Alon Bar-Lev wrote:
Hello, Todd sent me a trace of his session. We have found two issues with coolkey PKCS#11 provider. 1. Metadata I can see that C_GetTokenInfo returns empty fields for most of the fields (manufacturerId, model, serialNumber). I guess because NULL mCUID. This is highly none standard!
Thanks Alon, agreed. please write a bug so we don't loose this!...
This is not allowed by the spec. C_Initialize() fork() semantic is specifically specified as unpredictable. You need to finalize before the fork().These fields must not be empty, each provider should put its signature in these fields to allow distinguish between providers and tokens. Please make it return something logical. 2. Threading/multiprocess The following sequence should be valid with PKCS#11 (explicitly stated by standard): Given A, B processes. A.1. C_Initialize () A.2. <do whatever> A.3. fork()
B.1 C_Initialize () /* REQUIRED by standard, C_Initialize () after fork() */While this is not necessarily non-compliant behavior, it still seems reasonable to write a bug on this was well. It seems a reasonable thing to do.B.2 C_Finalize () /* We don't need PKCS#11 in this process */ B.3 <continue not using token> A.4 <continue using token>From some strange reason the sequence in the child process causes theparent to fail interaction with the token. Please make this sequence work, it is very important as child must not affect its parent. The simplest solution would be to store getpid () result at C_Initialize() an compare it in sequence C_Initialize () calls, if it is different, first clean up state and start fresh.
thanks Alon. bob
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel
