8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards #7037

wangweij · 2022-01-11T20:38:30Z

Change the order so parent class is at the left.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

Reviewers

Xue-Lei Andrew Fan (@XueleiFan - Reviewer)
Valerie Peng (@valeriepeng - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/7037/head:pull/7037
$ git checkout pull/7037

Update a local copy of the PR:
$ git checkout pull/7037
$ git pull https://git.openjdk.java.net/jdk pull/7037/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 7037

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/7037.diff

…arameterSpec appear to be backwards 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

bridgekeeper · 2022-01-11T20:39:26Z

👋 Welcome back weijun! 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-01-11T20:42:09Z

@wangweij The following label will be automatically applied to this pull request:

security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2022-01-11T20:45:51Z

Webrevs

01: Full - Incremental (a5b20563)
00: Full (5dccd0ed)

XueleiFan

Hm, an interesting catch. I have a concern, although.

XueleiFan · 2022-01-12T06:08:29Z

src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java

-        if (IvParameterSpec.class.isAssignableFrom(paramSpec)) {
+        if (paramSpec.isAssignableFrom(IvParameterSpec.class)) {


The call to cast() is confusing. But if the paramSpec is AlgorithmParameterSpec.class or Object.class, what's the expected behavior? There are potential casting exception, I guess. Maybe, a exactly class matching could be better.

If so, then the if block will be true and the spec object is casted to your specified class (AlgorithmParameterSpec.class or Object.class) and it always succeeds.

This is exactly what I want to achieve. In fact, this bug and the other getInstance(oid) bug have the same root. I was trying to decode an algorithm identifier from its encoding. First, the encoding of the algorithm is in OID so AlgorithmParameters.getInstance() must support OID. Second, I want to get the spec from the parameters without knowing the algorithm name and the child AlgorithmParametersSpec class type, so AlgorithmParameters::getParameterSpec must support AlgorithmParameterSpec.class as the argument.

Otherwise, the program needs to know name and parameter spec type on all supported algorithms.

Interesting... In hindsight, the cast call sort of confirms that the intended ordering is the suggested one.

The check ensures casting always succeeds. The fact that this has not been noticed for such a long time means everyone is using the exact subclass type when calling the method.

Right, I suppose so.

PBEKeyFactory.java, PBKDF2Core.java and PBKDF2HmacSHA1Factory.java also have isAssignableFrom() calls which seem backward. Perhaps covering them as well?

If so, then the if block will be true and the spec object is casted to your specified class (AlgorithmParameterSpec.class or Object.class) and it always succeeds.

This is exactly what I want to achieve.

Unfortunately, there is a returned value that we cannot return an object of any class.

If so, then the if block will be true and the spec object is casted to your specified class (AlgorithmParameterSpec.class or Object.class) and it always succeeds.
This is exactly what I want to achieve.

Unfortunately, there is a returned value that we cannot return an object of any class.

Oh, I missed that the paramSpec should be of class T, which extends AlgorithmParameterSpec. Then, I have no more concerns.

valeriepeng · 2022-01-12T19:41:31Z

test/jdk/java/security/spec/IsAssignableFromOrder.java

+
+    static void test(String algorithm, AlgorithmParameterSpec spec,
+            Class<? extends AlgorithmParameterSpec>... classes) throws Exception {
+        var ap1 = AlgorithmParameters.getInstance(algorithm);


nit: Print out the algorithm which has been tested?

I can, but if an exception is thrown, I can find out which algorithm has a problem by looking at the line number.

Yes, just thought that reporting the algorithm to the test output seems more informative. Otherwise, always have to dig out the source to find out what has been covered.

…arameterSpec appear to be backwards

wangweij · 2022-01-12T22:36:08Z

New commit pushed. Turns out PBKDF2HmacSHA1Factory.java is useless now. The algorithm is now implemented as a sub-class of PBKDF2Core.

openjdk · 2022-01-12T22:53:42Z

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

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

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

8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

Reviewed-by: xuelei, valeriep

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 101 new commits pushed to the master branch:

d70545d: 8258603: c1 IR::verify is expensive
0a094d7: 8268081: Upgrade Unicode Data Files to 14.0.0
ddddec7: 8274243: Implement fast-path for ASCII-compatible CharsetEncoders on aarch64
8fed8ab: 8278065: Refactor subclassAudits to use ClassValue
f54ce84: 8238161: use os::fopen in HS code where possible
ff0cb98: 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out
ece98d8: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code
525b20f: 8279676: Dubious YMM register clearing in x86_64 arraycopy stubs
4f0b650: 8278581: Improve reference processing statistics log output
bd339aa: 8277627: Fix copyright years in some jvmci files
... and 91 more: https://git.openjdk.java.net/jdk/compare/8dc4437d002db5d025b47f48e7420e3bae55bdec...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.

valeriepeng

Changes look good. Thanks~

wangweij · 2022-01-13T00:41:10Z

/integrate

openjdk · 2022-01-13T00:42:16Z

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

1228b2f: 8261455: Automatically generate the CDS archive if necessary
d70545d: 8258603: c1 IR::verify is expensive
0a094d7: 8268081: Upgrade Unicode Data Files to 14.0.0
ddddec7: 8274243: Implement fast-path for ASCII-compatible CharsetEncoders on aarch64
8fed8ab: 8278065: Refactor subclassAudits to use ClassValue
f54ce84: 8238161: use os::fopen in HS code where possible
ff0cb98: 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out
ece98d8: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code
525b20f: 8279676: Dubious YMM register clearing in x86_64 arraycopy stubs
4f0b650: 8278581: Improve reference processing statistics log output
... and 92 more: https://git.openjdk.java.net/jdk/compare/8dc4437d002db5d025b47f48e7420e3bae55bdec...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-01-13T00:42:29Z

@wangweij Pushed as commit cb25029.

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

8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetP…

5dccd0e

…arameterSpec appear to be backwards 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

openjdk bot added the rfr Pull request is ready for review label Jan 11, 2022

openjdk bot added the security security-dev@openjdk.org label Jan 11, 2022

XueleiFan suggested changes Jan 12, 2022

View reviewed changes

valeriepeng reviewed Jan 12, 2022

View reviewed changes

8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetP…

a5b2056

…arameterSpec appear to be backwards

XueleiFan approved these changes Jan 12, 2022

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 12, 2022

valeriepeng approved these changes Jan 13, 2022

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Jan 13, 2022

openjdk bot closed this Jan 13, 2022

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

wangweij deleted the 8279800 branch January 14, 2022 20:47

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards #7037

8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards #7037

wangweij commented Jan 11, 2022 •

edited by openjdk bot

Loading

bridgekeeper bot commented Jan 11, 2022

openjdk bot commented Jan 11, 2022

mlbridge bot commented Jan 11, 2022 •

edited

Loading

XueleiFan left a comment

XueleiFan Jan 12, 2022

wangweij Jan 12, 2022

valeriepeng Jan 12, 2022

wangweij Jan 12, 2022

valeriepeng Jan 12, 2022

valeriepeng Jan 12, 2022

XueleiFan Jan 12, 2022

XueleiFan Jan 12, 2022

valeriepeng Jan 12, 2022

wangweij Jan 12, 2022

valeriepeng Jan 12, 2022

wangweij commented Jan 12, 2022

openjdk bot commented Jan 12, 2022 •

edited

Loading

valeriepeng left a comment

wangweij commented Jan 13, 2022

openjdk bot commented Jan 13, 2022

openjdk bot commented Jan 13, 2022

		if (IvParameterSpec.class.isAssignableFrom(paramSpec)) {
		if (paramSpec.isAssignableFrom(IvParameterSpec.class)) {

8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards #7037

8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards #7037

Conversation

wangweij commented Jan 11, 2022 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Jan 11, 2022

openjdk bot commented Jan 11, 2022

mlbridge bot commented Jan 11, 2022 • edited Loading

Webrevs

XueleiFan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wangweij commented Jan 12, 2022

openjdk bot commented Jan 12, 2022 • edited Loading

valeriepeng left a comment

Choose a reason for hiding this comment

wangweij commented Jan 13, 2022

openjdk bot commented Jan 13, 2022

openjdk bot commented Jan 13, 2022

wangweij commented Jan 11, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Jan 11, 2022 •

edited

Loading

openjdk bot commented Jan 12, 2022 •

edited

Loading