# What's going on with openssh?

## curmudgeon

```

# emerge -p openssh

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U  ] net-misc/openssh-7.2_p2::gentoo [7.1_p1-r2::gentoo] USE="X hpn pie ssl -X509 -bindist -debug -kerberos -ldap -ldns -libedit (-libressl) -pam -sctp (-selinux) -skey -ssh1 -static" 0 KiB

Total: 1 package (1 upgrade), Size of downloads: 0 KiB

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) net-misc/openssh-7.2_p2::gentoo

 * openssh-7.2p2.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                   [ ok ]

 * openssh-7.2_p1-sctp.patch.xz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                           [ ok ]

 * Sorry, but this version does not yet support features

 * that you requested:   hpn

 * Please mask openssh-7.2_p2 for now and check back later:

 *  # echo '=net-misc/openssh-7.2_p2' >> /etc/portage/package.mask

 * ERROR: net-misc/openssh-7.2_p2::gentoo failed (setup phase):

 *   booooo

 * 

 * Call stack:

 *               ebuild.sh, line 133:  Called pkg_setup

 *   openssh-7.2_p2.ebuild, line  90:  Called die

 * The specific snippet of code:

 *              die "booooo"

 * 

 * If you need support, post the output of `emerge --info '=net-misc/openssh-7.2_p2::gentoo'`,

 * the complete build log and the output of `emerge -pqv '=net-misc/openssh-7.2_p2::gentoo'`.

 * The complete build log is located at '/var/log/portage/net-misc:openssh-7.2_p2:20160314-014135.log'.

 * For convenience, a symlink to the build log is located at '/var/tmp/portage/net-misc/openssh-7.2_p2/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/net-misc/openssh-7.2_p2/temp/die.env'.

 * Working directory: '/usr/lib64/python3.4/site-packages'

 * S: '/var/tmp/portage/net-misc/openssh-7.2_p2/work/openssh-7.2p2'

>>> Failed to emerge net-misc/openssh-7.2_p2, Log file:

>>>  '/var/log/portage/net-misc:openssh-7.2_p2:20160314-014135.log'

# diff /usr/portage/net-misc/openssh/openssh-7.1_p1-r2.ebuild /usr/portage/net-misc/openssh/openssh-7.2_p2.ebuild

1c1

< # Copyright 1999-2015 Gentoo Foundation

---

> # Copyright 1999-2016 Gentoo Foundation

5c5,6

< EAPI="4"

---

> EAPI="5"

> 

12,14c13,15

< HPN_PATCH="${PARCH}-hpnssh14v9.tar.xz"

< LDAP_PATCH="${PN}-lpk-6.8p1-0.3.14.patch.xz"

< X509_VER="8.6" X509_PATCH="${PN}-${PV//_/}+x509-${X509_VER}.diff.gz"

---

> #HPN_PATCH="${PARCH}-hpnssh14v10.tar.xz"

> LDAP_PATCH="${PN}-lpk-7.2p2-0.3.14.patch.xz"

> X509_VER="8.9" X509_PATCH="${PN}-${PV/_}+x509-${X509_VER}.diff.gz"

19c20

<       mirror://gentoo/${PN}-6.8_p1-sctp.patch.xz

---

>       mirror://gentoo/${PN}-7.2_p1-sctp.patch.xz

22d22

<               https://dev.gentoo.org/~polynomial-c/${HPN_PATCH}

31c31

< KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~arm-linux ~x86-linux"

---

> KEYWORDS="~alpha amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~arm-linux ~x86-linux"

124c124

<               epatch "${FILESDIR}"/${PN}-7.0_p1-sctp-x509-glue.patch

---

>               epatch "${FILESDIR}"/${PN}-7.2_p1-sctp-x509-glue.patch

127,129c127,128

<               epatch "${FILESDIR}"/${PN}-6.3_p1-x509-hpn14v2-glue.patch

<               epatch "${FILESDIR}"/${PN}-6.9_p1-x509-warnings.patch

<               save_version X509

---

>               #epatch "${FILESDIR}"/${PN}-7.1_p2-x509-hpn14v10-glue.patch

>               #save_version X509

135c134

<       epatch "${FILESDIR}"/${PN}-4.7_p1-GSSAPI-dns.patch #165444 integrated into gsskex

---

>       epatch "${FILESDIR}"/${PN}-7.2_p1-GSSAPI-dns.patch #165444 integrated into gsskex

137,139c136

<       # The X509 patchset fixes this independently.

<       use X509 || epatch "${FILESDIR}"/${PN}-6.8_p1-ssl-engine-configure.patch

<       epatch "${WORKDIR}"/${PN}-6.8_p1-sctp.patch

---

>       epatch "${WORKDIR}"/${PN}-7.2_p1-sctp.patch

202,203c199

<               # The X509 patch deletes this option entirely.

<               $(use X509 || use_with ssl openssl)

---

>               $(use_with ssl openssl)

```

