On Tue, May 12, 2026 at 6:07 PM Mark Thomas <[email protected]> wrote: > > All, > > Historically, our approach to security fixes has been: > > - take advantage of any opportunity to disguise what is actually being > fixed > - commit the fix with a non-obviously security related commit message > - tag > - vote > - release > > The time between the commit and tag depended on: > - the severity of the issue (more severe, closer to the tag) > - how obvious the fix was (more obvious, closer to the tag) > > The vote period is usually the standard >= 72 hours but we have reduced > that to a few hours when we have needed to release in a hurry. > > AI changes all of this. It is trivial (the ASF security team did this > with the 9.0.118 tag) to get AI to review the diff between tags and > identify the security fixes. It took about 20 minutes and several of the > CVEs I've just published were in the first few results. Work colleagues > have been doing something similar for a while too. > > Given this change in circumstances, I think it is worth reconsidering > how we approach security vulnerabilities and releases. > > 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.
Maybe ? > - Build and vote on releases in private then push to the pubic repos and > announce the CVEs as part of the release process. I would do that only if there's a critical issue (which has not happened for a long time). But let's plan for it ahead of time: if there's a critical CVE found, then +1 for doing that. > - 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. I plan to do that (sorry, I started with the javadoc instead ...). It is important to do it all the time, as soon as a more "capable" model is released (I'm not sure it is really more capable, but since they're all quite different they might catch different issues). > - Reduce the voting period. That's when some significant issues are caught. If we release with a regression, then people would not want to upgrade, so they become vulnerable for even longer. > - Something else? Go back in time, don't do any OSS in the first place, so LLMs don't have anything to be trained on. Rémy > Thoughts? > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
