8271566: DSA signature length value is not accurate in P11Signature

[martinuy]

As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4.

Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed.

No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey.

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8271566

---

Progress

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

Issue

• JDK-8271566: DSA signature length value is not accurate in P11Signature

Reviewers

• Valerie Peng (@valeriepeng - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4961

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

Using diff file

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

[bridgekeeper]

👋 Welcome back mbalao! 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]

@martinuy 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]

Webrevs

• 03: Full - Incremental (1e53b6d0)
• 02: Full (00564198)
• 01: Full - Incremental (ce7c79ed)
• 00: Full (b02826b1)

[valeriepeng]

As for your changes to P11Key class, I wonder why NSS doesn't make the "extractable" attribute false for their token keys? I agree that this change makes sense for NSS given their current impl but not sure how other vendor may be impacted by this. So, how about:

1. keep this change specific to NSS.
2. now that various P11XXXPrivateKey classes can also be sensitive and un-extractable, perhaps we should just make P11PrivateKey class a general class which these P11XXXPrivateKey extends from and store the "sensitiveKey" logic inside the P11PrivateKey constructor. This way, you don't need to change the constructor signature to add this extra boolean argument. The subclasses can just access the field in P11PrivateKey class and decide.
3. for RSA private keys, instead of just use P11PrivateKey, it could still use P11RSAPrivateNonCRTKey if the CRT attributes aren't available due to being a token key. Or, perhaps availability of public exponent attribute would give an indication?

[valeriepeng]

Hmm, I ran more security regression tests against the proposed changes and had a second thought about this proposed P11Key change. When the underlying P11 DSA key is un-extractable and returned as a P11Key which implements DSAPrivateKey interface. With the proposed change, calling getX() upon this key object returns null which will lead to unexpected NPE. This is a serious problem. Same goes for other private keys, e.g. EC, DH. And not just the private value of these keys, but also the encodings may lead to NPE. Thus, for un-extractable keys, we will have to continue to return them as P11PrivateKey objects which does not implement any algorithm specific interface.

[martinuy]

Yes, I see what you mean. Contrary to P11PrivateKey::getFormat and P11PrivateKey::getEncodedInternal where a 'null' returned value is documented in java.security.Key, we don't have that documentation for the other interfaces such as java.security.interfaces.DSAPrivateKey. That can lead to NPE if the client casts the P11Key to the interface, invokes the method and depends on a non-null value. I will give this some thought and try to come up with something, because the information is already there and (in reality) we need it internally only. It's clear that all these interfaces were not designed with unextractable P11 keys in mind, because it makes sense to me (conceptually) to have a private key from which we can retrieve some values (public, such as the parameters) and not other ones.

[valeriepeng]

Yes, I see what you mean. Contrary to P11PrivateKey::getFormat and P11PrivateKey::getEncodedInternal where a 'null' returned value is documented in java.security.Key, we don't have that documentation for the other interfaces such as java.security.interfaces.DSAPrivateKey. That can lead to NPE if the client casts the P11Key to the interface, invokes the method and depends on a non-null value. I will give this some thought and try to come up with something, because the information is already there and (in reality) we need it internally only. It's clear that all these interfaces were not designed with unextractable P11 keys in mind, because it makes sense to me (conceptually) to have a private key from which we can retrieve some values (public, such as the parameters) and not other ones.

Right, PKCS11 and unextractable keys come a few releases later after the JCA API. So, there may be some difficulties trying to work them into existing APIs. In order to maintain backward compatibility, API changes are also limited.

[martinuy]

I made some class refactoring in P11Key to achieve the following goals:

• Make the classes hierarchy more clear. It was a bit odd to see P11PrivateKey and P11(RSA,DSA,DH,EC)PrivateKey unrelated in terms of "the latter is a more specific instance of the former"

  • We now have P11(RSA,DSA,DH,EC)PrivateKey inheriting from P11PrivateKey
  • This allowed to promote the 'encoded' field which is shared across all of them

• Keep the API as before

  • For an external-package client, a non-sensitive private key is seen as a (RSA,DSA,DH,EC)PrivateKey as before. Thus, the result of calling methods that return key values or parameters should be non-null as expected
  • A sensitive private key will be of the PrivateKey visible type for an external-package client. Thus, it's not possible to get key values or parameters from there. Note that calling the methods that return the encoded key or format will keep returning null in these cases as before.
  • The difference now is that a package client (sun.security.pkcs11 internal class) can access key parameters for sensitive keys because the visible type for them is (RSA,DSA,DH,EC)PrivateKeyInternal
  • The key parameter information is now available and may be useful to several P11 classes in the future, in addition to P11Signature which is using it now to have an exact estimate of a DSA signature length

