On Sep 27, 2016 11:09 AM, "Florian Weimer" <fw_at_deneb.enyo.de> wrote:
>
> * bch:
>
> > Being devil's advocate, I think the level of responsibility, detail,
cost
> > of errors for getting into random-management and cryptography may be so
> > high that it really should be left to alternative software libcurl
consumes
> > (e.g. openssl), and should simply bail when it detects anomalies.
>
> The problem here is that for historic reasons, OpenSSL provides plenty
> of hooks so that you could use it securely on entropy-less systems.

I'm completely open to being wrong, so don't misinterpret my writing as
declarative, but should libcurl 7.50.x+ development be considerate of
historic openssl work? If this (in-curl random-handling) is broken now, are
we going to provide a "fix" for a combination (modern libcurl, old ssl)
that is vanishingly rarely ever going to occur in the wild? I don't know
the answer, but am interested to hear what systems might be at risk here.

-bch

> libcurl tries to abstract from that, instead of requiring that
> applications initialize OpenSSL as required, or use a
> platform-provided OpenSSL implementation which has all this built in.
>
> At least we have this built-in entropy sources in OpenSSL on most
> platforms nowadays. Locking is still application-provided and perhaps
> even more critical.
> -------------------------------------------------------------------
> List admin: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-09-27