EVALUATION
This is due to the change we put in for:
7113275: compatibility issue with MD2 trust anchor and old X509TrustManager
In AbstractTrustManagerWrapper, which is used as a wrapper when the passed-in custom TM isn't a X509ExtendedTrustManager, we are now caching the accepted certificate issuers from the constructor to speed up future AlgorithmConstraints checks.
The addAll(..., null) is throwing the NPE when getAcceptedIssuers is returning null.
There is one other place that calls getAcceptedIssuers, and that's in the ServerHandshaker when we do client authentication. We'll also throw a NPE there if someone passes in a custom TM that has this behavior. However, I think this is not normally seen because most applications don't do client auth by default, and don't provide custom trustmanagers with this broken behavior. This behavior has been there since at least 1.4.2 FCS, so don't feel it's necessary to fix here.
To fix it, we can either remove the caching, or we can check for null during the initialization. I'm leaning toward the latter, but the former is the safest.
|
EVALUATION
I prefer to checking the null value before adding it to the collection.
Please note that if X509TrustManager.getAcceptedIssuers() does not return the expected trusted issuers as the specification required, it does not grant the application will work as expected during algorithm constraints checking. The algorithm constraints is expected to ignoring the trusted certificates checking (I think TM.getAcceptedIssuers() return null does not means that there is no trusted certificate), but if the accepted issuers is null or empty, the checking will be done on every cert in the chain.
|
Java