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.
 
You must log in or register to reply here.
Back
Top