EPEL Orphaned packages with vulnerabilities

[Karel Volný]

Hi,

>>> There is now a security initiative to handle the outstanding security
>>> bugs.
>> 
>> that's cool that somebody cares
>> 
>> however, do you really think that users will appreciate this 
>> way of handling the bugs, i.e. removing important libraries instead
>> of patching them?
>
> If there is nobody that patches the library, I do not see how this is an
> option.

the key is this "if ..."

the person who cares about the security bugs could have been the one to 
patch - it is not uncommon that things are fixed by other people than the 
owner (e.g. qmmp, that is owned by me, got recently updated in F20 by Rex 
Dieter because of some PulseAudio stuff ..)

>>> ...
>> I've always thought that it works in the way that if package 
>> gets orphaned,
>> it simply won't make it into next version of the distribution, not that 
it
>> should get removed from the current version, causing regressions for 
users
>> ...? ...
>
> For me it is kind of common sense. Why should it be a good idea to ship
> packages with known vulnerabilities?

as said below - not to cause regressions by removing what users rely upon, 
because pros may overweight cons ... maybe not always "good" but often 
"less evil"

> As you can see from the long list of orphaned packages with known
> vulnerabilities, just orphaning packages in EPEL creates a dangerous
> situation where users installing packages from EPEL assume they are well
> taken care of, but in reality they are not.

I thought we've always advertised EPEL as "best effort", so I'd dismiss 
such assumptions as unfounded ... well, I know this is not nice, but I see 
it as the best (i.e. least bad) option, as we don't have the capacity to 
deal with every single problem in the (enterprise linux) world

this is the usual conflict between having things perfect but lack of them 
or having at least something - I often vote for the opposite, better 
nothing than something that makes the situation worse, but in this concrete 
case I *think* the better option is to have at least something ... MOD 
music is a niche market these days, but it used to be one of things I liked 
about linux that it's not just for the majority

> So I discussed this with others and retiring orphaned packages
> after a certain time seemed good to us.

okay, I believe you (and "others") know better than me, as I don't have 
enough insight into various aspects of the distribution (which doesn't mean 
that I couldn't express my objections :-))

what I'd like to see are clear rules for this, and a bit better process ...

> However, I did not intentionally retire a package that is depended upon, 
but
> since it is really easy to undo retirement in EPEL, I do not see much 
harm
> done.

so ... suppose someone will follow
http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages

but it won't fix the cves ... what now, will it get back anyways?

>>> So if you would like to have the package in EPEL, you need to find
>>> a maintainer or maintain it.
>> 
>> sorry, I just don't follow your logic
>> 
>> it wasn't me who did the action - why should I undo it?
>
> I really do not get what what is your motivation. You are a package
> maintainer with a package that depends on an orphaned library with
> security vulnerabilities. Why do you not want to fix this?

it's not my package and I don't want it to become mine

someone just put that "you want it back so you fix it", creating work for 
me (or someone else who'd want the same)

but I have enough things to do, I don't manage to give enough love to 
things I do maintain, I really don't want someone to create more work for 
me - I didn't want the package to be removed in the first place, if it 
wouldn't be removed, there would be no work to get it back ...

> First you wanted to get a better heads up, which I agree would have been
> better, but I do not see how this would have changed anything, because 
still
> nobody cares enough about libmodplug to unretire it and fix the security
> vulnerability.

what would have changed is that we wouldn't have broken dependencies and an 
user filing bug that would need (or "need") to be taken care of

the fact that "nobody cares" isn't something that can't be changed -

> Since you maintain a package that depends on it, you are
> the first candidate to do this.

together with xine maintainers ...

I'm not a good candidate, I'm not a programmer ... I understand the things 
enough to cherry pick a patch that can be applied directly, but I can 
hardly rewrite the patch for a different code of some old version, 
especially when I'm completely unfamiliar with the sources; probably I'd be 
able to handle it somehow in the end, but for a price of a lot of time that 
I'd need to use for other things (hey, I have a family waiting for me :-))

from what I understand from the bugzilla, everything got fixed upstream so 
rebase would be the least-effor solution that basically anyone (including 
me) could handle

however, we don't like to do rebases in EPEL ... would it be viable in this 
situation?

- at least on EL5 it would mean the need to rebuild the dependant packages 
... but we need to rebuild them anyways as the dependency became broken ...

K.

-- 
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol at jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."