Improving assert-printing in DMD

[Jonathan M Davis via Digitalmars-d]

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