On Monday, May 09, 2016 09:35:18 sigod via Digitalmars-d wrote: > On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote: > > But given that std.net.curl handles stuff like SSL/TLS, we > > _can't_ actually replace all of its functionality - at least > > not without adding a dependency on a different C library, since > > there's no way that it's sane to do the crypto stuff ourselves > > without a crypto expert, and even then, we should think twice > > about it. I could see implementing the SSL/TLS protocols > > themselves but not the crypto they use. If we replace > > std.net.curl, we likely should just provide the basic HTTP > > functionality, and leave the rest to a dub package that we move > > std.net.curl to. > > Any chances that we can produce good crypto code over time? And > verify it with experts, of course.
I'm sure that it's possible, but it's also very dangerous territory to deal with. Even if you get the crypto itself right, there are all kinds of other nasty problems you have to worry about that most people won't - like ensuring that certain operations take the same amount of time regardless of whether they succeed or not so that folks snooping can't figure out what is and isn't succeeding. There's also the issue of keeping up-to-date with which protocols should be used and which shouldn't (e.g. if I understand correctly, pretty much nothing should be using SSL now; it should all be TLS). So, while there is no technical barrier to us implementing all of this in D (the crypto itself included), it's a very tall order to get it right. Having the code vetted by experts would _definitely_ help, but it's going to go a lot better if we have a security expert writing and maintaining the code, and I'm not sure that we have anyone like that among our active contributors right now (though someone like that is definitely welcome to start contributing code). I actually considered implementing SSL in D at one point (with the idea that I'd use a C or C++ library for the crypto itself), but the more that I learn about this stuff, the more leery I am of implementing anything that's in the security domain. And the only way that I would ever consider doing the crypto itself would be by porting C code that did it, and even that seems pretty hairy - especially since I wouldn't have the knowledge necessary to maintain it. So, we may very well end up with full-on crypto stuff written in D at some point - maybe even in the standard library - but it's something that we need to be very careful with. - Jonathan M Davis