My only concern is that it would greatly reduce the usefulness of the
exception reporter, and might lead to people removing the
sensitive_variables decorator in order to see exception tracebacks.
Perhaps rather than obscure all local variables below the decorated
function, we could obscure any variable with the same *value* as a
sensitively marked variable in the call stack? This would work better with
strings than say dictionaries, but it could be a good middle ground.
On Wed, 4 Apr 2018, 21:05 ncvc via Django developers (Contributions to
Django itself), <firstname.lastname@example.org> wrote:
> SafeExceptionReporterFilter obfuscates variables in the function decorated
> with sensitive_variables, but it does not obfuscate variables lower in the
> call stack, which could result in sensitive data being leaked in exception
> For instance:
> def decorated_function():
> sensitive = 'something sensitive'
> def undecorated_function(var):
> raise Exception()
> In this code, the "sensitive" variable will be obfuscated in
> the decorated_function stack frame, but "var" in the undecorated_function
> stack frame will not, resulting in the sensitive data being leaked in the
> report. If we wrote undecorated_function, then we can just decorate the
> function ourselves, but if it's from a third-party package, we are unable
> to decorate it.
> The solution here is to obfuscate _all_ variables in all stack frames
> below a function decorated with sensitive_variables, since these functions
> can do arbitrary things with the sensitive data. I've written a custom
> SafeExceptionReporterFilter that does this for the company I work for, and
> I think it would be a good behavior to adopt in core Django.
> Any thoughts or concerns with this approach?
> This message, including any attachments, is a PRIVATE communication, which
> may contain confidential, legally privileged, and/or proprietary
> information. If you are not the intended recipient, you are hereby
> notified that any dissemination, disclosure, copying, distribution or use
> of the information contained in or attached to this message is strictly
> prohibited. Please notify the sender of the delivery error by replying to
> this message, and then permanently delete it from your system. Unless
> explicitly stated to the contrary, nothing contained in this message shall
> constitute an offer to buy or sell, or a solicitation of an offer to buy or
> sell, any security, property interest or other asset, nor shall it
> constitute a binding obligation of any kind, an official confirmation of
> any transaction or an official statement of Cadre.
> Cadre may monitor, review and retain email communications traveling
> through its networks or systems, AND CADRE IS NOT OBLIGATED TO RESTRICT THE
> USE OR DISCLOSURE OF ANY INFORMATION SENT TO IT BY YOU VIA E-MAIL
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to email@example.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.