On Fri, Oct 27, 2017 at 09:20:13PM +0100, Ben Laurie
wrote:> On 27 October 2017 at 20:24, Poul-Henning Kamp <phk at
phk.freebsd.dk> wrote:
> > --------
> > In message <CAG5KPzws=jmF2wLeEAz8Lzn7Ugude=0w5neoQjeDjYnGtJpS9Q at
mail.gmail.com>
> > , Ben Laurie writes:
> >
> >>OpenSSL includes (and is used for) lots of crypto that is not used
in
> >>SSL - since BearSSL targets SSL/TLS only, it can't, presumably,
be
> >>used to replace all uses of OpenSSL.
> >
> > Which implicitly raises the question if we really need all the
> > boatloads of crap OpenSSL drags in, or if we would be in a better
> > position with something simpler and saner ?
>
> Indeed it does. Perhaps worth noting that since it was staffed,
> OpenSSL has removed a fair amount of crap, BTW.
Full disclosure: I am an OpenSSL committer (but not a member of the
management committee).
It is true that a lot of crap has been removed recently, and the test
suite has gotten more robust (not the least due to the addition of
a large portion of the BoringSSL test suite). But we're still constrained
by a heavy burden of API/ABI stability in major release branches (compounded
by a promise to make the next release branch 1.1.1, with TLS 1.3 support,
so ABI-breaking changes are currently on indefinite hold). That,
combined with an existing public API that grew quite organically and
without a great deal of thought, still makes for a system that is
hard to maintain well.
But I think the main issue with OpenSSL in base that was leading to
thoughts about replacing it is the mismatch between FreeBSD release
branch support lifecycles and OpenSSL release branch support lifecycles.
That is, we (FreeBSD) would be stuck supporting an OpenSSL version that
is EOL upstream, which is not a great position to be in.
On the other hand, upstream OpenSSL is taking ABI compatibility more
seriously, so it might be reasonable to (e.g.) upgrade from 1.1.0 to
1.1.1 within a FreeBSD stable branch than it would (not) have been
to upgrade from 1.0.1 to 1.0.2. That might make the support lifecycle
concerns go away.
> Anyway, to answer that question will presumably require someone to
> either try it, or figure out what is actually needed, crypto-wise.
Indeed, and I do not think I can volunteer.
-Ben
P.S., when Chris H mentioned "an alternative with a long history of
reliability, safety, and a great deal of scrutiny by seasoned developers,
and security engineers", I couldn't really tell what that alternative
was
supposed to be.