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

Re: NMU rules for security fixes (was: DEP1: Clarifying policies and workflows for Non Maintainer Uploads)

On 25/04/08 at 18:32 +0200, Nico Golde wrote:
> What about introducing a special case regarding the waiting 
> period before uploading an NMU for security bugs? There are 
> often cases in which we already have a patch handy to fix a 
> security issue but still wait a few days on the maintainers 
> reaction.

On 26/04/08 at 20:22 +0200, Thijs Kinkhorst wrote:
> On Saturday 26 April 2008 02:07, Don Armstrong wrote:
> > On Sat, 26 Apr 2008, Paul Wise wrote:
> > > I'd prefer the security team did not delay fixes at all by default.
> > > Exceptions for specific maintainers, transitions or other reasons
> > > are fine too of course.
> >
> > For stable and testing, I agree. However, for unstable and
> > experimental the maintainer should be at least given a chance to
> > resolve the issue. [That is to say, I object to filing a bug and
> > immediately NMUing for unstable; in almost all cases the bug should be
> > a few days old before that happens.]
> I agree with that. The cases where the available "patch" for a security issue 
> was insufficient or broke other things are not quite rare. The maintainer of 
> a package is the first one responsible for it and should be given the 
> opportunity to comment on the patch and/or apply it himself. At least a few 
> days, and of course depending on the impact of the bug: no need to rush in 
> patches for low impact bugs.

I don't think that developers-reference is the good place to list
all the special cases. In the DEP, we include some example delays:
| While there are no general rules, it's recommended to upload to the
| DELAYED queue with a delay of at least a few days. Here are some
| examples that you could use as default values:
| # Upload fixing only release-critical bugs older than 7 days: 2 days
| # Upload fixing only release-critical and important bugs: 5 days
| # Other NMUs: 10 days

Those are example delays, not mandatory ones. If the uploader thinks
that he has a good reason to wait less time, he can still wait less

I've added this sentence after the above examples to clarify this:
| Those delays are only examples. In some cases (uploads fixing security
| issues, trivial bugfixes blocking a transition, ...), it is desirable
| that the fixed package reaches unstable sooner.
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |

Attachment: signature.asc
Description: Digital signature

Reply to: