[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-
maintainer.
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
(https://github.com/macports/macports-ports/pull/16977).
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
year.
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