#6361 All write access on src.fedoraproject.org requires membership in packager group
Opened a year ago by scfc. Modified 24 days ago

As a non-packager, I forked https://src.fedoraproject.org/fork/scfc/rpms/emacs-php-mode from https://src.fedoraproject.org/rpms/emacs-php-mode via the "Fork" button. "Source GIT URLs" for my fork says ssh://pkgs.fedoraproject.org/forks/scfc/rpms/emacs-php-mode.git. If I try to clone that, it fails with "Permission denied":

[tim@passepartout ~]$ git clone ssh://pkgs.fedoraproject.org/forks/scfc/rpms/emacs-php-mode.git $(mktemp -d)
Klone nach '/tmp/tmp.Pmv1p2nfw8' ...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
[tim@passepartout ~]$

My ssh key is correctly specified in my FAS profile at https://admin.fedoraproject.org/.

I'm not sponsored, but my assumption is that there should be no difference between the right to fork a repository and being able to access it.


Due to the way things are currently setup, this is not possible.

So, as a workaround you can setup a repo somewhere else and do a remote PR on src.fedoraproject.org. We are working to allow this use case more easily.

Metadata Update from @pingou:
- Issue tagged with: src.fp.o

a year ago

In positive side effect of the current situation is described in https://pagure.io/fedora-infrastructure/issue/6424

So something to take into account when investigating this ticket.

In https://pagure.io/fesco/issue/1770 FESCo voted to

#agreed Close ticket in favor of an Infra Ticket to implement

Any progress on this?

It is still in our roadmap/radar. Some work for it has been started, do not worry, we will announce it when it is there :)

This is blocking efficient collaboration of qe & devel on test maintenance in the new tests namespace. I suggest we address this issue in the coming weeks.

If this issue is resolved, update this documentation, please:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#One-off_contributions

See the thread "new section for 'Join the package collection maintainers'" in the devel mailing list for history.

This issue is not resolved yet. It's being worked on and we will update this issue as soon as it's fixed.

Metadata Update from @kevin:
- Issue priority set to: Waiting on External

6 months ago

I think this is at least the 2nd time a new user has hit this problem. I'm thinking we should disable forking for non packagers and send them to a page that links to the bug and tells them about remote PRs instead.

To open a remote PR: https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request

Me also. I want to make a PR to the fossil package, I have forked it here:

https://src.fedoraproject.org/fork/petasis/rpms/fossil

But I have been trying a whole day to understand why cloning with ssh does not work.
Now, I found this... :-)

PRs are merged. Fixed now?

@abitrolly the PR are merged but I don't think they have been released yet :)

I can sell you releasemeter that measures lag between feature merges and releases. =)

There is progress on this, it's pending review at:
- https://pagure.io/fedpkg/pull-request/225
- https://pagure.io/rpkg/pull-request/322

i took a gander at the PRs but it's not obvious.. what exactly is the fix?

We are allowing HTTPS-based pushing, for which users do not need ssh access to our systems, but instead use OpenID Connect/OAuth2 access tokens to authenticate pushes.
The PRs contain code to rpkg/fedpkg to retrieve and provide said tokens to git actions.

Is there a plan to release a new package which we could test the functionality with? Are there any extra config steps required from the user to make this working? Thanks.

Everything is in place on the server end now, we are just waiting for another fedpkg/rpkg release with the changes.

@cqi is there any plan for a fedpkg release soon? Thanks.

Yes. There is a plan to release rpkg and fedpkg in this month.

Plan with tests could get it gets automatically released once all of them pass. )

This is an essential feature and needs to be rolled about as a matter of priority. The poor workflow created without this is horrific and prevents efficient contribution.

+1 hit this as well,
If non packagers are not allowed to push code to src.fedoraproject.org, please disable the fork option, thanks!

rpkg-1.55 and fedpkg-1.34 have been released which support this. Please have a try.

https://docs.pagure.org/rpkg/releases/1.55.html
https://docs.pagure.org/fedpkg/releases/1.34.html

rpkg-1.55 and fedpkg-1.34 have been released which support this. Please have a try.
https://docs.pagure.org/rpkg/releases/1.55.html
https://docs.pagure.org/fedpkg/releases/1.34.html

These needs to be rebuilt for EPEL please, so those who use RHEL and CentOS etc. can use them.

These needs to be rebuilt for EPEL please, so those who use RHEL and CentOS etc. can use them.

There is. https://bodhi.fedoraproject.org/updates/?packages=rpkg&status=testing

