From wk at gnupg.org Thu Dec 4 15:29:10 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Dec 2008 15:29:10 +0100 Subject: ID Substring Matching In-Reply-To: <48C18814.60706@hurricanelabs.com> (Lann Martin's message of "Fri, 05 Sep 2008 15:27:16 -0400") References: <48C18814.60706@hurricanelabs.com> Message-ID: <873ah4xbd5.fsf@wheatstone.g10code.de> On Fri, 5 Sep 2008 21:27, lann-gnupg at hurricanelabs.com said: > If I specify a recipient on the command line, say: > -r friendly at example.com > gpg may select as the actual recipient. Despite > being documented in the manual, this feature is potentially dangerous > for the inexperienced GnuPG user (me). Also, it is an uncommon enough We can't change this anymore becuase it would break alsmost all applications of gnupg. The suggested way to speicify a key is by using its fingerprint which does not have this problem. Good mail clients do their own matching to allow the user to select a key if there is no unambiguous key available for example if two keys friend at example.com are in the keyring. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From mikeb at mikebanahan.com Thu Dec 4 20:32:36 2008 From: mikeb at mikebanahan.com (mikeb at mikebanahan.com) Date: Thu, 4 Dec 2008 19:32:36 +0000 Subject: Using smart card to access encrypted secret keyring Message-ID: <20081204193236.GA14245@lager.gbdirect.co.uk> I apologise if this subject has been discussed before but I'm new to the list. Having recently figured out what the objective of the Gnu smartcard is (and been pleased by how easy it is to use) I note one or two deficiencies in it from my persepctive. The most obvious is that I have already got significant investment in my primary key which is DSA not RSA and therefore can never be moved to the card. It also has a number of subkeys which remain in use and they are not suitable for the card either. Also I have several other secret keys used for varying roles - personal, business, hobby and so on. The card does not assist with these. However, if I could encrypt my secret keyring using the card key and then use those keys simply by inserting the card and entering its pin (i.e. the encrypted secret keyring is decrypted by gnupg for me) that would greatly assist. That would reduce the risks in having those keys on a less secure computer since they would be doubly protected; once by encryption and again by their passphrases. I'm tempted to implement this to see how hard it would be to do - probably as read-only to begin with, on the grounds that if I want to edit the secret keyring it should be done elsewhere, treating the encrypted version as a read-only version. However I suspect that there are people using this list who are considerably smarter than I am so I would welcome comments on the value of my idea before I get over-excited about it. Best wishes, Mike Banahan From dshaw at jabberwocky.com Thu Dec 4 21:45:04 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Dec 2008 15:45:04 -0500 Subject: Using smart card to access encrypted secret keyring In-Reply-To: <20081204193236.GA14245@lager.gbdirect.co.uk> References: <20081204193236.GA14245@lager.gbdirect.co.uk> Message-ID: <20081204204504.GB45454@jabberwocky.com> On Thu, Dec 04, 2008 at 07:32:36PM +0000, mikeb at mikebanahan.com wrote: > The most obvious is that I have already got significant investment > in my primary key which is DSA not RSA and therefore can never be > moved to the card. It also has a number of subkeys which remain in > use and they are not suitable for the card either. > > Also I have several other secret keys used for varying roles - > personal, business, hobby and so on. The card does not assist with > these. > > However, if I could encrypt my secret keyring using the card key and > then use those keys simply by inserting the card and entering its > pin (i.e. the encrypted secret keyring is decrypted by gnupg for me) > that would greatly assist. That would reduce the risks in having > those keys on a less secure computer since they would be doubly > protected; once by encryption and again by their passphrases. It depends on how secure the "less secure" computer is. The idea behind a smart card is that the key itself lives on the card and can't (by the nature of the card) be copied off. Even if the host computer is completely compromised, it cannot get the key off the card. (It can, however, remember your pin and use it to make some extra signatures or the like when the card is in the reader and you're not aware of it, but that's a different issue) Hence the "it depends" answer: using a smart card to encrypt an already encrypted secret key (that is, super-encrypting), doesn't really give you much protection against a compromised machine. Once you decrypt the secret key for use, the compromised machine then has it (remember that unlike the smart card key, the key we're decrypting doesn't live on the card, so it's just a file on disk to the host computer). This is similar in effect to the "put the key on a USB stick" idea. The key is protected until you use it, after which is isn't protected. Another way to look at it is that if your computer is secure, you don't need this, and if your computer is insecure, you can't use this. I don't want to give the impression that doing this is useless. It's not, but it doesn't add very much protection above what GPG already gives you with a straight passphrase. A possibly better way to go about this is to make a new subkey or two and store *them* on the card. I know you have subkeys in use, but by design, subkeys are easy to change. David From wk at gnupg.org Fri Dec 5 10:42:10 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Dec 2008 10:42:10 +0100 Subject: trust field for CMS In-Reply-To: <200808211620.08481.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 21 Aug 2008 16:20:04 +0200") References: <200808131416.20617.bernhard@intevation.de> <200808131555.45453.bernhard@intevation.de> <87hc9pgddo.fsf@wheatstone.g10code.de> <200808211620.08481.bernhard@intevation.de> Message-ID: <87r64nuff1.fsf@wheatstone.g10code.de> On Thu, 21 Aug 2008 16:20, bernhard at intevation.de said: > What about using 'm' in CMS (X.509) to indicate that > --disable-crl-checks OR --disable-policy-checks is active? I do not think tha this is a good idea. For OpenPGP we have no way to to check whether gpg has recently checked for a revocation certificate and thus the behaviour would be different between OpenPGP and X.509: In OpenPGP the 'm' describes a "marginally valid certificate" whereas in X.509 it descrives, a "fully valid certificate", just not checked for revocations. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Mon Dec 8 20:06:49 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 08 Dec 2008 20:06:49 +0100 Subject: select pinentry-curses/qt depending on situation In-Reply-To: <20081123162111.GB7861@localhost> References: <20081123162111.GB7861@localhost> Message-ID: <493D7049.2070705@ruhr-uni-bochum.de> Petr Uzel wrote: > Hey list! > > What is the best way (if any) to select which pinentry (-curses/-qt/-gtk) to > run, depending on situation, i.e. whether X is running and whether we have tty. The graphical pinentries have a fallback, which detects if no X is running and runs the curses pinentry (compiled in statically, ie the pinentry-curses binary is not needed in this case). > What I want is to run pinentry-curses if there is tty (e.g. gpg in virtual > console), and 'graphical' pinentry otherwise (e.g. signing mail in kmail). This should work fine with the pinentry-qt binary. Did you try it? I know that it works for pinentry-gtk-2. > Now, I have a shell script named /usr/bin/pinentry, that tries to determine > which pinentry to run and then executes it. The problem is that it can only use > command line options that gpg-agent passes to pinentry. This options either > does or doesn't contain --display option, depending on whether X is running. > The rest of options (namely --ttyname) is passed to pinentry via assuan > protocol, which obviously can not be used in the process of selecting proper > pinentry. Without ttyname I can't distinguish whether I have virtual terminal > or not (calling tty -s in pinentry script does not work). pinentry-FOO uses the DISPLAY variable setting to determine if X is running or not. > I have two questions: > > 1) Is there any way how to pass ttyname (and possibly other options) to > pinentry via command line arguments instead of assuan protocol? > > 2) More generally, is there any better way how to run various versions of > pinentry depending on situation ? Thanks, Marcus From wk at gnupg.org Tue Dec 9 08:55:27 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Dec 2008 08:55:27 +0100 Subject: [patch] gnupg-2.0.9 uses wrong charset In-Reply-To: <200806111400.39746.petr.uzel@suse.cz> (Petr Uzel's message of "Wed, 11 Jun 2008 14:00:38 +0200") References: <200806111400.39746.petr.uzel@suse.cz> Message-ID: <877i69u6j4.fsf@wheatstone.g10code.de> On Wed, 11 Jun 2008 14:00, petr.uzel at suse.cz said: > This can be fixed by calling setlocale(LC_ALL, "") prior to nl_langinfo(). > Since setlocale() is called from i18n_init() and nl_langinfo() from > init_common_subsystems(), attached patch should IMHO fix the problem. Just did this for all tools. Thanks, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Tue Dec 9 10:59:53 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Dec 2008 10:59:53 +0100 Subject: BUG: gpg 1.4.9 crashes when creating ELG keys with sign and encrypt capability in batch mode In-Reply-To: <48783DD5.5020109@adammil.net> (Adam Milazzo's message of "Fri, 11 Jul 2008 22:15:01 -0700") References: <48783DD5.5020109@adammil.net> Message-ID: <87zlj5sm7a.fsf@wheatstone.g10code.de> On Sat, 12 Jul 2008 07:15, adam at adammil.net said: > I think you're not supposed to use ElGamal keys that can sign and > encrypt, but GPG shouldn't crash in any case. This crash happens > consistently. Fixed in svn 4891. Error message for your example is now: gpg: -:4: specified Subkey-Usage not allowed for algo 16 Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Tue Dec 9 13:00:47 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Dec 2008 13:00:47 +0100 Subject: [Announce] First release candidate for GnuPG 2.0.10 Message-ID: <87skoxsgls.fsf@wheatstone.g10code.de> Hi, I just uploaded a release candidate for GnuPG 2.0.10: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.10rc1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.10rc1.tar.bz2.sig Note that the language files are not all updated; the known translators have been informed about this release candidate. If everything works out fine, the release is planned for end of December. Noteworthy changes in version 2.0.10 (unreleased) ------------------------------------------------- * [gpg] New keyserver helper gpg2keys_kdns as generic DNS CERT lookup. Run with --help for a short description. Requires the ADNS library. * [gpg] New mechanisms "local" and "nodefault" for --auto-key-locate. Fixed a few problems with this option. * [gpg] New command --locate-keys. * [gpg] New options --with-sig-list and --with-sig-check. * [gpg] The option "-sat" is no longer an alias for --clearsign. * [gpg] The option --fixed-list-mode is now implicitly used and obsolete. * [gpg] New control statement %ask-passphrase for the unattended key generation. * [gpgsm] Now uses AES by default. * [gpgsm] Made --output option work with --export-secret-key-p12. * [gpg-agent] Terminate process if the own listening socket is not anymore served by ourself. * [scdaemon] Made it more robust on W32. * [gpg-connect-agent] Accept commands given as command line arguments. * [w32] Initialized the socket subsystem for all keyserver helpers. * [w32] The sysconf directory has been moved from a subdirectory of the installation directory to %CSIDL_COMMON_APPDATA%/GNU/etc/gnupg. * [w32] The gnupg2.nls directory is not anymore used. The standard locale directory is now used. * [w32] Fixed a race condition bteween gpg and gpgsm in the use of temporary file names. * The gpg-preset-passphrase mechanism works again. An arbitrary string may now be used for a custom cache ID. * Admin PINs are cached again (bug in 2.0.9). * Support for version 2 OpenPGP cards. * Libgcrypt 1.4 is now required. There is a small bug I noticed too late: The libgcrypt version is always printed by gpg2 unless --batch is used. Happy hacking, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From pat.pannuto at gmail.com Mon Dec 1 16:39:43 2008 From: pat.pannuto at gmail.com (Pat Pannuto) Date: Mon, 1 Dec 2008 10:39:43 -0500 Subject: (gpg/gcry)_strsource_r()? Message-ID: Hi all, I'm writing an app using libgcrypt, and I noticed that a reentrant / thread-safe version of gcry_strerror is provided (gpg_strerror_r), but there is no analog for gcry_strsource? I tried both gcry_strsource_r and gpg_strsource_r on the off chance that they would work, but they did not. >From what I've noticed in debugging, the source is rarely very useful, and I see no real harm in just leaving it out I suppose, but if such a function exists, it would be nice to include it for completeness. Thanks, Pat -- Patrick Pannuto Computer Engineering University of Michigan 248.990.4548 -------------- next part -------------- An HTML attachment was scrubbed... URL: From RNufer at wakemed.org Fri Dec 5 15:49:11 2008 From: RNufer at wakemed.org (REX NUFER) Date: Fri, 5 Dec 2008 09:49:11 -0500 Subject: sig help Message-ID: I'm trying to download and install GPG. I've downloaded the files I need. The readme's all say I should verify the file by running sha1sum.exe against the tar files I've downloaded. They say to use the value in the *.sig file to compare the output against. But I can't read the *.sig file. How to I view that file? Does it need to be converted in some way? Thanks in advance. Rex Nufer ------------------------------------------------------------------------------- WakeMed Confidentiality Notice: This message, including any attachments, is for the sole use of the individual or entity to whom it is addressed and may contain confidential and/or legally privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorized review, use, copying, disclosure, or distribution of this message and attachments is strictly prohibited. ------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1089 bytes Desc: image001.gif URL: From gawd0wns at yahoo.com Sat Dec 6 02:21:02 2008 From: gawd0wns at yahoo.com (gline) Date: Fri, 5 Dec 2008 17:21:02 -0800 (PST) Subject: GnuPG feature suggestion Message-ID: <20865565.post@talk.nabble.com> I believe the addition of a secure file shredding application with GnuPG (particularly the windows version) would increase the application's robustness. What do you think? -- View this message in context: http://www.nabble.com/GnuPG-feature-suggestion-tp20865565p20865565.html Sent from the GnuPG - Dev mailing list archive at Nabble.com. From g.esp at free.fr Wed Dec 10 13:47:18 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Wed, 10 Dec 2008 13:47:18 +0100 Subject: sig help In-Reply-To: References: Message-ID: <1228913238.493fba5633986@imp.free.fr> Selon REX NUFER : > > I'm trying to download and install GPG. I've downloaded the files I need. > The readme's all say I should verify the file by running sha1sum.exe against > the tar files I've downloaded. They say to use the value in the *.sig file > to compare the output against. But I can't read the *.sig file. How to I > view that file? Does it need to be converted in some way? Thanks in > advance. > > Rex Nufer > You are mixing answer a) witht anwser b) You can't use the .sig file if you don't already have gpg installed " a) If you already have a trusted Version of GnuPG installed, you can simply check the supplied signature: $ gpg --verify gnupg-x.y.z.tar.gz.sig "... " b) If you don't have any of the above programs, you have to verify the SHA1 checksum: $ sha1sum gnupg-x.y.z.tar.gz " If you don't have gpg installed, you are in the b) case and have only the sha1 you could see the value at http://www.gnupg.org/download/index.en.html Depending if you have loaded .bz2 or .gz flavor 826f4bef1effce61c3799c8f7d3cc8313b340b55 gnupg-1.4.9.tar.bz2 52a245d20da70a3f79a2134c8ece3a1d30554ffa gnupg-1.4.9.tar.gz Gilles From tomp at idirect.com Fri Dec 12 00:02:07 2008 From: tomp at idirect.com (Tom Pegios) Date: Thu, 11 Dec 2008 18:02:07 -0500 Subject: GPG v2 svn:4899 make reports error in g10 directory Message-ID: <49419BEF.6080108@idirect.com> The following error occurs when trying to build GPG2 svn:4899 make[2]: Entering directory `/src/v2/4899/g10' make[2]: *** No rule to make target `rmd160.o', needed by `gpg2.exe'. Stop. make[2]: Leaving directory `/src/v2/4899/g10' This error was introduced in svn:4899 as the previous version (svn:4897) was fine. Regards Tom Pegios From bernhard at intevation.de Fri Dec 12 08:47:43 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 12 Dec 2008 08:47:43 +0100 Subject: GnuPG feature suggestion In-Reply-To: <20865565.post@talk.nabble.com> References: <20865565.post@talk.nabble.com> Message-ID: <200812120847.43967.bernhard@intevation.de> Am Samstag, 6. Dezember 2008 02:21:02 schrieb gline: > I believe the addition of a secure file shredding application with GnuPG > (particularly the windows version) would increase the application's > robustness. ?What do you think? I believe that crypto and the problem of securely deleting files form a filesystem media are completely different problems. So no, I would not wish to have this come with GnuPG itself. You could phrase a wish to the www.gpg4win.org packaging effort to see if they would take up a different application for file deletion. Note that another interesting approach is to use crypto file systems and just delete the keys when you are done. Is much easier than to wipe a disc. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: From bernhard at intevation.de Fri Dec 12 08:49:06 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 12 Dec 2008 08:49:06 +0100 Subject: trust field for CMS In-Reply-To: <87r64nuff1.fsf@wheatstone.g10code.de> References: <200808131416.20617.bernhard@intevation.de> <200808211620.08481.bernhard@intevation.de> <87r64nuff1.fsf@wheatstone.g10code.de> Message-ID: <200812120849.06909.bernhard@intevation.de> Am Freitag, 5. Dezember 2008 10:42:10 schrieb Werner Koch: > On Thu, 21 Aug 2008 16:20, bernhard at intevation.de said: > > What about using 'm' in CMS (X.509) to indicate that > > --disable-crl-checks OR --disable-policy-checks is active? > > I do not think tha this is a good idea. ?For OpenPGP we have no way to > to check whether gpg has recently checked for a revocation certificate > and thus the behaviour would be different between OpenPGP and X.509: In > OpenPGP the 'm' describes a "marginally valid certificate" whereas in > X.509 it descrives, a "fully valid certificate", just not checked for > revocations. Yes, I agree that it is different. I was wondering how this status could be communicated and what "marginally valid certificate" translated to in client action. So I saw the coindicence. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Dec 12 09:07:18 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Dec 2008 09:07:18 +0100 Subject: GPG v2 svn:4899 make reports error in g10 directory In-Reply-To: <49419BEF.6080108@idirect.com> (Tom Pegios's message of "Thu, 11 Dec 2008 18:02:07 -0500") References: <49419BEF.6080108@idirect.com> Message-ID: <87fxktolzd.fsf@wheatstone.g10code.de> On Fri, 12 Dec 2008 00:02, tomp at idirect.com said: > make[2]: Entering directory `/src/v2/4899/g10' > make[2]: *** No rule to make target `rmd160.o', needed by `gpg2.exe'. Stop. You need to use./confgure --enable-maintainer-mode or run autogen.sh first. However the file rmd160.h was missing in the SVN. I just commited it and a make distcheck works. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bh at intevation.de Fri Dec 12 11:27:49 2008 From: bh at intevation.de (Bernhard Herzog) Date: Fri, 12 Dec 2008 11:27:49 +0100 Subject: GPG v2 svn:4899 make reports error in g10 directory In-Reply-To: <87fxktolzd.fsf@wheatstone.g10code.de> References: <49419BEF.6080108@idirect.com> <87fxktolzd.fsf@wheatstone.g10code.de> Message-ID: <200812121127.52006.bh@intevation.de> On 12.12.2008, Werner Koch wrote: > However the file rmd160.h was missing in the SVN. I just commited it > and a make distcheck works. rmd160.c seems to be missing in SVN too. Bernhard -- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Dec 12 12:11:58 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Dec 2008 12:11:58 +0100 Subject: GPG v2 svn:4899 make reports error in g10 directory In-Reply-To: <200812121127.52006.bh@intevation.de> (Bernhard Herzog's message of "Fri, 12 Dec 2008 11:27:49 +0100") References: <49419BEF.6080108@idirect.com> <87fxktolzd.fsf@wheatstone.g10code.de> <200812121127.52006.bh@intevation.de> Message-ID: <87iqppmyv5.fsf@wheatstone.g10code.de> On Fri, 12 Dec 2008 11:27, bh at intevation.de said: > rmd160.c seems to be missing in SVN too. Oh well, I was soooo sure that I added it. But right, I didn't. it will be in 4903. Thanks, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Fri Dec 12 12:38:21 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 12 Dec 2008 12:38:21 +0100 Subject: gpg.texi gpgsm.texi small type "Not " -> "Note" Message-ID: <200812121238.25422.bernhard@intevation.de> http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/gpg.texi?rev=4888&root=GnuPG&view=auto | Not that you cannot abbreviate this command. http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/gpgsm.texi?rev=4850&root=GnuPG&view=markup | Not that you can | Not that you can abbreviate this command. | Not that you can -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: From wk at gnupg.org Fri Dec 12 14:14:41 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Dec 2008 14:14:41 +0100 Subject: gpg.texi gpgsm.texi small type "Not " -> "Note" In-Reply-To: <200812121238.25422.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 12 Dec 2008 12:38:21 +0100") References: <200812121238.25422.bernhard@intevation.de> Message-ID: <87ej0dmt6m.fsf@wheatstone.g10code.de> On Fri, 12 Dec 2008 12:38, bernhard at intevation.de said: > | Not that you can abbreviate this command. Actually this should read Note that you cannot abbreviate this command. Thanks, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From maarons at gnu.org Fri Dec 12 18:07:17 2008 From: maarons at gnu.org (Marek Aaron Sapota) Date: Fri, 12 Dec 2008 12:07:17 -0500 Subject: GnuPG FAQ suggestion Message-ID: <20081212170717.GA24656@fencepost.gnu.org> Hi, I'm gnu.org webmaster and we would like to put a link in download area to instructions how to check signature of downloaded package. We would like to link to: http://www.gnupg.org/documentation/faqs.en.html#q4.19 I have a suggestion though. This text: "Before you can verify the signature that accompanies a package, you must first have the vendor, organisation, or issueing person's key imported into your public keyring. To prevent GnuPG warning messages the key should also be validated (or locally signed). " isn't very informative for new users. Could you put there an explanation how to download a key for signature it it's on a public server? As a side note, shouldn't issueing be spelled issuing? Marek Aaron Sapota -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature URL: From bernhard at intevation.de Mon Dec 15 10:12:10 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 15 Dec 2008 10:12:10 +0100 Subject: Vs Combined Method? E+S from RFC 3156 6.2 In-Reply-To: <200807162308.45596.bernhard@intevation.de> References: <200804291414.53915.bernhard@intevation.de> <87fxsetkba.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200807162308.45596.bernhard@intevation.de> Message-ID: <200812151012.13350.bernhard@intevation.de> Am Mittwoch, 16. Juli 2008 23:08:41 schrieb Bernhard Reiter: > I am coming back to the discussion, > because I do not see the resolution. Again. Let me add that having this arguments available would be more and more important, because in the last month alone I've got email claimed to be from the following email application that are using the combined method (and text mode), which again I assume Werner dislikes: 1. User-Agent: Thunderbird 2.0.0.18 (X11/20081125) X-Enigmail-Version: 0.95.7 2. User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) 3. User-Agent: Mutt/1.5.18 (2008-05-17) Werner, what do you think? Even a strong recommendation from your side that someone could link to might help those implementors. Bernhard > According to RFC 3156 6.2 it makes sense to always use the combined > method for encryption and signature as there is a requirement > for all compliant application to support this method. > Still I am looking for arguments why this is not a good idea. > > On Monday 19 May 2008 16:55, Marcus Brinkmann wrote: > > At Thu, 15 May 2008 14:16:09 +0200, Bernhard Reiter wrote: > > > On Thursday 15 May 2008 13:20, Marcus Brinkmann wrote: > > > > At Tue, 29 Apr 2008 14:14:45 +0200, > > > > > > > > Bernhard Reiter wrote: > > > > > Given the enhanced compatibility, why not do combined method > > > > > whenever you can, just getting the compatibility advantage? > > > > > > > > Compatibility with what? > > > > > > The RFC from August 2001 says "to increase compatibility > > > with non-MIME implementations of OpenPGP". > > > > I was hoping for some specific applications that are in use today. > > Even if there is a tiny small number even on older machines, > this would be no reason to not use the combined method as > all the other applications also need to support it. > > Also this would be an open question what the RFC writers had in mind > when they made this statement. Is there a good way to find out about this?= > > > > Sure, so you are basically saying: The argument from 2001 is obsolete. > > > > I am not saying that, I am just suggesting that, after evaluation, it > > might be such a case, depending on how important compatibility is in > > the real world. > > > > > On the other hand, to ease the implementation, shouldn't we then push > > > for the removal of the combined method requirement? > > > At least make it mandadory in new implementation to not create > > > new combined method emails? > > > > I think that, if this is such a case, then that would be a sensible > > next step. > > This makes your argument depend on the outcome of the analysis. > Given that Werner does not recommend the combined method, > he must have a view on the result already. > > > > > So, the question is, are there significant MUAs that support only > > > > combined mode? > > > > > > As for non-MIME MUAs, I think Outlook is significant. > > > (Being one of the developers of Gpg4win, you know that until recently > > > it could not do MIME OpenPGP. And that Outlook itself it not fully > > > MIME compliant, e.g. it does not display the text part of a > > > multipart/signed email, though it MUST according to MIME standards.) > > > > Oh well, that may be a millstone around our neck for the time being. > > > > > There will be others out there as well, e.g. on older unix machines > > > which did not update software very often. > > > > Not really what you are looking for, but: Somehow I question the > > wisdom of relying on security software on such systems... > > Security is orthogonal to software modernisation: you might run a very old > unix-like system which is fully supported and thus fine security wise, > but still only has old software. > > Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: From wk at gnupg.org Mon Dec 15 11:53:10 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Dec 2008 11:53:10 +0100 Subject: Vs Combined Method? E+S from RFC 3156 6.2 In-Reply-To: <200812151012.13350.bernhard@intevation.de> (Bernhard Reiter's message of "Mon, 15 Dec 2008 10:12:10 +0100") References: <200804291414.53915.bernhard@intevation.de> <87fxsetkba.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200807162308.45596.bernhard@intevation.de> <200812151012.13350.bernhard@intevation.de> Message-ID: <87prjtlnft.fsf@wheatstone.g10code.de> On Mon, 15 Dec 2008 10:12, bernhard at intevation.de said: > would be more and more important, because in the last month alone I've got > email claimed to be from the following email application that are using the > combined method (and text mode), which again I assume Werner dislikes: It is merely that I suggest to use the standard method as per rfc3156. > 2. > User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) I am using GNUs for may years and the default is to use the non-combined method. However, it might depend on the backend you use for encryption. I use EasyPG. > 3. > User-Agent: Mutt/1.5.18 (2008-05-17) The principal authors of mutt are also authors of rfc3156. However, I believe that for histroic reasons the default is to use the combined method. If you switch to the GPGME backend ("set crypt_use_gpgme") the default the non-combined method. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Mon Dec 15 17:39:06 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 15 Dec 2008 17:39:06 +0100 Subject: Vs Combined Method? E+S from RFC 3156 6.2 In-Reply-To: <87prjtlnft.fsf@wheatstone.g10code.de> References: <200804291414.53915.bernhard@intevation.de> <200812151012.13350.bernhard@intevation.de> <87prjtlnft.fsf@wheatstone.g10code.de> Message-ID: <200812151739.07026.bernhard@intevation.de> Am Montag, 15. Dezember 2008 11:53:10 schrieb Werner Koch: > On Mon, 15 Dec 2008 10:12, bernhard at intevation.de said: > > would be more and more important, because in the last month alone I've > > got email claimed to be from the following email application that are > > using the combined method (and text mode), which again I assume Werner > > dislikes: > > It is merely that I suggest to use the standard method as per rfc3156. The combined method _is_ a standard method of rfc3156 as it lists both methods. Where do you read out a preference of any of them? -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: From wk at gnupg.org Mon Dec 15 17:53:06 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Dec 2008 17:53:06 +0100 Subject: Vs Combined Method? E+S from RFC 3156 6.2 In-Reply-To: <200812151739.07026.bernhard@intevation.de> (Bernhard Reiter's message of "Mon, 15 Dec 2008 17:39:06 +0100") References: <200804291414.53915.bernhard@intevation.de> <200812151012.13350.bernhard@intevation.de> <87prjtlnft.fsf@wheatstone.g10code.de> <200812151739.07026.bernhard@intevation.de> Message-ID: <87d4ftl6rx.fsf@wheatstone.g10code.de> On Mon, 15 Dec 2008 17:39, bernhard at intevation.de said: > Am Montag, 15. Dezember 2008 11:53:10 schrieb Werner Koch: >> On Mon, 15 Dec 2008 10:12, bernhard at intevation.de said: >> > would be more and more important, because in the last month alone I've >> > got email claimed to be from the following email application that are >> > using the combined method (and text mode), which again I assume Werner >> > dislikes: >> >> It is merely that I suggest to use the standard method as per rfc3156. > > The combined method _is_ a standard method of rfc3156 > as it lists both methods. Where do you read out a preference of any of them? RFC 3156 has to say this in section 6.2: [...] This method is allowed in order to reduce processing overhead and increase compatibility with non-MIME implementations of OpenPGP. [...] and a few lines later: It is explicitly allowed for an agent to decrypt a combined message and rewrite it as a multipart/signed object using the signature data embedded in the encrypted version. To me this is clearly a preference towards the standard (non-combined) method. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Tue Dec 16 09:33:03 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 16 Dec 2008 09:33:03 +0100 Subject: Vs Combined Method? E+S from RFC 3156 6.2 In-Reply-To: <87d4ftl6rx.fsf@wheatstone.g10code.de> References: <200804291414.53915.bernhard@intevation.de> <200812151739.07026.bernhard@intevation.de> <87d4ftl6rx.fsf@wheatstone.g10code.de> Message-ID: <200812160933.03459.bernhard@intevation.de> Am Montag, 15. Dezember 2008 17:53:06 schrieb Werner Koch: > >> It is merely that I suggest to use the standard method as per rfc3156. > > > > The combined method _is_ a standard method of rfc3156 > > as it lists both methods. Where do you read out a preference of any of > > them? > > RFC 3156 has to say this in section 6.2: > > ? ?[...] This method is allowed > ? ?in order to reduce processing overhead and increase compatibility > ? ?with non-MIME implementations of OpenPGP. ?[...] > > and a few lines later: > > ? ?It is explicitly allowed for an agent to decrypt a combined message > ? ?and rewrite it as a multipart/signed object using the signature data > ? ?embedded in the encrypted version. > > To me this is clearly a preference towards the standard (non-combined) > method. This is a weak perference (unfortunately) if it is one at all. To "allow" the combined method and to allow to rewrite it might be interpreted that the other one is prefered. If the RFC writers would have thought about a preference they should have written something like The method from 6.1 SHOULD be used. or that it is RECOMMENDED. The fact that they did not will make most people believe that there is no preference. This might be an oversight of the RFC writers then. So I still believe that having the arguments _why_ the combined method SHOULD not be prefered would be helpful to convince implementors. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. URL: From kssingvo at suse.de Tue Dec 16 18:33:03 2008 From: kssingvo at suse.de (Klaus Singvogel) Date: Tue, 16 Dec 2008 18:33:03 +0100 Subject: gnupg-1.4.9 fails checks in new distribution Message-ID: <20081216173303.GA14550@suse.de> Hi, I noticed that gnupg-1.4.9 fails currently 10 of 27 tests in openSUSE-11.1. FAIL: encrypt.test FAIL: encrypt-dsa.test FAIL: seat.test FAIL: encryptp.test FAIL: armencrypt.test FAIL: armencryptp.test FAIL: signencrypt.test FAIL: armsignencrypt.test FAIL: conventional.test FAIL: conventional-mdc.test The failures didn't occur with openSUSE-11.0 or previous. Having a closer look into the logfiles of above failed tests, I see always the same error message: -------------------------------------------------------------------- encrypt.test.log: Rijndael-128 test encryption failed. encrypt-dsa.test.log: Rijndael-128 test encryption failed. seat.test.log: Rijndael-128 test encryption failed. encryptp.test.log: Rijndael-128 test encryption failed. armencrypt.test.log: Rijndael-128 test encryption failed. armencryptp.test.log: Rijndael-128 test encryption failed. signencrypt.test.log: Rijndael-128 test encryption failed. armsignencrypt.test.log: Rijndael-128 test encryption failed. conventional.test.log: Rijndael-128 test encryption failed. conventional-mdc.test.log: Rijndael-128 test encryption failed. [2x] -------------------------------------------------------------------- In some logfiles (e.g. armsignencrypt.test.log) I see also the following message, but I'm unsure if it is relevant here: -------------------------------------------------------------------- gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: weak key created - retrying gpg: fatal: cannot avoid weak key for symmetric cipher; tried 16 times! secmem usage: 3360/4064 bytes in 7/9 blocks of pool 4064/32768 -------------------------------------------------------------------- But this additional message is not always present, e.g. in conventional.test.log missing. Anybody seen this too? If so, how has it been solved? Thanks in advance. Regards, Klaus. -- Klaus Singvogel - Maxfeldstr. 5 - 90409 Nuernberg - Germany Phone: +49-911-74053-0 GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) From dshaw at jabberwocky.com Wed Dec 17 02:28:46 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 16 Dec 2008 20:28:46 -0500 Subject: gnupg-1.4.9 fails checks in new distribution In-Reply-To: <20081216173303.GA14550@suse.de> References: <20081216173303.GA14550@suse.de> Message-ID: <4E4A0DD6-FBAD-447A-BDF9-8664EDD55C4C@jabberwocky.com> On Dec 16, 2008, at 12:33 PM, Klaus Singvogel wrote: > > Hi, > I noticed that gnupg-1.4.9 fails currently 10 of 27 tests in > openSUSE-11.1. > > FAIL: encrypt.test > FAIL: encrypt-dsa.test > FAIL: seat.test > FAIL: encryptp.test > FAIL: armencrypt.test > FAIL: armencryptp.test > FAIL: signencrypt.test > FAIL: armsignencrypt.test > FAIL: conventional.test > FAIL: conventional-mdc.test > > The failures didn't occur with openSUSE-11.0 or previous. There isn't enough information here to even guess. Can you give us more information, please? i386, x86_64, PowerPC? Please also send in your config.log file from when you ran ./configure. David From kssingvo at suse.de Wed Dec 17 10:55:30 2008 From: kssingvo at suse.de (Klaus Singvogel) Date: Wed, 17 Dec 2008 10:55:30 +0100 Subject: gnupg-1.4.9 fails checks in new distribution In-Reply-To: <4E4A0DD6-FBAD-447A-BDF9-8664EDD55C4C@jabberwocky.com> References: <20081216173303.GA14550@suse.de> <4E4A0DD6-FBAD-447A-BDF9-8664EDD55C4C@jabberwocky.com> Message-ID: <20081217095530.GA11725@suse.de> David Shaw wrote: > On Dec 16, 2008, at 12:33 PM, Klaus Singvogel wrote: > > >I noticed that gnupg-1.4.9 fails currently 10 of 27 tests in > >openSUSE-11.1. > > > >FAIL: encrypt.test > >FAIL: encrypt-dsa.test > >FAIL: seat.test > >FAIL: encryptp.test > >FAIL: armencrypt.test > >FAIL: armencryptp.test > >FAIL: signencrypt.test > >FAIL: armsignencrypt.test > >FAIL: conventional.test > >FAIL: conventional-mdc.test > > > >The failures didn't occur with openSUSE-11.0 or previous. > > There isn't enough information here to even guess. Can you give us > more information, please? i386, x86_64, PowerPC? Sure. No problem. The tests fail on i586 as well on x86_64. It's the very same package, which builds on openSUSE-11.1. So I assume it's a library or compiler, which the cause of the problem is. > Please also send in your config.log file from when you ran ./configure. It's very large, so I compressed it with bzip2, before I attached it. Hope it's ok. Regards, Klaus. -- Klaus Singvogel - Maxfeldstr. 5 - 90409 Nuernberg - Germany Phone: +49-911-74053-0 GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.bz2 Type: application/x-bzip Size: 18967 bytes Desc: not available URL: From dshaw at jabberwocky.com Wed Dec 17 17:11:58 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 17 Dec 2008 11:11:58 -0500 Subject: gnupg-1.4.9 fails checks in new distribution In-Reply-To: <20081217095530.GA11725@suse.de> References: <20081216173303.GA14550@suse.de> <4E4A0DD6-FBAD-447A-BDF9-8664EDD55C4C@jabberwocky.com> <20081217095530.GA11725@suse.de> Message-ID: On Dec 17, 2008, at 4:55 AM, Klaus Singvogel wrote: > David Shaw wrote: >> On Dec 16, 2008, at 12:33 PM, Klaus Singvogel wrote: >> >>> I noticed that gnupg-1.4.9 fails currently 10 of 27 tests in >>> openSUSE-11.1. >>> >>> FAIL: encrypt.test >>> FAIL: encrypt-dsa.test >>> FAIL: seat.test >>> FAIL: encryptp.test >>> FAIL: armencrypt.test >>> FAIL: armencryptp.test >>> FAIL: signencrypt.test >>> FAIL: armsignencrypt.test >>> FAIL: conventional.test >>> FAIL: conventional-mdc.test >>> >>> The failures didn't occur with openSUSE-11.0 or previous. >> >> There isn't enough information here to even guess. Can you give us >> more information, please? i386, x86_64, PowerPC? > > Sure. No problem. The tests fail on i586 as well on x86_64. > > It's the very same package, which builds on openSUSE-11.1. So I > assume it's a library or compiler, which the cause of the problem > is. > >> Please also send in your config.log file from when you ran ./ >> configure. > > It's very large, so I compressed it with bzip2, before I attached it. > Hope it's ok. Thanks. Nothing really jumped out of the config.log, so I brought up an openSUSE-11.1 box in vmware and the problem reproduced straight away. The issue seems to be between the compiler (gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]) and the cipher/rijndael.c file (i.e. the AES cipher). These two aren't getting along very well when the compiler is set to create very optimized code (which autoconf does by default). The workaround is to do something like ./configure CFLAGS="-O1". If you wanted to get tricky, just compiling rijndael.c with -O1 and the rest of the program with -O2 would work as well. As to whether it's a compiler problem or a rijndael.c problem, I'm inclined to look at the compiler first. rijndael.c has worked fine on many platforms (in GnuPG as well as libgcrypt) for many years through multiple gcc changes, and also compiles fine on a very close relative of that compiler (gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)). I've actually seen something similar to this happen once before, when Apple switched to gcc 4 from gcc 3 a while back. For a few months, until Apple upgraded to 4.0.1, rijndael.c with -O3 would compile without error or warning, but would not result in working code. David From wk at gnupg.org Wed Dec 17 13:36:25 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Dec 2008 13:36:25 +0100 Subject: gnupg-1.4.9 fails checks in new distribution In-Reply-To: <20081217095530.GA11725@suse.de> (Klaus Singvogel's message of "Wed, 17 Dec 2008 10:55:30 +0100") References: <20081216173303.GA14550@suse.de> <4E4A0DD6-FBAD-447A-BDF9-8664EDD55C4C@jabberwocky.com> <20081217095530.GA11725@suse.de> Message-ID: <87d4frj7w6.fsf@wheatstone.g10code.de> On Wed, 17 Dec 2008 10:55, kssingvo at suse.de said: > It's very large, so I compressed it with bzip2, before I attached it. Why are you using these extra options: -D_FORTIFY_SOURCE=2 -fstack-protector \ -funwind-tables -fasynchronous-unwind-tables did you used them also on the old system? The problem is probably due to _FORTIFY_SOURCE=2; youu need to debug that. Note that you might void the effect of the burn_stack calls we use to zeroize the stack variables. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Wed Dec 17 21:02:50 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 17 Dec 2008 15:02:50 -0500 Subject: gnupg-1.4.9 fails checks in new distribution In-Reply-To: <87d4frj7w6.fsf@wheatstone.g10code.de> References: <20081216173303.GA14550@suse.de> <4E4A0DD6-FBAD-447A-BDF9-8664EDD55C4C@jabberwocky.com> <20081217095530.GA11725@suse.de> <87d4frj7w6.fsf@wheatstone.g10code.de> Message-ID: <20081217200250.GA18490@jabberwocky.com> On Wed, Dec 17, 2008 at 01:36:25PM +0100, Werner Koch wrote: > On Wed, 17 Dec 2008 10:55, kssingvo at suse.de said: > > > It's very large, so I compressed it with bzip2, before I attached it. > > Why are you using these extra options: > > -D_FORTIFY_SOURCE=2 -fstack-protector \ > -funwind-tables -fasynchronous-unwind-tables > > did you used them also on the old system? The problem is probably due > to _FORTIFY_SOURCE=2; youu need to debug that. > > Note that you might void the effect of the burn_stack calls we use to > zeroize the stack variables. I did not use those options when I reproduced the problem. I used just -O2 vs -O1. David From kssingvo at suse.de Wed Dec 17 21:13:09 2008 From: kssingvo at suse.de (Klaus Singvogel) Date: Wed, 17 Dec 2008 21:13:09 +0100 Subject: gnupg-1.4.9 fails checks in new distribution In-Reply-To: <87d4frj7w6.fsf@wheatstone.g10code.de> References: <20081216173303.GA14550@suse.de> <4E4A0DD6-FBAD-447A-BDF9-8664EDD55C4C@jabberwocky.com> <20081217095530.GA11725@suse.de> <87d4frj7w6.fsf@wheatstone.g10code.de> Message-ID: <20081217201309.GA27116@suse.de> Werner Koch wrote: > Why are you using these extra options: > > -D_FORTIFY_SOURCE=2 -fstack-protector \ > -funwind-tables -fasynchronous-unwind-tables They were introduced through use of "$RPM_OPT_FLAGS" in the specfile. The intention is to make code more robust against attacks, and therefore the security team of SUSE set them in the global rpm macros file. > did you used them also on the old system? The problem is probably due > to _FORTIFY_SOURCE=2; youu need to debug that. I'm sure about to use options "-D_FORTIFY_SOURCE=2 -fstack-protector", but unsure about the other two on older systems. I think David Shaw already explained, that the issues don't occur anymore, when using "-O1" instead of "-O2" for comilation of rijndael.c. I changed it as suggested (only compiled rijndael.o), and the issues were really gone. I therefore filed a new bugzilla entry against gcc: https://bugzilla.novell.com/show_bug.cgi?id=459921 The bad news is, that profiling the code is no longer possible, when mixing "-O1" with "-O2" object files. But hopefully the compiler specialists can find the cause and fix it. Thanks! Best regards, Klaus. -- Klaus Singvogel - Maxfeldstr. 5 - 90409 Nuernberg - Germany Phone: +49-911-74053-0 GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) From kssingvo at suse.de Wed Dec 17 21:14:50 2008 From: kssingvo at suse.de (Klaus Singvogel) Date: Wed, 17 Dec 2008 21:14:50 +0100 Subject: gnupg-1.4.9 fails checks in new distribution In-Reply-To: References: <20081216173303.GA14550@suse.de> <4E4A0DD6-FBAD-447A-BDF9-8664EDD55C4C@jabberwocky.com> <20081217095530.GA11725@suse.de> Message-ID: <20081217201450.GB27116@suse.de> David Shaw wrote: [...] > If you wanted to get tricky, just compiling rijndael.c with -O1 and the > rest of the program with -O2 would work as well. I did it so and it works. Thanks. Best regards, Klaus. -- Klaus Singvogel - Maxfeldstr. 5 - 90409 Nuernberg - Germany Phone: +49-911-74053-0 GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) From robbat2 at gentoo.org Sun Dec 21 08:19:51 2008 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Sat, 20 Dec 2008 23:19:51 -0800 Subject: Doing --batch --lsign of a subset of uids in multiple keys (each with many uids) Message-ID: <20081221071951.GJ32364@curie-int.orbis-terrarum.net> I'm trying to add a local signature to a subset of uids (those matching @gentoo.org) for each key in a large keyring (~570 keys right now). The docs need some clearing up. There seems to be no way to select a specific uid (not key, but the uid). Basically an analogue of being able to select which subkey (basically "0xDEADBEEF!"). "gpg --lsign IDENTIFIER" only seems to let me choose the overall key, not which uid I'd like to sign, and assumes that I want to sign all uids, which isn't the case. doc/DETAILS doesn't seem to contain anything on using command-fd with edit-key either. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : robbat2 at gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 329 bytes Desc: not available URL: From dshaw at jabberwocky.com Sun Dec 21 17:08:24 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 21 Dec 2008 11:08:24 -0500 Subject: Doing --batch --lsign of a subset of uids in multiple keys (each with many uids) In-Reply-To: <20081221071951.GJ32364@curie-int.orbis-terrarum.net> References: <20081221071951.GJ32364@curie-int.orbis-terrarum.net> Message-ID: <026E94FF-50DE-478C-8C6B-71979E7E45CD@jabberwocky.com> On Dec 21, 2008, at 2:19 AM, Robin H. Johnson wrote: > I'm trying to add a local signature to a subset of uids (those > matching > @gentoo.org) for each key in a large keyring (~570 keys right now). > > The docs need some clearing up. There seems to be no way to select a > specific uid (not key, but the uid). Basically an analogue of being > able > to select which subkey (basically "0xDEADBEEF!"). > > "gpg --lsign IDENTIFIER" only seems to let me choose the overall key, > not which uid I'd like to sign, and assumes that I want to sign all > uids, which isn't the case. GPG does support picking a particular uid out from a key, but it's not part of the --lsign-keys and --sign-keys "short cuts". These short cuts just do "--edit-key (thekey) sign save", so you can do the same (it's a little clunky): gpg --fixed-list-mode --with-colons --list-keys gentoo | awk 'BEGIN { FS = ":" } ; $1 == "pub" {KEY = $5} ; $1 == "uid" && $10 ~ "\@gentoo \.org" { system("gpg --edit-key " KEY " \"uid " $8 "\" lsign") }' David