Formal request to clean out Python branches ASAP from our ports tree (was: git: 66173037774d - main - lang/python31[012]: deprecate 2026-03-31)

Am 03.01.26 um 23:50 schrieb Antoine Brodin:
> On Sat, Jan 3, 2026 at 11:48 PM Matthias Andree <mandree@freebsd.org> wrote:
>> The branch main has been updated by mandree:
>>
>> URL: https://cgit.FreeBSD.org/ports/commit/?id=66173037774d8648a59e30b424692ae80dbc20b3
>>
>> commit 66173037774d8648a59e30b424692ae80dbc20b3
>> Author:     Matthias Andree <mandree@FreeBSD.org>
>> AuthorDate: 2026-01-03 22:39:35 +0000
>> Commit:     Matthias Andree <mandree@FreeBSD.org>
>> CommitDate: 2026-01-03 22:42:02 +0000
>>
>>      lang/python31[012]: deprecate 2026-03-31
>>
>>      Since the current Python upstream maintainers have not yet released
>>      security fix releases to match 3.14.2 and 3.13.11, meaning that we have
>>      about three unfixed security issues per 3.12/3.11/3.10 release, and the
>>      current FreeBSD python@ team is unwilling to take approved upstream
>>      patches individually (see PR), we need to expedite the removal of
>>      vulnerable versions and the transition to 3.13/3.14.  Deprecate all
>>      "security support" releases of Python that are not in the bugfix phase.
>>
>>      PR:             291609
> This is wrong,  please revert.
> 3.10 end of life is october 2026
> 3.11 end of life is october 2027
> 3.12 end of life is october 2028

Dear Antoine, dear python, portmgr, ports-secteam and core teams,

Transparency: I am not on python@.

1. the upstream Python project has failed to deliver the security fix 
backports (of the fixes that appeared in 3.13 and 3.14 on 2025-12-05 
patchlevel releases) to source tarball releases (which is the only 
deliverable they committed to) of 3.12.X, 3.11.Y, 3.10.Z. The "EOL" and 
"security branch" of Python are a sham and do not deliver on their promise.

2. we must therefore move the FreeBSD project to 3.13 or 3.14, both 
releases in "bugfix" support, as quickly as possible.

REQUEST 3a. I formally request that either python@ or as backup portmgr@ 
or as backup core@ decides that we as a project distrust Python 
"security support" phase and the project's plan is to move to Python 
3.13 or 3.14 as our default ports version as quickly as possible.

It may be diligent to move to 3.13 first and to 3.14 in due time before 
3.13 transitions from bugfix support to security support in 
prospectively October 2026. Ideally we switch the main ports branch to 
3.14 in July or August so we have time to clean up fallout before we 
branch for  2026Q4.

3b. I am uncertain if ports-secteam@ has a say in this; but they already 
asked how we can avoid a situation where our default python version has 
been vulnerable to known security issues for an unduly long time already 
and remains unfixed today, and how to avoid that situation. My proposal 
is in 3a.

4. I formally request that either python@ or as backup portmgr@ or as 
backup core@ decides we need to reduce the number of Python branches in 
our tree, recognizing we cannot - as a project - maintain six branches 
of Python because we're understaffed.

More observations:

The extant python@ team of FreeBSD apparently has insufficient capacity 
to see to getting 3.11 and 3.10 maintained to the extent needed to get 
known security issues fixed, and this has so far left our default 
version 3.11.14 vulnerable to at least two, possibly three, known 
security issues (vishwin@ pulled three fixes into 3.12.12 as cherry-picks).

The extant python@ team of FreeBSD has five Python releases at hand 
(being 3.11, 3.10, 3.12, 3.13, 3.13t) and I expect 3.13t to be somewhat 
more cumbersome than the others AFAICS. (I am the maintainer for the 
3.14 port, and we do not have a 3.14t port. Footnote [1].) and we need 
to reduce that as quickly as possible.

Footnotes:

[1] If there is sufficient interest, I can set up a 3.14t port that I 
would *NOT WANT* integrated with the Python FLAVORS framework, but would 
keep separate as a minimal port that has venv and pip/wheel available so 
that people can build their virtual environments and install the 
necessary packages into a virtual environment for their project. I 
honestly don't think we can support all of ports/*/py-* for the "-t" 
variants of Python yet.

-- 
Matthias Andree
FreeBSD ports committer