From gnupg-users at spodhuis.org Sun Dec 3 02:20:02 2017 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Sat, 2 Dec 2017 20:20:02 -0500 Subject: Performance regression, 2.2.3/recent? Message-ID: <20171203012002.GA32623@breadbox.private.spodhuis.org> Anyone else seeing major slowdowns with keyring dumping in recent GnuPG on Linux? I have a dump-state script used for monthly backups where after an hour, I gave up. The step is just: gpg --with-colons --with-fingerprint --with-subkey-fingerprint --with-secret --list-keys but pubring.kbx is 236 MiB. Large, but GnuPG has handled it until now. If I copy to a clean GNUPGHOME on macOS (more CPU etc too) then things complete in about 27 seconds. No variation of the flags has a significant impact. I just killed another attempt on the Ubuntu / Atom-CPU box, which was running under `strace -o ...` which would slow things down a bit, but after 16+ minutes (16:41.54) the strace output was 535MiB. If I tailed the strace, I saw lots of repetitive output, reading the same chunks of data from the kbx. After killing it: $ grep '^open(' strace.foo | sort | uniq -c [...] 3382 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 10 1 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 3 1 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 4 1 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 7 Packages all built by me, under clean VMs, configure flags available if desired. Aside from install-location, it boils down to gmp gets --enable-fat, some gnutls bits, and gnupg22 gets: "--disable-nls", "--disable-ldap", "--enable-noexecstack", "--enable-key-cache=16384", "--enable-wks-tools", If I look at the successful dump on the beefier machine, then: % grep -c '^pub:' foo.5 5338 % grep -c '^uid:' foo.5 16927 I rebuilt GnuPG with --enable-key-cache=32768 and it hasn't helped. The latest attempt is 12 minutes in and still running, with the output file being 1032192 bytes large, it should be 3648012 when done. That's a long time, just to dump information. Package versions: ii optgnupg-gmp 6.1.2-pt2 ii optgnupg-gnupg 2.2.3-pt2 ii optgnupg-gnutls 3.5.16-pt2 ii optgnupg-libassuan 2.4.5-pt1 ii optgnupg-libgcrypt 1.8.1-pt1 ii optgnupg-libgpg-error 1.27-pt1 ii optgnupg-libksba 1.3.5-pt1 ii optgnupg-nettle 3.4-pt1 ii optgnupg-npth 1.5-pt1 ii optgnupg-pinentry 1.0.0-pt3 Thanks, -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From wk at gnupg.org Sun Dec 3 12:19:17 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 03 Dec 2017 12:19:17 +0100 Subject: Performance regression, 2.2.3/recent? In-Reply-To: <20171203012002.GA32623@breadbox.private.spodhuis.org> (Phil Pennock's message of "Sat, 2 Dec 2017 20:20:02 -0500") References: <20171203012002.GA32623@breadbox.private.spodhuis.org> Message-ID: <878tek6oui.fsf@wheatstone.g10code.de> On Sun, 3 Dec 2017 02:20, gnupg-users at spodhuis.org said: > Anyone else seeing major slowdowns with keyring dumping in recent GnuPG > on Linux? By recent do you mean 2.2.3 or a Git version (2.2 branch or master)? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg-users at spodhuis.org Mon Dec 4 01:31:30 2017 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Sun, 3 Dec 2017 19:31:30 -0500 Subject: Performance regression, 2.2.3/recent? In-Reply-To: <878tek6oui.fsf@wheatstone.g10code.de> References: <20171203012002.GA32623@breadbox.private.spodhuis.org> <878tek6oui.fsf@wheatstone.g10code.de> Message-ID: <20171204003130.GA54874@tower.spodhuis.org> On 2017-12-03 at 12:19 +0100, Werner Koch wrote: > On Sun, 3 Dec 2017 02:20, gnupg-users at spodhuis.org said: > > Anyone else seeing major slowdowns with keyring dumping in recent GnuPG > > on Linux? > > By recent do you mean 2.2.3 or a Git version (2.2 branch or master)? 2.2.3. The dump on Linux finally finished; zsh reports: 1591.65s user 2111.87s system 99% cpu 1:01:45.97 total Just over an hour, for something which was already slow at 27 seconds on macOS. System was never short on RAM. It is a smallish Atom computer, 2GiB RAM, two-core Atom(TM) CPU D2500. If I reinstall an older version: apt install optgnupg-gnupg=2.1.23-pdp1 time gpg --with-colons --with-fingerprint --with-subkey-fingerprint --with-secret --list-keys >foo3 301.22s user 257.94s system 99% cpu 9:22.54 total GnuPG 2.1.23: 9mins 22s GnuPG 2.2.3 : 61mins 45s At this point, I really have no idea what is a good path to investigate where this time is being spent. It's a 236M .kbx which I'm willing to share. From wk at gnupg.org Mon Dec 4 08:33:29 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Dec 2017 08:33:29 +0100 Subject: Performance regression, 2.2.3/recent? In-Reply-To: <20171204003130.GA54874@tower.spodhuis.org> (Phil Pennock's message of "Sun, 3 Dec 2017 19:31:30 -0500") References: <20171203012002.GA32623@breadbox.private.spodhuis.org> <878tek6oui.fsf@wheatstone.g10code.de> <20171204003130.GA54874@tower.spodhuis.org> Message-ID: <87indnueuu.fsf@wheatstone.g10code.de> On Mon, 4 Dec 2017 01:31, gnupg-users at spodhuis.org said: > 2.2.3. The major change I see are the fixes for bug 3446 which involves a new locking strategy during import. However, that should not affect a key listing. > At this point, I really have no idea what is a good path to investigate > where this time is being spent. It's a 236M .kbx which I'm willing to Thanks for the offer. Let's see whether we can replicate it with a smaller keyring. Tacked in https://dev.gnupg.org/T3573 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gniibe at fsij.org Mon Dec 4 10:20:21 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 04 Dec 2017 18:20:21 +0900 Subject: Performance regression, 2.2.3/recent? In-Reply-To: <20171203012002.GA32623@breadbox.private.spodhuis.org> References: <20171203012002.GA32623@breadbox.private.spodhuis.org> Message-ID: <871skayhm2.fsf@fsij.org> Hello, Phil Pennock wrote: > gpg --with-colons --with-fingerprint --with-subkey-fingerprint --with-secret --list-keys [...] > $ grep '^open(' strace.foo | sort | uniq -c > [...] > 3382 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 10 > 1 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 3 > 1 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 4 > 1 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 7 It seems that pubring.kbx is accessed recursively (something by depth 3, by fd: 4, 7 and 10 (fd 3 is to check the file type, I guess)). Could you please try with --no-expensive-trust-checks option, if it changes the behavior? -- From gnupg-users at spodhuis.org Wed Dec 6 01:21:32 2017 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Tue, 5 Dec 2017 19:21:32 -0500 Subject: Performance regression, 2.2.3/recent? In-Reply-To: <871skayhm2.fsf@fsij.org> References: <20171203012002.GA32623@breadbox.private.spodhuis.org> <871skayhm2.fsf@fsij.org> Message-ID: <20171206002132.GA46607@tower.spodhuis.org> On 2017-12-04 at 18:20 +0900, NIIBE Yutaka wrote: > It seems that pubring.kbx is accessed recursively (something by depth 3, > by fd: 4, 7 and 10 (fd 3 is to check the file type, I guess)). > > Could you please try with --no-expensive-trust-checks option, if it > changes the behavior? Yes: changes output and changes runtime. time gpg --no-expensive-trust-checks --with-colons --with-fingerprint --with-subkey-fingerprint --with-secret --list-keys > foo4 171.50s user 1.53s system 98% cpu 2:55.07 total That's much nicer run-time, but: -rw-r----- 1 pdp pdp 3648007 Dec 3 19:24 foo3 -rw-r----- 1 pdp pdp 3618838 Dec 5 19:15 foo4 The script is a state dump for backups and analysis, the second column being missing loses the evaluated trust. However, if I already have a `gpg --export-ownertrust` then I _think_ I have everything needed, so can safely lose this, right? Thanks, -Phil From gcrypt4 at gmail.com Thu Dec 7 09:53:48 2017 From: gcrypt4 at gmail.com (gnu cry) Date: Thu, 7 Dec 2017 12:23:48 +0330 Subject: Elliptic curve point multiplication with libgcrypt Message-ID: Hi gpg hackers! I want to implement an elliptic curve point multiplication (Q=dG) operation with libgcrypt. I attach my code but my program doesn't work and it has many errors. I comment the workflow of my program in the attached code. my question is how do you implement Q=dG in C with libgcrypt? any idea about my mistakes and how should I fix them? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ec.c Type: text/x-csrc Size: 1518 bytes Desc: not available URL: From rsvx at riseup.net Thu Dec 7 16:08:15 2017 From: rsvx at riseup.net (rsvx) Date: Thu, 7 Dec 2017 16:08:15 +0100 Subject: Installation of 2.2 Message-ID: <8feee417-7587-4b66-0b83-55957def0f7b@riseup.net> Hi, I'd like to upgrade to version 2.2.3? Will it be sufficient do download just the tarball on the downloadpage and build that? Afterwards I can delete the previous versions? If I do that, will the conf. file be deleted? Thank you. Jurgen. From wk at gnupg.org Thu Dec 7 20:03:46 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Dec 2017 20:03:46 +0100 Subject: Elliptic curve point multiplication with libgcrypt In-Reply-To: (gnu cry's message of "Thu, 7 Dec 2017 12:23:48 +0330") References: Message-ID: <87vahimkbx.fsf@wheatstone.g10code.de> On Thu, 7 Dec 2017 09:53, gcrypt4 at gmail.com said: > my question is how do you implement Q=dG in C with libgcrypt? any idea > about my mistakes and how should I fix them? You may want to look at libgcrypt/tests/t-mpi-point.c which does many operations on points. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gcrypt4 at gmail.com Thu Dec 7 14:16:41 2017 From: gcrypt4 at gmail.com (gnu cry) Date: Thu, 7 Dec 2017 16:46:41 +0330 Subject: Fwd: Elliptic curve point multiplication with libgcrypt In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: gnu cry Date: Thu, Dec 7, 2017 at 12:23 PM Subject: Elliptic curve point multiplication with libgcrypt To: gnupg-users at gnupg.org Hi gpg hackers! I want to implement an elliptic curve point multiplication (Q=dG) operation with libgcrypt. I attach my code but my program doesn't work and it has many errors. I comment the workflow of my program in the attached code. my question is how do you implement Q=dG in C with libgcrypt? any idea about my mistakes and how should I fix them? Thanks //ec.c #include #include #include #include //select and insert key and curve parameters char *key521 = "(key-data\n" " (public-key\n" " (ecc\n" " (curve NIST P-521)\n" " (q #00F2271E305679EBF9D7673FBF75EEA22E90D100A9E0B5DE30C500411E91710D05826F17F2C33A9527CC6799553C626C015ED666F63A4D5CEB27CDBE61F34DB0AF#)\n" " )\n" " )\n" " (private-key\n" " (ecc\n" " (curve NIST P-521)\n" " (d #00BC9D8FD5D0AC1C91C04A1E0A5B6A89229924AAD20E23C5F5E3FE702C3C4633E325D2084DC0CE2005A88FF0512E0CACC271DF3279865DC2C33FCF573F7788278E#)\n" " )\n" " )\n" "\n )"; // workflow for calculating of Q=dG int main() { gcry_check_version(NULL); gcry_mpi_point_t Q,G; //define and hold two elliptic curve point gcry_mpi_point_release(G); gcry_mpi_t d; //define the scalar (d) gcry_sexp_t dsex; //define an S-expression variable gcry_sexp_sscan(&dsex, NULL, key521, strlen(key521)); //set dsex = d in key521 data structure gcry_sexp_release(dsex); d= gcry_sexp_nth_mpi(dsex, 1, GCRYMPI_FMT_USG); // convert from S-exp to MPI format char curvename= "NIST P-521"; //define curve name gcry_ctx_t context; //define a context (ctx) gcry_mpi_ec_new(context, dsex, curvename); //set context gcry_ctx_release(context); gcry_mpi_ec_mul(Q,d,G,context); // calculate Q=dG } -------------- next part -------------- An HTML attachment was scrubbed... URL: From Healer64 at protonmail.com Fri Dec 8 19:37:28 2017 From: Healer64 at protonmail.com (Healer64) Date: Fri, 08 Dec 2017 13:37:28 -0500 Subject: Downloading the same key results in different files Message-ID: Hi, as keyserver spoofing and poisoning has been a concern, I decided to test it by downloading the same key from the same keyserver at different times and from different locations. When I exported the resulting keys using ascii the files were significantly different, 3k difference in file sizes. Is this expected? All the keys have the same fingerprint and the same subkeys. All the keys successfully verify a good signature from the source address. To account for differences in software version I imported each into a single machine, rexported, then deleted the imported key and followed the same process with the next key, so each key was exported using the same software version. They are still different from each other and identical with the original. Is there any explanation for this? Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlikonen at iki.fi Sat Dec 9 14:17:02 2017 From: tlikonen at iki.fi (Teemu Likonen) Date: Sat, 09 Dec 2017 15:17:02 +0200 Subject: TOFU's encryption counter is not updated (a bug?) Message-ID: <87efo4m46p.fsf@iki.fi> I have sent several encrypted emails to a friend and I'm using Gnus as my email program. I'm using "trust-model tofu" but it seems that TOFU's encryption counter is not incremented for the recipient's key. I queried the TOFU info with a command like this: gpg --list-keys --with-tofu-info --with-colons KEY | \ awk -F: '$1 == "tfs" {print $5}' To me this is looking very much like bug. I'm using GnuPG 2.1.18-8~deb9u1 (Debian 9). -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From gnupg.lists at whitewinterwolf.com Sun Dec 10 15:40:51 2017 From: gnupg.lists at whitewinterwolf.com (WhiteWinterWolf) Date: Sun, 10 Dec 2017 15:40:51 +0100 Subject: How to use '--verify-options pka-lookup'? Message-ID: <3d544de6-923c-7cb3-0e68-52fcbb284dea@whitewinterwolf.com> Hi, Can anyone tell me or point me to some example on how to use the following option: --verify-options pka-lookup As per my understanding, given a pubkey in the keyring and a signed file, this parameter should tell GPG to contact the DNS server handling the domain from the pubkey email address and ensure that the key fingerprint is indeed the expected one. I find this option interesting since, as long as PKA is not used to fetch the key too, it opens a very convenient way to check a key from two independent sources and make it far harder for an attacker to replace a key (as long as SHA-1 fingerprints can be trusted). However, I can try to use this option any way I can think of, it just doesn't seem to have any noticeable effect. Here is an example on how I tried to use this option: gpg --verify-options pka-lookup --verify somefile.sig somefile.txt PKA lookup step seems to be simply ignored and skipped. Thank you by advance! Simon. -- WhiteWinterWolf https://www.whitewinterwolf.com -- WhiteWinterWolf https://www.whitewinterwolf.com From gcrypt4 at gmail.com Fri Dec 8 12:55:10 2017 From: gcrypt4 at gmail.com (gnu cry) Date: Fri, 8 Dec 2017 15:25:10 +0330 Subject: Elliptic curve point multiplication with libgcrypt In-Reply-To: References: Message-ID: Salam Werner, Thank you for your answer On Thu, Dec 7, 2017 at 4:46 PM, gnu cry wrote: > > ---------- Forwarded message ---------- > From: gnu cry > Date: Thu, Dec 7, 2017 at 12:23 PM > Subject: Elliptic curve point multiplication with libgcrypt > To: gnupg-users at gnupg.org > > > Hi gpg hackers! > > I want to implement an elliptic curve point multiplication (Q=dG) > operation with libgcrypt. I attach my code but my program doesn't work and > it has many errors. I comment the workflow of my program in the attached > code. > my question is how do you implement Q=dG in C with libgcrypt? any idea > about my mistakes and how should I fix them? > > Thanks > > > > > //ec.c > > #include > #include > #include > #include > > //select and insert key and curve parameters > char *key521 = > "(key-data\n" > " (public-key\n" > " (ecc\n" > " (curve NIST P-521)\n" > " (q #00F2271E305679EBF9D7673FBF75EEA22E90D100A9E0B5DE30C500411E91710D05826F17F2C33A9527CC6799553C626C015ED666F63A4D5CEB27CDBE61F34DB0AF#)\n" > " )\n" > " )\n" > " (private-key\n" > " (ecc\n" > " (curve NIST P-521)\n" > " (d #00BC9D8FD5D0AC1C91C04A1E0A5B6A89229924AAD20E23C5F5E3FE702C3C4633E325D2084DC0CE2005A88FF0512E0CACC271DF3279865DC2C33FCF573F7788278E#)\n" > " )\n" > " )\n" > "\n )"; > > > // workflow for calculating of Q=dG > int main() { > > gcry_check_version(NULL); > gcry_mpi_point_t Q,G; //define and hold two elliptic curve point > gcry_mpi_point_release(G); > gcry_mpi_t d; //define the scalar (d) > > gcry_sexp_t dsex; //define an S-expression variable > gcry_sexp_sscan(&dsex, NULL, key521, strlen(key521)); //set dsex = d in key521 data structure > gcry_sexp_release(dsex); > d= gcry_sexp_nth_mpi(dsex, 1, GCRYMPI_FMT_USG); // convert from S-exp to MPI format > > char curvename= "NIST P-521"; //define curve name > gcry_ctx_t context; //define a context (ctx) > gcry_mpi_ec_new(context, dsex, curvename); //set context > gcry_ctx_release(context); > > gcry_mpi_ec_mul(Q,d,G,context); // calculate Q=dG > > } > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gcrypt4 at gmail.com Fri Dec 8 16:28:22 2017 From: gcrypt4 at gmail.com (gnu cry) Date: Fri, 8 Dec 2017 18:58:22 +0330 Subject: pgpdump alternative for gpg2 Message-ID: Hi gpg hackers, I want to see gpg2 key parameters packets. pgpdump v0.32 doesn't support gpg2 (especially elliptic curve cryptography packets) and "gpg2 --list-packets" doesn't show key parameters. is there any way to see key parameters (d, q and curve) of ecc in gpg2 imported secret subkeys? best -------------- next part -------------- An HTML attachment was scrubbed... URL: From angel at pgp.16bits.net Sun Dec 10 17:02:58 2017 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 10 Dec 2017 17:02:58 +0100 Subject: Downloading the same key results in different files In-Reply-To: References: Message-ID: <1512921778.2397.7.camel@16bits.net> On 2017-12-08 at 13:37 -0500, Healer64 via Gnupg-users wrote: > Hi, as keyserver spoofing and poisoning has been a concern, I decided > to test it by downloading the same key from the same keyserver at > different times and from different locations. > > > > When I exported the resulting keys using ascii the files were > significantly different, 3k difference in file sizes. Is this > expected? > > > > All the keys have the same fingerprint and the same subkeys. All the > keys successfully verify a good signature from the source address. > > > > To account for differences in software version I imported each into a > single machine, rexported, then deleted the imported key and followed > the same process with the next key, so each key was exported using the > same software version. They are still different from each other and > identical with the original. Is there any explanation for this? Did they have the same signers? Maybe in one case the key had extra signatures. That is the most common reason for differences on a single key that I have seen. Although if for instance the bigger one had an extra photo, that would explain the difference, too. Also note that although you can request it from "the same keyserver" (as in the same hostname), you may actually be accessing a different server. A host like pool.sks-keyservers.net may point to dozens of different servers. And even if there is apparently a single one, there may be several host balanced behind (although in that case it would be more strange that their dbs differed significantly). From peter at digitalbrains.com Sun Dec 10 19:36:28 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 10 Dec 2017 19:36:28 +0100 Subject: pgpdump alternative for gpg2 In-Reply-To: References: Message-ID: <0c65ea88-7b11-f40e-c9cd-8ae97033d885@digitalbrains.com> On 08/12/17 16:28, gnu cry wrote: > "gpg2 > --list-packets" doesn't show key parameters. Have you tried "-v --list-packets"? I'm testing with public keys, not private keys, but it seems to show the full data in hex. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sun Dec 10 19:53:17 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Dec 2017 19:53:17 +0100 Subject: pgpdump alternative for gpg2 In-Reply-To: (gnu cry's message of "Fri, 8 Dec 2017 18:58:22 +0330") References: Message-ID: <87lgiajtya.fsf@wheatstone.g10code.de> On Fri, 8 Dec 2017 16:28, gcrypt4 at gmail.com said: > I want to see gpg2 key parameters packets. pgpdump v0.32 doesn't support > gpg2 (especially elliptic curve cryptography packets) and "gpg2 > --list-packets" doesn't show key parameters. is there any way to see key > parameters (d, q and curve) of ecc in gpg2 imported secret subkeys? gpg --with-key-data ---with-colons -K shows the public data in "pkd" records. You can't easily see the secret data (d); for that you would need to add debug options to gpg-agent (--debug help). If your secret key is not protected, the ~/private-keys-v1.d/KEYGRIP.key file will reveal all parameters. /usr/local/libexec/gpg-protect-tool KEYFILE can be used to convert the canonical encoded s-expression into the advanced format which can be read in any editor. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From marcin.krzyzanowski at gmail.com Mon Dec 11 02:13:39 2017 From: marcin.krzyzanowski at gmail.com (Marcin Krzyzanowski) Date: Mon, 11 Dec 2017 02:13:39 +0100 Subject: onepass_sig without corresponding signagure packet Message-ID: <2d3623ac-3df8-4a46-9c13-9a5c9d88e97d@Canary> Hi, The Enigmail is able to produce encrypted and signed message that is of this format: # off=0 ctb=85 tag=1 hlen=3 plen=268 :pubkey enc packet: version 3, algo 1, keyid 99DC3902ACFB3F2D data: [2048 bits] # off=271 ctb=85 tag=1 hlen=3 plen=268 :pubkey enc packet: version 3, algo 1, keyid A93E9DF0C89796BC data: [2046 bits] # off=542 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb :encrypted data packet: length: unknown mdc_method: 2 # off=563 ctb=a3 tag=8 hlen=1 plen=0 indeterminate :compressed packet: algo=2 # off=565 ctb=90 tag=4 hlen=2 plen=13 :onepass_sig packet: keyid 4CAB945543809C83 version 3, sigclass 0x01, digest 8, pubkey 1, last=1 # off=580 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb :literal data packet: mode t (74), created 1512950823, name="", raw data: unknown length I?m not able to create this format by hand. What I?m curious about is missing signature packet after the literal packet. Whenever I try to encrypt and sign, there is onepass_sig and and signature packet at the end (as expected) gpg validate this message as valid. gpg ?decrypt gpg: Signature made Mon Dec 11 01:07:03 2017 CET gpg: using RSA key ADFB5525AC0262620BBED93C4CAB945543809C83 gpg: Good signature from "BobEnzevalos " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: ADFB 5525 AC02 6262 0BBE D93C 4CAB 9455 4380 9C83 my question is? where is this signature from? why this is a valid message? Thank you in advance. -- Regards. Marcin -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Dec 11 11:44:22 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Dec 2017 11:44:22 +0100 Subject: onepass_sig without corresponding signagure packet In-Reply-To: <2d3623ac-3df8-4a46-9c13-9a5c9d88e97d@Canary> (Marcin Krzyzanowski's message of "Mon, 11 Dec 2017 02:13:39 +0100") References: <2d3623ac-3df8-4a46-9c13-9a5c9d88e97d@Canary> Message-ID: <87o9n5ilx5.fsf@wheatstone.g10code.de> On Mon, 11 Dec 2017 02:13, marcin.krzyzanowski at gmail.com said: > my question is? where is this signature from? why this is a valid message? --list-packets sometimes swallows the past packet and thus you don't see it. Long standing bug. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gcrypt4 at gmail.com Sun Dec 10 18:07:31 2017 From: gcrypt4 at gmail.com (gnu cry) Date: Sun, 10 Dec 2017 20:37:31 +0330 Subject: pgpdump alternative for gpg2 In-Reply-To: References: Message-ID: I find my answer, my gpg version was my problem, more information in the below link: https://crypto.stackexchange.com/questions/53821/pgpdump-alternative-for-gnupg-2-x On Fri, Dec 8, 2017 at 6:58 PM, gnu cry wrote: > Hi gpg hackers, > > > I want to see gpg2 key parameters packets. pgpdump v0.32 doesn't support > gpg2 (especially elliptic curve cryptography packets) and "gpg2 > --list-packets" doesn't show key parameters. is there any way to see key > parameters (d, q and curve) of ecc in gpg2 imported secret subkeys? > > > best > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Healer64 at protonmail.com Tue Dec 12 02:44:10 2017 From: Healer64 at protonmail.com (Healer64) Date: Mon, 11 Dec 2017 20:44:10 -0500 Subject: Downloading the same key results in different files In-Reply-To: <1512921778.2397.7.camel@16bits.net> References: <1512921778.2397.7.camel@16bits.net> Message-ID: Good call. I forgot about the signing keys and sure enough there were a few differences. Thanks. >> Did they have the same signers? >> >> Maybe in one case the key had extra signatures. That is the most common >> reason for differences on a single key that I have seen. >> Although if for instance the bigger one had an extra photo, that would >> explain the difference, too. >> >> Also note that although you can request it from "the same keyserver" (as >> in the same hostname), you may actually be accessing a different server. >> A host like pool.sks-keyservers.net may point to dozens of different >> servers. And even if there is apparently a single one, there may be >> several host balanced behind (although in that case it would be more >> strange that their dbs differed significantly). > > --------------------------------------------------------------- > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuliknol at gmail.com Tue Dec 12 02:47:14 2017 From: nuliknol at gmail.com (Absolute Zero) Date: Mon, 11 Dec 2017 19:47:14 -0600 Subject: Compiling libgcrypt with ECC Message-ID: Hi all, I want to compile a lightweight version of libgcrypt with Public Key encryption using Elliptic curve cipher, but what do I feed on the ./configure command line for " --enable-ciphers" parameter? Is there a list of ciphers? Can't find this info in README, INSTALL or the html docs. If Elliptic curve public key cryptography is not yet implemented what cipher would you recommend me to use so the compiled library would be of the smallest possible size? Thanks in advance Nulik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Dec 12 08:43:08 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Dec 2017 08:43:08 +0100 Subject: Compiling libgcrypt with ECC In-Reply-To: (Absolute Zero's message of "Mon, 11 Dec 2017 19:47:14 -0600") References: Message-ID: <87shcgfl2r.fsf@wheatstone.g10code.de> On Tue, 12 Dec 2017 02:47, nuliknol at gmail.com said: > I want to compile a lightweight version of libgcrypt with Public Key > encryption using Elliptic curve cipher, but what do I feed on the > ./configure command line for " --enable-ciphers" parameter? Is there a list Nothing. ECC support is build by default. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From szczepan at nitrokey.com Tue Dec 12 11:41:29 2017 From: szczepan at nitrokey.com (Szczepan Zalega | Nitrokey) Date: Tue, 12 Dec 2017 11:41:29 +0100 Subject: Complete Ubuntu compile of GnuPG In-Reply-To: References: <135b2a53-5000-8f86-8611-c17e107986b0@gmail.com> <873756hdpl.fsf@wheatstone.g10code.de> <507d3f1c-56f1-26b9-27c2-169a1120acca@gmail.com> Message-ID: <38c88923-d6ab-43e7-7309-e2f2fe586c4e@nitrokey.com> On 11/25/2017 01:40 PM, murphy wrote: > Yes, the permissions and gpg-agent.conf creation is a problem I would > like to find an easy way around.? As it turns out a fresh install of > ubuntu 16.04.3 already has /usr/bin/pinentry-gnome3 installed.? That, > plus the fact that libgnutls28-dev also installs a bunch of stuff on my > bash file means I can reduce it to: > Hi! I have scripted an Ubuntu 17.10 docker container recently for building any GnuPG version and it is available at [1]. More details at [2]. Once built, it runs `gpg --card-edit` by default, but with [3] one can run any command. For building desired GnuPG version use (details at [4]): ``` bash docker-build.sh --build-arg GPG_VERSION=2.2.3 ``` [1] https://github.com/Nitrokey/gpg-docker [2] https://github.com/Nitrokey/gpg-docker/wiki [3] docker-run-command.sh [4] https://docs.docker.com/engine/reference/builder/#using-arg-variables -- Best regards, Szczepan From wk at gnupg.org Tue Dec 12 15:26:58 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Dec 2017 15:26:58 +0100 Subject: [Announce] GPGME 1.10.0 released Message-ID: <87k1xsauod.fsf@wheatstone.g10code.de> Hello! We are pleased to announce version 1.10.0 of GPGME. GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines like gpg and gpgsm easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification, and key management. GPGME comes with language bindings for Common Lisp, C++, QT, Python 2 and 3. See https://gnupg.org/software/gpgme for more. Noteworthy changes in version 1.10.0 ==================================== * Now returns more specific error codes for decryption to distinguish between bad passphrase, user canceled, and no secret key. * Now returns key origin information if available. * Added context flag "auto-key-retrieve" to selectively enable the corresponding gpg option. * Added flag is_de_vs to decryption and verify results. * py: Use SEEK_SET as default for data.seek. * cpp: Various new APIs. * Reduced spawn overhead on Linux again. Added new configure option --disable-linux-getdents to disable this feature for very old Linux versions. * Improved the Python bindings build system. * Made the test suite less fragile. Download ======== You may download this library and its OpenPGP signature from: https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.10.0.tar.bz2 (1338k) https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.10.0.tar.bz2.sig or from ftp.gnupg.org. The SHA-1 checksum is 77d3390887da25ed70b7ac04392360efbdca501f gpgme-1.10.0.tar.bz2 but you better check the integrity using the provided signature. See for details. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and one contractor. Both work exclusivly on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We are planning to extend our team again. See you at FOSDEM. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and with financial support. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-devel 'at' gnupg.org mailing list. p.p.s List of 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: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 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 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 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 gnupg at raf.org Wed Dec 13 02:17:00 2017 From: gnupg at raf.org (gnupg at raf.org) Date: Wed, 13 Dec 2017 12:17:00 +1100 Subject: Upgraded gpg from 1.4.18 to 2.1.18: --default-recipient-self no longer works Message-ID: <20171213011700.GA7423@raf.org> Hi, I've just upgraded a debian8 host to debian9 and got the new gpg (v2.1.18) and now my cronjob that encrypts data no longer works because it wants input for some reason. The gpg command is something like: cmd... | gpg --default-recipient-self --encrypt --output filename.gpg At first, it said (via cron): gpg: cannot open '/dev/tty': No such device or address Then I stupidly added --no-tty and it said: gpg: Sorry, no terminal at all requested - can't get input So it really wants input all of a sudden. So I ran it manually and it turned out that --default-recipient-self no longer works: You did not specify a user ID. (you may use "-r") Current recipients: Enter the user ID. End with an empty line: Any idea why it no longer knows who the default recipient is? There's only one key that it could be. The documentation for --default-recipient-self says: The default key is the first one from the secret keyring or the one set with --default-key. But it's not finding it: $ gpg --list-keys /home/user/.gnupg/pubring.gpg ----------------------------- pub rsa2048 2016-05-15 [SC] EB2040CBE8E339FD1210B004FB2608650E6E1961 uid [ultimate] Name sub rsa2048 2016-05-15 [E] $ gpg --list-secret-keys /home/user/.gnupg/pubring.gpg ----------------------------- sec rsa2048 2016-05-15 [SC] EB2040CBE8E339FD1210B004FB2608650E6E1961 uid [ultimate] Name ssb rsa2048 2016-05-15 [E] I can specify the ID explicitly (i.e. name at domain.com) and then it works but I shouldn't have to, should I? Why can it find the key when I name it but it can't find it by itself? Thanks for any insight. cheers, raf P.S. I noticed a couple of possible gpg(1) man page errors. (1) The documentation for --default-key says: Use name as the default key to sign with. But the documentation for --default-recipient-self implies that it is also for encryption, not just signing. Unless --recipient and --default-recipient apply to encryption but --default-recipient-self only applies to signing. If so, that would be confusing and should probably be stated explicitly. (2) The documentation for --no-tty says: Make sure that the TTY (terminal) is never used for any output... But it also makes sure that the TTY is not used for input as well. From wk at gnupg.org Wed Dec 13 09:36:29 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Dec 2017 09:36:29 +0100 Subject: Upgraded gpg from 1.4.18 to 2.1.18: --default-recipient-self no longer works In-Reply-To: <20171213011700.GA7423@raf.org> (gnupg@raf.org's message of "Wed, 13 Dec 2017 12:17:00 +1100") References: <20171213011700.GA7423@raf.org> Message-ID: <87lgi79g8i.fsf@wheatstone.g10code.de> On Wed, 13 Dec 2017 02:17, gnupg at raf.org said: > The gpg command is something like: > > cmd... | gpg --default-recipient-self --encrypt --output filename.gpg For all unattended use you need to add --batch (in all versions of gpg since he very beginning). > gpg: cannot open '/dev/tty': No such device or address Batch will also handle this. > So I ran it manually and it turned out that --default-recipient-self > no longer works: There have been a couple of internal changes in the last years which may have affected this option. > I can specify the ID explicitly (i.e. name at domain.com) and > then it works but I shouldn't have to, should I? It is always better to make it explict. To debug your failure, please run the encryption command agian but add --verbose --debug lookup to the invocation > (1) The documentation for --default-key says: > > Use name as the default key to sign with. > > But the documentation for --default-recipient-self > implies that it is also for encryption, not just signing. Both commands are basically the same; they just differ in how the default key is determined. So, right the man page is wrong. > (2) The documentation for --no-tty says: > > Make sure that the TTY (terminal) is never used for any output... > > But it also makes sure that the TTY is not used for input as well. Right. But in practise you don't need it. --batch is sufficient. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Dec 13 11:13:08 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Dec 2017 11:13:08 +0100 Subject: Upgraded gpg from 1.4.18 to 2.1.18: --default-recipient-self no longer works In-Reply-To: <87lgi79g8i.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 13 Dec 2017 09:36:29 +0100") References: <20171213011700.GA7423@raf.org> <87lgi79g8i.fsf@wheatstone.g10code.de> Message-ID: <87h8sv9brf.fsf@wheatstone.g10code.de> On Wed, 13 Dec 2017 09:36, wk at gnupg.org said: >> (1) The documentation for --default-key says: >> >> Use name as the default key to sign with. >> >> But the documentation for --default-recipient-self >> implies that it is also for encryption, not just signing. > > Both commands are basically the same; they just differ in how the > default key is determined. So, right the man page is wrong. I need to correct myself: I did not notice that you wrote --default-key; I read --default-recipient. --default-recipient and --default-recipient-self are used to sepciy an default encryption key - they don't affect signing. --default-key KEY is used for signing. The fact that --default-recipient-self uses that KEY also as default encryption key is the actual purpose of that very option --default-recipient-self. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg at raf.org Wed Dec 13 12:59:49 2017 From: gnupg at raf.org (gnupg at raf.org) Date: Wed, 13 Dec 2017 22:59:49 +1100 Subject: Upgraded gpg from 1.4.18 to 2.1.18: --default-recipient-self no longer works In-Reply-To: <87lgi79g8i.fsf@wheatstone.g10code.de> References: <20171213011700.GA7423@raf.org> <87lgi79g8i.fsf@wheatstone.g10code.de> Message-ID: <20171213115949.GA15083@raf.org> Werner Koch wrote: > On Wed, 13 Dec 2017 02:17, gnupg at raf.org said: > > > The gpg command is something like: > > > > cmd... | gpg --default-recipient-self --encrypt --output filename.gpg > > For all unattended use you need to add --batch (in all versions of gpg > since he very beginning). Hi Werner, thanks for the response. It always worked for me in the past without --batch and now, it works without --batch if I use --recipient or --default-recipient instead of --default-recipient-self. > > gpg: cannot open '/dev/tty': No such device or address > > Batch will also handle this. > > > So I ran it manually and it turned out that --default-recipient-self > > no longer works: > > There have been a couple of internal changes in the last years which may > have affected this option. I just tried using --default-recipient-self --batch and it worked. That surprised me. I wouldn't expect --batch to change the ability of --default-recipient-self to find the key (See below for probable explanation). > > I can specify the ID explicitly (i.e. name at domain.com) and > > then it works but I shouldn't have to, should I? > > It is always better to make it explict. To debug your failure, please > run the encryption command agian but add > > --verbose --debug lookup > > to the invocation I just tried that and it found the key. Then I tried just --default-recipient-self without the debugging and it worked! I think I know what happened. I now have a ~/.gnupg/.gpg-v21-migrated file and ~/.gnupg/private-keys-v1.d/ directory that I wouldn't have had when the --default-recipient-self first started failing via cron. But after I poked around a bit (e.g. gpg --list-secret-keys), the keyring migration took place and it's all working again. Does that make sense? It's a pity the keyring migration didn't take place during the cronjob. Then the upgrade would have been seamless. It's all good now though. Of course, you're right about it being better to be explicit but I wonder if --recipient would have also failed via cron immediately after the upgrade with the old keyring. > > (1) The documentation for --default-key says: > > > > Use name as the default key to sign with. > > > > But the documentation for --default-recipient-self > > implies that it is also for encryption, not just signing. > > Both commands are basically the same; they just differ in how the > default key is determined. So, right the man page is wrong. > > > > (2) The documentation for --no-tty says: > > > > Make sure that the TTY (terminal) is never used for any output... > > > > But it also makes sure that the TTY is not used for input as well. > > Right. But in practise you don't need it. --batch is sufficient. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. Thanks again and again. cheers, raf From peter at digitalbrains.com Wed Dec 13 14:05:07 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 13 Dec 2017 14:05:07 +0100 Subject: Upgraded gpg from 1.4.18 to 2.1.18: --default-recipient-self no longer works In-Reply-To: <20171213115949.GA15083@raf.org> References: <20171213011700.GA7423@raf.org> <87lgi79g8i.fsf@wheatstone.g10code.de> <20171213115949.GA15083@raf.org> Message-ID: On 13/12/17 12:59, gnupg at raf.org wrote: > It always worked for me in the past without --batch That was simple luck, which failed you now :-). All this time, GnuPG thought it was talking to a real person, and when it finally, after all those years, tried to say something to that person, all GnuPG found was a cron daemon... What a lonely moment that must have been. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From alex at nitrokey.com Thu Dec 14 14:36:38 2017 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Thu, 14 Dec 2017 14:36:38 +0100 Subject: Conditions for changing admin PIN not clarified (GNUK) Message-ID: <1569b4a8-b2cc-a881-9e3c-30ab751d664b@nitrokey.com> Hello everyone, we realized (because of the question of a user), that there are conditions in which GnuPG is not questioning to short PIN for admin. This seems to be specific for Gnuk devices, as I could not reproduce on OpenPGP Card 2.1 This is what happened: * factory-reset of device (NK Start with Gnuk 1.2.6, maybe other versions are affected as well) * 'gpg --card-edit' -> admin -> passwd -> 3 -> '12345678' to 'newpin' * "PIN changed." message stated that everything is fine, although admin needs 8 character * neither '12345678' nor 'newpin' is accepted afterwards This is on GnuPG 2.2.3 on Arch Linux (which should not matter). What shall I do, file a bug? Is this a bug in GnuPG or Gnuk? This seems to be related to the admin-less mode, although changing admin PIN first shouldn't trigger this, does it? Kind regards Alex From ssmeenk at freshdot.net Thu Dec 14 15:57:58 2017 From: ssmeenk at freshdot.net (Sander Smeenk) Date: Thu, 14 Dec 2017 15:57:58 +0100 Subject: GnuPGv2 & 'pinentry' on Linux w/ remote access References: <20171106214926.d64gfdtdpepopbvx@dot.freshdot.net> Message-ID: <20171214145758.z6g4rcqkbbehx6qe@dot.freshdot.net> Quoting Ryan Beethe (ryan at splintermail.com): > I also was frustrated with how GPG pinentry worked by default. > What I did was write a custom pinentry wrapper, which I call rpinentry. > It just dispaches either the curses-based pinentry or a gui pinentry > based on the environment variable PINENTRY_USER_DATA which is read by > gpg and passed to the pinentry program I remembered i never followed up on this thread anymore. Mostly because i had to make sure the setup now works as intended. And it does. Ryan, thank you so much for the pinentry wrapper idea / env-vars trick. I still think it's a stupendous amount of effort to make this work but at least it does. From vim, from mutt, from Ansible, on my urxvt terminals, through ssh, anything that needs my GPG key(s) can now prompt me for passwords. Thanks a bundle. For the mailinglist archives, see the previous post(s) by Ryan in this thread for a working solution to this problem! Regards, -Sndr. -- | aibohphobia - fear of palindromes. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 From gnupg at raf.org Mon Dec 18 10:01:02 2017 From: gnupg at raf.org (gnupg at raf.org) Date: Mon, 18 Dec 2017 20:01:02 +1100 Subject: Upgrading from gpg1 to gpg2: lots of trouble, need help Message-ID: <20171218090102.GA23081@raf.org> Hi, Happy Holidays! I'm migrating from gpg1 to gpg2 and am having lots of trouble. I apologise for the long email but it's been a saga and others may encounter the same problems I did and I have some (possibly stupid) suggestions and some questions that I need answers for. For most of my decryption use cases I can't use a pinentry program. Instead, I have to start gpg-agent in advance (despite what its manpage says) with --allow-preset-passphrase so that I can then use gpg-preset-passphrase so that when gpg is run later, it can decrypt unaided. Previously, on ubuntu14 and debian8, with (I think) gpg-1.4.x and gpg-agent-2.0.x it worked fine but I had great trouble getting it to work on ubuntu16 (with gpg2-2.1.11) and debian9 (with gpg-2.1.18) and on macos-10.11.6 (with macports gpg-2.2.3). Suggestion 1 ------------ Some of my troubles were due to gpg-preset-passphrase needing the keygrip and no longer working with the fingerprint as the cache id. It would accept the fingerprint without error but when I tried to decrypt, gpg would just hang there until I killed it. It wasn't until I discovered that I needed to use the keygrip that gpg could decrypt. This happened on the mac with gpg-2.2.3. If gpg-preset-passphrase doesn't work with fingerprints anymore, maybe it could identify when a fingerprint has been used and let the user know that they need to use the keygrip instead. An error message to that effect would have saved me a lot of time. Or it could just fetch the keygrip that corresponds to the supplied fingerprint. But maybe this isn't possible. Suggestion 2 ------------ I think much of the rest of my troubles had to do with the keyring migration needing to have happened before gpg tried to decrypt anything but it hadn't happened. I remember at some point while testing something manually the keyring migration happened and then gpg started working. But it's all a bit of a blur. I spent several days and nights on this and my brain was quite frazzled at the time. Keyring migration seems to happen automatically when performing some operations but not all. Possibly because I'm using gpg-preset-passphrase. Maybe it could be triggered in more places. And another thing... -------------------- I also discovered that I need to disable systemd's handling of gpg-agent (on debian9 with gpg-2.1.18) if I want to control when gpg-agent starts and stops and which options are passed to it. I know this is not recommended but I've had too much trouble in the past with systemd thinking that it knows when a "user" has "logged out" and then deciding to "clean up" causing me masses of grief that I just can't bring myself to trust it to know what it's doing. I've disabled systemd's handling of gpg-agent on the debian9 hosts with: systemctl --global mask --now gpg-agent.service systemctl --global mask --now gpg-agent.socket systemctl --global mask --now gpg-agent-ssh.socket systemctl --global mask --now gpg-agent-extra.socket systemctl --global mask --now gpg-agent-browser.socket (from /usr/share/doc/gnupg-agent/README.Debian) I know someone on the internet has expressed unhappiness about people doing this and not being happy about supporting people who do it but please just pretend that it's a non-systemd system. Not everything is Linux after all. Gnupg should still work. Question 1 ---------- The most important use case I have is where a host will ssh to another host which performs decryption on its behalf. The second host has to be prepared first by me starting a gpg-agent and presetting the passphrase for a limited time so that it is ready to decrypt when the other host connects. On the decrypting host, I run a command that does something like: sudo -u thing --set-home -- gpgconf --kill gpg-agent screen -- \ sudo -u thing --set-home -- \ gpg-agent --homedir /etc/thing/.gnupg \ --allow-preset-passphrase \ --default-cache-ttl 3600 \ --max-cache-ttl 3600 \ --daemon -- \ bash --login (Then /etc/thing/.bash_login runs gpg-preset-passphrase) While these screen/sudo/gpg-agent/bash processes are running, the first host can connect with ssh and run a single command that will decrypt and retrieve some data. I can detach from the screen session knowing that this access will last for 3600 seconds or until I come back and terminate the screen/sudo/gpg-agent/bash session. I've managed to get this working again on the ubuntu16 host with gpg-2.1.11 but on the debian9 host with gpg-2.1.18 (but with systemd handling of gpg-agent disabled), it doesn't work. If I run the decryption command from within the screen/bash session, it works, and the only gpg-agent process is the one created by the above commands: gpg-agent --homedir /etc/store/.gnupg --allow-preset-passphrase \ --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- \ /bin/bash --login But as soon as the first host connects via ssh (and tries to run gpg), there is a new gpg-agent process as well as the one above: gpg-agent --homedir /etc/store/.gnupg --use-standard-socket --daemon And the decryption no longer works from the ssh connection or from the screen/sudo/gpg-agent/bash session. I would have thought that, now that the use of the standard socket is mandatory, this wouldn't happen. It seems as though, when the ssh connection ran gpg, it ignored the existing gpg-agent and started a new gpg-agent which took over the standard socket. Maybe not, there are several standard sockets including what looks like an ssh-specific one: 0 srwx------ 1 thing thing 0 Dec 18 14:23 S.gpg-agent 0 srwx------ 1 thing thing 0 Dec 18 14:23 S.gpg-agent.browser 0 srwx------ 1 thing thing 0 Dec 18 14:23 S.gpg-agent.extra 0 srwx------ 1 thing thing 0 Dec 18 14:23 S.gpg-agent.ssh On the ubuntu16 host where this is working, there is only the S.gpg-agent socket. Previously, with gpg-agent-2.0.x, I would tell gpg-agent to write its environment variables to a file that the incoming ssh connection could use to connect to that gpg-agent. Now that's impossible and it seems that gpg is starting a separate gpg-agent with a separate socket for the incoming ssh connection. Can anyone help me to get this situation working on the debian9 host? Would this work? ln -s S.gpg-agent S.gpg-agent.ssh or is that just wishful/deranged thinking? I'm delighted (i.e. able to stop panicking) that I managed to get it working on the ubuntu16 host but I really need to have this working on multiple hosts and all the others are recently upgraded debian9 hosts where it doesn't work. And eventually, the ubuntu host will no doubt get a version of gpg that behaves like the one on the debian9 host. I really really need to get this working. Any help would be greatly appreciated. Question 2 ---------- There is another thing that I don't understand that I'd like to. I'd like to be able to tell, before running gpg, whether or not gpg-agent currently has a cached passphrase. I found a method on the internet that became this: gpg_userid="user at domain.org" gpg_cache_id="`gpg2 --fingerprint --with-keygrip $gpg_userid | \ grep '^ ' | tail -1 | sed -e 's/^.*= *//'`" echo "GET_PASSPHRASE --no-ask $gpg_cache_id Error Prompt Desc" | \ gpg-connect-agent --no-autostart | grep -q OK && echo OK || echo ERR And it seemed to work ok until I realised that whether it reported that the passphrase was present or not was not always related to whether or not gpg would be able to decrypt unaided. That wasted a lot of my time too. :-) I set up something like the following shell functions: export GPG_TTY="`tty`" [ -d /usr/lib/gnupg2 ] && PATH="$PATH:/usr/lib/gnupg2" # debian/ubuntu [ -d /opt/local/libexec ] && PATH="$PATH:/opt/local/libexec" # macports gpg_userid="user at domain.org" gpg_keygrip="`gpg2 --fingerprint --with-keygrip $gpg_userid | \ grep '^ ' | tail -1 | sed -e 's/^.*= *//'`" function gpgcheck() { echo "GET_PASSPHRASE --no-ask $gpg_keygrip Error Prompt Desc" | \ gpg-connect-agent --no-autostart | grep -q OK && echo OK || echo ERR ps auxwww | grep '[g]pg-agent' } function gpgstart() { gpgconf --kill gpg-agent gpg-agent --allow-preset-passphrase --default-cache-ttl 3600 \ --max-cache-ttl 3600 --daemon askpass | gpg-preset-passphrase --preset "$gpg_keygrip" } function gpgstop() { gpgconf --kill gpg-agent } And sure enough, after gpgstart, gpgcheck would report that the passphrase was present and gpg could decrypt unaided but at some later point, gpgcheck would report that the passphrase wasn't present but gpg could still decrypt unaided. It would be nice to have an explanation of this behaviour and it would be nice to know how to reliably check whether or not gpg-agent has the passphrase cached. But it's not essential. As long as I know that I can't trust this method, I know not to rely on it. But it would be nice to have a method that I could rely on. This might have something to do with the multiple standard sockets being used by different processes. Question 3 ---------- I have another use case that I also haven't managed to get working. This is a new use case that I didn't have working before migrating to gpg2. The above gpgstart/gpgcheck/gpgstop functions were created while trying to get this working. I use ansible to do things on a small number of servers. Each server has a different sudo password. Ansible on its own doesn't cater for this situation but it's possible to get ansible to run a program to get sudo passwords for each host. I've set up the "pass" program to store these passwords in individual gpg-encrypted files so that ansible can fetch them automatically. Since ansible will start up many processes in parallel, all needing to decrypt a sudo password without my interaction, a pinentry program can't be used. I need to preset the passphrase before running ansible but when I do, it doesn't work. I run gpgstart and enter the passphrase. Then I run gpgcheck and it reports that the passphrase is present. Then I run ansible e.g.: ansible all -b -m shell -a "echo yes" However, it seems that as soon as I start ansible, the gpg-agent loses the passphrase and I'm bombarded with pinentry-curses processes. It all gets a bit crazy and at best, my xterm's tty settings are all messed up (i.e. if I type anything afterwards, it's all gibberish) and I have to kill the xterm. At worst, my laptop ends up filled with pinentry-curses processes, all hammering the CPU, and I have to kill them as well or force a shutdown. Just before I start ansible, gpgcheck shows OK. As soon as I start ansible, gpgcheck (in another xterm) shows ERR (but the agent is still running). I know I said that what gpgcheck reports doesn't always reflect gpg's ability to access the passphrase to decrypt but in this case (at least soon after gpgstart), it does seem to be telling the truth. This is on macos-10.11.6 with macports gpg-2.2.3. Does anyone have any idea what might be going wrong here? An additional gpg-agent process does get automatically started while this is happening: gpg-agent --homedir /Users/me/.gnupg --use-standard-socket --daemon Which no doubt has something to do with it. But I don't understand why it refused to use the gpg-agent process that already existed. I just tried it again and managed to see this error message: gpg: waiting for lock (held by 20749) The process with pid 20749 is: gpg2 -d --quiet --yes --compress-algo=none --no-encrypt-to \ --batch --use-agent /Users/me/.password-store/ansible/s2.gpg That would have been started by "pass". And eventually I saw: "gpg: decryption failed: No secret key" Some of ansible's subprocesses will work and some won't so maybe some are getting the passphrase before it disappears. I saw this in gpg-agent's manpage: SIGHUP This signal flushes all cached passphrases... Is it possible that something here is sending gpg-agent a SIGHUP? If so, is there a way to prevent that? Or maybe it has to do with the multiple standard sockets as well. Question 4 ---------- One last use case. I have a .vimrc config that automatically decrypts gpg files upon opening and encrypts them upon writing. With gpg1, I could enter the passphrase each time I opened an encrypted file and it was fine. Now that the use of gpg-agent is mandatory and pinentry programs always get used, I have a problem. As far as I am aware, no single pinentry program will work for all of my uses of vim. I use vim in xterm or Terminal, sometimes locally, sometimes over ssh. I also use macports MacVim in the mac windowing system and an X11 gvim in fullscreen X11. I'd rather not use pinentry-mac because it will take me out of fullscreen X11 mode if I'm there. And if I'm logged into the host via ssh from elsewhere I imagine it probably won't work at all. I don't want to use the curses pinentry either because while it will work inside vim in an xterm, it won't work in MacVim or in an X11 gvim window which is my most common way of using vim. What I'd really like, is either the ability to not use gpg-agent (unlikely) or a non-gui, non-curses pinentry program that just printed a prompt to stdout and read the passphrase from stdin. That would work in vim and gvim and MacVim windows whether I am logging in locally or remotely. Macports won't let me install pgp1 and pgp2 at the same time and I get the impression that debian doesn't want me installing pgp1 either. It says it's deprecated which is a great shame. So if anyone knows of a non-gui non-curses pinentry program, please let me know (preferably one that doesn't hammer the CPU). I've had to resort to presetting a passphrase in a gpg-agent before editing a gpg-encrypted file which is ok but I'd rather be able to enter the passphrase from within gvim like I use to. Thanks in advance, raf From dkg at fifthhorseman.net Mon Dec 18 17:47:09 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 18 Dec 2017 11:47:09 -0500 Subject: Upgrading from gpg1 to gpg2: lots of trouble, need help In-Reply-To: <20171218090102.GA23081@raf.org> References: <20171218090102.GA23081@raf.org> Message-ID: <87lgi0oueq.fsf@fifthhorseman.net> On Mon 2017-12-18 20:01:02 +1100, gnupg at raf.org wrote: > For most of my decryption use cases I can't use a > pinentry program. Instead, I have to start gpg-agent in > advance (despite what its manpage says) with > --allow-preset-passphrase so that I can then use > gpg-preset-passphrase so that when gpg is run later, it > can decrypt unaided. can you explain more about this use case? it sounds to me like you might prefer to just keep your secret keys without a passphrase in the first place. > I also discovered that I need to disable systemd's > handling of gpg-agent (on debian9 with gpg-2.1.18) if I > want to control when gpg-agent starts and stops and > which options are passed to it. I know this is not > recommended but I've had too much trouble in the past > with systemd thinking that it knows when a "user" has > "logged out" and then deciding to "clean up" causing me > masses of grief that I just can't bring myself to trust > it to know what it's doing. > > I've disabled systemd's handling of gpg-agent on the > debian9 hosts with: > > systemctl --global mask --now gpg-agent.service > systemctl --global mask --now gpg-agent.socket > systemctl --global mask --now gpg-agent-ssh.socket > systemctl --global mask --now gpg-agent-extra.socket > systemctl --global mask --now gpg-agent-browser.socket > > (from /usr/share/doc/gnupg-agent/README.Debian) > > I know someone on the internet has expressed > unhappiness about people doing this and not being happy > about supporting people who do it but please just pretend > that it's a non-systemd system. Not everything is Linux > after all. Gnupg should still work. i might be "someone on the internet" :) I can pretend it's a non-systemd system if you like -- that means you simply don't have functional per-user session management, and it's now on you to figure out session management yourself. Without going into detail on your many questions, it sounds to me like your main concern has to do with pinentry not seeming well-matched to the way that you connect to the machines you use, and the way you expect user interaction to happen. Let me ask you to zoom out a minute from the specific details you're seeing and try to imagine what you *want* -- ideally, not just in terms of what you've done in the past. for example, do you really want to have keys stored on a remote machine, or do you want them stored locally, with the goal of being able to *use* them remotely? do you want to be prompted to confirm the use of each private key? do you expect that confirmation to include a passphrase entry? how do you conceive of your adversary in this context? are you concerned about leaking private key material? auditing access? some other constraints? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From kwadronaut at aktivix.org Tue Dec 19 09:13:27 2017 From: kwadronaut at aktivix.org (kwadronaut) Date: Tue, 19 Dec 2017 09:13:27 +0100 Subject: Expired cert with HSTS for this list Message-ID: <89076193-9189-d1cf-1e7f-76a7f59bd7cf@aktivix.org> Moin, Seems like this fragile thing called time has taken over again. Validity of the TLS cert deployed on https://lists.gnupg.org/pipermail/gnupg-users/ goes until Monday, December 18, 2017 at 9:13:00 PM, and that time was yesterday for me. It breaks many browsers with the included HSTS, luckily I still have lynx around. Might be time to let LetsEncrypt refresh the certs automagically every once in a while. Thanks to the lovely sysadmins for keeping these lists and archives online! [And now back to 'is this a bug or am I expecting the wrong things from dirmngr. If I remain silent, the bug was sitting between human and keyboard] Beslema, kwadronaut -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Dec 19 17:53:08 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Dec 2017 17:53:08 +0100 Subject: Expired cert with HSTS for this list In-Reply-To: <89076193-9189-d1cf-1e7f-76a7f59bd7cf@aktivix.org> (kwadronaut@aktivix.org's message of "Tue, 19 Dec 2017 09:13:27 +0100") References: <89076193-9189-d1cf-1e7f-76a7f59bd7cf@aktivix.org> Message-ID: <87bmiu3bij.fsf@wheatstone.g10code.de> On Tue, 19 Dec 2017 09:13, kwadronaut at aktivix.org said: > around. Might be time to let LetsEncrypt refresh the certs automagically > every once in a while. Yeah. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg at raf.org Wed Dec 20 04:11:26 2017 From: gnupg at raf.org (gnupg at raf.org) Date: Wed, 20 Dec 2017 14:11:26 +1100 Subject: Upgrading from gpg1 to gpg2: lots of trouble, need help In-Reply-To: <87lgi0oueq.fsf@fifthhorseman.net> References: <20171218090102.GA23081@raf.org> <87lgi0oueq.fsf@fifthhorseman.net> Message-ID: <20171220031126.GB20576@raf.org> Hi Daniel, Thanks for responding. Daniel Kahn Gillmor wrote: > On Mon 2017-12-18 20:01:02 +1100, gnupg at raf.org wrote: > > For most of my decryption use cases I can't use a > > pinentry program. Instead, I have to start gpg-agent in > > advance (despite what its manpage says) with > > --allow-preset-passphrase so that I can then use > > gpg-preset-passphrase so that when gpg is run later, it > > can decrypt unaided. > > can you explain more about this use case? it sounds to me like you > might prefer to just keep your secret keys without a passphrase in the > first place. I'm assuming that you are referring to the use case in Question 1. Definitely not. That would make it possible for the decryption to take place at any time. I need it to only be able to take place for short periods of time when I am expecting it. > > I also discovered that I need to disable systemd's > > handling of gpg-agent (on debian9 with gpg-2.1.18) if I > > want to control when gpg-agent starts and stops and > > which options are passed to it. I know this is not > > recommended but I've had too much trouble in the past > > with systemd thinking that it knows when a "user" has > > "logged out" and then deciding to "clean up" causing me > > masses of grief that I just can't bring myself to trust > > it to know what it's doing. > > > > I've disabled systemd's handling of gpg-agent on the > > debian9 hosts with: > > > > systemctl --global mask --now gpg-agent.service > > systemctl --global mask --now gpg-agent.socket > > systemctl --global mask --now gpg-agent-ssh.socket > > systemctl --global mask --now gpg-agent-extra.socket > > systemctl --global mask --now gpg-agent-browser.socket > > > > (from /usr/share/doc/gnupg-agent/README.Debian) > > > > I know someone on the internet has expressed > > unhappiness about people doing this and not being happy > > about supporting people who do it but please just pretend > > that it's a non-systemd system. Not everything is Linux > > after all. Gnupg should still work. > > i might be "someone on the internet" :) > > I can pretend it's a non-systemd system if you like -- that means you > simply don't have functional per-user session management, and it's now > on you to figure out session management yourself. Which is exactly how I want it. I want to decide when gpg-agent starts and when it stops. It is unrelated to per-user sessions. > Without going into detail on your many questions, it sounds to me like > your main concern has to do with pinentry not seeming well-matched to > the way that you connect to the machines you use, and the way you expect > user interaction to happen. That's true for some of the use case problems I'm having but not with this one. I could use pinentry-curses here because it's happening over an ssh connection in an xterm, not inside a gvim window where curses doesn't work. But I'm happy to keep using gpg-preset-passphrase. I think the real problem with this use case is that the incoming ssh connections from the other hosts are starting their own gpg-agent (I'm guessing using the S.gpg-agent.ssh socket) rather than just connecting to the existing gpg-agent that I have put the passphrase into (I'm guessing that gpg-agent uses the S.gpg-agent socket). > Let me ask you to zoom out a minute from the specific details you're > seeing and try to imagine what you *want* -- ideally, not just in terms > of what you've done in the past. What I want *is* what I've done in the past. That's why I did it. :-) > for example, do you really want to have keys stored on a remote machine, > or do you want them stored locally, with the goal of being able to *use* > them remotely? do you want to be prompted to confirm the use of each > private key? do you expect that confirmation to include a passphrase > entry? how do you conceive of your adversary in this context? are you > concerned about leaking private key material? auditing access? some > other constraints? > > --dkg For the purposes of this use case, all the hosts are "remote". i.e. None of this is happening on the host that I have physically in front of me. They are all servers of different kinds. What I want is to have gpg and encrypted data and a key-with-a-strong-passphrase on a small number of servers and then, when needed and only when needed, I want to be able to enable unassisted decryption by the uid that owns the data/keys/gpg-agent. Other hosts that need access to the decrypted data need to be able to ssh to the host that has gpg/keys/data to get that data without my interaction. I need to be able to ssh to the server with gpg/keys/data to set things up. Then I need to be able to log out without gpg-agent disappearing. Then the other servers need to be able to ssh to that server and use the gpg-agent that I prepared earlier so as to decrypt the data. Then I need to be able to ssh back in and turn off gpg-agent. The big picture is that there are some publically accessible servers that need access to sensitive data (e.g. database passwords and symmetric encryption keys and similar) that I don't want stored on those servers at all. Instead there are service processes that fetch the data from a set of several other servers that are not publically accessible. This fetching of data only needs to happen when the publically accessible servers reboot or when the data fetching services are restarted/reconfigured. So, in answer to your questions: > do you really want to have keys stored on a remote machine or do you > want them stored locally, with the goal of being able to *use* them > remotely? I don't want the keys stored locally on my laptop. I don't want the keys stored on the publically accessible remote hosts where the data is ultimately needed. I want to store and use the keys on a different set of non-publically accessible remote hosts. > do you want to be prompted to confirm the use of each private key? > do you expect that confirmation to include a passphrase entry? No. The private key will be used four times for each host that reboots. I don't want to have to be there to physically confirm each use of the private key (or enter the passphrase each time). After all, they may well happen at the same time and from within ssh connections that I have nothing to do with. That would be similar to my ansible user case. I want to be able to enter the passphrase once (on each of the gpg/data/key hosts) before I reboot the publically accessible hosts, and I want that to be sufficient to enable multiple incoming ssh connections from the rebooting hosts to get what they need, and when the hosts have successfully rebooted I want to be able to turn off gpg-agent. If you prefer, the confirmation of the use of private keys is me entering the passphrase into gpg-agent before the other hosts make their ssh connections. > how do you conceive of your adversary in this context? > are you concerned about leaking private key material? > auditing access? other constraints? I'm concerned about everything. Physical theft of servers, hackers, you name it. There are many, many defenses in place but I have to assume that someone might be able to get past them all. So making things as hard as possible for attackers is the way to go. It seems like a good idea not to have the sensitive data on the publically accessible hosts at all except in memory. Someone suggested using gpg-agent forwarding but that, and the first in your batch of questions above, seems to imply that the expectation is for keys to be stored locally and that access to those keys be made available to gpg processes on other hosts that a human user has connected to (in much the same way as ssh-agent forwarding works). That is not at all what I want to happen. My local laptop should have nothing to do with any of this except that it is where I ssh from to get everywhere else. Also, for redundancy purposes, the data and keys need to be stored on multiple servers in different locations. Even if I consider those servers to be "local", it's still not what I want because that assumes that it is the server with the keys that connects to the other servers with data that needs to be decrypted with those keys. In this case, it is those other servers that will be making the connections to the server with the keys (and the data). I don't want their rebooting to be delayed by my having to log in to each of them with a passphrase or a forwarded gpg-agent connection. I want them to make the connection by themselves as soon as they are ready to, obtain the data they need, and continue booting up. I'm not sure I understand your reasons for asking all these questions. Is it that you don't think that want I want to do is still possible with gnupg2.1+ and are you trying to convince me to fundamentally change what I'm doing? I don't want to fundamentally change what I'm doing. I don't have the time (unless there really is no alternative). I just wanted to upgrade my servers from debian8 to debian9. I had no idea this was going to happen. Can incoming ssh connections use the existing gpg-agent that I have already started and preset with a passphrase or not? Does anyone know? Is continuing to use gpg1 indefinitely an option? Will it contine to work with recent versions of gpg-agent? Debian says that gpg1 is deprecated but I've read that gpg1 is now mostly only useful for embedded systems (or servers). Since IoT and servers will never go away, does that mean that gpg1 will never go away? I'd be happy to keep using gpg1 if I knew that it wouldn't go away and if I knew that it would keep working with recent versions of gpg-agent. cheers, raf From wk at gnupg.org Wed Dec 20 16:36:34 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Dec 2017 16:36:34 +0100 Subject: [Announce] GnuPG 2.2.4 released Message-ID: <87fu85xvgd.fsf@wheatstone.g10code.de> Hello! 20 years after the first version we are pleased to announce the availability of a new GnuPG release: version 2.2.4. This is a maintenance release; see below for a list of fixed bugs. About GnuPG =========== 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. As an Universal Crypto Engine 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. Noteworthy changes in version 2.2.4 =================================== * gpg: Change default preferences to prefer SHA512. * gpg: Print a warning when more than 150 MiB are encrypted using a cipher with 64 bit block size. * gpg: Print a warning if the MDC feature has not been used for a message. * gpg: Fix regular expression of domain addresses in trust signatures. [#2923] * agent: New option --auto-expand-secmem to help with high numbers of concurrent connections. Requires libgcrypt 1.8.2 for having an effect. [#3530] * dirmngr: Cache responses of WKD queries. * gpgconf: Add option --status-fd. * wks: Add commands --check and --remove-key to gpg-wks-server. * Increase the backlog parameter of the daemons to 64 and add option --listen-backlog. * New configure option --enable-run-gnupg-user-socket to first try a socket directory which is not removed by systemd at session end. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.4 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: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.4.tar.bz2 (6417k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.4.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.4_20171220.exe (3817k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.5_20171220.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new Gpg4win 3.0 installer featuring this version of GnuPG will be available soon. 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.2.4.tar.bz2 you would use this command: gpg --verify gnupg-2.2.4.tar.bz2.sig gnupg-2.2.4.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 the end of this mail 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.2.4.tar.bz2, you run the command like this: sha1sum gnupg-2.2.4.tar.bz2 and check that the output matches the next line: 732266e8888c6f41c084d043c7a0058332ff3580 gnupg-2.2.4.tar.bz2 d06a1413fd901c51eba14164ddb28d99ab9f84df gnupg-w32-2.2.4_20171220.exe 60d0e804075e05c8268b75d4cda1ec4277691385 gnupg-w32-2.2.4_20171220.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= 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 reference manual of the system. Separate man pages are included as well but they miss some of the details availabale only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF 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 to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. 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 . If you need commercial support check out . 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. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and one contractor. Both work exclusively on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We are planning to extend our team again and to help developers to improve integration of crypto in their applications. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of 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: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 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 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dkg at fifthhorseman.net Wed Dec 20 15:52:14 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 20 Dec 2017 09:52:14 -0500 Subject: Upgrading from gpg1 to gpg2: lots of trouble, need help In-Reply-To: <20171220031126.GB20576@raf.org> References: <20171218090102.GA23081@raf.org> <87lgi0oueq.fsf@fifthhorseman.net> <20171220031126.GB20576@raf.org> Message-ID: <877ethmoyp.fsf@fifthhorseman.net> Hi raf-- Hi On Wed 2017-12-20 14:11:26 +1100, gnupg at raf.org wrote: > Daniel Kahn Gillmor wrote: >> On Mon 2017-12-18 20:01:02 +1100, gnupg at raf.org wrote: >> > For most of my decryption use cases I can't use a >> > pinentry program. Instead, I have to start gpg-agent in >> > advance (despite what its manpage says) with >> > --allow-preset-passphrase so that I can then use >> > gpg-preset-passphrase so that when gpg is run later, it >> > can decrypt unaided. >> >> can you explain more about this use case? it sounds to me like you >> might prefer to just keep your secret keys without a passphrase in the >> first place. > > I'm assuming that you are referring to the use case in Question 1. > > Definitely not. That would make it possible for the decryption to > take place at any time. I need it to only be able to take place > for short periods of time when I am expecting it. OK, so your preferred outcome is some way to enable a key for a limited period of time. is that right? > I think the real problem with this use case is that the incoming > ssh connections from the other hosts are starting their own > gpg-agent (I'm guessing using the S.gpg-agent.ssh socket) rather > than just connecting to the existing gpg-agent that I have put > the passphrase into (I'm guessing that gpg-agent uses the > S.gpg-agent socket). there should be only one S.gpg-agent.ssh socket, and therefore only one agent. If you were using systemd and dbus user sessions, those system management tools would make sure that these things exist. This is the entire point of session management. It's complex to do by hand, and choosing to abandon the tools that offer it to you seems gratuitously masochistic. But ok? > What I want is to have gpg and encrypted data and a > key-with-a-strong-passphrase on a small number of servers and > then, when needed and only when needed, I want to be able to > enable unassisted decryption by the uid that owns the > data/keys/gpg-agent. Other hosts that need access to the > decrypted data need to be able to ssh to the host that has > gpg/keys/data to get that data without my interaction. > > I need to be able to ssh to the server with gpg/keys/data to set > things up. Then I need to be able to log out without gpg-agent > disappearing. Then the other servers need to be able to ssh to > that server and use the gpg-agent that I prepared earlier so as > to decrypt the data. Then I need to be able to ssh back in and > turn off gpg-agent. I'm still not sure i understand your threat model -- apparently your theorized attacker is capable of compromising the account on the targeted host, but *only* between the times before you enable (and after you disable) gpg-agent. Is that right? Why do you need these multi-detached operations? by "multi-detached" i mean that your sequence of operations appears to be: * attach * enable gpg-agent * detach * other things use? * attach * disable gpg-agent * detach wouldn't you rather monitor these potentially-vulnerable accounts (by staying attached or keeping a session open while they're in use)? > The big picture is that there are some publically accessible > servers that need access to sensitive data (e.g. database > passwords and symmetric encryption keys and similar) that I > don't want stored on those servers at all. Instead there are > service processes that fetch the data from a set of several > other servers that are not publically accessible. This fetching > of data only needs to happen when the publically accessible > servers reboot or when the data fetching services are > restarted/reconfigured. so what is the outcome if the gpg-agent is disabled when these reboots/restarts happen? how do you coordinate that access? > I want to be able to enter the passphrase once (on each of the > gpg/data/key hosts) before I reboot the publically accessible > hosts, and I want that to be sufficient to enable multiple > incoming ssh connections from the rebooting hosts to get what > they need, and when the hosts have successfully rebooted I want > to be able to turn off gpg-agent. > > If you prefer, the confirmation of the use of private keys is me > entering the passphrase into gpg-agent before the other hosts > make their ssh connections. this approach seems congruent with my single-attach proposal: * you log into "key management" host (this enables the systemd gpg-agent user service) * on "key management" host, enable key access using gpg-preset-passphrase or something similar * you trigger restart of public-facing service * public-facing service connects to "key management" host, gets the data it needs * you verify that the restart of the public-facing service is successful * you log out of "key management" host. dbus-user-session closes the gpg-agent automatically with your logout, thereby closing the agent and disabling access to those keys. can you explain why that doesn't meet your goals? > Also, for redundancy purposes, the data and keys need to be > stored on multiple servers in different locations. I think there are other ways to address your redundancy concerns that don't involve giving each of the redundant backup servers access to the cleartext of the secret key material at any time; so i'm not going to address this redundancy concern. > Even if I consider those servers to be "local", it's still not what I > want because that assumes that it is the server with the keys that > connects to the other servers with data that needs to be decrypted > with those keys. In this case, it is those other servers that will be > making the connections to the server with the keys (and the data). I > don't want their rebooting to be delayed by my having to log in to > each of them with a passphrase or a forwarded gpg-agent connection. I > want them to make the connection by themselves as soon as they are > ready to, obtain the data they need, and continue booting up. Here, i think you're making an efficiency argument -- you want to prepare the "key management" host in advance, so that during the boot process of the public-facing service, it gets what it needs without you needing to manipulate it directly. > I'm not sure I understand your reasons for asking all these > questions. Is it that you don't think that want I want to do is > still possible with gnupg2.1+ and are you trying to convince me > to fundamentally change what I'm doing? I'm trying to extract high-level, security-conscious, sensible goals from your descriptions, so that i can help you figure out how to meet them. It's possible that your existing choices don't actually meet your goals as well as you thought they did, and newer tools can help get you closer to meeting your goals. This may mean some amount of change, but it's change in the direction of what you actually want, so hopefully it's worth the pain. > Can incoming ssh connections use the existing gpg-agent that I > have already started and preset with a passphrase or not? Does > anyone know? yes, i've tested it. it works. > Is continuing to use gpg1 indefinitely an option? Will it > contine to work with recent versions of gpg-agent? gpg1 only "works" with versions of gpg-agent as a passphrase cache, but modern versions of GnuPG use gpg-agent as an actual cryptographic agent, which does not release the secret key at all. This is actually what i think you want, as it minimizes exposure of the secret key itself. gpg1 has access to the full secret key, while gpg2 deliberately does not. gpg-preset-passphrase only unlocks access to secret key material in the agent -- that is, it does *not* touch the passphrase cache. This means that it is incompatible with gpg1, as noted in the manual page. > Debian says that gpg1 is deprecated but I've read that gpg1 is > now mostly only useful for embedded systems (or servers). where did you read this? imho, gpg1 is now mostly only useful for people with bizarre legacy constraints (like using an ancient, known-bad PGP-2 key to maintain a system that is so crufty it cannot update the list of administrator keys). > Since IoT and servers will never go away, does that mean that gpg1 > will never go away? I'd be happy to keep using gpg1 if I knew that it > wouldn't go away and if I knew that it would keep working with recent > versions of gpg-agent. i advise against this approach. please use the modern version. it is well-maintained and should meet your needs. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From gnupg at raf.org Thu Dec 21 06:19:00 2017 From: gnupg at raf.org (raf) Date: Thu, 21 Dec 2017 16:19:00 +1100 Subject: Upgrading from gpg1 to gpg2: lots of trouble, need help In-Reply-To: <877ethmoyp.fsf@fifthhorseman.net> References: <20171218090102.GA23081@raf.org> <87lgi0oueq.fsf@fifthhorseman.net> <20171220031126.GB20576@raf.org> <877ethmoyp.fsf@fifthhorseman.net> Message-ID: <20171221051859.GB5261@raf.org> Daniel Kahn Gillmor wrote: > Hi raf-- > > Hi On Wed 2017-12-20 14:11:26 +1100, gnupg at raf.org wrote: > > Daniel Kahn Gillmor wrote: > >> On Mon 2017-12-18 20:01:02 +1100, gnupg at raf.org wrote: > >> > For most of my decryption use cases I can't use a > >> > pinentry program. Instead, I have to start gpg-agent in > >> > advance (despite what its manpage says) with > >> > --allow-preset-passphrase so that I can then use > >> > gpg-preset-passphrase so that when gpg is run later, it > >> > can decrypt unaided. > >> > >> can you explain more about this use case? it sounds to me like you > >> might prefer to just keep your secret keys without a passphrase in the > >> first place. > > > > I'm assuming that you are referring to the use case in Question 1. > > > > Definitely not. That would make it possible for the decryption to > > take place at any time. I need it to only be able to take place > > for short periods of time when I am expecting it. > > OK, so your preferred outcome is some way to enable a key for a limited > period of time. is that right? Yes. > > I think the real problem with this use case is that the incoming > > ssh connections from the other hosts are starting their own > > gpg-agent (I'm guessing using the S.gpg-agent.ssh socket) rather > > than just connecting to the existing gpg-agent that I have put > > the passphrase into (I'm guessing that gpg-agent uses the > > S.gpg-agent socket). > > there should be only one S.gpg-agent.ssh socket, and therefore only one > agent. If you were using systemd and dbus user sessions, those system > management tools would make sure that these things exist. This is the > entire point of session management. It's complex to do by hand, and > choosing to abandon the tools that offer it to you seems gratuitously > masochistic. But ok? There is only one S.gpg-agent.ssh socket (I think). I'm pretty sure that I was mistaken when I guessed that S.gpg-agent.ssh had something to do with the incoming ssh connection using gpg which started up its own gpg-agent process. I now think that S.gpg-agent.ssh has to do with ssh-agent support and nothing to do with this. With gnupg-2.1.11 on ubuntu16, there is only a single socket: ~/.gnupg/S.gpg-agent With gnupg-2.1.18 on debian9, there are four sockets: ~/.gnupg/S.gpg-agent ~/.gnupg/S.gpg-agent.browser ~/.gnupg/S.gpg-agent.extra ~/.gnupg/S.gpg-agent.ssh This may have something to do with why what I am trying to do works with gnupg-2.1.11 but not with gnupg-2.1.18. The incoming ssh connection did start its own gpg-agent process (even though there already was one running) but I no longer think that it had anything to do with S.gpg-agent.ssh. In fact, since the "user session" in which the first gpg-agent process was started could no longer access the passphrase, it seems as though the new gpg-agent process took over the sockets so that all attempts to communicate with gpg-agent via these sockets connected to the new gpg-agent process that knew nothing and the original gpg-agent process which knew the passphrase was uncontactable. But again, I'm only guessing. I saw a comment of yours on a mailing list archive about one of the purposes of gpg-agent being to prevent access to its contents from any process just because they had permissions to use the sockets without alerting the user. It sounds like that could be what is preventing my use case from working. But again, I'm only guessing. https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029804.html Since you say that, if systemd was handling this, that it would make sure that these sockets exist, perhaps my attempt to mask them had no effect. Because as soon as I start the first gpg-agent, all four sockets are created. I assume that it is gpg-agent itself that creates them rather than systemd. They disappear again when gpg-agent terminates. But that's the same behaviour as on macos without systemd. The sockets are created when gpg-agent starts and they are deleted when it stops. Which seems sensible. Hardly masochistic. But perhaps my masochism threshold is too high. :-) > > What I want is to have gpg and encrypted data and a > > key-with-a-strong-passphrase on a small number of servers and > > then, when needed and only when needed, I want to be able to > > enable unassisted decryption by the uid that owns the > > data/keys/gpg-agent. Other hosts that need access to the > > decrypted data need to be able to ssh to the host that has > > gpg/keys/data to get that data without my interaction. > > > > I need to be able to ssh to the server with gpg/keys/data to set > > things up. Then I need to be able to log out without gpg-agent > > disappearing. Then the other servers need to be able to ssh to > > that server and use the gpg-agent that I prepared earlier so as > > to decrypt the data. Then I need to be able to ssh back in and > > turn off gpg-agent. > > I'm still not sure i understand your threat model -- apparently your > theorized attacker is capable of compromising the account on the > targeted host, but *only* between the times before you enable (and after > you disable) gpg-agent. Is that right? Well, for physical theft of the servers, yes. > Why do you need these multi-detached operations? by "multi-detached" i > mean that your sequence of operations appears to be: > > * attach > * enable gpg-agent > * detach > * other things use? > * attach > * disable gpg-agent > * detach > > wouldn't you rather monitor these potentially-vulnerable accounts (by > staying attached or keeping a session open while they're in use)? I usually do but I want the ability to be able to detach from the screen session. But it's only for a few minutes. Being able to detach is not important. Having the incoming ssh connections communicate with the existing gpg-agent process is what's important. In my testing of this, I didn't actually detach from the screen session so that is not what is causing this problem. > > The big picture is that there are some publically accessible > > servers that need access to sensitive data (e.g. database > > passwords and symmetric encryption keys and similar) that I > > don't want stored on those servers at all. Instead there are > > service processes that fetch the data from a set of several > > other servers that are not publically accessible. This fetching > > of data only needs to happen when the publically accessible > > servers reboot or when the data fetching services are > > restarted/reconfigured. > > so what is the outcome if the gpg-agent is disabled when these > reboots/restarts happen? how do you coordinate that access? If gpg-agent is disabled when the reboots happen, the client servers fail to obtain the data until I enable gpg-agent. The clients keep trying until it works. > > I want to be able to enter the passphrase once (on each of the > > gpg/data/key hosts) before I reboot the publically accessible > > hosts, and I want that to be sufficient to enable multiple > > incoming ssh connections from the rebooting hosts to get what > > they need, and when the hosts have successfully rebooted I want > > to be able to turn off gpg-agent. > > > > If you prefer, the confirmation of the use of private keys is me > > entering the passphrase into gpg-agent before the other hosts > > make their ssh connections. > > this approach seems congruent with my single-attach proposal: > > * you log into "key management" host (this enables the systemd > gpg-agent user service) > > * on "key management" host, enable key access using > gpg-preset-passphrase or something similar > > * you trigger restart of public-facing service > > * public-facing service connects to "key management" host, gets the > data it needs > > * you verify that the restart of the public-facing service is successful > > * you log out of "key management" host. dbus-user-session closes the > gpg-agent automatically with your logout, thereby closing the agent > and disabling access to those keys. > > can you explain why that doesn't meet your goals? Sorry, I thought I already did. The 4th point above does not work. When the public-facing host connects via ssh to the key management host, and runs gpg, instead of it successully connecting to the existing gpg-agent process that I started minutes earlier, it starts a new gpg-agent process which doesn't know the passphrase and so the decryption fails. Here are the gpg-agent processes after I start the first gpg-agent process and preset the passphrase: /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \ --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash --login Here are the gpg-agent processes after an inoming ssh connection that attempts to use gpg: /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \ --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash --login gpg-agent --homedir /etc/thing/.gnupg --use-standard-socket --daemon That second gpg-agent process should not exist. The gpg process that caused it to be started should have connected to the existing gpg-agent process. The sockets for it existed but perhaps there was some reason why it didn't use them. There must be some reason why gpg thinks it needs to start gpg-agent. Perhaps it's because it's a different "user session". They are from two different ssh connections after all. > > Even if I consider those servers to be "local", it's still not what I > > want because that assumes that it is the server with the keys that > > connects to the other servers with data that needs to be decrypted > > with those keys. In this case, it is those other servers that will be > > making the connections to the server with the keys (and the data). I > > don't want their rebooting to be delayed by my having to log in to > > each of them with a passphrase or a forwarded gpg-agent connection. I > > want them to make the connection by themselves as soon as they are > > ready to, obtain the data they need, and continue booting up. > > Here, i think you're making an efficiency argument -- you want to > prepare the "key management" host in advance, so that during the boot > process of the public-facing service, it gets what it needs without > you needing to manipulate it directly. That's correct. > > I'm not sure I understand your reasons for asking all these > > questions. Is it that you don't think that want I want to do is > > still possible with gnupg2.1+ and are you trying to convince me > > to fundamentally change what I'm doing? > > I'm trying to extract high-level, security-conscious, sensible goals > from your descriptions, so that i can help you figure out how to meet > them. It's possible that your existing choices don't actually meet your > goals as well as you thought they did, and newer tools can help get you > closer to meeting your goals. > > This may mean some amount of change, but it's change in the direction of > what you actually want, so hopefully it's worth the pain. I'm sure that's probably true and I do appreciate your efforts. > > Can incoming ssh connections use the existing gpg-agent that I > > have already started and preset with a passphrase or not? Does > > anyone know? > > yes, i've tested it. it works. That's hopeful but I wonder why it doesn't work for me. > > Is continuing to use gpg1 indefinitely an option? Will it > > contine to work with recent versions of gpg-agent? > > gpg1 only "works" with versions of gpg-agent as a passphrase cache, but > modern versions of GnuPG use gpg-agent as an actual cryptographic agent, > which does not release the secret key at all. And I noticed that gpg1 can't use preset passphrases anymore anyway. And gnupg-1.4.22 in macports says that it doesn't use the agent at all anymore so that's not an option (probably for the best). > This is actually what i think you want, as it minimizes exposure of the > secret key itself. gpg1 has access to the full secret key, while gpg2 > deliberately does not. > > gpg-preset-passphrase only unlocks access to secret key material in the > agent -- that is, it does *not* touch the passphrase cache. This means > that it is incompatible with gpg1, as noted in the manual page. > > > Debian says that gpg1 is deprecated but I've read that gpg1 is > > now mostly only useful for embedded systems (or servers). > > where did you read this? I can't remember. > imho, gpg1 is now mostly only useful for > people with bizarre legacy constraints (like using an ancient, known-bad > PGP-2 key to maintain a system that is so crufty it cannot update the > list of administrator keys). > > > Since IoT and servers will never go away, does that mean that gpg1 > > will never go away? I'd be happy to keep using gpg1 if I knew that it > > wouldn't go away and if I knew that it would keep working with recent > > versions of gpg-agent. > > i advise against this approach. please use the modern version. it is > well-maintained and should meet your needs. > > --dkg Don't worry. I will. But it hasn't met many of my needs so far. :-) Another reason that I disabled/masked systemd's handling of the sockets is for consistency between the ubuntu16 host with gnupg-2.1.11 and debian9 with gnupg-2.1.8. Only the debian9 host has the systemd handling of sockets (it started with gnupg-2.1.17). Ah, systemd puts the sockets in a completely different place: /run/user/*/gnupg/ instead of ~/.gnupg/. So much for a standard socket location :-). That might be relevant. But it shouldn't be if systemd is not handling the sockets. Perhaps I didn't disable systemd's handling of the sockets properly and it's still partially managing things. But it claims to be masked so I don't think that's the problem. No, something's not right. I've globally unmasked and enabled the sockets but... As my user, I can do: > systemctl --global is-enabled gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket static enabled enabled enabled enabled And: > systemctl --user is-enabled gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket static enabled enabled enabled enabled I had to specifically enable them with --user otherwise it said disabled with --user even though it said enabled with --global. I might have done --user disable in teh past as well. It's all a bit of a blur. But when I su to the user in question, I get: > systemctl --user is-enabled gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket Failed to connect to bus: No such file or directory But it still reports as enabled with --global. Maybe that's enough. I don't know. And, as that user, gpg can --list-secret-keys but when I try to decrypt something, it doesn't ask for a passphrase and it fails to decrypt but it does start gpg-agent and sockets are created in ~/.gnupg even though systemd is now supposed to be handling the sockets. This is without me starting up the screen/sudo/gpg-agent/bash processes first. > gpg --list-secret-keys /etc/thing/.gnupg/pubring.gpg ----------------------------- sec rsa2048 2016-01-13 [SC] 25EB4337C3CA32DE46774E1B17B64F00CD3C41D1 uid [ultimate] user ssb rsa2048 2016-01-13 [E] Hmm, it mentions the old keyring above, not the migrated one in ~/.gnupg/private-keys-v1.d. Maybe that's why --list-secret-keys worked but the rest below doesn't. > echo OK | gpg -e --default-recipient-self | gpg -d gpg: encrypted with 2048-bit RSA key, ID 6E76F4FAAE42FC15, created 2016-01-13 "user " gpg: public key decryption failed: Inappropriate ioctl for device gpg: decryption failed: No secret key > ls -alsp .gnupg/S* 0 srwx------ 1 thing thing 0 Dec 21 15:45 .gnupg/S.gpg-agent 0 srwx------ 1 thing thing 0 Dec 21 14:47 .gnupg/S.gpg-agent.browser 0 srwx------ 1 thing thing 0 Dec 21 14:47 .gnupg/S.gpg-agent.extra 0 srwx------ 1 thing thing 0 Dec 21 14:47 .gnupg/S.gpg-agent.ssh I am completely failing to understand what's going on here. :-) Is systemd handling the sockets or not? There's no /run/user directory for this user so probably not. Maybe I don't understand --user and --global or systemd in general. Sorry for taking up so much of your time. I appreciate your effort to help. cheers, raf From me at paulapplegate.com Thu Dec 21 16:48:31 2017 From: me at paulapplegate.com (Paul Applegate) Date: Thu, 21 Dec 2017 10:48:31 -0500 Subject: ld: symbol(s) not found for architecture x86_64 error when running make Message-ID: Hi all, I am trying to update GPG 2.2.3 to 2.2.4 and I get the error below when I run the make command. I have no knowledge in coding, so the error makes no sense to me. Can anyone make sense of it and explain how I can fix the error? I tried to Google the error with no results relating to GPG. Let me know if you need any additional information from me. I'm using a Mac running High Sierra 10.13.2, Xcode 9.2 is installed with the command line tools. I had no problem installing GPG 2.2.3. Thanks Paul Pauls-iMac:gnupg-2.2.4 thor2$ sudo make /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in m4 make[2]: Nothing to be done for `all'. Making all in common /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am make[3]: Nothing to be done for `all-am'. Making all in kbx make[2]: Nothing to be done for `all'. Making all in g10 make[2]: Nothing to be done for `all'. Making all in sm make[2]: Nothing to be done for `all'. Making all in agent gcc -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -Wall -Wno-pointer-sign -Wpointer-arith -g -O2 -o gpg-agent gpg_agent-gpg-agent.o gpg_agent-command.o gpg_agent-command-ssh.o gpg_agent-call-pinentry.o gpg_agent-cache.o gpg_agent-trans.o gpg_agent-findkey.o gpg_agent-pksign.o gpg_agent-pkdecrypt.o gpg_agent-genkey.o gpg_agent-protect.o gpg_agent-trustlist.o gpg_agent-divert-scd.o gpg_agent-cvt-openpgp.o gpg_agent-call-scd.o gpg_agent-learncard.o ../common/libcommonpth.a -L/usr/local/lib -lgcrypt -lgpg-error -lassuan -L/usr/local/lib -lgpg-error -L/usr/local/lib -lnpth -L/usr/local/lib -lgpg-error -liconv Undefined symbols for architecture x86_64: "_assuan_sock_set_system_hooks", referenced from: _main in gpg_agent-gpg-agent.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [gpg-agent] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 From peter at digitalbrains.com Thu Dec 21 22:50:08 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 21 Dec 2017 22:50:08 +0100 Subject: ld: symbol(s) not found for architecture x86_64 error when running make In-Reply-To: References: Message-ID: <9510b8fb-8362-f6f0-f208-ce884fc7f5fa@digitalbrains.com> On 21/12/17 16:48, Paul Applegate wrote: > Undefined symbols for architecture x86_64: > "_assuan_sock_set_system_hooks", referenced from: > _main in gpg_agent-gpg-agent.o This is related to a little mistake in the declared dependencies. You'll need to get a libassuan that is at least version 2.5.0. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- An embedded message was scrubbed... From: Kristian Fiskerstrand Subject: [PATCH] build: Increase libassuan min version to 2.5.0 Date: Wed, 20 Dec 2017 21:25:01 +0100 Size: 9090 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Healer64 at protonmail.com Fri Dec 22 14:51:53 2017 From: Healer64 at protonmail.com (Healer64) Date: Fri, 22 Dec 2017 08:51:53 -0500 Subject: Problems reading smartcard Message-ID: I have openpgp keys loaded on a yubikey in smartcard mode but am having problems accessing the card. Originally there were some permission issues but i worked them out to the point that gpg --card-status consistently reads the card. This is on fedora. However gpg2 --card-status gives "gpg selecting openpgp failed Card error gpg OpenPGP card not available Card error" Since selinux had previously been a problem I did setenforce 0 to troubleshoot. Now gpg2 --card-status reads the card successfully. However there are no new avc denials so I'm not sure how or why selinux is blocking gpg2 but not gpg. Even more weirdly If while selinux is in permissive mode I read the card with gpg2 I can't afterwards read it with gpg. I get "gpg pcsc_establish_context failed no service (0x801001d) gpg OpenPGP card not available general error" So using gpg I can access the card if selinux is on or off unless I first access the card with gpg2. Afterwards I get errors from gpg. gpg --version 1.4.22 gpg2 --version 2.1.13 Libgcrypt 1.7.9 Any idea how to troubleshoot this? Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Fri Dec 22 20:14:05 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 22 Dec 2017 20:14:05 +0100 Subject: Problems reading smartcard In-Reply-To: References: Message-ID: I think the problem is that gpg2 is not the one doing the smartcard calls. It spawns a gpg-agent process, which then spawns an scdaemon process. These two are still running when you're back at the command prompt. gpg does not do this by default, it talks to the card directly. However, after gpg2 has spawned its helpers, these helpers are still alive, and *holding the card reader exclusively*. So now gpg can no longer access the card reader because scdaemon, running in the background, already has it open. I don't know /anything/ about SELinux. But hopefully now you can look in the right place, because I think you got sidetracked by the gpg2 process not actually doing the business. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Sat Dec 23 16:43:31 2017 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sat, 23 Dec 2017 15:43:31 +0000 Subject: [Announce] GnuPG 2.2.4 released In-Reply-To: <87fu85xvgd.fsf@wheatstone.g10code.de> References: <87fu85xvgd.fsf@wheatstone.g10code.de> Message-ID: <572059587.20171223154331@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wednesday 20 December 2017 at 3:36:34 PM, in , Werner Koch wrote:- > Noteworthy changes in version 2.2.4 > =================================== > * gpg: Change default preferences to prefer SHA512. Out of curiosity, what is the reason for the self-signature and subkey binding signature continuing to default to SHA256 (digest algo 8)? I made a test key by "gpg --no-options --quick-gen-key Test20171223". Showpref gave me:- [marginal] (1). Test20171223 Cipher: AES256, AES192, AES, 3DES Digest: SHA512, SHA384, SHA256, SHA224, SHA1 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify - --list-packets gave me:- # off=0 ctb=99 tag=6 hlen=3 plen=269 :public key packet: version 4, algo 1, created 1514029011, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] keyid: ACF49800D0F8B1CE # off=272 ctb=b4 tag=13 hlen=2 plen=12 :user ID packet: "Test20171223" # off=286 ctb=89 tag=2 hlen=3 plen=340 :signature packet: algo 1, keyid ACF49800D0F8B1CE version 4, created 1514029011, md5len 0, sigclass 0x13 digest algo 8, begin of digest 8e 59 hashed subpkt 33 len 21 (issuer fpr v4 0BD8113FF3B9ED9BA4EE6F96ACF49800D0F8B1CE) hashed subpkt 2 len 4 (sig created 2017-12-23) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 9 len 4 (key expires after 2y0d0h0m) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID ACF49800D0F8B1CE) data: [2047 bits] # off=629 ctb=b9 tag=14 hlen=3 plen=269 :public sub key packet: version 4, algo 1, created 1514029011, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] keyid: F3749143D5AC687C # off=901 ctb=89 tag=2 hlen=3 plen=310 :signature packet: algo 1, keyid ACF49800D0F8B1CE version 4, created 1514029011, md5len 0, sigclass 0x18 digest algo 8, begin of digest 99 e5 hashed subpkt 33 len 21 (issuer fpr v4 0BD8113FF3B9ED9BA4EE6F96ACF49800D0F8B1CE) hashed subpkt 2 len 4 (sig created 2017-12-23) hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID ACF49800D0F8B1CE) data: [2047 bits] I am using the Windows version of GnuPG 2.2.4 from https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.4_20171220.exe under 64-bit Windows 10.0 Build 15063. - -- Best regards MFPA Wisdom is a companion to age; yet age may travel alone. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWj55pl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +hGRAP9hTRbd4Oj0AkmBT87f40GpPIw9Skxz82BnlWBiSxNfNAEA9QFryCoqb1zC rjf7PhVtmL8+hvsE94XDigdMpxuVJQaJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWj55pl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/3GhD/93F8ijHN5D9nbcptAlW4EtcvSH CgUeXgBsuvrePi1JTI2ScfkNT2WxHrhTRwERFUryyDBgMcM4OkQVMAqTlfs0p7H+ TeXkQ9UuOcrLm87kVzjWUMKJFBk52amPIvxzhqGDgjZETQJnymESVVMTijB+tU4t EwhodsbBUAaQ3DvhJpZwGfAWh4Wv+rn1vvWbC021K37J8vJp4W6lQQrqYwDmYVW6 wIJQC+IPTvP240P2+XwBtVXkays4MgT0JSu6pW8fhsNGVlfHJStv7jtv5shecMAJ jSU42GvO6a9bvEhbO2hAeIJQrgTg2soUm/t0pVEo8klFEd38bx4GErS7gifpEaZ+ GsSFTwxmsPhRoXnzQ93VLMIk9ddnxIblX3YvI2PtNo1S8YMBA9+VRR5lnPMEX0dF zHpn10hbd0KvSb/tOmByRmBspfUjVYbhv5Hru/4Mofq4VGoOte0RYk8VTDlWQZYc 8GTjLG1D42r16QEI31L9alVk2Nf0XqPgraaUHlsQFIMIAN/RCnPw1rSaOGOg5Nyk 3UL2X8gWokr/an7048cfdjjHwtYa/rKbz6HXbWD+XCM/JHiwMwR4fvLEOBbYF2nt g0CwPJL6g3rt7Vy7pFr93pWE4wpAqNh2CLIouLSfhJHkDm3bva+QoVRXpc2K5+J+ 98L4fLYCaREPcX/G7g== =sKVX -----END PGP SIGNATURE----- From cvimail81 at gmail.com Mon Dec 25 14:49:02 2017 From: cvimail81 at gmail.com (Egon) Date: Mon, 25 Dec 2017 14:49:02 +0100 Subject: Ascii-armor in paper - question Message-ID: <77f866a4-7bf2-e1c3-eab5-7120a2e406fd@gmail.com> Hi All, I have an encrypted GPG Ascii-armored document which I want to print it to paper in short form (if it is possible). Does ascii-armor format redundant or redundancy it true only for GPG keys? What can I do to print it in "shorter form"? (if available, convert it to some standardized format which produce shorter text). I want to find a method which help me to reconstruct the printed ascii-armor file from paper more easily (if possible). Paperkey - I think - working only with GPG keys. Best regards: Egon From Healer64 at protonmail.com Mon Dec 25 21:34:54 2017 From: Healer64 at protonmail.com (Healer64) Date: Mon, 25 Dec 2017 15:34:54 -0500 Subject: Problems reading smartcard In-Reply-To: References: Message-ID: Ah, that makes sense. Thanks. I'll try asking on an selinux help forum and see if they have any ideas. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: Problems reading smartcard > Local Time: December 22, 2017 1:14 PM > UTC Time: December 22, 2017 7:14 PM > From: peter at digitalbrains.com > To: Healer64 , gnupg-users at gnupg.org > > I think the problem is that gpg2 is not the one doing the smartcard calls. It > spawns a gpg-agent process, which then spawns an scdaemon process. These two are > still running when you're back at the command prompt. > > gpg does not do this by default, it talks to the card directly. However, after > gpg2 has spawned its helpers, these helpers are still alive, and holding the > card reader exclusively. So now gpg can no longer access the card reader > because scdaemon, running in the background, already has it open. > > I don't know /anything/ about SELinux. But hopefully now you can look in the > right place, because I think you got sidetracked by the gpg2 process not > actually doing the business. > > HTH, > > Peter. > > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at http://digitalbrains.com/2012/openpgp-key-peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From branko at majic.rs Wed Dec 27 21:01:18 2017 From: branko at majic.rs (Branko Majic) Date: Wed, 27 Dec 2017 21:01:18 +0100 Subject: Updating recurring donation payment information Message-ID: <20171227210118.3d37b84c@majic.rs> Hello folks, Perhaps this has already been covered somewhere, but quick searches brought-up nothing - although maybe I wasn't studious enough, so feel free to point me to correct resource :) Is there a way to update recurring donation information? In particular the payment card info :) Best regards -- Branko Majic XMPP: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? XMPP: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From calebcase at gmail.com Wed Dec 27 18:13:53 2017 From: calebcase at gmail.com (Caleb Case) Date: Wed, 27 Dec 2017 12:13:53 -0500 Subject: gpg2 export secret key without passphrase Message-ID: Hi, I am using gpg2 with some build automation and I need to generate a key for the automation that does not require a passphrase. I was unable to export the secret key until I added a passphrase, but then there was no way export it without the passphrase. I did eventually stumble on a hack recommended elsewhere to use the older gpg (not gpg2) toolchain, import, remove password, and then export. But this does not seem like the correct way to do this. How does one export a gpg2 private key without a passphrase? Thanks! Caleb -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Fri Dec 29 03:04:43 2017 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Fri, 29 Dec 2017 02:04:43 +0000 Subject: gpg2 export secret key without passphrase In-Reply-To: References: Message-ID: <10110621853.20171229020443@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wednesday 27 December 2017 at 5:13:53 PM, in , Caleb Case wrote:- > How does one export a gpg2 private key without a > passphrase? Here, using GnuPG 2.2.4 under Windows, I was able to:- 1. gpg --edit-key KeyID passwd. 2. enter the key's existing password in the pinentry pop-up 3. press ENTER when asked for the new passphrase 4. press the button to confirm I don't want protection 5. repeat 3. and 4. 6. quit the key editing dialogue 7. gpgconf --kill gpg-agent and then try another key editing operation on the same key to verify that I was no longer asked for a passphrase 8. gpg -a -o path\to\file --export-secret-key KeyID - -- Best regards MFPA I'd give my right arm to be ambidextrous. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWkWiv18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +rYBAQCTCqgylZp/zq1vLEgqIuQRYZqVd4hLMI9L56lt8ycARwD9FoacVkQ9M3TS SwKW0L1c+yM7MQuXfIxrSz5p+NlRrw+JApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWkWi3l8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/39KD/9ojMmofmweHVDNj4+ibVw+gMlF 8uQgh6S6VScQxRgdxrR4JR3BpDiIL/DaJX9GdU0/KvsZbuODP4Mc2CEXQdfm0eBF 6tpNyhvnXtIzBlKKfP+vs7+9m3tYypAxXwlRdmc/r5TUjRdGbgEXFOlp3GD49y2s E6nhsAc99ByYSIfiV4/i2Q5IUC70qqMKxz70VkxOa0WhMhUTsH+SQEXU+r5m+5OY kDR/xwvdH2bwLGkUGP4Tc/ndS9HTCHHSBIXeZaiUnxDGaMIy0tARDcg9Mce8t6MT d56UPY5Ha5fdrh9SxU8/79tIhxOWEGLp9QE5FgFnXOHuCqPg5T514bcZbtH1Ao+I BcL6Kr3ZTIQUa9MpMqSzPvs8Sm3eBoJZ04wKdKVxFW1mqYVBkqXHp3aoaYxXmj3P 9exWPzXnJ56uSpmrwVLRA6qzEovFwcGdOmAHec4UXLpvUIhq9N5bA8DmZ31M8oLl VfJHybx6bv8p8FWE1AL27I1xH4Cjtye+IWC9o+6e45bUv8e09SVPf+MuoaJRAKq9 z0e0UzqIUxvvwZkBCf6k9AMZaazBFhQr9xIa/a8idEPDFq9gLelzDgJHAC52LiNt luzCNYNUpxOtRFoIhxcoZCubF/vYn9nAIDzX93eDgsfsg14gMGDIO/P2AQV/4CmT 7hNIT67TkeR6DCgAZg== =Vvhx -----END PGP SIGNATURE----- From leo at famulari.name Thu Dec 28 23:49:58 2017 From: leo at famulari.name (Leo Famulari) Date: Thu, 28 Dec 2017 17:49:58 -0500 Subject: GPGME Python bindings Message-ID: <20171228224958.GA7098@jasmine.lan> Hello, I'm working on downstream packaging of GPGME and GPGME's Python language bindings for GNU Guix. [0] Because it was easier, we began packaging the GPGME Python bindings based on the PyPi release [1] of version 1.8.0. However, since that time, GPGME has had a few more releases, but the PyPi release has not been updated. How should we interpret this? Does it mean that we should continue to package version 1.8.0 of Python bindings? Or should we try to build them from the latest GPGME source release? Sincerely, Leo [0] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnupg.scm?id=50c4d676ff65a2e26a5df5745733b8cc16b23bc6#n372 https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnupg.scm?id=50c4d676ff65a2e26a5df5745733b8cc16b23bc6#n445 [1] https://pypi.python.org/pypi/gpg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gnupg-kontakt at rezart.qelibari.de Fri Dec 29 01:18:27 2017 From: gnupg-kontakt at rezart.qelibari.de (=?utf-8?Q?Rezart_Qelibari_f=C3=BCr_GnuPG?=) Date: Fri, 29 Dec 2017 01:18:27 +0100 Subject: How to batch generate ECC key Message-ID: Hi *, I want to batch generate a key using an ECC algorithm using the following command: $ cat config.txt | gpg ?-batch ?generate-key config.txt contains the following: Key-Type: eddsa Key-Curve: ed25519 Key-Usage: sign Subkey-Type: ecdh Subkey-Curve: cv25519 Subkey-Usage: encrypt Passphrase: somepassword Name-Real: Some Real Name Name-Email: mail at example.com Creation-Date: 20170801T180000 Expire-Date: 0 %commit But I always receive the following error: gpg: agent_genkey failed: Unknown elliptic curve gpg: key generation failed: Unknown elliptic curve I already tried changing the key type to 22 or 18. Strangely this only happens with ed25519 or cv25519 curves while it works for nist p 256 as shown here: https://askubuntu.com/questions/861978/unattended-gnupg-key-generation-for-ecc/861985 Does anyone know what exactly goes wrong here? I am using gpg 2.2.4 and libgcrypt 1.8.2. Best Rezart From wk at gnupg.org Fri Dec 29 14:35:03 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Dec 2017 14:35:03 +0100 Subject: gpg2 export secret key without passphrase In-Reply-To: (Caleb Case's message of "Wed, 27 Dec 2017 12:13:53 -0500") References: Message-ID: <87y3llzmgo.fsf@wheatstone.g10code.de> On Wed, 27 Dec 2017 18:13, calebcase at gmail.com said: > How does one export a gpg2 private key without a passphrase? See MFPA's recipe for a workaround. We have an open bug for this: https://dev.gnupg.org/T1753 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Fri Dec 29 14:30:55 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Dec 2017 14:30:55 +0100 Subject: Updating recurring donation payment information In-Reply-To: <20171227210118.3d37b84c@majic.rs> (Branko Majic's message of "Wed, 27 Dec 2017 21:01:18 +0100") References: <20171227210118.3d37b84c@majic.rs> Message-ID: <87608p1x0w.fsf@wheatstone.g10code.de> On Wed, 27 Dec 2017 21:01, branko at majic.rs said: > Is there a way to update recurring donation information? In particular > the payment card info :) The easiest way is to write to donations at gnupg.org (that's currently me). I will then cancel your subscription and you may create a new one. There is an open task for that: https://dev.gnupg.org/T3298 Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Dec 29 15:14:55 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 29 Dec 2017 15:14:55 +0100 Subject: How to batch generate ECC key In-Reply-To: References: Message-ID: On 12/29/2017 01:18 AM, Rezart Qelibari f?r GnuPG wrote: > Does anyone know what exactly goes wrong here? try: $ cat config.txt Key-Type: eddsa Key-Curve: Ed25519 Key-Usage: sign Subkey-Type: ecdh Subkey-Curve: Curve25519 Subkey-Usage: encrypt Passphrase: somepassword Name-Real: Some Real Name Name-Email: mail at example.com Creation-Date: 20170801T180000 Expire-Date: 0 %commit -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Cogito ergo sum I think, therefore I am -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Dec 29 17:31:49 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 29 Dec 2017 17:31:49 +0100 Subject: How to batch generate ECC key In-Reply-To: References: Message-ID: <6d707b10-6364-b35c-49e6-40efb81ebb6f@sumptuouscapital.com> On 12/29/2017 04:53 PM, Rezart Qelibari f?r GnuPG wrote: > - How did you find out the protocol names, especially the upper case ?E? > of ?Ed25519? and that ?cv25519? is actually named ?Curve25519?? Although > ?gpg --expert --full-generate-key? correctly states ??Curve 25519?, ?gpg > -k? still yields ?cv25519?. I find this behaviour very strange and unwisely. The short answer is libgcrypt's cipher/ecc-curves.c , see line 45/46 for mapping of shortnames to OIDs. Now, I agree this should at least be case-insensitive, but there might be a feature request open for that already :) > > - Why do the algorithm ids (22 for ?Ed25519? and 18 for ?Curve25519?) > not work? Algorithm IDs are not directly tied to curves, so that would be more related to Key-Type than Key-Curve (and corresponding subkey), not the OIDs. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "If you are successful, you may win false friends and true enemies. Succeed anyway." (Mother Teresa) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupg-kontakt at rezart.qelibari.de Fri Dec 29 16:53:27 2017 From: gnupg-kontakt at rezart.qelibari.de (=?utf-8?Q?Rezart_Qelibari_f=C3=BCr_GnuPG?=) Date: Fri, 29 Dec 2017 16:53:27 +0100 Subject: How to batch generate ECC key In-Reply-To: References: Message-ID: Thank you so much! This did the trick! I am very impressed. I don?t want to bother you too much, but maybe you can answer me the two follow-up questions: - How did you find out the protocol names, especially the upper case ?E? of ?Ed25519? and that ?cv25519? is actually named ?Curve25519?? Although ?gpg --expert --full-generate-key? correctly states ??Curve 25519?, ?gpg -k? still yields ?cv25519?. I find this behaviour very strange and unwisely. - Why do the algorithm ids (22 for ?Ed25519? and 18 for ?Curve25519?) not work? In both cases I looked up both gpg and libgcrypt documentations and found no hint on that behaviour at all. On 29. December 2017 at 15:16:07, Kristian Fiskerstrand (kristian.fiskerstrand at sumptuouscapital.com) wrote: try: $ cat config.txt Key-Type: eddsa ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Dec 29 20:20:20 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Dec 2017 20:20:20 +0100 Subject: How to batch generate ECC key In-Reply-To: ("Rezart Qelibari =?utf-8?Q?f=C3=BCr?= GnuPG"'s message of "Fri, 29 Dec 2017 16:53:27 +0100") References: Message-ID: <87fu7tz6h7.fsf@wheatstone.g10code.de> On Fri, 29 Dec 2017 16:53, gnupg-kontakt at rezart.qelibari.de said: > Thank you so much! This did the trick! I am very impressed. I just added a mapping from the displayed names to the canonical names. Thus with the next release (2.2.5) "ed25519" and "cv25519" should work. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg-kontakt at rezart.qelibari.de Fri Dec 29 20:33:35 2017 From: gnupg-kontakt at rezart.qelibari.de (=?utf-8?Q?Rezart_Qelibari_f=C3=BCr_GnuPG?=) Date: Fri, 29 Dec 2017 20:33:35 +0100 Subject: How to batch generate ECC key In-Reply-To: <87fu7tz6h7.fsf@wheatstone.g10code.de> References: <87fu7tz6h7.fsf@wheatstone.g10code.de> Message-ID: ? Thank you Kristian for explaining and thank you Werner for implementing that so fast. You guys are awesome! On 29. December 2017 at 20:29:56, Werner Koch (wk at gnupg.org(mailto:wk at gnupg.org)) wrote: > Thus with the next release (2.2.5) "ed25519" and "cv25519" should work. From dkg at fifthhorseman.net Fri Dec 29 21:55:46 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 29 Dec 2017 15:55:46 -0500 Subject: How to batch generate ECC key In-Reply-To: References: Message-ID: <878tdli78t.fsf@fifthhorseman.net> On Fri 2017-12-29 01:18:27 +0100, Rezart Qelibari f?r GnuPG wrote: > I want to batch generate a key using an ECC algorithm using the following command: > > $ cat config.txt | gpg ?-batch ?generate-key for modern gnupg, i think what you want is: gpg --quick-gen-key 'alice ' ed25519 and then, taking the generated fingerprint as $FPR, do: gpg --quick-add-key $FPR cv25519 encrypt this is documented in the gpg(1) man page. Normally, i'd just have suggested to use just quick-gen-key's "futuredefault", but i just ran into: https://dev.gnupg.org/T3655 while testing, so i'm giving you the more complicated version here.. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From ben at adversary.org Fri Dec 29 22:24:39 2017 From: ben at adversary.org (Ben McGinnes) Date: Sat, 30 Dec 2017 08:24:39 +1100 Subject: GPGME Python bindings In-Reply-To: <20171228224958.GA7098@jasmine.lan> References: <20171228224958.GA7098@jasmine.lan> Message-ID: <20171229212439.t3b5bargbdnekcmw@adversary.org> On Thu, Dec 28, 2017 at 05:49:58PM -0500, Leo Famulari wrote: > Hello, > > I'm working on downstream packaging of GPGME and GPGME's Python > language bindings for GNU Guix. [0] Cool. > Because it was easier, we began packaging the GPGME Python bindings > based on the PyPi release [1] of version 1.8.0. > > However, since that time, GPGME has had a few more releases, but the > PyPi release has not been updated. Nor is it likely to be at the moment, PyPi is ... one of the least impressive aspects of Python, unfortunately. > How should we interpret this? Does it mean that we should continue to > package version 1.8.0 of Python bindings? Or should we try to build them > from the latest GPGME source release? The Python bindings are updated with each GPGME release and compiling GPGME should result in the current bindings being built and installed in the versions of Python 2 and 3 found on the system. IIRC the bindings with GPGME 1.8.0 used the module name of gpgme, that has since been changed to gpg. and current behaviour is very pythonic. For example, here's about the simplest clear signing method (using the default key of the user running the code): import gpg from gpg.constants.sig import mode with gpg.Context() as c: signed = c.sign(b"Test message", mode=mode.CLEAR) afile = open("filename.txt.asc", "wb") afile.write(signed) afile.close() Encryption and decryption don't require much more than that either. Yes, you can encrypt data as a class and then import that upon decryption if your intent is to securely store authentication tokens as part of something else. In fact, that's what prompted what led to these bindings being updated to Python 3 in the first place. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Sat Dec 30 13:32:07 2017 From: wk at gnupg.org (Werner Koch) Date: Sat, 30 Dec 2017 13:32:07 +0100 Subject: How to batch generate ECC key In-Reply-To: <878tdli78t.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 29 Dec 2017 15:55:46 -0500") References: <878tdli78t.fsf@fifthhorseman.net> Message-ID: <87lghkxupk.fsf@wheatstone.g10code.de> On Fri, 29 Dec 2017 21:55, dkg at fifthhorseman.net said: > gpg --quick-gen-key 'alice ' ed25519 I was about to suggest that as well but realized that there seems to be no well specified way to set a creation time with that method. I'll look after the other bug. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: