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