openssh: Update to 10.0p2

[artkiver (グレェ)]

I'm working on updating the Portfile for this, but figured I should document that since I have some other timing critical obligations and probably won't finish for several more hours.

[artkiver (グレェ)]

preliminary Portfile for OpenSSH 10.0p1

[artkiver (グレェ)]

Updated agent.patch for ssh-agent.c changes that occurred between OpenSSH 9.9p2 and 10.0p1

[artkiver (グレェ)]

I've attached my preliminary Portfile for OpenSSH 10.0p1 and an updated agent.patch.

I'm currently working on updating patch-sshd-session.c-apple-sandbox-named-external.diff for changes that occurred in sshd-session.c between 9.9p2 and 10.0p1.

Though, if someone else beats me to it, add that attachment here and peace be with you! (and thanks for the help!)

I may not finish that for several more hours given some other obligations I have at the moment.

[artkiver (グレェ)]

preliminary updated patch for sshd-session.c

[artkiver (グレェ)]

log of build failure from port -v install

[artkiver (グレェ)]

main.log of failed build

[artkiver (グレェ)]

So, the changed patches I attached, it looks as if maybe sshd-session.c changed a bit more and it's failing to build even though the modified patch applied "cleanly"?

I need to step AFK for several hours, but hopefully can sort this out later.

Others are welcome to take a gander and maybe can fix whatever deficiencies I encountered? That would be awesome, but I won't be holding my breath.

[artkiver (グレェ)]

a "working" Portfile for OpenSSH 10.0p1 [though calling it 10.0p2 for "reasons"] but omits the two patches for ssh-agent.c and sshd-session.c due to build errors.

[artkiver (グレェ)]

OK, so in an effort to simplify (knowing that I recently tested an OpenSSH snapshot on April 7th, which built locally from the tarball) I modified the Portfile to remove the patches to ssh-agent.c and sshd-session.c which I refactored, and that does indeed facilitate OpenSSH building without errors.

e.g.

% ssh -V
OpenSSH_10.0p2, LibreSSL 4.0.0

Refactoring the modified patches seems to be the next step, but I may be a little out of my depth here and am probably going to ask for help on the MacPorts Dev list next.

But in a pinch, that Portfile could be submitted as a Pull Request if folks are impatient.

As an aside, there's a slight inconsistency in the OpenSSH 10.0 portable release nomenclature. The tarball is 10.0p1

However, as you can see above from ssh -V output as well as the OpenSSH 10.0 release notes, it mentions 10.0p2.

djm@ brought attention to this discrepancy on the OpenSSH UNIX dev mailing list:

​https://marc.info/?l=openssh-unix-dev&m=174424154612274&w=2

So, if that is a source of additional confusion, please don't pay it much mind.

[ryandesign (Ryan Carsten Schmidt)]

Based on the above mailing list post, the port version should be 10.0p2 not 10.0p1.

[artkiver (グレェ)]

Yeah, but the tarball on their mirrors is still named 10.0p1; so if we change the version to be 10.0p2 in the Portfile then

% port -v fetch

Will basically stall out, since there aren't any tarballs that correspond to the version 10.0p2 when I tried. Maybe there's another way to handle that?

Replying to ryandesign:

Based on the above mailing list post, the port version should be 10.0p2 not 10.0p1.

[jmroot (Joshua Root)]

If the distinction is important, you can change distname.

[artkiver (グレェ)]

modified Portfile to keep version consistent with upstream OpenSSH UNIX dev email message with distname suggestion from jmroot

[artkiver (グレェ)]

Thanks for the suggestion!

Replying to jmroot:

If the distinction is important, you can change distname.

[artkiver (グレェ)]

Perhaps against my better judgement, I am contemplating submitting a PR more or less as it currently stands. It's been about a week since OpenSSH 10.0p2 was released and while I've asked for help in fixing the patches to ssh-agent.c and sshd-session.c, nothing has materialized thus far.

Meanwhile, getting 10.0p2 will fix some other bugs documented but may additionally find some users in the wood work who notice if the MacPorts' specific functionality for ssh-agent and sshd-session impact them and will help contribute fixes? (I've observed similar events in MacPorts' past with OpenSSH combing through old Trac issues)

Alternatively, maybe no one notices, in which case, maybe it would be good to observe that as well and question whether MacPorts' should be differing that significantly from upstream anyway? That seems less likely, but not outside of the realms of possibility.

[artkiver (グレェ)]

Portfile for OpenSSH 10.0p2 with some additional distname clean up and omitting the patches for ssh-agent.c and sshd-session.c

[artkiver (グレェ)]

In 32864ee50fbcb2746c33875e14619107277ea969/macports-ports (master):

openssh: update to 10.0p2

• closes: #72317

[fhgwright (Fred Wright)]

Some kind of patches for ssh-agent were clearly necessary, since it no longer works. I don't know about sshd-session.

The ssh-agent situation is tricky, because the port has never provided a means for actually running it, so most users are probably still running the Apple version, even while using the MacPorts openssh. But the Apple ssh-agent on older systems sometimes causes deprecation warnings (I'm not sure about actual failures), so running the more up-to-date version from the port is helpful; you just need to create your own LaunchAgent file (and disable Apple's).

I've done that here, and after upgrading the port (and logging out and in), ssh-add hangs, though ssh-agent is running according to ps. Rolling back to 9.9p2_1 fixes it.

Presumably the problem is that the upstream ssh-agent is incompatible with launchd, and the purpose of the patches was to fix that. It might be more maintainable to create a wrapper program that would properly launch the unmodified ssh-agent; I don't know.

[alcu (Alan Chu)]

Yeah I've been using the built-in Apple version of ssh-agent for many years with MacPorts probably like most people.

However, ssh-agent is working for me with 10.0p2 when I manually start it. For example, if I ssh into a machine with ForwardAgent=no, then want to start an ssh-agent once there, running "eval $(ssh-agent -s)" and subsequent ssh-add commands can add keys to the MacPorts ssh-agent.

I noticed the default /System/Library/LaunchAgents/com.openssh.ssh-agent.plist file has the "-l" option in the ProgramArguments, and the agent.patch that we removed with 10.0p2 added that option. If you're using a plist file based on that, maybe try taking out that "-l" option?

[F30 (Felix Dreissig)]

Replying to alcu:

I noticed the default /System/Library/LaunchAgents/com.openssh.ssh-agent.plist file has the "-l" option in the ProgramArguments, and the agent.patch that we removed with 10.0p2 added that option. If you're using a plist file based on that, maybe try taking out that "-l" option?

Just taking it out won't cut it, because -l is what enables the agent to work with launchd socket activation. Apple's launchd job relies on that (by using SecureSocketWithKey), so most customized jobs do as well. It's certainly possible to do it without socket activation, but then you have to deal with the env variables yourself and I don't know enough about launchd for that.

I'm apparently one of the few people who actually used the SSH agent from MacPorts, because of its compatibility with FIDO2 keys (port variant fido2). Dropping the patch broke that.

I now revisited using Apple's OpenSSH with FIDO2, which should be possible by providing a custom SSH_SK_PROVIDER. The script from ​https://gist.github.com/BertanT/9d222da115ca2d1274ef34735c4260cf was helpful and I did some hacky adjustments to make it use libraries from MacPorts instead of Homebrew. The basic idea is to build a standalone dylib for FIDO2 support and then provide that as SSH_SK_PROVIDER.