On Thursday, 1 October 2015 at 09:59:41 UTC, Jonathan M Davis
wrote:
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
All reasonable points, so I guess it's not such a bad thing after
all. I just wanted to be sure that security was considered here.