Re: Status of Python 3.11

"Edward Sanford Sutton, III" <[email protected]>
Newsgroups gmane.os.freebsd.devel.ports
Message-ID <SA1PR11MB88116A9EB4D7ACDB8D71211DE6D02@SA1PR11MB8811.namprd11.prod.outlook.com>
On 8/7/26 16:24, Dan Langille wrote:
> 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.

   Until such a useful feature is added, you could self-filter one way 
or another:

pkg audit >~/vuln.old
# edit list to contain only vulnerabilities you do not care about
pkg audit -F >~/vuln.new
# a simple general output
diff ~/vuln.*|egrep "^<"|less
# an easily modified general output, in case you want it to help
# you review things you can now remove.
diff -y ~/vuln.*|egrep ">"|less

   You can end up with a short name script or alias that does the 
fetch+diff.
   Alternatively you can maintain your own vulnerability database 
variation where you apply select removals and rebuild with other new 
changes as they come along.
   Its easy to find yourself in a situation where a vulnerability is not 
relevant, but if another relevant vulnerability is used then preexisting 
vulnerability threats should be reconsidered.
   I's also find it helpful if we could run a check against the current 
pkg repo, and separately against the ports tree, to see if current 
versions include any fixes. I normally do that one port at a time by 
taking `pkg audit -q` output as a list of packages to check and running 
a series of repeats of it with an additional parameter like

pkg audit -q `make -C /usr/ports/\`pkg query %o python311-3.11.15_4\` 
-VPKGNAME`

   I should probably script that too but never got around to it and just 
manually pass the few names in, usually as a variable set at the start 
or a separate command for easy editing.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.