On 09/29/2015 05:25 PM, John Colvin wrote:
> auto pass = getPassword();
> pass.clean();
> assert(pass == pass.toLower());
> //and on we go ...

Interesting angle, but it's not something we should worry about. -- Andrei

On Tuesday, 29 September 2015 at 21:02:42 UTC, Nordlöw wrote:
> As a follow-up to
>
> https://github.com/D-Programming-Language/phobos/pull/3207#issuecomment-144073495
>
> I starting digging in DMD for logic controlling behaviour of assert(), especially whether it's possible to add automatic printing of `lhs` and `rhs` upon assertion failure if `AssertExp` is a binary expression say `lhs == rhs`.
>
> After grepping for `AssertExp` the only possible place I could think of was
>
> ToElemVisitor::visit(AssertExp *ae)
>
> inside
>
> elem *toElem(Expression *e, IRState *irs)
>
> in file e2ir.c.
>
> Questions:
>
> 1. Is this the right place where this lhs-rhs-printing logic should be added? If so could somebody tell me how to make this happen?
>
> 2. Is it possible to from within DMD generate expressions that do
>
> `import std.stdio : write`
>
> and then calls write on the `lhs` and `rsh`...or this a completely wrong approach to solving this problem?

I do think wiring this in the compiler is probably not the right way forward. Most language have some library functions like :

expect(exprssion).toBeTrue();
expect(function/delegate).toThrow!ExceptionType

And so on.

This allow to get nice error and do not need wiring int he language. This is extensible and all. I'd rather have something like this.

On 2015-09-30 05:45, deadalnix wrote:
> On Tuesday, 29 September 2015 at 21:02:42 UTC, Nordlöw wrote:
>> As a follow-up to
>>
>> https://github.com/D-Programming-Language/phobos/pull/3207#issuecomment-144073495

> I do think wiring this in the compiler is probably not the right way
> forward. Most language have some library functions like :
>
> expect(exprssion).toBeTrue();
> expect(function/delegate).toThrow!ExceptionType
>
> And so on.
>
> This allow to get nice error and do not need wiring int he language.
> This is extensible and all. I'd rather have something like this.

That's already what the above linked pull request does.

-- 
/Jacob Carlborg

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.

-- 
/Jacob Carlborg

On 09/30/2015 05:08 AM, Andrei Alexandrescu wrote:
> On 09/29/2015 05:25 PM, John Colvin wrote:
>> auto pass = getPassword();
>> pass.clean();
>> assert(pass == pass.toLower());
>> //and on we go ...
>
> Interesting angle, but it's not something we should worry about. -- Andrei

There's also the possibility of failing assertions within toString functions causing stack overflows.

On 09/29/2015 11:45 PM, deadalnix wrote:
> On Tuesday, 29 September 2015 at 21:02:42 UTC, Nordlöw wrote:
>> As a follow-up to
>>
>> https://github.com/D-Programming-Language/phobos/pull/3207#issuecomment-144073495
>>
>>
>> I starting digging in DMD for logic controlling behaviour of assert(),
>> especially whether it's possible to add automatic printing of `lhs`
>> and `rhs` upon assertion failure if `AssertExp` is a binary expression
>> say `lhs == rhs`.
>>
>> After grepping for `AssertExp` the only possible place I could think
>> of was
>>
>> ToElemVisitor::visit(AssertExp *ae)
>>
>> inside
>>
>> elem *toElem(Expression *e, IRState *irs)
>>
>> in file e2ir.c.
>>
>> Questions:
>>
>> 1. Is this the right place where this lhs-rhs-printing logic should be
>> added? If so could somebody tell me how to make this happen?
>>
>> 2. Is it possible to from within DMD generate expressions that do
>>
>> `import std.stdio : write`
>>
>> and then calls write on the `lhs` and `rsh`...or this a completely
>> wrong approach to solving this problem?
>
> I do think wiring this in the compiler is probably not the right way
> forward. Most language have some library functions like :
>
> expect(exprssion).toBeTrue();
> expect(function/delegate).toThrow!ExceptionType
>
> And so on.
>
> This allow to get nice error and do not need wiring int he language.
> This is extensible and all. I'd rather have something like this.

I encourage making assert smarter seeing (a) it's already used everywhere so the benefits will come for free and (b) it's a built-in. -- Andrei

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

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.

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.

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

-- 
Doubt is a self-fulfilling prophecy.

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.


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