Allow non packagers to push to distgit forks via ssh #11292

New issue

Closed

opened 2023-05-07 20:35:57 +00:00 by gotmax23 · 5 comments

gotmax23 commented

2023-05-07 20:35:57 +00:00

NOTE

If your issue is for security or deals with sensitive info please
mark it as private using the checkbox below.

Describe what you would like us to do:

Users who aren't members of the packager group should be able to push to their distgit forks via ssh. The current fedpkg clone -a http clone solution is nonideal. It's confusing for new packagers. git clone can't be used like it can for other git forges, as fedpkg is needed to setup the git cred helper. it requires a browser for the OIDC authentication, so it can't be used on a headless machine.

16:53 <+gotmax23> Is there a reason that non packagers still can't push to distgit forks via ssh?
18:21 <nirik> yes
18:22 <nirik> it's a complex tangle... I think we thought of a way to do it, but it's not been implemented yet.

**NOTE** If your issue is for security or deals with sensitive info please mark it as private using the checkbox below. # Describe what you would like us to do: ---- Users who aren't members of the packager group should be able to push to their distgit forks via ssh. The current `fedpkg clone -a` http clone solution is nonideal. It's confusing for new packagers. `git clone` can't be used like it can for other git forges, as fedpkg is needed to setup the git cred helper. it requires a browser for the OIDC authentication, so it can't be used on a headless machine. ``` 16:53 <+gotmax23> Is there a reason that non packagers still can't push to distgit forks via ssh? 18:21 <nirik> yes 18:22 <nirik> it's a complex tangle... I think we thought of a way to do it, but it's not been implemented yet. ```

ssbarnea commented

2023-05-08 07:37:20 +00:00

Please fix this, I wasted few hours over the weekend trying to make a contribution to a package. The current situation is very unfriendly for new-commers as it is unresonably limited and complex.

I am afraid that if not improved, it might serious impact the ability to increase the number of packagers over time, as most people might lose interest if the entry barrier is so high. We can assume that almost anyone is able to fork, make a git commit and create a pull request, something that can be done from any platform (not only Fedora).

I am using a MacOS as my primary host and I found that since 2018 is no longer possible to get a working installation of the fedpkg on it.

Basically I am advocating for a fedpkg free workflow that should allow anyone to propose a contribution via git alone. No other tooling, no platform requirements, no weird login experience (ssh not allowed for non-packager and the console-to-web login is fully broken for remote access as it assumed a localhost:1234 port for the response back, instead of having a polling check in place). Basically I failed to login even from a Fedora VM because it was a headless one.

Opening ssh, might prove a good first step towards making 1st contribution easier.

Please fix this, I wasted few hours over the weekend trying to make a contribution to a package. The current situation is very unfriendly for new-commers as it is unresonably limited and complex. I am afraid that if not improved, it might serious impact the ability to increase the number of packagers over time, as most people might lose interest if the entry barrier is so high. We can assume that almost anyone is able to fork, make a git commit and create a pull request, something that can be done from any platform (not only Fedora). I am using a MacOS as my primary host and I found that since 2018 is no longer possible to get a working installation of the fedpkg on it. Basically I am advocating for a fedpkg free workflow that should allow anyone to propose a contribution via git alone. No other tooling, no platform requirements, no weird login experience (ssh not allowed for non-packager and the console-to-web login is fully broken for remote access as it assumed a localhost:1234 port for the response back, instead of having a polling check in place). Basically I failed to login even from a Fedora VM because it was a headless one. Opening ssh, might prove a good first step towards making 1st contribution easier.

kevin commented

2023-05-08 16:55:33 +00:00

So, I agree it would be great to fix this.

However, it's a big can of worms.

Our dist-git setup is from the cvs days, and here's how it works:

packages have real accounts on pkgs01 (ie, pkgs.fedoraproject.org/src.fedoraproject.org). When a packager pushes a commit, it actually runs as them and (in addition to pagure perms checks) it also uses filesystem permissions. When a non packager tries to push something it doesn't work because... they don't have an account there.

Now, pagure.io works completely on pagure acl checks and runs everything as the 'git' user. It has ssh keys in it's database (seperate from accounts)
pkgs01 has ssh keys in the account system / ipa and gets them from there, not pagure.

We could move to a model like that on pkgs01. However, we would need to be VERY CAREFUL not to break acls or introduce secure problems. This would involve changing all the files in the entire git repo and re-working the acl wrapper to make sure it does the right thing.

We have been waiting until we actually move to gitlab or some other forge to try and do this.

To answer the above question, you can already do PRs with just some git server. Push your changes to some branch on any network reachable git server. Go to the package and click on 'create pull request' and click on 'remote pull request'. Fill in the url to your commit/branch and other info and... done? Does that work for your use case?

So, I agree it would be great to fix this. However, it's a big can of worms. Our dist-git setup is from the cvs days, and here's how it works: packages have real accounts on pkgs01 (ie, pkgs.fedoraproject.org/src.fedoraproject.org). When a packager pushes a commit, it actually runs as them and (in addition to pagure perms checks) it also uses filesystem permissions. When a non packager tries to push something it doesn't work because... they don't have an account there. Now, pagure.io works completely on pagure acl checks and runs everything as the 'git' user. It has ssh keys in it's database (seperate from accounts) pkgs01 has ssh keys in the account system / ipa and gets them from there, not pagure. We could move to a model like that on pkgs01. However, we would need to be VERY CAREFUL not to break acls or introduce secure problems. This would involve changing all the files in the entire git repo and re-working the acl wrapper to make sure it does the right thing. We have been waiting until we actually move to gitlab or some other forge to try and do this. To answer the above question, you can already do PRs with just some git server. Push your changes to some branch on any network reachable git server. Go to the package and click on 'create pull request' and click on 'remote pull request'. Fill in the url to your commit/branch and other info and... done? Does that work for your use case?

kevin commented

2023-05-08 18:02:37 +00:00

Metadata Update from @kevin:

Issue priority set to: Waiting on Assignee (was: Needs Review)
Issue tagged with: high-trouble, medium-gain, ops

**Metadata Update from @kevin**: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: high-trouble, medium-gain, ops

zlopez commented

2023-07-13 16:56:06 +00:00

Contributor

[backlog refinement]
This issue isn't a small task and needs to change the whole deployment of dist-git. @gotmax23 Please file this as CPE initiative as we don't have resources to work on this in Fedora Infra.

[backlog refinement] This issue isn't a small task and needs to change the whole deployment of dist-git. @gotmax23 Please file this as [CPE initiative](https://docs.fedoraproject.org/en-US/cpe/initiatives/) as we don't have resources to work on this in Fedora Infra.

zlopez commented

2023-07-13 16:56:07 +00:00

Contributor

Metadata Update from @zlopez: