There are known vulnerabilities in Python 3.11, however I can't see in UPDATING an entry for changing the current version. [...] What isThe recommended version is still 3.11. Although upstream has not yet
the current recommended version?
(I'm using portugrade directly in the ports tree)I really recommend using poudriere instead, especially if you have more
Hi,
There are known vulnerabilities in Python 3.11, however I can't see in UPDATING an entry for changing the current version. The only entry is
20240529:
?? AFFECTS: users of python
?? AUTHOR: rm@FreeBSD.org
?? The default version of python3 and python was switched to 3.11.
What is the current recommended version ? Does the tips in this entry still apply ?
Regards,
Xavier
--
Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Engineer https://www.amdh.fr
The oldest version that has patches for all known issues is 3.13. Unfortunately, changing the default is highly non-trivial as it tends to break a ton of dependents, but if you build your own packages, you canCorrection, setting python3 has no effect, all you need is:
try adding this line to make.conf:
DEFAULT_VERSIONS+=python=3.13 python3=3.13
Beware that net/samba416 and www/py-django60 are pinned to 3.11-3.12 andI have posted reviews net/samba416 and www/py-django60:
will refuse to build if you set the default to anything higher.
On Jun 19, 2026, at 12:46rC>PM, Xavier Humbert <xavier@groumpf.org> wrote:There are cherry-pickable patches for most of the post 3.11.15 CVEs, (python foundation has pushed back if some will be pushed into 3.11, but other OSes have locally patched) but I don't think the port has applied them locally.
Hi,
There are known vulnerabilities in Python 3.11, however I can't see in UPDATING an entry for changing the current version. The only entry is
20240529:
AFFECTS: users of python
AUTHOR: rm@FreeBSD.org
The default version of python3 and python was switched to 3.11.
What is the current recommended version ? Does the tips in this entry still apply ?
I tested python 3.14.We already know 3.14 doesn't work. For instance, the entire py-sphinx ecosystem is currently stuck at the newest version that still supports
Am 23.06.26 um 16:26 schrieb Dag-Erling Sm=C3=B8rgrav:,
We already know 3.14 doesn't work. For instance, the entire py-sphinx ecosystem is currently stuck at the newest version that still supports 3.11, and that version does not support 3.14. We need to switch the default Python version first, preferably to 3.13, then update py-sphinx=
before we can consider Python 3.14.
thanks for this, will give 3.13 now a try ;)
Matthias
I see that https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285957 is staled.
I'm unsure if it is the right time to start doing local builds with 3.13.
Hi,
Am 23.06.26 um 20:49 schrieb Nuno Teixeira:
I see that https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285957 is
staled.
I'm unsure if it is the right time to start doing local builds with 3.13.
I switched now to 3.13 and all seems at first to run fine.
Will test it the next days.
Two issues vex me and the alerts are overwhelming.Patches for these exist, but the maintainer refuses to apply them. https://reviews.freebsd.org/D57717
CVE-2025-15367
CVE-2025-15366
On Wed, Jun 24, 2026, at 12:45 AM, Matthias Fechner wrote:
Hi,
Am 23.06.26 um 20:49 schrieb Nuno Teixeira:
I see that https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285957 is
staled.
I'm unsure if it is the right time to start doing local builds with 3.13. >>
I switched now to 3.13 and all seems at first to run fine.
Will test it the next days.
I have been using Python 3.14 for some time and have switched over from 3.12
Two issues vex me and the alerts are overwhelming.
CVE-2025-15367
CVE-2025-15366
Every host is alerts with those, some for over 70 days.
Alert fatigue is a real thing.
I yearn for a way to easily silence specific vulns in the output of pkg-audit. I'm all for recording in vuxml. Yet at the same time, I want relief from pages of red alerts and having to scan them all to see if there's anything new.
Nothing will be backported until upstream can verify that the fixes doNot true. The patches I posted _are_ from upstream 3.15. There is an additional commit to imaplib commit which we could include:
not break existing (correct) behaviour. Currently only the imaplib (CVE-2025-15366) fixes are present in the latest upstream lang/python31{3,4,5}.
On Aug 8, 2026, at 11:27rC>PM, Dag-Erling Sm|+rgrav <des@FreeBSD.org> wrote:
Charlie Li <vishwin@freebsd.org> writes:
Nothing will be backported until upstream can verify that the fixes do
not break existing (correct) behaviour. Currently only the imaplib
(CVE-2025-15366) fixes are present in the latest upstream
lang/python31{3,4,5}.
Not true. The patches I posted _are_ from upstream 3.15. There is an additional commit to imaplib commit which we could include:
commit d0921efb665aff26b378f495e5ff84f7e3fe649d
Author: Serhiy Storchaka <storchaka@gmail.com>
AuthorDate: Sun Jul 5 18:25:36 2026 +0300
Commit: GitHub <noreply@github.com>
CommitDate: Sun Jul 5 18:25:36 2026 +0300
gh-143921: Narrow the control character check in imaplib commands (GH-153067)
Only NUL, CR and LF are rejected now. Other control characters are
valid in quoted strings and can occur in mailbox names returned by
the server, so they are now accepted and sent quoted.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Upstream 3.13.15 and 3.14.7 already have both imaplib patches but not
the poplib patch.
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
To Dan's L's point, though.
And yeah, pkg-audit needs a knob that exempts specific CVEID's/vuxml entries/packages from its alert. If you've looked at your system, read
the tea leaves, asked other knowledgeable people, asked your favorite
LLM, and asked your magic 8 ball and you say "okay, this is an imap and
pop3 vuln, I am sure I'm not using those libs" OR "I have patched the
code that consumes those functions" OR "in fact I've deleted them post-install, let me go on with life", you should be able to.
On Tue, 11 Aug 2026 07:20:38 -0400
"Dan Langille" <dan@langille.org> wrote:
On Tue, Aug 11, 2026, at 6:17 AM, Dan Mahoney wrote:
To Dan's L's point, though.
[snip]
And yeah, pkg-audit needs a knob that exempts specific
CVEID's/vuxml entries/packages from its alert. If you've looked at
your system, read the tea leaves, asked other knowledgeable people,
asked your favorite LLM, and asked your magic 8 ball and you say
"okay, this is an imap and pop3 vuln, I am sure I'm not using those
libs" OR "I have patched the code that consumes those functions" OR
"in fact I've deleted them post-install, let me go on with life",
you should be able to.
Please my post to freebsd-ports@ titled "modifying pkg-audit to
ignore specified vulns"
re:
https://lists.freebsd.org/archives/freebsd-ports/2026-August/009871.html
I have done a manual proof-of-concept and now it's just a simple
matter of coding.
Dan,
IIUC, you are building your own packages. I would like to propose a
simpler approach that does not require any development whatsoever.
You could either patch the local ports tree or just revert the
commits that added these vulnerabilities to the XML file, and
build the VuXML DB from such patched port, publish the XML artifact to
be accessible from within Freshports network, and modify this setting in pkg.conf:
#VULNXML_SITE = "http://vuxml.freebsd.org/freebsd/vuln.xml.xz";
This way you just redirect the whole infrastructure to a custom
advisory DB, still built and relying on a slightly adjusted project DB.
As long as you don't push from this local git repo of ports, you can
even commit the change. (I am assuming here, you use git to fetch the
tree).
On Tue, Aug 11, 2026, at 8:25 AM, Piotr Smyrak wrote:
On Tue, 11 Aug 2026 07:20:38 -0400
"Dan Langille" <dan@langille.org> wrote:
On Tue, Aug 11, 2026, at 6:17 AM, Dan Mahoney wrote:
To Dan's L's point, though.
[snip]
And yeah, pkg-audit needs a knob that exempts specific
CVEID's/vuxml entries/packages from its alert. If you've looked
at your system, read the tea leaves, asked other knowledgeable
people, asked your favorite LLM, and asked your magic 8 ball and
you say "okay, this is an imap and pop3 vuln, I am sure I'm not
using those libs" OR "I have patched the code that consumes
those functions" OR "in fact I've deleted them post-install, let
me go on with life", you should be able to.
Please my post to freebsd-ports@ titled "modifying pkg-audit to
ignore specified vulns"
re:
https://lists.freebsd.org/archives/freebsd-ports/2026-August/009871.html >>
I have done a manual proof-of-concept and now it's just a simple
matter of coding.
Dan,
IIUC, you are building your own packages. I would like to propose a
simpler approach that does not require any development whatsoever.
You could either patch the local ports tree or just revert the
commits that added these vulnerabilities to the XML file, and
build the VuXML DB from such patched port, publish the XML artifact
to be accessible from within Freshports network, and modify this
setting in pkg.conf:
#VULNXML_SITE = "http://vuxml.freebsd.org/freebsd/vuln.xml.xz";
This way you just redirect the whole infrastructure to a custom
advisory DB, still built and relying on a slightly adjusted project
DB.
As long as you don't push from this local git repo of ports, you can
even commit the change. (I am assuming here, you use git to fetch
the tree).
That is a nice idea. Thank you. That helps me, definitely.
The "tricky" part may be knowing there is a new VuXML to build and
then distributing it.
I'm an outlier. Most people do not build their own.
[..]IIUC, you are building your own packages. I would like to propose a simpler approach that does not require any development whatsoever.
You could either patch the local ports tree or just revert the
commits that added these vulnerabilities to the XML file, and
build the VuXML DB from such patched port, publish the XML artifact
to be accessible from within Freshports network, and modify this
setting in pkg.conf:
#VULNXML_SITE = "http://vuxml.freebsd.org/freebsd/vuln.xml.xz";
You could setup a git hook that detects changes to the XML files in security/vuxml/vuln and triggers a rebuild of your own DB.
On Tue, Aug 11, 2026 at 08:47:12PM +0200, Piotr Smyrak wrote:
IIUC, you are building your own packages. I would like to
propose a simpler approach that does not require any
development whatsoever. You could either patch the local ports
tree or just revert the commits that added these
vulnerabilities to the XML file, and build the VuXML DB from
such patched port, publish the XML artifact to be accessible
from within Freshports network, and modify this setting in
pkg.conf:
[..]#VULNXML_SITE = "http://vuxml.freebsd.org/freebsd/vuln.xml.xz";
You could setup a git hook that detects changes to the XML files in security/vuxml/vuln and triggers a rebuild of your own DB.
This is not really the way to address CVE alert fatigue for people
that do not want to hack around the alerting system by building their
own stuff left and right.
Most of my machines do not build anything locally, or even have a
ports or source tree checked out (using binpkg and freebsd-update
saves quite a significant bit of CPU = power = co2 costs...). So
having something that tells daily-security "ignore these two vulns,
please" would be much more useful for me.
This is not really the way to address CVE alert fatigue for people
that do not want to hack around the alerting system by building their
own stuff left and right.
Of course. And I agree with you. Still this is a voluntary free software project. So despite patches being welcome, they may not come ready
tomorrow.
In test reporting there is a concept of an expected fail, or
acknowledged one, and certain monitoring systems allow for flipping
such forever failing test item into green by marking it as such. Which
may as well in future turn red when it stops failing and thus then
needs to be turned around again.
What I am trying to say above is that the approach may also depend on
what monitoring tool one uses.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:39:38 |
| Calls: | 1,194 |
| Files: | 1,353 |
| D/L today: |
2 files (1,590K bytes) |
| Messages: | 290,985 |