qpid-proton does not build wth LibreSSL

[janstary (Jan Starý)]

  "_DH_set0_pqg", referenced from:^M^M
      _pn_ssl_domain in openssl.c.o^M^M
  "_SSL_CTX_get_security_level", referenced from:^M^M
      _pn_ssl_domain in openssl.c.o^M^M
  "_SSL_CTX_set_security_level", referenced from:^M^M
      _pn_ssl_domain in openssl.c.o^M^M
      _pn_ssl_domain_set_peer_authentication in openssl.c.o^M^M

These seem to be specific to OpenSSL 1.1

[ryandesign (Ryan Carsten Schmidt)]

But it builds with MacPorts openssl, right? We don't have openssl 1.1 in MacPorts; we have 1.0.2o.

[janstary (Jan Starý)]

Thanks for th corrections, I take the version statement back. At any rate, it does not build with LibreSSL 2.5.5.

[janstary (Jan Starý)]

The libcrypto.dylib provided by LibreSSL 2.7.2 provides DH_set0_pqg(), and the SSL_CTX_{get,set}_security_level() is patched away with a trivial ifdef. ​https://github.com/macports/macports-ports/pull/1626

[pmetzger (Perry E. Metzger)]

The qpid-proton people don't seem to support LibreSSL so I don't see why this is a defect.

[janstary (Jan Starý)]

Right; we should also remove all the other openssl/libressl patches in all the other ports.

You do see why not even compiling is a defect, don't you. The fact that upstream does not say in red letters "WE SUPPORT LIBRESSL" does not mean a _porting_ project such as MP should ignore it. Most of upstream does not say "WE SUPPORT OPENSSL" either.

LibreSSL is the default SSL/TLS implementation in MacOS. Get over it already.

[raimue (Rainer Müller)]

It does not matter which default macOS uses, because openssl is the default in MacPorts. All ports are tested with it and binary packages are linked against openssl. Anybody chosing the libressl{,-devel} ports has to be aware they are using an unsupported configuration.

In cases such as this one, we can either switch the dependency to port:openssl to disallow using libressl or someone steps up and provides patches to fix the build.

The best solution would still be to have non-conflicting openssl and libressl ports that can be installed side-by-side, with variants in ports deciding which library should be linked. See #54744.

[janstary (Jan Starý)]

In this case, the maintainer specificaly decided to depend on port:openssl.

This ticket exists solely to document that the breakage with LibreSSL does exist. It fails the same with LibreSSL 2.7.2 (whcih is what we have in libressl-devel now).