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

[Martin Balao]

On Thu, 17 Nov 2022 16:06:39 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> I'd like to backport this enhancement for parity with Oracle and the security roadmap [1]
>> 
>> The patch is based on the OpenJDK11 backport [2]
>> 
>> The changes are the following:
>> 
>> 1. java.security.* files are changed on the base of java.security
>> 2. jdk/src/share/classes/sun/security/tools/jarsigner/Main.java : signJar method is merged manually because of differences in the JDK-8172404 backport. 
>> 3. jdk/test/java/security/Security/signedfirst/DynStatic.java : modules dependency removed, changed path to utility classes
>> 4. jdk/test/sun/security/tools/jarsigner/Test4431684.java : changed library path. List.of() is not available in JDK8, so it is replaced with Arrays.asList()
>> 5. jdk/test/lib/security/SecurityUtils.java is updated to make removeFromDisabledAlgs method public. It is required by newly added test Test4431684.java
>> 6. jdk/test/sun/security/tools/jarsigner/DefaultOptions.java is skipped, it was introduced in JDK9 by JDK-8049834 as default_options.sh but never backported to JDK8
>> 7. JDK8 has jdk/test/sun/security/tools/jarsigner/diffend.sh test instead of jdk/test/sun/security/tools/jarsigner/DiffEnd.java. diffend.sh was not renamed to DiffEnd.java because of JDK-8180573 is not backported to JDK8. JDK-8180573 is a big refactoring and out of scope for this issue. diffend.sh updated accordingly - SHA1 replaced to SHA-256
>> 8. JDK8 has jdk/test/sun/security/tools/jarsigner/ec.sh test instead of jdk/test/sun/security/tools/jarsigner/EC.java. ec.sh was not renamed to EC.java because of JDK-8180573 is not backported to JDK8. JDK-8180573 is a big refactoring and out of scope for this issue. ec.sh has all required changes by JDK-8172404
>> 9. JDK8 has jdk/test/sun/security/tools/jarsigner/nameclash.sh test instead of jdk/test/sun/security/tools/jarsigner/NameClash.java. nameclash.sh was not renamed to NameClash.java because of JDK-8180573 is not backported to JDK8. JDK-8180573 is a big refactoring and out of scope for this issue. nameclash.sh has all required changes by JDK-8172404
>> 10. JDK8 has jdk/test/sun/security/tools/jarsigner/oldsig.sh test instead of  jdk/test/sun/security/tools/jarsigner/OldSig.java. oldsig.sh was not renamed to OldSig.java because of JDK-8180573 is not backported to JDK8. JDK-8180573 is a big refactoring and out of scope for this issue. The changes in the oldsig.sh are not required because of JDK-8217375 is not backported to JDK8.
>> 11. jdk/test/sun/security/tools/jarsigner/OldSig.props is not backported as it is not used in the  jdk/test/sun/security/tools/jarsigner/oldsig.sh
>> 
>> All java/security/Security sun/security/tools regression tests passed
>> 
>> [1] - https://www.java.com/en/jre-jdk-cryptoroadmap.html
>> [2] - https://github.com/openjdk/jdk11u-dev/commit/5a0824ba813ceda47847c9162c8a10bb0b8898e8
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   oldsig test updated again

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.

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

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