-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I just did a query of all the packages in EPEL that are currently orphaned and contain vulnerabilies. I'm wondering if any of them are still useful or if they can be removed from the repos. Here's the list:
couchdb - epel-all ejabberd - epel-5 erlang - epel-5 horde - epel-all libmodplug - epel-5 and epel-6 libupnp - epel-all mantis - epel-5 maradns - epel-5 mediawiki - epel-5 mediawiki116 - epel-all mod_wsgi - epel-5 moin - epel-5 openjpeg - epel-5 osc - epel-6 php-magpierss - epel-all php-suhosin - epel-all pki-common - epel-5 polipo - epel-all python26-mod_wsgi - epel-5 python26-simplejson - epel-5 qemu - epel-5 revelation - epel-5 telepathy-gabble - epel-6 tigase-server - epel-all torque - epel-all wordpress-mu - epel-5 xinha - epel-5 zope - epel-5
Some of the vulnerabilities on these packages are quite serious. I just don't know if any of these packages are still necessary and if they are how we can get them adopted and updated to remove the vulnerabilities.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Fedora Project
sparks@fedoraproject.org - sparks@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On 08/06/2014 12:32 PM, Eric H. Christensen wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I just did a query of all the packages in EPEL that are currently orphaned and contain vulnerabilies. I'm wondering if any of them are still useful or if they can be removed from the repos. Here's the list:
big list deleted
Random thought - have a "remove-insecure-packages" package that obsoletes dead packages with known vulnerabilities? People could perhaps exclude that package from yum updates if they really want to keep old stuff around.
On Wed, Aug 06, 2014 at 03:48:14PM -0600, Orion Poplawski wrote:
Random thought - have a "remove-insecure-packages" package that obsoletes dead packages with known vulnerabilities? People could perhaps exclude that package from yum updates if they really want to keep old stuff around.
In Debian oldstable there is a check-support-status script that shows which installed packages are currently supported, IMHO this would be a nice addition, maybe with a daily cron job that sends an e-mail or a yum plugin that shows this when checking for updates. This is something I would like more that removing packages automatically, since the package is usually installed for a reason.
Regards Till
6.8.2014 21.32, Eric H. Christensen kirjoitti:
I just did a query of all the packages in EPEL that are currently orphaned and contain vulnerabilies. I'm wondering if any of them are still useful or if they can be removed from the repos. Here's the list:
If you are concerned about orphaned and vulnerable packages, please remove openstack-nova as well. Even though it isn't marked as orphaned in the pkgdb, the package maintainer is apparently not going to fix the vulnerabilities. openstack-nova has been requested to be removed in one of the comments for the following bugs, but nothing has happened. I consider the package "de facto" orphaned.
https://bugzilla.redhat.com/show_bug.cgi?id=956808 /var/log/nova/ is world readable
https://bugzilla.redhat.com/show_bug.cgi?id=961736 CVE-2013-2030 insecure directory creation for signing
https://bugzilla.redhat.com/show_bug.cgi?id=963728 CVE-2013-2096 fails to verify image virtual size denial of service
https://bugzilla.redhat.com/show_bug.cgi?id=994810 CVE-2013-2256 private flavors resource limit circumvention
https://bugzilla.redhat.com/show_bug.cgi?id=994817 CVE-2013-4185 network source security groups denial of service
https://bugzilla.redhat.com/show_bug.cgi?id=995173 CVE-2013-4179 XML entities DoS
https://bugzilla.redhat.com/show_bug.cgi?id=999277 CVE-2013-4261 console-log DoS
https://bugzilla.redhat.com/show_bug.cgi?id=1040789 CVE-2013-7048 insecure directory permissions in snapshots
https://bugzilla.redhat.com/show_bug.cgi?id=1057311 CVE-2013-7130 Live migration can leak root disk into ephemeral storage
https://bugzilla.redhat.com/show_bug.cgi?id=1119585 CVE-2013-6437 DoS through ephemeral disk backing files
https://bugzilla.redhat.com/show_bug.cgi?id=1119632 CVE-2014-0134 Nova host data leak to vm instance in rescue mode
https://bugzilla.redhat.com/show_bug.cgi?id=1120951 CVE-2014-3517 timing attack issue allows access to other instances' configuration information
Hi,
I just did a query of all the packages in EPEL that are currently orphaned and contain vulnerabilies. I'm wondering if any of them are still useful or if they can be removed from the repos. Here's the list:
...
libmodplug - epel-5 and epel-6
...
sooo ... these got removed without any further notice?
since Sunday, I'm getting reports about broken dependencies of qmmp - it misses libmodplug
and seems users miss it too: https://bugzilla.redhat.com/show_bug.cgi?id=1128121
K.
sooo ... these got removed without any further notice?
um ... https://bugzilla.redhat.com/show_bug.cgi?id=728374#c3
submitted on 2014-08-06 14:35:20 EDT
from e-mail:
Received: by localhost.localdomain (Postfix, from userid 1000) id 958FD221E7E; Wed, 6 Aug 2014 14:32:31 -0400 (EDT)
the package got removed three minutes after sending the email stating "I'm wondering if any of them are still useful or if they can be removed from the repos."
you really haven't wondered for too long, now, in the middle of summer when folks are on vacations, did you?
:-(
K.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, Aug 11, 2014 at 03:31:56PM +0200, Karel Volný wrote:
you really haven't wondered for too long, now, in the middle of summer when folks are on vacations, did you?
Which folks, exactly? These were all orphaned packages so no one was working on them.
I requested releng to do *something* and the something they did was to retire the package. In response to that I closed all the tickets that were still open for that package. Perhaps you can un-retire the package(s) and maintain them?
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Fedora Project
sparks@fedoraproject.org - sparks@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
you really haven't wondered for too long, now, in the middle of summer when folks are on vacations, did you?
Which folks, exactly?
so, you want me to append the list of Flock attendants for example, or what is this question about?
These were all orphaned packages so no one was working on them.
are you trying to imply that only package owners can be interested in what happens with those packages?
- I guess the broken dependencies and the bugreport I've mentioned earlier prove the exact opposite
I requested releng to do *something* and the something they did was to retire the package.
don't be alibistic
"Could someone update this package or *remove* the package from the repos?" doesn't sound just like "something"
In response to that I closed all the tickets that were still open for
that
package.
I just wonder, if these had been opened for three years, why there was so great urgency to close the bugs now, immediately?
now I see you even filed the ticket *before* sending out the email ... is this how the "collaboration" works today, you "just don't know" but act before anyone has even the chance to answer?
Perhaps you can un-retire the package(s) and maintain them?
why should I fix things *you* broke?
K.
Please remember that EPEL falls under the Fedora Code of Conduct too. Let's assume that everyone is operating in good faith, and if something was done too hastily, it wasn't _malicious_ -- just someone trying to get things done. It also seems unlikely that there is irreparable harm here. Let's be constructive and get this worked out without making it personal. Thank you.
On Mon, Aug 11, 2014 at 04:58:17PM +0200, Karel Volný wrote:
In response to that I closed all the tickets that were still open for
that
package.
I just wonder, if these had been opened for three years, why there was so great urgency to close the bugs now, immediately?
There is now a security initiative to handle the outstanding security bugs.
Perhaps you can un-retire the package(s) and maintain them?
why should I fix things *you* broke?
Please calm down. If the package and its dependencies should stay in EPEL, they need to be maintained. So if you would like to have the package in EPEL, you need to find a maintainer or maintain it.
Regards Till
Hi,
...
There is now a security initiative to handle the outstanding security bugs.
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?
Perhaps you can un-retire the package(s) and maintain them?
why should I fix things *you* broke?
Please calm down. If the package and its dependencies should stay in EPEL, they need to be maintained.
probably my Google is broken, but I cannot find where this is set in stone?
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 it should get removed from the current version, causing regressions for users ...?
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?
K.
On Thu, Aug 14, 2014 at 11:54:59AM +0200, Karel Volný wrote:
There is now a security initiative to handle the outstanding security bugs.
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 option.
Perhaps you can un-retire the package(s) and maintain them?
why should I fix things *you* broke?
Please calm down. If the package and its dependencies should stay in EPEL, they need to be maintained.
probably my Google is broken, but I cannot find where this is set in stone?
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 it should get removed from the current version, causing regressions for users ...?
For me it is kind of common sense. Why should it be a good idea to ship packages with known vulnerabilities? 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. So I discussed this with others and retiring orphaned packages after a certain time seemed good to us. However, I did not intentionally retire a package that is depended upon, but since it is really easy to undo retirement in EPEL, I do not see much harm done.
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? 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 still nobody cares enough about libmodplug to unretire it and fix the security vulnerability. Since you maintain a package that depends on it, you are the first candidate to do this.
Regards Till
Hi,
There is now a security initiative to handle the outstanding security bugs.
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 option.
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
it
should get removed from the current version, causing regressions for
users
...? ...
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 "less evil"
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,
but
since it is really easy to undo retirement in EPEL, I do not see much
harm
done.
so ... suppose someone will follow http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requ...
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
still
nobody cares enough about libmodplug to unretire it and fix the security vulnerability.
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 situation?
- 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 ...
K.
On Tue, Aug 19, 2014 at 03:02:27PM +0200, Karel Volný wrote:
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 ..)
Yes, it is not necessarily the maintainer that needs to take care of stuff, but the maintainer should at least ask for help or coordinate this.
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
so ... suppose someone will follow http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requ...
but it won't fix the cves ... what now, will it get back anyways?
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 situation?
- 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 ...
Yes, a simple rebase will help here and is IMHO applicable here, since it is the lesser evil. It is not necessarily necessary to rebuild the dependent packages, if libmodplug did not change too much. Therefore in this case, I would consider it pretty irresponsible to just get libmodplug back in the state it is without taking care of the easy to fix vulnerabilities.
Regards Till
Hi,
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 ...
Yes, a simple rebase will help here and is IMHO applicable here, since it is the lesser evil.
ok, I've tried to just bump the version and it seems to work, so I've filed new SCM admin request (bug #1133548, as I couldn't find the original review)
what's next, suppose I have to wait until it is processed, then clone the repo and proceed with the update as usual, then step 6. "Request that Release Engineering team unblock the package for the current release, via their trac instance" ...?
It is not necessarily necessary to rebuild the dependent packages, if libmodplug did not change too much.
the so version did not change, so let's hope for the best
I mean EL6 ... still not sure what about EL5 ...
K.
On 11 August 2014 08:58, Karel Volný kvolny@redhat.com wrote:
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? All he did was say that these were orphaned packages which had other problems attached to them.
In the future, please follow this process instead:
1) Find out who removed the package. 2) Find out why they removed the package. 3) If the package was removed because it was orphaned, unmaintained, or not responding to CVE's find a packager who can do so that the package can go back into EPEL or Fedora.
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:
- Find out who removed the package.
Till
- Find out why they removed the package.
because Eric asked epel-releng
... now I don't understand what are these two good for?
- 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.
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
On 08/06/2014 07:32 PM, Eric H. Christensen wrote:
I just did a query of all the packages in EPEL that are currently orphaned and contain vulnerabilies. I'm wondering if any of them are still useful or if they can be removed from the repos. Here's the list:
couchdb - epel-all ejabberd - epel-5 erlang - epel-5 horde - epel-all libmodplug - epel-5 and epel-6 libupnp - epel-all mantis - epel-5 maradns - epel-5 mediawiki - epel-5 mediawiki116 - epel-all mod_wsgi - epel-5 moin - epel-5 openjpeg - epel-5 osc - epel-6 php-magpierss - epel-all php-suhosin - epel-all pki-common - epel-5 polipo - epel-all python26-mod_wsgi - epel-5 python26-simplejson - epel-5 qemu - epel-5 revelation - epel-5 telepathy-gabble - epel-6 tigase-server - epel-all torque - epel-all wordpress-mu - epel-5 xinha - epel-5 zope - epel-5
mongodb wasn't listed above, but it was retired as part of: https://fedorahosted.org/rel-eng/ticket/5963
Now RDO for example fails to install in its default setup.
Was mongo retired in error?
thanks, Pádraig.
On Mon, Aug 11, 2014 at 04:52:11PM +0100, Pádraig Brady wrote:
On 08/06/2014 07:32 PM, Eric H. Christensen wrote:
I just did a query of all the packages in EPEL that are currently orphaned and contain vulnerabilies. I'm wondering if any of them are still useful or if they can be removed from the repos. Here's the list:
couchdb - epel-all
mongodb wasn't listed above, but it was retired as part of: https://fedorahosted.org/rel-eng/ticket/5963
Now RDO for example fails to install in its default setup.
Was mongo retired in error?
Sorry, I confused it with couchdb. I undid my changes as far as I could and strobert is now the point-of-contact for EPEL 6. Do you know whether or not it was orphaned previously on EPEL 5 and 6? Nevertheless, it needs to be adopted in EPEL 5 to not be retired again, but strobert wrote it might not be worth maintaining it in EPEL 5 without bumping its release.
Regards Till
epel-devel@lists.fedoraproject.org
-
Anssi Johansson -
Eric Christensen -
Karel Volný -
Matthew Miller -
Orion Poplawski -
Pádraig Brady -
Stephen John Smoogen -
Till Maas