[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting)

On Thu, 2006-06-01 at 17:00 +0200, Thorsten Leemhuis wrote:
> Am Donnerstag, den 01.06.2006, 15:41 +0100 schrieb Jonathan Underwood:

> >  This discussion would also be useful in the
> > context of developing a mechanism for having a team of people
> > responsible for a package, rather than a single owner.
> We really need that. But that's stalled mostly because nobody in FESCo
> really works on driving it forward and the proposal from Patrice is
> still in my Todo-Inbox. :-((

This topic surfaces every now and then, often to be quickly countered
with "what do you need, just do it", which to my knowledge has not been
really answered.  Come on, what is there really to "drive forward" in

Just agree with the current maintainer of a package that you'll start
co-maintaining it, and add your email address to initialcclist in
owners.list, and start doing it.

> >  Do the problems
> > with the apprach alluded to by Konstantin have their roots in the
> > limitations of CVS permissions, or are there other issues?
> I don't know. It was started with the current scheme and I don't know
> the details why every packager has access everywhere. And it seems a lot
> of people don't want fine-graded ACLs. 

CVS ACLs are already deployed, but they're not currently fine grained at
all.  It should be possible to get them to be as fine grained as the
requirements are, but I guess maintaining them for a project like FE
(number of committers, number of packages) manually probably isn't fun
at all.

OTOH, some parts of the ACLs could be autogenerated from other sources,
such as allowing commit access to owners.list to a restricted group
only, and generating per-package ACLs from it + something that maps
bugzilla accounts to CVS accounts.

Also, providing broader commit access for the security response team
should be a no-brainer.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]