[14] RFR JDK-8176837 "SunPKCS11 provider needs to check more details on PKCS11 Mechanism"

[Xuelei Fan]

Just a very minor nit.

In the initToken() implementation, there is a check for the upper 32 
bits set of a mech and may continue to next mech.  The continue may 
ignore the showinfo dump for some cases in the patch.

Maybe, it might be more straightforward if we don't want to merge the 
log in one place:
1. always show the mech info log for every supported mechanism.
2. if not enabled, log with "DISABLED ...".
3. if upper 32 bits set, log with "UNKNOWN ...".
4. if legacy, log with "Legacy ...".

    for each mech {
        if (showInfo) {
            System.out.println("Mechanism " +
                Functions.getMechanismName(longMech) + ": " +
                p11.C_GetMechanismInfo(slotID, longMech);
        }

        if (!config.isEnabled(longMech)) {
            System.out.println("DISABLED in configuration");

            continue;
        }

        if (longMech >>> 32 != 0) {
            System.out.println("Unknown mechanism in configuration");

            continue;
        }

        int mech = (int)longMech;
        if (isLegacy(token, mech)) {
            System.out.println("Legacy mechanism in configuration");

            continue;
        }

        ...
    }

Otherwise, looks good to me.  Just a nit, no more review cycle is needed 
for me.

Thanks,
Xuelei

On 9/18/2019 5:56 PM, Valerie Peng wrote:
> 
> Can someone help reviewing this fix? AFAIK, only S11.4 have such 
> mechanisms, e.g. RC4 which only does decryption but not encryption.
> But the checks seems reasonable to apply to all PKCS11 libraries when 
> querying mechanisms.
> No new regression test needed as this is already caught by running 
> existing regression tests on S11.4.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8176837
> Webrev: http://cr.openjdk.java.net/~valeriep/8176837/webrev.00/
> 
> Thanks,
> Valerie