[7u40] Resolve ambiguity in OCSPChecker & CrlRevocationChecker
sean.coffey at oracle.com
Thu May 23 03:00:57 PDT 2013
On 23/05/2013 10:45, Andrew Hughes wrote:
> ---- Original Message -----
>> Bug report just created :
>> JDK-8015275 : Resolve ambiguity in OCSPChecker & CrlRevocationChecker
>> Looks like both classes being modified for jdk8 don't exist any longer.
> Ah, even better. Seems they were removed in:
> changeset: 5475:0c6830e7241f
> parent: 4964:d383b5d128e3
> user: mullan
> date: Wed May 30 17:19:46 2012 -0400
> summary: 6854712: Revocation checking enhancements (JEP-124)
> so no need to even apply this there just to keep the two in sync.
Well it's not just to keep to the two in sync. The "jdk8 first" rule is
there to avoid regressions being encountered in future upgrades. I've
marked JDK-8015275 with '8-na'
> Is this ok to push then?
Can you get a review from an official reviewer first? Preferably someone
from security team.
To keep in line with process them, a simple approval request can be logged.
>> On 22/05/2013 19:25, Andrew Hughes wrote:
>>> Webrev: http://cr.openjdk.java.net/~andrew/7u/webrev/
>>> There's an ambiguity that applies when building OpenJDK 7 with OpenJDK 6
>>> (and hence I haven't posted this for 8 as it can't be built with 6).
>>> OpenJDK 6 has a class
>>> OpenJDK 7 has a class java.security.cert.CertificateRevokedException.
>>> Two classes in sun.security.provider.certpath in OpenJDK 7 import
>>> java.security.cert.CertificateRevokedException indirectly via
>>> java.security.cert.*. This appears to cause a compilation failure
>>> in some cases if the ambiguity is resolved to the
>>> in the bootstrap JDK instead of the new one in java.security.cert.
>>> This is easily fixed by explicitly importing the classes required as in the
>>> above webrev.
>>> Is this ok for 7u? If so, can I have a bug ID for it?
More information about the jdk7u-dev