python311-3.11.14 vulnerable but no alternatives/updates

This is why administrators, moderators and developers should have zero tolerance for such ungrateful people. You guys are way too relaxed and tolerate way too much. Especially those that engage in discussions and trying to actually reason with them.
 
Just a note... there is lang/python315, not vulnerable according to 'pkg audit' test... no idea on compability, I just did it for a test.
 
Regarding CVE-2025-47273 in py-setuptools.
Code: 
As for this specific vulnerability, it is not exploitable to how we (ports) build
Python packages, since the affected mechanism is setuptools's own PyPI
fetching mechanism which we do not use (we have our own do-fetch via
fetch(1) et al).

In all, this vuxml entry was not added or reviewed by the python@ team, 
especially not for applicability to actual use cases.
 
Multiple people have stepped in and offered help (including doing work) since things are progressing very slowly. Friction, lack of communication and organisational skills and gatekeeping between a committer and several other developers (within FreeBSD), ports committers and contributors (unfortunately) don't improve the situation.

Just an example of how fast PRs are processed, from the release of Python 3.13 (Oct 2024 according to https://www.python.org/downloads/ ) over a year passed before it landed in tree and patches have been available during that time.

Looking at git history "python@ team" or its members haven't initially committed a single VuXML entry for the past two years so and there have been CVEs during that time (for those who want to know).
 
One of the example of show-stopper for bumping default python can be seen at Comment 21 of PR 274671, precisely, the part below.
because of one package that upstream declared not compatible with this version
Click to expand...
Broken backward compatibilities makes bumps harder and time consuming.
It matters worst for languages having too huge amount of dependants like python. And this is why I hate python as a programming language and don't want to learn it.
 
Charlie_ said:
New failures logs.

285957 – lang/python312 as default python

bugs.freebsd.org bugs.freebsd.org
These are the remaining problematic failures from last time.
Code: 
japanese/mozc-server : 15 skipped
devel/pyside2@py312 : 8 skipped
devel/py-yappi@py312 : 6 skipped
audio/aubio : 5 skipped
Click to expand...
The case for japanese/mozc-server looks ninja related (crashed in *.py).

Not tried on py312 environment, so possibly I'm overlooking something important, but mozc would switch to bazel builds (defaulted to bazel9) if PR 295074 by Ken DEGUCHI is accepted and lands. But some python scripts seem to be used at least for merging dictionaries, thus, this can still fail.
 
Charlie_ said:
Simply updating Mozc would require the decision to drop support for i386.
Depending on the committer, Mozc might maintain two ports, gyp and bazel,
until i386 support ends, similar to pkgsrc.
Click to expand...
As i386 is already Tier2 on 14.x and dropped supports at 15.0 and later, and considering current mozc ports are NOT upgraded for quite a long time, I personally think to copy current Mozc-related ports as *-i386 ports and upgrade existing ones into new form which uses bazel.

Actually, *-i386 (or *-gyp) would be actually "frozen" as coexisting both in one port using FLAVOR would be unrealistic (see the patch at PR 295074 how large the differences are!). And I've heard from Ken via personal email that upstream dropped supports for gyp builds.

Frankly, I don't like Bazel, but the decision is on upstream.
 
fernandel said:
I have a question about default version.
In /usr/ports/Updating stay pkg set -p -n py311-:py312- and than upgrade. It is okay but will be other need it packages automatically reinstalled, please? Thank you.
Click to expand...
The intention of the command is to rename all pkgs installed that have py311- to have py312- instead in local pkg database.

This may be because to surely avoid pkg-upgrade(8) to upgrade py311- pkgs to py311- (as-is), thus, nothing other than "actually" bumped whichever of PORTVERSION, DISTVERSION, PORTREVISION and/or PORTEPOCH could be kept as-is.

Not sure, but if something like foo-py311-bar left untouched, possibly you need to run pkg set -p -n \*-py311-\*:\*-py312-\*.
Don't try this unless you've really bitten in such a case (this mean, pkg doesn't work as documented).

Another possibility would be something like baz-py311.
If this kind of PKGNAME really exists, the procedure described in UPDATING is insufficient.
 
I did install py312 and everything works as before, no missing dependencies...
and pkg audit shows:
Code: 
python312-3.12.13_3 is vulnerable:
  Python -- poplib module, when passed a user-controlled command, can have additional commands injected using newlines
  CVE: CVE-2025-15367
  WWW: https://vuxml.FreeBSD.org/freebsd/6d3488ae-2e0f-11f1-88c7-00a098b42aeb.html

  python -- more webbrowser.open() command injection vulnerabilities
  CVE: CVE-2026-4786
  WWW: https://vuxml.FreeBSD.org/freebsd/cf75f572-378a-11f1-a119-e36228bfe7d4.html

  Python -- imaplib module, when passed a user-controlled command, can have additional commands injected using newlines
  CVE: CVE-2025-15366
  WWW: https://vuxml.FreeBSD.org/freebsd/0be929a5-2e0f-11f1-88c7-00a098b42aeb.html

  Python -- use-after-free vulnerability in decompressors under memory pressure
  CVE: CVE-2026-6100
  WWW: https://vuxml.FreeBSD.org/freebsd/b8e9f33c-375d-11f1-a119-e36228bfe7d4.html

  Python -- configparser vulnerable to excessive CPU use
  WWW: https://vuxml.FreeBSD.org/freebsd/5ec4dcf6-3588-11f1-b51c-6dd25bec137b.html

py312-setuptools-63.1.0_3 is vulnerable:
  py-setuptools -- Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
  CVE: CVE-2025-47273
  WWW: https://vuxml.FreeBSD.org/freebsd/690144e9-4f88-11f1-982e-00a098b42aeb.html

6 problem(s) in 2 package(s) found.
 
To me something like python, one has to stop and think.
pkg audit looks at installed packages but does not have knowledge of "are they in use".

So the user/sysadmin needs to look at the CVEs and figure out if they actually apply. If your system is a home desktop, not presenting any services to the general Internet, does the CVE actually matter?
 
fernandel said:
I did install py312 and everything works as before, no missing dependencies...
and pkg audit shows:
Code: 
python312-3.12.13_3 is vulnerable:
  Python -- poplib module, when passed a user-controlled command, can have additional commands injected using newlines
  CVE: CVE-2025-15367
  WWW: https://vuxml.FreeBSD.org/freebsd/6d3488ae-2e0f-11f1-88c7-00a098b42aeb.html

  python -- more webbrowser.open() command injection vulnerabilities
  CVE: CVE-2026-4786
  WWW: https://vuxml.FreeBSD.org/freebsd/cf75f572-378a-11f1-a119-e36228bfe7d4.html

  Python -- imaplib module, when passed a user-controlled command, can have additional commands injected using newlines
  CVE: CVE-2025-15366
  WWW: https://vuxml.FreeBSD.org/freebsd/0be929a5-2e0f-11f1-88c7-00a098b42aeb.html

  Python -- use-after-free vulnerability in decompressors under memory pressure
  CVE: CVE-2026-6100
  WWW: https://vuxml.FreeBSD.org/freebsd/b8e9f33c-375d-11f1-a119-e36228bfe7d4.html

  Python -- configparser vulnerable to excessive CPU use
  WWW: https://vuxml.FreeBSD.org/freebsd/5ec4dcf6-3588-11f1-b51c-6dd25bec137b.html

py312-setuptools-63.1.0_3 is vulnerable:
  py-setuptools -- Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
  CVE: CVE-2025-47273
  WWW: https://vuxml.FreeBSD.org/freebsd/690144e9-4f88-11f1-982e-00a098b42aeb.html

6 problem(s) in 2 package(s) found.
Click to expand...
Maybe the fix would be the NeXTnext step.

Landing the fix before this switch should cause another monthtime consuming exp-run including possiblly required (again) fixes for consumer ports, and at worst, causing upcoming 2026Q3 to still have Python3.11 as default Python.

So I think Python guys first landed the switch in hurry.

And this is why I dislike (almost hate) Python that doesn't assure lim 100% backward compatibilities.

If 100% backward compatibilities are achieved, no full exp-run should be needed anymore and heads-up before commiting for maintainers of consumer ports would be sufficient, as some consumer ports could actually want newly added features (and syntaxes) but forced to patch to support current defaults.

I like C, as even on currently supported versions of clang / gcc still have options to compile historic K&R codes. This is how programming languages SHALL be, I believe.
 
You must log in or register to reply here.
Back
Top