• There was boiler-plate code with P11(RSA,DSA,DH,EC)PublicKey classes because there is an overlap with key attributes fetched for private keys, and the fetching machinery was duplicated. We now have a single way of getting key attributes.

• In the P11RSAPrivateKey case (RSA CRT), we save one call to the native PKCS#11 library because all attributes are obtained at once, instead of delaying the fetch of CKA_MODULUS and CKA_PRIVATE_EXPONENT to a later point. We do not add additional PKCS#11 calls in any case.

• Several improvements specific to RSA key classes. Despite being a bit different than DSA, DH and EC because of the existence of CRT and non-CRT keys; they are now better aligned and duplicated code was removed.

The refactorings implied removing fields from private but serializable classes. In example, P11DSAPublicKey does not longer have the fields 'y' and 'params'. My understanding is that this a serial compatibility breaker and a CSR would be needed. I can address that but wish you could have a look at the proposal before, so we come to something stable first.

No test regressions observed in jdk/sun/security/pkcs11 category.

[valeriepeng]

I agree with the new class hierarchy and see the merits. But need to think more about this new Fetcher way of doing things. It seems that the Fetcher is the real key class where there is the common logic (sensitive, isPrivate, etc.) and you just cover it up with different wrapper classes which seems algorithm specific but yet do not contain any algorithm specific fields and the logic is all inside the corresponding Fetcher. In addition, there seems to be some duplicated code in retrieving the attributes in RSA*Fetcher vs P11Key.fetchAttributes(). Will try a few things before sharing my review comments. Thanks. Valerie

[valeriepeng]

I tried a few things out and prefer just minor refactoring over this new Fetcher mechanism. I have shared my prototype changes with you over email. Please check it out. Thanks. Valerie

[bridgekeeper]

@martinuy This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper]

@martinuy This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

[martinuy]

/open

[openjdk]

@martinuy This pull request is now open

[martinuy]

Hi Valerie,

Apologies for the delay; I've intention to resume this work if you can.

I had a look at your Webrev.00 but I'm not really convinced, at least when comparing it to the Fetcher approach. I'll share my comments below:

• Changing P11PrivateKey::getFormat to return 'PKCS#8' and not overriding this method on opaque/sensitive private key classes will be an observable change, and it does not match what's specified in Key::getFormat: 'Returns the name of the primary encoding format of this key, or null if this key does not support encoding.'. My thinking here is that an opaque key does not support encoding because its value is not even accessible.

• P11PrivateKeyRSA and P11RSAPrivateKey class names look confusing to me (where 'RSA' is located does not say anything about the class to me at least). The 'Opaque' suffix for the one that is package-private might be a better choice. I used the suffice 'Internal' before but now I like 'Opaque' more.

• P11PrivateKeyRSA::of duplicates the attributes retrieval logic (session.token.p11::C_GetAttributeValue call), which is there and in P11Key::fetchAttributes. Sensitive RSA keys get the attributes from one place and non-sensitive from the other. This does not look to me an advantage when compared to the Fetcher, which does the same for RSA and uses P11Key::fetchAttributes for the others. However, having all the RSA-related logic in P11RSAAttributesFetcher::doFetchValues makes it a bit easier for me to reason about the 4 different scenarios to get the data: CRT + sensitive, non-CRT + sensitive, CRT + non-sensitive and non-CRT + non-sensitive.

• By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.

• P11PrivateKeyRSA does not make the CRT/non-CRT distinction for sensitive keys, so the public exponent is not obtained when it could be. This is a bit less functionality than what the Fetcher provides, and would require a few changes to fit it into the design.

From comment #Aug 17:
"(...) and you just cover it up with different wrapper classes which seems algorithm specific but yet do not contain any algorithm specific fields and the logic is all inside the corresponding Fetcher"

• In my view, it's true that the Fetcher has the logic to get and hold the data. But the classes that use it are not just wrapper classes covering it up: they implement different interfaces and override/implement methods differently. In example, P11RSAPrivateNonCRTKey implements RSAPrivateKey and decides not to provide an implementation of methods such as getPublicExponent, getPrimeP, getPrimeQ, etc. On the other hand, having the logic for the different RSA data-availability scenarios in a single place (CRT sensitive, non-CRT sensitive, CRT non-sensitive and non-CRT non-sensitive) makes it a bit easier to reason about. Otherwise, this is scattered all over the place.

