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