Hello. Le lun. 5 oct. 2026 à 13:17, Arnout Engelen <[email protected]> a écrit : > > 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,
IIUC, this would not happen in normal usage, but in case the file format is being abused. If so, I agree that a "Commons" library is not the place where resources, such as CPU or RAM, can be controlled. This is rather a general issue that must be handled in the same way[1], whatever potentially runaway code is being called, by the application. > === > > from this published model: I don't think we've ever made such promises > before and I don't think we should start now. +1 [Nor any more than the JDK can make such promises.] > We can make narrower > promises for the specific cases where we do reasonably can and want to > deliver on those. Yes, we can implement "hardening checks" that e.g. prevent propagating "abnormal" values (like a negative size), but we cannot define "reasonable" limits on CPU or RAM. Gilles [1] Can "Commons" advertise a recommended way, or implement one? > > > > [...] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
