[MacPorts] #54744: coexistence of libressl, libressl-devel, openssl, boringssl, etc.

MacPorts noreply at macports.org
Tue Dec 27 07:31:34 UTC 2022

#54744: coexistence of libressl, libressl-devel, openssl, boringssl, etc.
  Reporter:  ryandesign        |      Owner:  artkiver
      Type:  defect            |     Status:  assigned
  Priority:  Normal            |  Milestone:
 Component:  ports             |    Version:
Resolution:                    |   Keywords:
      Port:  libressl openssl  |

Comment (by artkiver):

 Replying to [comment:16 Zweihorn]:

 Thank you for the kind words, and you are most welcome; admittedly, I also
 would be remiss in not also thanking neverpanic for volunteering to be co-

 Regarding your inquiry as far as the differentiation between libressl and
 libressl-devel, it ''should'' be the case that libressl-devel follows
 releases described as Development from the LibreSSL project (currently
 3.7.0) though we can probably expect LibreSSL 3.7.1 (as a "stable"
 release, and thus better suited to the libressl MacPort than libressl-
 devel) at some point (indeed there have been hints of such things to
 address some issues on the LibreSSL mailing list), which will be merged
 into the MacPort whenever I see a release announcement and do local
 testing and submit a PR.

 Based on past release versions from the upstream project, we probably
 won't see 3.8.x LibreSSL variants until OpenBSD starts tagging their
 branches for version 7.3 of their OS release probably? That is just an
 educated guess on my part though, despite doing volunteer editing for
 undeadly.org, I am not an OpenBSD committer and more just an assiduous
 observer of its development and related projects.

 There was an instance where both libressl and libressl-devel were at
 3.6.1, mostly thanks to neverpanic's suggestion so as to iron out an issue
 where I had incorrectly submitted a PR for a non Development release which
 was merged for libressl-devel, but I think as things presently stand, it
 is consistent with the upstream project and hopefully moving forward we
 will endeavor to maintain that consistency!

 I've attempted to do a little bit of sprucing up of some other related
 ports as well e.g. there was a libevent patch with some upstream changes
 not yet in a versioned release that improved compatibility with LibreSSL
 which I tested and they were merged successfully
 (https://github.com/macports/macports-ports/pull/16681), though someone
 else submitted that PR. I submitted a PR for xar, which made it a bit more
 LibreSSL friendly by using the dynamic library which got merged as well

 Currently, I have one uncommitted PR for rpki-client
 (https://github.com/macports/macports-ports/pull/16987) because I am
 pretty sure there there must be a better way to modify the Portfile, but I
 figured submitting a PR was at least one method to try to get some other
 eyeballs on it. Essentially, rpki-client will function with LibreSSL
 without issues; however if referencing the dynamic library, it *can* use
 OpenSSL as the previous version Portfile defaults reference, but only if
 LibreTLS is also a dependency. There is doubtlessly a better way to handle
 that than my attempt, but I figured better to submit some attempt and get
 additional input than to ignore it completely? I have been contemplating
 other ways to handle that, but haven't had a lot of time to give it more
 attention with the holidays. Honestly, it would be easier to submit a
 Portfile which requires LibreSSL instead of the dynamic library in that
 instance, but I didn't want to upset previous rpki-client users who were
 probably already accustomed to the OpenSSL and LibreTLS dependencies by
 leaving them out in the cold entirely.

 There are probably other rough edges too which hopefully in time and with
 sufficient cooperation we can smooth out as well. As for me, I mostly
 started taking a took at at such things when a JWZ blogpost brought to my
 attention an issue with an old version of LibreSSL and Let's Encrypt last

 Thankfully, the version of macOS's LibreSSL has been updated with Ventura,
 though macOS versions prior to Ventura were shipping with a version of
 LibreSSL which was about four years old, so it seemed worthwhile to try to
 keep the MacPorts' version a little more up to date.

 As it currently stands, both libressl and libressl-devel are approximately
 9 months ahead of the version shipping with Ventura, and I imagine that
 disparity will probably continue just given the nature of the upstream
 projects' release cycles as well as the nebulous nature of the whims of
 Apple's attention to their CLI tools.

 It's certainly my intention to continue to focus time and attention on
 keeping the ports as current as seems possible and I am guessing
 neverpanic shares similar sentiments. Thank you for noticing!

 > Hi,
 > I just want to express my **sincere gratitude** to the ''new
 maintainer'' of both libressl and libressl-devel.
 > Lacking some open commitment from myself to help the former maintainers,
 I was dependig on just bumping myself my ''local port defintion'' for
 libressl for years, unfortunately. However, the current updates for
 libressl and libressl-devel in parallel look very promising.
 > I highly appreciate the curent reasonable approach to meet the LibreSSL
 upstream update cicle in an applicable way.
 > I would like to understand this approach as:
 >   * libressl at 3.6.x until the 3.8 or newer comes around (then itself
 switching to 3.7.x) or 3.6 becomes EOL
 >   * libressl-devel at 3.7.x until the new development 3.8 or newer
 version comes around
 > IMO this fits.
 > Last not least would like to express my **strong support for this
 port**. For certain reasons I am a long standing user of LibreSSL on all
 my Mac OS X / macOS platforms for years and will continue using it.
 > Thank you very much. Keep on the good work and prosper.

Ticket URL: <https://trac.macports.org/ticket/54744#comment:17>
MacPorts <https://www.macports.org/>
Ports system for macOS

More information about the macports-tickets mailing list