EPEL Orphaned packages with vulnerabilities

[Karel Volný]

>>>> Perhaps you can un-retire the package(s) and maintain them?
>> 
>> why should I fix things *you* broke?
>> 
> If Eric didn't a) orphan the package in the first place, or b) remove the
> package from the repository... why are you saying he broke it?

so, if he hasn't removed it himself but just asked someone else to remove 
it, he has no responsibility for the removal?

> All he did was say that these were orphaned packages which had other
> problems attached to them.

"all"? - perhaps you've missed the quote from the ticket I posted just a 
few lines above, which you've cut from the reply?

> In the future, please follow this process instead:
>
> 1) Find out who removed the package.

Till

> 2) Find out why they removed the package.

because Eric asked epel-releng

... now I don't understand what are these two good for?

> 3) If the package was removed because it was orphaned, unmaintained,

if I get the docs right, this is not a reason to remove a package - there's 
a difference between orphaning and retiring

> or not responding to CVE's

that might be a reason - but in my opinion, the harm done by the removal is 
in this concrete case (libmodplug, haven't examined the other cases) worse 
than if we'd keep the vulnerable version ...

this is desktop software, no important servers will end up in flames 
because of it; to compare, similar (stack corruption) issue exists in 
libtiff version shipped in RHEL5 yet I'm not aware that Red Hat would be 
planning to retire libtiff from RHEL5, while libtiff is by orders of 
magnitude more important (`yum remove libtiff` would take away half of my 
system, including e.g. java, cups or qemu ...)

> find a packager who can do so that the package can go back into EPEL or 
Fedora.

it shouldn't have gotten to the point when we talk about "go back"

the search should have been done *before* removing the package

there was no "ping, we're approaching this catastrophic scenario, isn't 
there someone able to handle this before I file request for removal?" and 
also I can't find any trace that it would consider also the dependent 
packages, giving their maintainers a chance to step in or at least rebuild 
before the removal, avoiding broken dependencies

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."