[jdk8u-dev] RFR: 8269039: Disable SHA-1 Signed JARs [v4]

[Alexey Bakhtin]

On Fri, 25 Nov 2022 16:24:49 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Notice that for the 2019-01-01 max date to work, the JAR has to be timestamped by a TSA (Time Stamp Authority).
>> 
>> While the default behavior is changed (there is a [CSR attached to this bug](https://bugs.openjdk.org/browse/JDK-8272155) that has to be proposed for 8u as I commented before), the user can restore backward compatibility by re-enabling the use of the SHA-1 algorithm without conditions for JAR signing. You can verify how this works in the fix for [this test](https://github.com/openjdk/jdk8u-dev/pull/154/commits/57d0b0ba5a93c5ca2a88b2d8abc7f6f24a56a853). Also, the Release Note attached to this bug indicates how to [restore backward compatibility](https://bugs.openjdk.org/browse/JDK-8274081).
>> 
>> These crypto changes are part of the [crypto roadmap](https://www.java.com/en/jre-jdk-cryptoroadmap.html) as @jerboaa  mentioned. I think it's good to be aligned on that roadmap for parity with other JDKs and for security. The change has been backported to other JDK releases too, such as 11u. While I understand the concerns discussed here, I think that we have countermeasures to mitigate that and my recommendation to 8u maintainers is to approve this change.
>
>> Notice that for the 2019-01-01 max date to work, the JAR has to be timestamped by a TSA (Time Stamp Authority).
>> 
>> While the default behavior is changed (there is a [CSR attached to this bug](https://bugs.openjdk.org/browse/JDK-8272155) that has to be proposed for 8u as I commented before), the user can restore backward compatibility by re-enabling the use of the SHA-1 algorithm without conditions for JAR signing. You can verify how this works in the fix for [this test](https://github.com/openjdk/jdk8u-dev/pull/154/commits/57d0b0ba5a93c5ca2a88b2d8abc7f6f24a56a853). Also, the Release Note attached to this bug indicates how to [restore backward compatibility](https://bugs.openjdk.org/browse/JDK-8274081).
>> 
>> These crypto changes are part of the [crypto roadmap](https://www.java.com/en/jre-jdk-cryptoroadmap.html) as @jerboaa mentioned. I think it's good to be aligned on that roadmap for parity with other JDKs and for security. The change has been backported to other JDK releases too, such as 11u. While I understand the concerns discussed here, I think that we have countermeasures to mitigate that and my recommendation to 8u maintainers is to approve this change.
> 
> I agree it needs to be done, but I think, at this stage, it should have been delayed to 8u372. There are follow-on issues for this - e.g. https://bugs.openjdk.org/browse/JDK-8275887 - which will  now have to be resolved during rampdown.

@gnu-andrew, Thank you for the comment. I've submitted [PR](https://github.com/openjdk/jdk8u-dev/pull/197 ) for the backport of JDK-8275887

-------------

PR: https://git.openjdk.org/jdk8u-dev/pull/154