From bjk at luxsci.net Mon Aug 1 01:12:37 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Sun, 31 Jul 2016 19:12:37 -0400 Subject: [PATCH] Erase memory before freeing. Message-ID: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> * src/mem.h: New. * src/assuan-support.c (mem_item_s): New. (_gpgme_assuan_malloc_hooks): Replace to use tracking functions. (_gpgme_assuan_malloc): New. (_gpgme_assuan_realloc): Ditto. (_gpgme_assuan_free): Ditto. (free_locked): Ditto. (find_memlist_item): Ditto. * src/data-compat.c (gpgme_data_new_from_filepart): Wipe memory. * src/data-identify.c (gpgme_data_identify): Ditto. * src/data.c (_gpgme_data_release): Ditto. Signed-off-by: Ben Kibbey --- src/assuan-support.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++++-- src/data-compat.c | 11 +++- src/data-identify.c | 3 ++ src/data-mem.c | 6 ++- src/data.c | 5 ++ 5 files changed, 160 insertions(+), 6 deletions(-) diff --git a/src/assuan-support.c b/src/assuan-support.c index 745d2aa..7e27d1f 100644 --- a/src/assuan-support.c +++ b/src/assuan-support.c @@ -9,16 +9,151 @@ #include "assuan.h" #include "gpgme.h" +#include "sema.h" #include "ath.h" #include "priv-io.h" +#include "mem.h" #include "debug.h" +DEFINE_STATIC_LOCK (memlist_lock); + + +struct mem_item_s +{ + size_t size; + void *data; + struct mem_item_s *next; +}; + +static struct mem_item_s *memlist; + + +static struct mem_item_s * +find_memlist_item (void *p, int remove) +{ + struct mem_item_s *item, *last = NULL; + + for (item = memlist; item; item = item->next) + { + if (item->data == p) + { + if (remove) + { + if (last) + last->next = item->next; + else + memlist = item->next; + } + + break; + } + + last = item; + } + + return item; +} + + +static void +free_locked (void *p, int locked) +{ + struct mem_item_s *item; + + if (!locked) + LOCK (memlist_lock); + + item = find_memlist_item (p, 1); + assert (item); + + if (!locked) + UNLOCK (memlist_lock); + + wipememory (item->data, item->size); + free (item->data); + free (item); +} + + +static void +_gpgme_assuan_free (void *p) +{ + if (!p) + return; + + free_locked (p, 0); +} + + +static void * +_gpgme_assuan_malloc (size_t n) +{ + struct mem_item_s *item; + void *p; + + p = malloc (n); + if (!p) + return NULL; + + item = malloc (sizeof (struct mem_item_s)); + if (!item) + { + int e = errno; + free (p); + errno = e; + return NULL; + } + + item->data = p; + item->size = n; + LOCK (memlist_lock); + item->next = memlist; + memlist = item; + UNLOCK (memlist_lock); + return item->data; +} + + +static void * +_gpgme_assuan_realloc (void *p, size_t n) +{ + struct mem_item_s *item; + struct mem_item_s *newitem; + void *tmp; + + LOCK (memlist_lock); + item = find_memlist_item (p, 0); + if (!item) + { + UNLOCK (memlist_lock); + return _gpgme_assuan_malloc (n); + } + + tmp = _gpgme_assuan_malloc (n); + if (tmp) + newitem = find_memlist_item (tmp, 0); + else + { + int e = errno; + UNLOCK (memlist_lock); + errno = e; + return NULL; + } + + assert (newitem); + memcpy (newitem->data, item->data, + newitem->size < item->size ? newitem->size : item->size); + free_locked (item->data, 1); + UNLOCK (memlist_lock); + return newitem->data; +} + struct assuan_malloc_hooks _gpgme_assuan_malloc_hooks = { - malloc, - realloc, - free + _gpgme_assuan_malloc, + _gpgme_assuan_realloc, + _gpgme_assuan_free }; diff --git a/src/data-compat.c b/src/data-compat.c index ec80172..44a2b94 100644 --- a/src/data-compat.c +++ b/src/data-compat.c @@ -33,6 +33,7 @@ #include "data.h" #include "util.h" +#include "mem.h" #include "debug.h" @@ -92,7 +93,10 @@ gpgme_data_new_from_filepart (gpgme_data_t *r_dh, const char *fname, { int saved_err = gpg_error_from_syserror (); if (buf) - free (buf); + { + wipememory (buf, length); + free (buf); + } if (fname) fclose (stream); return TRACE_ERR (saved_err); @@ -105,7 +109,10 @@ gpgme_data_new_from_filepart (gpgme_data_t *r_dh, const char *fname, if (err) { if (buf) - free (buf); + { + wipememory (buf, length); + free (buf); + } return err; } diff --git a/src/data-identify.c b/src/data-identify.c index 88a472f..8b41395 100644 --- a/src/data-identify.c +++ b/src/data-identify.c @@ -28,6 +28,7 @@ #include "data.h" #include "util.h" #include "parsetlv.h" +#include "mem.h" /* The size of the sample data we take for detection. */ @@ -496,12 +497,14 @@ gpgme_data_identify (gpgme_data_t dh, int reserved) n = gpgme_data_read (dh, sample, SAMPLE_SIZE - 1); if (n < 0) { + wipememory (sample, SAMPLE_SIZE); free (sample); return GPGME_DATA_TYPE_INVALID; /* Ooops. */ } sample[n] = 0; /* (Required for our string functions.) */ result = basic_detection (sample, n); + wipememory (sample, SAMPLE_SIZE); free (sample); gpgme_data_seek (dh, off, SEEK_SET); diff --git a/src/data-mem.c b/src/data-mem.c index a498b82..4fe871a 100644 --- a/src/data-mem.c +++ b/src/data-mem.c @@ -32,6 +32,7 @@ #include "data.h" #include "util.h" +#include "mem.h" #include "debug.h" @@ -151,7 +152,10 @@ static void mem_release (gpgme_data_t dh) { if (dh->data.mem.buffer) - free (dh->data.mem.buffer); + { + wipememory (dh->data.mem.buffer, dh->data.mem.size); + free (dh->data.mem.buffer); + } } diff --git a/src/data.c b/src/data.c index 87b619e..1b8aacc 100644 --- a/src/data.c +++ b/src/data.c @@ -34,6 +34,7 @@ #include "util.h" #include "ops.h" #include "priv-io.h" +#include "mem.h" #include "debug.h" @@ -65,6 +66,8 @@ _gpgme_data_release (gpgme_data_t dh) if (dh->file_name) free (dh->file_name); + + wipememory (dh->pending, sizeof (dh->pending)); free (dh); } @@ -275,6 +278,8 @@ _gpgme_data_inbound_handler (void *opaque, int fd) buflen -= amt; } while (buflen > 0); + + wipememory (buffer, sizeof (buffer)); return TRACE_ERR (0); } -- 2.8.1 From justus at g10code.com Mon Aug 1 12:15:31 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 01 Aug 2016 12:15:31 +0200 Subject: [PATCH] Erase memory before freeing. In-Reply-To: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> References: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> Message-ID: <87oa5cokvw.fsf@europa.jade-hamburg.de> Hi :) Ben Kibbey writes: > * src/mem.h: New. Looks like you forgot to add this file. > * src/assuan-support.c (mem_item_s): New. > (_gpgme_assuan_malloc_hooks): Replace to use tracking functions. > (_gpgme_assuan_malloc): New. > (_gpgme_assuan_realloc): Ditto. > (_gpgme_assuan_free): Ditto. > (free_locked): Ditto. > (find_memlist_item): Ditto. > * src/data-compat.c (gpgme_data_new_from_filepart): Wipe memory. > * src/data-identify.c (gpgme_data_identify): Ditto. > * src/data.c (_gpgme_data_release): Ditto. > > Signed-off-by: Ben Kibbey > --- > src/assuan-support.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++++-- > src/data-compat.c | 11 +++- > src/data-identify.c | 3 ++ > src/data-mem.c | 6 ++- > src/data.c | 5 ++ > 5 files changed, 160 insertions(+), 6 deletions(-) [...] > +static struct mem_item_s *memlist; I wonder if a list is the right data structure. Linear lookup time feels expensive. [...] > +static void * > +_gpgme_assuan_malloc (size_t n) > +{ > + struct mem_item_s *item; > + void *p; > + > + p = malloc (n); > + if (!p) > + return NULL; > + > + item = malloc (sizeof (struct mem_item_s)); I'd suggest to allocate both in one chunk. That makes the error handling simpler, decreases pressure on the allocator and increases locality. > + if (!item) > + { > + int e = errno; > + free (p); > + errno = e; > + return NULL; > + } > + > + item->data = p; > + item->size = n; > + LOCK (memlist_lock); > + item->next = memlist; > + memlist = item; > + UNLOCK (memlist_lock); > + return item->data; > +} > + > + > +static void * > +_gpgme_assuan_realloc (void *p, size_t n) > +{ > + struct mem_item_s *item; > + struct mem_item_s *newitem; > + void *tmp; > + > + LOCK (memlist_lock); > + item = find_memlist_item (p, 0); > + if (!item) I'm confused, shouldn't that be if (p == NULL) return _gpgme_assuan_malloc (n); item = find_memlist_item (p, 0); assert (item); instead ? > + { > + UNLOCK (memlist_lock); > + return _gpgme_assuan_malloc (n); > + } > + > + tmp = _gpgme_assuan_malloc (n); Can't we just use realloc here? And if not for some reason, please don't look newitem up like this, instead create a variant of _gpgme_assuan_malloc that returns the item. > + if (tmp) > + newitem = find_memlist_item (tmp, 0); > + else > + { > + int e = errno; > + UNLOCK (memlist_lock); > + errno = e; > + return NULL; > + } > + > + assert (newitem); > + memcpy (newitem->data, item->data, > + newitem->size < item->size ? newitem->size : item->size); > + free_locked (item->data, 1); > + UNLOCK (memlist_lock); > + return newitem->data; > +} Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Aug 1 16:40:21 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 01 Aug 2016 10:40:21 -0400 Subject: [PATCH] Erase memory before freeing. In-Reply-To: <87oa5cokvw.fsf@europa.jade-hamburg.de> References: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> <87oa5cokvw.fsf@europa.jade-hamburg.de> Message-ID: <878twgft7u.fsf@alice.fifthhorseman.net> On Mon 2016-08-01 06:15:31 -0400, Justus Winter wrote: >> + { >> + UNLOCK (memlist_lock); >> + return _gpgme_assuan_malloc (n); >> + } >> + >> + tmp = _gpgme_assuan_malloc (n); > > Can't we just use realloc here? And if not for some reason, please > don't look newitem up like this, instead create a variant of > _gpgme_assuan_malloc that returns the item. I assume the concern about realloc is that it might copy the memory to a new location, freeing the old memory without wiping it first. --dkg From bernhard at intevation.de Mon Aug 1 17:45:34 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 1 Aug 2016 17:45:34 +0200 Subject: test key for problem reporting (rsa2048)? Message-ID: <201608011745.39016.bernhard@intevation.de> Hi! To get good error reports it is sometimes nice to have the user use a well known keypair where the secret key is known. I've been poking around on git.gnupg.org/gnupg.git master [1] finding such a key which should be standard default (rsa2048, with passphrase, readable by gpg1 gpg20 an gpg21 in an easy way) What is my best choice for this? I've looked at some options: tests/openpgp/secdemo.asc tests/openpgp/secring.asc only have 1024 keys. tests/openpgp/samplekeys/ rsa-rsa-sample-1.asc does not have the secret key right there (where is it?) silent-running.asc has a number of keys one is 2048. Drawback is that someone needs to import several ones. Best, Bernhard [1] rev40365b28c3fdf087fd58401f5a6f42f9d7d29d20 -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Mon Aug 1 17:56:20 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 1 Aug 2016 17:56:20 +0200 Subject: dirmngr: Wrong certificate error? In-Reply-To: <465ea677-4619-b326-b944-3c36236819ac@enigmail.net> References: <465ea677-4619-b326-b944-3c36236819ac@enigmail.net> Message-ID: <201608011756.23997.bernhard@intevation.de> Am Samstag, 16. Juli 2016 15:44:47 schrieb Patrick Brunschwig: > This gave me the error "TLS connection authentication failed: General > error" | dirmngr[53927.0]: TLS verification of peer failed: The certificate is NOT | trusted. The certificate issuer is unknown. | dirmngr[53927.0]: TLS verification of peer failed: hostname does not match seems to come from the code calling GNUTLS. Can you do a TLS connection to keys.mailvelope.com with gnutls-cli? -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Mon Aug 1 20:09:00 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 01 Aug 2016 14:09:00 -0400 Subject: thank you to Justus for the GnuPG test suite Message-ID: <87ziowe4zn.fsf@alice.fifthhorseman.net> i just wanted to send a public "thank you" to Justus Winter for his ongoing work on the GnuPG test suite. Any test suite for complex software is never complete, but it is an excellent bulwark against regression, and a boon to bootstrapping the project to new architectures with confidence. Justus's practice of resolving bugs by including counterexamples in the test suite to ensure future failures are caught at build time is really valuable. This is important work that is sometimes tedious and often thankless, but it makes a real difference. Thanks, Justus! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From patrick at enigmail.net Mon Aug 1 21:34:01 2016 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 1 Aug 2016 21:34:01 +0200 Subject: dirmngr: Wrong certificate error? In-Reply-To: <201608011756.23997.bernhard@intevation.de> References: <465ea677-4619-b326-b944-3c36236819ac@enigmail.net> <201608011756.23997.bernhard@intevation.de> Message-ID: <34631fe7-77ed-d0be-9978-fd452e765c70@enigmail.net> On 01.08.16 17:56, Bernhard Reiter wrote: > Am Samstag, 16. Juli 2016 15:44:47 schrieb Patrick Brunschwig: >> This gave me the error "TLS connection authentication failed: General >> error" > > | dirmngr[53927.0]: TLS verification of peer failed: The certificate is NOT > | trusted. The certificate issuer is unknown. > | dirmngr[53927.0]: TLS verification of peer failed: hostname does not match > > seems to come from the code calling GNUTLS. > Can you do a TLS connection to keys.mailvelope.com > with gnutls-cli? It looks like gnutls-cli is not successful (see below). How can the root certificates be added to gnutls (and dirmngr)? Error setting the x509 trust file Resolving 'keys.mailvelope.com:443'... Connecting to '52.208.40.58:443'... - Certificate type: X.509 - Got a certificate list of 4 certificates. - Certificate[0] info: - subject `CN=keys.mailvelope.com', issuer `C=US,O=Amazon,OU=Server CA 1B,CN=Amazon', RSA key 2048 bits, signed using RSA-SHA256, activated `2016-06-07 00:00:00 UTC', expires `2017-07-07 12:00:00 UTC', SHA-1 fingerprint `ca8f102975140402d7a63f4a7133044a52662db4' Public Key ID: 79229670c9c21919fc91824ff1f5effa4992866f Public key's random art: +--[ RSA 2048]----+ | o++ .. | | ..==oo . | | o=o=. . | | .+.. . . | | + S . . | | . . + o | | . + o | | oE+ . | | .o.o | +-----------------+ - Certificate[1] info: - subject `C=US,O=Amazon,OU=Server CA 1B,CN=Amazon', issuer `C=US,O=Amazon,CN=Amazon Root CA 1', RSA key 2048 bits, signed using RSA-SHA256, activated `2015-10-22 00:00:00 UTC', expires `2025-10-19 00:00:00 UTC', SHA-1 fingerprint `917e732d330f9a12404f73d8bea36948b929dffc' - Certificate[2] info: - subject `C=US,O=Amazon,CN=Amazon Root CA 1', issuer `C=US,ST=Arizona,L=Scottsdale,O=Starfield Technologies\, Inc.,CN=Starfield Services Root Certificate Authority - G2', RSA key 2048 bits, signed using RSA-SHA256, activated `2015-05-25 12:00:00 UTC', expires `2037-12-31 01:00:00 UTC', SHA-1 fingerprint `06b25927c42a721631c1efd9431e648fa62e1e39' - Certificate[3] info: - subject `C=US,ST=Arizona,L=Scottsdale,O=Starfield Technologies\, Inc.,CN=Starfield Services Root Certificate Authority - G2', issuer `C=US,O=Starfield Technologies\, Inc.,OU=Starfield Class 2 Certification Authority', RSA key 2048 bits, signed using RSA-SHA256, activated `2009-09-02 00:00:00 UTC', expires `2034-06-28 17:39:16 UTC', SHA-1 fingerprint `9e99a48a9960b14926bb7f3b02e22da2b0ab7280' - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed GnuTLS error: Error in the certificate. -Patrick From dkg at fifthhorseman.net Mon Aug 1 22:33:26 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 01 Aug 2016 16:33:26 -0400 Subject: dirmngr: Wrong certificate error? In-Reply-To: <34631fe7-77ed-d0be-9978-fd452e765c70@enigmail.net> References: <465ea677-4619-b326-b944-3c36236819ac@enigmail.net> <201608011756.23997.bernhard@intevation.de> <34631fe7-77ed-d0be-9978-fd452e765c70@enigmail.net> Message-ID: <87wpk0dyax.fsf@alice.fifthhorseman.net> On Mon 2016-08-01 15:34:01 -0400, Patrick Brunschwig wrote: > How can the root certificates be added to gnutls (and dirmngr)? see my initial proposal here: https://lists.gnupg.org/pipermail/gnupg-devel/2016-July/031372.html I've just opened this as: https://bugs.gnupg.org/gnupg/issue2433 fwiw, your gnutls-cli invocation's output looks like: > Error setting the x509 trust file > Resolving 'keys.mailvelope.com:443'... > Connecting to '52.208.40.58:443'... > - Certificate type: X.509 but "gnutls-cli keys.mailvelope.com" works for me, so i suspect you have something misconfigured with your gnutls installation. i see the start of the output as: > Processed 151 CA certificate(s). > Resolving 'keys.mailvelope.com'... > Connecting to '52.208.40.58:443'... > - Certificate type: X.509 maybe you need to look at the system-level trust store on your gnutls installation? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From bjk at luxsci.net Tue Aug 2 01:41:23 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Mon, 1 Aug 2016 19:41:23 -0400 Subject: [PATCH] Erase memory before freeing. In-Reply-To: <87oa5cokvw.fsf@europa.jade-hamburg.de> References: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> <87oa5cokvw.fsf@europa.jade-hamburg.de> Message-ID: <1470094922-8336086.34567908.fu71NfNvA017971@rs146.luxsci.com> On Mon, Aug 01, 2016 at 12:15:31PM +0200, Justus Winter wrote: > Hi :) > > Ben Kibbey writes: > > > * src/mem.h: New. > > Looks like you forgot to add this file. Sure did. Oops. :) > > +static struct mem_item_s *memlist; > > I wonder if a list is the right data structure. Linear lookup time > feels expensive. I thought this too. I haven't done any benchmarks but the list is prepended to so it comforms with most de/allocations as LIFO. I also don't khow how else to do it without requiring a realloc of a mem_item_s which would corrupt pointers for .next. Any ideas? > > + p = malloc (n); > > + if (!p) > > + return NULL; > > + > > + item = malloc (sizeof (struct mem_item_s)); > > I'd suggest to allocate both in one chunk. That makes the error handling > simpler, decreases pressure on the allocator and increases locality. See above. > > + LOCK (memlist_lock); > > + item = find_memlist_item (p, 0); > > + if (!item) > > I'm confused, shouldn't that be > > if (p == NULL) return _gpgme_assuan_malloc (n); > item = find_memlist_item (p, 0); > assert (item); > > instead ? Yes. Thanks! > > > + { > > + UNLOCK (memlist_lock); > > + return _gpgme_assuan_malloc (n); > > + } > > + > > + tmp = _gpgme_assuan_malloc (n); > > Can't we just use realloc here? And if not for some reason, please > don't look newitem up like this, instead create a variant of > _gpgme_assuan_malloc that returns the item. Needed to wipe item->data. Not sure how to do both wiping item->data and realloc'ing. Attached is the revised patch. Suggestions welcome. Also, Werner mentioned some time ago he'd like to add allocaters to gpg-error to replace the "hooks" in libassuan and others. Not sure if anyone has started that or not. Thanks for the review. -- Ben Kibbey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Erase-memory-before-freeing.patch Type: text/x-diff Size: 7658 bytes Desc: not available URL: From bjk at luxsci.net Tue Aug 2 03:25:32 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Mon, 1 Aug 2016 21:25:32 -0400 Subject: [PATCH] Fix ncurses build. Message-ID: <1470101163-7571789.8718608.fu721PXc3032193@rs146.luxsci.com> * pinentry/Makefile.am: Add NCURSES_CFLAGS. Signed-off-by: Ben Kibbey --- pinentry/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/pinentry/Makefile.am b/pinentry/Makefile.am index be99822..a99f12e 100644 --- a/pinentry/Makefile.am +++ b/pinentry/Makefile.am @@ -41,3 +41,4 @@ AM_CPPFLAGS = $(COMMON_CFLAGS) -I$(top_srcdir)/secmem libpinentry_a_SOURCES = pinentry.h pinentry.c argparse.c argparse.h \ password-cache.h password-cache.c $(pinentry_emacs_sources) libpinentry_curses_a_SOURCES = pinentry-curses.h pinentry-curses.c +libpinentry_curses_a_CFLAGS = @NCURSES_CFLAGS@ -- 2.8.1 From dkg at fifthhorseman.net Tue Aug 2 04:19:17 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 1 Aug 2016 22:19:17 -0400 Subject: [PATCH 3/3] more cleanup of "allow to" In-Reply-To: <1470104357-1074-1-git-send-email-dkg@fifthhorseman.net> References: <1470104357-1074-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1470104357-1074-3-git-send-email-dkg@fifthhorseman.net> * README, agent/command.c, agent/keyformat.txt, common/i18n.c, common/iobuf.c, common/keyserver.h, dirmngr/cdblib.c, dirmngr/ldap-wrapper.c, doc/DETAILS, doc/TRANSLATE, doc/announce-2.1.txt, doc/gpg.texi, doc/gpgsm.texi, doc/scdaemon.texi, doc/tools.texi, doc/whats-new-in-2.1.txt, g10/export.c, g10/getkey.c, g10/import.c, g10/keyedit.c, m4/ksba.m4, m4/libgcrypt.m4, m4/ntbtls.m4, po/ca.po, po/cs.po, po/da.po, po/de.po, po/el.po, po/eo.po, po/es.po, po/et.po, po/fi.po, po/fr.po, po/gl.po, po/hu.po, po/id.po, po/it.po, po/ja.po, po/nb.po, po/pl.po, po/pt.po, po/ro.po, po/ru.po, po/sk.po, po/sv.po, po/tr.po, po/uk.po, po/zh_CN.po, po/zh_TW.po, scd/app-p15.c, scd/ccid-driver.c, scd/command.c, sm/gpgsm.c, sm/sign.c, tools/gpgconf-comp.c, tools/gpgtar.h: replace "Allow to" with clearer text. In standard English, the normal construction is "${XXX} allows ${YYY} to" -- that is, the subject (${XXX}) of the sentence is allowing the object (${YYY}) to do something. When the object is missing, the phrasing sounds awkward, even if the object is implied by context. There's almost always a better construction that isn't as awkward. These changes should make the language a bit clearer. Signed-off-by: Daniel Kahn Gillmor --- README | 13 +++++++------ agent/command.c | 2 +- agent/keyformat.txt | 2 +- common/i18n.c | 6 +++--- common/iobuf.c | 2 +- common/keyserver.h | 4 ++-- dirmngr/cdblib.c | 2 +- dirmngr/ldap-wrapper.c | 4 ++-- doc/DETAILS | 4 ++-- doc/TRANSLATE | 4 ++-- doc/announce-2.1.txt | 8 ++++---- doc/gpg.texi | 2 +- doc/gpgsm.texi | 4 ++-- doc/scdaemon.texi | 10 +++++----- doc/tools.texi | 8 ++++---- doc/whats-new-in-2.1.txt | 2 +- g10/export.c | 2 +- g10/getkey.c | 2 +- g10/import.c | 2 +- g10/keyedit.c | 2 +- m4/ksba.m4 | 6 +++--- m4/libgcrypt.m4 | 6 +++--- m4/ntbtls.m4 | 8 ++++---- po/ca.po | 2 +- po/cs.po | 2 +- po/da.po | 2 +- po/de.po | 2 +- po/el.po | 2 +- po/eo.po | 2 +- po/es.po | 2 +- po/et.po | 2 +- po/fi.po | 2 +- po/fr.po | 2 +- po/gl.po | 2 +- po/hu.po | 2 +- po/id.po | 2 +- po/it.po | 2 +- po/ja.po | 2 +- po/nb.po | 2 +- po/pl.po | 2 +- po/pt.po | 2 +- po/ro.po | 2 +- po/ru.po | 2 +- po/sk.po | 2 +- po/sv.po | 2 +- po/tr.po | 2 +- po/uk.po | 2 +- po/zh_CN.po | 2 +- po/zh_TW.po | 2 +- scd/app-p15.c | 4 ++-- scd/ccid-driver.c | 2 +- scd/command.c | 2 +- sm/gpgsm.c | 4 ++-- sm/sign.c | 2 +- tools/gpgconf-comp.c | 4 ++-- tools/gpgtar.h | 2 +- 56 files changed, 89 insertions(+), 88 deletions(-) diff --git a/README b/README index 224db30..bb5cbef 100644 --- a/README +++ b/README @@ -9,15 +9,16 @@ * INTRODUCTION GnuPG is a complete and free implementation of the OpenPGP standard - as defined by RFC4880 (also known 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. + as defined by RFC4880 (also known as PGP). GnuPG enables encryption + and signing of data and communication, and features a versatile key + management system as well as access modules for public key + directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend - applications and libraries making use of GnuPG are available. Since - version 2 GnuPG provides support for S/MIME and Secure Shell in - addition to OpenPGP. + applications and libraries are available that make use of GnuPG. + Since version 2 GnuPG provides support for S/MIME and Secure Shell + in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the diff --git a/agent/command.c b/agent/command.c index e5d2268..1803b5f 100644 --- a/agent/command.c +++ b/agent/command.c @@ -3043,7 +3043,7 @@ io_monitor (assuan_context_t ctx, void *hook, int direction, (void) hook; - /* Note that we only check for the uppercase name. This allows to + /* Note that we only check for the uppercase name. This allows the user to see the logging for debugging if using a non-upercase command name. */ if (ctx && direction == ASSUAN_IO_FROM_PEER diff --git a/agent/keyformat.txt b/agent/keyformat.txt index c1a59ce..ddfb44b 100644 --- a/agent/keyformat.txt +++ b/agent/keyformat.txt @@ -324,7 +324,7 @@ similar to the private-key storage format. This is a master passphrase format where each file may protect several secrets under one master passphrase. It is possible to have several of those files each protected by a dedicated master passphrase. Clear text keywords -allow to list the available protected passphrases. +allow listing the available protected passphrases. The name of the files with these protected secrets have this form: pw-.dat. STRING may be an arbitrary string, as a default name diff --git a/common/i18n.c b/common/i18n.c index 39e3d8f..413fa9a 100644 --- a/common/i18n.c +++ b/common/i18n.c @@ -156,9 +156,9 @@ i18n_utf8 (const char *string) } -/* A variant of gettext which allows to specify the local to use for - translating the message. The function assumes that utf-8 is used - for the encoding. */ +/* A variant of gettext which allows the programmer to specify the + locale to use for translating the message. The function assumes + that utf-8 is used for the encoding. */ const char * i18n_localegettext (const char *lc_messages, const char *string) { diff --git a/common/iobuf.c b/common/iobuf.c index 9d582ca..06d0b61 100644 --- a/common/iobuf.c +++ b/common/iobuf.c @@ -1198,7 +1198,7 @@ iobuf_cancel (iobuf_t a) #if defined(HAVE_W32_SYSTEM) || defined(__riscos__) if (remove_name) { - /* Argg, MSDOS does not allow to remove open files. So + /* Argg, MSDOS does not allow removing open files. So * we have to do it here */ #ifdef HAVE_W32CE_SYSTEM wchar_t *wtmp = utf8_to_wchar (remove_name); diff --git a/common/keyserver.h b/common/keyserver.h index 63dbde6..200378d 100644 --- a/common/keyserver.h +++ b/common/keyserver.h @@ -48,8 +48,8 @@ /* Must be 127 due to shell internal magic. */ #define KEYSERVER_SCHEME_NOT_FOUND 127 -/* Object to hold information pertaining to a keyserver; it further - allows to build a list of keyservers. Note that g10/options.h has +/* Object to hold information pertaining to a keyserver; it also + allows building a list of keyservers. Note that g10/options.h has a typedef for this. FIXME: We should make use of the parse_uri_t. */ struct keyserver_spec diff --git a/dirmngr/cdblib.c b/dirmngr/cdblib.c index 23cb317..52c17c9 100644 --- a/dirmngr/cdblib.c +++ b/dirmngr/cdblib.c @@ -296,7 +296,7 @@ cdb_find(struct cdb *cdbp, const void *key, cdbi_t klen) /* Sequential-find routines that used separate structure. It is possible to have many than one record with the same key in a - database, and these routines allows to enumerate all them. + database, and these routines allow enumeration of all of them. cdb_findinit() initializes search structure pointed to by cdbfp. It will return negative value on error or 0 on success. cdb_find? next() attempts to find next matching key, setting value position diff --git a/dirmngr/ldap-wrapper.c b/dirmngr/ldap-wrapper.c index 55fcd8b..5fa3eac 100644 --- a/dirmngr/ldap-wrapper.c +++ b/dirmngr/ldap-wrapper.c @@ -545,8 +545,8 @@ reader_callback (void *cb_value, char *buffer, size_t count, size_t *nread) if (!buffer && !count && !nread) return -1; /* Rewind is not supported. */ - /* If we ever encountered a read error don't allow to continue and - possible overwrite the last error cause. Bail out also if the + /* If we ever encountered a read error, don't continue (we don't want to + possibly overwrite the last error cause). Bail out also if the file descriptor has been closed. */ if (ctx->fd_error || ctx->fd == -1) { diff --git a/doc/DETAILS b/doc/DETAILS index 4b3f0af..02f9bad 100644 --- a/doc/DETAILS +++ b/doc/DETAILS @@ -913,8 +913,8 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB: *** FAILURE This is the counterpart to SUCCESS and used to indicate a program - failure. It is used similar to ISO-C's EXIT_FAILURE but allows to - convey more information, in particular an gpg-error error code. + failure. It is used similar to ISO-C's EXIT_FAILURE but allows + conveying more information, in particular a gpg-error error code. That numerical error code may optionally have a suffix made of an underscore and a string with an error symbol like "151011327_EOF". A dash may be used instead of . diff --git a/doc/TRANSLATE b/doc/TRANSLATE index 2a20aad..eb0de97 100644 --- a/doc/TRANSLATE +++ b/doc/TRANSLATE @@ -23,8 +23,8 @@ Help files GnuPG provides a little help feature (entering a ? on a prompt). This help used to be translated the usual way with gettext but it turned -out that this is too inflexible and does for example not allow to -correct little mistakes in the English text. For some newer features +out that this is too inflexible and does for example not allow +correcting little mistakes in the English text. For some newer features we require editable help files anyway and thus the existing help strings have been moved to plain text files names "help.LL.txt". We distribute these files and allow overriding them by files of that name diff --git a/doc/announce-2.1.txt b/doc/announce-2.1.txt index e165332..8c35e53 100644 --- a/doc/announce-2.1.txt +++ b/doc/announce-2.1.txt @@ -6,13 +6,13 @@ new release: Version 2.1.0. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. -GnuPG, also known as GPG, allows to encrypt and sign data and +GnuPG, also known as GPG, enables encryption and signing of data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. -A wealth of frontend applications and libraries making use of GnuPG -are available. Since version 2 GnuPG provides support for S/MIME and -Secure Shell in addition to OpenPGP. +A wealth of frontend applications and libraries are available that +make use of GnuPG. Since version 2 GnuPG provides support for S/MIME +and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU diff --git a/doc/gpg.texi b/doc/gpg.texi index 3be401f..4d6a261 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2357,7 +2357,7 @@ obsolete; it does not harm to use it though. Revert to the pre-2.1 public key list mode. This only affects the human readable output and not the machine interface (i.e. @code{--with-colons}). Note that the legacy format does not -allow to convey suitable information for elliptic curves. +convey suitable information for elliptic curves. @item --with-fingerprint @opindex with-fingerprint diff --git a/doc/gpgsm.texi b/doc/gpgsm.texi index 2f6c297..dae26b2 100644 --- a/doc/gpgsm.texi +++ b/doc/gpgsm.texi @@ -636,7 +636,7 @@ algorithm than actually used. @command{gpgsm} uses a one-pass data processing model and thus needs to rely on the announced digest algorithms to properly hash the data. As a workaround this option may be used to tell gpg to also hash the data using the algorithm - at var{name}; this slows processing down a little bit but allows to verify + at var{name}; this slows processing down a little bit but allows verification of such broken signatures. If @command{gpgsm} prints an error like ``digest algo 8 has not been enabled'' you may want to try this option, with @samp{SHA256} for @var{name}. @@ -1479,7 +1479,7 @@ GETAUDITLOG [--data] [--html] If @option{--data} is used, the audit log is send using D-lines instead of being sent to the file descriptor given by an OUTPUT -command. If @option{--html} is used, the output is formated as an +command. If @option{--html} is used, the output is formatted as an XHTML block. This is designed to be incorporated into a HTML document. diff --git a/doc/scdaemon.texi b/doc/scdaemon.texi index 5e53223..c145814 100644 --- a/doc/scdaemon.texi +++ b/doc/scdaemon.texi @@ -258,7 +258,7 @@ deprecated; it may be removed in future releases. @item --disable-ccid @opindex disable-ccid Disable the integrated support for CCID compliant readers. This -allows to fall back to one of the other drivers even if the internal +allows falling back to one of the other drivers even if the internal CCID driver can handle the reader. Note, that CCID support is only available if libusb was available at build time. @@ -284,10 +284,10 @@ To get a list of available CCID readers you may use this command: If @var{n} is not 0 and no client is actively using the card, the card will be powered down after @var{n} seconds. Powering down the card avoids a potential risk of damaging a card when used with certain -cheap readers. This also allows non Scdaemon aware applications to -access the card. The disadvantage of using a card timeout is that -accessing the card takes longer and that the user needs to enter the -PIN again after the next power up. +cheap readers. This also allows applications that are not aware of +Scdaemon to access the card. The disadvantage of using a card timeout +is that accessing the card takes longer and that the user needs to +enter the PIN again after the next power up. Note that with the current version of Scdaemon the card is powered down immediately at the next timer tick for any value of @var{n} other diff --git a/doc/tools.texi b/doc/tools.texi index e52d6a7..d6cf56e 100644 --- a/doc/tools.texi +++ b/doc/tools.texi @@ -234,7 +234,7 @@ commit the changes. @command{gpgconf} provides the backend of a configuration editor. The configuration editor would usually be a graphical user interface -program, that allows to display the current options, their default +program that displays the current options, their default values, and allows the user to make changes to the options. These changes can then be made active with @command{gpgconf} again. Such a program that uses @command{gpgconf} in this way will be called GUI @@ -999,9 +999,9 @@ This script is a wrapper around @command{gpgconf} to run it with the command @code{--apply-defaults} for all real users with an existing GnuPG home directory. Admins might want to use this script to update he GnuPG configuration files for all users after - at file{/etc/gnupg/gpgconf.conf} has been changed. This allows to enforce -certain policies for all users. Note, that this is not a bulletproof of -forcing a user to use certain options. A user may always directly edit + at file{/etc/gnupg/gpgconf.conf} has been changed. This allows enforcing +certain policies for all users. Note, that this is not a bulletproof way to +force a user to use certain options. A user may always directly edit the configuration files and bypass gpgconf. @noindent diff --git a/doc/whats-new-in-2.1.txt b/doc/whats-new-in-2.1.txt index dd29c66..19ed8b9 100644 --- a/doc/whats-new-in-2.1.txt +++ b/doc/whats-new-in-2.1.txt @@ -540,7 +540,7 @@ https://gnupg.org/faq/whats-new-in-2.1.html key id matching the key id of another key. Importing a key with a long key id already used by another key in gpg???s local key store was not possible due to checks done on import. Now, if the ???wrong??? key - has been imported first /gpg/ would not allow to later import the + has been imported first /gpg/ would not allow later import of the second ???correct??? key. This problem has been fixed in 2.1 by allowing the import and by doing trial verification against all matching keys. diff --git a/g10/export.c b/g10/export.c index 92235fb..8c15868 100644 --- a/g10/export.c +++ b/g10/export.c @@ -1925,7 +1925,7 @@ do_export_stream (ctrl_t ctrl, iobuf_t out, strlist_t users, int secret, continue; } - /* The agent does not yet allow to export v3 packets. It is + /* The agent does not yet allow export of v3 packets. It is actually questionable whether we should allow them at all. */ if (pk->version == 3) diff --git a/g10/getkey.c b/g10/getkey.c index 3fe8274..90083ba 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -2514,7 +2514,7 @@ merge_selfsigs_main (KBNODE keyblock, int *r_revoked, else if ((IS_UID_SIG (sig) || IS_UID_REV (sig)) && sig->timestamp >= sigdate) { - /* Note: we allow to invalidate cert revocations + /* Note: we allow invalidation of cert revocations * by a newer signature. An attacker can't use this * because a key should be revoked with a key revocation. * The reason why we have to allow for that is that at diff --git a/g10/import.c b/g10/import.c index b83f371..3c7edd7 100644 --- a/g10/import.c +++ b/g10/import.c @@ -2020,7 +2020,7 @@ import_secret_one (ctrl_t ctrl, kbnode_t keyblock, #ifdef ENABLE_SELINUX_HACKS if (1) { - /* We don't allow to import secret keys because that may be used + /* We don't allow importing secret keys because that may be used to put a secret key into the keyring and the user might later be tricked into signing stuff with that key. */ log_error (_("importing secret keys not allowed\n")); diff --git a/g10/keyedit.c b/g10/keyedit.c index 9ebd643..4c833f8 100644 --- a/g10/keyedit.c +++ b/g10/keyedit.c @@ -1338,7 +1338,7 @@ sign_uids (ctrl_t ctrl, estream_t fp, } /* Fixme: see whether there is a revocation in which - * case we should allow to sign it again. */ + * case we should allow signing it again. */ if (!node->pkt->pkt.signature->flags.exportable && local) tty_fprintf ( fp, _("\"%s\" was already locally signed by key %s\n"), diff --git a/m4/ksba.m4 b/m4/ksba.m4 index 73b2e26..3e14e67 100644 --- a/m4/ksba.m4 +++ b/m4/ksba.m4 @@ -13,11 +13,11 @@ dnl AM_PATH_KSBA([MINIMUM-VERSION, dnl [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]]) dnl Test for libksba and define KSBA_CFLAGS and KSBA_LIBS -dnl MINIMUN-VERSION is a string with the version number optionalliy prefixed +dnl MINIMUM-VERSION is a string with the version number optionalliy prefixed dnl with the API version to also check the API compatibility. Example: -dnl a MINIMUN-VERSION of 1:1.0.7 won't pass the test unless the installed +dnl a MINIMUM-VERSION of 1:1.0.7 won't pass the test unless the installed dnl version of libksba is at least 1.0.7 *and* the API number is 1. Using -dnl this features allows to prevent build against newer versions of libksba +dnl this feature prevents building against newer versions of libksba dnl with a changed API. dnl AC_DEFUN([AM_PATH_KSBA], diff --git a/m4/libgcrypt.m4 b/m4/libgcrypt.m4 index c67cfec..d89fe11 100644 --- a/m4/libgcrypt.m4 +++ b/m4/libgcrypt.m4 @@ -15,11 +15,11 @@ dnl AM_PATH_LIBGCRYPT([MINIMUM-VERSION, dnl [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]]) dnl Test for libgcrypt and define LIBGCRYPT_CFLAGS and LIBGCRYPT_LIBS. -dnl MINIMUN-VERSION is a string with the version number optionalliy prefixed +dnl MINIMUM-VERSION is a string with the version number optionalliy prefixed dnl with the API version to also check the API compatibility. Example: -dnl a MINIMUN-VERSION of 1:1.2.5 won't pass the test unless the installed +dnl a MINIMUM-VERSION of 1:1.2.5 won't pass the test unless the installed dnl version of libgcrypt is at least 1.2.5 *and* the API number is 1. Using -dnl this features allows to prevent build against newer versions of libgcrypt +dnl this feature prevents building against newer versions of libgcrypt dnl with a changed API. dnl dnl If a prefix option is not used, the config script is first diff --git a/m4/ntbtls.m4 b/m4/ntbtls.m4 index 85c8ee9..0a30d92 100644 --- a/m4/ntbtls.m4 +++ b/m4/ntbtls.m4 @@ -14,11 +14,11 @@ dnl AM_PATH_NTBTLS([MINIMUM-VERSION, dnl [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]]) dnl dnl Test for NTBTLS and define NTBTLS_CFLAGS and NTBTLS_LIBS. -dnl MINIMUN-VERSION is a string with the version number optionalliy prefixed +dnl MINIMUM-VERSION is a string with the version number optionalliy prefixed dnl with the API version to also check the API compatibility. Example: -dnl a MINIMUN-VERSION of 1:1.2.5 won't pass the test unless the installed -dnl version of libgcrypt is at least 1.2.5 *and* the API number is 1. Using -dnl this features allows to prevent build against newer versions of libgcrypt +dnl a MINIMUM-VERSION of 1:1.2.5 won't pass the test unless the installed +dnl version of ntbtls is at least 1.2.5 *and* the API number is 1. Using +dnl this feature prevents building against newer versions of ntbtls dnl with a changed API. dnl AC_DEFUN([AM_PATH_NTBTLS], diff --git a/po/ca.po b/po/ca.po index 086ac26..633fc3c 100644 --- a/po/ca.po +++ b/po/ca.po @@ -8756,7 +8756,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/cs.po b/po/cs.po index 96bb049..ef00cd1 100644 --- a/po/cs.po +++ b/po/cs.po @@ -8257,7 +8257,7 @@ msgstr "|N| nastavit maxim??ln?? ??ivotnost kl?????? SSH na N sekund" msgid "Options enforcing a passphrase policy" msgstr "Volby vynucuj??c?? politiku hesel" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "nedovolit obej??t politiku hesel" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/da.po b/po/da.po index 2f8fb37..edc95da 100644 --- a/po/da.po +++ b/po/da.po @@ -8774,7 +8774,7 @@ msgstr "|N|angive maksimal livsforl??b for SSH-n??gle til N sekunder" msgid "Options enforcing a passphrase policy" msgstr "Tilvalg der fremtvinger en adgangsfrasepolitik" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "tillad ikke omg??else af adgangsfrasepolitikken" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/de.po b/po/de.po index f341c5f..c8748fe 100644 --- a/po/de.po +++ b/po/de.po @@ -8322,7 +8322,7 @@ msgstr "|N|setze die maximale Lebenszeit von SSH Schl??sseln auf N Sekunden" msgid "Options enforcing a passphrase policy" msgstr "Optionen f??r eine Passphrase-Policy" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "Einhaltung der Passphrase-Policy erzwingen" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/el.po b/po/el.po index 0160ccb..9e0cc10 100644 --- a/po/el.po +++ b/po/el.po @@ -8572,7 +8572,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/eo.po b/po/eo.po index 958c534..7b9921b 100644 --- a/po/eo.po +++ b/po/eo.po @@ -8515,7 +8515,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/es.po b/po/es.po index 5e374f5..4cbfd2e 100644 --- a/po/es.po +++ b/po/es.po @@ -8801,7 +8801,7 @@ msgstr "|N|establecer vida m msgid "Options enforcing a passphrase policy" msgstr "Opciones que fuerzan una pol?tica de frases contrase?a" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "no permitir evitar la pol?tica de frases contrase?a" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/et.po b/po/et.po index 5d9dcf3..c0534d9 100644 --- a/po/et.po +++ b/po/et.po @@ -8489,7 +8489,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/fi.po b/po/fi.po index 414f99b..0fe5521 100644 --- a/po/fi.po +++ b/po/fi.po @@ -8552,7 +8552,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/fr.po b/po/fr.po index c4b6e4d..af39a5c 100644 --- a/po/fr.po +++ b/po/fr.po @@ -8490,7 +8490,7 @@ msgstr "|N|d??finir la dur??e maximale du cache de clef SSH ?? N??secondes" msgid "Options enforcing a passphrase policy" msgstr "Options d'application d'une politique de phrase secr??te" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "pas de contournement de politique de phrase secr??te" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/gl.po b/po/gl.po index c8c5a26..c892f28 100644 --- a/po/gl.po +++ b/po/gl.po @@ -8576,7 +8576,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/hu.po b/po/hu.po index 8505a8f..392ac37 100644 --- a/po/hu.po +++ b/po/hu.po @@ -8522,7 +8522,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/id.po b/po/id.po index f1fbc44..452dccd 100644 --- a/po/id.po +++ b/po/id.po @@ -8511,7 +8511,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/it.po b/po/it.po index 3a0572b..a5cf128 100644 --- a/po/it.po +++ b/po/it.po @@ -8555,7 +8555,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/ja.po b/po/ja.po index 51cfc72..5f94814 100644 --- a/po/ja.po +++ b/po/ja.po @@ -7974,7 +7974,7 @@ msgstr "|N|??????SSH??????????????????N????????????" msgid "Options enforcing a passphrase policy" msgstr "??????????????????????????????????????????????????????" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "??????????????????????????????????????????????????????????????????" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/nb.po b/po/nb.po index db163f2..12bfd13 100644 --- a/po/nb.po +++ b/po/nb.po @@ -8090,7 +8090,7 @@ msgstr "|N|endre maksimal livstid for SSH-n??kler til N antall sekunder" msgid "Options enforcing a passphrase policy" msgstr "Valg som h??ndhever passordfrase-regler" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "ikke tillat overstyring av passordfrase-regler" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/pl.po b/po/pl.po index 74cd6d9..75822e4 100644 --- a/po/pl.po +++ b/po/pl.po @@ -8837,7 +8837,7 @@ msgstr "|N|ustawienie maksymalnego czasu msgid "Options enforcing a passphrase policy" msgstr "Opcje wymuszaj?ce polityk? hase?" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "nie zezwalanie na pomini?cie polityki hase?" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/pt.po b/po/pt.po index beee02b..63c6cec 100644 --- a/po/pt.po +++ b/po/pt.po @@ -8524,7 +8524,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/ro.po b/po/ro.po index 71435aa..dffe008 100644 --- a/po/ro.po +++ b/po/ro.po @@ -8586,7 +8586,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/ru.po b/po/ru.po index 57c4045..f36a27c 100644 --- a/po/ru.po +++ b/po/ru.po @@ -8195,7 +8195,7 @@ msgstr "|N|???????????????????? ???????????????????????? ???????? ?????????????? msgid "Options enforcing a passphrase policy" msgstr "??????????????????, ???????????????????????????? ?????????????? ?????? ????????-??????????????" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "???? ?????????????????? ???????????????? ?????????????? ?????? ????????-??????????????" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/sk.po b/po/sk.po index 8dda2be..d5e8692 100644 --- a/po/sk.po +++ b/po/sk.po @@ -8541,7 +8541,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/sv.po b/po/sv.po index 5c41560..8ff4dbf 100644 --- a/po/sv.po +++ b/po/sv.po @@ -8917,7 +8917,7 @@ msgstr "|N|st??ll in maximal livstid f??r SSH-nyckel till N sekunder" msgid "Options enforcing a passphrase policy" msgstr "Flaggor som tvingar igenom en l??senfraspolicy" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "till??t inte att g?? f??rbi l??senfraspolicyn" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/tr.po b/po/tr.po index 6e661b5..1eae9b4 100644 --- a/po/tr.po +++ b/po/tr.po @@ -8819,7 +8819,7 @@ msgstr "|N|azami SSH anahtar?? ??mr?? N saniyeye ayarlan??r" msgid "Options enforcing a passphrase policy" msgstr "Bir anahtar parolas?? kural??n?? zorlayan se??enekler" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "anahtar parolas?? kural??n??n atlanmas??na izin verilmez" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/uk.po b/po/uk.po index 97442c8..ac57ed4 100644 --- a/po/uk.po +++ b/po/uk.po @@ -8299,7 +8299,7 @@ msgstr "|N|???????????????????? ???????????????????????? ?????????? ?????? ???? msgid "Options enforcing a passphrase policy" msgstr "?????????????????? ?????????????????????? ???????????????????????? ???????????? ??????????????" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "???? ?????????????????? ?????????? ???????????? ??????????????" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/zh_CN.po b/po/zh_CN.po index 41613c7..27f88bb 100644 --- a/po/zh_CN.po +++ b/po/zh_CN.po @@ -8410,7 +8410,7 @@ msgstr "" msgid "Options enforcing a passphrase policy" msgstr "" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "" msgid "|N|set minimal required length for new passphrases to N" diff --git a/po/zh_TW.po b/po/zh_TW.po index d9a4bb8..9438e3d 100644 --- a/po/zh_TW.po +++ b/po/zh_TW.po @@ -8039,7 +8039,7 @@ msgstr "|N|??? SSH ?????????????????????????????? N ???" msgid "Options enforcing a passphrase policy" msgstr "?????????????????????????????????" -msgid "do not allow to bypass the passphrase policy" +msgid "do not allow bypassing the passphrase policy" msgstr "???????????????????????????" msgid "|N|set minimal required length for new passphrases to N" diff --git a/scd/app-p15.c b/scd/app-p15.c index e4d9de0..12254ab 100644 --- a/scd/app-p15.c +++ b/scd/app-p15.c @@ -2935,8 +2935,8 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, /* Due to the fact that the non-repudiation signature on a BELPIC card requires a verify immediately before the DSO we set the - MSE before we do the verification. Other cards might allow to do - this also but I don't want to break anything, thus we do it only + MSE before we do the verification. Other cards might also allow + this but I don't want to break anything, thus we do it only for the BELPIC card here. */ if (app->app_local->card_type == CARD_TYPE_BELPIC) { diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 7a093f6..b1523cb 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -2980,7 +2980,7 @@ ccid_transceive (ccid_driver_t handle, nresp = &dummy_nresp; *nresp = 0; - /* Smarter readers allow to send APDUs directly; divert here. */ + /* Smarter readers allow sending APDUs directly; divert here. */ if (handle->apdu_level) { /* We employ a hack for Omnikey readers which are able to send diff --git a/scd/command.c b/scd/command.c index d90c320..239480b 100644 --- a/scd/command.c +++ b/scd/command.c @@ -499,7 +499,7 @@ static const char hlp_serialno[] = "error is returned if the application is not supported or available.\n" "The default is to auto-select the application using a hardwired\n" "preference system. Note, that a future extension to this function\n" - "may allow to specify a list and order of applications to try.\n" + "may enable specifying a list and order of applications to try.\n" "\n" "This function is special in that it can be used to reset the card.\n" "Most other functions will return an error when a card change has\n" diff --git a/sm/gpgsm.c b/sm/gpgsm.c index 9b7dd4b..b64072e 100644 --- a/sm/gpgsm.c +++ b/sm/gpgsm.c @@ -1681,7 +1681,7 @@ main ( int argc, char **argv) /* Build the recipient list. We first add the regular ones and then the encrypt-to ones because the underlying function will silently - ignore duplicates and we can't allow to keep a duplicate which is + ignore duplicates and we can't allow keeping a duplicate which is flagged as encrypt-to as the actually encrypt function would then complain about no (regular) recipients. */ for (sl = remusr; sl; sl = sl->next) @@ -1785,7 +1785,7 @@ main ( int argc, char **argv) { estream_t fp = open_es_fwrite (opt.outfile?opt.outfile:"-"); - /* Fixme: We should also allow to concatenate multiple files for + /* Fixme: We should also allow concatenation of multiple files for signing because that is what gpg does.*/ set_binary (stdin); if (!argc) /* Create from stdin. */ diff --git a/sm/sign.c b/sm/sign.c index 08eebb7..6cb1f86 100644 --- a/sm/sign.c +++ b/sm/sign.c @@ -109,7 +109,7 @@ hash_and_copy_data (int fd, gcry_md_hd_t md, ksba_writer_t writer) es_fclose (fp); if (!any) { - /* We can't allow to sign an empty message because it does not + /* We can't allow signing an empty message because it does not make much sense and more seriously, ksba_cms_build has already written the tag for data and now expects an octet string and an octet string of size 0 is illegal. */ diff --git a/tools/gpgconf-comp.c b/tools/gpgconf-comp.c index 3d456a9..82b5325 100644 --- a/tools/gpgconf-comp.c +++ b/tools/gpgconf-comp.c @@ -560,7 +560,7 @@ static gc_option_t gc_options_gpg_agent[] = "gnupg", N_("Options enforcing a passphrase policy") }, { "enforce-passphrase-constraints", GC_OPT_FLAG_RUNTIME, GC_LEVEL_EXPERT, "gnupg", - N_("do not allow to bypass the passphrase policy"), + N_("do not allow bypassing the passphrase policy"), GC_ARG_TYPE_NONE, GC_BACKEND_GPG_AGENT }, { "min-passphrase-len", GC_OPT_FLAG_RUNTIME, GC_LEVEL_ADVANCED, "gnupg", @@ -3736,7 +3736,7 @@ gc_process_gpgconf_conf (const char *fname_arg, int update, int defaults, if (defaults) { - /* Here we explicitly allow to update the value again. */ + /* Here we explicitly allow updating the value again. */ if (newflags) { option_info->new_flags = 0; diff --git a/tools/gpgtar.h b/tools/gpgtar.h index 3f21ea1..7d03719 100644 --- a/tools/gpgtar.h +++ b/tools/gpgtar.h @@ -103,7 +103,7 @@ struct tar_header_s unsigned long long mtime; /* Modification time since Epoch. Note that we don't use time_t here but a type which is more likely to be larger - that 32 bit and thus allows to track + that 32 bit and thus allows tracking times beyond 2106. */ typeflag_t typeflag; /* The type of the file. */ -- 2.8.1 From dkg at fifthhorseman.net Tue Aug 2 04:19:16 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 1 Aug 2016 22:19:16 -0400 Subject: [PATCH 2/3] dirmngr: emit correct spelling of "superseded" In-Reply-To: <1470104357-1074-1-git-send-email-dkg@fifthhorseman.net> References: <1470104357-1074-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1470104357-1074-2-git-send-email-dkg@fifthhorseman.net> * dirmngr/crlcache.c (list_one_crl_entry), dirmngr/ocsp.c (ocsp_invalid): spell superseded directly. This might break some tools which parse the existing output and expect misspellings, but i'm not sure there are many such tools, and we should use standardized orthography going forward. Signed-off-by: Daniel Kahn Gillmor --- dirmngr/crlcache.c | 2 +- dirmngr/ocsp.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dirmngr/crlcache.c b/dirmngr/crlcache.c index 25ce7a6..af2a956 100644 --- a/dirmngr/crlcache.c +++ b/dirmngr/crlcache.c @@ -2361,7 +2361,7 @@ list_one_crl_entry (crl_cache_t cache, crl_cache_entry_t e, estream_t fp) if (reason & KSBA_CRLREASON_AFFILIATION_CHANGED ) es_fputs( "affiliation_changed ", fp ), any = 1; if (reason & KSBA_CRLREASON_SUPERSEDED ) - es_fputs( "superseeded", fp ), any = 1; + es_fputs( "superseded", fp ), any = 1; if (reason & KSBA_CRLREASON_CESSATION_OF_OPERATION ) es_fputs( "cessation_of_operation", fp ), any = 1; if (reason & KSBA_CRLREASON_CERTIFICATE_HOLD ) diff --git a/dirmngr/ocsp.c b/dirmngr/ocsp.c index e123409..561b7d7 100644 --- a/dirmngr/ocsp.c +++ b/dirmngr/ocsp.c @@ -716,7 +716,7 @@ ocsp_isvalid (ctrl_t ctrl, ksba_cert_t cert, const char *cert_fpr, reason == KSBA_CRLREASON_CA_COMPROMISE? "CA compromise": reason == KSBA_CRLREASON_AFFILIATION_CHANGED? "affiliation changed": - reason == KSBA_CRLREASON_SUPERSEDED? "superseeded": + reason == KSBA_CRLREASON_SUPERSEDED? "superseded": reason == KSBA_CRLREASON_CESSATION_OF_OPERATION? "cessation of operation": reason == KSBA_CRLREASON_CERTIFICATE_HOLD? -- 2.8.1 From dkg at fifthhorseman.net Tue Aug 2 04:19:15 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 1 Aug 2016 22:19:15 -0400 Subject: [PATCH 1/3] Fix spelling/grammar Message-ID: <1470104357-1074-1-git-send-email-dkg@fifthhorseman.net> * agent/learncard.c: s/coccured/occurred/ * doc/dirmngr.texi: s/ommitted/omitted/, s/orginally/originally/, s/reponses/responses/i * doc/gpg-agent.texi, doc/dirmngr.texi, doc/gpg.texi: , fix "allows to" to more conventional english usage * doc/tools.texi, g10/gpgcommpose.c, tests/openpgp/armor.scm, tests/openpgp/armor.test: s/occured/occurred/ * tools/gpgsplit.c: s/calcualting/calculating/ * sm/server.c: s/formated/formatted/ Signed-off-by: Daniel Kahn Gillmor --- agent/learncard.c | 6 +++--- doc/dirmngr.texi | 14 +++++++------- doc/gpg-agent.texi | 10 +++++----- doc/gpg.texi | 6 +++--- doc/tools.texi | 2 +- g10/gpgcompose.c | 2 +- sm/server.c | 2 +- tests/openpgp/armor.scm | 2 +- tests/openpgp/armor.test | 2 +- tools/gpgsplit.c | 2 +- 10 files changed, 24 insertions(+), 24 deletions(-) diff --git a/agent/learncard.c b/agent/learncard.c index e0f2340..e9304fb 100644 --- a/agent/learncard.c +++ b/agent/learncard.c @@ -133,7 +133,7 @@ kpinfo_cb (void *opaque, const char *line) char *p; if (parm->error) - return; /* no need to gather data after an error coccured */ + return; /* no need to gather data after an error occurred */ if ((parm->error = agent_write_status (parm->ctrl, "PROGRESS", "learncard", "k", "0", "0", NULL))) @@ -190,7 +190,7 @@ certinfo_cb (void *opaque, const char *line) char *p, *pend; if (parm->error) - return; /* no need to gather data after an error coccured */ + return; /* no need to gather data after an error occurred */ if ((parm->error = agent_write_status (parm->ctrl, "PROGRESS", "learncard", "c", "0", "0", NULL))) @@ -232,7 +232,7 @@ sinfo_cb (void *opaque, const char *keyword, size_t keywordlen, SINFO item; if (sparm->error) - return; /* no need to gather data after an error coccured */ + return; /* no need to gather data after an error occurred */ item = xtrycalloc (1, sizeof *item + keywordlen + 1 + strlen (data)); if (!item) diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index e87442f..033b5d3 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -321,9 +321,9 @@ whether @option{--honor-http-proxy} has been set. @item --ldap-proxy @var{host}[:@var{port}] @opindex ldap-proxy Use @var{host} and @var{port} to connect to LDAP servers. If @var{port} -is ommitted, port 389 (standard LDAP port) is used. This overrides any +is omitted, port 389 (standard LDAP port) is used. This overrides any specified host and port part in a LDAP URL and will also be used if host -and port have been ommitted from the URL. +and port have been omitted from the URL. @item --only-ldap-proxy @opindex only-ldap-proxy @@ -346,12 +346,12 @@ This server list file contains one LDAP server per line in the format Lines starting with a @samp{#} are comments. Note that as usual all strings entered are expected to be UTF-8 encoded. -Obviously this will lead to problems if the password has orginally been +Obviously this will lead to problems if the password has originally been encoded as Latin-1. There is no other solution here than to put such a password in the binary encoding into the file (i.e. non-ascii characters won't show up readable). at footnote{The @command{gpgconf} tool might be -helpful for frontends as it allows to edit this configuration file using -percent escaped strings.} +helpful for frontends as it enables editing this configuration file using +percent-escaped strings.} @item --ldaptimeout @var{secs} @@ -474,7 +474,7 @@ In the deprecated system daemon mode the second directory is used instead. @item /etc/gnupg/trusted-certs This directory should be filled with certificates of Root CAs you -are trusting in checking the CRLs and signing OCSP Reponses. +are trusting in checking the CRLs and signing OCSP Responses. Usually these are the same certificates you use with the applications making use of dirmngr. It is expected that each of these certificate @@ -496,7 +496,7 @@ This directory may contain extra certificates which are preloaded into the interal cache on startup. Applications using dirmngr (e.g. gpgsm) can request cached certificates to complete a trust chain. This is convenient in cases you have a couple intermediate CA certificates -or certificates ususally used to sign OCSP reponses. +or certificates ususally used to sign OCSP responses. These certificates are first tried before going out to the net to look for them. These certificates must also be @acronym{DER} encoded and suffixed with @file{.crt} or @file{.der}. diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index cd5d751..b481dd6 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -540,8 +540,8 @@ Also listen on native gpg-agent connections on the given socket. The intended use for this extra socket is to setup a Unix domain socket forwarding from a remote machine to this socket on the local machine. A @command{gpg} running on the remote machine may then connect to the -local gpg-agent and use its private keys. This allows to decrypt or -sign data on a remote machine without exposing the private keys to the +local gpg-agent and use its private keys. This enables decrypting or +signing data on a remote machine without exposing the private keys to the remote machine. @@ -633,7 +633,7 @@ agent. By default they may all be found in the current home directory lines are ignored. To mark a key as trusted you need to enter its fingerprint followed by a space and a capital letter @code{S}. Colons may optionally be used to separate the bytes of a fingerprint; this - allows to cut and paste the fingerprint from a key listing output. If + enables cutting and pasting the fingerprint from a key listing output. If the line is prefixed with a @code{!} the key is explicitly marked as not trusted. @@ -1041,8 +1041,8 @@ Here is an example session: @subsection Generating a Key This is used to create a new keypair and store the secret key inside the -active PSE --- which is in most cases a Soft-PSE. An not yet defined -option allows to choose the storage location. To get the secret key out +active PSE --- which is in most cases a Soft-PSE. A not-yet-defined +option allows choosing the storage location. To get the secret key out of the PSE, a special export tool has to be used. @example diff --git a/doc/gpg.texi b/doc/gpg.texi index 38f417e..3be401f 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -1678,7 +1678,7 @@ mechanisms, in the order they are to be tried: may be used here to query that particular keyserver. @item local - Locate the key using the local keyrings. This mechanism allows to + Locate the key using the local keyrings. This mechanism allows the user to select the order a local key lookup is done. Thus using @samp{--auto-key-locate local} is identical to @option{--no-auto-key-locate}. @@ -2110,7 +2110,7 @@ Use @var{name} as the key to sign with. Note that this option overrides @opindex try-secret-key For hidden recipients GPG needs to know the keys to use for trial decryption. The key set with @option{--default-key} is always tried -first, but this is often not sufficient. This option allows to set more +first, but this is often not sufficient. This option allows setting more keys to be used for trial decryption. Although any valid user-id specification may be used for @var{name} it makes sense to use at least the long keyid to avoid ambiguities. Note that gpg-agent might pop up a @@ -2791,7 +2791,7 @@ to display the message. This option overrides @option{--set-filename}. @itemx --no-use-embedded-filename @opindex use-embedded-filename Try to create a file with a name as embedded in the data. This can be -a dangerous option as it allows to overwrite files. Defaults to no. +a dangerous option as it enables overwriting files. Defaults to no. @item --cipher-algo @code{name} @opindex cipher-algo diff --git a/doc/tools.texi b/doc/tools.texi index 577df8e..e52d6a7 100644 --- a/doc/tools.texi +++ b/doc/tools.texi @@ -1749,7 +1749,7 @@ The possible exit status codes of @command{symcryptrun} are: @item 0 Success. @item 1 - Some error occured. + Some error occurred. @item 2 No valid passphrase was provided. @item 3 diff --git a/g10/gpgcompose.c b/g10/gpgcompose.c index cd5346f..e3bb013 100644 --- a/g10/gpgcompose.c +++ b/g10/gpgcompose.c @@ -1317,7 +1317,7 @@ sig_notation (const char *option, int argc, char *argv[], void *cookie) else notation = string_to_notation (p, 1); if (! notation) - log_fatal ("creating notation: an unknown error occured.\n"); + log_fatal ("creating notation: an unknown error occurred.\n"); notation->next = si->notations; si->notations = notation; diff --git a/sm/server.c b/sm/server.c index 8b4a29c..cdccff3 100644 --- a/sm/server.c +++ b/sm/server.c @@ -1039,7 +1039,7 @@ static const char hlp_getauditlog[] = "If --data is used, the output is send using D-lines and not to the\n" "file descriptor given by an OUTPUT command.\n" "\n" - "If --html is used the output is formated as an XHTML block. This is\n" + "If --html is used the output is formatted as an XHTML block. This is\n" "designed to be incorporated into a HTML document."; static gpg_error_t cmd_getauditlog (assuan_context_t ctx, char *line) diff --git a/tests/openpgp/armor.scm b/tests/openpgp/armor.scm index 5b4ea14..578e248 100755 --- a/tests/openpgp/armor.scm +++ b/tests/openpgp/armor.scm @@ -749,7 +749,7 @@ wg7Md81a5RI3F2FG8747t9gX ") ;; Bug 1179 solved 2010-05-12: -;; It occured for messages of a multiple of the iobuf block size where +;; It occurred for messages of a multiple of the iobuf block size where ;; the last line had no pad character. Due to premature poppng of thea ;; rmor filter gpg swalled the CRC line and passed the '-----END...' ;; line on to the decryption layer. diff --git a/tests/openpgp/armor.test b/tests/openpgp/armor.test index ce5939c..72831e3 100755 --- a/tests/openpgp/armor.test +++ b/tests/openpgp/armor.test @@ -742,7 +742,7 @@ wg7Md81a5RI3F2FG8747t9gX ' # Bug 1179 solved 2010-05-12: -# It occured for messages of a multiple of the iobuf block size where +# It occurred for messages of a multiple of the iobuf block size where # the last line had no pad character. Due to premature poppng of thea # rmor filter gpg swalled the CRC line and passed the '-----END...' # line on to the decryption layer. diff --git a/tools/gpgsplit.c b/tools/gpgsplit.c index 2451ab3..93dd8ed 100644 --- a/tools/gpgsplit.c +++ b/tools/gpgsplit.c @@ -577,7 +577,7 @@ write_part (FILE *fpin, unsigned long pktlen, len = public_key_length (blob, pktlen); if (!len) { - log_error ("error calcualting public key length\n"); + log_error ("error calculating public key length\n"); g10_exit (1); } if ( (hdr[0] & 0x40) ) -- 2.8.1 From ben at adversary.org Tue Aug 2 05:10:41 2016 From: ben at adversary.org (Ben McGinnes) Date: Tue, 2 Aug 2016 13:10:41 +1000 Subject: New option --recipient-file In-Reply-To: <87poqqvp9n.fsf@wheatstone.g10code.de> References: <87poqqvp9n.fsf@wheatstone.g10code.de> Message-ID: <20160802031041.GP60474@adversary.org> On Wed, Jul 06, 2016 at 04:01:56PM +0200, Werner Koch wrote: > > it is now possible to bypass the keyring and take the public key > directly from a file. That file may be a binary or an ascii armored > key and only the first keyblock from that file is used. A key > specified with this option is always fully trusted. Very nice, but does that mean it will also be able to handle additional .kbx files in addition to the .gpg and .asc files? If so, will it also work with a trustdb file and, if so, is it possible to specify a different trustdb file location when doing so? > To futher assist some use cases the option > > --no-keyring > > has also been implemented. This is similar to > > --no-default-keyring --keyring /dev/null A most useful feature too. I found it to be of particular use when the annual assertions[1] of compromised keys being propagated out in the world filter through various mailing lists and IT rumour mongers. It's the key component in preventing the reality (corrupted key data) interfering with my real keyring(s). Regards, Ben 1: We all know who I'm referring to, so I don't need to feed the flames of narcissism by naming him. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From bernhard at intevation.de Tue Aug 2 09:31:37 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 2 Aug 2016 09:31:37 +0200 Subject: dirmngr: Wrong certificate error? In-Reply-To: <34631fe7-77ed-d0be-9978-fd452e765c70@enigmail.net> References: <465ea677-4619-b326-b944-3c36236819ac@enigmail.net> <201608011756.23997.bernhard@intevation.de> <34631fe7-77ed-d0be-9978-fd452e765c70@enigmail.net> Message-ID: <201608020931.41589.bernhard@intevation.de> Am Montag, 1. August 2016 21:34:01 schrieb Patrick Brunschwig: > It looks like gnutls-cli is not successful (see below). How can the root > certificates be added to gnutls (and dirmngr)? > > Error setting the x509 trust file > Resolving 'keys.mailvelope.com:443'... Like Daniel I believe that you should check your gnutls setup. (I agree that it would make sense to think more about the relation between system certs and gpgsm certs, but this will not help you right away.) -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From pgut001 at cs.auckland.ac.nz Tue Aug 2 08:12:58 2016 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 2 Aug 2016 06:12:58 +0000 Subject: [PATCH 3/3] more cleanup of "allow to" In-Reply-To: <1470104357-1074-3-git-send-email-dkg@fifthhorseman.net> References: <1470104357-1074-1-git-send-email-dkg@fifthhorseman.net>, <1470104357-1074-3-git-send-email-dkg@fifthhorseman.net> Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CDDECF@uxcn10-5.UoA.auckland.ac.nz> Daniel Kahn Gillmor writes: > Since > version 2 GnuPG provides support for S/MIME and Secure Shell in > addition to OpenPGP. There's still something in there that sounds, the way it's used here "since" scans as "because" (e.g. "since our house burned down all hundred and sixty of us have had to live in a small shoebox in the middle of the road"). Better phrasing would be "starting with version 2...". Peter. From justus at g10code.com Tue Aug 2 09:51:42 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 02 Aug 2016 09:51:42 +0200 Subject: [PATCH] Erase memory before freeing. In-Reply-To: <1470094922-8336086.34567908.fu71NfNvA017971@rs146.luxsci.com> References: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> <87oa5cokvw.fsf@europa.jade-hamburg.de> <1470094922-8336086.34567908.fu71NfNvA017971@rs146.luxsci.com> Message-ID: <874m73sj5d.fsf@europa.jade-hamburg.de> Hi :) Ben Kibbey writes: > On Mon, Aug 01, 2016 at 12:15:31PM +0200, Justus Winter wrote: >> > +static struct mem_item_s *memlist; >> >> I wonder if a list is the right data structure. Linear lookup time >> feels expensive. > > I thought this too. I haven't done any benchmarks but the list is > prepended to so it comforms with most de/allocations as LIFO. I also > don't khow how else to do it without requiring a realloc of a mem_item_s > which would corrupt pointers for .next. Any ideas? Actually, if you allocate both the length and the actual data in one chunk, you don't need an extra data structure at all and get constant time lookups, i.e.: struct chunk { size_t size; char data[0]; }; then on free(p) you do chunk *c = p - offsetof(struct chunk, data); >> > + { >> > + UNLOCK (memlist_lock); >> > + return _gpgme_assuan_malloc (n); >> > + } >> > + >> > + tmp = _gpgme_assuan_malloc (n); >> >> Can't we just use realloc here? And if not for some reason, please >> don't look newitem up like this, instead create a variant of >> _gpgme_assuan_malloc that returns the item. > > Needed to wipe item->data. Not sure how to do both wiping item->data > and realloc'ing. Yeah, I understand now. > Attached is the revised patch. Suggestions welcome. Also, Werner > mentioned some time ago he'd like to add allocaters to gpg-error to > replace the "hooks" in libassuan and others. Not sure if anyone has > started that or not. I don't know that either. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From wk at gnupg.org Tue Aug 2 12:02:34 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Aug 2016 12:02:34 +0200 Subject: [PATCH] Erase memory before freeing. In-Reply-To: <874m73sj5d.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Tue, 02 Aug 2016 09:51:42 +0200") References: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> <87oa5cokvw.fsf@europa.jade-hamburg.de> <1470094922-8336086.34567908.fu71NfNvA017971@rs146.luxsci.com> <874m73sj5d.fsf@europa.jade-hamburg.de> Message-ID: <8760rjmqth.fsf@wheatstone.g10code.de> On Tue, 2 Aug 2016 09:51, justus at g10code.com said: > struct chunk { > size_t size; > char data[0]; > }; That is not portable. You need to use struct chunk { size_t size; char data[1]; }; Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Tue Aug 2 12:07:45 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Aug 2016 12:07:45 +0200 Subject: [PATCH] Erase memory before freeing. In-Reply-To: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> (Ben Kibbey's message of "Sun, 31 Jul 2016 19:12:37 -0400") References: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> Message-ID: <871t27mqku.fsf@wheatstone.g10code.de> Hi Ben, Please describe your threat model or use case for this change. Note that in Libgcrypt we put extensive work into wiping only memory with sensitive information. We also make sure to wipe the lowest number of bytes possible so to avoid cache pollution. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Tue Aug 2 12:09:58 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Aug 2016 12:09:58 +0200 Subject: New option --recipient-file In-Reply-To: <20160802031041.GP60474@adversary.org> (Ben McGinnes's message of "Tue, 2 Aug 2016 13:10:41 +1000") References: <87poqqvp9n.fsf@wheatstone.g10code.de> <20160802031041.GP60474@adversary.org> Message-ID: <87wpjzlbwp.fsf@wheatstone.g10code.de> On Tue, 2 Aug 2016 05:10, ben at adversary.org said: > Very nice, but does that mean it will also be able to handle > additional .kbx files in addition to the .gpg and .asc files? No. Only the OpenPGP compliant format. The .kbx format is internal to GnuPG. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From bjk at luxsci.net Wed Aug 3 00:25:04 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Tue, 2 Aug 2016 18:25:04 -0400 Subject: [PATCH] Erase memory before freeing. In-Reply-To: <871t27mqku.fsf@wheatstone.g10code.de> References: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> <871t27mqku.fsf@wheatstone.g10code.de> Message-ID: <1470176762-462351.836608482.fu72MP5TS010623@rs146.luxsci.com> On Tue, Aug 02, 2016 at 12:07:45PM +0200, Werner Koch wrote: > Hi Ben, > > Please describe your threat model or use case for this change. > > Note that in Libgcrypt we put extensive work into wiping only memory > with sensitive information. We also make sure to wipe the lowest number > of bytes possible so to avoid cache pollution. I was thinking about import/export of secret keys. But now that you mention it, replacing the assuan memory hooks is overkill. The wiping of memory is already done for the stack buffers in the callbacks. It is done for every call to the callback without parsing anything so that may be expensive, I don't know. Yet there is no telling what could be laying around after the final call. -- Ben Kibbey From ben at adversary.org Wed Aug 3 00:53:00 2016 From: ben at adversary.org (Ben McGinnes) Date: Wed, 3 Aug 2016 08:53:00 +1000 Subject: New option --recipient-file In-Reply-To: <87wpjzlbwp.fsf@wheatstone.g10code.de> References: <87poqqvp9n.fsf@wheatstone.g10code.de> <20160802031041.GP60474@adversary.org> <87wpjzlbwp.fsf@wheatstone.g10code.de> Message-ID: <20160802225300.GT60474@adversary.org> On Tue, Aug 02, 2016 at 12:09:58PM +0200, Werner Koch wrote: > On Tue, 2 Aug 2016 05:10, ben at adversary.org said: > > > Very nice, but does that mean it will also be able to handle > > additional .kbx files in addition to the .gpg and .asc files? > > No. Only the OpenPGP compliant format. The .kbx format is internal > to GnuPG. Cool, also a very good reason for not including it there. Given the propensity for people to generally only create ASCII armoured key files to leave all over the place, I'm fairly confident that that will become very popular. I know it had been asked about on one or two of the StackExchange sites two or three years ago and that entire network of sites is basically dedicated to history repeating, albeit getting fine tuned along the way, so it'll be a convenient answer the next time that happens. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From wk at gnupg.org Wed Aug 3 11:13:20 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Aug 2016 11:13:20 +0200 Subject: [PATCH] Erase memory before freeing. In-Reply-To: <1470176762-462351.836608482.fu72MP5TS010623@rs146.luxsci.com> (Ben Kibbey's message of "Tue, 2 Aug 2016 18:25:04 -0400") References: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> <871t27mqku.fsf@wheatstone.g10code.de> <1470176762-462351.836608482.fu72MP5TS010623@rs146.luxsci.com> Message-ID: <87zioufc5r.fsf@wheatstone.g10code.de> On Wed, 3 Aug 2016 00:25, bjk at luxsci.net said: > I was thinking about import/export of secret keys. But now that you > mention it, replacing the assuan memory hooks is overkill. The wiping of FWIW: If the user decides to use a non-protected secret key he needs to take care at a lot of other places too. I doubt that wiping the stack or heap will change anything. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From dkg at fifthhorseman.net Wed Aug 3 16:03:55 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 03 Aug 2016 10:03:55 -0400 Subject: messy commit on STABLE-BRANCH-1-4 Message-ID: <87lh0ec5kk.fsf@alice.fifthhorseman.net> hi all-- it looks to me like there is a mistaken commit on STABLE-BRANCH-1-4. In particular, db246f8b18b77314938e596b8217bd97223d5aad probably only intends to modify g10/tdbio.c, but in practice, it commits a lot of backup or generated files in po/*.po~ and po/*.gmo. This is probably something worth reverting (or rebasing the branch based on a cleaned-up commit, if the project's vcs policy permits that) before a new release of 1.4 is made. happy hacking, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From justus at g10code.com Wed Aug 3 17:04:24 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 03 Aug 2016 17:04:24 +0200 Subject: [PATCH 1/3] Fix spelling/grammar In-Reply-To: <1470104357-1074-1-git-send-email-dkg@fifthhorseman.net> References: <1470104357-1074-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87poppsxl3.fsf@europa.jade-hamburg.de> Merged, many thanks! I amended your commit messages a little, please have a look at doc/HACKING. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From justus at g10code.com Wed Aug 3 17:23:44 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 03 Aug 2016 17:23:44 +0200 Subject: messy commit on STABLE-BRANCH-1-4 In-Reply-To: <87lh0ec5kk.fsf@alice.fifthhorseman.net> References: <87lh0ec5kk.fsf@alice.fifthhorseman.net> Message-ID: <87mvktswov.fsf@europa.jade-hamburg.de> Hi, Daniel Kahn Gillmor writes: > it looks to me like there is a mistaken commit on STABLE-BRANCH-1-4. In > particular, db246f8b18b77314938e596b8217bd97223d5aad probably only > intends to modify g10/tdbio.c, but in practice, it commits a lot of > backup or generated files in po/*.po~ and po/*.gmo. > > This is probably something worth reverting (or rebasing the branch based > on a cleaned-up commit, if the project's vcs policy permits that) before > a new release of 1.4 is made. Good catch! I reverted that part. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Aug 3 17:56:55 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 3 Aug 2016 11:56:55 -0400 Subject: [STABLE-BRANCH-1-4 PATCH 1/2] Fix spelling: "occured" should be "occurred" Message-ID: <1470239816-585-1-git-send-email-dkg@fifthhorseman.net> * checks/armor.test, cipher/des.c, g10/ccid-driver.c, g10/pkclist.c, util/regcomp.c, util/regex_internal.c: correct the spelling of "occured" to "occurred" Signed-off-by: Daniel Kahn Gillmor --- checks/armor.test | 2 +- cipher/des.c | 2 +- g10/ccid-driver.c | 2 +- g10/pkclist.c | 2 +- util/regcomp.c | 4 ++-- util/regex_internal.c | 4 ++-- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/checks/armor.test b/checks/armor.test index cfd2359..a23f8d8 100755 --- a/checks/armor.test +++ b/checks/armor.test @@ -734,7 +734,7 @@ wg7Md81a5RI3F2FG8747t9gX ' # Bug 1179 solved 2010-05-12: -# It occured for messages of a multiple of the iobuf block size where +# It occurred for messages of a multiple of the iobuf block size where # the last line had no pad character. Due to premature popping of the # armor filter gpg swalled the CRC line and passed the '-----END...' # line on to the decryption layer. diff --git a/cipher/des.c b/cipher/des.c index 670ba65..7eaa2df 100644 --- a/cipher/des.c +++ b/cipher/des.c @@ -104,7 +104,7 @@ * * if ( (error_msg = selftest()) ) * { - * fprintf(stderr, "An error in the DES/Tripple-DES implementation occured: %s\n", error_msg); + * fprintf(stderr, "An error in the DES/Tripple-DES implementation occurred: %s\n", error_msg); * abort(); * } */ diff --git a/g10/ccid-driver.c b/g10/ccid-driver.c index 515b15a..6f7c9b2 100644 --- a/g10/ccid-driver.c +++ b/g10/ccid-driver.c @@ -2264,7 +2264,7 @@ ccid_poll (ccid_driver_t handle) } else if (msg[0] == RDR_to_PC_HardwareError) { - DEBUGOUT ("hardware error occured\n"); + DEBUGOUT ("hardware error occurred\n"); } else { diff --git a/g10/pkclist.c b/g10/pkclist.c index 198e307..b78070e 100644 --- a/g10/pkclist.c +++ b/g10/pkclist.c @@ -952,7 +952,7 @@ build_pk_list( STRLIST rcpts, PK_LIST *ret_pk_list, unsigned int use ) } /* Do group expand here too. The trick here is to continue - the loop if any expansion occured. The code above will + the loop if any expansion occurred. The code above will then list all expanded keys. */ if (expand_id(answer,&backlog,0)) continue; diff --git a/util/regcomp.c b/util/regcomp.c index 6964df9..aafb9c8 100644 --- a/util/regcomp.c +++ b/util/regcomp.c @@ -1764,7 +1764,7 @@ peek_token_bracket (token, input, syntax) /* Entry point of the parser. Parse the regular expression REGEXP and return the structure tree. - If an error is occured, ERR is set by error code, and return NULL. + If an error is occurred, ERR is set by error code, and return NULL. This function build the following tree, from regular expression : CAT / \ @@ -3349,7 +3349,7 @@ build_word_op (dfa, not, err) /* This is intended for the expressions like "a{1,3}". Fetch a number from `input', and return the number. Return -1, if the number field is empty like "{,1}". - Return -2, If an error is occured. */ + Return -2, If an error is occurred. */ static int fetch_number (input, token, syntax) diff --git a/util/regex_internal.c b/util/regex_internal.c index 6f3a96e..4349f1b 100644 --- a/util/regex_internal.c +++ b/util/regex_internal.c @@ -793,7 +793,7 @@ re_node_set_merge (dest, src) /* Insert the new element ELEM to the re_node_set* SET. return 0 if SET already has ELEM, - return -1 if an error is occured, return 1 otherwise. */ + return -1 if an error is occurred, return 1 otherwise. */ static int re_node_set_insert (set, elem) @@ -909,7 +909,7 @@ re_node_set_remove_at (set, idx) /* Add the token TOKEN to dfa->nodes, and return the index of the token. - Or return -1, if an error will be occured. */ + Or return -1, if an error will be occurred. */ static int re_dfa_add_node (dfa, token, mode) -- 2.8.1 From dkg at fifthhorseman.net Wed Aug 3 17:56:56 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 3 Aug 2016 11:56:56 -0400 Subject: [STABLE-BRANCH-1-4 PATCH 2/2] Clean up "allow to" In-Reply-To: <1470239816-585-1-git-send-email-dkg@fifthhorseman.net> References: <1470239816-585-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1470239816-585-2-git-send-email-dkg@fifthhorseman.net> * README, cipher/cipher.c, cipher/pubkey.c, doc/gpg.texi: replace "allow to" with clearer text In standard English, the normal construction is "${XXX} allows ${YYY} to" -- that is, the subject (${XXX}) of the sentence is allowing the object (${YYY}) to do something. When the object is missing, the phrasing sounds awkward, even if the object is implied by context. There's almost always a better construction that isn't as awkward. These changes should make the language a bit clearer. Signed-off-by: Daniel Kahn Gillmor --- README | 2 +- cipher/cipher.c | 4 ++-- cipher/pubkey.c | 2 +- doc/gpg.texi | 6 +++--- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/README b/README index 85b29d0..1a331fb 100644 --- a/README +++ b/README @@ -632,7 +632,7 @@ is in general the preferable solution. However the code is new and under some cirumstances it may give different output than with the limited old - support. This option allows to explicity disable + support. This option explicitly disables the use of iconv. Note, that iconv is also disabled if gettext has been disabled. diff --git a/cipher/cipher.c b/cipher/cipher.c index 4ef0d81..f55ce8b 100644 --- a/cipher/cipher.c +++ b/cipher/cipher.c @@ -586,7 +586,7 @@ do_cfb_encrypt( CIPHER_HANDLE c, byte *outbuf, byte *inbuf, unsigned nbytes ) /* Now we can process complete blocks. We use a loop as long as we have at least 2 blocks and use conditions for the rest. This - also allows to use a bulk encryption function if available. */ + also allows use of a bulk encryption function if available. */ #ifdef USE_AES if (nbytes >= blocksize_x_2 && (c->algo == CIPHER_ALGO_AES @@ -677,7 +677,7 @@ do_cfb_decrypt( CIPHER_HANDLE c, byte *outbuf, byte *inbuf, unsigned nbytes ) /* Now we can process complete blocks. We use a loop as long as we have at least 2 blocks and use conditions for the rest. This - also allows to use a bulk encryption function if available. */ + also allows use of a bulk encryption function if available. */ #ifdef USE_AES if (nbytes >= blocksize_x_2 && (c->algo == CIPHER_ALGO_AES diff --git a/cipher/pubkey.c b/cipher/pubkey.c index 02c096e..60d855c 100644 --- a/cipher/pubkey.c +++ b/cipher/pubkey.c @@ -276,7 +276,7 @@ check_pubkey_algo2( int algo, unsigned use ) int i; /* Map type 20 Elgamal algorithm to type 16 if it is used for - decryption. This allows to use legacy type 20 Elgamal keys for + decryption. This allows use of legacy type 20 Elgamal keys for decryption. */ if (algo == PUBKEY_ALGO_ELGAMAL && use == PUBKEY_USAGE_ENC) algo = PUBKEY_ALGO_ELGAMAL_E; diff --git a/doc/gpg.texi b/doc/gpg.texi index ee756d8..a41ab8e 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -1211,7 +1211,7 @@ Use @code{file} to access the smartcard reader. The current default is @item --disable-ccid @opindex disable-ccid Disable the integrated support for CCID compliant readers. This -allows to fall back to one of the other drivers even if the internal +allows falling back to one of the other drivers even if the internal CCID driver can handle the reader. Note, that CCID support is only available if libusb was available at build time. @@ -1438,7 +1438,7 @@ mechanisms, in the order they are to be tried: may be used here to query that particular keyserver. @item local - Locate the key using the local keyrings. This mechanism allows to + Locate the key using the local keyrings. This mechanism allows the user to select the order a local key lookup is done. Thus using @samp{--auto-key-locate local} is identical to @option{--no-auto-key-locate}. @@ -2416,7 +2416,7 @@ to display the message. This option overrides @option{--set-filename}. @itemx --no-use-embedded-filename @opindex use-embedded-filename Try to create a file with a name as embedded in the data. This can be -a dangerous option as it allows to overwrite files. Defaults to no. +a dangerous option as it enables overwriting files. Defaults to no. @item --cipher-algo @code{name} @opindex cipher-algo -- 2.8.1 From patrick at enigmail.net Wed Aug 3 19:53:17 2016 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 3 Aug 2016 19:53:17 +0200 Subject: dirmngr: Wrong certificate error? In-Reply-To: <87wpk0dyax.fsf@alice.fifthhorseman.net> References: <465ea677-4619-b326-b944-3c36236819ac@enigmail.net> <201608011756.23997.bernhard@intevation.de> <34631fe7-77ed-d0be-9978-fd452e765c70@enigmail.net> <87wpk0dyax.fsf@alice.fifthhorseman.net> Message-ID: <23643459-07ec-630f-428c-756e5855606a@enigmail.net> On 01.08.16 22:33, Daniel Kahn Gillmor wrote: > fwiw, your gnutls-cli invocation's output looks like: > >> Error setting the x509 trust file >> Resolving 'keys.mailvelope.com:443'... >> Connecting to '52.208.40.58:443'... >> - Certificate type: X.509 > > but "gnutls-cli keys.mailvelope.com" works for me, so i suspect you have > something misconfigured with your gnutls installation. i see the start > of the output as: > >> Processed 151 CA certificate(s). >> Resolving 'keys.mailvelope.com'... >> Connecting to '52.208.40.58:443'... >> - Certificate type: X.509 > > maybe you need to look at the system-level trust store on your gnutls > installation? Well yes, on Mac OS X, the system-level trust store of my self-compiled gnutls installation is empty. It's not surprising that gnutls can't read the root certificates from Apple's Keychain. I exported Apple's root certificates into my gnutls root store, and it works now correctly. Thanks -Patrick From dkg at fifthhorseman.net Wed Aug 3 21:15:37 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 03 Aug 2016 15:15:37 -0400 Subject: dirmngr: Wrong certificate error? In-Reply-To: <23643459-07ec-630f-428c-756e5855606a@enigmail.net> References: <465ea677-4619-b326-b944-3c36236819ac@enigmail.net> <201608011756.23997.bernhard@intevation.de> <34631fe7-77ed-d0be-9978-fd452e765c70@enigmail.net> <87wpk0dyax.fsf@alice.fifthhorseman.net> <23643459-07ec-630f-428c-756e5855606a@enigmail.net> Message-ID: <871t25d5pi.fsf@alice.fifthhorseman.net> On Wed 2016-08-03 13:53:17 -0400, Patrick Brunschwig wrote: > Well yes, on Mac OS X, the system-level trust store of my self-compiled > gnutls installation is empty. It's not surprising that gnutls can't read > the root certificates from Apple's Keychain. It is actually surprising to me. Modern versions of GnuTLS make a point of trying to integrate well with the local OS, to the point where it has features on Windows that it doesn't have on other OSes because Windows offers features in the crypto API that aren't on other OSes. http://gnutls.org/manual/gnutls.html#Application_002dspecific-keys In particular, i'd expect that gnutls_certificate_set_x509_system_trust() should Do the Right Thing. http://gnutls.org/manual/gnutls.html#gnutls_005fcertificate_005fset_005fx509_005fsystem_005ftrust > I exported Apple's root certificates into my gnutls root store, and it > works now correctly. If there's a particular step that you took that you think GnuTLS should be able to do automatically on OS X, i recommend opening a report here: https://gitlab.com/gnutls/gnutls Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From patrick at enigmail.net Wed Aug 3 22:15:41 2016 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 3 Aug 2016 22:15:41 +0200 Subject: dirmngr: Wrong certificate error? In-Reply-To: <871t25d5pi.fsf@alice.fifthhorseman.net> References: <465ea677-4619-b326-b944-3c36236819ac@enigmail.net> <201608011756.23997.bernhard@intevation.de> <34631fe7-77ed-d0be-9978-fd452e765c70@enigmail.net> <87wpk0dyax.fsf@alice.fifthhorseman.net> <23643459-07ec-630f-428c-756e5855606a@enigmail.net> <871t25d5pi.fsf@alice.fifthhorseman.net> Message-ID: On 03.08.16 21:15, Daniel Kahn Gillmor wrote: > On Wed 2016-08-03 13:53:17 -0400, Patrick Brunschwig wrote: >> Well yes, on Mac OS X, the system-level trust store of my self-compiled >> gnutls installation is empty. It's not surprising that gnutls can't read >> the root certificates from Apple's Keychain. > > It is actually surprising to me. Modern versions of GnuTLS make a point > of trying to integrate well with the local OS, to the point where it has > features on Windows that it doesn't have on other OSes because Windows > offers features in the crypto API that aren't on other OSes. > > http://gnutls.org/manual/gnutls.html#Application_002dspecific-keys > > In particular, i'd expect that > gnutls_certificate_set_x509_system_trust() should Do the Right Thing. > > http://gnutls.org/manual/gnutls.html#gnutls_005fcertificate_005fset_005fx509_005fsystem_005ftrust It looks to me that only Windows is supported. At least, words like Apple, Mac OS and similar don't appear in the docu. >> I exported Apple's root certificates into my gnutls root store, and it >> works now correctly. > > If there's a particular step that you took that you think GnuTLS should > be able to do automatically on OS X, i recommend opening a report here: [...] Well, I'm sure there would be an API for it. I just used a command line tool that is provided by Mac OS X, but I assume that integrating a command line tool is not an ideal solution for a library. -Patrick From justus at g10code.com Thu Aug 4 12:39:26 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 04 Aug 2016 12:39:26 +0200 Subject: [STABLE-BRANCH-1-4 PATCH 1/2] Fix spelling: "occured" should be "occurred" In-Reply-To: <1470239816-585-1-git-send-email-dkg@fifthhorseman.net> References: <1470239816-585-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87popostr5.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > * checks/armor.test, cipher/des.c, g10/ccid-driver.c, g10/pkclist.c, > util/regcomp.c, util/regex_internal.c: correct the spelling of > "occured" to "occurred" Both merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From justus at g10code.com Thu Aug 4 12:58:58 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 04 Aug 2016 12:58:58 +0200 Subject: [PATCH] Fix ncurses build. In-Reply-To: <1470101163-7571789.8718608.fu721PXc3032193@rs146.luxsci.com> References: <1470101163-7571789.8718608.fu721PXc3032193@rs146.luxsci.com> Message-ID: <87lh0cssul.fsf@europa.jade-hamburg.de> Ben Kibbey writes: > * pinentry/Makefile.am: Add NCURSES_CFLAGS. Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From wk at gnupg.org Thu Aug 4 16:28:18 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Aug 2016 16:28:18 +0200 Subject: [PATCH] Add keygrip to LISTKEYS output. In-Reply-To: <1468890724-292716.405388038.fu6J1BnQi002450@rs146.luxsci.com> (Ben Kibbey's message of "Mon, 18 Jul 2016 21:11:48 -0400") References: <1468890724-292716.405388038.fu6J1BnQi002450@rs146.luxsci.com> Message-ID: <87d1loehh9.fsf@wheatstone.g10code.de> Hi Ben, I changed gpg to include the "grp" record for all secret keys even if --with-keygrip is not used. If there is a real need to have the keygrip also for public keys (without any secret subkey) we may consider to always print the "grp" records. Or we add a new gpgme keylisting mode to enable that. Always printing the keygrip records has a speed penalty of ~1.5% measure with gpgme/tests/run-keylist. I also included the keygrip into the gpgme_subkey_t but did not do any of your other changes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From dkg at fifthhorseman.net Thu Aug 4 22:58:13 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 4 Aug 2016 16:58:13 -0400 Subject: [PATCH] avoid publishing the GnuPG version by default Message-ID: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> * g10/gpg.c (main): initialize opt.emit_version to 0 * doc/gpg.texi: document different default for --emit-version -- The version of GnuPG in use is not particularly helpful. It is not cryptographically verifiable, and it doesn't distinguish between significant version differences like 2.0.x and 2.1.x. Additionally, it leaks metadata that can be used to distinguish users from one another, and can potentially be used to target specific attacks if there are known behaviors that differ between major versions. It's probably better to take the more parsimonious approach to metadata production by default. Signed-off-by: Daniel Kahn Gillmor --- doc/gpg.texi | 4 ++-- g10/gpg.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index c544967..ffbc269 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2713,9 +2713,9 @@ protected by the signature. @opindex emit-version Force inclusion of the version string in ASCII armored output. If given once only the name of the program and the major number is -emitted (default), given twice the minor is also emitted, given triple +emitted, given twice the minor is also emitted, given triple the micro is added, and given quad an operating system identification -is also emitted. @option{--no-emit-version} disables the version +is also emitted. @option{--no-emit-version} (default) disables the version line. @item --sig-notation @code{name=value} diff --git a/g10/gpg.c b/g10/gpg.c index 35d350e..b33b61b 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -2269,7 +2269,7 @@ main (int argc, char **argv) opt.def_cert_expire = "0"; gnupg_set_homedir (NULL); opt.passphrase_repeat = 1; - opt.emit_version = 1; /* Limit to the major number. */ + opt.emit_version = 0; opt.weak_digests = NULL; additional_weak_digest("MD5"); -- 2.8.1 From bjk at luxsci.net Fri Aug 5 00:18:22 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Thu, 4 Aug 2016 18:18:22 -0400 Subject: [PATCH] Add keygrip to LISTKEYS output. In-Reply-To: <87d1loehh9.fsf@wheatstone.g10code.de> References: <1468890724-292716.405388038.fu6J1BnQi002450@rs146.luxsci.com> <87d1loehh9.fsf@wheatstone.g10code.de> Message-ID: <1470349142-153111.274848855.fu74MINPF023647@rs146.luxsci.com> On Thu, Aug 04, 2016 at 04:28:18PM +0200, Werner Koch wrote: > Hi Ben, > > I changed gpg to include the "grp" record for all secret keys even if > --with-keygrip is not used. If there is a real need to have the keygrip > also for public keys (without any secret subkey) we may consider to > always print the "grp" records. Or we add a new gpgme keylisting mode to > enable that. Always printing the keygrip records has a speed penalty of > ~1.5% measure with gpgme/tests/run-keylist. > > I also included the keygrip into the gpgme_subkey_t but did not do any > of your other changes. Thanks. -- Ben Kibbey From bjk at luxsci.net Fri Aug 5 00:20:09 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Thu, 4 Aug 2016 18:20:09 -0400 Subject: [PATCH] Erase memory before freeing. In-Reply-To: <874m73sj5d.fsf@europa.jade-hamburg.de> References: <1470006782-8635504.924451.fu6VNCcXn028026@rs146.luxsci.com> <87oa5cokvw.fsf@europa.jade-hamburg.de> <1470094922-8336086.34567908.fu71NfNvA017971@rs146.luxsci.com> <874m73sj5d.fsf@europa.jade-hamburg.de> Message-ID: <1470349262-8156958.28070813.fu74MKAUc024823@rs146.luxsci.com> On Tue, Aug 02, 2016 at 09:51:42AM +0200, Justus Winter wrote: > Actually, if you allocate both the length and the actual data in one > chunk, you don't need an extra data structure at all and get constant > time lookups, i.e.: > > struct chunk { > size_t size; > char data[0]; > }; > > then on free(p) you do > > chunk *c = p - offsetof(struct chunk, data); Thanks for the info. Good to know. I wonder how much faster it is. I'll do a benchmark sometime to see. -- Ben Kibbey From gniibe at fsij.org Fri Aug 5 10:48:34 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 5 Aug 2016 17:48:34 +0900 Subject: gpg-agent: SSH certificate support Message-ID: <1ae83c4f-90ba-1429-edbc-9489f3e8d673@fsij.org> Hello, I'm considering adding the support of SSH certificate to gpg-agent. Looking the code of ssh_handler_request_identities, I cleaned up the code a bit. Please find a change to limit access to file by findkey.c. The idea is extending the function agent_public_key_from_file. From: agent_public_key_from_file (ctrl, grip, &key_public) to: agent_public_key_from_file (ctrl, grip, &key_public, 1) Last argument is allowing SSH certificate. The function read_key_file will be also extended. From: read_key_file (const unsigned char *grip, gcry_sexp_t *result) to: read_key_file (const unsigned char *grip, gcry_sexp_t *result, int *ssh) When SSH is not NULL, it means allowing returning SSH certificate. If the file .key is in Extended Private Key Format and has OpenSSH-cert field, it will be set as *ssh = 1, and the sexp of RESULT will be in following format: (OpenSSH-cert(blob )) When SSH is NULL or the file .key is not in Extended Private Key Format, or it doesn't have OpenSSH-cert field, public key will be in the format: (public-key((...))) How about that? Anyway, here is a clean up part. diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 48f1b3d..583b4c7 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -814,67 +814,6 @@ stream_copy (estream_t dst, estream_t src) return err; } - - -/* Read the content of the file specified by FILENAME into a newly - create buffer, which is to be stored in BUFFER; store length of - buffer in BUFFER_N. */ -static gpg_error_t -file_to_buffer (const char *filename, unsigned char **buffer, size_t *buffer_n) -{ - unsigned char *buffer_new; - struct stat statbuf; - estream_t stream; - gpg_error_t err; - int ret; - - *buffer = NULL; - *buffer_n = 0; - - buffer_new = NULL; - err = 0; - - stream = es_fopen (filename, "rb"); - if (! stream) - { - err = gpg_error_from_syserror (); - goto out; - } - - ret = fstat (es_fileno (stream), &statbuf); - if (ret) - { - err = gpg_error_from_syserror (); - goto out; - } - - buffer_new = xtrymalloc (statbuf.st_size); - if (! buffer_new) - { - err = gpg_error_from_syserror (); - goto out; - } - - err = stream_read_data (stream, buffer_new, statbuf.st_size); - if (err) - goto out; - - *buffer = buffer_new; - *buffer_n = statbuf.st_size; - - out: - - if (stream) - es_fclose (stream); - - if (err) - xfree (buffer_new); - - return err; -} - - - /* Open the ssh control file and create it if not available. With APPEND passed as true the file will be opened in append mode, @@ -2683,12 +2622,8 @@ static gpg_error_t ssh_handler_request_identities (ctrl_t ctrl, estream_t request, estream_t response) { - ssh_key_type_spec_t spec; - char *key_fname = NULL; - char *fnameptr; u32 key_counter; estream_t key_blobs; - gcry_sexp_t key_secret; gcry_sexp_t key_public; gpg_error_t err; int ret; @@ -2700,7 +2635,6 @@ ssh_handler_request_identities (ctrl_t ctrl, /* Prepare buffer stream. */ - key_secret = NULL; key_public = NULL; key_counter = 0; err = 0; @@ -2729,29 +2663,6 @@ ssh_handler_request_identities (ctrl_t ctrl, key_counter++; } - - /* Prepare buffer for key name construction. */ - { - char *dname; - - dname = make_filename (gnupg_homedir (), GNUPG_PRIVATE_KEYS_DIR, NULL); - if (!dname) - { - err = gpg_err_code_from_syserror (); - goto out; - } - - key_fname = xtrymalloc (strlen (dname) + 1 + 40 + 4 + 1); - if (!key_fname) - { - err = gpg_err_code_from_syserror (); - xfree (dname); - goto out; - } - fnameptr = stpcpy (stpcpy (key_fname, dname), "/"); - xfree (dname); - } - /* Then look at all the registered and non-disabled keys. */ err = open_control_file (&cf, 0); if (err) @@ -2759,52 +2670,27 @@ ssh_handler_request_identities (ctrl_t ctrl, while (!read_control_file_item (cf)) { + unsigned char grip[20]; + if (!cf->item.valid) continue; /* Should not happen. */ if (cf->item.disabled) continue; assert (strlen (cf->item.hexgrip) == 40); + hex2bin (cf->item.hexgrip, grip, sizeof (grip)); - stpcpy (stpcpy (fnameptr, cf->item.hexgrip), ".key"); - - /* Read file content. */ - { - unsigned char *buffer; - size_t buffer_n; - - err = file_to_buffer (key_fname, &buffer, &buffer_n); - if (err) - { - log_error ("%s:%d: key '%s' skipped: %s\n", - cf->fname, cf->lnr, cf->item.hexgrip, - gpg_strerror (err)); - continue; - } - - err = gcry_sexp_sscan (&key_secret, NULL, (char*)buffer, buffer_n); - xfree (buffer); - if (err) - goto out; - } - - { - char *key_type = NULL; - - err = sexp_extract_identifier (key_secret, &key_type); - if (err) - goto out; - - err = ssh_key_type_lookup (NULL, key_type, &spec); - xfree (key_type); - if (err) + err = agent_public_key_from_file (ctrl, grip, &key_public); + if (err) + { + log_error ("failed to read the public key\n"); goto out; - } + } - err = ssh_send_key_public (key_blobs, key_secret, NULL); + err = ssh_send_key_public (key_blobs, key_public, NULL); if (err) goto out; - gcry_sexp_release (key_secret); - key_secret = NULL; + gcry_sexp_release (key_public); + key_public = NULL; key_counter++; } @@ -2820,7 +2706,6 @@ ssh_handler_request_identities (ctrl_t ctrl, out: /* Send response. */ - gcry_sexp_release (key_secret); gcry_sexp_release (key_public); if (!err) @@ -2838,7 +2723,6 @@ ssh_handler_request_identities (ctrl_t ctrl, es_fclose (key_blobs); close_control_file (cf); - xfree (key_fname); return ret_err; } -- From ilf at zeromail.org Fri Aug 5 10:53:57 2016 From: ilf at zeromail.org (ilf) Date: Fri, 5 Aug 2016 10:53:57 +0200 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <20160805085357.GH19126@zeromail.org> Daniel Kahn Gillmor: > The version of GnuPG in use is not particularly helpful. > It's probably better to take the more parsimonious approach to > metadata production by default. Werner, Daniel and I talked about this at the OpenPGP-session during IETF 96. [1] Thanks Daniel, for following up on this! I fully support this proposal. Since "Pervasive Monitoring Is an Attack" [2], let's minimize metadata as much as possible, especially if it's unencrypted *and* not cryptographically verifiable. The riseup.net "OpenPGP Best Practices" [3] refer to a gpg.conf [4] which already implements "no-emit-version". I and many other people have been using this with many implementations on many plattforms for a long time, without any problems. So I see no technical reason against the proposal. Even RFC 4880 lists no pressing reason for including this by default: > The Armor Headers are pairs of strings that can give the user or the > receiving OpenPGP implementation some information about how to decode > or use the message. [5] I can't see how "Version: GnuPG v2" tells me or an OpenPGP implementation "how to decode or use the message". Let's just drop it. 1. https://datatracker.ietf.org/doc/minutes-96-openpgp/ 2. https://tools.ietf.org/html/rfc7258 3. https://riseup.net/en/security/message-security/openpgp/best-practices 4. https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf 5. https://tools.ietf.org/html/rfc4880#page-55 -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From wk at gnupg.org Fri Aug 5 12:28:58 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Aug 2016 12:28:58 +0200 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <20160805085357.GH19126@zeromail.org> (ilf@zeromail.org's message of "Fri, 5 Aug 2016 10:53:57 +0200") References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <20160805085357.GH19126@zeromail.org> Message-ID: <87oa57a4r9.fsf@wheatstone.g10code.de> On Fri, 5 Aug 2016 10:53, ilf at zeromail.org said: >> The Armor Headers are pairs of strings that can give the user or the >> receiving OpenPGP implementation some information about how to >> decode or use the message. [5] > > I can't see how "Version: GnuPG v2" tells me or an OpenPGP > implementation "how to decode or use the message". You are right, the "Version:" has no technical meaning. The "Hash: foo" header for cleartext signatures is required to replace the one-pass signature packets we have in binary signatures. > Let's just drop it. I just pushed dkg's patch to master. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Fri Aug 5 13:28:44 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Aug 2016 13:28:44 +0200 Subject: gpg-agent: SSH certificate support In-Reply-To: <1ae83c4f-90ba-1429-edbc-9489f3e8d673@fsij.org> (NIIBE Yutaka's message of "Fri, 5 Aug 2016 17:48:34 +0900") References: <1ae83c4f-90ba-1429-edbc-9489f3e8d673@fsij.org> Message-ID: <87k2fva1zn.fsf@wheatstone.g10code.de> On Fri, 5 Aug 2016 10:48, gniibe at fsij.org said: > read_key_file (const unsigned char *grip, gcry_sexp_t *result, int *ssh) > > When SSH is not NULL, it means allowing returning SSH certificate. I would suggest to change to "char **ssh" and return a malloced buffer with the certificate (in some encoding). The creation and parsing of the s-expressions is quite complicate when not using Lisp and we need to return that data anyway as a plain buffer. This way we reduce the risk of introducing bugs in code paths not related to the ssh certificates. To be future proof an strlist_t could also be used which would allow to return several certifciates or other info. > Anyway, here is a clean up part. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From dkg at fifthhorseman.net Fri Aug 5 06:20:06 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Aug 2016 00:20:06 -0400 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <147036309446.28989.15300563108391407497@solidarity.enteig.net> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> Message-ID: <87oa576e4p.fsf@alice.fifthhorseman.net> On Thu 2016-08-04 22:11:34 -0400, malte at wk3.org wrote: > Quoting Daniel Kahn Gillmor (2016-08-04 22:58:13) >> * g10/gpg.c (main): initialize opt.emit_version to 0 >> * doc/gpg.texi: document different default for --emit-version > > Oh yes! And then > > opt.keyid_format = KF_0xLONG; > > if not even > > opt.with_fingerprint = 1; Have you used gnupg 2.1.14 yet? with no explicit configuration, "gpg --list-keys" produces: pub rsa2048 2016-08-05 [SC] 8131AB931A0CF6A48F2ACA03113C9F13434695EA uid [ultimate] Alice sub rsa2048 2016-08-05 [E] the GnuPG devs are way ahead of you ;) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From ilf at zeromail.org Fri Aug 5 14:43:10 2016 From: ilf at zeromail.org (ilf) Date: Fri, 5 Aug 2016 14:43:10 +0200 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <87oa576e4p.fsf@alice.fifthhorseman.net> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> Message-ID: <20160805124310.GM19126@zeromail.org> Daniel Kahn Gillmor: > with no explicit configuration, "gpg --list-keys" produces: > pub rsa2048 2016-08-05 [SC] > 8131AB931A0CF6A48F2ACA03113C9F13434695EA > uid [ultimate] Alice > sub rsa2048 2016-08-05 [E] Very nice! But it seems counter-intuitive that "keyid-format" still overrides this, especially since people have set that manually already. % gpg --options /dev/null --list-keys 80615870F5BAD690333686D0F2AD85AC1E42B367 pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31] 80615870F5BAD690333686D0F2AD85AC1E42B367 uid [ full ] Werner Koch uid [ full ] Werner Koch uid [ full ] Werner Koch sub rsa2048 2014-01-02 [E] [expires: 2016-12-31] sub dsa1024 2011-11-02 [S] % gpg --options /dev/null --keyid-format 0xlong --list-keys 80615870F5BAD690333686D0F2AD85AC1E42B367 pub dsa2048/0xF2AD85AC1E42B367 2007-12-31 [SC] [expires: 2018-12-31] uid [ full ] Werner Koch uid [ full ] Werner Koch uid [ full ] Werner Koch sub rsa2048/0x1E0FE11D664D7444 2014-01-02 [E] [expires: 2016-12-31] sub dsa1024/0x4F0540D577F95F95 2011-11-02 [S] How about removing the "keyid-format" option alltogether? -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From wk at gnupg.org Fri Aug 5 14:53:17 2016 From: wk at gnupg.org (wk at gnupg.org) Date: Fri, 5 Aug 2016 14:53:17 +0200 Subject: [PATCH] gpg: Remove tofu database format "split". Message-ID: <1470401597-30913-1-git-send-email-wk@gnupg.org> From: Werner Koch * g10/options.h (struct opt): Remove field tofu_db_format. * g10/gpg.h (server_control_s): Add fields tofu.batch_update_ref and tofu.batch_update_started. * g10/gpg.c (parse_tofu_db_format): Remove. (main): Make option --tofu-db-format obsolete. * g10/tofu.c: Major rework. Remove the pretty complicated and slower split format and with that all the caching. Use the dbs struct directly. Move global vars for batch update into CTRL. Change calling conventions of some function to take CTRL or DBS pointers instead of the former low-level database pointer. -- The split database format might have been nice for use with Unison but it bypasses the concept of a relational database by doing parts of this itself and also risking deadlocks. Working with the Tofu database for debugging or experiments is also not possible with parts of the database logic implemented in gpg. The Tofu support is quite new and we can assume that it is not in real use now. Thus we better remove that now so that we do not need to maintain it for all future. Signed-off-by: Werner Koch --- doc/DETAILS | 52 +++ doc/gpg.texi | 19 -- g10/gpg.c | 31 +- g10/gpg.h | 2 + g10/gpgv.c | 6 +- g10/keylist.c | 4 +- g10/options.h | 6 +- g10/test-stubs.c | 6 +- g10/tofu.c | 869 +++++++++---------------------------------------- g10/tofu.h | 4 +- tests/openpgp/tofu.scm | 2 +- 11 files changed, 230 insertions(+), 771 deletions(-) diff --git a/doc/DETAILS b/doc/DETAILS index 02f9bad..3c49556 100644 --- a/doc/DETAILS +++ b/doc/DETAILS @@ -1141,6 +1141,55 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB: stored in the version info record. +* Database scheme for the TOFU info + +#+begin_src sql +-- +-- The VERSION table holds the version of our TOFU data structures. +-- +CREATE TABLE version ( + version integer -- As of now this is always 1 +); + +-- +-- The BINDINGS table associates mail addresses with keys. +-- +CREATE TABLE bindings ( + oid integer primary key autoincrement, + fingerprint text, -- The key's fingerprint in hex + email text, -- The normalized mail address destilled from user_id + user_id text, -- The unmodified user id + time integer, -- The time this binding was first observed. + policy boolean check + (policy in (1, 2, 3, 4, 5)), -- The trust policy with the values: + -- 1 := Auto + -- 2 := Good + -- 3 := Unknown + -- 4 := Bad + -- 5 := Ask + conflict string, -- NULL or a hex formatted fingerprint. + unique (fingerprint, email) +); + +CREATE INDEX bindings_fingerprint_email on bindings (fingerprint, email); +CREATE INDEX bindings_email on bindings (email); + +-- +-- The SIGNATURES table records all data signatures we verified +-- +CREATE TABLE signatures ( + binding integer not null, -- Link to bindings table, + -- references bindings.oid. + sig_digest text, -- The digest of the signed message. + origin text, -- String describing who initially fed + -- the signature to gpg (e.g. "email:claws"). + sig_time integer, -- Timestamp from the signature. + time integer, -- Time this record was created. + primary key (binding, sig_digest, origin) +); +#+end_src + + * GNU extensions to the S2K algorithm 1 octet - S2K Usage: either 254 or 255. @@ -1166,6 +1215,9 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB: * Keyserver helper message format + *This information is obsolete* + (Keyserver helpers have been replaced by dirmngr) + The keyserver may be contacted by a Unix Domain socket or via TCP. The format of a request is: diff --git a/doc/gpg.texi b/doc/gpg.texi index ffbc269..944734b 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -1840,25 +1840,6 @@ key signer (defaults to 3) The default TOFU policy (defaults to @code{auto}). For more information about the meaning of this option, @xref{trust-model-tofu}. - at item --tofu-db-format @code{auto|split|flat} - at opindex tofu-default-policy -The format for the TOFU DB. - -The split file format splits the data across many DBs under the - at code{tofu.d} directory (one per email address and one per key). This -makes it easier to automatically synchronize the data using a tool -such as Unison (@url{https://www.cis.upenn.edu/~bcpierce/unison/}), -since the individual files change rarely. - -The flat file format keeps all of the data in the single file - at code{tofu.db}. This format results in better performance. - -If set to auto (which is the default), GnuPG will first check for the -existence of @code{tofu.d} and @code{tofu.db}. If one of these -exists, the corresponding format is used. If neither or both of these -exist, then GnuPG defaults to the @code{split} format. In the latter -case, a warning is emitted. - @item --max-cert-depth @code{n} @opindex max-cert-depth Maximum depth of a certification chain (default is 5). diff --git a/g10/gpg.c b/g10/gpg.c index b33b61b..640a3cf 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -709,7 +709,6 @@ static ARGPARSE_OPTS opts[] = { #endif ARGPARSE_s_s (oTrustModel, "trust-model", "@"), ARGPARSE_s_s (oTOFUDefaultPolicy, "tofu-default-policy", "@"), - ARGPARSE_s_s (oTOFUDBFormat, "tofu-db-format", "@"), ARGPARSE_s_s (oSetFilename, "set-filename", "@"), ARGPARSE_s_n (oForYourEyesOnly, "for-your-eyes-only", "@"), ARGPARSE_s_n (oNoForYourEyesOnly, "no-for-your-eyes-only", "@"), @@ -851,6 +850,7 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_s_s (opcscDriver, "pcsc-driver", "@"), ARGPARSE_s_n (oDisableCCID, "disable-ccid", "@"), ARGPARSE_s_n (oHonorHttpProxy, "honor-http-proxy", "@"), + ARGPARSE_s_s (oTOFUDBFormat, "tofu-db-format", "@"), /* Dummy options. */ ARGPARSE_s_n (oNoop, "sk-comments", "@"), @@ -2020,32 +2020,6 @@ parse_tofu_policy (const char *policystr) g10_exit (1); } -static int -parse_tofu_db_format (const char *db_format) -{ -#ifdef USE_TOFU - if (ascii_strcasecmp (db_format, "auto") == 0) - return TOFU_DB_AUTO; - else if (ascii_strcasecmp (db_format, "split") == 0) - return TOFU_DB_SPLIT; - else if (ascii_strcasecmp (db_format, "flat") == 0) - return TOFU_DB_FLAT; - else if (ascii_strcasecmp (db_format, "help") == 0) - { - log_info ("available TOFU DB fomats: auto, split, flat\n"); - g10_exit (1); - } - else -#endif /*USE_TOFU*/ - { - log_error (_("unknown TOFU DB format '%s'\n"), db_format); - if (!opt.quiet) - log_info (_("(use \"help\" to list choices)\n")); - g10_exit (1); - } -} - - /* This function called to initialized a new control object. It is assumed that this object has been zeroed out before calling this function. */ @@ -2260,7 +2234,6 @@ main (int argc, char **argv) opt.trust_model = TM_AUTO; #endif opt.tofu_default_policy = TOFU_POLICY_AUTO; - opt.tofu_db_format = TOFU_DB_AUTO; opt.mangle_dos_filenames = 0; opt.min_cert_level = 2; set_screen_dimensions (); @@ -2700,7 +2673,7 @@ main (int argc, char **argv) opt.tofu_default_policy = parse_tofu_policy (pargs.r.ret_str); break; case oTOFUDBFormat: - opt.tofu_db_format = parse_tofu_db_format (pargs.r.ret_str); + obsolete_option (configname, configlineno, "tofu-db-format"); break; case oForceOwnertrust: diff --git a/g10/gpg.h b/g10/gpg.h index c0f0a2d..1aaff2f 100644 --- a/g10/gpg.h +++ b/g10/gpg.h @@ -82,6 +82,8 @@ struct server_control_s /* Local data for tofu.c */ struct { tofu_dbs_t dbs; + int batch_update_ref; + time_t batch_update_started; } tofu; }; diff --git a/g10/gpgv.c b/g10/gpgv.c index d08dc5a..11106a2 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -689,11 +689,13 @@ tofu_policy_str (enum tofu_policy policy) } void -tofu_begin_batch_update (void) +tofu_begin_batch_update (ctrl_t ctrl) { + (void)ctrl; } void -tofu_end_batch_update (void) +tofu_end_batch_update (ctrl_t ctrl) { + (void)ctrl; } diff --git a/g10/keylist.c b/g10/keylist.c index 60b8f23..59344b2 100644 --- a/g10/keylist.c +++ b/g10/keylist.c @@ -134,7 +134,7 @@ public_key_list (ctrl_t ctrl, strlist_t list, int locate_mode) check_trustdb_stale (ctrl); #ifdef USE_TOFU - tofu_begin_batch_update (); + tofu_begin_batch_update (ctrl); #endif if (locate_mode) @@ -145,7 +145,7 @@ public_key_list (ctrl_t ctrl, strlist_t list, int locate_mode) list_one (ctrl, list, 0, opt.with_secret); #ifdef USE_TOFU - tofu_end_batch_update (); + tofu_end_batch_update (ctrl); #endif } diff --git a/g10/options.h b/g10/options.h index ccd8acb..d1c3634 100644 --- a/g10/options.h +++ b/g10/options.h @@ -116,17 +116,13 @@ struct int skip_verify; int skip_hidden_recipients; - /* TM_CLASSIC must be zero to accommodate trustdbs generated before + /* TM_CLASSIC must be zero to accommodate trustdbsg generated before we started storing the trust model inside the trustdb. */ enum { TM_CLASSIC=0, TM_PGP=1, TM_EXTERNAL=2, TM_ALWAYS, TM_DIRECT, TM_AUTO, TM_TOFU, TM_TOFU_PGP } trust_model; - enum - { - TOFU_DB_AUTO=0, TOFU_DB_SPLIT, TOFU_DB_FLAT - } tofu_db_format; enum tofu_policy tofu_default_policy; int force_ownertrust; enum diff --git a/g10/test-stubs.c b/g10/test-stubs.c index 6f50759..781f98c 100644 --- a/g10/test-stubs.c +++ b/g10/test-stubs.c @@ -497,11 +497,13 @@ tofu_policy_str (enum tofu_policy policy) } void -tofu_begin_batch_update (void) +tofu_begin_batch_update (ctrl_t ctrl) { + (void)ctrl; } void -tofu_end_batch_update (void) +tofu_end_batch_update (ctrl_t ctrl) { + (void)ctrl; } diff --git a/g10/tofu.c b/g10/tofu.c index a2732ff..ef14e85 100644 --- a/g10/tofu.c +++ b/g10/tofu.c @@ -55,46 +55,14 @@ #define FULL_TRUST_THRESHOLD 100 -#define DEBUG_TOFU_CACHE 0 -#if DEBUG_TOFU_CACHE -static int prepares_saved; -static int queries; -#endif - -/* The TOFU data can be saved in two different formats: either in a - single combined database (opt.tofu_db_format == TOFU_DB_FLAT) or in - a split file format (opt.tofu_db_format == TOFU_DB_SPLIT). In the - split format, there is one database per normalized email address - (DB_EMAIL) and one per key (DB_KEY). */ -enum db_type - { - DB_COMBINED, - DB_EMAIL, - DB_KEY - }; - -/* A list of open DBs. - - In the flat format, this consists of a single element with the type - DB_COMBINED and whose name is the empty string. - - In the split format, the first element is a dummy element (DB is - NULL) whose type is DB_COMBINED and whose name is the empty string. - Any following elements describe either DB_EMAIL or DB_KEY DBs. In - theis case, NAME is either the normalized email address or the - fingerprint. +/* An struct with data pertaining to the tofu DB. To initialize this data structure, call opendbs(). Cleanup is done when the CTRL object is released. To get a handle to a database, use the getdb() function. This will either return an existing handle or open a new DB connection, as appropriate. */ -struct db +struct tofu_dbs_s { - struct db *next; - struct db **prevp; - - enum db_type type; - sqlite3 *db; struct @@ -116,34 +84,9 @@ struct db sqlite3_stmt *register_insert; } s; -#if DEBUG_TOFU_CACHE - int hits; -#endif - int batch_update; - - /* If TYPE is DB_COMBINED, this is "". Otherwise, it is either the - fingerprint (type == DB_KEY) or the normalized email address - (type == DB_EMAIL). */ - char name[1]; }; -static struct db *db_cache; -static int db_cache_count; -#define DB_CACHE_ENTRIES 16 - -static void tofu_cache_dump (struct db *db) GPGRT_ATTR_USED; - -static void -tofu_cache_dump (struct db *db) -{ - log_info ("Connection %p:\n", db); - for (; db; db = db->next) - log_info (" %s: %sbatch mode\n", db->name, db->batch_update ? "" : "NOT "); - log_info ("Cache:\n"); - for (db = db_cache; db; db = db->next) - log_info (" %s: %sbatch mode\n", db->name, db->batch_update ? "" : "NOT "); -} #define STRINGIFY(s) STRINGIFY2(s) #define STRINGIFY2(s) #s @@ -167,8 +110,11 @@ tofu_cache_dump (struct db *db) # define TIME_AGO_UNIT_LARGE (30 * 24 * 60 * 60) #endif - +/* Local prototypes. */ +static gpg_error_t end_transaction (ctrl_t ctrl, int only_batch); + + const char * tofu_policy_str (enum tofu_policy policy) { @@ -213,83 +159,63 @@ tofu_policy_to_trust_level (enum tofu_policy policy) return 0; } } - -static int batch_update; -static time_t batch_update_started; -static gpg_error_t end_transaction (struct db *db, int only_batch); + /* Start a transaction on DB. */ static gpg_error_t -begin_transaction (struct db *db, int only_batch) +begin_transaction (ctrl_t ctrl, int only_batch) { + tofu_dbs_t dbs = ctrl->tofu.dbs; int rc; char *err = NULL; - if (batch_update && batch_update_started != gnupg_get_time ()) - /* We've been in batch update mode for a while (on average, more - than 500 ms). To prevent starving other gpg processes, we drop - and retake the batch lock. + log_assert (dbs); - Note: if we wanted higher resolution, we could use - npth_clock_gettime. */ + if (ctrl->tofu.batch_update_ref + && ctrl->tofu.batch_update_started != gnupg_get_time ()) { - struct db *t; - - for (t = db_cache; t; t = t->next) - if (t->batch_update) - end_transaction (t, 1); - for (t = db; t; t = t->next) - if (t->batch_update) - end_transaction (t, 1); + /* We've been in batch update mode for a while (on average, more + * than 500 ms). To prevent starving other gpg processes, we + * drop and retake the batch lock. + * + * Note: if we wanted higher resolution, we could use + * npth_clock_gettime. */ + if (dbs->batch_update) + end_transaction (ctrl, 1); - batch_update_started = gnupg_get_time (); + ctrl->tofu.batch_update_started = gnupg_get_time (); /* Yield to allow another process a chance to run. */ gpgrt_yield (); } - /* XXX: In split mode, this can end in deadlock. - - Consider: we have two gpg processes running simultaneously and - they each want to lock DB A and B, but in different orders. This - will be automatically resolved by causing one of them to return - EBUSY and aborting. - - A more intelligent approach would be to commit and retake the - batch transaction. This requires a list of all DBs that are - currently in batch mode. */ - - if (batch_update && ! db->batch_update) + if (ctrl->tofu.batch_update_ref && !dbs->batch_update) { - rc = gpgsql_stepx (db->db, &db->s.savepoint_batch, + rc = gpgsql_stepx (dbs->db, &dbs->s.savepoint_batch, NULL, NULL, &err, "savepoint batch;", SQLITE_ARG_END); if (rc) { log_error (_("error beginning transaction on TOFU database: %s\n"), err); - print_further_info ("batch, database '%s'", - *db->name ? db->name : "[combined]"); sqlite3_free (err); return gpg_error (GPG_ERR_GENERAL); } - db->batch_update = 1; + dbs->batch_update = 1; } if (only_batch) return 0; - rc = gpgsql_stepx (db->db, &db->s.savepoint_inner, + rc = gpgsql_stepx (dbs->db, &dbs->s.savepoint_inner, NULL, NULL, &err, "savepoint inner;", SQLITE_ARG_END); if (rc) { log_error (_("error beginning transaction on TOFU database: %s\n"), err); - print_further_info ("inner, database '%s'", - *db->name ? db->name : "[combined]"); sqlite3_free (err); return gpg_error (GPG_ERR_GENERAL); } @@ -297,34 +223,34 @@ begin_transaction (struct db *db, int only_batch) return 0; } + /* Commit a transaction. If ONLY_BATCH is 1, then this only ends the - batch transaction if we have left batch mode. If ONLY_BATCH is 2, - this ends any open batch transaction even if we are still in batch - mode. */ + * batch transaction if we have left batch mode. If ONLY_BATCH is 2, + * this ends any open batch transaction even if we are still in batch + * mode. */ static gpg_error_t -end_transaction (struct db *db, int only_batch) +end_transaction (ctrl_t ctrl, int only_batch) { + tofu_dbs_t dbs = ctrl->tofu.dbs; int rc; char *err = NULL; - if (!db) + if (!dbs) return 0; /* Shortcut to allow for easier cleanup code. */ - if ((! batch_update || only_batch == 2) && db->batch_update) - /* The batch transaction is still in open, but we left batch - mode. */ + if ((!ctrl->tofu.batch_update_ref || only_batch == 2) && dbs->batch_update) { - db->batch_update = 0; + /* The batch transaction is still in open, but we left batch + * mode. */ + dbs->batch_update = 0; - rc = gpgsql_stepx (db->db, &db->s.savepoint_batch_commit, + rc = gpgsql_stepx (dbs->db, &dbs->s.savepoint_batch_commit, NULL, NULL, &err, "release batch;", SQLITE_ARG_END); if (rc) { log_error (_("error committing transaction on TOFU database: %s\n"), err); - print_further_info ("batch, database '%s'", - *db->name ? db->name : "[combined]"); sqlite3_free (err); return gpg_error (GPG_ERR_GENERAL); } @@ -337,15 +263,13 @@ end_transaction (struct db *db, int only_batch) if (only_batch) return 0; - rc = gpgsql_stepx (db->db, &db->s.savepoint_inner_commit, + rc = gpgsql_stepx (dbs->db, &dbs->s.savepoint_inner_commit, NULL, NULL, &err, "release inner;", SQLITE_ARG_END); if (rc) { log_error (_("error committing transaction on TOFU database: %s\n"), err); - print_further_info ("inner, database '%s'", - *db->name ? db->name : "[combined]"); sqlite3_free (err); return gpg_error (GPG_ERR_GENERAL); } @@ -353,29 +277,33 @@ end_transaction (struct db *db, int only_batch) return 0; } + static gpg_error_t -rollback_transaction (struct db *db) +rollback_transaction (ctrl_t ctrl) { + tofu_dbs_t dbs = ctrl->tofu.dbs; int rc; char *err = NULL; - if (!db) + if (!dbs) return 0; /* Shortcut to allow for easier cleanup code. */ - if (db->batch_update) - /* Just undo the most recent update; don't revert any progress - made by the batch transaction. */ - rc = sqlite3_exec (db->db, "rollback to inner;", NULL, NULL, &err); + if (dbs->batch_update) + { + /* Just undo the most recent update; don't revert any progress + made by the batch transaction. */ + rc = sqlite3_exec (dbs->db, "rollback to inner;", NULL, NULL, &err); + } else - /* Rollback the whole she-bang. */ - rc = sqlite3_exec (db->db, "rollback;", NULL, NULL, &err); + { + /* Rollback the whole she-bang. */ + rc = sqlite3_exec (dbs->db, "rollback;", NULL, NULL, &err); + } if (rc) { log_error (_("error rolling back transaction on TOFU database: %s\n"), err); - print_further_info ("inner, database '%s'", - *db->name ? db->name : "[combined]"); sqlite3_free (err); return gpg_error (GPG_ERR_GENERAL); } @@ -384,27 +312,22 @@ rollback_transaction (struct db *db) } void -tofu_begin_batch_update (void) +tofu_begin_batch_update (ctrl_t ctrl) { - if (! batch_update) - batch_update_started = gnupg_get_time (); + if (!ctrl->tofu.batch_update_ref) + ctrl->tofu.batch_update_started = gnupg_get_time (); - batch_update ++; + ctrl->tofu.batch_update_ref ++; } void -tofu_end_batch_update (void) +tofu_end_batch_update (ctrl_t ctrl) { - log_assert (batch_update > 0); - batch_update --; + log_assert (ctrl->tofu.batch_update_ref > 0); + ctrl->tofu.batch_update_ref --; - if (batch_update == 0) - { - struct db *db; - - for (db = db_cache; db; db = db->next) - end_transaction (db, 1); - } + if (!ctrl->tofu.batch_update_ref) + end_transaction (ctrl, 1); } @@ -523,7 +446,7 @@ version_check_cb (void *cookie, int argc, char **argv, char **azColName) Return 0 if the database is okay and 1 otherwise. */ static int -initdb (sqlite3 *db, enum db_type type) +initdb (sqlite3 *db) { char *err = NULL; int rc; @@ -639,8 +562,7 @@ initdb (sqlite3 *db, enum db_type type) * the old binding's policy to ask if it was auto. So that we * know why this occurred, we also set conflict to 0xbaddecaf. */ - if (type == DB_EMAIL || type == DB_COMBINED) - rc = gpgsql_exec_printf + rc = gpgsql_exec_printf (db, NULL, NULL, &err, "create table bindings\n" " (oid INTEGER PRIMARY KEY AUTOINCREMENT,\n" @@ -653,20 +575,6 @@ initdb (sqlite3 *db, enum db_type type) "create index bindings_email on bindings (email);\n", TOFU_POLICY_AUTO, TOFU_POLICY_GOOD, TOFU_POLICY_UNKNOWN, TOFU_POLICY_BAD, TOFU_POLICY_ASK); - else - /* In the split DB case, the fingerprint DB only contains a subset - of the fields. This reduces the amount of duplicated data. - - Note: since the data is split on the email address, there is no - need to index the email column. */ - rc = gpgsql_exec_printf - (db, NULL, NULL, &err, - "create table bindings\n" - " (oid INTEGER PRIMARY KEY AUTOINCREMENT,\n" - " fingerprint TEXT, email TEXT, user_id,\n" - " unique (fingerprint, email));\n" - "create index bindings_fingerprint\n" - " on bindings (fingerprint);\n"); if (rc) { log_error (_("error initializing TOFU database: %s\n"), err); @@ -675,35 +583,32 @@ initdb (sqlite3 *db, enum db_type type) goto out; } - if (type != DB_KEY) - { - /* The signatures that we have observed. - - BINDING refers to a record in the bindings table, which - describes the binding (i.e., this is a foreign key that - references bindings.oid). - - SIG_DIGEST is the digest stored in the signature. - - SIG_TIME is the timestamp stored in the signature. - - ORIGIN is a free-form string that describes who fed this - signature to GnuPG (e.g., email:claws). - - TIME is the time this signature was registered. */ - rc = sqlite3_exec (db, + /* The signatures that we have observed. + * + * BINDING refers to a record in the bindings table, which + * describes the binding (i.e., this is a foreign key that + * references bindings.oid). + * + * SIG_DIGEST is the digest stored in the signature. + * + * SIG_TIME is the timestamp stored in the signature. + * + * ORIGIN is a free-form string that describes who fed this + * signature to GnuPG (e.g., email:claws). + * + * TIME is the time this signature was registered. */ + rc = sqlite3_exec (db, "create table signatures " " (binding INTEGER NOT NULL, sig_digest TEXT," " origin TEXT, sig_time INTEGER, time INTEGER," " primary key (binding, sig_digest, origin));", NULL, NULL, &err); - if (rc) - { - log_error (_("error initializing TOFU database: %s\n"), err); - print_further_info ("create signatures"); - sqlite3_free (err); - goto out; - } + if (rc) + { + log_error (_("error initializing TOFU database: %s\n"), err); + print_further_info ("create signatures"); + sqlite3_free (err); + goto out; } out: @@ -732,408 +637,79 @@ initdb (sqlite3 *db, enum db_type type) } } -/* Open and initialize a low-level TOFU database. Returns NULL on - failure. This function should not normally be directly called to - get a database handle. Instead, use getdb(). */ -static sqlite3 * -opendb (char *filename, enum db_type type) + +/* Create a new DB handle. Returns NULL on error. */ +/* FIXME: Change to return an error code for better reporting by the + caller. */ +static tofu_dbs_t +opendbs (ctrl_t ctrl) { + char *filename; sqlite3 *db; - int filename_free = 0; int rc; - if (opt.tofu_db_format == TOFU_DB_FLAT) + if (!ctrl->tofu.dbs) { - log_assert (! filename); - log_assert (type == DB_COMBINED); - filename = make_filename (gnupg_homedir (), "tofu.db", NULL); - filename_free = 1; - } - else - log_assert (type == DB_EMAIL || type == DB_KEY); - - log_assert (filename); - - rc = sqlite3_open (filename, &db); - if (rc) - { - log_error (_("error opening TOFU database '%s': %s\n"), - filename, sqlite3_errmsg (db)); - /* Even if an error occurs, DB is guaranteed to be valid. */ - sqlite3_close (db); - db = NULL; - } - - /* If a DB is locked wait up to 5 seconds for the lock to be cleared - before failing. */ - if (db) - sqlite3_busy_timeout (db, 5 * 1000); - - if (filename_free) - xfree (filename); - - if (db && initdb (db, type)) - { - sqlite3_close (db); - db = NULL; - } - - return db; -} - -/* Definition of the Tofu dabase meta handle. */ -struct tofu_dbs_s -{ - struct db *db; -}; - -static void -unlink_db (struct db *db) -{ - *db->prevp = db->next; - if (db->next) - db->next->prevp = db->prevp; -} - -static void -link_db (struct db **head, struct db *db) -{ - db->next = *head; - if (db->next) - db->next->prevp = &db->next; - db->prevp = head; - *head = db; -} - -/* Return a database handle. describes the required - database. If there is a cached handle in DBS, that handle is - returned. Otherwise, the database is opened and cached in DBS. - - NAME is the name of the DB and may not be NULL. - TYPE must be either DB_MAIL or DB_KEY. In the combined format, the - combined DB is always returned. */ -static struct db * -getdb (tofu_dbs_t dbs, const char *name, enum db_type type) -{ - struct db *t = NULL; - char *name_sanitized = NULL; - int count; - char *filename = NULL; - int need_link = 1; - sqlite3 *sqlitedb = NULL; - gpg_error_t rc; - - log_assert (dbs); - log_assert (name); - log_assert (type == DB_EMAIL || type == DB_KEY); - - if (opt.tofu_db_format == TOFU_DB_FLAT) - /* When using the flat format, we only have a single DB, the - combined DB. */ - { - if (dbs->db) + rc = sqlite3_open (filename, &db); + if (rc) { - log_assert (dbs->db->type == DB_COMBINED); - log_assert (! dbs->db->next); - return dbs->db; + log_error (_("error opening TOFU database '%s': %s\n"), + filename, sqlite3_errmsg (db)); + /* Even if an error occurs, DB is guaranteed to be valid. */ + sqlite3_close (db); + db = NULL; } + xfree (filename); - type = DB_COMBINED; - } - - if (type != DB_COMBINED) - /* Only allow alpha-numeric characters in the name. */ - { - int i; + /* If a DB is locked wait up to 5 seconds for the lock to be cleared + before failing. */ + if (db) + sqlite3_busy_timeout (db, 5 * 1000); - name_sanitized = xstrdup (name); - for (i = 0; name[i]; i ++) + if (db && initdb (db)) { - char c = name_sanitized[i]; - if (! (('a' <= c && c <= 'z') - || ('A' <= c && c <= 'Z') - || ('0' <= c && c <= '9'))) - name_sanitized[i] = '_'; + sqlite3_close (db); + db = NULL; } - } - - /* See if the DB is cached. */ - for (t = dbs->db; t; t = t->next) - if (t->type == type - && (type == DB_COMBINED || strcmp (t->name, name_sanitized) == 0)) - { - need_link = 0; - goto out; - } - - for (t = db_cache, count = 0; t; t = t->next, count ++) - if (type == t->type - && (type == DB_COMBINED || strcmp (t->name, name_sanitized) == 0)) - { - unlink_db (t); - db_cache_count --; - goto out; - } - - log_assert (db_cache_count == count); - - if (type == DB_COMBINED) - filename = NULL; - else - { - /* Open the DB. The filename has the form: - - tofu.d/TYPE/PREFIX/NAME.db - - We use a short prefix to try to avoid having many files in a - single directory. */ - { - char *type_str = type == DB_EMAIL ? "email" : "key"; - char prefix[3] = { name_sanitized[0], name_sanitized[1], 0 }; - char *name_db; - - /* Make the directory. */ - rc = gnupg_mkdir_p (gnupg_homedir (), "tofu.d", type_str, prefix, NULL); - if (rc) - { - name_db = xstrconcat (gnupg_homedir (), "tofu.d", - type_str, prefix, NULL); - log_error (_("can't create directory '%s': %s\n"), - name_db, gpg_strerror (rc)); - xfree (name_db); - goto out; - } - - name_db = xstrconcat (name_sanitized, ".db", NULL); - filename = make_filename - (gnupg_homedir (), "tofu.d", type_str, prefix, name_db, NULL); - xfree (name_db); - } - } - - sqlitedb = opendb (filename, type); - if (! sqlitedb) - goto out; - - t = xmalloc_clear (sizeof (struct db) - + (name_sanitized ? strlen (name_sanitized) : 0)); - t->type = type; - t->db = sqlitedb; - if (name_sanitized) - strcpy (t->name, name_sanitized); - - out: - if (t && need_link) - link_db (&dbs->db, t); - -#if DEBUG_TOFU_CACHE - if (t) - t->hits ++; -#endif - - xfree (filename); - xfree (name_sanitized); - return t; -} - -static void -closedb (struct db *db) -{ - sqlite3_stmt **statements; - if (opt.tofu_db_format == TOFU_DB_FLAT) - /* If we are using the flat format, then there is only ever the - combined DB. */ - log_assert (! db->next); - - if (db->type == DB_COMBINED) - { - log_assert (opt.tofu_db_format == TOFU_DB_FLAT); - log_assert (! db->name[0]); + if (db) + { + ctrl->tofu.dbs = xmalloc_clear (sizeof *ctrl->tofu.dbs); + ctrl->tofu.dbs->db = db; + } } else - { - log_assert (opt.tofu_db_format == TOFU_DB_SPLIT); - log_assert (db->type != DB_COMBINED); - log_assert (db->name[0]); - } - - if (db->batch_update) - end_transaction (db, 2); - - for (statements = (void *) &db->s; - (void *) statements < (void *) &(&db->s)[1]; - statements ++) - sqlite3_finalize (*statements); - - sqlite3_close (db->db); - -#if DEBUG_TOFU_CACHE - log_debug ("Freeing db. Used %d times.\n", db->hits); -#endif - - xfree (db); -} - - -/* Create a new DB meta-handle. Returns NULL on error. */ -/* FIXME: Change to return an error code for better reporting by the - caller. */ -static tofu_dbs_t -opendbs (ctrl_t ctrl) -{ - if (ctrl->tofu.dbs) - return ctrl->tofu.dbs; - - if (opt.tofu_db_format == TOFU_DB_AUTO) - { - char *filename = make_filename (gnupg_homedir (), "tofu.db", NULL); - struct stat s; - int have_tofu_db = 0; - int have_tofu_d = 0; - - if (stat (filename, &s) == 0) - { - have_tofu_db = 1; - if (DBG_TRUST) - log_debug ("%s exists.\n", filename); - } - else - { - if (DBG_TRUST) - log_debug ("%s does not exist.\n", filename); - } - - /* We now have tofu.d. */ - filename[strlen (filename) - 1] = '\0'; - if (stat (filename, &s) == 0) - { - have_tofu_d = 1; - if (DBG_TRUST) - log_debug ("%s exists.\n", filename); - } - else - { - if (DBG_TRUST) - log_debug ("%s does not exist.\n", filename); - } - - xfree (filename); - - if (have_tofu_db && have_tofu_d) - { - log_info (_("Warning: Home directory contains both tofu.db" - " and tofu.d.\n")); - log_info (_("Using split format for TOFU database\n")); - opt.tofu_db_format = TOFU_DB_SPLIT; - } - else if (have_tofu_db) - { - opt.tofu_db_format = TOFU_DB_FLAT; - if (DBG_TRUST) - log_debug ("Using flat format for TOFU database.\n"); - } - else if (have_tofu_d) - { - opt.tofu_db_format = TOFU_DB_SPLIT; - if (DBG_TRUST) - log_debug ("Using split format for TOFU database.\n"); - } - else - { - opt.tofu_db_format = TOFU_DB_FLAT; - if (DBG_TRUST) - log_debug ("Using flat format for TOFU database.\n"); - } - } + log_assert (ctrl->tofu.dbs->db); - ctrl->tofu.dbs = xmalloc_clear (sizeof (struct tofu_dbs_s)); return ctrl->tofu.dbs; } -/* Release all of the resources associated with a DB meta-handle. */ +/* Release all of the resources associated with the DB handle. */ void tofu_closedbs (ctrl_t ctrl) { - tofu_dbs_t dbs = ctrl->tofu.dbs; + tofu_dbs_t dbs; + sqlite3_stmt **statements; + dbs = ctrl->tofu.dbs; if (!dbs) return; /* Not initialized. */ - if (dbs->db && dbs->db->type == DB_COMBINED) - { - log_assert (!dbs->db->next); - closedb (dbs->db); - } - else if (dbs->db) - { - struct db *old_head = db_cache; - struct db *db; - int count; - - /* Find the last DB. */ - for (db = dbs->db, count = 1; db->next; db = db->next, count ++) - { - /* When we leave batch mode we leave batch mode on any - cached connections. */ - if (! batch_update) - log_assert (! db->batch_update); - } - if (! batch_update) - log_assert (! db->batch_update); + if (dbs->batch_update) + end_transaction (ctrl, 2); - /* Join the two lists. */ - db->next = db_cache; - if (db_cache) - db_cache->prevp = &db->next; - - /* Update the (new) first element. */ - db_cache = dbs->db; - dbs->db->prevp = &db_cache; - - db_cache_count += count; - - /* Make sure that we don't have too many DBs on DB_CACHE. If - so, free some. */ - if (db_cache_count > DB_CACHE_ENTRIES) - { - /* We need to find the (DB_CACHE_ENTRIES + 1)th entry. It - is easy to skip the first COUNT entries since we still - have a handle on the old head. */ - int skip = DB_CACHE_ENTRIES - count; - if (skip < 0) - for (old_head = db_cache, skip = DB_CACHE_ENTRIES; - skip > 0; - old_head = old_head->next, skip--) - { /* Do nothing. */ } - else - while (-- skip > 0) - old_head = old_head->next; - - *old_head->prevp = NULL; - - while (old_head) - { - db = old_head->next; - closedb (old_head); - old_head = db; - db_cache_count --; - } - - log_assert (db_cache_count == DB_CACHE_ENTRIES); - } - } + /* Arghh, that is asurprising use of the struct. */ + for (statements = (void *) &dbs->s; + (void *) statements < (void *) &(&dbs->s)[1]; + statements ++) + sqlite3_finalize (*statements); - xfree (ctrl->tofu.dbs); + sqlite3_close (dbs->db); + xfree (dbs); ctrl->tofu.dbs = NULL; - -#if DEBUG_TOFU_CACHE - log_debug ("Queries: %d (prepares saved: %d)\n", - queries, prepares_saved); -#endif } @@ -1171,7 +747,6 @@ record_binding (tofu_dbs_t dbs, const char *fingerprint, const char *email, const char *user_id, enum tofu_policy policy, int show_old) { char *fingerprint_pp = format_hexfingerprint (fingerprint, NULL, 0); - struct db *db_email = NULL, *db_key = NULL; gpg_error_t rc; char *err = NULL; /* policy_old needs to be a long and not an enum tofu_policy, @@ -1186,44 +761,14 @@ record_binding (tofu_dbs_t dbs, const char *fingerprint, const char *email, || policy == TOFU_POLICY_ASK)) log_bug ("%s: Bad value for policy (%d)!\n", __func__, policy); - db_email = getdb (dbs, email, DB_EMAIL); - if (! db_email) - { - rc = gpg_error (GPG_ERR_GENERAL); - goto leave; - } - - if (opt.tofu_db_format == TOFU_DB_SPLIT) - /* In the split format, we need to update two DBs. To keep them - consistent, we start a transaction on each. Note: this is the - only place where we start two transaction and we always start - transaction on the DB_KEY DB first, thus deadlock is not - possible. */ - /* We only need a transaction for the split format. */ - { - db_key = getdb (dbs, fingerprint, DB_KEY); - if (! db_key) - { - rc = gpg_error (GPG_ERR_GENERAL); - goto leave; - } - - rc = begin_transaction (db_email, 0); - if (rc) - goto leave; - - rc = begin_transaction (db_key, 0); - if (rc) - goto out_revert_one; - } if (show_old) - /* Get the old policy. Since this is just for informational - purposes, there is no need to start a transaction or to die if - there is a failure. */ { + /* Get the old policy. Since this is just for informational + * purposes, there is no need to start a transaction or to die + * if there is a failure. */ rc = gpgsql_stepx - (db_email->db, &db_email->s.record_binding_get_old_policy, + (dbs->db, &dbs->s.record_binding_get_old_policy, get_single_long_cb2, &policy_old, &err, "select policy from bindings where fingerprint = ? and email = ?", SQLITE_ARG_STRING, fingerprint, SQLITE_ARG_STRING, email, @@ -1252,17 +797,20 @@ record_binding (tofu_dbs_t dbs, const char *fingerprint, const char *email, } if (policy_old == policy) - /* Nothing to do. */ - goto out; + { + rc = 0; + goto leave; /* Nothing to do. */ + } if (opt.dry_run) { log_info ("TOFU database update skipped due to --dry-run\n"); - goto out; + rc = 0; + goto leave; } rc = gpgsql_stepx - (db_email->db, &db_email->s.record_binding_update, NULL, NULL, &err, + (dbs->db, &dbs->s.record_binding_update, NULL, NULL, &err, "insert or replace into bindings\n" " (oid, fingerprint, email, user_id, time, policy)\n" " values (\n" @@ -1281,64 +829,11 @@ record_binding (tofu_dbs_t dbs, const char *fingerprint, const char *email, print_further_info (" insert bindings <%s, %s> = %s", fingerprint, email, tofu_policy_str (policy)); sqlite3_free (err); - goto out; - } - - if (db_key) - /* We also need to update the key DB. */ - { - log_assert (opt.tofu_db_format == TOFU_DB_SPLIT); - - rc = gpgsql_stepx - (db_key->db, &db_key->s.record_binding_update2, NULL, NULL, &err, - "insert or replace into bindings\n" - " (oid, fingerprint, email, user_id)\n" - " values (\n" - /* If we don't explicitly reuse the OID, then SQLite will - reallocate a new one. We just need to search for the OID - based on the fingerprint and email since they are unique. */ - " (select oid from bindings where fingerprint = ? and email = ?),\n" - " ?, ?, ?);", - SQLITE_ARG_STRING, fingerprint, SQLITE_ARG_STRING, email, - SQLITE_ARG_STRING, fingerprint, SQLITE_ARG_STRING, email, - SQLITE_ARG_STRING, user_id, SQLITE_ARG_END); - if (rc) - { - log_error (_("error updating TOFU database: %s\n"), err); - print_further_info ("insert bindings <%s, %s>", - fingerprint, email); - sqlite3_free (err); - goto out; - } - } - else - log_assert (opt.tofu_db_format == TOFU_DB_FLAT); - - out: - if (opt.tofu_db_format == TOFU_DB_SPLIT) - /* We only need a transaction for the split format. */ - { - gpg_error_t rc2; - - if (rc) - rc2 = rollback_transaction (db_key); - else - rc2 = end_transaction (db_key, 0); - if (rc2) - sqlite3_free (err); - - out_revert_one: - if (rc) - rc2 = rollback_transaction (db_email); - else - rc2 = end_transaction (db_email, 0); - if (rc2) - sqlite3_free (err); + goto leave; } leave: xfree (fingerprint_pp); - return rc; } @@ -1507,22 +1002,17 @@ static enum tofu_policy get_policy (tofu_dbs_t dbs, const char *fingerprint, const char *email, char **conflict) { - struct db *db; int rc; char *err = NULL; strlist_t strlist = NULL; enum tofu_policy policy = _tofu_GET_POLICY_ERROR; long along; - db = getdb (dbs, email, DB_EMAIL); - if (! db) - return _tofu_GET_POLICY_ERROR; - /* Check if the binding is known (TOFU_POLICY_NONE cannot appear in the DB. Thus, if POLICY is still TOFU_POLICY_NONE after executing the query, then the result set was empty.) */ - rc = gpgsql_stepx (db->db, &db->s.get_policy_select_policy_and_conflict, + rc = gpgsql_stepx (dbs->db, &dbs->s.get_policy_select_policy_and_conflict, strings_collect_cb2, &strlist, &err, "select policy, conflict from bindings\n" " where fingerprint = ? and email = ?", @@ -1681,7 +1171,6 @@ format_conflict_msg_part1 (int policy, const char *conflict, */ static void ask_about_binding (tofu_dbs_t dbs, - struct db *db, enum tofu_policy *policy, int *trust_level, int bindings_with_this_email_count, @@ -1699,7 +1188,6 @@ ask_about_binding (tofu_dbs_t dbs, struct signature_stats *stats_iter = NULL; char *prompt; char *choices; - struct db *db_key; fp = es_fopenmem (0, "rw,samethread"); if (!fp) @@ -1716,30 +1204,16 @@ ask_about_binding (tofu_dbs_t dbs, /* Find other user ids associated with this key and whether the * bindings are marked as good or bad. */ - if (opt.tofu_db_format == TOFU_DB_SPLIT) - { - /* In the split format, we need to search in the fingerprint DB - * for all the emails associated with this key, not the email DB. */ - db_key = getdb (dbs, fingerprint, DB_KEY); - } - else - db_key = db; - - if (db_key) + rc = gpgsql_stepx + (dbs->db, &dbs->s.get_trust_gather_other_user_ids, + strings_collect_cb2, &other_user_ids, &sqerr, + "select user_id, policy from bindings where fingerprint = ?;", + SQLITE_ARG_STRING, fingerprint, SQLITE_ARG_END); + if (rc) { - rc = gpgsql_stepx - (db_key->db, &db_key->s.get_trust_gather_other_user_ids, - strings_collect_cb2, &other_user_ids, &sqerr, - opt.tofu_db_format == TOFU_DB_SPLIT - ? "select user_id, email from bindings where fingerprint = ?;" - : "select user_id, policy from bindings where fingerprint = ?;", - SQLITE_ARG_STRING, fingerprint, SQLITE_ARG_END); - if (rc) - { - log_error (_("error gathering other user IDs: %s\n"), sqerr); - sqlite3_free (sqerr); - sqerr = NULL; - } + log_error (_("error gathering other user IDs: %s\n"), sqerr); + sqlite3_free (sqerr); + sqerr = NULL; } if (other_user_ids) @@ -1759,10 +1233,7 @@ ask_about_binding (tofu_dbs_t dbs, strlist_iter = strlist_iter->next; other_thing = strlist_iter->d; - if (opt.tofu_db_format == TOFU_DB_SPLIT) - other_policy = get_policy (dbs, fingerprint, other_thing, NULL); - else - other_policy = atoi (other_thing); + other_policy = atoi (other_thing); es_fprintf (fp, " %s (", other_user_id); es_fprintf (fp, _("policy: %s"), tofu_policy_str (other_policy)); @@ -1778,7 +1249,7 @@ ask_about_binding (tofu_dbs_t dbs, embedded in the signature (column 'sig_time') or the time that we first verified the signature (column 'time'). */ rc = gpgsql_stepx - (db->db, &db->s.get_trust_gather_other_keys, + (dbs->db, &dbs->s.get_trust_gather_other_keys, signature_stats_collect_cb, &stats, &sqerr, "select fingerprint, policy, time_ago, count(*)\n" " from (select bindings.*,\n" @@ -2028,7 +1499,6 @@ get_trust (tofu_dbs_t dbs, PKT_public_key *pk, const char *fingerprint, const char *email, const char *user_id, int may_ask) { - struct db *db; enum tofu_policy policy; char *conflict = NULL; int rc; @@ -2051,10 +1521,6 @@ get_trust (tofu_dbs_t dbs, PKT_public_key *pk, && _tofu_GET_TRUST_ERROR != TRUST_FULLY && _tofu_GET_TRUST_ERROR != TRUST_ULTIMATE); - db = getdb (dbs, email, DB_EMAIL); - if (! db) - return _tofu_GET_TRUST_ERROR; - policy = get_policy (dbs, fingerprint, email, &conflict); if (policy == TOFU_POLICY_AUTO || policy == TOFU_POLICY_NONE) { /* See if the key is ultimately trusted. If so, we're done. */ @@ -2149,7 +1615,7 @@ get_trust (tofu_dbs_t dbs, PKT_public_key *pk, * also be returned. Thus, if the result set is empty, then this is * a new binding. */ rc = gpgsql_stepx - (db->db, &db->s.get_trust_bindings_with_this_email, + (dbs->db, &dbs->s.get_trust_bindings_with_this_email, strings_collect_cb2, &bindings_with_this_email, &sqerr, "select distinct fingerprint from bindings where email = ?;", SQLITE_ARG_STRING, email, SQLITE_ARG_END); @@ -2221,7 +1687,7 @@ get_trust (tofu_dbs_t dbs, PKT_public_key *pk, } /* If we get here, we need to ask the user about the binding. */ - ask_about_binding (dbs, db, + ask_about_binding (dbs, &policy, &trust_level, bindings_with_this_email_count, @@ -2239,7 +1705,7 @@ get_trust (tofu_dbs_t dbs, PKT_public_key *pk, /* If we weren't allowed to ask, also update this key as conflicting with itself. */ rc = gpgsql_exec_printf - (db->db, NULL, NULL, &sqerr, + (dbs->db, NULL, NULL, &sqerr, "update bindings set policy = %d, conflict = %Q" " where email = %Q" " and (policy = %d or (policy = %d and fingerprint = %Q));", @@ -2249,7 +1715,7 @@ get_trust (tofu_dbs_t dbs, PKT_public_key *pk, else { rc = gpgsql_exec_printf - (db->db, NULL, NULL, &sqerr, + (dbs->db, NULL, NULL, &sqerr, "update bindings set policy = %d, conflict = %Q" " where email = %Q and fingerprint != %Q and policy = %d;", TOFU_POLICY_ASK, fingerprint, email, fingerprint, @@ -2445,20 +1911,15 @@ show_statistics (tofu_dbs_t dbs, const char *fingerprint, const char *email, const char *user_id, const char *sig_exclude) { - struct db *db; char *fingerprint_pp; int rc; strlist_t strlist = NULL; char *err = NULL; - db = getdb (dbs, email, DB_EMAIL); - if (! db) - return; - fingerprint_pp = format_hexfingerprint (fingerprint, NULL, 0); rc = gpgsql_exec_printf - (db->db, strings_collect_cb, &strlist, &err, + (dbs->db, strings_collect_cb, &strlist, &err, "select count (*), strftime('%%s','now') - min (signatures.time),\n" " strftime('%%s','now') - max (signatures.time)\n" " from signatures\n" @@ -2687,7 +2148,6 @@ tofu_register (ctrl_t ctrl, PKT_public_key *pk, const char *user_id, time_t sig_time, const char *origin, int may_ask) { tofu_dbs_t dbs; - struct db *db; char *fingerprint = NULL; char *email = NULL; char *err = NULL; @@ -2731,25 +2191,16 @@ tofu_register (ctrl_t ctrl, PKT_public_key *pk, const char *user_id, goto die; } - /* Save the observed signature in the DB. */ - db = getdb (dbs, email, DB_EMAIL); - if (! db) - { - log_error (_("error opening TOFU database: %s\n"), - gpg_strerror (GPG_ERR_GENERAL)); - goto die; - } - /* We do a query and then an insert. Make sure they are atomic by wrapping them in a transaction. */ - rc = begin_transaction (db, 0); + rc = begin_transaction (ctrl, 0); if (rc) goto die; /* If we've already seen this signature before, then don't add it again. */ rc = gpgsql_stepx - (db->db, &db->s.register_already_seen, + (dbs->db, &dbs->s.register_already_seen, get_single_unsigned_long_cb2, &c, &err, "select count (*)\n" " from signatures left join bindings\n" @@ -2799,7 +2250,7 @@ tofu_register (ctrl_t ctrl, PKT_public_key *pk, const char *user_id, log_assert (c == 0); rc = gpgsql_stepx - (db->db, &db->s.register_insert, NULL, NULL, &err, + (dbs->db, &dbs->s.register_insert, NULL, NULL, &err, "insert into signatures\n" " (binding, sig_digest, origin, sig_time, time)\n" " values\n" @@ -2821,9 +2272,9 @@ tofu_register (ctrl_t ctrl, PKT_public_key *pk, const char *user_id, /* It only matters whether we abort or commit the transaction (so long as we do something) if we execute the insert. */ if (rc) - rc = rollback_transaction (db); + rc = rollback_transaction (ctrl); else - rc = end_transaction (db, 0); + rc = end_transaction (ctrl, 0); if (rc) { sqlite3_free (err); diff --git a/g10/tofu.h b/g10/tofu.h index d3448b9..e3ec819 100644 --- a/g10/tofu.h +++ b/g10/tofu.h @@ -112,8 +112,8 @@ gpg_error_t tofu_get_policy (ctrl_t ctrl, /* When doing a lot of DB activities (in particular, when listing keys), this causes the DB to enter batch mode, which can significantly speed up operations. */ -void tofu_begin_batch_update (void); -void tofu_end_batch_update (void); +void tofu_begin_batch_update (ctrl_t ctrl); +void tofu_end_batch_update (ctrl_t ctrl); /* Release all of the resources associated with a DB meta-handle. */ void tofu_closedbs (ctrl_t ctrl); diff --git a/tests/openpgp/tofu.scm b/tests/openpgp/tofu.scm index 38b6a0f..2b302ba 100755 --- a/tests/openpgp/tofu.scm +++ b/tests/openpgp/tofu.scm @@ -164,4 +164,4 @@ (checkpolicy "BC15C85A" format "ask") (checkpolicy "2183839A" format "bad") (checkpolicy "EE37CF96" format "ask")) - '("split" "flat")) + '("flat")) -- 2.8.1 From wk at gnupg.org Fri Aug 5 15:12:26 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Aug 2016 15:12:26 +0200 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <20160805124310.GM19126@zeromail.org> (ilf@zeromail.org's message of "Fri, 5 Aug 2016 14:43:10 +0200") References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> Message-ID: <87eg639x6t.fsf@wheatstone.g10code.de> On Fri, 5 Aug 2016 14:43, ilf at zeromail.org said: > How about removing the "keyid-format" option alltogether? Nope. Breaks too many scripts. FWIW, I recently learned that there widely used tools which parse --list-packets. An option I always considered a debug interface. When I added lines '# foo' the scripts broke despite that I took caution to use a de-facto comment standard for these new lines. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From dkg at fifthhorseman.net Fri Aug 5 16:46:43 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 5 Aug 2016 10:46:43 -0400 Subject: [STABLE-BRANCH-1-4 PATCH] gpg: Avoid publishing the GnuPG version by default In-Reply-To: <87oa57a4r9.fsf@wheatstone.g10code.de> References: <87oa57a4r9.fsf@wheatstone.g10code.de> Message-ID: <1470408403-30600-1-git-send-email-dkg@fifthhorseman.net> * g10/gpg.c (main): initialize opt.emit_version to 0 * doc/gpg.texi: document different default for --emit-version -- The version of GnuPG in use is not particularly helpful. It is not cryptographically verifiable, and it doesn't distinguish between significant version differences like 2.0.x and 2.1.x. Additionally, it leaks metadata that can be used to distinguish users from one another, and can potentially be used to target specific attacks if there are known behaviors that differ between major versions. It's probably better to take the more parsimonious approach to metadata production by default. (backport of master commit c9387e41db7520d176edd3d6613b85875bdeb32c) Signed-off-by: Daniel Kahn Gillmor --- doc/gpg.texi | 4 ++-- g10/gpg.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index a41ab8e..12a6d60 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2338,9 +2338,9 @@ protected by the signature. @opindex emit-version Force inclusion of the version string in ASCII armored output. If given once only the name of the program and the major number is -emitted (default), given twice the minor is also emitted, given triple +emitted, given twice the minor is also emitted, given triple the micro is added, and given quad an operating system identification -is also emitted. @option{--no-emit-version} disables the version +is also emitted. @option{--no-emit-version} (default) disables the version line. @item --sig-notation @code{name=value} diff --git a/g10/gpg.c b/g10/gpg.c index 72d313b..236ea1e 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -1911,7 +1911,7 @@ main (int argc, char **argv ) opt.def_cert_expire="0"; set_homedir ( default_homedir () ); opt.passwd_repeat=1; - opt.emit_version = 1; /* Limit to the major number. */ + opt.emit_version = 0; #ifdef ENABLE_CARD_SUPPORT #if defined(_WIN32) || defined(__CYGWIN__) -- 2.8.1 From dkg at fifthhorseman.net Fri Aug 5 16:47:51 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 5 Aug 2016 10:47:51 -0400 Subject: [STABLE-BRANCH-2-0 PATCH] gpg: Avoid publishing the GnuPG version by default In-Reply-To: <87oa57a4r9.fsf@wheatstone.g10code.de> References: <87oa57a4r9.fsf@wheatstone.g10code.de> Message-ID: <1470408471-30883-1-git-send-email-dkg@fifthhorseman.net> * g10/gpg.c (main): initialize opt.emit_version to 0 * doc/gpg.texi: document different default for --emit-version -- The version of GnuPG in use is not particularly helpful. It is not cryptographically verifiable, and it doesn't distinguish between significant version differences like 2.0.x and 2.1.x. Additionally, it leaks metadata that can be used to distinguish users from one another, and can potentially be used to target specific attacks if there are known behaviors that differ between major versions. It's probably better to take the more parsimonious approach to metadata production by default. (backport of master commit c9387e41db7520d176edd3d6613b85875bdeb32c) Signed-off-by: Daniel Kahn Gillmor --- doc/gpg.texi | 4 ++-- g10/gpg.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index 23636e9..cde27a5 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2504,9 +2504,9 @@ protected by the signature. @opindex emit-version Force inclusion of the version string in ASCII armored output. If given once only the name of the program and the major number is -emitted (default), given twice the minor is also emitted, given triple +emitted, given twice the minor is also emitted, given triple the micro is added, and given quad an operating system identification -is also emitted. @option{--no-emit-version} disables the version +is also emitted. @option{--no-emit-version} (default) disables the version line. @item --sig-notation @code{name=value} diff --git a/g10/gpg.c b/g10/gpg.c index 3a7dc38..a757fe3 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -2018,7 +2018,7 @@ main (int argc, char **argv) opt.def_cert_expire="0"; set_homedir ( default_homedir () ); opt.passphrase_repeat=1; - opt.emit_version = 1; /* Limit to the major number. */ + opt.emit_version = 0; opt.list_options |= LIST_SHOW_UID_VALIDITY; opt.verify_options |= LIST_SHOW_UID_VALIDITY; -- 2.8.1 From dkg at fifthhorseman.net Fri Aug 5 16:36:01 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Aug 2016 10:36:01 -0400 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <87oa57a4r9.fsf@wheatstone.g10code.de> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <20160805085357.GH19126@zeromail.org> <87oa57a4r9.fsf@wheatstone.g10code.de> Message-ID: <87d1ln5lm6.fsf@alice.fifthhorseman.net> On Fri 2016-08-05 06:28:58 -0400, Werner Koch wrote: > You are right, the "Version:" has no technical meaning. The "Hash: foo" > header for cleartext signatures is required to replace the one-pass > signature packets we have in binary signatures. Yep. And Hash: isn't necessary (nor is it generated) when doing detached signatures or PGP/MIME signatures anyway (the PGP/MIME multipart/signed content-type has a micalg= parameter that achieves the same purpose). > I just pushed dkg's patch to master. thanks! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Fri Aug 5 18:27:33 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Aug 2016 18:27:33 +0200 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <87d1ln5lm6.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 05 Aug 2016 10:36:01 -0400") References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <20160805085357.GH19126@zeromail.org> <87oa57a4r9.fsf@wheatstone.g10code.de> <87d1ln5lm6.fsf@alice.fifthhorseman.net> Message-ID: <87wpjv89l6.fsf@wheatstone.g10code.de> On Fri, 5 Aug 2016 16:36, dkg at fifthhorseman.net said: > Yep. And Hash: isn't necessary (nor is it generated) when doing > detached signatures or PGP/MIME signatures anyway (the PGP/MIME > multipart/signed content-type has a micalg= parameter that achieves the micalg is a problem by itself: For example it does only allow for one algorithm. It is also problematic from the processing model because you need to do a trial signature to figure out the algorithm which will be used. And it is often not correctly set, thus for detached signatures in streaming mode you may better guess the hash algorithm first. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From dkg at fifthhorseman.net Fri Aug 5 19:27:53 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Aug 2016 13:27:53 -0400 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <87wpjv89l6.fsf@wheatstone.g10code.de> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <20160805085357.GH19126@zeromail.org> <87oa57a4r9.fsf@wheatstone.g10code.de> <87d1ln5lm6.fsf@alice.fifthhorseman.net> <87wpjv89l6.fsf@wheatstone.g10code.de> Message-ID: <87mvkr3z3a.fsf@alice.fifthhorseman.net> On Fri 2016-08-05 12:27:33 -0400, Werner Koch wrote: > On Fri, 5 Aug 2016 16:36, dkg at fifthhorseman.net said: > >> Yep. And Hash: isn't necessary (nor is it generated) when doing >> detached signatures or PGP/MIME signatures anyway (the PGP/MIME >> multipart/signed content-type has a micalg= parameter that achieves the > > micalg is a problem by itself: For example it does only allow for one > algorithm. It is also problematic from the processing model because you > need to do a trial signature to figure out the algorithm which will be > used. And it is often not correctly set, thus for detached signatures > in streaming mode you may better guess the hash algorithm first. hm, i hadn't realized those drawbacks. thanks for the explanation. Maybe if you can guess the hash algorithm already and it works, it makes sense to just do that anyway (or be willing to fall back to multi-pass signature verification). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From aheinecke at intevation.de Fri Aug 5 20:03:17 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 05 Aug 2016 20:03:17 +0200 Subject: [PATCH] gpg: Remove tofu database format "split". In-Reply-To: <1470401597-30913-1-git-send-email-wk@gnupg.org> References: <1470401597-30913-1-git-send-email-wk@gnupg.org> Message-ID: <2347628.37FLxYZN6v@esus> Hi, On Friday 05 August 2016 14:53:17 wk at gnupg.org wrote: > The split database format might have been nice for use with Unison but > it bypasses the concept of a relational database by doing parts of > this itself and also risking deadlocks. Working with the Tofu > database for debugging or experiments is also not possible with parts > of the database logic implemented in gpg. > > The Tofu support is quite new and we can assume that it is not in real > use now. Thus we better remove that now so that we do not need to > maintain it for all future. Without reviewing the patch in detail +2 from me for this change. For various reasons I was against configurable, multiple formats and especially the split format from the start [1] and that is without tests on Windows where I expect the split format to have even more problems thanks to slower file handling and IO in general. Please push that change :-) Sorry Neal ;-), Regards, Andre 1: https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030461.html -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: This is a digitally signed message part. URL: From patrick at enigmail.net Fri Aug 5 20:24:32 2016 From: patrick at enigmail.net (Patrick Brunschwig) Date: Fri, 5 Aug 2016 20:24:32 +0200 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <87d1ln5lm6.fsf@alice.fifthhorseman.net> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <20160805085357.GH19126@zeromail.org> <87oa57a4r9.fsf@wheatstone.g10code.de> <87d1ln5lm6.fsf@alice.fifthhorseman.net> Message-ID: <8dd2eb02-2f4d-5668-b86f-5d4a7dcc9f34@enigmail.net> On 05.08.16 16:36, Daniel Kahn Gillmor wrote: > On Fri 2016-08-05 06:28:58 -0400, Werner Koch wrote: >> You are right, the "Version:" has no technical meaning. The "Hash: foo" >> header for cleartext signatures is required to replace the one-pass >> signature packets we have in binary signatures. > > Yep. And Hash: isn't necessary (nor is it generated) when doing > detached signatures or PGP/MIME signatures anyway (the PGP/MIME > multipart/signed content-type has a micalg= parameter that achieves the > same purpose). Be careful here. Removing the Hash: header would break all versions of Enigmail when trying to create PGP/MIME signed messages - and I'm sure a few other tools as well. Even though I do not care (anymore) for the value I find in the micalg= parameter when reading signed messages, I still rely on the header for the creation of such messages... -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Aug 5 20:37:21 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Aug 2016 14:37:21 -0400 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <8dd2eb02-2f4d-5668-b86f-5d4a7dcc9f34@enigmail.net> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <20160805085357.GH19126@zeromail.org> <87oa57a4r9.fsf@wheatstone.g10code.de> <87d1ln5lm6.fsf@alice.fifthhorseman.net> <8dd2eb02-2f4d-5668-b86f-5d4a7dcc9f34@enigmail.net> Message-ID: <87k2fv2hb2.fsf@alice.fifthhorseman.net> On Fri 2016-08-05 14:24:32 -0400, Patrick Brunschwig wrote: > Be careful here. Removing the Hash: header would break all versions of > Enigmail when trying to create PGP/MIME signed messages - and I'm sure a > few other tools as well. Even though I do not care (anymore) for the > value I find in the micalg= parameter when reading signed messages, I > still rely on the header for the creation of such messages... ah, you scan the Hash header of the generated detached cleartext signature to know how to set the micalg? presumably the same thing could be done by scanning the openpgp block itself, right? --dkg ps i don't think anyone has proposed removing the Hash: header, we're in total theoretical-land now in this discussion. From wk at gnupg.org Fri Aug 5 20:41:31 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Aug 2016 20:41:31 +0200 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <8dd2eb02-2f4d-5668-b86f-5d4a7dcc9f34@enigmail.net> (Patrick Brunschwig's message of "Fri, 5 Aug 2016 20:24:32 +0200") References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <20160805085357.GH19126@zeromail.org> <87oa57a4r9.fsf@wheatstone.g10code.de> <87d1ln5lm6.fsf@alice.fifthhorseman.net> <8dd2eb02-2f4d-5668-b86f-5d4a7dcc9f34@enigmail.net> Message-ID: <87h9az6otg.fsf@wheatstone.g10code.de> On Fri, 5 Aug 2016 20:24, patrick at enigmail.net said: > Be careful here. Removing the Hash: header would break all versions of I used the Hash header only as an example for an header which is actually required. There is no way to remove it for _cleartext_ signatures. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From ilf at zeromail.org Fri Aug 5 21:39:47 2016 From: ilf at zeromail.org (ilf) Date: Fri, 5 Aug 2016 21:39:47 +0200 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <87eg639x6t.fsf@wheatstone.g10code.de> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> Message-ID: <20160805193947.GB16190@zeromail.org> Werner Koch: >> How about removing the "keyid-format" option alltogether? > Nope. Breaks too many scripts. Well, the man-page sais about --list-public-keys: | Avoid using the output of this command in scripts or other programs as | it is likely to change as GnuPG changes. See --with-colons for a | machine-parseable key listing command that is appropriate for use in | scripts and other programs. IMHO we need *not* be respectful to third-party tools using GnuPG in a way that it explicitly warns against, exactly because it might break. If we don't agree on dropping --keyid-format completely, I would at least expect --keyid-format 0xlong not to display *less* data than --keyid-format none, especially the fingerprint should not be left out. (And that's what "none" is for in the first place, no?) ilf: >> % gpg --options /dev/null --list-keys 80615870F5BAD690333686D0F2AD85AC1E42B367 >> pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31] >> 80615870F5BAD690333686D0F2AD85AC1E42B367 >> % gpg --options /dev/null --keyid-format 0xlong --list-keys 80615870F5BAD690333686D0F2AD85AC1E42B367 >> pub dsa2048/0xF2AD85AC1E42B367 2007-12-31 [SC] [expires: 2018-12-31] Werner Koch: > FWIW, I recently learned that there widely used tools which parse > --list-packets. An option I always considered a debug interface. Which ones? Let's contact the maintainers to get them fixed. > When I added lines '# foo' the scripts broke despite that I took > caution to use a de-facto comment standard for these new lines. Funny, when I append a comment after "default-key" in gpg.conf, GnuPG 2.1 fails for me: | % grep ^default-key .gnupg/gpg.conf | default-key 0xCBB15A68EF3AC804875D5C4E153FE398821C8394 # ilf | % gpg2 --sign | gpg: secret key "0xCBB15A68EF3AC804875D5C4E153FE398821C8394 # ilf" not found: Invalid user ID | gpg: (check argument of option '--default-key') | gpg: all values passed to '--default-key' ignored vs. | % grep ^default-key .gnupg/gpg.conf | default-key 0xCBB15A68EF3AC804875D5C4E153FE398821C8394 | % gpg2 --sign | gpg: using "0xCBB15A68EF3AC804875D5C4E153FE398821C8394" as default secret key for signing -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Aug 5 21:48:15 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Aug 2016 15:48:15 -0400 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <20160805193947.GB16190@zeromail.org> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> Message-ID: <8737mj2e0w.fsf@alice.fifthhorseman.net> On Fri 2016-08-05 15:39:47 -0400, ilf wrote: > Werner Koch: >>> How about removing the "keyid-format" option alltogether? >> Nope. Breaks too many scripts. > > Well, the man-page sais about --list-public-keys: > > | Avoid using the output of this command in scripts or other programs as > | it is likely to change as GnuPG changes. See --with-colons for a > | machine-parseable key listing command that is appropriate for use in > | scripts and other programs. ilf, what are you asking for when you ask for removing the "keyid-format" option altogether? If we remove the parameter entirely, then everyone who has set it in their config files will end up with an error: gpg: invalid option "--keyid-format" Surely that's not desirable. So we could leave it in, have it consume its argument, but make it a no-op, thereby explicitly not doing what the user has asked us to do. That also doesn't seem desirable. If you're talking about deprecating the option, that's another choice entirely, but i don't think you've proposed a deprecation mechanism yet. Maybe a warning to stderr if keyid-format is explicitly set to anything but "none" ? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From neal at walfield.org Fri Aug 5 23:29:24 2016 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 05 Aug 2016 23:29:24 +0200 Subject: [PATCH] gpg: Remove tofu database format "split". In-Reply-To: <2347628.37FLxYZN6v@esus> References: <1470401597-30913-1-git-send-email-wk@gnupg.org> <2347628.37FLxYZN6v@esus> Message-ID: <878twagb0r.wl-neal@walfield.org> On Fri, 05 Aug 2016 20:03:17 +0200, Andre Heinecke wrote: > On Friday 05 August 2016 14:53:17 wk at gnupg.org wrote: > > The split database format might have been nice for use with Unison but > > it bypasses the concept of a relational database by doing parts of > > this itself and also risking deadlocks. Working with the Tofu > > database for debugging or experiments is also not possible with parts > > of the database logic implemented in gpg. > > > > The Tofu support is quite new and we can assume that it is not in real > > use now. Thus we better remove that now so that we do not need to > > maintain it for all future. > > Without reviewing the patch in detail +2 from me for this change. > > For various reasons I was against configurable, multiple formats and especially > the split format from the start [1] and that is without tests on Windows where > I expect the split format to have even more problems thanks to slower file > handling and IO in general. > > Please push that change :-) > > Sorry Neal ;-), I find the argument against complexity moderately good, although I really like the future. Nevertheless, it is only a half solution, because it doesn't sync my keyring, etc. I think we (well, at least I) need a tool that can merge two GNUPGHOME directories. :) Neal From dgouttegattat at incenp.org Fri Aug 5 22:45:08 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 5 Aug 2016 22:45:08 +0200 Subject: [PATCH 4/5] doc: Scute can be used to sign documents. In-Reply-To: <20160805204509.15964-1-dgouttegattat@incenp.org> References: <20160805204509.15964-1-dgouttegattat@incenp.org> Message-ID: <20160805204509.15964-5-dgouttegattat@incenp.org> * doc/manual/scute.texi: Explain how to use Scute with LibreOffice. * doc/manual/libreoffice-certificate-selection.png: New image. * doc/manual/libreoffice-digital-signatures.png: New image. * doc/manual/libreoffice-pdf-signature.png: New image. * doc/manual/Makefile.am: Include the new images. * README: Mention that Scute can work with LibreOffice. * doc/website/index.xhtml: Likewise. Signed-off-by: Damien Goutte-Gattat --- README | 3 +- doc/manual/Makefile.am | 4 ++- doc/manual/libreoffice-certificate-selection.png | Bin 0 -> 5267 bytes doc/manual/libreoffice-digital-signatures.png | Bin 0 -> 4998 bytes doc/manual/libreoffice-pdf-signature.png | Bin 0 -> 8607 bytes doc/manual/scute.texi | 38 +++++++++++++++++++++-- doc/website/index.xhtml | 4 +-- 7 files changed, 43 insertions(+), 6 deletions(-) create mode 100644 doc/manual/libreoffice-certificate-selection.png create mode 100644 doc/manual/libreoffice-digital-signatures.png create mode 100644 doc/manual/libreoffice-pdf-signature.png diff --git a/README b/README index 3e43aba..acc9904 100644 --- a/README +++ b/README @@ -26,7 +26,8 @@ authentication with SSL in Mozilla. See below for more details on how to get this working. Scute also allows you to sign emails with Thunderbird, using the -S/MIME protocol. +S/MIME protocol, and to sign OpenDocument and PDF files with +LibreOffice. Prerequisites diff --git a/doc/manual/Makefile.am b/doc/manual/Makefile.am index 14034e8..499e750 100644 --- a/doc/manual/Makefile.am +++ b/doc/manual/Makefile.am @@ -35,7 +35,9 @@ images = firefox-cm.png firefox-cm-view-detail.png firefox-cm-view.png \ firefox-dm-load-after.png firefox-dm-load-before.png \ firefox-dm-load.png firefox-dm-token-present.png firefox-pref.png \ firefox-pref-view.png firefox-bad-pin.png \ - thunderbird-account-settings.png thunderbird-smime-button.png + thunderbird-account-settings.png thunderbird-smime-button.png \ + libreoffice-certificate-selection.png \ + libreoffice-digital-signatures.png libreoffice-pdf-signature.png images_eps = $(images:.png=.eps) diff --git a/doc/manual/libreoffice-certificate-selection.png b/doc/manual/libreoffice-certificate-selection.png new file mode 100644 index 0000000000000000000000000000000000000000..ca94f372da687e3970adf3e12ed55dab3ad364ca GIT binary patch literal 5267 zcmd5=c{r49+gH8vM5@=4ETx``hsru*U$T>KDmz6eW=4{jgizT+mQ>U|)-W;#VGv_^ z?8!35*cp;_hOsnbH{+e^dEV`N-|slS|Gq!&<2=su`d#OBUFZ3`&+EMJs4Hehyxbz( z92^|HCdT^LI5_sAIXL!&{j!g3AxZJ^vc>OLE?XK1aqRBl+m$-Cqo}N^qM;?DxO-9G z(CD(6uFkf(g_Z3Mr>obtoo~b7o?dQl8~2cY4}(Jd{nnp^KLZkmLc`XsCXd7c6n-d({5V@&`k}PEr0gRuscsfmPOrp&tf{L;f1)(Dwlp;^b`Ux{ zI+m+?7km3j!=ppw;YGq126=pR=&w1lN5y{G0BdDAIQZ>M^mQyB4%1S3LO?a~$DR|-&d3Mlj_$Hu?brv%f^(%p ztJ@*@$`|+Q6eG-!!_sFfEL7UG-y}pPd^ALINgvmJ{}hzXBJ$Y1Ap_4J~cNN zGH!EATr+s?OZ8HUSkR5j0V?XEm#f_SfNPU>&zTS~cr$>$F~6N03#n1ns`KCRF8Nhm zQOAPW;>OBH3-!r>82KwT;ECoB0pGs(=a`WvH_x0-*w<9iJV>8>o}RkWpdf4oyMKEB z*h{CEaOo=0dbj1cz9KTkYgd%=|_Vx}T;RyeoLZ zq2O-C2(|XYk|c;?EzNDrdyUsSwWirn85{15npFSZN2 at Mg5~kp1-LbOx+lA4)kY|#N zot=>ZFK;_?{nG^UV&i?pj^)Lss;xs>lb3c^W~1JqPH+}2eX*2 at PBJ2$T=TZGu$!Ar zK8>uDW4$B*no21sEhUjU$v)JJ>oY8i;yyXQ zQZdNTDJ#x!EDNYesdCAwJF at LRgVxPO6*-M=PMXVOKUe03Nawya(iXDWvd4Bff~XTA zA=RpFpRNlY7VpR`t%^D#ztj1A at Vg>bH%cEPtDXLn8 z?|2wDjQcT~<6p#M^iTDN{V{sk1On|BP%7W~;Mi|$H5pj`WDl(BSc;cd(V9$~)7?I$ z6ti&jy5I%Z6H|0J+kwtrL`qE6HB;HBRiM* zHqj163pExc*hGH+U+=6queN1-{=>qRLihn z|7DuxZRdc!S at 7aXKhF!=)v`&|T32!xi*XR}XvE|tnS-sak~AC?7e83 zt6+oIA33UR=JE0pYfZ^13TBTnzuUQz?a0m3F0FqK9Zdz at WK$>LxWb5|RI6TtmZ<7W zI=6&h5U%7(^8mXw=y&@r<9(M7+h<`1xTw9FGIb0CLR_buG4Dfu8ed~uB3hwo`xCaK zPxggJbiMDw*(h&|0R~1T&u-OZMf&{t{38W#q(z80t?N4{^?0DYK?&X^X+fvI2?xY% z{{{|Tstd6{;S7n~q(w;@nuADn{C zivyAJ-b7+=VSLI9Y5w>#BP5Yb#zFvn$JXhEZs zRe~Tl`d<+tssO$7#hWC-(M^YOiqN!1kM?W2iD^wy4Sye8`Zon-UYWn{H=0HFzg9di zqF__klnw7KvvVy}IC1n~S$TfUF2dQ_Dje3#sLYdgTu>hvV*8&#Q)ND>s48D*^1zh5 zL9qe>bO&_p{9YsJ9$H z%kCfIabX^5EP7t0(BB)%8i%?NV9g_fyEv(v{@c(Z5I%eIkQFB!X|cFyTRwjV at 2hasYzCE zYi!?r=>W5 at kaWGYmV|C=)>yJ%!I^b~c4 at 6Pv+k{W*svSRy6fI;_0z>viG at n^P}f4S zfSBds0iMZZQZ&r9-kW>t;?&vRYorft{jtmQPJadF1WEk|lN|z;2;}^L0Ptw)rp7>e zjU}!;FIX;ma=?B}7BegyWu@#q4lPi>8>aCde^dKepnJ at u@u4v8#ecpVg#pY%@VUbd{gIYUzagf7_TtW zde%}_RBSZKY%~%nrj?N;5RaZ@@4zU}xz-8H{UA*DueFmkFtRA(wK1nlo_2%uL9A%c zf3BPs=XQ7CvtI3*noIzxiny=_Q7b4lq at Yl76`o-ry_3G_C=I3YtlzJAQJJTlPU$>B zR`O5HAOKLn>d&Bhj&!VsHhMZ at Uz4o|ns?W$o3nC`wjs|2onvl$icS<}n3mpS09O at v zDtsI}-fV|wq+KGVt()_GHtV+80 at 0Y%7q&?LH9Jy`J7Y1i^AZN-+ at XDnE1yCODZlq194-GAR;3Ik;X`ss_!e}KQi#K2 zeKjpugG5>0Skxc_G7fC}Or({e3;vRh+0?j?)ry=YQ*h@>o7Cfk{iIpzU%?3A$SU&& zZ~hqs>ET^YC{p+#bMW|_EK^7BsS+!N3C}jPSgPHgUBtih7RpY2oojDzTex#wbC8I; zY7NlFUbp+b6Q3n!%~fZ}>H!XZeI+B55RvI`H&60NLO_hfGil^fgLEfBgk)%I;q?)_ zzlf9}?>x?Z;H%;EEyxA)#wYcf$i7$bv@~hpoS(ePXeA|`;xix~Fv`NP1aoGkz`tp1*k!bA{+;$rLSW8}qv+-o-SS?g|#Bz>DL%mEh4(HhQL zh|R>HJ&Z_&LW4jQn!GsF1Ec0bt8=~lApiqdK3toSnAMIUG8W9&{ox04(njlqrc1wR zv=J at 6o;pG8a{M>FJe;5V``o4SX7|A_L0*?meH!gG#V?;L49t?EEgGx=94Lg|_8!RIn9pYM>fMC9 at iual$PvlQYo7C7`Tmo$R$=KeGKzQ-DJ!u#>gh{T{NbeofZ%1i<6EC=ysiS(OF` zLSz#cIOuR;oRX>f85RmH6!Kvvoqt_$E-mCjl>;zK;Ke?ff=tK9=z$k4E?RIvI3b+h zMR at 1{gBv(?19Z&%(O3V6f}bJvkGA`d?t3rz?*D at RuXo9Ra{d1deBYG=*wZc0E$|Nk z5Pz!Q?QH8miEe?P>L2Js#v~6&xGy{)7X9yy>5n#b*&O1TC6#STQu?0}{xb}J4>TKg z2-K~D(Ec1@=i*;)=8U{vTx0AL2r;U!7p{z=(LS2J$=^4ja27(+!w)_93PEc9-VIcp zToL_nCEeERtH`=6DyUNDY>|a^8}06tgo- at 4H(T&0Gk#Fy52pMRVFqQPYHh5EmaZd! zb3u-#~0p3ulTBDAws(*ydAA8#1J at 1HMT(v?AMW_`WXz zYYZJmNeljSXCYBwER&+{%Wv?F=J#6PVo;y-`(N94V?McV2V32%gT1Y657*Z_aY3^1 zS#kM(823Chh}SFzxpYPShM+nQp_glO{gg{}0^4k0VQaMAca?ExDS;;X)%~nTYTR-B zk_xhwvaQ-2&AsY#JSz!$z3Hv%Cq?BViD-cf`EvIgAj(=v14>|n8sMbs{0&&iay-(d zTDEh~^1Ny;(j7LYzM7cq#d|xW1Npq68``@Pe2kTuxD>CSL_VSY%8dOT6+g`hIEw-! zsw<6)m59p5InVye^J>uiMFH8GM;5%#6b9rYx)Ravs$E{au9Q9jOr(NZ at Rq6JE~_z% zc81f0E at WF__LdO~Hk|B at 4(N+dhC;=6g!RV~OZQyRN|JUWI}<2yPQh$iWb1IF_MoPAcCdQw>pY!D=fB4%b?);ZawNGRX^FfZJ?VYcL3E(x z8ll#f5+4vQH{jDvHGl~EkVX=XJ>#}G^=2>+1t*1GUG5g>M^NX${>~~{Vo;|NZRX*q zeB@;2(95Bkr?+RQ&V}v{oeI8y(b?i2p?#&EZXOXGRx8Dz+V>S}%#VFfYiPHx#-%rG z at _-F{x+~4?Nr5aG0c at YIFG}t-Bpk_zF!4}Z$dtl5zry7zmEkYs;V*#r#{@P;)VdR==oo_ zI7#Ojw=334%VGnSSUtrfxeA+M95jNws4y at jv1T|j^|hU6IvYA zf*s~MAwf5C^U7D2_zWLjQD;`6nD*9iq;Qb9lW}52fb~dg$^w&Cch;k(-~Xy0S2k4{+*-%`RySSLmlJmDZFc zA%0GtyGfXBSguXvDSz58W`C~p0Vsm-V%*GiTFDo`lOKl;EXb=6FH}@&emmsLDn-|q zch{#88b$&Y2f6Ki=8l6}o(kZ8b!N2F;W+xuLK#LFT8hYk(}}p+dUdDyp+Qrw5nZFT zM~5nYxCfr2^DCyHPeaQ|MMTl~z%|3|4c!tjZoFl at wel~DP1A-#f8vGl at Z<<9ES8;?fYt^30wHAO?D8B$iM!Lt= zgy`-V-7mAJ{!rk9*`D(rYQx{@^d61>L8oj=q}O{4ZIZ{Nq%n-xASHw%UApCp(u)*1bc7=zK$PB5 zklus at qG*V8sS!dE3Gjm7efRsmd1dDP_h$B)byk_R_iwK~zrD^0H!;#|DY`fe%J3^v6atexfQJk$Otyx4+OX%${8t$Y>;0?dUNG3eMfF~;xEgZKFuXX1 at wV`V}vE|;{oF5gm_-K2zu zTBz at CHySx#S}uK-i+xTf4Ry9Cftgln_4G|D8$cqielG(@gLcEAv&ALS8GbS;?P8Re zNekJ|hza~**}$D;vU11~iA^26ag1^3rVjU7%vVhzT1UX9uV>JC=bg){YBg%<$~&#C zYq9R!DQ_*-sg(X<8kI7iX8`Or__|m)@W}$pm6;w5fl>w|#t1fBnGSusXjYWKHxB=U77o z#~VHs4rTWEHSvxF9l?|US#EBbQXbD7T~FDhwK)<9yF2xC#RxU-POKct+e1KFg8S`G zCssYYk$ze693W%dBm(X32$)f~HYo1Ml%B!2r7RnHf>vn)huJfxCUvrBQ%#n~RxU86 zTaHj#>uXeHSu5!eX`r7#{%FPTCwNPq{yGEQxV@`SsZ~=;I69*zMtTIPe<091r?MVg zpJ|nxBW{TZ&NcL;VBY3#_m}P{tG-E71Kr|m#L~nMIe`LZp#ps+H)I&E5+pIPlzuEX z<7DlfE!cl2G?0e+;_ at AmV?p-Y?%8?6H|;ZU5^S?f7*utcDY`Idn2#B_TLE=F{t(}n zDv2NuyA--;BBz8m=~ow=aQTaV(2P>2pHart?&*xnRT>>L2rI&MC) zub3Pe()Y!HQ|ZG$iaZIr`IaSl>eHe^i`Ucsly)O$;WmfIbKP1Woa`wKz4H3JzU%5? z|3x?kRl at 5eg-bt*8VFeO;o|m at E-jdBKh-Dqnt^~c at V9YWi zf{VwP=U2WsU8uOq0CXsfsmcfV$?9fNh6p7J>M;8HP?qb&%gO$m8^YUD78Fs)78R~ipqxrxUpM!u%ftn(Pf7>hjuDvH$XfwN!I+Io{coyJHSO7E=`>1Ei=38pN*py`n zJlc6K*|(pC84)@!$l+dIHp&$Ljx5f7HV~k&0QNH6m at oy?=md1~Bu{b_$-zU-oiiF; zBPt{fIt=iMY&I(55v?ziO9%HSE1<%-*gpVjf;|hUwP>icJg|h^Z(X?ao&cxuA7fQH zkxyC;{zy!WH?6Sz?ESb~y>F)WwAS%$oWwYnTwxOT?607m$>@ZjEbiT&=^;1MfOo69 z7)WV at AaQl4CJ^~Oh2J=2A9J^9ZaJfO>y(@u;3k^tHuP- zo`Xa`)}p2$S2U~4aHM{J*g`B%A`R28-oB2av0-XM&IpR|@&6b?EG}6kK0DTK%`&?E z2AWXiEnd!XR@#{ZV_=tbav_I}^~$v7-Kr{`k-%mv-Rj;WWQ()+5}=0A>7eDL47_zN zw5X^N<|KysbyRi#XHsGelLHdwfV?Bm+z|%xJ0Lrfp$u&x6&O40WY7*PJI@#w)Alh& zy`B72Bz_ at CHf^6m at WW{Ii0)pj>pvTszxta06mXs2ZO*^mNgBxiOY~nC+3y?eA1%}W zlKTH!u+o8#958?hVES8p~Hbr20dG>TNiN6#@=^}eAFJKYnriw?5UD|wQdeO|-#%73Zd-y8gJo8=k zWd_qo)=|5e*V|*8kpIaWh3* z?!YbA^hyYCF+{BFb(^>YU)1GFS at A(B$D6P{;4%Sj^+xM;%U+`os1~D0) zjH%{z8>3lw7Y}sIbcKa7%W_IOT*8xY>e=N(mA6W|OY!hpH0ZuR)7>>Lu52_(4lkX+ z`UK8T2TUov#`1r^abb_HKch7RdGNMVN#$TsvCV zBQFK_o-p|?UZY+Dzp$W(XRM}Z{S#0dyuW}F)fm360DgDxjdM+08DVF(0K zXX%Vg%#$-Mk_$s|_TEy}nx^oiNTe{&LFBdE$P^v-$SsPt3g()Y{kkr)PPS67_o-K; z#m{m#k{ysVJclnu2&8*dXF?|FTC!zbkb zR({dH40}94%^(w)5AHTsxg`|hZiv(}&fDz%g2^noFg~$bMOmvnF4GauJPbnqhhLBgkY=n_Glx1!`AqhbxEk+QS^ux z32MO(cy9H`P?N${cVAy at G|e{5L4Xg+(8ZTeaZ;QMDP|R8LRBUw+neuOa&lsfpV(Rw zblGb9P|j^nb&XAWbdW#1a}R7-7s?k*AH}{7aZ7l zU#Hc=$($h6$h1<_dvQsbFGchUA#t|=1`0fe_>vDWsGk8>A$N95Ucx%^sFotoitw$J49t*5vgRA}lq)f3HDpuUDN)``&FoP%N0N? zjaPF2at4i2M%KhrkCaA5KR;HMGWq at lM9n*$8tJ(muPjVTHY@$;y^F9C?KQzf2~Z7p zxJEo*EDYWeLacG148bZ8{6{Q$($kYVVgJ&pb{CXR()~I%L`$xFx^DYoA=%{hN%8Vz zIBS#puRhm1NxkkT5A)8D2kZUZ at 4}zTV6n at 690=Y&>5+B!tDn4dFCRb{h509r%D;=dwMxt% z*eiJ7`}1!5+00vqk)tZ8s()HiMHb1>M3X~rmeLcM-(MvE!zsIGihS5ZQye THOKhX1k=|s(k{`w^Y}jiHm;Zr literal 0 HcmV?d00001 diff --git a/doc/manual/libreoffice-pdf-signature.png b/doc/manual/libreoffice-pdf-signature.png new file mode 100644 index 0000000000000000000000000000000000000000..ab5cc356441dcc451541b45045b321ecd83374eb GIT binary patch literal 8607 zcmdUVXIv9q6K?<&5fL#WNL9d~(o_;akX|DOM4EKL2mz$`j))*2MIs=JgepBCy at LgW zfRrTk-h1yoH#~2-&wKBC at 9%!SANK6-**SC0e`e0i?Cgd-Ra2(Bz;Xcu0 at 1-$6rO=V zR1gq|V(UB=xrgMBqa&ZbKYgO5NO_im0YtjVb%UAxL|F8pxRi{%GW^k_!^i3x8rr&# z)eiNHUznPst~e1*O!rYXb`GxY4i3A%0Rf1}zR-xM;NWfN_$qWyBx9j4Q&m;~y+6yYLcXD~SJ86}2L%ZD!c6X at c7`JqsmG|8uW<@e zRG}C^pc^2#f~=PNz;Yt37ogJj4Q>7+Yqek925N%&2>AG3=E-9{&?^&|<>?Cxst(y&@7 zKk((zgQLBphx!M8ewF(g55}9e%Sk7PuE$h}5e2kRLDy8ls$U9jUoiQkT5XcFI2%oq zRBtX(KWyknGqWzkO*(60XIpn}-4`}=v_H7rCW>hz7F0<2o$Sn(cQ9%M_>s0}PwGh= zMYByUuJJX*Lg!Qy0*+4L>~A0SJ=$Bgc6 at rW2iW?ZjQbrUVvmIP*56rd zB7F at _NDoP_K2DyrCnkQ!n~_JPqDLslA_&Q+{dd$@m9w2A`|!cORVLg0lR6x%5?)RU ziyZYn{Nc0@;HMVj>_+Q+_p6pWrDHnjPxhNehpLaC at jqQSiiuN1>kj=SmHR>0!A4gQ zIfH(Fb#?n_i{cqC^n0pR#F6w#lox3)%nR*gQ3( zNm+p>yQ?JIm0^cFI(Nb#1w9Rsv<9RJ>M<_KHTA#hARL8HP65<+l-`CuBi}*&G|Ip|F`C)&XZ0~NWL8P zq+hiDka`fwn>0xxJv!No;6-iFt{rxiD0ps22vGn>lt7>~6I2!ql|?&QP7Lp;&AN&w z)n}aSv*s;7aoJjOJvipI-bh at NhJ!m2h14yiwq^>l{Z7tVOK7r7CeV{+$xo#NNpN5* zp#RcQzuJbltesSD%mB;9on^5dG6#M!HSinAsv^3d2KZynWz^3kQD>6ifCp9g?(R1lpR%x;Xo_Xt>15pnh)9F+!(h~eT?oy?p(m|v4TD(M68pTkfZow; zc&WTxtu`lkUg*mmyb&F)EnLyD{F;}=m?z%$82KavL9#+!>I)k}iFnd7{J4`TJ at M@8*;xd)@EYXe7y z!dRmUW3 at sel+I2?<^^yv+U+3w)l at mw2ix9=M|ST74K!E}8nA2~S1{B{a6JEtX?&$P z(mLnup-a7xyksjaRZV1$SgLt*^u*Wsl7^)kcE_c^d#d3bMsY^Opd38P_ed9h$YrgV zXhN4=6nke^Pi;U+4_$f<8&ABqbpcQiV6+mtxTD?q*{5>Yh6C*fpLMxYh9(nejE1#RPm1x-ZZyV z7E4Q|UN8QgbjKEVy}QXf=@z{cEc5Gxcn;Mxcoj5NwkcfAa5>)5YC^y5sFIMHKU2z! z+e~(K4Tt9 at mKJW0q>BTej}!<} zem at oDVBeA5!wsV8#q?LS& z7H$Ez^wiQWbjzKzP3>w-q7er(dD9sIS2^Eo at klt7dZ!6%rNPJVH!O>Okto+&?n>t# zFo1^m+C5O0sw;A-1xH>pGCE;ywyv_x$9*Tje(7n2DM=GjH6-h^uOF8f_ja+^GVe^A z`9olq4?Y&W>(pPM8 at dlI)_q?(;o5PzO7s0elMx`MUz4X3B}=?h?!_0hA+YCKEIS{P z5ufACE2y^spZCnwt82{VZyYR075v=bmRr0&f3b;D@{}K zB@{Q%x6ew~A-1PGuY7fSmptzkBfSqz>$!W+E3)4AHubwYCxVBwTecmvEWgw?Mi3pp zLP7^8f3{Bn^Y<+UY}HERM48Jm<1ZfMtXO-F9*Nj&V(n#X ziWFMW8^CTjY5Np~cIXsqx>uDc7YNhqx0}B4RnUNDtD~FnkV(AA at BWo0ha#!#+cRnG zAC#-FM>Y+L($Yn!Te|mNk5*%HwRQEWnSA8%)rj7urXbEnSOWX{Ws@#;!sIN+7B=r! zSSs8H_ at G2jzrpBT!8tsf9k;Qvvf}GZT3g$5*PS^rX4hFIL_WqIR-( zK6TEYy7C4Fe9*m$-0wfaSEZDFAszse!5}~BCwI7Y&5?5o zPACgr&^yS$1J9c|sw?kB#MUo`mWxspg;tlXTXBIwGcXqK^fPv z*nkFU#Q3{G*bnwSW`LhnU-UU$9 at Eu60V?2oQ)dIivUBNZ=O5dvM at I5IPOn4V%eLIP zoza%<)pBz?51zPXGExX?f#v@^Qw^+r9ai`3m+>{Bs#Mr^8lS#wviXnsz1%u`!UH`; zf7)&Z at O+6##^)ef)0{E-pICr-0di|xkJ&OlkL!D5BxL;vudfjm3gObYi at 78z8LfM! zqR$Jh26^(d=DwdP^nPHqZwm}}m(nl`Lc0y`mGdEVGwOU}DazN=pzL5|-RT8WDo zV2Jw%&H5_BnQ_XelE8u#o$<_3$q2cdA~j#7Nn6S-h}J$+p at jhb9}>T at OqAo13Ev27 z!5*!0;VP=uPZBq3mI}uL at 85=r1{a*KFFHRVgE#|xzYb#%QVbIlj3Pu293=Z+9ba#Z zU_%5Rv`#6Obg?XZ)MRe;9#K|zPR*hmA0H*b(f2O$OXy1>*nG-d+~vT~hlXg=qwxJ% za*Cop?^SrAwJrr#YsS!6WrG^7aTcEpyc^pt^6~1rfKhQkdSQ4^Z$!QXZZ54yqVW8_ zl_9?+PfvRG!R0wsZQl83g^vlNTllu^Ese6}XWp5N1VNr-#3-wl#Ej2q7eM?u`GGZ3 zB1Vc`Z1W8iKkRa2GHY;ysZ5g%k=L)8smGr>2enuzC?ycMLdKVljgg8hZ at UR_D(AFq zSHAQ5I0YfRr(yj!7DhfO*UyxFwjkFdrqA%WQ0?dwTdON`U!&Cc(v4IO5+pBlN0{$x zyxgDsgZXeYFN3B}55b3@*!F%}O>|1j3aLpqv25hhDBL?17hvxY)97jV!<+D&1&0ss zK}cV$MJ|M(B=ZYe_EWt-#z479Fxy|*45V;h!dJ7H^!k3qxR|oSp2xe8`T0|LZ5;1j zyT^#cO12;2ZcDP;_X7>(gM9l%>iolO>1bK4Rm8;FlTd~2iQC;ps#pY~WC963ok=?d znw7R)k-pHAlMGK`*zbTPVUf|_(p9JLRvs^0^R0Ucg{#N8-ki5v*FZ|=L~34br;95H zc^Hv;&-X27v)BWRLEG_SHy7=6G2oBur$5Tz;(B-E^lef7f(XdT4nDo}{eZ2Q(uw7O zOo2}S9 at 1>F7VcTqf=YcIuM5kTQqvFCL#6t zBRtQY2lrrUe9>vF*n+O6C%NJ3RXSyc;j0v>W|rLW#r*h75O`dRwg?R8XIHcj*ByA5 zUT>_4h|s{NZ;27rzN%9LWF)Ih9ep0n3!Fx0$2Oo2GqSDy4oj7z?ove;zTdJUz?{8G zCqLi&-K0ZN(HSNPf>OwU|JC^ag2hwSgcd6j_gSTs&>>#5_E%QYS=wNV#6hTcAOyV2 zFs6X)ib=B+E0}gfN#%(wwa2>L3jVY`QIYO&90bACY?x4j&1rNt)Ncj&l z8v83 at V`Xe@<)y>Mx~%!wj`B>)fLr!eyqrp4W9zJ2b7lz4A_ZbB8m8Avc5 at PA+1Db7 zQw!cepGEH!%^0$Cipe5Ij=z3usU{SGz-+3}=c()J{$5rEmafh2-$P_b4%&{^zJu`j zqqCJZ#ii3lmBaMZTipz8y6Oh{R}O9<%p+L&YdC=KLb*8Ys675uDvPu$_P zRnaw%(HMh at IY;*D@~DMoiVV at X>M0T6`(YPPeLfN4#)0h{K$@3fF!>wW2CQupk`iK1 zz!tIA6Rzf)82%m%|4g}+|NPkxkhK*U4Zp*7Hsd2npDHg;z&A8qMOT_GjjN!$!FUP~ zBThfCpJ=Nz9FR?9G7=QpPWV=*pp(0xTc9)jnN4JCdgHE~AZ_mE+*)_L#QX4|-3W+l zgX6r*#B}~(46%+loll`=9tmlUhmI4G at sB^|`?B<;!q-Q5w0~c3k8^^)F;M_xC)<<} z4*{_OdnqXQ9fG!p-2)q(bU at AglCG6>|!RjM#kG5c_&AmOjiD`X;OgndA0$yKjJ at p3B<_ zp~Gjan-%jcCxi$sl)$w(HFYlYUavBezpZsS3~4hgQew+|;5b$oaBn0oHu7g}+G4vn z-{niJ0A8IbgEPqSm*}rjFq3BH(?#~elncOjuP%jMbc}7QNngZ81IAe{j{^0H3gQ=m zsg%E7Qm0V*Qg{0=1nBSzC08%rFc3Sw*BNWtOEZ}BTtZ5*Bm%N#jpEY5g+7dtwQ6RU ztw;%(e>EMaBuZCB-Y5v#wxW@ zFx;`^UOE&0 zE7~gvZx=hRRhYLbk1}zC>}(~3UhG>>D;Lc%4}Y^(VK4SV-y8C<3xKR$g3(B-hWXlU z48hV~dHdyuq(THn+1GbkMD4k4a at s7qPd2$w3yi# zfFN%N90=VNVwx1v`*?;@dQ;+Jw*Q`sGP9ZJ>CV(g`{dX+o zSZ>^)>oi8FP at PGq7|5lu^iQ at WU)%fhrc+R!ny}$#$OH({Y)1*xRAxyQjh0~(2a;)$ zamI+xR;*STLD%Q4dwJTniv?Vwn(4z%bCake$l6U9e3m#8E3R at iW3bFzJrP3A6T5iY z+P{&>Zu8iEZmLwPm=+?^qGxM!soXVvjfY_7C at cp4Ohfp$U)HzfE zgv^2fTJ8>n$~+Y%UyFSQZzO=0rX^9178jrt(0;ieA2Ph;z9s at uqi3u#Fh>wg)n1kr zQ`uUZq_X_R%g{G&c{r`rbBl#8RS>Q`O>o9Q5Rm;!$+H at rr}bc~A>Jz*Dh1a`ayPlM z)99!-oPV>+ceBpUs_l-Y|Ck&Ue~kPJr0`xCgNCa|cPn323O1{(vAw+7%P%di!g8bH zJfh*QUbguhj`I1}b@;};PtZG`S{Kf(leF)*(UUniDxs}{FsS&9b$HPM`5}Lp%VyWD z0I19w2h_p3MwC1>B-WB8$tDeMs+VU#Aj4cM&VH4%JcrKzSQ?+g+cJbEk1alMAB5fM z5jeFK@|ywkxAeT`B|g39;M+&DboaJ^cCou%~E};Vipve>?Slh^GDO;eX)hBy-AEyiO$&;txSlqBcBF_aRLF z6c!of7`K(2Cpe4!RDR`T<$(Snv+sie5D<#e|6k39PE^4;6)I={e+r6-oM_+6=jdu# zq9lS$X}VT%)jbMq1vJ70`QsWZjNrN^lmSIq9|)1-acWyO?-zj$vv90DQ+5_XURFN5 zZf)k4N^P-u at Uw#*v7_kMipig~-F$(-gy-)YCO{;a5Mzlbu8ENGw!^w?Sf;5+NR6Dq z43)YR);qgmt^wVue32yu2;%GJ&W}}-NJ7Yu!W2Be_0y;I-)s~?%(O#$kPeGtciGb< zotMf6X2o42w?2I92pcy%`9g1JO;A8wEYS0XN_dNhcte5bZn;N^(uq2CT83FPY(ze+ zj`ULbg*26#CmD$ynJM%|Z{=ZoeTnwDkXE=CgQepjO+Y)A#l)Oe*EqB?vA?G2n0Cq3 zeX%``cGvYe8uGwacYbN at D|~8 at uFX029W4*+bkS?m_g?;{_VHoNcdpNY57>)4*gqBP ztDwvLZFQ&^=l!A_FBg7SQ#t>fBNARl6 at 1S>?qg7e({?=s5xUEuKmB{896R+w{FKx4 z=}M+ASvi{BJT?^%=zL0?+bnWfR|rTvChJ}8`|WS&Vb?RJAg`wp$k?u2I2qw at F1lrB z{rw`c85R*Na8aorKHEVJ69(t~7%5d*=um0EhZ-oD)i(J9 at 8^Ql9as0oN{x{11wxIt%rXdIG|9$b~o-g?{pih0| zGSF-4|Ldo%e}C-ys}y3KjccgIf|=;Xmp;0zBoB9zeU0^T?%_ks_e$=?CE4nf5DAll z1*Cw%88K^Qq9jTbTIu7P6E|zXb*7zF&w_qH0N`Idix?aF=(3YM+=VpSyxxnVw1~(n zrWPQ_?=PviiSrF7TqsIjg`SDe&7RuC3I9_%?P3TY^vxuSz6N*wuA@;p{Wkw&9-e5vqxihv<`k;YAHVm at n1bdh~V+nlN+Tmf=w;)W-Uq%F! zrRWu-v`buuFS+V^%7OdX_25tXjrP;5E$~X?t*rwUVe(2~0T26yB+fH+ zWz~d$Rp%co%`E|449hnnAp&}#FUlbvNE;jddR3is2m!htG52GX+s&ZebIT#XXSeRa5|W2S&~NXc7Rr#@CtLZqqRRrU4sBn@ znYr6_VzO{0Hdf|BJ?U8MovVm3D1yseM>)S7%MU!-hR4MP8XACkQ4d&4pjdoj+d)w0 z;8{dQM1HC2eeVFsk1eqV%p?Wy{l~{!5$|gr6-8VcnEyyt?q4y}@e;xumgEowv7c!c z_v*B at da%9lD)gUsspLd;9k|F#CV0RjH&*kP(RCvAH}CNNauKwvBmW+tcls~D9R|wT zaIy(52SI4<=6Z0Q2A6NzkNm|?EuzY>yEPj0#!0!S@@;H(8O6?jhTne#;=cvt)yH5^ c-!Bpct at fQWLeOq&@+2U*qMAa!+>3z!0US%93;+NC literal 0 HcmV?d00001 diff --git a/doc/manual/scute.texi b/doc/manual/scute.texi index f6f12f8..cf8011d 100644 --- a/doc/manual/scute.texi +++ b/doc/manual/scute.texi @@ -83,6 +83,7 @@ module. * Preparation:: What you should do before using Scute. * Client Authentication:: How to use Scute for client authentication. * Email Signing:: How to use Scute for S/MIME email signing. +* Document Signing:: How to use Scute with LibreOffice. * Troubleshooting:: What to do when things go wrong. * Internals:: Technical details about Scute. @@ -118,6 +119,8 @@ Client Authentication Email Signing +Document Signing + Troubleshooting Internals @@ -210,8 +213,8 @@ application and GnuPG 2.0. Currently supported usages are client authentication over HTTPS with Firefox (allowing users to authenticate themselves to a remote web -service without entering their log-in information), and email signing -with Thunderbird. +service without entering their log-in information), email signing +with Thunderbird, and document signing with LibreOffice. @node Preparation @@ -574,6 +577,37 @@ will be prompted for your User PIN before the message is sent. @center @image{thunderbird-smime-button,13cm} + at node Document Signing + at chapter Document Signing + +Scute can also be used with LibreOffice to sign OpenDocument files. + +First, you must load the Scute module into Mozilla Firefox according to +the above procedure. Then, configure LibreOffice to use Firefox's +certificate store by defining the @code{MOZILLA_CERTIFICATE_FOLDER} +environment variable to your Firefox profile directory. + +Then, to sign the document you are editing, select the + at code{File->Digital Signatures...} menu option to open the + at code{Digital Signatures} dialog. + + at center @image{libreoffice-digital-signatures,13cm} + +Click the @code{Sign Document} button to open the certificate selection +dialog. Select your card-based certificate, then validate. Enter your +User PIN when prompted by GPG Agent. + + at center @image{libreoffice-certificate-selection,13cm} + +You may also sign a PDF export of your document. Select the + at code{File->Export as PDF...} menu option to open the @code{PDF Options} +dialog. In the @code{Digital Signatures} tab, use the @code{Select} +button to open the certificate selection dialog as above. You will be +prompted for your User PIN when you will click the @code{Export} button. + + at center @image{libreoffice-pdf-signature,13cm} + + @node Troubleshooting @chapter Troubleshooting diff --git a/doc/website/index.xhtml b/doc/website/index.xhtml index bd60464..cd182a7 100644 --- a/doc/website/index.xhtml +++ b/doc/website/index.xhtml @@ -67,8 +67,8 @@

Currently, supported usages are HTTPS client - authentication and S/MIME email signing using X.509 - certificates. + authentication, S/MIME email signing, and document signing with + LibreOffice.

You can read the -- 2.9.0 From dgouttegattat at incenp.org Fri Aug 5 22:45:04 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 5 Aug 2016 22:45:04 +0200 Subject: [PATCH 0/5] Scute: Update documentation. Message-ID: <20160805204509.15964-1-dgouttegattat@incenp.org> The following patch series updates the documentation for the Scute project to reflect some recent (or not so recent) changes in the code. In particular, it documents new usages (beyond HTTPS client authentication) that are possible now that Scute can sign any type of hash value. Damien Goutte-Gattat (5): doc: Scute can automatically start the agent. doc: Remove obsolete info about Mozilla PSM. doc: Scute can now be used to sign emails. doc: Scute can be used to sign documents. doc: Update list of not implemented functions. README | 22 ++---- TODO | 1 - doc/manual/Makefile.am | 5 +- doc/manual/libreoffice-certificate-selection.png | Bin 0 -> 5267 bytes doc/manual/libreoffice-digital-signatures.png | Bin 0 -> 4998 bytes doc/manual/libreoffice-pdf-signature.png | Bin 0 -> 8607 bytes doc/manual/scute.texi | 92 +++++++++++++++++------ doc/manual/thunderbird-account-settings.png | Bin 0 -> 20010 bytes doc/manual/thunderbird-smime-button.png | Bin 0 -> 7197 bytes doc/website/index.xhtml | 8 +- 10 files changed, 82 insertions(+), 46 deletions(-) create mode 100644 doc/manual/libreoffice-certificate-selection.png create mode 100644 doc/manual/libreoffice-digital-signatures.png create mode 100644 doc/manual/libreoffice-pdf-signature.png create mode 100644 doc/manual/thunderbird-account-settings.png create mode 100644 doc/manual/thunderbird-smime-button.png -- 2.9.0 From dgouttegattat at incenp.org Fri Aug 5 22:45:05 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 5 Aug 2016 22:45:05 +0200 Subject: [PATCH 1/5] doc: Scute can automatically start the agent. In-Reply-To: <20160805204509.15964-1-dgouttegattat@incenp.org> References: <20160805204509.15964-1-dgouttegattat@incenp.org> Message-ID: <20160805204509.15964-2-dgouttegattat@incenp.org> * README: Remove paragraph about the need to have an agent up and running and the GPG_AGENT_INFO variable set. * doc/manual/scute.texi: Likewise. -- As all other components of GnuPG, Scute does not need the GPG_AGENT_INFO variable anymore, and can start the agent on demand. Signed-off-by: Damien Goutte-Gattat --- README | 5 ----- doc/manual/scute.texi | 8 -------- 2 files changed, 13 deletions(-) diff --git a/README b/README index 5483062..e4dc01e 100644 --- a/README +++ b/README @@ -57,11 +57,6 @@ visiting the preferences dialog in the "advanced" category, under "Security Devices". There you can "load" the module from its installed path, e.g. "/usr/lib/libscute.so". -Note that for the module load to complete successfully, the GPG Agent -must be running and available. On Unix systems this means that -Mozilla needs to have the GPG_AGENT_INFO variable set correctly in its -environment. - Client Authentication ===================== diff --git a/doc/manual/scute.texi b/doc/manual/scute.texi index 35e0af2..749b4c4 100644 --- a/doc/manual/scute.texi +++ b/doc/manual/scute.texi @@ -258,14 +258,6 @@ configured: Scute uses the GnuPG 2.0 framework to access the OpenPGP card and for certificate management. The minimum version required is 2.0.0. - at strong{Caution:} A functional installation of GnuPG 2.0 requires a -running GPG Agent process, which must be advertised to the applications -via the @code{GPG_AGENT_INFO} environment variable. Please make sure -that you fulfill this requirement before using Scute in an application, -running the Scute test suite, or preparing certificates as described in - at ref{Certificate Preparation}. @xref{Invoking GPG-AGENT, , , gnupg, -Using the GNU Privacy Guard}, for details on how to run the GPG Agent. - @item Pinentry Pinentry is a dependency of GnuPG 2.0, so it also needs to be installed with it. -- 2.9.0 From dgouttegattat at incenp.org Fri Aug 5 22:45:07 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 5 Aug 2016 22:45:07 +0200 Subject: [PATCH 3/5] doc: Scute can now be used to sign emails. In-Reply-To: <20160805204509.15964-1-dgouttegattat@incenp.org> References: <20160805204509.15964-1-dgouttegattat@incenp.org> Message-ID: <20160805204509.15964-4-dgouttegattat@incenp.org> * doc/manual/scute.texi: Explain how to use Scute for email signing. * doc/manual/thunderbird-account-settings.png: New image. * doc/manual/thunderbird-smime-button.png: New image. * doc/manual/Makefile.am: Include the two above files. * doc/website/index.xhtml: Mention the email signing capability. * README: Likewise. -- Since commit e22c8cf, which added support for generic hash functions in addition to the TLS-specific 'tls-md5sha1', Scute is no longer limited to TLS client authentication. Signed-off-by: Damien Goutte-Gattat --- README | 5 ++-- doc/manual/Makefile.am | 3 +- doc/manual/scute.texi | 41 ++++++++++++++++++++++++---- doc/manual/thunderbird-account-settings.png | Bin 0 -> 20010 bytes doc/manual/thunderbird-smime-button.png | Bin 0 -> 7197 bytes doc/website/index.xhtml | 8 ++---- 6 files changed, 42 insertions(+), 15 deletions(-) create mode 100644 doc/manual/thunderbird-account-settings.png create mode 100644 doc/manual/thunderbird-smime-button.png diff --git a/README b/README index 43a6212..3e43aba 100644 --- a/README +++ b/README @@ -25,9 +25,8 @@ Scute enables you to use your OpenPGP smart card for client authentication with SSL in Mozilla. See below for more details on how to get this working. -In the future, Scute will enable you to use your OpenPGP smart card -for email decryption and signing with Thunderbird, using the X.509 -protocol. +Scute also allows you to sign emails with Thunderbird, using the +S/MIME protocol. Prerequisites diff --git a/doc/manual/Makefile.am b/doc/manual/Makefile.am index 62431d7..14034e8 100644 --- a/doc/manual/Makefile.am +++ b/doc/manual/Makefile.am @@ -34,7 +34,8 @@ DISTCLEANFILES = scute.tmp images = firefox-cm.png firefox-cm-view-detail.png firefox-cm-view.png \ firefox-dm-load-after.png firefox-dm-load-before.png \ firefox-dm-load.png firefox-dm-token-present.png firefox-pref.png \ - firefox-pref-view.png firefox-bad-pin.png + firefox-pref-view.png firefox-bad-pin.png \ + thunderbird-account-settings.png thunderbird-smime-button.png images_eps = $(images:.png=.eps) diff --git a/doc/manual/scute.texi b/doc/manual/scute.texi index 749b4c4..f6f12f8 100644 --- a/doc/manual/scute.texi +++ b/doc/manual/scute.texi @@ -82,6 +82,7 @@ module. * Introduction:: How to use this manual. * Preparation:: What you should do before using Scute. * Client Authentication:: How to use Scute for client authentication. +* Email Signing:: How to use Scute for S/MIME email signing. * Troubleshooting:: What to do when things go wrong. * Internals:: Technical details about Scute. @@ -115,6 +116,8 @@ Client Authentication * Application Configuration:: Preparing the application for use with Scute. * Authentication With Service:: Using Scute for client authentication. +Email Signing + Troubleshooting Internals @@ -178,8 +181,8 @@ Anybody can use, modify, and redistribute it under the terms of the GNU General Public License (@pxref{Copying}). @item it's built to grow -Although Scute currently only provides a single function, client -authentication using OpenPGP smart cards in Mozilla-based web browsers, +Although Scute initially provided a single function, client +authentication using OpenPGP smart cards in Mozilla-based web browsers, it was built with the intention of supporting other applications as well in the future. @@ -205,10 +208,10 @@ Instead, it uses the GnuPG 2.0 framework to access the smart cards and associated data like certificates. Scute acts as the glue between the application and GnuPG 2.0. -Currently, only client authentication over HTTPS with Firefox using the -OpenPGP card is supported. In this configuration, Scute allows users to -authenticate themselves to a remote web service without entering their -log-in information. +Currently supported usages are client authentication over HTTPS with +Firefox (allowing users to authenticate themselves to a remote web +service without entering their log-in information), and email signing +with Thunderbird. @node Preparation @@ -545,6 +548,32 @@ the @code{Try Again} button does not work as expected: @comment FIXME: Document possible error codes. + at node Email Signing + at chapter Email Signing + +Scute also allows you to use your card-based X.509 certificate to sign +your emails with the S/MIME signature format. This has been tested +with Mozilla Thunderbird only, but should work with any mail client +with support for PKCS #11 (notably GNOME Evolution). + +You must first load the Scute module into your mail client. With +Mozilla Thunderbird, the procedure is the same as the one described +above for Mozilla Firefox. + +Then, open your accent configuration dialog (@code{Edit->Account +Settings}), and in the @code{Security} tab, under the section + at code{Digital Signing}, use the @code{Select...} button to associate +your card-based certificate with your account. + + at center @image{thunderbird-account-settings,13cm} + +When writing a new message, you may then use the @code{S/MIME} button +and select @code{Digitally sign this message} in the popup menu. You +will be prompted for your User PIN before the message is sent. + + at center @image{thunderbird-smime-button,13cm} + + @node Troubleshooting @chapter Troubleshooting diff --git a/doc/manual/thunderbird-account-settings.png b/doc/manual/thunderbird-account-settings.png new file mode 100644 index 0000000000000000000000000000000000000000..a1caa4ee7b6b3f3740c0f8c9048059fef8434ca7 GIT binary patch literal 20010 zcmZU*cOYERw>B(7L_`olln_075G@!45fMfrx)3co(StEa5G9i6QIFnxjV?qlqxarM z8*P*s4DXS9fA_uL_x^DPXU^Gc?X~yW=ULBswqSKNCDL1TxA5 at rNR?kGyurh}4&dS8 z%ig>Wo{=740YCAY)nC0;#Jh%fkK{6nnD{Rtk+7JAxDxsQi^{7is>+l8EH^aOSF}&H zb$0%3-$e}eO$-foj&6;N4-ZdFPt8ouEzC|Y?=G({Avf2yb~bnScMcBsk4_FTrzaPe z=R~=65 at 27hnW!i!-~|yrcme)F{PBgZGaeoZ<<)TwFFx@;c#_CPSyho};re|_$$O8Z zBX;oc9^xr0$i4kEg-RmxNfSRgcHfcYEos%W|1h3pK4yn|4HU%~$Fbbon?Li>hTgsV zg1oTGdem^-;yJmR8vfe!PuV*%?BoPV`S6!7vyi*hKjwkt} zQ~^&qbp29@>|{N2EGakV&3X-EcmId{AN z;`}e&o6=4zG)8|;U5WYP5IY}H6^H)^dJyuJ9fPWw(m>hw)+ETtl)i#^pVA{wf6-I} zGM6|60Ohlf~b0JIj1Kv715d;Vk5j~p-t z7hIPYhk+!&&P#{ftZ4z6`ERXfXWL3rH78zC2>LybCpZ=Q79_MH*Yr}wZhx1PQ2dnW z5F0slnbF5#BUZCIoGl6r8PsCWh_g?BqmT|wIP3|~&y-bYBJ-cLN0zb%RXA~6ozqCkT_f27~gpePH7O~Z_1r)ObaL88Sa<ZVy at 9GYueR}rw zjV}tm%`crEzr^rbU7y+_+u=06e|hsP5h^9)@`qJjoM^m_(@wZB8F_?T#F=#pIP9OJ zGLM7TkNE5h3}}H>mzAU4-LH+vTIuf=ft1dvxam!n`?cHZBeMHaT1&{X!P_}rEsXeGpzbFbc!w@}^7dk&5>f*P zD-_rx_BMm$a}-(a5>TQ<9#poc7#6|bRKK-iGwHUMUWJ~{6OC#soz-YX#2_jenmJum zQ5K|Hq|Y11*2)FdZ|1$zJhS<1Z7Py^DDsGUWRd1n$xDjMZeWTctL^b+CFaEXm%VBNH&ANQ)3aXox; zG+Q_ZOG2Pwc z98?~nU4F}U*hqcixoGKx4)PnEd-`c1vF6dAhnXJ&CEpdsG at 270dW{Hg3u646kz3OU zxPi2;uoGI>N0u2K63z4&pJ=Lzbj+IdWj%~ypxt$yDnO}8e^Kb<4<`X+e&8}AY{pkK zRIN%cS~TEW+ONr;(V_lIJNg0=1aP2H^CPS?#K;f3Iy*eo^CC=4|7 at 8{?nCj|6qSEf&7;9t at SpXu_LGK#s>-PugG)c(_GeS9w6lZv&K;=B at f|KA~^I7?P zI6_YM_w_wuIg2i2XVru$=>p~F$3BFxXA6{93l{PK}VcQkgriVRa3WgrM#;_I7 zxZey9bv&)*?MhY*u{}uBKR7kzr0KL+(|zu6l088={&vkJBzr|h2w35x!iR0PH#lNH zK)OC?97M1>xxqe+Ju>3JB?*3P?-`jM=}aaDGKM-VWx7Nvfe)ple3O at CEFMT=A_3&S#XV%pDAT}n+bYh23TCezhKZ}GhhtiM0Zg=WRQPa#BG at BTRp4*-{kn)!8dJ9C&<#4kIy|GY z#5!rP+i{+aI*8(5EhJTsaoKw2X zUiuD)D)Nrj$bUp4nOpscw#?)ekIYc<=JV57MfL-tZSEXirQODFh4pNL^gB^hC9Pc0 z>3+ at saXdreyDOI_q|Gspvu_OZHk7SUaZuml?EssT2B~W`i@*`yKfj9%h7SHK_|bL! znU}d$K(3_>`a^uq=z>9Qx?$G-ds_OhaI7 z`Tq*`nDOP;a%f6eXBtSVp%Qsu)<_*4lKe4Rstz8fW&Mmrz5YU`LP&6icYoKELmjGP za__8Z7i0IQ!=duRVl+1D-_(E$=&oH83{}NJX(i=I8a{@|-qN3jx<$871uGQS_OeCT zO+4Ze8fy3>GvpBr_K8!0hsc5f at DiOG36)C6L(XWd^b^eYK z!Kc>GE=yc?^Ql=%8JaXDu z&AXZ%yu~yy-zjn4aEvm)Cy^Y4kYA}nOU#>mTAwFH_w;M{nRjJV-+5DmTHk}&^QHIh zKY=l_{Z|v$FYUpFzh4*pXhxc&X?2U6gkbZ?{P{OdH(`yt3_D%leM^zWU1wKnfwB+PS@(AWNIV3d%o{kZzroH3!&}twHsq+a at _h+*=iv50$R}c0 z#9bI%9C8u{lu!bmKM6&fdLdi at iYwkvQ^tW`p64c|ps+fi*i~Wo)Y6M-JXu&Y_~}-; zqqA>>{P|WZ*oeJe}-63I}ct zsUy|B3Rs1<`z^deI1;pSrCKtj2J`xEzvcXBpKxbtE<0=1wVmU&g}12v9d#!Vif;!2 zKLzk3y??7dCalpQcxKtKRj#(?c0*UkW0}e)#jsuLrwXHfDpiJDm)xf)VUy#9a%n|j zu5s&{2jgQ$y|S+O77eCfbJO$;CHp7da(Ly~-+Ak_u7@%B0X)_(q|V4-dQSODZs(pK z`G~uDj~R=i($9byy`q at yUEf4{?pUd+XFM;yM10xHsSoqghKy%h7L7U?r}f<);rM7D z2Rb|+J+2}ws(b?Lz8=L;+kLDN?3YqsYG at lJsrZl}0C8kyBS(Fs{@`}>#4VGqK7Bbl z(UrZt<8tZHvUIAU4>$5C#j90`>~^=hw=!uHGPb`deFTH5J$d=oV8 z?*2~@2R at 0Zfi3zbyEfj8!<)8huErdS{5WT9p43JH6aH;Sa$FXas4WR0_l) zOu;{!k#Tzxk4W4<{(&)?w{s9c5dMg8yHcY2kDG4e1HUeb<*uO4|G*s=76>tjt4NTM zzF?Xs3YcwWVFv_X30R|8EoGS3Z(|P6Z6!$Ffrx3h%>q|acvGjD!%H{adT6r#4)fo1 zhP~YPuG{`@{?{qa at LF^$%|nu^e9mt+4KKec|}F ziIGDy+ubEXb9DRlTky2_1$lqef^EJgd}?yLz+s9!2ydS_z(necF~QK^$In<&5npb5Wlul0&JH!M#6hFi78evlz} z at B@KOovM4l!jKq`NW4Fq*Q(e4yUn6&$y~2{ywiAgY|t|zif-(`FAhVPFC_7|{K>_B zGdr`|>nwi?q}l|Nmy?=Wy?<$P#FiPOHBTm|v^>173Z+?G7=ay|Uk)#ZTew2(gt!hW z7iWI`dZ#>wwLO*}pg04xC7Qm4&9{$Y>_+1bhq5lM_G3A8*t)&Lpzev(luNGcy2$cL zGBBmFJCPaPpN?p_`^|9vDKD&`JKG|Gm)lZ1!WAM2C-FnbL*_e_oKJ>Tlnoc};sXoi zd;;7iu}!AN77bA=RQ$|)9+r?U%{>Xn+mTJ|?(Y9N`3BM at AsB|`8K63-p=MrGEwB at T z8fe5Z>RG&M29ppmOTK3<`xqAxG3z7lgEQ87nerCPv(G(xRWtG9f)s&O5^qenzu6Ae z=NAxHJj_Zm_wG6TplTLS#U3ky>i+#Qo$cX}{)1RK0tY-`puT5s zCaP}2{VCv}2=R0PpVBKVg^~|>-3S;=({sXZH`LqEYFot?fLn3umNE zm8MGQP=0(EmfIQ>Uz&I=o at LLy1h!0Hl6~mtl4V!!m!Evwj!(`PU*H#>zjQoU}Ijtqvx4F zjX1YkmhV_Vi!As-_i6+HSAT!a7wxxxmR;r^=(^uc2(x!>{TmYF0Xzw(nu at 7En^cMM zknK&27KEm=|D4;r$i6wZ=LV7QD47(Nk)JjzrF?mj!@ta25 at uKsr%rXf=Qf?qT^$z8 z=b#o@>&OXVRRPNWv3i7nwQpaFx zDc0;;e;%^(RPcFhrnV-_FnJYz^PuDN`|pT3Acy1cDL3(6caJ~vuEZTiz$P?Qe+Ak{ zV8cYfjG>K+O5>NfaX8ky)V=SlSyjVb-ELt^^Yj|opMi?l5Xv{-bu-E?er8iBzKIMv z7&8}}{5rkD7ZDV2$QxN*kYnanmctDcMslEIl<*-x;NJSAIgR?38(;pKPlO?SJMKHJ z1D7LO*jGJ5Vs9xq>a0^UM1a__C5>N?S7TNRP)W3HZp*?&L({{a(G`gUJ`HC=Re4%E z_movxy7gn<+5ZHC(f#K!Ldc^hMA?ipG;co_coG*ab$6W&_B{#x#Tod0TOacTQ)w=@ zb=R%}MH~u$Sfl_#=C**xRzss>b}Gk4zZ75!D%XeCLKIi7{esw5U#-QZxL5--e#i`oy40LFSnI3s!MD!z=dHuK0L?FaPqfOLp+)r zgbMUZ1Z|WeiuO}$ADD8yJmV^?!$fhU7j&APitM6}g+aQAigUY8xFkVvsdQ9rs4qLB zTKpEgzNP$Cqdhw~q#~9*Nq775yy;fLWwUD<8|JX)ew3>o>jV9XG&BWyg!Tr1Sw;$} zwnm643omtbDMt->4b zr6hGnt{|~OkD(+f0S>z7QG#?(k{;eJ-4vr9w7K5#QQ>nl8yzsDK-)w$rXWHCj{ksy zmh9g-k=-eb-4!$~Vy}sFVZjz8Kwq;-D~kbOXfkv^UX8&^vo}$yua}dJiT*X;ts?{y z2-;^bScL at s7qKbHE`6uN$KwpJ&rnTx{O^l)(fP@%bKCuQ at ByY+M043+=i3iX{I at OV z*&MnY<=qCpE?m8ZVT~aOF0W&r*&8%o;pAS;Ifr%>`?B^P5*IBSwxz~S{ZX at 7{MrOiIAS(U3Ozlz5HmIx4Jxh(zl-_ z72p>5NrGha9uW&YzkWpy*~7H>EbR9O2m@%I4Bi at fMEvbJ&(>1;oi7g~D>)lWd~YsY z^P)|^cC`X`ocK7^Vn!?l2{oScsHd^*AMi z%_|QjxYh$Zn z4 zj&Fl_kUyLl*tF^If4 at Vy4q8sGqb0oL%&KCiV2z2N>*sK(nEEj+4|v081R5DhZu0a? zVo^Ym at sV?5fPFf>$#})ihSU4_FCHBc at qN)QXb=1F at 3;dmyXr0 at o35VHFG;;$mH5dw z3gA_(*E%!Z=;rWOg0Z%^46JY8i28Hoad~lD(#?T2=knDN;jlR~#C?hdkc{p}ns4iG zz;*%^cf3Z&y!0F>ZQf*f*UqU7&*4trj5Tp2$(YekovpfCfp)yOcurK at gaEh=?~<$pX>2Pp?I^Mq_q&s0Cm(CD4&xW40~3gQsnwhS$sYD8Bsb98 at k`%IXq;*S z(3n%(@Uzl;OQrH+-zE561ojlZDp at _fQrr;LZ&VhE)u}k at F|Td;gvGNaQjjK95NA8# z#goRZv!Bw$Ce at B`M^XMPsdL;O`ZD`1K~Sk`QUKbQ9o}UjX8!8zL$snlU5u*#u-N_v zDgBK34XOJ+dJSrLFvfVq$lWF%&G}v0qOk#?vkL0?g1Lk(m1t;kf5ILq3fJv!f7Lx@ z-qsqR!8Uu}iW`MgAySuoxM`Jx&8W2N%$pe)ZSuckQ*ix=K-^dt^UY4I$G|hpdpAqb z=c6qIS=bS3AW)D at Oke9bb`tveNxr;$yr#aWO%a%kT3WW5D0VdyqkDIURSnA`&&n4g z4e$ZsF9Ie!Ybuh)Uh79DfacTg&Tj<*R1lBa5^X!nUF}BaI at OCY9KvLLzOAUH5k+5i znOG0Q3%S1fWCS*(5)|Qczfhoon6SpysG0g3%Kx3By5WXUHMGw{^yBSmL`X~4d4_0* zQqfd6!6qJz&Z9NE*O#U_Eg`Fo7-J at X+pvn&lyABGnJXGy{QzZQsj1ItIJ=`;R{?s$ z8Q(Mj*K(_?0_qLcc2E}m?OzqH|00`-C6n#TNyphjfO4PkH+_R4IO7t|`Mf`@inZUF??hUQ(AU-- zPBY5d0*AT^PF0o^ofY~A(G^=;2;gU;s&U#q_A z+E6RS5NzCkT*e4QZ~P5BhGXAN*&U1<9xv;*6ge1`${!lRAq6R2*nH-&6z=)7eVyWYYOBsG&DTTS_ivBdNVS^p02IJcSW_O3 zXKfUZ-9|NUG1~6r0ah{b73Y?XO_Q5UEn-Qf6Eie zVTL6;Nm$*zxUD1LMFVw;0aAG0?4DI`(atVh#a&;kQ2zJHE1z zzzp}~tK48Qutwdw0}t{O2c+{TQ_nh)RIi-mv0r<(3GW%8+Du6M#jkE7TV;>?5xch*K86VK@ zv4~>0pQ7MJI}$$o1%ZM+4XT09 z)mcFwb4j3__f~4pn)DIhMygv7Ky>{Xb)=6ImQ_Qn)xQp9;H95I34MJ zEtjsH$8ZnN_oO at L^kA}0SqVVhsT_Vl=NqM^wN#=J*$$%- at CL6BZa=Ovdw(3l!ZYk_ zHSXf_`88OhO_2p{?0n-04DJEP9M~O`f>ww-9CjOrFF1b$loSYjvVn}QwmQ3pk$}Zn zGZ-9ORWJpedp}AGy{e1F02$Es? z>nMmfQX=;~PAYOvfx{(NZ11{PV(I?0MChHNt$NUW>}y;%%JqB&1ARo8aKJFC)9_)*AC9`~hT-l`{7}C&n`^CpgSAeHOzu&EF}pLXN2?hj325dX(^}(rci2PQQOHt82^c z=#9(8#lfq$?sNCpsU55*>-?U3Ml_3hmZq at 27YJk;B-I!TE0_!5|4)YS%l4QuBGvpf zAjW;sM){L+^yiSFkm}kF(f4=&&0mWL&Bf~2SGh`XneVtWJ5+qb zpg=kN at QCfI%JCUmWnV^C{V$2ZJq^}*@h>6hdVgK#FPO2UtV+L6h+*NeP46! zeo;8I%$27`2htjMyO3kf)x6^=O&5}vdjHn)$kUW-ug&I)lVx28LB5i4dxAR0;QkI zC%8l1Vcrd}9?lwWNbHa$ZPAGgh#IB4Lkh6qa{r;g#kMli1#QKtcenIsviX54k09h8 zNqc;~?inqYa?l&~v9&CMW%<|+3-oc{M=@p)cx9s^dr6(hy z_~`3F`>>V(w8UXZ%Y!k2J(sjq*g`cn>iMBfv(|=_0_yDgMLc4(`&Mj?4+X5hOySWq zd8|}f^?dk at Ko|d16l@*!^MvF?eIGX8wnuyV$|@8J)`PP|->GeFN>@+gpjK?!8$(@M z`4M*9zan2dGLKguk%<0H5ZoM((N+Zjj-n>6jn0j!T9K}vDM1hSxq;DYu=Z0WlD8Vt z at MC;MAwrFnMQid+N)O*%gi}k;f^!{y&!&T?ee%R$qw?IZL^-lrYQBxdLKtIddcn}&3a`A=;3-3$eAJIkZ zRzK#SZ)3rEdp=gs?r>G=Z86!t-vFvh25hi1Xl$yD_XYLm{s^cP6G&10 at 7gT^2)6$n z at 2+T-X9EFfWspvKkN~zd3|qgSMN at f9Q2~H56qqNxDlvc`T#`X)CHNKzGNSd(H4^4Hw_Ba{EHpyRnA{iVJ0Sv{7wQ`wXS?mS*A2rvEwtu;rLjah0_uiLIBpvBiz5|;6YM(kpCeywO0Jy{<~?0 z&(LS;p()PG!#V?1uUE at Uu8*48SFvzbV53mTy610yStg1M1{^bkokVv0KkVfSL1>ze z_akDnOEl=_tGSUopI at yTU=wR!V*IUjZ^^PEGH?i8N(p1LyZfnZ3yW0WKvxF3IF03d zrK+|wEcCWlP1#Cr3Zlz+d4)3THjKj*zVHl{-YoZvq5eD<{Ewa-fux at Sw*cIBviQBH zOKQSRQ|g{yxNUBUI z_dgIF2bKoCMuz`{FBcO!zlA)o7AzDEt{^{DgV8l?fHzFWG>IdQHDLEM)Q^9&^^$&n z=)?Cb^`MJ4L3M%BbNm9S*)O1vEVq)GME*Kd8r4LBtBx4Rb%6=2GRF24fYq5EPN?`> zUJ4hU0 at TX>t0fygpTS(3vHFsWmcD0yy3AU(tAsAi^;JTHe^A(_mRD%1-Gtng+6Zfi zAfw6(_k*kpVcE11NPi4F#-AT7{5xVQNX4!L1B82BhU~NS{cd+sK0ZK!N`jj}{wT`> z9csS`9#>C(B9iWo+E0N&- zW4)@-gKaK0dceI5&a0bG>3}8aV-~z;+IWO4b6I_2Lz(Y%JAdDz=|^5HD}*04nyTEN zJoN>W=zlHn@`Pj;bzSGWuUQV>Z$J!~Svb3&H-7U)kWF0PyGCA%|ET0RvX8kOeD=P@ zKTX5+3cQB}+2#+KHBIsJ^_g&5cgm5QE#s$;i*sb-^!;S$lo*=q at E^JmsxRQ6Qw4g1 zLc5V!mt0HSFmZ^o$1{jk6YFs^^6N_E{3S2X8$~?-BD`B{C9eR(;pb{pwsPO+LqK0! zEY{zWQt-iKibb^$8#k&3Lq#a_Oy0-InfA#Gyj{zLHEaL+n{4G7_pxfNVUMpT7G;Mj z=zcB!zHyS>IZlU`c1Yu0)Jp<(9xbx$Jyn~WmGV%Mm?X+D%j98>RPnc^8VzjMjZXjA4Ev#55O`6-)>5DQ*PB#*=lhc)H^)Ea!XUZF zcJC`U^}+ocJ1%*(+G;Ph4!JA}&n(RyZ&*7vb7E#XEt=zh45f}rS876r%X&#i{f)G= z-oDtfz7^k}J?k5(Z?YTj{^4FIX{B&DXvq6yr)Q#DMU+dVEczwGgdbH|U=EkoD?07E z-wTsnQs&PbbGj+YO-r(Cz0BROY}vIAhJgL_I%aQ1b}S4pXzLRe-amAjO)j}l+#PL{ ztHJpy-lfuYIs!+-LBTXi4faepz2%W)5;4*F)?a=pw^Z)ltq at zqdsU9KhY2QB8IF~q zB!$~TU`T7oI|kf}6Mv3vXdo0%Kr{EjE+GXm^()A;yoWI3BQfvZ_ at E3MSWc0ZsfvwE zrYj9FWEMpg_o`{_o!#rHezRq5Dwp@=hVfHVd!;7v94Nwu-&|S>SDhK?F1n}Az%9eI zbl>c(#(osyJqycI;t63DqpcW@{|w#B<@uN*@H1TW6vD$oJ9i6qktVFH0Pv zJ3eR4^KzJuCRpi;h4Z}Ba2yl=Iov+E9=a_xmeday;EiAw9Co`bcLF;T28~l^$OCKO zmS7E>N at MF#*~gXN=AW&jKZulw at pn8y2U%hT(W)xYG zeePJYg|x%rzei-A3hH7&xp=`nL^E=?E^*EG- zBHyU~#jByWL7ra6g`3cDG*@Ixy=!YJ&9by^6NR$Y$&dW=esB)IBwBCm9i z at lXzDJwg?73W}BKV#PgzJ8{BgmOn(QZ4LtE8_5^%wp?(RwCBTfIPy*b(4N78fy?d! zB|bnujfk_9A*G=36G&JfK0grEWq12cC&IT}MuUDr3Q?Za(JHXoFq`0ByqXc$NaK<79O%doQOyih419VisZhrP>cUaY(JrY#GJW zOjr1v_hv}Mi$j@!00XyAp!NUoj7K!QF`@F-y8f#hGrLZg!rHq&o*p*mV-@)6caobc z7 at h{MT9`uFf4t^sWq%bmnfD}1kA>x|NK=-ubY(91!zU96XB$K96RJ&wgf8R6*_(V` zCAX#kL?42zGAdaysF!s=cna=!N)Fq}`Y)ZDAEJE4*-Rg~9}L;9UvNJD+-WON ziG at iJdNiDgp*>d7J>XJA03Z>Z0Nu|o2$hxcqsX=E(~qUiqg=cj`^RXd>>y(LYSLg? z at Hmm20AkdJge7};?|Jya`1NFRr+BhE%$`qbn2Q_#=@v?KW{^1uz zZT^iDuh3rIzpH0hSUdj5-gQyxKN86ZO6q(GBEX{iih*l2%h(1PI4|0~KMnIO*i_V;{01ff{!Ww_}d35sAyJP<>FVyLM-?s)C^wT|*fYFb}rVf~-Hn zeBKHe73P!|>pz9R{`tXmU9H@@=R=<>1W8X?s8jHWR@^ul>s{NW;^yS at 2-0+H&$FE%#Xe*hcE7#TT&=UxS z6p%m=0sokzhNCiI#Y41$6qyW?Tf*}~U!yo8ZP&`BeaxLzdgh8ZzE#}TVc1>Nf`ooS z*WA;1mj95*>}>~AJegJG(_h-Vh~$v$b)@ZB&L^KL&=^={i0!d()2YNt<(*xx0$4h) zm440ZifWS4SJ3};Fy}}`BS#zyBI)J*xZSXu#WD0JYfk}eKV!AT?8=2N4ob1&d(SOp zs<$r>XI4J24VFAj!|!G3{UX>SPND?P at LbGJzS1?>eP;Nn$!zG*?|tv0DjzGkkwN|-UD0v>ADW2uFHxNol{MuPmDX17 zr08ttA6WBgY_AEPr{kw~J<2CWykxm;2F1)*cUK=s^rVs3 at +wYlv)0dFgE`643}kNH z+6Pst1Q2(v1(ewu;nixI%~m0 at BdUxq9Vk;v0 zQ~#&7W!jQv(z&Z*dL%-FHhT3%SWF2Sa7L)H{$rFaqr)(j`shUx7w*yN_Ta1|)752y zl$Pb1dF|gC%zBpuXd{cCu-e|qvHLyzA(r};+;i2G=YLI97p~ODzr&Jj_G!e&?Q`~P zxF>mtghBD_g0p7Br|M*su4AVkmB2<+F at gDX1B~K#A3xu(&)?!@>rGaLSHAdF6{dNl zwi)S2>~p(mJ%I7wzM|hWMS5z##|-Ro8Kv?W<@Qy at Qi*p at S0=o_C1j1yrL$FSz-OhO zYj1dJK zncdk8Of6U1WqllUtTuXj3i>B}3O at Gdp4kXNqqLK@{nV7!4>FN`nsvnziUPgy>QPyN zc2Fm-J8QGDTpcALrn6FD)aCHT?MR03ne}D)overH9B-$SDC#2993oG&<1r+gpGy0Y zk~2oZ+tTwn&L-iM* zHYJLMJ)`t7W(9WlVb2_36Sb;$Y%gy>{MOmgHM+UD_;)n>Fs9JOrQ0L4Djyt6YE_S) zuy-sxK!LOEO8QfBQl#PmNgkV$IxaNxlD+{9)Er2Z6{u=Sx|O+#%k;&pYKYbYqVOP>sOfsf^^2hT>FUq;$f%l0UXX)`3je-9{8Q}M?BVz zWZBrN5uGHi^OH=f)oh2WXMHfd0dFXO_nkkxk||zha;0|a14x7^^B4pNNHGiP_S^y? znCXG;{fb*dTI`hxc`^F4urW8T%G8bRJQT||!4>{aD>UxauYD>Z930KYkoi8(V;B=v zl&frDE_K|UD#G31_+JKIQka%?xmFgUw0?ua=4WPQF;oPQAG2^Rve$3*^G?Lw(77OY zoNmdWy4_+rUaJ^TZ=D85Ry#@!Cl`3x97Jpc`M1)Zyu8sgQxoHquCb9lU71|{ipQWU zK>VMl_&~>w&y;d`8>6{mdmb~&B$E%KDLE-V_C3+B?=-Hg!L}MW74MtSJIRvE5Ovzg z&_3oUDihvd(A{+EKKRl3d|YqNEv+Vkv5h#qYpf95!!WWx-5eG=kVAfg-QbZ`rRa+ zCR*c+$_6Xjvq5LC!m4_yQT_~s(TwN|i|#+ByB7s{bY4G9Wwn>U!nbDOomaX?u4yMWOs-OFO+-^l_z)s2+E1Olf#@E(I4jU)De7VJElsmNl}d zisA`nm|cZtuf{F()5RG5gHtV5dW)wKh8w3r?4Xti{fkcGtM|QTDCM|}+H0f#oc+z> z=Ar|+-eUs2#votp;{Eq7C|>#B6#Bm<^1q27KSbza`AyD~lgJWTc0Uks at 5iZ&wgw5s zr^LuEpnEZ|c9(bO8)4XE=|<>@bgn$KAhBaOdx!i86y?zXZQkd5t2_JqJ3aESCM3JP zA=Ju)2qIaQsQ3Fh5is6n!2rKJ*u!+<;TWA}g6epjSc_-EpiVAN6t6#hu1ExEw^{sx z;STopFnfD at t2TEJrV#iKxBtEs(O&(AvAuW?y17=?WczPL! znbYvQ9~pxLcg%&wMYL%0TQV{uw2s#KEqsdf at 1%A2Dhdm}EOiNYVWU#_&4QSBo{=V4 zxbNqFozxhgze`09jvUXjuqt5BsC$CmU*l3$Y!gU)5oV at TEYM-d^N6vj(fsG=HIzaS zgi4;z7N||9`tYL_?wjNLyO9vkZb$Ma&(2A~FE2hht7vb9?5w=}R_j=7HY>^Z$WR)> zCckWjvZ(XpiKZ5#@(bbRyE!M9hHnD93CbnW^62bhF)<@xjr*aTQSfW+r+)fXpO;2k zGm}6iB~fW3l)LpB7^CP_<1~EFlbrPhbS);aF9KF&(0^bis-efL9c-rk{bo~X&W$$H zB?M>Zz^5rpVZ9pl^yYw%5W{<(Uc<@bi`pDt!DJ{Npgj)nr}l_p({22P at _zF*yEb`- zk2~cn@~jz2)i01B5Yy9UaA$GkDZsQl at cJ6_UN9CQ8vc`x|9_>HSG!C8hn at VN`TAev zrIZK|? zJ0hiN!MU{!<()`nFloQ<&=nJ=Dm%lo61lw^R$o}c%Qj`tU&OX9fZ5h!_~0Z$v+qDG z*nrU-_0d1aFOy`8oq$KQG6cT*KrPAC=1PDg1ZHnVI&r)W!Bm^ak$M*AX{pK@>|sU4 z%udpOe^23GDA$jK8LIqk;>(x)#KKtk%|Rue&VaDl4rP&tzog|yW`cOqP(ZAv67~3Z z;a;`s at 0oV0=`{t`TGOffAucA&&Oa#_Ml5Sxt+r;w#23fO%W_1nol=a2GnnBKm1!Ms zPTT{8mb*{%ZZDQeytdXcre#r8YaT^piu;{98Yrtj*{ey#@lsdbs>DU at Tbjd|qoLGz z)eS%}(ab%+FNr0c=WxnIExSa$MTg3dH4)@heP&GdrjLe#1A2`Y)Ux>p(>KO4?VNVq zTHexBE^0`(aNLc!>s$TKEsa6 at -Gw2l?t%PoTeT=^EggxTm*gCozBV0>>~e~KkbxH# zjRn!*w$0Lb%W9#u?9OJq&?1TDAvT^~xnuRupkDy?TQH+) zHGkorY?VZA=+xdMc@)Uv1cZC92?k24M?UHSDp{I;g^*PN*l8R2&? zMN6G%e`vK=N2l7Di&*UzcYOUj5A%wmn!Eu~kv=b^Lx^rJX#_|140Wxr5KY4K23?|u zx>?+>%=EpJZpp&kyXHP^&RM&awcg^+6IilTjmk~Ojr5zJi9d$8tRl$zcXuJ_Ko4q3gYMrH0a+Z?C+{*V$~tG&KGnph z<<;~M(4PXHlh{%&$QJ6Km9fjWQe6X$ATjiG(M$hokbM3ivu;!fU!W$!_bpe~b8f%W z*IpXCIK>hOu8CKX@(f at LS{JHX=Es;FsI)<`mwJW`wG>fu at 1sh~+Lu;aEbdP!+DbpW zLbh19K`t~pi78=8!#=iAU(kPaUw<_6Hi`#ho7A&Ou-QSejP>8LmvImFsoR>ZU-Wus zqsY18pJa+BM}|0gcXlqscYz8F at qo)Y(qpZbPMM++JQSGvxe!_%EnJKdxUp4GhW;~{ zu7d;$xLNjUqw7sj9`^45-*zCDzuJ-TpRfL(um9Jb9zqZg2A71N5${EX2p~{|g`msr z)`O>A1rR&x7iE!9S#U8)KZuif{nb&n;szkJoulEVQ`fT9>Jz?x#E;f_ zADL`bnlgNinYaDN3@>G1k(EKm8483Gj4(Zg!@@uq$9A|N!-aX?JO0qLtBtH%A zTVy?HG$7RkZZGFQLzg1SrFq zjhA|~S|pY5rZJbQ*MV+z?oU54ZD{xXqziFmchzj2n!K!d5p`xOZ?3_4n8v~)YE44` zA#=MFMxMw_PFFma9yV(&HW}%NupNWNEL)$8x=fIG236!zet*~M!g}TW5*G451Mt5h zd{r9wH$KUPfU>wmWy{KJXo=R1o3Lb7Kv^fT{z<@{4zGKu at 2<|U1IDEWiF!ROuw9ml z9=w07O<5vf*wa-czy&l5mhEiZHU2N@ z$qOtsq|471l#A8hgkV{!@?<$`BJG|ed1ejTctz}s_VtS^(5E?8Vej!^n?+ykt~!oZ zX+I0vxLt84_^2+=TJZMH+5Ii zUA{I^W2UEp(o^l(;gwG0b3wj8%^w|bd+~1Co0yXpe`$R6YrpTXoNGYE+_xF&aUdbU zU1NGGco6dWUfV!ed85(c7Zd9biVM!yd8lJd9OUZ#_0eQ+f})1M?Krhaq0dZ;E2=p> zhLDVFkvlA(jEhzu){lAw-JU!tm6thfeYTzUvLI{0_H01=*5Mmka4yWj0;NwE73!;| z at 3oEaa~KL%JP#0CyYZZ#w{7n8t56XLD(7c6Z>jcF`PQ-tJuvB8We*?AAfMZm%2G8{ zba?w$D{JrnlydFSP;PBpL at v4HQb=xzQ6do)=OvdIIt?kB&T-4pkR#PNX&5t!D5E+e zHGMJ0$x%wmlv~Dx)Mvy<>bMVLhA%733^VVz%-K^;Ykhs|TkE_0GkeX<+WURqXaAmO zKkweZ=SN=uOJg^a)W1JhmVQt=mt20bT}wdRk68nyl|eJHdg1NWL5j-%mRsPn z;@`9PA)0)5E*sOURiCu>%(@h}wX*}}7qTbt9A!#`lkmLTF!uNkrGe}^Z4K*?&2pdu zBZswp-L2{xC#vr?z*34m?M1J1JagY>&{da7_gFMGjXX%s>U7rmAtos=qj_Cqcks&J zyM8{P7`Hc%tMrD?#J;MsD>jCo$7o)Ou5mAOwaHxpHn-X_pRx at 6`!Y`CdOoRDFEf#_ zbfjz|`Z1eVjhXh4lxXy}Oo*Ob1D-$0-(ir6nIhb3POd_l)Xgeb3eDls5dIn^-Yu5B zpeK;LEkQPD%a?g0w};+?4fHnp_tB`aJB2tyePn at db~mbARTa}UIaa;;`yw70&O_o1 z`_gxqfjMK8kZgrr1q{>ex^Guc5;}o}iwsHiebX&;&c+@*2h_r$-o8`fpWF9j*~XTX zo{4uH{-OQ-Z&pa%g+FRnUV0zTwb&(3!F3->qYF5loG&`HDXU%mgkfj#8U{YNXn*Z2h1 zkAGS_zV`kfmzMu~;PIXKbR!Z=Lr1383?j8;97s`?3DyKwPC+T24{63|60&0YG>A6~ zftZ34>8h>6K^ebso at g~`Y{WeZ9VS>?yA!f#g;%}NOmJC_!RJxq?$f*Gjb(vZ at pMJ$ zv9CTQj^}9BG;q1)_xMrm3^j_{%% zHh8UEtAT?GyJEpD%*(|)Y(2f&>|p*x=>`wv;Y|oo#NbtK)k}AI&BTwhQ&HpR;oIxt zes$Ws*E(2jAe!?BNxBh{T4ek>ji6!EqVU}eeM`Rm1Fg)J at 6Ax+a;qZ_f{bWalk4jN zbj649`^)P7URI5myhyyEQoE at _2hz$UQKx(MTd00aGfmMkE4ML_k1rfjlHR!8ZF&ld z5=_?YmC at HxU>0$*pX3Ek+}Yz4K1!Y&eOK&@R_Vp(55o|!lNCQ`3+<>_4~;(Ig- at -x zIO*(I;f(Sw(5m#ee%6VUBmdg9o_}dp%qte&<5Hp`6rb6hP+q5LI!+An<;R(g2udCj6t}Z2m{-mMc}gnX3*kw+HizYb04Co&`)d z#&E4XMWd^M`{0ccV~OD-5w;r9f=b)CzH^T3niC;ohCnAE1C`00lH3<0x(bJ}M-D)g z6ZZf$AeI}@z`r3`WS0{S@=NIXVggcr_6Y z062blYkg;lkinJ=om*O3B`*+$E}d1SkdP(wJI1O)DTv&nMSSmdmb at qpGNnjh7X{8$ zBL{T0tuu#Mw_5+7^lFCd#pWPIGktUZPq=0DV z3q$WN35_cAk6s(i4yrRV&EtcsZ!4y78AzT;U2u0Dsy%ra`B0Bm2n-I zcJueuG5`f#@WSlXq6H!Yfv at 0XwE}81X7Vi3Vcg#uxERgz_Uz)KsBTd#5*5zuio_oY zsKg%k$7pTYEG-J_!!O-zug-$Ye(Ccz*vPR1Nq1wUWXDEvn4Z01rl*9Q8LdCoY$){H}N>y&mQDGP?*FH*Go6^D;(XEi&@x`uBdr zcKoe5Ps`liBJ)(~o>GrSovZ01F^D7XS; zE+wlVry%=5;#N^bjRBghrmm`^2~pF6iJMW&LPO+~?wpL#bPWv5O*F);VvNl#^!2X! zoJv*ggRJfBtZd*ej#fIpAKaYH99`XPY_HzK+f#keJiNUOVtAB7tDOVVoxa5e2f9l~ zb$WPR2EyUWv2!`$O5cJm5Ru_w(Xp_U?$l^I|75GU*sxK=n}p;fv#iC~`19oSlDb^9 zw5*)WtPJPk*@C>ZA6ch4g(Y)&90f)Bze-@!d5ZZ(b%9l5^%ddqKZi>yf0kF46_%X# zR60gAuGUu<*4Ecl*Ecn{{%Y%N8}7(2>Rn&&_TB4)cA<`X`+NRQprMA^#|GNFCK|Sf za@!}iN5 at Bcr`C=pJtn5cCno+)&rXgkw at l8h%q{%6T5>#J*SK8qIaq96T3K9J8^2sb zEUxXXZ?2te{n^>u-ap(sI{9~Yae8%gdG~nxJBfq*X-UwH6=bB)Lb2Y+J~eP0WVM~q z(C|q9E9hux8UOWo?jrXI at _gkPIT0Uuiv++F4ULjfPD)b!>)hYW=#O)u3mhmx8dn(Rv)C|H4NjY8BV?YTVQR6z0>wEqUcMEff1~9SAM1S$`e-}nb-HXb~N{QH^)^@NxJtGuRI$x+q|aT z+*)t#2<&|>P2T3e8L|Jt)v>nOxsdprfTURW{DTMgB~w4QCT&Yl*K*0e#Ak-S>5c7u zJ+a%H(^bQ94t;;fBeeO(vGh48$$ofPY{+!L^M0~$;O- at AP27-(Fn at LS*kISp`>uaO z$Z^S$f!K#uIm*vx=lU8L$+SMo(pwofLfRzw-eXj0(l?Vj%iB(ik;H1lx_e2OS@!QS zOP%(e8*!8el)%c>)!N>g9}RnMUZgw3%c~_J_#0%e73Q-!%>)&_aXOUrL at rne>_I)a ztE(LRD5 at +(?7El#>9vF`E9V^V|Kl7j*i^1)mAJe49)dN9BOBS(tHqH9AzK03}yj{teg}9WR|&H;pwOD2sdibBo;>xX5uF z?cUHaV8N~087<~nTE>+|l$Up1OdM5^6)SMw=Aur9GK>j!`ZGHPRVvyJspPk_Ikml`$z~bJ8K$otIWBn>B zK%CAUpJ1WkT@<&f at 1>pd!%Q-8KRC8X;FI_xrQf~j#P%O9?2d%_;?-!tM)=u&-sbJU zXXBj$NZL8+GidfRL7j(TY?=M+R-Mlf7)0Evwp>B0OmB5KaOyuAL9U*97n zdPn7y7A6Q7!a8)$E}D{cMB5I#0yhDdHu_8NKo#QR-hN^!I#A|}g*96VM%a(o(4`SC zhus0S>&!^V;Xr6GC}}S#JSf%GF}?jeVJ1w+He$+}W`)@t#h8tfd7%WI!zA*SpIf7>~8M7@&o- z%DU^LkxakNwz5DpJOVtz7no505B^yH7g!>&W+&4YQWutu{!u;Wa-pwUxp8=7C&kqj zX(9Hi3hf+$B{O}l?rcX^uc@<0X}|c2&sdsZxU}DbulUv87tVR!6e{OzfrdkCXMYq{ z=UU(A;o8xf*-x9l5h;h+=agBK=hOyNq=;-x(hB!3e-s4Od1w&|=CgG>0VIT-FqD!z z=Mm=#$~?tLq(S{`!5$go{OL&GfH4h=EktHu`he zsVya2xCWl42PechZoHUe(|Xvp*6UmAv+l<9SHh3b4Pt)A#NCZx1spvEhs*^KQjQs( zu&l%!Qd<<}EQ!#}C_2uw1J9Bu)QLq2WLw&Z7pE#Xs#OQoxX6GGCIntHRuMOkOmH= z>1%CL`hV&iDMHW}Bh67rxuny^ZzGNH&;4zdHGOP_ at 2o1E`Txi568ZvG?_KLv^Ft8`Trg%)4PS3aXwP&;D2;bo*LPm}!|f-% zdvLMeH9X`%>al%9u*cVoHv#NwpY@#Z7DqV0@^@R<@NT(vaEdTwb-mYrsj0pg%Ubwt zwA4v|!+shHB5m at dUVkS}hn|1GIb!sIQFMm2o&l0D$&i<{Wk9r28 zgJl#e*hOtmZv9zsAv8qCKnKwM|KNW&|4a5fS;pj-=Fh5xbks_&CJEtWjAevM&kY?5 zfcS~HfgkwGRDz%3Lo?Vw;`rLx*i1rW{#b_SP&B|3I1(YRY?RnbwyKR)X_)}STYX5@ zrSB|FEj9R2o>owDDWNNOX(ab4q-ALgwWor#@O%g4X-P>Q+FH2*!T~qRBX=i*(^{p2 z1oqEf7lvR}kPt3N#J9e}L*O`qMOE45VZ}ge=#=y~cpO{q-;+6cX)1caT$cth2OvpH z>$N{(vMYxs;XNiuJ}8tJ at VPdOB;QzsBORu%fne+a50()D0a_>46ecdv(8iGYueTSS zCnqPJwpXvKQ+b6+7#GvqN(Xfw2NyFO; zxm{~Uu at 9GjFGM%jjA*>i6V&XU{iCJ!oa=4b0H6+`Hd~csg{Mr8O|m(`G)z9lVT^y@ zoZ{MtPq@`J7pQ=0Xpk#6T at 0T`s>(1plXw{;0Gq&Z!P7xf#Qd2L4)w)GE7AV+AH%_lMm)U7$A0 zwkkZJr0v~#pwK~>Nwx_w=c^ZFGaC-kf#6$7`C at 3oc|g?%k^z at k>G0hNDNC55yi(1M z#aY96C#l9qkiEGaElZYPa_yzkhScnBqa at NofI8o?$*$#(l86~AKhFiKOlql^Boc|E zDZn#hF=nt#O_FXaAL+*LBcsy4f(^FtO+Cxe+$Ne(>6v?DA{QzZPj<9K(g7}ns<4v3 z&Lc7NDA(ohXN$$|WH4x!_UQY}{DR`7rfB6*+N%RxGJ#2|kJJBxV)Mm;)8V993>poT{&-ZP%Ug&#*^*^8o|8y(`JG#OE5O=~L-PPic zfN3?=cSQyOg#jXHw?egA4jPo!Qgkv&vx+*hlUa9TJ& zCpb1`c_i;IWuj1&R#~M)brxt{6bGC0cs%2Bh5WH#vMlrJb1Oc=@2(MvJl+lwbOA5< z+9yWQ_b!_wB9UvP9=sYgNQ+cFW1?-$Tq9gv(NK6%3ZEvZk_%L2M+z=U)RoE at DX)Ev zt-QTkb8jT}#GVoegC2MGbmG4LS*9aiCeIw#Ki$fjE}Lxt;z%u+dV{BwI;^~5u0S$T z#+SZ*Qmr;Oz^R)Hv64EbaQDm9+^ExJB`Q$-V=>Ax1nLM-LtfZ9=6^8&#$)Nq)=A-Q z%W)g$d@*f)-dhu4ZU)Kp&>%$EKmPkCXm at vixop31b#b}ecK`5J;N`68(9#M|HIHUi z4Aq3xVo#14S11-ec+5B<5)B|1FRe}tDoWa}C+gI6idEDo*Q>u|_!wQBg5w2Mp4a!k zL1FNKE+_z|O(7WzV1`+1CmQ*)J^2bPmjyzya*y>;3rQ!OZ%czF5}s0LPI&Vcv6O7r z5x?3pb+UD3;}*md3_zBD&VD7b7dYfq|9dwxt+7tzWu^Ut1d at fx2&M0Q^e2x-+6Zt^ z{%u4>`gz|b4+^&4U-WDanx1r-iPXy~M}7jz^~DqvT_UO at Es;hhtLb?CoG)Hye1g;B zaSp2?Yh%^jWO@(hXP5x`P!xcOlHb z{u$H=gLgt>i|l?z%t?Fq_+9HK^ZI^ zQiO*oE`-r1xA6ytj-TT2*D9G~vy<|z56{~wy3MH~)zbp~+xq+h^gwscb~Q1X?!oQH zO`msM$*O+?ks*$f#dLQoW%KsxlXCWNNpZiN!gmAB;D`?*y;?F#H5wSE#493yQiC1B9}Nsl+PYt^nMFTIu|W;($#pgZ^yT^vl1({|Lp zx at V|qKy6z}PNr6IVjhoraNM!@DCFEfDpjXp+&E-sy*KksonkTqMLc-C^E+nii4dcz z@@5-b0PQuK70+Ijlt+&a@`Yu7?qQlc(G0>pKCJmrEnq#4ml{RG-o-o;ZJ-2jxBwg1p zLJ&?#W~Q&i4}cKMj-^*~j7st?P3F&-CGm6rxQ!6~US1Dp9*F~j+3OsvmR;fqK-AhF zPkUivypOiAVAFP=Ly}QWzM3|3%k6c)q8G1wyE?fa*~O;s{gm?y?~SveEoC%C-0`fL zirwqSIjJL`ML3Z2h5pRB6eM0oS%PF_$4>$TwQbgjQ*RENx(RNvF at o1UeNxxqURt! zRiMwOMi>@I2 at fxi{!{g%8;HxTX5B3(#tz#rBKCgUzgVvLs{lot8z+~hj6Y;?j)k#R zElxW*I5Y^+AP!}8ZSfJjk956NHA>j!}j7AFO4_ at r^exM_&fqE2sGKUe|&cPV8 z`_Dil344?+A>4c#8nrDdbXf at 6x^pWr$Hc{+1iciD6UpK?3z3aDu{W_VfIG_Xgy)d0jw=J(Lp+WPC) z?G}m%`rClWO!avB6aG^O#g#!DeA%5&MhVLKymI9dAQ1b*UDd`84CRQr-6qXK*dEy`*3M6I^ZM-iWxY;0iy(6X1Yyh$Qf3$tsQ#X z14Z;e4fNAuvrq at 4XeQBCUW#Lzt({&ix%vEH^uPr<`9M3q)R> zsNaZotV&AnxgC1g7)Ii#YZRau!?{4W00)}!2Go#27*=XSW0uq0rwu_`b+A|F=ZxpA z>N7`!Kei;bdRPXdeqclo z$p|Dp*`nGI-4r!Zoc=2H`z)LquP%#sa3iEBwJ7G at x8A?jNR&31i{9k*>= zih~mZc-}QkdRnX7*}j|qrC^LNw?Vs#AvA at 1I7l|BP;s!=vYbiSehMX3P4Rh8DE at d0 zm1oH;W}@hwZ)Doc&>Q#-tJcQDtD2G#^NW*_wc|q!kIxpDfB5<0cFe_G`%Lk z6RbZvkg|GDORvWD7cz?9qB#f$N zF14COu$S`}O*UO{;^82delqvph5_xWDVhK}L(KH$e_Y?n+pQXPNarx1gV at 1Aqvv7p zOX?ndR!W&1n3nXnMh)w!j&XmxK at j45-KNUtg<=G%Idp zNn7mcjfIOiYg5{D?-Uc5U$)wnIF-$CQ3ELS6ikDk(wx+TKse>tP5L>(D>ADFSS|{; zPMm)pz!8vxM8kzb## zAmbL1r?8dqm9r9Lg at bMSn5Bat0o$4LU!N`P0;bk$v9o at NVFUV2X`y!)#_pG>YCpdn zFno_TtVvEnxOAymTe^d0%CQ?~Am&s1^Feex0>lS9M?S!E+n;=0(S0xk4**nK08Kh- z-4Mujg_AKp2_n!2s3H+foTeSmG&%xS%H{VM{NZ>FwGT6|_5M?E|M=Cwhrb#6pVYzF z+o{O{ssSXvHF)s7%$(6HUzXIlDEg4a12}>U`NI)#cacg#&{AS;F4>jU7qjE^bip?5 zF1oSzs2rABKa)nwP7f at f2PmB_ySmkppPX5XU#&?1VTRV2c{E)6^K at PMqzj?kWQ6LI zSd$s4q#lg{`rr={0Z2bS8Qau&ko|PrPXX~SgqNY at KF--}*cnn|*F8BE98P{}XTty6 zz?h}F_ob#RLd*05eV}{FEN*m>F{NjPuzbDqlA*1gUnS?}$(|>B$olD$`evA|-m(vJ zQ1 at HKu+=pGntjI-LmiHW`OG}K*B|^iz1MWI$eH9_`@yK`-~k$6G&b6{B-UO#O(bA0#w6h>}zV*f8*a07l;R A$^ZZW literal 0 HcmV?d00001 diff --git a/doc/website/index.xhtml b/doc/website/index.xhtml index 78f8d82..bd60464 100644 --- a/doc/website/index.xhtml +++ b/doc/website/index.xhtml @@ -65,12 +65,10 @@ that makes use the NSS library.

- Currently, only HTTPS client - authentication is supported. In the future, Scute will also - allow you to use your OpenPGP Card with Thunderbird for signing and - decrypting e-mails using X.509 certificates. + authentication and S/MIME email signing using X.509 + certificates.

You can read the -- 2.9.0 From dgouttegattat at incenp.org Fri Aug 5 22:45:06 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 5 Aug 2016 22:45:06 +0200 Subject: [PATCH 2/5] doc: Remove obsolete info about Mozilla PSM. In-Reply-To: <20160805204509.15964-1-dgouttegattat@incenp.org> References: <20160805204509.15964-1-dgouttegattat@incenp.org> Message-ID: <20160805204509.15964-3-dgouttegattat@incenp.org> * README: Remove obsolete instruction about the Mozilla Personal Security Manager. -- Mozilla does no longer ship the Personal Security Manager as a separate package; it is now built directly with Firefox. Signed-off-by: Damien Goutte-Gattat --- README | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/README b/README index e4dc01e..43a6212 100644 --- a/README +++ b/README @@ -47,10 +47,7 @@ Installation ============ To install the PKCS #11 Module, follow the generic installation -instructions in the file INSTALL that accompanies this software. You -also need to install the Mozilla Personal Security Manager (PSM), -which may come with your GNU/Linux distribution in a package named -mozilla-psm or similar. +instructions in the file INSTALL that accompanies this software. After installation, you can configure Mozilla to use Scute by visiting the preferences dialog in the "advanced" category, under -- 2.9.0 From dgouttegattat at incenp.org Fri Aug 5 22:45:09 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 5 Aug 2016 22:45:09 +0200 Subject: [PATCH 5/5] doc: Update list of not implemented functions. In-Reply-To: <20160805204509.15964-1-dgouttegattat@incenp.org> References: <20160805204509.15964-1-dgouttegattat@incenp.org> Message-ID: <20160805204509.15964-6-dgouttegattat@incenp.org> * README: Update list of not implemented functions. * doc/manual/scute.texi: Likewise. * TODO: Remove C_GenerateRandom from the TODO list. Signed-off-by: Damien Goutte-Gattat --- README | 6 +----- TODO | 1 - doc/manual/scute.texi | 9 +-------- 3 files changed, 2 insertions(+), 14 deletions(-) diff --git a/README b/README index acc9904..7064b29 100644 --- a/README +++ b/README @@ -317,9 +317,6 @@ The following functions are not supported: C_VerifyRecoverInit, C_VerifyRec: Not supported. Only secret key operations are supported. -* C_SignInit, C_Sign: Currently, only signing 36 bytes - (MD5+SHA1) hashes is supported (used for client authentication). - * C_DecryptInit, C_Decrypt: Not yet supported, but will be in the future. @@ -337,8 +334,7 @@ The following functions are not supported: the tools accompanying the GnuPG software suite to generate and import keys for use with the token. -* C_SeedRandom, C_GenerateRandom: Not supported at this point. - C_GenerateRandom may be supported in the future, though. +* C_SeedRandom: Not supported. * C_CreateObject, C_CopyObject, C_DestroyObject, C_SetAttributeValue: Only read-only operations are supported on objects. diff --git a/TODO b/TODO index 75ef5fd..6f49130 100644 --- a/TODO +++ b/TODO @@ -13,7 +13,6 @@ ** Windows: Find thread-safe replacement for localtime_r and timegm. * Missing features: -** Implement random number generation function C_GenerateRandom. ** Add canonical gnupg logging module. ** Mozilla ignores the CKA_TRUSTED attribute to certificates, so exporting the information from GPGSM (ISTRUSTED) will not be diff --git a/doc/manual/scute.texi b/doc/manual/scute.texi index cf8011d..4c67555 100644 --- a/doc/manual/scute.texi +++ b/doc/manual/scute.texi @@ -710,11 +710,6 @@ Passphrase queries are implemented by the use of GPG Agent and Pinentry. @itemx C_VerifyRec Not supported. Only secret key operations are supported. - at item C_SignInit - at itemx C_Sign -Currently, only signing 36 bytes (MD5+SHA1) hashes is supported (used -for client authentication). - @item C_DecryptInit @itemx C_Decrypt Not yet supported, but will be in the future. @@ -745,9 +740,7 @@ accompanying the GnuPG software suite to generate and import keys for use with the token. @item C_SeedRandom - at itemx C_GenerateRandom -Not supported at this point. @code{C_GenerateRandom} may be supported -in the future, though. +Not supported. @item C_CreateObject @itemx C_CopyObject -- 2.9.0 From wk at gnupg.org Sat Aug 6 10:39:34 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 06 Aug 2016 10:39:34 +0200 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <20160805193947.GB16190@zeromail.org> (ilf@zeromail.org's message of "Fri, 5 Aug 2016 21:39:47 +0200") References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> Message-ID: <87r3a25m0p.fsf@wheatstone.g10code.de> On Fri, 5 Aug 2016 21:39, ilf at zeromail.org said: > IMHO we need *not* be respectful to third-party tools using GnuPG in a > way that it explicitly warns against, exactly because it might break. That's the theory. >> FWIW, I recently learned that there widely used tools which parse >> --list-packets. An option I always considered a debug interface. > > Which ones? Let's contact the maintainers to get them fixed. See debian bug 831500. However this is not the point. Although we can look at Debian's use of gpg we can't do soo for the majority of applications - they are simply not public and people usually don't tell about it. > Funny, when I append a comment after "default-key" in gpg.conf, GnuPG > 2.1 fails for me: > > | % grep ^default-key .gnupg/gpg.conf > | default-key 0xCBB15A68EF3AC804875D5C4E153FE398821C8394 # ilf That is not a common comment pattern. The common pattern is to ignore empty lines and lines with a '#' as first non white space character. A '#' somewhere on the line requires a more explicit grammar to consider it has a "ignore the rest of the line". Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Sat Aug 6 10:45:00 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 06 Aug 2016 10:45:00 +0200 Subject: [PATCH] gpg: Remove tofu database format "split". In-Reply-To: <878twagb0r.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 05 Aug 2016 23:29:24 +0200") References: <1470401597-30913-1-git-send-email-wk@gnupg.org> <2347628.37FLxYZN6v@esus> <878twagb0r.wl-neal@walfield.org> Message-ID: <87mvkq5lrn.fsf@wheatstone.g10code.de> On Fri, 5 Aug 2016 23:29, neal at walfield.org said: > really like the future. Nevertheless, it is only a half solution, > because it doesn't sync my keyring, etc. I think we (well, at least > I) need a tool that can merge two GNUPGHOME directories. An obvious feature for this would be --{export,import}-tofudb similar to --{export,import}-ownertrust. However this will soon get too complicated. Thus it might be useful to think of a backup tool to backup and restore _all_ required files. gpgtar would enable us to do this in a portable way. If we would serialize the databases before taring them up this would allow to implement a --merge-restore feature. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From neal at walfield.org Sat Aug 6 11:45:16 2016 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 06 Aug 2016 11:45:16 +0200 Subject: [PATCH] gpg: Remove tofu database format "split". In-Reply-To: <87mvkq5lrn.fsf@wheatstone.g10code.de> References: <1470401597-30913-1-git-send-email-wk@gnupg.org> <2347628.37FLxYZN6v@esus> <878twagb0r.wl-neal@walfield.org> <87mvkq5lrn.fsf@wheatstone.g10code.de> Message-ID: <874m6yfcyb.wl-neal@walfield.org> On Sat, 06 Aug 2016 10:45:00 +0200, Werner Koch wrote: > On Fri, 5 Aug 2016 23:29, neal at walfield.org said: > > > really like the future. Nevertheless, it is only a half solution, > > because it doesn't sync my keyring, etc. I think we (well, at least > > I) need a tool that can merge two GNUPGHOME directories. > > An obvious feature for this would be --{export,import}-tofudb similar to > --{export,import}-ownertrust. However this will soon get too > complicated. Thus it might be useful to think of a backup tool to > backup and restore _all_ required files. gpgtar would enable us to do > this in a portable way. If we would serialize the databases before > taring them up this would allow to implement a --merge-restore feature. Merging, not exporting, is the tricky part, I think. From patrick at enigmail.net Sat Aug 6 15:02:56 2016 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 6 Aug 2016 15:02:56 +0200 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <87r3a25m0p.fsf@wheatstone.g10code.de> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <87r3a25m0p.fsf@wheatstone.g10code.de> Message-ID: On 06.08.16 10:39, Werner Koch wrote: > On Fri, 5 Aug 2016 21:39, ilf at zeromail.org said: > >> IMHO we need *not* be respectful to third-party tools using GnuPG in a >> way that it explicitly warns against, exactly because it might break. > > That's the theory. > >>> FWIW, I recently learned that there widely used tools which parse >>> --list-packets. An option I always considered a debug interface. >> >> Which ones? Let's contact the maintainers to get them fixed. Enigmail does this too for occasions where gpg does not provide the required information by other means. Examples: * to get the original file name of encrypted files (in case encrypted files have names like "Attachment1.asc") * to find out about the structure of OpenPGP keys before they are imported, for example to ask the user upfront whether the key(s) should be imported. I think you should consider that other tools rely on --list-packets for more than debugging ;-) -Patrick From ilf at zeromail.org Sat Aug 6 16:06:04 2016 From: ilf at zeromail.org (ilf) Date: Sat, 6 Aug 2016 16:06:04 +0200 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <8737mj2e0w.fsf@alice.fifthhorseman.net> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <8737mj2e0w.fsf@alice.fifthhorseman.net> Message-ID: <20160806140604.GG16190@zeromail.org> Daniel Kahn Gillmor: > ilf, what are you asking for when you ask for removing the > "keyid-format" option altogether? As always, dkg is right, and I need to be more precise. Fortunately, I can just quote you: > I'm arguing here that short Key IDs and long Key IDs are actually > useless, and we should stop using them entirely where we can do so. We > certainly should not be exposing normal human users to them. https://debian-administration.org/users/dkg/weblog/105 I assume that the option --keyid-format was first "widely" used to mitigate from --keyid-format "short" to "long" after the first collisions were shown in 2011. That was okay then. https://web.archive.org/web/20160304064423/http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html But as dkg has argued in 2013, we should move away from --keyid-format "short" *and* "long". Which is why "none" was introduced and is now the default. Currently, --keyid-format? > ?"none" does not show the key ID at all but shows the fingerprint in a > separate line. This is good. But "short" and "long" do *only* show the key ID, *and not* the fingerprint in a separate line. (Except if used with --fingerprint, which is what this does: https://github.com/ioerror/duraconf/blob/master/configs/gnupg/gpg.conf) Surely this is not a desired behavior. So I would propose: 1. Short term: Add "the fingerprint in a separate line" for all --keyid-format values. 2. Gradually deprecate the "keyid-format" option. 2.a. Mid term: Add a warning to stderr if keyid-format is explicitly set to anything but "none". Note this in release notes. 2.b. Long term: Remove the parameter entirely. What do you think? -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ilf at zeromail.org Sat Aug 6 16:36:09 2016 From: ilf at zeromail.org (ilf) Date: Sat, 6 Aug 2016 16:36:09 +0200 Subject: Comments - Was: Fingerprints and Key-IDs In-Reply-To: <87r3a25m0p.fsf@wheatstone.g10code.de> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <87r3a25m0p.fsf@wheatstone.g10code.de> Message-ID: <20160806143609.GH16190@zeromail.org> Werner Koch: >> > default-key 0xCBB15A68EF3AC804875D5C4E153FE398821C8394 # ilf > That is not a common comment pattern. The common pattern is to ignore > empty lines and lines with a '#' as first non white space character. A > '#' somewhere on the line requires a more explicit grammar to consider > it has a "ignore the rest of the line". I beg to differ. A few examples, randomly taken from GNU manuals: > In the awk language, a comment starts with the number sign character > (?#?) and continues to the end of the line. The ?#? does not have to > be the first character on the line. https://www.gnu.org/software/gawk/manual/html_node/Comments.html > a word beginning with ?#? causes that word and all remaining > characters on that line to be ignored. https://www.gnu.org/software/bash/manual/html_node/Comments.html#Comments > In the Octave language, a comment starts with either the sharp sign > character, ?#?, or the percent symbol ?%? and continues to the end of > the line. Any text following the sharp sign or percent symbol is > ignored by the Octave interpreter and not executed. The following > example shows whole line and partial line comments. > disp ("Blast Off!"); # Rocket leaves pad https://www.gnu.org/software/octave/doc/v4.0.0/Single-Line-Comments.html#Single-Line-Comments > Comments in m4 are normally delimited by the characters ?#? and > newline. > `quoted text' # `commented text' https://www.gnu.org/software/m4/manual/m4-1.4.15/html_node/Comments.html > According to Posix, Make comments start with # and continue until an > unescaped newline is reached. > $ make # GNU make https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Backslash_002dNewline-Comments.html -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From wk at gnupg.org Sat Aug 6 17:44:51 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 06 Aug 2016 17:44:51 +0200 Subject: Fingerprints and Key-IDs In-Reply-To: (Patrick Brunschwig's message of "Sat, 6 Aug 2016 15:02:56 +0200") References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <87r3a25m0p.fsf@wheatstone.g10code.de> Message-ID: <87wpjt52bw.fsf_-_@wheatstone.g10code.de> On Sat, 6 Aug 2016 15:02, patrick at enigmail.net said: > Examples: > * to get the original file name of encrypted files (in case encrypted > files have names like "Attachment1.asc") There has always been a status line with that; e.g. an encrypted /etc/motd shows on decryption [GNUPG:] PLAINTEXT 62 1470497316 motd > * to find out about the structure of OpenPGP keys before they are > imported, for example to ask the user upfront whether the key(s) should > be imported. You should not do this because all what you see with --list-packets can be faked. If you are interested in the type of the data, you may want to checkout the code in gpgme/src/data-identify.c. gpg 2.1 can also be used to test-import keys. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Sat Aug 6 17:50:40 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 06 Aug 2016 17:50:40 +0200 Subject: Comments - Was: Fingerprints and Key-IDs In-Reply-To: <20160806143609.GH16190@zeromail.org> (ilf@zeromail.org's message of "Sat, 6 Aug 2016 16:36:09 +0200") References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <87r3a25m0p.fsf@wheatstone.g10code.de> <20160806143609.GH16190@zeromail.org> Message-ID: <87shuh5227.fsf@wheatstone.g10code.de> On Sat, 6 Aug 2016 16:36, ilf at zeromail.org said: >> In the awk language, a comment starts with the number sign character Right, that is a langugae with an explicit grammer and not a simple conf file. >> In the Octave language, a comment starts with either the sharp sign >> character, ?#?, or the percent symbol ?%? and continues to the end Ditto. >> Comments in m4 are normally delimited by the characters ?#? and >> newline. >> `quoted text' # `commented text' As a macro processor m4 is pretty special and '#' can be arbitrary redefined (note the "normally" above). >> According to Posix, Make comments start with # and continue until an >> unescaped newline is reached. >> $ make # GNU make Check out all the exception in the gmake manual. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Sat Aug 6 17:56:19 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 06 Aug 2016 17:56:19 +0200 Subject: Fingerprints and Key-IDs In-Reply-To: <20160806140604.GG16190@zeromail.org> (ilf@zeromail.org's message of "Sat, 6 Aug 2016 16:06:04 +0200") References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <8737mj2e0w.fsf@alice.fifthhorseman.net> <20160806140604.GG16190@zeromail.org> Message-ID: <87oa5551ss.fsf_-_@wheatstone.g10code.de> On Sat, 6 Aug 2016 16:06, ilf at zeromail.org said: > I assume that the option --keyid-format was first "widely" used to > mitigate from --keyid-format "short" to "long" after the first 12 years ago: Noteworthy changes in version 1.3.6 (2004-05-22) ------------------------------------------------ * New --keyid-format option that selects short (99242560), long (DB698D7199242560), 0xshort (0x99242560), or 0xlong (0xDB698D7199242560) keyid displays. This lets users tune the display to what they prefer. We simply can't remove that. > But as dkg has argued in 2013, we should move away from --keyid-format > "short" *and* "long". Which is why "none" was introduced and is now 9 years after we first suggested that ;-) > 2.b. Long term: Remove the parameter entirely. Long term is to use 2.1 and that defaults to the new format. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From dkg at fifthhorseman.net Sat Aug 6 18:26:42 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 06 Aug 2016 12:26:42 -0400 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <87r3a25m0p.fsf@wheatstone.g10code.de> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <87r3a25m0p.fsf@wheatstone.g10code.de> Message-ID: <87eg612799.fsf@alice.fifthhorseman.net> On Sat 2016-08-06 04:39:34 -0400, Werner Koch wrote: > On Fri, 5 Aug 2016 21:39, ilf at zeromail.org said: >> [ werner: ] >>> FWIW, I recently learned that there widely used tools which parse >>> --list-packets. An option I always considered a debug interface. >> >> Which ones? Let's contact the maintainers to get them fixed. > > See debian bug 831500. The nice thing about this bug report is that the reporter is acknowledging that his script was broken and wants to fix it :) Even better would be to provide him with a stable interface to do what he wants to do :) fwiw, i also recently saw: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19002 this was code that assumed that it knew exactly how many fields GnuPG would emit in its machine-parseable form. I've opened: https://bugs.gnupg.org/gnupg/issue2437 to try to encourage better communication between gnupg and its programmatic downstream consumers. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From bjk at luxsci.net Sat Aug 6 19:27:38 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Sat, 6 Aug 2016 13:27:38 -0400 Subject: [PATCH] tools/gpgconf.c (main): Initialize libgcrypt. Message-ID: <1470504482-9367085.26936188.fu76HRcRG012022@rs146.luxsci.com> -- Fixes a warning appearing the system logs when --homedir is passed. Signed-off-by: Ben Kibbey --- tools/gpgconf.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tools/gpgconf.c b/tools/gpgconf.c index f7ce4c9..19444df 100644 --- a/tools/gpgconf.c +++ b/tools/gpgconf.c @@ -23,6 +23,7 @@ #include #include #include +#include #include "gpgconf.h" #include "i18n.h" @@ -229,6 +230,12 @@ main (int argc, char **argv) i18n_init(); init_common_subsystems (&argc, &argv); + if (!gcry_check_version (NEED_LIBGCRYPT_VERSION) ) + { + log_fatal ( _("%s is too old (need %s, have %s)\n"), "libgcrypt", + NEED_LIBGCRYPT_VERSION, gcry_check_version (NULL) ); + } + /* Parse the command line. */ pargs.argc = &argc; pargs.argv = &argv; -- 2.8.1 From ilf at zeromail.org Sun Aug 7 12:56:43 2016 From: ilf at zeromail.org (ilf) Date: Sun, 7 Aug 2016 12:56:43 +0200 Subject: Fingerprints and Key-IDs In-Reply-To: <87oa5551ss.fsf_-_@wheatstone.g10code.de> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <8737mj2e0w.fsf@alice.fifthhorseman.net> <20160806140604.GG16190@zeromail.org> <87oa5551ss.fsf_-_@wheatstone.g10code.de> Message-ID: <20160807105643.GI16190@zeromail.org> Werner Koch: > We simply can't remove that. And what about adding the fingerprint in the next line with *all* keyid-format values, instead of just "none"? -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ilf at zeromail.org Sun Aug 7 13:16:18 2016 From: ilf at zeromail.org (ilf) Date: Sun, 7 Aug 2016 13:16:18 +0200 Subject: Comments - Was: Fingerprints and Key-IDs In-Reply-To: <87shuh5227.fsf@wheatstone.g10code.de> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <87r3a25m0p.fsf@wheatstone.g10code.de> <20160806143609.GH16190@zeromail.org> <87shuh5227.fsf@wheatstone.g10code.de> Message-ID: <20160807111618.GK16190@zeromail.org> Werner Koch: > Right, that is a langugae with an explicit grammer and not a simple > conf file. > Ditto. 1. These examples counter your argument, that "That is not a common comment pattern." It's POSIX, and a bunch of GNU software. 2. You're using it yourself: > scriptversion=2011-11-20.07; # UTC http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=build-aux/install-sh;hb=refs/heads/master#l4 3. It works in GnuPG 1.4, just not in 2.1: > % grep ^default-key .gnupg/gpg.conf > default-key 0xCBB15A68EF3AC804875D5C4E153FE398821C8394 # ilf > % gpg --version | head -1 > gpg (GnuPG) 1.4.20 > % gpg --sign > You need a passphrase to unlock the secret key for > user: "ilf " > % gpg2 --version | head -1 > gpg (GnuPG) 2.1.11 > % gpg2 --sign > gpg: secret key "0xCBB15A68EF3AC804875D5C4E153FE398821C8394 # ilf" not found: Invalid user ID > gpg: (check argument of option '--default-key') > gpg: all values passed to '--default-key' ignored Would it really be so complicated to also implement this comment format? -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ben at adversary.org Sun Aug 7 17:29:18 2016 From: ben at adversary.org (Ben McGinnes) Date: Mon, 8 Aug 2016 01:29:18 +1000 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <20160806140604.GG16190@zeromail.org> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <8737mj2e0w.fsf@alice.fifthhorseman.net> <20160806140604.GG16190@zeromail.org> Message-ID: <20160807152918.GB1930@adversary.org> On Sat, Aug 06, 2016 at 04:06:04PM +0200, ilf wrote: > > So I would propose: > > 1. Short term: Add "the fingerprint in a separate line" for all > --keyid-format values. I'm fine with this part. > 2. Gradually deprecate the "keyid-format" option. > > 2.a. Mid term: Add a warning to stderr if keyid-format is explicitly set to > anything but "none". Note this in release notes. > > 2.b. Long term: Remove the parameter entirely. > > What do you think? The rest of it is a problem. For all the reasons Werner mentioned, but also because the current full fingerprint output format (the default in 2.1) does not include any fingerprint or key ID data to identify subkeys. Now for those of you with just one master key to sign everything and one subkey for encryption it may not matter, but for those of us who use a subkey to sign messages and files with the master key only used to certify other keys and make changes this is an issue. It's also why I've still got keyid-format 0xLONG in my gpg.conf. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From ilf at zeromail.org Mon Aug 8 00:04:30 2016 From: ilf at zeromail.org (ilf) Date: Mon, 8 Aug 2016 00:04:30 +0200 Subject: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <87oa57a4r9.fsf@wheatstone.g10code.de> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <20160805085357.GH19126@zeromail.org> <87oa57a4r9.fsf@wheatstone.g10code.de> Message-ID: <20160807220430.GM28435@zeromail.org> Werner Koch: > You are right, the "Version:" has no technical meaning. > I just pushed dkg's patch to master. Thanks again for this. Even after the decision, I want to add a real-world example of why this change helps against de-anonymization: > Both "French Maid" and Force (operating as "Nob") used the exact same > brand of PGP software, a free brand called GnuPG. There are different > brands of PGP software so it is noteworthy that both Force (operating > as "Nob") and "French Main" used the same brand. Not only did Force > and "French Maid" both use the same brand of PGP software, they also > both used the same outdated version of that software, 1.4.12. Version > 1.4.12 was released on January 2012, and was replaced with a new > version by December 2012, and was one of several versions of GnuPG > software. As such, both "French Maid" and Force (as Nob) were using > the specific, older version of the GnuPG software, and neither of them > replaced it with the other (free) version of GnuPG that came out > thereafter. [?] > There are also additional similarities between Force's (Nob's) and > "French Maid's" PGP patterns. Both "Nob" and "French Maid" left > certain default settings on their PGP software. For one thing, both > "French Maid" and Force (Nob) left a "tag" that appeared on every > message authored from their PGP key revealing the brand and version of > PGP software they were using. This is akin to, for example, leaving > the phrase "sent from my iPhone" on the bottom of one's emails but > with greater detail: it would be akin to leaving a phrase like "sent > from my iPhone 6 iOS 8.0.1." Leaving this "tag" on typically reveals > that one is dealing with a fairly inexperienced user of PGP, because > someone that regularly uses PGP to communicate would normally have > changed their settings to omit this tag. http://www.justice.gov/sites/default/files/opa/press-releases/attachments/2015/03/30/criminal_complaint_forcev2.pdf http://www.networkworld.com/article/2904395/microsoft-subnet/mistakes-that-betrayed-anonymity-of-former-dea-agent-and-silk-road-investigator.html -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ilf at zeromail.org Mon Aug 8 10:21:16 2016 From: ilf at zeromail.org (ilf) Date: Mon, 8 Aug 2016 10:21:16 +0200 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <20160807152918.GB1930@adversary.org> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <8737mj2e0w.fsf@alice.fifthhorseman.net> <20160806140604.GG16190@zeromail.org> <20160807152918.GB1930@adversary.org> Message-ID: <20160808082116.GN28435@zeromail.org> Ben McGinnes: > but also because the current full fingerprint output format (the > default in 2.1) does not include any fingerprint or key ID data to > identify subkeys. This can be achieved by using "--fingerprint" twice. man gpg2(1): > If this command is given twice, the fingerprints of all secondary keys > are listed too. gpg (GnuPG) 2.1.14: > % gpg --options /dev/null --fingerprint --fingerprint --list-keys DB4724E6FA4286C92B4E55C4321E4E2373590E5D > pub rsa4096 2012-07-28 [SC] > DB47 24E6 FA42 86C9 2B4E 55C4 321E 4E23 7359 0E5D > uid [ unknown] Ben McGinnes > uid [ unknown] keybase.io/adversary > uid [ unknown] Ben McGinnes > uid [ unknown] Ben McGinnes (backup email address) > sub rsa3072 2012-07-28 [S] > B7F0 FE75 9387 430D D0C5 8BDB 7FF2 D371 35C7 553C > sub elg4096 2012-07-28 [E] > 9CBE F6B7 E0DF 72CF 9100 9AA5 C98B AA18 62E4 484D Ben McGinnes: > It's also why I've still got keyid-format 0xLONG in my gpg.conf. You can also add "fingerprint" twice into gpg.conf. -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From justus at g10code.com Mon Aug 8 11:22:10 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 08 Aug 2016 11:22:10 +0200 Subject: [PATCH] tools/gpgconf.c (main): Initialize libgcrypt. In-Reply-To: <1470504482-9367085.26936188.fu76HRcRG012022@rs146.luxsci.com> References: <1470504482-9367085.26936188.fu76HRcRG012022@rs146.luxsci.com> Message-ID: <87shufaa4d.fsf@europa.jade-hamburg.de> Hello :) Ben Kibbey writes: > -- > Fixes a warning appearing the system logs when --homedir is passed. I don't understand, what warning ends up in what log? Also, please mind our commit log guidelines, see doc/HACKING. > @@ -229,6 +230,12 @@ main (int argc, char **argv) > i18n_init(); > init_common_subsystems (&argc, &argv); > > + if (!gcry_check_version (NEED_LIBGCRYPT_VERSION) ) > + { > + log_fatal ( _("%s is too old (need %s, have %s)\n"), "libgcrypt", > + NEED_LIBGCRYPT_VERSION, gcry_check_version (NULL) ); > + } > + Hmm, as I see it, init_common_subsystems registers gcry_realloc as allocation function for libgpg-error. So shouldn't this check be included before init_common_subsystems, or maybe even just moved to init_common_subsystems? Also, I don't like the 'function ( space, before, argument )' style, and cursory grepping reveals that using 'function (no, space, before, argument)' is more common in GnuPG. At least please be consistent. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From justus at g10code.com Mon Aug 8 11:38:03 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 08 Aug 2016 11:38:03 +0200 Subject: [PATCH 0/5] Scute: Update documentation. In-Reply-To: <20160805204509.15964-1-dgouttegattat@incenp.org> References: <20160805204509.15964-1-dgouttegattat@incenp.org> Message-ID: <87popja9dw.fsf@europa.jade-hamburg.de> Damien Goutte-Gattat writes: > The following patch series updates the documentation for the Scute > project to reflect some recent (or not so recent) changes in the > code. > > In particular, it documents new usages (beyond HTTPS client > authentication) that are possible now that Scute can sign any > type of hash value. > > Damien Goutte-Gattat (5): > doc: Scute can automatically start the agent. > doc: Remove obsolete info about Mozilla PSM. > doc: Scute can now be used to sign emails. > doc: Scute can be used to sign documents. > doc: Update list of not implemented functions. All merged, many thanks! Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Aug 9 00:13:15 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 8 Aug 2016 18:13:15 -0400 Subject: [PATCH] dirmngr: clarify deprecation of --daemon without --homedir Message-ID: <1470694395-3627-1-git-send-email-dkg@fifthhorseman.net> * doc/dirmngr.texi: clarify that --daemon is only deprecated without --homedir -- The existing documentation claims that dirmngr --daemon is deprecated. But "gpgconf --launch dirmngr" and "gpg-connect-agent --dirmngr" (the two documented ways to reliably start dirmngr) both spawn dirmngr using a --daemon argument. I believe what's actually deprecated is --daemon *without* --homedir. This patch attempts to clarify the documentation. Debian-bug-id: 833565 Signed-off-by: Daniel Kahn Gillmor --- doc/dirmngr.texi | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index 033b5d3..126e7bb 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -88,7 +88,8 @@ This is only used for testing. @opindex daemon Run in background daemon mode and listen for commands on a socket. Note that this also changes the default home directory and enables the -internal certificate validation code. This mode is deprecated. +internal certificate validation code. Running in @code{--daemon} mode +without supplying @{--homedir} is deprecated. @item --list-crls @opindex list-crls @@ -146,7 +147,8 @@ running mode: @item With @code{--daemon} given on the commandline the directory named @file{@value{SYSCONFDIR}} is used for configuration files -and @file{@value{LOCALCACHEDIR}} for cached CRLs. +and @file{@value{LOCALCACHEDIR}} for cached CRLs. This mode of operation +(@code{--daemon} but no explicit @code{--homedir}) is deprecated. @item Without @code{--daemon} given on the commandline the directory named @file{.gnupg} directly below the home directory -- 2.8.1 From bjk at luxsci.net Tue Aug 9 00:40:03 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Mon, 8 Aug 2016 18:40:03 -0400 Subject: [PATCH] tools/gpgconf.c (main): Initialize libgcrypt. In-Reply-To: <87shufaa4d.fsf@europa.jade-hamburg.de> References: <1470504482-9367085.26936188.fu76HRcRG012022@rs146.luxsci.com> <87shufaa4d.fsf@europa.jade-hamburg.de> Message-ID: <1470696008-6356719.77400402.fu78Me4Ws030991@rs146.luxsci.com> On Mon, Aug 08, 2016 at 11:22:10AM +0200, Justus Winter wrote: > > Fixes a warning appearing the system logs when --homedir is passed. > > I don't understand, what warning ends up in what log? Also, please mind > our commit log guidelines, see doc/HACKING. The logged message is: Libgcrypt warning: missing initialization - please fix the application > > > @@ -229,6 +230,12 @@ main (int argc, char **argv) > > i18n_init(); > > init_common_subsystems (&argc, &argv); > > > > + if (!gcry_check_version (NEED_LIBGCRYPT_VERSION) ) > > + { > > + log_fatal ( _("%s is too old (need %s, have %s)\n"), "libgcrypt", > > + NEED_LIBGCRYPT_VERSION, gcry_check_version (NULL) ); > > + } > > + > > Hmm, as I see it, init_common_subsystems registers gcry_realloc as > allocation function for libgpg-error. So shouldn't this check be > included before init_common_subsystems, or maybe even just moved to > init_common_subsystems? > > Also, I don't like the 'function ( space, before, argument )' style, and > cursory grepping reveals that using 'function (no, space, before, > argument)' is more common in GnuPG. At least please be consistent. Fixed in the attached patch. -- Ben Kibbey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Cleanup-initialization-of-libgcrypt.patch Type: text/x-diff Size: 9949 bytes Desc: not available URL: From gniibe at fsij.org Tue Aug 9 10:39:48 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 9 Aug 2016 17:39:48 +0900 Subject: gpg-agent: SSH certificate support In-Reply-To: <87k2fva1zn.fsf@wheatstone.g10code.de> References: <1ae83c4f-90ba-1429-edbc-9489f3e8d673@fsij.org> <87k2fva1zn.fsf@wheatstone.g10code.de> Message-ID: On 08/05/2016 08:28 PM, Werner Koch wrote: > On Fri, 5 Aug 2016 10:48, gniibe at fsij.org said: >> read_key_file (const unsigned char *grip, gcry_sexp_t *result, int *ssh) >> >> When SSH is not NULL, it means allowing returning SSH certificate. > > I would suggest to change to "char **ssh" and return a malloced buffer > with the certificate (in some encoding). The creation and parsing of > the s-expressions is quite complicate when not using Lisp and we need to > return that data anyway as a plain buffer. This way we reduce the risk > of introducing bugs in code paths not related to the ssh certificates. > > To be future proof an strlist_t could also be used which would allow to > return several certifciates or other info. Thank you for the suggestions. In the protocol of SSH (extended by OpenSSH), only single certificate is supported. So, I take simpler approach, currently. Now, in my working directory, I have following changes. Since I don't have any SSH certificate, it is not tested yet. I only checked it builds with no problem and "make check" goes successfully. I'll create SSH certificate to test this patch. diff --git a/agent/agent.h b/agent/agent.h index fe5ffba..b541037 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -396,7 +396,8 @@ gpg_error_t agent_raw_key_from_file (ctrl_t ctrl, const unsigned char *grip, gcry_sexp_t *result); gpg_error_t agent_public_key_from_file (ctrl_t ctrl, const unsigned char *grip, - gcry_sexp_t *result); + gcry_sexp_t *result, + char **r_ssh_cert); int agent_is_dsa_key (gcry_sexp_t s_key); int agent_is_eddsa_key (gcry_sexp_t s_key); int agent_key_available (const unsigned char *grip); diff --git a/agent/command-ssh.c b/agent/command-ssh.c index b01cc06..8671154 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -2274,12 +2274,13 @@ ssh_receive_key (estream_t stream, gcry_sexp_t *key_new, int secret, } -/* Write the public key from KEY to STREAM in SSH key format. If - OVERRIDE_COMMENT is not NULL, it will be used instead of the - comment stored in the key. */ +/* Write the public key from KEY to STREAM in SSH key format. Or + write the certificate of CERT to STREAM in SSH key format. CERT + has precedence over KEY. If OVERRIDE_COMMENT is not NULL, it will + be used instead of the comment stored in the key. */ static gpg_error_t ssh_send_key_public (estream_t stream, gcry_sexp_t key, - const char *override_comment) + char *cert, const char *override_comment) { ssh_key_type_spec_t spec; int algo; @@ -2288,21 +2289,48 @@ ssh_send_key_public (estream_t stream, gcry_sexp_t key, size_t bloblen; gpg_error_t err = 0; - algo = get_pk_algo_from_key (key); - if (algo == 0) - goto out; + if (cert) + { + struct b64state state; + size_t nbytes; - err = ssh_key_type_lookup (NULL, algo, &spec); - if (err) - goto out; + err = b64dec_start (&state, NULL); + if (err) + goto out; - err = ssh_key_to_blob (key, 0, spec, &blob, &bloblen); - if (err) - goto out; + err = b64dec_proc (&state, cert, strlen (cert), &nbytes); + if (err) + goto out; - err = stream_write_string (stream, blob, bloblen); - if (err) - goto out; + err = b64dec_finish (&state); + if (err) + goto out; + + err = stream_write_string (stream, cert, nbytes); + if (err) + goto out; + } + else + { + algo = get_pk_algo_from_key (key); + if (algo == 0) + { + err = gpg_error (GPG_ERR_BAD_SECKEY); + goto out; + } + + err = ssh_key_type_lookup (NULL, algo, &spec); + if (err) + goto out; + + err = ssh_key_to_blob (key, 0, spec, &blob, &bloblen); + if (err) + goto out; + + err = stream_write_string (stream, blob, bloblen); + if (err) + goto out; + } if (override_comment) err = stream_write_cstring (stream, override_comment); @@ -2588,7 +2616,7 @@ ssh_handler_request_identities (ctrl_t ctrl, if (!opt.disable_scdaemon && !card_key_available (ctrl, &key_public, &cardsn)) { - err = ssh_send_key_public (key_blobs, key_public, cardsn); + err = ssh_send_key_public (key_blobs, key_public, NULL, cardsn); gcry_sexp_release (key_public); key_public = NULL; xfree (cardsn); @@ -2606,6 +2634,7 @@ ssh_handler_request_identities (ctrl_t ctrl, while (!read_control_file_item (cf)) { unsigned char grip[20]; + char *cert; if (!cf->item.valid) continue; /* Should not happen. */ @@ -2614,14 +2643,17 @@ ssh_handler_request_identities (ctrl_t ctrl, assert (strlen (cf->item.hexgrip) == 40); hex2bin (cf->item.hexgrip, grip, sizeof (grip)); - err = agent_public_key_from_file (ctrl, grip, &key_public); + err = agent_public_key_from_file (ctrl, grip, &key_public, &cert); if (err) { - log_error ("failed to read the public key\n"); + log_error ("%s:%d: key '%s' skipped: %s\n", + cf->fname, cf->lnr, cf->item.hexgrip, + gpg_strerror (err)); continue; } - err = ssh_send_key_public (key_blobs, key_public, NULL); + err = ssh_send_key_public (key_blobs, key_public, cert, NULL); + xfree (cert); if (err) goto out; gcry_sexp_release (key_public); diff --git a/agent/command.c b/agent/command.c index 7fc28ad..f72c0a7 100644 --- a/agent/command.c +++ b/agent/command.c @@ -998,7 +998,7 @@ cmd_readkey (assuan_context_t ctx, char *line) if (rc) return rc; /* Return immediately as this is already an Assuan error code.*/ - rc = agent_public_key_from_file (ctrl, grip, &s_pkey); + rc = agent_public_key_from_file (ctrl, grip, &s_pkey, NULL); if (!rc) { size_t len; diff --git a/agent/findkey.c b/agent/findkey.c index c5ab0e9..894243c 100644 --- a/agent/findkey.c +++ b/agent/findkey.c @@ -634,9 +634,13 @@ unprotect (ctrl_t ctrl, const char *cache_nonce, const char *desc_text, /* Read the key identified by GRIP from the private key directory and return it as an gcrypt S-expression object in RESULT. On failure - returns an error code and stores NULL at RESULT. */ + returns an error code and stores NULL at RESULT. If R_SSH_CERT is + not NULL and certificate information is available in the Extended + Private Key Format, certificate encoded in base64 is stored there. +*/ static gpg_error_t -read_key_file (const unsigned char *grip, gcry_sexp_t *result) +read_key_file (const unsigned char *grip, gcry_sexp_t *result, + char **r_ssh_cert) { int rc; char *fname; @@ -699,10 +703,22 @@ read_key_file (const unsigned char *grip, gcry_sexp_t *result) else { rc = nvc_get_private_key (pk, result); - nvc_release (pk); if (rc) log_error ("error getting private key from '%s': %s\n", fname, gpg_strerror (rc)); + else + { + nve_t e = nvc_lookup (pk, "OpenSSH-cert"); + if (e) + { + char *cert_str; + + cert_str = nve_value (e); + if (cert_str) + *r_ssh_cert = xtrystrdup (cert_str); + } + } + nvc_release (pk); } xfree (fname); @@ -811,7 +827,7 @@ agent_key_from_file (ctrl_t ctrl, const char *cache_nonce, if (r_passphrase) *r_passphrase = NULL; - rc = read_key_file (grip, &s_skey); + rc = read_key_file (grip, &s_skey, NULL); if (rc) { if (gpg_err_code (rc) == GPG_ERR_ENOENT) @@ -1141,7 +1157,7 @@ agent_raw_key_from_file (ctrl_t ctrl, const unsigned char *grip, *result = NULL; - err = read_key_file (grip, &s_skey); + err = read_key_file (grip, &s_skey, NULL); if (!err) *result = s_skey; return err; @@ -1151,11 +1167,14 @@ agent_raw_key_from_file (ctrl_t ctrl, const unsigned char *grip, /* Return the public key for the keygrip GRIP. The result is stored at RESULT. This function extracts the public key from the private key database. On failure an error code is returned and NULL stored - at RESULT. */ + at RESULT. When OpenSSH cert information is available and + R_SSH_CERT is not NULL, base64 encoded string is stored there. The + caller needs to free the returned certificate in base64. +*/ gpg_error_t agent_public_key_from_file (ctrl_t ctrl, const unsigned char *grip, - gcry_sexp_t *result) + gcry_sexp_t *result, char **r_ssh_cert) { gpg_error_t err; int i, idx; @@ -1178,8 +1197,9 @@ agent_public_key_from_file (ctrl_t ctrl, (void)ctrl; *result = NULL; + *r_ssh_cert = NULL; - err = read_key_file (grip, &s_skey); + err = read_key_file (grip, &s_skey, r_ssh_cert); if (err) return err; @@ -1190,6 +1210,8 @@ agent_public_key_from_file (ctrl_t ctrl, array, DIM (array), &curve, &flags); if (err) { + xfree (*r_ssh_cert); + *r_ssh_cert = NULL; gcry_sexp_release (s_skey); return err; } @@ -1221,6 +1243,8 @@ agent_public_key_from_file (ctrl_t ctrl, format = xtrymalloc (15+4+7*npkey+10+15+1+1); if (!format) { + xfree (*r_ssh_cert); + *r_ssh_cert = NULL; err = gpg_error_from_syserror (); for (i=0; array[i]; i++) gcry_mpi_release (array[i]); @@ -1275,6 +1299,11 @@ agent_public_key_from_file (ctrl_t ctrl, if (!err) *result = list; + else + { + xfree (*r_ssh_cert); + *r_ssh_cert = NULL; + } return err; } @@ -1324,7 +1353,7 @@ agent_key_info_from_file (ctrl_t ctrl, const unsigned char *grip, { gcry_sexp_t sexp; - err = read_key_file (grip, &sexp); + err = read_key_file (grip, &sexp, NULL); if (err) { if (gpg_err_code (err) == GPG_ERR_ENOENT) @@ -1405,7 +1434,7 @@ agent_delete_key (ctrl_t ctrl, const char *desc_text, char hexgrip[40+4+1]; char *default_desc = NULL; - err = read_key_file (grip, &s_skey); + err = read_key_file (grip, &s_skey, NULL); if (gpg_err_code (err) == GPG_ERR_ENOENT) err = gpg_error (GPG_ERR_NO_SECKEY); if (err) diff --git a/agent/pksign.c b/agent/pksign.c index 9011be2..2b16a30 100644 --- a/agent/pksign.c +++ b/agent/pksign.c @@ -332,7 +332,7 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, int is_ECDSA = 0; int is_EdDSA = 0; - rc = agent_public_key_from_file (ctrl, ctrl->keygrip, &s_pkey); + rc = agent_public_key_from_file (ctrl, ctrl->keygrip, &s_pkey, NULL); if (rc) { log_error ("failed to read the public key\n"); -- From justus at g10code.com Tue Aug 9 10:59:41 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 09 Aug 2016 10:59:41 +0200 Subject: [PATCH] tools/gpgconf.c (main): Initialize libgcrypt. In-Reply-To: <1470696008-6356719.77400402.fu78Me4Ws030991@rs146.luxsci.com> References: <1470504482-9367085.26936188.fu76HRcRG012022@rs146.luxsci.com> <87shufaa4d.fsf@europa.jade-hamburg.de> <1470696008-6356719.77400402.fu78Me4Ws030991@rs146.luxsci.com> Message-ID: <87ziomfhc2.fsf@europa.jade-hamburg.de> Ben Kibbey writes: > * common/init.c (init_common_subsystems): Initialize libgcrypt. Merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From wk at gnupg.org Tue Aug 9 11:34:02 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Aug 2016 11:34:02 +0200 Subject: [Announce] OpenPGP.conf early bird ends in 3 days Message-ID: <87wpjqs2ut.fsf@wheatstone.g10code.de> Hello! 5 weeks to go for the first OpenPGP conference on September 8 and 9 and 3 days to register with early bird discount. Hurry up. OpenPGP.conf is a place to meet, discuss, and learn about latest developments of OpenPGP aware applications and what technical measures can be deployed to repel the ever increasing trend to mass surveillance. We have two full days with topics around the protocol and use of OpenPGP. There will also be enough time to discuss with experienced users and developers. The talks and their speakers are: - A few concerns regarding PGP, new directions by Stefan 'stf' Marsiske - A Simple Solution to Key Discovery by Werner Koch - A stateless model for browser encryption in GlobaLeaks by Nick Skelsey - An update on the sks-keyservers.net services by Kristian Fiskerstrand - Automated use of GnuPG through GPGME by Andre Heinecke - Bypass Pinentry for good by Seiya Kawashima - Gnuk 1.2 by Yutaka NIIBE - GnuPG in Debian by Daniel Kahn Gillmor - History of OpenPGP by Lutz Donnerhacke - NEXTLEAP and automatic E2E emails by Holger Krekel - OpenKeychain UX decisions by Dominik Sch?rmann and Vincent Breitmoser - The Mathematical Mesh: Management of keys by Phillip Hallam-Baker - The State of three contracts from the German BSI by Bernhard Reiter - Transparent key management at LEAP by meskio For details see https://openpgp-conf.org . The organizer told me that there are still sufficient resources in their conference fee grant program. See you in Cologne, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 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 justus at g10code.com Tue Aug 9 12:36:26 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 09 Aug 2016 12:36:26 +0200 Subject: [STABLE-BRANCH-2-0 PATCH] gpg: Avoid publishing the GnuPG version by default In-Reply-To: <1470408471-30883-1-git-send-email-dkg@fifthhorseman.net> References: <87oa57a4r9.fsf@wheatstone.g10code.de> <1470408471-30883-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87wpjqfcut.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > * g10/gpg.c (main): initialize opt.emit_version to 0 > * doc/gpg.texi: document different default for --emit-version Both backports merged, thanks! Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From bjk at luxsci.net Wed Aug 10 01:28:55 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Tue, 9 Aug 2016 19:28:55 -0400 Subject: [PATCH] tools/gpgconf.c (main): Initialize libgcrypt. In-Reply-To: <87ziomfhc2.fsf@europa.jade-hamburg.de> References: <1470504482-9367085.26936188.fu76HRcRG012022@rs146.luxsci.com> <87shufaa4d.fsf@europa.jade-hamburg.de> <1470696008-6356719.77400402.fu78Me4Ws030991@rs146.luxsci.com> <87ziomfhc2.fsf@europa.jade-hamburg.de> Message-ID: <1470785342-7832792.54094846.fu79NStRT021298@rs146.luxsci.com> On Tue, Aug 09, 2016 at 10:59:41AM +0200, Justus Winter wrote: > Ben Kibbey writes: > > > * common/init.c (init_common_subsystems): Initialize libgcrypt. > > Merged, thanks! Noticed the mention of header files and GPG_ERR_SOURCE on xmpp so I revised the original patch to move gcrypt.h after everything else and also coding style. Should apply after reverting the previous one. There is still the problem of gcry_realloc being set before initialization but I couldn't find anywhere that it is actually used in init_common_subsystems(). The esteams support in libgpg-error makes use of it, but the only IO done is with WinCE and doesn't seem to call any estreams functions that I could see. -- Ben Kibbey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpgconf-Initialize-libgcrypt.patch Type: text/x-diff Size: 1126 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Aug 10 03:37:37 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 9 Aug 2016 21:37:37 -0400 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <8760rd25ye.fsf@alice.fifthhorseman.net> References: <8760rd25ye.fsf@alice.fifthhorseman.net> Message-ID: <1470793057-12340-1-git-send-email-dkg@fifthhorseman.net> * dirmngr/dirmngr.c (main): add new --supervised command, which is a mode designed for running under a process supervision system like systemd or runit. * doc/dirmngr.text: document --supervised and its interaction with --log-file * dirmngr/systemd-user/{README,dirmngr.{socket,service}}: new. System integration notes and configuration for socket-activated dirmngr on machines that run systemd -- "dirmngr --supervised" is a way to invoke dirmngr such that a system supervisor like systemd can provide socket-activated startup, log management, and scheduled shutdown. When running in this mode, dirmngr: * does not open its own listening socket; rather, it expects to be given a listening socket on file descriptor 3 * does not open or manage any logfile; instead, it logs to stdout and/or stderr * does not detach from the invoking process, staying in the foreground instead The dirmngr/systemd-user directory contains a brief README and some configuration files that enable socket-activated and cleanly-terminated dirmngr system integration on machines that run systemd. Signed-off-by: Daniel Kahn Gillmor --- dirmngr/dirmngr.c | 26 +++++++++++++++++++++++ dirmngr/systemd-user/README | 40 ++++++++++++++++++++++++++++++++++++ dirmngr/systemd-user/dirmngr.service | 6 ++++++ dirmngr/systemd-user/dirmngr.socket | 11 ++++++++++ doc/dirmngr.texi | 11 +++++++++- 5 files changed, 93 insertions(+), 1 deletion(-) create mode 100644 dirmngr/systemd-user/README create mode 100644 dirmngr/systemd-user/dirmngr.service create mode 100644 dirmngr/systemd-user/dirmngr.socket diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c index 007fa10..b57cd1e 100644 --- a/dirmngr/dirmngr.c +++ b/dirmngr/dirmngr.c @@ -94,6 +94,7 @@ enum cmd_and_opt_values { aServer, aDaemon, + aSupervised, aService, aListCRLs, aLoadCRL, @@ -155,6 +156,7 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_c (aServer, "server", N_("run in server mode (foreground)") ), ARGPARSE_c (aDaemon, "daemon", N_("run in daemon mode (background)") ), + ARGPARSE_c (aSupervised, "supervised", N_("run under supervision (e.g. systemd)")), #ifdef USE_W32_SERVICE ARGPARSE_c (aService, "service", N_("run as windows service (background)")), #endif @@ -911,6 +913,7 @@ main (int argc, char **argv) { case aServer: case aDaemon: + case aSupervised: case aService: case aShutdown: case aFlush: @@ -1093,6 +1096,29 @@ main (int argc, char **argv) start_command_handler (ASSUAN_INVALID_FD); shutdown_reaper (); } + else if (cmd == aSupervised) + { + /* In supervised mode, we expect file descriptor 3 to be an + already opened, listening socket. + + We will also not detach from the controlling process or close + stderr, and we do not open any logfile; the supervisor should + handle all of that. + + FIXME: should we try to extract the actual socket_name + from the file descriptor with getsockname(2) so that we + can return it in response to "GETINFO socket_name"? This + isn't currently done when --socket-name is supplied. + */ +#if USE_LDAP + ldap_wrapper_launch_thread (); +#endif /*USE_LDAP*/ + cert_cache_init (); + crl_cache_init (); + handle_connections (3); + assuan_sock_close (3); + shutdown_reaper (); + } else if (cmd == aDaemon) { assuan_fd_t fd; diff --git a/dirmngr/systemd-user/README b/dirmngr/systemd-user/README new file mode 100644 index 0000000..938740e --- /dev/null +++ b/dirmngr/systemd-user/README @@ -0,0 +1,40 @@ +Socket-activated dirmngr with systemd +===================================== + +When used on a GNU/Linux system supervised by systemd, you can ensure +that dirmngr is launched automatically the first time it's needed, and +shut down cleanly at session logout by enabling the dirmngr user +service via socket-activation. + +System distributors +------------------- + +The dirmngr.service and dirmngr.socket (from this directory) should be +placed in /usr/lib/systemd/user/ alongside other user-session services +and sockets. + +To enable socket-activated dirmngr for all accounts on the system, +use: + + systemctl --user --global enable dirmngr.socket + + +Individual users +---------------- + +A user on a system with systemd where this has not been installed +system-wide can place these files in ~/.config/systemd/user/ to make +them available. + +If it isn't installed system-wide, or it's installed system-wide but +not globally enabled hasn't been done, individual users will still +need to enable it: + +Users who want to enable socket-activated dirmngr for all future +sessions can do so with: + + systemctl --user enable dirmngr.socket + +To set up socket-activated dirmngr for the current session, use: + + systemctl --user start dirmngr.socket diff --git a/dirmngr/systemd-user/dirmngr.service b/dirmngr/systemd-user/dirmngr.service new file mode 100644 index 0000000..329ac76 --- /dev/null +++ b/dirmngr/systemd-user/dirmngr.service @@ -0,0 +1,6 @@ +[Unit] +Description=GnuPG network certificate management daemon +Documentation=man:dirmngr(8) + +[Service] +ExecStart=/usr/bin/dirmngr --supervised diff --git a/dirmngr/systemd-user/dirmngr.socket b/dirmngr/systemd-user/dirmngr.socket new file mode 100644 index 0000000..a840756 --- /dev/null +++ b/dirmngr/systemd-user/dirmngr.socket @@ -0,0 +1,11 @@ +[Unit] +Description=dirmngr listening socket +Documentation=man:dirmngr(8) +Before=sockets.target + +[Socket] +ListenStream=/run/user/%U/gnupg/S.dirmngr +SocketMode=0600 + +[Install] +WantedBy=default.target diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index 033b5d3..3b64b19 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -90,6 +90,13 @@ Run in background daemon mode and listen for commands on a socket. Note that this also changes the default home directory and enables the internal certificate validation code. This mode is deprecated. + at item --supervised + at opindex supervised +Run in the foreground, sending logs to stderr, and listening on file +descriptor 3, which must already be bound to a listening socket. This +is useful when running under systemd or other similar process +supervision schemes. + @item --list-crls @opindex list-crls List the contents of the CRL cache on @code{stdout}. This is probably @@ -168,7 +175,9 @@ verbose commands to @sc{dirmngr}, such as @option{-vv}. @item --log-file @var{file} @opindex log-file Append all logging output to @var{file}. This is very helpful in -seeing what the agent actually does. +seeing what the agent actually does. This has no effect in + at code{--supervised} mode, as the process supervisor is expected to +handle all logging (e.g., @code{journalctl --user -u dirmngr}). @item --debug-level @var{level} @opindex debug-level -- 2.8.1 From gniibe at fsij.org Wed Aug 10 05:09:48 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 10 Aug 2016 12:09:48 +0900 Subject: gpg-agent: SSH certificate support In-Reply-To: References: <1ae83c4f-90ba-1429-edbc-9489f3e8d673@fsij.org> <87k2fva1zn.fsf@wheatstone.g10code.de> Message-ID: <44c2e51a-5b06-ddf8-b7e2-9c6c0571da49@fsij.org> On 08/09/2016 05:39 PM, NIIBE Yutaka wrote: > Now, in my working directory, I have following changes. > > Since I don't have any SSH certificate, it is not tested yet. I only > checked it builds with no problem and "make check" goes successfully. > > I'll create SSH certificate to test this patch. Here is a updated version. I confirmed that it works for me (somehow). However, it's not the one I had expected; I found that OpenSSH and ssh-agent interactions are not the one I had expected. I had expected: if gpg-agent answers with certificate(s) for REQUEST_IDENTITIES, it were enough. No, the situation is different. It is actually not needed, for current protocol between ssh and ssh-agent. To use SSH certificate authentication, I need to prepare a file: ~/.ssh/id_rsa-cert.pub which is the OpenSSH certificate of my authentication key. When it is available, the client program of OpenSSH (ssh) does certificate authentication after normal public key authentication with this file. Then, ssh asks signing to ssh-agent. I think that we need to modify OpenSSH client program to use certificates which are answered by ssh-agent. After such a modification of OpenSSH, following patch will make sense. diff --git a/agent/agent.h b/agent/agent.h index fe5ffba..b541037 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -396,7 +396,8 @@ gpg_error_t agent_raw_key_from_file (ctrl_t ctrl, const unsigned char *grip, gcry_sexp_t *result); gpg_error_t agent_public_key_from_file (ctrl_t ctrl, const unsigned char *grip, - gcry_sexp_t *result); + gcry_sexp_t *result, + char **r_ssh_cert); int agent_is_dsa_key (gcry_sexp_t s_key); int agent_is_eddsa_key (gcry_sexp_t s_key); int agent_key_available (const unsigned char *grip); diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 2def342..4b02cde 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -2280,12 +2280,13 @@ ssh_receive_key (estream_t stream, gcry_sexp_t *key_new, int secret, } -/* Write the public key from KEY to STREAM in SSH key format. If - OVERRIDE_COMMENT is not NULL, it will be used instead of the - comment stored in the key. */ +/* Write the public key from KEY to STREAM in SSH key format. Or + write the certificate of CERT to STREAM in SSH key format. CERT + has precedence over KEY. If OVERRIDE_COMMENT is not NULL, it will + be used instead of the comment stored in the key. */ static gpg_error_t ssh_send_key_public (estream_t stream, gcry_sexp_t key, - const char *override_comment) + char *cert, const char *override_comment) { ssh_key_type_spec_t spec; int algo; @@ -2294,21 +2295,48 @@ ssh_send_key_public (estream_t stream, gcry_sexp_t key, size_t bloblen; gpg_error_t err = 0; - algo = get_pk_algo_from_key (key); - if (algo == 0) - goto out; + if (cert) + { + struct b64state state; + size_t nbytes; - err = ssh_key_type_lookup (NULL, algo, &spec); - if (err) - goto out; + err = b64dec_start (&state, NULL); + if (err) + goto out; - err = ssh_key_to_blob (key, 0, spec, &blob, &bloblen); - if (err) - goto out; + err = b64dec_proc (&state, cert, strlen (cert), &nbytes); + if (err) + goto out; - err = stream_write_string (stream, blob, bloblen); - if (err) - goto out; + err = b64dec_finish (&state); + if (err) + goto out; + + err = stream_write_string (stream, cert, nbytes); + if (err) + goto out; + } + else + { + algo = get_pk_algo_from_key (key); + if (algo == 0) + { + err = gpg_error (GPG_ERR_BAD_SECKEY); + goto out; + } + + err = ssh_key_type_lookup (NULL, algo, &spec); + if (err) + goto out; + + err = ssh_key_to_blob (key, 0, spec, &blob, &bloblen); + if (err) + goto out; + + err = stream_write_string (stream, blob, bloblen); + if (err) + goto out; + } if (override_comment) err = stream_write_cstring (stream, override_comment); @@ -2594,7 +2622,7 @@ ssh_handler_request_identities (ctrl_t ctrl, if (!opt.disable_scdaemon && !card_key_available (ctrl, &key_public, &cardsn)) { - err = ssh_send_key_public (key_blobs, key_public, cardsn); + err = ssh_send_key_public (key_blobs, key_public, NULL, cardsn); gcry_sexp_release (key_public); key_public = NULL; xfree (cardsn); @@ -2612,6 +2640,7 @@ ssh_handler_request_identities (ctrl_t ctrl, while (!read_control_file_item (cf)) { unsigned char grip[20]; + char *cert; if (!cf->item.valid) continue; /* Should not happen. */ @@ -2620,14 +2649,17 @@ ssh_handler_request_identities (ctrl_t ctrl, assert (strlen (cf->item.hexgrip) == 40); hex2bin (cf->item.hexgrip, grip, sizeof (grip)); - err = agent_public_key_from_file (ctrl, grip, &key_public); + err = agent_public_key_from_file (ctrl, grip, &key_public, &cert); if (err) { - log_error ("failed to read the public key\n"); + log_error ("%s:%d: key '%s' skipped: %s\n", + cf->fname, cf->lnr, cf->item.hexgrip, + gpg_strerror (err)); continue; } - err = ssh_send_key_public (key_blobs, key_public, NULL); + err = ssh_send_key_public (key_blobs, key_public, cert, NULL); + xfree (cert); if (err) goto out; gcry_sexp_release (key_public); diff --git a/agent/command.c b/agent/command.c index 7fc28ad..f72c0a7 100644 --- a/agent/command.c +++ b/agent/command.c @@ -998,7 +998,7 @@ cmd_readkey (assuan_context_t ctx, char *line) if (rc) return rc; /* Return immediately as this is already an Assuan error code.*/ - rc = agent_public_key_from_file (ctrl, grip, &s_pkey); + rc = agent_public_key_from_file (ctrl, grip, &s_pkey, NULL); if (!rc) { size_t len; diff --git a/agent/findkey.c b/agent/findkey.c index c5ab0e9..d3c7e3f 100644 --- a/agent/findkey.c +++ b/agent/findkey.c @@ -634,9 +634,13 @@ unprotect (ctrl_t ctrl, const char *cache_nonce, const char *desc_text, /* Read the key identified by GRIP from the private key directory and return it as an gcrypt S-expression object in RESULT. On failure - returns an error code and stores NULL at RESULT. */ + returns an error code and stores NULL at RESULT. If R_SSH_CERT is + not NULL and certificate information is available in the Extended + Private Key Format, certificate encoded in base64 is stored there. +*/ static gpg_error_t -read_key_file (const unsigned char *grip, gcry_sexp_t *result) +read_key_file (const unsigned char *grip, gcry_sexp_t *result, + char **r_ssh_cert) { int rc; char *fname; @@ -699,10 +703,22 @@ read_key_file (const unsigned char *grip, gcry_sexp_t *result) else { rc = nvc_get_private_key (pk, result); - nvc_release (pk); if (rc) log_error ("error getting private key from '%s': %s\n", fname, gpg_strerror (rc)); + else + { + nve_t e = nvc_lookup (pk, "OpenSSH-cert:"); + if (e) + { + char *cert_str; + + cert_str = nve_value (e); + if (cert_str && r_ssh_cert) + *r_ssh_cert = xtrystrdup (cert_str); + } + } + nvc_release (pk); } xfree (fname); @@ -811,7 +827,7 @@ agent_key_from_file (ctrl_t ctrl, const char *cache_nonce, if (r_passphrase) *r_passphrase = NULL; - rc = read_key_file (grip, &s_skey); + rc = read_key_file (grip, &s_skey, NULL); if (rc) { if (gpg_err_code (rc) == GPG_ERR_ENOENT) @@ -1141,7 +1157,7 @@ agent_raw_key_from_file (ctrl_t ctrl, const unsigned char *grip, *result = NULL; - err = read_key_file (grip, &s_skey); + err = read_key_file (grip, &s_skey, NULL); if (!err) *result = s_skey; return err; @@ -1151,11 +1167,14 @@ agent_raw_key_from_file (ctrl_t ctrl, const unsigned char *grip, /* Return the public key for the keygrip GRIP. The result is stored at RESULT. This function extracts the public key from the private key database. On failure an error code is returned and NULL stored - at RESULT. */ + at RESULT. When OpenSSH cert information is available and + R_SSH_CERT is not NULL, base64 encoded string is stored there. The + caller needs to free the returned certificate in base64. +*/ gpg_error_t agent_public_key_from_file (ctrl_t ctrl, const unsigned char *grip, - gcry_sexp_t *result) + gcry_sexp_t *result, char **r_ssh_cert) { gpg_error_t err; int i, idx; @@ -1178,8 +1197,10 @@ agent_public_key_from_file (ctrl_t ctrl, (void)ctrl; *result = NULL; + if (r_ssh_cert) + *r_ssh_cert = NULL; - err = read_key_file (grip, &s_skey); + err = read_key_file (grip, &s_skey, r_ssh_cert); if (err) return err; @@ -1190,6 +1211,11 @@ agent_public_key_from_file (ctrl_t ctrl, array, DIM (array), &curve, &flags); if (err) { + if (r_ssh_cert) + { + xfree (*r_ssh_cert); + *r_ssh_cert = NULL; + } gcry_sexp_release (s_skey); return err; } @@ -1221,6 +1247,11 @@ agent_public_key_from_file (ctrl_t ctrl, format = xtrymalloc (15+4+7*npkey+10+15+1+1); if (!format) { + if (r_ssh_cert) + { + xfree (*r_ssh_cert); + *r_ssh_cert = NULL; + } err = gpg_error_from_syserror (); for (i=0; array[i]; i++) gcry_mpi_release (array[i]); @@ -1275,6 +1306,14 @@ agent_public_key_from_file (ctrl_t ctrl, if (!err) *result = list; + else + { + if (r_ssh_cert) + { + xfree (*r_ssh_cert); + *r_ssh_cert = NULL; + } + } return err; } @@ -1324,7 +1363,7 @@ agent_key_info_from_file (ctrl_t ctrl, const unsigned char *grip, { gcry_sexp_t sexp; - err = read_key_file (grip, &sexp); + err = read_key_file (grip, &sexp, NULL); if (err) { if (gpg_err_code (err) == GPG_ERR_ENOENT) @@ -1405,7 +1444,7 @@ agent_delete_key (ctrl_t ctrl, const char *desc_text, char hexgrip[40+4+1]; char *default_desc = NULL; - err = read_key_file (grip, &s_skey); + err = read_key_file (grip, &s_skey, NULL); if (gpg_err_code (err) == GPG_ERR_ENOENT) err = gpg_error (GPG_ERR_NO_SECKEY); if (err) diff --git a/agent/pksign.c b/agent/pksign.c index 9011be2..2b16a30 100644 --- a/agent/pksign.c +++ b/agent/pksign.c @@ -332,7 +332,7 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, int is_ECDSA = 0; int is_EdDSA = 0; - rc = agent_public_key_from_file (ctrl, ctrl->keygrip, &s_pkey); + rc = agent_public_key_from_file (ctrl, ctrl->keygrip, &s_pkey, NULL); if (rc) { log_error ("failed to read the public key\n"); -- From justus at g10code.com Wed Aug 10 08:45:49 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 10 Aug 2016 08:45:49 +0200 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <1470793057-12340-1-git-send-email-dkg@fifthhorseman.net> References: <8760rd25ye.fsf@alice.fifthhorseman.net> <1470793057-12340-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87r39x15r6.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > * dirmngr/dirmngr.c (main): add new --supervised command, which is > a mode designed for running under a process supervision system > like systemd or runit. > * doc/dirmngr.text: document --supervised and its interaction with s/text/texi/ > --log-file Commit log style nitpick: We like to start with a capital letter after the colon, and end with a full stop. Likewise for the patch subject. I agree with this change. If I were to implement starting gpg-agent on demand on the Hurd using translator records (think generalized decentral socket activation from the nineties, everything old is new again), I'd also need such an interface. > * dirmngr/systemd-user/{README,dirmngr.{socket,service}}: new. System > integration notes and configuration for socket-activated dirmngr on > machines that run systemd I guess it makes sense to ship these as well. You need to add them to EXTRA_DIST, or they won't be included in releases. Having said that, I believe none of us runs systemd, so we will have to rely on contributors to keep these up-to-date. That likely means you ;) > "dirmngr --supervised" is a way to invoke dirmngr such that a system > supervisor like systemd can provide socket-activated startup, log > management, and scheduled shutdown. > > When running in this mode, dirmngr: > > * does not open its own listening socket; rather, it expects to be > given a listening socket on file descriptor 3 Is that file descriptor fixed? I remember systemd storing it in some environment variable. ~~~ Do we have a policy how we deal with systemd? I just noticed yesterday, on Debian sid, procps=2:3.3.12-2: # ldd /bin/ps linux-vdso.so.1 (0x00007fffe57f1000) libprocps.so.6 => /lib/x86_64-linux-gnu/libprocps.so.6 (0x00007fdf59d69000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdf59b65000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdf597c3000) libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fdf5973b000) /lib64/ld-linux-x86-64.so.2 (0x000055fed7763000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fdf59514000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdf5930b000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fdf590e8000) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fdf58dd9000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdf58bbb000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fdf58949000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fdf58734000) Wow, gpg-error and gcrypt crept into /bin/ps, likely courtesy of libsystemd. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From justus at g10code.com Wed Aug 10 14:36:55 2016 From: justus at g10code.com (Justus Winter) Date: Wed, 10 Aug 2016 14:36:55 +0200 Subject: [PATCH] tools/gpgconf.c (main): Initialize libgcrypt. In-Reply-To: <1470785342-7832792.54094846.fu79NStRT021298@rs146.luxsci.com> References: <1470504482-9367085.26936188.fu76HRcRG012022@rs146.luxsci.com> <87shufaa4d.fsf@europa.jade-hamburg.de> <1470696008-6356719.77400402.fu78Me4Ws030991@rs146.luxsci.com> <87ziomfhc2.fsf@europa.jade-hamburg.de> <1470785342-7832792.54094846.fu79NStRT021298@rs146.luxsci.com> Message-ID: <87oa50242g.fsf@europa.jade-hamburg.de> Ben Kibbey writes: > On Tue, Aug 09, 2016 at 10:59:41AM +0200, Justus Winter wrote: >> Ben Kibbey writes: >> >> > * common/init.c (init_common_subsystems): Initialize libgcrypt. >> >> Merged, thanks! > > Noticed the mention of header files and GPG_ERR_SOURCE on xmpp so I > revised the original patch to move gcrypt.h after everything else and > also coding style. Should apply after reverting the previous one. Common, don't flip flop on that one. All the programs have an insane amount of initialization boilerplate, and your patch reduces that a tiny bit, by moving some initialization of a common subsystem that happens everywhere to 'init_common_subsystem', which sounds perfectly reasonable imho. Also, xmpp is nice, but the discussion is already lost to history, so let's quickly recap the potential problems, and then have a proper discussion here. I remember three things, 1/ the order of includes may be important, 2/ some magical way that the error source is set that your change may have changed accidentally, 3/ i18n.h being included in common/init.c being a problem, 4/ init_common_subsystems might be running as root. Did I miss anything? 1/ If the order is important, I don't like that, and we should fix that. That sounds like the code is trying to be clever with the preprocessor. 2/ Likewise. It might be convenient, but it sounds too magical to be good. Explicit is better than implicit. 3/ I don't understand that point at all. 4/ Is that actually a problem? I just checked, none of the gnupg components on my Debian/Linux system are suid root, so that could only be the case if one runs gnupg as root, and I don't see why we should/how we could protect the user in this case, or it is not run as root in the first place, and then this point is moot. I believe that the change we merged looks very reasonable (hence I merged it), and such a change should not be able to have subtle side-effects like the ones Werner fears. If there are weird implicit side-effects, I believe we should make sure that such side-effects cannot happen instead of reverting that change. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Aug 10 17:11:42 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 10 Aug 2016 11:11:42 -0400 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <87r39x15r6.fsf@europa.jade-hamburg.de> References: <8760rd25ye.fsf@alice.fifthhorseman.net> <1470793057-12340-1-git-send-email-dkg@fifthhorseman.net> <87r39x15r6.fsf@europa.jade-hamburg.de> Message-ID: <87zioku09d.fsf@alice.fifthhorseman.net> Hi Justus-- Thanks for the feedback! On Wed 2016-08-10 02:45:49 -0400, Justus Winter wrote: > Commit log style nitpick: We like to start with a capital letter after > the colon, and end with a full stop. Likewise for the patch subject. gotcha. a revised patch is on its way. > I agree with this change. If I were to implement starting gpg-agent on > demand on the Hurd using translator records (think generalized decentral > socket activation from the nineties, everything old is new again), I'd > also need such an interface. cool, i'm glad it's also useful for this use case. The work for gpg-agent is slightly more complicated because gpg-agent listens on multiple sockets and does different things with different sockets, but i'm on it. fwiw, for a socket-activated, supervised gpg-agent, i'm planning to use the $LISTEN_FDS variable to store a count of file descriptors to listen on, and to distinguish socket types based on text labels passed in colon-delimited form in $LISTEN_FDNAMES. The simplest use case would be: LISTEN_FDS=1 LISTEN_FDNAMES= That's an agent listening only on file descriptor 3, speaking the normal gpg-agent protocol. In the most complex example: LISTEN_FDS=4 LISTEN_FDNAMES=:ssh:extra:browser would mean that the open file descriptors would be treated as: 3 -- normal gpg-agent socket 4 -- socket for ssh-agent emulation 5 -- "--extra-socket" restricted socket 6 -- "--browser-socket" experimental restricted socket See sd_listen_fds(3) for a description of this convention (though don't worry, i don't plan on linking gpg-agent to libsystemd()). I'm also going to propose a new feature for the runit suite (http://smarden.org/runit) that should make it easy to supervise other processes that use this convention on systems using that supervision system. > I guess it makes sense to ship these as well. You need to add them to > EXTRA_DIST, or they won't be included in releases. right, i'll include that in the revision. > Having said that, I believe none of us runs systemd, so we will have to > rely on contributors to keep these up-to-date. That likely means you ;) That's fine with me. I welcome other contributors' suggestions as well. After a bit more experimentation and research yesterday, i've tweaked these files a bit more, and i'm including them >> "dirmngr --supervised" is a way to invoke dirmngr such that a system >> supervisor like systemd can provide socket-activated startup, log >> management, and scheduled shutdown. >> >> When running in this mode, dirmngr: >> >> * does not open its own listening socket; rather, it expects to be >> given a listening socket on file descriptor 3 > > Is that file descriptor fixed? I remember systemd storing it in some > environment variable. It's fixed in a header file that's exposed to any process that builds against libsystemd: 0 dkg at alice:~$ grep -B1 '^#define SD_LISTEN_FDS_START' /usr/include/systemd/sd-daemon.h /* The first passed file descriptor is fd 3 */ #define SD_LISTEN_FDS_START 3 0 dkg at alice:~$ So this is something that cannot actually change without a rebuild of everything that links to libsystemd. I think it's safe to treat it as fixed for purposes of systemd. If you need it to be variable for dirmngr for Hurd or elsewhere, i'm fine with adding an option or an envvar to set it explicitly, but i hope you'll be OK with the default for that option being 3 ;) Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Aug 10 17:16:04 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 10 Aug 2016 11:16:04 -0400 Subject: [PATCH v2] dirmngr: Implement --supervised command (for systemd, etc). In-Reply-To: <87zioku09d.fsf@alice.fifthhorseman.net> References: <87zioku09d.fsf@alice.fifthhorseman.net> Message-ID: <1470842164-6499-1-git-send-email-dkg@fifthhorseman.net> * dirmngr/dirmngr.c (main): Add new --supervised command, which is a mode designed for running under a process supervision system like systemd or runit. * doc/dirmngr.texi: document --supervised and its interaction with --log-file. * dirmngr/systemd-user/{README,dirmngr.{socket,service}}: New. System integration notes and configuration for socket-activated dirmngr on machines that run systemd. * dirmngr/Makefile.am: Add systemd-user/ directory to EXTRA_DIST. -- "dirmngr --supervised" is a way to invoke dirmngr such that a system supervisor like systemd can provide socket-activated startup, log management, and scheduled shutdown. When running in this mode, dirmngr: * Does not open its own listening socket; rather, it expects to be given a listening socket on file descriptor 3. * Does not open or manage any logfile; instead, it logs to stdout and/or stderr. * Does not detach from the invoking process, staying in the foreground instead. The dirmngr/systemd-user directory contains a brief README and some configuration files that enable socket-activated and cleanly-terminated dirmngr system integration on machines that run systemd. Signed-off-by: Daniel Kahn Gillmor --- dirmngr/Makefile.am | 4 +++- dirmngr/dirmngr.c | 26 +++++++++++++++++++++++ dirmngr/systemd-user/README | 40 ++++++++++++++++++++++++++++++++++++ dirmngr/systemd-user/dirmngr.service | 10 +++++++++ dirmngr/systemd-user/dirmngr.socket | 10 +++++++++ doc/dirmngr.texi | 11 +++++++++- 6 files changed, 99 insertions(+), 2 deletions(-) create mode 100644 dirmngr/systemd-user/README create mode 100644 dirmngr/systemd-user/dirmngr.service create mode 100644 dirmngr/systemd-user/dirmngr.socket diff --git a/dirmngr/Makefile.am b/dirmngr/Makefile.am index 64bc058..15ca7b6 100644 --- a/dirmngr/Makefile.am +++ b/dirmngr/Makefile.am @@ -19,7 +19,9 @@ ## Process this file with automake to produce Makefile.in -EXTRA_DIST = OAUTHORS ONEWS ChangeLog-2011 tls-ca.pem +EXTRA_DIST = OAUTHORS ONEWS ChangeLog-2011 tls-ca.pem \ + systemd-user/README systemd-user/dirmngr.socket \ + systemd-user/dirmngr.service dist_pkgdata_DATA = sks-keyservers.netCA.pem bin_PROGRAMS = dirmngr dirmngr-client diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c index 007fa10..b57cd1e 100644 --- a/dirmngr/dirmngr.c +++ b/dirmngr/dirmngr.c @@ -94,6 +94,7 @@ enum cmd_and_opt_values { aServer, aDaemon, + aSupervised, aService, aListCRLs, aLoadCRL, @@ -155,6 +156,7 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_c (aServer, "server", N_("run in server mode (foreground)") ), ARGPARSE_c (aDaemon, "daemon", N_("run in daemon mode (background)") ), + ARGPARSE_c (aSupervised, "supervised", N_("run under supervision (e.g. systemd)")), #ifdef USE_W32_SERVICE ARGPARSE_c (aService, "service", N_("run as windows service (background)")), #endif @@ -911,6 +913,7 @@ main (int argc, char **argv) { case aServer: case aDaemon: + case aSupervised: case aService: case aShutdown: case aFlush: @@ -1093,6 +1096,29 @@ main (int argc, char **argv) start_command_handler (ASSUAN_INVALID_FD); shutdown_reaper (); } + else if (cmd == aSupervised) + { + /* In supervised mode, we expect file descriptor 3 to be an + already opened, listening socket. + + We will also not detach from the controlling process or close + stderr, and we do not open any logfile; the supervisor should + handle all of that. + + FIXME: should we try to extract the actual socket_name + from the file descriptor with getsockname(2) so that we + can return it in response to "GETINFO socket_name"? This + isn't currently done when --socket-name is supplied. + */ +#if USE_LDAP + ldap_wrapper_launch_thread (); +#endif /*USE_LDAP*/ + cert_cache_init (); + crl_cache_init (); + handle_connections (3); + assuan_sock_close (3); + shutdown_reaper (); + } else if (cmd == aDaemon) { assuan_fd_t fd; diff --git a/dirmngr/systemd-user/README b/dirmngr/systemd-user/README new file mode 100644 index 0000000..938740e --- /dev/null +++ b/dirmngr/systemd-user/README @@ -0,0 +1,40 @@ +Socket-activated dirmngr with systemd +===================================== + +When used on a GNU/Linux system supervised by systemd, you can ensure +that dirmngr is launched automatically the first time it's needed, and +shut down cleanly at session logout by enabling the dirmngr user +service via socket-activation. + +System distributors +------------------- + +The dirmngr.service and dirmngr.socket (from this directory) should be +placed in /usr/lib/systemd/user/ alongside other user-session services +and sockets. + +To enable socket-activated dirmngr for all accounts on the system, +use: + + systemctl --user --global enable dirmngr.socket + + +Individual users +---------------- + +A user on a system with systemd where this has not been installed +system-wide can place these files in ~/.config/systemd/user/ to make +them available. + +If it isn't installed system-wide, or it's installed system-wide but +not globally enabled hasn't been done, individual users will still +need to enable it: + +Users who want to enable socket-activated dirmngr for all future +sessions can do so with: + + systemctl --user enable dirmngr.socket + +To set up socket-activated dirmngr for the current session, use: + + systemctl --user start dirmngr.socket diff --git a/dirmngr/systemd-user/dirmngr.service b/dirmngr/systemd-user/dirmngr.service new file mode 100644 index 0000000..8c4c496 --- /dev/null +++ b/dirmngr/systemd-user/dirmngr.service @@ -0,0 +1,10 @@ +[Unit] +Description=GnuPG network certificate management daemon +Documentation=man:dirmngr(8) + +[Service] +ExecStart=/usr/bin/dirmngr --supervised + +[Install] +Also=dirmngr.socket +WantedBy=default.target diff --git a/dirmngr/systemd-user/dirmngr.socket b/dirmngr/systemd-user/dirmngr.socket new file mode 100644 index 0000000..6621cf6 --- /dev/null +++ b/dirmngr/systemd-user/dirmngr.socket @@ -0,0 +1,10 @@ +[Unit] +Description=dirmngr listening socket +Documentation=man:dirmngr(8) + +[Socket] +ListenStream=/run/user/%U/gnupg/S.dirmngr +SocketMode=0600 + +[Install] +WantedBy=sockets.target diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index 033b5d3..3b64b19 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -90,6 +90,13 @@ Run in background daemon mode and listen for commands on a socket. Note that this also changes the default home directory and enables the internal certificate validation code. This mode is deprecated. + at item --supervised + at opindex supervised +Run in the foreground, sending logs to stderr, and listening on file +descriptor 3, which must already be bound to a listening socket. This +is useful when running under systemd or other similar process +supervision schemes. + @item --list-crls @opindex list-crls List the contents of the CRL cache on @code{stdout}. This is probably @@ -168,7 +175,9 @@ verbose commands to @sc{dirmngr}, such as @option{-vv}. @item --log-file @var{file} @opindex log-file Append all logging output to @var{file}. This is very helpful in -seeing what the agent actually does. +seeing what the agent actually does. This has no effect in + at code{--supervised} mode, as the process supervisor is expected to +handle all logging (e.g., @code{journalctl --user -u dirmngr}). @item --debug-level @var{level} @opindex debug-level -- 2.8.1 From ben at adversary.org Thu Aug 11 00:47:45 2016 From: ben at adversary.org (Ben McGinnes) Date: Thu, 11 Aug 2016 08:47:45 +1000 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <20160808082116.GN28435@zeromail.org> References: <1470344293-32193-1-git-send-email-dkg@fifthhorseman.net> <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <8737mj2e0w.fsf@alice.fifthhorseman.net> <20160806140604.GG16190@zeromail.org> <20160807152918.GB1930@adversary.org> <20160808082116.GN28435@zeromail.org> Message-ID: <20160810224745.GB20128@adversary.org> On Mon, Aug 08, 2016 at 10:21:16AM +0200, ilf wrote: > Ben McGinnes: > > but also because the current full fingerprint output format (the default > > in 2.1) does not include any fingerprint or key ID data to identify > > subkeys. > > This can be achieved by using "--fingerprint" twice. Ah, of course, I forgot about that (most of the keys I have signed in the last few years are either done from the master/cert fpr or I was present when the key was generated). That being the case, though, why such concern for removing long or short? The same thing already provides what you want, except for the spaces and the likelihood of breaking third party code. > You can also add "fingerprint" twice into gpg.conf. I'll probably add another script (just a shell wrapper which saves typing) which automatically includes both of them for when they're needed, it's easier than maintaining multiple gpg.conf files when that thing also has a large chunk of group lines in place. When things are a little less busy I'll probably even do something which allows both space filled and without to print to the shell, but that really can wait (probably quite a long time). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From wk at gnupg.org Thu Aug 11 13:03:55 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Aug 2016 13:03:55 +0200 Subject: [PATCH] tools/gpgconf.c (main): Initialize libgcrypt. In-Reply-To: <87oa50242g.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Wed, 10 Aug 2016 14:36:55 +0200") References: <1470504482-9367085.26936188.fu76HRcRG012022@rs146.luxsci.com> <87shufaa4d.fsf@europa.jade-hamburg.de> <1470696008-6356719.77400402.fu78Me4Ws030991@rs146.luxsci.com> <87ziomfhc2.fsf@europa.jade-hamburg.de> <1470785342-7832792.54094846.fu79NStRT021298@rs146.luxsci.com> <87oa50242g.fsf@europa.jade-hamburg.de> Message-ID: <877fbnin38.fsf@wheatstone.g10code.de> On Wed, 10 Aug 2016 14:36, justus at g10code.com said: > 1/ If the order is important, I don't like that, and we should fix > that. That sounds like the code is trying to be clever with the > preprocessor. config.h must always be the first header becuase it controls features provided by the system headers. The latter SHOULD prepend application specific headers to ease debugging. [ some magical way that the error source is set that your change ..] > 2/ Likewise. It might be convenient, but it sounds too magical to be > good. Explicit is better than implicit. The tricky part is the GPG_ERR_SOURCE which has a default unless set in another way. In general not a problem but sometimes things get messed up. [i18n.h being included in common/init.c] > 3/ I don't understand that point at all. Pretty easy: This requires linking to libintl even for tools which have no need for it. > 4/ Is that actually a problem? I just checked, none of the gnupg > components on my Debian/Linux system are suid root, so that could only On Linux this is not a problem as long as the amount of mlocked memory is small enough. On other OSes you may want to suid the application to take advantage of mlocked memory. > I believe that the change we merged looks very reasonable (hence I > merged it), and such a change should not be able to have subtle > side-effects like the ones Werner fears. If there are weird implicit The gcry_check_version is important and chould be done explicit. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From ilf at zeromail.org Thu Aug 11 13:08:34 2016 From: ilf at zeromail.org (ilf) Date: Thu, 11 Aug 2016 13:08:34 +0200 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <20160810224745.GB20128@adversary.org> References: <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <8737mj2e0w.fsf@alice.fifthhorseman.net> <20160806140604.GG16190@zeromail.org> <20160807152918.GB1930@adversary.org> <20160808082116.GN28435@zeromail.org> <20160810224745.GB20128@adversary.org> Message-ID: <20160811110834.GJ3453@zeromail.org> Ben McGinnes: > That being the case, though, why such concern for removing long or > short? The same thing already provides what you want, except for the > spaces and the likelihood of breaking third party code. No user should be exposed to key-id short or long, only fingerprints. This is the case in default 2.1.14. But to transition away from the long-time default key-id short, we've been telling people to use "key-id long" and "fingerprint", see https://riseup.net/en/security/message-security/openpgp/best-practices#dont-rely-on-the-key-id For 1.4, 2.0 and <2.1.14, this is still the way to go. But with 2.1.14, this changes and no "key-id" and no "fingerprint" is best. That's default, good. But that doesn't change existing configs. So my proposal is to always add the fingerprint in the line after key-id, regardless of that being none, short or long. -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From justus at g10code.com Thu Aug 11 13:48:26 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 11 Aug 2016 13:48:26 +0200 Subject: [PATCH] tools/gpgconf.c (main): Initialize libgcrypt. In-Reply-To: <877fbnin38.fsf@wheatstone.g10code.de> References: <1470504482-9367085.26936188.fu76HRcRG012022@rs146.luxsci.com> <87shufaa4d.fsf@europa.jade-hamburg.de> <1470696008-6356719.77400402.fu78Me4Ws030991@rs146.luxsci.com> <87ziomfhc2.fsf@europa.jade-hamburg.de> <1470785342-7832792.54094846.fu79NStRT021298@rs146.luxsci.com> <87oa50242g.fsf@europa.jade-hamburg.de> <877fbnin38.fsf@wheatstone.g10code.de> Message-ID: <87mvkj5xx1.fsf@europa.jade-hamburg.de> Werner Koch writes: > On Wed, 10 Aug 2016 14:36, justus at g10code.com said: > >> 1/ If the order is important, I don't like that, and we should fix >> that. That sounds like the code is trying to be clever with the >> preprocessor. > > config.h must always be the first header becuase it controls features Sure, but other than that. > provided by the system headers. The latter SHOULD prepend application > specific headers to ease debugging. > > [ some magical way that the error source is set that your change ..] >> 2/ Likewise. It might be convenient, but it sounds too magical to be >> good. Explicit is better than implicit. > > The tricky part is the GPG_ERR_SOURCE which has a default unless set in > another way. In general not a problem but sometimes things get messed > up. And did the commit in question change that? (I still don't like it.) > [i18n.h being included in common/init.c] >> 3/ I don't understand that point at all. > > Pretty easy: This requires linking to libintl even for tools which have > no need for it. If we want to avoid that, then we could simply avoid translating the error message. >> 4/ Is that actually a problem? I just checked, none of the gnupg >> components on my Debian/Linux system are suid root, so that could only > > On Linux this is not a problem as long as the amount of mlocked memory > is small enough. On other OSes you may want to suid the application to > take advantage of mlocked memory. Right, other Unices. However, is that really still a problem? We even allow unpriviliged users to use small amounts of wired memory on Mach these days. >> I believe that the change we merged looks very reasonable (hence I >> merged it), and such a change should not be able to have subtle >> side-effects like the ones Werner fears. If there are weird implicit > > The gcry_check_version is important and chould be done explicit. And we didn't remove that, we just moved it. On the other hand, if we were to revert this change, then the following programs are using init_common_subsystems without properly initializing gcrypt: agent/preset-passphrase.c common/t-recsel.c dirmngr/dirmngr_ldap.c tools/gpg-connect-agent.c tools/gpg-wks-client.c tools/gpg-wks-server.c tools/gpgconf.c tools/gpgtar.c This actually strengthens my point. The initialization is so complex, that even you got it wrong, and noone knows the code as well as you. We need to make this simpler. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From justus at g10code.com Thu Aug 11 15:21:44 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 11 Aug 2016 15:21:44 +0200 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <87zioku09d.fsf@alice.fifthhorseman.net> References: <8760rd25ye.fsf@alice.fifthhorseman.net> <1470793057-12340-1-git-send-email-dkg@fifthhorseman.net> <87r39x15r6.fsf@europa.jade-hamburg.de> <87zioku09d.fsf@alice.fifthhorseman.net> Message-ID: <87k2fn5tlj.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > On Wed 2016-08-10 02:45:49 -0400, Justus Winter wrote: >> I agree with this change. If I were to implement starting gpg-agent on >> demand on the Hurd using translator records (think generalized decentral >> socket activation from the nineties, everything old is new again), I'd >> also need such an interface. > > cool, i'm glad it's also useful for this use case. I'm not gonna do that of course, I was merely trying to foster your proposal. Having said that, there are concerns with this kind of feature. First of all, this must not change where the log messages go. What good is it if they are collected by systemd but are missing in the gnupg log? Then, how are we going to tell from bug reports that a user is using some service manager, as opposed to letting gnupg handle its background servers by itself? Worse, if users are having trouble with this, how are we going to debug it, given that we do not use e.g. systemd ourself? Furthermore, it is not clear what benefits users will have if systemd manages our services. And please don't say that the benefit is that things are continue to work despite the fact that systemd starts to randomly kill services that are neither managed by it nor are communicating their with to live via some dbus interface. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From wk at gnupg.org Thu Aug 11 18:42:46 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Aug 2016 18:42:46 +0200 Subject: Fingerprints and Key-IDs - Was: [PATCH] avoid publishing the GnuPG version by default In-Reply-To: <20160811110834.GJ3453@zeromail.org> (ilf@zeromail.org's message of "Thu, 11 Aug 2016 13:08:34 +0200") References: <147036309446.28989.15300563108391407497@solidarity.enteig.net> <87oa576e4p.fsf@alice.fifthhorseman.net> <20160805124310.GM19126@zeromail.org> <87eg639x6t.fsf@wheatstone.g10code.de> <20160805193947.GB16190@zeromail.org> <8737mj2e0w.fsf@alice.fifthhorseman.net> <20160806140604.GG16190@zeromail.org> <20160807152918.GB1930@adversary.org> <20160808082116.GN28435@zeromail.org> <20160810224745.GB20128@adversary.org> <20160811110834.GJ3453@zeromail.org> Message-ID: <87k2fngsu1.fsf@wheatstone.g10code.de> On Thu, 11 Aug 2016 13:08, ilf at zeromail.org said: > So my proposal is to always add the fingerprint in the line after > key-id, regardless of that being none, short or long. No. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From kristian.fiskerstrand at sumptuouscapital.com Thu Aug 11 19:13:39 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 11 Aug 2016 19:13:39 +0200 Subject: [PATCH] pinentry:: Qt: Append -std=c++11 if building against Qt 5.7 Message-ID: Hi, * m4/qt.m4: Append -std=c++11 to CFLAGS if building against Qt 5.7 -- Qt 5.7 enables C++11 for Qt modules, and any app relying on it require to be compiled with at least this standard. This patch adds detection for Qt 5.7 and make sure -std=c++11 is passed if building against Qt 5.7 or higher. ## ( http://wiki.qt.io/New_Features_in_Qt_5.7 ) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Primum ego, tum ego, deinde ego First I, then I, thereafter I. -------------- next part -------------- From 7384e2a575dde2809784d9f182fd1d247064c8a2 Mon Sep 17 00:00:00 2001 From: Kristian Fiskerstrand Date: Thu, 11 Aug 2016 14:44:37 +0200 Subject: [PATCH] Qt: Append -std=c++11 if building against Qt 5.7 * m4/qt.m4: Append -std=c++11 to CFLAGS if building against Qt 5.7 -- Qt 5.7 enables C++11 for Qt modules, and any app relying on it require to be compiled with at least this standard. This patch adds detection for Qt 5.7 and make sure -std=c++11 is passed if building against Qt 5.7 or higher. --- m4/qt.m4 | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/m4/qt.m4 b/m4/qt.m4 index 093f428..90c4a6e 100644 --- a/m4/qt.m4 +++ b/m4/qt.m4 @@ -35,6 +35,7 @@ AC_DEFUN([FIND_QT], enable_pinentry_qt5="try") have_qt5_libs="no"; + require_qt_cpp11="no"; if test "$enable_pinentry_qt5" != "no"; then PKG_CHECK_MODULES(PINENTRY_QT, @@ -47,6 +48,15 @@ AC_DEFUN([FIND_QT], fi fi if test "$have_qt5_libs" = "yes"; then + PKG_CHECK_MODULES(PINENTRY_QT_REQUIRE_CPP11, + Qt5Core >= 5.7.0, + [require_qt_cpp11="yes"], + [require_qt_cpp11="no"]) + + if test "${require_qt_cpp11}" = "yes"; then + PINENTRY_QT_CFLAGS="$PINENTRY_QT_CFLAGS -std=c++11" + fi + AC_CHECK_TOOL(MOC, moc) AC_MSG_CHECKING([moc version]) mocversion=`$MOC -v 2>&1` -- 2.7.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Aug 11 22:47:35 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 11 Aug 2016 16:47:35 -0400 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <87k2fn5tlj.fsf@europa.jade-hamburg.de> References: <8760rd25ye.fsf@alice.fifthhorseman.net> <1470793057-12340-1-git-send-email-dkg@fifthhorseman.net> <87r39x15r6.fsf@europa.jade-hamburg.de> <87zioku09d.fsf@alice.fifthhorseman.net> <87k2fn5tlj.fsf@europa.jade-hamburg.de> Message-ID: <87vaz7rq1k.fsf@alice.fifthhorseman.net> Hi Justus-- Thanks for the additional thoughts! On Thu 2016-08-11 09:21:44 -0400, Justus Winter wrote: > Having said that, there are concerns with this kind of feature. First > of all, this must not change where the log messages go. What good is it > if they are collected by systemd but are missing in the gnupg log? Well, there is no general "gnupg log" that i'm aware of -- but i'm fine with re-enabling the log-file directive in --supervised mode if you prefer it that way. > Then, how are we going to tell from bug reports that a user is using > some service manager, as opposed to letting gnupg handle its background > servers by itself? i don't think gpg itself can tell the difference one way or another -- if the service is listening on the expected port, gpg will use it. We had this issue already in some sense with gnome-keyring "hijacking" gpg-agent (and, arguably, ssh has this issue with gpg-agent "hijacking" ssh-agent). But in the system supervision case it's actually still the same gpg-agent that's running, not an imposter. it's just be started up automatically without exercising any of the auto-spawning code. > Worse, if users are having trouble with this, how are we going to debug > it, given that we do not use e.g. systemd ourself? i don't know which "we" you mean, but as a community, we support GnuPG users on GNU/Linux, Windows, Mac OS, AIX, FreeBSD, VMS, Solaris, etc. Surely we don't all run all of those. I understand the wariness of adding a new mode to support, but systemd is hardly a niche system management suite, and the changes here are not particularly large. There is considerably more code in dirmngr that is only for the purposes of supporting one specific OS (Windows) than there is in the patchset i've proposed. > Furthermore, it is not clear what benefits users will have if systemd > manages our services. Hm, I thought i'd made this clear, but i'll try to set it out more formally. The goal here is to have a single daemon that runs for a given user for the duration of the time they're logged into a computer. It's possible that there are multiple concurrent logins for a given user -- for example, two different ssh sessions, or a graphical login and a text-mode login concurrently on the same machine. There are a few desiderata for any daemon that we're trying to handle in this way: 0) do not start the daemon unless something the user does actively needs it. 1) do not run multiple instances of the daemon for any given user. 2) cleanly and promptly terminate the daemon when the user has no more running sessions on the machine. Recent versions of gnupg support desiderata 0 and 1 fairly well out of the box, but i've seen no concrete proposals for how to deal with 2, and some legitimate complaints about it (see an earlier Subject: in this thread, which came from debian developer Ian Jackson: "Beware of leftover gpg-agent processes"). Even without --supervised mode, we can solve 1 and 2 on systemd and other session-tracking system service managers by manually starting a service for each daemon; this lets us safely clean up the daemon at session termination (because we started it, and we can track and safely tear down itself and any children it might spawn). But we don't solve desideratum 0 in this case, because the daemons are running even when you don't want them. We can solve 0, 1, and 2 together on systems that use systemd by using socket activation, as proposed here. An additional gain (which you may not care about as a non-user of systemd) is that there are other per-user or per-session daemons that are managed in the same way; being able to address each of the daemons in the same way, to inspect their status, to restart them, etc, is a feature for people who don't necessarily have the time to learn idiosyncrasies of each of the daemons that support their computing environment. This kind of system integration allows for the creation of simple quick overview tools of machine state (e.g. "systemctl --user status"), standardized logging (e.g. "journalctl --user -u gpg-agent"), and for standardized ways of constraining or controlling these daemons (e.g. Limit*=, AppArmorProfile=, and other directives in systemd.exec(5)). By integrating with a common management model in a specific operating environment, there's a lot that a program can get "for free" as it piggybacks on other infrastructure. > And please don't say that the benefit is that things are continue to > work despite the fact that systemd starts to randomly kill services > that are neither managed by it nor are communicating their with to > live via some dbus interface. eh? It sounds to me like you're aware of some complaint or bug report i'm unware of. Could you explain more, or point me to a specific example, please? I've been running systemd for quite some time and i've never seen any random killing or any requirements of reporting to a dbus interface. Certainly, you can configure systemd to act as a "watchdog" and have it kill processes that don't report regularly to a dbus interface, (i.e. WatchdogSec= in systemd.service(5)), but i don't see why anyone would ever configure that option for daemons like dirmngr or gpg-agent that don't talk to dbus. I certainly didn't in my example .service file :) Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Aug 12 07:37:59 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Aug 2016 01:37:59 -0400 Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for systemd, etc). In-Reply-To: <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net> * agent/gpg-agent.c (get_socket_path): New function for POSIX systems to return the path for a provided unix-domain socket. (map_supervised_sockets): New function to inspect $LISTEN_FDS and $LISTEN_FDNAMES and map them to the specific functionality offered by the agent. (main) Add --supervised command: when used, listen on already-open file descriptors instead of opening our own. * doc/gpg-agent.texi: Document --supervised option. -- "gpg-agent --supervised" is a way to invoke gpg-agent such that a system supervisor like systemd can provide socket-activated startup, log management, and scheduled shutdown. When running in this mode, gpg-agent: * Does not open its own listening socket; rather, it expects to be given a listening socket on incoming file descriptors. * Does not detach from the invoking process, staying in the foreground instead. Unless otherwise specified, logs are sent to stderr. Signed-off-by: Daniel Kahn Gillmor --- agent/gpg-agent.c | 229 ++++++++++++++++++++++++++++++++++++++++++++++++++++- doc/gpg-agent.texi | 12 +++ 2 files changed, 239 insertions(+), 2 deletions(-) diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index b8a5a3e..adb4a57 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -87,6 +87,7 @@ enum cmd_and_opt_values oLogFile, oServer, oDaemon, + oSupervised, oBatch, oPinentryProgram, @@ -149,6 +150,7 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_s_n (oDaemon, "daemon", N_("run in daemon mode (background)")), ARGPARSE_s_n (oServer, "server", N_("run in server mode (foreground)")), + ARGPARSE_s_n (oSupervised, "supervised", N_("run supervised (e.g., systemd)")), ARGPARSE_s_n (oVerbose, "verbose", N_("verbose")), ARGPARSE_s_n (oQuiet, "quiet", N_("be somewhat more quiet")), ARGPARSE_s_n (oSh, "sh", N_("sh-style command output")), @@ -715,6 +717,179 @@ finalize_rereadable_options (void) } +/* return a malloc'ed string that is the path to the passed unix-domain socket + (or return NULL if this is not a valid unix-domain socket) */ +static char * +get_socket_path (gnupg_fd_t fd) +{ +#ifdef HAVE_W32_SYSTEM + return NULL; +#else + struct sockaddr_un un; + socklen_t len = sizeof(un); + char *ret = NULL; + + if (fd == GNUPG_INVALID_FD) + return NULL; + + if (getsockname (fd, (struct sockaddr*)&un, &len) != 0) + log_error ("could not getsockname(%d) -- error %d (%s)\n", fd, + errno, strerror(errno)); + else if (un.sun_family != AF_UNIX) + log_error ("file descriptor %d is not a unix-domain socket\n", fd); + else if (len <= offsetof (struct sockaddr_un, sun_path)) + log_error ("socket path not present for file descriptor %d\n", fd); + else if (len > sizeof(un)) + log_error ("socket path for file descriptor %d was truncated " + "(passed %lu bytes, wanted %u)\n", fd, sizeof(un), len); + else + { + log_debug ("file descriptor %d has path %s (%lu octets)\n", fd, + un.sun_path, len - offsetof (struct sockaddr_un, sun_path)); + ret = malloc(len - offsetof (struct sockaddr_un, sun_path)); + if (ret == NULL) + log_error ("failed to allocate memory for path to file " + "descriptor %d\n", fd); + else + memcpy (ret, un.sun_path, len); + } + return ret; +#endif /* HAVE_W32_SYSTEM */ +} + + +/* Discover which inherited file descriptors correspond to which + services/sockets offered by gpg-agent, using the LISTEN_FDS and + LISTEN_FDNAMES convention. The understood labels are "ssh", + "extra", and "browser". Any other label will be interpreted as the + standard socket. + + This function is designed to log errors when the expected file + descriptors don't make sense, but to do its best to continue to + work even in the face of minor misconfigurations. + + For more information on the LISTEN_FDS convention, see + sd_listen_fds(3). + */ +static void +map_supervised_sockets (gnupg_fd_t *fd, + gnupg_fd_t *fd_extra, + gnupg_fd_t *fd_browser, + gnupg_fd_t *fd_ssh) +{ + const char *listen_pid = NULL; + const char *listen_fds = NULL; + const char *listen_fdnames = NULL; + int listen_fd_count = -1; + int listen_fdnames_colons = 0; + const char *fdnamep = NULL; + + listen_pid = getenv ("LISTEN_PID"); + listen_fds = getenv ("LISTEN_FDS"); + listen_fdnames = getenv ("LISTEN_FDNAMES"); + + if (!listen_pid) + log_error ("no $LISTEN_PID environment variable found in " + "--supervised mode (ignoring).\n"); + else if (atoi (listen_pid) != getpid ()) + log_error ("$LISTEN_PID (%d) does not match process ID (%d) " + "in --supervised mode (ignoring).\n", + atoi (listen_pid), getpid ()); + else + log_debug ("$LISTEN_PID matches process ID (%d)\n", + getpid()); + + if (listen_fdnames) + for (fdnamep = listen_fdnames; *fdnamep; fdnamep++) + if (*fdnamep == ':') + listen_fdnames_colons++; + log_debug ("%d colon(s) in $LISTEN_FDNAMES: (%s)\n", listen_fdnames_colons, listen_fdnames); + + if (!listen_fds) + { + if (!listen_fdnames) + { + log_error ("no LISTEN_FDS or LISTEN_FDNAMES environment variables " + "found in --supervised mode (assuming 1 active descriptor).\n"); + listen_fd_count = 1; + } + else + { + log_error ("no LISTEN_FDS environment variable found in --supervised " + " mode (relying on colons in LISTEN_FDNAMES instead)\n"); + listen_fd_count = listen_fdnames_colons + 1; + } + } + else + listen_fd_count = atoi (listen_fds); + + if (listen_fd_count < 1) + { + log_error ("--supervised mode expects at least one file descriptor (was told %d) " + "(carrying on as though it were 1)\n", listen_fd_count); + listen_fd_count = 1; + } + + if (!listen_fdnames) + { + if (listen_fd_count != 1) + log_error ("no LISTEN_FDNAMES and LISTEN_FDS (%d) != 1 in --supervised mode. " + "(ignoring all sockets but the first one)\n", listen_fd_count); + *fd = 3; + } + else + { + int i; + if (listen_fd_count != listen_fdnames_colons + 1) + { + log_fatal ("number of items in LISTEN_FDNAMES (%d) does not match " + "LISTEN_FDS (%d) in --supervised mode\n", + listen_fdnames_colons + 1, listen_fd_count); + exit (1); + } + + for (i = 3; i < 3 + listen_fd_count; i++) + { + int found = 0; + char *next = strchrnul(listen_fdnames, ':'); + *next = '\0'; +#define match_socket(var) if (!found && strcmp (listen_fdnames, #var) == 0) \ + { \ + found = 1; \ + if (*fd_ ## var == GNUPG_INVALID_FD) \ + { \ + *fd_ ## var = i; \ + log_info (#var " socket on fd %d\n", i); \ + } \ + else \ + { \ + log_error ("cannot listen on more than one " #var " socket. (closing fd %d)\n", i); \ + close (i); \ + } \ + } + match_socket(ssh); + match_socket(browser); + match_socket(extra); +#undef match_socket + if (!found) + { + if (*fd == GNUPG_INVALID_FD) + { + *fd = i; + log_info ("standard socket (\"%s\") on fd %d\n", + listen_fdnames, i); + } + else + { + log_error ("cannot listen on more than one standard socket. (closing fd %d)\n", i); + close (i); + } + } + listen_fdnames = next + 1; + } + } +} + /* The main entry point. */ int @@ -731,6 +906,7 @@ main (int argc, char **argv ) int default_config =1; int pipe_server = 0; int is_daemon = 0; + int is_supervised = 0; int nodetach = 0; int csh_style = 0; char *logfile = NULL; @@ -931,6 +1107,7 @@ main (int argc, char **argv ) case oSh: csh_style = 0; break; case oServer: pipe_server = 1; break; case oDaemon: is_daemon = 1; break; + case oSupervised: is_supervised = 1; break; case oDisplay: default_display = xstrdup (pargs.r.ret_str); break; case oTTYname: default_ttyname = xstrdup (pargs.r.ret_str); break; @@ -1030,9 +1207,9 @@ main (int argc, char **argv ) bind_textdomain_codeset (PACKAGE_GT, "UTF-8"); #endif - if (!pipe_server && !is_daemon && !gpgconf_list) + if (!pipe_server && !is_daemon && !gpgconf_list && !is_supervised) { - /* We have been called without any options and thus we merely + /* We have been called without any command and thus we merely check whether an agent is already running. We do this right here so that we don't clobber a logfile with this check but print the status directly to stderr. */ @@ -1187,6 +1364,54 @@ main (int argc, char **argv ) agent_deinit_default_ctrl (ctrl); xfree (ctrl); } + else if (is_supervised) + { + gnupg_fd_t fd = GNUPG_INVALID_FD; + gnupg_fd_t fd_extra = GNUPG_INVALID_FD; + gnupg_fd_t fd_browser = GNUPG_INVALID_FD; + gnupg_fd_t fd_ssh = GNUPG_INVALID_FD; + + /* when supervised and sending logs to stderr, the process + supervisor should handle log entry metadata (pid, name, + timestamp) */ + if (!logfile) + log_set_prefix (NULL, 0); + + log_info ("%s %s starting in supervised mode.\n", + strusage(11), strusage(13) ); + + map_supervised_sockets (&fd, &fd_extra, &fd_browser, &fd_ssh); + if (fd == GNUPG_INVALID_FD) + { + log_fatal ("no standard socket provided\n"); + exit (1); + } + /* record socket names where possible: */ + socket_name = get_socket_path (fd); + socket_name_extra = get_socket_path (fd_extra); + if (socket_name_extra) + opt.extra_socket = 2; + socket_name_browser = get_socket_path (fd_browser); + if (socket_name_browser) + opt.browser_socket = 2; + socket_name_ssh = get_socket_path (fd_ssh); + +#ifdef HAVE_SIGPROCMASK + if (startup_signal_mask_valid) + { + if (sigprocmask (SIG_SETMASK, &startup_signal_mask, NULL)) + log_error ("error restoring signal mask: %s\n", + strerror (errno)); + } + else + log_info ("no saved signal mask\n"); +#endif /*HAVE_SIGPROCMASK*/ + + log_debug ("FDs: std: %d extra: %d browser: %d ssh: %d\n", + fd, fd_extra, fd_browser, fd_ssh); + handle_connections (fd, fd_extra, fd_browser, fd_ssh); + assuan_sock_close (fd); + } else if (!is_daemon) ; /* NOTREACHED */ else diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index b481dd6..b1827be 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -158,6 +158,18 @@ As an alternative you may create a new process as a child of gpg-agent: @code{gpg-agent --daemon /bin/sh}. This way you get a new shell with the environment setup properly; after you exit from this shell, gpg-agent terminates within a few seconds. + + at item --supervised + at opindex supervised +Run in the foreground, sending logs by default to stderr, and +listening on provided file descriptors, which must already be bound to +listening sockets. This command is useful when running under systemd +or other similar process supervision schemes. + +In --supervised mode, different file descriptors can be provided for +use as different socket types (e.g. ssh, extra) as long as they are +identified in the environment variable $LISTEN_FDNAMES (see +sd_listen_fds(3) for more information on this convention). @end table @mansect options -- 2.8.1 From dkg at fifthhorseman.net Fri Aug 12 07:37:57 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Aug 2016 01:37:57 -0400 Subject: [PATCH v3 1/5] logging: Call log_set_prefix() with human-readable labels. In-Reply-To: <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1470980281-2675-2-git-send-email-dkg@fifthhorseman.net> * agent/preset-passphrase.c, agent/protect-tool.c, dirmngr/dirmngr.c, dirmngr/t-http.c, g10/gpg.c, g10/gpgv.c, g13/g13-syshelp.c, g13/g13.c, kbx/kbxutil.c, scd/scdaemon.c, sm/gpgsm.c, tests/gpgscm/main.c, tools/gpg-check-pattern.c, tools/gpg-connect-agent.c, tools/gpgconf.c, tools/gpgtar.c, tools/symcryptrun.c (main): invoke log_set_prefix() with human-readable labels. -- Some invocations of log_set_prefix() were done with raw numeric values instead of values that humans can understand. Use symbolic representations instead of numeric for better readability. Signed-off-by: Daniel Kahn Gillmor --- agent/preset-passphrase.c | 2 +- agent/protect-tool.c | 2 +- dirmngr/dirmngr.c | 4 ++-- dirmngr/t-http.c | 2 +- g10/gpg.c | 4 ++-- g10/gpgv.c | 2 +- g13/g13-syshelp.c | 4 ++-- g13/g13.c | 4 ++-- kbx/kbxutil.c | 2 +- scd/scdaemon.c | 4 ++-- sm/gpgsm.c | 4 ++-- tests/gpgscm/main.c | 2 +- tools/gpg-check-pattern.c | 2 +- tools/gpg-connect-agent.c | 2 +- tools/gpgconf.c | 2 +- tools/gpgtar.c | 2 +- tools/symcryptrun.c | 2 +- 17 files changed, 23 insertions(+), 23 deletions(-) diff --git a/agent/preset-passphrase.c b/agent/preset-passphrase.c index 485ca7b..a104977 100644 --- a/agent/preset-passphrase.c +++ b/agent/preset-passphrase.c @@ -208,7 +208,7 @@ main (int argc, char **argv) early_system_init (); set_strusage (my_strusage); - log_set_prefix ("gpg-preset-passphrase", 1); + log_set_prefix ("gpg-preset-passphrase", GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init (); diff --git a/agent/protect-tool.c b/agent/protect-tool.c index f41cc0b..dbf7811 100644 --- a/agent/protect-tool.c +++ b/agent/protect-tool.c @@ -560,7 +560,7 @@ main (int argc, char **argv ) early_system_init (); set_strusage (my_strusage); gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); - log_set_prefix ("gpg-protect-tool", 1); + log_set_prefix ("gpg-protect-tool", GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init (); diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c index 007fa10..cb17420 100644 --- a/dirmngr/dirmngr.c +++ b/dirmngr/dirmngr.c @@ -743,7 +743,7 @@ main (int argc, char **argv) #endif /*USE_W32_SERVICE*/ set_strusage (my_strusage); - log_set_prefix (DIRMNGR_NAME, 1|4); + log_set_prefix (DIRMNGR_NAME, GPGRT_LOG_WITH_PREFIX | GPGRT_LOG_WITH_PID); /* Make sure that our subsystems are ready. */ i18n_init (); @@ -1073,7 +1073,7 @@ main (int argc, char **argv) if (logfile) { log_set_file (logfile); - log_set_prefix (NULL, 2|4); + log_set_prefix (NULL, GPGRT_LOG_WITH_TIME | GPGRT_LOG_WITH_PID); } if (debug_wait) diff --git a/dirmngr/t-http.c b/dirmngr/t-http.c index 3a6be6c..59959c4 100644 --- a/dirmngr/t-http.c +++ b/dirmngr/t-http.c @@ -154,7 +154,7 @@ main (int argc, char **argv) http_session_t session = NULL; gpgrt_init (); - log_set_prefix (PGM, 1 | 4); + log_set_prefix (PGM, GPGRT_LOG_WITH_PREFIX | GPGRT_LOG_WITH_PID); if (argc) { argc--; argv++; } while (argc && last_argc != argc ) diff --git a/g10/gpg.c b/g10/gpg.c index fd21fde..891c85f 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -2171,7 +2171,7 @@ main (int argc, char **argv) gnupg_rl_initialize (); set_strusage (my_strusage); gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); - log_set_prefix (GPG_NAME, 1); + log_set_prefix (GPG_NAME, GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init(); @@ -3429,7 +3429,7 @@ main (int argc, char **argv) if (logfile && opt.batch) { log_set_file (logfile); - log_set_prefix (NULL, 1|2|4); + log_set_prefix (NULL, GPGRT_LOG_WITH_PREFIX | GPGRT_LOG_WITH_TIME | GPGRT_LOG_WITH_PID); } if (opt.verbose > 2) diff --git a/g10/gpgv.c b/g10/gpgv.c index fd1090e..4ef3e8b 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -149,7 +149,7 @@ main( int argc, char **argv ) early_system_init (); set_strusage (my_strusage); - log_set_prefix ("gpgv", 1); + log_set_prefix ("gpgv", GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init(); diff --git a/g13/g13-syshelp.c b/g13/g13-syshelp.c index 0bb34da..7976be4 100644 --- a/g13/g13-syshelp.c +++ b/g13/g13-syshelp.c @@ -244,7 +244,7 @@ main ( int argc, char **argv) set_strusage (my_strusage); gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); - log_set_prefix (G13_NAME "-syshelp", 1); + log_set_prefix (G13_NAME "-syshelp", GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init (); @@ -437,7 +437,7 @@ main ( int argc, char **argv) if (logfile) { log_set_file (logfile); - log_set_prefix (NULL, 1|2|4); + log_set_prefix (NULL, GPGRT_LOG_WITH_PREFIX | GPGRT_LOG_WITH_TIME | GPGRT_LOG_WITH_PID); } if (gnupg_faked_time_p ()) diff --git a/g13/g13.c b/g13/g13.c index 082edc9..7c6e2e3 100644 --- a/g13/g13.c +++ b/g13/g13.c @@ -364,7 +364,7 @@ main ( int argc, char **argv) set_strusage (my_strusage); gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); - log_set_prefix (G13_NAME, 1); + log_set_prefix (G13_NAME, GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init (); @@ -655,7 +655,7 @@ main ( int argc, char **argv) if (logfile) { log_set_file (logfile); - log_set_prefix (NULL, 1|2|4); + log_set_prefix (NULL, GPGRT_LOG_WITH_PREFIX | GPGRT_LOG_WITH_TIME | GPGRT_LOG_WITH_PID); } if (gnupg_faked_time_p ()) diff --git a/kbx/kbxutil.c b/kbx/kbxutil.c index e452b4d..77b134a 100644 --- a/kbx/kbxutil.c +++ b/kbx/kbxutil.c @@ -454,7 +454,7 @@ main( int argc, char **argv ) early_system_init (); set_strusage( my_strusage ); gcry_control (GCRYCTL_DISABLE_SECMEM); - log_set_prefix ("kbxutil", 1); + log_set_prefix ("kbxutil", GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init (); diff --git a/scd/scdaemon.c b/scd/scdaemon.c index 263d9bd..514e3c2 100644 --- a/scd/scdaemon.c +++ b/scd/scdaemon.c @@ -416,7 +416,7 @@ main (int argc, char **argv ) /* Please note that we may running SUID(ROOT), so be very CAREFUL when adding any stuff between here and the call to INIT_SECMEM() somewhere after the option parsing */ - log_set_prefix ("scdaemon", 1|4); + log_set_prefix ("scdaemon", GPGRT_LOG_WITH_PREFIX | GPGRT_LOG_WITH_PID); /* Make sure that our subsystems are ready. */ i18n_init (); @@ -695,7 +695,7 @@ main (int argc, char **argv ) if (logfile) { log_set_file (logfile); - log_set_prefix (NULL, 1|2|4); + log_set_prefix (NULL, GPGRT_LOG_WITH_PREFIX | GPGRT_LOG_WITH_TIME | GPGRT_LOG_WITH_PID); } if (debug_wait && pipe_server) diff --git a/sm/gpgsm.c b/sm/gpgsm.c index 42b6706..e3b1e88 100644 --- a/sm/gpgsm.c +++ b/sm/gpgsm.c @@ -930,7 +930,7 @@ main ( int argc, char **argv) /* Please note that we may running SUID(ROOT), so be very CAREFUL when adding any stuff between here and the call to secmem_init() somewhere after the option parsing */ - log_set_prefix (GPGSM_NAME, 1); + log_set_prefix (GPGSM_NAME, GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init (); @@ -1507,7 +1507,7 @@ main ( int argc, char **argv) if (logfile && cmd == aServer) { log_set_file (logfile); - log_set_prefix (NULL, 1|2|4); + log_set_prefix (NULL, GPGRT_LOG_WITH_PREFIX | GPGRT_LOG_WITH_TIME | GPGRT_LOG_WITH_PID); } if (gnupg_faked_time_p ()) diff --git a/tests/gpgscm/main.c b/tests/gpgscm/main.c index 5b3792e..34ebb9f 100644 --- a/tests/gpgscm/main.c +++ b/tests/gpgscm/main.c @@ -216,7 +216,7 @@ main (int argc, char **argv) *p = 0, scmpath_len++; set_strusage (my_strusage); - log_set_prefix ("gpgscm", 1); + log_set_prefix ("gpgscm", GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init (); diff --git a/tools/gpg-check-pattern.c b/tools/gpg-check-pattern.c index aa228a7..fba2365 100644 --- a/tools/gpg-check-pattern.c +++ b/tools/gpg-check-pattern.c @@ -165,7 +165,7 @@ main (int argc, char **argv ) early_system_init (); set_strusage (my_strusage); gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); - log_set_prefix ("gpg-check-pattern", 1); + log_set_prefix ("gpg-check-pattern", GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init (); diff --git a/tools/gpg-connect-agent.c b/tools/gpg-connect-agent.c index 6b5f507..106a8eb 100644 --- a/tools/gpg-connect-agent.c +++ b/tools/gpg-connect-agent.c @@ -1172,7 +1172,7 @@ main (int argc, char **argv) early_system_init (); gnupg_rl_initialize (); set_strusage (my_strusage); - log_set_prefix ("gpg-connect-agent", 1); + log_set_prefix ("gpg-connect-agent", GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init(); diff --git a/tools/gpgconf.c b/tools/gpgconf.c index f7ce4c9..69ea9c9 100644 --- a/tools/gpgconf.c +++ b/tools/gpgconf.c @@ -223,7 +223,7 @@ main (int argc, char **argv) early_system_init (); gnupg_reopen_std (GPGCONF_NAME); set_strusage (my_strusage); - log_set_prefix (GPGCONF_NAME, 1); + log_set_prefix (GPGCONF_NAME, GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init(); diff --git a/tools/gpgtar.c b/tools/gpgtar.c index fcbee50..9c17139 100644 --- a/tools/gpgtar.c +++ b/tools/gpgtar.c @@ -416,7 +416,7 @@ main (int argc, char **argv) gnupg_reopen_std (GPGTAR_NAME); set_strusage (my_strusage); - log_set_prefix (GPGTAR_NAME, 1); + log_set_prefix (GPGTAR_NAME, GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init(); diff --git a/tools/symcryptrun.c b/tools/symcryptrun.c index b6dc843..b2d8f5c 100644 --- a/tools/symcryptrun.c +++ b/tools/symcryptrun.c @@ -886,7 +886,7 @@ main (int argc, char **argv) early_system_init (); set_strusage (my_strusage); - log_set_prefix ("symcryptrun", 1); + log_set_prefix ("symcryptrun", GPGRT_LOG_WITH_PREFIX); /* Make sure that our subsystems are ready. */ i18n_init(); -- 2.8.1 From dkg at fifthhorseman.net Fri Aug 12 07:37:58 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Aug 2016 01:37:58 -0400 Subject: [PATCH v3 2/5] logging: Avoid leading ": " when there are no prefixes. In-Reply-To: <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1470980281-2675-3-git-send-email-dkg@fifthhorseman.net> * common/logging.c (do_logv): When no prefixes have been requested, omit the ": " separator, since there is nothing on the left-hand side of it. Signed-off-by: Daniel Kahn Gillmor --- common/logging.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/common/logging.c b/common/logging.c index b6bafc7..c70ba35 100644 --- a/common/logging.c +++ b/common/logging.c @@ -687,14 +687,15 @@ do_logv (int level, int ignore_arg_ptr, const char *fmt, va_list arg_ptr) else es_fprintf_unlocked (logstream, "[%u]", (unsigned int)getpid ()); } - if (!with_time || force_prefixes) + if ((!with_time && (with_prefix || with_pid)) || force_prefixes) es_putc_unlocked (':', logstream); /* A leading backspace suppresses the extra space so that we can correctly output, programname, filename and linenumber. */ if (fmt && *fmt == '\b') fmt++; else - es_putc_unlocked (' ', logstream); + if (with_time || with_prefix || with_pid || force_prefixes) + es_putc_unlocked (' ', logstream); } switch (level) -- 2.8.1 From dkg at fifthhorseman.net Fri Aug 12 07:37:56 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Aug 2016 01:37:56 -0400 Subject: [PATCH v3 0/5] systemd integration for GnuPG daemons (dirmngr and gpg-agent) In-Reply-To: <87vaz7rq1k.fsf@alice.fifthhorseman.net> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> Message-ID: <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> Here is a revised series that incorporates previous feedback and completes supervised socket-activated systemd integration for gpg-agent as well as dirmngr. Compared with v2, this series: * applies minor readability improvements to logging infrastructure * respects log-file configuration option for dirmngr even when in --supervised mode. * implements supervised, systemd-style socket-activation for gpg-agent ("gpg-agent --supervised") * moves the example configuration files from dirmngr/systemd-user into doc/examples/systemd-user -- agent/gpg-agent.c | 229 ++++++++++++++++++++++- agent/preset-passphrase.c | 2 +- agent/protect-tool.c | 2 +- common/logging.c | 5 +- dirmngr/dirmngr.c | 41 +++- dirmngr/t-http.c | 2 +- doc/Makefile.am | 9 +- doc/dirmngr.texi | 7 + doc/examples/systemd-user/README | 66 +++++++ doc/examples/systemd-user/dirmngr.service | 12 ++ doc/examples/systemd-user/dirmngr.socket | 10 + doc/examples/systemd-user/gpg-agent-extra.socket | 12 ++ doc/examples/systemd-user/gpg-agent-ssh.socket | 12 ++ doc/examples/systemd-user/gpg-agent.service | 12 ++ doc/examples/systemd-user/gpg-agent.socket | 10 + doc/gpg-agent.texi | 12 ++ g10/gpg.c | 4 +- g10/gpgv.c | 2 +- g13/g13-syshelp.c | 4 +- g13/g13.c | 4 +- kbx/kbxutil.c | 2 +- scd/scdaemon.c | 4 +- sm/gpgsm.c | 4 +- tests/gpgscm/main.c | 2 +- tools/gpg-check-pattern.c | 2 +- tools/gpg-connect-agent.c | 2 +- tools/gpgconf.c | 2 +- tools/gpgtar.c | 2 +- tools/symcryptrun.c | 2 +- 29 files changed, 451 insertions(+), 28 deletions(-) From dkg at fifthhorseman.net Fri Aug 12 07:38:00 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Aug 2016 01:38:00 -0400 Subject: [PATCH v3 4/5] dirmngr: Implement --supervised command (for systemd, etc). In-Reply-To: <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1470980281-2675-5-git-send-email-dkg@fifthhorseman.net> * dirmngr/dirmngr.c (main): Add new --supervised command, which is a mode designed for running under a process supervision system like systemd or runit. * doc/dirmngr.texi: document --supervised option. -- "dirmngr --supervised" is a way to invoke dirmngr such that a system supervisor like systemd can provide socket-activated startup, log management, and scheduled shutdown. When running in this mode, dirmngr: * Does not open its own listening socket; rather, it expects to be given a listening socket on file descriptor 3. * Does not detach from the invoking process, staying in the foreground instead. Signed-off-by: Daniel Kahn Gillmor --- dirmngr/dirmngr.c | 37 +++++++++++++++++++++++++++++++++++++ doc/dirmngr.texi | 7 +++++++ 2 files changed, 44 insertions(+) diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c index cb17420..fbbad82 100644 --- a/dirmngr/dirmngr.c +++ b/dirmngr/dirmngr.c @@ -94,6 +94,7 @@ enum cmd_and_opt_values { aServer, aDaemon, + aSupervised, aService, aListCRLs, aLoadCRL, @@ -155,6 +156,7 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_c (aServer, "server", N_("run in server mode (foreground)") ), ARGPARSE_c (aDaemon, "daemon", N_("run in daemon mode (background)") ), + ARGPARSE_c (aSupervised, "supervised", N_("run under supervision (e.g. systemd)")), #ifdef USE_W32_SERVICE ARGPARSE_c (aService, "service", N_("run as windows service (background)")), #endif @@ -911,6 +913,7 @@ main (int argc, char **argv) { case aServer: case aDaemon: + case aSupervised: case aService: case aShutdown: case aFlush: @@ -1093,6 +1096,40 @@ main (int argc, char **argv) start_command_handler (ASSUAN_INVALID_FD); shutdown_reaper (); } + else if (cmd == aSupervised) + { + /* In supervised mode, we expect file descriptor 3 to be an + already opened, listening socket. + + We will also not detach from the controlling process or close + stderr; the supervisor should handle all of that. + + FIXME: should we try to extract the actual socket_name from the + file descriptor with getsockname(2) so that we can return it + correctly in response to "GETINFO socket_name"? This isn't + currently done when --socket-name is supplied. + */ + /* Now start with logging to a file if this is desired. */ + if (logfile) + { + log_set_file (logfile); + log_set_prefix (NULL, (GPGRT_LOG_WITH_PREFIX + |GPGRT_LOG_WITH_TIME + |GPGRT_LOG_WITH_PID)); + current_logfile = xstrdup (logfile); + } + else + log_set_prefix (NULL, 0); + +#if USE_LDAP + ldap_wrapper_launch_thread (); +#endif /*USE_LDAP*/ + cert_cache_init (); + crl_cache_init (); + handle_connections (3); + assuan_sock_close (3); + shutdown_reaper (); + } else if (cmd == aDaemon) { assuan_fd_t fd; diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index 033b5d3..65f7d59 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -90,6 +90,13 @@ Run in background daemon mode and listen for commands on a socket. Note that this also changes the default home directory and enables the internal certificate validation code. This mode is deprecated. + at item --supervised + at opindex supervised +Run in the foreground, sending logs to stderr, and listening on file +descriptor 3, which must already be bound to a listening socket. This +is useful when running under systemd or other similar process +supervision schemes. + @item --list-crls @opindex list-crls List the contents of the CRL cache on @code{stdout}. This is probably -- 2.8.1 From dkg at fifthhorseman.net Fri Aug 12 07:38:01 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Aug 2016 01:38:01 -0400 Subject: [PATCH v3 5/5] systemd: Include config for socket-activated user services. In-Reply-To: <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1470980281-2675-6-git-send-email-dkg@fifthhorseman.net> * doc/examples/systemd-user/README: New file describing how to set up these user services for both system integrators and end users. * doc/examples/systemd-user/dirmngr.service: New user service file. * doc/examples/systemd-user/dirmngr.socket: New socket-activation configuration. * doc/examples/systemd-user/gpg-agent.service: New user service file. * doc/examples/systemd-user/gpg-agent*.socket: New socket-activation configurations. * doc/Makefile.am: ship these files in the examples directory. -- These configuration files and instructions enable clean and simple daemon supervision on machines that run systemd. Signed-off-by: Daniel Kahn Gillmor --- doc/Makefile.am | 9 +++- doc/examples/systemd-user/README | 66 ++++++++++++++++++++++++ doc/examples/systemd-user/dirmngr.service | 12 +++++ doc/examples/systemd-user/dirmngr.socket | 10 ++++ doc/examples/systemd-user/gpg-agent-extra.socket | 12 +++++ doc/examples/systemd-user/gpg-agent-ssh.socket | 12 +++++ doc/examples/systemd-user/gpg-agent.service | 12 +++++ doc/examples/systemd-user/gpg-agent.socket | 10 ++++ 8 files changed, 142 insertions(+), 1 deletion(-) create mode 100644 doc/examples/systemd-user/README create mode 100644 doc/examples/systemd-user/dirmngr.service create mode 100644 doc/examples/systemd-user/dirmngr.socket create mode 100644 doc/examples/systemd-user/gpg-agent-extra.socket create mode 100644 doc/examples/systemd-user/gpg-agent-ssh.socket create mode 100644 doc/examples/systemd-user/gpg-agent.service create mode 100644 doc/examples/systemd-user/gpg-agent.socket diff --git a/doc/Makefile.am b/doc/Makefile.am index 52ac398..53d3084 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -21,7 +21,14 @@ AM_CPPFLAGS = include $(top_srcdir)/am/cmacros.am -examples = examples/README examples/scd-event examples/trustlist.txt \ +examples = examples/README examples/scd-event examples/trustlist.txt \ + examples/systemd-user/README \ + examples/systemd-user/dirmngr.service \ + examples/systemd-user/dirmngr.socket \ + examples/systemd-user/gpg-agent.service \ + examples/systemd-user/gpg-agent.socket \ + examples/systemd-user/gpg-agent-ssh.socket \ + examples/systemd-user/gpg-agent-extra.socket \ examples/gpgconf.conf examples/pwpattern.list helpfiles = help.txt help.be.txt help.ca.txt help.cs.txt \ diff --git a/doc/examples/systemd-user/README b/doc/examples/systemd-user/README new file mode 100644 index 0000000..ac678ed --- /dev/null +++ b/doc/examples/systemd-user/README @@ -0,0 +1,66 @@ +Socket-activated dirmngr and gpg-agent with systemd +=================================================== + +When used on a GNU/Linux system supervised by systemd, you can ensure +that the GnuPG daemons dirmngr and gpg-agent are launched +automatically the first time they're needed, and shut down cleanly at +session logout. This is done by enabling user services via +socket-activation. + +System distributors +------------------- + +The *.service and *.socket files (from this directory) should be +placed in /usr/lib/systemd/user/ alongside other user-session services +and sockets. + +To enable socket-activated dirmngr for all accounts on the system, +use: + + systemctl --user --global enable dirmngr.socket + +To enable socket-activated gpg-agent for all accounts on the system, +use: + + systemctl --user --global enable gpg-agent.socket + +Additionally, you can enable socket-activated gpg-agent ssh-agent +emulation for all accounts on the system with: + + systemctl --user --global enable gpg-agent-ssh.socket + +You can also enable constrained ("--extra-socket"-style) gpg-agent +sockets for all accounts on the system with: + + systemctl --user --global enable gpg-agent-extra.socket + +Individual users +---------------- + +A user on a system with systemd where this has not been installed +system-wide can place these files in ~/.config/systemd/user/ to make +them available. + +If a given service isn't installed system-wide, or if it's installed +system-wide but not globally enabled, individual users will still need +to enable them. For example, to enable socket-activated dirmngr for +all future sessions: + + systemctl --user enable dirmngr.socket + +To enable socket-activated gpg-agent with ssh support, do: + + systemctl --user enable gpg-agent.socket gpg-agent-ssh.socket + +These changes won't take effect until your next login after you've +fully logged out (be sure to terminate any running daemons before +logging out). + +If you'd rather try a socket-activated GnuPG daemon in an +already-running session without logging out (with or without enabling +it for all future sessions), kill any existing daemon and start the +user socket directly. For example, to set up socket-activated dirmgnr +in the current session: + + gpgconf --kill dirmngr + systemctl --user start dirmngr.socket diff --git a/doc/examples/systemd-user/dirmngr.service b/doc/examples/systemd-user/dirmngr.service new file mode 100644 index 0000000..d5e6eac --- /dev/null +++ b/doc/examples/systemd-user/dirmngr.service @@ -0,0 +1,12 @@ +[Unit] +Description=GnuPG network certificate management daemon +Documentation=man:dirmngr(8) +Requires=dirmngr.socket +After=dirmngr.socket + +[Service] +ExecStart=/usr/bin/dirmngr --supervised + +[Install] +Also=dirmngr.socket +WantedBy=default.target diff --git a/doc/examples/systemd-user/dirmngr.socket b/doc/examples/systemd-user/dirmngr.socket new file mode 100644 index 0000000..27bb9cf --- /dev/null +++ b/doc/examples/systemd-user/dirmngr.socket @@ -0,0 +1,10 @@ +[Unit] +Description=GnuPG network certificate management daemon +Documentation=man:dirmngr(8) + +[Socket] +ListenStream=/run/user/%U/gnupg/S.dirmngr +SocketMode=0600 + +[Install] +WantedBy=sockets.target diff --git a/doc/examples/systemd-user/gpg-agent-extra.socket b/doc/examples/systemd-user/gpg-agent-extra.socket new file mode 100644 index 0000000..7eb35f9 --- /dev/null +++ b/doc/examples/systemd-user/gpg-agent-extra.socket @@ -0,0 +1,12 @@ +[Unit] +Description=GnuPG cryptographic agent and passphrase cache (restricted) +Documentation=man:gpg-agent(1) + +[Socket] +ListenStream=%t/gnupg/S.gpg-agent.extra +FileDescriptorName=extra +Service=gpg-agent.service +SocketMode=0600 + +[Install] +WantedBy=sockets.target diff --git a/doc/examples/systemd-user/gpg-agent-ssh.socket b/doc/examples/systemd-user/gpg-agent-ssh.socket new file mode 100644 index 0000000..8970288 --- /dev/null +++ b/doc/examples/systemd-user/gpg-agent-ssh.socket @@ -0,0 +1,12 @@ +[Unit] +Description=GnuPG cryptographic agent (ssh-agent emulation) +Documentation=man:gpg-agent(1) man:ssh-add(1) man:ssh-agent(1) man:ssh(1) + +[Socket] +ListenStream=%t/gnupg/S.gpg-agent.ssh +FileDescriptorName=ssh +Service=gpg-agent.service +SocketMode=0600 + +[Install] +WantedBy=sockets.target diff --git a/doc/examples/systemd-user/gpg-agent.service b/doc/examples/systemd-user/gpg-agent.service new file mode 100644 index 0000000..025230a --- /dev/null +++ b/doc/examples/systemd-user/gpg-agent.service @@ -0,0 +1,12 @@ +[Unit] +Description=GnuPG cryptographic agent and passphrase cache +Documentation=man:gpg-agent(1) +Requires=gpg-agent.socket +After=gpg-agent.socket + +[Service] +ExecStart=/usr/bin/gpg-agent --supervised + +[Install] +Also=gpg-agent.socket +WantedBy=default.target diff --git a/doc/examples/systemd-user/gpg-agent.socket b/doc/examples/systemd-user/gpg-agent.socket new file mode 100644 index 0000000..1c7b3a6 --- /dev/null +++ b/doc/examples/systemd-user/gpg-agent.socket @@ -0,0 +1,10 @@ +[Unit] +Description=GnuPG cryptographic agent and passphrase cache +Documentation=man:gpg-agent(1) + +[Socket] +ListenStream=%t/gnupg/S.gpg-agent +SocketMode=0600 + +[Install] +WantedBy=sockets.target -- 2.8.1 From aheinecke at intevation.de Fri Aug 12 09:31:35 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 12 Aug 2016 09:31:35 +0200 Subject: [PATCH] pinentry:: Qt: Append -std=c++11 if building against Qt 5.7 In-Reply-To: References: Message-ID: <2047445.Bn3o8kzvp7@esus> On Thursday 11 August 2016 19:13:39 Kristian Fiskerstrand wrote: > * m4/qt.m4: Append -std=c++11 to CFLAGS if building against Qt 5.7 Thanks, merged. Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Aug 12 12:12:57 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Aug 2016 12:12:57 +0200 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <87vaz7rq1k.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 11 Aug 2016 16:47:35 -0400") References: <8760rd25ye.fsf@alice.fifthhorseman.net> <1470793057-12340-1-git-send-email-dkg@fifthhorseman.net> <87r39x15r6.fsf@europa.jade-hamburg.de> <87zioku09d.fsf@alice.fifthhorseman.net> <87k2fn5tlj.fsf@europa.jade-hamburg.de> <87vaz7rq1k.fsf@alice.fifthhorseman.net> Message-ID: <87y442fg7q.fsf@wheatstone.g10code.de> On Thu, 11 Aug 2016 22:47, dkg at fifthhorseman.net said: > Well, there is no general "gnupg log" that i'm aware of -- but i'm fine > with re-enabling the log-file directive in --supervised mode if you My advise has always been to put log-file socket:///home/user/.gnupg/S.log into the conf files and use watchgnupg to read or log them. In fact that is what kmail does with its kwatchgnupg. > ssh-agent). But in the system supervision case it's actually still the > same gpg-agent that's running, not an imposter. it's just be started up > automatically without exercising any of the auto-spawning code. How do you convey the envvars to gpg-agent? What systemd does is different from what gpg will do; for example the default tty, DISPLAY, and locale may be different. gpg will also pass --homedir to the invocation of gpg-agent if gpg has been started this way. > There is considerably more code in dirmngr that is only for the purposes > of supporting one specific OS (Windows) than there is in the patchset > i've proposed. Actually we are not using dirmngr as a system service on Windows for some years. Thus most of this code is subject to removal. > 0) do not start the daemon unless something the user does actively > needs it. That is already accomplished by gnupg itself. > 1) do not run multiple instances of the daemon for any given user. Ditto. > 2) cleanly and promptly terminate the daemon when the user has > no more running sessions on the machine. For dirmngr this is not a good idea because we plan to add background tasks (parcimonie). For gpg-agent there valid use cases to keep on running gpg-agent even after all user sessions are closed. For example a server is using a smartcard to autheniticate connections done via cron. Terminating the gpg-agent and thus gpg-agent would reset the smartcard and require the operator to open a session to enter the PIN again. > Recent versions of gnupg support desiderata 0 and 1 fairly well out of > the box, but i've seen no concrete proposals for how to deal with 2, and A simple solution would be to "gpgconf --reload gpg-agent" after logout of any session. This will flush the caches and thus no sensitive information is held by the agent. This might be a bit annoying for other sessions using gpg-agent becuase they need to re-enter their passphrase, but I guess people can live with that. Or just kill the gpg-agent at session end, it will be restarted anyway as needed. For killing I added a feature to tell the number of active connections to gpg-agent, so that a logout script can gracefully kill gpg-agent. But even that is not required because a single SIGTERM will delay termination until all connections are close. Another option is that gpg-agent can be changed to terminate itself some time after all cache entries are expired. > some legitimate complaints about it (see an earlier Subject: in this > thread, which came from debian developer Ian Jackson: "Beware of > leftover gpg-agent processes"). One gpg-agent process per user, unless several have been started from different home directories. In fact gpg-agent has a self-check to make sure that only one instance is running for a given homedir (technically for a given socket). BTW, I wish Ian would finally apply the Tor patches to adns after more than one year of asking him. It is annoying that we have full Tor support only on Windows. > environment. This kind of system integration allows for the creation of > simple quick overview tools of machine state (e.g. "systemctl --user > status"), standardized logging (e.g. "journalctl --user -u gpg-agent"), Sounds like Windows and not like Unix > eh? It sounds to me like you're aware of some complaint or bug report > i'm unware of. Could you explain more, or point me to a specific > example, please? I've been running systemd for quite some time and i've See the recent LWN article about systemd terminating all processes at session close including nohup'ed processes. > Certainly, you can configure systemd to act as a "watchdog" and have it > kill processes that don't report regularly to a dbus interface, GnuPG does not use dbus. Long ago I considered to add support for this but after checking all the dependencies and code required for dbus I figured that this is not a good idea and could only be added using an external helper. What your proposed change won't solve is the ssh-agent support. Well gpg-agent would be started by ssh as needed - cool. But the also important point on how to convey the envvars to gpg-agent is not solved - this requires changes to the ssh-agent protocol and code changes to ssh, proper. Now if those changes are anyway required, the autostarting can be added as well. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Fri Aug 12 12:19:46 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Aug 2016 12:19:46 +0200 Subject: [PATCH v3 2/5] logging: Avoid leading ": " when there are no prefixes. In-Reply-To: <1470980281-2675-3-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Aug 2016 01:37:58 -0400") References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-3-git-send-email-dkg@fifthhorseman.net> Message-ID: <87k2fmffwd.fsf@wheatstone.g10code.de> On Fri, 12 Aug 2016 07:37, dkg at fifthhorseman.net said: > * common/logging.c (do_logv): When no prefixes have been requested, > omit the ": " separator, since there is nothing on the left-hand > side of it. Thanks. Apllied. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Fri Aug 12 12:19:30 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Aug 2016 12:19:30 +0200 Subject: [PATCH v3 1/5] logging: Call log_set_prefix() with human-readable labels. In-Reply-To: <1470980281-2675-2-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Aug 2016 01:37:57 -0400") References: <87vaz7rq1k.fsf@alice.fifthhorseman.net> <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net> <1470980281-2675-2-git-send-email-dkg@fifthhorseman.net> Message-ID: <87oa4yffwt.fsf@wheatstone.g10code.de> On Fri, 12 Aug 2016 07:37, dkg at fifthhorseman.net said: > Some invocations of log_set_prefix() were done with raw numeric values > instead of values that humans can understand. Use symbolic > representations instead of numeric for better readability. Thanks. Applied. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From dkg at fifthhorseman.net Fri Aug 12 22:07:43 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Aug 2016 16:07:43 -0400 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <87y442fg7q.fsf@wheatstone.g10code.de> Message-ID: <87twepzr74.fsf@alice.fifthhorseman.net> Hi Werner-- Thanks for the feedback, and for merging those logging patches! On Fri 2016-08-12 06:12:57 -0400, Werner Koch wrote: > My advise has always been to put > > log-file socket:///home/user/.gnupg/S.log > > into the conf files and use watchgnupg to read or log them. In fact > that is what kmail does with its kwatchgnupg. I see this advice is in doc/tools.texi, but i don't see it used often. 'S.log' for GnuPG doesn't show up anywhere else in debian, for example: https://codesearch.debian.net/search?q=%5CWS%5C.log%5CW&perpkg=1 Anyway, i'm happy to support this case, and have made sure in this latest series that log-file is still supported in the --supervised mode. >> ssh-agent). But in the system supervision case it's actually still the >> same gpg-agent that's running, not an imposter. it's just be started up >> automatically without exercising any of the auto-spawning code. > > How do you convey the envvars to gpg-agent? What systemd does is > different from what gpg will do; for example the default tty, DISPLAY, > and locale may be different. gpg will also pass --homedir to the > invocation of gpg-agent if gpg has been started this way. gpg conveys envvars to gpg-agent during its use. This is what allows us to run a single daemon that responds to requests from multiple concurrent sessions, right? >> There is considerably more code in dirmngr that is only for the purposes >> of supporting one specific OS (Windows) than there is in the patchset >> i've proposed. > > Actually we are not using dirmngr as a system service on Windows for > some years. Thus most of this code is subject to removal. Great! i'm always happy to hear about code removal in complex projects. :) Even aside from the system service, there's still a lot of Win32-specific code, though. This is not meant as a critique -- i think it's a good thing that GnuPG is capable of supporting people on Windows, even though it's not a platform i'd ever recommend or use myself. I recognize that some people are stuck there and we should be supporting them. >> 2) cleanly and promptly terminate the daemon when the user has >> no more running sessions on the machine. > > For dirmngr this is not a good idea because we plan to add background > tasks (parcimonie). I'd be a little surprised if most people expected a parcimonie-style updater to run (and update their keyring, etc) when they weren't actually logged into the computer. parcimonie itself certainly doesn't do that. But for someone who does want to do that, these changes don't prevent them from launching dirmngr explicitly in a non-supervised scope. > For gpg-agent there valid use cases to keep on running gpg-agent even > after all user sessions are closed. For example a server is using a > smartcard to autheniticate connections done via cron. Terminating the > gpg-agent and thus gpg-agent would reset the smartcard and require the > operator to open a session to enter the PIN again. Those use cases are definitely valid, and they're still supported: the user just doesn't use --supervised. however, the common use case, where users want daemons running alongside their session, and *don't* want gpg-agent still running and using the smartcard after they log out will be better handled with some sort of system integration. > A simple solution would be to "gpgconf --reload gpg-agent" after logout > of any session. This will flush the caches and thus no sensitive > information is held by the agent. This might be a bit annoying for > other sessions using gpg-agent becuase they need to re-enter their > passphrase, but I guess people can live with that. Or just kill the > gpg-agent at session end, it will be restarted anyway as needed. I agree that killing the agent at any logout is better than the current non-integration with any sort of session management (though i agree that it might be a little frustrating for one ephemeral login to drop a hot cache for a long-running login). This sounds like a reasonable proposal for systems that don't have structured session management. Any suggestions for where to encourage this setup on such a system? > For killing I added a feature to tell the number of active connections > to gpg-agent, so that a logout script can gracefully kill gpg-agent. > But even that is not required because a single SIGTERM will delay > termination until all connections are close. right, this bit is fine no matter how we resolve it. Thanks for making sure this engineering is solid. > Another option is that gpg-agent can be changed to terminate itself some > time after all cache entries are expired. Yes, this would be really useful approach, and seems like it'd be a good thing to do regardless of how this patch series works out. The only concern i'd have would be about how to get the agent to respawn for use by ssh (though the socket-activation i'm proposing does solve that problem). It would still leave sessions open in the background for several minutes after logout in some common use cases, but it would be far better than having live code running indefinitely. I'm assuming this would be a new configuration option for gpg-agent. Maybe --terminate-after-idle ? What should it default to? I can send patches for this feature if you want it. the other question is what counts as "idle" -- it's not just that nothing is in the cache, right? might also want to count commands like PUTVAL as a timer reset... >> some legitimate complaints about it (see an earlier Subject: in this >> thread, which came from debian developer Ian Jackson: "Beware of >> leftover gpg-agent processes"). > > One gpg-agent process per user, unless several have been started from > different home directories. In fact gpg-agent has a self-check to make > sure that only one instance is running for a given homedir (technically > for a given socket). > > BTW, I wish Ian would finally apply the Tor patches to adns after more > than one year of asking him. It is annoying that we have full Tor > support only on Windows. Totally agreed. Is there a canonical place where this is discussed, or where the patches live? I've seen discussions on it here on gnupg-devel, but there wasn't anything in the debian or GNU bts until i filed this earlier today: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24212 >> environment. This kind of system integration allows for the creation of >> simple quick overview tools of machine state (e.g. "systemctl --user >> status"), standardized logging (e.g. "journalctl --user -u gpg-agent"), > > Sounds like Windows and not like Unix System-wide overviews and standardized tooling ("do one thing and do it well") aren't unix-like? We should probably change that ;) But seriously, i'm not interested in this as a religious conflict; i'm interested in good system integration on platforms that i care about and can do something about. GNU/Linux with systemd as pid 1 is one such platform today. I'm pretty sure we can both acknowledge that good defaults that don't require research or special knowledge are important for making tools that normal users can actually use. And I'm also pretty sure we both want GnuPG and its related tools to be usable by normal people. right? >> eh? It sounds to me like you're aware of some complaint or bug report >> i'm unware of. Could you explain more, or point me to a specific >> example, please? I've been running systemd for quite some time and i've > > See the recent LWN article about systemd terminating all processes at > session close including nohup'ed processes. This is hardly "randomly killing" -- it's attempting to fix the problem that (for example) some daemon might remain active and doing things "on your behalf" after you thought you'd terminated your session. I agree that terminating the nohup'ed processes was overreach, but the problem they're attempting to solve is a real one. >> Certainly, you can configure systemd to act as a "watchdog" and have it >> kill processes that don't report regularly to a dbus interface, > > GnuPG does not use dbus. Long ago I considered to add support for this > but after checking all the dependencies and code required for dbus I > figured that this is not a good idea and could only be added using an > external helper. Sure -- i was not proposing that we'd do this for gpg-agent or for dirmngr. > What your proposed change won't solve is the ssh-agent support. Well > gpg-agent would be started by ssh as needed - cool. right, it solves this part of the problem, but... > But the also important point on how to convey the envvars to gpg-agent > is not solved ... it doesn't solve https://bugs.debian.org/830658 > this requires changes to the ssh-agent protocol and code changes to > ssh, proper. Now if those changes are anyway required, the > autostarting can be added as well. I'm not sure this is the only way to solve the problem, and i have pretty serious doubts about getting autostarting of gpg-agent into ssh. The problem isn't transmitting envvars in itself, it's figuring out how the agent should get a prompt back to the user. Historically, we've done that in GnuPG by passing env vars over the assuan socket. As long as you're OK with this kind of opportunity for leakage (processes in session B can take control of the agent without session A knowing about it), and your clients know what needs to be to sent, this is fine. And ssh has historically done that by having the agent just know the correct env vars in the first place, and never deviating. As long as you're OK with no leakage (session B can't use the agent without session A knowing about it), this also works fine. But they're not the same tradeoffs :/ In particular, the ssh-agent model assumes one agent *per X11 session*, and gpg-agent assumes one agent *per user*. If the agent's notifications were done per-user instead of per-X11 session, then the environment variables wouldn't necessarily be relevant, right? I need to think more about how we might approach this sanely, but it seems like you could potentially address it with a pinentry/ssh-askpass that is aware of how the parent daemon's lifespan is scoped. However we solve those problems, having process supervision and socket activation still seem like good things, so i'd still like these patches to be considered by upstream GnuPG. I don't think they break any existing non-systemd workflow, and they provide concrete benefits to people using machines configured with systemd. I welcome feedback on the proposed implementation and interfaces. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From ilf at zeromail.org Sat Aug 13 14:21:56 2016 From: ilf at zeromail.org (ilf) Date: Sat, 13 Aug 2016 14:21:56 +0200 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <87twepzr74.fsf@alice.fifthhorseman.net> References: <87y442fg7q.fsf@wheatstone.g10code.de> <87twepzr74.fsf@alice.fifthhorseman.net> Message-ID: <20160813122156.GD3453@zeromail.org> Daniel Kahn Gillmor: > I'd be a little surprised if most people expected a parcimonie-style > updater to run (and update their keyring, etc) when they weren't > actually logged into the computer. parcimonie itself certainly doesn't > do that. Both parcimonie.sh [1] and gpg-maintenance [2] do that. They start on boot via init/systemd and run independently of user logins. 1. https://github.com/EtiennePerot/parcimonie.sh 2. https://github.com/ilf/gpg-maintenance -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Aug 13 15:07:38 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 13 Aug 2016 09:07:38 -0400 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <20160813122156.GD3453@zeromail.org> References: <87y442fg7q.fsf@wheatstone.g10code.de> <87twepzr74.fsf@alice.fifthhorseman.net> <20160813122156.GD3453@zeromail.org> Message-ID: <871t1szujp.fsf@alice.fifthhorseman.net> On Sat 2016-08-13 08:21:56 -0400, ilf wrote: > Daniel Kahn Gillmor: >> I'd be a little surprised if most people expected a parcimonie-style >> updater to run (and update their keyring, etc) when they weren't >> actually logged into the computer. parcimonie itself certainly doesn't >> do that. > > Both parcimonie.sh [1] and gpg-maintenance [2] do that. They start on > boot via init/systemd and run independently of user logins. > > 1. https://github.com/EtiennePerot/parcimonie.sh > 2. https://github.com/ilf/gpg-maintenance This suggests that they're being run as system services, not user services. It requires administrative control over the system to set up a system service, so not everyone can do this. If you have administrative control over a system, you should also be able to set up a comparable system service with the mechanism i'm proposing here, and it wouldn't be terminated at logout. So i think the proposal on the table here isn't incompatible with this arrangement, for those who want it. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From wk at gnupg.org Tue Aug 16 10:22:04 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Aug 2016 10:22:04 +0200 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <87twepzr74.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Aug 2016 16:07:43 -0400") References: <87twepzr74.fsf@alice.fifthhorseman.net> Message-ID: <87wpjh86oj.fsf@wheatstone.g10code.de> On Fri, 12 Aug 2016 22:07, dkg at fifthhorseman.net said: > Thanks for the feedback, and for merging those logging patches! Thanks for that work. I am a bit under time pressure this week and would like to defer answering your mail. Except for some details I realize that we need to add some support for systemd soon. But probably not for the next release which is due this week anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From bjk at luxsci.net Wed Aug 17 02:51:35 2016 From: bjk at luxsci.net (Ben Kibbey) Date: Tue, 16 Aug 2016 20:51:35 -0400 Subject: [PATCH] pinentry-curses: Handle SETREPEAT. Message-ID: <1471395122-7425935.79796842.fu7H0pZJv015877@rs146.luxsci.com> * pinentry/pinentry-curses.c (DIALOG_POS_REPEAT_PIN): New. (dialog_t): Separate members for repeat. (dialog_create): Create passphrase repeat field. (dialog_switch_pos): Handle DIALOG_POS_REPEAT_PIN. (dialog_input): Modify to handle the repeat field. (test_repeat): New. (dialog_run): Skip OK when changing fields and passphrases do not match. Signed-off-by: Ben Kibbey --- pinentry/pinentry-curses.c | 287 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 227 insertions(+), 60 deletions(-) diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c index 659fa47..267d5be 100644 --- a/pinentry/pinentry-curses.c +++ b/pinentry/pinentry-curses.c @@ -70,6 +70,7 @@ typedef enum { DIALOG_POS_NONE, DIALOG_POS_PIN, + DIALOG_POS_REPEAT_PIN, DIALOG_POS_OK, DIALOG_POS_NOTOK, DIALOG_POS_CANCEL @@ -79,15 +80,21 @@ dialog_pos_t; struct dialog { dialog_pos_t pos; + char *repeat_pin; int pin_y; int pin_x; + int repeat_pin_y; + int repeat_pin_x; /* Width of the PIN field. */ int pin_size; + int repeat_pin_size; /* Cursor location in PIN field. */ int pin_loc; + int repeat_pin_loc; int pin_max; /* Length of PIN. */ int pin_len; + int repeat_pin_len; int ok_y; int ok_x; @@ -236,6 +243,7 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) CH *description = NULL; CH *error = NULL; CH *prompt = NULL; + CH *repeat_passphrase = NULL; dialog->pinentry = pinentry; @@ -256,6 +264,7 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) COPY_OUT (description); COPY_OUT (error); COPY_OUT (prompt); + COPY_OUT (repeat_passphrase); /* There is no pinentry->default_notok. Map it to pinentry->notok. */ @@ -364,6 +373,9 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) y += 2; /* Error message. */ } y += 2; /* Pin entry field. */ + + if (pinentry->repeat_passphrase) + y += 2; } y += 2; /* OK/Cancel and bottom frame. */ @@ -401,8 +413,12 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) new_x = MIN_PINENTRY_LENGTH; if (prompt) { - new_x += STRLEN (prompt) + 1; /* One space after prompt. */ + int n = repeat_passphrase ? STRLEN (repeat_passphrase) : 0; + new_x += STRLEN (prompt) + n + 1; /* One space after prompt. */ } + else if (repeat_passphrase) + new_x += STRLEN (repeat_passphrase) + 1; + if (new_x > size_x - 4) new_x = size_x - 4; if (new_x > x) @@ -431,8 +447,8 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) dialog->pos = DIALOG_POS_NONE; dialog->pin_max = pinentry->pin_len; - dialog->pin_loc = 0; - dialog->pin_len = 0; + dialog->pin_loc = dialog->repeat_pin_loc = 0; + dialog->pin_len = dialog->repeat_pin_len = 0; ypos = (size_y - y) / 2; xpos = (size_x - x) / 2; move (ypos, xpos); @@ -545,6 +561,35 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) move (ypos, xpos); addch (ACS_VLINE); ypos++; + + if (repeat_passphrase) + { + CH *p = repeat_passphrase; + + move (ypos, xpos); + addch (ACS_VLINE); + addch (' '); + + dialog->repeat_pin_y = ypos; + dialog->repeat_pin_x = xpos + 2; + dialog->repeat_pin_size = x - 4; + i = STRLEN (p); + if (i > x - 4 - MIN_PINENTRY_LENGTH) + i = x - 4 - MIN_PINENTRY_LENGTH; + dialog->repeat_pin_x += i + 1; + dialog->repeat_pin_size -= i + 1; + while (i-- > 0) + { + ADDCH (*(p++)); + } + addch (' '); + for (i = 0; i < dialog->repeat_pin_size; i++) + addch ('_'); + ypos++; + move (ypos, xpos); + addch (ACS_VLINE); + ypos++; + } } move (ypos, xpos); addch (ACS_VLINE); @@ -590,6 +635,8 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) free (error); if (prompt) free (prompt); + if (repeat_passphrase) + free (repeat_passphrase); return err; } @@ -620,8 +667,8 @@ dialog_switch_pos (dialog_t diag, dialog_pos_t new_pos) switch (diag->pos) { case DIALOG_POS_OK: - move (diag->ok_y, diag->ok_x); - addstr (diag->ok); + move (diag->ok_y, diag->ok_x); + addstr (diag->ok); break; case DIALOG_POS_NOTOK: if (diag->notok) @@ -647,13 +694,17 @@ dialog_switch_pos (dialog_t diag, dialog_pos_t new_pos) move (diag->pin_y, diag->pin_x + diag->pin_loc); set_cursor_state (1); break; + case DIALOG_POS_REPEAT_PIN: + move (diag->repeat_pin_y, diag->repeat_pin_x + diag->repeat_pin_loc); + set_cursor_state (1); + break; case DIALOG_POS_OK: set_cursor_state (0); - move (diag->ok_y, diag->ok_x); - standout (); - addstr (diag->ok); - standend (); - move (diag->ok_y, diag->ok_x); + move (diag->ok_y, diag->ok_x); + standout (); + addstr (diag->ok); + standend (); + move (diag->ok_y, diag->ok_x); break; case DIALOG_POS_NOTOK: if (diag->notok) @@ -690,9 +741,36 @@ dialog_switch_pos (dialog_t diag, dialog_pos_t new_pos) static void dialog_input (dialog_t diag, int alt, int chr) { - int old_loc = diag->pin_loc; + int old_loc = diag->pos == DIALOG_POS_PIN ? diag->pin_loc + : diag->repeat_pin_loc; + int *pin_len; + int *pin_loc; + int *pin_size; + int *pin_x, *pin_y; + int *pin_max = &diag->pin_max; + char *pin; + assert (diag->pinentry->pin); - assert (diag->pos == DIALOG_POS_PIN); + assert (diag->pos == DIALOG_POS_PIN || diag->pos == DIALOG_POS_REPEAT_PIN); + + if (diag->pos == DIALOG_POS_PIN) + { + pin_len = &diag->pin_len; + pin_loc = &diag->pin_loc; + pin_size = &diag->pin_size; + pin_x = &diag->pin_x; + pin_y = &diag->pin_y; + pin = diag->pinentry->pin; + } + else + { + pin_len = &diag->repeat_pin_len; + pin_loc = &diag->repeat_pin_loc; + pin_size = &diag->repeat_pin_size; + pin_x = &diag->repeat_pin_x; + pin_y = &diag->repeat_pin_y; + pin = diag->repeat_pin; + } if (alt && chr == KEY_BACKSPACE) /* Remap alt-backspace to control-W. */ @@ -706,15 +784,15 @@ dialog_input (dialog_t diag, int alt, int chr) /* ASCII DEL. What Mac OS X apparently emits when the "delete" (backspace) key is pressed. */ case 127: - if (diag->pin_len > 0) + if (*pin_len > 0) { - diag->pin_len--; - diag->pin_loc--; - if (diag->pin_loc == 0 && diag->pin_len > 0) + (*pin_len)--; + (*pin_loc)--; + if (*pin_loc == 0 && *pin_len > 0) { - diag->pin_loc = diag->pin_size - 5; - if (diag->pin_loc > diag->pin_len) - diag->pin_loc = diag->pin_len; + *pin_loc = *pin_size - 5; + if (*pin_loc > *pin_len) + *pin_loc = *pin_len; } } break; @@ -727,47 +805,45 @@ dialog_input (dialog_t diag, int alt, int chr) case 'u' - 'a' + 1: /* control-u */ /* Erase the whole line. */ - if (diag->pin_len > 0) + if (*pin_len > 0) { - diag->pin_len = 0; - diag->pin_loc = 0; + *pin_len = 0; + *pin_loc = 0; } break; case 'w' - 'a' + 1: /* control-w. */ - while (diag->pin_len > 0 - && diag->pinentry->pin[diag->pin_len - 1] == ' ') + while (*pin_len > 0 && pin[*pin_len - 1] == ' ') { - diag->pin_len --; - diag->pin_loc --; - if (diag->pin_loc < 0) + (*pin_len)--; + (*pin_loc)--; + if (*pin_loc < 0) { - diag->pin_loc += diag->pin_size; - if (diag->pin_loc > diag->pin_len) - diag->pin_loc = diag->pin_len; + *pin_loc += *pin_size; + if (*pin_loc > *pin_len) + *pin_loc = *pin_len; } } - while (diag->pin_len > 0 - && diag->pinentry->pin[diag->pin_len - 1] != ' ') + while (*pin_len > 0 && pin[*pin_len - 1] != ' ') { - diag->pin_len --; - diag->pin_loc --; - if (diag->pin_loc < 0) + (*pin_len)--; + (*pin_loc)--; + if (*pin_loc < 0) { - diag->pin_loc += diag->pin_size; - if (diag->pin_loc > diag->pin_len) - diag->pin_loc = diag->pin_len; + *pin_loc += *pin_size; + if (*pin_loc > *pin_len) + *pin_loc = *pin_len; } } break; default: - if (chr > 0 && chr < 256 && diag->pin_len < diag->pin_max) + if (chr > 0 && chr < 256 && *pin_len < *pin_max) { /* Make sure there is enough room for this character and a following NUL byte. */ - if (! pinentry_setbufferlen (diag->pinentry, diag->pin_len + 2)) + if (! pinentry_setbufferlen (diag->pinentry, *pin_len + 2)) { /* Bail. Here we use a simple approach. It would be better to have a pinentry_bug function. */ @@ -775,32 +851,85 @@ dialog_input (dialog_t diag, int alt, int chr) abort (); } - diag->pinentry->pin[diag->pin_len] = (char) chr; - diag->pin_len++; - diag->pin_loc++; - if (diag->pin_loc == diag->pin_size && diag->pin_len < diag->pin_max) + if (diag->pos == DIALOG_POS_REPEAT_PIN) + { + if (!*pin_len || *pin_len > diag->repeat_pin_len) + { + char *newp = secmem_realloc (diag->repeat_pin, *pin_len + 2); + + if (newp) + pin = diag->repeat_pin = newp; + else + { + secmem_free (diag->pinentry->pin); + diag->pinentry->pin = 0; + diag->pinentry->pin_len = 0; + secmem_free (diag->repeat_pin); + diag->repeat_pin = 0; + *pin_len = 0; + /* Bail. Here we use a simple approach. It would be + better to have a pinentry_bug function. */ + assert (!"setbufferlen failed"); + abort (); + } + } + } + else + pin = diag->pinentry->pin; + + pin[*pin_len] = (char) chr; + (*pin_len)++; + (*pin_loc)++; + if (*pin_loc == *pin_size && *pin_len < *pin_max) { - diag->pin_loc = 5; - if (diag->pin_loc < diag->pin_size - (diag->pin_max + 1 - diag->pin_len)) - diag->pin_loc = diag->pin_size - (diag->pin_max + 1 - diag->pin_len); + *pin_loc = 5; + if (*pin_loc < *pin_size - (*pin_max + 1 - *pin_len)) + *pin_loc = *pin_size - (*pin_max + 1 - *pin_len); } } break; } - if (old_loc < diag->pin_loc) + if (pin) + pin[*pin_len] = 0; + + if (old_loc < *pin_loc) { - move (diag->pin_y, diag->pin_x + old_loc); - while (old_loc++ < diag->pin_loc) + move (*pin_y, *pin_x + old_loc); + while (old_loc++ < *pin_loc) addch ('*'); } - else if (old_loc > diag->pin_loc) + else if (old_loc > *pin_loc) { - move (diag->pin_y, diag->pin_x + diag->pin_loc); - while (old_loc-- > diag->pin_loc) + move (*pin_y, *pin_x + *pin_loc); + while (old_loc-- > *pin_loc) addch ('_'); } - move (diag->pin_y, diag->pin_x + diag->pin_loc); + move (*pin_y, *pin_x + *pin_loc); +} + +static int +test_repeat (dialog_t diag) +{ + if (!diag->pinentry->repeat_passphrase) + return 1; + + if (!diag->pinentry->pin && !diag->repeat_pin) + return 1; + + if ((diag->pinentry->pin && !*diag->pinentry->pin + && (!diag->repeat_pin || !*diag->repeat_pin))) + return 1; + + if (diag->repeat_pin && !*diag->repeat_pin + && (!diag->pinentry->pin || !*diag->pinentry->pin)) + return 1; + + if (diag->pinentry->pin && diag->repeat_pin + && !strcmp (diag->pinentry->pin, diag->repeat_pin)) + return 1; + + return 0; } static int @@ -957,9 +1086,15 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) switch (diag.pos) { case DIALOG_POS_OK: - if (diag.pinentry->pin) + if (diag.pinentry->repeat_passphrase) + dialog_switch_pos (&diag, DIALOG_POS_REPEAT_PIN); + else if (diag.pinentry->pin) dialog_switch_pos (&diag, DIALOG_POS_PIN); break; + case DIALOG_POS_REPEAT_PIN: + if (diag.pinentry->pin) + dialog_switch_pos (&diag, DIALOG_POS_PIN); + break; case DIALOG_POS_NOTOK: dialog_switch_pos (&diag, DIALOG_POS_OK); break; @@ -967,7 +1102,12 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) if (diag.notok) dialog_switch_pos (&diag, DIALOG_POS_NOTOK); else - dialog_switch_pos (&diag, DIALOG_POS_OK); + { + if (!test_repeat (&diag)) + dialog_switch_pos (&diag, DIALOG_POS_REPEAT_PIN); + else + dialog_switch_pos (&diag, DIALOG_POS_OK); + } break; default: break; @@ -979,8 +1119,17 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) switch (diag.pos) { case DIALOG_POS_PIN: - dialog_switch_pos (&diag, DIALOG_POS_OK); + if (diag.pinentry->repeat_passphrase) + dialog_switch_pos (&diag, DIALOG_POS_REPEAT_PIN); + else + dialog_switch_pos (&diag, DIALOG_POS_OK); break; + case DIALOG_POS_REPEAT_PIN: + if (test_repeat (&diag)) + dialog_switch_pos (&diag, DIALOG_POS_OK); + else + dialog_switch_pos (&diag, DIALOG_POS_CANCEL); + break; case DIALOG_POS_OK: if (diag.notok) dialog_switch_pos (&diag, DIALOG_POS_NOTOK); @@ -999,8 +1148,17 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) switch (diag.pos) { case DIALOG_POS_PIN: - dialog_switch_pos (&diag, DIALOG_POS_OK); + if (diag.pinentry->repeat_passphrase) + dialog_switch_pos (&diag, DIALOG_POS_REPEAT_PIN); + else + dialog_switch_pos (&diag, DIALOG_POS_OK); break; + case DIALOG_POS_REPEAT_PIN: + if (test_repeat (&diag)) + dialog_switch_pos (&diag, DIALOG_POS_OK); + else + dialog_switch_pos (&diag, DIALOG_POS_CANCEL); + break; case DIALOG_POS_OK: if (diag.notok) dialog_switch_pos (&diag, DIALOG_POS_NOTOK); @@ -1029,7 +1187,10 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) switch (diag.pos) { case DIALOG_POS_PIN: + case DIALOG_POS_REPEAT_PIN: case DIALOG_POS_OK: + if (!test_repeat (&diag)) + break; done = 1; break; case DIALOG_POS_NOTOK: @@ -1044,8 +1205,11 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) break; default: - if (diag.pos == DIALOG_POS_PIN) - dialog_input (&diag, alt, c); + if (diag.pos == DIALOG_POS_PIN || diag.pos == DIALOG_POS_REPEAT_PIN) + { + dialog_input (&diag, alt, c); + diag.pinentry->repeat_okay = test_repeat (&diag); + } } #ifndef HAVE_DOSISH_SYSTEM no_input = 0; @@ -1097,6 +1261,9 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) } } + if (diag.repeat_pin) + secmem_free (diag.repeat_pin); + if (done == -2) pinentry->canceled = 1; -- 2.8.1 From wk at gnupg.org Wed Aug 17 18:06:56 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Aug 2016 18:06:56 +0200 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] Message-ID: <87fuq3xtun.fsf@wheatstone.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of new Libgcrypt and GnuPG versions to *fix a critical security problem*. Felix D?rre and Vladimir Klebanov from the Karlsruhe Institute of Technology found a bug in the mixing functions of Libgcrypt's random number generator: An attacker who obtains 4640 bits from the RNG can trivially predict the next 160 bits of output. This bug exists since 1998 in all GnuPG and Libgcrypt versions. Impact ====== All Libgcrypt and GnuPG versions released before 2016-08-17 are affected on all platforms. A first analysis on the impact of this bug in GnuPG shows that existing RSA keys are not weakened. For DSA and Elgamal keys it is also unlikely that the private key can be predicted from other public information. This needs more research and I would suggest _not to_ overhasty revoke keys. Solution ======== If you are using a vendor supplied version of GnuPG or Libgcrypt: * Wait for an update from your vendor. If you are using a GnuPG-2 version (2.0.x or 2.1.x): * Update Libgcrypt. We have released these fixed versions of Libgcrypt: 1.7.3, 1.6.6, and 1.5.6. See below for download information. If you are using GnuPG-1 version (1.4.x): * Update as soon as possible to GnuPG 1.4.21. See below for download information. Support ======= For help on developing with GnuPG or Libgcrypt you should read the included manuals and ask on the appropriate mailing list [1,2]. A listing with commercial support offers for GnuPG and Libgcrypt and related software is available at the GnuPG web site [3]. Maintenance and development of GnuPG and Libgcrypt is mostly financed by donations; see . We need your donations to continue our work. Thanks ====== We like to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Thanks to Felix D?rre and Vladimir Klebanov for sending us a draft of their research paper and working with us on a solution. Also many thanks to all our donors [4]. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source tarballs and their digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.3.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.3.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.6.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.6.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.6.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.6.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.21.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.21.tar.bz2.sig These files are also available via HTTP: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.3.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.3.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.6.6.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.6.6.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.5.6.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.5.6.tar.bz2.sig https://gnupg.org/ftp/gcrypt/gnupg/gnupg-1.4.21.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-1.4.21.tar.bz2.sig Checking the Integrity ====================== In order to check that the version you downloaded is an original and unmodified file please follow the instructions found at . In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.7.4.tar.bz2 you would use this command: gpg --verify libgcrypt-1.7.4.tar.bz2.sig libgcrypt-1.7.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. - If you are not able to use GnuPG, you have to verify the SHA-1 checksum. For example: sha1sum libgcrypt-1.7.3.tar.bz2 and check that the output matches the first line from the this list: 5a034291e7248592605db448481478e6c963aa9c libgcrypt-1.7.3.tar.bz2 a05cba7037e6cbc68dcf3ea5b45f703b79fa234f libgcrypt-1.7.3.tar.gz ad79fd0b6963e1049612aa5d98e1a0b8eb775701 libgcrypt-1.6.6.tar.bz2 d11b6ca1d55eb12f5d3091a5169d874806007130 libgcrypt-1.6.6.tar.gz 62eade7cd3545efee1a87512d54f69151abbae47 libgcrypt-1.5.6.tar.bz2 8d3f55cce21e17f21d0c991cccf6bf52ec244353 libgcrypt-1.5.6.tar.gz e3bdb585026f752ae91360f45c28e76e4a15d338 gnupg-1.4.21.tar.bz2 97bfba0e4db7cb1a3458f73240481767cb7fe90e gnupg-1.4.21.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users 'at' gnupg.org mailing list. [1] https://lists.gnupg.org/mailman/listinfo/gnupg-devel [2] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel [3] https://www.gnupg.org/service.html [4] https://gnupg.org/donate/kudos.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 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 pgut001 at cs.auckland.ac.nz Thu Aug 18 13:38:53 2016 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 18 Aug 2016 11:38:53 +0000 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> References: <87fuq3xtun.fsf@wheatstone.g10code.de>, <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> [Redirected to gnupg-devel rather than gnupg-users because it seems more appropriate there] I wrote: >OK, I'm downloading an older source archive now, let's see if I can find the >flaw before Werner posts a reply :-) So I think I've managed to reverse-engineer what the code is doing (there are no code comments explaining it). It's not at all what I described in my PRNG paper, but I can't tell if that's an accident or by design because, well, there are no code comments. What the GnuPG code does is mix the next 64 bytes and then overwrite the preceding 20 bytes with the mixed output, however this doesn't propagate any entropy along through the buffer. Quoting the original paper: Assuming the use of MD5, which has a 64-byte input and 16-byte output, we would hash the 16+64 bytes at locations n-16... n+63 and then write the resulting 16-byte hash to locations n ... n+15 (the chaining which is performed explicitly by PGP is performed implicitly here by including the previously processed 16 bytes in the input to the hash function). We then move forward 16 bytes and repeat the process, wrapping the input around to the start of the buffer when the end of the buffer is reached. The overlapping of the data input to each hash means that each 16-byte block which is processed is influenced by all the surrounding bytes The GnuPG code however only hashes the next 64 bytes, and then uses the output to overwrite the current 20 bytes (it uses RMD160, not MD5, since it's a bit newer than the original paper). No state is carried along. Peter. From pgut001 at cs.auckland.ac.nz Thu Aug 18 15:07:35 2016 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 18 Aug 2016 13:07:35 +0000 Subject: [FORGED] Re: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] In-Reply-To: <16a19674-f90a-3e52-0ad1-3ca5ca49e902@sumptuouscapital.com> References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz>, <16a19674-f90a-3e52-0ad1-3ca5ca49e902@sumptuouscapital.com> Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF2EFD@uxcn10-5.UoA.auckland.ac.nz> Kristian Fiskerstrand writes: >Have you seen >http://formal.iti.kit.edu/~klebanov/pubs/libgcrypt-cve-2016-6313.pdf ? Ah, thanks. So that matches the problem I saw when I looked at the code (see my followup post). Experimental repeatability achieved :-). (OK, not quite, when I tried to sketch out what was going on I had the hole in the wrong place in my diagram, it's after the first 20 bytes, not right at the start). Peter. From kristian.fiskerstrand at sumptuouscapital.com Thu Aug 18 14:47:33 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 18 Aug 2016 14:47:33 +0200 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> Message-ID: <16a19674-f90a-3e52-0ad1-3ca5ca49e902@sumptuouscapital.com> On 08/18/2016 01:13 PM, Peter Gutmann wrote: > Werner Koch writes: > >> Felix D?rre and Vladimir Klebanov from the Karlsruhe Institute of Technology >> found a bug in the mixing functions of Libgcrypt's random number generator: >> An attacker who obtains 4640 bits from the RNG can trivially predict the next >> 160 bits of output. This bug exists since 1998 in all GnuPG and Libgcrypt >> versions. > > Are any more details on what the problem is available? This predates my Have you seen http://formal.iti.kit.edu/~klebanov/pubs/libgcrypt-cve-2016-6313.pdf ? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From aheinecke at intevation.de Thu Aug 18 17:29:26 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 18 Aug 2016 17:29:26 +0200 Subject: Suggestions for gpgme on mingw-w64 In-Reply-To: <87ziz36m39.fsf@vigenere.g10code.de> References: <87ziz36m39.fsf@vigenere.g10code.de> Message-ID: <3875162.TN20GWstMY@esus> Hi, Sorry to pull out such an old thread but I just ran into the same problem as I was trying to use GpgME statically linked into GpgOL. After wasting some time figuring out why every call returned "Unsupported Protocol" I figured out that this here was also my problem. On Wednesday 28 October 2015 16:37:14 Werner Koch wrote: > I just pushed > > bb600aa w32: Add new global flag "w32-inst-dir". Works great! Useful :-) Although I wondered a bit if we shouldn't try the same fallbacks that we use to find gpgconf to find gpgme-w32spawn.exe, too. This would also solve this problem I guess. > bb2d11c w32: Add extra diagnostic about possible missing > gpgme-w32spawn.exe > > I have not tested any of these changes, I would appreciate if you could > give it a try. Please let me know if you need a tarball. The extra diagnostic was a bit useless for me. First I had to start Outlook in an environment with GpgME debugging and then as spawnhelper was NULL it would print: GPGME 2016-08-18 15:55:41 <0x13b0> gpgme-dinfo: gpgconf='C:\Gpg4win\..\GnuPG\bin\gpgconf.exe' GPGME 2016-08-18 15:55:41 <0x13b0> _gpgme_io_pipe: enter: filedes=02A5E3AC, inherit_idx=1 (GPGME uses it for reading) GPGME 2016-08-18 15:55:41 <0x13b0> _gpgme_io_pipe: leave: read=0x0 (000025B0/0x0), write=0x1 (00002B3C/0x0) GPGME 2016-08-18 15:55:41 <0x13b0> _gpgme_io_spawn: enter: path=0B34B048, path=C:\Gpg4win\..\GnuPG\bin\gpgconf.exe GPGME 2016-08-18 15:55:41 <0x13b0> _gpgme_io_spawn: check: path=0B34B048, argv[ 0] = C:\Gpg4win\..\GnuPG\bin\gpgconf.exe GPGME 2016-08-18 15:55:41 <0x13b0> _gpgme_io_spawn: check: path=0B34B048, argv[ 1] = --list-dirs GPGME 2016-08-18 15:55:41 <0x13b0> _gpgme_io_spawn: check: path=0B34B048, tmp_name = C:\Users\AHEINE~1\AppData\Local\Temp\gpgme-zPTgnT GPGME 2016-08-18 15:55:41 <0x13b0> _gpgme_io_spawn: check: path=0B34B048, CreateProcess failed: ec=87 GPGME 2016-08-18 15:55:41 <0x13b0> _gpgme_io_spawn: check: path=0B34B048, (is '(null)' correctly installed?) No mention of gpgme-w32spawn.exe and all paths looked completely correct for my system. Very little difference in the output to the working case :-/ So instead I've now (9cf983b0) added a big fat MessageBox in that case: https://files.intevation.de/users/aheinecke/gpgme_spawn_not_found.png because I also don't find it intuitive that a library needs a binary to work and usually if I package a library I just package the library and omit any binaries that this library installs. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Aug 18 19:19:46 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Aug 2016 19:19:46 +0200 Subject: [Announce] GnuPG 2.1.15 released Message-ID: <8737m2ouz1.fsf@wheatstone.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.15. See below for a list of new features and bug fixes. 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. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) comes with the latest features and is suggested for most users. This announcement is about this branch. - GnuPG "stable" (2.0) is the currently mostly used branch which will be maintain until 2017-12-31. - GnuPG "classic" (1.4) is a simplified version of GnuPG, required on very old platforms or to decrypt data created with PGP-2 keys. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. Noteworthy changes in version 2.1.15 ==================================== * gpg: Remove the --tofu-db-format option and support for the split TOFU database. * gpg: Add option --sender to prepare for coming features. * gpg: Add option --input-size-hint to help progress indicators. * gpg: Extend the PROGRESS status line with the counted unit. * gpg: Avoid publishing the GnuPG version by default with --armor. * gpg: Properly ignore legacy keys in the keyring cache. * gpg: Always print fingerprint records in --with-colons mode. * gpg: Make sure that keygrips are printed for each subkey in --with-colons mode. * gpg: New import filter "drop-sig". * gpgsm: Fix a bug in the machine-readable key listing. * gpg,gpgsm: Block signals during keyring updates to limits the effects of a Ctrl-C at the wrong time. * g13: Add command --umount and other fixes for dm-crypt. * agent: Fix regression in SIGTERM handling. * agent: Cleanup of the ssh-agent code. * agent: Allow import of overly long keys. * scd: Fix problems with card removal. * dirmngr: Remove all code for running as a system service. * tools: Make gpg-wks-client conforming to the specs. * tests: Improve the output of the new regression test tool. * tests: Distribute the standalone test runner. * tests: Run each test in a clean environment. * Spelling and grammar fixes. A detailed description of the changes found in the 2.1 branch can be found at . Please be aware that there are still known bugs which we are working on. Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.15 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.15.tar.bz2 (5590k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.15.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.15.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.15.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.15_20160818.exe (3569k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.15_20160818.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.15_20160818.exe https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.15_20160818.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. This Windows installer comes with TOFU support, translations, and support for Tor; it is still missing HKPS support, though. This Windows installer also fixes the Libgcrypt bug we announced yesterday. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.15.tar.bz2 you would use this command: gpg --verify gnupg-2.1.15.tar.bz2.sig gnupg-2.1.15.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.1.15.tar.bz2, you run the command like this: sha1sum gnupg-2.1.15.tar.bz2 and check that the output matches the next line: 908c86dac8e9a1fbf47e1605e570b11391b04ece gnupg-2.1.15.tar.bz2 c13fdb4daa2a2c715d86365e6ab6c3b70506340e gnupg-w32-2.1.15_20160818.exe 6e23249ed44f06638e760e06ab9f80112a257913 gnupg-w32-2.1.15_20160818.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 (2161 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow our postings at and . Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . 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. Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project employs 3 full-time developers, one part-timer, and one contractor. They all work exclusivly on GnuPG and closely related software like Libgcrypt and GPA. Please consider to donate via: https://gnupg.org/donate/ Conference ========== The OpenPGP.conf starts in 3 weeks; if you like to attended do not hesitate to ask for a grant towards the participation fee. See https://openpgp-conf.org Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and donating money. For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. 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: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Aug 18 20:21:01 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Aug 2016 20:21:01 +0200 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Thu, 18 Aug 2016 11:38:53 +0000") References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> Message-ID: <87r39mndki.fsf@wheatstone.g10code.de> On Thu, 18 Aug 2016 13:38, pgut001 at cs.auckland.ac.nz said: > So I think I've managed to reverse-engineer what the code is doing (there are > no code comments explaining it). It's not at all what I described in my PRNG No need to reverse engineer the code. Well, unless you are looking at that 18 year old code from 1.4. Here is the description from Libgcrypt before the fix: * Mix the 600 byte pool. Note that the 64 byte scratch area directly * follows the pool. The numbers in the diagram give the number of * bytes. * <................600...............> <.64.> * pool |------------------------------------| |------| * <..44..> <20> * | | * | +-----+ * +-----------------------------------|--+ * v v * |------| * * | * +---------------------------------------+ * v * <20> * pool' |------------------------------------| * <20><20><..44..> * | | * | +------------------------------+ * +-------------------------------------+ | * v v * |------| * * | * +-----------------------------------+ * v * <20> * pool'' |------------------------------------| * <20><20><20><..44..> * | | * | +--------------------------+ * +---------------------------------+ | * v v * |------| * * * and so on until we did this for all 30 blocks. * * To better protect against implementation errors in this code, we * xor a digest of the entire pool into the pool before mixing. Earlier versions had the same comment but using a different markup; see end of the mail. I updated the comment while looking at the research paper. > there are no code comments. What the GnuPG code does is mix the next 64 bytes > and then overwrite the preceding 20 bytes with the mixed output, however this > doesn't propagate any entropy along through the buffer. Quoting the original We have 30 slots of 20 bytes and for each slot we take the previous 20 bytes and the next 44 bytes, hash them and put them into the current slot. Thus the state is carried along _except for the last slot_, which nobody figured out in the last 18 years. Despite several code audits, including one by an German random pope. Only a few weeks ago there was an audit and the guy who worked on this produced pretty diagrams showing the operation as they should be; i.e. derived from the code and not from the above comment. He didn't noticed the hole either and I looked at his documents only after I received the paper. > The GnuPG code however only hashes the next 64 bytes, and then uses the output > to overwrite the current 20 bytes (it uses RMD160, not MD5, since it's a bit > newer than the original paper). No state is carried along. Nope. We recently switched from RMD160 to SHA1 for other reasons but that does not matter. The reason why only 64 bytes are hashed is that it allows the use of the bare transform function. IIRC, old Cryptlib versions did the same but I guess you changed that to the full hash machinery in the course of your doctoral work. I _might_ have introduced the hole to mix in more bytes in each step. Or it was a plain bug. Here is the description for the fixed code: * <................600...............> <.64.> * pool |------------------------------------| |------| * <20><.24.> <20> * | | +-----+ * +-----|-------------------------------|-+ * +-------------------------------|-|-+ * v v v * |------| * * +---------------------------------------+ * v * <20> * pool' |------------------------------------| * <20><20><.24.> * +---|-----|---------------------------+ * +-----|---------------------------|-+ * +---------------------------|-|-+ * v v v * |------| * * | * +-----------------------------------+ * v * <20> * pool'' |------------------------------------| * <20><20><20><.24.> * +---|-----|-----------------------+ * +-----|-----------------------|-+ * +-----------------------|-|-+ * v v v * Salam-Shalom, Werner p.s. Here is the old comment on how the pool is mixed (libgcrypt 1.7.2) * Mix the pool: * * |........blocks*20byte........|20byte|..44byte..| * <..44byte..> <20byte> * | | * | +------+ * +---------------------------|----------+ * v v * |........blocks*20byte........|20byte|..44byte..| * <.....64bytes.....> * | * +----------------------------------+ * Hash * v * |.............................|20byte|..44byte..| * <20byte><20byte><..44byte..> * | | * | +---------------------+ * +-----------------------------+ | * v v * |.............................|20byte|..44byte..| * <.....64byte......> * | * +-------------------------+ * Hash * v * |.............................|20byte|..44byte..| * <20byte><20byte><..44byte..> -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From calestyo at scientia.net Fri Aug 19 01:44:36 2016 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 19 Aug 2016 01:44:36 +0200 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] In-Reply-To: <87r39mndki.fsf@wheatstone.g10code.de> References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> <87r39mndki.fsf@wheatstone.g10code.de> Message-ID: <1471563876.8408.3.camel@scientia.net> Hey. Is more information respectively an in-depth-analysis already available on how this issue might have impacted security of all types of keys/etc. pp.? I mean many (many many) things rely on gnupg for their security, just take things like secure APT in Debian. Is it already for certain that no further actions are needed by all these communities? Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5930 bytes Desc: not available URL: From pgut001 at cs.auckland.ac.nz Fri Aug 19 14:08:01 2016 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri, 19 Aug 2016 12:08:01 +0000 Subject: [Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316] In-Reply-To: <87r39mndki.fsf@wheatstone.g10code.de> References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz>, <87r39mndki.fsf@wheatstone.g10code.de> Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF4129@uxcn10-5.UoA.auckland.ac.nz> Werner Koch writes: >No need to reverse engineer the code. Well, unless you are looking at that >18 year old code from 1.4. Here is the description from Libgcrypt before the >fix: Ah, I was looking at cipher/random.c, for which the sole comment is /* loop over the pool */. >The reason why only 64 bytes are hashed is that it allows the use of the bare >transform function. IIRC, old Cryptlib versions did the same but I guess you >changed that to the full hash machinery in the course of your doctoral work. Yeah, the last time the raw hash was used was in the 2002 release, since then the code has used the high-level interface because calling into a low-level internal function isn't very portable, and it makes the result harder to analyse. So now I explicitly hash $hashsize + 64 bytes, $hashsize bytes before the current position for chaining and 64 bytes after. Peter. From wk at gnupg.org Fri Aug 19 14:46:55 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Aug 2016 14:46:55 +0200 Subject: RNG bug in GnuPG/Libgcrypt In-Reply-To: <1471563876.8408.3.camel@scientia.net> (Christoph Anton Mitterer's message of "Fri, 19 Aug 2016 01:44:36 +0200") References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> <87r39mndki.fsf@wheatstone.g10code.de> <1471563876.8408.3.camel@scientia.net> Message-ID: <87lgztj58g.fsf_-_@wheatstone.g10code.de> On Fri, 19 Aug 2016 01:44, calestyo at scientia.net said: > Is more information respectively an in-depth-analysis already available > on how this issue might have impacted security of all types of > keys/etc. pp.? I tried to analyze the impact in key generation and I am pretty sure that RSA keys generated with GnuPG < 2.1 are not affected. The reasons are: For GnuPG < 2.1 the state of the pool is not preserved over gpg invocations. A single gpg process creates at max two keys. The default is to create two 2048 bit RSA keys. A single 2048 bit RSA key requires 256 byte of random. I instrumented the RNG code of Libgcrypt 1.7.3 and with this if (getenv ("DBG_GCRYPT")) log_info ("#RNG(%lu) stats: bytes: %lu (%lu + %lu) (%lu + %lu) #\n", (unsigned long)getpid (), rndstats.getbytes1 + rndstats.getbytes2, rndstats.getbytes1, rndstats.getbytes2, rndstats.ngetbytes1, rndstats.ngetbytes2); and started 1) a default key generation with GnuPG 2.0.30-beta to create two 2048 bit RSA keys: #RNG(14052) stats: bytes: 8 (8 + 0) (1 + 0) # 8 bytes read from the pool for the salting the passphrase. #RNG(14052) stats: bytes: 136 (8 + 128) (1 + 1) # 128 bytes extracted to find the first RSA prime for the primary key #RNG(14052) stats: bytes: 144 (16 + 128) (2 + 1) # 8 bytes read from the pool to seed Libgcrypt's nonce generator. #RNG(14052) stats: bytes: 272 (16 + 256) (2 + 2) # 128 bytes extracted to find the second RSA prime for the primary key gpg: writing self signature #RNG(14052) stats: bytes: 400 (16 + 384) (2 + 3) # 128 bytes extracted to find the first RSA prime for the subkey #RNG(14052) stats: bytes: 528 (16 + 512) (2 + 4) # 128 bytes extracted to find the second RSA prime for the subkey Thus we extracted 528 bytes in total; we didn't even extract the dangerous bytes 580..599. 2) Now let's create two 4096 bit keys: #RNG(14384) stats: bytes: 8 (8 + 0) (1 + 0) # 8 bytes read from the pool for the salting the passphrase. #RNG(14384) stats: bytes: 264 (8 + 256) (1 + 1) # 256 bytes extracted to find the first RSA prime for the primary key #RNG(14384) stats: bytes: 272 (16 + 256) (2 + 1) # 8 bytes read from the pool to seed Libgcrypt's nonce generator. #RNG(14384) stats: bytes: 528 (16 + 512) (2 + 2) # 256 bytes extracted to find the second RSA prime for the primary key #RNG(14384) stats: bytes: 784 (16 + 768) (2 + 3) # 256 bytes extracted to find the first RSA prime for the subkey. Now this is interesting. This prime has been taken from bytes 528..599 and 0..183 including the dangerous range from 580 to 599. However, we are pretty safe because almost the entire range is part of the secret prime: To predict bytes 580..599 an attacker needs to know the bytes in the range 0..44 and 560..579. From these bytes 0..7 are available as the salt used to protect the _secret key_; thus only 64 of 2048 bit. Even if that would help to guess the prime, an attacker arriving at that point could more easily guess the passphrase. #RNG(14384) stats: bytes: 1040 (16 + 1024) (2 + 4) # 256 bytes extracted to find the second RSA prime for the subkey. These random bytes are taken from bytes 184..439. Thus entirely safe. More analysis is required for other key types, but we can see that generated RSA keys are not really affected. For GnuPG 2.1 things are different because there is a long running process (gpg-agent) which creates all keys. The case for RSA keys is similar for above and large keys should never be in danger. This is a pretty short answer but I hope it clarifies the common use cases. Again, please to not revoke your keys before we have hard facts that there might be a real problem for DSA, Elgamal or ECC keys. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From astieger at suse.com Fri Aug 19 23:17:48 2016 From: astieger at suse.com (Andreas Stieger) Date: Fri, 19 Aug 2016 23:17:48 +0200 Subject: fix a void return in a non-void function Message-ID: <0c366bd0-2f35-d66c-54e8-fecdbb56e6a6@suse.com> Hello, the attached patch fixes a void return in a non-void function that was new in 2.1.15 and was apparently introduced in 14479e2. Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-common-Follow-up-to-14479e2-fix-void-return-in-non-v.patch Type: text/x-patch Size: 723 bytes Desc: not available URL: From calestyo at scientia.net Sat Aug 20 03:20:40 2016 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 20 Aug 2016 03:20:40 +0200 Subject: RNG bug in GnuPG/Libgcrypt In-Reply-To: <87lgztj58g.fsf_-_@wheatstone.g10code.de> References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> <87r39mndki.fsf@wheatstone.g10code.de> <1471563876.8408.3.camel@scientia.net> <87lgztj58g.fsf_-_@wheatstone.g10code.de> Message-ID: <1471656040.12474.2.camel@scientia.net> Thanks for the update :) I guess people should be also confirmed whether the main use cases (signing/encrypting) could be anyhow affected, and also whether 3rd party programs using libgcrypt need to do their own analysis on whether their stuff could be affected or not. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5930 bytes Desc: not available URL: From wk at gnupg.org Sat Aug 20 10:04:04 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Aug 2016 10:04:04 +0200 Subject: RNG bug in GnuPG/Libgcrypt In-Reply-To: <1471656040.12474.2.camel@scientia.net> (Christoph Anton Mitterer's message of "Sat, 20 Aug 2016 03:20:40 +0200") References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> <87r39mndki.fsf@wheatstone.g10code.de> <1471563876.8408.3.camel@scientia.net> <87lgztj58g.fsf_-_@wheatstone.g10code.de> <1471656040.12474.2.camel@scientia.net> Message-ID: <87zio7hnnv.fsf@wheatstone.g10code.de> On Sat, 20 Aug 2016 03:20, calestyo at scientia.net said: > I guess people should be also confirmed whether the main use cases > (signing/encrypting) could be anyhow affected, and also whether 3rd Let's see by encrypting to 4 keys (1 4k and 3 2k RSA keys) #RNG(11973) stats: bytes: 32 (32 + 0) (1 + 0) # The session key. #RNG(11973) stats: bytes: 506 (506 + 0) (2 + 0) # 474 bytes for the RSA padding of a 4096 bit key. #RNG(11973) stats: bytes: 514 (514 + 0) (3 + 0) # 5 extra bytes to replace the zero bytes in the padding. gpg: RSA/AES256 encrypted for: "3C1CFCC2 test 4096" #RNG(11973) stats: bytes: 732 (732 + 0) (4 + 0) # 218 bytes for the RSA padding of a 2048 bit key. gpg: RSA/AES256 encrypted for: "0C8AAAF8 zzzzzzzzzzzzzzzzzzzzzzzzzzz" #RNG(11973) stats: bytes: 950 (950 + 0) (5 + 0) # #RNG(11973) stats: bytes: 954 (954 + 0) (6 + 0) # 218 + 4 bytes for the RSA padding of a 2048 bit key. gpg: RSA/AES256 encrypted for: "0E443FF2 yyyyyyyyyyyyyyyyyyyyyyyyyyy" #RNG(11973) stats: bytes: 1172 (1172 + 0) (7 + 0) # 218 bytes for the RSA padding of a 2048 bit key. gpg: RSA/AES256 encrypted for: "D44EF6F6 xxxxxxxxxxxxxxxxxxxxxxxxxxx" #RNG(11973) stats: bytes: 1188 (1188 + 0) (8 + 0) # 16 bytes for the IV. Now, if two recipients work together they can predict 20 bytes of the padding used for another key. I doubt that 20 known bytes out of 218 of the padding puts the message in danger - in particilar not because they all received the same message. More important is the case where we sign and an encrypt a message. Let's do that by sending a 2048 bit key signed message to a 4096 bit key: #RNG(12472) stats: bytes: 32 (32 + 0) (1 + 0) # The session key. #RNG(12472) stats: bytes: 506 (506 + 0) (2 + 0) # 474 bytes for the padding. gpg: RSA/AES256 encrypted for: "3C1CFCC2 test 4096" #RNG(12472) stats: bytes: 514 (514 + 0) (3 + 0) # 8 bytes to initialize the nonce generator used for RSA blinding. gpg: RSA/SHA256 signature from: "72E20749 zzzzzzzzzzzzzzzzzzzzzzzzzzz" #RNG(12472) stats: bytes: 530 (530 + 0) (4 + 0) # 16 bytes for the IV. We do not access bytes 580..599. Even if we would do no sensitive data is leaked: As described above the padding is not relevant. The RSA blinding does not require stroing random and that random number is not leaked anyway. The IV does not matter because it is the same for all recipients. > party programs using libgcrypt need to do their own analysis on whether > their stuff could be affected or not. Yes. For example if an application sends a random challenge of 20 bytes using the real RNG and not the nonce generator to 30 recipients, recipient 1,3, and 29 are able to reconstruct the challenge sent to 30. This needs to be done in one process. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Sat Aug 20 11:34:41 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Aug 2016 11:34:41 +0200 Subject: RNG bug in GnuPG/Libgcrypt In-Reply-To: <87lgztj58g.fsf_-_@wheatstone.g10code.de> (Werner Koch's message of "Fri, 19 Aug 2016 14:46:55 +0200") References: <87fuq3xtun.fsf@wheatstone.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4CF2D80@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF2DCA@uxcn10-5.UoA.auckland.ac.nz> <87r39mndki.fsf@wheatstone.g10code.de> <1471563876.8408.3.camel@scientia.net> <87lgztj58g.fsf_-_@wheatstone.g10code.de> Message-ID: <87r39jhjgu.fsf@wheatstone.g10code.de> Hi, Let's see how DSA and Elgamal keys are impacted by the RNG bug in GnuPG 2 (but not in GnuPG 1.4). Here is how random is used for the former default of 2048 bit DSA + Elgamal key. #RNG(12952) stats: bytes: 8 (8 + 0) (1 + 0) # 8 bytes for the passphrase protection salt. #RNG(12952) stats: bytes: 16 (16 + 0) (2 + 0) # 8 bytes to initialize the nonce generator (triggered by the Rabin-Miller prime test) #RNG(12952) stats: bytes: 48 (16 + 32) (2 + 1) # 32 bytes for the DSA secret parameter x. #RNG(12952) stats: bytes: 80 (48 + 32) (3 + 1) # 32 bytes for the DSA parameter k to test the key. gpg: writing self signature #RNG(12952) stats: bytes: 112 (80 + 32) (4 + 1) # 32 bytes for the DSA parameter k to create the self-signature. gpg: DSA/SHA256 signature from: "E2EA1593 [?]" #RNG(12952) stats: bytes: 155 (80 + 75) (4 + 2) # 43 bytes for the Elgamal secret parameter x. #RNG(12952) stats: bytes: 198 (123 + 75) (5 + 2) # 43 bytes for the Elgamal parameter k to test the key. #RNG(12952) stats: bytes: 454 (379 + 75) (6 + 2) # 256 bytes for the Elgamal parameter k to test the key. gpg: writing key binding signature #RNG(12952) stats: bytes: 486 (411 + 75) (7 + 2) # 32 bytes for the DSA parameter k to create the key binding signature of the public key gpg: writing key binding signature #RNG(12952) stats: bytes: 518 (443 + 75) (8 + 2) # 32 bytes for the DSA parameter k to create the key binding signature of the secret key Thus we have not reached the critical bytes 580..599. So we are safe for the defaults. Further, the secret parameters x for both keys are created early enough to never get created from the critical bytes, even with 3072 DSA and 4096 Elgamal keys. My original doubts where based on the idea that the public primes for DSA and Elgamal are created from the regular RNG. However, with Libgcrypt 1.3 (2007) this was changed to use the nonce generator. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From bernhard at intevation.de Tue Aug 23 13:16:22 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 23 Aug 2016 13:16:22 +0200 Subject: contract "gpg4all": studies published (in German) In-Reply-To: <201511111148.36162.bernhard@intevation.de> References: <201504171106.56223.bernhard@intevation.de> <201510120912.47383.bernhard@intevation.de> <201511111148.36162.bernhard@intevation.de> Message-ID: <201608231316.27601.bernhard@intevation.de> Hi! The BSI published two studies about how to technically improve OpenPGP implementations for web and Android. The PDFs are in German, linked from the https://wiki.gnupg.org/Gpg4all2015 contract page. We appreciate your feedback! (Please chose only one mailinglist to reply to this email. :)) Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From gnupg-devel at spodhuis.org Thu Aug 25 04:51:29 2016 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Wed, 24 Aug 2016 22:51:29 -0400 Subject: Some PKA notes Message-ID: <20160825025129.GA20007@breadbox> Further to Werner's work on the new-style PKA records, as announced at: https://lists.gnupg.org/pipermail/gnupg-devel/2015-February/029544.html I did some debugging to get this working for me; here are some notes, which might be useful for feeding back into documentation or FAQs. Also a Python script, attached and as a GitHub gist. I initially added to DNS zones I control records from output of: gpg2.1 --export-options export-minimal,export-pka \ --export 0x4D1E900E14C1CC04 In the spodhuis.org zone, I've now updated these, per the below. The DNS records from that look like: $ORIGIN _pka.spodhuis.org. r6thk89hkz9zsaiqecoquhaucjatbz3o TYPE37 \# 26 0006 0000 00 14 ACBB4324393ADE3515DA2DDA4D1E900E14C1CC04 Testing with: $ export GNUPGHOME=$(mktemp -dt gpg.XXXXXXXXX) $ echo foo | gpg -v --auto-key-locate pka -r pdp at spodhuis.org -ea gpg: auto-key-locate found fingerprint ACBB4324393ADE3515DA2DDA4D1E900E14C1CC04 gpg: error retrieving 'pdp at spodhuis.org' via PKA: No public key gpg: pdp at spodhuis.org: skipped: No public key gpg: [stdin]: encryption failed: No public key Specifying an explicit keyserver on the command-line failed too. The DNS records are actually classic CERT records of type 6 (IPGP); I had these already, just not in _pka and for the unencoded LHS; skimming GnuPG source showed that the URL was being returned from the DNS parsing function. So I tried copying my existing DNS records into place and giving them the right name; the records length-prefix the fingerprint and any data after that is a URL to get the content from. I was using . gpg: requesting key 4D1E900E14C1CC04 from https server www.security.spodhuis.org gpg: error retrieving 'pdp at spodhuis.org' via PKA: General error Fix: grep '^hkp-cacert' ~/.gnupg/dirmngr.conf >| $GNUPGHOME/dirmngr.conf gpgconf --kill dirmngr But there was still an error (which I can't find in scrollback, sorry). Turning up dirmngr logging levels revealed that the URL returned was being massaged into an HKP URL: error accessing 'https://www.security.spodhuis.org:443/pks/lookup?op=get&options=mr&search=0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04': http status 404 So I switched to specifying my SKS keyserver: % echo foo | gpg -v --auto-key-locate pka -r pdp at spodhuis.org -ea gpg: no running Dirmngr - starting '/usr/local/bin/dirmngr' gpg: waiting for the dirmngr to come up ... (5s) gpg: connection to the dirmngr established gpg: requesting key 4D1E900E14C1CC04 from https server sks.spodhuis.org gpg: data source: https://sks.spodhuis.org:443 gpg: armor header: Version: SKS 1.1.5 gpg: armor header: Comment: Hostname: sks.spodhuis.org gpg: pub rsa4096/4D1E900E14C1CC04 2013-10-22 Phil Pennock gpg: /home/pdp/tmp/gpg.XXXXXXXXX.Am0UHa5O/trustdb.gpg: trustdb created gpg: using pgp trust model gpg: key 4D1E900E14C1CC04: public key "Phil Pennock " imported gpg: no running gpg-agent - starting '/usr/local/bin/gpg-agent' gpg: waiting for the agent to come up ... (5s) gpg: connection to agent established gpg: 0 keys processed (0 validity counts cleared) gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 gpg: auto-key-locate found fingerprint ACBB4324393ADE3515DA2DDA4D1E900E14C1CC04 gpg: using subkey A445DC2B1C5B7F39 instead of primary key 4D1E900E14C1CC04 gpg: automatically retrieved 'pdp at spodhuis.org' via PKA gpg: A445DC2B1C5B7F39: There is no assurance this key belongs to the named user sub rsa4096/A445DC2B1C5B7F39 2013-10-22 Phil Pennock Primary key fingerprint: ACBB 4324 393A DE35 15DA 2DDA 4D1E 900E 14C1 CC04 Subkey fingerprint: A689 CBD8 637B 57F2 B46B 7F53 A445 DC2B 1C5B 7F39 Success! Other notes: * The RR-name is encoded with Zooko-base32 encoding * The zbase32 Python module does not support Python3, so the attached script is Python2 instead * The payload in CERT form is given as base64-encoded data r6thk89hkz9zsaiqecoquhaucjatbz3o IN CERT 6 0 0 FKy7QyQ5Ot41Fdot2k0ekA4UwcwEaHR0cHM6Ly9za3Muc3BvZGh1aXMub3Jn 96bqcjktdxra6hd6mor16dn1huc49irf IN CERT 6 0 0 FKy7QyQ5Ot41Fdot2k0ekA4UwcwEaHR0cHM6Ly9za3Muc3BvZGh1aXMub3Jn The attached script is Python 2 (only tested with 2.7.12), requires `pip install attrs zbase32` and can be found in a Gist for retrieval at: https://gist.github.com/philpennock/30d030b6d1d0d86603febdabd98a1313 Invoked as: ./pka.py -k https://sks.spodhuis.org $pgp_key_main gives output modelled after that from `gpg --export-options export-pka` in CERT form, not TYPE37, skipping only the display-name (laziness in what data I schlep around) but including the URL. Skip the `-k $keyserver` and the non-comment output should match on-the-wire that from gpg. Regards, -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: pka.py Type: text/x-python Size: 3272 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From steve at gpgtools.org Thu Aug 25 11:31:44 2016 From: steve at gpgtools.org (steve (GPGTools)) Date: Thu, 25 Aug 2016 11:31:44 +0200 Subject: Problems creating keys since upgrade to Libgcrypt 1.7.x Message-ID: Dear all, sending this to gnupg-devel feel free to forward / copy to gcrypt-devel. Since we've upgraded the libgcrypt distributed in MacGPG 2.0.30 to 1.7 from 1.6.5, we've received different user reports which state that sometimes creating their first key fails for them. GnuPG simply aborts with error code 99 (cancelled) We're calling gnupg with the following options: --no-greeting --no-tty --with-colons --fixed-list-mode --utf8-strings --display-charset utf-8 --enable-special-filenames --yes --output - --status-fd 3 --batch --passphrase-fd 6 --gen-key --no-armor --no-textmode --no-emit-version -- -&5 We've managed to reproduce the problem consistently on one of our machines by following these steps: - Remove .gnupg folder - Create new key pair (using GPG Keychain on Mac) First attempt fails, second works. On a second computer we've only managed to reproduce the bug some of the time. As mentioned before, reverting libgcrypt to 1.6.x solves the problem. We were wondering if you Werner or others have any idea what changes from 1.6.5 (we have yet to try 1.6.6) to 1.7 might be related to the described bug. 1.7.0 and 1.7.3 have been tested with the same results. Best, steve and team GPGTools -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From wk at gnupg.org Mon Aug 29 09:00:17 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Aug 2016 09:00:17 +0200 Subject: Problems creating keys since upgrade to Libgcrypt 1.7.x In-Reply-To: (steve@gpgtools.org's message of "Thu, 25 Aug 2016 11:31:44 +0200") References: Message-ID: <87vaykdpq6.fsf@wheatstone.g10code.de> On Thu, 25 Aug 2016 11:31, steve at gpgtools.org said: > Since we've upgraded the libgcrypt distributed in MacGPG 2.0.30 to 1.7 Is Macgpg 2.0.30 a stock gnupg 2.0.30? Which library versions are you using? > On a second computer we've only managed to reproduce the bug some of the time. > Please try to figure out how these machines differ. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Mon Aug 29 12:14:57 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Aug 2016 12:14:57 +0200 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <87twepzr74.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Aug 2016 16:07:43 -0400") References: <87twepzr74.fsf@alice.fifthhorseman.net> Message-ID: <878tvfeva6.fsf@wheatstone.g10code.de> On Fri, 12 Aug 2016 22:07, dkg at fifthhorseman.net said: > I see this advice is in doc/tools.texi, but i don't see it used often. > 'S.log' for GnuPG doesn't show up anywhere else in debian, for example: I added remarks to the man page and also implement log-file socket:// to print to a socket named S.log in GnuPG socket directory. >> How do you convey the envvars to gpg-agent? What systemd does is >> different from what gpg will do; for example the default tty, DISPLAY, >> and locale may be different. gpg will also pass --homedir to the >> invocation of gpg-agent if gpg has been started this way. > > gpg conveys envvars to gpg-agent during its use. This is what allows us > to run a single daemon that responds to requests from multiple > concurrent sessions, right? For the use with screen(1) gpg-agent allows to fix some environment variables to those used at startup (keep-tty and keep-display). > projects. :) Even aside from the system service, there's still a lot of > Win32-specific code, though. This is not meant as a critique -- i think Removed with the last released. Thanks for the reminder. >> For dirmngr this is not a good idea because we plan to add background >> tasks (parcimonie). > > I'd be a little surprised if most people expected a parcimonie-style > updater to run (and update their keyring, etc) when they weren't Others already reponded to this. > problem). It would still leave sessions open in the background for > several minutes after logout in some common use cases, but it would be > far better than having live code running indefinitely. I guess that most users don't log out but hibernate their session. > I'm assuming this would be a new configuration option for gpg-agent. > Maybe --terminate-after-idle ? What should it default to? I can send I do not think that it is important enough to rush this in. Let's track it as issue2450. > System-wide overviews and standardized tooling ("do one thing and do it > well") aren't unix-like? We should probably change that ;) But Yes, it is similar to unix in the same way VMS POSIX subsystem is similar to Unix. But let's not get into this again. I can't fight windmills. > In particular, the ssh-agent model assumes one agent *per X11 session*, > and gpg-agent assumes one agent *per user*. If the agent's The ssh-agent has no such assumption; you can run several ssh agents on your X11 server and session. it is jut a matter on how the distro starts ssh-agent. GnuPG changed with --enable-standard-socket in 2.0 and made that the only option in 2.1. > However we solve those problems, having process supervision and socket > activation still seem like good things, so i'd still like these patches > to be considered by upstream GnuPG. I don't think they break any I will look at them in detail soon. I would however like a more generalized approach using options like --listing-socket-foo and nothing systemd specific. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From neal at walfield.org Mon Aug 29 13:22:52 2016 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 29 Aug 2016 13:22:52 +0200 Subject: gpg: unhelpful messages? Message-ID: <87shtnn7jn.wl-neal@walfield.org> Hi, While doing some unrelated development / testing, it occured to me that the following message is rather misleading: # gpg --verify FILE gpg: Signature made Wed 24 Aug 2016 01:49:53 PM CEST gpg: using RSA key 7223B56678E02528 gpg: Good signature from "Neal H. Walfield " [unknown] gpg: aka "Neal H. Walfield " [unknown] gpg: aka "Neal H. Walfield " [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: 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 Subkey fingerprint: C03F A641 1B03 AE12 5764 6118 7223 B566 78E0 2528 I think there are two problems with the above message. First, gpg says: "Good signature from USERID". The good signature is from the key, not the user id. Anyone can create a key and specify any user id that she wants. Only if the USERID / KEY binding has been somehow verified should we say Good signature. Otherwise, we should say something along the lines of: Good signature from KEY allegedly controlled by USERID [unknown] or the slightly shorter: Good signature from KEY with the moniker USERID [unknown] These are more accurate and only slightly more verbose than the status quo. Now, it is true that there is warning, which contradicts the previous text, but understanding it requires understanding what a "trusted signature" is. I think anyone who understands what a trusted signature is also understands what "good signature ... [unknown]" means and hence the warning is completely useless. Second, the warning says: "There is no indication that the signature belongs to the owner." Whereas my previous critique is based on the reliance on jargon, this phrase is just technically false. If the signature is valid, then it definitely belongs to the owner. The question is whether the owner is actually who the user thinks she is. I mentioned these issues to Werner on gnupg-devel and he said: 1. People complain about the TOFU messages being too verbose. 2. No one has complained about the above messages in the past 25 years. 3. gpg is just for geeks and as just the interface can use lots of jargon and users can be expected to look up these terms. I agree with #1 and would like to find a UX person to help communicate the problem more succinctly, but disagree with #2 and #3. I'm curious to what degree others agree or disagree with the above. I personally think it is worth investing some time to improve gpg's command line UI even if it is only for geeks, particularly because it is the geeks who implement the other UIs and take cues from gpg's UI. :) Neal From dkg at fifthhorseman.net Mon Aug 29 16:56:16 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 29 Aug 2016 10:56:16 -0400 Subject: [STABLE-BRANCH-1-4 PATCH] tools: Fix option parsing for gpg-zip. Message-ID: <20160829145616.8916-1-dkg@fifthhorseman.net> From: "Neal H. Walfield" * tools/gpg-zip.in: Correctly set GPG when --gpg is specified. Correctly set TAR when --tar is specified. Pass TAR_ARGS to tar. (cherry-picked by dkg from master branch's 84ebf15b06e435453b2f58775f97a3a1c61a7e55) -- Signed-off-by: Neal H. Walfield Co-authored-by: Michael M?nch GnuPG-bug-id 1351 GnuPG-bug-id 1442 --- tools/gpg-zip.in | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/gpg-zip.in b/tools/gpg-zip.in index d27b1f9..a6b4238 100644 --- a/tools/gpg-zip.in +++ b/tools/gpg-zip.in @@ -94,7 +94,8 @@ while test $# -gt 0 ; do exit 0 ;; --gpg) - GPG=$1 + GPG=$2 + shift shift ;; --gpg-args) @@ -103,7 +104,8 @@ while test $# -gt 0 ; do shift ;; --tar) - TAR=$1 + TAR=$2 + shift shift ;; --tar-args) @@ -126,8 +128,8 @@ while test $# -gt 0 ; do done if test x$create = xyes ; then -# echo "$TAR -cf - "$@" | $GPG --set-filename x.tar $gpg_args" 1>&2 - $TAR -cf - "$@" | $GPG --set-filename x.tar $gpg_args +# echo "$TAR $tar_args -cf - "$@" | $GPG --set-filename x.tar $gpg_args" 1>&2 + $TAR $tar_args -cf - "$@" | $GPG --set-filename x.tar $gpg_args elif test x$list = xyes ; then # echo "cat \"$1\" | $GPG $gpg_args | $TAR $tar_args -tf -" 1>&2 cat "$1" | $GPG $gpg_args | $TAR $tar_args -tf - -- 2.9.3 From dkg at fifthhorseman.net Mon Aug 29 16:36:33 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 29 Aug 2016 10:36:33 -0400 Subject: [STABLE-BRANCH-1-4 PATCH] spelling: correct achived to achieved Message-ID: <20160829143633.15270-1-dkg@fifthhorseman.net> Signed-off-by: Daniel Kahn Gillmor --- THOUGHTS | 2 +- doc/gpg.texi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/THOUGHTS b/THOUGHTS index 25707c4..aba9402 100644 --- a/THOUGHTS +++ b/THOUGHTS @@ -90,7 +90,7 @@ extension mechanisms in GPG should be enough to try various ways later on. 1) pass an argument string to loadable extension modules (maybe gpg --load-extension foofish=arg1,arg2,arg3 ?) - --> could also be achived by S-Exps + --> could also be achieved by S-Exps 2) allow multiple instances of the same extension module (presumably with different arguments) diff --git a/doc/gpg.texi b/doc/gpg.texi index 12a6d60..e9935c3 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -1894,7 +1894,7 @@ opposite meaning. The options are: a formerly deleted key does not automatically gain an ownertrust values merely due to import. On the other hand it is sometimes necessary to re-import a trusted set of keys again but keeping - already assigned ownertrust values. This can be achived by using + already assigned ownertrust values. This can be achieved by using this option. @item repair-pks-subkey-bug -- 2.9.3 From dkg at fifthhorseman.net Tue Aug 30 01:55:48 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 29 Aug 2016 19:55:48 -0400 Subject: [PINENTRY PATCH] gnome3: drop unnecessary use of gtk Message-ID: <20160829235548.17173-1-dkg@fifthhorseman.net> * configure.ac: pinentry-gnome3 only needs gcr-base, not gcr. * gnome3/pinentry-gnome3.c (main): instead of testing whether GTK can be loaded, check for DBUS_SESSION_BUS_ADDRESS pinentry-gnome3 really just uses gcr and libsecret -- there is no direct use of gtk at all. By linking only to the minimal gcr-base-3 and avoiding gcr-3 itself, we remove many unnecessary library dependencies from pinentry-gnome3. Specifically, "ldd $(which pinentry-gnome3) | wc -l" goes from 69 to 23 on debian testing. Signed-off-by: Daniel Kahn Gillmor --- configure.ac | 8 ++++---- gnome3/pinentry-gnome3.c | 12 ++++-------- 2 files changed, 8 insertions(+), 12 deletions(-) diff --git a/configure.ac b/configure.ac index 41e9d93..1620ebd 100644 --- a/configure.ac +++ b/configure.ac @@ -476,15 +476,15 @@ AM_CONDITIONAL(BUILD_PINENTRY_GTK_2, test "$pinentry_gtk_2" = "yes") if test "$pinentry_gnome_3" != "no"; then AC_MSG_CHECKING([for gcr]) - "${PKG_CONFIG}" --exists gcr-3,gcr-base-3 + "${PKG_CONFIG}" --exists gcr-base-3 if test $? -ne 0 ; then AC_MSG_RESULT([no]) - AC_MSG_WARN([pkg-config could not find the module gcr-3,gcr-base-3]) + AC_MSG_WARN([pkg-config could not find the module gcr-base-3]) pinentry_gnome_3=no else AC_MSG_RESULT([yes]) - GNOME3CFLAGS=`"${PKG_CONFIG}" --cflags gcr-3,gcr-base-3` - GNOME3LIBS=`"${PKG_CONFIG}" --libs gcr-3,gcr-base-3` + GNOME3CFLAGS=`"${PKG_CONFIG}" --cflags gcr-base-3` + GNOME3LIBS=`"${PKG_CONFIG}" --libs gcr-base-3` AC_SUBST(GNOME3CFLAGS) AC_SUBST(GNOME3LIBS) AC_DEFINE(GCR_API_SUBJECT_TO_CHANGE, 1, [Nod nod]) diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c index 8f91cb8..adf1062 100644 --- a/gnome3/pinentry-gnome3.c +++ b/gnome3/pinentry-gnome3.c @@ -22,10 +22,10 @@ # include "config.h" #endif -#include #include #include +#include #include @@ -261,15 +261,11 @@ main (int argc, char *argv[]) pinentry_init (PGMNAME); #ifdef FALLBACK_CURSES - if (pinentry_have_display (argc, argv)) + if (!getenv ("DBUS_SESSION_BUS_ADDRESS")) { - if (! gtk_init_check (&argc, &argv)) - pinentry_cmd_handler = curses_cmd_handler; + fprintf (stderr, "No $DBUS_SESSION_BUS_ADDRESS found, falling back to curses\n"); + pinentry_cmd_handler = curses_cmd_handler; } - else - pinentry_cmd_handler = curses_cmd_handler; -#else - gtk_init (&argc, &argv); #endif pinentry_parse_opts (argc, argv); -- 2.9.3 From dkg at fifthhorseman.net Tue Aug 30 02:37:50 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 29 Aug 2016 20:37:50 -0400 Subject: gpg: unhelpful messages? In-Reply-To: <87shtnn7jn.wl-neal@walfield.org> References: <87shtnn7jn.wl-neal@walfield.org> Message-ID: <8737ln2ish.fsf@alice.fifthhorseman.net> Thanks for raising this, Neal! On Mon 2016-08-29 07:22:52 -0400, Neal H. Walfield wrote: > While doing some unrelated development / testing, it occured to me > that the following message is rather misleading: > > # gpg --verify FILE > gpg: Signature made Wed 24 Aug 2016 01:49:53 PM CEST > gpg: using RSA key 7223B56678E02528 > gpg: Good signature from "Neal H. Walfield " [unknown] > gpg: aka "Neal H. Walfield " [unknown] > gpg: aka "Neal H. Walfield " [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: 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 > Subkey fingerprint: C03F A641 1B03 AE12 5764 6118 7223 B566 78E0 2528 > > I think there are two problems with the above message. > > > First, gpg says: "Good signature from USERID". The good signature is > from the key, not the user id. Anyone can create a key and specify > any user id that she wants. Only if the USERID / KEY binding has been > somehow verified should we say Good signature. Otherwise, we should > say something along the lines of: > > Good signature from KEY allegedly controlled by USERID [unknown] > > or the slightly shorter: > > Good signature from KEY with the moniker USERID [unknown] "allegedly controlled" would be my first choice, "moniker" second, and the current wording last. Thanks for suggesting this improvement. > Second, the warning says: "There is no indication that the signature > belongs to the owner." Whereas my previous critique is based on the > reliance on jargon, this phrase is just technically false. If the > signature is valid, then it definitely belongs to the owner. The > question is whether the owner is actually who the user thinks she is. I agree with this as well. If we fix the "Good signature" line, this entire warning could go away. Or, if we want to keep the WARNING, we could change both lines of the warning to something like: WARNING: GnuPG does not know whether KEY actually belongs to USERID. This signature might be made by someone pretending to be USERID. It'd be even nicer to give the user a suggestion about what to do if they have actually verified that KEY does belong to USERID, but that might get too verbose :) > I mentioned these issues to Werner on gnupg-devel and he said: > > 1. People complain about the TOFU messages being too verbose. > > 2. No one has complained about the above messages in the past 25 > years. Maybe no one has ever complained on-list or to the GnuPG team because they don't think they can ever be changed, or because they don't know how to rephrase them better. But i can tell you that i've heard many many complaints about these messages from trainers and from users during trainings. it's nearly impossible to explain it to new people, and it's one of the first things that new users see when they are trying to understand the tool. There, now at least two of us have complained on list, a minor reflection of the hundreds of complaints i've heard over the last few years. > 3. gpg is just for geeks and as just the interface can use lots of > jargon and users can be expected to look up these terms. if we want gpg to just be for geeks, we can keep it with its current usability. if we want it to have wider adoption, we need to take UI/UX/jargon concerns seriously and take the improvements that people offer. I'm on board with the fixes Neal proposes here. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Aug 30 07:34:05 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 30 Aug 2016 01:34:05 -0400 Subject: [PATCH] dirmngr: implement --supervised command (for systemd, etc) In-Reply-To: <878tvfeva6.fsf@wheatstone.g10code.de> References: <87twepzr74.fsf@alice.fifthhorseman.net> <878tvfeva6.fsf@wheatstone.g10code.de> Message-ID: <87zinu252q.fsf@alice.fifthhorseman.net> On Mon 2016-08-29 06:14:57 -0400, Werner Koch wrote: > On Fri, 12 Aug 2016 22:07, dkg at fifthhorseman.net said: >> However we solve those problems, having process supervision and socket >> activation still seem like good things, so i'd still like these patches >> to be considered by upstream GnuPG. I don't think they break any > > I will look at them in detail soon. I would however like a more > generalized approach using options like --listing-socket-foo and nothing > systemd specific. For dirmngr, which only listens on a single socket, this isn't too troubling -- i could replace --supervised with something like "--listen-socket-fd 3 --foreground", so the user interface for dirmngr only gets a little bit more complicated. But for gpg-agent, which can potentially listen on 4 different kinds of sockets, --listen-socket-extra-fd N", etc would be a worse disappointment. The current proposed --supervised implementation uses a set of environment variables that are provided by the supervisor under a straightforward naming convention (LISTEN_FDS, LISTEN_PID, and LISTEN_FDNAMES). While systemd did establish this convention, it needs by no means be limited to systemd, and the patches i've sent do not link to libsystemd at all. I'm currently working on an addition to the runit suite (to be called listen(8)) that will allow people to trigger this convention from any OS that supports both runit and the standard POSIX socket(7) abstraction. [0] In particular for gpg-agent, moving to a --listen-socket-FOO-fd N invocation model would leave systemd users with the necessity of writing a wrapper program that parses the LISTEN_* variables, builds a new gpg-agent commandline, and exec()s it. If you want to make it easy to support systemd users, this wrapper itself should probably be shipped with gnupg, and it will be more code to maintain than the current relatively small implementation. I'd really prefer to have a simpler interface, with less code, that supports the most widely-adopted existing socket-activated supervision system that is already in use, than to have a generic implementation with more knobs that ends up needing an additional wrapper to be useful in the common case. Regards, --dkg [0] http://skarnet.org/cgi-bin/archive.cgi?2:mss:1342:201608:igkfadclflfmoeckkhne -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From ineiev at gnu.org Tue Aug 30 08:05:28 2016 From: ineiev at gnu.org (Ineiev) Date: Tue, 30 Aug 2016 02:05:28 -0400 Subject: gpg: unhelpful messages? In-Reply-To: <8737ln2ish.fsf@alice.fifthhorseman.net> References: <87shtnn7jn.wl-neal@walfield.org> <8737ln2ish.fsf@alice.fifthhorseman.net> Message-ID: <20160830060527.GJ30563@gnu.org> On Mon, Aug 29, 2016 at 08:37:50PM -0400, Daniel Kahn Gillmor wrote: > > It'd be even nicer to give the user a suggestion about what to do if > they have actually verified that KEY does belong to USERID, but that > might get too verbose :) And to check if any USERIDs in the key match the expected one (e.g. when the signature comes with an email message). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From dominyktiller at gmail.com Tue Aug 30 21:24:05 2016 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Tue, 30 Aug 2016 20:24:05 +0100 Subject: gpg-zip doesn't completely respect --program-suffix Message-ID: <8e6ac12c-dd65-74db-4adf-14cf4ad355a8@gmail.com> Hey Folks, I'm not sure how much this can really be regarded as a bug, but building GnuPG 1.4.21 using `--program-suffix=1` results in the `gpg-zip1` script still setting the default GPG to `GPG=gpg` rather than `gpg1`. Not sure if that is intended, but it was something of a surprise. I'm aware you can manually pass it another GPG to use, but having to remember to do that each time is a little clunky for those of us who have a memory like a sieve. Dom -- Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Wed Aug 31 06:00:24 2016 From: ben at adversary.org (Ben McGinnes) Date: Wed, 31 Aug 2016 14:00:24 +1000 Subject: gpg-zip doesn't completely respect --program-suffix In-Reply-To: <8e6ac12c-dd65-74db-4adf-14cf4ad355a8@gmail.com> References: <8e6ac12c-dd65-74db-4adf-14cf4ad355a8@gmail.com> Message-ID: <20160831040024.GA84606@adversary.org> On Tue, Aug 30, 2016 at 08:24:05PM +0100, Dominyk Tiller wrote: > Hey Folks, > > I'm not sure how much this can really be regarded as a bug, but building > GnuPG 1.4.21 using `--program-suffix=1` results in the `gpg-zip1` script > still setting the default GPG to `GPG=gpg` rather than `gpg1`. > > Not sure if that is intended, but it was something of a surprise. I'm > aware you can manually pass it another GPG to use, but having to > remember to do that each time is a little clunky for those of us who > have a memory like a sieve. > For which I *highly* recommend keeping the config.log file from the previous build around for as a reference. It will tell you precisely what you did the last time. ;) I do that with everything, not just this. That's what log files are for. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: not available URL: From wk at gnupg.org Wed Aug 31 09:00:09 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 09:00:09 +0200 Subject: gpg-zip doesn't completely respect --program-suffix In-Reply-To: <8e6ac12c-dd65-74db-4adf-14cf4ad355a8@gmail.com> (Dominyk Tiller's message of "Tue, 30 Aug 2016 20:24:05 +0100") References: <8e6ac12c-dd65-74db-4adf-14cf4ad355a8@gmail.com> Message-ID: <87oa491kzq.fsf@wheatstone.g10code.de> On Tue, 30 Aug 2016 21:24, dominyktiller at gmail.com said: > I'm not sure how much this can really be regarded as a bug, but building > GnuPG 1.4.21 using `--program-suffix=1` results in the `gpg-zip1` script > still setting the default GPG to `GPG=gpg` rather than `gpg1`. --program-suffix is not really supported in GnuPG because GnuPG has its own method of naming its programs. That is required because they all closely interact with each other. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From dominyktiller at gmail.com Wed Aug 31 15:37:10 2016 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Wed, 31 Aug 2016 14:37:10 +0100 Subject: gpg-zip doesn't completely respect --program-suffix In-Reply-To: <87oa491kzq.fsf@wheatstone.g10code.de> References: <8e6ac12c-dd65-74db-4adf-14cf4ad355a8@gmail.com> <87oa491kzq.fsf@wheatstone.g10code.de> Message-ID: Hi Werner, Thanks for the clarification. Is there a more recommended way of ensuring GnuPG 1.4.x gets installed with the `gpg1` name rather than `gpg` or is it a case of build-your-own-solution, etc? I noticed Debian just patched the configure script for experimental, so perhaps that's a better solution. Thank you for the reply, Dom Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. On 31/08/2016 08:00, Werner Koch wrote: > On Tue, 30 Aug 2016 21:24, dominyktiller at gmail.com said: > >> I'm not sure how much this can really be regarded as a bug, but building >> GnuPG 1.4.21 using `--program-suffix=1` results in the `gpg-zip1` script >> still setting the default GPG to `GPG=gpg` rather than `gpg1`. > > --program-suffix is not really supported in GnuPG because GnuPG has its > own method of naming its programs. That is required because they all > closely interact with each other. > > > Salam-Shalom, > > Werner > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Aug 31 19:21:45 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Aug 2016 19:21:45 +0200 Subject: WKS enabled for gnupg.net and gnupg.org Message-ID: <87zinssvkm.fsf@wheatstone.g10code.de> Hi! Those of you with a gnupg.org or gnupg.net address may now publish their key using gpg-wks-client as described in the recent blog post. I copy the instruction below. Note that gpg-wks-client might be installed in bin/ and not in libexec/. Salam-Shalom, Werner ===================== An easy way of testing the system exists for [Mutt] and Gnus users: By adding the two lines ,---- | application/vnd.gnupg.wks; /usr/local/libexec/gpg-wks-client \ | -v --read --send; needsterminal; description=WKS message `---- to `/etc/mailcap' Mutt will do the decryption job and then call the wks-client for the protocol handling. It can be expected that Mutt users have a /usr/lib/sendmail installed which is required here. Note that `--read' is used which tells the client that the input mail has already been decrypted. For all others the protocol can be run by hand. Let?s assume, you have the key ,---- | sub cv25519 2016-07-15 [E] | C444189BD549468C97992D7D3C79E8F960C69FCE | pub ed25519 2016-06-28 [SC] | 64944BC035493D929EF2A2B9D19D22B06EE78668 | uid [ultimate] dewey at test.gnupg.org | sub cv25519 2016-06-28 [E] | B3746B6927FF8021486561D83452DE414E0B5CCD `---- which in fact is a real key of our own test environment. To publish that key you send the key to the mail provider: ,---- | $ /usr/local/libexec/gpg-wks-client --create --send \ | > 64944BC035493D929EF2A2B9D19D22B06EE78668 dewey at test.gnupg.org `---- As already mentioned, `--send' invokes `/usr/lib/sendmail' and sends out the mail. If that option is not used, the mail is written to stdout (or to the file given with `--output') and the user is responsible for feeding this to the mail system. If this all works a single message will be shown: ,---- | gpg-wks-client: submitting request to 'key-submission at test.gnupg.org' `---- Now, wait until you receive a mail back from your provider. In this example that mail was received and stored in the file `new/1472561079.6352_1.foobar'. We feed this file to the wks-client: ,---- | $ /usr/local/libexec/gpg-wks-client --receive --send \ | > < new/1472561079.6352_1.foobar `---- which may respond like this: ,---- | gpg-wks-client: gpg: encrypted with 256-bit ECDH key, ID 3452DE414E[...] | gpg-wks-client: gpg: "dewey at test.gnupg.org" | gpg-wks-client: new 'application/vnd.gnupg.wks' message part | gpg-wks-client: gpg: automatically retrieved 'key-submission at test.g[...] `---- and has sent the confirmation mail back to the provider. Over there the confirmation mail is matched to the pending key database and the key is then published. To check that the key has been published, use this: ,---- | $ gpg -v --auto-key-locate=clear,wkd,local --locate-key dewey at test.gnupg.org `---- you should see: ,---- | gpg: pub ed25519/D19D22B06EE78668 2016-06-28 dewey at test.gnupg.org | gpg: key D19D22B06EE78668: "dewey at test.gnupg.org" not changed | gpg: Total number processed: 1 | gpg: unchanged: 1 | gpg: auto-key-locate found fingerprint 64944BC035493D929EF2A2B9D19D22B06EE78668 | gpg: automatically retrieved 'dewey at test.gnupg.org' via WKD | pub ed25519 2016-06-28 [SC] | 64944BC035493D929EF2A2B9D19D22B06EE78668 | uid [ultimate] dewey at test.gnupg.org | sub cv25519 2016-06-28 [E] | B3746B6927FF8021486561D83452DE414E0B5CCD `---- Despite that it tells you that the key did not change (well, you asked the provider to publish this key), it also tells that the key was found using the Web Key Directory (WKD). You may also use this lower level test: ,---- | $ gpg-connect-agent --dirmngr --hex 'wkd_get dewey at test.gnupg.org' /bye `---- which results in a hex listing of the key -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Aug 31 18:12:23 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 31 Aug 2016 12:12:23 -0400 Subject: gpg-zip doesn't completely respect --program-suffix In-Reply-To: References: <8e6ac12c-dd65-74db-4adf-14cf4ad355a8@gmail.com> <87oa491kzq.fsf@wheatstone.g10code.de> Message-ID: <87y43cex3s.fsf@alice.fifthhorseman.net> On Wed 2016-08-31 09:37:10 -0400, Dominyk Tiller wrote: > Is there a more recommended way of ensuring GnuPG 1.4.x gets installed > with the `gpg1` name rather than `gpg` or is it a case of > build-your-own-solution, etc? > > I noticed Debian just patched the configure script for experimental, so > perhaps that's a better solution. fwiw, we're doing that in experimental and in unstable now. I'm hoping it'll make it to testing in the next week or two. --dkg From dkg at fifthhorseman.net Wed Aug 31 21:04:57 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 31 Aug 2016 15:04:57 -0400 Subject: WKS enabled for gnupg.net and gnupg.org In-Reply-To: <87zinssvkm.fsf@wheatstone.g10code.de> References: <87zinssvkm.fsf@wheatstone.g10code.de> Message-ID: <8760qgep46.fsf@alice.fifthhorseman.net> On Wed 2016-08-31 13:21:45 -0400, Werner Koch wrote: > Those of you with a gnupg.org or gnupg.net address may now publish their > key using gpg-wks-client as described in the recent blog post. I copy > the instruction below. > > Note that gpg-wks-client might be installed in bin/ and not in libexec/. I'm looking into shipping these tools for debian for those interested, but we're not shipping them yet. I see a couple options: * rename them as wks-client and wks-server and ship them in a separate "wks" binary package for people who are interested * add them into the standard "gnupg" package shipped in /usr/bin * add them into the standard "gnupg" package shipped in /usr/lib/gnupg (where scdaemon lives) any preferences? > An easy way of testing the system exists for [Mutt] and Gnus users: By > adding the two lines > > ,---- > | application/vnd.gnupg.wks; /usr/local/libexec/gpg-wks-client \ > | -v --read --send; needsterminal; description=WKS message > `---- is there a specific file extension that you want associated with this mime type? .wks was used by Microsoft Works for spreadsheets, but maybe that's far enough in the past that we can ignore it? I can have the debian package add this to /etc/mailcap automatically if you think that's a good idea. Might be a good argument for a separate wks package if we do that. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: