On 06/21/2011 07:59 PM, Stef Walter wrote: >> I didn't like the pinfile attribute of pkcs11-urls much, because >> its semantics are undefined. I see it as an option that could cause >> compatibility issues between libraries using URLs. That's why I >> have ignored it so far. > > Yes, I understand that the pinfile attribute is really ambiguous. > Until recently I saw it as an oddity and confusing. However I think > we can turn the ambiguity of the pinfile attribute to an advantage > (although I'm going to see if we can rename it to 'pin' on > s...@ietf.org). I've created an API in p11-kit which allows > registering of callbacks to handle specific (or any) pinfile. This > allows a UI (whether CLI or GUI) to register a pin callback. Then > gnutls (or other libraries) can detect the presence of a pinfile > attribute and use p11-kit to check if anyone has registered a > callback for that pinfile.
This sounds dangerous in terms of code execution. If you put a memory address would someone be able to execute arbitrary code by modifying it? If you put an index to functions, would someone be able to manipulate index and data to perform other than the expected calculations? These might not be easy to ensure. >> Are there other alternatives to solve the issue at hand? > I've tried threading context specific callbacks throughout gnutls, > and it was a very tedious and messy exercise. I have an incomplete > patch somewhere if you're interested. What if every gnutls_pkcs11_privkey_t struct has its own pin function? Would that help? regards, Nikos _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
