On Wed, Sep 23, 2026 at 1:53 AM Gary Gregory <[email protected]> wrote: > 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.
I much agree with that goal (and indeed CWE is just a classification system for CVEs, it should not drive what should be a CVE). > This is clearly marked as version 0.1.0 so it will evolve. If we promise things in our security/threat model, I don't think we can reasonably hide behind "yes but we marked it 0.1.0 so you shouldn't actually have trusted it", so we should only promise things we're actually ready to promise and commit to long-term, and be conservative about that. > 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: Good idea. I'll repeat my response here as well :) > 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. All good! > 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). I agree it is often unreasonable to expect a developer to sanitize such input. I do think it's reasonable for a developer to, when they process possibly-malicious input, deal with the risk of DoS conditions: they can decide to "not care" (and leave it to the operator to kill a hanged process or clean up if it ever happens), or have some automation/isolation to take care of that automatically. I think our default model should not promise the absence of DoS issues, and at most we should have specific cases where we do promise it (e.g. uncompressing Zip and Tar archives, but not all the exotic ones). Even for more serious issues such as SSRF, XXE and RCE: the fact that it wouldn't be reasonable to expect a developer to sanitize file/stream inputs doesn't mean they get a free pass to dump possibly-malicious input into any component. I think there's plenty of places where it's perfectly reasonable to say "this API is simply not suitable to be used with possibly-malicious input". I even think that should be our 'default' position - though I agree there's many components (like most of Compress, Imaging, etc) where we'd want to say "possibly-malicious input can cause DoS but not worse". https://commons.apache.org/proper/commons-bcel/security.html 's === processing untrusted () data is supported to the extent that this should never allow the supplier of the data to trigger arbitrary code execution, filesystem or network access. It may still trigger other crashes, such as for example StackOverflowError or OutOfMemoryError: if your code uses (this component) to process untrusted input then it is up to you to compensate for that as necessary. === seems like a good model for those to me. Specifically, I think we should remove the promise that "Compress, Configuration, Text, and FileUpload" can never lead to DoS, and keep it only for Compress when processing Zip or Tar input. We should only keep the promise that they won't lead to more serious issues. Cheers, Arnout Commons PMC > 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] > > > > > > -- 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]
