Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development (http://www.linux-archive.org/fedora-development/)
-   -   Concerns about 'provenpackager' and why I didn't mass ACL open (http://www.linux-archive.org/fedora-development/189586-concerns-about-provenpackager-why-i-didnt-mass-acl-open.html)

Michael DeHaan 11-07-2008 06:44 PM

Concerns about 'provenpackager' and why I didn't mass ACL open
 
Jesse Keating mentioned I should probably start a thread about why I
didn't include a few packages of mine in the mass-ACL opening with the
idea of starting a discussion about why some packages should or
shouldn't be included. I generally think in most cases people will do
the right thing with such access, but I choose to err on the side of
paranoid security when it comes to systems management software.


I'll explain -- For starters, I agree that it's important for people to
be able to fix packaging problems when needed (when the project owner is
not around especially), though my concern with the provenpackager system
is I am not sure of the levels of controls in place for what allows
someone to become a provenpackager -- or what would happen if a
provenpackager's machine+passwords get comprimised. With the number
of people being able to access a package being reasonably low, the risk
is low, but as we increase the number of people with commit access to
/anything/ so the risk also increases.


As I understand it, in general, provenpackager status requires packaging
a certain number of packages (N). In my opinion, this is insufficient
and potentially dangerous and package access should be given under an
"as needed" basis. This is for the same reason commit access to
repositories needs to be vetted (do any of us allow /everyone/ to
commit?) -- though in this case it's more important -- while git allows
backing off on a version, deleting history, and other things, this
system seems to allow for potentially releasing bits -- which is much
more powerful. It seems to allow deployed code to be changed without
the descretion of the people running the project. The risk is
unlikely but possible.


There are two events when it is dangerous -- (A) provenpackager decides
to correct what he thinks is an rpmlint error and thus unintentially
breaks the security of the packaged application, (B) credentials of
provenpackager are compromised allowing $evil to replace the contents of
a said package. In either case, the change could either be making a
new release of an application (which contains an exploit and/or
unwitting bug), or updating the specfile in a way that breaks file
permissions in a way that may not be immediately obvious (whether
intentional or not).
Now for some things, like desktop libraries, that could be used to
install a botnet type application -- through you still have to
comprimise N machines. What if you had a tool that allowed you to
comprimise an entire organization? That's something I want to make
sure never happens. Our security track record does not only stem from
things like SELinux, Unix permissions, and the like -- it also stems
from a culture of vigilance.


Now the two packages I've left off from the mass ACL opening now are
cobbler, koan, func, and certmaster.


The reason being for this is that these, if comprised, are tools that
/do/ allow reprogramming of an entire datacenter in very easy steps.
Cobbler could reinstall an entire set of managed machines in 1
command. Func should be more obvious. We pay very close attention to
these programs and while we are very accepting of any contributions and
ideas, we /do/ watch the commits very carefully. I know there are many
programs with similar capability that /have/ been opened up, but perhaps
because we didn't talk about consequences.


While it's true that any comprimised package would be a problem,
something as simple as making an unintended change to package
permissions (without first discussing it on the project lists), could
expose not the one system with packages installed but the entire set of
/managed/ systems.


I am not really comfortable with opening that up.

So, anyway, that's my logic ... if anyone can persuade me that releasing
new code is /not/ possible through the provenpackager system, I think I
could be persuaded to flip things, but right now, I can't see an
advantage in doing so.


(If a change is needed, people can still bring up the change on the
project lists and it can be made)


--Michael


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Michael DeHaan 11-07-2008 07:03 PM

Concerns about 'provenpackager' and why I didn't mass ACL open
 
Now the two packages I've left off from the mass ACL opening now are
cobbler, koan, func, and certmaster.


I mean Four .. and bright red shiny uniforms.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Toshio Kuratomi 11-07-2008 07:08 PM

Concerns about 'provenpackager' and why I didn't mass ACL open
 
Michael DeHaan wrote:
> Jesse Keating mentioned I should probably start a thread about why I
> didn't include a few packages of mine in the mass-ACL opening with the
> idea of starting a discussion about why some packages should or
> shouldn't be included. I generally think in most cases people will do
> the right thing with such access, but I choose to err on the side of
> paranoid security when it comes to systems management software.
>
> I'll explain -- For starters, I agree that it's important for people to
> be able to fix packaging problems when needed (when the project owner is
> not around especially), though my concern with the provenpackager system
> is I am not sure of the levels of controls in place for what allows
> someone to become a provenpackager -- or what would happen if a
> provenpackager's machine+passwords get comprimised. With the number
> of people being able to access a package being reasonably low, the risk
> is low, but as we increase the number of people with commit access to
> /anything/ so the risk also increases.
>
> As I understand it, in general, provenpackager status requires packaging
> a certain number of packages (N). In my opinion, this is insufficient
> and potentially dangerous and package access should be given under an
> "as needed" basis. This is for the same reason commit access to
> repositories needs to be vetted (do any of us allow /everyone/ to
> commit?) -- though in this case it's more important -- while git allows
> backing off on a version, deleting history, and other things, this
> system seems to allow for potentially releasing bits -- which is much
> more powerful. It seems to allow deployed code to be changed without
> the descretion of the people running the project. The risk is
> unlikely but possible.
>
> There are two events when it is dangerous -- (A) provenpackager decides
> to correct what he thinks is an rpmlint error and thus unintentially
> breaks the security of the packaged application, (B) credentials of
> provenpackager are compromised allowing $evil to replace the contents of
> a said package. In either case, the change could either be making a
> new release of an application (which contains an exploit and/or
> unwitting bug), or updating the specfile in a way that breaks file
> permissions in a way that may not be immediately obvious (whether
> intentional or not).
> Now for some things, like desktop libraries, that could be used to
> install a botnet type application -- through you still have to
> comprimise N machines. What if you had a tool that allowed you to
> comprimise an entire organization? That's something I want to make
> sure never happens. Our security track record does not only stem from
> things like SELinux, Unix permissions, and the like -- it also stems
> from a culture of vigilance.
>
> Now the two packages I've left off from the mass ACL opening now are
> cobbler, koan, func, and certmaster.
>
> The reason being for this is that these, if comprised, are tools that
> /do/ allow reprogramming of an entire datacenter in very easy steps.
> Cobbler could reinstall an entire set of managed machines in 1
> command. Func should be more obvious. We pay very close attention to
> these programs and while we are very accepting of any contributions and
> ideas, we /do/ watch the commits very carefully. I know there are many
> programs with similar capability that /have/ been opened up, but perhaps
> because we didn't talk about consequences.
>
> While it's true that any comprimised package would be a problem,
> something as simple as making an unintended change to package
> permissions (without first discussing it on the project lists), could
> expose not the one system with packages installed but the entire set of
> /managed/ systems.
>
> I am not really comfortable with opening that up.
>
> So, anyway, that's my logic ... if anyone can persuade me that releasing
> new code is /not/ possible through the provenpackager system, I think I
> could be persuaded to flip things, but right now, I can't see an
> advantage in doing so.
>
> (If a change is needed, people can still bring up the change on the
> project lists and it can be made)
>
I cannot allay your concerns and I can see your point. I'd like to
mention, though, that func depends on the following packages with open acls:

pyOpenSSL, python, python-simplejson

So in terms of protecting against $EVIL, restricting provenpackager
isn't very effective.

It is, effective for restricting people in provenpackager from making
unaudited changes to your code, though. So if you are a conscientious
maintainer who is on top of their bug reports, restricting
provenpackager could be good for everyone. On the other hand, if you're
a maintainer that has too many packages and other responsibilities and
doesn't get around to fixing things (or at least showing presence on a
bug) quickly, having provenpackager set is a definite detriment.

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating 11-07-2008 07:15 PM

Concerns about 'provenpackager' and why I didn't mass ACL open
 
On Fri, 2008-11-07 at 14:44 -0500, Michael DeHaan wrote:
> As I understand it, in general, provenpackager status requires packaging
> a certain number of packages (N). In my opinion, this is insufficient
> and potentially dangerous and package access should be given under an
> "as needed" basis.

Small correction here. Against my advise, the "has more than 5
packages" mark was only used for the initial seeding of the
provenpackager group. From this point on, the way to get in is to
request membership via the account system, and somebody already in the
group has to approve the membership. It isn't the same sponsorship type
thing that getting into packager has, once you approve somebody you're
not ultimately responsible for them. But we did want to make it
something somebody has to explicitly ask for, rather than be
auto-granted whether they want it or not.
>
> I am not really comfortable with opening that up.
>
> So, anyway, that's my logic ... if anyone can persuade me that releasing
> new code is /not/ possible through the provenpackager system, I think I
> could be persuaded to flip things, but right now, I can't see an
> advantage in doing so.

For rawhide, somebody would be able to commit a change and do a build,
and it would automatically go out in rawhide. But for a released
package, since it has to go through bodhi, only the "owner" can do bodhi
updates at this time. There are plans to enable co-maintainers to
submit updates too, but that would again be specifically granted people,
rather than members of a larger group.

All that said, I don't think your logic is wrong, and I think it has
been well thought out. I just wanted other folks to know where you were
coming from on these particular packages, mostly because it had seemed
in the past you were very much in favor of a more open system.

Thanks!

--
Jesse Keating
Fedora -- Freedomē is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Daniel P. Berrange" 11-07-2008 07:22 PM

Concerns about 'provenpackager' and why I didn't mass ACL open
 
On Fri, Nov 07, 2008 at 12:08:23PM -0800, Toshio Kuratomi wrote:
> I cannot allay your concerns and I can see your point. I'd like to
> mention, though, that func depends on the following packages with open acls:
>
> pyOpenSSL, python, python-simplejson
>
> So in terms of protecting against $EVIL, restricting provenpackager
> isn't very effective.
>
> It is, effective for restricting people in provenpackager from making
> unaudited changes to your code, though. So if you are a conscientious
> maintainer who is on top of their bug reports, restricting
> provenpackager could be good for everyone. On the other hand, if you're
> a maintainer that has too many packages and other responsibilities and
> doesn't get around to fixing things (or at least showing presence on a
> bug) quickly, having provenpackager set is a definite detriment.

IMHO, provenpackager is the wrong solution to that problem. Rather than
having a large group of people with commit to (nearly) everything for
fixing minor issues, the focus should be on significantly increasing our
levels of co-maintainership. The ideal should be for every package in the
distro to have at least 1 extra co-maintainer, or preferrably 3 or 4.
People with a little domain knowledge for the package who can handle
both the low-hanging fruit the main maintainer misses, with less risk
of making mistakes due to lack of package specific knowledge. Sure it'd
take more people resources than 'provenpackager' solution, and likely
require a big community publicity campaign to kick it off, but long
term it'd be more helpful & safer - particularly for 'infrastruture'
packages (python, perl, etc runtimes & important addon modules) and
security sensitive packages (openssl, gnutls, func, koan, etc).

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Michael DeHaan 11-07-2008 07:32 PM

Concerns about 'provenpackager' and why I didn't mass ACL open
 
Jesse Keating wrote:

On Fri, 2008-11-07 at 14:44 -0500, Michael DeHaan wrote:

As I understand it, in general, provenpackager status requires packaging
a certain number of packages (N). In my opinion, this is insufficient
and potentially dangerous and package access should be given under an
"as needed" basis.



Small correction here. Against my advise, the "has more than 5
packages" mark was only used for the initial seeding of the
provenpackager group. From this point on, the way to get in is to
request membership via the account system, and somebody already in the
group has to approve the membership.


This still seems a bit broad and unchecked to my liking.

The use cases for this are mainly what? Maintaince of packages
breaking other packages?


How large do we forsee this group being?


It isn't the same sponsorship type
thing that getting into packager has, once you approve somebody you're
not ultimately responsible for them. But we did want to make it
something somebody has to explicitly ask for, rather than be
auto-granted whether they want it or not.


I am not really comfortable with opening that up.

So, anyway, that's my logic ... if anyone can persuade me that releasing
new code is /not/ possible through the provenpackager system, I think I
could be persuaded to flip things, but right now, I can't see an
advantage in doing so.



For rawhide, somebody would be able to commit a change and do a build,
and it would automatically go out in rawhide. But for a released
package, since it has to go through bodhi, only the "owner" can do bodhi
updates at this time. There are plans to enable co-maintainers to
submit updates too, but that would again be specifically granted people,
rather than members of a larger group.

All that said, I don't think your logic is wrong, and I think it has
been well thought out. I just wanted other folks to know where you were
coming from on these particular packages, mostly because it had seemed
in the past you were very much in favor of a more open system.




I'm definitely big on collaboration and openness and all that -- not so
much on extending that decision as to when and what

to release of every software component.

If proven packagers cannot access non-rawhide updates, that's a
reasonable check, but is EPEL still not exposed (i.e. can a proven packager
use the build system and then EPEL testing will pick up the code just
like rawhide)?


I am basically looking at this in terms of the entire distro, and the
potential for exploit -- those packages

are just the ones I keep an eye on to explain my actions there.

We obviously can watch the commit logs for package CVS, though something
subtle has the chance to get

through. I want to be sure our bases are covered.

--Michael

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Michael DeHaan 11-07-2008 07:37 PM

Concerns about 'provenpackager' and why I didn't mass ACL open
 
Daniel P. Berrange wrote:

On Fri, Nov 07, 2008 at 12:08:23PM -0800, Toshio Kuratomi wrote:


I cannot allay your concerns and I can see your point. I'd like to
mention, though, that func depends on the following packages with open acls:

pyOpenSSL, python, python-simplejson

So in terms of protecting against $EVIL, restricting provenpackager
isn't very effective.

It is, effective for restricting people in provenpackager from making
unaudited changes to your code, though. So if you are a conscientious
maintainer who is on top of their bug reports, restricting
provenpackager could be good for everyone. On the other hand, if you're
a maintainer that has too many packages and other responsibilities and
doesn't get around to fixing things (or at least showing presence on a
bug) quickly, having provenpackager set is a definite detriment.



IMHO, provenpackager is the wrong solution to that problem. Rather than
having a large group of people with commit to (nearly) everything for
fixing minor issues, the focus should be on significantly increasing our
levels of co-maintainership. The ideal should be for every package in the
distro to have at least 1 extra co-maintainer, or preferrably 3 or 4.
People with a little domain knowledge for the package who can handle
both the low-hanging fruit the main maintainer misses, with less risk

of making mistakes due to lack of package specific knowledge. Sure it'd
take more people resources than 'provenpackager' solution, and likely
require a big community publicity campaign to kick it off, but long

term it'd be more helpful & safer - particularly for 'infrastruture'
packages (python, perl, etc runtimes & important addon modules) and
security sensitive packages (openssl, gnutls, func, koan, etc).


Daniel



Well said. Not just bringing up the problem but offering solutions.

How about we generate some reports on those packages that have one
maintainer and ones that we need obviously need backup for?
Minor issues that don't require an immediate fix /should/ be addressed
with the project (i.e. permissions look wrong in spec file, etc) rather
than being changed in CVS by someone and issuing their own builds. That
seems to be the responsible thing to do.


I assume Fedora release engineering folks already have
something-other-than-provenpackager access for emergency use anyway?


--Michael

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Toshio Kuratomi 11-07-2008 08:18 PM

Concerns about 'provenpackager' and why I didn't mass ACL open
 
Michael DeHaan wrote:
> Daniel P. Berrange wrote:
>> On Fri, Nov 07, 2008 at 12:08:23PM -0800, Toshio Kuratomi wrote:
>>
>>> I cannot allay your concerns and I can see your point. I'd like to
>>> mention, though, that func depends on the following packages with
>>> open acls:
>>>
>>> pyOpenSSL, python, python-simplejson
>>>
>>> So in terms of protecting against $EVIL, restricting provenpackager
>>> isn't very effective.
>>>
>>> It is, effective for restricting people in provenpackager from making
>>> unaudited changes to your code, though. So if you are a conscientious
>>> maintainer who is on top of their bug reports, restricting
>>> provenpackager could be good for everyone. On the other hand, if you're
>>> a maintainer that has too many packages and other responsibilities and
>>> doesn't get around to fixing things (or at least showing presence on a
>>> bug) quickly, having provenpackager set is a definite detriment.
>>>
>>
>> IMHO, provenpackager is the wrong solution to that problem.

provenpackager is the wrong solution to many problems. To me, the
provenpackager/packager split was a welcome thing because it allows us
to contain the *packager* group more strictly.

provenpackager is not as useful because it is broadly what the old
packager group was. If we were designing a group-style solution
specifically to fit the need of having people who can step in and make
corrections to packages then I'd advocate for a level above
provenpackager that has stricter entrance requirements.

