Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 658488 - net-misc/openssh-7.7_p1 should not be tracking upstream git
Summary: net-misc/openssh-7.7_p1 should not be tracking upstream git
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Thomas Deutschmann
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-19 14:51 UTC by SpanKY
Modified: 2018-08-24 21:50 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2018-06-19 14:51:30 UTC
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.
Comment 1 Thomas Deutschmann gentoo-dev Security 2018-06-19 15:45:02 UTC
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?
Comment 2 SpanKY gentoo-dev 2018-06-19 16:15:06 UTC
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.
Comment 3 Xiami 2018-06-21 05:50:32 UTC
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.