Red Hat Bugzilla – Bug 824089
CVE-2011-2082 rt3: Multiple security flaws fixed in upstream v3.8.12 and v4.0.6 versions [epel-all]
Last modified: 2015-06-08 11:32:19 EDT
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected Fedora
For comments that are specific to the vulnerability please use bugs filed
against "Security Response" product referenced in the "Blocks" field.
For more information see:
When creating a Bodhi update request, please include this bug ID and the
bug IDs of this bug's parent bugs filed against the "Security Response"
product (the top-level CVE bugs). Please mention the CVE IDs being fixed
in the RPM changelog when available.
Bodhi update submission link:
Please note: this issue affects multiple supported versions of Fedora EPEL.
Only one tracking bug has been filed; please ensure that it is only closed
when all affected versions are fixed.
[bug automatically created by: add-tracking-bugs]
This bug is VERY old, do we have an udpate/patch for this?
[Fedora maintainer speaking - I do not maintain rt in EPEL]
(In reply to David A. Cafaro from comment #1)
> This bug is VERY old, do we have an udpate/patch for this?
None that I am aware of. rt3 was abandoned upstream.
In Fedora >= 21, rt3 has been replaced with rt4 (rt-4.2.x) and is effectively abandoned/dead in Fedora 20. It's only still present in F20, because I missed to EOL it in time before F20 was released and because packages can't be removed from Fedora after release.
I do not think trying to backport the changes from rt4 or trying to develop actual bug-fixes is feasible (checking other distros could be worth a try, though).
Instead I'd recommend to remove rt3 from all EPELs and - should there be sufficient interest - somebody to try adding rt4 (4.0.x or 4.2.x) to EPEL. However, due to the long chain of deps on (modern) perl-modules and CentOS/RHEL's packaging policies, I would expect this to be a challenging, almost impossible task.
Thanks for the update and info. I'll take this back to the Security Team and see how we want to handle this. We have been working on policy to have packages that are abandoned removed so that's less of an issue than the dependency worries (which will take some thought).