-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
8288209: SSL debug message wrong about unsupported authentication scheme #9140
Conversation
👋 Welcome back weijun! A progress list of the required criteria for merging this PR into |
Webrevs
|
@@ -207,6 +207,15 @@ static String toString(Object... params) { | |||
} | |||
} | |||
|
|||
// Logs an warning message and always returns false. This method |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Logs a warning"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
hc.algorithmConstraints, // we will be able to produce | ||
hc.peerRequestedSignatureSchemes, // a CertificateVerify message later | ||
ka, hc.negotiatedProtocol) != null | ||
|| SSLLogger.logWarning("ssl,handshake", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice syntax!
} | ||
supportedKeyTypes.add(ss.keyAlgorithm); | ||
} | ||
String[] supportedKeyTypes = hc.peerRequestedCertSignSchemes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Preexisting, but shouldn't we use peerRequestedSignatureSchemes
here? If I read RFC 8446 correctly, peerRequestedCertSignSchemes
only applies to how the certificates were signed; it does not limit the end-entity key type in any way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does appear that there is an issue here. Weijun and I have done a little playtesting with this and there are some cases where it isn't behaving as expected. I don't know if this can be solved as simply as using peerRequestedSignatureSchemes
though. It might be that simple, but I think the selection code is complex enough and there are enough edge cases to test that this PR might not be the place to address this. We probably need a separate bug to deal with this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@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:
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 61 new commits pushed to the
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 |
/integrate |
Going to push as commit 1901735.
Your commit was automatically rebased without conflicts. |
At the beginning, this bug was about the incorrect warning message "Unsupported authentication scheme" on line 1051 which should have been "This key algorithm has been checked, skip it".
Now, it's a code refactoring that emphasizes only the key algorithm inside a signature scheme is checked in these two methods, and therefore the ignore-if-checked logic in the old code is correct.
Note:
logWarning
is put insideSSLLogger
so we can get the correct caller line number. Also, please advise if the|| SSLLogger.logWarning
style looks weird and if there is a better way to filter and log at the same time.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9140/head:pull/9140
$ git checkout pull/9140
Update a local copy of the PR:
$ git checkout pull/9140
$ git pull https://git.openjdk.org/jdk pull/9140/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 9140
View PR using the GUI difftool:
$ git pr show -t 9140
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9140.diff