On Thursday, 1 October 2015 at 08:46:51 UTC, John Colvin wrote:
Checks involving sensitive data after processing can definitely
be a check of program logic.
Sensitive data enters program
Sensitive data is checked using enforce
Sensitive data is passed to another function, but something
goes wrong (not enough checking before, wrong function called,
HDD dies, someone trips over a network cable), an assert is
triggered, the sensitive data spills to stderr.
A perfectly correct program in perfect circumstances will never
assert, but real programs in real situations will.
In almost all cases, printing out an assertion is by far the best
thing to do, and in general, the more information that's printed,
the better. But if anyone is dealing with sensitive data, they
_have_ to be smart about what they do with it, and if that means
that they can't put it an assertion directly, because assertions
print too much information, then so be it. We're talking about a
minority case where almost every other program would benefit.
Most programs don't even have assertions turned on in release,
which is where this would matter.
If a failed assertion could print out sensitive information, then
just don't put the information directly in the assertion. Heck,
anyone paranoid enough about it could create a special
secureAssert function or something that did something like
void secureAssert(E)(lazy E expression,
lazy string msg,
string file = __FILE__,
size_T line = __LINE__)
{
version(assert)
{
immutable result = cast(bool)expression();
if(!result)
throw new AssertError(msg, file, line);
}
}
I see no reason to make the debugging tools that we have worse
because of fear of someone who's writing code that processes
sensitive information. That code just needs to be written in a
way that's not going to leak the information. As Dmitry points
out, there are plenty of other ways for the information to be
leaked. So, not improving assertions due to security concerns
really isn't a valid approach IMHO.
Now, there are other reasons why we might not want to (e.g. if
the performance were worse, you might not want to make assertions
print additional information), but I think that it's far better
for code that needs to be that secure to do its own thing than to
hamper everyone over the concerns of the minority.
At the very least there should be a compiler switch to turn
assert-printing on/off
I expect that most folks who would want to avoid have assertions
printing out sensitive information would still want assertions
that didn't relate to sensitive information to print. A compiler
switch is a pretty blunt instrument, especially when someone
could write their own code which asserts without showing any
sensitive information while still testing that information.
- Jonathan M Davis
