Date: Wed, 11 Jun 2014 14:19:52 -0230 From: Jonathan Anderson <jonathan@FreeBSD.org> To: Dan Lukes <dan@obluda.cz> Cc: freebsd-security <freebsd-security@freebsd.org> Subject: Re: OpenSSL end of life Message-ID: <539888B0.9090108@FreeBSD.org> In-Reply-To: <53987248.5050103@obluda.cz> References: <CAG5KPzyYzcu0qF9m2Fjgh7tTC=RrSMpxzHiDX5zD8_U_aB8k2A@mail.gmail.com> <5398482C.7020406@obluda.cz> <CAG5KPzxQm1ayF=p5pAsttHvxoAOFvNTvxhe6AS-auX27mxdywg@mail.gmail.com> <539859BC.2050303@obluda.cz> <539860DE.9080609@FreeBSD.org> <53987248.5050103@obluda.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Lukes wrote: > In such case, the content of /usr/src/contrib needs to be reevaluated > very carefully. The OpenSSL is not only external library here ... OpenSSL is a bit special, though. The ABI for, e.g., jemalloc isn't likely to change very much upstream, nor are we likely to break it for security updates. If our version of OpenSSL goes EOL, however, that's very much a security concern. >> It seems to me that the only solution is to remove the ABI promise on >> OpenSSL: move the base system's libcrypt.so into /usr/lib/private. > > You are proposing to change meaning of words "patch" and "upgrade". > Sure, if we will call some upgrades as patches, then version number > needs not to be bumped > > But it's just magic with the words It's not just wordsmithing: right now, we promise not to break the x/stable ABI as long as there are x.y releases. That ABI includes things that, realistically, we aren't in a position to maintain. I propose that we be a bit more careful about the libraries that we're willing to commit to an ABI on, restricting ourselves to things that we are able to maintain internally as a project or where upstream changes don't break the ABI (e.g. an executable where the interface is the command line, so all we have to do is preserve existing arguments). > Note - English is not my native language. The text above is not offense > in any way. It explained how I understood the solution your mentioned. Perhaps I didn't explain myself very well: I hope my proposal is clearer now. > I prefer other solution mentioned in the thread. We need to support > particular version of OpenSSL by self during lifetime of particular > release. Sure, we could do point patches of old OpenSSL versions as vulnerabilities are discovered, but who's to say that we'll hear about them if the upstream vendor has stopped doing security advisories? If everybody else has moved on from 0.9.8, who in the FreeBSD project is willing to take ownership of such a large and complex code base? Jon -- Jonathan Anderson jonathan@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539888B0.9090108>