remove old patches

3 files changed, 0 insertions, 385 deletions

diff --git a/app-crypt/gnupg/Manifest b/app-crypt/gnupg/Manifest
index 5ecfea37c631..a54f236283d6 100644
--- a/app-crypt/gnupg/Manifest
+++ b/app-crypt/gnupg/Manifest
@@ -6,7 +6,5 @@ MD5 bf8f03fb22b2f44fd5f6a4395ab001dd metadata.xml 483
 MD5 7f0e728ae9c6810cb9c61500fdc39fc9 files/digest-gnupg-1.2.4 117
 MD5 c3a43a1e5da266ef33222f721e05fd63 files/digest-gnupg-1.2.6 117
 MD5 8c88d9fdef69bdda173170c5a8abd59e files/digest-gnupg-1.9.10 65
-MD5 db3c4c4fe234f87d269216f6e0be8817 files/gnupg-1.2.3-hkp-format-string.diff 922
 MD5 c6114a5a40f10aeca63d07b59fed650f files/gnupg-1.2.4-hppa_unaligned_constant.patch 1213
-MD5 b12193638991111d4dc2c9864fa8e15a files/gnupg-1.2.3-disable-elgamal.diff 12554
 MD5 cdb57d67164c7a63a167c33426c0a7a3 files/gnupg-1.2.4.ppc64.patch 471
