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
