Yes, I think we definitely want to support anyone who has signed the FPCA to be able to fork, push to their private fork and submit PRs against the master.

I think the packager group should be required to be allowed to merge to the master repository for the package.

@aries hit same issue one day, but he told me that it is possible to make changes via webui ...

Yes, I think we definitely want to support anyone who has signed the FPCA to be able to fork, push to their private fork and submit PRs against the master.
I think the packager group should be required to be allowed to merge to the master repository for the package.

+1

Yes, I think we definitely want to support anyone who has signed the FPCA to be able to fork, push to their private fork and submit PRs against the master.
I think the packager group should be required to be allowed to merge to the master repository for the package.

+1

This issue will be discussed in tomorrow's FESCo meeting, 2017-09-08 at 16:00:00 UTC in #fedora-meeting on Freenode.

FESCo agreed to @sgallagh's proposal during today's meeting: anyone who has signed the FPCA is allowed to fork, push to their private fork and submit PRs against the main repo. The packager group is required to merge to the main repo.

https://meetbot-raw.fedoraproject.org/fedora-meeting/2017-09-08/fesco.2017-09-08-16.00.txt

It might be nice to talk to @pingou here and see what the current state is and what it would take to implement the above. @pingou ?

So, I would first like to point out that right now, people can already push their fork to any other git repo host (pagure.io anyone?), and create a remote PR. There's nothing blocking that, just blocking people to push to their forks on pkgs.fp.o.

So, the title of this ticket should not be Allow PRs for non-packagers, but Allow git push access to repos on pkgs.fedoraproject.org for non-packagers.

Getting people to push to their fork directly on pkgs.fp.o is something entirely different, and to that I'm going to add a lot of requirements, and I'd like to know if FESCo still agrees.
Basically, if FESCo wants infra to enable non-packagers pushing to pkgs, I am going to limit everything on pkgs so that nobody except admins can do anything but git from it.
No outside internet access, no internal network access, nothing.

I just don't want to get the risk of people we don't know doing "strange" stuff coming from one of the servers in our network.

I don't believe any of us considered that ssh access would be needed when we made our decision last week, so I am a +1 to revisiting the decision in light of @puiterwijk's comment.

+1 to revisiting as well, I also hadn't taken into consideration the ssh access component.

I have to ask: What would we ever want non-admins to do on pkgs besides git? What functionality would be lost by locking down pkgs in this way?

It seems to me that we'd want that machine to be maximally locked down regardless of which level of contributor access we require, so I'm wondering if this would somehow require the removal of useful functionality.

So, I would first like to point out that right now, people can already push their fork to any other git repo host (pagure.io anyone?), and create a remote PR. There's nothing blocking that, just blocking people to push to their forks on pkgs.fp.o.

Why is allowing non-packagers to push to pagure.io less critical than allowing them to push to pkgs.fp.o? What kind of attacks are you afraid of? I assume it is that people might circumvent gitolite to execute arbitrary commands on the host. This would mean that they could manipulate any git repo on that host. This includes critical repos to create Fedora releases such as the releng repo with scripts that are automatically cloned and executed each day. I assume that the worst case for the Fedora project is that we distribute manipulated RPMs, which would be possible by this.

Basically, if FESCo wants infra to enable non-packagers pushing to pkgs, I am going to limit everything on pkgs so that nobody except admins can do anything but git from it.
No outside internet access, no internal network access, nothing.
I just don't want to get the risk of people we don't know doing "strange" stuff coming from one of the servers in our network.

This restrictions seem to make sense in any case, since packages should only be allowed to access git on pkgs. Is there a specific task that would be complicated by this?

I don't believe any of us considered that ssh access would be needed when we made our decision last week, so I am a +1 to revisiting the decision in light of @puiterwijk's comment.

IMHO these are technical details and there is not enough information/proposals to make a new decisions as FESCo. Our agreed vision is that there is an easy workflow for non-packagers to create PRs afaiu. Deciding whether this means to lock down pkgs more because we distrust gitolite or changing pagure to make forking repos from pkgs actually creating a repo on pagure.io and requesting a PR on the forked pagure.io repo creating a PR back on pkgs is something the infrastructure group can decide on their own. I am happy to provide feedback on actual proposals but IMHO there is not yet enough information/proposals to discuss this in a meeting.

Right, we don't need to discuss technical details here.

We will see if we can come up with a way to implement what FESCo asked us for here. In the event we decide it's not feasable, we will be happy to come back here and explain why and we can go from there.

I have to ask: What would we ever want non-admins to do on pkgs besides git? What functionality would be lost by locking down pkgs in this way?
It seems to me that we'd want that machine to be maximally locked down regardless of which level of contributor access we require, so I'm wondering if this would somehow require the removal of useful functionality.

Yes, I do want to lock the system down the same way whether we do this or not, but my concern is that if FESCo tells us "this must be enabled now", we do not yet have the time to properly do this, especially given the high number of other things on infra's queue right now due to modularity etc.

I am going to limit everything on pkgs so that nobody except admins can do anything but git from it.

I believe this is already the case afaik

Not sure how I ended up closing this :s

To provide a little more context on the situation, there is nothing on the pagure side that prevents non-packagers from pushing to their fork. The issue is in the way we've used and set-up gitolite on dist-git. Instead of relying on a single system account (which is how gitolite is supposed to be setup) we are creating one account per user, in this case, one account per packager. So while pagure allows the non-packagers to push to their fork, they simply do not have an account on the system letting them in.

I am going to limit everything on pkgs so that nobody except admins can do anything but git from it.

I believe this is already the case afaik

It is in the fact that there's gitolite-shell. However, if we want to grant non-packagers access, I want to limit it by more factors ("defense in depth"), for example from outgoing network traffic, in case an issue is found in gitolite.
This is simply a result of the number of people that would suddenly get access to the system, since the barrier for "packager" access is higher than for "CLA+1".
(Look at spammers. Some of those have gotten CLA+1 just by requesting membership to every single group, and finding one that just sponsors everyone who requests.)

Yes, I do want to lock the system down the same way whether we do this or not, but my concern is that if FESCo tells us "this must be enabled now", we do not yet have the time to properly do this, especially given the high number of other things on infra's queue right now due to modularity etc.

For the record, I don't think FESCo made any statement about timeframe for this. What we did was assert what we would like the end state to look like. The idea is to minimize the effort involved in getting contributions.

If it takes a few months to figure out and implement, I see no issue with that.

I'm not sure there's anything to vote on here, but I'm with sgallagh on this -- I'm not too worried about any sort of tight timeframe on this. I'd rather have things secure than rush to simplify things and open ourselves to possible security issues in the short term.

2017-09-15 FESCo Meeting:

#agreed Close ticket in favor of an Infra Ticket to implement (+1:5, -1:0, +0:0)

link to infra ticket?

There is https://pagure.io/fedora-infrastructure/issue/6361 although that appears to have been created independently rather than as a response to this ticket.