On Tue, Oct 29, 2013 at 9:55 AM, Dan Andreescu <dandreescu(a)wikimedia.org> wrote:
I think Ori's original point stands though.
Configuration could be used to
redact fully / not redact at all for local debugging purposes. But a black
list for what to redact is bad for all the reasons black lists are bad
security in general.
Theoretically speaking, the right way to do this would be to identify
the (small, one hopes) number of *sources* of sensitive data and
change them to return objects of a special class, which would then
automatically print out as "[REDACTED]" (if so configured) in a stack
trace. This would have other benefits; for instance, the special class
could arrange to handle the data extra-carefully (scrubbing it from
memory when no longer required, doing constant-time comparisons, that
sort of thing) and code that needed to treat the datum as anything
other than an opaque blob would have to explicitly unwrap it, which
would then be a red flag for code review.
I don't have any idea how hard this would be; I'd guess somewhere
between "conceptually easy but a huge number of tedious
almost-but-not-quite-mechanical changes to implement" and "infeasible
due to API breakage".
zw