On Tuesday, 8 April 2014 at 20:20:59 UTC, Brad Anderson wrote:
> Good point. I think perhaps a -boundscheck is in order if the

What about:

-boundscheck=<none|safe|all>

which defaults to 'all' and to 'safe' in combination with -release

-noboundscheck would be the same as -boundscheck=none

If compatibility is not an issue and we want to keep it simple, than -release should just turn off asserts and contracts.

On Tuesday, 8 April 2014 at 20:50:35 UTC, Steven Schveighoffer wrote:
> On Tue, 08 Apr 2014 16:07:53 -0400, Brad Anderson <eco@gnuk.net> wrote:
>
>> On Tuesday, 8 April 2014 at 19:47:02 UTC, Andrei Alexandrescu wrote:
>>> On 4/8/14, 1:47 AM, Paulo Pinto wrote:
>>>> Me too am glad see bounds checking in D by default.
>>>
>>> For the record, dmd used to remove bounds checking in -release mode. I've asked Walter to add a new flag for that, independent from -release, thus keeping release builds safer. It was the first and last time when I used "if you don't do this, I can't work on D anymore" card. True story.
>>>
>>>
>>> Andrei
>>
>> There is a lot of confusion about this so I looked into it.
>>
>> dmd still removes bound checking in non-@safe code when you specify -release. -noboundscheck just causes it to remove bounds checking in @safe code too. This is why I think it should be renamed -nosafeboundschecking or something similar.
>
> This does not sound correct. In NO case should you be able to remove bounds checking in @safe code.
>
> -Steve

Then we have a bug because that's how it works currently.

https://github.com/D-Programming-Language/dmd/blob/a3743bc645fc065104470cdecbd64e3f14034fdf/src/irstate.c#L193

Reminder of the magic numbers' meanings:
- 2 is the default[1]
- 1 if -release is specified[2]
- 0 if -noboundscheck is specified[3].

1. https://github.com/D-Programming-Language/dmd/blob/404bbbd1543b045d32166a4462b4bf1f271fbe7c/src/mars.c#L567
2. https://github.com/D-Programming-Language/dmd/blob/404bbbd1543b045d32166a4462b4bf1f271fbe7c/src/mars.c#L1144
3. https://github.com/D-Programming-Language/dmd/blob/404bbbd1543b045d32166a4462b4bf1f271fbe7c/src/mars.c#L1148

