From valeriep at openjdk.org  Wed Mar  1 00:30:06 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 1 Mar 2023 00:30:06 GMT
Subject: RFR: 8295425: Match the default priv exp length between SunPKCS11
 and other JDK providers [v2]
In-Reply-To: <yBdPYvjTwviENyIxRp1o2wWKcGGb7uZrqJaXiumrErQ=.344cfe90-6f38-46b0-98f4-650f88c78c4e@github.com>
References: <6BzcCj_w9ioeKwOvaAEXP4sbjQb28G9PRTC-uJzTI7U=.7197bedc-d79b-4422-9b01-258a58bbc7ef@github.com>
 <yBdPYvjTwviENyIxRp1o2wWKcGGb7uZrqJaXiumrErQ=.344cfe90-6f38-46b0-98f4-650f88c78c4e@github.com>
Message-ID: <zjKdr17hJ9QOE1mtg8oc6gEmVWj-V8mpBO-yWGGbc-g=.e3823ce9-22bd-44ee-90ce-8f55180e2ac4@github.com>

On Tue, 28 Feb 2023 23:51:51 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This changes the SunPKCS11 provider to use the same default private exponent length as the value used by SunJCE provider when initializing the DH Key Pair Generator impl using key size. In addition, the generated key pair will contain the specified parameters. If the supplied parameter does not contain the optional private exponent length, then we will leave it to the underlying PKCS11 library.
>> 
>> Thanks in advance for the review~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed comment.

Any comment for release note: https://bugs.openjdk.org/browse/JDK-8303414?

-------------

PR: https://git.openjdk.org/jdk/pull/12466


From duke at openjdk.org  Wed Mar  1 01:41:05 2023
From: duke at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 1 Mar 2023 01:41:05 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <mL4PBATk8MKIh9F7tlUc_MQYtLodhYOffwwgJ7vFbbY=.dab7da4e-896a-49d7-80fc-bd35208050c6@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <mL4PBATk8MKIh9F7tlUc_MQYtLodhYOffwwgJ7vFbbY=.dab7da4e-896a-49d7-80fc-bd35208050c6@github.com>
Message-ID: <77VnxGIMfmfL9yKakRjGy1bAIEYUwNy0btQzAj6iFdw=.d7ce13a2-74d1-4c64-8ee3-12997f89d693@github.com>

On Tue, 28 Feb 2023 22:57:31 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java line 66:
> 
>> 64:  *   CK_ULONG ulPrfDataLen;
>> 65:  *   CK_UTF8CHAR_PTR pPassword;
>> 66:  *   CK_ULONG_PTR ulPasswordLen;
> 
> This does not match the one in PKCS#11 spec, the 'ulPasswordLen' should be CK_ULONG type.
> I see that you added another CK_PKCS5_PBKD2_PARAMS class matching the spec definition. Is this to work around some existing bug? It seems strange to put the inconsistent type in the original class and the correct one in the new class.

Hi @valeriepeng. There's been a typo in the `CK_PKCS5_PBKD2_PARAMS` structure for some time. Apparently this [led to divergences in token implementations](https://lists.oasis-open.org/archives/pkcs11/201304/msg00019.html#00016:~:text=We%20have%20a,ul%27%20prefix%20indicator "Re: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length"), where some considered `ulPasswordLen` as `CK_ULONG` (the intention) and others, [including NSS](https://lists.oasis-open.org/archives/pkcs11/201304/msg00023.html#:~:text=I%27ve%20checked,typo%2e), considered it as `CK_ULONG_PTR` (the typo, but trying to follow the standard verbatim).

This was fixed in [PKCS#11 v2.40 errata 01](https://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/errata01/os/pkcs11-curr-v2.40-errata01-os-complete.html#_Toc72656433 "2.26.3 Mechanisms > PKCS #5 and PKCS #5-style password-based encryption (PBE) > PKCS #5 PBKDF2 key generation mechanism parameters") by introducing the new `CK_PKCS5_PBKD2_PARAMS2` structure.

The [PKCS#11 v3.0 _Oasis_ published version of `pkcs11t.h`](https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/os/include/pkcs11-v3.0/pkcs11t.h) and also _OpenJDK_'s `pkcs11t.h` define both structures:
https://github.com/openjdk/jdk/blob/04278e6bf2da501542feb777ab864bbcc5794fd0/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11t.h#L1946-L1977

Also, nowadays [NSS still uses the _deprecated_ `CK_PKCS5_PBKD2_PARAMS`](https://github.com/nss-dev/nss/blob/NSS_3_88_RTM/lib/softoken/pkcs11c.c#L4053-L4054) instead of the new and recommended `CK_PKCS5_PBKD2_PARAMS2`, thus we defined both `CK_PKCS5_PBKD2_PARAMS.java` and `CK_PKCS5_PBKD2_PARAMS2.java`.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbaesken at openjdk.org  Wed Mar  1 07:53:04 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 1 Mar 2023 07:53:04 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return
In-Reply-To: <r0ML1QUKkITkOliCmLxEJCEgBHxVT07qZUS2k63e3Fk=.17b2fb36-0170-4dde-a882-84c360b3d30a@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
 <r0ML1QUKkITkOliCmLxEJCEgBHxVT07qZUS2k63e3Fk=.17b2fb36-0170-4dde-a882-84c360b3d30a@github.com>
Message-ID: <VjOAn2CstmmrXMZDZCYcmjOiHJOZ4vuKi_I0x2ZSi6I=.4c22215b-a7f1-4871-8a51-ffa7437173ec@github.com>

On Tue, 28 Feb 2023 17:55:39 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Makes sense.

Hi Christoph, thanks for the review !  
May I have a second review ?

Thanks, Matthias

-------------

PR: https://git.openjdk.org/jdk/pull/12788


From eirbjo at gmail.com  Wed Mar  1 07:58:21 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 1 Mar 2023 08:58:21 +0100
Subject: Remove com.sun.jarsigner package with related options
In-Reply-To: <D429F5A7-1210-448D-913F-617DB8A9BBE4@oracle.com>
References: <CA+pBWhu53JwD9QfRv8gkY6MSGv1unhJWbtUY8Z=53AxBpk1pfg@mail.gmail.com>
 <D429F5A7-1210-448D-913F-617DB8A9BBE4@oracle.com>
Message-ID: <CA+pBWhu9GQwh7nkxUYH1T3+n_UcVJdEPQaH6iZ7To_24_5PF_A@mail.gmail.com>

>
> This needs a CSR and a release note. Do you volunteer to write them? If
> yes, you can write as comments in the PR and I can move them into JBS. You
> can look at the CSRs for the 2 related bugs.
>

Thanks Weijun! Happy to write the CRS and release notes, I have included
them as comments in the PR.

Note that this is my first time writing an OpenJDK CSR or release note, so
I might have missed some required field or perhaps not following the
preferred writing style.

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230301/8ad9ef44/attachment.htm>

From duke at openjdk.org  Wed Mar  1 07:59:51 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 1 Mar 2023 07:59:51 GMT
Subject: RFR: 8303410: Remove ContentSigner
Message-ID: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>

The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 16. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).

This PR suggests it's time to remove this code:

- The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
- `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
- Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
- Mentions of the options in Resource files in the same directory is removed
- The `jarsigner.1` man page is updated to remove the section on the deprecated options
- The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

-------------

Commit messages:
 - Remove the com.sun.jarsigner package, the -altsigner and -altsignerpath options which have been deprecated since 9 and deprecated for removal since 16.

Changes: https://git.openjdk.org/jdk/pull/12791/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12791&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303410
  Stats: 688 lines in 13 files changed: 3 ins; 661 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/12791.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12791/head:pull/12791

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Wed Mar  1 07:59:52 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 1 Mar 2023 07:59:52 GMT
Subject: RFR: 8303410: Remove ContentSigner
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <bbGDVfSPTov3BwSsoYfLVDuQuyTvks_tn3dPCzzJYm8=.88e6eaa5-9874-4ad2-8e0c-b16250de61ff@github.com>

On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 16. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

Suggested release note:

Release Note: Removal of the -altsigner mechanism in jarsigner

The `jarsigner` options `-altsigner` and `-altsignerpath` have been removed, along with the underlying `ContentSigner` API in the package `com.sun.jarsigner` . The mechanism was deprecated in JDK 9 and marked for removal in JDK 15.

Suggested CSR:

### Compatibility Kind: 
source, binary, behavioral

### Compatibility Risk
minimal

### Compatibility Risk Description
The APIs were deprecated in JDK 9 with no known existing use. The probability that they have been used after that time is low.

### Summary
The `ContentSigner` API in `com.sun.jarsigner` and the accompanying `jarsigner` options `-altsigner` and `-altsignerpath` options have been deprecated for removal since JDK 15 and should be removed.

### Problem
This extension mechanism was deprecated in JDK 9 since it was deemed too low-level and had no known use. Removing it will reduce maintainence costs for jarsigner. 

### Solution
Remove the terminally deprecated classes `com.sun.jarsigner.ContentSigner`, `com.sun.jarsigner.ContentSignerParameters`and the associated `package-info.java` file.

Remove the `-altsigner` and `-altsignerpath` options from jarsigner tool. Remove any mention of these options from the jarsigner man page.

### Specification

The classes `com.sun.jarsigner.ContentSigner` and `com.sun.jarsigner.ContentSignerParameters` are removed. Any class implementing these interfaces will fail to compile.

`jarsigner --help` no longer list the -altsigner or -altsigner options.

`jarsigner -altsigner` will fail with an 'illegal option' message:


% jarsigner -altsigner
Illegal option: -altsigner

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Wed Mar  1 08:06:05 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 1 Mar 2023 08:06:05 GMT
Subject: RFR: 8303410: Remove ContentSigner
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <7_nfHMunAreWpkCWVvAYcGhCU9RJYwQZc8O38GY6zqI=.14da5a35-bc8b-4169-8c21-afb8b41488e4@github.com>

On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

I noticed that the `-altsigner` and `-altsigner` were deprectated for removal in JDK 15, but their `@Deprecated` annotations say `since="16"`.  Is inconsistency something we need to worry about?


@Deprecated(since="16", forRemoval=true)
private final String altSignerPath;
@Deprecated(since="16", forRemoval=true)
private final String altSigner;

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From lancea at openjdk.org  Wed Mar  1 11:41:07 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 1 Mar 2023 11:41:07 GMT
Subject: RFR: 8303410: Remove ContentSigner
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <k39Ha5tJCJ0ZQ1X-X3Jrq9vfDmJfhh1FeH7qAUgvdF0=.04f14b27-40bc-4358-be5f-f441836c7a28@github.com>

On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

> I noticed that the `-altsigner` and `-altsigner` were deprectated for removal in JDK 15, but their `@Deprecated` annotations say `since="16"`. Is inconsistency something we need to worry about?
> 
> ```java
> @Deprecated(since="16", forRemoval=true)
> private final String altSignerPath;
> @Deprecated(since="16", forRemoval=true)
> private final String altSigner;
> ```

I don't see an issue with a different version and given this was done in JDK 16 we are now 3 soon to be 4 releases past the notification

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From lancea at openjdk.org  Wed Mar  1 11:49:01 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 1 Mar 2023 11:49:01 GMT
Subject: RFR: 8303410: Remove ContentSigner
In-Reply-To: <bbGDVfSPTov3BwSsoYfLVDuQuyTvks_tn3dPCzzJYm8=.88e6eaa5-9874-4ad2-8e0c-b16250de61ff@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <bbGDVfSPTov3BwSsoYfLVDuQuyTvks_tn3dPCzzJYm8=.88e6eaa5-9874-4ad2-8e0c-b16250de61ff@github.com>
Message-ID: <JcEgBe-eUZivDYhdbiQQ4VE_TGuXsHtGSr1vOjK_cOc=.002ad843-d91d-4f53-ae13-12dec257f1c8@github.com>

On Wed, 1 Mar 2023 07:52:58 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Suggested CSR:
> 
> ### Compatibility Kind:
> source, binary, behavioral
> 
> ### Compatibility Risk
> minimal
> 
> ### Compatibility Risk Description
> The APIs were deprecated in JDK 9 with no known existing use. The probability that they have been used after that time is low.
> 
> ### Summary
> The `ContentSigner` API in `com.sun.jarsigner` and the accompanying `jarsigner` options `-altsigner` and `-altsignerpath` options have been deprecated for removal since JDK 15 and should be removed.
> 
> ### Problem
> This extension mechanism was deprecated in JDK 9 since it was deemed too low-level and had no known use. Removing it will reduce maintainence costs for jarsigner.
> 
> ### Solution
> Remove the terminally deprecated classes `com.sun.jarsigner.ContentSigner`, `com.sun.jarsigner.ContentSignerParameters`and the associated `package-info.java` file.
> 
> Remove the `-altsigner` and `-altsignerpath` options from jarsigner tool. Remove any mention of these options from the jarsigner man page.
> 
> ### Specification
> The classes `com.sun.jarsigner.ContentSigner` and `com.sun.jarsigner.ContentSignerParameters` are removed. Any class implementing these interfaces will fail to compile.
> 
> `jarsigner --help` no longer list the -altsigner or -altsigner options.
> 
> `jarsigner -altsigner` will fail with an 'illegal option' message:
> 
> ```
> % jarsigner -altsigner
> Illegal option: -altsigner
> ```

This looks good overall.  I would probably make the compatibility risk _low_.  

For your spec changes, I might borrow the format I used in [JDK-8193757](https://bugs.openjdk.org/browse/JDK-8193757)

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Wed Mar  1 12:06:07 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 1 Mar 2023 12:06:07 GMT
Subject: RFR: 8303410: Remove ContentSigner
In-Reply-To: <JcEgBe-eUZivDYhdbiQQ4VE_TGuXsHtGSr1vOjK_cOc=.002ad843-d91d-4f53-ae13-12dec257f1c8@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <bbGDVfSPTov3BwSsoYfLVDuQuyTvks_tn3dPCzzJYm8=.88e6eaa5-9874-4ad2-8e0c-b16250de61ff@github.com>
 <JcEgBe-eUZivDYhdbiQQ4VE_TGuXsHtGSr1vOjK_cOc=.002ad843-d91d-4f53-ae13-12dec257f1c8@github.com>
Message-ID: <7veQKzNb7p5WEj2gV7oWBGrsa3iP7egSX5u1XJJ8lvw=.c909904d-c9a0-48f0-b24f-1dd7b164058a@github.com>

On Wed, 1 Mar 2023 11:46:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> For your spec changes, I might borrow the format I used in [JDK-8193757](https://bugs.openjdk.org/browse/JDK-8193757)

I updated the Specification section to use the list-style format from JDK-8193757. I also included a mention of the jarsigner deprectated options section.

I'm assuming the Specification section should focus on externally visible changes, not implementation-internal removals.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From lancea at openjdk.org  Wed Mar  1 12:14:02 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 1 Mar 2023 12:14:02 GMT
Subject: RFR: 8303410: Remove ContentSigner
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <Fl50rj5PpwVo_of006e6v2aU2jhGHdg9Q5AyL4fxruU=.c1bad5ae-ed96-4b60-a1d5-2e0b05c1de7c@github.com>

On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

> > For your spec changes, I might borrow the format I used in [JDK-8193757](https://bugs.openjdk.org/browse/JDK-8193757)
> 
> I updated the Specification section to use the list-style format from JDK-8193757. I also included a mention of the jarsigner deprectated options section.
> 
> I'm assuming the Specification section should focus on externally visible changes, not implementation-internal removals.

Thank you for the quick updates :-)

Yes the Specification section addresses the changes to the spec that impact  users

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Wed Mar  1 15:30:19 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 1 Mar 2023 15:30:19 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates [v3]
In-Reply-To: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
Message-ID: <ndfXFnwvprhARfu-_CWeJNxXCEghf2Oxj4LGEyh0H28=.201cdb49-7c26-4f83-8d7a-f50f76217b3c@github.com>

> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into templates
 - updated certificate info
 - Merge branch 'master' into templates
 - reverted changes, removed SSLSocketSSLEngineTemplate, updated SSLEngineBadBufferArrayAccess.java
 - fixed compilation errors
 - Merge branch 'master' into templates
 - 8284047: Harmonize/Standardize the SSLSocket/SSLEngine/SSLSocketSSLEngine test templates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12555/files
  - new: https://git.openjdk.org/jdk/pull/12555/files/7e4c0740..3e971cc0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12555&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12555&range=01-02

  Stats: 3116 lines in 89 files changed: 2501 ins; 299 del; 316 mod
  Patch: https://git.openjdk.org/jdk/pull/12555.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12555/head:pull/12555

PR: https://git.openjdk.org/jdk/pull/12555


From mdoerr at openjdk.org  Wed Mar  1 16:25:14 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 16:25:14 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return
In-Reply-To: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
Message-ID: <C7GrqnTxSqdc51Tf6jewomktd54EhWJWhXxCGTDeqsE=.2eeee33b-a2cd-40c1-8c7e-944a57d24f1a@github.com>

On Tue, 28 Feb 2023 15:17:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a (potential) early return in addCertificatesToKeystore in KeystoreImpl.m . This is implemented by the CHECK_NULL macro. However this missed a CFRelease call.

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12788


From weijun at openjdk.org  Wed Mar  1 16:40:03 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Mar 2023 16:40:03 GMT
Subject: RFR: 8303410: Remove ContentSigner
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <iWJnqqr_JA_kqAbAI-CvIHIaewcNrFv3DYU7pA8X7yU=.22791961-344d-485e-9b5a-64510cf23f43@github.com>

On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

I'll create a CSR and add your text there.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From weijun at openjdk.org  Wed Mar  1 17:01:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Mar 2023 17:01:21 GMT
Subject: RFR: 8303410: Remove ContentSigner
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <1p87nf_IZnNXsYUD0RCrzyT3xbR_MLCqzsKmmqZX9yw=.d90ef07c-516c-4da4-a060-05d7ff6e2c72@github.com>

On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

I've filed the CSR at https://bugs.openjdk.org/browse/JDK-8303469 and added myself as a reviewer. I did add a comment saying this is contributed by Eirik so the CSR guys won't be surprised why I reviewed my own CSR. I've also added a link to RFC 8933 to explain why `ContentSigner` is not only useless but also not secure.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From mullan at openjdk.org  Wed Mar  1 17:19:06 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 1 Mar 2023 17:19:06 GMT
Subject: RFR: 8303410: Remove ContentSigner
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <lNpFYX0TK1rboSJX7r1BBh3brNBwjgtgBMULD3DgbOM=.dbc83234-321c-48dd-8858-fbad82db463c@github.com>

On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

I would add more words to the title of the issue to cover the changes, ex: "Remove ContentSigner APIs and jarsigner -altsigner and -altsignerpath options"

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From weijun at openjdk.org  Wed Mar  1 18:51:15 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Mar 2023 18:51:15 GMT
Subject: RFR: 8303410: Remove ContentSigner
In-Reply-To: <lNpFYX0TK1rboSJX7r1BBh3brNBwjgtgBMULD3DgbOM=.dbc83234-321c-48dd-8858-fbad82db463c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <lNpFYX0TK1rboSJX7r1BBh3brNBwjgtgBMULD3DgbOM=.dbc83234-321c-48dd-8858-fbad82db463c@github.com>
Message-ID: <YVQ_lhtiHHX-0_Q9WsNpi5kxXwWIAZ_9R-6R7jJUVig=.ecd02ba8-eca1-4547-a597-b6b8ce20a828@github.com>

On Wed, 1 Mar 2023 17:15:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I would add more words to the title of the issue to cover the changes, ex: "Remove ContentSigner APIs and jarsigner -altsigner and -altsignerpath options"

Seems better. I've updated the title of JBS issue and CSR.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From weijun at openjdk.org  Wed Mar  1 19:54:14 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Mar 2023 19:54:14 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return
In-Reply-To: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
Message-ID: <tdeJ8Fcqhyiwbmb1DF_Mpbaep2qFlpVTGHNG9RduaZc=.01f0a6fc-61e2-4ab6-905b-c71080fa8585@github.com>

On Tue, 28 Feb 2023 15:17:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a (potential) early return in addCertificatesToKeystore in KeystoreImpl.m . This is implemented by the CHECK_NULL macro. However this missed a CFRelease call.

src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 431:

> 429:                 CFRelease(trustSettings);
> 430:                 goto errOut;
> 431:             }

Do you also need to switch to `goto errOut` for other `CHECK_NULL` calls (line 389 etc)? They also skip the release of `keychainItemSearch`.

-------------

PR: https://git.openjdk.org/jdk/pull/12788


From valeriep at openjdk.org  Wed Mar  1 22:40:18 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 1 Mar 2023 22:40:18 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <77VnxGIMfmfL9yKakRjGy1bAIEYUwNy0btQzAj6iFdw=.d7ce13a2-74d1-4c64-8ee3-12997f89d693@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <mL4PBATk8MKIh9F7tlUc_MQYtLodhYOffwwgJ7vFbbY=.dab7da4e-896a-49d7-80fc-bd35208050c6@github.com>
 <77VnxGIMfmfL9yKakRjGy1bAIEYUwNy0btQzAj6iFdw=.d7ce13a2-74d1-4c64-8ee3-12997f89d693@github.com>
Message-ID: <Nr-fJk7ok_A3rN1-oGgFTbW4hfzTGnIvZAGoq2yWmIg=.747765e7-94d2-4a04-a70f-329bcac23d72@github.com>

On Wed, 1 Mar 2023 00:59:10 GMT, Francisco Ferrari Bihurriet <duke at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java line 66:
>> 
>>> 64:  *   CK_ULONG ulPrfDataLen;
>>> 65:  *   CK_UTF8CHAR_PTR pPassword;
>>> 66:  *   CK_ULONG_PTR ulPasswordLen;
>> 
>> This does not match the one in PKCS#11 spec, the 'ulPasswordLen' should be CK_ULONG type.
>> I see that you added another CK_PKCS5_PBKD2_PARAMS class matching the spec definition. Is this to work around some existing bug? It seems strange to put the inconsistent type in the original class and the correct one in the new class.
>
> Hi @valeriepeng. There's been a typo in the `CK_PKCS5_PBKD2_PARAMS` structure for some time. Apparently this [led to divergences in token implementations](https://lists.oasis-open.org/archives/pkcs11/201304/msg00019.html#00016:~:text=We%20have%20a,ul%27%20prefix%20indicator "Re: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length"), where some considered `ulPasswordLen` as `CK_ULONG` (the intention) and others, [including NSS](https://lists.oasis-open.org/archives/pkcs11/201304/msg00023.html#:~:text=I%27ve%20checked,typo%2e), considered it as `CK_ULONG_PTR` (the typo, but trying to follow the standard verbatim).
> 
> This was fixed in [PKCS#11 v2.40 errata 01](https://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/errata01/os/pkcs11-curr-v2.40-errata01-os-complete.html#_Toc72656433 "2.26.3 Mechanisms > PKCS #5 and PKCS #5-style password-based encryption (PBE) > PKCS #5 PBKDF2 key generation mechanism parameters") by introducing the new `CK_PKCS5_PBKD2_PARAMS2` structure.
> 
> The [PKCS#11 v3.0 _Oasis_ published version of `pkcs11t.h`](https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/os/include/pkcs11-v3.0/pkcs11t.h) and also _OpenJDK_'s `pkcs11t.h` define both structures:
> https://github.com/openjdk/jdk/blob/04278e6bf2da501542feb777ab864bbcc5794fd0/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11t.h#L1946-L1977
> 
> Also, nowadays [NSS still uses the _deprecated_ `CK_PKCS5_PBKD2_PARAMS`](https://github.com/nss-dev/nss/blob/NSS_3_88_RTM/lib/softoken/pkcs11c.c#L4053-L4054) instead of the new and recommended `CK_PKCS5_PBKD2_PARAMS2`, thus we defined both `CK_PKCS5_PBKD2_PARAMS.java` and `CK_PKCS5_PBKD2_PARAMS2.java`.

I see. Thanks much for the explanation~

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From valeriep at openjdk.org  Wed Mar  1 22:44:24 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 1 Mar 2023 22:44:24 GMT
Subject: Integrated: 8295425: Match the default priv exp length between
 SunPKCS11 and other JDK providers
In-Reply-To: <6BzcCj_w9ioeKwOvaAEXP4sbjQb28G9PRTC-uJzTI7U=.7197bedc-d79b-4422-9b01-258a58bbc7ef@github.com>
References: <6BzcCj_w9ioeKwOvaAEXP4sbjQb28G9PRTC-uJzTI7U=.7197bedc-d79b-4422-9b01-258a58bbc7ef@github.com>
Message-ID: <_hiNRyEJnx5QgzoI1NSMaEthE9xumecc3iP4ZJ3dFhI=.858e398a-441b-437d-9019-93ab0ae66124@github.com>

On Wed, 8 Feb 2023 01:53:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> This changes the SunPKCS11 provider to use the same default private exponent length as the value used by SunJCE provider when initializing the DH Key Pair Generator impl using key size. In addition, the generated key pair will contain the specified parameters. If the supplied parameter does not contain the optional private exponent length, then we will leave it to the underlying PKCS11 library.
> 
> Thanks in advance for the review~
> Valerie

This pull request has now been integrated.

Changeset: 394eac85
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/394eac850cf8def6107193695f1d438f083d275a
Stats:     131 lines in 2 files changed: 121 ins; 1 del; 9 mod

8295425: Match the default priv exp length between SunPKCS11 and other JDK providers

Reviewed-by: weijun

-------------

PR: https://git.openjdk.org/jdk/pull/12466


From mbaesken at openjdk.org  Thu Mar  2 08:26:12 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Mar 2023 08:26:12 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return
In-Reply-To: <tdeJ8Fcqhyiwbmb1DF_Mpbaep2qFlpVTGHNG9RduaZc=.01f0a6fc-61e2-4ab6-905b-c71080fa8585@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
 <tdeJ8Fcqhyiwbmb1DF_Mpbaep2qFlpVTGHNG9RduaZc=.01f0a6fc-61e2-4ab6-905b-c71080fa8585@github.com>
Message-ID: <aYAH6dYPgUOrcX6a_PwN_8eeVKdJNUtyUOdwxUt3FbI=.b18494df-8b08-40bc-bacd-ccd775043999@github.com>

On Wed, 1 Mar 2023 19:51:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> We have a (potential) early return in addCertificatesToKeystore in KeystoreImpl.m . This is implemented by the CHECK_NULL macro. However this missed a CFRelease call.
>
> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 431:
> 
>> 429:                 CFRelease(trustSettings);
>> 430:                 goto errOut;
>> 431:             }
> 
> Do you also need to switch to `goto errOut` for other `CHECK_NULL` calls (line 389 etc)? They also skip the release of `keychainItemSearch`.

Hi Weijun, yes I think you are right , according to https://developer.apple.com/documentation/security/1515366-seckeychainsearchcreatefromattri   we have to call  CFRelease on keychainItemSearch

-------------

PR: https://git.openjdk.org/jdk/pull/12788


From mbaesken at openjdk.org  Thu Mar  2 09:47:56 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Mar 2023 09:47:56 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return [v2]
In-Reply-To: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
Message-ID: <qemaUfLjpqsdCpyqQkpfuq8nY0TR5WxHPm_GCJNKZD0=.8815d137-2216-436b-b4bf-1c4abcffdf60@github.com>

> We have a (potential) early return in addCertificatesToKeystore in KeystoreImpl.m . This is implemented by the CHECK_NULL macro. However this missed a CFRelease call.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  handle missing CFRelease calls

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12788/files
  - new: https://git.openjdk.org/jdk/pull/12788/files/5508cdba..7f5c63f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12788&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12788&range=00-01

  Stats: 19 lines in 1 file changed: 14 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12788.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12788/head:pull/12788

PR: https://git.openjdk.org/jdk/pull/12788


From prappo at openjdk.org  Thu Mar  2 12:13:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 2 Mar 2023 12:13:14 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
Message-ID: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>

Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.

The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:


    diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
    --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
    +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
    @@ -17084,7 +17084,7 @@
                      throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
     <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
     <div class="block"><code>readObject</code> is called to restore the state of the
    - (@code BasicPermission} from a stream.</div>
    + <code>BasicPermission</code> from a stream.</div>
     <dl class="notes">
     <dt>Parameters:</dt>
     <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>

Notes
-----

* I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
* I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
* I will update copyright years after (and if) the fix had been approved, as required.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12826/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303480
  Stats: 75 lines in 39 files changed: 0 ins; 0 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/12826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12826/head:pull/12826

PR: https://git.openjdk.org/jdk/pull/12826


From mullan at openjdk.org  Thu Mar  2 13:24:07 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Mar 2023 13:24:07 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <GCwAXDcnMpAJDHxB9QMEP9UmwTYemW62F7RUdNaEVk8=.8b73051d-d3a8-4fac-ac48-efc3864d33bc@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

security related changes look fine.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826


From mbaesken at openjdk.org  Thu Mar  2 13:43:09 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Mar 2023 13:43:09 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
Message-ID: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>

After 8278449, we seem to ignore in the call

`  if (SecTrustSettingsCopyTrustSettings(certRef, kSecTrustSettingsDomainUser, &trustSettings) == errSecItemNotFound) `

all trusted certs from admin and system domains, so a lot more certs are ignored than necessary.
Probably we should take at least the certs with trust settings from kSecTrustSettingsDomainUser, kSecTrustSettingsDomainAdmin and kSecTrustSettingsDomainSystem domains .

-------------

Commit messages:
 - JDK-8303465

Changes: https://git.openjdk.org/jdk/pull/12829/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12829&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303465
  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12829.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12829/head:pull/12829

PR: https://git.openjdk.org/jdk/pull/12829


From mdoerr at openjdk.org  Thu Mar  2 13:50:07 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Mar 2023 13:50:07 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return [v2]
In-Reply-To: <qemaUfLjpqsdCpyqQkpfuq8nY0TR5WxHPm_GCJNKZD0=.8815d137-2216-436b-b4bf-1c4abcffdf60@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
 <qemaUfLjpqsdCpyqQkpfuq8nY0TR5WxHPm_GCJNKZD0=.8815d137-2216-436b-b4bf-1c4abcffdf60@github.com>
Message-ID: <fzBEJ6rTv9gzuWDtDURABeoW1Io-LsymvNErcczmOB8=.7e546a2c-e586-436a-9109-30e167aaa069@github.com>

On Thu, 2 Mar 2023 09:47:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have a (potential) early return in addCertificatesToKeystore in KeystoreImpl.m . This is implemented by the CHECK_NULL macro. However this missed a CFRelease call.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   handle missing CFRelease calls

Thanks for the update!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12788


From weijun at openjdk.org  Thu Mar  2 13:57:14 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Mar 2023 13:57:14 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return [v2]
In-Reply-To: <qemaUfLjpqsdCpyqQkpfuq8nY0TR5WxHPm_GCJNKZD0=.8815d137-2216-436b-b4bf-1c4abcffdf60@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
 <qemaUfLjpqsdCpyqQkpfuq8nY0TR5WxHPm_GCJNKZD0=.8815d137-2216-436b-b4bf-1c4abcffdf60@github.com>
Message-ID: <S0T--MYBVXRY9GB8m5TLWBHhs-VbrfOHgYD44652PSE=.c9ca7056-7e1d-4ca2-9a41-8fbf8ac015ea@github.com>

On Thu, 2 Mar 2023 09:47:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have a (potential) early return in addCertificatesToKeystore in KeystoreImpl.m . This is implemented by the CHECK_NULL macro. However this missed a CFRelease call.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   handle missing CFRelease calls

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12788


From weijun at openjdk.org  Thu Mar  2 13:57:17 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Mar 2023 13:57:17 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return [v2]
In-Reply-To: <aYAH6dYPgUOrcX6a_PwN_8eeVKdJNUtyUOdwxUt3FbI=.b18494df-8b08-40bc-bacd-ccd775043999@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
 <tdeJ8Fcqhyiwbmb1DF_Mpbaep2qFlpVTGHNG9RduaZc=.01f0a6fc-61e2-4ab6-905b-c71080fa8585@github.com>
 <aYAH6dYPgUOrcX6a_PwN_8eeVKdJNUtyUOdwxUt3FbI=.b18494df-8b08-40bc-bacd-ccd775043999@github.com>
Message-ID: <l-RcYMMFrq_Ii76C70pnLzTsBwjzX3fJ6742gl12nk8=.b0e7a8d5-16f5-4ed2-88c3-530ecf482bf6@github.com>

On Thu, 2 Mar 2023 08:22:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 431:
>> 
>>> 429:                 CFRelease(trustSettings);
>>> 430:                 goto errOut;
>>> 431:             }
>> 
>> Do you also need to switch to `goto errOut` for other `CHECK_NULL` calls (line 389 etc)? They also skip the release of `keychainItemSearch`.
>
> Hi Weijun, yes I think you are right , according to https://developer.apple.com/documentation/security/1515366-seckeychainsearchcreatefromattri   we have to call  CFRelease on keychainItemSearch

Thanks for the fix. I almost think we should invent a CHECK_NULL_GOTO_ERROUT macro, but your fix is also OK.

-------------

PR: https://git.openjdk.org/jdk/pull/12788


From mbaesken at openjdk.org  Thu Mar  2 14:21:14 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Mar 2023 14:21:14 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return [v2]
In-Reply-To: <qemaUfLjpqsdCpyqQkpfuq8nY0TR5WxHPm_GCJNKZD0=.8815d137-2216-436b-b4bf-1c4abcffdf60@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
 <qemaUfLjpqsdCpyqQkpfuq8nY0TR5WxHPm_GCJNKZD0=.8815d137-2216-436b-b4bf-1c4abcffdf60@github.com>
Message-ID: <MUXYqAmGLME5t3npqfToKfcauzI9-VxSpLn2S6R4NNQ=.679a25ea-44b3-44e5-a6f9-ef815183424c@github.com>

On Thu, 2 Mar 2023 09:47:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have a (potential) early return in addCertificatesToKeystore in KeystoreImpl.m . This is implemented by the CHECK_NULL macro. However this missed a CFRelease call.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   handle missing CFRelease calls

Hi Martin and Weijun, thanks for the reviews !

-------------

PR: https://git.openjdk.org/jdk/pull/12788


From mbaesken at openjdk.org  Thu Mar  2 14:21:18 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Mar 2023 14:21:18 GMT
Subject: RFR: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return [v2]
In-Reply-To: <l-RcYMMFrq_Ii76C70pnLzTsBwjzX3fJ6742gl12nk8=.b0e7a8d5-16f5-4ed2-88c3-530ecf482bf6@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
 <tdeJ8Fcqhyiwbmb1DF_Mpbaep2qFlpVTGHNG9RduaZc=.01f0a6fc-61e2-4ab6-905b-c71080fa8585@github.com>
 <aYAH6dYPgUOrcX6a_PwN_8eeVKdJNUtyUOdwxUt3FbI=.b18494df-8b08-40bc-bacd-ccd775043999@github.com>
 <l-RcYMMFrq_Ii76C70pnLzTsBwjzX3fJ6742gl12nk8=.b0e7a8d5-16f5-4ed2-88c3-530ecf482bf6@github.com>
Message-ID: <YszCzeXhHcT3eAUKMiRwviZrtINMUn96mf0y-bQds2M=.8ebc45f1-17e0-41fd-a9cb-18520315956e@github.com>

On Thu, 2 Mar 2023 13:54:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Thanks for the fix. I almost think we should invent a CHECK_NULL_GOTO_ERROUT macro, but your fix is also OK.

I think I  discussed a while back some extended CHECK_NULL_  - macros (I think it was for freeing before return) but it was not s well received.

-------------

PR: https://git.openjdk.org/jdk/pull/12788


From mbaesken at openjdk.org  Thu Mar  2 14:24:41 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Mar 2023 14:24:41 GMT
Subject: Integrated: JDK-8303354: addCertificatesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return
In-Reply-To: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
References: <dqQIbugRNJaK0WPFxLXAo62rICEpcS5m-LIp6LCnSoc=.d522bd41-c5f0-4805-b2e7-7bd446575ced@github.com>
Message-ID: <uu2z91DUfqs3IgtsiL3Pkj-Xa3mijSvhP7Le9JkIN_Q=.b8b002eb-52e9-42a3-b00f-f22884afe127@github.com>

On Tue, 28 Feb 2023 15:17:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a (potential) early return in addCertificatesToKeystore in KeystoreImpl.m . This is implemented by the CHECK_NULL macro. However this missed a CFRelease call.

This pull request has now been integrated.

Changeset: b51ea420
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b51ea4204eaa18687e7712e87cdc92efbddfcb5b
Stats:     24 lines in 1 file changed: 17 ins; 0 del; 7 mod

8303354: addCertificatesToKeystore in KeystoreImpl.m needs CFRelease call in early potential CHECK_NULL return

Reviewed-by: clanger, mdoerr, weijun

-------------

PR: https://git.openjdk.org/jdk/pull/12788


From weijun at openjdk.org  Thu Mar  2 15:28:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Mar 2023 15:28:23 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
Message-ID: <6Cno145jJucm02uGonKOdDNtRPgXo1BUy7id1DVu6zo=.833f1cf6-da4a-4aa8-9183-3595db9f0262@github.com>

On Thu, 2 Mar 2023 13:33:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After 8278449, we seem to ignore in the call
> 
> `  if (SecTrustSettingsCopyTrustSettings(certRef, kSecTrustSettingsDomainUser, &trustSettings) == errSecItemNotFound) `
> 
> all trusted certs from admin and system domains, so a lot more certs are ignored than necessary.
> Probably we should take at least the certs with trust settings from kSecTrustSettingsDomainUser, kSecTrustSettingsDomainAdmin and kSecTrustSettingsDomainSystem domains .

I'd like to contribute a test.

/*
 * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

import jdk.test.lib.process.OutputAnalyzer;
import jdk.test.lib.process.ProcessTools;

import java.security.KeyStore;
import java.util.ArrayList;
import java.util.List;

/*
 * @test
 * @bug 8303465
 * @library /test/lib
 * @requires os.family == "mac"
 * @summary list more trusted certificates
 */
public class ListKeyChain {


    public static void main(String[] args) throws Throwable {
        List<String> trusted = new ArrayList<>();
        populate(true, trusted);
        populate(false, trusted);
        System.out.println(trusted);
        KeyStore ks = KeyStore.getInstance("KEYCHAINSTORE");
        ks.load(null, null);
        for (String alias : trusted) {
            if (!ks.containsAlias(alias)) {
                throw new RuntimeException("Not found: " + alias);
            }
        }
    }

    static void populate(boolean admin, List<String> trusted) throws Throwable {
        OutputAnalyzer output = admin
                ? ProcessTools.executeProcess("security", "dump-trust-setting", "-d")
                : ProcessTools.executeProcess("security", "dump-trust-setting");
        String certName = null;
        for (String line : output.shouldHaveExitValue(0).asLines()) {
            if (line.startsWith("Cert ")) {
                certName = line.split(":", 2)[1].trim().toLowerCase();
            } else if (line.contains("Number of trust settings :")) {
                if (line.endsWith(": 0")) { // we only list trusted-for-all certs
                    trusted.add(certName);
                }
            }
        }
    }
}

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From mbaesken at openjdk.org  Thu Mar  2 16:11:21 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Mar 2023 16:11:21 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <6Cno145jJucm02uGonKOdDNtRPgXo1BUy7id1DVu6zo=.833f1cf6-da4a-4aa8-9183-3595db9f0262@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
 <6Cno145jJucm02uGonKOdDNtRPgXo1BUy7id1DVu6zo=.833f1cf6-da4a-4aa8-9183-3595db9f0262@github.com>
Message-ID: <rOwPGrlhKYyX4kThwsPzsFpcMGabmvOMRiai4rJw0ZA=.ab18c034-0adf-49f3-8878-27ad7ee07921@github.com>

On Thu, 2 Mar 2023 15:23:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I'd like to contribute a test.

Thanks for contributing the test.  Any suggestion where to place the test ?

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From mullan at openjdk.org  Thu Mar  2 16:52:07 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Mar 2023 16:52:07 GMT
Subject: RFR: 8297955: LDAP CertStore should use LdapName and not String for
 DNs
Message-ID: <n0Gyy22_w8VxOcL5DVg76fnX13Tz18qxAcM4fuZ3B1E=.3702a1b9-7eba-43c4-9576-d4f4f4831218@github.com>

The LDAPCertStore implementation passes Distinguished Names in CRL and Certificate URLs as Strings to JNDI APIs such as LdapContext.getAttributes(String), which then treats them as CompositeNames. This causes issues with URLs that have DNs with forward slashes. These are rare  but compliant with the LDAP URL format for DNs referenced by [section 4.2.1.13 of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.13). Instead, the implementation should be passing the DN to JNDI APIs as an LdapName, which parses the forward slash character as part of the DN. Unfortunately, LDAP referral URLs can not be converted to LdapNames, so we keep the current DN syntax checks (and disallow forward slashes) if there are referrals involved.

The current test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java can be used to test this fix as it contains a test certificate with an LDAP URL in the CRL Distribution Points with a forward slash in the Distinguished Name. Prior to the fix it was failing because of this bug, now it is passing. We also take this opportunity to update the test and replace expired test certificates with new ones.

-------------

Commit messages:
 - Add comments. Update Actalis test certificates.
 - Restore checking of composite name on referral URL.
 - Merge
 - Update copyright date.
 - Merge
 - Initial revision.

Changes: https://git.openjdk.org/jdk/pull/12730/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12730&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297955
  Stats: 62 lines in 2 files changed: 11 ins; 8 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/12730.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12730/head:pull/12730

PR: https://git.openjdk.org/jdk/pull/12730


From weijun at openjdk.org  Thu Mar  2 16:55:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Mar 2023 16:55:23 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <rOwPGrlhKYyX4kThwsPzsFpcMGabmvOMRiai4rJw0ZA=.ab18c034-0adf-49f3-8878-27ad7ee07921@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
 <6Cno145jJucm02uGonKOdDNtRPgXo1BUy7id1DVu6zo=.833f1cf6-da4a-4aa8-9183-3595db9f0262@github.com>
 <rOwPGrlhKYyX4kThwsPzsFpcMGabmvOMRiai4rJw0ZA=.ab18c034-0adf-49f3-8878-27ad7ee07921@github.com>
Message-ID: <Z40xM0gxTeZgX7pxRYDPBd89rVciHVS9t4ck7A8GU0c=.e57883a8-1e38-4a78-8d05-2dd23e810e7d@github.com>

On Thu, 2 Mar 2023 16:07:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > I'd like to contribute a test.
> 
> Thanks for contributing the test. Any suggestion where to place the test ?

Maybe just in `test/jdk/java/security/KeyStore/`. Otherwise needs to create a new dir and add it into some groups.

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From weijun at openjdk.org  Thu Mar  2 17:36:22 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Mar 2023 17:36:22 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
Message-ID: <44mGPVdsCfVP53BUPXepIKtWc-spM5f3rlc_gZYBIuA=.3b0f468a-f66a-4bb8-b632-44efe6ca4bb8@github.com>

On Thu, 2 Mar 2023 13:33:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After 8278449, we seem to ignore in the call
> 
> `  if (SecTrustSettingsCopyTrustSettings(certRef, kSecTrustSettingsDomainUser, &trustSettings) == errSecItemNotFound) `
> 
> all trusted certs from admin and system domains, so a lot more certs are ignored than necessary.
> Probably we should take at least the certs with trust settings from kSecTrustSettingsDomainUser, kSecTrustSettingsDomainAdmin and kSecTrustSettingsDomainSystem domains .

Oops, seems the `security` command is failing when running the test on our testing clients. Maybe no user privilege? I'll do more investigation and maybe have to make it an internal test or manual one.

It does run fine on my own machine.

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From prr at openjdk.org  Thu Mar  2 21:29:04 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Mar 2023 21:29:04 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <LDJs1K7coRg4R4EWiETtoqjNIaZchHUjyKAg2madLSM=.11763787-9322-4863-8ca9-242447a9c6de@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

java.desktop changes are fine

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826


From cjplummer at openjdk.org  Thu Mar  2 22:18:08 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 Mar 2023 22:18:08 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <63UHTjtrUOVGBTwRt_M4QJ7aqBnuAGqekNTTTl3GM74=.ddedac04-ff87-40b9-9ea7-6b6d26d9d202@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

The SA changes (jdk.hotspot.agent) look fine.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826


From weijun at openjdk.org  Thu Mar  2 22:32:07 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Mar 2023 22:32:07 GMT
Subject: RFR: 8297955: LDAP CertStore should use LdapName and not String
 for DNs
In-Reply-To: <n0Gyy22_w8VxOcL5DVg76fnX13Tz18qxAcM4fuZ3B1E=.3702a1b9-7eba-43c4-9576-d4f4f4831218@github.com>
References: <n0Gyy22_w8VxOcL5DVg76fnX13Tz18qxAcM4fuZ3B1E=.3702a1b9-7eba-43c4-9576-d4f4f4831218@github.com>
Message-ID: <xQQacCvUmRKJLNNMtr_S18hJ5bizlAUMvDItpt82AZY=.02376d6b-9ae4-48c0-a146-cd801a869aa5@github.com>

On Thu, 23 Feb 2023 16:42:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> The LDAPCertStore implementation passes Distinguished Names in CRL and Certificate URLs as Strings to JNDI APIs such as LdapContext.getAttributes(String), which then treats them as CompositeNames. This causes issues with URLs that have DNs with forward slashes. These are rare  but compliant with the LDAP URL format for DNs referenced by [section 4.2.1.13 of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.13). Instead, the implementation should be passing the DN to JNDI APIs as an LdapName, which parses the forward slash character as part of the DN. Unfortunately, LDAP referral URLs can not be converted to LdapNames, so we keep the current DN syntax checks (and disallow forward slashes) if there are referrals involved.
> 
> The current test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java can be used to test this fix as it contains a test certificate with an LDAP URL in the CRL Distribution Points with a forward slash in the Distinguished Name. Prior to the fix it was failing because of this bug, now it is passing. We also take this opportunity to update the test and replace expired test certificates with new ones.

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12730


From rhalade at openjdk.org  Thu Mar  2 22:50:13 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 2 Mar 2023 22:50:13 GMT
Subject: RFR: 8297955: LDAP CertStore should use LdapName and not String
 for DNs
In-Reply-To: <n0Gyy22_w8VxOcL5DVg76fnX13Tz18qxAcM4fuZ3B1E=.3702a1b9-7eba-43c4-9576-d4f4f4831218@github.com>
References: <n0Gyy22_w8VxOcL5DVg76fnX13Tz18qxAcM4fuZ3B1E=.3702a1b9-7eba-43c4-9576-d4f4f4831218@github.com>
Message-ID: <nYQLjQ3Io4UTYq5KtJ08-PSH-x0aIvPoGIRUgnLs76w=.50574ca5-f2b1-44e9-bc73-cc53bf7dcc7e@github.com>

On Thu, 23 Feb 2023 16:42:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> The LDAPCertStore implementation passes Distinguished Names in CRL and Certificate URLs as Strings to JNDI APIs such as LdapContext.getAttributes(String), which then treats them as CompositeNames. This causes issues with URLs that have DNs with forward slashes. These are rare  but compliant with the LDAP URL format for DNs referenced by [section 4.2.1.13 of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.13). Instead, the implementation should be passing the DN to JNDI APIs as an LdapName, which parses the forward slash character as part of the DN. Unfortunately, LDAP referral URLs can not be converted to LdapNames, so we keep the current DN syntax checks (and disallow forward slashes) if there are referrals involved.
> 
> The current test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java can be used to test this fix as it contains a test certificate with an LDAP URL in the CRL Distribution Points with a forward slash in the Distinguished Name. Prior to the fix it was failing because of this bug, now it is passing. We also take this opportunity to update the test and replace expired test certificates with new ones.

Marked as reviewed by rhalade (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12730


From mbaesken at openjdk.org  Fri Mar  3 07:37:13 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 3 Mar 2023 07:37:13 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <6Cno145jJucm02uGonKOdDNtRPgXo1BUy7id1DVu6zo=.833f1cf6-da4a-4aa8-9183-3595db9f0262@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
 <6Cno145jJucm02uGonKOdDNtRPgXo1BUy7id1DVu6zo=.833f1cf6-da4a-4aa8-9183-3595db9f0262@github.com>
Message-ID: <PzufZF9eZAwjAQL9dprGctcBtPcZiGeFdaszonZ0774=.62ee51d9-7083-4da1-ac0b-ff2adc025593@github.com>

On Thu, 2 Mar 2023 15:23:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> dump-trust-setting

I have found some errors with dump-trust-settings like this one https://github.com/wbond/package_control/issues/1017  but not sure if this is related to what you saw on your test infrastructure.

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From aivanov at openjdk.org  Fri Mar  3 08:28:19 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Mar 2023 08:28:19 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

Looks good to me.

I looked through all the changes, paying more attention to the client area.

src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:

> 255: 
> 256:     /**
> 257:      * @return true iff the BSM method type exactly matches

I assume ?iff? should ?if??

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866:

> 2864:      * Merge multiple abstract methods. The preferred method is a method that is a subsignature
> 2865:      * of all the other signatures and whose return type is more specific {@link MostSpecificReturnCheck}.
> 2866:      * The resulting preferred method has a thrown clause that is the intersection of the merged

Is it ??has a {@code throws} clause???

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826


From prappo at openjdk.org  Fri Mar  3 09:41:06 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 Mar 2023 09:41:06 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
Message-ID: <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>

On Thu, 2 Mar 2023 16:23:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:
> 
>> 255: 
>> 256:     /**
>> 257:      * @return true iff the BSM method type exactly matches
> 
> I assume ?iff? should ?if??

Here and elsewhere in this file "iff" might mean [if and only if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense. (FWIW, there are a few hundred occurrences of the word "iff" in src.)

@cl4es (Claes Redestad), as the author of those lines would you like to chime in?

Since Claes might read this, I note that when I changed unsupported `{@see}` to `{@link}` thoughtout this file, my IDE could not resolve one of the links: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)`

While there's a similarly-name method with slightly different parameters, I refrained from using it:
`java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`.

-------------

PR: https://git.openjdk.org/jdk/pull/12826


From prappo at openjdk.org  Fri Mar  3 09:44:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 Mar 2023 09:44:13 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
Message-ID: <5TgKeBVz0u1hCa1qOiC7Y46DJvUtDIsDa1wv2I4tAX8=.8575f968-0685-450d-8d77-16523cd7531a@github.com>

On Fri, 3 Mar 2023 08:15:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866:
> 
>> 2864:      * Merge multiple abstract methods. The preferred method is a method that is a subsignature
>> 2865:      * of all the other signatures and whose return type is more specific {@link MostSpecificReturnCheck}.
>> 2866:      * The resulting preferred method has a thrown clause that is the intersection of the merged
> 
> Is it ??has a {@code throws} clause???

Thanks! I'll add this to a separate PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12826


From redestad at openjdk.org  Fri Mar  3 10:12:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 3 Mar 2023 10:12:13 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
Message-ID: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>

On Fri, 3 Mar 2023 09:38:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:
>> 
>>> 255: 
>>> 256:     /**
>>> 257:      * @return true iff the BSM method type exactly matches
>> 
>> I assume ?iff? should ?if??
>
> Here and elsewhere in this file "iff" might mean [if and only if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense. (FWIW, there are a few hundred occurrences of the word "iff" in src.)
> 
> @cl4es (Claes Redestad), as the author of those lines would you like to chime in?
> 
> Since Claes might read this, I note that when I changed unsupported `{@see}` to `{@link}` thoughtout this file, my IDE could not resolve one of the links: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)`
> 
> While there's a similarly-name method with slightly different parameters, I refrained from using it:
> `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`.

Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. As @pavelrappo points out it's a relatively common occurrence in the OpenJDK sources, though perhaps not in the public javadocs. Perhaps a bit pretentious, but mostly a terse way to say "return true if the BSM method type exactly matches X, otherwise false".

The broken link stems from the fact that the method I was targeting (a way to use condy for lambda proxy singletons rather than a `MethodHandle.constant`) was never integrated. We'll look at either getting that done (@briangoetz suggested the time might be ready for it) or remove this currently pointless static bootstrap specialization test.

-------------

PR: https://git.openjdk.org/jdk/pull/12826


From aivanov at openjdk.org  Fri Mar  3 11:34:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Mar 2023 11:34:16 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
 <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
Message-ID: <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>

On Fri, 3 Mar 2023 10:09:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics.

I've never come across it before. With your explanations, it makes perfect sense.

-------------

PR: https://git.openjdk.org/jdk/pull/12826


From mullan at openjdk.org  Fri Mar  3 13:09:33 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 3 Mar 2023 13:09:33 GMT
Subject: Integrated: 8297955: LDAP CertStore should use LdapName and not String
 for DNs
In-Reply-To: <n0Gyy22_w8VxOcL5DVg76fnX13Tz18qxAcM4fuZ3B1E=.3702a1b9-7eba-43c4-9576-d4f4f4831218@github.com>
References: <n0Gyy22_w8VxOcL5DVg76fnX13Tz18qxAcM4fuZ3B1E=.3702a1b9-7eba-43c4-9576-d4f4f4831218@github.com>
Message-ID: <uugk9o81PIidjHgXwPS1ctve0BZ1erHk1TxnS4hfuX0=.6cb15edc-23e0-4316-8e09-a440e3fb4034@github.com>

On Thu, 23 Feb 2023 16:42:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> The LDAPCertStore implementation passes Distinguished Names in CRL and Certificate URLs as Strings to JNDI APIs such as LdapContext.getAttributes(String), which then treats them as CompositeNames. This causes issues with URLs that have DNs with forward slashes. These are rare  but compliant with the LDAP URL format for DNs referenced by [section 4.2.1.13 of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.13). Instead, the implementation should be passing the DN to JNDI APIs as an LdapName, which parses the forward slash character as part of the DN. Unfortunately, LDAP referral URLs can not be converted to LdapNames, so we keep the current DN syntax checks (and disallow forward slashes) if there are referrals involved.
> 
> The current test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java can be used to test this fix as it contains a test certificate with an LDAP URL in the CRL Distribution Points with a forward slash in the Distinguished Name. Prior to the fix it was failing because of this bug, now it is passing. We also take this opportunity to update the test and replace expired test certificates with new ones.

This pull request has now been integrated.

Changeset: df9aad01
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df9aad018a769a27221cb29e4e66465e5d98ba94
Stats:     62 lines in 2 files changed: 11 ins; 8 del; 43 mod

8297955: LDAP CertStore should use LdapName and not String for DNs

Reviewed-by: weijun, rhalade

-------------

PR: https://git.openjdk.org/jdk/pull/12730


From weijun at openjdk.org  Fri Mar  3 14:13:14 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Mar 2023 14:13:14 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
Message-ID: <QZYBP9XOV9DwPb_tLOWvDP_gJkTA6GptUoC67HUNIOw=.8ace1dca-43d6-45b9-aafb-b77fbe2dbc2b@github.com>

On Thu, 2 Mar 2023 13:33:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After 8278449, we seem to ignore in the call
> 
> `  if (SecTrustSettingsCopyTrustSettings(certRef, kSecTrustSettingsDomainUser, &trustSettings) == errSecItemNotFound) `
> 
> all trusted certs from admin and system domains, so a lot more certs are ignored than necessary.
> Probably we should take at least the certs with trust settings from kSecTrustSettingsDomainUser, kSecTrustSettingsDomainAdmin and kSecTrustSettingsDomainSystem domains .

The command shows `SecTrustSettingsCopyCertificates: No Trust Settings were found.` and exits with 1.

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From weijun at openjdk.org  Fri Mar  3 15:19:13 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Mar 2023 15:19:13 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
Message-ID: <5Rve41gX2U4eAidy2uF9Mw7BnG3qDMOWG90kvUQ1GQA=.a2f3c078-1b18-4625-be62-3451a659c9ac@github.com>

On Thu, 2 Mar 2023 13:33:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After 8278449, we seem to ignore in the call
> 
> `  if (SecTrustSettingsCopyTrustSettings(certRef, kSecTrustSettingsDomainUser, &trustSettings) == errSecItemNotFound) `
> 
> all trusted certs from admin and system domains, so a lot more certs are ignored than necessary.
> Probably we should take at least the certs with trust settings from kSecTrustSettingsDomainUser, kSecTrustSettingsDomainAdmin and kSecTrustSettingsDomainSystem domains .

Maybe it's only the testing machines are too clean and simply do not have any trusted settings. I tried `security dump-trust-settings -s` there and it shows all root CAs.

I've made a small change to the test and it will not fail when exit value is not 0.

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From weijun.wang at oracle.com  Fri Mar  3 17:29:53 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Fri, 3 Mar 2023 17:29:53 +0000
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
Message-ID: <3273EFFC-5430-46F0-80CE-01C6A9E79979@oracle.com>

Hi All,

The JEP draft was just updated again.

The major change is that there is no more DerivedKeyParameterSpec class. Maybe it's because of the name, but we found many people treating it as a place to configure the KDF used inside a KEM. Actually the only usage of it is to give caller a chance to wrap (possibly a portion of) the shared secret into a SecretKey.

Therefore we drop the class and directly put the fields in the argument list of the encapsulate method, i.e.

  encapsulate(int from, int to, String algorithm);

We also noticed that unlike traditional KEM algorithms (like RSA-KEM and ECIES) that allow a user to choose an arbitrary KDF output length so the generated shared secret can be directly used as a cipher key, modern KEM algorithms have a constant shared secret size, and the output of the KEM is usually passed into a KDF to generate more keys. Therefore we are now providing a shorter method

  encapsulate();

that simply returns a SecretKey containing the full shared secret with algorithm name "Generic".

We hope this shorter method will be mostly used, and the longer one that takes from, to, and algorithm as arguments is only used for the traditional use case where the shared secret is directly used as a cipher key. This longer method might not always be supported by every implementation. For example, in PKCS #11 only a recognized algorithm can be mapped into a valid key type, and the key length must match the key type. In fact, if you want to derive an AES key but the size of the shared secret is bigger than your preferred key size, it's always the leading bytes of the shared secret that are removed. This means you can call encapsulate(secretSize() - 32, secretSize(), "AES") but calling encapsulate(0, 32, "AES") will throw an UnsupportedOperationException.

> 
> Please take a look. The updated JEP is still at https://openjdk.org/jeps/8301034.
> 

Thanks,
Max




From ecki at zusammenkunft.net  Fri Mar  3 17:37:56 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Fri, 3 Mar 2023 18:37:56 +0100
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <3273EFFC-5430-46F0-80CE-01C6A9E79979@oracle.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>,
 <3273EFFC-5430-46F0-80CE-01C6A9E79979@oracle.com>
Message-ID: <F8BCF847-C857-304E-86C2-ED81FB97B1D0@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230303/26c227ad/attachment.htm>

From duke at openjdk.org  Fri Mar  3 19:53:22 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 3 Mar 2023 19:53:22 GMT
Subject: RFR: 8296400: pointCrlIssuers might be null in
 DistributionPointFetcher::verifyURL
Message-ID: <gimiHYgrjuGMnIXl0qXJ8rDjAtbrG5W5ZYqRFPyhtPQ=.87f41307-bcd1-49ac-82ab-a6f6be401692@github.com>

Added null-checks for pointCrlIssuers before it is accessed.

-------------

Commit messages:
 - 8296400: pointCrlIssuers might be null in DistributionPointFetcher::verifyURL

Changes: https://git.openjdk.org/jdk/pull/12866/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12866&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296400
  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12866.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12866/head:pull/12866

PR: https://git.openjdk.org/jdk/pull/12866


From mullan at openjdk.org  Mon Mar  6 16:04:16 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Mar 2023 16:04:16 GMT
Subject: RFR: 8301793: AlgorithmId should not encode a missing parameters
 field as NULL unless hardcoded
In-Reply-To: <ERKkcP8r3ZiEYRqIMNkHvpG7VYSXCNGkDd_Sd9td-84=.5e3aba17-1b85-4a66-b27c-13ef41a01f61@github.com>
References: <ERKkcP8r3ZiEYRqIMNkHvpG7VYSXCNGkDd_Sd9td-84=.5e3aba17-1b85-4a66-b27c-13ef41a01f61@github.com>
Message-ID: <uH26kPWfx0tlDQsF231nj5-Us42NN05GQz1fU1p-xfA=.d10a2fd6-84c2-4a83-a204-8f4f93aa45ae@github.com>

On Fri, 3 Feb 2023 17:35:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Change blocklist to allowlist for encoding null parameters in `AlgorithmId`.

test/jdk/sun/security/x509/AlgorithmId/NullParams.java line 108:

> 106:         } else {
> 107:             if (data.available() != 0) {
> 108:                 System.out.println("Has expected NULL");

Should the message be "Has unexpected NULL"?

-------------

PR: https://git.openjdk.org/jdk/pull/12412


From mullan at openjdk.org  Mon Mar  6 16:07:12 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Mar 2023 16:07:12 GMT
Subject: RFR: 8301793: AlgorithmId should not encode a missing parameters
 field as NULL unless hardcoded
In-Reply-To: <ERKkcP8r3ZiEYRqIMNkHvpG7VYSXCNGkDd_Sd9td-84=.5e3aba17-1b85-4a66-b27c-13ef41a01f61@github.com>
References: <ERKkcP8r3ZiEYRqIMNkHvpG7VYSXCNGkDd_Sd9td-84=.5e3aba17-1b85-4a66-b27c-13ef41a01f61@github.com>
Message-ID: <koxcuplbvvYJl7k8vWKBXKQbPyScQtCYYFFwSFIlsD4=.ed078c3f-8d61-4841-8fd4-5404396efb0c@github.com>

On Fri, 3 Feb 2023 17:35:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Change blocklist to allowlist for encoding null parameters in `AlgorithmId`.

Looks good other than the minor test comment but I think this is probably an Enhancement rather than a Bug.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12412


From weijun at openjdk.org  Mon Mar  6 16:12:45 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Mar 2023 16:12:45 GMT
Subject: RFR: 8301793: AlgorithmId should not encode a missing parameters
 field as NULL unless hardcoded
In-Reply-To: <koxcuplbvvYJl7k8vWKBXKQbPyScQtCYYFFwSFIlsD4=.ed078c3f-8d61-4841-8fd4-5404396efb0c@github.com>
References: <ERKkcP8r3ZiEYRqIMNkHvpG7VYSXCNGkDd_Sd9td-84=.5e3aba17-1b85-4a66-b27c-13ef41a01f61@github.com>
 <koxcuplbvvYJl7k8vWKBXKQbPyScQtCYYFFwSFIlsD4=.ed078c3f-8d61-4841-8fd4-5404396efb0c@github.com>
Message-ID: <bbf3JtD0JsVZLCZ5FeCuvVk04tML3Hc3rJjCJaWyASg=.35688b97-3fdc-434c-9e8b-d2622ed91d9a@github.com>

On Mon, 6 Mar 2023 16:04:13 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Looks good other than the minor test comment but I think this is probably an Enhancement rather than a Bug.

Thanks. Fixed the test and updated the issue as an enhancement.

> test/jdk/sun/security/x509/AlgorithmId/NullParams.java line 108:
> 
>> 106:         } else {
>> 107:             if (data.available() != 0) {
>> 108:                 System.out.println("Has expected NULL");
> 
> Should the message be "Has unexpected NULL"?

Yes.

-------------

PR: https://git.openjdk.org/jdk/pull/12412


From weijun at openjdk.org  Mon Mar  6 16:25:32 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Mar 2023 16:25:32 GMT
Subject: RFR: 8301793: AlgorithmId should not encode a missing parameters
 field as NULL unless hardcoded [v2]
In-Reply-To: <ERKkcP8r3ZiEYRqIMNkHvpG7VYSXCNGkDd_Sd9td-84=.5e3aba17-1b85-4a66-b27c-13ef41a01f61@github.com>
References: <ERKkcP8r3ZiEYRqIMNkHvpG7VYSXCNGkDd_Sd9td-84=.5e3aba17-1b85-4a66-b27c-13ef41a01f61@github.com>
Message-ID: <Q5Yv0XxjBpu4kv637k7QDa40b5CbN1xfdOBM4eFVPXE=.7d55b8c4-c8f0-451e-9edd-bc9c67526710@github.com>

> Change blocklist to allowlist for encoding null parameters in `AlgorithmId`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  unexpected

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12412/files
  - new: https://git.openjdk.org/jdk/pull/12412/files/d2fd2048..f6f676c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12412&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12412&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12412.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12412/head:pull/12412

PR: https://git.openjdk.org/jdk/pull/12412


From weijun at openjdk.org  Mon Mar  6 16:25:36 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Mar 2023 16:25:36 GMT
Subject: Integrated: 8301793: AlgorithmId should not encode a missing
 parameters field as NULL unless hardcoded
In-Reply-To: <ERKkcP8r3ZiEYRqIMNkHvpG7VYSXCNGkDd_Sd9td-84=.5e3aba17-1b85-4a66-b27c-13ef41a01f61@github.com>
References: <ERKkcP8r3ZiEYRqIMNkHvpG7VYSXCNGkDd_Sd9td-84=.5e3aba17-1b85-4a66-b27c-13ef41a01f61@github.com>
Message-ID: <Zed4Gr9IZH04QE1-qSr7yCEHtbDHhx9WAQ1S8VKlNxA=.bd4d3099-3320-4df1-b043-8431ff51099a@github.com>

On Fri, 3 Feb 2023 17:35:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Change blocklist to allowlist for encoding null parameters in `AlgorithmId`.

This pull request has now been integrated.

Changeset: a97271e3
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a97271e3b5d5a08fc503a11cd3e253974fb77ce6
Stats:     193 lines in 2 files changed: 121 ins; 21 del; 51 mod

8301793: AlgorithmId should not encode a missing parameters field as NULL unless hardcoded

Reviewed-by: mullan

-------------

PR: https://git.openjdk.org/jdk/pull/12412


From duke at openjdk.org  Mon Mar  6 18:50:12 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Mar 2023 18:50:12 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <2Ya8O2iTwiqrU6SlwVCg2RU2xhY-X6UQRm5RDzCQI4A=.be24ab94-31c6-4deb-b1e5-a9530881b088@github.com>

On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

The CSR seems to be approved, so I guess it should be OK to proceeed with reviewing the actual deletions now?

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Mon Mar  6 19:02:02 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Mar 2023 19:02:02 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v2]
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <xlIiD1MHJ3DAlxyo0HJW8emn4IAE36KEZTJG75flL7c=.b90f4803-c0db-4c86-8618-90f8435f6e95@github.com>

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to generated file jarsigner.1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12791/files
  - new: https://git.openjdk.org/jdk/pull/12791/files/71c0e1b9..fdbcf021

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12791&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12791&range=00-01

  Stats: 58 lines in 1 file changed: 57 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12791.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12791/head:pull/12791

PR: https://git.openjdk.org/jdk/pull/12791


From weijun at openjdk.org  Mon Mar  6 19:02:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Mar 2023 19:02:04 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <xyUN0yyIVQgqc6sWY9y8zQ4ZfXAyPi4hC7F7IioPyRo=.099f2833-6609-4eaf-8d43-38e301a2a396@github.com>

On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

Yes. I'll review the change.

BTW, you don't need to touch `jarsigner.1`. It is auto-generated and another team maintains the source.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Mon Mar  6 19:02:04 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Mar 2023 19:02:04 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options
In-Reply-To: <xyUN0yyIVQgqc6sWY9y8zQ4ZfXAyPi4hC7F7IioPyRo=.099f2833-6609-4eaf-8d43-38e301a2a396@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <xyUN0yyIVQgqc6sWY9y8zQ4ZfXAyPi4hC7F7IioPyRo=.099f2833-6609-4eaf-8d43-38e301a2a396@github.com>
Message-ID: <LluZrfQ_o7RY5RhhFzpUB7vvPBVWnUPkn6cGS0-TfwY=.4b157b1e-b1c6-4cf6-9c27-ff53d4932527@github.com>

On Mon, 6 Mar 2023 18:52:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> BTW, you don't need to touch `jarsigner.1`. It is auto-generated and another team maintains the source.

Thanks, I was not aware. I have reverted the changes to this file and trust it will be updated through some other channel.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From prappo at openjdk.org  Mon Mar  6 20:22:48 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 Mar 2023 20:22:48 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8303480
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12826/files
  - new: https://git.openjdk.org/jdk/pull/12826/files/d2f4a553..87166408

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=00-01

  Stats: 13433 lines in 415 files changed: 9003 ins; 2610 del; 1820 mod
  Patch: https://git.openjdk.org/jdk/pull/12826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12826/head:pull/12826

PR: https://git.openjdk.org/jdk/pull/12826


From jjg at openjdk.org  Mon Mar  6 20:31:18 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 20:31:18 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
 <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
 <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>
Message-ID: <ZXfrODW3U49MwVjsf7erqcN1x3lsi5dyU5SSaETKruY=.616faeb3-663f-4191-8bec-8fc0c9eba48d@github.com>

On Fri, 3 Mar 2023 11:31:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. As @pavelrappo points out it's a relatively common occurrence in the OpenJDK sources, though perhaps not in the public javadocs. Perhaps a bit pretentious, but mostly a terse way to say "return true if the BSM method type exactly matches X, otherwise false".
>> 
>> The broken link stems from the fact that the method I was targeting (a way to use condy for lambda proxy singletons rather than a `MethodHandle.constant`) was never integrated. We'll look at either getting that done (@briangoetz suggested the time might be ready for it) or remove this currently pointless static bootstrap specialization test.
>
>> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics.
> 
> I've never come across it before. With your explanations, it makes perfect sense.

I would recommend (separately) changing `iff` to the expanded form `if and only if`

-------------

PR: https://git.openjdk.org/jdk/pull/12826


From jjg at openjdk.org  Mon Mar  6 20:36:13 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 20:36:13 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <ztCzFqlAYLpzLdZY0K_GgKPNNOvqF9FNTbDh5ZEg-lk=.3aa6a92b-a286-4760-bdc4-425f48e53a6f@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12826


From lancea at openjdk.org  Mon Mar  6 20:39:17 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 6 Mar 2023 20:39:17 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <RWgaYiwcqLzeKKbnHxAAnPlwk1ndum8VkwVOnvJAbMM=.e0a4507f-dd64-41c8-89c6-70ceb8d34995@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12826


From rriggs at openjdk.org  Mon Mar  6 21:29:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 6 Mar 2023 21:29:08 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <xJn3JEoOJduXQZ9MF4uueB3KdIC4T_3roLNAWSQ8mZM=.4d80d353-a5e3-4cc4-87b3-320643f8cc36@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12826


From macarte at openjdk.org  Mon Mar  6 21:35:14 2023
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 6 Mar 2023 21:35:14 GMT
Subject: RFR: 8303607: SunMSCAPI provider leaks memory and keys
Message-ID: <Q8wu8EpoRzPn70dQC2QEdvaae0Cqro59SCggunsFaeI=.412420e5-d54f-4cf4-bf7f-0a5eef04053b@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
Use the correct API for freeing key handles when directed to by the output of CryptAcquireCertificatePrivateKey [1].
Specifically when [out] pfCallerFreeProvOrNCryptKey is true we test [out] pdwKeySpec for the CERT_NCRYPT_KEY_SPEC flag.  When flag bit is set we now call NCryptFreeObject, otherwise we continue to call CryptReleaseContext (as before)

[1] https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptacquirecertificateprivatekey

-------------

Commit messages:
 - Merge branch 'openjdk:master' into ncrypt
 - Fix handle leak

Changes: https://git.openjdk.org/jdk/pull/12891/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12891&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303607
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12891.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12891/head:pull/12891

PR: https://git.openjdk.org/jdk/pull/12891


From Matthew.Carter at microsoft.com  Mon Mar  6 21:44:12 2023
From: Matthew.Carter at microsoft.com (Mat Carter)
Date: Mon, 6 Mar 2023 21:44:12 +0000
Subject: RFR: 8303607: SunMSCAPI provider leaks memory and keys
In-Reply-To: <Q8wu8EpoRzPn70dQC2QEdvaae0Cqro59SCggunsFaeI=.412420e5-d54f-4cf4-bf7f-0a5eef04053b@github.com>
References: <Q8wu8EpoRzPn70dQC2QEdvaae0Cqro59SCggunsFaeI=.412420e5-d54f-4cf4-bf7f-0a5eef04053b@github.com>
Message-ID: <BYAPR00MB05984EBF02BECBDBB6A91FC08AB69@BYAPR00MB0598.namprd00.prod.outlook.com>

Weijun,

Would you be so kind as to review and sponsor this change for me given that you are familiar with my previous changes [1] (although this issue existed prior)

Once this is in tip, I'll look to backport to 19, 17 and 11

Thanks in advance
Mat

[1] https://bugs.openjdk.org/browse/JDK-8284850

Sent from Outlook

From: security-dev <security-dev-retn at openjdk.org> on behalf of Mat Carter <macarte at openjdk.org>
Sent: Monday, March 6, 2023 1:35 PM
To: security-dev at openjdk.org <security-dev at openjdk.org>
Subject: RFR: 8303607: SunMSCAPI provider leaks memory and keys 
?
[Some people who received this message don't often get email from macarte at openjdk.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
Use the correct API for freeing key handles when directed to by the output of CryptAcquireCertificatePrivateKey [1].
Specifically when [out] pfCallerFreeProvOrNCryptKey is true we test [out] pdwKeySpec for the CERT_NCRYPT_KEY_SPEC flag.? When flag bit is set we now call NCryptFreeObject, otherwise we continue to call CryptReleaseContext (as before)

[1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fapi%2Fwincrypt%2Fnf-wincrypt-cryptacquirecertificateprivatekey&data=05%7C01%7Cmatthew.carter%40microsoft.com%7Ce26c0d2b15e8424b988f08db1e8ac459%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638137353598481138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DkDIdugqfKkENfLVcInWsdaN8mQHZk%2FMEzMo8a%2FofzQ%3D&reserved=0

-------------

Commit messages:
?- Merge branch 'openjdk:master' into ncrypt
?- Fix handle leak

Changes: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.org%2Fjdk%2Fpull%2F12891%2Ffiles&data=05%7C01%7Cmatthew.carter%40microsoft.com%7Ce26c0d2b15e8424b988f08db1e8ac459%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638137353598481138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=arWU6sUJYifADSnvxbxSbBhXixoV%2BfKQmERkfeleFWU%3D&reserved=0
?Webrev: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebrevs.openjdk.org%2F%3Frepo%3Djdk%26pr%3D12891%26range%3D00&data=05%7C01%7Cmatthew.carter%40microsoft.com%7Ce26c0d2b15e8424b988f08db1e8ac459%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638137353598481138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yVDaTyyNAasXuhsjGlKUE%2BybO%2FKYh853N54ONVfYUeE%3D&reserved=0
? Issue: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8303607&data=05%7C01%7Cmatthew.carter%40microsoft.com%7Ce26c0d2b15e8424b988f08db1e8ac459%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638137353598637370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HtZ9QLDhraylQ2H%2FNnuwMahhYI8MoMRP7A5zWGrXRgg%3D&reserved=0
? Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
? Patch: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.org%2Fjdk%2Fpull%2F12891.diff&data=05%7C01%7Cmatthew.carter%40microsoft.com%7Ce26c0d2b15e8424b988f08db1e8ac459%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638137353598637370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RnFSicrj4EDheFgBQ%2Fr7RszE%2FzS30gS2ykxpP%2FaSC10%3D&reserved=0
? Fetch: git fetch https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.org%2Fjdk&data=05%7C01%7Cmatthew.carter%40microsoft.com%7Ce26c0d2b15e8424b988f08db1e8ac459%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638137353598637370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ObH7qip2rYafj%2FLaCXVz9Fq6ZmIzaPLycQe1AcYR%2Bv4%3D&reserved=0 pull/12891/head:pull/12891

PR: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.org%2Fjdk%2Fpull%2F12891&data=05%7C01%7Cmatthew.carter%40microsoft.com%7Ce26c0d2b15e8424b988f08db1e8ac459%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638137353598637370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SQm05Uv%2B8Dde%2FUGdyDV%2FJl4be2vyYVMjuA6c2aLyVXk%3D&reserved=0

From cslucas at openjdk.org  Tue Mar  7 01:51:13 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 7 Mar 2023 01:51:13 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects
 participating in allocation merges
Message-ID: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>

Can I please get reviews for this PR to add support for the rematerialization of scalar-replaced objects that participate in allocation merges?

The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.

With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:

![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)

What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:

![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)

This PR adds support scalar replacing allocations participating in merges that are used *only* as debug information in SafePointNode and its subclasses. Although there is a performance benefit in doing scalar replacement in this scenario only, the goal of this PR is mainly to add infrastructure to support the rematerialization of SR objects participating in merges. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP, Load+AddP, primarily) subsequently.

The approach I used is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in allocation merges used only as debug information.

I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression that might be related. I also tested with several applications and didn't see any failure.

-------------

Commit messages:
 - Add support for rematerializing scalar replaced objects participating in allocation merges

Changes: https://git.openjdk.org/jdk/pull/12897/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287061
  Stats: 1803 lines in 18 files changed: 1653 ins; 9 del; 141 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897


From weijun at openjdk.org  Tue Mar  7 02:00:06 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 7 Mar 2023 02:00:06 GMT
Subject: RFR: 8303607: SunMSCAPI provider leaks memory and keys
In-Reply-To: <Q8wu8EpoRzPn70dQC2QEdvaae0Cqro59SCggunsFaeI=.412420e5-d54f-4cf4-bf7f-0a5eef04053b@github.com>
References: <Q8wu8EpoRzPn70dQC2QEdvaae0Cqro59SCggunsFaeI=.412420e5-d54f-4cf4-bf7f-0a5eef04053b@github.com>
Message-ID: <ndbcuONClYGOHfCRFlxljAtQaGemZtM-hle-uzXLClo=.71dd53fd-c175-4855-9953-2c9c78e9a724@github.com>

On Mon, 6 Mar 2023 21:27:07 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Use the correct API for freeing key handles when directed to by the output of CryptAcquireCertificatePrivateKey [1].
> Specifically when [out] pfCallerFreeProvOrNCryptKey is true we test [out] pdwKeySpec for the CERT_NCRYPT_KEY_SPEC flag.  When flag bit is set we now call NCryptFreeObject, otherwise we continue to call CryptReleaseContext (as before)
> 
> [1] https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptacquirecertificateprivatekey

Looks fine to me. Thanks.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12891


From macarte at openjdk.org  Tue Mar  7 02:15:24 2023
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 7 Mar 2023 02:15:24 GMT
Subject: Integrated: 8303607: SunMSCAPI provider leaks memory and keys
In-Reply-To: <Q8wu8EpoRzPn70dQC2QEdvaae0Cqro59SCggunsFaeI=.412420e5-d54f-4cf4-bf7f-0a5eef04053b@github.com>
References: <Q8wu8EpoRzPn70dQC2QEdvaae0Cqro59SCggunsFaeI=.412420e5-d54f-4cf4-bf7f-0a5eef04053b@github.com>
Message-ID: <0YKxNk3Njr1E47yfsP5XfGATTQakU0ZbA8XePvb7qGQ=.04f2fe67-4c9b-4f05-9542-196c74c3a231@github.com>

On Mon, 6 Mar 2023 21:27:07 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Use the correct API for freeing key handles when directed to by the output of CryptAcquireCertificatePrivateKey [1].
> Specifically when [out] pfCallerFreeProvOrNCryptKey is true we test [out] pdwKeySpec for the CERT_NCRYPT_KEY_SPEC flag.  When flag bit is set we now call NCryptFreeObject, otherwise we continue to call CryptReleaseContext (as before)
> 
> [1] https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptacquirecertificateprivatekey

This pull request has now been integrated.

Changeset: c51d40cf
Author:    Mat Carter <macarte at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c51d40cfebe793b2e979db0f2d91ac3b136311bb
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8303607: SunMSCAPI provider leaks memory and keys

Reviewed-by: weijun

-------------

PR: https://git.openjdk.org/jdk/pull/12891


From ihse at openjdk.org  Tue Mar  7 11:19:08 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Mar 2023 11:19:08 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <jtMAFBGGsxnmsPk8rzwnle3YNCoW9AMBfy69IAW5jT0=.2980eb41-64af-4b4b-8826-86f5a6ea6477@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12826


From mbaesken at openjdk.org  Tue Mar  7 14:39:40 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 7 Mar 2023 14:39:40 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
Message-ID: <vLV4oiv5Sx_3PFGbI-mUZNn0tc3cDeZRtKyEW2eVE44=.7746b72c-9809-4637-9785-c75ca1076033@github.com>

On Thu, 2 Mar 2023 13:33:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After 8278449, we seem to ignore in the call
> 
> `  if (SecTrustSettingsCopyTrustSettings(certRef, kSecTrustSettingsDomainUser, &trustSettings) == errSecItemNotFound) `
> 
> all trusted certs from admin and system domains, so a lot more certs are ignored than necessary.
> Probably we should take at least the certs with trust settings from kSecTrustSettingsDomainUser, kSecTrustSettingsDomainAdmin and kSecTrustSettingsDomainSystem domains .

Hi Weijun,  besides the test issue  you mentioned, is this patch fine with you?

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From prappo at openjdk.org  Tue Mar  7 15:35:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 15:35:51 GMT
Subject: Integrated: 8303480: Miscellaneous fixes to mostly invisible doc
 comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <bX8VasBimwapkC8a4jdbxSSzCrgVWVZmukOp-odUBTs=.afe4dd0d-9ed0-4cd8-8b8d-92285c7d58bc@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

This pull request has now been integrated.

Changeset: 45a616a8
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45a616a891e4a4b0e77b1f2fa040522f4a99d172
Stats:     75 lines in 39 files changed: 0 ins; 0 del; 75 mod

8303480: Miscellaneous fixes to mostly invisible doc comments

Reviewed-by: mullan, prr, cjplummer, aivanov, jjg, lancea, rriggs, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/12826


From mbaesken at openjdk.org  Tue Mar  7 16:04:21 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 7 Mar 2023 16:04:21 GMT
Subject: RFR: JDK-8303576: addIdentitiesToKeystore in KeystoreImpl.m needs
 CFRelease call in early potential CHECK_NULL return
Message-ID: <rrv1lTd68pr4N3P4rskEXxuAez0vhXI7-zXMby8y8ys=.51ef14e9-ba75-4309-8e90-66c3ea382e90@github.com>

Similar to what had been done in [JDK-8303354](https://bugs.openjdk.org/browse/JDK-8303354) , we miss CFRelease on the variable identitySearch in early CHECK_NULL returns potentially done in the function addIdentitiesToKeystore.

-------------

Commit messages:
 - JDK-8303576

Changes: https://git.openjdk.org/jdk/pull/12905/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12905&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303576
  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12905.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12905/head:pull/12905

PR: https://git.openjdk.org/jdk/pull/12905


From weijun at openjdk.org  Tue Mar  7 17:35:08 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 7 Mar 2023 17:35:08 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <vLV4oiv5Sx_3PFGbI-mUZNn0tc3cDeZRtKyEW2eVE44=.7746b72c-9809-4637-9785-c75ca1076033@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
 <vLV4oiv5Sx_3PFGbI-mUZNn0tc3cDeZRtKyEW2eVE44=.7746b72c-9809-4637-9785-c75ca1076033@github.com>
Message-ID: <jHO6Zyz2qap55fzosMaR1nZ4u-_REX_JSzQg1RFyjAI=.5656976f-b483-4fef-8a4a-528ce3b4706c@github.com>

On Tue, 7 Mar 2023 14:36:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Weijun, besides the test issue you mentioned, is this patch fine with you?

I'll think about it more and discuss with my colleagues.

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From jwaters at openjdk.org  Tue Mar  7 17:37:17 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Mar 2023 17:37:17 GMT
Subject: RFR: 8303764: sunmscapi.dll cannot compile under permissive-
Message-ID: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
security.cpp contains a few invalid implicit conversions between pointer types that will not fly when the permissive- compiler option is active. Given that permissive- will become the Visual C++ compiler's default mode of operation in the future, it is better to handle this now so future compiler upgrades will not cause issues. Problems here are very easily solved with explicit casts

-------------

Commit messages:
 - sunmscapi.dll cannot compile under permissive-

Changes: https://git.openjdk.org/jdk/pull/12907/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12907&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303764
  Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12907/head:pull/12907

PR: https://git.openjdk.org/jdk/pull/12907


From John.Gray at entrust.com  Tue Mar  7 17:43:01 2023
From: John.Gray at entrust.com (John Gray)
Date: Tue, 7 Mar 2023 17:43:01 +0000
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <3273EFFC-5430-46F0-80CE-01C6A9E79979@oracle.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
 <3273EFFC-5430-46F0-80CE-01C6A9E79979@oracle.com>
Message-ID: <DM6PR11MB2585023317F3DDD6B8740814EAB79@DM6PR11MB2585.namprd11.prod.outlook.com>

Thanks for this update.

It is possible future KEMs could have variable length shared-secret sizes, so having the ability to be flexible is needed.   Looks like you have covered all possible cases here.

Thanks for these additions!

Cheers,

John Gray
Entrust


-----Original Message-----
From: security-dev <security-dev-retn at openjdk.org> On Behalf Of Wei-Jun Wang
Sent: Friday, March 3, 2023 12:30 PM
To: security-dev at openjdk.java.net
Subject: [EXTERNAL] Re: Update to JEP draft: Key Encapsulation Mechanism API

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Hi All,

The JEP draft was just updated again.

The major change is that there is no more DerivedKeyParameterSpec class. Maybe it's because of the name, but we found many people treating it as a place to configure the KDF used inside a KEM. Actually the only usage of it is to give caller a chance to wrap (possibly a portion of) the shared secret into a SecretKey.

Therefore we drop the class and directly put the fields in the argument list of the encapsulate method, i.e.

  encapsulate(int from, int to, String algorithm);

We also noticed that unlike traditional KEM algorithms (like RSA-KEM and ECIES) that allow a user to choose an arbitrary KDF output length so the generated shared secret can be directly used as a cipher key, modern KEM algorithms have a constant shared secret size, and the output of the KEM is usually passed into a KDF to generate more keys. Therefore we are now providing a shorter method

  encapsulate();

that simply returns a SecretKey containing the full shared secret with algorithm name "Generic".

We hope this shorter method will be mostly used, and the longer one that takes from, to, and algorithm as arguments is only used for the traditional use case where the shared secret is directly used as a cipher key. This longer method might not always be supported by every implementation. For example, in PKCS #11 only a recognized algorithm can be mapped into a valid key type, and the key length must match the key type. In fact, if you want to derive an AES key but the size of the shared secret is bigger than your preferred key size, it's always the leading bytes of the shared secret that are removed. This means you can call encapsulate(secretSize() - 32, secretSize(), "AES") but calling encapsulate(0, 32, "AES") will throw an UnsupportedOperationException.

>
> Please take a look. The updated JEP is still at https://urldefense.com/v3/__https://openjdk.org/jeps/8301034__;!!FJ-Y8qCqXTj2!YplqJhcF4E24TPCPGDdbmukMBaEgm71og8rY95FsDzFlgXyu5XN73M7juERfHm5GY684RCo7E6MqmyS1MJWAsnJu1VhB$ .
>

Thanks,
Max


Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.


From weijun.wang at oracle.com  Tue Mar  7 21:02:28 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Tue, 7 Mar 2023 21:02:28 +0000
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <F8BCF847-C857-304E-86C2-ED81FB97B1D0@hxcore.ol>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
 <3273EFFC-5430-46F0-80CE-01C6A9E79979@oracle.com>
 <F8BCF847-C857-304E-86C2-ED81FB97B1D0@hxcore.ol>
Message-ID: <09864C61-FAF3-4332-A3AA-87D7F1592221@oracle.com>


> On Mar 3, 2023, at 12:37 PM, Bernd <ecki at zusammenkunft.net> wrote:
> 
> Will ?Generic? work with ciphers which need ?raw?, or is that intentionally not the case?

Not sure if I understand. "Raw" is the format type.

"Generic" is similar to the GENERIC in pkcs11, and it is invented for KDF and maybe it can also be used with Hmac. Hmac also happens to be the only consumer of a SecretKey that does not care about the algorithm.

Finally, it's up to the implementation to decide whether they accept a key of an unexpected algorithm name. IIRC, in the builtin provider of OpenJDK, all ciphers requires the algorithm name to be thing they recognize.

Thanks,
Max

> Btw I like the simplification.
> 
> Gruss
> Bernd 
> -- 
> http://bernd.eckenfels.net
>  Von: security-dev <security-dev-retn at openjdk.org> im Auftrag von Wei-Jun Wang <weijun.wang at oracle.com>
> Gesendet: Freitag, M?rz 3, 2023 6:31 PM
> An: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Betreff: Re: Update to JEP draft: Key Encapsulation Mechanism API
>  Hi All, 
> 
> The JEP draft was just updated again. 
> 
> The major change is that there is no more DerivedKeyParameterSpec class Maybe it's because of the name, but we found many people treating it as a place to configure the KDF used inside a KEM. Actually the only usage of it is to give caller a chance to wrap (possibly a portion of) the shared secret into a SecretKey. 
> 
> Therefore we drop the class and directly put the fields in the argument list of the encapsulate method, i.e. 
> 
> encapsulate(int from, int to, String algorithm); 
> 
> We also noticed that unlike traditional KEM algorithms (like RSA-KEM and ECIES) that allow a user to choose an arbitrary KDF output length so the generated shared secret can be directly used as a cipher key, modern KEM algorithms have a constant shared secret size, and the output of the KEM is usually passed into a KDF to generate more keys. Therefore we are now providing a shorter method 
> 
> encapsulate(); 
> 
> that simply returns a SecretKey containing the full shared secret with algorithm name "Generic". 
> 
> We hope this shorter method will be mostly used, and the longer one that takes from, to, and algorithm as arguments is only used for the traditional use case where the shared secret is directly used as a cipher key. This longer method might not always be supported by every implementation. For example, in PKCS #11 only a recognized algorithm can be mapped into a valid key type, and the key length must match the key type. In fact, if you want to derive an AES key but the size of the shared secret is bigger than your preferred key size, it's always the leading bytes of the shared secret that are removed. This means you can call encapsulate(secretSize() - 32, secretSize(), "AES") but calling encapsulate(0, 32, "AES") will throw an UnsupportedOperationException. 
> 
> > 
> > Please take a look. The updated JEP is still at https://openjdk.org/jeps/8301034. 
> > 
> 
> Thanks, 
> Max 
> 
> 


From weijun.wang at oracle.com  Tue Mar  7 21:04:41 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Tue, 7 Mar 2023 21:04:41 +0000
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <DM6PR11MB2585023317F3DDD6B8740814EAB79@DM6PR11MB2585.namprd11.prod.outlook.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
 <3273EFFC-5430-46F0-80CE-01C6A9E79979@oracle.com>
 <DM6PR11MB2585023317F3DDD6B8740814EAB79@DM6PR11MB2585.namprd11.prod.outlook.com>
Message-ID: <8A3A0C1F-79F3-45B7-8F97-B188319B5848@oracle.com>

What does "variable length shared-secret sizes" mean? In the current Java API design, this is not possible, as Ecapsulator.secretSize() returns a finite number. So it must be determined by algorithm name + KEMParamaterSpec + public key.

I don't think I added any flexibility here. If you mean the (algorithm, from, to) method, that's just for Java. In real KEM sense, there is only one define-size shared secret.

Thanks,
Max

> On Mar 7, 2023, at 12:43 PM, John Gray <John.Gray at entrust.com> wrote:
> 
> Thanks for this update.
> 
> It is possible future KEMs could have variable length shared-secret sizes, so having the ability to be flexible is needed.   Looks like you have covered all possible cases here.
> 
> Thanks for these additions!
> 
> Cheers,
> 
> John Gray
> Entrust
> 
> 
> -----Original Message-----
> From: security-dev <security-dev-retn at openjdk.org> On Behalf Of Wei-Jun Wang
> Sent: Friday, March 3, 2023 12:30 PM
> To: security-dev at openjdk.java.net
> Subject: [EXTERNAL] Re: Update to JEP draft: Key Encapsulation Mechanism API
> 
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
> 
> ______________________________________________________________________
> Hi All,
> 
> The JEP draft was just updated again.
> 
> The major change is that there is no more DerivedKeyParameterSpec class. Maybe it's because of the name, but we found many people treating it as a place to configure the KDF used inside a KEM. Actually the only usage of it is to give caller a chance to wrap (possibly a portion of) the shared secret into a SecretKey.
> 
> Therefore we drop the class and directly put the fields in the argument list of the encapsulate method, i.e.
> 
>  encapsulate(int from, int to, String algorithm);
> 
> We also noticed that unlike traditional KEM algorithms (like RSA-KEM and ECIES) that allow a user to choose an arbitrary KDF output length so the generated shared secret can be directly used as a cipher key, modern KEM algorithms have a constant shared secret size, and the output of the KEM is usually passed into a KDF to generate more keys. Therefore we are now providing a shorter method
> 
>  encapsulate();
> 
> that simply returns a SecretKey containing the full shared secret with algorithm name "Generic".
> 
> We hope this shorter method will be mostly used, and the longer one that takes from, to, and algorithm as arguments is only used for the traditional use case where the shared secret is directly used as a cipher key. This longer method might not always be supported by every implementation. For example, in PKCS #11 only a recognized algorithm can be mapped into a valid key type, and the key length must match the key type. In fact, if you want to derive an AES key but the size of the shared secret is bigger than your preferred key size, it's always the leading bytes of the shared secret that are removed. This means you can call encapsulate(secretSize() - 32, secretSize(), "AES") but calling encapsulate(0, 32, "AES") will throw an UnsupportedOperationException.
> 
>> 
>> Please take a look. The updated JEP is still at https://urldefense.com/v3/__https://openjdk.org/jeps/8301034__;!!FJ-Y8qCqXTj2!YplqJhcF4E24TPCPGDdbmukMBaEgm71og8rY95FsDzFlgXyu5XN73M7juERfHm5GY684RCo7E6MqmyS1MJWAsnJu1VhB$ .
>> 
> 
> Thanks,
> Max
> 
> 
> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.




From rhalade at openjdk.org  Tue Mar  7 21:33:35 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 7 Mar 2023 21:33:35 GMT
Subject: RFR: 8282201: Consider removal of expiry check in VerifyCACerts.java
 test
Message-ID: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>

This fix removes the check for 90 days expiry. But the test will continue to fail if the expired certificate is included in `cacerts` but no exception is granted.

Fix also includes minor code cleanup.

-------------

Commit messages:
 - Consider removal of expiry check in VerifyCACerts.java test

Changes: https://git.openjdk.org/jdk/pull/12910/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12910&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282201
  Stats: 52 lines in 1 file changed: 16 ins; 24 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12910.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12910/head:pull/12910

PR: https://git.openjdk.org/jdk/pull/12910


From rhalade at openjdk.org  Tue Mar  7 21:33:35 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 7 Mar 2023 21:33:35 GMT
Subject: RFR: 8282201: Consider removal of expiry check in
 VerifyCACerts.java test
In-Reply-To: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
References: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
Message-ID: <14WHJONrU9TTd5VYI_w0pmpkW3ECljcyKi21yMIe5oU=.51af6842-ce22-45a2-903a-e957f4acf917@github.com>

On Tue, 7 Mar 2023 21:19:37 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix removes the check for 90 days expiry. But the test will continue to fail if the expired certificate is included in `cacerts` but no exception is granted.
> 
> Fix also includes minor code cleanup.

test/jdk/sun/security/lib/cacerts/VerifyCACerts.java line 345:

> 343:                 cert.checkValidity();
> 344:             } catch (CertificateExpiredException cee) {
> 345:                 if (!EXPIRY_EXC_ENTRIES.contains(alias)) {

@seanjmullan 90 days expiry check is removed but test will continue to check expiry exception. This allows extra time to consider removal of root.

-------------

PR: https://git.openjdk.org/jdk/pull/12910


From weijun at openjdk.org  Wed Mar  8 01:09:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 8 Mar 2023 01:09:04 GMT
Subject: RFR: JDK-8303576: addIdentitiesToKeystore in KeystoreImpl.m needs
 CFRelease call in early potential CHECK_NULL return
In-Reply-To: <rrv1lTd68pr4N3P4rskEXxuAez0vhXI7-zXMby8y8ys=.51ef14e9-ba75-4309-8e90-66c3ea382e90@github.com>
References: <rrv1lTd68pr4N3P4rskEXxuAez0vhXI7-zXMby8y8ys=.51ef14e9-ba75-4309-8e90-66c3ea382e90@github.com>
Message-ID: <Wio7xqEa0vEtCKklQ3e9rBzWBrNJCAuLUzHB17r8YvY=.d4dd7045-1c20-4672-a919-3c1c195fe744@github.com>

On Tue, 7 Mar 2023 15:56:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Similar to what had been done in [JDK-8303354](https://bugs.openjdk.org/browse/JDK-8303354) , we miss CFRelease on the variable identitySearch in early CHECK_NULL returns potentially done in the function addIdentitiesToKeystore.

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12905


From xuelei at openjdk.org  Wed Mar  8 03:43:12 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 8 Mar 2023 03:43:12 GMT
Subject: RFR: 8282201: Consider removal of expiry check in
 VerifyCACerts.java test
In-Reply-To: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
References: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
Message-ID: <IJN5NdH6PZo4GOHqdm2ySvO7b9xJAK6LoB4elTzjPpw=.d9eef86f-913a-421e-8944-9162b1492c0c@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Tue, 7 Mar 2023 21:19:37 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix removes the check for 90 days expiry. But the test will continue to fail if the expired certificate is included in `cacerts` but no exception is granted.
> 
> Fix also includes minor code cleanup.

If the check get removed, how could the expired cert get caught in the future?

-------------

PR: https://git.openjdk.org/jdk/pull/12910


From ecki at zusammenkunft.net  Wed Mar  8 03:55:15 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Wed, 8 Mar 2023 04:55:15 +0100
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <09864C61-FAF3-4332-A3AA-87D7F1592221@oracle.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
 <3273EFFC-5430-46F0-80CE-01C6A9E79979@oracle.com>
 <F8BCF847-C857-304E-86C2-ED81FB97B1D0@hxcore.ol>,
 <09864C61-FAF3-4332-A3AA-87D7F1592221@oracle.com>
Message-ID: <88C5F0F7-298F-C346-8E1F-0C6E4BD85BB3@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230308/4d62980f/attachment.htm>

From mbaesken at openjdk.org  Wed Mar  8 07:47:41 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 8 Mar 2023 07:47:41 GMT
Subject: RFR: JDK-8303576: addIdentitiesToKeystore in KeystoreImpl.m needs
 CFRelease call in early potential CHECK_NULL return [v2]
In-Reply-To: <rrv1lTd68pr4N3P4rskEXxuAez0vhXI7-zXMby8y8ys=.51ef14e9-ba75-4309-8e90-66c3ea382e90@github.com>
References: <rrv1lTd68pr4N3P4rskEXxuAez0vhXI7-zXMby8y8ys=.51ef14e9-ba75-4309-8e90-66c3ea382e90@github.com>
Message-ID: <lktGPouMOJ-K2BuhEIa0IkvwK5Ut3SVZZ8HKjBbQZbo=.2f038807-17f2-4334-899e-3e8a0960f348@github.com>

> Similar to what had been done in [JDK-8303354](https://bugs.openjdk.org/browse/JDK-8303354) , we miss CFRelease on the variable identitySearch in early CHECK_NULL returns potentially done in the function addIdentitiesToKeystore.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Remove wrong remaining char in if check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12905/files
  - new: https://git.openjdk.org/jdk/pull/12905/files/8dcf5a2c..0718db2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12905&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12905&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12905.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12905/head:pull/12905

PR: https://git.openjdk.org/jdk/pull/12905


From jwaters at openjdk.org  Wed Mar  8 08:44:24 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Mar 2023 08:44:24 GMT
Subject: RFR: 8303764: sunmscapi.dll cannot compile under permissive-
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <4MPjAixZduIRQlqYY-QHnYlmjNPH6yvonv_nWt0ik4w=.5b03a240-038e-4c4d-bc5b-68912ecbe97f@github.com>

On Tue, 7 Mar 2023 17:27:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> security.cpp contains a few invalid implicit conversions between pointer types that will not fly when the permissive- compiler option is active. Given that permissive- will become the Visual C++ compiler's default mode of operation in the future, it is better to handle this now so future compiler upgrades will not cause issues. Problems here are very easily solved with explicit casts

@wangweij

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From mbaesken at openjdk.org  Wed Mar  8 08:58:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 8 Mar 2023 08:58:07 GMT
Subject: RFR: JDK-8303576: addIdentitiesToKeystore in KeystoreImpl.m needs
 CFRelease call in early potential CHECK_NULL return [v3]
In-Reply-To: <rrv1lTd68pr4N3P4rskEXxuAez0vhXI7-zXMby8y8ys=.51ef14e9-ba75-4309-8e90-66c3ea382e90@github.com>
References: <rrv1lTd68pr4N3P4rskEXxuAez0vhXI7-zXMby8y8ys=.51ef14e9-ba75-4309-8e90-66c3ea382e90@github.com>
Message-ID: <5K0HttBp9VnTBUAbUMJxQSeeCVmWLtc8R4NyzhiUMPo=.68ba453b-52ae-4ca8-b02b-3c91eecc8b05@github.com>

> Similar to what had been done in [JDK-8303354](https://bugs.openjdk.org/browse/JDK-8303354) , we miss CFRelease on the variable identitySearch in early CHECK_NULL returns potentially done in the function addIdentitiesToKeystore.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Fix if check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12905/files
  - new: https://git.openjdk.org/jdk/pull/12905/files/0718db2b..74b69104

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12905&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12905&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12905.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12905/head:pull/12905

PR: https://git.openjdk.org/jdk/pull/12905


From abakhtin at openjdk.org  Wed Mar  8 09:12:59 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 8 Mar 2023 09:12:59 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
Message-ID: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>

This patch fixes a possible native memory leak in case of a custom native GSS provider.
The actual leak was reported in production.

sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

-------------

Commit messages:
 - 8303809: Dispose context in SPNEGO NegotiatorImpl

Changes: https://git.openjdk.org/jdk/pull/12920/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12920&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303809
  Stats: 65 lines in 5 files changed: 65 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12920/head:pull/12920

PR: https://git.openjdk.org/jdk/pull/12920


From weijun at openjdk.org  Wed Mar  8 13:23:13 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 8 Mar 2023 13:23:13 GMT
Subject: RFR: 8303764: sunmscapi.dll cannot compile under permissive-
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <rEKOsOQuz366SzNOE73d344gaVVV1hBtG1IJZgtq5PE=.b4e82aa9-3ff4-45c0-9294-921b9f016431@github.com>

On Tue, 7 Mar 2023 17:27:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> security.cpp contains a few invalid implicit conversions between pointer types that will not fly when the permissive- compiler option is active. Given that permissive- will become the Visual C++ compiler's default mode of operation in the future, it is better to handle this now so future compiler upgrades will not cause issues. Problems here are very easily solved with explicit casts

Thanks for taking care of this. The code change looks innocent. I'm just wondering if this problem only happens in this file or there are similar changes needed in other files. If yes, I hope the change is consistent. For example, instead of casting to `jchar*`, is it possible to declare the variable to be `jchar*` at the beginning? I understand there might be other casts needed.

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From dfuchs at openjdk.org  Wed Mar  8 13:57:22 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 8 Mar 2023 13:57:22 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <iKayfRgvQfP6ArL4OY6pVbiB_zJ0UB-2xoaGGlA6Y_I=.5b889f38-480b-4751-9e30-245032a16d5f@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

@wangweij it would be good if you (or someone from security libs) could review this PR too

src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 525:

> 523:     public void disposeContext() {
> 524:         // do nothing
> 525:     }

It would be good to have some comment explaining the purpose of this method. In particular, it would be good to state when (at which point) it is supposed to be called.
Also hopefully the `AuthenticationInfo` object remain valid and can still be used after `disposeContext` has been called?

src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java line 182:

> 180:                 context.dispose();
> 181:             }
> 182:         }catch (GSSException e) {

Trivially: please add space after `}`

-------------

Changes requested by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12920


From jwaters at openjdk.org  Wed Mar  8 14:09:47 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Mar 2023 14:09:47 GMT
Subject: RFR: 8303764: sunmscapi.dll cannot compile under permissive-
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <IZPZJYEXO10bnaqMsZGF5JS9jWGujIEyMSjmbSEYWBA=.11565b42-381c-4e8a-ad70-56bfb7645d7f@github.com>

On Tue, 7 Mar 2023 17:27:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> security.cpp contains a few invalid implicit conversions between pointer types that will not fly when the permissive- compiler option is active. Given that permissive- will become the Visual C++ compiler's default mode of operation in the future, it is better to handle this now so future compiler upgrades will not cause issues. Problems here are very easily solved with explicit casts

permissive- is a pretty big problem for Windows code in general, in particular our very jint and jlong typedefs themselves on Windows are completely broken on Windows and compiling with permissive- will straight up make the entire JDK explode. Change here is particular is a small part of a much bigger (JDK wide) fix, if that's what you meant by it happening in other files. I'm not sure if the code here could be redefined as a jchar from the start though, should I give it a try?

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From weijun at openjdk.org  Wed Mar  8 14:34:55 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 8 Mar 2023 14:34:55 GMT
Subject: RFR: 8303764: sunmscapi.dll cannot compile under permissive-
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <C9tPX76u61FPXJ5fw5FGnmx5Rpf2WOMflALt8RzZF64=.930062b3-20af-4432-9a31-f05496333183@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Tue, 7 Mar 2023 17:27:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> security.cpp contains a few invalid implicit conversions between pointer types that will not fly when the permissive- compiler option is active. Given that permissive- will become the Visual C++ compiler's default mode of operation in the future, it is better to handle this now so future compiler upgrades will not cause issues. Problems here are very easily solved with explicit casts

I believe `jchar` and `wchar_t` are both 16 bit integers. I just hope we use the same style throughout JDK. If you believe this is a JDK wide issue, how about filing an umbrella bug and make the current bug as part of it? Thus at least the build team will notice it and maybe they will make a plan.

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From djelinski at openjdk.org  Wed Mar  8 14:50:07 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 Mar 2023 14:50:07 GMT
Subject: RFR: 8303764: sunmscapi.dll cannot compile under permissive-
In-Reply-To: <IZPZJYEXO10bnaqMsZGF5JS9jWGujIEyMSjmbSEYWBA=.11565b42-381c-4e8a-ad70-56bfb7645d7f@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <IZPZJYEXO10bnaqMsZGF5JS9jWGujIEyMSjmbSEYWBA=.11565b42-381c-4e8a-ad70-56bfb7645d7f@github.com>
Message-ID: <FJlKMJZZq2W8R_RAEUVaJF9034xJTPuAL_sYuVsrif0=.3f54c174-adbf-442c-94a2-3138fd9321bf@github.com>

On Wed, 8 Mar 2023 14:06:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> security.cpp contains a few invalid implicit conversions between pointer types that will not fly when the permissive- compiler option is active. Given that permissive- will become the Visual C++ compiler's default mode of operation in the future, it is better to handle this now so future compiler upgrades will not cause issues. Problems here are very easily solved with explicit casts
>
> permissive- is a pretty big problem for Windows code in general, in particular our very jint and jlong typedefs themselves on Windows are completely broken on Windows and compiling with permissive- will straight up make the entire JDK explode. Change here is particular is a small part of a much bigger (JDK wide) fix, if that's what you meant by it happening in other files. I'm not sure if the code here could be redefined as a jchar from the start though, should I give it a try?

Hi @TheShermanTanker What complier are you using? What command line?

`security.cpp` compiles just fine with `-permissive-` here, both debug and release. I'm using this compiler:

>cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31629 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

you can find the cmdline under support/native/jdk.crypto.mscapi/libsunmscapi.

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From jwaters at openjdk.org  Wed Mar  8 15:18:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Mar 2023 15:18:13 GMT
Subject: RFR: 8303764: sunmscapi.dll cannot compile under permissive-
In-Reply-To: <FJlKMJZZq2W8R_RAEUVaJF9034xJTPuAL_sYuVsrif0=.3f54c174-adbf-442c-94a2-3138fd9321bf@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <IZPZJYEXO10bnaqMsZGF5JS9jWGujIEyMSjmbSEYWBA=.11565b42-381c-4e8a-ad70-56bfb7645d7f@github.com>
 <FJlKMJZZq2W8R_RAEUVaJF9034xJTPuAL_sYuVsrif0=.3f54c174-adbf-442c-94a2-3138fd9321bf@github.com>
Message-ID: <Iof8D_pUxKmTTRfXD3o9vyEuWLW7KFlJMU2IKyLBdxQ=.5fd6b39f-04cf-4151-b13e-898b218f34f6@github.com>

On Wed, 8 Mar 2023 14:46:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Hi @TheShermanTanker What complier are you using? What command line?
> 
> `security.cpp` compiles just fine with `-permissive-` here, both debug and release. I'm using this compiler:
> 
> ```
> >cl.exe
> Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31629 for x64
> Copyright (C) Microsoft Corporation.  All rights reserved.
> ```
> 
> you can find the cmdline under support/native/jdk.crypto.mscapi/libsunmscapi.

Strange...


C:\Program Files\Microsoft Visual Studio\2022\Community>cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.32.31332 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.


Seems like it's actually a version behind, too

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From djelinski at openjdk.org  Wed Mar  8 15:18:21 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 Mar 2023 15:18:21 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <mHL1nXvw32MUy-3ox_f2801CU_vxlmLeUhLLyU8gV7o=.e0cb4a3f-8937-4102-8969-83b9bb8f7901@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

I'm not familiar with this code and don't know how to execute it, but since you mentioned  native memory leak...

I'm assuming NativeGSSConext is the class that holds a reference to the native memory. The class has a cleaner that is supposed to release the memory. It was recently refactored in JDK-8284490, and I think this refactoring introduced the leak. See:
https://github.com/openjdk/jdk/blob/master/src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java#L374-L377
`cleanable.clean()` calls `stub.deleteContext(pContext)`, but `pContext` is already zero.
Before ffca23a5313855a6f9797ad6b342bb2e2cb1b49b `deleteContext` was called before setting `pContext` to zero.

In general, when fixing native memory leaks, please focus on fixing broken cleaners, rather than manually disposing the memory.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From weijun at openjdk.org  Wed Mar  8 16:45:52 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 8 Mar 2023 16:45:52 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <mHL1nXvw32MUy-3ox_f2801CU_vxlmLeUhLLyU8gV7o=.e0cb4a3f-8937-4102-8969-83b9bb8f7901@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <mHL1nXvw32MUy-3ox_f2801CU_vxlmLeUhLLyU8gV7o=.e0cb4a3f-8937-4102-8969-83b9bb8f7901@github.com>
Message-ID: <lhKi7onBliRZbxqhQeWXr0k_DP9Gvr3wj39H8IOs8M8=.d47512d6-2bb6-4c45-adde-66ec916b055a@github.com>

On Wed, 8 Mar 2023 15:15:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> I'm not familiar with this code and don't know how to execute it, but since you mentioned  native memory leak...
> 
> I'm assuming NativeGSSConext is the class that holds a reference to the native memory. The class has a cleaner that is supposed to release the memory. It was recently refactored in JDK-8284490, and I think this refactoring introduced the leak. See:
> https://github.com/openjdk/jdk/blob/master/src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java#L374-L377
> `cleanable.clean()` calls `stub.deleteContext(pContext)`, but `pContext` is already zero.
> Before ffca23a5313855a6f9797ad6b342bb2e2cb1b49b `deleteContext` was called before setting `pContext` to zero.
> 
> In general, when fixing native memory leaks, please focus on fixing broken cleaners, rather than manually disposing the memory.

@djelinski Not a cleaner or lambda export, when `cleanable.clean()` is called, is it using its own copy of `pContext` and it's not reset to zero?

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From djelinski at openjdk.org  Wed Mar  8 17:19:23 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 Mar 2023 17:19:23 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <lZWfIEklePta6TXAANUcvnVUo_EeRsTjJ0U5-Hzk4dk=.b0b1d3e6-13f1-434c-922e-b28c23e27c49@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

ah, you're right, `cleanable` has its own copy of `pContext`. You can disregard my previous comment.

But then, is there any other place where we could be leaking native memory? As far as I could tell, this patch only releases the memory earlier, it doesn't fix any leaks. Am I missing something?

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From rhalade at openjdk.org  Wed Mar  8 17:39:51 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 8 Mar 2023 17:39:51 GMT
Subject: RFR: 8282201: Consider removal of expiry check in
 VerifyCACerts.java test
In-Reply-To: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
References: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
Message-ID: <fJkhlzcrKO51BKBRQgHH-viR2iT3SvFf83mgMuFlxso=.c005a098-3f61-41bf-bca2-31eb94072aba@github.com>

On Tue, 7 Mar 2023 21:19:37 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix removes the check for 90 days expiry. But the test will continue to fail if the expired certificate is included in `cacerts` but no exception is granted.
> 
> Fix also includes minor code cleanup.

> 

The fix removes the early warning (90 days). Usually this is very early and only fix is to add certificate to expiry exception. Test would still fail when a expired certificate is included but no exception is granted. I have filed tracking bugs for next few years with due date so we don't miss any.

-------------

PR: https://git.openjdk.org/jdk/pull/12910


From xuelei at openjdk.org  Wed Mar  8 17:46:19 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 8 Mar 2023 17:46:19 GMT
Subject: RFR: 8282201: Consider removal of expiry check in
 VerifyCACerts.java test
In-Reply-To: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
References: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
Message-ID: <Lh9L2ZyYVrN3LSSbDW4C_CME8X41ffbObFr9guzmbbM=.5cbf0572-3df7-4a61-ad5f-645fd8c32bbc@github.com>

On Tue, 7 Mar 2023 21:19:37 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix removes the check for 90 days expiry. But the test will continue to fail if the expired certificate is included in `cacerts` but no exception is granted.
> 
> Fix also includes minor code cleanup.

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12910


From aturbanov at openjdk.org  Wed Mar  8 19:19:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 8 Mar 2023 19:19:05 GMT
Subject: RFR: 8303832: Use enhanced-for cycle instead of Enumeration in
 JceKeyStore
Message-ID: <0B0tVUfiurFG1mqtWrh1ZkyFMBah6Or0rx0gJAnwZqo=.3552f5f0-907a-49ed-b90c-14881c4aa905@github.com>

java.util.Enumeration is a legacy interface from java 1.0.
There is couple of places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

-------------

Commit messages:
 - [PATCH] Use enhanced-for cycle instead of Enumeration in JceKeyStore

Changes: https://git.openjdk.org/jdk/pull/12930/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12930&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303832
  Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12930.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12930/head:pull/12930

PR: https://git.openjdk.org/jdk/pull/12930


From weijun at openjdk.org  Wed Mar  8 19:20:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 8 Mar 2023 19:20:12 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <Sop-rZ3oz6lWg1bPXZD7kyrlztNtkOeXm-cFvuscZe8=.98d02d10-bc4e-4514-93e8-a126bca22ff4@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

Maybe it's because it can be added into a cache or stored in `currentServerCredentials`? But then Daniel F asks if it can  remain valid.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From mstjohns at comcast.net  Wed Mar  8 20:15:12 2023
From: mstjohns at comcast.net (Michael StJohns)
Date: Wed, 8 Mar 2023 15:15:12 -0500
Subject: RFR: 8303832: Use enhanced-for cycle instead of Enumeration in
 JceKeyStore
In-Reply-To: <0B0tVUfiurFG1mqtWrh1ZkyFMBah6Or0rx0gJAnwZqo=.3552f5f0-907a-49ed-b90c-14881c4aa905@github.com>
References: <0B0tVUfiurFG1mqtWrh1ZkyFMBah6Or0rx0gJAnwZqo=.3552f5f0-907a-49ed-b90c-14881c4aa905@github.com>
Message-ID: <3dbc54f0-8520-9865-9329-c446bc8f7f2f@comcast.net>

On 3/8/2023 2:19 PM, Andrey Turbanov wrote:
> java.util.Enumeration is a legacy interface from java 1.0.
> There is couple of places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.
>
> -------------
>
> Commit messages:
>   - [PATCH] Use enhanced-for cycle instead of Enumeration in JceKeyStore
>
> Changes: https://git.openjdk.org/jdk/pull/12930/files
>   Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12930&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8303832
>    Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod
>    Patch: https://git.openjdk.org/jdk/pull/12930.diff
>    Fetch: git fetch https://git.openjdk.org/jdk pull/12930/head:pull/12930
>
> PR: https://git.openjdk.org/jdk/pull/12930

Perhaps updating the various Object assignments to be somewhat more 
typed as well would be helpful??? E.g.

private static interface Entry {? Instant getInstant(); } // or maybe 
abstract?? All "Date" objects end up as java.time.Instant

private static final class SecretKeyEntry implements Entry { ... }? // 
and the same for PrivateKeyEntry and SecretKeyEntry


private Hashtable<String, Entry> = new Hashtable<>();

Entry entry = entries.get(alias.toLowerCase(Locale.ENGLISH));

Etc.


Last note - perhaps modify the internal storage of the creation date 
from java.util.Date to a java.time.Instant?

createInstant = Instant.now().truncatedTo(ChronoUnit.SECONDS);

That makes the core of engineGetCreationDate to be something like:

return Date.from (entry.getInstant());? // Instant is immutable, Date is 
not.




From xuelei at openjdk.org  Wed Mar  8 20:30:11 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 8 Mar 2023 20:30:11 GMT
Subject: RFR: 8303832: Use enhanced-for cycle instead of Enumeration in
 JceKeyStore
In-Reply-To: <0B0tVUfiurFG1mqtWrh1ZkyFMBah6Or0rx0gJAnwZqo=.3552f5f0-907a-49ed-b90c-14881c4aa905@github.com>
References: <0B0tVUfiurFG1mqtWrh1ZkyFMBah6Or0rx0gJAnwZqo=.3552f5f0-907a-49ed-b90c-14881c4aa905@github.com>
Message-ID: <ygfpB8XwlN7yOl0B5V6_sfQeKvRTGwf79SyHO4pfcC4=.5139ff83-0f98-4f5f-a10f-6d6c34b5db38@github.com>

On Wed, 8 Mar 2023 19:10:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> java.util.Enumeration is a legacy interface from java 1.0.
> There is couple of places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

I like this idea.  Did you have a chance to check if the enhanced-for cycle has a better performance?

-------------

PR: https://git.openjdk.org/jdk/pull/12930


From mullan at openjdk.org  Wed Mar  8 20:39:16 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 8 Mar 2023 20:39:16 GMT
Subject: RFR: 8282201: Consider removal of expiry check in
 VerifyCACerts.java test
In-Reply-To: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
References: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
Message-ID: <TrjpEB2dmdPjl8r5U6Tp1bSlXo5MWh-hc5YxruKr09Y=.42659085-cfd0-489a-be83-13d80aa102e1@github.com>

On Tue, 7 Mar 2023 21:19:37 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix removes the check for 90 days expiry. But the test will continue to fail if the expired certificate is included in `cacerts` but no exception is granted.
> 
> Fix also includes minor code cleanup.

test/jdk/sun/security/lib/cacerts/VerifyCACerts.java line 299:

> 297: 
> 298:         // also ensure FINGERPRINT_MAP lists correct count
> 299:         if(FINGERPRINT_MAP.size() != COUNT) {

Nit: add space after `if`.

test/jdk/sun/security/lib/cacerts/VerifyCACerts.java line 356:

> 354:                     atLeastOneFailed = true;
> 355:                     System.err.println("ERROR: cert \"" + alias + "\" expiry \""
> 356:                             + notAfter.toString() + "\" will expire within 90 days");

It might be useful to still emit these lines as a "WARNING: ..." but not flag it as a failure.

-------------

PR: https://git.openjdk.org/jdk/pull/12910


From rhalade at openjdk.org  Wed Mar  8 21:03:59 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 8 Mar 2023 21:03:59 GMT
Subject: RFR: 8282201: Consider removal of expiry check in
 VerifyCACerts.java test [v2]
In-Reply-To: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
References: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
Message-ID: <O1hrSmwA2WQapYxnt3hLOWqB1fLudAC8F2D07TygNsI=.cf72b2ed-c81a-46d8-83f2-b34eda9efee4@github.com>

> This fix removes the check for 90 days expiry. But the test will continue to fail if the expired certificate is included in `cacerts` but no exception is granted.
> 
> Fix also includes minor code cleanup.

Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:

  Report 90 days expiry as warning

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12910/files
  - new: https://git.openjdk.org/jdk/pull/12910/files/070b4124..26351330

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12910&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12910&range=00-01

  Stats: 19 lines in 1 file changed: 13 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12910.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12910/head:pull/12910

PR: https://git.openjdk.org/jdk/pull/12910


From mullan at openjdk.org  Wed Mar  8 21:09:16 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 8 Mar 2023 21:09:16 GMT
Subject: RFR: 8282201: Consider removal of expiry check in
 VerifyCACerts.java test [v2]
In-Reply-To: <O1hrSmwA2WQapYxnt3hLOWqB1fLudAC8F2D07TygNsI=.cf72b2ed-c81a-46d8-83f2-b34eda9efee4@github.com>
References: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
 <O1hrSmwA2WQapYxnt3hLOWqB1fLudAC8F2D07TygNsI=.cf72b2ed-c81a-46d8-83f2-b34eda9efee4@github.com>
Message-ID: <JLBGAEl1UMaembEAaL8UzTMLCTgec_Krr5uKzIGBsl8=.cd345e6f-93c3-4acb-887b-5e8d2b83a3fc@github.com>

On Wed, 8 Mar 2023 21:03:59 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> This fix removes the check for 90 days expiry. But the test will continue to fail if the expired certificate is included in `cacerts` but no exception is granted.
>> 
>> Fix also includes minor code cleanup.
>
> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Report 90 days expiry as warning

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12910


From rhalade at openjdk.org  Wed Mar  8 21:13:21 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 8 Mar 2023 21:13:21 GMT
Subject: Integrated: 8282201: Consider removal of expiry check in
 VerifyCACerts.java test
In-Reply-To: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
References: <oA1lFvfHSItPyiq1HHihZZpvSwa1KM1HirjvvXCbFb4=.67cc444a-d22c-4982-b27c-7219e7cdcb2d@github.com>
Message-ID: <nTlX42Jdj8x5WpWG9V6dJ57_Lp-hHQoUrrM1SmiGzx0=.e0f7010e-8767-457a-a8fc-a183ae4ef950@github.com>

On Tue, 7 Mar 2023 21:19:37 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix removes the check for 90 days expiry. But the test will continue to fail if the expired certificate is included in `cacerts` but no exception is granted.
> 
> Fix also includes minor code cleanup.

This pull request has now been integrated.

Changeset: 5b43804b
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b43804b7988ea4abd6458fba0a042b7bd6d9cb8
Stats:     47 lines in 1 file changed: 16 ins; 15 del; 16 mod

8282201: Consider removal of expiry check in VerifyCACerts.java test

Reviewed-by: xuelei, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/12910


From weijun at openjdk.org  Wed Mar  8 22:51:16 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 8 Mar 2023 22:51:16 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <GSgm-Aa8gEDZzYfxtbGlZBImhKSrEpyRUDxDD35CsII=.777d3cba-bd2d-486f-8740-ea5800105bed@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

My 2 cents: I think the change to `HttpURLConnection` and `AuthenticationInfo` is unnecessarily big. If you only care about the releasing of the `GSSContext`, how about add a check inside `NegotiatorImpl` after `initSecContext` is called? Once the `isEstablished` flag returns true the `GSSContext` is no more useful and we can dispose it.

This might not be perfect, for example, if the context is not established yet but for some reason the `nextToken` method is not called. In that case, I hope the cleaner can take care of the cleanup, sooner or later.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From weijun at openjdk.org  Thu Mar  9 00:17:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Mar 2023 00:17:12 GMT
Subject: RFR: 8303832: Use enhanced-for cycle instead of Enumeration in
 JceKeyStore
In-Reply-To: <0B0tVUfiurFG1mqtWrh1ZkyFMBah6Or0rx0gJAnwZqo=.3552f5f0-907a-49ed-b90c-14881c4aa905@github.com>
References: <0B0tVUfiurFG1mqtWrh1ZkyFMBah6Or0rx0gJAnwZqo=.3552f5f0-907a-49ed-b90c-14881c4aa905@github.com>
Message-ID: <aW2pY0nnlPFVIzjlgfmX6Y6cjv6qJWmaygmOMC6wpIc=.c073ca01-2133-4bd5-90e7-2953ab49f731@github.com>

On Wed, 8 Mar 2023 19:10:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> java.util.Enumeration is a legacy interface from java 1.0.
> There is couple of places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

`Enumeration` is legacy because `Hashtable` behind it is legacy. But is it worth modifying `Hashtable` to `ConcurrentHashMap`? IMHO no.

-------------

PR: https://git.openjdk.org/jdk/pull/12930


From duke at openjdk.org  Thu Mar  9 01:16:06 2023
From: duke at openjdk.org (Ismael Juma)
Date: Thu, 9 Mar 2023 01:16:06 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v9]
In-Reply-To: <_gNn18fPzgItmImiBYueA6aPNCaTXtOcJn-jIKhNmhU=.c7c15dde-79aa-49c1-8e5d-94a253381a99@github.com>
References: <NSJSmJ_hDDVg2n0LzVrbmhyfVI_UW-54ncTvhMyIKmE=.2e29f9d3-923b-4ce0-92b7-7efa76eb8104@github.com>
 <_gNn18fPzgItmImiBYueA6aPNCaTXtOcJn-jIKhNmhU=.c7c15dde-79aa-49c1-8e5d-94a253381a99@github.com>
Message-ID: <JJN7oo4nA4u80tsV1KpbCvl23y6mUCvSYrely-wuBNU=.29621d08-fd9e-4604-b654-e5d217c90eb1@github.com>

On Fri, 4 Jun 2021 06:51:35 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - merge, and a few nits
>  - Merge branch 'master' into perfphase1
>  - left 4k test length for trigger
>  - missed resultLen and undo decrypt heap hasarray check
>  - code review comments
>  - fix
>  - Remove GCTR reset() calls because GCTR is released after the operation
>    some variable name consistency
>    other small cleanup
>  - Review comments update
>  - Review comments update
>  - Fix perf problem by reorganizing doLastBlock()
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/b9558655...d84d302b

> It is also a major code redesign limits the amount of data copies and make some performance-based decisions.

Out of curiosity, what kind of perf improvement should one expect as a result of these changes?

-------------

PR: https://git.openjdk.org/jdk/pull/4072


From abakhtin at openjdk.org  Thu Mar  9 08:25:06 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 9 Mar 2023 08:25:06 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <0XXnBTK6MCao0rquWZ58uuy6Qq6RzVGJDAflezzAeKI=.69ba5d21-ebe2-43ae-b3e6-d692451de756@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

@dfunch, @djelinski, @wangweij Thank you a lot for review and suggestions.
The customer uses its own native Kerberos provider. This provider can allocate up to 2 MB of native memory per GSSContext until they are disposed. An application can generate many contexts quickly and they are not cleaned up until GC collects them. It causes high native memory consumption. So, the main idea of the fix is to dispose context as soon as possible.
Unfortunately, in most cases, context is not yet established in the `NegotiatorImpl::init` method after `initSecContext()`. So, we have no right place in the `NegotiatorImpl` to dispose the context after `NegotiatorImpl::init`. This is the reason I have to move the initiation of context dispose into the `HttpURLConnection`.
`sun/security/krb5/auto/HttpNegotiateServer.java` and `sun/security/krb5/auto/HttpsCB.java` tests can be used to verify that `NegotiatorImpl::disposeContext()` is called correctly.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From abakhtin at openjdk.org  Thu Mar  9 08:25:09 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 9 Mar 2023 08:25:09 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <iKayfRgvQfP6ArL4OY6pVbiB_zJ0UB-2xoaGGlA6Y_I=.5b889f38-480b-4751-9e30-245032a16d5f@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <iKayfRgvQfP6ArL4OY6pVbiB_zJ0UB-2xoaGGlA6Y_I=.5b889f38-480b-4751-9e30-245032a16d5f@github.com>
Message-ID: <_KNphC1dSu6M0WDQOJQRcKJVK_Q98gBfv5HZ48oqNPg=.59f821bf-c8df-4518-a457-439747d56090@github.com>

On Wed, 8 Mar 2023 12:24:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java line 182:
> 
>> 180:                 context.dispose();
>> 181:             }
>> 182:         }catch (GSSException e) {
> 
> Trivially: please add space after `}`

Thank you. Sure, I will fix

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From jwaters at openjdk.org  Thu Mar  9 08:33:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 Mar 2023 08:33:11 GMT
Subject: RFR: 8303764: sunmscapi.dll cannot compile under permissive-
In-Reply-To: <FJlKMJZZq2W8R_RAEUVaJF9034xJTPuAL_sYuVsrif0=.3f54c174-adbf-442c-94a2-3138fd9321bf@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <IZPZJYEXO10bnaqMsZGF5JS9jWGujIEyMSjmbSEYWBA=.11565b42-381c-4e8a-ad70-56bfb7645d7f@github.com>
 <FJlKMJZZq2W8R_RAEUVaJF9034xJTPuAL_sYuVsrif0=.3f54c174-adbf-442c-94a2-3138fd9321bf@github.com>
Message-ID: <ytnp8yXRgfLMOZ_RM0NHRhTGZ93tkXx3AmpLQr7kFFU=.3408053a-182d-41ac-8cd2-c7bd217369f4@github.com>

On Wed, 8 Mar 2023 14:46:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> permissive- is a pretty big problem for Windows code in general, in particular our very jint and jlong typedefs themselves on Windows are completely broken on Windows and compiling with permissive- will straight up make the entire JDK explode. Change here is particular is a small part of a much bigger (JDK wide) fix, if that's what you meant by it happening in other files. I'm not sure if the code here could be redefined as a jchar from the start though, should I give it a try?
>
> Hi @TheShermanTanker What complier are you using? What command line?
> 
> `security.cpp` compiles just fine with `-permissive-` here, both debug and release. I'm using this compiler:
> 
>>cl.exe
> Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31629 for x64
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> you can find the cmdline under support/native/jdk.crypto.mscapi/libsunmscapi.

@djelinski After quite some time I think I know what the problem is: My fork is somehow missing the -Zc:wchar_t- flag in the configure script, and it's not because of the permissive- flag as I had initially though. Is there a reason we do this though? Barring this particular file it seems like the rest of the JDK compiles fine with it on my end. Maybe I could change this Pull Request to a build one instead of just a security-libs one in that case?

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From mbaesken at openjdk.org  Thu Mar  9 08:39:21 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 9 Mar 2023 08:39:21 GMT
Subject: Integrated: JDK-8303576: addIdentitiesToKeystore in KeystoreImpl.m
 needs CFRelease call in early potential CHECK_NULL return
In-Reply-To: <rrv1lTd68pr4N3P4rskEXxuAez0vhXI7-zXMby8y8ys=.51ef14e9-ba75-4309-8e90-66c3ea382e90@github.com>
References: <rrv1lTd68pr4N3P4rskEXxuAez0vhXI7-zXMby8y8ys=.51ef14e9-ba75-4309-8e90-66c3ea382e90@github.com>
Message-ID: <411djXOwiPc5l-_gZ7aLYZf__j2SIG3SWQmDY72h2po=.0d277b52-c300-41fd-b993-144b8c905cf0@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Tue, 7 Mar 2023 15:56:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Similar to what had been done in [JDK-8303354](https://bugs.openjdk.org/browse/JDK-8303354) , we miss CFRelease on the variable identitySearch in early CHECK_NULL returns potentially done in the function addIdentitiesToKeystore.

This pull request has now been integrated.

Changeset: a7e308ab
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7e308ab6e5dba7df790840d29fc7edbf3af2e24
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8303576: addIdentitiesToKeystore in KeystoreImpl.m needs CFRelease call in early potential CHECK_NULL return

Reviewed-by: weijun

-------------

PR: https://git.openjdk.org/jdk/pull/12905


From abakhtin at openjdk.org  Thu Mar  9 09:18:07 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 9 Mar 2023 09:18:07 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <iKayfRgvQfP6ArL4OY6pVbiB_zJ0UB-2xoaGGlA6Y_I=.5b889f38-480b-4751-9e30-245032a16d5f@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <iKayfRgvQfP6ArL4OY6pVbiB_zJ0UB-2xoaGGlA6Y_I=.5b889f38-480b-4751-9e30-245032a16d5f@github.com>
Message-ID: <5cKbCDpcKdJjj_3084U0B7Jw4bnk2gN-5w2bdiz2P3I=.e33a39bc-7eea-4bb8-a1c6-8aeab887281e@github.com>

On Wed, 8 Mar 2023 12:29:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 525:
> 
>> 523:     public void disposeContext() {
>> 524:         // do nothing
>> 525:     }
> 
> It would be good to have some comment explaining the purpose of this method. In particular, it would be good to state when (at which point) it is supposed to be called.
> Also hopefully the `AuthenticationInfo` object remain valid and can still be used after `disposeContext` has been called?

Right, `AuthenticationInfo` is still valid after `disposeContext`.
The Negotiator with the new context will be recreated if required https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java#L224

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From djelinski at openjdk.org  Thu Mar  9 09:38:17 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 9 Mar 2023 09:38:17 GMT
Subject: RFR: 8303764: sunmscapi.dll cannot compile under permissive-
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <NiIRF8-3U-mpMyzUyiLRXvMrcdL_A3Mp6AQPKocgIHk=.0e27eac8-fcc8-417a-9de4-7959e2cae072@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Tue, 7 Mar 2023 17:27:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> security.cpp contains a few invalid implicit conversions between pointer types that will not fly when the permissive- compiler option is active. Given that permissive- will become the Visual C++ compiler's default mode of operation in the future, it is better to handle this now so future compiler upgrades will not cause issues. Problems here are very easily solved with explicit casts

When `-Zc:wchar_t-` flag is added, `wchar_t` is equivalent to `jchar`; it's the default in C, which probably explains why this was the only failure. It allows us to avoid many reinterpret_casts, which are the root of all evil.

I guess we could explore changing jchar's typedef to wchar_t on Windows; we can't do that on other systems, because wchar_t is 32 bit there.

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From jwaters at openjdk.org  Thu Mar  9 09:47:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 Mar 2023 09:47:05 GMT
Subject: RFR: 8303764: sunmscapi.dll cannot compile under permissive-
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <srAeZAnLkrb-o87ZkniI3wQtPCHSahFvsYVT58qd_KQ=.27d64ef3-6d98-4117-b9e8-057d9b290737@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Tue, 7 Mar 2023 17:27:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> security.cpp contains a few invalid implicit conversions between pointer types that will not fly when the permissive- compiler option is active. Given that permissive- will become the Visual C++ compiler's default mode of operation in the future, it is better to handle this now so future compiler upgrades will not cause issues. Problems here are very easily solved with explicit casts

Hmm, that sounds like an interesting prospect. char16_t might also be helpful here

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From jwaters at openjdk.org  Thu Mar  9 11:18:04 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 Mar 2023 11:18:04 GMT
Subject: RFR: 8303764: Turn off -Zc:wchar_t- for Visual C++
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <hF8gNFK6tP4XB4JHJzOwd3mUaKZTI3uqc4Kqv2jO2P8=.15cf2fdd-a59d-4a88-a547-43d11673f27b@github.com>

On Tue, 7 Mar 2023 17:27:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> security.cpp contains a few invalid implicit conversions between pointer types that will not fly when the permissive- compiler option is active. Given that permissive- will become the Visual C++ compiler's default mode of operation in the future, it is better to handle this now so future compiler upgrades will not cause issues. Problems here are very easily solved with explicit casts

I'll experiment with switching off -Zc:wchar_t- in this change, will report back on any results

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From jwaters at openjdk.org  Thu Mar  9 11:27:47 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 Mar 2023 11:27:47 GMT
Subject: RFR: 8303764: Turn off -Zc:wchar_t- for Visual C++ [v2]
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <tdJNmtszNcrXniiOQL3D-kJ3wrASR1uuRLPrwIi_LqU=.21c45078-5674-4cb8-80e0-0e60161f204f@github.com>

> security.cpp contains a few invalid implicit conversions between pointer types that will not fly when the permissive- compiler option is active. Given that permissive- will become the Visual C++ compiler's default mode of operation in the future, it is better to handle this now so future compiler upgrades will not cause issues. Problems here are very easily solved with explicit casts

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - -Zc:wchar_t should be enabled
 - Remove explicit wchar_t check in jdk.accessibility

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12907/files
  - new: https://git.openjdk.org/jdk/pull/12907/files/29068054..e33c9c4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12907&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12907&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12907/head:pull/12907

PR: https://git.openjdk.org/jdk/pull/12907


From jwaters at openjdk.org  Thu Mar  9 11:35:22 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 Mar 2023 11:35:22 GMT
Subject: RFR: 8303764: Turn off -Zc:wchar_t- for Visual C++ [v3]
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <aWSjEtMcgCOBoQm-UMnuVUQyfvKXiQ1rDWn5Pw9g6oI=.57cd36b2-63f0-42d2-82d4-800d971e413c@github.com>

> Was: sunmscapi.dll cannot compile with Visual C++
> 
> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a distinct C++ type when compiling with Visual C++ so jchar and wchar_t are typedef'd to shorts on Windows. After some examination it appears this flag is not actually needed for almost every source file that we have, barring security.cpp, so we could try to remove it and make Windows code behave more like regular C++, since casting between wchar_t and jchar does not appear to happen very often (only appearing in one file!). wchar_t in Standard C is a typedef and is never affected by this flag, and if `-Zc:wchar_t` is enabled for C code, it is simply ignored

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-7
 - -Zc:wchar_t should be enabled
 - Remove explicit wchar_t check in jdk.accessibility
 - sunmscapi.dll cannot compile under permissive-

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12907/files
  - new: https://git.openjdk.org/jdk/pull/12907/files/e33c9c4d..f5d46e87

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12907&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12907&range=01-02

  Stats: 3501 lines in 137 files changed: 2496 ins; 563 del; 442 mod
  Patch: https://git.openjdk.org/jdk/pull/12907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12907/head:pull/12907

PR: https://git.openjdk.org/jdk/pull/12907


From djelinski at openjdk.org  Thu Mar  9 12:04:18 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 9 Mar 2023 12:04:18 GMT
Subject: RFR: 8303764: Turn off -Zc:wchar_t- for Visual C++ [v3]
In-Reply-To: <aWSjEtMcgCOBoQm-UMnuVUQyfvKXiQ1rDWn5Pw9g6oI=.57cd36b2-63f0-42d2-82d4-800d971e413c@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <aWSjEtMcgCOBoQm-UMnuVUQyfvKXiQ1rDWn5Pw9g6oI=.57cd36b2-63f0-42d2-82d4-800d971e413c@github.com>
Message-ID: <fyGN3KAEmKAxsYvuYhV62wuGGWnSdUk0hXMLU0Ji2HQ=.664f49ef-9245-4c39-92c2-9866f9955031@github.com>

On Thu, 9 Mar 2023 11:35:22 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Was: sunmscapi.dll cannot compile with Visual C++
>> 
>> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a distinct C++ type when compiling with Visual C++ so jchar and wchar_t are typedef'd to shorts on Windows. After some examination it appears this flag is not actually needed for almost every source file that we have, barring security.cpp, so we could try to remove it and make Windows code behave more like regular C++, since casting between wchar_t and jchar does not appear to happen very often (only appearing in one file!). wchar_t in Standard C is a typedef and is never affected by this flag, and if `-Zc:wchar_t` is enabled for C code, it is simply ignored
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-7
>  - -Zc:wchar_t should be enabled
>  - Remove explicit wchar_t check in jdk.accessibility
>  - sunmscapi.dll cannot compile under permissive-

src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 544:

> 542:                 {
> 543:                     if ((dwKeySpec & CERT_NCRYPT_KEY_SPEC) == CERT_NCRYPT_KEY_SPEC) {
> 544:                         PP("CNG %lld", (long long) hCryptProv);

What error were you seeing here before your changes?

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From jwaters at openjdk.org  Thu Mar  9 12:07:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 Mar 2023 12:07:18 GMT
Subject: RFR: 8303764: Turn off -Zc:wchar_t- for Visual C++ [v3]
In-Reply-To: <fyGN3KAEmKAxsYvuYhV62wuGGWnSdUk0hXMLU0Ji2HQ=.664f49ef-9245-4c39-92c2-9866f9955031@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <aWSjEtMcgCOBoQm-UMnuVUQyfvKXiQ1rDWn5Pw9g6oI=.57cd36b2-63f0-42d2-82d4-800d971e413c@github.com>
 <fyGN3KAEmKAxsYvuYhV62wuGGWnSdUk0hXMLU0Ji2HQ=.664f49ef-9245-4c39-92c2-9866f9955031@github.com>
Message-ID: <251dbbBTrMjEv8wUsqPljJ1SipRglNb7CLYWkDHPCnY=.0449fa83-d704-411f-85cb-6ee13ed84cf8@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Thu, 9 Mar 2023 12:00:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into patch-7
>>  - -Zc:wchar_t should be enabled
>>  - Remove explicit wchar_t check in jdk.accessibility
>>  - sunmscapi.dll cannot compile under permissive-
>
> src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 544:
> 
>> 542:                 {
>> 543:                     if ((dwKeySpec & CERT_NCRYPT_KEY_SPEC) == CERT_NCRYPT_KEY_SPEC) {
>> 544:                         PP("CNG %lld", (long long) hCryptProv);
> 
> What error were you seeing here before your changes?

Oh, that one wasn't really an error, but given that Microsoft has changed their definitions of a 64 bit int to a long long and the I64 specifier to ll in the ucrt for quite some time now, I figured that this was some extra cleanup I could fit in here. Not strictly required, but convenient code cleanliness for good measure nonetheless

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From djelinski at openjdk.org  Thu Mar  9 12:32:09 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 9 Mar 2023 12:32:09 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <0XXnBTK6MCao0rquWZ58uuy6Qq6RzVGJDAflezzAeKI=.69ba5d21-ebe2-43ae-b3e6-d692451de756@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <0XXnBTK6MCao0rquWZ58uuy6Qq6RzVGJDAflezzAeKI=.69ba5d21-ebe2-43ae-b3e6-d692451de756@github.com>
Message-ID: <nUQtVnbc0jDI-Q0zriAPF0aYZKdsJfIJ9hOaEL57K4A=.61487fe6-5d4a-4b1f-877d-a47a72445b2e@github.com>

On Thu, 9 Mar 2023 08:21:15 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> @dfunch, @djelinski, @wangweij Thank you a lot for review and suggestions.
> The customer uses its own native Kerberos provider. This provider can allocate up to 2 MB of native memory per GSSContext until they are disposed. An application can generate many contexts quickly and they are not cleaned up until GC collects them. It causes high native memory consumption. So, the main idea of the fix is to dispose context as soon as possible.
> Unfortunately, in most cases, context is not yet established in the `NegotiatorImpl::init` method after `initSecContext()`. So, we have no right place in the `NegotiatorImpl` to dispose the context after `NegotiatorImpl::init`. This is the reason I have to move the initiation of context dispose into the `HttpURLConnection`.
> `sun/security/krb5/auto/HttpNegotiateServer.java` and `sun/security/krb5/auto/HttpsCB.java` tests can be used to verify that `NegotiatorImpl::disposeContext()` is called correctly.

@alexeybakhtin thanks for adding more context. I believe @wangweij was suggesting adding `context.dispose()` after `initSecContext` in `NegotiatorImpl::nextToken`, which indeed looks like the right thing to do.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From weijun at openjdk.org  Thu Mar  9 14:12:42 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Mar 2023 14:12:42 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <RH3nt5JA35ucPDCSRm_JLDpAq95qZcZKsjVvLSyTqMM=.2f88b5cb-0a28-40a7-b053-6ee04071f22d@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

If context is not established after first call to `initSecContext`, will `nextToken` always be called? In case it's not called, which code change guarantees the context is disposed?

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From weijun at openjdk.org  Thu Mar  9 14:12:49 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Mar 2023 14:12:49 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <0XXnBTK6MCao0rquWZ58uuy6Qq6RzVGJDAflezzAeKI=.69ba5d21-ebe2-43ae-b3e6-d692451de756@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <0XXnBTK6MCao0rquWZ58uuy6Qq6RzVGJDAflezzAeKI=.69ba5d21-ebe2-43ae-b3e6-d692451de756@github.com>
Message-ID: <0dZP0oWXVQVTTuHWezFO4BEa96R-ZQomB80Zldm8mTs=.44ebf0d5-35b9-4241-8b66-8bf40f76ec2e@github.com>

On Thu, 9 Mar 2023 08:21:15 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> @dfunch, @djelinski, @wangweij Thank you a lot for review and suggestions.
> The customer uses its own native Kerberos provider. This provider can allocate up to 2 MB of native memory per GSSContext until they are disposed. An application can generate many contexts quickly and they are not cleaned up until GC collects them. It causes high native memory consumption. So, the main idea of the fix is to dispose context as soon as possible.
> Unfortunately, in most cases, context is not yet established in the `NegotiatorImpl::init` method after `initSecContext()`. So, we have no right place in the `NegotiatorImpl` to dispose the context after `NegotiatorImpl::init`. This is the reason I have to move the initiation of context dispose into the `HttpURLConnection`.
> `sun/security/krb5/auto/HttpNegotiateServer.java` and `sun/security/krb5/auto/HttpsCB.java` tests can be used to verify that `NegotiatorImpl::disposeContext()` is called correctly.

> @alexeybakhtin thanks for adding more context. I believe @wangweij was suggesting adding `context.dispose()` after `initSecContext` in `NegotiatorImpl::nextToken`, which indeed looks like the right thing to do.

Yes, after both `initSecContext` calls. In either case it's possible the context has already been established.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From jwaters at openjdk.org  Thu Mar  9 14:18:58 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 Mar 2023 14:18:58 GMT
Subject: RFR: 8303764: Turn off -Zc:wchar_t- for Visual C++ [v4]
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <vJtxll90L1mc2YmemLzKms7UW1qZbOmFM0Rou0IBKMc=.1eb5b895-cd9d-4742-96b4-f457b98f0d11@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
> Was: sunmscapi.dll cannot compile with Visual C++
> 
> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a distinct C++ type when compiling with Visual C++ so jchar and wchar_t are typedef'd to shorts on Windows. After some examination it appears this flag is not actually needed for almost every source file that we have, barring security.cpp, so we could try to remove it and make Windows code behave more like regular C++, since casting between wchar_t and jchar does not appear to happen very often (only appearing in one file!). wchar_t in Standard C is a typedef and is never affected by this flag, and if `-Zc:wchar_t` is enabled for C code, it is simply ignored

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  awt_Component.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12907/files
  - new: https://git.openjdk.org/jdk/pull/12907/files/f5d46e87..2c3f65cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12907&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12907&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12907/head:pull/12907

PR: https://git.openjdk.org/jdk/pull/12907


From abakhtin at openjdk.org  Thu Mar  9 16:06:03 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 9 Mar 2023 16:06:03 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <MYcKqDuRMbLbYrG2u3i68olsiy3qOzyzrYqA1c_bt84=.28b9efa0-82cb-454d-bc24-020364c6e771@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

Unfortunately, there is no guarantee `NegotiatorImpl::nextToken` will be called. 
At least in both `sun/security/krb5/auto/HttpNegotiateServer.java` and `sun/security/krb5/auto/HttpsCB.java` tests context is not established after the first `initSecContext` and `NegotiatorImpl::nextToken` is not called at all.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From mullan at openjdk.org  Thu Mar  9 16:19:27 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 9 Mar 2023 16:19:27 GMT
Subject: RFR: 8303832: Use enhanced-for cycle instead of Enumeration in
 JceKeyStore
In-Reply-To: <aW2pY0nnlPFVIzjlgfmX6Y6cjv6qJWmaygmOMC6wpIc=.c073ca01-2133-4bd5-90e7-2953ab49f731@github.com>
References: <0B0tVUfiurFG1mqtWrh1ZkyFMBah6Or0rx0gJAnwZqo=.3552f5f0-907a-49ed-b90c-14881c4aa905@github.com>
 <aW2pY0nnlPFVIzjlgfmX6Y6cjv6qJWmaygmOMC6wpIc=.c073ca01-2133-4bd5-90e7-2953ab49f731@github.com>
Message-ID: <ewCNqmUzzs2RMsBMO8ojTf1fwto5Mhhab_ufmh0F2D8=.c7a8d5e4-d420-44d7-9324-7a2df68f2be7@github.com>

On Thu, 9 Mar 2023 00:14:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> java.util.Enumeration is a legacy interface from java 1.0.
>> There is couple of places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.
>
> `Enumeration` is legacy because `Hashtable` behind it is legacy. But is it worth modifying `Hashtable` to `ConcurrentHashMap`? IMHO no.

To add to @wangweij comment, I'll point out that "JCEKS" is a legacy keystore type that is no longer recommended [1]. At this point, putting any additional work into this code (other than fixing bugs) is probably not worth it. I suggest closing this issue as "Won't Fix".

[1] https://bugs.openjdk.org/browse/JDK-8182879

-------------

PR: https://git.openjdk.org/jdk/pull/12930


From weijun at openjdk.org  Thu Mar  9 16:45:11 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Mar 2023 16:45:11 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v2]
In-Reply-To: <xlIiD1MHJ3DAlxyo0HJW8emn4IAE36KEZTJG75flL7c=.b90f4803-c0db-4c86-8618-90f8435f6e95@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <xlIiD1MHJ3DAlxyo0HJW8emn4IAE36KEZTJG75flL7c=.b90f4803-c0db-4c86-8618-90f8435f6e95@github.com>
Message-ID: <UxWYSuc1J66oceOauJp5Bl41wHi6SGf1LYt0Q8mhGdw=.45302049-24da-47cd-853e-c53cb18a490f@github.com>

On Mon, 6 Mar 2023 19:02:02 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
>> 
>> This PR suggests it's time to remove this code:
>> 
>> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
>> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
>> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
>> - Mentions of the options in Resource files in the same directory is removed
>> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
>> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to generated file jarsigner.1

`src/jdk.jartool/share/classes/module-info.java` and `test/jdk/TEST.groups` still reference `com.sun.jarsigner`.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Thu Mar  9 17:24:39 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Mar 2023 17:24:39 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v3]
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <48gm0uVBpWFzIxOU_-rEd_R5wBLHncO8TmV8tsrH70g=.83c86d97-6e98-41be-8739-fd7e23607cb1@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Remove references to com.sun.jarsigner from module-info.java and TEST.groups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12791/files
  - new: https://git.openjdk.org/jdk/pull/12791/files/fdbcf021..9051a550

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12791&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12791&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12791.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12791/head:pull/12791

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Thu Mar  9 17:24:42 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Mar 2023 17:24:42 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v2]
In-Reply-To: <UxWYSuc1J66oceOauJp5Bl41wHi6SGf1LYt0Q8mhGdw=.45302049-24da-47cd-853e-c53cb18a490f@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <xlIiD1MHJ3DAlxyo0HJW8emn4IAE36KEZTJG75flL7c=.b90f4803-c0db-4c86-8618-90f8435f6e95@github.com>
 <UxWYSuc1J66oceOauJp5Bl41wHi6SGf1LYt0Q8mhGdw=.45302049-24da-47cd-853e-c53cb18a490f@github.com>
Message-ID: <ZgdG-DIEc-CHjMC9-AOA-ZcklY2dwrvM81PjFG1maP0=.b6cdf440-e640-4681-a366-010e90300d6a@github.com>

On Thu, 9 Mar 2023 16:41:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `src/jdk.jartool/share/classes/module-info.java` and `test/jdk/TEST.groups` still reference `com.sun.jarsigner`.

Well spotted, I have removed these references.

I'm assuming the references in the jdk.compiler symbol tables will be updated through some form of automation.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From weijun at openjdk.org  Thu Mar  9 18:17:46 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Mar 2023 18:17:46 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v3]
In-Reply-To: <48gm0uVBpWFzIxOU_-rEd_R5wBLHncO8TmV8tsrH70g=.83c86d97-6e98-41be-8739-fd7e23607cb1@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <48gm0uVBpWFzIxOU_-rEd_R5wBLHncO8TmV8tsrH70g=.83c86d97-6e98-41be-8739-fd7e23607cb1@github.com>
Message-ID: <kx5fQ-ntIV_iT48IY_7rqT8GIyfai-pwgSab5apA0UI=.ed17601f-27a6-4b6a-b1d1-a86ee2bda866@github.com>

On Thu, 9 Mar 2023 17:24:39 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
>> 
>> This PR suggests it's time to remove this code:
>> 
>> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
>> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
>> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
>> - Mentions of the options in Resource files in the same directory is removed
>> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
>> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove references to com.sun.jarsigner from module-info.java and TEST.groups

I think those are for previous versions of JDKs, most likely used by `javac --source --release`.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From weijun at openjdk.org  Thu Mar  9 18:26:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Mar 2023 18:26:04 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v3]
In-Reply-To: <48gm0uVBpWFzIxOU_-rEd_R5wBLHncO8TmV8tsrH70g=.83c86d97-6e98-41be-8739-fd7e23607cb1@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <48gm0uVBpWFzIxOU_-rEd_R5wBLHncO8TmV8tsrH70g=.83c86d97-6e98-41be-8739-fd7e23607cb1@github.com>
Message-ID: <28kx6ruOeJvBzUB2jf-Co9VLveQs8bkpx50e0vjoGJY=.db8c98a2-d777-45f9-9167-c06b8a0e12d0@github.com>

On Thu, 9 Mar 2023 17:24:39 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
>> 
>> This PR suggests it's time to remove this code:
>> 
>> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
>> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
>> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
>> - Mentions of the options in Resource files in the same directory is removed
>> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
>> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove references to com.sun.jarsigner from module-info.java and TEST.groups

Oops, find two unused resource strings: `This.option.is.forremoval` and `using.an.alternative.signing.mechanism`. There is a test comparing the resources files and the usages.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Thu Mar  9 18:50:42 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Mar 2023 18:50:42 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v4]
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <3IU0BdgYuJZE0HHZcGAAXywcO27QeOtPU2YUPZMRbJ4=.55603a62-b10d-4a16-baa1-3e9050251c0e@github.com>

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused resource names 'This.option.is.forremoval' and 'using.an.alternative.signing.mechanism'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12791/files
  - new: https://git.openjdk.org/jdk/pull/12791/files/9051a550..9c1a0cad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12791&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12791&range=02-03

  Stats: 12 lines in 4 files changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12791.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12791/head:pull/12791

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Thu Mar  9 18:50:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Mar 2023 18:50:45 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v3]
In-Reply-To: <48gm0uVBpWFzIxOU_-rEd_R5wBLHncO8TmV8tsrH70g=.83c86d97-6e98-41be-8739-fd7e23607cb1@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <48gm0uVBpWFzIxOU_-rEd_R5wBLHncO8TmV8tsrH70g=.83c86d97-6e98-41be-8739-fd7e23607cb1@github.com>
Message-ID: <swPRrFhs_JPoaWfw2o_PaA4sYE9oXALQUXZePxxCh6s=.8e114bf5-d9a6-402f-bb38-67259cbbf3ee@github.com>

On Thu, 9 Mar 2023 17:24:39 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
>> 
>> This PR suggests it's time to remove this code:
>> 
>> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
>> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
>> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
>> - Mentions of the options in Resource files in the same directory is removed
>> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
>> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove references to com.sun.jarsigner from module-info.java and TEST.groups

Oops, I have removed those now!

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From weijun at openjdk.org  Thu Mar  9 19:32:42 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Mar 2023 19:32:42 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v4]
In-Reply-To: <3IU0BdgYuJZE0HHZcGAAXywcO27QeOtPU2YUPZMRbJ4=.55603a62-b10d-4a16-baa1-3e9050251c0e@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <3IU0BdgYuJZE0HHZcGAAXywcO27QeOtPU2YUPZMRbJ4=.55603a62-b10d-4a16-baa1-3e9050251c0e@github.com>
Message-ID: <U23ACpsACQBX2vq3ADjkwi8dnLaDxFgg6SCYKbAgTB8=.06705394-c4fe-47ea-9e56-f1bf52bb1d7e@github.com>

On Thu, 9 Mar 2023 18:50:42 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
>> 
>> This PR suggests it's time to remove this code:
>> 
>> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
>> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
>> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
>> - Mentions of the options in Resource files in the same directory is removed
>> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
>> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused resource names 'This.option.is.forremoval' and 'using.an.alternative.signing.mechanism'

No more comment. Approved. Thanks!

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12791


From weijun at openjdk.org  Thu Mar  9 20:13:09 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Mar 2023 20:13:09 GMT
Subject: RFR: 8296400: pointCrlIssuers might be null in
 DistributionPointFetcher::verifyURL
In-Reply-To: <gimiHYgrjuGMnIXl0qXJ8rDjAtbrG5W5ZYqRFPyhtPQ=.87f41307-bcd1-49ac-82ab-a6f6be401692@github.com>
References: <gimiHYgrjuGMnIXl0qXJ8rDjAtbrG5W5ZYqRFPyhtPQ=.87f41307-bcd1-49ac-82ab-a6f6be401692@github.com>
Message-ID: <KwCPcQ8fd5xOvIVnP6rzmjnSXJAklDWXbuQokQ7TAWA=.d0495a67-94ef-4b0f-a833-2437adceded2@github.com>

On Fri, 3 Mar 2023 19:45:22 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added null-checks for pointCrlIssuers before it is accessed.

src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java line 485:

> 483:                     // cannot all be missing from a certificate.
> 484:                     for (Iterator<GeneralName> t = pointCrlIssuers.iterator();
> 485:                          !match && t.hasNext(); ) {

Please keep the 8-char indentation for a wrapped line. Same below.

-------------

PR: https://git.openjdk.org/jdk/pull/12866


From duke at openjdk.org  Thu Mar  9 20:30:29 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Mar 2023 20:30:29 GMT
Subject: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner
 and -altsignerpath options [v4]
In-Reply-To: <3IU0BdgYuJZE0HHZcGAAXywcO27QeOtPU2YUPZMRbJ4=.55603a62-b10d-4a16-baa1-3e9050251c0e@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
 <3IU0BdgYuJZE0HHZcGAAXywcO27QeOtPU2YUPZMRbJ4=.55603a62-b10d-4a16-baa1-3e9050251c0e@github.com>
Message-ID: <WeG7FkeCf5xtKA8ktTLSUXuexSEdIUo-1xoHR9GemD0=.cda56648-d143-48f2-a719-43501b1f6925@github.com>

On Thu, 9 Mar 2023 18:50:42 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
>> 
>> This PR suggests it's time to remove this code:
>> 
>> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
>> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
>> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
>> - Mentions of the options in Resource files in the same directory is removed
>> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
>> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused resource names 'This.option.is.forremoval' and 'using.an.alternative.signing.mechanism'

Thanks for reviewing Weijun!

I'll let this simmer for a bit before integrating just in case someone else would want to have a look.

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From duke at openjdk.org  Thu Mar  9 20:53:44 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Thu, 9 Mar 2023 20:53:44 GMT
Subject: RFR: 8296400: pointCrlIssuers might be null in
 DistributionPointFetcher::verifyURL [v2]
In-Reply-To: <gimiHYgrjuGMnIXl0qXJ8rDjAtbrG5W5ZYqRFPyhtPQ=.87f41307-bcd1-49ac-82ab-a6f6be401692@github.com>
References: <gimiHYgrjuGMnIXl0qXJ8rDjAtbrG5W5ZYqRFPyhtPQ=.87f41307-bcd1-49ac-82ab-a6f6be401692@github.com>
Message-ID: <HlJa2LB9NzKDUEYsKl9PMuYEbo_W_Q3p9qSYUve1oWA=.598b1cde-6d41-46db-a3eb-02768c32cb73@github.com>

> Added null-checks for pointCrlIssuers before it is accessed.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  fixed indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12866/files
  - new: https://git.openjdk.org/jdk/pull/12866/files/e2d395dd..8f77f05f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12866&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12866&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12866.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12866/head:pull/12866

PR: https://git.openjdk.org/jdk/pull/12866


From weijun at openjdk.org  Thu Mar  9 21:05:55 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Mar 2023 21:05:55 GMT
Subject: RFR: 8296400: pointCrlIssuers might be null in
 DistributionPointFetcher::verifyURL [v2]
In-Reply-To: <HlJa2LB9NzKDUEYsKl9PMuYEbo_W_Q3p9qSYUve1oWA=.598b1cde-6d41-46db-a3eb-02768c32cb73@github.com>
References: <gimiHYgrjuGMnIXl0qXJ8rDjAtbrG5W5ZYqRFPyhtPQ=.87f41307-bcd1-49ac-82ab-a6f6be401692@github.com>
 <HlJa2LB9NzKDUEYsKl9PMuYEbo_W_Q3p9qSYUve1oWA=.598b1cde-6d41-46db-a3eb-02768c32cb73@github.com>
Message-ID: <aQDdgJjJQSzLqwbiQEUcNXQ4NROwATbvwww4RjeLLB8=.dd07e92f-b51f-4c2b-86f0-2ed159ffe250@github.com>

On Thu, 9 Mar 2023 20:53:44 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Added null-checks for pointCrlIssuers before it is accessed.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed indentation

Looks good. You might need to add a `noreg-` label to the JBS issue.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12866


From valeriep at openjdk.org  Fri Mar 10 00:29:16 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 10 Mar 2023 00:29:16 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <hrOv6KCpuxmj8elN6U67d-wBF-ogqcaO13uwIj-KJkw=.a64470ee-d871-424c-b17f-11ac5ced742d@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/java.base/share/classes/sun/security/util/PBEUtil.java line 59:

> 57:         }
> 58: 
> 59:         public AlgorithmParameters getAlgorithmParameters(int blkSize,

I see most if not all of the methods in this class are lifted from other classes as the result of code refactoring. Would be nice to document its callers, e.g. where it's used.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From duke at openjdk.org  Fri Mar 10 14:14:29 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 10 Mar 2023 14:14:29 GMT
Subject: Integrated: 8296400: pointCrlIssuers might be null in
 DistributionPointFetcher::verifyURL
In-Reply-To: <gimiHYgrjuGMnIXl0qXJ8rDjAtbrG5W5ZYqRFPyhtPQ=.87f41307-bcd1-49ac-82ab-a6f6be401692@github.com>
References: <gimiHYgrjuGMnIXl0qXJ8rDjAtbrG5W5ZYqRFPyhtPQ=.87f41307-bcd1-49ac-82ab-a6f6be401692@github.com>
Message-ID: <n5YyyHHxUhbN5961DWijXnNhj6I2QqqSTZ2Nb2puPHM=.04952e4c-56d3-4fbd-a56a-1349900e730a@github.com>

On Fri, 3 Mar 2023 19:45:22 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Added null-checks for pointCrlIssuers before it is accessed.

This pull request has now been integrated.

Changeset: de9f3b6a
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de9f3b6aac85edb39af67db887af78906e8d5da0
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8296400: pointCrlIssuers might be null in DistributionPointFetcher::verifyURL

Reviewed-by: weijun

-------------

PR: https://git.openjdk.org/jdk/pull/12866


From weijun at openjdk.org  Fri Mar 10 15:05:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 10 Mar 2023 15:05:12 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <tL5QOmDEf8lDubUzcBLuH9oyEO4tVKLRfpI32YUKJew=.cc00a3fc-f75f-4a28-a4b5-2b9ab9f55938@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

Yes, you are right. I believe the reason is that once an 200 OK is received, no one cares to look at the token anymore.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From weijun at openjdk.org  Fri Mar 10 15:09:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 10 Mar 2023 15:09:21 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <gwkg7jEuOSbIHLRQk4EjVFwv5fERBq9oHk5aqBwmLVQ=.00d0613f-3deb-4516-84a4-9d46c5a95393@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java line 254:

> 252:             try {
> 253:                 negotiator.disposeContext();
> 254:             }catch(IOException ioEx) {

Please add a space before `catch`.

src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java line 134:

> 132:             } catch(Exception ex) {
> 133:                 //dispose context silently
> 134:             }

Why is this cleanup necessary here but not in `nextToken()`? If we don't do any cleanup here, will `disposeContext()` be called inside `HttpURLConnection`?

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From abakhtin at openjdk.org  Fri Mar 10 16:14:15 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 10 Mar 2023 16:14:15 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <gwkg7jEuOSbIHLRQk4EjVFwv5fERBq9oHk5aqBwmLVQ=.00d0613f-3deb-4516-84a4-9d46c5a95393@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <gwkg7jEuOSbIHLRQk4EjVFwv5fERBq9oHk5aqBwmLVQ=.00d0613f-3deb-4516-84a4-9d46c5a95393@github.com>
Message-ID: <_W4ZBOEWTDGwO_cMwf1qARHDPR3FCdyzN2lqii-iYsw=.77735366-d5ad-4cbb-9d2d-ada10e07b3d1@github.com>

On Fri, 10 Mar 2023 15:05:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java line 134:
> 
>> 132:             } catch(Exception ex) {
>> 133:                 //dispose context silently
>> 134:             }
> 
> Why is this cleanup necessary here but not in `nextToken()`? If we don't do any cleanup here, will `disposeContext()` be called inside `HttpURLConnection`?

GSSContext could be allocated in init() line 97 but fails with Exception in context.initSecContext(). In this case null Negotiator is returned https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/net/www/protocol/http/Negotiator.java#L71 to NegotiatorAuthenticator: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java#L224. So nobody can clean context from HttpURLConnection

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From abakhtin at openjdk.org  Fri Mar 10 16:22:56 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 10 Mar 2023 16:22:56 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v2]
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <D_bLo4VA27u0dC-Xzymi9cFIEaR1ZilXDAL6esSmCZs=.0e15b86d-3535-476f-8ac2-605c2573adc9@github.com>

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Fix formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12920/files
  - new: https://git.openjdk.org/jdk/pull/12920/files/8efa0c76..1b34252b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12920&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12920&range=00-01

  Stats: 7 lines in 3 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12920/head:pull/12920

PR: https://git.openjdk.org/jdk/pull/12920


From valeriep at openjdk.org  Sat Mar 11 01:21:23 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 11 Mar 2023 01:21:23 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <scqJMmGR4QWeeUgpyExdgshjwBXlFX1GNMkx-YQvVYU=.c5ec3c01-8c77-474b-8b2e-70bcbdbbbe5b@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 492:

> 490:                 getAliases(algorithm), m, requiredMechs));
> 491:     }
> 492: 

nit: move this to after the other dA(String, String, String, int[]) below

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From valeriep at openjdk.org  Sat Mar 11 05:54:21 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 11 Mar 2023 05:54:21 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <TD1dnLJemziz3u9qprp6nrWRdQ-f523Iu3q9cn_Bk5I=.b3bd7cdf-7080-47bb-bdb5-aa30dba6543e@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 83:

> 81:          *     PKCS #11 call (bytes) => [ 0x00,   0x61,   0x00,   0x00 ]
> 82:          */
> 83:         byte[] passwordBytes = new String(password).getBytes(cs);

Best to not storing the password into a String object. Perhaps use a CharBuffer?

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From jwaters at openjdk.org  Sat Mar 11 15:10:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 15:10:09 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>

> Was: sunmscapi.dll cannot compile with Visual C++
> 
> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a distinct C++ type when compiling with Visual C++ so jchar and wchar_t are typedef'd to shorts on Windows. After some examination it appears this flag is not actually needed for almost every source file that we have, barring security.cpp, so we could try to remove it and make Windows code behave more like regular C++, since casting between wchar_t and jchar does not appear to happen very often (only appearing in one file!). wchar_t in Standard C is a typedef and is never affected by this flag, and if `-Zc:wchar_t` is enabled for C code, it is simply ignored

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  AccessBridgeJavaEntryPoints.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12907/files
  - new: https://git.openjdk.org/jdk/pull/12907/files/2c3f65cd..f082db28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12907&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12907&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12907/head:pull/12907

PR: https://git.openjdk.org/jdk/pull/12907


From jwaters at openjdk.org  Sat Mar 11 16:10:34 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 16:10:34 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
Message-ID: <UZ7o3EbaKrcToWfCY395VnTBwtGPRqTeLVcOqElj1Es=.8ebac174-c9de-4289-a44b-7a05febe252b@github.com>

On Sat, 11 Mar 2023 15:10:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Was: sunmscapi.dll cannot compile with Visual C++
>> 
>> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a distinct C++ type when compiling with Visual C++ so jchar and wchar_t are typedef'd to shorts on Windows. After some examination it appears this flag is not actually needed for almost every source file that we have, barring security.cpp, so we could try to remove it and make Windows code behave more like regular C++, since casting between wchar_t and jchar does not appear to happen very often (only appearing in one file!). wchar_t in Standard C is a typedef and is never affected by this flag, and if `-Zc:wchar_t` is enabled for C code, it is simply ignored
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AccessBridgeJavaEntryPoints.cpp

Oops, didn't mean to do that. Oh well, will update this again later

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From jwaters at openjdk.org  Sat Mar 11 16:10:35 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 16:10:35 GMT
Subject: Withdrawn: 8303764: Enable -Zc:wchar_t for Visual C++
In-Reply-To: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
Message-ID: <3BtY5Vr6Aq8Hc8rW-k2z-MPmr3BFztCJfj3_syP84XU=.06868179-a6d6-4db7-b8d5-c11485d58c0a@github.com>

On Tue, 7 Mar 2023 17:27:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Was: sunmscapi.dll cannot compile with Visual C++
> 
> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a distinct C++ type when compiling with Visual C++ so jchar and wchar_t are typedef'd to shorts on Windows. After some examination it appears this flag is not actually needed for almost every source file that we have, barring security.cpp, so we could try to remove it and make Windows code behave more like regular C++, since casting between wchar_t and jchar does not appear to happen very often (only appearing in one file!). wchar_t in Standard C is a typedef and is never affected by this flag, and if `-Zc:wchar_t` is enabled for C code, it is simply ignored

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12907


From aturbanov at openjdk.org  Mon Mar 13 13:07:50 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 13 Mar 2023 13:07:50 GMT
Subject: Withdrawn: 8303832: Use enhanced-for cycle instead of Enumeration in
 JceKeyStore
In-Reply-To: <0B0tVUfiurFG1mqtWrh1ZkyFMBah6Or0rx0gJAnwZqo=.3552f5f0-907a-49ed-b90c-14881c4aa905@github.com>
References: <0B0tVUfiurFG1mqtWrh1ZkyFMBah6Or0rx0gJAnwZqo=.3552f5f0-907a-49ed-b90c-14881c4aa905@github.com>
Message-ID: <ap2fVSSxXY6xPareEJcmQTFRmx9mn94WXAoIBhf4EnQ=.48abe879-0fac-48fe-959d-53872ed578e0@github.com>

On Wed, 8 Mar 2023 19:10:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> java.util.Enumeration is a legacy interface from java 1.0.
> There is couple of places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12930


From weijun at openjdk.org  Mon Mar 13 16:04:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 13 Mar 2023 16:04:38 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v2]
In-Reply-To: <D_bLo4VA27u0dC-Xzymi9cFIEaR1ZilXDAL6esSmCZs=.0e15b86d-3535-476f-8ac2-605c2573adc9@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <D_bLo4VA27u0dC-Xzymi9cFIEaR1ZilXDAL6esSmCZs=.0e15b86d-3535-476f-8ac2-605c2573adc9@github.com>
Message-ID: <sOIUu6m5BTwNrOLySxF4H784roz_99RHMVBhVHPhN3o=.6e63aaee-0de5-4548-8b70-2490ce03cf17@github.com>

On Fri, 10 Mar 2023 16:22:56 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting

src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java line 254:

> 252:             try {
> 253:                 negotiator.disposeContext();
> 254:             } catch(IOException ioEx) {

Another whitespace is required after `catch`.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From abakhtin at openjdk.org  Mon Mar 13 17:28:33 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 13 Mar 2023 17:28:33 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v2]
In-Reply-To: <sOIUu6m5BTwNrOLySxF4H784roz_99RHMVBhVHPhN3o=.6e63aaee-0de5-4548-8b70-2490ce03cf17@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <D_bLo4VA27u0dC-Xzymi9cFIEaR1ZilXDAL6esSmCZs=.0e15b86d-3535-476f-8ac2-605c2573adc9@github.com>
 <sOIUu6m5BTwNrOLySxF4H784roz_99RHMVBhVHPhN3o=.6e63aaee-0de5-4548-8b70-2490ce03cf17@github.com>
Message-ID: <wYuCQFtgKlxeB1TQsn2mjuddjSRvq_yMxvI6n-2wSu4=.ae1896f7-832f-4686-99a2-2e586cb29319@github.com>

On Mon, 13 Mar 2023 16:02:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix formatting
>
> src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java line 254:
> 
>> 252:             try {
>> 253:                 negotiator.disposeContext();
>> 254:             } catch(IOException ioEx) {
> 
> Another whitespace is required after `catch`.

Thank you. Fixed

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From abakhtin at openjdk.org  Mon Mar 13 17:28:28 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 13 Mar 2023 17:28:28 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v3]
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <bPRCDCVLY4ebUJAagdf46ZHqPJgx8bgWp1mr-17OXLs=.8fb76bde-a3f6-414d-bdd4-3cc506ba1bb7@github.com>

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Space after catch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12920/files
  - new: https://git.openjdk.org/jdk/pull/12920/files/1b34252b..a54c3f3d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12920&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12920&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12920/head:pull/12920

PR: https://git.openjdk.org/jdk/pull/12920


From abakhtin at openjdk.org  Mon Mar 13 17:33:12 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 13 Mar 2023 17:33:12 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v4]
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <-mjFaGHQDyEINWxZQH_brwQooWYAV3AF-XtXDFJp8To=.4b6a0514-79d9-43c2-9594-0adde832bd9f@github.com>

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  More space after catch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12920/files
  - new: https://git.openjdk.org/jdk/pull/12920/files/a54c3f3d..75584998

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12920&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12920&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12920/head:pull/12920

PR: https://git.openjdk.org/jdk/pull/12920


From valeriep at openjdk.org  Mon Mar 13 19:33:45 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 13 Mar 2023 19:33:45 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <GfqlKRQwmaMxrE4PWjkyuYsLYHOJwCsV8zkYrdE_afU=.81d1cb47-c51b-4807-8728-cb5da459472f@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java line 1152:

> 1150:     public static final long  CKP_PKCS5_PBKD2_HMAC_SHA512_224  = 0x00000007L;
> 1151:     public static final long  CKP_PKCS5_PBKD2_HMAC_SHA512_256  = 0x00000008L;
> 1152: 

nit: instead of moving these PBKDF2 constants out of the commented section, how about preserving the ordering and just break the commented section into two sections? IIRC, this is easier to check/compare to pkcs11t.h by following the same order.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From weijun at openjdk.org  Mon Mar 13 20:56:07 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 13 Mar 2023 20:56:07 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v4]
In-Reply-To: <-mjFaGHQDyEINWxZQH_brwQooWYAV3AF-XtXDFJp8To=.4b6a0514-79d9-43c2-9594-0adde832bd9f@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <-mjFaGHQDyEINWxZQH_brwQooWYAV3AF-XtXDFJp8To=.4b6a0514-79d9-43c2-9594-0adde832bd9f@github.com>
Message-ID: <KukkB1llCZE4wxmYwfleYFGy64ZsZy78CRKCkahnVdQ=.537ccfcf-593b-4f61-bb74-36ece3fab1b3@github.com>

On Mon, 13 Mar 2023 17:33:12 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More space after catch

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From valeriep at openjdk.org  Tue Mar 14 00:54:45 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 14 Mar 2023 00:54:45 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <UTH0vH0iqc4pRJKIjOCCDRTUy20Lgfg4l82T5nvLnWI=.665605d4-8232-4cd3-b456-a091ea3ebd14@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c line 423:

> 421:                  case CKM_NSS_PKCS12_PBE_SHA256_HMAC_KEY_GEN:
> 422:                  case CKM_NSS_PKCS12_PBE_SHA384_HMAC_KEY_GEN:
> 423:                  case CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN:

How about CKM_PBE_SHA1_DES3_EDE_CBC and CKM_PBE_SHA1_DES2_EDE_CBC?

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From djelinski at openjdk.org  Tue Mar 14 10:52:07 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 14 Mar 2023 10:52:07 GMT
Subject: RFR: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors [v2]
In-Reply-To: <A3QXaxzsDMf9ZqmMj8Yi-oSmBpdsKsegibStfU7H158=.16c88141-2e9d-455d-8187-7b6d210168ab@github.com>
References: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
 <A3QXaxzsDMf9ZqmMj8Yi-oSmBpdsKsegibStfU7H158=.16c88141-2e9d-455d-8187-7b6d210168ab@github.com>
Message-ID: <o85eIla5oP2ga3YnnqUH8XjaWBJMThFfWVswDoWpBTg=.15d0a58f-afb1-4904-8ce3-9e3c858df02f@github.com>

On Thu, 2 Feb 2023 18:33:23 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Hello all,
>> 
>> This addresses a test bug where the SimpleOCSPServer would reset the connections made by a client CertPathValidator.  I've made some minor changes to how the network data is read and sent from OCSP HTTP GET URLs and on responses, respectively.  This will take the test off the problem list as well.
>> 
>> This has been taken through hundreds of test runs and does not see the failure any longer where there used to be intermittent failures.  Also multiple tier2 runs have been executed with no failures.
>> 
>> - JBS: https://bugs.openjdk.org/browse/JDK-8300939
>
> Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - merge with main
>  - 8300939: sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to network errors
>  - Merge with main
>  - Restore policy Root.java lost during merge
>  - Merge with main
>  - 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList
>  - Remove dead commented code
>  - Throw exception directly from non 200 HTTP response codes
>  - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests
>  - 8296343: CPVE thrown on missing content-length in OCSP response

Draining the input stream is the right fix.

-------------

Marked as reviewed by djelinski (Committer).

PR: https://git.openjdk.org/jdk/pull/12370


From duke at openjdk.org  Tue Mar 14 11:52:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Mar 2023 11:52:41 GMT
Subject: Integrated: 8303410: Remove ContentSigner APIs and jarsigner
 -altsigner and -altsignerpath options
In-Reply-To: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
References: <Z68IrlhffEsY0WEhzzkrwuEUmmiV7GBcI6BW_lkRepI=.e9fc2107-24b5-471f-bbcd-e47e5e96527c@github.com>
Message-ID: <hTfQKyjZ5WxLjSjxMWekn7iZ4gKnGzHkHuag3lyXctc=.83d66c1c-d43a-446c-8908-d2c6bafbaf8e@github.com>

On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The `-altsigner` and `-altsignerpath` options in JarSigner with the underlying `ContentSigner` mechanism were deprected in Java 9, for removal in Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535), [JDK-8242260](https://bugs.openjdk.org/browse/JDK-8242260).
> 
> This PR suggests it's time to remove this code:
> 
> - The package `com/sun/jarsigner` is removed. This contained the `ContentSigner` and `ContentSignerParameters` along with a `package-info.java` file.
> - `JarSigner.java` is updated to remove processing of the `-altsigner` and `-altsignerpath` options and the loading and processing of the custom `ContentSigner`.
> - Similarly `c.s.s.t.jarsigner.Main` is updated to remove processing and mentioning of `-altsigner` and `-altsignerpath` options.
> - Mentions of the options in Resource files in the same directory is removed
> - The `jarsigner.1` man page is updated to remove the section on the deprecated options
> - The `Spec` and `Options` tests are update to remove usage of the `-altsigner` and `-altsignerpath` options.

This pull request has now been integrated.

Changeset: 31680b2b
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/31680b2bcffe03ec11204946a1e168d4d9f31d87
Stats:     646 lines in 14 files changed: 3 ins; 618 del; 25 mod

8303410: Remove ContentSigner APIs and jarsigner -altsigner and -altsignerpath options

Reviewed-by: weijun

-------------

PR: https://git.openjdk.org/jdk/pull/12791


From dfuchs at openjdk.org  Tue Mar 14 13:59:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 14 Mar 2023 13:59:10 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <MYcKqDuRMbLbYrG2u3i68olsiy3qOzyzrYqA1c_bt84=.28b9efa0-82cb-454d-bc24-020364c6e771@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <MYcKqDuRMbLbYrG2u3i68olsiy3qOzyzrYqA1c_bt84=.28b9efa0-82cb-454d-bc24-020364c6e771@github.com>
Message-ID: <ywninrpki_6LLKEepntWVS7TWqcYRTAw91xsjPiMGWo=.6b7f556d-7ac9-4767-8cec-11ef21d3a711@github.com>

On Thu, 9 Mar 2023 16:02:33 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> Unfortunately, there is no guarantee `NegotiatorImpl::nextToken` will be called. 
> At least in both `sun/security/krb5/auto/HttpNegotiateServer.java` and `sun/security/krb5/auto/HttpsCB.java` tests context is not established after the first `initSecContext` and `NegotiatorImpl::nextToken` is not called at all.

Hi @alexeybakhtin, I will do some tests and come back to you here.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From weijun at openjdk.org  Tue Mar 14 14:10:55 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 14 Mar 2023 14:10:55 GMT
Subject: RFR: 8304136: Match allocation and free in sspi.cpp
Message-ID: <SHCI07jBgMwrniNa4aeJcLltaY2eh5_YwPhSJBsW8Zs=.26e30881-4c81-4321-8cac-41c1ea6b4986@github.com>

After this change, `gss_buffer_t` always uses `malloc` and `free`. All others use `new` and `delete`. It also initializes several `SecBuffer` to zeroes so it's safe to check for null when trying to free them.

-------------

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/13018/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13018&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304136
  Stats: 32 lines in 1 file changed: 12 ins; 3 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13018.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13018/head:pull/13018

PR: https://git.openjdk.org/jdk/pull/13018


From jnimeh at openjdk.org  Tue Mar 14 14:24:20 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 14 Mar 2023 14:24:20 GMT
Subject: RFR: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors [v3]
In-Reply-To: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
References: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
Message-ID: <QALFgmcpWNknhw2vqzbEHxbIm_5zpiQHU5DLSUrP-Iw=.524904af-d0fc-43e8-9e4c-7a2e70107062@github.com>

> Hello all,
> 
> This addresses a test bug where the SimpleOCSPServer would reset the connections made by a client CertPathValidator.  I've made some minor changes to how the network data is read and sent from OCSP HTTP GET URLs and on responses, respectively.  This will take the test off the problem list as well.
> 
> This has been taken through hundreds of test runs and does not see the failure any longer where there used to be intermittent failures.  Also multiple tier2 runs have been executed with no failures.
> 
> - JBS: https://bugs.openjdk.org/browse/JDK-8300939

Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - merge with main
 - merge with main
 - 8300939: sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to network errors
 - Merge with main
 - Restore policy Root.java lost during merge
 - Merge with main
 - 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList
 - Remove dead commented code
 - Throw exception directly from non 200 HTTP response codes
 - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests
 - ... and 1 more: https://git.openjdk.org/jdk/compare/55aa1224...b2d25b7e

-------------

Changes: https://git.openjdk.org/jdk/pull/12370/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12370&range=02
  Stats: 55 lines in 3 files changed: 39 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/12370.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12370/head:pull/12370

PR: https://git.openjdk.org/jdk/pull/12370


From dfuchs at openjdk.org  Tue Mar 14 14:34:18 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 14 Mar 2023 14:34:18 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v4]
In-Reply-To: <-mjFaGHQDyEINWxZQH_brwQooWYAV3AF-XtXDFJp8To=.4b6a0514-79d9-43c2-9594-0adde832bd9f@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <-mjFaGHQDyEINWxZQH_brwQooWYAV3AF-XtXDFJp8To=.4b6a0514-79d9-43c2-9594-0adde832bd9f@github.com>
Message-ID: <qwaengSmNvQDf4SEqd_O6_AyckEuaDzDlLOGaMhAHz0=.76016f86-f56c-43c4-9c2e-5adfc6264b4f@github.com>

On Mon, 13 Mar 2023 17:33:12 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More space after catch

src/java.base/share/classes/sun/net/www/protocol/http/Negotiator.java line 86:

> 84:     }
> 85: 
> 86:     public abstract void disposeContext() throws IOException;

We have some old internal tests that extend  `Negotiator` and that will fail when this change is pushed. I'd suggest to change this method as follows:

Suggestion:

    public void disposeContext() throws IOException { }


This should avoid breaking existing subclasses that do not implement this method.

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From weijun at openjdk.org  Tue Mar 14 15:05:48 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 14 Mar 2023 15:05:48 GMT
Subject: RFR: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors [v3]
In-Reply-To: <QALFgmcpWNknhw2vqzbEHxbIm_5zpiQHU5DLSUrP-Iw=.524904af-d0fc-43e8-9e4c-7a2e70107062@github.com>
References: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
 <QALFgmcpWNknhw2vqzbEHxbIm_5zpiQHU5DLSUrP-Iw=.524904af-d0fc-43e8-9e4c-7a2e70107062@github.com>
Message-ID: <4IN9X02uKdIHcEjH1WBJUdIt-fqcmAZXzvD5dRApgx8=.fe424fa0-7f66-4d2d-9355-6f477cf8dd95@github.com>

On Tue, 14 Mar 2023 14:24:20 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Hello all,
>> 
>> This addresses a test bug where the SimpleOCSPServer would reset the connections made by a client CertPathValidator.  I've made some minor changes to how the network data is read and sent from OCSP HTTP GET URLs and on responses, respectively.  This will take the test off the problem list as well.
>> 
>> This has been taken through hundreds of test runs and does not see the failure any longer where there used to be intermittent failures.  Also multiple tier2 runs have been executed with no failures.
>> 
>> - JBS: https://bugs.openjdk.org/browse/JDK-8300939
>
> Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - merge with main
>  - merge with main
>  - 8300939: sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to network errors
>  - Merge with main
>  - Restore policy Root.java lost during merge
>  - Merge with main
>  - 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList
>  - Remove dead commented code
>  - Throw exception directly from non 200 HTTP response codes
>  - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/55aa1224...b2d25b7e

Looks fine. Just one comment.

test/jdk/java/security/testlibrary/SimpleOCSPServer.java line 340:

> 338:      */
> 339:     private static String dumpHexBytes(byte[] data, int dataLen,
> 340:             int itemsPerLine, String lineDelim, String itemDelim) {

You always call with `dataLen = data.length`. Is it still necessary to add this argument?

-------------

PR: https://git.openjdk.org/jdk/pull/12370


From weijun at openjdk.org  Tue Mar 14 15:08:46 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 14 Mar 2023 15:08:46 GMT
Subject: RFR: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors [v3]
In-Reply-To: <QALFgmcpWNknhw2vqzbEHxbIm_5zpiQHU5DLSUrP-Iw=.524904af-d0fc-43e8-9e4c-7a2e70107062@github.com>
References: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
 <QALFgmcpWNknhw2vqzbEHxbIm_5zpiQHU5DLSUrP-Iw=.524904af-d0fc-43e8-9e4c-7a2e70107062@github.com>
Message-ID: <UWAdXjEjZddTrMlwXKf9ivH0Plmz70mqUYkeHv2Gk5k=.1a0562af-a993-4905-bacc-5530311f0f12@github.com>

On Tue, 14 Mar 2023 14:24:20 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Hello all,
>> 
>> This addresses a test bug where the SimpleOCSPServer would reset the connections made by a client CertPathValidator.  I've made some minor changes to how the network data is read and sent from OCSP HTTP GET URLs and on responses, respectively.  This will take the test off the problem list as well.
>> 
>> This has been taken through hundreds of test runs and does not see the failure any longer where there used to be intermittent failures.  Also multiple tier2 runs have been executed with no failures.
>> 
>> - JBS: https://bugs.openjdk.org/browse/JDK-8300939
>
> Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - merge with main
>  - merge with main
>  - 8300939: sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to network errors
>  - Merge with main
>  - Restore policy Root.java lost during merge
>  - Merge with main
>  - 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList
>  - Remove dead commented code
>  - Throw exception directly from non 200 HTTP response codes
>  - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/55aa1224...b2d25b7e

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12370


From abakhtin at openjdk.org  Tue Mar 14 15:09:04 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 14 Mar 2023 15:09:04 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v5]
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <Ny0K3dNKvSP_alcNF-UIROsZlZHdXs0I1SNz49FGOYE=.c0c8fa21-e099-47ab-92fb-bb50cfa35235@github.com>

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Convert method from abstract to empty

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12920/files
  - new: https://git.openjdk.org/jdk/pull/12920/files/75584998..f64a9067

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12920&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12920&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12920/head:pull/12920

PR: https://git.openjdk.org/jdk/pull/12920


From abakhtin at openjdk.org  Tue Mar 14 15:09:09 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 14 Mar 2023 15:09:09 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v4]
In-Reply-To: <qwaengSmNvQDf4SEqd_O6_AyckEuaDzDlLOGaMhAHz0=.76016f86-f56c-43c4-9c2e-5adfc6264b4f@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <-mjFaGHQDyEINWxZQH_brwQooWYAV3AF-XtXDFJp8To=.4b6a0514-79d9-43c2-9594-0adde832bd9f@github.com>
 <qwaengSmNvQDf4SEqd_O6_AyckEuaDzDlLOGaMhAHz0=.76016f86-f56c-43c4-9c2e-5adfc6264b4f@github.com>
Message-ID: <GW2kbhbBJL6VkFM7Veiyfo-uWKlICIrr-igpVLcHzjI=.0584bae3-2fb5-4d3f-8f63-bc0ff898950a@github.com>

On Tue, 14 Mar 2023 14:30:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More space after catch
>
> src/java.base/share/classes/sun/net/www/protocol/http/Negotiator.java line 86:
> 
>> 84:     }
>> 85: 
>> 86:     public abstract void disposeContext() throws IOException;
> 
> We have some old internal tests that extend  `Negotiator` and that will fail when this change is pushed. I'd suggest to change this method as follows:
> 
> Suggestion:
> 
>     public void disposeContext() throws IOException { }
> 
> 
> This should avoid breaking existing subclasses that do not implement this method.

Thank you. Changed from abstract to empty.
sun/security/jgss sun/security/krb5 sun/net/www/protocol/http tests passed

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From jnimeh at openjdk.org  Tue Mar 14 15:40:39 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 14 Mar 2023 15:40:39 GMT
Subject: RFR: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors [v3]
In-Reply-To: <4IN9X02uKdIHcEjH1WBJUdIt-fqcmAZXzvD5dRApgx8=.fe424fa0-7f66-4d2d-9355-6f477cf8dd95@github.com>
References: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
 <QALFgmcpWNknhw2vqzbEHxbIm_5zpiQHU5DLSUrP-Iw=.524904af-d0fc-43e8-9e4c-7a2e70107062@github.com>
 <4IN9X02uKdIHcEjH1WBJUdIt-fqcmAZXzvD5dRApgx8=.fe424fa0-7f66-4d2d-9355-6f477cf8dd95@github.com>
Message-ID: <9P-aj0pfx2DzsehhJ1uCmvAxuqzXXhQqNbrTTre3JNk=.4782b178-23da-422e-bff2-567804e5f4da@github.com>

On Tue, 14 Mar 2023 15:01:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - merge with main
>>  - merge with main
>>  - 8300939: sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to network errors
>>  - Merge with main
>>  - Restore policy Root.java lost during merge
>>  - Merge with main
>>  - 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList
>>  - Remove dead commented code
>>  - Throw exception directly from non 200 HTTP response codes
>>  - Moved SimpleOCSPServer to use CountdownLatch for ready state, updated tests
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/55aa1224...b2d25b7e
>
> test/jdk/java/security/testlibrary/SimpleOCSPServer.java line 340:
> 
>> 338:      */
>> 339:     private static String dumpHexBytes(byte[] data, int dataLen,
>> 340:             int itemsPerLine, String lineDelim, String itemDelim) {
> 
> You always call with `dataLen = data.length`. Is it still necessary to add this argument?

Yes, I would prefer to keep this.  I made the change in order to help me debug draining the input stream and I felt it prudent to leave it in place, along with the main test's debug flag just in case.

-------------

PR: https://git.openjdk.org/jdk/pull/12370


From jnimeh at openjdk.org  Tue Mar 14 15:47:06 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 14 Mar 2023 15:47:06 GMT
Subject: Integrated: 8300939:
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to
 network errors
In-Reply-To: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
References: <H6NRn9Uv3hwylvX3iOuZjVPbZugruSQWylq7QP-KFDU=.33542ee5-017e-46e9-8c62-38c448bbb8e4@github.com>
Message-ID: <GWQ_q7YnnvRZ2SmmXJHXKrR9MXCiPiNQan0sl-poFQg=.8a916976-3573-4293-931c-51baaf58bc5b@github.com>

On Wed, 1 Feb 2023 18:10:41 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> Hello all,
> 
> This addresses a test bug where the SimpleOCSPServer would reset the connections made by a client CertPathValidator.  I've made some minor changes to how the network data is read and sent from OCSP HTTP GET URLs and on responses, respectively.  This will take the test off the problem list as well.
> 
> This has been taken through hundreds of test runs and does not see the failure any longer where there used to be intermittent failures.  Also multiple tier2 runs have been executed with no failures.
> 
> - JBS: https://bugs.openjdk.org/browse/JDK-8300939

This pull request has now been integrated.

Changeset: da044dd5
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da044dd5698d14eccd2a30a24cc691e30fa00cbd
Stats:     55 lines in 3 files changed: 39 ins; 2 del; 14 mod

8300939: sun/security/provider/certpath/OCSP/OCSPNoContentLength.java fails due to network errors

Reviewed-by: djelinski, weijun

-------------

PR: https://git.openjdk.org/jdk/pull/12370


From dfuchs at openjdk.org  Tue Mar 14 16:40:52 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 14 Mar 2023 16:40:52 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v5]
In-Reply-To: <Ny0K3dNKvSP_alcNF-UIROsZlZHdXs0I1SNz49FGOYE=.c0c8fa21-e099-47ab-92fb-bb50cfa35235@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <Ny0K3dNKvSP_alcNF-UIROsZlZHdXs0I1SNz49FGOYE=.c0c8fa21-e099-47ab-92fb-bb50cfa35235@github.com>
Message-ID: <YQaKmIgskCSWOd7E017sW8rKf8JR9GIuKG3j4UAX95I=.0670984c-8a47-41f2-a7b9-c0c3dfce2ae0@github.com>

On Tue, 14 Mar 2023 15:09:04 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert method from abstract to empty

Thanks Alexey. Tests returned green. Good to go!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12920


From abakhtin at openjdk.org  Tue Mar 14 16:40:55 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 14 Mar 2023 16:40:55 GMT
Subject: RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl [v5]
In-Reply-To: <YQaKmIgskCSWOd7E017sW8rKf8JR9GIuKG3j4UAX95I=.0670984c-8a47-41f2-a7b9-c0c3dfce2ae0@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
 <Ny0K3dNKvSP_alcNF-UIROsZlZHdXs0I1SNz49FGOYE=.c0c8fa21-e099-47ab-92fb-bb50cfa35235@github.com>
 <YQaKmIgskCSWOd7E017sW8rKf8JR9GIuKG3j4UAX95I=.0670984c-8a47-41f2-a7b9-c0c3dfce2ae0@github.com>
Message-ID: <18TYoEi-PLnJDUxupmAyCv8k3SXwzBCimKeoNF9ERM4=.5c86496d-9fe3-4f9e-9c7e-1ee2d21711c3@github.com>

On Tue, 14 Mar 2023 16:35:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks Alexey. Tests returned green. Good to go!

Thank you a lot for review

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From abakhtin at openjdk.org  Tue Mar 14 16:44:31 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 14 Mar 2023 16:44:31 GMT
Subject: Integrated: 8303809: Dispose context in SPNEGO NegotiatorImpl
In-Reply-To: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
References: <rXQID__R_jMI-2L8orEfylS5teHU-ZboqmbGvht-QMw=.35581e5b-1f9e-4daf-bc50-514c1dd08a6a@github.com>
Message-ID: <IKUBAyO1h2fVE-odeMXwxnGWqadtKUW5fqGJ_F6SA50=.a33c06ce-d4e0-4e7a-be1a-777406f45498@github.com>

On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> This patch fixes a possible native memory leak in case of a custom native GSS provider.
> The actual leak was reported in production.
> 
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed

This pull request has now been integrated.

Changeset: 10f16746
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10f16746254ce62031f40ffb0f49f22e81cbe631
Stats:     70 lines in 5 files changed: 70 ins; 0 del; 0 mod

8303809: Dispose context in SPNEGO NegotiatorImpl

Reviewed-by: dfuchs, weijun

-------------

PR: https://git.openjdk.org/jdk/pull/12920


From valeriep at openjdk.org  Tue Mar 14 17:10:42 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 14 Mar 2023 17:10:42 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <rTsBN7F8NGYUJbAU7fvq15O4A9etgByp3LLYDUKdy_Q=.352642f7-ab76-428c-89d9-38070706a74f@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c line 1825:

> 1823:         paramVersion = PARAMS2;
> 1824:     } else {
> 1825:         return NULL;

Instead of returning NULL, should some exception be thrown to indicate that there is a problem with the specified parameter (not the expected type)?

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From rhalade at openjdk.org  Tue Mar 14 17:22:08 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 14 Mar 2023 17:22:08 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates [v3]
In-Reply-To: <L9NFTf7xiATWmDN2OIxKO_dd3V-6a1DLwFOr8JVpy-4=.acc6a88e-5aab-49f9-83fa-99481dfd77f1@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
 <gkzeT1xHwkU5FRYfes9v_JkrFTD8zMaozE-XOfv9jYQ=.ac173945-017f-468f-a333-9edba82151ab@github.com>
 <L9NFTf7xiATWmDN2OIxKO_dd3V-6a1DLwFOr8JVpy-4=.acc6a88e-5aab-49f9-83fa-99481dfd77f1@github.com>
Message-ID: <Fnc1TiM_TNcJ0FToFI9-Oy82AgEXTYfgYVBDYpdLmUE=.f187190c-7d3f-493a-8702-b8c36eef05e0@github.com>

On Mon, 27 Feb 2023 19:11:29 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java line 31:
>> 
>>> 29:  * @bug 8051498 8145849 8158978 8170282
>>> 30:  * @summary JEP 244: TLS Application-Layer Protocol Negotiation Extension
>>> 31:  * @compile MyX509ExtendedKeyManager.java
>> 
>> Suggest you to delete file `MyX509ExtendedKeyManager.java` if it is not needed anymore.
>
> removed

Don't see this file deleted in PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12555


From duke at openjdk.org  Tue Mar 14 18:00:23 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 14 Mar 2023 18:00:23 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates [v4]
In-Reply-To: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
Message-ID: <ItahqAB5PUAxUK_p6Kj158cN9qKEm64XnF48sDx3hTs=.cf78390d-c253-489b-9a36-ca874ca48f62@github.com>

> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  removed last use of MyX509ExtendedKeyManager in ALPN directory

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12555/files
  - new: https://git.openjdk.org/jdk/pull/12555/files/3e971cc0..04d97ed7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12555&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12555&range=02-03

  Stats: 142 lines in 2 files changed: 0 ins; 139 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12555.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12555/head:pull/12555

PR: https://git.openjdk.org/jdk/pull/12555


From duke at openjdk.org  Tue Mar 14 18:00:42 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 14 Mar 2023 18:00:42 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates [v4]
In-Reply-To: <Fnc1TiM_TNcJ0FToFI9-Oy82AgEXTYfgYVBDYpdLmUE=.f187190c-7d3f-493a-8702-b8c36eef05e0@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
 <gkzeT1xHwkU5FRYfes9v_JkrFTD8zMaozE-XOfv9jYQ=.ac173945-017f-468f-a333-9edba82151ab@github.com>
 <L9NFTf7xiATWmDN2OIxKO_dd3V-6a1DLwFOr8JVpy-4=.acc6a88e-5aab-49f9-83fa-99481dfd77f1@github.com>
 <Fnc1TiM_TNcJ0FToFI9-Oy82AgEXTYfgYVBDYpdLmUE=.f187190c-7d3f-493a-8702-b8c36eef05e0@github.com>
Message-ID: <FKj6MPagBWZ-QPvQG31e4pU4FcG1S5SSmKfr8RafCGs=.2f7f82f9-2b4b-42aa-bebc-7e2fa4f9b18a@github.com>

On Tue, 14 Mar 2023 17:18:46 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> removed
>
> Don't see this file deleted in PR.

It was still being used by an "engine" test in that directory; I removed that last use and deleted the key manager class.

(there is another bug to refactor the SSLEngine tests.)

-------------

PR: https://git.openjdk.org/jdk/pull/12555


From rhalade at openjdk.org  Tue Mar 14 18:00:39 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 14 Mar 2023 18:00:39 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates [v3]
In-Reply-To: <ndfXFnwvprhARfu-_CWeJNxXCEghf2Oxj4LGEyh0H28=.201cdb49-7c26-4f83-8d7a-f50f76217b3c@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
 <ndfXFnwvprhARfu-_CWeJNxXCEghf2Oxj4LGEyh0H28=.201cdb49-7c26-4f83-8d7a-f50f76217b3c@github.com>
Message-ID: <9JDDXeHzLb54jDWw-qe-RstyrVCcNy1RHvTRDBSfldg=.c81c780d-d998-4afc-861f-b7d8d5a3bc8d@github.com>

On Wed, 1 Mar 2023 15:30:19 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
>> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
>> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into templates
>  - updated certificate info
>  - Merge branch 'master' into templates
>  - reverted changes, removed SSLSocketSSLEngineTemplate, updated SSLEngineBadBufferArrayAccess.java
>  - fixed compilation errors
>  - Merge branch 'master' into templates
>  - 8284047: Harmonize/Standardize the SSLSocket/SSLEngine/SSLSocketSSLEngine test templates

Updated review looks good to me except few minor code cleanup comments.

test/jdk/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java line 84:

> 82: import java.security.KeyStore;
> 83: import java.util.Arrays;
> 84: 

`java.security.KeyStore` is unused

test/jdk/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java line 144:

> 142:      * to avoid infinite hangs.
> 143:      */
> 144:     protected void runServerApplication(SSLSocket sslSocket) throws Exception {

Missing `@Override`

test/jdk/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java line 230:

> 228:      * to avoid infinite hangs.
> 229:      */
> 230:     protected void runClientApplication(SSLSocket sslSocket) throws Exception {

Missing `@Override`. Comment applies to few other files in this review.

test/jdk/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java line 58:

> 56: import java.util.Base64;
> 57: 
> 58: 

With the update to this file, many imports are unused.

test/jdk/sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java line 122:

> 120:     }
> 121: 
> 122:     public SSLContext createClientSSLContext() throws Exception {

please revert unnecessary change to this file

test/jdk/sun/security/ssl/SSLContextImpl/MultipleChooseAlias.java line 71:

> 69: 
> 70:     @Override
> 71:     public ContextParameters getClientContextParameters() {

Please revert unnecessary change to this file

test/jdk/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java line 116:

> 114: 
> 115:     @Override
> 116:     public SSLContext createServerSSLContext() throws Exception {

Same here, no change is needed in this file.

-------------

Changes requested by rhalade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12555


From duke at openjdk.org  Tue Mar 14 18:46:29 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 14 Mar 2023 18:46:29 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates [v5]
In-Reply-To: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
Message-ID: <Bv_KfldKsL9Pisc-PKIUgHxNjbzzeIFfs6zq-fHbZh8=.7db4d2ef-36a3-4a64-80a8-db319bfc2c58@github.com>

> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  cleaned up code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12555/files
  - new: https://git.openjdk.org/jdk/pull/12555/files/04d97ed7..b6935d36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12555&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12555&range=03-04

  Stats: 35 lines in 9 files changed: 7 ins; 16 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12555.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12555/head:pull/12555

PR: https://git.openjdk.org/jdk/pull/12555


From duke at openjdk.org  Tue Mar 14 18:46:30 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 14 Mar 2023 18:46:30 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates [v3]
In-Reply-To: <9JDDXeHzLb54jDWw-qe-RstyrVCcNy1RHvTRDBSfldg=.c81c780d-d998-4afc-861f-b7d8d5a3bc8d@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
 <ndfXFnwvprhARfu-_CWeJNxXCEghf2Oxj4LGEyh0H28=.201cdb49-7c26-4f83-8d7a-f50f76217b3c@github.com>
 <9JDDXeHzLb54jDWw-qe-RstyrVCcNy1RHvTRDBSfldg=.c81c780d-d998-4afc-861f-b7d8d5a3bc8d@github.com>
Message-ID: <qnf-tELYS77BGRNZGp2f2mCoUlDwFIDWhGgyTipZra4=.26ce9fb9-66f5-409e-9351-023375390535@github.com>

On Tue, 14 Mar 2023 17:56:07 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated review looks good to me except few minor code cleanup comments.

I went through all the changed files and added @Override where necessary and cleaned up imports. I think I got them all.

-------------

PR: https://git.openjdk.org/jdk/pull/12555


From rhalade at openjdk.org  Tue Mar 14 18:50:48 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 14 Mar 2023 18:50:48 GMT
Subject: RFR: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates [v5]
In-Reply-To: <Bv_KfldKsL9Pisc-PKIUgHxNjbzzeIFfs6zq-fHbZh8=.7db4d2ef-36a3-4a64-80a8-db319bfc2c58@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
 <Bv_KfldKsL9Pisc-PKIUgHxNjbzzeIFfs6zq-fHbZh8=.7db4d2ef-36a3-4a64-80a8-db319bfc2c58@github.com>
Message-ID: <q04upya8-Brypr6gROVx0VH7TwG5IVHk22qUVPXNPtM=.c0c3b310-fd22-40a3-9098-9c9a1c06529a@github.com>

On Tue, 14 Mar 2023 18:46:29 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
>> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
>> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleaned up code

Marked as reviewed by rhalade (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12555


From djelinski at openjdk.org  Tue Mar 14 20:13:08 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 14 Mar 2023 20:13:08 GMT
Subject: RFR: 8304136: Match allocation and free in sspi.cpp
In-Reply-To: <SHCI07jBgMwrniNa4aeJcLltaY2eh5_YwPhSJBsW8Zs=.26e30881-4c81-4321-8cac-41c1ea6b4986@github.com>
References: <SHCI07jBgMwrniNa4aeJcLltaY2eh5_YwPhSJBsW8Zs=.26e30881-4c81-4321-8cac-41c1ea6b4986@github.com>
Message-ID: <dFA-hjPgP2Ge0ZYmCq9Fl-D98hwVQ8Z3nVJmFRtngoE=.8274e89a-ef7e-4f7f-8e2e-9cd432cd89a7@github.com>

On Tue, 14 Mar 2023 14:02:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> After this change, `gss_buffer_t` always uses `malloc` and `free`. All others use `new` and `delete`. It also initializes several `SecBuffer` to zeroes so it's safe to check for null when trying to free them.

LGTM. Thanks!

-------------

Marked as reviewed by djelinski (Committer).

PR: https://git.openjdk.org/jdk/pull/13018


From valeriep at openjdk.org  Tue Mar 14 20:48:55 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 14 Mar 2023 20:48:55 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <Tmf8bvKbNgNGMnou3LQoL98gLwEhffn0C-bqVOQnls0=.f24c3e40-541e-4d1a-90c3-caa3d67d929a@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

Look fine. Thanks~

Just to be safe, I will also run regression test on my side as well.

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12732


From wetmore at openjdk.org  Tue Mar 14 20:56:27 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 14 Mar 2023 20:56:27 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <A93ZH12dzBHhxDiizk7Hkgbl1yB-i5_NJ3bVdnOOMrE=.e1a3bc18-7fab-404d-8c63-70379626383a@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

LGTM.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12732


From xuelei at openjdk.org  Tue Mar 14 21:25:51 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 14 Mar 2023 21:25:51 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <_qlJO4uIah2tm1dhS05u8ujJPXV1ABZtnM6xo4NW3J0=.776ffd52-f1b1-4e30-841b-32453f3c7b1b@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

May I get a chance to review it before the integration?  I may need more time to dig into time-constant issue.

-------------

Changes requested by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12732


From xuelei at openjdk.org  Tue Mar 14 22:01:23 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 14 Mar 2023 22:01:23 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <_qlJO4uIah2tm1dhS05u8ujJPXV1ABZtnM6xo4NW3J0=.776ffd52-f1b1-4e30-841b-32453f3c7b1b@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
 <_qlJO4uIah2tm1dhS05u8ujJPXV1ABZtnM6xo4NW3J0=.776ffd52-f1b1-4e30-841b-32453f3c7b1b@github.com>
Message-ID: <ZMw9GyCrzuJZwMMqPx0OrqPoi7Teztl6t2rvzqJeE6Y=.8c1a9433-8e7f-46cb-926d-3c7915806e56@github.com>

On Tue, 14 Mar 2023 21:23:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> May I get a chance to review it before the integration? I may need more time to dig into time-constant issue.

If I read the Bleichenbacher's Attack[1][2] right, the attack works if it can tell the difference between good conditions and error conditions.  RFC 8017 says "distinguish the different error conditions", but it may be parsed differently for various context.  Please be careful about this update.

Thank you for giving me more time to look into the details.

[1]: https://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf
[2]: https://medium.com/@c0D3M/bleichenbacher-attack-explained-bc630f88ff25
[3]: https://asecuritysite.com/encryption/c_c3

-------------

PR: https://git.openjdk.org/jdk/pull/12732


From valeriep at openjdk.org  Wed Mar 15 00:34:54 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Mar 2023 00:34:54 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <o4jO-b-vE8vC-jKTSkihgwmWT5BFzziCarzD3cBt0Cc=.4d404289-38be-4aa4-ac4d-eea0eb9385d1@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 108:

> 106:         }
> 107: 
> 108:         static boolean checkUse(KeyInfo ki, KeyInfo si) {

More comment on ki and si and how this method is used is needed as it's not obvious when looking at the code here.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 118:

> 116:                 return true;
> 117:             }
> 118:             return ki.keyType == si.keyType;

So, for non-PBE key info, algos do not have to match?

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From wetmore at openjdk.org  Wed Mar 15 00:39:34 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 15 Mar 2023 00:39:34 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <hVWVRfa-Kc0KRxBQ4Q3lZon65AZkUNsBEqBRQ_R3CY4=.a9ce8a1e-df81-41eb-88ef-2726dbe43b55@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

See my previous (edited) comment

-------------

Changes requested by wetmore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12732


From valeriep at openjdk.org  Wed Mar 15 00:50:35 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Mar 2023 00:50:35 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <4qzwDcl0k34UtSTQE4QH9lgGj7wkseCQvFPiUCvDdJU=.a363d756-d0ac-432b-a479-fed871b6823e@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 239:

> 237:         long kt = getKeyType(algorithm);
> 238:         if (kt == -1 || kt > PCKK_ANY) {
> 239:             // Replace pseudo key type.

Well, it seems clearer to have the "No pseudo key types" comment as method comment.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From weijun at openjdk.org  Wed Mar 15 13:52:24 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Mar 2023 13:52:24 GMT
Subject: RFR: 8304264: Debug messages always show up for NativeGSS
Message-ID: <06x1PzIDYKRrgGgUT7hXWBYA9e5JBLWtCowNWcHxU7g=.b2f3ca03-de5f-49c4-a050-5c55181d4183@github.com>

Only call `debug()` when `DEBUG` is set.

-------------

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/13043/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13043&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304264
  Stats: 61 lines in 5 files changed: 29 ins; 0 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/13043.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13043/head:pull/13043

PR: https://git.openjdk.org/jdk/pull/13043


From weijun at openjdk.org  Wed Mar 15 14:54:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Mar 2023 14:54:23 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <Wxq8UhV2QEt_LiMEUlf1hKF_pLGttTylntM1OpYZizA=.f9ac393b-3f4c-4bb3-aaa2-eaaa72572a7e@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/java.base/share/classes/sun/security/util/PBEUtil.java line 47:

> 45: 
> 46:     // Used by SunJCE and SunPKCS11
> 47:     public final static class PBES2Params {

This class confuses me. An instance is constructed without any parameter. The method `getPBEKeySpec` is able to mutate it and return something, the method `getAlgorithmParameters` is able to read the content and possibly mutate again and return something, and finally another method `getIvSpec` is able to return the content.

Please either precisely document how these methods will be called and enforce this rule with internal checks, or refactor it to something immutable.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From djelinski at openjdk.org  Wed Mar 15 15:10:27 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 15 Mar 2023 15:10:27 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <ptkZRk1ojLVqU3d9w_sSG6RVGzcQrhu8_z_4xtzZxzY=.70cb3be9-d1b6-40ad-bcc5-21cfec5d1116@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

Well `throw` will always be slower than `return`, even if the stack trace is populated on both paths. How do we know if we are not vulnerable to Bleichenbacher's attack today?
(granted, creating the exception on `throw` path only will increase the timing difference)

-------------

PR: https://git.openjdk.org/jdk/pull/12732


From jlu at openjdk.org  Wed Mar 15 16:08:07 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 15 Mar 2023 16:08:07 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>
Message-ID: <_dP9N3UNWa82tfLVEapoSFJjbvMmlyP21ZbuL0NjTDU=.3685af0b-31a0-42aa-86b0-5098bda72766@github.com>

On Tue, 7 Mar 2023 23:15:14 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> make/langtools/tools/compileproperties/CompileProperties.java line 252:
> 
>> 250:             try {
>> 251:                 writer = new BufferedWriter(
>> 252:                         new OutputStreamWriter(new FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));
> 
> Using ISO_8859_1 seems strange.
> Since these are generated files, you could write them as UTF-8 and then override the default javac option for ascii when compiling _just_ these files.
> 
> Or else just stay with ascii; no one should be looking at these files!

Will stick with your latter solution, as since the .properties files were converted via native2ascii, it makes sense to write out via ascii.

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From jjg at openjdk.org  Wed Mar 15 16:08:06 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 15 Mar 2023 16:08:06 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

make/langtools/tools/compileproperties/CompileProperties.java line 252:

> 250:             try {
> 251:                 writer = new BufferedWriter(
> 252:                         new OutputStreamWriter(new FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));

Using ISO_8859_1 seems strange.
Since these are generated files, you could write them as UTF-8 and then override the default javac option for ascii when compiling _just_ these files.

Or else just stay with ascii; no one should be looking at these files!

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From jlu at openjdk.org  Wed Mar 15 16:08:03 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 15 Mar 2023 16:08:03 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
Message-ID: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>

This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.

In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

-------------

Commit messages:
 - Write to ASCII
 - Read in .properties as UTF-8, but write to LRB .java as ISO-8859-1
 - Compile class with ascii (Not ready to make system wide change)
 - Toggle UTF-8 for javac option in JavaCompilation.gmk
 - CompileProperties converts in UTF-8
 - Convert .properties from ISO-8859-1 to UTF-8

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301991
  Stats: 29093 lines in 490 files changed: 6 ins; 0 del; 29087 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726


From duke at openjdk.org  Wed Mar 15 16:21:33 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 15 Mar 2023 16:21:33 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1:

> 1: #

This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files.

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From mullan at openjdk.org  Wed Mar 15 16:59:10 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 15 Mar 2023 16:59:10 GMT
Subject: RFR: 8304264: Debug messages always show up for NativeGSS
In-Reply-To: <06x1PzIDYKRrgGgUT7hXWBYA9e5JBLWtCowNWcHxU7g=.b2f3ca03-de5f-49c4-a050-5c55181d4183@github.com>
References: <06x1PzIDYKRrgGgUT7hXWBYA9e5JBLWtCowNWcHxU7g=.b2f3ca03-de5f-49c4-a050-5c55181d4183@github.com>
Message-ID: <QFLa-cleBHjP_kJvZbJa4XDtZ6yY-w67fKANlEHqkzA=.e4a86308-baed-47a0-a213-312c47f12f11@github.com>

On Wed, 15 Mar 2023 13:44:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Only call `debug()` when `DEBUG` is set.

Is this debug property documented anywhere? If not, perhaps we should add it to the Troubleshooting guide.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13043


From cslucas at openjdk.org  Wed Mar 15 17:20:47 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 15 Mar 2023 17:20:47 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v2]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <8d3LAUIIFVAJIXyrV2YafqAtAe6yiSPUS5THd2VynTk=.006e4cf8-90fe-43ea-8bb3-bbda4d3244f9@github.com>

> Can I please get reviews for this PR to add support for the rematerialization of scalar-replaced objects that participate in allocation merges?
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges that are used *only* as debug information in SafePointNode and its subclasses. Although there is a performance benefit in doing scalar replacement in this scenario only, the goal of this PR is mainly to add infrastructure to support the rematerialization of SR objects participating in merges. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP, Load+AddP, primarily) subsequently.
> 
> The approach I used is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in allocation merges used only as debug information.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression that might be related. I also tested with several applications and didn't see any failure.

Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge master
 - Add support for rematerializing scalar replaced objects participating in allocation merges

-------------

Changes: https://git.openjdk.org/jdk/pull/12897/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=01
  Stats: 1803 lines in 18 files changed: 1653 ins; 9 del; 141 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897


From valeriep at openjdk.org  Wed Mar 15 17:32:21 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Mar 2023 17:32:21 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <yRkx2mkRBhusL4Th7uab0aBg5vhZmMpucR-4ksq-21c=.daefb5b8-166a-49e2-b1a0-10b994a71fe9@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

suspend for now per Xuelei's request.

-------------

PR: https://git.openjdk.org/jdk/pull/12732


From duke at openjdk.org  Wed Mar 15 17:42:44 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 15 Mar 2023 17:42:44 GMT
Subject: Integrated: 8284047: Harmonize/Standardize the
 SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
In-Reply-To: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
References: <N4CsAa7cPmqIaLedqkZ7h205J_anB9WjTdlI1jQ_g3M=.5a516ec7-2a0b-47e2-9132-f40cc0e87ea8@github.com>
Message-ID: <Z72xkEFeW1wGswAjsBmlEBUNrN2W3exxD0M--2cJeV0=.bf4488cb-a8c4-42e7-b059-7ae1ad8d6e93@github.com>

On Tue, 14 Feb 2023 12:17:39 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> * Refactored SSLContextTemplate and SSLSocketTemplate to put common code in one base class (SSLContextTemplate)
> * Updated TLS/SSL tests to extend SSLSocketTemplate where possible.
> * Updated SSLEngineTemplate to accommodate changes in SSLContextTemplate. To keep this changeset to a reasonable size, updates to SSLEngine tests will be made under JDK-8301194.

This pull request has now been integrated.

Changeset: 824a5e4c
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/824a5e4c605d4aee55252bce5364fa01de525e1b
Stats:     4444 lines in 23 files changed: 984 ins; 3158 del; 302 mod

8284047: Harmonize/Standardize the SSLSocket/SSLEngine/SSLSocketSSLEngine test templates

Reviewed-by: rhalade

-------------

PR: https://git.openjdk.org/jdk/pull/12555


From valeriep at openjdk.org  Wed Mar 15 17:43:25 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Mar 2023 17:43:25 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <B5k6T-2_m3F-J8DQ5zgJlUrt_B9pLWy3tM-tqM3LNBE=.266d4de8-f44e-4941-8948-0b8501d4c514@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 138:

> 136:         if (key == null) {
> 137:             throw new InvalidKeyException("Key must not be null");
> 138:         }

Is there a particular reason for removing this code block?

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From duke at openjdk.org  Wed Mar 15 17:57:23 2023
From: duke at openjdk.org (Aliaksei Dubrouski)
Date: Wed, 15 Mar 2023 17:57:23 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <6Fbv3lIBOmB7AAS6PKXPJBs0bkdL5tT0KLn0sg-f6ys=.7b460c80-c926-4d71-baa7-5f602e60e5b2@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

I suggested using constructor with disabled stack trace as a backup option, but this will require refactoring few exception classes related to security package (i.e. currently GeneralSecurityException does not have protected constructor with enableSuppression/writableStackTrace flags) and reviewing all usages of them.

-------------

PR: https://git.openjdk.org/jdk/pull/12732


From valeriep at openjdk.org  Wed Mar 15 18:05:28 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Mar 2023 18:05:28 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <Wxq8UhV2QEt_LiMEUlf1hKF_pLGttTylntM1OpYZizA=.f9ac393b-3f4c-4bb3-aaa2-eaaa72572a7e@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <Wxq8UhV2QEt_LiMEUlf1hKF_pLGttTylntM1OpYZizA=.f9ac393b-3f4c-4bb3-aaa2-eaaa72572a7e@github.com>
Message-ID: <4kSETZwNby-RcFrPodXcGTM6Z2m1tRmebJyGDpOqtMM=.ec402259-bbc7-490d-9707-f37f7660bb8e@github.com>

On Wed, 15 Mar 2023 14:51:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/java.base/share/classes/sun/security/util/PBEUtil.java line 47:
> 
>> 45: 
>> 46:     // Used by SunJCE and SunPKCS11
>> 47:     public final static class PBES2Params {
> 
> This class confuses me. An instance is constructed without any parameter. The method `getPBEKeySpec` is able to mutate it and return something, the method `getAlgorithmParameters` is able to read the content and possibly mutate again and return something, and finally another method `getIvSpec` is able to return the content.
> 
> Please either precisely document how these methods will be called and enforce this rule with internal checks, or refactor it to something immutable.

+1.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From cslucas at openjdk.org  Wed Mar 15 18:06:58 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 15 Mar 2023 18:06:58 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v3]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <yuu55rxPYLO4QMsl23TdWsgL_y-rT31uTCbgrlYOlys=.a2e3aec8-63cb-40fc-9fb1-fcc251c20907@github.com>

> Can I please get reviews for this PR to add support for the rematerialization of scalar-replaced objects that participate in allocation merges?
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges that are used *only* as debug information in SafePointNode and its subclasses. Although there is a performance benefit in doing scalar replacement in this scenario only, the goal of this PR is mainly to add infrastructure to support the rematerialization of SR objects participating in merges. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP, Load+AddP, primarily) subsequently.
> 
> The approach I used is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in allocation merges used only as debug information.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression that might be related. I also tested with several applications and didn't see any failure.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Fix some typos and do some small refactorings.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/ea67a304..3b492d2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=01-02

  Stats: 72 lines in 8 files changed: 1 ins; 7 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897


From cslucas at openjdk.org  Wed Mar 15 18:11:28 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 15 Mar 2023 18:11:28 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <EGE2YA2K7rESOJXc3Si-PpffxWREq15o7flK-Cp8OM4=.68858f36-35c6-4952-a33f-cd12eb70440e@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

I may be wrong here but my take on this is that there is nothing at the language level that prevents the compiler from optimizing the code and moving the allocation inside the "If". In fact, GRAAL might as well be doing this as part of Partial Escape Analysis.

-------------

PR: https://git.openjdk.org/jdk/pull/12732


From duke at openjdk.org  Wed Mar 15 19:07:28 2023
From: duke at openjdk.org (Aliaksei Dubrouski)
Date: Wed, 15 Mar 2023 19:07:28 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <EGE2YA2K7rESOJXc3Si-PpffxWREq15o7flK-Cp8OM4=.68858f36-35c6-4952-a33f-cd12eb70440e@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
 <EGE2YA2K7rESOJXc3Si-PpffxWREq15o7flK-Cp8OM4=.68858f36-35c6-4952-a33f-cd12eb70440e@github.com>
Message-ID: <6YHyfyXhXdvCbME9bKjy_OHenaQlTbYiHOzrfL4jdAE=.55af25bd-276a-4dde-a05e-a9b705c0bb6d@github.com>

On Wed, 15 Mar 2023 18:08:20 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> I may be wrong here but my take on this is that there is nothing at the language level that prevents the compiler from optimizing the code and moving the allocation inside the "If". In fact, GRAAL might as well be doing this as part of Partial Escape Analysis.

Escape analysis does not work for conditionals. Microsoft JVM team is currently working on this feature, but it is still experimental.

-------------

PR: https://git.openjdk.org/jdk/pull/12732


From naoto at openjdk.org  Wed Mar 15 20:23:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Mar 2023 20:23:23 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156:

> 154: zh=\u00A4
> 155: zh_CN=\uFFE5
> 156: zh_HK=HK$

Why are they not encoded into UTF-8 native?

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From weijun at openjdk.org  Wed Mar 15 21:26:39 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Mar 2023 21:26:39 GMT
Subject: RFR: 8304264: Debug messages always show up for NativeGSS
In-Reply-To: <QFLa-cleBHjP_kJvZbJa4XDtZ6yY-w67fKANlEHqkzA=.e4a86308-baed-47a0-a213-312c47f12f11@github.com>
References: <06x1PzIDYKRrgGgUT7hXWBYA9e5JBLWtCowNWcHxU7g=.b2f3ca03-de5f-49c4-a050-5c55181d4183@github.com>
 <QFLa-cleBHjP_kJvZbJa4XDtZ6yY-w67fKANlEHqkzA=.e4a86308-baed-47a0-a213-312c47f12f11@github.com>
Message-ID: <LHS5-OxZVp2F7RktxbG577vVkPltOLRETXJt8cB43f4=.8a6d08e4-fb90-47fe-ba9f-dd8b61f6505a@github.com>

On Wed, 15 Mar 2023 16:56:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Is this debug property documented anywhere? If not, perhaps we should add it to the Troubleshooting guide.

We can add it to the "Accessing Native GSS-API" page. There is an existing "Troubleshooting" but it's inside the part about using JGSS with JAAS. Native GSS should not be used with JAAS.

-------------

PR: https://git.openjdk.org/jdk/pull/13043


From weijun at openjdk.org  Wed Mar 15 21:26:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Mar 2023 21:26:40 GMT
Subject: Integrated: 8304264: Debug messages always show up for NativeGSS
In-Reply-To: <06x1PzIDYKRrgGgUT7hXWBYA9e5JBLWtCowNWcHxU7g=.b2f3ca03-de5f-49c4-a050-5c55181d4183@github.com>
References: <06x1PzIDYKRrgGgUT7hXWBYA9e5JBLWtCowNWcHxU7g=.b2f3ca03-de5f-49c4-a050-5c55181d4183@github.com>
Message-ID: <F4D66UpDSAZvdd0ti2jnkHG0QQAmsVaVM-HcF9lMJwQ=.80376e2c-e42f-46b8-8722-3761cc376e50@github.com>

On Wed, 15 Mar 2023 13:44:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Only call `debug()` when `DEBUG` is set.

This pull request has now been integrated.

Changeset: be08a256
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be08a256ab8abab63ec9070342fb5ee46f00219b
Stats:     61 lines in 5 files changed: 29 ins; 0 del; 32 mod

8304264: Debug messages always show up for NativeGSS

Reviewed-by: mullan

-------------

PR: https://git.openjdk.org/jdk/pull/13043


From valeriep at openjdk.org  Wed Mar 15 23:01:23 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Mar 2023 23:01:23 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <PI-62B3AsalftkBJVpX1uw1elgUcOHyPLECRHaAADY4=.fe33d6e3-7f31-4081-bc37-df40b49a1550@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 233:

> 231:                 CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN, 512));
> 232:         putKeyInfo(new P12MacPBEKeyInfo("HmacPBESHA512/256",
> 233:                 CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN, 512));

Are these key lengths really 512? Or should they match the output size as in other key infos?

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From valeriep at openjdk.org  Thu Mar 16 00:38:22 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Mar 2023 00:38:22 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <-VwQey673TTv5yVqw7HN7qrbf9VPIifcCxqRQvEfkp0=.1ad683d8-9deb-456d-828d-613cc011550f@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 70:

> 68:     private final String algorithm;
> 69: 
> 70:     // PBEKeyInfo if algorithm is PBE, otherwise null

nit: PBE-related, not just PBE.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From valeriep at openjdk.org  Thu Mar 16 00:49:30 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Mar 2023 00:49:30 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <aCC9GaM4mD4QRd2sSRKB8P80gjaRlgekM0y-_xXnp6k=.4bf9fe42-6696-44a7-b03d-2b008fc1a19f@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 204:

> 202:         if (svcPbeKi != null) {
> 203:             if (key instanceof P11Key) {
> 204:                 params = PBEUtil.checkKeyParams(key, params, algorithm);

It seems strange that you check the key to be instanceof P11Key but then inside PBEUtil.checkKeyParams, it errors out if the key instanceof PBEKey. Maybe you meant to check if the key is an instanceof P11PBEKey? Could the key be a PBEKey but not P11Key and contains more than just password? I don't quite follow the logic here.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From valeriep at openjdk.org  Thu Mar 16 00:56:33 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Mar 2023 00:56:33 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <PE7O8-rnZmhz3_THUqFsK5qA0wviqv63Kb9bCSPhL84=.e206246d-43ea-4116-84a1-7ca6d5617605@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 223:

> 221:             }
> 222:             p11Key = P11SecretKeyFactory.convertKey(token, key, algorithm);
> 223:         }

Is this meant to handle Non-PBE-related case? The logic here seems conflicting with the above code block where the params must be null. Also if key is instanceof P11Key already, why are you calling P11SecretKeyFactory.convertKey(...) again? Strange.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbaesken at openjdk.org  Thu Mar 16 13:33:18 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 16 Mar 2023 13:33:18 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <jHO6Zyz2qap55fzosMaR1nZ4u-_REX_JSzQg1RFyjAI=.5656976f-b483-4fef-8a4a-528ce3b4706c@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
 <vLV4oiv5Sx_3PFGbI-mUZNn0tc3cDeZRtKyEW2eVE44=.7746b72c-9809-4637-9785-c75ca1076033@github.com>
 <jHO6Zyz2qap55fzosMaR1nZ4u-_REX_JSzQg1RFyjAI=.5656976f-b483-4fef-8a4a-528ce3b4706c@github.com>
Message-ID: <LOskeKNPhqAITNXQKYFgYd1PU2bHYFPxmBZEvKaTkE4=.0bb43015-b0ea-4aeb-995b-b3563a8f3681@github.com>

On Tue, 7 Mar 2023 17:32:15 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I'll think about it more and discuss with my colleagues.

Hi Weijun, is there some news from your colleagues ?

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From weijun at openjdk.org  Thu Mar 16 14:57:20 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Mar 2023 14:57:20 GMT
Subject: RFR: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <LOskeKNPhqAITNXQKYFgYd1PU2bHYFPxmBZEvKaTkE4=.0bb43015-b0ea-4aeb-995b-b3563a8f3681@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
 <vLV4oiv5Sx_3PFGbI-mUZNn0tc3cDeZRtKyEW2eVE44=.7746b72c-9809-4637-9785-c75ca1076033@github.com>
 <jHO6Zyz2qap55fzosMaR1nZ4u-_REX_JSzQg1RFyjAI=.5656976f-b483-4fef-8a4a-528ce3b4706c@github.com>
 <LOskeKNPhqAITNXQKYFgYd1PU2bHYFPxmBZEvKaTkE4=.0bb43015-b0ea-4aeb-995b-b3563a8f3681@github.com>
Message-ID: <_-0KsiU5vo_SIA1fLYTabAuq-8azpd__Xmf55N1Z4QA=.1ddf5576-1ab1-441e-844c-5679a251174d@github.com>

On Thu, 16 Mar 2023 13:30:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > I'll think about it more and discuss with my colleagues.
> 
> Hi Weijun, is there some news from your colleagues ?

Done some experiments. I'll contact you offline.

-------------

PR: https://git.openjdk.org/jdk/pull/12829


From jlu at openjdk.org  Thu Mar 16 18:19:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:19:29 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with four additional commits since the last revision:

 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/1e798f24..6d6bffe8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00-01

  Stats: 92 lines in 4 files changed: 0 ins; 0 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726


From jlu at openjdk.org  Thu Mar 16 18:21:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:40 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>
Message-ID: <CRTgRmg-NKyRb1XyeIcUdbz-JgoZE9nUJ6hBHsRIvLk=.c4614e2d-ec44-40fa-a88d-41c2b94b12bb@github.com>

On Thu, 16 Mar 2023 18:19:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1:

> 1: #

Conversion did not work as expected, addressing right now.

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From jlu at openjdk.org  Thu Mar 16 18:21:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:43 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>
Message-ID: <Pns4G-crmY2QuscU_BkwBA2hXFMN3VQMdzc-UWVKPDU=.d20ab56a-ca0f-45aa-9a2d-361b532281ed@github.com>

On Wed, 15 Mar 2023 20:19:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>
> test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156:
> 
>> 154: zh=\u00A4
>> 155: zh_CN=\uFFE5
>> 156: zh_HK=HK$
> 
> Why are they not encoded into UTF-8 native?

Not sure, thank you for catching it. Working on it right now.

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From jlu at openjdk.org  Thu Mar 16 18:21:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:46 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>
Message-ID: <_6WBGo5CQBseDEjMv16qCWmodFlYOO4gsT9WbON7ddA=.f94339a4-8893-47e4-8bb1-f28a8807ad9d@github.com>

On Wed, 15 Mar 2023 16:18:44 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>
> test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1:
> 
>> 1: #
> 
> This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files.

Thank you, removed the changes for this file

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From jlu at openjdk.org  Thu Mar 16 18:35:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:35:51 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v3]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/6d6bffe8..7119830b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=01-02

  Stats: 87 lines in 1 file changed: 0 ins; 0 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726


From jlu at openjdk.org  Thu Mar 16 18:35:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:35:54 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v3]
In-Reply-To: <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>
Message-ID: <XFZBHgkji9zthsA9wOP-bDqbf7PTVoKJzNXHDR1pThQ=.a99810cd-d764-40ee-9699-b234d6583007@github.com>

On Thu, 16 Mar 2023 18:31:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1:

> 1: #

CurrencySymbols.properties is fully converted to UTF-8 now

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From mbalao at openjdk.org  Fri Mar 17 15:34:15 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 17 Mar 2023 15:34:15 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <TyLb9DhpT9FM44g5i6LINM9oF7_utLHWttDakSI5XkE=.52e3e90d-b650-405e-9c44-575180b6d7b0@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <TyLb9DhpT9FM44g5i6LINM9oF7_utLHWttDakSI5XkE=.52e3e90d-b650-405e-9c44-575180b6d7b0@github.com>
Message-ID: <6J123-8IwFqhbSAaEdCbqTyZm664aCg9cydem3VliqI=.f5e874b6-d683-4a8c-af14-4d2e193f991e@github.com>

On Mon, 27 Feb 2023 22:51:58 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h line 71:
> 
>> 69: 
>> 70: #define CKA_NETSCAPE_BASE                       (0x80000000 + 0x4E534350)
>> 71: /*             ^ now known as CKM_NSS   (CKM_VENDOR_DEFINED | NSSCK_VENDOR_NSS) */
> 
> nit: "                ^" part seems un-necessary.

Good.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Fri Mar 17 15:51:10 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 17 Mar 2023 15:51:10 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <hrOv6KCpuxmj8elN6U67d-wBF-ogqcaO13uwIj-KJkw=.a64470ee-d871-424c-b17f-11ac5ced742d@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <hrOv6KCpuxmj8elN6U67d-wBF-ogqcaO13uwIj-KJkw=.a64470ee-d871-424c-b17f-11ac5ced742d@github.com>
Message-ID: <gooHoubcL5geL0QQ8J3qTVpkIi9k4Tm8o_VDZHsqSpc=.774f5b96-cf03-4878-99e0-56faa79dbf91@github.com>

On Fri, 10 Mar 2023 00:26:07 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/java.base/share/classes/sun/security/util/PBEUtil.java line 59:
> 
>> 57:         }
>> 58: 
>> 59:         public AlgorithmParameters getAlgorithmParameters(int blkSize,
> 
> I see most if not all of the methods in this class are lifted from other classes as the result of code refactoring. Would be nice to document its callers, e.g. where it's used.

I added references, that include the security provider and class, to each method and inner class in PBEUtil. The instance methods in PBEUtil$PBES2Params use the reference for their containing class. Let me know if you still want to repeat the reference for each one.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Fri Mar 17 15:55:21 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 17 Mar 2023 15:55:21 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <scqJMmGR4QWeeUgpyExdgshjwBXlFX1GNMkx-YQvVYU=.c5ec3c01-8c77-474b-8b2e-70bcbdbbbe5b@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <scqJMmGR4QWeeUgpyExdgshjwBXlFX1GNMkx-YQvVYU=.c5ec3c01-8c77-474b-8b2e-70bcbdbbbe5b@github.com>
Message-ID: <MPmobeb0v_uGTkUgnQT6bnYxjXNm7jtayrO_kiOUWi8=.cc8f4246-509e-490b-a3d7-37d11bbba1f1@github.com>

On Sat, 11 Mar 2023 01:18:04 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 492:
> 
>> 490:                 getAliases(algorithm), m, requiredMechs));
>> 491:     }
>> 492: 
> 
> nit: move this to after the other dA(String, String, String, int[]) below

Good

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Fri Mar 17 18:42:07 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 17 Mar 2023 18:42:07 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <TD1dnLJemziz3u9qprp6nrWRdQ-f523Iu3q9cn_Bk5I=.b3bd7cdf-7080-47bb-bdb5-aa30dba6543e@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <TD1dnLJemziz3u9qprp6nrWRdQ-f523Iu3q9cn_Bk5I=.b3bd7cdf-7080-47bb-bdb5-aa30dba6543e@github.com>
Message-ID: <F7uuNazHYAzLPXDhGau4iyXqPZAlxmNdsLO0rFqKYqI=.fb2dd3b9-1dca-472b-b3d0-b83a5db117ac@github.com>

On Sat, 11 Mar 2023 05:51:09 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 83:
> 
>> 81:          *     PKCS #11 call (bytes) => [ 0x00,   0x61,   0x00,   0x00 ]
>> 82:          */
>> 83:         byte[] passwordBytes = new String(password).getBytes(cs);
> 
> Best to not storing the password into a String object. Perhaps use a CharBuffer?

Good

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Fri Mar 17 18:50:10 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 17 Mar 2023 18:50:10 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <GfqlKRQwmaMxrE4PWjkyuYsLYHOJwCsV8zkYrdE_afU=.81d1cb47-c51b-4807-8728-cb5da459472f@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <GfqlKRQwmaMxrE4PWjkyuYsLYHOJwCsV8zkYrdE_afU=.81d1cb47-c51b-4807-8728-cb5da459472f@github.com>
Message-ID: <8heA0vFfV7UuICs4I-shKUhHBp8tncd8q6nc2XrbGko=.f48f006a-4f12-4c39-be6a-b08aaa4f81c9@github.com>

On Mon, 13 Mar 2023 19:30:54 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java line 1152:
> 
>> 1150:     public static final long  CKP_PKCS5_PBKD2_HMAC_SHA512_224  = 0x00000007L;
>> 1151:     public static final long  CKP_PKCS5_PBKD2_HMAC_SHA512_256  = 0x00000008L;
>> 1152: 
> 
> nit: instead of moving these PBKDF2 constants out of the commented section, how about preserving the ordering and just break the commented section into two sections? IIRC, this is easier to check/compare to pkcs11t.h by following the same order.

Good

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Fri Mar 17 19:34:53 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 17 Mar 2023 19:34:53 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <UTH0vH0iqc4pRJKIjOCCDRTUy20Lgfg4l82T5nvLnWI=.665605d4-8232-4cd3-b456-a091ea3ebd14@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <UTH0vH0iqc4pRJKIjOCCDRTUy20Lgfg4l82T5nvLnWI=.665605d4-8232-4cd3-b456-a091ea3ebd14@github.com>
Message-ID: <pX0y61cnn1uG8890huEyFsstcJ0EzrwHLrC-00X8E8U=.be869ded-cdc7-479c-a3eb-89035de1fd54@github.com>

On Tue, 14 Mar 2023 00:51:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c line 423:
> 
>> 421:                  case CKM_NSS_PKCS12_PBE_SHA256_HMAC_KEY_GEN:
>> 422:                  case CKM_NSS_PKCS12_PBE_SHA384_HMAC_KEY_GEN:
>> 423:                  case CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN:
> 
> How about CKM_PBE_SHA1_DES3_EDE_CBC and CKM_PBE_SHA1_DES2_EDE_CBC?

Good point. While CKM_PBE_SHA1_DES3_EDE_CBC and CKM_PBE_SHA1_DES2_EDE_CBC mechanisms were never supported, there was dead code in jMechParamToCKMechParamPtrSlow (p11_convert.c) for them before this enhancement proposal. In fact, CK_PBE_PARAMS (Java and C classes) existed without any uses, probably added for the sake of comprehensiveness. This code had issues that we had to fix when actually using it. It's not our intention to include legacy derivation mechanisms, such as PBEWithSHA1AndDESede, at this time in the scope. I'll propose to remove all references to CKM_PBE_SHA1_DES3_EDE_CBC and CKM_PBE_SHA1_DES2_EDE_CBC in jMechParamToCKMechParamPtrSlow so it don't lead to confusion.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From jlu at openjdk.org  Fri Mar 17 20:28:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Mar 2023 20:28:13 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Adjust CF test to read in with UTF-8 to fix failing test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/7119830b..007c78a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=02-03

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726


From angorya at openjdk.org  Fri Mar 17 20:34:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 17 Mar 2023 20:34:00 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
Message-ID: <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>

On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust CF test to read in with UTF-8 to fix failing test

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 226:

> 224:         Properties p = new Properties();
> 225:         try {
> 226:             FileInputStream input = new FileInputStream(propertiesPath);

Should this stream be closed in a finally { } block?

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From naoto at openjdk.org  Fri Mar 17 21:05:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Mar 2023 21:05:18 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
 <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>
Message-ID: <qJO-EntPnPd5u6rdRknlaAFlfED0JHmr5CXahe0N4oY=.fae98578-e8b4-4387-bd72-acf3cf871a40@github.com>

On Fri, 17 Mar 2023 20:31:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust CF test to read in with UTF-8 to fix failing test
>
> make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 226:
> 
>> 224:         Properties p = new Properties();
>> 225:         try {
>> 226:             FileInputStream input = new FileInputStream(propertiesPath);
> 
> Should this stream be closed in a finally { } block?

or better be `try-with-resources`?

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From weijun at openjdk.org  Fri Mar 17 21:52:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Mar 2023 21:52:23 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
Message-ID: <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>

On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust CF test to read in with UTF-8 to fix failing test

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 326:

> 324:                         outBuffer.append(toHex((aChar >> 8) & 0xF));
> 325:                         outBuffer.append(toHex((aChar >> 4) & 0xF));
> 326:                         outBuffer.append(toHex(aChar & 0xF));

Sorry I don't know when this tool is called, but why is it still writing in `\unnnn` style?

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From weijun at openjdk.org  Fri Mar 17 21:56:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Mar 2023 21:56:23 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
 <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>
Message-ID: <whhHbwzCZGIvBavtXFqc5Ari9SWIQg-BwdyP3t89Rcg=.d8dc3f56-857d-4265-a54d-9fdb5a59c96a@github.com>

On Fri, 17 Mar 2023 21:49:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust CF test to read in with UTF-8 to fix failing test
>
> make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 326:
> 
>> 324:                         outBuffer.append(toHex((aChar >> 8) & 0xF));
>> 325:                         outBuffer.append(toHex((aChar >> 4) & 0xF));
>> 326:                         outBuffer.append(toHex(aChar & 0xF));
> 
> Sorry I don't know when this tool is called, but why is it still writing in `\unnnn` style?

I probably understand it now, source code still needs escaping. When can we put in UTF-8 there as well?

-------------

PR: https://git.openjdk.org/jdk/pull/12726


From mchung at openjdk.org  Fri Mar 17 22:08:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 17 Mar 2023 22:08:56 GMT
Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the
 test library
Message-ID: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>

`ModuleInfoWriter` is not used by the runtime.   Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`.   The tests are updated to use the test library instead.   `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API.   Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added.

-------------

Commit messages:
 - JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library

Changes: https://git.openjdk.org/jdk/pull/13085/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13085&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304163
  Stats: 146 lines in 17 files changed: 87 ins; 15 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/13085.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13085/head:pull/13085

PR: https://git.openjdk.org/jdk/pull/13085


From jlu at openjdk.org  Fri Mar 17 22:27:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Mar 2023 22:27:48 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Close streams when finished loading into props

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/007c78a7..19b91e6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=03-04

  Stats: 15 lines in 3 files changed: 6 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726


From jpai at openjdk.org  Sat Mar 18 00:34:20 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 Mar 2023 00:34:20 GMT
Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the
 test library
In-Reply-To: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
References: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
Message-ID: <XVIIhzIHDSCettjbde92pQUD4HcHyReLURk5N-02rWY=.fcedd1e2-f288-45a0-8a61-12e217b0ba23@github.com>

On Fri, 17 Mar 2023 22:01:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `ModuleInfoWriter` is not used by the runtime.   Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`.   The tests are updated to use the test library instead.   `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API.   Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added.

The changes look good to me

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13085


From mbalao at openjdk.org  Sat Mar 18 05:33:27 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 18 Mar 2023 05:33:27 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <rTsBN7F8NGYUJbAU7fvq15O4A9etgByp3LLYDUKdy_Q=.352642f7-ab76-428c-89d9-38070706a74f@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <rTsBN7F8NGYUJbAU7fvq15O4A9etgByp3LLYDUKdy_Q=.352642f7-ab76-428c-89d9-38070706a74f@github.com>
Message-ID: <EvLPnY3mzkQSvXUYu_btBifigrwRwc1_wkTmLKfldOw=.ed0000af-9021-45fe-a800-2973539c7cca@github.com>

On Tue, 14 Mar 2023 17:07:52 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c line 1825:
> 
>> 1823:         paramVersion = PARAMS2;
>> 1824:     } else {
>> 1825:         return NULL;
> 
> Instead of returning NULL, should some exception be thrown to indicate that there is a problem with the specified parameter (not the expected type)?

Good idea, so the native call with a null CK_MECHANISM pParameter is avoided. This path should never happen, though.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Sat Mar 18 06:11:23 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 18 Mar 2023 06:11:23 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <o4jO-b-vE8vC-jKTSkihgwmWT5BFzziCarzD3cBt0Cc=.4d404289-38be-4aa4-ac4d-eea0eb9385d1@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <o4jO-b-vE8vC-jKTSkihgwmWT5BFzziCarzD3cBt0Cc=.4d404289-38be-4aa4-ac4d-eea0eb9385d1@github.com>
Message-ID: <9vhl91MVfHBn3WB948uVAZZmdy4RWzkww60nou0Slxo=.6fccc136-1858-41df-8c62-91a654655878@github.com>

On Wed, 15 Mar 2023 00:32:09 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 118:
> 
>> 116:                 return true;
>> 117:             }
>> 118:             return ki.keyType == si.keyType;
> 
> So, for non-PBE key info, algos do not have to match?

For services and keys cases in which algorithms identity-match ?irrespective if they are PBE or non-PBE?, KeyInfo::checkUse is not called and execution moves forward as if the check passed (see [here](https://github.com/openjdk/jdk/blob/ab7ffd56bb8b93d513023d0136df55a6375c3286/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L285)). The same is true for services that accept any key type, such as those whose pseudo types are PCKK_HMAC or PCKK_SSLMAC.

The ki.keyType == si.keyType success value affects cases in which algorithms are different but it's still possible to use the key in the service. One example that would hit this path is a PBE key derived for AES that it's used in an AES Cipher service. For non-PBE keys and services cases, one example is algorithms "RC4" and "ARCFOUR" that have both the underlying CKK_RC4 key type. Notice that this latter case is not new: previous to this enhancement proposal, key types were compared as well (see [here](https://github.com/openjdk/jdk/blob/jdk-21%2B14/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L147)).

For non-PBE keys and services cases, what is new with this enhancement is to accept them if their algorithms are identity-equal. This condition necessarily means that key types are equal ?the opposite is obviously not true?. One minor detail, when we refer to the algorithms equality trivial pass condition, it's an object identity comparison for performance.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Sat Mar 18 06:16:23 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 18 Mar 2023 06:16:23 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <4qzwDcl0k34UtSTQE4QH9lgGj7wkseCQvFPiUCvDdJU=.a363d756-d0ac-432b-a479-fed871b6823e@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <4qzwDcl0k34UtSTQE4QH9lgGj7wkseCQvFPiUCvDdJU=.a363d756-d0ac-432b-a479-fed871b6823e@github.com>
Message-ID: <IN7NZn0LkFz9UOH6xCXAeOcSDVS_jEFr1ChefTg7Cxk=.a9787301-366a-4ac5-815c-5d1f61c19cd1@github.com>

On Wed, 15 Mar 2023 00:47:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 239:
> 
>> 237:         long kt = getKeyType(algorithm);
>> 238:         if (kt == -1 || kt > PCKK_ANY) {
>> 239:             // Replace pseudo key type.
> 
> Well, it seems clearer to have the "No pseudo key types" comment as method comment.

Ok, moved as a method comment and replaced by the suggested wording.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Sat Mar 18 06:25:25 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 18 Mar 2023 06:25:25 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <B5k6T-2_m3F-J8DQ5zgJlUrt_B9pLWy3tM-tqM3LNBE=.266d4de8-f44e-4941-8948-0b8501d4c514@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <B5k6T-2_m3F-J8DQ5zgJlUrt_B9pLWy3tM-tqM3LNBE=.266d4de8-f44e-4941-8948-0b8501d4c514@github.com>
Message-ID: <csIvXeHGMzaGHLIINbMx37K6eIceSVsAxUKHWvukHF0=.43a3b9d2-669f-4b73-99bc-8110b8843202@github.com>

On Wed, 15 Mar 2023 17:40:27 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 138:
> 
>> 136:         if (key == null) {
>> 137:             throw new InvalidKeyException("Key must not be null");
>> 138:         }
> 
> Is there a particular reason for removing this code block?

Key has to be an instance of SecretKey (see [here](https://github.com/openjdk/jdk/blob/ab7ffd56bb8b93d513023d0136df55a6375c3286/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L268)), so a ```null``` value would lead to an InvalidKeyException anyways. We proposed to remove it in the interest of simplifying/shortening the code.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Sat Mar 18 06:29:24 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 18 Mar 2023 06:29:24 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <-VwQey673TTv5yVqw7HN7qrbf9VPIifcCxqRQvEfkp0=.1ad683d8-9deb-456d-828d-613cc011550f@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <-VwQey673TTv5yVqw7HN7qrbf9VPIifcCxqRQvEfkp0=.1ad683d8-9deb-456d-828d-613cc011550f@github.com>
Message-ID: <8RdWOvnyny0gQSo59kNbCNV4YXlBoptiKfc4ial996c=.e01eeee4-b5d9-4387-92d8-3da627a4935c@github.com>

On Thu, 16 Mar 2023 00:35:54 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 70:
> 
>> 68:     private final String algorithm;
>> 69: 
>> 70:     // PBEKeyInfo if algorithm is PBE, otherwise null
> 
> nit: PBE-related, not just PBE.

Good

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Sat Mar 18 06:52:25 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 18 Mar 2023 06:52:25 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <PI-62B3AsalftkBJVpX1uw1elgUcOHyPLECRHaAADY4=.fe33d6e3-7f31-4081-bc37-df40b49a1550@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <PI-62B3AsalftkBJVpX1uw1elgUcOHyPLECRHaAADY4=.fe33d6e3-7f31-4081-bc37-df40b49a1550@github.com>
Message-ID: <cHmiH-s_TlSlFd5nh2tJXh1gq802oz_Oeyai_WSARs4=.68b271e2-0bd9-4d53-8c68-e2e95e623006@github.com>

On Wed, 15 Mar 2023 22:58:51 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 233:
> 
>> 231:                 CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN, 512));
>> 232:         putKeyInfo(new P12MacPBEKeyInfo("HmacPBESHA512/256",
>> 233:                 CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN, 512));
> 
> Are these key lengths really 512? Or should they match the output size as in other key infos?

Good question. Looks like a bug. The values should probably be 224 and 256 respectively (output sizes). @franferrax what do you think? We can trace the CKA_VALUE_LEN for these mechanisms in the NSS Software Token to verify it. Also, we should explore if it's possible to add a test for HmacPBESHA512/224 and HmacPBESHA512/256 to TestPBKD. I'll make the change but leave this comment open until we further explore.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Sat Mar 18 06:57:24 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 18 Mar 2023 06:57:24 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <cHmiH-s_TlSlFd5nh2tJXh1gq802oz_Oeyai_WSARs4=.68b271e2-0bd9-4d53-8c68-e2e95e623006@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <PI-62B3AsalftkBJVpX1uw1elgUcOHyPLECRHaAADY4=.fe33d6e3-7f31-4081-bc37-df40b49a1550@github.com>
 <cHmiH-s_TlSlFd5nh2tJXh1gq802oz_Oeyai_WSARs4=.68b271e2-0bd9-4d53-8c68-e2e95e623006@github.com>
Message-ID: <J-1IjhoPmgvbR2O_-g8FiokhclnfnjskR__qQKJ9mRI=.a00e587f-e124-498d-a565-896bad7dd479@github.com>

On Sat, 18 Mar 2023 06:49:20 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 233:
>> 
>>> 231:                 CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN, 512));
>>> 232:         putKeyInfo(new P12MacPBEKeyInfo("HmacPBESHA512/256",
>>> 233:                 CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN, 512));
>> 
>> Are these key lengths really 512? Or should they match the output size as in other key infos?
>
> Good question. Looks like a bug. The values should probably be 224 and 256 respectively (output sizes). @franferrax what do you think? We can trace the CKA_VALUE_LEN for these mechanisms in the NSS Software Token to verify it. Also, we should explore if it's possible to add a test for HmacPBESHA512/224 and HmacPBESHA512/256 to TestPBKD. I'll make the change but leave this comment open until we further explore.

I just realized that the underlying native mechanism is the same so I'm not even sure that the NSS Software Token will truncate the output as we expect. This reinforces the need for further exploration and testing. We may need to remove support for these algorithms.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Sat Mar 18 07:21:26 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 18 Mar 2023 07:21:26 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <aCC9GaM4mD4QRd2sSRKB8P80gjaRlgekM0y-_xXnp6k=.4bf9fe42-6696-44a7-b03d-2b008fc1a19f@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <aCC9GaM4mD4QRd2sSRKB8P80gjaRlgekM0y-_xXnp6k=.4bf9fe42-6696-44a7-b03d-2b008fc1a19f@github.com>
Message-ID: <1VkOwD0SqUUl__B6-ejTqNqhDVb-k_5-tNOSRGwtHD8=.6c88e94b-b159-4619-8a63-e4980724b59b@github.com>

On Thu, 16 Mar 2023 00:46:58 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 204:
> 
>> 202:         if (svcPbeKi != null) {
>> 203:             if (key instanceof P11Key) {
>> 204:                 params = PBEUtil.checkKeyParams(key, params, algorithm);
> 
> It seems strange that you check the key to be instanceof P11Key but then inside PBEUtil.checkKeyParams, it errors out if the key instanceof PBEKey. Maybe you meant to check if the key is an instanceof P11PBEKey? Could the key be a PBEKey but not P11Key and contains more than just password? I don't quite follow the logic here.

We can only pass PBEKey keys to PBE Mac services.

If the key is a P11Key (PBEKey + P11Key == P11PBEKey), derivation is not needed. We just check that the P11Key came from a PBE derivation inside PBEUtil.checkKeyParams and that's it. This is for consistency enforcement only: the token does not care the P11Key origin as long as it has the right attributes to calculate the HMAC.

If the key is not a P11Key, we have to derive it. We just check that the key implements the PBEKey interface, so there is data for derivation. The derived key will be a P11Key (in particular, a P11PBEKey).

Thus, the ```if``` [here](https://github.com/openjdk/jdk/blob/ab7ffd56bb8b93d513023d0136df55a6375c3286/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java#L203) should be read as: are we receiving an already derived key (true) or do we have to derive it (false)? In any case, apply the corresponding checks and move forward.

I'll add a comment to the code to make this logic more clear.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Sat Mar 18 07:56:27 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 18 Mar 2023 07:56:27 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <PE7O8-rnZmhz3_THUqFsK5qA0wviqv63Kb9bCSPhL84=.e206246d-43ea-4116-84a1-7ca6d5617605@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <PE7O8-rnZmhz3_THUqFsK5qA0wviqv63Kb9bCSPhL84=.e206246d-43ea-4116-84a1-7ca6d5617605@github.com>
Message-ID: <CXO0EbZSll2DBmYq5YHtTyqST8mffHstl_MLQRfk0Gc=.7c4a7ced-0abe-4aec-b4b9-c253ea266611@github.com>

On Thu, 16 Mar 2023 00:54:01 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 223:
> 
>> 221:             }
>> 222:             p11Key = P11SecretKeyFactory.convertKey(token, key, algorithm);
>> 223:         }
> 
> Is this meant to handle Non-PBE-related case? The logic here seems conflicting with the above code block where the params must be null. Also if key is instanceof P11Key already, why are you calling P11SecretKeyFactory.convertKey(...) again? Strange.

The quoted block handles non-PBE cases (svcPbeKi == null) and PBE cases in which the derivation was not required (svcPbeKi != null && key instanceof P11Key). The only cases left out of the block are PBE ones in which the key had to be derived because no conversion is needed.

If we enter the block in the non-PBE case, params must be null like before to this enhancement (see [here](https://github.com/openjdk/jdk/blob/jdk-21%2B14/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java#L195)).

If we enter the block in the PBE case (derivation not required), params is what PBEUtil::checkKeyParams returned. This function returns the PBEParameterSpec::paramSpec field of the passed PBEParameterSpec instance, which is always null except for the PBE Cipher cases in which the IV can be specified. Given that this is a Mac service, a non-null value there is not expected. We check this for consistency.

We are calling P11SecretKeyFactory::convertKey if the key is a P11Key because it might be a P11Key from a token different than the P11Mac service one (the condition [here](https://github.com/openjdk/jdk/blob/ab7ffd56bb8b93d513023d0136df55a6375c3286/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L294) could be false). If that's the case, a new derivation in the P11Mac service token will be done. Notice that this is a little caveat to my previous comment [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1140958830): a P11Key might still require a derivation.

I'll add comments to the code to make this more clear.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From alanb at openjdk.org  Sat Mar 18 10:59:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 18 Mar 2023 10:59:19 GMT
Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the
 test library
In-Reply-To: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
References: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
Message-ID: <ZxR48BJKLwmxYsLXLo-IXGJ-lvmxg0WPePsgId0JFkA=.6aba5283-2855-471c-8a28-a44e52f5096b@github.com>

On Fri, 17 Mar 2023 22:01:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `ModuleInfoWriter` is not used by the runtime.   Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`.   The tests are updated to use the test library instead.   `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API.   Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added.

Thanks for moving this to the test lib.

On the tag ordering, the reason some of these tests had @modules before @library was just to recommend ordering in the tag tag spec (https://openjdk.org/jtreg/tag-spec.html#ORDER).

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13085


From mchung at openjdk.org  Sat Mar 18 19:14:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 18 Mar 2023 19:14:09 GMT
Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the
 test library [v2]
In-Reply-To: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
References: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
Message-ID: <akJtaSAAKeTaoWdkwC9RXCTaw60vcG1tC0pptq_Q-vU=.c5f07395-1549-43a2-b6ac-d56a1f549459@github.com>

> `ModuleInfoWriter` is not used by the runtime.   Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`.   The tests are updated to use the test library instead.   `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API.   Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  move @library after @modules per the recommended ordering

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13085/files
  - new: https://git.openjdk.org/jdk/pull/13085/files/3eda19b5..6b7611ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13085&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13085&range=00-01

  Stats: 30 lines in 14 files changed: 15 ins; 15 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13085.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13085/head:pull/13085

PR: https://git.openjdk.org/jdk/pull/13085


From mchung at openjdk.org  Sat Mar 18 19:14:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 18 Mar 2023 19:14:11 GMT
Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the
 test library
In-Reply-To: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
References: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
Message-ID: <Mze6dL2q4vPgtRW9u3OPcTf39b0C7wlUbg8tsJ6en8M=.ee929936-7e9a-4341-920a-86f88e8f8f04@github.com>

On Fri, 17 Mar 2023 22:01:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `ModuleInfoWriter` is not used by the runtime.   Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`.   The tests are updated to use the test library instead.   `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API.   Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added.

Thanks for the pointer to the recommended ordering.   Tests updated.

-------------

PR: https://git.openjdk.org/jdk/pull/13085


From alanb at openjdk.org  Sun Mar 19 07:05:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Mar 2023 07:05:19 GMT
Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the
 test library [v2]
In-Reply-To: <akJtaSAAKeTaoWdkwC9RXCTaw60vcG1tC0pptq_Q-vU=.c5f07395-1549-43a2-b6ac-d56a1f549459@github.com>
References: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
 <akJtaSAAKeTaoWdkwC9RXCTaw60vcG1tC0pptq_Q-vU=.c5f07395-1549-43a2-b6ac-d56a1f549459@github.com>
Message-ID: <UYsx_MP9H-8ox4dBSNNaSojji9SZy9XtPFB-pIOjj9k=.1ecd2b1d-a15e-462a-ad88-50b8699ef5ae@github.com>

On Sat, 18 Mar 2023 19:14:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `ModuleInfoWriter` is not used by the runtime.   Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`.   The tests are updated to use the test library instead.   `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API.   Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move @library after @modules per the recommended ordering

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/13085


From lmesnik at openjdk.org  Mon Mar 20 01:37:23 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 20 Mar 2023 01:37:23 GMT
Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the
 test library [v2]
In-Reply-To: <akJtaSAAKeTaoWdkwC9RXCTaw60vcG1tC0pptq_Q-vU=.c5f07395-1549-43a2-b6ac-d56a1f549459@github.com>
References: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
 <akJtaSAAKeTaoWdkwC9RXCTaw60vcG1tC0pptq_Q-vU=.c5f07395-1549-43a2-b6ac-d56a1f549459@github.com>
Message-ID: <hKMj7pHcKJ1MdTWcRjGftMGDf-8yjp2YjpG2wAfOhVc=.d11d1708-3445-4842-9342-3b1d925e26ff@github.com>

On Sat, 18 Mar 2023 19:14:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `ModuleInfoWriter` is not used by the runtime.   Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`.   The tests are updated to use the test library instead.   `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API.   Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move @library after @modules per the recommended ordering

Changes requested by lmesnik (Reviewer).

test/jdk/java/lang/ModuleTests/AnnotationsTest.java line 61:

> 59:  *          java.base/jdk.internal.module
> 60:  * @library /test/lib
> 61:  * @build jdk.test.lib.util.ModuleInfoWriter

You don't need to build library classes explicitly. I think @library /test/lib it enough.

-------------

PR: https://git.openjdk.org/jdk/pull/13085


From jpai at openjdk.org  Mon Mar 20 07:00:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 20 Mar 2023 07:00:24 GMT
Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the
 test library [v2]
In-Reply-To: <hKMj7pHcKJ1MdTWcRjGftMGDf-8yjp2YjpG2wAfOhVc=.d11d1708-3445-4842-9342-3b1d925e26ff@github.com>
References: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
 <akJtaSAAKeTaoWdkwC9RXCTaw60vcG1tC0pptq_Q-vU=.c5f07395-1549-43a2-b6ac-d56a1f549459@github.com>
 <hKMj7pHcKJ1MdTWcRjGftMGDf-8yjp2YjpG2wAfOhVc=.d11d1708-3445-4842-9342-3b1d925e26ff@github.com>
Message-ID: <COehKHnWJS6fchdmpdUKyJNedhJxdFYtndaYSQdauNM=.a9c0d8bf-d0ce-485d-8546-f9082068f115@github.com>

On Mon, 20 Mar 2023 01:34:11 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move @library after @modules per the recommended ordering
>
> test/jdk/java/lang/ModuleTests/AnnotationsTest.java line 61:
> 
>> 59:  *          java.base/jdk.internal.module
>> 60:  * @library /test/lib
>> 61:  * @build jdk.test.lib.util.ModuleInfoWriter
> 
> You don't need to build library classes explicitly. I think @library /test/lib it enough.

Hello @lmesnik, on the contrary, these build directives are recommended (and based on some of the issues we have encountered, are in fact necessary). The jtreg documentation has this to say https://openjdk.org/jtreg/tag-spec.html:

> In general, classes in library directories are not automatically compiled as part of a compilation command explicitly naming the source files containing those classes. A test that relies upon library classes should contain appropriate @build directives to ensure that the classes will be compiled. It is strongly recommended that tests do not rely on the use of implicit compilation by the Java compiler. Such an approach is generally fragile, and may lead to incomplete recompilation when a test or library code has been modified.

-------------

PR: https://git.openjdk.org/jdk/pull/13085


From mbalao at openjdk.org  Mon Mar 20 14:58:06 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 20 Mar 2023 14:58:06 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <o4jO-b-vE8vC-jKTSkihgwmWT5BFzziCarzD3cBt0Cc=.4d404289-38be-4aa4-ac4d-eea0eb9385d1@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <o4jO-b-vE8vC-jKTSkihgwmWT5BFzziCarzD3cBt0Cc=.4d404289-38be-4aa4-ac4d-eea0eb9385d1@github.com>
Message-ID: <aR5rC-brsEU80rw1gl-MKc0sUm9HyMDd2iY5IGYwQpA=.3dd8ec55-992d-4b23-9dfb-f9b067ee7b44@github.com>

On Wed, 15 Mar 2023 00:30:56 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. I
 n particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
>> 
>>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>>     * A ```P11PBECipher``` service accepts PBE keys only.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diff
 erent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>>       * If the key algorithm matches the service algorithm, the use is allowed
>>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP
 _PKCS5_PBKD2_HMAC_SHA1``` constant.
>>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>>     * New constants added.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>>     * Adjustments to work with the new PBE parameter structures.
>>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
>> 
>>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>>     * Native constants and structures added.
>> 
>> Test files
>> 
>>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
>> 
>>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>>     * Same issue fixed than for ```MacSameTest```.
>> 
>>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
>> 
>>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
>> 
>> Testing
>> 
>>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
>> 
>>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
>> 
>>   * No regressions have been observed in the JDK Tier-1 category.
>> 
>>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
>> 
>> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 108:
> 
>> 106:         }
>> 107: 
>> 108:         static boolean checkUse(KeyInfo ki, KeyInfo si) {
> 
> More comment on ki and si and how this method is used is needed as it's not obvious when looking at the code here.

I'll add an upper comment explaining the purpose of the checkUse method and a comment explaining the ki.keyType == si.keyType path in particular.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mbalao at openjdk.org  Mon Mar 20 14:58:08 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 20 Mar 2023 14:58:08 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <9vhl91MVfHBn3WB948uVAZZmdy4RWzkww60nou0Slxo=.6fccc136-1858-41df-8c62-91a654655878@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <o4jO-b-vE8vC-jKTSkihgwmWT5BFzziCarzD3cBt0Cc=.4d404289-38be-4aa4-ac4d-eea0eb9385d1@github.com>
 <9vhl91MVfHBn3WB948uVAZZmdy4RWzkww60nou0Slxo=.6fccc136-1858-41df-8c62-91a654655878@github.com>
Message-ID: <XL9_Ou13Cz23XYWGV-1H6p9icuAGgonE0GFIg8S-a1g=.62eed0b1-7008-41aa-9f18-e003eb2ad333@github.com>

On Sat, 18 Mar 2023 06:08:07 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 118:
>> 
>>> 116:                 return true;
>>> 117:             }
>>> 118:             return ki.keyType == si.keyType;
>> 
>> So, for non-PBE key info, algos do not have to match?
>
> For services and keys cases in which algorithms identity-match ?irrespective if they are PBE or non-PBE?, KeyInfo::checkUse is not called and execution moves forward as if the check passed (see [here](https://github.com/openjdk/jdk/blob/ab7ffd56bb8b93d513023d0136df55a6375c3286/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L285)). The same is true for services that accept any key type, such as those whose pseudo types are PCKK_HMAC or PCKK_SSLMAC.
> 
> The ki.keyType == si.keyType success value affects cases in which algorithms are different but it's still possible to use the key in the service. One example that would hit this path is a PBE key derived for AES that it's used in an AES Cipher service. For non-PBE keys and services cases, one example is algorithms "RC4" and "ARCFOUR" that have both the underlying CKK_RC4 key type. Notice that this latter case is not new: previous to this enhancement proposal, key types were compared as well (see [here](https://github.com/openjdk/jdk/blob/jdk-21%2B14/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L147)).
> 
> For non-PBE keys and services cases, what is new with this enhancement is to accept them if their algorithms are identity-equal. This condition necessarily means that key types are equal ?the opposite is obviously not true?. One minor detail, when we refer to the algorithms equality trivial pass condition, it's an object identity comparison for performance.

As commented [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1142245451), I'll add a comment to the code explaining this execution path.

-------------

PR: https://git.openjdk.org/jdk/pull/12396


From mchung at openjdk.org  Mon Mar 20 17:12:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 20 Mar 2023 17:12:56 GMT
Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the
 test library [v2]
In-Reply-To: <COehKHnWJS6fchdmpdUKyJNedhJxdFYtndaYSQdauNM=.a9c0d8bf-d0ce-485d-8546-f9082068f115@github.com>
References: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
 <akJtaSAAKeTaoWdkwC9RXCTaw60vcG1tC0pptq_Q-vU=.c5f07395-1549-43a2-b6ac-d56a1f549459@github.com>
 <hKMj7pHcKJ1MdTWcRjGftMGDf-8yjp2YjpG2wAfOhVc=.d11d1708-3445-4842-9342-3b1d925e26ff@github.com>
 <COehKHnWJS6fchdmpdUKyJNedhJxdFYtndaYSQdauNM=.a9c0d8bf-d0ce-485d-8546-f9082068f115@github.com>
Message-ID: <VTH_R1GmbPrJ0lpvzqi1PGMyrhqqCbzW3a17g2dRP4E=.72611b98-f00f-44f3-9f0b-591a5113a818@github.com>

On Mon, 20 Mar 2023 06:57:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/lang/ModuleTests/AnnotationsTest.java line 61:
>> 
>>> 59:  *          java.base/jdk.internal.module
>>> 60:  * @library /test/lib
>>> 61:  * @build jdk.test.lib.util.ModuleInfoWriter
>> 
>> You don't need to build library classes explicitly. I think @library /test/lib it enough.
>
> Hello @lmesnik, on the contrary, these build directives are recommended (and based on some of the issues we have encountered, are in fact necessary). The jtreg documentation has this to say https://openjdk.org/jtreg/tag-spec.html:
> 
>> In general, classes in library directories are not automatically compiled as part of a compilation command explicitly naming the source files containing those classes. A test that relies upon library classes should contain appropriate @build directives to ensure that the classes will be compiled. It is strongly recommended that tests do not rely on the use of implicit compilation by the Java compiler. Such an approach is generally fragile, and may lead to incomplete recompilation when a test or library code has been modified.

Explicit compilation is exactly the reason of adding `@build`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13085#discussion_r1142447529


From mchung at openjdk.org  Mon Mar 20 17:33:33 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 20 Mar 2023 17:33:33 GMT
Subject: Integrated: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to
 the test library
In-Reply-To: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
References: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
Message-ID: <G_NfS1yQgjnAzyPjTZ7JPYo8brswGsOjJFbWHJdMs7o=.f634351b-9c0a-4ff9-8140-c91c457b4a32@github.com>

On Fri, 17 Mar 2023 22:01:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `ModuleInfoWriter` is not used by the runtime.   Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`.   The tests are updated to use the test library instead.   `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API.   Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added.

This pull request has now been integrated.

Changeset: 622f2394
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/622f239448c2a96a74202621ee84c181d79fbde4
Stats:     154 lines in 17 files changed: 91 ins; 19 del; 44 mod

8304163: Move jdk.internal.module.ModuleInfoWriter to the test library

Reviewed-by: jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/13085


From dcubed at openjdk.org  Mon Mar 20 17:55:59 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 20 Mar 2023 17:55:59 GMT
Subject: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the
 test library [v2]
In-Reply-To: <akJtaSAAKeTaoWdkwC9RXCTaw60vcG1tC0pptq_Q-vU=.c5f07395-1549-43a2-b6ac-d56a1f549459@github.com>
References: <DUzfefeIaKuRtN3pg_ByF9yInOIXlSGPlCI4Q2n-cME=.707d3ba1-9ccc-4100-82e5-c146637f241a@github.com>
 <akJtaSAAKeTaoWdkwC9RXCTaw60vcG1tC0pptq_Q-vU=.c5f07395-1549-43a2-b6ac-d56a1f549459@github.com>
Message-ID: <gaLBbS4LqOc7KL3MAJ-2AW1h7nPG75UHlw8qK7J_-PY=.1c043a09-363f-4a8a-bf33-0df75e823873@github.com>

On Sat, 18 Mar 2023 19:14:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `ModuleInfoWriter` is not used by the runtime.   Move it to the test library as `jdk.test.lib.util.ModuleInfoWriter`.   The tests are updated to use the test library instead.   `ModuleInfoWriter` depends on `jdk.internal.module` types and the Classfile API.   Hence `@modules java.base/jdk.internal.classfile` and other classfile subpackages are added.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move @library after @modules per the recommended ordering

Sigh... And again we have the situation where some folks are adding
`@build` directives and other folks are removing `@build` directives.

Another recent PR removed library build directives:
https://github.com/openjdk/jdk/pull/13030

and that made the related tests stop failing with NoClassDefFoundErrors.

This mess is related to:
[CODETOOLS-7902847](https://bugs.openjdk.org/browse/CODETOOLS-7902847) 
Class directory of a test case should not be used to compile a library

and these problems show up when doing parallel execution of tests
where more than one test uses the "offending" library.

We really, really need @jonathan-gibbons to chime in on review threads like these.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13085#issuecomment-1476684779


From mbalao at openjdk.org  Mon Mar 20 18:14:38 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 20 Mar 2023 18:14:38 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <4kSETZwNby-RcFrPodXcGTM6Z2m1tRmebJyGDpOqtMM=.ec402259-bbc7-490d-9707-f37f7660bb8e@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <Wxq8UhV2QEt_LiMEUlf1hKF_pLGttTylntM1OpYZizA=.f9ac393b-3f4c-4bb3-aaa2-eaaa72572a7e@github.com>
 <4kSETZwNby-RcFrPodXcGTM6Z2m1tRmebJyGDpOqtMM=.ec402259-bbc7-490d-9707-f37f7660bb8e@github.com>
Message-ID: <ilguh846M4KG46se2MTssRcCQCXM-Vx2EmhsPrZdFZY=.1ca9f427-83f0-4772-b9e7-a82b65b15bb7@github.com>

On Wed, 15 Mar 2023 18:02:58 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/PBEUtil.java line 47:
>> 
>>> 45: 
>>> 46:     // Used by SunJCE and SunPKCS11
>>> 47:     public final static class PBES2Params {
>> 
>> This class confuses me. An instance is constructed without any parameter. The method `getPBEKeySpec` is able to mutate it and return something, the method `getAlgorithmParameters` is able to read the content and possibly mutate again and return something, and finally another method `getIvSpec` is able to return the content.
>> 
>> Please either precisely document how these methods will be called and enforce this rule with internal checks, or refactor it to something immutable.
>
> +1.

This class mutates because we have to keep state that may change an undefined number of times. This is not new, in the previous code state was kept as well. The only difference is that instead of keeping the state spread across different fields ?which would now require mirroring fields between SunJCE and SunPKCS11 sides?, we have it aggregated in a single class. We are also proposing that the methods that change this state ?which are used equally from SunJCE and SunPKCS11? are also part of the same class. The intention is to help with consistency and code reuse.

I'll give a brief reminder of how state changes work, even before the PBE enhancement. When engineInit is called, parameter values (passed, defaults or randomly generated) will change the state. All following calls to engineGetParameters must return the same state. When engineInit is called again ?with the same CipherSpi instance?, state is re-initialized and the previous sequence repeats. The only special case is when engineGetParameters is called before the first call to engineInit. In such case, engineGetParameters generates the initial state and this state will be overwritten by the first call to engineInit later.

I'll add comments to the class to help explaining this logic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1142516414


From cslucas at openjdk.org  Mon Mar 20 19:23:34 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 20 Mar 2023 19:23:34 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>

> Can I please get reviews for this PR? 
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
> 
> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
> 
> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Add support for SR'ing some inputs of merges used for field loads

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/3b492d2e..a158ae66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=02-03

  Stats: 481 lines in 9 files changed: 292 ins; 117 del; 72 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897


From weijun.wang at oracle.com  Mon Mar 20 21:51:27 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Mon, 20 Mar 2023 21:51:27 +0000
Subject: JEP draft: Leighton-Micali Hash-Based Signatures
Message-ID: <382D5BA4-4E07-4D78-9D65-0903829A35F8@oracle.com>

Hi All,

We propose to add support for HSS/LMS as a Signature algorithm to JCA/JCE.

All currently widely used digital signature schemes, including DSA, RSA, ECDSA, and EdDSA, have the potential to be broken if large scale quantum computers are ever built. However, the security of HSS/LMS depends only on the security of the underlying hash functions, and it is believed that the security of hash functions will not be broken by the development of large-scale quantum computers.

We have drafted a JEP for adding this support (see link below). We propose to add a new standard name and some new APIs. We will also provide an implementation of signature verification which would be integrated into an existing JDK security provider.

We don?t plan to provide implementations of key pair generation and signature generation out-of-box as they should be implemented in hardware. However, we believe third party vendors will be interested in implementing them (in a ?hardware cryptographic module?) and exposing the functions through a Java security provider. Thus we are proposing an HSSGenParameterSpec class to initialize the KeyPairGenerator for HSS/LMS. We also are proposing to define new interfaces named HSSLMSPrivateKey and HSSLMSPublicKey where you can read parameters from the keys. There is a keysRemaining() method where you can find out how many LM-OTS keys are left.

You can read the draft JEP at https://openjdk.org/jeps/8303541.

Feel free to add any comment here.

Thanks,
Max


From mbalao at openjdk.org  Tue Mar 21 06:30:47 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 21 Mar 2023 06:30:47 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <gooHoubcL5geL0QQ8J3qTVpkIi9k4Tm8o_VDZHsqSpc=.774f5b96-cf03-4878-99e0-56faa79dbf91@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <hrOv6KCpuxmj8elN6U67d-wBF-ogqcaO13uwIj-KJkw=.a64470ee-d871-424c-b17f-11ac5ced742d@github.com>
 <gooHoubcL5geL0QQ8J3qTVpkIi9k4Tm8o_VDZHsqSpc=.774f5b96-cf03-4878-99e0-56faa79dbf91@github.com>
Message-ID: <jKePZiAyfoPsFbEHxmHwGOyKbfQ4J5Fiw19t0Qp021s=.eaef92f0-2eca-4a66-a29d-ac3fcb743105@github.com>

On Fri, 17 Mar 2023 15:47:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/PBEUtil.java line 59:
>> 
>>> 57:         }
>>> 58: 
>>> 59:         public AlgorithmParameters getAlgorithmParameters(int blkSize,
>> 
>> I see most if not all of the methods in this class are lifted from other classes as the result of code refactoring. Would be nice to document its callers, e.g. where it's used.
>
> I added references, that include the security provider and class, to each method and inner class in PBEUtil. The instance methods in PBEUtil$PBES2Params use the reference for their containing class. Let me know if you still want to repeat the reference for each one.

We finally decided to include a general comment in the PBEUtil$PBES2Params class and also comments in each method. We also added comments to other PBEUtil methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1142937134


From mbalao at openjdk.org  Tue Mar 21 06:45:49 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 21 Mar 2023 06:45:49 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <1VkOwD0SqUUl__B6-ejTqNqhDVb-k_5-tNOSRGwtHD8=.6c88e94b-b159-4619-8a63-e4980724b59b@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <aCC9GaM4mD4QRd2sSRKB8P80gjaRlgekM0y-_xXnp6k=.4bf9fe42-6696-44a7-b03d-2b008fc1a19f@github.com>
 <1VkOwD0SqUUl__B6-ejTqNqhDVb-k_5-tNOSRGwtHD8=.6c88e94b-b159-4619-8a63-e4980724b59b@github.com>
Message-ID: <yzvO8BFuEqn2ZxE0dLRSbKnAX80dIO8PFI6Gg_JNvms=.eacc912f-0997-4cf9-87e0-2ce44fda4af9@github.com>

On Sat, 18 Mar 2023 07:18:31 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 204:
>> 
>>> 202:         if (svcPbeKi != null) {
>>> 203:             if (key instanceof P11Key) {
>>> 204:                 params = PBEUtil.checkKeyParams(key, params, algorithm);
>> 
>> It seems strange that you check the key to be instanceof P11Key but then inside PBEUtil.checkKeyParams, it errors out if the key instanceof PBEKey. Maybe you meant to check if the key is an instanceof P11PBEKey? Could the key be a PBEKey but not P11Key and contains more than just password? I don't quite follow the logic here.
>
> We can only pass PBEKey keys to PBE Mac services.
> 
> If the key is a P11Key (PBEKey + P11Key == P11PBEKey), derivation is not needed. We just check that the P11Key came from a PBE derivation inside PBEUtil.checkKeyParams and that's it. This is for consistency enforcement only: the token does not care the P11Key origin as long as it has the right attributes to calculate the HMAC.
> 
> If the key is not a P11Key, we have to derive it. We just check that the key implements the PBEKey interface, so there is data for derivation. The derived key will be a P11Key (in particular, a P11PBEKey).
> 
> Thus, the ```if``` [here](https://github.com/openjdk/jdk/blob/ab7ffd56bb8b93d513023d0136df55a6375c3286/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java#L203) should be read as: are we receiving an already derived key (true) or do we have to derive it (false)? In any case, apply the corresponding checks and move forward.
> 
> I'll add a comment to the code to make this logic more clear.

In addition to the new comments, we finally implemented a couple of minor changes for clarity and to enforce a check that was previously omitted:

  * PBEUtil.checkKeyParams was renamed to PBEUtil.checkKeyAndParams and does not longer return the underlying service params (PBEParameterSpec.paramSpec). It's only checking that the key implements the PBEKey interface and that params, if an instance of PBEParameterSpec, are consistent with the key's derivation data. We added a comment in PBEUtil.java too, where PBEUtil.checkKeyParams is defined.
  * For all PBE cases in which params is an instance of PBEParameterSpec, the underlying service params value (PBEParameterSpec.paramSpec) is obtained and assigned to params. Notice that this was not done before in derivation cases.
  * Now, we enforce the check that the underlying service params is null even in those cases in which we derived.

We modified P11PBECipher to be aligned to these changes, and added equivalent comments there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1142945131


From mbalao at openjdk.org  Tue Mar 21 06:51:47 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 21 Mar 2023 06:51:47 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <CXO0EbZSll2DBmYq5YHtTyqST8mffHstl_MLQRfk0Gc=.7c4a7ced-0abe-4aec-b4b9-c253ea266611@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <PE7O8-rnZmhz3_THUqFsK5qA0wviqv63Kb9bCSPhL84=.e206246d-43ea-4116-84a1-7ca6d5617605@github.com>
 <CXO0EbZSll2DBmYq5YHtTyqST8mffHstl_MLQRfk0Gc=.7c4a7ced-0abe-4aec-b4b9-c253ea266611@github.com>
Message-ID: <ipidh8O4kmlLFjx-WA7PN8KvQcMke1DghUHw5g7nnbw=.1e8795db-7e2b-4050-a10b-d756f6150704@github.com>

On Sat, 18 Mar 2023 07:53:15 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 223:
>> 
>>> 221:             }
>>> 222:             p11Key = P11SecretKeyFactory.convertKey(token, key, algorithm);
>>> 223:         }
>> 
>> Is this meant to handle Non-PBE-related case? The logic here seems conflicting with the above code block where the params must be null. Also if key is instanceof P11Key already, why are you calling P11SecretKeyFactory.convertKey(...) again? Strange.
>
> The quoted block handles non-PBE cases (svcPbeKi == null) and PBE cases in which the derivation was not required (svcPbeKi != null && key instanceof P11Key). The only cases left out of the block are PBE ones in which the key had to be derived because no conversion is needed.
> 
> If we enter the block in the non-PBE case, params must be null like before to this enhancement (see [here](https://github.com/openjdk/jdk/blob/jdk-21%2B14/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java#L195)).
> 
> If we enter the block in the PBE case (derivation not required), params is what PBEUtil::checkKeyParams returned. This function returns the PBEParameterSpec::paramSpec field of the passed PBEParameterSpec instance, which is always null except for the PBE Cipher cases in which the IV can be specified. Given that this is a Mac service, a non-null value there is not expected. We check this for consistency.
> 
> We are calling P11SecretKeyFactory::convertKey if the key is a P11Key because it might be a P11Key from a token different than the P11Mac service one (the condition [here](https://github.com/openjdk/jdk/blob/ab7ffd56bb8b93d513023d0136df55a6375c3286/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L294) could be false). If that's the case, a new derivation in the P11Mac service token will be done. Notice that this is a little caveat to my previous comment [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1140958830): a P11Key might still require a derivation.
> 
> I'll add comments to the code to make this more clear.

We made a subtle modification to this code that does not change execution paths ?except for checking params against null in derivation cases, as commented [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1142945131)? but hopefully helps with clarity. In particular:

  * The condition to try conversion is now p11Key == null. Conversion is tried in non-PBE cases and PBE cases in which derivation was not done, as commented [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1140963493).
  * The check of params against null is now previous to the conversion block, and applies to all cases (including those in which we derived).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1142948975


From mbalao at openjdk.org  Tue Mar 21 06:59:49 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 21 Mar 2023 06:59:49 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <X-i4Bfp7X08-GxA2qKVJPSU3xVj14RMT0czsBJmCHzo=.44d57597-e761-4dc4-ba7a-a7064de33db6@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <D1IoF4NpLbZu_3KOEWJ40mhnbKoZo8pVmPWZ8ZpWlGw=.1f96677f-b450-47e7-831d-6d3c74285a8b@github.com>
 <X-i4Bfp7X08-GxA2qKVJPSU3xVj14RMT0czsBJmCHzo=.44d57597-e761-4dc4-ba7a-a7064de33db6@github.com>
Message-ID: <Wo5cNyWfyfgW4e4uANEfdwlrFf4EKEgUWnCWH-nr_ZU=.55fa1a96-18b7-4e7d-b986-9f03b720fa84@github.com>

On Thu, 16 Feb 2023 23:12:09 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java line 1192:
>> 
>>> 1190:                                         /* (CKM_NSS + 31) */ = 0xCE53436FL;
>>> 1191:     public static final long  CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN
>>> 1192:                                         /* (CKM_NSS + 32) */ = 0xCE534370L;
>> 
>> For user-friendly sake, now that you added these mechanisms, you should add the string name mapping for these native NSS mechanisms into the sun.security.pkcs11.wrapper.Functions class through its addMech(long, String) method.
>
> That's right. As part of the next iteration we will fix that and better align the order, grouping NSS mechanisms together in PKCS11Constants.java.

We realized that strings for Pseudo-random function (CKP_) and Salt/Encoding parameter (CKZ_) constants were missing. We added it to Functions.java, and modified CK_PKCS5_PBKD2_PARAMS and CK_PKCS5_PBKD2_PARAMS2 classes to use them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1142952860


From mbalao at openjdk.org  Tue Mar 21 07:02:49 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 21 Mar 2023 07:02:49 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <YhzKw3AtLWRivwa9OAEel8gB-MIx0aZgrKy46V92EgQ=.98d79b60-41bf-46d4-bb4b-d3671dfa3567@github.com>

On Fri, 3 Feb 2023 01:41:41 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

In addition to all inline comments, our next iteration will contain minor improvements validation of static assertion data in TestPBKD.java, PBAMac.java and PBECipher.java tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1477360349


From mbalao at openjdk.org  Tue Mar 21 20:31:44 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 21 Mar 2023 20:31:44 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v2]
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <7CAUW1aHjrYSDR2wg0tigIApQDNNta3TCjwR_5D1dxA=.51cdb2c0-61f9-4945-8c93-86fe54327c2b@github.com>

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) and ```PBES2Core::engineGetParameters```, given a single ```PBES2Core``` instance. In
  particular, a call to any of these methods can potentially modify the state in an observable way by means of generating a random IV and a salt. Previous to the proposed patch, this data was persisted in the ```PBES2Core::ivSpec``` and ```PBES2Core::salt``` instance fields. For compatibility purposes, we decided to preserve ```SunJCE```'s current behavior.
> 
>   * ```src/java.base/share/classes/sun/security/util/PBEUtil.java``` (new file)
>     * This utility file contains the PBE parameters checking routines and default values that are used by both ```SunJCE``` and ```SunPKCS11```. These routines are invoked from ```HmacPKCS12PBECore``` (```SunJCE```), ```PBES2Core``` (```SunJCE```), ```P11PBECipher``` (```SunPKCS11```) and ```P11Mac``` (```SunPKCS11```). As previously noted, the goals are to avoid duplicate code and to improve compatibility between different security providers that implement PBE algorithms.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java``` (modified)
>     * An utility function to determine if the token is NSS is now called. This function is in a common utility class (```P11Util```) and invoked from ```P11Key``` and ```P11SecretKeyFactory``` too.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java``` (modified)
>     * A new type of P11 key is introduced: ```P11PBEKey```. This new type represents a secret key that exists inside the token. Thus, this type inherits from ```P11SecretKey```. At the same time, this type holds data used for key derivation. Thus, this type implements the ```javax.crypto.interfaces.PBEKey``` interface. In addition to the conceptual modeling, there are practical advantages of identifying a key by this new ```P11PBEKey``` type and holding the data used for derivation: 1) if the key is used in another token (different than the one where it was originally derived), a new derivation must take place; 2) if the key is passed to a non-```SunPKCS11``` security provider, its key translation method might use derivation data to derive again; and, 3) it's possible to return the ```PBEKeySpec``` for the key (see for example ```P11SecretKeyFactory::engineGetKeySpec```).
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java``` (modified)
>     * We decided to integrate PBE algorithms to the existing ```P11Mac``` service because the changes required have a low impact on the existing code. When the ```P11Mac``` instance is created, we use the algorithm to get PBE key information (if available). Only PBE algorithms have this type of information. In the ```P11Mac::engineInit``` method, we now need to handle the PBE service case. In such case, if the key is a ```P11Key```, we check parameters and that the key implements ```javax.crypto.interfaces.PBEKey``` by calling ```PBEUtil::checkKeyParams```. In other words, the key has to be a ```P11PBEKey``` and the parameters used for its derivation must match the ones passed in the invocation to ```P11Mac::engineInit```. If the key is not a ```P11Key```, a PBE derivation is needed. As for the ```SunJCE``` case, we go through parameters processing in ```PBEUtil::getPBAKeySpec```.
>     * There are two cases in which we need to call ```P11SecretKeyFactory::convertKey```. One is when the service is not PBE, as we did before the proposed change. In the PBE case, we must call this function because it might be possible that, if the key token is not the same than the service's token, a new key derivation is required.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java``` (new file)
>     * Contrary to the ```P11Mac``` case, we decided to separate PBE ```Cipher``` from non-PBE ```Cipher``` in a different class. There is some additional complexity or gap between the two that we prefer to keep simple. A PBE ```Cipher``` uses a non-PBE ```Cipher``` service underneath and forwards most of its operations, but adds wrapping code to potentially derive keys during initialization (see ```P11PBECipher::engineInit```). The code associated to key derivation and parameters consistency checking is analogous to the one described for ```P11Mac```.
>     * ```P11PBECipher``` has a ```P11PBECipher::engineGetParameters``` method which calls ```PBEUtil.PBES2Params::getAlgorithmParameters``` and can potentially initialize an IV and a salt with a random value, as explained in the comments for ```PBES2Core```.
>     * A ```P11PBECipher``` service accepts PBE keys only.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java``` (modified)
>     * The first significant change to this class that we want to discuss is the introduction of the ```KeyInfo``` class and the refactoring of the previous ```keyTypes``` map. Previous to the proposed change, the key information that we needed to retain for key creation at the PKCS #&#x2060;11 level was simple: key algorithm -> PKCS #&#x2060;11 native key type. With PBE, we must consider not only the algorithm name and key type but also (depending on the case) the mechanism that has to be used for derivation, the underlying derivation function and the key length. As an example, to derive a key for the PBEWithHmacSHA512AndAES_256 algorithm, we need to know that this algorithm maps to a PKCS #&#x2060;11 derivation mechanism value of ```CKM_PKCS5_PBKD2```, a derivation function value of ```CKP_PKCS5_PBKD2_HMAC_SHA512```, a derived key type of ```CKK_AES``` ?so it can be used in an AES Cipher service? and a key length of 256 bits. A new hierarchy of classes to represent these diffe
 rent entries on the mapping structure has been introduced (see ```KeyInfo```, ```PBEKeyInfo```, ```AESPBEKeyInfo```, ```PBKDF2KeyInfo``` and ```P12MacPBEKeyInfo```). The methods to add or find entries in the new map have been adjusted. The previous pseudo key types strategy (```HMAC```, ```SSLMAC```), that allows any key type to be used in a HMAC service, has not been modified.
>     * The second significant change to this class was in the ```P11SecretKeyFactory::convertKey``` method. When checking if a key can be used in a service ?notice here that the service can be any of ```SecretKeyFactory```, ```Cipher``` or ```Mac```?, the following rules apply:
>       * If the key algorithm matches the service algorithm, the use is allowed
>       * If the key algorithm does not match the service algorithm and the service is not one of the pseudo types, further checks are needed. The ```KeyInfo``` structure for the key and service algorithms are obtained from the map and the ```KeyInfo::checkUse``` method is invoked. The following principles apply to make a decision: 1) PBE services require a ```javax.crypto.interfaces.PBEKey``` of the same algorithm ?we cannot use an AES key, for example, in a PBEWithHmacSHA512AndAES_256 ```Cipher``` service?, 2) PBKD2 keys can be used on any service ?there is no information about the key purpose to make a decision? and 3) keys can be used in a service if their underlying type match ?as an example, a PBEWithHmacSHA512AndAES_256 PBE key has an underlying type of ```CKK_AES``` and can be used in an AES ```Cipher``` service?.
>     * The third significant change to this class was the addition of the ```P11SecretKeyFactory::derivePBEKey``` function. This function does different checks and creates the PKCS #&#x2060;11 structures to make a native call to ```C_GenerateKey``` to derive the key. They key returned, in case of success, is of ```P11PBEKey``` type. It is worth mentioning that this function is the only path to invoke a native key derivation. It's used not only by the PBE ```P11SecretKeyFactory``` service but also by PBE ```Cipher``` and PBE ```Mac``` services when they need to derive a key.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java``` (modified)
>     * Added some utility functions. One of them is ```P11Util::encodePassword``` which serves the purpose of encoding a password in a way that can go through native library truncation (OpenJDK) and reach the PKCS #&#x2060;11 API in the expected encoding. Password encoding must be UTF-8 for PKCS #&#x2060;5 v2.1 derivation and BMPString (UTF-16 big endian) for PKCS #&#x2060;12 v1.1 General Method for Password Integrity derivation. By avoiding a modification to the existing native ```jCharArrayToCKUTF8CharArray``` function (```p11_util.c```), we reduce the risk of breaking existing code.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java``` (modified)
>     * The new PBE algorithms are registered for ```SunPKCS11``` services. It's worth noting that there is an additional (and optional) ```requiredMechs``` array to specify a list of native mechanisms that must be available in the token for the service to be enabled. To explain the need for this structure, we will focus on the HmacPBESHA1 ```Mac``` service example. On the one hand, we require the ```CKM_SHA_1_HMAC``` mechanism to be available in the token because this is, ultimately, a SHA-1 HMAC operation. However, the ```CKM_PBA_SHA1_WITH_SHA1_HMAC``` mechanism must be available as well for the preceding PBE key derivation. In the PBKDF2 case, we leverage on this structure to require a mechanism associated to the derivation function. The assumption is that, for example, if the ```CKM_PKCS5_PBKD2``` and ```CKM_SHA_1_HMAC``` mechanisms are available, a PBKDF2 derivation using HMAC SHA-1 underneath will be available. In this case, the derivation function is represented by the ```CKP_
 PKCS5_PBKD2_HMAC_SHA1``` constant.
>     * As mentioned in [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), for some algorithms there isn't a PKCS #&#x2060;11 constant and we use the NSS vendor-specific one. This code can be easily be updated in the future if a constant is introduced to the standard. We don't know if that will ever happen as the newer PKCS #&#x2060;5 derivation for Mac (PBMAC1) might be considered in the future as a PKCS #&#x2060;12 integrity scheme replacement.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java``` (modified)
>     * Minor comment fix. This mistake was probably the result of using the ```CK_PKCS5_PBKD2_PARAMS``` file as a template and forgetting to update the comment.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java``` (modified)
>     * New constructors for the ```CK_PBE_PARAMS```, ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures that can be used along with a ```CK_MECHANISM```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java``` (modified)
>     * Some minor adjustments to comments and a constructor to make this class usable with the PKCS #&#x2060;12 General Method for Password Integrity derivation.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java``` (modified)
>     * Same than for ```CK_PBE_PARAMS```. It is worth noting that this structure is the one used in PKCS #&#x2060;11 revisions previous to v2.40 Errata 01. Given that NSS has decided to keep using it ?even when it's not compliant with the latest revisions of the v2.40 and v3.0 standards?, we make an exception for it.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS2.java``` (new file)
>     * The new structure for passing PBE parameters to the PKCS #&#x2060;11 token in the PKCS #&#x2060;5 v2.1 derivation scheme.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java``` (modified)
>     * Same comment than for ```CK_ECDH1_DERIVE_PARAMS```.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java``` (modified)
>     * More visibility of major and minor versions of the PKCS #&#x2060;11 standard implemented by a token is needed to decide between the ```CK_PKCS5_PBKD2_PARAMS``` and ```CK_PKCS5_PBKD2_PARAMS2``` structures.
> 
>   * ```src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java``` (modified)
>     * New constants added.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c``` (modified)
>     * Adjustments made to work with the structures to pass parameters to the token for PBE derivation. It's worth noting that native PBKD2 parameter structures have a tag before the data so we can execute the correct logic to free up resources, once the operation is completed. This is how we differentiate a ```CK_PKCS5_PBKD2_PARAMS``` from a ```CK_PKCS5_PBKD2_PARAMS2``` one.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c``` (modified)
>     * Adjustments to work with the new PBE parameter structures.
>     * A bug affecting non-null Java arrays whose length is 0 and need to be converted to native PKCS #&#x2060;11 arrays has been fixed. For these arrays, it was possible that some platforms return ```NULL``` as a result of calling memory allocation functions when the size was 0 and an ```OutOfMemory``` exception was incorrectly thrown.
> 
>   * ```src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h``` (modified)
>     * Native constants and structures added.
> 
> Test files
> 
>   * ```test/jdk/sun/security/pkcs11/Cipher/PBECipher.java``` (new file)
>     * Tests the PBE ```Cipher``` service in ```SunPKCS11```, cross-comparing results against ```SunJCE``` (if available) and static data.
>     * The PBE ```Cipher``` service is tested with different types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service, derived from data in ```AlgorithmParameters``` and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/KeyStore/ImportKeyToP12.java``` (new file)
>     * Tests that, for several PBE algorithms, PKCS #&#x2060;12 key stores (with Privacy and Integrity) written using ```SunPKCS11``` underneath can be read using ```SunJCE``` underneath.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/MacSameTest.java``` (modified)
>     * This test was not expecting PBE services to be available in the ```SunPKCS11``` security provider, and needs to invoke a new function (```PKCS11Test::generateKey```) to generate a random key (password).
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/PBAMac.java``` (new file)
>     * Similar to ```PBECipher``` but these are the possible types of keys: derived from data in a ```PBEParameterSpec```, derived with a ```SunPKCS11``` ```SecretKeyFactory``` service and derived from data contained in a ```javax.crypto.interfaces.PBEKey``` instance.
> 
>   * ```test/jdk/sun/security/pkcs11/Mac/ReinitMac.java``` (modified)
>     * Same issue fixed than for ```MacSameTest```.
> 
>   * ```test/jdk/sun/security/pkcs11/PKCS11Test.java``` (modified)
>     * Functions to generate random keys or passwords for PBE and non-PBE algorithms.
> 
>   * ```test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java``` (new file)
>     * In addition to testing derived keys for different algorithms against ```SunJCE``` and static assertion data, this test asserts: 1) different types of valid and invalid key conversions, and 2) invalid or inconsistent parameters passed for key derivation. Keys are derived with data contained in a ```PBEKeySpec``` or in a ```javax.crypto.interfaces.PBEKey``` instance.
>     * Both an empty and a unicode password, containing a non-ASCII character, are used during this test.
> 
> Testing
> 
>   * No regressions have been observed in the ```jdk/sun/security/pkcs11``` category (```SunPKCS11```).
> 
>   * No regressions have been observed in the ```jdk/com/sun/crypto/provider``` category (```SunJCE```).
> 
>   * No regressions have been observed in the JDK Tier-1 category.
> 
>   * Anecdotally, a partial version of the proposed patch containing ```Cipher``` and ```Mac``` changes is shipped in Red Hat Enterprise Linux builds of OpenJDK 17 since November 2022, without any known issues at this moment.
> 
> This contribution is co-authored between @franferrax and @martinuy. We are both under the cover of the OCA agreement per our employer (Red Hat). We look forward to sharing this new feature for the benefit of the broad OpenJDK community and users.

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
  
  Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12396/files
  - new: https://git.openjdk.org/jdk/pull/12396/files/ab7ffd56..f1b2006a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=00-01

  Stats: 327 lines in 17 files changed: 210 ins; 64 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/12396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12396/head:pull/12396

PR: https://git.openjdk.org/jdk/pull/12396


From duke at openjdk.org  Tue Mar 21 21:25:50 2023
From: duke at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 21 Mar 2023 21:25:50 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v2]
In-Reply-To: <J-1IjhoPmgvbR2O_-g8FiokhclnfnjskR__qQKJ9mRI=.a00e587f-e124-498d-a565-896bad7dd479@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <PI-62B3AsalftkBJVpX1uw1elgUcOHyPLECRHaAADY4=.fe33d6e3-7f31-4081-bc37-df40b49a1550@github.com>
 <cHmiH-s_TlSlFd5nh2tJXh1gq802oz_Oeyai_WSARs4=.68b271e2-0bd9-4d53-8c68-e2e95e623006@github.com>
 <J-1IjhoPmgvbR2O_-g8FiokhclnfnjskR__qQKJ9mRI=.a00e587f-e124-498d-a565-896bad7dd479@github.com>
Message-ID: <ujWSN25hzUZHLjHSIzCVycBK0vHirIVCNHSo-32hCP4=.b9c8dd3c-4a21-465f-a0b5-15689636a12c@github.com>

On Sat, 18 Mar 2023 06:54:37 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Good question. Looks like a bug. The values should probably be 224 and 256 respectively (output sizes). @franferrax what do you think? We can trace the CKA_VALUE_LEN for these mechanisms in the NSS Software Token to verify it. Also, we should explore if it's possible to add a test for HmacPBESHA512/224 and HmacPBESHA512/256 to TestPBKD. I'll make the change but leave this comment open until we further explore.
>
> I just realized that the underlying native mechanism is the same so I'm not even sure that the NSS Software Token will truncate the output as we expect. This reinforces the need for further exploration and testing. We may need to remove support for these algorithms.

We've given it another look, and realized that in fact this was left there by mistake. I initially thought that we could implement those algorithms by just truncating the `CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN` derivation output from `512` to `224` or `256` bits, but never moved ahead with that implementation.

This [chosen `keyLen` divided by `8` ends up passed as the `CKA_VALUE_LEN` attribute](https://github.com/openjdk/jdk/blob/ab7ffd56bb8b93d513023d0136df55a6375c3286/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L421), which the PKCS <span>#</span>11 token can ignore and just use `64` (`512 / 8`), given the mechanism itself indicates the key length. NSS does this, see [`pkcs11c.c:4655-4659`](https://github.com/nss-dev/nss/blob/NSS_3_85_RTM/lib/softoken/pkcs11c.c#L4655-L4659) and [`pkcs11c.c:4421`](https://github.com/nss-dev/nss/blob/NSS_3_85_RTM/lib/softoken/pkcs11c.c#L4421). So changing `512` to `224` or `256` doesn't have any effect.

On the other hand, re-checking this, even if I had developed truncation of the derived key, it wouldn't have worked, because is the output of the pseudo-random hash function what should be truncated instead, in every iteration and step of the derivation.

For this reason, we decided to remove the `HmacPBESHA512/224` and `HmacPBESHA512/256` algorithms from the proposal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1144002498


From duke at openjdk.org  Wed Mar 22 16:20:03 2023
From: duke at openjdk.org (Brian J. Stafford)
Date: Wed, 22 Mar 2023 16:20:03 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ZMw9GyCrzuJZwMMqPx0OrqPoi7Teztl6t2rvzqJeE6Y=.8c1a9433-8e7f-46cb-926d-3c7915806e56@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
 <_qlJO4uIah2tm1dhS05u8ujJPXV1ABZtnM6xo4NW3J0=.776ffd52-f1b1-4e30-841b-32453f3c7b1b@github.com>
 <ZMw9GyCrzuJZwMMqPx0OrqPoi7Teztl6t2rvzqJeE6Y=.8c1a9433-8e7f-46cb-926d-3c7915806e56@github.com>
Message-ID: <7TV6SD5DyaXGW-ineak0cohJnV58jrsD_cTC5GFhphA=.9a22fca7-aab7-45fb-b033-6d3b044ff396@github.com>

On Tue, 14 Mar 2023 21:58:46 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> May I get a chance to review it before the integration?  I may need more time to dig into time-constant issue.
>
>> May I get a chance to review it before the integration? I may need more time to dig into time-constant issue.
> 
> If I read the Bleichenbacher's Attack[[1]](https://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf)[[2]](https://medium.com/@c0D3M/bleichenbacher-attack-explained-bc630f88ff25)[[3]](https://asecuritysite.com/encryption/c_c3) right, the attack works if it can tell the difference between good conditions and error conditions.  RFC 8017 says "distinguish the different error conditions", but it may be parsed differently for various context.  Please be careful about this update.
> 
> Thank you for giving me more time to look into the details.

@XueleiFan are you still looking into the details of this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12732#issuecomment-1479856354


From kvn at openjdk.org  Fri Mar 24 16:38:02 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 16:38:02 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
Message-ID: <g6BlojUYZSiXJh61lESSO6I2IV7p6ujx7fnMLxeIeoA=.117d0bd6-4ac0-4702-a533-ebe2e6e01e4a@github.com>

On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for SR'ing some inputs of merges used for field loads

Thank you, @JohnTortugo, for continue working on it. I will test it and do proper review late.
Of cause @iwanowww have to approve it too :)

-------------

PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1357067077


From kvn at openjdk.org  Fri Mar 24 16:43:13 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 16:43:13 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
Message-ID: <xeGxSTB0GhzgnN1EwPutxShuPnGXh5bbBUs1w28_f64=.d1eadc8e-e78f-41d3-b8b3-823493f01ce6@github.com>

On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for SR'ing some inputs of merges used for field loads

You new test failed in GHA testing with 32-bit VM: `Could not find VM flag "UseCompressedOops" in @IR rule 1 at int`.
You need to adjust next rule: `@IR(counts = { IRNode.ALLOC, "2" }, applyIf = { "UseCompressedOops", "false" })`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1483098691


From xuelei at openjdk.org  Fri Mar 24 17:38:21 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 24 Mar 2023 17:38:21 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ZMw9GyCrzuJZwMMqPx0OrqPoi7Teztl6t2rvzqJeE6Y=.8c1a9433-8e7f-46cb-926d-3c7915806e56@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
 <_qlJO4uIah2tm1dhS05u8ujJPXV1ABZtnM6xo4NW3J0=.776ffd52-f1b1-4e30-841b-32453f3c7b1b@github.com>
 <ZMw9GyCrzuJZwMMqPx0OrqPoi7Teztl6t2rvzqJeE6Y=.8c1a9433-8e7f-46cb-926d-3c7915806e56@github.com>
Message-ID: <VNyiuEHcm2jfdY-mI2IEST9DqLun7_4p8zeDpV_Epno=.b7712ffd-ca49-4c3f-b420-10b0478cd2fd@github.com>

On Tue, 14 Mar 2023 21:58:46 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> May I get a chance to review it before the integration?  I may need more time to dig into time-constant issue.
>
>> May I get a chance to review it before the integration? I may need more time to dig into time-constant issue.
> 
> If I read the Bleichenbacher's Attack[[1]](https://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf)[[2]](https://medium.com/@c0D3M/bleichenbacher-attack-explained-bc630f88ff25)[[3]](https://asecuritysite.com/encryption/c_c3) right, the attack works if it can tell the difference between good conditions and error conditions.  RFC 8017 says "distinguish the different error conditions", but it may be parsed differently for various context.  Please be careful about this update.
> 
> Thank you for giving me more time to look into the details.

> @XueleiFan are you still looking into the details of this change?

I'm not sure this update is safe.  It would be good (it is possible) to have an improvement that  there is no timing differences between success and failure by not using exception in unpad() implementation any longer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12732#issuecomment-1483174451


From weijun.wang at oracle.com  Fri Mar 24 18:32:24 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Fri, 24 Mar 2023 18:32:24 +0000
Subject: Update to JEP draft: Key Encapsulation Mechanism API
In-Reply-To: <3273EFFC-5430-46F0-80CE-01C6A9E79979@oracle.com>
References: <6EA03210-3F06-495F-B540-0D4111992ECC@oracle.com>
 <9DB75943-41AA-455E-B330-A321B8CD493B@oracle.com>
 <3273EFFC-5430-46F0-80CE-01C6A9E79979@oracle.com>
Message-ID: <F00ED918-BD35-486E-920C-740E358ECD6E@oracle.com>

Hi All,

The JEP draft was just updated again.

The KEMParameterSpec argument is moved from getInstance() to newEncapsulator() and newDecapsulator(). The reason is that when delayed provider selection happens, a KEMSpi object is only created when newEncapsulator/newDecapsulator is called. If the parameter is rejected then some kind of exception should be thrown. It looks a little strange for newEncapsulator/newDecapsulator to throw an InvalidAlgorithmParameterException since their only argument is a key. A user might also question why the exception was not thrown when getInstance() was called.

Furthermore, since the only bonus a KEMParameterSpec provides is a SecureRandom and it's useless for a decapsulator, we decided to remove the KEMParameterSpec class. User can now provide a SecureRandom and an AlgorithmParameterSpec separately when creating an encapsulator, and only an AlgorithmParameterSpec when creating a decapsulator.

    public Encapsulator newEncapsulator(PublicKey pk, AlgorithmParameterSpec spec, SecureRandom sr)
            throws InvalidAlgorithmParameterException, InvalidKeyException;

    public Decapsulator newDecapsulator(PrivateKey sk, AlgorithmParameterSpec spec)
            throws InvalidAlgorithmParameterException, InvalidKeyException;


Please take a look. The updated JEP is still at https://openjdk.org/jeps/8301034.

Thanks,
Max



From weijun at openjdk.org  Fri Mar 24 18:43:09 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 24 Mar 2023 18:43:09 GMT
Subject: RFR: 8304136: Match allocation and free in sspi.cpp
In-Reply-To: <dFA-hjPgP2Ge0ZYmCq9Fl-D98hwVQ8Z3nVJmFRtngoE=.8274e89a-ef7e-4f7f-8e2e-9cd432cd89a7@github.com>
References: <SHCI07jBgMwrniNa4aeJcLltaY2eh5_YwPhSJBsW8Zs=.26e30881-4c81-4321-8cac-41c1ea6b4986@github.com>
 <dFA-hjPgP2Ge0ZYmCq9Fl-D98hwVQ8Z3nVJmFRtngoE=.8274e89a-ef7e-4f7f-8e2e-9cd432cd89a7@github.com>
Message-ID: <97qSRilYbSLx6TGJxS0ZdrrCrWkdp-oRcSc5JPxuqgc=.7993128c-70a2-4ecf-a5b5-0943aa4596dc@github.com>

On Tue, 14 Mar 2023 20:10:08 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> After this change, `gss_buffer_t` always uses `malloc` and `free`. All others use `new` and `delete`. It also initializes several `SecBuffer` to zeroes so it's safe to check for null when trying to free them.
>
> LGTM. Thanks!

Congratulations to @djelinski for being promoted to an OpenJDK Reviewer!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13018#issuecomment-1483253260


From weijun at openjdk.org  Fri Mar 24 18:43:11 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 24 Mar 2023 18:43:11 GMT
Subject: Integrated: 8304136: Match allocation and free in sspi.cpp
In-Reply-To: <SHCI07jBgMwrniNa4aeJcLltaY2eh5_YwPhSJBsW8Zs=.26e30881-4c81-4321-8cac-41c1ea6b4986@github.com>
References: <SHCI07jBgMwrniNa4aeJcLltaY2eh5_YwPhSJBsW8Zs=.26e30881-4c81-4321-8cac-41c1ea6b4986@github.com>
Message-ID: <Y7Vt8-SLL-TloGNQbDy6M_uOhuhe5l5g_QoTNnL_4Dg=.8b333927-756e-48b6-884e-727b06087386@github.com>

On Tue, 14 Mar 2023 14:02:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> After this change, `gss_buffer_t` always uses `malloc` and `free`. All others use `new` and `delete`. It also initializes several `SecBuffer` to zeroes so it's safe to check for null when trying to free them.

This pull request has now been integrated.

Changeset: 765a9425
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/765a94258d84ac6f22bb2dedd1fc1afdbabb2b14
Stats:     32 lines in 1 file changed: 12 ins; 3 del; 17 mod

8304136: Match allocation and free in sspi.cpp

Reviewed-by: djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/13018


From kvn at openjdk.org  Fri Mar 24 19:46:36 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 19:46:36 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
Message-ID: <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>

On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for SR'ing some inputs of merges used for field loads

Initial review.

src/hotspot/share/code/debugInfo.hpp line 199:

> 197: // ObjectValue describing an object that was scalar replaced.
> 198: 
> 199: class ObjectMergeValue: public ScopeValue {

Why you did not make subclass of ObjectValue? You would need to check `sv->is_object_merge()` first before `sv->is_object()` in few places. But on other hand you don't need to duplicates ObjectValue`s fields and asserts.

src/hotspot/share/opto/callnode.cpp line 1479:

> 1477: #ifdef ASSERT
> 1478:   _alloc(alloc),
> 1479: #endif

May be we should always pass alloc, even in product VM. It is not related to your changes but it is pain to have.

src/hotspot/share/opto/callnode.hpp line 511:

> 509: // by a SafePoint; 2) A scalar replaced object is participating in an allocation
> 510: // merge (Phi) and the Phi is referenced by a SafePoint. The schematics of how
> 511: // 'spobj' is used in both scenarios are described below.

I am not comfortable with reusing SafePointScalarObjectNode for 2) since it describes totally different information.
I think it should be separate Node which points to array of  SFSO  id (in addition to Phis) similar how we do now if SFSO is referenced in other SFSO's field.   SFSO could be created before the merge. Consider:

  Point p = new Point();
  Point q = foo();
  if (cond) {
      q = p;
  }
  trap(p, q);

src/hotspot/share/opto/callnode.hpp line 519:

> 517: //   _nfields     : how many fields the SR object has.
> 518: //   _alloc       : pointer to the Allocate object that previously created the SR object.
> 519: //                  Only used for debug purposes.

May be useful in other cases too in a future not only in debug.

src/hotspot/share/opto/macro.hpp line 196:

> 194:                           Node* size_in_bytes);
> 195: 
> 196:   static Node* make_arraycopy_load(Compile* comp, PhaseIterGVN* igvn, ArrayCopyNode* ac, intptr_t offset, Node* ctl, Node* mem, BasicType ft, const Type *ftype, AllocateNode *alloc);

Why you need this change? It polluted diffs and hide important changes. Could be separate change from this one.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1357285068
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147961058
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147963487
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147991641
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147965112
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147973203


From xliu at openjdk.org  Fri Mar 24 19:56:32 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 24 Mar 2023 19:56:32 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
Message-ID: <OlB0qzAQmWd4mmE2RymaDf7VJ8fjTthhVMFcTC4SFAU=.95b0e982-db39-4fee-afe2-3a845eb38f7c@github.com>

On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for SR'ing some inputs of merges used for field loads

src/hotspot/share/opto/callnode.hpp line 614:

> 612:   int merge_pointer_idx(JVMState* jvms) const {
> 613:     assert(jvms != nullptr, "JVMS reference is null.");
> 614:     return jvms->scloff() + _merge_pointer_idx;

how about we also assert is_from_merge() here? 

Your comment above says that _merge_point_idx is a zero-based index of sfpt's input array. 
here we use scloff-based. I think either is okay, but we need consistency.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148000014


From mchung at openjdk.org  Fri Mar 24 20:49:23 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Mar 2023 20:49:23 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API
Message-ID: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>

This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   

For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 

The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.

To dump lambda proxy classes, set this system property:
   -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>

To dump LambdaForms and method handle implementation, set this system property:
   -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
   
P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

-------------

Commit messages:
 - rename the system property
 - 8304846: Provide a shared utility to dump generated classes defined via Lookup API

Changes: https://git.openjdk.org/jdk/pull/13182/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304846
  Stats: 636 lines in 10 files changed: 317 ins; 262 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/13182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13182/head:pull/13182

PR: https://git.openjdk.org/jdk/pull/13182


From liach at openjdk.org  Fri Mar 24 21:08:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 24 Mar 2023 21:08:31 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API
In-Reply-To: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
Message-ID: <HDQdI2wjmJ2NZIP4mYF8a87EE7tc1VDBPhmpwBtEonQ=.41f5ee76-d489-4cd8-8aea-772509e691b8@github.com>

On Fri, 24 Mar 2023 20:41:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

src/java.base/share/classes/java/lang/invoke/ClassFileDumper.java line 88:

> 86:                 dir = validateDumpDir(Path.of(path.trim()));
> 87:             }
> 88:             DUMPER_MAP.putIfAbsent(key, new ClassFileDumper(key, dir));

Can just return `putIfAbsent` result to avoid another map lookup

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1148045563


From mchung at openjdk.org  Fri Mar 24 23:00:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Mar 2023 23:00:12 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v2]
In-Reply-To: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
Message-ID: <uUdKtY0uRUrxRPFYbTquJGOhPqCu9vvO_RF7P9mP5WQ=.a4e8c9f5-93fa-4b6e-8d7e-599f2f8bdd74@github.com>

> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
> 
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
> 
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
> 
> To dump lambda proxy classes, set this system property:
>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
> 
> To dump LambdaForms and method handle implementation, set this system property:
>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>    
> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  avoid another map lookup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13182/files
  - new: https://git.openjdk.org/jdk/pull/13182/files/d1c739cf..04406e3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13182&range=00-01

  Stats: 14 lines in 1 file changed: 8 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13182/head:pull/13182

PR: https://git.openjdk.org/jdk/pull/13182


From mchung at openjdk.org  Fri Mar 24 23:00:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Mar 2023 23:00:17 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v2]
In-Reply-To: <HDQdI2wjmJ2NZIP4mYF8a87EE7tc1VDBPhmpwBtEonQ=.41f5ee76-d489-4cd8-8aea-772509e691b8@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <HDQdI2wjmJ2NZIP4mYF8a87EE7tc1VDBPhmpwBtEonQ=.41f5ee76-d489-4cd8-8aea-772509e691b8@github.com>
Message-ID: <DfUpe-vl5rxMVkxutBdevbX0GO2q3IZz98CyCcp9kAg=.a126f8d4-e3c6-4264-9222-8c245d80c207@github.com>

On Fri, 24 Mar 2023 20:54:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   avoid another map lookup
>
> src/java.base/share/classes/java/lang/invoke/ClassFileDumper.java line 88:
> 
>> 86:                 dir = validateDumpDir(Path.of(path.trim()));
>> 87:             }
>> 88:             DUMPER_MAP.putIfAbsent(key, new ClassFileDumper(key, dir));
> 
> Can just return `putIfAbsent` result to avoid another map lookup

This is not performance critical.  I updated it anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1148129324


From cslucas at openjdk.org  Fri Mar 24 23:29:29 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 24 Mar 2023 23:29:29 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
Message-ID: <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com>

On Fri, 24 Mar 2023 19:06:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for SR'ing some inputs of merges used for field loads
>
> src/hotspot/share/opto/callnode.cpp line 1479:
> 
>> 1477: #ifdef ASSERT
>> 1478:   _alloc(alloc),
>> 1479: #endif
> 
> May be we should always pass alloc, even in product VM. It is not related to your changes but it is pain to have.

I can make that change.

> src/hotspot/share/opto/macro.hpp line 196:
> 
>> 194:                           Node* size_in_bytes);
>> 195: 
>> 196:   static Node* make_arraycopy_load(Compile* comp, PhaseIterGVN* igvn, ArrayCopyNode* ac, intptr_t offset, Node* ctl, Node* mem, BasicType ft, const Type *ftype, AllocateNode *alloc);
> 
> Why you need this change? It polluted diffs and hide important changes. Could be separate change from this one.

I had to make this method static because it uses `value_from_mem` - which I also made static. I had to make `value_from_mem` static so that I can use it outside PhaseMacroExpand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148141099
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148140607


From kvn at openjdk.org  Fri Mar 24 23:40:31 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 23:40:31 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
 <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com>
Message-ID: <o6msC4bnqaYIl0YQPjv-IPXsHRUbtleyEvcirt5dyog=.56d57ae0-f3bc-4942-942e-066e8fd95856@github.com>

On Fri, 24 Mar 2023 23:24:47 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/opto/macro.hpp line 196:
>> 
>>> 194:                           Node* size_in_bytes);
>>> 195: 
>>> 196:   static Node* make_arraycopy_load(Compile* comp, PhaseIterGVN* igvn, ArrayCopyNode* ac, intptr_t offset, Node* ctl, Node* mem, BasicType ft, const Type *ftype, AllocateNode *alloc);
>> 
>> Why you need this change? It polluted diffs and hide important changes. Could be separate change from this one.
>
> I had to make this method static because it uses `value_from_mem` - which I also made static. I had to make `value_from_mem` static so that I can use it outside PhaseMacroExpand.

I see, you use it in escape.cpp. Okay. I need to review changes there too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148144963


From cslucas at openjdk.org  Fri Mar 24 23:49:31 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 24 Mar 2023 23:49:31 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <OlB0qzAQmWd4mmE2RymaDf7VJ8fjTthhVMFcTC4SFAU=.95b0e982-db39-4fee-afe2-3a845eb38f7c@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <OlB0qzAQmWd4mmE2RymaDf7VJ8fjTthhVMFcTC4SFAU=.95b0e982-db39-4fee-afe2-3a845eb38f7c@github.com>
Message-ID: <9n3UqJDruE0pvA51cFuUGal2gvluNX5LoseLuhvXlIg=.ab6692bd-3aba-4d42-a925-a15ff906677d@github.com>

On Fri, 24 Mar 2023 19:53:52 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for SR'ing some inputs of merges used for field loads
>
> src/hotspot/share/opto/callnode.hpp line 614:
> 
>> 612:   int merge_pointer_idx(JVMState* jvms) const {
>> 613:     assert(jvms != nullptr, "JVMS reference is null.");
>> 614:     return jvms->scloff() + _merge_pointer_idx;
> 
> how about we also assert is_from_merge() here? 
> 
> Your comment above says that _merge_point_idx is a zero-based index of sfpt's input array. 
> here we use scloff-based. I think either is okay, but we need consistency.

I think adding assert is a good idea. I'll fix the comment. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148148247


From cslucas at openjdk.org  Fri Mar 24 23:59:30 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 24 Mar 2023 23:59:30 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
Message-ID: <7xRwVRVapKbqiVQMDMZUh3ILhfaYub_brXWVopFhJ8M=.28289c04-0ff0-4f19-b764-03af4d3155d6@github.com>

On Fri, 24 Mar 2023 19:02:57 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for SR'ing some inputs of merges used for field loads
>
> src/hotspot/share/code/debugInfo.hpp line 199:
> 
>> 197: // ObjectValue describing an object that was scalar replaced.
>> 198: 
>> 199: class ObjectMergeValue: public ScopeValue {
> 
> Why you did not make subclass of ObjectValue? You would need to check `sv->is_object_merge()` first before `sv->is_object()` in few places. But on other hand you don't need to duplicates ObjectValue`s fields and asserts.

Let me try that and see how it looks.

> src/hotspot/share/opto/callnode.hpp line 511:
> 
>> 509: // by a SafePoint; 2) A scalar replaced object is participating in an allocation
>> 510: // merge (Phi) and the Phi is referenced by a SafePoint. The schematics of how
>> 511: // 'spobj' is used in both scenarios are described below.
> 
> I am not comfortable with reusing SafePointScalarObjectNode for 2) since it describes totally different information.
> I think it should be separate Node which points to array of  SFSO  id (in addition to Phis) similar how we do now if SFSO is referenced in other SFSO's field.   SFSO could be created before the merge. Consider:
> 
>   Point p = new Point();
>   Point q = foo();
>   if (cond) {
>       q = p;
>   }
>   trap(p, q);

I had considered that but decided not to do it to prevent adding a new IR node. I'll give that a shot and update this thread with how it goes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148150933
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148151474


From kvn at openjdk.org  Sat Mar 25 00:11:31 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 25 Mar 2023 00:11:31 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <7xRwVRVapKbqiVQMDMZUh3ILhfaYub_brXWVopFhJ8M=.28289c04-0ff0-4f19-b764-03af4d3155d6@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
 <7xRwVRVapKbqiVQMDMZUh3ILhfaYub_brXWVopFhJ8M=.28289c04-0ff0-4f19-b764-03af4d3155d6@github.com>
Message-ID: <gu_ZHFRO-SoFPxYgt-NDukPxS894AwlZQqDPjcRCwl4=.d0b5473e-83f8-42a9-ae38-bed52780fe58@github.com>

On Fri, 24 Mar 2023 23:57:07 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/opto/callnode.hpp line 511:
>> 
>>> 509: // by a SafePoint; 2) A scalar replaced object is participating in an allocation
>>> 510: // merge (Phi) and the Phi is referenced by a SafePoint. The schematics of how
>>> 511: // 'spobj' is used in both scenarios are described below.
>> 
>> I am not comfortable with reusing SafePointScalarObjectNode for 2) since it describes totally different information.
>> I think it should be separate Node which points to array of  SFSO  id (in addition to Phis) similar how we do now if SFSO is referenced in other SFSO's field.   SFSO could be created before the merge. Consider:
>> 
>>   Point p = new Point();
>>   Point q = foo();
>>   if (cond) {
>>       q = p;
>>   }
>>   trap(p, q);
>
> I had considered that but decided not to do it to prevent adding a new IR node. I'll give that a shot and update this thread with how it goes.

It **will** complicate your DebugInfo code (packing/unpacking) information. But I think it is right thing to do to avoid duplicated re-allocations during deoptimization - you should have only one new object.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148154060


From cslucas at openjdk.org  Sat Mar 25 00:11:34 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Sat, 25 Mar 2023 00:11:34 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
Message-ID: <UwoDrrNM4KFSPdw6tbIxBAT9VV6fIRjWpOxPU-taB3I=.01986941-4e67-4a54-8235-31dbcb7c5a71@github.com>

On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for SR'ing some inputs of merges used for field loads

src/hotspot/share/opto/escape.cpp line 3734:

> 3732:       if (reducible_merges.member(n)) {
> 3733:         // Split loads through phi
> 3734:         reduce_this_phi_on_field_access(n->as_Phi(), alloc_worklist);

I decided to do the split here so that Phase 1 of `split_unique_types` could assign a new instance type for the new loads created by `split_through_phi`. However, I'm considering doing the split at the end of `compute_escape` instead of here to keep all the code that does split close together.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148153569


From brian.goetz at oracle.com  Sun Mar 26 17:06:39 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 26 Mar 2023 13:06:39 -0400
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API
In-Reply-To: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
Message-ID: <1535b07c-d226-6e55-e837-a690edfaeb26@oracle.com>

Since LMF goes through Lookup::defineHiddenClass, does this mean that 
they will be potentially dumped twice, once through Lookup, and once 
through LMF?

Now that there is a shared implementation, perhaps we should migrate use 
in LMF to something more like

    -Djava.lang.invoke.MethodHandle.DUMP_LAMBDA_PROXY_CLASS_FILES=true

and retire the separate dumpProxyClasses flag.

On 3/24/2023 4:49 PM, Mandy Chung wrote:
> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>`
>
> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230326/92fb55cf/attachment.htm>

From shade at openjdk.org  Mon Mar 27 08:47:34 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 27 Mar 2023 08:47:34 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <QDqHW-zI6dye4c0IMwx7qgu5VbvFV3f0oYlCCsC4FH0=.6c3997cb-ef93-4b43-be1a-ea3171eaa57c@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

Drive-by comment: If the exception creation is the problem, maybe we should turn it stackless (overriding the `fillInStackTrace` in the subclass of `BadPaddingException`), assuming this exception does not leak out of the method to the users and/or users do not require the stack trace. This would not put us into security-related discussion whether moving the exception on conditional path improves the fidelity of timing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12732#issuecomment-1484745045


From xuelei at openjdk.org  Mon Mar 27 16:05:53 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 27 Mar 2023 16:05:53 GMT
Subject: RFR: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <QDqHW-zI6dye4c0IMwx7qgu5VbvFV3f0oYlCCsC4FH0=.6c3997cb-ef93-4b43-be1a-ea3171eaa57c@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
 <QDqHW-zI6dye4c0IMwx7qgu5VbvFV3f0oYlCCsC4FH0=.6c3997cb-ef93-4b43-be1a-ea3171eaa57c@github.com>
Message-ID: <xPzpSDkoHwD26FUVFhuc_5xZFcfD2AhFX9jxBmI5mOw=.04618d85-2ce4-4d55-a27d-96b5dad244a1@github.com>

On Mon, 27 Mar 2023 08:44:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> If the exception creation is the problem, maybe we should turn it stackless

This is one direction of the update, I think.  Alternatively, it may be doable by not using exception in the unpad() implementation any longer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12732#issuecomment-1485407309


From duke at openjdk.org  Tue Mar 28 17:57:38 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:38 GMT
Subject: RFR: 8302819: Remove JAR Index
Message-ID: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>

This PR removes the JAR index feature from the runtime:

- `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
- The `JarIndex` implementation class is moved into `jdk.jartool` module.
- The `InvalidJarIndexError` exception class is removed because it falls out of use
- The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
- The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
- The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
- All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
- `JarIndex` is given package-private access.

Outstanding code work:

- Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.

Outstanding work:

- CSR for the removal
- Release notes for the removal
- Coordination of the update of the Jar File Specification

-------------

Commit messages:
 - Remove JarIndex default constructor
 - Make JarIndex.INDEX_NAME package private
 - Remove outdated reference to URLClassLoader using JarIndex
 - Make JarIndex package private
 - The JarIndex.merge method ended up being used only by the JarIndexMergeTest test. Removing this test, the JarIndex.merge methods and a number of other JarIndex methods not used by the 'jar' tool
 - Revert the export of sun.security.action to jdk.jartool. JarIndex can use System.property instead since the 'jar' tool does not run with a SecurityManager
 - Revert noisy whitespace changes
 - Revert noisy whitespace changes
 - Remove jar index feature from the runtime. Move JarIndex into jdk.jartool. Remove tests which depend on the jar index feature being considered during class loading.

Changes: https://git.openjdk.org/jdk/pull/13158/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302819
  Stats: 1809 lines in 24 files changed: 221 ins; 1576 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13158/head:pull/13158

PR: https://git.openjdk.org/jdk/pull/13158


From duke at openjdk.org  Tue Mar 28 17:57:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:44 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <viS-x5O7Al7Cf-CsvKSo2ex-P9GN_WxLTVA_viHVTvY=.b15b21ff-5a88-44a1-8b85-adb78a013aec@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
 <viS-x5O7Al7Cf-CsvKSo2ex-P9GN_WxLTVA_viHVTvY=.b15b21ff-5a88-44a1-8b85-adb78a013aec@github.com>
Message-ID: <Yzccg0slHHHj4tWomzy8iyMHb1J82syDycIsb5fCYpc=.5e34e640-e2ec-4a07-9d19-50eaf0e423fc@github.com>

On Thu, 23 Mar 2023 15:10:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I don't think we should be exporting that package. Instead, the `JarIndex` class can be updated to do `AccessController.doPrivileged(...)`.

Nice, I'll try that!

 Do you know if the `jar` tool allows running with a `SecurityManager`? If not, we could perhaps simply use `System.getProperty`?

@jaikiran made the good observation that the `JarIndex` class has various cruft left which is not needed for the `jar -i` implementation.

Since we at the moment do not know when `jar -i` will be removed (if ever), we would risk leaving a lot of unused code around if we chose to postpone this cleanup.

Becuse of this, I suggest we extend the scope of this PR to clean up `IndexJar` for use by `jdk.jartool` only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481407490
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481783142


From duke at openjdk.org  Tue Mar 28 17:57:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:44 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <Yzccg0slHHHj4tWomzy8iyMHb1J82syDycIsb5fCYpc=.5e34e640-e2ec-4a07-9d19-50eaf0e423fc@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
 <viS-x5O7Al7Cf-CsvKSo2ex-P9GN_WxLTVA_viHVTvY=.b15b21ff-5a88-44a1-8b85-adb78a013aec@github.com>
 <Yzccg0slHHHj4tWomzy8iyMHb1J82syDycIsb5fCYpc=.5e34e640-e2ec-4a07-9d19-50eaf0e423fc@github.com>
Message-ID: <yb_PJJGbDEThvneXZ0-Aui_A1YGlchfBHfaoBiyNv9k=.a3d5740d-ac30-4527-9bb6-45ab4458296c@github.com>

On Thu, 23 Mar 2023 15:31:31 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Do you know if the `jar` tool allows running with a `SecurityManager`? If not, we could perhaps simply use `System.getProperty`?

I ended up feeling opimistic and replaced the current code with just `System.getProperty`. If that is any concern doing that, let me know and I can use `AccessController` instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481727128


From jpai at openjdk.org  Tue Mar 28 17:57:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 17:57:39 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>

On Thu, 23 Mar 2023 12:05:50 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Hello Eirik,

> Note that this PR does not aim to remove the ability for the jar tool to produce JAR files with indexes. Such a removal could be handled separately from this PR.

My understanding of https://bugs.openjdk.org/browse/JDK-8302819 is that we are removing the JAR Index since it is no longer usable in recent versions.

The work, that by default disabled support for jar indexes in URLClassLoader https://bugs.openjdk.org/browse/JDK-8273473 did not deprecate the `jar -i` option and explicitly noted that it would continue to work the way it used to.
Perhaps now is the time to add a deprecation/warning message when `jar -i` option is used? JDK-8302819 does note this as a possibility as part of this change:
> The jar -i (--generate-index=FILE) option can continue to generate the JAR index or the option can be changed to just emit a warning.

> 
>  The `InvalidJarIndexError` exception class is removed because it falls out of use

Since `Throwable` classes are serializable, I looked up the serialization spec to see if this removal would have any compatibility issues that need to be accounted for. The specification https://docs.oracle.com/en/java/javase/20/docs/specs/serialization/version.html#compatible-changes states that removing classes is a compatible change, so this should be fine. Plus, this exception appears to be thrown only when index file is being processed (as the name suggests).

Sorry my previous message wasn't clear.

> Hooking in a simple deprecation warning in this PR would propably not require a lot of extra review cycles, perhaps the opposite. So I'm happy to do that if that is what you meant

Yes, that's what I meant - I think we should add a warning message when that option is used, as part of these changes. I don't think we can completely remove that option in this release, since it wasn't deprecated (for removal) before, so it would be a good idea to start warning. Like you, I too would let Alan provide guidance on whether this should be done as part of this PR.

Hello Eirik, thank you for the updates to the PR.
I see that Alan suggested that we take up the `jar -i` deprecation in a separate PR. I think that simplifies the work in this PR. I'll run some tests with these changes and do another review soon, but you don't have to wait for it, if you want to move this PR out of draft status.

Hello Eirik, I ran our tier tests against the current state of this PR and they came back fine.

With the removal of support for `META-INF/INDEX.LIST`, this PR rightly removes the related test cases. I think we should introduce a new test class with some test methods which verifies that the `java.util.jar.JarFile` and `java.util.jar.JarInputStream` APIs continue to work fine when they are presented with a jar which has a `META-INF/INDEX.LIST`. Some such tests would be to use these APIs to load:

 - A jar which has a META-INF/MANIFEST.MF and a META-INF/INDEX.LIST
 - A jar which has a META-INF/INDEX.LIST but no manifest file
 - A signed jar which has a META-INF/INDEX.LIST

Adding these tests I think will help us verify that these APIs  and also exercise the code in these classes where we have checks for `META-INF/INDEX.LIST` entry. Is that something you could consider adding as part of this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481267431
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481283448
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481306676
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1483076228
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1485073282


From jpai at openjdk.org  Tue Mar 28 17:57:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 17:57:45 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <Yzccg0slHHHj4tWomzy8iyMHb1J82syDycIsb5fCYpc=.5e34e640-e2ec-4a07-9d19-50eaf0e423fc@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
 <viS-x5O7Al7Cf-CsvKSo2ex-P9GN_WxLTVA_viHVTvY=.b15b21ff-5a88-44a1-8b85-adb78a013aec@github.com>
 <Yzccg0slHHHj4tWomzy8iyMHb1J82syDycIsb5fCYpc=.5e34e640-e2ec-4a07-9d19-50eaf0e423fc@github.com>
Message-ID: <6yfUz_5fyZiGWdcg6s6KuwtX12GUHZkuovhdtVQuYs4=.c7fa3c4e-fa12-4d33-97bc-a3da172589d3@github.com>

On Thu, 23 Mar 2023 15:31:31 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > I don't think we should be exporting that package. Instead, the `JarIndex` class can be updated to do `AccessController.doPrivileged(...)`.
> 
> Nice, I'll try that!
> 
> Do you know if the `jar` tool allows running with a `SecurityManager`? If not, we could perhaps simply use `System.getProperty`?

I had a look at the existing code in the jar tool. It appears that it doesn't run with a SecurityManager - there's direct calls to `System.getProperty()` in some places in the code. So I think just calling `System.getProperty()` should be fine. When this PR goes into a published state for review, I'm sure others who have more knowledge about this area will help decide.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1482267543


From duke at openjdk.org  Tue Mar 28 17:57:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:46 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <6yfUz_5fyZiGWdcg6s6KuwtX12GUHZkuovhdtVQuYs4=.c7fa3c4e-fa12-4d33-97bc-a3da172589d3@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
 <viS-x5O7Al7Cf-CsvKSo2ex-P9GN_WxLTVA_viHVTvY=.b15b21ff-5a88-44a1-8b85-adb78a013aec@github.com>
 <Yzccg0slHHHj4tWomzy8iyMHb1J82syDycIsb5fCYpc=.5e34e640-e2ec-4a07-9d19-50eaf0e423fc@github.com>
 <6yfUz_5fyZiGWdcg6s6KuwtX12GUHZkuovhdtVQuYs4=.c7fa3c4e-fa12-4d33-97bc-a3da172589d3@github.com>
Message-ID: <pguXFnJ_6JtAXuHsLuVOG8y03du3iD1jI7-NAOzeaOk=.eaff03af-f2a5-4500-8ca2-2461224a3a8b@github.com>

On Fri, 24 Mar 2023 05:20:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> I don't think we should be exporting that package. Instead, the `JarIndex` class can be updated to do `AccessController.doPrivileged(...)`.
>> 
>> Nice, I'll try that!
>> 
>>  Do you know if the `jar` tool allows running with a `SecurityManager`? If not, we could perhaps simply use `System.getProperty`?
>
>> > I don't think we should be exporting that package. Instead, the `JarIndex` class can be updated to do `AccessController.doPrivileged(...)`.
>> 
>> Nice, I'll try that!
>> 
>> Do you know if the `jar` tool allows running with a `SecurityManager`? If not, we could perhaps simply use `System.getProperty`?
> 
> I had a look at the existing code in the jar tool. It appears that it doesn't run with a SecurityManager - there's direct calls to `System.getProperty()` in some places in the code. So I think just calling `System.getProperty()` should be fine. When this PR goes into a published state for review, I'm sure others who have more knowledge about this area will help decide.

@jaikiran 

Looking into how the deprecation warning could be implemented, it seems `jar` has some existing infrastructure for deprecation warnings, so the deprecation could be implemented with the following small patch:


Subject: [PATCH] Remove JarIndex default constructor
---
Index: src/jdk.jartool/share/classes/sun/tools/jar/Main.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/jdk.jartool/share/classes/sun/tools/jar/Main.java b/src/jdk.jartool/share/classes/sun/tools/jar/Main.java
--- a/src/jdk.jartool/share/classes/sun/tools/jar/Main.java	(revision fee0da27be832a7413886ddd2cfd5586bfd2e37a)
+++ b/src/jdk.jartool/share/classes/sun/tools/jar/Main.java	(date 1679654673667)
@@ -396,6 +396,9 @@
                     }
                 }
             } else if (iflag) {
+                if (!suppressDeprecateMsg) {
+                    warn(formatMsg("warn.flag.is.deprecated", "-i"));
+                }
                 String[] files = filesMap.get(BASE_VERSION);  // base entries only, can be null
                 genIndex(rootjar, files);
             } else if (dflag) {


This gives the following warning message on use:


% build/macosx-x86_64-server-release/images/jdk/bin/jar --generate-index file.jar
Warning: The -i option is deprecated, and is planned for removal in a future JDK release


Which may be overridden by using `-XDsuppress-tool-removal-message`:


% build/macosx-x86_64-server-release/images/jdk/bin/jar --generate-index file.jar -XDsuppress-tool-removal-message

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1482612735


From alanb at openjdk.org  Tue Mar 28 17:57:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 17:57:48 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
Message-ID: <o4sZE_ctiQcXuaVIJhqhtTQ-0BkUwYvlhRuLTIOl3So=.a44c8f55-5456-4ca3-8b9d-5349cd097d38@github.com>

On Fri, 24 Mar 2023 16:22:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I see that Alan suggested that we take up the `jar -i` deprecation in a separate PR. I think that simplifies the work in this PR.

Yes, there are options for `jar -i` that include "leave it as is", have the option create the index and emit a warning that the feature is deprecated, or remove the index creation and emit a warning that it is ignored. I don't think we should change "jar -i` to fail with an error as that would break existing scripts. None of these directions impact the JAR file spec or the API docs, it's just the jar tool so I think can be separated to another PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1483778627


From alanb at openjdk.org  Tue Mar 28 17:57:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 17:57:48 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <46YSN3xN-klcZdEOVWQgKIp1rxW0Zpt9Ad1uJ2CoYIs=.8f277496-0f2c-456c-b897-7ac416876c0e@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
 <46YSN3xN-klcZdEOVWQgKIp1rxW0Zpt9Ad1uJ2CoYIs=.8f277496-0f2c-456c-b897-7ac416876c0e@github.com>
Message-ID: <wlNxvDyqXPcdi8OWdDXPGATHV0HCflMc01aESvFkwms=.db1241a3-fede-4bbf-9bf0-8b218656b7de@github.com>

On Mon, 27 Mar 2023 17:12:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > Adding these tests I think will help us verify that these APIs and also exercise the code in these classes where we have checks for `META-INF/INDEX.LIST` entry. Is that something you could consider adding as part of this PR?
> 
> Yes, I agree this should be done. For now, I've added a note in the "Outstanding code work" section at the top of this PR.

Adding a test would be good. In the mean-time, I think it would be good to get the review started to flush out any concerns about removing this index.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1486914564


From duke at openjdk.org  Tue Mar 28 17:57:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:48 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <wlNxvDyqXPcdi8OWdDXPGATHV0HCflMc01aESvFkwms=.db1241a3-fede-4bbf-9bf0-8b218656b7de@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
 <46YSN3xN-klcZdEOVWQgKIp1rxW0Zpt9Ad1uJ2CoYIs=.8f277496-0f2c-456c-b897-7ac416876c0e@github.com>
 <wlNxvDyqXPcdi8OWdDXPGATHV0HCflMc01aESvFkwms=.db1241a3-fede-4bbf-9bf0-8b218656b7de@github.com>
Message-ID: <opf9QDMU5eSv8ofVGX6Cg7vhpONXA6OqoSHiN4Gj6So=.9a191f02-ff7d-462b-a9a0-1cb6cd28a5f3@github.com>

On Tue, 28 Mar 2023 13:42:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>Adding a test would be good. In the mean-time, I think it would be good to get the review started to flush out any concerns about removing this index.

Good! I will mark this ready for review. 

(I did not find time to write a test today)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1487361023


From duke at openjdk.org  Tue Mar 28 17:57:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:41 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <lGc_ni0SO3SW-l37MsMvMjmr7w4v_n2NTuVcAisXo3E=.bd3180ba-1880-4102-bcc2-03a75d149a81@github.com>

On Thu, 23 Mar 2023 12:05:50 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

If we include the deprecation of `jar -i` in this PR, then the CSR for this PR would need to also cover that deprecation. Same is true for release notes. Not seeing any problem with that myself, but thought it would be good to take note here.

Regarding `JarIndex`:

>Additionally you could even make it package-private there, instead of public. It would anyway need some updates to its javadoc and maybe remove any no longer used methods.

Making it package-private did not work because of the `JarIndexMergeTest` test which directly depends on `JarIndex`. Changing package of the test did not work because of split packages.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481314347
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481730500


From duke at openjdk.org  Tue Mar 28 17:57:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 17:57:41 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
Message-ID: <46YSN3xN-klcZdEOVWQgKIp1rxW0Zpt9Ad1uJ2CoYIs=.8f277496-0f2c-456c-b897-7ac416876c0e@github.com>

On Thu, 23 Mar 2023 14:09:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Perhaps now is the time to add a deprecation/warning message when `jar -i` option is used?

I'm not entirely sure I know what you mean or suggest here, so I'll try to be explicit with what I do (think I) understand and what my reasoning is:

I one of my early comments on JDK-8302819, I suggest / recommend that the deprecation and/or eventual removal of the `jar -i` options is handled as a follow-up to this PR. My reasoning was the usual concerns about PRs: Reducing the scope seems to make the review process simpler, faster, more efficient.

Hooking in a simple deprecation warning  in this PR would propably not require a lot of extra review cycles, perhaps the opposite. So I'm happy to do that if that is what you meant and Alan also agrees.

Do you think I understood your comment?

> Sorry my previous message wasn't clear.

Thanks for clarifying, Jaikiran. I think our understanding is in sync now, which is always good!

@jaikiran Do you agree with the move of `JarIndex` from `java.base` to `jdk.jartool`? Since it ends up only being used there, I thought it would be cleaner if we moved it. But the move is not strictly necessary. What's your thoughts?

> Like you, I too would let Alan provide guidance on whether this should be done as part of this PR.

The alternative to including it in this PR would be to do it immediately following the integration of this PR. For users it maybe does not matter much as long as two changes are included in the same JDK/Java SE version?

> Adding these tests I think will help us verify that these APIs and also exercise the code in these classes where we have checks for `META-INF/INDEX.LIST` entry. Is that something you could consider adding as part of this PR?

Yes, I agree this should be done. For now, I've added a note in the "Outstanding code work" section at the top of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481293806
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481309871
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481321377
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481348568
PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1485529082


From jpai at openjdk.org  Tue Mar 28 17:57:43 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Mar 2023 17:57:43 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
Message-ID: <viS-x5O7Al7Cf-CsvKSo2ex-P9GN_WxLTVA_viHVTvY=.b15b21ff-5a88-44a1-8b85-adb78a013aec@github.com>

On Thu, 23 Mar 2023 14:33:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Sorry my previous message wasn't clear.
> 
>> Hooking in a simple deprecation warning in this PR would propably not require a lot of extra review cycles, perhaps the opposite. So I'm happy to do that if that is what you meant
> 
> Yes, that's what I meant - I think we should add a warning message when that option is used, as part of these changes. I don't think we can completely remove that option in this release, since it wasn't deprecated (for removal) before, so it would be a good idea to start warning. Like you, I too would let Alan provide guidance on whether this should be done as part of this PR.

> @jaikiran Do you agree with the move of `JarIndex` from `java.base` to `jdk.jartool`? Since it ends up only being used there, I thought it would be cleaner if we moved it. But the move is not strictly necessary. What's your thoughts?

With the changes in this PR, the `JarIndex` (an internal) class would only be relevant/useful in the `jar` tool. So I think it makes sense to move it to the `jdk.jartool` module. Additionally you could even make it package-private there, instead of public. It would anyway need some updates to its javadoc and maybe remove any no longer used methods.

On a related note, I see that the `module-info.java` of `java.base` module has been updated to export `sun.security.action` package to the `jdk.jartool`. I think that is because the (now moved) `JarIndex` uses the `sun.security.action.GetPropertyAction.privilegedGetProperty` utility method to read a system property. I don't think we should be exporting that package. Instead, the `JarIndex` class can be updated to do `AccessController.doPrivileged(...)`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1481371199


From lancea at openjdk.org  Tue Mar 28 18:34:32 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 28 Mar 2023 18:34:32 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <o4sZE_ctiQcXuaVIJhqhtTQ-0BkUwYvlhRuLTIOl3So=.a44c8f55-5456-4ca3-8b9d-5349cd097d38@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
 <o4sZE_ctiQcXuaVIJhqhtTQ-0BkUwYvlhRuLTIOl3So=.a44c8f55-5456-4ca3-8b9d-5349cd097d38@github.com>
Message-ID: <d54DmnqKcvTGRk2GI-NWthlg6YGOlzYmFDQlbs8gF-w=.dc7792f8-17ec-4f8a-b9a9-97ec750129c5@github.com>

On Sat, 25 Mar 2023 09:35:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I see that Alan suggested that we take up the `jar -i` deprecation in a separate PR. I think that simplifies the work in this PR.
> 
> Yes, there are options for `jar -i` that include "leave it as is", have the option create the index and emit a warning that the feature is deprecated, or remove the index creation and emit a warning that it is ignored. I don't think we should change "jar -i` to fail with an error as that would break existing scripts. None of these directions impact the JAR file spec or the API docs, it's just the jar tool so I think can be separated to another PR.

Agree, we should handle this separately.  If we are thinking of emitting a warning, we probably should do that in = JDK 22  as that could break tests with golden files so we might want to give a heads up in JDK 21  before doing this

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1487416516


From alanb at openjdk.org  Tue Mar 28 19:34:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 19:34:29 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <d54DmnqKcvTGRk2GI-NWthlg6YGOlzYmFDQlbs8gF-w=.dc7792f8-17ec-4f8a-b9a9-97ec750129c5@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <T70-cjOy3hGPoLj5CjNdBFzjPfBnn3XaSy6InShNoAA=.49c78008-1332-423d-b961-0f77c7468f4f@github.com>
 <o4sZE_ctiQcXuaVIJhqhtTQ-0BkUwYvlhRuLTIOl3So=.a44c8f55-5456-4ca3-8b9d-5349cd097d38@github.com>
 <d54DmnqKcvTGRk2GI-NWthlg6YGOlzYmFDQlbs8gF-w=.dc7792f8-17ec-4f8a-b9a9-97ec750129c5@github.com>
Message-ID: <xGnV824S7P-mSHbPoV150GkoHiGz2dpBhGbh4VW3l3E=.a58bf03d-a564-49f9-93c5-3230147916a5@github.com>

On Tue, 28 Mar 2023 18:31:28 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> If we are thinking of emitting a warning, we probably should do that in = JDK 22 as that could break tests with golden files so we might want to give a heads up in JDK 21 before doing this

The best option might be to just have `jar -i` work as before (as it does in the current proposal) but have it warn that -i may be changed to do nothing and/or be removed in a future release. If there are tests that looking for META/INDEX.list then they will work as before.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1487486680


From mchung at openjdk.org  Tue Mar 28 20:13:33 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 28 Mar 2023 20:13:33 GMT
Subject: RFR: 8302819: Remove JAR Index
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <F_Yb-1akb5O4V7YyeMmNtfk63HRaDXIRbjaKl-IxPkw=.5bae9f27-efd2-4d30-9d81-eb056c90dab3@github.com>

On Thu, 23 Mar 2023 12:05:50 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Happy to see this work!  This change looks fine in general.    I agree that it's good to keep this issue to remove the runtime support and separate the `jar -i` change.   JDK tools don't run with security manager enabled and no need to wrap `System::getProperty` with `doPrivileged`.

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 936:

> 934:         @Override
> 935:         URL[] getClassPath() throws IOException {
> 936: 

Nit: extra line 936 can be removed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1361828286
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1151099546


From duke at openjdk.org  Wed Mar 29 16:42:47 2023
From: duke at openjdk.org (Ahmed Muhsin)
Date: Wed, 29 Mar 2023 16:42:47 GMT
Subject: Withdrawn: 8302017: Allocate BadPaddingException only if it will be
 thrown
In-Reply-To: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
References: <ccp2VLzXDZu-ii6WRmuY4-gep79YNSyB-_PyQiEgneU=.a3cd3d25-3c4c-40cd-a72a-07023b949cf3@github.com>
Message-ID: <CgLjJE26p-aGsgbaHyUOMxys7q_XA_9wtLjDIMBH0qs=.a1c05145-af9b-4756-bd94-ac0ff4c5fab2@github.com>

On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin <duke at openjdk.org> wrote:

> This change will move the instantiation of BadPaddingException into the branch of the if statement where it is thrown. This will decrease the overhead of calling `unpadV15` and `unpadOAEP`.  Please see the associated work item for past discussions regarding this change.
> 
> The build and tier1 tests pass locally on mac-aarch64.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12732


From duke at openjdk.org  Wed Mar 29 19:55:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 19:55:37 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <KokXTJwqLA8w3ChsLXAdx2Gs6d1o5A-r31r20xLFH98=.90fc12fb-7ccf-4cde-bd50-4bdc0a52cb29@github.com>

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Remove blank line 93 as per suggestion by Mandy
 - Merge branch 'master' into remove-jar-index
 - Remove JarIndex default constructor
 - Make JarIndex.INDEX_NAME package private
 - Remove outdated reference to URLClassLoader using JarIndex
 - Make JarIndex package private
 - The JarIndex.merge method ended up being used only by the JarIndexMergeTest test. Removing this test, the JarIndex.merge methods and a number of other JarIndex methods not used by the 'jar' tool
 - Revert the export of sun.security.action to jdk.jartool. JarIndex can use System.property instead since the 'jar' tool does not run with a SecurityManager
 - Revert noisy whitespace changes
 - Revert noisy whitespace changes
 - ... and 1 more: https://git.openjdk.org/jdk/compare/599939df...2b5d8a4a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13158/files
  - new: https://git.openjdk.org/jdk/pull/13158/files/fee0da27..2b5d8a4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=00-01

  Stats: 12002 lines in 289 files changed: 4769 ins; 5962 del; 1271 mod
  Patch: https://git.openjdk.org/jdk/pull/13158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13158/head:pull/13158

PR: https://git.openjdk.org/jdk/pull/13158


From duke at openjdk.org  Wed Mar 29 19:55:40 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 19:55:40 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <F_Yb-1akb5O4V7YyeMmNtfk63HRaDXIRbjaKl-IxPkw=.5bae9f27-efd2-4d30-9d81-eb056c90dab3@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <F_Yb-1akb5O4V7YyeMmNtfk63HRaDXIRbjaKl-IxPkw=.5bae9f27-efd2-4d30-9d81-eb056c90dab3@github.com>
Message-ID: <4MdPoBeCqEuqUw0f5bJ9Rb6yFl_nN0nhcb6CvOTnrvI=.d5b580d5-c8c3-4acc-8422-8b1ecd9d8b85@github.com>

On Tue, 28 Mar 2023 20:06:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Remove blank line 93 as per suggestion by Mandy
>>  - Merge branch 'master' into remove-jar-index
>>  - Remove JarIndex default constructor
>>  - Make JarIndex.INDEX_NAME package private
>>  - Remove outdated reference to URLClassLoader using JarIndex
>>  - Make JarIndex package private
>>  - The JarIndex.merge method ended up being used only by the JarIndexMergeTest test. Removing this test, the JarIndex.merge methods and a number of other JarIndex methods not used by the 'jar' tool
>>  - Revert the export of sun.security.action to jdk.jartool. JarIndex can use System.property instead since the 'jar' tool does not run with a SecurityManager
>>  - Revert noisy whitespace changes
>>  - Revert noisy whitespace changes
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/599939df...2b5d8a4a
>
> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 936:
> 
>> 934:         @Override
>> 935:         URL[] getClassPath() throws IOException {
>> 936: 
> 
> Nit: extra line 936 can be removed.

Thank to @mlchung,  line 936 is now history!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1152412960


From vrudomet at openjdk.org  Thu Mar 30 05:04:10 2023
From: vrudomet at openjdk.org (Victor Rudometov)
Date: Thu, 30 Mar 2023 05:04:10 GMT
Subject: RFR: JDK-8305211: Remove CA certificates that are expired
Message-ID: <TJuMM7NrPJW-WPQEB65f5VVxR6rRgZ0Yxx2RjUo5TYI=.fb972ccc-5156-48d7-821c-b546029f5c08@github.com>

Removed 6 CA certificates that are expired, updated VerifyCACerts test

Build passed, jtreg test VerifyCACerts passed.

-------------

Commit messages:
 - 8305211: Remove CA certificates that are expired

Changes: https://git.openjdk.org/jdk/pull/13237/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13237&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305211
  Stats: 220 lines in 7 files changed: 1 ins; 217 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13237/head:pull/13237

PR: https://git.openjdk.org/jdk/pull/13237


From alanb at openjdk.org  Thu Mar 30 07:08:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 07:08:21 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <KokXTJwqLA8w3ChsLXAdx2Gs6d1o5A-r31r20xLFH98=.90fc12fb-7ccf-4cde-bd50-4bdc0a52cb29@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KokXTJwqLA8w3ChsLXAdx2Gs6d1o5A-r31r20xLFH98=.90fc12fb-7ccf-4cde-bd50-4bdc0a52cb29@github.com>
Message-ID: <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>

On Wed, 29 Mar 2023 19:55:37 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR removes the JAR index feature from the runtime:
>> 
>> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
>> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
>> - The `InvalidJarIndexError` exception class is removed because it falls out of use
>> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
>> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
>> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
>> - `JarIndex` is given package-private access.
>> 
>> Outstanding code work:
>> 
>> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
>> 
>> Outstanding work:
>> 
>> - CSR for the removal
>> - Release notes for the removal
>> - Coordination of the update of the Jar File Specification
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Remove blank line 93 as per suggestion by Mandy
>  - Merge branch 'master' into remove-jar-index
>  - Remove JarIndex default constructor
>  - Make JarIndex.INDEX_NAME package private
>  - Remove outdated reference to URLClassLoader using JarIndex
>  - Make JarIndex package private
>  - The JarIndex.merge method ended up being used only by the JarIndexMergeTest test. Removing this test, the JarIndex.merge methods and a number of other JarIndex methods not used by the 'jar' tool
>  - Revert the export of sun.security.action to jdk.jartool. JarIndex can use System.property instead since the 'jar' tool does not run with a SecurityManager
>  - Revert noisy whitespace changes
>  - Revert noisy whitespace changes
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/e90f7996...2b5d8a4a

This looks good. I've added the "csr" label to the PR.

For "jar -i", I think we are converging on the option to just add a warning, meaning it will generated/update the index as before, but emit a warning that JAR Index is ignored since JDK 18. It doesn't matter if we do this in this PR or a separate PR. For CSR and release note purposes it would be a bit easier if it was this PR, would that be okay?

src/java.base/share/classes/java/util/jar/JarFile.java line 212:

> 210:     /**
> 211:      * The 'JAR index' feature has been removed, but we still need to
> 212:      * process existing files which have this entry.

"but we still need ..."   Maybe better to say that that JarInputStream and the verification of signed JARs need to skip this attribute.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 73:

> 71: import jdk.internal.opt.CommandLine;
> 72: 
> 73: import java.time.LocalDateTime;

This can move up to the imports of the other java.* classes.

test/jdk/java/util/jar/JarFile/mrjar/TestVersionedStream.java line 29:

> 27:  * @summary basic tests for multi-release jar versioned streams
> 28:  * @library /test/lib
> 29:  * @modules jdk.jartool/sun.tools.jar

This test could be changed to use ToolProvider.findFirst("jar") and it would avoid needing to use sun.tools.jar.Main directly.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13158#pullrequestreview-1364446354
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1152816329
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1152817035
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1152814946


From duke at openjdk.org  Thu Mar 30 11:03:22 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 11:03:22 GMT
Subject: RFR: 8302819: Remove JAR Index [v3]
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <zgVZKsf435wbZ1L0blBV1TFT2piCiM65YUSiRk1Lljs=.01408e4c-356e-4d4b-8434-637bfe8fc069@github.com>

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Use ToolProvider.findFirst("jar") instead of calling sun.tools.jar.Main directly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13158/files
  - new: https://git.openjdk.org/jdk/pull/13158/files/2b5d8a4a..959af030

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13158/head:pull/13158

PR: https://git.openjdk.org/jdk/pull/13158


From duke at openjdk.org  Thu Mar 30 11:17:05 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 11:17:05 GMT
Subject: RFR: 8302819: Remove JAR Index [v4]
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <0VNpuRIuvQZNjeKkVft2Ll2AoS4PNSiiNXVpTeALzHQ=.6460b10b-9cb9-4900-8569-045b7e24a9af@github.com>

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:

 - Add warning that the "jar -i" operation is deprecated and planned for removal:
   
   Warning: The -i option is deprecated, and is planned for removal in a future JDK release
 - Move the import of "java.time.LocalDateTime" into the other "import java.*" imports
 - Be more specific about which classes/code "still need to process" the META-INF/INDEX.LIST entry.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13158/files
  - new: https://git.openjdk.org/jdk/pull/13158/files/959af030..26c47b01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=02-03

  Stats: 9 lines in 2 files changed: 5 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13158/head:pull/13158

PR: https://git.openjdk.org/jdk/pull/13158


From duke at openjdk.org  Thu Mar 30 11:17:12 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 11:17:12 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KokXTJwqLA8w3ChsLXAdx2Gs6d1o5A-r31r20xLFH98=.90fc12fb-7ccf-4cde-bd50-4bdc0a52cb29@github.com>
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
Message-ID: <WU82Cv-9SJ1tRVEE3iw7N9Jc0fBwJx0Bw7YcPrSIsxU=.09d5087d-67c4-4a07-af1f-602e6ba98965@github.com>

On Thu, 30 Mar 2023 07:00:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Remove blank line 93 as per suggestion by Mandy
>>  - Merge branch 'master' into remove-jar-index
>>  - Remove JarIndex default constructor
>>  - Make JarIndex.INDEX_NAME package private
>>  - Remove outdated reference to URLClassLoader using JarIndex
>>  - Make JarIndex package private
>>  - The JarIndex.merge method ended up being used only by the JarIndexMergeTest test. Removing this test, the JarIndex.merge methods and a number of other JarIndex methods not used by the 'jar' tool
>>  - Revert the export of sun.security.action to jdk.jartool. JarIndex can use System.property instead since the 'jar' tool does not run with a SecurityManager
>>  - Revert noisy whitespace changes
>>  - Revert noisy whitespace changes
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/85c16dfb...2b5d8a4a
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 212:
> 
>> 210:     /**
>> 211:      * The 'JAR index' feature has been removed, but we still need to
>> 212:      * process existing files which have this entry.
> 
> "but we still need ..."   Maybe better to say that that JarInputStream and the verification of signed JARs need to skip this attribute.

I rephrased this to be more specific about which code still needs this. Agree "we" is not the best choice of subject here.

> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 73:
> 
>> 71: import jdk.internal.opt.CommandLine;
>> 72: 
>> 73: import java.time.LocalDateTime;
> 
> This can move up to the imports of the other java.* classes.

Fixed.

> test/jdk/java/util/jar/JarFile/mrjar/TestVersionedStream.java line 29:
> 
>> 27:  * @summary basic tests for multi-release jar versioned streams
>> 28:  * @library /test/lib
>> 29:  * @modules jdk.jartool/sun.tools.jar
> 
> This test could be changed to use ToolProvider.findFirst("jar") and it would avoid needing to use sun.tools.jar.Main directly.

An improvement a bit unrelated to this PR, but it was a simple change so I have implemented it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1153102163
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1153102298
PR Review Comment: https://git.openjdk.org/jdk/pull/13158#discussion_r1153101442


From duke at openjdk.org  Thu Mar 30 11:19:20 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 11:19:20 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KokXTJwqLA8w3ChsLXAdx2Gs6d1o5A-r31r20xLFH98=.90fc12fb-7ccf-4cde-bd50-4bdc0a52cb29@github.com>
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
Message-ID: <Ncibs2_GcTTW7K_4iL28V_HNMl6ofDMibKU184wlIEU=.f048803a-c059-4717-aa43-48fbc7ddcb01@github.com>

On Thu, 30 Mar 2023 07:05:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> For CSR and release note purposes it would be a bit easier if it was this PR, would that be okay?

We seem to have wiggled a bit on this issue, but I'm ok with including it.

I have implemented the -i warning using the existing warnings strings already in place in `jar`. This means the following warning will be output:


% build/macosx-x86_64-server-release/images/jdk/bin/jar --generate-index file.jar
Warning: The -i option is deprecated, and is planned for removal in a future JDK release


Which may be overridden by using `-XDsuppress-tool-removal-message`:


% build/macosx-x86_64-server-release/images/jdk/bin/jar --generate-index file.jar -XDsuppress-tool-removal-message



I'm not sure we are planning to remove it though, so perhaps the current message is somewhat misleading? On the other hand, this message will allow us to remove it in the future, which is perhaps good?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1490123577


From mullan at openjdk.org  Thu Mar 30 11:57:17 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 30 Mar 2023 11:57:17 GMT
Subject: RFR: JDK-8305211: Remove CA certificates that are expired
In-Reply-To: <TJuMM7NrPJW-WPQEB65f5VVxR6rRgZ0Yxx2RjUo5TYI=.fb972ccc-5156-48d7-821c-b546029f5c08@github.com>
References: <TJuMM7NrPJW-WPQEB65f5VVxR6rRgZ0Yxx2RjUo5TYI=.fb972ccc-5156-48d7-821c-b546029f5c08@github.com>
Message-ID: <qvTKDCyDhEpqo9Vah7fOogoPcSnUd1ZXqBWvkqm7-hY=.780cd155-5659-4989-ad4a-78138c56d3af@github.com>

On Thu, 30 Mar 2023 04:56:37 GMT, Victor Rudometov <vrudomet at openjdk.org> wrote:

> Removed 6 CA certificates that are expired, updated VerifyCACerts test
> 
> Build passed, jtreg test VerifyCACerts passed.

These root certificates should not be removed. These root CAs have issued code signing certificates, which may still be in use if they were previously used to sign and timestamp Java code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13237#issuecomment-1490173577


From alanb at openjdk.org  Thu Mar 30 13:43:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 13:43:29 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <Ncibs2_GcTTW7K_4iL28V_HNMl6ofDMibKU184wlIEU=.f048803a-c059-4717-aa43-48fbc7ddcb01@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KokXTJwqLA8w3ChsLXAdx2Gs6d1o5A-r31r20xLFH98=.90fc12fb-7ccf-4cde-bd50-4bdc0a52cb29@github.com>
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
 <Ncibs2_GcTTW7K_4iL28V_HNMl6ofDMibKU184wlIEU=.f048803a-c059-4717-aa43-48fbc7ddcb01@github.com>
Message-ID: <gEuOYfBS3Z5DmVSyBITZx1SgSRm1EtOWZjYqKdKwpSM=.f3584379-a821-4679-91da-6a636f2a6f06@github.com>

On Thu, 30 Mar 2023 11:16:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> We seem to have wiggled a bit on this issue, but I'm ok with including it.

I think we've converged on `jar -i` work as before but print a warning. For the purposes of the CSR and the release note then I think it would be better to have the complete story in one issue rather than some of the story in one issue the two issues needing to cross reference each other. So thanks for going with that.

> 
> I have implemented the -i warning using the existing warnings strings already in place in `jar`. This means the following warning will be output:
> 
> ```
> % build/macosx-x86_64-server-release/images/jdk/bin/jar --generate-index file.jar
> Warning: The -i option is deprecated, and is planned for removal in a future JDK release
> ```

I think the warning should also communicate that the JAR index is also ignored, maybe something like this:


The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18.
The --generate-index/-i option is deprecated - it may be ignored or removed in a future release.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1490325051


From duke at openjdk.org  Thu Mar 30 14:21:29 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 14:21:29 GMT
Subject: RFR: 8302819: Remove JAR Index [v5]
In-Reply-To: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
Message-ID: <2WlS9lx99k4xv1Mr4X-QFYzoiSWV2oMF6uk1pkuWjxs=.929d5c45-71b1-436b-ad52-e879afd12896@github.com>

> This PR removes the JAR index feature from the runtime:
> 
> - `URLClassPath` is  updated to remove the `enableJarIndex` system property and any code which would be called when this property was `true`
> - The `JarIndex` implementation class is moved into `jdk.jartool` module.
> - The `InvalidJarIndexError` exception class is removed because it falls out of use
> - The test `test/jdk/sun/misc/JarIndex/metaInfFileNames/Basic.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java` is removed because it depends on the JarIndex feature being present
> - The test `test/jdk/sun/misc/JarIndex/JarIndexMergeTest.java` is removed because it end up being the only caller of the  JarIndex.merge feature
> - All `JarIndex` methods/constructors which are not used by the `jar -i` implementation are removed. 
> - `JarIndex` is given package-private access.
> 
> Outstanding code work:
> 
> - Create tests for `JarFile` and `JarInputStream` accepting dusty INDEX jars.
> 
> Outstanding work:
> 
> - CSR for the removal
> - Release notes for the removal
> - Coordination of the update of the Jar File Specification

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Include a warning saying that 'The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13158/files
  - new: https://git.openjdk.org/jdk/pull/13158/files/26c47b01..79b19e94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13158&range=03-04

  Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13158/head:pull/13158

PR: https://git.openjdk.org/jdk/pull/13158


From duke at openjdk.org  Thu Mar 30 14:22:38 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 14:22:38 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <gEuOYfBS3Z5DmVSyBITZx1SgSRm1EtOWZjYqKdKwpSM=.f3584379-a821-4679-91da-6a636f2a6f06@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KokXTJwqLA8w3ChsLXAdx2Gs6d1o5A-r31r20xLFH98=.90fc12fb-7ccf-4cde-bd50-4bdc0a52cb29@github.com>
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
 <Ncibs2_GcTTW7K_4iL28V_HNMl6ofDMibKU184wlIEU=.f048803a-c059-4717-aa43-48fbc7ddcb01@github.com>
 <gEuOYfBS3Z5DmVSyBITZx1SgSRm1EtOWZjYqKdKwpSM=.f3584379-a821-4679-91da-6a636f2a6f06@github.com>
Message-ID: <CZQrcl0aqaKHRb726Ttbq3Io0IZJlj6NqBU3H5Mnm5s=.2709f914-0ccf-46e6-8f4f-440dc4ce3409@github.com>

On Thu, 30 Mar 2023 13:40:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think the warning should also communicate that the JAR index is also ignored, maybe something like this:

I added the following property to `jar.properties`:


warn.index.is.ignored=\
        The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18


Then I chose to update the existing property `warn.flag.is.deprecated` from the following:


warn.flag.is.deprecated=\
         Warning: The {0} option is deprecated, and is planned for removal in a future JDK release\n


to the following:


warn.flag.is.deprecated=\
        Warning: The {0} option is deprecated, and may be ignored or removed in a future release\n


This gives the following warning on use:


% build/macosx-x86_64-server-release/images/jdk/bin/jar -i hello.zip
The JAR index (META-INF/INDEX.LIST) is ignored at run-time since JDK 18
Warning: The --generate-index/-i option is deprecated, and may be ignored or removed in a future release

Is this repurposing of `warn.flag.is.deprecated` considered ok?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1490393173


From mchung at openjdk.org  Thu Mar 30 17:13:19 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 30 Mar 2023 17:13:19 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <CZQrcl0aqaKHRb726Ttbq3Io0IZJlj6NqBU3H5Mnm5s=.2709f914-0ccf-46e6-8f4f-440dc4ce3409@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KokXTJwqLA8w3ChsLXAdx2Gs6d1o5A-r31r20xLFH98=.90fc12fb-7ccf-4cde-bd50-4bdc0a52cb29@github.com>
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
 <Ncibs2_GcTTW7K_4iL28V_HNMl6ofDMibKU184wlIEU=.f048803a-c059-4717-aa43-48fbc7ddcb01@github.com>
 <gEuOYfBS3Z5DmVSyBITZx1SgSRm1EtOWZjYqKdKwpSM=.f3584379-a821-4679-91da-6a636f2a6f06@github.com>
 <CZQrcl0aqaKHRb726Ttbq3Io0IZJlj6NqBU3H5Mnm5s=.2709f914-0ccf-46e6-8f4f-440dc4ce3409@github.com>
Message-ID: <X-Vm0bWNMaisbgEEIbuRDGRai8iF6VAo3YOfmyG4EgI=.d93242a9-6a56-4032-939d-4e44ce486f4b@github.com>

On Thu, 30 Mar 2023 14:19:55 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Is this repurposing of warn.flag.is.deprecated considered ok?

yes, that's not used.   It was a leftover from JDK-8204981 & JDK-8234596.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1490647633


From jjg at openjdk.org  Thu Mar 30 17:31:12 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 17:31:12 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
Message-ID: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>

Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.

This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.

While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.

It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]

[here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
[disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

-------------

Commit messages:
 - JDK-8305206: Add @spec tags in java.base/java.* (part 1)

Changes: https://git.openjdk.org/jdk/pull/13248/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305206
  Stats: 281 lines in 60 files changed: 267 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13248/head:pull/13248

PR: https://git.openjdk.org/jdk/pull/13248


From duke at openjdk.org  Thu Mar 30 17:39:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 30 Mar 2023 17:39:18 GMT
Subject: RFR: 8302819: Remove JAR Index [v2]
In-Reply-To: <X-Vm0bWNMaisbgEEIbuRDGRai8iF6VAo3YOfmyG4EgI=.d93242a9-6a56-4032-939d-4e44ce486f4b@github.com>
References: <2AyfyxXxKsgOftFF-2BJFZZ7JpSX6VfsjQ5C_9-_XIo=.7fee86be-caaf-4353-8d31-f368427ffa58@github.com>
 <KokXTJwqLA8w3ChsLXAdx2Gs6d1o5A-r31r20xLFH98=.90fc12fb-7ccf-4cde-bd50-4bdc0a52cb29@github.com>
 <83FoBH92lGs58VfmVV9QnYzKM0Qbiz75CgpVbR6TSTE=.d8d275fe-afba-41c3-b6e3-c89fa87d3ba8@github.com>
 <Ncibs2_GcTTW7K_4iL28V_HNMl6ofDMibKU184wlIEU=.f048803a-c059-4717-aa43-48fbc7ddcb01@github.com>
 <gEuOYfBS3Z5DmVSyBITZx1SgSRm1EtOWZjYqKdKwpSM=.f3584379-a821-4679-91da-6a636f2a6f06@github.com>
 <CZQrcl0aqaKHRb726Ttbq3Io0IZJlj6NqBU3H5Mnm5s=.2709f914-0ccf-46e6-8f4f-440dc4ce3409@github.com>
 <X-Vm0bWNMaisbgEEIbuRDGRai8iF6VAo3YOfmyG4EgI=.d93242a9-6a56-4032-939d-4e44ce486f4b@github.com>
Message-ID: <VLVVa8QqiDcP7cGBlkaZwA9cXI_EmTDwtTw3zWq7N0k=.634ef398-90a7-425c-8097-47ece2b65a26@github.com>

On Thu, 30 Mar 2023 17:10:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> yes, that's not used. It was a leftover from JDK-8204981 & JDK-8234596.

Thanks a lot for this clarificaton, Mandy.

https://bugs.openjdk.org/browse/JDK-8204981
https://bugs.openjdk.org/browse/JDK-8234596

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13158#issuecomment-1490678668


From vrudomet at openjdk.org  Thu Mar 30 18:45:15 2023
From: vrudomet at openjdk.org (Victor Rudometov)
Date: Thu, 30 Mar 2023 18:45:15 GMT
Subject: RFR: JDK-8305211: Remove CA certificates that are expired
In-Reply-To: <TJuMM7NrPJW-WPQEB65f5VVxR6rRgZ0Yxx2RjUo5TYI=.fb972ccc-5156-48d7-821c-b546029f5c08@github.com>
References: <TJuMM7NrPJW-WPQEB65f5VVxR6rRgZ0Yxx2RjUo5TYI=.fb972ccc-5156-48d7-821c-b546029f5c08@github.com>
Message-ID: <MSZ7vjAib7Y1qI6_CD7N0O-AXiA4oyYck8E0WvRtShM=.db130bf5-114b-45ae-9598-aa2f059bd565@github.com>

On Thu, 30 Mar 2023 04:56:37 GMT, Victor Rudometov <vrudomet at openjdk.org> wrote:

> Removed 6 CA certificates that are expired, updated VerifyCACerts test
> 
> Build passed, jtreg test VerifyCACerts passed.

Isn't it required for all certificates in the chain to be valid at the current date/time?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13237#issuecomment-1490758124


From mullan at openjdk.org  Thu Mar 30 19:03:16 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 30 Mar 2023 19:03:16 GMT
Subject: RFR: JDK-8305211: Remove CA certificates that are expired
In-Reply-To: <MSZ7vjAib7Y1qI6_CD7N0O-AXiA4oyYck8E0WvRtShM=.db130bf5-114b-45ae-9598-aa2f059bd565@github.com>
References: <TJuMM7NrPJW-WPQEB65f5VVxR6rRgZ0Yxx2RjUo5TYI=.fb972ccc-5156-48d7-821c-b546029f5c08@github.com>
 <MSZ7vjAib7Y1qI6_CD7N0O-AXiA4oyYck8E0WvRtShM=.db130bf5-114b-45ae-9598-aa2f059bd565@github.com>
Message-ID: <84PqQydQkE9V8sMOZ7YYNs7diZP8BlfetThg7_512OI=.06e2a1f2-3b54-481f-a238-a643f8776d57@github.com>

On Thu, 30 Mar 2023 18:42:21 GMT, Victor Rudometov <vrudomet at openjdk.org> wrote:

> Isn't it required for all certificates in the chain to be valid at the current date/time?

For TLS, yes. For signed code, no as long as the code was previously timestamped and that timestamp was within the validity period of all of the certificates in the chain.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13237#issuecomment-1490784302


From vrudomet at openjdk.org  Thu Mar 30 19:14:28 2023
From: vrudomet at openjdk.org (Victor Rudometov)
Date: Thu, 30 Mar 2023 19:14:28 GMT
Subject: Withdrawn: JDK-8305211: Remove CA certificates that are expired
In-Reply-To: <TJuMM7NrPJW-WPQEB65f5VVxR6rRgZ0Yxx2RjUo5TYI=.fb972ccc-5156-48d7-821c-b546029f5c08@github.com>
References: <TJuMM7NrPJW-WPQEB65f5VVxR6rRgZ0Yxx2RjUo5TYI=.fb972ccc-5156-48d7-821c-b546029f5c08@github.com>
Message-ID: <UzHhIrfs8SR7inF-AJDVylG1w8RfcXgbC-sSf2zwFzs=.281a394b-3a8b-46d9-960d-9207b8d5d14f@github.com>

On Thu, 30 Mar 2023 04:56:37 GMT, Victor Rudometov <vrudomet at openjdk.org> wrote:

> Removed 6 CA certificates that are expired, updated VerifyCACerts test
> 
> Build passed, jtreg test VerifyCACerts passed.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13237


From vrudomet at openjdk.org  Thu Mar 30 19:14:27 2023
From: vrudomet at openjdk.org (Victor Rudometov)
Date: Thu, 30 Mar 2023 19:14:27 GMT
Subject: RFR: JDK-8305211: Remove CA certificates that are expired
In-Reply-To: <TJuMM7NrPJW-WPQEB65f5VVxR6rRgZ0Yxx2RjUo5TYI=.fb972ccc-5156-48d7-821c-b546029f5c08@github.com>
References: <TJuMM7NrPJW-WPQEB65f5VVxR6rRgZ0Yxx2RjUo5TYI=.fb972ccc-5156-48d7-821c-b546029f5c08@github.com>
Message-ID: <1nlgcjvhYTdDxH0WsQioKsFYIBFDkvF2DI_KsfBKNjc=.5810eda8-fdd6-4560-8eb9-7853f1a44a87@github.com>

On Thu, 30 Mar 2023 04:56:37 GMT, Victor Rudometov <vrudomet at openjdk.org> wrote:

> Removed 6 CA certificates that are expired, updated VerifyCACerts test
> 
> Build passed, jtreg test VerifyCACerts passed.

Oh, I see, thank you for the explanation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13237#issuecomment-1490798860


From alanb at openjdk.org  Thu Mar 30 19:51:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 19:51:22 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

I skimmed through the changes and it looks quite good, much more workable than PR 11073.

Do you have a proposed ordering with other tags? I expected it would go with @see but I see several where @spec is before @author, and @see after @author. I know it doesn't really matter.

src/java.base/share/classes/java/lang/Thread.java line 1960:

> 1958:      *             thread.
> 1959:      *
> 1960:      * @spec jni/index.html Java Native Interface Specification

The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.

src/java.base/share/classes/java/nio/file/Files.java line 1724:

> 1722:      *
> 1723:      * @spec https://www.rfc-editor.org/info/rfc2045
> 1724:      *      RFC 2045: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies

Maybe this one can be put on two lines to avoid the wrapping when looking at is side-by-side.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1365814487
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153715180
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153716361


From weijun at openjdk.org  Thu Mar 30 19:57:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 30 Mar 2023 19:57:38 GMT
Subject: RFR: 8305310: Calculate PublicKey from PrivateKey
Message-ID: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>

This code change is for DHKEM, which requires the function

pk(skX): The KEM public key corresponding to the KEM private key skX.

-------------

Commit messages:
 - add a test
 - the fix

Changes: https://git.openjdk.org/jdk/pull/13250/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13250&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305310
  Stats: 184 lines in 7 files changed: 145 ins; 20 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13250.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13250/head:pull/13250

PR: https://git.openjdk.org/jdk/pull/13250


From jjg at openjdk.org  Thu Mar 30 20:33:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:33:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>
Message-ID: <ZXpGUrrQbi53QnGyYTMxbbQfepA4H-RzMTRDkmBAYAg=.41881291-c325-4291-808b-1369730c9869@github.com>

On Thu, 30 Mar 2023 19:42:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> src/java.base/share/classes/java/lang/Thread.java line 1960:
> 
>> 1958:      *             thread.
>> 1959:      *
>> 1960:      * @spec jni/index.html Java Native Interface Specification
> 
> The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.

Right now, the tag is added for any declaration whose comment contains a reference to an external spec (i.e. with `<a href-....>`. 

When we enable the "External Specifications" page, it will contain a link back to this page as part of the cross-reference info, which seems useful. That being said, if you feel strongly the tag should not be added here, I can remove it.

> src/java.base/share/classes/java/nio/file/Files.java line 1724:
> 
>> 1722:      *
>> 1723:      * @spec https://www.rfc-editor.org/info/rfc2045
>> 1724:      *      RFC 2045: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
> 
> Maybe this one can be put on two lines to avoid the wrapping when looking at is side-by-side.

Fixed. There was also a stutter-bug with a double "RFC 2045: RFC 2045:" which I have also fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153755656
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153756945


From jjg at openjdk.org  Thu Mar 30 20:45:08 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:45:08 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13248/files
  - new: https://git.openjdk.org/jdk/pull/13248/files/3e1102a9..096a4188

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13248/head:pull/13248

PR: https://git.openjdk.org/jdk/pull/13248


From jjg at openjdk.org  Thu Mar 30 20:45:10 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:45:10 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <AFuAduz4qqk1zQOOajsUEmtpy1XZ18P_95Av_6ZkKgs=.69b361cb-f738-4e62-a764-a21bec7df0f2@github.com>

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

> I skimmed through the changes and it looks quite good, much more workable than PR 11073.
> 
> Do you have a proposed ordering with other tags? I expected it would go with @see but I see several where @SPEC is before @author, and @see after @author. I know it doesn't really matter.

The initial assumption was "after the @param/@return/@throws group". Overall, as I said in the description for this PR, the block tags are not very consistent about ordering. I was thinking we might want to recommend an overall ordering, but I'm worried it would be too intrusive a change to apply generally.  In the description, I suggested an ordering based on the
order in `Docs.gmk` which defines the order in which tags appear in the generated output.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1490920050


From naoto at openjdk.org  Thu Mar 30 22:44:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Mar 2023 22:44:16 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <6a2ZYG8twjvIWSMNXjFdLra2lXGXoC3R9wyVFL8BAiY=.11396706-6da0-44fb-8e68-3965fd418edd@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Changes in i18n-related classes look good to me.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366032864


From cslucas at openjdk.org  Thu Mar 30 23:36:20 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 30 Mar 2023 23:36:20 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>

> Can I please get reviews for this PR? 
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
> 
> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
> 
> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/a158ae66..5ef86371

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=03-04

  Stats: 552 lines in 18 files changed: 181 ins; 169 del; 202 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897


From weijun at openjdk.org  Fri Mar 31 02:32:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 31 Mar 2023 02:32:21 GMT
Subject: RFR: 8297878: Implementing Key Encapsulation Mechanism API
Message-ID: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>

The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

-------------

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/13256/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297878
  Stats: 2222 lines in 9 files changed: 2214 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256

PR: https://git.openjdk.org/jdk/pull/13256


From darcy at openjdk.org  Fri Mar 31 04:35:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 Mar 2023 04:35:15 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <KrmUUZooBBZCX4WnmF1L1WpbI_lU2eXFldn_EMhoqYk=.717ec9fb-f542-48d5-b296-bab253be56bc@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Good to see these changes.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366237224


From alanb at openjdk.org  Fri Mar 31 10:26:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:26:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <nJ6I7j1VirPsWWSI1WgCK6FOVYxFpT163gKO8xzfbHE=.aa845440-9715-45ce-8587-e0112ae249ff@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366677936


From alanb at openjdk.org  Fri Mar 31 10:26:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:26:19 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <ZXpGUrrQbi53QnGyYTMxbbQfepA4H-RzMTRDkmBAYAg=.41881291-c325-4291-808b-1369730c9869@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>
 <ZXpGUrrQbi53QnGyYTMxbbQfepA4H-RzMTRDkmBAYAg=.41881291-c325-4291-808b-1369730c9869@github.com>
Message-ID: <EWW2GBqSWEKK01g2OWHM3TllOeAbIzNKQbQ_hdTWm0Q=.038c5f4a-b8ca-473d-8f31-3c4c67158432@github.com>

On Thu, 30 Mar 2023 20:28:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 1960:
>> 
>>> 1958:      *             thread.
>>> 1959:      *
>>> 1960:      * @spec jni/index.html Java Native Interface Specification
>> 
>> The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.
>
> Right now, the tag is added for any declaration whose comment contains a reference to an external spec (i.e. with `<a href-....>`. 
> 
> When we enable the "External Specifications" page, it will contain a link back to this page as part of the cross-reference info, which seems useful. That being said, if you feel strongly the tag should not be added here, I can remove it.

Leave it in for now and we can look at it again when the external spec page is in place. My comment is mostly that it will look a bit strange to link to this method because it's text in an implNote rather than spec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154302925


From alanb at openjdk.org  Fri Mar 31 10:29:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:29:18 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <AFuAduz4qqk1zQOOajsUEmtpy1XZ18P_95Av_6ZkKgs=.69b361cb-f738-4e62-a764-a21bec7df0f2@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <AFuAduz4qqk1zQOOajsUEmtpy1XZ18P_95Av_6ZkKgs=.69b361cb-f738-4e62-a764-a21bec7df0f2@github.com>
Message-ID: <ZGHuaYhpb5JLEXLMFrqw2WDNMATOUxwIjrpsurPb23Y=.d06e5ede-f7d4-4565-9e46-4ba049d79db2@github.com>

On Thu, 30 Mar 2023 20:38:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The initial assumption was "after the @param/@return/@throws group". Overall, as I said in the description for this PR, the block tags are not very consistent about ordering. I was thinking we might want to recommend an overall ordering, but I'm worried it would be too intrusive a change to apply generally. In the description, I suggested an ordering based on the order in `Docs.gmk` which defines the order in which tags appear in the generated output.

Okay, I think it's just a few of the usages that I sampled had author tags left over from early JDK releases and they end up between the spec and see tags. We can fix these things up at another time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1491696054


From lancea at openjdk.org  Fri Mar 31 10:36:17 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 Mar 2023 10:36:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Hi Jon,

This looks fine.  I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366691673


From dfuchs at openjdk.org  Fri Mar 31 10:44:17 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 31 Mar 2023 10:44:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <xhqVzVaj-GfS0YTdnG0h8FxEyfTmgaC045v38qGZc0o=.cf6e00c7-fb70-468e-a094-7a0cda52aaab@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

I had a look at the java.net part and it looks reasonable.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366700592


From lancea at openjdk.org  Fri Mar 31 10:48:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 Mar 2023 10:48:13 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>
Message-ID: <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>

On Fri, 31 Mar 2023 10:33:50 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi Jon,
> 
> This looks fine. I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?

Well, I must need coffee this morning as obviously JDBC is in the java.sql module, not java.base.... So scratch that comment ;-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1491723581


From duke at openjdk.org  Fri Mar 31 11:18:16 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 31 Mar 2023 11:18:16 GMT
Subject: RFR: 8305310: Calculate PublicKey from PrivateKey
In-Reply-To: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>
References: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>
Message-ID: <NWOsnKwE74yZQtQlB_Lv2NleiJUVD28k9lCePIbd52w=.cc691e6f-2cbd-4828-8fda-2b9e0f8f8516@github.com>

On Thu, 30 Mar 2023 19:31:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change is for DHKEM, which requires the function
> 
> pk(skX): The KEM public key corresponding to the KEM private key skX.
> 
> Only implemented for EC and XDH. Might add PKCS #11 support later.

src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 217:

> 215:             return new ECPublicKeyImpl(w, ecParams);
> 216:         } catch (InvalidKeyException e) {
> 217:             throw new ProviderException("Should not happen", e);

On the remote chance that this exception is thrown, the message doesn't help the user.  A better message might be "Unexpected error creating public key" or even just not having a message and using the `ProviderException(Throwable)`constructor. 

This message is also used in XDHPrivateKeyimpl.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13250#discussion_r1154349583


From duke at openjdk.org  Fri Mar 31 11:50:18 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 31 Mar 2023 11:50:18 GMT
Subject: RFR: 8305310: Calculate PublicKey from PrivateKey
In-Reply-To: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>
References: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>
Message-ID: <KT2AQLf_t2aCacmQ2OYmN35eD264RR5Z9W-Qjb_jJFs=.b65f9280-bddd-4560-b125-3f08821606e1@github.com>

On Thu, 30 Mar 2023 19:31:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change is for DHKEM, which requires the function
> 
> pk(skX): The KEM public key corresponding to the KEM private key skX.
> 
> Only implemented for EC and XDH. Might add PKCS #11 support later.

test/jdk/sun/security/util/InteralPrivateKey/Correctness.java line 39:

> 37:  * @modules java.base/sun.security.util
> 38:  */
> 39: public class Correctness {

There's a misspelling in the directory name for this class: InteralPrivateKey vs. InternalPrivateKey

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13250#discussion_r1154377942


From weijun at openjdk.org  Fri Mar 31 12:41:16 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 31 Mar 2023 12:41:16 GMT
Subject: RFR: 8305310: Calculate PublicKey from PrivateKey
In-Reply-To: <NWOsnKwE74yZQtQlB_Lv2NleiJUVD28k9lCePIbd52w=.cc691e6f-2cbd-4828-8fda-2b9e0f8f8516@github.com>
References: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>
 <NWOsnKwE74yZQtQlB_Lv2NleiJUVD28k9lCePIbd52w=.cc691e6f-2cbd-4828-8fda-2b9e0f8f8516@github.com>
Message-ID: <r1aQ1QnB2pQo0qDZs_rLGaGFqfbzN5tVH6n3xt4pz6A=.932ae9a5-0977-4a66-8c49-61c8cad3a114@github.com>

On Fri, 31 Mar 2023 11:15:19 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> This code change is for DHKEM, which requires the function
>> 
>> pk(skX): The KEM public key corresponding to the KEM private key skX.
>> 
>> Only implemented for EC and XDH. Might add PKCS #11 support later.
>
> src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 217:
> 
>> 215:             return new ECPublicKeyImpl(w, ecParams);
>> 216:         } catch (InvalidKeyException e) {
>> 217:             throw new ProviderException("Should not happen", e);
> 
> On the remote chance that this exception is thrown, the message doesn't help the user.  A better message might be "Unexpected error creating public key" or even just not having a message and using the `ProviderException(Throwable)`constructor. 
> 
> This message is also used in XDHPrivateKeyimpl.

Good suggestion.

> test/jdk/sun/security/util/InteralPrivateKey/Correctness.java line 39:
> 
>> 37:  * @modules java.base/sun.security.util
>> 38:  */
>> 39: public class Correctness {
> 
> There's a misspelling in the directory name for this class: InteralPrivateKey vs. InternalPrivateKey

Sharp eye!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13250#discussion_r1154425496
PR Review Comment: https://git.openjdk.org/jdk/pull/13250#discussion_r1154425633


From weijun at openjdk.org  Fri Mar 31 12:48:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 31 Mar 2023 12:48:21 GMT
Subject: RFR: 8305310: Calculate PublicKey from PrivateKey [v2]
In-Reply-To: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>
References: <7wQWfZVN4wUDa-ovuBrF_6bkg0t1BFti3BX0G9J-b40=.5643a455-edf7-4ab5-9cad-599f6e4c84d3@github.com>
Message-ID: <Eb3EX3nkXnXMFPhW1DrL7kZr4tZA83TWV4mpnxQQtP0=.89e18e24-1ad1-4494-964d-2e98218c7b14@github.com>

> This code change is for DHKEM, which requires the function
> 
> pk(skX): The KEM public key corresponding to the KEM private key skX.
> 
> Only implemented for EC and XDH. Might add PKCS #11 support later.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  exception message, directory name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13250/files
  - new: https://git.openjdk.org/jdk/pull/13250/files/48ecd5a0..afdd5a3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13250&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13250&range=00-01

  Stats: 4 lines in 3 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13250.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13250/head:pull/13250

PR: https://git.openjdk.org/jdk/pull/13250


From mullan at openjdk.org  Fri Mar 31 16:31:20 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 31 Mar 2023 16:31:20 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <xr0fgOmpPj6uUCvuSIiov-DKPYhTxPUEoFRwg-WSd7w=.1dd94a44-30f0-471d-a52a-7b16a431f882@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

I didn't see any changes to security APIs - are they coming in a follow-on issue?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492236091


From iris at openjdk.org  Fri Mar 31 17:22:18 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 31 Mar 2023 17:22:18 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <MsIJ9F_LHrratAyjmUoPw1pEkxGYRo4L-tAmdkyWt8A=.8cb545c4-1daf-43c7-a4ef-5bc2feaf879d@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by iris (Reviewer).

src/java.base/share/classes/java/io/ObjectOutputStream.java line 165:

> 163:  * @see java.io.Serializable
> 164:  * @see java.io.Externalizable
> 165:  * @since       1.1

Just confirming... The changes to the java.io classes for the Serialization Spec now all point to the index rather than particular chapters/sections. I'm assuming that's intentional so that when the top-level Spec page appears, there is a single entry for that specification.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367309978
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154716150


From mchung at openjdk.org  Fri Mar 31 17:25:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 31 Mar 2023 17:25:16 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <jmr06nDi3ImVdDXkR2CdZ2RiRqn0Nfk7lDiwR4VNXao=.87f529ea-5d89-4178-916b-f7d9e4bfa445@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

LGTM

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367320601


From xliu at openjdk.org  Fri Mar 31 17:53:20 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 31 Mar 2023 17:53:20 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
Message-ID: <jHg4FYCdKnJq9wOPuKKXCl6_yEBw-OvHtEN-Pk0UxxM=.1d019bbe-581a-4f0e-b627-7b011e5809f2@github.com>

On Thu, 30 Mar 2023 23:36:20 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.

src/hotspot/share/opto/escape.cpp line 588:

> 586: }
> 587: 
> 588: // This method will create a SafePointScalarObjectNode for each combination of

you have changed to SafePointScalarMergeNode in code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154745690


From xliu at openjdk.org  Fri Mar 31 18:24:18 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 31 Mar 2023 18:24:18 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
Message-ID: <tWki9FSa5shsXyCMcUVJL5oPuM5lxjN_gMWDVkYvst4=.a1101c45-1b1a-425e-83b5-856d6fddaacc@github.com>

On Thu, 30 Mar 2023 23:36:20 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.

src/hotspot/share/opto/macro.cpp line 632:

> 630:           safepoints->append_if_missing(sfpt);
> 631:         }
> 632:       } else if (ignore_merges && (use->is_Phi() || use->is_EncodeP() || use->Opcode() == Op_MemBarRelease)) {

I try to understand this part. now `can_eliminate_allocation` can pre-test whether SR can eliminate the alloc.  I see that you use it in EA. 

With ignore_merges, why we also skip EncodeP or MemBarRelease here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154771471


From xliu at openjdk.org  Fri Mar 31 18:27:21 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 31 Mar 2023 18:27:21 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <tWki9FSa5shsXyCMcUVJL5oPuM5lxjN_gMWDVkYvst4=.a1101c45-1b1a-425e-83b5-856d6fddaacc@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
 <tWki9FSa5shsXyCMcUVJL5oPuM5lxjN_gMWDVkYvst4=.a1101c45-1b1a-425e-83b5-856d6fddaacc@github.com>
Message-ID: <mxsldgW-AtEV3etyH7yZ2jx5MXXSyQFiKqzalVYPaYg=.fae3b88a-1f76-4b60-8644-6413a7d8accb@github.com>

On Fri, 31 Mar 2023 18:21:40 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
>
> src/hotspot/share/opto/macro.cpp line 632:
> 
>> 630:           safepoints->append_if_missing(sfpt);
>> 631:         }
>> 632:       } else if (ignore_merges && (use->is_Phi() || use->is_EncodeP() || use->Opcode() == Op_MemBarRelease)) {
> 
> I try to understand this part. now `can_eliminate_allocation` can pre-test whether SR can eliminate the alloc.  I see that you use it in EA. 
> 
> With ignore_merges, why we also skip EncodeP or MemBarRelease here?

Do you really need the boolean parameter ignore_merges here? 
It looks like we can use (safepoints == nullptr) instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154773826


From jjg at openjdk.org  Fri Mar 31 18:29:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 18:29:17 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>
 <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>
Message-ID: <E6VI-_KYfAb3rvONO2NokBVCgNRU9Nkb5MRRpBiSXTI=.6228fc9b-37e5-495b-9971-adaacb8a502a@github.com>

On Fri, 31 Mar 2023 10:45:39 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > Hi Jon,
> > This looks fine. I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?
> 
> Well, I must need coffee this morning as obviously JDBC is in the java.sql module, not java.base.... So scratch that comment ;-)

The other modules will be done in due course.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492417414


From jjg at openjdk.org  Fri Mar 31 18:29:20 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 18:29:20 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <MsIJ9F_LHrratAyjmUoPw1pEkxGYRo4L-tAmdkyWt8A=.8cb545c4-1daf-43c7-a4ef-5bc2feaf879d@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <MsIJ9F_LHrratAyjmUoPw1pEkxGYRo4L-tAmdkyWt8A=.8cb545c4-1daf-43c7-a4ef-5bc2feaf879d@github.com>
Message-ID: <8CaBH8YGWfkV6NnZtXfTyDI90ZwzCWFF631EnE6sU0A=.7a4acefb-6b85-4f41-a642-e266ab24363f@github.com>

On Fri, 31 Mar 2023 17:14:01 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/java.base/share/classes/java/io/ObjectOutputStream.java line 165:
> 
>> 163:  * @see java.io.Serializable
>> 164:  * @see java.io.Externalizable
>> 165:  * @since       1.1
> 
> Just confirming... The changes to the java.io classes for the Serialization Spec now all point to the index rather than particular chapters/sections. I'm assuming that's intentional so that when the top-level Spec page appears, there is a single entry for that specification.

The `@spec` tag should point to the root, but we should not remove more specific references to within the spec. I will review places where `@see` has been removed/replaced.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154774688


From xliu at openjdk.org  Fri Mar 31 18:33:19 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 31 Mar 2023 18:33:19 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
Message-ID: <Fco8XVAwjuZJoOaK-fb7UzAu3y9utPQk17D6ncUAH6E=.f097a54d-8883-42f7-b81a-2a7b423511d5@github.com>

On Thu, 30 Mar 2023 23:36:20 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.

src/hotspot/share/opto/escape.cpp line 457:

> 455:         found_sr_allocate = true;
> 456:       } else {
> 457:         ptn->set_scalar_replaceable(false);

This member function is const. Do we really need to change ptn's property here? 

My reading is ophi is profitable as long as we spot any input object which can be eliminated.  how about you just return at line 455?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154778280


From xliu at openjdk.org  Fri Mar 31 18:41:23 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 31 Mar 2023 18:41:23 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <o6msC4bnqaYIl0YQPjv-IPXsHRUbtleyEvcirt5dyog=.56d57ae0-f3bc-4942-942e-066e8fd95856@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
 <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com>
 <o6msC4bnqaYIl0YQPjv-IPXsHRUbtleyEvcirt5dyog=.56d57ae0-f3bc-4942-942e-066e8fd95856@github.com>
Message-ID: <FOUeJrVL0xYrKw3FzYZc8HCSocQ82_Iizd_HthI-W_8=.06b6b235-1412-4e5c-82ee-51893239c2f1@github.com>

On Fri, 24 Mar 2023 23:37:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I had to make this method static because it uses `value_from_mem` - which I also made static. I had to make `value_from_mem` static so that I can use it outside PhaseMacroExpand.
>
> I see, you use it in escape.cpp. Okay. I need to review changes there too.

or you could construct a temporary PhaseMacroExpand object in EA. 

I see that you convert many member function to static so you can query in EA. the only blocker is _igvn.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154785040


From jlu at openjdk.org  Fri Mar 31 21:41:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 21:41:17 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
Message-ID: <UC_eXLH1ZYj0NDyQ-MSY5oRvejr6HAHIznL3Lh7rwOY=.4cb34fe7-3979-454d-8d49-b07b248a5cf7@github.com>

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Something thing to consider is that Intellj defaults .properties files to ISO 8859-1. 

https://www.jetbrains.com/help/idea/properties-files.html#encoding

So users of Intellj / (other IDEs that default to ISO 8859-1 for .properties files) will need to change the default encoding to utf-8 for such files. Or ideally, the respective IDEs can change their default encoding for .properties files if this change is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492640306


From jjg at openjdk.org  Fri Mar 31 22:07:26 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 22:07:26 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v3]
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  revert removing @see tags where the URL was not the same as the @spec URL

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13248/files
  - new: https://git.openjdk.org/jdk/pull/13248/files/096a4188..7f64cc32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=01-02

  Stats: 12 lines in 4 files changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13248/head:pull/13248

PR: https://git.openjdk.org/jdk/pull/13248


From jjg at openjdk.org  Fri Mar 31 22:18:15 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 22:18:15 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]
In-Reply-To: <xr0fgOmpPj6uUCvuSIiov-DKPYhTxPUEoFRwg-WSd7w=.1dd94a44-30f0-471d-a52a-7b16a431f882@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <xr0fgOmpPj6uUCvuSIiov-DKPYhTxPUEoFRwg-WSd7w=.1dd94a44-30f0-471d-a52a-7b16a431f882@github.com>
Message-ID: <is-v-fguWbSiEU4xVmQNC5S8HrjugCcUZ-LCgO9baSk=.89991275-b806-48d1-8920-08afabb59cab@github.com>

On Fri, 31 Mar 2023 16:28:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I didn't see any changes to security APIs - are they coming in a follow-on issue?

Yes, this is _Add `@spec` tags in java.base/java.* (part 1)_
The rest of `java.base` will be in part 2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492670942


From naoto at openjdk.org  Fri Mar 31 22:48:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 22:48:29 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
Message-ID: <G-JuA4B7q1ygFjywx4FOwGfJX2Ud-Jf4BwgrzPykvXg=.61ddf6ba-5a7d-45a2-87aa-4613ec3dfb3b@github.com>

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Hmm, I just wonder why they are sticking to ISO-8859-1 as the default. I know j.u.Properties defaults to 8859-1, but PropertyResourceBundle, which is their primary use defaults to UTF-8 since JDK9 (https://openjdk.org/jeps/226)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492682703