On Mon, Mar 28, 2022 at 10:53 AM Alan Bateman <alan.bate...@oracle.com> wrote: > > On 22/03/2022 12:28, Volker Simonis wrote: > > : > > I don't really understand this concern? Do you mean what happens if > > another thread is changing the content of the output buffer during an > > inflate? I think such a use case has never been well-defined and > > amending the specification won't change anything for such a situation. > The setup means that user code has access to temporary storage used by > the inflater library. It's important that nothing sensitive leaks, also > important that flipping bits in any of the bytes in that temporary > buffer doesn't lead to something that is considered a security issue. If > you are confident that nothing bad can happen they great, I'm just > pointing out things to consider when allow for the behavior discussed here.
As I wrote before, the extra data written into the output buffer isn't sensitive because it can only originate from the history buffer (aka "sliding window"). Also, this data is already exposed today if the `Inflater` class is being used stand-alone, because in contrast to `InflaterInputStream::read(..)`, `Inflater::inflate(..)` doesn't guarantee to leave the content beyond the last read byte unaffected. Finally, the referenced zlib-chromium implementation with the mentioned behavior is the default zlib implementation in on Android and Chrome browsers. I've created a pull request and an associated CSR for this issue under: https://github.com/openjdk/jdk/pull/7986 https://bugs.openjdk.java.net/browse/JDK-8283758 Finally I've also created a PR to fix the ZipFSOutputStreamTest mentioned in my initial mail: https://github.com/openjdk/jdk/pull/7984 Can you please kindly take a look and review? Thank you and best regards, Volker PS: just saw you've already approved https://github.com/openjdk/jdk/pull/7984 :) > > -Alan
