"and may have security issues." ... seriously? You are going to add packages which you are not going to maintain or how should I understand that?

For the most cases those are old Python versions only provided for developers, so they can run their test suites on. The description of the packages makes it clear that they are for this purpose only, if we can indicate it even more, please suggest how.

I.e. if you develop a library that is supposed to support Python 2.6 to Python 3.5, you can now simply dnf install those and use tox or other tools to test it. We don't want people to install Python 2.6 from the repo to run their critical web app on Fedora Server, however, we cannot stop them to do so, as we cannot stop them to compile their own version of Python anyway.

If the use case does not work, i.e. the interpreter is unusable for testing your code, we are going to fix that, if a new patch version is released, we are probably going to update the package (but for most of those, no new versions will happen). But we will not monitor those and apply security fixes as patches.

Security is one reason we don't want anything other to depend on those packages. Other reason is that we don't want to have 5+ stacks of Python modules packaged, 2 is plenty.

Makes sense?

Replying to [comment:3 vondruch]:

"and may have security issues." ... seriously? You are going to add packages which you are not going to maintain or how should I understand that?

Some of these packages (python26, python33) are not maintained anymore upstream, which means security issues are not fixed upstream. So yeah they may have security issues and they should not be used as the base interpreter of the system, or have applications/packages/scripts rely on these packages to work.

I don't want to get into whether Fedora actually wants to carry these packages. I can certainly see the utility, but I can also see the dark urge packagers may have to build up dependency trees around them instead of getting things ported to "supported" releases. I definitely do agree that we need to be able to say something ''generally'' about having dependencies on them.

How about this: we come up with something to be added via Provides: to this kind of package. "Provides: unsupported(python) = 2.4" or whatever. We then say that nothing in Fedora can depend upon any package which provides "unsupported(*)", and of course it becomes easy to actually look for instances of that.

Of course you should feel free to suggest something better than "unsupported".

Whatever works. But I think it gets overcomplicated. Packages can (technically) Require the package directly anyway. I don't see a benefit in creating a virtual provide to stop people require it.

The provide makes it easy to track these, and to know that a specific package is actually unsupported without having to read the description. It's the same thing we do with bundled libraries. Plus, it's a lot easier to say "can't depend on any package which provides unsupported(*)" than it is to say "there are a bunch of random python packages, plus maybe some other non-python packages, upon which you shouldn't depend, and this list will change in the future so you just have to know or hope that FPC updates the guideline page."

To be clear: we intend to maintain these packages. However, and we intend to do ''package maintenance'' only – we won't be coding patches, or actively looking for security issues. Most of the older Python versions no longer have upstream support (though they're still useful).

As for why multiple Pythons are important:

Authors of many Python libraries want to ensure compatibility with various versions and implementations of the language. Doing this in Fedora currently involves compiling from source or hunting down COPRs, or just using CI in the cloud, most popular being the (open-source, but Ubuntu-based) Travis CI. With multiple Pythons packaged, you dnf install tox, put in a config file, and run tox.

During Flock discussions around making Fedora better for Python developers, testing on multiple versions was one of the top issues.

Does this generalize to outside the Python ecosystem? It probably does, so unsupported(*) would be a good idea. Not sure if unsupported is the right word, maybe something more towards "devel-only"?

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-10-06/fpc.2016-10-06-16.00.txt):

• 650 Alternate Python Interpreters (geppetto, 16:06:52)

• ACTION: We'll table this until FESCo has made some decisions on what
  to package (geppetto, 16:25:08)

And just to add here what I mentioned at the meeting.

What is the difference between unsupported (upstream) python interpreters, and various other packages where upstream is EOL?

Every other package out there where upstream is EOL might pose a security risk, but I haven't seen any objections or concerns regarding that.

The only reason these concerns are expressed now, is because we took the extra step to actually document what these packages are for, their use cases and also explicitly state their upstream status.

Does that mean that software should be packaged only when upstream is active, even though the package is working as expected?

Replying to [comment:11 cstratak]:

And just to add here what I mentioned at the meeting.

What is the difference between unsupported (upstream) python interpreters, and various other packages where upstream is EOL?

None in general.

Every other package out there where upstream is EOL might pose a security risk, but I haven't seen any objections or concerns regarding that.

The only reason these concerns are expressed now, is because we took the extra step to actually document what these packages are for, their use cases and also explicitly state their upstream status.

No, the only reason is that I've never seen a package with known security vulnerabilities with no plans for fixing them accepted into Fedora before. This has nothing to do with your packages specifically. They were just a trigger and prompted me to ask FESCo to address a more general issue for which we don't have any policy yet.

Does that mean that software should be packaged only when upstream is active, even though the package is working as expected?

If that were the only caveat then no. Having known security vulnerabilities without any plans to fix them is an entirely different and far more serious issue.

Replying to [comment:13 rathann]:

If that were the only caveat then no. Having known security vulnerabilities without any plans to fix them is an entirely different and far more serious issue.

That would be an issue if the packages were intended to be used in production. And yes that would be a serious concern, however the intended use case is testing. So apart from warning users/developers I don't really see a valid argument of how this could pose a problem unless someone intentionally wants to break their systems by deploying applications targeting these interpreters.

