On Sun, May 21, 2017 at 09:24:50PM -0500, Ryan Schmidt wrote:
On May 21, 2017, at 21:23, Zero King <l...@macports.org> wrote: On Sun, May 21, 2017 at 09:14:10PM -0500, Ryan Schmidt wrote:Why does this https variant default to libressl (while allowing openssl), when other ports default to openssl (while allowing libressl)? libressl is *not* a drop-in replacement for openssl, in that ports have to be recompiled to use a different ssl library. By defaulting to libressl here, you guarantee that users who install this port with the https variant first will get libressl, and if they then install any other port that depends on *ssl, the binaries they receive will be broken and will need to be recompiled from source.Note that this variant depends on libtls.dylib not libssl.dylib and only libressl(-devel) provides it. I have a libtls[1] port for this but I'm not sure if it's ready for the official ports tree. [1] https://github.com/l2dy/macports-user-l2dy/blob/master/security/libtls/PortfileOh. So what's the plan? The libtls port gets added, libtls.dylib gets removed from the libressl port, and the libressl port then depends on the libtls port? And then openntpd also depends on libtls instead of libressl?
The libtls library, as shipped with LibreSSL 2.3.2 or later, is required to use the HTTPS constraint feature, though it is not required to use OpenNTPD.
libtls.dylib will not be removed from libressl* ports. OpenNTPD requires LibreSSL to use its HTTPS constraint feature and my libtls port is just a workaround. The plan is if @jeremyhu is willing to maintain libtls too it can be added to the ports tree and used by default in the variant. If not, the variant only works with LibreSSL. -- Best regards, Zero King Don't trust the From address.
smime.p7s
Description: S/MIME cryptographic signature
