Re: [opensc-devel] [opensc-commits] svn opensc changed [3592] Add --list-token-slots / -T to pkcs11-tool to list only slots with tokens.
On Fri, Dec 12, 2008 at 8:20 AM, Alon Bar-Lev wrote: > On 12/6/08, Martin Paljak wrote: >> On 06.12.2008, at 21:27, Alon Bar-Lev wrote: >> >> >> > On 12/6/08, Martin Paljak wrote: >> > >> > > As it affect the overall operation of pkcs11-tool (C_GetSlotList is >> called >> > > only once during the lifetime of the tool) >> > > it is justified to have it as a generic option to pkcs11-tool. I'm just >> not >> > > sure if adding a verbose option is the right thing to do. >> > > If you actually use pkcs11-tool (as a human being) one often wants to >> cut >> > > the unnecessary noise (e.g. 13 empty virtual slots) >> > > So it also makes sense to have it as a shorthand option. >> > > >> > >> > I understand this... But having too many options is also makes it >> > difficult for people to use the tool. >> > >> >> I'm a firm believer in the 'explorer' approach to command line utilities. >> This means that the tools should always work and do something useful with >> minimal options and allow to tweak and expand the functionality in a >> consistent way as you learn. > > 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. I agree with Martin here. A list-like command should list all objects from all slots of all tokens -- by default -- without having to specify each token and slot. The user can ask more specific/restricted output using options. Of course the output should be clear to indicate the token and slot information of each object. Maybe something like the getinfo.py [1] tool. What could be none-reversible when using a "display all objects" command? Bye [1] pykcs11/trunk/samples/getinfo.py (the web server is down now so I do not have the exact URL) -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed [3592] Add --list-token-slots / -T to pkcs11-tool to list only slots with tokens.
On 12/12/08, Ludovic Rousseau wrote: > >> > > >> > I understand this... But having too many options is also makes it > >> > difficult for people to use the tool. > >> > > >> > >> I'm a firm believer in the 'explorer' approach to command line utilities. > >> This means that the tools should always work and do something useful with > >> minimal options and allow to tweak and expand the functionality in a > >> consistent way as you learn. > > > > 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. > > > I agree with Martin here. A list-like command should list all objects > from all slots of all tokens -- by default -- without having to > specify each token and slot. The user can ask more specific/restricted > output using options. There are two issues here: 1. Add more and more standalone options. (For example separate option to list slots with token and without). 2. Having more output by default from query. You did not address the first issue... So I guess you agree with the second one. Listing all slots is better than having opensc specific code (all virtual slots of one token), but then if you specify --login to this option and you don't have the same PIN for all tokens, you start increasing the login failure counter... Running this command a few more times and you lock few tokens. > Of course the output should be clear to indicate the token and slot > information of each object. Maybe something like the getinfo.py [1] > tool. > > What could be none-reversible when using a "display all objects" command? One example: pkcs11-tool --list-objects --login --pin '' These tools must be consistant... and a solution of --list-objects without --login works using a specific slot and --list-objects without --login list all slots is none consistant. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed [3592] Add --list-token-slots / -T to pkcs11-tool to list only slots with tokens.
On 12.12.2008, at 9:20, Alon Bar-Lev wrote: >> I'm a firm believer in the 'explorer' approach to command line >> utilities. >> This means that the tools should always work and do something >> useful with >> minimal options and allow to tweak and expand the functionality in a >> consistent way as you learn. > > 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. >> Or it could be related to Tokens :) Currently pkcs11-tool options >> that are >> capitals deal with the module itself, or are "global" in the sense >> that they >> don't deal with any objects in a specific slot (except -O). >> So it would also be OK to keep only the short option -T. > > 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. Like USB ports - you care more about the devices connected to them than ports themselves. Similarly to the change in [3597] I'd like to change pkcs11-tool - O for example to display all objects in all slots, unless a slot is specified. >>> >>> I've seen this... You mean all objects in first none empty slot... >>> >> No. All objects in all slots. With readers a casual user has one or >> maybe >> two readers (and N virtual OpenCT readers on Ubuntu) and from >> granularity >> point of view it is fair to find the first reader that has anything >> in it to >> process further. >> But current OpenSC implementation has many slots for every card >> (default is >> 4) so only displaying stuff from the first slot only reveals half >> of the >> stuff. > > 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. >>> Well, I must say I did not like this... But it did not made any >>> damage. I don't like the goto you added there :) Better is to >>> search using another variable... >>> >> Right, I though about the goto and decided to use if only because I >> have an >> evil mind ;) gotos are used all over the place in opensc, so it >> doesn't >> matter. It's readable I hope. > > gotos are used in order to jump to cleanup code, not part of normal > program flow. And also the fact that there are bad stuff in the code > does not mean that any more should be added. I'm personally not religious about gotos. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed [3592] Add --list-token-slots / -T to pkcs11-tool to list only slots with tokens.
On 12/12/08, Martin Paljak 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 '' 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
