[Gt-eos] GSI-OpenSSH Packages for Ubuntu

[Mischa Salle]

Hi Frank,

On Thu, May 16, 2019 at 03:16:12PM +0200, Frank Scheiner wrote:
> also explicitly adding Mattias to the addressees.
> 
> On 4/29/19 11:16, Mischa Salle via Gt-eos wrote:
> > Hi Adam,
> > 
> > our apologies for not getting back to you (not sure about the others,
> > but I was offline last week).
> > 
> > In the past we have tried to get gsi-openssh in Debian, but we never got
> > it there, see e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687517
> 
> I'm not specifically familiar with the Debian processes for new packages -
> ITP ([1]) and RFP ([2]) in this case - but what is included in the above
> mentioned pseudo-bug doesn't sound to me like a complete nor official
> refusal.
> 
> [1]: https://wiki.debian.org/ITP
> 
> [2]: https://wiki.debian.org/RFP
> 
> Apart from that I wonder if this process should not be restarted - maybe
> this time with another approach, if the following makes sense:
> 
> Would it be possible to include the GSI-OpenSSH patches into the "official"
> OpenSSH source package ([3]) and produce a second set of server and client
> packages in addition to the existing OpenSSH server and client packages
> which link to the GSI libraries. This way the amount of duplication would be
> reduced and limited to the binary packages only.
I think this is probably not a good idea, the 'official' openssh is used
by vastly more people and these patches are still rather specific to a
subgroup.

> [3]: https://salsa.debian.org/ssh-team/openssh
> 
> And if Debian can afford to have three implementations of SSH clients
> (openssh-client ([4]), lsh-client ([5]), putty-tools ([6])) with assumed
> identical functionality, a fourth implementation with the added
> functionality of X.509-like authentication shouldn't hurt too much. It more
> hurts the users that they can't use GSI-OpenSSH on Debian/Ubuntu.
> 
> UPDATE: There's also another SSH implementation available in Debian, the one
> from Dropbear, though I assume this does not provide all the features of the
> other mentioned implementations.
I think that's a fair argument. Why not add another one that actually
adds something? Aparently, having 3 or 4 is not a problem...

> [4]: https://packages.debian.org/sid/openssh-client
> 
> [5]: https://packages.debian.org/sid/lsh-client
> 
> [6]: https://packages.debian.org/sid/putty-tools
> 
> Apart from all that, why not providing pre-compiled GSI-OpenSSH packages for
> Debian/Ubuntu ourselves in the meantime? Even more so when we already have
> the packaging meta data ready.
This indeed seems to be the first thing to do.
And if travis-ci can't do it, then the open buildservice could do it.

    Cheers,
    Mischa

> 
> > The rest of the GCT is in the Debian repositories. Also the packaging is
> > there, see https://github.com/gridcf/gct/tree/master/packaging/debian/gsi-openssh/debian
> > so in principle building is not too difficult, but we should indeed
> > provide pre-built binaries.
> 
> Cheers,
> Frank
> 
> -- 
> Frank Scheiner
> 
> High Performance Computing Center Stuttgart (HLRS)
> Department Project User Management & Accounting
> 
> Email: scheiner at hlrs.de
> Phone: +49 711 685 68039
> 



-- 
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/20190519/70d65ebb/attachment.p7s>