On 2015-05-16 07:20, Kimmo Paasiala wrote:
On Fri, May 15, 2015 at 9:34 PM, Roger Marquis <marq...@roble.com> wrote:
Mark Felder wrote:
Another option is a second openssl port, one that overwrites base and
guarantees compatibility with RELEASE. Then we could at least have all
versions of openssl in vuln.xml (not that that's been a reliable
indicator of security of late).
This will never work. You can't guarantee compatibility with RELEASE and
upgrade it too.
How do you figure? RedHat does exactly that with every backport, and
they do it for the life of a release.
Redhat makes no promise of binary compatibility for locally compiled
software. They can update OpenSSL as they wish from version 1.0.1 to
1.0.2, recompile all affected packages (all of Redhat "userland" is
covered by .rpm packages) and push them to the users and advise users
of locally compiled software to recompile what they have. This is
unacceptable in FreeBSD that makes a hard promise that the ABI will
remain compatible troughout the whole lifetime of the same major
version line.
I'm really glad that FreeBSD makes that promise. It means I have a
long-lived and well-defined scope of compatibility for a given system.
It makes freebsd-update and pkg possible in production. I no longer
have to deal with localized system images.
That's paired with support for linking to openssl from ports and
FreeBSD's recent direction of decoupling network services from the base.
I have systems where all of the user-facing services link to openssl
1.0.2 even though the base OS doesn't. That means the time it will take
to reimplement and test on what will eventually become 11.0 won't
interact chronologically with the security needs of my existing
deployments on 10.x. It means "following -current in preprod" is no
longer part of my dayjob. That's a huge deal.
_______________________________________________
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"
