scute/TODO

* Undergoing clean-up:
** table.{h,c}: Simplify, remove hurdism.
** agent.{h,c}: Clean namespace.
** gpgsm.c: Support more than one keygrip.
** slots.{h,c}: Cleanup lookup function and the rest.
** p11-closeallsessions.c, p11-closesession.c, p11-findobjects.c,
   p11-findobjectsfinal.c, p11-findobjectsinit.c, p11-getattributevalue.c,
   p11-getmechanisminfo.c, p11-getmechanismlist.c, p11-getsessioninfo.c,
   p11-getslotinfo.c, p11-getslotlist.c, p11-gettokeninfo.c,
   p11-opensession.c, p11-sign.c, p11-signinit.c

* Bugs or misfeatures:
** If more than one certificate with the same keygrip is installed in
   gpgsm, only the first one is found.  We probably should return them
   all and let Mozilla choose among them (if Mozilla supports that,
   otherwise we need to make it configurable).

* Missing features:
** Implement random number generation function C_GenerateRandom.
** Add canonical gnupg logging module.

* Standard ambiguities, or non-conformance in the applications:
** If the token is removed, the current sessions are closed.  If then
   a new token is inserted, and the application calls C_OpenSession, a
   previously used session handle may be reused.  It is not clear to
   me what behaviour the standard specifies in this case.

** Mozilla NSS has this comment (and relies on the assumption):
  "check to see if the module has added new slots. PKCS 11 v2.20
  allows for modules to add new slots, but never remove them. Slots
  cannot be added between a call to C_GetSlotLlist(Flag, NULL,
  &count) and the subsequent C_GetSlotList(flag, &data, &count) so
  that the array doesn't accidently grow on the caller. It is
  permissible for the slots to increase between successive calls with
  NULL to get the size."

  My reading of the spec is quite different.  I do not think it does
  say that the slot list can not shrink, at least it does not say
  explicitely.  Maybe it is a tacit assumption, because the interface
  is obviously broken if the list shrinks.  However, the spec says:

  "All slots which C_GetSlotList reports must be able to be queried as
  valid slots by C_GetSlotInfo. Furthermore, the set of slots
  accessible through a Cryptoki library is checked at the time that
  C_GetSlotList, for list length prediction (NULL pSlotList argument)
  is called. If an application calls C_GetSlotList with a non-NULL
  pSlotList, and then the user adds or removes a hardware device, the
  changed slot list will only be visible and effective if
  C_GetSlotList is called again with NULL. Even if C_GetSlotList is
  successfully called this way, it may or may not be the case that
  the changed slot list will be successfully recognized depending on
  the library implementation. On some platforms, or earlier PKCS11
  compliant libraries, it may be necessary to successfully call
  C_Initialize or to restart the entire system."

  Note the phrase "user adds or removes a hardware device" and "the
  changed slot list".  This implies that removal of a hardware device
  could lead to a shrinking slot list.  If this is true, then the note
  in the NSS code is incorrect, and the NSS code will break if a
  driver shrinks the slot list.

  However, as long as the assumption is made, we have to comply.

Copyright 2006 g10 Code GmbH

This file is free software; as a special exception the author gives
unlimited permission to copy and/or distribute it, with or without
modifications, as long as this notice is preserved.

This file is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.