RFR: 8377506: Implementation of PEM Encodings of Cryptographic Objects (Final)
Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include: - `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied. - `DEREncodable` 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` indicates failures during cryptographic processing at runtime. thanks ------------- Commit messages: - Merge branch 'master' into pem27 - doc and test updates - Initial Changes: https://git.openjdk.org/jdk/pull/29640/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29640&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377506 Stats: 752 lines in 33 files changed: 272 ins; 182 del; 298 mod Patch: https://git.openjdk.org/jdk/pull/29640.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29640/head:pull/29640 PR: https://git.openjdk.org/jdk/pull/29640
On Mon, 9 Feb 2026 21:04:34 GMT, Anthony Scarpino <ascarpino@openjdk.org> wrote:
Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
- `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied. - `DEREncodable` 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` indicates failures during cryptographic processing at runtime.
thanks
src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 92:
90: @JEP(number=524, title="PEM Encodings of Cryptographic Objects", 91: status="Second Preview") 92: PEM_API,
@lahodaj This comes up each time that a feature proposes to become permanent after being in preview. Do we still leave the value in place for one release and then cleanup in release N+1 ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2820737035
On Wed, 18 Feb 2026 07:17:51 GMT, Alan Bateman <alanb@openjdk.org> wrote:
Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
- `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied. - `DEREncodable` 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` indicates failures during cryptographic processing at runtime.
thanks
src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 92:
90: @JEP(number=524, title="PEM Encodings of Cryptographic Objects", 91: status="Second Preview") 92: PEM_API,
@lahodaj This comes up each time that a feature proposes to become permanent after being in preview. Do we still leave the value in place for one release and then cleanup in release N+1 ?
This came up the last time too and Jan explained how to deal with the removal of these constants. I've now added a comment and pinned it to that previous JBS issue at https://bugs.openjdk.org/browse/JDK-8365699?focusedId=14856891&page=com.atla... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2820795515
On Wed, 18 Feb 2026 07:37:13 GMT, Jaikiran Pai <jpai@openjdk.org> wrote:
src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 92:
90: @JEP(number=524, title="PEM Encodings of Cryptographic Objects", 91: status="Second Preview") 92: PEM_API,
@lahodaj This comes up each time that a feature proposes to become permanent after being in preview. Do we still leave the value in place for one release and then cleanup in release N+1 ?
This came up the last time too and Jan explained how to deal with the removal of these constants. I've now added a comment and pinned it to that previous JBS issue at https://bugs.openjdk.org/browse/JDK-8365699?focusedId=14856891&page=com.atla...
In fact, I just realized that the same detail is available in the source code as comment a few lines above https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/i... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2820812830
On Wed, 18 Feb 2026 07:42:18 GMT, Jaikiran Pai <jpai@openjdk.org> wrote:
This came up the last time too and Jan explained how to deal with the removal of these constants. I've now added a comment and pinned it to that previous JBS issue at https://bugs.openjdk.org/browse/JDK-8365699?focusedId=14856891&page=com.atla...
In fact, I just realized that the same detail is available in the source code as comment a few lines above https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/i...
Thanks. I would be very surprised if interim javac would pull in PEM but as it's not always easy to determine this so best to leave until the release N+1 cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2820819783
On Wed, 18 Feb 2026 07:44:22 GMT, Alan Bateman <alanb@openjdk.org> wrote:
In fact, I just realized that the same detail is available in the source code as comment a few lines above https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/i...
Thanks. I would be very surprised if interim javac would pull in PEM but as it's not always easy to determine this so best to leave until the release N+1 cleanup.
I am sorry for this situation, but I can't say when or if we will be able to do something about this. Currently, keeping the constant for one more release is always safe; removing it may be OK, but it is difficult to determine whether the missing constant will cause problems of not. It is only if the interim javac would touch a classfile that uses the constant, but it is not easy to say whether that will be the case. (And, IIRC, we've had a situation in the past that we had to re-introduce a constant, because it was needed in some specific circumstances.) I'll think again of ways to avoid the need to keep the constants. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2820968470
On Wed, 18 Feb 2026 08:24:51 GMT, Jan Lahoda <jlahoda@openjdk.org> wrote:
I am sorry for this situation, but I can't say when or if we will be able to do something about this.
No need to be sorry, you've always been very helpful and patient on this matter. @ascarpino I assume you'll update the PR to leave the constant in place. You can probably drop the core-libs and compiler labels from the PR if you want to keep the review on security-dev. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2821148471
On Wed, 18 Feb 2026 09:00:52 GMT, Alan Bateman <alanb@openjdk.org> wrote:
I am sorry for this situation, but I can't say when or if we will be able to do something about this.
Currently, keeping the constant for one more release is always safe; removing it may be OK, but it is difficult to determine whether the missing constant will cause problems of not. It is only if the interim javac would touch a classfile that uses the constant, but it is not easy to say whether that will be the case. (And, IIRC, we've had a situation in the past that we had to re-introduce a constant, because it was needed in some specific circumstances.)
I'll think again of ways to avoid the need to keep the constants.
I am sorry for this situation, but I can't say when or if we will be able to do something about this.
No need to be sorry, you've always been very helpful and patient on this matter.
@ascarpino I assume you'll update the PR to leave the constant in place. You can probably drop the core-libs and compiler labels from the PR if you want to keep the review on security-dev.
To be sure, I need to leave `PEM_API`, but I can remove the `@JEP` line, correct? @AlanBateman will do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2824069480
On Mon, 9 Feb 2026 21:04:34 GMT, Anthony Scarpino <ascarpino@openjdk.org> wrote:
Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
- `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied. - `DEREncodable` 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` indicates failures during cryptographic processing at runtime.
thanks
src/java.base/share/classes/java/security/BinaryEncodable.java line 1:
1: /*
Is `import jdk.internal.javac.PreviewFeature` still needed on line 28? src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 1:
1: /*
update copyright date ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829412160 PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829160926
On Mon, 9 Feb 2026 21:04:34 GMT, Anthony Scarpino <ascarpino@openjdk.org> wrote:
Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
- `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied. - `DEREncodable` 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` indicates failures during cryptographic processing at runtime.
thanks
src/java.base/share/classes/java/security/PEMEncoder.java line 163:
161: * string. 162: * 163: * @param de the {@code BinaryEncodable} to encode
Change variable name to `be`. src/java.base/share/classes/java/security/PEMEncoder.java line 260:
258: * byte array. 259: * 260: * @param de the {@code BinaryEncodable} to be encoded
Change variable name to `be`. src/java.base/share/classes/java/security/PEMEncoder.java line 279:
277: * {@code PKCS8EncodedKeySpec} objects can be encoded with this newly 278: * configured instance. Encoding other {@code BinaryEncodable} objects will 279: * throw an {@code PEMException}.
s/an/a/ src/java.base/share/classes/java/security/PEMEncoder.java line 327:
325: 326: if (key != null && privateEncoding == null) { 327: throw new IllegalArgumentException("This BinaryEncodable cannot " +
Some exception messages end with a period, others don't. Probably should be consistent. I don't think it common to end exception messages with a period. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829846441 PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829865682 PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829869191 PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829881214
On Mon, 9 Feb 2026 21:04:34 GMT, Anthony Scarpino <ascarpino@openjdk.org> wrote:
Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
- `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied. - `DEREncodable` 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` indicates failures during cryptographic processing at runtime.
thanks
src/java.base/share/classes/java/security/CryptoException.java line 26:
24: */ 25: 26: package java.security;
Suggest moving this to the `javax.crypto` package because of its name and it is more for crypto related errors. src/java.base/share/classes/java/security/CryptoException.java line 38:
36: * <p>This exception is not intended to represent internal 37: * provider errors, which should be reported using {@link ProviderException}. 38: */
Need an `@since` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2830317164 PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2830332106
Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
- `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied. - `DEREncodable` 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` indicates failures during cryptographic processing at runtime.
thanks
Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29640/files - new: https://git.openjdk.org/jdk/pull/29640/files/aba9622c..9697afd7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29640&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29640&range=00-01 Stats: 45 lines in 6 files changed: 5 ins; 2 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/29640.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29640/head:pull/29640 PR: https://git.openjdk.org/jdk/pull/29640
On Fri, 20 Feb 2026 01:32:39 GMT, Anthony Scarpino <ascarpino@openjdk.org> wrote:
Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
- `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied. - `DEREncodable` 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` indicates failures during cryptographic processing at runtime.
thanks
Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
review comments
src/java.base/share/classes/java/security/PEM.java line 76:
74: */ 75: 76: final public class PEM implements BinaryEncodable {
I think the order should be "public final". src/java.base/share/classes/java/security/PEMDecoder.java line 514:
512: * Returns a copy of this {@code PEMDecoder} that decodes and decrypts 513: * encrypted private keys using the specified password. 514: * Unencrypted PEM can also be decoded by the returned instance
Missing period. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 347:
345: * Specification. 346: * 347: * @param de the {@code BinaryEncodable} to encrypt. Supported types include
Change variable name to `be`. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 392:
390: * password-based encryption (PBE) algorithm and provider are used. 391: * 392: * @param de the {@code BinaryEncodable} to encrypt. Supported types include
Change variable name to be. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 426:
424: * Specification. 425: * 426: * @param de the {@code BinaryEncodable} to encrypt. Supported types include
Change variable name to be. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2833666554 PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2833557059 PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2833246705 PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2833253745 PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2833255134
On Fri, 20 Feb 2026 01:32:39 GMT, Anthony Scarpino <ascarpino@openjdk.org> wrote:
Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
- `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied. - `DEREncodable` 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` indicates failures during cryptographic processing at runtime.
thanks
Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
review comments
/remove-label compiler /remove-label core-libs ------------- PR Comment: https://git.openjdk.org/jdk/pull/29640#issuecomment-3948659120
participants (5)
-
Alan Bateman
-
Anthony Scarpino
-
Jaikiran Pai
-
Jan Lahoda
-
Sean Mullan