Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified #9859

Closed
wants to merge 10 commits into from

Conversation

driverkt
Copy link
Member

@driverkt driverkt commented Aug 12, 2022

add @exception message to indicate an NPE might be thrown when the input parameter is null


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
  • Change requires a CSR request to be approved

Issues

  • JDK-6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified
  • JDK-8292299: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified (CSR)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9859/head:pull/9859
$ git checkout pull/9859

Update a local copy of the PR:
$ git checkout pull/9859
$ git pull https://git.openjdk.org/jdk pull/9859/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9859

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9859.diff

@driverkt
Copy link
Member Author

/issue add 6205692

@bridgekeeper
Copy link

bridgekeeper bot commented Aug 12, 2022

👋 Welcome back kdriver! 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.

@driverkt
Copy link
Member Author

/csr needed

@driverkt driverkt changed the title (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified Aug 12, 2022
@openjdk
Copy link

openjdk bot commented Aug 12, 2022

@driverkt The primary solved issue for a PR is set through the PR title. Since the current title does not contain an issue reference, it will now be updated.

…to indicate an NPE might be thrown when the input parameter is null
@openjdk openjdk bot added the rfr Pull request is ready for review label Aug 12, 2022
@openjdk openjdk bot added the csr Pull request needs approved CSR before integration label Aug 12, 2022
@openjdk
Copy link

openjdk bot commented Aug 12, 2022

@driverkt has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@driverkt please create a CSR request for issue JDK-6205692 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

@openjdk
Copy link

openjdk bot commented Aug 12, 2022

@driverkt 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.

@openjdk openjdk bot added the security security-dev@openjdk.org label Aug 12, 2022
@mlbridge
Copy link

mlbridge bot commented Aug 12, 2022

Copy link
Contributor

@LanceAndersen LanceAndersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks OK. I did a quick scan and did not see a test in open/test which covers this and it probably would be worth considering adding one as part of this update

@driverkt
Copy link
Member Author

driverkt commented Aug 12, 2022

This looks OK. I did a quick scan and did not see a test in open/test which covers this and it probably would be worth considering adding one as part of this update

@LanceAndersen I can add a test, if needed; however this is only a javadoc update and no new code is introduced. In other words, we could add a test to demonstrate existing behavior, but a test would not help with verifying this change.

@@ -101,6 +101,9 @@ protected abstract void engineInit(Key key,
* process ByteBuffers more efficiently than byte arrays.
*
* @param input the ByteBuffer
*
* @exception NullPointerException if {@code input} is null

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I recall @throws is preferred.

How about the update(...) methods in javax.crypto.Mac class? Perhaps the NPE there should be documented as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@valeriepeng I totally agree about @throws. I was just going for consistency within the file. There are other @exception appearances.

Yes, I do agree about the update(ByteBuffer) in Mac as well; however this one throws IllegalArgumentException if the parameter is null. Or were you referring to another version of the update method?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@valeriepeng see 0bc0394 for the proposed change.

Let me know what you think about consistency within the files wrt @throws vs @exception.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this particular case, I would go for @throws. Moving toward the newer notation seems better.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@valeriepeng I totally agree about @throws. I was just going for consistency within the file. There are other @exception appearances.

Yes, I do agree about the update(ByteBuffer) in Mac as well; however this one throws IllegalArgumentException if the parameter is null. Or were you referring to another version of the update method?

Right, I should have not stated NPE, but rather the IAE caused by null argument. For completeness sake, perhaps we can cover NPE for Mac.update(byte[]) also? Since we are filing CSR already. It'd be great if this fix covers both Mac and MacSpi regarding null argument of the update(...)/engineUpdate(..) methods. Or, if that's a bit much, then we should strive to cover Mac.update(ByteBuffer)/MacSpi.engineUpdate(ByteBuffer) methods for completeness sake.

@LanceAndersen
Copy link
Contributor

This looks OK. I did a quick scan and did not see a test in open/test which covers this and it probably would be worth considering adding one as part of this update

@LanceAndersen I can add a test, if needed; however this is only a javadoc update and no new code is introduced. In other words, we could add a test to demonstrate existing behavior, but a test would not help with verifying this change.

Understand it is just updating the spec/javadoc. It would be good for coverage going forward. At a minimum, the JCK should add a test.

@openjdk-notifier
Copy link

@driverkt Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See OpenJDK Developers’ Guide for more information.

Copy link
Contributor

@LanceAndersen LanceAndersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps consider converting the remaining @exceptions to @throws as part of this update

Copy link

@valeriepeng valeriepeng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

Copy link
Contributor

@bradfordwetmore bradfordwetmore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's currently here is ok, but I concur about the suggestions for adding test(s), and changing @exception to @throws in both Mac and MacSpi.

Comment on lines 100 to 112
private static class MyMac extends Mac {
private MyMacSpi spi;

public MyMac(MyMacSpi macSpi, Provider provider, String algorithm) {
super(macSpi, provider, algorithm);
spi = macSpi;
}

public void updateSpi(ByteBuffer input) {
spi.engineUpdate(input);
}
}
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can remove all these and directly instantiate the dummy MacSpi object and call the public engineUpdate(ByteBuffer) method in the execute method.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed! please re-review

Copy link
Contributor

@bradfordwetmore bradfordwetmore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no "newline" at the end of the new test file.

Copy link
Contributor

@bradfordwetmore bradfordwetmore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nits, don't need to be rereviewed after fixing.

test/jdk/com/sun/crypto/provider/Mac/Test6205692.java Outdated Show resolved Hide resolved
test/jdk/com/sun/crypto/provider/Mac/Test6205692.java Outdated Show resolved Hide resolved
@driverkt
Copy link
Member Author

/integrate

@openjdk
Copy link

openjdk bot commented Aug 30, 2022

@driverkt This pull request has not yet been marked as ready for integration.

@driverkt
Copy link
Member Author

/issue add 8292299

@openjdk
Copy link

openjdk bot commented Aug 30, 2022

@driverkt
Adding additional issue to issue list: 8292299: Document exception in Mac.update(ByteBuffer)/MacSpi.engineUpdate(ByteBuffer).

@driverkt
Copy link
Member Author

/issue remove 8292299

@openjdk
Copy link

openjdk bot commented Aug 30, 2022

@driverkt
Removing additional issue from issue list: 8292299.

@driverkt
Copy link
Member Author

/integrate

@openjdk
Copy link

openjdk bot commented Aug 30, 2022

@driverkt This pull request has not yet been marked as ready for integration.

@driverkt
Copy link
Member Author

/csr needed

@openjdk
Copy link

openjdk bot commented Aug 30, 2022

@driverkt an approved CSR request is already required for this pull request.

@driverkt
Copy link
Member Author

/issue add 8292299

@openjdk
Copy link

openjdk bot commented Aug 30, 2022

@driverkt
Adding additional issue to issue list: 8292299: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified.

@driverkt
Copy link
Member Author

/issue remove 8292299

@openjdk
Copy link

openjdk bot commented Aug 30, 2022

@driverkt
Removing additional issue from issue list: 8292299.

@driverkt
Copy link
Member Author

/integrate

@openjdk openjdk bot removed the csr Pull request needs approved CSR before integration label Aug 30, 2022
@openjdk
Copy link

openjdk bot commented Aug 30, 2022

@driverkt 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:

6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified

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

  • 622be79: 8293090: Remove unused par_oop_since_save_marks_iterate_done
  • 3d0ab2b: 8292858: G1: Remove redundant check in G1FlushHumongousCandidateRemSets
  • 6e24827: 8292878: x86: Make scratch register usage explicit in assembler code

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@LanceAndersen, @valeriepeng, @bradfordwetmore) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added ready Pull request is ready to be integrated sponsor Pull request is ready to be sponsored labels Aug 30, 2022
@openjdk
Copy link

openjdk bot commented Aug 30, 2022

@driverkt
Your change (at version 6a9dafe) is now ready to be sponsored by a Committer.

@bradfordwetmore
Copy link
Contributor

/sponsor

@openjdk
Copy link

openjdk bot commented Aug 30, 2022

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

  • 622be79: 8293090: Remove unused par_oop_since_save_marks_iterate_done
  • 3d0ab2b: 8292858: G1: Remove redundant check in G1FlushHumongousCandidateRemSets
  • 6e24827: 8292878: x86: Make scratch register usage explicit in assembler code

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Aug 30, 2022
@openjdk openjdk bot closed this Aug 30, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Aug 30, 2022
@openjdk
Copy link

openjdk bot commented Aug 30, 2022

@bradfordwetmore @driverkt Pushed as commit 6335150.

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

@driverkt driverkt deleted the JDK-6205692 branch August 30, 2022 20:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated security security-dev@openjdk.org
4 participants