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

[Michael Scherer]

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