openssh: Update to 7.6p1

[danielluke (Daniel J. Luke)]

(for 7.4p1):
As per usual, a simple version bump works for me (but I did not test the +hpn or +gsskex variants - which usually need some attention).
(for 7.5p1):
Unfortunately, a simple version bump fails earlier now (launchd.patch for channels.c fails).
(for 7.6p1):
Simple version bump with fix to launchd.patch. No support for other variants.

[danielluke (Daniel J. Luke)]

simple version bump

[myrkraverk (Johann 'Myrkraverk' Oskarsson)]

There are at least two relevant CVEs so I'd like to bump up the priority.

​https://bugs.chromium.org/p/project-zero/issues/detail?id=1010

​https://bugs.chromium.org/p/project-zero/issues/detail?id=1009

[raimue (Rainer Müller)]

Replying to myrkraverk:

There are at least two relevant CVEs so I'd like to bump up the priority.

​https://bugs.chromium.org/p/project-zero/issues/detail?id=1010

Bug against sshd.

​https://bugs.chromium.org/p/project-zero/issues/detail?id=1009

Bug against ssh-agent.

Both of these binaries are usually the version provided by Apple, unless you explicitly exposed the MacPorts version by changing your system configuration. Upgrading MacPorts will not remove the attack vector.

[myrkraverk (Johann 'Myrkraverk' Oskarsson)]

Replying to raimue:

Both of these binaries are usually the version provided by Apple, unless you explicitly exposed the MacPorts version by changing your system configuration. Upgrading MacPorts will not remove the attack vector.

Ok, so purely installing MacPorts is not sufficient, but can I still use the provided ssh-agent by changing my system config to use it? Or is it incompatible somehow?

Right now I'm less concerned about the SSH daemon than the agent.

[Ionic (Mihai Moldovan)]

You could, but it doesn't make a whole lot of sense. In theory, the MacPorts ssh-agent binary should be compatible to the Apple-provided one, although I've had reports of it crashing for users with me being unable to reproduce it.

The gist is that switching to the MacPorts-provided ssh-agent binary as your system daemon only really makes sense if you want to use key types that are not supported by the system version, especially on older systems, as Apple is generally not updating software they ship within a release (short of bugfixes.)

I can't promise an update soonishly, will probably take me few weeks.

[Schamschula (Marius Schamschula)]

I'm more concerned about missing security fixes, than I am about the latest key types. Apple's sshd for Sierra currently is 7.3p1 - libressl 2.4.1, but on my El Capitan machine it is only 6.9p1 - libressl 2.1.8.

For the same reason I don't run the OS openssh under FreeBSD either (currently OpenSSH_7.2p2, OpenSSL 1.0.2j-freebsd vs. OpenSSH_7.4p1, OpenSSL 1.0.2k from the openssh-portable package).

[danielluke (Daniel J. Luke)]

7.5p1 is out now.

Unfortunately, a simple version bump fails earlier now (launchd.patch for channels.c fails). I don't know when I'll have time to look at it, but I'll try and get the default build working if no one beats me to it).

[ryandesign (Ryan Carsten Schmidt)]

7.6p1 is now out.

[Schamschula (Marius Schamschula)]

Beside th ewabove mention issue with the launchd patch, the gsskex variant keeps causing the update hang ups. I looks like this patch is no longer being updated upstream (Debian), and the OpenBSD folks never agreed to integrate GSSAPI support into the mainstream package (potential security issues). This means a lot of patching of the patch file...

[Schamschula (Marius Schamschula)]

Portfile for 7.6p1 only default variant fixed

[Ionic (Mihai Moldovan)]

Please be patient. Openssh is next on my list. I'll work on it soon!

[danielluke (Daniel J. Luke)]

I think we should consider splitting this port into a 'vanilla' openssh (minimal patching) and a version with the problematic patches that takes longer to update.

[Schamschula (Marius Schamschula)]

Replying to Ionic:

Please be patient. Openssh is next on my list. I'll work on it soon!

Good to hear! +1

[Schamschula (Marius Schamschula)]

Replying to danielluke:

I think we should consider splitting this port into a 'vanilla' openssh (minimal patching) and a version with the problematic patches that takes longer to update.

+1

[Schamschula (Marius Schamschula)]

Also, please consider #54762 - merging ssh-copy-id as a subport of openssh.

[H3ik0]

Replying to Schamschula:

Replying to danielluke:

I think we should consider splitting this port into a 'vanilla' openssh (minimal patching) and a version with the problematic patches that takes longer to update.

+1

+1

[Ionic (Mihai Moldovan)]

Well, at least I started working on it. So far have managed to update all patches but the huge GSSKEX one. Will try to get this into shape tomorrow, do some other cleanups and finally make the newest version available.

[Mihai Moldovan <ionic@…>]

In cd1cc0653a300ac6714501bdb64bdedabddb8d75/macports-ports:

net/{openssh,ssh-copy-id}: update to 7.6p1.

Fixes: #53108
Fixes: #54762

Changes:

• Rebase patches.
• Update to newer HPN patchset version. Based upon the 7.5p1 version 13 patch. Preliminary, a newer version will be backported once available upstream.
• Merge in ssh-copy-id as a subport and delete the standalone port.
• Provide maintainer helpers for quilt patch management. Not used within the Portfile itself.
• Remove unreachable or outdated mirrors.
• Add new size parameter to checksums.

[Ionic (Mihai Moldovan)]

Replying to Schamschula:

Beside the above mentioned issue with the launchd patch

Incidentally, that patch is a bit less intrusive now since some functionality has been merged upstream.

the gsskex variant keeps causing the update hang ups. I looks like this patch is no longer being updated upstream (Debian)

How did you come to this conclusion? Both Debian and RedHat/Fedora still very much maintain this patch, though RH/F has been slower to update to 7.6p1 this time around. Not a real problem, since Debian had a 7.6p1 version available and most of the changes between 7.5p1 and 7.6p1 relate to dropping SSH1 support.

and the OpenBSD folks never agreed to integrate GSSAPI support into the mainstream package (potential security issues).

Yes, but it's still a default patch in a lot of distributions and its security track record is pretty good. Most CVEs revolved around RH-specific additions.

This means a lot of patching of the patch file...

Well, yeah, it's always a pain to update this stuff...