On Friday, 07 October 2016 at 19:35, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Oct 07, 2016 at 06:43:10PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > Dear All, > > I was made aware that EOL software with known security bugs that will > > not be fixed upstream (due to EOL status) was reviewed and accepted into > > Fedora recently. This came on the back of the FPC ticket [1] asking to > > make some changes in the Python Packaging Guidelines. I did go back and > > re-read our current guidelines and found that we don't have any policy > > on that. As a result, I opened a FESCo ticket [2] with the aim of > > establishing a clear policy on how to treat EOL software with known > > security vulnerabilities. > > A parallel could be drawn between previous python versions and > previous C standards, like c89, c90, c99, etc. One could say that they > are obsolete, but it is still very convenient to be able to add > CFLAGS=-ansi. gcc is a bit of a special case IMHO. It's rarely installed on servers, especially Internet-facing ones. The only runtime component is libgcc, which is fairly small and even if you're using an application binary compiled with an ancient gcc because it won't compile with a newer one, any vulnerabilities will more likely come from that application than from gcc itself. > The difference is that gcc has this built in, while > python does not have compatibility with previous "standards", so the > only way to test with previous versions is to run those previous > versions. It's damn useful for testing, and it's much more convenient > to do it through dnf install than through > virtualization/containers/cloud/hand-compilation/copr/other-nonstandard-things. > > So from my side, a vote for > 1. labelling old pythons very clearly as such, How do you propose we do that? I can imagine patching the interpreter to print some warning about this every time it's run, but I wonder if that's too much to ask. > 2. allowing people to install them using dnf. I am not denying the usefulness, though I wonder why you would want to test against an unmaintained branch. I can see a case for python-2.6, which will be maintained by Red Hat for a couple more years and I'd expect the Fedora maintainer to either be the same person who maintains it in RHEL or that they follow the RHEL package closely otherwise. I can't find python3 in RHEL, so the above doesn't hold for python3.x. Also, your point 2. is achievable through COPR. However, my point is a more general one, that's why I'm asking our security team for their thoughts as well. You'll notice that I purposefully propose to leave a way for such packages to enter Fedora anyway after their risks and benefits have been reviewed by FESCo and/or FST. I hope you'll agree that such packages deserve greater scrutiny. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