>> Rather than
>> having a large group of people with commit to (nearly) everything for
>> fixing minor issues, the focus should be on significantly increasing our
>> levels of co-maintainership. The ideal should be for every package in
>> the distro to have at least 1 extra co-maintainer, or preferrably 3 or 4.
>> People with a little domain knowledge for the package who can handle
>> both the low-hanging fruit the main maintainer misses, with less risk
>> of making mistakes due to lack of package specific knowledge. Sure it'd
>> take more people resources than 'provenpackager' solution, and likely
>> require a big community publicity campaign to kick it off, but long
>> term it'd be more helpful & safer - particularly for 'infrastruture'
>> packages (python, perl, etc runtimes & important addon modules) and
>> security sensitive packages (openssl, gnutls, func, koan, etc).

This makes a lot of theoretical sense but has had mixed results in
practice. I can recall at least two drives to get comaintainers for
packages in the past. This has had some more people sign up for
comaintainership for some packages but it hasn't gotten us near to 100%
coverage. Some of the things it doesn't address:

Trust: If I'm a new contributor who just needed to get X.Y.Z in because
I just started using it on my shiny Fedora Desktop, I may not have any
contact with any other Fedora Contributor. If I don't trust the
provenpackager group with this software, I'm not likely to trust an
unknown packager who asks to be a comaintainer either. In fact, if
there was an over-all group of people who seldom make a mistake and know
packaging and software backward and forward, I'm more likely to entrust
that group with the ability to modify my package than the random packager.

Non-Responsiveness: If the package in question is getting bug reports
from people about the low-hanging packaging bugs but the bug reports are
not being answered even if there are two or more maintainers, there
still needs to be a way for the changes to be applied to the packages.
We also need to have a means of adding comaintainers when the maintainer
does not answer the requests to add a comaintainer.

A non-responsive, forced comaintenance policy would help deal with the
second part of this problem.

Interest in fixing an error that is easily checked for: Contributors
like Michael Schwendt have written and run checks for specific packaging
errors and then opened bugs for them against many packages. When the
bug is not replied to, they have written patches. When those aren't
acknoledged they have applied them where the acls are open. When the
acls are closed the process breaks.

A non-responsive: forced acl opening policy would work for this.

Interest in a package: If the packager is the only one interested in
doing work on a package, then there won't be a comaintainer. That
doesn't mean that the package won't have common problems so that someone
looking for common problems won't need to get changes applied to it later.

>
> Well said. Not just bringing up the problem but offering solutions.
>
> How about we generate some reports on those packages that have one
> maintainer and ones that we need obviously need backup for?

Some reports I'd be interested in seeing would be:
1) Open bug reports vs number of comaintainers
2) Unanswered bug reports vs number of comaintainers
3) Newer upstream versions (in rawhide) vs number of comaintainers


> Minor issues that don't require an immediate fix /should/ be addressed
> with the project (i.e. permissions look wrong in spec file, etc) rather
> than being changed in CVS by someone and issuing their own builds. That
> seems to be the responsible thing to do.
>
> I assume Fedora release engineering folks already have
> something-other-than-provenpackager access for emergency use anyway?
>
At the moment, the cvsadmin group has the ability to make commits
despite what acls are in place. I don't think we're often called on to
make changes to a package due to non-responsive maintainers, though.
Instead, we have opened the acls and orphaned packages for
non-responsiveness and people who are more interested in the package
have then taken over and done the work.

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating 11-07-2008 08:26 PM

Concerns about 'provenpackager' and why I didn't mass ACL open
 
On Fri, 2008-11-07 at 13:18 -0800, Toshio Kuratomi wrote:
>
> Trust: If I'm a new contributor who just needed to get X.Y.Z in because
> I just started using it on my shiny Fedora Desktop, I may not have any
> contact with any other Fedora Contributor. If I don't trust the
> provenpackager group with this software, I'm not likely to trust an
> unknown packager who asks to be a comaintainer either. In fact, if
> there was an over-all group of people who seldom make a mistake and know
> packaging and software backward and forward, I'm more likely to entrust
> that group with the ability to modify my package than the random packager.

To be fair, when I first proposed new maintainer containment, this above
was my vision for the elevated access group.

Unfortunately FESCo chose to fill that group with a much larger set of
people with nothing but "number of packages" as a requirement.

--
Jesse Keating
Fedora -- Freedomē is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Michael DeHaan 11-07-2008 08:59 PM

Concerns about 'provenpackager' and why I didn't mass ACL open
 
