OpenSSL Security Advisory [11 Jun 2015]

[Don Lewis]

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.