External dependency on Globus GSI-OpenSSH about gct HOT 15 CLOSED

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.

from gct.

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

from gct.

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.

from gct.

@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?

from gct.

@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.

from gct.

@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.

from gct.

@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. :-/

from gct.

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.

from gct.

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

from gct.

@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?

from gct.

Sounds reasonable and probably the best we can do.

from gct.

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.

from gct.

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.

from gct.

@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.

from gct.

Fixed in GCT 6.2.20210826 maintenance release.

from gct.