Dominik 'Rathann' Mierzejewski wrote:
> My proposal is:
> 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.
I agree with this.
While I think it is important to provide compatibility packages to keep
older software running, in this case, we have old versions of Python that:
* should not be necessary to run software, software for Python n.m usually
runs just fine with the newer n.m+1,
* in fact, have it as an explicit non-goal to package things against them,
* contain the priceless "No security fixes will be applied.", which is an
entirely unacceptable attitude: at the very least, if someone files a bug
report with an explicit CVE against your package, you are supposed to at
least TRY to backport the fix for that CVE, and ask for help if you fail.
I comaintain the qt3 and kdelibs3 compat packages and do not want those
removed, but I actually go and fix all security vulnerabilities that I am
made aware of. I think that this should be the minimum standard to require
for all packages, even compat packages.
These python[23][1-9] packages are entirely unnecessary and should go away
ASAP.
> 2. A ticket may be opened to FESCo applying for an exception to the
> above. FESCo should most likely seek the advice of the Fedora
> Security Team in such cases.
What cases do you have in mind for the exceptions? The infamous old WebKit
versions that everything still depends on? (The old webkitgtk is now getting
dropped, Qt5WebKit will hopefully soon be upgraded to the new resurrected
version, and hopefully we can drop Qt4WebKit soon, but right now this is
still not fully sorted out.) Ideally, we'd just fix all our security
vulnerabilities. The WebKit mess is a case where it's not working though.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
