Mark,
On 5/13/26 3:53 PM, Mark Thomas wrote:
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.
+1
I see this as the biggest problem.
I don't think any amount of tweaking of the release process is going to
make admins go any faster. Upgrades simply take time, even if it's not a
lot of time.2/3 of the world (assuming an even distribution of admins,
which isn't the case) won't even get the announcement until their next
business day, so 20 minutes has already long past. I wouldn't upgrade
anything like this without testing it in at least one other environment
beforehand and I would suspect that very few environments are completely
automated for infrastructure upgrades. Application upgrades, sure. But
not the underlying server.
So while we may be able to reduce the time between commit and release,
I'm not sure that's the time that matters.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
