From jeroen at berkeley.edu  Wed Jan  2 22:17:33 2019
From: jeroen at berkeley.edu (Jeroen Ooms)
Date: Wed, 2 Jan 2019 22:17:33 +0100
Subject: gpgme_op_delete() does not work with gpg 2.x
In-Reply-To: <d992f33e-fdac-5067-32cb-383078f716b6@square-r00t.net>
References: <CABFfbXsXcMJ=P8n8_XKk=DCuxd2iNvHi54R8KusgEPAjZOfV8w@mail.gmail.com>
 <d992f33e-fdac-5067-32cb-383078f716b6@square-r00t.net>
Message-ID: <CABFfbXuF4KGZxP5Wef9m4u5Y7qr0f2kDDUH0poamL87yEc2JBQ@mail.gmail.com>

On Sat, Dec 29, 2018 at 5:01 PM brent s. <bts at square-r00t.net> wrote:
>
> On 12/29/18 9:01 AM, Jeroen Ooms wrote:
> > A user of the R bindings has reported (and I have confirmed) that
> > deleting secret keys in gpgme does not work with gnupg2. We call (on
> > an existing key):
> >
> >   gpgme_op_delete(ctx, key, 1)
> >
> > This returns success if the key exists, and when we are running with
> > GnuPG 1.4 the key is deleted. However when running gpg2 it returns
> > success but the key is still there.
> >
> > Downstream issue: https://github.com/jeroen/gpg/issues/3
> >
> > _______________________________________________
> > Gnupg-devel mailing list
> > Gnupg-devel at gnupg.org
> > http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> >
>
> I'm not sure how much this will help you, but deleting a private key
> works in the Python bindings if I use the abstracted method but not the
> direct gpgme method (see attached POC).

So which C function does the latter use then? I don't use python but
to me it looks like both those methods are different syntax for the
same thing? Why would they show different behavior?


> Haven't taken a look at the R bindings; is there a similar
> context-specific method there?

I maintain these bindings so I can add it a working implementation if
I know which C API to call.


From bts at square-r00t.net  Wed Jan  2 23:34:31 2019
From: bts at square-r00t.net (brent s.)
Date: Wed, 2 Jan 2019 17:34:31 -0500
Subject: gpgme_op_delete() does not work with gpg 2.x
In-Reply-To: <CABFfbXuF4KGZxP5Wef9m4u5Y7qr0f2kDDUH0poamL87yEc2JBQ@mail.gmail.com>
References: <CABFfbXsXcMJ=P8n8_XKk=DCuxd2iNvHi54R8KusgEPAjZOfV8w@mail.gmail.com>
 <d992f33e-fdac-5067-32cb-383078f716b6@square-r00t.net>
 <CABFfbXuF4KGZxP5Wef9m4u5Y7qr0f2kDDUH0poamL87yEc2JBQ@mail.gmail.com>
Message-ID: <ed2620ae-0144-7d65-9f71-d76f00378548@square-r00t.net>

On 1/2/19 4:17 PM, Jeroen Ooms wrote:
>> I'm not sure how much this will help you, but deleting a private key
>> works in the Python bindings if I use the abstracted method but not the
>> direct gpgme method (see attached POC).
> 
> So which C function does the latter use then? I don't use python but
> to me it looks like both those methods are different syntax for the
> same thing? Why would they show different behavior?
> 

I don't know much about the bindings themselves other than they're
generated (mostly?) automatically via SWIG[0]. However, the former
method (gpgme.gpgme_op_delete()) is, I believe, the direct SWIG method
and the latter Context class method (gpg.Context().op_delete()) is
inherited somehow from it (as I don't see an actual separate
.op_delete() method defined anywhere in the library).

SWIG does support R, it looks like[1] so you may be able to create the R
bindings in much the same way (while even reusing many of the parts for
python[2]).


Based on git commit history, I'd try to see if you can get in touch with
Ben McGinnes[3]; he should be able to answer your question with much
more clarity, I'd imagine. Sorry I wasn't much more help!




[0] http://www.swig.org/
[1] http://www.swig.org/Doc1.3/R.html
[2]
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=tree;f=lang/python
[3] You can get his email address by cloning the gpgme git repo and running:

  git shortlog -nes -- lang/python

or just getting it from the gitweb interface.

(not pasting the email addresses here in case there are harvesting
spiders for spammers)

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190102/24c9e2bf/attachment.sig>

From rainer.perske at uni-muenster.de  Thu Jan  3 02:04:38 2019
From: rainer.perske at uni-muenster.de (Rainer Perske)
Date: Thu, 03 Jan 2019 02:04:38 +0100 (CET)
Subject: Most efficient way to look whether a secret key is for X.509 or for
 OpenPGP
Message-ID: <permail-201901030104388218e1ae000029fa-perske@message-id.uni-muenster.de>

Hello,

I use gpgsm and gpg2 concurrently. I can quickly and easily see whether
there are private keys in gnupghome/private-keys-v1.d/. But I cannot
easily see whether these keys belong to X.509 key pairs or to OpenPGP
key pairs.

For my application, I need to know:

a) What is the fastest way to detect whether I have a private X.509
   key? I need a simple boolean answer: yes or no.

   The response time of ? gpgsm --list-secret-key ? is .4 seconds, that
   is far too long.

b) What is the fastest way to detect whether I have a private OpenPGP
   key? I need a simple boolean answer: yes or no.

   The response time of ? gpg2 --list-secret-key ? is .4 seconds, that
   is far too long.

c) What is the fastest way to detect whether a private key in
   gnupghome/private-keys-v1.d/ belongs to an X.509 key and/or to an 
   OpenPGP key? I need a simple answer: X.509-only, OpenPGP-only or 
   both.

   The response time of ? gpgsm --list-secret-key '&'${filename%.key} ?
   and ? gpg2 --with-keygrip --list-secret-key | grep ${filename%.key}
   ? is 1 second, that is far too long

(My application needs these responses very quickly without any visible
delay. There is no time to wait for startup of gpg-agent, dirmngr or
any other daemon first. Perhaps there is already any indicator in the 
.key file?)

Best regards
-- 
Rainer Perske
Abteilung Systembetrieb und Leiter der Zertifizierungsstelle (WWUCA)
Zentrum f?r Informationsverarbeitung (Universit?tsrechenzentrum)

Westf?lische Wilhelms-Universit?t
Zentrum f?r Informationsverarbeitung
Rainer Perske
R?ntgenstra?e 7-13
48149 M?nster

Tel.: +49 251 83-31582
Fax.: +49 251 83-31555
E-Mail: rainer.perske at uni-muenster.de
WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml
B?ro: Raum 006, R?ntgenstra?e 11
Lageplan: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474

Zertifizierungsstelle der Universit?t M?nster (WWUCA):
Tel.: +49 251 83-31590
Fax.: +49 251 83-31555
E-Mail: ca at uni-muenster.de
WWW: https://www.uni-muenster.de/WWUCA/

Zentrum f?r Informationsverarbeitung (ZIV):
Tel.: +49 251 83-31600 (Mo-Fr 7:30-17:30 Uhr)
Fax.: +49 251 83-31555
E-Mail: ziv at uni-muenster.de
WWW: https://www.uni-muenster.de/ZIV/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6807 bytes
Desc: S/MIME cryptographic signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190103/552ee1f3/attachment.bin>

From jeroen at berkeley.edu  Thu Jan  3 16:51:08 2019
From: jeroen at berkeley.edu (Jeroen Ooms)
Date: Thu, 3 Jan 2019 16:51:08 +0100
Subject: Is gpgme_set_passphrase_cb effectively deprecated?
Message-ID: <CABFfbXuNoe7=8iLUx+g7JN3a=FxwbCL-cMzFt1y2L=Bfjv0r0Q@mail.gmail.com>

I maintain the gpgme bindings for the R programming language, and we
use a have a custom password entry dialog in the GUI application.
IIRC, the following code used to work about 2 or 3 years ago:

  gpgme_set_pinentry_mode(ctx, GPGME_PINENTRY_MODE_LOOPBACK);
  gpgme_set_passphrase_cb(ctx, cb_fun, payload);

However I tried this with gpgme 1.11 (Windows) and 1.12 (MacOS), and
this does not seem to work anymore at all. The cb_fun is never
invoked, neither with gpg 1.4 nor gpg 2.2.

Some old posts on this mailing lists suggest that this is expected
because not all versions of gpg support loopback, but I am not sure if
this info is up to date.

Also the documentation for gpgme_set_passphrase_cb says "Some engines
do not even support an external passphrase callback at all, in this
case the error code GPG_ERR_NOT_SUPPORTED is returned" however the
function returns void so this seems incorrect.

I was wondering if it is possible to update the
gpgme_set_passphrase_cb documentation on the current situation, which
versions of gnupg it is expected to work, under which
conditions/settings.


From ced at cyberbits.eu  Sat Jan  5 09:47:49 2019
From: ced at cyberbits.eu (ced at cyberbits.eu)
Date: Sat, 5 Jan 2019 08:47:49 +0000
Subject: New mirror: mirror.cyberbits.eu
Message-ID: <221ebf59-7a83-9921-ddab-a10e19afd6eb@cyberbits.eu>

Hi,

I've set up a new gnupg.org mirror.

The website is mirrored at <https://mirror.cyberbits.eu/gnupg.org/> and
the FTP is at <https://mirror.cyberbits.eu/gnupg.org/ftp/>

I sync every 6 hours on a random minute from rsync://ftp.gnupg.org/

I noticed that most mirrors listed at
<https://gnupg.org/download/mirrors.html> are no longer maintained so
this may need some spring cleaning.

Moreover, many links/paths on the website start with a slash (/) and
since I'm hosting the website in a sub-directory, they end up in 404s.
Ideally all links/paths should be made relative (similarly to what
torproject.org does). As a temporary workaround, I do some dirty
post-processing to fix them:

> find .../gnupg.org/ -name '*.html' \
>      -exec sed -ri 's:(href|src)="/:\1="/gnupg.org/:g' {} \;

Hopefully this is the right place to post this - please point me to the
appropriate mailing list if not.

