Looks good, mostly minor stuff so far, just have one other file I need
more time to review:
* java.security
Update description of new constraints to match CCC.
* PKIXExtendedParameters.java
Update class description (it is out-of-date).
* CertConstraintParameters.java
2 * Copyright (c) 2016
DisabledAlgorithmConstraints.java
=
public final boolean permits(Set primitives, Key
key) {
-return checkConstraints(primitives, "", key, null);
+try {
+permits(new ConstraintsParameters(key.getAlgorithm(), null,
key,
+
In the first sentence I would give the fully qualified name
(javax.security.auth.Subject) instead of just Subject to provide a bit
more context. Otherwise, looks good.
--Sean
On 1/19/17 12:14 PM, Jamil Nimeh wrote:
Hello all,
Please review this one release note that documents a change in beh
Hi Siba,
In valid.policy, use 'grant codeBase "file:${test.classes}/*"' so that
only the tests are granted the needed permissions.
In ClassLoaderTest.java, the @bug should be 8168075. Also, the @summary
contains a bunch of lines (29-39) that should probably just be code
comments.
Seems fi
> On 26 Jan 2017, at 17:55, Mandy Chung wrote:
>
>
>> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote:
>>
>>>
>>> jdk.vm.compiler is defined by the application class loader and it’s used by
>>> AOT tool. I wonder why it has to run with security manager.
>>
>> Without java.security.AllPermis
> On 26 Jan 2017, at 03:32, Mandy Chung wrote:
>
> (dropping jdk9-dev. security-libs is the appropriate list to review security
> permission)
>
>> On Jan 23, 2017, at 1:56 PM, Doug Simon wrote:
>>
>> Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a
>> security mana
> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote:
>
>>
>> jdk.vm.compiler is defined by the application class loader and it’s used by
>> AOT tool. I wonder why it has to run with security manager.
>
> Without java.security.AllPermission, the policy for jdk.vm.compiler required
> to get throu