Yes, indeed, the hpn patch is commented out in the new version (an important security update). Does anyone know why?

----------

## toralf

I'd like to know it too, but maybe for a different reason. I was always wondering why "hpn" was the default. Gentoo is about choice so an opt-in by the user is IMO the better way.

----------

## ct85711

well, chances are either that patch doesn't work anymore, or the source already has it applied.  You can always modify the ebuild, and try applying the patch and see if it works or not.  Who knows maybe you get lucky and find out the devs forgot to re-enable that patch for the update.  If the patch works, be sure to test it out first before opening a bug report about it.

----------

## tnt

and all of this happens in the "stable" tree...   :Crying or Very sad: 

----------

## lutel

Another crapy ebuild. Gentoo seriously needs some way to control quality of ebuilds. This bug is more than 3 days old and it is like that in stable portage.

----------

## mv

 *lutel wrote:*   

> Another crapy ebuild.

 

I don't see it this way: The feature does not (yet) work with current openssh. So there's the following possibilities:

Do not keyword the new version. This is perhaps not a good option if the old version has security holes.Remove the USE-flag. Users who relied on the (default) patch might get a surprise.Explicitly error out if the USE-flag is set to avoid such surprises. IMHO, the current solution is the best of these three. It is correct that the feature - since it is not upstream - should perhaps not have been enabled at all by default; but this depends on how important the developers consider the feature.

----------

## tnt

 *mv wrote:*   

> Do not keyword the new version. This is perhaps not a good option if the old version has security holes.Remove the USE-flag. Users who relied on the (default) patch might get a surprise.Explicitly error out if the USE-flag is set to avoid such surprises.

 

that's obvious, but nobody running server with a stable branch with default config should run into such a middle-of-nowhere USE-flag tunnings, and especially not without some big announcement message.

and if anybody has just tried to update a stable branch system with default USE-flags before releasing this ebuild, he/she wound definitely notice that it doesn't go well. ==> QA

----------

## toralf

I just missed a good git  commit message.

----------

## khayyam

 *mv wrote:*   

> Do not keyword the new version. This is perhaps not a good option if the old version has security holes.Remove the USE-flag. Users who relied on the (default) patch might get a surprise.Explicitly error out if the USE-flag is set to avoid such surprises.

 

 *tnt wrote:*   

> that's obvious, but nobody running server with a stable branch with default config should run into such a middle-of-nowhere USE-flag tunnings, and especially not without some big announcement message.

 

tnt ... why? If it is a choice between reacting to a vunerability quickly, and preserving continuity with a "high performance" patch, then I would expect anyone maintaining a server to choose the former. Disabling hpn (until such a time when the patch is updated) would seem to me the more sensible option, use-change and all. As for being notified, the package does warn on hpn being set explicitly, otherwise all that is happening is a IUSE change and these are not treated as warrenting a news item.

 *tnt wrote:*   

> and if anybody has just tried to update a stable branch system with default USE-flags before releasing this ebuild, he/she wound definitely notice that it doesn't go well. ==> QA

 

