[MacPorts] #67442: openssh @9.3p1_0+kerberos5+xauth not compatible with openssl @3_10--segmentation fault
MacPorts
noreply at macports.org
Fri May 19 00:25:13 UTC 2023
#67442: openssh @9.3p1_0+kerberos5+xauth not compatible with openssl @3_10--
segmentation fault
-------------------------+----------------------
Reporter: EJFielding | Owner: artkiver
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.8.1
Resolution: | Keywords:
Port: openssh |
-------------------------+----------------------
Comment (by artkiver):
Thanks for the update!
In looking at your earlier output a little more carefully, I also noticed
this:
/opt/local/lib/libgssapi_krb5.2.2.dylib (compatibility version
2.0.0, current version 2.2.0)
Which, isn't reflected in your most recent otool output.
The GSSAPI/gsskex variant was deprecated a while ago (9.0p1 e.g.
https://trac.macports.org/ticket/64982 ).
I also can't claim to have thoroughly tested the xauth variant, so while I
might suggest removing that with -xauth, your mention that it is
functioning OK on M1 but not on an Intel Mac has me scratching my head a
bit. I do still have some Intel Macs, but in storage and running rather
old macOS variants (I don't think they're even capable of running Ventura
without using 3rd party tools such as https://dortania.github.io/OpenCore-
Legacy-Patcher/).
LibreSSL has been used as the default macOS TLS library since at least
High Sierra macOS 10.13 released circa 2017 if not earlier. However, I am
reticent to recommend simply removing OpenSSL and installing LibreSSL for
a MacPorts user as a fix all, because some ports have not been updated to
accomodate the change gracefully. It has been a long and involved process,
not just for MacPorts developers (who are, near as I can discern, myself
included, all volunteers) but for other projects. FreeBSD has relatively
simple toggles to rebuild /usr/src with LibreSSL, OpenBSD (obviously)
defaulted to LibreSSL before any other OS, but some projects such as
HardenBSD which had migrated to LibreSSL, eventually undid that due to
challenges (though, AFAIK HardenBSD only has one "full time" developer and
he isn't particularly well funded so that may not be a great example).
e.g. https://trac.macports.org/ticket/66740 is one ticket highlighting
some similar challenges, though at least personally on some of my systems
I have found that LibreSSL and OpenSSL can peacefully coexist, that is
going to be pretty contingent upon what other dependencies and their TLS
libraries may be.
Some things (rpki-client for example) have a bit more robust handling for
either TLS library beyond the dylib and will attempt to determine which
library is already installed and work with that and otherwise default to
(at least in that instance, installing libressl as needed).
It is probably a bit of my bias showing, but since Apple already started
shipping LibreSSL years ago and increasingly more projects have adapted
compatibility with it where it wasn't as easy of a "drop in replacement"
as maybe intended, but my hope is to continue to adapt software within
MacPorts to be happy with LibreSSL.
But, I am a volunteer and have a LOT of other things on my plate.
Tomorrow it's possible I can pick up one of my older Intel based Macs from
my storage unit and attempt to do some more thorough testing to see if I
can replicate the segfault you have reported. However, I am already booked
to work Saturday and Sunday, have at least one other obligation on Monday
and am doing my damndest to try to fit in some time to apply to a job
requisition which is hopefully still open as I am a far cry from working a
normal "40 hour work week" am thousands of dollars in debt, and sleeping
in a car, which is a hardship to understate it.
So, when I state that "I won't be able to do much" that is unpacking that
a little bit, particularly as, and I am doing my best to phrase this as
delicately as possible, but if you have never heard of LibreSSL until my
reply, you're fundamentally (2023-2014[when LibreSSL was originally
released] = 9 years behind OpenBSD's complete open source release
announcement of the LibreSSL project and there's only so much advocacy I
can do for libre/free open source software projects when I myself am a
volunteer).
Rest assured, I have dragged older code kicking and screaming into the
future than this, but even in those instances it was a laborious and time
consuming process and more often than not done for free, or under the
auspices of registered 501c3 non-profit organizations who, when they would
invoice attorneys for my time would charge say, Fortune 25 (e.g. Alphabet
Inc./Google) $300/hour for my time, but I was *lucky* if they paid me
$15-$30/hour for my troubles out of that. Meanwhile, MacPorts, as far as I
know, has even less funding than that and I have seen precisely nothing
other than mutual good will from fellow MacPorts contributors, so it's
been an endeavor in which I am happy to continue to co-create with other
seemingly good natured folks.
Having written as much, one of the Trac tickets I recently closed was 9
years old too. So, if things progress slightly slower than desireable,
there's only so much we can do collectively; particularly as at the
moment: we are still shipping newer SSH and TLS libraries than Apple is
with what was it, trillions of dollars in market valuation? I think we
(humble brag) do a fair bit better than Homebrew with supporting MUCH
older versions of OS X, to say nothing of Fink and other "also ran" port
managers for macOS/OS X. All of that, and I do not even have commit access
to the project! Yet, it has been my experience that those who do, have
been great about providing worthwhile perspective and modifications and
merging PRs quickly as merited.
My apologies for the TL;DR! I most certainly do want to help you, and
others who may be experiencing similar issues. At best, I may be able to
take a more in depth look at it tomorrow. Hopefully that is acceptable?
I am also more than willing to review patches if you have any to submit!
Moreover, I only added myself as "maintainer" (in conjunction with
"openmaintainer") because it was my experience that I had submitted
several PRs updating OpenSSH and it had been a "nomaintainer" MacPort and
it seemed that since I was presumably going to keep putting my time and
attention torwards at least doing my best to keep it as up to date with
the stock "vanilla" OpenSSH -portable branch, that I may as well make my
efforts slightly known. By no means do I claim to be as well versed as
djm, Niels Provos, Theo de Raadt or other key OpenSSH developers. I don't
think I have, to date, even submitted a patch to upstream that has been
merged, but maybe one will be necessary in this instance? Hard to say! I
did help get a modification merged into the aforemention rpki-client
somewhat recently, as well as some changes to the -portable branch of Got
(GameofTrees) both of which are also OpenBSD affiliated projects.
Hopefully that sheds a little more light into my immediate takeaway (which
I realize isn't too helpful with good advice) and my own work process and
constraints?
In summation:
If you *want* to try to uninstall OpenSSL and install LibreSSL *maybe*
that will function more harmoniously? But I would caution against that as
a first approach, mostly because you may have other dependencies, and you
also mentioned specific strife on an Intel Mac, but not an M1, so maybe it
is more archictecture dependent?
Similarly removing the -xauth variant might simplify things (I am
currently second guessing things at the moment, because I swear in the
past I saw that installed by default even though I never explicitly
specified it, and maybe I need to comb over the Portfile a bit more to
have a cleaner default)?
Alternatively, MacPorts actually has multiple OpenSSL ports, the dylib
attempts to be mindful of this too, but OpenSSL3
(https://ports.macports.org/port/openssl3/) would probably be recommended
as contrasted with openssl (which is more of a "catch all") or older
"openssl10" (https://ports.macports.org/port/openssl10/) or "openssl11"
(https://ports.macports.org/port/openssl11/) which are presumably there
more for compatibility with even older more brittle MacPorts? That is just
a guess though!
Oh, one more thing, you can run:
ssh -V
And it should display the OpenSSH version as well as what TLS library it
is linked against.
e.g. locally:
{{{
% ssh -V
OpenSSH_9.3p1, LibreSSL 3.7.2
}}}
However, if SSH is continuing to segfault, the otool methodology you are
using may be necessary.
In my experience with building OpenSSH against different TLS libraries,
typically I will get more verbose error messages that display information
related specifically to TLS libraries than segfaults, so your problem has
me scratching my head in some other ways, but I have already probably
written WAY TOO MUCH here and I don't want to cause reader fatigue, so
much as be thorough in my thought process and documenting some ideas to
try until I am in front of hardware that I can do more with hands on
(lamentably, due to my life circumstances and employer dynamics, I do not
currently have servers racked in datacenters or even VMs running vastly
variant OS variants to test with at the moment, and my relationship with
GitHub is about as far of a cry as "harmonious" as can be imagined and I
am vehemently opposed to using them, not just "oh codespaces could solve
this" ignorant, using anything tied to GitHub/M$/AWS and many other
vendors, to me personally, is antipode to the reality I am striving to co-
create and actually actively working against my ideals when I taint myself
with it, but that's scraping the surface of ethics and morality and I am
already way too deep in this reply).
Replying to [comment:4 EJFielding]:
> This is the library linkage on my Intel Mac:
> {{{
> otool -L /opt/local/bin/ssh
> /opt/local/bin/ssh:
> /usr/lib/libbsm.0.dylib (compatibility version 1.0.0, current
version 1.0.0)
> /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current
version 1.0.0)
> /opt/local/libexec/openssl3/lib/libcrypto.3.dylib (compatibility
version 3.0.0, current version 3.0.0)
> /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.13)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1319.100.3)
> }}}
> It is no longer linked to the kerberos library but still segFaults.
--
Ticket URL: <https://trac.macports.org/ticket/67442#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list