Thank you,
C?dric

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190105/94f7ae82/attachment.sig>

From smueller at chronox.de  Sat Jan  5 12:11:22 2019
From: smueller at chronox.de (Stephan Mueller)
Date: Sat, 05 Jan 2019 12:11:22 +0100
Subject: [PATCH GnuPG] gpg: expand GPG groups when resolving a key
Message-ID: <1876530.vRkGqGgpGy@tauon.chronox.de>

* g10/expand_group.c: New
* g10/pkclist.c: Extract expand_group and expand_id into expand_group.c
* g10/keydb.h: Add prototypes of expand_id and expand_group
* g10/getkey.c: Use expand_group before resolving key references
* g10/Makefile.am: Compile expand_group.c
--

When searching a key by its name, try to expand the provided name in
case it is a GPG group reference. This GPG group resolution is performed
before the individual keys are verified.

This allows key listing using a GPG group reference. In particular, this
modification fixes the encryption to group support in KDE's Kmail which
is broken since version 18.08.

Signed-off-by: Stephan Mueller <smueller at chronox.de>
---
 g10/Makefile.am    |  1 +
 g10/expand_group.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++
 g10/getkey.c       | 15 ++++++----
 g10/keydb.h        |  2 ++
 g10/pkclist.c      | 49 -------------------------------
 5 files changed, 86 insertions(+), 54 deletions(-)
 create mode 100644 g10/expand_group.c

diff --git a/g10/Makefile.am b/g10/Makefile.am
index 3b4464364..63a42aba5 100644
--- a/g10/Makefile.am
+++ b/g10/Makefile.am
@@ -99,6 +99,7 @@ common_source =  \
 	      filter.h		\
 	      free-packet.c	\
 	      getkey.c		\
+	      expand_group.c	\
 	      keydb.c keydb.h    \
 	      keyring.c keyring.h \
 	      seskey.c		\
diff --git a/g10/expand_group.c b/g10/expand_group.c
new file mode 100644
index 000000000..310daa944
--- /dev/null
+++ b/g10/expand_group.c
@@ -0,0 +1,73 @@
+/* expand_group.c - expand GPG group definitions
+ * Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
+ *               2008, 2009, 2010 Free Software Foundation, Inc.
+ *
+ * This file is part of GnuPG.
+ *
+ * GnuPG is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GnuPG 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 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 <https://www.gnu.org/licenses/>.
+ */
+
+#include <config.h>
+
+#include "gpg.h"
+#include "options.h"
+#include "keydb.h"
+
+int
+expand_id(const char *id,strlist_t *into,unsigned int flags)
+{
+  struct groupitem *groups;
+  int count=0;
+
+  for(groups=opt.grouplist;groups;groups=groups->next)
+    {
+      /* need strcasecmp() here, as this should be localized */
+      if(strcasecmp(groups->name,id)==0)
+	{
+	  strlist_t each,sl;
+
+	  /* this maintains the current utf8-ness */
+	  for(each=groups->values;each;each=each->next)
+	    {
+	      sl=add_to_strlist(into,each->d);
+	      sl->flags=flags;
+	      count++;
+	    }
+
+	  break;
+	}
+    }
+
+  return count;
+}
+
+/* For simplicity, and to avoid potential loops, we only expand once -
+ * you can't make an alias that points to an alias.  */
+strlist_t
+expand_group (strlist_t input)
+{
+  strlist_t output = NULL;
+  strlist_t sl, rover;
+
+  for (rover = input; rover; rover = rover->next)
+    if (!(rover->flags & PK_LIST_FROM_FILE)
+        && !expand_id(rover->d,&output,rover->flags))
+      {
+	/* Didn't find any groups, so use the existing string */
+	sl=add_to_strlist(&output,rover->d);
+	sl->flags=rover->flags;
+      }
+
+  return output;
+}
diff --git a/g10/getkey.c b/g10/getkey.c
index 08e17e930..fb07937dd 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1098,7 +1098,7 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist,
 {
   int rc = 0;
   int n;
-  strlist_t r;
+  strlist_t r, namelist_expanded = NULL;
   GETKEY_CTX ctx;
   KBNODE help_kb = NULL;
   KBNODE found_key = NULL;
@@ -1127,8 +1127,9 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist,
     }
   else
     {
+      namelist_expanded = expand_group (namelist);
       /* Build the search context.  */
-      for (n = 0, r = namelist; r; r = r->next)
+      for (n = 0, r = namelist_expanded; r; r = r->next)
 	n++;
 
       /* CTX has space for a single search term at the end.  Thus, we
@@ -1137,7 +1138,7 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist,
       ctx = xmalloc_clear (sizeof *ctx + (n - 1) * sizeof ctx->items);
       ctx->nitems = n;
 
-      for (n = 0, r = namelist; r; r = r->next, n++)
+      for (n = 0, r = namelist_expanded; r; r = r->next, n++)
 	{
 	  gpg_error_t err;
 
@@ -1148,7 +1149,8 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist,
 	  if (err)
 	    {
 	      xfree (ctx);
-	      return gpg_err_code (err); /* FIXME: remove gpg_err_code.  */
+	      rc = gpg_err_code (err); /* FIXME: remove gpg_err_code.  */
+	      goto out;
 	    }
 	  if (!include_unusable
 	      && ctx->items[n].mode != KEYDB_SEARCH_MODE_SHORT_KID
@@ -1169,7 +1171,7 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist,
     {
       rc = gpg_error_from_syserror ();
       getkey_end (ctrl, ctx);
-      return rc;
+      goto out;
     }
 
   if (!ret_kb)
@@ -1200,6 +1202,9 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist,
       getkey_end (ctrl, ctx);
     }
 
+out:
+  if (namelist_expanded)
+    free_strlist(namelist_expanded);
   return rc;
 }
 
diff --git a/g10/keydb.h b/g10/keydb.h
index 9748e571e..14cf04ff3 100644
--- a/g10/keydb.h
+++ b/g10/keydb.h
@@ -254,6 +254,8 @@ void show_revocation_reason (ctrl_t ctrl, PKT_public_key *pk, int mode );
 int  check_signatures_trust (ctrl_t ctrl, PKT_signature *sig);
 
 void release_pk_list (PK_LIST pk_list);
+int expand_id(const char *id,strlist_t *into,unsigned int flags);
+strlist_t expand_group (strlist_t input);
 int  build_pk_list (ctrl_t ctrl, strlist_t rcpts, PK_LIST *ret_pk_list);
 gpg_error_t find_and_check_key (ctrl_t ctrl,
                                 const char *name, unsigned int use,
diff --git a/g10/pkclist.c b/g10/pkclist.c
index e7484432a..8b49a31d3 100644
--- a/g10/pkclist.c
+++ b/g10/pkclist.c
@@ -759,55 +759,6 @@ default_recipient (ctrl_t ctrl)
 }
 
 
