EPEL Orphaned packages with vulnerabilities
kvolny at redhat.com
Tue Aug 19 13:02:27 UTC 2014
>>> There is now a security initiative to handle the outstanding security
>> 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
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
>> should get removed from the current version, causing regressions for
>> ...? ...
> 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
> 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,
> since it is really easy to undo retirement in EPEL, I do not see much
so ... suppose someone will follow
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
> nobody cares enough about libmodplug to unretire it and fix the security
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
- 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 ...
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."
More information about the epel-devel