Am 03.01.26 um 23:50 schrieb Antoine Brodin:
On Sat, Jan 3, 2026 at 11:48 PM Matthias Andree <[email protected]> wrote:
The branch main has been updated by mandree:
URL:
https://cgit.FreeBSD.org/ports/commit/?id=66173037774d8648a59e30b424692ae80dbc20b3
commit 66173037774d8648a59e30b424692ae80dbc20b3
Author: Matthias Andree <[email protected]>
AuthorDate: 2026-01-03 22:39:35 +0000
Commit: Matthias Andree <[email protected]>
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
