<div dir="auto"><div>Hi Severin,</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Thank you and best regards,</div><div dir="auto">Volker</div><div dir="auto"><br></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Severin Gehwolf <<a href="mailto:sgehwolf@redhat.com">sgehwolf@redhat.com</a>> schrieb am Do., 17. Aug. 2023, 02:34:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Wed, 2023-08-16 at 22:33 -0700, Volker Simonis wrote:<br>
> Hi,<br>
> <br>
> We would like to downport JDK-8313765 [1] to jdk11u-dev and jdk17u-<br>
> dev and propose to release new versions of 11.0.20 and 17.0.8. <br>
> <br>
> JDK-8313765 [1] is a fix for a regression in the processing of zip<br>
> files containing extended ZIP64 entries that was introduced by JDK-<br>
> 8302483 in the July security update.<br>
<br>
That bug introduced the jdk.util.zip.disableZip64ExtraFieldValidation<br>
property so as to have a way to disable the new extra validation. That<br>
seems like a work-around to me. Is that not working?<br>
<br>
I'll also note that CVE-2023-22036 (8302483) has a score of 3.7 (low)<br>
if that is being turned off.<br>
<br>
> This regression affects a significant number of our internal as well<br>
> as external customers (you can find more details in the JBS issue [1]<br>
> and the original PR [2]).<br>
> <br>
> We think that the blast radius of the regression justifies a re-spin<br>
> of 11.0.20 and 17.0.8 and we are planning to do this for Amazon<br>
> Corretto. We would however appreciate if we could agree on this<br>
> downport among all maintainers and come up with a synchronized up-<br>
> stream fix and versioning. We've published corresponding PRs for<br>
> jdk11u-dev [3] and jdk17u-dev [4].<br>
<br>
While I agree that it makes sense to fix this in the next JDK 17<br>
(17.0.9) and 11 (11.0.21) releases, I'm not sure this warrants an<br>
upstream respin (provided the work-around does what it's supposed to).<br>
<br>
Thanks,<br>
Severin<br>
<br>
> <br>
> [1] <a href="https://bugs.openjdk.org/browse/JDK-8313765" rel="noreferrer noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8313765</a><br>
> [2] <a href="https://github.com/openjdk/jdk/pull/15273" rel="noreferrer noreferrer" target="_blank">https://github.com/openjdk/jdk/pull/15273</a><br>
> [3] <a href="https://github.com/openjdk/jdk11u-dev/pull/2084" rel="noreferrer noreferrer" target="_blank">https://github.com/openjdk/jdk11u-dev/pull/2084</a><br>
> [4] <a href="https://github.com/openjdk/jdk17u-dev/pull/1670" rel="noreferrer noreferrer" target="_blank">https://github.com/openjdk/jdk17u-dev/pull/1670</a><br>
<br>
</blockquote></div></div></div>