See ChangeLog: Mon Sep 13 10:55:14 CEST 1999 Werner Koch

BUGS

@@ -47,6 +47,7 @@ and after about half a day in the rsync snapshots.
 [  *] #23 1999-09-03 <todd.brooks@yale.edu> 0.9.11
     Only the first signature of a cleartext sig seems to be verified.
     Can't fix it in 1.0 because the code is semi-frozen.
+    HMMM: Can't reprodude the bug here - it just works.  Check wehther
 
 [  *] #24 1999-09-05 <marcus@yoyo.cc.monash.edu.au> 0.9.11
     Does not link libc and libz expect when removing all "-lc -lz" except

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
@@ -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
@@ -221,12 +241,17 @@ 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:

VERSION

@@ -1 +1 @@
-1.0.0
+1.0.0a

cipher/ChangeLog

@@ -1,3 +1,9 @@
+Mon Sep 13 10:51:29 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
+
+
+	* bithelp.h: New.
+	* rmd160.h, sha1.h, md5.h: Use the rol macro from bithelp.h
+
 Tue Sep  7 16:23:36 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
 
 

cipher/Makefile.am

@@ -39,6 +39,7 @@ libcipher_la_SOURCES = cipher.c  \
 		 md.c		\
 		 dynload.c	\
 		 dynload.h	\
+		 bithelp.h	\
 		 des.c		\
 		 des.h		\
 		 twofish.c	\

cipher/bithelp.h

@@ -0,0 +1,41 @@
+/* bithelp.h  -  Some bit manipulation helpers
+ *	Copyright (C) 1999 Free Software Foundation, Inc.
+ *
+ * This file is part of GnuPG.
+ *
+ * GnuPG is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * GnuPG is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ */
+#ifndef G10_BITHELP_H
+#define G10_BITHELP_H
+
+
+/****************
+ * Rotate a 32 bit integer by n bytes
+ */
+#if defined(__GNUC__) && defined(__i386__)
+static inline u32
+rol( u32 x, int n)
+{
+	__asm__("roll %%cl,%0"
+		:"=r" (x)
+		:"0" (x),"c" (n));
+	return x;
+}
+#else
+  #define rol(x,n) ( ((x) << (n)) | ((x) >> (32-(n))) )
+#endif
+
+
+#endif /*G10_BITHELP_H*/

cipher/md5.c

@@ -37,6 +37,8 @@
 #include "memory.h"
 #include "dynload.h"
 
