* options.h, keyserver.c (parse_keyserver_options): Remove
[gnupg.git] / THOUGHTS
index 247264c..25707c4 100644 (file)
--- a/THOUGHTS
+++ b/THOUGHTS
@@ -1,5 +1,12 @@
+How often have we to do a key lookup by mailaddress?.
+can this be accomplished by an external program?
 
 
+
+What about using S-Exp to describe the interface to the ciphers instead
+of simply iterating over them. This way we can easy register a name which
+can be used as the "hintstr" for --load-extension.
+
 EGD
 ====
 Oh, and on embedding egd into the gpg package: I think if you just unpack it
@@ -23,7 +30,7 @@ conditional.
       more secure than swapping out to the swap disk?  I don't
       believe so because if an attacker has access to the physical
       box (and he needs this to look at the swap area) he can also
-      leave a trojan horse which is far more easier than to analyze
+      leave a Trojan horse which is far more easier than to analyze
       memory dumps.  Question: Is it possible that a Unix pages
       an old (left over by some other process) swap page in for
       another process - this should be considered a serious design
@@ -48,8 +55,8 @@ From: Matthew Skala <mskala@ansuz.sooke.bc.ca>
 
 
 
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA1
+==============================
+[ "-->" indicates a comment by me (wk) ]
 
 Hi Werner..
 
@@ -83,11 +90,16 @@ extension mechanisms in GPG should be enough to try various ways later on.
 
 1) pass an argument string to loadable extension modules (maybe
     gpg --load-extension foofish=arg1,arg2,arg3 ?)
+    --> could also be achived by S-Exps
+
 2) allow multiple instances of the same extension module (presumably with
    different arguments)
+   --> set an alias name when loading them
 3) allow extension modules to use stdin/stdout/stderr as normal (probably
    already in there), for giving feedback to the user, or possibly asking them
    for a password of some sort
+   --> there should really be some kind of callback mechanism.
+
 4) have an extension to provide secret keys:
 
    It looks like most of the hooks for this are already in place, it just
@@ -97,6 +109,9 @@ extension mechanisms in GPG should be enough to try various ways later on.
    an argument. When the keyblock resource is asked to enumerate its keys, it
    runs the external program (first with a "0" argument, then a "1", and so on
    until the program reports that no more keys are available). The external
+--> better use a cookie:  This way we are also stateless but have a more
+   general interface.
+
    program returns one (possibly armored) secret key block each time. The
    program might have some kind of special protocol to talk to the storage
    device.  One thing that comes to mind is to simply include a random number
@@ -108,6 +123,8 @@ extension mechanisms in GPG should be enough to try various ways later on.
    much processing power and IO is available on the device. But the same
    extension module should be able to handle as complex a scheme as one could
    wish.
+   --> authenticate the session on startup, using DH and the mentioned
+       cookie/screen/keyboard authentication.
 
    The current keyblock-resource interface would work fine, although it
    might be more convenient if a resource could be asked for a key by id
@@ -118,10 +135,13 @@ extension mechanisms in GPG should be enough to try various ways later on.
    to fetch by id (which would require it to fall back to the other keyblock
    resources if it failed), the user's device might be asked to release the
    key even though some other secret key was the one needed.
+   --> Right.
 
 
 5) have an extension to perform a secret-key operation without the actual
    secret key material
+   --> Define a clear interface to do this and in the first step write
+       a daemon which does exactly this.
 
  basically something to indicate that any decrypt or sign operations that
  occur for a specific keyid should call the extension module instead. The
@@ -184,9 +204,9 @@ o  the KS should verify signatures and only accept those
 o  Keep a blacklist of known bad signatures to minimize
    the time needed to check them
 
-o  Should be fast - I currently designing a new storage
+o  Should be fast - I'm currently designing a new storage
    system called keybox which takes advantage of the fact
-   that the keyID is highly random and can be directly be
+   that the keyID is highly random and can directly be
    used as a hash value and this keyID is (for v4 keys)
    part of the fingerprint: So it is possible to use the
    fingerprint as key but do an lookup by the keyID.
@@ -216,9 +236,40 @@ of the existing key servers (I think they bail out on some rfc2440
 packet formats).
 
 
+DJGPP
+=====
+Don't use symlinks but try to do the preprocessing in the config-links script.
+DJPGG has problems to distinguish betwen .s and .S becaus the FAT filesystem
+is not case sensitive (Mark Elbrecht).
+Well, it runs only on one architecture and therefor it might be possible
+to add a special case for it, completely bypassing the symlink autselection
+trick.
+
+Special procmail addresses
+==========================
+  * foo+bar@example.net:  Try to match the address without the "+bar".
+    Should be done by the MUA, but maybe we can do this.
+    --> Yep.  Another reason to utilize a directory service or something
+       else for keylookup.
+
+
+
 Suggested things which I will not do:
 =====================================
   * Let take --help an option to select some topics.
     Using grep is much easier
+  * 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.
+    --> Use a script and --status-fd
+
+
+ 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.