RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..)

[Volker Simonis]

On Mon, Mar 28, 2022 at 10:53 AM Alan Bateman <Alan.Bateman at 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