what to do when base openssl isn't suitable

Matthew Seaman matthew at FreeBSD.org
Sat Jul 2 14:12:44 UTC 2016

On 02/07/2016 11:45, Gerard Seibert wrote:
> I have to admit that this whole discussion has gotten me confused. I
> use "openssl" from ports, always have and probably always will. I use
> to use the now apparently depreciate statement in the /etc/make.conf
> file:
> From what I am reading, I would replace that line with the following
> statement:
> DEFAULT_VERSIONS+= ssl=openssl
> to force the use of the "ports" version of "openssl". Is that correct,
> or is my interpretation of this incorrect?

These would work for an individual user to customize things via their
/etc/make.conf file, and have the effect of causing all OpenSSL using
ports to link against the ports version of OpenSSL.

Except that neither of these constructs is valid for adding to a port's
own Makefile -- and indeed, as you say, WITH_OPENSSL_PORT is no longer
useable anywhere.

USES=ssl unfortunately does not offer any argument to allow the port
maintainer to limit what SSL library the user can select.  There are two
possible answers to this problem

  1) Test the value of eg. OPENSSL_PORT after USES=ssl has been
     processed and error out if the user has chosen something
     incompatible with this port.

  2) Make this port, and in fact all ports, compatible with as many as
     possible of the different variations on SSL libraries that the
     ports supports[*].

While (1) is superficially attractive, it basically means that your port
is going to fragile in the face of changes to whichever SSL library is
chosen: something that is likely to happen with different versions of
FreeBSD or based on revealed security problems with these libraries.
Not recommended.

Essentially, you will need to be able to do (2) -- compile successfully
against a number of different SSL library implementations.  This is
clearly much harder to do than (1), given that software consumers of SSL
libraries will all have their own ideas about how to configure and link
themselves, but on the whole there will be several groups of relatively
similar solutions, likely one of which will be relevant and fairly easy
to copy and adapt to the needs of a specific port.

A lot of this work has already been done, and documented -- largely as a
result of the desire to use LibreSSL as a generic replacement for
OpenSSL.  See Bernard Spil's wiki pages here:


There is a plan afoot to make all ported software only use SSL libraries
from the ports, and reserve the base OpenSSL library as private to base
system software.  This will make SSL support in ports substantially
easier, but it not here yet.



[*] which is currently base-OpenSSL, ports-OpenSSL, LibreSSL and
maybe... a bunch of other contenders like GnuTLS, PolarSSL, WolfSSL.
You've a reasonable assurance of success with the first three, but the
rest are less commonly used, or have significant differences in their
APIs, and more importantly, haven't had the work put in to make them
generically portable[+].

[+] Also there's a question over whether these SSL libraries will be up
to standard with the latest security ideas, such as obsoleting SSLv2,
SSLv3 and TLSv1.0 in favour of TLSv1.1 or above.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20160702/bfe294ab/attachment.sig>

More information about the freebsd-ports mailing list