RFR: 8242565: Policy initialization issues when the denyAfter constraint is enabled

[Sean Mullan]

When a SecurityManager is enabled, early code paths that involve 
ServiceLoader (SL) can trigger permission checks that cause parsing of a 
custom policy file to fail due to recursive processing of the policy file.

I have fixed two of these issues which can occur under the following 
conditions:

1. SecurityManager enabled
2. Signed JAR on the classpath
3. Policy file granting permission based on who signed jar and a 
keystore entry containing the alias/key
4. Code triggering a permission check based on that grant
5. A SHA-1 denyAfter constraint set in the jdk.jar.disabledAlgorithms 
property in the java.security file

Parsing of the denyAfter constraint is required to verify the signed 
JAR, which happens very early. This causes SL to search for a 
LocaleProvider to parse the denyAfter date field which triggers a 
permission check, causes the policy machinery to bootstrap, and which 
triggers further permission checks, etc.

The first issue is that PKCS12KeyStore is unable to verify the integrity 
of the keystore entry in the custom policy file because it cannot find a 
"PBE" AlgorithmParameters implementation. I fixed this by adding 
"SunJCE" to the list of providers that are automatically installed 
during signed JAR verification.

The second issue is also in PKCS12 KeyStore where it tries to 
instantiate a java.text.Collator which also uses SL and thus triggers a 
recursive permission check. This was fixed by using a lazy 
initialization Holder pattern.

webrev: https://cr.openjdk.java.net/~mullan/webrevs/8242565/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8242565

More details and stack traces can be found in the bug.

Thanks,
Sean