Rather than
having a large group of people with commit to (nearly) everything for
fixing minor issues, the focus should be on significantly increasing our
levels of co-maintainership. The ideal should be for every package in
the distro to have at least 1 extra co-maintainer, or preferrably 3 or 4.
People with a little domain knowledge for the package who can handle
both the low-hanging fruit the main maintainer misses, with less risk
of making mistakes due to lack of package specific knowledge. Sure it'd
take more people resources than 'provenpackager' solution, and likely
require a big community publicity campaign to kick it off, but long
term it'd be more helpful & safer - particularly for 'infrastruture'
packages (python, perl, etc runtimes & important addon modules) and
security sensitive packages (openssl, gnutls, func, koan, etc).



This makes a lot of theoretical sense but has had mixed results in
practice. I can recall at least two drives to get comaintainers for
packages in the past. This has had some more people sign up for
comaintainership for some packages but it hasn't gotten us near to 100%
coverage. Some of the things it doesn't address:

Trust: If I'm a new contributor who just needed to get X.Y.Z in because
I just started using it on my shiny Fedora Desktop, I may not have any
contact with any other Fedora Contributor. If I don't trust the
provenpackager group with this software, I'm not likely to trust an
unknown packager who asks to be a comaintainer either. In fact, if
there was an over-all group of people who seldom make a mistake and know
packaging and software backward and forward, I'm more likely to entrust
that group with the ability to modify my package than the random packager.



I would hope the process here is to:

(A) email package-owner@fedoraproject.org about the version and/or file
a bugzilla

(B) have a process to handle things if the owner is MIA

Let's take the "I need X.Y.Z" case. If someone can't make a change in
a week --- that in itself may not be a problem -- provenpackager may be
trying to be helpful, but may not have the domain knowledge about the
app -- say version X.Y.Z is not ready for prime time. I would say "I
need version X.Y.Z" now is not a strong enough reason to require an
override by a provenpackager if a maintainer is not immediately
reachable (say, on vacation). If the package maintainer is orphaned by
our definitions, it needs a maintainer. I certaintly would not want
someone updating the package and being suprised by that -- and then
having to revert those changes because they were wrong for the package.


And yes, I'm not likely to trust someone I don't know to co-maintain a
package, but likely are people that we /do/ know in many cases.

provenpackagers seems to imply a whole new need for a level of oversight
-- especially if any provenpackager can make more.



Non-Responsiveness: If the package in question is getting bug reports
from people about the low-hanging packaging bugs but the bug reports are
not being answered even if there are two or more maintainers, there
still needs to be a way for the changes to be applied to the packages.
We also need to have a means of adding comaintainers when the maintainer
does not answer the requests to add a comaintainer.

A non-responsive, forced comaintenance policy would help deal with the
second part of this problem.

Interest in fixing an error that is easily checked for: Contributors
like Michael Schwendt have written and run checks for specific packaging
errors and then opened bugs for them against many packages. When the
bug is not replied to, they have written patches. When those aren't
acknoledged they have applied them where the acls are open. When the
acls are closed the process breaks.





This /seems/ to be why we have the "MIA maintainer" policy. If the
maintainer is unresponsive we have a larger issue and a temporary fix to
the package will still leave the package out of date, and it starts to
be maintained ad-hoc and is likely to grow more out of date.



A non-responsive: forced acl opening policy would work for this.

Interest in a package: If the packager is the only one interested in
doing work on a package, then there won't be a comaintainer. That
doesn't mean that the package won't have common problems so that someone
looking for common problems won't need to get changes applied to it later.



I think it's covered by the above too, isn't it?



Minor issues that don't require an immediate fix /should/ be addressed
with the project (i.e. permissions look wrong in spec file, etc) rather
than being changed in CVS by someone and issuing their own builds. That
seems to be the responsible thing to do.

I assume Fedora release engineering folks already have
something-other-than-provenpackager access for emergency use anyway?



At the moment, the cvsadmin group has the ability to make commits
despite what acls are in place. I don't think we're often called on to
make changes to a package due to non-responsive maintainers, though.
Instead, we have opened the acls and orphaned packages for
non-responsiveness and people who are more interested in the package
have then taken over and done the work.



Yeah, the orphan policy seems to solve most of the problems that I can see.


-Toshio




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


All times are GMT. The time now is 04:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.