On Fri, 15 May 2026 03:27:03 GMT, Anthony Scarpino <[email protected]>
wrote:
>> src/java.base/share/classes/sun/security/util/Pem.java line 320:
>>
>>> 318: } while (hyphen < 5);
>>> 319:
>>> 320: while ((c = is.read()) != eol && c != -1 && c != '\s' && c
>>> != '\t') {
>>
>> This is different from reading the header. Space and tab are not skipped,
>> instead, they end the loop. This means a block ending with `-----END
>> SOMETHING------ xyz` is treated as valid.
>
> The way I read RFC 7468,
> ```
> textualmsg = preeb *WSP eol
> *eolWSP
> base64text
> posteb *WSP [eol]
>
> `\s` , `\t` and maybe `[eol]` are part of the footer otherwise they would
> not be listed above. I also interpreted, but wasn't certain, that `[eol]`
> was optional as it maybe the EOF. But if it was not EOF, then there would be
> an `eol`. If I cannot assume the last line is `eol` or EOF, then I will read
> one byte past the pem, in your example `x` and cannot push the char back into
> the inputstream.
>
> If I interpret the way you see it, `readPEM()` stops after the last dash, and
> the next inputstream read may read the remainder of that line, which would be
> awkward for `leadingData` or an app that reads inputstream directly.
No, I don't mean `readPEM()` should stop after the last dash. Since `*WSP` is a
part of the encoding we should consume it. I agree with your understanding that
`eol` is optional only because EOF can be there. Thus In my example when `x` is
encountered before either `eol` or EOF, I would treat it as an invalid block.
There is no need to push any char back, just stop after `eol` or EOF.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r3248087864
