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 <bjk at luxsci.net>
---
 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 <bjk at luxsci.net> 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 <bjk at luxsci.net>
> ---
>  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: </pipermail/attachments/20160801/672d6a8f/attachment.sig>

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: </pipermail/attachments/20160801/99afd89d/attachment.sig>

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: </pipermail/attachments/20160801/c87e816f/attachment.sig>

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: </pipermail/attachments/20160801/b6b4d7d9/attachment.sig>

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: </pipermail/attachments/20160801/7448f63d/attachment.sig>

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 <bjk at luxsci.net> 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: </pipermail/attachments/20160801/b7badf77/attachment-0001.patch>

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 <bjk at luxsci.net>
---
 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 <dkg at fifthhorseman.net>
---
 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-<string>.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 <location> <error_code>
     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 <location>.
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 <dkg at fifthhorseman.net>
---
 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 <dkg at fifthhorseman.net>
---
 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: </pipermail/attachments/20160802/3d1d4f1d/attachment.sig>

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: </pipermail/attachments/20160802/8a3706df/attachment.sig>

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 <dkg at fifthhorseman.net> 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 <bjk at luxsci.net> 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: </pipermail/attachments/20160802/6e2aa298/attachment-0001.sig>

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  <https://openpgp-conf.org> */



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  <https://openpgp-conf.org> */



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  <https://openpgp-conf.org> */



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: </pipermail/attachments/20160803/90a626c7/attachment.sig>

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  <https://openpgp-conf.org> */



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: </pipermail/attachments/20160803/21a06053/attachment.sig>

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: </pipermail/attachments/20160803/be8b1f64/attachment.sig>

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 <dkg at fifthhorseman.net> 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: </pipermail/attachments/20160803/37e02f7c/attachment.sig>

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 <dkg at fifthhorseman.net>
---
 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 <reg_exp>:
            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 <dkg at fifthhorseman.net>
---
 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: </pipermail/attachments/20160803/426f1f38/attachment.sig>

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: <b31249ad-b1bc-8ca0-afd9-84f9558ddd54@enigmail.net>

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 <dkg at fifthhorseman.net> 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: </pipermail/attachments/20160804/8a7bbf6d/attachment.sig>

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 <bjk at luxsci.net> 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: </pipermail/attachments/20160804/2593501c/attachment.sig>

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  <https://openpgp-conf.org> */



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 <dkg at fifthhorseman.net>
---
 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 <KEYGRIP>.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 <BLOB of the certificate in binary>))

When SSH is NULL or the file <KEYGRIP>.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(<ALGO>(...)))

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: </pipermail/attachments/20160805/de2d23b6/attachment.sig>

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  <https://openpgp-conf.org> */



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  <https://openpgp-conf.org> */



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 <alice at example.org>
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: </pipermail/attachments/20160805/e16895b8/attachment.sig>

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 <alice at example.org>
> 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 <wk at gnupg.org>
uid           [  full  ] Werner Koch <wk at g10code.com>
uid           [  full  ] Werner Koch <werner at eifzilla.de>
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 <wk at gnupg.org>
uid                   [  full  ] Werner Koch <wk at g10code.com>
uid                   [  full  ] Werner Koch <werner at eifzilla.de>
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: </pipermail/attachments/20160805/214a9744/attachment-0001.sig>

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 <wk at gnupg.org>

* 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 <wk at gnupg.org>
---
 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.  <type, name> 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 <FINGERPRINT, EMAIL> 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  <https://openpgp-conf.org> */



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 <dkg at fifthhorseman.net>
---
 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 <dkg at fifthhorseman.net>