+#include "bithelp.h"
+
 
 typedef struct {
     u32 A,B,C,D;	  /* chaining variables */
@@ -104,15 +106,11 @@ transform( MD5_CONTEXT *ctx, byte *data )
   do								    \
     {								    \
       a += FF (b, c, d) + (*cwp++) + T; 	    \
-      CYCLIC (a, s);						    \
+      a = rol(a, s);						    \
       a += b;							    \
     }								    \
   while (0)
 
-  /* It is unfortunate that C does not provide an operator for
-     cyclic rotation.  Hope the C compiler is smart enough.  */
-#define CYCLIC(w, s) (w = (w << s) | (w >> (32 - s)))
-
     /* Before we start, one word about the strange constants.
        They are defined in RFC 1321 as
 
@@ -142,7 +140,7 @@ transform( MD5_CONTEXT *ctx, byte *data )
     do								      \
       { 							      \
 	a += f (b, c, d) + correct_words[k] + T;		      \
-	CYCLIC (a, s);						      \
+	a = rol(a, s);						      \
 	a += b; 						      \
       } 							      \
     while (0)

cipher/rmd160.c

@@ -29,6 +29,8 @@
 #include "cipher.h" /* only used for the rmd160_hash_buffer() prototype */
 #include "dynload.h"
 
+#include "bithelp.h"
+
 /*********************************
  * RIPEMD-160 is not patented, see (as of 25.10.97)
  *   http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
@@ -153,19 +155,6 @@ rmd160_init( RMD160_CONTEXT *hd )
 }
 
 
-#if defined(__GNUC__) && defined(__i386__)
-static inline u32
-rol(int n, u32 x)
-{
-	__asm__("roll %%cl,%0"
-		:"=r" (x)
-		:"0" (x),"c" (n));
-	return x;
-}
-#else
-  #define rol(n,x) ( ((x) << (n)) | ((x) >> (32-(n))) )
-#endif
-
 
 /****************
  * Transform the message X which consists of 16 32-bit-words
@@ -218,8 +207,8 @@ transform( RMD160_CONTEXT *hd, byte *data )
 #define F3(x,y,z)   ( ((x) & (z)) | ((y) & ~(z)) )
 #define F4(x,y,z)   ( (x) ^ ((y) | ~(z)) )
 #define R(a,b,c,d,e,f,k,r,s) do { t = a + f(b,c,d) + k + x[r]; \
-				  a = rol(s,t) + e;	       \
+				  a = rol(t,s) + e;	       \
-				  c = rol(10,c);	       \
+				  c = rol(c,10);	       \
 				} while(0)
 
     /* left lane */

cipher/sha1.c

@@ -39,6 +39,7 @@
 #include "util.h"
 #include "memory.h"
 #include "dynload.h"
+#include "bithelp.h"
 
 
 typedef struct {
@@ -49,20 +50,6 @@ typedef struct {
 } SHA1_CONTEXT;
 
 
-#if defined(__GNUC__) && defined(__i386__)
-static inline u32
-rol(int n, u32 x)
-{
-	__asm__("roll %%cl,%0"
-		:"=r" (x)
-		:"0" (x),"c" (n));
-	return x;
-}
-#else
-  #define rol(n,x)  ( ((x) << (n)) | ((x) >> (32-(n))) )
-#endif
-
-
 
 
 void
@@ -123,11 +110,11 @@ transform( SHA1_CONTEXT *hd, byte *data )
 		    ^ x[(i-8)&0x0f] ^ x[(i-3)&0x0f] \
 	       , (x[i&0x0f] = (tm << 1) | (tm >> 31)) )
 
-#define R(a,b,c,d,e,f,k,m)  do { e += rol( 5, a )     \
+#define R(a,b,c,d,e,f,k,m)  do { e += rol( a, 5 )     \
 				      + f( b, c, d )  \
 				      + k	      \
 				      + m;	      \
-				 b = rol( 30, b );    \
+				 b = rol( b, 30 );    \
 			       } while(0)
     R( a, b, c, d, e, F1, K1, x[ 0] );
     R( e, a, b, c, d, F1, K1, x[ 1] );

doc/FAQ

@@ -232,7 +232,7 @@
   abbreviated -o) is an option that takes a filename. The option's argument
   must follow immediately after the option itself, otherwise gpg doesn't know
   which option the argument is supposed to go with. As an option, --output and
-  its filename must come before the command. The --remote-user (-r) option takes
+  its filename must come before the command. The --recipient (-r) option takes
   a name or keyid to encrypt the message to, which must come right after the -r
   argument.  The --encrypt (or -e) command comes after all the options followed
   by the file you wish to encrypt. So use
@@ -241,22 +241,22 @@
 
   If you write the options out in full, it is easier to read
 
-   gpg --remote-user alice --output secret.txt --encrypt test.txt
+   gpg --recipient alice --output secret.txt --encrypt test.txt
 
   If you're saving it in a file called ".txt" then you'd probably expect to see
   ASCII-armored text in there, so you need to add the --armor (-a) option,
   which doesn't take any arguments.
 
-   gpg --armor --remote-user alice --output secret.txt --encrypt test.txt
+   gpg --armor --recipient alice --output secret.txt --encrypt test.txt
 
   If you imagine square brackets around the optional parts, it becomes a bit
   clearer:
 
-   gpg [--armor] [--remote-user alice] [--output secret.txt] --encrypt test.txt
+   gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt
 
   The optional parts can be rearranged any way you want.
 
