Hello. Le jeu. 14 déc. 2023 à 12:10, Arnout Engelen <enge...@apache.org> a écrit : > > Hello Commons developers, > > I'd like to discuss what our security ambitions are for components like > Commons Imaging, Compress, Codec and IO: > > Generally for Commons, we say that unless otherwise specified it is up to > the user of the library to make sure any input is either trusted or > correctly validated/sanitized (https://commons.apache.org/security.html). > > For these modules it might make sense to be a little more nuanced: > https://commons.apache.org/proper/commons-imaging/ already explicitly says > it intends to be "more secure against corrupt/malicious images", and while > the others don't seem to say it explicitly AFAICS in practice we consider > it OK to decompress/decode/... untrusted input at least to some degree. > > So what does that mean? > > * I'd say parsing/decompression/decoding should never allow malicious input > to trigger arbitrary code execution(?)
+1 > * Should parsing/decompression/decoding protect against 'disproportionate' > CPU usage? > * Should parsing/decompression/decoding protect against 'disproportionate' > memory usage? > * Should parsing/decompression/decoding protect against 'disproportionate' > disk usage? > > Where we say 'yes', I vaguely recall a similar conversation where the answer was "no" (IIRC). [Along: "What is the definition of disproportionate?"] > we should also decide whether we intend to treat such > issues as security problems (that should be fixed with some priority and, > after release, disclosed in an advisory) or bugs/improvements (where we can > possibly take more of an 'issues and patches welcome' position). > > I'm curious about your thoughts! > If "Commons" intends to provide utilities with the same purpose across components, it would be sensible to have them defined in a "lower"-level component on which [Imaging], [Compress], ... would depend. Especially if the corresponding code is purported to be focused on security, "let's just copy the source" should not be allowed. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
