From gniibe at fsij.org Wed Feb 1 11:53:32 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 01 Feb 2017 19:53:32 +0900 Subject: [LIBGPG-ERROR] Add Base64 decoder In-Reply-To: <87fujz37xr.fsf@wheatstone.g10code.de> References: <87efzl171q.fsf@fsij.org> <87efzk4fch.fsf@wheatstone.g10code.de> <87vasvy6ql.fsf@fsij.org> <87fujz37xr.fsf@wheatstone.g10code.de> Message-ID: <877f5ab2s3.fsf@fsij.org> Werner Koch wrote: > struct _gpgrt_b64state; > typedef struct _gpgrt_b64state *gpgrt_b64state_t; Thanks for your suggestion. I did that. Also, I added entries in visibility.h. And I added NEWS entry for API change. I found that the test in GnuPG is for manual testing. So, I wrote a simple test. Hopefully, this is the final version. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-Base64-decoder-0201.patch Type: text/x-diff Size: 17470 bytes Desc: Add Base64 decoder -- revision 3 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Feb 1 16:47:10 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Feb 2017 16:47:10 +0100 Subject: [PINENTRY PATCH] add efl-based frontend In-Reply-To: (Mike Blumenkrantz's message of "Mon, 30 Jan 2017 14:59:18 +0000") References: <20161012113515.675d5a30@Sir.Pimpleton> <87y41swi1i.fsf@europa.jade-hamburg.de> <87inso1r02.fsf@europa.jade-hamburg.de> <20161019100137.66563eb7@Sir.Pimpleton> <877f5kzpab.fsf@europa.jade-hamburg.de> <20170125081219.4d666e71@Sir.Pimpleton> Message-ID: <871svhx69t.fsf@wheatstone.g10code.de> On Mon, 30 Jan 2017 15:59, michael.blumenkrantz at gmail.com said: > in moderation because the patch size is 41kb which exceeds the mailing list > limit of 40kb. Approved and bumped the limit up to 60k. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 2 09:29:48 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Feb 2017 09:29:48 +0100 Subject: [PATCH] Add ability to specify a subkey. In-Reply-To: <1483229101-3908919.47615372.fv0104L03007020@rs146.luxsci.com> (Ben Kibbey's message of "Sat, 31 Dec 2016 19:04:20 -0500") References: <1483229101-3908919.47615372.fv0104L03007020@rs146.luxsci.com> Message-ID: <87poj1t2pv.fsf@wheatstone.g10code.de> On Sun, 1 Jan 2017 01:04, bjk at luxsci.net said: > a keyid or fingerprint. It's up to the user to set the .exact member of > gpgme_subkey_t to have the '!' appended before calling gpg otherwise it The struct returned by GPGME need to be considered read-only for a user of GPGME: Those structures shall be considered read-only and an application must not allocate such a structure on its own. (in the section Result Management). Thus a different way to specify this is required. Given that this is will be a rarely used feature, what about a gpgme_key_set_flag function which could works similar to the gpgme_data_set_flag function. That would be more flexible than to add dedicated functions for marking a subkey or to provide extra versions of the encrypt and sign functions to take a selection criteria for the subkey. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bjk at luxsci.net Sat Feb 4 04:23:37 2017 From: bjk at luxsci.net (Ben Kibbey) Date: Fri, 3 Feb 2017 22:23:37 -0500 Subject: [PATCH] Add ability to specify a subkey. In-Reply-To: <87poj1t2pv.fsf@wheatstone.g10code.de> References: <1483229101-3908919.47615372.fv0104L03007020@rs146.luxsci.com> <87poj1t2pv.fsf@wheatstone.g10code.de> Message-ID: <1486178642-5970966.65282142.fv143Ncbo018164@rs146.luxsci.com> On Thu, Feb 02, 2017 at 09:29:48AM +0100, Werner Koch wrote: > On Sun, 1 Jan 2017 01:04, bjk at luxsci.net said: > > > a keyid or fingerprint. It's up to the user to set the .exact member of > > gpgme_subkey_t to have the '!' appended before calling gpg otherwise it > > The struct returned by GPGME need to be considered read-only for a user > of GPGME: > > Those structures shall be considered read-only and an application > must not allocate such a structure on its own. > > (in the section Result Management). Thus a different way to specify > this is required. > > Given that this is will be a rarely used feature, what about a > gpgme_key_set_flag function which could works similar to the > gpgme_data_set_flag function. That would be more flexible than to add > dedicated functions for marking a subkey or to provide extra versions of > the encrypt and sign functions to take a selection criteria for the > subkey. Attached is a patch to add gpgme_subkey_set_flag(). Is this what you had in mind? -- Ben Kibbey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-gpgme_subkey_set_flag.patch Type: text/x-diff Size: 6716 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Feb 4 07:23:32 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 4 Feb 2017 01:23:32 -0500 Subject: [PATCH] gpg: fix aliases --list-key, --list-sig, and --check-sig. Message-ID: <20170204062332.22065-1-dkg@fifthhorseman.net> * g10/gpg.c: ARGPARSE_OPTS opts[]: define commands with ARGPARSE_c instead of ARGPARSE_s_n. -- These three entries are commands, but they're being treated as a string-based option for some reason. However, if you try to use them concurrently with another command like --clearsign, you'll get "gpg: conflicting commands". Furthermore, because they're marked as options, their flags differ from the commands that they alias, they cause ambiguity in abbreviation (e.g. try "gpg --list-ke") which should have been fixed by 7249ab0f95d1f6cb8ee61eefedc79801bb56398f. Marking them explicitly as commands for argparse should be more accurate and should resolve the abbreviation ambiguity issue. Signed-off-by: Daniel Kahn Gillmor --- g10/gpg.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/g10/gpg.c b/g10/gpg.c index f9039ae09..e280c2249 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -728,9 +728,9 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_s_n (oWithKeyData,"with-key-data", "@"), ARGPARSE_s_n (oWithSigList,"with-sig-list", "@"), ARGPARSE_s_n (oWithSigCheck,"with-sig-check", "@"), - ARGPARSE_s_n (aListKeys, "list-key", "@"), /* alias */ - ARGPARSE_s_n (aListSigs, "list-sig", "@"), /* alias */ - ARGPARSE_s_n (aCheckKeys, "check-sig", "@"), /* alias */ + ARGPARSE_c (aListKeys, "list-key", "@"), /* alias */ + ARGPARSE_c (aListSigs, "list-sig", "@"), /* alias */ + ARGPARSE_c (aCheckKeys, "check-sig", "@"), /* alias */ ARGPARSE_s_n (oSkipVerify, "skip-verify", "@"), ARGPARSE_s_n (oSkipHiddenRecipients, "skip-hidden-recipients", "@"), ARGPARSE_s_n (oNoSkipHiddenRecipients, "no-skip-hidden-recipients", "@"), -- 2.11.0 From dkg at fifthhorseman.net Sat Feb 4 08:13:39 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 04 Feb 2017 02:13:39 -0500 Subject: [PATCH] gpg: fix aliases --list-key, --list-sig, and --check-sig. In-Reply-To: <20170204062332.22065-1-dkg@fifthhorseman.net> References: <20170204062332.22065-1-dkg@fifthhorseman.net> Message-ID: <87poiyqvh8.fsf@alice.fifthhorseman.net> On Sat 2017-02-04 01:23:32 -0500, Daniel Kahn Gillmor wrote: > * g10/gpg.c: ARGPARSE_OPTS opts[]: define commands with ARGPARSE_c > instead of ARGPARSE_s_n. I sent this to the list instead of pushing it directly because i'm not confident that i fully understand all the implications of this switch (or why these three things were _s_n instead of _c in the first place), and i'm hoping to get some feedback from folks more comfortable with GnuPG's ARGPARSE mechanics. comments welcome! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Sun Feb 5 08:22:27 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 5 Feb 2017 02:22:27 -0500 Subject: [PINENTRY PATCH 2/3] core: Only scan for the command line if probably on the same host. In-Reply-To: <20170205072228.16577-1-dkg@fifthhorseman.net> References: <20170205072228.16577-1-dkg@fifthhorseman.net> Message-ID: <20170205072228.16577-2-dkg@fifthhorseman.net> * pinentry/pinentry.c (pinentry_get_title): Check the current hostname and make sure it matches. If it does not, do not bother looking for the command line. -- If we don't do this, and the agent is forwarded from somewhere else, pinentry will be looking up arbitrary process command lines. Signed-off-by: Daniel Kahn Gillmor --- pinentry/pinentry.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c index 8cf712d..d8d7a62 100644 --- a/pinentry/pinentry.c +++ b/pinentry/pinentry.c @@ -28,6 +28,7 @@ #include #include #include +#include #ifndef HAVE_W32CE_SYSTEM # include #endif @@ -438,19 +439,22 @@ pinentry_get_title (pinentry_t pe) else if (pe->owner_pid) { char buf[200]; - char *cmdline = get_cmdline (pe->owner_pid); + struct utsname utsbuf; + char *cmdline = NULL; + + if (pe->owner_host && + !uname (&utsbuf) && utsbuf.nodename && + !strcmp (utsbuf.nodename, pe->owner_host)) + cmdline = get_cmdline (pe->owner_pid); if (pe->owner_host && cmdline) snprintf (buf, sizeof buf, "[%lu]@%s (%s)", pe->owner_pid, pe->owner_host, cmdline); - else if (cmdline) - snprintf (buf, sizeof buf, "[%lu] (%s)", - pe->owner_pid, cmdline); else if (pe->owner_host) snprintf (buf, sizeof buf, "[%lu]@%s", pe->owner_pid, pe->owner_host); else - snprintf (buf, sizeof buf, "[%lu]", + snprintf (buf, sizeof buf, "[%lu] ", pe->owner_pid); buf[sizeof buf - 1] = 0; free (cmdline); -- 2.11.0 From dkg at fifthhorseman.net Sun Feb 5 08:22:26 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 5 Feb 2017 02:22:26 -0500 Subject: [PINENTRY PATCH 1/3] core: Clean up command line extraction. Message-ID: <20170205072228.16577-1-dkg@fifthhorseman.net> * pinentry/pinentry.c (get_cmdline): Avoid trailing space, and return NULL when no bytes were read from /proc. Signed-off-by: Daniel Kahn Gillmor --- pinentry/pinentry.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c index 517a033..8cf712d 100644 --- a/pinentry/pinentry.c +++ b/pinentry/pinentry.c @@ -410,14 +410,16 @@ get_cmdline (unsigned long pid) fclose (fp); return NULL; } - /* Arguments are delimites by Nuls. We should do proper quoting but + fclose (fp); + if (n == 0) + return NULL; + /* Arguments are delimited by Nuls. We should do proper quoting but * that can be a bit complicated, thus we simply replace the Nuls by * spaces. */ for (i=0; i < n; i++) - if (!buffer[i]) + if (!buffer[i] && i < n-1) buffer[i] = ' '; buffer[i] = 0; /* Make sure the last byte is the string terminator. */ - fclose (fp); return strdup (buffer); } -- 2.11.0 From dkg at fifthhorseman.net Sun Feb 5 08:22:28 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 5 Feb 2017 02:22:28 -0500 Subject: [PINENTRY PATCH 3/3] core: Expect (and verify) a uid on "owner" option. In-Reply-To: <20170205072228.16577-1-dkg@fifthhorseman.net> References: <20170205072228.16577-1-dkg@fifthhorseman.net> Message-ID: <20170205072228.16577-3-dkg@fifthhorseman.net> * pinentry/pinentry.h (struct pinentry): Add field 'owner_uid'. * pinentry/pinentry.c (pinentry_reset): Handle this new field. (get_pid_name_for_uid): New. Atomic check for the base process name contingent on process ownership. (pinentry_get_title): Only scan for full commandline if the process actually belongs to the claimed uid. (option_handler): Option "owner" now expects "pid uid hostname". -- This requires an update to gpg's use of the "owner" option to emit the uid (which will follow shortly). It is not as atomic as it should be. In particular, there's a race condition between reading from /proc/PID/status and reading from /proc/PID/cmdline, but it's a much smaller race than there was previously. Signed-off-by: Daniel Kahn Gillmor --- pinentry/pinentry.c | 94 +++++++++++++++++++++++++++++++++++++++++++++-------- pinentry/pinentry.h | 6 +++- 2 files changed, 86 insertions(+), 14 deletions(-) diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c index d8d7a62..ea34063 100644 --- a/pinentry/pinentry.c +++ b/pinentry/pinentry.c @@ -100,6 +100,7 @@ pinentry_reset (int use_defaults) char *default_tt_hide = pinentry.default_tt_hide; char *touch_file = pinentry.touch_file; unsigned long owner_pid = pinentry.owner_pid; + int owner_uid = pinentry.owner_uid; char *owner_host = pinentry.owner_host; /* These options are set from the command line. Don't reset @@ -174,6 +175,8 @@ pinentry_reset (int use_defaults) pinentry.color_bg = PINENTRY_COLOR_DEFAULT; pinentry.color_so = PINENTRY_COLOR_DEFAULT; pinentry.color_so_bright = 0; + + pinentry.owner_uid = -1; } else /* Restore the options. */ { @@ -192,6 +195,7 @@ pinentry_reset (int use_defaults) pinentry.default_tt_hide = default_tt_hide; pinentry.touch_file = touch_file; pinentry.owner_pid = owner_pid; + pinentry.owner_uid = owner_uid; pinentry.owner_host = owner_host; pinentry.debug = debug; @@ -426,6 +430,54 @@ get_cmdline (unsigned long pid) } +/* Atomically ask the kernel for information about process PID. + * Return a malloc'ed copy of the process name as long as the process + * uid matches UID. If it cannot determine that the process has uid + * UID, it returns NULL. + + * This is not as informative as get_cmdline, but it verifies that the + * process does belong to the user in question. + */ +static char * +get_pid_name_for_uid (unsigned long pid, int uid) +{ + char buffer[400]; + FILE *fp; + size_t end, n; + char *uidstr; + + snprintf (buffer, sizeof buffer, "/proc/%lu/status", pid); + buffer[sizeof buffer - 1] = 0; + + fp = fopen (buffer, "rb"); + if (!fp) + return NULL; + n = fread (buffer, 1, sizeof buffer - 1, fp); + if (n < sizeof buffer -1 && ferror (fp)) + { + /* Some error occurred. */ + fclose (fp); + return NULL; + } + fclose (fp); + if (n == 0) + return NULL; + if (strncmp (buffer, "Name:\t", 6)) + return NULL; + end = strcspn (buffer + 6, "\n") + 6; + buffer[end] = 0; + + /* check that uid matches what we expect */ + uidstr = strstr (buffer + end + 1, "\nUid:\t"); + if (!uidstr) + return NULL; + if (atoi (uidstr + 6) != uid) + return NULL; + + return strdup (buffer + 6); +} + + /* Return a malloced string with the title. The caller mus free the * string. If no title is available or the title string has an error * NULL is returned. */ @@ -440,16 +492,21 @@ pinentry_get_title (pinentry_t pe) { char buf[200]; struct utsname utsbuf; + char *pidname = NULL; char *cmdline = NULL; if (pe->owner_host && !uname (&utsbuf) && utsbuf.nodename && !strcmp (utsbuf.nodename, pe->owner_host)) - cmdline = get_cmdline (pe->owner_pid); + { + pidname = get_pid_name_for_uid (pe->owner_pid, pe->owner_uid); + if (pidname) + cmdline = get_cmdline (pe->owner_pid); + } - if (pe->owner_host && cmdline) + if (pe->owner_host && (cmdline || pidname)) snprintf (buf, sizeof buf, "[%lu]@%s (%s)", - pe->owner_pid, pe->owner_host, cmdline); + pe->owner_pid, pe->owner_host, cmdline ? cmdline : pidname); else if (pe->owner_host) snprintf (buf, sizeof buf, "[%lu]@%s", pe->owner_pid, pe->owner_host); @@ -457,6 +514,7 @@ pinentry_get_title (pinentry_t pe) snprintf (buf, sizeof buf, "[%lu] ", pe->owner_pid); buf[sizeof buf - 1] = 0; + free (pidname); free (cmdline); title = strdup (buf); } @@ -1004,24 +1062,34 @@ option_handler (assuan_context_t ctx, const char *key, const char *value) free (pinentry.owner_host); pinentry.owner_host = NULL; + pinentry.owner_uid = -1; + pinentry.owner_pid = 0; errno = 0; along = strtol (value, &endp, 10); - if (along < 0 || errno) - pinentry.owner_pid = 0; - else + if (along && !errno) { pinentry.owner_pid = (unsigned long)along; - while (endp && *endp == ' ') - endp++; if (*endp) { - pinentry.owner_host = strdup (endp); - if (pinentry.owner_host) + errno = 0; + along = strtol (endp, &endp, 10); + if (along >= 0 && !errno) { - for (endp=pinentry.owner_host; *endp && *endp != ' '; endp++) - ; - *endp = 0; + pinentry.owner_uid = (int)along; + if (endp) + { + while (*endp == ' ') + endp++; + if (*endp) + { + pinentry.owner_host = strdup (endp); + for (endp=pinentry.owner_host; + *endp && *endp != ' '; endp++) + ; + *endp = 0; + } + } } } } diff --git a/pinentry/pinentry.h b/pinentry/pinentry.h index 868b4d8..a7ca891 100644 --- a/pinentry/pinentry.h +++ b/pinentry/pinentry.h @@ -96,7 +96,11 @@ struct pinentry * which actually triggered the the pinentry. For example gpg. */ unsigned long owner_pid; - /* The malloced hostname of the owener or NULL. */ + /* The numeric uid (user ID) of the owner process or -1 if not + * known. */ + int owner_uid; + + /* The malloced hostname of the owner or NULL. */ char *owner_host; /* The window ID of the parent window over which the pinentry window -- 2.11.0 From dkg at fifthhorseman.net Sun Feb 5 08:23:30 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 5 Feb 2017 02:23:30 -0500 Subject: [PATCH] agent: Send pinentry the uid of connecting process where possible. In-Reply-To: <20170205072228.16577-3-dkg@fifthhorseman.net> References: <20170205072228.16577-3-dkg@fifthhorseman.net> Message-ID: <20170205072330.16705-1-dkg@fifthhorseman.net> * agent/agent.h (server_control_s): Add field 'client_uid'. * agent/call-pinentry.c (start_pinentry): Add uid field to assuan option "owner" sent to pinentry. * agent/command-ssh.c (peer_info_s): New static struct. (get_client_pid): Rename to... (get_client_info): Here, and extract uid in addition to pid. (start_command_handler_ssh): Use get_client_info() instead of get_client_pid(). * agent/command.c (start_command_handler): Use assuan_get_peercred instead of assuan_get_pid. -- This requires a concurrent update to pinentry to handle the new uid field. Distributing the uid as well as the pid makes it harder for a different user on the same machine to take advantage of any race conditions between when a requesting process might ask for something that needs pinentry, and when pinentry gets around to inspecting the state of that process. Signed-off-by: Daniel Kahn Gillmor --- agent/agent.h | 1 + agent/call-pinentry.c | 5 +++-- agent/command-ssh.c | 29 +++++++++++++++++++++++------ agent/command.c | 23 +++++++++++++++++------ 4 files changed, 44 insertions(+), 14 deletions(-) diff --git a/agent/agent.h b/agent/agent.h index 217838472..23064a703 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -219,6 +219,7 @@ struct server_control_s char *lc_ctype; char *lc_messages; unsigned long client_pid; + int client_uid; /* The current pinentry mode. */ pinentry_mode_t pinentry_mode; diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index 99316653b..9d62b442f 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -553,8 +553,9 @@ start_pinentry (ctrl_t ctrl) nodename = utsbuf.nodename; #endif /*!HAVE_W32_SYSTEM*/ - if ((optstr = xtryasprintf ("OPTION owner=%lu %s", - ctrl->client_pid, nodename))) + if ((optstr = xtryasprintf ("OPTION owner=%lu %d %s", + ctrl->client_pid, ctrl->client_uid, + nodename))) { assuan_transact (entry_ctx, optstr, NULL, NULL, NULL, NULL, NULL, NULL); diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 1d4453c84..40fd481ec 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -248,6 +248,11 @@ static gpg_error_t ssh_signature_encoder_eddsa (ssh_key_type_spec_t *spec, static gpg_error_t ssh_key_extract_comment (gcry_sexp_t key, char **comment); +struct peer_info_s +{ + unsigned long pid; + int uid; +}; /* Global variables. */ @@ -3492,10 +3497,12 @@ ssh_request_process (ctrl_t ctrl, estream_t stream_sock) /* Return the peer's pid. Stripped down code from libassuan. */ -static unsigned long -get_client_pid (int fd) +static struct peer_info_s +get_client_info (int fd) { + struct peer_info_s out; pid_t client_pid = (pid_t)(-1); + uid_t client_uid = (uid_t)-1; #ifdef HAVE_SO_PEERCRED { @@ -3503,7 +3510,10 @@ get_client_pid (int fd) socklen_t cl = sizeof cr; if ( !getsockopt (fd, SOL_SOCKET, SO_PEERCRED, &cr, &cl)) - client_pid = cr.pid; + { + client_pid = cr.pid; + client_uid = cr.uid; + } } #elif defined (HAVE_GETPEERUCRED) { @@ -3511,7 +3521,8 @@ get_client_pid (int fd) if (getpeerucred (fd, &ucred) != -1) { - client_pid= ucred_getpid (ucred); + client_pid = ucred_getpid (ucred); + client_uid = ucred_geteuid (ucred); ucred_free (ucred); } } @@ -3522,10 +3533,13 @@ get_client_pid (int fd) if (getsockopt (fd, 0, LOCAL_PEEREID, &unp, &unpl) != -1) client_pid = unp.unp_pid; + client_uid = unp.unp_euid; } #endif - return client_pid == (pid_t)(-1)? 0 : (unsigned long)client_pid; + out.pid = (client_pid == (pid_t)(-1)? 0 : (unsigned long)client_pid); + out.uid = (int)client_uid; + return out; } @@ -3536,12 +3550,15 @@ start_command_handler_ssh (ctrl_t ctrl, gnupg_fd_t sock_client) estream_t stream_sock = NULL; gpg_error_t err; int ret; + struct peer_info_s peer_info; err = agent_copy_startup_env (ctrl); if (err) goto out; - ctrl->client_pid = get_client_pid (FD2INT(sock_client)); + peer_info = get_client_info (FD2INT(sock_client)); + ctrl->client_pid = peer_info.pid; + ctrl->client_uid = peer_info.uid; /* Create stream from socket. */ stream_sock = es_fdopen (FD2INT(sock_client), "r+"); diff --git a/agent/command.c b/agent/command.c index c8b34e988..1aef6a154 100644 --- a/agent/command.c +++ b/agent/command.c @@ -3288,7 +3288,7 @@ start_command_handler (ctrl_t ctrl, gnupg_fd_t listen_fd, gnupg_fd_t fd) for (;;) { - pid_t client_pid; + assuan_peercred_t client_creds; rc = assuan_accept (ctx); if (gpg_err_code (rc) == GPG_ERR_EOF || rc == -1) @@ -3301,12 +3301,23 @@ start_command_handler (ctrl_t ctrl, gnupg_fd_t listen_fd, gnupg_fd_t fd) break; } - client_pid = assuan_get_pid (ctx); - ctrl->server_local->connect_from_self = (client_pid == getpid ()); - if (client_pid != ASSUAN_INVALID_PID) - ctrl->client_pid = (unsigned long)client_pid; + rc = assuan_get_peercred (ctx, &client_creds); + if (rc) + { + log_info ("Assuan get_peercred failed: %s\n", gpg_strerror (rc)); + ctrl->client_pid = 0; + ctrl->client_uid = -1; + } else - ctrl->client_pid = 0; + { + ctrl->server_local->connect_from_self = + (client_creds->pid == getpid ()); + if (client_creds->pid != ASSUAN_INVALID_PID) + ctrl->client_pid = (unsigned long)client_creds->pid; + else + ctrl->client_pid = 0; + ctrl->client_uid = client_creds->uid; + } rc = assuan_process (ctx); if (rc) -- 2.11.0 From wk at gnupg.org Sun Feb 5 18:08:54 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 05 Feb 2017 18:08:54 +0100 Subject: [PATCH] gpg: fix aliases --list-key, --list-sig, and --check-sig. In-Reply-To: <87poiyqvh8.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 04 Feb 2017 02:13:39 -0500") References: <20170204062332.22065-1-dkg@fifthhorseman.net> <87poiyqvh8.fsf@alice.fifthhorseman.net> Message-ID: <87tw88lg49.fsf@wheatstone.g10code.de> On Sat, 4 Feb 2017 08:13, dkg at fifthhorseman.net said: > I sent this to the list instead of pushing it directly because i'm not > confident that i fully understand all the implications of this switch Should be fine. You changed only the aliases and the rela commands where already marked as commands. In the past these commands were treated specially to implement PGP-2 combinations of commands. But we dropped this for 2.1 anyway. > (or why these three things were _s_n instead of _c in the first > place), and i'm hoping to get some feedback from folks more > comfortable with GnuPG's ARGPARSE mechanics. Commands and options only differ in that gpg tries to detect conflicts between commands - options may be given several times. There is also a slighly different error message. I pushed your change. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Sun Feb 5 22:31:35 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 5 Feb 2017 16:31:35 -0500 Subject: [PATCH] g10: Skip signing keys where no secret key is available. Message-ID: <20170205213135.17465-1-dkg@fifthhorseman.net> From: Simon Arlott * g10/getkey.c (finish_lookup): When requiring PUBKEY_USAGE_SIG, skip over keys where no signing key is available. -- This should only be relevant when gpg is required to choose which key to sign with -- if verifying signatures, we already know which subkey to look at, and indeed gpg doesn't seem to have a problem with this. This patch comes from https://bugs.gnupg.org/gnupg/file793/sign-fix.patch I (dkg) have reviewed and tested it with missing local keys, and it makes sense to me as the default behavior. If the user has the secret key for a signing-capable subkey available and the command is --sign, it should be used. If the user has explicitly specified a subkey that happens to be missing (e.g. with the trailing ! for --default-key 0x${FPR}!) then this does not override that behavior (the signature will still fail). GnuPG-bug-id: 1967 Debian-bug-id: 834922 Signed-off-by: Daniel Kahn Gillmor --- g10/getkey.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/g10/getkey.c b/g10/getkey.c index e39de28ae..d2349ee6c 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -3523,6 +3523,13 @@ finish_lookup (kbnode_t keyblock, unsigned int req_usage, int want_exact, continue; } + if ((req_usage & PUBKEY_USAGE_SIG) && agent_probe_secret_key (NULL, pk)) + { + if (DBG_LOOKUP) + log_debug ("\tno secret key for signing\n"); + continue; + } + if (DBG_LOOKUP) log_debug ("\tsubkey might be fine\n"); /* In case a key has a timestamp of 0 set, we make sure -- 2.11.0 From dkg at fifthhorseman.net Mon Feb 6 05:40:24 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 05 Feb 2017 23:40:24 -0500 Subject: [GPGME PATCH] doc: Document that gpgme_op_genkey() parms parameter is not XML. In-Reply-To: <20170126233912.8136-1-dkg@fifthhorseman.net> References: <87efzpbsio.fsf@wheatstone.g10code.de> <20170126233912.8136-1-dkg@fifthhorseman.net> Message-ID: <87h948lyo7.fsf@alice.fifthhorseman.net> On Thu 2017-01-26 18:39:12 -0500, Daniel Kahn Gillmor wrote: > * doc/gpgme.texi (GnupgKeyParms): document that input format is not > true XML. Hearing no objections, I've gone ahead and pushed this. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From patrick at enigmail.net Mon Feb 6 10:57:59 2017 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 6 Feb 2017 10:57:59 +0100 Subject: [PATCH] g10: Skip signing keys where no secret key is available. In-Reply-To: <20170205213135.17465-1-dkg@fifthhorseman.net> References: <20170205213135.17465-1-dkg@fifthhorseman.net> Message-ID: <6bda9d2a-ff86-f9b5-c6bd-e6347e6848fc@enigmail.net> On 05.02.17 22:31, Daniel Kahn Gillmor wrote: > From: Simon Arlott > > * g10/getkey.c (finish_lookup): When requiring PUBKEY_USAGE_SIG, skip > over keys where no signing key is available. > > -- > > This should only be relevant when gpg is required to choose which key > to sign with -- if verifying signatures, we already know which subkey > to look at, and indeed gpg doesn't seem to have a problem with this. > > This patch comes from > https://bugs.gnupg.org/gnupg/file793/sign-fix.patch > > I (dkg) have reviewed and tested it with missing local keys, and it > makes sense to me as the default behavior. If the user has the secret > key for a signing-capable subkey available and the command is --sign, > it should be used. > > If the user has explicitly specified a subkey that happens to be > missing (e.g. with the trailing ! for --default-key 0x${FPR}!) then > this does not override that behavior (the signature will still fail). > > GnuPG-bug-id: 1967 > Debian-bug-id: 834922 > > Signed-off-by: Daniel Kahn Gillmor > --- > g10/getkey.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/g10/getkey.c b/g10/getkey.c > index e39de28ae..d2349ee6c 100644 > --- a/g10/getkey.c > +++ b/g10/getkey.c > @@ -3523,6 +3523,13 @@ finish_lookup (kbnode_t keyblock, unsigned int req_usage, int want_exact, > continue; > } > > + if ((req_usage & PUBKEY_USAGE_SIG) && agent_probe_secret_key (NULL, pk)) > + { > + if (DBG_LOOKUP) > + log_debug ("\tno secret key for signing\n"); > + continue; > + } > + > if (DBG_LOOKUP) > log_debug ("\tsubkey might be fine\n"); > /* In case a key has a timestamp of 0 set, we make sure Would this patch still issue a "MISSING_KEY" line for --status-fd? If no, you break existing logic (which for example Enigmail relies on). -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jestedfa at microsoft.com Mon Feb 6 22:49:39 2017 From: jestedfa at microsoft.com (Jeffrey Stedfast) Date: Mon, 6 Feb 2017 21:49:39 +0000 Subject: gpgme-1.8.0 does not build on Mac OS X Message-ID: <3F14F3E3-192F-41A2-B989-DB2953108327@microsoft.com> Hey all, It turns out that gpgme-1.8.0 does not build on Mac OS X (tested only on Sierra 10.12.2 with Xcode 8.2), but 1.7.0 does. The compile failures are all from lang/cpp/src/*result.cpp due to strdup() being undeclared. Source files such as src/get-env.c, data.c, etc also warn about strdup() being undeclared but do not error out. I suspect the issue is due to c++ being more strict. I did a quick comparison of gpgme-1.7.0 and 1.8.0 and discovered the problem was that 1.8.0 added #include ?config.h?, so it appears that something in config.h is making the c++ compiler fail on Mac OS X. I took a look at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/string.h and it only defined strdup() if __DARWIN_C_LEVEL >= 200112L (stpcpy(), another source of compiler *warnings*, is likewise only defined if __DARWIN_C_LEVEL >= 200809L). After a bit of investigation, I eventually came to sys/cdefs.h which has the following: /* Deal with various X/Open Portability Guides and Single UNIX Spec. */ #ifdef _XOPEN_SOURCE #if _XOPEN_SOURCE - 0L >= 700L && (!defined(_POSIX_C_SOURCE) || _POSIX_C_SOURCE - 0L < 200809L) #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 200809L #elif _XOPEN_SOURCE - 0L >= 600L && (!defined(_POSIX_C_SOURCE) || _POSIX_C_SOURCE - 0L < 200112L) #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 200112L #elif _XOPEN_SOURCE - 0L >= 500L && (!defined(_POSIX_C_SOURCE) || _POSIX_C_SOURCE - 0L < 199506L) #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 199506L #endif #endif Sure enough, gpgme?s config.h defines _XOPEN_SOURCE to be 500. After modifying the definition of _XOPEN_SOURCE to 700 in my config.h, gpgme-1.8.0 built fine although there are still a few warnings in the c sources: conversion.c:519:14: warning: implicit declaration of function 'timegm' is invalid in C99 [-Wimplicit-function-declaration] return timegm (&buf); ^ data.c:196:11: warning: comparison of unsigned enum expression < 0 is always false [-Wtautological-compare] if (enc < 0 || enc > GPGME_DATA_ENCODING_MIME) ~~~ ^ ~ key.c:293:16: warning: expression which evaluates to zero treated as a null pointer constant of type 'char *' [-Wnon-literal-null-conversion] sig->uid = '\0'; ^~~~ engine-gpg.c:1160:11: warning: comparison of unsigned enum expression >= 0 is always true [-Wtautological-compare] if (r >= 0) ~ ^ ~ engine-gpg.c:2512:15: warning: implicit declaration of function 'asprintf' is invalid in C99 [-Wimplicit-function-declaration] if (asprintf (r_line, ^ engine-gpgsm.c:399:11: warning: implicit declaration of function 'asprintf' is invalid in C99 [-Wimplicit-function-declaration] if (asprintf (&optstr, "OPTION display=%s", dft_display) < 0) ^ engine-gpgsm.c:639:21: warning: comparison of unsigned enum expression >= 0 is always true [-Wtautological-compare] if (r >= 0 && status_fnc && !cb_err) ~ ^ ~ engine-gpgsm.c:990:10: warning: comparison of unsigned enum expression >= 0 is always true [-Wtautological-compare] if (r >= 0) ~ ^ ~ Looking into asprintf() being undefined, it turns out stdio.h only defines asprintf() on Mac OS X if __DARWIN_C_LEVEL >= __DARWIN_C_FULL and __DARWIN_C_FULL is defined to be 900000L, so configure.ac may also need to define __DARWIN_C_LEVEL as 900000L for Mac OS X rather than trying to define _XOPEN_SOURCE alone. Hope that helps, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Tue Feb 7 01:22:38 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 6 Feb 2017 19:22:38 -0500 Subject: gpgme-1.8.0 does not build on Mac OS X In-Reply-To: <3F14F3E3-192F-41A2-B989-DB2953108327@microsoft.com> References: <3F14F3E3-192F-41A2-B989-DB2953108327@microsoft.com> Message-ID: <8245a36e-e466-b7d4-dd07-8eecf8d856e9@sixdemonbag.org> > It turns out that gpgme-1.8.0 does not build on Mac OS X (tested only on > Sierra 10.12.2 with Xcode 8.2), but 1.7.0 does. Known bug, but thank you for the report. :) https://bugs.gnupg.org/gnupg/issue2910 From justus at g10code.com Tue Feb 7 11:36:11 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 07 Feb 2017 11:36:11 +0100 Subject: gpgme-1.8.0 does not build on Mac OS X In-Reply-To: <8245a36e-e466-b7d4-dd07-8eecf8d856e9@sixdemonbag.org> References: <3F14F3E3-192F-41A2-B989-DB2953108327@microsoft.com> <8245a36e-e466-b7d4-dd07-8eecf8d856e9@sixdemonbag.org> Message-ID: <8737fqguec.fsf@thinkbox.jade-hamburg.de> "Robert J. Hansen" writes: >> It turns out that gpgme-1.8.0 does not build on Mac OS X (tested only on >> Sierra 10.12.2 with Xcode 8.2), but 1.7.0 does. > > Known bug, but thank you for the report. :) > > https://bugs.gnupg.org/gnupg/issue2910 Yes, this pops up again and again. On our build server we do exactly what Jeffrey suggested, and we could just do it in our configure scripts, like we set _GNU_SOURCE on glibc systems. The problem is mostly that we have little experience with the Apple environment, and did not feel confident about just doing that. But I guess we should just do that. Thoughts? Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jestedfa at microsoft.com Tue Feb 7 17:28:31 2017 From: jestedfa at microsoft.com (Jeffrey Stedfast) Date: Tue, 7 Feb 2017 16:28:31 +0000 Subject: gpgme-1.8.0 does not build on Mac OS X In-Reply-To: <8737fqguec.fsf@thinkbox.jade-hamburg.de> References: <3F14F3E3-192F-41A2-B989-DB2953108327@microsoft.com> <8245a36e-e466-b7d4-dd07-8eecf8d856e9@sixdemonbag.org> <8737fqguec.fsf@thinkbox.jade-hamburg.de> Message-ID: <034696D3-D91A-4C09-B731-E51CB05371CE@microsoft.com> I most most of my development on Mac these days. Based on my research and testing out the solution I proposed, I feel confident that this is the correct fix. Just my $0.02 Jeff On 2/7/17, 5:36 AM, "Gnupg-devel on behalf of Justus Winter" wrote: "Robert J. Hansen" writes: >> It turns out that gpgme-1.8.0 does not build on Mac OS X (tested only on >> Sierra 10.12.2 with Xcode 8.2), but 1.7.0 does. > > Known bug, but thank you for the report. :) > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.gnupg.org%2Fgnupg%2Fissue2910&data=02%7C01%7Cjestedfa%40microsoft.com%7C7b0b08992b8d4eb901f308d44f58c2b9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636220690029416250&sdata=JHUvj0oDOxgr6%2Ba4TF5Ks1xq686apq1X%2Fmzf451L6rw%3D&reserved=0 Yes, this pops up again and again. On our build server we do exactly what Jeffrey suggested, and we could just do it in our configure scripts, like we set _GNU_SOURCE on glibc systems. The problem is mostly that we have little experience with the Apple environment, and did not feel confident about just doing that. But I guess we should just do that. Thoughts? Justus From wk at gnupg.org Thu Feb 9 15:48:01 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Feb 2017 15:48:01 +0100 Subject: [GPGME PATCH] doc: Document that gpgme_op_genkey() parms parameter is not XML. In-Reply-To: <87h948lyo7.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sun, 05 Feb 2017 23:40:24 -0500") References: <87efzpbsio.fsf@wheatstone.g10code.de> <20170126233912.8136-1-dkg@fifthhorseman.net> <87h948lyo7.fsf@alice.fifthhorseman.net> Message-ID: <87wpcze7z2.fsf@wheatstone.g10code.de> On Mon, 6 Feb 2017 05:40, dkg at fifthhorseman.net said: > Hearing no objections, I've gone ahead and pushed this. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lugarius at riseup.net Thu Feb 9 19:34:05 2017 From: lugarius at riseup.net (lugarius at riseup.net) Date: Thu, 09 Feb 2017 19:34:05 +0100 Subject: Howto build GnuPG 2.1.18 and up without dynamic linking Message-ID: Hello Devs, I am a young programmer and I'd like to learn how to compile Gpg complete static on any Linux machine (in some kind of sandbox so that the instructions are the same on every distribution). I tried it by setting on every compilation the CFLAGS to ?-static? but it resulted with an error. What I learn here gets blogged so others don't have to ask again. (I only need the gpg2 binary if it helps to cut out some dependencies) Thank you. Lugarius From dkg at fifthhorseman.net Fri Feb 10 19:51:25 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Feb 2017 13:51:25 -0500 Subject: Howto build GnuPG 2.1.18 and up without dynamic linking In-Reply-To: References: Message-ID: <87fujlswuq.fsf@alice.fifthhorseman.net> Hi lugarius-- On Thu 2017-02-09 13:34:05 -0500, lugarius at riseup.net wrote: > I am a young programmer and I'd like to learn how to compile Gpg > complete static on any Linux machine > (in some kind of sandbox so that the instructions are the same on every > distribution). > > I tried it by setting on every compilation the CFLAGS to ?-static? but > it resulted with an error. > What I learn here gets blogged so others don't have to ask again. > (I only need the gpg2 binary if it helps to cut out some dependencies) If you're interested, you might take a look at the debian packaging, which builds "gpgv-static" with basically the same goals that you have: https://sources.debian.net/src/gnupg2/2.1.18-4/debian/rules/ sorry that the rules file there is a little hard to read, it's trying to be clever, taking advantage of debian infrastructure, and then trying to build something useful cross-platform. The main distinction between gpgv-static and the minimalist gpgv built for udeb (debian installer use) is just the use of the -static option in LDFLAGS: https://sources.debian.net/src/gnupg2/2.1.18-4/debian/rules/#L45 hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From alon.barlev at gmail.com Sat Feb 11 22:00:05 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 11 Feb 2017 23:00:05 +0200 Subject: gpg --card-status always create proxy private keys Message-ID: Hi, This is a change in behaviour, I believe resulted by this[1] commit. Everytime gpg --card-status is executed the proxy private keys at ~/.gnupg/private-keys-v1.d/ are created, also if no matching public key in gpg. It has the side effect of having duplicate keys when trying to generate keys using gpg --card-edit without actually re-generate the key on the card (return the same keygrip). As a result usage of scd which only capable of reusing keys such as PKCS#11 is now broken. Interesting is that these keys are not available using gpg --list-secret-keys as well so they cannot be removed. If this change was intentional and keys should be cached when invoking status even if not matching public keys, can you please consider rewriting the same key when generating the keys? ---- Real name: test1 Email address: test1 at test.com Comment: You selected this USER-ID: "test1 " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o Key generation failed: File exists --- Thanks, Alon [1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=82cbab906a3e72a98fdc16096f2f0451465969a2 From gniibe at fsij.org Mon Feb 13 09:03:54 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 13 Feb 2017 17:03:54 +0900 Subject: gpg --card-status always create proxy private keys In-Reply-To: References: Message-ID: <87y3xams9h.fsf@fsij.org> Alon Bar-Lev writes: > This is a change in behaviour, I believe resulted by this[1] commit. > Everytime gpg --card-status is executed the proxy private keys at > ~/.gnupg/private-keys-v1.d/ are created, also if no matching public > key in gpg. > > It has the side effect of having duplicate keys when trying to > generate keys using gpg --card-edit without actually re-generate the > key on the card (return the same keygrip). > > As a result usage of scd which only capable of reusing keys such as > PKCS#11 is now broken. I don't understand your description above. Could you elaborate? BTW, the change which introduce creating a shadow key by --card-status is this (not the one you addressed): commit f3f9f9b2844c35f7942ee904d5222523615cdad4 Author: Werner Koch Date: Fri Dec 12 12:35:45 2014 +0100 gpg: Let --card--status create a shadow key (card key stub). -- From alon.barlev at gmail.com Mon Feb 13 12:32:46 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 13 Feb 2017 13:32:46 +0200 Subject: gpg --card-status always create proxy private keys In-Reply-To: <87y3xams9h.fsf@fsij.org> References: <87y3xams9h.fsf@fsij.org> Message-ID: On 13 February 2017 at 10:03, NIIBE Yutaka wrote: > > Alon Bar-Lev writes: > > This is a change in behaviour, I believe resulted by this[1] commit. > > Everytime gpg --card-status is executed the proxy private keys at > > ~/.gnupg/private-keys-v1.d/ are created, also if no matching public > > key in gpg. > > > > It has the side effect of having duplicate keys when trying to > > generate keys using gpg --card-edit without actually re-generate the > > key on the card (return the same keygrip). > > > > As a result usage of scd which only capable of reusing keys such as > > PKCS#11 is now broken. > > I don't understand your description above. Could you elaborate? There are cases in which the card daemon (not the one gpg provides) will come with pre-defined generated keys. In this case the "generate" will actually return these keys instead of generating new ones. It has been working for about 10 years :) I do not mind if we cache these shadows, as long as after generate the cache will be rewritten with the new keys even if these already exist in the cache. However, I do not understand what is the point of caching keys that have no associated public key in the keyring (ether locally or obtained using the URL fetch). Assuming we would like to shadow everything, can we please rewrite when writing the shadow keys after generate (and in general)? > BTW, the change which introduce creating a shadow key by --card-status > is this (not the one you addressed): > > commit f3f9f9b2844c35f7942ee904d5222523615cdad4 > Author: Werner Koch > Date: Fri Dec 12 12:35:45 2014 +0100 > > gpg: Let --card--status create a shadow key (card key stub). > -- Thanks for the reference! Alon From wk at gnupg.org Mon Feb 13 15:24:29 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Feb 2017 15:24:29 +0100 Subject: gpg --card-status always create proxy private keys In-Reply-To: (Alon Bar-Lev's message of "Mon, 13 Feb 2017 13:32:46 +0200") References: <87y3xams9h.fsf@fsij.org> Message-ID: <87a89q184i.fsf@wheatstone.g10code.de> On Mon, 13 Feb 2017 12:32, alon.barlev at gmail.com said: > There are cases in which the card daemon (not the one gpg provides) If someone modifies a software, it is up to them to make it work. Filing this as a GnuPG bug is thus not a good idea. Although, Debian distributes scdaemon as a separate package, scdaemon is part of GnuPG proper and can't be replaced by other software while assuming that the whole system works as before. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From alon.barlev at gmail.com Mon Feb 13 15:31:24 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 13 Feb 2017 16:31:24 +0200 Subject: gpg --card-status always create proxy private keys In-Reply-To: <87a89q184i.fsf@wheatstone.g10code.de> References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> Message-ID: On 13 February 2017 at 16:24, Werner Koch wrote: > On Mon, 13 Feb 2017 12:32, alon.barlev at gmail.com said: > >> There are cases in which the card daemon (not the one gpg provides) > > If someone modifies a software, it is up to them to make it work. > Filing this as a GnuPG bug is thus not a good idea. > > Although, Debian distributes scdaemon as a separate package, scdaemon is > part of GnuPG proper and can't be replaced by other software while > assuming that the whole system works as before. That's correct, but please help us to integrate with gnupg same as openssh guys allow to integrate gpg with their software. All I request after recent changes is that you not fail with EEXIST if private key hexgrip already exists on card after generate, I can try and send patch for this if you agree. This will enable integration to keep working. Thanks, Alon From zmike at samsung.com Mon Feb 13 16:24:08 2017 From: zmike at samsung.com (Mike Blumenkrantz) Date: Mon, 13 Feb 2017 10:24:08 -0500 Subject: [PINENTRY PATCH 1/1] doc: Clarify the documented requirements for commit logs. References: Message-ID: <20170213102408.0c511def@Sir.Pimpleton> Hi, As promised some time ago, the attached patch fixes some typos and makes clearer the requirements for commit log messages in patches submitted to Pinentry. My apologies for the delay, please let me know if I've missed anything. Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-doc-Clarify-the-documented-requirements-for-commit-l.patch Type: text/x-patch Size: 2307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Mon Feb 13 17:15:45 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 13 Feb 2017 17:15:45 +0100 Subject: gpg --card-status always create proxy private keys In-Reply-To: References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> Message-ID: <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> I'm not up to speed on all the fine detail. But perhaps there is a different alternative that would work for you. GnuPG 2.1 has: $ gpg2 --expert --edit-key [KEYID] [...] > addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key Note option 13. You can use this to add an existing key from an OpenPGP smartcard as well. So if you want to add existing keys from a card infrastructure emulating an OpenPGP card, I think it could be integrated in the same way you can, now with 2.1, add existing keys on real OpenPGP cards. This was a workflow that didn't exist in 2.0. 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 gabrielfrancosouza at gmail.com Mon Feb 13 18:46:35 2017 From: gabrielfrancosouza at gmail.com (Gabriel Souza Franco) Date: Mon, 13 Feb 2017 15:46:35 -0200 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: References: <87tw8f3blu.fsf@wheatstone.g10code.de> Message-ID: On Tue, Jan 31, 2017 at 11:28 AM, Gabriel Souza Franco wrote: > On Tue, Jan 31, 2017 at 5:57 AM, Werner Koch wrote: >> On Tue, 31 Jan 2017 04:22, gabrielfrancosouza at gmail.com said: >> >>> With the new backend introduced in 2.1.17 I can no longer resolve >>> keyserver urls, and I've traced it back to a failing SRV lookup. >> >> Have your tried 2.1.18 which should fix the DNS bugs? > > Yes, those fixes haven't solved my problem. Ping. Is just ignoring FORMERR the correct approach? From kristian.fiskerstrand at sumptuouscapital.com Mon Feb 13 18:53:52 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 13 Feb 2017 18:53:52 +0100 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: References: <87tw8f3blu.fsf@wheatstone.g10code.de> Message-ID: On 02/13/2017 06:46 PM, Gabriel Souza Franco wrote: > Ping. Is just ignoring FORMERR the correct approach? The correct approach is likely to fix the network configuration causing FORMERR to begin with? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- 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 Mon Feb 13 19:17:52 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Feb 2017 13:17:52 -0500 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: References: <87tw8f3blu.fsf@wheatstone.g10code.de> Message-ID: <87zihqneen.fsf@alice.fifthhorseman.net> On Mon 2017-02-13 12:46:35 -0500, Gabriel Souza Franco wrote: > On Tue, Jan 31, 2017 at 11:28 AM, Gabriel Souza Franco > wrote: >> On Tue, Jan 31, 2017 at 5:57 AM, Werner Koch wrote: >>> On Tue, 31 Jan 2017 04:22, gabrielfrancosouza at gmail.com said: >>> >>>> With the new backend introduced in 2.1.17 I can no longer resolve >>>> keyserver urls, and I've traced it back to a failing SRV lookup. >>> >>> Have your tried 2.1.18 which should fix the DNS bugs? >> >> Yes, those fixes haven't solved my problem. > > Ping. Is just ignoring FORMERR the correct approach? can you supply a packet capture (.pcap format is fine) of the DNS request and response you're seeing? --dkg From gabrielfrancosouza at gmail.com Mon Feb 13 19:38:46 2017 From: gabrielfrancosouza at gmail.com (Gabriel Souza Franco) Date: Mon, 13 Feb 2017 16:38:46 -0200 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: <87zihqneen.fsf@alice.fifthhorseman.net> References: <87tw8f3blu.fsf@wheatstone.g10code.de> <87zihqneen.fsf@alice.fifthhorseman.net> Message-ID: On Mon, Feb 13, 2017 at 4:17 PM, Daniel Kahn Gillmor wrote: > > can you supply a packet capture (.pcap format is fine) of the DNS > request and response you're seeing? > > --dkg This is the DNS activity after running --refresh-keys. -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg-2.1.18-dns.pcap Type: application/vnd.tcpdump.pcap Size: 1356 bytes Desc: not available URL: From gabrielfrancosouza at gmail.com Mon Feb 13 19:09:57 2017 From: gabrielfrancosouza at gmail.com (Gabriel Souza Franco) Date: Mon, 13 Feb 2017 16:09:57 -0200 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: References: <87tw8f3blu.fsf@wheatstone.g10code.de> Message-ID: On Tue, Jan 31, 2017 at 1:22 AM, Gabriel Souza Franco wrote: > Hello, > > With the new backend introduced in 2.1.17 I can no longer resolve > keyserver urls, and I've traced it back to a failing SRV lookup. > For some unfathomable reason, my ISP provided router responds with > FORMERR instead of NXDOMAIN (but not for .localdomain queries, > interestingly). The failed SRV query then bubbles up, resulting in > Server indicated failure/No keyserver available errors. The old > backend seems to treat any failures as no response instead. On Mon, Feb 13, 2017 at 3:53 PM, Kristian Fiskerstrand wrote: > On 02/13/2017 06:46 PM, Gabriel Souza Franco wrote: >> Ping. Is just ignoring FORMERR the correct approach? > > The correct approach is likely to fix the network configuration causing > FORMERR to begin with? I don't think my ISP will care much (see above). Besides, the old behavior worked with this configuration just fine. From wk at gnupg.org Mon Feb 13 20:46:41 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Feb 2017 20:46:41 +0100 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: (Gabriel Souza Franco's message of "Mon, 13 Feb 2017 16:09:57 -0200") References: <87tw8f3blu.fsf@wheatstone.g10code.de> Message-ID: <87lgt9zxem.fsf@wheatstone.g10code.de> On Mon, 13 Feb 2017 19:09, gabrielfrancosouza at gmail.com said: >> The correct approach is likely to fix the network configuration causing >> FORMERR to begin with? > > I don't think my ISP will care much (see above). Besides, the old > behavior worked with this configuration just fine. The DNS resolver you are using predates SRV records: 19:22:50.674427 IP 192.168.15.20.10218 > 192.168.15.1.domain: 53039+ SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (65) 19:22:50.693552 IP 192.168.15.1.domain > 192.168.15.20.10218: 53039 FormErr 0/0/0 (65) The RFC for SRV records is 17 years old and even not so decent DNS software supports this. If it does not it is very likely that the box has huge numbers of exploitble bugs (think UDP) and an sysadmin should be able to get access to that forgotten DNS server even without a password and fix it. If you have no sysadmin at hand I suggest to take a sledgehammer and tear down the wall behind you assume 192.168.15.1. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gabrielfrancosouza at gmail.com Mon Feb 13 22:29:30 2017 From: gabrielfrancosouza at gmail.com (Gabriel Souza Franco) Date: Mon, 13 Feb 2017 19:29:30 -0200 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: <87lgt9zxem.fsf@wheatstone.g10code.de> References: <87tw8f3blu.fsf@wheatstone.g10code.de> <87lgt9zxem.fsf@wheatstone.g10code.de> Message-ID: On Mon, Feb 13, 2017 at 5:46 PM, Werner Koch wrote: > > The DNS resolver you are using predates SRV records: > > 19:22:50.674427 IP 192.168.15.20.10218 > 192.168.15.1.domain: 53039+ SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (65) > 19:22:50.693552 IP 192.168.15.1.domain > 192.168.15.20.10218: 53039 FormErr 0/0/0 (65) > > The RFC for SRV records is 17 years old and even not so decent DNS > software supports this. If it does not it is very likely that the box > has huge numbers of exploitble bugs (think UDP) and an sysadmin should > be able to get access to that forgotten DNS server even without a > password and fix it. If you have no sysadmin at hand I suggest to take > a sledgehammer and tear down the wall behind you assume 192.168.15.1. > I agree that its security might be laughable, but this is not the point. This unit is a modem/router provided by my ISP and, short of manually configuring resolver settings at each client, it can't be fixed (there is no manual firmware upgrade option). The problem isn't SRV records, but actually any non-existing address. Someone must've used the wrong bitmask or something. Again, the old behavior was to treat a DNS error as 0 results found. Since libdns requests are not malformed, ignoring FORMERR should be safe. $ nslookup thisdomaindoesnotexist.co Server: 192.168.15.1 Address: 192.168.15.1#53 ** server can't find thisdomaindoesnotexist.co: FORMERR $ nslookup -querytype=SRV _xmpp-client._tcp.google.com Server: 192.168.15.1 Address: 192.168.15.1#53 Non-authoritative answer: _xmpp-client._tcp.google.com service = 5 0 5222 xmpp.l.google.com. _xmpp-client._tcp.google.com service = 20 0 5222 alt2.xmpp.l.google.com. _xmpp-client._tcp.google.com service = 20 0 5222 alt1.xmpp.l.google.com. _xmpp-client._tcp.google.com service = 20 0 5222 alt3.xmpp.l.google.com. _xmpp-client._tcp.google.com service = 20 0 5222 alt4.xmpp.l.google.com. > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alon.barlev at gmail.com Mon Feb 13 22:59:08 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 13 Feb 2017 23:59:08 +0200 Subject: gpg --card-status always create proxy private keys In-Reply-To: References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> Message-ID: On 13 February 2017 at 23:49, Alon Bar-Lev wrote: > On 13 February 2017 at 18:15, Peter Lebbing wrote: >> >> I'm not up to speed on all the fine detail. But perhaps there is a >> different alternative that would work for you. GnuPG 2.1 has: >> >> $ gpg2 --expert --edit-key [KEYID] >> [...] >> > addkey >> Please select what kind of key you want: >> (3) DSA (sign only) >> (4) RSA (sign only) >> (5) Elgamal (encrypt only) >> (6) RSA (encrypt only) >> (7) DSA (set your own capabilities) >> (8) RSA (set your own capabilities) >> (10) ECC (sign only) >> (11) ECC (set your own capabilities) >> (12) ECC (encrypt only) >> (13) Existing key >> >> Note option 13. You can use this to add an existing key from an OpenPGP >> smartcard as well. So if you want to add existing keys from a card >> infrastructure emulating an OpenPGP card, I think it could be integrated >> in the same way you can, now with 2.1, add existing keys on real OpenPGP >> cards. This was a workflow that didn't exist in 2.0. > > Hi Peter, > > Similar option was possible in 2.0 using addcardkey. > I checked this as well, and it actually works nicely. > However, it is insufficient... > I am unsure I like the master key to exist outside of the hardware... > This is egg and chicken as the master key cannot be enrolled per the > issue I am experiencing. > Also unfortunately, rpm does not support signing using subkeys. > > Do you know other magics? I searched maybe to take a subkey and > promote it to primary key somehow... did not find sane sequence. > > Maybe instead of "card-edit/generate" there should be "card-edit/use > existing" or something? hmmm... maybe something like: gpg --genkey --keygrip XXXXXX so it will generate a primary key out of specific private key? > > I still think that the simplest solution is to override whatever in > ~/.gnupg/private-keys-v1.d and not fail if same key hash exists, this > requires a small code change of gnupg. > > Regards, > Alon From alon.barlev at gmail.com Mon Feb 13 22:49:54 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 13 Feb 2017 23:49:54 +0200 Subject: gpg --card-status always create proxy private keys In-Reply-To: <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> Message-ID: On 13 February 2017 at 18:15, Peter Lebbing wrote: > > I'm not up to speed on all the fine detail. But perhaps there is a > different alternative that would work for you. GnuPG 2.1 has: > > $ gpg2 --expert --edit-key [KEYID] > [...] > > addkey > Please select what kind of key you want: > (3) DSA (sign only) > (4) RSA (sign only) > (5) Elgamal (encrypt only) > (6) RSA (encrypt only) > (7) DSA (set your own capabilities) > (8) RSA (set your own capabilities) > (10) ECC (sign only) > (11) ECC (set your own capabilities) > (12) ECC (encrypt only) > (13) Existing key > > Note option 13. You can use this to add an existing key from an OpenPGP > smartcard as well. So if you want to add existing keys from a card > infrastructure emulating an OpenPGP card, I think it could be integrated > in the same way you can, now with 2.1, add existing keys on real OpenPGP > cards. This was a workflow that didn't exist in 2.0. Hi Peter, Similar option was possible in 2.0 using addcardkey. I checked this as well, and it actually works nicely. However, it is insufficient... I am unsure I like the master key to exist outside of the hardware... This is egg and chicken as the master key cannot be enrolled per the issue I am experiencing. Also unfortunately, rpm does not support signing using subkeys. Do you know other magics? I searched maybe to take a subkey and promote it to primary key somehow... did not find sane sequence. Maybe instead of "card-edit/generate" there should be "card-edit/use existing" or something? I still think that the simplest solution is to override whatever in ~/.gnupg/private-keys-v1.d and not fail if same key hash exists, this requires a small code change of gnupg. Regards, Alon From dkg at fifthhorseman.net Tue Feb 14 01:02:17 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Feb 2017 19:02:17 -0500 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: References: <87tw8f3blu.fsf@wheatstone.g10code.de> <87zihqneen.fsf@alice.fifthhorseman.net> Message-ID: <87o9y5od12.fsf@alice.fifthhorseman.net> On Mon 2017-02-13 13:38:46 -0500, Gabriel Souza Franco wrote: > On Mon, Feb 13, 2017 at 4:17 PM, Daniel Kahn Gillmor wrote: >> >> can you supply a packet capture (.pcap format is fine) of the DNS >> request and response you're seeing? > > This is the DNS activity after running --refresh-keys. Thanks for the pcap! This shows that there are SRV requests, whose responses contain FORMERR as you reported. But then there are subsequent A and AAAA lookups which return the expected IPv4 and IPv6 addresses. This is what i would expect to happen if dirmngr was to treat the SRV lookup as a failure. Is this your patched dirmngr or the stock dirmngr? --dkg From gabrielfrancosouza at gmail.com Tue Feb 14 01:14:24 2017 From: gabrielfrancosouza at gmail.com (Gabriel Souza Franco) Date: Mon, 13 Feb 2017 22:14:24 -0200 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: <87o9y5od12.fsf@alice.fifthhorseman.net> References: <87tw8f3blu.fsf@wheatstone.g10code.de> <87zihqneen.fsf@alice.fifthhorseman.net> <87o9y5od12.fsf@alice.fifthhorseman.net> Message-ID: On Mon, Feb 13, 2017 at 10:02 PM, Daniel Kahn Gillmor wrote: > > Is this your patched dirmngr or the stock dirmngr? > This is stock. With my patch it continues making several PTR requests, as usual. From dkg at fifthhorseman.net Tue Feb 14 01:19:36 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Feb 2017 19:19:36 -0500 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: References: <87tw8f3blu.fsf@wheatstone.g10code.de> <87zihqneen.fsf@alice.fifthhorseman.net> <87o9y5od12.fsf@alice.fifthhorseman.net> Message-ID: <87inodoc87.fsf@alice.fifthhorseman.net> On Mon 2017-02-13 19:14:24 -0500, Gabriel Souza Franco wrote: > On Mon, Feb 13, 2017 at 10:02 PM, Daniel Kahn Gillmor > wrote: >> >> Is this your patched dirmngr or the stock dirmngr? > > This is stock. With my patch it continues making several PTR requests, as usual. I believe the PTR requests themselves are a bug, so not making them seems just fine to me: https://bugs.gnupg.org/gnupg/issue2928 So it looks to me like the stock behavior is the correct behavior for dirmngr to me, given a broken DNS resolver that cannot handle SRV queries. Can you explain what you would expect to be done differently? --dkg From dkg at fifthhorseman.net Tue Feb 14 01:29:15 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Feb 2017 19:29:15 -0500 Subject: autocrypt at the IFF Message-ID: <878tp9obs4.fsf@alice.fifthhorseman.net> hey folks-- Some of you might have heard about (or are participating in) the Autocrypt project, which aims to see what compromises are necessary to get encrypted mail opportunistically in the hands of more people: https://autocrypt.org/ The Autocrypt people are getting together in Valencia, Spain around the Internet Freedom Festival: https://internetfreedomfestival.org/ We have a slot scheduled for Wednesday evening, March 8th, but we also plan to try to meet up in Valencia before the festival begins, starting with a half-day Saturday afternoon, March 4th, and a full day Sunday March 5th. We'd love to see any GnuPG developers at the IFF generally and in the Autocrypt discussions specifically, since GnuPG is a likely component used by many Autocrypt implementers. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From gabrielfrancosouza at gmail.com Tue Feb 14 02:01:27 2017 From: gabrielfrancosouza at gmail.com (Gabriel Souza Franco) Date: Mon, 13 Feb 2017 23:01:27 -0200 Subject: Can't resolve DNS since 2.1.17 In-Reply-To: <87inodoc87.fsf@alice.fifthhorseman.net> References: <87tw8f3blu.fsf@wheatstone.g10code.de> <87zihqneen.fsf@alice.fifthhorseman.net> <87o9y5od12.fsf@alice.fifthhorseman.net> <87inodoc87.fsf@alice.fifthhorseman.net> Message-ID: On Mon, Feb 13, 2017 at 10:19 PM, Daniel Kahn Gillmor wrote: > > I believe the PTR requests themselves are a bug, so not making them > seems just fine to me: > > https://bugs.gnupg.org/gnupg/issue2928 > > So it looks to me like the stock behavior is the correct behavior for > dirmngr to me, given a broken DNS resolver that cannot handle SRV > queries. > > Can you explain what you would expect to be done differently? > > --dkg Not bailing out on a FORMERR from a SRV query. Note that my problem isn't that my resolver can't handle SRV, but that it gives the wrong answer instead of a NXDOMAIN. This marks the keyserver as dead even with successful A and AAAA replies. $ gpg --refresh-keys gpg: refreshing [?] keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: No keyserver available From justus at g10code.com Tue Feb 14 13:04:48 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 14 Feb 2017 13:04:48 +0100 Subject: [PATCH 1/4] python: Conditionally provide py3 argument to SWIG In-Reply-To: <1482253236.22871.3.camel@cryptobitch.de> References: <20161220164853.GN4181@cryptobitch.de> <1482253236.22871.3.camel@cryptobitch.de> Message-ID: <87r331rna7.fsf@europa.jade-hamburg.de> Hello :) Tobias Mueller writes: > * lang/python/setup.py.in: Only call with -py3 when we run under python3 > or higher. > -- > > If we ever remove the -builtin flag and leave the the -py3 flag, SWIG > will generate Python code which will be incompatible with Python 2, > because the py3 flag generates python3 code which is incompatible with > python2. > > So we conditionally generate SWIG bindings with -py3. Indeed, and with -builtin gone, this actually caused a problem with our build system. I fixed this by using one copy of the sources per Python version, so that SWIG can inject its version-specific wrapper file there. I merged this patch and the rest of the series. Many thanks. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From marvin_schmidt at gmx.net Tue Feb 14 15:00:13 2017 From: marvin_schmidt at gmx.net (marvin_schmidt at gmx.net) Date: Tue, 14 Feb 2017 15:00:13 +0100 Subject: [LIBGPG-ERROR PATCH 0/2] Add armv7-unknown-linux-gnueabihf support Message-ID: <20170214140015.24114-1-marvin_schmidt@gmx.net> From: Marvin Schmidt The attached patches fix the formatting in Makefile.am to use tabs consistently and add support for the armv7-unknown-linux-gnueabihf architecture Marvin Schmidt (2): build: Fix formatting syscfg: Add armv7-unknown-linux-gnueabihf src/Makefile.am | 71 +++++++++++----------- .../lock-obj-pub.armv7-unknown-linux-gnueabihf.h | 23 +++++++ 2 files changed, 59 insertions(+), 35 deletions(-) create mode 100644 src/syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h -- 2.11.1 From marvin_schmidt at gmx.net Tue Feb 14 15:00:15 2017 From: marvin_schmidt at gmx.net (marvin_schmidt at gmx.net) Date: Tue, 14 Feb 2017 15:00:15 +0100 Subject: [PATCH 2/2] syscfg: Add armv7-unknown-linux-gnueabihf In-Reply-To: <20170214140015.24114-1-marvin_schmidt@gmx.net> References: <20170214140015.24114-1-marvin_schmidt@gmx.net> Message-ID: <20170214140015.24114-3-marvin_schmidt@gmx.net> From: Marvin Schmidt --- src/Makefile.am | 1 + .../lock-obj-pub.armv7-unknown-linux-gnueabihf.h | 23 ++++++++++++++++++++++ 2 files changed, 24 insertions(+) create mode 100644 src/syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h diff --git a/src/Makefile.am b/src/Makefile.am index e8c00eb..550a0e6 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -50,6 +50,7 @@ lock_obj_pub = \ syscfg/lock-obj-pub.arm-apple-darwin.h \ syscfg/lock-obj-pub.armv5-unknown-linux-musleabi.h \ syscfg/lock-obj-pub.armv6-unknown-linux-musleabihf.h \ + syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h \ syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h \ syscfg/lock-obj-pub.i386-apple-darwin.h \ syscfg/lock-obj-pub.i686-pc-gnu.h \ diff --git a/src/syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h b/src/syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h new file mode 100644 index 0000000..7a910bb --- /dev/null +++ b/src/syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h @@ -0,0 +1,23 @@ +## lock-obj-pub.armv7-unknown-linux-gnueabihf.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## -- 2.11.1 From marvin_schmidt at gmx.net Tue Feb 14 15:00:14 2017 From: marvin_schmidt at gmx.net (marvin_schmidt at gmx.net) Date: Tue, 14 Feb 2017 15:00:14 +0100 Subject: [PATCH 1/2] build: Fix formatting In-Reply-To: <20170214140015.24114-1-marvin_schmidt@gmx.net> References: <20170214140015.24114-1-marvin_schmidt@gmx.net> Message-ID: <20170214140015.24114-2-marvin_schmidt@gmx.net> From: Marvin Schmidt Use tabs consistently instead of mixing spaces/tabs for indentation. NFC. --- src/Makefile.am | 70 ++++++++++++++++++++++++++++----------------------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 06ba1cd..e8c00eb 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -41,41 +41,41 @@ endif # Distributed lock object definitions for cross compilation. lock_obj_pub = \ - syscfg/lock-obj-pub.aarch64-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.aarch64-apple-darwin.h \ - syscfg/lock-obj-pub.alpha-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.arm-unknown-linux-androideabi.h \ - syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h \ - syscfg/lock-obj-pub.arm-unknown-linux-gnueabihf.h \ - syscfg/lock-obj-pub.arm-apple-darwin.h \ - syscfg/lock-obj-pub.armv5-unknown-linux-musleabi.h \ - syscfg/lock-obj-pub.armv6-unknown-linux-musleabihf.h \ - syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.i386-apple-darwin.h \ - syscfg/lock-obj-pub.i686-pc-gnu.h \ - syscfg/lock-obj-pub.i686-pc-kfreebsd-gnu.h \ - syscfg/lock-obj-pub.i686-pc-linux-gnu.h \ - syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.mips-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h \ - syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.nios2-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.powerpc-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.powerpc64-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.powerpc64le-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.powerpc-unknown-linux-gnuspe.h \ - syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h \ - syscfg/lock-obj-pub.sh3-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.x86_64-apple-darwin.h \ - syscfg/lock-obj-pub.x86_64-pc-kfreebsd-gnu.h \ - syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h \ - syscfg/lock-obj-pub.x86_64-pc-linux-gnux32.h \ - syscfg/lock-obj-pub.x86_64-pc-linux-musl.h \ - syscfg/lock-obj-pub.tilegx-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.aarch64-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.aarch64-apple-darwin.h \ + syscfg/lock-obj-pub.alpha-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.arm-unknown-linux-androideabi.h \ + syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h \ + syscfg/lock-obj-pub.arm-unknown-linux-gnueabihf.h \ + syscfg/lock-obj-pub.arm-apple-darwin.h \ + syscfg/lock-obj-pub.armv5-unknown-linux-musleabi.h \ + syscfg/lock-obj-pub.armv6-unknown-linux-musleabihf.h \ + syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.i386-apple-darwin.h \ + syscfg/lock-obj-pub.i686-pc-gnu.h \ + syscfg/lock-obj-pub.i686-pc-kfreebsd-gnu.h \ + syscfg/lock-obj-pub.i686-pc-linux-gnu.h \ + syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.mips-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h \ + syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.nios2-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.powerpc-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.powerpc64-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.powerpc64le-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.powerpc-unknown-linux-gnuspe.h \ + syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h \ + syscfg/lock-obj-pub.sh3-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.x86_64-apple-darwin.h \ + syscfg/lock-obj-pub.x86_64-pc-kfreebsd-gnu.h \ + syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h \ + syscfg/lock-obj-pub.x86_64-pc-linux-gnux32.h \ + syscfg/lock-obj-pub.x86_64-pc-linux-musl.h \ + syscfg/lock-obj-pub.tilegx-unknown-linux-gnu.h \ syscfg/lock-obj-pub.mingw32.h -- 2.11.1 From marvin_schmidt at gmx.net Tue Feb 14 16:24:38 2017 From: marvin_schmidt at gmx.net (marvin_schmidt at gmx.net) Date: Tue, 14 Feb 2017 16:24:38 +0100 Subject: [PATCH 2/2] syscfg: Add armv7-unknown-linux-gnueabihf In-Reply-To: <20170214152438.10646-1-marvin_schmidt@gmx.net> References: <20170214152438.10646-1-marvin_schmidt@gmx.net> Message-ID: <20170214152438.10646-3-marvin_schmidt@gmx.net> From: Marvin Schmidt --- src/Makefile.am | 1 + .../lock-obj-pub.armv7-unknown-linux-gnueabihf.h | 23 ++++++++++++++++++++++ 2 files changed, 24 insertions(+) create mode 100644 src/syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h diff --git a/src/Makefile.am b/src/Makefile.am index e8c00eb..550a0e6 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -50,6 +50,7 @@ lock_obj_pub = \ syscfg/lock-obj-pub.arm-apple-darwin.h \ syscfg/lock-obj-pub.armv5-unknown-linux-musleabi.h \ syscfg/lock-obj-pub.armv6-unknown-linux-musleabihf.h \ + syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h \ syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h \ syscfg/lock-obj-pub.i386-apple-darwin.h \ syscfg/lock-obj-pub.i686-pc-gnu.h \ diff --git a/src/syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h b/src/syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h new file mode 100644 index 0000000..7a910bb --- /dev/null +++ b/src/syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h @@ -0,0 +1,23 @@ +## lock-obj-pub.armv7-unknown-linux-gnueabihf.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## -- 2.11.1 From marvin_schmidt at gmx.net Tue Feb 14 16:24:37 2017 From: marvin_schmidt at gmx.net (marvin_schmidt at gmx.net) Date: Tue, 14 Feb 2017 16:24:37 +0100 Subject: [PATCH 1/2] build: Fix formatting In-Reply-To: <20170214152438.10646-1-marvin_schmidt@gmx.net> References: <20170214152438.10646-1-marvin_schmidt@gmx.net> Message-ID: <20170214152438.10646-2-marvin_schmidt@gmx.net> From: Marvin Schmidt Use tabs consistently instead of mixing spaces/tabs for indentation. NFC. --- src/Makefile.am | 70 ++++++++++++++++++++++++++++----------------------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 06ba1cd..e8c00eb 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -41,41 +41,41 @@ endif # Distributed lock object definitions for cross compilation. lock_obj_pub = \ - syscfg/lock-obj-pub.aarch64-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.aarch64-apple-darwin.h \ - syscfg/lock-obj-pub.alpha-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.arm-unknown-linux-androideabi.h \ - syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h \ - syscfg/lock-obj-pub.arm-unknown-linux-gnueabihf.h \ - syscfg/lock-obj-pub.arm-apple-darwin.h \ - syscfg/lock-obj-pub.armv5-unknown-linux-musleabi.h \ - syscfg/lock-obj-pub.armv6-unknown-linux-musleabihf.h \ - syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.i386-apple-darwin.h \ - syscfg/lock-obj-pub.i686-pc-gnu.h \ - syscfg/lock-obj-pub.i686-pc-kfreebsd-gnu.h \ - syscfg/lock-obj-pub.i686-pc-linux-gnu.h \ - syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.mips-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h \ - syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.nios2-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.powerpc-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.powerpc64-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.powerpc64le-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.powerpc-unknown-linux-gnuspe.h \ - syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h \ - syscfg/lock-obj-pub.sh3-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h \ - syscfg/lock-obj-pub.x86_64-apple-darwin.h \ - syscfg/lock-obj-pub.x86_64-pc-kfreebsd-gnu.h \ - syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h \ - syscfg/lock-obj-pub.x86_64-pc-linux-gnux32.h \ - syscfg/lock-obj-pub.x86_64-pc-linux-musl.h \ - syscfg/lock-obj-pub.tilegx-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.aarch64-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.aarch64-apple-darwin.h \ + syscfg/lock-obj-pub.alpha-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.arm-unknown-linux-androideabi.h \ + syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h \ + syscfg/lock-obj-pub.arm-unknown-linux-gnueabihf.h \ + syscfg/lock-obj-pub.arm-apple-darwin.h \ + syscfg/lock-obj-pub.armv5-unknown-linux-musleabi.h \ + syscfg/lock-obj-pub.armv6-unknown-linux-musleabihf.h \ + syscfg/lock-obj-pub.hppa-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.i386-apple-darwin.h \ + syscfg/lock-obj-pub.i686-pc-gnu.h \ + syscfg/lock-obj-pub.i686-pc-kfreebsd-gnu.h \ + syscfg/lock-obj-pub.i686-pc-linux-gnu.h \ + syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.mips-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h \ + syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.nios2-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.powerpc-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.powerpc64-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.powerpc64le-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.powerpc-unknown-linux-gnuspe.h \ + syscfg/lock-obj-pub.s390x-ibm-linux-gnu.h \ + syscfg/lock-obj-pub.sh3-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.sh4-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.sparc-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.sparc64-unknown-linux-gnu.h \ + syscfg/lock-obj-pub.x86_64-apple-darwin.h \ + syscfg/lock-obj-pub.x86_64-pc-kfreebsd-gnu.h \ + syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h \ + syscfg/lock-obj-pub.x86_64-pc-linux-gnux32.h \ + syscfg/lock-obj-pub.x86_64-pc-linux-musl.h \ + syscfg/lock-obj-pub.tilegx-unknown-linux-gnu.h \ syscfg/lock-obj-pub.mingw32.h -- 2.11.1 From marvin_schmidt at gmx.net Tue Feb 14 16:24:36 2017 From: marvin_schmidt at gmx.net (marvin_schmidt at gmx.net) Date: Tue, 14 Feb 2017 16:24:36 +0100 Subject: [LIBGPG-ERROR PATCH 0/2] Add armv7-unknown-linux-gnueabihf support Message-ID: <20170214152438.10646-1-marvin_schmidt@gmx.net> From: Marvin Schmidt The attached patches fix the formatting in Makefile.am to use tabs consistently and add support for the armv7-unknown-linux-gnueabihf architecture Marvin Schmidt (2): build: Fix formatting syscfg: Add armv7-unknown-linux-gnueabihf src/Makefile.am | 71 +++++++++++----------- .../lock-obj-pub.armv7-unknown-linux-gnueabihf.h | 23 +++++++ 2 files changed, 59 insertions(+), 35 deletions(-) create mode 100644 src/syscfg/lock-obj-pub.armv7-unknown-linux-gnueabihf.h -- 2.11.1 From peter at digitalbrains.com Tue Feb 14 20:11:03 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 14 Feb 2017 20:11:03 +0100 Subject: gpg --card-status always create proxy private keys In-Reply-To: References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> Message-ID: <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> Hello Alon, On 13/02/17 22:49, Alon Bar-Lev wrote: > Similar option was possible in 2.0 using addcardkey. If you can wrest this behaviour from "addcardkey" you're a better man than I :-). If I use addcardkey from 2.0, it does not give me the option to use an existing smartcard key, it will instead warn me that it will overwrite the existing key. Are you sure you can use an existing key that way? > Also unfortunately, rpm does not support signing using subkeys. My first thought is: then rpm should be updated, OpenPGP subkeys are a well-established technology. But I suppose you need a developer that cares enough first, it's cheap to yell "then it should be updated!". But since you can actually create a primary key that can do both certify and sign, it's not a showstopper for using smartcards. You can, right? I'm not 100% sure I ever tested using a primary key on smartcard with *both* certify and sign, but I wouldn't expect it not to work since you actually use the "Sign" slot on a smartcard to use a Certify-capable key. > Maybe instead of "card-edit/generate" there should be "card-edit/use > existing" or something? Isn't that exactly the same as GnuPG 2.1's "edit-key/addkey/Use existing"? What would be the difference? Well, okay for the latter you need to look up the keygrip, but the functionality is there. On 13/02/17 22:59, Alon Bar-Lev wrote: > hmmm... maybe something like: > gpg --genkey --keygrip XXXXXX > so it will generate a primary key out of specific private key? I'd actually expect it differently. Right now, in contrast with "edit-key/addkey", GnuPG 2.1 offers the following: > $ gpg2 --expert --full-gen-key > gpg (GnuPG) 2.1.16; Copyright (C) 2016 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. > > Please select what kind of key you want: > (1) RSA and RSA (default) > (2) DSA and Elgamal > (3) DSA (sign only) > (4) RSA (sign only) > (7) DSA (set your own capabilities) > (8) RSA (set your own capabilities) > (9) ECC and ECC > (10) ECC (sign only) > (11) ECC (set your own capabilities) > Your selection? I'd just like to see option 13 from "edit-key/addkey", so it would be like this (this is a mock-up, not actual output!): > $ gpg2 --expert --full-gen-key > gpg (GnuPG) 2.1.16; Copyright (C) 2016 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. > > Please select what kind of key you want: > (1) RSA and RSA (default) > (2) DSA and Elgamal > (3) DSA (sign only) > (4) RSA (sign only) > (7) DSA (set your own capabilities) > (8) RSA (set your own capabilities) > (9) ECC and ECC > (10) ECC (sign only) > (11) ECC (set your own capabilities) > (13) Existing key > Your selection? 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 alon.barlev at gmail.com Tue Feb 14 20:31:13 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 14 Feb 2017 21:31:13 +0200 Subject: gpg --card-status always create proxy private keys In-Reply-To: <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> Message-ID: On 14 February 2017 at 21:11, Peter Lebbing wrote: > Hello Alon, > > On 13/02/17 22:49, Alon Bar-Lev wrote: >> Similar option was possible in 2.0 using addcardkey. > > If you can wrest this behaviour from "addcardkey" you're a better man than I > :-). If I use addcardkey from 2.0, it does not give me the option to use an > existing smartcard key, it will instead warn me that it will overwrite the > existing key. Are you sure you can use an existing key that way? > >> Also unfortunately, rpm does not support signing using subkeys. > > My first thought is: then rpm should be updated, OpenPGP subkeys are a > well-established technology. But I suppose you need a developer that cares > enough first, it's cheap to yell "then it should be updated!". Yes... but I cannot control that... it is pending ~10 years[1] I need to support, among other, signing rpms using PKCS#11 enabled HSM. [1] https://www.redhat.com/archives/rpm-list/2006-November/msg00105.html > But since you can actually create a primary key that can do both certify and > sign, it's not a showstopper for using smartcards. This option is now lost when re-using keys as I described in my initial mail. > You can, right? I'm not 100% sure I ever tested using a primary key on smartcard > with *both* certify and sign, but I wouldn't expect it not to work since you > actually use the "Sign" slot on a smartcard to use a Certify-capable key. This worked so far, as "card-edit/generate" returned existing key, so using PKCS#11 keys could have been used as primary keys, however, now that gpg does not enable generate to return the same key, it broke the ability to use primary keys. I believe that the block of using existing key when generate is an unattended behavior and can be fixed easily. >> Maybe instead of "card-edit/generate" there should be "card-edit/use >> existing" or something? > > Isn't that exactly the same as GnuPG 2.1's "edit-key/addkey/Use existing"? What > would be the difference? Well, okay for the latter you need to look up the > keygrip, but the functionality is there. The difference is that edit-key uses existing primary key and manage subkeys, while I need to support primary keys as well. > > On 13/02/17 22:59, Alon Bar-Lev wrote: >> hmmm... maybe something like: >> gpg --genkey --keygrip XXXXXX >> so it will generate a primary key out of specific private key? > > I'd actually expect it differently. Right now, in contrast with > "edit-key/addkey", GnuPG 2.1 offers the following: > >> $ gpg2 --expert --full-gen-key >> gpg (GnuPG) 2.1.16; Copyright (C) 2016 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. >> >> Please select what kind of key you want: >> (1) RSA and RSA (default) >> (2) DSA and Elgamal >> (3) DSA (sign only) >> (4) RSA (sign only) >> (7) DSA (set your own capabilities) >> (8) RSA (set your own capabilities) >> (9) ECC and ECC >> (10) ECC (sign only) >> (11) ECC (set your own capabilities) >> Your selection? > > I'd just like to see option 13 from "edit-key/addkey", so it would be like this > (this is a mock-up, not actual output!): >> $ gpg2 --expert --full-gen-key >> gpg (GnuPG) 2.1.16; Copyright (C) 2016 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. >> >> Please select what kind of key you want: >> (1) RSA and RSA (default) >> (2) DSA and Elgamal >> (3) DSA (sign only) >> (4) RSA (sign only) >> (7) DSA (set your own capabilities) >> (8) RSA (set your own capabilities) >> (9) ECC and ECC >> (10) ECC (sign only) >> (11) ECC (set your own capabilities) >> (13) Existing key >> Your selection? Yes, this should generate a primary key using existing private key. If this is acceptable it will be very nice. Thanks! > 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 > From kristian.fiskerstrand at sumptuouscapital.com Tue Feb 14 20:53:30 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 14 Feb 2017 20:53:30 +0100 Subject: gpg --card-status always create proxy private keys In-Reply-To: References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> Message-ID: <04611433-c052-8a8a-d271-49b63377ce62@sumptuouscapital.com> On 02/13/2017 10:49 PM, Alon Bar-Lev wrote: > Maybe instead of "card-edit/generate" there should be "card-edit/use > existing" or something? This discussion might relate to [issue1734] , the smartcard already store sufficient information to generate it already (timestamp of generation for proper fingerprint in calculation) , not sure if you find anything useful in References: [issue1734] https://bugs.gnupg.org/gnupg/issue1734 [1] http://lists.gnupg.org/pipermail/gnupg-users/2010-September/039488.html [2] http://lists.gnupg.org/pipermail/gnupg-users/2014-October/051051.html -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Feb 14 20:39:27 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 14 Feb 2017 20:39:27 +0100 Subject: gpg --card-status always create proxy private keys In-Reply-To: References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> Message-ID: <173383b0-01c2-b87b-5f68-df363f85e7b2@digitalbrains.com> On 14/02/17 20:31, Alon Bar-Lev wrote: > This worked so far, as "card-edit/generate" returned existing key I think that was not a GnuPG design decision but rather somewhat of a "hack" to enable this use case? I don't think you can obtain this behaviour with a real OpenPGP card, it's just something the emulation layer decided to do, right? > The difference is that edit-key uses existing primary key and manage > subkeys, while I need to support primary keys as well. Right, yes, of course, silly of me. > Yes, this should generate a primary key using existing private key. > If this is acceptable it will be very nice. And it would support this behaviour for real OpenPGP cards as well, not just for the emulation layer interfacing to PKCS#11 cards. Plus, it makes the behaviour obvious. It would not be obvious to me that "generate" actually didn't... well... generate keys ;-). Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From alon.barlev at gmail.com Tue Feb 14 20:57:35 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 14 Feb 2017 21:57:35 +0200 Subject: gpg --card-status always create proxy private keys In-Reply-To: <04611433-c052-8a8a-d271-49b63377ce62@sumptuouscapital.com> References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <04611433-c052-8a8a-d271-49b63377ce62@sumptuouscapital.com> Message-ID: On 14 February 2017 at 21:53, Kristian Fiskerstrand wrote: > On 02/13/2017 10:49 PM, Alon Bar-Lev wrote: >> Maybe instead of "card-edit/generate" there should be "card-edit/use >> existing" or something? > > This discussion might relate to [issue1734] , the smartcard already > store sufficient information to generate it already (timestamp of > generation for proper fingerprint in calculation) , not sure if you find > anything useful in Actually, now every time you insert your card the shadow is created. However, there is no way to reuse this key (even if has no public key) to any use. I am unsure I understood this [issue1734], you are right that these are similar, both would like to reuse existing key but maybe to different purposes. > > References: > [issue1734] https://bugs.gnupg.org/gnupg/issue1734 > [1] http://lists.gnupg.org/pipermail/gnupg-users/2010-September/039488.html > [2] http://lists.gnupg.org/pipermail/gnupg-users/2014-October/051051.html > > -- > ---------------------------- > Kristian Fiskerstrand > Blog: https://blog.sumptuouscapital.com > Twitter: @krifisk > ---------------------------- > Public OpenPGP keyblock at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 > ---------------------------- > Qui audet vincit > Who dares wins > From alon.barlev at gmail.com Tue Feb 14 21:49:51 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 14 Feb 2017 22:49:51 +0200 Subject: gpg --card-status always create proxy private keys In-Reply-To: <173383b0-01c2-b87b-5f68-df363f85e7b2@digitalbrains.com> References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> <173383b0-01c2-b87b-5f68-df363f85e7b2@digitalbrains.com> Message-ID: On 14 February 2017 at 21:39, Peter Lebbing wrote: > On 14/02/17 20:31, Alon Bar-Lev wrote: >> This worked so far, as "card-edit/generate" returned existing key > > I think that was not a GnuPG design decision but rather somewhat of a "hack" to > enable this use case? I don't think you can obtain this behaviour with a real > OpenPGP card, it's just something the emulation layer decided to do, right? Correct. Functionality of gnupg is required also for other types of cards, however, there is no real way to integrate with gnupg as the interfaces are not stable, the last 10 years I modified solution over and over in order to provide a service to users that requires integration with other devices, here I found a dead end. Of course I can simulate empty token and return a key only after generate... before I do that I thought that maybe the existing behavior of caring what generate returns while there is nothing in keychain that relates to the key is intentional, I still believe that this is not. >> The difference is that edit-key uses existing primary key and manage >> subkeys, while I need to support primary keys as well. > > Right, yes, of course, silly of me. > >> Yes, this should generate a primary key using existing private key. >> If this is acceptable it will be very nice. > > And it would support this behaviour for real OpenPGP cards as well, not just for > the emulation layer interfacing to PKCS#11 cards. Plus, it makes the behaviour > obvious. It would not be obvious to me that "generate" actually didn't... > well... generate keys ;-). Great, how can we push that? > > Cheers, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at > From peter at digitalbrains.com Wed Feb 15 11:55:34 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 15 Feb 2017 11:55:34 +0100 Subject: Feature request: use existing key in --full-gen-key (was: gpg --card-status always create proxy private keys) In-Reply-To: References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> <173383b0-01c2-b87b-5f68-df363f85e7b2@digitalbrains.com> Message-ID: Hello developers, GnuPG 2.1 has the option to use an existing key when adding a subkey: > $ gpg2 --expert --edit-key [KEYID] > [...] >> addkey > Please select what kind of key you want: > [...] > (13) Existing key > Your selection? However, this is not an option when generating a new primary key. Could we have this option for new primary keys as well? Option (13) could be made available when doing: > $ gpg2 --expert --full-gen-key > [...] > Please select what kind of key you want: > (1) RSA and RSA (default) > [...] > (11) ECC (set your own capabilities) > Your selection? As you can see in the parent thread, this is an actively desired feature for using non-OpenPGP crypto hardware with an OpenPGP emulation layer. A PKCS#11 Hardware Security Module for signing rpm's was mentioned. The feature has been implemented already by having this emulation layer use an existing key when "card-edit/generate" is invoked, rather than actually creating new keys. However, this broke because of changes in 2.1. It is my feeling that since we now have "Use existing key" as an explicit option for "edit-key/addkey", it makes sense to use this same mechanism for primary keys as well. In this way, the problem Alon Bar-Lev has is solved as well, and the functionality is more generic and consistent. People can use existing on-disk keys, existing smartcard keys on a real OpenPGP smartcard and existing smartcard keys on an emulated OpenPGP smartcard, all in the same manner. On 14/02/17 21:49, Alon Bar-Lev wrote: > Great, how can we push that? How about this feature request? :-) Does it work for you? 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 patrick at enigmail.net Wed Feb 15 16:48:45 2017 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 15 Feb 2017 16:48:45 +0100 Subject: Questions about gpg-wks-client usage Message-ID: <9cddb035-9afd-2b1c-d5da-705af6d71cce@enigmail.net> I got a patch from Kai which integrates gpg-wks-client into Enigmail (thanks for this!). Now reviewing, and trying to understand the code, I noticed that the tool is invoked the following way: /path/to/gpg-wks-client --supported and then then the exit status of gpg-wks-client is checked (0 = OK, other = did not work). Is this the correct way to determine if gpg-wks-client was successful? Or is this the better (safer) way: /path/to/gpg-wks-client --status-fd 2 --supported and then the status output should be checked just like regular gpg-output? Thanks, Patrick From aheinecke at intevation.de Wed Feb 15 17:18:16 2017 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 15 Feb 2017 17:18:16 +0100 Subject: Questions about gpg-wks-client usage In-Reply-To: <9cddb035-9afd-2b1c-d5da-705af6d71cce@enigmail.net> References: <9cddb035-9afd-2b1c-d5da-705af6d71cce@enigmail.net> Message-ID: <1942486.CI7ggX11JM@esus> Hi, On Wednesday 15 February 2017 16:48:45 Patrick Brunschwig wrote: > I got a patch from Kai which integrates gpg-wks-client into Enigmail > (thanks for this!). Now reviewing, and trying to understand the code, I > noticed that the tool is invoked the following way: > > /path/to/gpg-wks-client --supported > > and then then the exit status of gpg-wks-client is checked (0 = OK, > other = did not work). > > Is this the correct way to determine if gpg-wks-client was successful? Yes this is the correct way. It is the way QGpgME / KMail also check if wks is supported. > Or is this the better (safer) way: > > /path/to/gpg-wks-client --status-fd 2 --supported > > and then the status output should be checked just like regular gpg-output? This was added on my request thanks to a technical detail in GPGME that created problems for me in GpgOL. In GPGME we have gpgme_op_spawn for a platform independent spawn of a process. Nice API and easier to use then CreateProcess / fork etc. But gpgme_op_spawn does not communicate the return code of the spawned process. We added the status-fd as a workaround so that a plain GPGME application can use gpgme_op_spawn to interact with the wks tools. So its more of an optional workaround to check if wks is supported even if you don't have access to the return code of the process. Thanks for reviewing this and best regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From Katarina.Behrens at cib.de Wed Feb 15 21:08:26 2017 From: Katarina.Behrens at cib.de (Katarina Behrens) Date: Wed, 15 Feb 2017 21:08:26 +0100 Subject: [PATCH]Build with gpg-error in non-standard prefix Message-ID: <3981274.xy9ZBSpSpL@localhost.localdomain> Hello world, this is my first time on this list and I'm totally clueless as for what the social conventions and procedures for submitting patches here are, so please bear with me. On fairly run-of-the-mill Linux system, I have libgpg-error in non-standard prefix (let's say /opt), so that: 'gpg-error-config --cflags' => '-I/opt/include' 'gpg-error-config --libs' => -L/opt/lib -lgpg-error So I do (in the folder with gpgme sources): ./configure --with-libgpg-error-prefix=/opt So far, everything is peachy. But that's where it ends and with this setup (and with libassuan in a different prefix), I can't build gpgme. Compilation fails because it can't find gpg-error headers (src/Makefile.am AM_CFLAGS contains only LIBASSUAN_CFLAGS). Linking of gpgme-tool fails as well, as gpgme_tool_LDADD misses reference to GPG_ERROR_LIBS Attached patch fixes the issue. I'm not sure if actually having gpg-error in a different prefix (that is not the same as libassuan prefix) is a supported scenario and maybe what I'm doing is rather silly. In that case, feel free to ignore the patch. -- Katarina Behrens Softwareentwicklerin LibreOffice ??? CIB software GmbH Gesch?ftsstelle Hamburg Flachsland 10 22083 Hamburg ??? T +49 (40) / 28 48 42 -235 F +49 (40) / 28 48 42 -100 Katarina.Behrens at cib.de www.cib.de ??? Sitz: M?nchen Registergericht M?nchen, HRB 123286 Gesch?ftsf?hrer: Dipl.-Ing. Ulrich Brandner -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Build-with-libgpg-error-headers-and-libs-in-non-stan.patch Type: text/x-patch Size: 950 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 16 09:28:27 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Feb 2017 09:28:27 +0100 Subject: [PATCH]Build with gpg-error in non-standard prefix In-Reply-To: <3981274.xy9ZBSpSpL@localhost.localdomain> (Katarina Behrens's message of "Wed, 15 Feb 2017 21:08:26 +0100") References: <3981274.xy9ZBSpSpL@localhost.localdomain> Message-ID: <87efyytu8k.fsf@wheatstone.g10code.de> Hi! On Wed, 15 Feb 2017 21:08, Katarina.Behrens at cib.de said: > On fairly run-of-the-mill Linux system, I have libgpg-error in non-standard > prefix (let's say /opt), so that: But it seems that libassuan has been build with a different libgpg-error. > Compilation fails because it can't find gpg-error headers (src/Makefile.am > AM_CFLAGS contains only LIBASSUAN_CFLAGS). Linking of gpgme-tool fails as Libassuan requires libgpg-error and thus LIBASSUAN_CFLAGS already includes the CFLAGS required for libgpg-error. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From patrick at enigmail.net Thu Feb 16 17:19:07 2017 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 16 Feb 2017 17:19:07 +0100 Subject: WKS - Inconsistency in RFC-Draft Message-ID: <00533f6f-bee8-0f06-2d6b-5dbb6ae89fbf@enigmail.net> Hi Werner in the WKS draft [1], you specify in section 4.3 that the confirmation request must have the content-type "application/vnd.gnupg.wkd". In the examples at the end, you use the content-type "application/vnd.gnupg.wks" (note the difference in the last letter). The test server set up by Intevation sends "application/vnd.gnupg.wks". Which of the two is now correct? Thanks, Patrick [1] https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-03.txt From wk at gnupg.org Thu Feb 16 17:41:44 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Feb 2017 17:41:44 +0100 Subject: WKS - Inconsistency in RFC-Draft In-Reply-To: <00533f6f-bee8-0f06-2d6b-5dbb6ae89fbf@enigmail.net> (Patrick Brunschwig's message of "Thu, 16 Feb 2017 17:19:07 +0100") References: <00533f6f-bee8-0f06-2d6b-5dbb6ae89fbf@enigmail.net> Message-ID: <87y3x6rstz.fsf@wheatstone.g10code.de> On Thu, 16 Feb 2017 17:19, patrick at enigmail.net said: > Hi Werner > > in the WKS draft [1], you specify in section 4.3 that the confirmation > request must have the content-type "application/vnd.gnupg.wkd". In the > examples at the end, you use the content-type > "application/vnd.gnupg.wks" (note the difference in the last letter). wk*s* is correct. I'll fix it for the next version. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gniibe at fsij.org Fri Feb 17 01:03:08 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 17 Feb 2017 09:03:08 +0900 Subject: Feature request: use existing key in --full-gen-key (was: gpg --card-status always create proxy private keys) In-Reply-To: References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> <173383b0-01c2-b87b-5f68-df363f85e7b2@digitalbrains.com> Message-ID: <87efyxiszn.fsf@iwagami.gniibe.org> Peter Lebbing wrote: > As you can see in the parent thread, this is an actively desired feature > for using non-OpenPGP crypto hardware with an OpenPGP emulation layer. A > PKCS#11 Hardware Security Module for signing rpm's was mentioned. The > feature has been implemented already by having this emulation layer use > an existing key when "card-edit/generate" is invoked, rather than > actually creating new keys. However, this broke because of changes in > 2.1. It is my feeling that since we now have "Use existing key" as an > explicit option for "edit-key/addkey", it makes sense to use this same > mechanism for primary keys as well. In this way, the problem Alon > Bar-Lev has is solved as well, and the functionality is more generic and > consistent. People can use existing on-disk keys, existing smartcard > keys on a real OpenPGP smartcard and existing smartcard keys on an > emulated OpenPGP smartcard, all in the same manner. Sounds good and consistent to me. Thanks for your proposal. I'll consider implementation feasibility. -- From ineiev at gnu.org Fri Feb 17 09:52:47 2017 From: ineiev at gnu.org (Ineiev) Date: Fri, 17 Feb 2017 03:52:47 -0500 Subject: [STABLE-BRANCH-1-4 PATCH] g10: secmem leak In-Reply-To: <87r3e85bnp.fsf@wheatstone.g10code.de> References: <20160414161817.GA9527@gnu.org> <87r3e85bnp.fsf@wheatstone.g10code.de> Message-ID: <20170217085247.GM18144@gnu.org> On Thu, Apr 14, 2016 at 07:43:22PM +0200, Werner Koch wrote: > On Thu, 14 Apr 2016 18:18, ineiev at gnu.org said: > > > I attach a patch for GnuPG-bug 1371. in short, secure memory > > is leaked because proc_parameter_file() adds new entries > > to the head of the list of parameters, and these entries > > aren't accessible to the caller that releases the list. > > Thanks for the patch - I will look at it later. It still applies. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From bre at pagekite.net Fri Feb 17 14:39:01 2017 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Fri, 17 Feb 2017 13:39:01 -0000 Subject: Key generation: is it possible to fail fast? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello gnupg-devel! I am pondering the problem of key generation vs. system entropy. In short, it's a pretty bad user experience if key generation takes a very long time (potentially forever). This sort of thing happens especially in virtual machine environments. If the system doesn't have enough entropy, and generates entropy too slowly to create a key within a "reasonable time frame", would it be possible to detect that and fail early? Is it possible to estimate how long key generation will take? Of course, anything that can be done to speed up key generation would be ideal, but I do understand that the GnuPG project would very much like to avoid generating weak keys. Thanks, - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYpvz3AAoJEI4ANxYAz5SRizgH/2axueHMsPdTlMHi5U+H2X9X 4z1AXUYX+M0kBrIXD4QlTUiQYwblujY2hf+zIIiPD4KYFXWes1pYzeWfZ1fuMQs2 jd71+wSjrKUTQUX+cnBSEcpnmlz4grr0yTD+Kz6HNO+sHZ0Evl6qivJwTnj3J/Qb AiIX0fNFrRnWjaiFheq+jk/TPZ8ATmUQK5FjzlqiQmtJQXEnzSb3J8sgJSWbt5Ck 0vsQRdI/v6UBM24o2ybqEfET658jvczLozeO3z2yDqp2kjPKQPuMhGvWBuBmfRBW WTuBAQP87gZgupq3s0aqpgFUnLQ4jydtPtoPalHih3+7J4l0CKsolAmFTLvRReY= =DIbL -----END PGP SIGNATURE----- From justus at g10code.com Fri Feb 17 15:59:12 2017 From: justus at g10code.com (Justus Winter) Date: Fri, 17 Feb 2017 15:59:12 +0100 Subject: Key generation: is it possible to fail fast? In-Reply-To: References: Message-ID: <87wpcoeudb.fsf@europa.jade-hamburg.de> Bjarni Runar Einarsson writes: > I am pondering the problem of key generation vs. system entropy. > In short, it's a pretty bad user experience if key generation > takes a very long time (potentially forever). This sort of thing > happens especially in virtual machine environments. > > If the system doesn't have enough entropy, and generates entropy > too slowly to create a key within a "reasonable time frame", > would it be possible to detect that and fail early? Is it > possible to estimate how long key generation will take? > > Of course, anything that can be done to speed up key generation > would be ideal, but I do understand that the GnuPG project would > very much like to avoid generating weak keys. At our last hackathon we briefly pondered an idea to make key generation appear fast without compromising on key strength: When the frontend starts a new key generation wizard, start collecting entropy in the backend, and use this to speed up the generation once the user completed the wizard. With such a design, the frontend could even ask the backend on the progress, and detect entropy-starved environments before attempting the key generation. Sadly the idea was not popular. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From muelli at cryptobitch.de Fri Feb 17 16:17:13 2017 From: muelli at cryptobitch.de (Tobias Mueller) Date: Fri, 17 Feb 2017 16:17:13 +0100 Subject: Key generation: is it possible to fail fast? In-Reply-To: References: Message-ID: <20170217151713.GE22717@cryptobitch.de> Hi. On Fri, Feb 17, 2017 at 01:39:01PM -0000, Bjarni Runar Einarsson wrote: > If the system doesn't have enough entropy, and generates entropy > too slowly to create a key within a "reasonable time frame", > would it be possible to detect that and fail early? Hm. I guess you could run a timer and abort the key generation (e.g. kill the process) if it's taking you too long. > Of course, anything that can be done to speed up key generation > would be ideal ECC keys are super fast to generate. I've seen people installing havegd in virtual machine environments to emulate entropy. Cheers, Tobi From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 17 16:27:39 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 17 Feb 2017 16:27:39 +0100 Subject: Key generation: is it possible to fail fast? In-Reply-To: <20170217151713.GE22717@cryptobitch.de> References: <20170217151713.GE22717@cryptobitch.de> Message-ID: On February 17, 2017 4:17:13 PM GMT+01:00, Tobias Mueller wrote: >Hi. > >On Fri, Feb 17, 2017 at 01:39:01PM -0000, Bjarni Runar Einarsson wrote: >> If the system doesn't have enough entropy, and generates entropy >> too slowly to create a key within a "reasonable time frame", >> would it be possible to detect that and fail early? >Hm. I guess you could run a timer and abort the key generation (e.g. >kill the >process) if it's taking you too long. > >> Of course, anything that can be done to speed up key generation >> would be ideal >ECC keys are super fast to generate. > >I've seen people installing havegd in virtual machine environments >to emulate entropy. I prefer adding a TRNG (like NeuG (reads noisy)) by gniibe on the hypervisor and accessing that from within the VMs (libvirt+qemu+kvm) , works like a charm > >Cheers, > Tobi > >_______________________________________________ >Gnupg-devel mailing list >Gnupg-devel at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-devel -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 From bre at pagekite.net Fri Feb 17 16:15:28 2017 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Fri, 17 Feb 2017 15:15:28 -0000 Subject: Key generation: is it possible to fail fast? In-Reply-To: <87wpcoeudb.fsf@europa.jade-hamburg.de> References: <87wpcoeudb.fsf@europa.jade-hamburg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Justus, Justus Winter wrote: > At our last hackathon we briefly pondered an idea to make key > generation appear fast without compromising on key strength: > When the frontend starts a new key generation wizard, start > collecting entropy in the backend, and use this to speed up the > generation once the user completed the wizard. Interesting idea. This might improve the experience of manual users, but for tools which use GnuPG as a backend/API, this wouldn't change anything since the wizard would be completed instantly. It also probably only helps if the kernel's entropy pool is nearly full when GnuPG is started. If it's not, then the total time will remain unchanged because the kernel is already gathering entropy in the background, no matter what GnuPG is doing. - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYpxOWAAoJEI4ANxYAz5SRSB0IAKvCwyKNKn62Q3TI2zJ8NuNs rIPw1yRwsZ8hTUZFz1LHOJ/xRmNEUmV2QSapn7xNT/tEH2oa8i7sCMGyzMzZH3Gt a6gaZrwuNXf8Nu23ndeP1nu2D6j8k1rR3jbPidTuHExTRZk5j9HqtUoOrnoTT11Q ow8HU7ZwoXD983tk3yOfPa2tV1cxMnhiLq1LUEfMayhAmRkDOlzs/r83iVKroN+S DJZbQBHC+NSUULUMU8b7wTkKaWfWHpQW7/EKF7Y0roc4g2FLMMv8jLpszooDe/nt muM8wTIl1jLIGRLwTG/2ZVSd0eN7GZg+BjOuBiW90Of9xJ4MjYVDZKcHONUYj24= =rIbq -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Fri Feb 17 19:18:06 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 17 Feb 2017 13:18:06 -0500 Subject: live documentation for GpgME language bindings? Message-ID: <87shncheap.fsf@alice.fifthhorseman.net> Hey all-- Is there a canonical reference for the GpgME language bindings? Someone was asking on #gnupg on freenode's IRC network for documentation for the gpgme++ bindings, and i didn't know where to point them. it'd be nice if the qt and python bindings had some public-facing documentation too. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Fri Feb 17 20:45:19 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Feb 2017 20:45:19 +0100 Subject: Key generation: is it possible to fail fast? In-Reply-To: <87wpcoeudb.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Fri, 17 Feb 2017 15:59:12 +0100") References: <87wpcoeudb.fsf@europa.jade-hamburg.de> Message-ID: <871suwr48g.fsf@wheatstone.g10code.de> On Fri, 17 Feb 2017 15:59, justus at g10code.com said: > At our last hackathon we briefly pondered an idea to make key generation > appear fast without compromising on key strength: When the frontend > starts a new key generation wizard, start collecting entropy in the I doubt that this solves the problem. From my experience you either have a good entropy source or you don't. Without one it takes really looooong and this means looonger than the user needs to go thru a wizard. Using a hardware RNG is very good idea in all cases, next best is to use a CPU with RDRAND or Padlock. What I do for my test is rngd -r /dev/urandom which basically maps /dev/urandom to /dev/random and makes things really fast. That is of course ONLY FOR TESTING. Libgcrypt and gpg are pretty conservative in these things which might be a good or bad thing. Right now we require /dev/random for long term key generation. Given that on Linux the kernel RNG should be good enough, we could imagine an option to never use /dev/random (so basically doing the above trick). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Feb 17 21:51:46 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 17 Feb 2017 15:51:46 -0500 Subject: Key generation: is it possible to fail fast? In-Reply-To: <871suwr48g.fsf@wheatstone.g10code.de> References: <87wpcoeudb.fsf@europa.jade-hamburg.de> <871suwr48g.fsf@wheatstone.g10code.de> Message-ID: <87r32wfsm5.fsf@alice.fifthhorseman.net> On Fri 2017-02-17 14:45:19 -0500, Werner Koch wrote: > Libgcrypt and gpg are pretty conservative in these things which might be > a good or bad thing. Right now we require /dev/random for long term key > generation. Given that on Linux the kernel RNG should be good enough, > we could imagine an option to never use /dev/random (so basically doing > the above trick). The other approach, which has been advocated by folks like djb and Yevgeniy Dodis, is to take a healthy fixed-size chunk from the system's "hard" entropy source -- say, 256 bits, or 512 if you want to be conservative, and use that to seed a cryptographically-strong pseudorandom number generator (CSPRNG) like yarrow or fortuna. Then your key generation pulls from the CSPRNG, instead of /dev/random directly. There's still a risk of blocking in this framework, but it's reduced to pulling out 32 or 64 octets from /dev/random, instead of going back to blocking after you've exhausted your entropy while looking around for primes. For a long-running process like gpg-agent, this could be done once at agent initialization, and then all subsequent needs for entropy could be pulled from the internal CSPRNG. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From robbat2 at gentoo.org Sat Feb 18 05:43:19 2017 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Sat, 18 Feb 2017 04:43:19 +0000 Subject: pinentry: grab_keyboard iteration count, tiling window managers & tooltips Message-ID: TL;DR: gtk-2 tooltips interfere with gdk_keyboard_grab in some window managers, recommend disabling tooltips. I recently upgraded from pinentry 0.9.7 to pinentry 1.0.0, using the gtk+-2 frontend, and was very surprised to have it break on me in a strange way: the window would appear and disappear. It also still seemed to be present in master (as of cd7b35e8ff) I use a tiling WM, Awesome, so I've seen similar glitches in the past for windows that wanted to steal focus. Reproducable via: $ pinentry-gtk-2 <<< "GETPIN" ** (pinentry-gtk-2:10527): CRITICAL **: could not grab keyboard: not viewable (3) ** (pinentry-gtk-2:10527): WARNING **: it took 4097 tries to grab the keyboard ** (pinentry-gtk-2:10527): WARNING **: it took 233 tries to grab the pointer The issue did appear to be very similar to the previously reported Debian bug 850708, which added a fix for FVWM; however, even master still seemed to be problematic. With git bisect, I narrowed it down to commit f4b5049c68, which was strange, because it was adding a new button. Some further digging within that commit, showed that if I commented out a single line: gtk+-2/pinentry-gtk-2.c:519: gtk_widget_set_tooltip_text (GTK_WIDGET(button), tooltip); The issue reliably went away, as well and pinentry did NOT even need to retry the grab. Alternatively, if I raised the grab_keyboard max_tries limit past 4096, it DOES eventually succeed: $ pinentry-gtk-2 <<< "GETPIN" 2>&1 OK Pleased to meet you ** (pinentry-gtk-2:12534): WARNING **: it took 4705 tries to grab the keyboard D testing123 OK I went digging in Google for Gtk-2 tooltip and grabbing devices, and found that tooltip and grabbing seem to have longstanding issues together in gtk-2: https://bugzilla.gnome.org/show_bug.cgi?id=615451 Raising the count is a kind of crappy option in my opinion, so I'd like to consider the alternative of disabling the tooltip until such time as upstream Gtk fixes their issue. If we did want to go with raising the count, an hour of testing (while I went for dinner) the following on my system showed the highest count was ~7500 tries to grab the keyboard, so I'm not sure that 8192 tries will cover all cases reliably. (login from another system and touch 'escape' to kill the loop) # while true ; do \ [ -e escape ] && break ; \ timeout 1 ./gtk+-2/pinentry-gtk-2 <<< "GETPIN" 2>&1 ; \ sleep 0.1 ; \ done | tee logfile -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer E-Mail : robbat2 at gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1083 bytes Desc: Digital signature URL: From yurchor at ukr.net Sat Feb 18 13:39:48 2017 From: yurchor at ukr.net (Yuri Chornoivan) Date: Sat, 18 Feb 2017 14:39:48 +0200 Subject: [PATCH] Fix some extra word repetitions in comments and docs Message-ID: <5790498.WO4Guj2XYN@localhost.localdomain> Hi, Attached is a patch to fix extra word repetitons (like "the the" or "is is") in the code and docs. Thanks in advance for revewing it. Best regards, Yuri -------------- next part -------------- A non-text attachment was scrubbed... Name: repetitions.patch.gz Type: application/gzip Size: 21219 bytes Desc: not available URL: From robbat2 at gentoo.org Sat Feb 18 22:24:42 2017 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Sat, 18 Feb 2017 21:24:42 +0000 Subject: pinentry: grab_keyboard iteration count, tiling window managers & tooltips In-Reply-To: References: Message-ID: <20170218212442.GA6177@orbis-terrarum.net> Some further research into this, on the pinentry side, shows that the problem has surfaced multiple times: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;bug=40195 (patch was merged later) https://lists.gnupg.org/pipermail/gpa-dev/2010-April/002497.html There was another Debian bug as a followup to bug 615451 that proposed adding usleep: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851707 I took this, and added patches to: - (attached) record & emit how long it took to try grabbing the keyboard/pointer. - (attached) sleep in 0.1ms between attempts (nanosleep, based on the comments on the usleep patch) - Debugging: Always print how many tries it took, and when we ungrab. The last of these gave me the most surprising output, it showed that we did grab more than once, and we didn't ungrab. ** (pinentry-gtk-2:14728): WARNING **: it took 573 tries over 149.80 ms to grab the keyboard ** (pinentry-gtk-2:14728): WARNING **: it took 1 tries over 3.45 ms to grab the pointer ** (pinentry-gtk-2:14728): WARNING **: it took 1 tries over 0.03 ms to grab the keyboard ** (pinentry-gtk-2:14728): WARNING **: it took 1 tries over 0.04 ms to grab the pointer ERR 83886179 Operation cancelled That surprised me: why did the grab happen MORE than once? Compiling GTK w/ debugging, and using GDK_DEBUG='events' shows interesting results as well (trimmed all property notify atom cases). # GDK_DEBUG='events' ./gtk+-2/pinentry-gtk-2 <<< GETPIN 2>&1 OK Pleased to meet you ** (pinentry-gtk-2:22796): WARNING **: it took 385 tries over 97.29 ms to grab the keyboard ** (pinentry-gtk-2:22796): WARNING **: it took 1 tries over 0.69 ms to grab the pointer Gdk-Message: property notify: window: 109051905, atom(306): "_NET_WM_NAME" Gdk-Message: property notify: window: 109051905, atom(39): "WM_NAME" ... (skipping all of the atoms) Gdk-Message: configure notify: window: 109051907 x,y: 2708 536 w,h: 344 128 b-w: 0 above: 111149059 ovr: 0 Gdk-Message: configure notify: window: 109051907 x,y: 2708 536 w,h: 344 128 b-w: 0 above: 109051943 ovr: 0 Gdk-Message: destroy notify: window: 109051943 Gdk-Message: reparent notify: window: 109051907 x,y: 0 0 parent: 31459965 ovr: 0 Gdk-Message: map notify: window: 109051907 Gdk-Message: configure notify: window: 109051907 x,y: 2709 537 w,h: 344 128 b-w: 1 above: 0 ovr: 0 Gdk-Message: configure notify: window: 109051907 x,y: 0 22 w,h: 344 128 b-w: 0 above: 0 ovr: 0 Gdk-Message: configure notify: window: 109051907 x,y: 2709 559 w,h: 344 128 b-w: 1 above: 0 ovr: 0 Gdk-Message: configure notify: window: 109051907 x,y: 2709 559 w,h: 344 128 b-w: 1 above: 0 ovr: 0 Gdk-Message: visibility notify: window: 109051907 full ** (pinentry-gtk-2:22796): WARNING **: it took 1 tries over 0.04 ms to grab the keyboard ** (pinentry-gtk-2:22796): WARNING **: it took 1 tries over 0.03 ms to grab the pointer Gdk-Message: expose: window: 109051907 0 x,y: 0 0 w,h: 344 128 Gdk-Message: client message: window: 109051907 Gdk-Message: focus in: window: 109051907, detail: NotifyNonlinear, mode: NotifyNormal Gdk-Message: enter notify: window: 109051907 detail: 3 subwin: 0 mode: 1 Gdk-Message: focus out: window: 109051907, detail: NotifyInferior, mode: NotifyWhileGrabbed Gdk-Message: key press : window: 109051907 key: Escape 65307 Gdk-Message: length: 1 string: "" -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer E-Mail : robbat2 at gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gtk2-Record-how-long-we-tried-to-grab-the-keyboard-p.patch Type: text/x-diff Size: 3521 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-gtk2-sleep-between-grab-attempts.patch Type: text/x-diff Size: 2759 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1083 bytes Desc: Digital signature URL: From quae at daurnimator.com Sun Feb 19 08:17:14 2017 From: quae at daurnimator.com (Daurnimator) Date: Sun, 19 Feb 2017 18:17:14 +1100 Subject: Way to use existing scdaemon Message-ID: Hi, I was looking for a way to use an existing scdaemon instance from gpg-agent. Could we make socket_name[1] a command line option? Thanks, Daurnimator. [1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/call-scd.c;h=71e0f581ca42a5fdaf4cb7472e144ffe988a0246;hb=HEAD#l100 From gniibe at fsij.org Mon Feb 20 05:07:06 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 20 Feb 2017 13:07:06 +0900 Subject: Feature request: use existing key in --full-gen-key (was: gpg --card-status always create proxy private keys) In-Reply-To: <87efyxiszn.fsf@iwagami.gniibe.org> References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> <173383b0-01c2-b87b-5f68-df363f85e7b2@digitalbrains.com> <87efyxiszn.fsf@iwagami.gniibe.org> Message-ID: <87wpclijyt.fsf@iwagami.gniibe.org> NIIBE Yutaka writes: > Sounds good and consistent to me. Thanks for your proposal. I'll > consider implementation feasibility. I examined the related code. Here is a patch to implement the feature. Also, I found that we need to a fix ECC keys. I only tested the patch with RSA. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: pKEYGRIP.diff Type: text/x-diff Size: 12025 bytes Desc: Use existing keys in --full-gen-key URL: From wk at gnupg.org Mon Feb 20 09:15:15 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Feb 2017 09:15:15 +0100 Subject: Key generation: is it possible to fail fast? In-Reply-To: <87r32wfsm5.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 17 Feb 2017 15:51:46 -0500") References: <87wpcoeudb.fsf@europa.jade-hamburg.de> <871suwr48g.fsf@wheatstone.g10code.de> <87r32wfsm5.fsf@alice.fifthhorseman.net> Message-ID: <87h93pnur0.fsf@wheatstone.g10code.de> On Fri, 17 Feb 2017 21:51, dkg at fifthhorseman.net said: > conservative, and use that to seed a cryptographically-strong > pseudorandom number generator (CSPRNG) like yarrow or fortuna. Then > your key generation pulls from the CSPRNG, instead of /dev/random > directly. Actually this is how the Libgcrypt RNG has always worked. It is merly that as an extra security pitch we require some extra seeding for creating long term keys. Thus the actual question is whether the extra security margin we gain trough the extra seeding is worth the trouble. In the past /dev/urandom was not guaranteed to be actually seeded and thus the use of the blocking /dev/random was the needed. With the advent of the getrandom system call on Linux we known that /dev/urandom is seeded and thus we could do without the blocking /dev/random. I don't want to decide that myself, though. Shalom-Salam, Werner ps. A note about libgcrypt's RNG: This random number generator is modelled after the one described in Peter Gutmann's 1998 Usenix Security Symposium paper: "Software Generation of Practically Strong Random Numbers". See also chapter 6 in his book "Cryptographic Security Architecture", New York, 2004, ISBN 0-387-95387-6. Note that the acronym CSPRNG stands for "Continuously Seeded PseudoRandom Number Generator" as used in Peter's implementation of the paper and not only for "Cryptographically Secure PseudoRandom Number Generator". Nowadays CSPRNG is used with the meaning you gave above, which should be a self-evident for cryptograhic applications. The manual has a more detailed description. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Feb 20 08:59:55 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Feb 2017 08:59:55 +0100 Subject: Way to use existing scdaemon In-Reply-To: (Daurnimator's message of "Sun, 19 Feb 2017 18:17:14 +1100") References: Message-ID: <87lgt1nvgk.fsf@wheatstone.g10code.de> On Sun, 19 Feb 2017 08:17, quae at daurnimator.com said: > I was looking for a way to use an existing scdaemon instance from gpg-agent. > Could we make socket_name[1] a command line option? Sorry, I don't understand your question. scdaemon is managed by gpg-agent and started as needed. You could use scdaemon on your own but that is not suggested because it would conflict with gpg-agent's use of scdaemon. You can use all scdaemon commands via gpg-agent by prefixing the command with "SCD ", like this $ gpg-connect-agent > scd apdu --atr S CARD-ATR 3BDA11FF81B1FE551F0300318473800180009000E4 OK Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From justus at g10code.com Mon Feb 20 10:28:46 2017 From: justus at g10code.com (Justus Winter) Date: Mon, 20 Feb 2017 10:28:46 +0100 Subject: Key generation: is it possible to fail fast? In-Reply-To: References: <87wpcoeudb.fsf@europa.jade-hamburg.de> Message-ID: <87a89hus6p.fsf@europa.jade-hamburg.de> Bjarni Runar Einarsson writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Justus, > > Justus Winter wrote: >> At our last hackathon we briefly pondered an idea to make key >> generation appear fast without compromising on key strength: >> When the frontend starts a new key generation wizard, start >> collecting entropy in the backend, and use this to speed up the >> generation once the user completed the wizard. > > Interesting idea. > > This might improve the experience of manual users, but for tools > which use GnuPG as a backend/API, this wouldn't change anything > since the wizard would be completed instantly. > > It also probably only helps if the kernel's entropy pool is > nearly full when GnuPG is started. If it's not, then the total > time will remain unchanged because the kernel is already > gathering entropy in the background, no matter what GnuPG is > doing. Sorry, I didn't get the idea across. I meant to say that a frontend like the MUA can communicate that it started a key generation wizard to GnuPG running as a background service. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From bre at pagekite.net Mon Feb 20 10:50:32 2017 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Mon, 20 Feb 2017 09:50:32 -0000 Subject: Key generation: is it possible to fail fast? In-Reply-To: <87a89hus6p.fsf@europa.jade-hamburg.de> References: <87a89hus6p.fsf@europa.jade-hamburg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Justus! Justus Winter wrote: > > Sorry, I didn't get the idea across. I meant to say that a > frontend like the MUA can communicate that it started a key > generation wizard to GnuPG running as a background service. Thank you for the clarification. However, even this fails badly in two ways: 1) User doesn't complete the form, aborts and then starts over - except now the entropy pool has been drained. 2) Key generation is fully automatic, there's no form for the user to fill out... but I still need to inform them that key generation is happening and request they don't close the app itself. :-) Either way, Werner is right, when the entropy is replentished too slowly we're talking about key generation times well above 15 minutes. I've given up myself after half an hour and stopped recommending 4k keys by default in Mailpile for this reason alone. The time spent in the wizard just doesn't matter that much. - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYqrvsAAoJEI4ANxYAz5SRZgsH/1gi5Rf1IK9tj1eeg1va19ya SdP/U3OxEqir3LA1JtIWOuNHim89FVizpxOnny5Qx97PNLFgv7rRBRrBChENdCSz XYH/k+Y4nG7BvUn1NHJN7MRgvyqTtxa5Oawco/527mfZbTHKTad2OC2+4Bab0v2A i+xj+fgeVRs7yCnPs7YogRJ4Ghj7OXK3YILx8LsGogFpJzszWf3jMdXFMBnsWt36 arYmGVdXHhGiZJdN6g8FcALLfaJdHQm8W+ImkagL17OpbZzbmtQzfwqr8Zofq7Vq zFIncEAqYWSKxgB9SkPdG9rLfmHwkBkXr7rrzMtr7hL6YzbBHYPwutBx3FB4gco= =69yo -----END PGP SIGNATURE----- From justus at g10code.com Mon Feb 20 12:53:25 2017 From: justus at g10code.com (Justus Winter) Date: Mon, 20 Feb 2017 12:53:25 +0100 Subject: Key generation: is it possible to fail fast? In-Reply-To: References: <87a89hus6p.fsf@europa.jade-hamburg.de> Message-ID: <874lzpulhm.fsf@europa.jade-hamburg.de> Bjarni Runar Einarsson writes: > Justus Winter wrote: >> >> Sorry, I didn't get the idea across. I meant to say that a >> frontend like the MUA can communicate that it started a key >> generation wizard to GnuPG running as a background service. > > Thank you for the clarification. However, even this fails badly > in two ways: > > 1) User doesn't complete the form, aborts and then starts over - > except now the entropy pool has been drained. No, it would not be wasted. The entropy would be collected by a long-running background server. (Which brings me to an important point: There is no way that we will ever implement any features you ask for in GnuPG 1.4. This release is in deep-maintenance mode and will only ever receive bug fixes.) Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From peter at digitalbrains.com Mon Feb 20 17:51:02 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 20 Feb 2017 17:51:02 +0100 Subject: Feature request: use existing key in --full-gen-key In-Reply-To: <87wpclijyt.fsf@iwagami.gniibe.org> References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> <173383b0-01c2-b87b-5f68-df363f85e7b2@digitalbrains.com> <87efyxiszn.fsf@iwagami.gniibe.org> <87wpclijyt.fsf@iwagami.gniibe.org> Message-ID: Hello NIIBE, On 20/02/17 05:07, NIIBE Yutaka wrote: > I examined the related code. Here is a patch to implement the feature. > Also, I found that we need to a fix ECC keys. I only tested the patch > with RSA. Great, thanks! 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 From alon.barlev at gmail.com Mon Feb 20 21:40:51 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 20 Feb 2017 22:40:51 +0200 Subject: Feature request: use existing key in --full-gen-key (was: gpg --card-status always create proxy private keys) In-Reply-To: <87wpclijyt.fsf@iwagami.gniibe.org> References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> <173383b0-01c2-b87b-5f68-df363f85e7b2@digitalbrains.com> <87efyxiszn.fsf@iwagami.gniibe.org> <87wpclijyt.fsf@iwagami.gniibe.org> Message-ID: On 20 February 2017 at 06:07, NIIBE Yutaka wrote: > NIIBE Yutaka writes: >> Sounds good and consistent to me. Thanks for your proposal. I'll >> consider implementation feasibility. > > I examined the related code. Here is a patch to implement the feature. > Also, I found that we need to a fix ECC keys. I only tested the patch > with RSA. > -- Thank you so much for this! It is working perfectly with the custom scd, I can use the existing key as primary key and then add existing keys as subkeys. One minor issue, not sure it worth fixing, I must execute gpg --card-status for gnupg to find the key. Thanks! Alon From quae at daurnimator.com Tue Feb 21 03:53:40 2017 From: quae at daurnimator.com (Daurnimator) Date: Tue, 21 Feb 2017 13:53:40 +1100 Subject: Way to use existing scdaemon In-Reply-To: <87lgt1nvgk.fsf@wheatstone.g10code.de> References: <87lgt1nvgk.fsf@wheatstone.g10code.de> Message-ID: On 20 February 2017 at 18:59, Werner Koch wrote: > On Sun, 19 Feb 2017 08:17, quae at daurnimator.com said: > >> I was looking for a way to use an existing scdaemon instance from gpg-agent. >> Could we make socket_name[1] a command line option? > > Sorry, I don't understand your question. scdaemon is managed by > gpg-agent and started as needed. You could use scdaemon on your own but > that is not suggested because it would conflict with gpg-agent's use of > scdaemon. I want to be able to run scdaemon as my own user daemon (without running gpg-agent). This isn't a problem, except that you can't really run more than one scdaemon at once. So if some misc program starts gpg-agent, then gpg-agent starts it's *own* scdaemon, which doesn't work as intended.due to the first one already having e.g. my smart card open. ==> I'd like an option to put in my gpg-agent.conf to tell it to try to find a 'scdaemon --multi-server' socket ready and waiting somewhere. > You can use all scdaemon commands via gpg-agent by prefixing the command > with "SCD ", like this > > $ gpg-connect-agent > > scd apdu --atr > S CARD-ATR 3BDA11FF81B1FE551F0300318473800180009000E4 > OK I'm hoping to not run gpg-agent. From gniibe at fsij.org Tue Feb 21 04:07:39 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 21 Feb 2017 12:07:39 +0900 Subject: Feature request: use existing key in --full-gen-key (was: gpg --card-status always create proxy private keys) In-Reply-To: References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> <173383b0-01c2-b87b-5f68-df363f85e7b2@digitalbrains.com> <87efyxiszn.fsf@iwagami.gniibe.org> <87wpclijyt.fsf@iwagami.gniibe.org> Message-ID: <87ino4p7gk.fsf@iwagami.gniibe.org> Hello, The patch is committed and pushed. Alon Bar-Lev wrote: > It is working perfectly with the custom scd, I can use the existing > key as primary key and then add existing keys as subkeys. > One minor issue, not sure it worth fixing, I must execute gpg > --card-status for gnupg to find the key. I think you mean that doing "gpg --card-status" is required to have the shadowed private key in .gnupg/private-keys-v1.d. Or by "gpg", do you mean different version of GnuPG (1.4 or 2.0)? Yes, for those versions, it is required to associate keys on smartcard and .gnupg/seckey.gpg. -- From dkg at fifthhorseman.net Mon Feb 20 21:09:42 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 20 Feb 2017 15:09:42 -0500 Subject: Key generation: is it possible to fail fast? In-Reply-To: <87h93pnur0.fsf@wheatstone.g10code.de> References: <87wpcoeudb.fsf@europa.jade-hamburg.de> <871suwr48g.fsf@wheatstone.g10code.de> <87r32wfsm5.fsf@alice.fifthhorseman.net> <87h93pnur0.fsf@wheatstone.g10code.de> Message-ID: <87wpckd3p5.fsf@alice.fifthhorseman.net> On Mon 2017-02-20 03:15:15 -0500, Werner Koch wrote: > In the past /dev/urandom was not guaranteed to be actually seeded and > thus the use of the blocking /dev/random was the needed. With the > advent of the getrandom system call on Linux we known that /dev/urandom > is seeded and thus we could do without the blocking /dev/random. I don't > want to decide that myself, though. What kind of help (and from whom) would you need to make that decision? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Feb 21 05:08:33 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 20 Feb 2017 23:08:33 -0500 Subject: Way to use existing scdaemon In-Reply-To: References: <87lgt1nvgk.fsf@wheatstone.g10code.de> Message-ID: <87zihgb2ym.fsf@alice.fifthhorseman.net> On Mon 2017-02-20 21:53:40 -0500, Daurnimator wrote: > I want to be able to run scdaemon as my own user daemon (without > running gpg-agent). > This isn't a problem, except that you can't really run more than one > scdaemon at once. > So if some misc program starts gpg-agent, then gpg-agent starts it's > *own* scdaemon, which doesn't work as intended.due to the first one > already having e.g. my smart card open. > ==> I'd like an option to put in my gpg-agent.conf to tell it to try > to find a 'scdaemon --multi-server' socket ready and waiting > somewhere. > >> You can use all scdaemon commands via gpg-agent by prefixing the command >> with "SCD ", like this >> >> $ gpg-connect-agent >> > scd apdu --atr >> S CARD-ATR 3BDA11FF81B1FE551F0300318473800180009000E4 >> OK > > I'm hoping to not run gpg-agent. you've said twice in here that you don't want to run gpg-agent, but people here have already told you that scdaemon is really designed to be supervised by gpg-agent. And it sounds like you're likely to have an instance of gpg-agent running anyway, so it's not like you are trying to build a machine that doesn't have gpg-agent installed at all, either. So it kind of sounds like the old routine where the patient says "doc, it hurts when i do this," and the doctor says "well, don't do that then" :P Maybe you've got a good reason to want to run scdaemon without running gpg-agent, but we don't know what it is. Can you explain a bit more why running gpg-agent to supervise scdaemon is a problem for you? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From alon.barlev at gmail.com Tue Feb 21 06:19:39 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 21 Feb 2017 07:19:39 +0200 Subject: Feature request: use existing key in --full-gen-key (was: gpg --card-status always create proxy private keys) In-Reply-To: <87ino4p7gk.fsf@iwagami.gniibe.org> References: <87y3xams9h.fsf@fsij.org> <87a89q184i.fsf@wheatstone.g10code.de> <995cc0fc-85ad-5c0d-d192-8a0bb139cae5@digitalbrains.com> <7a21c834-7db7-5b44-ddf7-99d15805dab3@digitalbrains.com> <173383b0-01c2-b87b-5f68-df363f85e7b2@digitalbrains.com> <87efyxiszn.fsf@iwagami.gniibe.org> <87wpclijyt.fsf@iwagami.gniibe.org> <87ino4p7gk.fsf@iwagami.gniibe.org> Message-ID: On 21 February 2017 at 05:07, NIIBE Yutaka wrote: > > Hello, > > The patch is committed and pushed. > > Alon Bar-Lev wrote: > > It is working perfectly with the custom scd, I can use the existing > > key as primary key and then add existing keys as subkeys. > > One minor issue, not sure it worth fixing, I must execute gpg > > --card-status for gnupg to find the key. > > I think you mean that doing "gpg --card-status" is required to > have the shadowed private key in .gnupg/private-keys-v1.d. Yes, the user experience should be: 1. run gpg --card-status 2. generate key based on existing one I was wondering if this is intentional or we can have this automatically when trying to use existing key, worse case no card. Thanks for your work! Alon From amzh at hushmail.com Tue Feb 21 10:32:19 2017 From: amzh at hushmail.com (Andrey Mozharovskiy) Date: Tue, 21 Feb 2017 12:32:19 +0300 Subject: No subject Message-ID: <20170221093219.F224BC0666@smtp.hushmail.com> Hello, We're having some trouble with decryption in our xmpp messenger, basically some messages aren't being decrypted. Could someone please clarify, does the following make libgcrypt do all the work in separate thread : gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread) ? That is, after initializing libgcrypt like that, do all the calls to decrypt automatically go in a separate thread? -------------- next part -------------- An HTML attachment was scrubbed... URL: From amzh at hushmail.com Tue Feb 21 10:35:45 2017 From: amzh at hushmail.com (Andrey Mozharovskiy) Date: Tue, 21 Feb 2017 12:35:45 +0300 Subject: libgcrypt with multiple threads In-Reply-To: <20170221093219.F224BC0666@smtp.hushmail.com> Message-ID: <20170221093546.324C1C0666@smtp.hushmail.com> Hello, We're having some trouble with decryption in our xmpp messenger, basically some messages aren't being decrypted. Could someone please clarify, does the following make libgcrypt do all the work in separate thread : gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread) ? That is, after initializing libgcrypt like that, do all the calls to decrypt automatically go in a separate thread? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Feb 21 19:12:58 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 21 Feb 2017 13:12:58 -0500 Subject: [PATCH] Fix some extra word repetitions in comments and docs In-Reply-To: <5790498.WO4Guj2XYN@localhost.localdomain> References: <5790498.WO4Guj2XYN@localhost.localdomain> Message-ID: <87o9xv9zv9.fsf@alice.fifthhorseman.net> On Sat 2017-02-18 07:39:48 -0500, Yuri Chornoivan wrote: > Attached is a patch to fix extra word repetitons (like "the the" or "is is") in > the code and docs. Thanks for this cleanup. I've reviewed these changes, and pushed them upstream. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Tue Feb 21 19:42:41 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 21 Feb 2017 19:42:41 +0100 Subject: libgcrypt with multiple threads In-Reply-To: <20170221093546.324C1C0666@smtp.hushmail.com> (Andrey Mozharovskiy's message of "Tue, 21 Feb 2017 12:35:45 +0300") References: <20170221093546.324C1C0666@smtp.hushmail.com> Message-ID: <87efyrl71a.fsf@wheatstone.g10code.de> Hi! On Tue, 21 Feb 2017 10:35, amzh at hushmail.com said: > Could someone please clarify, does the following make libgcrypt do all > the work in separate thread : gcry_control (GCRYCTL_SET_THREAD_CBS, > &gcry_threads_pthread) ? That is, after initializing libgcrypt like > that, do all the calls to decrypt automatically go in a separate Let me quote from the manual: 'GCRYCTL_SET_THREAD_CBS; Arguments: struct ath_ops *ath_ops' This command is obsolete since version 1.6. in older versions this call was used to register a set of thread callbacks to use Libgcrypt with different thread implementations. Since 1.6 we only support the standard thread library of the platform; ie. pthreads on Unix or the standard Windows API. Your application code needs to implement decryption in another thread itself. Thake care: A cipher context (e.g. from gcry_cipher_open) may not be shared between threads. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From amzh at hushmail.com Wed Feb 22 11:30:34 2017 From: amzh at hushmail.com (Andrey Mozharovskiy) Date: Wed, 22 Feb 2017 13:30:34 +0300 Subject: libgcrypt with multiple threads In-Reply-To: <87efyrl71a.fsf@wheatstone.g10code.de> References: <20170221093546.324C1C0666@smtp.hushmail.com> <87efyrl71a.fsf@wheatstone.g10code.de> Message-ID: <20170222103034.75BE6C0669@smtp.hushmail.com> Okay, thank you On 2/21/2017 at 9:47 PM, "Werner Koch" wrote:Hi! On Tue, 21 Feb 2017 10:35, amzh at hushmail.com said: > Could someone please clarify, does the following make libgcrypt do all > the work in separate thread : gcry_control (GCRYCTL_SET_THREAD_CBS, > &gcry_threads_pthread) ? That is, after initializing libgcrypt like > that, do all the calls to decrypt automatically go in a separate Let me quote from the manual: 'GCRYCTL_SET_THREAD_CBS; Arguments: struct ath_ops *ath_ops' This command is obsolete since version 1.6. in older versions this call was used to register a set of thread callbacks to use Libgcrypt with different thread implementations. Since 1.6 we only support the standard thread library of the platform; ie. pthreads on Unix or the standard Windows API. Your application code needs to implement decryption in another thread itself. Thake care: A cipher context (e.g. from gcry_cipher_open) may not be shared between threads. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From quae at daurnimator.com Wed Feb 22 23:56:20 2017 From: quae at daurnimator.com (Daurnimator) Date: Thu, 23 Feb 2017 09:56:20 +1100 Subject: Way to use existing scdaemon In-Reply-To: <87lgt1nvgk.fsf@wheatstone.g10code.de> References: <87lgt1nvgk.fsf@wheatstone.g10code.de> Message-ID: On 20 February 2017 at 18:59, Werner Koch wrote: > You can use all scdaemon commands via gpg-agent by prefixing the command > with "SCD ", like this > > $ gpg-connect-agent > > scd apdu --atr > S CARD-ATR 3BDA11FF81B1FE551F0300318473800180009000E4 > OK Does this provide the necessary locking/transactions? e.g. if I run 'scd setdata aabbcc' 'scd pksign openpgp.1' from two programs at once, is there a race? Going through gpg-connect-agent also doesn't allow responding to scdaemon. e.g. 'scd learn' without --force doesn't let me reply to the 'inquire' From quae at daurnimator.com Thu Feb 23 00:00:34 2017 From: quae at daurnimator.com (Daurnimator) Date: Thu, 23 Feb 2017 10:00:34 +1100 Subject: Way to use existing scdaemon In-Reply-To: <87zihgb2ym.fsf@alice.fifthhorseman.net> References: <87lgt1nvgk.fsf@wheatstone.g10code.de> <87zihgb2ym.fsf@alice.fifthhorseman.net> Message-ID: On 21 February 2017 at 15:08, Daniel Kahn Gillmor wrote: > On Mon 2017-02-20 21:53:40 -0500, Daurnimator wrote: >> I want to be able to run scdaemon as my own user daemon (without >> running gpg-agent). >> This isn't a problem, except that you can't really run more than one >> scdaemon at once. >> So if some misc program starts gpg-agent, then gpg-agent starts it's >> *own* scdaemon, which doesn't work as intended.due to the first one >> already having e.g. my smart card open. >> ==> I'd like an option to put in my gpg-agent.conf to tell it to try >> to find a 'scdaemon --multi-server' socket ready and waiting >> somewhere. >> >>> You can use all scdaemon commands via gpg-agent by prefixing the command >>> with "SCD ", like this >>> >>> $ gpg-connect-agent >>> > scd apdu --atr >>> S CARD-ATR 3BDA11FF81B1FE551F0300318473800180009000E4 >>> OK >> >> I'm hoping to not run gpg-agent. > > you've said twice in here that you don't want to run gpg-agent, but > people here have already told you that scdaemon is really designed to be > supervised by gpg-agent. And it sounds like you're likely to have an > instance of gpg-agent running anyway, so it's not like you are trying to > build a machine that doesn't have gpg-agent installed at all, either. > > So it kind of sounds like the old routine where the patient says "doc, > it hurts when i do this," and the doctor says "well, don't do that then" > :P > > Maybe you've got a good reason to want to run scdaemon without running > gpg-agent, but we don't know what it is. Can you explain a bit more why > running gpg-agent to supervise scdaemon is a problem for you? I'm playing around with writing my own replacement for gpg-agent (which has it's whole own set of reasons). Having it require gpg-agent running seems superbly redundant: however at the same time I don't want to conflict with it. scdaemon seems like a useful piece of software standalone: I can see myself wanting to run it outside of a single gpg-agent anyway e.g. to have multiple gpg-agents running; or starting it on demand via a systemd unit. From bernhard at intevation.de Thu Feb 23 14:25:20 2017 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 23 Feb 2017 14:25:20 +0100 Subject: cv25519 subkey problems for some combinations (was: pubkey_encrypt failed: Provided object is too short (with 2.1.11 and Werner's new subkeys)) In-Reply-To: <201701060951.06581.bernhard@intevation.de> References: <201701051708.02493.bernhard@intevation.de> <201701060924.00656.bernhard@intevation.de> <201701060951.06581.bernhard@intevation.de> Message-ID: <201702231425.27090.bernhard@intevation.de> Am Freitag 06 Januar 2017 09:51:06 schrieb Bernhard Reiter: > Am Freitag 06 Januar 2017 09:24:00 schrieb Bernhard Reiter: > > Am Donnerstag 05 Januar 2017 20:02:57 schrieb Werner Koch: > > > > With gnupg 2.1.11 libgcrypt 1.6.5 using > > > > I know that this combination is old and probably superceded by a better > > one. (This is why I've pointed it out in two places of my post.) > > I've got a report that GnuPG 2.1.13 with libgcrypt 1.6.6 on Fedora 25 > also has this problem that it believes to have the ability to cope with > the sub cv25519 encryption key, but fails to compute the keygrip. > Leading to an unspecific general error. In addition the version for Ubuntu LTS/14.04 has the problem in a slightly different variant: gpg: Ohhhh jeeee: can't encode a 256 bit key in a 0 bits frame As this is with a stable production GNU/Linux distribution, maybe it makes sense to come up with a patch and report this to Ubuntu. This I've created https://bugs.gnupg.org/gnupg/issue2974 Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From hdevalence at riseup.net Fri Feb 24 03:43:45 2017 From: hdevalence at riseup.net (Henry de Valence) Date: Thu, 23 Feb 2017 18:43:45 -0800 Subject: SHA-1 deprecation timeline In-Reply-To: References: <20160510182551.GD1111@riseup.net> <403767b0-dc84-b876-89e2-c689e13d1301@sixdemonbag.org> <20160512133115.GA3170@riseup.net> Message-ID: <20170224024345.GB1185@riseup.net> On Fri, May 13, 2016 at 01:04:15AM -0400, Robert J. Hansen wrote: > > SHA-1 has been broken for the last 11 years... > > No. In fact, it still hasn't been broken today. Don't scaremonger. > Scaremongering about crypto is one of the quickest ways to make me angry. Just to circle back on this, actually SHA-1 has been broken today. > SHA-1 has failed to meet its cryptographic goals. It is 'broken' in an > extremely narrow cryptanalytic sense. There has been no break in it > which would result in OpenPGP messages being forgeable. We definitely > need to migrate away from it (my first "please migrate away" message was > August 19, 2005; I've been banging this drum a *long* time), but we also > need to not spread misinformation and fear. It is 'broken' in the extremely broad and practical sense that there are two PDF files with the same SHA-1 hash. You can download them from Google. > As far as the OpenPGP use case, SHA-1 is not yet broken. > > > and people have been urging its removal for at least that long > > Yes, people who don't understand a bloody thing about cryptographic > systems. The people who write them for a living have instead understood > that SHA-1 needs to be supported for at least the next decade just to > interoperate with legacy systems and traffic. > > Deprecating an optional algorithm (like MD5) is pretty easy. Removing a > required algorithm (like SHA-1) is pretty tough. And it starts by > editing the RFC to make the required algorithm optional, and then it > gets deprecated. > > > GPG only disabled MD5 in June 2014... > > It was deprecated long, *long* before that. > > > How long will GPG users have to wait this time, and what has to happen to get a > > concrete timetable, like there has been for TLS since 2014? > > Unless you've got a support contract with g10 Code, you've got no cause > to be talking like this. Nobody here owes you a blessed thing. > > You've already been told what has to happen. Once the IETF OpenPGP > Working Group publishes a new RFC with guidance for what should be done > about SHA-1, GnuPG will implement that RFC in short order -- my guess is > within weeks. The delay is in the Working Group, *not* GnuPG. What has the IETF OpenPGP working group done since last May? The TLS ecosystem has been hard at work deprecating SHA-1 for several years now. Cheers, Henry de Valence From bernhard at intevation.de Fri Feb 24 08:27:28 2017 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 24 Feb 2017 08:27:28 +0100 Subject: Ubuntu 14.04LTS problem: cv25519 subkey In-Reply-To: <201702231425.27090.bernhard@intevation.de> References: <201701051708.02493.bernhard@intevation.de> <201701060951.06581.bernhard@intevation.de> <201702231425.27090.bernhard@intevation.de> Message-ID: <201702240827.28868.bernhard@intevation.de> Am Donnerstag 23 Februar 2017 14:25:20 schrieb Bernhard Reiter: > In addition the version for Ubuntu LTS/14.04 has the problem in a slightly > different variant: Help wanted: If you have an Ubuntu "account", please report the issue, details in > https://bugs.gnupg.org/gnupg/issue2974 -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From manish at mozilla.com Sat Feb 25 05:41:39 2017 From: manish at mozilla.com (Manish Goregaokar) Date: Fri, 24 Feb 2017 20:41:39 -0800 Subject: [PATCH] g10: fix typo Message-ID: I already have copyright assignment with the FSF for GDB. I don't think I'll need to do the DCO thing. Signed-off-by: Manish Goregaokar --- g10/keygen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/g10/keygen.c b/g10/keygen.c index 844d38d..226cabd 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -5149,7 +5149,7 @@ generate_card_subkeypair (kbnode_t pub_keyblock, node = find_kbnode (pub_keyblock, PKT_PUBLIC_KEY); if (!node) { - log_error ("Oops; publkic key lost!\n"); + log_error ("Oops; public key lost!\n"); err = gpg_error (GPG_ERR_INTERNAL); goto leave; } -- 2.10.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From manish at mozilla.com Sat Feb 25 07:05:15 2017 From: manish at mozilla.com (Manish Goregaokar) Date: Fri, 24 Feb 2017 22:05:15 -0800 Subject: [PATCH] g10: fix typo Message-ID: I already have copyright assignment with the FSF for GDB. I don't think I'll need to do the DCO thing. Signed-off-by: Manish Goregaokar --- g10/keygen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/g10/keygen.c b/g10/keygen.c index 844d38d..226cabd 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -5149,7 +5149,7 @@ generate_card_subkeypair (kbnode_t pub_keyblock, node = find_kbnode (pub_keyblock, PKT_PUBLIC_KEY); if (!node) { - log_error ("Oops; publkic key lost!\n"); + log_error ("Oops; public key lost!\n"); err = gpg_error (GPG_ERR_INTERNAL); goto leave; } -- 2.10.1 From dkg at fifthhorseman.net Sat Feb 25 22:36:08 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 25 Feb 2017 16:36:08 -0500 Subject: please include --hidden-recipients in gpgme Message-ID: <87r32mt0l3.fsf@alice.fifthhorseman.net> gpgme_op_encrypt() and gpgme_op_encrypt_start() and gpgme_encrypt_sign() and gpgme_op_encrypt_sign_start() all have an option: gpgme_key_t recp[] for who the cleartext should be encrypted to. But there appears to be no way to include a list of hidden recipients (in the sense of gpg's --hidden-recipient option). I'm not sure what the right way to introduce this would be -- perhaps we need a second form of these functions, with an additional argument? I considered the possibility of adding a flag that forces all recipients to be hidden, but i think that --throw-keyids is too coarse of a hammer. The most common use case is for e-mail, where there's no point in obscuring the key IDs for recipients who are listed in the e-mail headers (though it is important to be able to hide the keyIDs of the recipients who are listed in Bcc during message composition). Any suggestions on the best way to introduce this feature for future users of gpgme? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Sun Feb 26 09:42:20 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 26 Feb 2017 00:42:20 -0800 Subject: test failure on git master with decrypt-session-key.scm (and: continuous integration?) Message-ID: <877f4dtkb7.fsf@alice.fifthhorseman.net> After a "make check" from git master, i see: Failed tests: decrypt-session-key.scm Makefile:920: recipe for target 'xcheck' failed make: *** [xcheck] Error 1 and decrypt-session-key.scm.log contains: ----------- Checking decryption of supplied files using the session key. > plain-1 gpg: Fatal: can't open '/tmp/gpgscm-20170226T080733-run-tests-v5v0mB/trustdb.gpg': No such file or directory : () 0: tests.scm:140: (throw (:stderr result)) 1: decrypt-session-key.scm:25: (call-popen `(, at gpg --status-fd=1 --decrypt --show-session-key --output ,sink ,filename) "") ----------- Using "git bisect", it appears that commit effa80e0b5fd8cf9e31a984afe391c2406edee8b ("gpg: Emit new status DECRYPTION_KEY") introduces the failure, probably because gpg is now trying to learn the trust associated with the key it's emitting. I'm not sure the right way to fix this. The simplest way is probably to create a trustdb.gpg for the test, but it also seems like gpg --decrypt shouldn't fail if the trustdb.gpg file is missing, either. Zooming out a bit: GnuPG has a good test suite, but this commit has been on master for over two days now. I'm a little surprised it hasn't been caught. Would it be possible to set up some sort of continuous integration server that would run the test suite on each new commit? It'd be nice if commits wouldn't be merged to master without passing a continuous integration check like this as well. This would have caught my recent mistake committing Yuri Chornoivan's word replication cleanup, which also broke the test suite because the test suite depends on a duplicated word. Thanks to Gniibe for catching my error and fixing it! Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From gniibe at fsij.org Mon Feb 27 00:31:04 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 27 Feb 2017 08:31:04 +0900 Subject: continuous integration? In-Reply-To: <877f4dtkb7.fsf@alice.fifthhorseman.net> References: <877f4dtkb7.fsf@alice.fifthhorseman.net> Message-ID: <874lzg8r7r.fsf@iwagami.gniibe.org> Daniel Kahn Gillmor wrote: > Zooming out a bit: > > GnuPG has a good test suite, but this commit has been on master for over > two days now. I'm a little surprised it hasn't been caught. Would it > be possible to set up some sort of continuous integration server that > would run the test suite on each new commit? Let's share more information. Thanks to Justus, we have the jenkins server (now, with IPv4 address) at: https://jenkins.gnupg.org/ At XMPP channel of gnupg-devel at conference.jabber.gnupg.org, the jenkins server emits message of each build. IIUC, it builds for debian/macos/openbsd/w32 at each new commit and for sanitizer/distcheck daily on some conditions. For GnuPG, it's: https://jenkins.gnupg.org/job/gnupg/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From justus at g10code.com Tue Feb 28 10:35:27 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 28 Feb 2017 10:35:27 +0100 Subject: test failure on git master with decrypt-session-key.scm (and: continuous integration?) In-Reply-To: <877f4dtkb7.fsf@alice.fifthhorseman.net> References: <877f4dtkb7.fsf@alice.fifthhorseman.net> Message-ID: <87y3wq4q00.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > [ Unknown signature status ] (Off-topic: I'm using notmuch with the emacs frontend as distributed by Debian. In the notmuch-show buffer it says: [ Good signature by key: 0x38276051EA477FA3E49539321498ADC6C1923237 ] However, as soon as I hit reply, it says unknown signature status.) > After a "make check" from git master, i see: > > Failed tests: decrypt-session-key.scm > Makefile:920: recipe for target 'xcheck' failed > make: *** [xcheck] Error 1 > > and decrypt-session-key.scm.log contains: > > ----------- > Checking decryption of supplied files using the session key. > > plain-1 gpg: Fatal: can't open '/tmp/gpgscm-20170226T080733-run-tests-v5v0mB/trustdb.gpg': No such file or directory > : () > 0: tests.scm:140: (throw (:stderr result)) > 1: decrypt-session-key.scm:25: (call-popen `(, at gpg --status-fd=1 --decrypt --show-session-key --output ,sink ,filename) "") > ----------- > > Using "git bisect", it appears that commit > effa80e0b5fd8cf9e31a984afe391c2406edee8b ("gpg: Emit new status > DECRYPTION_KEY") introduces the failure, probably because gpg is now > trying to learn the trust associated with the key it's emitting. > > I'm not sure the right way to fix this. The simplest way is probably to > create a trustdb.gpg for the test, but it also seems like gpg --decrypt > shouldn't fail if the trustdb.gpg file is missing, either. I dug into this. The change introduced a status line which includes the owner trust of the key used to decrypt the message. The reason why this breaks the tests is that we run all tests (except for the TOFU test) with --always-trust, hence no trust database is ever created. It only breaks this particular test because it is the only decryption test using --status-fd. This really highlights two problems: 1/ What should the new status line say when used with --always-trust? 2/ The code doesn't cope well when querying / updating the trustdb fails. This isn't easy to fix unfortunately. > Zooming out a bit: > > GnuPG has a good test suite, but this commit has been on master for over > two days now. I'm a little surprised it hasn't been caught. Would it > be possible to set up some sort of continuous integration server that > would run the test suite on each new commit? We don't build every revision, but we do builds as post-commit action, and nightly builds, weekly for the stable branches. > It'd be nice if commits wouldn't be merged to master without passing a > continuous integration check like this as well. This would have caught > my recent mistake committing Yuri Chornoivan's word replication cleanup, That is a policy change and needs to be discussed. Our current unwritten policy is: please run make check before pushing changes to catch the most obvious problems, but if problems crop up in distcheck or on non-Linux platforms, it is ok to fix them afterwards. > which also broke the test suite because the test suite depends on a > duplicated word. Thanks to Gniibe for catching my error and fixing > it! Ouch :/ Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wk at gnupg.org Tue Feb 28 20:56:13 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Feb 2017 20:56:13 +0100 Subject: test failure on git master with decrypt-session-key.scm (and: continuous integration?) In-Reply-To: <877f4dtkb7.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sun, 26 Feb 2017 00:42:20 -0800") References: <877f4dtkb7.fsf@alice.fifthhorseman.net> Message-ID: <871suif5sy.fsf@wheatstone.g10code.de> On Sun, 26 Feb 2017 09:42, dkg at fifthhorseman.net said: > effa80e0b5fd8cf9e31a984afe391c2406edee8b ("gpg: Emit new status > DECRYPTION_KEY") introduces the failure, probably because gpg is now Am sorry for that. I was working on a nasty regression we had in Windows over the last week and weekend and obviously forgot to run the "make check" before pushing (or I only tested it manually on Windows). I implemented that feature only because I required a break from getting setup looking with insufficient tools on the Windows problem for too long. Fortunately the Windows problems was fixed and I just pushed a fixed for the DECRYPTION_KEY regression. > I'm not sure the right way to fix this. The simplest way is probably to > create a trustdb.gpg for the test, but it also seems like gpg --decrypt > shouldn't fail if the trustdb.gpg file is missing, either. Justus already explained the things. My fix simply inhibits the creation of a trustdb in the DECRYPTION_KEY case and when listing other keys to which a message was also encrypted, > It'd be nice if commits wouldn't be merged to master without passing a > continuous integration check like this as well. This would have caught The whole test suite runs pretty long and we plan to add even more platforms. Right now we are just a few hackers which can push to the git.gnupg.org master and in general we notice regression pretty fast. We rely on seeing each other changes soon. This time it was carnival, most of us not on duty (Monday was a holiday for g10 Code people), and I was working on the laptop without an open tab on our Jenkins. Of course it would be possible to have a staging branch which pushes to master nonly after all regression tests have passed. But that would not have helped you either to detect that (funny) dup-word-required issue. Thanks to you and Justus for tracking down the problem I introduced. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: