RFR: 8160655 Fix denyAfter and usage types for security properties

Anthony Scarpino anthony.scarpino at oracle.com
Wed Feb 8 03:35:36 UTC 2017


The two changes are connected, removing the key algorithm check in the 
second change is linked to changing the permits() in the first change. 
But I agree that this change is unnecessary.. I'm going to revert it back.

thanks

Tony

On 01/26/2017 01:09 PM, Xuelei Fan wrote:
> DisabledAlgorithmConstraints.java
> =================================
>      public final boolean permits(Set<CryptoPrimitive> primitives, Key
> key) {
> -        return checkConstraints(primitives, "", key, null);
> +        try {
> +            permits(new ConstraintsParameters(key.getAlgorithm(), null,
> key,
> +                    null));
> +            return true;
> +        } catch (CertPathValidatorException e) {
> +            return false;
> +        }
>      }
> Looks like there are some overlap if this method is not used for cert.
> What's the point for this update?
>
> @@ -172,56 +180,21 @@
> -        // check the key algorithm
> -        if (!permits(primitives, key.getAlgorithm(), null)) {
> -            return false;
> -        }
> This block cannot be removed as the standard permits() (seel line 130)
> still need to this check.
>
> Otherwise, looks fine to me.
>
> Xuelei
>
> On 1/23/2017 3:27 PM, Anthony Scarpino wrote:
>> Hi,
>>
>> I need a code review of this change that brings more detail constraints
>> checking and control to certpath and jar disabled algorithm Security
>> properties.
>>
>> http://cr.openjdk.java.net/~ascarpino/8160655/webrev/
>>
>> thanks
>>
>> Tony




More information about the security-dev mailing list