RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v6]
Sean Mullan
mullan at openjdk.org
Tue Oct 14 18:22:39 UTC 2025
On Tue, 14 Oct 2025 03:55:54 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:
>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>>
>> updates
>
> src/java.base/share/classes/java/security/PEM.java line 68:
>
>> 66: * metadata that accompanies the PEM data. This value was not defensively
>> 67: * copied by the constructor, and the {@link #leadingData()} method does not
>> 68: * return a clone.
>
> I see the Javadoc already notes that leadingData isn’t defensively copied or cloned. Given that PEM is a record (and callers might assume immutability), should we clarify ownership semantics a bit more — e.g., that the caller must not modify the array after passing it in?
The javadoc should clearly describe the mutability aspects, but we can't control what the caller does after that.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430031746
More information about the security-dev
mailing list