On 2015-05-16 07:20, Kimmo Paasiala wrote:> On Fri, May 15, 2015 at 9:34 PM, Roger Marquis <marquis at 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.