For the PKCS11 wrapper stuff, would it be legitimate to tie this to JNA? The current version of the wrapper is about 8 years old - and doesn't support a lot of the new mechanisms. At some point, this is going to need an update to support PKCS11 v2.30 and other new mechanisms. I had a thought that instead of doing this through new native code for the new structures it may make sense to provide support for a JNA based definition of those structures. That would make extending the PKCS11 provider a bit easier.
Later, Mike At 09:06 AM 10/29/2012, John Zavgren wrote: >Greetings: > >I modified several files in the core library security code: > >src/share/native/sun/security/jgss/wrapper/GSSLibStub.c >src/share/native/sun/security/jgss/wrapper/NativeUtil.c >src/share/native/sun/security/pkcs11/wrapper/p11_convert.c >src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c >src/share/native/sun/security/pkcs11/wrapper/p11_digest.c >src/share/native/sun/security/pkcs11/wrapper/p11_general.c >src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c >src/share/native/sun/security/pkcs11/wrapper/p11_sign.c >src/share/native/sun/security/pkcs11/wrapper/p11_util.c >src/solaris/native/sun/security/pkcs11/j2secmod_md.c >src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c > >to eliminate compiler warnings. I used the OS-independent ptr_to_jlong() and >jlong_to_ptr() macros to ensure that casting is done correctly, changed local >variables to have the correct type before comparison (unsigned versus signed >integers), made format strings and arguments consistent, initialized one data >structure (memory was being accessed before initialization), initialized >several local variables, etc. > >The webrev image of these changes is located at: >http://cr.openjdk.java.net/~alanb/8001579/webrev/ > >I look forward to your comments. > >Thanks! >John Zavgren