-static int
-expand_id(const char *id,strlist_t *into,unsigned int flags)
-{
-  struct groupitem *groups;
-  int count=0;
-
-  for(groups=opt.grouplist;groups;groups=groups->next)
-    {
-      /* need strcasecmp() here, as this should be localized */
-      if(strcasecmp(groups->name,id)==0)
-	{
-	  strlist_t each,sl;
-
-	  /* this maintains the current utf8-ness */
-	  for(each=groups->values;each;each=each->next)
-	    {
-	      sl=add_to_strlist(into,each->d);
-	      sl->flags=flags;
-	      count++;
-	    }
-
-	  break;
-	}
-    }
-
-  return count;
-}
-
-/* For simplicity, and to avoid potential loops, we only expand once -
- * you can't make an alias that points to an alias.  */
-static strlist_t
-expand_group (strlist_t input)
-{
-  strlist_t output = NULL;
-  strlist_t sl, rover;
-
-  for (rover = input; rover; rover = rover->next)
-    if (!(rover->flags & PK_LIST_FROM_FILE)
-        && !expand_id(rover->d,&output,rover->flags))
-      {
-	/* Didn't find any groups, so use the existing string */
-	sl=add_to_strlist(&output,rover->d);
-	sl->flags=rover->flags;
-      }
-
-  return output;
-}
-
-
 /* Helper for build_pk_list to find and check one key.  This helper is
  * also used directly in server mode by the RECIPIENTS command.  On
  * success the new key is added to PK_LIST_ADDR.  NAME is the user id
-- 
2.20.1






From smueller at chronox.de  Sat Jan  5 13:39:48 2019
From: smueller at chronox.de (Stephan Mueller)
Date: Sat, 05 Jan 2019 13:39:48 +0100
Subject: [PATCH GnuPG] gpg: expand GPG groups when resolving a key
Message-ID: <6698374.p8xfKXfX4R@tauon.chronox.de>

* g10/expand_group.c: New
* g10/pkclist.c: Extract expand_group and expand_id into expand_group.c
* g10/keydb.h: Add prototypes of expand_id and expand_group
* g10/getkey.c: Use expand_group before resolving key references
* g10/Makefile.am: Compile expand_group.c
--

When searching a key by its name, try to expand the provided name in
case it is a GPG group reference. This GPG group resolution is performed
before the individual keys are verified.

This allows key listing using a GPG group reference. In particular, this
modification fixes the encryption to group support in KDE's Kmail which
is broken since version 18.08.

Signed-off-by: Stephan Mueller <smueller at chronox.de>
---
 g10/Makefile.am    |  1 +
 g10/expand_group.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++
 g10/getkey.c       | 15 ++++++----
 g10/keydb.h        |  2 ++
 g10/pkclist.c      | 49 -------------------------------
 5 files changed, 86 insertions(+), 54 deletions(-)
 create mode 100644 g10/expand_group.c

diff --git a/g10/Makefile.am b/g10/Makefile.am
index 3b4464364..63a42aba5 100644
--- a/g10/Makefile.am
+++ b/g10/Makefile.am
@@ -99,6 +99,7 @@ common_source =  \
 	      filter.h		\
 	      free-packet.c	\
 	      getkey.c		\
+	      expand_group.c	\
 	      keydb.c keydb.h    \
 	      keyring.c keyring.h \
 	      seskey.c		\
diff --git a/g10/expand_group.c b/g10/expand_group.c
new file mode 100644
index 000000000..310daa944
--- /dev/null
+++ b/g10/expand_group.c
@@ -0,0 +1,73 @@
+/* expand_group.c - expand GPG group definitions
+ * Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
+ *               2008, 2009, 2010 Free Software Foundation, Inc.
+ *
+ * This file is part of GnuPG.
+ *
+ * GnuPG is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GnuPG 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 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 <https://www.gnu.org/licenses/>.
+ */
+
+#include <config.h>
+
+#include "gpg.h"
+#include "options.h"
+#include "keydb.h"
+
+int
+expand_id(const char *id,strlist_t *into,unsigned int flags)
+{
+  struct groupitem *groups;
+  int count=0;
+
+  for(groups=opt.grouplist;groups;groups=groups->next)
+    {
+      /* need strcasecmp() here, as this should be localized */
+      if(strcasecmp(groups->name,id)==0)
+	{
+	  strlist_t each,sl;
+
+	  /* this maintains the current utf8-ness */
+	  for(each=groups->values;each;each=each->next)
+	    {
+	      sl=add_to_strlist(into,each->d);
+	      sl->flags=flags;
+	      count++;
+	    }
+
+	  break;
+	}
+    }
+
+  return count;
+}
+
+/* For simplicity, and to avoid potential loops, we only expand once -
+ * you can't make an alias that points to an alias.  */
+strlist_t
+expand_group (strlist_t input)
+{
+  strlist_t output = NULL;
+  strlist_t sl, rover;
+
+  for (rover = input; rover; rover = rover->next)
+    if (!(rover->flags & PK_LIST_FROM_FILE)
+        && !expand_id(rover->d,&output,rover->flags))
+      {
+	/* Didn't find any groups, so use the existing string */
+	sl=add_to_strlist(&output,rover->d);
+	sl->flags=rover->flags;
+      }
+
+  return output;
+}
diff --git a/g10/getkey.c b/g10/getkey.c
index 08e17e930..fb07937dd 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1098,7 +1098,7 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t 
namelist,
 {
   int rc = 0;
   int n;
-  strlist_t r;
+  strlist_t r, namelist_expanded = NULL;
   GETKEY_CTX ctx;
   KBNODE help_kb = NULL;
   KBNODE found_key = NULL;
@@ -1127,8 +1127,9 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t 
namelist,
     }
   else
     {
+      namelist_expanded = expand_group (namelist);
       /* Build the search context.  */
-      for (n = 0, r = namelist; r; r = r->next)
+      for (n = 0, r = namelist_expanded; r; r = r->next)
 	n++;
 
       /* CTX has space for a single search term at the end.  Thus, we
@@ -1137,7 +1138,7 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t 
namelist,
       ctx = xmalloc_clear (sizeof *ctx + (n - 1) * sizeof ctx->items);
       ctx->nitems = n;
 
-      for (n = 0, r = namelist; r; r = r->next, n++)
+      for (n = 0, r = namelist_expanded; r; r = r->next, n++)
 	{
 	  gpg_error_t err;
 
@@ -1148,7 +1149,8 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t 
namelist,
 	  if (err)
 	    {
 	      xfree (ctx);
-	      return gpg_err_code (err); /* FIXME: remove gpg_err_code.  */
+	      rc = gpg_err_code (err); /* FIXME: remove gpg_err_code.  */
+	      goto out;
 	    }
 	  if (!include_unusable
 	      && ctx->items[n].mode != KEYDB_SEARCH_MODE_SHORT_KID
@@ -1169,7 +1171,7 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t 
namelist,
     {
       rc = gpg_error_from_syserror ();
       getkey_end (ctrl, ctx);
-      return rc;
+      goto out;
     }
 
   if (!ret_kb)
@@ -1200,6 +1202,9 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t 
namelist,
       getkey_end (ctrl, ctx);
     }
 
+out:
+  if (namelist_expanded)
+    free_strlist(namelist_expanded);
   return rc;
 }
 
diff --git a/g10/keydb.h b/g10/keydb.h
index 9748e571e..14cf04ff3 100644
--- a/g10/keydb.h
+++ b/g10/keydb.h
@@ -254,6 +254,8 @@ void show_revocation_reason (ctrl_t ctrl, PKT_public_key 
*pk, int mode );
 int  check_signatures_trust (ctrl_t ctrl, PKT_signature *sig);
 
 void release_pk_list (PK_LIST pk_list);
+int expand_id(const char *id,strlist_t *into,unsigned int flags);
+strlist_t expand_group (strlist_t input);
 int  build_pk_list (ctrl_t ctrl, strlist_t rcpts, PK_LIST *ret_pk_list);
 gpg_error_t find_and_check_key (ctrl_t ctrl,
                                 const char *name, unsigned int use,
diff --git a/g10/pkclist.c b/g10/pkclist.c
index e7484432a..8b49a31d3 100644
--- a/g10/pkclist.c
+++ b/g10/pkclist.c
@@ -759,55 +759,6 @@ default_recipient (ctrl_t ctrl)
 }
 
 
-static int
-expand_id(const char *id,strlist_t *into,unsigned int flags)
-{
-  struct groupitem *groups;
-  int count=0;
-
-  for(groups=opt.grouplist;groups;groups=groups->next)
-    {
-      /* need strcasecmp() here, as this should be localized */
-      if(strcasecmp(groups->name,id)==0)
-	{
-	  strlist_t each,sl;
-
-	  /* this maintains the current utf8-ness */
-	  for(each=groups->values;each;each=each->next)
-	    {
-	      sl=add_to_strlist(into,each->d);
-	      sl->flags=flags;
-	      count++;
-	    }
-	  break;
-	}
-  return count;
-}
-/* For simplicity, and to avoid potential loops, we only expand once -
- * you can't make an alias that points to an alias.  */
-static strlist_t
-expand_group (strlist_t input)
-{
-  strlist_t output = NULL;
-  strlist_t sl, rover;
-
-  for (rover = input; rover; rover = rover->next)
-    if (!(rover->flags & PK_LIST_FROM_FILE)
-        && !expand_id(rover->d,&output,rover->flags))
-      {
-	/* Didn't find any groups, so use the existing string */
-	sl=add_to_strlist(&output,rover->d);
-	sl->flags=rover->flags;
-      }
-  return output;
-}
 /* Helper for build_pk_list to find and check one key.  This helper is
  * also used directly in server mode by the RECIPIENTS command.  On
  * success the new key is added to PK_LIST_ADDR.  NAME is the user id
-- 




From aheinecke at gnupg.org  Mon Jan  7 10:47:18 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Mon, 07 Jan 2019 10:47:18 +0100
Subject: Is gpgme_set_passphrase_cb effectively deprecated?
In-Reply-To: <CABFfbXuNoe7=8iLUx+g7JN3a=FxwbCL-cMzFt1y2L=Bfjv0r0Q@mail.gmail.com>
References: <CABFfbXuNoe7=8iLUx+g7JN3a=FxwbCL-cMzFt1y2L=Bfjv0r0Q@mail.gmail.com>
Message-ID: <1864384.JgDNukKA3z@esus>

Hi,

On Thursday 3 January 2019 16:51:08 CET Jeroen Ooms wrote:
> I maintain the gpgme bindings for the R programming language, and we
> use a have a custom password entry dialog in the GUI application.
> IIRC, the following code used to work about 2 or 3 years ago:
> 
>   gpgme_set_pinentry_mode(ctx, GPGME_PINENTRY_MODE_LOOPBACK);
>   gpgme_set_passphrase_cb(ctx, cb_fun, payload);
> 
> However I tried this with gpgme 1.11 (Windows) and 1.12 (MacOS), and
> this does not seem to work anymore at all. The cb_fun is never
> invoked, neither with gpg 1.4 nor gpg 2.2.

Strange. It should work with gpg 1.4 and gpg > 2.1 (with the loopback). I have 
a test in the Qt testsuite that uses it. There I have the logic:

static bool decryptSupported()
{
    /* With GnuPG 2.0.x (at least 2.0.26 by default on jessie)
     * the passphrase_cb does not work. So the test popped up
     * a pinentry. So tests requiring decryption don't work. */
    static auto version = GpgME::engineInfo(GpgME::GpgEngine).engineVersion();
    if (version < "2.0.0") {
        /* With 1.4 it just works */
        return true;
    }
    if (version < "2.1.0") {
        /* With 2.1 it works with loopback mode */
        return false;
    }
    return true;
}

The only version for which it does not work is afaik 2.0.x

That is using Protocol / Engine OpenPGP. I think for S/MIME it does not work.

> Also the documentation for gpgme_set_passphrase_cb says "Some engines
> do not even support an external passphrase callback at all, in this
> case the error code GPG_ERR_NOT_SUPPORTED is returned" however the
> function returns void so this seems incorrect.

Indeed.

> I was wondering if it is possible to update the
> gpgme_set_passphrase_cb documentation on the current situation, which
> versions of gnupg it is expected to work, under which
> conditions/settings.

Something else seems wrong in your setup / code. It should work for you.

Maybe take a look at the gpgme log to see more about what happens.

Best Regards,
Andre

-- 
GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190107/e9786453/attachment.sig>

From aheinecke at gnupg.org  Mon Jan  7 10:57:20 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Mon, 07 Jan 2019 10:57:20 +0100
Subject: Most efficient way to look whether a secret key is for X.509 or
 for OpenPGP
In-Reply-To: <permail-201901030104388218e1ae000029fa-perske@message-id.uni-muenster.de>
References: <permail-201901030104388218e1ae000029fa-perske@message-id.uni-muenster.de>
Message-ID: <11813237.UfyVpPf4nk@esus>

Hi

On Thursday 3 January 2019 02:04:38 CET Rainer Perske wrote:
> I use gpgsm and gpg2 concurrently. I can quickly and easily see whether
> there are private keys in gnupghome/private-keys-v1.d/. But I cannot
> easily see whether these keys belong to X.509 key pairs or to OpenPGP
> key pairs.
> 
> For my application, I need to know:
> 
> a) What is the fastest way to detect whether I have a private X.509
>    key? I need a simple boolean answer: yes or no.
> ....

