The end of curl (in phobos)

[Jonathan M Davis via Digitalmars-d]

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