---
 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: </pipermail/attachments/20160805/7a443933/attachment.sig>

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  <https://openpgp-conf.org> */



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: </pipermail/attachments/20160805/311e3726/attachment.sig>

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: </pipermail/attachments/20160805/25185495/attachment.sig>

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: </pipermail/attachments/20160805/352bec4c/attachment-0001.sig>

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  <https://openpgp-conf.org> */



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: </pipermail/attachments/20160805/d15f56fe/attachment.sig>

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: </pipermail/attachments/20160805/1c155cbf/attachment.sig>

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 <dgouttegattat at incenp.org>
---
 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`XsCXd7<ymUz)
zOG2flWuYGye9g>c6n-d({5V@&`k}PEr0gRuscsfmPOrp&tf{L;f1)(Dwlp;^b`Ux{
zI+m+?7km3j!=ppw;YGq126=pR=<CXtuj8YW)Tx=TW0bX-xrG_Z^bCzLzertNrcu6a
zt<aYlYxHj$+v}Tatlgc61$q|yEPGr`jr2L5aUM5jD+lfw+xc*C at bG_s_HckH$Jj<L
zUlYK9>&w1lN5y{G0BdDAIQZ>M^mQyB4%1S3LO?a~$DR|-&d3Mlj_$Hu?brv%f^(%p
ztJ@*@$`|+Q6eG-!!_sFfEL7UG-y}pPd^A<id))g{*o@=aA#g9aH$y5ziUX7YW@<P?
z#N3zn0~Q5&zpYMhhuqs)-ayg=<tZx at 6GUdQ2|^>LINgvmJ{}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{CEa<r)le$}n{srJovx-8E-twZ|{zl^LWOXNLmvGbthXdlCg6v(a7pQ9zUABA+)
zjqa#zQsEf0x~NGT&x;zhFC=xaM~H;3jn>Oo=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$<P)~9}C(6ZSLb8VYx9`a5?2Z7n at jg>v)JJ>oY8i;yyXQ
zQZdNTDJ#x!EDNYesdCAwJF at LRgVxPO6*-M=PMXVOKUe03Nawya(iXDWvd4Bff~XTA
zA=RpFpRNlY7VpR<G9qnXh=&NC%WS2)E~yhQKa>`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<on^v*a{4C`dN|frXDlRWk=h>%Z6H|0J+kw<T=@y34 at uc22*`^i|twFuL
z)i&;BSftt-{%V at qYpfOO*xtI(8vd*_s1H-_Q}f}2vRB(h6b8>trL`qE6HB;HBRiM*
zHqj163pExc*hGH+U+=6queN1-<u_osc?2yCR=F^#ilwWcxcrOjb9<+n>{=>qRLihn
z|7DuxZRdc!S at 7aXKhF!=)v`&|T32!xi*XR}XvE|tnS<AEn+~7luE>-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{;<ful^LPr_g{jOtI at Kw*bCJf!=4*oE7`Gn7^!kul at nWQ^n?9*^p{ceD
z2y1-N(Bjf;d6n51$k|>S7n~q(w;@nuADn{C<!3(6Xjb6i+tQ_u9X}VLql_VK5PeS>
zivyAJ-b7+=VSLI9Y5<duAD at V9@HVTSmaO;|O79#!<M-O>w>#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>b<XyVq^58F*D8SR&rAFKrEO-RrkgGlFJIy8B1W0%U+UQz{Zw`#sW+ku{UFMO
z^dOfL!8=CS^d3uT5(5m~WY3FfNWF-roC~t5hNCLY7 at -Gg7JJ8UrCg`jbl3t`M?ncj
zkNLiEHw31KP%Fu!^#qMnKPxCjK19zcDE(pqL);3K%8OdVA9c7 at FX>O&_p{9YsJ9$H
z%kCfIabX^5EP7t0(B<RxjJFV;)u?>B)%8i%?NV9g_fyEv(v{@c(Z5I<lDfoBTKOKb
zA`Lk+2nP*_uiP at En5K$7nRze9B5LlA{NhSL6%$fd?*g$wOB2a at u&_H3t!nenk+E`X
zgM*=c42m3tTqT at tMsn=Jq3TaPwDl;r;wyS**Y>%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@u<oT3)y-zpfROD^i-G8
z+K#+BDtVZKh)6-D_0PY~NJ~S<f%R@><!!-oVH1iZ!oY}d69)BR7CaP_MCLg}m3i|m
z?d{hZ1rl_XuLB3KGB|yU88hG$m{jiekg>4v8#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 XDnE1yCO<f$Dr
z!=Rp^6W84Pd*whM2q5YS$q|Nu#~K^w(oaPf_WJ&kAngK04tKh3?_-UPX-`ove!P63
zlhJ*b`_v?ama- at NnHd&s6Yy#0w3d4s#+tB>DZlq194-GAR;3Ik;X`ss_!e}KQi#K2
zeKjpugG5>0Skxc_G7fC}Or({e3;vRh+0?j?)ry=YQ*h@<B7US<9Xr#P@?+Qh12Vud
zUX1&63_hqI0&Cb`mS^TLec!{rkDgB`pxU{9Nz<xGBgyS-xAvb@@nYs#*KnC+M{$*C
zd?fYYBFd|{Fcch?4A#?213hL6X7e6Y<CnKesx#m=x1w>>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`NP1ao<eRuC^j
zDQ~xEd)awRcU%=nPh}!Q`9Ty$BJB9AmC5tM#liOjz9I(=Gts1bhF at 4t(6eAbR%nkU
zD*<j*k&AXFTUFNe>Gkz`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?<aeT$M%D;irFwe-ysiMH+l
znq%KOorg=iJ$jdM4}a<qU4IsB&%e_OSi^&7{4oe=n^l*bC9Qa$pd6<MHe2`Qs_ at 3)
zXvEsPB1R1^NsO6ny>;L49t?EEgGx=94Lg|_8!RIn9pYM>fMC9 at iual<x;`OU-V+b0
z52Un9M>$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-#<dC)ijS&Ik_Lx&C4Lh)F2>~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|J<xuYz%U;HEbVp`p~`ieJi|
zny>UWI}<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$dtl5zry7<j{O2S^O|QlN?r}fVxJOO
zT`jR)WKvzr-pJa4|CM|HRI^BoP-PZv`B*l($Zwz&pX6pjiXYps8E+NhEA#c!#QVUL
zAk5|1kg}jhr%WCUmZ~SS5r at Y&Y(`EBCf<tt4sd~x$y&7uShV{5P^xJumU72WG+Xx_
zxLD}!C&LTAqi7+j$Srj()@*CyqtT=;Q_byk8P7W>zmEkYs;V*#r#{@P;)VdR==oo_
zI7#Ojw=334%VGnSSUtrfx<xoD08fGjF>eA+M95jNws4y at jv<frV>1T|j^|hU6IvYA
zf*s~MAwf5C^U7D2_zWLjQD;`6nD*9iq;Qb9lW}52fb~dg<uzY?nP*ulGE7r6kaE)j
zRykYh+FR;YD1L{tKow^V-UghMh>$^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<N`3Mf2M9zVQ)uUh22*cLh
z%x6|!m)NPe#SfIF1~V%uR9$`u`(l3y9bRqfd1PC<<ycW(u%!kxrp4Cyez<@errW`#
zE1t$J9IY{A#~~Gf^gY;uN+%)J>~DP1A-#f8vGl at Z<<9ES8;?fYt^30wHAO?<W&bwu
z7*H|F(Kq-g)Y90Rl<FCTZ#2!40vC(XBa815cWQN{&tNDI-5tgkmwUu>D8B$iM!Lt=
zgy`-V-7mAJ{!rk9*`D(rYQx{@^d61>L8oj=q}O{4ZIZ{Nq%n<L2{8qO87*~NY{VJ$
zh3|aJrWkqc<S+dl(7vle;QDEa`aY!$vSZ=?f$P85dZ~*DD5tUJE|;sqz-qj~JemF9
Pjl;yiOuta~=F`6c`Q?E?

literal 0
HcmV?d00001

diff --git a/doc/manual/libreoffice-digital-signatures.png b/doc/manual/libreoffice-digital-signatures.png
new file mode 100644
index 0000000000000000000000000000000000000000..9a84d6c3f0e849fd654bd517e49330cc7a8e9108
GIT binary patch
literal 4998
zcmd5=cTiJXw-0&|QLs`)KtYNiAd-M|qzZTdje>-xASHw%UApCp(u)*1bc7=zK$PB5
zklus at qG*V8sS!dE3Gjm7efRsmd1dDP_h$B)byk_R_iwK~zrD^0H!;#<KXmF43<hJ@
zzp8x$2HOY0U`&{U`xzFvavh2x-kDsxsRLtzal>|DY`fe%J3^v6atex<Rn*kAbaeEu
zsb8UAyN*PfnHw0<E$`UbIXYY0{Brg5c6Hf!5FGmOacFSh`lGPt#_=N&vGLKdQO};O
zCnTrXXOYvgvNJPi`2__}%f6MoDK0Fcy)DC+SC&;)S5(zjHZ;{YHNPupn`rs4+}6?h
zp|iX9V{bEImN2+P7#buF6Ud+EN64Sal&|FR$#3Hn^7!J!^!Uv8g_*hO`K7s~AB!ui
z%c~o-jbH0KyYw5>fQJk$Otyx4+OX%${8t$Y>;0?dUNG3<lY0*n3{2-?7+Jja0Uefa
z`+2yykB2h%pM$|pT+`RSa`VB+Vg{?$_+=gq(yRR3GtF<#wB!mulY4g%**bD#Y<Cw2
z7`S&oL}fPzF5LiMO&eySyK1MiWHqKY9bK62orW{RnKh6aNEp0VK+l^Abm(t=#R=vv
zD$)HP#E3Phs5f<__}q9Ao}zjTh>eMfF~;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_<Ip{x3{LJMa2V6K(+MC)RH~{fj%x!arU)(W|oZ1
zlh3Q;?PX at 2G6Bm!=!+LjiKJD{o<Wl1(NO8ude0R~cgxg!r(gGjR$FS-l(v6zTD!T0
z?9lybH0p{#A|!KIHUll2hxJNP3 at -wV@tLo5TJLQIotB)#NRUpHP720*d2Zj=@T1S*
zaPA~ZNu!AUc2qy49;(&^0M>_|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=<gE%dTtu~yaB>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<em^k<RsU^!g=6mz#TSNjW3L`MOqPs42*
z+^4?~Ff?PwnfoM=!HRJLa)3Ytl&QQgoIgt_Ox`yW<|Zxmczka7o at -mr+NXdtEgz7a
ztSGyF8YnyqL<+ykN!E=I81)GveKiOv8lz7dIMoURKHZmYc6UXZ>-Dqnt^~c at V9YWi
zf{VwP=U2WsU8uOq0CX<QfgM4(M4RYnt(g9_Env-nBE)Sutc#B$8TqqGok*8h4j8SW
zf)<^zi1eoN6AR9+64p0Gs=2$Kyo5IlT&I_b^(s+0F7*CLDZ133sH-jWS!OyN$7x}T
z<7oJqo!IRs#5n=nZ%i%CjkZ3E&nP at T1jlBcuyLtN(tLYh(@^sL5kzn7E8g%j?5%pK
z+fRLEZJWPz8s}9A^y+ymM2v5LZ)N6}Qc7zB&k$I;BIE;}+LmGAMrO&xKs(DIdG;BZ
z;y;v$<>sfsmcfV$?9fNh6p7J>M;8HP?qb&%gO$m8^YUD78Fs)78R~ipqxrxU<da5E
zBvhbt?nW7QC48!<eZAi~0#DDfWHtB0VMPR^zg!7Bn-#*|uSYGy&yAmTJ~lv%JG$V!
znvhXnh?vqhoJ9>pM!u%ftn(Pf7>hjuDvH$XfwN!I+Io{coyJHS<mxpbwrx_BL;t`i
zg%5zd7f12c(I9MGA8K!%GnL#2Hl{(4zhJF9Rw(;C4BVG}{$ItO&M<=e7H%NRwxpHx
z%THEEdemWT7xkUJl+RbYh6PvY3M=zsCbyJ4`Fs8V0=*ty8`ydSm8s4?`kZrQn+ at QV
z+SeZj;R7$B at XrcoCBZfmp=WqSRF-oPm-4rZ at QT(ZQ*&hGlOb}JJz#%2BG-A!qx`8s
zQNtCskl8i6E?XAuea2JIWFtYN)~0+A!I#{)?xN&#N?s1ES+)`T7zcIcH=$V09cWAe
z3-KZM%bblcU9yRxb4&Vp2wKe?CT at uX<6JZ1QW#z+*V{#O>O7E=`>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)W<NE17AL&Ij0|H&iGIq#s8zp;YR_tKZ_q8zAZvC~Qm4TvF*hR_-|dMAYCoewcaI
zXvJkfY^sm0B9}G7`}Q-O<M|5}-<`+bC=LXV^C{G=XEFo^M&auL07V$cz{)AHN{OCS
zP*+R+KK|PKCXeY%DuHOVN7F%pN?8)27HNkLfT3~oKJ${^8s~moO|&L#=nw|)%e!(+
z7%KUpq5jnsA+inFd5OISO3JdeH$ZN_!?o`p(2lV5R7*;#GX7N?YCY^YXuM(K(s(K#
z|B*3!gLp>V at AaQl4CJ^~Oh2J=2A9J^9<B)p*<HU<CE at P7!HfENEj{)qXK_*g#G`W0
z6-8^egU5!5l8c#s{X@;~)KxgSrsOF9nkztaur`C at eD5{O>ZaJfO>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<k(XOhs&QpaZ-S?(;=rr521$;>~Hbr20<Fstb{M-{)6HE
zrnbKr&P9hH at Y|pB-~0E7agPb}3ed4Jk1h-t5{V0=qrMb9$M*7#KkK6Ir}5WTS;^@m
z<(RcdypJ>dG>TNiN6#@=^}eAFJKYnriw?5UD|wQdeO|-#%73Zd-y8gJo8<lV%Nn(1
zt?kdZj(77)W`B;p at r&}<-E?XT_98VMaanJVYJ=d5i}g0z{i|w%VTyrdS-G-yCl>=k
zWd_qo)=|5e<U__^q7Hy1AH6rOGgh7ZdpKASi~`1H*Sc6RzG{MPF120`85g44+Gm3}
z0rl*(g2B_l1=G{;TOYlTA`o-P8K<FQ`{UP8YX)}J+H+m2uex66pnr at OObuD0H`^s5
zawq#RzgU`Hl)@cxps7Ss0O4}S=kg)HBMo2j1+hbcZ8zPe2*lAG2>*V|*8kpIaWh3*
z?!YbA^hyYCF+{BFb(^>YU)1GFS at A(B<e|s`+rG{uL05~8t=l#a7E-JyN0O`?gyPAj
z9u%N%&A?b(N^~?CEi+iZV)#8oEy|3b7wkz9htP>$D6P{;4%Sj^+xM;%U+`os1~D0)
zjH%{z8>3lw7Y}sIbcKa7%W_IOT*8xY>e=N(mA6<A<l5kgKFfnIpC7Nrk*H8)T5iyG
z;EeknxI7L^PTZh{7_MKzqi<KaZdJPTadt1sh<>W|OY!hpH0ZuR)7>>Lu52_(4lkX+
z`UK8T2TUov#`1r^abb<Eza8bFB5go3c%@%_Y}h-mrUr4>_HKch7RdGNMVN#$TsvCV
zBQFK_o-<kB8C*|BR47H?IRmzpi|N{pV3dUK!0Xmsjo0bq!oJ-AFlNdsucTY8ATrCK
z%<ZU!FMhPjqUHM>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{<h);OZ4eLPRJo6o;KJ9W8nmQO!U(OMHG&oSR)smd(eO$2fvE9K3u)7?@NG
zxAgIVKh`w(shw2iFOr<v;oV(^J?j?IxnI`myTnQ>ysVJclnu2&8*dXF?|FTC!zbkb
zR({dH40}94%^(w)5AHTsxg`|hZiv(}<A1dhoa2%URU~xq^XRHKiHn#BvfG^|!PViT
zO6jaX>&fDz%g2^noFg~$bMOmvnF4GauJPbnqhhLBgkY=n_Glx1!`AqhbxEk+QS^ux
z32MO(cy9H`P?N${cVAy at G|e{5L4Xg+(8ZTeaZ;QMDP|R8LRBUw+neuOa&lsfpV(Rw
zbl<A;CO)QFQo3(N6_gKGA}TDlJ2W21 at Yl#E37#TS)5iKJg1}Z%BOkTlfj5Wb4XX<e
zdLouW-B9L1ZgbPpnXzB%VsMmlWC|))JA5l5Z9a*T4mo5S)+HioQ_Icmp3-JWJ5VAb
zz?#4Fd{q(Jo_tXNH?D7Ut&aH?rVWt+|6sT4di6_ssW#GU9*mg1q;hPudt9Hw+Z)e6
zN0%u=%N*V%3rABFGA`K1Ww|_shfuuLb at u}l9NOoy_{{+hpezTw{PLPschXvW at f`*a
zlnmaaC^|(zxaOA&)&y2CcQ)dpfFFKV7<9Wv2;thXY1^4;;h|a+JhBEpB|@=vRNhy+
zFEx2ySy?C<h(tB;M6V(;=C(&;X6KR3pKuokNyJhcN9E}u(J0l!!odKO{2zM^`R^^{
zU)sOXZSyD^T<LqS8p5_NSVjSEfo>Gb9P|j^nb&XAWbdW#1a}R7-7s?k*AH}{7aZ7l
zU#Hc=$($h6$h1<_dvQsbFGchUA#t|=1`0fe_>vDWsGk8>A$N95Uc<Dq6u59NeP~cT
z>x%^sFotoitw$J49t*5vgRA}lq)f3HDpuUDN)``&F<lJd&trZ?KwJ3POK4q`oy)2r
zb$Hb$2^wRMn-G8h{!7noI^m<|Ej#~wl5|To^+FOvJm{LU=$1fMHKP at 4<W%JO<FE}e
z(2hf!=ZlHf(RRMCqFkjVjBMrCvtz3CD}6ChU5_*|`ZP7bN;8c&GW5fj5CLES&NOro
zz9!!}493)DY6=p)YrR`YAB{3{dZRe~s1xjNCl8yGyi?&L7fsr~oC`GRn)>oP%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 6<cOqRsso!jiTLRU*C$rc!Ck?wqn=R?
z#<sp#Slsh?69(&tR%HY0c(sNR<Z`$>90=Y&>5+B!tDn4dFCRb{h509r%D;=dwMxt%
z*eiJ7`}1!5+00vqk)tZ8s()HiMHb1>M3X~rmeLcM-(MvE!zsIGihS5ZQy<ki#$g>e
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_$qW<yk*)Lkd)${H<Fr}
zla-U1k-32_Dv79^C at Cxc@ME*KzUEiMT4C!<OG|r8Yja!YpFj96VrO?xXGa5Zwxe^6
z(1q{p?(Oa+_Vh0I53CFf^^c4V506hxPEX9v&n&JitgJ6 at Y^`tYZ0_uB?H%kM9PJ;G
z4o^r&-!5>yBx9j4Q&m;~y+6yYLcXD~SJ86<foQ>}2L%ZD!c6X at c7`JqsmG|8uW<@e
zRG}C^pc^2#f~=PNz;Yt37ogJj4Q>7+<v_cI&|6hyE9D9c##RY&SwWddB$Ha<FS6mm
zF96`MZonS6uH<7&{ULtViW1~i0sNsDQ|vqgLV*6=Bsaj+e_Y=i<s=ylGw%5&`?3|e
zNpu&X9L<_dOh&y=Mo}KegT15)$=>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=
zMY<bJtE at nCk>ByUuJJX*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*g<UHLvybGyTLg(48&C+$uSnoM*x>Q3(
zNm+p>yQ?JIm0^cFI(Nb#1w9R<!^L*>sv<9RJ>M<_KHTA#hARL8HP65<+l-`<bbIJw
zEqntWSJV2TpyWtMRMh0i5G`$&?>CuBi}*&<d8YFWf~@7g>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>6<E%Mh}ykB9k
zaPQ@&BwW(+$_lOIATj1kdzj#RNub6!L2%p;fDm7fGWayM0`J>ifCp9g?(<p}1uOaK
zNQKl3EtR{JKV5Ccgd7dMb24WT3hY4%8FR=)hrb%^a<+cj^qt6kq~66d-Yyc at Q<KOM
zq at wG&8E#}y7QLLZqR0w%Dk`21Ki5c6+o$t*bLUZzk<q9Nq2{PT1d8pJKGJI$ydAi0
zH8J<&CQ!08?>R1lpR%x;Xo_Xt>15pnh)9F+!(h~eT?oy?p(m|v4TD(M68pTkfZow;
zc&WTxtu`lkUg*mmy<HOmkHBcjxsj~i+tRuxg at DR{Ye|`_b1ipQ4jXdH(P|zjZ8kG8
zn29M$^^vze(8E_?R4#<%-~1VoGMIah4GK+*gcNiu)Yfbyy*h;d at rX##+ZZ-3alwwq
zmc5gHjVs4j=Rh=AAD9#Gn&lXmWoc=ROJT=Y76e9!!FRt;y3*;@rA2%S&?vn<p?a%w
zt~D$|t&-Q08It*-Lzh2!jT-JIsoXoTzkc-O1S+NY^<nA4!tz!_V{pzvMmS%GHleQB
z;G_B*PL~{fcn}_^gP at euw=SRA)M1;!pZtDN>b&F)EnLyD{F;}=m?z%$82<!p&EaZL
z{BAigWhI}A6=94Gnf2I!^-^Q>KavL9#+!>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&ABqbpcQi<xv_RNl%GyFEVr%EEp&`#o{4g(UM{=NY6a%
zAC at n!gcehPV0Leh9&<?k+OBycXfioIIjIm<K8<*nS(cW{?Q$=Ixg*Z5(3k`15Ywap
zW}J(>V6+mtxTD?q*{5><bIG9fe#FSS{;(LbmF{<#a;;<(HVd<-p?*%|TaFSZZRXZv
zBW-HV$(0-`jqs_8dWVdPbQR7LLz~5N$IKCq-}$kvk!+g6OHEsq8g$B$!bIepVx-uB
zh{TCZQo4F?4_?7Q_2mWNgMp_n1LNeNPAO_DO$$m?Fv<?ulY4D8KXVyjoQo6lopuqW
zVHWcB-7Nq8+91Svuyf;Wbkkm&G+iW5-aAn>Yh6C*fpLMxYh9(nejE1#RPm1x-ZZyV
z7E4Q|UN8QgbjKEVy}QXf=@z{cEc5Gxcn;Mxcoj5NwkcfAa5>)5YC^y5sFIMHKU2z!
z+e~(K4Tt9 at mKJW0q>BTej}<F!TVD|rJ%@3xey)Y?HQz-3`a}KkO$6D at kyl>!<K><}
zem at oD<mj at h!|F`eh2Sd_hC<-pPw@$v*7L?6u~P4Y!!Hcaq~m?wNAN6*h|e at E!9-Z0
zw%r|d9KA$UNsp(A*<XsD%IugVa!FK=tA#d|J4 at P%+S#JS at OM(dx~<AXmitaIB?aLS
zwCT`wkCPH3V$Y_NtuH~lP89$3+=B1Vaz_NP;w|Z<-<|5PpN`Th=+|o_cn<eCFXI at R
zH+oRd5+M1u)o#D?y-gE?BpeMqK(S at p7(;0V at Nl@U=-tnR&}Y>VBeA5!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^spZ<j37pcNve2|L(nsao{Q(>Cnwt82{VZyYR075v=bmRr0&f3b;D@{}K
zB@{Q%x6ew~A-1PGuY7fSmptzkBfSqz>$!W+E3)4AHubwYCxVBwTecmvEWgw?Mi3pp
zLP7^8f3{Bn^Y<+UY}HERM48Jm<<Bh3iku83cb<wXKHIoy>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-<mdoV{sv!|tY)
z{I&YXmfta)<xob^SZG{X9CR;=tv-^a)gXMJRz2ryo3 at v}n7rpD?MJ at y6}r4F9Xzxj
zR#JbjDqGsEqD3YKa at K}l8cX at 6TSiWdyxtj;lC12s3sdh^KjD%DzGUH!hh35UIOe|h
zb-@#Yl_LqGwJJk at j?0Q)uhdB=|1fKfbl~2VXdN0|eYD#ntj+0Ex9-?6fze9DVhl>(
zK<YCf)$&WpFC at is=xs<_=OU;3guC&=(EV31jX0iykkVjX*tgst!R4J(SwtR5d30nJ
z&OWQI|334@@&{SZ1UeHk>6TEYy7C4Fe9*m$-0wfaSEZDFAszse!5}~BCwI7Y&5?5o
zPACgr&^yS$1J9c|<ZMlVkBjBFozvGZFkE-AHV}eU+>sw?kB#MU<LLLuNXN^4eY|ZW
znfs_^9Alwcw!Ud{%u(}41R)3N6B$XR0Rf=o|Ft>o`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}D<O>azN=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=YcIuM5kTQqvF<HLQaS|F*AW`@A7Hy3xC!xLQ_I8uuq5$7{M-
zCA47|;_Gd9CGJ||M1L(@OTqZZVXR7oZAl$zgy(LoNOZ|ahdDvDN-Mtzf$sjzYm~4H
z(eO)1%-qu2k0eY!Io0w|f?*8=KSWQ*=<K6u-K_e4Hs7!+L|%Viocm6+H{q+>CL#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>L<J;Lgj~J>3jVY`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*8Ys675<b=`0e9>uDvPu$_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(<S(t*+)!w+<+G#o*5xNmnw1Mf0#inh$fE9<vi#^^ZD{0U
zr8W(0&M#=%6;`z9&Mu(y8-Lb4I}9ahVlENVx4gi;Av($t%M~cfRXy}{Do1Rvr6VQz
z1^J@=6;2hjst-+ZunIKkqZL%h3g|IiKY^M;Sj58V(`kf6zFY!8Y*@Gr+Ok#{5kzZj
zEf%BbL3Ud9`siCkt6#E+*fYP-(D(_OFSa;m<B$wXMC at xQTNe_y#e=vu(s@=aB&Gaw
z(k);lWBesV*=Vg)fy}_=67dy+PG~gM)I6QKkM=(TEY3i-PDIR(rG^$C=<R0T4t0-9
zq1j&<%d=b)lm~AN|Ij0j83jS6s^1O}z0Q_1WzxjTEMp8YkeV#}_9Nrj&Z&{hv!CRW
zX^s|v<{P$`${RQIU>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>EMa<OmhujM+-VbMd`!*5=0jEd3cVLN6f7qWeggJgQxh>BuZCB-Y5v#wxW@
zFx<e?m`5O~s*JEf304)Qo}a))r9BabVp7eu?rZbukEVu%L7rAaY;ATSGkNv~wLZ}M
zhhejdIdJ_tF(Cac50#_=bXcj+-oR7}2wbnKN1(TXUPi00(BKn3sd*N?1>;`^UOE&0
zE7~gvZx=hRRhYLbk1}zC>}(~3UhG>>D;Lc%4}Y^(VK4SV-y8C<3xKR$g3(B-hWXlU
z48hV~dHdyuq(T<UQrxCHUsx&Wo(^tQuOd+Tc%Y&LAZ8rxjn9pd*<@$xkXtP^F9&vy
z1isAfa%TE{<RF)u$aSZwZQzmgW|bWF(-kJ8W)q>Hn+1GbkMD4k4a at s7qPd2$w3yi#
zfFN%N90<h!<DwWMSQRzD)co|!>=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<x!^f&+^d1`9VBVxLjGOQ#4B#W(n at ror!!i83iKz^TsIefNsD
z@;a==nJ?VXP&<1ydi0DG2Et&OpJbE$R^cJzWinr4I!1_)Mw3hfkgIyeWMHywQRmLT
z5F!KEdk;j7oUsaq%76|9Zqi)_S^9&>=+?^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@|<!Vgw)XlE#WPNcrU_V%SVk~Lxj4h0%WNR%A<F;6+Owakp;`3d#%YsvaXX&
zZRs6Z1)LgSLW0clsdDOXk;QrA9|{?{_V;KngDwy7hRLubQ~gs5Nq^G<xx4msnuQ=T
zJ8E|_cmG=Q8w+(;;1T4h at OC;y&h?vtwg^0V at 7zNCw8z_G@@O<|<lDL)a35cX(!}ZS
z4c&J>ywkxAeT`B|g39<q_ECiM)dGH|5*{2khK;C2$OeKSc!5(o<TOVxf5P44TBwlD
zRHctuZpfhB-9N*IpMo9g8lm)^4TLuG1{$+KP1JRGp=C^fVt3&-DxT|eWHT<GHBu{O
zZ>;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*Na8aorKHEVJ<AbDh3dflj+f0Nqc2|fyHDUlyHM{TOd1|j{{UYbZE}ldM
zW4!aM^=PacYgNlptQwz54^QP})E0K at +}D1O(8mkLDM%NVgSi)dOvm<4Im=7jg5|n3
zqHx#h#Cfv;Zu0)){q-l>69(t~7%5d*<lJU|jlhnWBDTcAaMJUkQd7~r8sVMRR!Sy3
z-Gu0F%el0-8#&g;(U4ZPb#%US`C{L)gc&Ge!opW?y0pHb{9v$-*l2wL6-|;V8g*A9
zZ~ZuH*2&9=u?g72R;Kx23Zc7QPwd|~ou8!XvY~N0Pv!mnVPM=74_a6;@{*}Py(sxx
z<lnQU|G4>=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^vxu<wZju+ZH}dbOs6d#xl6_P
zRq>Sz6N*wuA@;p{Wkw&9-e5vqxihv<`k;YAHVm at n1bdh~V+nlN+Tmf=w;)W-Uq%F!
zrRWu-v`buuFS+V^%7OdX_25tXjrP;5E$~<S)}J|VCH_Ki=ouuG4d7Z5*|haBR;`^Z
z^8IBmQOnORuF?%45V1eh6v|Md%9^baI*LvYEXAw&1n_5Em36LY$`&(iCHP)Ls5w2-
zQN;sOuUwUSdNQ^(ip;8nM|FM-upknHE{q&z8-<S7%6ff)&}{s1lf8G}3=t%I588P~
zjmQ&{6*A6 at egs^sWXl4vQfFFmnZFCq7IbUg$pl_|T^>X?t*rwUVe(2~0T26yB+fH+
zWz~d$Rp%co%`E|449hnnAp&}#FUlbvNE;jddR3is2m!htG52GX+s&ZebIT#XXSe<w
z=7y0pni at HD%1H0(ChFPhp8TXX at O&BBIOi!`kQ~C29q{a8QZmlF4E#}Gpl#gwg<@{%
zLl#)#aLiuNy_(Bpk?n7sOSMxgMma{ma(>Ra5|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 @@
 	<p>
 	  Currently, supported usages are <a
 	  href="http://en.wikipedia.org/wiki/Https">HTTPS</a> client
-          authentication and S/MIME email signing using X.509
-          certificates.
+          authentication, S/MIME email signing, and document signing with
+          <a href="http://www.libreoffice.org/">LibreOffice</a>.
 	</p>
 	<p>
 	  You can <a href="documentation.xhtml">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 <dgouttegattat at incenp.org>
---
 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 <dgouttegattat at incenp.org>
---
 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+7JAxD<pL;w3F7ukb?UmAXc|sMrhT
za}90XGNtGGMkXTWi6$0S3+n2&j?R3a5q35wy~gi9dHYn`+r12Jfq9+y1qP}9oK%lp
z4EYfr^6khyuE8vMJR&x3GcX_?NX^VnPtVCajEaVrt>xsQi^{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<j}jHQ=DJ7A-A#n$6K>}
zQ~^&qbp29<mxO&xKEVqQG2TyGJ^WJ27tz5(*cTMh{%d&mKKBP8kR8Q`Eyu at OeSPD_
z?qs(IxYTYFBoP7S9n%TL at XM_}gv=#OqcUZFkSHJpy?~CZOq50j?qh}R<ac)ld<`QY
zi}&h7lY!*vgbxUWN1TkzZds+ioqjj+WSTx?HEa}p+5q at mc%B at QG_<sB$i!TnA0l}s
zye?3~*-+rp3Uw`hHwOX0_2rMJtFsUGr)T-~#boEpGGRk&Xyh~;L6T<W;?*jdx`4Kf
z_dY!vw)KI?Tpl}I93m|CJXB$j8R?y7<OB1v`CaG`)>@>|{N2EGakV&3X-EcmId{AN
z;`}e&o6=4zG)8|;U5WYP5IY}H6^H)^dJyuJ9fPWw(m>hw)+ETtl)i#^pVA{wf6-I}
zGM6|60O<R#K at a0kup3sfh2IbkHn2C-9bY@zV-A$P0Qh{95ibo|s1_GTM(&45$Bp9Z
z&J#qw_`oktuwv%>hlf~b0JIj1Kv<t)u|UW`(*~m!A0#&{=Lyn&;>715d;Vk5j~p-t
z7hIPYhk+!&&P#{ftZ4z6`ERXfXWL3rH78zC2>LybCpZ=Q79_MH*Yr}wZhx1PQ2dnW
z5F0slnbF5#BUZCIoGl6r8PsCWh_g?BqmT|wIP3|~<VwmeB?C8N-S_aeIngXmIj)<!
zJjZf$!(Z*xoXVgXA7P{-CLSX=#~dkW3c8ncS2f;s^Gy55lv5vRcxz4 at Cu`eZ;Ce6W
z<+FEuoKO>&y-bYBJ-cLN0zb%RXA~6ozqCkT_f27~gpePH7O~Z_1r)ObaL88Sa<<my
z(?2&L0ra=fGWR8)o&r-lewbZ%yS1I2<gse|oQHhi+`z0M9XT4QWjM|S3HLl0a5!DJ
zXLV-)a0$COaVGiA-6jLYHZ^&#;SlHZ2ovbh;IEzw&dO_mHgh-f at E8dYMKalbptXB`
z{Wz)x<(?R~Y(S~0opcG~N6TQz^L0w56AIkB_+MRW`Q|G<yuk9F0>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`?cH<G}E%9cn#T&<UW4;4%&F=
z&8PH`9u`CdTRZ_S0dTPINTK}P9}F!rd3x+Mw@&oTUv2=qPb^1{@qc&|_U!-ng8;(3
z9*^PWV0zh?e*c8r<;Ke at G;I+iswEHsJY2_BPW2;KO!p;TW6p2L?egsrLzu6Q^+&M&
zrII&Nl$AOLw7cmveJ6X>ZBeMHa<c`>T1&{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^D<!$%&G+aXZ*QAO{pI{QGDvFAvhZQtkSj#L
z(#Ko%?WHKE&F^3lKg(96wLE^IvTdPdm0o$S#pG)YDGVZoh(#lJy%NVpZ)uWvo*bh!
zVHa<W%q|XxsUhRV9});Q-w%mGMhmo1yzXmgIm~n{RQ6VqAW)yQ_4_AkE^QyHp{<`?
zRM8$@RRJVD7{_5?hSC>DsGUWRd1n$xDjMZeWTctL^b+CFaEXm%VBNH&ANQ)3aXox;
zG+Q_ZOG2P<h}F$vPh4^Kq|?4jhc*)s+k^ZXFJF~%$&?(+Q`%2IiyW07y(yDkC8xAd
z-gp`3K65!E1+TLX%P5+fxX7sZQn)|8GpJ`ZwwNys&nLy?)xkIIWvai=LyD7`m<W=c
z?W;0;FOGPNJw+f)SkVCJwYA~RYn7x=@qsM_nOz++XU==(Qf&q5(BOxq<HEWgcyy$|
z;OC(l$Dfqw`$vbX9p<&mzcyWXrr6|Xws6i)Z2I(Te_LC<8%_H325_diU%g*5b=mc2
z8LjMR<`YLv_O0 at zN)<P~LKxy}<vz2T at TG4GdJ%n?@*os?V{$m+T{ge=k<LyTBW at 65
zz|@qfiZnW;!`_J|^%Q`}G at nP;<qZ}H+DsurM!u at T%8HN=o_~D^KDZEo$qI;YdkWB6
zBkm2<byy5up0}R at +ZR1XWaT1|So{ySIR9PA23b`LnJ_9pJ*}c`^0ws%`wgthlOlNB
zf=T2S&^N(hmllW#&Hieg6Eu6cA||_a2F$N_Z(HF`j~8|Kl--S8ZsG$LbTW(f0fWrz
zbQm`6PUP^dKF-4;SpV1W#-4-U$qRHNon_HMF#hC$Gyl18C;|~vJ}^u1S!8Q#jq>wc
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<NYALXae<cTY~0Z9aZd9QA9%SqT=GcTbK~Xa*4rty
zz<kH1O1pB`zHA-3im-P>=1aP2H^C<qTXn|c99b1qBeX<W!y{&AH*Gt+rcnj-h7(?W
zYYmw#$w*R|V)<Tg8+Xhe+TW>PS?#K;f3Iy*eo^CC=4|7 at 8{?nC<Kd&b5?7(r)o!Eo
zeNiEzO>j|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{<K?>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<v=-#d
zPe=C-uT4pYEul$Go;-JsBYA-p(NEVY4!6(Lo{RVV?r{_srZ1pj7&dmyh<TSbd6_cj
z&d-jQkLrEPIli!g*TW>=A<NZNO3m^W$T~ho$lkJnQ6CBf2wX6Nv+KvYlVt)fafj44
zoko~)m at b5g@A%blPwmNIlWvBZ!EIh)b(lG|s%9CqRI%$PRk{&29Bv~P;-fpl4V0y)
zXeQe>_3&S#<YATX$*}qx at a(Hb%vkXAkv|oJ<g0f{JbKH%@$oRnnZA3Onb)&i0FAeQ
zcF3Z<mA8%(eu??hIrE#y_|c43haT`^RViOBO?<Fhf<}3B{y39KNw*Nub#`FYd2&N=
zCySTmvw^7G-6-*!tQKZ%`I`1NIB1=6t9CHs_eD0pdt(@e-&UJ<@`}eYUYwfK{vIya
z9d0m;AoFTbIKQE$V+L>XV%pDAT}n+bYh23TCezhKZ}GhhtiM0Zg=WRQ<QZ+^<wktX
zeWxDIIW6P14v%LKw|eW<Fz}?X3o_F#8>Pa#BG at BTRp4*-{kn)!8dJ9C&<#4kIy|GY
z#5!rP+i<O2`lkGBVW$dia5M77p)-HPNE1p$=FV%f%qdrX6epSId-ar+GUAAozj7rJ
znkHZK!;33{z=-F6)dui+6Ip(?&;g=2*89^-G{m3U+}E?B>{+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-<S4xAnE-=#+A$q)qwewDCexKTQIW at ge^b0x{p&zp
zv)1knW2U4Z6)9f|HH-*r_z)VAx|DsK|2zD`{Pou6fTp_c_h8jCCYN`r!>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<U}myEZn!V96J5|@Vv`M6<XrL<H}cr0xt(zhyHQmXMfW%J=T&8 at 4X?h<
z?|nJhuH_5?ofIn4kAC^REb4~c%$p$y=%-5Lm`BuDOP=fVt^C)?3AQq(b=#IT`ZDpJ
z+YeCL$J6#_jwACMQd0=cwYc+(Y$3SKsmZw(fwKD2LtgON!%j|2OTlflmaDDT12hQU
zOiW!KE`7$a_|empj-TJqo3}JzW89eIJpH7(RC_szal+RYR2LdKdv-3b=Xxw-zCTT9
z=V at 7BA09p=R=!j=ovRg>>GvpBr_<E_6o}V+m&~oC+dcOf at XYW|oRWy;C`3Oh+`7ni
zd%mii=d`uyb6`5kU)*-hcE{&{?O#*};g{v>K8!0hsc5f at DiOG36)C6L(XWd^b^eYK
z!Kc>GE=yc?^Ql=%8JaX<VVydlH&O5r8{v(tc|o{-Y|}e+i56Wfe^hB-^UT6q2U~x?
zN805J9lSjgWw*Q{pvmdH<}<?Ez7;<-B#}dAI0k1M33xs*7!RF<RdqPzn`&aCh?=1$
zModkG{SweLT-7u@@p#w47x827+|G<?C_(ILdqe$qq1x1#<=mZ9Mvm$v1eUtB^}>Du
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^zWU1w<J<7yw3
zuGAlYk^1+i`S>KnfwB+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<s_=ed8lo%sHQ;7kE=)<gFY*_&pXP)3c&n&JM3Bu_>|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=o<l!S&$opGP**E<M
zM&WrdYdPvq!(H@)mB*1k*b51*ERiKXXOn`8<;jvcCrc~6vUb$$V)H@|DjJG;Pk>V8
z?*2~@2R at 0Zfi3zbyEf<m=H8!sD{2%s{dP*rv at SIkHOR^yt~m{><!mc=vx_-^4LYfN
z{q{PRk<79jb0$*cqv3G+kRloy!CGk!j=B-yI$T(^%d at 0TK8gWmIFCbUofCvXDgG;V
zI_G!GMd0~?8UvqsgA($Mi at z5>j8!<)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 L<mdC@@iSlv?5J{8kNcgTDEg*LU>F^$%|nu^e9mt+4KKec|}F
ziIGDy+ubEXb9DRlTky2_1$lqef^EJgd}?yLz+s9!2ydS_<z!WZAC+n?c+~KJuiCqS
z4W-e=NN%o`x9Q?Uj(A&Lz~t=%jE-bVG!I7YmJ;9F$I&gv3B2_GlHSw~SAz6NZBkZG
z_?4gLE43 at Gq|(V*v}e=vIzereNR;q41KCk;JXNEvGm6T!t63_Elb4e9e}-}cxBqe{
z;6v`(Wq-?{B5#>z(necF<VNTz3*9Z&*J^rl#=QO;ruMFtabvtD6Yt5vtEtOGk=J)V
zO%TvZraoAd{R<JNftZ?T=d&)UWf#>~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-`pu<K+(cix_l?krip>T5s
zCaP}2{VCv}2=R0PpVBKVg^~|>-3S;=({sXZH`LqEYFot<C@!n^hlc;5|K5STI1ywG
zW#Ex?k}H1GLb{NCa at E@0r|8L04vuG|6QhDuI%fW-?<SpC%Y(eqm=mWTIE+%qoHNUU
z=(QrON}m?}#1)^`&(9+g{nC6d5X@!WL at i9KS4bzr`&?m^009i%yRXm4>?fLn3umNE
zm8MGQP=0(EmfIQ>Uz<g3m}=K0;1Kx_NX~bEnyozKSQhGBAT3^vw9QvBYqHitQ1iLv
z6=lrK-$rp_Y(>&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@>&OXVRRPNWv3i<Db8K1zA8eRTi-6j at MlX(-lL|PW{Q9?Bhwe3-Nbn;8#Frw;
z!65rzq8_1aCd|@3D}4E71?7>7nwQp<YVp1LjKue)IRI6E{{dZYSogkuG{W;|<>aFx
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%<bS{oih- at 9X}2YL~i~E1r7E;kHP)
zWT>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-<ee{-D_Jbzs)^MvAoMMq`{wI#oUaI$$p<wI1`fL;=8#Nm~)>>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*IBS<b(jYUdHLOPGL(9
z3eBi+5L^k-q!YDAU(ACg0q|ze>wxz~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^*<?BLB_4`|jiXFBd-xP|QjThH at MEPFfTj214
zF54nOEpLGGHOMq7`=;^3bgB{m;K7H3 at VnlyoU6uN2@M|}{S{<PU#x&}7 at uFS<!v)g
zyYwf at YI-OCee*&chp33}V^62DG%MV^;M};sWo%4tCPeY+PfDNJ<eJ7`OL0EHIFV++
zoa={t7_gM0nQ1xf^Y+AHSvbGlL3r?zL3Hre6pWghsmX3%_p98`E``fsQtF!QJ>AMi
z%_|QjxYh<TbJczNOLX|}<eF2&WIJEBp8;HTmt9j*cXhIwY}2SJum-D*<~nn4k>$Zn
z4<my2r*rk&WPcidiXxy$U;GP8t1?O%0i4UEO3;~Fy5F}i)DdJ!OUwXkyCog~f~-c>
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<LOPtE
z{<i>=?~<$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#TNyph<G*>jfO4PkH+<M<Gbypgvr$s<-
zV!O2f%lpw8Q2w3MCB0DvyEy3#TgeM==taKrX>_R4IO7t|`Mf`@inZUF??hUQ(AU--
z<kB0l0QHv=6os6eb`W>PBY5d0*AT^PF0o^ofY~A(G^=;2;gU<Bck2Qij+750i8sCo
z#n`Pn at 7&&wYtQxu5Kd_oz(#oc*C&vkdimTqq?<uu<cHDkD=~fCu8^Lvz`2J;i1$%z
zT$3^K9y$<hXZhzcmVLa-rDO{C16)n9Id%^|rhfnP(9n8Jcza)WpX&zyE>;s&U#q_A
z+E6RS5NzCkT*e4QZ~P5BhGXAN*&U1<9xv;*6ge1`<rh1Yo0zbt;TVn$A-+ at B1_MjK
zns3 at 6ouBO-UDLA>${!lRA<U?~ve(MpW%`yH6Oi&^-7G)KS+t27K5ZgvsFYuJJuQ?(
z)9Sa1lN{YHIO9E5>q6R2*nH-&6z=)7eVyWYYOBsG&DTTS_ivBdNVS^p02IJcSW_O3
zXKfUZ-9|NUG1~6r0ah{b73Y?XO_Q5U<Rt3TrSmf{jW15sX8<qY)$`GGfAnzZ!JQPh
zl;j)KtQQxA5OXwFG3`X1tOuP0+zau!n<)X2M%esIwR at e@Bbn5$wFX(xIoey@%beN8
zmVmWI7){O$m2EKfzv%HLTxPOgMgK%=W2ATLiQ`Kc&t&~yuRo^#vBhN-44bJR|Bn{n
zm~Q*EquO}&z{SBFYLO=iv0Y+~_5c at Vdl_dj1CscZHb~A{B%dh-x12JM>En-Qf6Eie
zVTL6;Nm$*zxUD1LMFVw;0aAG0?4<kK!SxdvXPY8IRm%>DI`(atVh#a&;kQ2zJHE1z
zzzp}~tK48Qutwdw0}t{O2c+{TQ_nh)RIi-mv0r<(3GW%8+Du6M#jkE7TV;><fiHqr
zx<Duiv0N*I2fT(pmsv2rGgV6F0--mRfKL+`{1m+ZJE7F{kY$h958>?5xch*K86VK@
zv4~>0pQ7MJI}$$o1%ZM+4<d8(;2z;l4*1Ich`9W~W#<pl4N`vJ*N`E(RIkm#>XT09
z)mcFwb4j3__f~4pn<y(ySfdW(o6s6V`S06sO27ybCEDa;UggWLT28iiK?Ua5|C5qq
zwuf$kskGM~7PaqD^QpEDrtpW;B>)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<Xc8*;FNG)c)oOkp=atBqg6Fwct}0i7oFPS32y>}AGy{e1F02$Es?
z>nMmfQX=;~PAYOvfx{(NZ11{PV(I?0<gw}^+Oaf`|07s^N;*Duvq-Yry&@^l-x3gZ
zu(ibo^<TU2r(MYo-csKJ^$kUHZGUX{71z6beZMGwP~+KH_X5(Y%=?5`OxvT36;KKg
ztzJsPY=?>MChHNt$NU<vj>W>}y;%%JqB&1ARo8aKJFC)9_)*AC9`~hT-l`{<o%@ds
z at PHr(7VN84Jx>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~2SG<j)AG0-LpY;8pq>h`XneVtWJ5+qb
zpg=kN at QCfI%JCUmWnV^C{V$2ZJq^}*@h>6hdVgK#FPO2UtV+L6h+<O^$l>*NeP46!
zeo;8I%$27`2htjMyO3kf)<AQ)Wx+<&Zr3Eu2(cD(K36ATnooCB`8oH60jDzkeN64l
z!oYKp%B}w-UV(^TqyyF-)1}G&>x6^=O&5}vdjHn)<kvN4<}m6-&oirg_cSv-wRZ(#
z=Q*$Ph~z+vsYtg7I;u4I+hUje$j*ShtNcj(>$kUW-ug&I)lVx28LB5i4dxAR0;QkI
zC%8l1Vcrd}9?lwWNbHa$ZPAGgh#IB4Lkh6qa{r;g#kMli1#QKtcenIsviX54k09h8
zNqc;~?inqYa?l&~v9&CMW%<|+3-oc{M<z&dA?_PJWO)ozICp6##-w6nz-Fj1+hNAm
zp|xyMKW2_v6aKi&a=dxfK`|V(FR!NQ&5_J#eZqxBwErVQ6e&74n?ZJC_IhCGnzKYn
z!JjhtHQll5R}N!q8gzrjD)VLdRT3qtfFW;0xT at A`L`etDABz|g*;o%(M0xFHTuk44
z+fgdgSEqmGj2Ium#`-vC7yVIev#^+JUMR1m|4twBHlgiDn8J8>=@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?IZ<xmfKZA7*$T~Z#dqN9A&
zHVjd8EIj at -L=AI#%6b4+US}^W(#+>L^-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#`<fG=!9%S1qbxtxdx6
zBtAG>X)CHNKzGNSd(H4^4Hw_Ba{EHpyRnA{iVJ0<op)m^42}No<g#++gyp<?m|b0O
zqd>Sv{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{<?@K48Px}(G7- at 6ItFP?~1GFPn%<D-QgBx?q6ZfM6B*l3kTQ>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`>
z9c<CHd*Iwkih|}D9}US;;HC2T;uGgp$Ni%skMa=;2H?Dq>sS`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^<Q?kN-m?u(
z&-AjP4Dv}mQ-j at 0ovKIk&+s8+=jW(N8I1}`;Qy)t@=@8bE3L`aEw7y at MUjenlnzsG
z1z-302mgDcdX3kU%{*}>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<MV4f&>*@H1TW6vD$oJ9i6qktVFH0Pv
zJ3eR4^KzJuCRpi;h4Z}Ba2yl=Iov+E9=a_xmeday;EiAw9Co`bcLF;T28~l^$OCKO
zmS7E>N at MF#*~gXN=AW&jK<tS8B_*ut$!6S#ADU66L6$uxGa&?ixkkBR2`SZ1=UO at -
znK&Y3{ESlf8U+|To8{`f@^(MpP!ZA0`!K5hPZBv^GK|D)Ti3J}t!ZfJ05EVPAO8IC
zs}mb5=sp_OM)N!C%1q^nJ86K0Zak2 at A&D0AbS6UK at poI>Zulw at pn8y2U%hT(W)xYG
zeePJYg|x%rzei-A3hH7&xp=`nL^E<SbYf6{@u at EfHBaB&AKDC?K`HhSQ>=?E^*EG-
zBHyU~#jB<G?u3%yY7%q(<R~J5yrSO%E!1CfE%W|wfxFA!Vy)0?L_<ud7S1V<{}TrC
zJwzs*C309;c)fdW#V-&W#2il%3Az8JCsh1RAc}SFMSkH9Ch!+Z`K;sS0XB!3`D-EJ
zvQ_O?+q#BIV)=w0>yWL7ra6g`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}MuUDr<xk?Zs<6{-m=hdCt)6OF<Rv2r
zDBe{|>3Q?Za(JHXoFq`0ByqXc$NaK<79O%doQOyih419VisZhrP>cUaY(JrY#G<XD
zP~m&aiEA3#w)gix1f$*qXiKZ17u8caCAZ6|<MP?ddw(cDos`G&qJ4h_Je%v}RQ>JW
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}<XOj>L;9UvNJD+-WON
ziG at iJdNiDgp*>d7J>XJA03Z>Z0Nu|o2$hxcqsX=E(~qUiqg=cj`^RXd>>y(LYSLg?
z at Hmm20AkdJge7};?|Jya`1NFRr+<XnE;Ys at 0{W3A>BhE%$`qbn2Q_#=@v?KW{^1uz
zZT^iDuh3rIzpH0hSUdj5-gQyxKN86ZO6q(GBEX{iih*l2%h(1PI4|0~KMnIO*<!XI
zV`=xq=d7s6&b>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<gjyvLV
zR(mE<xp5L at U$G-xg~*yVsS1PhkUECWfFjFo3(=HVX}H!s(N)e$35e6^cQ$pRh2c(m
zi203rJnGped}_ at WM;FnPS;x*07fYyA?JY<fM*V1|@x8z?uVlt_cZdp$?01iX4|^Vr
zut1RB!uv;WHL-)_8r at _Mtp5;s_Cc}|5c<OXU2HaLckLn!HnuCUwK9w at U*&ZHOY$Wm
zW6K$*Cj)P$prx&i2nz`eOvwr{ALH@$jW7cBTaU9Z??D$|g61YHhMu%Rt}*$~qdtu?
zzOM%*u%gWqpOA+{woiYF<Yk5SWxi9FE=)M$8%_|}6^LBC%l{SOB^K9~jG2Re_=fP?
z_PHfL#&^_=tT~vh13oy;_n}ki&BHr%!}GrwN*$qRLfA6RlE#v--wKTr13Yh3sND17
zT+^tR(I=32nEwyd${2>+H&$FE%#Xe*hc<a!X5WnbC<p7`)par7_kK2>E7#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*<kTABrYt=OZa~PR
z;zL8MP63uz_!$519TqW+T5<hI$62PO3k%(F?#~PZm2dF6Pdkp^w|6*zncwhpP)zwk
z7|zqmepRwzOh)8;tdYSC`GD6>?|tv0DjzGkkwN|-UD0v>ADW2uFHxNol{MuPmDX17
zr08ttA6WBgY_AEPr{kw~J<2CWykxm;2F1)*cUK=s^rVs3 at +wYlv)0dFgE`643}kNH
z+6Pst1Q2(v1(ewu;nixI%~<eGXHv~AuJTI1x`L=hFFY?+aBO;i>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
zYj1<GT at om{c!aWYGnl`E`}Q_6x{v)cZ-zWvh(25WFFVcEUd+34*3+9?(;OEq)>dJK
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*<bp<AT+yoe98voG^#_sJQl)Y3atnOA#fh at h`Nfao;?eg__e2>
zHYJLMJ)`t7W(9WlVb2_36Sb;$Y%gy>{MOmgHM+UD_;)n>Fs9JOrQ0L4Djyt6YE_S)
zuy-sxK!LOEO8QfBQl#PmNgkV$IxaNxlD+{9)Er2Z6{<Q|O_XhY#$?bPZYUkyQMzz@
zalzP8kQ$gH5Eiu?eS6|eHb3^|jZq$^cWzdRASTz#G75UKee{!;z<ZF**u;2U$+M`^
z8&&I|*UGIg$=yS-#UQ4px2oelh1utknJvPKa+(y2C5c)E at Ra`K%uvhHzjoo?(Acnq
zHP>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=k<Xnc!hiQi(IE(b
z^Q|kX#&L-D at 7|pk7Mi-mOnekL)#T?WAMQsUj)GNm4l{43#BgI-k>VAfg-QbZ`rRa+
zCR*c+$_6Xjvq5LC!m4_yQT_~s(TwN|i|#+ByB7s{bY4G9Wwn>U!nbDOomaX<RFV*J
zo^}Twh%Q<;WPh4F>?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?y1<P|Trt|YsP+1k!er!R|6GWgHKo9G
z#GIPsdk<tQ<x|Yf+zz$e+hLs9pPXo1C!`t+iE*4rovM~?&7{d{CBkol`(QCd_e^(2
zT{L%x(LN*($J=Vi%tE|(-_=`mTj(%4<r51VH3|I9SB{^|ck?)Oh!e!r>7=?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|<O6Ey&`C|7G1cT4DQ(E`nRwTMl!_t6WmOF9U<Z$^mkG%XDNCo2unJ6|(ye>?
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#<!fsB<XcSHaa2s~-<6{>u?9OJq&?1TDAvT^~xnuRupkDy?TQH+)
zHGkorY?VZA=+xdM<k?~&aq~34q!sq<odm3X2RVNNWo7`C{r)5*Hm{-gHq1~Mu&RxE
z-t+XrZis&Ts*C#3(0&senPNwwhx~Q&3-NkVpw3MTqtBOYx1~y+Nf)G at 5lIp*|G+P{
zpy|akT{lT9DoxcQ#?-wbf*HHmq(>c@)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$zc<A{q3dJJ8
z&Sa|x7O}gEy_h#5V-JBug0Cnjvb<4p>XuJ_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{<u%xfy66;>nb&n;szkJoulEVQ`fT9>Jz?x#E;f_
zADL`bnlgNinYaDN3@>G1k(EKm8483Gj4(Zg<Y3>!@@uq$9A|N!-aX?JO0qLtBtH%A
zT<MvuG&n1|GHyzb at Pp}32=q&*Z~L9N7+S}0$2kE!yxS93{}<rCtJP!|=WbB9Jx^(d
zYSO at yG<;VQ5cycj<cp#1bI0*P*n3iKMzx!)Tf&uJ2q>Vy?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-<ld1_`0dk(iS4%#a5svOjNCvTlZrjhSIUj>czy&l5mhEiZHU2N@
z$qOtsq|471l#A8hgkV{!@?<$`BJG|ed1ejTctz}s_VtS^(5E?8Vej!^n?+ykt~!oZ
zX+I0vxLt<hCIH_rvCYUdJ<n at Kx6kPLOnF|6eK`s*WV2sz7Tn-|wsE}7Vroo#yc(JI
z;A{*o_Jjs}^%&j(!u#l&TS9d01Olrj5h_=(ep-`)x0O1$A at g>84_^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-%m<yQP>RsPn
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<XScxNJd(&(NC9+}&M$tws!
zi#~ZqT?b#KnbQ!~2KsGuL$`NPf{ok#)gZ+ALbPc?yjl3%pl8$#sht2 at K^0XVKeyZq
z(}LL*YK1CmUiizMH!Y`SQvduWE&DcO`}+6SQsIA>&`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<VGK!rsC!PsoWTL(suoVeXZxcAe`u<0t{$te#>_{%%
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&<CU$XbYzTRM|l^Vn4h_ar-uQ9R*hHZ
z=pBI?ew*oV=Yx}Xj-UB-(a#GC&@U;daaq_ZB=keRQfOAbGk+`gW~*m!704=TiweT!
zl_~By at g-k+R9C5D@CeA3C|~OV(bNHHF4&j?e~fX?u2qDvK!XDT+4usn4p)dKNJYqf
z at rU?rz+HcvCVPlrs_zFo6&J-q<jrAjhV^9 at TA!d%Y`3t`Q9OfgU)QQmZ8l&)@i<VH
z4-`ZI!oO_*n4~{~ruS)LMvi;wEOXYhz##C{3W$0&4fA;S9pw!jqM=U_;8qMSG at m}@
zy><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@=<DlS5UYW&)ji^JEcQqoOBhQ_IOdz#^q>NIXVggcr_6Y
z062blYkg;lkinJ=om*O3B`*+$E}d1SkdP(wJI1O)DTv&nMSSmdmb at qpGNnjh7X{8$
zBL<DN5TraVS!zlE$LxZafSQ$vonM^b>{T0tuu#Mw_5+7^lFCd#pWPIGktUZPq=0DV
z3q$WN35_cAk6s(i4yrRV&Etcs<kbf_8vz+6N(qZa8{@%nI!5PCbXapgI_h$*W_yE$
zARHcz#e at u7iUjG6#=L!ReJ!0*Vg(5I=I7gc>Z!4y78AzT;U2u0Dsy%ra`B0Bm2n-I
zcJueuG5`f#@WSlXq6H!Yfv at 0XwE}81X7Vi3Vcg#uxERgz_Uz)KsBTd#5*5zuio_oY
zsKg%k$7pTYEG-J_!!O-z<FTXV#Gwr(*_QD?Wo_{BKc;;lc+F1%1g#_#6wSxYPoGUn
zYE?=m5X6L5>ug-$Ye(Ccz*vPR1Nq1wUWXDEvn4Z01rl*9Q8LdCoY$){H}N><ef*^A
z(r!^Y3*9|I*wFFpnbV4K{v<s2xP9|6qTJqN-ECYe;7VR2cI7Wb3u8i~o+-wHP}uWe
zBqvsw-uT?G80W*g{m4epbfvWI)YHEy(i|wbl6rPOG?+|GEKR>y&mQDGP?*FH*<vEF
z{bUV*nM~FJ9_*4iS}vJN5W{RXae)c#qCDP_MZ35?;xer}0LUE7bg{rW&dk6y*7nJG
z_WN8}F}<E~;IS^b$xQE-ZGwY?SMY=nK)44axhoT?YT=n<J>Go6^D;(XEi&@x`uBdr
zcKoe5Ps`l<PQFaylTmRDXz)oTC at rX_MrFCjC<0$;$7IKxdq0x=Cdm70TxWG?z?md$
z&MErfccQe1`K*0Dasr|Rp7om3e+u`9<(VU$YcJJYGfOT`0+-c=4!K$upwBo%dikfc
zuQVcc)7Na&#=H5gqTuAd_gJALW|ik`!|70P)eXrielIbbUSh<%g#hLVy!r5A;ib3{
zSQwt at 4AJbzVi7UBbL^ALz_@@*m8DHJQ=UrQ!<bV4G}VMah8A1(k1iQApIZp_z|OL+
zpI?+#1{a4U={@sD-kHIjl#c4kRNLpLd8~9^F!U)v>iBJ)(~o>GrSovZ01F^D<?{iH
zCy4^{9vx`{2}FmU%D*TUEz1~5!_IQ_0Zn|K^y8se;?pryYhAs`5Xhm)AU*ecJah{?
F|0k*Sbd&%9

literal 0
HcmV?d00001

diff --git a/doc/manual/thunderbird-smime-button.png b/doc/manual/thunderbird-smime-button.png
new file mode 100644
index 0000000000000000000000000000000000000000..5492b08e6e4ea98509059d80972b966052c46447
GIT binary patch
literal 7197
zcmZvBWl$VEv^G$n1xoQPR&?=&LeZjS%i_g~EQ?!lx8hP3Timr2ciG|;hs9l6+`SZc
zxx9Dgo4G%}AIWnvlgW8<l1xsXgsCXW;Nw!_qM at PT%gIWqp`kqkJlUZyo;}r{HX=pP
z(9r!=6xAVU=x79JkFUuA49v`=oVGM{4-kHAegQsS!S{k9V&WgfXg+=ull;gh>7XS;
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)<bG@$R{H!g%
zZIWk`2I^|+YX<+!{nT->u3mhmx8dn(Rv)C|H4NjY8BV?YTVQR6z0>wEqUcMEff1<b
z(`rQ*-_Lt}?0quCEBUS<;KL999zI3ahT5CKrH2RlPP#F8G8{{I0p?qycy_Y+_LiBN
zjL<Lu+4wlPm%AwweMrLDwjkmkgN^|@dKi=eDvenjhgKo)5IDO2T%rI0vS_=-rbi2p
z^YPqGgI6o<{#-%;3+wBd&aSi0WL{o_r6%QPJts6l2+8v+Pvz;JUvFD)FrzluOdPLH
zW)|);uS7f6h|$00EnOOb8_37X33`_=YJH!J*!L2wl7|e6+E9^zLqbB8JlXKIs<=7=
zF%cZjr}fwK?lcRHPMd&T#n>~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(tHq<edVgCQZL9Aq
z{jcr9$mlKQrJ^Wv<t6pUkadS45f?Y{^WQvsXfvf+IyyR)bxmDhWJ+pj-)8OO!=;{w
z?Xf@@pdNsR5LomItZZ!wr(Ny>H9AzK03}yj{teg}9WR|&H;pwOD2sdibBo;>xX5uF
z?cUHaV8N~087<~nTE>+|l$Up1OdM5^6)SMw=Aur9GK>j<DKu)J!(|wpmynt&O)5U+
zt_8K;7lOKKSlsV;P)b<84f*cZ)*>!`ZGHPRVvyJspPk_Ikml`$z~bJ8K$otIWBn>B
zK%CAUpJ1WkT@<&f at 1>pd!%Q-8KRC8X;FI_xrQf~j#P%O9?2d%_;?-!tM)=u&-sbJU
zXXBj$<HVeFn}>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;Xr<BDqKwHon#9O#j|_o%m*B*Fwb}I#jmSFuzqE3PYLBQs$OvBWU*+o
z?ERfS?%xiGWt|V=CpJrk&wCU`VLfaw<o{k9fTf;gFZC0A;nGVBAb{YP_4=Iqs)P*P
z2zy_xPa%b_c5!LjZin^4dz77dlPiY)cA4iWvB!p(95osT5IlIW#E({jmRdY`r2|n5
z;!;N>6GC}}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<!fMS!mpalW$4heKNx=_l(Gm at N>=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#OQoxX6GG<Xu`eI?(59OovHx
z^K=yrspDf~<=i_uE&rbnk0&3!jqpw3vy%$E%$pOJ;yEG&yQ2zq>CIntHRuMOkOmH=
z>1%CL`hV&iDMHW}Bh67rxuny^ZzGNH&;4zdHGOP_ at 2<I^LghG1nl6?xr*G&+=3T}b
zqXDsFrZa4zV-M0YAP3!^M9hnMdU1-<ZXSELC_rCNmmLdnidLMe<Q_SvH`SqSn*FBK
z)NTgcWVL3?x>o1E`Txi568ZvG?_KLv^Ft8`Trg%)4PS3aXwP&;D2;bo*LPm}!|f-%
zdvLMeH9X`%>al%9u*cVoHv#NwpY@#Z7DqV0@^@R<@NT(vaEdTwb-mYrsj0pg%Ubwt
z<iL@$#alqGxQGR`u+V8Rq7{?0b~DJ?#J at Ao)5pm*B}@9IFIM<`vn7 at _0}(7V_r-LQ
z$6{WU0egn=?~CFv3%(B7su1TCu?jQA&`$zkZyHVPR&9mmYh=+7;e at Nsx_*qRtN5O8
zFQPhRr#yPs)cJ>wA4v|!+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
zCnqPJwpXv<pZBGv2`+qucO;-SCIQS-3Bm!);gf6qYV>KQ+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)GE<EZI2Ongt
zB6_iZbp<8GA%j%N=0JFu98te&6Mo|XQ0pqH(?3t#X4+Zb_M>7AV+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|k<ZP}2O9YK5q^rpNY8SH
zfC$+C6lIzZM$uA9+*KXV+h1&i%xdnsG;0cmPj2W5jFYFc#|om at s1Ql-qtW&g5mcsD
zJ&kk#HJaR>JJBxV)Mm;)8V993>poT{&-ZP%Ug&#*^*^8o|8y(`JG#OE5O=~L-PPic
zfN3?=cSQyOg#jXHw?egA4j<D<QUNJAn9ocGZ`NX5V2{$>Po!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?Y<sYBa{?w0Y*H1Fp;e|0UfC1(BsF6p=a`omQ|>h%^jWO@(hXP5x`P!xcOlHb
z{u$H=gLgt>i|l?z%t?Fq_<U1cEsqJ5CnpoiHA_6GW1anpat{iJc-1mpv>+9HK^ZI^
zQiO*oE`-r1xA6ytj-TT2*D9G~vy<|z56{~wy3MH~)zbp~+xq+h^gwscb~Q1X?!oQH
zO`msM$*O+?ks*$f#dLQoW%KsxlXCWN<I=zKPOln?1+<`@XX^YAyYyY^7>NpZiN<qV
z6!6h at QyyO{z9W6)KiYOb%y|n-2|%CYDzExVG{Y%tZK*y~YOGm7#6EEW3oX2r&5Ahi
zXgdXxv%rG37QZb0Q+DcVy_QISYZ<P_6t@|dl6CIKWmu-46}RVl5=SvuHH%!y$PGSd
z<tJ{^*{RctWA(x$n}|-EeL-4al+gUlNUEjfM`QfNu8~;z)BXj)grMFF*A{R*xsSig
z25N4Vl>!gmAB;D`?*y;?F#H5wSE#<NcZjSvmUKqw+e_p{lD?aO49BSD?5P;#lYu%6
z2@;Xa7x9MOL0?RpUaG>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;Z<rBV<Xe?8
ztl;TY6Z55w{FcFJ3Q>J-2jxBwg1p<P3wHgetR&3{?m4=^crE1in(@p??1za_wk0N>
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`M<KcG7^7Q=a0%E7p!d5<a4<Z_9A#V#91Lf-K6qXw6lt*<dX`Q8T7)*5
zf|Jk5O2==iy>L3Z2h5pRB6eM0oS%PF_$4>$TwQbgjQ*RENx(RNvF at o1UeNxxqURt!
zRiMwOMi>@I2 at fxi{!{g%8;HxTX5B3(#tz#rBKCgUzgVvLs{lot8z+~hj6Y;?j)k#R
zElxW*I5Y^+AP!}8ZS<n=0BcxC#gT;q3Pa%q6iv7Fr?hd7)?1Fq7n4O7SgFB1o~vmE
z`#nb at ssaGd@BZ6t-)E(R;Kns_=pZFZ1RzyJgm(Dhe$ORDQhG3pij$8;9Xb&)Zb;Ac
zG0%VSyUPInUKA>fJjk956NHA>j!}j7AFO4_ at r<dMv1Y>^exM_&fqE2sGKUe|&cPV8
z`_Dil344?+A>4c#8nrDd<NN=0;mwzJE?OR<zObdk|M4_P0NT?_;{O05evX=g#uOg|
zgrUQj7=B+2M1TFmISRh;mh8-Lb_EzXA_!0`_UjPT^Z$<p=2IR;*S^MzEui0gRsIs{
zKSBm*N_dURv3VJe>bXf at 6x^pWr$Hc{+1iciD6U<S*yFjf1FC*Q4IbB{CERoxh2o)n
zquFSP0Cfd(h^nb!UiB(^?rr(6$aBAV3r7!=OYJ`f3+2PLC=~yHzOpz0!ubs8%mb$H
zcFX<<0)oON9$Q*(yEYeJFJFeD=Css>pK?3z3aDu{W_VfIG_Xgy)d0jw=J(Lp+WPC)
z?G}m%`rClWO!avB6aG^O#g#!DeA%5&MhVLKymI9dAQ1b*UDd<E at F60%O67N#?f_<3
zVq&^!3H?*Vg^WNAOMwsppN)0#{HVw4ySak3t`NU+39q_Uorx%{3Dy^(-QnqcaBX1a
zHapD0A60D9 at n%>`84CRQr-6qXK*dEy`*3M6I^ZM-iWxY;0iy(6X1Yyh$Qf3$tsQ#X
z14Z;e4fNAuvrq at 4XeQBCUW#Lzt({&ix%<!KQScsas0oj;W8?;fX{#Fs)WOFn`_y$y
zQ7Bkh0_GqF+TwDl*;(fGgh3GTQeG+`efMmJP%H#l+8Ykd)*E>vEH^uPr<`9M3q)R>
zsNaZotV&AnxgC1g7)Ii#YZRau!?{4W00)}!2Go#27*=XSW0uq0rwu_`b+A|F=ZxpA
z>N7`!Kei;bdR<z8N{n#3!`mm&0Q?4Jbn2j=3&tpY){USgWawn?xW<}pRq%KD^I%Bg
zTi0Ew=^*TTY-;_&SF?RM<BBb8)O_jb!&?D{J|ZK;qi<v7b))LNf70WQQ>PXdeqclo
z$p|Dp*`nGI-4r!Zoc=2H`z)LquP%#sa3iEBwJ7G at x8A?jNR&<I3{K6L*%nqPkl&eY
zWGgxD`E#7ThyFA+X}QLfb|Gd)#`wc$2z7?{<bcIu3lzq*w+D(Lca2IOPR7aZsOXb<
zPF!A*^Q`{VRPGkm{;Hk%j~DgwhJ$fD4eOG_t7w|@zBMWFG|3U8s$uA$>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!k<D<0m!uP(63ZW}piG;a1FLB^
zrvYt&!OOYg at 2@nJq0NU%5DvhDjTe(FmJcS67di4ZCv^i#DpD-ucPjuo2xqUr-KYhB
zRD^YBLxC=0$PH at j`IkDHYrC`kTe5QOlg6DL;IMc(MYC4GWcnu{-=;cmuf4!$jjarf
zMrLcEgG2D*r);b#LAjtJnR139uTu=39FLwd4cwP(g?-4ChK6w$q(u*hT_*{&lnn8~
z+HDa*%-JmU4&03E=xfhF!bDViw2P0Z@$s4mq~mvhEkARRRnBwBX8yE|#x-Y)=3cYz
zP$GR2Q><E|J)#&ASjRk%i7So^oT0BQSO&yI&*JEXLOKMxk{|-w^^plXU<8gkkiCMh
z6lZWY=fHTX3~!j6jTp2Y5tHoMJzE+*rIP_OD{N1Xjv4e><n2*cI0jF1;6g1t%DX9d
z!8<VB-@;1&kqm)Tao%l$J3dI$LWhV^dgG0RppA!OmAl89xis77##s8s<{tfRjIS1m
zg1*T;mm!=3(#2}aeJIXIb}D?iyqcXH5&DR+M%@Okk=JK%J33EwK*q!mOHH33Q{E5~
zt7Yick_^vSjK7q^^J1{c!9ICkLd6-8q~0*#1*yZ5e~xQB9>IxpDfB5<0cFe_G`%Lk
z6RbZ<J|)Y`Z_sx}NFs&OaA^Uu^hOx2;bh%|yA?Aa<@);H0rO!1PN*Rd1FX8+NM(OD
zEQX_Pi66EipRfT4bp9$vvgCvK{bk_-2?pC+0EhdI;a>vkg|GDORvWD7cz?9qB#f$N
zF14COu$S`}O*UO{;^82delqvph5_xWDVhK}L(KH$e_Y?n+pQXPNarx1gV at 1Aqvv7p
zOX?nd<kxCnQZirAKmryq5BR5T4tPS2`|DoIOn0!3q6Mhl0 at dlWxPco`D(&50#`Mt%
zZ+MuKyFwZdSg#VBX2r8=q#7n$7tN20l#R$+seNIUBRdS!Eo4-6r3K)}E#LOUmLNk_
zj^0~kM&Uz5O*BVY!8cZRv9^+k`ifM<ggcoa6m!NH at dud4|LYKScND at -T}ly*;#;Lx
zmeMcq>R!W&1n3nXnMh)w!j&XmxK at j45-KNUtg<=<Bl#Uy+ at y1ajaKz{Gu0A>G%Idp
zNn7mcjfIOiYg5{D?-Uc5U$)wnIF-$CQ3ELS6ikDk(wx+TKse>tP5L>(D>ADFSS|{;
zPMm)pz!8<dvE}e7;st`q6qtmq*NCLBrY^0;3xWJ6OCZxyjiE6T#Go&K>vxM8kzb##
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<Xm*|S^pTb_t}I;h2&n{#CIl=`Q9Xa1X+v|L1)
z+Nau*Y4!aO^&(_RP0f}%u&o9<2^E7Gm<3z9!U9Id=J at A+Xjadcj8il@m48WA{a8k<
zlX*W*rlA>|^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.
 	</p>
 	<p>
-	  Currently, only <a
+	  Currently, supported usages are <a
 	  href="http://en.wikipedia.org/wiki/Https">HTTPS</a> client
-	  authentication is supported.  In the future, Scute will also
-	  allow you to use your OpenPGP Card with <a
-	  href="http://www.mozilla.com/">Thunderbird</a> for signing and
-	  decrypting e-mails using X.509 certificates.
+          authentication and S/MIME email signing using X.509
+          certificates.
 	</p>
 	<p>
 	  You can <a href="documentation.xhtml">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 <dgouttegattat at incenp.org>
---
 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 <dgouttegattat at incenp.org>
---
 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  <https://openpgp-conf.org> */



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  <https://openpgp-conf.org> */



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: <c5d8a530-f9ed-c406-2350-21f235b8df11@enigmail.net>

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: </pipermail/attachments/20160806/0fbbe46d/attachment.sig>

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: </pipermail/attachments/20160806/6547c897/attachment-0001.sig>

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: <c5d8a530-f9ed-c406-2350-21f235b8df11@enigmail.net> (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>
 <c5d8a530-f9ed-c406-2350-21f235b8df11@enigmail.net>
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  <https://openpgp-conf.org> */



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  <https://openpgp-conf.org> */



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  <https://openpgp-conf.org> */



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: </pipermail/attachments/20160806/8552ac65/attachment.sig>

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 <bjk at luxsci.net>
---
 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 <stdlib.h>
 #include <string.h>
 #include <unistd.h>
+#include <gcrypt.h>
 
 #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: </pipermail/attachments/20160807/c6dd31b5/attachment.sig>

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 <ilf at zeromail.org>"

> % 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: </pipermail/attachments/20160807/2036c028/attachment.sig>

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: </pipermail/attachments/20160808/681495e5/attachment-0001.sig>

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: </pipermail/attachments/20160808/9f166755/attachment.sig>

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 <ben at adversary.org>
> uid           [ unknown] keybase.io/adversary <adversary at keybase.io>
> uid           [ unknown] Ben McGinnes <ben.mcginnes at pirateparty.org.au>
> uid           [ unknown] Ben McGinnes (backup email address) <benmcginnes at gmail.com>
> 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: </pipermail/attachments/20160808/8aa2e920/attachment.sig>

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 <bjk at luxsci.net> 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: </pipermail/attachments/20160808/d4303bf4/attachment.sig>

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 <dgouttegattat at incenp.org> 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: </pipermail/attachments/20160808/60222371/attachment.sig>

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 <dkg at fifthhorseman.net>
---
 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: </pipermail/attachments/20160808/9bd88ace/attachment-0001.patch>

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: <cbcf674b-ab7a-dbf8-db39-2879881872de@fsij.org>

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 <bjk at luxsci.net> 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: </pipermail/attachments/20160809/932445ce/attachment.sig>

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  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20160809/11f511fb/attachment.sig>
-------------- 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 <dkg at fifthhorseman.net> 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: </pipermail/attachments/20160809/9dc5c29b/attachment.sig>

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 <bjk at luxsci.net> 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: </pipermail/attachments/20160809/e5083ce4/attachment-0001.patch>

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 <dkg at fifthhorseman.net>
---
 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: <cbcf674b-ab7a-dbf8-db39-2879881872de@fsij.org>
References: <1ae83c4f-90ba-1429-edbc-9489f3e8d673@fsij.org>
 <87k2fva1zn.fsf@wheatstone.g10code.de>
 <cbcf674b-ab7a-dbf8-db39-2879881872de@fsij.org>
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 <dkg at fifthhorseman.net> 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: </pipermail/attachments/20160810/c3402c96/attachment.sig>

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 <bjk at luxsci.net> writes:

> On Tue, Aug 09, 2016 at 10:59:41AM +0200, Justus Winter wrote:
>> Ben Kibbey <bjk at luxsci.net> 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: </pipermail/attachments/20160810/19c21a4a/attachment-0001.sig>

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: </pipermail/attachments/20160810/408baf8f/attachment.sig>

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 <dkg at fifthhorseman.net>
---
 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: </pipermail/attachments/20160811/e200c6f3/attachment.sig>

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  <https://openpgp-conf.org> */



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: </pipermail/attachments/20160811/4366db55/attachment.sig>

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 <wk at gnupg.org> 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: </pipermail/attachments/20160811/986930f1/attachment-0001.sig>

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 <dkg at fifthhorseman.net> 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: </pipermail/attachments/20160811/7140e46b/attachment.sig>

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  <https://openpgp-conf.org> */



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: <d5141b96-9648-9cb6-a649-68fd33137cb5@sumptuouscapital.com>

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 <kf at sumptuouscapital.com>
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: </pipermail/attachments/20160811/f0ed5999/attachment.sig>

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: </pipermail/attachments/20160811/cd7c880a/attachment.sig>

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 <dkg at fifthhorseman.net>
---
 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 <dkg at fifthhorseman.net>
---
 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 <dkg at fifthhorseman.net>
---
 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 <dkg at fifthhorseman.net>
---
 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 <dkg at fifthhorseman.net>
---
 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: <d5141b96-9648-9cb6-a649-68fd33137cb5@sumptuouscapital.com>
References: <d5141b96-9648-9cb6-a649-68fd33137cb5@sumptuouscapital.com>
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: </pipermail/attachments/20160812/5fb2e7f2/attachment.sig>

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"),

<scnr>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  <https://openpgp-conf.org> */



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  <https://openpgp-conf.org> */



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  <https://openpgp-conf.org> */



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"),
>
> <scnr>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: </pipermail/attachments/20160812/5d42f6e5/attachment.sig>

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: </pipermail/attachments/20160813/3e062860/attachment-0001.sig>

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: </pipermail/attachments/20160813/9fc73612/attachment.sig>

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  <https://openpgp-conf.org> */



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 <bjk at luxsci.net>
---
 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 <https://gnupg.org/donate/>.  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 <https://gnupg.org/download/mirrors.html>.  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
<https://gnupg.org/download/integrity_check.html>.  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) <dshaw 'at' jabberwocky.com>

  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) <gniibe 'at' fsij.org>

  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  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20160817/9a9f4612/attachment-0001.sig>
-------------- 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 <kristian.fiskerstrand at sumptuouscapital.com> 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 <wk at gnupg.org> 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: </pipermail/attachments/20160818/568019e7/attachment.sig>

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: <CABFfbXs7OQLO3XZFMFT-gT5WPw9zQN6p7Hs7yNgfsg3NpLDVOA@mail.gmail.com>
 <CABFfbXsRqxnYFKDS4otjBEHchVKTJuC-aEcuvKfRYKppsaPLQg@mail.gmail.com>
 <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: </pipermail/attachments/20160818/e592fe8c/attachment.sig>

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 <https://gnupg.org/faq/whats-new-in-2.1.html>.

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 <https://gnupg.org/download/> 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
<https://gnupg.org/download/mirrors.html>.  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 <https://gnupg.org/blob/>
and <https://twitter.com/gnupg>.


Support
========

Please consult the archive of the gnupg-users mailing list before
reporting a bug <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  If you need commercial
support check out <https://gnupg.org/service.html>.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.

Maintenance and development of GnuPG is mostly financed by donations.
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) <dshaw 'at' jabberwocky.com>

  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) <gniibe 'at' fsij.org>

  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  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20160818/866822e8/attachment-0001.sig>
-------------- 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
 *                                               |------|
 *                                                <hash>
 *                                                  |
 *          +---------------------------------------+
 *          v
 *         <20>
 * pool'  |------------------------------------|
 *         <20><20><..44..>
 *          |         |
 *          |         +------------------------------+
 *          +-------------------------------------+  |
 *                                                v  v
 *                                               |------|
 *                                                <hash>
 *                                                  |
 *              +-----------------------------------+
 *              v
 *             <20>
 * pool'' |------------------------------------|
 *         <20><20><20><..44..>
 *              |         |
 *              |         +--------------------------+
 *              +---------------------------------+  |
 *                                                v  v
 *                                               |------|
 *                                                <hash>
 *
 * 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
 *                                               |------|
 *                                                <hash>
 *          +---------------------------------------+
 *          v
 *         <20>
 * pool'  |------------------------------------|
 *         <20><20><.24.>
 *          +---|-----|---------------------------+
 *              +-----|---------------------------|-+
 *                    +---------------------------|-|-+
 *                                                v v v
 *                                               |------|
 *                                                <hash>
 *                                                  |
 *              +-----------------------------------+
 *              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  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20160818/95ffec52/attachment.sig>

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: </pipermail/attachments/20160819/42b220dd/attachment.bin>

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 <wk at gnupg.org> 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  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20160819/e3e9a80e/attachment-0001.sig>

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 <astieger at suse.com>
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: </pipermail/attachments/20160819/a3e8d5fb/attachment.bin>

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: </pipermail/attachments/20160820/70047a0f/attachment.bin>

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  <https://openpgp-conf.org> */



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  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20160820/fc7a728c/attachment.sig>

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: </pipermail/attachments/20160823/96009b98/attachment.sig>

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
<https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc>.

  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 <pdp at exim.org>
  gpg: /home/pdp/tmp/gpg.XXXXXXXXX.Am0UHa5O/trustdb.gpg: trustdb created
  gpg: using pgp trust model
  gpg: key 4D1E900E14C1CC04: public key "Phil Pennock <phil.pennock at spodhuis.org>" 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 <phil.pennock at spodhuis.org>
   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: </pipermail/attachments/20160824/47e1a245/attachment-0001.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: </pipermail/attachments/20160824/47e1a245/attachment-0001.sig>

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: <C0812434-333F-41E8-A524-6FA0BB60111F@gpgtools.org>

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: </pipermail/attachments/20160825/30383b14/attachment.html>
-------------- 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: </pipermail/attachments/20160825/30383b14/attachment.sig>

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: <C0812434-333F-41E8-A524-6FA0BB60111F@gpgtools.org>
 (steve@gpgtools.org's message of "Thu, 25 Aug 2016 11:31:44 +0200")
References: <C0812434-333F-41E8-A524-6FA0BB60111F@gpgtools.org>
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  <https://openpgp-conf.org> */



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  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20160829/48b561a2/attachment.sig>

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 <neal at walfield.org>" [unknown]
  gpg:                 aka "Neal H. Walfield <neal at gnupg.org>" [unknown]
  gpg:                 aka "Neal H. Walfield <neal at g10code.com>" [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" <neal at g10code.com>

* 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 <neal at g10code.com>
Co-authored-by: Michael M?nch <michael.moench at marktjagd.de>
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 <dkg at fifthhorseman.net>
---
 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 <dkg at fifthhorseman.net>
---
 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 <gtk/gtk.h>
 #include <gcr/gcr-base.h>
 
 #include <string.h>
+#include <stdlib.h>
 
 #include <assuan.h>
 
@@ -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 <neal at walfield.org>" [unknown]
>   gpg:                 aka "Neal H. Walfield <neal at gnupg.org>" [unknown]
>   gpg:                 aka "Neal H. Walfield <neal at g10code.com>" [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: </pipermail/attachments/20160829/49945457/attachment.sig>

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: </pipermail/attachments/20160830/6fc970ab/attachment.sig>

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: </pipermail/attachments/20160830/a272a140/attachment.sig>

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: </pipermail/attachments/20160830/70ed6c83/attachment.sig>

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: </pipermail/attachments/20160831/58b8161b/attachment.sig>

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  <https://openpgp-conf.org> */



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: <d225bd6a-57dd-0bad-2958-8802ad91adb9@gmail.com>

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: </pipermail/attachments/20160831/2fb81e8e/attachment-0001.sig>

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  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20160831/bfa2b586/attachment.sig>

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: <d225bd6a-57dd-0bad-2958-8802ad91adb9@gmail.com>
References: <8e6ac12c-dd65-74db-4adf-14cf4ad355a8@gmail.com>
 <87oa491kzq.fsf@wheatstone.g10code.de>
 <d225bd6a-57dd-0bad-2958-8802ad91adb9@gmail.com>
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: </pipermail/attachments/20160831/ca69380b/attachment.sig>