<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...
<Henson>
patches and eventually transition over to openssh version 8.0?
<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
<flokli>
Henson: hpn contains just some performance improvements, no other features, right?
<flokli>
urgh. the openssh derivation just points to a completely different src if hpn support is enabled
<Henson>
yes, but that source seems to be based off the openssh/openssh-portable repository
<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
<Henson>
there's already an openssh_hpn nixpkgs attribute that's based off the openssh derivation with hpnSupport=true specified
<Henson>
and no packages in nixpkgs other than openssh_hpn call the openssh derivation with hpnSupport enabled
<flokli>
The hpn people didn't publish some patches somewhere?
<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>
at least for unstable
<flokli>
if somebody picks it up, we can apply a set of patches, like the gssapi ones
<flokli>
but that's just my opinion ¯\_(ツ)_/¯
<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
<Henson>
who knows if anybody is even using this hpn feature
<qyliss>
mark the package as broken with hpn support, and at some future point if nobody's removed it we can kill it
pietranera has quit [Quit: Leaving.]
<Henson>
qyliss: so would I just add meta.broken=true to the openssh_hpn derivation?
<andi->
if it fails do that
<andi->
and leave a comment why (preferably)
<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?
<flokli>
Henson: I guess it's ok to break stuff in unstable, especially if upstream is unmaintained and it's unclear if stuff is used at all
<flokli>
and if someone cares about it, he can still fix it afterwards…
<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.
<gchristensen>
we don't want to keep junk around for no reason
<gchristensen>
so if we're keeping something, it should be for a very good reason
<Henson>
ah, ok
<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?
<gchristensen>
I'm afraid that is above my paygrade
<flokli>
:-D
<andi->
if you know it is broken set broken = true conditionally that is probably better then throwing an error
<Henson>
haha
<andi->
filtering broken packages is a thing we are "good" at... Random assertions doesn't that great
<Henson>
ok, so it's possible to set meta.broken = true in response to somebody setting hpnSupport=true?
<flokli>
I think this means, rip out all the hpnSupport specific code from the openssh derivation, keep the argument, but ignore it, except set meta.broken if it's set to true?
<Henson>
also, in the future, is this a discussion that should happen within the pull request of the openssh package, or is doing it through IRC fine?
<gchristensen>
at least summarizing the discussion on the PR would be good
<Henson>
ok
<samueldr>
instead of keeping a ghost image, marked broken, why not simply drop it all off?
<samueldr>
(with appropriate release note indicating the package has been dropped)