On Tue, Oct 29, 2013 at 9:55 AM, Dan Andreescu dandreescu@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