From owner-freebsd-security@FreeBSD.ORG Fri May 15 21:53:35 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C10D4302 for ; Fri, 15 May 2015 21:53:35 +0000 (UTC) Received: from gw.catspoiler.org (unknown [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57A43190C for ; Fri, 15 May 2015 21:53:35 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t4FLrQGj021958; Fri, 15 May 2015 14:53:30 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201505152153.t4FLrQGj021958@gw.catspoiler.org> Date: Fri, 15 May 2015 14:53:26 -0700 (PDT) From: Don Lewis Subject: Re: Forums.FreeBSD.org - SSL Issue? To: marquis@roble.com cc: freebsd-security@FreeBSD.org In-Reply-To: <20150515183437.A2380A09@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 21:53:35 -0000 On 15 May, Roger Marquis 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. They have paying customers to cover the cost of the salaries of the Red Hat employees who backport security fixes to whatever version of software that they included in the initial release if it has been abandoned by its upstream source. Don't expect any new features, though. According to , RHEL 4 is supported through March 2017 and RHEL 5 is supported through November 2020, though both are now in the extended lifecycle support phase, which is an "add on" and probably costs an extra leg. RHEL 4 uses openssl 0.9.7 and RHEL 5 uses openssl 0.9.8. According to , upstream support for the former ended in February 2007 and the latter will end at the end of 2015. Neither support TLS v1.1 or v1.2. If you need that and you are stuck on one of these versions of RHEL, you are on your own and have to wedge a newer version into the system yourself by downloading the source, running configure and make, and installing under /usr/local. Then you need to build whatever needs the new openssl yourself, making sure that it picks up the right version. No shiny RPMs for you! I used to run CentOS 4 (RHEL 4 clone) at a previous job. It came with an ancient version of gcc that wasn't capable of compling some other piece of software that I needed. I needed to wedge in a recent version of gcc, binutils, and a bunch of other dependencies before I could even get around to building the software package that actually needed.