On Tue, Feb 19, 2013 at 10:19 AM, Ludovic Rousseau <[email protected]> wrote: > 2013/2/19 Chris J Arges <[email protected]>: > We need to understanf why the code you removed is causing problems. It > is supposed to solve problems :-) > > Alon, it looks like you wrote this code. Any idea? > Maybe call C_Finalize() only if initialized_pid has been set (!= -1)? > > commit 1875a25c4090b261d9eeb419beeb74bae9735650 > Author: alonbl <alonbl@c6295689-39f2-0310-b995-f0e70906c6a9> > Date: Thu Mar 6 14:56:31 2008 +0000 > > PKCS#11 "Application and processes" instructs the sequence > that should be taken after fork(). > Applications should call C_Initialize() immediately after fork() > to reinitialize the provider. > > The change monitor the pid that calls C_Initialize(), if it is > different than previous C_Finalize() is called.
Looking at PKCS#11 v2.20, 6.6.1 Applications and processes It tells: In the scenario specified above, C should actually call C_Initialize whether or not it needs to use Cryptoki; if it has no need to use Cryptoki, it should then call C_Finalize immediately thereafter. This (having the child immediately call C_Initialize and then call C_Finalize if the parent is using Cryptoki) is considered to be good Cryptoki programming practice, since it can prevent the existence of dangling duplicate resources that were created at the time of the fork() call; however, it is not required by Cryptoki. So maybe "helping" the cryptoki application is actually not a good idea, better report some error or print some fat warning to stderr/out "misbehaving PKCS#11 application". Martin _______________________________________________ Muscle mailing list [email protected] http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
