External dependency on Globus GSI-OpenSSH

[icheceoin]

GCT has an external dependencies on Globus GSI-OpenSSH based on OpenSSH 7.5p1 dating from 2017-06-27. These patches are pulled in by default if a manual source build is performed. See "prep-gsissh" in the source tarball.

Is there a plan to include up to date GCT supported GSI-OpenSSH versions of these patches? Or to change the build process to remove these patches?

[matyasselmeci]

We definitely want to fix the build process. IMO the way we build gsi-openssh by fetching the patches is horrifying...

[icheceoin]

Is OpenSSH 7.5p1 plus the patches from the Globus repo currently considered a secure base to build GSI-OpenSSH on? I'll be advising administrators who are upgrading to use downstream binary RPM installs or source RPM builds but many will have a historical build process that involves ./configure ... from source.

[fscheiner]

@icheceoin
Is there a way for you to use the source RPMs of GSI-OpenSSH in EPEL6 or EPEL7? What OS are you using actually?

[icheceoin]

@fscheiner
Personally, I'm happy to use the EPEL binary RPMs for my own use case and I think EPEL source RPMs of GSI-OpenSSH should cover everything else.

My question mainly related to how easily a user can currently inadvertently build an unpatched GSI-OpenSSH version right now if they're used to a ./configure ... build procedure.

[fscheiner]

@icheceoin

My question mainly related to how easily a user can currently inadvertently build an unpatched GSI-OpenSSH version right now if they're used to a ./configure ... build procedure.

Of course. I just wasn't sure if you were aware of the possible "alternative" to use source RPMs from EPEL, which is what I already recommended to PRACE sites for the transition from the Globus Toolkit to the GCT.

But also good to have that emphasized as issue here for other users.

[fscheiner]

@matyasselmeci @ellert @msalle
Maybe we should rephrase the issue title to something like:

GCT's in-tree GSI-OpenSSH is outdated

....and close this issue when we have a solution on how to provide GSI-OpenSSH as part of the GCT sources.

OTOH GSI-OpenSSH is actually not really in-tree, but only pulled in during the configure run. :-/

[ellert]

As part of the proposed changes in PR #63, the build script is changed to use the patches from the source tree in packaging/debian/gsi-openssh/debian/patches/ instead of downloading them.

[icheceoin]

@ellert
That at least gets us part the way there but it still leaves the project using OpenSSH 7.5p1 by default.

[fscheiner]

@ellert @msalle @matyasselmeci @icheceoin
After fixing openssh-gsskex/openssh-gsskex#18 my proposal would be to always include the full sources of GSI-OpenSSH from the latest stable Fedora version in the GCT sources. So this will always be based on the current version of OpenSSH or a version very close to the current version of OpenSSH. And it will be more similar to the other parts of the GCT in that the gsi_openssh subdir will contain a set of source files from the beginning instead of only during a build.

Thoughts?

[msalle]

Sounds reasonable and probably the best we can do.

[ShamrockLee]

I tried to package GCT with Nix package manager as a dependency of other CERN softwares, but the download-when-build behavior makes the work complicated.

Nix (a cross-platform package manager) forbids network access without using fetchers and predetermined hashes to keep the package "purely declarative"

It would make things much easier to injech the dependencies with other not-so-ad-hoc approaches.

[maarten-litmaath]

Hi,
why can't those other softwares just depend on rpms etc. instead?

Please note the Grid Community Forum collaboration only has limited effort available and may hence not be in a position to make and debug considerable changes in the build procedures.

[matyasselmeci]

Hi @ShamrockLee , EPEL has the same restriction so you should take a look at how they handled it (here's a link to their source RPMs: https://dl.fedoraproject.org/pub/epel/7/SRPMS/Packages/g/).

You can also try building the software suite without GSI-OpenSSH by deleting prep-gsissh from your checkout and adding --disable-gsi-openssh to your ./configure line.

[fscheiner]

@ShamrockLee:
This should be solved as soon as we start to ship the GCT with the full sources of a current GSI-OpenSSH. See #67 (comment) for details.

[fscheiner]

Fixed in GCT 6.2.20210826 maintenance release.