i don't see any discussion as to why this started, but it's not something we've done in the past, and it looks like a terrible idea for such a core/important package. it doesn't offer us anything useful over grabbing specific/known bug fixes, but has lots of downsides of pulling in changes that haven't been tested beyond local developer systems and OpenBSD. plus, the $PV is wrong: this is not 7.7p1, this is a random git version after the 7.7p1 release.
Discussion generally happens in #gentoo-base IRC channel if there wasn't a bug report in Gentoo yet. Would be nice to see you there again! What may have changed is that we are now picking upstream patches earlier than before in base system packages once we have validated the reported issue and were able to reproduce and confirm the fix instead of waiting for a new upstream release. But in general I still agree with you. That's why we take care that we only pick commits addressing known bugs in existing features affecting Gentoo users which we were able to reproduce. We don't pick commits adding new features or changing default behavior (exception proves the rule). Is there any specific patch in detail you are concerned of?
there are more than specific bug fixes in there: 2000_all_openssh-7.7p1_update-default-IPQoS-values.patch 2007_all_openssh-7.7p1_make-this-a-bit-more-portable.patch 2028_all_openssh-7.7p1_whitespace.patch there are changes in there that arguably aren't necessary or important: 2010_all_openssh-7.7p1_upstream_bug2719.patch 2016_all_openssh-7.7p1_implement-EMFILE-mitigation-for-ssh-agent.patch 2016_all_openssh-7.7p1-X509_implement-EMFILE-mitigation-for-ssh-agent.patch 2018_all_openssh-7.7p1_sync-fmt_scaled_c.patch 2019_all_openssh-7.7p1_emphasise-that-w-implicitly-sets-tunnel-ptp.patch 2025_all_openssh-7.7p1_prefer-argv0-to-ssh-when-re-executing-ssh-for-proxyjump.patch 2025_all_openssh-7.7p1-X509_prefer-argv0-to-ssh-when-re-executing-ssh-for-proxyjump.patch 2026_all_openssh-7.7p1_return-correct-exit-code-when-searching-for-and-hashing.patch 2027_all_openssh-7.7p1_make-ssh_remote_ipaddr-capable-of-being-called-after.patch 2029_all_openssh-7.7p1_adapt-to-extra-default-verbosity-from-ssh-keygen.patch the openssh ebuild should be tracking specific bugfixes rather than grabbing anything that looks interesting. regressions have been introduced before (if they didn't, we wouldn't be pulling in regression fixes), so the fact that it's been committed is not a perfect signal that it's OK to include.
Just FYI: This backported commit [https://github.com/openssh/openssh-portable/commit/5ee8448ad7c306f05a9f56769f95336a8269f37] breaks virtual machines in NAT mode on VMware Workstation. It's a VMware's BUG and really strange in my opinion. NOTHING WITH OPENSSH. Because vmnat do not recognise AF21/CS1 DSCP flags, it'll send back a RST packet (don't know why) immediately upon received any packet having either flags, and finally break all ssh connection. (This happens soon after authentication since IPQoS applies during channel establish) As this commit(V_7_7_P1-5-g5ee8448a) haven't been contained in any official releases and vmnat has few(?) users, it won't cause severe impact I think. You can reproduce this by `ssh -o IPQoS=af21` on any supported openssh for vmnat VMs.
