On Fri, 15 May 2026 22:31:27 GMT, Anthony Scarpino <[email protected]> 
wrote:

>> Please review the finalized PEM API at https://openjdk.org/jeps/8376991. The 
>> most significant changes from the second preview, JEP 524 
>> (https://openjdk.org/jeps/524), include:
>> 
>> - The `PEM` class is now an ordinary class rather than a record. It adds 
>> Binary-encoded content constructors and data is defensively copied.
>> - The `DEREncodable` interface is renamed to `BinaryEncodable` to more 
>> accurately reflect the binary data stored in PEM text.
>> - In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept 
>> `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer 
>> include a `Provider` parameter.
>> - A new `CryptoException` class indicates failures in cryptographic 
>> processing at runtime.
>> 
>> thanks
>> 
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the 
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Anthony Scarpino has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   comments

src/java.base/share/classes/java/security/PEM.java line 92:

> 90:      *        This array is defensively copied.
> 91:      *
> 92:      * @throws IllegalArgumentException if {@code type} contains PEM

Constructors currently say “type … must not contain PEM encapsulation syntax” 
and “Throws IllegalArgumentException if type contains PEM encapsulation syntax.”
However, the implementation only rejects types that start with "-", "BEGIN " or 
"END ".
Could you please clarify what the intended contract is?
Should a type be rejected only if it starts with these prefixes, or
Should it be rejected if it contains PEM encapsulation syntax anywhere in the 
string (e.g., "FOO -----BEGIN PUBLIC KEY----- BAR")?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r3285575640

Reply via email to