Plaintext emails rendered from templates contain escaping

[keeakita]

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

1. Send any email using a text (not HTML) template, where one of the context variables being rendered contains special characters (&,<,>,',etc)

Expected Result

1. Email renders as straightforward plaintext without any form of escaping

Actual Result

Email is rendered with inappropriate escaping that's not needed

Product Area

Other

Link

No response

DSN

No response

Version

No response

[getsantry]

Routing to @getsentry/product-owners-other for triage ⏲️

[keeakita]

Y'know, I thought I could solve this in some fairly generic way, but this API is really painful. The options:

• Use mark_safe() in a central location. Doesn't work well because some of these templates have objects in their context that aren't strings.
• Wrap every email template in {% autoescape off %}, which opens us to regressions in the future if someone misses this
• Ensure that all templates use the safe filter, which also has the regression issue
• Define a new backend via TEMPLATES with autoescape=FALSE, then reference it by name. This would be fine except for the fact that default loader.render_to_string, used in multiple parts of the codebase, when not given a value for using=, will iterate through all configured engines. Adding an engine with autoescape turned off could result in unsafe renders app-wide! That's mildly terrifying.
• Create a whole new engine or backend instance just for rendering the plaintext emails. This could cause divergence in the more subtle parts of the logic between rending HTML and text emails, but might have to be the way to go.

[wedamija]

@keeakita Do you know which team owns this?

[markstory]

@wedamija I think it is 'unowned' but related to notifications.

[keeakita]

Ah yes sorry, this was just a thing I stumbled upon and took a crack at during hack week, unowned and I haven't been able to spend any time on it since