#108 Would be good if there was an acl for "let all packagers edit this package" in pkgdb
Closed None Opened 14 years ago by rstrode.


I own a lot of packages that get contributions once in a while from random people. Usually they're like simple spec file fixes, but occasionally patches back ported from upstream or new fixes.

When I get these easily reviewable things, I like to say "feel free to commit" so the barrier to contribution is really low and so I don't have to stop what i'm doing to make the change, or punt and forget about the bug.

I'm pretty sure, at one point my packages had open ACLs, but that got changed when provenpackager was added.

I'd like a checkbox next to 'provenpackager' that's like it, but for every packager, not just those that have passed the provenpackager litmus test.

Some relevant discussion from IRC:
<abadger1999> halfline: Could you propose it to FESCo? I can add it back with a little work but I want to stop flipf-lopping :-)
<halfline> just as long as i get to choose who works on mine
<generalBordeaux> warren, i think its the same problem there ... (yum + rpm + proxies) ... (flash player + videos + proxies ..)
<halfline> abadger1999: trac ticket?
<jds2001> halfline: yeah, we can take it up on friday
<halfline> ok
<abadger1999> Excellent.
<warren> generalBordeaux: anyway, the new spec isn't a proxy
hughsie is now known as hughsie-afk-runn.
<skvidal> generalBordeaux: kick ass, man
dmlloyd has left chat #fedora-devel (Nick collision from services.).
** dmlloyd_ is now known as dmlloyd.
<generalBordeaux> skvidal, thanks!!
<warren^ in short, repository replicating filesystem * jds2001 may be a few minutes late...nautre calls at an inopportune time :( I'm sure that was TMI, oh well..... <llaumgui> warren > description in pv
<generalBordeaux> warren, i hope you'll blog about it ... and we'll be informed automatically via planet.. or just give me link to some page which i can lookup periodically for the updates ...
<f13> halfline: the problem is that exposing a 'packager' box directly conflicts with the interests of those that aren't comfortable sponsoring new contributors if said new contributors had access to more than just their own packages.
<halfline> f13: it shouldn't conflict, because those contributors won't have access to those people's packages
<f13> I think you didn't understand me
<halfline> not having the 'packager' box directly conflicts with my interest of keeping the barrier to contribute as low as possible
<f13> sponsors are not willing to be /responsible/ for a new packager that has "keys to the castle"
<f13> halfline: sponsors are more comfortable if they are responsible for people who only have explicit access to packages, rather than the whole shebang.
<halfline> but it's not the whole shebang, it's my packages
<f13> its your packages now
<halfline> it's no different than me explicitly adding them to the acl
<f13> and anybody else's packages that check the 'packager' box
<halfline> i'm just asking it happen automatically
<f13> and then we're to the point where all the work for proven packagers and new packager containment has been thrown out the window
<f13> and we're back to where we were months ago
<f13> people unwilling to open their packages, people unwilling to take on new packagers.
<halfline> i should be able to decide who works on my packages...
<f13> you can decide
<f13> explicitly
<halfline> i'm explicitly deciding i'd like everyone to be able to work on my packages
<halfline> anyway, feel free to voice your concerns on the ticket: https://fedorahosted.org/fesco/ticket/108
<halfline> i don't sponsors to decide if the person they're sponsoring can work on my packages, i want to decide
<warren> Sprint seems to call every month asking if I'm happy with their service. I tell them I plan on leaving if they don't have an Android phone soon. They then call again the next month.
<halfline> likewise i don't want fesco to decide who can work on my packages
cjb thinks halfline sounds reasonable.
<halfline> it shouldn't be anyone's choice but mine and the person wanting to contribute

sorry about the lack of newlines on that.

More discussion:

<tibbs|h> As a sponsor, I am the one that has to decide whether a person gets access to a limited amount of Fedora infrasture: cvs for their package.
<tibbs|h> Before, when it was bunches of packages, we were very reluctant to sponsor people. We asked them to demonstrate their value to the project in various ways.
<tibbs|h> It was essentially a filter to get rid of the fire and forget packagers, as well as those who might be trying to get access for unpleasant purposes.
<tibbs|h> We can't do background checks; we can't even see their account data if they click the private button. So we don't have much to go on.
<tibbs|h> Restricting new packagers to their packages only has allowed us to lower the barrier to entry.
<tibbs|h> If we go back to "you get access to a bunch of stuff" then we'll start to worry again, and honestly I just don't want to be put in that position again.
<tibbs|h> That's as well as I can articulate it in this medium.
<halfline> i don't think it's something to worry about in practice though... like i said, gnome's is open and it's been open for over a decade with no real problems
<tibbs|h> And yet we've been hacked and are still smarting from it.
<halfline> you can deal with people who misbehave via social mechanisms
<halfline> "don't do that"
<halfline> and if they do it again take away all their packaging rights
<tibbs|h> Of course, the fact that we don't know how we were hacked doesn't exactly help.
<cjb^ was the person who hacked you a registered Fedora developer? <br /><cjb> (I actually don't know the answer.)
<tibbs|h> I have no way to know that answer.
<halfline> i think getting hacked is sort of orthogonal to this discussion
<cjb> But you're assuming it?
<mjg59> tibbs|h: Given a determined attacker, it's probably possible for anyone who can upload to Fedora to gain access to infrastructure
<cjb> (By bringing it up as relevant.)
<tibbs|h> I am assuming nothing; my point is that we are somewhat paranoid.
<halfline> remember anyone who builds any package at all can add their own nasties in %post
<mjg59> tibbs|h: The probability of someone doing something actively malicious by modifying an infrastructural package is pretty small, simply because so many people are going to see those patches
<halfline> we don't need to be paranoid though, paranoia doesn't gain us anything but unneeded process
<tibbs|h> Well, that's your opinion and you are of course welcome to it.
<mjg59> So I don't think the evil guy concern is a valid concern
<mjg59> I think we're much more at risk from well-meaning incompetence
<tibbs|h> But I know rather well where I stand, and I am much happier with the current "you get access to your own packages until you prove yourself" situation than the previous one.


FWIW, I have no problems changing the pkgdb, I just want to know what the policy should be.

tibbs's concern about initial sponsorship is why I proposed there be another new group below packager (or between packager and provenpackager) before. That was already voted down once, though, so I'll shut up about it now ;-)

Tabled this until mmcgrath comes back with a threat assessment. Then changes can be discussed.

There was some discussion about this at the meeting today, search for

.fesco 108



to read where it starts.

Threat assessment has been done. Putting this back on the meeting agenda.

Also: link to Sponsor Responsibilities which should be tied into whatever we decide:


Initial FESCo thoughts are that this is a desirable feature but there are a good many issues they want to resolve in doing it:

  • opt-in. Should be no problem to do this.
  • Maybe: cvs-commit message fixed. This was something people saw as a threat but also agreed that maintainers should still be diligent about watching what has been checked into a package when the maintainer builds and pushes. ricky is working on fixing this, though.
  • fs acls. Currently, a cvs acl script does the heavy lifting of who is allowed and who is denied access to a package. Standard Unix permissions are set so someone must be in the packager group to commit to a package if the acl script were to fail for some reason. fs acls would let us lock this down more or discard the cvs acl script. I'm not sure that fs acls can address any vulnerability in the proposed system that aren't present in the current system, though.
  • General revamp of pkgdb acls/fs acls/etc. This was mentioned but no specifics of what was wanted.
  • Tie to SCM switch: if any of the above are hard/impossible to accomplish with the current SCM, this could be a reason to move to a new SCM.

We're not going to do this at this point. Or if we are, consider this a kick in the butt and reopen it.

for what it's worth, i'm still would very much like this feature, and I'm disappointed it got closed.

Login to comment on this ticket.