including EOL and vulnerable software in Fedora
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. 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. 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. Please read comments in both referenced tickets to avoid repeating arguments which were given already. References: [1] https://fedorahosted.org/fpc/ticket/650 [2] https://fedorahosted.org/fesco/ticket/1634 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
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. 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, 2. allowing people to install them using dnf. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On 8 October 2016 at 23:13, Kevin Kofler wrote: > These python[23][1-9] packages are entirely unnecessary and should go away > ASAP. They're not unnecessary for Python developers, as if you want to make sure you're not accidentally using any features from later versions of Python, the only way to reliably check that is to actually test your code on those older versions. Tools like "tox" make that relatively easy to do, but you still need a straightforward way to get hold of the old runtimes for tox to use. The addition of these packages to Fedora means that as soon as you do "dnf install tox", those runtimes are all brought in automatically via Recommends, rather than having to jump through multiple hoops to reconfigure your local package management. For the specific case of Python though, it would be better if the EOL upstream versions were built from the CentOS SRPMs (which *do* get security fixes) rather than directly from the upstream tarballs (in addition to Python 2.6 RPMs that mirror those in CentOS 6.x, it'd be nice to have the patched Python 2.7.5 release from CentOS 7.x readily available for compatibility testing as well). So +1 from me for the general premise of this thread - if we're going to include EOL software, that should be treated as a special case requiring approval from FESCo, and we should try to find a source for that software where it *isn't* EOL (even if that means inverting the traditional dependency flow between Fedora and RHEL/CentOS). However, I'm also a strong +1 for making tox work well by default in Fedora, and that means providing widely used Python runtime versions, even if they're officially EOL upstream and now only supported by redistributors. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On Sat, Oct 8, 2016 at 11:42 PM, Nick Coghlan wrote: > On 8 October 2016 at 23:13, Kevin Kofler wrote: >> These python[23][1-9] packages are entirely unnecessary and should go away >> ASAP. > > They're not unnecessary for Python developers, as if you want to make > sure you're not accidentally using any features from later versions of > Python, the only way to reliably check that is to actually test your > code on those older versions. Tools like "tox" make that relatively > easy to do, but you still need a straightforward way to get hold of > the old runtimes for tox to use. The addition of these packages to > Fedora means that as soon as you do "dnf install tox", those runtimes > are all brought in automatically via Recommends, rather than having to > jump through multiple hoops to reconfigure your local package > management. > > For the specific case of Python though, it would be better if the EOL > upstream versions were built from the CentOS SRPMs (which *do* get > security fixes) rather than directly from the upstream tarballs (in > addition to Python 2.6 RPMs that mirror those in CentOS 6.x, it'd be > nice to have the patched Python 2.7.5 release from CentOS 7.x readily > available for compatibility testing as well). > > So +1 from me for the general premise of this thread - if we're going > to include EOL software, that should be treated as a special case > requiring approval from FESCo, and we should try to find a source for > that software where it *isn't* EOL (even if that means inverting the > traditional dependency flow between Fedora and RHEL/CentOS). > > However, I'm also a strong +1 for making tox work well by default in > Fedora, and that means providing widely used Python runtime versions, > even if they're officially EOL upstream and now only supported by > redistributors. > Why in the main repository? Why not just put them in a COPR instead? The main repository provides a very specific promise that I don't think we can keep with these EOL packages (that the software is trustable, useful, and dependable). -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
Nick Coghlan wrote: > They're not unnecessary for Python developers, as if you want to make > sure you're not accidentally using any features from later versions of > Python, the only way to reliably check that is to actually test your > code on those older versions. Tools like "tox" make that relatively > easy to do, but you still need a straightforward way to get hold of > the old runtimes for tox to use. The addition of these packages to > Fedora means that as soon as you do "dnf install tox", those runtimes > are all brought in automatically via Recommends, rather than having to > jump through multiple hoops to reconfigure your local package > management. That contradicts churchyard's claim in the FESCo tracker: | 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. I would also like to point out that if you have these suffixed Python versions installed, some build scripts may be accidentally picking up those instead of the recommended default versions of Python. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
Dne 9.10.2016 v 05:42 Nick Coghlan napsal(a): > On 8 October 2016 at 23:13, Kevin Kofler wrote: >> These python[23][1-9] packages are entirely unnecessary and should go away >> ASAP. > They're not unnecessary for Python developers, as if you want to make > sure you're not accidentally using any features from later versions of > Python, the only way to reliably check that is to actually test your > code on those older versions. While I understand you want to test against older pythons, I don't understand how you would do that, since I don't believe that "just" older python is enough. You typically need also some additional libraries. Therefore I'm afraid this won't stop just with older python, but will continue with another set of packages. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On Mon, Oct 10, 2016 at 10:29 AM, Vít Ondruch wrote: > > > Dne 9.10.2016 v 05:42 Nick Coghlan napsal(a): >> On 8 October 2016 at 23:13, Kevin Kofler wrote: >>> These python[23][1-9] packages are entirely unnecessary and should go away >>> ASAP. >> They're not unnecessary for Python developers, as if you want to make >> sure you're not accidentally using any features from later versions of >> Python, the only way to reliably check that is to actually test your >> code on those older versions. > > While I understand you want to test against older pythons, I don't > understand how you would do that, since I don't believe that "just" > older python is enough. You typically need also some additional > libraries. Therefore I'm afraid this won't stop just with older python, > but will continue with another set of packages. I think pip should be used for that along with/without virtalenv. > > > Vít > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
This seems highly unlikely Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Kevin Kofler" To: devel@lists.fedoraproject.org Sent: Sunday, October 9, 2016 5:39:00 PM Subject: Re: including EOL and vulnerable software in Fedora I would also like to point out that if you have these suffixed Python versions installed, some build scripts may be accidentally picking up those instead of the recommended default versions of Python. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On 10/07/2016 06:43 PM, Dominik 'Rathann' Mierzejewski wrote: 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. Fedora relies on EOLed components pretty much across the system (including critical security functionality), so one more such package really isn't the end of the world. I think new packages should not be held to tremendously higher standards than existing packages. Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
- Original Message - From: "Kevin Kofler" To: devel@lists.fedoraproject.org Sent: Saturday, October 8, 2016 3:13:10 PM Subject: Re: including EOL and vulnerable software in Fedora > * should not be necessary to run software, software for Python n.m usually > runs just fine with the newer n.m+1, Not really. >* 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. That is also not true. I encourage you and everyone who makes these claims to go read the tickets. If people's issues is just the CVE's, and then everything will be fine, we can go and fix all the CVE's discovered so far. The thing that people do not seem to understand here, is that these packages are not supported anymore upstream (as so many other packages in Fedora), and this is what is stressed out in the description of the packages. > These python[23][1-9] packages are entirely unnecessary and should go away > ASAP. Again I suggest you read the tickets before making these assumptions. Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On Monday, 10 October 2016 at 11:07, Florian Weimer wrote: > On 10/07/2016 06:43 PM, Dominik 'Rathann' Mierzejewski wrote: > > > 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. > > Fedora relies on EOLed components pretty much across the system (including > critical security functionality), so one more such package really isn't the > end of the world. I think new packages should not be held to tremendously > higher standards than existing packages. I think times have changed enough to warrant this at least for new packages. I don't think it's acceptable to simply allow adding known-to-be-vulnerable software to our package repositories without additional review anymore. 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
- Original Message - From: "Dominik 'Rathann' Mierzejewski" To: devel@lists.fedoraproject.org, python-de...@lists.fedoraproject.org Sent: Friday, October 7, 2016 9:23:51 PM Subject: Re: including EOL and vulnerable software in Fedora > 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. This is possible. > 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. That holds true for the Fedora maintainer(s) of these packages, I don't know why you would assume otherwise. Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On Mon, Oct 10, 2016 at 11:32:43AM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 10 October 2016 at 11:07, Florian Weimer wrote: > > On 10/07/2016 06:43 PM, Dominik 'Rathann' Mierzejewski wrote: > > > > > 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. > > > > Fedora relies on EOLed components pretty much across the system (including > > critical security functionality), so one more such package really isn't the > > end of the world. I think new packages should not be held to tremendously > > higher standards than existing packages. > > I think times have changed enough to warrant this at least for new > packages. I don't think it's acceptable to simply allow adding > known-to-be-vulnerable software to our package repositories without > additional review anymore. History has shown that it is safe to assume that every single non-trivial application contains multiple security vulnerabilities, at all times. We may not have found them yet, but you can certainly bet there are some there. If you have 2 packages proposed for Fedora, one with known security bugs, and one without, this does not imply that the former is less secure / more dangerous for Fedora. It almost certainly just means that no one has looked for security bugs in the other piece of "bug free" software. In some ways the piece of software with known security bugs may be considered better, because it is a sign that it has actually had some attention from security researchers, and users of it have information to evaluate whether their usage scenario is actually at risk or not. So IMHO a rule that forbids addition of software with known security bugs is far too crude a hammer and would just give us a false sense of security. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On 10/09/2016 05:39 PM, Kevin Kofler wrote: Nick Coghlan wrote: They're not unnecessary for Python developers, as if you want to make sure you're not accidentally using any features from later versions of Python, the only way to reliably check that is to actually test your code on those older versions. Tools like "tox" make that relatively easy to do, but you still need a straightforward way to get hold of the old runtimes for tox to use. The addition of these packages to Fedora means that as soon as you do "dnf install tox", those runtimes are all brought in automatically via Recommends, rather than having to jump through multiple hoops to reconfigure your local package management. That contradicts churchyard's claim in the FESCo tracker: | 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. Indeed, there's a disconnect here. The old Pythons are intended for *upstream* development/testing. If you're developing for Fedora, the old Pythons are not for you. They're for people who are developing cross-platform libraries, which for some reason need backwards compatibility: usually for deployment elsewhere (old RHEL, old Debian – I've even seen people that need an old Python for Symbian phones, though that's older than we can support in Fedora). And if you're developing a cross-platform library, you don't *want* your dependencies to come form RPMs. They need to be installable from PyPI (the Python-specific package repository) so you can use them on any distro. So, the older Pythons should come with virtualenv & Pip, but a RPM ecosystem around them would be useless. The people this is for want to develop compatible libraries for Python. They don't really care for the OS underneath. But having the old Pythons easily installable provides an incentive for them to choose Fedora. The resulting upstream libraries can then be packaged as RPMs with Fedora's normal Python. I would also like to point out that if you have these suffixed Python versions installed, some build scripts may be accidentally picking up those instead of the recommended default versions of Python. Do you mean Fedora build scripts here? -- Petr Viktorin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
Petr Viktorin wrote: > Indeed, there's a disconnect here. The old Pythons are intended for > *upstream* development/testing. Your explanation does not solve the inherent contradiction between: >> churchyard (in the FESCo tracker): >> | 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 and: >> Nick Coghlan (in this thread): >>> The addition of these packages to Fedora means that as soon as you do >>> "dnf install tox", those runtimes are all brought in automatically via >>> Recommends >> I would also like to point out that if you have these suffixed Python >> versions installed, some build scripts may be accidentally picking up >> those instead of the recommended default versions of Python. > > Do you mean Fedora build scripts here? I mean build scripts in upstream tarballs, which can also end up in our packages (and cause problems when building outside of mock), but which can also be used directly by people. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
- Original Message - From: "Kevin Kofler" To: devel@lists.fedoraproject.org Sent: Monday, October 10, 2016 4:14:30 PM Subject: Re: including EOL and vulnerable software in Fedora > Your explanation does not solve the inherent contradiction between: >> churchyard (in the FESCo tracker): >> | 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 >and: >> Nick Coghlan (in this thread): >>> The addition of these packages to Fedora means that as soon as you do >>> "dnf install tox", those runtimes are all brought in automatically via >>> Recommends tox is THE main reason for multiple interpreters in Fedora. So no the comments are not contradictory but it seems there is a lack of (technical) understanding of the actual situation here, but I may be wrong here, so please correct me if you think so. tox is not just any package, so maybe it is not stressed out I guess from the original descriptions. This is the work in progress (posted also to one of the tickets) for the fedora developers portal where use cases are explained[0]. [0] https://github.com/hroncok/content/blob/c893f742cad6458ba010748b3e1683dba5671b84/tech/languages/python/multiple-pythons.md Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
Charalampos Stratakis wrote: > If people's issues is just the CVE's, and then everything will be fine, we > can go and fix all the CVE's discovered so far. That would be a good start. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
Charalampos Stratakis wrote: > tox is THE main reason for multiple interpreters in Fedora. > > So no the comments are not contradictory but it seems there is a lack of > (technical) understanding of the actual situation here, but I may be wrong > here, so please correct me if you think so. > > tox is not just any package, so maybe it is not stressed out I guess from > the original descriptions. If no package is allowed to require the old Pythons (and IMHO, "Recommends:" is "require"), that also applies to tox. If tox is allowed to recommend the old Pythons, that invalidates the claim that they will never be dragged in as dependencies. What tox uses the old Pythons for does not change anything to the contradiction. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
- Original Message - From: "Kevin Kofler" To: devel@lists.fedoraproject.org Sent: Monday, October 10, 2016 6:18:19 PM Subject: Re: including EOL and vulnerable software in Fedora > If no package is allowed to require the old Pythons (and IMHO, "Recommends:" > is "require"), that also applies to tox. If tox is allowed to recommend the > old Pythons, that invalidates the claim that they will never be dragged in > as dependencies. What tox uses the old Pythons for does not change anything > to the contradiction. Nevertheless, at the link that I posted before, you can see for yourself the exact use case, so that should make things clear enough. Contradictory or not (as I said maybe the original descriptions possibly need to be rephrased), arguing about that does not really contribute anything to the discussion. Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
+1 There is no need to keep broken deprecated stuff in fedora repositories. If somebody really wants to use this, use a COPR. Or use the distro with conservative risky update policy you are developing against (CentOS, RHEL, Debian, Ubuntu, …). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
Charalampos Stratakis wrote: > Nevertheless, at the link that I posted before, you can see for yourself > the exact use case, so that should make things clear enough. Contradictory > or not (as I said maybe the original descriptions possibly need to be > rephrased), arguing about that does not really contribute anything to the > discussion. Pointing out the contradiction contributes to the discussion that it points out that the claimed guarantees that you will not end up with the old Pythons without installing them explicitly are blatantly false if there will be exceptions to the "no dependencies on those packages" rule. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On Mon, Oct 10, 2016 at 10:29:16AM +0200, Vít Ondruch wrote: > > > Dne 9.10.2016 v 05:42 Nick Coghlan napsal(a): > > On 8 October 2016 at 23:13, Kevin Kofler wrote: > >> These python[23][1-9] packages are entirely unnecessary and should go away > >> ASAP. > > They're not unnecessary for Python developers, as if you want to make > > sure you're not accidentally using any features from later versions of > > Python, the only way to reliably check that is to actually test your > > code on those older versions. > > While I understand you want to test against older pythons, I don't > understand how you would do that, since I don't believe that "just" > older python is enough. You typically need also some additional > libraries. Therefore I'm afraid this won't stop just with older python, > but will continue with another set of packages. Most pure-python packages nowadays support 2.x and 3.x from the same codebase (at least "libraries", this not true for some "leaf" programs). So if you are lucky and don't need any complied python modules, simply adding site-packages from a similar version to PYTHONPATH should be enough. And anyway, once you have python running, then you have pip, and bootstrapping is significantly easier. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
Dne 11.10.2016 v 01:59 Zbigniew Jędrzejewski-Szmek napsal(a): > On Mon, Oct 10, 2016 at 10:29:16AM +0200, Vít Ondruch wrote: >> >> Dne 9.10.2016 v 05:42 Nick Coghlan napsal(a): >>> On 8 October 2016 at 23:13, Kevin Kofler wrote: These python[23][1-9] packages are entirely unnecessary and should go away ASAP. >>> They're not unnecessary for Python developers, as if you want to make >>> sure you're not accidentally using any features from later versions of >>> Python, the only way to reliably check that is to actually test your >>> code on those older versions. >> While I understand you want to test against older pythons, I don't >> understand how you would do that, since I don't believe that "just" >> older python is enough. You typically need also some additional >> libraries. Therefore I'm afraid this won't stop just with older python, >> but will continue with another set of packages. > Most pure-python packages nowadays support 2.x and 3.x from the same > codebase (at least "libraries", this not true for some "leaf" programs). This is contradicting. Either they works and you don't have to test anything or they are know to not work and you need to test the compatibility and possibly use different versions. > So if you are lucky and don't need any complied python modules, Yes, if you are lucky, this is another argument against. > simply > adding site-packages from a similar version to PYTHONPATH should be > enough. > > And anyway, once you have python running, then you have pip, pip is independent package, so you don't have pip out of the box ... Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
I'd like to apologize for the wording "No security fixes will be applied". It was meant as a warning to users who might install the package without knowing what it is for, not as a declaration that we won't maintain the package properly. The "python26" package is meant to provide just that -- Python 2.6, as it was released and as it is present in various old environments. People that develop backwards-compatible libraries need to test against this version, and to make Fedora compelling for those developers, we want to make it as easy as possible to test the backwards compatibility. This version is no longer supported upstream, so there aren't many eyes on it. It shouldn't be held to the same standards as the current Python versions, but since it is still in use, bugs still sometimes get found and security fixes will get applied. We do intend to maintain the package according to Fedora standards -- as far as there are standards for packages with inactive upstreams. This conversation builds on discussions all the way back to Flock, and some details were elided or worded inappropriately in the recent messages. I'd like to invite everyone to take a deep breath, try to understand the intent, and ask for clarifications rather than forming assumptions. -- Petr Viktorin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On 10/10/2016 06:18 PM, Kevin Kofler wrote: Charalampos Stratakis wrote: tox is THE main reason for multiple interpreters in Fedora. So no the comments are not contradictory but it seems there is a lack of (technical) understanding of the actual situation here, but I may be wrong here, so please correct me if you think so. tox is not just any package, so maybe it is not stressed out I guess from the original descriptions. If no package is allowed to require the old Pythons (and IMHO, "Recommends:" is "require"), This is the source of the apparent contradiction. For me, "Recommends" and "Requires" are two different things. "Requires" means that the dependency is required for proper operation. In this case, that would usually mean the library is built for a particular version of Python. "Recommends" means that people usually want to install the packages together. Specifically, "tox" is a tool for testing Python code across multiple Python versions. Without a few different interpreters, it would be useless, but no single interpreter is required for it. And since many people use it to test across various versions, it makes sense to install those by default. that also applies to tox. If tox is allowed to recommend the old Pythons, that invalidates the claim that they will never be dragged in as dependencies. Sorry for the brevity in that claim. The old Pythons should not being dragged in as deps, *except* for development tools specifically meant for testing on alternate Pythons, where "alternate" almost always means "old". In an earlier mail: On 10/10/2016 04:14 PM, Kevin Kofler wrote: Petr Viktorin wrote: I would also like to point out that if you have these suffixed Python versions installed, some build scripts may be accidentally picking up those instead of the recommended default versions of Python. Do you mean Fedora build scripts here? I mean build scripts in upstream tarballs, which can also end up in our packages (and cause problems when building outside of mock), but which can also be used directly by people. Okay, let's go back to the use case here: a developer wants to test on various versions of Python. If that's not the case, they wouldn't install tox, since tox is a tool that only tests code on various versions of Python. The alternative to packaging those Pythons in Fedora is putting them in some COPR. I believe this would send a bad message. If we want to make Fedora friendly for Python developers, we should make cross-version testing officially supported, and as easy as possible. "Bring your own Python from somewhere" does not give Fedora any advantage over any other OS. But either way, main repos or COPR, if a developer wants to test against multiple Pythons and follows the recommended steps, the old Pythons might get picked up by build scripts. I don't see an alternative that would prevent this. The alternative to Recommending lots of Python versions from Tox is letting people install them manually. This, again, makes the experience worse – people just want to start testing, and we want them to be able to do that by just installing the testing tool and running it. -- Petr Viktorin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On Tue, Oct 11, 2016 at 09:50:13AM +0200, Vít Ondruch wrote: > > > Dne 11.10.2016 v 01:59 Zbigniew Jędrzejewski-Szmek napsal(a): > > On Mon, Oct 10, 2016 at 10:29:16AM +0200, Vít Ondruch wrote: > >> > >> Dne 9.10.2016 v 05:42 Nick Coghlan napsal(a): > >>> On 8 October 2016 at 23:13, Kevin Kofler wrote: > These python[23][1-9] packages are entirely unnecessary and should go > away > ASAP. > >>> They're not unnecessary for Python developers, as if you want to make > >>> sure you're not accidentally using any features from later versions of > >>> Python, the only way to reliably check that is to actually test your > >>> code on those older versions. > >> While I understand you want to test against older pythons, I don't > >> understand how you would do that, since I don't believe that "just" > >> older python is enough. You typically need also some additional > >> libraries. Therefore I'm afraid this won't stop just with older python, > >> but will continue with another set of packages. > > Most pure-python packages nowadays support 2.x and 3.x from the same > > codebase (at least "libraries", this not true for some "leaf" programs). > > This is contradicting. Either they works and you don't have to test > anything or they are know to not work and you need to test the > compatibility and possibly use different versions. I want to test *my* code, that I'm working on and actively changing. There's no contradiction between running tests on the code you are developing, while assuming (at least before evidence to the contrary) that the rest of the system is OK. That's how software development happens ;) > > So if you are lucky and don't need any complied python modules, > > Yes, if you are lucky, this is another argument against. Those packages are not supposed to be a solution to everything. If they help some people some of the time that's already good. > > simply > > adding site-packages from a similar version to PYTHONPATH should be > > enough. > > > > And anyway, once you have python running, then you have pip, > > pip is independent package, so you don't have pip out of the box ... $ sudo dnf install python3.4 -y $ python3.4 -m ensurepip --user $ python3.4 -m pip ... Yes I do ;) Zbyszek PS. PYTHONPATH=/usr/lib/python3.5/site-packages python3.4 -m pip also works... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
Dne 11.10.2016 v 12:57 Petr Viktorin napsal(a): > > The alternative to packaging those Pythons in Fedora is putting them > in some COPR. I believe this would send a bad message. If we want to > make Fedora friendly for Python developers, we should make > cross-version testing officially supported, and as easy as possible. > "Bring your own Python from somewhere" does not give Fedora any > advantage over any other OS. But this goes back to mttdm's "rings" proposal IMO. Yes, provide these packages somewhere, but not in the main repositories. I can't see nothing wrong suggesting "dnf copr enable pythondevel/pythons" to make tox work. And if you want to be fancy and want to really start the ring proposal, the "copr" dnf plugin could be forked into some "ring" plugin with some ring specific functionality (whatever it is, e.g. "dnf ring enable pythondevel"). Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: including EOL and vulnerable software in Fedora
On 11 October 2016 at 02:18, Kevin Kofler wrote: > Charalampos Stratakis wrote: >> tox is THE main reason for multiple interpreters in Fedora. >> >> So no the comments are not contradictory but it seems there is a lack of >> (technical) understanding of the actual situation here, but I may be wrong >> here, so please correct me if you think so. >> >> tox is not just any package, so maybe it is not stressed out I guess from >> the original descriptions. > > If no package is allowed to require the old Pythons (and IMHO, "Recommends:" > is "require"), that also applies to tox. If tox is allowed to recommend the > old Pythons, that invalidates the claim that they will never be dragged in > as dependencies. What tox uses the old Pythons for does not change anything > to the contradiction. As Petr clarified, these old Python runtimes are effectively optional pieces of Fedora's tox package - they're just broken out as "pythonXY" packages since that makes them more consistent with the way Python runtimes are packaged normally and allows for easier SRPM sharing with EPEL and downstream. If it's only the package names that bother folks, then they could technically be namespaced as "tox-pythonXY" in Fedora, but that seems like imposing additional work on tooling maintainers (as well as creating inconsistencies between mainline Fedora and EPEL) for no practical benefit to anyone. If, on the other hand, the claim is that these particular Python developer tools shouldn't be in the main repository for Fedora at all, then that runs counter to the user experience goals of Fedora Workstation: "The system will primarily be aimed at providing a platform for development of server side and client applications that is attractive to a range of developers - from hobbyists and students to developers working in corporate environments." Now, it may be that the Fedora Modularity project will eventually say "Hey, Python development and testing utilities can be a module!", and we'll see both tox and the additional Python runtimes move to that maintenance model. In the long run, that's almost certainly a good idea. Today though, the best possible developer experience that Fedora can provide is for "dnf install tox" to *just work*, and give you an environment for testing software compatibility against multiple versions of Python from 2.6 through to 3.5+. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org