including EOL and vulnerable software in Fedora

[Dominik 'Rathann' Mierzejewski]

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"

[Zbigniew Jędrzejewski-Szmek]

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

[Dominik 'Rathann' Mierzejewski]

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"

[Charalampos Stratakis]

----- Original Message -----
From: "Dominik 'Rathann' Mierzejewski" <dominik(a)greysector.net&gt;
To: devel(a)lists.fedoraproject.org, python-devel(a)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

[Kevin Kofler]

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

[Nick Coghlan]

On 8 October 2016 at 23:13, Kevin Kofler <kevin.kofler(a)chello.at&gt; 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   |   ncoghlan(a)gmail.com   |   Brisbane, Australia

[Neal Gompa]

On Sat, Oct 8, 2016 at 11:42 PM, Nick Coghlan <ncoghlan(a)gmail.com&gt; wrote:
>  On 8 October 2016 at 23:13, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; 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!

[Christian Stadelmann]

+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, …).

[Kevin Kofler]

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

[Charalampos Stratakis]

This seems highly unlikely

Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat

----- Original Message -----
From: "Kevin Kofler" <kevin.kofler(a)chello.at&gt;
To: devel(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Petr Viktorin]

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

[Kevin Kofler]

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

[Charalampos Stratakis]

----- Original Message -----
From: "Kevin Kofler" <kevin.kofler(a)chello.at&gt;
To: devel(a)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/c893f742cad6458ba010748b3e1683dba...

Regards,

Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat

[Kevin Kofler]

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

[Charalampos Stratakis]

----- Original Message -----
From: "Kevin Kofler" <kevin.kofler(a)chello.at&gt;
To: devel(a)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

[Kevin Kofler]

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

[Petr Viktorin]

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

[Vít Ondruch]

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

[Nick Coghlan]

On 11 October 2016 at 02:18, Kevin Kofler <kevin.kofler(a)chello.at&gt; 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   |   ncoghlan(a)gmail.com   |   Brisbane, Australia

[Vít Ondruch]

Dne 9.10.2016 v 05:42 Nick Coghlan napsal(a):
>  On 8 October 2016 at 23:13, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; 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

[Igor Gnatenko]

On Mon, Oct 10, 2016 at 10:29 AM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  Dne 9.10.2016 v 05:42 Nick Coghlan napsal(a):
> > On 8 October 2016 at 23:13, Kevin Kofler <kevin.kofler(a)chello.at&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
-Igor Gnatenko

[Zbigniew Jędrzejewski-Szmek]

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 <kevin.kofler(a)chello.at&gt; 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

[Vít Ondruch]

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 <kevin.kofler(a)chello.at&gt; 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

[Zbigniew Jędrzejewski-Szmek]

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 <kevin.kofler(a)chello.at&gt;
> 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...

[Charalampos Stratakis]

----- Original Message -----
From: "Kevin Kofler" <kevin.kofler(a)chello.at&gt;
To: devel(a)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

[Kevin Kofler]

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

[Petr Viktorin]

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

[Florian Weimer]

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

[Dominik 'Rathann' Mierzejewski]

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"

[Daniel P. Berrange]

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/ :|