On 12/12/08, Martin Paljak <martin.pal...@gmail.com> wrote: > > I disagree. When the subject is complex and/or sensitive and/or > > none-reversible the above does not apply. Token management is complex, > > sensitive and sometimes none-reversible. > > > As long as it remains read-only it is safe I believe.
Just wrote an example... pkcs11-tool --list-object --login --pin '00000000' Will increment and eventually lock few of the tokens. > > No. It relates to slots. The PKCS#11 specs treats this as SLOT with > > TOKEN. Please follow this logic in parameters. > > > Slots are just gateways to get access to tokens. Tokens are what actually > matter and do stuff, (empty) slot is just an implementation detail. Well... PKCS#11 tool should use PKCS#11 terms... C_GetSlotList with true as tokenPresent is what you want here. > Like USB ports - you care more about the devices connected to them than > ports themselves. Wrong. PKCS#11 treats slots as important element. (C_GetSlotList, C_GetSlotInfo, C_WaitForSlotEvent), token insert is a slot event and not the other way around. To make the utility usable and understandable for both developers and users one should keep the terms consistant with the specification. But I truly don't care... If it is that important to you to add inconsistent stuff and as there is no active project leader... I can only suggest that this is wrong. > > Again... You miss the point of pkcs11-tool. This is PKCS#11 generic > > tool, not OpenSC specific tool. It cannot make any assumption on the > > provider identity. > > > > The problem is also generic. Defaulting to slot 0 is not logical to > non-programmers. pkcs11-tool is used by non-programmers. I already told you that I have no problem with the default to first available slot (except of the actual implementation). I do have problem in breaking the slot domain. Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
