From dkg at fifthhorseman.net  Tue Nov  1 01:33:01 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 31 Oct 2016 20:33:01 -0400
Subject: help dirmngr be more idle
Message-ID: <20161101003306.12261-1-dkg@fifthhorseman.net>

A patch series follows that aims to help dirmngr tread more lightly on
the system it uses.  In particular, on my system, a default dirmngr
process wakes up twice every two seconds and then immediately goes
back to sleep.

This represents a potential problem for power management, and suggests
that there is room for improvement at least in the default case where
dirmngr is mostly idle.  This concern was raised quite some time ago
in the debian BTS, for example: https://bugs.debian.org/507361.

With these patches applied, an idle dirmngr is actually idle --
waiting in the kernel's select() for activity to wake it up.  It is no
less responsive to the user, and it doesn't burn CPU it doesn't need.

Comments welcome!

Regards,

        --dkg


From dkg at fifthhorseman.net  Tue Nov  1 01:24:33 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 31 Oct 2016 20:24:33 -0400
Subject: [PATCH] Fix misspelled dirmngr
Message-ID: <20161101002433.12106-1-dkg@fifthhorseman.net>

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index c211979..47de5f8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -200,7 +200,7 @@ test -n "$GNUPG_PROTECT_TOOL_PGM" \
       && show_gnupg_protect_tool_pgm="$GNUPG_PROTECT_TOOL_PGM"
 
 AC_ARG_WITH(dirmngr-ldap-pgm,
-    [  --with-dirmngr-ldap-pgm=PATH  Use PATH as the default for the dirmnge ldap wrapper)],
+    [  --with-dirmngr-ldap-pgm=PATH  Use PATH as the default for the dirmngr ldap wrapper)],
           GNUPG_DIRMNGR_LDAP_PGM="$withval", GNUPG_DIRMNGR_LDAP_PGM="" )
 AC_SUBST(GNUPG_DIRMNGR_LDAP_PGM)
 AM_CONDITIONAL(GNUPG_DIRMNGR_LDAP_PGM, test -n "$GNUPG_DIRMNGR_LDAP_PGM")
-- 
2.10.1



From dkg at fifthhorseman.net  Tue Nov  1 01:33:06 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 31 Oct 2016 20:33:06 -0400
Subject: [PATCH 5/5] dirmngr: lazily launch ldap reaper thread
In-Reply-To: <20161101003306.12261-1-dkg@fifthhorseman.net>
References: <20161101003306.12261-1-dkg@fifthhorseman.net>
Message-ID: <20161101003306.12261-6-dkg@fifthhorseman.net>

* dirmngr/dirmngr.c (main): avoid calling ldap_wrapper_launch_thread()
  before we need it.
* dirmngr/ldap-wrapper.c (ldap_wrapper): call
  ldap_wrapper_launch_thread() just in time (before any attempt to use
  an ldap subprocess)

--

A dirmngr process that never looks anything up in LDAP has no need for
a reaper thread, but one was started automatically.  This thread wakes
up every two seconds to look for ldap processes that might never have
been running.  We won't start more than one reaper thread for any
given dirmngr due to the static int "done" in
ldap_wrapper_launch_thread(), so it's safe to call this every time
there is a use of ldap_wrapper.

If someone wants to do further dirmngr optimizations for ldap users,
the reaper thread itself could use dynamically-calculated timeouts
(and probably needs to be alerted dynamically when a new ldap
subprocess is available so it can re-calculate those timeouts).

Note: It's not clear to me how to test ldap access effectively; i know
of no public ldap services that i can verify against, and i do not run
my own ldap servers.  If someone has a publicly-available ldap server
that developers can run tests against, i would be happy to hear about
it.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 dirmngr/dirmngr.c      | 18 ------------------
 dirmngr/ldap-wrapper.c |  7 ++++---
 2 files changed, 4 insertions(+), 21 deletions(-)

diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c
index 970fa4a..efacebc 100644
--- a/dirmngr/dirmngr.c
+++ b/dirmngr/dirmngr.c
@@ -978,9 +978,6 @@ main (int argc, char **argv)
       thread_init ();
       cert_cache_init ();
       crl_cache_init ();
-#if USE_LDAP
-      ldap_wrapper_launch_thread ();
-#endif /*USE_LDAP*/
       start_command_handler (ASSUAN_INVALID_FD);
       shutdown_reaper ();
     }
@@ -1015,9 +1012,6 @@ main (int argc, char **argv)
       thread_init ();
       cert_cache_init ();
       crl_cache_init ();
-#if USE_LDAP
-      ldap_wrapper_launch_thread ();
-#endif /*USE_LDAP*/
       handle_connections (3);
       assuan_sock_close (3);
       shutdown_reaper ();
@@ -1215,9 +1209,6 @@ main (int argc, char **argv)
       thread_init ();
       cert_cache_init ();
       crl_cache_init ();
-#if USE_LDAP
-      ldap_wrapper_launch_thread ();
-#endif /*USE_LDAP*/
       handle_connections (fd);
       assuan_sock_close (fd);
       shutdown_reaper ();
@@ -1227,9 +1218,6 @@ main (int argc, char **argv)
       /* Just list the CRL cache and exit. */
       if (argc)
         wrong_args ("--list-crls");
-#if USE_LDAP
-      ldap_wrapper_launch_thread ();
-#endif /*USE_LDAP*/
       crl_cache_init ();
       crl_cache_list (es_stdout);
     }
@@ -1243,9 +1231,6 @@ main (int argc, char **argv)
       thread_init ();
       cert_cache_init ();
       crl_cache_init ();
-#if USE_LDAP
-      ldap_wrapper_launch_thread ();
-#endif /*USE_LDAP*/
       if (!argc)
         rc = crl_cache_load (&ctrlbuf, NULL);
       else
@@ -1269,9 +1254,6 @@ main (int argc, char **argv)
       thread_init ();
       cert_cache_init ();
       crl_cache_init ();
-#if USE_LDAP
-      ldap_wrapper_launch_thread ();
-#endif /*USE_LDAP*/
       rc = crl_fetch (&ctrlbuf, argv[0], &reader);
       if (rc)
         log_error (_("fetching CRL from '%s' failed: %s\n"),
diff --git a/dirmngr/ldap-wrapper.c b/dirmngr/ldap-wrapper.c
index 5fa3eac..f7dc649 100644
--- a/dirmngr/ldap-wrapper.c
+++ b/dirmngr/ldap-wrapper.c
@@ -654,9 +654,10 @@ ldap_wrapper (ctrl_t ctrl, ksba_reader_t *reader, const char *argv[])
      only viable solutions are either to have another thread
      responsible for logging the messages or to add an option to the
      wrapper module to do the logging on its own.  Given that we anyway
-     need a way to rip the child process and this is best done using a
-     general ripping thread, that thread can do the logging too. */
-
+     need a way to reap the child process and this is best done using a
+     general reaping thread, that thread can do the logging too. */
+  ldap_wrapper_launch_thread ();
+  
   *reader = NULL;
 
   /* Files: We need to prepare stdin and stdout.  We get stderr from
-- 
2.10.1



From dkg at fifthhorseman.net  Tue Nov  1 01:33:04 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 31 Oct 2016 20:33:04 -0400
Subject: [PATCH 3/5] dimrngr: avoid need for hkp housekeeping
In-Reply-To: <20161101003306.12261-1-dkg@fifthhorseman.net>
References: <20161101003306.12261-1-dkg@fifthhorseman.net>
Message-ID: <20161101003306.12261-4-dkg@fifthhorseman.net>

* dirmngr/ks-engine-hkp.c (host_is_alive): new function tests whether
  host is alive and resurrects it if it has been dead long enough;
  (select_random_host, map_host, ks_hkp_mark_host): use host_is_alive
  instead of testing hostinfo_t->dead directly; (ks_hkp_housekeeping):
  remove function, no longer needed.
* dirmngr/dirmngr.c (housekeeping_thread): remove call to
  ks_hkp_housekeeping.

--

Rather than resurrecting hosts upon scheduled resurrection times, test
whether hosts should be resurrected as they're inspected for being
dead.  This removes the need for explicit housekeeping, and makes host
resurrections happen "just in time", rather than being clustered on
HOUSEKEEPING_INTERVAL seconds.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 dirmngr/dirmngr.c       |  4 ---
 dirmngr/dirmngr.h       |  4 ---
 dirmngr/ks-engine-hkp.c | 73 ++++++++++++++++++++++++-------------------------
 3 files changed, 36 insertions(+), 45 deletions(-)

diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c
index 776cf95..d7b43df 100644
--- a/dirmngr/dirmngr.c
+++ b/dirmngr/dirmngr.c
@@ -1757,11 +1757,9 @@ static void *
 housekeeping_thread (void *arg)
 {
   static int sentinel;
-  time_t curtime;
 
   (void)arg;
 
-  curtime = gnupg_get_time ();
   if (sentinel)
     {
       log_info ("housekeeping is already going on\n");
@@ -1771,8 +1769,6 @@ housekeeping_thread (void *arg)
   if (opt.verbose > 1)
     log_info ("starting housekeeping\n");
 
-  ks_hkp_housekeeping (curtime);
-
   if (opt.verbose > 1)
     log_info ("ready with housekeeping\n");
   sentinel--;
diff --git a/dirmngr/dirmngr.h b/dirmngr/dirmngr.h
index 9e216cd..40f9416 100644
--- a/dirmngr/dirmngr.h
+++ b/dirmngr/dirmngr.h
@@ -187,10 +187,6 @@ void dirmngr_sighup_action (void);
 const char* dirmngr_get_current_socket_name (void);
 
 
-/*-- Various housekeeping functions.  --*/
-void ks_hkp_housekeeping (time_t curtime);
-
-
 /*-- server.c --*/
 ldap_server_t get_ldapservers_from_ctrl (ctrl_t ctrl);
 ksba_cert_t get_cert_local (ctrl_t ctrl, const char *issuer);
diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c
index a9d566e..7a8d647 100644
--- a/dirmngr/ks-engine-hkp.c
+++ b/dirmngr/ks-engine-hkp.c
@@ -203,6 +203,25 @@ host_in_pool_p (int *pool, int tblidx)
 }
 
 
+static int
+host_is_alive (hostinfo_t hi, time_t curtime)
+{
+  if (!hi)
+    return 0;
+  if (!hi->dead)
+    return 1;
+  if (!hi->died_at)
+    return 0; /* manually marked dead */
+  if (hi->died_at + RESURRECT_INTERVAL <= curtime
+      || hi->died_at > curtime)
+    {
+      hi->dead = 0;
+      log_info ("resurrected host '%s'", hi->name);
+      return 1;
+    }
+  return 0;
+}
+
 /* Select a random host.  Consult TABLE which indices into the global
    hosttable.  Returns index into TABLE or -1 if no host could be
    selected.  */
@@ -212,11 +231,13 @@ select_random_host (int *table)
   int *tbl = NULL;
   size_t tblsize = 0;
   int pidx, idx;
+  time_t curtime;
 
+  curtime = gnupg_get_time ();
   /* We create a new table so that we randomly select only from
      currently alive hosts.  */
   for (idx=0; (pidx = table[idx]) != -1; idx++)
-    if (hosttable[pidx] && !hosttable[pidx]->dead)
+    if (hosttable[pidx] && host_is_alive (hosttable[pidx], curtime))
       {
         tblsize++;
         tbl = xtryrealloc(tbl, tblsize * sizeof *tbl);
@@ -392,6 +413,7 @@ map_host (ctrl_t ctrl, const char *name, int force_reselect,
   gpg_error_t err = 0;
   hostinfo_t hi;
   int idx;
+  time_t curtime;
 
   *r_host = NULL;
   if (r_httpflags)
@@ -540,6 +562,7 @@ map_host (ctrl_t ctrl, const char *name, int force_reselect,
         xfree (reftbl);
     }
 
+  curtime = gnupg_get_time ();
   hi = hosttable[idx];
   if (hi->pool)
     {
@@ -556,7 +579,7 @@ map_host (ctrl_t ctrl, const char *name, int force_reselect,
       if (force_reselect)
         hi->poolidx = -1;
       else if (hi->poolidx >= 0 && hi->poolidx < hosttable_size
-               && hosttable[hi->poolidx] && hosttable[hi->poolidx]->dead)
+               && hosttable[hi->poolidx] && !host_is_alive (hosttable[hi->poolidx], curtime))
         hi->poolidx = -1;
 
       /* Select a host if needed.  */
@@ -580,7 +603,7 @@ map_host (ctrl_t ctrl, const char *name, int force_reselect,
       assert (hi);
     }
 
-  if (hi->dead)
+  if (!host_is_alive (hi, curtime))
     {
       log_error ("host '%s' marked as dead\n", hi->name);
       if (r_poolname)
@@ -685,7 +708,8 @@ ks_hkp_mark_host (ctrl_t ctrl, const char *name, int alive)
 {
   gpg_error_t err = 0;
   hostinfo_t hi, hi2;
-  int idx, idx2, idx3, n;
+  int idx, idx2, idx3, n, is_alive;
+  time_t curtime;
 
   if (!name || !*name || !strcmp (name, "localhost"))
     return 0;
@@ -694,13 +718,15 @@ ks_hkp_mark_host (ctrl_t ctrl, const char *name, int alive)
   if (idx == -1)
     return gpg_error (GPG_ERR_NOT_FOUND);
 
+  curtime = gnupg_get_time ();
   hi = hosttable[idx];
-  if (alive && hi->dead)
+  is_alive = host_is_alive (hi, curtime);
+  if (alive && !is_alive)
     {
       hi->dead = 0;
       err = ks_printf_help (ctrl, "marking '%s' as alive", name);
     }
-  else if (!alive && !hi->dead)
+  else if (!alive && is_alive)
     {
       hi->dead = 1;
       hi->died_at = 0; /* Manually set dead.  */
@@ -732,14 +758,15 @@ ks_hkp_mark_host (ctrl_t ctrl, const char *name, int alive)
 
           hi2 = hosttable[n];
           if (!hi2)
-            ;
-          else if (alive && hi2->dead)
+            continue;
+          is_alive = host_is_alive (hi2, curtime);
+          if (alive && !is_alive)
             {
               hi2->dead = 0;
               err = ks_printf_help (ctrl, "marking '%s' as alive",
                                     hi2->name);
             }
-          else if (!alive && !hi2->dead)
+          else if (!alive && is_alive)
             {
               hi2->dead = 1;
               hi2->died_at = 0; /* Manually set dead. */
@@ -941,34 +968,6 @@ ks_hkp_resolve (ctrl_t ctrl, parsed_uri_t uri)
 }
 
 
-/* Housekeeping function called from the housekeeping thread.  It is
-   used to mark dead hosts alive so that they may be tried again after
-   some time.  */
-void
-ks_hkp_housekeeping (time_t curtime)
-{
-  int idx;
-  hostinfo_t hi;
-
-  for (idx=0; idx < hosttable_size; idx++)
-    {
-      hi = hosttable[idx];
-      if (!hi)
-        continue;
-      if (!hi->dead)
-        continue;
-      if (!hi->died_at)
-        continue; /* Do not resurrect manually shot hosts.  */
-      if (hi->died_at + RESURRECT_INTERVAL <= curtime
-          || hi->died_at > curtime)
-        {
-          hi->dead = 0;
-          log_info ("resurrected host '%s'", hi->name);
-        }
-    }
-}
-
-
 /* Send an HTTP request.  On success returns an estream object at
    R_FP.  HOSTPORTSTR is only used for diagnostics.  If HTTPHOST is
    not NULL it will be used as HTTP "Host" header.  If POST_CB is not
-- 
2.10.1



From dkg at fifthhorseman.net  Tue Nov  1 01:33:03 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 31 Oct 2016 20:33:03 -0400
Subject: [PATCH 2/5] dirmngr: hkp: avoid race condition when some hosts die
In-Reply-To: <20161101003306.12261-1-dkg@fifthhorseman.net>
References: <20161101003306.12261-1-dkg@fifthhorseman.net>
Message-ID: <20161101003306.12261-3-dkg@fifthhorseman.net>

* dirmngr/ks-engine-hkp.c (select_random_host): use atomic pass
  through the host table instead of risking out-of-bounds write

--

Multiple threads may write to hosttable[x]->dead while
select_random_host() is running.  For example, a housekeeping thread
might clear the ->dead bit on some entries, or another connection to
dirmngr might manually mark a host as alive.

If one or more hosts are resurrected between the two loops over a
given table in select_random_host(), then the allocation of tbl might
not be large enough, resulting in a write past the end of tbl on the
second loop.

This change collapses the two loops into a single loop to avoid this
discrepancy: each host's "dead" bit is now only checked once.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 dirmngr/ks-engine-hkp.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c
index bcc1750..a9d566e 100644
--- a/dirmngr/ks-engine-hkp.c
+++ b/dirmngr/ks-engine-hkp.c
@@ -209,25 +209,24 @@ host_in_pool_p (int *pool, int tblidx)
 static int
 select_random_host (int *table)
 {
-  int *tbl;
-  size_t tblsize;
+  int *tbl = NULL;
+  size_t tblsize = 0;
   int pidx, idx;
 
   /* We create a new table so that we randomly select only from
      currently alive hosts.  */
-  for (idx=0, tblsize=0; (pidx = table[idx]) != -1; idx++)
+  for (idx=0; (pidx = table[idx]) != -1; idx++)
     if (hosttable[pidx] && !hosttable[pidx]->dead)
-      tblsize++;
+      {
+        tblsize++;
+        tbl = xtryrealloc(tbl, tblsize * sizeof *tbl);
+        if (!tbl)
+          return -1; /* memory allocation failed! */
+        tbl[tblsize-1] = pidx;
+      }
   if (!tblsize)
     return -1; /* No hosts.  */
 
-  tbl = xtrymalloc (tblsize * sizeof *tbl);
-  if (!tbl)
-    return -1;
-  for (idx=0, tblsize=0; (pidx = table[idx]) != -1; idx++)
-    if (hosttable[pidx] && !hosttable[pidx]->dead)
-      tbl[tblsize++] = pidx;
-
   if (tblsize == 1)  /* Save a get_uint_nonce.  */
     pidx = tbl[0];
   else
-- 
2.10.1



From dkg at fifthhorseman.net  Tue Nov  1 01:33:02 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 31 Oct 2016 20:33:02 -0400
Subject: [PATCH 1/5] dirmngr: more win32 system daemon cleanup
In-Reply-To: <20161101003306.12261-1-dkg@fifthhorseman.net>
References: <20161101003306.12261-1-dkg@fifthhorseman.net>
Message-ID: <20161101003306.12261-2-dkg@fifthhorseman.net>

* dirmngr/dirmngr.c (handle_tick): remove win32 tests for
  shutdown_pending; no longer needed.

--

In d83ba4897bf217d1045c58d1b99e52bd31c58812, we removed the
Windows-specific system daemon features, where shutdown_pending was
set from w32_service_control().  shutdown_pending is now never
assigned outside of handle_signal() or within an inotify test, neither
of which are available on win32.

As a result, this stanza in handle_tick() should be dead code, and can
be removed to keep things simple.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 dirmngr/dirmngr.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c
index 07cbed9..776cf95 100644
--- a/dirmngr/dirmngr.c
+++ b/dirmngr/dirmngr.c
@@ -1811,20 +1811,6 @@ time_for_housekeeping_p (time_t curtime)
 static void
 handle_tick (void)
 {
-  /* Under Windows we don't use signals and need a way for the loop to
-     check for the shutdown flag.  */
-#ifdef HAVE_W32_SYSTEM
-  if (shutdown_pending)
-    log_info (_("SIGTERM received - shutting down ...\n"));
-  if (shutdown_pending > 2)
-    {
-      log_info (_("shutdown forced\n"));
-      log_info ("%s %s stopped\n", strusage(11), strusage(13) );
-      cleanup ();
-      dirmngr_exit (0);
-    }
-#endif /*HAVE_W32_SYSTEM*/
-
   if (time_for_housekeeping_p (gnupg_get_time ()))
     {
       npth_t thread;
-- 
2.10.1



From dkg at fifthhorseman.net  Tue Nov  1 01:33:05 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 31 Oct 2016 20:33:05 -0400
Subject: [PATCH 4/5] dirmngr: drop useless housekeeping
In-Reply-To: <20161101003306.12261-1-dkg@fifthhorseman.net>
References: <20161101003306.12261-1-dkg@fifthhorseman.net>
Message-ID: <20161101003306.12261-5-dkg@fifthhorseman.net>

* dirmngr/dirmngr.c (handle_tick, time_for_housekeeping_p,
  housekeeping_thread): remove, no longer needed;
  (handle_connections): drop any attempt at a timeout, since no
  housekeeping is necessary.

--

The housekeeping thread no longer does anything, and the main loop was
waking up every two seconds for no good reason.  The code is simpler
and the runtime is more efficient if we drop this.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 dirmngr/dirmngr.c | 120 +++---------------------------------------------------
 1 file changed, 5 insertions(+), 115 deletions(-)

diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c
index d7b43df..970fa4a 100644
--- a/dirmngr/dirmngr.c
+++ b/dirmngr/dirmngr.c
@@ -289,20 +289,6 @@ static int disable_check_own_socket;
 /* Counter for the active connections.  */
 static int active_connections;
 
-/* The timer tick used for housekeeping stuff.  For Windows we use a
-   longer period as the SetWaitableTimer seems to signal earlier than
-   the 2 seconds.  All values are in seconds. */
-#if defined(HAVE_W32CE_SYSTEM)
-# define TIMERTICK_INTERVAL         (60)
-#elif defined(HAVE_W32_SYSTEM)
-# define TIMERTICK_INTERVAL          (4)
-#else
-# define TIMERTICK_INTERVAL          (2)
-#endif
-
-#define HOUSEKEEPING_INTERVAL      (600)
-
-
 /* This union is used to avoid compiler warnings in case a pointer is
    64 bit and an int 32 bit.  We store an integer in a pointer and get
    it back later (npth_getspecific et al.).  */
@@ -1752,83 +1738,6 @@ handle_signal (int signo)
 #endif /*!HAVE_W32_SYSTEM*/
 
 
-/* Thread to do the housekeeping.  */
-static void *
-housekeeping_thread (void *arg)
-{
-  static int sentinel;
-
-  (void)arg;
-
-  if (sentinel)
-    {
-      log_info ("housekeeping is already going on\n");
-      return NULL;
-    }
-  sentinel++;
-  if (opt.verbose > 1)
-    log_info ("starting housekeeping\n");
-
-  if (opt.verbose > 1)
-    log_info ("ready with housekeeping\n");
-  sentinel--;
-  return NULL;
-
-}
-
-
-#if GPGRT_GCC_HAVE_PUSH_PRAGMA
-# pragma GCC push_options
-# pragma GCC optimize ("no-strict-overflow")
-#endif
-static int
-time_for_housekeeping_p (time_t curtime)
-{
-  static time_t last_housekeeping;
-
-  if (!last_housekeeping)
-    last_housekeeping = curtime;
-
-  if (last_housekeeping + HOUSEKEEPING_INTERVAL <= curtime
-      || last_housekeeping > curtime /*(be prepared for y2038)*/)
-    {
-      last_housekeeping = curtime;
-      return 1;
-    }
-  return 0;
-}
-#if GPGRT_GCC_HAVE_PUSH_PRAGMA
-# pragma GCC pop_options
-#endif
-
-
-/* This is the worker for the ticker.  It is called every few seconds
-   and may only do fast operations. */
-static void
-handle_tick (void)
-{
-  if (time_for_housekeeping_p (gnupg_get_time ()))
-    {
-      npth_t thread;
-      npth_attr_t tattr;
-      int err;
-
-      err = npth_attr_init (&tattr);
-      if (err)
-        log_error ("error preparing housekeeping thread: %s\n", strerror (err));
-      else
-        {
-          npth_attr_setdetachstate (&tattr, NPTH_CREATE_DETACHED);
-          err = npth_create (&thread, &tattr, housekeeping_thread, NULL);
-          if (err)
-            log_error ("error spawning housekeeping thread: %s\n",
-                       strerror (err));
-          npth_attr_destroy (&tattr);
-        }
-    }
-}
-
-
 /* Check the nonce on a new connection.  This is a NOP unless we are
    using our Unix domain socket emulation under Windows.  */
 static int
@@ -1928,9 +1837,6 @@ handle_connections (assuan_fd_t listen_fd)
   gnupg_fd_t fd;
   int nfd, ret;
   fd_set fdset, read_fdset;
-  struct timespec abstime;
-  struct timespec curtime;
-  struct timespec timeout;
   int saved_errno;
 #ifdef HAVE_INOTIFY_INIT
   int my_inotify_fd;
@@ -1972,9 +1878,7 @@ handle_connections (assuan_fd_t listen_fd)
 #endif /*HAVE_INOTIFY_INIT*/
 
 
-  /* Setup the fdset.  It has only one member.  This is because we use
-     pth_select instead of pth_accept to properly sync timeouts with
-     to full second.  */
+  /* Setup the fdset.  */
   FD_ZERO (&fdset);
   FD_SET (FD2INT (listen_fd), &fdset);
   nfd = FD2INT (listen_fd);
@@ -1987,9 +1891,6 @@ handle_connections (assuan_fd_t listen_fd)
     }
 #endif /*HAVE_INOTIFY_INIT*/
 
-  npth_clock_gettime (&abstime);
-  abstime.tv_sec += TIMERTICK_INTERVAL;
-
   /* Main loop.  */
   for (;;)
     {
@@ -2000,31 +1901,21 @@ handle_connections (assuan_fd_t listen_fd)
             break; /* ready */
 
           /* Do not accept new connections but keep on running the
-             loop to cope with the timer events.  */
+             select loop to wait for signals (e.g. SIGCHLD).  */
           FD_ZERO (&fdset);
 	}
 
       /* Take a copy of the fdset.  */
       read_fdset = fdset;
 
-      npth_clock_gettime (&curtime);
-      if (!(npth_timercmp (&curtime, &abstime, <)))
-	{
-	  /* Timeout.  */
-	  handle_tick ();
-	  npth_clock_gettime (&abstime);
-	  abstime.tv_sec += TIMERTICK_INTERVAL;
-	}
-      npth_timersub (&abstime, &curtime, &timeout);
-
 #ifndef HAVE_W32_SYSTEM
-      ret = npth_pselect (nfd+1, &read_fdset, NULL, NULL, &timeout, npth_sigev_sigmask());
+      ret = npth_pselect (nfd+1, &read_fdset, NULL, NULL, NULL, npth_sigev_sigmask());
       saved_errno = errno;
 
       while (npth_sigev_get_pending(&signo))
 	handle_signal (signo);
 #else
-      ret = npth_eselect (nfd+1, &read_fdset, NULL, NULL, &timeout, NULL, NULL);
+      ret = npth_eselect (nfd+1, &read_fdset, NULL, NULL, NULL, NULL, NULL);
       saved_errno = errno;
 #endif
 
@@ -2038,8 +1929,7 @@ handle_connections (assuan_fd_t listen_fd)
 
       if (ret <= 0)
         {
-          /* Interrupt or timeout.  Will be handled when calculating the
-             next timeout.  */
+          /* Interrupt.  Will be handled at the top of the next loop.  */
           continue;
         }
 
-- 
2.10.1



From dkg at fifthhorseman.net  Tue Nov  1 06:11:35 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue,  1 Nov 2016 01:11:35 -0400
Subject: [PATCH 3/4] agent: avoid tight timer tick when possible
In-Reply-To: <20161101051136.31766-1-dkg@fifthhorseman.net>
References: <20161101051136.31766-1-dkg@fifthhorseman.net>
Message-ID: <20161101051136.31766-4-dkg@fifthhorseman.net>

* agent/gpg-agent.c (need_tick): evaluate whether the short-phase
  handle_tick() is needed.  (handle_connections): on each cycle of the
  select loop, adjust whether we should call handle_tick() or not.
* agent/call-scd.c (start_scd): call interrupt_main_thread_loop() once
  the scdaemon thread context has started up.

--

With this change, an idle gpg-agent that has no scdaemon running only
wakes up once a minute (to check_own_socket).

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 agent/call-scd.c  |  4 +++-
 agent/gpg-agent.c | 25 ++++++++++++++++++++++++-
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/agent/call-scd.c b/agent/call-scd.c
index 0f7d570..9ddb978 100644
--- a/agent/call-scd.c
+++ b/agent/call-scd.c
@@ -407,7 +407,9 @@ start_scd (ctrl_t ctrl)
 
   primary_scd_ctx = ctx;
   primary_scd_ctx_reusable = 0;
-
+  /* notify the main loop that something has changed */
+  interrupt_main_thread_loop ();
+  
  leave:
   xfree (abs_homedir);
   if (err)
diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c
index c588e80..827735c 100644
--- a/agent/gpg-agent.c
+++ b/agent/gpg-agent.c
@@ -2241,6 +2241,26 @@ create_directories (void)
 }
 
 
+static int
+need_tick (void)
+{
+#ifdef HAVE_W32_SYSTEM
+  /* We do not know how to interrupt the select loop on Windows, so we
+     always need a short tick there. */
+  return 1;
+#else
+  /* if we were invoked like "gpg-agent cmd arg1 arg2" then we need to
+     watch our parent. */
+  if (parent_pid != (pid_t)(-1))
+    return 1;
+  /* if scdaemon is running, we need to check that it's alive */
+  if (agent_scd_check_running ())
+    return 1;
+  /* otherwise, nothing fine-grained to do. */
+  return 0;
+#endif /*HAVE_W32_SYSTEM*/
+}
+
 
 /* This is the worker for the ticker.  It is called every few seconds
    and may only do fast operations. */
@@ -2299,7 +2319,7 @@ agent_sigusr2_action (void)
 
 #ifndef HAVE_W32_SYSTEM
 /* The signal handler for this program.  It is expected to be run in
-   its own trhead and not in the context of a signal handler.  */
+   its own thread and not in the context of a signal handler.  */
 static void
 handle_signal (int signo)
 {
@@ -2835,6 +2855,9 @@ handle_connections (gnupg_fd_t listen_fd,
          thus a simple assignment is fine to copy the entire set.  */
       read_fdset = fdset;
 
+      /* avoid a fine-grained timer if we don't need one: */
+      timertbl[0].interval.tv_sec = need_tick () ? TIMERTICK_INTERVAL : 0;
+
       /* loop through all timers, fire any registered functions, and
          plan next timer to trigger */
       npth_clock_gettime (&curtime);
-- 
2.10.1



From dkg at fifthhorseman.net  Tue Nov  1 06:11:34 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue,  1 Nov 2016 01:11:34 -0400
Subject: [PATCH 2/4] agent: allow threads to interrupt main select loop with
 SIGCONT
In-Reply-To: <20161101051136.31766-1-dkg@fifthhorseman.net>
References: <20161101051136.31766-1-dkg@fifthhorseman.net>
Message-ID: <20161101051136.31766-3-dkg@fifthhorseman.net>

* agent/gpg-agent.c (interrupt_main_thread_loop): new function on
  non-windows platforms, allows other threads to interrupt the main
  loop if there's something that the main loop might be interested in.

--

For example, the main loop might be interested in changes in program
state that affect the timers it expects to see.

I don't know how to do this on Windows platforms, but i welcome any
proposed improvements.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 agent/agent.h     |  1 +
 agent/gpg-agent.c | 19 ++++++++++++++++++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/agent/agent.h b/agent/agent.h
index a3ec457..7bc061c 100644
--- a/agent/agent.h
+++ b/agent/agent.h
@@ -347,6 +347,7 @@ void *get_agent_scd_notify_event (void);
 #endif
 void agent_sighup_action (void);
 int map_pk_openpgp_to_gcry (int openpgp_algo);
+void interrupt_main_thread_loop (void);
 
 /*-- command.c --*/
 gpg_error_t agent_inq_pinentry_launched (ctrl_t ctrl, unsigned long pid);
diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c
index f122e5b..c588e80 100644
--- a/agent/gpg-agent.c
+++ b/agent/gpg-agent.c
@@ -380,6 +380,9 @@ static char *current_logfile;
    watched. */
 static pid_t parent_pid = (pid_t)(-1);
 
+/* Record the pid of the main thread, for easier signalling */
+static pid_t main_thread_pid = (pid_t)(-1);
+
 /* Number of active connections.  */
 static int active_connections;
 
@@ -1994,7 +1997,7 @@ get_agent_scd_notify_event (void)
                                  GetCurrentProcess(), &h2,
                                  EVENT_MODIFY_STATE|SYNCHRONIZE, TRUE, 0))
         {
-          log_error ("setting syncronize for scd notify event failed: %s\n",
+          log_error ("setting synchronize for scd notify event failed: %s\n",
                      w32_strerror (-1) );
           CloseHandle (h);
         }
@@ -2320,6 +2323,10 @@ handle_signal (int signo)
       agent_sigusr2_action ();
       break;
 
+      /* nothing to do here, just take an extra cycle on the select loop */
+    case SIGCONT:
+      break;
+
     case SIGTERM:
       if (!shutdown_pending)
         log_info ("SIGTERM received - shutting down ...\n");
@@ -2658,6 +2665,13 @@ start_connection_thread_ssh (void *arg)
 }
 
 
+void interrupt_main_thread_loop (void)
+{
+#ifndef HAVE_W32_SYSTEM
+  kill (main_thread_pid, SIGCONT);
+#endif
+}
+
 /* helper function for readability: test whether a given struct
    timespec is set to all-zeros */
 static inline int
@@ -2726,8 +2740,10 @@ handle_connections (gnupg_fd_t listen_fd,
   npth_sigev_add (SIGUSR1);
   npth_sigev_add (SIGUSR2);
   npth_sigev_add (SIGINT);
+  npth_sigev_add (SIGCONT);
   npth_sigev_add (SIGTERM);
   npth_sigev_fini ();
+  main_thread_pid = getpid ();
 #else
 # ifdef HAVE_W32CE_SYSTEM
   /* Use a dummy event. */
@@ -2739,6 +2755,7 @@ handle_connections (gnupg_fd_t listen_fd,
 # endif
 #endif
 
+
   if (disable_check_own_socket)
     my_inotify_fd = -1;
   else if ((err = gnupg_inotify_watch_socket (&my_inotify_fd, socket_name)))
-- 
2.10.1



From dkg at fifthhorseman.net  Tue Nov  1 06:11:32 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue,  1 Nov 2016 01:11:32 -0400
Subject: help gpg-agent be more idle
Message-ID: <20161101051136.31766-1-dkg@fifthhorseman.net>

A patch series follows that aims to help gpg-agent tread more lightly
on the system it uses, at least on non-Windows systems.  In
particular, on my GNU/Linux system, a default gpg-agent process wakes
up every two seconds and then immediately goes back to sleep.

This represents a potential problem for power management, and suggests
that there is room for improvement at least in the default case where
gpg-agent is mostly idle.  This is similar to the recent patch series
i submitted about helping dirmngr be more idle, but focused on
gpg-agent instead.

With these patches applied, an idle gpg-agent on non-Windows platforms
is actually idle for up to 60 seconds at a time -- waiting in the
kernel's select() for activity to wake it up, or checking on its own
sockets every minute.

Even better, on platforms which support inotify both at compile-time
and at run-time, gpg-agent is completely idle, since inotify removes
the need for scheduled checks of control of the socket.  The process
is no less responsive to the user, and it doesn't burn CPU it doesn't
need.

However, if gpg-agent launches scdaemon, then these optimizations go
away, and gpg-agent falls back to its usual every-two-seconds wakeups
to verify the status of the scdaemon.  scdaemon itself wakes up every
0.5 seconds, so handling the idle case with scdaemon running will take
more work.  However, the following patch series is still a win for
every user who doesn't run scdaemon, so i hope it will be considered.

Comments welcome!

Regards,

        --dkg


From dkg at fifthhorseman.net  Tue Nov  1 06:11:36 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue,  1 Nov 2016 01:11:36 -0400
Subject: [PATCH 4/4] agent: avoid scheduled checks on socket when inotify is
 working
In-Reply-To: <20161101051136.31766-1-dkg@fifthhorseman.net>
References: <20161101051136.31766-1-dkg@fifthhorseman.net>
Message-ID: <20161101051136.31766-5-dkg@fifthhorseman.net>

* agent/gpg-agent.c (handle_connections): when inotify is working, we
  do not need to schedule a timer to evaluate whether we control our
  own socket or not.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 agent/gpg-agent.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c
index 827735c..98fae4f 100644
--- a/agent/gpg-agent.c
+++ b/agent/gpg-agent.c
@@ -2857,6 +2857,8 @@ handle_connections (gnupg_fd_t listen_fd,
 
       /* avoid a fine-grained timer if we don't need one: */
       timertbl[0].interval.tv_sec = need_tick () ? TIMERTICK_INTERVAL : 0;
+      /* avoid waking up to check sockets if we can count on inotify */
+      timertbl[1].interval.tv_sec = (my_inotify_fd == -1) ? CHECK_OWN_SOCKET_INTERVAL : 0;
 
       /* loop through all timers, fire any registered functions, and
          plan next timer to trigger */
-- 
2.10.1



From dkg at fifthhorseman.net  Tue Nov  1 06:11:33 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue,  1 Nov 2016 01:11:33 -0400
Subject: [PATCH 1/4] agent: create framework of scheduled timers
In-Reply-To: <20161101051136.31766-1-dkg@fifthhorseman.net>
References: <20161101051136.31766-1-dkg@fifthhorseman.net>
Message-ID: <20161101051136.31766-2-dkg@fifthhorseman.net>

agent/gpg-agent.c (handle_tick): remove intermittent call to
check_own_socket; (tv_set): add inline helper function for
readability; (handle_connections) create general table of pending
scheduled timeouts.

--

handle_tick() does fine-grained, rapid activity.  check_own_socket()
is supposed to happen at a different interval.

Mixing the two of them makes it a requirement that one interval be a
multiple of the other, which isn't ideal if there are different delay
strategies that we might want in the future.

Creating an extensible regular timer framework in handle_connections
should make it possible to have any number of cadenced timers fire
regularly, without requiring that they happen in cadences related to
each other.

It should also make it possible to dynamically change the cadence of
any regularly-scheduled timeout.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 agent/gpg-agent.c | 87 ++++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 58 insertions(+), 29 deletions(-)

diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c
index 7294c69..f122e5b 100644
--- a/agent/gpg-agent.c
+++ b/agent/gpg-agent.c
@@ -2244,11 +2244,6 @@ create_directories (void)
 static void
 handle_tick (void)
 {
-  static time_t last_minute;
-
-  if (!last_minute)
-    last_minute = time (NULL);
-
   /* Check whether the scdaemon has died and cleanup in this case. */
   agent_scd_check_aliveness ();
 
@@ -2267,16 +2262,6 @@ handle_tick (void)
         }
     }
 #endif /*HAVE_W32_SYSTEM*/
-
-  /* Code to be run from time to time.  */
-#if CHECK_OWN_SOCKET_INTERVAL > 0
-  if (last_minute + CHECK_OWN_SOCKET_INTERVAL <= time (NULL))
-    {
-      check_own_socket ();
-      last_minute = time (NULL);
-    }
-#endif
-
 }
 
 
@@ -2673,6 +2658,15 @@ start_connection_thread_ssh (void *arg)
 }
 
 
+/* helper function for readability: test whether a given struct
+   timespec is set to all-zeros */
+static inline int
+tv_set (struct timespec tv)
+{
+  return tv.tv_sec || tv.tv_nsec;
+}
+
+
 /* Connection handler loop.  Wait for connection requests and spawn a
    thread after accepting a connection.  */
 static void
@@ -2690,9 +2684,11 @@ handle_connections (gnupg_fd_t listen_fd,
   gnupg_fd_t fd;
   int nfd;
   int saved_errno;
+  int idx;
   struct timespec abstime;
   struct timespec curtime;
   struct timespec timeout;
+  struct timespec *select_timeout;
 #ifdef HAVE_W32_SYSTEM
   HANDLE events[2];
   unsigned int events_set;
@@ -2708,6 +2704,14 @@ handle_connections (gnupg_fd_t listen_fd,
     { "browser", start_connection_thread_browser },
     { "ssh",    start_connection_thread_ssh   }
   };
+  struct {
+    struct timespec interval;
+    void (*func) (void);
+    struct timespec next;
+  } timertbl[] = {
+    { { TIMERTICK_INTERVAL, 0 }, handle_tick },
+    { { CHECK_OWN_SOCKET_INTERVAL, 0 }, check_own_socket }
+  };
 
 
   ret = npth_attr_init(&tattr);
@@ -2797,9 +2801,6 @@ handle_connections (gnupg_fd_t listen_fd,
   listentbl[2].l_fd = listen_fd_browser;
   listentbl[3].l_fd = listen_fd_ssh;
 
-  npth_clock_gettime (&abstime);
-  abstime.tv_sec += TIMERTICK_INTERVAL;
-
   for (;;)
     {
       /* Shutdown test.  */
@@ -2817,18 +2818,47 @@ handle_connections (gnupg_fd_t listen_fd,
          thus a simple assignment is fine to copy the entire set.  */
       read_fdset = fdset;
 
+      /* loop through all timers, fire any registered functions, and
+         plan next timer to trigger */
       npth_clock_gettime (&curtime);
-      if (!(npth_timercmp (&curtime, &abstime, <)))
-	{
-	  /* Timeout.  */
-	  handle_tick ();
-	  npth_clock_gettime (&abstime);
-	  abstime.tv_sec += TIMERTICK_INTERVAL;
-	}
-      npth_timersub (&abstime, &curtime, &timeout);
+      abstime.tv_sec = abstime.tv_nsec = 0;
+      for (idx=0; idx < DIM(timertbl); idx++)
+        {
+          /* schedule any unscheduled timers */
+          if ((!tv_set (timertbl[idx].next)) && tv_set (timertbl[idx].interval))
+            npth_timeradd (&timertbl[idx].interval, &curtime, &timertbl[idx].next);
+          /* if a timer is due, fire it ... */
+          if (tv_set (timertbl[idx].next))
+            {
+              if (!(npth_timercmp (&curtime, &timertbl[idx].next, <)))
+                {
+                  timertbl[idx].func ();
+                  npth_clock_gettime (&curtime);
+                  /* ...and reschedule it, if desired: */
+                  if (tv_set (timertbl[idx].interval))
+                    npth_timeradd (&timertbl[idx].interval, &curtime, &timertbl[idx].next);
+                  else
+                    timertbl[idx].next.tv_sec = timertbl[idx].next.tv_nsec = 0;
+                }
+            }
+          /* accumulate next timer to come due in abstime: */
+          if (tv_set (timertbl[idx].next) &&
+              ((!tv_set (abstime)) ||
+               (npth_timercmp (&abstime, &timertbl[idx].next, >))))
+            abstime = timertbl[idx].next;
+        }
+      /* choose a timeout for the select loop: */
+      if (tv_set (abstime))
+        {
+          npth_timersub (&abstime, &curtime, &timeout);
+          select_timeout = &timeout;
+        }
+      else
+          select_timeout = NULL;
+      
 
 #ifndef HAVE_W32_SYSTEM
-      ret = npth_pselect (nfd+1, &read_fdset, NULL, NULL, &timeout,
+      ret = npth_pselect (nfd+1, &read_fdset, NULL, NULL, select_timeout,
                           npth_sigev_sigmask ());
       saved_errno = errno;
 
@@ -2838,7 +2868,7 @@ handle_connections (gnupg_fd_t listen_fd,
           handle_signal (signo);
       }
 #else
-      ret = npth_eselect (nfd+1, &read_fdset, NULL, NULL, &timeout,
+      ret = npth_eselect (nfd+1, &read_fdset, NULL, NULL, select_timeout,
                           events, &events_set);
       saved_errno = errno;
 
@@ -2861,7 +2891,6 @@ handle_connections (gnupg_fd_t listen_fd,
 
       if (!shutdown_pending)
         {
-          int idx;
           ctrl_t ctrl;
           npth_t thread;
 
-- 
2.10.1



From bernhard at intevation.de  Tue Nov  1 08:48:24 2016
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 1 Nov 2016 08:48:24 +0100
Subject: begging for pyme name change
In-Reply-To: <877f8r3zuj.fsf@wheatstone.g10code.de>
References: <87insx8404.fsf@servo.finestructure.net>
 <87twbw9o7c.fsf@alice.fifthhorseman.net>
 <877f8r3zuj.fsf@wheatstone.g10code.de>
Message-ID: <201611010848.25027.bernhard@intevation.de>

Am Samstag 29 Oktober 2016 18:05:24 schrieb Werner Koch:
> On Fri, 28 Oct 2016 23:08, dkg at fifthhorseman.net said:
> > If any gpgme developers think this is worth doing, please go ahead and
> > claim the "gpg" name on pypi, and you're welcome to merge my patch.
>
> I think this is a good idea. ?Justus, what do you think?

Again I think that "gnupg" is better,
with "gpgme" as the second best alternative.
(See my post from the 19th about the "brand".)


-- 
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/20161101/9850db65/attachment.sig>

From bernhard at intevation.de  Tue Nov  1 09:01:55 2016
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 1 Nov 2016 09:01:55 +0100
Subject: Web Key Service server lookup
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
Message-ID: <201611010902.03549.bernhard@intevation.de>

Moin J?rgen,

Am Freitag 28 Oktober 2016 10:58:59 schrieb J?rgen Sch?pker:
> thanks for the answer, Werner. I?m still not sure what the functional
> advantage is for using binary instead of armored, though.

the question is: What is the drawback of using binary?
Peter Fischer <p.fischer at heinlein-support.de> suggested to allow
armoured as well, so they could just take the input data without checking.

> An idea on setup 
> simplicity: currently the request URL is composed as
> https://example.org/.well-known/openpgpkey/hu/XXXX
> This usually requires some form of redirection to the actual WKD server
> (when it?s not the same as the one running at example.org). 

Yes, we must attach this to the domain part of the intended recipient's email 
address, because this is all we have to verify.

> To make life easier for admins (specifically in small business scenarios) 
> I would like to suggest that if
> https://example.org/.well-known/openpgpkey/hu/XXXX 
> returns a 404 or timeout error, another attempt should be made at a
> subdomain like https://keys.example.org/.well-known/openpgpkey/hu/XXXX (or
> https://wkd.example.org/.well-known/openpgpkey/hu/XXXX). I imagine this
> could ease setting up a WKD server significantly (e.g. when modifications
> to a main server are difficult because of bureaucracy etc).

We are also thinking about potential solutions to this problem.
However the problem is that we'd need a TLS certificate for the subdomain.
That is even harder than getting a TLS cert for the example.org domain,
so it does not seem to be a good solution.

And if we are not requiring a domain check via TLS, then we could use any 
domain name that has been placed in DNS.

> https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept suggests a
> priority list for looking up keys ? are those lookup-attempts meant to work
> only in sequence or in parallel and what timeouts should be used?

Are you refering to the five points under "Proposed solution"?
This has not yet been fully worked out. My personal idea is that it is to be 
taken in order. Of course 2. may be tried more often even when 1. has a hit
to check for updates. 4. and 5. may be mixed, so that 4. is never applied 
alone.

Thanks for reading and commenting on our proposal! 

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/20161101/34dff949/attachment.sig>

From aheinecke at intevation.de  Tue Nov  1 10:06:38 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Tue, 01 Nov 2016 10:06:38 +0100
Subject: GPGME question: who uses /usr/include/{gpgmepp,
 qgpgme}_version.h  ?
In-Reply-To: <87ins88hry.fsf@alice.fifthhorseman.net>
References: <87ins88hry.fsf@alice.fifthhorseman.net>
Message-ID: <8646423.G9ysC7oTy0@esus>

Hi,

On Monday 31 October 2016 15:01:21 Daniel Kahn Gillmor wrote:
> i just realized that in addition to /usr/include/qgpgme/ and
> /usr/include/gpgme++/, GPGME's development headers want to ship
> /usr/include/qgpgme_version.h and /usr/include/libgpgmepp_version.h.
> 
> These files contain #define macros for the version information of the
> library that's being built against.
> 
> What's the reason for having these two files at the same level
> (/usr/include/) instead of shipping them inside the shipped directories?
> For example, why not ship /usr/include/qgpgme/version.h instead?

This was because it was done this way in the KDE Frameworks variants. In KDE 
Frameworks the version headers are installed under the KF5 prefix and the 
actual headers are installed in subdirectories.

So you have:
<prefix>/include/KF5/gpgme++
and:
<prefix>/include/KF5/gpgmepp_version.h

ls <prefix>include/KF5/*version.h | wc -l
113

I just kept it this way when dropping the KF5 prefix.

> On my own dev workstation, i see many more packages following the
> foo/version.h approach:
> 
>     0 dkg at alice:~$ ls /usr/include/*/*version.h | wc -l
>     29
>     0 dkg at alice:~$ ls /usr/include/*version.h | wc -l
>     4
>     0 dkg at alice:~$
> 
> Is there a reason to use ${library}_version.h instead of putting the
> file inside the shipped directory?  fwiw, if there's a concern about
> backward compatibility, I've looked on https://codesearch.debian.net and
> i don't see anyone using these version.h files directly in debian at all
> at the moment.

I don't see a reason for why they are outside the directory. I take it your 
recommendation is to move them inside, so I'll follow your recommendation.

But, I'll keep the name to be qgpgme_version.h and gpgmepp_version.h to avoid 
ambiguities if someone directly includes /usr/include/qgpgme and 
/usr/include/gpgmepp.

I am also unaware of any user of these headers but I think they can be useful 
in software using it to require a lower minimum version and ifdef out features 
that would require a newer version without having to write fine grained feature 
checks.

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: 659 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161101/9501d8f7/attachment.sig>

From wk at gnupg.org  Tue Nov  1 12:06:06 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 01 Nov 2016 12:06:06 +0100
Subject: [PATCH 2/5] dirmngr: hkp: avoid race condition when some hosts die
In-Reply-To: <20161101003306.12261-3-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Mon, 31 Oct 2016 20:33:03 -0400")
References: <20161101003306.12261-1-dkg@fifthhorseman.net>
 <20161101003306.12261-3-dkg@fifthhorseman.net>
Message-ID: <87bmxza28x.fsf@wheatstone.g10code.de>

On Tue,  1 Nov 2016 01:33, dkg at fifthhorseman.net said:

> Multiple threads may write to hosttable[x]->dead while
> select_random_host() is running.  For example, a housekeeping thread

Nope.  Please look at the code:

  for (idx=0, tblsize=0; (pidx = table[idx]) != -1; idx++)
    if (hosttable[pidx] && !hosttable[pidx]->dead)
      tblsize++;
  if (!tblsize)
    return -1; /* No hosts.  */

  tbl = xtrymalloc (tblsize * sizeof *tbl);
  if (!tbl)
    return -1;
  for (idx=0, tblsize=0; (pidx = table[idx]) != -1; idx++)
    if (hosttable[pidx] && !hosttable[pidx]->dead)
      tbl[tblsize++] = pidx;

  if (tblsize == 1)  /* Save a get_uint_nonce.  */
    pidx = tbl[0];
  else
    pidx = tbl[get_uint_nonce () % tblsize];

and explain where you see a syscall which may switch to another thread.
Neither xtrymalloc nor get_unit_nonce are such syscalls or supposed to
use nPth wrapper syscalls.

I agree that the use of get_unit_nonce is a bit fragile because we can't
immediatly see how it is implemented and thus would be better to get its
value at the start of the function.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161101/472d93c2/attachment-0001.sig>

From wk at gnupg.org  Tue Nov  1 12:12:27 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 01 Nov 2016 12:12:27 +0100
Subject: can we drop -lassuan and -lgpg-error from the output of
 "gpgme-config --libs" ?
In-Reply-To: <87func8h05.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Mon, 31 Oct 2016 15:18:02 -0400")
References: <87func8h05.fsf@alice.fifthhorseman.net>
Message-ID: <874m3ra1yc.fsf@wheatstone.g10code.de>

On Mon, 31 Oct 2016 20:18, dkg at fifthhorseman.net said:

> symbols from those libraries themselves.  The dynamic linker should
> handle any necessary recursive loads.

That is a glibc feature but fails on many other platforms.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161101/bb396e6c/attachment.sig>

From Juergen.Schaepker at giepa.de  Tue Nov  1 12:49:59 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Tue, 1 Nov 2016 12:49:59 +0100
Subject: AW: Web Key Service server lookup
In-Reply-To: <201611010902.03549.bernhard@intevation.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>

Hi Bernhard,

>However the problem is that we'd need a TLS certificate for the subdomain.
>That is even harder than getting a TLS cert for the example.org domain,
>so it does not seem to be a good solution.

I would think this is usually solved by wildcard certificates.

Regarding the lookup proposed solution:
One idea would be to allow parallel lookups and using the results retrieved by priority when the timeout expired and the highest priority (WKD) did not deliver anything before timeout. I'd think timeout could be limited to a (user-customizable) low value like e.g. 20 seconds, maybe more for mobile.

Another potential issue in the draft: the domain-part seems to be taken from the request URL. In a number of hosting configurations, e.g. via reverse proxy, the request URL might by default be rewritten (though in some configurations it might be recoverable from X-Forwarded-Host header). In case the original requester host cannot be determined, this would create potential collisions on WKDs answering for multiple domains, e.g. it couldn't discern the hashes for joe at for.com and joe at bar.com.

Wouldn't it be better if the hash was calculated for the full email address?

Best regards,
JS

-----Urspr?ngliche Nachricht-----
Von: Bernhard Reiter [mailto:bernhard at intevation.de] 
Gesendet: Dienstag, 1. November 2016 09:02
An: gnupg-devel at gnupg.org
Betreff: Re: Web Key Service server lookup

Moin J?rgen,

Am Freitag 28 Oktober 2016 10:58:59 schrieb J?rgen Sch?pker:
> thanks for the answer, Werner. I?m still not sure what the functional
> advantage is for using binary instead of armored, though.

the question is: What is the drawback of using binary?
Peter Fischer <p.fischer at heinlein-support.de> suggested to allow
armoured as well, so they could just take the input data without checking.

> An idea on setup 
> simplicity: currently the request URL is composed as
> https://example.org/.well-known/openpgpkey/hu/XXXX
> This usually requires some form of redirection to the actual WKD server
> (when it?s not the same as the one running at example.org). 

Yes, we must attach this to the domain part of the intended recipient's email 
address, because this is all we have to verify.

> To make life easier for admins (specifically in small business scenarios) 
> I would like to suggest that if
> https://example.org/.well-known/openpgpkey/hu/XXXX 
> returns a 404 or timeout error, another attempt should be made at a
> subdomain like https://keys.example.org/.well-known/openpgpkey/hu/XXXX (or
> https://wkd.example.org/.well-known/openpgpkey/hu/XXXX). I imagine this
> could ease setting up a WKD server significantly (e.g. when modifications
> to a main server are difficult because of bureaucracy etc).

We are also thinking about potential solutions to this problem.
However the problem is that we'd need a TLS certificate for the subdomain.
That is even harder than getting a TLS cert for the example.org domain,
so it does not seem to be a good solution.

And if we are not requiring a domain check via TLS, then we could use any 
domain name that has been placed in DNS.

> https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept suggests a
> priority list for looking up keys ? are those lookup-attempts meant to work
> only in sequence or in parallel and what timeouts should be used?

Are you refering to the five points under "Proposed solution"?
This has not yet been fully worked out. My personal idea is that it is to be 
taken in order. Of course 2. may be tried more often even when 1. has a hit
to check for updates. 4. and 5. may be mixed, so that 4. is never applied 
alone.

Thanks for reading and commenting on our proposal! 

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

From dgouttegattat at incenp.org  Tue Nov  1 15:53:59 2016
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 1 Nov 2016 15:53:59 +0100
Subject: New Scute release?
Message-ID: <7a8d081b-f717-9e0a-660c-e4d814e3d816@incenp.org>

Hi,

A few weeks ago we discussed about making a new release for Scute [1]. I 
sent a last patch to update the NEWS file prior to the release [2].

Where do we stand about that release? Is there anything I can do to help 
going further?

Cheers,

Damien


[1] https://lists.gnupg.org/pipermail/gnupg-devel/2016-September/031695.html
[2] https://lists.gnupg.org/pipermail/gnupg-devel/2016-September/031700.html

-------------- 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/20161101/066bb57e/attachment.sig>

From dkg at fifthhorseman.net  Tue Nov  1 16:25:26 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 01 Nov 2016 11:25:26 -0400
Subject: begging for pyme name change
In-Reply-To: <201611010848.25027.bernhard@intevation.de>
References: <87insx8404.fsf@servo.finestructure.net>
 <87twbw9o7c.fsf@alice.fifthhorseman.net>
 <877f8r3zuj.fsf@wheatstone.g10code.de>
 <201611010848.25027.bernhard@intevation.de>
Message-ID: <87lgx35ijd.fsf@alice.fifthhorseman.net>

On Tue 2016-11-01 03:48:24 -0400, Bernhard Reiter wrote:
> Am Samstag 29 Oktober 2016 18:05:24 schrieb Werner Koch:
>> On Fri, 28 Oct 2016 23:08, dkg at fifthhorseman.net said:
>> > If any gpgme developers think this is worth doing, please go ahead and
>> > claim the "gpg" name on pypi, and you're welcome to merge my patch.
>>
>> I think this is a good idea. ?Justus, what do you think?
>
> Again I think that "gnupg" is better,
> with "gpgme" as the second best alternative.
> (See my post from the 19th about the "brand".)

Yes, you mentioned this, but i didn't see any proposal to deal with the
fact that name "gnupg" is currently already taken, both as a pypi
package ("source package name") and as a python module name ("import
gnupg"), with the same fairly sophisticated package:

   https://pypi.python.org/pypi/gnupg

While we might be able to convince the author of that package to
deprecate it and transfer the name to the GnuPG upstream team, it's not
clear how we would help any existing users/dependencies of the module to
transition if we just squat the namespace and break the API.

Hence, the choice of "gpg", which doesn't have a problem with the pypi
package name, and has only a very limited and unsophisticated (and
already dangerously broken) API.

I understand why you think this is "second best", and i think in a world
without technical debt or any pre-existing deployed software, i'd agree
with you.  As it stands, i want to move forward with something with a
sensible name that only requires a hill of work, and not a mountain ;) I
hope you'll agree that this is an acceptable tradeoff, and still an
improvement over "pyme3/pyme" in terms of name recognition and
usability.

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/20161101/c4b5976f/attachment.sig>

From dkg at fifthhorseman.net  Tue Nov  1 15:59:24 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 01 Nov 2016 10:59:24 -0400
Subject: can we drop -lassuan and -lgpg-error from the output of
 "gpgme-config --libs" ?
In-Reply-To: <874m3ra1yc.fsf@wheatstone.g10code.de>
References: <87func8h05.fsf@alice.fifthhorseman.net>
 <874m3ra1yc.fsf@wheatstone.g10code.de>
Message-ID: <87r36v5jqr.fsf@alice.fifthhorseman.net>

On Tue 2016-11-01 07:12:27 -0400, Werner Koch wrote:
> On Mon, 31 Oct 2016 20:18, dkg at fifthhorseman.net said:
>
>> symbols from those libraries themselves.  The dynamic linker should
>> handle any necessary recursive loads.
>
> That is a glibc feature but fails on many other platforms.

This is why we have a -config script, right?  Shouldn't it produce the
minimal set on platforms that use glibc, and the extended set when built
against other platforms?

      --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/20161101/681af6a5/attachment.sig>

From dkg at fifthhorseman.net  Tue Nov  1 16:13:23 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 01 Nov 2016 11:13:23 -0400
Subject: [PATCH 2/5] dirmngr: hkp: avoid race condition when some hosts die
In-Reply-To: <87bmxza28x.fsf@wheatstone.g10code.de>
References: <20161101003306.12261-1-dkg@fifthhorseman.net>
 <20161101003306.12261-3-dkg@fifthhorseman.net>
 <87bmxza28x.fsf@wheatstone.g10code.de>
Message-ID: <87oa1z5j3g.fsf@alice.fifthhorseman.net>

On Tue 2016-11-01 07:06:06 -0400, Werner Koch wrote:
> On Tue,  1 Nov 2016 01:33, dkg at fifthhorseman.net said:
>
>> Multiple threads may write to hosttable[x]->dead while
>> select_random_host() is running.  For example, a housekeeping thread
>
> Nope.  Please look at the code:
>
>   for (idx=0, tblsize=0; (pidx = table[idx]) != -1; idx++)
>     if (hosttable[pidx] && !hosttable[pidx]->dead)
>       tblsize++;
>   if (!tblsize)
>     return -1; /* No hosts.  */
>
>   tbl = xtrymalloc (tblsize * sizeof *tbl);
>   if (!tbl)
>     return -1;
>   for (idx=0, tblsize=0; (pidx = table[idx]) != -1; idx++)
>     if (hosttable[pidx] && !hosttable[pidx]->dead)
>       tbl[tblsize++] = pidx;
>
>   if (tblsize == 1)  /* Save a get_uint_nonce.  */
>     pidx = tbl[0];
>   else
>     pidx = tbl[get_uint_nonce () % tblsize];
>
> and explain where you see a syscall which may switch to another thread.
> Neither xtrymalloc nor get_unit_nonce are such syscalls or supposed to
> use nPth wrapper syscalls.

Sorry, i wasn't aware that the only place where a thread could execute
concurrently was in a call into the kernel.  Will npth never provide
concurrent execution on any multiprocessor architecture?

I also wasn't aware that xtrymalloc() was guaranteed to never call
brk().

At any rate, while i think this particular patch improves readability
and maintainability of the code, i'm happy to rebase this series without
it -- the only difference, i suppose, is that i'll have to remove the
log_info() in host_is_alive() so that we don't accidentally create a
syscall while testing (i'll also add a comment warning that this
function must never be modified to make syscalls so that future editors
don't get tripped up).

Would you like me to send such a rebased patch queue?

        --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/20161101/3fdfac37/attachment.sig>

From Juergen.Schaepker at giepa.de  Tue Nov  1 16:47:57 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Tue, 1 Nov 2016 16:47:57 +0100
Subject: AW: AW: Web Key Service server lookup
In-Reply-To: <c89d9f9c-04b8-11b2-30a5-d5e251122096@digitalbrains.com>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
 <c89d9f9c-04b8-11b2-30a5-d5e251122096@digitalbrains.com>
Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B92@S2008SBS.intern.giepa.de>

Hi,

> So this is a webserver that serves the exact same for any request for the site
>at http://for.com/ and the site at http://bar.com/ and this is not an explicit
>decision by the admin but a consequence of limitations of the setup? Sounds
>esoteric enough to ignore to me.

In my experience this is not uncommon. It could be as trivial as a company using domains company.com, company.ca and company.de where email addresses might or might not be aliases between .com, .ca and .de.  robert.smith at company.com might or might not be the same person as robert.smith at company.ca.


Best regards,
JS

-----Urspr?ngliche Nachricht-----
Von: Peter Lebbing [mailto:peter at digitalbrains.com] 
Gesendet: Dienstag, 1. November 2016 16:14
An: J?rgen Sch?pker; gnupg-devel at gnupg.org
Betreff: Re: AW: Web Key Service server lookup

On 01/11/16 12:49, J?rgen Sch?pker wrote:
> Another potential issue in the draft: the domain-part seems to be taken from
> the request URL. In a number of hosting configurations, e.g. via reverse
> proxy, the request URL might by default be rewritten (though in some
> configurations it might be recoverable from X-Forwarded-Host header). In case
> the original requester host cannot be determined, this would create potential
> collisions on WKDs answering for multiple domains, e.g. it couldn't discern
> the hashes for joe at for.com and joe at bar.com.

So this is a webserver that serves the exact same for any request for the site
at http://for.com/ and the site at http://bar.com/ and this is not an explicit
decision by the admin but a consequence of limitations of the setup? Sounds
esoteric enough to ignore to me.

My 2 cents,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

Email secured by Check Point

From wk at gnupg.org  Tue Nov  1 17:24:21 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 01 Nov 2016 17:24:21 +0100
Subject: [PATCH] gpg, gpgsm, python: atomic directory creation
In-Reply-To: <CAOazyz0qmFBu_rG=MrW+oN6kD=Msguv6yw4HT5yEfCz2vyo4TA@mail.gmail.com>
 (Alon Bar-Lev's message of "Mon, 24 Oct 2016 20:05:43 +0300")
References: <87a8e0pvmh.fsf@wheatstone.g10code.de>
 <1476867847-24352-1-git-send-email-alon.barlev@gmail.com>
 <CAOazyz0qmFBu_rG=MrW+oN6kD=Msguv6yw4HT5yEfCz2vyo4TA@mail.gmail.com>
Message-ID: <87funb88y2.fsf@wheatstone.g10code.de>

On Mon, 24 Oct 2016 19:05, alon.barlev at gmail.com said:
> Hi,
> Anything more I can do?

I have ticked you mail and will make sure it is applied for the next
release.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161101/3009c0d9/attachment.sig>

From peter at digitalbrains.com  Tue Nov  1 16:14:00 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 1 Nov 2016 16:14:00 +0100
Subject: AW: Web Key Service server lookup
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
Message-ID: <c89d9f9c-04b8-11b2-30a5-d5e251122096@digitalbrains.com>

On 01/11/16 12:49, J?rgen Sch?pker wrote:
> Another potential issue in the draft: the domain-part seems to be taken from
> the request URL. In a number of hosting configurations, e.g. via reverse
> proxy, the request URL might by default be rewritten (though in some
> configurations it might be recoverable from X-Forwarded-Host header). In case
> the original requester host cannot be determined, this would create potential
> collisions on WKDs answering for multiple domains, e.g. it couldn't discern
> the hashes for joe at for.com and joe at bar.com.

So this is a webserver that serves the exact same for any request for the site
at http://for.com/ and the site at http://bar.com/ and this is not an explicit
decision by the admin but a consequence of limitations of the setup? Sounds
esoteric enough to ignore to me.

My 2 cents,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From wk at gnupg.org  Tue Nov  1 17:49:16 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 01 Nov 2016 17:49:16 +0100
Subject: [PATCH 2/5] dirmngr: hkp: avoid race condition when some hosts die
In-Reply-To: <87oa1z5j3g.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 01 Nov 2016 11:13:23 -0400")
References: <20161101003306.12261-1-dkg@fifthhorseman.net>
 <20161101003306.12261-3-dkg@fifthhorseman.net>
 <87bmxza28x.fsf@wheatstone.g10code.de>
 <87oa1z5j3g.fsf@alice.fifthhorseman.net>
Message-ID: <871syv87sj.fsf@wheatstone.g10code.de>

On Tue,  1 Nov 2016 16:13, dkg at fifthhorseman.net said:

> Sorry, i wasn't aware that the only place where a thread could execute
> concurrently was in a call into the kernel.  Will npth never provide
> concurrent execution on any multiprocessor architecture?

That is the whole point of using nPth or the older Pth.  You can
implement most algorithms without thinking about multithreading as long
as you avoid blocking system calls.  nPth is a wrapper around all
blocking system calls which is best illustrated by looking at one of
these calls (modified for readability):

  ssize_t
  npth_read(int fd, void *buf, size_t nbytes)
  {
    ssize_t res;
  
    sem_post (sceptre);  /* This is the core of enter_pth () */
    res = read(fd, buf, nbytes);
    sem_wait (sceptre);  /* This is the core of leave_pth () */
    return res;
  }

The semaphore SCEPTRE has been initialized to 1 (by npth_init at the
start of the program).  Due to the sem_post other threads can continue
to run so that the read() can block but other blocking system calls will
continue to run.  The sem_wait then makes sure that outside of npth_read
only one thread is running.

For special purposes the user may control the blocking on his own by
using npth_enter and npth_leave and thus create threads which run
independent from the npth created threads.  This is for example required
to work with libraries which are not nPth aware (e.g. LDAP).

> I also wasn't aware that xtrymalloc() was guaranteed to never call
> brk().

It doesn't matter because brk is not a blocking call and not wrapped by
nPth.  nPth actually requires the expclit use of nPth versions of the
blocking calls.

> and maintainability of the code, i'm happy to rebase this series without
> it -- the only difference, i suppose, is that i'll have to remove the

I have only picked this patch because I noticed the term "race" in the
subject.

In general I would like to postpone all these patches because they do
not add required features or fixes.  We have a whole bunch of other
topics to address in the next weeks and any other new code will only
delay a release even more.


Shalom-Salam,

   Werner


p.s. 
Please remember to capitalize the first word of a sentence and the
word after a colon in the Changelog entries.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161101/40d65773/attachment.sig>

From wk at gnupg.org  Tue Nov  1 17:52:12 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 01 Nov 2016 17:52:12 +0100
Subject: can we drop -lassuan and -lgpg-error from the output of
 "gpgme-config --libs" ?
In-Reply-To: <87r36v5jqr.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 01 Nov 2016 10:59:24 -0400")
References: <87func8h05.fsf@alice.fifthhorseman.net>
 <874m3ra1yc.fsf@wheatstone.g10code.de>
 <87r36v5jqr.fsf@alice.fifthhorseman.net>
Message-ID: <87shrb6t37.fsf@wheatstone.g10code.de>

On Tue,  1 Nov 2016 15:59, dkg at fifthhorseman.net said:

> This is why we have a -config script, right?  Shouldn't it produce the
> minimal set on platforms that use glibc, and the extended set when built

Right.  But simply dropping would re-open old bugs.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161101/a9b02c6a/attachment.sig>

From peter at digitalbrains.com  Tue Nov  1 18:04:56 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 1 Nov 2016 18:04:56 +0100
Subject: AW: AW: Web Key Service server lookup
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B92@S2008SBS.intern.giepa.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
 <c89d9f9c-04b8-11b2-30a5-d5e251122096@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B92@S2008SBS.intern.giepa.de>
Message-ID: <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>

On 01/11/16 16:47, J?rgen Sch?pker wrote:
> In my experience this is not uncommon.

Taken for granted for a moment that this needs to be dealt with, I'd say the
better solution is to alter the requests from

https://example.org/.well-known/openpgpkey/hu/XXXX

to

https://example.org/.well-known/openpgpkey/example.org/hu/XXXX

In other words, just move all processing a new part in the hierarchy, where you
repeat the "Host:" header part of the HTTP request to cope with situations where
the header is lost, and everything is below that.

Warm regards,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From Juergen.Schaepker at giepa.de  Tue Nov  1 18:15:49 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Tue, 1 Nov 2016 18:15:49 +0100
Subject: AW: AW: AW: Web Key Service server lookup
In-Reply-To: <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
 <c89d9f9c-04b8-11b2-30a5-d5e251122096@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B92@S2008SBS.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@S2008SBS.intern.giepa.de>

Hi,

>to alter the requests from
>https://example.org/.well-known/openpgpkey/hu/XXXX
>to
>https://example.org/.well-known/openpgpkey/example.org/hu/XXXX

That seems to be a reasonable workaround. 

I'm still not sure though why the hash shouldn't be designed by default as a unique ID, using the complete email address. Doing that removes the need for the server to know which domains it provides the lookup for.


Best regards,
JS


From kristian.fiskerstrand at sumptuouscapital.com  Tue Nov  1 20:35:20 2016
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Tue, 1 Nov 2016 20:35:20 +0100
Subject: [PATCH 2/3] dirmngr: add system CAs if no hkp-cacert is given
In-Reply-To: <878tt4a8vc.fsf@alice.fifthhorseman.net>
References: <20161027223059.31844-1-dkg@fifthhorseman.net>
 <20161027223059.31844-2-dkg@fifthhorseman.net>
 <b636f245-c43b-2b48-c16d-48b4635fad59@sumptuouscapital.com>
 <878tt4a8vc.fsf@alice.fifthhorseman.net>
Message-ID: <d7d6148f-227c-55a9-f409-e0c35a96edbb@sumptuouscapital.com>

On 10/31/2016 03:30 PM, Daniel Kahn Gillmor wrote:
> On Thu 2016-10-27 18:59:03 -0400, Kristian Fiskerstrand wrote:
>> On 10/28/2016 12:30 AM, Daniel Kahn Gillmor wrote:
>>> * dirmngr/dirmngr.c (http_session_new): if the user isn't talking to
>>>   the HKPS pool, and they have not specified any hkp-cacert, then we
>>>   should default to the system CAs, rather than nothing.
>>> * doc/dirmngr.texi: document choice of CAs.
>>
>> I'm a bit ambiguous about this change. In Gentoo we currently have the
>> use of a system CA behind a user-selectable use flag for hkps but even
>> so the set of provided CAs is originating mostly from Mozilla.
>>
>> As seen with the latest WoSign / StartCom issues, mozilla is not overly
>> concerned about third-party usage of the provided CA certificates, and
>> have more complex restrictions in place for NSS (e.g specific
>> notBeforeDate and OneCRL checking).
>>
>> As such I question the security of the root stores and actually like
>> that it defaults to not using system CAs so users needs to make an
>> informed decision.
> 
> We're talking about case (b) from the commit message, right?
> 

As discussed here and on IRC you've convinced me that the correct
approach is shifting the focus to auditing the components of the
distribution provided root stores[Note A] and enabling the use of
centralized system root store for the applications.

Handling of the WoSign and StartCom removals will be an interesting test
to see how this is done in various distros, so far I'm only aware of one
that have removed the certs.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"When I was kidnapped, my parents snapped into action. They rented out
my room."
(Woody Allen)

-------------- 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/20161101/54e6fbdb/attachment.sig>

From dkg at fifthhorseman.net  Tue Nov  1 20:39:52 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 01 Nov 2016 15:39:52 -0400
Subject: [PATCH 2/5] dirmngr: hkp: avoid race condition when some hosts die
In-Reply-To: <871syv87sj.fsf@wheatstone.g10code.de>
References: <20161101003306.12261-1-dkg@fifthhorseman.net>
 <20161101003306.12261-3-dkg@fifthhorseman.net>
 <87bmxza28x.fsf@wheatstone.g10code.de>
 <87oa1z5j3g.fsf@alice.fifthhorseman.net>
 <871syv87sj.fsf@wheatstone.g10code.de>
Message-ID: <87h97r3s6v.fsf@alice.fifthhorseman.net>

On Tue 2016-11-01 12:49:16 -0400, Werner Koch wrote:
> That is the whole point of using nPth or the older Pth.  You can
> implement most algorithms without thinking about multithreading as long
> as you avoid blocking system calls.

hm, interesting.  If you can avoid blocking system calls, you can get
the same benefit by just using an event-driven model, with no explicit
threads at all, right?

> In general I would like to postpone all these patches because they do
> not add required features or fixes.

It's not clear to me what features or fixes are required -- but i know
that i want to help people have a functional, smoothly-running system
that supports the modern GnuPG mini-server model without them noticing
the change.  Part of doing that is avoiding systems that are active when
they intend to be idle (which we've had complaints about), so i'm trying
to offer a fix for that on platforms and configurations that can easily
support it.

> We have a whole bunch of other topics to address in the next weeks and
> any other new code will only delay a release even more.

fwiw, this dirmngr series is not a lot of "new code".  rather, it's a
reduction (two patches in this series are simply dead code removal):

 dirmngr/dirmngr.c       | 156 ++----------------------------------------------
 dirmngr/dirmngr.h       |   4 --
 dirmngr/ks-engine-hkp.c |  94 ++++++++++++++---------------
 dirmngr/ldap-wrapper.c  |   7 ++-
 4 files changed, 55 insertions(+), 206 deletions(-)

I don't want these patches to get lost, and i'd love review.  however, i
don't know what the project's priorities are, so i'm not sure how to
make sure they don't fall off of the queue (i don't even know where the
queue is).

What do you recommend i do?

     --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/20161101/25c69fd3/attachment-0001.sig>

From wk at gnupg.org  Wed Nov  2 08:34:51 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 02 Nov 2016 08:34:51 +0100
Subject: [PATCH 2/5] dirmngr: hkp: avoid race condition when some hosts die
In-Reply-To: <87h97r3s6v.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 01 Nov 2016 15:39:52 -0400")
References: <20161101003306.12261-1-dkg@fifthhorseman.net>
 <20161101003306.12261-3-dkg@fifthhorseman.net>
 <87bmxza28x.fsf@wheatstone.g10code.de>
 <87oa1z5j3g.fsf@alice.fifthhorseman.net>
 <871syv87sj.fsf@wheatstone.g10code.de>
 <87h97r3s6v.fsf@alice.fifthhorseman.net>
Message-ID: <8737ja72sk.fsf@wheatstone.g10code.de>

On Tue,  1 Nov 2016 20:39, dkg at fifthhorseman.net said:

> hm, interesting.  If you can avoid blocking system calls, you can get
> the same benefit by just using an event-driven model, with no explicit
> threads at all, right?

Right.  The problem with event driven processing is that complex
operations require a lot of state and it is not anymore possible to
follow the processing flow in an audit.  Thus the use of an automatic
co-processing model (to decribe nPTh in a different way) makes things a
lot easier.

> It's not clear to me what features or fixes are required -- but i know
> that i want to help people have a functional, smoothly-running system
> that supports the modern GnuPG mini-server model without them noticing

I know.  However we need to prioritize what we do.  Even if I say these
patches should go into 2.3 they can also be backported to 2.2 to make it
into a Debian point release.

> fwiw, this dirmngr series is not a lot of "new code".  rather, it's a
> reduction (two patches in this series are simply dead code removal):

Maybe.  Removing code may also break things.  I have also noticed some
portability problem.

> I don't want these patches to get lost, and i'd love review.  however, i

I would suggest to open a feature request and attsch the patches.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161102/6fe705e4/attachment.sig>

From bernhard at intevation.de  Wed Nov  2 09:41:29 2016
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 2 Nov 2016 09:41:29 +0100
Subject: begging for pyme name change
In-Reply-To: <87lgx35ijd.fsf@alice.fifthhorseman.net>
References: <87insx8404.fsf@servo.finestructure.net>
 <201611010848.25027.bernhard@intevation.de>
 <87lgx35ijd.fsf@alice.fifthhorseman.net>
Message-ID: <201611020941.32840.bernhard@intevation.de>

Daniel,

Am Dienstag 01 November 2016 16:25:26 schrieb Daniel Kahn Gillmor:
> On Tue 2016-11-01 03:48:24 -0400, Bernhard Reiter wrote:
> > Again I think that "gnupg" is better,

> i didn't see any proposal to deal with the
> fact that name "gnupg" is currently already taken, both as a pypi
> package ("source package name") and as a python module name ("import
> gnupg"), with the same fairly sophisticated package

my proposal was to use "gnupg2" as a package name to solve the problem.
Adding a number is a solution take by a number of well known python modules 
even in the python standard library. It fits the brand name GnuPG better and 
solves the API problems in a clean and inexpensive way as far as I can see.

>  As it stands, i want to move forward with something with a
> sensible name that only requires a hill of work, and not a mountain ;) I
> hope you'll agree that this is an acceptable tradeoff, and still an
> improvement over "pyme3/pyme" in terms of name recognition and
> usability.

I'll highly appreciate your work on the matter and for leading the discussion. 
If this is the consensus that you have led us to, I will not stand in the 
way. I agree that "python-gpg" is an improvement than "python-pyme". However 
I do not see why that the better "python-gnupg2" is posing "a mountain" of 
work. If other agree with you, it basically means my arguments are not 
considered as valid as yours. 

Anyway I thought I am stateing my different opinion for the record.

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/20161102/c43238dd/attachment.sig>

From bernhard at intevation.de  Wed Nov  2 10:31:30 2016
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 2 Nov 2016 10:31:30 +0100
Subject: WKD for separate email hosting? (Is: Web Key Service server lookup)
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
Message-ID: <201611021031.37406.bernhard@intevation.de>

Hi,

Am Dienstag 01 November 2016 12:49:59 schrieb J?rgen Sch?pker:
> >However the problem is that we'd need a TLS certificate for the subdomain.
> >That is even harder than getting a TLS cert for the example.org domain,
> >so it does not seem to be a good solution.
>
> I would think this is usually solved by wildcard certificates.

the whole benefit of using a standard second domain name like 
pubkeys.example.org would be that that can be hosted on a second 
domain. And for email-only hosters that the server behind this second domian 
can serve many second domains, e.g.
   pubkeys.example.org
and
  pubkeys.example.com

As example.org owner I would need to get "*.example.org" and transfer the
private keys of the cert to my email hoster. And the owner of example.com
needs to be do the same. Then a technique as SNI has to be applied to
the one IP address for the server to serve both certs and the DNS entries
have to be made.

This looks more complicated on the onside  than to let the https server on 
https://example.org proxy to my mailprovider's server over TLS and deliver 
the result.

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/20161102/3d853b9b/attachment.sig>

From bernhard at intevation.de  Wed Nov  2 10:37:16 2016
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 2 Nov 2016 10:37:16 +0100
Subject: WKD lookup priority (Is: Web Key Service server lookup)
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
Message-ID: <201611021037.16694.bernhard@intevation.de>

Am Dienstag 01 November 2016 12:49:59 schrieb J?rgen Sch?pker:
> Regarding the lookup proposed solution:
> One idea would be to allow parallel lookups and using the results retrieved
> by priority when the timeout expired and the highest priority (WKD) did not
> deliver anything before timeout.

This approach would "lose" some information to an attacker that listens
on the transport, because the DNS request is unencrypted.
Of course this is not a lot of info, but it can be avoided by using WKD
via https and wait for failure until trying the next. Usually the request will 
be fast anyway. So I prefer doing WKD via https first (after internal cache 
checking) and wait for the result before doing something else.

Best,
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/20161102/700a8b41/attachment.sig>

From bernhard at intevation.de  Wed Nov  2 10:45:07 2016
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 2 Nov 2016 10:45:07 +0100
Subject: WKD lookup (Re: Web Key Service server lookup)
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@S2008SBS.intern.giepa.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@S2008SBS.intern.giepa.de>
Message-ID: <201611021045.07973.bernhard@intevation.de>

Am Dienstag 01 November 2016 18:15:49 schrieb J?rgen Sch?pker:
> >to alter the requests from
> >https://example.org/.well-known/openpgpkey/hu/XXXX
> >to
> >https://example.org/.well-known/openpgpkey/example.org/hu/XXXX
>
> That seems to be a reasonable workaround.

As pointed out by Peter: I think it can be solved by setup without a 
workaround.

The 00 version of the draft had the "domain" part in the url,
however Werner decided to remove this, the mains reason being url
encoding and trouble with international domain names.

> I'm still not sure though why the hash shouldn't be designed by default as
> a unique ID, using the complete email address. Doing that removes the need
> for the server to know which domains it provides the lookup for.

We had some discussion on this on the list (which you may look up if you are 
interested in how the design came to be.)

I'd say that the server must know which email domains it will serve pubkeys 
for anyway. And it must be encoded in the request url anyway, because this is
the only little trust anchor via checking the TLS cert. The 02 draft design 
meet the minimalist requirement for good design in this regard.

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/20161102/3e14202f/attachment.sig>

From justus at g10code.com  Wed Nov  2 12:40:58 2016
From: justus at g10code.com (Justus Winter)
Date: Wed,  2 Nov 2016 12:40:58 +0100
Subject: [PATCH GnuPG] RFC: g10: Improve and unify key selection.
In-Reply-To: <id:87twbssgu4.fsf@europa.jade-hamburg.de>
References: <id:87twbssgu4.fsf@europa.jade-hamburg.de>
Message-ID: <20161102114058.25580-1-justus@g10code.com>

* g10/getkey.c (struct pubkey_cmp_cookie): New type.
(key_is_ok, uid_is_ok, subkey_is_ok): New functions.
(pubkey_cmp): Likewise.
(get_best_pubkey_byname): Likewise.
* g10/keydb.h (get_best_pubkey_byname): New prototype.
* g10/keylist.c (locate_one): Use the new function.
* g10/pkclist.c (find_and_check_key): Likewise.
--

When a name resembling a mail address is given to either --locate-key
or --recipient, rank the search results and use only the most relevant
key.

This also lets us query which key will be used for encryption using
--locate-key.  XXX: Is this true?  B/c if we use --recipient, we only
consider keys usable for encryption.  Otoh, --locate-key has no such
constraint.

GnuPG-bug-id: 2359
Signed-off-by: Justus Winter <justus at g10code.com>
---
 g10/getkey.c  | 211 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 g10/keydb.h   |   7 ++
 g10/keylist.c |   2 +-
 g10/pkclist.c |   2 +-
 4 files changed, 220 insertions(+), 2 deletions(-)

diff --git a/g10/getkey.c b/g10/getkey.c
index 5ef5fc3..7da75c0 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1461,6 +1461,217 @@ get_pubkey_byname (ctrl_t ctrl, GETKEY_CTX * retctx, PKT_public_key * pk,
   return rc;
 }
 
+
+
+/* Comparison machinery for get_best_pubkey_byname.  */
+
+/* First we have a struct to cache computed information about the key
+   in question.  */
+struct pubkey_cmp_cookie
+{
+  int valid;			/* Are the information valid?  */
+  PKT_public_key key;		/* The key.  */
+  PKT_user_id *uid;		/* The matching UID packet.  */
+  unsigned int validity;	/* Computed validity of (KEY, UID).  */
+  u32 creation_time;		/* Creation time of the newest subkey
+                                   capable of encryption.  */
+};
+
+/* Then we have a series of helper functions.  */
+static int
+key_is_ok (const PKT_public_key *key)
+{
+  return ! key->has_expired && ! key->flags.revoked
+    && key->flags.valid && ! key->flags.disabled;
+}
+
+static int
+uid_is_ok (const PKT_public_key *key, const PKT_user_id *uid)
+{
+  return key_is_ok (key) && ! uid->is_revoked
+#if I_FIGURE_OUT_WHAT_IT_MEANS_FOR_A_UID_TO_BE_INVALID
+    && ! uid->is_invalid
+#endif
+    ;
+}
+
+static int
+subkey_is_ok (const PKT_public_key *sub)
+{
+  return ! sub->flags.revoked && sub->flags.valid && ! sub->flags.disabled;
+}
+
+/* Finally this function compares a NEW key to the former candidate
+   OLD.  */
+static int
+pubkey_cmp (ctrl_t ctrl, const char *name, struct pubkey_cmp_cookie *old,
+            struct pubkey_cmp_cookie *new, KBNODE new_keyblock)
+{
+  KBNODE n;
+
+  new->creation_time = 0;
+  for (n = find_next_kbnode (new_keyblock, PKT_PUBLIC_SUBKEY);
+       n; n = find_next_kbnode (n, PKT_PUBLIC_SUBKEY))
+    {
+      PKT_public_key *sub = n->pkt->pkt.public_key;
+
+      if ((sub->pubkey_usage & PUBKEY_USAGE_ENC) == 0)
+        continue;
+
+      if (! subkey_is_ok (sub))
+        continue;
+
+      if (sub->timestamp > new->creation_time)
+        new->creation_time = sub->timestamp;
+    }
+
+  new->uid = NULL;
+  for (n = find_next_kbnode (new_keyblock, PKT_USER_ID);
+       n; n = find_next_kbnode (n, PKT_USER_ID))
+    {
+      PKT_user_id *uid = n->pkt->pkt.user_id;
+      char *mbox = mailbox_from_userid (uid->name);
+      int match = mbox ? strcasecmp (name, mbox) == 0 : 0;
+
+      xfree (mbox);
+      if (! match)
+        continue;
+
+      new->uid = uid;
+      new->validity =
+        get_validity (ctrl, &new->key, uid, NULL, 0) & TRUST_MASK;
+      new->valid = 1;
+
+      if (! old->valid)
+        return -1;	/* No OLD key.  */
+
+      if (! uid_is_ok (&old->key, old->uid) && uid_is_ok (&new->key, uid))
+        return 1;	/* Validity of the NEW key is better.  */
+
+      if (old->validity < new->validity)
+        return 1;	/* Validity of the NEW key is better.  */
+
+      if (old->validity == new->validity && uid_is_ok (&new->key, uid)
+          && old->creation_time < new->creation_time)
+        return 1;	/* Both keys are of the same validity, but the
+                           NEW key is newer.  */
+    }
+
+  /* Stick with the OLD key.  */
+  return -1;
+}
+
+
+/* This function works like get_pubkey_byname, but if the name
+   resembles a mail address, the results are ranked and only the best
+   result is returned.  */
+int
+get_best_pubkey_byname (ctrl_t ctrl, GETKEY_CTX *retctx, PKT_public_key *pk,
+                        const char *name, KBNODE *ret_keyblock,
+                        int include_unusable, int no_akl)
+{
+  int rc;
+  struct getkey_ctx_s *ctx = NULL;
+  KBNODE keyblock;
+
+  if (ret_keyblock == NULL)
+    ret_keyblock = &keyblock;
+
+  rc = get_pubkey_byname (ctrl, &ctx, pk, name, ret_keyblock,
+                          NULL, include_unusable, no_akl);
+  if (rc)
+    {
+      if (ctx)
+        getkey_end (ctx);
+      if (retctx)
+        *retctx = NULL;
+      return rc;
+    }
+
+  if (is_valid_mailbox (name))
+    {
+      /* Rank results and return only the most relevant key.  */
+      struct pubkey_cmp_cookie best = { 0 }, new;
+      while (getkey_next (ctx, &new.key, NULL) == 0)
+        {
+          int diff = pubkey_cmp (ctrl, name, &best, &new, *ret_keyblock);
+          if (diff < 0)
+            {
+              /* New key is better.  */
+              release_public_key_parts (&best.key);
+              best = new;
+            }
+          else if (diff > 0)
+            {
+              /* Old key is better.  */
+              release_public_key_parts (&new.key);
+            }
+          else
+            {
+              /* A tie.  Keep the old key.  */
+              release_public_key_parts (&new.key);
+            }
+        }
+      getkey_end (ctx);
+      ctx = NULL;
+
+      if (best.valid)
+        {
+          if (retctx || ret_keyblock)
+            {
+              ctx = xtrycalloc (1, sizeof **retctx);
+              if (! ctx)
+                rc = gpg_error_from_syserror ();
+              else
+                {
+                  ctx->kr_handle = keydb_new ();
+                  if (! ctx->kr_handle)
+                    {
+                      xfree (ctx);
+                      *retctx = NULL;
+                      rc = gpg_error_from_syserror ();
+                    }
+                  else
+                    {
+                      u32 *keyid = pk_keyid (&best);
+                      ctx->exact = 1;
+                      ctx->nitems = 1;
+                      ctx->items[0].mode = KEYDB_SEARCH_MODE_LONG_KID;
+                      ctx->items[0].u.kid[0] = keyid[0];
+                      ctx->items[0].u.kid[1] = keyid[1];
+
+                      if (ret_keyblock)
+                        {
+                          release_kbnode (*ret_keyblock);
+                          *ret_keyblock = NULL;
+                          rc = getkey_next (ctx, NULL, ret_keyblock);
+                        }
+                    }
+                }
+            }
+
+          if (pk)
+            *pk = best.key;
+          else
+            release_public_key_parts (&best.key);
+        }
+    }
+
+  if (rc && ctx)
+    {
+      getkey_end (ctx);
+      ctx = NULL;
+    }
+
+  if (retctx && ctx)
+    *retctx = ctx;
+  else
+    getkey_end (ctx);
+
+  return rc;
+}
+
+
 
 /* Get a public key from a file.
  *
diff --git a/g10/keydb.h b/g10/keydb.h
index 35512bb..11cc695 100644
--- a/g10/keydb.h
+++ b/g10/keydb.h
@@ -324,6 +324,13 @@ int get_pubkey_byname (ctrl_t ctrl,
                        KBNODE *ret_keyblock, KEYDB_HANDLE *ret_kdbhd,
 		       int include_unusable, int no_akl );
 
+/* Likewise, but only return the best match if NAME resembles a mail
+   address.  */
+int get_best_pubkey_byname (ctrl_t ctrl,
+			    GETKEY_CTX *retctx, PKT_public_key *pk,
+			    const char *name, KBNODE *ret_keyblock,
+			    int include_unusable, int no_akl);
+
 /* Get a public key directly from file FNAME.  */
 gpg_error_t get_pubkey_fromfile (ctrl_t ctrl,
                                  PKT_public_key *pk, const char *fname);
diff --git a/g10/keylist.c b/g10/keylist.c
index 212d77e..51dc409 100644
--- a/g10/keylist.c
+++ b/g10/keylist.c
@@ -650,7 +650,7 @@ locate_one (ctrl_t ctrl, strlist_t names)
 
   for (sl = names; sl; sl = sl->next)
     {
-      rc = get_pubkey_byname (ctrl, &ctx, NULL, sl->d, &keyblock, NULL, 1, 0);
+      rc = get_best_pubkey_byname (ctrl, &ctx, NULL, sl->d, &keyblock, 1, 0);
       if (rc)
 	{
 	  if (gpg_err_code (rc) != GPG_ERR_NO_PUBKEY)
diff --git a/g10/pkclist.c b/g10/pkclist.c
index da4cc06..eef3437 100644
--- a/g10/pkclist.c
+++ b/g10/pkclist.c
@@ -838,7 +838,7 @@ find_and_check_key (ctrl_t ctrl, const char *name, unsigned int use,
   if (from_file)
     rc = get_pubkey_fromfile (ctrl, pk, name);
   else
-    rc = get_pubkey_byname (ctrl, NULL, pk, name, NULL, NULL, 0, 0);
+    rc = get_best_pubkey_byname (ctrl, NULL, pk, name, NULL, 0, 0);
   if (rc)
     {
       int code;
-- 
2.10.1



From justus at g10code.com  Wed Nov  2 12:58:59 2016
From: justus at g10code.com (Justus Winter)
Date: Wed, 02 Nov 2016 12:58:59 +0100
Subject: [PATCH] Spelling: correct spelling of "passphrase"
In-Reply-To: <20161028190611.17524-1-dkg@fifthhorseman.net>
References: <20161028190611.17524-1-dkg@fifthhorseman.net>
Message-ID: <874m3qjdoc.fsf@europa.jade-hamburg.de>

Hey,

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
> There were several different variant spellings of "passphrase".  This
> should fix them all for all English text.

thanks for the patch, I have applied it.

However:

> diff --git a/doc/help.be.txt b/doc/help.be.txt
> index 36c9ffb..f722b8c 100644
> --- a/doc/help.be.txt
> +++ b/doc/help.be.txt
> @@ -228,7 +228,7 @@ self-signatures will be advanced by one second.
>  
>  .#gpg.passphrase.enter
>  # fixme: Please translate and remove the hash mark from the key line.
> -Please enter the passhrase; this is a secret sentence 
> +Please enter the passphrase; this is a secret sentence 

You are adding a line with trailing whitespace.  I don't know how you
got this past your git commit hook (I'm guessing you disabled it), but
we also use this hook on the git server, and it does not allow me to
push such a commit.  So I had to amend your patch accordingly, and I
remember that I had to do so in the past.  So *please* enable that hook
that checks for these mistakes.


Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20161102/365a08fb/attachment.sig>

From Juergen.Schaepker at giepa.de  Wed Nov  2 13:01:42 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Wed, 2 Nov 2016 13:01:42 +0100
Subject: AW: WKD lookup priority (Is: Web Key Service server lookup)
In-Reply-To: <201611021037.16694.bernhard@intevation.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
 <201611021037.16694.bernhard@intevation.de>
Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD5@S2008SBS.intern.giepa.de>

Hi,

>This approach would "lose" some information to an attacker that listens
>on the transport, because the DNS request is unencrypted.
>Of course this is not a lot of info, but it can be avoided by using WKD
>via https and wait for failure until trying the next. Usually the request will 
>be fast anyway. So I prefer doing WKD via https first (after internal cache 
>checking) and wait for the result before doing something else.

In practice this would mean waiting maybe 60 or 120 seconds for WKD to fail (if system timeouts are used) before starting other lookups.

I think it should be customizable if other lookups are started in parallel and the timeout period waiting for WKD.


Best regards,
JS

From justus at g10code.com  Wed Nov  2 13:02:37 2016
From: justus at g10code.com (Justus Winter)
Date: Wed, 02 Nov 2016 13:02:37 +0100
Subject: [PATCH] Fix misspelled dirmngr
In-Reply-To: <20161101002433.12106-1-dkg@fifthhorseman.net>
References: <20161101002433.12106-1-dkg@fifthhorseman.net>
Message-ID: <871syujdia.fsf@europa.jade-hamburg.de>


Applied, thanks.

Nitpick: Please use a component in the summary line, in this case
'build', and end the summary with a colon.


Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20161102/4c13f0a8/attachment.sig>

From Juergen.Schaepker at giepa.de  Wed Nov  2 13:12:30 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Wed, 2 Nov 2016 13:12:30 +0100
Subject: AW: WKD for separate email hosting? (Is: Web Key Service server
 lookup)
In-Reply-To: <201611021031.37406.bernhard@intevation.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
 <201611021031.37406.bernhard@intevation.de>
Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD6@S2008SBS.intern.giepa.de>

Hi,

>the whole benefit of using a standard second domain name like 
>pubkeys.example.org would be that that can be hosted on a second 
>domain. And for email-only hosters that the server behind this second domian 
>can serve many second domains, e.g.
>   pubkeys.example.org
>and
>  pubkeys.example.com

The big benefit is a much easier setup or in some cases the only way setting up WKD at all.

>As example.org owner I would need to get "*.example.org" and transfer the
>private keys of the cert to my email hoster. And the owner of example.com
>needs to be do the same. Then a technique as SNI has to be applied to
>the one IP address for the server to serve both certs and the DNS entries
>have to be made.

Your use case seems to be only/primarily Mail Service Providers. 

My concern is for small/medium business entities who don't use an MSP but just their own email server, possibly forwarded and gatewayed through whatever. They should be able to simply use a subdomain if they want to.

Or is the standard by itself only intended for private use?

>This looks more complicated on the onside  than to let the https server on 
>https://example.org proxy to my mailprovider's server over TLS and deliver 
>the result.

Many small/medium businesses who use cheap webhosting services have no control over redirection on the server that hosts their example.com. Mail is often routed to a completely different system. The use case here is that they should be able to set up a WKD server easily.

Best regards,
JS



From justus at g10code.com  Wed Nov  2 13:22:26 2016
From: justus at g10code.com (Justus Winter)
Date: Wed, 02 Nov 2016 13:22:26 +0100
Subject: [STABLE-BRANCH-1-4 PATCH] tools: Fix option parsing for gpg-zip.
In-Reply-To: <20160829145616.8916-1-dkg@fifthhorseman.net>
References: <20160829145616.8916-1-dkg@fifthhorseman.net>
Message-ID: <87y412hy0t.fsf@europa.jade-hamburg.de>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

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

Merged, thanks!

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20161102/2f1c993e/attachment.sig>

From justus at g10code.com  Wed Nov  2 13:23:00 2016
From: justus at g10code.com (Justus Winter)
Date: Wed, 02 Nov 2016 13:23:00 +0100
Subject: [STABLE-BRANCH-1-4 PATCH] spelling: correct achived to achieved
In-Reply-To: <20160829143633.15270-1-dkg@fifthhorseman.net>
References: <20160829143633.15270-1-dkg@fifthhorseman.net>
Message-ID: <87vaw6hxzv.fsf@europa.jade-hamburg.de>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> ---
>  THOUGHTS     | 2 +-
>  doc/gpg.texi | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Merged, thanks!

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20161102/e3ace7c8/attachment.sig>

From Juergen.Schaepker at giepa.de  Wed Nov  2 13:24:53 2016
From: Juergen.Schaepker at giepa.de (=?Windows-1252?Q?J=FCrgen_Sch=E4pker?=)
Date: Wed, 2 Nov 2016 13:24:53 +0100
Subject: AW: WKD lookup (Re: Web Key Service server lookup)
In-Reply-To: <201611021045.07973.bernhard@intevation.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@S2008SBS.intern.giepa.de>
 <201611021045.07973.bernhard@intevation.de>
Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@S2008SBS.intern.giepa.de>

Hi,

>The 00 version of the draft had the "domain" part in the url,
>however Werner decided to remove this, the mains reason being url
>encoding and trouble with international domain names.

I'd believe WKD servers need to normalize domain names in any case, this normalization should be in the standard.

>> I'm still not sure though why the hash shouldn't be designed by default as
>> a unique ID, using the complete email address. Doing that removes the need
>> for the server to know which domains it provides the lookup for.

>I'd say that the server must know which email domains it will serve pubkeys 
>for anyway. And it must be encoded in the request url anyway, because this is
>the only little trust anchor via checking the TLS cert. The 02 draft design 
>meet the minimalist requirement for good design in this regard.

The request URL will be modified e.g. by default by most reverse proxies. You cannot rely on it containing the original host domain name. 


Best regards,
JS



From kristian.fiskerstrand at sumptuouscapital.com  Wed Nov  2 13:29:42 2016
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 2 Nov 2016 13:29:42 +0100
Subject: WKD for separate email hosting? (Is: Web Key Service server
 lookup)
In-Reply-To: <201611021031.37406.bernhard@intevation.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
 <201611021031.37406.bernhard@intevation.de>
Message-ID: <395ae83b-3be7-bfe2-b394-5fc2430fadcf@sumptuouscapital.com>

On 11/02/2016 10:31 AM, Bernhard Reiter wrote:
>>> However the problem is that we'd need a TLS certificate for the subdomain.
>>> > >That is even harder than getting a TLS cert for the example.org domain,
>>> > >so it does not seem to be a good solution.
>> >
>> > I would think this is usually solved by wildcard certificates.
> the whole benefit of using a standard second domain name like 
> pubkeys.example.org would be that that can be hosted on a second 
> domain.

I'm not sure if it is worth it still, just as a banal start of
discussion; having a subdomain being used could open up different attack
vectors if a user can control this (pubkeys.github.org user?). And
serving it on a separate server is trivial to do using a reverse proxy
request on the loadbalancer anyways.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"History repeats itself; historians repeat each other"
(Philip Guedalla)

-------------- 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/20161102/97f52520/attachment-0001.sig>

From aheinecke at intevation.de  Wed Nov  2 14:14:25 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Wed, 02 Nov 2016 14:14:25 +0100
Subject: [PATCH GnuPG] RFC: g10: Improve and unify key selection.
In-Reply-To: <20161102114058.25580-1-justus@g10code.com>
References: <20161102114058.25580-1-justus@g10code.com>
Message-ID: <1867561.BuBvmWHY45@esus>

Hi,

Generally looks good to me. But your algroithm does not take tofu into 
account. (Mine did neither). The problem is that TOFU does not affect the 
validity of the UID. Which I think is a problem because it complicates things. 
As you then have to check the tofu binding policy, too.

E.g. if you have a conflict both uid's will be unknown with tofu validity 
unknown and the tofu policy set to ask. ( issue2817 )

Or worse for this algorithm, if a key was explicitly marked as bad in tofu it 
would still be used by this algorithm as the policy is not checked. But again 
this might be fixed by tofu changing the validity in that case to never.


On Wednesday 02 November 2016 12:40:58 Justus Winter wrote:
> When a name resembling a mail address is given to either --locate-key
> or --recipient, rank the search results and use only the most relevant
> key.
> 
> This also lets us query which key will be used for encryption using
> --locate-key.  XXX: Is this true?  B/c if we use --recipient, we only
> consider keys usable for encryption.  Otoh, --locate-key has no such
> constraint.

I think with the change you can remove the second part of your commit message 
now.

> +/* First we have a struct to cache computed information about the key
> +   in question.  */
> +struct pubkey_cmp_cookie
> +{
> +  int valid;			/* Are the information valid?  */

I think it should be "Is the cookie valid?"

> +static int
> +uid_is_ok (const PKT_public_key *key, const PKT_user_id *uid)
> +{
> +  return key_is_ok (key) && ! uid->is_revoked
> +#if I_FIGURE_OUT_WHAT_IT_MEANS_FOR_A_UID_TO_BE_INVALID
> +    && ! uid->is_invalid
> +#endif

I think an invalid uid may be a uid with an invalid self signature but I'm not 
sure either. But in doubt so such a uid should be skipped, too.

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: 659 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161102/07e57c37/attachment.sig>

From dkg at fifthhorseman.net  Wed Nov  2 17:48:00 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 02 Nov 2016 12:48:00 -0400
Subject: [PATCH] Spelling: correct spelling of "passphrase"
In-Reply-To: <874m3qjdoc.fsf@europa.jade-hamburg.de>
References: <20161028190611.17524-1-dkg@fifthhorseman.net>
 <874m3qjdoc.fsf@europa.jade-hamburg.de>
Message-ID: <87k2cl3k1r.fsf@alice.fifthhorseman.net>

On Wed 2016-11-02 07:58:59 -0400, Justus Winter wrote:
>> diff --git a/doc/help.be.txt b/doc/help.be.txt
>> index 36c9ffb..f722b8c 100644
>> --- a/doc/help.be.txt
>> +++ b/doc/help.be.txt
>> @@ -228,7 +228,7 @@ self-signatures will be advanced by one second.
>>  
>>  .#gpg.passphrase.enter
>>  # fixme: Please translate and remove the hash mark from the key line.
>> -Please enter the passhrase; this is a secret sentence 
>> +Please enter the passphrase; this is a secret sentence 
>
> You are adding a line with trailing whitespace.  I don't know how you
> got this past your git commit hook (I'm guessing you disabled it), but
> we also use this hook on the git server, and it does not allow me to
> push such a commit.  So I had to amend your patch accordingly, and I
> remember that I had to do so in the past.  So *please* enable that hook
> that checks for these mistakes.

Hm, sorry, it looks like i'd commented out that check in my pre-commit
hook, probably because i need to commit patches to other branches of my
git repo (for debian packaging purposes), and a patch which includes an
empty context line will invariably have trailing whitespace (the full
line looks like " ").  I'll try to adjust the check to limit this
allowance to those branches where i need to commit patches.

I also note that the original (replaced) line itself had trailing
whitespace.  If the goal is no trailing whitespace, and you want people
to enforce this, perhaps it'd be worthwhile to do a global trailing
whitespace cleanup?

thanks for the merges!

        --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/20161102/4c5df91b/attachment.sig>

From aheinecke at intevation.de  Wed Nov  2 19:46:42 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Wed, 02 Nov 2016 19:46:42 +0100
Subject: Clean whitespace errors in gnupg repos (was Re: [PATCH] Spelling:
 correct spelling of "passphrase")
In-Reply-To: <87k2cl3k1r.fsf@alice.fifthhorseman.net>
References: <20161028190611.17524-1-dkg@fifthhorseman.net>
 <874m3qjdoc.fsf@europa.jade-hamburg.de>
 <87k2cl3k1r.fsf@alice.fifthhorseman.net>
Message-ID: <1707539.LRh0i1C7qQ@esus>

Hi,

On Wednesday 02 November 2016 12:48:00 Daniel Kahn Gillmor wrote:
> I also note that the original (replaced) line itself had trailing
> whitespace.  If the goal is no trailing whitespace, and you want people
> to enforce this, perhaps it'd be worthwhile to do a global trailing
> whitespace cleanup?

Yes! Please! I know it makes history / blame a bit harder but not really a 
problem. In KDE we had coding style changes that changed nearly every line but 
I can still work with git to figure out the history. We should do this in all 
gnupg repos imo, maybe combined with an astyle run.

I find it very annoying in GpgOL (tons of whitespace errors) that this was 
never done. Makes patches harder and whitespace errors are highlighted in my 
editor so I "want" to fix them automatically and its irritating to ignore 
theese highlights.

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: 659 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161102/010b641c/attachment.sig>

From wk at gnupg.org  Wed Nov  2 20:35:25 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 02 Nov 2016 20:35:25 +0100
Subject: Clean whitespace errors in gnupg repos
In-Reply-To: <1707539.LRh0i1C7qQ@esus> (Andre Heinecke's message of "Wed, 02
 Nov 2016 19:46:42 +0100")
References: <20161028190611.17524-1-dkg@fifthhorseman.net>
 <874m3qjdoc.fsf@europa.jade-hamburg.de>
 <87k2cl3k1r.fsf@alice.fifthhorseman.net> <1707539.LRh0i1C7qQ@esus>
Message-ID: <87y4114qv6.fsf@wheatstone.g10code.de>

On Wed,  2 Nov 2016 19:46, aheinecke at intevation.de said:

> Yes! Please! I know it makes history / blame a bit harder but not really a 
> problem. In KDE we had coding style changes that changed nearly every

I consider this a real annoyance and thus a global chnage is not a good
idea.  Some years ago I re-indented _most_ files and I do want another
bulk change again.

If you encounter trailing white spaces when doing a fix for a file,
please postpone the fix until you have trimmed and commited those white
spaces.

> I find it very annoying in GpgOL (tons of whitespace errors) that this was 

SVN legacy.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161102/9c018041/attachment.sig>

From dkg at fifthhorseman.net  Wed Nov  2 23:34:34 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 02 Nov 2016 18:34:34 -0400
Subject: Clean whitespace errors in gnupg repos
In-Reply-To: <87y4114qv6.fsf@wheatstone.g10code.de>
References: <20161028190611.17524-1-dkg@fifthhorseman.net>
 <874m3qjdoc.fsf@europa.jade-hamburg.de>
 <87k2cl3k1r.fsf@alice.fifthhorseman.net> <1707539.LRh0i1C7qQ@esus>
 <87y4114qv6.fsf@wheatstone.g10code.de>
Message-ID: <87oa1x1pfp.fsf@alice.fifthhorseman.net>

On Wed 2016-11-02 15:35:25 -0400, Werner Koch wrote:
> On Wed,  2 Nov 2016 19:46, aheinecke at intevation.de said:
>
>> Yes! Please! I know it makes history / blame a bit harder but not really a 
>> problem. In KDE we had coding style changes that changed nearly every
>
> I consider this a real annoyance and thus a global chnage is not a good
> idea.  Some years ago I re-indented _most_ files and I do want another
> bulk change again.

unless one of these messages is off by a "not", this paragraph doesn't
make sense to me.

> If you encounter trailing white spaces when doing a fix for a file,
> please postpone the fix until you have trimmed and commited those white
> spaces.

So those of us without commit access shouldn't do work on any fixes that
touch files with whitespace errors until we've convinced someone with
the commit bit to clean the whitespace in a given file?  It's unclear to
me how i should effectively act on this advice other than advocating for
a repo-wide whitespace cleanup, as i was trying to do.

Surely the goal is to facilitate review of external contributions based
on substance, rather than erecting hurdles to contribution based on
form?

           --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/20161102/a8627cc6/attachment.sig>

From wk at gnupg.org  Thu Nov  3 08:05:25 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 03 Nov 2016 08:05:25 +0100
Subject: Clean whitespace errors in gnupg repos
In-Reply-To: <87oa1x1pfp.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 02 Nov 2016 18:34:34 -0400")
References: <20161028190611.17524-1-dkg@fifthhorseman.net>
 <874m3qjdoc.fsf@europa.jade-hamburg.de>
 <87k2cl3k1r.fsf@alice.fifthhorseman.net> <1707539.LRh0i1C7qQ@esus>
 <87y4114qv6.fsf@wheatstone.g10code.de>
 <87oa1x1pfp.fsf@alice.fifthhorseman.net>
Message-ID: <87ins53ux6.fsf@wheatstone.g10code.de>

On Wed,  2 Nov 2016 23:34, dkg at fifthhorseman.net said:

>> idea.  Some years ago I re-indented _most_ files and I do want another
>> bulk change again.
>
> unless one of these messages is off by a "not", this paragraph doesn't
> make sense to me.

Correction: ... and I do not want another bulk change again.

> So those of us without commit access shouldn't do work on any fixes that
> touch files with whitespace errors until we've convinced someone with

The committers will notice that anyway and can do the fix prior to
applying a fix.  Anyway, those remaining trailing white space are mostly
in files not having been touched for many years like the help text
files.  Thus it should not be a real problem.  IIRC, the patch in
question was the first in in many months with white space problems?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161103/15b2ab69/attachment.sig>

From Juergen.Schaepker at giepa.de  Thu Nov  3 10:48:29 2016
From: Juergen.Schaepker at giepa.de (=?Windows-1252?Q?J=FCrgen_Sch=E4pker?=)
Date: Thu, 3 Nov 2016 10:48:29 +0100
Subject: Web Key Directory handling of IDN
Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@S2008SBS.intern.giepa.de>

Hi,

the current draft currently does not appear to handle possible issues with IDN addresses, specifically there is no definition if only punycode domain names are to be used by client search requests or if UTF8 is allowed for lookups. Request URLs are probably expected to be in punycode on the server while the local-part hash might be generated from an UTF8-string that is lower-cased for ASCII-only, ignoring case for non-ASCII.

I believe the standard should allow for searches for IDN email addresses. The hash should be calculated from the complete address, local and domain part, to avoid all possible issues with the request URL and domain association. Lower-casing should probably be applied to all characters before hashing, using a defined algorithm.


Best regards,
JS




From justus at g10code.com  Thu Nov  3 11:13:41 2016
From: justus at g10code.com (Justus Winter)
Date: Thu, 03 Nov 2016 11:13:41 +0100
Subject: Clean whitespace errors in gnupg repos
In-Reply-To: <87ins53ux6.fsf@wheatstone.g10code.de>
References: <20161028190611.17524-1-dkg@fifthhorseman.net>
 <874m3qjdoc.fsf@europa.jade-hamburg.de>
 <87k2cl3k1r.fsf@alice.fifthhorseman.net> <1707539.LRh0i1C7qQ@esus>
 <87y4114qv6.fsf@wheatstone.g10code.de>
 <87oa1x1pfp.fsf@alice.fifthhorseman.net>
 <87ins53ux6.fsf@wheatstone.g10code.de>
Message-ID: <87eg2syip6.fsf@europa.jade-hamburg.de>

Werner Koch <wk at gnupg.org> writes:
>> So those of us without commit access shouldn't do work on any fixes that
>> touch files with whitespace errors until we've convinced someone with
>
> The committers will notice that anyway and can do the fix prior to
> applying a fix.

I read Werners statement differently, but please correct me if I'm
wrong.  I thought the best practice is to fix whitespace issues iff one
touches the offenting lines anyway.  This way we get rid of issues
eventually while preserving relevant authorship information.


Cheers,
Justus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20161103/b51079eb/attachment.sig>

From dkg at fifthhorseman.net  Thu Nov  3 16:43:56 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu,  3 Nov 2016 11:43:56 -0400
Subject: [PINENTRY PATCH] gnome3: Test if Gcr System Prompter is available at
 startup.
In-Reply-To: <878tt01trc.fsf@alice.fifthhorseman.net>
References: <878tt01trc.fsf@alice.fifthhorseman.net>
Message-ID: <20161103154356.28300-1-dkg@fifthhorseman.net>

* gnome3/pinentry-gnome3.c (gcr_system_prompt_available): new function
  tests whether it is possible to create a GcrSystemPrompt; (main):
  use gcr_system_prompt_available() to decide whether to fall back to
  curses or not.

Debian-bug-id: 842015
Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 gnome3/pinentry-gnome3.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index d6d7d16..37c7a44 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -258,6 +258,39 @@ gnome3_cmd_handler (pinentry_t pe)
 
 pinentry_cmd_handler_t pinentry_cmd_handler = gnome3_cmd_handler;
 
+
+/* test whether we can create a system prompt or not.  This briefly
+   does create a system prompt, which blocks other tools from making
+   the same concurrent request, so we just create it to test if it is
+   available, and quickly close it.
+*/
+int gcr_system_prompt_available ()
+{
+  GcrSystemPrompt *prompt;
+  GError *error = NULL;
+  int ret = 0;
+  
+  prompt = gcr_system_prompt_open (0, NULL, &error);
+  if (prompt)
+    {
+      ret = 1;
+      if (!gcr_system_prompt_close (prompt, NULL, &error))
+          fprintf (stderr, "failed to close test Gcr System Prompt (%d): %s\n",
+                   error ? error->code : -1, error ? error->message : "<no GError>");
+      g_clear_object (&prompt);
+    }
+  else
+      /* This one particular failure is OK; we're clearly capable of
+         making a system prompt, even though someone else has the
+         system prompter right now: */
+    if (error && error->code == GCR_SYSTEM_PROMPT_IN_PROGRESS)
+      ret = 1;
+
+  if (error)
+    g_error_free (error);
+  return ret;
+}
+
 int
 main (int argc, char *argv[])
 {
@@ -270,6 +303,12 @@ main (int argc, char *argv[])
                " falling back to curses\n");
       pinentry_cmd_handler = curses_cmd_handler;
     }
+  else if (!gcr_system_prompt_available ())
+    {
+      fprintf (stderr, "No Gcr System Prompter available,"
+               " falling back to curses\n");
+      pinentry_cmd_handler = curses_cmd_handler;
+    }      
 #endif
 
   pinentry_parse_opts (argc, argv);
-- 
2.10.1



From justus at g10code.com  Thu Nov  3 16:56:59 2016
From: justus at g10code.com (Justus Winter)
Date: Thu, 03 Nov 2016 16:56:59 +0100
Subject: [PINENTRY PATCH] gnome3: Test if Gcr System Prompter is available
 at startup.
In-Reply-To: <20161103154356.28300-1-dkg@fifthhorseman.net>
References: <878tt01trc.fsf@alice.fifthhorseman.net>
 <20161103154356.28300-1-dkg@fifthhorseman.net>
Message-ID: <878tt0y2t0.fsf@europa.jade-hamburg.de>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> * gnome3/pinentry-gnome3.c (gcr_system_prompt_available): new function
>   tests whether it is possible to create a GcrSystemPrompt; (main):
>   use gcr_system_prompt_available() to decide whether to fall back to
>   curses or not.

Please start each sentence with a capital letter, end with a full stop.
Put a newline before a new (item).  Please don't indent the lines (I
know, emacs does that by itself, a little annoying, but my emacs-foo is
too low to fix that).

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20161103/7e8ee2c6/attachment.sig>

From dkg at fifthhorseman.net  Thu Nov  3 17:25:28 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 03 Nov 2016 12:25:28 -0400
Subject: [PINENTRY PATCH] gnome3: Test if Gcr System Prompter is available
 at startup.
In-Reply-To: <878tt0y2t0.fsf@europa.jade-hamburg.de>
References: <878tt01trc.fsf@alice.fifthhorseman.net>
 <20161103154356.28300-1-dkg@fifthhorseman.net>
 <878tt0y2t0.fsf@europa.jade-hamburg.de>
Message-ID: <874m3o1qfb.fsf@alice.fifthhorseman.net>

On Thu 2016-11-03 11:56:59 -0400, Justus Winter wrote:
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>
>> * gnome3/pinentry-gnome3.c (gcr_system_prompt_available): new function
>>   tests whether it is possible to create a GcrSystemPrompt; (main):
>>   use gcr_system_prompt_available() to decide whether to fall back to
>>   curses or not.
>
> Please start each sentence with a capital letter, end with a full stop.
> Put a newline before a new (item).  Please don't indent the lines (I
> know, emacs does that by itself, a little annoying, but my emacs-foo is
> too low to fix that).

Could you please also include some feedback on the actual code provided?
It would make the orthographic nit-pickery a little easier to stomach.

      --dkg, frustrated, and trying to fix real problems here
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161103/0bc639df/attachment.sig>

From dkg at fifthhorseman.net  Thu Nov  3 17:31:40 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu,  3 Nov 2016 12:31:40 -0400
Subject: [PINENTRY PATCH v2] gnome3: Test if Gcr System Prompter is available
 at startup.
In-Reply-To: <878tt0y2t0.fsf@europa.jade-hamburg.de>
References: <878tt0y2t0.fsf@europa.jade-hamburg.de>
Message-ID: <20161103163140.29183-1-dkg@fifthhorseman.net>

* gnome3/pinentry-gnome3.c (gcr_system_prompt_available): New. Tests
whether it is possible to create a GcrSystemPrompt.
(main): Use gcr_system_prompt_available() to decide whether to fall
back to curses or not.

Debian-bug-id: 842015
Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 gnome3/pinentry-gnome3.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index d6d7d16..37c7a44 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -258,6 +258,39 @@ gnome3_cmd_handler (pinentry_t pe)
 
 pinentry_cmd_handler_t pinentry_cmd_handler = gnome3_cmd_handler;
 
+
+/* test whether we can create a system prompt or not.  This briefly
+   does create a system prompt, which blocks other tools from making
+   the same concurrent request, so we just create it to test if it is
+   available, and quickly close it.
+*/
+int gcr_system_prompt_available ()
+{
+  GcrSystemPrompt *prompt;
+  GError *error = NULL;
+  int ret = 0;
+  
+  prompt = gcr_system_prompt_open (0, NULL, &error);
+  if (prompt)
+    {
+      ret = 1;
+      if (!gcr_system_prompt_close (prompt, NULL, &error))
+          fprintf (stderr, "failed to close test Gcr System Prompt (%d): %s\n",
+                   error ? error->code : -1, error ? error->message : "<no GError>");
+      g_clear_object (&prompt);
+    }
+  else
+      /* This one particular failure is OK; we're clearly capable of
+         making a system prompt, even though someone else has the
+         system prompter right now: */
+    if (error && error->code == GCR_SYSTEM_PROMPT_IN_PROGRESS)
+      ret = 1;
+
+  if (error)
+    g_error_free (error);
+  return ret;
+}
+
 int
 main (int argc, char *argv[])
 {
@@ -270,6 +303,12 @@ main (int argc, char *argv[])
                " falling back to curses\n");
       pinentry_cmd_handler = curses_cmd_handler;
     }
+  else if (!gcr_system_prompt_available ())
+    {
+      fprintf (stderr, "No Gcr System Prompter available,"
+               " falling back to curses\n");
+      pinentry_cmd_handler = curses_cmd_handler;
+    }      
 #endif
 
   pinentry_parse_opts (argc, argv);
-- 
2.10.1



From wk at gnupg.org  Thu Nov  3 18:04:33 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 03 Nov 2016 18:04:33 +0100
Subject: emacs-foo (was: Bug#842015: [PINENTRY PATCH] gnome3: Test if Gcr
 System Prompter is available at startup)
In-Reply-To: <878tt0y2t0.fsf@europa.jade-hamburg.de> (Justus Winter's message
 of "Thu, 03 Nov 2016 16:56:59 +0100")
References: <878tt01trc.fsf@alice.fifthhorseman.net>
 <20161103154356.28300-1-dkg@fifthhorseman.net>
 <878tt0y2t0.fsf@europa.jade-hamburg.de>
Message-ID: <8737j81om6.fsf_-_@wheatstone.g10code.de>

On Thu,  3 Nov 2016 16:56, justus at g10code.com said:

> know, emacs does that by itself, a little annoying, but my emacs-foo is
> too low to fix that).

ChangeLog mode gets this right and the 'C' key in Magit does nearly the
Right Thing.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161103/263e497c/attachment.sig>

From wk at gnupg.org  Thu Nov  3 18:02:44 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 03 Nov 2016 18:02:44 +0100
Subject: Bug#842015: [PINENTRY PATCH] gnome3: Test if Gcr System Prompter
 is available at startup.
In-Reply-To: <874m3o1qfb.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Thu, 03 Nov 2016 12:25:28 -0400")
References: <878tt01trc.fsf@alice.fifthhorseman.net>
 <20161103154356.28300-1-dkg@fifthhorseman.net>
 <878tt0y2t0.fsf@europa.jade-hamburg.de>
 <874m3o1qfb.fsf@alice.fifthhorseman.net>
Message-ID: <877f8k1op7.fsf@wheatstone.g10code.de>

On Thu,  3 Nov 2016 17:25, dkg at fifthhorseman.net said:

> Could you please also include some feedback on the actual code provided?

Looks fine.  I have no way to test it right now, though.

> It would make the orthographic nit-pickery a little easier to stomach.
>
>       --dkg, frustrated, and trying to fix real problems here

For easier reading a common indentation is a Good Thing.  Given that I
assume to see even more patches from you we need to be a bit picky about
this.  I fact, i told Justus only yesterday to keep an eye on these
things.

I know this can be frustrating - I'll buy you a beer or two.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161103/b554341b/attachment.sig>

From dkg at fifthhorseman.net  Thu Nov  3 17:59:18 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu,  3 Nov 2016 12:59:18 -0400
Subject: [PINENTRY PATCH 2/2] Convert to UTF-8.
In-Reply-To: <20161103165918.32295-1-dkg@fifthhorseman.net>
References: <20161103165918.32295-1-dkg@fifthhorseman.net>
Message-ID: <20161103165918.32295-2-dkg@fifthhorseman.net>

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 AUTHORS           | 2 +-
 doc/pinentry.texi | 2 +-
 qt/Makefile.am    | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index 695d0ba..d74004a 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -5,7 +5,7 @@ License: GPLv2+
 
 Robert Bihlmeyer <robbe at orcus.priv.at>
 Werner Koch, g10 Code GmbH <wk at gnupg.org>
-Steffen Hansen, Klar?lvdalens Datakonsult AB <steffen at klaralvdalens-datakonsult.se>
+Steffen Hansen, Klar??lvdalens Datakonsult AB <steffen at klaralvdalens-datakonsult.se>
 Marcus Brinkmann, g10 Code GmbH <marcus at g10code.com>
 Timo Schulz, g10 Code GmbH
 Neal Walfied, g10 Code GmbH <neal at gnu.org>
diff --git a/doc/pinentry.texi b/doc/pinentry.texi
index e9da4ee..feef4f0 100644
--- a/doc/pinentry.texi
+++ b/doc/pinentry.texi
@@ -64,7 +64,7 @@ This is edition @value{EDITION}, last updated @value{UPDATED}, of
 @cite{The `PINEntry' Manual}, for version @value{VERSION}.
 @sp 1
 Published by g10 Code GmbH@*
-H?ttenstr. 61@*
+H??ttenstr. 61@*
 40699 Erkrath, Germany
 @sp 1
 @copyrightnotice{}
diff --git a/qt/Makefile.am b/qt/Makefile.am
index 96d0880..6659007 100644
--- a/qt/Makefile.am
+++ b/qt/Makefile.am
@@ -1,5 +1,5 @@
 # Makefile.am
-# Copyright (C) 2002 g10 Code GmbH, Klar?lvdalens Datakonsult AB
+# Copyright (C) 2002 g10 Code GmbH, Klar??lvdalens Datakonsult AB
 # Copyright (C) 2008, 2015 g10 Code GmbH
 #
 # This file is part of PINENTRY.
-- 
2.10.1



From dkg at fifthhorseman.net  Thu Nov  3 18:08:23 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 03 Nov 2016 13:08:23 -0400
Subject: [PINENTRY PATCH v2] gnome3: Test if Gcr System Prompter is
 available at startup.
In-Reply-To: <20161103163140.29183-1-dkg@fifthhorseman.net>
References: <878tt0y2t0.fsf@europa.jade-hamburg.de>
 <20161103163140.29183-1-dkg@fifthhorseman.net>
Message-ID: <871sys1ofs.fsf@alice.fifthhorseman.net>

Control: tags 842015 + patch

On Thu 2016-11-03 12:31:40 -0400, Daniel Kahn Gillmor wrote:
> +/* test whether we can create a system prompt or not.  This briefly
> +   does create a system prompt, which blocks other tools from making
> +   the same concurrent request, so we just create it to test if it is
> +   available, and quickly close it.
> +*/
> +int gcr_system_prompt_available ()

Just to be clear here -- this doesn't actually open any windows or
display anything.  It simply asks the gcr to reserve the right to make a
system prompt:

    https://developer.gnome.org/gcr/stable/GcrSystemPrompt.html#gcr-system-prompt-open

It should fail properly if:

 * there is nothing providing the gcr service on the current d-bus
   session, or

 * there is something which provides gcr, but it knows it is unable to
   make a system prompt.

let me know if you have any questions,

   --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/20161103/39813d03/attachment-0001.sig>

From dkg at fifthhorseman.net  Thu Nov  3 17:59:17 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu,  3 Nov 2016 12:59:17 -0400
Subject: [PINENTRY PATCH 1/2] Fix spelling errors.
Message-ID: <20161103165918.32295-1-dkg@fifthhorseman.net>

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 ChangeLog-old            |  8 ++++----
 NEWS                     |  2 +-
 build-aux/texinfo.tex    | 12 ++++++------
 doc/pinentry.texi        |  4 ++--
 doc/texinfo.tex          | 12 ++++++------
 gnome3/pinentry-gnome3.c |  2 +-
 m4/glib.m4               |  6 +++---
 m4/gtk.m4                |  6 +++---
 pinentry/argparse.c      |  2 +-
 pinentry/pinentry.c      |  4 ++--
 pinentry/pinentry.h      |  4 ++--
 qt/pinentrydialog.cpp    |  2 +-
 12 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/ChangeLog-old b/ChangeLog-old
index cad8c1a..02a8010 100644
--- a/ChangeLog-old
+++ b/ChangeLog-old
@@ -999,7 +999,7 @@
 
 	* configure.ac: Version 0.6.9
 	* qt/Makefile.am: Added moc files to DISTCLEANFILES
-	* qt/pinentrycontroller.cpp: Dont spew assuan debug stuff out on stderr.
+	* qt/pinentrycontroller.cpp: Don't spew assuan debug stuff out on stderr.
 
 2003-03-26  Steffen Hansen  <steffen at klaralvdalens-datakonsult.se>
 
@@ -1619,7 +1619,7 @@
 2000-04-23  Robert Bihlmeyer  <robbe at orcus.priv.at>
 
 	* secret-query.c (constrain_size): Lower window max_width to
-	accomodate bugs in GTK and Scwm.
+	accommodate bugs in GTK and Scwm.
 
 	* agent.c (main): Set x_enabled if X appears to be available.
 	Use it to selectively make FLAGS_INSURE supported.
@@ -1861,7 +1861,7 @@
 
 	* agent.c (main): Moved secmem_init() after the fork, since that
 	seemingly munlock's all pages.
-	Drop priviledges just in case somebody wants to install this
+	Drop privileges just in case somebody wants to install this
 	suid-root.
 	Flush stdout.
 
@@ -1953,7 +1953,7 @@
 	* Thoughts: Removed discussion of other names.
 	Added indication of which things already work.
 
-	* agent.c (make_tmpdir): Removed occurance of "gpg-agent."
+	* agent.c (make_tmpdir): Removed occurrence of "gpg-agent."
 
 	* README: First proper version.
 
diff --git a/NEWS b/NEWS
index 4278865..7a7ca76 100644
--- a/NEWS
+++ b/NEWS
@@ -217,7 +217,7 @@ Noteworthy changes in version 0.7.3 (2007-07-06)
  * New option --colors=FG,BG,SO to set the colors for the curses
    pinentry.
 
- * Pinentry-w32 does now basicaly work.  It needs some finishing
+ * Pinentry-w32 does now basically work.  It needs some finishing
    though.  For example the buttons should resize themself according
    to the size of the text.
 
diff --git a/build-aux/texinfo.tex b/build-aux/texinfo.tex
index a181898..5552e50 100644
--- a/build-aux/texinfo.tex
+++ b/build-aux/texinfo.tex
@@ -3,7 +3,7 @@
 % Load plain if necessary, i.e., if running under initex.
 \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
 %
-\def\texinfoversion{2007-05-03.09}
+\def\texinfoversion{2016-11-03.12}
 %
 % Copyright (C) 1985, 1986, 1988, 1990, 1991, 1992, 1993, 1994, 1995,
 % 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
@@ -415,7 +415,7 @@
 \def\argremovecomment#1\comment#2\ArgTerm{\argremovec #1\c\ArgTerm}
 \def\argremovec#1\c#2\ArgTerm{\argcheckspaces#1\^^M\ArgTerm}
 
-% Each occurence of `\^^M' or `<space>\^^M' is replaced by a single space.
+% Each occurrence of `\^^M' or `<space>\^^M' is replaced by a single space.
 %
 % \argremovec might leave us with trailing space, e.g.,
 %    @end itemize  @c foo
@@ -440,7 +440,7 @@
 % to get _exactly_ the rest of the line, we had to prevent such situation.
 % We prepended an \empty token at the very beginning and we expand it now,
 % just before passing the control to \argtorun.
-% (Similarily, we have to think about #3 of \argcheckspacesY above: it is
+% (Similarly, we have to think about #3 of \argcheckspacesY above: it is
 % either the null string, or it ends with \^^M---thus there is no danger
 % that a pair of braces would be stripped.
 %
@@ -497,7 +497,7 @@
 % used to check whether the current environment is the one expected.
 %
 % Non-false conditionals (@iftex, @ifset) don't fit into this, so they
-% are not treated as enviroments; they don't open a group.  (The
+% are not treated as environments; they don't open a group.  (The
 % implementation of @end takes care not to call \endgroup in this
 % special case.)
 
@@ -4598,7 +4598,7 @@ end
 \chardef\maxseclevel = 3
 %
 % A numbered section within an unnumbered changes to unnumbered too.
-% To achive this, remember the "biggest" unnum. sec. we are currently in:
+% To achieve this, remember the "biggest" unnum. sec. we are currently in:
 \chardef\unmlevel = \maxseclevel
 %
 % Trace whether the current chapter is an appendix or not:
@@ -7034,7 +7034,7 @@ end
 % In case a @footnote appears in a vbox, save the footnote text and create
 % the real \insert just after the vbox finished.  Otherwise, the insertion
 % would be lost.
-% Similarily, if a @footnote appears inside an alignment, save the footnote
+% Similarly, if a @footnote appears inside an alignment, save the footnote
 % text to a box and make the \insert when a row of the table is finished.
 % And the same can be done for other insert classes.  --kasal, 16nov03.
 
diff --git a/doc/pinentry.texi b/doc/pinentry.texi
index dcff886..e9da4ee 100644
--- a/doc/pinentry.texi
+++ b/doc/pinentry.texi
@@ -711,14 +711,14 @@ The actual return code is dependent on whether the dialog is in
 message mode or in passphrase mode.
 
 If the dialog is in message mode and the user pressed ok, return 1.
-Otherwise, return 0.  If an error occured, indicate this by setting it
+Otherwise, return 0.  If an error occurred, indicate this by setting it
 in @code{specific_err} or setting @code{locale_err} to @code{1} (for
 locale specific errors).  If the dialog was canceled, then the handler
 should set the @code{canceled} variable to @code{1}.  If the not ok
 button was pressed, don't do anything else.
 
 If the dialog is in passphrase mode return @code{1} if the user
-entered a password and pressed ok.  If an error occured, return
+entered a password and pressed ok.  If an error occurred, return
 @code{-1} and set @code{specific_err} or @code{locale_err}, as above.
 If the user canceled the dialog box, return @code{-1}.
 
diff --git a/doc/texinfo.tex b/doc/texinfo.tex
index 5063065..919d85d 100644
--- a/doc/texinfo.tex
+++ b/doc/texinfo.tex
@@ -3,7 +3,7 @@
 % Load plain if necessary, i.e., if running under initex.
 \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
 %
-\def\texinfoversion{2007-05-03.09}
+\def\texinfoversion{2016-11-03.12}
 %
 % Copyright (C) 1985, 1986, 1988, 1990, 1991, 1992, 1993, 1994, 1995,
 % 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
@@ -415,7 +415,7 @@
 \def\argremovecomment#1\comment#2\ArgTerm{\argremovec #1\c\ArgTerm}
 \def\argremovec#1\c#2\ArgTerm{\argcheckspaces#1\^^M\ArgTerm}
 
-% Each occurence of `\^^M' or `<space>\^^M' is replaced by a single space.
+% Each occurrence of `\^^M' or `<space>\^^M' is replaced by a single space.
 %
 % \argremovec might leave us with trailing space, e.g.,
 %    @end itemize  @c foo
@@ -440,7 +440,7 @@
 % to get _exactly_ the rest of the line, we had to prevent such situation.
 % We prepended an \empty token at the very beginning and we expand it now,
 % just before passing the control to \argtorun.
-% (Similarily, we have to think about #3 of \argcheckspacesY above: it is
+% (Similarly, we have to think about #3 of \argcheckspacesY above: it is
 % either the null string, or it ends with \^^M---thus there is no danger
 % that a pair of braces would be stripped.
 %
@@ -497,7 +497,7 @@
 % used to check whether the current environment is the one expected.
 %
 % Non-false conditionals (@iftex, @ifset) don't fit into this, so they
-% are not treated as enviroments; they don't open a group.  (The
+% are not treated as environments; they don't open a group.  (The
 % implementation of @end takes care not to call \endgroup in this
 % special case.)
 
@@ -4598,7 +4598,7 @@ end
 \chardef\maxseclevel = 3
 %
 % A numbered section within an unnumbered changes to unnumbered too.
-% To achive this, remember the "biggest" unnum. sec. we are currently in:
+% To achieve this, remember the "biggest" unnum. sec. we are currently in:
 \chardef\unmlevel = \maxseclevel
 %
 % Trace whether the current chapter is an appendix or not:
@@ -7034,7 +7034,7 @@ end
 % In case a @footnote appears in a vbox, save the footnote text and create
 % the real \insert just after the vbox finished.  Otherwise, the insertion
 % would be lost.
-% Similarily, if a @footnote appears inside an alignment, save the footnote
+% Similarly, if a @footnote appears inside an alignment, save the footnote
 % text to a box and make the \insert when a row of the table is finished.
 % And the same can be done for other insert classes.  --kasal, 16nov03.
 
diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index d6d7d16..90ff60f 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -104,7 +104,7 @@ create_prompt (pinentry_t pe, int confirm)
       g_free (msg);
     }
 
-  /* An error occured during the last prompt.  */
+  /* An error occurred during the last prompt.  */
   if (pe->error)
     {
       msg = pinentry_utf8_validate (pe->error);
diff --git a/m4/glib.m4 b/m4/glib.m4
index b3c632b..7338acb 100644
--- a/m4/glib.m4
+++ b/m4/glib.m4
@@ -95,7 +95,7 @@ main ()
              glib_major_version, glib_minor_version, glib_micro_version);
       printf ("*** was found! If glib-config was correct, then it is best\n");
       printf ("*** to remove the old version of GLIB. You may also be able to fix the error\n");
-      printf("*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing\n");
+      printf("*** by modifying your LD_LIBRARY_PATH environment variable, or by editing\n");
       printf("*** /etc/ld.so.conf. Make sure you have run ldconfig if that is\n");
       printf("*** required on your system.\n");
       printf("*** If glib-config was wrong, set the environment variable GLIB_CONFIG\n");
@@ -132,7 +132,7 @@ main ()
         printf("*** being found. The easiest way to fix this is to remove the old version\n");
         printf("*** of GLIB, but you can also set the GLIB_CONFIG environment to point to the\n");
         printf("*** correct copy of glib-config. (In this case, you will have to\n");
-        printf("*** modify your LD_LIBRARY_PATH enviroment variable, or edit /etc/ld.so.conf\n");
+        printf("*** modify your LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf\n");
         printf("*** so that the correct libraries are found at run-time))\n");
       }
     }
@@ -179,7 +179,7 @@ main ()
           echo "***"
           echo "***    rpm --erase --nodeps gtk gtk-devel" ],
         [ echo "*** The test program failed to compile or link. See the file config.log for the"
-          echo "*** exact error that occured. This usually means GLIB was incorrectly installed"
+          echo "*** exact error that occurred. This usually means GLIB was incorrectly installed"
           echo "*** or that you have moved GLIB since it was installed. In the latter case, you"
           echo "*** may want to edit the glib-config script: $GLIB_CONFIG" ])
           CFLAGS="$ac_save_CFLAGS"
diff --git a/m4/gtk.m4 b/m4/gtk.m4
index f2dd472..6f6a422 100644
--- a/m4/gtk.m4
+++ b/m4/gtk.m4
@@ -91,7 +91,7 @@ main ()
              gtk_major_version, gtk_minor_version, gtk_micro_version);
       printf ("*** was found! If gtk-config was correct, then it is best\n");
       printf ("*** to remove the old version of GTK+. You may also be able to fix the error\n");
-      printf("*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing\n");
+      printf("*** by modifying your LD_LIBRARY_PATH environment variable, or by editing\n");
       printf("*** /etc/ld.so.conf. Make sure you have run ldconfig if that is\n");
       printf("*** required on your system.\n");
       printf("*** If gtk-config was wrong, set the environment variable GTK_CONFIG\n");
@@ -130,7 +130,7 @@ main ()
         printf("*** being found. The easiest way to fix this is to remove the old version\n");
         printf("*** of GTK+, but you can also set the GTK_CONFIG environment to point to the\n");
         printf("*** correct copy of gtk-config. (In this case, you will have to\n");
-        printf("*** modify your LD_LIBRARY_PATH enviroment variable, or edit /etc/ld.so.conf\n");
+        printf("*** modify your LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf\n");
         printf("*** so that the correct libraries are found at run-time))\n");
       }
     }
@@ -177,7 +177,7 @@ main ()
           echo "***"
           echo "***    rpm --erase --nodeps gtk gtk-devel" ],
         [ echo "*** The test program failed to compile or link. See the file config.log for the"
-          echo "*** exact error that occured. This usually means GTK was incorrectly installed"
+          echo "*** exact error that occurred. This usually means GTK was incorrectly installed"
           echo "*** or that you have moved GTK since it was installed. In the latter case, you"
           echo "*** may want to edit the gtk-config script: $GTK_CONFIG" ])
           CFLAGS="$ac_save_CFLAGS"
diff --git a/pinentry/argparse.c b/pinentry/argparse.c
index e31b67e..4f586d4 100644
--- a/pinentry/argparse.c
+++ b/pinentry/argparse.c
@@ -845,7 +845,7 @@ find_long_option( ARGPARSE_ARGS *arg,
     /* Would be better if we can do a binary search, but it is not
        possible to reorder our option table because we would mess
        up our help strings - What we can do is: Build a nice option
-       lookup table wehn this function is first invoked */
+       lookup table when this function is first invoked */
     if( !*keyword )
 	return -1;
     for(i=0; opts[i].short_opt; i++ )
diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c
index 3131b1e..4a0f859 100644
--- a/pinentry/pinentry.c
+++ b/pinentry/pinentry.c
@@ -96,7 +96,7 @@ pinentry_reset (int use_defaults)
   pinentry_color_t color_so = pinentry.color_so;
   int color_so_bright = pinentry.color_so_bright;
 
-  int timout = pinentry.timeout;
+  int timeout = pinentry.timeout;
 
   char *invisible_char = pinentry.invisible_char;
 
@@ -184,7 +184,7 @@ pinentry_reset (int use_defaults)
       pinentry.color_so = color_so;
       pinentry.color_so_bright = color_so_bright;
 
-      pinentry.timeout = timout;
+      pinentry.timeout = timeout;
     }
 }
 
diff --git a/pinentry/pinentry.h b/pinentry/pinentry.h
index 50d5f98..c6e12e4 100644
--- a/pinentry/pinentry.h
+++ b/pinentry/pinentry.h
@@ -109,7 +109,7 @@ struct pinentry
   int canceled;
 
   /* The frontend should set this to true if an error with the local
-     conversion occured. */
+     conversion occurred. */
   int locale_err;
 
   /* The frontend should set this to a gpg-error so that commands are
@@ -222,7 +222,7 @@ typedef struct pinentry *pinentry_t;
    PIN.  If PIN->pin is zero, request a confirmation, otherwise a PIN
    entry.  On confirmation, the function should return TRUE if
    confirmed, and FALSE otherwise.  On PIN entry, the function should
-   return -1 if an error occured or the user cancelled the operation
+   return -1 if an error occurred or the user cancelled the operation
    and 1 otherwise.  */
 typedef int (*pinentry_cmd_handler_t) (pinentry_t pin);
 
diff --git a/qt/pinentrydialog.cpp b/qt/pinentrydialog.cpp
index 12f7718..f9dd700 100644
--- a/qt/pinentrydialog.cpp
+++ b/qt/pinentrydialog.cpp
@@ -75,7 +75,7 @@ WINBOOL SetForegroundWindowEx(HWND hWnd)
 
 void raiseWindow(QWidget *w)
 {
-    /* Maybe Qt will become agressive enough one day that
+    /* Maybe Qt will become aggressive enough one day that
      * this is enough on windows too*/
     w->raise();
 #ifdef Q_OS_WIN
-- 
2.10.1



From wk at gnupg.org  Thu Nov  3 19:00:15 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 03 Nov 2016 19:00:15 +0100
Subject: [PINENTRY PATCH 2/2] Convert to UTF-8.
In-Reply-To: <20161103165918.32295-2-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Thu, 3 Nov 2016 12:59:18 -0400")
References: <20161103165918.32295-1-dkg@fifthhorseman.net>
 <20161103165918.32295-2-dkg@fifthhorseman.net>
Message-ID: <87ins4zbo0.fsf@wheatstone.g10code.de>

Hi!

I pushed both patches.  Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161103/75442612/attachment.sig>

From vinay_sajip at yahoo.co.uk  Fri Nov  4 11:11:15 2016
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Fri, 4 Nov 2016 10:11:15 +0000 (UTC)
Subject: Using loopback pin entry with GnuPG 2.1
In-Reply-To: <878ttegr3s.fsf@wheatstone.g10code.de>
References: <574777160.1243146.1476982583037.ref@mail.yahoo.com>
 <574777160.1243146.1476982583037@mail.yahoo.com>
 <878ttegr3s.fsf@wheatstone.g10code.de>
Message-ID: <868322669.288810.1478254275137@mail.yahoo.com>

Dear Werner,

Thanks for the suggestions. My comments are:

>  $ gpg-error 67108924
>  67108924 = (4, 60) = (GPG_ERR_SOURCE_GPGAGENT, GPG_ERR_NOT_SUPPORTED) \
>                     = (GPG Agent, Not supported)

gpg-error is apparently not shipped with all distros - there's no sign of it on my Ubuntu system. Is there a list of error codes with meanings published somewhere (other than in gpg-error.h)?

I did the following:

> watchgnupg --force /home/foo/.gnupg/S.log

> in a second terminal and add this to gpg-agent.conf:

>  log-file socket:///home/foo/.gnupg/S.log
>  verbose
>  debug ipc


The second window now shows traffic with the agent, e.g.:

[client at fd 4 connected (local)]
4 - 2016-11-04 10:04:10  started
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> OK Pleased to meet you, process 1897
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 <- OK Pleased to meet you, process 1897
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 -> GETINFO pid
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 <- GETINFO pid
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> D 1897
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 <- D 1897
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> OK
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 <- OK
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 -> BYE
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 <- BYE
4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> OK closing connection
4 - 2016-11-04 10:04:10 gpg-agent[1897]: handler 0x7f960ce8b700 for fd 6 terminated


However, when I run the tests (and they fail as before, with the same error code), no further details are displayed by watchgnupg.

Do you have any further suggestions?

Thanks and regards,

Vinay Sajip


From peter at digitalbrains.com  Fri Nov  4 11:30:38 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 4 Nov 2016 11:30:38 +0100
Subject: Using loopback pin entry with GnuPG 2.1
In-Reply-To: <868322669.288810.1478254275137@mail.yahoo.com>
References: <574777160.1243146.1476982583037.ref@mail.yahoo.com>
 <574777160.1243146.1476982583037@mail.yahoo.com>
 <878ttegr3s.fsf@wheatstone.g10code.de>
 <868322669.288810.1478254275137@mail.yahoo.com>
Message-ID: <cbcc294e-2b02-dd89-c575-c3a9034bcd6e@digitalbrains.com>

On 04/11/16 11:11, Vinay Sajip wrote:
> gpg-error is apparently not shipped with all distros - there's no
> sign of it on my Ubuntu system.

It's in the package libgpg-error-dev.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From wk at gnupg.org  Fri Nov  4 15:00:43 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Nov 2016 15:00:43 +0100
Subject: Using loopback pin entry with GnuPG 2.1
In-Reply-To: <868322669.288810.1478254275137@mail.yahoo.com> (Vinay Sajip's
 message of "Fri, 4 Nov 2016 10:11:15 +0000 (UTC)")
References: <574777160.1243146.1476982583037.ref@mail.yahoo.com>
 <574777160.1243146.1476982583037@mail.yahoo.com>
 <878ttegr3s.fsf@wheatstone.g10code.de>
 <868322669.288810.1478254275137@mail.yahoo.com>
Message-ID: <87twbnwdis.fsf@wheatstone.g10code.de>

On Fri,  4 Nov 2016 11:11, vinay_sajip at yahoo.co.uk said:

>
> The second window now shows traffic with the agent, e.g.:
>
> [client at fd 4 connected (local)]
> 4 - 2016-11-04 10:04:10  started
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> OK Pleased to meet you, process 1897
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 <- OK Pleased to meet you, process 1897
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 -> GETINFO pid
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 <- GETINFO pid
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_6 -> D 1897
> 4 - 2016-11-04 10:04:10 gpg-agent[1897]: DBG: chan_4 <- D 1897

That is gpg-agent making a connection to itself to see whether its
socket is still connected to self.  This is done once a minute.

It seems your gpg is not using that agent.

You can add "--debug ipc" to gpg to get gpg's site of the communication.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161104/6592f819/attachment-0001.sig>

From wk at gnupg.org  Fri Nov  4 17:05:24 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Nov 2016 17:05:24 +0100
Subject: AW: AW: Web Key Service server lookup
In-Reply-To: <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com> (Peter
 Lebbing's message of "Tue, 1 Nov 2016 18:04:56 +0100")
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
 <c89d9f9c-04b8-11b2-30a5-d5e251122096@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B92@S2008SBS.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
Message-ID: <87eg2rw7qz.fsf@wheatstone.g10code.de>

On Tue,  1 Nov 2016 18:04, peter at digitalbrains.com said:

> better solution is to alter the requests from
>
> https://example.org/.well-known/openpgpkey/hu/XXXX
>
> to
>
> https://example.org/.well-known/openpgpkey/example.org/hu/XXXX

My first implementation actually did it this way but I figured that this
raises more problems than it solves.  Even the simplest HTTP servers can
rewrite the URL or symlink the directories.  Thus the duplication is not
required and won't help with the certificate problem of vanity domains
(mail only domain w/o web space)



Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161104/23efb17b/attachment.sig>

From wk at gnupg.org  Fri Nov  4 17:08:12 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Nov 2016 17:08:12 +0100
Subject: AW: WKD lookup (Re: Web Key Service server lookup)
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@S2008SBS.intern.giepa.de>
 (=?utf-8?Q?=22J=C3=BCrgen_Sch=C3=A4pker=22's?= message of "Wed, 2 Nov 2016
 13:24:53 +0100")
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@S2008SBS.intern.giepa.de>
 <201611021045.07973.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@S2008SBS.intern.giepa.de>
Message-ID: <87a8dfw7mb.fsf@wheatstone.g10code.de>

On Wed,  2 Nov 2016 13:24, Juergen.Schaepker at giepa.de said:

> I'd believe WKD servers need to normalize domain names in any case, this normalization should be in the standard.

We actually don't talk about domain names - it is an implementation
detail of the HTTP transport on how to map URLs to IP addresses.

> The request URL will be modified e.g. by default by most reverse proxies. You cannot rely on it containing the original host domain name. 

Again an implementation detail and not part of the protocol.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161104/761a2436/attachment.sig>

From wk at gnupg.org  Fri Nov  4 17:11:25 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Nov 2016 17:11:25 +0100
Subject: AW: WKD for separate email hosting? (Is: Web Key Service server
 lookup)
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD6@S2008SBS.intern.giepa.de>
 (=?utf-8?Q?=22J=C3=BCrgen_Sch=C3=A4pker=22's?= message of "Wed, 2 Nov 2016
 13:12:30 +0100")
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
 <201611021031.37406.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD6@S2008SBS.intern.giepa.de>
Message-ID: <8760o3w7gy.fsf@wheatstone.g10code.de>

On Wed,  2 Nov 2016 13:12, Juergen.Schaepker at giepa.de said:

> Many small/medium businesses who use cheap webhosting services have no
> control over redirection on the server that hosts their
> example.com. Mail is often routed to a completely different
> system. The use case here is that they should be able to set up a WKD
> server easily.

So what?  As long as the well-known URL under _their_ domain resolves it
all works.  Even the mail can be processes outside as long as they can
direct mails to a certain account to their server running the WKS.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161104/344918f0/attachment.sig>

From Juergen.Schaepker at giepa.de  Fri Nov  4 17:44:36 2016
From: Juergen.Schaepker at giepa.de (=?Windows-1252?Q?J=FCrgen_Sch=E4pker?=)
Date: Fri, 4 Nov 2016 17:44:36 +0100
Subject: AW: AW: WKD for separate email hosting? (Is: Web Key Service server
 lookup)
In-Reply-To: <8760o3w7gy.fsf@wheatstone.g10code.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
 <201611021031.37406.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD6@S2008SBS.intern.giepa.de>
 <8760o3w7gy.fsf@wheatstone.g10code.de>
Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C8F@S2008SBS.intern.giepa.de>

Hi,

>So what?  As long as the well-known URL under _their_ domain resolves it
>all works.  Even the mail can be processes outside as long as they can
>direct mails to a certain account to their server running the WKS.

What about multiple domains handled by a single server?

Please also see my question on IDN handling. If the complete (normalized) email address isn?t used to calculate the hash (on both client and server), I think there is no way to determine an unambiguous IDN address. ASCII-only lowercasing is not really a working option.


Best regards,
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161104/a80e80ca/attachment.html>

From Juergen.Schaepker at giepa.de  Fri Nov  4 17:51:37 2016
From: Juergen.Schaepker at giepa.de (=?Windows-1252?Q?J=FCrgen_Sch=E4pker?=)
Date: Fri, 4 Nov 2016 17:51:37 +0100
Subject: AW: AW: WKD lookup (Re: Web Key Service server lookup)
In-Reply-To: <87a8dfw7mb.fsf@wheatstone.g10code.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@S2008SBS.intern.giepa.de>
 <201611021045.07973.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@S2008SBS.intern.giepa.de>
 <87a8dfw7mb.fsf@wheatstone.g10code.de>
Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C90@S2008SBS.intern.giepa.de>

Hi,

>We actually don't talk about domain names - it is an implementation
>detail of the HTTP transport on how to map URLs to IP addresses.

>> The request URL will be modified e.g. by default by most reverse proxies. You cannot rely on it containing the original host domain name.

>Again an implementation detail and not part of the protocol.

How exactly is the domain-part supposed to be determined by the WKD server?


Best regards,
JS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161104/28fd23e8/attachment.html>

From peter at digitalbrains.com  Fri Nov  4 20:15:14 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 4 Nov 2016 20:15:14 +0100
Subject: Web Key Directory handling of IDN
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@S2008SBS.intern.giepa.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@S2008SBS.intern.giepa.de>
Message-ID: <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>

On 03/11/16 10:48, J?rgen Sch?pker wrote:
> the current draft currently does not appear to handle possible issues
> with IDN addresses, specifically there is no definition if only
> punycode domain names are to be used by client search requests or if
> UTF8 is allowed for lookups.

Can you give a concrete example along with the point where you observe
ambiguity? I believe that internationalised e-mail just uses UTF-8 on
most of the higher layers. I don't believe MUAs even need to deal with
IDN, they just use UTF-8. And WKD seems to work as interacting MUA's and
static HTTPS URLs. So I'm not quite following where the problem comes
in. You send a mail to an UTF-8 address. You receive a reply on an UTF-8
email address, and so on, and the URL for key retrieval doesn't actually
contain the domain name, so there is no problem with the domain name
there either.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From peter at digitalbrains.com  Fri Nov  4 20:22:56 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 4 Nov 2016 20:22:56 +0100
Subject: Web Key Directory handling of IDN
In-Reply-To: <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@S2008SBS.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
Message-ID: <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>

On 04/11/16 20:15, Peter Lebbing wrote:
> and the URL for key retrieval doesn't actually contain the domain
> name, so there is no problem with the domain name there either.

Sorry, that's horribly inaccurate, I meant the path portion of the URL
doesn't contain the domain name.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From wk at gnupg.org  Fri Nov  4 21:03:37 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Nov 2016 21:03:37 +0100
Subject: Question to WKD-Feature
In-Reply-To: <bad1978d-bc5b-91a4-0a22-e0a1cd23e119@heinlein-support.de> (Peter
 Fischer's message of "Tue, 25 Oct 2016 18:47:13 +0200")
References: <bad1978d-bc5b-91a4-0a22-e0a1cd23e119@heinlein-support.de>
Message-ID: <877f8jui5i.fsf@wheatstone.g10code.de>

Hi Peter,

On Tue, 25 Oct 2016 18:47, p.fischer at heinlein-support.de said:

> "The HTTP GET method MUST return the binary representation of the
> OpenPGP key for the given mail address"
>
> Q1: Why is the output-key-format of the WKD-server binary and not
> "ASCII amored"? In difference the key-format of the submissions-mail
> is "ASCII armored".

It is binary because HTTP transports binary data just fine.

In contrast SMTP is not able to transport binary (hard line length
limitation) so that PGP/MIME (RFC-3156) demands armored messages.
Right, they could have also used binary so that MIME would be forces to
use Base64 encoding.  I guess Michael Elkins wrote the specs in that way
to make it easier for implementations (checkout how Mutt handles PGP).

A single fixed format makes it easier for implementations because the
test for binary or armored is not needed (cf. gpg's option --no-armor)
and a couple of problems with armor won't happen.  There has also been a
discussion in the OpenPGP WG on dropping the armor format from the
standard (unlikely to happen, though).

> Q2: Why do you build the URL for the public keys with SHA1-hash of the
> local-part?
>  * Are SHA1 hash-collisions theoretically possible (special on large
> userbases) ?

No.  But that is not the point; the hashing is only used to map all
possible local-parts to a character set which can easily be expressed in
an URL and be used in a file system (e.g. '/' is allowed in the
local-part but problematic in a file name).

>  * What about lower-casing all upper-case ASCII characters in
> local-part? Maybe encoding base64, for forward and backward lookup of
> the local-part?

The lower-casing has a pretty simple but common reason.  On business
cards the mail address is often written as John.Doe at example.com.  Most
users are not aware of the unspecified handling of case in local-parts
and some will type the name as is other will lower-case the name.
Regardless of that they want to send to the same address.  Fortunately
all mail providers I am aware of ignore the case in the local-part.

Now, if you really want to allow a lookup with a mixed case local-part
(say, due to software which does not do the lower-casing in the
request), it is easy to extract the mail address from the key and create
a symlink or a copy of the key under that hash.

> We believe that your reason for this is compatible and robustness on
> differed file systems. Please describe it, in an short comment in the
> DRAFT, to understand the motivation.

It is already there:

  OpenPGP defines its User IDs, and thus the mail address, as UTF-8
  strings.  To help with the common pattern of using capitalized names
  (e.g. "Joe.Doe at example.org") for mail addresses, and under the premise
  that almost all MTAs treat the "local-part" case-insensitive and [...]

and

  The use of SHA-1 for the mapping of the "local-part" to a fixed string
  is not a security feature but merely used to map the local-part to a
  fixed-sized string made from a well defined set of characters.  It is not
  intended to conceal information about a mail address.


> Q3: Why is in the fixed string an subfolder "hu" (e.g.
> "<https://example.com/.well-known/openpgpkey/hu>")
> * We found the answer on the WKS-Site
> (<https://www.gnupg.org/blog/20160830-web-key-service.html>), but it
> is needed (and when please  describe it in the Draft)?

It is just an identifier to put the keys into a separate directory than
the static information.  It also allows to switch to a newer version of
the protocol by replacing "hu" by another name.

RFCs give rationales only on important topics; most decisions are left
as an exercise for digital archaeologists ;-).


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161104/148abed9/attachment.sig>

From vinay_sajip at yahoo.co.uk  Fri Nov  4 20:14:34 2016
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Fri, 4 Nov 2016 19:14:34 +0000 (UTC)
Subject: Using loopback pin entry with GnuPG 2.1
In-Reply-To: <87twbnwdis.fsf@wheatstone.g10code.de>
References: <574777160.1243146.1476982583037.ref@mail.yahoo.com>
 <574777160.1243146.1476982583037@mail.yahoo.com>
 <878ttegr3s.fsf@wheatstone.g10code.de>
 <868322669.288810.1478254275137@mail.yahoo.com>
 <87twbnwdis.fsf@wheatstone.g10code.de>
Message-ID: <325432173.1102143.1478286874607@mail.yahoo.com>

Dear Werner,

> That is gpg-agent making a connection to itself to see whether its
> socket is still connected to self.  This is done once a minute.

> It seems your gpg is not using that agent.

> You can add "--debug ipc" to gpg to get gpg's site of the communication.

I did that, with no difference. After running my failed tests, I did

$ ps -ef | grep gpg-agent | grep -v grep
vinay     1863  1734  0 19:06 ?        00:00:00 gpg-agent --homedir /home/vinay/.gnupg --use-standard-socket --daemon
vinay     2343  1734 23 19:08 ?        00:00:04 gpg-agent --homedir /home/vinay/projects/python-gnupg/keys --use-standard-socket --daemon
vinay     2368  1734 29 19:08 ?        00:00:04 gpg-agent --homedir /home/vinay/projects/python-gnupg/keys --use-standard-socket --daemon
vinay     2415  1734 43 19:08 ?        00:00:03 gpg-agent --homedir /home/vinay/projects/python-gnupg/keys --use-standard-socket --daemon


Only the first line was present before I ran the tests. After a while, only two lines appear:

$ ps -ef | grep gpg-agent | grep -v grep
vinay     1863  1734  0 19:06 ?        00:00:00 gpg-agent --homedir /home/vinay/.gnupg --use-standard-socket --daemon
vinay     2415  1734  1 19:08 ?        00:00:03 gpg-agent --homedir /home/vinay/projects/python-gnupg/keys --use-standard-socket --daemon


I don't understand what invokes the additional gpg-agent invocations. The watchgnupg program only connects to the first agent (process 1863 above).

I appreciate your help.

Regards,

Vinay Sajip


From wk at gnupg.org  Fri Nov  4 21:14:30 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Nov 2016 21:14:30 +0100
Subject: WKD for separate email hosting?
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C8F@S2008SBS.intern.giepa.de>
 (=?utf-8?Q?=22J=C3=BCrgen_Sch=C3=A4pker=22's?= message of "Fri, 4 Nov 2016
 17:44:36 +0100")
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <201611010902.03549.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B57@S2008SBS.intern.giepa.de>
 <201611021031.37406.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD6@S2008SBS.intern.giepa.de>
 <8760o3w7gy.fsf@wheatstone.g10code.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C8F@S2008SBS.intern.giepa.de>
Message-ID: <87wpgjt32x.fsf_-_@wheatstone.g10code.de>

On Fri,  4 Nov 2016 17:44, Juergen.Schaepker at giepa.de said:

> What about multiple domains handled by a single server?

I don't understand your question?  Running several domains on one IP
address is standard deployment.  SNI works just fine and we do not need
to care about outdated OSes which are not able to handle them.  All TLS
libraries do SNI.

> Please also see my question on IDN handling. If the complete
> (normalized) email address isn?t used to calculate the hash (on both
> client and server), I think there is no way to determine an
> unambiguous IDN address. ASCII-only lowercasing 

I doubt that anyone will ever be able to get the BS of internationalized
mail addresses and domains right.  That is such a large can of worms
that you better don't open it without asbestos.

Fortunately we can step this aside in the protocol specs.  OpenPGP
requires UTF-8 and thus the protocol uses only UTF-8 and leaves all
IDNing to the MUA.


Shalom-Salam,

   Werner


ps.
I stripped the subject which was modified by strange behaving MUAs to
inserts arbitrary strings like "AW:" instead of the the de-facto standard
"re:" and "was:".
-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161104/7794c5ed/attachment.sig>

From wk at gnupg.org  Fri Nov  4 21:16:16 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Nov 2016 21:16:16 +0100
Subject: AW: AW: WKD lookup (Re: Web Key Service server lookup)
In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C90@S2008SBS.intern.giepa.de>
 (=?utf-8?Q?=22J=C3=BCrgen_Sch=C3=A4pker=22's?= message of "Fri, 4 Nov 2016
 17:51:37 +0100")
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@S2008SBS.intern.giepa.de>
 <201611021045.07973.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@S2008SBS.intern.giepa.de>
 <87a8dfw7mb.fsf@wheatstone.g10code.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C90@S2008SBS.intern.giepa.de>
Message-ID: <87shr7t2zz.fsf@wheatstone.g10code.de>

On Fri,  4 Nov 2016 17:51, Juergen.Schaepker at giepa.de said:

> How exactly is the domain-part supposed to be determined by the WKD server?

Strip everyting up to and including the first '@' from the (UTF_8
encoded) addr-spec.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161104/7d3b32ff/attachment.sig>

From wk at gnupg.org  Fri Nov  4 21:25:45 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 Nov 2016 21:25:45 +0100
Subject: Using loopback pin entry with GnuPG 2.1
In-Reply-To: <325432173.1102143.1478286874607@mail.yahoo.com> (Vinay Sajip's
 message of "Fri, 4 Nov 2016 19:14:34 +0000 (UTC)")
References: <574777160.1243146.1476982583037.ref@mail.yahoo.com>
 <574777160.1243146.1476982583037@mail.yahoo.com>
 <878ttegr3s.fsf@wheatstone.g10code.de>
 <868322669.288810.1478254275137@mail.yahoo.com>
 <87twbnwdis.fsf@wheatstone.g10code.de>
 <325432173.1102143.1478286874607@mail.yahoo.com>
Message-ID: <87ins3t2k6.fsf@wheatstone.g10code.de>

On Fri,  4 Nov 2016 20:14, vinay_sajip at yahoo.co.uk said:

> I did that, with no difference. After running my failed tests, I did

I am sorry, but I do not have enough information what you are doing.  If
you need help, please describe exactly what you are doing (including the
version of the software and the OS).  You might have given that in
another mail, but I can't remember.

> $ ps -ef | grep gpg-agent | grep -v grep

    ps -ef | grep gpg-agen[t]

is easier ;-)  or "pgrep -l gpg-agent" if the pids are sufficient

> I don't understand what invokes the additional gpg-agent
> invocations. The watchgnupg program only connects to the first agent
> (process 1863 above).

The agent connects to the socket watchgnupg is listening on.  All agents
configured to use that socket will be showsn by watchgnupg.  note tah if
you used

  log-file socket://

the used socket depends on the current GNUPGHOME.  To direct all log
messages to a single watchgnupg use something like

  log-file socket:///tmp/S.my-gnupg-log

and run

  watchgnupg --time-only --force /tmp/S.my-gnupg-log


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161104/f6c91abf/attachment.sig>

From vinay_sajip at yahoo.co.uk  Fri Nov  4 23:42:25 2016
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Fri, 4 Nov 2016 22:42:25 +0000 (UTC)
Subject: Using loopback pin entry with GnuPG 2.1
In-Reply-To: <87ins3t2k6.fsf@wheatstone.g10code.de>
References: <574777160.1243146.1476982583037.ref@mail.yahoo.com>
 <574777160.1243146.1476982583037@mail.yahoo.com>
 <878ttegr3s.fsf@wheatstone.g10code.de>
 <868322669.288810.1478254275137@mail.yahoo.com>
 <87twbnwdis.fsf@wheatstone.g10code.de>
 <325432173.1102143.1478286874607@mail.yahoo.com>
 <87ins3t2k6.fsf@wheatstone.g10code.de>
Message-ID: <543274049.1230443.1478299346005@mail.yahoo.com>

Dear Werner,

> I am sorry, but I do not have enough information what you are doing.  If
> you need help, please describe exactly what you are doing (including the
> version of the software and the OS).  You might have given that in
> another mail, but I can't remember.

I am running on Ubuntu 16.04.1 (x86_64) with gpg 1.4.20 and gpg 2.1.11 installed using the distro package manager.

My ~/.gnupg/gpg-agent.conf is:

allow-loopback-pinentry
log-file socket:///tmp/S.my-gnupg-log
verbose
debug ipc

Just after reboot, there is only one agent running:


$ ps -ef | grep gpg-agen[t]
vinay     1836  1710  0 22:11 ?        00:00:00 gpg-agent --homedir /home/vinay/.gnupg --use-standard-socket --daemon

and watchgnupg connects to it:


$ watchgnupg --time-only --force /tmp/S.my-gnupg-log
[client at fd 4 connected (local)]
4 - 22:13:12 gpg-agent[1836]: handler 0x7efca342e700 for fd 5 started
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 -> OK Pleased to meet you, process 1836
4 - 22:13:12 gpg-agent[1836]: DBG: chan_4 <- OK Pleased to meet you, process 1836
4 - 22:13:12 gpg-agent[1836]: DBG: chan_4 -> GETINFO pid
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 <- GETINFO pid
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 -> D 1836
4 - 22:13:12 gpg-agent[1836]: DBG: chan_4 <- D 1836
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 -> OK
4 - 22:13:12 gpg-agent[1836]: DBG: chan_4 <- OK
4 - 22:13:12 gpg-agent[1836]: DBG: chan_4 -> BYE
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 <- BYE
4 - 22:13:12 gpg-agent[1836]: DBG: chan_5 -> OK closing connection
4 - 22:13:12 gpg-agent[1836]: handler 0x7efca342e700 for fd 5 terminated


Then I run a single test, which fails. After it, there are two agents:

$ ps -ef | grep gpg-agen[t]
vinay     1836  1710  0 22:11 ?        00:00:00 gpg-agent --homedir /home/vinay/.gnupg --use-standard-socket --daemon
vinay     2373  1710 48 22:12 ?        00:00:03 gpg-agent --homedir /home/vinay/projects/python-gnupg/keys --use-standard-socket --daemon


I have placed a copy of ~/.gnupg/gpg-agent.conf in /home/vinay/projects/python-gnupg/keys/gpg-agent.conf.

However, the watchgnupg output shows no reference to PID 2373, only the once-a-minute check with PID 1836.

The test creates two keys and encrypts and decrypts some data, and verifies that the decryption result matches what was encrypted. The test fails at the decryption stage, the relevant excerpt from the test log is as follows:

MainThread gpg2 --pinentry-mode loopback --status-fd 2 --no-tty --debug ipc --homedir /home/vinay/projects/python-gnupg/keys --batch --passphrase-fd 0 --debug-quick-random --decrypt
MainThread Wrote passphrase
MainThread data copier: <Thread(Thread-12, initial daemon)>, <_io.BytesIO object at 0x7f8d51b40410>, <open file '<fdopen>', mode 'wb' at 0x7f8d5207c9c0>
MainThread stderr reader: <Thread(Thread-13, initial daemon)>
Thread-12  closed output, 896 bytes sent
MainThread stdout reader: <Thread(Thread-14, initial daemon)>
Thread-13  gpg: Note: no default option file '/home/vinay/projects/python-gnupg/keys/gpg.conf'
Thread-13  gpg: enabled debug flags: ipc
Thread-13  [GNUPG:] ENC_TO 195194AD659FA047 16 0
Thread-13  gpg: DBG: chan_5 <- OK Pleased to meet you, process 2384
Thread-13  gpg: DBG: connection to agent established
Thread-13  gpg: DBG: chan_5 -> RESET
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> OPTION ttytype=xterm-256color
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> OPTION display=:0
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> OPTION xauthority=/home/vinay/.Xauthority
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> OPTION putenv=XMODIFIERS=@im=ibus
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> OPTION putenv=GTK_IM_MODULE=ibus
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-qFEK77X1S3
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> OPTION putenv=QT_IM_MODULE=ibus
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> GETINFO version
Thread-13  gpg: DBG: chan_5 <- D 2.1.11
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> OPTION allow-pinentry-notify
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> OPTION agent-awareness=2.1.0
Thread-13  gpg: DBG: chan_5 <- OK
Thread-13  gpg: DBG: chan_5 -> OPTION pinentry-mode=loopback
Thread-13  gpg: DBG: chan_5 <- ERR 67108924 Not supported <GPG Agent>
Thread-13  gpg: setting pinentry mode 'loopback' failed: Not supported
Thread-13  [GNUPG:] ERROR set_pinentry_mode 67108924
Thread-13  gpg: DBG: chan_5 -> AGENT_ID
Thread-13  gpg: DBG: chan_5 <- ERR 67109139 Unknown IPC command <GPG Agent>
Thread-13  gpg: encrypted with 2048-bit ELG key, ID 659FA047, created 2016-11-04
Thread-13        "Barbara Brown (A test user (insecure!)) <barbara.brown at beta.com>"
Thread-13  [GNUPG:] NO_SECKEY 195194AD659FA047
Thread-13  [GNUPG:] BEGIN_DECRYPTION
Thread-13  [GNUPG:] DECRYPTION_FAILED
Thread-13  gpg: decryption failed: No secret key
Thread-13  [GNUPG:] END_DECRYPTION


In the above: the MainThread invokes gpg2 and writes the passphrase, Thread-12 writes the data to be decrypted to gpg2's stdin, and Thread-13 reads gpg2's stderr.

Does the above shed any additional light on what's going on? The identical test code works fine with gpg 1.4.20.

Regards,

Vinay Sajip


From kristian.fiskerstrand at sumptuouscapital.com  Fri Nov  4 23:52:07 2016
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Fri, 4 Nov 2016 23:52:07 +0100
Subject: CRL checking in dirmngr (Was: Re: [PATCH 2/3] dirmngr: add system CAs
 if no hkp-cacert is given)
In-Reply-To: <878tt4a8vc.fsf@alice.fifthhorseman.net>
References: <20161027223059.31844-1-dkg@fifthhorseman.net>
 <20161027223059.31844-2-dkg@fifthhorseman.net>
 <b636f245-c43b-2b48-c16d-48b4635fad59@sumptuouscapital.com>
 <878tt4a8vc.fsf@alice.fifthhorseman.net>
Message-ID: <7f0c2984-9587-8382-ab61-543771f11cb8@sumptuouscapital.com>

On 10/31/2016 03:30 PM, Daniel Kahn Gillmor wrote:
> On Thu 2016-10-27 18:59:03 -0400, Kristian Fiskerstrand wrote:
>> On 10/28/2016 12:30 AM, Daniel Kahn Gillmor wrote:
>>> * dirmngr/dirmngr.c (http_session_new): if the user isn't talking to
>>>   the HKPS pool, and they have not specified any hkp-cacert, then we
>>>   should default to the system CAs, rather than nothing.
>>> * doc/dirmngr.texi: document choice of CAs.
>>
>> I'm a bit ambiguous about this change. In Gentoo we currently have the
>> use of a system CA behind a user-selectable use flag for hkps but even
>> so the set of provided CAs is originating mostly from Mozilla.
>>
>> As seen with the latest WoSign / StartCom issues, mozilla is not overly
>> concerned about third-party usage of the provided CA certificates, and
>> have more complex restrictions in place for NSS (e.g specific
>> notBeforeDate and OneCRL checking).

Since dirmngr already has CRL checking capabilities, at least OneCRL
checking is likely a good idea to implement. I'd also be nice if CRL is
checked for specific CA, e.g in the case of
https://sks-keyservers.net/ca/crl.pem for hkps.pool.sks-keyservers.net


-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Nosce te ipsum!
Know thyself!

-------------- 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/20161104/81bde0c2/attachment.sig>

From dkg at fifthhorseman.net  Fri Nov  4 23:57:47 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  4 Nov 2016 18:57:47 -0400
Subject: [PINENTRY PATCH 3/8] tty: Report timeout.
In-Reply-To: <20161104225752.29980-1-dkg@fifthhorseman.net>
References: <20161104225752.29980-1-dkg@fifthhorseman.net>
Message-ID: <20161104225752.29980-4-dkg@fifthhorseman.net>

* tty/pinentry-tty.c (confirm): Report if canceled due to timeout.
(password): Report if canceled due to timeout.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 tty/pinentry-tty.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/tty/pinentry-tty.c b/tty/pinentry-tty.c
index cef6947..183b7a5 100644
--- a/tty/pinentry-tty.c
+++ b/tty/pinentry-tty.c
@@ -37,6 +37,7 @@
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <ctype.h>
+#include <gpg-error.h>
 
 #include "pinentry.h"
 #include "memory.h"
@@ -283,6 +284,11 @@ confirm (pinentry_t pinentry, FILE *ttyfi, FILE *ttyfo)
         }
     }
 
+#ifndef HAVE_DOSISH_SYSTEM
+  if (timed_out)
+    pinentry->specific_err = gpg_error (GPG_ERR_TIMEOUT);
+#endif
+
   tcsetattr (fileno(ttyfi), TCSANOW, &o_term);
 
   return ret;
@@ -447,6 +453,11 @@ password (pinentry_t pinentry, FILE *ttyfi, FILE *ttyfo)
 	secmem_free (passphrase);
     }
 
+#ifndef HAVE_DOSISH_SYSTEM
+  if (timed_out)
+    pinentry->specific_err = gpg_error (GPG_ERR_TIMEOUT);
+#endif
+
   return done;
 }
 
-- 
2.10.1



From dkg at fifthhorseman.net  Fri Nov  4 23:57:51 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  4 Nov 2016 18:57:51 -0400
Subject: [PINENTRY PATCH 7/8] gnome3: Convert password/confirmation to
 asynchronous model.
In-Reply-To: <20161104225752.29980-1-dkg@fifthhorseman.net>
References: <20161104225752.29980-1-dkg@fifthhorseman.net>
Message-ID: <20161104225752.29980-8-dkg@fifthhorseman.net>

* gnome3/pinentry-gnome3.c (gnome3_cmd_handler): Convert main part of
password or confirmation fetching into asynchronous code by moving
completion into...
(_gcr_prompt_password_done): ... here and...
(_gcr_prompt_confirm_done): ... here.

--

The async programming interface to gcr is necessary if we want to be
able to enforce a timeout, which will happen in the next patch in this
series.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 gnome3/pinentry-gnome3.c | 98 ++++++++++++++++++++++++++++++++++++------------
 1 file changed, 73 insertions(+), 25 deletions(-)

diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index 40be2a4..06c2076 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -69,6 +69,19 @@ pinentry_utf8_validate (gchar *text)
   return result;
 }
 
+struct _gnome3_run {
+  pinentry_t pinentry;
+  GcrPrompt *prompt;
+  GMainLoop *main_loop;
+  int ret;
+};
+
+static void
+_gcr_prompt_password_done (GObject *source_object, GAsyncResult *res, gpointer user_data);
+
+static void
+_gcr_prompt_confirm_done (GObject *source_object, GAsyncResult *res, gpointer user_data);
+
 static void
 _propagate_g_error_to_pinentry (pinentry_t pe, GError *error, gpg_err_code_t code, const char *loc)
 {
@@ -181,26 +194,55 @@ create_prompt (pinentry_t pe, int confirm)
 static int
 gnome3_cmd_handler (pinentry_t pe)
 {
-  GcrPrompt *prompt = NULL;
-  GError *error = NULL;
-  int ret = -1;
+  struct _gnome3_run state;
 
-  if (pe->pin)
-    /* Passphrase mode.  */
+  state.main_loop = g_main_loop_new (NULL, FALSE);
+  if (!state.main_loop)
     {
-      const char *password;
-
-      prompt = create_prompt (pe, 0);
-      if (! prompt)
-	/* Something went wrong.  */
+      pe->specific_err_info = strdup ("Failed to create GMainLoop");
+      pe->specific_err = gpg_error (GPG_ERR_PIN_ENTRY);
+      pe->specific_err_loc = "g_main_loop_new";
+      pe->canceled = 1;
+      return -1;
+    }      
+  state.pinentry = pe;
+  state.ret = 0;
+  state.prompt = create_prompt (pe, !!(pe->pin));
+  if (!state.prompt)
 	{
 	  pe->canceled = 1;
 	  return -1;
 	}
+  if (pe->pin)
+    gcr_prompt_password_async (state.prompt, NULL, _gcr_prompt_password_done, &state);
+  else
+    gcr_prompt_confirm_async (state.prompt, NULL, _gcr_prompt_confirm_done, &state);
+
+  g_main_loop_run (state.main_loop);
+
+  /* clean up state: */
+  g_clear_object (&state.prompt);
+  g_main_loop_unref (state.main_loop);
+  return state.ret;
+};
+
+
+static void
+_gcr_prompt_password_done (GObject *source_object, GAsyncResult *res, gpointer user_data)
+{
+  struct _gnome3_run *state = (struct _gnome3_run *) user_data;
+  GcrPrompt *prompt = GCR_PROMPT (source_object);
+  
+  if (state && prompt && state->prompt == prompt)
+    {
+      const char *password;
+      GError *error = NULL;
+      pinentry_t pe = state->pinentry;
+      int ret = -1;
 
       /* "The returned password is valid until the next time a method
 	 is called to display another prompt."  */
-      password = gcr_prompt_password (prompt, NULL, &error);
+      password = gcr_prompt_password_finish (prompt, res, &error);
       if (error)
 	/* Error.  */
 	{
@@ -228,23 +270,29 @@ gnome3_cmd_handler (pinentry_t pe)
 
 	  ret = 1;
 	}
+      state->ret = ret;
     }
-  else
-    /* Message box mode.  */
-    {
-      GcrPromptReply reply;
 
-      prompt = create_prompt (pe, 1);
-      if (! prompt)
-	/* Something went wrong.  */
+  if (state)
+    g_main_loop_quit (state->main_loop);
+}
+
+static void
+_gcr_prompt_confirm_done (GObject *source_object, GAsyncResult *res, gpointer user_data)
+{
+  struct _gnome3_run *state = (struct _gnome3_run *) user_data;
+  GcrPrompt *prompt = GCR_PROMPT (source_object);
+
+  if (state && prompt && state->prompt == prompt)
 	{
-	  pe->canceled = 1;
-	  return -1;
-	}
+      GcrPromptReply reply;
+      GError *error = NULL;
+      pinentry_t pe = state->pinentry;
+      int ret = -1;
 
       /* XXX: We don't support a third button!  */
 
-      reply = gcr_prompt_confirm_run (prompt, NULL, &error);
+      reply = gcr_prompt_confirm_finish (prompt, res, &error);
       if (error)
 	{
           _propagate_g_error_to_pinentry (state->pinentry, error, GPG_ERR_PIN_ENTRY,
@@ -263,11 +311,11 @@ gnome3_cmd_handler (pinentry_t pe)
 	  pe->canceled = 1;
 	  ret = 0;
 	}
+      state->ret = ret;
     }
 
-  if (prompt)
-    g_clear_object (&prompt);
-  return ret;
+  if (state)
+    g_main_loop_quit (state->main_loop);
 }
 
 pinentry_cmd_handler_t pinentry_cmd_handler = gnome3_cmd_handler;
-- 
2.10.1



From dkg at fifthhorseman.net  Fri Nov  4 23:57:46 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  4 Nov 2016 18:57:46 -0400
Subject: [PINENTRY PATCH 2/8] gnome3: Propagate GError messages to pinentry.
In-Reply-To: <20161104225752.29980-1-dkg@fifthhorseman.net>
References: <20161104225752.29980-1-dkg@fifthhorseman.net>
Message-ID: <20161104225752.29980-3-dkg@fifthhorseman.net>

* gnome3/pinentry-gnome3.c (_propagate_g_error_to_pinentry): New. Send
GError messages back out to pinentry error reporting.
(create_prompt): Use _propagate_g_error_to_pinentry on error.
(gnome3_cmd_handler): Use _propagate_g_error_to_pinentry on error.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 gnome3/pinentry-gnome3.c | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index 1205300..40be2a4 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -69,6 +69,17 @@ pinentry_utf8_validate (gchar *text)
   return result;
 }
 
+static void
+_propagate_g_error_to_pinentry (pinentry_t pe, GError *error, gpg_err_code_t code, const char *loc)
+{
+  size_t infolen = strlen(error->message) + 20;
+  pe->specific_err = gpg_error (code);
+  pe->specific_err_info = malloc (infolen);
+  pe->specific_err_info[infolen-1] = '\0';
+  snprintf (pe->specific_err_info, infolen, "%d: %s", error->code, error->message);
+  pe->specific_err_loc = loc;
+}
+
 static GcrPrompt *
 create_prompt (pinentry_t pe, int confirm)
 {
@@ -81,11 +92,8 @@ create_prompt (pinentry_t pe, int confirm)
   prompt = GCR_PROMPT (gcr_system_prompt_open (-1, NULL, &error));
   if (! prompt)
     {
-      fprintf (stderr, "couldn't create prompt for gnupg passphrase: %s\n",
-               error->message);
-      pe->specific_err_loc = "gcr_prompt";
-      pe->specific_err_info = strdup (error->message);
-      pe->specific_err = gpg_error (GPG_ERR_CONFIGURATION);
+      _propagate_g_error_to_pinentry (pe, error, GPG_ERR_CONFIGURATION,
+                                      "gcr_system_prompt_open");
       g_error_free (error);
       return NULL;
     }
@@ -196,7 +204,8 @@ gnome3_cmd_handler (pinentry_t pe)
       if (error)
 	/* Error.  */
 	{
-	  pe->specific_err = gpg_error (GPG_ERR_ASS_GENERAL);
+          _propagate_g_error_to_pinentry (state->pinentry, error, GPG_ERR_PIN_ENTRY,
+                                          "gcr_system_password_finish");
 	  g_error_free (error);
 	  ret = -1;
 	}
@@ -238,7 +247,8 @@ gnome3_cmd_handler (pinentry_t pe)
       reply = gcr_prompt_confirm_run (prompt, NULL, &error);
       if (error)
 	{
-	  pe->specific_err = gpg_error (GPG_ERR_ASS_GENERAL);
+          _propagate_g_error_to_pinentry (state->pinentry, error, GPG_ERR_PIN_ENTRY,
+                                          "gcr_system_confirm_finish");
 	  ret = 0;
 	}
       else if (reply == GCR_PROMPT_REPLY_CONTINUE
-- 
2.10.1



From dkg at fifthhorseman.net  Fri Nov  4 23:57:45 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  4 Nov 2016 18:57:45 -0400
Subject: [PINENTRY PATCH 1/8] gnome3: Set parent window.
In-Reply-To: <20161104225752.29980-1-dkg@fifthhorseman.net>
References: <20161104225752.29980-1-dkg@fifthhorseman.net>
Message-ID: <20161104225752.29980-2-dkg@fifthhorseman.net>

* gnome3/pinentry-gnome3.c (create_prompt): Tell Gcr about the caller
window, if we know it.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 gnome3/pinentry-gnome3.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index 90ff60f..1205300 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -75,6 +75,7 @@ create_prompt (pinentry_t pe, int confirm)
   GcrPrompt *prompt;
   GError *error = NULL;
   char *msg;
+  char window_id[32];
 
   /* Create the prompt.  */
   prompt = GCR_PROMPT (gcr_system_prompt_open (-1, NULL, &error));
@@ -145,8 +146,11 @@ create_prompt (pinentry_t pe, int confirm)
       /* XXX: Add support for the third option.  */
     }
 
-  /* XXX: gcr expects a string; we have a int.  */
-  // gcr_prompt_set_caller_window (prompt, pe->parent_wid);
+  /* gcr expects a string; we have a int.  see gcr's
+     ui/frob-system-prompt.c for example conversion using %lu */
+  snprintf(window_id, sizeof (window_id), "%lu", (long unsigned int)pe->parent_wid);
+  window_id[sizeof (window_id) - 1] = '\0';
+  gcr_prompt_set_caller_window (prompt, window_id);
 
 #ifdef HAVE_LIBSECRET
   if (! confirm && pe->allow_external_password_cache && pe->keyinfo)
-- 
2.10.1



From dkg at fifthhorseman.net  Fri Nov  4 23:57:52 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  4 Nov 2016 18:57:52 -0400
Subject: [PINENTRY PATCH 8/8] gnome3: Honor timeout.
In-Reply-To: <20161104225752.29980-1-dkg@fifthhorseman.net>
References: <20161104225752.29980-1-dkg@fifthhorseman.net>
Message-ID: <20161104225752.29980-9-dkg@fifthhorseman.net>

* gnome3/pinentry-gnome3.c (create_prompt): Use timeout to determine
how long to wait for Gcr to provide a system prompt before giving up.
(_gcr_timeout_done): New.  Record that a timeout has elapsed.
(gnome3_cmd_handler): Set up a timeout before launching the prompt,
and tear it down afterward.
(_gcr_prompt_password_done): Report timeout differently from normal
cancellation.
(_gcr_prompt_confirm_done): Report timeout differently from normal
cancellation.

--

Without this change, pinentry-gnome3 does not respect the timeout
parameter at all, and can hang indefinitely in the event that the
system prompter is locked or the user is ignoring the session.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 gnome3/pinentry-gnome3.c | 75 +++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 65 insertions(+), 10 deletions(-)

diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index 06c2076..148ef65 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -74,6 +74,8 @@ struct _gnome3_run {
   GcrPrompt *prompt;
   GMainLoop *main_loop;
   int ret;
+  guint timeout_id;
+  int timed_out;
 };
 
 static void
@@ -82,6 +84,9 @@ _gcr_prompt_password_done (GObject *source_object, GAsyncResult *res, gpointer u
 static void
 _gcr_prompt_confirm_done (GObject *source_object, GAsyncResult *res, gpointer user_data);
 
+static gboolean
+_gcr_timeout_done (gpointer user_data);
+
 static void
 _propagate_g_error_to_pinentry (pinentry_t pe, GError *error, gpg_err_code_t code, const char *loc)
 {
@@ -102,11 +107,25 @@ create_prompt (pinentry_t pe, int confirm)
   char window_id[32];
 
   /* Create the prompt.  */
-  prompt = GCR_PROMPT (gcr_system_prompt_open (-1, NULL, &error));
+  prompt = GCR_PROMPT (gcr_system_prompt_open (pe->timeout ? pe->timeout : -1, NULL, &error));
   if (! prompt)
     {
-      _propagate_g_error_to_pinentry (pe, error, GPG_ERR_CONFIGURATION,
-                                      "gcr_system_prompt_open");
+      /* this means the timeout elapsed, but no prompt was ever shown. */
+      if (error->code == GCR_SYSTEM_PROMPT_IN_PROGRESS)
+        { 
+          fprintf (stderr, "Timeout: the Gcr system prompter was already in use.\n");
+          pe->specific_err_info = strdup ("Timeout: the Gcr system prompter was already in use.");
+          /* not using GPG_ERR_TIMEOUT here because the user never saw
+             a prompt: */
+          pe->specific_err = gpg_error (GPG_ERR_PIN_ENTRY);
+        }
+      else
+        {
+          fprintf (stderr, "couldn't create prompt for gnupg passphrase: %s\n",
+                   error->message);
+          _propagate_g_error_to_pinentry (pe, error, GPG_ERR_CONFIGURATION,
+                                          "gcr_system_prompt_open");
+        }
       g_error_free (error);
       return NULL;
     }
@@ -207,6 +226,8 @@ gnome3_cmd_handler (pinentry_t pe)
     }      
   state.pinentry = pe;
   state.ret = 0;
+  state.timeout_id = 0;
+  state.timed_out = 0;
   state.prompt = create_prompt (pe, !!(pe->pin));
   if (!state.prompt)
 	{
@@ -218,9 +239,13 @@ gnome3_cmd_handler (pinentry_t pe)
   else
     gcr_prompt_confirm_async (state.prompt, NULL, _gcr_prompt_confirm_done, &state);
 
+  if (pe->timeout)
+    state.timeout_id = g_timeout_add_seconds (pe->timeout, _gcr_timeout_done, &state);
   g_main_loop_run (state.main_loop);
 
   /* clean up state: */
+  if (state.timeout_id && !state.timed_out)
+    g_source_destroy (g_main_context_find_source_by_id (NULL, state.timeout_id));
   g_clear_object (&state.prompt);
   g_main_loop_unref (state.main_loop);
   return state.ret;
@@ -243,17 +268,23 @@ _gcr_prompt_password_done (GObject *source_object, GAsyncResult *res, gpointer u
       /* "The returned password is valid until the next time a method
 	 is called to display another prompt."  */
       password = gcr_prompt_password_finish (prompt, res, &error);
-      if (error)
-	/* Error.  */
+      if ((! password && ! error) ||
+          (error && error->code == G_IO_ERROR_CANCELLED))
+        {
+          /* operation was cancelled or timed out.  */
+          ret = -1;
+          if (state->timed_out)
+            state->pinentry->specific_err = gpg_error (GPG_ERR_TIMEOUT);
+          if (error)
+            g_error_free (error);
+        }
+      else if (error)
 	{
           _propagate_g_error_to_pinentry (state->pinentry, error, GPG_ERR_PIN_ENTRY,
                                           "gcr_system_password_finish");
 	  g_error_free (error);
 	  ret = -1;
 	}
-      else if (! password && ! error)
-	/* User cancelled the operation.  */
-	ret = -1;
       else
 	{
 	  pinentry_setbufferlen (pe, strlen (password) + 1);
@@ -295,8 +326,16 @@ _gcr_prompt_confirm_done (GObject *source_object, GAsyncResult *res, gpointer us
       reply = gcr_prompt_confirm_finish (prompt, res, &error);
       if (error)
 	{
-          _propagate_g_error_to_pinentry (state->pinentry, error, GPG_ERR_PIN_ENTRY,
-                                          "gcr_system_confirm_finish");
+          if (error->code == G_IO_ERROR_CANCELLED)
+            {
+              pe->canceled = 1;
+              if (state->timed_out)
+                state->pinentry->specific_err = gpg_error (GPG_ERR_TIMEOUT);
+            }
+          else
+            _propagate_g_error_to_pinentry (state->pinentry, error, GPG_ERR_PIN_ENTRY,
+                                            "gcr_system_confirm_finish");
+	  g_error_free (error);
 	  ret = 0;
 	}
       else if (reply == GCR_PROMPT_REPLY_CONTINUE
@@ -309,6 +348,8 @@ _gcr_prompt_confirm_done (GObject *source_object, GAsyncResult *res, gpointer us
 	/* GCR_PROMPT_REPLY_CANCEL */
 	{
 	  pe->canceled = 1;
+          if (state->timed_out)
+            state->pinentry->specific_err = gpg_error (GPG_ERR_TIMEOUT);
 	  ret = 0;
 	}
       state->ret = ret;
@@ -318,6 +359,20 @@ _gcr_prompt_confirm_done (GObject *source_object, GAsyncResult *res, gpointer us
     g_main_loop_quit (state->main_loop);
 }
 
+static gboolean
+_gcr_timeout_done (gpointer user_data)
+{
+  struct _gnome3_run *state = (struct _gnome3_run *) user_data;
+
+  if (!state)
+    return FALSE;
+
+  state->timed_out = 1;
+  gcr_prompt_close (state->prompt);
+
+  return FALSE;
+}
+
 pinentry_cmd_handler_t pinentry_cmd_handler = gnome3_cmd_handler;
 
 int
-- 
2.10.1



From dkg at fifthhorseman.net  Fri Nov  4 23:57:44 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  4 Nov 2016 18:57:44 -0400
Subject: Pinentry error reporting and timeout cleanup
Message-ID: <20161104225752.29980-1-dkg@fifthhorseman.net>

Very few of the current pinentry implementations report timeouts as
timeouts.  Some of them (gnome3 in particular) do not even respect the
timeout parameter at all.

This patch series cleans up and improves pinentry error reporting, and
ensures that all pinentries respecting the timeout parameter.



From dkg at fifthhorseman.net  Fri Nov  4 23:57:48 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  4 Nov 2016 18:57:48 -0400
Subject: [PINENTRY PATCH 4/8] gtk2: Report timeout.
In-Reply-To: <20161104225752.29980-1-dkg@fifthhorseman.net>
References: <20161104225752.29980-1-dkg@fifthhorseman.net>
Message-ID: <20161104225752.29980-5-dkg@fifthhorseman.net>

* gtk+-2/pinentry-gtk-2.c (create_window): Send pointer to pinentry
into timeout_cb.
(timeout_cb): Report if canceled due to timeout.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 gtk+-2/pinentry-gtk-2.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/gtk+-2/pinentry-gtk-2.c b/gtk+-2/pinentry-gtk-2.c
index cd6270f..544e595 100644
--- a/gtk+-2/pinentry-gtk-2.c
+++ b/gtk+-2/pinentry-gtk-2.c
@@ -38,6 +38,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#include <gpg-error.h>
 
 #ifdef HAVE_GETOPT_H
 #include <getopt.h>
@@ -515,9 +516,13 @@ show_hide_button_toggled (GtkWidget *widget, gpointer data)
 static gboolean
 timeout_cb (gpointer data)
 {
-  (void)data;
+  pinentry_t pinentry = (pinentry_t)data;
   if (!got_input)
-    gtk_main_quit ();
+    {
+      gtk_main_quit ();
+      if (pinentry)
+        pinentry->specific_err = gpg_error (GPG_ERR_TIMEOUT);
+    }
 
   /* Don't run again.  */
   timeout_source = 0;
@@ -873,7 +878,7 @@ create_window (pinentry_t ctx)
   gtk_window_present (GTK_WINDOW (win));  /* Make sure it has the focus.  */
 
   if (pinentry->timeout > 0)
-    timeout_source = g_timeout_add (pinentry->timeout*1000, timeout_cb, NULL);
+    timeout_source = g_timeout_add (pinentry->timeout*1000, timeout_cb, pinentry);
 
   return win;
 }
-- 
2.10.1



From dkg at fifthhorseman.net  Fri Nov  4 23:57:49 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  4 Nov 2016 18:57:49 -0400
Subject: [PINENTRY PATCH 5/8] curses: Report timeout.
In-Reply-To: <20161104225752.29980-1-dkg@fifthhorseman.net>
References: <20161104225752.29980-1-dkg@fifthhorseman.net>
Message-ID: <20161104225752.29980-6-dkg@fifthhorseman.net>

* pinentry/pinentry-curses.c (dialog_run): Report if canceled due to
timeout.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 pinentry/pinentry-curses.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c
index 9882cbf..a6dbb69 100644
--- a/pinentry/pinentry-curses.c
+++ b/pinentry/pinentry-curses.c
@@ -941,6 +941,7 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type)
       if (timed_out && no_input)
 	{
 	  done = -2;
+          pinentry->specific_err = gpg_error (GPG_ERR_TIMEOUT);
 	  break;
 	}
 #endif
-- 
2.10.1



From dkg at fifthhorseman.net  Fri Nov  4 23:57:50 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri,  4 Nov 2016 18:57:50 -0400
Subject: [PINENTRY PATCH 6/8] qt: Report timeout.
In-Reply-To: <20161104225752.29980-1-dkg@fifthhorseman.net>
References: <20161104225752.29980-1-dkg@fifthhorseman.net>
Message-ID: <20161104225752.29980-7-dkg@fifthhorseman.net>

* qt/pinentryconfirm.h (PinentryConfirm): Add _timed_out, timedOut().
* qt/pinentrydialog.h (PinentryDialog): Add _timed_out, timedOut().
* qt/pinentryconfirm.cpp (slotTimeout): Record elapsed timeout.
(PinentryConfirm): Initialize _timed_out to false.
(timedOut): New. Returns value of _timed_out.
* qt/pinentryDialog.cpp (slotTimeout): Record elapsed timeout.
(PinentryDialog): Initialize _timed_out to false.
(timedOut): New. Returns value of _timed_out.
* qt/main.cpp (qt_cmd_handler): Report if canceled due to timeout.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 qt/main.cpp            | 6 ++++++
 qt/pinentryconfirm.cpp | 7 +++++++
 qt/pinentryconfirm.h   | 2 ++
 qt/pinentrydialog.cpp  | 7 +++++++
 qt/pinentrydialog.h    | 3 +++
 5 files changed, 25 insertions(+)

diff --git a/qt/main.cpp b/qt/main.cpp
index d5da4a8..8284960 100644
--- a/qt/main.cpp
+++ b/qt/main.cpp
@@ -44,6 +44,7 @@
 
 #include <memory>
 #include <stdexcept>
+#include <gpg-error.h>
 
 #ifdef FALLBACK_CURSES
 #include <pinentry-curses.h>
@@ -205,6 +206,8 @@ qt_cmd_handler(pinentry_t pe)
         }
         bool ret = pinentry.exec();
         if (!ret) {
+            if (pinentry.timedOut())
+                pe->specific_err = gpg_error (GPG_ERR_TIMEOUT);
             return -1;
         }
 
@@ -270,6 +273,9 @@ qt_cmd_handler(pinentry_t pe)
         if (rc == QMessageBox::Cancel) {
             pe->canceled = true;
         }
+        if (box.timedOut()) {
+          pe->specific_err = gpg_error (GPG_ERR_TIMEOUT);
+        }
 
         return rc == QMessageBox::Ok || rc == QMessageBox::Yes ;
 
diff --git a/qt/pinentryconfirm.cpp b/qt/pinentryconfirm.cpp
index e81b188..8b59d9d 100644
--- a/qt/pinentryconfirm.cpp
+++ b/qt/pinentryconfirm.cpp
@@ -24,6 +24,7 @@ PinentryConfirm::PinentryConfirm(Icon icon, int timeout, const QString &title,
                                  const QString &desc, StandardButtons buttons, QWidget *parent) :
     QMessageBox(icon, title, desc, buttons, parent)
 {
+    _timed_out = false;
     if (timeout > 0) {
         _timer = new QTimer(this);
         connect(_timer, SIGNAL(timeout()), this, SLOT(slotTimeout()));
@@ -36,6 +37,11 @@ PinentryConfirm::PinentryConfirm(Icon icon, int timeout, const QString &title,
     raiseWindow(this);
 }
 
+bool PinentryConfirm::timedOut() const
+{
+    return _timed_out;
+}
+
 void PinentryConfirm::showEvent(QShowEvent *event)
 {
     QDialog::showEvent(event);
@@ -45,6 +51,7 @@ void PinentryConfirm::showEvent(QShowEvent *event)
 void PinentryConfirm::slotTimeout()
 {
     QAbstractButton *b = button(QMessageBox::Cancel);
+    _timed_out = true;
 
     if (b) {
         b->animateClick(0);
diff --git a/qt/pinentryconfirm.h b/qt/pinentryconfirm.h
index 23e05dc..21b91c5 100644
--- a/qt/pinentryconfirm.h
+++ b/qt/pinentryconfirm.h
@@ -29,12 +29,14 @@ public:
     PinentryConfirm(Icon, int timeout, const QString &title,
                     const QString &desc, StandardButtons buttons,
                     QWidget *parent);
+    bool timedOut() const;
 
 private slots:
     void slotTimeout();
 
 private:
     QTimer *_timer;
+    bool _timed_out;
 
 protected:
     /* reimp */ void showEvent(QShowEvent *event);
diff --git a/qt/pinentrydialog.cpp b/qt/pinentrydialog.cpp
index f9dd700..92cf19e 100644
--- a/qt/pinentrydialog.cpp
+++ b/qt/pinentrydialog.cpp
@@ -121,6 +121,7 @@ QPixmap icon(QStyle::StandardPixmap which)
 
 void PinEntryDialog::slotTimeout()
 {
+    _timed_out = true;
     reject();
 }
 
@@ -137,6 +138,7 @@ PinEntryDialog::PinEntryDialog(QWidget *parent, const char *name,
       mVisiActionEdit(NULL),
       mVisiCB(NULL)
 {
+    _timed_out = false;
     setWindowFlags(windowFlags() & ~Qt::WindowContextHelpButtonHint);
 
     if (modal) {
@@ -463,6 +465,11 @@ QString PinEntryDialog::repeatedPin() const
     return QString();
 }
 
+bool PinEntryDialog::timedOut() const
+{
+    return _timed_out;
+}
+
 void PinEntryDialog::setRepeatErrorText(const QString &err)
 {
     mRepeatError = err;
diff --git a/qt/pinentrydialog.h b/qt/pinentrydialog.h
index c302f95..a996f8e 100644
--- a/qt/pinentrydialog.h
+++ b/qt/pinentrydialog.h
@@ -82,6 +82,8 @@ public:
 
     void setPinentryInfo(pinentry_t);
 
+    bool timedOut() const;
+    
 protected slots:
     void updateQuality(const QString &);
     void slotTimeout();
@@ -105,6 +107,7 @@ private:
     QPushButton *_cancel;
     bool       _grabbed;
     bool       _have_quality_bar;
+    bool       _timed_out;
     pinentry_t _pinentry_info;
     QTimer    *_timer;
     QString    mRepeatError,
-- 
2.10.1



From dkg at fifthhorseman.net  Sat Nov  5 05:25:12 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat,  5 Nov 2016 00:25:12 -0400
Subject: [PINENTRY PATCH] all: Prefer https:// over http:// in source where
 possible.
Message-ID: <20161105042512.12147-1-dkg@fifthhorseman.net>

This change cleans up as many internal web references as possible, to
make them use https.  In some cases, the canonical references had
slightly different URLs in addition to the change in schema.

Sadly, git.savannah.gnu.org is still http-only.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 README                        |  2 +-
 autogen.sh                    |  2 +-
 build-aux/compile             |  2 +-
 build-aux/config.guess        |  2 +-
 build-aux/config.sub          |  2 +-
 build-aux/depcomp             |  2 +-
 build-aux/gitlog-to-changelog |  2 +-
 build-aux/mdate-sh            |  2 +-
 build-aux/missing             | 10 +++++-----
 build-aux/texinfo.tex         | 14 +++++++-------
 configure.ac                  |  2 +-
 doc/texinfo.tex               | 14 +++++++-------
 emacs/pinentry-emacs.c        |  2 +-
 gtk+-2/pinentry-gtk-2.c       |  2 +-
 m4/pkg.m4                     |  2 +-
 pinentry/argparse.c           |  8 ++++----
 pinentry/argparse.h           |  2 +-
 pinentry/password-cache.c     |  2 +-
 pinentry/password-cache.h     |  2 +-
 pinentry/pinentry-emacs.c     |  2 +-
 pinentry/pinentry-emacs.h     |  2 +-
 pinentry/pinentry.c           |  2 +-
 pinentry/pinentry.h           |  2 +-
 tty/Makefile.am               |  2 +-
 tty/pinentry-tty.c            |  2 +-
 25 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/README b/README
index b80d466..33f0ab4 100644
--- a/README
+++ b/README
@@ -3,7 +3,7 @@ PIN Entry
 
 This is a collection of simple PIN or passphrase entry dialogs which
 utilize the Assuan protocol as described by the aegypten project; see
-http://www.gnupg.org/aegypten/ for details.
+https://www.gnupg.org/aegypten/ for details.
 
 There are programs for different toolkits available.  For all GUIs it
 is automatically detected which modules can be built, but it can also
diff --git a/autogen.sh b/autogen.sh
index 7effd56..37edfc6 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -422,7 +422,7 @@ if [ -d .git ]; then
     [ -z "${SILENT}" ] && cat <<EOF
 *** Activating trailing whitespace git pre-commit hook. ***
     For more information see this thread:
-      http://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00084html
+      https://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00084.html
     To deactivate this pre-commit hook again move .git/hooks/pre-commit
     and .git/hooks/pre-commit.sample out of the way.
 EOF
diff --git a/build-aux/compile b/build-aux/compile
index 531136b..52f8f94 100755
--- a/build-aux/compile
+++ b/build-aux/compile
@@ -17,7 +17,7 @@ scriptversion=2012-10-14.11; # UTC
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/config.guess b/build-aux/config.guess
index dbfb978..7adf147 100755
--- a/build-aux/config.guess
+++ b/build-aux/config.guess
@@ -15,7 +15,7 @@ timestamp='2015-01-01'
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, see <http://www.gnu.org/licenses/>.
+# along with this program; if not, see <https://www.gnu.org/licenses/>.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/config.sub b/build-aux/config.sub
index 6d2e94c..0b2d816 100755
--- a/build-aux/config.sub
+++ b/build-aux/config.sub
@@ -15,7 +15,7 @@ timestamp='2015-01-01'
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, see <http://www.gnu.org/licenses/>.
+# along with this program; if not, see <https://www.gnu.org/licenses/>.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/depcomp b/build-aux/depcomp
index 4ebd5b3..f0a474c 100755
--- a/build-aux/depcomp
+++ b/build-aux/depcomp
@@ -16,7 +16,7 @@ scriptversion=2013-05-30.07; # UTC
 # GNU General Public License for more details.
 
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/gitlog-to-changelog b/build-aux/gitlog-to-changelog
index 5cf071f..81a0431 100755
--- a/build-aux/gitlog-to-changelog
+++ b/build-aux/gitlog-to-changelog
@@ -22,7 +22,7 @@ my $VERSION = '2012-01-24 15:58 (wk)'; # UTC
 # GNU General Public License for more details.
 
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # Written by Jim Meyering
 # Custom bugs bred by Werner Koch
diff --git a/build-aux/mdate-sh b/build-aux/mdate-sh
index b3719cf..39f48bb 100755
--- a/build-aux/mdate-sh
+++ b/build-aux/mdate-sh
@@ -17,7 +17,7 @@ scriptversion=2010-08-21.06; # UTC
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
diff --git a/build-aux/missing b/build-aux/missing
index db98974..528c6c4 100755
--- a/build-aux/missing
+++ b/build-aux/missing
@@ -1,7 +1,7 @@
 #! /bin/sh
 # Common wrapper for a few potentially missing GNU programs.
 
-scriptversion=2013-10-28.13; # UTC
+scriptversion=2016-11-05.04; # UTC
 
 # Copyright (C) 1996-2013 Free Software Foundation, Inc.
 # Originally written by Fran,cois Pinard <pinard at iro.umontreal.ca>, 1996.
@@ -17,7 +17,7 @@ scriptversion=2013-10-28.13; # UTC
 # GNU General Public License for more details.
 
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
@@ -101,9 +101,9 @@ else
   exit $st
 fi
 
-perl_URL=http://www.perl.org/
-flex_URL=http://flex.sourceforge.net/
-gnu_software_URL=http://www.gnu.org/software
+perl_URL=https://www.perl.org/
+flex_URL=https://github.com/westes/flex
+gnu_software_URL=https://www.gnu.org/software
 
 program_details ()
 {
diff --git a/build-aux/texinfo.tex b/build-aux/texinfo.tex
index 5552e50..1e6de89 100644
--- a/build-aux/texinfo.tex
+++ b/build-aux/texinfo.tex
@@ -3,7 +3,7 @@
 % Load plain if necessary, i.e., if running under initex.
 \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
 %
-\def\texinfoversion{2016-11-03.12}
+\def\texinfoversion{2016-11-05.00}
 %
 % Copyright (C) 1985, 1986, 1988, 1990, 1991, 1992, 1993, 1994, 1995,
 % 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
@@ -21,7 +21,7 @@
 %
 % You should have received a copy of the GNU General Public License
 % along with this texinfo.tex file; see the file COPYING.  If not,
-% see <http://www.gnu.org/licenses/>.
+% see <https://www.gnu.org/licenses/>.
 %
 % As a special exception, when this file is read by TeX when processing
 % a Texinfo source document, you may use the result without
@@ -29,9 +29,9 @@
 %
 % Please try the latest version of texinfo.tex before submitting bug
 % reports; you can get the latest version from:
-%   http://www.gnu.org/software/texinfo/ (the Texinfo home page), or
+%   https://www.gnu.org/software/texinfo/ (the Texinfo home page), or
 %   ftp://tug.org/tex/texinfo.tex
-%     (and all CTAN mirrors, see http://www.ctan.org).
+%     (and all CTAN mirrors, see https://www.ctan.org).
 % The texinfo.tex in any given distribution could well be out
 % of date, so if that's what you're using, please check.
 %
@@ -55,7 +55,7 @@
 % extent.  You can get the existing language-specific files from the
 % full Texinfo distribution.
 %
-% The GNU Texinfo home page is http://www.gnu.org/software/texinfo.
+% The GNU Texinfo home page is https://www.gnu.org/software/texinfo.
 
 
 \message{Loading texinfo [version \texinfoversion]:}
@@ -1209,7 +1209,7 @@ where each line of input produces a line of output.}
 % for display in the outlines, and in other places.  Thus, we have to
 % double any backslashes.  Otherwise, a name like "\node" will be
 % interpreted as a newline (\n), followed by o, d, e.  Not good.
-% http://www.ntg.nl/pipermail/ntg-pdftex/2004-July/000654.html
+% https://mailman.ntg.nl/pipermail/ntg-pdftex/2004-July/000654.html
 % (and related messages, the final outcome is that it is up to the TeX
 % user to double the backslashes and otherwise make the string valid, so
 % that's what we do).
@@ -2560,7 +2560,7 @@ end
 % We use the free feym* fonts from the eurosym package by Henrik
 % Theiling, which support regular, slanted, bold and bold slanted (and
 % "outlined" (blackboard board, sort of) versions, which we don't need).
-% It is available from http://www.ctan.org/tex-archive/fonts/eurosym.
+% It is available from https://www.ctan.org/tex-archive/fonts/eurosym.
 %
 % Although only regular is the truly official Euro symbol, we ignore
 % that.  The Euro is designed to be slightly taller than the regular
diff --git a/configure.ac b/configure.ac
index 1620ebd..1dfdf17 100644
--- a/configure.ac
+++ b/configure.ac
@@ -42,7 +42,7 @@ m4_define([mym4_betastring],
 m4_define([mym4_isgit],m4_if(mym4_betastring,[],[no],[yes]))
 m4_define([mym4_full_version],[mym4_version[]mym4_betastring])
 
-AC_INIT([pinentry],[mym4_full_version], [http://bugs.gnupg.org])
+AC_INIT([pinentry],[mym4_full_version], [https://bugs.gnupg.org])
 
 AC_CONFIG_AUX_DIR([build-aux])
 AM_CONFIG_HEADER(config.h)
diff --git a/doc/texinfo.tex b/doc/texinfo.tex
index 919d85d..3f81058 100644
--- a/doc/texinfo.tex
+++ b/doc/texinfo.tex
@@ -3,7 +3,7 @@
 % Load plain if necessary, i.e., if running under initex.
 \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
 %
-\def\texinfoversion{2016-11-03.12}
+\def\texinfoversion{2016-11-05.00}
 %
 % Copyright (C) 1985, 1986, 1988, 1990, 1991, 1992, 1993, 1994, 1995,
 % 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
@@ -21,7 +21,7 @@
 %
 % You should have received a copy of the GNU General Public License
 % along with this texinfo.tex file; see the file COPYING.  If not, 
-% see <http://www.gnu.org/licenses/>.
+% see <https://www.gnu.org/licenses/>.
 %
 % As a special exception, when this file is read by TeX when processing
 % a Texinfo source document, you may use the result without
@@ -29,9 +29,9 @@
 %
 % Please try the latest version of texinfo.tex before submitting bug
 % reports; you can get the latest version from:
-%   http://www.gnu.org/software/texinfo/ (the Texinfo home page), or
+%   https://www.gnu.org/software/texinfo/ (the Texinfo home page), or
 %   ftp://tug.org/tex/texinfo.tex
-%     (and all CTAN mirrors, see http://www.ctan.org).
+%     (and all CTAN mirrors, see https://www.ctan.org).
 % The texinfo.tex in any given distribution could well be out
 % of date, so if that's what you're using, please check.
 %
@@ -55,7 +55,7 @@
 % extent.  You can get the existing language-specific files from the
 % full Texinfo distribution.
 %
-% The GNU Texinfo home page is http://www.gnu.org/software/texinfo.
+% The GNU Texinfo home page is https://www.gnu.org/software/texinfo.
 
 
 \message{Loading texinfo [version \texinfoversion]:}
@@ -1209,7 +1209,7 @@ where each line of input produces a line of output.}
 % for display in the outlines, and in other places.  Thus, we have to
 % double any backslashes.  Otherwise, a name like "\node" will be
 % interpreted as a newline (\n), followed by o, d, e.  Not good.
-% http://www.ntg.nl/pipermail/ntg-pdftex/2004-July/000654.html
+% https://mailman.ntg.nl/pipermail/ntg-pdftex/2004-July/000654.html
 % (and related messages, the final outcome is that it is up to the TeX
 % user to double the backslashes and otherwise make the string valid, so
 % that's what we do).
@@ -2560,7 +2560,7 @@ end
 % We use the free feym* fonts from the eurosym package by Henrik
 % Theiling, which support regular, slanted, bold and bold slanted (and
 % "outlined" (blackboard board, sort of) versions, which we don't need).
-% It is available from http://www.ctan.org/tex-archive/fonts/eurosym.
+% It is available from https://www.ctan.org/tex-archive/fonts/eurosym.
 % 
 % Although only regular is the truly official Euro symbol, we ignore
 % that.  The Euro is designed to be slightly taller than the regular
diff --git a/emacs/pinentry-emacs.c b/emacs/pinentry-emacs.c
index de4ca05..da96985 100644
--- a/emacs/pinentry-emacs.c
+++ b/emacs/pinentry-emacs.c
@@ -14,7 +14,7 @@
    General Public License for more details.
 
    You should have received a copy of the GNU General Public License
-   along with this program; if not, see <http://www.gnu.org/licenses/>.
+   along with this program; if not, see <https://www.gnu.org/licenses/>.
 */
 
 #ifdef HAVE_CONFIG_H
diff --git a/gtk+-2/pinentry-gtk-2.c b/gtk+-2/pinentry-gtk-2.c
index cd6270f..f7ead2a 100644
--- a/gtk+-2/pinentry-gtk-2.c
+++ b/gtk+-2/pinentry-gtk-2.c
@@ -115,7 +115,7 @@ constrain_size (GtkWidget *win, GtkRequisition *req, gpointer data)
 /* Realize the window as transient if we grab the keyboard.  This
    makes the window a modal dialog to the root window, which helps the
    window manager.  See the following quote from:
-   http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2512420
+   https://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2512420
 
    Implementing enhanced support for application transient windows
 
diff --git a/m4/pkg.m4 b/m4/pkg.m4
index e602e5b..5acff96 100644
--- a/m4/pkg.m4
+++ b/m4/pkg.m4
@@ -146,7 +146,7 @@ path to pkg-config.
 
 _PKG_TEXT
 
-To get pkg-config, see <http://pkg-config.freedesktop.org/>.])],
+To get pkg-config, see <https://pkg-config.freedesktop.org/>.])],
 		[$4])
 else
 	$1[]_CFLAGS=$pkg_cv_[]$1[]_CFLAGS
diff --git a/pinentry/argparse.c b/pinentry/argparse.c
index 4f586d4..f6c160c 100644
--- a/pinentry/argparse.c
+++ b/pinentry/argparse.c
@@ -26,7 +26,7 @@
  *
  * You should have received a copies of the GNU General Public License
  * and the GNU Lesser General Public License along with this program;
- * if not, see <http://www.gnu.org/licenses/>.
+ * if not, see <https://www.gnu.org/licenses/>.
  */
 
 /* This file may be used as part of GnuPG or standalone.  A GnuPG
@@ -1490,10 +1490,10 @@ strusage( int level )
     case 10:
 #if ARGPARSE_GPL_VERSION == 3
       p = ("License GPLv3+: GNU GPL version 3 or later "
-           "<http://gnu.org/licenses/gpl.html>");
+           "<https://www.gnu.org/licenses/gpl.html>");
 #else
       p = ("License GPLv2+: GNU GPL version 2 or later "
-           "<http://gnu.org/licenses/>");
+           "<https://www.gnu.org/licenses/>");
 #endif
       break;
     case 11: p = "foo"; break;
@@ -1515,7 +1515,7 @@ ARGPARSE_STR2(ARGPARSE_GPL_VERSION)
 "MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n"
 "GNU General Public License for more details.\n\n"
 "You should have received a copy of the GNU General Public License\n"
-"along with this software.  If not, see <http://www.gnu.org/licenses/>.\n";
+"along with this software.  If not, see <https://www.gnu.org/licenses/>.\n";
       break;
     case 40: /* short and long usage */
     case 41: p = ""; break;
diff --git a/pinentry/argparse.h b/pinentry/argparse.h
index b4dc253..54d9c5b 100644
--- a/pinentry/argparse.h
+++ b/pinentry/argparse.h
@@ -25,7 +25,7 @@
  *
  * You should have received a copies of the GNU General Public License
  * and the GNU Lesser General Public License along with this program;
- * if not, see <http://www.gnu.org/licenses/>.
+ * if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef LIBJNLIB_ARGPARSE_H
diff --git a/pinentry/password-cache.c b/pinentry/password-cache.c
index c98c4c5..903c013 100644
--- a/pinentry/password-cache.c
+++ b/pinentry/password-cache.c
@@ -14,7 +14,7 @@
    General Public License for more details.
 
    You should have received a copy of the GNU General Public License
-   along with this program; if not, see <http://www.gnu.org/licenses/>.
+   along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifdef HAVE_CONFIG_H
diff --git a/pinentry/password-cache.h b/pinentry/password-cache.h
index 0bc8788..77e82e1 100644
--- a/pinentry/password-cache.h
+++ b/pinentry/password-cache.h
@@ -14,7 +14,7 @@
    General Public License for more details.
 
    You should have received a copy of the GNU General Public License
-   along with this program; if not, see <http://www.gnu.org/licenses/>.
+   along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef PASSWORD_CACHE_H
diff --git a/pinentry/pinentry-emacs.c b/pinentry/pinentry-emacs.c
index 9ced8da..df12f1b 100644
--- a/pinentry/pinentry-emacs.c
+++ b/pinentry/pinentry-emacs.c
@@ -14,7 +14,7 @@
    General Public License for more details.
 
    You should have received a copy of the GNU General Public License
-   along with this program; if not, see <http://www.gnu.org/licenses/>.
+   along with this program; if not, see <https://www.gnu.org/licenses/>.
 */
 
 #ifdef HAVE_CONFIG_H
diff --git a/pinentry/pinentry-emacs.h b/pinentry/pinentry-emacs.h
index 61d04cc..24dabb9 100644
--- a/pinentry/pinentry-emacs.h
+++ b/pinentry/pinentry-emacs.h
@@ -14,7 +14,7 @@
    General Public License for more details.
 
    You should have received a copy of the GNU General Public License
-   along with this program; if not, see <http://www.gnu.org/licenses/>.
+   along with this program; if not, see <https://www.gnu.org/licenses/>.
 */
 
 #ifndef PINENTRY_EMACS_H
diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c
index 4a0f859..a5c0722 100644
--- a/pinentry/pinentry.c
+++ b/pinentry/pinentry.c
@@ -14,7 +14,7 @@
    General Public License for more details.
 
    You should have received a copy of the GNU General Public License
-   along with this program; if not, see <http://www.gnu.org/licenses/>.
+   along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifdef HAVE_CONFIG_H
diff --git a/pinentry/pinentry.h b/pinentry/pinentry.h
index c6e12e4..01fb373 100644
--- a/pinentry/pinentry.h
+++ b/pinentry/pinentry.h
@@ -14,7 +14,7 @@
    General Public License for more details.
 
    You should have received a copy of the GNU General Public License
-   along with this program; if not, see <http://www.gnu.org/licenses/>.
+   along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifndef PINENTRY_H
diff --git a/tty/Makefile.am b/tty/Makefile.am
index e232473..7168342 100644
--- a/tty/Makefile.am
+++ b/tty/Makefile.am
@@ -14,7 +14,7 @@
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, see <http://www.gnu.org/licenses/>.
+# along with this program; if not, see <https://www.gnu.org/licenses/>.
 
 ## Process this file with automake to produce Makefile.in
 
diff --git a/tty/pinentry-tty.c b/tty/pinentry-tty.c
index cef6947..6dabdcd 100644
--- a/tty/pinentry-tty.c
+++ b/tty/pinentry-tty.c
@@ -16,7 +16,7 @@
    General Public License for more details.
 
    You should have received a copy of the GNU General Public License
-   along with this program; if not, see <http://www.gnu.org/licenses/>.
+   along with this program; if not, see <https://www.gnu.org/licenses/>.
  */
 
 #ifdef HAVE_CONFIG_H
-- 
2.10.1



From dkg at fifthhorseman.net  Sat Nov  5 05:44:53 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat,  5 Nov 2016 00:44:53 -0400
Subject: [PINENTRY PATCH] build: Avoid unnecessary dependency on gtk+-2 for
 GNOME3 development.
Message-ID: <20161105044453.12760-1-dkg@fifthhorseman.net>

* configure.ac: There is no reason to reject building the GNOME3
pinentry if GTK+-2 development libraries are not present.  GNOME3 does
not require GTK+-2.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 configure.ac | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1dfdf17..2a96ccd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -438,14 +438,13 @@ if test "$pinentry_gtk_2" != "no" -o "$pinentry_gnome_3" != "no"; then
 fi
 
 dnl check if the module gtk+-2.0 exists
-if test "$pinentry_gtk_2" != "no" -o "$pinentry_gnome_3" != "no"; then
+if test "$pinentry_gtk_2" != "no"; then
 	AC_MSG_CHECKING([for gtk+-2])
 	"${PKG_CONFIG}" --exists gtk+-2.0
 	if test $? -ne 0 ; then
 		AC_MSG_RESULT([no])
 		AC_MSG_WARN([pkg-config could not find the module gtk+-2.0])
 		pinentry_gtk_2=no
-		pinentry_gnome_3=no
 	else
 		AC_MSG_RESULT([yes])
 		AC_MSG_CHECKING([gtk+-2 version >= 2.4.0])
@@ -455,7 +454,6 @@ if test "$pinentry_gtk_2" != "no" -o "$pinentry_gnome_3" != "no"; then
 		if test $? -ne 0 ; then
 			AC_MSG_WARN([building GTK+-2 pinentry disabled])
 			pinentry_gtk_2=no
-			pinentry_gnome_3=no
 		else
 			GTK2CFLAGS=`"${PKG_CONFIG}" --cflags gtk+-2.0`
 			GTK2LIBS=`"${PKG_CONFIG}" --libs gtk+-2.0`
@@ -465,10 +463,6 @@ if test "$pinentry_gtk_2" != "no" -o "$pinentry_gnome_3" != "no"; then
 			then
 			  pinentry_gtk_2=yes
 			fi
-			if test "$pinentry_gnome_3" != "no"
-			then
-			  pinentry_gnome_3=yes
-			fi
 		fi
 	fi
 fi
-- 
2.10.1



From wk at gnupg.org  Sat Nov  5 08:34:50 2016
From: wk at gnupg.org (Werner Koch)
Date: Sat, 05 Nov 2016 08:34:50 +0100
Subject: Using loopback pin entry with GnuPG 2.1
In-Reply-To: <543274049.1230443.1478299346005@mail.yahoo.com> (Vinay Sajip's
 message of "Fri, 4 Nov 2016 22:42:25 +0000 (UTC)")
References: <574777160.1243146.1476982583037.ref@mail.yahoo.com>
 <574777160.1243146.1476982583037@mail.yahoo.com>
 <878ttegr3s.fsf@wheatstone.g10code.de>
 <868322669.288810.1478254275137@mail.yahoo.com>
 <87twbnwdis.fsf@wheatstone.g10code.de>
 <325432173.1102143.1478286874607@mail.yahoo.com>
 <87ins3t2k6.fsf@wheatstone.g10code.de>
 <543274049.1230443.1478299346005@mail.yahoo.com>
Message-ID: <874m3mtm5h.fsf@wheatstone.g10code.de>

On Fri,  4 Nov 2016 23:42, vinay_sajip at yahoo.co.uk said:

> Thread-13  gpg: DBG: chan_5 -> GETINFO version
> Thread-13  gpg: DBG: chan_5 <- D 2.1.11

That is an old version of GnuPG.

> Thread-13  gpg: DBG: chan_5 -> OPTION pinentry-mode=loopback
> Thread-13  gpg: DBG: chan_5 <- ERR 67108924 Not supported <GPG Agent>
> Thread-13  gpg: setting pinentry mode 'loopback' failed: Not supported

For that old version you need to put

  allow-loopback-pinentry

into gpg-agent.conf.  However, I  would strongly suggest to switch to
2.1.15.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161105/975ad0a4/attachment.sig>

From vinay_sajip at yahoo.co.uk  Sat Nov  5 11:06:14 2016
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Sat, 5 Nov 2016 10:06:14 +0000 (UTC)
Subject: Using loopback pin entry with GnuPG 2.1
In-Reply-To: <874m3mtm5h.fsf@wheatstone.g10code.de>
References: <574777160.1243146.1476982583037.ref@mail.yahoo.com>
 <574777160.1243146.1476982583037@mail.yahoo.com>
 <878ttegr3s.fsf@wheatstone.g10code.de>
 <868322669.288810.1478254275137@mail.yahoo.com>
 <87twbnwdis.fsf@wheatstone.g10code.de>
 <325432173.1102143.1478286874607@mail.yahoo.com>
 <87ins3t2k6.fsf@wheatstone.g10code.de>
 <543274049.1230443.1478299346005@mail.yahoo.com>
 <874m3mtm5h.fsf@wheatstone.g10code.de>
Message-ID: <1487469558.1453501.1478340374239@mail.yahoo.com>

Dear Werner,


>> Thread-13  gpg: DBG: chan_5 <- D 2.1.11

> That is an old version of GnuPG.

Yes, I mentioned the version I was using at the top of my post.

> For that old version you need to put
>  allow-loopback-pinentry
> into gpg-agent.conf.  However, I  would strongly suggest to switch to
> 2.1.15.

As I mentioned in my post, the allow-loopback-pinentry option has already been specified in gpg-agent.conf. As to the version of GnuPG used - unfortunately, many users will have to use whatever GnuPG version is bundled with their distro, which in this case is 2.1.11. I am trying to see how I can improve support for GnuPG 2.1 for my users, many of whom typically will not have the option to upgrade to a more recent GnuPG version.

Does 2.1.11 not support loopback pinentry?

Regards,

Vinay Sajip


From wk at gnupg.org  Sat Nov  5 11:47:44 2016
From: wk at gnupg.org (Werner Koch)
Date: Sat, 05 Nov 2016 11:47:44 +0100
Subject: Pinentry error reporting and timeout cleanup
In-Reply-To: <20161104225752.29980-1-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Fri, 4 Nov 2016 18:57:44 -0400")
References: <20161104225752.29980-1-dkg@fifthhorseman.net>
Message-ID: <87mvherynj.fsf@wheatstone.g10code.de>

On Fri,  4 Nov 2016 23:57, dkg at fifthhorseman.net said:
> Very few of the current pinentry implementations report timeouts as
> timeouts.  Some of them (gnome3 in particular) do not even respect the
> timeout parameter at all.

Thanks for that work.  All pushed.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161105/0dc02b40/attachment.sig>

From wk at gnupg.org  Sat Nov  5 11:48:23 2016
From: wk at gnupg.org (Werner Koch)
Date: Sat, 05 Nov 2016 11:48:23 +0100
Subject: [PINENTRY PATCH] build: Avoid unnecessary dependency on gtk+-2
 for GNOME3 development.
In-Reply-To: <20161105044453.12760-1-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Sat, 5 Nov 2016 00:44:53 -0400")
References: <20161105044453.12760-1-dkg@fifthhorseman.net>
Message-ID: <87ins2rymg.fsf@wheatstone.g10code.de>

On Sat,  5 Nov 2016 05:44, dkg at fifthhorseman.net said:
> * configure.ac: There is no reason to reject building the GNOME3
> pinentry if GTK+-2 development libraries are not present.  GNOME3 does
> not require GTK+-2.

Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161105/4fe7a532/attachment.sig>

From wk at gnupg.org  Sat Nov  5 15:55:20 2016
From: wk at gnupg.org (Werner Koch)
Date: Sat, 05 Nov 2016 15:55:20 +0100
Subject: Using loopback pin entry with GnuPG 2.1
In-Reply-To: <1487469558.1453501.1478340374239@mail.yahoo.com> (Vinay Sajip's
 message of "Sat, 5 Nov 2016 10:06:14 +0000 (UTC)")
References: <574777160.1243146.1476982583037.ref@mail.yahoo.com>
 <574777160.1243146.1476982583037@mail.yahoo.com>
 <878ttegr3s.fsf@wheatstone.g10code.de>
 <868322669.288810.1478254275137@mail.yahoo.com>
 <87twbnwdis.fsf@wheatstone.g10code.de>
 <325432173.1102143.1478286874607@mail.yahoo.com>
 <87ins3t2k6.fsf@wheatstone.g10code.de>
 <543274049.1230443.1478299346005@mail.yahoo.com>
 <874m3mtm5h.fsf@wheatstone.g10code.de>
 <1487469558.1453501.1478340374239@mail.yahoo.com>
Message-ID: <878tsyrn6v.fsf@wheatstone.g10code.de>

On Sat,  5 Nov 2016 11:06, vinay_sajip at yahoo.co.uk said:

> As I mentioned in my post, the allow-loopback-pinentry option has
> already been specified in gpg-agent.conf. As to the version of GnuPG

Not in the version of the agent you are running.  Look at the log
message:

> Thread-13  gpg: DBG: chan_5 -> OPTION pinentry-mode=loopback
> Thread-13  gpg: DBG: chan_5 <- ERR 67108924 Not supported <GPG Agent>

and the code producing this:

  else if (!strcmp (key, "pinentry-mode"))
    {
      int tmp = parse_pinentry_mode (value);
      if (tmp == -1)
        err = gpg_error (GPG_ERR_INV_VALUE);
      else if (tmp == PINENTRY_MODE_LOOPBACK && !opt.allow_loopback_pinentry)
        err = gpg_error (GPG_ERR_NOT_SUPPORTED);
      else
        ctrl->pinentry_mode = tmp;
    }
  [...]
  else
    err = gpg_error (GPG_ERR_UNKNOWN_OPTION);

Thus you will see the error "Not supported" (GPG_ERR_NOT_SUPPORTED) only
if opt.allow_loopback_pinentry (this variable is set from the conf file)
is not set.  I suggest to double check your setup.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161105/29ce93d8/attachment.sig>

From neal at walfield.org  Sat Nov  5 22:26:51 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Sat, 05 Nov 2016 22:26:51 +0100
Subject: [PINENTRY PATCH v2] gnome3: Test if Gcr System Prompter is
 available at startup.
In-Reply-To: <20161103163140.29183-1-dkg@fifthhorseman.net>
References: <878tt0y2t0.fsf@europa.jade-hamburg.de>
 <20161103163140.29183-1-dkg@fifthhorseman.net>
Message-ID: <8737j539es.wl-neal@walfield.org>

Hi Daniel,

Thanks for fixing this!  As discussed offline, I made a few minor
tweaks before comitting (2e17565).

:) Neal

At Thu,  3 Nov 2016 12:31:40 -0400,
Daniel Kahn Gillmor wrote:
> 
> * gnome3/pinentry-gnome3.c (gcr_system_prompt_available): New. Tests
> whether it is possible to create a GcrSystemPrompt.
> (main): Use gcr_system_prompt_available() to decide whether to fall
> back to curses or not.
> 
> Debian-bug-id: 842015
> Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> ---
>  gnome3/pinentry-gnome3.c | 39 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
> index d6d7d16..37c7a44 100644
> --- a/gnome3/pinentry-gnome3.c
> +++ b/gnome3/pinentry-gnome3.c
> @@ -258,6 +258,39 @@ gnome3_cmd_handler (pinentry_t pe)
>  
>  pinentry_cmd_handler_t pinentry_cmd_handler = gnome3_cmd_handler;
>  
> +
> +/* test whether we can create a system prompt or not.  This briefly
> +   does create a system prompt, which blocks other tools from making
> +   the same concurrent request, so we just create it to test if it is
> +   available, and quickly close it.
> +*/
> +int gcr_system_prompt_available ()
> +{
> +  GcrSystemPrompt *prompt;
> +  GError *error = NULL;
> +  int ret = 0;
> +  
> +  prompt = gcr_system_prompt_open (0, NULL, &error);
> +  if (prompt)
> +    {
> +      ret = 1;
> +      if (!gcr_system_prompt_close (prompt, NULL, &error))
> +          fprintf (stderr, "failed to close test Gcr System Prompt (%d): %s\n",
> +                   error ? error->code : -1, error ? error->message : "<no GError>");
> +      g_clear_object (&prompt);
> +    }
> +  else
> +      /* This one particular failure is OK; we're clearly capable of
> +         making a system prompt, even though someone else has the
> +         system prompter right now: */
> +    if (error && error->code == GCR_SYSTEM_PROMPT_IN_PROGRESS)
> +      ret = 1;
> +
> +  if (error)
> +    g_error_free (error);
> +  return ret;
> +}
> +
>  int
>  main (int argc, char *argv[])
>  {
> @@ -270,6 +303,12 @@ main (int argc, char *argv[])
>                 " falling back to curses\n");
>        pinentry_cmd_handler = curses_cmd_handler;
>      }
> +  else if (!gcr_system_prompt_available ())
> +    {
> +      fprintf (stderr, "No Gcr System Prompter available,"
> +               " falling back to curses\n");
> +      pinentry_cmd_handler = curses_cmd_handler;
> +    }      
>  #endif
>  
>    pinentry_parse_opts (argc, argv);
> -- 
> 2.10.1
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 


From dkg at fifthhorseman.net  Sat Nov  5 22:53:47 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat,  5 Nov 2016 17:53:47 -0400
Subject: [PINENTRY PATCH] gnome3: Avoid risk of uinitialized memory access.
Message-ID: <20161105215347.28391-1-dkg@fifthhorseman.net>

* gnome3/pinentry-gnome3.c (_propagate_g_error_to_pinentry): Ensure
that pinentry->specific_err_info is null-terminated.

--

It's possible that "%d: %s" ends up producing more than 20 additional
characters.  A 64-bit signed int at its minimum is
"-9223372036854775808", which is 20 characters.  On any platform where
gint is 128-bit (i don't know whether they exist), it could be
significantly more.

snprintf doesn't write the final NUL byte if the string exceeds the
buffer, so anyone reading specific_err_info as a NUL-terminated string
in such a case would go on to read uninitialized memory after the
buffer.  So we should force there to always be a NUL char after the
written buffer.  It would be simpler to use asprintf, but i suspect
that's not portable enough for use in pinentry.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 gnome3/pinentry-gnome3.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index ba6ab46..b164ed0 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -93,13 +93,16 @@ static void
 _propagate_g_error_to_pinentry (pinentry_t pe, GError *error,
                                 gpg_err_code_t code, const char *loc)
 {
-  size_t infolen = strlen(error->message) + 20;
+  size_t infolen = strlen(error->message) + 24;
 
   pe->specific_err = gpg_error (code);
-  pe->specific_err_info = malloc (infolen);
+  pe->specific_err_info = malloc (infolen + 1);
   if (pe->specific_err_info)
-    snprintf (pe->specific_err_info, infolen,
-              "%d: %s", error->code, error->message);
+    {
+      pe->specific_err_info[infolen] = '\0';
+      snprintf (pe->specific_err_info, infolen,
+                "%d: %s", error->code, error->message);
+    }
   pe->specific_err_loc = loc;
 }
 
-- 
2.10.1



From dkg at fifthhorseman.net  Sun Nov  6 04:26:35 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat,  5 Nov 2016 23:26:35 -0400
Subject: [PINENTRY PATCH] tty: Declare dummy curses_cmd_handler.
Message-ID: <20161106032635.6322-1-dkg@fifthhorseman.net>

* tty/pinentry-tty.c: Declare a dummy handler for the
curses_cmd_handler for fallback.

--

This is needed for building pinentry-tty, which links to a copy of the
pinentry object which doesn't have curses (it makes no sense to
fallback from tty to curses).  But the new cmd_info in
pinentry/pinentry.c needs some sort of value to test against when
reporting the flavor.

You can replicate this linker error from git with:

     ./autogen.sh
     ./configure --enable-maintainer-mode \
       --enable-{fallback-curses,pinentry-tty} \
       --disable-{inside-emacs,libsecret} && make

Which produces:

    gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith   -o pinentry-tty pinentry-tty.o ../pinentry/libpinentry.a ../secmem/libsecmem.a -lassuan -L/usr/lib/x86_64-linux-gnu -lgpg-error -L/usr/lib/x86_64-linux-gnu -lgpg-error  -lcap
    ../pinentry/libpinentry.a(pinentry.o): In function `cmd_getinfo':
    ?BUILDDIR?/pinentry/pinentry.c:1457: undefined reference to `curses_cmd_handler'
    collect2: error: ld returned 1 exit status
    Makefile:410: recipe for target 'pinentry-tty' failed
    make[2]: *** [pinentry-tty] Error 1
    make[2]: Leaving directory '?BUILDDIR?/tty'

One could argue that developers who --enable-tty then must also
--disable-fallback-curses, but that would just mean that it's
impossible to't build one of the graphical pinentries at the same time
(with curses fallback) as you are actually building pinentry-tty.
Arguably, though, the ./configure script should figure out the right
thing to do in this case and the build each variant sensibly.

This patch is a hack to ensure that pinentry-tty continues to link
properly even when other pinentries are being built concurrently with
a curses fallback.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 tty/pinentry-tty.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tty/pinentry-tty.c b/tty/pinentry-tty.c
index bd82fad..3d6cd5a 100644
--- a/tty/pinentry-tty.c
+++ b/tty/pinentry-tty.c
@@ -556,6 +556,10 @@ tty_cmd_handler(pinentry_t pinentry)
 
 pinentry_cmd_handler_t pinentry_cmd_handler = tty_cmd_handler;
 
+/* needed to link cleanly; should never be used except for comparison
+ * in pinentry/pinentry.c's cmd_getinfo(): */
+pinentry_cmd_handler_t curses_cmd_handler = NULL;
+
 
 int
 main (int argc, char *argv[])
-- 
2.10.1



From dkg at fifthhorseman.net  Sun Nov  6 08:17:04 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun,  6 Nov 2016 02:17:04 -0500
Subject: [PINENTRY PATCH] gnome3: Fall back to curses if screensaver is locked.
Message-ID: <20161106071704.16758-1-dkg@fifthhorseman.net>

* gnome3/pinentry-gnome3.c (pe_gnome_screen_locked): New Function.
Returns true only if we can talk to a GNOME screensaver over D-Bus and
it assures us that it is locked.
(main): If GNOME screensaver is locked, fall back to curses.

--

We assume that if pinentry is triggered while the screensaver is
locked, then it is likely being done by some sort of remote connection
(e.g. ssh), and isn't being done directly from the graphical console.
In that case, prompting at the graphical console won't be able to get
the attention of the user, so we should fall back to curses if
possible.

GnuPG-bug-id: 2818
---
 gnome3/pinentry-gnome3.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index ba6ab46..fd345a5 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -390,6 +390,69 @@ pe_gcr_timeout_done (gpointer user_data)
 
 pinentry_cmd_handler_t pinentry_cmd_handler = gnome3_cmd_handler;
 
+/* Test whether there is a GNOME screensaver running that happens to
+ * be locked.  Note that if there is no GNOME screensaver running at
+ * all the answer is still FALSE */
+static gboolean
+pe_gnome_screen_locked (void)
+{
+  GDBusConnection *dbus;
+  GError *error;
+  GVariant *reply, *reply_bool;
+  gboolean ret;
+
+  dbus = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, &error);
+
+  if (!dbus)
+    {
+      fprintf (stderr, "failed to connect to user session D-Bus (%d): %s",
+               error ? error->code : -1,
+               error ? error->message : "<no GError>");
+      if (error)
+        g_error_free (error);
+      return FALSE;
+    }
+
+  /* this is intended to be the equivalent of:
+   * dbus-send --print-reply=literal --session          \
+   *           --dest=org.gnome.ScreenSaver             \
+   *           /org/gnome/ScreenSaver                   \
+   *           org.gnome.ScreenSaver.GetActive
+   */
+  reply = g_dbus_connection_call_sync (dbus,
+                                       "org.gnome.ScreenSaver",
+                                       "/org/gnome/ScreenSaver",
+                                       "org.gnome.ScreenSaver",
+                                       "GetActive",
+                                       NULL,
+                                       ((const GVariantType *) "(b)"),
+                                       G_DBUS_CALL_FLAGS_NO_AUTO_START,
+                                       0,
+                                       NULL,
+                                       &error);
+  g_object_unref(dbus);
+  if (!reply)
+    {
+      fprintf (stderr, "failed to get reply (%d): %s",
+               error ? error->code : -1,
+               error ? error->message : "<no GError>");
+      if (error)
+        g_error_free (error);
+      return FALSE;
+    }
+  reply_bool = g_variant_get_child_value (reply, 0);
+  if (!reply_bool)
+    {
+      fprintf (stderr, "failed to get boolean from reply\n");
+      ret = FALSE;
+    }
+  else
+    ret = g_variant_get_boolean (reply_bool);
+
+  g_variant_unref (reply_bool);
+  g_variant_unref (reply);
+  return ret;
+}
 
 /* Test whether we can create a system prompt or not.  This briefly
  * does create a system prompt, which blocks other tools from making
@@ -443,6 +506,12 @@ main (int argc, char *argv[])
                " falling back to curses\n");
       pinentry_cmd_handler = curses_cmd_handler;
     }
+  else if (pe_gnome_screen_locked ())
+    {
+      fprintf (stderr, "GNOME screensaver is locked,"
+               " falling back to curses\n");
+      pinentry_cmd_handler = curses_cmd_handler;
+    }
 #endif
 
   pinentry_parse_opts (argc, argv);
-- 
2.10.2



From Juergen.Schaepker at giepa.de  Sun Nov  6 13:40:57 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Sun, 6 Nov 2016 12:40:57 +0000
Subject: WKD lookup (Re: Web Key Service server lookup)
In-Reply-To: <87shr7t2zz.fsf@wheatstone.g10code.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@s2008sbs.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@s2008sbs.intern.giepa.de>
 <201611021045.07973.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@s2008sbs.intern.giepa.de>
 <87a8dfw7mb.fsf@wheatstone.g10code.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C90@s2008sbs.intern.giepa.de>
 <87shr7t2zz.fsf@wheatstone.g10code.de>
Message-ID: <em58046c15-28a4-4bbc-a651-3f85ff72d2e7@titan>

Hi,

"Werner Koch" <wk at gnupg.org> wrote:

  >> How exactly is the domain-part supposed to be determined by the WKD 
server?

 >Strip everyting up to and including the first '@' from the (UTF_8
 >encoded) addr-spec.

My question was apparently ambiguous. My concern is the WKD server. How 
does a WKD server know which domain it is serving for when the request 
HOST header is modified (e.g. by a reverse proxy) and so the domain-part 
cannot be determined from that.

Example scenario:
The WKD server is intended to provide keys for a.com, a.net, a.de, 
bass.de, ba?.de, ?ppelwoi.de etc. WKD is redirected from all those 
domains to some server at wkd.unrelated.com. At least from one of those 
domains redirection is done by a request-modifying reverse proxy, e.g. 
a.net requests reach the WKD with HOST reverse.nota.com.

The lookup hash for email addresses with local-part "joe" is the same 
for all domains (if I don't misunderstand something fundamental in the 
current draft) so there is always ambiguity. And non-ASCII local-parts 
will only match by pure chance because they are not normalized.


I don't think the need to use RFC 3490 ToASCII (or similar) can be 
avoided.


best regards,
JS

From Juergen.Schaepker at giepa.de  Sun Nov  6 13:47:02 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Sun, 6 Nov 2016 12:47:02 +0000
Subject: Web Key Directory handling of IDN
In-Reply-To: <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
Message-ID: <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>


On 04/11/16 20:15, Peter Lebbing wrote:

 >Sorry, that's horribly inaccurate, I meant the path portion of the URL
 >doesn't contain the domain name.

The local-part contains UTF-8 as well and isn't normalized (with e.g. 
ToASCII) in the current draft. This automatically leads to ambiguity for 
non-ASCII I'd think.


best regards,
JS

From peter at digitalbrains.com  Sun Nov  6 13:55:32 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 6 Nov 2016 13:55:32 +0100
Subject: WKD lookup
In-Reply-To: <em58046c15-28a4-4bbc-a651-3f85ff72d2e7@titan>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@s2008sbs.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@s2008sbs.intern.giepa.de>
 <201611021045.07973.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@s2008sbs.intern.giepa.de>
 <87a8dfw7mb.fsf@wheatstone.g10code.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C90@s2008sbs.intern.giepa.de>
 <87shr7t2zz.fsf@wheatstone.g10code.de>
 <em58046c15-28a4-4bbc-a651-3f85ff72d2e7@titan>
Message-ID: <a79488ce-3bee-e673-e62f-2c4493a1e0cd@digitalbrains.com>

On 06/11/16 13:40, J?rgen Sch?pker wrote:
> My question was apparently ambiguous. My concern is the WKD server. How 
> does a WKD server know which domain it is serving for when the request 
> HOST header is modified (e.g. by a reverse proxy) and so the domain-part 
> cannot be determined from that.

This doesn't seem to be a concern of this (draft) standard. HTTP Host: is well
standardized and defined. You should solve this there, in your webserver/proxy.
This is just sensible layering of protocols. You should strive to solve the
problems in the correct layer. Sometimes a little layering violation is still
the lesser of evils, but I really don't think that applies here. *Especially*
with IDN! That only makes it worse. How many independent IDN implementations in
how many layers do you want to add?

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From Juergen.Schaepker at giepa.de  Sun Nov  6 14:06:32 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Sun, 6 Nov 2016 13:06:32 +0000
Subject: WKD lookup
In-Reply-To: <a79488ce-3bee-e673-e62f-2c4493a1e0cd@digitalbrains.com>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@s2008sbs.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@s2008sbs.intern.giepa.de>
 <201611021045.07973.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@s2008sbs.intern.giepa.de>
 <87a8dfw7mb.fsf@wheatstone.g10code.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C90@s2008sbs.intern.giepa.de>
 <87shr7t2zz.fsf@wheatstone.g10code.de>
 <em58046c15-28a4-4bbc-a651-3f85ff72d2e7@titan>
 <a79488ce-3bee-e673-e62f-2c4493a1e0cd@digitalbrains.com>
Message-ID: <em41753d92-163a-4b34-9211-8a79fb36bfe3@titan>

Hi,


 >This doesn't seem to be a concern of this (draft) standard. HTTP Host: 
is well
 >standardized and defined. You should solve this there, in your 
webserver/proxy.
 >This is just sensible layering of protocols. You should strive to solve 
the
 >problems in the correct layer. Sometimes a little layering violation is 
still
 >the lesser of evils, but I really don't think that applies here.

You will not increase the adoption rate for OpenPGP if the standard just 
creates unnecessary requirements for no good reason.

I see no advantage why the hash should be calculated from local-part 
only and not from the full Email-address.

 >*Especially*
 >with IDN! That only makes it worse. How many independent IDN 
implementations
 >in how many layers do you want to add?

One might be enough, on MUA and WKD server. libidn ToASCII should be 
able do it, not?


best regards,
JS

From peter at digitalbrains.com  Sun Nov  6 16:54:25 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 6 Nov 2016 16:54:25 +0100
Subject: WKD lookup
In-Reply-To: <em41753d92-163a-4b34-9211-8a79fb36bfe3@titan>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@s2008sbs.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@s2008sbs.intern.giepa.de>
 <201611021045.07973.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@s2008sbs.intern.giepa.de>
 <87a8dfw7mb.fsf@wheatstone.g10code.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C90@s2008sbs.intern.giepa.de>
 <87shr7t2zz.fsf@wheatstone.g10code.de>
 <em58046c15-28a4-4bbc-a651-3f85ff72d2e7@titan>
 <a79488ce-3bee-e673-e62f-2c4493a1e0cd@digitalbrains.com>
 <em41753d92-163a-4b34-9211-8a79fb36bfe3@titan>
Message-ID: <c3ce0801-7c0a-58dc-57f5-b02e649b2b9f@digitalbrains.com>

On 06/11/16 14:06, J?rgen Sch?pker wrote:
>> How many independent IDN implementations in how many layers do you
>> want to add?
> 
> One might be enough, on MUA and WKD server. libidn ToASCII should be
>  able do it, not?

I think we've both made clear where we stand and that's as far as we're
gonna get, but I'd just like to point out that you're doing it twice
then, not once. Once in the HTTP layer to reach the internationalised
domain name in the first place, and once more in the MUA / WKD server.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From peter at digitalbrains.com  Sun Nov  6 16:57:31 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 6 Nov 2016 16:57:31 +0100
Subject: WKD lookup
In-Reply-To: <em41753d92-163a-4b34-9211-8a79fb36bfe3@titan>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@s2008sbs.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@s2008sbs.intern.giepa.de>
 <201611021045.07973.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@s2008sbs.intern.giepa.de>
 <87a8dfw7mb.fsf@wheatstone.g10code.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C90@s2008sbs.intern.giepa.de>
 <87shr7t2zz.fsf@wheatstone.g10code.de>
 <em58046c15-28a4-4bbc-a651-3f85ff72d2e7@titan>
 <a79488ce-3bee-e673-e62f-2c4493a1e0cd@digitalbrains.com>
 <em41753d92-163a-4b34-9211-8a79fb36bfe3@titan>
Message-ID: <3f3815b2-647e-71d5-58ae-a2cf33c3a2c2@digitalbrains.com>

On 06/11/16 14:06, J?rgen Sch?pker wrote:
> I see no advantage why the hash should be calculated from local-part 
> only and not from the full Email-address.

Not having to deal with IDN? :-)

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From neal at walfield.org  Mon Nov  7 01:09:17 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Sun, 06 Nov 2016 19:09:17 -0500
Subject: [PINENTRY PATCH] gnome3: Fall back to curses if screensaver is
 locked.
In-Reply-To: <20161106071704.16758-1-dkg@fifthhorseman.net>
References: <20161106071704.16758-1-dkg@fifthhorseman.net>
Message-ID: <87y40w1782.wl-neal@walfield.org>

Thanks for working on this.  I've applied it with a small change,
which we discussed offline.

For the record, this doesn't detect if xscreensaver or something
similar is running and fall back to the curses interface, it only
works for GNOME screensaver.  But, it is reasonable to expect that
anyone who uses pinentry-gnome3 will be running GNOME screensaver and
not xscreensaver.

:) Neal

At Sun,  6 Nov 2016 02:17:04 -0500,
Daniel Kahn Gillmor wrote:
> 
> * gnome3/pinentry-gnome3.c (pe_gnome_screen_locked): New Function.
> Returns true only if we can talk to a GNOME screensaver over D-Bus and
> it assures us that it is locked.
> (main): If GNOME screensaver is locked, fall back to curses.
> 
> --
> 
> We assume that if pinentry is triggered while the screensaver is
> locked, then it is likely being done by some sort of remote connection
> (e.g. ssh), and isn't being done directly from the graphical console.
> In that case, prompting at the graphical console won't be able to get
> the attention of the user, so we should fall back to curses if
> possible.
> 
> GnuPG-bug-id: 2818
> ---
>  gnome3/pinentry-gnome3.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 69 insertions(+)
> 
> diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
> index ba6ab46..fd345a5 100644
> --- a/gnome3/pinentry-gnome3.c
> +++ b/gnome3/pinentry-gnome3.c
> @@ -390,6 +390,69 @@ pe_gcr_timeout_done (gpointer user_data)
>  
>  pinentry_cmd_handler_t pinentry_cmd_handler = gnome3_cmd_handler;
>  
> +/* Test whether there is a GNOME screensaver running that happens to
> + * be locked.  Note that if there is no GNOME screensaver running at
> + * all the answer is still FALSE */
> +static gboolean
> +pe_gnome_screen_locked (void)
> +{
> +  GDBusConnection *dbus;
> +  GError *error;
> +  GVariant *reply, *reply_bool;
> +  gboolean ret;
> +
> +  dbus = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, &error);
> +
> +  if (!dbus)
> +    {
> +      fprintf (stderr, "failed to connect to user session D-Bus (%d): %s",
> +               error ? error->code : -1,
> +               error ? error->message : "<no GError>");
> +      if (error)
> +        g_error_free (error);
> +      return FALSE;
> +    }
> +
> +  /* this is intended to be the equivalent of:
> +   * dbus-send --print-reply=literal --session          \
> +   *           --dest=org.gnome.ScreenSaver             \
> +   *           /org/gnome/ScreenSaver                   \
> +   *           org.gnome.ScreenSaver.GetActive
> +   */
> +  reply = g_dbus_connection_call_sync (dbus,
> +                                       "org.gnome.ScreenSaver",
> +                                       "/org/gnome/ScreenSaver",
> +                                       "org.gnome.ScreenSaver",
> +                                       "GetActive",
> +                                       NULL,
> +                                       ((const GVariantType *) "(b)"),
> +                                       G_DBUS_CALL_FLAGS_NO_AUTO_START,
> +                                       0,
> +                                       NULL,
> +                                       &error);
> +  g_object_unref(dbus);
> +  if (!reply)
> +    {
> +      fprintf (stderr, "failed to get reply (%d): %s",
> +               error ? error->code : -1,
> +               error ? error->message : "<no GError>");
> +      if (error)
> +        g_error_free (error);
> +      return FALSE;
> +    }
> +  reply_bool = g_variant_get_child_value (reply, 0);
> +  if (!reply_bool)
> +    {
> +      fprintf (stderr, "failed to get boolean from reply\n");
> +      ret = FALSE;
> +    }
> +  else
> +    ret = g_variant_get_boolean (reply_bool);
> +
> +  g_variant_unref (reply_bool);
> +  g_variant_unref (reply);
> +  return ret;
> +}
>  
>  /* Test whether we can create a system prompt or not.  This briefly
>   * does create a system prompt, which blocks other tools from making
> @@ -443,6 +506,12 @@ main (int argc, char *argv[])
>                 " falling back to curses\n");
>        pinentry_cmd_handler = curses_cmd_handler;
>      }
> +  else if (pe_gnome_screen_locked ())
> +    {
> +      fprintf (stderr, "GNOME screensaver is locked,"
> +               " falling back to curses\n");
> +      pinentry_cmd_handler = curses_cmd_handler;
> +    }
>  #endif
>  
>    pinentry_parse_opts (argc, argv);
> -- 
> 2.10.2
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 


From neal at walfield.org  Mon Nov  7 01:27:30 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Sun, 06 Nov 2016 19:27:30 -0500
Subject: [PINENTRY PATCH] tty: Declare dummy curses_cmd_handler.
In-Reply-To: <20161106032635.6322-1-dkg@fifthhorseman.net>
References: <20161106032635.6322-1-dkg@fifthhorseman.net>
Message-ID: <87wpgg16dp.wl-neal@walfield.org>

Committed.  Thanks!

At Sat,  5 Nov 2016 23:26:35 -0400,
Daniel Kahn Gillmor wrote:
> 
> * tty/pinentry-tty.c: Declare a dummy handler for the
> curses_cmd_handler for fallback.
> 
> --
> 
> This is needed for building pinentry-tty, which links to a copy of the
> pinentry object which doesn't have curses (it makes no sense to
> fallback from tty to curses).  But the new cmd_info in
> pinentry/pinentry.c needs some sort of value to test against when
> reporting the flavor.
> 
> You can replicate this linker error from git with:
> 
>      ./autogen.sh
>      ./configure --enable-maintainer-mode \
>        --enable-{fallback-curses,pinentry-tty} \
>        --disable-{inside-emacs,libsecret} && make
> 
> Which produces:
> 
>     gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith   -o pinentry-tty pinentry-tty.o ../pinentry/libpinentry.a ../secmem/libsecmem.a -lassuan -L/usr/lib/x86_64-linux-gnu -lgpg-error -L/usr/lib/x86_64-linux-gnu -lgpg-error  -lcap
>     ../pinentry/libpinentry.a(pinentry.o): In function `cmd_getinfo':
>     ?BUILDDIR?/pinentry/pinentry.c:1457: undefined reference to `curses_cmd_handler'
>     collect2: error: ld returned 1 exit status
>     Makefile:410: recipe for target 'pinentry-tty' failed
>     make[2]: *** [pinentry-tty] Error 1
>     make[2]: Leaving directory '?BUILDDIR?/tty'
> 
> One could argue that developers who --enable-tty then must also
> --disable-fallback-curses, but that would just mean that it's
> impossible to't build one of the graphical pinentries at the same time
> (with curses fallback) as you are actually building pinentry-tty.
> Arguably, though, the ./configure script should figure out the right
> thing to do in this case and the build each variant sensibly.
> 
> This patch is a hack to ensure that pinentry-tty continues to link
> properly even when other pinentries are being built concurrently with
> a curses fallback.
> 
> Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> ---
>  tty/pinentry-tty.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/tty/pinentry-tty.c b/tty/pinentry-tty.c
> index bd82fad..3d6cd5a 100644
> --- a/tty/pinentry-tty.c
> +++ b/tty/pinentry-tty.c
> @@ -556,6 +556,10 @@ tty_cmd_handler(pinentry_t pinentry)
>  
>  pinentry_cmd_handler_t pinentry_cmd_handler = tty_cmd_handler;
>  
> +/* needed to link cleanly; should never be used except for comparison
> + * in pinentry/pinentry.c's cmd_getinfo(): */
> +pinentry_cmd_handler_t curses_cmd_handler = NULL;
> +
>  
>  int
>  main (int argc, char *argv[])
> -- 
> 2.10.1
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From neal at walfield.org  Mon Nov  7 01:28:09 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Sun, 06 Nov 2016 19:28:09 -0500
Subject: [PINENTRY PATCH] gnome3: Avoid risk of uinitialized memory access.
In-Reply-To: <20161105215347.28391-1-dkg@fifthhorseman.net>
References: <20161105215347.28391-1-dkg@fifthhorseman.net>
Message-ID: <87vaw016cm.wl-neal@walfield.org>

I changed the code to use g_strdup_printf to do the actual formatting.
Then, there is no possibility of a buffer overflow.

Thanks!

:) Neal

At Sat,  5 Nov 2016 17:53:47 -0400,
Daniel Kahn Gillmor wrote:
> 
> * gnome3/pinentry-gnome3.c (_propagate_g_error_to_pinentry): Ensure
> that pinentry->specific_err_info is null-terminated.
> 
> --
> 
> It's possible that "%d: %s" ends up producing more than 20 additional
> characters.  A 64-bit signed int at its minimum is
> "-9223372036854775808", which is 20 characters.  On any platform where
> gint is 128-bit (i don't know whether they exist), it could be
> significantly more.
> 
> snprintf doesn't write the final NUL byte if the string exceeds the
> buffer, so anyone reading specific_err_info as a NUL-terminated string
> in such a case would go on to read uninitialized memory after the
> buffer.  So we should force there to always be a NUL char after the
> written buffer.  It would be simpler to use asprintf, but i suspect
> that's not portable enough for use in pinentry.
> 
> Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> ---
>  gnome3/pinentry-gnome3.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
> index ba6ab46..b164ed0 100644
> --- a/gnome3/pinentry-gnome3.c
> +++ b/gnome3/pinentry-gnome3.c
> @@ -93,13 +93,16 @@ static void
>  _propagate_g_error_to_pinentry (pinentry_t pe, GError *error,
>                                  gpg_err_code_t code, const char *loc)
>  {
> -  size_t infolen = strlen(error->message) + 20;
> +  size_t infolen = strlen(error->message) + 24;
>  
>    pe->specific_err = gpg_error (code);
> -  pe->specific_err_info = malloc (infolen);
> +  pe->specific_err_info = malloc (infolen + 1);
>    if (pe->specific_err_info)
> -    snprintf (pe->specific_err_info, infolen,
> -              "%d: %s", error->code, error->message);
> +    {
> +      pe->specific_err_info[infolen] = '\0';
> +      snprintf (pe->specific_err_info, infolen,
> +                "%d: %s", error->code, error->message);
> +    }
>    pe->specific_err_loc = loc;
>  }
>  
> -- 
> 2.10.1
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 


From bernhard at intevation.de  Mon Nov  7 09:14:57 2016
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 07 Nov 2016 09:14:57 +0100
Subject: Question to WKD-Feature
In-Reply-To: <877f8jui5i.fsf@wheatstone.g10code.de>
References: <bad1978d-bc5b-91a4-0a22-e0a1cd23e119@heinlein-support.de>
 <877f8jui5i.fsf@wheatstone.g10code.de>
Message-ID: <1702876.boSI1JWCEu@kymo.gruen>

Werner, 

[WKD https get method must return the binary representation]

Am Freitag, 4. November 2016, 21:03:37 schrieb Werner Koch:
> It is binary because HTTP transports binary data just fine.
> 
> In contrast SMTP is not able to transport binary

what do you think about the idea to also allow "ascii armored"
so that some server implementations (of WKS) could manage the pubkeys
without looking into the contents? They could just deliver the ascii 
armored pubkey they've gotten from the client via auth-summit.

Best Regards,
Bernhard


-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
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: 490 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161107/5216a225/attachment.sig>

From wk at gnupg.org  Mon Nov  7 08:13:33 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 07 Nov 2016 08:13:33 +0100
Subject: snprintf (was: [PINENTRY PATCH] gnome3: Avoid risk of uinitialized
 memory access)
In-Reply-To: <20161105215347.28391-1-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Sat, 5 Nov 2016 17:53:47 -0400")
References: <20161105215347.28391-1-dkg@fifthhorseman.net>
Message-ID: <87bmxrpwie.fsf@wheatstone.g10code.de>

On Sat,  5 Nov 2016 22:53, dkg at fifthhorseman.net said:

> snprintf doesn't write the final NUL byte if the string exceeds the
> buffer, so anyone reading specific_err_info as a NUL-terminated string

I have some comments on this problem, given that I changed your original
commit and removed the explicit string termination before Neal changed
this again to use g_strdup_printf.  This is just a FWIW and there is no
need for any action.

The specs are not fully clear on what shall happen when the result needs
to be truncated but there would be space for a terminating Nul.  It is
probably not only my interpretation that surprises should be avoid and
snprintf(3) should behave similar to fgets(3); the Linux man page,
which should be aligned with C89 and POSIX-2001 says:

  fgets() reads in at most one less than size characters from stream and
  stores them into the buffer pointed to by s.  [...] A terminating null
  byte ('\0') is stored after the last character in the buffer.

This behaviour makes a lot of sense because, like snprintf, fgets works
on strings (i.e. Nul terminated buffers).  GnuPG's own snprintf
implementations (meanwhile taken from libgpg-error) makes sure that the
buffer is always Nul terminated (unless SIZE is 0),  This is the same
behaviour as glibc and other other snprintf implementations.  A test
program (see below) shows this:

  $ ./a.out
  ->xxxxx<-
  ->123<-
  ->123<-

Now, the Windows snprintf does not behave in this sane way:

  $ wine ./a.exe
  ->xxxxx<-
  ->123<-
  ->1234x<-

I knew that this was the case for Windows XP but I assumed that this was
fixed in later Windows versions.  Only now I looked at more recent
versions and unfortunately I see the same behaviour from XP and Wine
also on Vista.

Old code in GnuPG used to use this pattern:

  snprintf (buf, sizeof buf, format);
  buf[sizeof buf -1] = 0;

which was only for that Windows problem.  After we switched to our own
snprintf (which also allows for arg reordering and all kind of modern
format specifiers) that failsafe assignment was removed.

I removed that code also from Pinentry without realizing that we do not
use our wrapped function.

> written buffer.  It would be simpler to use asprintf, but i suspect
> that's not portable enough for use in pinentry.

Well, we could make use of the asprintf from libgpg-error.  But similar
to g_strdup_printf (which is now used), there is the problem of
different malloc systems in Windows - you need to use the free from the
same libc DLL which also implemnts the used malloc.  For larger
applications it may happen that several libc versions are in use!  Thus
to use the asprintf from libgpg-error the free would also needed to be
remapped to es_free.  Thus using the old explicit termination is often
a better way.  


Shalom-Salam,

   Werner


p.s.
--8<---------------cut here---------------start------------->8---
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int
main (void)
{
  char buffer[6];

  memset (buffer, 'x', 5);
  buffer[5] = 0;
  printf ("->%s<-\n", buffer);

  snprintf (buffer, 4, "123");
  printf ("->%s<-\n", buffer);

  memset (buffer, 'x', 5);
  buffer[5] = 0;

  snprintf (buffer, 4, "1234");
  printf ("->%s<-\n", buffer);

  return 0;
}
--8<---------------cut here---------------end--------------->8---


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161107/3e40beff/attachment.sig>

From wk at gnupg.org  Mon Nov  7 08:19:47 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 07 Nov 2016 08:19:47 +0100
Subject: Web Key Directory handling of IDN
In-Reply-To: <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan> (=?utf-8?Q?=22?=
 =?utf-8?Q?J=C3=BCrgen=09Sch=C3=A4pker=22's?= message of "Sun, 6 Nov 2016
 12:47:02 +0000")
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
Message-ID: <87k2cfpxik.fsf@wheatstone.g10code.de>

On Sun,  6 Nov 2016 13:47, Juergen.Schaepker at giepa.de said:

> The local-part contains UTF-8 as well and isn't normalized (with e.g. 
> ToASCII) in the current draft. This automatically leads to ambiguity for 
> non-ASCII I'd think.

The rules on how to lowercase UTF-8 are pretty complex and chnage from
time to time.  Thus they are not mapped:

  all upper-case ASCII characters in a User ID are mapped to lowercase.
  Non-ASCII characters are not changed.

ASCII means all bytes with bit 7 cleared.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161107/0247fcbc/attachment-0001.sig>

From peter at digitalbrains.com  Mon Nov  7 11:12:16 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 7 Nov 2016 11:12:16 +0100
Subject: Web Key Directory handling of IDN
In-Reply-To: <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
Message-ID: <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>

On 06/11/16 13:47, J?rgen Sch?pker wrote:
> The local-part contains UTF-8 as well and isn't normalized (with e.g.
>  ToASCII) in the current draft. This automatically leads to ambiguity
> for non-ASCII I'd think.

I don't think the standard is ambiguous about this: it says that you map
uppercase ASCII to lowercase and leave the rest unharmed.

But I think you mean the match is overspecific. However, you need to be
careful not to match more than the mail server does. I think this isn't
standardized anywhere, different mail servers do different things.[1]

Now suppose WKD would match more than the mail server would. I think
this is a real problem. Suppose you have <j?rgen.sch?pker at example.org>.
The mail server at example.org doesn't do any more than lowercasing
ASCII uppercase. This means I can still register
<jurgen.schapker at example.org>, and use that address. Now I create an
OpenPGP key with both e-mail addresses as UID's, and register it through
example.org's Web Key Directory. If a search for the local part
j?rgen.sch?pker would search for jurgen.schapker instead, people would
end up downloading my OpenPGP key, not yours, and would then use it
since it holds the correct UID.

I think your matching behaviour needs to correspond as well as possible
to what the actual mail server does. It seems matching more specifically
is less bad than matching more broadly. I don't see the advantage of
using RFC 3490 ToASCII on the match at all, by the way? This doesn't
seem to actually broaden the match at all, it just encodes it
differently? I'm probably misunderstanding your point :).

On a completely different note, I think it's great you're giving the WKD
proposal a lot of thought and effort. Thanks for trying to make OpenPGP
and its use better!

I noticed something you said in the other thread I'd also like to reply
to, and since this thread seems to be about the same subject, I'll
copy-paste it here.

On 06/11/16 13:40, J?rgen Sch?pker wrote:
> Example scenario: The WKD server is intended to provide keys for
> a.com, a.net, a.de, bass.de, ba?.de, ?ppelwoi.de etc. WKD is
> redirected from all those domains to some server at
> wkd.unrelated.com. At least from one of those domains redirection is
> done by a request-modifying reverse proxy, e.g. a.net requests reach
> the WKD with HOST reverse.nota.com.

If you're redirecting anyway, you can easily solve this. Let's suppose
bass.de and ba?.de indicate the same e-mail accounts, and the others are
all individual. You'd simply redirect as follows:

https://bass.de/.well-known/openpgpkey/*
->
https://wkd.unrelated.com/bass.de/*

https://ba?.de/.well-known/openpgpkey/*
->
https://wkd.unrelated.com/bass.de/*

https://a.com/.well-known/openpgpkey/*
->
https://wkd.unrelated.com/a.com/*

https://a.net/.well-known/openpgpkey/*
->
https://wkd.unrelated.com/a.net/*

etc. etc.

You can simply manually avoid UTF-8, by simply writing the redirect rule
to be:

https://?ppelwoi.de/.well-known/openpgpkey/*
->
https://wkd.unrelated.com/appelwoi.e/*

HTH,

Peter.

[1] GMail even removes dots from the local part before matching! But you
certainly can't accomodate every strange behaviour, so let's not even
try to cope with that.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From peter at digitalbrains.com  Mon Nov  7 11:37:59 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 7 Nov 2016 11:37:59 +0100
Subject: WKD lookup
In-Reply-To: <87shr7t2zz.fsf@wheatstone.g10code.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65A48@S2008SBS.intern.giepa.de>
 <fc5b6ded-e9f5-4109-4606-1ebf7c8c3a1d@digitalbrains.com>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65B96@S2008SBS.intern.giepa.de>
 <201611021045.07973.bernhard@intevation.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65BD8@S2008SBS.intern.giepa.de>
 <87a8dfw7mb.fsf@wheatstone.g10code.de>
 <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C90@S2008SBS.intern.giepa.de>
 <87shr7t2zz.fsf@wheatstone.g10code.de>
Message-ID: <cbf72383-50f2-5601-b643-8bb8fa715b8a@digitalbrains.com>

On 04/11/16 21:16, Werner Koch wrote:
> Strip everyting up to and including the first '@' from the (UTF_8
> encoded) addr-spec.

This is perhaps not as RFC 5321 specifies e-mail addresses[1]. I see:

-----------------------8<--------------->8-----------------------
   Mailbox        = Local-part "@" ( Domain / address-literal )

   Local-part     = Dot-string / Quoted-string
                  ; MAY be case-sensitive


   Dot-string     = Atom *("."  Atom)

   Atom           = 1*atext

   Quoted-string  = DQUOTE *QcontentSMTP DQUOTE

   QcontentSMTP   = qtextSMTP / quoted-pairSMTP

   quoted-pairSMTP  = %d92 %d32-126
                    ; i.e., backslash followed by any ASCII
                    ; graphic (including itself) or SPace

   qtextSMTP      = %d32-33 / %d35-91 / %d93-126
                  ; i.e., within a quoted string, any
                  ; ASCII graphic or space is permitted
                  ; without blackslash-quoting except
                  ; double-quote and the backslash itself.
-----------------------8<--------------->8-----------------------

atext is defined in RFC 5322: [2]

-----------------------8<--------------->8-----------------------
 atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"
-----------------------8<--------------->8-----------------------

This seems to suggest the following e-mail addresses:

"Peter at work"@example.org
"Unmatched\"@messing-with-you"@example.org

It would also seem to suggest that people doing this deserve not being
able to receive e-mail ;-).

HTH,

Peter.

[1] https://tools.ietf.org/html/rfc5321#section-4.1.2
[2] https://tools.ietf.org/html/rfc5322#section-3.2.3

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From vinay_sajip at yahoo.co.uk  Mon Nov  7 13:23:53 2016
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Mon, 7 Nov 2016 12:23:53 +0000 (UTC)
Subject: Using loopback pin entry with GnuPG 2.1
In-Reply-To: <878tsyrn6v.fsf@wheatstone.g10code.de>
References: <574777160.1243146.1476982583037.ref@mail.yahoo.com>
 <574777160.1243146.1476982583037@mail.yahoo.com>
 <878ttegr3s.fsf@wheatstone.g10code.de>
 <868322669.288810.1478254275137@mail.yahoo.com>
 <87twbnwdis.fsf@wheatstone.g10code.de>
 <325432173.1102143.1478286874607@mail.yahoo.com>
 <87ins3t2k6.fsf@wheatstone.g10code.de>
 <543274049.1230443.1478299346005@mail.yahoo.com>
 <874m3mtm5h.fsf@wheatstone.g10code.de>
 <1487469558.1453501.1478340374239@mail.yahoo.com>
 <878tsyrn6v.fsf@wheatstone.g10code.de>
Message-ID: <2038382105.3548525.1478521433373@mail.yahoo.com>

Dear Werner,


>> As I mentioned in my post, the allow-loopback-pinentry option has
>> already been specified in gpg-agent.conf. As to the version of GnuPG

> Not in the version of the agent you are running.  Look at the log
> message:


$ gpg-agent --version 
gpg-agent (GnuPG) 2.1.11 
libgcrypt 1.6.5 
Copyright (C) 2016 Free Software Foundation, Inc. 


That's the version that's running, and gpg-agent.conf is in ~/.gnupg and /home/vinay/projects/python-gnupg/keys - which seem to be the only two relevant locations.

Is the code you posted from 2.1.11, or a more recent version?

Regards,

Vinay Sajip


From Juergen.Schaepker at giepa.de  Mon Nov  7 13:58:39 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Mon, 7 Nov 2016 12:58:39 +0000
Subject: AW: Web Key Directory handling of IDN
In-Reply-To: <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
 <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>
Message-ID: <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>

Hi,

>I don't think the standard is ambiguous about this: it says that you map
>uppercase ASCII to lowercase and leave the rest unharmed.

The current draft WKD will only be able to find non-ASCII address hashes by pure chance. MUAs can look for the hashes of ?yvind at something.net and ?yvind at something.net and only for one WKD will return a result.

>Now suppose WKD would match more than the mail server would. I think
>this is a real problem. Suppose you have <j?rgen.sch?pker at example.org>.
>The mail server at example.org doesn't do any more than lowercasing
>ASCII uppercase. This means I can still register
><jurgen.schapker at example.org>, and use that address. Now I create an
>OpenPGP key with both e-mail addresses as UID's, and register it through
>example.org's Web Key Directory. If a search for the local part
>j?rgen.sch?pker would search for jurgen.schapker instead, people would
>end up downloading my OpenPGP key, not yours, and would then use it
>since it holds the correct UID.

"a" is not the normalized form of "?". To get a clearer picture of an IDNA2003 conversion try http://www.dotarai.com/idna/

J?rgen and j?rgen convert to xn--jrgen-kva 
???? and ????  convert to xn--ss-uia5e3a 
?mit.Emino?lu and ?mit.emino?lu convert to xn--mit-goa.xn--eminolu-rbb
?yvind.Fahlstr?m@?cker-H??ler.de and ?yvind.fahlstr?m@?cker-h??ler.de convert to xn--yvind-iua.xn--fahlstrm-t4a at xn--cker-hssler-q8a91a.de
?yvind.Br?kke@?cker-H??ler.de and ?yvind.br?kke@?cker-h??ler.de convert to xn--yvind-uua.xn--brkke-tra at xn--cker-hssler-q8a91a.de

The point is having a normalized string on both client and server.

Of course IDNA2003 is not perfect (e.g. for ?) but just ignoring non-ASCII upper/lower case is not an option.

>> wkd.unrelated.com. At least from one of those domains redirection is
>> done by a request-modifying reverse proxy, e.g. a.net requests reach
>> the WKD with HOST reverse.nota.com.

>If you're redirecting anyway, you can easily solve this. 

No. Not if you don't control the redirecting server. We should not assume that the person attempting to introduce/install WKD has control over all servers involved, specifically not in international companies with all kinds of political bullshit involved. You simply cannot rely on the request host being unmodified and you cannot rely on finding a single god admin for all domains that should be served by a single WKD.

If there is no valid technical reason for a requirement that will limit a standard's applicability, it should not be in the standard.


Best regards,
JS


From peter at digitalbrains.com  Mon Nov  7 15:41:40 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 7 Nov 2016 15:41:40 +0100
Subject: Web Key Directory handling of IDN
In-Reply-To: <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
 <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>
 <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>
Message-ID: <e0ea776a-560c-1190-15c5-960de0dc8a59@digitalbrains.com>

On 07/11/16 13:58, J?rgen Sch?pker wrote:
> The current draft WKD will only be able to find non-ASCII address
> hashes by pure chance. MUAs can look for the hashes of
> ?yvind at something.net and ?yvind at something.net and only for one WKD
> will return a result.

And what does the mail server do? It is not clear to me at all that the
mail server fares any better. Are you working here with a specific MTA
application in mind that happens to misuse IDN for normalizing local
parts? (IDN is for domain names, not other UTF-8 encoded data)

Do you happen to know how some major MTA's (Exim, Postfix, Sendmail,
Exchange[1]) handle this?

> "a" is not the normalized form of "?". To get a clearer picture of an
> IDNA2003 conversion try http://www.dotarai.com/idna/
> 
> J?rgen and j?rgen convert to xn--jrgen-kva

I don't see your point. So I register the e-mail address xn--jrgen-kva
instead of jurgen. It was just an example, the details are freely
exchangeable and my point stands.

> No. Not if you don't control the redirecting server.

Let's agree to disagree.

> you cannot rely on finding a single god admin for all domains that
> should be served by a single WKD.

I don't follow this single admin line of thought. I simply do not know
what you mean.

> If there is no valid technical reason for a requirement that will
> limit a standard's applicability, it should not be in the standard.

I agree. I just seem to disagree on the validity of the technical
reasons discussed.

Cheers,

Peter.

[1] Exchange can't even implement the most basic SMTP things correctly,
so I'm not so sure it should qualify for a look at it. Just the other
day I received some backscatter spam from an Exchange server. It was
doing a bounce report for a bounce report. The original bounce report
correctly had the null return route, but Exchange still thought it a
good idea to generate another bounce report for it, which it sent from a
non-null return route. In different circumstances, the mail could have
bounced around indefinitely. Throw in a non-fatal SMTP error somewhere
and it could have grown exponentially on the retries. I've heard of a
server going down under the load in this precise circumstance because
the Exchange server on the other end not even got this totally basic
null return route stuff right, which is very explicitly in the standard,
including the comment that it is precisely to prevent endless bouncing
around.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From Juergen.Schaepker at giepa.de  Mon Nov  7 16:00:31 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Mon, 7 Nov 2016 15:00:31 +0000
Subject: AW: Web Key Directory handling of IDN
In-Reply-To: <e0ea776a-560c-1190-15c5-960de0dc8a59@digitalbrains.com>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
 <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>
 <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>
 <e0ea776a-560c-1190-15c5-960de0dc8a59@digitalbrains.com>
Message-ID: <89deccf2275e4272b7ce068ee5fd66cd@DVWIGUPEX2013.intern.giepa.de>

Hi,

>> The current draft WKD will only be able to find non-ASCII address
>> hashes by pure chance. MUAs can look for the hashes of
>> ?yvind at something.net and ?yvind at something.net and only for one WKD
>> will return a result.

>And what does the mail server do? It is not clear to me at all that the
>mail server fares any better. Are you working here with a specific MTA
>application in mind that happens to misuse IDN for normalizing local
>parts? (IDN is for domain names, not other UTF-8 encoded data)

Please read up on https://en.wikipedia.org/wiki/International_email

The following are all valid international email addresses:

  ??@??.??                 (Chinese, Unicode)
  ??????????@??????.???           (Hindi, Unicode)
  ????@???????.???             (Ukrainian, Unicode)
  ????@???????.???             (Greek, Unicode)
  D?rte at S?rensen.example.com   (German, Unicode)

>Do you happen to know how some major MTA's (Exim, Postfix, Sendmail,
>Exchange[1]) handle this?

Apparently there are lots of MTAs that support it. There is a standard SMTPUTF8 in RFC 6531.

List of supporting servers

    Postfix (version 3.0 and later)[8]
    Momentum (versions 4.1[9] and 3.6.5, and later)
    Sendmail (Under development)
    Exim (experimental as of the 4.86 release)

>> J?rgen and j?rgen convert to xn--jrgen-kva

 >I don't see your point. So I register the e-mail address xn--jrgen-kva
>instead of jurgen. It was just an example, the details are freely
>exchangeable and my point stands.

In other words: if the standard doesn't work in reality, change reality.

No.

The standard must work in the context of other existing standards. People already use IDN email so the WKD standard must support it unless it is intended to be incompatible from the get-go.

It's not about registering an email address. In businesses most people are assigned addresses. And the concern is the lookup. A contact's email address might be typed in any upper/lower case combination. The MUA needs to be able to type in as search address any upper/lower case variant of D?RTE.WhAt?v??@?tt?.com and still get the result for that address from the WKD.

>> No. Not if you don't control the redirecting server.

>Let's agree to disagree.

You can't successfully disagree with reality.

>> you cannot rely on finding a single god admin for all domains that
>> should be served by a single WKD.

>I don't follow this single admin line of thought. I simply do not know
>what you mean.

I don't think you are arguing honestly here. You can't imagine control issues in international companies with different IT departments in different countries?  You can't imagine a small office using a cheap webhoster that doesn't allow redirection the way you want?

I think you should remember that a standard should work in all scenarios, even those you personally have no experience with.


Best regards,
JS


From peter at digitalbrains.com  Mon Nov  7 16:23:25 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 7 Nov 2016 16:23:25 +0100
Subject: Web Key Directory handling of IDN
In-Reply-To: <89deccf2275e4272b7ce068ee5fd66cd@DVWIGUPEX2013.intern.giepa.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
 <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>
 <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>
 <e0ea776a-560c-1190-15c5-960de0dc8a59@digitalbrains.com>
 <89deccf2275e4272b7ce068ee5fd66cd@DVWIGUPEX2013.intern.giepa.de>
Message-ID: <69d3dc1d-717e-1806-d963-d9ab23c97cbd@digitalbrains.com>

On 07/11/16 16:00, J?rgen Sch?pker wrote:
> Apparently there are lots of MTAs that support it. There is a
> standard SMTPUTF8 in RFC 6531.

I asked what normalization they do on the local part, not whether they
support it.

> In other words: if the standard doesn't work in reality, change
> reality.

I'm saying that there is an impersonation problem with your proposal. If
you register <j?rgen at example.org>, I could register
<xn--jrgen-kva at example.org> and get my OpenPGP key in the WKD instead of
you.

Please actually read what I am saying without resorting to cheap shots
that frankly are far off the bow. And yes, I'm mixing expressions :-).
Not sure it holds up to close scrutiny, but I thought it was nice.

If you did not understand something I said, just ask.

> You can't successfully disagree with reality.

That's funny, it's something I observe all the time! One word: atheist.
What I also observe is my unwillingness to conduct discussions when this
is the way it is done.

>> I don't follow this single admin line of thought. I simply do not
>> know what you mean.
> 
> I don't think you are arguing honestly here.

I'm not arguing at all. I'm just asking you to clarify what you meant
because I didn't understand.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From Juergen.Schaepker at giepa.de  Mon Nov  7 16:54:20 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Mon, 7 Nov 2016 15:54:20 +0000
Subject: AW: Web Key Directory handling of IDN
In-Reply-To: <69d3dc1d-717e-1806-d963-d9ab23c97cbd@digitalbrains.com>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
 <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>
 <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>
 <e0ea776a-560c-1190-15c5-960de0dc8a59@digitalbrains.com>
 <89deccf2275e4272b7ce068ee5fd66cd@DVWIGUPEX2013.intern.giepa.de>
 <69d3dc1d-717e-1806-d963-d9ab23c97cbd@digitalbrains.com>
Message-ID: <ac144de0470f4183b27bb902499620f3@DVWIGUPEX2013.intern.giepa.de>

Hi,

>I asked what normalization they do on the local part, not whether they
>support it.

Apparently NFC is used: 

https://tools.ietf.org/html/rfc6532
https://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms

>> In other words: if the standard doesn't work in reality, change
>> reality.

>I'm saying that there is an impersonation problem with your proposal. If
>you register <j?rgen at example.org>, I could register
><xn--jrgen-kva at example.org> and get my OpenPGP key in the WKD instead of
>you.

This can't happen when hashes are calculated from normalized full email addresses and uniqueness is checked by WKD/WKS before storing a new hash. It also cannot happen if email servers check for such collisions before registering addresses. Most domain registrators usually (offer to) register both domains automatically.

>Please actually read what I am saying without resorting to cheap shots
>that frankly are far off the bow. And yes, I'm mixing expressions :-).
>Not sure it holds up to close scrutiny, but I thought it was nice.

I'm sorry if my words seemed like cheap shots to you, they are not intended that way. But I do believe that a productive discussion needs intellectual honesty and curiosity from all. To just disregard scenarios and use cases one personally might not have thought about before seems somewhat lazy to me.


Best regards,
JS


From peter at digitalbrains.com  Mon Nov  7 18:19:20 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 7 Nov 2016 18:19:20 +0100
Subject: Web Key Directory handling of IDN
In-Reply-To: <ac144de0470f4183b27bb902499620f3@DVWIGUPEX2013.intern.giepa.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
 <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>
 <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>
 <e0ea776a-560c-1190-15c5-960de0dc8a59@digitalbrains.com>
 <89deccf2275e4272b7ce068ee5fd66cd@DVWIGUPEX2013.intern.giepa.de>
 <69d3dc1d-717e-1806-d963-d9ab23c97cbd@digitalbrains.com>
 <ac144de0470f4183b27bb902499620f3@DVWIGUPEX2013.intern.giepa.de>
Message-ID: <151de7f1-f745-a2dd-15f1-339be26b17c0@digitalbrains.com>

On 07/11/16 16:54, J?rgen Sch?pker wrote:
> [...] intellectual honesty and curiosity from all. To just disregard
> scenarios and use cases one personally might not have thought about
> before seems somewhat lazy to me.

Never attribute to malice that which is adequately explained by
stupidity (Hanlon's Razor).

I'm done with this discussion. Goodbye.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From Juergen.Schaepker at giepa.de  Mon Nov  7 18:41:22 2016
From: Juergen.Schaepker at giepa.de (=?utf-8?B?SsO8cmdlbiBTY2jDpHBrZXI=?=)
Date: Mon, 7 Nov 2016 17:41:22 +0000
Subject: Web Key Directory handling of IDN
Message-ID: <4818a4f5fdfd426c871c9deca42a7b07@DVWIGUPEX2013.intern.giepa.de>

Hi,

> I'm done with this discussion. Goodbye.

Well, sorry again if my words were capable of being misunderstood. I believe we are all lazy and stupid, to some degree.

But maybe you could still just answer the one important question: should the standard allow for case-insensitive searches of non-ASCII email addresses?


Best regards,
JS



From rfkrocktk at gmail.com  Mon Nov  7 19:08:15 2016
From: rfkrocktk at gmail.com (Naftuli Kay)
Date: Mon, 7 Nov 2016 10:08:15 -0800
Subject: GPG Agent: No detach not working?
Message-ID: <CAPTk+sbeJng_EG6VuMLjJwTt6NVU2r74FdoguQGPyN5=pGJy0g@mail.gmail.com>

I'm looking to run my gpg-agent in a SystemD user unit file like so:

[Unit]
Description=GnuPG Agent

[Service]
Type=simple
ExecStart=/usr/bin/gpg-agent --no-detach --daemon
Restart=always
RestartSec=10s

[Install]
WantedBy=multi-user.target


The problem here is that the gpg-agent detaches immediately, despite
having the --no-detach flag set. My agent is:

$ gpg-agent --version
gpg-agent (GnuPG) 2.1.11
libgcrypt 1.6.5
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Running on Ubuntu 16.04. I'd like to have it run in the foreground so
that its output is captured by the SystemD journal so I can review.

I can get it to work if I set it to Type=forking, but I specifically
want it to run in the foreground.


From wk at gnupg.org  Mon Nov  7 18:01:56 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 07 Nov 2016 18:01:56 +0100
Subject: Question to WKD-Feature
In-Reply-To: <1702876.boSI1JWCEu@kymo.gruen> (Bernhard Reiter's message of
 "Mon, 07 Nov 2016 09:14:57 +0100")
References: <bad1978d-bc5b-91a4-0a22-e0a1cd23e119@heinlein-support.de>
 <877f8jui5i.fsf@wheatstone.g10code.de> <1702876.boSI1JWCEu@kymo.gruen>
Message-ID: <87wpgfnrzv.fsf@wheatstone.g10code.de>

On Mon,  7 Nov 2016 09:14, bernhard at intevation.de said:

> without looking into the contents? They could just deliver the ascii 
> armored pubkey they've gotten from the client via auth-summit.

They can't do that because they need to filter the key first.  It is
important to remove all mail addresses  but  the one which is expected
under this entry in the WKD.

Consider a client which imports from the WKD or DANE without filtering
(which a client should also do that) and further does not track which
user ID has been received via WKD.  That would spoil the local keyring
with unverified mail addresses.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161107/ff05980d/attachment.sig>

From wk at gnupg.org  Mon Nov  7 20:17:19 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 07 Nov 2016 20:17:19 +0100
Subject: AW: Web Key Directory handling of IDN
In-Reply-To: <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>
 (=?utf-8?Q?=22J=C3=BCrgen_Sch=C3=A4pker=22's?= message of "Mon, 7 Nov 2016
 12:58:39 +0000")
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
 <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>
 <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>
Message-ID: <877f8fnlq8.fsf@wheatstone.g10code.de>

On Mon,  7 Nov 2016 13:58, Juergen.Schaepker at giepa.de said:

> The current draft WKD will only be able to find non-ASCII address
> hashes by pure chance. MUAs can look for the hashes of
> ?yvind at something.net and ?yvind at something.net and only for one WKD
> will return a result.

Well, if a user decides to use non-ASCII adresses they need to live with
the strict but impractical rules of RFC5322 which says that case folding
may or may not happen.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161107/5e4a4209/attachment.sig>

From dkg at fifthhorseman.net  Tue Nov  8 04:01:55 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 07 Nov 2016 22:01:55 -0500
Subject: [PINENTRY PATCH] gnome3: Fall back to curses if screensaver is
 locked.
In-Reply-To: <87y40w1782.wl-neal@walfield.org>
References: <20161106071704.16758-1-dkg@fifthhorseman.net>
 <87y40w1782.wl-neal@walfield.org>
Message-ID: <87a8davfmk.fsf@alice.fifthhorseman.net>

On Sun 2016-11-06 19:09:17 -0500, Neal H. Walfield wrote:
> Thanks for working on this.  I've applied it with a small change,
> which we discussed offline.

Thanks!

> For the record, this doesn't detect if xscreensaver or something
> similar is running and fall back to the curses interface, it only
> works for GNOME screensaver.  But, it is reasonable to expect that
> anyone who uses pinentry-gnome3 will be running GNOME screensaver and
> not xscreensaver.

Hm, it's possible that other screensavers can report their state over
d-bus (kde screensavers?) -- though i don't think xscreensaver is among
them, since it doesn't appear to use dbus.  if anyone wants to propose a
patch for detecting another locked d-bus-enabled screensaver, i'm happy
to review 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/20161107/dd6e6313/attachment-0001.sig>

From m at tthias.eu  Tue Nov  8 09:41:04 2016
From: m at tthias.eu (Matthias Wimmer)
Date: Tue, 8 Nov 2016 09:41:04 +0100
Subject: Web Key Directory handling of IDN
In-Reply-To: <877f8fnlq8.fsf@wheatstone.g10code.de>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
 <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>
 <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>
 <877f8fnlq8.fsf@wheatstone.g10code.de>
Message-ID: <20161108084104.rrhyoz6ldzlfj6ro@atwork.matthias.wimmer.name>

Hi,


El 2016-11-07 20:17:19, Werner Koch escribi?:
> Well, if a user decides to use non-ASCII adresses they need to live with
> the strict but impractical rules of RFC5322 which says that case folding
> may or may not happen.

In think that in the case the following rule from RFC6530, section 10.1
applies:

   For the particular case of mailbox names that contain non-ASCII
   characters in the local part, domain part, or both, special attention
   MUST be paid to Unicode normalization [Unicode-UAX15], in part
   because Unicode strings may be normalized by other processes
   independent of what a mail protocol specifies (this is exactly
   analogous to what may happen with quoting and dequoting in
   traditional addresses).  Consequently, the following principles are
   offered as advice to those who are selecting names for mailboxes:

   o  In general, it is wise to support addresses in Normalized form,
      using at least Normalization Form NFC.  Except in circumstances in
      which NFKC would map characters together that the parties
      responsible for the destination mail server would prefer to be
      kept distinguishable, supporting the NFKC-conformant form would
      yield even more predictable behavior for the typical user.

   o  It will usually be wise to support other forms of the same local-
      part string, either as aliases or by normalization of strings
      reaching the delivery server: the sender should not be depended
      upon to send the strings in normalized form.

   o  Stated differently and in more specific terms, the rules of the
      protocol for local-part strings essentially provide that:

      *  Unnormalized strings are valid, but sufficiently bad practice
         that they may not work reliably on a global basis.  Servers
         should not depend on clients to send normalized forms but
         should be aware that procedures on client machines outside the
         control of the MUA may cause normalized strings to be sent
         regardless of user intent.

      *  C0 (and presumably C1) controls (see The Unicode Standard
         [Unicode]) are prohibited, the first in RFC 5321 and the second
         by an obvious extension from it [RFC5198].

      *  Other kinds of punctuation, spaces, etc., are risky practice.
         Perhaps they will work, and SMTP receiver code is required to
         handle them without severe errors (even if such strings are not
         accepted in addresses to be delivered on that server), but
         creating dependencies on them in mailbox names that are chosen
         is usually a bad practice and may lead to interoperability
         problems.


Regards,
Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: </pipermail/attachments/20161108/2c37712f/attachment.sig>

From peter at digitalbrains.com  Tue Nov  8 13:35:04 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 8 Nov 2016 13:35:04 +0100
Subject: Web Key Directory handling of IDN
In-Reply-To: <20161108084104.rrhyoz6ldzlfj6ro@atwork.matthias.wimmer.name>
References: <1DC3C8C67280FB4C9A402CB6DB1358F51BCCB65C03@s2008sbs.intern.giepa.de>
 <faa3432c-5d1e-28f2-016e-8765aac8c815@digitalbrains.com>
 <d3a189c5-d1a4-e000-2f51-e6ee4f1788a2@digitalbrains.com>
 <emb6f54251-af47-4480-ac69-efb04dc11c6f@titan>
 <56e8c203-e0af-2574-844e-5bc4f6b62924@digitalbrains.com>
 <268f46e449394a2b9763c81ce3ff00b1@DVWIGUPEX2013.intern.giepa.de>
 <877f8fnlq8.fsf@wheatstone.g10code.de>
 <20161108084104.rrhyoz6ldzlfj6ro@atwork.matthias.wimmer.name>
Message-ID: <27f3338f-7b35-2195-dc68-0ca0e7ad5aa2@digitalbrains.com>

Wouldn't the authors of the various mail plugins have quite some
experience with matching of user-provided e-mail addresses to user ID's
on OpenPGP keys? It seems like the same type of matching needs to be
done there, and they might have gotten bug reports or feature requests
of people who encountered issues with the plugin matching a key to a
mail they typed.

This of course depends on the scale of adoption of OpenPGP as it is now.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From aheinecke at intevation.de  Tue Nov  8 17:38:38 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Tue, 08 Nov 2016 17:38:38 +0100
Subject: [GPGME PATCH] core: Use gpgrt locking for thread safety
Message-ID: <3084075.QhVPcxW0Tr@esus>

* configure.ac: Require libgpg-error 1.17
* doc/gpgme.texi: Document removed neccessity for thread
safe gpgme flavours.
* src/sema.h (DEFINE_GLOBAL_LOCK),
(DEFINE_STATIC_LOCK, INIT_LOCK, DECLARE_LOCK)
(DESTROY_LOCK, LOCK, UNLOCK): Change to gpgrt equivalents.
* src/posix-sema.c, src/w32-sema.c: Removed.
* src/Makefile.am: Update accordingly.
* src/ath.c, src/ath.h (ath_mutex_init)
(ath_mutex_destroy, ath_mutex_lock, ath_mutex_unlock): Removed.
* src/ath.h (ATH_MUTEX_INITIALIZER): Removed.
* src/version.c (do_subsystem_inits): sema_subsystem_init is
no longer required.
* src/Makefile.am
* tests/gpg/Makefile.am: Add new threading tests.
(t_thread1_LDADD, t_cancel_LDADD):
Use just gpgme.
* tests/gpg/t-thread-keylist-verify.c,
tests/gpg/t-thread-keylist.c: New.

--
This makes the "default" flavor as thread safe as the
pthread flavor.

As the cpp bindings link against libgpgme
and not libgpgme-pthread this fixes threading problems
with them.

Using gpgrt locks instead of pthread locks also removes
the neccessity to link pthread directly to gpgme and
have a different, thread safe flavor of gpgme.

libgpgme-pthread is still installed for compatibility but
is now exactly the same as libgpgme.
---
 configure.ac                        |   3 +-
 doc/gpgme.texi                      |  36 ++-----
 src/Makefile.am                     |  34 +++----
 src/ath-pthread.c                   | 188 ------------------------------------
 src/ath.c                           |  51 ----------
 src/ath.h                           |  13 ---
 src/posix-sema.c                    |  68 -------------
 src/sema.h                          |  43 ++-------
 src/version.c                       |   1 -
 src/w32-sema.c                      | 117 ----------------------
 tests/gpg/Makefile.am               |   9 +-
 tests/gpg/t-thread-keylist-verify.c | 129 +++++++++++++++++++++++++
 tests/gpg/t-thread-keylist.c        |  76 +++++++++++++++
 13 files changed, 240 insertions(+), 528 deletions(-)
 delete mode 100644 src/ath-pthread.c
 delete mode 100644 src/posix-sema.c
 delete mode 100644 src/w32-sema.c
 create mode 100644 tests/gpg/t-thread-keylist-verify.c
 create mode 100644 tests/gpg/t-thread-keylist.c

diff --git a/configure.ac b/configure.ac
index b52f214..031b83c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -71,7 +71,7 @@ LIBQGPGME_LT_REVISION=0
 GPGME_CONFIG_API_VERSION=1
 ##############################################
 
-NEED_GPG_ERROR_VERSION=1.11
+NEED_GPG_ERROR_VERSION=1.17
 NEED_LIBASSUAN_API=2
 NEED_LIBASSUAN_VERSION=2.0.2
 
@@ -905,7 +905,6 @@ echo "
 
         UI Server:         $uiserver
         FD Passing:        $use_descriptor_passing
-        GPGME Pthread:     $have_pthread
 
         Language bindings: ${enabled_languages_v:-$enabled_languages}
 "
diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index a70418d..f4ec9f6 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -458,12 +458,6 @@ specifying both options to @command{gpgme-config}:
 gcc -o foo foo.c `gpgme-config --cflags --libs`
 @end example
 
-If you want to link to one of the thread-safe versions of
- at acronym{GPGME}, you must specify the @option{--thread} option before
-any other option to select the thread package you want to link with.
-Supported thread packages are @option{--thread=pth} and
- at option{--thread=pthread}.
-
 If you need to detect the installed language bindings you can use list
 them using:
 
@@ -614,7 +608,9 @@ that can be used with GNU Pth, and defines @code{GPGME_PTH_CFLAGS} and
 
 @code{AM_PATH_GPGME_PTHREAD} checks for the version of @acronym{GPGME}
 that can be used with the native pthread implementation, and defines
- at code{GPGME_PTHREAD_CFLAGS} and @code{GPGME_PTHREAD_LIBS}.
+ at code{GPGME_PTHREAD_CFLAGS} and @code{GPGME_PTHREAD_LIBS}. Since
+verison 1.7.2 this is no longer required to GPGME_PTHREAD as
+ at acronym{GPGME} itself is thread safe.
 
 This macro searches for @command{gpgme-config} along the PATH.  If
 you are cross-compiling, it is useful to set the environment variable
@@ -814,32 +810,12 @@ application is multi-threaded, and you install a signal action for
 @cindex thread-safeness
 @cindex multi-threading
 
-The @acronym{GPGME} library is not entirely thread-safe, but it can
-still be used in a multi-threaded environment if some care is taken.
-If the following requirements are met, there should be no race
-conditions to worry about:
+The @acronym{GPGME} library is mostly thread-safe, an can be used
+in a mulithreaded environment but there are some requirements
+for mutlithreaded use:
 
 @itemize @bullet
 @item
- at acronym{GPGME} supports the thread libraries pthread and GNU Pth.
-The support for this has to be enabled at compile time.
- at acronym{GPGME} will automatically detect the location in which the
-thread libraries are installed and activate the support for them at
-build time.
-
-Support for other thread libraries is very easy to add.  Please
-contact us if you have the need.
-
- at item
-If you want to use @acronym{GPGME} with threads, you must link to the
-right version of the library.  The name of the right library is
- at code{libgpgme-} followed by the name of the thread package you use.
-For example, if you use GNU Pth, the right name is
- at code{libgpgme-pth}.  Use the Automake macros or
- at command{gpgme-config} program for simplicity.
-
-
- at item
 The function @code{gpgme_check_version} must be called before any
 other function in the library, because it initializes the thread
 support subsystem in @acronym{GPGME}.  To achieve this in
diff --git a/src/Makefile.am b/src/Makefile.am
index eddd192..0512ce1 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -28,20 +28,13 @@ nodist_include_HEADERS = gpgme.h
 
 bin_PROGRAMS = gpgme-tool
 
-if HAVE_PTHREAD
-ltlib_gpgme_pthread = libgpgme-pthread.la
-else
-ltlib_gpgme_pthread =
-endif
-
 if BUILD_W32_GLIB
 ltlib_gpgme_glib = libgpgme-glib.la
 else
 ltlib_gpgme_glib =
 endif
 
-lib_LTLIBRARIES = libgpgme.la $(ltlib_gpgme_glib) $(ltlib_gpgme_qt) \
-	$(ltlib_gpgme_pthread)
+lib_LTLIBRARIES = libgpgme.la libgpgme-pthread.la $(ltlib_gpgme_glib)
 
 if HAVE_LD_VERSION_SCRIPT
 libgpgme_version_script_cmd = -Wl,--version-script=$(srcdir)/libgpgme.vers
@@ -50,10 +43,10 @@ libgpgme_version_script_cmd =
 endif
 
 if HAVE_DOSISH_SYSTEM
-system_components = w32-util.c w32-sema.c
+system_components = w32-util.c
 system_components_not_extra = w32-io.c
 else
-system_components = ath.h posix-util.c posix-sema.c posix-io.c
+system_components = ath.h posix-util.c posix-io.c
 system_components_not_extra =
 endif
 
@@ -93,12 +86,10 @@ main_sources =								\
 	engine-spawn.c 	                                                \
 	gpgconf.c queryswdb.c						\
 	sema.h priv-io.h $(system_components) sys-util.h dirinfo.c	\
-	debug.c debug.h gpgme.c version.c error.c
-
-libgpgme_la_SOURCES = $(main_sources)					\
+	debug.c debug.h gpgme.c version.c error.c \
 	ath.h ath.c $(system_components_not_extra)
-libgpgme_pthread_la_SOURCES = $(main_sources)				\
-	ath.h ath-pthread.c $(system_components_not_extra)
+
+libgpgme_la_SOURCES = $(main_sources)
 
 if BUILD_W32_GLIB
 libgpgme_glib_la_SOURCES = $(main_sources) ath.h ath.c w32-glib-io.c
@@ -163,13 +154,12 @@ libgpgme_la_DEPENDENCIES = @LTLIBOBJS@ $(srcdir)/libgpgme.vers $(gpgme_deps)
 libgpgme_la_LIBADD = $(gpgme_res) @LIBASSUAN_LIBS@ @LTLIBOBJS@ \
 	             @GPG_ERROR_LIBS@
 
-libgpgme_pthread_la_LDFLAGS = \
-        $(no_undefined) $(export_symbols) $(extra_ltoptions) \
-	$(libgpgme_version_script_cmd) -version-info \
-	@LIBGPGME_LT_CURRENT@:@LIBGPGME_LT_REVISION@:@LIBGPGME_LT_AGE@
-libgpgme_pthread_la_DEPENDENCIES = @LTLIBOBJS@ $(srcdir)/libgpgme.vers
-libgpgme_pthread_la_LIBADD = $(gpgme_res) @LIBASSUAN_LIBS@ @LTLIBOBJS@ \
-	-lpthread @GPG_ERROR_LIBS@
+# This should probably be removed at some point as libgpgme_pthread
+# is the same as libgpgme
+libgpgme_pthread_la_SOURCES = $(libgpgme_la_SOURCES)
+libgpgme_pthread_la_LDFLAGS = $(libgpgme_la_LDFLAGS)
+libgpgme_pthread_la_DEPENDENCIES = $(libgpgme_la_DEPENDENCIES)
+libgpgme_pthread_la_LIBADD = $(libgpgme_la_LIBADD)
 
 if BUILD_W32_GLIB
 libgpgme_glib_la_LDFLAGS = \
diff --git a/src/ath-pthread.c b/src/ath-pthread.c
deleted file mode 100644
index 47b38ee..0000000
--- a/src/ath-pthread.c
+++ /dev/null
@@ -1,188 +0,0 @@
-/* ath-pthread.c - pthread module for self-adapting thread-safeness library
-   Copyright (C) 2002, 2003, 2004 g10 Code GmbH
-
-   This file is part of GPGME.
-
-   GPGME is free software; you can redistribute it and/or modify it
-   under the terms of the GNU Lesser General Public License as
-   published by the Free Software Foundation; either version 2.1 of
-   the License, or (at your option) any later version.
-
-   GPGME is distributed in the hope that it will be useful, but
-   WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-   Lesser General Public License for more details.
-
-   You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, write to the Free Software
-   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
-   02111-1307, USA.  */
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-
-#include <stdlib.h>
-#include <errno.h>
-#ifdef HAVE_UNISTD_H
-# include <unistd.h>
-#endif
-#ifdef HAVE_SYS_SELECT_H
-# include <sys/select.h>
-#else
-# ifdef HAVE_SYS_TIME_H
-#  include <sys/time.h>
-# endif
-#endif
-#include <sys/types.h>
-#include <sys/wait.h>
-
-#include <pthread.h>
-
-#include "gpgme.h"
-
-#include "ath.h"
-
-
-/* The lock we take while checking for lazy lock initialization.  */
-static pthread_mutex_t check_init_lock = PTHREAD_MUTEX_INITIALIZER;
-
-/* Initialize the mutex *PRIV.  If JUST_CHECK is true, only do this if
-   it is not already initialized.  */
-static int
-mutex_pthread_init (ath_mutex_t *priv, int just_check)
-{
-  int err = 0;
-
-  if (just_check)
-    pthread_mutex_lock (&check_init_lock);
-  if (!*priv || !just_check)
-    {
-      pthread_mutex_t *lock = malloc (sizeof (pthread_mutex_t));
-      if (!lock)
-	err = ENOMEM;
-      if (!err)
-	{
-	  err = pthread_mutex_init (lock, NULL);
-	  if (err)
-	    free (lock);
-	  else
-	    *priv = (ath_mutex_t) lock;
-	}
-    }
-  if (just_check)
-    pthread_mutex_unlock (&check_init_lock);
-  return err;
-}
-
-
-void
-ath_init (void)
-{
-  /* Nothing to do.  */
-}
-
-
-uintptr_t
-ath_self (void)
-{
-  return (uintptr_t) pthread_self ();
-}
-
-
-int
-ath_mutex_init (ath_mutex_t *lock)
-{
-  return mutex_pthread_init (lock, 0);
-}
-
-
-int
-ath_mutex_destroy (ath_mutex_t *lock)
-{
-  int err = mutex_pthread_init (lock, 1);
-  if (!err)
-    {
-      err = pthread_mutex_destroy ((pthread_mutex_t *) *lock);
-      free (*lock);
-    }
-  return err;
-}
-
-
-int
-ath_mutex_lock (ath_mutex_t *lock)
-{
-  int ret = mutex_pthread_init (lock, 1);
-  if (ret)
-    return ret;
-
-  return pthread_mutex_lock ((pthread_mutex_t *) *lock);
-}
-
-
-int
-ath_mutex_unlock (ath_mutex_t *lock)
-{
-  int ret = mutex_pthread_init (lock, 1);
-  if (ret)
-    return ret;
-
-  return pthread_mutex_unlock ((pthread_mutex_t *) *lock);
-}
-
-
-gpgme_ssize_t
-ath_read (int fd, void *buf, size_t nbytes)
-{
-  return read (fd, buf, nbytes);
-}
-
-
-gpgme_ssize_t
-ath_write (int fd, const void *buf, size_t nbytes)
-{
-  return write (fd, buf, nbytes);
-}
-
-
-gpgme_ssize_t
-ath_select (int nfd, fd_set *rset, fd_set *wset, fd_set *eset,
-	    struct timeval *timeout)
-{
-  return select (nfd, rset, wset, eset, timeout);
-}
-
-
-gpgme_ssize_t
-ath_waitpid (pid_t pid, int *status, int options)
-{
-  return waitpid (pid, status, options);
-}
-
-
-int
-ath_accept (int s, struct sockaddr *addr, socklen_t *length_ptr)
-{
-  return accept (s, addr, length_ptr);
-}
-
-
-int
-ath_connect (int s, const struct sockaddr *addr, socklen_t length)
-{
-  return connect (s, addr, length);
-}
-
-int
-ath_sendmsg (int s, const struct msghdr *msg, int flags)
-{
-  return sendmsg (s, msg, flags);
-}
-
-
-int
-ath_recvmsg (int s, struct msghdr *msg, int flags)
-{
-  return recvmsg (s, msg, flags);
-}
diff --git a/src/ath.c b/src/ath.c
index ddd8a87..6b4667e 100644
--- a/src/ath.c
+++ b/src/ath.c
@@ -49,11 +49,6 @@
 #include "ath.h"
 
 
-#define MUTEX_UNLOCKED	((ath_mutex_t) 0)
-#define MUTEX_LOCKED	((ath_mutex_t) 1)
-#define MUTEX_DESTROYED	((ath_mutex_t) 2)
-
-
 #ifdef HAVE_W32_SYSTEM
 #include <windows.h>
 uintptr_t
@@ -80,52 +75,6 @@ ath_self (void)
 #endif
 
 
-int
-ath_mutex_init (ath_mutex_t *lock)
-{
-#ifndef NDEBUG
-  *lock = MUTEX_UNLOCKED;
-#endif
-  return 0;
-}
-
-
-int
-ath_mutex_destroy (ath_mutex_t *lock)
-{
-#ifndef NDEBUG
-  assert (*lock == MUTEX_UNLOCKED);
-
-  *lock = MUTEX_DESTROYED;
-#endif
-  return 0;
-}
-
-
-int
-ath_mutex_lock (ath_mutex_t *lock)
-{
-#ifndef NDEBUG
-  assert (*lock == MUTEX_UNLOCKED);
-
-  *lock = MUTEX_LOCKED;
-#endif
-  return 0;
-}
-
-
-int
-ath_mutex_unlock (ath_mutex_t *lock)
-{
-#ifndef NDEBUG
-  assert (*lock == MUTEX_LOCKED);
-
-  *lock = MUTEX_UNLOCKED;
-#endif
-  return 0;
-}
-
-
 gpgme_ssize_t
 ath_read (int fd, void *buf, size_t nbytes)
 {
diff --git a/src/ath.h b/src/ath.h
index 8eb9eb9..a1be9e5 100644
--- a/src/ath.h
+++ b/src/ath.h
@@ -60,10 +60,6 @@
 #define _ATH_PREFIX1(x,y) x ## y
 #define _ATH_PREFIX2(x,y) _ATH_PREFIX1(x,y)
 #define _ATH_PREFIX(x) _ATH_PREFIX2(_ATH_EXT_SYM_PREFIX,x)
-#define ath_mutex_init _ATH_PREFIX(ath_mutex_init)
-#define ath_mutex_destroy _ATH_PREFIX(ath_mutex_destroy)
-#define ath_mutex_lock _ATH_PREFIX(ath_mutex_lock)
-#define ath_mutex_unlock _ATH_PREFIX(ath_mutex_unlock)
 #define ath_read _ATH_PREFIX(ath_read)
 #define ath_write _ATH_PREFIX(ath_write)
 #define ath_select _ATH_PREFIX(ath_select)
@@ -75,17 +71,8 @@
 #endif
 
 
-typedef void *ath_mutex_t;
-#define ATH_MUTEX_INITIALIZER 0;
-
 uintptr_t ath_self (void);
 
-/* Functions for mutual exclusion.  */
-int ath_mutex_init (ath_mutex_t *mutex);
-int ath_mutex_destroy (ath_mutex_t *mutex);
-int ath_mutex_lock (ath_mutex_t *mutex);
-int ath_mutex_unlock (ath_mutex_t *mutex);
-
 /* Replacement for the POSIX functions, which can be used to allow
    other (user-level) threads to run.  */
 gpgme_ssize_t ath_read (int fd, void *buf, size_t nbytes);
diff --git a/src/posix-sema.c b/src/posix-sema.c
deleted file mode 100644
index d04ce61..0000000
--- a/src/posix-sema.c
+++ /dev/null
@@ -1,68 +0,0 @@
-/* posix-sema.c
-   Copyright (C) 2001 Werner Koch (dd9jn)
-   Copyright (C) 2001, 2002, 2004, 2007 g10 Code GmbH
-
-   This file is part of GPGME.
-
-   GPGME is free software; you can redistribute it and/or modify it
-   under the terms of the GNU Lesser General Public License as
-   published by the Free Software Foundation; either version 2.1 of
-   the License, or (at your option) any later version.
-
-   GPGME is distributed in the hope that it will be useful, but
-   WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-   Lesser General Public License for more details.
-
-   You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, write to the Free Software
-   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
-   02111-1307, USA.  */
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <assert.h>
-#include <errno.h>
-#include <signal.h>
-#include <fcntl.h>
-#ifdef HAVE_UNISTD_H
-# include <unistd.h>
-#endif
-#ifdef HAVE_SYS_TIME_H
-# include <sys/time.h>
-#endif
-#ifdef HAVE_SYS_TYPES_H
-# include <sys/types.h>
-#endif
-
-#include "util.h"
-#include "sema.h"
-#include "ath.h"
-
-void
-_gpgme_sema_subsystem_init ()
-{
-}
-
-void
-_gpgme_sema_cs_enter (struct critsect_s *s)
-{
-  _gpgme_ath_mutex_lock (&s->priv);
-}
-
-void
-_gpgme_sema_cs_leave (struct critsect_s *s)
-{
-  _gpgme_ath_mutex_unlock (&s->priv);
-}
-
-void
-_gpgme_sema_cs_destroy (struct critsect_s *s)
-{
-  _gpgme_ath_mutex_destroy (&s->priv);
-  s->priv = NULL;
-}
diff --git a/src/sema.h b/src/sema.h
index 4b7c0af..5b0d53d 100644
--- a/src/sema.h
+++ b/src/sema.h
@@ -22,46 +22,23 @@
 #ifndef SEMA_H
 #define SEMA_H
 
-struct critsect_s
-{
-  const char *name;
-  void *priv;
-};
+#include <gpg-error.h>
 
 #define DEFINE_GLOBAL_LOCK(name) \
-  struct critsect_s name = { #name, NULL }
+  gpgrt_lock_t name  = GPGRT_LOCK_INITIALIZER
+
 #define DEFINE_STATIC_LOCK(name) \
-  static struct critsect_s name  = { #name, NULL }
+  static gpgrt_lock_t name = GPGRT_LOCK_INITIALIZER
 
-#define DECLARE_LOCK(name) \
-  struct critsect_s name
-#define INIT_LOCK(a)			\
-  do					\
-    {					\
-      (a).name = #a;			\
-      (a).priv = NULL;			\
-    }					\
-  while (0)
-#define DESTROY_LOCK(name) _gpgme_sema_cs_destroy (&(name))
+#define INIT_LOCK(name) \
+  name = (gpgrt_lock_t) GPGRT_LOCK_INITIALIZER
 
+#define DECLARE_LOCK(name) gpgrt_lock_t name
 
-#define LOCK(name)			\
-  do					\
-    {					\
-      _gpgme_sema_cs_enter (&(name));	\
-    }					\
-  while (0)
+#define DESTROY_LOCK(name) gpgrt_lock_destroy(&name)
 
-#define UNLOCK(name)			\
-  do					\
-    {					\
-      _gpgme_sema_cs_leave (&(name));	\
-    }					\
-  while (0)
+#define LOCK(name) gpgrt_lock_lock(&name)
 
-void _gpgme_sema_subsystem_init (void);
-void _gpgme_sema_cs_enter (struct critsect_s *s);
-void _gpgme_sema_cs_leave (struct critsect_s *s);
-void _gpgme_sema_cs_destroy (struct critsect_s *s);
+#define UNLOCK(name) gpgrt_lock_unlock(&name)
 
 #endif /* SEMA_H */
diff --git a/src/version.c b/src/version.c
index 8bc898f..99698fa 100644
--- a/src/version.c
+++ b/src/version.c
@@ -74,7 +74,6 @@ do_subsystem_inits (void)
   }
 #endif
 
-  _gpgme_sema_subsystem_init ();
   _gpgme_debug_subsystem_init ();
   _gpgme_io_subsystem_init ();
   _gpgme_status_init ();
diff --git a/src/w32-sema.c b/src/w32-sema.c
deleted file mode 100644
index 648a6bb..0000000
--- a/src/w32-sema.c
+++ /dev/null
@@ -1,117 +0,0 @@
-/* w32-sema.c
-   Copyright (C) 2001 Werner Koch (dd9jn)
-   Copyright (C) 2001, 2002, 2004, 2007 g10 Code GmbH
-
-   This file is part of GPGME.
-
-   GPGME is free software; you can redistribute it and/or modify it
-   under the terms of the GNU Lesser General Public License as
-   published by the Free Software Foundation; either version 2.1 of
-   the License, or (at your option) any later version.
-
-   GPGME is distributed in the hope that it will be useful, but
-   WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-   Lesser General Public License for more details.
-
-   You should have received a copy of the GNU Lesser General Public
-   License along with this program; if not, write to the Free Software
-   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
-   02111-1307, USA.  */
-
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <assert.h>
-#include <errno.h>
-#include <fcntl.h>
-#ifdef HAVE_SYS_TIME_H
-# include <sys/time.h>
-#endif
-#ifdef HAVE_SYS_TYPES_H
-# include <sys/types.h>
-#endif
-#include <io.h>
-
-#include "util.h"
-#include "sema.h"
-#include "debug.h"
-
-static void
-sema_fatal (const char *text)
-{
-    fprintf (stderr, "sema.c: %s\n", text);
-    abort ();
-}
-
-
-static void
-critsect_init (struct critsect_s *s)
-{
-    CRITICAL_SECTION *mp;
-    static CRITICAL_SECTION init_lock;
-    static int initialized;
-
-    if (!initialized) {
-        /* The very first time we call this function, we assume that
-	   only one thread is running, so that we can bootstrap the
-	   semaphore code.  */
-        InitializeCriticalSection (&init_lock);
-        initialized = 1;
-    }
-    if (!s)
-        return; /* we just want to initialize ourself */
-
-    /* first test whether it is really not initialized */
-    EnterCriticalSection (&init_lock);
-    if ( s->priv ) {
-        LeaveCriticalSection (&init_lock);
-        return;
-    }
-    /* now init it */
-    mp = malloc ( sizeof *mp );
-    if (!mp) {
-        LeaveCriticalSection (&init_lock);
-        sema_fatal ("out of core while creating critical section lock");
-    }
-    InitializeCriticalSection (mp);
-    s->priv = mp;
-    LeaveCriticalSection (&init_lock);
-}
-
-void
-_gpgme_sema_subsystem_init ()
-{
-    /* fixme: we should check that there is only one thread running */
-    critsect_init (NULL);
-}
-
-
-void
-_gpgme_sema_cs_enter ( struct critsect_s *s )
-{
-    if (!s->priv)
-        critsect_init (s);
-    EnterCriticalSection ( (CRITICAL_SECTION*)s->priv );
-}
-
-void
-_gpgme_sema_cs_leave (struct critsect_s *s)
-{
-    if (!s->priv)
-        critsect_init (s);
-    LeaveCriticalSection ((CRITICAL_SECTION*)s->priv);
-}
-
-void
-_gpgme_sema_cs_destroy ( struct critsect_s *s )
-{
-    if (s && s->priv) {
-        DeleteCriticalSection ((CRITICAL_SECTION*)s->priv);
-        free (s->priv);
-        s->priv = NULL;
-    }
-}
diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am
index 2538f63..dd33b0a 100644
--- a/tests/gpg/Makefile.am
+++ b/tests/gpg/Makefile.am
@@ -38,7 +38,8 @@ c_tests = \
         t-encrypt t-encrypt-sym t-encrypt-sign t-sign t-signers		\
 	t-decrypt t-verify t-decrypt-verify t-sig-notation t-export	\
 	t-import t-trustlist t-edit t-keylist t-keylist-sig t-wait	\
-	t-encrypt-large t-file-name t-gpgconf t-encrypt-mixed $(tests_unix)
+	t-encrypt-large t-file-name t-gpgconf t-encrypt-mixed $(tests_unix) \
+	t-thread-keylist t-thread-keylist-verify
 
 TESTS = initial.test $(c_tests) final.test
 
@@ -61,8 +62,10 @@ EXTRA_DIST = initial.test final.test \
 AM_CPPFLAGS = -I$(top_builddir)/src @GPG_ERROR_CFLAGS@
 AM_LDFLAGS = -no-install
 LDADD = ../../src/libgpgme.la
-t_thread1_LDADD = ../../src/libgpgme-pthread.la -lpthread
-t_cancel_LDADD = ../../src/libgpgme-pthread.la -lpthread
+t_thread1_LDADD = ../../src/libgpgme.la -lpthread
+t_thread_keylist_LDADD = ../../src/libgpgme.la -lpthread
+t_thread_keylist_verify_LDADD = ../../src/libgpgme.la -lpthread
+t_cancel_LDADD = ../../src/libgpgme.la -lpthread
 
 # We don't run t-genkey and t-cancel in the test suite, because it
 # takes too long
diff --git a/tests/gpg/t-thread-keylist-verify.c b/tests/gpg/t-thread-keylist-verify.c
new file mode 100644
index 0000000..55af88a
--- /dev/null
+++ b/tests/gpg/t-thread-keylist-verify.c
@@ -0,0 +1,129 @@
+/* t-thread-verify.c - Regression test.
+   Copyright (C) 2015 Intevation GmbH
+
+   This file is part of GPGME.
+
+   GPGME is free software; you can redistribute it and/or modify it
+   under the terms of the GNU Lesser General Public License as
+   published by the Free Software Foundation; either version 2.1 of
+   the License, or (at your option) any later version.
+
+   GPGME is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+   02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+
+#include <gpgme.h>
+
+#include <pthread.h>
+
+#include "t-support.h"
+
+#define THREAD_COUNT 500
+
+static const char test_text1[] = "Just GNU it!\n";
+static const char test_sig1[] =
+"-----BEGIN PGP SIGNATURE-----\n"
+"\n"
+"iN0EABECAJ0FAjoS+i9FFIAAAAAAAwA5YmFyw7bDpMO8w58gZGFzIHdhcmVuIFVt\n"
+"bGF1dGUgdW5kIGpldHp0IGVpbiBwcm96ZW50JS1aZWljaGVuNRSAAAAAAAgAJGZv\n"
+"b2Jhci4xdGhpcyBpcyBhIG5vdGF0aW9uIGRhdGEgd2l0aCAyIGxpbmVzGhpodHRw\n"
+"Oi8vd3d3Lmd1Lm9yZy9wb2xpY3kvAAoJEC1yfMdoaXc0JBIAoIiLlUsvpMDOyGEc\n"
+"dADGKXF/Hcb+AKCJWPphZCphduxSvrzH0hgzHdeQaA==\n"
+"=nts1\n"
+"-----END PGP SIGNATURE-----\n";
+
+void *
+start_keylist (void *arg)
+{
+  gpgme_error_t err;
+  gpgme_ctx_t ctx;
+  gpgme_key_t key;
+
+  err = gpgme_new (&ctx);
+  fail_if_err (err);
+
+  err = gpgme_op_keylist_start (ctx, NULL, 0);
+  fail_if_err (err);
+
+  while (!(err = gpgme_op_keylist_next (ctx, &key)));
+
+  return NULL;
+}
+
+void *
+start_verify (void *arg)
+{
+  gpgme_ctx_t ctx;
+  gpgme_error_t err;
+  gpgme_data_t sig, text;
+  gpgme_verify_result_t result;
+  gpgme_signature_t signature;
+
+  err = gpgme_new (&ctx);
+  fail_if_err (err);
+
+  /* Checking a valid message.  */
+  err = gpgme_data_new_from_mem (&text, test_text1, strlen (test_text1), 0);
+  fail_if_err (err);
+  err = gpgme_data_new_from_mem (&sig, test_sig1, strlen (test_sig1), 0);
+  fail_if_err (err);
+  err = gpgme_op_verify (ctx, sig, text, NULL);
+  fail_if_err (err);
+  result = gpgme_op_verify_result (ctx);
+
+  signature = result->signatures;
+
+  if (strcmp (signature->fpr, "A0FF4590BB6122EDEF6E3C542D727CC768697734"))
+    {
+      fprintf (stderr, "%s:%i: Unexpected fingerprint: %s\n",
+               __FILE__, __LINE__, signature->fpr);
+      exit (1);
+    }
+  if (gpgme_err_code (signature->status) != GPG_ERR_NO_ERROR)
+    {
+      fprintf (stderr, "%s:%i: Unexpected signature status: %s\n",
+               __FILE__, __LINE__, gpgme_strerror (signature->status));
+      exit (1);
+    }
+  return NULL;
+}
+
+int
+main (int argc, char *argv[])
+{
+  int i;
+  pthread_t verify_threads[THREAD_COUNT];
+  pthread_t keylist_threads[THREAD_COUNT];
+  init_gpgme (GPGME_PROTOCOL_OpenPGP);
+
+  for (i = 0; i < THREAD_COUNT; i++)
+    {
+      if (pthread_create(&verify_threads[i], NULL, start_verify, NULL) ||
+          pthread_create(&keylist_threads[i], NULL, start_keylist, NULL))
+        {
+          fprintf(stderr, "%s:%i: failed to create threads \n",
+                       __FILE__, __LINE__);
+          exit(1);
+        }
+   }
+  for (i = 0; i < THREAD_COUNT; i++)
+    {
+      pthread_join (verify_threads[i], NULL);
+      pthread_join (keylist_threads[i], NULL);
+    }
+  return 0;
+}
diff --git a/tests/gpg/t-thread-keylist.c b/tests/gpg/t-thread-keylist.c
new file mode 100644
index 0000000..14f7718
--- /dev/null
+++ b/tests/gpg/t-thread-keylist.c
@@ -0,0 +1,76 @@
+/* t-thread-verify.c - Regression test.
+   Copyright (C) 2015 Intevation GmbH
+
+   This file is part of GPGME.
+
+   GPGME is free software; you can redistribute it and/or modify it
+   under the terms of the GNU Lesser General Public License as
+   published by the Free Software Foundation; either version 2.1 of
+   the License, or (at your option) any later version.
+
+   GPGME is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+   02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+
+#include <gpgme.h>
+
+#include <pthread.h>
+
+#include "t-support.h"
+
+#define THREAD_COUNT 500
+
+void *
+start_keylist (void *arg)
+{
+  gpgme_error_t err;
+  gpgme_ctx_t ctx;
+  gpgme_key_t key;
+
+  err = gpgme_new (&ctx);
+  fail_if_err (err);
+
+  err = gpgme_op_keylist_start (ctx, NULL, 0);
+  fail_if_err (err);
+
+  while (!(err = gpgme_op_keylist_next (ctx, &key)));
+
+  return NULL;
+}
+
+int
+main (int argc, char *argv[])
+{
+  int i;
+  pthread_t keylist_threads[THREAD_COUNT];
+  init_gpgme (GPGME_PROTOCOL_OpenPGP);
+
+  for (i = 0; i < THREAD_COUNT; i++)
+    {
+      if (pthread_create(&keylist_threads[i], NULL, start_keylist, NULL))
+        {
+          fprintf(stderr, "%s:%i: failed to create threads \n",
+                       __FILE__, __LINE__);
+          exit(1);
+        }
+   }
+  for (i = 0; i < THREAD_COUNT; i++)
+    {
+      pthread_join (keylist_threads[i], NULL);
+    }
+  return 0;
+}
-- 
2.1.4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161108/f14272eb/attachment-0001.sig>

From dkg at fifthhorseman.net  Tue Nov  8 21:37:25 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue,  8 Nov 2016 14:37:25 -0600
Subject: [PINENTRY PATCH] gnome3: Tighten up error messages when GNOME
 screensaver is absent.
Message-ID: <20161108203725.25643-1-dkg@fifthhorseman.net>

* gnome3/pinentry-gnome3.c (pe_gnome_screen_locked): clean up error
messages when GNOME screensaver is absent or misbehaving.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 gnome3/pinentry-gnome3.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index f9c9262..a040f9b 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -446,9 +446,12 @@ pe_gnome_screen_locked (void)
   g_object_unref(dbus);
   if (!reply)
     {
-      fprintf (stderr, "failed to get reply (%d): %s",
-               error ? error->code : -1,
-               error ? error->message : "<no GError>");
+      /* G_IO_ERROR_TIMED_OUT is the expected response when there is
+       * no gnome screensaver at all, don't be noisy in that case: */
+      if (!(error && error->code == G_IO_ERROR_TIMED_OUT))
+        fprintf (stderr, "Failed to get d-bus reply for org.gnome.ScreenSaver.GetActive (%d): %s\n",
+                 error ? error->code : -1,
+                 error ? error->message : "<no GError>");
       if (error)
         g_error_free (error);
       return FALSE;
@@ -456,7 +459,7 @@ pe_gnome_screen_locked (void)
   reply_bool = g_variant_get_child_value (reply, 0);
   if (!reply_bool)
     {
-      fprintf (stderr, "failed to get boolean from reply\n");
+      fprintf (stderr, "Failed to get d-bus boolean from org.gnome.ScreenSaver.GetActive; assuming screensaver is not locked\n");
       ret = FALSE;
     }
   else
-- 
2.10.2



From neal at walfield.org  Tue Nov  8 22:03:36 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Tue, 08 Nov 2016 16:03:36 -0500
Subject: [PINENTRY PATCH] gnome3: Tighten up error messages when GNOME
 screensaver is absent.
In-Reply-To: <20161108203725.25643-1-dkg@fifthhorseman.net>
References: <20161108203725.25643-1-dkg@fifthhorseman.net>
Message-ID: <87bmxplm53.wl-neal@walfield.org>

Applied.  Thanks!

:) Neal

At Tue,  8 Nov 2016 14:37:25 -0600,
Daniel Kahn Gillmor wrote:
> 
> * gnome3/pinentry-gnome3.c (pe_gnome_screen_locked): clean up error
> messages when GNOME screensaver is absent or misbehaving.
> 
> Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> ---
>  gnome3/pinentry-gnome3.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
> index f9c9262..a040f9b 100644
> --- a/gnome3/pinentry-gnome3.c
> +++ b/gnome3/pinentry-gnome3.c
> @@ -446,9 +446,12 @@ pe_gnome_screen_locked (void)
>    g_object_unref(dbus);
>    if (!reply)
>      {
> -      fprintf (stderr, "failed to get reply (%d): %s",
> -               error ? error->code : -1,
> -               error ? error->message : "<no GError>");
> +      /* G_IO_ERROR_TIMED_OUT is the expected response when there is
> +       * no gnome screensaver at all, don't be noisy in that case: */
> +      if (!(error && error->code == G_IO_ERROR_TIMED_OUT))
> +        fprintf (stderr, "Failed to get d-bus reply for org.gnome.ScreenSaver.GetActive (%d): %s\n",
> +                 error ? error->code : -1,
> +                 error ? error->message : "<no GError>");
>        if (error)
>          g_error_free (error);
>        return FALSE;
> @@ -456,7 +459,7 @@ pe_gnome_screen_locked (void)
>    reply_bool = g_variant_get_child_value (reply, 0);
>    if (!reply_bool)
>      {
> -      fprintf (stderr, "failed to get boolean from reply\n");
> +      fprintf (stderr, "Failed to get d-bus boolean from org.gnome.ScreenSaver.GetActive; assuming screensaver is not locked\n");
>        ret = FALSE;
>      }
>    else
> -- 
> 2.10.2
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 


From david at davidstrauss.net  Wed Nov  9 01:56:49 2016
From: david at davidstrauss.net (David Strauss)
Date: Wed, 09 Nov 2016 00:56:49 +0000
Subject: Automatic PINpad support for the Cherry KC 1000 SC
Message-ID: <CABpmRD46F3PpUeRg1chyDgQjkqG862sxcvg6wS-chd4rLQgq+w@mail.gmail.com>

The current PINpad detection [1] automatically uses secure PIN entry on the
older Cherry ST2000 keyboards. The KC 1000 SC is the successor product, and
it also supports direct, variable-length PIN entry. I have tested the
support by setting "enable-pinpad-varlen" in scdaemon.conf, and it works
reliably. If would be good if GnuPG automatically detected the new model.

Here is the dmesg output from plugging the device in, which I think
contains the necessary vendor IDs:

[  862.822190] usb 1-3: new full-speed USB device number 6 using xhci_hcd
[  862.999508] usb 1-3: New USB device found, idVendor=046a, idProduct=00a1
[  862.999517] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[  862.999522] usb 1-3: Product: KC 1000 SC
[  862.999526] usb 1-3: Manufacturer: Cherry
[  863.008566] input: Cherry KC 1000 SC as
/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:046A:00A1.0003/input/input19
[  863.061868] hid-generic 0003:046A:00A1.0003: input,hidraw0: USB HID
v1.11 Keyboard [Cherry KC 1000 SC] on usb-0000:00:14.0-3/input0
[  863.066893] input: Cherry KC 1000 SC as
/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:046A:00A1.0004/input/input20
[  863.119355] hid-generic 0003:046A:00A1.0004: input,hidraw1: USB HID
v1.11 Device [Cherry KC 1000 SC] on usb-0000:00:14.0-3/input1

I attempted to create a patch, but it wasn't clear to me that the KC 1000
SC should have the exact same configuration as the ST2000. I would be happy
to send a KC 1000 SC to an established GnuPG contributor to help get this
support added. I would also be happy to test any patches.

[1] https://wiki.gnupg.org/CardReader/PinpadInput
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161109/215194f3/attachment.html>

From dkg at fifthhorseman.net  Wed Nov  9 19:43:32 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Nov 2016 12:43:32 -0600
Subject: GPG Agent: No detach not working?
In-Reply-To: <CAPTk+sbeJng_EG6VuMLjJwTt6NVU2r74FdoguQGPyN5=pGJy0g@mail.gmail.com>
References: <CAPTk+sbeJng_EG6VuMLjJwTt6NVU2r74FdoguQGPyN5=pGJy0g@mail.gmail.com>
Message-ID: <871sykebor.fsf@alice.fifthhorseman.net>

Hi Naftuli--

On Mon 2016-11-07 12:08:15 -0600, Naftuli Kay wrote:
> I'm looking to run my gpg-agent in a SystemD user unit file like so:
 [...]
> Running on Ubuntu 16.04. I'd like to have it run in the foreground so
> that its output is captured by the SystemD journal so I can review.
>
> I can get it to work if I set it to Type=forking, but I specifically
> want it to run in the foreground.

Please wait until 2.1.16 is released (or backport the fixes for the
"--supervised" options to dirmngr and gpg-agent), and then use the the
socket-activated .service and .socket files that we're shipping in
debian:

    https://sources.debian.net/src/gnupg2/unstable/debian/systemd-user/

This will provide you with exactly what you're looking for, and it will
have the additional advantage of not actually running the daemons until
they're needed.

I've asked upstream to include these .service and .socket files in the
upstream git repo to make them easier to find, but that hasn't happened
yet.

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/20161109/7ef0c569/attachment.sig>

From dkg at fifthhorseman.net  Wed Nov  9 19:40:43 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Nov 2016 12:40:43 -0600
Subject: [PATCH] systemd: Include config for socket-activated user
 services.
In-Reply-To: <877f8tctx7.fsf@alice.fifthhorseman.net>
References: <20161027181918.920-1-dkg@fifthhorseman.net>
 <87lgx962db.fsf@wheatstone.g10code.de>
 <877f8tctx7.fsf@alice.fifthhorseman.net>
Message-ID: <8737j0ebtg.fsf@alice.fifthhorseman.net>

On Thu 2016-10-27 17:24:04 -0500, Daniel Kahn Gillmor wrote:
> I'll certainly keep them in debian if they're not imported upstream. but
> i'd much rather see them upstream so that other OSes that already use
> systemd won't need to go to the trouble of inventing their own configs
> to have a well-integrated, session-bound set of agents.
>
> If you had a separate directory that included mechanism to cleanly
> integrate into other system managers, that would also be a reasonable
> collection of things to host in the upstream repo.

In case this wasn't clear, i'm volunteering to maintain these systemd
integration pieces for GnuPG and systemd.  All i'm asking for is the
visibility of having these stored in the upstream git repo.

If it would make it more palatable for you to put it in a "contrib"
directory, that's fine with me.

It would make it simpler to respond to questions like the one asked
recently by Naftuli Kay <rfkrocktk at gmail.com> if i could point simply to
the upstream repo.

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/20161109/1d0e4071/attachment.sig>

From rfkrocktk at gmail.com  Wed Nov  9 20:15:19 2016
From: rfkrocktk at gmail.com (Naftuli Kay)
Date: Wed, 9 Nov 2016 11:15:19 -0800
Subject: GPG Agent: No detach not working?
In-Reply-To: <871sykebor.fsf@alice.fifthhorseman.net>
References: <CAPTk+sbeJng_EG6VuMLjJwTt6NVU2r74FdoguQGPyN5=pGJy0g@mail.gmail.com>
 <871sykebor.fsf@alice.fifthhorseman.net>
Message-ID: <CAPTk+sZfHJFyvYo6=q+8xyx-J8kJEgPie+as5N6iJhAtkoONwA@mail.gmail.com>

Thank you so much, this answers my question!
Thanks,
 - Naftuli Kay


On Wed, Nov 9, 2016 at 10:43 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> Hi Naftuli--
>
> On Mon 2016-11-07 12:08:15 -0600, Naftuli Kay wrote:
>> I'm looking to run my gpg-agent in a SystemD user unit file like so:
>  [...]
>> Running on Ubuntu 16.04. I'd like to have it run in the foreground so
>> that its output is captured by the SystemD journal so I can review.
>>
>> I can get it to work if I set it to Type=forking, but I specifically
>> want it to run in the foreground.
>
> Please wait until 2.1.16 is released (or backport the fixes for the
> "--supervised" options to dirmngr and gpg-agent), and then use the the
> socket-activated .service and .socket files that we're shipping in
> debian:
>
>     https://sources.debian.net/src/gnupg2/unstable/debian/systemd-user/
>
> This will provide you with exactly what you're looking for, and it will
> have the additional advantage of not actually running the daemons until
> they're needed.
>
> I've asked upstream to include these .service and .socket files in the
> upstream git repo to make them easier to find, but that hasn't happened
> yet.
>
> Regards,
>
>      --dkg


From gniibe at fsij.org  Thu Nov 10 03:17:42 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 10 Nov 2016 11:17:42 +0900
Subject: Automatic PINpad support for the Cherry KC 1000 SC
In-Reply-To: <CABpmRD46F3PpUeRg1chyDgQjkqG862sxcvg6wS-chd4rLQgq+w@mail.gmail.com>
References: <CABpmRD46F3PpUeRg1chyDgQjkqG862sxcvg6wS-chd4rLQgq+w@mail.gmail.com>
Message-ID: <92a6ef80-6384-02da-80e7-7b95005f1a3d@fsij.org>

Hello,

Thank you for your information.  Let me ask some.

On 11/09/2016 09:56 AM, David Strauss wrote:
> The current PINpad detection [1] automatically uses secure PIN entry on
> the older Cherry ST2000 keyboards. The KC 1000 SC is the successor
> product, and it also supports direct, variable-length PIN entry. I have
> tested the support by setting "enable-pinpad-varlen" in scdaemon.conf,
> and it works reliably. If would be good if GnuPG automatically detected
> the new model.

Are you using scdaemon with PC/SC?  I think that it can work well
somehow with the internal ccid driver with no setting of
"enable-pinpad-varlen" in scdaemon.conf (You need permission setting
of the USB device).

Please try with no PC/SC service.

> Here is the dmesg output from plugging the device in, which I think
> contains the necessary vendor IDs:
> 
> [  862.822190] usb 1-3: new full-speed USB device number 6 using xhci_hcd
> [  862.999508] usb 1-3: New USB device found, idVendor=046a, idProduct=00a1
> [  862.999517] usb 1-3: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [  862.999522] usb 1-3: Product: KC 1000 SC
> [  862.999526] usb 1-3: Manufacturer: Cherry
> [  863.008566] input: Cherry KC 1000 SC as
> /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:046A:00A1.0003/input/input19
> [  863.061868] hid-generic 0003:046A:00A1.0003: input,hidraw0: USB HID
> v1.11 Keyboard [Cherry KC 1000 SC] on usb-0000:00:14.0-3/input0
> [  863.066893] input: Cherry KC 1000 SC as
> /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:046A:00A1.0004/input/input20
> [  863.119355] hid-generic 0003:046A:00A1.0004: input,hidraw1: USB HID
> v1.11 Device [Cherry KC 1000 SC] on usb-0000:00:14.0-3/input1
> 
> I attempted to create a patch, but it wasn't clear to me that the KC
> 1000 SC should have the exact same configuration as the ST2000. I would
> be happy to send a KC 1000 SC to an established GnuPG contributor to
> help get this support added. I would also be happy to test any patches.

I'm afraid if this reader works well with OpenPGP card for RSA-2048 or
larger keys.

I'm looking at the information here:

    http://pcsclite.alioth.debian.org/ccid/readers/Cherry_KC_1000_SC.txt

If it is correct (no extended APDU support), this reader can't be used
for OpenPGP card with RSA-2048 or larger keys for following operations:

    * key registration
    * decryption

while degital signing and authentication would work.

Note that ST-2000 only support TPDU level exchange (lower level than
APDU), thus, it works well (the larger message handling is done by
host side).


Well, some people still has old key and want to keep using with
OpenPGP card, and want to use PC/SC service for some reasons.  For
those people, possible fix may be something like this:

=====================================================
diff --git a/scd/apdu.c b/scd/apdu.c
index 3e2b609..54f3b30 100644
--- a/scd/apdu.c
+++ b/scd/apdu.c
@@ -1896,8 +1896,12 @@ pcsc_vendor_specific_init (int slot)
       reader_table[slot].is_spr532 = 1;
       reader_table[slot].pinpad_varlen_supported = 1;
     }
-  else if (vendor == 0x046a && product == 0x003e) /* Cherry ST-2xxx */
+  else if (vendor == 0x046a)
     {
+      /* Cherry ST-2xxx (product == 0x003e) supports TPDU level
+       * exchange.  Other products which only support short APDU level
+       * exchange only work with shorter keys like RSA 1024.
+       */
       reader_table[slot].pcsc.pinmax = 15;
       reader_table[slot].pinpad_varlen_supported = 1;
     }
-- 


From dkg at fifthhorseman.net  Thu Nov 10 12:06:53 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 10 Nov 2016 05:06:53 -0600
Subject: dirmngr, ldap, dirmngr_ldap, and the ldap "wrapper"
Message-ID: <87y40rbnle.fsf@alice.fifthhorseman.net>

Hi all--

dirmngr in debian used to have a weaker dependency (a "Recommends:"
instead of "Depends:") on the libldap binary package, so users who
wanted a smaller system and didn't need dirmngr ldap access could
install dirmngr without installing libldap.  Of course, dirmngr_ldap
would fail on those systems.  Currently, however, libldap is a hard
dependency of dirmngr, because dirmngr links in ks-engine-ldap.c

Comments in the header of dirmngr/ldap-wrapper.c say:

----------
   We can't use LDAP directly for these reasons:

   1. On some systems the LDAP library uses (indirectly) pthreads and
      that is not compatible with PTh.

   2. It is huge library in particular if TLS comes into play.  So
      problems with unfreed memory might turn up and we don't want
      this in a long running daemon.

   3. There is no easy way for timeouts. In particular the timeout
      value does not work for DNS lookups (well, this is usual) and it
      seems not to work while loading a large attribute like a
      CRL. Having a separate process allows us to either tell the
      process to commit suicide or have our own housekepping function
      kill it after some time.  The latter also allows proper
      cancellation of a query at any point of time.

   4. Given that we are going out to the network and usually get back
      a long response, the fork/exec overhead is acceptable.
----------

The inclusion of ks-engine-ldap.c appears to have happened in
51341badb623927f2a358588c725a356fc77dbe7.  Has the rationale in
ldap-wrapper.c been reconsidered or made obsolete for some reason?  If
so, it should be updated.  If not, should we try to re-separate
dirmngr's use of ldap back into the wrapper?

Any thoughts?

          --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/20161110/363bfd34/attachment.sig>

From Alexander.Strobel at giepa.de  Thu Nov 10 13:25:24 2016
From: Alexander.Strobel at giepa.de (Alexander Strobel)
Date: Thu, 10 Nov 2016 13:25:24 +0100
Subject: GnuPG git server down?
Message-ID: <221d29bb-a28d-82ba-b129-48a90c110fac@giepa.de>

I tried to clone the gnupg repo without success.
Am I doing something wrong?

Z:\>git clone git://git.gnupg.org/gnupg.git
Cloning into 'gnupg'...
fatal: unable to connect to git.gnupg.org:
git.gnupg.org[0: 217.69.76.56]: errno=No error

Z:\>git clone https://git.gnupg.org/gnupg.git
Cloning into 'gnupg'...
fatal: repository 'https://git.gnupg.org/gnupg.git/' not found


Best regards
 Alex Strobel
 www.gpg4o.com


From dkg at fifthhorseman.net  Thu Nov 10 14:34:55 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 10 Nov 2016 07:34:55 -0600
Subject: [PATCH v2] dirmngr: Clarify deprecation of --daemon without --homedir.
In-Reply-To: <1470694395-3627-1-git-send-email-dkg@fifthhorseman.net>
References: <1470694395-3627-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <20161110133455.13444-1-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 6620a87..e059583 100644
--- a/doc/dirmngr.texi
+++ b/doc/dirmngr.texi
@@ -83,7 +83,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 --supervised
 @opindex supervised
@@ -148,7 +149,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.10.2



From dkg at fifthhorseman.net  Thu Nov 10 14:17:17 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 10 Nov 2016 07:17:17 -0600
Subject: [PATCH] agent: Clean up comments.
Message-ID: <20161110131717.10975-1-dkg@fifthhorseman.net>

* agent/agent.h: Clean up comments.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 agent/agent.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/agent/agent.h b/agent/agent.h
index 9ba7dc8..2dfbf5c 100644
--- a/agent/agent.h
+++ b/agent/agent.h
@@ -154,12 +154,12 @@ struct
   int keep_tty;      /* Don't switch the TTY (for pinentry) on request */
   int keep_display;  /* Don't switch the DISPLAY (for pinentry) on request */
 
-  /* This global options indicates the use of an extra socket. Note
+  /* This global option indicates the use of an extra socket. Note
      that we use a hack for cleanup handling in gpg-agent.c: If the
      value is less than 2 the name has not yet been malloced. */
   int extra_socket;
 
-  /* This global options indicates the use of an extra socket for web
+  /* This global option indicates the use of an extra socket for web
      browsers. Note that we use a hack for cleanup handling in
      gpg-agent.c: If the value is less than 2 the name has not yet
      been malloced. */
-- 
2.10.2



From vinay_sajip at yahoo.co.uk  Thu Nov 10 19:38:54 2016
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Thu, 10 Nov 2016 18:38:54 +0000 (UTC)
Subject: Building gpg locally
References: <1634078852.2723658.1478803134050.ref@mail.yahoo.com>
Message-ID: <1634078852.2723658.1478803134050@mail.yahoo.com>

I'm trying to build gpg 2.1.15 locally. I've downloaded the latest sources to:
~/libgpg-error-1.24~/npth-1.2~/libassuan-2.4.3~/libksba-1.3.5~/libgcrypt-1.7.3~/gnupg-2.1.15
In each of the above, I've done
./configure --prefix=$HOME/tmp && make && make install
They all work except for the last one, and I get include files in ~/tmp/include, lib files in ~/tmp/lib etc., as expected.
However, if I try and invoke ./configure in the gnupg-2.1.15 directory, it can't find the dependencies ...
configure:****** You need libgpg-error to build this program.** ?This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libgpg-error*** (at least version 1.24 is required.)***configure:****** You need libgcrypt to build this program.** ?This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libgcrypt/*** (at least version 1.7.0 (API 1) is required.)***configure:****** You need libassuan to build this program.*** This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libassuan/*** (at least version 2.4.3 (API 2) is required).***configure:****** You need libksba to build this program.*** This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libksba/*** (at least version 1.3.4 using API 1 is required).***configure:****** It is now required to build with support for the*** New Portable Threads Library (nPth). Please install this*** library first. ?The library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/npth/*** (at least version 1.2 (API 1) is required).***configure: error:?****** Required libraries not found. Please consult the above messages*** and install them before running configure again.***
I've invoked the gnupg configure using
CFLAGS=-I$HOME/tmp/include LDFLAGS=-L$HOME/tmp/lib ./configure --prefix=$HOME/tmp
Environment is Ubuntu 16.04.1 (64-bit).
How should I invoke configure for gnupg to get it to pick up the private copies of includes and libs in $HOME/tmp ? I couldn't see any answer via ./configure --help.
Regards,

Vinay Sajip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161110/3b802f5c/attachment.html>

From gniibe at fsij.org  Fri Nov 11 02:40:26 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 11 Nov 2016 10:40:26 +0900
Subject: Building gpg locally
In-Reply-To: <1634078852.2723658.1478803134050@mail.yahoo.com>
References: <1634078852.2723658.1478803134050.ref@mail.yahoo.com>
 <1634078852.2723658.1478803134050@mail.yahoo.com>
Message-ID: <a94116b4-ff3f-02bb-fe16-7fe867eb2bc0@fsij.org>

Hello,

On 11/11/2016 03:38 AM, Vinay Sajip wrote:
> I've invoked the gnupg configure using
> 
> CFLAGS=-I$HOME/tmp/include LDFLAGS=-L$HOME/tmp/lib ./configure
> --prefix=$HOME/tmp
> 
> Environment is Ubuntu 16.04.1 (64-bit).
> 
> How should I invoke configure for gnupg to get it to pick up the private
> copies of includes and libs in $HOME/tmp ? I couldn't see any answer via
> ./configure --help.

In that cas, you need to specify following options with $HOME/tmp.

    --with-libgpg-error-prefix
    --with-npth-prefix
    --with-libgcrypt-prefix
    --with-libassuan-prefix
    --with-ksba-prefix

I think that CFLAGS and LDFLAGS are not needed to be specified.

By the commands of gpg-error-config, npth-config, libgcrypt-config,
libassuan-config, and ksba-config, CFLAGS and LDFLAGS are examined.
-- 


From wk at gnupg.org  Fri Nov 11 08:28:35 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Nov 2016 08:28:35 +0100
Subject: [PATCH] agent: Clean up comments.
In-Reply-To: <20161110131717.10975-1-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Thu, 10 Nov 2016 07:17:17 -0600")
References: <20161110131717.10975-1-dkg@fifthhorseman.net>
Message-ID: <87mvh6h3vg.fsf@wheatstone.g10code.de>

On Thu, 10 Nov 2016 14:17, dkg at fifthhorseman.net said:
> * agent/agent.h: Clean up comments.

Thanks.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161111/3dd71100/attachment.sig>

From wk at gnupg.org  Fri Nov 11 08:27:01 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Nov 2016 08:27:01 +0100
Subject: [PATCH v2] dirmngr: Clarify deprecation of --daemon without
 --homedir.
In-Reply-To: <20161110133455.13444-1-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Thu, 10 Nov 2016 07:34:55 -0600")
References: <1470694395-3627-1-git-send-email-dkg@fifthhorseman.net>
 <20161110133455.13444-1-dkg@fifthhorseman.net>
Message-ID: <87r36ih3y2.fsf@wheatstone.g10code.de>

On Thu, 10 Nov 2016 14:34, dkg at fifthhorseman.net said:

> I believe what's actually deprecated is --daemon *without* --homedir.

No.  The system daemon feature was removed in August but that is not
reflccted in the man page.  Thus I'll push the change below.  Thanks for
looking on these details.


Salam-Shalom,

   Werner


==========
commit 1854f0f6112651c4fc3b92372b98c932e830ed21
Author: Werner Koch <wk at gnupg.org>
Date:   Fri Nov 11 08:25:04 2016 +0100

    doc: Clarify dirmngr option --daemon.
    
    --
    
    With commit d83ba4897bf217d1045c58d1b99e52bd31c58812 all system daemon
    features have been removed and thus this should be reflected in the
    man page.
    
    Signed-off-by: Werner Koch <wk at gnupg.org>

	Modified   doc/dirmngr.texi
diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi
index 6620a87..300068e 100644
--- a/doc/dirmngr.texi
+++ b/doc/dirmngr.texi
@@ -82,8 +82,9 @@ This is only used for testing.
 @item --daemon
 @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.
+This is the way @command{dirmngr} is started on demand by the other
+GnuPG components.  To force starting @command{dirmngr} it is in
+general best to use @code{gpgconf --launch dirmngr}.
 
 @item --supervised
 @opindex supervised
@@ -141,21 +142,11 @@ per-user configuration file.  The default configuration file is named
 @item --homedir @var{dir}
 @opindex options
 Set the name of the home directory to @var{dir}.  This option is only
-effective when used on the command line.  The default depends on the
-running mode:
-
- at table @asis
-
- at 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.
-
- at item Without @code{--daemon} given on the commandline
+effective when used on the command line.  The default os
 the directory named @file{.gnupg} directly below the home directory
 of the user unless the environment variable @code{GNUPGHOME} has been set
 in which case its value will be used.  All kind of data is stored below
 this directory.
- at end table
 
 
 @item -v
@@ -345,8 +336,7 @@ configured LDAP server if the connection using the "proxy" failed.
 @opindex ldapserverlist-file
 Read the list of LDAP servers to consult for CRLs and certificates from
 file instead of the default per-user ldap server list file. The default
-value for @var{file} is @file{dirmngr_ldapservers.conf} or
- at file{ldapservers.conf} when running in @option{--daemon} mode.
+value for @var{file} is @file{dirmngr_ldapservers.conf}.
 
 This server list file contains one LDAP server per line in the format
 

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161111/6129045e/attachment.sig>

From wk at gnupg.org  Fri Nov 11 08:58:03 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Nov 2016 08:58:03 +0100
Subject: [PATCH] systemd: Include config for socket-activated user
 services.
In-Reply-To: <877f8tctx7.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Thu, 27 Oct 2016 18:24:04 -0400")
References: <20161027181918.920-1-dkg@fifthhorseman.net>
 <87lgx962db.fsf@wheatstone.g10code.de>
 <877f8tctx7.fsf@alice.fifthhorseman.net>
Message-ID: <87inrue9dg.fsf@wheatstone.g10code.de>

Hi,

it seems to be futile trying to stop Windowization of all our precious
Linux boxes.  Swinging my Stenton I am dropping those examples files
onto the package.

Commit 57e95f5.  Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161111/0e1c9cdd/attachment.sig>

From wk at gnupg.org  Fri Nov 11 09:18:32 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Nov 2016 09:18:32 +0100
Subject: [PATCH] gpg, gpgsm, python: atomic directory creation
In-Reply-To: <1476867847-24352-1-git-send-email-alon.barlev@gmail.com> (Alon
 Bar-Lev's message of "Wed, 19 Oct 2016 12:04:07 +0300")
References: <87a8e0pvmh.fsf@wheatstone.g10code.de>
 <1476867847-24352-1-git-send-email-alon.barlev@gmail.com>
Message-ID: <877f8ae8fb.fsf@wheatstone.g10code.de>

On Wed, 19 Oct 2016 11:04, alon.barlev at gmail.com said:
> * lang/python/tests/Makefile.am,
> tests/gpg/Makefile.am,
> tests/gpgsm/Makefile.am: atomic directory creation.

Thanks.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161111/5f40e81a/attachment.sig>

From dkg at fifthhorseman.net  Thu Nov 10 23:08:40 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 10 Nov 2016 14:08:40 -0800
Subject: gpgme.info "UI Server Encrypt" section has unintelligible client and
 server conversation
Message-ID: <87k2cbvvh3.fsf@alice.fifthhorseman.net>

Hi GnuPG folks--

The end of the "UI Server Encrypt" page of gpgme.info has the following
not-very-useful description:

-----------
Here is an example of a complete encryption sequence; client lines are
indicated by a C:, server responses by C::

         C:     S:     C:     S:     C:     S:     C:     S:     S:     C:     \
S:     C:     S:     C:     S: 

-----------

the source for this (doc/uiserver.texi) says:

@smallexample
@group
  @clnt RESET
  @srvr OK
  @clnt RECIPIENT foo@@example.net
  @srvr OK
  @clnt RECIPIENT bar@@example.com
  @srvr OK
  @clnt PREP_ENCRYPT
  @srvr S PROTOCOL OpenPGP
  @srvr OK
  @clnt INPUT FD=17
  @srvr OK
  @clnt OUTPUT FD=18
  @srvr OK
  @clnt ENCRYPT
  @srvr OK
@end group
@end smallexample

i'm not skilled enough with .texi to know what needs to be fixed here,
but i thought maybe someone else would know.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: </pipermail/attachments/20161110/f14908d4/attachment.sig>

From dkg at fifthhorseman.net  Fri Nov 11 06:53:18 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 11 Nov 2016 14:53:18 +0900
Subject: GnuPG UI Server Protocol: verification status for DECRYPT?
Message-ID: <87h97ewoj5.fsf@alice.fifthhorseman.net>

Hi all--

I'm trying to understand the GnuPG UI Server Protocol, as documented in
gpgme.info. I'm working with gpgme from git master and gpg quite close
to git master (2.1.15 plus many dozens of patches from git)

the DECRYPT command has a --no-verify flag, which implies that sometimes
it does verify the message.  But it does not indicate how to retrieve
the status of the signature verification (if any).

the VERIFY command documents a "SIGSTATUS" status line.  Should this be
provided as well for DECRYPT?  I tried the following sequence with
"gpgme-tool" and "gpg --server", with a signed+encrypted file attached
to FD 5 and an output file connected to FD 6:

    INPUT FD=5
    OUTPUT FD=6
    DECRYPT

and while both programs successfully decrypted the file, neither of them
produced a status like of type SIGSTATUS.  "gpg --server" produced no
output status lines, and "gpgme-tool" produced only PROGRESS status
lines.  If i gave "gpg --server" a --status-fd argument, then it
produced some status lines like "VALIDSIG" on that file descriptor, but
nothing that reflected the GnuPG UI Server Protocol documentation.

Am i misunderstanding something?  is there no way in the GnuPG UI Server
Protocol to get a signature status report on an encrypted+signed
message?  Or are "gpg --server" and "gpgme-tool" not intended to be
implementations of the GnuPG UI Server Protocol at all and i should look
elsewhere?

         --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: </pipermail/attachments/20161111/dd66a307/attachment.sig>

From dkg at fifthhorseman.net  Fri Nov 11 06:25:19 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 11 Nov 2016 14:25:19 +0900
Subject: [GPGME PATCH] doc: Correct text about gpgme_cancel_async.
Message-ID: <20161111052519.29955-1-dkg@fifthhorseman.net>

* doc/gpgme.texi: Documentation about gpgme_cancel_async should refer
to the correct name.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 doc/gpgme.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index c790537..5a0b8ea 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -6537,7 +6537,7 @@ case the state of @var{ctx} is not modified).
 
 
 @deftypefun gpgme_ctx_t gpgme_cancel_async (@w{gpgme_ctx_t @var{ctx}})
-The function @code{gpgme_cancel} attempts to cancel a pending
+The function @code{gpgme_cancel_async} attempts to cancel a pending
 operation in the context @var{ctx}.  This can be called by any thread
 at any time after starting an operation on the context, but will not
 take effect immediately.  The actual cancellation happens at the next
-- 
2.10.2



From dkg at fifthhorseman.net  Fri Nov 11 07:16:43 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 11 Nov 2016 15:16:43 +0900
Subject: [GPGME PATCH] doc: Correct deftypefun for
 gpgme_op_decrypt_verify_start.
Message-ID: <20161111061643.30814-1-dkg@fifthhorseman.net>

* doc/gpgme.texi: Documentationabout gpgme_op_decrypt_verify_start was
stored under the name gpgme_op_decrypt_verify instead.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 doc/gpgme.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index 5a0b8ea..78c173f 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -5117,7 +5117,7 @@ secret key could not be retrieved, and passes through any errors that
 are reported by the crypto engine support routines.
 @end deftypefun
 
- at deftypefun gpgme_error_t gpgme_op_decrypt_verify (@w{gpgme_ctx_t @var{ctx}}, @w{gpgme_data_t @var{cipher}}, @w{gpgme_data_t @var{plain}})
+ at deftypefun gpgme_error_t gpgme_op_decrypt_verify_start (@w{gpgme_ctx_t @var{ctx}}, @w{gpgme_data_t @var{cipher}}, @w{gpgme_data_t @var{plain}})
 The function @code{gpgme_op_decrypt_verify_start} initiates a
 @code{gpgme_op_decrypt_verify} operation.  It can be completed by
 calling @code{gpgme_wait} on the context.  @xref{Waiting For
-- 
2.10.2



From dkg at fifthhorseman.net  Fri Nov 11 08:49:28 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 11 Nov 2016 16:49:28 +0900
Subject: [GPGME PATCH] core: Enable extraction of session keys.
Message-ID: <20161111074928.3780-1-dkg@fifthhorseman.net>

* src/gpgme.c (gpgme_set_export_session_keys): New function.
(gpgme_get_export_session_keys): New function.
* src/gpgme.h.in (struct _gpgme_op_decrypt_result): Add session_key
member.
(gpgme_{set,get}_export_session_keys): Declare new functions.
* src/libgpgme.vers, src/gpgme.def: Export new functions in shared
object.
* src/engine.h: (_gpgme_engine_op_decrypt) Add export_session_key
parameter.
(_gpgme_engine_op_decrypt_verify): Add export_session_key parameter.
* src/engine-backend.h: (struct engine_ops): Change function
pointer declarations to match.
* src/context.h (struct gpgme_context): Add export_session_keys member.
* src/decrypt.c (release_op_data): Free result.session_key.
(_gpgme_decrypt_status_handler): Store a copy of the exported session
key.
(decrypt_start): Pass export_session_keys from the context.
* src/decrypt-verify.c (decrypt_verify_start): Pass
export_session_keys from context.
* src/engine.c (_gpgme_engine_op_decrypt): Pass through
export_session_key flag.
(_gpgme_engine_op_decrypt_verify): Pass through export_session_key
flag.
* src/engine-gpg.c (gpg_decrypt): If export_session_key is set, add
--export-session-key to argument list.
* src/engine-gpgsm.c (gpgsm_decrypt): Ignore export_session_key for
now, since gpgsm offers no such mechanism.
* src/engine-uiserver.c (_uiserver_decrypt): If export_session_key is
set, add --export-session-key flag to cmd.
* doc/gpgme.texi: Document new functions and session_key member of
decrypt_result_t.
* doc/uiserver.texi: Add --export-session-key flag to DECRYPT command.

--

gpg(1) documents session key export as useful for key escrow, and is
rightly dubious of that use case.  However, session key export is also
useful in other use cases.  Two examples from MUA development (where
this functionality would be specifically useful to me right now):

 * If the MUA stores a local copy of the session key upon decrypting
   the message, it can re-decrypt the message without expensive
   asymmetric operations.  When rendering a thread with dozens of
   encrypted messages, this can represent a significant speedup.

 * A user may have expired encryption-capable secret key material,
   along with many messages encrypted to that material.  If she stores
   the session keys for those messages she wants to keep, she can
   destroy her secret key material and make any messages she has
   deleted completely unrecoverable, even to an attacker who gets her
   remaining secret keys in the future.

This patchset makes a two specific implementation decisions that could
have gone in different ways.  I welcome feedback on preferred outcomes.

 0) session key representation: we currently represent the session key
    as an opaque textual string, rather than trying to provide any
    sort of in-memory structure.  While it wouldn't be hard to parse
    the data produced by gpg's --export-session-key, I chose to use
    the opaque string rather than lock in a particular data format.

 1) API/ABI: i've added a member to gpgme_op_decrypt_result_t.  This
    has the potential to cause an out-of-bound memory access if
    someone uses code compiled against the newer verision, but linked
    at runtime against an older version.  I've attempted to limit that
    risk by documenting that users must verify
    gpgme_get_export_session_keys() before accessing this new struct
    member -- this means that code expecting this capability will
    require the symbol at link-time, and will refuse to link against
    older versions.

    Another approach to solving this problem would be to avoid
    modifying gpgme_op_decrypt_result_t, and to introduce instead a
    new function gpgme_op_session_key(), which could be called in the
    same places as gpgme_op_decrypt_result().  Depending on the
    representation of the session key, this might introduce new
    memory-management burdens on the user of the library, and the
    session key is certainly part of a decryption result, so it seemed
    simpler to go with what i have here.

If anyone has strong preferences that these choices should be solved
in a different way, i'm happy to hear them.

Additionally, I note that i'm also still pretty unclear about how the
"UI Server" fits into this whole ecosystem. In particular, I don't
know whether it's kosher to just add an --export-session-key flag to
the DECRYPT operation without actually having implemented it anywhere,
but i don't see where i would actually implement it either :/

If this patch (or some variant) is adopted, i will supply another
patch that permits offering a session key during decryption (e.g. "gpg
--override-session-key"), but I wanted to get these implementation
choices ironed out first.

Gnupg-Bug-Id: 2754
Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 doc/gpgme.texi        | 38 ++++++++++++++++++++++++++++++++++++++
 doc/uiserver.texi     | 10 ++++++----
 src/context.h         |  3 +++
 src/decrypt-verify.c  |  2 +-
 src/decrypt.c         | 11 ++++++++++-
 src/engine-backend.h  |  4 ++--
 src/engine-gpg.c      |  5 ++++-
 src/engine-gpgsm.c    |  5 ++++-
 src/engine-uiserver.c | 16 +++++++++-------
 src/engine.c          |  8 ++++----
 src/engine.h          |  6 ++++--
 src/gpgme.c           | 24 ++++++++++++++++++++++++
 src/gpgme.def         |  2 ++
 src/gpgme.h.in        | 11 +++++++++++
 src/libgpgme.vers     |  3 +++
 15 files changed, 125 insertions(+), 23 deletions(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index 78c173f..1f6e00b 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -191,6 +191,7 @@ Context Attributes
 * Text Mode::                     Choosing canonical text mode.
 * Offline Mode::                  Choosing offline mode.
 * Included Certificates::         Including a number of certificates.
+* Exporting Session Keys::        Requesting session keys upon decryption.
 * Key Listing Mode::              Selecting key listing mode.
 * Passphrase Callback::           Getting the passphrase from the user.
 * Progress Meter Callback::       Being informed about the progress.
@@ -2351,6 +2352,7 @@ started.  In fact, these references are accessed through the
 * Offline Mode::                  Choosing offline mode.
 * Pinentry Mode::                 Choosing the pinentry mode.
 * Included Certificates::         Including a number of certificates.
+* Exporting Session Keys::        Requesting session keys upon decryption.
 * Key Listing Mode::              Selecting key listing mode.
 * Passphrase Callback::           Getting the passphrase from the user.
 * Progress Meter Callback::       Being informed about the progress.
@@ -2641,6 +2643,29 @@ certificates to include into an S/MIME signed message.
 @end deftypefun
 
 
+ at node Exporting Session Keys
+ at subsection Exporting Session Keys
+ at cindex context, exporting session keys
+ at cindex Exporting Session Keys
+ at cindex exporting session keys
+
+ at deftypefun void gpgme_set_export_session_keys (@w{gpgme_ctx_t @var{ctx}}, @w{int @var{yes}})
+The function @code{gpgme_set_export_session_keys} specifies whether
+the context should try to export the symmetric session key when
+decrypting data.  By default, session keys are not exported.
+
+Session keys are not exported if @var{yes} is zero, and
+enabled otherwise.
+ at end deftypefun
+
+ at deftypefun int gpgme_get_export_session_keys (@w{gpgme_ctx_t @var{ctx}})
+The function @code{gpgme_get_export_session_keys} returns @code{1} if
+the context will try to export the symmetric session key when
+decrypting, and @code{0} if not, or if @var{ctx} is not a valid
+pointer.
+ at end deftypefun
+
+
 @node Key Listing Mode
 @subsection Key Listing Mode
 @cindex key listing mode
@@ -4777,6 +4802,19 @@ This is a linked list of recipients to which this message was encrypted.
 @item char *file_name
 This is the filename of the original plaintext message file if it is
 known, otherwise this is a null pointer.
+
+ at item char *session_key
+A textual representation (null-terminated string) of the session key
+used in symmetric encryption of the message, if the context has been
+set to export session keys (see @code{gpgme_get_export_session_keys}
+and @code{gpgme_set_export_session_keys}), and a session key was
+available for the most recent decryption operation.  Otherwise, this
+is a null pointer.
+
+You should never access this member of a
+ at code{gpgme_op_decrypt_result_t} without first ensuring that
+ at code{gpgme_get_export_session_keys} returns non-zero for the
+reporting context.
 @end table
 @end deftp
 
diff --git a/doc/uiserver.texi b/doc/uiserver.texi
index 16e8f85..94c378b 100644
--- a/doc/uiserver.texi
+++ b/doc/uiserver.texi
@@ -260,12 +260,14 @@ encoded. For details on the file descriptor, see the description of
 @noindent
 The decryption is started with the command:
 
- at deffn Command DECRYPT - at w{}-protocol=@var{name} [- at w{}-no-verify]
+ at deffn Command DECRYPT - at w{}-protocol=@var{name} [- at w{}-no-verify] [- at w{}-export-session-key]
 @var{name} is the encryption protocol used for the message. For a
 description of the allowed protocols see the @code{ENCRYPT} command.
-This argument is mandatory.  If the option @option{--no-verify} is given,
-the server should not try to verify a signature, in case the input data
-is an OpenPGP combined message.
+This argument is mandatory.  If the option @option{--no-verify} is
+given, the server should not try to verify a signature, in case the
+input data is an OpenPGP combined message. If the option
+ at option{--export-session-key} is given and the underlying engine knows
+how to export the session key, it will appear on a status line
 @end deffn
 
 
diff --git a/src/context.h b/src/context.h
index 00e2e77..94935c8 100644
--- a/src/context.h
+++ b/src/context.h
@@ -111,6 +111,9 @@ struct gpgme_context
    * unmodified string, as received form gpg, will be returned.  */
   unsigned int raw_description : 1;
 
+  /* True if session keys should be exported upon decryption.  */
+  unsigned int export_session_keys : 1;
+
   /* Flags for keylist mode.  */
   gpgme_keylist_mode_t keylist_mode;
 
diff --git a/src/decrypt-verify.c b/src/decrypt-verify.c
index a334f86..00d256a 100644
--- a/src/decrypt-verify.c
+++ b/src/decrypt-verify.c
@@ -77,7 +77,7 @@ decrypt_verify_start (gpgme_ctx_t ctx, int synchronous,
   _gpgme_engine_set_status_handler (ctx->engine,
 				    decrypt_verify_status_handler, ctx);
 
-  return _gpgme_engine_op_decrypt_verify (ctx->engine, cipher, plain);
+  return _gpgme_engine_op_decrypt_verify (ctx->engine, cipher, plain, ctx->export_session_keys);
 }
 
 
diff --git a/src/decrypt.c b/src/decrypt.c
index 51e4292..49c735c 100644
--- a/src/decrypt.c
+++ b/src/decrypt.c
@@ -63,6 +63,9 @@ release_op_data (void *hook)
   if (opd->result.file_name)
     free (opd->result.file_name);
 
+  if (opd->result.session_key)
+    free (opd->result.session_key);
+
   while (recipient)
     {
       gpgme_recipient_t next = recipient->next;
@@ -277,6 +280,12 @@ _gpgme_decrypt_status_handler (void *priv, gpgme_status_code_t code,
       opd->last_recipient_p = &(*opd->last_recipient_p)->next;
       break;
 
+    case GPGME_STATUS_SESSION_KEY:
+      if (opd->result.session_key)
+        free (opd->result.session_key);
+      opd->result.session_key = strdup(args);
+      break;
+
     case GPGME_STATUS_NO_SECKEY:
       {
 	gpgme_recipient_t rec = opd->result.recipients;
@@ -381,7 +390,7 @@ decrypt_start (gpgme_ctx_t ctx, int synchronous,
 
   _gpgme_engine_set_status_handler (ctx->engine, decrypt_status_handler, ctx);
 
-  return _gpgme_engine_op_decrypt (ctx->engine, cipher, plain);
+  return _gpgme_engine_op_decrypt (ctx->engine, cipher, plain, ctx->export_session_keys);
 }
 
 
diff --git a/src/engine-backend.h b/src/engine-backend.h
index a8b1ac6..144b156 100644
--- a/src/engine-backend.h
+++ b/src/engine-backend.h
@@ -62,9 +62,9 @@ struct engine_ops
   gpgme_error_t (*set_locale) (void *engine, int category, const char *value);
   gpgme_error_t (*set_protocol) (void *engine, gpgme_protocol_t protocol);
   gpgme_error_t (*decrypt) (void *engine, gpgme_data_t ciph,
-			    gpgme_data_t plain);
+			    gpgme_data_t plain, int export_session_key);
   gpgme_error_t (*decrypt_verify) (void *engine, gpgme_data_t ciph,
-				   gpgme_data_t plain);
+				   gpgme_data_t plain, int export_session_key);
   gpgme_error_t (*delete) (void *engine, gpgme_key_t key, int allow_secret);
   gpgme_error_t (*edit) (void *engine, int type, gpgme_key_t key,
 			 gpgme_data_t out, gpgme_ctx_t ctx /* FIXME */);
diff --git a/src/engine-gpg.c b/src/engine-gpg.c
index 7725a00..0e43c24 100644
--- a/src/engine-gpg.c
+++ b/src/engine-gpg.c
@@ -1550,13 +1550,16 @@ add_input_size_hint (engine_gpg_t gpg, gpgme_data_t data)
 
 
 static gpgme_error_t
-gpg_decrypt (void *engine, gpgme_data_t ciph, gpgme_data_t plain)
+gpg_decrypt (void *engine, gpgme_data_t ciph, gpgme_data_t plain, int export_session_key)
 {
   engine_gpg_t gpg = engine;
   gpgme_error_t err;
 
   err = add_arg (gpg, "--decrypt");
 
+  if (!err && export_session_key)
+    err = add_arg (gpg, "--show-session-key");
+
   /* Tell the gpg object about the data.  */
   if (!err)
     err = add_arg (gpg, "--output");
diff --git a/src/engine-gpgsm.c b/src/engine-gpgsm.c
index a815cf0..2ff353b 100644
--- a/src/engine-gpgsm.c
+++ b/src/engine-gpgsm.c
@@ -1120,10 +1120,13 @@ gpgsm_reset (void *engine)
 
 
 static gpgme_error_t
-gpgsm_decrypt (void *engine, gpgme_data_t ciph, gpgme_data_t plain)
+gpgsm_decrypt (void *engine, gpgme_data_t ciph, gpgme_data_t plain, int export_session_key)
 {
   engine_gpgsm_t gpgsm = engine;
   gpgme_error_t err;
+  /* gpgsm is not capable of exporting session keys right now, so we
+   * will ignore this if requested. */
+  (void)export_session_key;
 
   if (!gpgsm)
     return gpg_error (GPG_ERR_INV_VALUE);
diff --git a/src/engine-uiserver.c b/src/engine-uiserver.c
index 47b7dc3..26f0d18 100644
--- a/src/engine-uiserver.c
+++ b/src/engine-uiserver.c
@@ -960,7 +960,8 @@ uiserver_reset (void *engine)
 
 static gpgme_error_t
 _uiserver_decrypt (void *engine, int verify,
-		   gpgme_data_t ciph, gpgme_data_t plain)
+		   gpgme_data_t ciph, gpgme_data_t plain,
+                   int export_session_key)
 {
   engine_uiserver_t uiserver = engine;
   gpgme_error_t err;
@@ -978,8 +979,9 @@ _uiserver_decrypt (void *engine, int verify,
   else
     return gpgme_error (GPG_ERR_UNSUPPORTED_PROTOCOL);
 
-  if (asprintf (&cmd, "DECRYPT%s%s", protocol,
-		verify ? "" : " --no-verify") < 0)
+  if (asprintf (&cmd, "DECRYPT%s%s%s", protocol,
+		verify ? "" : " --no-verify",
+                export_session_key ? " --export-session-key" : "") < 0)
     return gpg_error_from_syserror ();
 
   uiserver->input_cb.data = ciph;
@@ -1006,16 +1008,16 @@ _uiserver_decrypt (void *engine, int verify,
 
 
 static gpgme_error_t
-uiserver_decrypt (void *engine, gpgme_data_t ciph, gpgme_data_t plain)
+uiserver_decrypt (void *engine, gpgme_data_t ciph, gpgme_data_t plain, int export_session_key)
 {
-  return _uiserver_decrypt (engine, 0, ciph, plain);
+  return _uiserver_decrypt (engine, 0, ciph, plain, export_session_key);
 }
 
 
 static gpgme_error_t
-uiserver_decrypt_verify (void *engine, gpgme_data_t ciph, gpgme_data_t plain)
+uiserver_decrypt_verify (void *engine, gpgme_data_t ciph, gpgme_data_t plain, int export_session_key)
 {
-  return _uiserver_decrypt (engine, 1, ciph, plain);
+  return _uiserver_decrypt (engine, 1, ciph, plain, export_session_key);
 }
 
 
diff --git a/src/engine.c b/src/engine.c
index 4e513b6..b43f683 100644
--- a/src/engine.c
+++ b/src/engine.c
@@ -653,7 +653,7 @@ _gpgme_engine_set_protocol (engine_t engine, gpgme_protocol_t protocol)
 
 gpgme_error_t
 _gpgme_engine_op_decrypt (engine_t engine, gpgme_data_t ciph,
-			  gpgme_data_t plain)
+			  gpgme_data_t plain, int export_session_key)
 {
   if (!engine)
     return gpg_error (GPG_ERR_INV_VALUE);
@@ -661,13 +661,13 @@ _gpgme_engine_op_decrypt (engine_t engine, gpgme_data_t ciph,
   if (!engine->ops->decrypt)
     return gpg_error (GPG_ERR_NOT_IMPLEMENTED);
 
-  return (*engine->ops->decrypt) (engine->engine, ciph, plain);
+  return (*engine->ops->decrypt) (engine->engine, ciph, plain, export_session_key);
 }
 
 
 gpgme_error_t
 _gpgme_engine_op_decrypt_verify (engine_t engine, gpgme_data_t ciph,
-				 gpgme_data_t plain)
+				 gpgme_data_t plain, int export_session_key)
 {
   if (!engine)
     return gpg_error (GPG_ERR_INV_VALUE);
@@ -675,7 +675,7 @@ _gpgme_engine_op_decrypt_verify (engine_t engine, gpgme_data_t ciph,
   if (!engine->ops->decrypt_verify)
     return gpg_error (GPG_ERR_NOT_IMPLEMENTED);
 
-  return (*engine->ops->decrypt_verify) (engine->engine, ciph, plain);
+  return (*engine->ops->decrypt_verify) (engine->engine, ciph, plain, export_session_key);
 }
 
 
diff --git a/src/engine.h b/src/engine.h
index 15b0b5d..512ac19 100644
--- a/src/engine.h
+++ b/src/engine.h
@@ -83,10 +83,12 @@ _gpgme_engine_set_colon_line_handler (engine_t engine,
 				      engine_colon_line_handler_t fnc,
 				      void *fnc_value);
 gpgme_error_t _gpgme_engine_op_decrypt (engine_t engine, gpgme_data_t ciph,
-					gpgme_data_t plain);
+					gpgme_data_t plain,
+                                        int export_session_key);
 gpgme_error_t _gpgme_engine_op_decrypt_verify (engine_t engine,
 					       gpgme_data_t ciph,
-					       gpgme_data_t plain);
+					       gpgme_data_t plain,
+                                               int export_session_key);
 gpgme_error_t _gpgme_engine_op_delete (engine_t engine, gpgme_key_t key,
 				       int allow_secret);
 gpgme_error_t _gpgme_engine_op_edit (engine_t engine, int type,
diff --git a/src/gpgme.c b/src/gpgme.c
index 443cb76..7b14b5e 100644
--- a/src/gpgme.c
+++ b/src/gpgme.c
@@ -518,6 +518,30 @@ gpgme_get_armor (gpgme_ctx_t ctx)
 }
 
 
+/* Enable or disable the exporting session keys upon decryption.  */
+void
+gpgme_set_export_session_keys (gpgme_ctx_t ctx, int export_session_keys)
+{
+  TRACE2 (DEBUG_CTX, "gpgme_set_export_session_keys", ctx, "export_session_keys=%i (%s)",
+	  export_session_keys, export_session_keys ? "yes" : "no");
+
+  if (!ctx)
+    return;
+
+  ctx->export_session_keys = !!export_session_keys;
+}
+
+
+/* Return whether this context will export session keys upon decryption.  */
+int
+gpgme_get_export_session_keys (gpgme_ctx_t ctx)
+{
+  TRACE2 (DEBUG_CTX, "gpgme_get_export_session_keys", ctx, "ctx->export_session_keys=%i (%s)",
+	  ctx->export_session_keys, ctx->export_session_keys ? "yes" : "no");
+  return ctx->export_session_keys;
+}
+
+
 /* Enable or disable the use of the special textmode.  Textmode is for
   example used for the RFC2015 signatures; note that the updated RFC
   3156 mandates that the MUA does some preparations so that textmode
diff --git a/src/gpgme.def b/src/gpgme.def
index 2f6837d..35f4341 100644
--- a/src/gpgme.def
+++ b/src/gpgme.def
@@ -252,5 +252,7 @@ EXPORTS
     gpgme_op_query_swdb                   @189
     gpgme_op_query_swdb_result            @190
 
+    gpgme_set_export_session_keys         @191
+    gpgme_get_export_session_keys         @192
 ; END
 
diff --git a/src/gpgme.h.in b/src/gpgme.h.in
index 4f470a0..2a0e16e 100644
--- a/src/gpgme.h.in
+++ b/src/gpgme.h.in
@@ -1037,6 +1037,13 @@ void gpgme_set_offline (gpgme_ctx_t ctx, int yes);
 /* Return non-zero if offline mode is set in CTX.  */
 int gpgme_get_offline (gpgme_ctx_t ctx);
 
+/* If YES is non-zero, try to return session keys during decryption,
+   do not otherwise.  */
+void gpgme_set_export_session_keys (gpgme_ctx_t ctx, int yes);
+
+/* Return non-zero if export_session_keys is set in CTX.  */
+int gpgme_get_export_session_keys (gpgme_ctx_t ctx);
+
 /* Use whatever the default of the backend crypto engine is.  */
 #define GPGME_INCLUDE_CERTS_DEFAULT	-256
 
@@ -1527,6 +1534,10 @@ struct _gpgme_op_decrypt_result
   /* The original file name of the plaintext message, if
      available.  */
   char *file_name;
+
+  /* A textual representation of the session key used to decrypt the
+   * message, if available */
+  char *session_key;
 };
 typedef struct _gpgme_op_decrypt_result *gpgme_decrypt_result_t;
 
diff --git a/src/libgpgme.vers b/src/libgpgme.vers
index 5457daa..9a3ecb2 100644
--- a/src/libgpgme.vers
+++ b/src/libgpgme.vers
@@ -125,6 +125,9 @@ GPGME_1.1 {
 
     gpgme_op_query_swdb;
     gpgme_op_query_swdb_result;
+
+    gpgme_set_export_session_keys;
+    gpgme_get_export_session_keys;
 };
 
 
-- 
2.10.2



From dkg at fifthhorseman.net  Fri Nov 11 00:47:48 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 10 Nov 2016 15:47:48 -0800
Subject: [GPGME PATCH] core: Non-zero values should set _armor, _textmode,
 and _online.
Message-ID: <20161110234748.11936-1-dkg@fifthhorseman.net>

* src/gpgme.c (gpgme_set_armor, gpgme_set_textmode,
gpgme_set_offline): Ensure that non-zero values actually set the
appropriate internal bit.

--

The documentation for these functions says things like "disabled if
YES is zero, and enabled otherwise", where YES is an integer.
However, if you pass an even integer, it will be aliased back to 0
because the context member variables are declared as single bits.

This should make the implementation match the documentation.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 src/gpgme.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gpgme.c b/src/gpgme.c
index 6d0dbff..443cb76 100644
--- a/src/gpgme.c
+++ b/src/gpgme.c
@@ -504,7 +504,7 @@ gpgme_set_armor (gpgme_ctx_t ctx, int use_armor)
   if (!ctx)
     return;
 
-  ctx->use_armor = use_armor;
+  ctx->use_armor = !!use_armor;
 }
 
 
@@ -531,7 +531,7 @@ gpgme_set_textmode (gpgme_ctx_t ctx, int use_textmode)
   if (!ctx)
     return;
 
-  ctx->use_textmode = use_textmode;
+  ctx->use_textmode = !!use_textmode;
 }
 
 /* Return the state of the textmode flag.  */
@@ -555,7 +555,7 @@ gpgme_set_offline (gpgme_ctx_t ctx, int offline)
   if (!ctx)
     return;
 
-  ctx->offline = offline;
+  ctx->offline = !!offline;
 }
 
 /* Return the state of the offline flag.  */
-- 
2.10.2



From wk at gnupg.org  Fri Nov 11 15:12:47 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Nov 2016 15:12:47 +0100
Subject: gpgme.info "UI Server Encrypt" section has unintelligible client
 and server conversation
In-Reply-To: <87k2cbvvh3.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Thu, 10 Nov 2016 14:08:40 -0800")
References: <87k2cbvvh3.fsf@alice.fifthhorseman.net>
Message-ID: <87oa1mayw0.fsf@wheatstone.g10code.de>

On Thu, 10 Nov 2016 23:08, dkg at fifthhorseman.net said:

> The end of the "UI Server Encrypt" page of gpgme.info has the following
> not-very-useful description:

makeinfo must have changed the semantics of macros since 2008.  Fixed.
Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161111/97023a73/attachment.sig>

From wk at gnupg.org  Fri Nov 11 15:16:35 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Nov 2016 15:16:35 +0100
Subject: [GPGME PATCH] core: Non-zero values should set _armor, _textmode,
 and _online.
In-Reply-To: <20161110234748.11936-1-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Thu, 10 Nov 2016 15:47:48 -0800")
References: <20161110234748.11936-1-dkg@fifthhorseman.net>
Message-ID: <87k2caaypo.fsf@wheatstone.g10code.de>

On Fri, 11 Nov 2016 00:47, dkg at fifthhorseman.net said:
> * src/gpgme.c (gpgme_set_armor, gpgme_set_textmode,
> gpgme_set_offline): Ensure that non-zero values actually set the
> appropriate internal bit.

Pretty obvious fix.  Thanks.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161111/b202c567/attachment.sig>

From lists at ssl-mail.com  Fri Nov 11 15:45:13 2016
From: lists at ssl-mail.com (lists at ssl-mail.com)
Date: Fri, 11 Nov 2016 06:45:13 -0800
Subject: packaged gpg 2.1.x can't retrieve any keys from keyservers.. is there
 any upstream fix or progress?
Message-ID: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>

I've lost track of where the end of any thread on this is :-/

At the moment, none of our package-installed GPG 2.1.x are able to retrieve keys.

It's causing lots of grief here.  I need to decide whether to remove/blacklist it from all our machines, or rollback to some working version, etc. 

What's the status on the bug

gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)"  
https://bugs.gnupg.org/gnupg/issue2745

?

I've tried to provide every bit of requested info so far.  If there's more needed let me know exactly what.



From wk at gnupg.org  Sat Nov 12 12:11:00 2016
From: wk at gnupg.org (Werner Koch)
Date: Sat, 12 Nov 2016 12:11:00 +0100
Subject: gpg-agent blocking in genkey etc.
Message-ID: <87k2c99cmz.fsf@wheatstone.g10code.de>

Hi!

yesterday we tracked down a bug in gpg-agent which inhibited a second
connection to the gpg-agent while the gpg-agent was creating a key.

After some more testing we will soon release libgpg-error 1.25 and gnupg
2.1.16 to fix those blocking problems.

There are to reasons for the problem:

The key generation requires reading from /dev/random.  The first step
Libgcrypt does is to set a mutex for its internal random pool.  If a
second connection (i.e. nPth thread) need to get a random number (also
key generation but also for signing) it would block right at that mutex.
That would be fine because we want to serialize access to the RNG.
However an arbitrary third thread (e.g. another connection) would not be
able to run because nPth (our user land threding library) did not know
about lock inside Libgcrypt and thus it can't schedule any threads.

The solution to this is straightforward: Libgpg-error (which actually
does the locking) has been fixed to also use its "system call clamp" for
the locking calls.  This clamp is set by gpg-agent to connect
libgpg-error with the Pth library.  That thingy has originally been
implemented for Libgcrypt's estream I/O system but it needs to be used
for all other blocking calls as well.  The fix will go into Libgpg-error
1.25.

Now that this has been solved things should work.  But they won't:
Libgcrypt reads from /dev/random and that is, as we all know, a blocking
system call.  Same problem again.  Fortunately Libgcrypt uses select
before the read and calls back into gpg-agent every few seconds with a
PROGRESS notification.  gpg-agent now catches this notification and
takes a short nap (100ms via npth_usleep) so that other threads can run.
The delay is not a problem because it gives the kernel time to collect
entropy.  This fix will be released with 2.1.16.

That solution works but gpg-agent is not every responsive because
re-scheduling takes places only every few seconds when a PROGRESS
notification is received.  A better solution is to use a system call
clamp in Libgcrypt as well.  That can be easily done by reading the
clamp already known to libgpg-error.  However, there are a few
peculiarities which won't allow us to do this in an updated Libgcrypt
1.7.  Thus the final fix will work only with the not-yet released
Libgcrypt 1.8.0.  GnuPG 2.1.16 will be prepared for that.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161112/d830e7a7/attachment.sig>

From wk at gnupg.org  Sat Nov 12 20:24:21 2016
From: wk at gnupg.org (Werner Koch)
Date: Sat, 12 Nov 2016 20:24:21 +0100
Subject: [PATCH libgpg-error 4/4] estream: Support 'es_poll' on Windows.
In-Reply-To: <20161019102044.6469-4-justus@g10code.com> (Justus Winter's
 message of "Wed, 19 Oct 2016 12:20:44 +0200")
References: <20161019102044.6469-1-justus@g10code.com>
 <20161019102044.6469-4-justus@g10code.com>
Message-ID: <87a8d47b8a.fsf@wheatstone.g10code.de>

Hi!

The code looks fine.  I added a comment that the origin of the code is
GPGME and pushed it.  Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161112/a5a90e26/attachment.sig>

From david at hardeman.nu  Sun Nov 13 16:50:02 2016
From: david at hardeman.nu (David =?utf-8?b?SMOkcmRlbWFu?=)
Date: Sun, 13 Nov 2016 16:50:02 +0100
Subject: [PATCH] scdaemon: Fix status info encoding
Message-ID: <147905220269.27567.2259412821780462064.stgit@zeus.hardeman.nu>

I've been playing around a bit with private data objects using an OpenPGP
card when I noticed that writing binary data to an object and then reading
it back would sometime alter the data.

Example:
  $ echo -n "%41" > binfile
  $ od -tx1 binfile
  0000000 25 34 31
  0000003

  $ gpg --card-edit
  ....
  gpg/card> privatedo 1 < binfile

  gpg/card> verify
  ...
  Private DO 1 .....: A

Last line should have been:
  Private DO 1 .....: %41

Turns out that scdaemon does not properly escape the '%' character, meaning
that gpg-agent and gpg parse the unescaped '%' character.

Signed-off-by: David H?rdeman <david at hardeman.nu>
---
 scd/command.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scd/command.c b/scd/command.c
index 3584593..a1fa060 100644
--- a/scd/command.c
+++ b/scd/command.c
@@ -2137,7 +2137,7 @@ send_status_info (ctrl_t ctrl, const char *keyword, ...)
         }
       for ( ; valuelen && n < DIM (buf)-2; n++, valuelen--, value++)
         {
-          if (*value < ' ' || *value == '+')
+          if (*value < ' ' || *value == '+' || *value == '%')
             {
               sprintf (p, "%%%02X", *value);
               p += 3;



From gniibe at fsij.org  Mon Nov 14 02:37:10 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 14 Nov 2016 10:37:10 +0900
Subject: [PATCH] scdaemon: Fix status info encoding
In-Reply-To: <147905220269.27567.2259412821780462064.stgit@zeus.hardeman.nu>
References: <147905220269.27567.2259412821780462064.stgit@zeus.hardeman.nu>
Message-ID: <a2e0ea67-29e1-fafb-1d23-0c1ca7c74043@fsij.org>

On 11/14/2016 12:50 AM, David H?rdeman wrote:
> Turns out that scdaemon does not properly escape the '%' character, meaning
> that gpg-agent and gpg parse the unescaped '%' character.

Thank you.

Fixed just as the function percent_plus_escape does; Double quote
should be also escaped.

Pushed to repo.
-- 


From dkg at fifthhorseman.net  Tue Nov 15 02:28:09 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 15 Nov 2016 10:28:09 +0900
Subject: gpgme 1.7.2 release?
Message-ID: <87h979cz12.fsf@alice.fifthhorseman.net>

Hi all--

is gpgme in a releasable state?  it would be nice for me to get a 1.7.2
release formalized that includes the python pyme?gpg module name change.

the debian freeze is fast approaching, and i would like to make sure
that we get this package name change into the next release of debian.

if gpgme isn't in a releasable state, what specifically is blocking it?

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: </pipermail/attachments/20161115/46b3273b/attachment-0001.sig>

From wk at gnupg.org  Tue Nov 15 08:33:57 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 15 Nov 2016 08:33:57 +0100
Subject: gpgme 1.7.2 release?
In-Reply-To: <87h979cz12.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 15 Nov 2016 10:28:09 +0900")
References: <87h979cz12.fsf@alice.fifthhorseman.net>
Message-ID: <87fumtyz6i.fsf@wheatstone.g10code.de>

On Tue, 15 Nov 2016 02:28, dkg at fifthhorseman.net said:

> is gpgme in a releasable state?  it would be nice for me to get a 1.7.2
> release formalized that includes the python pyme?gpg module name change.

Andre implemented the gpgme_set_sender interface for cpp and Qt
yesterday and thus we are ready for a release.  But wait, let me first
checkout our session key patches.

> the debian freeze is fast approaching, and i would like to make sure
> that we get this package name change into the next release of debian.

Okay.  I'll do a gpgme release today and only then gnupg 2.1.16 (which
we urgently need despite of the bugs given that the 2.15 is 3 months
old).


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161115/cf489397/attachment.sig>

From wk at gnupg.org  Tue Nov 15 10:42:34 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 15 Nov 2016 10:42:34 +0100
Subject: [GPGME PATCH] core: Enable extraction of session keys.
In-Reply-To: <20161111074928.3780-1-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Fri, 11 Nov 2016 16:49:28 +0900")
References: <20161111074928.3780-1-dkg@fifthhorseman.net>
Message-ID: <878tslyt85.fsf@wheatstone.g10code.de>

Hi!

Thanks for the patch.  I applied it with this comment:

    On the concern of adding a new field to a structure: It may not be
    clearly documented but we don't expect that a user ever allocates such
    a structure - those result structure may only be created bu gpgme and
    are read-only for the user.  Adding a new member constitutes a
    compatible ABI change and thus an older SO may not be used by code
    compiled with a header for the newer API.  Unless someone tinkers with
    the build system, this should never happen.  We have added new fields
    to result structure may times and I can't remember any problems.

I also went forward and implemented the override feature.  However I
changed the API for both:

    To keep the number of context manipulation functions at bay, this
    patches removes the just added gpgme_set_export_session_keys and
    gpgme_get_export_session_keys by flags for the generic context
    function.

This is because I consider the session-key exporting a rarely used
feature and thus the generic flag setting function is more appropriate.
This also instantly provides the Qt and cpp bindings.  Usage is pretty
simple:

  if (export_session_key)
    gpgme_set_ctx_flag (ctx, "export-session-key", "1");
  if (override_session_key)
    gpgme_set_ctx_flag (ctx, "override-session-key", override_session_key);

see tests/run-decrypt.c


Shalom-Salam,

   Werner
    

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161115/f5a57200/attachment.sig>

From dkg at fifthhorseman.net  Tue Nov 15 11:53:35 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 15 Nov 2016 19:53:35 +0900
Subject: [GPGME PATCH] doc: Fix typos.
Message-ID: <20161115105335.27142-1-dkg@fifthhorseman.net>

---
 doc/gpgme.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index eb06c20..fd396e0 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -2315,7 +2315,7 @@ structures such as @code{gpgme_decrypt_result_t}.  The corresponding
 retrieval functions such as @code{gpgme_op_decrypt_result} provide
 static access to the results after an operation completes.  Those
 structures shall be considered read-only and an application must not
-allocated such a strucure on its own.  The following interfaces make
+allocate such a structure on its own.  The following interfaces make
 it possible to detach a result structure from its associated context
 and give it a lifetime beyond that of the current operation or
 context.
-- 
2.10.2



From justus at g10code.com  Tue Nov 15 12:04:50 2016
From: justus at g10code.com (Justus Winter)
Date: Tue, 15 Nov 2016 12:04:50 +0100
Subject: [GPGME PATCH] doc: Fix typos.
In-Reply-To: <20161115105335.27142-1-dkg@fifthhorseman.net>
References: <20161115105335.27142-1-dkg@fifthhorseman.net>
Message-ID: <87lgwlt359.fsf@europa.jade-hamburg.de>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> ---
>  doc/gpgme.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Merged, thanks!

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20161115/02bd46a3/attachment.sig>

From dkg at fifthhorseman.net  Tue Nov 15 13:32:24 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 15 Nov 2016 21:32:24 +0900
Subject: [GPGME PATCH] core: Enable extraction of session keys.
In-Reply-To: <878tslyt85.fsf@wheatstone.g10code.de>
References: <20161111074928.3780-1-dkg@fifthhorseman.net>
 <878tslyt85.fsf@wheatstone.g10code.de>
Message-ID: <87eg2cappj.fsf@alice.fifthhorseman.net>

Hi Werner--

Thanks for the review and the followup.  This is great!

On Tue 2016-11-15 18:42:34 +0900, Werner Koch wrote:

> Thanks for the patch.  I applied it with this comment:
>
>     On the concern of adding a new field to a structure: It may not be
>     clearly documented but we don't expect that a user ever allocates such
>     a structure - those result structure may only be created bu gpgme and
>     are read-only for the user.  Adding a new member constitutes a
>     compatible ABI change and thus an older SO may not be used by code
>     compiled with a header for the newer API.  Unless someone tinkers with
>     the build system, this should never happen.  We have added new fields
>     to result structure may times and I can't remember any problems.

I'm not sure what this means exactly -- when you say "an older SO may
not be used by code compiled with a header for the newer API", are you
implying that there's mechanism to enforce that?  I don't think "tinkers
with the build system" is the issue -- there are many people who run
code on systems different than the build system.  The build system can
remain intact, but the version mismatch can happen during deployment.

the only mechanism i'm aware of to enforce the correct linkage is the
dynamic linker's requirement of mapping symbols (function names).  But
with the choice of using gpgme_set_ctx_flag instead of
gpgme_set_export_session_keys, we don't have any exported symbol to
catch errors when the dynamic linker runs.

In debian, we would be able to distinguish compiled objects that link
against the new symbol and automatically indicate the right dependency
versioning in the associated package as a result (we track which version
a new symbol was added).  I don't think we have any way to do that
otherwise, though.  I suppose i can just mark the symbols depdendencies
as a hard lower limit with the new revision, though.  that will be a
tighter dependency match than necessary for most code (which doesn't
need the new functionality), but whatever.

> I also went forward and implemented the override feature.  However I
> changed the API for both:
>
>     To keep the number of context manipulation functions at bay, this
>     patches removes the just added gpgme_set_export_session_keys and
>     gpgme_get_export_session_keys by flags for the generic context
>     function.
>
> This is because I consider the session-key exporting a rarely used
> feature and thus the generic flag setting function is more appropriate.
> This also instantly provides the Qt and cpp bindings.  Usage is pretty
> simple:
>
>   if (export_session_key)
>     gpgme_set_ctx_flag (ctx, "export-session-key", "1");
>   if (override_session_key)
>     gpgme_set_ctx_flag (ctx, "override-session-key", override_session_key);
>
> see tests/run-decrypt.c

If this is intended to be an example for how others should use this
feature, it's a bit dangerous to not check the error return value from
gpgme_set_ctx_flag, no?

It would be good to have a bit of documentation that ensures that the
user at least tests that the flags have been properly set.

How about this change:

-----------------------
diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index fd396e0..8820312 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -4810,14 +4810,19 @@ known, otherwise this is a null pointer.
 @item char *session_key
 A textual representation (nul-terminated string) of the session key
 used in symmetric encryption of the message, if the context has been
 set to export session keys (see @code{gpgme_set_ctx_flag,
 "export-session-key"}), and a session key was available for the most
 recent decryption operation.  Otherwise, this is a null pointer.
 
+You must not try to access this member of the struct unless
+ at code{gpgme_set_ctx_flag (ctx, "export-session-key")} returns
+ at code{GPG_ERR_NO_ERROR} or @code{gpgme_get_ctx_flag (ctx,
+"export-session-key")} returns @code{"1"}.
+
 @end table
 @end deftp
 
 @deftypefun gpgme_decrypt_result_t gpgme_op_decrypt_result (@w{gpgme_ctx_t @var{ctx}})
 The function @code{gpgme_op_decrypt_result} returns a
 @code{gpgme_decrypt_result_t} pointer to a structure holding the
 result of a @code{gpgme_op_decrypt} operation.  The pointer is only
-----------------------

another (hacky) advantage of this is that compliant reliant code might
make use of the newly-introduced symbols gpgme_get_ctx_flag(), which
would give us the exposed symbol indicators that debian (and similar
systems) could use for dependency tracking :)

Thanks again for sorting this out,

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: </pipermail/attachments/20161115/660bcf17/attachment.sig>

From wk at gnupg.org  Tue Nov 15 15:46:30 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 15 Nov 2016 15:46:30 +0100
Subject: [GPGME PATCH] core: Enable extraction of session keys.
In-Reply-To: <87eg2cappj.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 15 Nov 2016 21:32:24 +0900")
References: <20161111074928.3780-1-dkg@fifthhorseman.net>
 <878tslyt85.fsf@wheatstone.g10code.de>
 <87eg2cappj.fsf@alice.fifthhorseman.net>
Message-ID: <87a8d0yf5l.fsf@wheatstone.g10code.de>

On Tue, 15 Nov 2016 13:32, dkg at fifthhorseman.net said:

> not be used by code compiled with a header for the newer API", are you
> implying that there's mechanism to enforce that?  I don't think "tinkers

If you build software using a new header we can assume that the it is
also linked to the matching version of the library.  The SO minor number
will be bumped up for the release (but not in the git version).  By
tinkering with the build system I mean to force linking against an older
SO; that is installing just the application but not the library and
hoping that everything works.

> with the choice of using gpgme_set_ctx_flag instead of
> gpgme_set_export_session_keys, we don't have any exported symbol to
> catch errors when the dynamic linker runs.

We have

 gpgme_set_sender                NEW.
 gpgme_get_sender                NEW.
 gpgme_op_query_swdb             NEW.
 gpgme_op_query_swdb_result      NEW.
 gpgme_query_swdb_result_t       NEW.
 gpgme_get_ctx_flag              NEW.

however they are most likely not used.  That is the same as with
gpgme_set_export_session_keys.

> versioning in the associated package as a result (we track which version
> a new symbol was added).  I don't think we have any way to do that

Well, we have new exported symbols.  And the SO minor will be bumbed.
So both mechanismn are in place; the Debian thing and the proper thing
all libraries should do.

> If this is intended to be an example for how others should use this
> feature, it's a bit dangerous to not check the error return value from
> gpgme_set_ctx_flag, no?

Okay, I thought I could leave that out because we don't have a way to
check whether the override works in gpg.  But, okay for education I add
an error check.

> It would be good to have a bit of documentation that ensures that the
> user at least tests that the flags have been properly set.

We are extending the result structures for more than 10 years.  I am not
aware of any problems related to this.  Granted, some of these changes
are merely new bits taken from a reserved bit field variable but often
enough we added new pointer fields.

> +You must not try to access this member of the struct unless
> + at code{gpgme_set_ctx_flag (ctx, "export-session-key")} returns
> + at code{GPG_ERR_NO_ERROR} or @code{gpgme_get_ctx_flag (ctx,

We would need to add such requirments to a lot of other fucntions as
well.  For example the TOFU stuff also adds new fields to the result
structure which _may_ only be set when GPGME_KEYLIST_MODE_WITH_TOFU is
used.

> another (hacky) advantage of this is that compliant reliant code might
> make use of the newly-introduced symbols gpgme_get_ctx_flag(), which
> would give us the exposed symbol indicators that debian (and similar
> systems) could use for dependency tracking :)

For backward compatible changes on glibc systems we bump the minor SO
number - what's wrong with this approach?  Just because some projects
don't do proper ABI tracking we shall fallback to such hacks as tracking
new symbol names?

If you really really want it, I guess we could add extra code on glibc
systems to detect broken installations.  But is it really worse the
trouble and extra bugs just due to this code?  We used such magic in
GNOME more than 15 years ago.  Can you point me to any bug reported
related to GPGME caused by such improper use?  I only recall problems
with off_t and off64_t for which we added detection code to gpgme.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161115/4807bbb0/attachment.sig>

From vinay_sajip at yahoo.co.uk  Tue Nov 15 19:24:29 2016
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Tue, 15 Nov 2016 18:24:29 +0000 (UTC)
Subject: GnuPG 2.1.15 - delete-secret-keys seems not to accept loopback
 pinentry
References: <70587844.1123310.1479234269383.ref@mail.yahoo.com>
Message-ID: <70587844.1123310.1479234269383@mail.yahoo.com>

I've made some progress with getting GnuPG 2.1.15 to accept passphrases on fd 0 - it seems to work now for e.g. decryption operations. However, deleting secret keys still seems to fail. Environment is Ubuntu 16.04.1 (64-bit), GnuPG 2.1.15 built from source.

$ cat keys/gpg-agent.conf 

allow-loopback-pinentry
log-file socket:///tmp/S.my-gnupg-log
verbose
debug ipc

Output from watchgnupg --time-only --force /tmp/S.my-gnupg-log:
? 4 - 17:46:12 gpg-agent[14900]: handler 0x7ff2ff4f6700 for fd 5 started
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK Pleased to meet you, process 14926
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- RESET
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION ttytype=xterm-256color
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION display=:0
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION xauthority=/home/vinay/.Xauthority
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION putenv=XMODIFIERS=@im=ibus
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION putenv=GTK_IM_MODULE=ibus
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-DYgUN0UGwd
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION putenv=QT_IM_MODULE=ibus
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- GETINFO version
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> D 2.1.15
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION allow-pinentry-notify
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION agent-awareness=2.1.0
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION pinentry-mode=loopback
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- AGENT_ID
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> ERR 67109139 Unknown IPC command <GPG Agent>
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- HAVEKEY E957503A4483EFA081EBF906B52DBB4B621814FF
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- HAVEKEY E957503A4483EFA081EBF906B52DBB4B621814FF
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- SETKEYDESC Do+you+really+want+to+permanently+delete+the+OpenPGP+secret+key:%0A%22Autogenerated+Key+<user1 at test>%22%0A2048-bit+RSA+key,+ID+8F03D92FB77E3265,%0Acreated+2016-11-15.%0A?
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- DELETE_KEY E957503A4483EFA081EBF906B52DBB4B621814FF
? 4 - 17:46:12 gpg-agent[14900]: command 'DELETE_KEY' failed: No PINentry
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> ERR 67108949 No PINentry <GPG Agent>
? 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- [eof]
? 4 - 17:46:12 gpg-agent[14900]: handler 0x7ff2ff4f6700 for fd 5 terminated

My test run log file:
14926: /home/vinay/tmp/bin/gpg2 --pinentry-mode loopback --status-fd 2 --no-tty --debug ipc --homedir /home/vinay/projects/python-gnupg/keys --batch --passphrase-fd 0 --debug-quick-random --batch --delete-secret-key B1743E3C7D6DC65F44720E548F03D92FB77E3265
Wrote passphrase
gpg: Note: no default option file '/home/vinay/projects/python-gnupg/keys/gpg.conf'
gpg: enabled debug flags: ipc
gpg: DBG: chan_6 <- OK Pleased to meet you, process 14926
gpg: DBG: connection to agent established
gpg: DBG: chan_6 -> RESET
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> OPTION ttytype=xterm-256color
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> OPTION display=:0
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> OPTION xauthority=/home/vinay/.Xauthority
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> OPTION putenv=XMODIFIERS=@im=ibus
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> OPTION putenv=GTK_IM_MODULE=ibus
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-DYgUN0UGwd
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> OPTION putenv=QT_IM_MODULE=ibus
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> GETINFO version
gpg: DBG: chan_6 <- D 2.1.15
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> OPTION allow-pinentry-notify
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> OPTION agent-awareness=2.1.0
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> OPTION pinentry-mode=loopback
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> AGENT_ID
gpg: DBG: chan_6 <- ERR 67109139 Unknown IPC command <GPG Agent>
gpg: DBG: chan_6 -> HAVEKEY E957503A4483EFA081EBF906B52DBB4B621814FF
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> HAVEKEY E957503A4483EFA081EBF906B52DBB4B621814FF
gpg: DBG: chan_6 <- OK
[GNUPG:] KEY_CONSIDERED B1743E3C7D6DC65F44720E548F03D92FB77E3265 0
gpg: DBG: chan_6 -> SETKEYDESC Do+you+really+want+to+permanently+delete+the+OpenPGP+secret+key:%0A%22Autogenerated+Key+<user1 at test>%22%0A2048-bit+RSA+key,+ID+8F03D92FB77E3265,%0Acreated+2016-11-15.%0A?
gpg: DBG: chan_6 <- OK
gpg: DBG: chan_6 -> DELETE_KEY E957503A4483EFA081EBF906B52DBB4B621814FF
gpg: DBG: chan_6 <- ERR 67108949 No PINentry <GPG Agent>
gpg: deleting secret key failed: No PINentry
gpg: B1743E3C7D6DC65F44720E548F03D92FB77E3265: delete key failed: No PINentry
gpg: secmem usage: 224/32768 bytes in 1 blocks

The first line of my test run log indicates the PID and command line of the gpg process. This ties up with the watchgnupg program output. The "OPTION pinentry-mode=loopback" seems to have been accepted. I don't understand why the AGENT_ID causes the "ERR 67109139 Unknown IPC command <GPG Agent>" or whether it is relevant to the later failure. Why does DELETE_KEY fail with "No PINentry", and how can I avoid this? As far as I can tell, the passphrase was written successfully on fd 0 (the 2nd line in my test run log, "Wrote passphrase").
Can anyone shed any light on this?
Regards,
Vinay Sajip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161115/c9afb130/attachment-0001.html>

From dkg at fifthhorseman.net  Wed Nov 16 00:52:42 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Nov 2016 08:52:42 +0900
Subject: [LIBGPG-ERROR PATCH 2/6] Convert THANKS to UTF-8.
In-Reply-To: <20161115235246.24860-1-dkg@fifthhorseman.net>
References: <20161115235246.24860-1-dkg@fifthhorseman.net>
Message-ID: <20161115235246.24860-2-dkg@fifthhorseman.net>

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 THANKS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/THANKS b/THANKS
index 9250249..9f37446 100644
--- a/THANKS
+++ b/THANKS
@@ -1,5 +1,5 @@
 
-Albrecht Dre?		albrecht.dress at arcor de
+Albrecht Dre??		albrecht.dress at arcor de
 Guillaume Libersat      glibersat at hurdfr org
 Jakub Bogusz            qboosh at pld-linux org
 Petr Pisar              petr.pisar at atlas cz
-- 
2.10.2



From dkg at fifthhorseman.net  Wed Nov 16 00:52:44 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Nov 2016 08:52:44 +0900
Subject: [LIBGPG-ERROR PATCH 4/6] Fix more misspellings.
In-Reply-To: <20161115235246.24860-1-dkg@fifthhorseman.net>
References: <20161115235246.24860-1-dkg@fifthhorseman.net>
Message-ID: <20161115235246.24860-4-dkg@fifthhorseman.net>

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 NEWS                 | 4 ++--
 doc/errorref.txt     | 2 +-
 doc/gpgrt.texi       | 4 ++--
 src/estream-printf.c | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/NEWS b/NEWS
index ce2beb5..46ecdc9 100644
--- a/NEWS
+++ b/NEWS
@@ -478,8 +478,8 @@ Noteworthy changes in version 1.4 (2006-09-14)
  * New error codes for the Assuan IPC library.
 
  * New error code GPG_ERR_MISSING_ERRNO to be used in cases when a
-   system accidently does not set errno but a system error definitely
-   occured.
+   system accidentally does not set errno but a system error
+   definitely occurred.
 
  * New error source GPG_ERR_SOURCE_ANY to allow proper use of
    libgpg-error even if a specific source is not available.
diff --git a/doc/errorref.txt b/doc/errorref.txt
index da4510e..d389398 100644
--- a/doc/errorref.txt
+++ b/doc/errorref.txt
@@ -78,7 +78,7 @@ GPG_ERR_NO_PUBKEY		No public key
             - The public key could not be retrieved from a corresponding
               certificate on a card (command READKEY in scd).
             - A requested certificate was not found or an unspecified
-              error occured while selecting a X.509 certificate in
+              error occurred while selecting a X.509 certificate in
               gpgsm.
             - The specified certificate or key was not found.  This
               does not necessary mean that the certifciate is not
diff --git a/doc/gpgrt.texi b/doc/gpgrt.texi
index b8a3008..53beef8 100644
--- a/doc/gpgrt.texi
+++ b/doc/gpgrt.texi
@@ -128,7 +128,7 @@ RunTime).
 This manual documents the Libgpg-error library application programming
 interface (API).  The goal is to that all functions and data types
 provided by the library are explained.  However, for now this is only
-a stub and not very usefull.
+a stub and not very useful.
 
 
 @node Features
@@ -327,7 +327,7 @@ TBD.
 @node Generalities
 @chapter Generalities
 
-TBD.  (Description of the error fucntion may be taken from Libgcrypt.)
+TBD.  (Description of the error function may be taken from Libgcrypt.)
 
 
 
diff --git a/src/estream-printf.c b/src/estream-printf.c
index 091ff7d..f1cbcde 100644
--- a/src/estream-printf.c
+++ b/src/estream-printf.c
@@ -1784,7 +1784,7 @@ dynamic_buffer_out (void *outfncarg, const char *buf, size_t buflen)
         {
           parm->error_flag = errno ? errno : ENOMEM;
           /* Wipe out what we already accumulated.  This is useful in
-             case sensitive data is formated.  */
+             case sensitive data is formatted.  */
           memset (parm->buffer, 0, parm->used);
           return -1;
         }
-- 
2.10.2



From dkg at fifthhorseman.net  Wed Nov 16 00:52:46 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Nov 2016 08:52:46 +0900
Subject: [LIBGPG-ERROR PATCH 6/6] w32-iconv: Remove invalid link to
 unicode.org in comment.
In-Reply-To: <20161115235246.24860-1-dkg@fifthhorseman.net>
References: <20161115235246.24860-1-dkg@fifthhorseman.net>
Message-ID: <20161115235246.24860-6-dkg@fifthhorseman.net>

--
http://www.unicode.org/unicode/onlinedat/languages.html currently says:

     The mapping information between Macintosh and Windows codes is no
     longer available on the Unicode site. Please consult the
     Macintosh and Windows developer sites.

And there are no outbound links.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 src/w32-gettext.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/w32-gettext.c b/src/w32-gettext.c
index 8168e30..3b54ebd 100644
--- a/src/w32-gettext.c
+++ b/src/w32-gettext.c
@@ -680,7 +680,6 @@ my_nl_locale_name (const char *categoryname)
   sub = SUBLANGID (langid);
 
   /* Dispatch on language.
-     See also http://www.unicode.org/unicode/onlinedat/languages.html .
      For details about languages, see https://www.ethnologue.com/ .  */
   switch (primary)
     {
-- 
2.10.2



From dkg at fifthhorseman.net  Wed Nov 16 00:52:41 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Nov 2016 08:52:41 +0900
Subject: [LIBGPG-ERROR PATCH 1/6] Fix misspellings in error descriptions.
Message-ID: <20161115235246.24860-1-dkg@fifthhorseman.net>

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 doc/errorref.txt   | 2 +-
 po/cs.po           | 4 ++--
 po/da.po           | 4 ++--
 po/de.po           | 4 ++--
 po/eo.po           | 4 ++--
 po/fr.po           | 6 ++----
 po/hu.po           | 4 ++--
 po/it.po           | 4 ++--
 po/ja.po           | 4 ++--
 po/nl.po           | 4 ++--
 po/pl.po           | 4 ++--
 po/pt.po           | 4 ++--
 po/ro.po           | 4 ++--
 po/ru.po           | 4 ++--
 po/sr.po           | 4 ++--
 po/sv.po           | 4 ++--
 po/uk.po           | 4 ++--
 po/vi.po           | 4 ++--
 po/zh_CN.po        | 4 ++--
 po/zh_TW.po        | 4 ++--
 src/err-codes.h.in | 4 ++--
 21 files changed, 41 insertions(+), 43 deletions(-)

diff --git a/doc/errorref.txt b/doc/errorref.txt
index 0203724..da4510e 100644
--- a/doc/errorref.txt
+++ b/doc/errorref.txt
@@ -739,7 +739,7 @@ GPG_ERR_BAD_HS_CERT_VER         Bad certificate verify message in handshake
 
     NTBTLS: - As the description says.
 
-GPG_ERR_BAD_HS_CHANGE_CIPHER    Bad change cipher messsage in handshake
+GPG_ERR_BAD_HS_CHANGE_CIPHER    Bad change cipher message in handshake
 
     NTBTLS: - As the description says.
 
diff --git a/po/cs.po b/po/cs.po
index 4b58c21..4ff6ef0 100644
--- a/po/cs.po
+++ b/po/cs.po
@@ -824,7 +824,7 @@ msgstr "Chybn? zpr?va s?po?adavkem na certifik?t v?zah?jen?"
 msgid "Bad certificate verify message in handshake"
 msgstr "Chybn? zpr?va o?ov??en? certifik?tu v?zah?jen?"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "Chybn? zpr?va se zm?nou ?ifry v?zah?jen?"
 
 msgid "Bad client hello message in handshake"
@@ -833,7 +833,7 @@ msgstr "Chybn? zpr?va s?pozdravem klienta v?zah?jen?"
 msgid "Bad server hello message in handshake"
 msgstr "Chybn? zpr?va s?pozdravem serveru v?zah?jen?"
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "Chybn? zpr?va o?dokon?en? pozdravu serveru v?zah?jen?"
 
 msgid "Bad finished message in handshake"
diff --git a/po/da.po b/po/da.po
index 7fd9f11..61ba1e2 100644
--- a/po/da.po
+++ b/po/da.po
@@ -819,7 +819,7 @@ msgstr "Besked om ?delagt certifikatforesp?rgsel i h?ndtrykket"
 msgid "Bad certificate verify message in handshake"
 msgstr "Besked om ?delagt certifikatforesp?rgsel i h?ndtrykket"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "?delagt ??ndr chiffer?-besked i h?ndtrykket"
 
 msgid "Bad client hello message in handshake"
@@ -829,7 +829,7 @@ msgid "Bad server hello message in handshake"
 msgstr "Besked om ?delagt serverhilsen i h?ndtrykket"
 
 # engelsk fejl
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "?delagt ?afsluttet serverhilsen?-besked i h?ndtrykket"
 
 msgid "Bad finished message in handshake"
diff --git a/po/de.po b/po/de.po
index 2abbf88..1a8ebcc 100644
--- a/po/de.po
+++ b/po/de.po
@@ -810,7 +810,7 @@ msgstr "Fehlerhafte Zertifikatsanforderungsnachricht im Handshake"
 msgid "Bad certificate verify message in handshake"
 msgstr "Fehlerhafte Zertifikats?berpr?fungsnachricht im Handshake"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "Fehlerhafte Verschl?sselungsalgorithmuswechselnachricht im Handshake"
 
 msgid "Bad client hello message in handshake"
@@ -819,7 +819,7 @@ msgstr "Fehlerhafte \"Client Hello\" Nachricht im Handshake"
 msgid "Bad server hello message in handshake"
 msgstr "Fehlerhafte \"Server Hello\" Nachricht im Handshake"
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "Fehlerhafte \"Server Hello Done\" Nachricht im Handshake"
 
 msgid "Bad finished message in handshake"
diff --git a/po/eo.po b/po/eo.po
index a511ac9..5948f9a 100644
--- a/po/eo.po
+++ b/po/eo.po
@@ -874,7 +874,7 @@ msgstr ""
 msgid "Bad certificate verify message in handshake"
 msgstr ""
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr ""
 
 msgid "Bad client hello message in handshake"
@@ -883,7 +883,7 @@ msgstr ""
 msgid "Bad server hello message in handshake"
 msgstr ""
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr ""
 
 msgid "Bad finished message in handshake"
diff --git a/po/fr.po b/po/fr.po
index a03a9e7..db1cdcb 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -817,8 +817,7 @@ msgstr "Mauvais message de demande de certificat dans l?initialisation"
 msgid "Bad certificate verify message in handshake"
 msgstr "Mauvais message de v?rification de certificat dans l?initialisation"
 
-# NOTE: s/messsage/message/
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "Mauvais message de modification d?algorithme dans l?initialisation"
 
 msgid "Bad client hello message in handshake"
@@ -827,8 +826,7 @@ msgstr "Mauvais message de salut du client dans l?initialisation"
 msgid "Bad server hello message in handshake"
 msgstr "Mauvais message de salut du serveur dans l?initialisation"
 
-# NOTE: s/hanshake/handshake/
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "Mauvais message de fin de salut du serveur dans l?initialisation"
 
 msgid "Bad finished message in handshake"
diff --git a/po/hu.po b/po/hu.po
index b271089..cb143e0 100644
--- a/po/hu.po
+++ b/po/hu.po
@@ -872,7 +872,7 @@ msgstr ""
 msgid "Bad certificate verify message in handshake"
 msgstr ""
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr ""
 
 msgid "Bad client hello message in handshake"
@@ -881,7 +881,7 @@ msgstr ""
 msgid "Bad server hello message in handshake"
 msgstr ""
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr ""
 
 msgid "Bad finished message in handshake"
diff --git a/po/it.po b/po/it.po
index 82d1782..dc17bcb 100644
--- a/po/it.po
+++ b/po/it.po
@@ -815,7 +815,7 @@ msgstr "Messaggio di richiesta del certificato errato nell'handshake"
 msgid "Bad certificate verify message in handshake"
 msgstr "Messaggio di verifica del certificato errato nell'handshake"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "Messaggi di modifica cifrario errato nell'handshake"
 
 msgid "Bad client hello message in handshake"
@@ -824,7 +824,7 @@ msgstr "Messaggio client hello errato nell'handshake"
 msgid "Bad server hello message in handshake"
 msgstr "Messaggio server hello errato nell'handshake"
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "Messaggio server hello completato errato nell'handshake"
 
 msgid "Bad finished message in handshake"
diff --git a/po/ja.po b/po/ja.po
index f1d44e4..e0e76c5 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -806,7 +806,7 @@ msgstr "???????????????????????"
 msgid "Bad certificate verify message in handshake"
 msgstr "???????????????????????"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "??????????????????????"
 
 msgid "Bad client hello message in handshake"
@@ -815,7 +815,7 @@ msgstr "????????????????????????
 msgid "Bad server hello message in handshake"
 msgstr "????????????????????????"
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "??????????????????????????"
 
 msgid "Bad finished message in handshake"
diff --git a/po/nl.po b/po/nl.po
index e5734a1..d90ac4f 100644
--- a/po/nl.po
+++ b/po/nl.po
@@ -816,7 +816,7 @@ msgstr "Slecht verzoek om certificaatbericht in uitwisseling"
 msgid "Bad certificate verify message in handshake"
 msgstr "Slecht certificaatbericht over verificatie in uitwisseling"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "Slecht wijzigingsbericht over vercijfering in uitwisseling"
 
 msgid "Bad client hello message in handshake"
@@ -825,7 +825,7 @@ msgstr "Slecht hello-bericht van client in uitwisseling"
 msgid "Bad server hello message in handshake"
 msgstr "Slecht hello-bericht van server in uitwisseling"
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "Slecht hello-gedaan-bericht van server in uitwisseling"
 
 msgid "Bad finished message in handshake"
diff --git a/po/pl.po b/po/pl.po
index dcb26d9..66f66f2 100644
--- a/po/pl.po
+++ b/po/pl.po
@@ -804,7 +804,7 @@ msgstr "B??dny komunikat ??dania certyfikatu przy powitaniu"
 msgid "Bad certificate verify message in handshake"
 msgstr "B??dny komunikat weryfikacji certyfikatu przy powitaniu"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "B??dny komunikat zmiany szyfru przy powitaniu"
 
 msgid "Bad client hello message in handshake"
@@ -813,7 +813,7 @@ msgstr "B??dny komunikat przywitania klienta w powitaniu"
 msgid "Bad server hello message in handshake"
 msgstr "B??dny komunikat przywitania serwera w powitaniu"
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "B??dny komunikat zako?czenia przywitania serwera w powitaniu"
 
 msgid "Bad finished message in handshake"
diff --git a/po/pt.po b/po/pt.po
index 691c64c..822d307 100644
--- a/po/pt.po
+++ b/po/pt.po
@@ -816,7 +816,7 @@ msgstr "Mensagem de pedido de certificado errada no handshake"
 msgid "Bad certificate verify message in handshake"
 msgstr "Mensagem de verifica??o de certificado errada no handshake"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "Mensagem de altera??o de certificado errada no handshake"
 
 msgid "Bad client hello message in handshake"
@@ -825,7 +825,7 @@ msgstr "Mensagem de hello do cliente errada no handshake"
 msgid "Bad server hello message in handshake"
 msgstr "Mensagem de hello do servidor errada no handshake"
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "Mensagem de hello done do servidor errada no handshake"
 
 msgid "Bad finished message in handshake"
diff --git a/po/ro.po b/po/ro.po
index 2e5f404..c9ad5dd 100644
--- a/po/ro.po
+++ b/po/ro.po
@@ -874,7 +874,7 @@ msgstr ""
 msgid "Bad certificate verify message in handshake"
 msgstr ""
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr ""
 
 msgid "Bad client hello message in handshake"
@@ -883,7 +883,7 @@ msgstr ""
 msgid "Bad server hello message in handshake"
 msgstr ""
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr ""
 
 msgid "Bad finished message in handshake"
diff --git a/po/ru.po b/po/ru.po
index 69cd250..8ff628b 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -810,7 +810,7 @@ msgstr "?????? ?????????-?????? ??????????? ??
 msgid "Bad certificate verify message in handshake"
 msgstr "?????? ?????????-???????? ??????????? ??? ???????????? ?????"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "?????? ????????? ????? ????? ??? ???????????? ?????"
 
 msgid "Bad client hello message in handshake"
@@ -819,7 +819,7 @@ msgstr "?????? ????????? ????????? ??????? ???
 msgid "Bad server hello message in handshake"
 msgstr "?????? ????????? ????????? ??????? ??? ???????????? ?????"
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "?????? ????????? ??????? ?? ????????? ????????? ??? ???????????? ?????"
 
 msgid "Bad finished message in handshake"
diff --git a/po/sr.po b/po/sr.po
index be7117d..1a0f4f4 100644
--- a/po/sr.po
+++ b/po/sr.po
@@ -871,7 +871,7 @@ msgstr ""
 msgid "Bad certificate verify message in handshake"
 msgstr ""
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr ""
 
 msgid "Bad client hello message in handshake"
@@ -880,7 +880,7 @@ msgstr ""
 msgid "Bad server hello message in handshake"
 msgstr ""
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr ""
 
 msgid "Bad finished message in handshake"
diff --git a/po/sv.po b/po/sv.po
index b4b6ea3..5ed1db1 100644
--- a/po/sv.po
+++ b/po/sv.po
@@ -861,7 +861,7 @@ msgstr ""
 msgid "Bad certificate verify message in handshake"
 msgstr ""
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr ""
 
 msgid "Bad client hello message in handshake"
@@ -870,7 +870,7 @@ msgstr ""
 msgid "Bad server hello message in handshake"
 msgstr ""
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr ""
 
 msgid "Bad finished message in handshake"
diff --git a/po/uk.po b/po/uk.po
index cbab08a..173bacd 100644
--- a/po/uk.po
+++ b/po/uk.po
@@ -815,7 +815,7 @@ msgstr ""
 "????????? ???????????? ???? ????????? ???????????? ??? ??? ????????????? "
 "???????"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "????????? ???????????? ???? ????? ????? ??? ??? ????????????? ???????"
 
 msgid "Bad client hello message in handshake"
@@ -824,7 +824,7 @@ msgstr "????????? ???????? ???????????? ?????
 msgid "Bad server hello message in handshake"
 msgstr "????????? ???????? ???????????? ??????? ??? ??? ????????????? ???????"
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr ""
 "????????? ???????????? ??? ?????????? ??????? ??? ??????? ??? ??? "
 "????????????? ???????"
diff --git a/po/vi.po b/po/vi.po
index 4ee1ec9..1179fca 100644
--- a/po/vi.po
+++ b/po/vi.po
@@ -863,7 +863,7 @@ msgstr ""
 msgid "Bad certificate verify message in handshake"
 msgstr ""
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr ""
 
 msgid "Bad client hello message in handshake"
@@ -872,7 +872,7 @@ msgstr ""
 msgid "Bad server hello message in handshake"
 msgstr ""
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr ""
 
 msgid "Bad finished message in handshake"
diff --git a/po/zh_CN.po b/po/zh_CN.po
index 680af4b..a65757e 100644
--- a/po/zh_CN.po
+++ b/po/zh_CN.po
@@ -860,7 +860,7 @@ msgstr ""
 msgid "Bad certificate verify message in handshake"
 msgstr ""
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr ""
 
 msgid "Bad client hello message in handshake"
@@ -869,7 +869,7 @@ msgstr ""
 msgid "Bad server hello message in handshake"
 msgstr ""
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr ""
 
 msgid "Bad finished message in handshake"
diff --git a/po/zh_TW.po b/po/zh_TW.po
index ac6d7e3..afa8ae4 100644
--- a/po/zh_TW.po
+++ b/po/zh_TW.po
@@ -818,7 +818,7 @@ msgstr "????????????"
 msgid "Bad certificate verify message in handshake"
 msgstr "????????????"
 
-msgid "Bad change cipher messsage in handshake"
+msgid "Bad change cipher message in handshake"
 msgstr "?????????????"
 
 msgid "Bad client hello message in handshake"
@@ -827,7 +827,7 @@ msgstr "?????????????"
 msgid "Bad server hello message in handshake"
 msgstr "?????????????"
 
-msgid "Bad server hello done message in hanshake"
+msgid "Bad server hello done message in handshake"
 msgstr "???????????????"
 
 msgid "Bad finished message in handshake"
diff --git a/src/err-codes.h.in b/src/err-codes.h.in
index 082819e..de703d7 100644
--- a/src/err-codes.h.in
+++ b/src/err-codes.h.in
@@ -274,10 +274,10 @@
 240	GPG_ERR_BAD_HS_CERT		Bad certificate message in handshake
 241	GPG_ERR_BAD_HS_CERT_REQ		Bad certificate request message in handshake
 242	GPG_ERR_BAD_HS_CERT_VER		Bad certificate verify message in handshake
-243	GPG_ERR_BAD_HS_CHANGE_CIPHER	Bad change cipher messsage in handshake
+243	GPG_ERR_BAD_HS_CHANGE_CIPHER	Bad change cipher message in handshake
 244	GPG_ERR_BAD_HS_CLIENT_HELLO	Bad client hello message in handshake
 245	GPG_ERR_BAD_HS_SERVER_HELLO	Bad server hello message in handshake
-246	GPG_ERR_BAD_HS_SERVER_HELLO_DONE	Bad server hello done message in hanshake
+246	GPG_ERR_BAD_HS_SERVER_HELLO_DONE	Bad server hello done message in handshake
 247	GPG_ERR_BAD_HS_FINISHED		Bad finished message in handshake
 248	GPG_ERR_BAD_HS_SERVER_KEX	Bad server key exchange message in handshake
 249	GPG_ERR_BAD_HS_CLIENT_KEX	Bad client key exchange message in handshake
-- 
2.10.2



From dkg at fifthhorseman.net  Wed Nov 16 00:52:43 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Nov 2016 08:52:43 +0900
Subject: [LIBGPG-ERROR PATCH 3/6] po: Convert ro.po to UTF-8.
In-Reply-To: <20161115235246.24860-1-dkg@fifthhorseman.net>
References: <20161115235246.24860-1-dkg@fifthhorseman.net>
Message-ID: <20161115235246.24860-3-dkg@fifthhorseman.net>

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 po/ro.po | 376 +++++++++++++++++++++++++++++++--------------------------------
 1 file changed, 188 insertions(+), 188 deletions(-)

diff --git a/po/ro.po b/po/ro.po
index c9ad5dd..6354580 100644
--- a/po/ro.po
+++ b/po/ro.po
@@ -1,6 +1,6 @@
-# Mesajele ?n limba rom?n? pentru libgpg-error.
+# Mesajele ??n limba rom??n?? pentru libgpg-error.
 # Copyright (C) 2005 Free Software Foundation, Inc.
-# Acest fi?ier este distribuit sub aceea?i licen?? ca ?i pachetul libgpg-error.
+# Acest fi??ier este distribuit sub aceea??i licen???? ca ??i pachetul libgpg-error.
 # Laurentiu Buzdugan <lbuz at rolix.org>, 2005.
 #
 #
@@ -14,12 +14,12 @@ msgstr ""
 "Language-Team: Romanian <translation-team-ro at lists.sourceforge.net>\n"
 "Language: ro\n"
 "MIME-Version: 1.0\n"
-"Content-Type: text/plain; charset=ISO-8859-2\n"
+"Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=(n != 1);\n"
 
 msgid "Unspecified source"
-msgstr "Surs? nespecificat?"
+msgstr "Surs?? nespecificat??"
 
 msgid "gcrypt"
 msgstr "gcrypt"
@@ -71,58 +71,58 @@ msgstr ""
 
 #, fuzzy
 msgid "Any source"
-msgstr "Surs? necunoscut?"
+msgstr "Surs?? necunoscut??"
 
 msgid "User defined source 1"
-msgstr "Surs? definit? de utilizator 1"
+msgstr "Surs?? definit?? de utilizator 1"
 
 msgid "User defined source 2"
-msgstr "Surs? definit? de utilizator 2"
+msgstr "Surs?? definit?? de utilizator 2"
 
 msgid "User defined source 3"
-msgstr "Surs? definit? de utilizator 3"
+msgstr "Surs?? definit?? de utilizator 3"
 
 msgid "User defined source 4"
-msgstr "Surs? definit? de utilizator 4"
+msgstr "Surs?? definit?? de utilizator 4"
 
 msgid "Unknown source"
-msgstr "Surs? necunoscut?"
+msgstr "Surs?? necunoscut??"
 
 msgid "Success"
 msgstr "Succes"
 
 msgid "General error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 msgid "Unknown packet"
 msgstr "Pachet necunoscut"
 
 msgid "Unknown version in packet"
-msgstr "versiune necunoscut? ?n pachet"
+msgstr "versiune necunoscut?? ??n pachet"
 
 msgid "Invalid public key algorithm"
-msgstr "Algoritm cu cheie public? invalid"
+msgstr "Algoritm cu cheie public?? invalid"
 
 msgid "Invalid digest algorithm"
 msgstr "Algoritm rezumat invalid"
 
 msgid "Bad public key"
-msgstr "Cheie public? incorect?"
+msgstr "Cheie public?? incorect??"
 
 msgid "Bad secret key"
-msgstr "Cheie secret? incorect?"
+msgstr "Cheie secret?? incorect??"
 
 msgid "Bad signature"
-msgstr "Semn?tur? incorect?"
+msgstr "Semn??tur?? incorect??"
 
 msgid "No public key"
-msgstr "Nici o cheie public?"
+msgstr "Nici o cheie public??"
 
 msgid "Checksum error"
 msgstr "Eroare checksum"
 
 msgid "Bad passphrase"
-msgstr "Fraz?-parol? incorect?"
+msgstr "Fraz??-parol?? incorect??"
 
 msgid "Invalid cipher algorithm"
 msgstr "Algoritm cifrare invalid"
@@ -134,34 +134,34 @@ msgid "Invalid packet"
 msgstr "Pachet invalid"
 
 msgid "Invalid armor"
-msgstr "Armur? invalid?"
+msgstr "Armur?? invalid??"
 
 msgid "No user ID"
 msgstr "Nici un ID utilizator."
 
 msgid "No secret key"
-msgstr "Nici o cheie secret?"
+msgstr "Nici o cheie secret??"
 
 msgid "Wrong secret key used"
-msgstr "A fost folosit? o cheie secret? gre?it?"
+msgstr "A fost folosit?? o cheie secret?? gre??it??"
 
 msgid "Bad session key"
-msgstr "Cheie de sesiune incorect?"
+msgstr "Cheie de sesiune incorect??"
 
 msgid "Unknown compression algorithm"
 msgstr "Algoritm compresie necunoscut"
 
 msgid "Number is not prime"
-msgstr "Num?rul nu este prim"
+msgstr "Num??rul nu este prim"
 
 msgid "Invalid encoding method"
-msgstr "Valoare de encodare invalid?"
+msgstr "Valoare de encodare invalid??"
 
 msgid "Invalid encryption scheme"
-msgstr "Schem? de cifrare invalid?"
+msgstr "Schem?? de cifrare invalid??"
 
 msgid "Invalid signature scheme"
-msgstr "Schem? de semn?turi invalid?"
+msgstr "Schem?? de semn??turi invalid??"
 
 msgid "Invalid attribute"
 msgstr "Argument invalid"
@@ -170,22 +170,22 @@ msgid "No value"
 msgstr "Nici o valoare"
 
 msgid "Not found"
-msgstr "Nu a fost g?sit(?)"
+msgstr "Nu a fost g??sit(??)"
 
 msgid "Value not found"
-msgstr "Valoarea nu a fost g?sit?"
+msgstr "Valoarea nu a fost g??sit??"
 
 msgid "Syntax error"
-msgstr "Eroare de sintax?"
+msgstr "Eroare de sintax??"
 
 msgid "Bad MPI value"
-msgstr "Valoare MPI incorect?"
+msgstr "Valoare MPI incorect??"
 
 msgid "Invalid passphrase"
-msgstr "Fraz?-parol? invalid?"
+msgstr "Fraz??-parol?? invalid??"
 
 msgid "Invalid signature class"
-msgstr "Clas? semn?turi invalid?"
+msgstr "Clas?? semn??turi invalid??"
 
 msgid "Resources exhausted"
 msgstr "Resurse epuizate"
@@ -194,7 +194,7 @@ msgid "Invalid keyring"
 msgstr "Inel de chei invalid"
 
 msgid "Trust DB error"
-msgstr "Eroare baz? de date ?ncredere"
+msgstr "Eroare baz?? de date ??ncredere"
 
 msgid "Bad certificate"
 msgstr "Certificat incorect"
@@ -203,7 +203,7 @@ msgid "Invalid user ID"
 msgstr "ID utilizator invalid"
 
 msgid "Unexpected error"
-msgstr "Eroare nea?teptat?"
+msgstr "Eroare nea??teptat??"
 
 msgid "Time conflict"
 msgstr "Conflict de timp"
@@ -212,34 +212,34 @@ msgid "Keyserver error"
 msgstr "Eroare server de chei"
 
 msgid "Wrong public key algorithm"
-msgstr "Algoritm cheie public? gre?it"
+msgstr "Algoritm cheie public?? gre??it"
 
 msgid "Tribute to D. A."
 msgstr "Tribut lui D. A."
 
 msgid "Weak encryption key"
-msgstr "Cheie de cifrare slab?"
+msgstr "Cheie de cifrare slab??"
 
 msgid "Invalid key length"
-msgstr "Lungime cheie invalid?"
+msgstr "Lungime cheie invalid??"
 
 msgid "Invalid argument"
 msgstr "Argument invalid"
 
 msgid "Syntax error in URI"
-msgstr "Eroare de sintax? ?n URI"
+msgstr "Eroare de sintax?? ??n URI"
 
 msgid "Invalid URI"
 msgstr "URI incorect"
 
 msgid "Network error"
-msgstr "Eroare re?ea"
+msgstr "Eroare re??ea"
 
 msgid "Unknown host"
-msgstr "Gazd? necunoscut?"
+msgstr "Gazd?? necunoscut??"
 
 msgid "Selftest failed"
-msgstr "Auto-test e?uat"
+msgstr "Auto-test e??uat"
 
 msgid "Data not encrypted"
 msgstr "Date necifrate"
@@ -248,37 +248,37 @@ msgid "Data not processed"
 msgstr "Date neprocesate"
 
 msgid "Unusable public key"
-msgstr "Cheie public? de nefolosit"
+msgstr "Cheie public?? de nefolosit"
 
 msgid "Unusable secret key"
-msgstr "cheie secret? de nefolosit"
+msgstr "cheie secret?? de nefolosit"
 
 msgid "Invalid value"
-msgstr "Valoare invalid?"
+msgstr "Valoare invalid??"
 
 msgid "Bad certificate chain"
-msgstr "Lan? certificate incorect"
+msgstr "Lan?? certificate incorect"
 
 msgid "Missing certificate"
-msgstr "Certificat lips?"
+msgstr "Certificat lips??"
 
 msgid "No data"
-msgstr "Nici o dat?"
+msgstr "Nici o dat??"
 
 msgid "Bug"
 msgstr "Bug"
 
 msgid "Not supported"
-msgstr "Nu este suportat(?)"
+msgstr "Nu este suportat(??)"
 
 msgid "Invalid operation code"
-msgstr "Cod opera?ie invalid"
+msgstr "Cod opera??ie invalid"
 
 msgid "Timeout"
-msgstr "Pauz?"
+msgstr "Pauz??"
 
 msgid "Internal error"
-msgstr "Eroare intern?"
+msgstr "Eroare intern??"
 
 msgid "EOF (gcrypt)"
 msgstr "EOF (gcrypt)"
@@ -293,13 +293,13 @@ msgid "Provided object is too large"
 msgstr "Obiectul furnizat e prea larg"
 
 msgid "Missing item in object"
-msgstr "Articol lips? ?n obiect"
+msgstr "Articol lips?? ??n obiect"
 
 msgid "Not implemented"
-msgstr "Nu a fost implementat(?)"
+msgstr "Nu a fost implementat(??)"
 
 msgid "Conflicting use"
-msgstr "Folosire ?n conflict"
+msgstr "Folosire ??n conflict"
 
 msgid "Invalid cipher mode"
 msgstr "Mod cifru invalid"
@@ -314,13 +314,13 @@ msgid "Result truncated"
 msgstr "Rezultat invalid"
 
 msgid "Incomplete line"
-msgstr "Linie incomplet?"
+msgstr "Linie incomplet??"
 
 msgid "Invalid response"
-msgstr "R?spuns invalid"
+msgstr "R??spuns invalid"
 
 msgid "No agent running"
-msgstr "Nu ruleaz? nici un agent"
+msgstr "Nu ruleaz?? nici un agent"
 
 #, fuzzy
 #| msgid "agent error"
@@ -336,13 +336,13 @@ msgstr "Eroare server Assuan"
 
 #, fuzzy
 msgid "General Assuan error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 msgid "Invalid session key"
-msgstr "Cheie de sesiune invalid?"
+msgstr "Cheie de sesiune invalid??"
 
 msgid "Invalid S-expression"
-msgstr "Expresie-S invalid?"
+msgstr "Expresie-S invalid??"
 
 msgid "Unsupported algorithm"
 msgstr "Algoritm nesuportat"
@@ -366,7 +366,7 @@ msgid "Invalid parameter"
 msgstr "Parametru invalid"
 
 msgid "Wrong card"
-msgstr "Card gre?it"
+msgstr "Card gre??it"
 
 msgid "No dirmngr"
 msgstr "Nici un dirmngr"
@@ -384,13 +384,13 @@ msgid "CRL too old"
 msgstr "CRL prea vechi"
 
 msgid "Line too long"
-msgstr "Linie prea lung?"
+msgstr "Linie prea lung??"
 
 msgid "Not trusted"
-msgstr "Nu este de ?ncredere"
+msgstr "Nu este de ??ncredere"
 
 msgid "Operation cancelled"
-msgstr "Opera?iune anulat?"
+msgstr "Opera??iune anulat??"
 
 msgid "Bad CA certificate"
 msgstr "Certificat CA incorect"
@@ -405,13 +405,13 @@ msgid "Unsupported certificate"
 msgstr "Certificat nesuportat"
 
 msgid "Unknown S-expression"
-msgstr "Expresie-S necunoscut?"
+msgstr "Expresie-S necunoscut??"
 
 msgid "Unsupported protection"
-msgstr "Protec?ie nesuportat?"
+msgstr "Protec??ie nesuportat??"
 
 msgid "Corrupted protection"
-msgstr "Protec?ie corupt?"
+msgstr "Protec??ie corupt??"
 
 msgid "Ambiguous name"
 msgstr "Nume ambiguu"
@@ -420,7 +420,7 @@ msgid "Card error"
 msgstr "Eroare card"
 
 msgid "Card reset required"
-msgstr "Este necesar? resetarea cardului"
+msgstr "Este necesar?? resetarea cardului"
 
 msgid "Card removed"
 msgstr "Card scos"
@@ -432,10 +432,10 @@ msgid "Card not present"
 msgstr "Cardul nu este prezent"
 
 msgid "No PKCS15 application"
-msgstr "Nici o aplica?ie PKCS15"
+msgstr "Nici o aplica??ie PKCS15"
 
 msgid "Not confirmed"
-msgstr "Neconfirmat(?)"
+msgstr "Neconfirmat(??)"
 
 msgid "Configuration error"
 msgstr "Eroare de configurare"
@@ -459,34 +459,34 @@ msgid "Unsupported protocol"
 msgstr "Protocol nesuportat"
 
 msgid "Bad PIN method"
-msgstr "Metod? PIN incorect?"
+msgstr "Metod?? PIN incorect??"
 
 msgid "Card not initialized"
-msgstr "Card neini?ializat"
+msgstr "Card neini??ializat"
 
 msgid "Unsupported operation"
-msgstr "Opera?ie nesuportat?"
+msgstr "Opera??ie nesuportat??"
 
 msgid "Wrong key usage"
-msgstr "Folosire cheie gre?it?"
+msgstr "Folosire cheie gre??it??"
 
 msgid "Nothing found"
-msgstr "Nu a fost g?sit nimic"
+msgstr "Nu a fost g??sit nimic"
 
 msgid "Wrong blob type"
 msgstr "Tip de blob incorect"
 
 msgid "Missing value"
-msgstr "Valoare lips?"
+msgstr "Valoare lips??"
 
 msgid "Hardware problem"
-msgstr "Problem? hardware"
+msgstr "Problem?? hardware"
 
 msgid "PIN blocked"
 msgstr "PIN blocat"
 
 msgid "Conditions of use not satisfied"
-msgstr "Condi?ii de folosire nesatisf?cute"
+msgstr "Condi??ii de folosire nesatisf??cute"
 
 msgid "PINs are not synced"
 msgstr "PIN-urile nu sunt sincronizate"
@@ -501,22 +501,22 @@ msgid "Invalid BER"
 msgstr "BER invalid"
 
 msgid "Element not found"
-msgstr "Elementul nu a fost g?sit"
+msgstr "Elementul nu a fost g??sit"
 
 msgid "Identifier not found"
-msgstr "Identificator nu a fost g?sit"
+msgstr "Identificator nu a fost g??sit"
 
 msgid "Invalid tag"
-msgstr "Etichet? invalid?"
+msgstr "Etichet?? invalid??"
 
 msgid "Invalid length"
-msgstr "Lungime invalid?"
+msgstr "Lungime invalid??"
 
 msgid "Invalid key info"
-msgstr "Informa?ii cheie invalide"
+msgstr "Informa??ii cheie invalide"
 
 msgid "Unexpected tag"
-msgstr "Etichet? nea?teptat?"
+msgstr "Etichet?? nea??teptat??"
 
 msgid "Not DER encoded"
 msgstr "Nu e encodat DER"
@@ -534,10 +534,10 @@ msgid "Unsupported CMS object"
 msgstr "Obiect CMS nesuportat"
 
 msgid "Unsupported encoding"
-msgstr "Encodare nesuportat?"
+msgstr "Encodare nesuportat??"
 
 msgid "Unsupported CMS version"
-msgstr "Versiune CMS nesuportat?"
+msgstr "Versiune CMS nesuportat??"
 
 msgid "Unknown algorithm"
 msgstr "Algoritm necunoscut"
@@ -546,34 +546,34 @@ msgid "Invalid crypto engine"
 msgstr "Motor cifrare invalid"
 
 msgid "Public key not trusted"
-msgstr "Cheia public? nu este de ?ncredere"
+msgstr "Cheia public?? nu este de ??ncredere"
 
 msgid "Decryption failed"
-msgstr "Decriptarea a e?uat"
+msgstr "Decriptarea a e??uat"
 
 msgid "Key expired"
-msgstr "Cheie expirat?"
+msgstr "Cheie expirat??"
 
 msgid "Signature expired"
-msgstr "Semn?tur? expirat?"
+msgstr "Semn??tur?? expirat??"
 
 msgid "Encoding problem"
-msgstr "Problem? de encodare"
+msgstr "Problem?? de encodare"
 
 msgid "Invalid state"
-msgstr "Stare invalid?"
+msgstr "Stare invalid??"
 
 msgid "Duplicated value"
-msgstr "Valoare dubl?"
+msgstr "Valoare dubl??"
 
 msgid "Missing action"
-msgstr "Ac?iune lips?"
+msgstr "Ac??iune lips??"
 
 msgid "ASN.1 module not found"
-msgstr "Modulul ASN.1 nu a fost g?sit"
+msgstr "Modulul ASN.1 nu a fost g??sit"
 
 msgid "Invalid OID string"
-msgstr "?ir OID invalid"
+msgstr "??ir OID invalid"
 
 msgid "Invalid time"
 msgstr "Timp invalid"
@@ -582,7 +582,7 @@ msgid "Invalid CRL object"
 msgstr "Obiect CRL invalid"
 
 msgid "Unsupported CRL version"
-msgstr "Versiune CRL nesuportat?"
+msgstr "Versiune CRL nesuportat??"
 
 msgid "Invalid certificate object"
 msgstr "Obiect certificat incorect"
@@ -591,10 +591,10 @@ msgid "Unknown name"
 msgstr "Nume necunoscut"
 
 msgid "A locale function failed"
-msgstr "O func?ie locale a e?uat"
+msgstr "O func??ie locale a e??uat"
 
 msgid "Not locked"
-msgstr "Nefor?at(?)"
+msgstr "Nefor??at(??)"
 
 msgid "Protocol violation"
 msgstr "Violare de protocol"
@@ -603,23 +603,23 @@ msgid "Invalid MAC"
 msgstr "MAC invalid"
 
 msgid "Invalid request"
-msgstr "Cerere invalid?"
+msgstr "Cerere invalid??"
 
 #, fuzzy
 msgid "Unknown extension"
-msgstr "Expresie-S necunoscut?"
+msgstr "Expresie-S necunoscut??"
 
 #, fuzzy
 msgid "Unknown critical extension"
-msgstr "Expresie-S necunoscut?"
+msgstr "Expresie-S necunoscut??"
 
 #, fuzzy
 msgid "Locked"
-msgstr "Nefor?at(?)"
+msgstr "Nefor??at(??)"
 
 #, fuzzy
 msgid "Unknown option"
-msgstr "Expresie-S necunoscut?"
+msgstr "Expresie-S necunoscut??"
 
 #, fuzzy
 msgid "Unknown command"
@@ -627,18 +627,18 @@ msgstr "Cod de eroare necunoscut"
 
 #, fuzzy
 msgid "Not operational"
-msgstr "Opera?ie nesuportat?"
+msgstr "Opera??ie nesuportat??"
 
 #, fuzzy
 msgid "No passphrase given"
-msgstr "Fraz?-parol? incorect?"
+msgstr "Fraz??-parol?? incorect??"
 
 msgid "No PIN given"
 msgstr ""
 
 #, fuzzy
 msgid "Not enabled"
-msgstr "Nefor?at(?)"
+msgstr "Nefor??at(??)"
 
 #, fuzzy
 msgid "No crypto engine"
@@ -646,7 +646,7 @@ msgstr "Motor cifrare invalid"
 
 #, fuzzy
 msgid "Missing key"
-msgstr "Valoare lips?"
+msgstr "Valoare lips??"
 
 #, fuzzy
 msgid "Too many objects"
@@ -657,11 +657,11 @@ msgstr ""
 
 #, fuzzy
 msgid "Not initialized"
-msgstr "Card neini?ializat"
+msgstr "Card neini??ializat"
 
 #, fuzzy
 msgid "Missing issuer certificate"
-msgstr "Certificat lips?"
+msgstr "Certificat lips??"
 
 msgid "No keyserver available"
 msgstr ""
@@ -672,12 +672,12 @@ msgstr "Timp invalid"
 
 #, fuzzy
 msgid "Unknown elliptic curve"
-msgstr "Surs? necunoscut?"
+msgstr "Surs?? necunoscut??"
 
 #, fuzzy
 #| msgid "Duplicated value"
 msgid "Duplicated key"
-msgstr "Valoare dubl?"
+msgstr "Valoare dubl??"
 
 #, fuzzy
 #| msgid "Ambiguous name"
@@ -703,12 +703,12 @@ msgstr ""
 #, fuzzy
 #| msgid "No public key"
 msgid "Broken public key"
-msgstr "Nici o cheie public?"
+msgstr "Nici o cheie public??"
 
 #, fuzzy
 #| msgid "No secret key"
 msgid "Broken secret key"
-msgstr "Nici o cheie secret?"
+msgstr "Nici o cheie secret??"
 
 #, fuzzy
 #| msgid "Invalid digest algorithm"
@@ -717,53 +717,53 @@ msgstr "Algoritm rezumat invalid"
 
 #, fuzzy
 msgid "Operation fully cancelled"
-msgstr "Opera?iune anulat?"
+msgstr "Opera??iune anulat??"
 
 #, fuzzy
 msgid "Operation not yet finished"
-msgstr "Opera?iune anulat?"
+msgstr "Opera??iune anulat??"
 
 msgid "Buffer too short"
 msgstr "Buffer prea scurt"
 
 msgid "Invalid length specifier in S-expression"
-msgstr "Specificarea lungimii invalid? ?n expresia-S"
+msgstr "Specificarea lungimii invalid?? ??n expresia-S"
 
 msgid "String too long in S-expression"
-msgstr "?ir prea lung ?n expresia-S"
+msgstr "??ir prea lung ??n expresia-S"
 
 msgid "Unmatched parentheses in S-expression"
-msgstr "Parantez? f?r? pereche ?n expresia-S"
+msgstr "Parantez?? f??r?? pereche ??n expresia-S"
 
 msgid "S-expression not canonical"
-msgstr "Expresia-S nu este canonic?"
+msgstr "Expresia-S nu este canonic??"
 
 msgid "Bad character in S-expression"
-msgstr "Caracter invalid ?n expresia-S"
+msgstr "Caracter invalid ??n expresia-S"
 
 msgid "Bad quotation in S-expression"
-msgstr "Ghilimele incorecte ?n expresia-S"
+msgstr "Ghilimele incorecte ??n expresia-S"
 
 msgid "Zero prefix in S-expression"
-msgstr "Prefix zero ?n expresia-S"
+msgstr "Prefix zero ??n expresia-S"
 
 msgid "Nested display hints in S-expression"
-msgstr "Indica?ii de afi?are ?ncuib?rite ?n expresia-S"
+msgstr "Indica??ii de afi??are ??ncuib??rite ??n expresia-S"
 
 msgid "Unmatched display hints"
-msgstr "Indica?ii de afi?are f?r? pereche"
+msgstr "Indica??ii de afi??are f??r?? pereche"
 
 msgid "Unexpected reserved punctuation in S-expression"
-msgstr "Punctua?ie rezervat? nea?teptat? ?n expresia-S"
+msgstr "Punctua??ie rezervat?? nea??teptat?? ??n expresia-S"
 
 msgid "Bad hexadecimal character in S-expression"
-msgstr "Caracter hexazecimal incorect ?n expresia-S"
+msgstr "Caracter hexazecimal incorect ??n expresia-S"
 
 msgid "Odd hexadecimal numbers in S-expression"
-msgstr "Numere hexazecimale ciudate ?n expresia-S"
+msgstr "Numere hexazecimale ciudate ??n expresia-S"
 
 msgid "Bad octal character in S-expression"
-msgstr "Caracter octal incorect ?n expresia-S"
+msgstr "Caracter octal incorect ??n expresia-S"
 
 msgid "All subkeys are expired or revoked"
 msgstr ""
@@ -784,7 +784,7 @@ msgstr "Nume necunoscut"
 #, fuzzy
 #| msgid "No public key"
 msgid "No key"
-msgstr "Nici o cheie public?"
+msgstr "Nici o cheie public??"
 
 msgid "Legacy key"
 msgstr ""
@@ -797,7 +797,7 @@ msgstr "Buffer prea scurt"
 #, fuzzy
 #| msgid "Line too long"
 msgid "Request too long"
-msgstr "Linie prea lung?"
+msgstr "Linie prea lung??"
 
 msgid "Object is in termination state"
 msgstr ""
@@ -805,7 +805,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Bad certificate chain"
 msgid "No certificate chain"
-msgstr "Lan? certificate incorect"
+msgstr "Lan?? certificate incorect"
 
 #, fuzzy
 #| msgid "Certificate too young"
@@ -823,7 +823,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Unexpected tag"
 msgid "Unexpected message"
-msgstr "Etichet? nea?teptat?"
+msgstr "Etichet?? nea??teptat??"
 
 msgid "Compression or decompression failed"
 msgstr ""
@@ -841,7 +841,7 @@ msgstr "Algoritm cifrare invalid"
 
 #, fuzzy
 msgid "Missing client certificate"
-msgstr "Certificat lips?"
+msgstr "Certificat lips??"
 
 #, fuzzy
 #| msgid "Certificate revoked"
@@ -851,12 +851,12 @@ msgstr "Certificat revocat"
 #, fuzzy
 #| msgid "Key expired"
 msgid "Ticket expired"
-msgstr "Cheie expirat?"
+msgstr "Cheie expirat??"
 
 #, fuzzy
 #| msgid "Bad public key"
 msgid "Bad ticket"
-msgstr "Cheie public? incorect?"
+msgstr "Cheie public?? incorect??"
 
 #, fuzzy
 #| msgid "Unknown packet"
@@ -866,7 +866,7 @@ msgstr "Pachet necunoscut"
 #, fuzzy
 #| msgid "Bad certificate chain"
 msgid "Bad certificate message in handshake"
-msgstr "Lan? certificate incorect"
+msgstr "Lan?? certificate incorect"
 
 msgid "Bad certificate request message in handshake"
 msgstr ""
@@ -904,7 +904,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Key expired"
 msgid "Key disabled"
-msgstr "Cheie expirat?"
+msgstr "Cheie expirat??"
 
 msgid "Not possible with a card based key"
 msgstr ""
@@ -922,7 +922,7 @@ msgstr ""
 
 #, fuzzy
 msgid "General IPC error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 msgid "IPC accept call failed"
 msgstr ""
@@ -932,19 +932,19 @@ msgstr ""
 
 #, fuzzy
 msgid "Invalid IPC response"
-msgstr "R?spuns invalid"
+msgstr "R??spuns invalid"
 
 #, fuzzy
 msgid "Invalid value passed to IPC"
-msgstr "Valoare invalid?"
+msgstr "Valoare invalid??"
 
 #, fuzzy
 msgid "Incomplete line passed to IPC"
-msgstr "Linie incomplet?"
+msgstr "Linie incomplet??"
 
 #, fuzzy
 msgid "Line passed to IPC too long"
-msgstr "Linie prea lung?"
+msgstr "Linie prea lung??"
 
 msgid "Nested IPC commands"
 msgstr ""
@@ -977,7 +977,7 @@ msgstr ""
 
 #, fuzzy
 msgid "Unexpected IPC command"
-msgstr "Etichet? nea?teptat?"
+msgstr "Etichet?? nea??teptat??"
 
 #, fuzzy
 msgid "Unknown IPC command"
@@ -985,7 +985,7 @@ msgstr "Cod de eroare necunoscut"
 
 #, fuzzy
 msgid "IPC syntax error"
-msgstr "Eroare de sintax?"
+msgstr "Eroare de sintax??"
 
 msgid "IPC call has been cancelled"
 msgstr ""
@@ -1002,7 +1002,7 @@ msgstr "Eroare card"
 
 #, fuzzy
 msgid "Unknown IPC inquire"
-msgstr "Surs? necunoscut?"
+msgstr "Surs?? necunoscut??"
 
 #, fuzzy
 msgid "Crypto engine too old"
@@ -1026,7 +1026,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Duplicated value"
 msgid "Duplicated name"
-msgstr "Valoare dubl?"
+msgstr "Valoare dubl??"
 
 #, fuzzy
 #| msgid "Certificate too young"
@@ -1040,30 +1040,30 @@ msgstr "Obiectul furnizat e prea scurt"
 
 #, fuzzy
 msgid "General LDAP error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 #, fuzzy
 #| msgid "General error"
 msgid "General LDAP attribute error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 #, fuzzy
 #| msgid "General error"
 msgid "General LDAP name error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 #, fuzzy
 msgid "General LDAP security error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 #, fuzzy
 #| msgid "General error"
 msgid "General LDAP service error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 #, fuzzy
 msgid "General LDAP update error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 msgid "Experimental LDAP error code"
 msgstr ""
@@ -1074,17 +1074,17 @@ msgstr "Eroare card"
 
 #, fuzzy
 msgid "Other general LDAP error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 #, fuzzy
 #| msgid "Decryption failed"
 msgid "LDAP connecting failed (X)"
-msgstr "Decriptarea a e?uat"
+msgstr "Decriptarea a e??uat"
 
 #, fuzzy
 #| msgid "General error"
 msgid "LDAP referral limit exceeded"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 msgid "LDAP client loop"
 msgstr ""
@@ -1092,22 +1092,22 @@ msgstr ""
 #, fuzzy
 #| msgid "Card reset required"
 msgid "No LDAP results returned"
-msgstr "Este necesar? resetarea cardului"
+msgstr "Este necesar?? resetarea cardului"
 
 #, fuzzy
 #| msgid "Element not found"
 msgid "LDAP control not found"
-msgstr "Elementul nu a fost g?sit"
+msgstr "Elementul nu a fost g??sit"
 
 #, fuzzy
 #| msgid "Not supported"
 msgid "Not supported by LDAP"
-msgstr "Nu este suportat(?)"
+msgstr "Nu este suportat(??)"
 
 #, fuzzy
 #| msgid "Unexpected error"
 msgid "LDAP connect error"
-msgstr "Eroare nea?teptat?"
+msgstr "Eroare nea??teptat??"
 
 msgid "Out of memory in LDAP"
 msgstr ""
@@ -1118,7 +1118,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Unsupported operation"
 msgid "User cancelled LDAP operation"
-msgstr "Opera?ie nesuportat?"
+msgstr "Opera??ie nesuportat??"
 
 #, fuzzy
 #| msgid "Bad certificate"
@@ -1127,12 +1127,12 @@ msgstr "Certificat incorect"
 
 #, fuzzy
 msgid "Unknown LDAP authentication method"
-msgstr "Expresie-S necunoscut?"
+msgstr "Expresie-S necunoscut??"
 
 #, fuzzy
 #| msgid "Timeout"
 msgid "Timeout in LDAP"
-msgstr "Pauz?"
+msgstr "Pauz??"
 
 #, fuzzy
 #| msgid "dirmngr error"
@@ -1180,7 +1180,7 @@ msgstr ""
 
 #, fuzzy
 msgid "LDAP authentication method not supported"
-msgstr "Expresie-S necunoscut?"
+msgstr "Expresie-S necunoscut??"
 
 msgid "Strong(er) LDAP authentication required"
 msgstr ""
@@ -1191,7 +1191,7 @@ msgstr ""
 #, fuzzy
 #| msgid "General error"
 msgid "LDAP referral"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 msgid "Administrative LDAP limit exceeded"
 msgstr ""
@@ -1202,7 +1202,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Card reset required"
 msgid "Confidentiality required by LDAP"
-msgstr "Este necesar? resetarea cardului"
+msgstr "Este necesar?? resetarea cardului"
 
 msgid "LDAP SASL bind in progress"
 msgstr ""
@@ -1218,7 +1218,7 @@ msgstr "Argument invalid"
 #, fuzzy
 #| msgid "Unsupported protection"
 msgid "Inappropriate matching in LDAP"
-msgstr "Protec?ie nesuportat?"
+msgstr "Protec??ie nesuportat??"
 
 #, fuzzy
 #| msgid "Protocol violation"
@@ -1231,7 +1231,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Invalid state"
 msgid "Invalid syntax in LDAP"
-msgstr "Stare invalid?"
+msgstr "Stare invalid??"
 
 #, fuzzy
 #| msgid "No CMS object"
@@ -1241,12 +1241,12 @@ msgstr "Nici un obiect CMS"
 #, fuzzy
 #| msgid "Hardware problem"
 msgid "LDAP alias problem"
-msgstr "Problem? hardware"
+msgstr "Problem?? hardware"
 
 #, fuzzy
 #| msgid "Invalid state"
 msgid "Invalid DN syntax in LDAP"
-msgstr "Stare invalid?"
+msgstr "Stare invalid??"
 
 msgid "LDAP entry is a leaf"
 msgstr ""
@@ -1254,7 +1254,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Encoding problem"
 msgid "LDAP alias dereferencing problem"
-msgstr "Problem? de encodare"
+msgstr "Problem?? de encodare"
 
 msgid "LDAP proxy authorization failure (X)"
 msgstr ""
@@ -1262,7 +1262,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Unsupported protection"
 msgid "Inappropriate LDAP authentication"
-msgstr "Protec?ie nesuportat?"
+msgstr "Protec??ie nesuportat??"
 
 #, fuzzy
 #| msgid "Invalid card"
@@ -1287,7 +1287,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Missing action"
 msgid "LDAP naming violation"
-msgstr "Ac?iune lips?"
+msgstr "Ac??iune lips??"
 
 #, fuzzy
 #| msgid "Protocol violation"
@@ -1296,12 +1296,12 @@ msgstr "Violare de protocol"
 
 #, fuzzy
 msgid "LDAP operation not allowed on non-leaf"
-msgstr "Opera?iune anulat?"
+msgstr "Opera??iune anulat??"
 
 #, fuzzy
 #| msgid "Operation cancelled"
 msgid "LDAP operation not allowed on RDN"
-msgstr "Opera?iune anulat?"
+msgstr "Opera??iune anulat??"
 
 msgid "Already exists (LDAP)"
 msgstr ""
@@ -1312,19 +1312,19 @@ msgstr ""
 #, fuzzy
 #| msgid "Line too long"
 msgid "LDAP results too large"
-msgstr "Linie prea lung?"
+msgstr "Linie prea lung??"
 
 #, fuzzy
 #| msgid "Operation cancelled"
 msgid "LDAP operation affects multiple DSAs"
-msgstr "Opera?iune anulat?"
+msgstr "Opera??iune anulat??"
 
 msgid "Virtual LDAP list view error"
 msgstr ""
 
 #, fuzzy
 msgid "Other LDAP error"
-msgstr "Eroare general?"
+msgstr "Eroare general??"
 
 #, fuzzy
 #| msgid "Resources exhausted"
@@ -1339,7 +1339,7 @@ msgstr "Violare de protocol"
 #, fuzzy
 #| msgid "Invalid state"
 msgid "Invalid data in LCUP"
-msgstr "Stare invalid?"
+msgstr "Stare invalid??"
 
 #, fuzzy
 #| msgid "Unsupported certificate"
@@ -1349,7 +1349,7 @@ msgstr "Certificat nesuportat"
 #, fuzzy
 #| msgid "Card reset required"
 msgid "Reload required in LCUP"
-msgstr "Este necesar? resetarea cardului"
+msgstr "Este necesar?? resetarea cardului"
 
 #, fuzzy
 #| msgid "Success"
@@ -1358,11 +1358,11 @@ msgstr "Succes"
 
 #, fuzzy
 msgid "No LDAP operation to cancel"
-msgstr "Opera?ie nesuportat?"
+msgstr "Opera??ie nesuportat??"
 
 #, fuzzy
 msgid "Too late to cancel LDAP"
-msgstr "Opera?ie nesuportat?"
+msgstr "Opera??ie nesuportat??"
 
 msgid "Cannot cancel LDAP"
 msgstr ""
@@ -1370,7 +1370,7 @@ msgstr ""
 #, fuzzy
 #| msgid "Decryption failed"
 msgid "LDAP assertion failed"
-msgstr "Decriptarea a e?uat"
+msgstr "Decriptarea a e??uat"
 
 msgid "Proxied authorization denied by LDAP"
 msgstr ""
@@ -1427,10 +1427,10 @@ msgid "System error w/o errno"
 msgstr ""
 
 msgid "Unknown system error"
-msgstr "Eroare de sistem necunoscut?"
+msgstr "Eroare de sistem necunoscut??"
 
 msgid "End of file"
-msgstr "Sf?r?it de fi?ier"
+msgstr "Sf??r??it de fi??ier"
 
 msgid "Unknown error code"
 msgstr "Cod de eroare necunoscut"
@@ -1441,7 +1441,7 @@ msgstr "Folosire: %s EROARE-GPG [...]\n"
 
 #, c-format
 msgid "%s: warning: could not recognize %s\n"
-msgstr "%s: avertisment: nu am putut recunoa?te %s\n"
+msgstr "%s: avertisment: nu am putut recunoa??te %s\n"
 
 #, fuzzy
 #~| msgid "Resources exhausted"
@@ -1456,12 +1456,12 @@ msgstr "%s: avertisment: nu am putut recunoa
 #, fuzzy
 #~| msgid "Decryption failed"
 #~ msgid "Assertion failed in lDAP"
-#~ msgstr "Decriptarea a e?uat"
+#~ msgstr "Decriptarea a e??uat"
 
 #, fuzzy
 #~| msgid "General error"
 #~ msgid "LDAP Other general error"
-#~ msgstr "Eroare general?"
+#~ msgstr "Eroare general??"
 
 #, fuzzy
 #~| msgid "dirmngr error"
-- 
2.10.2



From dkg at fifthhorseman.net  Wed Nov 16 00:52:45 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Nov 2016 08:52:45 +0900
Subject: [LIBGPG-ERROR PATCH 5/6] w32: Update links from http to https.
In-Reply-To: <20161115235246.24860-1-dkg@fifthhorseman.net>
References: <20161115235246.24860-1-dkg@fifthhorseman.net>
Message-ID: <20161115235246.24860-5-dkg@fifthhorseman.net>

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 src/w32-iconv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/w32-iconv.c b/src/w32-iconv.c
index 47a06b2..c10bb32 100644
--- a/src/w32-iconv.c
+++ b/src/w32-iconv.c
@@ -389,7 +389,7 @@ static struct {
 
     /*
      * Code Page Identifiers
-     * http://msdn2.microsoft.com/en-us/library/ms776446.aspx
+     * https://msdn.microsoft.com/en-us/library/dd317756.aspx
      */
     {37, "IBM037"}, /* IBM EBCDIC US-Canada */
     {437, "IBM437"}, /* OEM United States */
@@ -968,7 +968,7 @@ name_to_codepage(const char *name)
 }
 
 /*
- * http://www.faqs.org/rfcs/rfc2781.html
+ * https://tools.ietf.org/html/rfc2781
  */
 static uint
 utf16_to_ucs4(const ushort *wbuf)
-- 
2.10.2



From gniibe at fsij.org  Wed Nov 16 03:25:01 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 16 Nov 2016 11:25:01 +0900
Subject: Poldi
Message-ID: <b7e1835a-ed71-968f-9415-de5c5ed55b04@fsij.org>

Hello,

I am a maintainer of Debian Poldi package.  I did package it up, so
that people can stop complaining that it is too difficult to build.  I
do that to share the work of building the software.

Although I occasionally push some changes to upstream (to keep it
working), I don't want to put my energy to maintain the upstream.

It is somewhat difficult for me to say I'm working for Poldi, as I am
not that positive for this software.  Please understand this unclear
situation of mine.

Basically, I can't imagine useful/effective use cases of PAM
authentication by Poldi with OpenPGP card, while I noticed possible
misuses and possible weakness of the implementation.


Having said that, I recently pushed some changes to Poldi.  That's
mainly because GnuPG 2.1 deprecated use of the environment variable
GPG_AGENT_INFO.

I added following entries in poldi/NEWS file.

==============================================================
Changes since version 0.4.1:

* poldi-ctrl is removed
  Please use gpg-connect-agent instead.

* For backward compatibility of sudo and screen unlock
  In GnuPG 2.1, the environment variable GPG_AGENT_INFO is gone.  And
  now, Poldi's default is invoking scdaemon directly.  Still, there
  are use cases (like sudo and screen unlock) which expect connecting
  user's gpg-agent.  For this purpose, Poldi now distinguishes a case
  where pam_username == username_of_process_uid.  Only for such a case,
  Poldi tries to find scdaemon under gpg-agent.

* Poldi invokes scdaemon to connect it through pipe
  Older Poldi has a feature of connecting to scdaemon with help of
  gpg-agent using the GPG_AGENT_INFO enviornment variable.  In GnuPG
  2.1, the environment variable GPG_AGENT_INFO is gone and scdaemon no
  longer keeps locking the reader after card removal, it is good to
  always invoke scdaemon for the authentication by default.  If there
  is an existing scdaemon with card inserted, a failure is expected
  and this is safer fallback.  That's because Poldi should not connect
  to a smartcard which is in use for other purpose and possibly
  already authenticated.
==============================================================


I got a report that my change breaks a use case:

   * In the system, Poldi is configured for su.  A public key of auth
     key is registered in /etc/poldi/localdb for "root".

     That is, the system allows use of "su" service to the holder of
     the auth private key.

   * A user has an OpenPGP card with signing key, decryption key and
     auth key.

   * The card is in use by gpg-agent for a user for signing/decryption.

   * When typing "su -" to become superuser, it is the intention of
     the user to use the auth key in the card.


I don't know how/if Poldi can support this use case correctly.  It's
too difficult to solve for me.  I need your help.

(If I were the user and the admin of the system, I'd configure sudo
for Poldi and use "sudo -i".)


I think that it's not good in general for Poldi to connect to existing
scdaemon;  The scdaemon could be malicious one to steal other persons
PIN (if it's shared computer).
-- 


From dkg at fifthhorseman.net  Wed Nov 16 05:30:13 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Nov 2016 13:30:13 +0900
Subject: [GPGME PATCH] core: Enable extraction of session keys.
In-Reply-To: <87a8d0yf5l.fsf@wheatstone.g10code.de>
References: <20161111074928.3780-1-dkg@fifthhorseman.net>
 <878tslyt85.fsf@wheatstone.g10code.de>
 <87eg2cappj.fsf@alice.fifthhorseman.net>
 <87a8d0yf5l.fsf@wheatstone.g10code.de>
Message-ID: <8737is9hd6.fsf@alice.fifthhorseman.net>

On Tue 2016-11-15 23:46:30 +0900, Werner Koch wrote:
> If you build software using a new header we can assume that the it is
> also linked to the matching version of the library.  The SO minor number
> will be bumped up for the release (but not in the git version).  By
> tinkering with the build system I mean to force linking against an older
> SO; that is installing just the application but not the library and
> hoping that everything works.

In practice, at runtime, the linker normally looks for the SO major
number, not the SO minor number.  that is, it looks for libfoo.so.X, not
libfoo.so.X.Y.

Most people who install software today did not build it themselves, and
they rely on library dependency declarations, as stated by their package
managers.  So its the dependency declaratoins done by the package
managers that need to be well-formed.

>> with the choice of using gpgme_set_ctx_flag instead of
>> gpgme_set_export_session_keys, we don't have any exported symbol to
>> catch errors when the dynamic linker runs.
>
> We have
>
>  gpgme_set_sender                NEW.
>  gpgme_get_sender                NEW.
>  gpgme_op_query_swdb             NEW.
>  gpgme_op_query_swdb_result      NEW.
>  gpgme_query_swdb_result_t       NEW.
>  gpgme_get_ctx_flag              NEW.
>
> however they are most likely not used.  That is the same as with
> gpgme_set_export_session_keys.

sure, but if we say that gpgme-dependent softwre that accesses
->session_key must have invoked gpgme_set_export_session_keys(), then
that software will use the symbols (and get mapped to the correct, tight
dependencies).  And other gpgme-dependent software that *doesn't* ever
access ->session_key won't use the symbol, and it will get mapped to
(also correct) looser depenedencies, making it easier to install on
different systems.

> Well, we have new exported symbols.  And the SO minor will be bumbed.
> So both mechanismn are in place; the Debian thing and the proper thing
> all libraries should do.

If there's no guidance that requires users to test whether the library
actually supports the new field, and there's no explicit symbol use,
then the safest thing for me to do as a distributor will be to implement
much more strict versioning than i'd otherwise need to, which will make
binary packages harder for people to install.  *shrug* so it goes.

>> If this is intended to be an example for how others should use this
>> feature, it's a bit dangerous to not check the error return value from
>> gpgme_set_ctx_flag, no?
>
> Okay, I thought I could leave that out because we don't have a way to
> check whether the override works in gpg.  But, okay for education I add
> an error check.

I'll send a patch shortly, now that i hear you're OK with this.  thanks!

>> It would be good to have a bit of documentation that ensures that the
>> user at least tests that the flags have been properly set.
>
> We are extending the result structures for more than 10 years.  I am not
> aware of any problems related to this.  Granted, some of these changes
> are merely new bits taken from a reserved bit field variable but often
> enough we added new pointer fields.

I'm not sure what to tell you about why you haven't heard about these
problems.  They're easy to trigger, unfortunately.

>> +You must not try to access this member of the struct unless
>> + at code{gpgme_set_ctx_flag (ctx, "export-session-key")} returns
>> + at code{GPG_ERR_NO_ERROR} or @code{gpgme_get_ctx_flag (ctx,
>
> We would need to add such requirments to a lot of other fucntions as
> well.  For example the TOFU stuff also adds new fields to the result
> structure which _may_ only be set when GPGME_KEYLIST_MODE_WITH_TOFU is
> used.

it's not a question of whether the fields are *set* correctly -- even
checking to see whether they're NULL or not when run against older
versions of the library will cause a segmentation fault.  So it's
critically important to not try to access them *at all* unless you know
for certain that you're using a version of the library that supports it.

> For backward compatible changes on glibc systems we bump the minor SO
> number - what's wrong with this approach?  Just because some projects
> don't do proper ABI tracking we shall fallback to such hacks as tracking
> new symbol names?

it's not "hacks", it's a commonly-accepted practice [0], and there are
good reasons for it.

The better package managers try to ensure that their dependencies are as
*loose* as possible, so that binary packages are as widely-deployable as
possible.

The simplest way to do that effectively given the binary packages is to
inspect the linked symbols.  If the API changes in such a way that it's
not detectable by symbol changes, then the package managers are forced
to create tighter dependencies to avoid runtime failures.  This makes it
more difficult to install software on different systems.

This isn't the end of the world, but it's a consequence of the API
design that ought to be made explicitly.

> If you really really want it, I guess we could add extra code on glibc
> systems to detect broken installations.  But is it really worse the
> trouble and extra bugs just due to this code?  We used such magic in
> GNOME more than 15 years ago.  Can you point me to any bug reported
> related to GPGME caused by such improper use?  I only recall problems
> with off_t and off64_t for which we added detection code to gpgme.

No, please do not add extra code to do a custom check for this at
runtime.  The ideal situation would be a library with symbol-based
versioning (or some other standard, simple mechanism).  that would let
us check things at build time and map them to explicit
dependencies. Barring that, we can just make the external dependency
declarations tighter and carry on.

Thanks for the discussion!

       --dkg

[0] e.g. "Do not expose any complex structures in your API; Use get()
    and set() instead." from libabc's README, which also encourages the
    use of symbol versioning:
     https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/plain/README
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: </pipermail/attachments/20161116/1a1d6b2c/attachment.sig>

From dkg at fifthhorseman.net  Wed Nov 16 06:10:22 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Nov 2016 14:10:22 +0900
Subject: [GPGME PATCH] doc,
 tests: Require use of ctx_flag before use of session_key.
In-Reply-To: <8737is9hd6.fsf@alice.fifthhorseman.net>
References: <8737is9hd6.fsf@alice.fifthhorseman.net>
Message-ID: <20161116051022.4189-1-dkg@fifthhorseman.net>

* doc/gpgme.texi: Document requirements of verifying that it is OK to
use session_key.
* tests/run-decrypt.c: Ensure that we fail if we're unable to access
the session key, so that we do not violate the guidance above.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 doc/gpgme.texi      |  5 +++++
 tests/run-decrypt.c | 20 ++++++++++++++++++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index fd396e0..8820312 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -4814,6 +4814,11 @@ set to export session keys (see @code{gpgme_set_ctx_flag,
 "export-session-key"}), and a session key was available for the most
 recent decryption operation.  Otherwise, this is a null pointer.
 
+You must not try to access this member of the struct unless
+ at code{gpgme_set_ctx_flag (ctx, "export-session-key")} returns
+ at code{GPG_ERR_NO_ERROR} or @code{gpgme_get_ctx_flag (ctx,
+"export-session-key")} returns @code{"1"}.
+
 @end table
 @end deftp
 
diff --git a/tests/run-decrypt.c b/tests/run-decrypt.c
index 65624d0..b9042bb 100644
--- a/tests/run-decrypt.c
+++ b/tests/run-decrypt.c
@@ -174,9 +174,25 @@ main (int argc, char **argv)
       gpgme_set_ctx_flag (ctx, "full-status", "1");
     }
   if (export_session_key)
-    gpgme_set_ctx_flag (ctx, "export-session-key", "1");
+    {
+      err = gpgme_set_ctx_flag (ctx, "export-session-key", "1");
+      if (err)
+        {
+          fprintf (stderr, PGM ": error requesting exported session key: %s\n",
+                   gpgme_strerror (err));
+          exit (1);
+        }
+    }
   if (override_session_key)
-    gpgme_set_ctx_flag (ctx, "override-session-key", override_session_key);
+    {
+      err = gpgme_set_ctx_flag (ctx, "overrride-session-key", "1");
+      if (err)
+        {
+          fprintf (stderr, PGM ": error overriding session key: %s\n",
+                   gpgme_strerror (err));
+          exit (1);
+        }
+    }
 
   err = gpgme_data_new_from_stream (&in, fp_in);
   if (err)
-- 
2.10.2



From dkg at fifthhorseman.net  Wed Nov 16 07:22:11 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Nov 2016 15:22:11 +0900
Subject: gpgme's override-session-key property leaks into the process table
Message-ID: <87zil07xm4.fsf@alice.fifthhorseman.net>

Hi all--

Werner, thanks for integrating the session-key stuff in gpgme!

I just noticed that setting the session key via gpgme will leak the
session key to the process table. :(

That seems a little troubling: it means that on a typical machine (with
global process table visibility) someone who sees an encrypted message
in transit and monitors the process table could grab the session key
From a user who uses a tool that uses this feature.

Fixing this would probably require fixing gpg itself
(e.g. --override-session-key-fd or --override-session-key-envvar) and
then adjusting how it's invoked in gpgme.

i don't plan on using --override-session-key immediately (harvesting
with --export-session-key comes first), but eventually someone will, and
this could be a bad outcome.  Should we add a warning to the
documentation at the moment in lieu of a fix?  or should we just fix it
before release?

sorry to raise these concerns when we're trying to do a release, i want
to make sure we're clear about the tradeoffs to any developers who might
rely on gpgme for this.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: </pipermail/attachments/20161116/d8000c37/attachment.sig>

From wk at gnupg.org  Wed Nov 16 07:54:53 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 16 Nov 2016 07:54:53 +0100
Subject: gpgme's override-session-key property leaks into the process table
In-Reply-To: <87zil07xm4.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 16 Nov 2016 15:22:11 +0900")
References: <87zil07xm4.fsf@alice.fifthhorseman.net>
Message-ID: <87a8czx6bm.fsf@wheatstone.g10code.de>

On Wed, 16 Nov 2016 07:22, dkg at fifthhorseman.net said:

> I just noticed that setting the session key via gpgme will leak the
> session key to the process table. :(

Ah yes.  With the use case you described this is not good.  The original
reason for --override-session-key was a different one: When the first UK
RIP act was set in power Caspar Bowden asked me to for a way to mitigate
the effect.  According to him the act did not require that the private
key needs to be given to the police but just the key and that could very
well be the session key.

> Fixing this would probably require fixing gpg itself
> (e.g. --override-session-key-fd or --override-session-key-envvar) and

Yet another fd to pass:-(.  On Unix we could use an envvar by setting it
after the fork, but that does not work on Windows (leaked to the
process' memory and problems with threads).  A better solution would be
to wait until we have changed gpg to be an Assuan server.  But that will
not happen soon.

> this could be a bad outcome.  Should we add a warning to the
> documentation at the moment in lieu of a fix?  or should we just fix it

I'll add a warning to gpg and gpgme for now.  After the release we can
add the --override-session-key-fd session id thing - maybe even for
2.1.16.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161116/792ffff9/attachment.sig>

From wk at gnupg.org  Wed Nov 16 10:20:13 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 16 Nov 2016 10:20:13 +0100
Subject: gpgme's override-session-key property leaks into the process table
In-Reply-To: <87zil07xm4.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 16 Nov 2016 15:22:11 +0900")
References: <87zil07xm4.fsf@alice.fifthhorseman.net>
Message-ID: <87wpg3vl0y.fsf@wheatstone.g10code.de>

On Wed, 16 Nov 2016 07:22, dkg at fifthhorseman.net said:

> Fixing this would probably require fixing gpg itself
> (e.g. --override-session-key-fd or --override-session-key-envvar) and
> then adjusting how it's invoked in gpgme.

Both done.  Thus when using gnupg 2.1.16 the session key will be set with
--override-session-key-fd.  I added qwarning notes for use with older
gpg versions.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161116/92640428/attachment-0001.sig>

From wk at gnupg.org  Wed Nov 16 13:00:28 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 16 Nov 2016 13:00:28 +0100
Subject: gpgconf --launch ignores gpgconf.conf?
In-Reply-To: <10341419.Z49yr6ZIgR@liwardyna> (Maciej Mrozowski's message of
 "Tue, 25 Oct 2016 22:28:58 +0200")
References: <10341419.Z49yr6ZIgR@liwardyna>
Message-ID: <87mvgzvdlv.fsf@wheatstone.g10code.de>

On Tue, 25 Oct 2016 22:28, reavertm at gmail.com said:

> But it doesn't work, 'gpgconf --launch gpg-agent' starts it without required 
> option:

/etc/gnupg/gpgconf.conf is only used to modify configuration files.
Thus an admin can run the applygnupgdefault script to setup standard
configuration files for all users.  It also allows to inhibit users to
set change certain option via gpgconf (i.e. from a GUI tool).


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161116/78e613e3/attachment.sig>

From wk at gnupg.org  Wed Nov 16 14:07:25 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 16 Nov 2016 14:07:25 +0100
Subject: gpgme 1.8.0 released
Message-ID: <87inrnvaia.fsf@wheatstone.g10code.de>

Hi!

This is a quick announcement, that gpgme 1.8.0 is now available at the
usual places.


Noteworthy changes in version 1.8.0 (2016-11-16)
------------------------------------------------

 * The module of the Python bindings has been renamed to 'gpg'.

 * New interface to query current software versions.

 * New feature to use gpg's --{show,override}session-key options.

 * New interface to set the sender of a mail.

 * qt: Added Distinguished Name parser from libkleo

 * The --homedir option is now used with recent gpgconf versions.

 * On 64 bit Windows systems gpgconf is now properly located.

 * The internal locking functions have been replaced by libgpg-error
   locking functions.

 * Interface changes relative to the 1.7.1 release:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 gpgme_set_sender                NEW.
 gpgme_get_sender                NEW.
 gpgme_op_query_swdb             NEW.
 gpgme_op_query_swdb_result      NEW.
 gpgme_query_swdb_result_t       NEW.
 gpgme_get_ctx_flag              NEW.
 gpgme_decrypt_result_t          EXTENDED: New field session_key.
 qt: DN                          NEW.
 qt: DN::Attribute               NEW.
 qt: Job::context(Job*)          NEW.
 cpp: EngineInfo::Version::Version(const char*) NEW.
 cpp: EngineInfo::Version::Version()            NEW.
 cpp: SwdbResult                                NEW.
 cpp: Context::setSender(const char*)           NEW.
 cpp: Context::getSender()                      NEW.



Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161116/15bde943/attachment.sig>

From cmt at burggraben.net  Wed Nov 16 12:50:55 2016
From: cmt at burggraben.net (Christoph Moench-Tegeder)
Date: Wed, 16 Nov 2016 12:50:55 +0100
Subject: Latest libgpg-error breaks gpg-agent and more
Message-ID: <20161116115054.GA1632@elch.exwg.net>

Hi,

after the update to libgpg-error 1.25 (from 1.24) gpg-agent (from gnupg
2.1.15) aborts with core in npth ("Assertion failed: (res == 0), function
enter_npth, file npth.c, line 123").
Short investigation shows that the "sceptre" semaphore is being used
uninitialised. Some more investigation revealed that one would only
need to move the npth_init() call in agent/gpg-agent.c main() in front 
of the init_common_subsystems() call. On the other hand, there have
been more changes and code shuffling between 2.1.15 and HEAD in that
area, and commit fc0b392e766af8127094e8b529d25abb84ad1d65 (October 7th)
seems to have fixed the issue, judging from the commit message
("Call gpgrt_set_syscall_clamp after npth_init.").
Can we get gnupg 2.1.16 "real soon now"?

Regards,
Christoph

-- 
Spare Space


From wk at gnupg.org  Wed Nov 16 16:25:36 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 16 Nov 2016 16:25:36 +0100
Subject: Latest libgpg-error breaks gpg-agent and more
In-Reply-To: <20161116115054.GA1632@elch.exwg.net> (Christoph Moench-Tegeder's
 message of "Wed, 16 Nov 2016 12:50:55 +0100")
References: <20161116115054.GA1632@elch.exwg.net>
Message-ID: <8760nnv43z.fsf@wheatstone.g10code.de>

On Wed, 16 Nov 2016 12:50, cmt at burggraben.net said:

> after the update to libgpg-error 1.25 (from 1.24) gpg-agent (from gnupg
> 2.1.15) aborts with core in npth ("Assertion failed: (res == 0), function

Better an assertion failure than the hangs we have seen before ;-).

> uninitialised. Some more investigation revealed that one would only
> need to move the npth_init() call in agent/gpg-agent.c main() in front 

It is all caused by broken OS with weird semantics of unnamed
semaphores.  The fixes for that unfortunately broke things on Linux.
Delaying npth_init is a bit tricky and I would like to avoid it but
there are those OS X folks ...

> Can we get gnupg 2.1.16 "real soon now"?

I did a gpgme release today and 2.1.16 will be the next thing.  Maybe
tomorrow.  There is only that One Last Feature(tm) I want to get in.  We
will do a release in the current state with some open bugs but given
that 2.1.15 is already 3 months old it is better than no release.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161116/cadf1bef/attachment.sig>

From cmt at burggraben.net  Wed Nov 16 17:34:26 2016
From: cmt at burggraben.net (Christoph Moench-Tegeder)
Date: Wed, 16 Nov 2016 17:34:26 +0100
Subject: Latest libgpg-error breaks gpg-agent and more
In-Reply-To: <8760nnv43z.fsf@wheatstone.g10code.de>
References: <20161116115054.GA1632@elch.exwg.net>
 <8760nnv43z.fsf@wheatstone.g10code.de>
Message-ID: <20161116163426.GB1632@elch.exwg.net>

## Werner Koch (wk at gnupg.org):

> > after the update to libgpg-error 1.25 (from 1.24) gpg-agent (from gnupg
> > 2.1.15) aborts with core in npth ("Assertion failed: (res == 0), function
> Better an assertion failure than the hangs we have seen before ;-).

Hm, it didn't hang for me. But that assertion cut me off from my
ssh keys, which clearly is a degradation.
I'm running under workaround now,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214568

> > Can we get gnupg 2.1.16 "real soon now"?
> I did a gpgme release today and 2.1.16 will be the next thing.  Maybe
> tomorrow.  There is only that One Last Feature(tm) I want to get in.

I understand that notion :) But as gpg-agent is now part of my
ssh client setup (keys on smartcard rock!) it has become
"infrastructure" - that is, I'm more concerned about having
gpg and gpg-agent working at all; additional features are of
lower priority (even as there's always more cool stuff, of course).

Regards,
Christoph

-- 
Spare Space


From michael.haubenwallner at ssi-schaefer.com  Wed Nov 16 16:16:52 2016
From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner)
Date: Wed, 16 Nov 2016 16:16:52 +0100
Subject: [ping] [PATCH] Use EXEEXT and -no-undefined flag even on Unix.
In-Reply-To: <1463757560-20435-1-git-send-email-michael.haubenwallner@ssi-schaefer.com>
References: <1463757560-20435-1-git-send-email-michael.haubenwallner@ssi-schaefer.com>
Message-ID: <becb5caf-ecf4-75a7-3184-62a3f8987d97@ssi-schaefer.com>

Anyone a thought here?

Ohw, Cygwin actually requires _no_ undefined symbols for shared libraries.

Thanks!
/haubi/

On 05/20/2016 05:19 PM, Michael Haubenwallner wrote:
> * src/Makefile.am: Always use the -no-undefined libtool flag.
> Use EXEEXT with gen-posix-lock-obj in extra make target.
> 
> Cygwin is not identified as W32 system, but requires undefined symbols
> to create a shared library.  As the shared library should not have
> undefined symbols anywhere at all, we can use the -no-undefined libtool
> flag unconditionally.
> Although Cygwin tries to hide the .exe extension in general, automake
> uses EXEEXT with PROGRAMS targets, which we have to match here.
> ---
>  src/Makefile.am | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 5623aff..2cf9dfb 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -118,7 +118,6 @@ SUFFIXES = .rc .lo
>         $(LTRCCOMPILE) -i "$<" -o "$@"
> 
>  gpg_error_res = versioninfo.lo
> -no_undefined = -no-undefined
>  export_symbols = -export-symbols gpg-error.def
>  # i686-w64-mingw32.gcc version 4.9.1 takes the long long helper
>  # functions from libgcc_s_sjlj-1.dll and not from a static libgcc.  As
> @@ -147,7 +146,6 @@ else
>  #
>  arch_sources = posix-lock.c posix-lock-obj.h posix-thread.c
>  gpg_error_res =
> -no_undefined =
>  export_symbols =
>  extra_ltoptions =
> 
> @@ -168,7 +166,7 @@ else
>  endif
> 
>  libgpg_error_la_LDFLAGS = \
> -  $(no_undefined) $(export_symbols) $(libgpg_error_vers_opt) \
> +  -no-undefined $(export_symbols) $(libgpg_error_vers_opt) \
>    $(extra_ltoptions) -version-info \
>    @LIBGPG_ERROR_LT_CURRENT@:@LIBGPG_ERROR_LT_REVISION@:@LIBGPG_ERROR_LT_AGE@
> 
> @@ -288,8 +286,8 @@ else
>  pre_mkheader_cmds = :
>  parts_of_gpg_error_h += ./lock-obj-pub.native.h
> 
> -./lock-obj-pub.native.h: Makefile gen-posix-lock-obj posix-lock-obj.h
> -       ./gen-posix-lock-obj >$@
> +./lock-obj-pub.native.h: Makefile gen-posix-lock-obj$(EXEEXT) posix-lock-obj.h
> +       ./gen-posix-lock-obj$(EXEEXT) >$@
>  endif
> 
>  # We also depend on versioninfo.rc because that is build by
> --
> 2.7.3
> 


From rjh at sixdemonbag.org  Thu Nov 17 01:04:43 2016
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 16 Nov 2016 19:04:43 -0500
Subject: gpgme 1.8 build failure
Message-ID: <908b8300-797c-88d4-bc79-0213203f0980@sixdemonbag.org>

Build environment: macOS Sierra, XCode 8.1.

quorra:gpgme-1.8.0 rjh$ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in src
make[2]: Nothing to be done for `all'.
Making all in tests
Making all in gpg
make[3]: Nothing to be done for `all'.
Making all in gpgsm
make[3]: Nothing to be done for `all'.
Making all in opassuan
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all-am'.
Making all in doc
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
make[3]: Nothing to be done for `all-am'.
Making all in lang
Making all in cl
make[3]: Nothing to be done for `all'.
Making all in cpp
Making all in src
/bin/sh ../../../libtool  --tag=CXX   --mode=compile g++ -std=c++11
-DHAVE_CONFIG_H -I. -I../../..  -I../../../src -I/usr/local/include
-I/usr/local/include -DBUILDING_GPGMEPP   -g -O2 -MT
keygenerationresult.lo -MD -MP -MF .deps/keygenerationresult.Tpo -c -o
keygenerationresult.lo keygenerationresult.cpp
libtool: compile:  g++ -std=c++11 -DHAVE_CONFIG_H -I. -I../../..
-I../../../src -I/usr/local/include -I/usr/local/include
-DBUILDING_GPGMEPP -g -O2 -MT keygenerationresult.lo -MD -MP -MF
.deps/keygenerationresult.Tpo -c keygenerationresult.cpp  -fno-common
-DPIC -o .libs/keygenerationresult.o
keygenerationresult.cpp:43:23: error: use of undeclared identifier 'strdup'
            res.fpr = strdup(res.fpr);
                      ^
1 error generated.


From heirecka at exherbo.org  Wed Nov 16 23:09:45 2016
From: heirecka at exherbo.org (Heiko Becker)
Date: Wed, 16 Nov 2016 23:09:45 +0100
Subject: [PATCH GPGME] Remove a forgotten instance of @libsuffix@
Message-ID: <20161116220945.6761-1-heirecka@exherbo.org>

* lang/cpp/src/GpgmeppConfig.cmake.in.in: Remove a forgotten
instance of @libsuffix at .
--

b2c07bd47bd608afa5cc819b60a7b5bb8c9dd96a removed @libsuffix@ from
cmake config files, but missed one instance.

Signed-off-by: Heiko Becker <heirecka at exherbo.org>
---
 lang/cpp/src/GpgmeppConfig.cmake.in.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lang/cpp/src/GpgmeppConfig.cmake.in.in b/lang/cpp/src/GpgmeppConfig.cmake.in.in
index 928d19f..cbe9713 100644
--- a/lang/cpp/src/GpgmeppConfig.cmake.in.in
+++ b/lang/cpp/src/GpgmeppConfig.cmake.in.in
@@ -63,7 +63,7 @@ add_library(Gpgmepp SHARED IMPORTED)
 
 set_target_properties(Gpgmepp PROPERTIES
   INTERFACE_INCLUDE_DIRECTORIES "@resolved_includedir@/gpgme++;@resolved_includedir@"
-  INTERFACE_LINK_LIBRARIES "pthread;@resolved_libdir@/libgpgme at libsuffix@;@LIBASSUAN_LIBS@"
+  INTERFACE_LINK_LIBRARIES "pthread;@resolved_libdir@/libgpgme.so;@LIBASSUAN_LIBS@"
   IMPORTED_LOCATION "@resolved_libdir@/libgpgmepp.so"
 )
 
-- 
2.10.2



From gniibe at fsij.org  Thu Nov 17 06:36:37 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 17 Nov 2016 14:36:37 +0900
Subject: [ping] [PATCH] Use EXEEXT and -no-undefined flag even on Unix.
In-Reply-To: <becb5caf-ecf4-75a7-3184-62a3f8987d97@ssi-schaefer.com>
References: <1463757560-20435-1-git-send-email-michael.haubenwallner@ssi-schaefer.com>
 <becb5caf-ecf4-75a7-3184-62a3f8987d97@ssi-schaefer.com>
Message-ID: <fbd44336-02e1-c5cb-0a7a-37290294991f@fsij.org>

Hello,

Thank you for your notification.

On 11/17/2016 12:16 AM, Michael Haubenwallner wrote:
> Ohw, Cygwin actually requires _no_ undefined symbols for shared libraries.

I understand your points for Cygwin.  For EXEEXT thing, I applied a
part of your change, it's pushed to repo.

On 05/20/2016 05:19 PM, Michael Haubenwallner wrote:
> * src/Makefile.am: Always use the -no-undefined libtool flag.
> Use EXEEXT with gen-posix-lock-obj in extra make target.
>
> Cygwin is not identified as W32 system, but requires undefined symbols
> to create a shared library.  As the shared library should not have
> undefined symbols anywhere at all, we can use the -no-undefined libtool
> flag unconditionally.
> Although Cygwin tries to hide the .exe extension in general, automake
> uses EXEEXT with PROGRAMS targets, which we have to match here.

Your change effects not only Cygwin but also other POSIX systems,
because you remove the Make variable of no_undefined to force
-no-undefined flag.   It's good for Cygwin, but it's too radical
for other systems.

> @@ -288,8 +286,8 @@ else
>  pre_mkheader_cmds = :
>  parts_of_gpg_error_h += ./lock-obj-pub.native.h
>
> -./lock-obj-pub.native.h: Makefile gen-posix-lock-obj posix-lock-obj.h
> -       ./gen-posix-lock-obj >$@
> +./lock-obj-pub.native.h: Makefile gen-posix-lock-obj$(EXEEXT) posix-lock-obj.h
> +       ./gen-posix-lock-obj$(EXEEXT) >$@
>  endif

$(EXEEXT) is not needed to be invoked.

The change will be in 1.26.
-- 


From gniibe at fsij.org  Thu Nov 17 06:51:25 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 17 Nov 2016 14:51:25 +0900
Subject: [ping] [PATCH] Use EXEEXT and -no-undefined flag even on Unix.
In-Reply-To: <becb5caf-ecf4-75a7-3184-62a3f8987d97@ssi-schaefer.com>
References: <1463757560-20435-1-git-send-email-michael.haubenwallner@ssi-schaefer.com>
 <becb5caf-ecf4-75a7-3184-62a3f8987d97@ssi-schaefer.com>
Message-ID: <6e873720-fc50-4219-22fa-3b5d064890e1@fsij.org>

I've checked the packaging in Cygwin for libgpg-error.

I think that the workaround with the Make variable no_undefined makes
sense.  That is, build with:

	make no_undefined=-no-undefined
-- 


From aheinecke at intevation.de  Thu Nov 17 09:26:43 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Thu, 17 Nov 2016 09:26:43 +0100
Subject: [PATCH GPGME] Remove a forgotten instance of @libsuffix@
In-Reply-To: <20161116220945.6761-1-heirecka@exherbo.org>
References: <20161116220945.6761-1-heirecka@exherbo.org>
Message-ID: <5672118.pcGs4n3CAC@esus>

Thanks,

Applied this patch. Sorry for overlooking that.

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: 659 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161117/b12481ae/attachment.sig>

From aheinecke at intevation.de  Thu Nov 17 09:55:52 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Thu, 17 Nov 2016 09:55:52 +0100
Subject: gpgme 1.8 build failure
In-Reply-To: <908b8300-797c-88d4-bc79-0213203f0980@sixdemonbag.org>
References: <908b8300-797c-88d4-bc79-0213203f0980@sixdemonbag.org>
Message-ID: <7590557.nRbBky8x1B@esus>

Hi,

On Wednesday 16 November 2016 19:04:43 Robert J. Hansen wrote:
> Build environment: macOS Sierra, XCode 8.1.
> 
> quorra:gpgme-1.8.0 rjh$ make

...

> keygenerationresult.cpp:43:23: error: use of undeclared identifier 'strdup'
>             res.fpr = strdup(res.fpr);
>                       ^
> 1 error generated.

Sorry, I don't understand the problem. In line 35 keygenerationresult.cpp 
includes <string.h> so strdup should be available. Is string.h not the right 
header for strdup on macOS?


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: 659 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161117/f48f39c5/attachment.sig>

From michael.haubenwallner at ssi-schaefer.com  Thu Nov 17 10:08:05 2016
From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner)
Date: Thu, 17 Nov 2016 10:08:05 +0100
Subject: [ping] [PATCH] Use EXEEXT and -no-undefined flag even on Unix.
In-Reply-To: <fbd44336-02e1-c5cb-0a7a-37290294991f@fsij.org>
References: <1463757560-20435-1-git-send-email-michael.haubenwallner@ssi-schaefer.com>
 <becb5caf-ecf4-75a7-3184-62a3f8987d97@ssi-schaefer.com>
 <fbd44336-02e1-c5cb-0a7a-37290294991f@fsij.org>
Message-ID: <582D7375.1060409@ssi-schaefer.com>

Hi Yutaka,

On 11/17/2016 06:36 AM, NIIBE Yutaka wrote:
> Hello,
> 
> Thank you for your notification.
> 
> On 11/17/2016 12:16 AM, Michael Haubenwallner wrote:
>> Ohw, Cygwin actually requires _no_ undefined symbols for shared libraries.
> 
> I understand your points for Cygwin.  For EXEEXT thing, I applied a
> part of your change, it's pushed to repo.

Thanks a lot!

> On 05/20/2016 05:19 PM, Michael Haubenwallner wrote:
>> * src/Makefile.am: Always use the -no-undefined libtool flag.
>> Use EXEEXT with gen-posix-lock-obj in extra make target.
>>
>> Cygwin is not identified as W32 system, but requires undefined symbols
>> to create a shared library.  As the shared library should not have
>> undefined symbols anywhere at all, we can use the -no-undefined libtool
>> flag unconditionally.
>> Although Cygwin tries to hide the .exe extension in general, automake
>> uses EXEEXT with PROGRAMS targets, which we have to match here.
> 
> Your change effects not only Cygwin but also other POSIX systems,
> because you remove the Make variable of no_undefined to force
> -no-undefined flag.   It's good for Cygwin, but it's too radical
> for other systems.

While I'm fine with the no_undefined=-no-undefined workaround, would
you mind to elaborate why it's too radical for other systems?

>> @@ -288,8 +286,8 @@ else
>>  pre_mkheader_cmds = :
>>  parts_of_gpg_error_h += ./lock-obj-pub.native.h
>>
>> -./lock-obj-pub.native.h: Makefile gen-posix-lock-obj posix-lock-obj.h
>> -       ./gen-posix-lock-obj >$@
>> +./lock-obj-pub.native.h: Makefile gen-posix-lock-obj$(EXEEXT) posix-lock-obj.h
>> +       ./gen-posix-lock-obj$(EXEEXT) >$@
>>  endif
> 
> $(EXEEXT) is not needed to be invoked.

Indeed!

> The change will be in 1.26.

Thanks!
/haubi/


From wk at gnupg.org  Thu Nov 17 11:17:36 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 17 Nov 2016 11:17:36 +0100
Subject: gpgme 1.8 build failure
In-Reply-To: <908b8300-797c-88d4-bc79-0213203f0980@sixdemonbag.org> (Robert
 J. Hansen's message of "Wed, 16 Nov 2016 19:04:43 -0500")
References: <908b8300-797c-88d4-bc79-0213203f0980@sixdemonbag.org>
Message-ID: <87h976tnpb.fsf@wheatstone.g10code.de>

On Thu, 17 Nov 2016 01:04, rjh at sixdemonbag.org said:
> Build environment: macOS Sierra, XCode 8.1.

We are still using x86_64-apple-darwin15.5.0 with

./configure --prefix=/Users/jenkins/prefix/native
  --enable-maintainer-mode 'CFLAGS= -D_DARWIN_C_SOURCE=900000L -fPIC'
  'CXXFLAGS= -D_DARWIN_C_SOURCE=900000L -fPIC -std=c++11'

and we see no problems.  

We plan to update to Sierra as time permits.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161117/37780996/attachment.sig>

From wk at gnupg.org  Thu Nov 17 15:38:36 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 17 Nov 2016 15:38:36 +0100
Subject: [PATCH 1/3] dirmngr: register hkp-cacert even if the file doesn't
 exist yet
In-Reply-To: <20161027223059.31844-1-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Thu, 27 Oct 2016 18:30:57 -0400")
References: <20161027223059.31844-1-dkg@fifthhorseman.net>
Message-ID: <87vavmrx1v.fsf@wheatstone.g10code.de>

On Fri, 28 Oct 2016 00:30, dkg at fifthhorseman.net said:
> * dirmngr/dirmngr.c (parse_readable_options): if we're unable to turn
>   an argument for hkp-cacert into an absolute filename, terminate
>   completely.
> * dirmngr/http.c (http_register_tls_ca): show a warning if file is not
>   immediately accessible, but register it anyway.

I just pushed all three patches.  Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161117/8646cad3/attachment.sig>

From gniibe at fsij.org  Fri Nov 18 00:20:14 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 18 Nov 2016 08:20:14 +0900
Subject: [ping] [PATCH] Use EXEEXT and -no-undefined flag even on Unix.
In-Reply-To: <582D7375.1060409@ssi-schaefer.com>
References: <1463757560-20435-1-git-send-email-michael.haubenwallner@ssi-schaefer.com>
 <becb5caf-ecf4-75a7-3184-62a3f8987d97@ssi-schaefer.com>
 <fbd44336-02e1-c5cb-0a7a-37290294991f@fsij.org>
 <582D7375.1060409@ssi-schaefer.com>
Message-ID: <f8bd6a64-de18-dad6-fe18-241bebd5c499@fsij.org>

On 11/17/2016 06:08 PM, Michael Haubenwallner wrote:
>> Your change effects not only Cygwin but also other POSIX systems,
>> because you remove the Make variable of no_undefined to force
>> -no-undefined flag.   It's good for Cygwin, but it's too radical
>> for other systems.
> 
> While I'm fine with the no_undefined=-no-undefined workaround, would
> you mind to elaborate why it's too radical for other systems?

Your change has an impact to other systems.  When you don't know how
large the impact is, please be conservative and be more careful.

Please note that libgpg-error uses libtool for its build.  And libtool
has the option "-no-undefined" because there are some systems where
undefined symbols are valid or even needed.

For example, (at least) I know the user space implementation of shared
library for a.out format where it's inevitable to have undefined
symbols.

Please note that shared library feature is not standardized for POSIX
systems.  I think that we have libtool for this exact reason.  For
detail, please see:

    https://www.gnu.org/software/libtool/manual/html_node/index.html

For modern systems of ELF, System V Application Binary Interface
defines the shared object format and its semantics.  (17 years ago, I
made one for SuperH architecture together with my friend,
independently to its vendor.  Around that time, some people insisted
that static linking is only good for embedded systems.)

Well, I agree with you that your claim (no undefined symbols) are
valid for most of modern systems.  On the other hand, I would like to
support other systems as well.
-- 


From gniibe at fsij.org  Fri Nov 18 02:48:56 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 18 Nov 2016 10:48:56 +0900
Subject: [LIBGPG-ERROR PATCH 6/6] w32-iconv: Remove invalid link to
 unicode.org in comment.
In-Reply-To: <20161115235246.24860-6-dkg@fifthhorseman.net>
References: <20161115235246.24860-1-dkg@fifthhorseman.net>
 <20161115235246.24860-6-dkg@fifthhorseman.net>
Message-ID: <46d4987c-b9a6-0949-89f5-950456946e10@fsij.org>

Thanks.

All of six patches applied as documentation changes.  Pushed.
-- 


From michael.haubenwallner at ssi-schaefer.com  Fri Nov 18 11:01:44 2016
From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner)
Date: Fri, 18 Nov 2016 11:01:44 +0100
Subject: [ping] [PATCH] Use EXEEXT and -no-undefined flag even on Unix.
In-Reply-To: <f8bd6a64-de18-dad6-fe18-241bebd5c499@fsij.org>
References: <1463757560-20435-1-git-send-email-michael.haubenwallner@ssi-schaefer.com>
 <becb5caf-ecf4-75a7-3184-62a3f8987d97@ssi-schaefer.com>
 <fbd44336-02e1-c5cb-0a7a-37290294991f@fsij.org>
 <582D7375.1060409@ssi-schaefer.com>
 <f8bd6a64-de18-dad6-fe18-241bebd5c499@fsij.org>
Message-ID: <7a903cf5-32fe-dfb8-9ded-53f31db55977@ssi-schaefer.com>


On 11/18/2016 12:20 AM, NIIBE Yutaka wrote:
> On 11/17/2016 06:08 PM, Michael Haubenwallner wrote:
>>> Your change effects not only Cygwin but also other POSIX systems,
>>> because you remove the Make variable of no_undefined to force
>>> -no-undefined flag.   It's good for Cygwin, but it's too radical
>>> for other systems.
>>
>> While I'm fine with the no_undefined=-no-undefined workaround, would
>> you mind to elaborate why it's too radical for other systems?
> 
> Your change has an impact to other systems.  When you don't know how
> large the impact is, please be conservative and be more careful.

Agreed - except for that I believe to know about the impact. :)

> Please note that libgpg-error uses libtool for its build.  And libtool
> has the option "-no-undefined" because there are some systems where
> undefined symbols are valid or even needed.
> 
> For example, (at least) I know the user space implementation of shared
> library for a.out format where it's inevitable to have undefined
> symbols.
> 
> Please note that shared library feature is not standardized for POSIX
> systems.  I think that we have libtool for this exact reason.

Exactly. But doesn't this also mean that the libtool user should not
need to take care about the underlying library architecture any more?

> For detail, please see:
> 
>     https://www.gnu.org/software/libtool/manual/html_node/index.html

So the "-no-undefined" flag "allows libtool to assume that undefined
symbols will not happen", rather than "must not happen".

> For modern systems of ELF, System V Application Binary Interface
> defines the shared object format and its semantics.  (17 years ago, I
> made one for SuperH architecture together with my friend,
> independently to its vendor.  Around that time, some people insisted
> that static linking is only good for embedded systems.)
> 
> Well, I agree with you that your claim (no undefined symbols) are
> valid for most of modern systems.  On the other hand, I would like to
> support other systems as well.

So if the "-no-undefined" flag breaks somewhere, and there really is no
undefined symbol within the library itself and the linked libraries,
then I would take this as libtool bug.

Another upside: Having linkers (that are able to) report undefined
symbols may unhide obscure bugs in the library.

Anyway, thanks for sharing your thoughts!
/haubi/


From wk at gnupg.org  Fri Nov 18 22:19:54 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 18 Nov 2016 22:19:54 +0100
Subject: [Announce] GnuPG 2.1.16 released
Message-ID: <87twb4pjt1.fsf@wheatstone.g10code.de>

Hello!

The GnuPG team is pleased to announce the availability of a new release
of GnuPG modern: Version 2.1.16.  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.16
====================================

 * gpg: New algorithm for selecting the best ranked public key when
   using a mail address with -r, -R, or --locate-key.

 * gpg: New option --with-tofu-info to print a new "tfs" record in
   colon formatted key listings.

 * gpg: New option --compliance as an alternative way to specify
   options like --rfc2440, --rfc4880, et al.

 * gpg: Many changes to the TOFU implementation.

 * gpg: Improve usability of --quick-gen-key.

 * gpg: In --verbose mode print a diagnostic when a pinentry is
   launched.

 * gpg: Remove code which warns for old versions of gnome-keyring.

 * gpg: New option --override-session-key-fd.

 * gpg: Option --output does now work with --verify.

 * gpgv: New option --output to allow saving the verified data.

 * gpgv: New option --enable-special-filenames.

 * agent, dirmngr: New --supervised mode for use by systemd and alike.

 * agent: By default listen on all available sockets using standard
   names.

 * agent: Invoke scdaemon with --homedir.

 * dirmngr: On Linux now detects the removal of its own socket and
   terminates.

 * scd: Support ECC key generation.

 * scd: Support more card readers.

 * dirmngr: New option --allow-version-check to download a software
   version database in the background.

 * dirmngr: Use system provided CAs if no --hkp-cacert is given.

 * dirmngr: Use a default keyserver if none is explicitly set

 * gpgconf: New command --query-swdb to check software versions
   against an copy of an online database.

 * gpgconf: Print the socket directory with --list-dirs.

 * tools: The WKS tools now support draft version -02.

 * tools: Always build gpg-wks-client and install under libexec.

 * tools: New option --supported for gpg-wks-client.

 * The log-file option now accepts a value "socket://" to log to the
   socket named "S.log" in the standard socket directory.

 * Provide fake pinentries for use by tests cases of downstream
   developers.

 * Fixed many bugs and regressions.

 * Many changes and improvements for the test suite.

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.16 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.16.tar.bz2  (5704k)
 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.16.tar.bz2.sig
or here:
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.16.tar.bz2
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.16.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.16_20161118.exe  (3684k)
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.16_20161118.exe.sig
or here
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.16_20161118.exe
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.16_20161118.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 and Web Key Directory support, though.


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.16.tar.bz2 you would use this command:

     gpg --verify gnupg-2.1.16.tar.bz2.sig gnupg-2.1.16.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.16.tar.bz2, you run the command like this:

     sha1sum gnupg-2.1.16.tar.bz2

   and check that the output matches the next line:

67540161c9fe289153c4a5ea60f7cdce0ef48897  gnupg-2.1.16.tar.bz2
50b0bd286faa90e5c71417b5f2f36cf5de964084  gnupg-w32-2.1.16_20161118.exe
dd7d33a941c47574830df2e35503cd8ba0788eda  gnupg-w32-2.1.16_20161118.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.  Due to expected changes in the next release some
strings pertaining to the TOFU code are not translated in this version.


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, GPGME, and GPA.  Please consider to donate via:

                  https://gnupg.org/donate/


Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, 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: 2020-10-30]
  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.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161118/09f89207/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From dkg at fifthhorseman.net  Sat Nov 19 01:14:57 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 18 Nov 2016 19:14:57 -0500
Subject: packaged gpg 2.1.x can't retrieve any keys from keyservers.. is
 there any upstream fix or progress?
In-Reply-To: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
References: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
Message-ID: <878tsgfhq6.fsf@alice.fifthhorseman.net>

On Fri 2016-11-11 09:45:13 -0500, lists at ssl-mail.com wrote:
> I've lost track of where the end of any thread on this is :-/

thanks for starting a new thread.  for your reference, the old thread
began at Message-ID:
1476027783.1522252.750391089.07374952 at webmail.messagingengine.com

> At the moment, none of our package-installed GPG 2.1.x are able to retrieve keys.

I don't know what you mean "package-installed", and i don't know what
version of 2.1.x you're talking about (though you mention 2.1.15 below).
can you be more specific?

> What's the status on the bug
>
> gpg 2.1.15, *no* keyservers found for submit/recv, "DNS query returned an error or no records: No such domain (nxdomain)"  
> https://bugs.gnupg.org/gnupg/issue2745
>
> I've tried to provide every bit of requested info so far.  If there's more needed let me know exactly what.

that bug report suggests that after your SRV lookups fail, dirmngr
doesn't bother to continue with the A and AAAA lookups.  This isn't what
happens on systems that i use.

Perhaps you could try increasing the logging for dirmngr ("log-level
guru" and "log-file /path/to/wherever/dirmngr.log" in
~/.gnupg/dirmngr.conf) and review the output?  If that doesn't give you
more pointers, could you attatch to dirmngr (with debug symbols
installed) and see what it's doing inside dirmngr/http.c,
dirmngr/ks-engine-hkp.c, and dirmngr/dns-stuff.c, where the actual SRV
lookups (and A and AAAA lookups) are generated.

        --dkg


From dkg at fifthhorseman.net  Fri Nov 18 06:47:55 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 18 Nov 2016 14:47:55 +0900
Subject: CRL checking in dirmngr (Was: Re: [PATCH 2/3] dirmngr: add system
 CAs if no hkp-cacert is given)
In-Reply-To: <7f0c2984-9587-8382-ab61-543771f11cb8@sumptuouscapital.com>
References: <20161027223059.31844-1-dkg@fifthhorseman.net>
 <20161027223059.31844-2-dkg@fifthhorseman.net>
 <b636f245-c43b-2b48-c16d-48b4635fad59@sumptuouscapital.com>
 <878tt4a8vc.fsf@alice.fifthhorseman.net>
 <7f0c2984-9587-8382-ab61-543771f11cb8@sumptuouscapital.com>
Message-ID: <87twb549v8.fsf@alice.fifthhorseman.net>

On Sat 2016-11-05 07:52:07 +0900, Kristian Fiskerstrand wrote:
> Since dirmngr already has CRL checking capabilities, at least OneCRL
> checking is likely a good idea to implement. I'd also be nice if CRL is
> checked for specific CA, e.g in the case of
> https://sks-keyservers.net/ca/crl.pem for hkps.pool.sks-keyservers.net

Kristian, do you have a patch for this?  Now that the sks-keyservers
pool CA is being shipped and used automatically, this seems like an
important step.

how frequently do you think it should be checked?  What if there were a
policy to refresh it infrequently?  without creating something that
"phones home", we could have a simple policy like:

 * if use-tor is enabled, and
 * if the list of configured keyservers includes
   hkps.pool.sks-keyservers.net, and
 * the CRL "Next at" update check is expired

then refresh it?

     --dkg


From lists at ssl-mail.com  Sat Nov 19 05:11:52 2016
From: lists at ssl-mail.com (lists at ssl-mail.com)
Date: Fri, 18 Nov 2016 20:11:52 -0800
Subject: packaged gpg 2.1.x can't retrieve any keys from keyservers.. is
 there any upstream fix or progress?
In-Reply-To: <878tsgfhq6.fsf@alice.fifthhorseman.net>
References: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
 <878tsgfhq6.fsf@alice.fifthhorseman.net>
Message-ID: <1479528712.4167275.792800985.20E5A953@webmail.messagingengine.com>


> I don't know what you mean "package-installed", 

Installed from distribution's packaging, as opposed to my owne from-src builds

> and i don't know what
> version of 2.1.x you're talking about (though you mention 2.1.15 below).
> can you be more specific?

rpm -qa | grep -i gpg2 | grep -v pubkey
  gpg2-2.1.15-197.4.x86_64
  gpg2-lang-2.1.15-197.4.noarch

which gpg
  /usr/bin/gpg

ls -al /usr/bin/gpg
  lrwxrwxrwx 1 root root 4 Nov 15 11:29 /usr/bin/gpg -> gpg2*

gpg2 --version
  gpg (GnuPG) 2.1.15
  libgcrypt 1.7.3
  Copyright (C) 2016 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  
  Home: /root/.gnupg
  Supported algorithms:
  Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
  Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
          CAMELLIA128, CAMELLIA192, CAMELLIA256
  Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
  Compression: Uncompressed, ZIP, ZLIB, BZIP2

> Perhaps you could try increasing the logging for dirmngr ("log-level
> guru" and "log-file /path/to/wherever/dirmngr.log" in
> ~/.gnupg/dirmngr.conf) and review the output? 

cat ~/.gnupg/dirmngr.conf
	verbose
	debug 1024
	debug-level guru
	log-file   /var/log/gnupg/dirmngr.log

	keyserver hkps://hkps.pool.sks-keyservers.net:443
	hkp-cacert /usr/share/gnupg/sks-keyservers.netCA.pem

	nameserver 10.1.1.100


gpg -v --debug-all --recv-keys 0x673A03E4C1DB921F
	gpg: reading options from '/root/.gnupg/gpg.conf'
	gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing cardio ipc clock lookup extprog
	gpg: DBG: [not enabled in the source] start
	gpg: DBG: chan_3 <- # Home: /root/.gnupg
	gpg: DBG: chan_3 <- # Config: /root/.gnupg/dirmngr.conf
	gpg: DBG: chan_3 <- OK Dirmngr 2.1.15 at your service
	gpg: DBG: connection to the dirmngr established
	gpg: DBG: chan_3 -> GETINFO version
	gpg: DBG: chan_3 <- D 2.1.15
	gpg: DBG: chan_3 <- OK
	gpg: DBG: chan_3 -> KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net:443
	gpg: DBG: chan_3 <- OK
	gpg: DBG: chan_3 -> KS_GET -- 0x673A03E4C1DB921F
	gpg: DBG: chan_3 <- ERR 167772346 No keyserver available <Dirmngr>
	gpg: keyserver receive failed: No keyserver available
	gpg: DBG: chan_3 -> BYE
	gpg: DBG: [not enabled in the source] stop
	gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
	              outmix=0 getlvl1=0/0 getlvl2=0/0
	gpg: secmem usage: 0/65536 bytes in 0 blocks

tail -f /var/log/gnupg/dirmngr.log


	2016-11-18 20:05:21 dirmngr[20059.0] handler for fd 0 started
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 -> # Home: /root/.gnupg
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 -> # Config: /root/.gnupg/dirmngr.conf
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 -> OK Dirmngr 2.1.15 at your service
	2016-11-18 20:05:21 dirmngr[20059.0] connection from process 20330 (0:0)
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 <- GETINFO version
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 -> D 2.1.15
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 -> OK
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 <- KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net:443
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 -> OK
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 <- KS_GET -- 0x673A03E4C1DB921F
	2016-11-18 20:05:21 dirmngr[20059.0] host 'hkps.pool.sks-keyservers.net' marked as dead
	2016-11-18 20:05:21 dirmngr[20059.0] command 'KS_GET' failed: No keyserver available
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 -> ERR 167772346 No keyserver available <Dirmngr>
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 <- BYE
	2016-11-18 20:05:21 dirmngr[20059.0] DBG: chan_0 -> OK closing connection
	2016-11-18 20:05:21 dirmngr[20059.0] handler for fd 0 terminated



> If that doesn't give you more pointers

I honestly don't know.  Does it?

> could you attatch to dirmngr (with debug symbols
> installed) and see what it's doing inside dirmngr/http.c,
> dirmngr/ks-engine-hkp.c, and dirmngr/dns-stuff.c, where the actual SRV
> lookups (and A and AAAA lookups) are generated.

Will need some more specific guidance here ...


From kristian.fiskerstrand at sumptuouscapital.com  Sat Nov 19 16:42:12 2016
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sat, 19 Nov 2016 16:42:12 +0100
Subject: CRL checking in dirmngr (Was: Re: [PATCH 2/3] dirmngr: add system
 CAs if no hkp-cacert is given)
In-Reply-To: <87twb549v8.fsf@alice.fifthhorseman.net>
References: <20161027223059.31844-1-dkg@fifthhorseman.net>
 <20161027223059.31844-2-dkg@fifthhorseman.net>
 <b636f245-c43b-2b48-c16d-48b4635fad59@sumptuouscapital.com>
 <878tt4a8vc.fsf@alice.fifthhorseman.net>
 <7f0c2984-9587-8382-ab61-543771f11cb8@sumptuouscapital.com>
 <87twb549v8.fsf@alice.fifthhorseman.net>
Message-ID: <9d93812b-cacf-ed8e-19de-c50ec5129ecb@sumptuouscapital.com>

On 11/18/2016 06:47 AM, Daniel Kahn Gillmor wrote:
> On Sat 2016-11-05 07:52:07 +0900, Kristian Fiskerstrand wrote:
>> Since dirmngr already has CRL checking capabilities, at least OneCRL
>> checking is likely a good idea to implement. I'd also be nice if CRL is
>> checked for specific CA, e.g in the case of
>> https://sks-keyservers.net/ca/crl.pem for hkps.pool.sks-keyservers.net
> 
> Kristian, do you have a patch for this?  Now that the sks-keyservers

No, I haven't done anything wrt this

> pool CA is being shipped and used automatically, this seems like an
> important step.

I'm not entirely sure if it is correct to do it in downstream app to
begin with, but maybe in the TLS provider (in this case mostlly gnutls),
it should be the library's responsibility to provide expected security
level. If the system root store is expected to be used it needs to have
additional checks these days, and a fix would affect more apps.

> 
> how frequently do you think it should be checked?  What if there were a
> policy to refresh it infrequently?  without creating something that
> "phones home", we could have a simple policy like:

Can likely use the CRL expiration as a baseline, if a test was actually
implemented I'd change this to a shorter duration, probably 1 month or
so. Checking more than once a week is likely not necessary, so somewhere
between 1w and 1m would be my suggestion, but ymmw.
> 
>  * if use-tor is enabled, and
>  * if the list of configured keyservers includes
>    hkps.pool.sks-keyservers.net, and
>  * the CRL "Next at" update check is expired
> 
> then refresh it?

Sounds reasonable for this particular case (and this would fit in
downstream app as it is special use case, so it is reasonable to work on
it).

I'm actually more curious about [OneCRL] not being checked for the rest
of the root store/system CAs at this point.


References:
[OneCRL] json variant available at
https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"A ship is safe in harbour, but that's not what ships are for"
(Will Shedd)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20161119/d220df3a/attachment-0001.sig>

From lists at ssl-mail.com  Sun Nov 20 13:55:57 2016
From: lists at ssl-mail.com (lists at ssl-mail.com)
Date: Sun, 20 Nov 2016 04:55:57 -0800
Subject: packaged gpg 2.1.x can't retrieve any keys from keyservers.. is
 there any upstream fix or progress?
In-Reply-To: <1479528712.4167275.792800985.20E5A953@webmail.messagingengine.com>
References: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
 <878tsgfhq6.fsf@alice.fifthhorseman.net>
 <1479528712.4167275.792800985.20E5A953@webmail.messagingengine.com>
Message-ID: <1479646557.2155810.793629113.7C0AC3AC@webmail.messagingengine.com>

just fyi

On Fri, Nov 18, 2016, at 08:11 PM, lists at ssl-mail.com wrote:
> > and i don't know what
> > version of 2.1.x you're talking about (though you mention 2.1.15 below).
> > can you be more specific?

upgraded to

gpg2 --version
gpg (GnuPG) 2.1.16
libgcrypt 1.7.3
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /root/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

and the problem persists as reported


From lists at ssl-mail.com  Sun Nov 20 14:50:10 2016
From: lists at ssl-mail.com (lists at ssl-mail.com)
Date: Sun, 20 Nov 2016 05:50:10 -0800
Subject: packaged gpg 2.1.x can't retrieve any keys from keyservers.. is
 there any upstream fix or progress?
In-Reply-To: <1479646557.2155810.793629113.7C0AC3AC@webmail.messagingengine.com>
References: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
 <878tsgfhq6.fsf@alice.fifthhorseman.net>
 <1479528712.4167275.792800985.20E5A953@webmail.messagingengine.com>
 <1479646557.2155810.793629113.7C0AC3AC@webmail.messagingengine.com>
Message-ID: <1479649810.2163132.793655281.228031F8@webmail.messagingengine.com>

Here's the output of

	tail -f ~/dirmngr.strace

for dirmgr attached as

	strace -o ~/dirmngr.strace -f -tt -T -p 27452

on exec of

	gpg -v --debug-all --recv-keys 0x673A03E4C1DB921F

output:

	tail -f ~/dirmngr.strace
		27453 05:40:53.949749 clock_gettime(CLOCK_REALTIME, {1479649253, 949794906}) = 0 <0.000038>
		27453 05:40:53.949881 clock_gettime(CLOCK_REALTIME, {1479649253, 949904138}) = 0 <0.000043>
		27453 05:40:53.949965 pselect6(1, [], NULL, NULL, {2, 109232}, {NULL, 8}) = 0 (Timeout) <2.002186>
		27453 05:40:55.952224 clock_gettime(CLOCK_REALTIME, {1479649255, 952257773}) = 0 <0.000036>
		27453 05:40:55.952308 clock_gettime(CLOCK_REALTIME, {1479649255, 952321189}) = 0 <0.000029>
		27453 05:40:55.952404 pselect6(1, [], NULL, NULL, {2, 63416}, {NULL, 8} <unfinished ...>
		27452 05:40:56.784768 <... pselect6 resumed> ) = 1 (in [5], left {44, 797015830}) <15.203071>
		27452 05:40:56.784825 accept(5, {sa_family=AF_UNIX}, [110->2]) = 7 <0.000022>
		27452 05:40:56.784901 clone( <unfinished ...>
		29104 05:40:56.784989 set_robust_list(0x7fceb30289e0, 24 <unfinished ...>
		27452 05:40:56.785020 <... clone resumed> child_stack=0x7fceb3027ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fceb30289d0, tls=0x7fceb3028700, child_tidptr=0x7fceb30289d0) = 29104 <0.000110>
		29104 05:40:56.785038 <... set_robust_list resumed> ) = 0 <0.000022>
		29104 05:40:56.785061 futex(0x7fceb67ad220, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
		27452 05:40:56.785075 open("/proc/self/task/29104/comm", O_RDWR) = 8 <0.000033>
		27452 05:40:56.785150 write(8, "conn fd=7", 9) = 9 <0.000015>
		27452 05:40:56.785199 close(8)          = 0 <0.000024>
		27452 05:40:56.785278 clock_gettime(CLOCK_REALTIME, {1479649256, 785304438}) = 0 <0.000020>
		27452 05:40:56.785355 futex(0x7fceb67ad220, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
		29104 05:40:56.785401 <... futex resumed> ) = 0 <0.000328>
		27452 05:40:56.785419 <... futex resumed> ) = 1 <0.000038>
		27452 05:40:56.785436 pselect6(7, [5 6], NULL, NULL, {44, 796342555}, {[], 8} <unfinished ...>
		29104 05:40:56.785460 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 53) = 53 <0.000027>
		29104 05:40:56.785518 write(4, " started\n", 9) = 9 <0.000015>
		29104 05:40:56.785575 getsockopt(7, SOL_SOCKET, SO_PEERCRED, {pid=29103, uid=0, gid=0}, [12]) = 0 <0.000014>
		29104 05:40:56.785646 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000023>
		29104 05:40:56.785707 write(4, "chan_7 -> # Home: /root/.gnupg\n", 31) = 31 <0.000021>
		29104 05:40:56.785779 write(7, "# ", 2) = 2 <0.000023>
		29104 05:40:56.785844 write(7, "Home: /root/.gnupg", 18) = 18 <0.000025>
		29104 05:40:56.785898 write(7, "\n", 1) = 1 <0.000053>
		29104 05:40:56.786000 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000026>
		29104 05:40:56.786073 write(4, "chan_7 -> # Config: /root/.gnupg"..., 46) = 46 <0.000026>
		29104 05:40:56.786146 write(7, "# ", 2) = 2 <0.000028>
		29104 05:40:56.786202 write(7, "Config: /root/.gnupg/dirmngr.con"..., 33) = 33 <0.000029>
		29104 05:40:56.786270 write(7, "\n", 1) = 1 <0.000042>
		29104 05:40:56.786365 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000019>
		29104 05:40:56.786430 write(4, "chan_7 -> OK Dirmngr 2.1.16 at y"..., 44) = 44 <0.000031>
		29104 05:40:56.786500 write(7, "OK ", 3) = 3 <0.000025>
		29104 05:40:56.786557 write(7, "Dirmngr 2.1.16 at your service", 30) = 30 <0.000023>
		29104 05:40:56.786611 write(7, "\n", 1) = 1 <0.000024>
		29104 05:40:56.786690 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 71) = 71 <0.000022>
		29104 05:40:56.786742 write(4, ")\n", 2) = 2 <0.000016>
		29104 05:40:56.786785 read(7, "GETINFO version\n", 1002) = 16 <0.000020>
		29104 05:40:56.786851 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000023>
		29104 05:40:56.786914 write(4, "chan_7 <- GETINFO version\n", 26) = 26 <0.000020>
		29104 05:40:56.786980 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000023>
		29104 05:40:56.787045 write(4, "chan_7 -> D 2.1.16\n", 19) = 19 <0.000020>
		29104 05:40:56.787095 write(7, "D 2.1.16\n", 9) = 9 <0.000031>
		29104 05:40:56.787163 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000024>
		29104 05:40:56.787224 write(4, "chan_7 -> OK\n", 13) = 13 <0.000023>
		29104 05:40:56.787280 write(7, "OK", 2) = 2 <0.000026>
		29104 05:40:56.787344 write(7, "\n", 1) = 1 <0.000035>
		29104 05:40:56.787412 read(7, "KEYSERVER --clear hkps://hkps.po"..., 1002) = 58 <0.000016>
		29104 05:40:56.787463 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000017>
		29104 05:40:56.787507 write(4, "chan_7 <- KEYSERVER --clear hkps"..., 68) = 68 <0.000026>
		29104 05:40:56.787586 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000104>
		29104 05:40:56.787719 write(4, "chan_7 -> OK\n", 13) = 13 <0.000121>
		29104 05:40:56.787872 write(7, "OK", 2) = 2 <0.000034>
		29104 05:40:56.787946 write(7, "\n", 1) = 1 <0.000056>
		29104 05:40:56.788042 read(7, "KS_GET -- 0x673A03E4C1DB921F\n", 1002) = 29 <0.000020>
		29104 05:40:56.788101 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000021>
		29104 05:40:56.788155 write(4, "chan_7 <- KS_GET -- 0x673A03E4C1"..., 39) = 39 <0.000021>
		29104 05:40:56.788225 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 71) = 71 <0.000024>
		29104 05:40:56.788299 write(4, "' marked as dead\n", 17) = 17 <0.000021>
		29104 05:40:56.788365 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 84) = 84 <0.000019>
		29104 05:40:56.788418 write(4, "\n", 1) = 1 <0.000021>
		29104 05:40:56.788487 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000026>
		29104 05:40:56.788554 write(4, "chan_7 -> ERR 167772346 No keyse"..., 57) = 57 <0.000023>
		29104 05:40:56.788615 write(7, "ERR 167772346 No keyserver avail"..., 46) = 46 <0.000025>
		29104 05:40:56.788674 write(7, "\n", 1) = 1 <0.000024>
		29104 05:40:56.788725 read(7, "BYE\n", 1002) = 4 <0.000017>
		29104 05:40:56.788775 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000020>
		29104 05:40:56.788820 write(4, "chan_7 <- BYE\n", 14) = 14 <0.000018>
		29104 05:40:56.788871 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 42) = 42 <0.000023>
		29104 05:40:56.788920 write(4, "chan_7 -> OK closing connection\n", 32) = 32 <0.000017>
		29104 05:40:56.788962 write(7, "OK closing connection", 21) = -1 EPIPE (Broken pipe) <0.000018>
		29104 05:40:56.789009 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=27452, si_uid=0} ---
		29104 05:40:56.789031 close(7)          = 0 <0.000026>
		29104 05:40:56.789094 wait4(29103, NULL, 0, NULL) = -1 ECHILD (No child processes) <0.000016>
		29104 05:40:56.789166 write(4, "2016-11-20 05:40:56 dirmngr[2745"..., 53) = 53 <0.000019>
		29104 05:40:56.789220 write(4, " terminated\n", 12) = 12 <0.000018>
		29104 05:40:56.789270 madvise(0x7fceb2828000, 8368128, MADV_DONTNEED) = 0 <0.000021>
		29104 05:40:56.789323 exit(0)           = ?
		29104 05:40:56.789362 +++ exited with 0 +++
		27453 05:40:57.954561 <... pselect6 resumed> ) = 0 (Timeout) <2.002131>
		27453 05:40:57.954621 clock_gettime(CLOCK_REALTIME, {1479649257, 954640462}) = 0 <0.000025>
		27453 05:40:57.954709 clock_gettime(CLOCK_REALTIME, {1479649257, 954748297}) = 0 <0.000019>
		27453 05:40:57.954801 pselect6(1, [], NULL, NULL, {2, 107835}, {NULL, 8}) = 0 (Timeout) <2.002315>
		27453 05:40:59.957234 clock_gettime(CLOCK_REALTIME, {1479649259, 957268714}) = 0 <0.000037>
		27453 05:40:59.957316 clock_gettime(CLOCK_REALTIME, {1479649259, 957328219}) = 0 <0.000025>
		27453 05:40:59.957403 pselect6(1, [], NULL, NULL, {2, 59505}, {NULL, 8}


From gniibe at fsij.org  Mon Nov 21 03:17:34 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 21 Nov 2016 11:17:34 +0900
Subject: [PATCH v3 3/5] gpg-agent: Implement --supervised command (for
 systemd, etc).
In-Reply-To: <87ponfi7nv.fsf@wheatstone.g10code.de>
References: <87vaz7rq1k.fsf@alice.fifthhorseman.net>
 <1470980281-2675-1-git-send-email-dkg@fifthhorseman.net>
 <1470980281-2675-4-git-send-email-dkg@fifthhorseman.net>
 <87oa30jfz9.fsf@wheatstone.g10code.de>
 <87vax7760i.fsf@alice.fifthhorseman.net>
 <87ponfi7nv.fsf@wheatstone.g10code.de>
Message-ID: <91d2943f-67a0-f94e-4cb7-4e744d77411f@fsij.org>

On 10/05/2016 04:20 PM, Werner Koch wrote:
> On Wed,  5 Oct 2016 06:51, dkg at fifthhorseman.net said:
> 
>> I've tested this and there are a few problems still aside from the
>> patch i've sent to the list.
> 
> My fault.  I had to rebase my commits before pushing.  This required
> some manual edits and although I recall that I added initialize_modules
> to the supervised mode, that somehow got lost.

Sorry, I should have be more careful after the rebased commit and the
fix.

My commit eda17649f8bd3b8ce7bfc00a3c11cbcae63c845d did this once
(moving initialization).  Then, the rebased commit
9f92b62a51d2d60f038fdbe01602865c5933fa95 inserted it for parent.

The fix f57dc2b1e6f28d164f882373535dbcb0d632ca17 added
initialized_modules for --supervised.

Here is a patch to remove initialized_modules for --daemon.

diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c
index 1433f7f..175866d 100644
--- a/agent/gpg-agent.c
+++ b/agent/gpg-agent.c
@@ -1473,8 +1473,6 @@ main (int argc, char **argv )
       pid_t pid;
 #endif

-      initialize_modules ();
-
       /* Remove the DISPLAY variable so that a pinentry does not
          default to a specific display.  There is still a default
          display when gpg-agent was started using --display or a
-- 

-------------- 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/20161121/f83b40c8/attachment.sig>

From dkg at fifthhorseman.net  Mon Nov 21 03:35:13 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 20 Nov 2016 21:35:13 -0500
Subject: [PATCH] doc: Clarify dirmngr --homedir option.
Message-ID: <20161121023513.30139-1-dkg@fifthhorseman.net>

* doc/dirmngr.texi: Fix minor spelling and grammar issues in
documentation of --homedir option for dirmngr.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 doc/dirmngr.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi
index be4e97a..963dff8 100644
--- a/doc/dirmngr.texi
+++ b/doc/dirmngr.texi
@@ -142,10 +142,10 @@ per-user configuration file.  The default configuration file is named
 @item --homedir @var{dir}
 @opindex options
 Set the name of the home directory to @var{dir}.  This option is only
-effective when used on the command line.  The default os
+effective when used on the command line.  The default is
 the directory named @file{.gnupg} directly below the home directory
 of the user unless the environment variable @code{GNUPGHOME} has been set
-in which case its value will be used.  All kind of data is stored below
+in which case its value will be used.  Many kinds of data are stored within
 this directory.
 
 
-- 
2.10.2



From dkg at fifthhorseman.net  Mon Nov 21 07:06:19 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 21 Nov 2016 01:06:19 -0500
Subject: [PATCH] doc: Ship example gpg-agent-browser.socket in
 examples/systemd-user/.
Message-ID: <20161121060619.5890-1-dkg@fifthhorseman.net>

* doc/Makefile.am: Ship gpg-agent-browser.socket alongside the other
systemd user service example files.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 doc/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/Makefile.am b/doc/Makefile.am
index 53cd639..5638530 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -28,6 +28,7 @@ examples = examples/README examples/scd-event examples/trustlist.txt	\
 	   examples/systemd-user/gpg-agent.service 			\
 	   examples/systemd-user/gpg-agent.socket 			\
 	   examples/systemd-user/gpg-agent-ssh.socket 			\
+	   examples/systemd-user/gpg-agent-browser.socket		\
 	   examples/systemd-user/gpg-agent-extra.socket 		\
 	   examples/gpgconf.conf examples/pwpattern.list
 
-- 
2.10.2



From gniibe at fsij.org  Mon Nov 21 08:40:19 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 21 Nov 2016 16:40:19 +0900
Subject: [PATCH] doc: Ship example gpg-agent-browser.socket in
 examples/systemd-user/.
In-Reply-To: <20161121060619.5890-1-dkg@fifthhorseman.net>
References: <20161121060619.5890-1-dkg@fifthhorseman.net>
Message-ID: <d876ae74-8aa3-d03f-7376-ae19a1548490@fsij.org>

On 11/21/2016 03:06 PM, Daniel Kahn Gillmor wrote:
> * doc/Makefile.am: Ship gpg-agent-browser.socket alongside the other
> systemd user service example files.
> 
> Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> ---
>  doc/Makefile.am | 1 +
>  1 file changed, 1 insertion(+)

Thank you.  Applied and pushed.
--


From gniibe at fsij.org  Mon Nov 21 09:38:54 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 21 Nov 2016 17:38:54 +0900
Subject: [PATCH] doc: Clarify dirmngr --homedir option.
In-Reply-To: <20161121023513.30139-1-dkg@fifthhorseman.net>
References: <20161121023513.30139-1-dkg@fifthhorseman.net>
Message-ID: <3aeef3a1-f27d-70c7-af78-4ca778812f61@fsij.org>

On 11/21/2016 11:35 AM, Daniel Kahn Gillmor wrote:
> * doc/dirmngr.texi: Fix minor spelling and grammar issues in
> documentation of --homedir option for dirmngr.
> 
> Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> ---
>  doc/dirmngr.texi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Thank you.  Applied and pushed.  I didn't put the detail of change is
not in the commit log since it's documentation only change which is
not needed to be ChangeLog.
-- 


From wk at gnupg.org  Mon Nov 21 09:58:14 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 21 Nov 2016 09:58:14 +0100
Subject: FYI: Result of donations to GnuPG's WHS account
Message-ID: <87ziktnra1.fsf@wheatstone.g10code.de>

Hi!

I just received an account statement from the Wau Holland Foundation on
the GnuPG account they set up for us:

GnuPG donations at WHS as of 2016-11-20:

|       | Paypal |   Bank | BTC in ? |
|-------+--------+--------+----------+
|  2014 |    141 |  6.500 |    3.730 |
|  2015 |  4.600 | 22.760 |   10.356 |
|  2016 |        |  1.684 |      148 |
|-------+--------+--------+----------+
| Summe |  4.741 | 30.944 |   14.234 |
|-------+--------+--------+----------+
| Total | 49.919 |        |          |




Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161121/dd3f3ca5/attachment.sig>

From patrick at enigmail.net  Mon Nov 21 14:28:00 2016
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Mon, 21 Nov 2016 14:28:00 +0100
Subject: GnuPG 2.1.16 build error on Mac OS X
Message-ID: <c7f1aeae-de30-aba6-a043-e4c9997e5785@enigmail.net>

Building tools/gpg-wks-client fails on Mac OS X because $(LIBINTL) is
not specified.

Please append $(LIBINTL) to gpg_wks_client_LDADD in Makefile.am /
Makefile.in

-Patrick


From wk at gnupg.org  Mon Nov 21 16:59:44 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 21 Nov 2016 16:59:44 +0100
Subject: GnuPG 2.1.16 build error on Mac OS X
In-Reply-To: <c7f1aeae-de30-aba6-a043-e4c9997e5785@enigmail.net> (Patrick
 Brunschwig's message of "Mon, 21 Nov 2016 14:28:00 +0100")
References: <c7f1aeae-de30-aba6-a043-e4c9997e5785@enigmail.net>
Message-ID: <87y40clt73.fsf@wheatstone.g10code.de>

On Mon, 21 Nov 2016 14:28, patrick at enigmail.net said:
> Building tools/gpg-wks-client fails on Mac OS X because $(LIBINTL) is
> not specified.

Yep, see https://bugs.gnupg.org/gnupg/issue2846 .  Interesting fact is
that our build links against iconv:

 gcc -I/Users/jenkins/prefix/native/include
   -I/Users/jenkins/prefix/native/include -O3 -Wall -Wcast-align -Wshadow
   -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W
   -Wno-sign-compare -Wno-missing-field-initializers
   -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith
   -D_DARWIN_C_SOURCE=900000L -fPIC -o gpg-wks-client
   gpg_wks_client-gpg-wks-client.o gpg_wks_client-wks-util.o
   gpg_wks_client-wks-receive.o gpg_wks_client-rfc822parse.o
   gpg_wks_client-mime-parser.o gpg_wks_client-mime-maker.o
   gpg_wks_client-send-mail.o gpg_wks_client-call-dirmngr.o
   ../common/libcommon.a -lassuan -L/Users/jenkins/prefix/native/lib
   -lgpg-error -L/Users/jenkins/prefix/native/lib -lgcrypt -lgpg-error
   -L/Users/jenkins/prefix/native/lib -lgpg-error -L/Users/jenkins/pkg/lib
   -liconv

which is due to this change (part of 2.1.16):

  commit 6054e8aaecbd355bb7559697eecaadf2225189b8
  Author:     Justus Winter <justus at g10code.com>
  AuthorDate: Fri Sep 30 12:34:31 2016 +0200
  Commit:     Justus Winter <justus at g10code.com>
  CommitDate: Fri Sep 30 17:45:59 2016 +0200
  
      build: Fix build against libiconv.
      
      * agent/Makefile.am: Add INCICONV and LIBICONV.
      * common/Makefile.am: Likewise.
      * tools/Makefile.am: Likewise.
  
So, what is different on your build?




Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161121/b8733913/attachment.sig>

From patrick at enigmail.net  Mon Nov 21 17:30:51 2016
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Mon, 21 Nov 2016 17:30:51 +0100
Subject: GnuPG 2.1.16 build error on Mac OS X
In-Reply-To: <87y40clt73.fsf@wheatstone.g10code.de>
References: <c7f1aeae-de30-aba6-a043-e4c9997e5785@enigmail.net>
 <87y40clt73.fsf@wheatstone.g10code.de>
Message-ID: <8e5f4318-2da4-978e-1578-c5213b1b1a00@enigmail.net>

On 21.11.16 16:59, Werner Koch wrote:
> On Mon, 21 Nov 2016 14:28, patrick at enigmail.net said:
>> Building tools/gpg-wks-client fails on Mac OS X because $(LIBINTL) is
>> not specified.
> 
> Yep, see https://bugs.gnupg.org/gnupg/issue2846 .  Interesting fact is
> that our build links against iconv:
> 
>  gcc -I/Users/jenkins/prefix/native/include
>    -I/Users/jenkins/prefix/native/include -O3 -Wall -Wcast-align -Wshadow
>    -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W
>    -Wno-sign-compare -Wno-missing-field-initializers
>    -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith
>    -D_DARWIN_C_SOURCE=900000L -fPIC -o gpg-wks-client
>    gpg_wks_client-gpg-wks-client.o gpg_wks_client-wks-util.o
>    gpg_wks_client-wks-receive.o gpg_wks_client-rfc822parse.o
>    gpg_wks_client-mime-parser.o gpg_wks_client-mime-maker.o
>    gpg_wks_client-send-mail.o gpg_wks_client-call-dirmngr.o
>    ../common/libcommon.a -lassuan -L/Users/jenkins/prefix/native/lib
>    -lgpg-error -L/Users/jenkins/prefix/native/lib -lgcrypt -lgpg-error
>    -L/Users/jenkins/prefix/native/lib -lgpg-error -L/Users/jenkins/pkg/lib
>    -liconv
> 
> which is due to this change (part of 2.1.16):
> 
>   commit 6054e8aaecbd355bb7559697eecaadf2225189b8
>   Author:     Justus Winter <justus at g10code.com>
>   AuthorDate: Fri Sep 30 12:34:31 2016 +0200
>   Commit:     Justus Winter <justus at g10code.com>
>   CommitDate: Fri Sep 30 17:45:59 2016 +0200
>   
>       build: Fix build against libiconv.
>       
>       * agent/Makefile.am: Add INCICONV and LIBICONV.
>       * common/Makefile.am: Likewise.
>       * tools/Makefile.am: Likewise.
>   
> So, what is different on your build?

I'm also building against iconv. But in I'm not referencing libintl in
libiconv. That is I don't specify --with-libintl-prefix, and due to not
using standard directories, libintl is not found.

Therefore libiconv and libintl are two separate libraries on my system.

-Patrick



From wk at gnupg.org  Mon Nov 21 18:31:21 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 21 Nov 2016 18:31:21 +0100
Subject: GnuPG 2.1.16 build error on Mac OS X
In-Reply-To: <8e5f4318-2da4-978e-1578-c5213b1b1a00@enigmail.net> (Patrick
 Brunschwig's message of "Mon, 21 Nov 2016 17:30:51 +0100")
References: <c7f1aeae-de30-aba6-a043-e4c9997e5785@enigmail.net>
 <87y40clt73.fsf@wheatstone.g10code.de>
 <8e5f4318-2da4-978e-1578-c5213b1b1a00@enigmail.net>
Message-ID: <87h970loye.fsf@wheatstone.g10code.de>

On Mon, 21 Nov 2016 17:30, patrick at enigmail.net said:

> I'm also building against iconv. But in I'm not referencing libintl in

Ooops, I am always mixing up libiconv and libintl.  Of course they are
separate.

> libiconv. That is I don't specify --with-libintl-prefix, and due to not
> using standard directories, libintl is not found.

configure didn't found libintl and thus we build w/o NLS.  Okay, needs
to be fixed in the build script.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161121/ae21cfb3/attachment.sig>

From mailinglists at gusnan.se  Mon Nov 21 18:55:03 2016
From: mailinglists at gusnan.se (Andreas Ronnquist)
Date: Mon, 21 Nov 2016 18:55:03 +0100
Subject: [gpa] small typo proceeed/proceed
Message-ID: <20161121185503.083a514c@debian-i7>

Hi!

Working on packaging the new version of gpa into Debian, I (with great
help from the lintian tool) discovered a typo in it - see the attached
patch.

best
-- Andreas R?nnquist
mailinglists at gusnan.se
gusnan at openmailbox.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-typo-proceeed-proceed.patch
Type: text/x-patch
Size: 975 bytes
Desc: not available
URL: </pipermail/attachments/20161121/e56cfb7b/attachment.bin>

From gniibe at fsij.org  Tue Nov 22 09:40:15 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 22 Nov 2016 17:40:15 +0900
Subject: [PATCH] scdaemon change for OpenPGPcard V3: Please test
Message-ID: <76d29fdc-cb06-cf48-5aae-cda587e3b0b7@fsij.org>

Hello,

I found that OpenPGPcard V3 specification changed the semantics
of some data in Extended Capabilities.  I think that it is good
if scdaemon can support OpenPGPcard V2 and V3.

Here is my change.  Users who have OpenPGP card implementations,
I'd like to ask you testing with this code.

For Gnuk, it doesn't use extended Lc and extended Le at all, so it
doesn't matter.  (Although I tested already.)


diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index d1c9efe..0586fe4 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -195,10 +195,8 @@ struct app_local_s {
     unsigned int has_decrypt:1;        /* Support symmetric decryption.  */
     unsigned int has_button:1;
     unsigned int sm_algo:2;            /* Symmetric crypto algo for SM.  */
-    unsigned int max_certlen_3:16;
+    unsigned int max_certlen:16;
     unsigned int max_get_challenge:16; /* Maximum size for
get_challenge.  */
-    unsigned int max_cmd_data:16;      /* Maximum data size for a
command.  */
-    unsigned int max_rsp_data:16;      /* Maximum size of a response.  */
   } extcap;

   /* Flags used to control the application.  */
@@ -325,7 +323,7 @@ get_cached_data (app_t app, int tag,
     }

   if (try_extlen && app->app_local->cardcap.ext_lc_le)
-    exmode = app->app_local->extcap.max_rsp_data;
+    exmode = app->app_local->extcap.max_certlen + 2;
   else
     exmode = 0;

@@ -455,10 +453,7 @@ get_one_do (app_t app, int tag, unsigned char
**result, size_t *nbytes,

   if (app->card_version > 0x0100 && data_objects[i].get_immediate_in_v11)
     {
-      if (data_objects[i].try_extlen && app->app_local->cardcap.ext_lc_le)
-        exmode = app->app_local->extcap.max_rsp_data;
-      else
-        exmode = 0;
+      exmode = 0;
       rc = iso7816_get_data (app->slot, exmode, tag, &buffer, &buflen);
       if (rc)
         {
@@ -922,6 +917,40 @@ send_key_attr (ctrl_t ctrl, app_t app, const char
*keyword, int keyno)
 }


+
+enum {
+  OP_GET_PUBKEY,
+  OP_SIGN,
+  OP_DECIPHER,
+  OP_AUTH,
+};
+
+static int
+determine_response_size (app_t app, int keyno, int op)
+{
+  int size = 256;               /* Default */
+
+  if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA)
+    {
+      if (op == OP_GET_PUBKEY)
+        {
+          size = 2 + 3 /* header */
+            + 4 /* tag+len */ + app->app_local->keyattr[keyno].rsa.n_bits/8
+            + 2 /* tag+len */ +
app->app_local->keyattr[keyno].rsa.e_bits/8;
+
+          if (app->app_local->keyattr[keyno].rsa.n_bits <= 1024)
+            size = size - 2;
+        }
+      else
+        size = app->app_local->keyattr[keyno].rsa.n_bits / 8;
+
+      size += 2;        /* Add two for status bytes.  */
+    }
+
+  return size;
+}
+
+
 /* Implement the GETATTR command.  This is similar to the LEARN
    command but returns just one value via the status interface. */
 static gpg_error_t
@@ -991,13 +1020,13 @@ do_getattr (app_t app, ctrl_t ctrl, const char *name)
       char tmp[110];

       snprintf (tmp, sizeof tmp,
-                "gc=%d ki=%d fc=%d pd=%d mcl3=%u aac=%d "
+                "gc=%d ki=%d fc=%d pd=%d mcl=%u aac=%d "
                 "sm=%d si=%u dec=%d bt=%d",
                 app->app_local->extcap.get_challenge,
                 app->app_local->extcap.key_import,
                 app->app_local->extcap.change_force_chv,
                 app->app_local->extcap.private_dos,
-                app->app_local->extcap.max_certlen_3,
+                app->app_local->extcap.max_certlen,
                 app->app_local->extcap.algo_attr_change,
                 (app->app_local->extcap.sm_supported
                  ? (app->app_local->extcap.sm_algo == 0? CIPHER_ALGO_3DES :
@@ -1534,7 +1563,7 @@ get_public_key (app_t app, int keyno)
       if (app->app_local->cardcap.ext_lc_le)
         {
           exmode = 1;    /* Use extended length.  */
-          le_value = app->app_local->extcap.max_rsp_data;
+          le_value = determine_response_size (app, keyno, OP_GET_PUBKEY);
         }
       else
         {
@@ -2285,7 +2314,7 @@ do_writecert (app_t app, ctrl_t ctrl,
     return gpg_error (GPG_ERR_INV_ARG);
   if (!app->app_local->extcap.is_v2)
     return gpg_error (GPG_ERR_NOT_SUPPORTED);
-  if (certdatalen > app->app_local->extcap.max_certlen_3)
+  if (certdatalen > app->app_local->extcap.max_certlen)
     return gpg_error (GPG_ERR_TOO_LARGE);
   return do_setattr (app, "CERT-3", pincb, pincb_arg, certdata,
certdatalen);
 #else
@@ -3774,7 +3803,7 @@ do_genkey (app_t app, ctrl_t ctrl,  const char
*keynostr, unsigned int flags,
       if (app->app_local->cardcap.ext_lc_le && keybits > 1900)
         {
           exmode = 1;    /* Use extended length w/o a limit.  */
-          le_value = app->app_local->extcap.max_rsp_data;
+          le_value = determine_response_size (app, keyno, OP_GET_PUBKEY);
           /* No need to check le_value because it comes from a 16 bit
              value and thus can't create an overflow on a 32 bit
              system.  */
@@ -4125,7 +4154,7 @@ do_sign (app_t app, const char *keyidstr, int
hashalgo,
   if (app->app_local->cardcap.ext_lc_le)
     {
       exmode = 1;    /* Use extended length.  */
-      le_value = app->app_local->extcap.max_rsp_data;
+      le_value = determine_response_size (app, 0, OP_SIGN);
     }
   else
     {
@@ -4228,7 +4257,7 @@ do_auth (app_t app, const char *keyidstr,
       if (app->app_local->cardcap.ext_lc_le)
         {
           exmode = 1;    /* Use extended length.  */
-          le_value = app->app_local->extcap.max_rsp_data;
+          le_value = determine_response_size (app, 2, OP_AUTH);
         }
       else
         {
@@ -4420,7 +4449,7 @@ do_decipher (app_t app, const char *keyidstr,
   if (app->app_local->cardcap.ext_lc_le && indatalen > 254 )
     {
       exmode = 1;    /* Extended length w/o a limit.  */
-      le_value = app->app_local->extcap.max_rsp_data;
+      le_value = determine_response_size (app, 1, OP_DECIPHER);
     }
   else if (app->app_local->cardcap.cmd_chaining && indatalen > 254)
     {
@@ -4577,9 +4606,7 @@ show_caps (struct app_local_s *s)
   if (s->extcap.sm_supported)
     log_printf (" (%s)", s->extcap.sm_algo==2? "3DES":
                 (s->extcap.sm_algo==2? "AES-128" : "AES-256"));
-  log_info ("Max-Cert3-Len ..: %u\n", s->extcap.max_certlen_3);
-  log_info ("Max-Cmd-Data ...: %u\n", s->extcap.max_cmd_data);
-  log_info ("Max-Rsp-Data ...: %u\n", s->extcap.max_rsp_data);
+  log_info ("Max-Cert-Len ..: %u\n", s->extcap.max_certlen);
   log_info ("Cmd-Chaining ...: %s\n", s->cardcap.cmd_chaining?"yes":"no");
   log_info ("Ext-Lc-Le ......: %s\n", s->cardcap.ext_lc_le?"yes":"no");
   log_info ("Status Indicator: %02X\n", s->status_indicator);
@@ -4882,9 +4909,7 @@ app_select_openpgp (app_t app)
           app->app_local->extcap.sm_algo = buffer[1];
           app->app_local->extcap.max_get_challenge
                                                = (buffer[2] << 8 |
buffer[3]);
-          app->app_local->extcap.max_certlen_3 = (buffer[4] << 8 |
buffer[5]);
-          app->app_local->extcap.max_cmd_data  = (buffer[6] << 8 |
buffer[7]);
-          app->app_local->extcap.max_rsp_data  = (buffer[8] << 8 |
buffer[9]);
+          app->app_local->extcap.max_certlen = (buffer[4] << 8 |
buffer[5]);
         }
       xfree (relptr);

-- 


From dkg at fifthhorseman.net  Wed Nov 23 20:45:19 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 23 Nov 2016 14:45:19 -0500
Subject: generic and flexible bindings for gpg without race conditions
In-Reply-To: <87a8eaxug3.fsf@alice.fifthhorseman.net>
References: <87a8eaxug3.fsf@alice.fifthhorseman.net>
Message-ID: <87bmx6geuo.fsf@alice.fifthhorseman.net>

Hi all--

On Tue 2016-10-11 20:49:32 -0400, Daniel Kahn Gillmor wrote:
> GnuPG::Interface has traditionally offered a mode for users to provide
> the password programmatically, and then passed the password to the gpg
> process.  I will probably urge the GnuPG::Interface maintainer to
> discourage this use pattern in favor of delegating access decisions to
> the agent or a custom pinentry, but they will likely want to support
> this mode for some time into the future.
>
> With modern GnuPG, using this "send the password explicitly" mode
> requires --pinentry-mode=loopback, but neither classic nor stable
> supports this argument.
>
> As a result, i don't know how to decide what to send: either i supply
> --pinentry-mode=loopback (and fail on classic and stable because of
> "Invalid option") or i don't supply it (and the passphrase doesn't get
> seen by modern at all).
>
> I could test the version of gpg, at the not-insignificant expense of an
> additional subprocess ("gpg --version"), and a possible race condition
> (the subsequent call to gpg could hit a different installed gpg process
> than the one tested with --version if there was an upgrade in between
> invocations).
>
> One way to resolve this would be to add --pinentry-mode=loopback as a
> dummy no-op parameter to classic and modern.  This doesn't help for old
> installations, of course, but if someone can upgrade within a given
> series, it would at least let the bindings work.
>
> Are there other solutions to this conundrum?  The upgrade path here is
> tricky and kind of fraught :/

I haven't heard any responses to this question.  Are there any
suggestions?  I note that gpgme invokes a subprocess to get this
information (_gpgme_get_program_version in src/version.c), which seems
not only expensive, but racy: it's certainly possible for gpg to be
upgraded between the initial invocation and subsequent accesses.  Can we
do better?

What is the right approach here?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: </pipermail/attachments/20161123/7b5e758b/attachment.sig>

From muelli at cryptobitch.de  Wed Nov 23 22:42:22 2016
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Wed, 23 Nov 2016 22:42:22 +0100
Subject: DCO for Tobias Mueller
Message-ID: <1479937342.11180.3.camel@cryptobitch.de>

GPGME Developer's Certificate of Origin.??Version 1.0
=====================================================

By making a contribution to the GPGME project, I certify that:

(a) The contribution was created in whole or in part by me and I
????have the right to submit it under the free software license
????indicated in the file; or

(b) The contribution is based upon previous work that, to the
????best of my knowledge, is covered under an appropriate free
????software license and I have the right under that license to
????submit that work with modifications, whether created in whole
????or in part by me, under the same free software license
????(unless I am permitted to submit under a different license),
????as indicated in the file; or

(c) The contribution was provided directly to me by some other
????person who certified (a), (b) or (c) and I have not modified
????it.

(d) I understand and agree that this project and the contribution
????are public and that a record of the contribution (including
????all personal information I submit with it, including my
????sign-off) is maintained indefinitely and may be redistributed
????consistent with this project or the free software license(s)
????involved.

Signed-off-by:?Tobias Mueller <muelli at cryptobitch.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20161123/4e54438e/attachment.sig>

From gniibe at fsij.org  Fri Nov 25 08:12:02 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 25 Nov 2016 16:12:02 +0900
Subject: [PATCH] scdaemon change for OpenPGPcard V3: Please test
In-Reply-To: <76d29fdc-cb06-cf48-5aae-cda587e3b0b7@fsij.org>
References: <76d29fdc-cb06-cf48-5aae-cda587e3b0b7@fsij.org>
Message-ID: <88f42b63-1a51-de16-efc9-fa862e8d06e7@fsij.org>

On 11/22/2016 05:40 PM, NIIBE Yutaka wrote:
> I found that OpenPGPcard V3 specification changed the semantics
> of some data in Extended Capabilities.  I think that it is good
> if scdaemon can support OpenPGPcard V2 and V3.

Here is an update.  I'm going to apply this change to master (2.1
branch).

This change has a little risk breaking existing cards or tokens, while
supporting V3 card.  I tested with OpenPGP card v2.0 and v2.2, it
works fine with limited tests.  It should be OK for Gnuk as it doesn't
use extended Lc/Le at all.

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index d1c9efe..4af999f 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -197,8 +197,6 @@ struct app_local_s {
     unsigned int sm_algo:2;            /* Symmetric crypto algo for SM.  */
     unsigned int max_certlen_3:16;
     unsigned int max_get_challenge:16; /* Maximum size for
get_challenge.  */
-    unsigned int max_cmd_data:16;      /* Maximum data size for a
command.  */
-    unsigned int max_rsp_data:16;      /* Maximum size of a response.  */
   } extcap;

   /* Flags used to control the application.  */
@@ -325,7 +323,7 @@ get_cached_data (app_t app, int tag,
     }

   if (try_extlen && app->app_local->cardcap.ext_lc_le)
-    exmode = app->app_local->extcap.max_rsp_data;
+    exmode = app->app_local->extcap.max_certlen_3;
   else
     exmode = 0;

@@ -455,10 +453,7 @@ get_one_do (app_t app, int tag, unsigned char
**result, size_t *nbytes,

   if (app->card_version > 0x0100 && data_objects[i].get_immediate_in_v11)
     {
-      if (data_objects[i].try_extlen && app->app_local->cardcap.ext_lc_le)
-        exmode = app->app_local->extcap.max_rsp_data;
-      else
-        exmode = 0;
+      exmode = 0;
       rc = iso7816_get_data (app->slot, exmode, tag, &buffer, &buflen);
       if (rc)
         {
@@ -922,6 +917,25 @@ send_key_attr (ctrl_t ctrl, app_t app, const char
*keyword, int keyno)
 }


+#define RSA_SMALL_SIZE_KEY 1960
+#define RSA_SMALL_SIZE_OP  2048
+
+static int
+determine_rsa_response (app_t app, int keyno)
+{
+  int size;
+
+  size = 2 + 3 /* header */
+    + 4 /* tag+len */ + app->app_local->keyattr[keyno].rsa.n_bits/8
+    + 2 /* tag+len */ + app->app_local->keyattr[keyno].rsa.e_bits/8;
+
+  if (app->app_local->keyattr[keyno].rsa.n_bits <= 1024)
+    size = size - 2;
+
+  return size;
+}
+
+
 /* Implement the GETATTR command.  This is similar to the LEARN
    command but returns just one value via the status interface. */
 static gpg_error_t
@@ -1531,10 +1545,12 @@ get_public_key (app_t app, int keyno)
       int exmode, le_value;

       /* We may simply read the public key out of these cards.  */
-      if (app->app_local->cardcap.ext_lc_le)
+      if (app->app_local->cardcap.ext_lc_le
+          && app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA
+          && app->app_local->keyattr[keyno].rsa.n_bits >
RSA_SMALL_SIZE_KEY)
         {
           exmode = 1;    /* Use extended length.  */
-          le_value = app->app_local->extcap.max_rsp_data;
+          le_value = determine_rsa_response (app, keyno);
         }
       else
         {
@@ -3769,12 +3785,11 @@ do_genkey (app_t app, ctrl_t ctrl,  const char
*keynostr, unsigned int flags,
       if (keybits > 4096)
         return gpg_error (GPG_ERR_TOO_LARGE);

-      /* Test whether we will need extended length mode.  (1900 is an
-         arbitrary length which for sure fits into a short apdu.)  */
-      if (app->app_local->cardcap.ext_lc_le && keybits > 1900)
+      if (app->app_local->cardcap.ext_lc_le && keybits > RSA_SMALL_SIZE_KEY
+          && app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA)
         {
           exmode = 1;    /* Use extended length w/o a limit.  */
-          le_value = app->app_local->extcap.max_rsp_data;
+          le_value = determine_rsa_response (app, keyno);
           /* No need to check le_value because it comes from a 16 bit
              value and thus can't create an overflow on a 32 bit
              system.  */
@@ -4122,10 +4137,12 @@ do_sign (app_t app, const char *keyidstr, int
hashalgo,
     }


-  if (app->app_local->cardcap.ext_lc_le)
+  if (app->app_local->cardcap.ext_lc_le
+      && app->app_local->keyattr[0].key_type == KEY_TYPE_RSA
+      && app->app_local->keyattr[0].rsa.n_bits > RSA_SMALL_SIZE_OP)
     {
       exmode = 1;    /* Use extended length.  */
-      le_value = app->app_local->extcap.max_rsp_data;
+      le_value = app->app_local->keyattr[0].rsa.n_bits / 8;
     }
   else
     {
@@ -4225,10 +4242,12 @@ do_auth (app_t app, const char *keyidstr,
     {
       int exmode, le_value;

-      if (app->app_local->cardcap.ext_lc_le)
+      if (app->app_local->cardcap.ext_lc_le
+          && app->app_local->keyattr[2].key_type == KEY_TYPE_RSA
+          && app->app_local->keyattr[2].rsa.n_bits > RSA_SMALL_SIZE_OP)
         {
           exmode = 1;    /* Use extended length.  */
-          le_value = app->app_local->extcap.max_rsp_data;
+          le_value = app->app_local->keyattr[2].rsa.n_bits / 8;
         }
       else
         {
@@ -4417,10 +4436,13 @@ do_decipher (app_t app, const char *keyidstr,
   else
     return gpg_error (GPG_ERR_INV_VALUE);

-  if (app->app_local->cardcap.ext_lc_le && indatalen > 254 )
+  if (app->app_local->cardcap.ext_lc_le
+      && (indatalen > 254
+          || (app->app_local->keyattr[1].key_type == KEY_TYPE_RSA
+              && app->app_local->keyattr[1].rsa.n_bits >
RSA_SMALL_SIZE_OP)))
     {
       exmode = 1;    /* Extended length w/o a limit.  */
-      le_value = app->app_local->extcap.max_rsp_data;
+      le_value = app->app_local->keyattr[1].rsa.n_bits / 8;
     }
   else if (app->app_local->cardcap.cmd_chaining && indatalen > 254)
     {
@@ -4578,8 +4600,6 @@ show_caps (struct app_local_s *s)
     log_printf (" (%s)", s->extcap.sm_algo==2? "3DES":
                 (s->extcap.sm_algo==2? "AES-128" : "AES-256"));
   log_info ("Max-Cert3-Len ..: %u\n", s->extcap.max_certlen_3);
-  log_info ("Max-Cmd-Data ...: %u\n", s->extcap.max_cmd_data);
-  log_info ("Max-Rsp-Data ...: %u\n", s->extcap.max_rsp_data);
   log_info ("Cmd-Chaining ...: %s\n", s->cardcap.cmd_chaining?"yes":"no");
   log_info ("Ext-Lc-Le ......: %s\n", s->cardcap.ext_lc_le?"yes":"no");
   log_info ("Status Indicator: %02X\n", s->status_indicator);
@@ -4883,8 +4903,6 @@ app_select_openpgp (app_t app)
           app->app_local->extcap.max_get_challenge
                                                = (buffer[2] << 8 |
buffer[3]);
           app->app_local->extcap.max_certlen_3 = (buffer[4] << 8 |
buffer[5]);
-          app->app_local->extcap.max_cmd_data  = (buffer[6] << 8 |
buffer[7]);
-          app->app_local->extcap.max_rsp_data  = (buffer[8] << 8 |
buffer[9]);
         }
       xfree (relptr);

-- 


From wk at gnupg.org  Sat Nov 26 17:40:24 2016
From: wk at gnupg.org (Werner Koch)
Date: Sat, 26 Nov 2016 17:40:24 +0100
Subject: generic and flexible bindings for gpg without race conditions
In-Reply-To: <87a8eaxug3.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 11 Oct 2016 20:49:32 -0400")
References: <87a8eaxug3.fsf@alice.fifthhorseman.net>
Message-ID: <87h96ufb47.fsf@wheatstone.g10code.de>

On Wed, 12 Oct 2016 02:49, dkg at fifthhorseman.net said:

> With modern GnuPG, using this "send the password explicitly" mode
> requires --pinentry-mode=loopback, but neither classic nor stable
> supports this argument.

You could put

  ignore-invalid-option pinentry-mode
  pinentry-mode loopback

into gpg.conf but that would force the use of loopback for 2.1.  The
ignore-invalid-option does only work with the configuraion file.

> additional subprocess ("gpg --version"), and a possible race condition
> (the subsequent call to gpg could hit a different installed gpg process
> than the one tested with --version if there was an upgrade in between

Which should not harm unless the upgrade is actually a downgrade.

> One way to resolve this would be to add --pinentry-mode=loopback as a
> dummy no-op parameter to classic and modern.  This doesn't help for old

I am in favor of this.

The other alternative would be to switch to loopback mode in 2.1 as soon
as pinentry-fd is used.  This has been suggested somewhere else.  But
that would be surprising and doesn't work with symmetric only encryption.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161126/c7989e31/attachment.sig>

From fabio.coatti at gmail.com  Sun Nov 27 11:56:17 2016
From: fabio.coatti at gmail.com (Fabio Coatti)
Date: Sun, 27 Nov 2016 11:56:17 +0100
Subject: [pinentry]
Message-ID: <2209807.3WtvXZ1AUa@calvin>

Hi all,
I'm trying to build pinentry 1.0.0 using LTO and I'm having some issues.
Without LTO active I have no issues and the compilation goes just fine.

However, with LTO I'm getting this error (maybe I'm doing something wrong, 
however 0.9.7 compiled just fine even with lto):

x86_64-pc-linux-gnu-gcc  -O2 -fpie -fpic -pipe -march=native -fstack-
protector-strong -flto=4 -fuse-linker-
plugin -Wall -Wno-pointer-sign -Wpointer-arith  -Wl,-O1 -Wl,--as-needed -O2 -
fpie -fpic -pipe -march=native
-fstack-protector-strong -flto=4 -fuse-linker-plugin -o pinentry-tty pinentry-
tty.o ../pinentry/libpinentr
y.a ../secmem/libsecmem.a -lsecret-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -L/
usr/lib64 -lassuan -lgpg-error -
lgpg-error  -lcap   
pinentry-curses.h:30:5: error: variable ?curses_cmd_handler? redeclared as 
function 
pinentry-tty.c:561:24: note: previously declared here 
pinentry_cmd_handler_t curses_cmd_handler = NULL; 
                       ^ 
lto1: fatal error: errors during merging of translation units 
compilation terminated. 
lto-wrapper: fatal error: /usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0/x86_64-pc-
linux-gnu-gcc returned 1 exit st
atus 
compilation terminated. 
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
error: lto-wrapper failed 
collect2: error: ld returned 1 exit status 
make[2]: *** [Makefile:410: pinentry-tty] Error 1 
make[2]: Leaving directory '/var/tmp/portage/app-crypt/pinentry-1.0.0/work/
pinentry-1.0.0/tty' 
make[1]: *** [Makefile:460: all-recursive] Error 1 
make[1]: Leaving directory '/var/tmp/portage/app-crypt/pinentry-1.0.0/work/
pinentry-1.0.0' 
make: *** [Makefile:401: all] Error 2


Output of configure phase:

configure: 

       Pinentry v1.0.0 has been configured as follows: 

       Revision:    (0) 
       Platform:  x86_64-pc-linux-gnu 

       Curses Pinentry ..: yes 
       TTY Pinentry .....: yes 
       Emacs Pinentry ...: no 
       GTK+-2 Pinentry ..: yes 
       GNOME 3 Pinentry .: yes 
       Qt Pinentry ......: yes (Qt5) 
       W32 Pinentry .....: no 

       Fallback to Curses: yes 
       Emacs integration : yes 

       libsecret ........: yes 

       Default Pinentry .: pinentry-gtk-2


gcc: 5.4.0
ld: 2.27

System: gentoo.

Of course I'm available for any other info needed

-- 
Fabio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161127/cbbcfd0f/attachment-0001.html>

From gniibe at fsij.org  Mon Nov 28 06:21:02 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 28 Nov 2016 14:21:02 +0900
Subject: [NPTH] npth and fork
In-Reply-To: <be5b898c-6511-0063-2c03-a09a377017ee@fsij.org>
References: <ca6f6280-8dad-b0a8-4e11-5fb1d6455479@fsij.org>
 <b639474a-313d-2b51-b775-b3abb4bdf319@fsij.org>
 <f8d33fab-bd9b-5eec-fe65-5112ba331efd@fsij.org>
 <be5b898c-6511-0063-2c03-a09a377017ee@fsij.org>
Message-ID: <1b7ccb73-ef6f-8e16-bd61-cc865efc5950@fsij.org>

On 10/04/2016 09:49 AM, NIIBE Yutaka wrote:
> Now, I would like to change nPth for macOS.  Currently, it uses named
> semaphore detecting the failure of sem_init at runtime.  I think
> that use of unnamed semaphore of Grand Central Dispatch is better.

Attached is the change.  It's not yet tested with GnuPG.
I will do.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: npth-mac.diff
Type: text/x-patch
Size: 2519 bytes
Desc: not available
URL: </pipermail/attachments/20161128/d756b866/attachment.bin>

From wk at gnupg.org  Mon Nov 28 10:28:35 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 28 Nov 2016 10:28:35 +0100
Subject: [NPTH] npth and fork
In-Reply-To: <1b7ccb73-ef6f-8e16-bd61-cc865efc5950@fsij.org> (NIIBE Yutaka's
 message of "Mon, 28 Nov 2016 14:21:02 +0900")
References: <ca6f6280-8dad-b0a8-4e11-5fb1d6455479@fsij.org>
 <b639474a-313d-2b51-b775-b3abb4bdf319@fsij.org>
 <f8d33fab-bd9b-5eec-fe65-5112ba331efd@fsij.org>
 <be5b898c-6511-0063-2c03-a09a377017ee@fsij.org>
 <1b7ccb73-ef6f-8e16-bd61-cc865efc5950@fsij.org>
Message-ID: <87mvgkdkcc.fsf@wheatstone.g10code.de>

On Mon, 28 Nov 2016 06:21, gniibe at fsij.org said:

> Attached is the change.  It's not yet tested with GnuPG.
> I will do.

You patch also removed the fix (or well, semi-fix) for AIX.  Was this
intentional?


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161128/5ab0d4fb/attachment.sig>

From gniibe at fsij.org  Mon Nov 28 12:45:26 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 28 Nov 2016 20:45:26 +0900
Subject: [NPTH] npth and fork
In-Reply-To: <87mvgkdkcc.fsf@wheatstone.g10code.de>
References: <ca6f6280-8dad-b0a8-4e11-5fb1d6455479@fsij.org>
 <b639474a-313d-2b51-b775-b3abb4bdf319@fsij.org>
 <f8d33fab-bd9b-5eec-fe65-5112ba331efd@fsij.org>
 <be5b898c-6511-0063-2c03-a09a377017ee@fsij.org>
 <1b7ccb73-ef6f-8e16-bd61-cc865efc5950@fsij.org>
 <87mvgkdkcc.fsf@wheatstone.g10code.de>
Message-ID: <d7ef87b9-96b3-3ffb-00d9-5e575e40139d@fsij.org>

On 11/28/2016 06:28 PM, Werner Koch wrote:
> You patch also removed the fix (or well, semi-fix) for AIX.  Was this
> intentional?

It's not intentional for AIX.  My intention is just for macOS.
Nevertheless, this is a good opportunity also addressing AIX.

Executive summary:
I think that the removal is also valid for AIX versions.


I learn the versions of AIX in the Wikipedia:
    https://en.wikipedia.org/wiki/IBM_AIX

I checked IBM Knowledge Center.

    IBM Knowledge Center:
    https://www.ibm.com/support/knowledgecenter/

Current supported versions: 5.3, 6.1, 7.1, 7.2
All has sem_init and it doesn't return ENOSYS.
It seems that it was introduced 5.2.

I found a page saying it was ENOSYS in 4.3.3:

    http://www.verycomputer.com/176_d019c987cbd61c92_1.htm

I don't know about 5.1.

I checked Python bug tracker.  We can see similar issues on AIX
about sem_init.  For example:

    http://bugs.python.org/issue12372


I checked BDW-gc library mailing list:

    http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2011-May/004591.html

It said that it worked on AIX 5.2, 5.3, 6.1 and 7.1.


So, I believe that it (I mean, removal of try_sem_open) works on AIX
5.2, 5.3, 6.1, 7.1 and 7.2.  Note that I can only test on AIX 6.1.


I also find an article:

    Implement POSIX Semaphore APIs using System V Semaphores APIs:
    http://www.ibm.com/developerworks/library/l-semaphore/index.html

It suggests use of System V Semaphores for z/OS.
-- 


From wk at gnupg.org  Mon Nov 28 15:54:21 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 28 Nov 2016 15:54:21 +0100
Subject: [NPTH] npth and fork
In-Reply-To: <d7ef87b9-96b3-3ffb-00d9-5e575e40139d@fsij.org> (NIIBE Yutaka's
 message of "Mon, 28 Nov 2016 20:45:26 +0900")
References: <ca6f6280-8dad-b0a8-4e11-5fb1d6455479@fsij.org>
 <b639474a-313d-2b51-b775-b3abb4bdf319@fsij.org>
 <f8d33fab-bd9b-5eec-fe65-5112ba331efd@fsij.org>
 <be5b898c-6511-0063-2c03-a09a377017ee@fsij.org>
 <1b7ccb73-ef6f-8e16-bd61-cc865efc5950@fsij.org>
 <87mvgkdkcc.fsf@wheatstone.g10code.de>
 <d7ef87b9-96b3-3ffb-00d9-5e575e40139d@fsij.org>
Message-ID: <87lgw3d59e.fsf@wheatstone.g10code.de>

On Mon, 28 Nov 2016 12:45, gniibe at fsij.org said:

> I think that the removal is also valid for AIX versions.

Okay.  Can you please add a comment with this content:

> Current supported versions: 5.3, 6.1, 7.1, 7.2
> All has sem_init and it doesn't return ENOSYS.
> It seems that it was introduced 5.2.
>
> I found a page saying it was ENOSYS in 4.3.3:
>
>     http://www.verycomputer.com/176_d019c987cbd61c92_1.htm

So that the next time someone with a very old AIX versions files a bug
report, we can reject this as wontfix after only looking at the code
with the call to sem_init.



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161128/3c64200b/attachment.sig>

From gniibe at fsij.org  Tue Nov 29 04:03:23 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 29 Nov 2016 12:03:23 +0900
Subject: [NPTH] npth and fork
In-Reply-To: <87lgw3d59e.fsf@wheatstone.g10code.de>
References: <ca6f6280-8dad-b0a8-4e11-5fb1d6455479@fsij.org>
 <b639474a-313d-2b51-b775-b3abb4bdf319@fsij.org>
 <f8d33fab-bd9b-5eec-fe65-5112ba331efd@fsij.org>
 <be5b898c-6511-0063-2c03-a09a377017ee@fsij.org>
 <1b7ccb73-ef6f-8e16-bd61-cc865efc5950@fsij.org>
 <87mvgkdkcc.fsf@wheatstone.g10code.de>
 <d7ef87b9-96b3-3ffb-00d9-5e575e40139d@fsij.org>
 <87lgw3d59e.fsf@wheatstone.g10code.de>
Message-ID: <7f7f4336-ea1e-6d2c-1e2b-978ca08e115d@fsij.org>

On 11/28/2016 11:54 PM, Werner Koch wrote:
> So that the next time someone with a very old AIX versions files a bug
> report, we can reject this as wontfix after only looking at the code
> with the call to sem_init.

I added comments and pushed the change.  I also add detection of Grand
Central Dispatch for macOS only.

Interestingly, the t-fork test successes on macOS Sierra (I had expected
a failure).
-- 

-------------- 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/20161129/1780319e/attachment.sig>

From zdenek.hatas at gmail.com  Tue Nov 29 12:27:53 2016
From: zdenek.hatas at gmail.com (Zdenek Hatas)
Date: Tue, 29 Nov 2016 12:27:53 +0100
Subject: [GPA] Translation patch question
Message-ID: <CAAwQP0O4n6bEOwSiqGBkfsewqMgMSbJ2n7r44OeZASeSBdJn-g@mail.gmail.com>

Hi,
I contributed translation to GPA project in the past and now made update
again.

When I tried to send a message with a patch, "message too large" returned
to me from the list.
What is the right way to send a patch wich is 60k large?
Patch hold single file cs translation update for GPA.

Thanks,

Zden?k H.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161129/255871be/attachment.html>

From muelli at cryptobitch.de  Tue Nov 29 13:51:42 2016
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Tue, 29 Nov 2016 13:51:42 +0100
Subject: [PATCH] python: Add a __repr__ function for a gpgme_user_id.
Message-ID: <1480423902.28504.40.camel@cryptobitch.de>

* lang/python/gpgme.i: Added _gpgme_user_id::__repr__
--

This makes it look a bit nicer in the Python REPL.

Signed-off-by: Tobias Mueller <muelli at cryptobitch.de>
---
 lang/python/gpgme.i | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i
index 0e2feec..5d61725 100644
--- a/lang/python/gpgme.i
+++ b/lang/python/gpgme.i
@@ -684,3 +684,13 @@ _gpg_unwrap_gpgme_ctx_t(PyObject *wrapped)
 /* ... but only the public definitions here.  They will be exposed to
    the Python world, so let's be careful.  */
 %include "helpers.h"
+
+%feature("python:slot", "tp_repr", functype="reprfunc") _gpgme_user_id::__repr__;
+
+%extend _gpgme_user_id {
+    PyObject* __repr__ () {
+        return PyUnicode_FromFormat("UID(\"%s\" revoked=%d invalid=%d validity=%d)",
+                    $self->uid,
+                    $self->revoked, $self->invalid, $self->validity);
+    }
+};
-- 
2.7.4


From justus at g10code.com  Tue Nov 29 16:07:32 2016
From: justus at g10code.com (Justus Winter)
Date: Tue, 29 Nov 2016 16:07:32 +0100
Subject: GnuPG 2.1.16 build error on Mac OS X
In-Reply-To: <87h970loye.fsf@wheatstone.g10code.de>
References: <c7f1aeae-de30-aba6-a043-e4c9997e5785@enigmail.net>
 <87y40clt73.fsf@wheatstone.g10code.de>
 <8e5f4318-2da4-978e-1578-c5213b1b1a00@enigmail.net>
 <87h970loye.fsf@wheatstone.g10code.de>
Message-ID: <87vav6pbnv.fsf@europa.jade-hamburg.de>

Hi Patrick,

Werner Koch <wk at gnupg.org> writes:
> On Mon, 21 Nov 2016 17:30, patrick at enigmail.net said:
>
>> I'm also building against iconv. But in I'm not referencing libintl in
>
> Ooops, I am always mixing up libiconv and libintl.  Of course they are
> separate.
>
>> libiconv. That is I don't specify --with-libintl-prefix, and due to not
>> using standard directories, libintl is not found.
>
> configure didn't found libintl and thus we build w/o NLS.  Okay, needs
> to be fixed in the build script.

https://bugs.gnupg.org/gnupg/issue2846

Does that issue describe your problem?  Is the fix sufficient?

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20161129/6ecfdae9/attachment-0001.sig>

From justus at g10code.com  Tue Nov 29 17:07:06 2016
From: justus at g10code.com (Justus Winter)
Date: Tue, 29 Nov 2016 17:07:06 +0100
Subject: [gpa] small typo proceeed/proceed
In-Reply-To: <20161121185503.083a514c@debian-i7>
References: <20161121185503.083a514c@debian-i7>
Message-ID: <87shqap8wl.fsf@europa.jade-hamburg.de>

Hey,

Andreas Ronnquist <mailinglists at gusnan.se> writes:
> Working on packaging the new version of gpa into Debian, I (with great
> help from the lintian tool) discovered a typo in it - see the attached
> patch.

Merged, many thanks!

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20161129/94cbb4d9/attachment.sig>

From patrick at enigmail.net  Tue Nov 29 17:28:26 2016
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Tue, 29 Nov 2016 17:28:26 +0100
Subject: GnuPG 2.1.16 build error on Mac OS X
In-Reply-To: <87vav6pbnv.fsf@europa.jade-hamburg.de>
References: <c7f1aeae-de30-aba6-a043-e4c9997e5785@enigmail.net>
 <87y40clt73.fsf@wheatstone.g10code.de>
 <8e5f4318-2da4-978e-1578-c5213b1b1a00@enigmail.net>
 <87h970loye.fsf@wheatstone.g10code.de>
 <87vav6pbnv.fsf@europa.jade-hamburg.de>
Message-ID: <64bc3524-b268-aac2-b745-0a44719a8c2f@enigmail.net>

On 29.11.16 16:07, Justus Winter wrote:
> Hi Patrick,
> 
> Werner Koch <wk at gnupg.org> writes:
>> On Mon, 21 Nov 2016 17:30, patrick at enigmail.net said:
>>
>>> I'm also building against iconv. But in I'm not referencing libintl in
>>
>> Ooops, I am always mixing up libiconv and libintl.  Of course they are
>> separate.
>>
>>> libiconv. That is I don't specify --with-libintl-prefix, and due to not
>>> using standard directories, libintl is not found.
>>
>> configure didn't found libintl and thus we build w/o NLS.  Okay, needs
>> to be fixed in the build script.
> 
> https://bugs.gnupg.org/gnupg/issue2846
> 
> Does that issue describe your problem?  Is the fix sufficient?

Yes, that's sufficient.

Thanks,
Patrick


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20161129/c1c1980d/attachment.sig>

From muelli at cryptobitch.de  Tue Nov 29 22:51:07 2016
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Tue, 29 Nov 2016 22:51:07 +0100
Subject: [PATCH] python: Remove -builtin flag for SWIG bindings.
Message-ID: <1480456267.7697.5.camel@cryptobitch.de>

* lang/python/setup.py.in: changed the swig call
--

The motivation is to be able to program __repr__
functions more easily, i.e. in Python rather than C.

The -builtin flag prevents that, though, because Python code
will not be compiled.

The -py3 flag prevents the SWIG bindings to run under python2
when generated without the -builtin flag, because the py3 flag
generates python3 code which is incompatible with python2.

So we conditionally generate SWIG bindings with -py3.

Signed-off-by: Tobias Mueller <muelli at cryptobitch.de>
---
 lang/python/setup.py.in | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in
index 9669c28..5b5d5be 100755
--- a/lang/python/setup.py.in
+++ b/lang/python/setup.py.in
@@ -152,9 +152,10 @@ class BuildExtFirstHack(build):
         self.run_command('build_ext')
         build.run(self)
 
+py3 = [] if sys.version_info.major < 3 else ['-py3']
 swige = Extension("gpg._gpgme", ["gpgme.i", "helpers.c"],
-                  swig_opts = ['-py3', '-builtin', '-threads',
-                               '-outdir', 'gpg'] + extra_swig_opts,
+                  swig_opts = ['-threads',
+                               '-outdir', 'gpg'] + py3 + extra_swig_opts,
                   include_dirs = include_dirs,
                   define_macros = define_macros,
                   library_dirs = library_dirs,
-- 
2.7.4


From muelli at cryptobitch.de  Tue Nov 29 23:26:20 2016
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Tue, 29 Nov 2016 23:26:20 +0100
Subject: [PATCH] python: Make Context have a repr method.
Message-ID: <1480458380.7697.14.camel@cryptobitch.de>

* lang/python/gpg/core.py (Context.__repr__): added
--

To look nicer in a REPL

Signed-off-by: Tobias Mueller <muelli at cryptobitch.de>
---
 lang/python/gpg/core.py | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lang/python/gpg/core.py b/lang/python/gpg/core.py
index 748bcbb..7b49d3b 100644
--- a/lang/python/gpg/core.py
+++ b/lang/python/gpg/core.py
@@ -204,6 +204,14 @@ class Context(GpgmeWrapper):
         self.pinentry_mode = pinentry_mode
         self.protocol = protocol
 
+    def __repr__(self):
+        return "".join((
+            "Context(armor={0.armor}, ",
+            "textmode={0.textmode}, offline={0.offline}, ",
+            "signers={0.signers}, pinentry_mode={0.pinentry_mode}, ",
+            "protocol={0.protocol}",
+            ")")).format(self)
+
     def encrypt(self, plaintext, recipients=[], sign=True, sink=None,
                 passphrase=None, always_trust=False, add_encrypt_to=False,
                 prepare=False, expect_sign=False, compress=True):
-- 
2.7.4


From caro at nymph.paranoici.org  Wed Nov 30 00:04:29 2016
From: caro at nymph.paranoici.org (Carola Grunwald)
Date: Tue, 29 Nov 2016 23:04:29 +0000 (UTC)
Subject: Key creation problem with 2.1.16
Message-ID: <20161129230429.B2488100B190@remailer.paranoici.org>

Hi,

after key creation, which usually succeeds, gpg.exe sometimes returns
error number 2, which looks like a bug.

| gpg: DBG: get_keygrip for public key
| gpg: DBG: keygrip= C5 A4 75 9F 78 43 21 40 44 66 AC A9 47 12 E4 F8 B5 A8 8B 02
| gpg: DBG: chan_0x00000094 -> RESET
| gpg: DBG: chan_0x00000094 <- OK
| gpg: DBG: chan_0x00000094 -> SIGKEY C5A4759F784321404466ACA94712E4F8B5A88B02
| gpg: DBG: chan_0x00000094 <- OK
| gpg: DBG: chan_0x00000094 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Gpg+Test+<gpgtest at nym.mixmin.net>%22%0A2048-bit+RSA+key,+ID+C738D5E556AFC7CE,%0Acreated+2016-11-24.%0A
| gpg: DBG: chan_0x00000094 <- OK
| gpg: DBG: chan_0x00000094 -> SETHASH 8 F682A7CB5487904584DC35C490D25ADE02BB223877C39C0398C49077E54EE6E9
| gpg: DBG: chan_0x00000094 <- OK
| gpg: DBG: chan_0x00000094 -> PKSIGN -- 071F0B591589B1AE96E29326
| gpg: DBG: chan_0x00000094 <- S INQUIRE_MAXLEN 255
| gpg: DBG: chan_0x00000094 <- INQUIRE PASSPHRASE
| [GNUPG:] USERID_HINT C738D5E556AFC7CE Gpg Test <gpgtest at nym.mixmin.net>
| [GNUPG:] NEED_PASSPHRASE C738D5E556AFC7CE C738D5E556AFC7CE 1 0
| [GNUPG:] INQUIRE_MAXLEN 100
| gpg: Sorry, we are in batchmode - can't get input

vs.

| gpg: DBG: get_keygrip for public key
| gpg: DBG: keygrip= A5 82 DC 7B 32 E2 1A 79 82 9F 57 F7 A9 1B 2F 96 15 FB 43 C2
| gpg: DBG: chan_0x00000094 -> RESET
| gpg: DBG: chan_0x00000094 <- OK
| gpg: DBG: chan_0x00000094 -> SIGKEY A582DC7B32E21A79829F57F7A91B2F9615FB43C2
| gpg: DBG: chan_0x00000094 <- OK
| gpg: DBG: chan_0x00000094 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Gpg+Test+<gpgtest at nym.mixmin.net>%22%0A2048-bit+RSA+key,+ID+682B479F1A75E8C3,%0Acreated+2016-11-24.%0A
| gpg: DBG: chan_0x00000094 <- OK
| gpg: DBG: chan_0x00000094 -> SETHASH 8 657C84AFB05669CA8CD7721FFD634C4226C601311453F9E5667B747F75894F38
| gpg: DBG: chan_0x00000094 <- OK
| gpg: DBG: chan_0x00000094 -> PKSIGN -- 744E5829E93B414D3221D01E
| gpg: DBG: chan_00000094 <- [ 44 20 28 37 3a 73 69 67 2d 76 61 6c 28 33 3a 72 ...(273 byte(s) skipped) ]
| gpg: DBG: chan_0x00000094 <- OK
| gpg: DBG: build_packet() type=2
| gpg: DBG: iobuf-7.0: close '?'
| gpg: DBG: armor-filter: control: 4
| gpg: DBG: armor-filter: control: 5
| gpg: DBG: iobuf-6.1: close 'armor_filter'
| gpg: DBG: armor-filter: control: 2
| gpg: DBG: iobuf-6.0: close 'file_filter(fd)'
| gpg: DBG: G:/mob/Mail/MyGnuPG/gpg/openpgp-revocs.d\81A7B5FA786C103986170348682B479F1A75E8C3.rev: close fd/handle 176
| gpg: DBG: fd_cache_close (176) real
| gpg: revocation certificate stored as 'G:/mob/Mail/MyGnuPG/gpg/openpgp-revocs.d\81A7B5FA786C103986170348682B479F1A75E8C3.rev'
| [GNUPG:] KEY_CREATED P 81A7B5FA786C103986170348682B479F1A75E8C3
| gpg: DBG: free_packet() type=6
| gpg: DBG: free_packet() type=13
| gpg: DBG: free_packet() type=2
| gpg: DBG: iobuf-1.0: close '?'
| gpg: DBG: [not enabled in the source] stop
| gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
|               outmix=0 getlvl1=0/0 getlvl2=0/0
| gpg: secmem usage: 0/32768 bytes in 0 blocks

I attached .exe i/o data of erroneous (gpg_cmd_ko.log) and normal
processing (gpg_cmd_ok.log) as well as the respective --gen-key file.

Kind regards

Caro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpg_cmd_ko.log
Type: application/octet-stream
Size: 12923 bytes
Desc: not available
URL: </pipermail/attachments/20161129/79cdc246/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpg_cmd_ok.log
Type: application/octet-stream
Size: 13345 bytes
Desc: not available
URL: </pipermail/attachments/20161129/79cdc246/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: key_gen.cfg
Type: application/octet-stream
Size: 293 bytes
Desc: not available
URL: </pipermail/attachments/20161129/79cdc246/attachment-0005.obj>

From dkg at fifthhorseman.net  Wed Nov 30 07:26:05 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 30 Nov 2016 01:26:05 -0500
Subject: gpgme 1.8.0 released
In-Reply-To: <87inrnvaia.fsf@wheatstone.g10code.de>
References: <87inrnvaia.fsf@wheatstone.g10code.de>
Message-ID: <87h96pzdoi.fsf@alice.fifthhorseman.net>

On Wed 2016-11-16 08:07:25 -0500, Werner Koch wrote:
> Noteworthy changes in version 1.8.0 (2016-11-16)
> ------------------------------------------------
>
>  * The module of the Python bindings has been renamed to 'gpg'.

I note that https://pypi.python.org/pypi/gpg still only shows
1.7.2-beta7.  Can Someone? upload 1.8.0 to PyPI?

More generally, it would be great to have upload to PyPI be part of the
release process, so that it's always kept up-to-date there.

Thanks for this release, i'm quite glad to have it in debian now.

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20161130/66e412f2/attachment.sig>

From muelli at cryptobitch.de  Wed Nov 30 08:47:29 2016
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Wed, 30 Nov 2016 08:47:29 +0100
Subject: [PATCH] python: Make Results have a nicer __repr__.
Message-ID: <1480492049.15252.4.camel@cryptobitch.de>

* lang/python/gpg/results.py (Result.__str__): Renamed to '__repr__' ...
* lang/python/gpg/results.py (Result.__repr__): ... and added fields
--

So that it looks a bit nicer in the Python REPL.

It looked like this before:

In [2]: gpg.core.get_engine_info()[0]
Out[2]:
<gpg.results.EngineInfo at 0x7fb23509a240>

Now the output is

In [2]: gpg.core.get_engine_info()[0]
Out[2]:
EngineInfo(file_name='/usr/bin/gpg2', home_dir=None,
protocol=0, req_version='1.4.0', version='2.1.11')

This also applies to other results, e.g. the ImportResult.

Note that the format now changed from "<Class >" to "Class()". The
Python documentation on repr states: "For many object types, including
most builtins, eval(repr(obj)) == obj."

Signed-off-by: Tobias Mueller <muelli at cryptobitch.de>
---
 lang/python/gpg/results.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lang/python/gpg/results.py b/lang/python/gpg/results.py
index 3383896..46ebeec 100644
--- a/lang/python/gpg/results.py
+++ b/lang/python/gpg/results.py
@@ -64,10 +64,10 @@ class Result(object):
 
             setattr(self, key, getattr(fragile, key))
 
-    def __str__(self):
-        return '<{} {}>'.format(
+    def __repr__(self):
+        return '{}({})'.format(
             self.__class__.__name__,
-            ', '.join('{}: {}'.format(k, getattr(self, k))
+            ', '.join('{}={!r}'.format(k, getattr(self, k))
                       for k in dir(self) if not k.startswith('_')))
 
 class InvalidKey(Result):
-- 
2.7.4


From justus at g10code.com  Wed Nov 30 10:48:32 2016
From: justus at g10code.com (Justus Winter)
Date: Wed, 30 Nov 2016 10:48:32 +0100
Subject: gpgme 1.8.0 released
In-Reply-To: <87h96pzdoi.fsf@alice.fifthhorseman.net>
References: <87inrnvaia.fsf@wheatstone.g10code.de>
 <87h96pzdoi.fsf@alice.fifthhorseman.net>
Message-ID: <87y401b8nj.fsf@europa.jade-hamburg.de>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> [ Unknown signature status ]
> On Wed 2016-11-16 08:07:25 -0500, Werner Koch wrote:
>> Noteworthy changes in version 1.8.0 (2016-11-16)
>> ------------------------------------------------
>>
>>  * The module of the Python bindings has been renamed to 'gpg'.
>
> I note that https://pypi.python.org/pypi/gpg still only shows
> 1.7.2-beta7.  Can Someone? upload 1.8.0 to PyPI?

Yes, that Someone is me, and I just did that.

> More generally, it would be great to have upload to PyPI be part of the
> release process, so that it's always kept up-to-date there.

Indeed.  For the record, the way to do that is just:

% git checkout gpgme-1.8.0
% ./autogen.sh
% mkdir obj-py-1.8.0
% cd obj-py-1.8.0
% ../configure --enable-maintainer-mode
% make -Clang/python sdist
% make -Clang/python upload

This needs a pypi account, twine, twine configuration, and of course
permissions to upload to that project.


Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20161130/56a9f68c/attachment.sig>

From wk at gnupg.org  Wed Nov 30 11:15:18 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 30 Nov 2016 11:15:18 +0100
Subject: gpgme 1.8.0 released
In-Reply-To: <87y401b8nj.fsf@europa.jade-hamburg.de> (Justus Winter's message
 of "Wed, 30 Nov 2016 10:48:32 +0100")
References: <87inrnvaia.fsf@wheatstone.g10code.de>
 <87h96pzdoi.fsf@alice.fifthhorseman.net>
 <87y401b8nj.fsf@europa.jade-hamburg.de>
Message-ID: <87k2bl6zpl.fsf@wheatstone.g10code.de>

On Wed, 30 Nov 2016 10:48, justus at g10code.com said:

> % git checkout gpgme-1.8.0
> % ./autogen.sh

I would suggest to do this from the released tarball and not from the repo.

> This needs a pypi account, twine, twine configuration, and of course
> permissions to upload to that project.

A make rule will be helpful here, although only you will right now be
able to upload it.  For example to upload the gpgme manual we have this
rule in gpgme/doc/Makefile

online: gpgme.html gpgme.pdf
	set -e; \
	echo "Uploading current manuals to www.gnupg.org ..."; \
        user=werner ; \
	(cd gpgme.html && rsync -vr --exclude='.svn' .  \
	  $${user}@ftp.gnupg.org:webspace/manuals/gpgme/ ); \
        rsync -v gpgme.pdf $${user}@ftp.gnupg.org:webspace/manuals/

and I use that from the build done from the released tarball.  It is
configured for me but anyone with the required permissions can easily
adjust this.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161130/2565f929/attachment.sig>

From justus at g10code.com  Wed Nov 30 11:35:54 2016
From: justus at g10code.com (Justus Winter)
Date: Wed, 30 Nov 2016 11:35:54 +0100
Subject: gpgme 1.8.0 released
In-Reply-To: <87k2bl6zpl.fsf@wheatstone.g10code.de>
References: <87inrnvaia.fsf@wheatstone.g10code.de>
 <87h96pzdoi.fsf@alice.fifthhorseman.net>
 <87y401b8nj.fsf@europa.jade-hamburg.de>
 <87k2bl6zpl.fsf@wheatstone.g10code.de>
Message-ID: <87shq9b6gl.fsf@europa.jade-hamburg.de>

Werner Koch <wk at gnupg.org> writes:

> [ Unknown signature status ]
> On Wed, 30 Nov 2016 10:48, justus at g10code.com said:
>
>> % git checkout gpgme-1.8.0
>> % ./autogen.sh
>
> I would suggest to do this from the released tarball and not from the repo.

Indeed.

>> This needs a pypi account, twine, twine configuration, and of course
>> permissions to upload to that project.
>
> A make rule will be helpful here,

I don't follow.  I created a make rule (ok, two, but that is nice
because one can inspect the pypi package before uploading).

Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20161130/204ba9a8/attachment.sig>

From lists at ssl-mail.com  Wed Nov 30 20:59:55 2016
From: lists at ssl-mail.com (lists at ssl-mail.com)
Date: Wed, 30 Nov 2016 11:59:55 -0800
Subject: gpg 2.1.x can't retrieve any keys from any keyservers, gpg 2.0.x can ?
In-Reply-To: <1479649810.2163132.793655281.228031F8@webmail.messagingengine.com>
References: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
 <878tsgfhq6.fsf@alice.fifthhorseman.net>
 <1479528712.4167275.792800985.20E5A953@webmail.messagingengine.com>
 <1479646557.2155810.793629113.7C0AC3AC@webmail.messagingengine.com>
 <1479649810.2163132.793655281.228031F8@webmail.messagingengine.com>
Message-ID: <1480535995.656378.804159785.1CCB7F55@webmail.messagingengine.com>

Today's the day i've been told to 'fish or cut bait' re: GPG 2.1+ . So one last hail-mary pass at it ...

Getting any keys, e.g Google GPG keys, with GPG2 2.0.24 works OK,

gpg --version
	gpg: WARNING: unsafe ownership on configuration file `/root/.gnupg/gpg.conf'
	gpg (GnuPG) 2.0.24
	libgcrypt 1.7.3
	Copyright (C) 2013 Free Software Foundation, Inc.
	License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
	This is free software: you are free to change and redistribute it.
	There is NO WARRANTY, to the extent permitted by law.

	Home: ~/.gnupg
	Supported algorithms:
	Pubkey: RSA, RSA, RSA, ELG, DSA
	Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
	        CAMELLIA128, CAMELLIA192, CAMELLIA256
	Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
	Compression: Uncompressed, ZIP, ZLIB, BZIP2


gpg -v --keyserver pgp.mit.edu --recv-keys 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991
	gpg: requesting key 0xA040830F7FAC5991 from hkp server pgp.mit.edu
	Version: SKS 1.1.5
	gpg: armor header:
	Comment: Hostname: pgp.mit.edu
	gpg: armor header:
	gpg: pub  1024D/0xA040830F7FAC5991 2007-03-08  Google, Inc. Linux Package Signing Key <linux-packages-keymaster at google.com>
	gpg: using PGP trust model
	gpg: key 0xA040830F7FAC5991: public key "Google, Inc. Linux Package Signing Key <linux-packages-keymaster at google.com>" imported
	gpg: 29 keys cached (920 signatures)
	gpg: 0 keys processed (0 validity counts cleared)
	gpg: no ultimately trusted keys found
	gpg: Total number processed: 1
	gpg:               imported: 1

After an upgrade from 2.0.24 > 2.1.16 I can't retrieve keys anymore.

gpg --version
	gpg (GnuPG) 2.1.16
	libgcrypt 1.7.3
	Copyright (C) 2016 Free Software Foundation, Inc.
	License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
	This is free software: you are free to change and redistribute it.
	There is NO WARRANTY, to the extent permitted by law.

	Home: /root/.gnupg
	Supported algorithms:
	Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
	Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
	        CAMELLIA128, CAMELLIA192, CAMELLIA256
	Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
	Compression: Uncompressed, ZIP, ZLIB, BZIP2

gpg -v --keyserver pgp.mit.edu --recv-keys 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991
	gpg: keyserver receive failed: No keyserver available


This happens on all our machines I've tried; so far, ~ 20 in 7 different locations. 
This happens with any & all keyservers & protocols.  

I've responded here, and it just gets dropped.  I've filed a bug, and it gets no further action.  That's all cool, it's "free", and obviously not my app. 

Kinof hoped somebody would be interested since it clearly works in 2.0, but not 2.1.


From peter at digitalbrains.com  Wed Nov 30 22:05:21 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 30 Nov 2016 22:05:21 +0100
Subject: gpg 2.1.x can't retrieve any keys from any keyservers, gpg 2.0.x
 can ?
In-Reply-To: <1480535995.656378.804159785.1CCB7F55@webmail.messagingengine.com>
References: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
 <878tsgfhq6.fsf@alice.fifthhorseman.net>
 <1479528712.4167275.792800985.20E5A953@webmail.messagingengine.com>
 <1479646557.2155810.793629113.7C0AC3AC@webmail.messagingengine.com>
 <1479649810.2163132.793655281.228031F8@webmail.messagingengine.com>
 <1480535995.656378.804159785.1CCB7F55@webmail.messagingengine.com>
Message-ID: <303a314e-088c-90c3-f3ea-9670accc15f7@digitalbrains.com>

On 30/11/16 20:59, lists at ssl-mail.com wrote:
> I've responded here, and it just gets dropped.  I've filed a bug, and
> it gets no further action.  That's all cool, it's "free", and
> obviously not my app.

Well, nobody could reproduce your issue. It works fine for everybody who
looked at it. And you indicated you needed more help to attach to the
process and use a debugger, but that is not an easily answered question.

Globally, it would be something like you run dirmngr in the GNU Debugger
(gdb) and put breakpoints in the functions Daniel mentioned (at least
that's loosely how I interpreted it), step through the code and check
why your systems, for whatever reason, do different stuff there than the
machines of people who tried to help seem to use. However, if you're not
acquainted with debugging C code in this way, it's not an easy thing to
explain, and since you're not paying anybody, they have to do it in
their spare time.

Obviously you could also pay for support, in that case somebody would
look at it for you. g10 Code for instance offers paid support for GnuPG,
but there are more parties providing paid support.

I would not say it "got dropped" or "got no further action". You were
asked for more details, but had problems providing them, asking how to
do this. Then, it did get a bit quiet, because it's not as simple as
"please press this button and tell us what the screen output is".

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From lists at ssl-mail.com  Wed Nov 30 22:13:05 2016
From: lists at ssl-mail.com (lists at ssl-mail.com)
Date: Wed, 30 Nov 2016 13:13:05 -0800
Subject: gpg 2.1.x can't retrieve any keys from any keyservers,
 gpg 2.0.x can ?
In-Reply-To: <303a314e-088c-90c3-f3ea-9670accc15f7@digitalbrains.com>
References: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
 <878tsgfhq6.fsf@alice.fifthhorseman.net>
 <1479528712.4167275.792800985.20E5A953@webmail.messagingengine.com>
 <1479646557.2155810.793629113.7C0AC3AC@webmail.messagingengine.com>
 <1479649810.2163132.793655281.228031F8@webmail.messagingengine.com>
 <1480535995.656378.804159785.1CCB7F55@webmail.messagingengine.com>
 <303a314e-088c-90c3-f3ea-9670accc15f7@digitalbrains.com>
Message-ID: <1480540385.673917.804238009.2234E763@webmail.messagingengine.com>

As I started off:  it's a 'free' app.  

The project wants help from users, but when 'we' do, there's the same old mantra about money ...

Payment & spare-time cut both ways.

So saving everyone -- myself incldued -- any further valuable time & effort, I'll ACK that the 'hail-mary' failed, simply remove / block 2.1.x for my users/clients, and move on.

Thanks all.  Later.


From peter at digitalbrains.com  Wed Nov 30 22:21:59 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 30 Nov 2016 22:21:59 +0100
Subject: gpg 2.1.x can't retrieve any keys from any keyservers, gpg 2.0.x
 can ?
In-Reply-To: <303a314e-088c-90c3-f3ea-9670accc15f7@digitalbrains.com>
References: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
 <878tsgfhq6.fsf@alice.fifthhorseman.net>
 <1479528712.4167275.792800985.20E5A953@webmail.messagingengine.com>
 <1479646557.2155810.793629113.7C0AC3AC@webmail.messagingengine.com>
 <1479649810.2163132.793655281.228031F8@webmail.messagingengine.com>
 <1480535995.656378.804159785.1CCB7F55@webmail.messagingengine.com>
 <303a314e-088c-90c3-f3ea-9670accc15f7@digitalbrains.com>
Message-ID: <30a89a4d-9901-b219-d859-e47428c7fc9f@digitalbrains.com>

On 30/11/16 22:05, Peter Lebbing wrote:
> Obviously you could also pay for support, in that case somebody would
> look at it for you.

Upon reading it back, I notice that the intended meaning very much
depends on the reader putting the correct inflection in the sentence.

What I meant is, if you payed someone, maybe they could work more
directly with you over phone, video chat or SSH, and look at it. Do it
for you rather than that you had to do most of it yourself.

But since this stress on the word "for" is lost in written words, it
easily reads as "if only you would pay, then somebody would look at it".
That is definitely not how I meant it!

I myself don't give paid support, and I wouldn't feel qualified enough
to ask money for it anyway!

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From peter at digitalbrains.com  Wed Nov 30 22:48:02 2016
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 30 Nov 2016 22:48:02 +0100
Subject: gpg 2.1.x can't retrieve any keys from any keyservers, gpg 2.0.x
 can ?
In-Reply-To: <1480540385.673917.804238009.2234E763@webmail.messagingengine.com>
References: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
 <878tsgfhq6.fsf@alice.fifthhorseman.net>
 <1479528712.4167275.792800985.20E5A953@webmail.messagingengine.com>
 <1479646557.2155810.793629113.7C0AC3AC@webmail.messagingengine.com>
 <1479649810.2163132.793655281.228031F8@webmail.messagingengine.com>
 <1480535995.656378.804159785.1CCB7F55@webmail.messagingengine.com>
 <303a314e-088c-90c3-f3ea-9670accc15f7@digitalbrains.com>
 <1480540385.673917.804238009.2234E763@webmail.messagingengine.com>
Message-ID: <8cabfe27-ca99-c16a-2d7d-00ffa9fb5266@digitalbrains.com>

On 30/11/16 22:13, lists at ssl-mail.com wrote:
> The project wants help from users, but when 'we' do, there's the same old mantra about money ...

Is this due to the unfortunate way I phrased that sentence? I'm sorry if
I offended you by putting it so awkwardly. When you type a sentence, you
hear it in your head, with its intended inflection. You don't always
notice what is lost when only the written word gets across.

However, any help you /offered/ was very abstract, I have to say. Nobody
has come forward with this problem before, as far as I know you're the
only one having this issue. The help would be that if the situation is
understood and dealt with, nobody else will in the future encounter this
specific problem.

It seems to me you were asking for help, not giving help. So I get a bit
of a nasty taste in my mouth when you describe a project I hold dear[1]
in the way you just did. I think it is undeserved. Not in the last place
that if I prompted that statement, it shouldn't reflect on the GnuPG
project, me not being involved and such.

I'm sorry you couldn't get your problem fixed.

Cheers,

Peter.

[1] I'm just a hobbyist interested in the subject and the software, I
don't work on or with GnuPG professionally.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From muelli at cryptobitch.de  Wed Nov 30 23:08:47 2016
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Wed, 30 Nov 2016 23:08:47 +0100
Subject: [PATCH] python: Check "buffer" when writing to sys.stdout for
 python2 compat.
Message-ID: <20161130220847.GA27907@cryptobitch.de>

* lang/python/tests/support.py (print_data): added buffer check
--

When running with something like make -C lang/python check verbose=2 the
test would fail under python2, because the file objects do not have a
buffer property.

Signed-off-by: Tobias Mueller <muelli at cryptobitch.de>
---
 lang/python/tests/support.py | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lang/python/tests/support.py b/lang/python/tests/support.py
index f991c6d..0b04bb6 100644
--- a/lang/python/tests/support.py
+++ b/lang/python/tests/support.py
@@ -48,7 +48,11 @@ def print_data(data):
         except:
             # Hope for the best.
             pass
-        sys.stdout.buffer.write(data)
+
+        if hasattr(sys.stdout, "buffer"):
+            sys.stdout.buffer.write(data)
+        else:
+            sys.stdout.write(data)
 
 def mark_key_trusted(ctx, key):
     class Editor(object):
-- 
2.7.4


From wk at gnupg.org  Wed Nov 30 23:37:40 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 30 Nov 2016 23:37:40 +0100
Subject: gpg 2.1.x can't retrieve any keys from any keyservers,
 gpg 2.0.x can ?
In-Reply-To: <1480535995.656378.804159785.1CCB7F55@webmail.messagingengine.com>
 (lists@ssl-mail.com's message of "Wed, 30 Nov 2016 11:59:55 -0800")
References: <1478875513.717010.784733545.2B20AE92@webmail.messagingengine.com>
 <878tsgfhq6.fsf@alice.fifthhorseman.net>
 <1479528712.4167275.792800985.20E5A953@webmail.messagingengine.com>
 <1479646557.2155810.793629113.7C0AC3AC@webmail.messagingengine.com>
 <1479649810.2163132.793655281.228031F8@webmail.messagingengine.com>
 <1480535995.656378.804159785.1CCB7F55@webmail.messagingengine.com>
Message-ID: <8737i861cb.fsf@wheatstone.g10code.de>

On Wed, 30 Nov 2016 20:59, lists at ssl-mail.com said:

> gpg -v --keyserver pgp.mit.edu --recv-keys 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991
> 	gpg: keyserver receive failed: No keyserver available
>

Did you install dirmmngr and can gpg access dirmmgr?   Best try do
connect directly to dirmngr:

  gpg-connect-agent --dirmngr -v
  > keyserver hkp://pgp.mit.edu
  > ks_get 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991

Do you see 'D ' lines with the kext data and does it return OK?

If this all works, try the gpg command again but add the option
  --debug ipc
to show the communication between gpg and dirmngr,

Note that the keyserver helper tools from 2.0 have been replaced by the
dirmngr daemon,


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161130/4516c996/attachment.sig>