Re: RFC: allow new upstream into stable when it's the only way tofix security issues.
Joe Smith wrote: > How about if it meets the folowing critieria: > > 1. it has been in testing for 10 days (been in sid at least 20 days) This means the security hole was disclosed at least 20 days ago, probably more. > 2. Iff it fixes a critical security problem, uploaded to security (This > requires security team and/or stable RM approval). Requiring more manual action, give this at least a few days I'd say. So we're looking at leaving our users exploitable for the better part of a month, before we even release an update, in the *best case* under this procedure. I think we can generally expect that a package like Mozilla Firefox will take more than 10 days to get into testing, especially if we're in the middle of, say, a C++ transition. Also, its quite possible the maintainer convincing the security team to release the update, and then the security team actually doing so, could take another week (remember, Mozilla takes a while to autobuild, too). This could easily leave our users vulnerable for over a month. Is that really acceptable on today's Internet? It doesn't take long at all for exploit code to be written and released into the wild. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way tofix security issues.
On Tue, 2005-08-02 at 17:19 -0400, Joe Smith wrote: > I think the no new upstream versions is stable rule needs to be more > flexible anyway. I have seen times where EVERY SINGLE change except for the > version number have been backported. That is often the case where the new > release consists of nothing but the desired changes. In those cases it is > illogical not to just go with the new versions. But that's only possible when there were no releases in between. And those are probably rare cases anyway. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way tofix security issues.
How about if it meets the folowing critieria: 1. it has been in testing for 10 days (been in sid at least 20 days) 2. the version is sid is the same as in testing (the maintainer has not found problems in the ten days since it entered testing) 3. and has no RC bugs (no rc bugs reported in the ten days it has been in testing) 4. It fixes security or stability bugs (whose fixes would normally be backported) that cannot reasonably be backported. Then (at the discretion of the maintainer) it can be: 1. uploaded to stable-proposed-updates (it will only get in to stable with stable RM's approval) OR 2. Iff it fixes a critical security problem, uploaded to security (This requires security team and/or stable RM approval). This makes sure it is fairly stable, yet allows bugs in programs like mozilla (when the new upstream version should only be fixing bugs anyway). -- I think the no new upstream versions is stable rule needs to be more flexible anyway. I have seen times where EVERY SINGLE change except for the version number have been backported. That is often the case where the new release consists of nothing but the desired changes. In those cases it is illogical not to just go with the new versions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
