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

Created 9 months ago by scfc
Modified 6 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.

9 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:

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.

2 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:


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.

Login to comment on this ticket.