There seems to be consensus here, so I'll update the page. TY! Gary
On Mon, Oct 5, 2026 at 10:07 AM Gilles Sadowski <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