My idea to make it faster then letting the agent do it is to do a keylisting 
with the keygrip:

gpg(sm) --with-colons -k --with-keygrip
(the grp line contains the keygrip)

And then check if the private-keys.v1.d contains such a key file.This would be 
quicker of course if you only needed to check for the private key of a specific 
pubkey for which you knew the keyrgrip in advance.

You should leave it to the agent though (maybe you could somehow prestart the 
agent to make it faster)? So that it is more robust if the key format changes 
in the future.

Regards,
Andre

-- 
GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190107/c0510008/attachment-0001.sig>

From aheinecke at gnupg.org  Mon Jan  7 10:34:35 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Mon, 07 Jan 2019 10:34:35 +0100
Subject: Exporting SSH keys from OpenPGP Authentication keys
 programatically (gpgme)
In-Reply-To: <303014d3-077b-56e6-2e70-4a3626fd16e5@metacode.biz>
References: <15d4748b-2be1-a3cd-bd03-66a42ca0998e@metacode.biz>
 <640b070e7652fb6c8b55f9513bfb5aa01411ff8d.camel@googlemail.com>
 <303014d3-077b-56e6-2e70-4a3626fd16e5@metacode.biz>
Message-ID: <3068260.dLyEgXFm7Z@esus>

Hi,

On Sunday 30 December 2018 20:29:06 CET Wiktor Kwapisiewicz via Gnupg-devel 
wrote:
> >> This is not supported.  Do you think this could be a common use case?
> 
> I don't know if this is "common" enough but I'm planning to write an 
integration
> that would automatically add user's keys (OpenPGP, SSH) to GitLab when a new
> e-mail is added through Web Key Directory [0]. As far as I've seen they use
> GpgME for key management so if it was possible I'd like to keep the same 
style.

Sounds good. Although I do not think that we would even need a usecase for 
this. Just for consistency the API should provide it.  It is a simple change 
IMO to add this as an export mode.
I noted the request down as:

https://dev.gnupg.org/T4310

Best Regards,
Andre

-- 
GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190107/1a2e6643/attachment.sig>

From jeroen at berkeley.edu  Mon Jan  7 17:04:15 2019
From: jeroen at berkeley.edu (Jeroen Ooms)
Date: Mon, 7 Jan 2019 17:04:15 +0100
Subject: Is gpgme_set_passphrase_cb effectively deprecated?
In-Reply-To: <1864384.JgDNukKA3z@esus>
References: <CABFfbXuNoe7=8iLUx+g7JN3a=FxwbCL-cMzFt1y2L=Bfjv0r0Q@mail.gmail.com>
 <1864384.JgDNukKA3z@esus>
Message-ID: <CABFfbXttnF-obRM-9=242hyoOA-pqMVyHgriuswR2mhVkmcexA@mail.gmail.com>

On Mon, Jan 7, 2019 at 10:47 AM Andre Heinecke <aheinecke at gnupg.org> wrote:
> > I was wondering if it is possible to update the
> > gpgme_set_passphrase_cb documentation on the current situation, which
> > versions of gnupg it is expected to work, under which
> > conditions/settings.
>
> Something else seems wrong in your setup / code. It should work for you.
> Maybe take a look at the gpgme log to see more about what happens.

OK it does work indeed, I realize my mistake now. First I assumed the
passphrase would be required when importing or exporting keys, as is
the case for ssh/PEM files. But I understand now that gpg will import
an encrypted gpg key; the passphrase is only needed when actually
using the key.

In addition, I was confused because gpg seems to be using ssh-agent to
cache keys? The passphrase callback function was not being invoked
because the unlocked key was cached apparently. I have never setup
gpg-agent on this machine, but I am running ssh-agent. Anyway I
cleared the cache:

  echo RELOADAGENT | gpg-connect-agent

And now I do get prompted for the passphrase when trying to sign with
the encrypted key!


From aheinecke at gnupg.org  Wed Jan  9 08:51:42 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Wed, 09 Jan 2019 08:51:42 +0100
Subject: GPGME Qt test failures as of 6. Jan 2019,..
Message-ID: <1890130.EMHIXS9NX6@esus>

Hi,

The GPGME Qt test suite fails in released GPGME versions because I made the 
stupid mistake of using keys with an expiry date for a test. The keys expired 
on Jan 06. 2019,...

The failure is:

FAIL!  : TofuInfoTest::testTofuConflict() 'sig.validity() == 
Signature::Marginal' returned FALSE. ()
   Loc: [t-tofuinfo.cpp(458)]

So this failure can be safely ignored. GPGME Master has a fix for this (using 
keys without expiry,..) [1]. This was not fixed earlier even though it had been 
reported nrealy a year ago, because I overlooked it and there was a bit 
miscommunication,... 

I can only apologize for the hassle, especially to packagers. :-/

Best Regards,
Andre

1: https://dev.gnupg.org/rM66376f3e206a1aa791d712fb8577bb3490268f60
2: https://dev.gnupg.org/T3815

-- 
GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190109/33e6c157/attachment.sig>

From gnupg at eckner.net  Wed Jan  9 11:55:12 2019
From: gnupg at eckner.net (Erich Eckner)
Date: Wed, 9 Jan 2019 11:55:12 +0100
Subject: wks for sign-only keys
Message-ID: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net>

Hi,

I'm currently setting up wkd and wks on my server. This works great for
keys which can encrypt and sign. However, when I try to publish a
sign-only key, I get:

> /usr/lib/gnupg/gpg-wks-client -vvv --create
5FDCA472AB93292BC678FD59255A76DB9A12601A arch-packages at eckner.net
gpg-wks-client: gpg: writing to stdout
gpg-wks-client: submitting request to 'key-submission at szilassi.eckner.net'
gpg-wks-client: gpg: Total number processed: 1
gpg-wks-client: submitting key with user id 'Erich Eckner (just to sign
arch packages) <arch-packages at eckner.net>'
gpg-wks-client: gpg: 5FDCA472AB93292BC678FD59255A76DB9A12601A: skipped:
Unusable public key
gpg-wks-client: gpg: [stdin]: encryption failed: Unusable public key
gpg-wks-client: error running '/usr/bin/gpg': exit status 2
gpg-wks-client: encryption failed: Unusable public key
gpg-wks-client: creating request failed: Unusable public key

I understand, that the wks server sends back an encrypted email - which
it can't with the sign-only key. However, would it be possible to fall
back to an unencrypted email for keys which are not suited for
encrypting? In the end, the content will still be signed, thus authentic.

My understanding is, that the encrypted email from wks to the client
ensures:
a) client has the private key (unnecessary, as it already signed
something - or can be verified again by signing some given content)
b) client actually wants to publish its key (for that, no encryption is
needed, just a valid signature from the wks and from the client for the
answer)
Am i right?

regards,
Erich


From bernhard at intevation.de  Thu Jan 10 09:29:37 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 10 Jan 2019 09:29:37 +0100
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
Message-ID: <201901100929.42086.bernhard@intevation.de>

Phil,

Am Freitag 27 Oktober 2017 18:24:45 schrieb Phil Pennock:
> Thus at <https://public-packages.pennock.tech/> I have packages

thanks again for those packages, I'll still use them for test sometimes!

Just missed a gpgme package, to see how gpgme-json does, which is needed to 
couple Mailvelope to GnuPG [1]. ;)

Best Regards,
Bernhard

[1] https://www.mailvelope.com/en/blog/mailvelope-3.0 announcement


-- 
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: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190110/1795c5cd/attachment.sig>

From gnupg-devel at spodhuis.org  Fri Jan 11 00:04:47 2019
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Thu, 10 Jan 2019 18:04:47 -0500
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <201901100929.42086.bernhard@intevation.de>
References: <201901100929.42086.bernhard@intevation.de>
Message-ID: <20190110230446.GA55039@osmium.pennocktech.home.arpa>

On 2019-01-10 at 09:29 +0100, Bernhard Reiter wrote:
> Am Freitag 27 Oktober 2017 18:24:45 schrieb Phil Pennock:
> > Thus at <https://public-packages.pennock.tech/> I have packages
> 
> thanks again for those packages, I'll still use them for test sometimes!

Good to know.  :)

> Just missed a gpgme package, to see how gpgme-json does, which is needed to 
> couple Mailvelope to GnuPG [1]. ;)

I'm a little reluctant to provide gpgme packages, because (1) I don't
use it myself, so would be unlikely to notice failures, and (2) the
combination of languages and dependencies can explode quite quickly.  Do
you pull in QT as a dependency always, or skip QT?  Node.js?

I recommend just installing gpgme yourself with the required
dependencies for your use-case.  Perhaps work from speedo.mk and build
more packages too, migrating to have everything under your local
control.  My packages are convenient for some use-cases, but I'm also
one person who might get hit by a bus.  They'll get you able to make
progress and move forward with "current GnuPG ecosystem, installed out
of the way of the system, ASAP".

I think that gpgme with the various integration options, considered
across multiple OSes, is a step too far for me to be comfortable trying
to maintain unless and until I have a use-case for my own systems.

-Phil


From bernhard at intevation.de  Fri Jan 11 09:05:41 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 11 Jan 2019 09:05:41 +0100
Subject: wks for sign-only keys
In-Reply-To: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net>
References: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net>
Message-ID: <201901110905.50013.bernhard@intevation.de>

Am Mittwoch 09 Januar 2019 11:55:12 schrieb Erich Eckner:
> I'm currently setting up wkd and wks on my server. This works great for
> keys which can encrypt and sign. However, when I try to publish a

> gpg-wks-client: creating request failed: Unusable public key

One of the design ideas of WKD/WKS is that it is as simple as possible.
A pubkey without the ability to be encrypted to is a special case.

Maybe some special cases could be supported in the future, but in my view this
would need a very good reason, so that the hassle of added complexity is worth 
it.

So what is your use case? Why not just use a pubkey with allows encryption
and do not use it, if you don't need it? To me the encryption test has the 
advantage to check that it is actually possible to retrieve a pubkey for an 
email address and right away use it for encryption to this address.


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: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190111/2e111585/attachment-0001.sig>

