#6696 Long-lived pagure token for fedpkg
Closed: Will Not/Can Not fix 4 years ago by cverna. Opened 6 years ago by cqi.

As you might have known that new version of fedpkg has the ability to allow requesting new package repository and branch by creating issues in src.fp.o, that requires user to save his/her own pagure token into a local configuration file in several steps, go to src.fp.o website, generate the token, create a user configuration file and save that token into that file. Technically, this works well. However, I'm thinking is it possible to simplify these steps by just using a long-lived token issued from infra, which

  • is limited for fedpkg use only
  • allows to create issues only in releng/fedora-scm-requests
  • can be delivered as part of the fedpkg configuration in the fedpkg.conf

Another thing I'm not sure if this long-lived token solution is feasible, that is, with user's own token, the created issue's Reporter property has the user's name, so when using a long-lived token that is not dedicated for a specific user, what value would the Reporter property have? I have no idea if there is way to find out user's name from a long-lived token. What I can figure out at this moment is to get user's name from bug and update it to the created issue, but it should depend on whether user uses same name in src.fp.o as well.

Could you please review this request whatever it's doable, any security issues there, or even other feasible solution instead of token? It's appreciated. Thanks!


Since the token are created by the users themselves on pagure, there no current a solution for long live token (at least longer live than what pagure offers now).

There are two aspects that can be worked on:
- There is the request to allow setting the end date for a token manually, I still would like to max that end date, but I have no idea on what would be a good max (1 year? more? less?)
- Some time in the future we're likely doing to migrate dist-git and/or pagure to use openid connect which comes with a different token system and may answer that question

I think the solution really is OIDC... Perhaps this is something we can work on at the upcoming infrastructure hackfest.

Metadata Update from @ralph:
- Issue tagged with: authentication

6 years ago

Metadata Update from @kevin:
- Issue assigned to pingou
- Issue priority set to: Waiting on Asignee

6 years ago

So, dist-git is now moved to OIDC right? But pagure.io isn't? Or is it?

What can we do here now?

AFAIK, neither have been moved to OIDC

Also the work that has been done for OIDC, ported the UI to it, not the API.
The work for the API was started by @cverna in https://pagure.io/pagure/pull-request/3016 but I believe it is stuck, also pending some changes upstream in ipsilon.

Should we close this ? and re open a ticket once the futur of our Authentication system is clearer ?

I would leave the decision to @onosek, who is current fedpkg maintainer.

Yes, we can close for now.

Metadata Update from @cverna:
- Issue close_status updated to: Will Not/Can Not fix
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Metadata