From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 16:49:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD7B87DE for ; Wed, 11 Jun 2014 16:49:54 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B03552BA0; Wed, 11 Jun 2014 16:49:54 +0000 (UTC) Received: from janderson.engr.mun.ca (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s5BGnrQa014445; Wed, 11 Jun 2014 16:49:54 GMT (envelope-from jonathan@FreeBSD.org) Message-ID: <539888B0.9090108@FreeBSD.org> Date: Wed, 11 Jun 2014 14:19:52 -0230 From: Jonathan Anderson User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dan Lukes Subject: Re: OpenSSL end of life References: <5398482C.7020406@obluda.cz> <539859BC.2050303@obluda.cz> <539860DE.9080609@FreeBSD.org> <53987248.5050103@obluda.cz> In-Reply-To: <53987248.5050103@obluda.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:49:54 -0000 Dan Lukes wrote: > In such case, the content of /usr/src/contrib needs to be reevaluated > very carefully. The OpenSSL is not only external library here ... OpenSSL is a bit special, though. The ABI for, e.g., jemalloc isn't likely to change very much upstream, nor are we likely to break it for security updates. If our version of OpenSSL goes EOL, however, that's very much a security concern. >> It seems to me that the only solution is to remove the ABI promise on >> OpenSSL: move the base system's libcrypt.so into /usr/lib/private. > > You are proposing to change meaning of words "patch" and "upgrade". > Sure, if we will call some upgrades as patches, then version number > needs not to be bumped > > But it's just magic with the words It's not just wordsmithing: right now, we promise not to break the x/stable ABI as long as there are x.y releases. That ABI includes things that, realistically, we aren't in a position to maintain. I propose that we be a bit more careful about the libraries that we're willing to commit to an ABI on, restricting ourselves to things that we are able to maintain internally as a project or where upstream changes don't break the ABI (e.g. an executable where the interface is the command line, so all we have to do is preserve existing arguments). > Note - English is not my native language. The text above is not offense > in any way. It explained how I understood the solution your mentioned. Perhaps I didn't explain myself very well: I hope my proposal is clearer now. > I prefer other solution mentioned in the thread. We need to support > particular version of OpenSSL by self during lifetime of particular > release. Sure, we could do point patches of old OpenSSL versions as vulnerabilities are discovered, but who's to say that we'll hear about them if the upstream vendor has stopped doing security advisories? If everybody else has moved on from 0.9.8, who in the FreeBSD project is willing to take ownership of such a large and complex code base? Jon -- Jonathan Anderson jonathan@FreeBSD.org