EPEL Orphaned packages with vulnerabilities

[Till Maas]

On Thu, Aug 14, 2014 at 12:41:39PM +0200, Karel Volný wrote:

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

There was an libmodplug related update to fix the vulnerabilities in
RHEL 4, so at least for Red Hat the bugs are important enough to fix
them:
https://bugzilla.redhat.com/show_bug.cgi?id=728371

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

I agree that the communication should be improved, but this can only be
changed for future retirements. Nevertheless the past shows that it
would not have made a difference to whether or not the vulnerabilities
get fixed, since they still are not and I did not notice progress on the
other, announced packages.

Regards
Till