On 4/8/14, 1:07 PM, Martin Krejcirik wrote:
> On Tuesday, 8 April 2014 at 19:47:02 UTC, Andrei Alexandrescu wrote:
>> For the record, dmd used to remove bounds checking in -release mode.
>> I've asked Walter to add a new flag for that, independent
>
> It still does (for un-@safe functions) and there is no way to turn it on
> (if you don't want asserts and contracts).

:o|

We need to fix that.

Andrei

On Tuesday, 8 April 2014 at 21:01:26 UTC, Martin Krejcirik wrote:
> On Tuesday, 8 April 2014 at 20:20:59 UTC, Brad Anderson wrote:
>> Good point. I think perhaps a -boundscheck is in order if the
>
> What about:
>
> -boundscheck=<none|safe|all>
>
> which defaults to 'all' and to 'safe' in combination with -release
>
> -noboundscheck would be the same as -boundscheck=none

Asked Andrei in IRC about it and he liked -boundscheck=.

https://d.puremagic.com/issues/show_bug.cgi?id=12550

I'll try to make a pull request if someone else doesn't beat me to it.

On Mon, 07 Apr 2014 21:36:28 -0400, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On 4/7/2014 7:28 PM, w0rp wrote:
>> http://heartbleed.com/
>>
>> This bug has been getting around. The bug was caused by missing bounds
>> checking.
>>
>> I'm glad to be using a language with bounds checking.
>
> Whelp, time for that server system upgrade I've been putting off for far too long...
>

In theory, patching openSSL doesn't solve the problem, because someone could have previously used the vulnerability to get your private key.

So technically you need to also get a new cert. This is what my password-generation vendor (lastpass.com) is recommending:

1. Generate a new password for your most critical sites.
2. But only after they get a cert dated after today!

I don't think many people understand this aspect.

Hopefully, this vulnerability was not known by hackers before it was announced. Even if it was, there is quite a window of opportunity for them as the patched sites roll out.

-Steve

On 4/8/2014 8:50 PM, Steven Schveighoffer wrote:
> On Mon, 07 Apr 2014 21:36:28 -0400, Nick Sabalausky
> <SeeWebsiteToContactMe@semitwist.com> wrote:
>>
>> Whelp, time for that server system upgrade I've been putting off for
>> far too long...
>>
>
> In theory, patching openSSL doesn't solve the problem, because someone
> could have previously used the vulnerability to get your private key.
>
> So technically you need to also get a new cert. This is what my
> password-generation vendor (lastpass.com) is recommending:
>
> 1. Generate a new password for your most critical sites.
> 2. But only after they get a cert dated after today!
>
> I don't think many people understand this aspect.
>
> Hopefully, this vulnerability was not known by hackers before it was
> announced. Even if it was, there is quite a window of opportunity for
> them as the patched sites roll out.
>

Very good point.

Luckily for me (and yet, simultaneously embarrassing), my server's version of openssl turned out not to be affected. Which is nice since I *just* paid for a new cert about one week ago.

Am Mon, 07 Apr 2014 23:28:02 +0000
schrieb "w0rp" <devw0rp@gmail.com>:

> http://heartbleed.com/
> 
> This bug has been getting around. The bug was caused by missing bounds checking.
> 
> I'm glad to be using a language with bounds checking.

Sorry, but wasn't this security risk instead caused by uninitialized memory, and shouldn't you instead have said:

"I'm glad to be using a language with default initialization?"


(The attacker could request a larger packet size than required
for the requested data and malloc() doesn't zero out the rest
of the memory block, possibly containing sensitive data.)

In an article I read that malloc implementations using mmap
are more seriously affected, since that memory can come from
anywhere whereas the sbrk version is usually reusing memory
from the calling process.
I didn't understand that, since mmap on Linux returns zeroed
out pages. Process isolation is actually pretty good.
And frankly, had the OpenSSH developers replaced the m with c
in malloc, they could have avoided a lot of trouble as well.
But as it goes with such low level libraries performance is
very important to put load off servers for what is today seen
as a normal part of the network stack. I don't think any of
these calls for "safer languages" will change that the
developers want to win in those throughput benchmarks with
their implementation and keep using unsafe functions.

-- 
Marco

On Tuesday, 8 April 2014 at 21:52:56 UTC, Brad Anderson wrote:
> On Tuesday, 8 April 2014 at 21:01:26 UTC, Martin Krejcirik wrote:
>> On Tuesday, 8 April 2014 at 20:20:59 UTC, Brad Anderson wrote:
>>> Good point. I think perhaps a -boundscheck is in order if the
>>
>> What about:
>>
>> -boundscheck=<none|safe|all>
>>
>> which defaults to 'all' and to 'safe' in combination with -release
>>
>> -noboundscheck would be the same as -boundscheck=none
>
> Asked Andrei in IRC about it and he liked -boundscheck=.
>
> https://d.puremagic.com/issues/show_bug.cgi?id=12550
>
> I'll try to make a pull request if someone else doesn't beat me to it.

https://github.com/D-Programming-Language/dmd/pull/3443

On Tuesday, 8 April 2014 at 20:50:35 UTC, Steven Schveighoffer wrote:
> This does not sound correct. In NO case should you be able to remove bounds checking in @safe code.

It is. In fact, that's the very reason why DMD has -noboundscheck in addition to -release.

David

On Tuesday, 8 April 2014 at 21:23:35 UTC, Andrei Alexandrescu wrote:
> On 4/8/14, 1:07 PM, Martin Krejcirik wrote:
>> On Tuesday, 8 April 2014 at 19:47:02 UTC, Andrei Alexandrescu wrote:
>>> For the record, dmd used to remove bounds checking in -release mode.
>>> I've asked Walter to add a new flag for that, independent
>>
>> It still does (for un-@safe functions) and there is no way to turn it on
>> (if you don't want asserts and contracts).
>
> :o|
>
> We need to fix that.

Just for the record, LDC has -enable-boundscheck and -disable-boundscheck (in line with all the other flags for enabling-disabling certain features). If neither is specified, the DMD default (-release disables checks in non-@safe code) is used.

David