Le mardi 24 mai 2011 à 12:45 +0200, nicolas vigier a écrit : > On Tue, 24 May 2011, Christiaan Welvaart wrote: > > > On Tue, 24 May 2011, Michael Scherer wrote: > > > >> I would keep this as a update after the release is out ( like they 4 > >> ruby cve, libzip one ( CVE-2011-0421 )) and others that came out since > >> yesterday. > >> > >> So maybe we could open bugs for this ? > > > >> There is 2 proposal : > >> - filling them on security, and have a saved search > > > > What do you mean by that, a security product? > > There is a component "Security" on bugzilla. > > > > >> - creating a tracker bug > >> > >> I would be in favor of the tracker bug : > >> - you can subscribe to it > >> - it will be clearer ( as bugfixes are not security so we may miss some > >> update to do ) > >> - it doesn't pollute the list of saved search > >> > >> But as pascal said, a tracker bug requires that each bug to be linked to > >> it, which is manual and error prone. > > > > I don't know much about bugzilla, but: > > - Add a keyword 'security' to all security bugs. > > (also manual and error prone?) > > We already have a security component. Would a keyword instead of a > component be better for this ?
What when we have more than 1 release ? I really think the security component is wrongly named. The bug is against a rpm package, be it a security or non security fix, and treating security fix differently than non security fixes add IMHO unneeded complexity to the process. > It is also manual, but a keywork is easier to remember than a tracker > bug number. That's a good point, I guess we can either place the link on bugzilla main page, or use named bugs, or something like that ? > Maybe we can also think about a mailing list to receive all security > bugs. It doesn't take non security related fix in account. Given the fact that there is no difference between the way we treat them ( ie, it is updates ), and given the fact than even later the difference will be between embargoed updates and the rest, I guess that a generic list for issue affecting a stable release would be better suited. But I am not sure it will help much, we need to think to the problem we try to solve, and the way I see it, it is twofold : - we need to have a list of thing to update ( security or not, doesn't matter now ) - we need a way to be aware of changes to the aformentioned list The solutions must : - be extensible with possibility of having a embargo in the future - be as automated as possible - be open to people that want to help - take in account that we will have more than 1 release, maybe more than 1 project Anybody see others constraints ? -- Michael Scherer
