Downporting JDK-8313765 to jdk11u and jdk17u and respinning 11.0.20 and 17.0.8

[Volker Simonis]

Hi Severin,

As you correctly noted, the workaround will disable all ZIP64 field
validation and expose customers to the known vulnerability. This is not
acceptable for our customers and I don't think we should force customers
into a position where they have to choose between security and
functionality.

Moreover we know from big customers who are holding back the whole security
update untill this issue gets fixed because they cannot easily add the new
property to all of their deployments and are afraid to break their services.

I've privately talked to Christoph and Goetz (who are both on vacation) and
they both support a synchronized up-stream respin. Andrew Haley also the
indicated support last week when I talked to him at JVMLS (would be
interested in getting his opinion here on this thread).

The only tricky thing is the 11u and 17u repos already contain the changes
for the October release. So after we got the approval and pushed the
downports to 11u-dev and 17u-dev we have to cherry pick them and apply them
in a new branch right on top of the 11.0.20/17.0.8 GA changes (and not the
current HEAD of those repos). We'd also had to bump the version strings in
those new branches. But this has all been done in the past already and I'm
happy to do the work.

I'd therefore kindly ask you to reconsider your opinion Severin and support
a re-spin for the benefit of the OpenJDK community and customers.

Thank you and best regards,
Volker


Severin Gehwolf <sgehwolf at redhat.com> schrieb am Do., 17. Aug. 2023, 02:34:

> Hi,
>
> On Wed, 2023-08-16 at 22:33 -0700, Volker Simonis wrote:
> > Hi,
> >
> > We would like to downport JDK-8313765 [1] to jdk11u-dev and jdk17u-
> > dev and propose to release new versions of 11.0.20 and 17.0.8.
> >
> > JDK-8313765 [1] is a fix for a regression in the processing of zip
> > files containing extended ZIP64 entries that was introduced by JDK-
> > 8302483 in the July security update.
>
> That bug introduced the jdk.util.zip.disableZip64ExtraFieldValidation
> property so as to have a way to disable the new extra validation. That
> seems like a work-around to me. Is that not working?
>
> I'll also note that CVE-2023-22036 (8302483) has a score of 3.7 (low)
> if that is being turned off.
>
> > This regression affects a significant number of our internal as well
> > as external customers (you can find more details in the JBS issue [1]
> > and the original PR [2]).
> >
> > We think that the blast radius of the regression justifies a re-spin
> > of 11.0.20 and 17.0.8 and we are planning to do this for Amazon
> > Corretto. We would however appreciate if we could agree on this
> > downport among all maintainers and come up with a synchronized up-
> > stream fix and versioning. We've published corresponding PRs for
> > jdk11u-dev [3] and jdk17u-dev [4].
>
> While I agree that it makes sense to fix this in the next JDK 17
> (17.0.9) and 11 (11.0.21) releases, I'm not sure this warrants an
> upstream respin (provided the work-around does what it's supposed to).
>
> Thanks,
> Severin
>
> >
> > [1] https://bugs.openjdk.org/browse/JDK-8313765
> > [2] https://github.com/openjdk/jdk/pull/15273
> > [3] https://github.com/openjdk/jdk11u-dev/pull/2084
> > [4] https://github.com/openjdk/jdk17u-dev/pull/1670
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-updates-dev/attachments/20230817/5d94e6a2/attachment.htm>