From bernhard at intevation.de  Fri Jan 11 09:09:24 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 11 Jan 2019 09:09:24 +0100
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <20190110230446.GA55039@osmium.pennocktech.home.arpa>
References: <201901100929.42086.bernhard@intevation.de>
 <20190110230446.GA55039@osmium.pennocktech.home.arpa>
Message-ID: <201901110909.24371.bernhard@intevation.de>

Am Freitag 11 Januar 2019 00:04:47 schrieb Phil Pennock:
> I recommend just installing gpgme yourself with the required
> dependencies for your use-case. 

Maybe that would be a good statement to add to your page (if somebody else 
wonders).

> I think that gpgme with the various integration options, considered
> across multiple OSes, is a step too far for me to be comfortable trying
> to maintain unless and until I have a use-case for my own systems.

Thanks for the response and for having a clear and good understanding of what 
you can and want to provide! To me it makes good sense.

Still, as you have intended, I believe your packages are a helpful addition to 
the GnuPG packaging ecosystem, so thanks again.

Cheers,
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: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190111/0dc5deae/attachment.sig>

From gnupg at eckner.net  Fri Jan 11 09:46:05 2019
From: gnupg at eckner.net (Erich Eckner)
Date: Fri, 11 Jan 2019 09:46:05 +0100
Subject: wks for sign-only keys
In-Reply-To: <201901110905.50013.bernhard@intevation.de>
References: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net>
 <201901110905.50013.bernhard@intevation.de>
Message-ID: <d80f738a-8c9d-a4eb-0a7d-a8e30fab8d31@eckner.net>



On 11.01.19 09:05, Bernhard Reiter wrote:
> Am Mittwoch 09 Januar 2019 11:55:12 schrieb Erich Eckner:
>> I'm currently setting up wkd and wks on my server. This works great for
>> keys which can encrypt and sign. However, when I try to publish a
> 
>> gpg-wks-client: creating request failed: Unusable public key
> 
> One of the design ideas of WKD/WKS is that it is as simple as possible.
> A pubkey without the ability to be encrypted to is a special case.
> 
> Maybe some special cases could be supported in the future, but in my view this
> would need a very good reason, so that the hassle of added complexity is worth 
> it.
> 
> So what is your use case? Why not just use a pubkey with allows encryption
> and do not use it, if you don't need it? To me the encryption test has the 
> advantage to check that it is actually possible to retrieve a pubkey for an 
> email address and right away use it for encryption to this address.
> 
> 
> Best Regards,
> Bernhard

My use case is a key for (automatic) signing of packages and/or
archives. To avoid any confusions, I created the key without capability
of encryption (no emails should be sent to that address - besides of
course wks emails).
If it would add much complexity to allow for uploading sign-only keys, I
guess, I'm fine with replacing the key with one that can also encrypt -
or uploading the key manually to wkd.

regards,
Erich


From gnupg at eckner.net  Fri Jan 11 09:47:18 2019
From: gnupg at eckner.net (Erich Eckner)
Date: Fri, 11 Jan 2019 09:47:18 +0100
Subject: wks for sign-only keys
In-Reply-To: <87ef9jsi20.fsf@wheatstone.g10code.de>
References: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net>
 <87ef9jsi20.fsf@wheatstone.g10code.de>
Message-ID: <0bb3a6c8-13dc-1828-2cdf-917f867d1eb3@eckner.net>



On 11.01.19 09:40, Werner Koch wrote:
> On Wed,  9 Jan 2019 11:55, gnupg at eckner.net said:
> 
>> it can't with the sign-only key. However, would it be possible to fall
>> back to an unencrypted email for keys which are not suited for
>> encrypting? In the end, the content will still be signed, thus authentic.
> 
> The purpose of the Web Key Directory is to provide an encryption key for
> a given mail address.  It is entirely useless for a signing key because
> a verifying party can't find the key using the Web Key directory because
> the lookup is by the mail address and not by the fingerprint, which is
> provided as part of the signature.
> 
> 
> Shalom-Salam,
> 
>    Werner
> 

oh, I haven't thought of that. Thanks for the explanation /
clarification :-)

regards,
Erich


From wk at gnupg.org  Fri Jan 11 09:40:55 2019
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Jan 2019 09:40:55 +0100
Subject: wks for sign-only keys
In-Reply-To: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net> (Erich Eckner's
 message of "Wed, 9 Jan 2019 11:55:12 +0100")
References: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net>
Message-ID: <87ef9jsi20.fsf@wheatstone.g10code.de>

On Wed,  9 Jan 2019 11:55, gnupg at eckner.net said:

> it can't with the sign-only key. However, would it be possible to fall
> back to an unencrypted email for keys which are not suited for
> encrypting? In the end, the content will still be signed, thus authentic.

The purpose of the Web Key Directory is to provide an encryption key for
a given mail address.  It is entirely useless for a signing key because
a verifying party can't find the key using the Web Key directory because
the lookup is by the mail address and not by the fingerprint, which is
provided as part of the signature.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190111/37c9bc68/attachment.sig>

From bernhard at intevation.de  Fri Jan 11 11:08:09 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 11 Jan 2019 11:08:09 +0100
Subject: wks for sign-only keys
In-Reply-To: <d80f738a-8c9d-a4eb-0a7d-a8e30fab8d31@eckner.net>
References: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net>
 <201901110905.50013.bernhard@intevation.de>
 <d80f738a-8c9d-a4eb-0a7d-a8e30fab8d31@eckner.net>
Message-ID: <201901111108.17474.bernhard@intevation.de>

Am Freitag 11 Januar 2019 09:46:05 schrieb Erich Eckner:
> To avoid any confusions, I created the key without capability
> of encryption (no emails should be sent to that address - besides of
> course wks emails).

An interessting question then is: What do you do, if you an email is send to 
this address? :) Even if you throw them away, being able to encrypt is 
important, because users may have send you some interesting information.
If you don't want email send at all, why offering an email address?

> If it would add much complexity to allow for uploading sign-only keys, I
> guess, I'm fine with replacing the key with one that can also encrypt

Given my assumptions above this maybe the better solution for you anyway. ;)

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: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190111/fbf18649/attachment.sig>

From gnupg at eckner.net  Fri Jan 11 11:20:00 2019
From: gnupg at eckner.net (Erich Eckner)
Date: Fri, 11 Jan 2019 11:20:00 +0100
Subject: wks for sign-only keys
In-Reply-To: <201901111108.17474.bernhard@intevation.de>
References: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net>
 <201901110905.50013.bernhard@intevation.de>
 <d80f738a-8c9d-a4eb-0a7d-a8e30fab8d31@eckner.net>
 <201901111108.17474.bernhard@intevation.de>
Message-ID: <65cdd8ac-3fe7-fe73-2323-0d632d35181e@eckner.net>

On 11.01.19 11:08, Bernhard Reiter wrote:
> Am Freitag 11 Januar 2019 09:46:05 schrieb Erich Eckner:
>> To avoid any confusions, I created the key without capability
>> of encryption (no emails should be sent to that address - besides of
>> course wks emails).
> 
> An interessting question then is: What do you do, if you an email is send to 
> this address? :) Even if you throw them away, being able to encrypt is 
> important, because users may have send you some interesting information.
> If you don't want email send at all, why offering an email address?

Email will be discarded. I was simply offering an email address, because
I thought it was mandatory (but now I see, that it is not).

> 
>> If it would add much complexity to allow for uploading sign-only keys, I
>> guess, I'm fine with replacing the key with one that can also encrypt
> 
> Given my assumptions above this maybe the better solution for you anyway. ;)

Yes, either that or a key without an email address and manual upload to
the wkd.

regards,
Erich


From bernhard at intevation.de  Fri Jan 11 12:25:37 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 11 Jan 2019 12:25:37 +0100
Subject: wks for sign-only keys
In-Reply-To: <65cdd8ac-3fe7-fe73-2323-0d632d35181e@eckner.net>
References: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net>
 <201901111108.17474.bernhard@intevation.de>
 <65cdd8ac-3fe7-fe73-2323-0d632d35181e@eckner.net>
Message-ID: <201901111225.37892.bernhard@intevation.de>

Am Freitag 11 Januar 2019 11:20:00 schrieb Erich Eckner:
> or a key without an email address and manual upload to the wkd.

This won't work. 
As Werner wrote: WKD shall give the pubkey for an email address.
So if there is no known email address, no pubkey can be found (or will be 
accessed).

-- 
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: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190111/f1cf8c1f/attachment.sig>

From dkg at fifthhorseman.net  Fri Jan 11 21:51:27 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 11 Jan 2019 15:51:27 -0500
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <201901100929.42086.bernhard@intevation.de>
References: <201901100929.42086.bernhard@intevation.de>
Message-ID: <8736pydik0.fsf@fifthhorseman.net>

Hi Bernhard--

On Thu 2019-01-10 09:29:37 +0100, Bernhard Reiter wrote:
> Just missed a gpgme package, to see how gpgme-json does, which is needed to 
> couple Mailvelope to GnuPG [1]. ;)

That would be great to have!  I welcome followup on
https://bugs.debian.org/911189

Suggestions or patches are welcome -- i'd be very happy to have more
people actively contributing to the debian packaging for gpgme.

all the best,

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190111/d8328ba6/attachment-0001.sig>

From ben at adversary.org  Sat Jan 12 11:54:20 2019
From: ben at adversary.org (Ben McGinnes)
Date: Sat, 12 Jan 2019 21:54:20 +1100
Subject: Request for Comment: protocol extension design
Message-ID: <20190112105420.bcaqhmpgn3i64e7n@adversary.org>

Hi all,
	So for much of last year I've been working on the Python
bindings for GPGME (now in maintenance mode) and though that occupied
much of my time, it didn't occupy all of it.  At least not all of the
time spent on matters of interest to this list.

I've also been spending a fair bit of time, mostly in April last year
and then again in November and December, as well as a little over the
last week, working on something else for OpenPGP in general.  That
being an extension or adaptation of the W3C's ActiveStreams 2.0 and
ActivityPub protocols to integrate with OpenPGP in order to provide
features for both signed and/or encrypted activities or objects for
those two protocols.