-   gpg --output secret.txt --remote-user alice --armor --encrypt test.txt
+   gpg --output secret.txt --recipient alice --armor --encrypt test.txt
 
   If your filename begins with a hyphen (e.g. "-a.txt"), gnupg assumes this is
   an option and may complain.  To avoid this you have either to use
@@ -282,8 +282,7 @@
      other keys.  "validity", or calculated trust, is a value which
      says how much GnuPG thinks a key is valid (that it really belongs
      to the one who claims to be the owner of the key).
-     For more see the chapter "The Web of Trust" in the
+     For more see the chapter "The Web of Trust" in the Manual
-     Manual [gpg: Oops: Internal error: manual not found - sorry]
 
   Q: How do I interpret some of the informational outputs?
   A: While checking the validity of a key, GnuPG sometimes prints
@@ -340,5 +339,6 @@
   A: There is a script in the tools directory to help you:
      After you have imported the PGP keyring you can give this command:
 	$ lspgpot pgpkeyring | gpg --import-ownertrust
-
+     where pgpkeyring is the original keyring and not the GnuPG one you
+     might have created in the first step.
 

doc/OpenPGP

@@ -1,7 +1,7 @@
 		    GnuPG and OpenPGP
 		    =================
 
-   See RFC2440 for a description of OpenPGP.  I have an annotated version
+   See RFC2440 for a description of OpenPGP.  We have an annotated version
    of this RFC online:	http://www.gnupg.org/rfc2440.html
 
 

g10/ChangeLog

@@ -1,3 +1,10 @@
+Mon Sep 13 10:51:29 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
+
+
+	* signal.c (got_fatal_signal): Print message using write(2) and
+	only for development versions.
+
+
 Mon Sep  6 19:59:08 CEST 1999  Werner Koch  <wk@isil.d.shuttle.de>
 
 	* tdbio.c (tdbio_set_dbname): Use mkdir macro

g10/signal.c

@@ -1,5 +1,5 @@
 /* signal.c - signal handling
- *	Copyright (C) 1998 Free Software Foundation, Inc.
+ *	Copyright (C) 1998, 1999 Free Software Foundation, Inc.
  *
  * This file is part of GnuPG.
  *
@@ -39,28 +39,34 @@ static volatile int caught_fatal_sig = 0;
 static volatile int caught_sigusr1 = 0;
 
 static const char *
-signal_name( int signum )
+get_signal_name( int signum )
 {
   #if defined(SYS_SIGLIST_DECLARED) && defined(NSIG)
     return (signum >= 0 && signum < NSIG) ? sys_siglist[signum] : "?";
   #else
-    static char buf[20];
+    return "some signal";
-    sprintf(buf, "signal %d", signum );
-    return buf;
   #endif
 }
 
+
 static RETSIGTYPE
 got_fatal_signal( int sig )
 {
+    const char *s;
+
     if( caught_fatal_sig )
 	raise( sig );
     caught_fatal_sig = 1;
 
-    fprintf( stderr, "\n%s: %s caught ... exiting\n",
-	      log_get_name(), signal_name(sig) );
     secmem_term();
-    exit( 8 );
+  #ifdef IS_DEVELOPMENT_VERSION
+    write(2, "\n", 1 );
+    s = log_get_name(); if( s ) write(2, s, strlen(s) );
+    write(2, ": ", 2 );
+    s = get_signal_name(sig); write(2, s, strlen(s) );
+    write(2, " caught ... exiting\n", 21 );
+  #endif
+    exit(8); /* Hmmm, for some reasons rais2e does not work */
 }
 
 

util/secmem.c

@@ -370,6 +370,16 @@ m_is_secure( const void *p )
     return p >= pool && p < (void*)((char*)pool+poolsize);
 }
 
+
+
+/****************
+ * Warning:  This code might be called by an interrupt handler
+ *	     and frankly, thre should really be such a handler,
+ *	     to make sure that the memory is wiped out.
+ *	     We hope that the OS wipes out mlocked memory after
+ *	     receiving a SIGKILL - it really should do so, otherwise
+ *	     there is no chance to get the secure memory cleaned.
+ */
 void
 secmem_term()
 {