-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8264864: Multiple byte tag not supported by ASN.1 encoding #3391
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
Conversation
8264864: Multiple byte tag not supported by ASN.1 encoding
👋 Welcome back weijun! A progress list of the required criteria for merging this PR into |
Webrevs
|
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.
Looks good to me, except a minor comment.
@@ -221,6 +221,9 @@ public boolean isConstructed(byte constructedTag) { | |||
* Creates a new DerValue by specifying all its fields. | |||
*/ | |||
DerValue(byte tag, byte[] buffer, int start, int end, boolean allowBER) { | |||
if ((tag & 0x1f) == 0x1f) { | |||
throw new IllegalArgumentException("Tag number 31 is not supported"); |
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.
As number 31 just means the tag is bigger than 31, Is it more accuracy by using "Tag number over 30 is not supported"?
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.
Well, it's a little delicate here. Even if we support multi-byte tag one day, this constructor will still only be used to create a single-byte tag DerValue
, and it's illegal for a single byte tag to end with 0x1f. So the words above is to remind people that they cannot create a tag number 31 DerValue
just because it seems it still fits into the 5 bits. Precisely, the words should be "this constructor only supports tag number between 0 and 30", but... I'll choose your words.
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 makes sense. Your words is good to me.
@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 58 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 |
@@ -315,6 +318,9 @@ public DerValue(byte[] encoding) throws IOException { | |||
} | |||
int pos = offset; | |||
tag = buf[pos++]; | |||
if ((tag & 0x1f) == 0x1f) { | |||
throw new IOException("Tag number over 30 is not supported"); |
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.
Would it be useful for these types of exception messages to either display the offending tag value or perhaps the tag offset? Just thinking it might be a nice thing for the recipient to know where in the DER encoding the issue is.
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.
I don't want to go on reading the following bytes to find out what the intended tag number is, because that somehow shows I do understand the encoding a lot but still don't want to support it (well, actually I only understand a little). There are only 2 kinds of tags: one <= 30 and one >= 31. IMHO, the message has already expressed the meaning that we only support the 1st one.
An alternative message I can think of is "Unsupported tag byte: 0xBF", but it looks too cryptic.
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.
I think that is fair. If you don't want to read ahead like that, what about using the "offset" or "pos" field to give a message like "Tag number over 30 at offset NN is not supported" (something like that, at least) Maybe don't worry about the tag value itself, but at least the position in the data stream. Just a suggestion only, no strong feelings about this either 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.
There is an offset
value here but I have really no idea if the user knows where to count from. If we say "offset" then we probably need to tell what data block we are talking about. What if the DerValue is just a portion of a bigger data block?
That said, if you really like it, I can add an offset like "tag byte at offset nnnn". I just hope the user can find it.
/integrate |
/integrate |
1 similar comment
/integrate |
@wangweij Since your change was applied there have been 61 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 3d2b4cc. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
@wangweij The command |
@wangweij The command |
This code change does not intend to support multiple byte tags. Instead, it aims to fail more gracefully when such a tag is encountered. For
DerValue
constructors from an encoding (type I), anIOException
will be thrown since it's already in the throws clause. For constructors from tag and value (type II), anIllegalArgumentException
will be thrown. All existing type II callers inside JDK use tag numbers smaller than 31.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3391/head:pull/3391
$ git checkout pull/3391
Update a local copy of the PR:
$ git checkout pull/3391
$ git pull https://git.openjdk.java.net/jdk pull/3391/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 3391
View PR using the GUI difftool:
$ git pr show -t 3391
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3391.diff