Replaced INTLLIBS by LIBINTL.
[gnupg.git] / PROJECTS
index 842d2a3..d6725f7 100644 (file)
--- a/PROJECTS
+++ b/PROJECTS
@@ -1,22 +1,46 @@
 
-  * Urko Lusa <ulusa@lacueva.ddns.org> is working on es.po
+    * 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.
 
+    * Add a way to override the current cipher/md implementations
+      by others (using extensions)
 
-  * 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.
+    * Not GnuPG related:  What about option completion in bash?
+      Can "--dump-options" be used for this or should we place the
+      options in an ELF note section?
 
+    * Split key support (n-out-of-m).  Use our own protocol or figure out
+      how PGP does it.
 
-  * abstraction of the MPI
+    * 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?)
+      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.
 
-  * Add a way to override the current cipher/md implementations
-    by others (using extensions)
+    * write a tool to extract selected keys from a file.
 
-  * add a fast-import command which does not do the signature checks
-    of other keys (processing of the sdir hintlist).  The signatures
-    may then be verified by a maintainence pass.
+    * Change the buffering to a mbuf like scheme?  See Michael's proposal.
 
-  * Not GnupG replated:  What about option completion in bash?
-    Can "--dump-options" be used for this or should we place the
-    options in a special ELF segment?
+    * 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.