svn commit: r264265 - in head: crypto/openssl/crypto/bn crypto/openssl/crypto/ec crypto/openssl/ssl sys/fs/nfsserver

[Kubilay Kocak]

On 10/04/2014 12:01 AM, Dag-Erling Smørgrav wrote:
> Bryan Drewery <bdrewery at FreeBSD.org> writes:
>> Also, that this was a partial release of 1.0.1g is confusing a LOT of
>> users. They think they are still vulnerable. They expect to see 1.0.1g
>> in 'openssl version'. We could have our own version string in 'openssl
>> version' to remedy this.
> 
> This is no different from what other OSes do, e.g. RHEL6.5:
> 
> % cat /etc/redhat-release 
> Red Hat Enterprise Linux Workstation release 6.5 (Santiago)
> % openssl version
> OpenSSL 1.0.1e-fips 11 Feb 2013
> % TZ=UTC rpm -qi openssl
> Name        : openssl                      Relocations: (not relocatable)
> Version     : 1.0.1e                            Vendor: Red Hat, Inc.
> Release     : 16.el6_5.7                    Build Date: Mon 07 Apr 2014 11:34:45 AM UTC
> Install Date: Tue 08 Apr 2014 05:18:52 AM UTC      Build Host: x86-027.build.eng.bos.redhat.com
> [...]
> 
> which despite the version number and date is *not* vulnerable.
> 
> DES
> 

More precisely, users expect *not* to see 1.0.1e

That expectation is orthogonal to whether we or other projects do it one
way or another. RHEL users may well be as confused as ours (whether of
not ours are). It may be relevant as a data point, but not for decision
making.

Whether its just 1.0.1e, a full 1.0.1g, e+foo, or additional meta
obviously matters, but it's not as important as distinguishing 'what we
want' with how we're going to do it and why.

I'll give it a crack:

"Our users can quickly and clearly see and know, on the system, when a
vendored library or piece of software in base is patched, or partially
updated to account for bugs or security vulnerabilities in a supported
version of FreeBSD"

./koobs