So unless your test suite manages to somehow deploy stuff to production, I don't see a security concern, maybe someone more experienced or with specific use cases in mind can shed some light to that.

You can also check the work-in-progress about the benefits of these packages and the use cases, aimed to be posted at [https://github.com/hroncok/content/blob/c893f742cad6458ba010748b3e1683dba5671b84/tech/languages/python/multiple-pythons.md Fedora developer portal].

And as a side note (although mentioned before), this is a part of a bigger initiative to make Fedora attractive for (Python and not only) developers. Feedback was gathered through Python-SIG, Flock meetups, mailing lists, irc etc and that was one of the main points. To have multiple python interpreters available for testing.

Replying to [comment:14 cstratak]:

Replying to [comment:13 rathann]:

If that were the only caveat then no. Having known security vulnerabilities without any plans to fix them is an entirely different and far more serious issue.

That would be an issue if the packages were intended to be used in production. And yes that would be a serious concern, however the intended use case is testing. So apart from warning users/developers I don't really see a valid argument of how this could pose a problem unless someone intentionally wants to break their systems by deploying applications targeting these interpreters.

So unless your test suite manages to somehow deploy stuff to production, I don't see a security concern, maybe someone more experienced or with specific use cases in mind can shed some light to that.

I'm sorry, but in the real world, even if you say something is not intended for production, people will still try to deploy it in production. I have seen too many cases already. The only way to stop this is not to make vulnerable stuff available in any sort of official repository.

You can also check the work-in-progress about the benefits of these packages and the use cases, aimed to be posted at [https://github.com/hroncok/content/blob/c893f742cad6458ba010748b3e1683dba5671b84/tech/languages/python/multiple-pythons.md Fedora developer portal].

And as a side note (although mentioned before), this is a part of a bigger initiative to make Fedora attractive for (Python and not only) developers. Feedback was gathered through Python-SIG, Flock meetups, mailing lists, irc etc and that was one of the main points. To have multiple python interpreters available for testing.

That's very nice, but in my opinion enabling and promoting the use of EOL and vulnerable software is irresponsible. There is enough grief caused by new vulnerabilities already. I don't think Fedora should be in the business of reintroducing old ones.

Replying to [comment:15 rathann]:

I'm sorry, but in the real world, even if you say something is not intended for production, people will still try to deploy it in production. I have seen too many cases already. The only way to stop this is not to make vulnerable stuff available in any sort of official repository.

People can do many things that can compromise their security, I don't really think that is the argument here. From what I can deduct the main point is that Fedora shouldn't "support" unreliable software (as in not have it in the official repos) but how do you define "support"? The packages will be maintained and there are some limitations from upstream, however they serve a specific purpose.

Also what the [https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name naming guidelines for compat packages] suggest is a good example, same policy is being followed here, there is no deviation from the packaging guidelines.

That's very nice, but in my opinion enabling and promoting the use of EOL and vulnerable software is irresponsible. There is enough grief caused by new vulnerabilities already. I don't think Fedora should be in the business of reintroducing old ones.

Vulnerable software is not promoted, specific use cases and techniques are promoted aimed for python developers using Fedora. It seems for some reason the words "security, vulnerability, etc" trigger negative emotions to many people and by continuing to use those terms in their generic form, it just makes the actual argument muddy.

So in, my opinion, the question here is:

Do those packages pose any risks or expose Fedora users to certain vulnerabilities?

Short Answer: No

Long Answer: No if they are used for what they are supposed to, but if people start doing undocumented and unsupported tricks, hacks, deployments etc (and for sure it is possible to happen in this case as well) they might expose themselves to certain vulnerabilities (which can happen with everything else in Fedora repos when used in an unsupported way).

So it's a specific set of packages with specific use cases and it should be treated as that. I don't know if an exception from FESCO or FPC will be required as something like that is not really documented, but treating this case as an example of "vulnerable software in Fedora repositories" does not really help in resolving the issue and addressing the concerns about it.

Replying to [comment:16 cstratak]:

Replying to [comment:15 rathann]:

People can do many things that can compromise their security, I don't really think that is the argument here. From what I can deduct the main point is that Fedora shouldn't "support" unreliable software (as in not have it in the official repos) but how do you define "support"? The packages will be maintained and there are some limitations from upstream, however they serve a specific purpose.

I have nothing against your specific use-case as long as the risks are understood and accepted by FESCo and Fedora Security Team. Hence my proposal to require an exception process. I'm trying to address a general issue, not stop your work from benefiting developers that use Fedora. OTOH, I don't see why these old python runtimes couldn't be distributed via COPR. You'd only have to add one line to your howto.

Also what the [https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name naming guidelines for compat packages] suggest is a good example, same policy is being followed here, there is no deviation from the packaging guidelines.

I never said there was any deviation.

That's very nice, but in my opinion enabling and promoting the use of EOL and vulnerable software is irresponsible. There is enough grief caused by new vulnerabilities already. I don't think Fedora should be in the business of reintroducing old ones.

Vulnerable software is not promoted, specific use cases and techniques are promoted aimed for python developers using Fedora. It seems for some reason the words "security, vulnerability, etc" trigger negative emotions to many people and by continuing to use those terms in their generic form, it just makes the actual argument muddy.

So in, my opinion, the question here is:

Do those packages pose any risks or expose Fedora users to certain vulnerabilities?

Short Answer: No

Long Answer: No if they are used for what they are supposed to, but if people start doing undocumented and unsupported tricks, hacks, deployments etc (and for sure it is possible to happen in this case as well) they might expose themselves to certain vulnerabilities (which can happen with everything else in Fedora repos when used in an unsupported way).

{{{dnf install foo}}} is unsupported?

So it's a specific set of packages with specific use cases and it should be treated as that. I don't know if an exception from FESCO or FPC will be required as something like that is not really documented, but treating this case as an example of "vulnerable software in Fedora repositories" does not really help in resolving the issue and addressing the concerns about it.

It's recently added software that was known to be vulnerable at the moment of package review. People will often not read the package descriptions, so you cannot expect they will not just {{{dnf install python26}}} and start using it like any other package. IOW: you cannot limit their usage.

This discussion should be continued either in the FESCo ticket (https://fedorahosted.org/fesco/ticket/1634) or in the devel mailing list.

Replying to [comment:17 rathann]:

This discussion should be continued either in the FESCo ticket (https://fedorahosted.org/fesco/ticket/1634) or in the devel mailing list.

Agreed.

Packages were accepted [0]

[0] https://pagure.io/fesco/issue/1634

Thanks for the update. But what should happen with this ticket? Is the original issue still valid?

I still maintain that we need a general mechanism for a package to specify that nothing should depend upon it, but I don't know if it's worth actually formalizing one if there's no need.

And if it's going to be OK for other things to depend on these packages, we have other work to do in the guidelines to prepare for having multiple complete python stacks. (Which we're partially ready for now given what EPEL has been doing, though it makes the packaging just horribly messy right now.)

I don't have time to change the wording after the FESCo meeting, but the original point still stands. Nothing should depend on pythonXY packages in Fedora.

OK, then I propose what I mentioned in comment 6 above: these packages add "Provides: something(python) = %version" or "something(%name) = %version" (have to think about pros and cons of each) and we add a prohibition on packages depending on any package which provides "something(*".

Given that "unsupported" isn't the right word, I'm drawing a blank on what "something" should actually be. "do-not-depend" is all I can think of, and it doesn't really seem great.

And since the discussion seemed to go the wrong way when I brought it up before, how this actually gets enforced is beyond the scope. It's certainly enforcable and if passed then I can talk to the taskotron folks.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-11-03/fpc.2016-11-03-16.00.txt):

• 650 Alternate Python Interpreters (geppetto, 16:09:28)

• ACTION: Packages to add leaf-only(%name) = %version to not be
  required by other packages (+1:5, 0:0, -1:0) (geppetto, 16:15:28)
• "No package can Require or BuildRequire any package that provides
  "leaf-only" (geppetto, 16:24:52)

So we can still Recommend it from tox, right?

I can't parse that.

Basically, you add Provides: leaf-only(%name) = %version to your package. That's it.

The guidelines will (once I update them) indicate that dependencies on such packages (manual or automatic, build or runtime) are forbidden. Eventually the rest of the distro may grow tooling to do some automatic checking, but that's kind of beyond the scope of the packaging committee.

Well, the original proposal said:

Those packages may only be Recommended or Suggested by tools intended for testing Python code on various interpreters, such as python-tox.

This is still our concern.

This will be a MUST NOT; any exceptions must be specifically granted by the committee. Can you provide a list of all such tools, or is python-tox the only relevant one at the moment?

python-tox is the only relevant for now

Clarification: python-tox is not being run by those interpreters, quite the contrary: it helps to run them.

Proposal for FPC: allow python-tox to depend upon the otherwise leaf-only python2. and python3. packages.

The proposal should be: allow python-tox to ''recommend'' the otherwise leaf-only python2. and python3. packages.

Allowing "Depends" would probably also allow "Recommends", but it would be nice to be specific. Tox will never have a ''hard'' dependency on a leaf-only Python. (But the Recommends is an important part of our effort of making Fedora the distro of choice for Python developers.)

I don't know that the committee wants to get into that much detail. I certainly don't. But if you want to complicate things....

The idea is to simply have the software which will check for any type of dependency on the leaf-only packages ignore python-tox if it shows up in the list, and include a reference to the ticket where the exception is approved. That's about it.

I'm OK with a single whitelist for automated checkers. But a human-readable description, like the approving ticket, can say tox's exception is only for Recommends.

Just noticed that all of those alternate python packages were imported with names that violate the packaging guidelines. python26, not python2.6 as required. Will get to blocking them all now.

OK, I apologize. It's merely recommended that you use "python2.6", but it's not a hard requirement. I'll go ahead and use the big capital SHOULD there to make it clear.

I had cleaned up the naming guidelines to try and make it more obvious that "python2.6" is the proper name for the package back in November and never closed the ticket. Oops.