From: Anthony F. <ant...@gm...> - 2013-07-31 03:43:20
|
Greetings. (Note, I find it a bit easier to reply if there's a human name there somewhere. :) On Tue, Jul 30, 2013 at 9:49 AM, <op...@se...> wrote: > The point is that the slot ID (as numbered by the PKCS#11 drver) has > nothing to do with the index of the slots array generated by libp11, only > accidentally they match when you're using one driver only. > > If you identify a key with, for instance, the name > "slot_761406623-id_1307301149164400" (reporting the slot ID), it will > miserably fail (and it is a good thing, at least it is not trying to > access the wrong slot with a bad PIN) because it finds out that 761406623 > is not good. The message is "Invalid slot number: 761406623" even if the > slot ID is exactly that. > > Now, I suspect that the original intention is to put the slot ID, not the > slot array index, in the string... is my observation correct? > Or did I make any mistake in my analysis of the code? A patch would be interesting, especially if it is obvious that any large number is intended as slot id, not array index -- that could minimize compatibility headaches. > If I am right, I am likely going to work on my old version and change the > code for my purpose even if the intention was not to indicate the slot > ID...: do you have some important advice regarding my attempt? If you can use a token label, does that work for your cases? libp11 allows access via "label_...." if I remember correctly. Failing that, can you enumerate the slots via libp11 and get a (presumably valid) handle that way? Good luck. Best regards, Anthony Foiani |