Improving assert-printing in DMD

[Dmitry Olshansky via Digitalmars-d]

On 01-Oct-2015 11:46, John Colvin wrote:
> On Wednesday, 30 September 2015 at 17:59:41 UTC, H. S. Teoh wrote:
>> On Wed, Sep 30, 2015 at 04:14:59PM +0000, John Colvin via
>> Digitalmars-d wrote:
>>> On Wednesday, 30 September 2015 at 14:53:31 UTC, H. S. Teoh wrote:
>>> >On Wed, Sep 30, 2015 at 08:30:47AM +0200, Jacob Carlborg via
>>> >Digitalmars-d wrote:
>>> >>On 2015-09-29 23:32, Andrej Mitrovic via Digitalmars-d wrote:
>>> >>
>>> >>>If you have plaintext passwords stored anywhere you are
>>> >>>>already
>>> >>screwed. ;)
>>> >>
>>> >>The password always starts out in plaintext, or do you hash >>it in
>>> the front end, as the users types? Since the back end >>shouldn't
>>> trust the front end, it needs to hash it again.
>>> >[...]
>>> >
>>> >The right way to do it is for the server to send a random >challenge
>>> which the front end (presumably running on the >user's machine)
>>> encrypts with the password, sending the >ciphertext back to the
>>> server.  The plaintext password is >never sent over wire, yet the
>>> only way the client can provide >the correct response is if it knows
>>> the password to begin >with.
>>> >
>>> >
>>> >T
>>>
>>> right. Nonetheless, sometimes code does have to work with sensitive
>>> data and you don't want it to leak outside the program in unexpected
>>> ways.
>>
>> Certainly.  But I have a hard time imagining a scenario where I'd use
>> assert() on sensitive data.  After all, assert() should be used to
>> verify program *logic*, not the data that the program is processing.
>> That's clearly in the realm of enforce() or just plain ole if(), IMO.
>>
>>
>> T
>
> 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.
>

To be honest to save us from this we should simply ban printing to 
stdout/stderr because some debug statement may print sensitive data.

Come on, there are better way to protect sensitive data then crippling 
language primitives/compiler switches.

Lastly - ALL data in a PC's RAM is wide open to sysadmins so anything in 
sitting in RAM is vulnerable anyhow.

> At the very least there should be a compiler switch to turn
> assert-printing on/off


-- 
Dmitry Olshansky