[Discuss] [Gt-eos] GSI-OpenSSH Packages for Ubuntu

[Mischa Salle]

On Thu, Jul 04, 2019 at 02:52:20PM +0200, Frank Scheiner wrote:
> On 7/4/19 11:57, Mischa Salle wrote:
> > On Thu, Jul 04, 2019 at 09:07:45AM +0200, Frank Scheiner wrote:
> > > Debian uses different versions of OpenSSH in different versions of Debian:
> > > 
> > > 
> > > * Jessie (oldstable) - OpenSSH 6.7p1
> > > * Stretch (stable) - OpenSSH 7.4p1
> > > * Sid (unstable) - OpenSSH 7.9p1 => will also be in Buster (testing)
> > > 
> > > ...taken from [1].
> > > 
> > > [1]: https://packages.debian.org/search?suite=all&searchon=names&keywords=openssh-server
> > > 
> > > I don't expect that our current patch set (for 7.5p1) applies to these
> > > OpenSSH versions without further modification - but I can be wrong.
> > > 
> > > UPDATE: Ok, I think I understand what you mean. Though I'm not sure if
> > > that's so easy:
> > > 
> > > Don't different Debian versions incl. Ubuntu versions link their OpenSSH to
> > > different versions of its dependencies? How do we know if our version will
> > > always work correctly with the respective dependency on a specific version
> > > of Debian or Ubuntu?
> > 
> > If we build it against a certain Debian version, I don't see a reason
> > why it won't work for that Debian version? It's just a different binary
> > from the OS-openssh. and we have basically nothing to do with the
> > OS openssh.
> 
> But maybe with incompatible dependencies in the respective Debian versions,
> isn't that realistic? Well, maybe we just have to try.

Still not sure what you mean. You could give the same argument for any
piece of source code: If I compile my source code (in this case
openssh-X.Y plus a set of patches on that source code) on platform Z,
then yes it is possible that it fails runtime in some unexpected way but
not due to ABI incompatibility. Once I have compiled against OS-Z, its
dependencies (library SO versions) are in the binary, so that should
work runtime. The other incompatibilities are no different for any piece
of software we maintain (i.e. the rest of GCT).

> > > And what version of OpenSSH should we use, is the one in the GCT tree
> > > (7.5p1) still supported? I don't think so, so we would need to get or
> > > backport fixes from a 7.5p1 package that's still maintained somewhere.
> > That is indeed an issue, but not different from what we do for Fedora.
> 
> The situation for Fedora actually is different - as I just noticed:
> 
> Because for the Fedora RPM spec files we don't have one for GSI-OpenSSH in
> the GCT tree, it only exists for the different EPEL and Fedora releases at
> Fedora, effectively eliminating the "problem" we currently discuss for
> Debian.
Yes and no, ultimately the patches are against a openssh source tarball,
not really against the rest of the OS (at least not AFAIK). The point is
that we there try to keep the version of gsi-openssh in sync with the OS
version of openssh I think?

> And if there would be a RPM spec for GSI-OpenSSH in the GCT, which version
> would we use? The newest one for EPEL or Fedora or something else?
I think the spec isn't so different, but yes, I would probably just try
to build the newest version available.

> We can't do the same for Debian at the moment, as Debian didn't accept the
> GSI-OpenSSH package because of the amount of code shared with the OpenSSH
> package - i.e. something that seems to be a non-issue for Fedora.
> 
> So why not follow the OpenSSH version in Debian unstable for our Debian
> packaging until it gets accepted in Debian? But even after dropping the
> iSSHD and HPN patches there's still a 500+ KiB patch to forward-port to a
> still supported OpenSSH version. Who can do that?
> 
> > I'd suggest to use the newest upstream version for which we have a
> > patch-set, and compile that for the different Debians and Ubuntus we
> > think are useful.
> 
> We have:
> 
> * one "full" patch set for 7.5p1 for the GCT and the Debian packaging in the
> GCT - but 7.5p1 is no longer supported upstream and I also don't see it used
> by Debian ([1]), Ubuntu ([2]), CentOS 6 ([3]) and 7 ([4]) (dito for SL 6 and
> 7), Fedora 29 ([5]) and 30 ([6]) or SUSE ([7]) - though I don't know what's
> available for SLES 12 and 15
> 
> [1]: https://packages.debian.org/search?suite=all&searchon=names&keywords=openssh-server
> 
> [2]: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=openssh-server
> 
> [3]: http://mirror.centos.org/centos/6/os/x86_64/Packages/
> 
> [4]: http://mirror.centos.org/centos/7/os/x86_64/Packages/
> 
> [5]: https://dl.fedoraproject.org/pub/fedora/linux/releases/29/Everything/x86_64/os/Packages/o/
> 
> [6]: https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Everything/x86_64/os/Packages/o/
> 
> [7]: https://software.opensuse.org/package/openssh
> 
> * most likely the same for all older OpenSSH versions which could allow us
> to pick a - though older - OpenSSH version that is still supported by a OS
> community or vendor as basis
> 
> * one patch set (don't know the exact extent) for 7.6p1 from Eisaku Sakane
> (see [gct issue #72]) - this version is also used in Ubuntu 18.04 so will be
> supported by Canonical until end of April 2023
> 
> [gct issue #72]: https://github.com/gridcf/gct/issues/72
> 
> * GSI-only (@Mattias: Is that correct?) patch sets for EPEL and Fedora
> versions up to the latest upstream version of OpenSSH.

That's where I would start. Once we have the basic GSI-openssh, we can
add other patches. We actually got offers from people to help with this
if I remember correctly...

    Cheers,
    Mischa
-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4521 bytes
Desc: not available
URL: <http://mailman.egi.eu/pipermail/discuss/attachments/20190704/8fe4137c/attachment.p7s>