#6361 All write access on src.fedoraproject.org requires membership in packager group

Created 11 months ago by scfc
Modified 14 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.

11 months ago

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

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.

4 months ago

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

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

Just hit this issue.

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

+1 I just hit this too.

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.

Edited 15 days ago by kathenas

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

Edited 15 days ago by kathenas

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

Login to comment on this ticket.