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.