If you still want to take the non-fetcher approach and address the issues mentioned above, I can have a look.

Kind regards,
Martin.-

[valeriepeng]

Hmm, ok, I was focus on something else and missed your update to this PR. it's been a while, I will take another look to refresh my memory and get back to you... Thanks~

[valeriepeng]

Hi Martin,

Please find my comments in line below.

* Changing P11PrivateKey::getFormat to return 'PKCS#8' and not overriding this method on opaque/sensitive private key classes will be an observable change, and it does not match what's specified in Key::getFormat: 'Returns the name of the primary encoding format of this key, or null if this key does not support encoding.'. My thinking here is that an opaque key does not support encoding because its value is not even accessible.

Hmm, good point. I agree that returning null as default format and override it whenever an encoding is returned is the right thing to do.

* P11PrivateKeyRSA and P11RSAPrivateKey class names look confusing to me (where 'RSA' is located does not say anything about the class to me at least). The 'Opaque' suffix for the one that is package-private might be a better choice. I used the suffice 'Internal' before but now I like 'Opaque' more.

Sure, I didn't spend much time on this. Either Opaque or Internal suffix is fine. Generally I prefer shorter names.

* P11PrivateKeyRSA::of duplicates the attributes retrieval logic (session.token.p11::C_GetAttributeValue call), which is there and in P11Key::fetchAttributes. Sensitive RSA keys get the attributes from one place and non-sensitive from the other. This does not look to me an advantage when compared to the Fetcher, which does the same for RSA and uses P11Key::fetchAttributes for the others. However, having all the RSA-related logic in P11RSAAttributesFetcher::doFetchValues makes it a bit easier for me to reason about the 4 different scenarios to get the data: CRT + sensitive, non-CRT + sensitive, CRT + non-sensitive and non-CRT + non-sensitive.

This is where our view differs. We both have same class hierarchy but where the attributes are managed are different, you put all of them in the very bottom, i.e. fetcher, but I prefer them to be at top. Using RSA as an example, there are P11RSAPrivateKeyInternal - sensitive private key
P11RSAPrivateKey - non-sensitive CRT private key
P11RSAPrivateNonCRTKey - non-sensitive non-CRT private key
P11RSAPublicKey - public key
They all use the same P11RSAAttributesFetcher class but with different keySensitive, isPrivate flags to decide which attributes to query and which fields to populate. Whether the fields are null or not, the upper classes have no idea. The logic are all inside the fetcher. The keySensitive, isPrivate flags also have to be passed all around which seems strange as the classes themselves already implied these values and should not need to take arguments, i.e. P11RSAPrivateKey (keySensitive== false AND isPrivate == true). Overall, I find it hard to read. Comparing the fetcher model vs the non-fetcher model, the non-fetcher model has less code (at least 100 lines less) and it's very clear which attributes each class requires.

* By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.

There shouldn't be another call to the native library as it is only made when the modulus n is null. However, since n is already available, overriding the getModulus() method makes sense as there is no need to call fetchValues() which should return upon a non-null n value, but still an overhead.

* P11PrivateKeyRSA does not make the CRT/non-CRT distinction for sensitive keys, so the public exponent is not obtained when it could be. This is a bit less functionality than what the Fetcher provides, and would require a few changes to fit it into the design.

The proposed P11RSAPrivateKeyInternal class has no method for returning the public exponent either. If needed, it should be doable by adding extra attribute to the list of attributes in P11PrivateKeyRSA class. Should be trivial.

I updated the class naming in my prototype to align with yours and updated the prototype changes with your feedback. You can check/compare it at: http://cr.openjdk.java.net/~valeriep/8271566/webrev.01/

We have different views on this I guess. I prefer to let each class manage their list of attributes instead of a separate fetcher with their own logic. Former also has less code and follows the same model of existing code.

Thanks,
Valerie

[martinuy]

Hi @valeriepeng ,

Thanks for having a look at this. While we might have slightly different views on the fetcher, I appreciate that you took the time to explain your reasons. In any case, I believe that this iteration will be a significant improvement when compared to the old code, so I'm good to move forward on that. I'll check the other discussion points and your Webrev.01 proposal as soon as possible.

Martin.-

[martinuy]

* By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.

There shouldn't be another call to the native library as it is only made when the modulus n is null. However, since n is already available, overriding the getModulus() method makes sense as there is no need to call fetchValues() which should return upon a non-null n value, but still an overhead.

