On Wed, Sep 23, 2026 at 10:51 AM Arnout Engelen <[email protected]> wrote:
> On Wed, Sep 23, 2026 at 1:53 AM Gary Gregory <[email protected]> wrote:
> > 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.
Since there were no more replies here, I feel we should remove the
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,
===
from this published model: I don't think we've ever made such promises
before and I don't think we should start now. We can make narrower
promises for the specific cases where we do reasonably can and want to
deliver on those.
Cheers,
Arnout
> > 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
--
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]
