On Thu, 17 Oct 2024 16:24:02 GMT, Anthony Scarpino <ascarp...@openjdk.org> wrote:
>> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a >> format for encoding and decoding cryptographic keys and certificates. It >> will be integrated into JDK24 as a Preview Feature. Preview features does >> not permanently define the API and it is subject to change in future >> releases until it is finalized. >> >> Details about this change can be seen at [PEM API >> JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> 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 39 commits: > > - merge with master & updates > - Merge branch 'master' into pem > - partial code review update > - fix decoding non-encrypted types > - comments updates and getPBEID > - test fixes > - Merge branch 'master' into pem > - fix StringBuffer/Builder > X509C* changes > - test merge with futures > docs cleanup > - review comments part 2 > - ... and 29 more: https://git.openjdk.org/jdk/compare/28538524...4b3aae00 This JEP is misnamed. The RFC clearly says For reasons that basically boil down to non-coordination or inattention, many PKIX, PKCS, and CMS libraries implement a text- based encoding that is similar to -- but not identical with -- PEM encoding. ... Unlike legacy PEM encoding [[RFC1421](https://www.rfc-editor.org/rfc/rfc1421)], OpenPGP ASCII armor, and the OpenSSH key file format, textual encoding does *not* define or permit headers to be encoded alongside the data. Empty space can appear between the pre-encapsulation boundary and the base64, but generators SHOULD NOT emit such any such spacing. (The provision for this empty area is a throwback to PEM, which defined an "encapsulated header portion".) So this RFC is clearly not PEM and this JEP shouldn't be named as such, hence class names neither. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17543#issuecomment-2423196928
