From patrick at enigmail.net Sun Feb 1 09:52:55 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 01 Feb 2015 09:52:55 +0100 Subject: Encrypting / Signing the mail subject? In-Reply-To: <87mw5ixyee.fsf@alice.fifthhorseman.net> References: <20150116134324.6d918b4e@pc> <87mw5ixyee.fsf@alice.fifthhorseman.net> Message-ID: <54CDE967.3040800@enigmail.net> On 16.01.15 21:29, Daniel Kahn Gillmor wrote: [...] > > Embedded Header Proposal > ======================== > > Here's a counter-proposal to consider, which relies on PGP/MIME. > PGP/MIME messages are the only reliably structured mail OpenPGP e-mail > messages anyway [0]. > > A normal PGP/MIME signed text/plain message structure looks like this > (Content-Type of each part is shown) [1]: > > A ???multipart/signed > B ???text/plain > C ???application/pgp-signature [signature.asc] > > I propose sending a message with an additional text/rfc822-headers [2] part > injected as a sub-part in the message, like this: > > D ???multipart/signed > E ???multipart/mixed > F ????text/rfc822-headers inline [header] > G ????text/plain > H ???application/pgp-signature [signature.asc] > > the text/rfc822-headers mime type is defined here: [...] > > What do you think? I think your proposal is a very nice idea. I will implement this in a future version of Enigmail. -Patrick From bjk at luxsci.net Sun Feb 1 19:06:17 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Sun, 1 Feb 2015 13:06:17 -0500 Subject: [PATCH] Add macro to test for pthreads. In-Reply-To: <1422741481-4652467.67403224.ft0VLvF1v022014@rs146.luxsci.com> References: <1422741481-4652467.67403224.ft0VLvF1v022014@rs146.luxsci.com> Message-ID: <1422814022-302876.565559067.ft11I6I9Q018814@rs146.luxsci.com> On Sat, Jan 31, 2015 at 04:57:14PM -0500, Ben Kibbey wrote: Forgot about gpgme-config. Heres the revised patch. -- Ben Kibbey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-macro-to-test-for-pthreads.patch Type: text/x-diff Size: 17646 bytes Desc: not available URL: From hans at guardianproject.info Mon Feb 2 19:20:46 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 02 Feb 2015 19:20:46 +0100 Subject: ./configure: line 9178: syntax error near unexpected token `LIBGNUTLS, ' Message-ID: <54CFBFFE.8070506@guardianproject.info> I'm getting this while building the latest GnuPG for Android using gnupg 2.1.1: checking for NTBTLS - version >= 0.1.0... no ./configure: line 9178: syntax error near unexpected token `LIBGNUTLS,' ./configure: line 9178: ` PKG_CHECK_MODULES(LIBGNUTLS, gnutls >= $NEED_GNUTLS_VERSION,' make: *** [gnupg/Makefile] Error 2 I'm not really sure the exact trigger for this, but on one Debian/stable machine, I get this problem reliably, while on another Debian/stable machine, I do not. But I think I can see the cause, at line 858 in configure.ac: if test x"$try_gnutls" = xyes ; then PKG_CHECK_MODULES([LIBGNUTLS], [gnutls >= $NEED_GNUTLS_VERSION], [have_gnutls=yes], [have_gnutls=no]) fi Which looks like this in ./configure: if test x"$try_gnutls" = xyes ; then PKG_CHECK_MODULES(LIBGNUTLS, gnutls >= $NEED_GNUTLS_VERSION, have_gnutls=yes, have_gnutls=no) fi Here, PKG_CHECK_MODULES() is being included as a sh function rather than an autoconf macro. As far as I know, it is not valid sh syntax to have a function call with parens spanning multiple lines. I attached the config.log and log of the build itself. The generic ./configure script is too big to attach for this list's strict, tiny 40kb limit, so it is here: https://gist.github.com/eighthave/4212cd6d369c92e4fa7b .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: build.log.bz2 Type: application/x-bzip Size: 4857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.bz2 Type: application/x-bzip Size: 10151 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Feb 2 19:34:35 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 02 Feb 2015 13:34:35 -0500 Subject: ./configure: line 9178: syntax error near unexpected token `LIBGNUTLS, ' In-Reply-To: <54CFBFFE.8070506@guardianproject.info> References: <54CFBFFE.8070506@guardianproject.info> Message-ID: <87bnlcf9hg.fsf@alice.fifthhorseman.net> On Mon 2015-02-02 13:20:46 -0500, Hans-Christoph Steiner wrote: > I'm getting this while building the latest GnuPG for Android using gnupg 2.1.1: > > checking for NTBTLS - version >= 0.1.0... no > ./configure: line 9178: syntax error near unexpected token `LIBGNUTLS,' > ./configure: line 9178: ` PKG_CHECK_MODULES(LIBGNUTLS, gnutls >= > $NEED_GNUTLS_VERSION,' > make: *** [gnupg/Makefile] Error 2 > > I'm not really sure the exact trigger for this, but on one Debian/stable > machine, I get this problem reliably, while on another Debian/stable machine, > I do not. Does the system where the problem happens reliably have pkg-config installed on it? --dkg From wk at gnupg.org Tue Feb 3 11:47:49 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Feb 2015 11:47:49 +0100 Subject: ./configure: line 9178: syntax error near unexpected token `LIBGNUTLS, ' In-Reply-To: <54CFBFFE.8070506@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 02 Feb 2015 19:20:46 +0100") References: <54CFBFFE.8070506@guardianproject.info> Message-ID: <87iofjnuei.fsf@vigenere.g10code.de> On Mon, 2 Feb 2015 19:20, hans at guardianproject.info said: > https://gist.github.com/eighthave/4212cd6d369c92e4fa7b You are using a several weeks old GIT version. Current versions are requiring automake 1.14 - yours don't. Did you run ./autogen.sh ? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Tue Feb 3 23:00:45 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 03 Feb 2015 23:00:45 +0100 Subject: ./configure: line 9178: syntax error near unexpected token `LIBGNUTLS, ' In-Reply-To: <87iofjnuei.fsf@vigenere.g10code.de> References: <54CFBFFE.8070506@guardianproject.info> <87iofjnuei.fsf@vigenere.g10code.de> Message-ID: <54D1450D.7050609@guardianproject.info> Werner Koch: > On Mon, 2 Feb 2015 19:20, hans at guardianproject.info said: > >> https://gist.github.com/eighthave/4212cd6d369c92e4fa7b > > You are using a several weeks old GIT version. Current versions are > requiring automake 1.14 - yours don't. Did you run ./autogen.sh ? This is gnupg-2.1.1 tag, so not an arbitrary git version. I guess I'll try installing pkg-config on the machine where it wasn't working. Updating the Android build to use automake1.14 is probably non-trivial :-( Also, automake1.14 is not available on Debian/stable or wheezy-backports: https://packages.debian.org/search?keywords=automake .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 From wk at gnupg.org Wed Feb 4 08:31:02 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Feb 2015 08:31:02 +0100 Subject: ./configure: line 9178: syntax error near unexpected token `LIBGNUTLS, ' In-Reply-To: <54D1450D.7050609@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 03 Feb 2015 23:00:45 +0100") References: <54CFBFFE.8070506@guardianproject.info> <87iofjnuei.fsf@vigenere.g10code.de> <54D1450D.7050609@guardianproject.info> Message-ID: <87h9v2m8uh.fsf@vigenere.g10code.de> On Tue, 3 Feb 2015 23:00, hans at guardianproject.info said: > installing pkg-config on the machine where it wasn't working. Updating the > Android build to use automake1.14 is probably non-trivial :-( Also, You need to do it at some point anyway. People have been complaining about not using 1.14 for a long time and thus with Jessie being close to a release I made the switch. 1.14 was released in June 2013. You may run sed 's/min_automake_version="1.14"/min_automake_version="1.13"/' on all configure files. It should work as well with 1.13 but given that I did not tested it I set the min version to 1.14. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 4 10:45:29 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Feb 2015 10:45:29 +0100 Subject: docs In-Reply-To: (Dave Pawson's message of "Mon, 5 Jan 2015 08:11:26 +0000") References: Message-ID: <87wq3yko1y.fsf@vigenere.g10code.de> On Mon, 5 Jan 2015 09:11, dave.pawson at gmail.com said: > You must run scripts/autogen.sh before doing the./configure scripts/ is from gnupg-1.4 but even there we have a wrapper thus ./autogen.sh works tehre too. I changed that. > script autgen.rc differs from this, having > final_info="./configure --sysconfdir=/etc --enable-maintainer-mode && make" I changed the wording to avoid the conflict. Actually --sysconfdir is an option and thus not required. However, I do not think that the use of /user/local/etc is a good idea and thus I always use this options. "./configure --help" briefly explains all options. Like --prefix, --sysconfdir is a standard configure option. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From leo at carotec.de Wed Feb 4 11:57:17 2015 From: leo at carotec.de (Carsten Leonhardt) Date: Wed, 04 Feb 2015 11:57:17 +0100 Subject: [PATCH] Make --enable-large-rsa work Message-ID: <87386meygi.fsf@arioch.leonhardt.eu> Hi, This patch makes --enable-large-rsa actually work for me, otherwise the dialogue doesn't allow a 8192 bit keysize to be entered. Carsten (re-sent as my first try seems to be stuck in the moderation queue) --- g10/keygen.c~ Fri Jan 30 17:55:11 2015 +++ g10/keygen.c Fri Jan 30 17:55:11 2015 @@ -1995,7 +1995,7 @@ static unsigned ask_keysize (int algo, unsigned int primary_keysize) { - unsigned int nbits, min, def = DEFAULT_STD_KEYSIZE, max=4096; + unsigned int nbits, min, def = DEFAULT_STD_KEYSIZE, max= (opt.flags.large_rsa ? 8192 : 4096); int for_subkey = !!primary_keysize; int autocomp = 0; From wk at gnupg.org Wed Feb 4 15:17:21 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Feb 2015 15:17:21 +0100 Subject: [PATCH] Make --enable-large-rsa work In-Reply-To: <87386meygi.fsf@arioch.leonhardt.eu> (Carsten Leonhardt's message of "Wed, 04 Feb 2015 11:57:17 +0100") References: <87386meygi.fsf@arioch.leonhardt.eu> Message-ID: <87bnl9lq1a.fsf@vigenere.g10code.de> On Wed, 4 Feb 2015 11:57, leo at carotec.de said: > This patch makes --enable-large-rsa actually work for me, otherwise the > dialogue doesn't allow a 8192 bit keysize to be entered. That is on purpose. From the commit log: Building with ./configure --enable-large-secmem will make gpg capable of working with those secret keys, as well as permitting the use of a new gpg option --enable-large-rsa, which let gpg generate RSA keys up to 8Kib when used with --batch --gen-key. ^^^^^^^^^^^^^^^^^ Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Feb 4 15:28:10 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 04 Feb 2015 09:28:10 -0500 Subject: [PATCH] Make --enable-large-rsa work In-Reply-To: <87386meygi.fsf@arioch.leonhardt.eu> References: <87386meygi.fsf@arioch.leonhardt.eu> Message-ID: <87vbjh7nut.fsf@alice.fifthhorseman.net> On Wed 2015-02-04 05:57:17 -0500, Carsten Leonhardt wrote: > This patch makes --enable-large-rsa actually work for me, otherwise the > dialogue doesn't allow a 8192 bit keysize to be entered. My understanding was that --enable-large-rsa enables creation of keysizes up to 8192 in --batch mode (i.e. for programmatic use by other tools), and enables the *use* of large RSA keys that otherwise might fail due to lack of allocated secure memory. I don't think the intent was to expose the size of 8192 to the normal user interface. --dkg From hans at guardianproject.info Fri Feb 6 13:32:36 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 06 Feb 2015 13:32:36 +0100 Subject: ./configure: line 9178: syntax error near unexpected token `LIBGNUTLS, ' In-Reply-To: <87h9v2m8uh.fsf@vigenere.g10code.de> References: <54CFBFFE.8070506@guardianproject.info> <87iofjnuei.fsf@vigenere.g10code.de> <54D1450D.7050609@guardianproject.info> <87h9v2m8uh.fsf@vigenere.g10code.de> Message-ID: <54D4B464.80404@guardianproject.info> Werner Koch: > On Tue, 3 Feb 2015 23:00, hans at guardianproject.info said: > >> installing pkg-config on the machine where it wasn't working. Updating the >> Android build to use automake1.14 is probably non-trivial :-( Also, > > You need to do it at some point anyway. People have been complaining > about not using 1.14 for a long time and thus with Jessie being close to > a release I made the switch. > > 1.14 was released in June 2013. You may run > > sed 's/min_automake_version="1.14"/min_automake_version="1.13"/' > > on all configure files. It should work as well with 1.13 but given that > I did not tested it I set the min version to 1.14. I know messing with the build system is not fun work, and can be a time sink. Ideally, it would be compatible with both 1.11 and 1.14. Is that not possible? Otherwise, I guess I have to wait for Debian/jessie to come out, or we find some new GPG-Android funding to do a real update. At least 2.1.1 seems to be mostly working on Android. I'm doing GPG-Android updates here and there on my own time these days. I know you know all about that :). .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 From aheinecke at intevation.de Fri Feb 6 15:01:30 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 06 Feb 2015 15:01:30 +0100 Subject: ./configure: line 9178: syntax error near unexpected token `LIBGNUTLS, ' In-Reply-To: <54D4B464.80404@guardianproject.info> References: <54CFBFFE.8070506@guardianproject.info> <87h9v2m8uh.fsf@vigenere.g10code.de> <54D4B464.80404@guardianproject.info> Message-ID: <5067729.h1tDoQLT16@esus> Hi, On Friday, February 06, 2015 01:32:36 PM Hans-Christoph Steiner wrote: > I know messing with the build system is not fun work, and can be a time > sink. > > Ideally, it would be compatible with both 1.11 and 1.14. Is that not > possible? Otherwise, I guess I have to wait for Debian/jessie to come out, > or we find some new GPG-Android funding to do a real update. At least > 2.1.1 seems to be mostly working on Android. I'm doing GPG-Android updates > here and there on my own time these days. I know you know all about that > :). For what it's worth I've packaged automake-1.14 for wheezy as part of our gnupg2.1 packaging. Nothing fancy, I just took the automake package from ubuntu 14.4 (which I am running) renamed the package to automake1.14 and threw it in a wheezy pbuilder and changed the build dependency in the gnupg2 package to automake1.14 Source and binaries are available under: http://apt.intevation.org/dists/wheezy/gnupg/ Maybe it helps. Regards Andre -- Andre Heinecke | ++49-541-335083-262 | 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: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From hans at guardianproject.info Fri Feb 6 16:52:13 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 06 Feb 2015 16:52:13 +0100 Subject: ./configure: line 9178: syntax error near unexpected token `LIBGNUTLS, ' In-Reply-To: <5067729.h1tDoQLT16@esus> References: <54CFBFFE.8070506@guardianproject.info> <87h9v2m8uh.fsf@vigenere.g10code.de> <54D4B464.80404@guardianproject.info> <5067729.h1tDoQLT16@esus> Message-ID: <54D4E32D.5020301@guardianproject.info> Andre Heinecke: > Hi, > > On Friday, February 06, 2015 01:32:36 PM Hans-Christoph Steiner wrote: >> I know messing with the build system is not fun work, and can be a time >> sink. >> >> Ideally, it would be compatible with both 1.11 and 1.14. Is that not >> possible? Otherwise, I guess I have to wait for Debian/jessie to come out, >> or we find some new GPG-Android funding to do a real update. At least >> 2.1.1 seems to be mostly working on Android. I'm doing GPG-Android updates >> here and there on my own time these days. I know you know all about that >> :). > > For what it's worth I've packaged automake-1.14 for wheezy as part of our > gnupg2.1 packaging. Nothing fancy, I just took the automake package from > ubuntu 14.4 (which I am running) renamed the package to automake1.14 and threw > it in a wheezy pbuilder and changed the build dependency in the gnupg2 package > to automake1.14 > > Source and binaries are available under: > http://apt.intevation.org/dists/wheezy/gnupg/ > > Maybe it helps. > > Regards > Andre That would be worth a lot as an official backport. I'm a DD, so I can upload that if someone wants to take it on. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Feb 9 20:53:46 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 9 Feb 2015 14:53:46 -0500 Subject: (Off-topic) Packaging Message-ID: I maintain a couple of small libre tools that are in use in the digital forensics community, and there?s been some interest in getting them packaged up as .debs and .rpms. Unfortunately, this is a skill that I haven?t really picked up. There are a lot of resources available online, some quite new and some quite old, and some that are infuriatingly incomplete (like the two days I spent trying to generate GnuPG signatures for an RPM, only to discover that for some reason RPM refuses to support DSA keys and none of the resources I was checking documented this). There are a fair number of people on this list who have recent experience with Debian and/or Fedora packaging. If you could please email me, *off-list*, with your recommendations for current, up-to-date, and useful documentation, I?d appreciate it quite a bit. Thank you all, and I apologize for the off-topic post. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3634 bytes Desc: not available URL: From hw42 at ipsumj.de Tue Feb 10 03:45:31 2015 From: hw42 at ipsumj.de (HW42) Date: Tue, 10 Feb 2015 03:45:31 +0100 Subject: restrict the set of accepted digest algorithms Message-ID: <54D970CB.7010906@ipsumj.de> Hi, is there an option to restrict the set of "accepted" (see below) set of digest algorithms (after searching the man page I don't think so)? The desired behavior would be that gnupg simply ignores signatures made with a algorithm not in the given set. For example I would like to restrict the set of "accepted" algorithms to SHA2 for code verification in a package manager like apt. HW42 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From calestyo at scientia.net Tue Feb 10 05:14:31 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Tue, 10 Feb 2015 05:14:31 +0100 Subject: restrict the set of accepted digest algorithms In-Reply-To: <54D970CB.7010906@ipsumj.de> References: <54D970CB.7010906@ipsumj.de> Message-ID: <1423541671.17478.51.camel@scientia.net> On Tue, 2015-02-10 at 03:45 +0100, HW42 wrote: > For example I would like to restrict the set of "accepted" algorithms to > SHA2 for code verification in a package manager like apt. I wouldn't think that you can reach *that* sepcific goal via restricting the accepted hash algos on the GPG side... at least not per se. The reason is how secure APT works (and note, that I'm not talking about debsigs). Secure APT, uses a single central "Release"[0] file per APT repository, as the root of all verification of further repo data (including the actual [source] packages). This, and only this, file is OpenPGP-signed and verified via gpg. All other files of the next level, these are for example the "Sources" and "Packages" files, are verified via hash sums in the Release files (which are secure, since the Release file was verified). These files in turn, contain hashes for the next level, which are e.g. the source packages or the binary packages. The syntax allows for different hash algos to be used in these files. Now comes the bad part: APT had (at least until recently) several bugs, in that it e.g. only verified MD5 (which has still a somewhat special status there, at least syntactically)... IIRC *that* specific issue was fixed some months ago, but I'm not sure about the general status. E.g. the "best" that current production files generated by the Debian repo servers contain is SHA256. In my opinion, APT should have some minimum set of algo(s) that it expects to be present (and if not, the target file should be considered forged). If the files would contain more hashes per target file, then *ALL* should be validated and if a single one doesn't verify, the target file should again be considered compromised. As said, I don't know about the current status, but I believe that this is *not* the case. Unfortunately Debian doesn't take security really very serious in that areas,... which shows also on the quite long validity times of the Release files, which in turn allows blocking/downgrading attacks. I've started several discussions on matters like these on debian-devel and opened bugs (e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752450)... but it's like fighting windmills and basically no one really cares. Probably also, why MD5 was used so long without an outcry :-( Cheers, Chris. [0] Technically there's an alternative "InRelease" but that's basically the same in green. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From hw42 at ipsumj.de Tue Feb 10 05:47:33 2015 From: hw42 at ipsumj.de (HW42) Date: Tue, 10 Feb 2015 05:47:33 +0100 Subject: restrict the set of accepted digest algorithms In-Reply-To: <1423541671.17478.51.camel@scientia.net> References: <54D970CB.7010906@ipsumj.de> <1423541671.17478.51.camel@scientia.net> Message-ID: <54D98D65.1010901@ipsumj.de> Christoph Anton Mitterer: > On Tue, 2015-02-10 at 03:45 +0100, HW42 wrote: >> For example I would like to restrict the set of "accepted" algorithms to >> SHA2 for code verification in a package manager like apt. > I wouldn't think that you can reach *that* sepcific goal via restricting > the accepted hash algos on the GPG side... at least not per se. > > The reason is how secure APT works (and note, that I'm not talking about > debsigs). > Secure APT, uses a single central "Release"[0] file per APT repository, > as the root of all verification of further repo data (including the > actual [source] packages). > This, and only this, file is OpenPGP-signed and verified via gpg. Yes I'm aware of this. My question here on gnupg-devel concerns only the gpg part. I mentioned apt just as one example. > All other files of the next level, these are for example the "Sources" > and "Packages" files, are verified via hash sums in the Release files > (which are secure, since the Release file was verified). > These files in turn, contain hashes for the next level, which are e.g. > the source packages or the binary packages. > > The syntax allows for different hash algos to be used in these files. > > > Now comes the bad part: > APT had (at least until recently) several bugs, in that it e.g. only > verified MD5 (which has still a somewhat special status there, at least > syntactically)... IIRC *that* specific issue was fixed some months ago, > but I'm not sure about the general status. > E.g. the "best" that current production files generated by the Debian > repo servers contain is SHA256. > > In my opinion, APT should have some minimum set of algo(s) that it > expects to be present (and if not, the target file should be considered > forged). > If the files would contain more hashes per target file, then *ALL* > should be validated and if a single one doesn't verify, the target file > should again be considered compromised. > > As said, I don't know about the current status, but I believe that this > is *not* the case. > > > Unfortunately Debian doesn't take security really very serious in that > areas,... which shows also on the quite long validity times of the > Release files, which in turn allows blocking/downgrading attacks. > I've started several discussions on matters like these on debian-devel > and opened bugs (e.g. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752450)... but it's > like fighting windmills and basically no one really cares. > Probably also, why MD5 was used so long without an outcry :-( > > > Cheers, > Chris. > > > [0] Technically there's an alternative "InRelease" but that's basically > the same in green. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Tue Feb 10 11:29:53 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 10 Feb 2015 11:29:53 +0100 Subject: restrict the set of accepted digest algorithms In-Reply-To: <54D970CB.7010906@ipsumj.de> References: <54D970CB.7010906@ipsumj.de> Message-ID: <8477083.KM56qnXf6u@inno> Am Di 10.02.2015, 03:45:31 schrieb HW42: > is there an option to restrict the set of "accepted" (see below) set > of digest algorithms (after searching the man page I don't think so)? That is not possible (in the general case and the one you are interested in) because the standard required SHA-1 to be accepted. But, of course, you are not required to use the exit code for a decision. Run gpg -v --status-fd 1 --verify and check the output for a line starting with "[GNUPG:] VALIDSIG". It if appears then the seventh field after VALIDSIG is the digest algo number. Check that against your set. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Tue Feb 10 16:15:08 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Feb 2015 10:15:08 -0500 Subject: gpg 2.1.1 --recv-key fails ("Input/output error") for a specific key Message-ID: <878ug5u7b7.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- One key from the public keyservers appears to cause gpg 2.1.1 to fail to import: 0 dkg at alice:~$ gpg2 --keyserver keys.gnupg.net --recv 0x99AB06246EEBF5A8 gpg: keyserver receive failed: Input/output error 2 dkg at alice:~$ This happens with hkps, with plain hkp, with the pool, and with all the different distinct keyservers i've tried. The same command is not a problem for gpg 1.4.x. Any thoughts about what's going on here? --dkg From hw42 at ipsumj.de Tue Feb 10 17:09:48 2015 From: hw42 at ipsumj.de (HW42) Date: Tue, 10 Feb 2015 17:09:48 +0100 Subject: restrict the set of accepted digest algorithms In-Reply-To: <8477083.KM56qnXf6u@inno> References: <54D970CB.7010906@ipsumj.de> <8477083.KM56qnXf6u@inno> Message-ID: <54DA2D4C.3090600@ipsumj.de> Hauke Laging: > Am Di 10.02.2015, 03:45:31 schrieb HW42: > >> is there an option to restrict the set of "accepted" (see below) set >> of digest algorithms (after searching the man page I don't think so)? > > That is not possible (in the general case and the one you are interested > in) because the standard required SHA-1 to be accepted. So you have a policy to not include options which can violate the OpenPGP standard? > But, of course, you are not required to use the exit code for a > decision. Run > > gpg -v --status-fd 1 --verify > > and check the output for a line starting with "[GNUPG:] VALIDSIG". It if > appears then the seventh field after VALIDSIG is the digest algo number. > Check that against your set. I'm aware of this possibility. It just require much more work than to add a cmdline parameter (or set an option in gpg.conf) for the software using GnuPG. Especially if I want to check certification chains. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From lists-gnupgdev at lina.inka.de Tue Feb 10 17:37:52 2015 From: lists-gnupgdev at lina.inka.de (lists-gnupgdev at lina.inka.de) Date: Tue, 10 Feb 2015 17:37:52 +0100 Subject: restrict the set of accepted digest algorithms In-Reply-To: <54DA2D4C.3090600@ipsumj.de> References: <54D970CB.7010906@ipsumj.de> <8477083.KM56qnXf6u@inno> <54DA2D4C.3090600@ipsumj.de> Message-ID: <20150210173752.00001f1d.ecki@lina.inka.de> Am Tue, 10 Feb 2015 17:09:48 +0100 schrieb HW42 : > Hauke Laging: > > Am Di 10.02.2015, 03:45:31 schrieb HW42: > > > >> is there an option to restrict the set of "accepted" (see below) > >> set of digest algorithms (after searching the man page I don't > >> think so)? > > > > That is not possible (in the general case and the one you are > > interested in) because the standard required SHA-1 to be accepted. > > So you have a policy to not include options which can violate the > OpenPGP standard? I dont wanted to say anything, but as it is repeatet here: this is not at all helpfull. If an outdated standard demands a security level which is not acceptable for a local application, there is really no use in enforcing it. I think this (quite widespread) attitude is one of the reasons GnuPG is less often used than it would be possible. (I am speaking about a social phenomen here). And yes it is good to ensure everybody who wants to communicate on the internet adhers to a common standard. (at least as long as the standard is reasonable current, which in case of OpenPGP becomes less and less true - think of missing curve support, of missing high-security profiles, of missing segmented encryption (for streaming authenticated usecases), missing EtM (instead of esoteric modes) or Curve25519/41417). But there are a lot of locally governed use cases where PGP format is used but with additional restrictions or extensions (I actually suspect such things (distribution file signing, file transfer applications) are more commonly used than email encryption). And most of those users are quite happy to define "we diverge from a standard which has not the right baseline for us". And switching of a cryptographic primitive without code change is really not that big of a sin or unusual requirement. (Just take a look on how long md5 was still in use). Gruss Bernd > > > But, of course, you are not required to use the exit code for a > > decision. Run > > > > gpg -v --status-fd 1 --verify > > > > and check the output for a line starting with "[GNUPG:] VALIDSIG". > > It if appears then the seventh field after VALIDSIG is the digest > > algo number. Check that against your set. > > I'm aware of this possibility. It just require much more work than to > add a cmdline parameter (or set an option in gpg.conf) for the > software using GnuPG. Especially if I want to check certification > chains. > > > From dkg at fifthhorseman.net Tue Feb 10 18:40:32 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Feb 2015 12:40:32 -0500 Subject: gpg 2.1.1 --recv-key fails ("Input/output error") for a specific key In-Reply-To: <878ug5u7b7.fsf@alice.fifthhorseman.net> References: <878ug5u7b7.fsf@alice.fifthhorseman.net> Message-ID: <87y4o5sm0f.fsf@alice.fifthhorseman.net> On Tue 2015-02-10 10:15:08 -0500, Daniel Kahn Gillmor wrote: > Hi GnuPG folks-- > > One key from the public keyservers appears to cause gpg 2.1.1 to fail to > import: > > 0 dkg at alice:~$ gpg2 --keyserver keys.gnupg.net --recv 0x99AB06246EEBF5A8 > gpg: keyserver receive failed: Input/output error > 2 dkg at alice:~$ > > This happens with hkps, with plain hkp, with the pool, and with all the > different distinct keyservers i've tried. The same command is not a > problem for gpg 1.4.x. Sorry, i take it back. this is a problem specifically with hkps fetches and this key. I hadn't realized that gpg2 --keyserver arguments were being ignored. I've been fetching other keys successfully with hkps://keys.mayfirst.org (with the appropriate hkp-cacert set in dirmngr.conf [0]), though; only this key is failing. I've tried to get other hkps session set up to test other servers, but have only had authentication failures with them :/ --dkg [0] https://support.mayfirst.org/attachment/wiki/faq/security/mfpl-certificate-authority/mfpl.crt From patrick at enigmail.net Tue Feb 10 18:44:31 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 10 Feb 2015 18:44:31 +0100 Subject: gpg 2.1: no error message if gpg-agent or pinentry fail Message-ID: <54DA437F.2020509@enigmail.net> If pinentry can't be launched, then gpg 2.0 will report an error saying something like "problem with gpg-agent". But if you try to decrypt a message with gpg 2.1 and pinentry doesn't work, then there is absolutely no error message. You simply see "missing key xyz" messages. This makes it very difficult to help people debug their setup (which happens quite frequently on Linux). I would therefore appreciate if there would at least be some human-readable error message; and even better a parse-able message. -Patrick From rjh at sixdemonbag.org Tue Feb 10 18:52:13 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Feb 2015 12:52:13 -0500 Subject: restrict the set of accepted digest algorithms In-Reply-To: <20150210173752.00001f1d.ecki@lina.inka.de> References: <54D970CB.7010906@ipsumj.de> <8477083.KM56qnXf6u@inno> <54DA2D4C.3090600@ipsumj.de> <20150210173752.00001f1d.ecki@lina.inka.de> Message-ID: <54DA454D.5030500@sixdemonbag.org> > I think this (quite widespread) attitude is one of the reasons GnuPG is > less often used than it would be possible. (I am speaking about a > social phenomen here). It's not. What fraction of computer users even know about GnuPG? Call that A. What fraction of GnuPG-aware users understand crypto enough to have a basic understanding? Call that B. What fraction of crypto-aware users can give an intelligent, informed opinion about the Standard's use of SHA-1 and whether that's a good thing? Call that C. What fraction of informed users with a strong opinion on the subject think the Standard's continued use of SHA-1 is a compelling reason to avoid it entirely, when there is no real alternative? (S/MIME has the exact same problem, after all; just worse.) Call that D. A * B * C * D = the fraction of the potential userbase you've alienated. B * C * D = the fraction of the current GnuPG userbase you've alienated. IMO, this is not an issue worth discussing. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From lists-gnupgdev at lina.inka.de Tue Feb 10 19:57:42 2015 From: lists-gnupgdev at lina.inka.de (lists-gnupgdev at lina.inka.de) Date: Tue, 10 Feb 2015 19:57:42 +0100 Subject: customizing PGP (was: restrict the set of accepted digest algorithms) In-Reply-To: <54DA454D.5030500@sixdemonbag.org> References: <54D970CB.7010906@ipsumj.de> <8477083.KM56qnXf6u@inno> <54DA2D4C.3090600@ipsumj.de> <20150210173752.00001f1d.ecki@lina.inka.de> <54DA454D.5030500@sixdemonbag.org> Message-ID: <20150210195742.00003ba7.ecki@lina.inka.de> Am Tue, 10 Feb 2015 12:52:13 -0500 schrieb "Robert J. Hansen" : > > I think this (quite widespread) attitude is one of the reasons > > GnuPG is less often used than it would be possible. (I am speaking > > about a social phenomen here). > > It's not. ... > A * B * C * D = the fraction of the potential userbase you've > alienated. I am not talking about users beeing alienated (by not allowing to tuen off SHA1), I am talking about developers beeing patronized on this list. This IMHO started way back when GPGME was "enforced" on them. And it repeats every time somebody want to contribute something modern (not covered by OpenPGP). But as I said, its just a feeling, but I dont think I am alone with that. And I am not sure if this is good or bad for the project (and sales orders of G10, for that matter). Pointing to "SHA-1 is mandatory in the standard" is IMHO really not a helpful answer (even when I personally don't think it is time to avoid it so strictly). Gruss Bernd From rjh at sixdemonbag.org Tue Feb 10 21:38:17 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Feb 2015 15:38:17 -0500 Subject: customizing PGP In-Reply-To: <20150210195742.00003ba7.ecki@lina.inka.de> References: <54D970CB.7010906@ipsumj.de> <8477083.KM56qnXf6u@inno> <54DA2D4C.3090600@ipsumj.de> <20150210173752.00001f1d.ecki@lina.inka.de> <54DA454D.5030500@sixdemonbag.org> <20150210195742.00003ba7.ecki@lina.inka.de> Message-ID: <54DA6C39.9010801@sixdemonbag.org> > I am not talking about users beeing alienated (by not allowing to > tuen off SHA1), I am talking about developers beeing patronized on > this list. Okay. If I were patronizing you I'd find some way to be conciliatory and to placate you. If you don't want patronizing, then I'm free to be blunt: Get over it. > This IMHO started way back when GPGME was "enforced" on them. If I want to interact with GnuPG in the Werner-approved way, I can. If I don't, I'm free to compile my own OpenPGP library out of the GnuPG codebase -- all that happens is Werner won't prepackage it for me in a convenient form. And really, why should he? If he disagrees with what I want to do and doesn't want to support it, he shouldn't be required to. And if I disagree with how he's managing GnuPG, I should be free to start a new version and steer it in the direction I wish. As it turns out, we're both free to do just those things. How is that 'enforcing' anything? > And it repeats every time somebody want to contribute something > modern (not covered by OpenPGP). That's because GnuPG implements the OpenPGP and S/MIME RFCs. No more, no less. If you want to extend GnuPG in a way that breaks OpenPGP, you're free to do so: the code is out there and you can use it as you wish (subject only to the GPL's requirements on code-sharing). But it's the height of hubris and arrogance to say, "I want to contribute something to GnuPG that will break OpenPGP compliance and you won't accept it, therefore you're alienating developers." And I say that as the guy on this list most often accused of having an ego the size of a small planet. > Pointing to "SHA-1 is mandatory in the standard" is IMHO really not a > helpful answer. The standard requires SHA-1 be present and that it be used in certain cases. If GnuPG deviates from that, GnuPG is no longer OpenPGP-conformant. GnuPG's entire mission statement is to be a conformant implementation of the OpenPGP and S/MIME standards. If that's unhelpful, then -- okay. I'm unhelpful. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From gniibe at fsij.org Wed Feb 11 15:58:28 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 11 Feb 2015 23:58:28 +0900 Subject: NeuG 1.0.1 Message-ID: <54DB6E14.7070209@fsij.org> Hello, Version 1.0.1 of NeuG has been released. NeuG is an implementation of True Random Number Generator based on sampling noise of ADC of STM32F103. Original intention of NeuG development was using it as a part of Gnuk, but we also have standalone USB CDC-ACM version. You can get random stream from /dev/ttyACM0 when connected to your host PC. Standalone version is useful to feed entropy to /dev/random on GNU/Linux. Its generation speed is >= 80kB/sec (kB = 1000-byte). The output has been tested NIST STS 2.1.1, Dieharder 3.31.1 and PractRand 0.92. * Upgrade of Chopstx (the thread library) Now, we use Chopstx 0.04. * Upgrade of Fraucheky (the GPL container) Furoshiki is traditional Japanese way of wrapping things. Fraucheky is a GPL container which makes sure to deliver GPL to users. Now, we use Fraucheky 0.1. * Compile options We use -O3 (with no -Os) for neug.o and sha256.o. Links ===== NeuG (under Gnuk Repository): http://gitorious.org/gnuk/neug FST-01 support pages: http://www.gniibe.org/category/fst-01.html FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 True Random Number Generators - FST-01 - Well Tempered Hacker: https://www.youtube.com/watch?v=iDuhLQ43tvQ Gnuk Mailing List: https://lists.alioth.debian.org/mailman/listinfo/gnuk-users Thanks to Anders Brownworth for the movie. -- From wk at gnupg.org Wed Feb 11 20:40:39 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Feb 2015 20:40:39 +0100 Subject: [Announce] GnuPG 2.1.2 released Message-ID: <874mqs2q4o.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of the third release of GnuPG modern: Version 2.1.2. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about the first release of this version. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in GnuPG-2.1 ======================= * gpg: The parameter 'Passphrase' for batch key generation works again. * gpg: Using a passphrase option in batch mode now has the expected effect on --quick-gen-key. * gpg: Improved reporting of unsupported PGP-2 keys. * gpg: Added support for algo names when generating keys using --command-fd. * gpg: Fixed DoS based on bogus and overlong key packets. * agent: When setting --default-cache-ttl the value for --max-cache-ttl is adjusted to be not lower than the former. * agent: Fixed problems with the new --extra-socket. * agent: Made --allow-loopback-pinentry changeable with gpgconf. * agent: Fixed importing of unprotected openpgp keys. * agent: Now tries to use a fallback pinentry if the standard pinentry is not installed. * scd: Added support for ECDH. * Fixed several bugs related to bogus keyrings and improved some other code. A detailed description of the changes found in 2.1 can be found at https://gnupg.org/faq/whats-new-in-2.1.html . Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.1.2 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at https://gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.2.tar.bz2 (4720k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.2.tar.bz2.sig This is the GnuPG 2.1 source code compressed using BZIP2 and its OpenPGP signature. A Windows installer is not available for this version because we are currently reworking some parts of it. This version fixes a lot of bugs found after the release of 2.1.0 but there are still known bugs which we are working on. Please check the mailing list archives and https://wiki.gnupg.org for known problems and workaround. Checking the Integrity ====================== 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 version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.2.tar.bz2 you would use this command: gpg --verify gnupg-2.1.2.tar.bz2.sig gnupg-2.1.2.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.1.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.2.tar.bz2 and check that the output matches the first line from the following list: 7e972cb9af47d9b8ce164dcf37fc4f32634d6cd6 gnupg-2.1.2.tar.bz2 Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2061 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow postings at https://gnupg.org/blob/. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Since the start of the funding campaign in December several thousand people have been kind enough to donate a total of 250000 Euro to support this project. In addition the Linux Foundation gave a grant of $ 60000 for 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. I am amazed by this superb and unexpected support for the GnuPG project. This will not only allow us to continue the project and hire at least a second full time developer but gives us also the resources to improve things which have been delayed for too long. *Thank you all !* Salam-Shalom, Werner p.s. This is a announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing lists. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 wk at gnupg.org Thu Feb 12 13:54:39 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Feb 2015 13:54:39 +0100 Subject: customizing PGP In-Reply-To: <54DA6C39.9010801@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 10 Feb 2015 15:38:17 -0500") References: <54D970CB.7010906@ipsumj.de> <8477083.KM56qnXf6u@inno> <54DA2D4C.3090600@ipsumj.de> <20150210173752.00001f1d.ecki@lina.inka.de> <54DA454D.5030500@sixdemonbag.org> <20150210195742.00003ba7.ecki@lina.inka.de> <54DA6C39.9010801@sixdemonbag.org> Message-ID: <8761b7z3w0.fsf@vigenere.g10code.de> On Tue, 10 Feb 2015 21:38, rjh at sixdemonbag.org said: > The standard requires SHA-1 be present and that it be used in certain > cases. If GnuPG deviates from that, GnuPG is no longer > OpenPGP-conformant. GnuPG's entire mission statement is to be a > conformant implementation of the OpenPGP and S/MIME standards. To add on this: And allow decryption/verification of data created a long time ago - even in a distant future. This is the purpose of a standard. Look at the outcry of some after having removed PGP-2 support form 2.1. PGP-2 is really old and for various reasons (see discussions on this list) it was decided that removing it is a good idea as long as we keep on maintaining a version which supports PGP-2 keys. A few years back when PRZ was still in the PGP business he put quite some effort into convincing us implementors to comply with the standard and limit the number of different algorithms for the sake of better interoperability. Bernd you are asking to ignore the standard. If someone creates a signature using SHA-1, why should one be concerned? It is their decision to do that and you can't control that. You can't control either whether they have opened their box to the world by using inscure, broken, or backdoored software. The hardwired use of SHA-1 is not an immediate problem if you look at the attack tree. The major obstacle is that it slows down bulk encryption due to its use in the MDC. That can be changed but it will take some years before that can actually be used. I am actually keen to start working on an extesion to use OCB mode instead of CFB+MDC. Yes, I know that the use of the SHA-1 fingerprint in some OpenPGP features is a bit problematic but it is something we can live with for now. We keep on doing what we have ever done: Add new algorithms, deploy software implementing them and eventually start to use them. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Feb 13 01:17:47 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Feb 2015 19:17:47 -0500 Subject: customizing PGP In-Reply-To: <8761b7z3w0.fsf@vigenere.g10code.de> References: <54D970CB.7010906@ipsumj.de> <8477083.KM56qnXf6u@inno> <54DA2D4C.3090600@ipsumj.de> <20150210173752.00001f1d.ecki@lina.inka.de> <54DA454D.5030500@sixdemonbag.org> <20150210195742.00003ba7.ecki@lina.inka.de> <54DA6C39.9010801@sixdemonbag.org> <8761b7z3w0.fsf@vigenere.g10code.de> Message-ID: <87bnkyll5g.fsf@alice.fifthhorseman.net> On Thu 2015-02-12 07:54:39 -0500, Werner Koch wrote: > I am actually keen to start working on an extesion to use OCB mode > instead of CFB+MDC. I think this (or any other AEAD construction) would be a great thing. This very issue (and the possible vulnerabilities that go with it) came up recently on messaging at moderncrypto.org. If you have a draft or a start of one, i'd be happy to review it. --dkg From lists-gnupgdev at lina.inka.de Fri Feb 13 06:01:37 2015 From: lists-gnupgdev at lina.inka.de (lists-gnupgdev at lina.inka.de) Date: Fri, 13 Feb 2015 06:01:37 +0100 Subject: customizing PGP In-Reply-To: <8761b7z3w0.fsf@vigenere.g10code.de> References: <54D970CB.7010906@ipsumj.de> <8477083.KM56qnXf6u@inno> <54DA2D4C.3090600@ipsumj.de> <20150210173752.00001f1d.ecki@lina.inka.de> <54DA454D.5030500@sixdemonbag.org> <20150210195742.00003ba7.ecki@lina.inka.de> <54DA6C39.9010801@sixdemonbag.org> <8761b7z3w0.fsf@vigenere.g10code.de> Message-ID: <20150213060137.00000f0a.ecki@lina.inka.de> Am Thu, 12 Feb 2015 13:54:39 +0100 schrieb Werner Koch : > Bernd you are asking to ignore the standard. No I dont. I am not even the OP. I was just commenting that there are other use cases besides strictly standard compliant communication. gpg already has enough options beside "the" standard. Thats what the --opengpg option is for anyway. There is simple no point to restrict gpg (the application) for a usecase where the standard is itself not fit for purpose anymore. Especially as it becomes somehow lesser relevant anyway. But sure, beeing standard compliant and making sure users do not produce junk (as it happend in the past with PGP over and over again) is one valid goal. It should just not be the only one. I think most users who have recognized that the focus of gpg is a different one have moved on (for example I am quite happily using BC for example (but this is also due to the better java integration). Gruss Bernd From adament at adament.net Fri Feb 13 13:30:50 2015 From: adament at adament.net (Adam Ehlers Nyholm Thomsen) Date: Fri, 13 Feb 2015 13:30:50 +0100 Subject: Problems with HKPS pools (GPG 2.1.1) Message-ID: <20150213123050.GA13645@adament-laptop.imf.au.dk> Dear GnuPG developers, I tried setting my keyserver to hkps.pool.sks-keyservers.net and most times when trying to refresh keys I got: gpg: refreshing 12 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: General error Activating debugging for dirmngr there seemed to be a number of different reasons for this, depending on which server dirmngr chose to contact. However most of these seemede to be related to hostname verification. Would it be possible to give a more meaningful error message so that this would be clearer to the user? Another seemed to be that dirmngr insisted on contacting the same server the whole time. Is this intended behaviour? Would it maybe be reasonable for dirmngr after a certain number of hostname verification errors to give up and try another server? I ended up killing gpg-agent and dirmngr and relaunching them a number of times. Every once in a while it would pick a good server and then everything worked. Regards, Adam Ehlers Nyholm Thomsne -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 13 15:08:50 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 13 Feb 2015 15:08:50 +0100 Subject: Problems with HKPS pools (GPG 2.1.1) In-Reply-To: <20150213123050.GA13645@adament-laptop.imf.au.dk> References: <20150213123050.GA13645@adament-laptop.imf.au.dk> Message-ID: <54DE0572.8020901@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/13/2015 01:30 PM, Adam Ehlers Nyholm Thomsen wrote: > Dear GnuPG developers, > Hi Adam, > I tried setting my keyserver to hkps.pool.sks-keyservers.net and > most times when trying to refresh keys I got: > > gpg: refreshing 12 keys from hkps://hkps.pool.sks-keyservers.net > gpg: keyserver refresh failed: General error > > Activating debugging for dirmngr there seemed to be a number of > different reasons for this, depending on which server dirmngr chose > to contact. However most of these seemede to be related to > hostname verification. Would it be possible to give a more > meaningful error message so that this would be clearer to the > user? > Indeed, in particular the PTR lookup causes issues with hostname validation as well as SNI. This has been discussed previously a few times [0,1,2] and is on the roadmap for fixes in 2.1 [3] References: [0] http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028458.html [1] http://lists.gnupg.org/pipermail/gnupg-users/2014-December/051901.html [2] http://lists.gnupg.org/pipermail/gnupg-users/2014-November/051471.html [3] https://gnupg.org/roadmap.html - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Ab esse ad posse - From being to knowing -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU3gVpAAoJEP7VAChXwav6+KcH/AzfhB9XDn+lBqehxLillbtR s+UPNurxeKpHoZEJLmbnTK1hVgNOz+54Kr55Qsz1Fp6UmunNOR31++44xtV67lcF S7NW4aC3C/u7bV0FzUox2xj60cBn7OmQDLvH78JwCoMVG9WNyJXFGD67KJ1qSNeV 5VGmUfIOT6Wn1KnDKqPPgHfm6zr2+yubsU9ETG/LjVSDW17Q/7P4kwxNxvgwQivI SbhoniSY6hf3jpC/VIU3Q6MNiC7S/wcQv1deyx8TahF/ZuE6WKR+DRZ2+VH1D208 zdAhiMqKg6APbPjlOLsdvnpbVciwx78fDqoW/1UPoThTY5nB5dAhHB1k78LbSTw= =ey8W -----END PGP SIGNATURE----- From wk at gnupg.org Fri Feb 13 20:25:35 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Feb 2015 20:25:35 +0100 Subject: customizing PGP In-Reply-To: <87bnkyll5g.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 12 Feb 2015 19:17:47 -0500") References: <54D970CB.7010906@ipsumj.de> <8477083.KM56qnXf6u@inno> <54DA2D4C.3090600@ipsumj.de> <20150210173752.00001f1d.ecki@lina.inka.de> <54DA454D.5030500@sixdemonbag.org> <20150210195742.00003ba7.ecki@lina.inka.de> <54DA6C39.9010801@sixdemonbag.org> <8761b7z3w0.fsf@vigenere.g10code.de> <87bnkyll5g.fsf@alice.fifthhorseman.net> Message-ID: <87vbj5txzk.fsf@vigenere.g10code.de> On Fri, 13 Feb 2015 01:17, dkg at fifthhorseman.net said: > up recently on messaging at moderncrypto.org. If you have a draft or a > start of one, i'd be happy to review it. I plan to do that but first 2.1 needs to get more stable. And I have to do maintenance release of 1.4 and 2.0 too. I am currently working on 2.0. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Feb 13 20:33:31 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Feb 2015 20:33:31 +0100 Subject: customizing PGP In-Reply-To: <20150213060137.00000f0a.ecki@lina.inka.de> (lists-gnupgdev@lina.inka.de's message of "Fri, 13 Feb 2015 06:01:37 +0100") References: <54D970CB.7010906@ipsumj.de> <8477083.KM56qnXf6u@inno> <54DA2D4C.3090600@ipsumj.de> <20150210173752.00001f1d.ecki@lina.inka.de> <54DA454D.5030500@sixdemonbag.org> <20150210195742.00003ba7.ecki@lina.inka.de> <54DA6C39.9010801@sixdemonbag.org> <8761b7z3w0.fsf@vigenere.g10code.de> <20150213060137.00000f0a.ecki@lina.inka.de> Message-ID: <87r3tttxmc.fsf@vigenere.g10code.de> On Fri, 13 Feb 2015 06:01, lists-gnupgdev at lina.inka.de said: > gpg already has enough options beside "the" standard. Thats what the > --opengpg option is for anyway. There is one standard but there are things which are open for interpretation. All the compatibility options still create valid OpenPGP data but in a way that for example PGP-6 can work with it. > There is simple no point to restrict gpg (the application) for a > usecase where the standard is itself not fit for purpose anymore. > Especially as it becomes somehow lesser relevant anyway. So you think that S/MIME (CMS+X.509) is more up to the task? Having implemented both I doubt that that but your mileage may very. I am not aware of any other encryption standard for offline communcation. > different one have moved on (for example I am quite happily using BC > for example (but this is also due to the better java integration). BC? bc (1) - An arbitrary precision calculator language I don't understand. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Feb 13 20:36:38 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Feb 2015 20:36:38 +0100 Subject: Problems with HKPS pools (GPG 2.1.1) In-Reply-To: <20150213123050.GA13645@adament-laptop.imf.au.dk> (Adam Ehlers Nyholm Thomsen's message of "Fri, 13 Feb 2015 13:30:50 +0100") References: <20150213123050.GA13645@adament-laptop.imf.au.dk> Message-ID: <87mw4htxh5.fsf@vigenere.g10code.de> On Fri, 13 Feb 2015 13:30, adament at adament.net said: > I tried setting my keyserver to hkps.pool.sks-keyservers.net and most > times when trying to refresh keys I got: There are known problems with 21. > I ended up killing gpg-agent and dirmngr and relaunching them a number > of times. Every once in a while it would pick a good server and then You may instead do this: gpg-connect-agent --dirmngr > keyserver --resolve > bye also try "help keyserver". Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at peterkrantz.se Fri Feb 13 20:18:10 2015 From: peter at peterkrantz.se (Peter Krantz) Date: Fri, 13 Feb 2015 20:18:10 +0100 Subject: [PATCH] Minor swedish translations Message-ID: <45594B75-AB17-4D65-AA54-7DD2B7FB6924@peterkrantz.se> Hi! Here are som additional strings in swedish that were untranslated. -------------- next part -------------- A non-text attachment was scrubbed... Name: minor_swedish_translations.patch Type: application/octet-stream Size: 2017 bytes Desc: not available URL: -------------- next part -------------- Regards, Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hanno at hboeck.de Fri Feb 13 21:31:22 2015 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Fri, 13 Feb 2015 21:31:22 +0100 Subject: Multiple issues in GnuPG found through keyring fuzzing (TFPA 001/2015) Message-ID: <20150213213122.6d67c2a0@pc> Advisory published here: https://blog.fuzzing-project.org/5-Multiple-issues-in-GnuPG-found-through-keyring-fuzzing-TFPA-0012015.html A complex tool like GnuPG has many ways to parse input data. I previously had fuzzed GnuPG which had led to the detection of a Buffer Overflow vulnerability in GnuPG and libksba (CVE-2014-9087). Recently I tried to fuzz less obvious inputs of GnuPG: Keyrings and configuration files. GnuPG allows to specify a non-standard keyring on the command line. Fuzzing GPG with gpg --export --no-default-keyring --keyring [input keyring] led to the detection of various issues. (Please note that the keyring parameter needs the full path and does not like filenames with unusual characters like the ones generated by american fuzzy lop.) NULL pointer deref in parse_trust (parse-packet.c) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=39978487863066e59bb657f5fe4e8baab510da7e https://crashes.fuzzing-project.org/TFPA-2015-01-gnupg-keyring-null-ptr-1 NULL pointer deref in do_key (build-packet.c) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=0835d2f44ef62eab51fce6a927908f544e01cf8f https://crashes.fuzzing-project.org/TFPA-2015-01-gnupg-keyring-null-ptr-2 Use after free (build-packet.c) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=f0f71a721ccd7ab9e40b8b6b028b59632c0cc648 https://crashes.fuzzing-project.org/TFPA-2015-01-gnupg-keyring-use-after-free memcpy with overlapping ranges (keybox_search.c) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=2183683bd633818dd031b090b5530951de76f392 https://crashes.fuzzing-project.org/TFPA-2015-01-gnupg-keyring-memcpy-overlap All issues found with american fuzzy lop. Fuzzing of the configuration file parser showed no issues. While keyrings are usually not user-submitted data, some of these can be reached through other code paths. None of the issues looks severe, however judging the exact security would require further analysis. Timeline: 2015-02-06 Reported three issues to GnuPG developer Werner Koch 2015-02-09 ALl reported issues fixed in git 2015-02-09 Reported one more issue to Werner Koch 2015-02-11 Last issue fixed in git 2015-02-11 Release of GnuPG 2.1.2 containing all fixes -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From aixtools at gmail.com Sun Feb 15 12:16:58 2015 From: aixtools at gmail.com (Michael Felt) Date: Sun, 15 Feb 2015 12:16:58 +0100 Subject: GNUPG 2.* and AIX - questions Message-ID: This is not a bug report. Short history - I have tried to package gnupg several times, the gunpg v1.* has never been difficult - and maybe I shall just leave it at that. My key question is about the difference between v1.X and v2.X - are there security elements in v2 that are missing/weaker in v1 - or are the differences mainly that v2 supports/is always GUI while v1 is always CLI. Background info... The first wall I run into with gnupg-2.0.26 is that it wants gnu threads - so, the question is: is there something inherently wrong with POSIX threads, or even specifically with AIX pthreads that configure does not attempt to use them (by default). I took the hint and tried to package gnu/nth but make fails - immediately - with this message. root at x064:[/data/prj/gnu/pth/pth-2.0.7]make ./libtool --mode=compile --quiet cc -c -I. pth_debug.c "pth.h", line 93.2: 1506-205 (S) #error "FD_SETSIZE is larger than what GNU Pth can handle." make: *** [pth_debug.lo] Error 1 root at x064:[/data/prj/gnu/pth/pth-2.0.7] For extra info: root at x064:[/data/prj/gnu/pth/pth-2.0.7]grep FD_SETSIZE *.h pth.h: /* check if the user requests a bigger FD_SETSIZE than we can handle */ pth.h:#if defined(FD_SETSIZE) pth.h:#if FD_SETSIZE > 1024 pth.h:#error "FD_SETSIZE is larger than what GNU Pth can handle." pth_p.h:#if !defined(FD_SETSIZE) pth_p.h:#define FD_SETSIZE 1024 # AIX 5.3 so anno 2009 root at x064:[/data/prj/gnu/pth/pth-2.0.7]grep FD_SETSIZE /usr/include/*.h /usr/include/sys/*.h /usr/include/sys/time.h: * FD_SETSIZE may be defined by the user to the maximum valued file /usr/include/sys/time.h:#ifndef FD_SETSIZE /usr/include/sys/time.h:#define FD_SETSIZE 65534 /usr/include/sys/time.h:/* Number of entries needed for FD_SETSIZE open files */ /usr/include/sys/time.h:#define __NUM_ENTRIES (FD_SETSIZE/__NFDBITS+1) Again, this is NOT a bug-report. I have never seen gnupg 2.0 (so maybe it is all GUI related, when all I am really interested in is security abilities). Thank your for your time. Michael p.s. please forgive the cross post to @devel - not sure which is the best list for this question. -------------- next part -------------- An HTML attachment was scrubbed... URL: From micah at riseup.net Tue Feb 17 18:35:09 2015 From: micah at riseup.net (micah anderson) Date: Tue, 17 Feb 2015 12:35:09 -0500 Subject: gpg2 keytocard removes secret key Message-ID: <87oaossape.fsf@muck.riseup.net> Hello, In the world of gpg1, there were three ways of handling smartcard secret key material. You could generate the material on the card itself; you could generate it on your computer and then move it to the smartcard so it is no longer on your computer; you could generate it on your computer, but keep the secret key material on your computer (for whatever reason). Obviously, some methods are better than others, for different reasons. There are likely other methods as well. To move the secret key material to the card, removing it from the computer, you would simply do a 'keytocard' operation, and then quit and save. In order to keep the secret key material on the computer, you would do the same operation, but this time you would *not* save when you quit. There are a number of tutorials out there that describe this step as the way to do it. I discovered yesterday that this third method does not work with gpg2, when you do the 'keytocard' operation, the secret key material is removed, you do not have the ability to opt-out of the saving process. Was this an intentional change in gpg2? I am unsure if it is a regression/bug, or if it was an intentional change. If it was intentional, then it is a bit surprising for people who are coming from the gpg1 world with the knowledge that their secret key would not be removed (or who were following a tutorial that said this would not happen, and then it does). While I support pushing people towards not storing that secret key material on the PC, I think this violates the law of least astonishment for people coming from gpg1, and the rule of clarity ("Clarity is better than cleverness"): if this is going to make these secret keys no longer available on your computer, without that smartcard present, you should be told this. Perhaps a giant warning asking you to confirm, would help people not lose their secret key material Fortunately, when I was doing this, I had backups... ! micah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From gniibe at fsij.org Wed Feb 18 01:26:30 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 18 Feb 2015 09:26:30 +0900 Subject: 2.1.x regression (Re: gpg2 keytocard removes secret key) In-Reply-To: <87oaossape.fsf@muck.riseup.net> References: <87oaossape.fsf@muck.riseup.net> Message-ID: <54E3DC36.6050406@fsij.org> On 02/18/2015 02:35 AM, micah anderson wrote: > To move the secret key material to the card, removing it from the > computer, you would simply do a 'keytocard' operation, and then quit and > save. In order to keep the secret key material on the computer, you > would do the same operation, but this time you would *not* save when you > quit. There are a number of tutorials out there that describe this step > as the way to do it. > > I discovered yesterday that this third method does not work with gpg2, > when you do the 'keytocard' operation, the secret key material is > removed, you do not have the ability to opt-out of the saving process. Sorry, my badness. It is obviously a regression of 2.1.x. Note that it works with 2.0, as gpg1. An excuse. From 2.0 to 2.1, there was a major architectural change which moved private keys handling to gpg-agent. Then, the feature of "keytocard" was lost and it had been unimplemented (somehow longer) during 2.1 development. It was a kind of the last unimplemented feature of 2.1 which blocked the release. A year ago, I managed to implement the feature back by the commits: b90506ea220860c89128f002bd593d0462a08d73 30f8a3c8736451d8c06ef72521a8da5eabf23016 But I forgot about the third case. No, this is not correct description. Now, I can remember that I clearly recognized this particular regression once or twice, and I knew the exact reason. But it was buried into under my unconscious world. Then, I made myself blind to this regression. To support the third case, it would be required to add another command (or two) in gpg-agent. But, I think that it's worth to do that. Meanwhile... > Perhaps a giant warning asking you to confirm, would help people not > lose their secret key material this make sense now, at least. > Fortunately, when I was doing this, I had backups... ! Good. I opened the issue here to track: https://bugs.g10code.com/gnupg/issue1846 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Feb 18 10:11:31 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 18 Feb 2015 04:11:31 -0500 Subject: [PATCH] curl-shim: clean up varargs Message-ID: <1424250691-31497-1-git-send-email-dkg@fifthhorseman.net> * keyserver/curl-shim.c (curl_easy_setopt) : ensure that va_end is called. -- stdarg(3) says: Each invocation of va_start() must be matched by a corresponding invocation of va_end() in the same function. Observed by Joshua Rogers Debian-Bug-Id: #773475 --- keyserver/curl-shim.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/keyserver/curl-shim.c b/keyserver/curl-shim.c index 696efe2..dc380eb 100644 --- a/keyserver/curl-shim.c +++ b/keyserver/curl-shim.c @@ -164,6 +164,8 @@ curl_easy_setopt(CURL *curl,CURLoption option,...) break; } + va_end(ap); + return handle_error(curl,CURLE_OK,NULL); } -- 2.1.4 From wk at gnupg.org Wed Feb 18 12:27:39 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 12:27:39 +0100 Subject: [PATCH] curl-shim: clean up varargs In-Reply-To: <1424250691-31497-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 18 Feb 2015 04:11:31 -0500") References: <1424250691-31497-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87lhjvlas4.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 10:11, dkg at fifthhorseman.net said: > * keyserver/curl-shim.c (curl_easy_setopt) : ensure that va_end is > called. That was right in time for the next 2.0 release. Thanks to Joshua Rogers and you. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 18 12:33:31 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 12:33:31 +0100 Subject: [PATCH] Minor swedish translations In-Reply-To: <45594B75-AB17-4D65-AA54-7DD2B7FB6924@peterkrantz.se> (Peter Krantz's message of "Fri, 13 Feb 2015 20:18:10 +0100") References: <45594B75-AB17-4D65-AA54-7DD2B7FB6924@peterkrantz.se> Message-ID: <87h9ujlaic.fsf@vigenere.g10code.de> On Fri, 13 Feb 2015 20:18, peter at peterkrantz.se said: > Here are som additional strings in swedish that were untranslated. For which branch is that? I'd also like to ask that you use git format-patch so that I can easier apply it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 18 16:29:12 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 16:29:12 +0100 Subject: [Announce] GnuPG 2.0.27 "stable" released Message-ID: <87ioezi6gn.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.27. This is a maintenance release which fixes a couple of bugs. Update to this version is suggested. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. - GnuPG "stable" (2.0) - which this is about - is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in 2.0.27 ==================== * gpg: Detect faulty use of --verify on detached signatures. * gpg: New import option "keep-ownertrust". * gpg: Uses SHA-256 for all signature types also on RSA keys. * gpg: Added support for algo names when generating keys using the --command-fd method. * gpg: Unless --allow-weak-digest-algos is used the insecure MD5 based fingerprints are shown as all zeroe * gpg: Fixed DoS based on bogus and overlong key packets. * gpg: Better error reporting for keyserver problems. * Fixed several bugs related to bogus keyrings and improved some other code. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.0.27 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at https://gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org and on its mirrors you should find the following new files in the gnupg/ directory: - The GnuPG source code compressed using BZIP2 and its OpenPGP signature: gnupg-2.0.27.tar.bz2 (4321k) gnupg-2.0.27.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs for GnuPG-2. A Windows version will eventually be released at https://gpg4win.org . If you are new to GnuPG please consider to use the "modern" version 2.1.2. Checking the Integrity ====================== 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 version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.0.27.tar.bz2 you would use this command: gpg --verify gnupg-2.0.27.tar.bz2.sig gnupg-2.0.27.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.1.tar.bz2, you would run the command like this: sha1sum gnupg-2.0.27.tar.bz2 and check that the output matches the next line: d065be185f5bac8ea07b210ab7756e79b83b63d4 gnupg-2.0.27.tar.bz2 Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 using an already installed version of gpg. Remeber to check the fingerprints against the above list (which you also find on the flip side of our printed visit cards). The keys are also available at https://gnupg.org/signature_key.html and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Documentation ============= The file gnupg.info has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at https://www.gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://www.gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: https://www.gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software takes up most of their resources. To allow him to continue this work he kindly asks to either purchase a support contract, engage g10 Code for custom enhancements, or to donate money: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Since the start of the funding campaign in December several thousand people have been kind enough to donate a total of 250000 Euro to support this project. In addition the Linux Foundation gave a grant of $ 60000 for 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. I am amazed by this superb and unexpected support for the GnuPG project. This will not only allow us to continue the project and hire at least a second full time developer but gives us also the resources to improve things which have been delayed for too long. *Thank you all !* Shalom-Salam, Werner p.s. This is a announcement only mailing list. Please send replies only to the gnupg-users 'at' gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 guilhem at fripost.org Wed Feb 18 21:18:17 2015 From: guilhem at fripost.org (Guilhem Moulin) Date: Wed, 18 Feb 2015 21:18:17 +0100 Subject: [PATCH] keyedit.c: Replace calls to printf by es_printf. Message-ID: <1424290697-19070-1-git-send-email-guilhem@fripost.org> Needed for unattended key edits with --status-fd, because since 2.1 status prompts are preceded by es_fflush (in cpr.c:do_get_from_fd) not fflush(3), so the standard output may not be flushed before each prompt. (Which breaks scripts using select(2) to multiplex between the standard and status outputs.) --- g10/keyedit.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/g10/keyedit.c b/g10/keyedit.c index f283e55..db62407 100644 --- a/g10/keyedit.c +++ b/g10/keyedit.c @@ -158,22 +158,22 @@ print_and_check_one_sig_colon (KBNODE keyblock, KBNODE node, if (sigrc != '?' || print_without_key) { - printf ("sig:%c::%d:%08lX%08lX:%lu:%lu:", + es_printf ("sig:%c::%d:%08lX%08lX:%lu:%lu:", sigrc, sig->pubkey_algo, (ulong) sig->keyid[0], (ulong) sig->keyid[1], (ulong) sig->timestamp, (ulong) sig->expiredate); if (sig->trust_depth || sig->trust_value) - printf ("%d %d", sig->trust_depth, sig->trust_value); + es_printf ("%d %d", sig->trust_depth, sig->trust_value); - printf (":"); + es_printf (":"); if (sig->trust_regexp) es_write_sanitized (es_stdout, sig->trust_regexp, strlen (sig->trust_regexp), ":", NULL); - printf ("::%02x%c\n", sig->sig_class, + es_printf ("::%02x%c\n", sig->sig_class, sig->flags.exportable ? 'x' : 'l'); if (opt.show_subpackets) @@ -4732,14 +4732,14 @@ ask_revoke_sig (KBNODE keyblock, KBNODE node) if (opt.with_colons) { if (uid->attrib_data) - printf ("uat:::::::::%u %lu", uid->numattribs, uid->attrib_len); + es_printf ("uat:::::::::%u %lu", uid->numattribs, uid->attrib_len); else { - printf ("uid:::::::::"); + es_printf ("uid:::::::::"); es_write_sanitized (es_stdout, uid->name, uid->len, ":", NULL); } - printf ("\n"); + es_printf ("\n"); print_and_check_one_sig_colon (keyblock, node, NULL, NULL, NULL, NULL, 1); -- 2.1.4 From neal at walfield.org Wed Feb 18 21:36:24 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 18 Feb 2015 21:36:24 +0100 Subject: GNUPG 2.* and AIX - questions In-Reply-To: References: Message-ID: <87k2zfaref.wl%neal@walfield.org> At Sun, 15 Feb 2015 12:16:58 +0100, Michael Felt wrote: > My key question is about the difference between v1.X and v2.X - are there > security elements in v2 that are missing/weaker in v1 - or are the > differences mainly that v2 supports/is always GUI while v1 is always CLI. gpg2 is a more extensible rewrite of gpg classic. gpg2 supports some crypto algorithms that gpg does not support (e.g., ECC starting with version 2.1). gpg2 is still for the CLI and makes some CLI operations easier than gpg. > The first wall I run into with gnupg-2.0.26 is that it wants gnu threads - > so, the question is: is there something inherently wrong with POSIX > threads, or even specifically with AIX pthreads that configure does not > attempt to use them (by default). npth uses cooperative threading rather than preemptive threading. This has the advantage of simplifying code: if you don't explicitly yield (or use a function that yields), then you can't be preempted. This can significantly reduce synchronization bugs. Neal From wk at gnupg.org Thu Feb 19 11:41:28 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Feb 2015 11:41:28 +0100 Subject: GNUPG 2.* and AIX - questions In-Reply-To: (Michael Felt's message of "Sun, 15 Feb 2015 12:16:58 +0100") References: Message-ID: <87k2zefajr.fsf@vigenere.g10code.de> On Sun, 15 Feb 2015 12:16, aixtools at gmail.com said: > I took the hint and tried to package gnu/nth but make fails - immediately - > with this message. You might find something about this in bugs.gnupg.org. I have not tried gnupg 2.0.x on AIX for many years thus it is quite possible that you run into problems, possible due to newer AIX versions. However, GnuPG 2.1 builds and works fine on AIX. I even test it from time to time. Thus instead of settling on 2.0 you may want to jump directly jump from 1.4 to 2.1. 2.0 will be maintained for some times but probably not more than two years from now. > p.s. please forgive the cross post to @devel - not sure which is the best > list for this question. Both make sense ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From laurent at elanor.org Thu Feb 19 15:53:07 2015 From: laurent at elanor.org (Laurent Blume) Date: Thu, 19 Feb 2015 15:53:07 +0100 Subject: GnuPG 2.0.27 fails tests on Solaris 10 sparc Message-ID: <54E5F8D3.9050504@elanor.org> Hello, I'm having issues packaging 2.0.27 on Solaris 10 sparc: some tests are failing, for no clear reason. Here's the quick output: gmake[3]: Entering directory '/home/laurent/opencsw/gnupg2/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gnupg-2.0.27/common' /bin/bash: line 5: 17724 Abort (core dumped) ${dir}$tst FAIL: t-convert PASS: t-percent PASS: t-gettime PASS: t-sysutils PASS: t-sexputil max. file descriptors: 65536 open file descriptors: 3 PASS: t-exechelp Known envvars: GPG_TTY(ttyname) TERM(ttytype) DISPLAY(display) XAUTHORITY(xauthority) XMODIFIERS GTK_IM_MODULE QT_IM_MODULE PINENTRY_USER_DATA(pinentry-user-data) PASS: t-session-env /bin/bash: line 5: 17785 Abort (core dumped) ${dir}$tst FAIL: t-ssh-utils ====================================== 2 of 8 tests failed Please report to http://bugs.gnupg.org ====================================== Here's what I could gather: $ ../../g10/gpg2 --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc Warning: using insecure memory! Abort The bottom of a truss on the same command: 3206: llseek(5, 0, SEEK_SET) = 0 3206: read(5, "9901A204 ?F2 5\b1104\0BF".., 8192) = 8192 3206: read(5, "D8839901A204 6E3A2E21104".., 8192) = 8192 3206: read(5, " pB9EF8899D68C ZFC\r x |".., 8192) = 8192 3206: read(5, "96 &E8EDE297\r I12BD ?97".., 8192) = 8192 3206: llseek(4, 0, SEEK_SET) = 0 3206: llseek(4, 25746, SEEK_SET) = 25746 3206: read(4, "9901A204 6E3B5CB1104\081".., 8192) = 8192 3206: llseek(4, 0, SEEK_SET) = 0 3206: read(4, "9901A204 ?F2 5\b1104\0BF".., 8192) = 8192 3206: read(4, "D8839901A204 6E3A2E21104".., 8192) = 8192 3206: read(4, " pB9EF8899D68C ZFC\r x |".., 8192) = 8192 3206: read(4, "96 &E8EDE297\r I12BD ?97".., 8192) = 8192 3206: llseek(5, 0, SEEK_SET) = 0 3206: llseek(5, 25746, SEEK_SET) = 25746 3206: read(5, "9901A204 6E3B5CB1104\081".., 8192) = 8192 3206: close(3) = 0 3206: munmap(0xFF030000, 32768) = 0 3206: sigaction(SIGABRT, 0x00000000, 0xFFBFF2B0) = 0 3206: sigaction(SIGABRT, 0xFFBFF160, 0xFFBFF200) = 0 3206: sigfillset(0xFF35B3BC) = 0 3206: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF] 3206: lwp_kill(1, SIGABRT) = 0 3206: Received signal #6, SIGABRT [default] 3206: siginfo: SIGABRT pid=3206 uid=17160 code=-1 I'm not having issue with the same on Solaris 10 x86. Anything else I can do to diagnose this? Laurent From wk at gnupg.org Thu Feb 19 16:43:58 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Feb 2015 16:43:58 +0100 Subject: GnuPG 2.0.27 fails tests on Solaris 10 sparc In-Reply-To: <54E5F8D3.9050504@elanor.org> (Laurent Blume's message of "Thu, 19 Feb 2015 15:53:07 +0100") References: <54E5F8D3.9050504@elanor.org> Message-ID: <87sie1ewjl.fsf@vigenere.g10code.de> On Thu, 19 Feb 2015 15:53, laurent at elanor.org said: > I'm having issues packaging 2.0.27 on Solaris 10 sparc: some tests are > failing, for no clear reason. Did 2.0.26 build on the same machine? Maybe the Pth problem which has already been reported? > FAIL: t-convert Please run common/t-convert under a debugger and show the stack backtrace. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Feb 19 17:25:02 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Feb 2015 17:25:02 +0100 Subject: [PATCH] keyedit.c: Replace calls to printf by es_printf. In-Reply-To: <1424290697-19070-1-git-send-email-guilhem@fripost.org> (Guilhem Moulin's message of "Wed, 18 Feb 2015 21:18:17 +0100") References: <1424290697-19070-1-git-send-email-guilhem@fripost.org> Message-ID: <87oaopeun5.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 21:18, guilhem at fripost.org said: > Needed for unattended key edits with --status-fd, because since 2.1 > status prompts are preceded by es_fflush (in cpr.c:do_get_from_fd) not > fflush(3), so the standard output may not be flushed before each prompt. commit d2a70fd8348d6c11d1960caf2afe0701833dad6a Author: Werner Koch Date: Thu Feb 19 17:22:27 2015 +0100 gpg: Replace remaining uses of stdio by estream. * g10/sign.c (sign_file): Use log_printf instead of stderr. * g10/tdbdump.c (export_ownertrust): Use estream fucntions. (import_ownertrust): Ditto. * g10/tdbio.c (tdbio_dump_record): Ditto. Change arg to estream_t. -- Reported-by: Guilhem Moulin Needed for unattended key edits with --status-fd, because since 2.1 status prompts are preceded by es_fflush (in cpr.c:do_get_from_fd) not fflush(3), so the standard output may not be flushed before each prompt. (Which breaks scripts using select(2) to multiplex between the standard and status outputs.) His patch only affected print_and_check_one_sig_colon() but there are many more places where stdio and estream are mixed. This patch now replaces most of them in g10/. At some places stdio is still used, but that is local to a function and should not have side effects. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From laurent at elanor.org Thu Feb 19 22:22:41 2015 From: laurent at elanor.org (Laurent Blume) Date: Thu, 19 Feb 2015 22:22:41 +0100 Subject: GnuPG 2.0.27 fails tests on Solaris 10 sparc In-Reply-To: <87sie1ewjl.fsf@vigenere.g10code.de> References: <54E5F8D3.9050504@elanor.org> <87sie1ewjl.fsf@vigenere.g10code.de> Message-ID: <54E65421.3060804@elanor.org> On 19/02/2015 16:43, Werner Koch wrote: > > Did 2.0.26 build on the same machine? > > Maybe the Pth problem which has already been reported? I think it's actually related to this libgpg-error issue, which is still present in 1.18: http://lists.gnupg.org/pipermail/gnupg-devel/2014-December/029226.html Because I checked that an old 2.0.26 binary, which had passed the tests previously, is now having the symptoms. > > Please run common/t-convert under a debugger and show the stack > backtrace. > Can we have a look at this? Even if the problem is not the same, at this point, I'd rather get it out of the way if only to be sure. The current core looks the same as what it was then: $ file core core: ELF 32-bit MSB core file SPARC Version 1, from 't-printf' $ pstack core core 'core' of 29157: ./t-printf ff25c7fc __lwp_sigqueue (6, ffffffef, ffffffec, ffbff690, 5, 6) + 8 ff1db5ec abort (ff3540fc, ff2f0234, 6, 1, ff2f1b48, 0) + 108 ff3540c8 get_lock_object (ff36f4a4, ff353ac4, ff3578e0, ff3ee388, 1, c21) + 4 ff354100 _gpgrt_lock_lock (ff36f4a4, 0, 50, ff322a40, ffffffff, 0) + 4 ff3577d8 _gpgrt_fflush (0, ff36f4a4, ff2f4840, 0, 1, 0) + d4 ff3578e0 do_deinit (ff2f6e40, 0, ff322a40, ff322a40, ff320140, 2944) + 10 ff1dd00c _exithandle (ff320000, ff320100, ff2f4840, 2880, 2800, f) + 50 ff1cb1ac exit (0, 142e0, f, f, f, 15) + 4 00010f10 _start (0, 0, 0, 0, 0, 0) + 64 Thanks! Laurent From dkg at fifthhorseman.net Fri Feb 20 21:18:51 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 20 Feb 2015 15:18:51 -0500 Subject: [PATCH] curl-shim: clean up varargs In-Reply-To: <87lhjvlas4.fsf@vigenere.g10code.de> References: <1424250691-31497-1-git-send-email-dkg@fifthhorseman.net> <87lhjvlas4.fsf@vigenere.g10code.de> Message-ID: <87zj8872vo.fsf@alice.fifthhorseman.net> On Wed 2015-02-18 06:27:39 -0500, Werner Koch wrote: > On Wed, 18 Feb 2015 10:11, dkg at fifthhorseman.net said: >> * keyserver/curl-shim.c (curl_easy_setopt) : ensure that va_end is >> called. > > That was right in time for the next 2.0 release. Thanks to Joshua > Rogers and you. thanks, that was quick :) I think it should be applied to master as well as STABLE-BRANCH-2-0. Regards, --dkg From dkg at fifthhorseman.net Sat Feb 21 17:04:13 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 11:04:13 -0500 Subject: [PATCH] gpg: avoid chatter about trustdb when --quiet Message-ID: <1424534653-8609-1-git-send-email-dkg@fifthhorseman.net> * g10/trustdb.c (tdb_check_trustdb_stale): avoid log_info() when opt.quiet -- gpg(1) says: -q, --quiet Try to be as quiet as possible. While the mentions about the stale trustdb information are edifying, they aren't necessary, and shouldn't be emitted when the user requests --quiet. Signed-off-by: Daniel Kahn Gillmor --- g10/trustdb.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/g10/trustdb.c b/g10/trustdb.c index f0b5501..6145cf0 100644 --- a/g10/trustdb.c +++ b/g10/trustdb.c @@ -938,11 +938,13 @@ tdb_check_trustdb_stale (void) if (opt.no_auto_check_trustdb) { pending_check_trustdb = 1; - log_info (_("please do a --check-trustdb\n")); + if (!opt.quiet) + log_info (_("please do a --check-trustdb\n")); } else { - log_info (_("checking the trustdb\n")); + if (!opt.quiet) + log_info (_("checking the trustdb\n")); validate_keys (0); } } -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 00:23:44 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 18:23:44 -0500 Subject: [PATCH] gpg: Fix segv due to NULL value stored as opaque MPI (BRANCH 2.0) Message-ID: <1424561024-22745-1-git-send-email-dkg@fifthhorseman.net> * g10/build-packet.c (do_secret_key): Check for NULL return from gcry_mpi_get_opaque. * g10/keyid.c (hash_public_key): Ditto. -- This is a backport of 76c8122adfed0f0f443cce7bda702ba2b39661b3 from master to the STABLE-BRANCH-2-0 On the STABLE-BRANCH-2-0, we may also want to patch g10/seckey-cert.c, but that has not been done in this patch. This fix extends commmit 0835d2f44ef62eab51fce6a927908f544e01cf8f. gpg2 --export --no-default-keyring --keyring TESTDATA With TESTDATA being below after unpacking. -----BEGIN PGP ARMORED FILE----- mBMEhdkMmS8BcX8F//8F5voEhQAQmBMEnAAAZwAAo4D/f/8EhQAAAIAEnP8EhQAQ iBMEnP8AAAAABf8jIID///8EhQYQmBMEnIUAEIgTBKT/AAAAAAUAACCA/f//BIUA EJgTBJx/AP8ABPPzBJx/AP8ABPPz =2yE0 -----END PGP ARMORED FILE----- Reported-by: Jodie Cunningham Signed-off-by: Daniel Kahn Gillmor --- g10/build-packet.c | 6 ++++-- g10/keyid.c | 16 ++++++++++------ 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/g10/build-packet.c b/g10/build-packet.c index e986987..5cc03cf 100644 --- a/g10/build-packet.c +++ b/g10/build-packet.c @@ -398,7 +398,8 @@ do_secret_key( IOBUF out, int ctb, PKT_secret_key *sk ) assert (gcry_mpi_get_flag (sk->skey[npkey], GCRYMPI_FLAG_OPAQUE)); p = gcry_mpi_get_opaque (sk->skey[npkey], &ndatabits ); - iobuf_write (a, p, (ndatabits+7)/8 ); + if (p) + iobuf_write (a, p, (ndatabits+7)/8 ); } else if ( sk->is_protected ) { @@ -410,7 +411,8 @@ do_secret_key( IOBUF out, int ctb, PKT_secret_key *sk ) assert (gcry_mpi_get_flag (sk->skey[i], GCRYMPI_FLAG_OPAQUE)); p = gcry_mpi_get_opaque (sk->skey[i], &ndatabits); - iobuf_write (a, p, (ndatabits+7)/8); + if (p) + iobuf_write (a, p, (ndatabits+7)/8); } write_16(a, sk->csum ); } diff --git a/g10/keyid.c b/g10/keyid.c index 6af0f48..ef6ee1c 100644 --- a/g10/keyid.c +++ b/g10/keyid.c @@ -115,14 +115,18 @@ hash_public_key( gcry_md_hd_t md, PKT_public_key *pk ) if(npkey==0 && pk->pkey[0] && gcry_mpi_get_flag (pk->pkey[0], GCRYMPI_FLAG_OPAQUE)) { - gcry_md_write (md, pp[0], nn[0]); + if (pp[0]) + gcry_md_write (md, pp[0], nn[0]); } else - for(i=0; i < npkey; i++ ) - { - gcry_md_write ( md, pp[i], nn[i] ); - xfree(pp[i]); - } + { + for(i=0; i < npkey; i++ ) + { + if (pp[i]) + gcry_md_write ( md, pp[i], nn[i] ); + xfree(pp[i]); + } + } } static gcry_md_hd_t -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:35 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:35 -0500 Subject: [PATCH 11/13] curl-shim: clean up varargs In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-12-git-send-email-dkg@fifthhorseman.net> * keyserver/curl-shim.c (curl_easy_setopt) : ensure that va_end is called. -- stdarg(3) says: Each invocation of va_start() must be matched by a corresponding invocation of va_end() in the same function. Observed by Joshua Rogers Debian-Bug-Id: #773475 [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- keyserver/curl-shim.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/keyserver/curl-shim.c b/keyserver/curl-shim.c index ce510cb..72c0f04 100644 --- a/keyserver/curl-shim.c +++ b/keyserver/curl-shim.c @@ -155,6 +155,8 @@ curl_easy_setopt(CURL *curl,CURLoption option,...) break; } + va_end(ap); + return handle_error(curl,CURLE_OK,NULL); } -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:24 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:24 -0500 Subject: Backporting fixes to STABLE-BRANCH-1-4 Message-ID: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> A lot of good bug-fixes and minor improvments have landed on the 2.0 and 2.1 branches recently, but several of those fixes haven't made it to the 1.4 branch. The patch series that follows is my attempt to port the relevant changes from the 2.0 series to STABLE-BRANCH-1-4. I've left the git commit messages alone for the most part, just added my own Signed-off-by line and a note that this was a backport to 1.4. Please let me know if there are any issues with this series, its presentation, or its approach. Hope this is helpful, --dkg From dkg at fifthhorseman.net Sun Feb 22 05:10:37 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:37 -0500 Subject: [PATCH 13/13] gpg: Fix segv due to NULL value stored as opaque MPI (BRANCH 1.4) In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-14-git-send-email-dkg@fifthhorseman.net> * g10/build-packet.c (do_secret_key): Check for NULL return from gcry_mpi_get_opaque. * g10/keyid.c (hash_public_key): Ditto. -- This is a backport of 76c8122adfed0f0f443cce7bda702ba2b39661b3 from master to the STABLE-BRANCH-1-4 On the STABLE-BRANCH-1-4, we may also want to patch g10/seckey-cert.c, but that has not been done in this patch. This fix extends commmit 0835d2f44ef62eab51fce6a927908f544e01cf8f. gpg2 --export --no-default-keyring --keyring TESTDATA With TESTDATA being below after unpacking. -----BEGIN PGP ARMORED FILE----- mBMEhdkMmS8BcX8F//8F5voEhQAQmBMEnAAAZwAAo4D/f/8EhQAAAIAEnP8EhQAQ iBMEnP8AAAAABf8jIID///8EhQYQmBMEnIUAEIgTBKT/AAAAAAUAACCA/f//BIUA EJgTBJx/AP8ABPPzBJx/AP8ABPPz =2yE0 -----END PGP ARMORED FILE----- Reported-by: Jodie Cunningham [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- g10/build-packet.c | 6 ++++-- g10/keyid.c | 8 ++++++-- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/g10/build-packet.c b/g10/build-packet.c index 60eb3c8..028d064 100644 --- a/g10/build-packet.c +++ b/g10/build-packet.c @@ -356,7 +356,8 @@ do_secret_key( IOBUF out, int ctb, PKT_secret_key *sk ) assert( mpi_is_opaque( sk->skey[npkey] ) ); p = mpi_get_opaque( sk->skey[npkey], &ndata ); - iobuf_write(a, p, ndata ); + if (p) + iobuf_write(a, p, ndata ); } else if( sk->is_protected ) { /* The secret key is protected te old v4 way. */ @@ -366,7 +367,8 @@ do_secret_key( IOBUF out, int ctb, PKT_secret_key *sk ) assert (mpi_is_opaque (sk->skey[i])); p = mpi_get_opaque (sk->skey[i], &ndata); - iobuf_write (a, p, ndata); + if (p) + iobuf_write (a, p, ndata); } write_16(a, sk->csum ); } diff --git a/g10/keyid.c b/g10/keyid.c index ed30cff..a86ac94 100644 --- a/g10/keyid.c +++ b/g10/keyid.c @@ -112,13 +112,17 @@ hash_public_key( MD_HANDLE md, PKT_public_key *pk ) md_putc( md, pk->pubkey_algo ); if(npkey==0 && pk->pkey[0] && mpi_is_opaque(pk->pkey[0])) - md_write(md,pp[0],nn[0]); + { + if (pp[0]) + md_write(md,pp[0],nn[0]); + } else for(i=0; i < npkey; i++ ) { md_putc( md, nb[i]>>8); md_putc( md, nb[i] ); - md_write( md, pp[i], nn[i] ); + if (pp[i]) + md_write( md, pp[i], nn[i] ); xfree(pp[i]); } } -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:28 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:28 -0500 Subject: [PATCH 04/13] gpg: Fix a NULL-deref due to empty ring trust packets. In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-5-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * g10/parse-packet.c (parse_trust): Always allocate a packet. -- Reported-by: Hanno B?ck Signed-off-by: Werner Koch (back ported from commit 39978487863066e59bb657f5fe4e8baab510da7e) [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- g10/parse-packet.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/g10/parse-packet.c b/g10/parse-packet.c index c0b6ad6..e7e923b 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -2245,11 +2245,13 @@ parse_trust( IOBUF inp, int pkttype, unsigned long pktlen, PACKET *pkt ) { int c; + (void)pkttype; + + pkt->pkt.ring_trust = xmalloc( sizeof *pkt->pkt.ring_trust ); if (pktlen) { c = iobuf_get_noeof(inp); pktlen--; - pkt->pkt.ring_trust = xmalloc( sizeof *pkt->pkt.ring_trust ); pkt->pkt.ring_trust->trustval = c; pkt->pkt.ring_trust->sigcache = 0; if (!c && pktlen==1) @@ -2267,8 +2269,10 @@ parse_trust( IOBUF inp, int pkttype, unsigned long pktlen, PACKET *pkt ) } else { - if( list_mode ) - fprintf (listfp, ":trust packet: empty\n"); + pkt->pkt.ring_trust->trustval = 0; + pkt->pkt.ring_trust->sigcache = 0; + if (list_mode) + fprintf (listfp, ":trust packet: empty\n"); } iobuf_skip_rest (inp, pktlen, 0); } -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:27 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:27 -0500 Subject: [PATCH 03/13] gpg: Limit the size of key packets to a sensible value. In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-4-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * g10/parse-packet.c (MAX_KEY_PACKET_LENGTH): New. (MAX_UID_PACKET_LENGTH): New. (MAX_COMMENT_PACKET_LENGTH): New. (MAX_ATTR_PACKET_LENGTH): New. (parse_key): Limit the size of a key packet to 256k. (parse_user_id): Use macro for the packet size limit. (parse_attribute): Ditto. (parse_comment): Ditto. -- Without that it is possible to force gpg to allocate large amounts of memory by using a bad encoded MPI. This would be an too easy DoS. Another way to mitigate would be to change the MPI read function to allocate memory dynamically while reading the MPI. However, that complicates and possibly slows down the code. A too large key packet is in any case a sign for broken data and thus gpg should not use it. Reported-by: Hanno B?ck GnuPG-bug-id: 1823 Signed-off-by: Werner Koch (back ported from commit 382ba4b137b42d5f25a7e256bb7c053ee5ac7b64) [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- g10/parse-packet.c | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/g10/parse-packet.c b/g10/parse-packet.c index e4e524c..c0b6ad6 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -40,6 +40,12 @@ #define MAX_EXTERN_MPI_BITS 16384 #endif +/* Maximum length of packets to avoid excessive memory allocation. */ +#define MAX_KEY_PACKET_LENGTH (256 * 1024) +#define MAX_UID_PACKET_LENGTH ( 2 * 1024) +#define MAX_COMMENT_PACKET_LENGTH ( 64 * 1024) +#define MAX_ATTR_PACKET_LENGTH ( 16 * 1024*1024) + static int mpi_print_mode; static int list_mode; @@ -1663,6 +1669,13 @@ parse_key( IOBUF inp, int pkttype, unsigned long pktlen, rc = G10ERR_INVALID_PACKET; goto leave; } + else if (pktlen > MAX_KEY_PACKET_LENGTH) { + log_error ("packet(%d) too large\n", pkttype); + if (list_mode) + fputs (":key packet: [too large]\n", listfp); + rc = G10ERR_INVALID_PACKET; + goto leave; + } timestamp = read_32(inp); pktlen -= 4; if( is_v4 ) { @@ -2083,7 +2096,7 @@ parse_user_id( IOBUF inp, int pkttype, unsigned long pktlen, PACKET *packet ) allocatable, and a very large pktlen could actually cause our allocation to wrap around in xmalloc to a small number. */ - if(pktlen>2048) + if (pktlen > MAX_UID_PACKET_LENGTH) { log_error("packet(%d) too large\n", pkttype); iobuf_skip_rest(inp, pktlen, 0); @@ -2152,6 +2165,19 @@ parse_attribute( IOBUF inp, int pkttype, unsigned long pktlen, PACKET *packet ) { byte *p; + (void)pkttype; + + /* We better cap the size of an attribute packet to make DoS not + too easy. 16MB should be more then enough for one attribute + packet (ie. a photo). */ + if (pktlen > MAX_ATTR_PACKET_LENGTH) { + log_error ("packet(%d) too large\n", pkttype); + if (list_mode) + fprintf (listfp, ":attribute packet: [too large]\n"); + iobuf_skip_rest (inp, pktlen, 0); + return G10ERR_INVALID_PACKET; + } + #define EXTRA_UID_NAME_SPACE 71 packet->pkt.user_id = xmalloc_clear(sizeof *packet->pkt.user_id + EXTRA_UID_NAME_SPACE); @@ -2186,7 +2212,7 @@ parse_comment( IOBUF inp, int pkttype, unsigned long pktlen, PACKET *packet ) overflow in the malloc below. Comment packets are actually not anymore define my OpenPGP and we even stopped to use our private comment packet. */ - if (pktlen>65536) + if (pktlen > MAX_COMMENT_PACKET_LENGTH) { log_error ("packet(%d) too large\n", pkttype); iobuf_skip_rest (inp, pktlen, 0); -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:26 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:26 -0500 Subject: [PATCH 02/13] gpg: Allow predefined names as answer to the keygen.algo prompt. In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-3-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * g10/keygen.c (ask_algo): Add list of strings. -- Signed-off-by: Werner Koch (backported from commit b1d5ed6ac842469afcb84868d0f6641dc286a6c7) [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- doc/DETAILS | 28 ++++++++++++++++++++++++++++ g10/keygen.c | 24 +++++++++++++----------- 2 files changed, 41 insertions(+), 11 deletions(-) diff --git a/doc/DETAILS b/doc/DETAILS index 7f12e21..7c2c347 100644 --- a/doc/DETAILS +++ b/doc/DETAILS @@ -1251,3 +1251,31 @@ This can be implemented using Hurd's translator mechanism. However, I think the whole key server stuff has to be re-thought; I have some ideas and probably create a white paper. + +Algorithm names for the "keygen.algo" prompt +============================================ + + When using a --command-fd controlled key generation or "addkey" + there is way to know the number to enter on the "keygen.algo" + prompt. The displayed numbers are for human reception and may + change with releases. To provide a stable way to enter a desired + algorithm choice the prompt also accepts predefined names for the + algorithms, which will not change. + + | Name | No | Description | + |---------+----+---------------------------------| + | rsa+rsa | 1 | RSA and RSA (default) | + | dsa+elg | 2 | DSA and Elgamal | + | dsa | 3 | DSA (sign only) | + | rsa/s | 4 | RSA (sign only) | + | elg | 5 | Elgamal (encrypt only) | + | rsa/e | 6 | RSA (encrypt only) | + | dsa/* | 7 | DSA (set your own capabilities) | + | rsa/* | 8 | RSA (set your own capabilities) | + + If one of the "foo/*" names are used a "keygen.flags" prompt needs + to be answered as well. Instead of toggling the predefined flags, + it is also possible to set them direct: Use a "=" character + directly followed by a comination of "a" (for authentication), "s" + (for signing), or "c" (for certification). + diff --git a/g10/keygen.c b/g10/keygen.c index 5af0043..995ba63 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -1481,7 +1481,7 @@ ask_key_flags(int algo,int subkey) static int ask_algo (int addmode, int *r_subkey_algo, unsigned int *r_usage) { - char *answer; + char *answer = NULL; int algo; int dummy_algo; @@ -1512,53 +1512,53 @@ ask_algo (int addmode, int *r_subkey_algo, unsigned int *r_usage) { *r_usage = 0; *r_subkey_algo = 0; + xfree (answer); answer = cpr_get ("keygen.algo", _("Your selection? ")); cpr_kill_prompt (); - algo = *answer? atoi(answer): 1; - xfree (answer); - if ( algo == 1 && !addmode ) + algo = *answer? atoi (answer) : 1; + if ((algo == 1 || !strcmp (answer, "rsa+rsa")) && !addmode) { algo = PUBKEY_ALGO_RSA; *r_subkey_algo = PUBKEY_ALGO_RSA; break; } - else if (algo == 2 && !addmode) + else if ((algo == 2 || !strcmp (answer, "dsa+elg")) && !addmode) { algo = PUBKEY_ALGO_DSA; *r_subkey_algo = PUBKEY_ALGO_ELGAMAL_E; break; } - else if (algo == 3) + else if (algo == 3 || !strcmp (answer, "dsa")) { algo = PUBKEY_ALGO_DSA; *r_usage = PUBKEY_USAGE_SIG; break; } - else if (algo == 4) + else if (algo == 4 || !strcmp (answer, "rsa/s")) { algo = PUBKEY_ALGO_RSA; *r_usage = PUBKEY_USAGE_SIG; break; } - else if (algo == 5 && addmode) + else if ((algo == 5 || !strcmp (answer, "elg")) && addmode) { algo = PUBKEY_ALGO_ELGAMAL_E; *r_usage = PUBKEY_USAGE_ENC; break; } - else if (algo == 6 && addmode) + else if ((algo == 6 || !strcmp (answer, "rsa/e")) && addmode) { algo = PUBKEY_ALGO_RSA; *r_usage = PUBKEY_USAGE_ENC; break; } - else if (algo == 7 && opt.expert) + else if ((algo == 7 || !strcmp (answer, "dsa/*")) && opt.expert) { algo = PUBKEY_ALGO_DSA; *r_usage = ask_key_flags (algo, addmode); break; } - else if (algo == 8 && opt.expert) + else if ((algo == 8 || !strcmp (answer, "rsa/*")) && opt.expert) { algo = PUBKEY_ALGO_RSA; *r_usage = ask_key_flags (algo, addmode); @@ -1566,8 +1566,10 @@ ask_algo (int addmode, int *r_subkey_algo, unsigned int *r_usage) } else tty_printf (_("Invalid selection.\n")); + } + xfree(answer); return algo; } -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:25 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:25 -0500 Subject: [PATCH 01/13] gpg: Print a warning if the subkey expiration may not be what you want. In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-2-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * g10/keyedit.c (subkey_expire_warning): New. keyedit_menu): Call it when needed. -- GnuPG-bug-id: 1715 The heuristic to detect a problem is not very advanced but it should catch the most common cases. (backported from commit ae3d1bbb65b65cf3c57bb14886be120f5e31635d) [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- g10/keyedit.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/g10/keyedit.c b/g10/keyedit.c index afc5ff4..95be10e 100644 --- a/g10/keyedit.c +++ b/g10/keyedit.c @@ -51,6 +51,7 @@ static void show_names(KBNODE keyblock,PKT_public_key *pk, static void show_key_with_all_names( KBNODE keyblock, int only_marked, int with_revoker, int with_fpr, int with_subkeys, int with_prefs ); static void show_key_and_fingerprint( KBNODE keyblock ); +static void subkey_expire_warning (kbnode_t keyblock); static int menu_adduid( KBNODE keyblock, KBNODE sec_keyblock, int photo, const char *photo_name ); static void menu_deluid( KBNODE pub_keyblock, KBNODE sec_keyblock ); @@ -1506,6 +1507,7 @@ keyedit_menu( const char *username, STRLIST locusr, int redisplay = 1; int modified = 0; int sec_modified = 0; + int run_subkey_warnings = 0; int toggle; int have_commands = !!commands; @@ -1604,6 +1606,14 @@ keyedit_menu( const char *username, STRLIST locusr, tty_printf("\n"); redisplay = 0; } + + if (run_subkey_warnings) + { + run_subkey_warnings = 0; + if (!count_selected_keys (keyblock)) + subkey_expire_warning (keyblock); + } + do { xfree(answer); if( have_commands ) { @@ -2053,6 +2063,7 @@ keyedit_menu( const char *username, STRLIST locusr, { merge_keys_and_selfsig( sec_keyblock ); merge_keys_and_selfsig( keyblock ); + run_subkey_warnings = 1; sec_modified = 1; modified = 1; redisplay = 1; @@ -2952,6 +2963,53 @@ no_primary_warning(KBNODE keyblock) " the assumed primary.\n")); } + +/* Print a warning if the latest encryption subkey expires soon. This + function is called after the expire data of the primary key has + been changed. */ +static void +subkey_expire_warning (kbnode_t keyblock) +{ + u32 curtime = make_timestamp (); + kbnode_t node; + PKT_public_key *pk; + /* u32 mainexpire = 0; */ + u32 subexpire = 0; + u32 latest_date = 0; + + for (node = keyblock; node; node = node->next) + { + if (node->pkt->pkttype != PKT_PUBLIC_SUBKEY) + continue; + pk = node->pkt->pkt.public_key; + + if (!pk->is_valid) + continue; + if (pk->is_revoked) + continue; + if (pk->timestamp > curtime) + continue; /* Ignore future keys. */ + if (!(pk->pubkey_usage & PUBKEY_USAGE_ENC)) + continue; /* Not an encryption key. */ + + if (pk->timestamp > latest_date || (!pk->timestamp && !latest_date)) + { + latest_date = pk->timestamp; + subexpire = pk->expiredate; + } + } + + if (!subexpire) + return; /* No valid subkey with an expiration time. */ + + if (curtime + (10*86400) > subexpire) + { + log_info (_("WARNING: Your encryption subkey expires soon.\n")); + log_info (_("You may want to change its expiration date too.\n")); + } +} + + /**************** * Ask for a new user id, do the selfsignature and put it into * both keyblocks. -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:30 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:30 -0500 Subject: [PATCH 06/13] gpg: Prevent an invalid memory read using a garbled keyring. In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-7-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * g10/keyring.c (keyring_get_keyblock): Whitelist allowed packet types. -- The keyring DB code did not reject packets which don't belong into a keyring. If for example the keyblock contains a literal data packet it is expected that the processing code stops at the data packet and reads from the input stream which is referenced from the data packets. Obviously the keyring processing code does not and cannot do that. However, when exporting this messes up the IOBUF and leads to an invalid read of sizeof (int). We now skip all packets which are not allowed in a keyring. Reported-by: Hanno B?ck (back ported from commit f0f71a721ccd7ab9e40b8b6b028b59632c0cc648) [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- g10/keyring.c | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/g10/keyring.c b/g10/keyring.c index 108e107..270bf8e 100644 --- a/g10/keyring.c +++ b/g10/keyring.c @@ -400,8 +400,26 @@ keyring_get_keyblock (KEYRING_HANDLE hd, KBNODE *ret_kb) rc = G10ERR_INV_KEYRING; break; } - if (pkt->pkttype == PKT_COMPRESSED) { - log_error ("skipped compressed packet in keyring\n"); + + /* Filter allowed packets. */ + switch (pkt->pkttype){ + case PKT_PUBLIC_KEY: + case PKT_PUBLIC_SUBKEY: + case PKT_SECRET_KEY: + case PKT_SECRET_SUBKEY: + case PKT_USER_ID: + case PKT_ATTRIBUTE: + case PKT_SIGNATURE: + break; /* Allowed per RFC. */ + case PKT_RING_TRUST: + case PKT_OLD_COMMENT: + case PKT_COMMENT: + case PKT_GPG_CONTROL: + break; /* Allowed by us. */ + + default: + log_error ("skipped packet of type %d in keyring\n", + (int)pkt->pkttype); free_packet(pkt); init_packet(pkt); continue; @@ -467,7 +485,7 @@ keyring_get_keyblock (KEYRING_HANDLE hd, KBNODE *ret_kb) if (rc || !ret_kb) release_kbnode (keyblock); else { - /*(duplicated form the loop body)*/ + /*(duplicated from the loop body)*/ if ( pkt && pkt->pkttype == PKT_RING_TRUST && lastnode && lastnode->pkt->pkttype == PKT_SIGNATURE -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:29 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:29 -0500 Subject: [PATCH 05/13] gpg: Fix a NULL-deref in export due to invalid packet lengths. In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-6-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * g10/build-packet.c (write_fake_data): Take care of a NULL stored as opaque MPI. -- Reported-by: Hanno B?ck (back ported from commit 0835d2f44ef62eab51fce6a927908f544e01cf8f) [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- g10/build-packet.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/g10/build-packet.c b/g10/build-packet.c index abe0181..499dd68 100644 --- a/g10/build-packet.c +++ b/g10/build-packet.c @@ -193,7 +193,8 @@ write_fake_data( IOBUF out, MPI a ) void *p; p = mpi_get_opaque( a, &i ); - iobuf_write( out, p, i ); + if (p) + iobuf_write( out, p, i ); } } -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:32 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:32 -0500 Subject: [PATCH 08/13] Use inline functions to convert buffer data to scalars. In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-9-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * include/host2net.h (buf16_to_ulong, buf16_to_uint): New. (buf16_to_ushort, buf16_to_u16): New. (buf32_to_size_t, buf32_to_ulong, buf32_to_uint, buf32_to_u32): New. -- This fixes sign extension on shift problems. Hanno B?ck found a case with an invalid read due to this problem. To fix that almost all uses of "<< 24" and "<< 8" are changed by this patch to use an inline function from host2net.h. (back ported from commit 2183683bd633818dd031b090b5530951de76f392) Signed-off-by: Werner Koch [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- g10/apdu.c | 27 ++++++++---------- g10/app-openpgp.c | 3 +- g10/build-packet.c | 6 ++-- g10/ccid-driver.c | 3 +- g10/getkey.c | 17 ++++++------ g10/keygen.c | 14 ++++------ g10/keyid.c | 28 ++++++++----------- g10/misc.c | 11 -------- g10/parse-packet.c | 41 ++++++++++++++-------------- g10/tdbio.c | 22 +++++++-------- g10/trustdb.c | 2 +- include/host2net.h | 80 +++++++++++++++++++++++++++++++++++++++++++++++------- 12 files changed, 148 insertions(+), 106 deletions(-) diff --git a/g10/apdu.c b/g10/apdu.c index 66cf30b..ffc7d36 100644 --- a/g10/apdu.c +++ b/g10/apdu.c @@ -60,6 +60,7 @@ #include "scdaemon.h" #include "exechelp.h" #endif /* GNUPG_MAJOR_VERSION != 1 */ +#include "../include/host2net.h" #include "apdu.h" #include "ccid-driver.h" @@ -916,15 +917,14 @@ pcsc_get_status_wrapped (int slot, unsigned int *status) i? strerror (errno) : "premature EOF"); goto command_failed; } - len = (msgbuf[1] << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; + len = buf32_to_size_t (msgbuf+1); if (msgbuf[0] != 0x81 || len < 4) { log_error ("invalid response header from PC/SC received\n"); goto command_failed; } len -= 4; /* Already read the error code. */ - err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) - | (msgbuf[7] << 8 ) | msgbuf[8]); + err = PCSC_ERR_MASK (buf32_to_ulong (msgbuf+5)); if (err) { log_error ("pcsc_status failed: %s (0x%lx)\n", @@ -1084,15 +1084,14 @@ pcsc_send_apdu_wrapped (int slot, unsigned char *apdu, size_t apdulen, i? strerror (errno) : "premature EOF"); goto command_failed; } - len = (msgbuf[1] << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; + len = buf32_to_size_t (msgbuf+1); if (msgbuf[0] != 0x81 || len < 4) { log_error ("invalid response header from PC/SC received\n"); goto command_failed; } len -= 4; /* Already read the error code. */ - err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) - | (msgbuf[7] << 8 ) | msgbuf[8]); + err = PCSC_ERR_MASK (buf32_to_ulong (msgbuf+5)); if (err) { log_error ("pcsc_transmit failed: %s (0x%lx)\n", @@ -1217,15 +1216,14 @@ close_pcsc_reader_wrapped (int slot) i? strerror (errno) : "premature EOF"); goto command_failed; } - len = (msgbuf[1] << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; + len = buf32_to_size_t (msgbuf+1); if (msgbuf[0] != 0x81 || len < 4) { log_error ("invalid response header from PC/SC received\n"); goto command_failed; } len -= 4; /* Already read the error code. */ - err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) - | (msgbuf[7] << 8 ) | msgbuf[8]); + err = PCSC_ERR_MASK (buf32_to_ulong (msgbuf+5)); if (err) log_error ("pcsc_close failed: %s (0x%lx)\n", pcsc_error_string (err), err); @@ -1405,7 +1403,7 @@ reset_pcsc_reader_wrapped (int slot) i? strerror (errno) : "premature EOF"); goto command_failed; } - len = (msgbuf[1] << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; + len = buf32_to_size_t (msgbuf+1); if (msgbuf[0] != 0x81 || len < 4) { log_error ("invalid response header from PC/SC received\n"); @@ -1419,8 +1417,7 @@ reset_pcsc_reader_wrapped (int slot) sw = SW_HOST_GENERAL_ERROR; goto command_failed; } - err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) - | (msgbuf[7] << 8 ) | msgbuf[8]); + err = PCSC_ERR_MASK (buf32_to_ulong (msgbuf+5)); if (err) { log_error ("PC/SC RESET failed: %s (0x%lx)\n", @@ -1719,7 +1716,7 @@ open_pcsc_reader_wrapped (const char *portstr) i? strerror (errno) : "premature EOF"); goto command_failed; } - len = (msgbuf[1] << 24) | (msgbuf[2] << 16) | (msgbuf[3] << 8 ) | msgbuf[4]; + len = buf32_to_size_t (msgbuf+1); if (msgbuf[0] != 0x81 || len < 4) { log_error ("invalid response header from PC/SC received\n"); @@ -1732,8 +1729,8 @@ open_pcsc_reader_wrapped (const char *portstr) (unsigned long)len); goto command_failed; } - err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) - | (msgbuf[7] << 8 ) | msgbuf[8]); + err = PCSC_ERR_MASK (buf32_to_ulong (msgbuf+5)); + if (err) { log_error ("PC/SC OPEN failed: %s\n", pcsc_error_string (err)); diff --git a/g10/app-openpgp.c b/g10/app-openpgp.c index c3b4fae..192680c 100644 --- a/g10/app-openpgp.c +++ b/g10/app-openpgp.c @@ -68,6 +68,7 @@ #include "iso7816.h" #include "app-common.h" #include "tlv.h" +#include "../include/host2net.h" /* A table describing the DOs of the card. */ @@ -744,7 +745,7 @@ send_fprtime_if_not_null (ctrl_t ctrl, const char *keyword, char numbuf1[50], numbuf2[50]; unsigned long value; - value = (stamp[0] << 24) | (stamp[1]<<16) | (stamp[2]<<8) | stamp[3]; + value = buf32_to_ulong (stamp); if (!value) return; sprintf (numbuf1, "%d", number); diff --git a/g10/build-packet.c b/g10/build-packet.c index 499dd68..60eb3c8 100644 --- a/g10/build-packet.c +++ b/g10/build-packet.c @@ -34,6 +34,7 @@ #include "memory.h" #include "i18n.h" #include "options.h" +#include "../include/host2net.h" static int do_user_id( IOBUF out, int ctb, PKT_user_id *uid ); static int do_public_key( IOBUF out, int ctb, PKT_public_key *pk ); @@ -586,8 +587,7 @@ delete_sig_subpkt (subpktarea_t *area, sigsubpkttype_t reqtype ) if( n == 255 ) { if( buflen < 4 ) break; - n = (buffer[0] << 24) | (buffer[1] << 16) - | (buffer[2] << 8) | buffer[3]; + n = buf32_to_size_t (buffer); buffer += 4; buflen -= 4; } @@ -710,7 +710,7 @@ build_sig_subpkt (PKT_signature *sig, sigsubpkttype_t type, /* This should never happen since we don't currently allow creating such a subpacket, but just in case... */ case SIGSUBPKT_SIG_EXPIRE: - if(buffer_to_u32(buffer)+sig->timestamp<=make_timestamp()) + if (buf32_to_u32 (buffer) + sig->timestamp <= make_timestamp()) sig->flags.expired=1; else sig->flags.expired=0; diff --git a/g10/ccid-driver.c b/g10/ccid-driver.c index 8c362d7..515b15a 100644 --- a/g10/ccid-driver.c +++ b/g10/ccid-driver.c @@ -92,6 +92,7 @@ #include #include "ccid-driver.h" +#include "../include/host2net.h" #define DRVNAME "ccid-driver: " @@ -292,7 +293,7 @@ static int abort_cmd (ccid_driver_t handle, int seqno); static unsigned int convert_le_u32 (const unsigned char *buf) { - return buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24); + return buf[0] | (buf[1] << 8) | (buf[2] << 16) | ((unsigned int)buf[3] << 24); } diff --git a/g10/getkey.c b/g10/getkey.c index 3c953d6..9870710 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -34,6 +34,7 @@ #include "trustdb.h" #include "i18n.h" #include "keyserver-internal.h" +#include "../include/host2net.h" #define MAX_PK_CACHE_ENTRIES PK_UID_CACHE_SIZE #define MAX_UID_CACHE_ENTRIES PK_UID_CACHE_SIZE @@ -1427,14 +1428,14 @@ merge_keys_and_selfsig( KBNODE keyblock ) p = parse_sig_subpkt( sig->hashed, SIGSUBPKT_KEY_EXPIRE, NULL ); if( pk ) { - ed = p? pk->timestamp + buffer_to_u32(p):0; + ed = p? pk->timestamp + buf32_to_u32(p):0; if( sig->timestamp > sigdate ) { pk->expiredate = ed; sigdate = sig->timestamp; } } else { - ed = p? sk->timestamp + buffer_to_u32(p):0; + ed = p? sk->timestamp + buf32_to_u32(p):0; if( sig->timestamp > sigdate ) { sk->expiredate = ed; sigdate = sig->timestamp; @@ -1559,8 +1560,8 @@ fixup_uidnode ( KBNODE uidnode, KBNODE signode, u32 keycreated ) /* ditto for the key expiration */ p = parse_sig_subpkt (sig->hashed, SIGSUBPKT_KEY_EXPIRE, NULL); - if( p && buffer_to_u32(p) ) - uid->help_key_expire = keycreated + buffer_to_u32(p); + if( p && buf32_to_u32 (p) ) + uid->help_key_expire = keycreated + buf32_to_u32(p); else uid->help_key_expire = 0; @@ -1774,9 +1775,9 @@ merge_selfsigs_main(KBNODE keyblock, int *r_revoked, struct revoke_info *rinfo) key_usage=parse_key_usage(sig); p = parse_sig_subpkt (sig->hashed, SIGSUBPKT_KEY_EXPIRE, NULL); - if( p && buffer_to_u32(p) ) + if( p && buf32_to_u32 (p) ) { - key_expire = keytimestamp + buffer_to_u32(p); + key_expire = keytimestamp + buf32_to_u32 (p); key_expire_seen = 1; } @@ -2198,8 +2199,8 @@ merge_selfsigs_subkey( KBNODE keyblock, KBNODE subnode ) subpk->pubkey_usage = key_usage; p = parse_sig_subpkt (sig->hashed, SIGSUBPKT_KEY_EXPIRE, NULL); - if ( p && buffer_to_u32(p) ) - key_expire = keytimestamp + buffer_to_u32(p); + if ( p && buf32_to_u32 (p) ) + key_expire = keytimestamp + buf32_to_u32 (p); else key_expire = 0; subpk->has_expired = key_expire >= curtime? 0 : key_expire; diff --git a/g10/keygen.c b/g10/keygen.c index 995ba63..76ee74e 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -40,6 +40,7 @@ #include "i18n.h" #include "cardglue.h" #include "keyserver-internal.h" +#include "host2net.h" #define MAX_PREFS 30 @@ -832,10 +833,7 @@ make_backsig (PKT_signature *sig, PKT_public_key *pk, } else if(buf[1]==255) { - pktlen =buf[2] << 24; - pktlen|=buf[3] << 16; - pktlen|=buf[4] << 8; - pktlen|=buf[5]; + pktlen = buf32_to_size_t (buf+2); buf+=6; } else @@ -852,14 +850,14 @@ make_backsig (PKT_signature *sig, PKT_public_key *pk, break; case 2: - pktlen =buf[mark++] << 24; - pktlen|=buf[mark++] << 16; + pktlen = (size_t)buf[mark++] << 24; + pktlen |= buf[mark++] << 16; case 1: - pktlen|=buf[mark++] << 8; + pktlen |= buf[mark++] << 8; case 0: - pktlen|=buf[mark++]; + pktlen |= buf[mark++]; } buf+=mark; diff --git a/g10/keyid.c b/g10/keyid.c index d7072d4..ed30cff 100644 --- a/g10/keyid.c +++ b/g10/keyid.c @@ -32,6 +32,7 @@ #include "mpi.h" #include "keydb.h" #include "i18n.h" +#include "host2net.h" #ifdef HAVE_UNSIGNED_TIME_T # define INVALID_TIME_CHECK(a) ((a) == (time_t)(-1)) @@ -241,15 +242,8 @@ keystr_from_desc(KEYDB_SEARCH_DESC *desc) { u32 keyid[2]; - keyid[0] = (unsigned char)desc->u.fpr[12] << 24 - | (unsigned char)desc->u.fpr[13] << 16 - | (unsigned char)desc->u.fpr[14] << 8 - | (unsigned char)desc->u.fpr[15] ; - keyid[1] = (unsigned char)desc->u.fpr[16] << 24 - | (unsigned char)desc->u.fpr[17] << 16 - | (unsigned char)desc->u.fpr[18] << 8 - | (unsigned char)desc->u.fpr[19] ; - + keyid[0] = buf32_to_u32 (desc->u.fpr+12); + keyid[1] = buf32_to_u32 (desc->u.fpr+16); return keystr(keyid); } @@ -300,8 +294,8 @@ keyid_from_sk( PKT_secret_key *sk, u32 *keyid ) if(md) { dp = md_read( md, 0 ); - keyid[0] = dp[12] << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; - keyid[1] = dp[16] << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; + keyid[0] = buf32_to_u32 (dp+12); + keyid[1] = buf32_to_u32 (dp+16); lowbits = keyid[1]; md_close(md); sk->keyid[0] = keyid[0]; @@ -354,8 +348,8 @@ keyid_from_pk( PKT_public_key *pk, u32 *keyid ) if(md) { dp = md_read( md, 0 ); - keyid[0] = dp[12] << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; - keyid[1] = dp[16] << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; + keyid[0] = buf32_to_u32 (dp+12); + keyid[1] = buf32_to_u32 (dp+16); lowbits = keyid[1]; md_close(md); pk->keyid[0] = keyid[0]; @@ -398,8 +392,8 @@ keyid_from_fingerprint( const byte *fprint, size_t fprint_len, u32 *keyid ) } else { const byte *dp = fprint; - keyid[0] = dp[12] << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; - keyid[1] = dp[16] << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; + keyid[0] = buf32_to_u32 (dp+12); + keyid[1] = buf32_to_u32 (dp+16); } return keyid[1]; @@ -687,8 +681,8 @@ fingerprint_from_pk( PKT_public_key *pk, byte *array, size_t *ret_len ) if( !array ) array = xmalloc( len ); memcpy(array, dp, len ); - pk->keyid[0] = dp[12] << 24 | dp[13] << 16 | dp[14] << 8 | dp[15] ; - pk->keyid[1] = dp[16] << 24 | dp[17] << 16 | dp[18] << 8 | dp[19] ; + pk->keyid[0] = buf32_to_u32 (dp+12); + pk->keyid[1] = buf32_to_u32 (dp+16); md_close(md); } diff --git a/g10/misc.c b/g10/misc.c index 60ecf96..2c5c6cc 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -295,17 +295,6 @@ checksum_mpi( MPI a ) return csum; } -u32 -buffer_to_u32( const byte *buffer ) -{ - unsigned long a; - a = *buffer << 24; - a |= buffer[1] << 16; - a |= buffer[2] << 8; - a |= buffer[3]; - return a; -} - void print_pubkey_algo_note( int algo ) { diff --git a/g10/parse-packet.c b/g10/parse-packet.c index e7e923b..862ec6e 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -35,6 +35,7 @@ #include "options.h" #include "main.h" #include "i18n.h" +#include "host2net.h" #ifndef MAX_EXTERN_MPI_BITS #define MAX_EXTERN_MPI_BITS 16384 @@ -94,7 +95,7 @@ static unsigned short read_16(IOBUF inp) { unsigned short a; - a = iobuf_get_noeof(inp) << 8; + a = (unsigned short)iobuf_get_noeof(inp) << 8; a |= iobuf_get_noeof(inp); return a; } @@ -103,7 +104,7 @@ static unsigned long read_32(IOBUF inp) { unsigned long a; - a = iobuf_get_noeof(inp) << 24; + a = (unsigned long)iobuf_get_noeof(inp) << 24; a |= iobuf_get_noeof(inp) << 16; a |= iobuf_get_noeof(inp) << 8; a |= iobuf_get_noeof(inp); @@ -383,7 +384,8 @@ parse( IOBUF inp, PACKET *pkt, int onlykeypkts, off_t *retpos, } else if( c == 255 ) { - pktlen = (hdr[hdrlen++] = iobuf_get_noeof(inp)) << 24; + pktlen = + (unsigned long)(hdr[hdrlen++] = iobuf_get_noeof(inp)) << 24; pktlen |= (hdr[hdrlen++] = iobuf_get_noeof(inp)) << 16; pktlen |= (hdr[hdrlen++] = iobuf_get_noeof(inp)) << 8; if( (c = iobuf_get(inp)) == -1 ) @@ -878,14 +880,15 @@ dump_sig_subpkt( int hashed, int type, int critical, switch( type ) { case SIGSUBPKT_SIG_CREATED: if( length >= 4 ) - fprintf (listfp, "sig created %s", strtimestamp( buffer_to_u32(buffer) ) ); + fprintf (listfp, "sig created %s", + strtimestamp (buf32_to_u32(buffer)) ); break; case SIGSUBPKT_SIG_EXPIRE: if( length >= 4 ) { - if(buffer_to_u32(buffer)) + if(buf32_to_u32(buffer)) fprintf (listfp, "sig expires after %s", - strtimevalue( buffer_to_u32(buffer) ) ); + strtimevalue( buf32_to_u32(buffer) ) ); else fprintf (listfp, "sig does not expire"); } @@ -918,9 +921,9 @@ dump_sig_subpkt( int hashed, int type, int critical, case SIGSUBPKT_KEY_EXPIRE: if( length >= 4 ) { - if(buffer_to_u32(buffer)) + if(buf32_to_u32(buffer)) fprintf (listfp, "key expires after %s", - strtimevalue( buffer_to_u32(buffer) ) ); + strtimevalue( buf32_to_u32(buffer) ) ); else fprintf (listfp, "key does not expire"); } @@ -943,8 +946,8 @@ dump_sig_subpkt( int hashed, int type, int critical, case SIGSUBPKT_ISSUER: if( length >= 8 ) fprintf (listfp, "issuer key ID %08lX%08lX", - (ulong)buffer_to_u32(buffer), - (ulong)buffer_to_u32(buffer+4) ); + buf32_to_ulong (buffer), + buf32_to_ulong (buffer+4)); break; case SIGSUBPKT_NOTATION: { @@ -1192,8 +1195,7 @@ enum_sig_subpkt( const subpktarea_t *pktbuf, sigsubpkttype_t reqtype, if( n == 255 ) { /* 4 byte length header */ if( buflen < 4 ) goto too_short; - n = (buffer[0] << 24) | (buffer[1] << 16) - | (buffer[2] << 8) | buffer[3]; + n = buf32_to_size_t (buffer); buffer += 4; buflen -= 4; } @@ -1415,7 +1417,7 @@ parse_signature( IOBUF inp, int pkttype, unsigned long pktlen, p = parse_sig_subpkt (sig->hashed, SIGSUBPKT_SIG_CREATED, NULL ); if(p) - sig->timestamp = buffer_to_u32(p); + sig->timestamp = buf32_to_u32 (p); else if(!(sig->pubkey_algo>=100 && sig->pubkey_algo<=110) && opt.verbose) log_info ("signature packet without timestamp\n"); @@ -1423,16 +1425,16 @@ parse_signature( IOBUF inp, int pkttype, unsigned long pktlen, p = parse_sig_subpkt2( sig, SIGSUBPKT_ISSUER, NULL ); if(p) { - sig->keyid[0] = buffer_to_u32(p); - sig->keyid[1] = buffer_to_u32(p+4); + sig->keyid[0] = buf32_to_u32 (p); + sig->keyid[1] = buf32_to_u32 (p+4); } else if(!(sig->pubkey_algo>=100 && sig->pubkey_algo<=110) && opt.verbose) log_info ("signature packet without keyid\n"); p=parse_sig_subpkt(sig->hashed,SIGSUBPKT_SIG_EXPIRE,NULL); - if(p && buffer_to_u32(p)) - sig->expiredate=sig->timestamp+buffer_to_u32(p); + if(p && buf32_to_u32 (p)) + sig->expiredate = sig->timestamp + buf32_to_u32 (p); if(sig->expiredate && sig->expiredate<=make_timestamp()) sig->flags.expired=1; @@ -2032,9 +2034,8 @@ parse_attribute_subpkts(PKT_user_id *uid) if( n == 255 ) { /* 4 byte length header */ if( buflen < 4 ) goto too_short; - n = (buffer[0] << 24) | (buffer[1] << 16) - | (buffer[2] << 8) | buffer[3]; - buffer += 4; + n = buf32_to_size_t (buffer); + buffer += 4; buflen -= 4; } else if( n >= 192 ) { /* 2 byte special encoded length header */ diff --git a/g10/tdbio.c b/g10/tdbio.c index f109dde..403b608 100644 --- a/g10/tdbio.c +++ b/g10/tdbio.c @@ -1219,13 +1219,13 @@ tdbio_read_record( ulong recnum, TRUSTREC *rec, int expected ) rec->r.ver.trust_model = *p++; rec->r.ver.min_cert_level = *p++; p += 2; - rec->r.ver.created = buftoulong(p); p += 4; - rec->r.ver.nextcheck = buftoulong(p); p += 4; + rec->r.ver.created = buf32_to_ulong (p); p += 4; + rec->r.ver.nextcheck = buf32_to_ulong (p); p += 4; p += 4; p += 4; - rec->r.ver.firstfree =buftoulong(p); p += 4; + rec->r.ver.firstfree =buf32_to_ulong (p); p += 4; p += 4; - rec->r.ver.trusthashtbl =buftoulong(p); p += 4; + rec->r.ver.trusthashtbl =buf32_to_ulong (p); p += 4; if( recnum ) { log_error( _("%s: version record with recnum %lu\n"), db_name, (ulong)recnum ); @@ -1238,17 +1238,17 @@ tdbio_read_record( ulong recnum, TRUSTREC *rec, int expected ) } break; case RECTYPE_FREE: - rec->r.free.next = buftoulong(p); p += 4; + rec->r.free.next = buf32_to_ulong (p); p += 4; break; case RECTYPE_HTBL: for(i=0; i < ITEMS_PER_HTBL_RECORD; i++ ) { - rec->r.htbl.item[i] = buftoulong(p); p += 4; + rec->r.htbl.item[i] = buf32_to_ulong (p); p += 4; } break; case RECTYPE_HLST: - rec->r.hlst.next = buftoulong(p); p += 4; + rec->r.hlst.next = buf32_to_ulong (p); p += 4; for(i=0; i < ITEMS_PER_HLST_RECORD; i++ ) { - rec->r.hlst.rnum[i] = buftoulong(p); p += 4; + rec->r.hlst.rnum[i] = buf32_to_ulong (p); p += 4; } break; case RECTYPE_TRUST: @@ -1257,12 +1257,12 @@ tdbio_read_record( ulong recnum, TRUSTREC *rec, int expected ) rec->r.trust.depth = *p++; rec->r.trust.min_ownertrust = *p++; p++; - rec->r.trust.validlist = buftoulong(p); p += 4; + rec->r.trust.validlist = buf32_to_ulong (p); p += 4; break; case RECTYPE_VALID: memcpy( rec->r.valid.namehash, p, 20); p+=20; rec->r.valid.validity = *p++; - rec->r.valid.next = buftoulong(p); p += 4; + rec->r.valid.next = buf32_to_ulong (p); p += 4; rec->r.valid.full_count = *p++; rec->r.valid.marginal_count = *p++; break; @@ -1570,7 +1570,7 @@ migrate_from_v2 () ottable_size += 1000; ottable = xrealloc (ottable, ottable_size * sizeof *ottable); } - ottable[ottable_used].keyrecno = buftoulong (oldbuf+6); + ottable[ottable_used].keyrecno = buf32_to_ulong (oldbuf+6); ottable[ottable_used].ot = oldbuf[18]; ottable[ottable_used].okay = 0; memset (ottable[ottable_used].fpr,0, 20); diff --git a/g10/trustdb.c b/g10/trustdb.c index a541106..e4317e2 100644 --- a/g10/trustdb.c +++ b/g10/trustdb.c @@ -1624,7 +1624,7 @@ mark_usable_uid_certs (KBNODE keyblock, KBNODE uidnode, u32 expire; p = parse_sig_subpkt (sig->hashed, SIGSUBPKT_SIG_EXPIRE, NULL ); - expire = p? sig->timestamp + buffer_to_u32(p) : 0; + expire = p? sig->timestamp + buf32_to_u32 (p) : 0; if (expire==0 || expire > curtime ) { diff --git a/include/host2net.h b/include/host2net.h index fe0ec41..ecb00dc 100644 --- a/include/host2net.h +++ b/include/host2net.h @@ -1,5 +1,5 @@ -/* host2net.h - Some macros - * Copyright (C) 1998, 1999, 2000, 2001 Free Software Foundation, Inc. +/* host2net.h - Endian conversion macros + * Copyright (C) 1998, 2014, 2015 Werner Koch * * This file is part of GNUPG. * @@ -17,14 +17,11 @@ * along with this program; if not, see . */ -#ifndef G10_HOST2NET_H -#define G10_HOST2NET_H +#ifndef GNUPG_COMMON_HOST2NET_H +#define GNUPG_COMMON_HOST2NET_H #include "types.h" -#define buftoulong( p ) ((*(byte*)(p) << 24) | (*((byte*)(p)+1)<< 16) | \ - (*((byte*)(p)+2) << 8) | (*((byte*)(p)+3))) -#define buftoushort( p ) ((*((byte*)(p)) << 8) | (*((byte*)(p)+1))) #define ulongtobuf( p, a ) do { \ ((byte*)p)[0] = a >> 24; \ ((byte*)p)[1] = a >> 16; \ @@ -35,8 +32,71 @@ ((byte*)p)[0] = a >> 8; \ ((byte*)p)[1] = a ; \ } while(0) -#define buftou32( p) buftoulong( (p) ) -#define u32tobuf( p, a) ulongtobuf( (p), (a) ) -#endif /*G10_HOST2NET_H*/ +static inline unsigned long +buf16_to_ulong (const void *buffer) +{ + const unsigned char *p = buffer; + + return (((unsigned long)p[0] << 8) | p[1]); +} + +static inline unsigned int +buf16_to_uint (const void *buffer) +{ + const unsigned char *p = buffer; + + return (((unsigned int)p[0] << 8) | p[1]); +} + +static inline unsigned short +buf16_to_ushort (const void *buffer) +{ + const unsigned char *p = buffer; + + return (((unsigned short)p[0] << 8) | p[1]); +} + +static inline u16 +buf16_to_u16 (const void *buffer) +{ + const unsigned char *p = buffer; + + return (((u16)p[0] << 8) | p[1]); +} + +static inline size_t +buf32_to_size_t (const void *buffer) +{ + const unsigned char *p = buffer; + + return (((size_t)p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]); +} + +static inline unsigned long +buf32_to_ulong (const void *buffer) +{ + const unsigned char *p = buffer; + + return (((unsigned long)p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]); +} + +static inline unsigned int +buf32_to_uint (const void *buffer) +{ + const unsigned char *p = buffer; + + return (((unsigned int)p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]); +} + +static inline u32 +buf32_to_u32 (const void *buffer) +{ + const unsigned char *p = buffer; + + return (((u32)p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]); +} + + +#endif /*GNUPG_COMMON_HOST2NET_H*/ -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:34 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:34 -0500 Subject: [PATCH 10/13] gpg: Print better diagnostics for keyserver operations. In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-11-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * g10/armor.c (parse_key_failed_line): New. (check_input): Watch out for gpgkeys_ error lines. * g10/filter.h (armor_filter_context_t): Add field key_failed_code. * g10/import.c (import): Add arg r_gpgkeys_err. (import_keys_internal): Ditto. (import_keys_stream): Ditto. * g10/keyserver.c (keyserver_errstr): New. (keyserver_spawn): Detect "KEY " lines while sending. Get gpgkeys_err while receiving keys. (keyserver_work): Add kludge for better error messages. -- GnuPG-bug-id: 1832 Note that these changes can be backported to 1.4 but they don't make sense for 2.1 due to the removal of the keyserver helpers. The error reporting could be improved even more but given that this is an old GnuPG branch it is not justified to put too much effort into it. Signed-off-by: Werner Koch [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- g10/armor.c | 37 +++++++++++++++++++++++++++++++++ g10/filter.h | 2 ++ g10/import.c | 41 +++++++++++++++++++++++++------------ g10/keyserver.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++-------- g10/main.h | 4 +++- 5 files changed, 125 insertions(+), 22 deletions(-) diff --git a/g10/armor.c b/g10/armor.c index c50525c..4332d70 100644 --- a/g10/armor.c +++ b/g10/armor.c @@ -385,6 +385,32 @@ is_armor_header( byte *line, unsigned len ) } +/* Helper to parse a "KEY FAILED " line and return the + error code. LINEPTR points right behind "KEY ". */ +int +parse_key_failed_line (const void *lineptr, unsigned int len) +{ + const byte *line = lineptr; + int code = 0; + + for (; len && !spacep (line); len--, line++) + ; + for (; len && spacep (line); len--, line++) + ; + if (len > 7 && !memcmp (line, "FAILED ", 7)) + { + line += 7; + len -= 7; + for (; len && digitp (line); len--, line++) + { + code *= 10; + code += atoi_1 (line); + } + } + + return code; +} + /**************** * Parse a header lines @@ -505,6 +531,17 @@ check_input( armor_filter_context_t *afx, IOBUF a ) /* find the armor header */ while(len) { i = is_armor_header( line, len ); + if (i == -1 && afx->only_keyblocks + && !afx->key_failed_code + && len > 4 && !memcmp (line, "KEY ", 4)) + { + /* This is probably input from a keyserver helper and we + have not yet seen an error line. */ + afx->key_failed_code = parse_key_failed_line (line+4, len-4); + log_debug ("armor-keys-failed (%.*s) ->%d\n", + (int)len, line, + afx->key_failed_code); + } if( i >= 0 && !(afx->only_keyblocks && i != 1 && i != 5 && i != 6 )) { hdr_line = i; if( hdr_line == BEGIN_SIGNED_MSG_IDX ) { diff --git a/g10/filter.h b/g10/filter.h index 54a4152..f746695 100644 --- a/g10/filter.h +++ b/g10/filter.h @@ -40,6 +40,8 @@ typedef struct { /* these fileds must be initialized to zero */ int no_openpgp_data; /* output flag: "No valid OpenPGP data found" */ + int key_failed_code; /* Error code from the first gpgkkeys_* + "KEY FAILED " line. */ /* the following fields must be initialized to zero */ int inp_checked; /* set if the input has been checked */ diff --git a/g10/import.c b/g10/import.c index c9df368..7050039 100644 --- a/g10/import.c +++ b/g10/import.c @@ -60,7 +60,8 @@ struct stats_s { static int import( IOBUF inp, const char* fname,struct stats_s *stats, unsigned char **fpr,size_t *fpr_len,unsigned int options, - import_filter_t filter, void *filter_arg ); + import_filter_t filter, void *filter_arg, + int *r_gpgkeys_err); static int read_block( IOBUF a, PACKET **pending_pkt, KBNODE *ret_root ); static void revocation_present(KBNODE keyblock); static int import_one(const char *fname, KBNODE keyblock,struct stats_s *stats, @@ -177,7 +178,8 @@ static int import_keys_internal( IOBUF inp, char **fnames, int nnames, void *stats_handle, unsigned char **fpr, size_t *fpr_len, unsigned int options, - import_filter_t filter, void *filter_arg) + import_filter_t filter, void *filter_arg, + int *r_gpgkeys_err) { int i, rc = 0; struct stats_s *stats = stats_handle; @@ -187,7 +189,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, if (inp) { rc = import (inp, "[stream]", stats, fpr, fpr_len, options, - filter, filter_arg); + filter, filter_arg, r_gpgkeys_err); } else { int once = (!fnames && !nnames); @@ -208,7 +210,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, else { rc = import (inp2, fname, stats, fpr, fpr_len, options, - NULL, NULL); + NULL, NULL, r_gpgkeys_err); iobuf_close(inp2); /* Must invalidate that ugly cache to actually close it. */ iobuf_ioctl (NULL, 2, 0, (char*)fname); @@ -240,34 +242,42 @@ import_keys( char **fnames, int nnames, void *stats_handle, unsigned int options ) { import_keys_internal (NULL, fnames, nnames, stats_handle, NULL, NULL, - options, NULL, NULL); + options, NULL, NULL, NULL); } + +/* Import keys from an open stream. */ int import_keys_stream( IOBUF inp, void *stats_handle, unsigned char **fpr, size_t *fpr_len,unsigned int options, - import_filter_t filter, void *filter_arg ) + import_filter_t filter, void *filter_arg, + int *r_gpgkeys_err) { return import_keys_internal (inp, NULL, 0, stats_handle, fpr, fpr_len, - options, filter, filter_arg); + options, filter, filter_arg, r_gpgkeys_err); } + +/* Note: If R_GPGKEYS_ERR is not NULL an error code from the keyserver + helpers will be stored there. */ static int -import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options, - import_filter_t filter, void *filter_arg) +import (IOBUF inp, const char* fname,struct stats_s *stats, + unsigned char **fpr, size_t *fpr_len, unsigned int options, + import_filter_t filter, void *filter_arg, int *r_gpgkeys_err) { PACKET *pending_pkt = NULL; KBNODE keyblock = NULL; int rc = 0; + int need_armor = (!opt.no_armor || r_gpgkeys_err); + armor_filter_context_t *afx = NULL; getkey_disable_caches(); - if( !opt.no_armor ) { /* armored reading is not disabled */ - armor_filter_context_t *afx = new_armor_context (); + if (!opt.no_armor || r_gpgkeys_err) { + /* armored reading is not disabled or enforced. */ + afx = new_armor_context (); afx->only_keyblocks = 1; push_armor_filter (afx, inp); - release_armor_context (afx); } while( !(rc = read_block( inp, &pending_pkt, &keyblock) )) { @@ -297,6 +307,11 @@ import( IOBUF inp, const char* fname,struct stats_s *stats, else if( rc && rc != G10ERR_INV_KEYRING ) log_error( _("error reading `%s': %s\n"), fname, g10_errstr(rc)); + if (afx && r_gpgkeys_err) + *r_gpgkeys_err = afx->key_failed_code; + + release_armor_context (afx); + return rc; } diff --git a/g10/keyserver.c b/g10/keyserver.c index 810713c..d1ddc99 100644 --- a/g10/keyserver.c +++ b/g10/keyserver.c @@ -1040,6 +1040,30 @@ keyserver_retrieval_filter (kbnode_t keyblock, void *opaque) } +static const char * +keyserver_errstr (int code) +{ + const char *s; + + switch (code) + { + case KEYSERVER_OK: s = "success"; break; + case KEYSERVER_INTERNAL_ERROR:s = "keyserver helper internal error"; break; + case KEYSERVER_NOT_SUPPORTED: s = "keyserver not supported"; break; + case KEYSERVER_VERSION_ERROR: s = "keyserver helper version mismatch";break; + case KEYSERVER_GENERAL_ERROR: s = "keyserver helper general error"; break; + case KEYSERVER_NO_MEMORY: s = "keyserver helper is out of core"; break; + case KEYSERVER_KEY_NOT_FOUND: s = "key not found"; break; + case KEYSERVER_KEY_EXISTS: s = "key exists"; break; + case KEYSERVER_KEY_INCOMPLETE:s = "key incomplete (EOF)"; break; + case KEYSERVER_UNREACHABLE: s = "keyserver unreachable"; break; + case KEYSERVER_TIMEOUT: s = "keyserver timeout"; break; + default: s = "?"; break; + } + return s; +} + + static int keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, int count,int *prog,unsigned char **fpr,size_t *fpr_len, @@ -1539,8 +1563,11 @@ keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, plen--; ptr[plen]='\0'; - if(*ptr=='\0') - break; + /* Stop at the first empty line but not if we are sending keys. + In the latter case we won't continue reading later and thus + we need to watch out for errors right in this loop. */ + if(*ptr=='\0' && action != KS_SEND) + break; if(ascii_strncasecmp(ptr,"VERSION ",8)==0) { @@ -1561,6 +1588,14 @@ keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, } else if(ascii_strncasecmp(ptr,"OPTION OUTOFBAND",16)==0) outofband=1; /* Currently the only OPTION */ + else if (action == KS_SEND + && ascii_strncasecmp(ptr,"KEY ",4)==0) + { + ret = parse_key_failed_line (ptr+4, strlen (ptr+4)); + break; /* We stop at the first KEY line so that we won't + run into an EOF which would return an unspecified + error message (due to iobuf_read_line). */ + } } if(!gotversion) @@ -1577,6 +1612,7 @@ keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, { void *stats_handle; struct ks_retrieval_filter_arg_s filterarg; + int gpgkeys_err; stats_handle=import_new_stats_handle(); @@ -1591,14 +1627,21 @@ keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, but we better protect against rogue keyservers. */ filterarg.desc = desc; filterarg.ndesc = count; + gpgkeys_err = 0; import_keys_stream (spawn->fromchild, stats_handle, fpr, fpr_len, (opt.keyserver_options.import_options | IMPORT_NO_SECKEY), - keyserver_retrieval_filter, &filterarg); + keyserver_retrieval_filter, &filterarg, + &gpgkeys_err); import_print_stats(stats_handle); import_release_stats_handle(stats_handle); - + if (gpgkeys_err) + { + log_error (_("keyserver communications error: %s\n"), + keyserver_errstr (gpgkeys_err)); + ret = gpgkeys_err; + } break; } @@ -1619,7 +1662,6 @@ keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, xfree(line); xfree(searchstr); - *prog=exec_finish(spawn); return ret; @@ -1644,9 +1686,11 @@ keyserver_work(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, return G10ERR_KEYSERVER; #else - /* Spawn a handler */ - + /* Spawn a handler. The use of RC and RET is a mess. We use a + kludge to return a suitable error message. */ rc=keyserver_spawn(action,list,desc,count,&ret,fpr,fpr_len,keyserver); + if (ret == KEYSERVER_INTERNAL_ERROR && rc) + ret = rc; if(ret) { switch(ret) @@ -1675,6 +1719,9 @@ keyserver_work(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, log_error(_("keyserver timed out\n")); break; + case KEYSERVER_UNREACHABLE: + return G10ERR_UNKNOWN_HOST; + case KEYSERVER_INTERNAL_ERROR: default: log_error(_("keyserver internal error\n")); @@ -2127,7 +2174,7 @@ keyserver_import_cert(const char *name,unsigned char **fpr,size_t *fpr_len) rc=import_keys_stream (key, NULL, fpr, fpr_len, (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY), NULL, NULL); + | IMPORT_NO_SECKEY), NULL, NULL, NULL); opt.no_armor=armor_status; diff --git a/g10/main.h b/g10/main.h index 05a4059..05b60bb 100644 --- a/g10/main.h +++ b/g10/main.h @@ -67,6 +67,7 @@ void print_digest_algo_note( int algo ); /*-- armor.c --*/ char *make_radix64_string( const byte *data, size_t len ); +int parse_key_failed_line (const void *lineptr, unsigned int len); /*-- misc.c --*/ void trap_unaligned(void); @@ -216,7 +217,8 @@ void import_keys( char **fnames, int nnames, void *stats_hd, unsigned int options ); int import_keys_stream (IOBUF inp,void *stats_hd,unsigned char **fpr, size_t *fpr_len,unsigned int options, - import_filter_t filter, void *filter_arg); + import_filter_t filter, void *filter_arg, + int *r_gpgkeys_err); void *import_new_stats_handle (void); void import_release_stats_handle (void *p); void import_print_stats (void *hd); -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:33 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:33 -0500 Subject: [PATCH 09/13] keyserver: Show log prefix when not build with cURL. In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-10-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * keyserver/ksutil.c (init_ks_options) [!HAVE_LIBCURL]: Set logging prefix. Signed-off-by: Werner Koch [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- keyserver/ksutil.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/keyserver/ksutil.c b/keyserver/ksutil.c index b2efd00..5f21a1b 100644 --- a/keyserver/ksutil.c +++ b/keyserver/ksutil.c @@ -89,6 +89,12 @@ init_ks_options(void) { struct ks_options *opt; +#ifndef HAVE_LIBCURL + /* Without cURL we use our own HTTP module which uses our logging + subsystem. Thus we need to init that. */ + log_set_prefix ("gpgkeys", JNLIB_LOG_WITH_PREFIX); +#endif /*!HAVE_LIBCURL*/ + opt=calloc(1,sizeof(struct ks_options)); if(opt) -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:31 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:31 -0500 Subject: [PATCH 07/13] doc: Change remaining http links to gnupg.org to https In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-8-git-send-email-dkg@fifthhorseman.net> From: Werner Koch -- GnuPG-bug-id: 1830 [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- doc/gpg.texi | 2 +- g10/misc.c | 4 ++-- g10/sig-check.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index acfc026..ae3931a 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -321,7 +321,7 @@ useful for debugging. Present a menu to work with a smartcard. The subcommand "help" provides an overview on available commands. For a detailed description, please see the Card HOWTO at -http://www.gnupg.org/documentation/howtos.html#GnuPG-cardHOWTO . +https://gnupg.org/documentation/howtos.html#GnuPG-cardHOWTO . @item --card-status @opindex card-status diff --git a/g10/misc.c b/g10/misc.c index 68b4cea..60ecf96 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -462,7 +462,7 @@ md5_digest_warn (int show) log_info (_("WARNING: digest algorithm %s is deprecated\n"), digest_algo_to_string (DIGEST_ALGO_MD5)); log_info (_("please see %s for more information\n"), - "http://www.gnupg.org/faq/weak-digest-algos.html"); + "https://gnupg.org/faq/weak-digest-algos.html"); warned = 1; } } @@ -477,7 +477,7 @@ not_in_gpg1_notice (void) { log_info (_("NOTE: This feature is not available in %s\n"), "GnuPG 1.x"); log_info (_("please see %s for more information\n"), - "http://www.gnupg.org/faq/features-not-in-gnupg-1.html"); + "https://gnupg.org/faq/features-not-in-gnupg-1.html"); warned = 1; } } diff --git a/g10/sig-check.c b/g10/sig-check.c index d6bbb92..b7709c1 100644 --- a/g10/sig-check.c +++ b/g10/sig-check.c @@ -99,7 +99,7 @@ signature_check2( PKT_signature *sig, MD_HANDLE digest, u32 *r_expiredate, log_info(_("WARNING: signing subkey %s is not" " cross-certified\n"),keystr_from_pk(pk)); log_info(_("please see %s for more information\n"), - "http://www.gnupg.org/faq/subkey-cross-certify.html"); + "https://gnupg.org/faq/subkey-cross-certify.html"); /* --require-cross-certification makes this warning an error. TODO: change the default to require this after more keys have backsigs. */ -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 05:10:36 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 23:10:36 -0500 Subject: [PATCH 12/13] gpg: Remove an unused variable. In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1424578237-12925-13-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * g10/import.c (import): Remove need_armor. [dkg: rebased to STABLE-BRANCH-1-4] Signed-off-by: Daniel Kahn Gillmor --- g10/import.c | 1 - 1 file changed, 1 deletion(-) diff --git a/g10/import.c b/g10/import.c index 7050039..4620c5f 100644 --- a/g10/import.c +++ b/g10/import.c @@ -268,7 +268,6 @@ import (IOBUF inp, const char* fname,struct stats_s *stats, PACKET *pending_pkt = NULL; KBNODE keyblock = NULL; int rc = 0; - int need_armor = (!opt.no_armor || r_gpgkeys_err); armor_filter_context_t *afx = NULL; getkey_disable_caches(); -- 2.1.4 From dkg at fifthhorseman.net Sun Feb 22 07:12:25 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 22 Feb 2015 01:12:25 -0500 Subject: [PATCH] Point to the correct URLs for the FAQ Message-ID: <1424585545-16279-1-git-send-email-dkg@fifthhorseman.net> * doc/FAQ: correct URLs, use https -- The old FAQ URLs (http://www.gnupg.org/faq/GnuPG-FAQ.html) return versions from the end of 2012. We probably also want to replace those with an HTTP redirect to the correct page. I also note that the plaintext version of the FAQ is sent by the web server with the following header: Content-Type: text/plain Note the lack of a charset parameter. The file itself appears to contain UTF-8-encoded text. Many user-agents still interpret the lack of a charset parameter to mean an encoding of iso-8859-1. I recommend that the server send the following instead: Content-Type: text/plain;charset=utf-8 Signed-off-by Daniel Kahn Gillmor --- doc/FAQ | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/doc/FAQ b/doc/FAQ index 32d0744..d5f2a19 100644 --- a/doc/FAQ +++ b/doc/FAQ @@ -3,11 +3,8 @@ GnuPG Frequently Asked Questions A FAQ is a fast moving target and thus we don't distribute it anymore with GnuPG. You may retrieve the current FAQ in HTML format at - http://www.gnupg.org/faq/GnuPG-FAQ.html + https://gnupg.org/faq/gnupg-faq.html or in plain text format at the FTP server: - ftp://ftp.gnupg.org/gcrypt/gnupg/GnuPG-FAQ.txt - - - + https://gnupg.org/faq/gnupg-faq.txt -- 2.1.4 From Mento at gpgtools.org Sun Feb 22 13:17:09 2015 From: Mento at gpgtools.org (Roman Zechmeister) Date: Sun, 22 Feb 2015 13:17:09 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: Hello! > It seems there's http://github.com/GPGTools/pinentry now, which is based on the original pinentry. This repo is my quick check, if it's possible to integrate pinentry-mac into pinentry. It's more or less our code for pinentry-mac, copied into the sub-dir macosx. The most of the code is old and ugly, but it works. So i'm thinking about a complete rewrite. There are some points, i want to clear, before i start to work on this: 1. On Mac OS X it's standard to use Xcode for builds and we're using it for pinentry-mac and all of our other tools. Is it okay for you, if we're using an Xcode-Project and Xcode, instead of plain automake, to build pinentry for Mac OS X? 2. Should we compile the required source-code from pinentry direct into pinentry-mac (as we do actually) or should we link against the libs? 3. pinentry-mac allows the user to store the passphrase in the Mac OS X keychain, by selecting a checkbox. To make this possible, we're patching gpg-agent, to pass the cacheid to pinentry. (OPTION cache-id=xxx) Without this option ? e.g. upstream gpg-agent ? pinentry-mac doesn't allow the user to store the passphrase. How should we solve this in the future? 4. pinentry-mac allows the calling app to define a custom message to show. This is implemented using PINENTRY_USER_DATA. We allow placeholders like %KEYID and %USERID. To fill the placeholders, we parse the description from pinentry. This works in the most cases. The reason for this feature is, to allow some more informative and readable messages. e.g. We can tell the user for which email/file, he enters the passphrase. What do you think about that? Is this a desirable feature for pinentry? 5. Using PINENTRY_USER_DATA we also allow to set a custom icon to be shown, like the standard Mac OS X security dialog. Opinions? Regards, Mento -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From patrick at enigmail.net Sun Feb 22 16:13:19 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 22 Feb 2015 16:13:19 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: <54E9F20F.9040506@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 22.02.15 13:17, Roman Zechmeister wrote: > Hello! > >> It seems there's http://github.com/GPGTools/pinentry now, which >> is based on the original pinentry. > > This repo is my quick check, if it's possible to integrate > pinentry-mac into pinentry. It's more or less our code for > pinentry-mac, copied into the sub-dir macosx. The most of the code > is old and ugly, but it works. So i'm thinking about a complete > rewrite. That's a _very_ good idea! > There are some points, i want to clear, before i start to work on > this: > > 1. On Mac OS X it's standard to use Xcode for builds and we're > using it for pinentry-mac and all of our other tools. Is it okay > for you, if we're using an Xcode-Project and Xcode, instead of > plain automake, to build pinentry for Mac OS X? I'd say that this should be OK. Automake should probably simply be able to determine that it's compiling for OS X and then use the XCode project. > 2. Should we compile the required source-code from pinentry direct > into pinentry-mac (as we do actually) or should we link against > the libs? I would prefer the same approach as all other pinentry-frontends, that is, libpinentry.a is linked into the frontend. > 3. pinentry-mac allows the user to store the passphrase in the Mac > OS X keychain, by selecting a checkbox. To make this possible, > we're patching gpg-agent, to pass the cacheid to pinentry. (OPTION > cache-id=xxx) Without this option ? e.g. upstream gpg-agent ? > pinentry-mac doesn't allow the user to store the passphrase. How > should we solve this in the future? > > 4. pinentry-mac allows the calling app to define a custom message > to show. This is implemented using PINENTRY_USER_DATA. We allow > placeholders like %KEYID and %USERID. To fill the placeholders, we > parse the description from pinentry. This works in the most > cases. The reason for this feature is, to allow some more > informative and readable messages. e.g. We can tell the user for > which email/file, he enters the passphrase. What do you think about > that? Is this a desirable feature for pinentry? I think this is a desirable feature of pinentry in general. Other tools could profit from it as well. > 5. Using PINENTRY_USER_DATA we also allow to set a custom icon to > be shown, like the standard Mac OS X security dialog. Opinions? Same as above. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU6fINAAoJENsRh7ndX2k79YEP/21NKT2rT/ntCfXbxURn4Ssx DgJ5EMe0gGZcNk/3iox8QCvvyiIZVgsoc4XtLTaMS76PC74yOywdq7rXsUk2GA/4 o02LyfQpWC4YywrsdGTTgHrz2xgowiwhHPvekFodszdjBIM/K3i5aVm0ZczgCCDp LxdVU+/Ba05EfQDSmJ36JBow+glOobKfcR9av3AfKo9O6CkHmYp+7lPiEx1vIELq gWXKcMjN4tiFz9b6Uh68OYB8UiZ8/DT5g3LOIIvF1Fb/O9Q4ObutofEm7gp3Qngp 8jw20dQQZX9JH4sLgTLCWA7g98xXwMGv9576Z1gCjA/tj/2JtisUh2y+sSrzyQVY iRfsmkhn3B2X8UNK3scUjlp9jFTC7GSBTP/fQehLQo/r27v2Ln0ScL1mHkAS/157 rB3bz4/O6zNyY8e1WvhiU/dRzM64RDoTAGSeAz8l3OeAWx82arV6ai+no8fY8DWP 2ixxVDVefZ8dNLliEyoAme+vi6j4jCvYOJeNT42IOnjVItY7gvxK64uGuBXGZ52X 32qJ7Xq01oIqWN1B6Fyo9JSfHPyfUuHA7SxNkKf5+duTU+i3UNtFBcZ48rGx8hA4 o7i0ki9Q5pOihzfXWZnBMOFfbGnrAlWOsr8oN9PITI7ce2ZtDpZet53Y29FxF1Bu EcqFrjmcZcKT+cAM4LCB =xEeO -----END PGP SIGNATURE----- From Mento at gpgtools.org Sun Feb 22 17:55:08 2015 From: Mento at gpgtools.org (Roman Zechmeister) Date: Sun, 22 Feb 2015 17:55:08 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: <8146F873-C161-4DC6-9FDE-47C065F12105@gpgtools.org> Hello Jonathan! > This could be used to trick the user into thinking he's doing the right thing when in fact he's not. What if you just don't use %KEYID, but write another key ID there that the user expects, when in fact you sign for something else? If you want to trick a user, you could simply run they few lines below. So i don't think that's a reason to not add feature. string='GET_PASSPHRASE 12345678 X Passphrase Please+enter+the+passphrase+'\ 'to+unlock+the+secret+key+for+the+OpenPGP+certificate:%0A%22Example+User+'\ '%22%0A4096-bit+RSA+key,+ID+12345678,%0Acreated+1503-02-29.%0A' gpg-agent --server <<<"$string" 2>/dev/null | sed -n '2s/OK //p' | xxd -p -r Regards, Mento -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From albrecht.dress at arcor.de Sun Feb 22 19:14:36 2015 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Sun, 22 Feb 2015 19:14:36 +0100 Subject: Encrypting / Signing the mail subject? In-Reply-To: <87mw5ixyee.fsf@alice.fifthhorseman.net> Message-ID: <1424628876.3637.1@deneb.(none)> A non-text attachment was scrubbed... Name: not available Type: text/rfc822-headers Size: 460 bytes Desc: not available URL: -------------- next part -------------- Hi Daniel: I am currently working on the implementation of your proposal for Balsa [1], and would like to add a few comments. Am 16.01.15 21:29 schrieb(en) Daniel Kahn Gillmor: > PGP/MIME messages are the only reliably structured mail OpenPGP e-mail messages anyway [0]. As your proposal is fully transparent, I think it could also be used for RFC 2633 S/MIME (i.e. multipart/signed; application/pkcs7-signature as well as for application/pkcs7-mime). > The embedded header part (F, above) should be Content-Disposition: inline, and should be subject to all the usual rules of parsing mail message headers. In your example, you added a "charset" parameter to the mime type. IMHO, this contradicts the RFC 6522 statement that it shall have neither required nor optional parameters. I think it's unneeded anyway, as all headers shall be encoded as required by RFC 2047. Applying the "usual" header parsing rules will of course decode them properly. The whole part /should/ be encoded quoted-printable, though, as required by RFC 3156, sect. 3. The headers /should/ be 7-bit clean, but you never know for sure... > This e-mail message contains a signed set of embedded headers in the way i've proposed. How does it render in your unaware MUA? feel free to send me a private report if you like. What do you think about always adding a header, e.g. "X-Protected-Headers", which includes a short info about the purpose of that part (as in this example)? Otherwise, it might be somewhat confusing if such a MUA displays the header twice. If we can agree on a standard name, it also assists MUA's to detect the block. > signed_headers: > * Subject > * Date > * From > * To > * Cc As including more headers doesn't cost much, I propose to also add the following: - Reply-To: and Disposition-Notification-To:. Rationale: an attacker might tamper them as to provoke sending information to arbitrary recipients (at least for inattentive users, or for MUA's sending MDN's automatically). - References: and In-Reply-To:. Rationale: avoids breaking the threading information by an attacker. > encrypted_headers: > * (Subject,"ENCRYPTED SUBJECT") > * (In-Reply-To,) > * (References,) IMHO, the list of encrypted headers could be the same as above. > We'd also need to define what happens if more than one text/rfc822-headers part shows up in a multipart message -- most simply, we could say that we only process text/rfc822-headers if it happens to be the first non-multipart part within the multipart/signed or multipart/encrypted part. I think this should read: "if the text/rfc822-headers part is * the first part of a multipart/mixed, which in turn is the first part of the top-level multipart/signed or application/pkcs7-mime, or * the first part of the top-level decrypted multipart/mixed for unsigned, but encrypted messages." > This prevents the receiving MUA from applying text/rfc822-headers from a forwarded (attached) signed/encrypted message. It would make sense, though, to verify if the headers of forwarded and signed message/rfc822 parts against the (embedded) text/rfc822-headers parts. > If some are unacceptable, should we have a blocklist (allow arbitrary headers by default, only reject certain ones) or an allowlist (block arbitrary headers by default, only accept certain ones like Subject and date)? IMHO, a whitelist is easier to handle. Any comments? Just my ?0.01... Cheers, Albrecht. [1] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From chdiza at gmail.com Mon Feb 23 05:47:01 2015 From: chdiza at gmail.com (Charles Diza) Date: Sun, 22 Feb 2015 23:47:01 -0500 Subject: Integrate pinentry-mac into pinentry In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: On Sun, Feb 22, 2015 at 7:17 AM, Roman Zechmeister wrote: > Hello! > > > It seems there's http://github.com/GPGTools/pinentry now, which is > based on the original pinentry. > > This repo is my quick check, if it's possible to integrate pinentry-mac > into pinentry. > It's more or less our code for pinentry-mac, copied into the sub-dir > macosx. > The most of the code is old and ugly, but it works. So i'm thinking about > a complete rewrite. > > > There are some points, i want to clear, before i start to work on this: > > 1. On Mac OS X it's standard to use Xcode for builds and we're using it > for pinentry-mac and all of our other tools. > Is it okay for you, if we're using an Xcode-Project and Xcode, instead of > plain automake, to build pinentry for Mac OS X? > Whatever happens here, a vanilla pinentry MUST still be buildable on older MacOSX systems. Pinentry-mac and its Xcodeproj have long since abandoned 10.4, 10.5, and (I think) 10.6. Users on those systems should still be able to build a non-GUI pinentry (as they can now), so an Xcode project should only come into play for newer systems. -Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Feb 23 11:05:18 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Feb 2015 11:05:18 +0100 Subject: [PATCH 09/13] keyserver: Show log prefix when not build with cURL. In-Reply-To: <1424578237-12925-10-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 21 Feb 2015 23:10:33 -0500") References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> <1424578237-12925-10-git-send-email-dkg@fifthhorseman.net> Message-ID: <87wq392ba9.fsf@vigenere.g10code.de> On Sun, 22 Feb 2015 05:10, dkg at fifthhorseman.net said: > From: Werner Koch > > * keyserver/ksutil.c (init_ks_options) [!HAVE_LIBCURL]: Set logging > prefix. That does not work too well in 1.4. It was anyway only a cosmetic change. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Feb 23 11:09:46 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Feb 2015 11:09:46 +0100 Subject: Backporting fixes to STABLE-BRANCH-1-4 In-Reply-To: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 21 Feb 2015 23:10:24 -0500") References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87sidx2b2t.fsf@vigenere.g10code.de> On Sun, 22 Feb 2015 05:10, dkg at fifthhorseman.net said: > A lot of good bug-fixes and minor improvments have landed on the 2.0 > and 2.1 branches recently, but several of those fixes haven't made it > to the 1.4 branch. Thanks for helping with this. Really appreciated. > Please let me know if there are any issues with this series, its > presentation, or its approach. You may have mentioned from which branch you backported it, but that is not really an issue. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Mon Feb 23 21:15:51 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 23 Feb 2015 15:15:51 -0500 Subject: Backporting fixes to STABLE-BRANCH-1-4 In-Reply-To: <87sidx2b2t.fsf@vigenere.g10code.de> References: <1424578237-12925-1-git-send-email-dkg@fifthhorseman.net> <87sidx2b2t.fsf@vigenere.g10code.de> Message-ID: <87twycv0y0.fsf@alice.fifthhorseman.net> On Mon 2015-02-23 05:09:46 -0500, Werner Koch wrote: > On Sun, 22 Feb 2015 05:10, dkg at fifthhorseman.net said: >> A lot of good bug-fixes and minor improvments have landed on the 2.0 >> and 2.1 branches recently, but several of those fixes haven't made it >> to the 1.4 branch. > > Thanks for helping with this. Really appreciated. glad it was useful! >> Please let me know if there are any issues with this series, its >> presentation, or its approach. > > You may have mentioned from which branch you backported it, but that is > not really an issue. right, i'll try to do that for future work. --dkg From wk at gnupg.org Tue Feb 24 11:39:13 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Feb 2015 11:39:13 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: <54E9F20F.9040506@enigmail.net> (Patrick Brunschwig's message of "Sun, 22 Feb 2015 16:13:19 +0100") References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> <54E9F20F.9040506@enigmail.net> Message-ID: <87ioery4oe.fsf@vigenere.g10code.de> On Sun, 22 Feb 2015 16:13, patrick at enigmail.net said: > That's a _very_ good idea! Seconded. > I'd say that this should be OK. Automake should probably simply be > able to determine that it's compiling for OS X and then use the XCode > project. Nope. That that is a bad idea. The build system is based on standard Makefiles generated via automake and autoconf and I am strongly against any other build systems. We have this discussion every few years related to Windows and I do not want to repeat this. It is important to be able to cross-build everything using a free (and audit-able platform). Form my understanding Xcode is a non-text proprietary thing like Visual Studio projects for Windows. If there is a sound reason why _autoconf_ can't work on that platform, a dedicated config file might be acceptable (cf. the VMS port). But for a BSD based OS I can's see a compelling reason. >> 4. pinentry-mac allows the calling app to define a custom message >> to show. This is implemented using PINENTRY_USER_DATA. We allow >> placeholders like %KEYID and %USERID. To fill the placeholders, we >> parse the description from pinentry. This works in the most >> cases. The reason for this feature is, to allow some more >> informative and readable messages. e.g. We can tell the user for >> which email/file, he enters the passphrase. What do you think about >> that? Is this a desirable feature for pinentry? > > I think this is a desirable feature of pinentry in general. Other > tools could profit from it as well. This violates the security barrier of gpg-agent. Any application could trick a user into doing things he does not want. For keys controlled by gpg-agent the shown key identification should come from gpg-agent without any user overridable string. It is a different thing to allow additional information to be displayed. If there is a need for it it can be added but it should be specified in the gpg-agent/pinentry protocol. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Mento at gpgtools.org Tue Feb 24 12:37:24 2015 From: Mento at gpgtools.org (Roman Zechmeister) Date: Tue, 24 Feb 2015 12:37:24 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: <87ioery4oe.fsf@vigenere.g10code.de> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de> Message-ID: <3A741587-62BE-415D-8156-48A9C7E808A9@gpgtools.org> Hello Werner! > This violates the security barrier of gpg-agent. Any application could > trick a user into doing things he does not want. For keys controlled by > gpg-agent the shown key identification should come from gpg-agent > without any user overridable string. > > It is a different thing to allow additional information to be displayed. > If there is a need for it it can be added but it should be specified in > the gpg-agent/pinentry protocol. My idea is not to allow to override the shown Fingerprint/KeyID. The idea is to allow a more intuitive and informative message. Normally the message comes from gpg and not from gpg-agent. The message could also come from any other software using gpg-agent directly. Also have a look at my last mail on the devel list (22 Feb, 17:55). Btw. the same attack could be used on pinentry, to show a fake message. Regards, Mento -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From wk at gnupg.org Tue Feb 24 14:51:27 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Feb 2015 14:51:27 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: <3A741587-62BE-415D-8156-48A9C7E808A9@gpgtools.org> (Roman Zechmeister's message of "Tue, 24 Feb 2015 12:37:24 +0100") References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de> <3A741587-62BE-415D-8156-48A9C7E808A9@gpgtools.org> Message-ID: <878ufnxvs0.fsf@vigenere.g10code.de> On Tue, 24 Feb 2015 12:37, Mento at gpgtools.org said: > Normally the message comes from gpg and not from gpg-agent. Right, that is the case for OpenPGP messages. But after all gpg-agent decides what to display. The gpg-agent command SETKEYDESC is used to tell gpg-agent about the OpenPGP properties and desired operation of the requested key. However, gpg-agent may eventually be changed to screen that information for correctness. This is in particular important when gpg is used via a remote socket. > Btw. the same attack could be used on pinentry, to show a fake message. Conceptually it is not allowed that pinentry is used by other software than gpg-agent. Today gpg-agent is mostly used within the same security boundary as gpg (under the same user and on the same box) and thus there is no enforcement of it. However, using a SE-Linux it is possible to enforce that even on current systems. PINENTRY_USER_DATA was implemented to allow the use of a web interface for Pinentry. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From guilhem at fripost.org Wed Feb 25 01:07:16 2015 From: guilhem at fripost.org (Guilhem Moulin) Date: Wed, 25 Feb 2015 01:07:16 +0100 Subject: [PATCH] Fix import option name: s/import-keep-ownertrust/keep-ownertrust/. Message-ID: <1424822836-19168-1-git-send-email-guilhem@fripost.org> ?keep-ownertrust? is the name found in import.c. --- doc/gpg.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index 79fe234..b90f487 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2019,7 +2019,7 @@ opposite meaning. The options are: generally useful unless a shared keyring scheme is being used. Defaults to no. - @item import-keep-ownertrust + @item keep-ownertrust Normally possible still existing ownertrust values of a key are cleared if a key is imported. This is in general desirable so that a formerly deleted key does not automatically gain an ownertrust -- 2.1.4 From guilhem at fripost.org Wed Feb 25 10:14:20 2015 From: guilhem at fripost.org (Guilhem Moulin) Date: Wed, 25 Feb 2015 10:14:20 +0100 Subject: Benchmarking key listing: pubring.kbx vs pubring.gpg, 1.4 vs 2.1 Message-ID: <20150225091420.GA2052@localhost> TL;DR: * --list-keys is slower than (one would naively think) it should be * --list-sigs is quadratic (O(mn), where m is the total number of signatures, and n the number of keys in the keyring) due to the primary UID search on each signing key * --list-sigs with a keybox is too slow to be usable with large keyrings (probably a bug) Hi list, The new keybox format looks very appealing for large keyrings: ?Random access to the keys is now really fast and keyrings with 30000 keys and more are now easily possible.? ? https://gnupg.org/faq/whats-new-in-2.1.html#keybox However key listing doesn't seem to scale that well :-/ The timings below are from my X60, Core? Duo L2400 1.66GHz; I also run the benchmark on a Core? i7-4770S 3.10GHz, and while it's of course faster then the general observation remains. $ gpg --version | head -1 gpg (GnuPG) 1.4.18 $ gpg2 --version | head -1 gpg (GnuPG) 2.1.2 Starting with fresh copies of my keyring (containing 1245 keys) as pubring.gpg and pubring.kbx: $ mkdir -m0700 /tmp/gnupg1 /tmp/gnupg2 $ echo 'trust-model always' | tee /tmp/gnupg1/gpg.conf >/tmp/gnupg2/gpg.conf $ echo no-autostart >>/tmp/gnupg2/gpg.conf $ gpg2 --export | gpg --homedir /tmp/gnupg1 --import [?] gpg: Total number processed: 1245 gpg: imported: 1245 (RSA: 979) $ gpg2 --export | gpg2 --homedir /tmp/gnupg2 --import [?] gpg: Total number processed: 1245 gpg: imported: 1245 $ stat --printf="%s %n\n" /tmp/gnupg1/pubring.gpg /tmp/gnupg2/pubring.kbx 77957249 /tmp/gnupg1/pubring.gpg 78184432 /tmp/gnupg2/pubring.kbx $ alias time="/usr/bin/time -f '%E (%U user, %S sys) %Mk maxres'" Doing a key listing takes roughly the same time on the fresh GnuPGHOMEs; surprisingly enough 2.1 is slower than 1.4 on legacy public keyrings, and it takes almost twice as long on my ~/.gnupg (which contains a pubring.kbx but no pubring.gpg); I have no idea why. $ time gpg --homedir /tmp/gnupg1 --list-keys >/dev/null 0:05.25 (5.09 user, 0.14 sys) 9084k maxres $ time gpg2 --homedir /tmp/gnupg2 --list-keys >/dev/null 0:04.98 (4.84 user, 0.12 sys) 14360k maxres $ time gpg2 --homedir /tmp/gnupg1 --list-keys >/dev/null 0:07.24 (7.14 user, 0.08 sys) 9580k maxres $ time gpg2 --options /tmp/gnupg2/gpg.conf --list-keys >/dev/null 0:09.06 (8.94 user, 0.10 sys) 14264k maxres I wonder where the bottleneck is anyway: listing slightly over a thousands keys shouldn't take several seconds IMHO. By comparison using kbxutil(1) to dump the pubring.kbx is 10x faster: $ time kbxutil /tmp/gnupg2/pubring.kbx >/dev/null 0:00.66 (0.60 user, 0.05 sys) 4888k maxres Listing signatures is not really usable as it takes quite a while already with the legacy pubring.gpg, and much much longer with the new pubring.kbx. (I didn't compute the asymptotic complexities exactly, but as shown below the difference doesn't seem to be a constant factor.) $ time gpg --homedir /tmp/gnupg1 --list-sigs >/dev/null 1:57.54 (83.55 user, 33.57 sys) 9264k maxres $ time gpg2 --homedir /tmp/gnupg2 --list-sigs >/dev/null 2:24:34 (564.61 user, 8083.49 sys) 14936k maxres $ time gpg2 --homedir /tmp/gnupg2 --fast-list-mode --list-sigs >/dev/null 0:05.97 (5.88 user, 0.07 sys) 14296k maxres $ time gpg2 --homedir /tmp/gnupg1 --list-sigs >/dev/null 1:57.55 (89.15 user, 28.07 sys) 9740k maxres The second timming is really odd: over 2h of system time? Surely it must be a bug. The difference is already noticeable with a single key 0x39278DA8109E6244 with 1322 signatures, 953 for which the signing key is also present in my keyring: $ gpg2 --with-colons --list-sigs 0x39278DA8109E6244 | grep -c ^sig: 1322 $ gpg2 --with-colons --list-sigs 0x39278DA8109E6244 | grep -Ec '^sig:([^:]*:){8}\[User ID not found\]:' 369 $ time gpg --homedir /tmp/gnupg1 --list-sigs 0x39278DA8109E6244 >/dev/null 0:17.24 (11.72 user, 5.46 sys) 8852k maxres $ time gpg2 --homedir /tmp/gnupg2 --list-sigs 0x39278DA8109E6244 >/dev/null 0:30.85 (3.26 user, 27.50 sys) 14564k maxres $ time gpg2 --homedir /tmp/gnupg1 --list-sigs 0x39278DA8109E6244 >/dev/null 0:17.16 (12.58 user, 4.54 sys) 9608k maxres Once again, I don't understand the difference between pubring.gpg and pubring.kbx, especially why dumping the latter spends most of its time in kernel mode. But as I explained in a patch (unmerged as of 2.1.2) last autumn [0], the fact that --list-sigs takes that long is because it searches the primary UID of the signing keys, and as there is no caching ?get_user_id? is called *for every sig*, and at each iteration this function walks through the *whole* keyring and packs the whole public part of the signing key. All in all, the algorithm for listing signatures seems highly suboptimal. In my earlier patch [0] I proposed to make --fast-list-mode work better with --list-sigs (not printing the primary UID of the signing keys hence skipping the quadratic search. The primary UIDs could later be retrieved by using --list-keys on the whole list of signing keys without duplicates, albeit at the expense of extra memory allocation.) But as shown above kbxutil is capable of dumping the whole pubring.kbx in half a second, dump from where all primary UIDs can be retrieved, so I guess that with caching ?get_user_id? could be made much faster ;-) $ kbxutil /tmp/gnupg2/pubring.kbx | grep -E '^(Uid|Key-Kid)\[0\]' Or even better, since ?random access to the keys is now really fast?, presumably getting the pubkey off a keybox from its 64 bits key ID can be done in sub-linear time (not sure, I couldn't find the specs for the keybox format) via some kind of hash table. Caching might not be needed after all ;-) -- Guilhem. [0] http://lists.gnupg.org/pipermail/gnupg-devel/2014-September/028739.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From hans at guardianproject.info Wed Feb 25 15:28:09 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 25 Feb 2015 15:28:09 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: <87ioery4oe.fsf@vigenere.g10code.de> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de> Message-ID: <54EDDBF9.3030108@guardianproject.info> Werner Koch: > On Sun, 22 Feb 2015 16:13, patrick at enigmail.net said: > >> That's a _very_ good idea! > > Seconded. > >> I'd say that this should be OK. Automake should probably simply be >> able to determine that it's compiling for OS X and then use the XCode >> project. > > Nope. That that is a bad idea. The build system is based on standard > Makefiles generated via automake and autoconf and I am strongly against > any other build systems. We have this discussion every few years > related to Windows and I do not want to repeat this. It is important to > be able to cross-build everything using a free (and audit-able platform). > Form my understanding Xcode is a non-text proprietary thing like Visual > Studio projects for Windows. > > If there is a sound reason why _autoconf_ can't work on that platform, a > dedicated config file might be acceptable (cf. the VMS port). But for a > BSD based OS I can's see a compelling reason. > >>> 4. pinentry-mac allows the calling app to define a custom message >>> to show. This is implemented using PINENTRY_USER_DATA. We allow >>> placeholders like %KEYID and %USERID. To fill the placeholders, we >>> parse the description from pinentry. This works in the most >>> cases. The reason for this feature is, to allow some more >>> informative and readable messages. e.g. We can tell the user for >>> which email/file, he enters the passphrase. What do you think about >>> that? Is this a desirable feature for pinentry? >> >> I think this is a desirable feature of pinentry in general. Other >> tools could profit from it as well. > > This violates the security barrier of gpg-agent. Any application could > trick a user into doing things he does not want. For keys controlled by > gpg-agent the shown key identification should come from gpg-agent > without any user overridable string. > > It is a different thing to allow additional information to be displayed. > If there is a need for it it can be added but it should be specified in > the gpg-agent/pinentry protocol. I'm not sure this provides any real protection, and it does make for a worse UI, which generally translated into worse security. A malicious app could just make a custom pinentry app that looks however it wants, and basically make a phishing interface that also interacts with gpg-agent. If you don't trust your locally installed apps, there is not much you can do about it in the software. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 From wk at gnupg.org Wed Feb 25 16:49:16 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 25 Feb 2015 16:49:16 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: <54EDDBF9.3030108@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 25 Feb 2015 15:28:09 +0100") References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de> <54EDDBF9.3030108@guardianproject.info> Message-ID: <87bnkiuh37.fsf@vigenere.g10code.de> On Wed, 25 Feb 2015 15:28, hans at guardianproject.info said: > UI, which generally translated into worse security. A malicious app could > just make a custom pinentry app that looks however it wants, and basically Right. However, there are ways to avoid that. The SAK feature on older systems or a visual effect only controllable by an OS trusted process is what pinentry would need. And of course there is the idea of using gpg-agent and thus pinentry on a separate device. Another reasons against adding arbitrary UI features to Pinentry is that as soon as you do it more features will be requested and the former sharp boundaries between gpg-agent/pinentry will become fuzzy. Such overloading has often been the cause for opening new attack paths to a system. Pinentry was once decide to do just one thing and that is it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 25 17:03:38 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 25 Feb 2015 17:03:38 +0100 Subject: PKA updates Message-ID: <874mqaugf9.fsf@vigenere.g10code.de> Hi! For about a decade GnuPG features a DNS based key validation system named PKA. It worked by adding special TEXT records into the DNS and directing gpg via --auto-key-locate to make use of them. There are however a couple of problems with that (e.g. the use of TEXT records) so that it requires a redefintion. What I implemented in master is: - The local-part of the mailbox is now hashed and z-base-32 encoded. This allows the use of characters which are not allowed as a DNS name The open question is what to do about case insensitivity: The local-part is case sensitive but in practice nobody makes use of it. It would also be quite surprising if you the addresses "joe.doe at example.org" and "Joe.Doe at example.org" would be different entities. What I have in mind is to downcase all plain ascii characters before hashing but keeping the other utf-8 characters as they are. This would help with existing addresses but don't conflict with too complicated utf-8 rules for downcasing (if they at all exists). - The code for the old PKA has been removed. - The new command --print-pka-records prints records for insertion into zone files. Before each line an $ORIGIN line is given so that a simple script can be used to divert the output to thre respective zone files. More work is required to use PKA only for initial key retrieval but not anymore for validating keys - the DNS is just too insecure for it and we should not rely on DNSSEC for validation either. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From buanzo at buanzo.com.ar Wed Feb 25 20:49:16 2015 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Wed, 25 Feb 2015 16:49:16 -0300 Subject: PKA updates In-Reply-To: <874mqaugf9.fsf@vigenere.g10code.de> References: <874mqaugf9.fsf@vigenere.g10code.de> Message-ID: Hello Werner, Thank you for this. Could you elaborate on your DNSSEC comments? Sincerely, Buanzo. On Wed, Feb 25, 2015 at 1:03 PM, Werner Koch wrote: > Hi! > > For about a decade GnuPG features a DNS based key validation system > named PKA. It worked by adding special TEXT records into the DNS and > directing gpg via --auto-key-locate to make use of them. There are > however a couple of problems with that (e.g. the use of TEXT records) so > that it requires a redefintion. > > What I implemented in master is: > > - The local-part of the mailbox is now hashed and z-base-32 encoded. > This allows the use of characters which are not allowed as a DNS name > > The open question is what to do about case insensitivity: The > local-part is case sensitive but in practice nobody makes use of it. > It would also be quite surprising if you the addresses > "joe.doe at example.org" and "Joe.Doe at example.org" would be different > entities. What I have in mind is to downcase all plain ascii > characters before hashing but keeping the other utf-8 characters as > they are. This would help with existing addresses but don't conflict > with too complicated utf-8 rules for downcasing (if they at all > exists). > > - The code for the old PKA has been removed. > > - The new command --print-pka-records prints records for insertion into > zone files. Before each line an $ORIGIN line is given so that a > simple script can be used to divert the output to thre respective > zone files. > > More work is required to use PKA only for initial key retrieval but not > anymore for validating keys - the DNS is just too insecure for it and we > should not rely on DNSSEC for validation either. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionic at ionic.de Wed Feb 25 20:03:39 2015 From: ionic at ionic.de (Mihai Moldovan) Date: Wed, 25 Feb 2015 20:03:39 +0100 Subject: [PATCH] gpg: don't show debug messages when not requested. Message-ID: <54EE1C8B.1060306@ionic.de> * g10/armor.c: add debug level guard for log_debug call. -- Fixes a regression introduced in 2.0.27. The debug message was always shown, although no debugging requested. Signed-off-by: Mihai Moldovan --- g10/armor.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-don-t-show-debug-messages-when-not-requested.patch Type: text/x-patch Size: 811 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Feb 25 21:34:49 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 25 Feb 2015 15:34:49 -0500 Subject: PKA updates In-Reply-To: <874mqaugf9.fsf@vigenere.g10code.de> References: <874mqaugf9.fsf@vigenere.g10code.de> Message-ID: <87385tspau.fsf@alice.fifthhorseman.net> On Wed 2015-02-25 11:03:38 -0500, Werner Koch wrote: > For about a decade GnuPG features a DNS based key validation system > named PKA. It worked by adding special TEXT records into the DNS and > directing gpg via --auto-key-locate to make use of them. There are > however a couple of problems with that (e.g. the use of TEXT records) so > that it requires a redefintion. > > What I implemented in master is: > > - The local-part of the mailbox is now hashed and z-base-32 encoded. > This allows the use of characters which are not allowed as a DNS name > > The open question is what to do about case insensitivity: The > local-part is case sensitive but in practice nobody makes use of it. > It would also be quite surprising if you the addresses > "joe.doe at example.org" and "Joe.Doe at example.org" would be different > entities. What I have in mind is to downcase all plain ascii > characters before hashing but keeping the other utf-8 characters as > they are. This would help with existing addresses but don't conflict > with too complicated utf-8 rules for downcasing (if they at all > exists). > > - The code for the old PKA has been removed. > > - The new command --print-pka-records prints records for insertion into > zone files. Before each line an $ORIGIN line is given so that a > simple script can be used to divert the output to thre respective > zone files. how does this relate to https://tools.ietf.org/html/draft-ietf-dane-openpgpkey ? Should we try to support this draft? > More work is required to use PKA only for initial key retrieval but not > anymore for validating keys - the DNS is just too insecure for it and we > should not rely on DNSSEC for validation either. I see DNSSEC as a corroborative channel -- it doesn't need to be authoritative for people who don't want it to be, but it could be useful as well, and it is cryptographically verifiable (caveat: the keys are often much weaker than we'd like today). There are other kinds of security at issue, though: DNS provides a pretty nasty leakage channel, since confidential DNS query mechanisms are not widely deployed. I'd hope that DNS lookups aren't necessarily enabled by default unless we can guarantee that channel is private. --dkg From hanno at hboeck.de Wed Feb 25 23:55:35 2015 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Wed, 25 Feb 2015 23:55:35 +0100 Subject: PKA updates In-Reply-To: <874mqaugf9.fsf@vigenere.g10code.de> References: <874mqaugf9.fsf@vigenere.g10code.de> Message-ID: <20150225235535.2ee2366d@pc> Hi Werner, On Wed, 25 Feb 2015 17:03:38 +0100 Werner Koch wrote: > For about a decade GnuPG features a DNS based key validation system > named PKA. It worked by adding special TEXT records into the DNS and > directing gpg via --auto-key-locate to make use of them. There are > however a couple of problems with that (e.g. the use of TEXT records) > so that it requires a redefintion. I thought about this. A DNS record that points to a key that has to be grabbed elsewhere. I wonder: Why this DNS middleman? It's kinda the worst one, because it's insecure by design. (if anyone cries "DNSSEC" - I'll get to that) Why not use https directly? It already has some security. We all know it's weak and depends on the questionable CA system, but it's still certainly better than nothing (and with key pinning and certificate transparency it's improving). Something like a defined URL. E.g. for mail address foo at bar.com it could be https://pgpkey.bar.com/foo_at_bar.com.asc (Just an example, can be anything, you get the idea, just has to be a defined algorithm of getting the url out of the key) Or integrate it somehow in one of the many ways mail clients autodiscover their configuration options (yeah, standards, great!). In 2006 you wrote that DNS will get more secure by the deployment of DNSSEC. We know this didn't happen. I'm very sceptical it will ever happen. Some IT sec people at Google and Yahooo have recently publicly commented they don't like DNSSEC. It has various problems, the biggest one being that it has been vapoware forever and nobody uses it. By using https one could use the security of an existing system that we may not like, but it's already there and works. cu, -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Feb 26 09:24:55 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Feb 2015 09:24:55 +0100 Subject: PKA updates In-Reply-To: <20150225235535.2ee2366d@pc> ("Hanno =?utf-8?Q?B=C3=B6ck=22's?= message of "Wed, 25 Feb 2015 23:55:35 +0100") References: <874mqaugf9.fsf@vigenere.g10code.de> <20150225235535.2ee2366d@pc> Message-ID: <87pp8xt6zs.fsf@vigenere.g10code.de> On Wed, 25 Feb 2015 23:55, hanno at hboeck.de said: > I thought about this. A DNS record that points to a key that has to be > grabbed elsewhere. Right, it would also be possible to put the key into the DNS proper (certtype PGP) but that won't fit into an UDP packet and thus it will be a bit slower. Further, for any key updates you need to update that copy of the key and thus you depend on the admin of the zone. The --auto-key-locate method "cert" allows this anyway (need to store the key under its fingerprint, but that is desirable anyway) and can be used in addition to IPGP. > I wonder: Why this DNS middleman? It's kinda the worst one, because > it's insecure by design. (if anyone cries "DNSSEC" - I'll get to that) For a very simple reason. If you want to send a mail to foo at example.org you or your smarthost need to lookup the MX for example.org anyway. Thus a DNS retrieval is required in any case and an addition IPGP fetch won't harm. Sure, this reveals the local-part of the address (the hash is no protection against this) but the proposal is not about hiding meta data but about an easy way to find a key for an arbitray mail address. By the time we have an ubiquitous anonymous naming system, the very same method can be used with such a system and would solve the meta data leakage instantly. And given that such a system will anyway be a part of a fully anonymized net the entire met data problem will be solved. Instead of sending a DNS request from the local client, it might also be possible to extend IMAP to have the provider lookup the fingerint and key for you. This somewhat mitigates the leakage of the local-part. > Why not use https directly? It already has some security. We all know Too expensive, to hard to maintain, and experience has shown that it does not solve a problem: We have all these feature availabale for years but they are rarely used. Thus I think it is better to split the problem: 1. Find the right key matching a certain mail address. 2. Make sure that you have the latest update of that key (for revocations) and detect a key change. PKA is about the first while other methods (e.g. TOFU) is about the second. If you already have a key matching a mail address this is not required. Some fine tuning will be required to see what to do if you already have two matching keys for the same address in you local keyring. > In 2006 you wrote that DNS will get more secure by the deployment of > DNSSEC. We know this didn't happen. I'm very sceptical it will ever > happen. Some IT sec people at Google and Yahooo have recently publicly > commented they don't like DNSSEC. It has various problems, the biggest > one being that it has been vapoware forever and nobody uses it. By I don't buy that vaporware argument; that is too similar to the "IPv6 won't ever be used". But: DNSSEC has no distributed security and we have meanwhile learned that there are powerful organisations which will likely subvert the security of DNSSEC as soon has it gets into real use. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Feb 26 09:34:23 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Feb 2015 09:34:23 +0100 Subject: PKA updates In-Reply-To: <87385tspau.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 25 Feb 2015 15:34:49 -0500") References: <874mqaugf9.fsf@vigenere.g10code.de> <87385tspau.fsf@alice.fifthhorseman.net> Message-ID: <87lhjlt6k0.fsf@vigenere.g10code.de> On Wed, 25 Feb 2015 21:34, dkg at fifthhorseman.net said: > https://tools.ietf.org/html/draft-ietf-dane-openpgpkey ? Should we try > to support this draft? I looked at this again. - It requires a new record type - It merges the first time key retrieval with the validation of the key. [ - Why using SHA224 for hashing if this is just for maiing the local-part. ] > I see DNSSEC as a corroborative channel -- it doesn't need to be > authoritative for people who don't want it to be, but it could be useful That was my original idea behind PKA. I don't think that is anymore justified. However, if you trust DNSSEC gpg can already be tweaked to that that in account by using "--verify-options pka-trust-increase" etc. > There are other kinds of security at issue, though: DNS provides a > pretty nasty leakage channel, since confidential DNS query mechanisms > are not widely deployed. I'd hope that DNS lookups aren't necessarily I think this decision should be left to the MUAs. If it is enabled by default, that would be better than sending mails in the clear. Thus for a first time non-expert installation enabling such a feature by default would be the Right Thing. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Feb 26 09:35:58 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Feb 2015 09:35:58 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: (Roman Zechmeister's message of "Wed, 25 Feb 2015 18:28:25 +0100") References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> <54E9F20F.9040506@enigmail.net> <87ioery4oe.fsf@vigenere.g10code.de> <54EDDBF9.3030108@guardianproject.info> <87bnkiuh37.fsf@vigenere.g10code.de> Message-ID: <87h9u9t6hd.fsf@vigenere.g10code.de> On Wed, 25 Feb 2015 18:28, Roman at mento.at said: > Passing a string with placeholder for KeyID etc. to gpg. It checks the > string against missing placeholders and fake KeyID etc., and then > gives that message to gpg-agent. That makes a good topic for the summit in April. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Feb 26 15:19:27 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Feb 2015 15:19:27 +0100 Subject: [PATCH] Fix import option name: s/import-keep-ownertrust/keep-ownertrust/. In-Reply-To: <1424822836-19168-1-git-send-email-guilhem@fripost.org> (Guilhem Moulin's message of "Wed, 25 Feb 2015 01:07:16 +0100") References: <1424822836-19168-1-git-send-email-guilhem@fripost.org> Message-ID: <8761aosqkw.fsf@vigenere.g10code.de> On Wed, 25 Feb 2015 01:07, guilhem at fripost.org said: > ?keep-ownertrust? is the name found in import.c. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ionic at ionic.de Thu Feb 26 17:53:18 2015 From: ionic at ionic.de (Mihai Moldovan) Date: Thu, 26 Feb 2015 17:53:18 +0100 Subject: [PATCH v2] gpg: remove left-over debug message. In-Reply-To: <87d24xt6f3.fsf@vigenere.g10code.de> References: <54EE1C8B.1060306@ionic.de> <87d24xt6f3.fsf@vigenere.g10code.de> Message-ID: <54EF4F7E.2000200@ionic.de> * g10/armor.c: remove armor-keys-failed debug message. -- Fixes a regression introduced in 2.0.27. The debug message was always shown, although there's no need for it at all. Signed-off-by: Mihai Moldovan --- g10/armor.c | 3 --- 1 file changed, 3 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-remove-left-over-debug-message.patch Type: text/x-patch Size: 627 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Feb 27 21:20:54 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 21:20:54 +0100 Subject: [Announce] GnuPG 1.4.19 released (with SCA fix) Message-ID: <87d24vm7h5.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG classic release: Version 1.4.19. This release mitigates two new side channel attacks. Updating any GnuPG 1.4 version to 1.4.19 is suggested! To update a GnuPG 2.0 or 2.1 version you need to update the shared library Libgcrypt to version 1.6.3. What is GnuPG ============= The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. This announcement is about a release of this version. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in GnuPG 1.4.19 ========================== * Use ciphertext blinding for Elgamal decryption [CVE-2014-3591]. See http://www.cs.tau.ac.il/~tromer/radioexp/ for details. * Fixed data-dependent timing variations in modular exponentiation [related to CVE-2015-0837, Last-Level Cache Side-Channel Attacks are Practical]. * Detect faulty use of --verify on detached signatures. * Changed the PKA method to use CERT records and hashed names. * New import option "keep-ownertrust". * Support algorithm names when generating keys using the --command-fd method. * Updated many translations. * Updated build system. * Fixed a regression in keyserver import * Fixed argument parsing for option --debug-level. * Fixed DoS based on bogus and overlong key packets. * Fixed bugs related to bogus keyrings. * The usual minor minor bug fixes. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 1.4.19 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at https://gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.bz2 (3627k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.bz2.sig This is the GnuPG 1.4.19 source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.gz (5020k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.gz.sig This is the same GnuPG 1.4.19 source code compressed using GZIP and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.19.exe (1586k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.19.exe.sig This is GnuPG 1.4.19 compiled for Microsoft Windows and its OpenPGP signature. This is a command line only version; the source files are the same as above. Note, that this is a minimal installer and unless you are only in need for the simple the gpg binary, you are better off using the full featured installer at https://www.gpg4win.org . Checking the Integrity ====================== 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 version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-1.4.19.tar.bz2 you would use this command: gpg --verify gnupg-1.4.19.tar.bz2.sig gnupg-1.4.19.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-1.4.19.tar.bz2, you would run the command like this: sha1sum gnupg-1.4.19.tar.bz2 and check that the output matches the first line from the following list: 5503f7faa0a0e84450838706a67621546241ca50 gnupg-1.4.19.tar.bz2 d0cf40cc42ce057d7d747908ec21a973a423a508 gnupg-1.4.19.tar.gz dc03ae4e4c3e8fe0583b37dd6c3124f94246d2f8 gnupg-w32cli-1.4.19.exe Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html . Note that this mail has been signed using my standard PGP key. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Since the start of the funding campaign in December several thousand people have been kind enough to donate a total of 250000 Euro to support this project. In addition the Linux Foundation gave a grant of $ 60000 for 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. I am amazed by this superb and unexpected support for the GnuPG project. This does not only allow us to continue the project and allowed to hire second full time developer, but also gives the resources to improve things which have been delayed for too long. *Thank you all !* Salam-Shalom, Werner p.s. This is a announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 wk at gnupg.org Fri Feb 27 21:39:05 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 21:39:05 +0100 Subject: [Announce] Libgcrypt 1.6.3 released (with SCA fix) Message-ID: <874mq7m6mu.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.6.3. This is a security fix release to mitigate two new side channel attacks. Libgcrypt is a general purpose library of cryptographic building blocks. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required for proper use Libgcrypt. Noteworthy changes in version 1.6.3 =================================== * Use ciphertext blinding for Elgamal decryption [CVE-2014-3591]. See http://www.cs.tau.ac.il/~tromer/radioexp/ for details. * Fixed data-dependent timing variations in modular exponentiation [related to CVE-2015-0837, Last-Level Cache Side-Channel Attacks are Practical]. * Improved asm support for older toolchains. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.bz2 (2436k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.gz (2893k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.gz.sig In order to check that the version of Libgcrypt you are going to build is an original and unmodified one, you can do it in one of the following ways: * Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.6.3.tar.bz2 you would use this command: gpg --verify libgcrypt-1.6.3.tar.bz2.sig libgcrypt-1.6.3.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one of the release signing keys. See https://gnupg.org/signature_key.html . * If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.6.3.tar.bz2 and check that the output matches the first line from the following list: 9456e7b64db9df8360a1407a38c8c958da80bbf1 libgcrypt-1.6.3.tar.bz2 4d56b5d754d39acae239f876537672e1dc8298e3 libgcrypt-1.6.3.tar.gz Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Niibe Yutaka did most of the work on fixing the side channel attacks. Special thanks to a) Daniel Genkin and his team for working with us on the fix for the "radioexp" attack, b) Yuval Yarum and its team for advance information on their new cache attack and sample code on how to fix it. Since the start of the GnuPG funding campaign in December several thousand people have been kind enough to donate a total of 250000 Euro to support this project. In addition the Linux Foundation gave a grant of $ 60000 for 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. I am amazed by this superb and unexpected support for the GnuPG project. This will not only allow us to continue the project and hire a second full time developer but gives us also the resources to improve things which have been delayed for too long. *Thank you all !* Happy hacking, Werner [1] http://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] https://www.gnupg.org/service.html p.s. This is a announcement only mailing list. Please send replies only to the gcrypt-devel at gnupg.org mailing lists. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 dkg at fifthhorseman.net Sat Feb 28 05:08:03 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 Feb 2015 23:08:03 -0500 Subject: PKA updates In-Reply-To: <87lhjlt6k0.fsf@vigenere.g10code.de> References: <874mqaugf9.fsf@vigenere.g10code.de> <87385tspau.fsf@alice.fifthhorseman.net> <87lhjlt6k0.fsf@vigenere.g10code.de> Message-ID: <87sidqr84c.fsf@alice.fifthhorseman.net> On Thu 2015-02-26 03:34:23 -0500, Werner Koch wrote: > On Wed, 25 Feb 2015 21:34, dkg at fifthhorseman.net said: > >> https://tools.ietf.org/html/draft-ietf-dane-openpgpkey ? Should we try >> to support this draft? > > I looked at this again. > > - It requires a new record type I'm not sure that a new record type is much of a problem. Most DNS servers support generic types these days, and the hash-slinger code can produce hex-encoded records that should be acceptable. http://people.redhat.com/pwouters/hash-slinger/ > - It merges the first time key retrieval with the validation of the > key. The draft allows for validation of the key via DNS fetch, but it doesn't require that the MUA treat the dnssec validation as authoritative. > [ - Why using SHA224 for hashing if this is just for maiing the > local-part. ] i'm not sure what the issue is here. can you explain further? My understanding is that the digest is to avoid DNS labels that are either too long, or contain unwieldy characters, not as an attempt to mask the identity being looked up. > That was my original idea behind PKA. I don't think that is anymore > justified. However, if you trust DNSSEC gpg can already be tweaked to > that that in account by using "--verify-options pka-trust-increase" etc. Can you explain more why you no longer think that using dnssec as a corroborative channel is justified? I'm personally wary of the hierarchical model for DNSSEC, but i don't think that invalidates it for corroboration. >> There are other kinds of security at issue, though: DNS provides a >> pretty nasty leakage channel, since confidential DNS query mechanisms >> are not widely deployed. I'd hope that DNS lookups aren't necessarily > > I think this decision should be left to the MUAs. If it is enabled by > default, that would be better than sending mails in the clear. Thus for > a first time non-expert installation enabling such a feature by default > would be the Right Thing. Well, sending mail in the clear over a STARTTLS submission channel only leaks the To: information to the user's sending MTA, while the DNS query leaks the same information to every machine along the network path to the DNS server. But i think you're right that this is something that can be mitigated with sensible MUA operation, caching results, etc. --dkg