Re: Best way to help get CVE's addressed

From: Charlie Li <vishwin_at_freebsd.org>
Date: Mon, 25 May 2026 18:47:31 UTC
Pete Wright wrote:
> hello - i was hoping to find the best place to help address outstanding 
> CVE's for python pkgs.  i noticed charlie's last comment in this bug:
> 
tl;dr the best balance is allowing upstream and python@ to do their jobs.
> i understand that it is a lot of effort to keep on top of these patches. 
> since i run python systems for work i would like to do my fair share to 
> help get these patched in a timely manner.  my goal would be to have 
> "pkg audit" be clean for my python webapp servers.
> 
The other, bigger, issue that I did not elaborate further on there, 
because it is not entirely relevant to that PR, deals with how broken 
the CVE system, and by extension vuxml, is. The more recent vuxml 
entries were not added or validated by the python@ team, and the timing 
in which they were added did not correspond to upstream having cut 
releases addressing them. Some of those entries, particularly the one 
concerning IMAP, upstream still needs to work through not regressing 
previously correct behaviour amongst other things.

The better way to do vuxml is what many other committers already do with 
other ports: add the entries *after* a release or other off-cycle 
commit(s) addressing the entries are ready for use. Adding entries that 
upstream do not have mitigations for does not benefit anyone (apart from 
some kind of vanity).

Apparently the word "security" and the want for clean `pkg audit`s 
evokes some sort of emotional response to the point of bullying and 
subverting maintainers to re-prioritise existing work and processes, 
which already include dealing with security issues. We all want clean 
`pkg audit`s at the end of the day, but a big part of security is 
actually reviewing entries on your own and comparing them to *your* 
threat model rather than blindly reacting.

> i searched bugzilla and wasn't sure if we are filing reports for each 
> CVE and tracking there, or are our efforts better spent focusing on 
> getting a newer default python out the door?
> 
Please do not do anything of this sort, they only slow things down. 
Security reports almost always affect every supported and development 
branch upstream at the same time.

-- 
Charlie Li
...nope, still don't have an exit line.