For those unfamiliar with ActivityStreams and ActivityPub, they're
microblogging protocols which provide functionality similar to
Twitter, except via a federated model rather than a centralised one.
Most users of these protocols know it by the more familiar names of
the software implementing them: Mastodon and Pleroma.  The various
server instances of these being collectively known as the fediverse.

My introduction to the fediverse came early last year, not long after
starting the Python bindings HOWTO and my reading up on the underlying
protocols at that time made one thing very clear to me.  That those
protocols were inherently something very familiar to everyone here:
they were a transport protocol.  They were, however, a transport
protocol with no integrated means by which end users could guarantee
the fidelity of their posts or content, nor could they guarantee
end-to-end encrypted private communications save by somewhat ad-hoc
means.

My proposal seeks to change that and now the second draft is ready for
public review, comment and critique.

It is pretty much essential to read and be familiar with Activity
Streams 2.0 and ActivityPub first.  Both standards are available via
the W3C:

https://www.w3.org/TR/activitystreams-core/
https://www.w3.org/TR/activitypub/

Then move on to my work at the following URL.  The zipfile after that
contains all the public and private key data used in the examples.

Active Cryptography: OpenPGP over Activity Streams 2.0
http://files.de.adversary.org/crypto/ac/index.html

Active Cryptography: supplemental files
http://files.de.adversary.org/crypto/ac/supplemental.zip

Both of these latter URLs are hosted on AWS S3 servers; so you can
access them via HTTPS, but it will trigger an SSL certificate mismatch
alert.  It's up to you.

These documents and files are being published principally in Germany
for political reasons and just in case.  I may mirror them in the USA
later on, but I haven't decided on what the best course for Australian
publication is just yet.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190112/5d13de2e/attachment.sig>

From albrecht.dress at arcor.de  Sat Jan 12 16:52:11 2019
From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=)
Date: Sat, 12 Jan 2019 16:52:11 +0100
Subject: GpgME: gpgme_op_import_result() for crap data
Message-ID: <B32IVXXL.XVFSOFFG.HNOH7UDF@6FLC4UGY.NJM5CKNU.XERRCSDD>

Hi all,

when I call gpg to import some crap data, a proper error message is returned, e.g.:

<snip>
user at host:~$ gpg --import <<< 'some crap'
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
</snip>

However, calling gpgme_op_import() on the same data, and then reading gpgme_op_import_result(), no usable error information is returned.  E.g. running the attached simple code, the result is

<snip>
user at host:~$ ./gpgme-import
GpgME version: 1.12.0
gpgme_new: 0
gpgme_set_protocol: 0
gpgme_data_new_from_mem: 0
gpgme_op_import: 0
gpgme_op_import_result: imported=0, not imported=0, imports=(nil)
</snip>

I would expect that imports is not NULL, and imports->result indicate the error (probably GPG_ERR_INV_DATA).

Did I miss something here (i.e. I have to read the error information somewhere else), or is this information left out intentionally?

Thanks
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpgme-import.c
Type: text/x-csrc
Size: 735 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190112/9c9e29d2/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190112/9c9e29d2/attachment.sig>

From smueller at chronox.de  Sun Jan 13 06:20:04 2019
From: smueller at chronox.de (Stephan Mueller)
Date: Sun, 13 Jan 2019 06:20:04 +0100
Subject: Different recipient match algorithms
Message-ID: <5230421.kG3MfHUPeR@tauon.chronox.de>

Hi,

When using gpg to encrypt to a recipient, the pattern matching logic to 
resolve a user-provided recipient identifier to a key seems to be performed 
with classify_user_id.

When applying a group definition expansion, the function expand_id performs 
the pattern matching by using strcasemp when searching for the group 
reference.

With this difference, the following is apparent: If I have 2 keys in my key 
ring with both looking like in that order:

AB <ab at c.d>
B <b at c.d>

both recipient resolution operations produce different results when encrypting 
to b at c.d. The group resolution resolves ab at c.d whereas the "regular" 
resolution operation returns b at c.d.

May I ask why this apparent different key resolution operation? Shouldn't 
expand_id also use classify_user_id instead of strcasecmp?

Ciao
Stephan




From aheinecke at gnupg.org  Tue Jan 15 10:54:49 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Tue, 15 Jan 2019 10:54:49 +0100
Subject: GpgME: gpgme_op_import_result() for crap data
In-Reply-To: <B32IVXXL.XVFSOFFG.HNOH7UDF@6FLC4UGY.NJM5CKNU.XERRCSDD>
References: <B32IVXXL.XVFSOFFG.HNOH7UDF@6FLC4UGY.NJM5CKNU.XERRCSDD>
Message-ID: <2271076.EWK8tFVoQg@esus>

Hi,

On Saturday, January 12, 2019 4:52:11 PM CET Albrecht Dre? wrote:
> when I call gpg to import some crap data, a proper error message is
> returned, e.g.:
> 
> <snip>
> user at host:~$ gpg --import <<< 'some crap'
> gpg: no valid OpenPGP data found.
> gpg: Total number processed: 0
> </snip>

That is not an error but a status message. The difference is that the 
operation continues. E.g. if you provide two filenames and the second one 
contains valid data you will get the status message once but still something 
is imported.

> I would expect that imports is not NULL, and imports->result indicate the 
error (probably GPG_ERR_INV_DATA).

I agree that it is bad. In Kleopatra I just treat empty results like an error 
happened. But if you import two files and only one has an error Kleopatra also 
will not show it.
 
> Did I miss something here (i.e. I have to read the error information 
somewhere else), or is this information left out intentionally?

You could use the new diagnostic interface to show the status output of GnuPG 
to the user in case an empty import result occured. I explicitly wanted to 
have that interface for such reasons where diagnostic output that is printed 
to stderr by GnuPG would otherwise be lost.

Be aware though that you should not automatically parse the diagnostic output 
as it might change because it is by design human readable output and not 
machine output.

I've commited an example how to use it to the gpgme run-import test:

https://dev.gnupg.org/rMce327f994a2888b807b63cf202ddcecc3fb9c685


Best Regards,
Andre

-- 
GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190115/224da26d/attachment.sig>

From albrecht.dress at arcor.de  Tue Jan 15 19:42:05 2019
From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=)
Date: Tue, 15 Jan 2019 19:42:05 +0100
Subject: GpgME: gpgme_op_import_result() for crap data
In-Reply-To: <2271076.EWK8tFVoQg@esus> (from aheinecke@gnupg.org on Tue Jan 15
 10:54:49 2019)
Message-ID: <Z5XOFYCE.VTUM2AK3.JVEVDKUT@2DSS64CE.LJR7FQOW.RVFP47A7>

Am 15.01.19 10:54 schrieb(en) Andre Heinecke:
> That is not an error but a status message. The difference is that the operation continues. E.g. if you provide two filenames and the second one contains valid data you will get the status message once but still something is imported.

O.k., understood.

>> I would expect that imports is not NULL, and imports->result indicate the error (probably GPG_ERR_INV_DATA).
> 
> I agree that it is bad. In Kleopatra I just treat empty results like an error happened.

My use case is the import of a single key in a MUA (from Autocrypt header, key server search, etc.).  Just telling the user ?something went wrong? is somewhat unsatisfactory?

> But if you import two files and only one has an error Kleopatra also will not show it.

The GpgME gpgme_import_result_t and gpgme_import_status_t data structures could cover this case, as the latter is a linked list.  I.e. add a separate item for each key, with a NULL fpr and appropriate status for all failed attempts.

> You could use the new diagnostic interface to show the status output of GnuPG to the user in case an empty import result occured. I explicitly wanted to have that interface for such reasons where diagnostic output that is printed to stderr by GnuPG would otherwise be lost.
[snip]
> I've commited an example how to use it to the gpgme run-import test:

Thanks, that's a helpful hint!  Unfortunately available since 1.11.2 only, i.e. not in Stretch or Ubuntu 18.04 ? more #ifdef's in the code!

Thanks again,
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190115/f3c68578/attachment-0001.sig>

From bogorodskiy at gmail.com  Thu Jan 17 05:12:36 2019
From: bogorodskiy at gmail.com (Roman Bogorodskiy)
Date: Thu, 17 Jan 2019 08:12:36 +0400
Subject: [PATCH libgpg-error] gpgrt-config: escape expr(1) operands
In-Reply-To: <8736r6utnq.fsf@iwagami.gniibe.org>
References: <20181209090821.86084-1-bogorodskiy@gmail.com>
 <8736r6utnq.fsf@iwagami.gniibe.org>
Message-ID: <20190117041233.GA1604@kloomba>

  NIIBE Yutaka wrote:

