[MacPorts] #70319: openssh @9.8p1 broke some key types

[MacPorts]

#70319: openssh @9.8p1 broke some key types
------------------------+----------------------
  Reporter:  fhgwright  |      Owner:  artkiver
      Type:  defect     |     Status:  assigned
  Priority:  High       |  Milestone:
 Component:  ports      |    Version:  2.9.3
Resolution:             |   Keywords:
      Port:  openssh    |
------------------------+----------------------

Comment (by artkiver):

 > Are you expecting everyone doing a `port upgrade outdated` to look at
 the list of upgraded ports, visit their upstream websites, and view the
 upstream release notes, for every upgraded port?  Seriously??? That sort
 of "notice" isn't much better then "Beware of the Leopard" notice.  While
 referring to upstream release notes is OK in the context of "For more
 information see XXX", primary notification of upcoming breakage needs to
 be made directly by the ''port'' to its users.  Either that or just don't
 break things (a concept which seems to be lost on upstream).
 >
 > And the `port notes` mechanism isn't really adequate, since not only are
 unsolicited port notes only provided at install and upgrade time, but also
 notes from an upgrade tend to get buried in a forest of nearly pointless
 notes from every upgraded port that uses `port select`.

 I am not sure why you seem to be lashing out on this, let alone making
 spurious expectations/"putting words into my mouth" and making up things
 which I have never written nor said on the subject.

 I am not an OpenSSH developer. I am a volunteer.

 However, I certainly understand that OpenSSH, is not something which is
 unique to MacPorts.

 Albeit, I am biased.

 I am also an editor for undeadly.org, the OpenBSD journal and heck, I even
 published this story on the OpenSSH 9.7/9.7p1 release announcement:
 https://undeadly.org/cgi?action=article;sid=20240312065313. Every manpage
 and GitHub and BugZilla link, is something I personally wrote an a href
 tag for in that story because copy & paste is insufficient to capture all
 the pertinent nuances for the release notes in a format that is consistent
 with undeadly.org editorial styles. But again, there too, I am a
 volunteer. In over 20 years, no one has paid me a penny for any of my
 contributions to that site.

 I should note: I am also not an OpenBSD developer, even if most of the
 MacPorts on which I toil, are OpenBSD related. That's more a matter of
 personal interest. As an aside, I have given a brief once over creating a
 MacPort for OpenBGPD, but it didn't seem to build cleanly from source on
 macOS, not to mention given that macOS requires /usr/bin/caffeinate to be
 invoked to make it not sleep, it doesn't really seem as if it is an ideal
 OS target for core routing protocols, but maybe someday I will tickle that
 itch again.

 Regardless, MacPorts does not exist in a vacuum.

 I wouldn't expect that anyone using MacPorts' OpenSSH would be oblivious
 that OpenSSH itself is an upstream project? Do you think that Other Linux
 distros shipping OpenSSH 9.8p1 are splitting hairs over DSA's removal as a
 compile time default? I am guessing, from
 https://repology.org/project/openssh/versions that since only 92 even
 appear to be at 9.8 out of 768, that the vast majority of Linux distros
 and their packaging systems, have far bigger problems to worry about; or
 they're like RHEL which do extremely confusing things such as backporting
 patches to old version numbers, which I think does everyone a disservice.

 If you think it is incumbent upon MacPorts and its maintainers to make its
 users aware of every nuance that an upstream project is making, rather
 than focusing on keeping -CURRENT with upstream, I concur that I don't
 think "port notes" or whatever is going to be adequate, because that isn't
 what MacPorts has ever been about AFAIK. We don't have anything like the
 MacPorts' Journal, documenting salient improvements, and far be it from
 any capitalistic advertising laden blogs such as Apple Insider or
 MacRumors to pay attention to MacPorts either, apparently. Not that I
 would expect anything less. There are reasons I contribute to MacPorts and
 not Homebrew after all, not the least of which is Homebrew defaults to
 spyware, MacPorts requires users opt-in to installing mpstats if they want
 to report analytics. I think its wise to avoid surveillance capitalism, by
 default.

 But then, I guess since I was blessed to work with jkh (who seems to be
 conspicuously absent from MacPorts since around 2016? I have my theories
 as to why but I haven't seen him in person since the FreeBSD 20 year
 anniversary party to confirm my suspicions) at iXSystems when we were both
 there circa 2013 and got to know him personally, I never really saw
 MacPorts/DarwinPorts as anything more than something like a BSD /usr/ports
 as might be found in OpenBSD or FreeBSD, etc.? Those typically, also do
 their best to keep -CURRENT with upstream, but don't make a point of
 subsuming responsibility from the upstream projects as far as their
 overarching development goals or objectives. I don't think any BSD
 /usr/ports user would expect their respective port maintainers to keep
 ports users abreast of everything upstream changes either, so much as
 salient release tracking? I don't think most MacPorts users would consider
 that part of maintainers' responsibilities either?

 If it makes you feel any better, it is not as if I am resting on my
 laurels regarding OpenSSH's development with regards to MacPorts.

 For example, I filed https://bugzilla.mindrot.org/show_bug.cgi?id=3697
 which djm@ rectified, shortly afterwards. I was testing that OpenSSH
 snapshot, knowing that this commit had occurred: https://marc.info/?l
 =openbsd-cvs&m=171590564107097&w=2

 Thankfully, that build issue was rectified before the 9.8p1 release, even
 if the main things focused on by 9.8p1 were security related, there was at
 least one other bug I helped identify and djm@ remediated which were
 pertinent to MacPorts/macOS builds and I like to think I helped make a
 little bit of a difference in avoiding more potential delays that might
 have been encountered had I not been testing snapshots and such?

 If you want more from me, you probably haven't been paying attention to
 how dire my living circumstances already are, which I have documented in
 other Trac tickets. I make a best effort but am barely scraping by as it
 is. (TL;DR: I am thousands in debt, homeless/sleep in my car and even
 replying to this is thanks to some library WiFi).

 At least personally, I don't think that it is particularly wise to keep
 the DSA cipher, already deprecated, with future, publicly documented
 upstream plans to have support removed entirely next year, on any form of
 life support by MacPorts. I would question, without having done the due
 diligence, whether potentially impacted systems might not be better off,
 in every appreciable manner, by simply running ssh-keygen again with a
 supported key? I believe ssh-keygen currently defaults to ed25519?

 I do remember (and I even filed a bug with Apple back when it was still
 Radar not FeedBack, which Apple closed as a duplicate years after it was
 opened, not that Apple has ever publicly acknowledged me for any bug I
 have filed with them [and yes, I filed FeedBack for the vulnerability
 remediated by 9.8p1 just to raise their awareness internally in hopes
 maybe they'll ship something saner with Sequoia let alone remunerated me
 through their bug bounty program]) that Apple was not supporting any
 elliptic curve keys, so maybe there is some weird edge case which would
 run afoul of whatever backasswards things Apple's asinine attorneys were
 deluded about even years after Dragos Ruiu had publicly cited how whatever
 US Navy patents on such things had long since expired, but I don't seem to
 have access to the old bug reports I filed with Apple rdar to check those
 notes at the moment, doubtlessly I could probably dig up the citations
 again on some BugTraq archive or wherever.

 Regardless, that ship sailed.

 Even Apple's OpenSSH and ssh-keygen do support elliptic curves currently,
 and MacPorts' users benefit from more current versions of OpenSSH than
 Apple ships anyway, so I am kind of confused why there would be much of a
 need for MacPorts' OpenSSH to support DSA moving forward; but as
 previously mentioned:

 While I personally am not going to submit such a PR, if someone really
 thinks OpenSSH DSA key support is vital and wants to submit a PR with a
 variant, so long as it is not a default variant, maybe that will help some
 folks out and more power to them!

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