EPEL Orphaned packages with vulnerabilities

Till Maas opensource at till.name
Sun Aug 17 18:03:13 UTC 2014

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

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


More information about the epel-devel mailing list