<qyliss>
giving hpn users an old version sounds fair enough to me though?
<ajs124>
#99959 there's an ssh bump that hasn't been merged for over 3 weeks, because 1. we didn't have the GSSAPI patches (which seem legit) and 2. someone at some point dropped support for having multiple different versions of ssh to accomodate hpn-ssh not providing timely updates.
<Henson>
required and wants to remove it, then they just have to get rid of the openssh_hpn derivation and nothing else is affected.
<Henson>
I think what I'll do it this: make openssh_hpn a full derivation in its own right (not being an override of openssh with hpnSupport=true), and make openssh be 7.9p1 without the hpnSupport logic. That way it simplifies openssh, allows upstream patches to be applied easily, and will allow it to progress to version 8.0 at some point in time. If somebody later decides hpnSupport is no longer...
<Henson>
but an underlying question still remains, do we keep the hpnSupport flag in the openssh package which automatically switches it back to version 7.8p1, do we move the hpnSupport logic into the openssh_hpn package which is forever stuck at 7.8p1, or do we just get rid of hpnSupport and openssh_hpn altogether?
<Henson>
ok, here's a wrinkle in the openssh_hpn thing I was asking about earlier. I made a mistake in that hpnSupport=true uses version 7.8p1 of OpenSSH, and my CVE patches for 7.9p1 were not being enabled conditionally on the version being 7.9p1, which is why they weren't applying to the hpnSupport source.
2019-08-08
<Henson>
ok, so please help me decide between flokli and qyliss' suggestions: should I add meta.broken = true to the openssh_hpn package, or should I throw an error from openssh when hpnSupport=true is supplied?
<Henson>
I still don't really understand why we can't just move openssh_hpn from depending on openssh with hpnSupport=true to its own derivation that no longer depends on the openssh derivation. That way openssh_hpn can continue to exist, with openssh moving forward with hpn logic removed from the derivation.
<Henson>
but it should be possible for somebody to specify an input to the openssh derivation that will cause it not to build. Since openssh_hpn will be marked as broken, if somebody has openssh with hpnSupport=true in an override, then it just won't work anymore. Perhaps this is why flokli suggested throwing hpn support isn't supported anymore. Is it okay to break the hpn package this way?
<Henson>
qyliss: so would I just add meta.broken=true to the openssh_hpn derivation?
<qyliss>
mark the package as broken with hpn support, and at some future point if nobody's removed it we can kill it
<Henson>
who knows if anybody is even using this hpn feature
<Henson>
but if people wanted to continue using hpn ssh for some reason, then spinning that off into openssh_hpn stuck at version 7.9 and allowing openssh to continue on without hpn support would allow people wanting hpn to keep using it
<flokli>
hrm, i'd just keep the hpnSupport attribute, remove the "conditional different src and version part", and throw that hpn support isn't supported and unmaintained
<flokli>
The hpn people didn't publish some patches somewhere?
<Henson>
and no packages in nixpkgs other than openssh_hpn call the openssh derivation with hpnSupport enabled
<Henson>
there's already an openssh_hpn nixpkgs attribute that's based off the openssh derivation with hpnSupport=true specified
<Henson>
so rolling hpn into the openssh derivation may have made sense at one time, but since development on hpn has stopped, it's not causing problems moving the openssh derivation forward
<flokli>
urgh. the openssh derivation just points to a completely different src if hpn support is enabled
<flokli>
Henson: hpn contains just some performance improvements, no other features, right?
<Henson>
the openbsd source code CVE patches could be modified to work with the hpn source code, but it seems like openssh with hpn support might need to be parked in its own derivation because it doesn't have any future at the moment
<Henson>
hi everyone, I have some questions about the openssh CVE patches I'm working on. It all builds properly except when hpnSupport=true because the hpn source code patch is not compatible with the openbsd source code patch. Since hpn is no longer maintained, should it be spun off to its own derivation for people who still want to use hpn, and the openssh derivation can continue with the CVE...