8269039: Disable SHA-1 Signed JARs by alexeybakhtin · Pull Request #154 · openjdk/jdk8u-dev

alexeybakhtin · 2022-11-03T15:34:01Z

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:

java.security.* files are changed on the base of java.security
jdk/src/share/classes/sun/security/tools/jarsigner/Main.java : signJar method is merged manually because of differences in the JDK-8172404 backport.
jdk/test/java/security/Security/signedfirst/DynStatic.java : modules dependency removed, changed path to utility classes
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()
jdk/test/lib/security/SecurityUtils.java is updated to make removeFromDisabledAlgs method public. It is required by newly added test Test4431684.java
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
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
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
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
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.
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] - openjdk/jdk11u-dev@5a0824b

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8269039: Disable SHA-1 Signed JARs

Reviewers

Martin Balao (@martinuy - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev pull/154/head:pull/154
$ git checkout pull/154

Update a local copy of the PR:
$ git checkout pull/154
$ git pull https://git.openjdk.org/jdk8u-dev pull/154/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 154

View PR using the GUI difftool:
$ git pr show -t 154

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/154.diff

bridgekeeper · 2022-11-03T15:35:43Z

👋 Welcome back abakhtin! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2022-11-03T15:36:41Z

This backport pull request has now been updated with issue from the original commit.

mlbridge · 2022-11-03T15:42:53Z

Webrevs

jerboaa · 2022-11-11T16:05:12Z

@martinuy Could you please help review this? Thank you!

martinuy

Hi @alexeybakhtin ,

Thanks for proposing this backport.

In addition to the inlined comments, I have this additional observation:

jdk/test/sun/security/tools/jarsigner/oldsig.sh is using SHA1, as well as JDK-11's OldSig.java. The security properties file that is now passed has the following comment: "Re-enable SHA-1 since OldSig.java test uses it". You mentioned 8217375 as the reason why changes are not required for the backport, but I'm having difficulties to find the connection and wonder if we should re-enable SHA1 for oldsig.sh. Can you please elaborate a bit on this?

Thanks,
Martin.-

martinuy · 2022-11-15T16:05:32Z

jdk/test/java/security/Security/signedfirst/DynStatic.java

+import java.nio.file.Paths;
+import java.util.List;
+
+import jdk.test.lib.process.ProcessTools;


The ProcessTools class in JDK-8 has always been jdk.testlibrary.ProcessTools. To use it, you would only need @library /lib/testlibrary in the test's JTREG header. Unfortunately, one backport -which I presume to be JFR- introduced the same class, from a newer JDK release, at a different location. So we now have duplicated code for this test library and it is causing confusion: I can now see a couple of TLS test using this library when they shouldn't. Until we get rid of this technical debt, I suggest that all JDK-8 tests keep using jdk.testlibrary.ProcessTools.

Thank you. You are right. jdk.testlibrary.ProcessTools is a better choice even if some modifications are required.
Fixed

Good, thanks.

martinuy · 2022-11-15T16:49:39Z

jdk/test/sun/security/tools/jarsigner/TimestampCheck.java

+                        .shouldContain("treated as unsigned")
+                        .shouldMatch("Timestamp.*digest.*SHA-1.*(disabled)");

                // Disabled algorithms


Isn't this comment removed?

Thank you. Fixed

Good, thanks.

alexeybakhtin · 2022-11-16T15:51:23Z

Hello @martinuy
Thank you a lot for the review.
The major changes in the oldsig.sh were done in terms of JDK-8217375. JDK-8217375 adds -verbose option and the output parsing. Without these changes, the test passed successfully with and without SHA1. The property changes are not required.
If you believe these changes should be done in terms of this patch, I can do it.

martinuy · 2022-11-17T06:58:36Z

I've verified that test oldsig.sh passes with and without SHA1. This is because even if a disabled algorithm is used for signing or if a disabled algorithm is found when verifying a signature, jarsigner returns 0. While the jar is actually signed, the verification fails and the jar is considered unsigned. The test should do better in the assertion statement, for example by checking sm ... B.class in a verbose output. The test in later JDK releases has been fixed and the assertion statement improved.

@alexeybakhtin, my suggestion would be to backport the JDK-11 OldSig.java test to JDK-8. I agree with you that doing all the .sh -> .Java test conversions is out of the scope of this backport, but I would make an exception for the case discussed here because, otherwise, we would be having a broken/useless test in JDK-8. I'm also open to consider adding a better assertion statement to the current .sh test. What do you think?

alexeybakhtin · 2022-11-17T08:30:01Z

@martinuy, thank you for the review again.
I've updated the existing oldsig.sh and added OldSig.props file. Now test validates the signature.

martinuy · 2022-11-17T15:51:46Z

@alexeybakhtin , thanks for addressing this concern.

What do you think about the following (minor) change to your proposal?

diff --git a/jdk/test/sun/security/tools/jarsigner/oldsig.sh b/jdk/test/sun/security/tools/jarsigner/oldsig.sh
index fcc2293d5d..5c8e328367 100644
--- a/jdk/test/sun/security/tools/jarsigner/oldsig.sh
+++ b/jdk/test/sun/security/tools/jarsigner/oldsig.sh
@@ -79,7 +79,8 @@ ${TESTJAVA}${FS}bin${FS}jarsigner
-digestalg SHA1
B.jar c

-echo "${TESTJAVA}${FS}bin${FS}jarsigner -verify ${KS_ARGS} ${PROP_ARGS} -verbose B.jar"
-LINES=`${TESTJAVA}${FS}bin${FS}jarsigner -verify ${KS_ARGS} ${PROP_ARGS} -verbose B.jar | grep smk | grep B.class | wc -l`
+JAR_VERIFY_CMD="${TESTJAVA}${FS}bin${FS}jarsigner -verify ${KS_ARGS} ${PROP_ARGS} -verbose B.jar"
+echo ${JAR_VERIFY_CMD}
+LINES=`${JAR_VERIFY_CMD} | grep smk | grep B.class | wc -l`
[ $LINES = 1 ] || exit 1

alexeybakhtin · 2022-11-17T16:02:22Z

@martinuy, Thank you! Sure it is better. Test updated

martinuy

Looks good to me. Thanks for this contribution.

openjdk · 2022-11-17T16:14:25Z

@alexeybakhtin This change now passes all automated pre-integration checks.

After integration, the commit message for the final commit will be:

8269039: Disable SHA-1 Signed JARs

Reviewed-by: mbalao

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 19 new commits pushed to the master branch:

b98d485: 8197859: VS2017 Complains about UINTPTR_MAX definition in globalDefinitions_VisCPP.hpp
7ae002c: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled
6849667: 8284389: Improve stability of GHA Pre-submit testing by caching cygwin installer
7024bf0: 8296959: Fix hotspot shell tests of 8u on multilib systems
17fd40a: 8295714: GHA ::set-output is deprecated and will be removed
2f509c7: 8159599: [TEST_BUG] java/awt/Modal/ModalInternalFrameTest/ModalInternalFrameTest.java
f6d869f: 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64
3bfde7d: 8284622: Update versions of some Github Actions used in JDK workflow
3a1a2e0: 8233551: [TESTBUG] SelectEditTableCell.java fails on MacOS
736c1fb: 8295288: Some vm_flags tests associate with a wrong BugID
... and 9 more: https://git.openjdk.org/jdk8u-dev/compare/f04ad96cf53385c9f8aa071a4167ad7790cb8466...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

martinuy · 2022-11-17T16:17:04Z

One last note/reminder, this change has a CSR so 8u maintainers will look into that to approve this change.

theRealAph · 2022-11-23T10:21:24Z

This is scary stuff. Clearly it isn't a backwards-compatible change. I guess the way this works is that JARs timestamped prior to January 01, 2019 are accepted, but only until the signing certificate expires. Right?

jerboaa · 2022-11-23T10:43:05Z

The crypto roadmap mentions it's been included in Oracle JDK 8u351 (October 2022 CPU). While not 100% backwards compatible it's the default that is changing, right? So we should have it in OpenJDK 8u too and the CSR mentions it can be worked around by modifying java.security file. Is my understanding correct?

alexeybakhtin · 2022-11-23T11:15:26Z

Right, it can be easily workarounded by removing SHA1 restriction from java.security file

alexeybakhtin · 2022-11-23T13:50:02Z

This is scary stuff. Clearly it isn't a backwards-compatible change. I guess the way this works is that JARs timestamped prior to January 01, 2019 are accepted, but only until the signing certificate expires. Right?

The behavior of the SHA-1 signed certificates before January 01, 2019 is not changed. They are still valid even if the signer certificate expires. The changes apply to JARs signed after January 01, 2019

martinuy · 2022-11-23T14:11:42Z

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 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. Also, the Release Note attached to this bug indicates how to restore backward compatibility.

These crypto changes are part of the crypto roadmap 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.

alexeybakhtin · 2022-11-23T15:14:32Z

/integrate

openjdk · 2022-11-23T15:16:39Z

Going to push as commit c501bfa.
Since your change was applied there have been 23 commits pushed to the master branch:

5a32484: 8297141: Fix hotspot/test/runtime/SharedArchiveFile/DefaultUseWithClient.java for 8u
da0c382: 8241086: Test runtime/NMT/HugeArenaTracking.java is failing on 32bit Windows
91d8b89: 8129827: [TEST_BUG] Test java/awt/Robot/RobotWheelTest/RobotWheelTest.java fails
9cb8752: 8079255: [TEST_BUG] [macosx] Test closed/java/awt/Robot/RobotWheelTest/RobotWheelTest fails for Mac only
b98d485: 8197859: VS2017 Complains about UINTPTR_MAX definition in globalDefinitions_VisCPP.hpp
7ae002c: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled
6849667: 8284389: Improve stability of GHA Pre-submit testing by caching cygwin installer
7024bf0: 8296959: Fix hotspot shell tests of 8u on multilib systems
17fd40a: 8295714: GHA ::set-output is deprecated and will be removed
2f509c7: 8159599: [TEST_BUG] java/awt/Modal/ModalInternalFrameTest/ModalInternalFrameTest.java
... and 13 more: https://git.openjdk.org/jdk8u-dev/compare/f04ad96cf53385c9f8aa071a4167ad7790cb8466...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-11-23T15:17:07Z

@alexeybakhtin Pushed as commit c501bfa.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

gnu-andrew · 2022-11-25T16:24:49Z

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 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. Also, the Release Note attached to this bug indicates how to restore backward compatibility.

These crypto changes are part of the crypto roadmap 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.

alexeybakhtin · 2022-11-28T13:30:44Z

@gnu-andrew, Thank you for the comment. I've submitted PR for the backport of JDK-8275887

gnu-andrew · 2022-11-28T15:12:41Z

Thanks. It'll need to be against https://github.com/openjdk/jdk8u once I've finished promoting b05 to make 8u362. jdk8u-dev is now for 8u372 changes.

alexeybakhtin · 2022-11-29T07:12:32Z

@gnu-andrew, New pull request against jdk8u was created : openjdk/jdk8u#24

Backport 6d91a3eb7bd1e1403cfb67f7eb8ce06d7e08e7a7

0cccb13

openjdk bot changed the title ~~Backport 6d91a3eb7bd1e1403cfb67f7eb8ce06d7e08e7a7~~ 8269039: Disable SHA-1 Signed JARs Nov 3, 2022

openjdk bot added backport Port of a pull request already in a different code base rfr Pull request is ready for review labels Nov 3, 2022

martinuy reviewed Nov 15, 2022

View reviewed changes

test fixes

2f2e7b2

Update oldsig test

57d0b0b

oldsig test updated again

57637b6

martinuy approved these changes Nov 17, 2022

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Nov 17, 2022

openjdk bot added the integrated Pull request has been integrated label Nov 23, 2022

openjdk bot closed this Nov 23, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Nov 23, 2022

Conversation

alexeybakhtin commented Nov 3, 2022 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Nov 3, 2022

Uh oh!

openjdk bot commented Nov 3, 2022

Uh oh!

mlbridge bot commented Nov 3, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

jerboaa commented Nov 11, 2022

Uh oh!

martinuy left a comment

Choose a reason for hiding this comment

Uh oh!

martinuy Nov 15, 2022

Choose a reason for hiding this comment

Uh oh!

alexeybakhtin Nov 16, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

martinuy Nov 16, 2022

Choose a reason for hiding this comment

Uh oh!

martinuy Nov 15, 2022

Choose a reason for hiding this comment

Uh oh!

alexeybakhtin Nov 16, 2022

Choose a reason for hiding this comment

Uh oh!

martinuy Nov 16, 2022

Choose a reason for hiding this comment

Uh oh!

alexeybakhtin commented Nov 16, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinuy commented Nov 17, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexeybakhtin commented Nov 17, 2022

Uh oh!

martinuy commented Nov 17, 2022

Uh oh!

alexeybakhtin commented Nov 17, 2022

Uh oh!

martinuy left a comment

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Nov 17, 2022

Uh oh!

martinuy commented Nov 17, 2022

Uh oh!

theRealAph commented Nov 23, 2022

Uh oh!

jerboaa commented Nov 23, 2022

Uh oh!

alexeybakhtin commented Nov 23, 2022

Uh oh!

alexeybakhtin commented Nov 23, 2022

Uh oh!

martinuy commented Nov 23, 2022

Uh oh!

alexeybakhtin commented Nov 23, 2022

Uh oh!

openjdk bot commented Nov 23, 2022

Uh oh!

openjdk bot commented Nov 23, 2022

Uh oh!

gnu-andrew commented Nov 25, 2022

Uh oh!

alexeybakhtin commented Nov 28, 2022

Uh oh!

gnu-andrew commented Nov 28, 2022

alexeybakhtin commented Nov 3, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Nov 3, 2022 •

edited

Loading

alexeybakhtin Nov 16, 2022 •

edited

Loading

alexeybakhtin commented Nov 16, 2022 •

edited

Loading

martinuy commented Nov 17, 2022 •

edited

Loading