Date: Thu, 10 Apr 2014 00:19:23 +1000 From: Kubilay Kocak <koobs.freebsd@gmail.com> To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= <des@des.no>, Bryan Drewery <bdrewery@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI <delphij@freebsd.org>, secteam@FreeBSD.org Subject: Re: svn commit: r264265 - in head: crypto/openssl/crypto/bn crypto/openssl/crypto/ec crypto/openssl/ssl sys/fs/nfsserver Message-ID: <534556EB.5080700@FreeBSD.org> In-Reply-To: <86bnwa7gav.fsf@nine.des.no> References: <201404081827.s38IRXiL048987@svn.freebsd.org> <e25208600d1ed778a20d6ac8596c658a@shatow.net> <86bnwa7gav.fsf@nine.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/04/2014 12:01 AM, Dag-Erling Smørgrav wrote: > Bryan Drewery <bdrewery@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?534556EB.5080700>