Date: Thu, 12 Jun 2014 00:43:02 +0200 From: Dan Lukes <dan@obluda.cz> To: Jonathan Anderson <jonathan@FreeBSD.org> Cc: freebsd-security <freebsd-security@freebsd.org> Subject: Re: OpenSSL end of life Message-ID: <5398DB76.3040707@obluda.cz> In-Reply-To: <539888B0.9090108@FreeBSD.org> 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> <539888B0.9090108@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/11/14 18:49, Jonathan Anderson: > 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). So your proposal is to make something like wrapper library around OpenSSL. Such wrapper library will offer stable ABI to the rest of system and will hide possible ABI changes of underlying native OpenSSL. If the underlying OpenSSL will be replaced by other one, the wrapper library will be modified accordingly, to maintain previous ABI. Right ? It sound plausible to me. I'm not sure it will take less resources that self-support of old OpenSSL version, but I can't estimate it right now. >> 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? OpenSSL is considered part of base system. Either we can support the system for it's lifetime or not. If we have resources to maintain 5-years lifetime, then OK, I will welcome 5-year lifetime. If we have no such resources, then declared lifetime should to be shortened. Both solutions are OK for me. I have nothing against current 1y/2y system. > On 06/11/14 22:31, Joe User: >> Sorry, but i heard/read this kind of discussion since two decades now It can't be overlooked. You are claiming the arguments that are not mine, then you are responding to them. I'm sure you can continue without me even in the future ;-) Dan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5398DB76.3040707>