On Wed, 12 Aug 2026 12:20:28 GMT, Sean Mullan <[email protected]> wrote:
>> Guanqiang Han has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Return early after CRL is cleared
>
> src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java
> line 680:
>
>> 678: private static Collection<X509CRL> getMatchingCRLs
>> 679: (X509CRL crl, CRLSelector selector) {
>> 680: if (crl != null && (selector == null || selector.match(crl))) {
>
> Now you don't need to make this change anymore.
The early return handles the initial request that encounters the oversized
`crl`, but I wonder whether the null check of `crl` in `getMatchingCRLs` is
still needed for the cached path, as shown below:
https://github.com/openjdk/jdk/blob/8b81f8fbb8428ccd137240efc465f580ac7eb62b/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java#L607-L611
After the oversized `crl` is set to null. Maybe a subsequent
`engineGetCRLs(null)` within `CHECK_INTERVAL` takes the cached path and calls
`getMatchingCRLs(null, null)`.
With the original condition, this returns `Collections.singletonList(null)`,
while the revised condition returns an empty collection.
It seems that the original logic assumes that `crl` and `selector` cannot both
be null. Are there any cases where this assumption might not hold?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32164#discussion_r3767160878
