RFR: 8298420: PEM API: Implementation (Preview) [v2]

[Anthony Scarpino]

On Thu, 25 Jul 2024 21:02:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - bad test check
>>  - internal PEMRecord optimization
>
> src/java.base/share/classes/sun/security/util/Pem.java line 303:
> 
>> 301:         return new Pem(header.getBytes(StandardCharsets.ISO_8859_1),
>> 302:             data.getBytes(StandardCharsets.ISO_8859_1),
>> 303:             footer.getBytes(StandardCharsets.ISO_8859_1));
> 
> So you read bytes and accumulate them as strings and then return as bytes at the end. Is it possible to not convert to strings in between? Or, in `PEMDecoder` you compare the header and footer to bytes arrays. Is it possible to return header and footer as strings and compare to strings there? Plus, can the data part be de-BASE64ed here?

The new code changes this behavior.

> test/jdk/java/security/PEM/PEMCerts.java line 294:
> 
>> 292: 
>> 293:     static String makeNoCRLF(String pem) {
>> 294:         return Pattern.compile("/n").matcher(pem).replaceAll("");
> 
> You mean no new lines inside the PEM? Is that something legal?

By the spec, probably not.. but parsers are suppose to be flexible and excluding formats usually ends up is user complaints.  It's no extra work to allow it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1692456189
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1692455722