The reason I didn't mention that yet is because there is current a issue with pagure preventing non packagers from making forks.... but sure if you already have an existing fork it might work.

The reason I didn't mention that yet is because there is current a issue with pagure preventing non packagers from making forks.... but sure if you already have an existing fork it might work.

With the updated packages from 'epel-testing', the issue remains when attempting to clone a repo or fork of a repo.

@kathenas with the new packages, non-packagers can clone their forks with the -a ("anonymous") flag, which will clone over HTTPS, and you can now push via that same clone URL as well.
So please make sure to clone your fork with the -a flag.

@kathenas with the new packages, non-packagers can clone their forks with the -a ("anonymous") flag, which will clone over HTTPS, and you can now push via that same clone URL as well.
So please make sure to clone your fork with the -a flag.

The on fork page 'Source GIT URLs' are misleading and fail, no matter what.

You can successfully clone a fork via HTTPS, doing:

fedpkg clone --anonymous forks/<your_fas_name>/rpms/<project_name>

Could you maybe give us the full URLs?

Could you maybe give us the full URLs?

At the moment I am playing/testing: https://src.fedoraproject.org/fork/kathenas/rpms/liferea

Clone done with:

fedpkg clone --anonymous forks/kathenas/rpms/liferea

Below command will fail:

fedpkg clone --anonymous https://src.fedoraproject.org/forks/kathenas/rpms/liferea.git

Then we get to the fun stuff...

Make a change to the spec file.

Commit the above change.

'fedpkg push' will prompt for FAS username and password and display the following through that element.

[philwyett@ks-kenobi liferea]$ fedpkg push
Could not execute gitcred_get: init() got an unexpected keyword argument 'printfd'
Could not execute gitcred_get: init() got an unexpected keyword argument 'printfd'
Could not execute gitcred_erase: init() got an unexpected keyword argument 'printfd'
Could not execute gitcred_erase: init() got an unexpected keyword argument 'printfd'
fatal: Authentication failed for 'https://src.fedoraproject.org/forks/kathenas/rpms/liferea.git/'
Could not execute push: Command '['git', '-c', 'credential.helper=/usr/bin/fedpkg gitcred', '-c', 'credential.useHttpPath=true', 'push']' returned non-zero exit status 128
[philwyett@ks-kenobi liferea]$

It should not be asking for a userna,e/password.
However, this issue is known and is caused by fedpkg missing a requires on python-openidc-client >= 0.6.0.
So if you grab the new python-openidc-client from updates-testing, it should work.

It should not be asking for a userna,e/password.
However, this issue is known and is caused by fedpkg missing a requires on python-openidc-client >= 0.6.0.
So if you grab the new python-openidc-client from updates-testing, it should work.

Added the app and FAS token grab worked.

Now able to fork, commit and PR.

Fork:

https://src.fedoraproject.org/fork/kathenas/rpms/liferea

Commit:

https://src.fedoraproject.org/fork/kathenas/rpms/liferea/c/cc75359ff77bda4b405d956ef2185e34c16c2b69?branch=master

PR:

https://src.fedoraproject.org/rpms/liferea/pull-request/2

Now fantastic and contribution is made simple. :-D

Today. @vstinner (not a packager) was surprised by the fact the ha was able to fork a repo, but not to push to his fork.

I propose, as well as @franzh did: if non packagers are not allowed to push code to src.fedoraproject.org forks, please disable the fork option. This is really a confusing setup.

Thank You.

@churchyard This is in fact fixed, we just haven't announced it yet.

They definitely should have been able to push to their fork via fedpkg push (provided fedpkg is new enough and they are using a graphical session that has a browser running).

I'll try and get things alined to announce this as soon as I can...

The procedure is documented in https://fedoraproject.org/wiki/CI/Pull_Requests for the moment, but we'll need to document it elsewhere and announce it for sure :)

Also, the documentation doesn't work on Fedora 29, where fedpkg uses Python 3.

@churchyard do you have a recent enough version of fedpkg and python3-openidc-client installed?
And what does "doesn't work" mean?

"deson't work" in the most recent comment relates to the documentation that mentions python2-openidc-client. I'm working on updating it to work both on F29+ and F28-.

https://fedoraproject.org/w/index.php?title=CI%2FPull_Requests&type=revision&diff=525804&oldid=523133

I don't need this HTTP pushing for myself. But to answer your question, I have python3-openidc-client-0.6.0-3.20180605gitcd8d91c.fc29.noarch

Login to comment on this ticket.

Metadata