In my view (Webrev.00 based comment), the variable 'n' holding the modulus value is private in P11RSAPrivateKey. This means that when P11PrivateKeyRSA::getModulus is called, P11PrivateKeyRSA::n (which is protected) has a 'null' value and the PKCS#11 lib call is done again.

[valeriepeng]

* By eliminating P11RSAPrivateKey::getModulus, looks to me that P11PrivateKeyRSA::getModulus and P11PrivateKeyRSA::fetchValues are now called, leading to an unnecessary call to the native library as the modulus was already received on P11RSAPrivateKey constructor. This happens to P11RSAPrivateNonCRTKey as well.

There shouldn't be another call to the native library as it is only made when the modulus n is null. However, since n is already available, overriding the getModulus() method makes sense as there is no need to call fetchValues() which should return upon a non-null n value, but still an overhead.

In my view (Webrev.00 based comment), the variable 'n' holding the modulus value is private in P11RSAPrivateKey. This means that when P11PrivateKeyRSA::getModulus is called, P11PrivateKeyRSA::n (which is protected) has a 'null' value and the PKCS#11 lib call is done again.

Hmm, this is a bug and unintended. The 'n' in the child class should be removed as the 'n' in the parent class has scope protected and should be used instead.

I checked webrev.01 and this has been caught and fixed already. Good to have a different pair of eyes and more likely to spot problems. Thanks!

Regards,
Valerie

[martinuy]

Hi @valeriepeng ,

Some comments and questions regarding Webrev.01:

• P11Key.java

• Would you consider replacing the 'Internal' suffix with 'Opaque'? I believe the term 'opaque' better reflects what these keys are: you cannot see their values -thus, opaque- but you can use them as-is. 'Internal' gives me the impression of something not supposed to be exposed; and this is not exactly the case.

• Why are P11RSAPrivateKeyInternal::n, P11RSAPrivateKey::<e, d, p, q, pe, qe, coeff>, etc. now transient?

• Now that P11RSAPrivateKey::n private field was removed, the extra PKCS#11 lib call I mentioned in Webrev.00 is not possible anymore. The override of ::getModulus looks good to me, though, for the reasons you said.

• Can P11RSAPrivateNonCRTKey use the protected 'n' field from its parent instead of declaring a private one?

• P11Signature.java

• 'long errorCode = e.getErrorCode();' -> Looks to me that this change was included into the Webrev by mistake, and is part of JDK-8236512.

Thanks,
Martin.-

[valeriepeng]

Hi @valeriepeng ,

Some comments and questions regarding Webrev.01:

* P11Key.java

* Would you consider replacing the 'Internal' suffix with 'Opaque'? I believe the term 'opaque' better reflects what these keys are: you cannot see their values -thus, opaque- but you can use them as-is. 'Internal' gives me the impression of something not supposed to be exposed; and this is not exactly the case.

* Why are P11RSAPrivateKeyInternal::n, P11RSAPrivateKey::<e, d, p, q, pe, qe, coeff>, etc. now transient?

* Now that P11RSAPrivateKey::n private field was removed, the extra PKCS#11 lib call I mentioned in Webrev.00 is not possible anymore. The override of ::getModulus looks good to me, though, for the reasons you said.

* Can P11RSAPrivateNonCRTKey use the protected 'n' field from its parent instead of declaring a private one?

* P11Signature.java

* 'long errorCode = e.getErrorCode();' -> Looks to me that this change was included into the Webrev by mistake, and is part of JDK-8236512.

Thanks, Martin.-

Either internal or opaque suffix works for me. Fields aren't really being written out into the serialized bytes are "transient". IIRC, the serialized bytes are the "encoding" instead of the fields, we should mark these fields transient. As for the P11RSAPrivateNonCRTKey, yes, it should use the 'n' from parent instead of its own. I missed it when working on webrev.01. As for 'long errorCode = e.getErrorCode();' in P11Signature.java, yes, it should have been removed. I was manually merging the changes when refreshing the source tree and missed to remove this line.

Thanks,
Valerie

[valeriepeng]

Hmm, thinking more about "internal"/"opaque", given this is naming for the parent, maybe "internal" is more correct. The non-sensitive keys are encapsulated by the children classes and is still an instance of the parent. If you name the parent class w/ "opaque" suffix, it looks misleading/confusing. The opaqueness is implied by the implementation instead of the properties of the objects.

[martinuy]

Hi @valeriepeng ,

Yes, I just verified how serialization works for P11Keys and your 'transient' change makes sense to me now.

