Hi all, I proposed publishing 0.1.0 to Piotr and we agreed. My argument for publishing _something_ is to lower the rate of incoming reports that won't fit the model. In particular, CWEs are not automatic CVEs.
This is clearly marked as version 0.1.0 so it will evolve. Let's discuss what's in and out of bounds. I think I might have dragged my feet on this; might as well make thisna public thread, so, repeating what I wrote on the security ML: My high-level and ideal goal is to be able to define or refine our Commons-wide security model. To this end, we will need some generalities and clear specifics that may have to reside in each component. In general, as low-level libraries, the API is a boundary where all input is trusted. By this, I mean that a developer is responsible for the code they write against that API, and, more importantly, they can change that code. Where the dilemma is, IMO, is when the input to an API is a file or stream that outside of the developer's control, for example: - class and JAR (ZIP) files as input to Commons BCEL - Configuration files as input to Commons Configuration - ZIP, TAR, and so on, as input to Commons Compress - Script files as input to Commons JEXL In the above, I use the term "files" to mean a data source whether it is actually a Java File, Path, Reader, or InputStream (you get the idea). In these cases, it seems unreasonable for a developer to do anything to sanitize any of this data. The developer can write code that only accepts input from a specific folder and not from the web, or reject files beyond a given size, for example. But those types of examples seem to be the limit of what can be reasonably expected (IMO). While a part of me would be happy to wash my hands of it all and say "everything you report might be a bug, never a CVE, because everything is trusted", it feels unrealistic. WDYT? My heart is not set either way and I'd like to get everyone's help here to shape a long lasting policy. We can settle with what we have today, or refine it. HTH, Gary On Tue, Sep 22, 2026, 17:43 Arnout Engelen <[email protected]> wrote: > I was surprised to see this published. From the earlier discussion on > the Commons Security list > (https://lists.apache.org/thread/dw992t9771drg3gjfqo2zvxkr8vpqxvg) my > understanding (which I also stated in that thread) was that the model > proposed there was longer-term intended to grow into a holistic > public-facing threat/security model, but that for the foreseeable > future it was only meant to inform the internal LLM audits, not > something we'd publicly commit to. > > I think this model is too ambitious. For the internal LLM audit that > is no problem: worst-case it'd find some things that we'd end up > fixing as hardening instead of as vulnerabilities. For posting > publicly I think it is a problem: it means we're making a public > commitment to promises that I'm not sure we're ready to commit to. > > For example, the model claims: > > === > for Compress, Configuration, Text, and FileUpload, passing any data to > them in their default configuration will not: > > cause excessive CPU consumption, > cause excessive memory allocation, > === > > Do we really have consensus that this is something we want to commit > to? TBH I don't think we have the bandwidth to make good on that > promise, and I don't think it's necessary. > > > Kind regards, > > Arnout > > On Tue, Sep 22, 2026 at 9:09 PM Gary D. Gregory <[email protected]> > wrote: > > > > Fixed typo in the subject. > > > > Gary > > > > On 2026/09/22 17:47:18 Gary Gregory wrote: > > > Hi All, > > > > > > Thank you to Piotr for helping get our threat model off the ground. > > > > > > Please review for content and typos, if you feel so inclined: > > > > > > - https://commons.apache.org/threat-model-short-0.1.0.html > > > - https://commons.apache.org/threat-model-0.1.0.html > > > > > > Both are linked from https://commons.apache.org/security.html > > > > > > TY, > > > Gary > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > -- > Arnout Engelen > ASF Security Response > Apache Pekko PMC member, ASF Member > NixOS Committer > Independent Open Source consultant > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > >
