From owner-freebsd-ports@FreeBSD.ORG Sat Jun 13 19:51:03 2015 Return-Path: Delivered-To: freebsd-ports@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1B84EC for ; Sat, 13 Jun 2015 19:51:03 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [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 361AF8F2 for ; Sat, 13 Jun 2015 19:51:03 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t5DJooEA021169; Sat, 13 Jun 2015 12:50:55 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201506131950.t5DJooEA021169@gw.catspoiler.org> Date: Sat, 13 Jun 2015 12:50:50 -0700 (PDT) From: Don Lewis Subject: Re: OpenSSL Security Advisory [11 Jun 2015] To: michelle@sorbs.net cc: fbsd@xtaz.co.uk, ml@netfence.it, freebsd-ports@FreeBSD.org In-Reply-To: <557C2230.4070502@sorbs.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 19:51:03 -0000 On 13 Jun, Michelle Sullivan wrote: > Matt Smith wrote: >> On Jun 13 13:13, Michelle Sullivan wrote: >>> Don Lewis wrote: >>>> On 13 Jun, Michelle Sullivan wrote: >>>> >>>> >>>>> SSH would be the biggie that most security departments are scared >>>>> of... >>>>> >>>> >>>> Well, ssh is available in ports, though I haven't checked to see >>>> that it >>>> picks up the correct version of openssl. >>>> >>>> >>> >>> Problem is it doesn't have 'overwrite base' anymore - and >>> openssh-portable66 which does have overwrite base is now marked >>> depreciated... which means one would have to be very careful about how >>> they use SSH in production as both server and client... Server is >>> easier as it has a different _enable identifier... but the client is not >>> distinguishable so unless one puts /usr/local/bin in their permanent >>> path as a priority over /usr/bin one will use the wrong version. >>> >> >> I put WITHOUT_OPENSSH=yes in /etc/src.conf. Then run make delete-old >> and make delete-old-libs in /usr/src. This removes the base version >> which means you don't have this issue any longer. I do the same thing >> with NTP and Unbound as well. >> >> Obviously this makes more sense if like me you do source based stuff >> rather than using freebsd-update. I'm not sure if you can do similar >> with binary based upgrades? >> > > 57 servers around the world that I have to maintain, patch and upgrade > at the same time as devel and maintain my applications... yeah I don't > do source stuff ;-) > > It would be useful to have that option in freebsd-update. > >> The other alternatives are as you say, put /usr/local/bin before >> /usr/bin in the $PATH. Or add an alias for commands like ssh to point >> to the ports version. These methods aren't quite as clean though. >> > Not clean and very error prone... replace base was a lot cleaner and > less error prone... but then you never know the people in security might > surprise us and put out a version of base with openssl 1.0.2b in it - > this would be a real bonus for a lot of people and take us a little bit > away from debian where you can wait months/years for an update.... and > then sometimes only if you upgrade your system to include features that > you don't want. Something to consider is building your own customized releases and setting up your own freebsd-update server. It's an additional headache, but would allow you to eliminate some possible additional hazards, such as the setuid rsh and rlogin. I'm thinking about doing it here. I generally track -STABLE and have some src.conf tweaks, so I'm used to doing source upgrades, but some of my machines are pretty slow and being able to keep them up to date with freebsd-update would be a time saver. Upgrading base openssl to 1.0.2 in an existing release branch is pretty much not going to happen because of the ABI change. A freebsd-update that did such a thing would instantly break all non-base applications that were linked to base openssl. FreeBSD is not unique in this regard. For instance, RHEL 5 is supported as a production release through March 2017, with extended support available through November 2020. It is still using openssl 0.98. It'll be interesting to see what Red Hat does once openssl 0.98 goes EOL at the end of 2015. I suspect that Red Hat will continue to maintain 0.98 internally and backport security fixes to it. The only branch where ABI changes is allowed is HEAD, so until we can change the openssl ABI in FreeBSD 11 up until FreeBSD 11.0-RELEASE. I suspect that sometime before that point, we will remove openssl from the the ABI by making it a private library in base so that its only consumers are other applications in base. That would allow us to upgrade the openssl version at any time, since the freebsd-update run that installed the new openssl would also install the new versions of the affected base applications. Ports would use only the ports version of openssl, and updates there would also be atomic. There are a number of problems to solve to get from here to there, such as the linkage between gssapi and libfetch to openssl. Also pkg might need to bundle its own private copy of openssl.