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
jonat...@freebsd.org
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
