#1634 EOL and vulnerable software
Closed: Fixed 6 years ago Opened 7 years ago by rathann.

= phenomenon =
EOL software with known security vulnerabilities is making its way into Fedora as new packages. Should we allow this to pass review?

= background analysis =
What prompted me to open this ticket is the fact that a couple of EOL versions of python (python26 and python33) were [https://bugzilla.redhat.com/show_bug.cgi?id=1373487 recently] [https://admin.fedoraproject.org/pkgdb/package/rpms/python26/timeline accepted] into Fedora with package descriptions containing lines like "No security fixes will be applied." Both of these have known security vulnerabilities (for example, CVE-2014-4616 and CVE-2016-0772) which will not be fixed upstream.

= implementation recommendation =
1. Prevent EOL software with known security vulnerabilities from entering Fedora in the first place, i.e. make it a review bullet point (if the package is EOL it MUST NOT have any known security vulnerabilties). If existing packages are found to be EOL and have known security vulnerabilities, the vulnerability must either be patched by the maintainer (or otherwise handled, e.g. by switching to an actively maintained fork) or the package must be removed from Fedora.
2. A ticket may be opened to FESCo applying for an exception to the above. FESCo should most likely seek the advice of the [https://fedoraproject.org/wiki/Category:Security_Team Fedora Security Team] in such cases.


Also this ticket and the discussions revolving it originate from [https://fedorahosted.org/fpc/ticket/650 this fpc ticket] where I believe the comments there are important in determining the outcome of this decision.

As I packaged the mentioned packages (python26 and python33), I feel the need to explain several things:

These packages are not intended to be used as dependencies for other packages (such as we have some "compat" packages when another package needs an older version of a library), hence we want to stop people from requiring them, see https://fedorahosted.org/fpc/ticket/650 - as a result no software in Fedora will ever run on those.

These packages are not intended for production, although I'm aware that we cannot stop anybody from doing that. I've tried to make that clear from the description. If the description is not clear enough or it can be also mentioned at another more visible place, I'm very open to suggestions.

The only purpose of these packages is to be able to run your test suite on several Python versions at once. I see no security issues with that.

If someone opens a bug and says running their test suite brings security issues, I'm more than happy to help them. If someone opens a bug and says they need CVE XYZ fixed, I'll inform them again about the main purpose of these packages, but if the patch exists, I'd gladly accept it. I will not activelly go and seak for CVEs that I can patch and fix. "No security fixes will be applied" is not entirely true, it's a warning, I can reword it to "Security fixes will only be applied upon request" (which BTW is the way things work in Fedora for many other packages).

The benefits here outweigh the fact that those packages are EOL. Python developers are one of the main targets for Fedora and on Flock 2016 we (Python SIG and other interested parties) had a long discussion about this and putting alternate Python versions to Fedora was one of our main goals. The intention was also clearly stated on python-devel several times, the reviews were also announced there.

Also I would like to stress out that most of the people involved in this initiative have various other obligations today and they won't be able to attend the FESCo meeting, so if there is a plan to discuss this ticket today, I would propose to postpone it for the next meeting.

Yup, this isn't on the agenda for today. There was a brief discussion during the open floor but nothing substantial. Would be good if the interested parties could join next week's meeting though.

So, at the last meeting, we:

  • Got the maintainers for the eol upstream pythons to clarify that they will be following RHEL releases and thus applying security updates.
  • They will change the comments in the description for those python packages to something like "These packages exist to allow fedora developers to test against RHEL or other long term downstream supported pythons. They are not a full python stack and if you wish to run your applications with them, see RHEL/CentOS/UbuntuLTS"
  • Agreed I would draft something to add to the https://fedoraproject.org/wiki/Package_maintainer_responsibilities page.

This is my proposed addition:

Last line of support

  • When upstream is non responsive, or the package version(s) shipped by Fedora is explicitly not supported by upstream, it falls to the Package Maintainer(s) to maintain the package and perform all the functions that upstream projects normally take care of, such as security updates, porting to new library versions, fixing bugs, etc. In the event that this is too much burden, the Package Maintainer(s) are encouraged to orphan the package, and if no interested new maintainers cannot be found, retire it.

I will not be at the 2016-10-28 meeting, feel free to discuss or defer.

When upstream is non responsive, or the package version(s) shipped by Fedora is explicitly not supported by upstream, it falls to the Package Maintainer(s) to maintain the package and perform all the functions that upstream projects normally take care of, such as security updates, porting to new library versions, fixing bugs, etc. In the event that this is too much burden, the Package Maintainer(s) are encouraged to orphan the package, and if no interested new maintainers cannot be found, retire it.

This looks good to me.

So, at the last meeting, we:

Got the maintainers for the eol upstream pythons to clarify that they will be following RHEL releases and thus applying security updates.
They will change the comments in the description for those python packages to something like "These packages exist to allow fedora developers to test against RHEL or other long term downstream supported pythons. They are not a full python stack and if you wish to run your applications with them, see RHEL/CentOS/UbuntuLTS"

I saw a commit similar to this text has been committed to required pythonXY packages.

Agreed I would draft something to add to the https://fedoraproject.org/wiki/Package_maintainer_responsibilities page.

This is my proposed addition:
Last line of support

When upstream is non responsive, or the package version(s) shipped by Fedora is explicitly not supported by upstream, it falls to the Package Maintainer(s) to maintain the package and perform all the functions that upstream projects normally take care of, such as security updates, porting to new library versions, fixing bugs, etc. In the event that this is too much burden, the Package Maintainer(s) are encouraged to orphan the package, and if no interested new maintainers cannot be found, retire it.

+1 Looks good to me as well.

While I like the proposal above (+1), the original question was whether or not we want new packages with known security vulnerabilities to pass review. This is still not addressed.

While I like the proposal above (+1), the original question was whether or not we want new packages with known security vulnerabilities to pass review. This is still not addressed.

My takeaway was that FESCo would make a determination on a case-by-case basis, but if you feel we need to discuss it further, please add the meeting keyword.

Adding the meeting keyword so we can discuss this further and decide if there's anything further we wish to do here.

Metadata Update from @kevin:
- Issue tagged with: meeting

7 years ago

FESCo will hear any such future examples on a case-by-case basis. (For: +5, Against: 0, Abstain: 1)

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata