From owner-svn-src-all@FreeBSD.ORG Wed Apr 9 14:19:32 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 777C64F1; Wed, 9 Apr 2014 14:19:32 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B9031CE6; Wed, 9 Apr 2014 14:19:32 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id lf10so2583377pab.13 for ; Wed, 09 Apr 2014 07:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lzOBzydKyGRoF/BSkq2aKztorH+dDgj1awxwEatE3D0=; b=xSHa68G6GeLgcF+ywe3szg7TtBaHBb7LdQ64fOj5Hfo1aP6N9wfsCwTfnW6uK3JhCH vj1IAKOq0qdAq3+RrS8EfQxIl54duNU/HLfFP8edDsMZvMDGHzpc+zc8JrrAT6URMVRK xXyR4CvZ5A5r459H+MGne62e5PFFX4ylCEV5MfEHLwH9TQ0ke0049plAjbHWwJZNo/Pm tJCKi9y43MQleX+r2Tpfm8AGp/dHE71W5K7cqUGRLxX3S+Ws732FMNX0//0DBnCoT3Em 3u05rmmkJT182BybySaGjRLH6GzTT93CZYv0Jg3S7dV6o0AAI7maHvS13KxvGorCqslI Pg/g== X-Received: by 10.69.8.225 with SMTP id dn1mr12534521pbd.46.1397053171774; Wed, 09 Apr 2014 07:19:31 -0700 (PDT) Received: from [192.168.1.7] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id xk3sm2842434pbb.65.2014.04.09.07.19.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Apr 2014 07:19:31 -0700 (PDT) Message-ID: <534556EB.5080700@FreeBSD.org> Date: Thu, 10 Apr 2014 00:19:23 +1000 From: Kubilay Kocak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , Bryan Drewery Subject: Re: svn commit: r264265 - in head: crypto/openssl/crypto/bn crypto/openssl/crypto/ec crypto/openssl/ssl sys/fs/nfsserver References: <201404081827.s38IRXiL048987@svn.freebsd.org> <86bnwa7gav.fsf@nine.des.no> In-Reply-To: <86bnwa7gav.fsf@nine.des.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI , secteam@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: koobs@FreeBSD.org List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:19:32 -0000 On 10/04/2014 12:01 AM, Dag-Erling Smørgrav wrote: > Bryan Drewery 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