I just did, and everything went fine.

best ... khay

----------

## Hu

As I read the ebuild, the USE flag hpn is only defaulted on if HPN_PATCH is non-empty.  Users who made no decision receive USE=hpn when the patch is available and USE=-hpn when it is not available.  The only users who are unable to update are the ones who have made a local configuration change to set USE=hpn even when the ebuild would not enable it by default.

----------

## curmudgeon

 *Hu wrote:*   

> As I read the ebuild, the USE flag hpn is only defaulted on if HPN_PATCH is non-empty.  Users who made no decision receive USE=hpn when the patch is available and USE=-hpn when it is not available.  The only users who are unable to update are the ones who have made a local configuration change to set USE=hpn even when the ebuild would not enable it by default.

 

I suppose that offers some explanation as to why this happened. My security policy requires explicit approval of EVERY USE flag. When I saw "+hpn" in a previous version, I investigated it, and added it to /etc/portage/make.conf. I never considered the possibility that the flag would appear (not masked) in the list of USE="foo bar" but not actually be available. To me, that is a bug, not a feature. If a USE flag is not available, it should be masked.

----------

## Hu

The problem with masking it is that then it is forced off for everyone, regardless of their USE settings.  By masking the hpn flag, everyone would be able to upgrade to it, and nobody would get hpn.  In some cases, users might prefer to have USE=hpn even at the price of running a known-vulnerable version of openssh.  If the sshd is only accessible to trusted users due to other filtering (e.g. network firewalls), running a vulnerable version might be acceptable.

----------

## steveL

 *Hu wrote:*   

> As I read the ebuild, the USE flag hpn is only defaulted on if HPN_PATCH is non-empty.  Users who made no decision receive USE=hpn when the patch is available and USE=-hpn when it is not available.

 

That is truly horrible. Far better to fail if the two do not match.

----------

## Hu

I do not understand your position.  For each of the three cases, what are you proposing should happen when HPN_PATCH is not defined?

Case 1: User has explicitly set USE=hpn (either in make.conf or package.use).

Case 2: User has explicitly set USE=-hpn.

Case 3: User has not made any decision, and may well be unaware that HPN exists and its purpose.

In the current ebuild, the results are:

Case 1: HPN is used if available.  The ebuild dies if HPN is not available.

Case 2: HPN is never used.

Case 3: HPN is used if available.  The ebuild succeeds without HPN if HPN is not available, so users lose the benefits of the HPN patch, but are able to upgrade without taking special steps.

----------

## steveL

 *Hu wrote:*   

> I do not understand your position.

 

My position is: do not do anything automagic, especially with dependencies, and especially with USE settings. (like defaulting to on or off according to what is on the filesystem, or in the environment.)

So Case 3 should be excluded: let the user find out about the ability to add the patch, from the metadata about the USE flag, or otherwise, just like we do for every other ebuild or flag out there.

As soon as you start doing automagic stuff, reproducible builds go out the window.

We've learnt this lesson over long years, so let's not forget about it now.

Further you really do not want USE flags defaulting to on or off, according to the local env; it means the idea of a shared cache goes out the window (the same reason we have restrictions on what an ebuild can do in "global scope".)

If I've misunderstood what's happening, apologies; I simply reacted to the statement previously quoted.

As it is, I'm surprised the openssh ebuild hasn't been slapped with a QA violation.

By all means, clarify my confusion. :)

----------

## Ant P.

