Requesting LibreSSL

[NotHere]

OpenBSD has released libressl-2.0.0 for Linux, Solaris, Mac OS X and FreeBSD. Would like to use it in place of OpenSSL.

How could this be done?

​http://undeadly.org/cgi?action=article&sid=20140711201841&mode=flat

[ryandesign (Ryan Carsten Schmidt)]

Well, creating a port is hopefully straightforward. Documentation is in our guide.

Using it in place of openssl is more involved. If libressl is indeed designed to be a drop-in replacement for openssl, and uses the same library version number, then all ports that depend on openssl could be modified from port:-style dependencies to path:-style dependencies. If they are not library version compatible, however, then any port that uses openssl and could optionally use libressl would have to have variants added, and openssl and libressl would have to make sure that they don't try to install files to the same locations.

[cooljeanius (Eric Gallager)]

Cc Me!

[petrrr]

Cc Me!

[jerryyhom]

Cc Me!

[jerryyhom]

Replying to ryandesign@…:

Well, creating a port is hopefully straightforward. Documentation is in our guide.

It is straightforward. I created a basic portfile and successfully rebuilt a port which depends on it.

Using it in place of openssl is more involved. If libressl is indeed designed to be a drop-in replacement for openssl, and uses the same library version number, then all ports that depend on openssl could be modified from port:-style dependencies to path:-style dependencies.

Could someone enlighten me as to what path:-style dependencies mean? (Silly me, I found the Guide section on dependencies.) I do wonder how the MacPorts devs feel about fitting in libressl, such as with port:-style dependencies. I read of a gentoo dev who made a virtual port which depended on libressl to avoid any disruptions; though that seems to me like a short term solution.

If they are not library version compatible, however, then any port that uses openssl and could optionally use libressl would have to have variants added, and openssl and libressl would have to make sure that they don't try to install files to the same locations.

According to libressl, it is designed to be a drop-in replacement, so ports should not use openssl *and* libressl, or even optionally as variants. As a replacement, libressl does install very nearly the same set of headers/libraries.

[jerryyhom]

I am attaching the portfile I created for libressl. I also have a few patches. As a drop-in replacement for openssl, installing libressl requires deactivating openssl, plus dependent ports need rebuilding against libressl's libraries via updating their Portfile. Comments appreciated.

[mf2k (Frank Schima)]

Thanks!

[pixilla (Bradley Giesbrecht)]

Cc Me!

[rmerpes]

Cc Me!

[jerryyhom]

In the attached files, Portfile.2 is identical to Portfile (forgot to check the overwrite box) and could be removed, if possible. The patches for Makefile and tls_internal are unchanged and necessary.

[jeremyhu (Jeremy Huddleston Sequoia)]

+universal is failing.

The i386 build attempts to compile aes-macosx-x86_64.s ... need to figure that out.

/usr/bin/clang -pipe -O0 -g3 -arch i386 -Wall -std=gnu99 -fno-strict-aliasing -fno-strict-overflow -D_FORTIFY_SOURCE=2 -fstack-protector-strong -c aes/aes-macosx-x86_64.s  -fno-common -DPIC -o aes/.libs/aes-macosx-x86_64.o

[jeremyhu (Jeremy Huddleston Sequoia)]

r139224 r139225

[jeremyhu (Jeremy Huddleston Sequoia)]

Gonna rebuild a bunch of ports and then revbump libressl to set openssldir, etc that I missed.

[jeremyhu (Jeremy Huddleston Sequoia)]

Updated dependents in r139229

[jeremyhu (Jeremy Huddleston Sequoia)]

r139230 fixes the path to cert.pem