diff --git a/app-crypt/gnupg/files/gnupg-1.2.3-disable-elgamal.diff b/app-crypt/gnupg/files/gnupg-1.2.3-disable-elgamal.diff
deleted file mode 100644
index d0053bea601c..000000000000
--- a/app-crypt/gnupg/files/gnupg-1.2.3-disable-elgamal.diff
+++ /dev/null
@@ -1,353 +0,0 @@
-From: wk@gnupg.org (Werner Koch)
-Newsgroups: mailing.unix.bugtraq
-Subject: GnuPG's ElGamal signing keys compromised
-Date: Thu, 27 Nov 2003 18:31:32 +0000 (UTC)
-Organization: NCTU CSIE FreeBSD Server
-Lines: 338
-Sender: nobody@FreeBSD.csie.NCTU.edu.tw
-Message-ID: <bq5fu4$65h$1@FreeBSD.csie.NCTU.edu.tw>
-NNTP-Posting-Host: freebsd.csie.nctu.edu.tw
-X-Trace: FreeBSD.csie.NCTU.edu.tw 1069957892 6322 140.113.17.209 (27 Nov 2003 18:31:32 GMT)
-X-Complaints-To: usenet@FreeBSD.csie.NCTU.edu.tw
-NNTP-Posting-Date: Thu, 27 Nov 2003 18:31:32 +0000 (UTC)
-
-
-
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA1
-
-            GnuPG's ElGamal signing keys compromised
-           ==========================================
-
-Summary
-=======
-
-Phong Nguyen identified a severe bug in the way GnuPG creates and uses
-ElGamal keys for signing.  This is a significant security failure
-which can lead to a compromise of almost all ElGamal keys used for
-signing.  Note that this is a real world vulnerability which will
-reveal your private key within a few seconds.
-
-Please *take immediate action and revoke your ElGamal signing keys*.
-Furthermore you should take whatever measures necessary to limit the
-damage done for signed or encrypted documents using that key.
-
-Please do not send private mail in response to this message as I won't
-have the time to catch up with all the messages.  The mailing list
-gnupg-users@gnupg.org is the best place to discuss this problem
-(please subscribe first so you don't need moderator approval [2]).
-
-Note that the standard keys as generated by GnuPG (DSA and ElGamal
-encryption) as well as RSA keys are NOT vulnerable.  Note also that
-ElGamal signing keys cannot be generated without the use of a special
-flag to enable hidden options and even then overriding a warning
-message about this key type.  See below for details on how to identify
-vulnerable keys.
-
-This message is signed using the usual GnuPG distribution key[1].  I
-apologize for this severe bug and all the problems resulting from it.
-
-
-Background:
-===========
-
-For historic reasons [3], GnuPG permits creating ElGamal keys which
-are usable for both encryption and signing.  It is even possible to
-have one key (the primary one) used for both operations.  This is not
-considered good cryptographic practice, but is permitted by the
-OpenPGP standard.
-
-It was not anticipated that these keys would still be used for signing
-because they have several disadvantages: The signature is much larger
-than a RSA or DSA signature, verification and creation takes far
-longer and the use of ElGamal for signing has always been problematic
-due to a couple of cryptographic weaknesses when not done properly.
-Thus I have always dissuaded people from using ElGamal keys for
-signing; however they are still used and about 200 keys per year are
-generated and uploaded to the keyservers.
-
-In January 2000, as part of version 1.0.2, the GnuPG code was changed
-to create ElGamal keys which work more efficiently for encryption
-(selecting a smaller x secret exponent and using a smaller k for
-encryption).  While making this change the problem with signing keys
-was accidentally introduced: the same small k for encryption was also
-used for signing.  This can be used for a cryptographic attack to
-reveal the private key (i.e. the secret exponent x) if a signature
-made using that key is available.  Such a signature is always
-available for primary ElGamal keys because signatures created with
-that key are used to bind the user ID and other material to the
-primary key (self-signatures).  Even if the key was never used for
-signing documents it should be considered compromised.
-
-Note that this weakness does not apply to the far more common
-encrypt-only (type 16) ElGamal key as GnuPG does not permit signatures
-to be issued by this key type.  Only the ElGamal sign+encrypt key
-(type 20) is affected and then only when used to make a signature with
-a GnuPG version 1.0.2 or later.
-
-
-Impact:
-=======
-
-All ElGamal sign+encrypt keys (type 20) generated with GnuPG 1.0.2 or
-later must be considered compromised.  Keys generated and used only
-with prior versions might still be safe but should ideally be revoked
-too.  Note that even if an ElGamal sign+encrypt key was generated
-before GnuPG 1.0.2, using that key in GnuPG 1.0.2 or later to issue
-signatures will still compromise the key.
-
-Again, ElGamal encrypt-only keys (type 16) from any version of GnuPG
-are *not* affected.
-
-
-Solution:
-=========
-
-Do not use *ElGamal sign+encrypt keys (type 20)*.  Revoke all those
-keys immediately.  Consider all material signed or encrypted with such
-a key as compromised.
-
-Forthcoming GnuPG versions will remove the ability to create such keys
-and the ability create ElGamal signatures.
-
-
-How to detect ElGamal type 20 keys:
-===================================
-
-We have to distinguish between two cases: The primary key is ElGamal
-sign+encrypt versus just a subkey is ElGamal sign+encrypt.
-
-The first case requires immediate attention, like this one:
-
-  $ gpg --list-keys xxxxxxxx
-  pub  2048G/xxxxxxxx 2001-xx-xx Mallory <mallory@example.net>
-
-such a key might be followed with additional "uid", "sig" or "sub"
-lines.  Here an ElGamal sign+encrypt key is used and very likely
-created with GnuPG >= 1.0.2.  The capital letter "G" indicates a
-ElGamal sign+encrypt key.  REVOKE such a key immediately.
-
-The second case is about subkeys. Here is an example:
-
-  $ gpg --list-keys 621CC013
-  pub  1024D/621CC013 1998-07-07 Werner Koch <wk@gnupg.org>
-  uid                            Werner Koch <werner.koch@guug.de>
-  uid                            Werner Koch <wk@g10code.com>
-  sub  1536g/ADF6A6E1 1999-02-20 [expires: 2002-11-01]
-  sub  1536G/B5A18FF4 1998-07-07 [expires: 2002-07-06]
-  sub  1536R/23D2A63D 2002-07-30 [expires: 2003-12-31]
-    
-This my usual working key, which is a standard GnuPG key with some
-additional subkeys added over time.  It is a good example because one
-subkey was created as type 20 signing and encrypt ElGamal key.  It is
-the second subkey:
-
-  sub  1536G/B5A18FF4 1998-07-07 [expires: 2002-07-06]
-
-The capital letter "G" denotes such an possible compromised subkey
-whereas the first subkey:
-
-  sub  1536g/ADF6A6E1 1999-02-20 [expires: 2002-11-01]
-
-is a standard encryption-only subkey as indicated by the small letter
-"g".  That key is not affected.
-
-The keys denoted with this capital letter "G" should be REVOKED unless
-you are definitely sure those subkeys were never used to create a
-signatures with GnuPG >= 1.0.2.
-
-
-How to revoke a key:
-====================
-
-To create a revocation certificate for the entire key (primary and
-all subkeys), you do:
-
- gpg --gen-revoke your_keyid >foo.rev
-
-If you have lost access to your passphrase, hopefully you have a
-pre-manufactured revocation certificate (either on a floppy or printed
-on a sheet of paper) which you may the use instead of the above
-command.
-
-This revocation certificate should then be imported into
-GnuPG using:
-
-  gpg --import <foo.rev
-
-now export your key to a file and distribute it to the keyservers.
-
-  gpg --export -a your_keyid >mykey.asc
-
-  gpg --keyserver subkeys.pgp.net --send-keys your_keyid
-
-
-If your primary key is not an ElGamal key, you might need to revoke a
-subkey.  Note again that only type 20 ElGamal keys (denoted by a
-capital letter "G") require revocation - the standard ElGamal
-encrypt-only key (small g) is perfectly fine.  Use gpg's edit command
-like this:
-
-  $ gpg --edit-key xyzxyzxy
-  
-The key listing will be shown. Select the subkey you want to revoke,
-using the command "key 2" (or whatever subkey it is) and then enter
-the command "revkey" and follow the prompts.  Continue then with an
-export as described above.
-
-
-How many keys are affected?
-===========================
-
-I can't tell for sure.  According to the keyserver statistics, there
-are 848 primary ElGamal signing keys which are affected.  These are a
-mere 0.04 percent of all primary keys on the keyservers.  There are
-324 vulnerable subkeys on the keyservers, too.  
-
-Some of the subkeys might have never been used for signing because for
-some time in the past GnuPG created the encryption subkey as type 20
-but didn't used it for signing because the DSA primary key was used
-instead.  It is better to revoke such keys nevertheless.
-
-Note again that the standard configuration of GnuPG does not allow
-creating the vulnerable sign+encrypt ElGamal keys and that neither DSA
-(type 17), RSA (type 1) nor ElGamal encrypt-only keys (type 16) are
-affected.
-
-
-Thanks
-======
-
-Phong Nguyen [4] analyzed the implementation of GnuPG's cryptographic
-parts and found this vulnerability.  He also developed actual code to
-mount the attack and was so kind to give me enough time to have a look
-at his paper and to gather a list of known type 20 keys owners.
-
-
-I am really sorry for this,
-
-   Werner
-
-
-[1] To get a fresh key you might want to consult the keyservers or get
-    it from using "finger wk@g10code.com" or "finger dd9jn@gnu.org".
-[2] See http://lists.gnupg.org/mailman/listinfo/gnupg-users .
-[3] The patent status of DSA was not clear when I started to write
-    GnuPG back in 1997.
-[4] Working at the French National Center for Scientific Research and
-    the Ecole normale superieure: http://www.di.ens.fr/~pnguyen/ .
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v1.2.3 (GNU/Linux)
-
-iD8DBQE/xavwaLeriVdUjc0RAquhAJ9crSJ2j8EbqaAnbJGoXBsgERPLaACePwcP
-70laYWsyhXkzVgqL2X4ELVk=
-=xGWG
------END PGP SIGNATURE-----
-
-
-
---=-=-=
-Content-Type: text/x-patch
-Content-Disposition: attachment; filename=elgamal.patch
-
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA1
-NotDashEscaped: You need GnuPG to verify this message
-
-Hi,
-
-David Shaw wrote a patch against GnuPG 1.2.3 to disable the ability to
-create signatures using the ElGamal sign+encrypt (type 20) keys as
-well as to remove the option to create such keys.
-
-This patch will go into the next release; if you feel better with
-those flawed features disabled, you may want to apply this patch.
-
-
-Thanks,
-
-  Werner
-
-
-Index: getkey.c
-===================================================================
-RCS file: /cvs/gnupg/gnupg/g10/getkey.c,v
-retrieving revision 1.78.2.20
-diff -u -r1.78.2.20 getkey.c
---- getkey.c	21 Jul 2003 14:55:00 -0000	1.78.2.20
-+++ getkey.c	27 Nov 2003 00:32:30 -0000
-@@ -1655,6 +1655,11 @@
-         if ( x ) /* mask it down to the actual allowed usage */
-             key_usage &= x; 
-     }
-+
-+    /* Type 20 Elgamal keys are not usable. */
-+    if(pk->pubkey_algo==PUBKEY_ALGO_ELGAMAL)
-+      key_usage=0;
-+
-     pk->pubkey_usage = key_usage;
- 
-     if ( !key_expire_seen ) {
-@@ -1869,6 +1874,13 @@
-         if ( x ) /* mask it down to the actual allowed usage */
-             key_usage &= x; 
-     }
-+
-+    /* Type 20 Elgamal subkeys or any subkey on a type 20 primary are
-+       not usable. */
-+    if(mainpk->pubkey_algo==PUBKEY_ALGO_ELGAMAL
-+       || subpk->pubkey_algo==PUBKEY_ALGO_ELGAMAL)
-+      key_usage=0;
-+
-     subpk->pubkey_usage = key_usage;
-     
-     p = parse_sig_subpkt (sig->hashed, SIGSUBPKT_KEY_EXPIRE, NULL);
-Index: keygen.c
-===================================================================
-RCS file: /cvs/gnupg/gnupg/g10/keygen.c,v
-retrieving revision 1.90.2.11
-diff -u -r1.90.2.11 keygen.c
---- keygen.c	16 Jul 2003 03:09:15 -0000	1.90.2.11
-+++ keygen.c	27 Nov 2003 00:32:31 -0000
-@@ -958,8 +958,6 @@
-     tty_printf(    _("   (%d) DSA (sign only)\n"), 2 );
-     if( addmode )
- 	tty_printf(    _("   (%d) ElGamal (encrypt only)\n"), 3 );
--    if (opt.expert)
--        tty_printf(    _("   (%d) ElGamal (sign and encrypt)\n"), 4 );
-     tty_printf(    _("   (%d) RSA (sign only)\n"), 5 );
-     if (addmode)
-         tty_printf(    _("   (%d) RSA (encrypt only)\n"), 6 );
-@@ -989,21 +987,6 @@
- 	    algo = PUBKEY_ALGO_RSA;
-             *r_usage = PUBKEY_USAGE_SIG;
- 	    break;
--	}
--	else if( algo == 4 && opt.expert)
--	  {
--	    tty_printf(_(
--"The use of this algorithm is only supported by GnuPG.  You will not be\n"
--"able to use this key to communicate with PGP users.  This algorithm is also\n"
--"very slow, and may not be as secure as the other choices.\n"));
--
--	    if( cpr_get_answer_is_yes("keygen.algo.elg_se",
--				      _("Create anyway? ")))
--	      {
--		algo = PUBKEY_ALGO_ELGAMAL;
--		*r_usage = PUBKEY_USAGE_ENC | PUBKEY_USAGE_SIG;
--		break;
--	      }
- 	}
- 	else if( algo == 3 && addmode ) {
- 	    algo = PUBKEY_ALGO_ELGAMAL_E;
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v1.2.3 (GNU/Linux)
-
-iD8DBQE/xa20aLeriVdUjc0RAvXcAKCIxQR0JbaxfX/EFpI4NLcb4vUI2ACZAQTx
-zfX4QUrn7HnluPP4Pfoofdk=
-=OtPO
------END PGP SIGNATURE-----
-
---=-=-=--
-
-
diff --git a/app-crypt/gnupg/files/gnupg-1.2.3-hkp-format-string.diff b/app-crypt/gnupg/files/gnupg-1.2.3-hkp-format-string.diff
deleted file mode 100644
index efb98bf6a680..000000000000
--- a/app-crypt/gnupg/files/gnupg-1.2.3-hkp-format-string.diff
+++ /dev/null
@@ -1,30 +0,0 @@
-#########################
-# http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/gnupg/keyserver/gpgkeys_hkp.c.diff?r1=text&tr1=1.15.2.7&r2=text&tr2=1.15.2.8&diff_format=u
-#
-# - taviso@gentoo.org 03/12/2003.
-#
-###################################
-===================================================================
-RCS file: /cvs/gnupg/gnupg/keyserver/gpgkeys_hkp.c,v
-retrieving revision 1.15.2.7
-retrieving revision 1.15.2.8
-diff -u -r1.15.2.7 -r1.15.2.8
---- gnupg/keyserver/gpgkeys_hkp.c	2003/05/30 04:00:26	1.15.2.7
-+++ gnupg/keyserver/gpgkeys_hkp.c	2003/11/27 12:18:20	1.15.2.8
-@@ -268,14 +268,14 @@
- 
- 	  if(gotit)
- 	    {
--	      fprintf(output,line);
-+	      fputs (line, output);
- 	      if(strcmp(line,"-----END PGP PUBLIC KEY BLOCK-----\n")==0)
- 		break;
- 	    }
- 	  else
- 	    if(strcmp(line,"-----BEGIN PGP PUBLIC KEY BLOCK-----\n")==0)
- 	      {
--		fprintf(output,line);
-+		fputs (line, output);
- 		gotit=1;
- 	      }
- 	}