I have to agree with that; USE=hpn should go in an -r1 so people who need it can p.mask -r0 (i.e. people who don't like being locked out of their servers because they had one of the HPN sshd_config lines uncommented...)

----------

## curmudgeon

 *Hu wrote:*   

> As I read the ebuild, the USE flag hpn is only defaulted on if HPN_PATCH is non-empty.  Users who made no decision receive USE=hpn when the patch is available and USE=-hpn when it is not available.

 

This is too clever by far more than half. Why not make the use flag either not show up at all, or show up as masked (which it effectively is) when the patch is not available.

 *Hu wrote:*   

> The problem with masking it is that then it is forced off for everyone, regardless of their USE settings.  By masking the hpn flag, everyone would be able to upgrade to it, and nobody would get hpn.

 

If the hpn patch is not available, no one is going to get it regardless.

 *Hu wrote:*   

> In some cases, users might prefer to have USE=hpn even at the price of running a known-vulnerable version of openssh.

 

Fine, then let them see a masked USE flag when they attempt to upgrade. That should get their attention.

 *steveL wrote:*   

> 
> 
> My position is: do not do anything automagic, especially with dependencies, and especially with USE settings. (like defaulting to on or off according to what is on the filesystem, or in the environment.)

 

I could not agree more. My biggest annoyances with  Gentoo is when it tries to take decisions away from the users (it was designed to do the exact opposite).

 *steveL wrote:*   

> As soon as you start doing automagic stuff, reproducible builds go out the window.
> 
> We've learnt this lesson over long years, so let's not forget about it now.
> 
> Further you really do not want USE flags defaulting to on or off, according to the local env; it means the idea of a shared cache goes out the window (the same reason we have restrictions on what an ebuild can do in "global scope".)

 

Could not have said it better myself.

 *Ant P. wrote:*   

> I have to agree with that; USE=hpn should go in an -r1 so people who need it can p.mask -r0 (i.e. people who don't like being locked out of their servers because they had one of the HPN sshd_config lines uncommented...)

 

YES! To amend my thought above, my biggest COMPLAINT about actually using Gentoo is when things get changed in an ebuild (sometimes even including dependencies), and there is no version bump (which often leads to the inability to reproduce issues with no idea why). Any subsequent addition of the hpn patch to net-misc/openssh-7.2_p2 should REQUIRE a version bump (-r1). Period.

----------

## Hu

There is nothing automagic here.  The user's local system has no influence on whether HPN_PATCH is defined or undefined, and so no influence on the ebuild default value of USE=hpn.  The Gentoo developer who comments or uncomments HPN_PATCH controls whether it is enabled.  Most of the rest of steveL's post is therefore inapplicable, because it all assumes that this is triggered by local environment, not by a variable in the ebuild.

Ant P.: people who configure HPN in their sshd_config ought also to set USE=hpn in their Portage configuration, which would prevent them from upgrading to an HPN-free openssh.  Whether they will set that, I cannot say.

curmudgeon: as I explained above, if the USE flag is masked, then people who set USE=hpn can upgrade to this version and end up with no HPN.  As I also explained, under the current design, if HPN is not available, and your environment has USE=hpn through package.use, the ebuild will fail, leaving you on an older version of openssh with HPN and an error message explaining that you need to choose whether you want to disable HPN and upgrade now or keep HPN and wait until the new version has it.  I have seen enough users blow past masked USE flags that I seriously doubt having this one masked would get their attention.  If you disagree, I would encourage you to contact a developer who works on openssh and express your view there.  I am just a user who can explain how this works, and I am trying to explain it because you explicitly indicated you did not know why it was working the way that it is.  While I will agree that a hard abort is undesirable, I believe that the current capabilities of the package manager make this the best way to avoid upgrade surprises.  Even if you convinced me otherwise, there is nothing I can do to help you.  I do not maintain this package.  I have no influence over those who do.

I see no reason for the revision bump when HPN becomes available.  People who do not use HPN will not need a rebuild, but a revision bump would ask them to do one anyway.  People who do use HPN will not have upgraded to -r0 because of the hard abort in the current -r0, so they will still need an upgrade when the HPN patch becomes available.  It would be nice to have the package manager recognize that situation and remind them that now they can upgrade, but I do not know how to do that with current EAPI.

----------

## curmudgeon

 *Hu wrote:*   

> There is nothing automagic here.

 

Perhaps not in the most common meaning, but the developers have made a default decision for users (use HPN), which is subject to availability (without adequate notice, in my opinion). That is not "The Gentoo Way."

 *Hu wrote:*   

> under the current design, if HPN is not available, and your environment has USE=hpn through package.use, the ebuild will fail, leaving you on an older version of openssh with HPN and an error message explaining that you need to choose whether you want to disable HPN and upgrade now or keep HPN and wait until the new version has it.

 

I still see this as clearly inferior behavior. The package manager should explicitly say "sorry, I can't build this version of openssh with hpn," (BEFORE the emerge) rather than appear that it can and then die. First, that leaves the user with the impression that something is wrong (in general, ebuilds should not die). Second, it may not be obvious to many people (myself included, before this thread) just why the ebuild died.

 *Hu wrote:*   

> I have seen enough users blow past masked USE flags that I seriously doubt having this one masked would get their attention.

 

I am all for making things simpler for the "non-hardcore" users, but looking at the "emerge -p" output is a basic requirement to run Gentoo effectively (my opinion, again). I want to understand every use flag and dependency change from one version to the next (even more so, when rebuilding something already installed). Further, those who really needs hpn are likely not casual users, and they should be expected to maintain a higher level of vigilance.

 *Hu wrote:*   

> I am just a user who can explain how this works, and I am trying to explain it because you explicitly indicated you did not know why it was working the way that it is.

 

I do understand (and appreciate) that. Thank you.

 *Hu wrote:*   

> I see no reason for the revision bump when HPN becomes available.  People who do not use HPN will not need a rebuild, but a revision bump would ask them to do one anyway.  People who do use HPN will not have upgraded to -r0 because of the hard abort in the current -r0, so they will still need an upgrade when the HPN patch becomes available.

 

I am going to disagree most strongly with that, only because hpn is enabled in the ebuild by default (if available). Feel free to criticize that decision, but you are talking about those who emerge after a particular moment in time getting a binary with an extra capability that the developers thought it important enough to make a default. This leads to huge reproducibility issues (one of the biggest problems of Gentoo in both theory and practice), and THE PATCH CAN'T BE MADE AVAILABLE IN THIS VERSION WITHOUT THE EBUILD BEING UPDATED ANYWAY. That alone, makes a revision bump mandatory (my opinion, yet again).

 *Hu wrote:*   

> It would be nice to have the package manager recognize that situation and remind them that now they can upgrade, but I do not know how to do that with current EAPI.

 

Easily done the old fashioned way (a bump to openssh-7.2_p2-r1). :)

----------

## steveL

 *Hu wrote:*   

> There is nothing automagic here.  The user's local system has no influence on whether HPN_PATCH is defined or undefined, and so no influence on the ebuild default value of USE=hpn.  The Gentoo developer who comments or uncomments HPN_PATCH controls whether it is enabled.  Most of the rest of steveL's post is therefore inapplicable, because it all assumes that this is triggered by local environment, not by a variable in the ebuild.

 

Ah thanks for clarification. So long as the eclass/ebuild sets HPN_PATCH= (to empty) then I am fine; otherwise it could leak from the env.

I agree with curmudgeon about the revision-bump, though, if the developer has set HPN_PATCH.

Again, if I'm missing something, apologies.

edit: Hmm not sure if I am fine with what I'm hearing (fwiw.) Why is there even a USE flag, when there's no patch defined?

The ebuild cannot support it, so wtf is it doing in IUSE?

Further, why default it to on, just because it happens to be available? As a developer, you are effectively just applying it for the majority of users in that case. Clearly it has implications, or you would just apply it directly: so don't make that call by the backdoor.

Make it, or preferably don't.

What khayyam said sums it up for me:  *khayyam wrote:*   

> If it is a choice between reacting to a vunerability quickly, and preserving continuity with a "high performance" patch, then I would expect anyone maintaining a server to choose the former. Disabling hpn (until such a time when the patch is updated) would seem to me the more sensible option, use-change and all.

 

----------