I see your point about Internal/Opaque. Keep 'Internal' then if you prefer. The whole inheritance relationship between these classes sounds a bit weird to me, beyond the names we call them. I wouldn't suggest any additional changes there now, though.

It looks to me that the only 2 changes expected for Webrev.02 are: 1) P11RSAPrivateNonCRTKey to use the parent's protected 'n'; and 2) removal of 'long errorCode = e.getErrorCode();'.

Now that we almost have the changeset ready, I'm not sure of how to proceed with the push. Do you want me to commit Webrev.02 in my own branch and use the 'Co-authored-by:' header? If we do that, do we still need an additional Reviewer? Do you prefer to have your own branch? Please let me know of how to move forward.

Martin.-

[valeriepeng]

Hi @valeriepeng ,

Yes, I just verified how serialization works for P11Keys and your 'transient' change makes sense to me now.

I see your point about Internal/Opaque. Keep 'Internal' then if you prefer. The whole inheritance relationship between these classes sounds a bit weird to me, beyond the names we call them. I wouldn't suggest any additional changes there now, though.

It looks to me that the only 2 changes expected for Webrev.02 are: 1) P11RSAPrivateNonCRTKey to use the parent's protected 'n'; and 2) removal of 'long errorCode = e.getErrorCode();'.

Now that we almost have the changeset ready, I'm not sure of how to proceed with the push. Do you want me to commit Webrev.02 in my own branch and use the 'Co-authored-by:' header? If we do that, do we still need an additional Reviewer? Do you prefer to have your own branch? Please let me know of how to move forward.

Martin.-

You can just incorporate the changes on your branch and proceeds with me being the reviewer. The webrev that I sent u is just an easier way to express the comments/feedbacks.

Thanks,
Valerie

[martinuy]

Hi @valeriepeng

I've reverted the initial 2 changesets on this branch, rebased to the latest commit on 'master' (git merge), applied Webrev.02 as discussed and added the test case from the initial commit (with the change from the 2nd commit applied on top).

I've noticed no regressions in jdk/sun/security/pkcs11.

Does it look good to you?

Thanks,
Martin.-

[martinuy]

Hi @valeriepeng ,

Please take a look at the latest change based on your comments.

No regressions found in 'jdk/sun/security/pkcs11'.

Thanks,
Martin.-

[valeriepeng]

Looks good. Thanks! Valerie

[openjdk]

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

8271566: DSA signature length value is not accurate in P11Signature

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

• 239362d: 8247973: Javadoc incorrect for IdentityArrayList, IdentityLinkedList
• 2c31a17: 8275082: Update XML Security for Java to 2.3.0
• 70bad89: 8277497: Last column cell in the JTAble row is read as empty cell
• 5045eb5: 8278273: Remove unnecessary exclusion of doclint accessibility checks
• 587e540: 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> (a java.lang.Class ...'
• 082fdf4: 8172065: javax/swing/JTree/4908142/bug4908142.java The selected index should be "aad"
• ab78187: 8277105: Inconsistent handling of missing permitted subclasses
• adf3952: 8277372: Add getters for BOT and card table members
• 7c6f57f: 8275610: C2: Object field load floats above its null check resulting in a segfault
• a885aab: 8276125: RunThese24H.java SIGSEGV in JfrThreadGroup::thread_group_id
• ... and 46 more: https://git.openjdk.java.net/jdk/compare/e0f1fc783cb492dd1eb18f2d56c57bdc160a410d...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]

/integrate

[openjdk]

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

• 239362d: 8247973: Javadoc incorrect for IdentityArrayList, IdentityLinkedList
• 2c31a17: 8275082: Update XML Security for Java to 2.3.0
• 70bad89: 8277497: Last column cell in the JTAble row is read as empty cell
• 5045eb5: 8278273: Remove unnecessary exclusion of doclint accessibility checks
• 587e540: 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> (a java.lang.Class ...'
• 082fdf4: 8172065: javax/swing/JTree/4908142/bug4908142.java The selected index should be "aad"
• ab78187: 8277105: Inconsistent handling of missing permitted subclasses
• adf3952: 8277372: Add getters for BOT and card table members
• 7c6f57f: 8275610: C2: Object field load floats above its null check resulting in a segfault
• a885aab: 8276125: RunThese24H.java SIGSEGV in JfrThreadGroup::thread_group_id
• ... and 46 more: https://git.openjdk.java.net/jdk/compare/e0f1fc783cb492dd1eb18f2d56c57bdc160a410d...master

Your commit was automatically rebased without conflicts.

[openjdk]

@martinuy Pushed as commit ea8d3c9.

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