From owner-freebsd-ports@FreeBSD.ORG Sat Jun 13 05:52:03 2015 Return-Path: Delivered-To: freebsd-ports@hub.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 357DA552 for ; Sat, 13 Jun 2015 05:52: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 BA004EF3 for ; Sat, 13 Jun 2015 05:52:02 +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 t5D5pqiO084627; Fri, 12 Jun 2015 22:51:57 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201506130551.t5D5pqiO084627@gw.catspoiler.org> Date: Fri, 12 Jun 2015 22:51:52 -0700 (PDT) From: Don Lewis Subject: Re: OpenSSL Security Advisory [11 Jun 2015] To: michelle@sorbs.net cc: ml@netfence.it, freebsd-ports@FreeBSD.org In-Reply-To: <557B9D53.2010805@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 05:52:03 -0000 On 13 Jun, Michelle Sullivan wrote: > Don Lewis wrote: >> >> I'm still running 8.4 here (but planning on upgrading to 10.1 in the >> next couple of weeks). I use poudriere to build my own package set with >> customized options, and I mentioned a couple weeks ago on >> freebsd-security@ that I switched my packages to use the openssl port >> instead of openssl from base by adding WITH_OPENSSL_PORT=yes to >> make.conf. The only significant problem that I ran into was with >> ftp/curl, which silently continues to link to base openssl if you leave >> its GSSAPI option set to the default GSSAPI_BASE. Choosing one of the >> other options fixes that problem. >> > > Actually I ran into that problem (or a similar), but with different > ports and couldn't work out how to nuke it.. so to work around just > disabled linking GSSAPI and that seemed to cure the issue. After looking at the problem for a bit, the first thing I tried was GSSAPI_NONE, since that is a feature that I did not need. I subsequently verified the other non-default GSSAPI settings also worked and filed a PR with a patch to fix curl's sanity check to catch the conflicting settings. >> There were a couple of other ports that I found in the set that I build >> that didn't handle WITH_OPENSSL_PORT=yes, but they were easy to fix and >> I filed PRs with patches for them. The last time I looked, there was >> only one port that set WITH_OPENSSL_BASE=yes in its Makefile, and that >> is not a port that I use. >> > > WITH_OPENSSL_PORT=yes > > worked for me with all except openldap - which was one of the ports that > I needed to disable GSSAPI on. Makes sense. I didn't stumble across that one since I don't use ldap here. >> Of all the binaries and shared libraries installed by my set of >> packages, the only ones that still link to base openssl belong to >> ports-mgmt/pkg. Fixing that and avoiding the resulting chicken vs. egg >> problem would probably require bundling a private copy of openssl with >> pkg. >> >> There are still a number of things in base that use openssl, but in my >> case the only significant ones are ssh and fetch. In one of the replies >> in the thread that I started, someone mentioned that it could be a >> problem if a port uses libfetch because that shared library is linked to >> openssl from base, but none of the ports that I use appear to use >> libfetch. >> > > 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.