From wk at gnupg.org Tue Dec 1 12:54:51 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Dec 2015 12:54:51 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: <8737vrtflp.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 27 Nov 2015 14:19:30 -0500") References: <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> <87h9u9t6hd.fsf@vigenere.g10code.de> <09F12993-5464-4156-8C7D-0D40435A3935@gpgtools.org> <87pozaw9g8.wl-neal@walfield.org> <87mvuew455.wl-neal@walfield.org> <514E159D-C26D-47BF-AB2F-E36ACA75DBC1@gpgtools.org> <87k2p3s572.fsf@vigenere.g10code.de> <8737vrtflp.fsf@alice.fifthhorseman.net> Message-ID: <87poyqpeno.fsf@vigenere.g10code.de> On Fri, 27 Nov 2015 20:19, dkg at fifthhorseman.net said: > And pinentry does use gettext in pinentry/argparse.c and secmem/util.c > (both copied from other projects, so maybe we can ignore that?). Actually it does not. In argparse we have this code #ifndef GNUPG_MAJOR_VERSION # ifndef _ # define _(a) (a) # endif [...] so we define the usual _() macro to a nop unless the file is used in GnuPG. The use of _() in secmem/util.c is inactive code. > rather, requires that non-GnuPG projects provide well-localized strings > directly to pinentry instead of depending on its defaults). > > It would be good to add this caveat to doc/HACKING so people better > understand the constraints for pinentry. I will do so. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Wed Dec 2 12:04:37 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 02 Dec 2015 12:04:37 +0100 Subject: Possible regression in 2.1.10-beta for --local-user In-Reply-To: <8737vnwbsg.wl-neal@walfield.org> References: <565C7CCA.3030100@sumptuouscapital.com> <8737vnwbsg.wl-neal@walfield.org> Message-ID: <87y4ddun5m.wl-neal@walfield.org> At Mon, 30 Nov 2015 20:02:39 +0100, Neal H. Walfield wrote: > > Hi Kristian, > > At Mon, 30 Nov 2015 17:43:54 +0100, > Kristian Fiskerstrand wrote: > > I haven't had time to bisect which commit introduce this behavior, but > > somewhere after 2.1.9 there seems to be a regression to specifying a > > specific signing subkey for --local-user using the ! operator. briefly > > looking through log I suspect it might be related to [0] > > I've found the bug and I'll try to come up with a fix tomorrow. > > Thanks for the helpful bug report! I've (hopefully) fixed this in 10cca02. Thanks! Neal From wk at gnupg.org Wed Dec 2 15:09:12 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Dec 2015 15:09:12 +0100 Subject: Jabber MUC for GnuPG developer Message-ID: <87si3llz7b.fsf@vigenere.g10code.de> Hi! it is probably not very well known that some of the GnuPG developer use a Jabber multi-user-chat for quick communication. For a long time this required a jabber.gnupg.odoc account because I was too lazy to figure out how to get that MUC working from other servers. That has been fixed some months ago and thus anyone should be able to join and lurk: gnupg-devel at conference.jabber.gnupg.org Please do not use this channel for general questions about GnuPG; instead use IRC (#gnupg at freenode). Kudos to Jens Link for running this server. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mail at joed.hu Wed Dec 2 16:17:29 2015 From: mail at joed.hu (=?iso-8859-2?Q?Dubravszky_J=F3zsef?=) Date: Wed, 2 Dec 2015 16:17:29 +0100 Subject: gpg-agent protocol Message-ID: <03aa01d12d14$932004c0$b9600e40$@joed.hu> Hello, Before I do any coding or trials I would like to clear some GPG4Win questions. Atsuhiko Yamanaka made an excellent Eclipse SSH agent plugin (https://github.com/ymnk/jsch-agent-proxy) to proxy SSH agents to Eclipse subsystems. Currently it supports ssh-agent on Linux and Pageant on Windows. As of GPG4Win 2.2 the gpg-agent.exe can function as an SSH agent for Putty. It would be just awesome to be able to use gpg-agent.exe in Eclipse. For that, a connector needs to be developed but first I would like to get information on how could I "talk to" the gpg-agent.exe? The Pageant connector uses Win32 shared memory operations. My question might sound silly, but is there anything that would prevent me writing a connector that uses the same Win32 shared memory operations based protocol? I also recognized that on Windows an S.gpg-agent.ssh file is created in the users roaming AppData (C:\Users\USERNAME\AppData\Roaming\gnupg\S.gpg-agent.ssh), that pretty much resembles a Unix socket. As far as I know there is no such compatible domain socket on Windows, but what is this file then? Thank you for your help. BR, joe From gniibe at fsij.org Thu Dec 3 01:01:55 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 03 Dec 2015 09:01:55 +0900 Subject: Curve25519 with the prefix 0x40 In-Reply-To: <5656765A.7020800@fsij.org> References: <5656765A.7020800@fsij.org> Message-ID: <565F8673.9010907@fsij.org> On 11/26/2015 12:02 PM, NIIBE Yutaka wrote: > I review our implementation of Curve25519 again, and I think that we > should add the prefix 0x40 so that it matches the practice of Ed25519. > > While my patch for libgcrypt is on review, and here is the patch for > GnuPG. Well, it seems that only change for scdaemon. I pushed it to master, since the impact is only scdaemon, and it means that it will be Gnuk Token users. I think that having the prefix 0x40 for point representation of Curve25519 makes sense and it's better than no prefix, because when we have the prefix, it is safe to handle the octets as plain MPI. If no prefix, some code in GnuPG for MPI puts 0x00 at the beginning, it changes the value for the point for Curve25519. -- From gniibe at fsij.org Thu Dec 3 01:46:35 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 03 Dec 2015 09:46:35 +0900 Subject: gpg-agent protocol In-Reply-To: <03aa01d12d14$932004c0$b9600e40$@joed.hu> References: <03aa01d12d14$932004c0$b9600e40$@joed.hu> Message-ID: <565F90EB.3080702@fsij.org> On 12/03/2015 12:17 AM, Dubravszky J?zsef wrote: > Atsuhiko Yamanaka made an excellent Eclipse SSH agent plugin > (https://github.com/ymnk/jsch-agent-proxy) to proxy SSH agents to Eclipse > subsystems. Currently it supports ssh-agent on Linux and Pageant on Windows. It's good to hear his name again. Great. I guess it also just works with gpg-agent, possibly. (Newer) gpg-agent supports the communication method of Pageant<->Putty. > My question might sound silly, but is there anything that would > prevent me writing a connector that uses the same Win32 shared > memory operations based protocol? IIUC, the connector for Pageant works with gpg-agent, because it's the same protocol. Please try. > I also recognized that on Windows an S.gpg-agent.ssh file is created in the > users roaming AppData > (C:\Users\USERNAME\AppData\Roaming\gnupg\S.gpg-agent.ssh), that pretty much > resembles a Unix socket. As far as I know there is no such compatible domain > socket on Windows, but what is this file then? Please note that my knowledge is limited since I'm not a Windows user. GnuPG implements Unix domain socket emulation and use it for gpg<->gpg-agent communication. The S.gpg-agent.ssh is the one for SSH, while there are no client program on Windows (Putty uses another channel: Win32 shared memory operations). -- From patrick at enigmail.net Thu Dec 3 22:08:22 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 3 Dec 2015 22:08:22 +0100 Subject: Gpg 2.1 with dirmngr at changing locations Message-ID: <5660AF46.9080804@enigmail.net> I'm using a notebook, that I carry around quite a lot. The notebook is hardly turned off; it usually just sleeps. Whenever I wake up my notebook at a different location than before (which usually implies changed routes and changed name servers), dirmngr fails to do any keyserver operation with a "no route to host" error. I have to kill it in order to get it working afterwards. I know, I'm using a Mac -- which is why having my notebook sleep works almost 100% reliably -- so this may be something OS-specific. Can anybody confirm this? -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Fri Dec 4 06:21:40 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 04 Dec 2015 14:21:40 +0900 Subject: Curve25519 with the prefix 0x40 In-Reply-To: <565F8673.9010907@fsij.org> References: <5656765A.7020800@fsij.org> <565F8673.9010907@fsij.org> Message-ID: <566122E4.3090806@fsij.org> On 12/03/2015 09:01 AM, NIIBE Yutaka wrote: > I pushed it to master, since the impact is only scdaemon, and > it means that it will be Gnuk Token users. Sorry, the patch was immature. Thanks Werner for fixing my mistakes. More fix is needed, in fact. My badness. Tested with my Gnuk Token this time. Pushing. scd: More fix for Curve25519 prefix handling. * scd/app-openpgp.c (do_decipher): Handle trancated cipher text. Also fix xfree bug introduced. -- In old format with no prefix, cipher text can be trancated when it is parsed as MPI. Recover the value adding back zeros. Fixes-commit: 11b2691eddc42e91651e4f95dd2731255a3e9211 diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index f8e1460..d204740 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -4175,14 +4175,25 @@ do_decipher (app_t app, const char *keyidstr, } else if (app->app_local->keyattr[1].key_type == KEY_TYPE_ECC) { - if (app->app_local->keyattr[1].ecc.flags - && (indatalen%2)) - { /* - * Skip the prefix. It may be 0x40 (in new format), or MPI - * head of 0x00 (in old format). - */ - indata = (const char *)indata + 1; - indatalen--; + int old_format_len = 0; + + if (app->app_local->keyattr[1].ecc.flags) + { + if (indatalen > 32 + 1) + { /* + * Skip the prefix. It may be 0x40 (in new format), or MPI + * head of 0x00 (in old format). + */ + indata = (const char *)indata + 1; + indatalen--; + } + else if (indatalen < 32) + { /* + * Old format trancated by MPI handling. + */ + old_format_len = indatalen; + indatalen = 32; + } } fixuplen = 7; @@ -4198,7 +4209,16 @@ do_decipher (app_t app, const char *keyidstr, fixbuf[4] = (char)(indatalen+2); fixbuf[5] = '\x86'; fixbuf[6] = (char)indatalen; - memcpy (fixbuf+fixuplen, indata, indatalen); + if (old_format_len) + { + memset (fixbuf+fixuplen, 0, 32 - old_format_len); + memcpy (fixbuf+fixuplen + 32 - old_format_len, + indata, old_format_len); + } + else + { + memcpy (fixbuf+fixuplen, indata, indatalen); + } indata = fixbuf; indatalen = fixuplen + indatalen; @@ -4230,12 +4250,12 @@ do_decipher (app_t app, const char *keyidstr, fixbuf = xtrymalloc (*outdatalen + 1); if (!fixbuf) { - xfree (outdata); + xfree (*outdata); return gpg_error_from_syserror (); } fixbuf[0] = 0x40; memcpy (fixbuf+1, *outdata, *outdatalen); - xfree (outdata); + xfree (*outdata); *outdata = fixbuf; *outdatalen = *outdatalen + 1; } -- From ueno at gnu.org Fri Dec 4 09:55:09 2015 From: ueno at gnu.org (Daiki Ueno) Date: Fri, 4 Dec 2015 17:55:09 +0900 Subject: [PATCH] doc: Fix minor errors Message-ID: * doc/gpgme.texi: Fix errors and typos in the cancellation and gpgme_import_result_t documentation. Signed-off-by: Daiki Ueno --- doc/gpgme.texi | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/doc/gpgme.texi b/doc/gpgme.texi index 1c680b5..db94617 100644 --- a/doc/gpgme.texi +++ b/doc/gpgme.texi @@ -3810,7 +3810,7 @@ for the context @var{ctx}, or, if that is not set, by the encoding specified for @var{keydata}. The keys to export are taken form the @code{NULL} terminated array - at var{keys}. Only keys of the the currently selected protocol of + at var{keys}. Only keys of the currently selected protocol of @var{ctx} which do have a fingerprint set are considered for export. Other keys specified by the @var{keys} are ignored. In particular OpenPGP keys retrieved via an external key listing are not included. @@ -3883,7 +3883,7 @@ permanent which have been retrieved from an external source (i.e. using for the usual workaround of exporting and then importing a key to make an X.509 key permanent.} -Only keys of the the currently selected protocol of @var{ctx} are +Only keys of the currently selected protocol of @var{ctx} are considered for import. Other keys specified by the @var{keys} are ignored. As of now all considered keys must have been retrieved using the same method, that is the used key listing mode must be identical. @@ -3970,34 +3970,34 @@ The number of keys without user ID. @item int imported The total number of imported keys. - at item imported_rsa + at item int imported_rsa The number of imported RSA keys. - at item unchanged + at item int unchanged The number of unchanged keys. - at item new_user_ids + at item int new_user_ids The number of new user IDs. - at item new_sub_keys + at item int new_sub_keys The number of new sub keys. - at item new_signatures + at item int new_signatures The number of new signatures. - at item new_revocations + at item int new_revocations The number of new revocations. - at item secret_read + at item int secret_read The total number of secret keys read. - at item secret_imported + at item int secret_imported The number of imported secret keys. - at item secret_unchanged + at item int secret_unchanged The number of unchanged secret keys. - at item not_imported + at item int not_imported The number of keys not imported. @item gpgme_import_status_t imports @@ -6147,16 +6147,16 @@ operation in the context @var{ctx}. This only works if you use the global event loop or your own event loop. If you use the global event loop, you must not call @code{gpgme_wait} -or @code{gpgme_wait} during cancellation. After successful +during cancellation. After successful cancellation, you can call @code{gpgme_wait} (optionally waiting on @var{ctx}), and the context @var{ctx} will appear as if it had finished with the error code @code{GPG_ERR_CANCEL}. -If you use your an external event loop, you must ensure that no I/O +If you use an external event loop, you must ensure that no I/O callbacks are invoked for this context (for example by halting the event loop). On successful cancellation, all registered I/O callbacks for this context will be unregistered, and a @code{GPGME_EVENT_DONE} -event with the error code @code{GPG_ERR_CANCEL} will be signaled. +event with the error code @code{GPG_ERR_CANCEL} will be signalled. The function returns an error code if the cancellation failed (in this case the state of @var{ctx} is not modified). -- 2.5.0 From ueno at gnu.org Fri Dec 4 10:45:06 2015 From: ueno at gnu.org (Daiki Ueno) Date: Fri, 04 Dec 2015 18:45:06 +0900 Subject: status code for gpgme_op_delete In-Reply-To: <87fv0qs1e8.fsf-ueno@gnu.org> (Daiki Ueno's message of "Sun, 01 Nov 2015 15:02:23 +0900") References: <87fv0qs1e8.fsf-ueno@gnu.org> Message-ID: Daiki Ueno writes: > When trying to delete a key from GPGME, I am asked through Pinentry: > > Do you really want to permanently delete the OpenPGP secret key ...? > > If I answer "No" to this, gpgme_op_delete does not return any error, > since there is no status output for this case. Maybe DELETE_PROBLEM > could be extended or a new status code could be added? For what it's worth, I'm attaching a patch for GnuPG and its counterpart for GPGME. With the patch, gpg emits an ERROR status line with "delete_key.secret" error source (the name is taken from the cpr prompt on the above line in the code). I'm currently working on Seahorse visual refresh[1] in GNOME, and to provide a responsive UI, I want this and the --gen-key cancellation issue to be fixed. Footnotes: [1] https://github.com/ueno/gnome-credentials Thanks, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Write-ERROR-status-on-delete-key-cancellation.patch Type: text/x-patch Size: 1008 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Return-on-user-cancellation-of-delete-operation.patch Type: text/x-patch Size: 1637 bytes Desc: not available URL: From jeroen.ooms at stat.ucla.edu Fri Dec 4 13:23:06 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Fri, 4 Dec 2015 13:23:06 +0100 Subject: gpg-verify c api Message-ID: I've been working on a package with gpgme bindings for the R programming language to make gpg encryption and signature functionality available to R users. The ultimate goal is to implement native support in the R for verifying gpg signatures in the package manager. However because R itself has to work out of the box on Linux, Mac and Windows, it cannot have a runtime dependency on gpg executables. Hence I was wondering if there pure C API for verifying gpg signatures, which depends only on libgcrypt (or other c libraries) but does not require a full gpg installation. That way we can statically link libgcrypt into the R binary on mac and windows, and have a portable solution. The client would not need any of gpg's advanced features, it only needs to verify if a given signature is valid for a given message and pubkey, similar to the openssl EVP_Verify api [1]. Perhaps I underestimate the complexity of the gpg system, but I think a simple portable gpg-verify C library would be very useful for many other software as well. BSD has something called netpgpverify, but unfortunately it does not work on other platforms. I was unable to figure out how to implement signature verification with libgcrypt alone. Has somebody worked on something similar? [1] https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying From neal at walfield.org Fri Dec 4 13:41:46 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 04 Dec 2015 13:41:46 +0100 Subject: gpg-verify c api In-Reply-To: References: Message-ID: <87egf2jshh.wl-neal@walfield.org> At Fri, 4 Dec 2015 13:23:06 +0100, Jeroen Ooms wrote: > I've been working on a package with gpgme bindings for the R > programming language to make gpg encryption and signature > functionality available to R users. The ultimate goal is to implement > native support in the R for verifying gpg signatures in the package > manager. Meik Michalke was working on creating an R package for working with GnuPG a while ago. I don't know what the status is. (I've add him to the cc.) > However because R itself has to work out of the box on Linux, Mac and > Windows, it cannot have a runtime dependency on gpg executables. Hence > I was wondering if there pure C API for verifying gpg signatures, > which depends only on libgcrypt (or other c libraries) but does not > require a full gpg installation. That way we can statically link > libgcrypt into the R binary on mac and windows, and have a portable > solution. There is no such library as far as I know. The closest that I'm aware of is gpgv, which just verifies signatures (it part of the GnuPG). > The client would not need any of gpg's advanced features, it only > needs to verify if a given signature is valid for a given message and > pubkey, similar to the openssl EVP_Verify api [1]. A signature is not much more use than a checksum if you don't also check the key's validity. How were you planning on doing this? Were you just going to hard code a few keys? > I was unable to figure out how to implement signature verification > with libgcrypt alone. Has somebody worked on something similar? At the very least, you need to parse the OpenPGP message, which is what gpg does. Neal From jeroen.ooms at stat.ucla.edu Fri Dec 4 14:06:33 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Fri, 4 Dec 2015 14:06:33 +0100 Subject: gpg-verify c api In-Reply-To: <87egf2jshh.wl-neal@walfield.org> References: <87egf2jshh.wl-neal@walfield.org> Message-ID: On Fri, Dec 4, 2015 at 1:41 PM, Neal H. Walfield wrote: > There is no such library as far as I know. The closest that I'm aware > of is gpgv, which just verifies signatures (it part of the GnuPG). But gpgv only has a command line interface, correct? Or does it also provide a C API? > A signature is not much more use than a checksum if you don't also > check the key's validity. How were you planning on doing this? Were > you just going to hard code a few keys? Yes, I was thinking of shipping trusted keys with the R installation, possibly with the option to update them via https. The R archive network already has SSL certs for it's root servers so that should be fine I think. > At the very least, you need to parse the OpenPGP message, which is > what gpg does. Is this available at the C level, similar to ? https://www.openssl.org/docs/manmaster/crypto/pem.html From neal at walfield.org Fri Dec 4 14:11:14 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 04 Dec 2015 14:11:14 +0100 Subject: gpg-verify c api In-Reply-To: References: <87egf2jshh.wl-neal@walfield.org> Message-ID: <87d1umjr4d.wl-neal@walfield.org> Hi, At Fri, 4 Dec 2015 14:06:33 +0100, Jeroen Ooms wrote: > On Fri, Dec 4, 2015 at 1:41 PM, Neal H. Walfield wrote: > > There is no such library as far as I know. The closest that I'm aware > > of is gpgv, which just verifies signatures (it part of the GnuPG). > > But gpgv only has a command line interface, correct? Or does it also > provide a C API? Correct. It is a program. But if you are willing to depend on a library, I don't see why you can't depend on an executable. > > A signature is not much more use than a checksum if you don't also > > check the key's validity. How were you planning on doing this? Were > > you just going to hard code a few keys? > > Yes, I was thinking of shipping trusted keys with the R installation, > possibly with the option to update them via https. The R archive > network already has SSL certs for it's root servers so that should be > fine I think. Sounds like a disaster waiting to happen. > > At the very least, you need to parse the OpenPGP message, which is > > what gpg does. > > Is this available at the C level, similar to ? > https://www.openssl.org/docs/manmaster/crypto/pem.html No. Neal From wk at gnupg.org Fri Dec 4 14:06:49 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Dec 2015 14:06:49 +0100 Subject: [Announce] GnuPG 2.1.10 released Message-ID: <878u5al5w6.fsf@vigenere.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.10. The main features of this release are support for TOFU (Trust-On-First-Use) and anonymous key retrieval via Tor. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG 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 branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - 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. Noteworthy changes in version 2.1.10 ==================================== * gpg: New trust models "tofu" and "tofu+pgp". * gpg: New command --tofu-policy. New options --tofu-default-policy and --tofu-db-format. * gpg: New option --weak-digest to specify hash algorithms which should be considered weak. * gpg: Allow the use of multiple --default-key options; take the last available key. * gpg: New option --encrypt-to-default-key. * gpg: New option --unwrap to only strip the encryption layer. * gpg: New option --only-sign-text-ids to exclude photo IDs from key signing. * gpg: Check for ambigious or non-matching key specification in the config file or given to --encrypt-to. * gpg: Show the used card reader with --card-status. * gpg: Print export statistics and an EXPORTED status line. * gpg: Allow selecting subkeys by keyid in --edit-key. * gpg: Allow updating the expiration time of multiple subkeys at once. * dirmngr: New option --use-tor. For full support this requires libassuan version 2.4.2 and a patched version of libadns (e.g. adns-1.4-g10-7 as used by the standard Windows installer). * dirmngr: New option --nameserver to specify the nameserver used in Tor mode. * dirmngr: Keyservers may again be specified by IP address. * dirmngr: Fixed problems in resolving keyserver pools. * dirmngr: Fixed handling of premature termination of TLS streams so that large numbers of keys can be refreshed via hkps. * gpg: Fixed a regression in --locate-key [since 2.1.9]. * gpg: Fixed another bug for keyrings with legacy keys. * gpgsm: Allow combinations of usage flags in --gen-key. * Make tilde expansion work with most options. * Many other cleanups and bug fixes. A detailed description of the changes found in the 2.1 branch can be found at . Please be aware that there are still known bugs which we are working on. Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.10 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 . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.10.tar.bz2 (5052k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.10.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.10.tar.bz2 (5052k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.10.tar.bz2.sig An installer for Windows without any graphical frontend except for a basic Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.10_20151204.exe (2617k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.10_20151204.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.10_20151204.exe (2617k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.10_20151204.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. This Windows installer is missing translations, it has no TOFU support and no HKPS support. However, it fully supports Tor and the Tor browser. 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.10.tar.bz2 you would use this command: gpg --verify gnupg-2.1.10.tar.bz2.sig gnupg-2.1.10.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.10.tar.bz2, you run the command like this: sha1sum gnupg-2.1.10.tar.bz2 and check that the output matches the next line: 4aa2594d2d364fe7708a9739ae7cebd251e536c4 gnupg-2.1.10.tar.bz2 b86b642390e1bf1b144b84dfabdcd574a56c0ba8 gnupg-w32-2.1.10_20151204.exe 2923d56ac5288570b5503c3038081dc28e6294cd gnupg-w32-2.1.10_20151204.tar.xz 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 keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2111 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 . 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 need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Maintenance and development of GnuPG is mostly financed by donations. As of today we employ 3 full-time developers, one part-timer, and one contractor. They all work on GnuPG and closely related software like Enigmail. Please see https://gnupg.org/donate/ on how you can help. 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, answering questions on the mailing lists, and donating money. For the GnuPG hackers, Werner p.s. This is an 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 mail at joed.hu Fri Dec 4 14:43:52 2015 From: mail at joed.hu (=?windows-1252?Q?Dubravszky_J=F3zsef?=) Date: Fri, 4 Dec 2015 14:43:52 +0100 Subject: gpg-agent protocol In-Reply-To: <565F90EB.3080702@fsij.org> References: <03aa01d12d14$932004c0$b9600e40$@joed.hu> <565F90EB.3080702@fsij.org> Message-ID: <01db01d12e99$d4178440$7c468cc0$@joed.hu> Hello, Thank you Yutaka San. That was my first idea but have not got the chance to try it. But most certainly I will try it the current shared memory operations based protocol. On #gnupg @ Freenode had this idea, that gpg-agent.exe uses Windows named pipes and it could be used with gpg-connect-agent -S C:\Users\USERNAME\AppData\Roaming\gnupg\S.gpg-agent.ssh. If the shmop version fails, will give this a shot too. Anyways, I will post results. BR, joe Dubravszky J?zsef mail at joed.hu +36 30?435 7816 -----Original Message----- From: NIIBE Yutaka [mailto:gniibe at fsij.org] Sent: Thursday, December 03, 2015 1:47 AM To: gnupg-devel at gnupg.org Subject: Re: gpg-agent protocol On 12/03/2015 12:17 AM, Dubravszky J?zsef wrote: > Atsuhiko Yamanaka made an excellent Eclipse SSH agent plugin > (https://github.com/ymnk/jsch-agent-proxy) to proxy SSH agents to Eclipse > subsystems. Currently it supports ssh-agent on Linux and Pageant on Windows. It's good to hear his name again. Great. I guess it also just works with gpg-agent, possibly. (Newer) gpg-agent supports the communication method of Pageant<->Putty. > My question might sound silly, but is there anything that would > prevent me writing a connector that uses the same Win32 shared > memory operations based protocol? IIUC, the connector for Pageant works with gpg-agent, because it's the same protocol. Please try. > I also recognized that on Windows an S.gpg-agent.ssh file is created in the > users roaming AppData > (C:\Users\USERNAME\AppData\Roaming\gnupg\S.gpg-agent.ssh), that pretty much > resembles a Unix socket. As far as I know there is no such compatible domain > socket on Windows, but what is this file then? Please note that my knowledge is limited since I'm not a Windows user. GnuPG implements Unix domain socket emulation and use it for gpg<->gpg-agent communication. The S.gpg-agent.ssh is the one for SSH, while there are no client program on Windows (Putty uses another channel: Win32 shared memory operations). -- From wk at gnupg.org Fri Dec 4 16:43:55 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Dec 2015 16:43:55 +0100 Subject: status code for gpgme_op_delete In-Reply-To: (Daiki Ueno's message of "Fri, 04 Dec 2015 18:45:06 +0900") References: <87fv0qs1e8.fsf-ueno@gnu.org> Message-ID: <87bna6jk1w.fsf@vigenere.g10code.de> On Fri, 4 Dec 2015 10:45, ueno at gnu.org said: > For what it's worth, I'm attaching a patch for GnuPG and its counterpart > for GPGME. With the patch, gpg emits an ERROR status line with Thanks. > + write_status_error ("delete_key.secret", > + gpg_err_code (err)); I changed that to > + write_status_error ("delete_key.secret", err); so that the error source is conveyed. gpgme the uses gpg_err_code to strip that and replace it with the GPGME error source. But it might come handy for other purposes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Dec 5 13:42:05 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Dec 2015 13:42:05 +0100 Subject: adns and TOR In-Reply-To: <22083.42471.21873.170334@chiark.greenend.org.uk> (Ian Jackson's message of "Wed, 11 Nov 2015 20:32:39 +0000") References: <87vba1n0nc.fsf@vigenere.g10code.de> <22054.22959.951094.201969@chiark.greenend.org.uk> <87h9llmk1m.fsf@vigenere.g10code.de> <22055.30470.407246.973906@chiark.greenend.org.uk> <87a8rchuku.fsf@vigenere.g10code.de> <22055.62681.859262.777669@chiark.greenend.org.uk> <8737wcnv77.fsf@vigenere.g10code.de> <22083.42471.21873.170334@chiark.greenend.org.uk> Message-ID: <87610dgj8i.fsf@vigenere.g10code.de> On Wed, 11 Nov 2015 21:32, ijackson at chiark.greenend.org.uk said: > Hi. I got your mail, thanks. I will try to look at this properly > soon. If I don't, please chase me. Had you a chance to look at the code? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From patrick at enigmail.net Sat Dec 5 19:43:09 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 5 Dec 2015 19:43:09 +0100 Subject: [Announce] GnuPG 2.1.10 released In-Reply-To: <878u5al5w6.fsf__1975.93347770653$1449235613$gmane$org@vigenere.g10code.de> References: <878u5al5w6.fsf__1975.93347770653$1449235613$gmane$org@vigenere.g10code.de> Message-ID: <5663303D.7000509@enigmail.net> On 04.12.15 14:06, Werner Koch wrote: > Hello! > > The GnuPG team is pleased to announce the availability of a new release > of GnuPG modern: Version 2.1.10. The main features of this release are > support for TOFU (Trust-On-First-Use) and anonymous key retrieval via > Tor. GnuPG compilation fails on Mac OS X with the following errors: dns-stuff.c:1303:5: error: use of undeclared identifier 'HEADER' HEADER *header = (HEADER *)answer; (and a few more of these) dns-stuff.c:1328:16: error: use of undeclared identifier 'QFIXEDSZ' pt += rc + QFIXEDSZ; Any idea? -Patrick From ca+gnupg-devel at esmtp.org Sat Dec 5 20:00:44 2015 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Sat, 5 Dec 2015 11:00:44 -0800 Subject: GnuPG 2.1.10 failure on MacOSX In-Reply-To: <5663303D.7000509@enigmail.net> References: <878u5al5w6.fsf__1975.93347770653$1449235613$gmane$org@vigenere.g10code.de> <5663303D.7000509@enigmail.net> Message-ID: <20151205190043.GA169@x2.esmtp.org> On Sat, Dec 05, 2015, Patrick Brunschwig wrote: > GnuPG compilation fails on Mac OS X with the following errors: Disclaimer: I don't use OS X. > dns-stuff.c:1303:5: error: use of undeclared identifier 'HEADER' > HEADER *header = (HEADER *)answer; > (and a few more of these) > dns-stuff.c:1328:16: error: use of undeclared identifier 'QFIXEDSZ' > pt += rc + QFIXEDSZ; Some DNS related include file is missing. Look in /usr/include/arpa (or some other include directory) for nameser.h nameser8_compat.h nameser_compat.h and find the one that has the definitions. From wk at gnupg.org Sat Dec 5 22:39:38 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Dec 2015 22:39:38 +0100 Subject: [Announce] GnuPG 2.1.10 released In-Reply-To: <5663303D.7000509@enigmail.net> (Patrick Brunschwig's message of "Sat, 5 Dec 2015 19:43:09 +0100") References: <878u5al5w6.fsf__1975.93347770653$1449235613$gmane$org@vigenere.g10code.de> <5663303D.7000509@enigmail.net> Message-ID: <87si3gfucl.fsf@vigenere.g10code.de> On Sat, 5 Dec 2015 19:43, patrick at enigmail.net said: > dns-stuff.c:1303:5: error: use of undeclared identifier 'HEADER' Use adns and best the patched adns version we use in the Windows installer, that one has Tor support: ftp://ftp.g10code.com/g10code/adns/adns-1.4-g10-7.tar.bz2 ftp://ftp.g10code.com/g10code/adns/adns-1.4-g10-7.tar.bz2.sig It should be possible to link static but I have not yet tried. Use configure option --with-adns if configure does not pick up adns. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at gnu.org Mon Dec 7 10:13:40 2015 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 07 Dec 2015 18:13:40 +0900 Subject: status code for gpgme_op_delete In-Reply-To: <87bna6jk1w.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 04 Dec 2015 16:43:55 +0100") References: <87fv0qs1e8.fsf-ueno@gnu.org> <87bna6jk1w.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: > I changed that to > >> + write_status_error ("delete_key.secret", err); > > so that the error source is conveyed. gpgme the uses gpg_err_code to > strip that and replace it with the GPGME error source. But it might > come handy for other purposes. Thanks for fixing and checking it in. Could you also take a look at: https://lists.gnupg.org/pipermail/gnupg-devel/2015-November/030527.html Actually it does not fix the issue 1415 out-of-box, but I have confirmed that it does if I add "exit-on-status-write-error" to ~/.gnupg/gpg.conf. I'm not certain if it is a good idea to let GPGME pass that option to gpg. Regards, -- Daiki Ueno From patrick at enigmail.net Tue Dec 8 14:24:22 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 8 Dec 2015 14:24:22 +0100 Subject: [Announce] GnuPG 2.1.10 released In-Reply-To: <87si3gfucl.fsf@vigenere.g10code.de> References: <878u5al5w6.fsf__1975.93347770653$1449235613$gmane$org@vigenere.g10code.de> <5663303D.7000509@enigmail.net> <87si3gfucl.fsf@vigenere.g10code.de> Message-ID: <5666DA06.1080504@enigmail.net> On 05.12.15 22:39, Werner Koch wrote: > On Sat, 5 Dec 2015 19:43, patrick at enigmail.net said: > >> dns-stuff.c:1303:5: error: use of undeclared identifier 'HEADER' > > Use adns and best the patched adns version we use in the Windows > installer, that one has Tor support: > > ftp://ftp.g10code.com/g10code/adns/adns-1.4-g10-7.tar.bz2 > ftp://ftp.g10code.com/g10code/adns/adns-1.4-g10-7.tar.bz2.sig > > It should be possible to link static but I have not yet tried. Use > configure option --with-adns if configure does not pick up adns. I managed to build gpg 2.1.10 with forcing a static build of adns. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From justus at g10code.com Tue Dec 8 14:03:59 2015 From: justus at g10code.com (Justus Winter) Date: Tue, 08 Dec 2015 14:03:59 +0100 Subject: On Scute v1.4.0 support key length up to 4096, proceed s-expressions on common way In-Reply-To: <564CBD34.1030608@gurevich.de> References: <564CBD34.1030608@gurevich.de> Message-ID: <20151208130359.30188.85672@thinkbox.jade-hamburg.de> Hi Oleg, Quoting Oleg Gurevich (2015-11-18 19:02:28) > would you please take a look on following patch. thanks for your patch. I cannot comment on the big picture, but I can nitpick a little. > +struct s_expression { We follow the GNU coding conventions, see doc/HACKING for details. Please put the opening bracket on a new line here. > + unsigned int sig_len; > + char *prefix; > + unsigned int prefix_len; > + Spurious newline. > +} supported_expr[] = { Likewise insert a newline here please. > + /* FIXME: better ? */ > + err = GPG_ERR_BAD_SIGNATURE; > + for(i = 0; i < sizeof(supported_expr) / sizeof(struct s_expression); i++) sizeof is an operator and hence requires no parenthesis in general. If required, please add a space before opening parenthesis. Maybe we even have a version of ARRAY_SIZE, I don't know tbh. > { > - if (sig.len != SIG_PREFIX_LEN + SIG_LEN + SIG_POSTFIX_LEN) > - return gpg_error (GPG_ERR_BAD_SIGNATURE); > - if (memcmp (sig.data, SIG_PREFIX, SIG_PREFIX_LEN)) > - return gpg_error (GPG_ERR_BAD_SIGNATURE); > - if (memcmp (sig.data + sig.len - SIG_POSTFIX_LEN, > - SIG_POSTFIX, SIG_POSTFIX_LEN)) > - return gpg_error (GPG_ERR_BAD_SIGNATURE); > - memcpy (sig_result, sig.data + SIG_PREFIX_LEN, SIG_LEN); > - *sig_len = SIG_LEN; > + if( sig.len == supported_expr[i].prefix_len + Personally, I like 'if (expr)' better than 'if( expr )', and even though both is used in gnupg, I the former is used more often. In general, try to make your changes blend in with the code surrounding it. Likewise for 'for'. > supported_expr[i].sig_len + SIG_POSTFIX_LEN ) Note that your patch got mangled by your MUA. Consider using git send-email. > + { > + // check prefix matching No C++ comments please. > + if (memcmp (sig.data, supported_expr[i].prefix, > supported_expr[i].prefix_len)) Likewise mangled here. > + return gpg_error (GPG_ERR_BAD_SIGNATURE); > + // check postfix matching > + if(memcmp(sig.data + sig.len - SIG_POSTFIX_LEN, SIG_POSTFIX, Space before the '('s. Cheers, Justus From oleg at gurevich.de Tue Dec 8 19:49:45 2015 From: oleg at gurevich.de (Oleg Gurevich) Date: Tue, 08 Dec 2015 19:49:45 +0100 Subject: On Scute v1.4.0 support key length up to 4096, proceed s-expressions on common way In-Reply-To: <20151208130359.30188.85672@thinkbox.jade-hamburg.de> References: <564CBD34.1030608@gurevich.de> <20151208130359.30188.85672@thinkbox.jade-hamburg.de> Message-ID: <56672649.8010404@gurevich.de> Hi Justus, thank you for comments. I appreciate it. It is decent and makes sense. ... will pay attention next time and hope it will get better. mit freundlichen Gr??en/ ? ?????????/ best regards Oleg Gurevich PGP Key: E74A0B0C PGP fingerprint: 38A0 D0CC BD23 1707 B0AF D158 E9D7 6E3F E74A 0B0C On 12/08/2015 02:03 PM, Justus Winter wrote: > Hi Oleg, > > Quoting Oleg Gurevich (2015-11-18 19:02:28) >> would you please take a look on following patch. > > thanks for your patch. I cannot comment on the big picture, but I can > nitpick a little. > >> +struct s_expression { > > We follow the GNU coding conventions, see doc/HACKING for details. > Please put the opening bracket on a new line here. > >> + unsigned int sig_len; >> + char *prefix; >> + unsigned int prefix_len; >> + > > Spurious newline. > >> +} supported_expr[] = { > > Likewise insert a newline here please. > >> + /* FIXME: better ? */ >> + err = GPG_ERR_BAD_SIGNATURE; >> + for(i = 0; i < sizeof(supported_expr) / sizeof(struct s_expression); i++) > > sizeof is an operator and hence requires no parenthesis in general. > If required, please add a space before opening parenthesis. Maybe we > even have a version of ARRAY_SIZE, I don't know tbh. > >> { >> - if (sig.len != SIG_PREFIX_LEN + SIG_LEN + SIG_POSTFIX_LEN) >> - return gpg_error (GPG_ERR_BAD_SIGNATURE); >> - if (memcmp (sig.data, SIG_PREFIX, SIG_PREFIX_LEN)) >> - return gpg_error (GPG_ERR_BAD_SIGNATURE); >> - if (memcmp (sig.data + sig.len - SIG_POSTFIX_LEN, >> - SIG_POSTFIX, SIG_POSTFIX_LEN)) >> - return gpg_error (GPG_ERR_BAD_SIGNATURE); >> - memcpy (sig_result, sig.data + SIG_PREFIX_LEN, SIG_LEN); >> - *sig_len = SIG_LEN; >> + if( sig.len == supported_expr[i].prefix_len + > > Personally, I like 'if (expr)' better than 'if( expr )', and even > though both is used in gnupg, I the former is used more often. In > general, try to make your changes blend in with the code surrounding > it. Likewise for 'for'. > >> supported_expr[i].sig_len + SIG_POSTFIX_LEN ) > > Note that your patch got mangled by your MUA. Consider using git > send-email. > >> + { >> + // check prefix matching > > No C++ comments please. > >> + if (memcmp (sig.data, supported_expr[i].prefix, >> supported_expr[i].prefix_len)) > > Likewise mangled here. > >> + return gpg_error (GPG_ERR_BAD_SIGNATURE); >> + // check postfix matching >> + if(memcmp(sig.data + sig.len - SIG_POSTFIX_LEN, SIG_POSTFIX, > > Space before the '('s. > > > Cheers, > Justus > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Dec 8 20:03:55 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Dec 2015 20:03:55 +0100 Subject: [Announce] GnuPG 2.1.10 released In-Reply-To: <5666DA06.1080504@enigmail.net> (Patrick Brunschwig's message of "Tue, 8 Dec 2015 14:24:22 +0100") References: <878u5al5w6.fsf__1975.93347770653$1449235613$gmane$org@vigenere.g10code.de> <5663303D.7000509@enigmail.net> <87si3gfucl.fsf@vigenere.g10code.de> <5666DA06.1080504@enigmail.net> Message-ID: <874mfsn4o4.fsf@vigenere.g10code.de> On Tue, 8 Dec 2015 14:24, patrick at enigmail.net said: > I managed to build gpg 2.1.10 with forcing a static build of adns. That might actually be the best way because the libary is only used by dirmngr. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Dec 9 19:01:04 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 9 Dec 2015 13:01:04 -0500 Subject: [PATCH] fix keystrlen when no keyid-format option has been given Message-ID: <1449684064-18144-1-git-send-email-dkg@fifthhorseman.net> * g10/keyid.c (keystrlen): if opt.keyid_format has not been set, default to 0xLONG, as is done in format_keyid. -- Without this fix, gpgv2 fails with: gpgv: Ohhhh jeeee: ... this is a bug (keyid.c:342:keystrlen) Signed-off-by: Daniel Kahn Gillmor --- g10/keyid.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/g10/keyid.c b/g10/keyid.c index cb237ef..bb5c7b9 100644 --- a/g10/keyid.c +++ b/g10/keyid.c @@ -324,7 +324,11 @@ format_keyid (u32 *keyid, int format, char *buffer, int len) size_t keystrlen(void) { - switch(opt.keyid_format) + int format = opt.keyid_format; + if (format == KF_DEFAULT) + format = KF_0xLONG; + + switch(format) { case KF_SHORT: return 8; -- 2.6.2 From dh at dotlan.net Wed Dec 9 16:56:32 2015 From: dh at dotlan.net (Daniel Hoffend) Date: Wed, 9 Dec 2015 16:56:32 +0100 Subject: Unplugging USB Smartcard/Yubikey causes problems with scdaemon Message-ID: <20151209155631.GA912@dotCarbon> Hello, In the last days I've tracked down an issue under windows where unplugging the yubikey (usb smartcard reader with integrated smartcard) resulted in an usable scdaemon. Once plugged out the yubikey will no longer work until I killed the scdaemon from the task manager. The main issue is that unplugging pcsc/scdaemon throws an error which is mapped to general error leaving the smartcard loaded in an unusable state. It still shows the smartcard loaded which is unsuable. I've documented the issue including scdaemon debug logs with comments in the bug tracker: https://bugs.gnupg.org/gnupg/issue2167 I've also created a patch which maps the 2 errors I've encountered SCARD_E_NO_SERVICE and SCARD_E_SERVICE_STOPPED to the internal SW_HOST_NO_READER error. This should result in removing the no longer existing Smarcard Reader from the current list of active devices. https://bugs.gnupg.org/gnupg/file732/0001-scd-Fix-removal-of-unplugged-usb-readers.patch Since I'm not able to compile the windows version of gpg myself I can't verify this finally. I also can't say for sure that the 2 errors aren't used in any other scenario but right now it sounds logical to me. I'm able to reproduce this error using the stable gnupg 2.0.29 version (from gpg4win 2.3) and the gnupg 2.1.9 (solo installation). The patch should fix the issue for 2.0 and 2.1 hopefully. If there's anything else I can help you with I'm happy to help testing again. -- Best Regards Daniel Hoffend From dkg at fifthhorseman.net Wed Dec 9 21:24:24 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 09 Dec 2015 15:24:24 -0500 Subject: [PATCH] ship sks-keyservers.netCA.pem in distributed tarball In-Reply-To: <878u6sdj58.fsf@vigenere.g10code.de> References: <1445312986-29456-1-git-send-email-dkg@fifthhorseman.net> <87lhat8dir.fsf@alice.fifthhorseman.net> <878u6sdj58.fsf@vigenere.g10code.de> Message-ID: <87oadznzev.fsf@alice.fifthhorseman.net> On Sat 2015-10-24 17:57:39 -0400, Werner Koch wrote: > On Fri, 23 Oct 2015 23:45, dkg at fifthhorseman.net said: >> Any followup on this? is there a reason we shouldn't ship Kristian's >> cert as part of the source tarball? > > Sure, we will do this. This is still not done in 2.1.10, afaict. Should i open a ticket at https://bugs.gnupg.org with the patch that started this original thread? what's the best way for me to follow up on things like this? i don't want to feel like i'm nagging! --dkg From calestyo at scientia.net Wed Dec 9 21:59:16 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Wed, 09 Dec 2015 21:59:16 +0100 Subject: [PATCH] ship sks-keyservers.netCA.pem in distributed tarball In-Reply-To: <87oadznzev.fsf@alice.fifthhorseman.net> References: <1445312986-29456-1-git-send-email-dkg@fifthhorseman.net> <87lhat8dir.fsf@alice.fifthhorseman.net> <878u6sdj58.fsf@vigenere.g10code.de> <87oadznzev.fsf@alice.fifthhorseman.net> Message-ID: <1449694756.6354.21.camel@scientia.net> On Wed, 2015-12-09 at 15:24 -0500, Daniel Kahn Gillmor wrote: > On Sat 2015-10-24 17:57:39 -0400, Werner Koch wrote: > > On Fri, 23 Oct 2015 23:45, dkg at fifthhorseman.net said: > > > Any followup on this???is there a reason we shouldn't ship > > > Kristian's > > > cert as part of the source tarball? > > > > Sure, we will do this. > > This is still not done in 2.1.10, afaict.??Should i open a ticket at > https://bugs.gnupg.org with the patch that started this original > thread? > > what's the best way for me to follow up on things like this? i don't > want to feel like i'm nagging! btw: I still don't see how hkps adds any real security or trust... or privacy - at least not as a single measurement. The first problem is that there is too much power in one person (the CA's root), and while I have no reason to distrust Kristian (and I hope he doesn't take this personal in anyway)... it's still a conceptual problem that we shouldn't introduce in GPG, at least not, if that means we don't do any further/real measurements to improve keyserver network security. The next problem would be, that *anyone* gets certificates from Kristian, without any real validation (at least nothing that would be more than sending it to the email address the keyserver would announce as it's operator - which is of course however nothing that Kristian could know for sure, as it's not secured). As I've said previously at several occasions, the best the clients could IMHO do to improve the security of their interaction with the keyserver network is the following: - send any key submissions to *many* keyservers (ideally of course to as many as possible) - send any search requests to *many* keyservers (ideally of course to as many as possible), match their results (and warn if there are too many differences) and merge their results (i.e. if one keyserver would e.g. include a revoc cert or other signatures, that another (possibly evil) keyserver would have stripped off). - For privacy concerns, Tor is the solution (speaking of gpg as tor client)[1] - Another, effective way would be, that gnupg.org operates a keyserver itself and that this one is *always* included in the above mentioned set of keyservers used for multi-submissions/requests. The idea is simply: If one trusts GnuPG (i.e. the software) we can also trust their server.. and if a powerful attacker would manage to force Werner&Co. to manipulate their keyserver (by law or whatever), the would possibly also manage to force them to introduce some very subtle hidden security hole. And again, this doesn't mean that I wouldn't see any value in Kristian's work (actually I appreciate it, and my own keyserver also has one of his certs in place),... but as the only measurement to improve keyserver security, I don't think it's (effective) enough, and rather may give a wrong sense of security. Cheers, Chris. [1] There was that discussion recently on sks-devel about keyservers as hidden tor services. I still largely remain on my PoV that there is no real security benefit of that, except for the case, that there would be hidden-Tor-services-only keyservers, whose operators remain fully anonymous (in their communication with e.g. sks-devel) and which operate *no* normal (i.e. non hidden-Tor-service) keyserver. Cause, the only real security benefit that I've been convinced of is, that by that way, we could hide some keyservers (and their key DBs) from possibly evil powers (NSA and friends), which may force the operators to manipulate the DB. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From andrey.od.utkin at gmail.com Wed Dec 9 23:05:58 2015 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Thu, 10 Dec 2015 00:05:58 +0200 Subject: Please consider joining Bountysource Salt to collect recurring donations Message-ID: <5668A5C6.10603@gmail.com> This request targets GnuPG maintainers to register a team on that (and/or others, e.g. Gratipay) croudfunding platform. GnuPG users are welcome to comment whether they would support such opportunity. Occasional GnuPG contributors are welcome to comment whether they would like to become "bounty hunters" (an opportunity on subj site). I am not affiliated to these platforms. -- OpenPGP usage is appreciated (it also helps your letter to bypass spam filters). To email me with encryption easily, go https://encrypt.to/0xC6FCDB11 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Dec 10 00:21:31 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 09 Dec 2015 18:21:31 -0500 Subject: [PATCH] ship sks-keyservers.netCA.pem in distributed tarball In-Reply-To: <1449694756.6354.21.camel@scientia.net> References: <1445312986-29456-1-git-send-email-dkg@fifthhorseman.net> <87lhat8dir.fsf@alice.fifthhorseman.net> <878u6sdj58.fsf@vigenere.g10code.de> <87oadznzev.fsf@alice.fifthhorseman.net> <1449694756.6354.21.camel@scientia.net> Message-ID: <87bn9znr7o.fsf@alice.fifthhorseman.net> Hi Christoph-- On Wed 2015-12-09 15:59:16 -0500, Christoph Anton Mitterer wrote: > I still don't see how hkps adds any real security or trust... or > privacy - at least not as a single measurement. There are two significant gains: A) do you want your keyserver pushes and fetches to be visible to everyone along the network path or whether you want them to be limited to whichever keyserver operator you end up choosing? B) do you want your traffic to the keyserver (and its responses to you) to be undetectably modified by anyone along the network path, or do you want the tampering to be limited to the set of keyserver operators? This is very far from a complete security guarantee. But it is substantially better than cleartext over the public Internet. At the very least, passive adversaries are blocked in this configuration. Please don't make it harder to make some progress even though it's clear that we all share the goal to eventually provide an even stronger guarantee. Regards, --dkg From calestyo at scientia.net Thu Dec 10 00:33:48 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Thu, 10 Dec 2015 00:33:48 +0100 Subject: [PATCH] ship sks-keyservers.netCA.pem in distributed tarball In-Reply-To: <87bn9znr7o.fsf@alice.fifthhorseman.net> References: <1445312986-29456-1-git-send-email-dkg@fifthhorseman.net> <87lhat8dir.fsf@alice.fifthhorseman.net> <878u6sdj58.fsf@vigenere.g10code.de> <87oadznzev.fsf@alice.fifthhorseman.net> <1449694756.6354.21.camel@scientia.net> <87bn9znr7o.fsf@alice.fifthhorseman.net> Message-ID: <1449704028.6354.35.camel@scientia.net> On Wed, 2015-12-09 at 18:21 -0500, Daniel Kahn Gillmor wrote: > A) do you want your keyserver pushes and fetches to be visible to > ???everyone along the network path or whether you want them to be > ???limited to whichever keyserver operator you end up choosing? > > B) do you want your traffic to the keyserver (and its responses to > you) > ???to be undetectably modified by anyone along the network path, or > do > ???you want the tampering to be limited to the set of keyserver > ???operators? Both, however, don't protect against any attacker simply setting up a keyserver and directly trying to get privacy related information or mangle around with the data. > This is very far from a complete security guarantee.??But it is > substantially better than cleartext over the public Internet. Agreed, but as I've said... we shouldn't make ourself believe that this makes things really secure... (or even trustworthy). > Please don't make it harder to make some progress even though it's > clear > that we all share the goal to eventually provide an even stronger > guarantee. I don't think I've said or did anything that made it harder... just that this alone isn't enough. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 10 17:29:58 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Dec 2015 17:29:58 +0100 Subject: [PATCH] fix keystrlen when no keyid-format option has been given In-Reply-To: <1449684064-18144-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 9 Dec 2015 13:01:04 -0500") References: <1449684064-18144-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87bn9ygtbt.fsf@vigenere.g10code.de> On Wed, 9 Dec 2015 19:01, dkg at fifthhorseman.net said: > * g10/keyid.c (keystrlen): if opt.keyid_format has not been set, > default to 0xLONG, as is done in format_keyid. > gpgv: Ohhhh jeeee: ... this is a bug (keyid.c:342:keystrlen) Neal, why did you introduced the KF_DEFAULT at all? I can't immediately the the reason. While looking at the code I also wonder why we do this: if (keyid[0]) snprintf (buffer, len, "%08lX%08lX", (ulong)keyid[0], (ulong)keyid[1]); else snprintf (buffer, len, "%08lX", (ulong)keyid[1]); break; This break the column alignment for keyis 0x00000000xxxxxxxxx . Granted, this is a rare case but why should be do that at all, the commit message from 2004 says: * keyid.c (keystr): If printing a keyid that lacks the high 4 bytes, print the low 4 alone. (keystr_from_desc): Handle short keyids and warn on v3 fingerprints. However, last year I fixed the indentation in some messages to match the current keyid format - this requires that keyid has a constant length. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 10 20:35:28 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Dec 2015 20:35:28 +0100 Subject: [PATCH] ship sks-keyservers.netCA.pem in distributed tarball In-Reply-To: <87oadznzev.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 09 Dec 2015 15:24:24 -0500") References: <1445312986-29456-1-git-send-email-dkg@fifthhorseman.net> <87lhat8dir.fsf@alice.fifthhorseman.net> <878u6sdj58.fsf@vigenere.g10code.de> <87oadznzev.fsf@alice.fifthhorseman.net> Message-ID: <877fkmf667.fsf@vigenere.g10code.de> On Wed, 9 Dec 2015 21:24, dkg at fifthhorseman.net said: > This is still not done in 2.1.10, afaict. Should i open a ticket at > https://bugs.gnupg.org with the patch that started this original thread? Yes, please. That is safer. Sorry, I forgot about this as I put most effort into getting Tor support into 2.1.10 which is helpful also for WIndows users because there we do not have TLS yet in 2.1. > what's the best way for me to follow up on things like this? i don't > want to feel like i'm nagging! No problem. Feel also free to nag me on Jabber. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Dec 10 23:26:17 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 10 Dec 2015 17:26:17 -0500 Subject: [PATCH] ship sks-keyservers.netCA.pem in distributed tarball In-Reply-To: <877fkmf667.fsf@vigenere.g10code.de> References: <1445312986-29456-1-git-send-email-dkg@fifthhorseman.net> <87lhat8dir.fsf@alice.fifthhorseman.net> <878u6sdj58.fsf@vigenere.g10code.de> <87oadznzev.fsf@alice.fifthhorseman.net> <877fkmf667.fsf@vigenere.g10code.de> Message-ID: <87zixij5yu.fsf@alice.fifthhorseman.net> On Thu 2015-12-10 14:35:28 -0500, Werner Koch wrote: > On Wed, 9 Dec 2015 21:24, dkg at fifthhorseman.net said: > >> This is still not done in 2.1.10, afaict. Should i open a ticket at >> https://bugs.gnupg.org with the patch that started this original thread? > > Yes, please. That is safer. that's now done: https://bugs.gnupg.org/gnupg/issue2181 > Sorry, I forgot about this as I put most effort into getting Tor support > into 2.1.10 which is helpful also for WIndows users because there we do > not have TLS yet in 2.1. yep, adding tor support is much appreciated. thanks! --dkg From dkg at fifthhorseman.net Fri Dec 11 02:22:19 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 10 Dec 2015 20:22:19 -0500 Subject: can't build master: es_poll_t type is unknown in common/sh-exectool.{c, h} Message-ID: <877fklkcdw.fsf@alice.fifthhorseman.net> i can't build from the current master because of errors having to do with es_poll_t in common/sh-exectool.{c,h}, which seems to have been introduced without any declaration of the type in 2ae07f826aa551db8adf714158fce962790a6b54 and a81aca6e1c2a4529d416d1989f15d7338d2ee81e. for example: make[3]: Entering directory '/home/dkg/src/pkg-gnupg/gnupg2/common' gcc -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"lib/gnupg2\"" -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/usr/local/var\"" -DWITHOUT_NPTH=1 -Wall -Wno-pointer-sign -Wpointer-arith -g -O2 -MT libcommon_a-sh-exectool.o -MD -MP -MF .deps/libcommon_a-sh-exectool.Tpo -c -o libcommon_a-sh-exectool.o `test -f 'sh-exectool.c' || echo './'`sh-exectool.c sh-exectool.c:48:52: error: unknown type name ?es_poll_t? read_and_log_stderr (read_and_log_buffer_t *state, es_poll_t *fderr) ^ sh-exectool.c: In function ?sh_exec_tool_stream?: sh-exectool.c:227:3: error: unknown type name ?es_poll_t? es_poll_t fds[3]; hth, --dkg From dkg at fifthhorseman.net Fri Dec 11 04:05:48 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 10 Dec 2015 22:05:48 -0500 Subject: [PATCH v2] Use sks-keyservers CA by default for the hkps pool. In-Reply-To: <87zixij5yu.fsf@alice.fifthhorseman.net> References: <87zixij5yu.fsf@alice.fifthhorseman.net> Message-ID: <1449803148-8458-1-git-send-email-dkg@fifthhorseman.net> Ship the certificate for the sks-keyservers hkps pool. If the user has specified that they want to use hkps://hkps.pool.sks-keyservers.net, and they have not specified any hkp-cacert explicitly, then initialize the trust path with this specific trust anchor. --- dirmngr/Makefile.am | 1 + dirmngr/http.c | 22 +++++++++++++++++++++- dirmngr/http.h | 3 ++- dirmngr/ks-engine-hkp.c | 2 +- dirmngr/ks-engine-http.c | 2 +- dirmngr/t-http.c | 2 +- 6 files changed, 27 insertions(+), 5 deletions(-) diff --git a/dirmngr/Makefile.am b/dirmngr/Makefile.am index c3bce0d..1c74d10 100644 --- a/dirmngr/Makefile.am +++ b/dirmngr/Makefile.am @@ -20,6 +20,7 @@ ## Process this file with automake to produce Makefile.in EXTRA_DIST = OAUTHORS ONEWS ChangeLog-2011 tls-ca.pem +dist_pkgdata_DATA = sks-keyservers.netCA.pem bin_PROGRAMS = dirmngr dirmngr-client diff --git a/dirmngr/http.c b/dirmngr/http.c index 74b6911..c4f7cbc 100644 --- a/dirmngr/http.c +++ b/dirmngr/http.c @@ -130,6 +130,8 @@ "01234567890@" \ "!\"#$%&'()*+,-./:;<=>?[\\]^_{|}~" +#define HKPS_POOL_CA_PEM GNUPG_DATADIR "/sks-keyservers.netCA.pem" + /* A long counter type. */ #ifdef HAVE_STRTOULL typedef unsigned long long longcounter_t; @@ -562,7 +564,8 @@ http_session_release (http_session_t sess) /* Create a new session object which is currently used to enable TLS support. It may eventually allow reusing existing connections. */ gpg_error_t -http_session_new (http_session_t *r_session, const char *tls_priority) +http_session_new (http_session_t *r_session, const char *tls_priority, + const char *intended_hostname) { gpg_error_t err; http_session_t sess; @@ -600,6 +603,23 @@ http_session_new (http_session_t *r_session, const char *tls_priority) goto leave; } + /* if the user has not specified a CA list, and they are looking + * for the hkps pool from sks-keyservers.net, then default to + * Kristian's certificate authority: + */ + if (!tls_ca_certlist) + { + if (intended_hostname && + 0 == strcasecmp("hkps.pool.sks-keyservers.net", intended_hostname)) + { + rc = gnutls_certificate_set_x509_trust_file + (sess->certcred, HKPS_POOL_CA_PEM, GNUTLS_X509_FMT_PEM); + if (rc < 0) + log_info ("setting CA from file '" HKPS_POOL_CA_PEM "' failed: %s\n", + gnutls_strerror (rc)); + + } + } for (sl = tls_ca_certlist; sl; sl = sl->next) { rc = gnutls_certificate_set_x509_trust_file diff --git a/dirmngr/http.h b/dirmngr/http.h index 64f55e1..58b8c1a 100644 --- a/dirmngr/http.h +++ b/dirmngr/http.h @@ -98,7 +98,8 @@ void http_register_tls_callback (gpg_error_t (*cb)(http_t,http_session_t,int)); void http_register_tls_ca (const char *fname); gpg_error_t http_session_new (http_session_t *r_session, - const char *tls_priority); + const char *tls_priority, + const char *intended_hostname); http_session_t http_session_ref (http_session_t sess); void http_session_release (http_session_t sess); diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c index e458899..f6af688 100644 --- a/dirmngr/ks-engine-hkp.c +++ b/dirmngr/ks-engine-hkp.c @@ -990,7 +990,7 @@ send_request (ctrl_t ctrl, const char *request, const char *hostportstr, *r_fp = NULL; - err = http_session_new (&session, NULL); + err = http_session_new (&session, NULL, httphost); if (err) goto leave; http_session_set_log_cb (session, cert_log_cb); diff --git a/dirmngr/ks-engine-http.c b/dirmngr/ks-engine-http.c index ae128ee..c51c0ce 100644 --- a/dirmngr/ks-engine-http.c +++ b/dirmngr/ks-engine-http.c @@ -65,7 +65,7 @@ ks_http_fetch (ctrl_t ctrl, const char *url, estream_t *r_fp) estream_t fp = NULL; char *request_buffer = NULL; - err = http_session_new (&session, NULL); + err = http_session_new (&session, NULL, NULL); if (err) goto leave; http_session_set_log_cb (session, cert_log_cb); diff --git a/dirmngr/t-http.c b/dirmngr/t-http.c index 63662a2..9d5ea5f 100644 --- a/dirmngr/t-http.c +++ b/dirmngr/t-http.c @@ -262,7 +262,7 @@ main (int argc, char **argv) http_register_tls_callback (verify_callback); http_register_tls_ca (cafile); - err = http_session_new (&session, NULL); + err = http_session_new (&session, NULL, NULL); if (err) log_error ("http_session_new failed: %s\n", gpg_strerror (err)); -- 2.6.2 From justus at g10code.com Fri Dec 11 11:21:08 2015 From: justus at g10code.com (Justus Winter) Date: Fri, 11 Dec 2015 11:21:08 +0100 Subject: can't build master: es_poll_t type is unknown in common/sh-exectool.{c, h} In-Reply-To: <877fklkcdw.fsf@alice.fifthhorseman.net> References: <877fklkcdw.fsf@alice.fifthhorseman.net> Message-ID: <20151211102108.3140.81525@thinkbox.jade-hamburg.de> Hi Daniel, Quoting Daniel Kahn Gillmor (2015-12-11 02:22:19) > i can't build from the current master because of errors having to do > with es_poll_t in common/sh-exectool.{c,h}, which seems to have been > introduced without any declaration of the type in > 2ae07f826aa551db8adf714158fce962790a6b54 and > a81aca6e1c2a4529d416d1989f15d7338d2ee81e. Yeah, that is my fault. I merged code from Werner using the new type and didn't realize that I need to bump NEED_GPG_ERROR_VERSION. The new type is introduced in the yet unreleased libgpg-error 1.21. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: signature URL: From wk at gnupg.org Fri Dec 11 19:01:10 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Dec 2015 19:01:10 +0100 Subject: can't build master: es_poll_t type is unknown in common/sh-exectool.{c, h} In-Reply-To: <20151211102108.3140.81525@thinkbox.jade-hamburg.de> (Justus Winter's message of "Fri, 11 Dec 2015 11:21:08 +0100") References: <877fklkcdw.fsf@alice.fifthhorseman.net> <20151211102108.3140.81525@thinkbox.jade-hamburg.de> Message-ID: <87zixgc1ax.fsf@vigenere.g10code.de> On Fri, 11 Dec 2015 11:21, justus at g10code.com said: > and didn't realize that I need to bump NEED_GPG_ERROR_VERSION. The > new type is introduced in the yet unreleased libgpg-error 1.21. Oh dear, I thought I had released 1.21 - I'll do that in the next days. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Dec 12 14:19:54 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 12 Dec 2015 14:19:54 +0100 Subject: can't build master: es_poll_t type is unknown in common/sh-exectool.{c, h} In-Reply-To: <87zixgc1ax.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 11 Dec 2015 19:01:10 +0100") References: <877fklkcdw.fsf@alice.fifthhorseman.net> <20151211102108.3140.81525@thinkbox.jade-hamburg.de> <87zixgc1ax.fsf@vigenere.g10code.de> Message-ID: <87wpsjajnp.fsf@vigenere.g10code.de> On Fri, 11 Dec 2015 19:01, wk at gnupg.org said: > Oh dear, I thought I had released 1.21 - I'll do that in the next days. I just released libgpg-error 1.21 . Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From patrick at enigmail.net Sat Dec 12 18:27:18 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 12 Dec 2015 18:27:18 +0100 Subject: Gpg 2.1.10 - Invalid error with --encrypt-to Message-ID: <566C58F6.6070402@enigmail.net> Using GnuPG 2.1.10 with --encrypt-to brings wrong error messages. An example can be found here: https://bugs.gnupg.org/gnupg/issue2186 Another example is this one: Using gpg2 --encrypt-to 0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B \ -r someone - e Results in the following error message, which I consider wrong: gpg: key specification '0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B' is ambiguous gpg: (check argument of option '--encrypt-to') gpg: '0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B' matches at least: gpg: 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B gpg: 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B Result of gpg2 --list-keys 0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B: pub rsa4096/DD5F693B 2015-01-17 [expires: 2025-01-14] uid [ full ] Patrick Brunschwig uid [ full ] Patrick Brunschwig uid [ full ] [jpeg image of size 13251] sub rsa4096/4E4953D8 2015-01-17 [expires: 2018-01-16] -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Mon Dec 14 09:31:08 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 14 Dec 2015 09:31:08 +0100 Subject: [PATCH] gpg: Print ownertrust in TOFU+PGP trust model. Message-ID: <1450081868-24601-1-git-send-email-dgouttegattat@incenp.org> * g10/keyedit.c: Print ownertrust in TOFU+PGP trust model. -- The key editor currently prints out the ownertrust value assigned to a key only when using the classic or PGP trust models; but that value is also meaningful in the recently introduced TOFU+PGP combined model. Signed-off-by: Damien Goutte-Gattat --- g10/keyedit.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/g10/keyedit.c b/g10/keyedit.c index 0a4766e..d958db8 100644 --- a/g10/keyedit.c +++ b/g10/keyedit.c @@ -3233,9 +3233,10 @@ show_key_with_all_names (ctrl_t ctrl, estream_t fp, opt.legacy_list_mode? ((int) keystrlen () + 13):5, ""); /* Ownertrust is only meaningful for the PGP or - classic trust models */ + classic trust models, or PGP combined with TOFU */ if (opt.trust_model == TM_PGP - || opt.trust_model == TM_CLASSIC) + || opt.trust_model == TM_CLASSIC + || opt.trust_model == TM_TOFU_PGP) { int width = 14 - strlen (otrust); if (width <= 0) -- 1.8.4 From neal at walfield.org Mon Dec 14 12:00:07 2015 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 14 Dec 2015 12:00:07 +0100 Subject: Gpg 2.1.10 - Invalid error with --encrypt-to In-Reply-To: <566C58F6.6070402@enigmail.net> References: <566C58F6.6070402@enigmail.net> Message-ID: <878u4xz45k.wl-neal@walfield.org> Hi Patrick, Thanks for reporting this! On Sat, 12 Dec 2015 18:27:18 +0100, Patrick Brunschwig wrote: > Using GnuPG 2.1.10 with --encrypt-to brings wrong error messages. An > example can be found here: https://bugs.gnupg.org/gnupg/issue2186 > > Another example is this one: > > Using gpg2 --encrypt-to 0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B \ > -r someone - e > > Results in the following error message, which I consider wrong: > > gpg: key specification '0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B' is > ambiguous > gpg: (check argument of option '--encrypt-to') > gpg: '0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B' matches at least: > gpg: 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B > gpg: 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B > > Result of gpg2 --list-keys 0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B: > > pub rsa4096/DD5F693B 2015-01-17 [expires: 2025-01-14] > uid [ full ] Patrick Brunschwig > uid [ full ] Patrick Brunschwig > uid [ full ] [jpeg image of size 13251] > sub rsa4096/4E4953D8 2015-01-17 [expires: 2018-01-16] This error has been turned into a more exact warning in 6dc37c5f: gpg: Don't error out if a key occurs multiple times in the keyring. This might suggest some keyring corruption. Are you using a keyring or a keybox (try running gpg2 -k KEYID with --debug=lookup)? Are you using multiple keyrings/keyboxes? Thanks! Neal From neal at walfield.org Mon Dec 14 12:02:05 2015 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 14 Dec 2015 12:02:05 +0100 Subject: [PATCH] gpg: Print ownertrust in TOFU+PGP trust model. In-Reply-To: <1450081868-24601-1-git-send-email-dgouttegattat@incenp.org> References: <1450081868-24601-1-git-send-email-dgouttegattat@incenp.org> Message-ID: <877fkhz42a.wl-neal@walfield.org> Hi Damien, On Mon, 14 Dec 2015 09:31:08 +0100, Damien Goutte-Gattat wrote: > > * g10/keyedit.c: Print ownertrust in TOFU+PGP trust model. > -- > > The key editor currently prints out the ownertrust value assigned > to a key only when using the classic or PGP trust models; but > that value is also meaningful in the recently introduced TOFU+PGP > combined model. Thanks! This looks right, I'll apply it soon. Neal From patrick at enigmail.net Mon Dec 14 17:30:33 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 14 Dec 2015 17:30:33 +0100 Subject: Gpg 2.1.10 - Invalid error with --encrypt-to In-Reply-To: <878u4xz45k.wl-neal@walfield.org> References: <566C58F6.6070402@enigmail.net> <878u4xz45k.wl-neal@walfield.org> Message-ID: <566EEEA9.6030600@enigmail.net> On 14.12.15 12:00, Neal H. Walfield wrote: > Hi Patrick, > > Thanks for reporting this! > > On Sat, 12 Dec 2015 18:27:18 +0100, > Patrick Brunschwig wrote: >> Using GnuPG 2.1.10 with --encrypt-to brings wrong error messages. An >> example can be found here: https://bugs.gnupg.org/gnupg/issue2186 >> >> Another example is this one: >> >> Using gpg2 --encrypt-to 0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B \ >> -r someone - e >> >> Results in the following error message, which I consider wrong: >> >> gpg: key specification '0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B' is >> ambiguous >> gpg: (check argument of option '--encrypt-to') >> gpg: '0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B' matches at least: >> gpg: 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B >> gpg: 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B >> >> Result of gpg2 --list-keys 0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B: >> >> pub rsa4096/DD5F693B 2015-01-17 [expires: 2025-01-14] >> uid [ full ] Patrick Brunschwig >> uid [ full ] Patrick Brunschwig >> uid [ full ] [jpeg image of size 13251] >> sub rsa4096/4E4953D8 2015-01-17 [expires: 2018-01-16] > > This error has been turned into a more exact warning in 6dc37c5f: > > gpg: Don't error out if a key occurs multiple times in the keyring. > > This might suggest some keyring corruption. Are you using a keyring > or a keybox (try running gpg2 -k KEYID with --debug=lookup)? Are you > using multiple keyrings/keyboxes? I'm using keybox, and it looks like my key is only once on the keyring. On a side remark, using the key ID instead the fingerprint works correctly. gpg: reading options from '/Users/pbr/enigmail/.gnupg/gpg.conf' gpg: enabled debug flags: lookup gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: FPR20: '4F9F 89F5 505A C1D1 A260 631C DB11 87B9 4F9F 89F' gpg: DBG: keydb_search: searching keybox (resource 0 of 1) gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success gpg: DBG: finish_lookup: checking key DD5F693B (all)(req_usage=0) gpg: DBG: using key DD5F693B gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: FPR20: '4F9F 89F5 505A C1D1 A260 631C DB11 87B9 4F9F 89F' gpg: DBG: keydb_search: searching keybox (resource 0 of 1) gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF gpg: secmem usage: 0/32768 bytes in 0 blocks pub rsa4096/DD5F693B 2015-01-17 [expires: 2025-01-14] uid [ full ] Patrick Brunschwig uid [ full ] Patrick Brunschwig uid [ full ] [jpeg image of size 13251] sub rsa4096/4E4953D8 2015-01-17 [expires: 2018-01-16] By the way, could you add some parse-able error message for this situation (if it is correctly determined), such that tools like Enigmail can print a meaningful message to the user? -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Tue Dec 15 03:32:42 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 15 Dec 2015 11:32:42 +0900 Subject: g10: fix regression of card key generation with backup Message-ID: <566F7BCA.4000300@fsij.org> Hello, I'm looking the issue 2169. Smartcard card-edit generate fails when off-card backup of encryption key is selected: https://bugs.gnupg.org/gnupg/issue2169 If we keep the same usage of GnuPG, I think that it will be something like: * Rewrite gen_card_key_with_backup * Remove save_unprotected_key_to_card * Remove generate_raw_key * Remove do_ask_passphrase And the rewrite will be in g10/keygen.c: (1) Call do_create to ask creation of a private key on gpg-agent (2) Call agent_export_key to receive a secret key from agent (3) Save it to a file by OpenPGP format. File: sk_%08lX%08lX.gpg (4) Call agent_keytocard to ask move of a key to card (or Call card_store_subkey?) (5) Call agent_scd_learn (NULL, 1) to remove the key in agent If this is OK, I'd like to take the issue 2169 as assigned to me. -- From dkg at fifthhorseman.net Tue Dec 15 04:37:03 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 14 Dec 2015 22:37:03 -0500 Subject: Gpg 2.1.10 - Invalid error with --encrypt-to In-Reply-To: <566EEEA9.6030600@enigmail.net> References: <566C58F6.6070402@enigmail.net> <878u4xz45k.wl-neal@walfield.org> <566EEEA9.6030600@enigmail.net> Message-ID: <87wpsgbcww.fsf@alice.fifthhorseman.net> On Mon 2015-12-14 11:30:33 -0500, Patrick Brunschwig wrote: > I'm using keybox, and it looks like my key is only once on the keyring. > On a side remark, using the key ID instead the fingerprint works correctly. This sounds similar to https://bugs.gnupg.org/gnupg/issue2187 as well, actually. Is it possible that the logic for stepping through the keydb (whether keybox or keyring) has changed subtly, particularly when the specification used is a fingerprint? --dkg From neal at walfield.org Tue Dec 15 12:24:29 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 15 Dec 2015 12:24:29 +0100 Subject: Gpg 2.1.10 - Invalid error with --encrypt-to In-Reply-To: <566EEEA9.6030600@enigmail.net> References: <566C58F6.6070402@enigmail.net> <878u4xz45k.wl-neal@walfield.org> <566EEEA9.6030600@enigmail.net> Message-ID: <8737v4ymxe.wl-neal@walfield.org> Hi Patrick, On Mon, 14 Dec 2015 17:30:33 +0100, Patrick Brunschwig wrote: > > On Sat, 12 Dec 2015 18:27:18 +0100, > > Patrick Brunschwig wrote: > >> Using GnuPG 2.1.10 with --encrypt-to brings wrong error messages. An > >> example can be found here: https://bugs.gnupg.org/gnupg/issue2186 > >> > >> Another example is this one: > >> > >> Using gpg2 --encrypt-to 0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B \ > >> -r someone - e > >> > >> Results in the following error message, which I consider wrong: > >> > >> gpg: key specification '0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B' is > >> ambiguous > >> gpg: (check argument of option '--encrypt-to') > >> gpg: '0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B' matches at least: > >> gpg: 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B > >> gpg: 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B > >> > >> Result of gpg2 --list-keys 0x4F9F89F5505AC1D1A260631CDB1187B9DD5F693B: > >> > >> pub rsa4096/DD5F693B 2015-01-17 [expires: 2025-01-14] > >> uid [ full ] Patrick Brunschwig > >> uid [ full ] Patrick Brunschwig > >> uid [ full ] [jpeg image of size 13251] > >> sub rsa4096/4E4953D8 2015-01-17 [expires: 2018-01-16] > > > > This error has been turned into a more exact warning in 6dc37c5f: > > > > gpg: Don't error out if a key occurs multiple times in the keyring. > > > > This might suggest some keyring corruption. Are you using a keyring > > or a keybox (try running gpg2 -k KEYID with --debug=lookup)? Are you > > using multiple keyrings/keyboxes? > > I'm using keybox, and it looks like my key is only once on the keyring. > On a side remark, using the key ID instead the fingerprint works correctly. dkg was right: this is the same bug as described in #2187. This should be fixed in 2e4e10c. Please let me know if you are still having trouble. Thanks! :) Neal From neal at walfield.org Tue Dec 15 13:14:16 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 15 Dec 2015 13:14:16 +0100 Subject: Gpg 2.1.10 - Invalid error with --encrypt-to In-Reply-To: <87wpsgbcww.fsf@alice.fifthhorseman.net> References: <566C58F6.6070402@enigmail.net> <878u4xz45k.wl-neal@walfield.org> <566EEEA9.6030600@enigmail.net> <87wpsgbcww.fsf@alice.fifthhorseman.net> Message-ID: <871tanzz6v.wl-neal@walfield.org> On Tue, 15 Dec 2015 04:37:03 +0100, Daniel Kahn Gillmor wrote: > Is it possible that the logic for stepping through the keydb > (whether keybox or keyring) has changed subtly, particularly when the > specification used is a fingerprint? The problem is that a cache was not entirely transparent. Here are the details. Occasionally the same key is searched for repeatedly. This apparently happens primarily when looking up keys by fingerprint. We maintain a cache for this case. When we search by fingerprint, we first check if the cached entry matches the search description. If it does, we return that the resource was found. The mistake was to not also take into consideration the current file position. Thus, if we looked for ambiguous entries, we would end up in an infinite loop. I changed the cache management code to only consider the cache if the current file position is less than or equal to the cached entry's position. Thanks! :) Neal From wk at gnupg.org Tue Dec 15 14:20:56 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 Dec 2015 14:20:56 +0100 Subject: Gpg 2.1.10 - Invalid error with --encrypt-to In-Reply-To: <87wpsgbcww.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 14 Dec 2015 22:37:03 -0500") References: <566C58F6.6070402@enigmail.net> <878u4xz45k.wl-neal@walfield.org> <566EEEA9.6030600@enigmail.net> <87wpsgbcww.fsf@alice.fifthhorseman.net> Message-ID: <87vb7z6e6f.fsf@vigenere.g10code.de> On Tue, 15 Dec 2015 04:37, dkg at fifthhorseman.net said: > actually. Is it possible that the logic for stepping through the keydb > (whether keybox or keyring) has changed subtly, particularly when the > specification used is a fingerprint? It is due to the new code to check the supplied arguments for valid keys etc. It now does a key DB search very early and exhibits existing problems in a key DB as well as it introduced new bugs. For example I was not able to sign the released tarball with that versions w/o using a workaround. I nevertheless continued with the release given that this release was late anyway and I expect that more bugs will show up which we need to fix in 2.1.11. Our resources for testing are still limited and thus we need the help from our fearless users. One of the problems is the case where an offline primary key is specified for certain options. This has meanwhile been fixed in the repo and I actually wonder that we did not received more complaints. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Dec 18 02:11:11 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 18 Dec 2015 10:11:11 +0900 Subject: g10: fix regression of card key generation with backup In-Reply-To: <566F7BCA.4000300@fsij.org> References: <566F7BCA.4000300@fsij.org> Message-ID: <56735D2F.6000500@fsij.org> On 12/15/2015 11:32 AM, NIIBE Yutaka wrote: > I'm looking the issue 2169. > > Smartcard card-edit generate fails when off-card backup > of encryption key is selected: > https://bugs.gnupg.org/gnupg/issue2169 > > If we keep the same usage of GnuPG, I consider that fixing this regression makes sense (than asking users new way of handling private keys by gpg-agent). Here is the change. I intentionally don't remove unused functions, so that we can focus the change. Removal of unused functions will be done in next commit. It builds successfully. I tested lightly. It is somewhat difficult to do extensive testing because it takes time to generate keys. I'm pushing this. diff --git a/g10/keygen.c b/g10/keygen.c index a1f449e..9259ff3 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -141,9 +141,6 @@ static int write_keyblock (iobuf_t out, kbnode_t node); static gpg_error_t gen_card_key (int algo, int keyno, int is_primary, kbnode_t pub_root, u32 *timestamp, u32 expireval); -static int gen_card_key_with_backup (int algo, int keyno, int is_primary, - kbnode_t pub_root, u32 timestamp, - u32 expireval, struct para_data_s *para); static void @@ -3964,6 +3961,166 @@ start_tree(KBNODE *tree) } +/* Write the *protected* secret key to the file. */ +static gpg_error_t +card_write_key_to_backup_file (PKT_public_key *sk, const char *backup_dir) +{ + gpg_error_t err = 0; + int rc; + char name_buffer[50]; + char *fname; + IOBUF fp; + mode_t oldmask; + PACKET *pkt = NULL; + + keyid_from_pk (sk, NULL); + snprintf (name_buffer, sizeof name_buffer, "sk_%08lX%08lX.gpg", + (ulong)sk->keyid[0], (ulong)sk->keyid[1]); + + fname = make_filename (backup_dir, name_buffer, NULL); + /* Note that the umask call is not anymore needed because + iobuf_create now takes care of it. However, it does not harm + and thus we keep it. */ + oldmask = umask (077); + if (is_secured_filename (fname)) + { + fp = NULL; + gpg_err_set_errno (EPERM); + } + else + fp = iobuf_create (fname, 1); + umask (oldmask); + if (!fp) + { + err = gpg_error_from_syserror (); + log_error (_("can't create backup file '%s': %s\n"), fname, strerror (errno) ); + goto leave; + } + + pkt = xcalloc (1, sizeof *pkt); + pkt->pkttype = PKT_SECRET_KEY; + pkt->pkt.secret_key = sk; + + rc = build_packet (fp, pkt); + if (rc) + { + log_error ("build packet failed: %s\n", gpg_strerror (rc)); + iobuf_cancel (fp); + } + else + { + unsigned char array[MAX_FINGERPRINT_LEN]; + char *fprbuf, *p; + int n; + int i; + + iobuf_close (fp); + iobuf_ioctl (NULL, IOBUF_IOCTL_INVALIDATE_CACHE, 0, (char*)fname); + log_info (_("Note: backup of card key saved to '%s'\n"), fname); + + fingerprint_from_pk (sk, array, &n); + p = fprbuf = xmalloc (MAX_FINGERPRINT_LEN*2 + 1 + 1); + if (!p) + { + err = gpg_error_from_syserror (); + goto leave; + } + + for (i=0; i < n ; i++, p += 2) + sprintf (p, "%02X", array[i]); + *p++ = ' '; + *p = 0; + + write_status_text_and_buffer (STATUS_BACKUP_KEY_CREATED, fprbuf, + fname, strlen (fname), 0); + xfree (fprbuf); + } + + leave: + xfree (pkt); + xfree (fname); + return err; +} + + +/* Store key to card and make a backup file in OpenPGP format. */ +static gpg_error_t +card_store_key_with_backup (ctrl_t ctrl, PKT_public_key *sub_psk, + const char *backup_dir) +{ + PKT_public_key *sk; + gnupg_isotime_t timestamp; + gpg_error_t err; + char *hexgrip; + int rc; + struct agent_card_info_s info; + gcry_cipher_hd_t cipherhd = NULL; + char *cache_nonce = NULL; + void *kek = NULL; + size_t keklen; + + sk = copy_public_key (NULL, sub_psk); + if (!sk) + return gpg_error_from_syserror (); + + epoch2isotime (timestamp, (time_t)sk->timestamp); + err = hexkeygrip_from_pk (sk, &hexgrip); + if (err) + return err; + + memset(&info, 0, sizeof (info)); + rc = agent_scd_getattr ("SERIALNO", &info); + if (rc) + return (gpg_error_t)rc; + + rc = agent_keytocard (hexgrip, 2, 1, info.serialno, timestamp); + xfree (info.serialno); + if (rc) + { + err = (gpg_error_t)rc; + goto leave; + } + + err = agent_keywrap_key (ctrl, 1, &kek, &keklen); + if (err) + { + log_error ("error getting the KEK: %s\n", gpg_strerror (err)); + goto leave; + } + + err = gcry_cipher_open (&cipherhd, GCRY_CIPHER_AES128, GCRY_CIPHER_MODE_AESWRAP, 0); + if (!err) + err = gcry_cipher_setkey (cipherhd, kek, keklen); + if (err) + { + log_error ("error setting up an encryption context: %s\n", gpg_strerror (err)); + goto leave; + } + + err = receive_seckey_from_agent (ctrl, cipherhd, &cache_nonce, hexgrip, sk); + if (err) + { + log_error ("error getting secret key from agent: %s\n", gpg_strerror (err)); + goto leave; + } + + err = card_write_key_to_backup_file (sk, backup_dir); + if (err) + log_error ("writing card key to backup file: %s\n", gpg_strerror (err)); + else + /* Remove secret key data in agent side. */ + agent_scd_learn (NULL, 1); + + leave: + xfree (cache_nonce); + gcry_cipher_close (cipherhd); + xfree (kek); + xfree (hexgrip); + free_public_key (sk); + return err; +} + + static void do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, struct output_control_s *outctrl, int card) @@ -4095,7 +4252,7 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, if (!err && get_parameter (para, pSUBKEYTYPE)) { sub_psk = NULL; - if (!card) + if (!card || (s = get_parameter_value (para, pCARDBACKUPKEY))) { err = do_create (get_parameter_algo (para, pSUBKEYTYPE, NULL), get_parameter_uint (para, pSUBKEYLENGTH), @@ -4103,7 +4260,7 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, pub_root, timestamp, get_parameter_u32 (para, pSUBKEYEXPIRE), 1, - outctrl->keygen_flags, + s ? KEYGEN_FLAG_NO_PROTECTION : outctrl->keygen_flags, get_parameter_passphrase (para), &cache_nonce); /* Get the pointer to the generated public subkey packet. */ @@ -4115,25 +4272,15 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, if (node->pkt->pkttype == PKT_PUBLIC_SUBKEY) sub_psk = node->pkt->pkt.public_key; assert (sub_psk); + + if (s) + err = card_store_key_with_backup (ctrl, sub_psk, opt.homedir); } } else { - if ((s = get_parameter_value (para, pCARDBACKUPKEY))) - { - /* A backup of the encryption key has been requested. - Generate the key in software and import it then to - the card. Write a backup file. */ - err = gen_card_key_with_backup - (PUBKEY_ALGO_RSA, 2, 0, pub_root, timestamp, - get_parameter_u32 (para, pKEYEXPIRE), para); - } - else - { - err = gen_card_key (PUBKEY_ALGO_RSA, 2, 0, pub_root, - ×tamp, - get_parameter_u32 (para, pKEYEXPIRE)); - } + err = gen_card_key (PUBKEY_ALGO_RSA, 2, 0, pub_root, ×tamp, + get_parameter_u32 (para, pKEYEXPIRE)); } if (!err) diff --git a/g10/main.h b/g10/main.h index e4c6e8f..60bbd24 100644 --- a/g10/main.h +++ b/g10/main.h @@ -363,6 +363,10 @@ gpg_error_t export_pubkey_buffer (ctrl_t ctrl, const char *keyspec, kbnode_t *r_keyblock, void **r_data, size_t *r_datalen); +gpg_error_t receive_seckey_from_agent (ctrl_t ctrl, gcry_cipher_hd_t cipherhd, + char **cache_nonce_addr, const char *hexgrip, + PKT_public_key *pk); + /*-- dearmor.c --*/ int dearmor_file( const char *fname ); int enarmor_file( const char *fname ); -- From wk at gnupg.org Sun Dec 20 13:16:04 2015 From: wk at gnupg.org (Werner Koch) Date: Sun, 20 Dec 2015 13:16:04 +0100 Subject: [Announce] GnuPG 1.4.20 released Message-ID: <878u4puxh7.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG classic release: Version 1.4.20. This release finally rejects all MD5 based signatures; see below for details. 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 platforms or if there is a need to handle PGP-2 messages. 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.20 ========================== * Reject signatures made using the MD5 hash algorithm unless the new option --allow-weak-digest-algos or --pgp2 are given. * New option --weak-digest to specify hash algorithms which should be considered weak. * Changed default cipher for symmetric-only encryption to AES-128. * Fix for DoS when importing certain garbled secret keys. * Improved error reporting for secret subkey w/o corresponding public subkey. * Improved error reporting in decryption due to wrong algorithm. * Fix cluttering of stdout with trustdb info in double verbose mode. * Pass a DBUS envvar to gpg-agent for use by gnome-keyring. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 1.4.20 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.20.tar.bz2 (3606k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.20.tar.bz2.sig This is the GnuPG 1.4.20 source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.20.tar.gz (5036k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.20.tar.gz.sig This is the same GnuPG 1.4.20 source code compressed using GZIP and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.20.exe (2359k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.20.exe.sig This is GnuPG 1.4.20 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 . To download the files via https use these URLs: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-1.4.20.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-1.4.20.tar.bz2.sig https://gnupg.org/ftp/gcrypt/gnupg/gnupg-1.4.20.tar.gz https://gnupg.org/ftp/gcrypt/gnupg/gnupg-1.4.20.tar.gz.sig https://gnupg.org/ftp/gcrypt/binary/gnupg-w32cli-1.4.20.exe https://gnupg.org/ftp/gcrypt/binary/gnupg-w32cli-1.4.20.exe.sig 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.20.tar.bz2 you would use this command: gpg --verify gnupg-1.4.20.tar.bz2.sig gnupg-1.4.20.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.20.tar.bz2, you would run the command like this: sha1sum gnupg-1.4.20.tar.bz2 and check that the output matches the first line from the following list: cbc9d960e3d8488c32675019a79fbfbf8680387e gnupg-1.4.20.tar.bz2 359e464bcabbe370696e3dba45a1d63968c06ab3 gnupg-1.4.20.tar.gz 8f0c4760c9f38102f64a156744ec8a428298b92d gnupg-w32cli-1.4.20.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 need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Maintenance and development of GnuPG is mostly financed by donations. As of today we employ 3 full-time developers, one part-timer, and one contractor. They all work on GnuPG and closely related software like Enigmail. Please see https://gnupg.org/donate/ on how you can help. 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, answering questions on the mailing lists, and donating money. For the GnuPG hackers, Werner p.s. This is an 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 spora at email.it Tue Dec 22 21:21:36 2015 From: spora at email.it (Spet) Date: Tue, 22 Dec 2015 21:21:36 +0100 Subject: GnuPG 1.4.20 Win x64 Message-ID: Do it is difficult to have a win x64 binary for GnuPG 1.4.20? From patrick at enigmail.net Wed Dec 23 18:29:54 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 23 Dec 2015 18:29:54 +0100 Subject: gpg 2.1: no error message if gpg-agent or pinentry fail In-Reply-To: <552155DF.8030805@enigmail.net> References: <54DA437F.2020509@enigmail.net> <87bnjzmtan.fsf@vigenere.g10code.de> <552155DF.8030805@enigmail.net> Message-ID: <567ADA12.1000606@enigmail.net> On 05.04.15 17:33, Patrick Brunschwig wrote: > On 11.03.15 16:45, Werner Koch wrote: >> Trying to decrypt something gives these messages: >> >> [...] gpg: public key decryption failed: Tribute to D. A. [GNUPG:] >> ERROR pkdecrypt_failed 67108906 [GNUPG:] BEGIN_DECRYPTION [GNUPG:] >> DECRYPTION_FAILED gpg: decryption failed: No secret key [GNUPG:] >> END_DECRYPTION >> >> Right you can't see the source of the error. Thus we need to look >> at the ERROR status line: >> >> $ gpg-error 67108906 67108906 = (4, 42) = (GPG_ERR_SOURCE_GPGAGENT, >> GPG_ERR_TRIBUTE_TO_D_A) = (GPG Agent, Tribute to D. A.) I have to bring up this topic again for gpg 2.1.10. If I use "gpg2 --status-fd 1 --sign", and there is a pinentry error, there is the following error message: [GNUPG:] FAILURE sign 67108949 But for "gpg2 --status-fd 1 --decrypt" there is no such message anymore, and no "ERROR" message either. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Dec 23 20:47:07 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Dec 2015 20:47:07 +0100 Subject: gpg 2.1: no error message if gpg-agent or pinentry fail In-Reply-To: <567ADA12.1000606@enigmail.net> (Patrick Brunschwig's message of "Wed, 23 Dec 2015 18:29:54 +0100") References: <54DA437F.2020509@enigmail.net> <87bnjzmtan.fsf@vigenere.g10code.de> <552155DF.8030805@enigmail.net> <567ADA12.1000606@enigmail.net> Message-ID: <87io3pq75w.fsf@vigenere.g10code.de> On Wed, 23 Dec 2015 18:29, patrick at enigmail.net said: > I have to bring up this topic again for gpg 2.1.10. Is there an entry in the bug tracker? > But for "gpg2 --status-fd 1 --decrypt" there is no such message anymore, BTW: Please take care when using stdout for the status channel unless you use --output FILE. The plaintext can be used to mess up your status processing. Never mix the status output with the data output. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Dec 24 04:31:36 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 24 Dec 2015 12:31:36 +0900 Subject: smartcard: generate under --card-edit with off-card backup and bkuptocard/checkbkupkey under --key-edit Message-ID: <567B6718.3090003@fsij.org> Hello, I'm working the issue 2169: https://bugs.gnupg.org/gnupg/issue2169 Since I only do generating keys on card for testing purpose, I have things to confirm for this use case. # For myself, my practice is generating keys on host and doing # keytocard. While the support of checkbkupkey was removed, the two regressions in 2.1 were fixed: * generating keys on card with off-card backup * bkuptocard The checkbkupkey will be implemented again, if it's useful. AIUC, this command is for a user who wants to make sure if the backup file can be used correctly with a passphrase remembered. It would be just simple to have another subcommand to recover a private subkey on host from the backup (and a user will do "keytocard", if needed). It seems that the scenario of bkuptocard is something like: (1) The smartcard was lost/broken. (2) But a user wants to read encrypted messages. (3) There is the public key (primary, subkeys) on host as well as the backup file for private key. (4) With new smartcard, a user recovers encryption key using the backup file for private key. Is this correct? Backup file is created on GnuPG's homedir. So, I think that the commit which assumes homedir for backup file makes sense: ee433d2b00c93b5a4e4ed54b9fb5806361df1b71 If this is useful, I'd like to backport this to 2.0. Currently, the private key stub is precondition for the subcommand bkuptocard: { "bkuptocard", cmdBKUPTOCARD, KEYEDIT_NEED_SK | KEYEDIT_ONLY_SK, N_("move a backup key to a smartcard")}, But I think that it is OK not to have the private key stub files on host. Shall I remove KEYEDIT_NEED_SK flag from "cmds"? -- From patrick at enigmail.net Thu Dec 24 09:08:16 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 24 Dec 2015 09:08:16 +0100 Subject: gpg 2.1: no error message if gpg-agent or pinentry fail In-Reply-To: <87io3pq75w.fsf@vigenere.g10code.de> References: <54DA437F.2020509@enigmail.net> <87bnjzmtan.fsf@vigenere.g10code.de> <552155DF.8030805@enigmail.net> <567ADA12.1000606@enigmail.net> <87io3pq75w.fsf@vigenere.g10code.de> Message-ID: <567BA7F0.2080002@enigmail.net> On 23.12.15 20:47, Werner Koch wrote: > On Wed, 23 Dec 2015 18:29, patrick at enigmail.net said: > >> I have to bring up this topic again for gpg 2.1.10. > > Is there an entry in the bug tracker? No, and I think I have to correct myself. I re-tested with libgpg-error 1.21 and cannot reproduce the bug anymore. >> But for "gpg2 --status-fd 1 --decrypt" there is no such message anymore, > > BTW: Please take care when using stdout for the status channel unless > you use --output FILE. The plaintext can be used to mess up your status > processing. Never mix the status output with the data output. Sure, I would normally use stdout for status-fd. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: