On Sep 27, 2016 11:09 AM, "Florian Weimer" <f...@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