* keyid.c (keyid_from_sk): Minor performance boost by caching secret key
[gnupg.git] / PROJECTS
index c5eb71f..d6725f7 100644 (file)
--- a/PROJECTS
+++ b/PROJECTS
@@ -1,49 +1,46 @@
 
 
-    * Check if an object (a message, detached sign, public key, or whatever)
-      is signed by definite user, i.e. define user
-      (userid, or any other unique identification) on command line.
-      --> NO: Use a script and --status-fd
-
-    * Change the internal represention of keyid into a struct which
+    * Change the internal representation of keyid into a struct which
       can also hold the localid and extend the localid to hold information
       of the subkey number because two subkeys may have the same keyid.
 
       can also hold the localid and extend the localid to hold information
       of the subkey number because two subkeys may have the same keyid.
 
-    * signature verification is done duplicated on import: in import.c and
-      then in trustdb.c too.  Maybe we can use a flag to skip the actual
-      verification process (this should work if we use the same keyblock,
-      but I'm not sure how to accomplish that).  Another way is to allow
-      the import of bogus data and let trustdb mark these keys as invalid;
-      I see an advantage in this that it may help to prevent a DoS on a
-      keyserver by sending him a lot of bogus signatures which he has
-      to check - Needs further investigation.
-
     * Add a way to override the current cipher/md implementations
       by others (using extensions)
 
     * Add a way to override the current cipher/md implementations
       by others (using extensions)
 
-    * Not GnuPG replated:  What about option completion in bash?
+    * Not GnuPG related:  What about option completion in bash?
       Can "--dump-options" be used for this or should we place the
       Can "--dump-options" be used for this or should we place the
-      options in a special ELF segment?
-
-    * Split key support (n-out-of-m)
+      options in an ELF note section?
 
 
-    * Check Berkeley DB - it is in glibc - any licensing problems?
+    * Split key support (n-out-of-m).  Use our own protocol or figure out
+      how PGP does it.
 
     * add an option to re-create a public key from a secret key; we
 
     * add an option to re-create a public key from a secret key; we
-      can do this in trustdb.c:verify_own_keys.
-      (special tool?)
+      can do this in trustdb.c:verify_own_keys. (special tool?)
+      Hmmm, we better drop the duplication of the public part and just keep
+      the secrets in the "secring" - this has the additional that we can
+      put those secrets on a hardware token.
 
 
-    * rewrite --list-packets or put it into another tool.
-
-    * We need a maintainence pass over the trustdb which flags
-      signatures as expired if the key used to make the signature has
-      expired. Maybe it is a good idea to store the exiration time
-      in the key record of the trustdb.
     * write a tool to extract selected keys from a file.
 
     * write a tool to extract selected keys from a file.
 
-    * Change the buffering to a mbuf like scheme? Need it for PSST anyway;
-      see Michael's proposal.
-
-    * Work on the library
+    * Change the buffering to a mbuf like scheme?  See Michael's proposal.
 
     * Keep a list of duplicate, faked or unwanted keyids.
 
 
     * Keep a list of duplicate, faked or unwanted keyids.
 
+    * The current code has knowledge about the structure of a keyblock.
+      We should add an abstraction layer so that adding support for
+      different certificate structures will become easier.
+
+    * "Michael T. Babcock" <mbabcock@fibrespeed.net> suggested to write
+      an event log so that other software can display a key history or
+      alike with GnuPG results.  This should be connected to the keyrings.
+
+
+
+ Copyright 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
+
+ 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.