[Mageia-dev] slight security improvement: should we update aria2 to 1.11.2?

Tue May 24 13:52:48 CEST 2011

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
+
+