On 2014-05-05 2:54 PM, Daniele M. wrote:
> Have you thought about creating an SSL/TLS implementations tester instead?

You mean testing existing TLS libraries using this information?

The advantages of using all-D is having zero-copy buffers that inline with the other layers of streams when built inside another D project. I can also add processor-specific assembler-code algorithms of AES and RSA from openSSL (optimizing the critical parts can put it on par or better in speed).

To answer the question about safety, the code is very modular and so when you decide to zero out memory of keys before/after serialization/deserialization or even for the buffers, it happens for everything regardless of the complexity of the application. It's definitely easier to make it safer!

On 05/05/2014 12:41 PM, Jonathan M Davis via Digitalmars-d wrote:
> Regardless, there's
> nothing fundamentally limited about @safe except for operations which are
> actually unsafe with regards to memory

What does 'actually unsafe' mean? @safe will happily ban statements that will never 'actually' result in memory corruption.

On Tue, 06 May 2014 09:56:11 +0200
Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 05/05/2014 12:41 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Regardless, there's
> > nothing fundamentally limited about @safe except for operations
> > which are actually unsafe with regards to memory
>
> What does 'actually unsafe' mean? @safe will happily ban statements that will never 'actually' result in memory corruption.

@safe is supposed to ban any code where it can't prove that it can't access memory that it shouldn't - be it to read from it to write to it - as well as code that it can't prove will not result in other code accessing memory that it shouldn't have access to. It's quite possible that some code which shouldn't be being banned is currently being banned, and it may be the case that we'll be stuck with some code being banned simply because we can't make the compiler smart enough to know that it doesn't need to ban it (though hopefully that's kept to a minimum). But @trusted is there precisely for the situations where an operation is unsafe in the general case but is perfectly safe in a specific case based on information that the compiler does not have access to but the programmer does (such as knowing that certain values will never be passed to the given function).

However, I don't think that there's much question that at this point @safe isn't quite correct. There are definitely cases right now that are considered @safe when they shouldn't be (e.g. https://issues.dlang.org/show_bug.cgi?id=8838 ), and I expect that there are also cases where code is considered @system when the compiler should consider it @safe (though I don't know of any of those off the top of my head).

- Jonathan M Davis

On Monday, 5 May 2014 at 15:01:05 UTC, Andrei Alexandrescu wrote:
> On 5/5/14, 2:32 AM, JR wrote:
>> On Sunday, 4 May 2014 at 21:18:24 UTC, Daniele M. wrote:
>>> And then comes my next question: except for that malloc-hack, would it
>>> have been possible to write it in @safe D? I guess that if not,
>>> module(s) could have been made un-@safe. Not saying that a similar
>>> separation of concerns was not possible in OpenSSL itself, but that D
>>> could have made it less development-expensive in my opinion.
>>
>> TDPL SafeD visions notwithstanding, @safe is very very limiting.
>>
>> I/O is forbidden so simple Hello Worlds are right out, let alone
>> advanced socket libraries.
>
> Sounds like a library bug. Has it been submitted? -- Andrei

When mentioned in #d it was met with replies of "well *obviously*", so I chalked it up to an irreconcilability of @safe's. Perhaps I'm expecting too much of the subset.

My code certainly does no pointer arithmetic, but adding @safe: in select locations quickly shows that string operations like indexOf are unsafe, as is everything in concurrency (including thisTid), getopt, std.conv.to (to avoid casts), and all socket operations. All of those can throw, but I don't see how they can corrupt memory.

Apologies for the negativity. It's not that much of a deal, but your code will have to be very unreliant upon phobos to be completely @safe. I appreciate these threads gauging community reactions and I hope the mood will be lighter post-dconf, but at present there's still a sour taste left in my mouth after the final-by-default pivot.

(Manu and Thaut, please don't leave~ :<   )

On Monday, 5 May 2014 at 14:59:13 UTC, Etienne wrote:
> On 2014-05-04 4:34 AM, Daniele M. wrote:
>> I have read this excellent article by David A. Wheeler:
>>
>> http://www.dwheeler.com/essays/heartbleed.html
>>
>> And since D language was not there, I mentioned it to him as a possible
>> good candidate due to its static typing and related features.
>>
>> However, now I am asking the community here: would a D implementation
>> (with GC disabled) of OpenSSL have been free from Heartbleed-type
>> vulnerabilities? Specifically
>> http://cwe.mitre.org/data/definitions/126.html and
>> http://cwe.mitre.org/data/definitions/20.html as David mentions.
>>
>> I find this perspective very interesting, please advise :)
>
> I'm currently working on a TLS library using only D. I've shared the ASN.1 parser here: https://github.com/globecsys/asn1.d
>
> The ASN.1 format allows me to compile the data structures to D from the tls.asn1 in the repo I linked to. It uses the equivalent of D template structures extensively with what's called an Information Object Class.
>
> Obviously, when it's done I need a DER serializer/deserializer which I intend on editing MsgPackD, and then I can do a handshake (read a ASN.1 certificate) and encrypt/decrypt AES/RSA using the certificate information and this cryptography library: https://github.com/apartridge/crypto .
>
> I've never expected any help so I'm not sure what the licensing will be. I'm currently working on the generation step for the ASN.1 to D compiler, it's very fun to make a compiler in D.

I've been working on an ASN.1 parser and D code generator [0].
Didn't get the BER encoder working but..
I thought it may be a good idea mention it here.

[0] https://github.com/rikkimax/asn1

On 5/6/14, 2:37 AM, JR wrote:
>
> Apologies for the negativity. It's not that much of a deal, but your
> code will have to be very unreliant upon phobos to be completely @safe.

It's a huge deal. Most of phobos should be @safe or @trusted! Please submit everything you find as bugs. Thanks! -- Andrei