On 13/05/2026 18:52, Christopher Schultz wrote:
On 5/12/26 12:07 PM, Mark Thomas wrote:
<snip/>
A few random ideas to get the discussion started:
- Where mitigation is available (e.g. via configuration) publish the CVE
at the same time as the fix is committed - i.e. before the release.
This seems like something to consider.
- Build and vote on releases in private then push to the pubic repos and
announce the CVEs as part of the release process.
I don't like private voting at all. Logistically, it's ugly, then we
need to tally votes in private and post them later. They might be forged
or misrepresented (though unlikely). We have to have a private repo,
more digital paperwork, more opportunities to break something during the
rush to push the release out the door, etc.
Finally, if the release drops at the same time we push the private ->
public, then AI has 20 minutes to find the vulnerabilities and the
admins of the world also have 20 minutes to install their updates.
None of that sounds good to me.
I think most of those concerns could be fixed with automation but the 20
minute concern still applies.
- Run some (which?) AI security scans on the Tomcat code base to try get
ahead (unlikely) but at least keep up with anything an attacker could
find.
This sounds like a good thing to do. I suspect that some committers
employers are already setting up tooling along these lines. We could ask
them to throw Tomcat's code into the mix for scanning.
- Reduce the voting period.
I'm not sure this is okay per ASF policy. I seem to remember that some
project (Subversion?) never held release votes precisely because they
didn't want to deal with the official rules on "voting". So they just
pushed "versions" without any voting.
We can't do this generally. We can on a case by case basis if we need to.
- Something else?
Is "no changes" an option?
It is an option. Not sure if it is a viable one. Then again, I'm not
sure any of the options are viable at this point.
Or is your position that if AI can figure out the changes in 20 minutes,
there is no point in putting up any kind of smoke-screen; we may as well
just commit security fixes directly and without any attempt to hide them?
That is certainly a large part of it.
I'm curious about the report of ASF Security doing this with the 9.0.118
tag and coming up with the same CVEs that we had already fixed. That
sounds almost too convenient, unless you mean it looked at the diffs
from 9.0.117 and said "it looks like they fixed XXX YYY and ZZZ in spite
of the weird commit comments".
Yes. They ignored the comments and just looked at the commits.
I remember someone from the httpd team presenting at an ASF conference
one year saying "we are lying to our users when we silently commit
security fixes and then publish later, and it doesn't make us feel
good". Does anyone know if httpd ever changed their methodology?
I haven't seen any sign of a process change.
The speed of AI is the fundamental problem and I can't see a solution to
that that doesn't involve users updating an awful lot faster (orders of
magnitude faster) than they typically do at the moment. And that too
carries risk.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
