Hi Martin,
A few comments:
1) The newly added property is causing 41 regression tests to fail due
to permission problem. You will need to update
src/java.base/share/lib/security/default.policy
--- a/src/java.base/share/lib/security/default.policy
+++ b/src/java.base/share/lib/security/default.policy
@@ -127,6 +127,7 @@
permission java.lang.RuntimePermission
"accessClassInPackage.sun.nio.ch";
permission java.lang.RuntimePermission "loadLibrary.j2pkcs11";
permission java.util.PropertyPermission
"sun.security.pkcs11.allowSingleThreadedModules", "read";
+ permission java.util.PropertyPermission
"sun.security.pkcs11.enableNativeKeysExtraction", "read";
permission java.util.PropertyPermission "os.name", "read";
permission java.util.PropertyPermission "os.arch", "read";
permission java.util.PropertyPermission
"jdk.crypto.KeyAgreement.legacyKDF", "read";
2) As for p11_keymgmt.c, I agree that the earlier version maybe too
strict to check for CKR_OK for the first two C_GetAttributeValue(...)
call. Now that we don't check the status, we can probably remove the
TRACE0 code (line 190 and 217). BTW, the JNI method signature on line
128 and 397 need to be updated to include the jobject jWrappingMech
argument.
3) For the new system property, it will need a CSR. Here are some
pointers on CSR and its process, faq, etc.
* https://wiki.openjdk.java.net/display/csr/Main
* https://wiki.openjdk.java.net/display/csr/CSR+FAQs
Thanks,
Valerie
On 10/26/2018 10:57 AM, Martin Balao wrote:
Hi Valerie,
I fixed all previously discussed issues in Webrev.13:
*
http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.13/
<http://cr.openjdk.java.net/%7Embalao/webrevs/6913047/6913047.webrev.13/>
*
http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.13.zip
<http://cr.openjdk.java.net/%7Embalao/webrevs/6913047/6913047.webrev.13.zip>
In addition to that, I fixed a couple of bugs introduced in p11_keymgmt.c.
In Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo function,
the first call to C_GetAttributeValue (to get CKA_CLASS, CKA_KEY_TYPE,
CKA_SENSITIVE and CKA_NETSCAPE_DB attributes) may fail because the key
may not have a CKA_NETSCAPE_DB attribute. That is fine. It just means
that we are not going to get that attribute -which does not exist- and
it won't be needed for key unwrapping.
Later in Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo
function, a similar issue happened. The call to get buffer lengths may
return an error if one of the attributes does not exist. This is fine
because length values are obtained anyways and based on that we were
not going to query for non-existent attributes later.
These bugs were silently making all keys not to be extracted.
Thanks,
Martin.-
