Providing RPM releases in EPEL

[paulmillar]

Hi,

Are there plans to get oidc-agent into EPEL?

The reason I'm asking is that my efforts to push oidc-agent have somewhat stalled on oidc-agent not being available in EPEL:

https://gitlab.cern.ch/fts/fts-rest/-/merge_requests/34#note_3579200

Cheers, Paul.

[marcvs]

The cern gitlab is not particularly friendly to work with our IdP, so I can't comment there, but:

Of course, we are committed to bringing oidc-agent into all major distributions. We have debian on a higher priority than epel, though. Any help will be appreciated!!

[paulmillar]

Don't worry too much about the merge/pull request. It was only to point out that there's a pull request where the FTS REST client would use oidc-agent, but it's currently blocked because oidc-agent (and perhaps the python API/binding, too) isn't currently part of EPEL.

I terms of thoughts on getting oidc-agent into EPEL, one option would be to approach Mattias Ellert mattias.ellert@physics.uu.se and ask if he can help out. He has a lot of experience with getting packages into EPEL.

[paulmillar]

Hiya,

Has there been any progress on getting oidc-agent into EPEL?

[marcvs]

Well, I got it building on copr at some point. Then asked Petr Vokac who told me was tasked with this from HEP, and never heard of him again.

We're currently busy with Version 4.3.0. I'll give it another try once we have that finished. Windows is more of a priority at the moment.

[vokac]

I assigned this task to me myself, because it is not comfortable to use packages outside of normal distribution channels. It took some time to have a response for first review and meanwhile I moved to different topics... Now, I would like to move forward with EPEL packages for this software ... updates can be tracked in related bugzilla issue#1997994.

I think for EPEL we should simplify oidc-agent packages, keep just essential functionality and drop GUI interface which doesn't add to much value and brings unnecessary dependencies. Than we'll hopefully have just clib-list that is not available in EPEL. Build system for this application seems to me a bit fragile and e.g. export USE_CJSON_SO=1 doesn't really work for me ... actually what's the reason not to use library provided by distribution?

[paulmillar]

Hi @vokac,

I think for EPEL we should simplify oidc-agent packages, keep just essential functionality and drop GUI interface which doesn't add to much value and brings unnecessary dependencies

I understand the motivation here, and such a decision wouldn't affect me: I always use the command-line. However, I'm wondering whether dropping support for GUI-based interaction is a good idea.

For years (decades, even) people have complained that using X.509 is difficult. In part, (I believe) this comes from the requirement to use obscure command-line invocations.

If the EPEL packages included the oidc-agent GUI support then it's possible that (for some users) the token-based approach would be seen as an improvement over the current X.509-based tools.

In the end, the decision should try to balance the cost/benefit. I would suggest not ruling out the GUI part ... at least, if including the packages isn't a complete nightmare.

[vokac]

OK, I agree that GUI is important for end users, but I'm probably too focused on WLCG token transition timeline where we don't expect users to really use tokens for next four years. We did not even started real discussion how to make tokens easy to use by users and which tools will be really used ... in my view right now oidc-agent it is mostly for "developers".

[marcvs]

The GUI part is more problematic to package, so we'll first focus on non-gui elements. The GUI (that prompts users for passphrase, really not much more) is very handy in my day-to-day commandline scripted use. Some scripts run to use some oidc-protected rest-interfaces. Whenever I had to reboot (i.e. my oidc-agent is restarted) running the scripts prompts me to enter the passphrases, which is kinda neat, but not quite essential.

[paulmillar]

Thanks for the feedback.

Actually, I would suggest that not all oidc-agent users are developers.

There are some (non-WLCG) use-cases in Helmholtz (in Germany) where the people involved are not developers (at least, that is not their main focus), but are rather "power-users". For them, oidc-agent appears to be a reasonable solution. To be somewhat more concrete, one particular solution involves using oidc-agent and rclone to access OIDC-authenticated WebDAV storage. This is not intended for developers, but for real, scientific researchers. There are also other use-cases (e.g., triggering data replication) where OIDC-based authentication would be helpful. OIDC-based authentication is a burgeoning field.

One of useful features of oidc-agent is that a user can (in principle) install it easily on their desktop.

Alternatives (such as Fermilab's solution based on Hashicorp Vault) have certain advantages when operating at scale; however, it's hard for me to see such solutions scaling down, so that an individual will installing Vault on their desktop machine. In general, I think it's very helpful if we provide a way for individuals to be productive using OIDC without requiring the deployment of a new, campus-wide IT service. This also helps demonstrate the demand; which, in turn, could drive IT to deploy more scalable solutions.

I'm certainly happy if the initial work focuses on the non-GUI part: rclone is command-line driven, after all.

Just please don't forget that, for some users, the GUI may also be important.

Cheers, Paul.

[ellert]

https://packages.fedoraproject.org/pkgs/oidc-agent/

[paulmillar]

Just to update this issue, the oidc-agent family of packages is available in EPEL 9, EPEL 8 and EPEL 7.

Therefore, I believe we can close this issue. My thanks to everyone who contributed, especially @ellert.