EPEL Orphaned packages with vulnerabilities

[Eric Christensen]

-----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(a)fedoraproject.org - sparks(a)redhat.com
097C 82C3 52DF C64A 50C2  E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQGcBAEBCgAGBQJT4nS8AAoJEB/kgVGp2CYvGcgL/3/GImrTGYkZSyPFWdXxJQ6e
> 4bzOXPzR0PTXoLanwrwTqTPUb0sWfanx4wOgVjSfjlnsS9oyNcDtH74tLJ6CWmBi
> NsXQrQ4YPy+YZWrvePMJC7cRDfn7FOcMzdyOiZ28TdnS412IraK1gBwr2bOEZ239
> HZSjLyI3TFgw7xfAuzIoZj0e5bzZlf/rFfjmXm3gE9le6CvCPsoCKPSqZNG6JB0H
> h8KsLYGCuZYwpwm1MaHhlygH51dUUuooXnh5Pj143+T/vki8cldxkkjl5eRyepoY
> mcRuDzLvtQI0MdwsRAENL/JS9RboI7gxE9wWLJHKRpxrmm6v6g2RwH7w7oWo2fv3
> OnB40p3qbdhvOvXbT5ndpwawEkXGrqsn/fJIcWtCSB/wwQepDMjlI4vX0fkS9DUe
> Ou6706mEXM6sEVh4IOFpGCq4jvsYphrWoFL+4fIdG9iVeG6QP+qeMpruTE5n8TaU
> uYBPUPEp51tA4/kei/bQgeHLW2MKP53RvjArBPakNA==
> =9Mbh
> -----END PGP SIGNATURE-----

[Orion Poplawski]

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.


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: [phone]
3380 Mitchell Lane                       orion(a)nwra.com
Boulder, CO 80301                   http://www.nwra.com

[Till Maas]

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

[Anssi Johansson]

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

[Karel Volný]

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.

-- 
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. [phone]
(RH: [phone] ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."

[Karel Volný]

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

-- 
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. [phone]
(RH: [phone] ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."

[Eric Christensen]

-----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(a)fedoraproject.org - sparks(a)redhat.com
097C 82C3 52DF C64A 50C2  E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQGcBAEBCgAGBQJT6MqbAAoJEB/kgVGp2CYvY8sL/Aq3152EW8bZnu+kVao5wTpZ
> FkYLsgD10ZjjzmtWuYmFhD8WYdxMyDHzuWpqKeqsSqdPdx5UeQ0Pj6MzEgIe4fRm
> BhIIXZi/bE1bFjCmPT6qfmZgISvEqbz9gyy1oxK2awnxmLYbW/BSmufBNOiWDRzi
> XnNtwTwoGO4XbapAIKN1zpVRxFGPpTv4vErvwbJGK1AoUcxqUpHis4sfLGwE2jy+
> KKUOeCK3UCqV5D1r+3MRC4DuckdUBoDrio6ttZBufjIsLXmVVzSd4kZlYD0e69Wb
> FlUKg5d0OAiRHCClHJ8JMfE04pb16rvRHvpGxGGa6TZYdrkbt0h2yPlkwbxf4FFM
> AUJpaccW1JI7XZN+cpO0Q1eWDGpr4pjXqDki9ai+xkYHEAORD/ckAi8RYbZAs6qv
> rIQKNgLeKKouM2NM4o0fbxitgQ9bfdJNgRXueY4quWED2eKWUdIs43im2qtIZNJN
> V5XkuPzYMewps1Ie+9iK7bnFjmzLfiJccoLFprxjvQ==
> =OQuI
> -----END PGP SIGNATURE-----

[Karel Volný]

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

-- 
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. [phone]
(RH: [phone] ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."

[Matthew Miller]

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.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Till Maas]

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

[Karel Volný]

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.

-- 
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. [phone]
(RH: [phone] ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."

[Till Maas]

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

[Karel Volný]

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

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.

-- 
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. [phone]
(RH: [phone] ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."

[Till Maas]

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

EPEL libmodplug unretirement [was: Re: Orphaned packages with vulnerabilities]

[Karel Volný]

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.

-- 
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. [phone]
(RH: [phone] ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."

[Stephen John Smoogen]

On 11 August 2014 08:58, Karel Volný <kvolny(a)redhat.com&gt; 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.

-- 
Stephen J Smoogen.

[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. [phone]
(RH: [phone] ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."

[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

[Pádraig Brady]

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.

[Till Maas]

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