[MacPorts] #67539: openssh @9.3p1_1 Nearly all client programs crash with Segmentation Fault.

[MacPorts]

#67539: openssh @9.3p1_1 Nearly all client programs crash with Segmentation Fault.
------------------------+----------------------
  Reporter:  snowflake  |      Owner:  artkiver
      Type:  defect     |     Status:  assigned
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.8.99
Resolution:             |   Keywords:
      Port:  openssh    |
------------------------+----------------------

Comment (by artkiver):

 I share your concerns.

 Admittedly, I am not sure if it is quite so straight forward to require
 MacPorts' clang?

 Currently the Portfile already has the following:

 {{{
  compiler.blacklist-append   *gcc*     cc {clang < 421}
 }}}

 Meanwhile, reading https://trac.macports.org/wiki/UsingTheRightCompiler we
 could potentially use the compiler.whitelist to specify preferred
 compilers; however, piru's stipulation that the following versions of
 XCode are impacted, I haven't been able to replicate locally (presumably
 because this is only for Intel systems running Ventura? Whereas the only
 Intel systems I have at present are too old to be running that officially,
 and are using llvm16 or llvm-devel from MacPorts).

 So the thought of blacklisting:


 {{{
 Xcode 14.3
 Build version 14E222b
 Xcode 14.3.1
 Build version 14E300c
 }}}


 Wouldn't necessarily be a correct fix for Apple Silicon users either as
 far as I can discern?

 Moreover, those versions do not seem to correspond to the sorts of
 parameters expected by https://github.com/macports/macports-
 base/blob/master/src/port1.0/portconfigure.tcl#L758 so the Xcode and Build
 versions, would need to be related to something which would be correctly
 parsed there first before I can meaningfully update the Portfile by
 expanding the blacklist.

 The code snippet @piru provided as a heuristic makes me wonder if it would
 be able to utilize it similarly inspired by something I stumbled across
 here when trying to research others encountering issues which required
 compiler blacklisting:
 https://lists.macports.org/pipermail/macports-users/2017-March/043018.html
 (and the corresponding commit referenced therein:
 https://github.com/macports/macports-
 ports/commit/6fb35a1f2843454f08ef5027dfe0e3db59016d99 )

 My apologies as I have not had much time to look into this more deeply.
 Moreover, I do not have sufficient resources to have even been able to
 replicate the issue, so attempting to test a potential fix from my vantage
 is somewhat problematic.

 I've asked for an extra set of eyeballs on IRC as well, but it doesn't
 seem as if any human is presently active on there other than, so for the
 last half hour since my inquiry, it's just been mplog messages.

 I'll forward this to the email list next and see if others have
 suggestions for how to move forward. There's a reason this Portfile is
 "openmaintainer" after all, I mostly just put myself down as I had been
 submitting PRs to update OpenSSH in alignment with upstream releases since
 8.9p1 and had noticed no one else was really doing much to keep it spruced
 up.

 In the interim, it seems as if the users impacted by this are a limited
 subset, and thankfully there are known workarounds such as using
 llvm/clang from MacPorts, though I concur: it would be preferable to have
 such things in the Portfile.

 If anyone who has a system which is impacted by this, can try testing some
 of the suggestions and submitting a PR, that would be more than welcome.


 Replying to [comment:40 danielluke]:
 > If the 'best' version of fixing this is going to take some time, could
 we please require macports clang so that people with affected systems can
 get a working port in the interim?

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