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: References: Message-ID: On Sat, Dec 29, 2018 at 5:01 PM brent s. 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: References: Message-ID: 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: 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: 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: 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: 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 and the FTP is at I sync every 6 hours on a random minute from rsync://ftp.gnupg.org/ I noticed that most mirrors listed at 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: 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 --- 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 . + */ + +#include + +#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 --- 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 . + */ + +#include + +#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: References: 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: 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: References: 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: 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: 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: <1864384.JgDNukKA3z@esus> Message-ID: On Mon, Jan 7, 2019 at 10:47 AM Andre Heinecke 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: 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) ' 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 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: 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 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: 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: 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: 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: 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: References: <3c01ecd5-6e8f-f6e2-81e4-b547ee16ff2e@eckner.net> <201901110905.50013.bernhard@intevation.de> 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: 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> <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: 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: 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: 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: Hi all, when I call gpg to import some crap data, a proper error message is returned, e.g.: user at host:~$ gpg --import <<< 'some crap' gpg: no valid OpenPGP data found. gpg: Total number processed: 0 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 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) 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: 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 B 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: References: 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.: > > > user at host:~$ gpg --import <<< 'some crap' > gpg: no valid OpenPGP data found. > gpg: Total number processed: 0 > 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: 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: 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: 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 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: 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 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 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: 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: 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 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: 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: 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 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: 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: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: 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: References: <875zu84bog.fsf@fifthhorseman.net> 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: