On Wed, 12 Aug 2026 14:09:03 GMT, Guanqiang Han <[email protected]> wrote:
>> 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?
Let me take a closer look and get back to you. I feel like this is guarding
against a bug in the code. A null CRL should never really be passed into
`getMatchingCRLs`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32164#discussion_r3768439301