> Roman Bogorodskiy <bogorodskiy at gmail.com> wrote:
> > With FreeBSD's expr(1), gpgrt-config prints the following:
> [...]
> > This happens because FreeBSD expr(1) makes no lexical distinction
> > between arguments which may be operators and arguments which
> > may be operands. [1]
> >
> > To fix that, parenthesize values that could start with "-", as
> > suggested in the man page.
> 
> Thank you.
> 
> > --- a/src/gpgrt-config
> > +++ b/src/gpgrt-config
> > @@ -404,7 +404,7 @@ sysroot () {
> >  	    _result="$_result${_result:+ }$_opt"
> >  	    shift
> >  	    _result="$_result $PKG_CONFIG_SYSROOT_DIR$1"
> > -	elif expr "$1" : "^$_opt" >/dev/null; then
> > +	elif expr "\( $1 \)" : "^$_opt" >/dev/null; then
> 
> Here, the expression is to match string of $1 against $_opt.  IIUC,
> while this fix indeed escapes $1, I'm afraid it changes the semantics.
> 
> I fix it in a different way, by adding "x" to the expression.  I also
> fix another portability problem of expr.

Hi,

For some reason, it looks like this change was not included to 1.34,
which is strange, because I can see the commit[1] in the repo.

If I do something like that, I can see the old bits are still there:

$ curl -s https://gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.34.tar.bz2 | tar Ojxf - libgpg-error-1.34/src/gpgrt-config |egrep -n 'expr ("\$1|match)'
451:    elif expr "$1" : "^$_opt" >/dev/null; then
452:        _result="$_result${_result:+ }$_opt$PKG_CONFIG_SYSROOT_DIR$(expr "$1" : "^$_opt\(.*\)")"
571:elif expr match "$module_list" "=\|!=\|<\|>\|<=\|>=" >/dev/null; then
$

Am I missing something?

1: https://github.com/gpg/libgpg-error/commit/1d71dbb

Roman Bogorodskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190117/827d1d9e/attachment.sig>

From gniibe at fsij.org  Thu Jan 17 13:07:03 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 17 Jan 2019 21:07:03 +0900
Subject: [PATCH libgpg-error] gpgrt-config: escape expr(1) operands
In-Reply-To: <20190117041233.GA1604@kloomba>
References: <20181209090821.86084-1-bogorodskiy@gmail.com>
 <8736r6utnq.fsf@iwagami.gniibe.org> <20190117041233.GA1604@kloomba>
Message-ID: <87d0ovv66w.fsf@fsij.org>

Hello,

Thanks again for your report.

Roman Bogorodskiy <bogorodskiy at gmail.com> wrote:
> For some reason, it looks like this change was not included to 1.34,
> which is strange, because I can see the commit[1] in the repo.

I confirmed that the release of 1.33 and 1.34 have wrong gpgrt-config.

This is because gpgrt-config was generated file (in terms of automake,
it was the one in bin_SCRIPTS), but changed to the one of
dist_bin_SCRIPTS, during the development of 1.33, and we did not remove
generated gpgrt-config in our build directory.  We should have removed
the generated file in our build directory.

1.35 will fix this problem.
-- 


From gniibe at fsij.org  Fri Jan 18 01:13:53 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 18 Jan 2019 09:13:53 +0900
Subject: [PATCH libgpg-error] gpgrt-config: escape expr(1) operands
In-Reply-To: <87d0ovv66w.fsf@fsij.org>
References: <20181209090821.86084-1-bogorodskiy@gmail.com>
 <8736r6utnq.fsf@iwagami.gniibe.org> <20190117041233.GA1604@kloomba>
 <87d0ovv66w.fsf@fsij.org>
Message-ID: <875zumhlfi.fsf@fsij.org>

NIIBE Yutaka <gniibe at fsij.org> wrote:
> I confirmed that the release of 1.33 and 1.34 have wrong gpgrt-config.

To reproduce the error, here is a scenario.  You can reproduce that the
old generated gpgrt-config is in the released tarball.

If your automake is diffent version to the one of author, you will see
minor differences of automake generated files.  Also, po/*.po will have
different time stamps.  If you stay in different timezone, your
generated ChangeLog date fields will be also different.

Except these differences, it is only the file gpgrt-config, which is
different.

Well, for reproducibility, it would be good to invoke
gitlog-to-changelog with European timezone in Makefile.

==========================
# Preparation
# (1) Insall tools needed (git, autoconf, automake, etc.)
# (2) Manually install gnupg/build-aux/gitlog-to-changelog to /usr/local/bin

$ mkdir build-libgpg-error

# Clone the libgpg-error package
$ git clone git://git.gnupg.org/libgpg-error.git
$ cd libgpg-error

# Go to the version which used to generate gpgrt-config
$ git checkout 1096ff7
# And build the tarballs
$ ./autogen.sh
$ cd ../build-libgpg-error
$ ../libgpg-error/configure --enable-maintainer-mode
$ make distcheck

# This produces files:
#	libgpg-error-1.33-beta40.swdb
#	libgpg-error-1.33-beta40.tar.bz2
#	libgpg-error-1.33-beta40.tar.gz

# Some clean up (to recover po/*.po files)
$ cd ../libgpg-error
$ git reset --hard

# Then, go to the released version of 1.34
$ git checkout libgpg-error-1.34
# And build the tarballs, with same BUILD directory (not cleaned)
$ ./autogen.sh
$ cd ../build-libgpg-error
$ make distcheck

# This produces files:
#	libgpg-error-1.34.swdb
#	libgpg-error-1.34.tar.bz2
#	libgpg-error-1.34.tar.gz

$ cd ../libgpg-error
$ git reset --hard
==========================

In libgpg-error-1.34.tar.bz2 or libgpg-error-1.34.tar.gz, we can see old
generated gpgrt-config.
-- 


From dkg at fifthhorseman.net  Tue Jan 29 00:14:39 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 28 Jan 2019 18:14:39 -0500
Subject: What should '--local-user' mean when multiple secret keys match?
Message-ID: <875zu84bog.fsf@fifthhorseman.net>

I'm in the middle of a key transition, so i'm uncovering several places
where there's some awkwardness.

I want people to be able to move to a new OpenPGP certificate, without
completely disabling their old certificates, and still being able to
cope with a world where people rely temporarily on their old certs in
some contexts.

I recently ran into the situation where i was using git to sign a tag.

"git tag" uses --local-user with a User ID constructed from the git
committer identity.  GnuPG uses that string to pick the secret key that
has a matching user ID and is signing-capable.

Here were my two keys, in the order emitted by "gpg --list-secret-keys":

A * oldprimary [signing,certification] (created 2007)
B   - matching User ID
C   - subkey [signing] (created 2018)

D * newprimary [certification] (created 2019)
E   - matching User ID
F   - subkey [signing] (created 2019)

gpg chose to sign with C.

I wanted it to sign with F.

Now, i know *some* workarounds to convince gpg into signing with F based
on --local-user, but they all have downsides.  In the interest of trying
to figure out a better user experience for people who *don't* know (and
don't want to have to learn) all of these workarounds, i'll note what i
came up with:

 0) i could explicitly set git's user.signingKey field to the
    fingerprint of the new OpenPGP certificate.

    Downside: this doesn't scale well to multiple tools.  If i do this
    here, then presumably i have to do it in every tool that uses GnuPG.
    This would make future key transitions much more difficult, because
    i'd have to track down every place i've stashed the fingerprint.

 1) i could disable A entirely using "disable" from gpg --edit-key
 
    Downside: this disables the entire key, afaict, which is more than i
    want to do.

 2) i could re-order the keys in my GnuPG keyring so that newprimary
    comes first.

    Downside: this is tricky, as it involves deleting the old
    certificate and re-adding it later.  It has issues with maintaining
    ownertrust, secret key material, and non-exportable certifications
    if you do it wrong.  is there an easy/safe way to do this?

 3) i could remove the signing-capability on A, and change C's
    expiration date to "now".

    Downside: Let's assume that i've published such a change. Removing
    the signing-capability from the primary seems like it might cause
    problems for signatures made with A in the past (i haven't tested in
    detail), and it limits my ability to use C during the transition,
    should i need to do so in some contexts (e.g. peers that don't know
    about my new certificate yet).  This also requires the use of
    "change-usage", which is not even documented in "help" in "gpg
    --edit-key"

 4) Back up and delete the secret keys from
    ~/.gnupg/private-keys-v1.d/*.key that correspond to keys A and C.

    Downside: This limits my ability to use A or C during the transition
    phase if i want to use them -- it's more cumbersome to have to
    restore them from backup.  It also depends on my understanding the
    contents of ~/.gnupg/, which has traditionally been outside the
    "API" of GnuPG.  Do we really want to encourage users tinkering
    around in there?

So, how could GnuPG make this decision more correctly and safely by
default for normal users who want to transition in an orderly fashion to
a new key?  A couple ideas:

 * sign with the most recently-created key available.  (does this mean
   we're looking at the age of the primary, or of the subkey?)

 * provide explicit prioritization mechanisms between these keys that
   are easy to use and easy to revert

 * allow locally disabling subkeys independently from primary keys, or
   even disabling key usage flags on the primary key.

Any other suggestions?  what have i missed?  What should GnuPG do to
handle this use case better?

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190128/1445d8bf/attachment.sig>

From dashohoxha at gmail.com  Tue Jan 29 11:19:59 2019
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Tue, 29 Jan 2019 11:19:59 +0100
Subject: What should '--local-user' mean when multiple secret keys match?
In-Reply-To: <875zu84bog.fsf@fifthhorseman.net>
References: <875zu84bog.fsf@fifthhorseman.net>
Message-ID: <CAMucfLyyfT2z9ihG8byrF2TQh5cuv6k93=nckZn4LTLMw+iq0w@mail.gmail.com>

I find this discussion interesting. Thanks for sharing your experience.
I have a suggestion that you might have missed, which I describe below.

On Tue, Jan 29, 2019 at 12:15 AM Daniel Kahn Gillmor <dkg at fifthhorseman.net>
wrote:

> I'm in the middle of a key transition, so i'm uncovering several places
> where there's some awkwardness.
>
> I want people to be able to move to a new OpenPGP certificate, without
> completely disabling their old certificates, and still being able to
> cope with a world where people rely temporarily on their old certs in
> some contexts.
>
> I recently ran into the situation where i was using git to sign a tag.
>
> "git tag" uses --local-user with a User ID constructed from the git
> committer identity.  GnuPG uses that string to pick the secret key that
> has a matching user ID and is signing-capable.
>
> Here were my two keys, in the order emitted by "gpg --list-secret-keys":
>
> A * oldprimary [signing,certification] (created 2007)
> B   - matching User ID
> C   - subkey [signing] (created 2018)
>
> D * newprimary [certification] (created 2019)
> E   - matching User ID
> F   - subkey [signing] (created 2019)
>
> gpg chose to sign with C.
>
> I wanted it to sign with F.
>
> Now, i know *some* workarounds to convince gpg into signing with F based
> on --local-user, but they all have downsides.  In the interest of trying
> to figure out a better user experience for people who *don't* know (and
> don't want to have to learn) all of these workarounds, i'll note what i
> came up with:
>
>  0) i could explicitly set git's user.signingKey field to the
>     fingerprint of the new OpenPGP certificate.
>
>     Downside: this doesn't scale well to multiple tools.  If i do this
>     here, then presumably i have to do it in every tool that uses GnuPG.
>     This would make future key transitions much more difficult, because
>     i'd have to track down every place i've stashed the fingerprint.
>
>  1) i could disable A entirely using "disable" from gpg --edit-key
>
>     Downside: this disables the entire key, afaict, which is more than i
>     want to do.
>
>  2) i could re-order the keys in my GnuPG keyring so that newprimary
>     comes first.
>
>     Downside: this is tricky, as it involves deleting the old
>     certificate and re-adding it later.  It has issues with maintaining
>     ownertrust, secret key material, and non-exportable certifications
>     if you do it wrong.  is there an easy/safe way to do this?
>
>  3) i could remove the signing-capability on A, and change C's
>     expiration date to "now".
>
>     Downside: Let's assume that i've published such a change. Removing
>     the signing-capability from the primary seems like it might cause
>     problems for signatures made with A in the past (i haven't tested in
>     detail), and it limits my ability to use C during the transition,
>     should i need to do so in some contexts (e.g. peers that don't know
>     about my new certificate yet).  This also requires the use of
>     "change-usage", which is not even documented in "help" in "gpg
>     --edit-key"
>
>  4) Back up and delete the secret keys from
>     ~/.gnupg/private-keys-v1.d/*.key that correspond to keys A and C.
>
>     Downside: This limits my ability to use A or C during the transition
>     phase if i want to use them -- it's more cumbersome to have to
>     restore them from backup.  It also depends on my understanding the
>     contents of ~/.gnupg/, which has traditionally been outside the
>     "API" of GnuPG.  Do we really want to encourage users tinkering
>     around in there?
>

5) Backup the whole GNUPGHOME, like this: `cp -a ~/.gnupg ~/.oldgnupg`
     Make sure that you have only one secret key on each GNUPGHOME
     (the old key on ~/.oldgnupg, and the new one on ~/.gnupg).
     You could have done the backup before generating the new key, to make
     things easier. With this setup you normally would use the new key, but
if you
     want to use the old one for some reason, you could prefix the command
with
     `GNUPGHOME=~/.oldgnupg some-command . . . . .`
     Or you can run `export GNUPGHOME=~/.oldgnupg` on a new terminal window,
     and afterwards start the program that you wish to use.

I am not sure how well this would work for your case, but this is just
another possible
solution. From my experience (and meditation) I have arrived in the
conclusion that
usually it is better to keep only one secret key per context (or
GNUPGHOME), and to
change the context whenever you need to use a different key.


>
> So, how could GnuPG make this decision more correctly and safely by
> default for normal users who want to transition in an orderly fashion to
> a new key?  A couple ideas:
>
>  * sign with the most recently-created key available.  (does this mean
>    we're looking at the age of the primary, or of the subkey?)
>
>  * provide explicit prioritization mechanisms between these keys that
>    are easy to use and easy to revert
>
>  * allow locally disabling subkeys independently from primary keys, or
>    even disabling key usage flags on the primary key.
>
> Any other suggestions?  what have i missed?  What should GnuPG do to
> handle this use case better?
>

Maybe GnuPG should do something to improve the handling of GNUPGHOME,
if there is something to be improved about it.

Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190129/c23459ca/attachment-0001.html>

From andrewg at andrewg.com  Tue Jan 29 11:45:06 2019
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 29 Jan 2019 10:45:06 +0000
Subject: What should '--local-user' mean when multiple secret keys match?
In-Reply-To: <875zu84bog.fsf@fifthhorseman.net>
References: <875zu84bog.fsf@fifthhorseman.net>
Message-ID: <0be9ae74-7098-db04-1d0f-93677ac7e101@andrewg.com>

On 28/01/2019 23:14, Daniel Kahn Gillmor wrote:
> So, how could GnuPG make this decision more correctly and safely by
> default for normal users who want to transition in an orderly fashion to
> a new key?  A couple ideas:
> 
>  * sign with the most recently-created key available.  (does this mean
>    we're looking at the age of the primary, or of the subkey?)

I think "Most recent valid subkey of the most recent valid primary key"
is a sensible default. "Most recent valid subkey no matter how old the
primary is" would be the other option, but I can't imagine a use case
where it would be preferable.

>  * provide explicit prioritization mechanisms between these keys that
>    are easy to use and easy to revert

This would be useful for advanced users, but probably overkill for most.

>  * allow locally disabling subkeys independently from primary keys, or
>    even disabling key usage flags on the primary key.

Changing the usage flags on the primary has been a longstanding feature
request, but if your first two suggestions were implemented it wouldn't
be necessary for this use case.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190129/49ae6abf/attachment.sig>

From uri at mit.edu  Tue Jan 29 14:03:50 2019
From: uri at mit.edu (Uri Blumenthal)
Date: Tue, 29 Jan 2019 13:03:50 +0000
Subject: What should '--local-user' mean when multiple secret keys match?
In-Reply-To: <0be9ae74-7098-db04-1d0f-93677ac7e101@andrewg.com>
References: <875zu84bog.fsf@fifthhorseman.net>
 <0be9ae74-7098-db04-1d0f-93677ac7e101@andrewg.com>
Message-ID: <3BE596C1-A241-42C7-9A0E-167A60D8929F@mit.edu>

See inline please.

Sent from my test iPhone

> On Jan 29, 2019, at 07:45, Andrew Gallagher <andrewg at andrewg.com> wrote:
> 
>> * sign with the most recently-created key available.  (does this mean
>>   we're looking at the age of the primary, or of the subkey?)
> 
> I think "Most recent valid subkey of the most recent valid primary key"
> is a sensible default. "Most recent valid subkey no matter how old the
> primary is" would be the other option, but I can't imagine a use case
> where it would be preferable.

I think both scenarios are valid. I agree with your default. Perhaps, a config option to switch to the other...?


>> * provide explicit prioritization mechanisms between these keys that
>>   are easy to use and easy to revert
> 
> This would be useful for advanced users, but probably overkill for most.

So, most users would not change the default prioritization, and the advanced ones would have a convenient tool in hand. (Sotto voce: I strongly suspect there are more advanced users of GnuPG, than the "normal" ones.)

>> * allow locally disabling subkeys independently from primary keys, or
>>   even disabling key usage flags on the primary key.
> 
> Changing the usage flags on the primary has been a longstanding feature
> request, but if your first two suggestions were implemented it wouldn't
> be necessary for this use case.

I would still want very much to be able to change Usage flags on the primary. Regardless of whether the other good suggestions are implemented.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2894 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190129/c7674d2b/attachment.bin>

From peter at digitalbrains.com  Tue Jan 29 20:39:14 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 29 Jan 2019 20:39:14 +0100
Subject: What should '--local-user' mean when multiple secret keys match?
In-Reply-To: <3BE596C1-A241-42C7-9A0E-167A60D8929F@mit.edu>
References: <875zu84bog.fsf@fifthhorseman.net>
 <0be9ae74-7098-db04-1d0f-93677ac7e101@andrewg.com>
 <3BE596C1-A241-42C7-9A0E-167A60D8929F@mit.edu>
Message-ID: <b2275f3c-7694-7a48-d9e0-89b8d3a7d094@digitalbrains.com>

On 29/01/2019 14:03, Uri Blumenthal wrote:> See inline please.
> I would still want very much to be able to change Usage flags on the
> primary. Regardless of whether the other good suggestions are
> implemented.

I think that functionality is already implemented, though not
documented AFAIK. This is Debian stable:

--8<---------------cut here---------------start------------->8---
$ gpg --edit-key [...]
gpg (GnuPG) 2.1.18; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa2048/[...]
     created: 2017-06-21  expires: 2019-06-21  usage: SC
     trust: never         validity: unknown
ssb  rsa2048/[...]
     created: 2017-06-21  expires: 2019-06-21  usage: E
[ unknown] (1). [...]

gpg> change-usage
Changing usage of the primary key.

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? 
--8<---------------cut here---------------end--------------->8---

By the way, the way I understood dkg's

>  * allow locally disabling subkeys independently from primary keys, or
>    even disabling key usage flags on the primary key.

was as not /changing/ usage flags (as already implemented), which is an
externally visible action that changes how other people use your pub
key, but rather a /local/ configuration that disables local access to
functionality. I.e., it will not be considered to have a certain usage
by GnuPG even though the public key that is shared with others does
actually have that flag.

HTH,

Peter.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190129/c428c362/attachment-0001.sig>

From dkg at fifthhorseman.net  Thu Jan 31 23:13:26 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 31 Jan 2019 17:13:26 -0500
Subject: What should '--local-user' mean when multiple secret keys match?
In-Reply-To: <CAMucfLyyfT2z9ihG8byrF2TQh5cuv6k93=nckZn4LTLMw+iq0w@mail.gmail.com>
References: <875zu84bog.fsf@fifthhorseman.net>
 <CAMucfLyyfT2z9ihG8byrF2TQh5cuv6k93=nckZn4LTLMw+iq0w@mail.gmail.com>
Message-ID: <87imy4327t.fsf@fifthhorseman.net>

On Tue 2019-01-29 11:19:59 +0100, Dashamir Hoxha wrote:
>      Make sure that you have only one secret key on each GNUPGHOME
>      (the old key on ~/.oldgnupg, and the new one on ~/.gnupg).

Thanks, this is definitely another functional workaround that i could
probably do in some contexts, but i can see how it would be difficult
for a novice user (someone who doesn't even know what environment
variables are).  And it could also be problematic for (for example) a
mail user agent, which is receiving mail that is encrypted to both the
old key and the new key.  Which GNUPGHOME should that mail user agent be
pointed to in order to handle incoming mail? (not to mention accessing
historical mail archives)

> From my experience (and meditation) I have arrived in the conclusion
> that usually it is better to keep only one secret key per context (or
> GNUPGHOME), and to change the context whenever you need to use a
> different key.

This is a super interesting observation.  Do other people have the same
experience?  it seems to me that keeping the public keyrings in sync
alone would be a fair amount of hassle.  Can you describe any other
scenarios where that might improve the user experience?  I want to
really focus on making it easy for even a non-technical user to do
sensible things easily, in particular here: a planned, phased-in,
non-sudden key transition.  Can you give other examples of where the
separated secret keyring is concretely useful and usable?

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190131/05ade4b9/attachment.sig>