keep on walking towards rc3

configure.ac

@@ -9,7 +9,7 @@ dnl it under the terms of the GNU General Public License as published by
 dnl the Free Software Foundation; either version 2 of the License, or
 dnl (at your option) any later version.
 dnl 
-dnl GnuPG is distributed in the hope that it will be useful,
+dnl GnuPG is distributed in the hope that it will be useful,g
 dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
 dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 dnl GNU General Public License for more details.
@@ -26,7 +26,7 @@ min_automake_version="1.9.3"
 
 # Remember to change the version number immediately *after* a release
 # and remove the "-cvs" or "rc" suffix immediately *before* a release.
-AC_INIT(gnupg, 1.4.3rc2, bug-gnupg@gnu.org)
+AC_INIT(gnupg, 1.4.3-cvs, bug-gnupg@gnu.org)
 # Set development_version to yes if the minor number is odd or you
 # feel that the default check for a development version is not
 # sufficient.

doc/detached-sig-verification-bug.txt

@@ -0,0 +1,231 @@
+           False positive signature verification in GnuPG
+           ==============================================
+                       (released 2006-02-15)
+
+
+Summary
+=======
+
+The Gentoo project identified a security related bug in GnuPG.  When
+using any current version of GnuPG for unattended signature
+verification (e.g. by scripts and mail programs), false positive
+signature verification of detached signatures may occur.
+
+This problem affects the tool *gpgv*, as well as using "gpg --verify"
+to imitate gpgv, if only the exit code of the process is used to
+decide whether a detached signature is valid.  This is a plausible
+mode of operation for gpgv.
+
+If, as suggested, the --status-fd generated output is used to decide
+whether a signature is valid, no problem exists.  In particular
+applications making use of the GPGME library[2] are not affected.
+
+To solve this problem an update of the current stable version has been
+released (see below).
+
+Please do not send private mail in response to this message.  The
+mailing list gnupg-devel is the best place to discuss this problem
+(please subscribe first so you don't need moderator approval [1]).
+
+
+Impact:
+=======
+
+Signature verification of detached signatures does not work, thus
+modified versions of signature protected files may not be detected.
+
+All versions of gnupg prior to 1.4.2.1 are affected if they are used
+in certain unattended operation modes.
+
+There is no problem using GnuPG in an interactive way because GnuPG
+won't print any signature status at all; i.e. no "Good signature".
+
+Scripts and applications using gpg or gpgv with the --status-fd option
+and properly parsing this output are not affected.
+
+Applications using the GPGME library[2] are not affected.
+
+The GnuPG versions 1.9 are not affected unless the currently
+deprecated gpg part has been enabled.
+
+
+Solution:
+=========
+
+Update GnuPG as soon as possible to version 1.4.2.1.  There are no
+fixes for older versions available, although the fix described below
+may be adjusted for them.
+
+To update please follow the instructions found at
+http://www.gnupg.org/download/ or read on:
+
+GnuPG 1.4.2.1 may be downloaded from one of the GnuPG mirror sites or
+direct from ftp://ftp.gnupg.org/gcrypt/ .  The list of mirrors can be
+found at http://www.gnupg.org/mirrors.html .  Note, that GnuPG is not
+available at ftp.gnu.org.
+
+On the mirrors you should find the following files in the *gnupg*
+directory:
+
+  gnupg-1.4.2.1.tar.bz2 (2.8M)
+  gnupg-1.4.2.1.tar.bz2.sig
+
+      GnuPG source compressed using BZIP2 and OpenPGP signature.
+
+  gnupg-1.4.2.1.tar.gz (4.0M)
+  gnupg-1.4.2.1.tar.gz.sig
+
+      GnuPG source compressed using GZIP and OpenPGP signature.
+
+  gnupg-1.4.2-1.4.2.1.diff.bz2 (39k)
+
+      A patch file to upgrade a 1.4.2 GnuPG source. 
+
+Select one of them. To shorten the download time, you probably want to
+get the BZIP2 compressed file.  Please try another mirror if
+exceptional your mirror is not yet up to date.
+
+In the *binary* directory, you should find these files:
+
+  gnupg-w32cli-1.4.2.1.exe (1.4M)
+  gnupg-w32cli-1.4.2.1.exe.sig
+
+      GnuPG compiled for Microsoft Windows and OpenPGP signature.
+      Note that this is a command line version and now comes with a
+      graphical installer tool.  The source files are the same as
+      given above.  Note, that a new version of the Gpg4Win
+      package[4], including an updated version of GnuPG will be
+      available later the day.
+
+
+In order to check that the version of GnuPG which you are going to
+install is an original and unmodified one, you can do it in one of
+the following ways:
+
+ * If you already have a trusted version of GnuPG installed, you
+   can simply check the supplied signature.  For example to check the
+   signature of the file gnupg-1.4.2.1.tar.bz2 you would use this command:
+
+     gpg --verify gnupg-1.4.2.1.tar.bz2.sig
+
+   This checks whether the signature file matches the source file.
+   You should see a message indicating that the signature is good and
+   made by that signing key.  Make sure that you have the right key,
+   either by checking the fingerprint of that key with other sources
+   or by checking that the key has been signed by a trustworthy other
+   key.  Note, that you can retrieve the signing key using "finger wk
+   'at' g10code.com" or "finger dd9jn 'at' gnu.org" or using the
+   keyservers.  From time to time I prolong the expiration date; thus
+   you might need a fresh copy of that key.
+
+   Never use a GnuPG version you just downloaded to check the
+   integrity of the source - use an existing GnuPG installation!
+   Watch out for a "Good signature" messages.
+
+ * If you are not able to use an old version of GnuPG, you have to
+   verify the SHA-1 checksum.  Assuming you downloaded the file
+   gnupg-1.4.2.1.tar.bz2, you would run the sha1sum command like this:
+
+     sha1sum gnupg-1.4.2.1.tar.bz2
+
+   and check that the output matches the first line from the
+   following list:
+
+1c0306ade25154743d6f6f9ac05bee74c55c6eda  gnupg-1.4.2.1.tar.bz2
+cefc74560f21bde74eed298d86460612cd7e12ee  gnupg-1.4.2.1.tar.gz
+98d597b1a9871b4aadc820d8641b36ce09125612  gnupg-1.4.2-1.4.2.1.diff.bz2
+a4db35a72d72df8e76751adc6f013b4c96112fd4  gnupg-w32cli-1.4.2.1.exe
+
+
+Background:
+===========
+
+If a file with arbitrary data, for example 64 times the character
+0xCA, is used as the detached signature, any data file will lead to
+gpg exiting with 0 (success).  There won't be any messages indicating
+that the signature is valid or false:
+
+  $ fortune >x.txt
+  $ perl -e 'print "\xca"x"64"' >x.txt.sig
+  $ gpgv x.txt.sig x.txt
+  $ echo $?
+  0
+
+Cleary this should not return success.
+
+The same problem appears when using "gpg --verify" in place of gpgv.
+However in this case any application should to do further checks to
+make sure that the key verifying the signature is actually the desired
+one, thus using "gpg --verify" without processing the --status-fd
+generated output is in general the wrong approach.
+
+The fixed version makes sure that gpgv and "gpg --verify" won't return
+success if no signature has been seen.  A minimal but sufficient fix
+against 1.4.2 and possible older versions is:
+
+====8<============
+--- g10/mainproc.c	(revision 4001)
++++ g10/mainproc.c	(working copy)
+@@ -77,6 +77,7 @@
+         int op;
+         int stop_now;
+     } pipemode;
++    int any_sig_seen;  /* Set to true if a signature packet has been seen. */
+ };
+ 
+ 
+@@ -217,6 +218,7 @@
+ {
+     KBNODE node;
+ 
++    c->any_sig_seen = 1;
+     if( pkt->pkttype == PKT_SIGNATURE && !c->list ) {
+ 	/* This is the first signature for the following datafile.
+ 	 * GPG does not write such packets; instead it always uses
+@@ -1137,6 +1139,18 @@
+     c->signed_data = signedfiles;
+     c->sigfilename = sigfilename;
+     rc = do_proc_packets( c, a );
++ 
++    /* If we have not encountered any signature we print an error
++       messages, send a NODATA status back and return an error code.
++       Using log_error is required because verify_files does not check
++       error codes for each file but we want to terminate the process
++       with an error. */ 
++    if (!rc && !c->any_sig_seen)
++      {
++ 	 write_status_text (STATUS_NODATA, "4");
++        log_error (_("no signature found\n"));
++        rc = -1;
++      }
+     m_free( c );
+     return rc;
+ }
+====>8============
+
+Note that the released version also includes a test case for this bug
+and prints an additional diagnostic.  With the patch above the output
+using the same test data as above should be:
+
+  $ gpgv x.txt.sig x.txt
+  gpgv: no signature found
+  gpgv: verify signatures failed: eof
+  $ echo $?
+  2
+
+
+
+Thanks
+======
+
+taviso from the Gentoo project found this vulnerability and informed
+me on Monday evening.  Unfortunately I had already switched off my
+monitor at that time.  The update has been released yesterday evening
+(CET).
+
+
+
+
+[1] http://lists.gnupg.org/mailman/listinfo/gnupg-devel
+[2] http://www.gnupg.org/related_software/gpgme
+[3] http://www.gpg4win.org

doc/embedded-sig-verification-bug.txt

@@ -0,0 +1,211 @@
+           GnuPG does not detect injection of unsigned data
+           ================================================
+                 (released 2006-03-09, CVE-2006-0049)
+
+
+Summary
+=======
+
+In the aftermath of the false positive signature verfication bug
+(announced 2006-02-15) more thorough testing of the fix has been done
+and another vulnerability has been detected.
+
+This new problem affects the use of *gpg* for verification of
+signatures which are _not_ detached signatures.  The problem also
+affects verification of signatures embedded in encrypted messages;
+i.e. standard use of gpg for mails.
+
+To solve this problem, an update of the current stable version has
+been released (see below).
+
+Please do not respond to this message.  The mailing list gnupg-devel
+is the best place to discuss this problem (please subscribe first so
+you don't need moderator approval [1]).
+
+
+Impact:
+=======
+
+Signature verification of non-detached signatures may give a positive
+result but when extracting the signed data, this data may be prepended
+or appended with extra data not covered by the signature.  Thus it is
+possible for an attacker to take any signed message and inject extra
+arbitrary data.
+
+Detached signatures (a separate signature file) are not affected.
+
+All versions of gnupg prior to 1.4.2.2 are affected.
+
+Scripts and applications using gpg to verify the integrity of data are
+affected. This includes applications using the GPGME library[2].
+
+The GnuPG version 1.9.x is not affected unless the currently
+deprecated gpg part has been enabled.
+
+
+Solution:
+=========
+
+Update GnuPG as soon as possible to version 1.4.2.2.  There are no
+fixes for older versions available.
+
+If you can't get an update from your vendor, please follow the
+instructions found at http://www.gnupg.org/download/ or read on:
+
+GnuPG 1.4.2.2 may be downloaded from one of the GnuPG mirror sites or
+direct from ftp://ftp.gnupg.org/gcrypt/ .  The list of mirrors can be
+found at http://www.gnupg.org/mirrors.html .  Note, that GnuPG is not
+available at ftp.gnu.org.
+
+On the mirrors you should find the following files in the *gnupg*
+directory:
+
+  gnupg-1.4.2.2.tar.bz2 (2.8M)
+  gnupg-1.4.2.2.tar.bz2.sig
+
+      GnuPG source compressed using BZIP2 and OpenPGP signature.
+
+  gnupg-1.4.2.2.tar.gz (4.0M)
+  gnupg-1.4.2.2.tar.gz.sig
+
+      GnuPG source compressed using GZIP and OpenPGP signature.
+
+  gnupg-1.4.2.1-1.4.2.2.diff.bz2 (101k)
+
+      A patch file to upgrade a 1.4.2.1 GnuPG source. 
+
+Select one of them. To shorten the download time, you probably want to
+get the BZIP2 compressed file.  Please try another mirror if
+exceptional your mirror is not yet up to date.
+
+In the *binary* directory, you should find these files:
+
+  gnupg-w32cli-1.4.2.2.exe (1.4M)
+  gnupg-w32cli-1.4.2.2.exe.sig
+
+      GnuPG compiled for Microsoft Windows and OpenPGP signature.
+      Note that this is a command line version and now comes with a
+      graphical installer tool.  The source files are the same as
+      given above.  Note, that a new version of the Gpg4Win
+      package[3], including a fixed version of GnuPG has also been
+      released today.
+
+
+In order to check that the version of GnuPG which you are going to
+install is an original and unmodified one, you can do it in one of
+the following ways:
+
+ * If you already have a trusted version of GnuPG installed, you can
+   simply check the supplied signature.  Due to the fact that detached
+   signatures are used, the problem described here does not affect
+   this verification.  For example to check the signature of the file
+   gnupg-1.4.2.2.tar.bz2 you would use this command:
+
+     gpg --verify gnupg-1.4.2.2.tar.bz2.sig
+
+   This checks whether the signature file matches the source file.
+   You should see a message indicating that the signature is good and
+   made by that signing key.  Make sure that you have the right key,
+   either by checking the fingerprint of that key with other sources
+   or by checking that the key has been signed by a trustworthy other
+   key.  Note, that you can retrieve the signing key using "finger wk
+   'at' g10code.com" or "finger dd9jn 'at' gnu.org" or using the
+   keyservers.  From time to time I prolong the expiration date; thus
+   you might need a fresh copy of that key.
+
+   Never use a GnuPG version you just downloaded to check the
+   integrity of the source - use an existing GnuPG installation!
+   Watch out for a "Good signature" messages.
+
+ * If you are not able to use an old version of GnuPG, you have to
+   verify the SHA-1 checksum.  Assuming you downloaded the file
+   gnupg-1.4.2.1.tar.bz2, you would run the sha1sum command like this:
+
+     sha1sum gnupg-1.4.2.2.tar.bz2
+
+   and check that the output matches the first line from the
+   following list:
+
+f5559ddb004e0638f6bd9efe2bac00134c5065ba  gnupg-1.4.2.2.tar.bz2
+959540c1c6158e09d668ceee055bf366dc26d0bd  gnupg-1.4.2.2.tar.gz
+880b3e937f232b1ca366bda37c4a959aacbd84f3  gnupg-1.4.2.1-1.4.2.2.diff.bz2
+95dd7fd4c49423b86704acfc396ce5a53c8b19e7  gnupg-w32cli-1.4.2.2.exe
+
+
+
+Background:
+===========
+
+OpenPGP messages are made up of packets.  The signed data is a packet,
+the actual signature is a packet and there are several control packets
+as well.  For example:
+
+   O + D + S 
+
+This describes a standard signed message made made up of a control
+packet (O for one-pass signature packet), the actual signed data (D)
+and the actual signature packet (S).  gpg checks that the signature S
+is valid over the data D.  This is actually easy if not OpenPGP and
+GnuPG would have a long tradition of changing the fromats.  PGP 2
+versions used a different way of composing these packets:
+
+   S + D
+
+and early versions of gpg, released before RFC2440, even created
+
+   D + S
+
+i.e. without the one-pass packet.  Still this would all be easy to
+process properly but in an ill-advised attempt to make things easier,
+gpg allowed the processing of multiple signatures per file, like
+
+   O1 + D1 + S1 + O2 + D2 + S2
+
+where two standard signatures are concatenated.  Now when combining
+this with the other variants of signatures, things get really messy
+and it is not always possible to assocciate the signature (S) with the
+signed data (D).  gpg checked that this all works but unfortunately
+these checks are not sufficient enough.  The attack is to change a
+standard message to inject faked data (F).  A simple case is this:
+
+   F + O + D + S 
+
+gpg now happily skips F for verification and does a proper signature
+verification of D and if this succeeds, prints a positive result.
+However when asked to output the actual signed data it will output the
+concatenation of F + D and thus create the impression that both are
+covered by the signature.  Depending on how gpg is invoked (in a
+pipeline or using --output) it may even output just F and not at all
+D.  There are several variants of the attack in where to put the faked
+data.
+
+The only correct solution to this problem is to get rid of the feature
+to check concatenated signatures - this allows for strict checking of
+valid packet composition.  This is what has been done in 1.4.2.2 and
+in the forthcoming 1.4.3rc2.  These versions accept signatures only if
+they are composed of
+
+  O + D + S
+  S + D
+  
+Cleartext signatures are of course also supported, they are similiar
+to the O+D+S case.
+
+The actual checking for valid signature packet composition is done at
+g10/mainproc.c, at the top of check_sig_and_print().
+
+
+Thanks
+======
+
+Tavis Ormandy again poked on gpg and found this vulnerability. 
+
+The new version has been released yesterday and should by now be
+available on all mirrors.
+
+
+
+
+[1] http://lists.gnupg.org/mailman/listinfo/gnupg-devel
+[2] http://www.gnupg.org/related_software/gpgme
+[3] http://www.gpg4win.org