From gniibe at fsij.org Thu Oct 1 06:27:23 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 01 Oct 2015 13:27:23 +0900 Subject: ssh: Fix allocation of pinentry buffer In-Reply-To: <87si5w9ttb.wl-neal@walfield.org> References: <5609004B.2070706@fsij.org> <8737xyhlmp.fsf@vigenere.g10code.de> <5609F2A0.1050301@fsij.org> <87si5w9ttb.wl-neal@walfield.org> Message-ID: <560CB62B.6030303@fsij.org> On 09/30/2015 05:48 PM, Neal H. Walfield wrote: > I think your patch is correct, but I'd prefer a change that increases > robustness rather than one that preserves this fragility. Second, > this bug is also present in agent/genkey.c. Can you fix it there as > well? Thank you for reviewing. Actually, the code around pinentry invocation has more bugs, and more fixes are expected. So, I was considering a step-by-step approach would be better and cherry-picking some of patches into 2.0. I should have expressed that. (Well, my patch yesterday include change of agent/genkey.c.) It's complicated because there are multiple communications, and some arbitrary numbers. I think that you've changed a number like 100 by MAX_PASSPHRASE_LEN, but there are still numbers like 90 and 100. Here is a picture: loopback gpg <-------> PIN gpg-agent <---> scdaemon pinentry <--> passphrase / PIN Passphrase for local keys and PIN for card are different things, and it would make sense to have different values for each. But, the length limitation would be ok to be same. Following is current my working patch around passphrase/pin inputs. There are semantic inconsistency (of buffer length or of passphrase length), off-by-one errors, allocation assumption mistake (caller/callee allocation responsibility), and inconsistent string handling (sending all buffer or only string). Following patch is not intended to commit directly. It's to show more to be done. Perhaps, it would be good to do: fixed size allocation and fixed size communication scdaemon can limit the length of PIN to lower value than the one for passphrase diff --git a/agent/agent.h b/agent/agent.h index b3e8470..0057c03 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -260,10 +260,8 @@ struct pin_entry_info_s int (*check_cb)(struct pin_entry_info_s *); /* CB used to check the PIN */ void *check_cb_arg; /* optional argument which might be of use in the CB */ const char *cb_errtext; /* used by the cb to display a specific error */ - size_t max_length; /* Allocated length of the buffer PIN. */ - char pin[1]; /* The buffer to hold the PIN or passphrase. - It's actual allocated length is given by - MAX_LENGTH (above). */ + /* The buffer to hold the PIN or passphrase. */ + char pin[MAX_PASSPHRASE_LEN+1]; }; @@ -350,8 +348,7 @@ void bump_key_eventcounter (void); void bump_card_eventcounter (void); void start_command_handler (ctrl_t, gnupg_fd_t, gnupg_fd_t); gpg_error_t pinentry_loopback (ctrl_t, const char *keyword, - unsigned char **buffer, size_t *size, - size_t max_length); + unsigned char **buffer, size_t *size); #ifdef HAVE_W32_SYSTEM int serve_mmapped_ssh_request (ctrl_t ctrl, diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index 9845a03..c16c874 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -829,8 +829,7 @@ agent_askpin (ctrl_t ctrl, size_t size; *pininfo->pin = 0; /* Reset the PIN. */ - rc = pinentry_loopback(ctrl, "PASSPHRASE", &passphrase, &size, - pininfo->max_length); + rc = pinentry_loopback(ctrl, "PASSPHRASE", &passphrase, &size); if (rc) return rc; @@ -848,7 +847,7 @@ agent_askpin (ctrl_t ctrl, return gpg_error(GPG_ERR_NO_PIN_ENTRY); } - if (!pininfo || pininfo->max_length < 1) + if (!pininfo) return gpg_error (GPG_ERR_INV_VALUE); if (!desc_text && pininfo->min_digits) desc_text = L_("Please enter your PIN, so that the secret key " @@ -933,7 +932,7 @@ agent_askpin (ctrl_t ctrl, for (;pininfo->failed_tries < pininfo->max_tries; pininfo->failed_tries++) { memset (&parm, 0, sizeof parm); - parm.size = pininfo->max_length; + parm.size = MAX_PASSPHRASE_LEN; *pininfo->pin = 0; /* Reset the PIN. */ parm.buffer = (unsigned char*)pininfo->pin; @@ -1062,10 +1061,9 @@ agent_get_passphrase (ctrl_t ctrl, if (ctrl->pinentry_mode == PINENTRY_MODE_LOOPBACK) { size_t size; - size_t len = ASSUAN_LINELENGTH/2; - unsigned char *buffer = gcry_malloc_secure (len); + unsigned char *buffer; - rc = pinentry_loopback(ctrl, "PASSPHRASE", &buffer, &size, len); + rc = pinentry_loopback(ctrl, "PASSPHRASE", &buffer, &size); if (rc) xfree(buffer); else diff --git a/agent/call-scd.c b/agent/call-scd.c index 6cd5825..bb46e3f 100644 --- a/agent/call-scd.c +++ b/agent/call-scd.c @@ -711,7 +711,7 @@ inq_needpin (void *opaque, const char *line) if ((s = has_leading_keyword (line, "NEEDPIN"))) { line = s; - pinlen = 90; + pinlen = MAX_PASSPHRASE_LEN+1; pin = gcry_malloc_secure (pinlen); if (!pin) return out_of_core (); diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 8be1255..4469e46 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -3101,17 +3101,15 @@ ssh_identity_register (ctrl_t ctrl, ssh_key_type_spec_t *spec, goto out; } - pi = gcry_calloc_secure (2, sizeof (*pi) + MAX_PASSPHRASE_LEN + 1); + pi = gcry_calloc_secure (2, sizeof (*pi)); if (!pi) { err = gpg_error_from_syserror (); goto out; } - pi2 = pi + (sizeof *pi + MAX_PASSPHRASE_LEN + 1); - pi->max_length = MAX_PASSPHRASE_LEN + 1; + pi2 = pi + 1; pi->max_tries = 1; pi->with_repeat = 1; - pi2->max_length = MAX_PASSPHRASE_LEN + 1; pi2->max_tries = 1; pi2->check_cb = reenter_compare_cb; pi2->check_cb_arg = pi->pin; @@ -3155,8 +3153,8 @@ ssh_identity_register (ctrl_t ctrl, ssh_key_type_spec_t *spec, out: - if (pi && pi->max_length) - wipememory (pi->pin, pi->max_length); + if (pi) + wipememory (pi->pin, MAX_PASSPHRASE_LEN+1); xfree (pi); xfree (buffer); xfree (comment); diff --git a/agent/command.c b/agent/command.c index f09a2ff..63d2d21 100644 --- a/agent/command.c +++ b/agent/command.c @@ -3250,18 +3250,17 @@ start_command_handler (ctrl_t ctrl, gnupg_fd_t listen_fd, gnupg_fd_t fd) parameters on to the client. */ gpg_error_t pinentry_loopback(ctrl_t ctrl, const char *keyword, - unsigned char **buffer, size_t *size, - size_t max_length) + unsigned char **buffer, size_t *size) { gpg_error_t rc; assuan_context_t ctx = ctrl->server_local->assuan_ctx; - rc = print_assuan_status (ctx, "INQUIRE_MAXLEN", "%zu", max_length); + rc = print_assuan_status (ctx, "INQUIRE_MAXLEN", "%zu", MAX_PASSPHRASE_LEN); if (rc) return rc; assuan_begin_confidential (ctx); - rc = assuan_inquire (ctx, keyword, buffer, size, max_length); + rc = assuan_inquire (ctx, keyword, buffer, size, MAX_PASSPHRASE_LEN); assuan_end_confidential (ctx); return rc; } diff --git a/agent/cvt-openpgp.c b/agent/cvt-openpgp.c index fb5a473..b42084c 100644 --- a/agent/cvt-openpgp.c +++ b/agent/cvt-openpgp.c @@ -916,10 +916,9 @@ convert_from_openpgp_main (ctrl_t ctrl, gcry_sexp_t s_pgp, struct pin_entry_info_s *pi; struct try_do_unprotect_arg_s pi_arg; - pi = xtrycalloc_secure (1, sizeof (*pi) + MAX_PASSPHRASE_LEN + 1); + pi = xtrycalloc_secure (1, sizeof (*pi)); if (!pi) return gpg_error_from_syserror (); - pi->max_length = MAX_PASSPHRASE_LEN + 1; pi->min_digits = 0; /* We want a real passphrase. */ pi->max_digits = 16; pi->max_tries = 3; @@ -954,7 +953,7 @@ convert_from_openpgp_main (ctrl_t ctrl, gcry_sexp_t s_pgp, cache_value = agent_get_cache (cache_nonce, CACHE_MODE_NONCE); if (cache_value) { - if (strlen (cache_value) < pi->max_length) + if (strlen (cache_value) < MAX_PASSPHRASE_LEN) strcpy (pi->pin, cache_value); xfree (cache_value); } @@ -963,7 +962,7 @@ convert_from_openpgp_main (ctrl_t ctrl, gcry_sexp_t s_pgp, } else if (from_native) { - if (strlen (passphrase) < pi->max_length) + if (strlen (passphrase) < MAX_PASSPHRASE_LEN) strcpy (pi->pin, passphrase); err = try_do_unprotect_cb (pi); } diff --git a/agent/divert-scd.c b/agent/divert-scd.c index a2da9e7..955233c 100644 --- a/agent/divert-scd.c +++ b/agent/divert-scd.c @@ -260,10 +260,9 @@ getpin_cb (void *opaque, const char *info, char *buf, size_t maxbuf) mess because we should call the card's verify function from the pinentry check pin CB. */ again: - pi = gcry_calloc_secure (1, sizeof (*pi) + maxbuf + 10); + pi = gcry_calloc_secure (1, sizeof (*pi)); if (!pi) return gpg_error_from_syserror (); - pi->max_length = maxbuf-1; pi->min_digits = 0; /* we want a real passphrase */ pi->max_digits = 16; pi->max_tries = 3; @@ -275,14 +274,13 @@ getpin_cb (void *opaque, const char *info, char *buf, size_t maxbuf) if (!rc && newpin) { struct pin_entry_info_s *pi2; - pi2 = gcry_calloc_secure (1, sizeof (*pi) + maxbuf + 10); + pi2 = gcry_calloc_secure (1, sizeof (*pi)); if (!pi2) { rc = gpg_error_from_syserror (); xfree (pi); return rc; } - pi2->max_length = maxbuf-1; pi2->min_digits = 0; pi2->max_digits = 16; pi2->max_tries = 1; diff --git a/agent/findkey.c b/agent/findkey.c index c49c37a..e70aace 100644 --- a/agent/findkey.c +++ b/agent/findkey.c @@ -450,10 +450,9 @@ unprotect (ctrl_t ctrl, const char *cache_nonce, const char *desc_text, } } - pi = gcry_calloc_secure (1, sizeof (*pi) + MAX_PASSPHRASE_LEN + 1); + pi = gcry_calloc_secure (1, sizeof (*pi)); if (!pi) return gpg_error_from_syserror (); - pi->max_length = MAX_PASSPHRASE_LEN + 1; pi->min_digits = 0; /* we want a real passphrase */ pi->max_digits = 16; pi->max_tries = 3; diff --git a/agent/genkey.c b/agent/genkey.c index 13858ca..f6fab33 100644 --- a/agent/genkey.c +++ b/agent/genkey.c @@ -357,10 +357,9 @@ agent_ask_new_passphrase (ctrl_t ctrl, const char *prompt, if (ctrl->pinentry_mode == PINENTRY_MODE_LOOPBACK) { size_t size; - size_t len = 100; unsigned char *buffer; - err = pinentry_loopback(ctrl, "NEW_PASSPHRASE", &buffer, &size, len); + err = pinentry_loopback(ctrl, "NEW_PASSPHRASE", &buffer, &size); if (!err) { if (size) @@ -374,13 +373,11 @@ agent_ask_new_passphrase (ctrl_t ctrl, const char *prompt, return err; } - pi = gcry_calloc_secure (2, sizeof (*pi) + MAX_PASSPHRASE_LEN + 1); - pi2 = pi + (sizeof *pi + MAX_PASSPHRASE_LEN + 1); - pi->max_length = MAX_PASSPHRASE_LEN + 1; + pi = gcry_calloc_secure (2, sizeof (*pi)); + pi2 = pi + 1; pi->max_tries = 3; pi->with_qualitybar = 1; pi->with_repeat = 1; - pi2->max_length = MAX_PASSPHRASE_LEN + 1; pi2->max_tries = 3; pi2->check_cb = reenter_compare_cb; pi2->check_cb_arg = pi->pin; -- From gniibe at fsij.org Thu Oct 1 07:21:17 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 01 Oct 2015 14:21:17 +0900 Subject: Optimization-dependent behavior with GnuPG 1.4.19 and GCC 5 In-Reply-To: <20150930071652.GA22565@kevinolos> References: <20150930071652.GA22565@kevinolos> Message-ID: <560CC2CD.8050101@fsij.org> Hello, Thank you for the bug report with reproducible scenario. On 09/30/2015 04:16 PM, Kevin Locke wrote: > Debugging the behavior in gdb shows that in parse_signature at > g10/parse-packet.c:1413, sig->unhashed is NULL. This results in > taking the branch at g10/parse-packet.c:1185 in enum_sig_subpkt which > returns the address of the pktbuf argument. Although the code expects > this to result in a non-NULL value, it appears that the compiler > optimizations at -O2 result in returning a NULL value. I'm unsure if > this is a compiler error, or if this is allowed as undefined behavior > when using the address of an argument after a function has returned. Your analysis is correct. I think it's up to compiler. > Thoughts? Is anyone else seeing this behavior? I confirmed this bug in my Debian machine. We have a fix for master branch. I'm going to backport this to 2.0 and 1.4. ======================================================= commit 6a0c3fa19cfcdd590b96691e8a8ffb48fb5e0ec4 Author: Werner Koch Date: Thu Sep 18 15:08:51 2014 +0200 gpg: Silence a compiler warning. * g10/parse-packet.c (enum_sig_subpkt): Replace hack. diff --git a/g10/parse-packet.c b/g10/parse-packet.c index edaa84d..f7b2079 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -1428,11 +1428,10 @@ enum_sig_subpkt (const subpktarea_t * pktbuf, sigsubpkttype_t reqtype, if (!pktbuf || reqseq == -1) { - /* return some value different from NULL to indicate that - * there is no critical bit we do not understand. The caller - * will never use the value. Yes I know, it is an ugly hack */ - return reqtype == - SIGSUBPKT_TEST_CRITICAL ? (const byte *) &pktbuf : NULL; + static char dummy[] = "x"; + /* Return a value different from NULL to indicate that + * there is no critical bit we do not understand. */ + return reqtype == SIGSUBPKT_TEST_CRITICAL ? dummy : NULL; } buffer = pktbuf->data; buflen = pktbuf->len; -- From kevin at kevinlocke.name Thu Oct 1 07:41:27 2015 From: kevin at kevinlocke.name (Kevin Locke) Date: Wed, 30 Sep 2015 22:41:27 -0700 Subject: Optimization-dependent behavior with GnuPG 1.4.19 and GCC 5 In-Reply-To: <560CC2CD.8050101@fsij.org> References: <20150930071652.GA22565@kevinolos> <560CC2CD.8050101@fsij.org> Message-ID: <20151001054127.GA12084@kevinolos> On Thu, 2015-10-01 at 14:21 +0900, NIIBE Yutaka wrote: > Thank you for the bug report with reproducible scenario. My pleasure, thank you for looking into it. > On 09/30/2015 04:16 PM, Kevin Locke wrote: >> Debugging the behavior in gdb shows that in parse_signature at >> g10/parse-packet.c:1413, sig->unhashed is NULL. This results in >> taking the branch at g10/parse-packet.c:1185 in enum_sig_subpkt which >> returns the address of the pktbuf argument. Although the code expects >> this to result in a non-NULL value, it appears that the compiler >> optimizations at -O2 result in returning a NULL value. I'm unsure if >> this is a compiler error, or if this is allowed as undefined behavior >> when using the address of an argument after a function has returned. > > [...] > > We have a fix for master branch. I'm going to backport this to 2.0 > and 1.4. The patch looks great. That should solve the issue going forward. Any idea if sig->unhashed being NULL is easily avoidable when creating signed documents as a workaround for users with affected versions already in the wild? I can investigate, but I'm not familiar with the PGP format, which makes investigating a bit slow. Thanks again, Kevin From gniibe at fsij.org Thu Oct 1 09:19:19 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 01 Oct 2015 16:19:19 +0900 Subject: Optimization-dependent behavior with GnuPG 1.4.19 and GCC 5 In-Reply-To: <20151001054127.GA12084@kevinolos> References: <20150930071652.GA22565@kevinolos> <560CC2CD.8050101@fsij.org> <20151001054127.GA12084@kevinolos> Message-ID: <560CDE77.2090808@fsij.org> On 10/01/2015 02:41 PM, Kevin Locke wrote: > Any idea if sig->unhashed being NULL is easily avoidable when creating > signed documents as a workaround for users with affected versions > already in the wild? I don't think we have an easy way. Fortunately, GnuPG itself doesn't produce such a signature. Dumping the signature packet of the file (InRelease) by pgpgdump, it is: ====================================== New: Signature Packet(tag 2)(284 bytes) Ver 4 - new Sig type - Signature of a canonical text document(0x01). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Thu Oct 1 14:06:24 JST 2015 Hashed Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x3746C208A7317B0F Hash left 2 bytes - d5 16 RSA m^d mod n(2048 bits) - ... -> PKCS-1 ====================================== Here, issuer key ID is hashed (and we don't have unhashed packet). GnuPG puts issuer key ID to unhashed packet. -- From neal at walfield.org Thu Oct 1 11:39:49 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 01 Oct 2015 11:39:49 +0200 Subject: ssh: Fix allocation of pinentry buffer In-Reply-To: <560CB62B.6030303@fsij.org> References: <5609004B.2070706@fsij.org> <8737xyhlmp.fsf@vigenere.g10code.de> <5609F2A0.1050301@fsij.org> <87si5w9ttb.wl-neal@walfield.org> <560CB62B.6030303@fsij.org> Message-ID: <87pp0z9bbu.wl-neal@walfield.org> Hi Niibe-san, At Thu, 01 Oct 2015 13:27:23 +0900, NIIBE Yutaka wrote: > Thank you for reviewing. Actually, the code around pinentry > invocation has more bugs, and more fixes are expected. > So, I was considering a step-by-step approach would be better and > cherry-picking some of patches into 2.0. I should have expressed > that. I prefer commits that encapsulate a single change. This is the logical unit of change. And, this can later help to identify the cause of problems using git bisect. Werner sometimes has slightly larger commits arguing that git bisect is rarely needed in practice and, when it is used, the added resolution doesn't help find the problem much faster. Further, he points out that breaking up and testing the individual commits adds overhead. > (Well, my patch yesterday include change of agent/genkey.c.) Whoops. I somehow overlooked that the second change was for genkey.c! I'm sorry! > It's complicated because there are multiple communications, and some > arbitrary numbers. I think that you've changed a number like 100 by > MAX_PASSPHRASE_LEN, but there are still numbers like 90 and 100. Werner and I chatted about this a while ago and these constants should be replaced by symbolic expressions. > Here is a picture: > > loopback > gpg <-------> PIN > gpg-agent <---> scdaemon > pinentry <--> > passphrase / PIN > > Passphrase for local keys and PIN for card are different things, and > it would make sense to have different values for each. But, the > length limitation would be ok to be same. What do you mean by different values? Do you mean lengths? > Following is current my working patch around passphrase/pin inputs. > There are semantic inconsistency (of buffer length or of passphrase > length), off-by-one errors, allocation assumption mistake > (caller/callee allocation responsibility), and inconsistent string > handling (sending all buffer or only string). Thanks for auditing this! > Perhaps, it would be good to do: > fixed size allocation and fixed size communication If we have a small limit, it is probably always better to use fixed size allocations rather than attempting to save a few bytes while increasing the code's complexity. > diff --git a/agent/agent.h b/agent/agent.h > index b3e8470..0057c03 100644 > --- a/agent/agent.h > +++ b/agent/agent.h > @@ -260,10 +260,8 @@ struct pin_entry_info_s > int (*check_cb)(struct pin_entry_info_s *); /* CB used to check the PIN */ > void *check_cb_arg; /* optional argument which might be of use in the CB */ > const char *cb_errtext; /* used by the cb to display a specific error */ > - size_t max_length; /* Allocated length of the buffer PIN. */ > - char pin[1]; /* The buffer to hold the PIN or passphrase. > - It's actual allocated length is given by > - MAX_LENGTH (above). */ > + /* The buffer to hold the PIN or passphrase. */ > + char pin[MAX_PASSPHRASE_LEN+1]; > }; This is a good change, I think. > @@ -963,7 +962,7 @@ convert_from_openpgp_main (ctrl_t ctrl, gcry_sexp_t s_pgp, > } > else if (from_native) > { > - if (strlen (passphrase) < pi->max_length) > + if (strlen (passphrase) < MAX_PASSPHRASE_LEN) > strcpy (pi->pin, passphrase); Shouldn't this be <=, not (NIIBE Yutaka's message of "Thu, 01 Oct 2015 13:27:23 +0900") References: <5609004B.2070706@fsij.org> <8737xyhlmp.fsf@vigenere.g10code.de> <5609F2A0.1050301@fsij.org> <87si5w9ttb.wl-neal@walfield.org> <560CB62B.6030303@fsij.org> Message-ID: <877fn6bzjd.fsf@vigenere.g10code.de> On Thu, 1 Oct 2015 06:27, gniibe at fsij.org said: > Thank you for reviewing. Actually, the code around pinentry > invocation has more bugs, and more fixes are expected. AFAIC, these bugs are due to the avoidance of a second malloc. This was my fault initially. Later others copied that code for use at other places. Interestingly agent/divert-scd does it correctly. > fixed size allocation and fixed size communication The pin_entry_info_s is allocated in secure memory thus when piossible it should be limited in size. What about this basic fix? If there are other problem they can be applied on top of this. >From 3e71ed12acbb54ec5cf5d347f62b57bb8a0ad233 Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Thu, 1 Oct 2015 13:21:25 +0200 Subject: [PATCH] agent: Fix alignment problem with the second passphrase struct. * agent/genkey.c (agent_ask_new_passphrase): Use a separate malloc for PI2. Check return value of the malloc function. * agent/command-ssh.c (ssh_identity_register): Use a separate malloc for PI2. Wipe PI2. -- For whatever stupid reasons I once allocated only one memory area and split that into PI and PI2. This is actually a common pattern with malloc but here we used a made up object size and do not take the extra alignment required into account. One of these not yet hit by a (sig)bus PC/VAX hacker bugs. Instead of trying to fix the alignment, it is better to use a second calloc for the second struct. GnuPG-bug-id: 2112 Signed-off-by: Werner Koch --- agent/command-ssh.c | 15 ++++++++++++--- agent/genkey.c | 13 +++++++++++-- 2 files changed, 23 insertions(+), 5 deletions(-) diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 8be1255..0aa0098 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -3070,7 +3070,8 @@ ssh_identity_register (ctrl_t ctrl, ssh_key_type_spec_t *spec, char *comment = NULL; char *key_fpr = NULL; const char *initial_errtext = NULL; - struct pin_entry_info_s *pi = NULL, *pi2; + struct pin_entry_info_s *pi = NULL; + struct pin_entry_info_s *pi2 = NULL; err = ssh_key_grip (key, key_grip_raw); if (err) @@ -3101,13 +3102,18 @@ ssh_identity_register (ctrl_t ctrl, ssh_key_type_spec_t *spec, goto out; } - pi = gcry_calloc_secure (2, sizeof (*pi) + MAX_PASSPHRASE_LEN + 1); + pi = gcry_calloc_secure (1, sizeof (*pi) + MAX_PASSPHRASE_LEN + 1); if (!pi) { err = gpg_error_from_syserror (); goto out; } - pi2 = pi + (sizeof *pi + MAX_PASSPHRASE_LEN + 1); + pi2 = gcry_calloc_secure (1, sizeof (*pi2) + MAX_PASSPHRASE_LEN + 1); + if (!pi2) + { + err = gpg_error_from_syserror (); + goto out; + } pi->max_length = MAX_PASSPHRASE_LEN + 1; pi->max_tries = 1; pi->with_repeat = 1; @@ -3155,6 +3161,9 @@ ssh_identity_register (ctrl_t ctrl, ssh_key_type_spec_t *spec, out: + if (pi2 && pi2->max_length) + wipememory (pi2->pin, pi2->max_length); + xfree (pi2); if (pi && pi->max_length) wipememory (pi->pin, pi->max_length); xfree (pi); diff --git a/agent/genkey.c b/agent/genkey.c index 13858ca..e8195c2 100644 --- a/agent/genkey.c +++ b/agent/genkey.c @@ -374,8 +374,16 @@ agent_ask_new_passphrase (ctrl_t ctrl, const char *prompt, return err; } - pi = gcry_calloc_secure (2, sizeof (*pi) + MAX_PASSPHRASE_LEN + 1); - pi2 = pi + (sizeof *pi + MAX_PASSPHRASE_LEN + 1); + pi = gcry_calloc_secure (1, sizeof (*pi) + MAX_PASSPHRASE_LEN + 1); + if (!pi) + return gpg_error_from_syserror (); + pi2 = gcry_calloc_secure (1, sizeof (*pi2) + MAX_PASSPHRASE_LEN + 1); + if (!pi2) + { + err = gpg_error_from_syserror (); + xfree (pi2); + return err; + } pi->max_length = MAX_PASSPHRASE_LEN + 1; pi->max_tries = 3; pi->with_qualitybar = 1; @@ -422,6 +430,7 @@ agent_ask_new_passphrase (ctrl_t ctrl, const char *prompt, } xfree (initial_errtext); + xfree (pi2); xfree (pi); return err; } -- 2.1.4 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Thu Oct 1 23:17:10 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 01 Oct 2015 23:17:10 +0200 Subject: TOFU code available Message-ID: <87oagi9tm1.wl-neal@walfield.org> Hi! I now have an almost complete version of the TOFU code available for testing. I've pushed it to the neal/next branch. I'd appreciate if people would try it. $ git clone git://git.gnupg.org/gnupg.git $ git checkout neal/next The patch adds two new trust models: tofu and tofu+pgp (alias: tofu+wot). The first trust model just uses TOFU for determining whether a key is trusted. The second combines TOFU and the WoT. The basic idea is that we evaluate the key's trust in both models and then if either deems the key to be untrusted (NEVER or EXPIRE) that is returned. Otherwise, the maximum of the two is returned (UNKNOWN < UNDEFINED < MARGINAL < FULLY < ULTIMATE). I've implemented TOFU as follows: when we observe a new binding (), we add it to the TOFU database. If there is no other binding with the email address, then there is no conflict and we just silently add the binding to the TOFU database with the "auto" policy. Consider: $ gpg2 --trust-model=tofu --verify EE37CF96-1.txt gpg: Signature made Fri 18 Sep 2015 02:05:37 PM CEST using RSA key ID EE37CF96 gpg: TOFU: New binding , no conflict. gpg: TOFU: Set trust policy for binding <362D3527F53AAD1971AAFDE658859975EE37CF96, testing (insecure!)> to auto. gpg: DBG: TOFU: Saving signature <362D3527F53AAD1971AAFDE658859975EE37CF96, testing (insecure!), oyOLc2uXxiTbOdZwSqlo03fxBX8TAhE8iNJkBlEaYso> gpg: Good signature from "Testing (insecure!)" [full] gpg: TOFU: auto (default trust: auto) binding: <362D3527F53AAD1971AAFDE658859975EE37CF96, testing (insecure!)> gpg: DBG: Already observed the signature There are 5 policies in all: good, unknown, bad, auto and ask. It is possible to manually set the policy as follows: $ gpg2 --tofu-policy good 2183839A gpg: Setting TOFU policy for 2183839A to good gpg: TOFU: Set trust policy for binding <96DCD49DA38D389927687ECB3C5A915F2183839A, testing (insecure!)> to good. When a key's trust level is checked, the binding's policy is retrieved and translated to a trust level. There are three main scenarios: - If the policy is good, unknown or bad, then FULLY, UNKNOWN or NEVER is returned. - If the policy is auto, then we use the value of the --tofu-default-policy option as the policy. (In other words, the default policy is determined lazily.) This option can also either be good, unknown, bad, auto or ask. If it is also auto (the default), then the good policy is used, i.e., FULLY is returned. - If the binding's policy is ask, then we ask the user how to continue. If batch mode is enabled, then we act as if the unknown policy is in effect. --tofu-default-policy is a powerful knob. A common concern among security sensitive users is that TOFU is too weak, because it automatically trusts everyone. But, TOFU can detect man-in-the-middle attacks. Although a careful use of the WoT can also prevent such attacks, the WoT imposes a large overhead: secure communication is often not possible until a physical meeting has occured and the user must spend a lot of time not only collecting signatures, but also curating their trusted introducers (gpg --key-edit KEYID; trust). (Anecdotally, even those people who actively sign keys don't realize they have to do this.) By setting --tofu-default-policy to unknown, we only use the TOFU data for negative assertions (i.e., conflicts) and rely on the WoT for positive assertions. Thus, TOFU can help even the most paranoid without exposing them to additional risk. When the TOFU policy detects a conflict (a new binding has the same email address as some known binding), then we show a dialog to the user describing the problem as well as some statistics about messages verified with the keys. Here's an example: $ gpg2 --trust-model=tofu --verify BC15C85A-1.txt gpg: Signature made Fri 18 Sep 2015 02:06:17 PM CEST using RSA key ID BC15C85A gpg: TOFU: Set trust policy for binding <439D954F18F79CC4F71BED91CACED996BC15C85A, testing (insecure!)> to ask. gpg: DBG: TOFU: Saving signature <439D954F18F79CC4F71BED91CACED996BC15C85A, testing (insecure!), IupTST8BFF8+YL4ZTaQNyIZOXqcLbdwqNVaU2DubeNU> gpg: Good signature from "Testing (insecure!)" [unknown] Please indicate whether you believe the binding is legitimate (good) or a forgery (bad). Known user ids associated with this key: Testing (insecure!) (policy: ask) Statistics for keys with the email `testing (insecure!)': 439D954F18F79CC4F71BED91CACED996BC15C85A (this key): 1 message 13 days ago. 362D3527F53AAD1971AAFDE658859975EE37CF96, which was judged to be ask: 1 message 0 minutes ago. 14 messages 13 days ago. Normally, there is only a single key associated with an email address. However, people sometimes generate a new key if their key is too old or they think it might be compromised. Alternatively, a new key may indicate a man-in-the-middle attack! Before accepting this key, you should talk to or call the person to make sure this new key is legitimate. (G)ood/(A)ccept once/(U)nknown/(R)eject once/(B)ad? If gpg is in batch mode, then the dialog is not shown. Instead, the ask policy is associted with the binding and UNKNOWN is returned as the trust value. In addition to marking the current key as suspicious, the TOFU code also changes the policy of any conflicting bindings to 'ask' if their policy was 'auto'. In this way, the next time the user verifies a signature created by that key or encrypts to that key, they will be presented with the above dialog. This can be a bit confusing for a key that has been apparently good for a long time. It is probably a good idea to indicate why the key's policy was changed to ask. Currently, I don't do this. It is possible to retrieve the current policy by listing the key in --with-colons mode. Note: this is only shown when the trust model is TOFU or TOFU+PGP. The policy is shown in the 18th field. Since the binding is between the key and email address, this is only relevant for uid records. $ gpg2 --trust-model=tofu --list-keys --with-colons 2183839A gpg: TOFU: Known binding <96DCD49DA38D389927687ECB3C5A915F2183839A, testing (insecure!)>'s policy: good gpg: TOFU: Known binding <96DCD49DA38D389927687ECB3C5A915F2183839A, testing (insecure!)>'s policy: good tru:t:1:1442583132:1474113640:3:1:5 pub:f:1024:1:3C5A915F2183839A:1442583126:1474119126::u:::scESC::::::: uid:f::::1442583126::82414861BDCC320E1812DDD1DCAD506DFCDC1347::Testing (insecure!)::::::::good: -> **** sub:f:1024:1:6C63BFF012636FCF:1442583126:1474119126:::::e:::::: In summary, the following new options are available: # Change the trust model. --trust-model=tofu|tofu+pgp|togu+wot # Determine the policy for bindings whose policy is auto. --tofu-default-policy=good|unknown|bad|auto|ask # Set the policy for one or more keys --tofu-policy=good|unknown|bad|auto|ask KEYID [KEYID...] The TOFU DB is used when verifying (gpg --verify message.txt) and when encrypting (gpg -e -r EE37CF96). Note: the tofu data is stored in .gnupg/tofu.d. There is one DB per email address and one per fingerprint. This will hopefully make synchronizing TOFU data between multiple machines using something like unison possible. The main missing bit is the mechanism to normalize email addresses. Currently, I simply ASCII lower-case the local part. However, I want to use the locale independent case folding data [1] and specially handle gmail addresses (e.g., dots are simply ignored). If you are aware of existing code that would help me do either of these things, I'd appreciate it if you'd let me know. I'm also happy to hear additional suggestions. Now is the time since the interface can still be easily changed. Thanks! :) Neal [1] http://www.unicode.org/Public/UNIDATA/CaseFolding.txt From kevin at kevinlocke.name Fri Oct 2 00:35:36 2015 From: kevin at kevinlocke.name (Kevin Locke) Date: Thu, 1 Oct 2015 15:35:36 -0700 Subject: Optimization-dependent behavior with GnuPG 1.4.19 and GCC 5 In-Reply-To: <560CDE77.2090808@fsij.org> References: <20150930071652.GA22565@kevinolos> <560CC2CD.8050101@fsij.org> <20151001054127.GA12084@kevinolos> <560CDE77.2090808@fsij.org> Message-ID: <20151001223536.GA21687@kevinolos> On Thu, 2015-10-01 at 16:19 +0900, NIIBE Yutaka wrote: > On 10/01/2015 02:41 PM, Kevin Locke wrote: >> Any idea if sig->unhashed being NULL is easily avoidable when creating >> signed documents as a workaround for users with affected versions >> already in the wild? > > I don't think we have an easy way. > > Fortunately, GnuPG itself doesn't produce such a signature. Good to know, thanks! (Also thanks for mentioning pgpdump, it was new to me.) For my original issue (signed Debian package Release files for Google Cloud SDK) it may be possible to convince the signers to use GnuPG for signing the release files, so that may be a solution after all. Thanks again, Kevin From pde-lists at eff.org Thu Oct 1 23:45:32 2015 From: pde-lists at eff.org (Peter Eckersley) Date: Thu, 1 Oct 2015 14:45:32 -0700 Subject: Support for signature-from-message-digest Message-ID: Sometimes it is useful to be able to produce detached signatures on files given only the file's message digest as an input. We've been able to get this to work with openssl / smime signatures, but are wondering if there would be an easy way of getting gpg to accept a message digest as an input file, rather than trying to compute it from the input file? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Fri Oct 2 02:07:56 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 02 Oct 2015 09:07:56 +0900 Subject: Optimization-dependent behavior with GnuPG 1.4.19 and GCC 5 In-Reply-To: <20151001223536.GA21687@kevinolos> References: <20150930071652.GA22565@kevinolos> <560CC2CD.8050101@fsij.org> <20151001054127.GA12084@kevinolos> <560CDE77.2090808@fsij.org> <20151001223536.GA21687@kevinolos> Message-ID: <560DCADC.3030105@fsij.org> On 10/02/2015 07:35 AM, Kevin Locke wrote: > Good to know, thanks! (Also thanks for mentioning pgpdump, it was new > to me.) For my original issue (signed Debian package Release files > for Google Cloud SDK) it may be possible to convince the signers to > use GnuPG for signing the release files, so that may be a solution > after all. That's a possible work around. For Debian, Jessie and older still use GCC 4, thus, all we need to care is building gnupg 1.4 in sid/testing. Since I found Ubuntu uses GCC 5, I submitted a report: https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1501634 It seems that Fedora is also uses GCC 5, but I can't find how to submit these kinds of bug report to them. No action taken from me to Fedora. The direct impact would be not that huge for them (than Debian and Ubuntu), though. -- From kevin at kevinlocke.name Fri Oct 2 02:19:24 2015 From: kevin at kevinlocke.name (Kevin Locke) Date: Thu, 1 Oct 2015 17:19:24 -0700 Subject: Optimization-dependent behavior with GnuPG 1.4.19 and GCC 5 In-Reply-To: <560DCADC.3030105@fsij.org> References: <20150930071652.GA22565@kevinolos> <560CC2CD.8050101@fsij.org> <20151001054127.GA12084@kevinolos> <560CDE77.2090808@fsij.org> <20151001223536.GA21687@kevinolos> <560DCADC.3030105@fsij.org> Message-ID: <20151002001924.GA4085@kevinolos> On Fri, 2015-10-02 at 09:07 +0900, NIIBE Yutaka wrote: > On 10/02/2015 07:35 AM, Kevin Locke wrote: >> Good to know, thanks! (Also thanks for mentioning pgpdump, it was new >> to me.) For my original issue (signed Debian package Release files >> for Google Cloud SDK) it may be possible to convince the signers to >> use GnuPG for signing the release files, so that may be a solution >> after all. > > That's a possible work around. > > For Debian, Jessie and older still use GCC 4, thus, all we need to > care is building gnupg 1.4 in sid/testing. > > Since I found Ubuntu uses GCC 5, I submitted a report: > > https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1501634 That's great! Did you submit a bug to Debian, or do you know if there are plans to include the patch in testing? I hadn't thought that GCC 5 was being used by default yet, but I'm definitely seeing the issue in the packages currently in testing and the most recent build logs[1] show gcc-5_5.2.1-15. Thank you again for all of your extra effort on this, Kevin 1. https://buildd.debian.org/status/fetch.php?pkg=gnupg&arch=amd64&ver=1.4.19-5&stamp=1439904061 From gniibe at fsij.org Fri Oct 2 03:00:56 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 02 Oct 2015 10:00:56 +0900 Subject: ssh: Fix allocation of pinentry buffer In-Reply-To: <877fn6bzjd.fsf@vigenere.g10code.de> References: <5609004B.2070706@fsij.org> <8737xyhlmp.fsf@vigenere.g10code.de> <5609F2A0.1050301@fsij.org> <87si5w9ttb.wl-neal@walfield.org> <560CB62B.6030303@fsij.org> <877fn6bzjd.fsf@vigenere.g10code.de> Message-ID: <560DD748.80302@fsij.org> On 10/01/2015 08:26 PM, Werner Koch wrote: > What about this basic fix? If there are other problem they can be > applied on top of this. No objection. I'll apply other fixes on top of this, in the next week. Also, I'll backport this to 2.0. Neal, I understand your point of: commits that encapsulate a single change. For adding new feature, I completely agree. My concern was that we have other cases, too: for some fixes, we need to backport the fixes to 2.0, and those should be applied to the version of each distribution. Well, security team in a distribution is so picky (that is good thing), and smaller distinct fixes are better to be evaluated by them independently. * * * >> fixed size allocation and fixed size communication > > The pin_entry_info_s is allocated in secure memory thus when piossible > it should be limited in size. Noted. I keep the code which limits the size. The reason why I consider fixed size communication would be better is that we have fixed size communication between gpg-agent to scdaemon. Currently, the communication between gpg-agent to scdaemon for pin input is done in fixed size (null-padded). No, it is not me :-) who decided it. The code is in: agent/divert-scd.c:getpin_cb agent/call-scd.c:inq_needpin If the intention of this fixed size communication is to mitigate some side channel attacks, I think that we should keep this code. -- From gniibe at fsij.org Fri Oct 2 03:47:45 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 02 Oct 2015 10:47:45 +0900 Subject: Optimization-dependent behavior with GnuPG 1.4.19 and GCC 5 In-Reply-To: <20151002001924.GA4085@kevinolos> References: <20150930071652.GA22565@kevinolos> <560CC2CD.8050101@fsij.org> <20151001054127.GA12084@kevinolos> <560CDE77.2090808@fsij.org> <20151001223536.GA21687@kevinolos> <560DCADC.3030105@fsij.org> <20151002001924.GA4085@kevinolos> Message-ID: <560DE241.1090003@fsij.org> On 10/02/2015 09:19 AM, Kevin Locke wrote: > Did you submit a bug to Debian, or do you know if there are plans to > include the patch in testing? I hadn't thought that GCC 5 was being > used by default yet, but I'm definitely seeing the issue in the > packages currently in testing and the most recent build logs[1] show > gcc-5_5.2.1-15. I didn't know it's in testing already. I apt-get'ed and confirm that the bug is there. Thank you. I just submitted bug report: https://bugs.debian.org/800641 I'll make sure this will be included in the next upload of gnupg package. -- From wk at gnupg.org Fri Oct 2 08:29:02 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Oct 2015 08:29:02 +0200 Subject: Support for signature-from-message-digest In-Reply-To: (Peter Eckersley's message of "Thu, 1 Oct 2015 14:45:32 -0700") References: Message-ID: <87wpv5aimp.fsf@vigenere.g10code.de> On Thu, 1 Oct 2015 23:45, pde-lists at eff.org said: > Sometimes it is useful to be able to produce detached signatures on files > given only the file's message digest as an input. We've been able to get > this to work with openssl / smime signatures, but are wondering if there > would be an easy way of getting gpg to accept a message digest as an input > file, rather than trying to compute it from the input file? We got this request several times in the last decade. However, it is not easy to do because OpenPGP hashes some extra bytes and thus you would need to take a snapshot of the message digest before it has been finalized. This is not easy because it requires marshaling to be platform independent. The good news is that you do not need it anymore because since 2.1 you can use ssh to run gpg on the remote machine while keeping the private key and the signing operation on your local box. (See gpg-agent's --extra-socket option) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Oct 2 11:06:04 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Oct 2015 11:06:04 +0200 Subject: Release branch for 2.2 created Message-ID: <87mvw1abcz.fsf@vigenere.g10code.de> Hi! I created a new branch STABLE-BRANCH-2-2 for GnUPG. For now this is only used to prepare the 2.1 releases. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Oct 2 12:12:13 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Oct 2015 12:12:13 +0200 Subject: TOFU code available In-Reply-To: <87oagi9tm1.wl-neal@walfield.org> (Neal H. Walfield's message of "Thu, 01 Oct 2015 23:17:10 +0200") References: <87oagi9tm1.wl-neal@walfield.org> Message-ID: <87fv1ta8aq.fsf@vigenere.g10code.de> On Thu, 1 Oct 2015 23:17, neal at walfield.org said: > I now have an almost complete version of the TOFU code available for > testing. I've pushed it to the neal/next branch. I'd appreciate if > people would try it. Nice. > The main missing bit is the mechanism to normalize email addresses. > Currently, I simply ASCII lower-case the local part. However, I want > to use the locale independent case folding data [1] and specially I don't think that this is a good idea. There are no fixed rules and the scheme is quite complicated. We have seen to many problem with that in the past and they won't go away. Further, it is only common use to not distinguish case in mail addresses. The RFCs tell us that only "Postmaster" mus be recognized case-insensitive. But agreed, most users don't know about this and thus almost all MTA ignore the case of the local part. It is good to lowercase ASCII characters because that is well defined iff "C" is assumed as locale. If people want to use non-ascii mail addresses we better don't try to be too smart and take them verbatim. > handle gmail addresses (e.g., dots are simply ignored). If you are > aware of existing code that would help me do either of these things, At our meeting on Wednesday we discussed this and my point was that if we do this, we should do it in the same way Google handles addresses in their forthcoming OpenPGP service. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Oct 2 12:17:44 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Oct 2015 12:17:44 +0200 Subject: keydb.[ch], internal docs In-Reply-To: <871tdy199v.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 16 Sep 2015 20:58:20 +0200") References: <87oah21jb2.fsf@vigenere.g10code.de> <871tdy199v.wl-neal@walfield.org> Message-ID: <87bncha81j.fsf@vigenere.g10code.de> On Wed, 16 Sep 2015 20:58, neal at walfield.org said: >> Not beeing a C++ ahcker, I am used to look directly at the code and not >> to switch back and forth between .c and .h. Thus I would prefer to have [..] > I didn't realize that this is a C++ thing. I picked it up from glibc. Because most C++ code does not hide private data but declares the class entirely in a header along with inline code. So we see lots of comments there. We discussed this on the phone and our conclusion is that we keep the comments in the C file but put brief usage instructions to the prototypes in the header. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Oct 2 12:34:01 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Oct 2015 12:34:01 +0200 Subject: ssh: Fix allocation of pinentry buffer In-Reply-To: <560DD748.80302@fsij.org> (NIIBE Yutaka's message of "Fri, 02 Oct 2015 10:00:56 +0900") References: <5609004B.2070706@fsij.org> <8737xyhlmp.fsf@vigenere.g10code.de> <5609F2A0.1050301@fsij.org> <87si5w9ttb.wl-neal@walfield.org> <560CB62B.6030303@fsij.org> <877fn6bzjd.fsf@vigenere.g10code.de> <560DD748.80302@fsij.org> Message-ID: <877fn5a7ae.fsf@vigenere.g10code.de> On Fri, 2 Oct 2015 03:00, gniibe at fsij.org said: > No objection. I'll apply other fixes on top of this, in the next > week. Also, I'll backport this to 2.0. Okay, I pushed my fix. > My concern was that we have other cases, too: for some fixes, we need > to backport the fixes to 2.0, and those should be applied to the > version of each distribution. Well, security team in a distribution > is so picky (that is good thing), and smaller distinct fixes are Good point. > agent/divert-scd.c:getpin_cb > agent/call-scd.c:inq_needpin Yes, the max length is set to 90 which is pretty large for any PIN. If that is a problem we could add an option to the NEEDPIN inquiry to tell the maximum expected size of the PIN. > If the intention of this fixed size communication is to mitigate some > side channel attacks, I think that we should keep this code. No, I dont think that is an issue. The IPC between gpg-agent and scdaemon is considered to be safe. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bjk at luxsci.net Sat Oct 3 18:48:47 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Sat, 3 Oct 2015 12:48:47 -0400 Subject: Pinentry and passphrase file button Message-ID: <1443890942-7227570.1513671.ft93GmmTF031264@rs146.luxsci.com> Does anyone object to adding a button to the pinentry dialogs to fill the passphrase text field with the contents of a file? The passphrase file may contain control characters so maybe adding a checkbox to toggle the text field, a new filename text field and file button would be better. Also, since the passphrase file may contain control characters (nil included), many functions in gpg-agent would need to be passed the length of the passphrase rather than potentially truncating it. Or maybe only issue a warning in pinentry if the passphrase would be truncated? -- Ben Kibbey From neal at walfield.org Sat Oct 3 20:13:07 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 03 Oct 2015 20:13:07 +0200 Subject: Pinentry and passphrase file button In-Reply-To: <1443890942-7227570.1513671.ft93GmmTF031264@rs146.luxsci.com> References: <1443890942-7227570.1513671.ft93GmmTF031264@rs146.luxsci.com> Message-ID: <87k2r3aki4.wl-neal@walfield.org> Hi, At Sat, 3 Oct 2015 12:48:47 -0400, Ben Kibbey wrote: > > Does anyone object to adding a button to the pinentry dialogs to fill > the passphrase text field with the contents of a file? The passphrase > file may contain control characters so maybe adding a checkbox to toggle > the text field, a new filename text field and file button would be > better. > > Also, since the passphrase file may contain control characters (nil > included), many functions in gpg-agent would need to be passed the > length of the passphrase rather than potentially truncating it. Or maybe > only issue a warning in pinentry if the passphrase would be truncated? Before we add additional complexity, can you please explain why such strange passphrases are needed? Here's my thoughts on the issue: The passphrase protects the key in case your hard disk is stolen. If the passphrase is in a file, what's the point of having a passphrase at all? The use of a file just adds a tiny bit of obscurity, which is little security at all. Neal From rjh at sixdemonbag.org Sat Oct 3 19:24:24 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 3 Oct 2015 13:24:24 -0400 Subject: Pinentry and passphrase file button In-Reply-To: <1443890942-7227570.1513671.ft93GmmTF031264@rs146.luxsci.com> References: <1443890942-7227570.1513671.ft93GmmTF031264@rs146.luxsci.com> Message-ID: <56100F48.2030904@sixdemonbag.org> > Does anyone object to adding a button to the pinentry dialogs to fill > the passphrase text field with the contents of a file? I've never understood the motivation for this use case, so I weigh in on "don't change it". From bjk at luxsci.net Sat Oct 3 22:44:58 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Sat, 3 Oct 2015 16:44:58 -0400 Subject: Pinentry and passphrase file button In-Reply-To: <87k2r3aki4.wl-neal@walfield.org> References: <1443890942-7227570.1513671.ft93GmmTF031264@rs146.luxsci.com> <87k2r3aki4.wl-neal@walfield.org> Message-ID: <1443905102-5220447.86472815.ft93KiwkC018359@rs146.luxsci.com> On Sat, Oct 03, 2015 at 08:13:07PM +0200, Neal H. Walfield wrote: > Before we add additional complexity, can you please explain why such > strange passphrases are needed? > > Here's my thoughts on the issue: The passphrase protects the key in > case your hard disk is stolen. If the passphrase is in a file, what's > the point of having a passphrase at all? The use of a file just adds > a tiny bit of obscurity, which is little security at all. The file could be stored on removable media. -- Ben Kibbey From rjh at sixdemonbag.org Sun Oct 4 00:57:48 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 3 Oct 2015 18:57:48 -0400 Subject: Pinentry and passphrase file button In-Reply-To: <1443905102-5220447.86472815.ft93KiwkC018359@rs146.luxsci.com> References: <1443890942-7227570.1513671.ft93GmmTF031264@rs146.luxsci.com> <87k2r3aki4.wl-neal@walfield.org> <1443905102-5220447.86472815.ft93KiwkC018359@rs146.luxsci.com> Message-ID: <56105D6C.601@sixdemonbag.org> > The file could be stored on removable media. Show a use case, please. Where would it make sense for a user to store a passphrase on CD-R and choose to load in the passphrase from CD? Why not use a smartcard in this use case? From bjk at luxsci.net Sun Oct 4 02:45:53 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Sat, 3 Oct 2015 20:45:53 -0400 Subject: Pinentry and passphrase file button In-Reply-To: <56105D6C.601@sixdemonbag.org> References: <1443890942-7227570.1513671.ft93GmmTF031264@rs146.luxsci.com> <87k2r3aki4.wl-neal@walfield.org> <1443905102-5220447.86472815.ft93KiwkC018359@rs146.luxsci.com> <56105D6C.601@sixdemonbag.org> Message-ID: <1443919562-9974288.16224481.ft940jsCx027302@rs146.luxsci.com> On Sat, Oct 03, 2015 at 06:57:48PM -0400, Robert J. Hansen wrote: > > The file could be stored on removable media. > > Show a use case, please. Where would it make sense for a user to store > a passphrase on CD-R and choose to load in the passphrase from CD? Why > not use a smartcard in this use case? I agree that a smartcard is more secure, but not all smartcards are as portable or widely used as a thumb drive, for example. -- Ben Kibbey From rjh at sixdemonbag.org Sun Oct 4 03:25:53 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 3 Oct 2015 21:25:53 -0400 Subject: Pinentry and passphrase file button In-Reply-To: <1443919562-9974288.16224481.ft940jsCx027302@rs146.luxsci.com> References: <1443890942-7227570.1513671.ft93GmmTF031264@rs146.luxsci.com> <87k2r3aki4.wl-neal@walfield.org> <1443905102-5220447.86472815.ft93KiwkC018359@rs146.luxsci.com> <56105D6C.601@sixdemonbag.org> <1443919562-9974288.16224481.ft940jsCx027302@rs146.luxsci.com> Message-ID: <56108021.8010904@sixdemonbag.org> > I agree that a smartcard is more secure, but not all smartcards are as > portable or widely used as a thumb drive, for example. That's meaningless. Sure, large smartcards exist. Most of them, though, are *smaller* than a thumb drive -- look at how large the knockout panel on a Kernel Concepts card is. The existence of large smartcards is not an argument to use wildly unsafe USB storage media for passphrases. Again, show me the use case. Show me an instance in which, say, a Gemalto Shelltoken card reader with a SIM breakout OpenPGP card is an insufficient alternative to a thumb drive. A Gemalto card reader is 18 euros; an OpenPGP 2.1 smartcard with SIM breakout is 17 euros. 35 euros is a pretty reasonable investment. http://shop.kernelconcepts.de/ From neal at walfield.org Mon Oct 5 21:12:36 2015 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 05 Oct 2015 21:12:36 +0200 Subject: TOFU code available In-Reply-To: <87fv1ta8aq.fsf@vigenere.g10code.de> References: <87oagi9tm1.wl-neal@walfield.org> <87fv1ta8aq.fsf@vigenere.g10code.de> Message-ID: <87egh99ljv.wl-neal@walfield.org> At Fri, 02 Oct 2015 12:12:13 +0200, Werner Koch wrote: > On Thu, 1 Oct 2015 23:17, neal at walfield.org said: > > The main missing bit is the mechanism to normalize email addresses. > > Currently, I simply ASCII lower-case the local part. However, I want > > to use the locale independent case folding data [1] and specially > > I don't think that this is a good idea. There are no fixed rules and > the scheme is quite complicated. We have seen to many problem with that > in the past and they won't go away. Further, it is only common use to > not distinguish case in mail addresses. The RFCs tell us that only > "Postmaster" mus be recognized case-insensitive. But agreed, most users > don't know about this and thus almost all MTA ignore the case of the > local part. > > It is good to lowercase ASCII characters because that is well defined > iff "C" is assumed as locale. > > If people want to use non-ascii mail addresses we better don't try to be > too smart and take them verbatim. TOFU can do two things: - Identify previously unseen keys, and - Detect key changes. We don't implement the first thing by default (although it can be enabled by setting --tofu-default-policy=ask). This policy decision is based on the observation that if we have too many user interactions, the user will simply dismiss all questions without actually understanding them thereby undermining any security improvements that TOFU brings. The second thing detects man-in-the-middle attacks. It requires binding keys to identifiers and detecting when that identifier is associated with another key. I argued in a previous mail that the right identifier is an email address and there seems to be rough consensus that this is the best approach. If we are conservative in what we consider to be equivalent email addresses, then we make it easy for an attacker to circumvent this protection. If we are liberal, we run the risk of incorrectly flagging conflicts when there are none (i.e., introducing false positives). I suspect that in practice false positives will be extremely rare. Permitting false negatives, however, can have dire consequences (and if you don't consider them dire then you probably don't care about TOFU). Therefore, I strongly argue that we should aggressively normalize email addresses before comparing them. Consider the attack that we are trying to protect against: Eve wants to send an email to Alice that appears to come from ?tienne. Eve assumes that Alice and ?tienne are in regular contact and that ?tienne's key is: <0xdeadbeef, ?tienne at example.org>. Eve also knows that Alice uses GnuPG with its TOFU trust model and that GnuPG's --auto-key-locate functionality is enabled. To mount the attack, Eve needs to create a key that will be acceptable to TOFU without raising a conflict. If we choose a conservative comparison function, this is trivial. Eve creates a new key <0xbaddecaf, ?tienne at example.org> and signs a message that she sends to Alice using this key. Although Alice has never seen this key, she doesn't realize it: GnuPG silently fetches the key for her. Further, because Alice is using TOFU in its default configuration, the binding is considered to be new and hence fully trusted. Now, it's up to Alice. This is what she sees: gpg: Signature made Mon 05 Oct 2015 08:53:36 PM CEST gpg: using RSA key 0xbaddecaf gpg: Good signature from "?tienne " [full] For Alice to win, she needs to recognize that either the key id or the email address has changed. Most people won't recognize changes to the key id. And, given how optically similar the email addresses are, Alice is unlikely to recognize the difference there as well. As such, Eve almost certainly wins. For Eve to lose, we must force her to choose an email address that Alice detects as being wrong. For instance, if we force Eve to choose foo at example.org, then Alice has a good chance of noticing the suspicious email address. Such an extreme choice is not possible, but we can make Eve's life more difficult by lower-casing all letters, removing accents, removing punctuation, etc. before comparison. > > handle gmail addresses (e.g., dots are simply ignored). If you are > > aware of existing code that would help me do either of these things, > > At our meeting on Wednesday we discussed this and my point was that if > we do this, we should do it in the same way Google handles addresses > in their forthcoming OpenPGP service. Note: the point is not to come up with the canonical email address, but to compare two email addresses and indicate whether they are similar enough that a warning is justified. Thoughts? Neal From bjk at luxsci.net Tue Oct 6 02:47:32 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Mon, 5 Oct 2015 20:47:32 -0400 Subject: SSH and smartcard regression Message-ID: <1444092482-7518916.45009982.ft960lXqI021696@rs146.luxsci.com> Hello, Since commit cfbe6ba9cf I've been having trouble using the ssh-agent part of gpg-agent with a smartcard. Reverting the commit fixes things. I havent tried any other algorithms. Heres my authentication key: ssb rsa4096/5258F30F created: 2015-10-03 expires: 2017-10-02 usage: A card-no: 0005 00000B13 And heres the gpg-agent log: ssh request handler for request_identities (11) ready ssh request handler for sign_request (13) started DBG: detected card with S/N D276000124010200000500000B130000 starting a new PIN Entry checking created signature failed: Invalid object ssh sign request failed: Invalid object Please let me know if you need more info. Thanks, -- Ben Kibbey From gniibe at fsij.org Tue Oct 6 08:18:44 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 06 Oct 2015 15:18:44 +0900 Subject: SSH and smartcard regression In-Reply-To: <1444092482-7518916.45009982.ft960lXqI021696@rs146.luxsci.com> References: <1444092482-7518916.45009982.ft960lXqI021696@rs146.luxsci.com> Message-ID: <561367C4.3030000@fsij.org> On 10/06/2015 09:47 AM, Ben Kibbey wrote: > Since commit cfbe6ba9cf I've been having trouble using the ssh-agent > part of gpg-agent with a smartcard. Reverting the commit fixes things. [...] > And heres the gpg-agent log: > > ssh request handler for request_identities (11) ready > ssh request handler for sign_request (13) started > DBG: detected card with S/N D276000124010200000500000B130000 > starting a new PIN Entry > checking created signature failed: Invalid object > ssh sign request failed: Invalid object Thanks a lot for your report. That's my badness. I wrongly thought as if gcry_pk_verify accepted shadowed private key (used for smartcard). Here is a fix. It is pushed by RSA authentication with smartcard (Gnuk Token). commit 4a5bd1720f5a3dbb26f5daeb03725cae29be7e24 Author: NIIBE Yutaka Date: Tue Oct 6 15:10:25 2015 +0900 agent: Fix verification of signature for smartcard. * agent/pksign.c (agent_pksign_do): Use public key smartcard. -- Since gcry_pk_verify can't handle shadowed private key, public key SEXP should be prepared for smartcard. diff --git a/agent/pksign.c b/agent/pksign.c index 243c49d..e079c3f 100644 --- a/agent/pksign.c +++ b/agent/pksign.c @@ -291,6 +291,7 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, { gcry_sexp_t s_skey = NULL, s_sig = NULL; gcry_sexp_t s_hash = NULL; + gcry_sexp_t s_pkey = NULL; unsigned char *shadow_info = NULL; unsigned int rc = 0; /* FIXME: gpg-error? */ const unsigned char *data; @@ -331,6 +332,13 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, int is_ECDSA = 0; int is_EdDSA = 0; + rc = agent_public_key_from_file (ctrl, ctrl->keygrip, &s_pkey); + if (rc) + { + log_error ("failed to read the public key\n"); + goto leave; + } + if (agent_is_eddsa_key (s_skey)) is_EdDSA = 1; else @@ -497,7 +505,7 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, ctrl->digest.raw_value); } - rc = gcry_pk_verify (s_sig, s_hash, s_skey); + rc = gcry_pk_verify (s_sig, s_hash, s_pkey? s_pkey: s_skey); if (rc) { @@ -512,6 +520,7 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, *signature_sexp = s_sig; + gcry_sexp_release (s_pkey); gcry_sexp_release (s_skey); gcry_sexp_release (s_hash); xfree (shadow_info); -- From gniibe at fsij.org Tue Oct 6 20:29:03 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 07 Oct 2015 03:29:03 +0900 Subject: gen-key with wrong passphrase Message-ID: <561412EF.5040907@fsij.org> Hello, I found that the commit efde50f92a introduced a regression for wrong passphrase input (different passphrase for second time). When it's different, it failed with following error. gpg: agent_genkey failed: Unknown system error Key generation failed: Unknown system error Expected behavior is to repeat asking passphrase. In genkey.c, the function reenter_compare_cb can return -1. The value -1 is incompatible by the change of the commit efde50f92a. I'm not sure how we fix this. Shall we change the callback pininfo->check_cb return type from int to gpg_error_t? commit efde50f92af241d8357db83e280a6ece62f6397f Author: Werner Koch Date: Wed Mar 11 16:28:32 2015 +0100 agent: Improve error reporting from Pinentry. * agent/call-pinentry.c (unlock_pinentry): Add error logging. Map error source of uncommon errors to Pinentry. -- With this change it is possible to detect whether an error like GPG_ERR_ASS_INV_RESPONSE has its origin in a call to Pinentry or comes from another part of gpg-agent. Signed-off-by: Werner Koch diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index a96406f..ef1bfa4 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -133,6 +133,34 @@ unlock_pinentry (int rc) assuan_context_t ctx = entry_ctx; int err; + if (rc) + { + if (DBG_ASSUAN) + log_debug ("error calling pinentry: %s <%s>\n", + gpg_strerror (rc), gpg_strsource (rc)); + + /* Change the source of the error to pinentry so that the final + consumer of the error code knows that the problem is with + pinentry. For backward compatibility we do not do that for + some common error codes. */ + switch (gpg_err_code (rc)) + { + case GPG_ERR_NO_PIN_ENTRY: + case GPG_ERR_CANCELED: + case GPG_ERR_FULLY_CANCELED: + case GPG_ERR_ASS_UNKNOWN_INQUIRE: + case GPG_ERR_ASS_TOO_MUCH_DATA: + case GPG_ERR_NO_PASSPHRASE: + case GPG_ERR_BAD_PASSPHRASE: + case GPG_ERR_BAD_PIN: + break; + + default: + rc = gpg_err_make (GPG_ERR_SOURCE_PINENTRY, gpg_err_code (rc)); + break; + } + } + entry_ctx = NULL; err = npth_mutex_unlock (&entry_lock); if (err) -- From wk at gnupg.org Tue Oct 6 20:53:26 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Oct 2015 20:53:26 +0200 Subject: gen-key with wrong passphrase In-Reply-To: <561412EF.5040907@fsij.org> (NIIBE Yutaka's message of "Wed, 07 Oct 2015 03:29:03 +0900") References: <561412EF.5040907@fsij.org> Message-ID: <87lhbf3k2h.fsf@vigenere.g10code.de> On Tue, 6 Oct 2015 20:29, gniibe at fsij.org said: > In genkey.c, the function reenter_compare_cb can return -1. > The value -1 is incompatible by the change of the commit efde50f92a. Right. I used -1 to make the functions similar to strcmp - but that is not really required. > I'm not sure how we fix this. Shall we change the callback > pininfo->check_cb return type from int to gpg_error_t? That is a good idea. I am not sure what error to return. The new GPG_ERR_FALSE seems to be best but we may need to also change the callers to return a more descriptive error message. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Oct 7 09:34:50 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 07 Oct 2015 16:34:50 +0900 Subject: gen-key with wrong passphrase In-Reply-To: <87lhbf3k2h.fsf@vigenere.g10code.de> References: <561412EF.5040907@fsij.org> <87lhbf3k2h.fsf@vigenere.g10code.de> Message-ID: <5614CB1A.20804@fsij.org> On 10/07/2015 03:53 AM, Werner Koch wrote: > Right. I used -1 to make the functions similar to strcmp - but that is > not really required. > >> I'm not sure how we fix this. Shall we change the callback >> pininfo->check_cb return type from int to gpg_error_t? > > That is a good idea. I am not sure what error to return. The new > GPG_ERR_FALSE seems to be best but we may need to also change the > callers to return a more descriptive error message. I had thought that it were big change, but it is not, actually. I'm afraid GPG_ERR_FALSE is too new. For the pininfo->check_cb case, I think that we can simply use GPG_ERR_BAD_PASSPHRASE, because the semantics is clear and this is independent usage. Here is a fix. Built successfully, confirmed that the regression is fixed. OK to push? diff --git a/agent/agent.h b/agent/agent.h index b3e8470..6e24df4 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -257,7 +257,8 @@ struct pin_entry_info_s int with_qualitybar; /* Set if the quality bar should be displayed. */ int with_repeat; /* Request repetition of the passphrase. */ int repeat_okay; /* Repetition worked. */ - int (*check_cb)(struct pin_entry_info_s *); /* CB used to check the PIN */ + gpg_error_t (*check_cb)(struct pin_entry_info_s *); /* CB used to check + the PIN */ void *check_cb_arg; /* optional argument which might be of use in the CB */ const char *cb_errtext; /* used by the cb to display a specific error */ size_t max_length; /* Allocated length of the buffer PIN. */ @@ -402,11 +403,11 @@ void initialize_module_call_pinentry (void); void agent_query_dump_state (void); void agent_reset_query (ctrl_t ctrl); int pinentry_active_p (ctrl_t ctrl, int waitseconds); -int agent_askpin (ctrl_t ctrl, - const char *desc_text, const char *prompt_text, - const char *inital_errtext, - struct pin_entry_info_s *pininfo, - const char *keyinfo, cache_mode_t cache_mode); +gpg_error_t agent_askpin (ctrl_t ctrl, + const char *desc_text, const char *prompt_text, + const char *inital_errtext, + struct pin_entry_info_s *pininfo, + const char *keyinfo, cache_mode_t cache_mode); int agent_get_passphrase (ctrl_t ctrl, char **retpass, const char *desc, const char *prompt, const char *errtext, int with_qualitybar, diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index 0140387..8b22aea 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -127,8 +127,8 @@ agent_reset_query (ctrl_t ctrl) disconnect that pinentry - we do this after the unlock so that a stalled pinentry does not block other threads. Fixme: We should have a timeout in Assuan for the disconnect operation. */ -static int -unlock_pinentry (int rc) +static gpg_error_t +unlock_pinentry (gpg_error_t rc) { assuan_context_t ctx = entry_ctx; int err; @@ -229,7 +229,7 @@ getinfo_pid_cb (void *opaque, const void *buffer, size_t length) that this function must always be used to aquire the lock for the pinentry - we will serialize _all_ pinentry calls. */ -static int +static gpg_error_t start_pinentry (ctrl_t ctrl) { int rc = 0; @@ -709,7 +709,7 @@ inq_quality (void *opaque, const char *line) /* Helper for agent_askpin and agent_get_passphrase. */ -static int +static gpg_error_t setup_qualitybar (ctrl_t ctrl) { int rc; @@ -801,14 +801,14 @@ pinentry_status_cb (void *opaque, const char *line) number here and repeat it as long as we have invalid formed numbers. KEYINFO and CACHE_MODE are used to tell pinentry something about the key. */ -int +gpg_error_t agent_askpin (ctrl_t ctrl, const char *desc_text, const char *prompt_text, const char *initial_errtext, struct pin_entry_info_s *pininfo, const char *keyinfo, cache_mode_t cache_mode) { - int rc; + gpg_error_t rc; char line[ASSUAN_LINELENGTH]; struct entry_parm_s parm; const char *errtext = NULL; @@ -829,10 +829,10 @@ agent_askpin (ctrl_t ctrl, size_t size; *pininfo->pin = 0; /* Reset the PIN. */ - rc = pinentry_loopback(ctrl, "PASSPHRASE", &passphrase, &size, - pininfo->max_length); - if (rc) - return rc; + rc = pinentry_loopback (ctrl, "PASSPHRASE", &passphrase, &size, + pininfo->max_length); + if (rc) + return rc; memcpy(&pininfo->pin, passphrase, size); xfree(passphrase); @@ -1006,7 +1006,7 @@ agent_askpin (ctrl_t ctrl, /* More checks by utilizing the optional callback. */ pininfo->cb_errtext = NULL; rc = pininfo->check_cb (pininfo); - if (rc == -1 && pininfo->cb_errtext) + if (gpg_err_code (rc) == GPG_ERR_BAD_PASSPHRASE && pininfo->cb_errtext) errtext = pininfo->cb_errtext; else if (gpg_err_code (rc) == GPG_ERR_BAD_PASSPHRASE || gpg_err_code (rc) == GPG_ERR_BAD_PIN) diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 0aa0098..6144ae1 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -3040,14 +3040,14 @@ ssh_key_to_protected_buffer (gcry_sexp_t key, const char *passphrase, /* Callback function to compare the first entered PIN with the one currently being entered. */ -static int +static gpg_error_t reenter_compare_cb (struct pin_entry_info_s *pi) { const char *pin1 = pi->check_cb_arg; if (!strcmp (pin1, pi->pin)) return 0; /* okay */ - return -1; + return gpg_error (GPG_ERR_BAD_PASSPHRASE); } @@ -3133,7 +3133,7 @@ ssh_identity_register (ctrl_t ctrl, ssh_key_type_spec_t *spec, if (*pi->pin && !pi->repeat_okay) { err = agent_askpin (ctrl, description2, NULL, NULL, pi2, NULL, 0); - if (err == -1) + if (gpg_err_code (err) == GPG_ERR_BAD_PASSPHRASE) { /* The re-entered one did not match and the user did not hit cancel. */ initial_errtext = L_("does not match - try again"); diff --git a/agent/cvt-openpgp.c b/agent/cvt-openpgp.c index fb5a473..0b9ecf0 100644 --- a/agent/cvt-openpgp.c +++ b/agent/cvt-openpgp.c @@ -657,7 +657,7 @@ do_unprotect (const char *passphrase, /* Callback function to try the unprotection from the passphrase query code. */ -static int +static gpg_error_t try_do_unprotect_cb (struct pin_entry_info_s *pi) { gpg_error_t err; diff --git a/agent/findkey.c b/agent/findkey.c index c49c37a..af61e7e 100644 --- a/agent/findkey.c +++ b/agent/findkey.c @@ -111,7 +111,7 @@ agent_write_private_key (const unsigned char *grip, /* Callback function to try the unprotection from the passphrase query code. */ -static int +static gpg_error_t try_unprotect_cb (struct pin_entry_info_s *pi) { struct try_unprotect_arg_s *arg = pi->check_cb_arg; diff --git a/agent/genkey.c b/agent/genkey.c index e8195c2..b780c50 100644 --- a/agent/genkey.c +++ b/agent/genkey.c @@ -326,14 +326,14 @@ check_passphrase_constraints (ctrl_t ctrl, const char *pw, /* Callback function to compare the first entered PIN with the one currently being entered. */ -static int +static gpg_error_t reenter_compare_cb (struct pin_entry_info_s *pi) { const char *pin1 = pi->check_cb_arg; if (!strcmp (pin1, pi->pin)) return 0; /* okay */ - return -1; + return gpg_error (GPG_ERR_BAD_PASSPHRASE); } @@ -410,7 +410,7 @@ agent_ask_new_passphrase (ctrl_t ctrl, const char *prompt, if (*pi->pin && !pi->repeat_okay) { err = agent_askpin (ctrl, text2, NULL, NULL, pi2, NULL, 0); - if (err == -1) + if (gpg_err_code (err) == GPG_ERR_BAD_PASSPHRASE) { /* The re-entered one did not match and the user did not hit cancel. */ initial_errtext = xtrystrdup (L_("does not match - try again")); -- From wk at gnupg.org Wed Oct 7 21:06:20 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Oct 2015 21:06:20 +0200 Subject: gen-key with wrong passphrase In-Reply-To: <5614CB1A.20804@fsij.org> (NIIBE Yutaka's message of "Wed, 07 Oct 2015 16:34:50 +0900") References: <561412EF.5040907@fsij.org> <87lhbf3k2h.fsf@vigenere.g10code.de> <5614CB1A.20804@fsij.org> Message-ID: <8737xm33df.fsf@vigenere.g10code.de> On Wed, 7 Oct 2015 09:34, gniibe at fsij.org said: > Here is a fix. Built successfully, confirmed that the regression > is fixed. > > OK to push? Sure. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bjk at luxsci.net Sat Oct 10 00:19:58 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Fri, 9 Oct 2015 18:19:58 -0400 Subject: No subject Message-ID: <1444429202-4773890.17667507.ft99MJwrC006584@rs146.luxsci.com> Hello, The recent commit to gnupg (commit 625e292) breaks decrypting symmetrically signed data when using gpgme. Adding "force-mdc" to gpg.conf before signing fixes things. Maybe adding --ignore-mdc-errors should be added to the command line as well so previously signed data can be used, too? Or maybe I'm doing something wrong? Thanks, -- Ben Kibbey From bjk at luxsci.net Sat Oct 10 01:25:02 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Fri, 9 Oct 2015 19:25:02 -0400 Subject: gpgme, symmetrically signed and MDC Message-ID: <1444433162-1576939.84373354.ft99NP2Il007304@rs146.luxsci.com> Hello, The recent commit to gnupg (commit 625e292) breaks decrypting symmetrically signed data when using gpgme. Adding "force-mdc" to gpg.conf before signing fixes things. Maybe adding --ignore-mdc-errors should be added to the command line as well so previously signed data can be used, too? Or maybe I'm doing something wrong? Thanks, -- Ben Kibbey From wk at gnupg.org Sat Oct 10 12:14:11 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 10 Oct 2015 12:14:11 +0200 Subject: [Announce] GnuPG 2.1.9 released Message-ID: <878u7byqrw.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.9. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. Noteworthy changes in version 2.1.9 =================================== * gpg: Allow fetching keys via OpenPGP DANE (--auto-key-locate). New option --print-dane-records. * gpg: Fix for a problem with PGP-2 keys in a keyring. * gpg: Fail with an error instead of a warning if a modern cipher algorithm is used without a MDC. * agent: New option --pinentry-invisible-char. * agent: Always do a RSA signature verification after creation. * agent: Fix a regression in ssh-add-ing Ed25519 keys. * agent: Fix ssh fingerprint computation for nistp384 and EdDSA. * agent: Fix crash during passprase entry on some platforms. * scd: Change timeout to fix problems with some 2.1 cards. * dirmngr: Displayed name is now Key Acquirer. * dirmngr: Add option --keyserver. Deprecate that option for gpg. Install a dirmngr.conf file from a skeleton for new installations. A detailed description of the changes found in the 2.1 branch can be found at . Please be aware that there are still known bugs which we are working on. Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.9 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.9.tar.bz2 (4810k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.9.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.9.tar.bz2 (4810k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.9.tar.bz2.sig An installer for Windows without any graphical frontend except for a basic Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.9_20151009.exe (2580k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.9_20151009.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.9_20151009.exe (2580k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.9_20151009.exe.sig Note that some feature are not yet working in the Windows version. The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.9.tar.bz2 you would use this command: gpg --verify gnupg-2.1.9.tar.bz2.sig gnupg-2.1.9.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.9.tar.bz2, you run the command like this: sha1sum gnupg-2.1.9.tar.bz2 and check that the output matches the next line: 119bab38d2ff3a849be62914be9bf7333da68883 gnupg-2.1.9.tar.bz2 f6568d0c407090d1528cda87ca0af85eec2b7b22 gnupg-w32-2.1.9_20151009.exe c0a514c2c1c0087aca05a425635e13eb7017bf1e gnupg-w32-2.1.9_20151009.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2091 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow postings at https://gnupg.org/blob/. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Maintenance and development of GnuPG is mostly financed by individual and corporate donations; see . For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Mon Oct 12 09:37:08 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Oct 2015 09:37:08 +0200 Subject: gpgme, symmetrically signed and MDC In-Reply-To: <1444433162-1576939.84373354.ft99NP2Il007304@rs146.luxsci.com> (Ben Kibbey's message of "Fri, 9 Oct 2015 19:25:02 -0400") References: <1444433162-1576939.84373354.ft99NP2Il007304@rs146.luxsci.com> Message-ID: <87twpwy1uj.fsf@vigenere.g10code.de> On Sat, 10 Oct 2015 01:25, bjk at luxsci.net said: > The recent commit to gnupg (commit 625e292) breaks decrypting > symmetrically signed data when using gpgme. Adding "force-mdc" to Good catch. I just pushed the fix below. Should we backport those MDC changes to 2.0? Salam-Shalom, Werner >From 4584125802be11833a5b289e864b45eedc2b45fd Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Mon, 12 Oct 2015 09:31:44 +0200 Subject: [PATCH] gpg: Try hard to use MDC also for sign+symenc. * g10/encrypt.c (use_mdc): Make it a global func. * g10/sign.c (sign_symencrypt_file): Use that function to decide whether to use an MDC. * tests/openpgp/conventional-mdc.test: Add a simple test case. -- We used --force-mdc in sign+symenc mode (-cs) only with --force-mdc. That broke our assumption from commit 625e292 (GnuPG 2.1.9) that all uses of modern ciphers are using MDC. Reported-by: Ben Kibbey Signed-off-by: Werner Koch --- g10/encrypt.c | 4 ++-- g10/main.h | 1 + g10/sign.c | 13 ++++++------- tests/openpgp/conventional-mdc.test | 11 ++++++++++- 4 files changed, 19 insertions(+), 10 deletions(-) diff --git a/g10/encrypt.c b/g10/encrypt.c index e2e1c05..8bdbe8c 100644 --- a/g10/encrypt.c +++ b/g10/encrypt.c @@ -101,8 +101,8 @@ encrypt_seskey (DEK *dek, DEK **seskey, byte *enckey) /* We try very hard to use a MDC */ -static int -use_mdc(PK_LIST pk_list,int algo) +int +use_mdc (pk_list_t pk_list,int algo) { /* RFC-2440 don't has MDC */ if (RFC2440) diff --git a/g10/main.h b/g10/main.h index 0bace61..c9521ad 100644 --- a/g10/main.h +++ b/g10/main.h @@ -211,6 +211,7 @@ void display_online_help( const char *keyword ); /*-- encode.c --*/ int setup_symkey (STRING2KEY **symkey_s2k,DEK **symkey_dek); +int use_mdc (pk_list_t pk_list,int algo); int encrypt_symmetric (const char *filename ); int encrypt_store (const char *filename ); int encrypt_crypt (ctrl_t ctrl, int filefd, const char *filename, diff --git a/g10/sign.c b/g10/sign.c index 782b9fc..fadf4cc 100644 --- a/g10/sign.c +++ b/g10/sign.c @@ -1261,12 +1261,7 @@ sign_symencrypt_file (const char *fname, strlist_t locusr) goto leave; } - /* We have no way to tell if the recipient can handle messages - with an MDC, so this defaults to no. Perhaps in a few years, - this can be defaulted to yes. Note that like regular - encrypting, --force-mdc overrides --disable-mdc. */ - if(opt.force_mdc) - cfx.dek->use_mdc=1; + cfx.dek->use_mdc = use_mdc (NULL, cfx.dek->algo); /* now create the outfile */ rc = open_outfile (-1, fname, opt.armor? 1:0, 0, &out); @@ -1309,7 +1304,11 @@ sign_symencrypt_file (const char *fname, strlist_t locusr) /* Push the compress filter */ if (default_compress_algo()) - push_compress_filter(out,&zfx,default_compress_algo()); + { + if (cfx.dek && cfx.dek->use_mdc) + zfx.new_ctb = 1; + push_compress_filter (out, &zfx,default_compress_algo() ); + } /* Write the one-pass signature packets */ /*(current filters: zip - encrypt - armor)*/ diff --git a/tests/openpgp/conventional-mdc.test b/tests/openpgp/conventional-mdc.test index 744e11e..031fc0e 100755 --- a/tests/openpgp/conventional-mdc.test +++ b/tests/openpgp/conventional-mdc.test @@ -31,5 +31,14 @@ for ciph in `all_cipher_algos`; do cmp z y || error "$ciph/$i: mismatch" done done - progress_end + +#info Checking sign+symencrypt +for i in $plain_files $data_files; do + echo "Hier spricht HAL" | $GPG --passphrase-fd 0 $s2k -cs -o x --yes $i + echo "Hier spricht HAL" | $GPG --passphrase-fd 0 $s2k -o y --yes x + cmp $i y || error "$i: mismatch in sign+symenc" +done + + +# eof -- 2.1.4 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Tue Oct 13 10:33:29 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 13 Oct 2015 10:33:29 +0200 Subject: TOFU code available In-Reply-To: <87egh99ljv.wl-neal@walfield.org> References: <87oagi9tm1.wl-neal@walfield.org> <87fv1ta8aq.fsf@vigenere.g10code.de> <87egh99ljv.wl-neal@walfield.org> Message-ID: <877fmr9nhi.wl-neal@walfield.org> At Mon, 05 Oct 2015 21:12:36 +0200, Neal H. Walfield wrote: > Note: the point is not to come up with the canonical email address, > but to compare two email addresses and indicate whether they are > similar enough that a warning is justified. Werner and I discussed this offline. He argued that if we aggressively normalize email addresses then we'll never be done. For instance, we need to consider homograph attacks (glyphs that look similar but have different code points, e.g. a and alpha) and invalid unicode. To help detect conflicts there are two measures that we can take. First, the MUA can check that the sender and the signer are consistent with each other. (This check should be done even if you're not using TOFU. Unfortunately, it is currently only performed by kmail and claws.) This doesn't work if the message is forwarded or bounced; if the From header is forged; or, if a message is checked outside of the MUA (e.g., from the command line). Second, we can always show some basic statistics when verifying a signature. In particular, we show the number of signatures that we've verified. The idea is that if the user is in regular contact with someone and gpg reports that this is the first message that its seen signed by that key, then the user should become suspicious. Neal From wk at gnupg.org Tue Oct 13 13:26:25 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Oct 2015 13:26:25 +0200 Subject: TOFU code available In-Reply-To: <877fmr9nhi.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 13 Oct 2015 10:33:29 +0200") References: <87oagi9tm1.wl-neal@walfield.org> <87fv1ta8aq.fsf@vigenere.g10code.de> <87egh99ljv.wl-neal@walfield.org> <877fmr9nhi.wl-neal@walfield.org> Message-ID: <87eggzuhzy.fsf@vigenere.g10code.de> On Tue, 13 Oct 2015 10:33, neal at walfield.org said: > aggressively normalize email addresses then we'll never be done. For > instance, we need to consider homograph attacks (glyphs that look > similar but have different code points, e.g. a and alpha) and invalid Also transliteration are a common problem. For example "otto.m?ller at foo" -> "otto.mueller at foo" which is pretty common in German and there are more complex cases if it comes to Cyrillic or Japanese. Better leave this to the MUA. Thanks for writing this up, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Oct 14 02:19:29 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 14 Oct 2015 09:19:29 +0900 Subject: TOFU code available In-Reply-To: <87eggzuhzy.fsf@vigenere.g10code.de> References: <87oagi9tm1.wl-neal@walfield.org> <87fv1ta8aq.fsf@vigenere.g10code.de> <87egh99ljv.wl-neal@walfield.org> <877fmr9nhi.wl-neal@walfield.org> <87eggzuhzy.fsf@vigenere.g10code.de> Message-ID: <561D9F91.20601@fsij.org> On 10/13/2015 08:26 PM, Werner Koch wrote: > Also transliteration are a common problem. For example > "otto.m?ller at foo" -> "otto.mueller at foo" which is pretty common in German > and there are more complex cases if it comes to Cyrillic or Japanese. > Better leave this to the MUA. There are multiple ways for transliteration of Japanese. For example, someone wants to use "si" not "shi". I remember the case where a person in Japan named Kobayashi in 90's. The person in a company used login name "kobayash" because of UNIX 8-character restriction (omitting the last "i"). He also had an e-mail alias "kobayashi" which looked better (for him). So, he could be reachable by both addresses of kobayash at the-company or kobayashi at the-company. It was somehow confusing; When he sent e-mail from good MUA, it was from kobayashi at the-company. When he sent e-mail by a script in UNIX (by /usr/lib/sendmail), it was kobayash at the-company. In a new year, a new system administrator assigned login name "kobayasi" for a freshman (also named Kobayashi), without checking existing usernames carefully. The freshman set up his MUA with kobayashi at the-company (wrongly). All replies to the freshman went to another person's (senior Kobayashi's) mail box. -- From gniibe at fsij.org Thu Oct 15 02:31:24 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 15 Oct 2015 09:31:24 +0900 Subject: gpgme: fix gpg_error_t and gpg_err_code_t confusion Message-ID: <561EF3DC.4020101@fsij.org> Hello, Handling the issue 2074 [0] for libgcrypt, I review the patch submitted [1]. (Note that the discussion in the issue and the patch is a sort of independent.) I applied it and then fixed the change (reverting a part of the original change), both for master and LIBGCRYPT-1-6-BRANCH. It is fixing gpg_error_t and gpg_err_code_t confusion. I also fixed similar bug in gnupg master. Those fixes are already pushed, since they are obvious simple fixes. [0] https://bugs.gnupg.org/gnupg/issue2074 [1] https://bugs.gnupg.org/gnupg/file692/patch-sunstudio Then, I found similar mistakes in gpgme. Although it's obvious fix, I haven't had an experience to push to gpgme repository. Thus, I ask if it is OK to push this fix to gpgme repo. ======================================== diff --git a/src/data-compat.c b/src/data-compat.c index 99827f1..abb7863 100644 --- a/src/data-compat.c +++ b/src/data-compat.c @@ -146,7 +146,7 @@ gpgme_data_new_from_file (gpgme_data_t *r_dh, const char *fname, int copy) static int gpgme_error_to_errno (gpgme_error_t err) { - int res = gpg_err_code_to_errno (err); + int res = gpg_err_code_to_errno (gpg_err_code (err)); if (!err) { diff --git a/src/gpgme.c b/src/gpgme.c index 343e775..3c4e8e9 100644 --- a/src/gpgme.c +++ b/src/gpgme.c @@ -91,7 +91,7 @@ gpgme_new (gpgme_ctx_t *r_ctx) TRACE_BEG (DEBUG_CTX, "gpgme_new", r_ctx); if (_gpgme_selftest) - return TRACE_ERR (gpgme_error (_gpgme_selftest)); + return TRACE_ERR (_gpgme_selftest); if (!r_ctx) return TRACE_ERR (gpg_error (GPG_ERR_INV_VALUE)); -- From gniibe at fsij.org Thu Oct 15 05:13:31 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 15 Oct 2015 12:13:31 +0900 Subject: Checksum error importing (unencrypted) ecdsa private key In-Reply-To: References: <1422491615.27984.YahooMailBasic@web125805.mail.ne1.yahoo.com> <55C95259.9000006@fsij.org> Message-ID: <561F19DB.4060302@fsij.org> Hello, On 09/18/2015 11:08 PM, Krzysztof Kotowicz wrote: > It looks like it hasn't been fixed yet, as I'm getting the same error in > 2.1.8. Do you have a bug# to track this? We have another reproductible case > at https://github.com/google/end-to-end/issues/326#issuecomment-123585977 Sorry for my late response. As you already confirmed, the fix is in 2.1.9. It was not our bug tracker, it was on my stashed patch set in my working directory. It was stashed for preparation of 2.1.7, and I pushed after 2.1.8 before 2.1.9. Thank you for your patience. -- From koto at google.com Thu Oct 15 10:58:10 2015 From: koto at google.com (Krzysztof Kotowicz) Date: Thu, 15 Oct 2015 10:58:10 +0200 Subject: Checksum error importing (unencrypted) ecdsa private key In-Reply-To: <561F19DB.4060302@fsij.org> References: <1422491615.27984.YahooMailBasic@web125805.mail.ne1.yahoo.com> <55C95259.9000006@fsij.org> <561F19DB.4060302@fsij.org> Message-ID: Thanks for your help! Now let's see that ECC adoption rise :) On Thu, Oct 15, 2015 at 5:13 AM, NIIBE Yutaka wrote: > Hello, > > On 09/18/2015 11:08 PM, Krzysztof Kotowicz wrote: > > It looks like it hasn't been fixed yet, as I'm getting the same error in > > 2.1.8. Do you have a bug# to track this? We have another reproductible > case > > at > https://github.com/google/end-to-end/issues/326#issuecomment-123585977 > > Sorry for my late response. As you already confirmed, the fix is in > 2.1.9. > > It was not our bug tracker, it was on my stashed patch set in my > working directory. It was stashed for preparation of 2.1.7, and I > pushed after 2.1.8 before 2.1.9. > > Thank you for your patience. > -- > -- koto@ / Krzysztof Kotowicz / Google -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Oct 15 18:20:17 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Oct 2015 18:20:17 +0200 Subject: gpgme: fix gpg_error_t and gpg_err_code_t confusion In-Reply-To: <561EF3DC.4020101@fsij.org> (NIIBE Yutaka's message of "Thu, 15 Oct 2015 09:31:24 +0900") References: <561EF3DC.4020101@fsij.org> Message-ID: <8737xct872.fsf@vigenere.g10code.de> On Thu, 15 Oct 2015 02:31, gniibe at fsij.org said: > I applied it and then fixed the change (reverting a part of the > original change), both for master and LIBGCRYPT-1-6-BRANCH. Many thanks. > Then, I found similar mistakes in gpgme. Although it's obvious fix, > I haven't had an experience to push to gpgme repository. Thus, I ask > if it is OK to push this fix to gpgme repo. Okay. > - int res = gpg_err_code_to_errno (err); > + int res = gpg_err_code_to_errno (gpg_err_code (err)); (I was not aware that we had such a function) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Fri Oct 16 11:04:59 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 16 Oct 2015 11:04:59 +0200 Subject: Better name for new "Internet Gateway for Certs" (Re: please do not change "Directory Manager" to "Network Manager") In-Reply-To: <87mvw7hlrs.fsf@vigenere.g10code.de> References: <87lhbvcev0.fsf@alice.fifthhorseman.net> <87zj089fc6.wl-neal@walfield.org> <87mvw7hlrs.fsf@vigenere.g10code.de> Message-ID: <201510161105.04827.bernhard@intevation.de> > One reason why I changed the name is to make it clear that all access to > the net is done via dirmngr and thus not installing dirmngr will > effectivly disable all web bugs. It is mainly about the public keys with additional data - which I have made a habit of calling "certificates" or "certs". So if this is element going to be included in the name, I'd vote for "certs" or "cert". I do not like the "manager" bit in the name, because it maybe a gateway, bridging or distribution functionality, but it does not maintain a larger number of things (in my understanding). The managing is more done by a different component. So here some naming ideas based the above points brainstorming: "certs network link" "network gateway", as in "GnuPG's network gateway" -> "gng" or "gnetgate" "network link" "internet certs gate" "Net Gate for Certs" or a combination. Hope you'll find my suggestions inspiring! Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 bernhard at intevation.de Fri Oct 16 10:52:49 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 16 Oct 2015 10:52:49 +0200 Subject: Own Mail: PGP running on local server; Is it secure In-Reply-To: <20150926113657.Horde.oqbo4_PTIvtpEXqQNLv9yrE@slackmail.co.uk> References: <20150926113657.Horde.oqbo4_PTIvtpEXqQNLv9yrE@slackmail.co.uk> Message-ID: <201510161052.55343.bernhard@intevation.de> Just for completeness, On Saturday 26 September 2015 at 12:36:57, sam_uk at riseup.net wrote: > Hi I spotted this project: https://www.own-mailbox.com/#HowWork the topic has been discussed further on gnupg-users. Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 bernhard at intevation.de Fri Oct 16 10:36:47 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 16 Oct 2015 10:36:47 +0200 Subject: TOFU code available In-Reply-To: <87oagi9tm1.wl-neal@walfield.org> References: <87oagi9tm1.wl-neal@walfield.org> Message-ID: <201510161036.53269.bernhard@intevation.de> Hi Neal, good too see progress here, discussion and writeups On Thursday 01 October 2015 at 23:17:10, Neal H. Walfield wrote: > --tofu-default-policy is a powerful knob. ?A common concern among > security sensitive users is that TOFU is too weak, because it > automatically trusts everyone. ?But, TOFU can detect man-in-the-middle > attacks. ?Although a careful use of the WoT can also prevent such > attacks, the WoT imposes a large overhead: secure communication is > often not possible until a physical meeting has occured and the user > must spend a lot of time not only collecting signatures, but also > curating their trusted introducers (gpg --key-edit KEYID; trust). > (Anecdotally, even those people who actively sign keys don't realize > they have to do this.) ?By setting --tofu-default-policy to unknown, > we only use the TOFU data for negative assertions (i.e., conflicts) > and rely on the WoT for positive assertions. ?Thus, TOFU can help even > the most paranoid without exposing them to additional risk. My suggestion is to keep a "current state" with "current design" document on the wiki, because it soon gets harder to keep the overview on an email discussion. For example it took me some time scanning to find the part above that I was more interested in as it explains goals and parts of the motivation and reasoning about this feature. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 gniibe at fsij.org Fri Oct 16 17:02:03 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 17 Oct 2015 00:02:03 +0900 Subject: 2.1 migration and smartcard stub Message-ID: <5621116B.6010609@fsij.org> Hello, At Debconf15, I was asked about 2.1 migration. The bug is filed in Debian: gnupg2: gnupg 2.1 secret keys migration skips keys on smartcard https://bugs.debian.org/795881 I think that GnuPG 2.1 should emit some message for smartkey stub. In the end of this message, I put my proposal patch. It memorizes if there were stub in private key migration, and if so, emit a message which suggests invocation of "gpg --card-status" with smartcard. Currently, the message is: To migrate private key stubs for smartcard, run: gpg --card-status with smartcard But, I'm not sure if new PO message is worth for that. I'm not sure if "gpg" in the message would be better than "gpg2" (there are instances of "gpg" as well as "gpg2" in existing code to emit messages), or not. I'm not good at using plural form. Please correct the message string. Situation is: Private key (or private sub key) for smartcard has a stub (reference) to the specific card, instead of key material (which is on the card). A single smartcard can have multiple private (sub)keys. A user can use multiple smartcards. If a user uses multiple smartcards, invocation should be done for each smartcard. Perhaps, it would be good not to expose internal term "stub", and following would be better: To migrate secring.gpg for smartcard, with each smartcard, run: gpg --card-status diff --git a/g10/import.c b/g10/import.c index 048b136..0e784bc 100644 --- a/g10/import.c +++ b/g10/import.c @@ -1331,6 +1331,7 @@ transfer_secret_keys (ctrl_t ctrl, struct stats_s *stats, kbnode_t sec_keyblock, unsigned char *wrappedkey = NULL; size_t wrappedkeylen; char *cache_nonce = NULL; + int stub_key_found = 0; /* Get the current KEK. */ err = agent_keywrap_key (ctrl, 0, &kek, &keklen); @@ -1391,7 +1392,10 @@ transfer_secret_keys (ctrl_t ctrl, struct stats_s *stats, kbnode_t sec_keyblock, has been inserted and a stub key is in turn generated by the agent. */ if (ski->s2k.mode == 1001 || ski->s2k.mode == 1002) - continue; + { + stub_key_found = 1; + continue; + } /* Convert our internal secret key object into an S-expression. */ nskey = pubkey_get_nskey (pk->pubkey_algo); @@ -1568,6 +1572,10 @@ transfer_secret_keys (ctrl_t ctrl, struct stats_s *stats, kbnode_t sec_keyblock, } } + if (!err && stub_key_found) + /* We need to notify user how to migrate stub keys. */ + err = gpg_error (GPG_ERR_NOT_PROCESSED); + leave: gcry_sexp_release (curve); xfree (cache_nonce); @@ -1757,8 +1765,17 @@ import_secret_one (ctrl_t ctrl, const char *fname, kbnode_t keyblock, keystr_from_pk (pk)); else { + gpg_error_t err; + nr_prev = stats->secret_imported; - if (!transfer_secret_keys (ctrl, stats, keyblock, batch)) + err = transfer_secret_keys (ctrl, stats, keyblock, batch); + if (gpg_err_code (err) == GPG_ERR_NOT_PROCESSED) + { + log_info (_("To migrate private key stubs for smartcard, " + "run: gpg --card-status with smartcard\n")); + err = 0; + } + if (!err) { int status = 16; if (!opt.quiet) -- From neal at walfield.org Sun Oct 18 19:03:22 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 18 Oct 2015 19:03:22 +0200 Subject: TOFU code available In-Reply-To: <87oagi9tm1.wl-neal@walfield.org> References: <87oagi9tm1.wl-neal@walfield.org> Message-ID: <8737x89kit.wl-neal@walfield.org> Hi, I've now pushed the TOFU code to master. It will be part of the next release. It would be great to get some feedback on it. To enable TOFU, either set --trust-model=tofu or --trust-model=tofu+pgp. (Alternatively, you can also add the line 'trust-model MODEL' to your gpg.conf). To get a feel for how TOFU works, try the following. Encrypt a message: $ gpg2 -e -a -r EE37CF96 * gpg: Verified 0 messages signed by "Testing (insecure!)" (key: 362D 3527 F53A AD19 71AA FDE6 5885 9975 EE37 CF96, policy auto). * gpg: Warning: we've have yet to see a message signed by this key! * gpg: Warning: if this value is unexpectedly low, this might indicate that this key is a forgery! Carefully examine the email address for small variations (e.g., additional white space). If the key is suspect, then use 'gpg --tofu-policy bad "362D 3527 F53A AD19 71AA FDE6 5885 9975 EE37 CF96"' to mark the key as being bad. gpg: 6EA74366: There is limited assurance this key belongs to the named user -----BEGIN PGP MESSAGE----- ... Verify a message: $ gpg2 --verify EE37CF96-1.txt gpg: Signature made Fri 18 Sep 2015 02:05:37 PM CEST using RSA key ID EE37CF96 * gpg: Good signature from "Testing (insecure!)" [marginal] * gpg: Verified 0 messages signed by "Testing (insecure!)" (key: 362D 3527 F53A AD19 71AA FDE6 5885 9975 EE37 CF96, policy auto). * gpg: Warning: we've have yet to see a message signed by this key! * gpg: Warning: if this value is unexpectedly low, this might indicate that this key is a forgery! Carefully examine the email address for small variations (e.g., additional white space). If the key is suspect, then use 'gpg --tofu-policy bad "362D 3527 F53A AD19 71AA FDE6 5885 9975 EE37 CF96"' to mark the key as being bad. gpg: WARNING: This key is not certified with sufficiently trusted signatures! gpg: It is not certain that the signature belongs to the owner. Primary key fingerprint: 362D 3527 F53A AD19 71AA FDE6 5885 9975 EE37 CF96 And, encrypt to a key with the same email (well, in this case, name since there is no email): $ gpg2 -e -a -r BC15C85A The binding <439D 954F 18F7 9CC4 F71B ED91 CACE D996 BC15 C85A, testing (insecure!)> is NOT known. Please indicate whether you believe the binding is legitimate (the key belongs to the stated owner) or a forgery (bad). Statistics for keys with the email 'testing (insecure!)': 439D 954F 18F7 9CC4 F71B ED91 CACE D996 BC15 C85A (this key): 0 signed messages. 362D 3527 F53A AD19 71AA FDE6 5885 9975 EE37 CF96 (policy: auto): 1 message signed over the past 1 month. Normally, there is only a single key associated with an emailaddress. However, people sometimes generate a new key iftheir key is too old or they think it might be compromised.Alternatively, a new key may indicate a man-in-the-middle attack!Before accepting this key, you should talk to or call the personto make sure this new key is legitimate. (G)ood/(A)ccept once/(U)nknown/(R)eject once/(B)ad? b gpg: Verified 0 messages signed by "Testing (insecure!)" (key: 439D 954F 18F7 9CC4 F71B ED91 CACE D996 BC15 C85A, policy bad). gpg: invalid trustlevel 3 returned from validation layer gpg: C6D85A87: There is no assurance this key belongs to the named user sub rsa1024/C6D85A87 2015-09-18 Testing (insecure!) Primary key fingerprint: 439D 954F 18F7 9CC4 F71B ED91 CACE D996 BC15 C85A Subkey fingerprint: F5A6 985C B48D BF6C 241B 6172 6B2A BB68 C6D8 5A87 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) n gpg: [stdin]: encryption failed: Unusable public key Also, take a look at the manual for a description the related commands / options (search for 'tofu'). :) Neal From dkg at fifthhorseman.net Sun Oct 18 23:35:32 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 18 Oct 2015 17:35:32 -0400 Subject: [PATCH] Enable deprecation of specific digest algorithms for gpg and gpgv Message-ID: <1445204132-20727-1-git-send-email-dkg@fifthhorseman.net> * g10/options.h: add additional_weak_digests linked list to opts. * g10/main.h: declare weakhash linked list struct and additional_weak_digest() function to insert newly-declared weak digests into opts. * g10/misc.c: (additional_weak_digest): new function. (print_digest_algo_note): check for deprecated digests; use proper gcry_md_algos type. * g10/sig-check.c: (do_check): reject weak digests in addition to MD5. * g10/gpg.c: add --weak-digest option to gpg * doc/gpg.texi: document gpg --weak-digest option * g10/gpgv.c: add --weak-digest option to gpgv * doc/gpgv.texi: document gpgv --weak-digest option -- gpg and gpgv treat signatures made over MD5 as unreliable, unless the user supplies --allow-weak-digests to gpg. Signatures over any other digest are considered acceptable. Despite SHA-1 being a mandatory-to-implement digest algorithm in RFC 4880, the collision-resistance of SHA-1 is weaker than anyone would like it to be. Some operators of high-value targets that depend on OpenPGP signatures may wish to require their signers to use a stronger digest algorithm than SHA1, even if the OpenPGP ecosystem at large cannot deprecate SHA1 entirely today. This changeset adds a new "--weak-digest DIGEST" option for both gpg and gpgv, which makes it straightforward for anyone to treat any signature or certification made over the specified digest as unreliable. This option can be supplied multiple times if the operator wishes to deprecate multiple digest algorithms, and will be ignored completely if the operator supplies --allow-weak-digests (as before). MD5 is still always considered weak, regardless of any further --weak-digest options supplied. Signed-off-by: Daniel Kahn Gillmor --- doc/gpg.texi | 17 ++++++++++++++--- doc/gpgv.texi | 8 ++++++++ g10/gpg.c | 6 ++++++ g10/gpgv.c | 5 +++++ g10/main.h | 7 +++++++ g10/misc.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++--- g10/options.h | 1 + g10/sig-check.c | 11 +++++++---- 8 files changed, 96 insertions(+), 10 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index a702040..ffd7a97 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2789,9 +2789,20 @@ message was tampered with intentionally by an attacker. @item --allow-weak-digest-algos @opindex allow-weak-digest-algos -Signatures made with the broken MD5 algorithm are normally rejected -with an ``invalid digest algorithm'' message. This option allows the -verification of signatures made with such weak algorithms. +Signatures made with known-weak digest algorithms are normally +rejected with an ``invalid digest algorithm'' message. This option +allows the verification of signatures made with such weak algorithms. +MD5 is the only digest algorithm considered weak by default. See also + at option{--weak-digest} to reject other digest algorithms. + + at item --weak-digest @code{name} + at opindex weak-digest +Treat the specified digest algorithm as weak. Signatures made over +weak digests algorithms are normally rejected. This option can be +supplied multiple times if multiple algorithms should be considered +weak. See also @option{--allow-weak-digest-algos} to disable +rejection of weak digests. MD5 is always considered weak, and does +not need to be listed explicitly. @item --no-default-keyring @opindex no-default-keyring diff --git a/doc/gpgv.texi b/doc/gpgv.texi index 6bcbc0a..280966b 100644 --- a/doc/gpgv.texi +++ b/doc/gpgv.texi @@ -118,6 +118,14 @@ checks into warnings. @include opt-homedir.texi + at item --weak-digest @code{name} + at opindex weak-digest +Treat the specified digest algorithm as weak. Signatures made over +weak digests algorithms are normally rejected. This option can be +supplied multiple times if multiple algorithms should be considered +weak. MD5 is always considered weak, and does not need to be listed +explicitly. + @end table @mansect return value diff --git a/g10/gpg.c b/g10/gpg.c index ada913c..cb610a1 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -389,6 +389,7 @@ enum cmd_and_opt_values oPrintDANERecords, oTOFUDefaultPolicy, oTOFUDBFormat, + oWeakDigest, oNoop }; @@ -749,6 +750,7 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_s_s (oPersonalCompressPreferences, "personal-compress-preferences", "@"), ARGPARSE_s_s (oFakedSystemTime, "faked-system-time", "@"), + ARGPARSE_s_s (oWeakDigest, "weak-digest","@"), /* Aliases. I constantly mistype these, and assume other people do as well. */ @@ -2208,6 +2210,7 @@ main (int argc, char **argv) set_homedir (default_homedir ()); opt.passphrase_repeat = 1; opt.emit_version = 1; /* Limit to the major number. */ + opt.additional_weak_digests = NULL; /* Check whether we have a config file on the command line. */ orig_argc = argc; @@ -3124,6 +3127,9 @@ main (int argc, char **argv) break; case oAgentProgram: opt.agent_program = pargs.r.ret_str; break; case oDirmngrProgram: opt.dirmngr_program = pargs.r.ret_str; break; + case oWeakDigest: + additional_weak_digest(pargs.r.ret_str); + break; case oDisplay: set_opt_session_env ("DISPLAY", pargs.r.ret_str); diff --git a/g10/gpgv.c b/g10/gpgv.c index 0807622..23e7610 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -61,6 +61,7 @@ enum cmd_and_opt_values { oStatusFD, oLoggerFD, oHomedir, + oWeakDigest, aTest }; @@ -78,6 +79,7 @@ static ARGPARSE_OPTS opts[] = { N_("|FD|write status info to this FD")), ARGPARSE_s_i (oLoggerFD, "logger-fd", "@"), ARGPARSE_s_s (oHomedir, "homedir", "@"), + ARGPARSE_s_s (oWeakDigest, "weak-digest", "@"), ARGPARSE_end () }; @@ -192,6 +194,9 @@ main( int argc, char **argv ) log_set_fd (translate_sys2libc_fd_int (pargs.r.ret_int, 1)); break; case oHomedir: opt.homedir = pargs.r.ret_str; break; + case oWeakDigest: + additional_weak_digest(pargs.r.ret_str); + break; case oIgnoreTimeConflict: opt.ignore_time_conflict = 1; break; default : pargs.err = ARGPARSE_PRINT_ERROR; break; } diff --git a/g10/main.h b/g10/main.h index c9521ad..0226c64 100644 --- a/g10/main.h +++ b/g10/main.h @@ -69,6 +69,12 @@ struct groupitem struct groupitem *next; }; +struct weakhash +{ + enum gcry_md_algos algo; + struct weakhash *next; +}; + /*-- gpg.c --*/ extern int g10_errors_seen; @@ -82,6 +88,7 @@ void print_pubkey_algo_note (pubkey_algo_t algo); void print_cipher_algo_note (cipher_algo_t algo); void print_digest_algo_note (digest_algo_t algo); void print_md5_rejected_note (void); +void additional_weak_digest (const char* digestname); /*-- armor.c --*/ char *make_radix64_string( const byte *data, size_t len ); diff --git a/g10/misc.c b/g10/misc.c index 9134b28..39f77bb 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -307,6 +307,10 @@ print_cipher_algo_note (cipher_algo_t algo) void print_digest_algo_note (digest_algo_t algo) { + int deprecated = 0; + const enum gcry_md_algos galgo = map_md_openpgp_to_gcry (algo); + const struct weakhash *weak; + if(algo >= 100 && algo <= 110) { static int warn=0; @@ -315,14 +319,21 @@ print_digest_algo_note (digest_algo_t algo) warn=1; es_fflush (es_stdout); log_info (_("WARNING: using experimental digest algorithm %s\n"), - gcry_md_algo_name (algo)); + gcry_md_algo_name (galgo)); } } - else if(algo==DIGEST_ALGO_MD5) + else if(algo == DIGEST_ALGO_MD5) + deprecated = 1; + else + for (weak = opt.additional_weak_digests; weak != NULL; weak = weak->next) + if (weak->algo == galgo) + deprecated = 1; + + if (deprecated) { es_fflush (es_stdout); log_info (_("WARNING: digest algorithm %s is deprecated\n"), - gcry_md_algo_name (algo)); + gcry_md_algo_name (galgo)); } } @@ -1676,3 +1687,37 @@ ecdsa_qbits_from_Q (unsigned int qbits) qbits /= 2; return qbits; } + + +/* ignore signatures and certifications made over certain digest + algorithms by default, MD5 is considered weak. This allows users + to deprecate support for other algorithms as well. +*/ +void +additional_weak_digest (const char* digestname) +{ + struct weakhash *weak = NULL; + const enum gcry_md_algos algo = string_to_digest_algo(digestname); + + if (algo == GCRY_MD_MD5) + return; /* MD5 is always considered weak, no need to add it */ + + if (algo == GCRY_MD_NONE) + { + log_error(_("Unknown weak digest '%s'\n"), digestname); + return; + } + + /* check to ensure it's not already present */ + for (weak = opt.additional_weak_digests; weak != NULL; weak = weak->next) + { + if (algo == weak->algo) + return; + } + + /* add it to the head of the list */ + weak = xmalloc(sizeof(*weak)); + weak->algo = algo; + weak->next = opt.additional_weak_digests; + opt.additional_weak_digests = weak; +} diff --git a/g10/options.h b/g10/options.h index 2135aa0..c1ea9dd 100644 --- a/g10/options.h +++ b/g10/options.h @@ -170,6 +170,7 @@ struct prefitem_t *personal_cipher_prefs; prefitem_t *personal_digest_prefs; prefitem_t *personal_compress_prefs; + struct weakhash *additional_weak_digests; int no_perm_warn; int no_mdc_warn; char *temp_dir; diff --git a/g10/sig-check.c b/g10/sig-check.c index d45a9f3..8db71a1 100644 --- a/g10/sig-check.c +++ b/g10/sig-check.c @@ -274,15 +274,18 @@ do_check( PKT_public_key *pk, PKT_signature *sig, gcry_md_hd_t digest, { gcry_mpi_t result = NULL; int rc = 0; + const struct weakhash *weak; if( (rc=do_check_messages(pk,sig,r_expired,r_revoked)) ) return rc; - if (sig->digest_algo == GCRY_MD_MD5 - && !opt.flags.allow_weak_digest_algos) + if (!opt.flags.allow_weak_digest_algos) { - print_md5_rejected_note (); - return GPG_ERR_DIGEST_ALGO; + if (sig->digest_algo == GCRY_MD_MD5) + return GPG_ERR_DIGEST_ALGO; + for (weak = opt.additional_weak_digests; weak != NULL; weak = weak->next) + if (sig->digest_algo == weak->algo) + return GPG_ERR_DIGEST_ALGO; } /* Make sure the digest algo is enabled (in case of a detached -- 2.6.1 From wk at gnupg.org Mon Oct 19 14:33:06 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Oct 2015 14:33:06 +0200 Subject: [PATCH] Enable deprecation of specific digest algorithms for gpg and gpgv In-Reply-To: <1445204132-20727-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sun, 18 Oct 2015 17:35:32 -0400") References: <1445204132-20727-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87twpnqbr1.fsf@vigenere.g10code.de> Hi, this feature is non-disruptive and it makes sense for certain users. Thus I applied it. Thanks. As minor change I capitalized comments and - for (weak = opt.additional_weak_digests; weak != NULL; weak = weak->next) + for (weak = opt.additional_weak_digests; weak; weak = weak->next) to make the line fit into 80 columns. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Oct 19 15:03:35 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Oct 2015 15:03:35 +0200 Subject: The --use-tor option Message-ID: <87oafvqac8.fsf@vigenere.g10code.de> Hi! I implemented a --use-tor option for dirmngr which routes all traffic over TOR. This should be HTTP based CRLs (not tested), keyserver access and all non-LDAP --fetch-key URLs. If traffic can't be torified the command will fail. This is not complete because DNS lookups are leaking. This could be fixed for some commands (like gpg --fetch-key URL) but that would be a specialized solution. The more problematic areas are resolving of the keyserver pools and retrieving of CERT and DANE records. Thus I did not implemented the specialized case for --fetch-key. Given that it is not likely that we will seen generic DNS support in TOR soon, we need to find our own solution. Using a public server via TCP is probably the only thing we can do. This requires two thing: - Being able to specify a public DNS server independent of /etc/resolv.conf. - Forcing the use of a virtual circuit (ie. TCP) so that TOR can route the request. With the standard resolver this is not possible. Adding a full-fledged resolver library to Dirmngr is overkill and we will likely run into problems under Windows. My idea is to make use of the ADNS library. A quick check showed that it is not too much work to add SOCKS5 support (to access TOR) and a flag to enable this. Now, for Windows we are making use of ADNS for a long time now. In 2008 I ported ADNS to Windows and updated the build system to make use of autotools [1]. Unfortunately back then the ADNS author did not liked the use of autotools and was not genuinely interested in Windows support. Thus I maintain my port under the name libadns-1.4-g10-N but use it with GnuPG only on Windows. Adding the TOR support would be easy for me but that would be a Windows only solution to avoid a real fork. Possible solutions are: - Add the required parts of ADNS to GnuPG proper. That would actually be the easiest way but it has similar problems as static linking. - Rename my port and keep it separate from ADNS. - Check with upstream ADNS whether adding SOCKS5 support and a TOR flag would be accepted, develop that, and keep keep the APIs of my (Windows) port and upstream in sync. Suggestions? Salam-Shalom, Werner [1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=adns.git -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Oct 19 15:27:44 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Oct 2015 15:27:44 +0200 Subject: The --use-tor option In-Reply-To: <87oafvqac8.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 19 Oct 2015 15:03:35 +0200") References: <87oafvqac8.fsf@vigenere.g10code.de> Message-ID: <87fv17q97z.fsf@vigenere.g10code.de> On Mon, 19 Oct 2015 15:03, wk at gnupg.org said: > I implemented a --use-tor option for dirmngr which routes all traffic If you want to test it you need the gnupg _and_ libassuan master branches. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Mon Oct 19 16:41:23 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 19 Oct 2015 10:41:23 -0400 Subject: [PATCH] print warning when rejecting weak digests In-Reply-To: <87twpnqbr1.fsf@vigenere.g10code.de> References: <87twpnqbr1.fsf@vigenere.g10code.de> Message-ID: <1445265683-6824-1-git-send-email-dkg@fifthhorseman.net> * g10/main.h: change print_md5_rejected_note to print_digest_rejected_note * g10/misc.c: same; parameterize function to take an enum gcry_md_algos * g10/sig-check.c: use print_digest_rejected_note() when rejecting signatures -- 76afaed65e3b0ddfa4923cb577ada43217dd4b18 allowed extra --weak-digests, but removed the one call to print_md5_rejected_note(). This replaces and generalizes that warning. Signed-Off-By: Daniel Kahn Gillmor --- g10/main.h | 2 +- g10/misc.c | 4 ++-- g10/sig-check.c | 10 ++++++++-- 3 files changed, 11 insertions(+), 5 deletions(-) diff --git a/g10/main.h b/g10/main.h index 0226c64..601a952 100644 --- a/g10/main.h +++ b/g10/main.h @@ -87,7 +87,7 @@ extern int g10_errors_seen; void print_pubkey_algo_note (pubkey_algo_t algo); void print_cipher_algo_note (cipher_algo_t algo); void print_digest_algo_note (digest_algo_t algo); -void print_md5_rejected_note (void); +void print_digest_rejected_note (enum gcry_md_algos algo); void additional_weak_digest (const char* digestname); /*-- armor.c --*/ diff --git a/g10/misc.c b/g10/misc.c index c135059..93ddaa0 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -339,7 +339,7 @@ print_digest_algo_note (digest_algo_t algo) void -print_md5_rejected_note (void) +print_digest_rejected_note (enum gcry_md_algos algo) { static int shown; @@ -348,7 +348,7 @@ print_md5_rejected_note (void) es_fflush (es_stdout); log_info (_("Note: signatures using the %s algorithm are rejected\n"), - "MD5"); + gcry_md_algo_name(algo)); shown = 1; } } diff --git a/g10/sig-check.c b/g10/sig-check.c index 84930d6..23f42b9 100644 --- a/g10/sig-check.c +++ b/g10/sig-check.c @@ -282,10 +282,16 @@ do_check( PKT_public_key *pk, PKT_signature *sig, gcry_md_hd_t digest, if (!opt.flags.allow_weak_digest_algos) { if (sig->digest_algo == GCRY_MD_MD5) - return GPG_ERR_DIGEST_ALGO; + { + print_digest_rejected_note(sig->digest_algo); + return GPG_ERR_DIGEST_ALGO; + } for (weak = opt.additional_weak_digests; weak; weak = weak->next) if (sig->digest_algo == weak->algo) - return GPG_ERR_DIGEST_ALGO; + { + print_digest_rejected_note(sig->digest_algo); + return GPG_ERR_DIGEST_ALGO; + } } /* Make sure the digest algo is enabled (in case of a detached -- 2.6.1 From wk at gnupg.org Mon Oct 19 17:37:50 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Oct 2015 17:37:50 +0200 Subject: [PATCH] print warning when rejecting weak digests In-Reply-To: <1445265683-6824-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 19 Oct 2015 10:41:23 -0400") References: <87twpnqbr1.fsf@vigenere.g10code.de> <1445265683-6824-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <876122rhrl.fsf@vigenere.g10code.de> On Mon, 19 Oct 2015 16:41, dkg at fifthhorseman.net said: > * g10/main.h: change print_md5_rejected_note to print_digest_rejected_note > * g10/misc.c: same; parameterize function to take an enum gcry_md_algos > * g10/sig-check.c: use print_digest_rejected_note() when rejecting signatures Pushed. BTW, no need to document changes to the prototypes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From malte at wk3.org Mon Oct 19 16:54:49 2015 From: malte at wk3.org (Malte) Date: Mon, 19 Oct 2015 16:54:49 +0200 Subject: The --use-tor option In-Reply-To: <87oafvqac8.fsf@vigenere.g10code.de> References: <87oafvqac8.fsf@vigenere.g10code.de> Message-ID: <2331911.xffYaiXkJa@localhost> On Monday 19 October 2015 15:03 Werner Koch wrote: > This is not complete because DNS lookups are leaking. This could be > fixed [?] Maybe Kristian Fiskerstrand would be willing to set up an Onion Service for the SKS-Pool that could be used by default? From dkg at fifthhorseman.net Tue Oct 20 05:49:46 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 19 Oct 2015 23:49:46 -0400 Subject: [PATCH] ship sks-keyservers.netCA.pem in distributed tarball Message-ID: <1445312986-29456-1-git-send-email-dkg@fifthhorseman.net> sks-keyservers.netCA.pem should get shipped in the signed and distributed tarball, to facilitate hkps connections to the keyserver pool. Signed-Off-By: Daniel Kahn Gillmor --- dirmngr/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dirmngr/Makefile.am b/dirmngr/Makefile.am index ae16660..845f3f5 100644 --- a/dirmngr/Makefile.am +++ b/dirmngr/Makefile.am @@ -19,7 +19,7 @@ ## Process this file with automake to produce Makefile.in -EXTRA_DIST = OAUTHORS ONEWS ChangeLog-2011 tls-ca.pem +EXTRA_DIST = OAUTHORS ONEWS ChangeLog-2011 tls-ca.pem sks-keyservers.netCA.pem bin_PROGRAMS = dirmngr dirmngr-client -- 2.6.1 From twim at riseup.net Tue Oct 20 11:32:51 2015 From: twim at riseup.net (Ivan Markin) Date: Tue, 20 Oct 2015 09:32:51 +0000 Subject: Fwd: Re: The --use-tor option Message-ID: <56260A43.5090500@riseup.net> Werner Koch: > I implemented a --use-tor option for dirmngr which routes all traffic > over TOR. This should be HTTP based CRLs (not tested), keyserver access > and all non-LDAP --fetch-key URLs. If traffic can't be torified the > command will fail. > > This is not complete because DNS lookups are leaking. Why not just use torsocks [1]? There are any cons that I'm missing? [1] https://gitweb.torproject.org/torsocks.git Thanks, -- Ivan Markin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Oct 20 13:33:02 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Oct 2015 13:33:02 +0200 Subject: Fwd: Re: The --use-tor option In-Reply-To: <56260A43.5090500@riseup.net> (Ivan Markin's message of "Tue, 20 Oct 2015 09:32:51 +0000") References: <56260A43.5090500@riseup.net> Message-ID: <87d1w9ojv5.fsf@vigenere.g10code.de> On Tue, 20 Oct 2015 11:32, twim at riseup.net said: > Why not just use torsocks [1]? There are any cons that I'm missing? Because it is hack for ELF based systems and does not work under Windows. Anyway it does not solve the real problem of leaking DNS. Recall that we need more than just AAAA records. Meanwhile I hacked ADNS and I am now able to send DNS queries to a public server via TOR. Works nice and would be sufficient for Dirmngr. While doing that I realized that the TCP mode in ADNS has the problem that it does a non-blocking connect but does not really handle EINPROGRESS. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jacob at appelbaum.net Tue Oct 20 13:43:34 2015 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Tue, 20 Oct 2015 11:43:34 +0000 Subject: Fwd: Re: The --use-tor option In-Reply-To: <87d1w9ojv5.fsf@vigenere.g10code.de> References: <56260A43.5090500@riseup.net> <87d1w9ojv5.fsf@vigenere.g10code.de> Message-ID: On 10/20/15, Werner Koch wrote: > On Tue, 20 Oct 2015 11:32, twim at riseup.net said: > >> Why not just use torsocks [1]? There are any cons that I'm missing? > > Because it is hack for ELF based systems and does not work under > Windows. Anyway it does not solve the real problem of leaking DNS. > Recall that we need more than just AAAA records. torsocks is great, needed and useful but it is a hack around native Tor integration as much as anything. Will gnupg have a UseTor option for gpg.conf now? I could imagine: UseTor /path/to/unixsocket UseTor 127.0.0.1:9050 If GnuPG had Tor ControlPort integration, we could even generate Tor Hidden Services automatically and use them together in smart ways with GnuPG. > > Meanwhile I hacked ADNS and I am now able to send DNS queries to a > public server via TOR. Works nice and would be sufficient for Dirmngr. > While doing that I realized that the TCP mode in ADNS has the problem > that it does a non-blocking connect but does not really handle > EINPROGRESS. I hope you'll also support the Unix Domain Socket SOCKS port that we're now shipping with Tor (0.2.7.x and up, I think). That would mean that gnupg could be entirely sandboxed from the internet and only able to talk to the internet through Tor. What else isn't proxy friendly in GnuPG? All the best, Jacob From wk at gnupg.org Tue Oct 20 15:05:52 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Oct 2015 15:05:52 +0200 Subject: Fwd: Re: The --use-tor option In-Reply-To: (Jacob Appelbaum's message of "Tue, 20 Oct 2015 11:43:34 +0000") References: <56260A43.5090500@riseup.net> <87d1w9ojv5.fsf@vigenere.g10code.de> Message-ID: <87zizdn0zz.fsf@vigenere.g10code.de> On Tue, 20 Oct 2015 13:43, jacob at appelbaum.net said: > Will gnupg have a UseTor option for gpg.conf now? You will need to add "use-tor" to dirmngr.conf because dirmngr is now solely responsible for all network access. As soon as the DNS leak has been addressed that option will show upin the preference dialogs of GPA and Kleoptara (and possible more MUAs). > UseTor /path/to/unixsocket > UseTor 127.0.0.1:9050 I was not ware that there is a Unix Domain socket entry point to TOR. Anyway I implemented a fixed 127.0.0.1:9050 for now. > If GnuPG had Tor ControlPort integration, we could even generate Tor > Hidden Services automatically and use them together in smart ways with Its a few years since I ran a TOR node thus I have to read again about the control port. Pointers to concrete ideas? > I hope you'll also support the Unix Domain Socket SOCKS port that > we're now shipping with Tor (0.2.7.x and up, I think). That would mean > that gnupg could be entirely sandboxed from the internet and only able > to talk to the internet through Tor. Well, this could be added but there other high priority tasks. What is the concrete use case for the Unix Domain socket? With --use-tor dirmngr won't be able to connect to anything except the localhost - modulo bugs of course. > What else isn't proxy friendly in GnuPG? LDAP access to keyservers and CRLs. LDAP for keyserver is not a public service, so it does not make sense. CRL downloading introduces a web bug because the CRL distribution point is taken from the certifciate. More code is require to fix that. For now I think it is better to also disable HTTP access to CRLs. Salam-Shalom, Werner p.s I have just pushed my ADNS patches to http://git.gnupg.org/cgi-bin/gitweb.cgi?p=adns.git -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From twim at riseup.net Tue Oct 20 15:41:33 2015 From: twim at riseup.net (Ivan Markin) Date: Tue, 20 Oct 2015 13:41:33 +0000 Subject: Fwd: Re: The --use-tor option In-Reply-To: References: <56260A43.5090500@riseup.net> <87d1w9ojv5.fsf@vigenere.g10code.de> Message-ID: <5626448D.3070804@riseup.net> Jacob Appelbaum: > On 10/20/15, Werner Koch wrote: >> On Tue, 20 Oct 2015 11:32, twim at riseup.net said: >> >>> Why not just use torsocks [1]? There are any cons that I'm missing? >> >> Because it is hack for ELF based systems and does not work under >> Windows. Anyway it does not solve the real problem of leaking DNS. >> Recall that we need more than just AAAA records. > > torsocks is great, needed and useful but it is a hack around native > Tor integration as much as anything. Sad. I had a guess about Windows. For me it looks like we need some 'reference' implementation of this, a library (like Stem) to not to reimplement Tor support each time in each project, to be able to update app-Tor interaction for all apps at once by updating this library. In this way it should be torsocks-like. As far as I know, one can call pythonic Stem code from C. For instance, one can use C bindings to Stem to create HSes as well as run it in a client mode. > If GnuPG had Tor ControlPort integration, we could even generate Tor > Hidden Services automatically and use them together in smart ways with > GnuPG. 'Smart ways' sounds intriguing. What applications of 'client' Hidden Services in GnuPG do you mean? Or it's just for simplifying keyserver setup over Tor? -- Ivan Markin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Oct 20 15:43:27 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Oct 2015 09:43:27 -0400 Subject: Fwd: Re: The --use-tor option In-Reply-To: References: <56260A43.5090500@riseup.net> <87d1w9ojv5.fsf@vigenere.g10code.de> Message-ID: <87fv15irk0.fsf@alice.fifthhorseman.net> Hi Jacob-- On Tue 2015-10-20 07:43:34 -0400, Jacob Appelbaum wrote: > Will gnupg have a UseTor option for gpg.conf now? in modern GnuPG (2.1.x), all network access is handled by the dirmngr daemon. --use-tor is an option for dirmngr, so it will live in ~/.gnupg/dirmngr.conf. > If GnuPG had Tor ControlPort integration, we could even generate Tor > Hidden Services automatically and use them together in smart ways with > GnuPG. GnuPG has never offered any network services, so offering hidden services seems like a strict increase in attack surface. what network service are you imagining gpg would offer? > I hope you'll also support the Unix Domain Socket SOCKS port that > we're now shipping with Tor (0.2.7.x and up, I think). That would mean > that gnupg could be entirely sandboxed from the internet and only able > to talk to the internet through Tor. GnuPG 2.1 already only talks to the internet through dirmngr -- improvements to dirmngr are the way to go here :) It would also be great if someone wanted to write an apparmor or selinux profile that confined gpg to not be able to talk to the network at all. --dkg From simon at josefsson.org Tue Oct 20 16:34:26 2015 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 20 Oct 2015 16:34:26 +0200 Subject: The --use-tor option In-Reply-To: <87oafvqac8.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 19 Oct 2015 15:03:35 +0200") References: <87oafvqac8.fsf@vigenere.g10code.de> Message-ID: <87twpltxql.fsf@latte.josefsson.org> Werner Koch writes: > This is not complete because DNS lookups are leaking. This could be > fixed for some commands (like gpg --fetch-key URL) but that would be a > specialized solution. The more problematic areas are resolving of the > keyserver pools and retrieving of CERT and DANE records. Thus I did not > implemented the specialized case for --fetch-key. > > Given that it is not likely that we will seen generic DNS support in TOR > soon, we need to find our own solution. Using a public server via TCP > is probably the only thing we can do. This requires two thing: > > - Being able to specify a public DNS server independent of > /etc/resolv.conf. > > - Forcing the use of a virtual circuit (ie. TCP) so that TOR can route > the request. > > With the standard resolver this is not possible. Adding a full-fledged > resolver library to Dirmngr is overkill and we will likely run into > problems under Windows. My idea is to make use of the ADNS library. A > quick check showed that it is not too much work to add SOCKS5 support > (to access TOR) and a flag to enable this. Where would you get the IP address of the DNS server to use with ADNS? I recall discussions with Christian Grothoff about doing a small asynchronous library for "name resolution" that could resolv A, AAAA, CERT, DNAE etc records from DNS, or through other protocols too. The library would talk to a local daemon that performed the actual name resolution, over TOR, using gNS, or whatever. The admin could configure it to talk to a DNS server over TOR, or possibly each app could request special handling (like TOR routing). What do you think of this approach? > - Check with upstream ADNS whether adding SOCKS5 support and a TOR flag > would be accepted, develop that, and keep keep the APIs of my > (Windows) port and upstream in sync. This would be nice. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Oct 20 16:57:53 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Oct 2015 10:57:53 -0400 Subject: The --use-tor option In-Reply-To: <2331911.xffYaiXkJa@localhost> References: <87oafvqac8.fsf@vigenere.g10code.de> <2331911.xffYaiXkJa@localhost> Message-ID: <87wpuhh9ji.fsf@alice.fifthhorseman.net> On Mon 2015-10-19 10:54:49 -0400, Malte wrote: > On Monday 19 October 2015 15:03 Werner Koch wrote: > >> This is not complete because DNS lookups are leaking. This could be >> fixed [?] > > Maybe Kristian Fiskerstrand would be willing to set up an Onion Service for > the SKS-Pool that could be used by default? I don't think this makes much sense -- there are already keyservers that offer hidden services (e.g. qdigse2yzvuglcix.onion), but they are individual keyservers. providing a .onion frontend to the pool would be something very different. how would it work? would it just proxy connections to other members of the pool? if so, it's basically acting as a tor exit node, but a very specialized one. is this a good idea? or are you imagining it would do something different? --dkg From wk at gnupg.org Tue Oct 20 17:46:52 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Oct 2015 17:46:52 +0200 Subject: Fwd: Re: The --use-tor option In-Reply-To: <5626448D.3070804@riseup.net> (Ivan Markin's message of "Tue, 20 Oct 2015 13:41:33 +0000") References: <56260A43.5090500@riseup.net> <87d1w9ojv5.fsf@vigenere.g10code.de> <5626448D.3070804@riseup.net> Message-ID: <87oaftmtjn.fsf@vigenere.g10code.de> On Tue, 20 Oct 2015 15:41, twim at riseup.net said: > Sad. I had a guess about Windows. For me it looks like we need some > 'reference' implementation of this, a library (like Stem) to not to > reimplement Tor support each time in each project, to be able to update Accessing a SOCKS5 proxy (which is used to access tor) on the local machine is actually quite simple because you only need to replaces the connect call. We already do something more complicated for Windows (to emulate UnixDonain sockets). See below for the code Dirmngr uses (from Libassuan). It is pretty straightforward unless you have to integrate with non-blocking event driven code. Salam-Shalom, Werner === static int socks5_connect (assuan_context_t ctx, int sock, struct sockaddr *addr, socklen_t length) { int ret; /* struct sockaddr_in6 proxyaddr_in6; */ struct sockaddr_in proxyaddr_in; struct sockaddr *proxyaddr; size_t proxyaddrlen; struct sockaddr_in6 *addr_in6; struct sockaddr_in *addr_in; unsigned char buffer[22]; size_t buflen; /* memset (&proxyaddr_in6, 0, sizeof proxyaddr_in6); */ memset (&proxyaddr_in, 0, sizeof proxyaddr_in); /* Connect to local host. */ /* Fixme: First try to use IPv6. */ proxyaddr_in.sin_family = AF_INET; proxyaddr_in.sin_port = htons (tor_mode); proxyaddr_in.sin_addr.s_addr = htonl (INADDR_LOOPBACK); proxyaddr = (struct sockaddr *)&proxyaddr_in; proxyaddrlen = sizeof proxyaddr_in; ret = _assuan_connect (ctx, sock, proxyaddr, proxyaddrlen); if (ret) return ret; buffer[0] = 5; /* RFC-1928 VER field. */ buffer[1] = 1; /* NMETHODS */ buffer[2] = 0; /* Method: No authentication required. */ /* Negotiate method. */ ret = do_writen (ctx, sock, buffer, 3); if (ret) return ret; ret = do_readn (ctx, sock, buffer, 2); if (ret) return ret; if (buffer[0] != 5 || buffer[1] != 0 ) { /* Socks server returned wrong version or does not support our requested method. */ gpg_err_set_errno (ENOTSUP); /* Fixme: Is there a better errno? */ return -1; } /* Send request details (rfc-1928, 4). */ buffer[0] = 5; /* VER */ buffer[1] = 1; /* CMD = CONNECT */ buffer[2] = 0; /* RSV */ if (addr->sa_family == AF_INET6) { addr_in6 = (struct sockaddr_in6 *)addr; buffer[3] = 4; /* ATYP = IPv6 */ memcpy (buffer+ 4, &addr_in6->sin6_addr.s6_addr, 16); /* DST.ADDR */ memcpy (buffer+20, &addr_in6->sin6_port, 2); /* DST.PORT */ buflen = 22; } else { addr_in = (struct sockaddr_in *)addr; buffer[3] = 1; /* ATYP = IPv4 */ memcpy (buffer+4, &addr_in->sin_addr.s_addr, 4); /* DST.ADDR */ memcpy (buffer+8, &addr_in->sin_port, 2); /* DST.PORT */ buflen = 10; } ret = do_writen (ctx, sock, buffer, buflen); if (ret) return ret; ret = do_readn (ctx, sock, buffer, buflen); if (ret) return ret; if (buffer[0] != 5 || buffer[2] != 0 ) { /* Socks server returned wrong version or the reserved field is not zero. */ gpg_err_set_errno (EPROTO); return -1; } if (buffer[1]) { switch (buffer[1]) { case 0x01: /* general SOCKS server failure. */ gpg_err_set_errno (ENETDOWN); break; case 0x02: /* connection not allowed by ruleset. */ gpg_err_set_errno (EACCES); break; case 0x03: /* Network unreachable */ gpg_err_set_errno (ENETUNREACH); break; case 0x04: /* Host unreachable */ gpg_err_set_errno (EHOSTUNREACH); break; case 0x05: /* Connection refused */ gpg_err_set_errno (ECONNREFUSED); break; case 0x06: /* TTL expired */ gpg_err_set_errno (ETIMEDOUT); break; case 0x08: /* Address type not supported */ gpg_err_set_errno (EPROTONOSUPPORT); break; case 0x07: /* Command not supported */ default: gpg_err_set_errno (ENOTSUP); /* Fixme: Is there a better errno? */ } return -1; } /* FIXME: We have not way to store the actual address used by the server. */ return 0; } -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ijackson at chiark.greenend.org.uk Tue Oct 20 17:11:43 2015 From: ijackson at chiark.greenend.org.uk (Ian Jackson) Date: Tue, 20 Oct 2015 16:11:43 +0100 Subject: adns and TOR In-Reply-To: <87vba1n0nc.fsf@vigenere.g10code.de> References: <87vba1n0nc.fsf@vigenere.g10code.de> Message-ID: <22054.22959.951094.201969@chiark.greenend.org.uk> Werner Koch writes ("adns and TOR"): > [stuff] ... > With the standard resolver this is not possible. Adding a full-fledged > resolver library to Dirmngr is overkill and we will likely run into > problems under Windows. My idea is to make use of the ADNS library. A > quick check showed that it is not too much work to add SOCKS5 support > (to access TOR) and a flag to enable this. ... > Unfortunately back then the ADNS author did not liked the use of > autotools and was not genuinely interested in Windows support. I'm afraid that my enthusiasm for Windows support is still quite low. In particular, I definitely don't want to deal with libtool, nor with automake. > - Check with upstream ADNS whether adding SOCKS5 support and a TOR flag > would be accepted, develop that, and keep keep the APIs of my > (Windows) port and upstream in sync. I would prefer this. I'm hoping that we can reasonably quickly converge on an appropriate API for adns. I don't feel I understand the TOR constraints and architecture well enough to have a good opinion yet. So I am going to ask some questions which may seem foolish. > Meanwhile I implemented a Tor mode to my ADNS version: > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=adns.git;a=commit;h=56eef0afa4c01d2352f8b671a9b22405dc8119db I'm afraid this commit is very hard to read in your gitweb due to all the whitespace change noise. > Do you have an interest to add it to upstream or can we agree on > a flag value to be used for such a feature? I use this: I am not opposed to supporting SOCKS. But I don't understand why so much of this has to be done in adns. Can't SOCKS provide `connect' ? Is there not some library with the SOCKS protocol client ? > - adns_if_checkc_freq= 0x0300 /* consistency checks very frequently (slow!) */ > + adns_if_checkc_freq= 0x0300,/* consistency checks very frequently (slow!) */ > + adns_if_tormode= 0x1000 /* route all trafic via TOR. */ Also, I don't understand why it isn't better to use adns_init_strcfg. Do we want other random utilities, eg command line utilities, to be able to use the socksified adns ? And I don't understand why it is a good idea to teach adns about TOR rather than to have the next-layer-up TOR things know about that. But perhaps I don't understand how the TOR client software is structured. If you point me to something where I could do some reading, I'm happy to read up on it. Thanks, Ian. From malte at wk3.org Tue Oct 20 19:31:58 2015 From: malte at wk3.org (malte at wk3.org) Date: Tue, 20 Oct 2015 19:31:58 +0200 Subject: The --use-tor option In-Reply-To: <87wpuhh9ji.fsf@alice.fifthhorseman.net> References: <87oafvqac8.fsf@vigenere.g10code.de> <2331911.xffYaiXkJa@localhost> <87wpuhh9ji.fsf@alice.fifthhorseman.net> Message-ID: <144536231884.3214.3469580307642771155@solidarity.enteig.net> Quoting Daniel Kahn Gillmor (2015-10-20 16:57:53) > On Mon 2015-10-19 10:54:49 -0400, Malte wrote: > > On Monday 19 October 2015 15:03 Werner Koch wrote: > > > >> This is not complete because DNS lookups are leaking. This could be > >> fixed [?] > > > > Maybe Kristian Fiskerstrand would be willing to set up an Onion Service for > > the SKS-Pool that could be used by default? > > I don't think this makes much sense -- there are already keyservers that > offer hidden services (e.g. qdigse2yzvuglcix.onion), but they are > individual keyservers. Ok. Then let's use that one. My main concern was the DNS resolution problem. From jacob at appelbaum.net Tue Oct 20 19:44:04 2015 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Tue, 20 Oct 2015 17:44:04 +0000 Subject: The --use-tor option In-Reply-To: <87wpuhh9ji.fsf@alice.fifthhorseman.net> References: <87oafvqac8.fsf@vigenere.g10code.de> <2331911.xffYaiXkJa@localhost> <87wpuhh9ji.fsf@alice.fifthhorseman.net> Message-ID: On 10/20/15, Daniel Kahn Gillmor wrote: > On Mon 2015-10-19 10:54:49 -0400, Malte wrote: >> On Monday 19 October 2015 15:03 Werner Koch wrote: >> >>> This is not complete because DNS lookups are leaking. This could be >>> fixed [?] >> >> Maybe Kristian Fiskerstrand would be willing to set up an Onion Service >> for >> the SKS-Pool that could be used by default? > > I don't think this makes much sense -- there are already keyservers that > offer hidden services (e.g. qdigse2yzvuglcix.onion), but they are > individual keyservers. > > providing a .onion frontend to the pool would be something very > different. how would it work? would it just proxy connections to other > members of the pool? if so, it's basically acting as a tor exit node, > but a very specialized one. is this a good idea? > It would be possible to use OnionBalance here - someone can run a popular .onion and add all of the SKS servers with .onions into that instance of Onion balance. Thus - a single .onion name can redirect entirely within Tor to every individual SKS server that has a .onion name/Hidden Service. > or are you imagining it would do something different? It would be great if we shipped some .onion SKS servers that work with Tor by default - not so different than shipping the SKS server pool by default. All the best, Jacob From twim at riseup.net Tue Oct 20 20:09:51 2015 From: twim at riseup.net (Ivan Markin) Date: Tue, 20 Oct 2015 18:09:51 +0000 Subject: Fwd: Re: The --use-tor option In-Reply-To: <87oaftmtjn.fsf@vigenere.g10code.de> References: <56260A43.5090500@riseup.net> <87d1w9ojv5.fsf@vigenere.g10code.de> <5626448D.3070804@riseup.net> <87oaftmtjn.fsf@vigenere.g10code.de> Message-ID: <5626836F.7020709@riseup.net> Werner Koch: >> Sad. I had a guess about Windows. For me it looks like we need some >> > 'reference' implementation of this, a library (like Stem) to not to >> > reimplement Tor support each time in each project, to be able to update > Accessing a SOCKS5 proxy (which is used to access tor) on the local > machine is actually quite simple because you only need to replaces the > connect call. We already do something more complicated for Windows (to > emulate UnixDonain sockets). See below for the code Dirmngr uses (from > Libassuan). It is pretty straightforward unless you have to integrate > with non-blocking event driven code. What I'm trying to say is that you're dealing with IPv4/IPv6-addressess, trying to resolve domain names, etc in your code. When you delegate this stuff to some library your code becomes platform independent and easier to maintain. So this pluggable network module could be anything (ClearNet/Tor/i2p/whatever). This module should know how to resolve hostnames and should do it in its own way - an application just passes some data to "hostname" (no matter what does this "hostname" mean and how to resolve it). -- Ivan Markin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Oct 20 20:11:40 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Oct 2015 14:11:40 -0400 Subject: The --use-tor option In-Reply-To: <144536231884.3214.3469580307642771155@solidarity.enteig.net> References: <87oafvqac8.fsf@vigenere.g10code.de> <2331911.xffYaiXkJa@localhost> <87wpuhh9ji.fsf@alice.fifthhorseman.net> <144536231884.3214.3469580307642771155@solidarity.enteig.net> Message-ID: <87r3kpjtpf.fsf@alice.fifthhorseman.net> On Tue 2015-10-20 13:31:58 -0400, malte at wk3.org wrote: > Quoting Daniel Kahn Gillmor (2015-10-20 16:57:53) >> On Mon 2015-10-19 10:54:49 -0400, Malte wrote: >> > On Monday 19 October 2015 15:03 Werner Koch wrote: >> > >> >> This is not complete because DNS lookups are leaking. This could be >> >> fixed [?] >> > >> > Maybe Kristian Fiskerstrand would be willing to set up an Onion Service for >> > the SKS-Pool that could be used by default? >> >> I don't think this makes much sense -- there are already keyservers that >> offer hidden services (e.g. qdigse2yzvuglcix.onion), but they are >> individual keyservers. > > Ok. Then let's use that one. My main concern was the DNS resolution > problem. Well, that's just one individual keyserver. If you configure that one and it dies you've gotta change your settings. A pool has the usual advantages of failover, etc. Given that hidden services have the name bound to the public key, i'm not sure how you'd operate a hidden service pool without sharing the associated secret key among all hosts. Has anyone done any research on high-availability hidden services? --dkg From jacob at appelbaum.net Tue Oct 20 20:27:49 2015 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Tue, 20 Oct 2015 18:27:49 +0000 Subject: The --use-tor option In-Reply-To: <87r3kpjtpf.fsf@alice.fifthhorseman.net> References: <87oafvqac8.fsf@vigenere.g10code.de> <2331911.xffYaiXkJa@localhost> <87wpuhh9ji.fsf@alice.fifthhorseman.net> <144536231884.3214.3469580307642771155@solidarity.enteig.net> <87r3kpjtpf.fsf@alice.fifthhorseman.net> Message-ID: On 10/20/15, Daniel Kahn Gillmor wrote: > On Tue 2015-10-20 13:31:58 -0400, malte at wk3.org wrote: >> Quoting Daniel Kahn Gillmor (2015-10-20 16:57:53) >>> On Mon 2015-10-19 10:54:49 -0400, Malte wrote: >>> > On Monday 19 October 2015 15:03 Werner Koch wrote: >>> > >>> >> This is not complete because DNS lookups are leaking. This could be >>> >> fixed [?] >>> > >>> > Maybe Kristian Fiskerstrand would be willing to set up an Onion Service >>> > for >>> > the SKS-Pool that could be used by default? >>> >>> I don't think this makes much sense -- there are already keyservers that >>> offer hidden services (e.g. qdigse2yzvuglcix.onion), but they are >>> individual keyservers. >> >> Ok. Then let's use that one. My main concern was the DNS resolution >> problem. > > Well, that's just one individual keyserver. If you configure that one > and it dies you've gotta change your settings. A pool has the usual > advantages of failover, etc. > > Given that hidden services have the name bound to the public key, i'm > not sure how you'd operate a hidden service pool without sharing the > associated secret key among all hosts. Has anyone done any research on > high-availability hidden services? Yeah - the best person in the world is Donncha. I've cc'ed him. He wrote OnionBalance. Source: https://github.com/DonnchaC/onionbalance Documentation: https://onionbalance.readthedocs.org In short: one .onion name can be used to load balance over many other .onions run by many other people. The main .onion does not need access to the private key of the other onions. We could have ten SKS servers each with their own .onion {{0-9}.onion} name and then one .onion shipped with GnuPG, for example. We could even have a dozen such names in GnuPG each backed by ~10 .onions, for example. The nice thing about a .onion name is that it means that a service can be hidden behind a NAT - it makes a name end to end encrypted, geographically anonymized and *reachable* as long as the Tor client providing the name is able to get online. Hooray, lots of problems solved! New problems coming up soon enough! All the best, Jacob From aheinecke at intevation.de Tue Oct 20 19:46:23 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 20 Oct 2015 19:46:23 +0200 Subject: TOFU code available In-Reply-To: <8737x89kit.wl-neal@walfield.org> References: <87oagi9tm1.wl-neal@walfield.org> <8737x89kit.wl-neal@walfield.org> Message-ID: <3708391.A5zfnRD9AI@esus> Hi, On Sunday 18 October 2015 19:03:22 Neal H. Walfield wrote: > I've now pushed the TOFU code to master. It will be part of the next > release. It would be great to get some feedback on it. I've tried this out today. My observations in this mail are based on rev. 26d457c Using trust model "tofu+pgp": - Binding problems occured with my own keys (having multiple UId's on different keys). I find it strange that I am asked if one of my own keys is "Good". I would suggest that you can just assume an answer of "Good" in case the key is signed by a key with ultimate trust or is itself ultimately trusted. - When running multiple keylists in parallel (Happens when Kleopatra is running) after activating tofu-pgp trust model and running the first keylisting leads to some errors. (We've talked about this on jabber already) - The performance of the initial tofu db build is quite bad. One of your changes today roughly doubled the time I currently need to build the inititial tofu db. After removing the tofu.d the first keylisting now takes about 45 seconds. I think this needs some profiling and optimization as that's with a homedir on a SSD with an i7 2600k CPU and a keyring with "just" 615 keys. - In KMail / with Kleopatra messages signed with previously unknown keys are shown as a good (green) signature with the details: The signature is valid and the key is marginally trusted. (Btw. I think that trust is the wrong word here but that's unrelated as this is KMail internal ;-) ) While this appears basically Ok to me. This is probably too little information. But I think it could work (without changes to KMail or Kleopatra neccessary) if we would implement gpgme getauditlog for OpenPGP and fill it with the tofu statistics shown on the command line. More detailed verify information for OpenPGP as part of the Auditlog is something we already have our TODO list for the Gpg4all project. So we could probably add tofu details as part of that work? KMail / Kleo both already query gpgme for an auditlog for every verification and should make it available when it is available. I've not yet tested what happens in case of conflicts where the command line would ask questions. Maybe bring up a pinentry prompt for that? Regards, Andre P.S. While I'm pointing out the negative things I noticed in general I'm very happy that Tofu is moving forward. :) -- 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: 181 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Oct 20 21:12:05 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Oct 2015 21:12:05 +0200 Subject: adns and TOR In-Reply-To: <22054.22959.951094.201969@chiark.greenend.org.uk> (Ian Jackson's message of "Tue, 20 Oct 2015 16:11:43 +0100") References: <87vba1n0nc.fsf@vigenere.g10code.de> <22054.22959.951094.201969@chiark.greenend.org.uk> Message-ID: <87h9llmk1m.fsf@vigenere.g10code.de> On Tue, 20 Oct 2015 17:11, ijackson at chiark.greenend.org.uk said: > I'm afraid that my enthusiasm for Windows support is still quite low. > In particular, I definitely don't want to deal with libtool, nor with Well, well, I keep my own version for Windows. > I'm afraid this commit is very hard to read in your gitweb due to all > the whitespace change noise. Sorry, I forgot to do a separate commit when adding the --use-tor option to adnshost. The other chnages are easier to read. The bulk of changes is in event.c > I am not opposed to supporting SOCKS. But I don't understand why so > much of this has to be done in adns. Can't SOCKS provide `connect' ? > Is there not some library with the SOCKS protocol client ? I think there are libraries but - they are overkill because we do not need to implement any SOCKS authenticatian method, - probably won't fit into ADNS event driven model, - adds an other dependency. SOCKS dates back to 1992 and the SOCKS5 version is desrcibed in RFC-1928 from 1996. SOCKS is a pretty simple protocol: - connect to the proxy (localhost:9050 for Tor) - send hello with requested authenitcation methods (non for us) - read response from the proxy (bascially ACK or NACK) - send a data block with port and address to the proxy - read response from proxy with status code (okay or connection failed) - do your work with the server (proxy won't interrupt you anymore) > Also, I don't understand why it isn't better to use adns_init_strcfg. > Do we want other random utilities, eg command line utilities, to be > able to use the socksified adns ? You mean a new option? Makes sense to me. AFAICS, those options set an adns_if flag anyway. My current GnuPG configure checks whether that flag is in adns.h to decide whether Tor support will be possible. A function to ask for that at runtime would of course be safer. > And I don't understand why it is a good idea to teach adns about TOR > rather than to have the next-layer-up TOR things know about that. > But perhaps I don't understand how the TOR client software is > structured. If you point me to something where I could do some Tor is more than a HTTP proxy so you can't use the standard http_proxy thing. Tor allows to relay all *TCP* traffic. To accomplish this you send all your traffic via SOCKS. The problem is that the Tor server and the network has only limited capabilities for DNS. It would be much cooler if we could ask TOR to retrieve arbitrary RRs but that has not been implemented. Thus the hack to force the use of TCP for name resolution and to route this over Tor to a public resolver. Yes, Google can easily manipulate the DNS - it is not safe but that is a different story. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Oct 20 21:18:01 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Oct 2015 21:18:01 +0200 Subject: The --use-tor option In-Reply-To: <87twpltxql.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 20 Oct 2015 16:34:26 +0200") References: <87oafvqac8.fsf@vigenere.g10code.de> <87twpltxql.fsf@latte.josefsson.org> Message-ID: <87d1w9mjrq.fsf@vigenere.g10code.de> On Tue, 20 Oct 2015 16:34, simon at josefsson.org said: > Where would you get the IP address of the DNS server to use with ADNS? 8.8.8.8 A --nameserver option to be used in dirmngr.conf will obviously be added. > I recall discussions with Christian Grothoff about doing a small > asynchronous library for "name resolution" that could resolv A, AAAA, > CERT, DNAE etc records from DNS, or through other protocols too. The ADNS is such a library. Christian's problem is that he needs LGPLed code. ADNS is GPL which is fine for GnuPG. > library would talk to a local daemon that performed the actual name > resolution, over TOR, using gNS, or whatever. The admin could configure > it to talk to a DNS server over TOR, or possibly each app could request > special handling (like TOR routing). He could also use dirmngr to ask for such records. CERT, PKA and DANE are already supported and I would also like to add GNS support to access them. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Oct 20 21:35:39 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Oct 2015 21:35:39 +0200 Subject: Fwd: Re: The --use-tor option In-Reply-To: <5626836F.7020709@riseup.net> (Ivan Markin's message of "Tue, 20 Oct 2015 18:09:51 +0000") References: <56260A43.5090500@riseup.net> <87d1w9ojv5.fsf@vigenere.g10code.de> <5626448D.3070804@riseup.net> <87oaftmtjn.fsf@vigenere.g10code.de> <5626836F.7020709@riseup.net> Message-ID: <878u6xmiyc.fsf@vigenere.g10code.de> On Tue, 20 Oct 2015 20:09, twim at riseup.net said: > What I'm trying to say is that you're dealing with IPv4/IPv6-addressess, > trying to resolve domain names, etc in your code. When you delegate Need to do that to better handle the keyservers in the pools. Without that feature a dead keyserver cannot be detected or replaced by a different one. > this stuff to some library your code becomes platform independent and > easier to maintain. So this pluggable network module could be anything That is called dirmmgr ;-). You can even script that $ gpg-connect-agent --dirmngr \ '/datafile -' 'dns_cert --dane wk at gnupg.org' /bye >1e42b367.pub Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Oct 20 22:36:57 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Oct 2015 22:36:57 +0200 Subject: TOFU code available In-Reply-To: <3708391.A5zfnRD9AI@esus> (Andre Heinecke's message of "Tue, 20 Oct 2015 19:46:23 +0200") References: <87oagi9tm1.wl-neal@walfield.org> <8737x89kit.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> Message-ID: <87twpll1jq.fsf@vigenere.g10code.de> On Tue, 20 Oct 2015 19:46, aheinecke at intevation.de said: > KMail / Kleo both already query gpgme for an auditlog for every verification > and should make it available when it is available. I think we can re-use this interface for such informtation. A new flag value is required. The implementation problem is that it works only with gpgsm. For gpg we need to do a gpg/gpgme hack until we have changed gpg to work as a co-process. > I've not yet tested what happens in case of conflicts where the command line > would ask questions. Maybe bring up a pinentry prompt for that? Nope. We should not overload the Pinentry with functions it is not designed for. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From twim at riseup.net Tue Oct 20 23:55:07 2015 From: twim at riseup.net (Ivan Markin) Date: Tue, 20 Oct 2015 21:55:07 +0000 Subject: Fwd: Re: The --use-tor option In-Reply-To: <878u6xmiyc.fsf@vigenere.g10code.de> References: <56260A43.5090500@riseup.net> <87d1w9ojv5.fsf@vigenere.g10code.de> <5626448D.3070804@riseup.net> <87oaftmtjn.fsf@vigenere.g10code.de> <5626836F.7020709@riseup.net> <878u6xmiyc.fsf@vigenere.g10code.de> Message-ID: <5626B83B.3010708@riseup.net> Werner Koch: > On Tue, 20 Oct 2015 20:09, twim at riseup.net said: > >> What I'm trying to say is that you're dealing with IPv4/IPv6-addressess, >> trying to resolve domain names, etc in your code. When you delegate > > Need to do that to better handle the keyservers in the pools. Without > that feature a dead keyserver cannot be detected or replaced by a > different one. I didn't mean that you should eliminate all of this code :). For me it's sounds reasonable to move this code to a 'clearnet' module. For a 'tor' module there will be different code to manage keyservers in the pools. Like Jacob said before, in Tor case it can be OnionBalance to manage keyservers. To test availability at least you can fetch HS descriptor and look at the "current-time" and "time-period" fields. In case of 'network modules', you'll use Tor on high level and be able to add keyserver management/keyserver setup on top of it. [I confess that there are no Stem bindings. Yet] >> this stuff to some library your code becomes platform independent and >> easier to maintain. So this pluggable network module could be anything > > That is called dirmmgr ;-). You can even script that > > $ gpg-connect-agent --dirmngr \ > '/datafile -' 'dns_cert --dane wk at gnupg.org' /bye >1e42b367.pub dirmngr is too GnuPG-specific, so I can't use it for my chat app for example. What is reason to reimplement it for each app (I mean what you're going to implement :) )? btw, this script doen't work for me. -- Ivan Markin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From bjk at luxsci.net Wed Oct 21 01:59:34 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Tue, 20 Oct 2015 19:59:34 -0400 Subject: [PATCH] Check for GPG_TTY as well as DISPLAY. Message-ID: <1445385603-3678688.75890528.ft9KNxZWg007079@rs146.luxsci.com> Hello, There doesn't seem to be a way to set the tty for a pinentry to prompt on in gpgme if isatty() fails (daemon process). This patch uses the GPG_TTY environment variable as the value of --ttyname when set, and the value of ttyname_r() if not. OK to push? -- Ben Kibbey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Check-for-GPG_TTY-as-well-as-DISPLAY.patch Type: text/x-diff Size: 6017 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Oct 21 12:02:05 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 21 Oct 2015 12:02:05 +0200 Subject: The --use-tor option In-Reply-To: References: <87oafvqac8.fsf@vigenere.g10code.de> <2331911.xffYaiXkJa@localhost> <87wpuhh9ji.fsf@alice.fifthhorseman.net> Message-ID: <5627629D.2060605@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/20/2015 07:44 PM, Jacob Appelbaum wrote: > On 10/20/15, Daniel Kahn Gillmor wrote: >> On Mon 2015-10-19 10:54:49 -0400, Malte wrote: >>> On Monday 19 October 2015 15:03 Werner Koch wrote: >>> >>>> This is not complete because DNS lookups are leaking. This >>>> could be fixed [?] >>> >>> Maybe Kristian Fiskerstrand would be willing to set up an Onion >>> Service for the SKS-Pool that could be used by default? >> >> I don't think this makes much sense -- there are already >> keyservers that offer hidden services (e.g. >> qdigse2yzvuglcix.onion), but they are individual keyservers. >> >> providing a .onion frontend to the pool would be something very >> different. how would it work? would it just proxy connections >> to other members of the pool? if so, it's basically acting as a >> tor exit node, but a very specialized one. is this a good idea? >> > > It would be possible to use OnionBalance here - someone can run a > popular .onion and add all of the SKS servers with .onions into > that instance of Onion balance. Thus - a single .onion name can > redirect entirely within Tor to every individual SKS server that > has a .onion name/Hidden Service. > Thanks for this pointer, I'm not too familiar with it (and frankly Tor in general) and busy with real life atm, but will try to read up a bit and see if it is something that can be of interest later this week - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Uxor formosa et vinum sunt dulcia venena Beautiful women and wine are sweet venom -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJWJ2KKAAoJECULev7WN52FEMsH/jFQD9w3MNMd7xZ7Od6ON5AN c9Yc7jvwN3n6KBf/hWvo3LhJZaGMY6X0b9p4RPxo5ozvvij58r1B0N2iF02Rz3yP sp/uFqG1J+03nEXfAa1EOraIPfrlWVv00RLbFU6EUtTEU1EVDVLG0icgxUSQNyPv c+dWPPsrof93wuLdA5Cf9gvBUdN26koOkdlxUy14Quayy2tcnwmoERUxoJZqlbIS svUJcLht6Jde/nA+Vhx6THEAax1gG2t6GvSg5augCJ4fEtVmuPXBPVAwRlq+QAnI 3+plzXnIBrsrum4svgsRUxCUagG5QUUaHcQ0tQTQuePmBJxKz+L2WQw8tTAF6is= =w0qy -----END PGP SIGNATURE----- From ijackson at chiark.greenend.org.uk Wed Oct 21 13:29:10 2015 From: ijackson at chiark.greenend.org.uk (Ian Jackson) Date: Wed, 21 Oct 2015 12:29:10 +0100 Subject: adns and TOR In-Reply-To: <87h9llmk1m.fsf@vigenere.g10code.de> References: <87vba1n0nc.fsf@vigenere.g10code.de> <22054.22959.951094.201969@chiark.greenend.org.uk> <87h9llmk1m.fsf@vigenere.g10code.de> Message-ID: <22055.30470.407246.973906@chiark.greenend.org.uk> Werner Koch writes ("Re: adns and TOR"): > On Tue, 20 Oct 2015 17:11, ijackson at chiark.greenend.org.uk said: > > I am not opposed to supporting SOCKS. But I don't understand why so > > much of this has to be done in adns. Can't SOCKS provide `connect' ? > > Is there not some library with the SOCKS protocol client ? > > I think there are libraries but > > - they are overkill because we do not need to implement any > SOCKS authenticatian method, > - probably won't fit into ADNS event driven model, > - adds an other dependency. These are fairly convincing reasons. I don't fancy trying to break out asynchronous SOCKS support into its own library at this stage, which is what the alternative would probably look like. > > Also, I don't understand why it isn't better to use adns_init_strcfg. > > Do we want other random utilities, eg command line utilities, to be > > able to use the socksified adns ? > > You mean a new option? Makes sense to me. AFAICS, those options set an > adns_if flag anyway. My current GnuPG configure checks whether that > flag is in adns.h to decide whether Tor support will be possible. A > function to ask for that at runtime would of course be safer. I mean a textual config option in the config file (the resolv.conf, which adns lets you provide a different one of). To use the TOR resolver you're going to have to specify nameservers anyway, so you already have a custom resolv.conf, presumably. The init flags are for properties of the application's interaction with the adns API, not really for how to configure where DNS data comes from. The latter is defined in the config file. > > And I don't understand why it is a good idea to teach adns about TOR > > rather than to have the next-layer-up TOR things know about that. > > But perhaps I don't understand how the TOR client software is > > structured. If you point me to something where I could do some > > Tor is more than a HTTP proxy so you can't use the standard http_proxy > thing. Tor allows to relay all *TCP* traffic. To accomplish this you > send all your traffic via SOCKS. The problem is that the Tor server and > the network has only limited capabilities for DNS. It would be much > cooler if we could ask TOR to retrieve arbitrary RRs but that has not > been implemented. Thus the hack to force the use of TCP for name > resolution and to route this over Tor to a public resolver. Yes, Google > can easily manipulate the DNS - it is not safe but that is a different > story. Right. I guess I meant: is it intended that every application program which one might want to use to access a TOR service would have to be patched to know about TOR, specifically ? That seems like it would be a pain. Surely it would be better to allow use of any SOCKSified application. But I don't know how SOCKS is usually configured. How do you normally tell a SOCKSified client program where to find its SOCKS server ? (For that matter, in the TOR context, how do you tell an application to use a different resolver?) Regards, Ian. From aheinecke at intevation.de Wed Oct 21 13:29:20 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 21 Oct 2015 13:29:20 +0200 Subject: TOFU code available In-Reply-To: <87twpll1jq.fsf@vigenere.g10code.de> References: <87oagi9tm1.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87twpll1jq.fsf@vigenere.g10code.de> Message-ID: <4204042.BDtm6V7NUR@esus> Hi, On Tuesday 20 October 2015 22:36:57 Werner Koch wrote: > On Tue, 20 Oct 2015 19:46, aheinecke at intevation.de said: > > I've not yet tested what happens in case of conflicts where the command > > line would ask questions. Maybe bring up a pinentry prompt for that? > > Nope. We should not overload the Pinentry with functions it is not > designed for. I think it makes sense though. We already have pinentry asking for Root Certificate trust in S/MIME and imo the TOFU questions fall in the same category. It's just a dialog with a question and some options. Some advantages I see: - User visible strings would all be in GnuPG itself. (And thus unified and centrally l10n'ed) And the same as in the CLI. - It would be controlled by GnuPG. If there are changes they are always in line with the GnuPG version. - No need for a complex protocol to handle these interactions through gpgme. And there would be no need to adapt existing MUA's :-) 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: 181 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Wed Oct 21 13:58:02 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 21 Oct 2015 13:58:02 +0200 Subject: TOFO trust model should recognize ultimately trusted keys In-Reply-To: <3708391.A5zfnRD9AI@esus> References: <87oagi9tm1.wl-neal@walfield.org> <8737x89kit.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> Message-ID: <87wpug8md1.wl-neal@walfield.org> Hi Andre, Thanks for the feedback and your help with debugging yesterday! At Tue, 20 Oct 2015 19:46:23 +0200, Andre Heinecke wrote: > On Sunday 18 October 2015 19:03:22 Neal H. Walfield wrote: > Using trust model "tofu+pgp": > > - Binding problems occured with my own keys (having multiple UId's on different > keys). I find it strange that I am asked if one of my own keys is "Good". I > would suggest that you can just assume an answer of "Good" in case the key is > signed by a key with ultimate trust or is itself ultimately trusted. I've checked in some code so that both the tofu and the tofu+pgp models will recognize ultimately trusted keys as good. I don't think the TOFU model should consider signatures at all. This is what the pgp part of the tofu+pgp model is for. Thanks! Neal From jacob at appelbaum.net Wed Oct 21 14:05:26 2015 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Wed, 21 Oct 2015 12:05:26 +0000 Subject: adns and TOR In-Reply-To: <22055.30470.407246.973906@chiark.greenend.org.uk> References: <87vba1n0nc.fsf@vigenere.g10code.de> <22054.22959.951094.201969@chiark.greenend.org.uk> <87h9llmk1m.fsf@vigenere.g10code.de> <22055.30470.407246.973906@chiark.greenend.org.uk> Message-ID: On 10/21/15, Ian Jackson wrote: > Werner Koch writes ("Re: adns and TOR"): >> On Tue, 20 Oct 2015 17:11, ijackson at chiark.greenend.org.uk said: >> > I am not opposed to supporting SOCKS. But I don't understand why so >> > much of this has to be done in adns. Can't SOCKS provide `connect' ? >> > Is there not some library with the SOCKS protocol client ? >> >> I think there are libraries but >> >> - they are overkill because we do not need to implement any >> SOCKS authenticatian method, >> - probably won't fit into ADNS event driven model, >> - adds an other dependency. > > These are fairly convincing reasons. I don't fancy trying to break > out asynchronous SOCKS support into its own library at this stage, > which is what the alternative would probably look like. Authentication is actually important for Tor but not for obvious reasons. We use it to signal that we'd like a new Tor circuit. A freshly generated (random) username and password would signal to Tor to not attach the SOCKS TCP stream to any current circuit. This is an important thing to consider - do you want to download your keyring updates all on a single circuit? Perhaps? Perhaps not? > >> > Also, I don't understand why it isn't better to use adns_init_strcfg. >> > Do we want other random utilities, eg command line utilities, to be >> > able to use the socksified adns ? >> >> You mean a new option? Makes sense to me. AFAICS, those options set an >> adns_if flag anyway. My current GnuPG configure checks whether that >> flag is in adns.h to decide whether Tor support will be possible. A >> function to ask for that at runtime would of course be safer. > > I mean a textual config option in the config file (the resolv.conf, > which adns lets you provide a different one of). To use the TOR > resolver you're going to have to specify nameservers anyway, so you > already have a custom resolv.conf, presumably. > > The init flags are for properties of the application's interaction > with the adns API, not really for how to configure where DNS data > comes from. The latter is defined in the config file. > >> > And I don't understand why it is a good idea to teach adns about TOR >> > rather than to have the next-layer-up TOR things know about that. >> > But perhaps I don't understand how the TOR client software is >> > structured. If you point me to something where I could do some >> >> Tor is more than a HTTP proxy so you can't use the standard http_proxy >> thing. Tor allows to relay all *TCP* traffic. To accomplish this you >> send all your traffic via SOCKS. The problem is that the Tor server and >> the network has only limited capabilities for DNS. It would be much >> cooler if we could ask TOR to retrieve arbitrary RRs but that has not >> been implemented. Thus the hack to force the use of TCP for name >> resolution and to route this over Tor to a public resolver. Yes, Google >> can easily manipulate the DNS - it is not safe but that is a different >> story. > > Right. > Please read our specs in your free time: https://gitweb.torproject.org/torspec.git > I guess I meant: is it intended that every application program which > one might want to use to access a TOR service would have to be patched > to know about TOR, specifically ? Tor, not TOR. Also - if you want to connect to a .onion (eg: our soon to be published RFC 7686) - you need to use a proxy that supports it OR you need an OS that transparently routes TCP traffic into that proxy. If you're not using SOCKS5 (or SOCKS4a) then you're going to have trouble resolving .onion names - please see RFC 7686 in the next few days for more details or read our draft: https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ > That seems like it would be a pain. Surely it would be better to > allow use of any SOCKSified application. That is generally how things are done - but SOCKS doesn't really solve all of the issues as Werner has explained. We don't proxy UDP - we have a minimal resolver available over a SOCKS4a/SOCKS5 interface. > > But I don't know how SOCKS is usually configured. How do you normally > tell a SOCKSified client program where to find its SOCKS server ? > Generally, you'd tell it the Unix Domain Socket ( /var/lib/tor/sockssocket ) or IP address and port number (eg: 127.0.0.1:9050 ), a username/passsword (which can be anything, see torspec). > (For that matter, in the TOR context, how do you tell an application > to use a different resolver?) Generally speaking - an application should be made Tor aware - otherwise you have a problem of something like making local DNS requests to the local resolver, which leak information about a user's behavior, then the resolved IP is passed via SOCKS to Tor. If one has this split in an application, it means a local censor can poison your DNS and Tor will helpfully connect you to their block page. In the Tor Browser, we configure everything to work properly by default. With a package like torsocks, LD_PRELOAD is used to overload unsafe functions that would leak or violate your privacy, etc. If you have some specific applications in mind, I can try to explain how to Torify them or explain why it may not be possible (eg: it uses UDP and SCTP exclusively). All the best, Jacob From neal at walfield.org Wed Oct 21 14:36:07 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 21 Oct 2015 14:36:07 +0200 Subject: TOFU performance / DB format In-Reply-To: <3708391.A5zfnRD9AI@esus> References: <87oagi9tm1.wl-neal@walfield.org> <8737x89kit.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> Message-ID: <87vba08klk.wl-neal@walfield.org> At Tue, 20 Oct 2015 19:46:23 +0200, Andre Heinecke wrote: > - The performance of the initial tofu db build is quite bad. > One of your changes today roughly doubled the time I currently need to build > the inititial tofu db. After removing the tofu.d the first keylisting now takes > about 45 seconds. > I think this needs some profiling and optimization as that's with a homedir on > a SSD with an i7 2600k CPU and a keyring with "just" 615 keys. I wonder if the slow down is due to 26d457c2, which causes the code to retry a few times instead of immediately abort if the database is locked. (Was Kleopatra running in the background performing key listings?) As we also spoke about on jabber, there are two database formats: the split format and the flat format. The split format, which is currently the default, uses one DB per email and key. So in your case, you're looking at potentially a few thousand small files and the cost of sqlite setting up the initial data structures in each one and opening and closing the DBs. The flat format uses a single file and is, as you observed on jabber, about 20 times faster. The split and flat formats offer a trade-off. The flat format is faster. The split format is more amenable to two-way synchronization (e.g., Union). If you don't use GnuPG on multiple computers or don't care about keeping your TOFU DBs synchronized, then using the flat format is the way to go. Currently, there is no tool to convert between the two, but it should be a problem to write such a tool. In fact, it might make sense to write a tool that merges multiple DBs. Do you have any thoughts about this? Thanks! :) Neal From neal at walfield.org Wed Oct 21 15:15:30 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 21 Oct 2015 15:15:30 +0200 Subject: TOFU: showing statistics is important In-Reply-To: <3708391.A5zfnRD9AI@esus> References: <87oagi9tm1.wl-neal@walfield.org> <8737x89kit.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> Message-ID: <87twpk8irx.wl-neal@walfield.org> Hi Andre, At Tue, 20 Oct 2015 19:46:23 +0200, Andre Heinecke wrote: > - In KMail / with Kleopatra messages signed with previously unknown keys are > shown as a good (green) signature with the details: Green should mean that not only is the signature correct, but the key is fully trusted (manually verified). If the signature is correct but the key hasn't been verified (e.g., marginal) then it should be yellow and a tooltip should explain (or provide a link explaining) how to verify the key. > The signature is valid and the key is marginally trusted. > > (Btw. I think that trust is the wrong word here but that's unrelated as this > is KMail internal ;-) ) > > While this appears basically Ok to me. This is probably too little > information. But I think it could work (without changes to KMail or Kleopatra > neccessary) if we would implement gpgme getauditlog for OpenPGP and fill it > with the tofu statistics shown on the command line. > More detailed verify information for OpenPGP as part of the Auditlog is > something we already have our TODO list for the Gpg4all project. So we could > probably add tofu details as part of that work? It is essential that the statistics be shown to the user. There is an important difference between how TOFU works with OpenPGP and how it works with ssh. In ssh, the user enters the hostname. In OpenPGP, the attacker controls the user id. Since TOFU security measure is to identify and warn users of conflicts (multiple keys using the same email address), an attacker can just choose a different email address. To make this more difficult, we display the email address. If it is obviously wrong, the user will hopefully notice. (Note: email clients should also display a warning if the sender doesn't match a signer. AFAIU, only Claws and KMail does this.) This forces the attacker to choose a similarly looking email address. To mitigate this attack, we show statistics about the number of messages that we've seen that are signed by the binding. Further, if this number is low (< 10), we also display a warning message. If this is unexpectedly low, the user will hopefully become suspicious. So, yes, you are right, the audit log should contain the TOFU output. Thanks! :) Neal From aheinecke at intevation.de Wed Oct 21 15:32:05 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 21 Oct 2015 15:32:05 +0200 Subject: TOFU performance / DB format In-Reply-To: <87vba08klk.wl-neal@walfield.org> References: <87oagi9tm1.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87vba08klk.wl-neal@walfield.org> Message-ID: <4769117.He9oYshJPS@esus> Hi Neal, On Wednesday 21 October 2015 14:36:07 Neal H. Walfield wrote: > At Tue, 20 Oct 2015 19:46:23 +0200, > > Andre Heinecke wrote: > > - The performance of the initial tofu db build is quite bad. > > One of your changes today roughly doubled the time I currently need to > > build the inititial tofu db. After removing the tofu.d the first > > keylisting now takes about 45 seconds. > > I think this needs some profiling and optimization as that's with a > > homedir on a SSD with an i7 2600k CPU and a keyring with "just" 615 keys. > > I wonder if the slow down is due to 26d457c2, which causes the code to > retry a few times instead of immediately abort if the database is > locked. (Was Kleopatra running in the background performing key > listings?) Kleopatra was not running. > As we also spoke about on jabber, there are two database formats: the > split format and the flat format. > > The split format, which is currently the default, uses one DB per > email and key. So in your case, you're looking at potentially a few > thousand small files and the cost of sqlite setting up the initial > data structures in each one and opening and closing the DBs. I am a bit unwilling to believe that this is really that expensive. I mean a clean build of gnupg on this system takes only 20 seconds. And that also involves a lot of calculations and thousands of files ;-) > The flat format uses a single file and is, as you observed on jabber, > about 20 times faster. That was a misunderstanding then. The 20 times speedup was between the first and the second run of gpg2 -k flat / split both were at around 20sec. Here are some more timinings (tofu.d and tofu.db deleted between runs): With rev: 9afeb4cc gpg2 --trust-model=tofu+pgp --tofu-db-format flat -k 3.52s user 0.91s system 21% cpu 20.695 total gpg2 --trust-model=tofu+pgp --tofu-db-format split -k 3.10s user 2.43s system 12% cpu 44.597 tota With rev: bc9ff6c85 gpg2 --trust-model=tofu+pgp --tofu-db-format flat -k 1.34s user 0.89s system 13% cpu 16.068 total gpg2 --trust-model=tofu+pgp --tofu-db-format split -k 3.01s user 2.57s system 12% cpu 45.751 total With rev: eb8a0b0 gpg2 --trust-model=tofu+pgp --tofu-db-format flat -k 1.14s user 0.87s system 13% cpu 14.532 total gpg2 --trust-model=tofu+pgp --tofu-db-format split -k 3.18s user 2.49s system 12% cpu 45.165 total I'm a bit confused with the last result as yesterday on that revision it only took 22sec. Maybe a problem with my test setup. ATM I don't have time to look into it more. 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 From neal at walfield.org Wed Oct 21 15:35:33 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 21 Oct 2015 15:35:33 +0200 Subject: TOFU: interacting with the user In-Reply-To: <3708391.A5zfnRD9AI@esus> References: <87oagi9tm1.wl-neal@walfield.org> <8737x89kit.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> Message-ID: <87si548hui.wl-neal@walfield.org> At Tue, 20 Oct 2015 19:46:23 +0200, Andre Heinecke wrote: > I've not yet tested what happens in case of conflicts where the command line > would ask questions. Maybe bring up a pinentry prompt for that? This requires GpgME support. There are a couple of arguments against using pinentry for this. I think we should only use pinentry for requesting sensitive information. Moreover, only gpg agent should use pinentry. This way, the user learns that only gpg-agent uses this interface. Currently, it is not possible to enforce this behavior. But if we ever get good mechanisms for implementing the principle of least authority (like Genode), we should make sure that we are still in a position to take advantage of them. Second, pinentry doesn't currently support TOFU's queries! When a conflict is detected, GnuPG asks the user to assign a policy to the key. There are five choices (good, accept once, unknown, reject one, bad). Currently, pinentry only supports up to three buttons. A hack would be to only offer three choices: good, unknown and bad. This works because the other two are just ways to defer the decision and not really policies. Thanks, :) Neal From aheinecke at intevation.de Wed Oct 21 15:54:25 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 21 Oct 2015 15:54:25 +0200 Subject: TOFU: interacting with the user In-Reply-To: <87si548hui.wl-neal@walfield.org> References: <87oagi9tm1.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87si548hui.wl-neal@walfield.org> Message-ID: <3143047.2sWcrhqp8x@esus> Hi, On Wednesday 21 October 2015 15:35:33 Neal H. Walfield wrote: > At Tue, 20 Oct 2015 19:46:23 +0200, > > Andre Heinecke wrote: > > I've not yet tested what happens in case of conflicts where the command > > line would ask questions. Maybe bring up a pinentry prompt for that? > > This requires GpgME support. > > There are a couple of arguments against using pinentry for this. > > I think we should only use pinentry for requesting sensitive > information. Isn't "Is this key good or bad?" a sensitive decision? Like trusting a CA. It directly influences the outcome of verification results. > Moreover, only gpg agent should use pinentry. This way, > the user learns that only gpg-agent uses this interface. Currently, > it is not possible to enforce this behavior. But if we ever get good > mechanisms for implementing the principle of least authority (like > Genode), we should make sure that we are still in a position to take > advantage of them. I don't see why this couldn't be handled by the agent too? gpg -> agent -> pinentry > > Second, pinentry doesn't currently support TOFU's queries! When a > conflict is detected, GnuPG asks the user to assign a policy to the > key. There are five choices (good, accept once, unknown, reject one, > bad). Currently, pinentry only supports up to three buttons. A hack > would be to only offer three choices: good, unknown and bad. This > works because the other two are just ways to defer the decision and > not really policies. Right. But we can easily and quickly modify pinentry to present those queries nicely in a new version. Doing this in every GUI Software that uses gnupg and adding support to gpgme would be way more effort and I expect that it will take much longer until tofu is widely supported if we wait for that. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Wed Oct 21 16:27:43 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 21 Oct 2015 16:27:43 +0200 Subject: TOFU performance / DB format In-Reply-To: <4769117.He9oYshJPS@esus> References: <87oagi9tm1.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87vba08klk.wl-neal@walfield.org> <4769117.He9oYshJPS@esus> Message-ID: <87r3ko8ffk.wl-neal@walfield.org> At Wed, 21 Oct 2015 15:32:05 +0200, Andre Heinecke wrote: > On Wednesday 21 October 2015 14:36:07 Neal H. Walfield wrote: > > At Tue, 20 Oct 2015 19:46:23 +0200, > > The flat format uses a single file and is, as you observed on jabber, > > about 20 times faster. > > That was a misunderstanding then. The 20 times speedup was between the first > and the second run of gpg2 -k Thanks for clearing that up. > flat / split both were at around 20sec. Unless I'm interpreting your numbers incorrectly, it looks like flat is about 20s and split is 45 seconds. > Here are some more timinings (tofu.d and tofu.db deleted between runs): > > With rev: 9afeb4cc > > gpg2 --trust-model=tofu+pgp --tofu-db-format flat -k 3.52s user 0.91s system > 21% cpu 20.695 total > > gpg2 --trust-model=tofu+pgp --tofu-db-format split -k 3.10s user 2.43s system > 12% cpu 44.597 tota > > With rev: bc9ff6c85 > > gpg2 --trust-model=tofu+pgp --tofu-db-format flat -k 1.34s user 0.89s system > 13% cpu 16.068 total > > gpg2 --trust-model=tofu+pgp --tofu-db-format split -k 3.01s user 2.57s system > 12% cpu 45.751 total > > With rev: eb8a0b0 > > gpg2 --trust-model=tofu+pgp --tofu-db-format flat -k 1.14s user 0.87s system > 13% cpu 14.532 total > > gpg2 --trust-model=tofu+pgp --tofu-db-format split -k 3.18s user 2.49s system > 12% cpu 45.165 total > > I'm a bit confused with the last result as yesterday on that revision it only > took 22sec. Maybe a problem with my test setup. ATM I don't have time to look > into it more. Here's what I see (I'm using wget 'http://keyserver.borgnet.us/dump/sks-dump-0000.pgp.bz2, which contains just over 500 keys). Here's the base line (no TOFU): 0.1s $ time gpg2 --trust-model=pgp -k >/dev/null real 0m0.092s user 0m0.072s sys 0m0.012s With the TOFU flat format: initial listing: 29s (0.4 seconds CPU time) subsequent listing: 1s (0.1 seconds CPU time) $ time gpg2 --trust-model=tofu --tofu-db-format=flat -k >/dev/null real 0m28.549s user 0m0.384s sys 0m0.384s $ time gpg2 --trust-model=tofu --tofu-db-format=flat -k >/dev/null real 0m0.945s user 0m0.084s sys 0m0.056s With the TOFU split format: initial listing: 96s (1.1 seconds CPU time) subsequent listing: 3s (0.2 seconds CPU time) $ time gpg2 --trust-model=tofu --tofu-db-format=split -k >/dev/null real 1m35.562s user 0m1.076s sys 0m1.276s $ time gpg2 --trust-model=tofu --tofu-db-format=split -k >/dev/null real 0m3.148s user 0m0.232s sys 0m0.152s So at least here, the flat format is about 3 times faster than the split format. You're seeing a bit more than a two times difference. This can be explained by your use of a local SSD and my use of NFS. Whatever the case, it's worth investing some time into understanding why the TOFU updates are relatively slow and both updates (the initial run) and reads (the second gpg2 -k) are so I/O bound. In terms of updates, I think it is because SQLite is slow with many individual updates (the SQLite developers recommend batching writes to amortize the cost). As for reads, I have no idea. Thanks for the feedback! :) Neal From wk at gnupg.org Wed Oct 21 21:25:17 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Oct 2015 21:25:17 +0200 Subject: [PATCH] Check for GPG_TTY as well as DISPLAY. In-Reply-To: <1445385603-3678688.75890528.ft9KNxZWg007079@rs146.luxsci.com> (Ben Kibbey's message of "Tue, 20 Oct 2015 19:59:34 -0400") References: <1445385603-3678688.75890528.ft9KNxZWg007079@rs146.luxsci.com> Message-ID: <87eggohvmq.fsf@vigenere.g10code.de> On Wed, 21 Oct 2015 01:59, bjk at luxsci.net said: > There doesn't seem to be a way to set the tty for a pinentry to prompt > on in gpgme if isatty() fails (daemon process). This patch uses the > GPG_TTY environment variable as the value of --ttyname when set, and the > value of ttyname_r() if not. This will change the behaviour of most gpgme using applications. We need to better understand the problem and evaluate the risks of breaking code. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 21 21:48:01 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Oct 2015 21:48:01 +0200 Subject: adns and TOR In-Reply-To: <22055.30470.407246.973906@chiark.greenend.org.uk> (Ian Jackson's message of "Wed, 21 Oct 2015 12:29:10 +0100") References: <87vba1n0nc.fsf@vigenere.g10code.de> <22054.22959.951094.201969@chiark.greenend.org.uk> <87h9llmk1m.fsf@vigenere.g10code.de> <22055.30470.407246.973906@chiark.greenend.org.uk> Message-ID: <87a8rchuku.fsf@vigenere.g10code.de> On Wed, 21 Oct 2015 13:29, ijackson at chiark.greenend.org.uk said: > which adns lets you provide a different one of). To use the TOR > resolver you're going to have to specify nameservers anyway, so you > already have a custom resolv.conf, presumably. Right, this is the current code if (tor_mode? adns_init_strcfg (&state, adns_if_noerrprint|adns_if_tormode, NULL, "nameserver 8.8.8.8") /* */: adns_init (&state, adns_if_noerrprint, NULL)) changing this to an config option would be fairly easy. > The init flags are for properties of the application's interaction > with the adns API, not really for how to configure where DNS data > comes from. The latter is defined in the config file. Okay. However, the flags are part of the public API - at least they seem to be. > I guess I meant: is it intended that every application program which > one might want to use to access a TOR service would have to be patched > to know about TOR, specifically ? There is this torsocks script which LD_PRELOADs a wrapper to intercept all network related calls to send them to Tor or returns an error. For most use cases this is fine but Dirmngr is GnuPG network access module and a background process which is designed to properly control access to the network. Thus for this and other heavy network users integrated Tor support seems to be better. > But I don't know how SOCKS is usually configured. How do you normally > tell a SOCKSified client program where to find its SOCKS server ? Clicking somehwere ;-). Maybe there is an envar similar to http_proxy but I don't know for sure. > (For that matter, in the TOR context, how do you tell an application > to use a different resolver?) Usually Tor does its own thing as Jake explained in his mail. Dirmngr however needs to take care of the keyserver pools and thus need to figure out the IP addresses. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 21 22:00:47 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Oct 2015 22:00:47 +0200 Subject: adns and TOR In-Reply-To: (Jacob Appelbaum's message of "Wed, 21 Oct 2015 12:05:26 +0000") References: <87vba1n0nc.fsf@vigenere.g10code.de> <22054.22959.951094.201969@chiark.greenend.org.uk> <87h9llmk1m.fsf@vigenere.g10code.de> <22055.30470.407246.973906@chiark.greenend.org.uk> Message-ID: <876120htzk.fsf@vigenere.g10code.de> On Wed, 21 Oct 2015 14:05, jacob at appelbaum.net said: > Authentication is actually important for Tor but not for obvious > reasons. We use it to signal that we'd like a new Tor circuit. A Yeah, someone told me that but to keep things easy I will ignore this for the first version. But it needs to be considered for the next Libassuan release which will have the SOCKS5 code. Libassuan is the IPC library but also features a socket wrapper layer. > Tor, not TOR. Also - if you want to connect to a .onion (eg: our soon [Okay: 9ffcb77 Change capitalization of TOR to Tor.] > to be published RFC 7686) - you need to use a proxy that supports it > OR you need an OS that transparently routes TCP traffic into that > proxy. If you're not using SOCKS5 (or SOCKS4a) then you're going to > have trouble resolving .onion names - please see RFC 7686 in the next Good point. This needs to be addressed. I hoped to delay that until I am ready to move the assuan socket wrappers into libgpg-error (common code for all GnuPG related projects). But it seems I need to write assuan_sock_connect_byname(), which will be a combination of socket()+connect(), earlier. However this is not DNS related, or well, only at a different layer. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ijackson at chiark.greenend.org.uk Wed Oct 21 22:26:01 2015 From: ijackson at chiark.greenend.org.uk (Ian Jackson) Date: Wed, 21 Oct 2015 21:26:01 +0100 Subject: adns and TOR In-Reply-To: <87a8rchuku.fsf@vigenere.g10code.de> References: <87vba1n0nc.fsf@vigenere.g10code.de> <22054.22959.951094.201969@chiark.greenend.org.uk> <87h9llmk1m.fsf@vigenere.g10code.de> <22055.30470.407246.973906@chiark.greenend.org.uk> <87a8rchuku.fsf@vigenere.g10code.de> Message-ID: <22055.62681.859262.777669@chiark.greenend.org.uk> Werner Koch writes ("Re: adns and TOR"): > On Wed, 21 Oct 2015 13:29, ijackson at chiark.greenend.org.uk said: > > which adns lets you provide a different one of). To use the TOR > > resolver you're going to have to specify nameservers anyway, so you > > already have a custom resolv.conf, presumably. > > Right, this is the current code > > if (tor_mode? adns_init_strcfg (&state, adns_if_noerrprint|adns_if_tormode, > NULL, "nameserver 8.8.8.8") > /* */: adns_init (&state, adns_if_noerrprint, NULL)) > > changing this to an config option would be fairly easy. Right. So, a config option "socks" with suitable semantics would do ? I would welcome a patch to do that. A bit of care ought to be taken to allow room for likely future extensions (authentication is being discussed, it seems...) > > The init flags are for properties of the application's interaction > > with the adns API, not really for how to configure where DNS data > > comes from. The latter is defined in the config file. > > Okay. However, the flags are part of the public API - at least they > seem to be. Indeed. But the point is that things outside the program can't set init flags. Whereas things outside the program _can_ define the config, for example by setting ADNS_* environment variables. > > I guess I meant: is it intended that every application program which > > one might want to use to access a TOR service would have to be patched > > to know about TOR, specifically ? > > There is this torsocks script which LD_PRELOADs a wrapper to intercept > all network related calls to send them to Tor or returns an error. > [...] So this script ought to set suitable ADNS_* variable so tht naive programs get an adns configuration which uses the Tor socks proxy for dns lookups. Am I right ? Thanks, Ian. From bjk at luxsci.net Thu Oct 22 00:07:20 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Wed, 21 Oct 2015 18:07:20 -0400 Subject: [PATCH] Check for GPG_TTY as well as DISPLAY. In-Reply-To: <87eggohvmq.fsf@vigenere.g10code.de> References: <1445385603-3678688.75890528.ft9KNxZWg007079@rs146.luxsci.com> <87eggohvmq.fsf@vigenere.g10code.de> Message-ID: <1445465282-9798705.77418447.ft9LM7KOY017487@rs146.luxsci.com> On Wed, Oct 21, 2015 at 09:25:17PM +0200, Werner Koch wrote: > On Wed, 21 Oct 2015 01:59, bjk at luxsci.net said: > > > There doesn't seem to be a way to set the tty for a pinentry to prompt > > on in gpgme if isatty() fails (daemon process). This patch uses the > > GPG_TTY environment variable as the value of --ttyname when set, and the > > value of ttyname_r() if not. > > This will change the behaviour of most gpgme using applications. We > need to better understand the problem and evaluate the risks of breaking > code. I have a server that runs detached from a terminal and uses gpgme which spawns gpg2 and pinentry. Clients connect to this server which invoke the actual commands on the server to spawn gpg2 and pinentry. Since gpgme uses isatty() to determine what to pass as --ttyname to gpg2, if isatty() fails (which it will for a background process) then there isn't a way for pinentry to know what tty the client is on. The patch obtains the tty from the GPG_TTY environment variable. The server sets GPG_TTY via a command that the client has the value for. I suppose it may be better to change the test around. So rather than doing: if (!_gpgme_getenv ("GPG_TTY", &tmp_ttyname) || isatty (1)) do: if (isatty(1) || !_gpgme_getenv ("GPG_TTY", &tmp_ttyname)) which would keep the original behavior but not work for my case as the foreground server process would catch the pinentry rather than the client on another tty. Would that be OK to push after keeping the isatty() test order? -- Ben Kibbey From bjk at luxsci.net Thu Oct 22 03:15:09 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Wed, 21 Oct 2015 21:15:09 -0400 Subject: [PATCH] Check for GPG_TTY as well as DISPLAY. In-Reply-To: <1445465282-9798705.77418447.ft9LM7KOY017487@rs146.luxsci.com> References: <1445385603-3678688.75890528.ft9KNxZWg007079@rs146.luxsci.com> <87eggohvmq.fsf@vigenere.g10code.de> <1445465282-9798705.77418447.ft9LM7KOY017487@rs146.luxsci.com> Message-ID: <1445476562-5316839.91670606.ft9M1FAUp001014@rs146.luxsci.com> On Wed, Oct 21, 2015 at 06:07:20PM -0400, Ben Kibbey wrote: > which would keep the original behavior but not work for my case as the > foreground server process would catch the pinentry rather than the > client on another tty. > > Would that be OK to push after keeping the isatty() test order? Nevermind. Pushing the above modification wouldn't make a difference. I got what I needed to work working. Sorry about the noise. -- Ben Kibbey From wk at gnupg.org Thu Oct 22 14:29:05 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Oct 2015 14:29:05 +0200 Subject: TOFU code available In-Reply-To: <4204042.BDtm6V7NUR@esus> (Andre Heinecke's message of "Wed, 21 Oct 2015 13:29:20 +0200") References: <87oagi9tm1.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87twpll1jq.fsf@vigenere.g10code.de> <4204042.BDtm6V7NUR@esus> Message-ID: <87io5zgk8e.fsf@vigenere.g10code.de> On Wed, 21 Oct 2015 13:29, aheinecke at intevation.de said: >> Nope. We should not overload the Pinentry with functions it is not >> designed for. > > I think it makes sense though. We already have pinentry asking for Root > Certificate trust in S/MIME and imo the TOFU questions fall in the same > category. It's just a dialog with a question and some options. The difference is that there are only a few root certificates (modulo self-signed stuff) but for Tofu the "root certificate" is the key of the user. Thus you would have a Pinentry pop up for each key. > Some advantages I see: Right. My point is that the Pinentry should be rarley Used for non-PIN request. Exceptions I see are Root CA fingerprints and security update notification. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Thu Oct 22 15:06:57 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 22 Oct 2015 15:06:57 +0200 Subject: TOFU code available In-Reply-To: <87io5zgk8e.fsf@vigenere.g10code.de> References: <87oagi9tm1.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87twpll1jq.fsf@vigenere.g10code.de> <4204042.BDtm6V7NUR@esus> <87io5zgk8e.fsf@vigenere.g10code.de> Message-ID: <87oafr832m.wl-neal@walfield.org> At Thu, 22 Oct 2015 14:29:05 +0200, Werner Koch wrote: > > On Wed, 21 Oct 2015 13:29, aheinecke at intevation.de said: > >> Nope. We should not overload the Pinentry with functions it is not > >> designed for. > > > > I think it makes sense though. We already have pinentry asking for Root > > Certificate trust in S/MIME and imo the TOFU questions fall in the same > > category. It's just a dialog with a question and some options. > > The difference is that there are only a few root certificates > (modulo self-signed stuff) but for Tofu the "root certificate" is > the key of the user. Thus you would have a Pinentry pop up for > each key. This is not the case. We only require user interaction if there is a conflict. The default policy is to silently set the policy to auto. Moreover, the user of pinentry doesn't change the number of user interactions so this is a bit of a red herring. :) Neal From wk at gnupg.org Thu Oct 22 15:16:16 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Oct 2015 15:16:16 +0200 Subject: TOFU: interacting with the user In-Reply-To: <87si548hui.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 21 Oct 2015 15:35:33 +0200") References: <87oagi9tm1.wl-neal@walfield.org> <8737x89kit.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87si548hui.wl-neal@walfield.org> Message-ID: <87eggngi1r.fsf@vigenere.g10code.de> On Wed, 21 Oct 2015 15:35, neal at walfield.org said: > Second, pinentry doesn't currently support TOFU's queries! When a Right, this is on purpose. When not using Tofu and the key can't be verified, gpg already ask the user whether to use use the key anyway. There has never been a request to do move this to Pinentry. Instead the calling application should display a warning that the key can't be used but allow the user to override this (using GPGME_ENCRYPT_ALWAYS_TRUST). > key. There are five choices (good, accept once, unknown, reject one, > bad). Currently, pinentry only supports up to three buttons. A hack Similar to what we have now: "yes", "no" ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Thu Oct 22 15:29:17 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 22 Oct 2015 15:29:17 +0200 Subject: TOFU: interacting with the user In-Reply-To: <87eggngi1r.fsf@vigenere.g10code.de> References: <87oagi9tm1.wl-neal@walfield.org> <8737x89kit.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87si548hui.wl-neal@walfield.org> <87eggngi1r.fsf@vigenere.g10code.de> Message-ID: <87mvvb821e.wl-neal@walfield.org> At Thu, 22 Oct 2015 15:16:16 +0200, Werner Koch wrote: > > On Wed, 21 Oct 2015 15:35, neal at walfield.org said: > > > Second, pinentry doesn't currently support TOFU's queries! When a > > Right, this is on purpose. When not using Tofu and the key can't be > verified, gpg already ask the user whether to use use the key anyway. > There has never been a request to do move this to Pinentry. Instead the > calling application should display a warning that the key can't be used > but allow the user to override this (using GPGME_ENCRYPT_ALWAYS_TRUST). I think I wasn't clear. This is a technical limitation in pinentry. Pinentry supports 3 options (buttons). TOFU requires 5 options. This issue is orthogonal to any policy decision that we may or may not want. > > key. There are five choices (good, accept once, unknown, reject one, > > bad). Currently, pinentry only supports up to three buttons. A hack > > Similar to what we have now: "yes", "no" ;-) I'm not sure what you are referring to here. Thanks, :) Neal From wk at gnupg.org Thu Oct 22 15:52:01 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Oct 2015 15:52:01 +0200 Subject: TOFU: interacting with the user In-Reply-To: <87mvvb821e.wl-neal@walfield.org> (Neal H. Walfield's message of "Thu, 22 Oct 2015 15:29:17 +0200") References: <87oagi9tm1.wl-neal@walfield.org> <8737x89kit.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87si548hui.wl-neal@walfield.org> <87eggngi1r.fsf@vigenere.g10code.de> <87mvvb821e.wl-neal@walfield.org> Message-ID: <87611zgge6.fsf@vigenere.g10code.de> On Thu, 22 Oct 2015 15:29, neal at walfield.org said: > Pinentry supports 3 options (buttons). TOFU requires 5 options. This > issue is orthogonal to any policy decision that we may or may not Put an to fix technical restriction. Still I don't like thyat idea. >> Similar to what we have now: "yes", "no" ;-) > > I'm not sure what you are referring to here. What I mean is that we do not use the Pinentry to ask for "yes" or "no" in this case ("Use key anyway?") Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Thu Oct 22 16:04:49 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 22 Oct 2015 16:04:49 +0200 Subject: TOFU: interacting with the user In-Reply-To: <87611zgge6.fsf@vigenere.g10code.de> References: <87oagi9tm1.wl-neal@walfield.org> <8737x89kit.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87si548hui.wl-neal@walfield.org> <87eggngi1r.fsf@vigenere.g10code.de> <87mvvb821e.wl-neal@walfield.org> <87611zgge6.fsf@vigenere.g10code.de> Message-ID: <87lhav80e6.wl-neal@walfield.org> At Thu, 22 Oct 2015 15:52:01 +0200, Werner Koch wrote: > On Thu, 22 Oct 2015 15:29, neal at walfield.org said: > > > Pinentry supports 3 options (buttons). TOFU requires 5 options. This > > issue is orthogonal to any policy decision that we may or may not > > Put an to fix technical restriction. Still I don't like thyat idea. I'm not sure I understand. > >> Similar to what we have now: "yes", "no" ;-) > > > > I'm not sure what you are referring to here. > > What I mean is that we do not use the Pinentry to ask for "yes" or "no" > in this case ("Use key anyway?") When TOFU asks whether to use the key, it's not a yes or no question. There are five options. Thanks, :) Neal From kristian.fiskerstrand at sumptuouscapital.com Thu Oct 22 23:11:18 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 22 Oct 2015 23:11:18 +0200 Subject: The --use-tor option In-Reply-To: <5627629D.2060605@sumptuouscapital.com> References: <87oafvqac8.fsf@vigenere.g10code.de> <2331911.xffYaiXkJa@localhost> <87wpuhh9ji.fsf@alice.fifthhorseman.net> <5627629D.2060605@sumptuouscapital.com> Message-ID: <562950F6.20907@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/21/2015 12:02 PM, Kristian Fiskerstrand wrote: > On 10/20/2015 07:44 PM, Jacob Appelbaum wrote: >> On 10/20/15, Daniel Kahn Gillmor wrote: >>> On Mon 2015-10-19 10:54:49 -0400, Malte wrote: >>>> On Monday 19 October 2015 15:03 Werner Koch wrote: >>>> ... > >> It would be possible to use OnionBalance here - someone can run a >> popular .onion and add all of the SKS servers with .onions into >> that instance of Onion balance. Thus - a single .onion name can >> redirect entirely within Tor to every individual SKS server that >> has a .onion name/Hidden Service. > > > Thanks for this pointer, I'm not too familiar with it (and frankly > Tor in general) and busy with real life atm, but will try to read > up a bit and see if it is something that can be of interest later > this week > > Ok, I've started doing some preliminary work on this, and added a manual listing of onion addresses. Tor information is as such included in the keyserver status listings[0] and in meta pages[1]. In the process my own SKS cluster is now Tor enabled. Will look into actually setting up the pool using OnionBalance another day (need to set up a Gentoo package for it etc), but at least the framework is in place for the information. References: [0] https://sks-keyservers.net/status/ [1] https://sks-keyservers.net/status/info/keys2.kfwebs.net - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Carpe noctem Seize the night -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJWKVDuAAoJECULev7WN52FZdwIAIwb+poA5s9p+OFt+NstqmIa mCfden+AVMciEx+wfQRWF0rHBAtD1fd8iCBIg11gl+cPbNF1/HnQ58HJ9kItFmib hihZWoM9XuzEUG/Txc7eSOGRpGpzXfuW3P2VSCcnVk+MTDMhSN/MPTm7avOJNfNv 2T5TUyX/IAerTMvpucS6XrsgcUj6MetDMDlw3N5rtoWOQuarY2uSUH9SzD5yim0z MCqACE4fLV/Barz4jY/kJo+ulKG5303M6oM2x2tcWqJz/42nVrSHwjyjIeYOZmFU 9NDJ/NEH3Zb5CIoxlVGlb9VF1Va7uk+T6i/QTkx6ShT3qMY2K3Ly4DTtDjRoEFY= =hu9E -----END PGP SIGNATURE----- From donncha at donncha.is Fri Oct 23 00:36:47 2015 From: donncha at donncha.is (Donncha O'Cearbhaill) Date: Thu, 22 Oct 2015 22:36:47 +0000 Subject: The --use-tor option In-Reply-To: <562950F6.20907@sumptuouscapital.com> References: <87oafvqac8.fsf@vigenere.g10code.de> <2331911.xffYaiXkJa@localhost> <87wpuhh9ji.fsf@alice.fifthhorseman.net> <5627629D.2060605@sumptuouscapital.com> <562950F6.20907@sumptuouscapital.com> Message-ID: <562964FF.7050004@donncha.is> Kristian Fiskerstrand: > On 10/21/2015 12:02 PM, Kristian Fiskerstrand wrote: >> On 10/20/2015 07:44 PM, Jacob Appelbaum wrote: >>> On 10/20/15, Daniel Kahn Gillmor wrote: >>>> On Mon 2015-10-19 10:54:49 -0400, Malte wrote: >>>>> On Monday 19 October 2015 15:03 Werner Koch wrote: >>>>> > > ... > > >>> It would be possible to use OnionBalance here - someone can run a >>> popular .onion and add all of the SKS servers with .onions into >>> that instance of Onion balance. Thus - a single .onion name can >>> redirect entirely within Tor to every individual SKS server that >>> has a .onion name/Hidden Service. > > >> Thanks for this pointer, I'm not too familiar with it (and frankly >> Tor in general) and busy with real life atm, but will try to read >> up a bit and see if it is something that can be of interest later >> this week > > > > Ok, I've started doing some preliminary work on this, and added a > manual listing of onion addresses. Tor information is as such included > in the keyserver status listings[0] and in meta pages[1]. In the > process my own SKS cluster is now Tor enabled. > > Will look into actually setting up the pool using OnionBalance another > day (need to set up a Gentoo package for it etc), but at least the > framework is in place for the information. > > References: > [0] https://sks-keyservers.net/status/ > [1] https://sks-keyservers.net/status/info/keys2.kfwebs.net I'm the developer of the OnionBalance tool. Please let me know if there is anything I can do to help the GnuPG project with setting up a onion service SKS pool. Tor clients will automatically fail over and try other SKS servers servers if the fail to connect to one of the servers in the pool. It's also straightforward for the pool operator to swap out onion services from the pool if they are misbehaving or offline. Kind Regards, Donncha -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From neal at walfield.org Fri Oct 23 19:09:24 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 23 Oct 2015 19:09:24 +0200 Subject: TOFU performance / DB format In-Reply-To: <87r3ko8ffk.wl-neal@walfield.org> References: <87oagi9tm1.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87vba08klk.wl-neal@walfield.org> <4769117.He9oYshJPS@esus> <87r3ko8ffk.wl-neal@walfield.org> Message-ID: <87io5x8qbf.wl-neal@walfield.org> At Wed, 21 Oct 2015 16:27:43 +0200, Neal H. Walfield wrote: > > At Wed, 21 Oct 2015 15:32:05 +0200, > Andre Heinecke wrote: > > On Wednesday 21 October 2015 14:36:07 Neal H. Walfield wrote: > > > At Tue, 20 Oct 2015 19:46:23 +0200, > > > The flat format uses a single file and is, as you observed on jabber, > > > about 20 times faster. > > > > That was a misunderstanding then. The 20 times speedup was between the first > > and the second run of gpg2 -k > > Thanks for clearing that up. > > > flat / split both were at around 20sec. > > Unless I'm interpreting your numbers incorrectly, it looks like flat > is about 20s and split is 45 seconds. > > > Here are some more timinings (tofu.d and tofu.db deleted between runs): > > > > With rev: 9afeb4cc > > > > gpg2 --trust-model=tofu+pgp --tofu-db-format flat -k 3.52s user 0.91s system > > 21% cpu 20.695 total > > > > gpg2 --trust-model=tofu+pgp --tofu-db-format split -k 3.10s user 2.43s system > > 12% cpu 44.597 tota > > > > With rev: bc9ff6c85 > > > > gpg2 --trust-model=tofu+pgp --tofu-db-format flat -k 1.34s user 0.89s system > > 13% cpu 16.068 total > > > > gpg2 --trust-model=tofu+pgp --tofu-db-format split -k 3.01s user 2.57s system > > 12% cpu 45.751 total > > > > With rev: eb8a0b0 > > > > gpg2 --trust-model=tofu+pgp --tofu-db-format flat -k 1.14s user 0.87s system > > 13% cpu 14.532 total > > > > gpg2 --trust-model=tofu+pgp --tofu-db-format split -k 3.18s user 2.49s system > > 12% cpu 45.165 total > > > > I'm a bit confused with the last result as yesterday on that revision it only > > took 22sec. Maybe a problem with my test setup. ATM I don't have time to look > > into it more. > > Here's what I see (I'm using wget > 'http://keyserver.borgnet.us/dump/sks-dump-0000.pgp.bz2, which > contains just over 500 keys). > > Here's the base line (no TOFU): 0.1s > > $ time gpg2 --trust-model=pgp -k >/dev/null > real 0m0.092s > user 0m0.072s > sys 0m0.012s > > With the TOFU flat format: > > initial listing: 29s (0.4 seconds CPU time) > subsequent listing: 1s (0.1 seconds CPU time) > > $ time gpg2 --trust-model=tofu --tofu-db-format=flat -k >/dev/null > real 0m28.549s > user 0m0.384s > sys 0m0.384s > $ time gpg2 --trust-model=tofu --tofu-db-format=flat -k >/dev/null > real 0m0.945s > user 0m0.084s > sys 0m0.056s In 7f65e84, I added an interface to enable batch updates. This was based on the observation that SQLite performs better when there is a single big transaction instead of many small transactions [1]. This proved correct. With this patch, the time for an initial listing decreases from 29 seconds to 0.16 seconds. This means that using the TOFU trust model with the flat DB format performs almost the same as the pgp trust model. For a subsequent listing, the time increased slightly from 1 second to 1.2 seconds. However, this may just be noise. [1] https://www.sqlite.org/faq.html#q19 $ rm -rf tofu.d*; time gpg2 --trust-mode=tofu --tofu-db-format=flat -k >/dev/null real 0m0.161s user 0m0.052s sys 0m0.004s $ time gpg2 --trust-mode=tofu --tofu-db-format=flat -k >/dev/null real 0m1.197s user 0m0.088s sys 0m0.044s Unfortunately, this change only helps with the flat database format. For the split forat, we're still looking at over 90 seconds for the initial listing and 3 seconds for subsequent listings. I'd be interested to hear people's opinions about whether the split format (with its ability to be more easily synced) is still interesting despite the slow performance. Thanks! :) Neal From wk at gnupg.org Fri Oct 23 21:10:41 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Oct 2015 21:10:41 +0200 Subject: TOFU performance / DB format In-Reply-To: <87io5x8qbf.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 23 Oct 2015 19:09:24 +0200") References: <87oagi9tm1.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87vba08klk.wl-neal@walfield.org> <4769117.He9oYshJPS@esus> <87r3ko8ffk.wl-neal@walfield.org> <87io5x8qbf.wl-neal@walfield.org> Message-ID: <87vb9xe6z2.fsf@vigenere.g10code.de> On Fri, 23 Oct 2015 19:09, neal at walfield.org said: > In 7f65e84, I added an interface to enable batch updates. This was > based on the observation that SQLite performs better when there is a > single big transaction instead of many small transactions [1]. This I have not looked at the patch but I assume that you now do a BEGIN_TRANSACTION and a single COMMIT at the end of the key listing instead of the default auto-commit mode. Given that this is now a single large transaction, I wonder how the system behaves if several gpg instances start a Key listing at about the same time. Kleopatra is known for doing this in some cases. > $ rm -rf tofu.d*; time gpg2 --trust-mode=tofu --tofu-db-format=flat -k >/dev/null > real 0m0.161s > user 0m0.052s > sys 0m0.004s Now many keys? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Fri Oct 23 23:22:51 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 23 Oct 2015 23:22:51 +0200 Subject: TOFU performance / DB format In-Reply-To: <87vb9xe6z2.fsf@vigenere.g10code.de> References: <87oagi9tm1.wl-neal@walfield.org> <3708391.A5zfnRD9AI@esus> <87vba08klk.wl-neal@walfield.org> <4769117.He9oYshJPS@esus> <87r3ko8ffk.wl-neal@walfield.org> <87io5x8qbf.wl-neal@walfield.org> <87vb9xe6z2.fsf@vigenere.g10code.de> Message-ID: <87h9lh8el0.wl-neal@walfield.org> At Fri, 23 Oct 2015 21:10:41 +0200, Werner Koch wrote: > > On Fri, 23 Oct 2015 19:09, neal at walfield.org said: > > > In 7f65e84, I added an interface to enable batch updates. This was > > based on the observation that SQLite performs better when there is a > > single big transaction instead of many small transactions [1]. This > > I have not looked at the patch but I assume that you now do a > BEGIN_TRANSACTION and a single COMMIT at the end of the key listing > instead of the default auto-commit mode. Given that this is now a > single large transaction, I wonder how the system behaves if several > gpg instances start a Key listing at about the same time. > Kleopatra is known for doing this in some cases. If the DB is locked, I've configured sqlite to wait up to 5 seconds before aborting. Because there are situations where this might not be enough, my plan to to drop, yield and then retake the big lock occasionally. > > $ rm -rf tofu.d*; time gpg2 --trust-mode=tofu --tofu-db-format=flat -k >/dev/null > > real 0m0.161s > > user 0m0.052s > > sys 0m0.004s > > Now many keys? 518. Thanks, :) Neal From dkg at fifthhorseman.net Fri Oct 23 23:45:48 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 23 Oct 2015 17:45:48 -0400 Subject: [PATCH] ship sks-keyservers.netCA.pem in distributed tarball In-Reply-To: <1445312986-29456-1-git-send-email-dkg@fifthhorseman.net> References: <1445312986-29456-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87lhat8dir.fsf@alice.fifthhorseman.net> On Mon 2015-10-19 23:49:46 -0400, Daniel Kahn Gillmor wrote: > sks-keyservers.netCA.pem should get shipped in the signed and > distributed tarball, to facilitate hkps connections to the keyserver > pool. > > Signed-Off-By: Daniel Kahn Gillmor > --- > dirmngr/Makefile.am | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dirmngr/Makefile.am b/dirmngr/Makefile.am > index ae16660..845f3f5 100644 > --- a/dirmngr/Makefile.am > +++ b/dirmngr/Makefile.am > @@ -19,7 +19,7 @@ > > ## Process this file with automake to produce Makefile.in > > -EXTRA_DIST = OAUTHORS ONEWS ChangeLog-2011 tls-ca.pem > +EXTRA_DIST = OAUTHORS ONEWS ChangeLog-2011 tls-ca.pem sks-keyservers.netCA.pem > > bin_PROGRAMS = dirmngr dirmngr-client Any followup on this? is there a reason we shouldn't ship Kristian's cert as part of the source tarball? --dkg From dkg at fifthhorseman.net Fri Oct 23 23:46:57 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 23 Oct 2015 17:46:57 -0400 Subject: [PATCH] ensure all weak digest rejection notices are shown In-Reply-To: <1445265683-6824-1-git-send-email-dkg@fifthhorseman.net> References: <1445265683-6824-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1445636817-5244-1-git-send-email-dkg@fifthhorseman.net> * g10/main.h: add rejection_shown flag to each weakhash struct * g10/misc.c (print_digest_algo_note, additional_weak_digest): do not treat MD5 separately; (print_digest_rejected_note): use weakhash.rejection_shown instead of static shown * g10/options.h (opt): change from additional_weak_digests to weak_digests. * g10/sig-check.c: do not treat MD5 separately. * g10/gpg.c (main): explicitly set MD5 as weak. * g10/gpgv.c (main): explicitly set MD5 as weak. -- Previously, only one weak digest rejection message was shown, of whichever was the first type encountered. This meant that if "gpg --weak-digest SHA224" encountered both an MD5 digest and a SHA224 digest, it would only show the user that the MD5 digest was rejected. In order to let the user know which algorithms were rejected, we needed to move the "shown" flag into a per-weak-algorithm location. Given this additional complication, it made no sense to continue to treat MD5 specially, so it is added as a default weak algorithm in the same opt.weak_digests data structure as any other. Signed-Off-By: Daniel Kahn Gillmor --- g10/gpg.c | 3 ++- g10/gpgv.c | 2 ++ g10/main.h | 1 + g10/misc.c | 51 +++++++++++++++++++++++++-------------------------- g10/options.h | 2 +- g10/sig-check.c | 11 ++--------- 6 files changed, 33 insertions(+), 37 deletions(-) diff --git a/g10/gpg.c b/g10/gpg.c index ff6e59f..c18edd0 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -2216,7 +2216,8 @@ main (int argc, char **argv) set_homedir (default_homedir ()); opt.passphrase_repeat = 1; opt.emit_version = 1; /* Limit to the major number. */ - opt.additional_weak_digests = NULL; + opt.weak_digests = NULL; + additional_weak_digest("MD5"); /* Check whether we have a config file on the command line. */ orig_argc = argc; diff --git a/g10/gpgv.c b/g10/gpgv.c index ec09706..9a6dbd6 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -169,11 +169,13 @@ main( int argc, char **argv ) opt.batch = 1; opt.homedir = default_homedir (); + opt.weak_digests = NULL; tty_no_terminal(1); tty_batchmode(1); dotlock_disable (); gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); + additional_weak_digest("MD5"); pargs.argc = &argc; pargs.argv = &argv; diff --git a/g10/main.h b/g10/main.h index a50c85c..cb79a71 100644 --- a/g10/main.h +++ b/g10/main.h @@ -72,6 +72,7 @@ struct groupitem struct weakhash { enum gcry_md_algos algo; + int rejection_shown; struct weakhash *next; }; diff --git a/g10/misc.c b/g10/misc.c index 93ddaa0..5c77714 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -307,7 +307,6 @@ print_cipher_algo_note (cipher_algo_t algo) void print_digest_algo_note (digest_algo_t algo) { - int deprecated = 0; const enum gcry_md_algos galgo = map_md_openpgp_to_gcry (algo); const struct weakhash *weak; @@ -322,34 +321,38 @@ print_digest_algo_note (digest_algo_t algo) gcry_md_algo_name (galgo)); } } - else if(algo == DIGEST_ALGO_MD5) - deprecated = 1; else - for (weak = opt.additional_weak_digests; weak != NULL; weak = weak->next) + for (weak = opt.weak_digests; weak != NULL; weak = weak->next) if (weak->algo == galgo) - deprecated = 1; - - if (deprecated) - { - es_fflush (es_stdout); - log_info (_("WARNING: digest algorithm %s is deprecated\n"), - gcry_md_algo_name (galgo)); - } + { + es_fflush (es_stdout); + log_info (_("WARNING: digest algorithm %s is deprecated\n"), + gcry_md_algo_name (galgo)); + } } void print_digest_rejected_note (enum gcry_md_algos algo) { - static int shown; - - if (!shown) + struct weakhash* weak; + int show = 1; + for (weak = opt.weak_digests; weak; weak = weak->next) + if (weak->algo == algo) + { + if (weak->rejection_shown) + show = 0; + else + weak->rejection_shown = 1; + break; + } + + if (show) { es_fflush (es_stdout); log_info (_("Note: signatures using the %s algorithm are rejected\n"), gcry_md_algo_name(algo)); - shown = 1; } } @@ -1699,9 +1702,6 @@ additional_weak_digest (const char* digestname) struct weakhash *weak = NULL; const enum gcry_md_algos algo = string_to_digest_algo(digestname); - if (algo == GCRY_MD_MD5) - return; /* MD5 is always considered weak, no need to add it. */ - if (algo == GCRY_MD_NONE) { log_error(_("Unknown weak digest '%s'\n"), digestname); @@ -1709,15 +1709,14 @@ additional_weak_digest (const char* digestname) } /* Check to ensure it's not already present. */ - for (weak = opt.additional_weak_digests; weak != NULL; weak = weak->next) - { - if (algo == weak->algo) - return; - } + for (weak = opt.weak_digests; weak; weak = weak->next) + if (algo == weak->algo) + return; /* Add it to the head of the list. */ weak = xmalloc(sizeof(*weak)); weak->algo = algo; - weak->next = opt.additional_weak_digests; - opt.additional_weak_digests = weak; + weak->rejection_shown = 0; + weak->next = opt.weak_digests; + opt.weak_digests = weak; } diff --git a/g10/options.h b/g10/options.h index 0c674e6..4c7a5db 100644 --- a/g10/options.h +++ b/g10/options.h @@ -169,7 +169,7 @@ struct prefitem_t *personal_cipher_prefs; prefitem_t *personal_digest_prefs; prefitem_t *personal_compress_prefs; - struct weakhash *additional_weak_digests; + struct weakhash *weak_digests; int no_perm_warn; int no_mdc_warn; char *temp_dir; diff --git a/g10/sig-check.c b/g10/sig-check.c index f912c0c..2cfc5da 100644 --- a/g10/sig-check.c +++ b/g10/sig-check.c @@ -360,19 +360,12 @@ check_signature_end (PKT_public_key *pk, PKT_signature *sig, return rc; if (!opt.flags.allow_weak_digest_algos) - { - if (sig->digest_algo == GCRY_MD_MD5) + for (weak = opt.weak_digests; weak; weak = weak->next) + if (sig->digest_algo == weak->algo) { print_digest_rejected_note(sig->digest_algo); return GPG_ERR_DIGEST_ALGO; } - for (weak = opt.additional_weak_digests; weak; weak = weak->next) - if (sig->digest_algo == weak->algo) - { - print_digest_rejected_note(sig->digest_algo); - return GPG_ERR_DIGEST_ALGO; - } - } /* Make sure the digest algo is enabled (in case of a detached signature). */ -- 2.6.1 From dkg at fifthhorseman.net Fri Oct 23 23:54:44 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 23 Oct 2015 17:54:44 -0400 Subject: [PATCH] ensure all weak digest rejection notices are shown In-Reply-To: <1445636817-5244-1-git-send-email-dkg@fifthhorseman.net> References: <1445265683-6824-1-git-send-email-dkg@fifthhorseman.net> <1445636817-5244-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87fv118d3v.fsf@alice.fifthhorseman.net> On Fri 2015-10-23 17:46:57 -0400, Daniel Kahn Gillmor wrote: > Previously, only one weak digest rejection message was shown, of > whichever was the first type encountered. This meant that if "gpg > --weak-digest SHA224" encountered both an MD5 digest and a SHA224 > digest, it would only show the user that the MD5 digest was rejected. > > In order to let the user know which algorithms were rejected, we > needed to move the "shown" flag into a per-weak-algorithm location. > Given this additional complication, it made no sense to continue to > treat MD5 specially, so it is added as a default weak algorithm in the > same opt.weak_digests data structure as any other. btw, sorry to dribble these changes in over the course of three patches instead of one. each successive patch addresses failings that i hadn't noticed when i submitted the previous one. I think this is the last of them for this particular enhancement, but then again, that's what i thought last time too :/ --dkg From wk at gnupg.org Sat Oct 24 23:57:39 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 24 Oct 2015 23:57:39 +0200 Subject: [PATCH] ship sks-keyservers.netCA.pem in distributed tarball In-Reply-To: <87lhat8dir.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 23 Oct 2015 17:45:48 -0400") References: <1445312986-29456-1-git-send-email-dkg@fifthhorseman.net> <87lhat8dir.fsf@alice.fifthhorseman.net> Message-ID: <878u6sdj58.fsf@vigenere.g10code.de> On Fri, 23 Oct 2015 23:45, dkg at fifthhorseman.net said: > Any followup on this? is there a reason we shouldn't ship Kristian's > cert as part of the source tarball? Sure, we will do this. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bertrand at jacquin.bzh Mon Oct 26 15:34:27 2015 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Mon, 26 Oct 2015 14:34:27 +0000 Subject: gpgsm --gen-key segfault with ECC key on smartcard In-Reply-To: <20150819212750.GA12535@lady-voodoo.scabb> References: <20150819212750.GA12535@lady-voodoo.scabb> Message-ID: Hi, Please note that still happens with GnuPG 2.1.9 Cheers, Bertrand On 19/08/2015 22:27, Bertrand Jacquin wrote: > Hi, > > I'm getting a SEGV running gpgsm --gen-key with GnuPG 2.1.6. The issue > comes from libksba. Here is a backtrace: > > $ gpg --version > gpg (GnuPG) 2.1.6 > libgcrypt 1.6.3 > > $ gdb gpgsm > GNU gdb (Gentoo 7.7.1 p1) 7.7.1 > Copyright (C) 2014 Free Software Foundation, Inc. > > (gdb) r --gen-key > Starting program: /usr/bin/gpgsm --gen-key > > gpgsm (GnuPG) 2.1.6; Copyright (C) 2015 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 > (2) Existing key > (3) Existing key from card > Your selection? 3 > Serial number of the card: D276000124010200FFFE50FF6A060000 > Available keys: > (1) 1EE6350B308927412446FE9E39191C9A2107D817 OPENPGP.1 > (2) 41AC7E51641A4053606B139F18FDD044D49C0CF1 OPENPGP.3 > Your selection? 2 > Possible actions for a RSA key: > (1) sign, encrypt > (2) sign > (3) encrypt > Your selection? 2 > Enter the X.509 subject name: o=test > Enter email addresses (end with an empty line): >> test at test >> > Enter DNS names (optional; end with an empty line): >> > Enter URIs (optional; end with an empty line): >> > Create self-signed certificate? (y/N) > These parameters are used: > Key-Type: card:OPENPGP.3 > Key-Length: 1024 > Key-Usage: sign > Name-DN: o=test > Name-Email: test at test > Proceed with creation? (y/N) y > Now creating certificate request. This may take a while ... > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff76ba49c in get_ecc_curve_oid (buf=0x0, buflen=7, > r_oidlen=r_oidlen at entry=0x7fffffffd070) at > /usr/src/debug/dev-libs/libksba-1.3.3/libksba-1.3.3/src/keyinfo.c:328 > 328 buflen = strlen (curve_names[i].name); > > (gdb) bt > #0 0x00007ffff76ba49c in get_ecc_curve_oid (buf=0x0, buflen=7, > r_oidlen=r_oidlen at entry=0x7fffffffd070) at > /usr/src/debug/dev-libs/libksba-1.3.3/libksba-1.3.3/src/keyinfo.c:328 > #1 0x00007ffff76d5683 in _ksba_keyinfo_from_sexp > (sexp=sexp at entry=0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))", > r_der=0x69b908, r_derlen=0x69b910) > at > /usr/src/debug/dev-libs/libksba-1.3.3/libksba-1.3.3/src/keyinfo.c:1055 > #2 0x00007ffff76cff54 in _ksba_certreq_set_public_key (cr= out>, key=key at entry=0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))") > at > /usr/src/debug/dev-libs/libksba-1.3.3/libksba-1.3.3/src/certreq.c:355 > #3 0x00007ffff76bac85 in ksba_certreq_set_public_key (cr= out>, key=key at entry=0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))") > at > /usr/src/debug/dev-libs/libksba-1.3.3/libksba-1.3.3/src/visibility.c:888 > #4 0x0000000000425b3a in create_request (writer=, > sigkey=0x0, public=0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))", > carddirect=0x696980 "OPENPGP.3", para=0x673ac0, > ctrl=0x7fffffffdb40) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/certreqgen.c:909 > #5 proc_parameters (ctrl=ctrl at entry=0x7fffffffdb40, > para=para at entry=0x673ac0, out_fp=out_fp at entry=0x671940, > outctrl=outctrl at entry=0x7fffffffd460) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/certreqgen.c:752 > #6 0x0000000000426fa8 in read_parameters > (ctrl=ctrl at entry=0x7fffffffdb40, fp=fp at entry=0x696ec0, > out_fp=out_fp at entry=0x671940) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/certreqgen.c:390 > #7 0x00000000004270bb in gpgsm_genkey > (ctrl=ctrl at entry=0x7fffffffdb40, in_stream=in_stream at entry=0x696ec0, > out_stream=out_stream at entry=0x671940) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/certreqgen.c:1361 > #8 0x0000000000427924 in gpgsm_gencertreq_tty > (ctrl=ctrl at entry=0x7fffffffdb40, > output_stream=output_stream at entry=0x671940) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/certreqgen-ui.c:408 > #9 0x000000000040a66a in main (argc=0, argv=0x7fffffffdce8) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/gpgsm.c:1895 > > (gdb) fr 0 > #0 0x00007ffff76ba49c in get_ecc_curve_oid (buf=0x0, buflen=7, > r_oidlen=r_oidlen at entry=0x7fffffffd070) at > /usr/src/debug/dev-libs/libksba-1.3.3/libksba-1.3.3/src/keyinfo.c:328 > 328 buflen = strlen (curve_names[i].name); > (gdb) info args > buf = 0x0 > buflen = 7 > r_oidlen = 0x7fffffffd070 > (gdb) print curve_names > $1 = {{ > oid = 0x7ffff76dc3c0 "1.2.840.10045.3.1.1", > name = 0x7ffff76dc3d4 "NIST P-192" > }, { > oid = 0x7ffff76dc3c0 "1.2.840.10045.3.1.1", > name = 0x7ffff76dc3df "prime192v1" > }, { > oid = 0x7ffff76dc3c0 "1.2.840.10045.3.1.1", > name = 0x7ffff76dc3ea "secp192r1" > }, { > oid = 0x7ffff76dc3f4 "1.3.132.0.33", > name = 0x7ffff76dc401 "secp224r1" > }, { > oid = 0x7ffff76dc40b "1.2.840.10045.3.1.7", > name = 0x7ffff76dc41f "NIST P-256" > }, { > oid = 0x7ffff76dc40b "1.2.840.10045.3.1.7", > name = 0x7ffff76dc42a "prime256v1" > }, { > oid = 0x7ffff76dc40b "1.2.840.10045.3.1.7", > name = 0x7ffff76dc435 "secp256r1" > }, { > oid = 0x7ffff76dc43f "1.3.132.0.34", > name = 0x7ffff76dc44c "secp384r1" > }, { > oid = 0x7ffff76dc456 "1.3.132.0.35", > name = 0x7ffff76dc463 "secp521r1" > }, { > oid = 0x7ffff76dc46d "1.3.36.3.3.2.8.1.1.1", > name = 0x7ffff76dc482 "brainpoolP160r1" > }, { > oid = 0x7ffff76dc492 "1.3.36.3.3.2.8.1.1.3", > name = 0x7ffff76dc4a7 "brainpoolP192r1" > }, { > oid = 0x7ffff76dc4b7 "1.3.36.3.3.2.8.1.1.5", > name = 0x7ffff76dc4cc "brainpoolP224r1" > }, { > oid = 0x7ffff76dc4dc "1.3.36.3.3.2.8.1.1.7", > name = 0x7ffff76dc4f1 "brainpoolP256r1" > }, { > oid = 0x7ffff76dc501 "1.3.36.3.3.2.8.1.1.9", > name = 0x7ffff76dc516 "brainpoolP320r1" > }, { > oid = 0x7ffff76dc526 "1.3.36.3.3.2.8.1.1.11", > name = 0x7ffff76dc53c "brainpoolP384r1" > }, { > oid = 0x7ffff76dc54c "1.3.36.3.3.2.8.1.1.13", > name = 0x7ffff76dc562 "brainpoolP512r1" > }, { > oid = 0x0, > name = 0x0 > }} > (gdb) print i > $2 = > (gdb) print buflen > $3 = 7 > > (gdb) fr 1 > #1 0x00007ffff76d5683 in _ksba_keyinfo_from_sexp > (sexp=sexp at entry=0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))", > r_der=0x69b908, r_derlen=0x69b910) > at > /usr/src/debug/dev-libs/libksba-1.3.3/libksba-1.3.3/src/keyinfo.c:1055 > 1055 curve_oid = get_ecc_curve_oid (parm[idxtbl[0]].value, > (gdb) info args > sexp = 0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))" > r_der = 0x69b908 > r_derlen = 0x69b910 > > (gdb) fr 2 > #2 0x00007ffff76cff54 in _ksba_certreq_set_public_key (cr= out>, key=key at entry=0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))") > at > /usr/src/debug/dev-libs/libksba-1.3.3/libksba-1.3.3/src/certreq.c:355 > 355 return _ksba_keyinfo_from_sexp (key, &cr->key.der, > &cr->key.derlen); > (gdb) info args > cr = > key = 0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))" > > (gdb) fr 3 > #3 0x00007ffff76bac85 in ksba_certreq_set_public_key (cr= out>, key=key at entry=0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))") > at > /usr/src/debug/dev-libs/libksba-1.3.3/libksba-1.3.3/src/visibility.c:888 > 888 return _ksba_certreq_set_public_key (cr, key); > (gdb) info args > cr = > key = 0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))" > > (gdb) fr 4 > #4 0x0000000000425b3a in create_request (writer=, > sigkey=0x0, public=0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))", > carddirect=0x696980 "OPENPGP.3", para=0x673ac0, > ctrl=0x7fffffffdb40) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/certreqgen.c:909 > 909 err = ksba_certreq_set_public_key (cr, public); > (gdb) info args > writer = > sigkey = 0x0 > public = 0x69b000 > "(10:public-key(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32:\371_c\373\331|\237\062\253a\306\376\347\377\356\260\376`f\305r\333C\001\344?\346\370\224\034Y)))" > carddirect = 0x696980 "OPENPGP.3" > para = 0x673ac0 > ctrl = 0x7fffffffdb40 > > (gdb) fr 5 > #5 proc_parameters (ctrl=ctrl at entry=0x7fffffffdb40, > para=para at entry=0x673ac0, out_fp=out_fp at entry=0x671940, > outctrl=outctrl at entry=0x7fffffffd460) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/certreqgen.c:752 > 752 rc = create_request (ctrl, para, cardkeyid, public, > sigkey, writer); > (gdb) info args > ctrl = 0x7fffffffdb40 > para = 0x673ac0 > out_fp = 0x671940 > outctrl = 0x7fffffffd460 > > (gdb) fr 6 > #6 0x0000000000426fa8 in read_parameters > (ctrl=ctrl at entry=0x7fffffffdb40, fp=fp at entry=0x696ec0, > out_fp=out_fp at entry=0x671940) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/certreqgen.c:390 > 390 rc = proc_parameters (ctrl, para, out_fp, &outctrl); > (gdb) info args > ctrl = 0x7fffffffdb40 > fp = 0x696ec0 > out_fp = 0x671940 > > (gdb) fr 7 > #7 0x00000000004270bb in gpgsm_genkey > (ctrl=ctrl at entry=0x7fffffffdb40, in_stream=in_stream at entry=0x696ec0, > out_stream=out_stream at entry=0x671940) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/certreqgen.c:1361 > 1361 rc = read_parameters (ctrl, in_stream, out_stream); > (gdb) info args > ctrl = 0x7fffffffdb40 > in_stream = 0x696ec0 > out_stream = 0x671940 > > (gdb) fr 8 > #8 0x0000000000427924 in gpgsm_gencertreq_tty > (ctrl=ctrl at entry=0x7fffffffdb40, > output_stream=output_stream at entry=0x671940) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/certreqgen-ui.c:408 > 408 err = gpgsm_genkey (ctrl, fp, output_stream); > (gdb) info args > ctrl = 0x7fffffffdb40 > output_stream = 0x671940 > > (gdb) fr 9 > #9 0x000000000040a66a in main (argc=0, argv=0x7fffffffdce8) at > /usr/src/debug/app-crypt/gnupg-2.1.6/gnupg-2.1.6/sm/gpgsm.c:1895 > 1895 gpgsm_gencertreq_tty (&ctrl, fpout); > (gdb) info args > argc = 0 > argv = 0x7fffffffdce8 > > Is there any other information that I can provide ? > > Thanks, > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -- Bertrand From wk at gnupg.org Mon Oct 26 16:54:49 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Oct 2015 16:54:49 +0100 Subject: More Tor support available Message-ID: <87k2q9d3qu.fsf@vigenere.g10code.de> Hi! I hacked more on Tor support in GnuPG. All the DNS function have meanwhile been replaced by wrapper code which will make it much easier to resolve them via Tor. The next step will be to add an ADNS based backend for to the getaddrinfo wrapper so that a torified ADNS library will take care of actually resolving via Tor. In addition *.onion addresses are now directly supported so that it is possible to retrieve keys anonymously. Example configuration lines for dirmngr.conf are # keys2.kfwebs.net keyserver hkp://dyh2j3qyrirn43iw.onion or # zimmermann.mayfirst.org keyserver hkp://qdigse2yzvuglcix.onion To make this work you need the latest GnuPG and Libassuan from Git. Next steps are: - Figure out an algorithm for stream isolation (i.e. how often to change username/password). - Implement the mentioned ADNS backend for getaddrinfo. 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: 180 bytes Desc: not available URL: From wk at gnupg.org Mon Oct 26 17:01:17 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Oct 2015 17:01:17 +0100 Subject: [PATCH] ensure all weak digest rejection notices are shown In-Reply-To: <87fv118d3v.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 23 Oct 2015 17:54:44 -0400") References: <1445265683-6824-1-git-send-email-dkg@fifthhorseman.net> <1445636817-5244-1-git-send-email-dkg@fifthhorseman.net> <87fv118d3v.fsf@alice.fifthhorseman.net> Message-ID: <87a8r5d3g2.fsf@vigenere.g10code.de> On Fri, 23 Oct 2015 23:54, dkg at fifthhorseman.net said: > noticed when i submitted the previous one. I think this is the last of > them for this particular enhancement, but then again, that's what i > thought last time too :/ Pushed. I am now ready for the next part :-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Mon Oct 26 18:33:49 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 26 Oct 2015 18:33:49 +0100 Subject: More Tor support available In-Reply-To: <87k2q9d3qu.fsf@vigenere.g10code.de> References: <87k2q9d3qu.fsf@vigenere.g10code.de> Message-ID: <562E63FD.9080805@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/26/2015 04:54 PM, Werner Koch wrote: > Hi! > > I hacked more on Tor support in GnuPG. All the DNS function have > meanwhile been replaced by wrapper code which will make it much > easier to resolve them via Tor. The next step will be to add an > ADNS based backend for to the getaddrinfo wrapper so that a > torified ADNS library will take care of actually resolving via > Tor. > > In addition *.onion addresses are now directly supported so that it > is possible to retrieve keys anonymously. Example configuration > lines for dirmngr.conf are > > # keys2.kfwebs.net keyserver hkp://dyh2j3qyrirn43iw.onion > > or > > # zimmermann.mayfirst.org keyserver hkp://qdigse2yzvuglcix.onion > I have no idea if it works yet, but fwiw hkp://jirk5u4osbsr34t5.onion is _supposed_ to be an OnionBalance instance in front of both of these addresses. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Carpe noctem Seize the night -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJWLmP5AAoJECULev7WN52FYV4H/i9bb0+RdnUwSvLXmuaImBhG KhjmydZ4NzaEi5EYLAYKGCzYrUGBxzg5wz3dlKNvYqpZP5eSxbNxOMpzB+S9fCpJ pocad6ets+D0L+YrrTeem/riZh6AUZZF1tX7ryGH2Wc5D3kiA2Fm4QSmx4VgVPbx nq0AN+/D3TAxvEShT7HE+h9csPi/Zej1FBgRDxcavRfLl78tSa55xZXCWgR3O/rD KCNDaJsM9mtrDB3LfgpovtIIxWDRV3sn05yeHERZPtI4Xibimn7We6WmIvDSqmRO JLN7ZCll5VDNIqKi6ly9tAZwqSdRbiqNWt3At7nKrWYNA37i2xDeL08AGMIAty0= =GmQV -----END PGP SIGNATURE----- From jeroen.ooms at stat.ucla.edu Mon Oct 26 19:55:40 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Mon, 26 Oct 2015 19:55:40 +0100 Subject: GnuPG Github mirrors Message-ID: Following other GNU projects such as Linux and R, the GnuPG git server is now mirrored on Github: https://github.com/gpg For those unfamiliar with Github: it is a popular git hosting service which adds a nice web interface and API for things like commits [1,4] branches [2,5], releases [3,6], etc. Hopefully this can help making GnuPG development a bit more visible and accessible. Github also provides powerful collaboration features to fork repositories, generate/review/discuss/merge patches (pull requests), and organize access control via users and organizations. However these features are mainly useful when using Github as the primary development server rather than a mirror. I am currently controlling the Github 'gpg' organization but will happily transfer ownership if someone from GnuPG wants to take over. [1] https://github.com/gpg/gnupg/commits [2] https://github.com/gpg/gnupg/branches [3] https://github.com/gpg/gnupg/releases [4] https://api.github.com/repos/gpg/gnupg/commits [5] https://api.github.com/repos/gpg/gnupg/branches [6] https://api.github.com/repos/gpg/gnupg/tags From kristian.fiskerstrand at sumptuouscapital.com Mon Oct 26 20:05:17 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 26 Oct 2015 20:05:17 +0100 Subject: GnuPG Github mirrors In-Reply-To: References: Message-ID: <562E796D.2020506@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/26/2015 07:55 PM, Jeroen Ooms wrote: > Following other GNU projects such as Linux and R, the GnuPG git > server is now mirrored on Github: > > https://github.com/gpg > > For those unfamiliar with Github: it is a popular git hosting > service which adds a nice web interface and API for things like > commits [1,4] branches [2,5], releases [3,6], etc. Hopefully this > can help making GnuPG development a bit more visible and > accessible. This is a joke, right? In case it is not I simply ask; why would anyone want to move away from libre repository hosting (and issue tracker, wiki etc) in favor of a proprietary solution where you potentially have no control of your own data in the future? - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Carpe noctem Seize the night -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJWLnlpAAoJECULev7WN52Fiw4H/26fovjteGz0whIFkhgH3syK pvhYhNrhGF291PXdx3KuKOgPWDB6bfkpHFA6IH0bGUe6tLHyTdsJqDu6O+ir7BM8 lgWipd7ccYYn0XU+oAPj0F93k7okwi5WGzm5JcA1EFYgwsHglsqXeCkieJ4t7mFn tLiHMBRfJpz1kH/0jbOqdvDPnYJsq0aBRoC7zUWqJa/D440If9+HokBsB8mUYLP7 aMb1lFiONzy9mDeco65FC6mJW0ZEOaXJrtltdcnwIJ6EgFNZo9PdI8DVrQUswZgn rJMB9Neh4XQzgUKr1bYo05zI/cmIOMN7kp4/vUhgGf194BF8ZJjjYUgXA7Oz6nA= =1fWy -----END PGP SIGNATURE----- From jeroen.ooms at stat.ucla.edu Mon Oct 26 20:58:47 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Mon, 26 Oct 2015 20:58:47 +0100 Subject: GnuPG Github mirrors In-Reply-To: <562E796D.2020506@sumptuouscapital.com> References: <562E796D.2020506@sumptuouscapital.com> Message-ID: On Mon, Oct 26, 2015 at 8:05 PM, Kristian Fiskerstrand wrote: > why would anyone want to move away from libre repository hosting (and issue tracker, wiki etc) in favor of a proprietary solution where you potentially have no control of your own data in the future? It's a *mirror*, I'm not sure where exactly you got the moving away part. Think of it as a similar role as ftp mirrors, but then for browsable code, commits, etc. Using it is entirely optional, you don't have to give out control of your data to anyone. From wk at gnupg.org Mon Oct 26 21:12:21 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Oct 2015 21:12:21 +0100 Subject: More Tor support available In-Reply-To: <562E63FD.9080805@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Mon, 26 Oct 2015 18:33:49 +0100") References: <87k2q9d3qu.fsf@vigenere.g10code.de> <562E63FD.9080805@sumptuouscapital.com> Message-ID: <87ziz5bd96.fsf@vigenere.g10code.de> On Mon, 26 Oct 2015 18:33, kristian.fiskerstrand at sumptuouscapital.com said: > I have no idea if it works yet, but fwiw hkp://jirk5u4osbsr34t5.onion > is _supposed_ to be an OnionBalance instance in front of both of these Well, gpg --recv-key returns my key. If I use the socks5 test program for Libassuan, I get this: $ ./socks5 --byname --user foo1 --pass bar3 jirk5u4osbsr34t5.onion 11371 HTTP/1.1 200 OK Server: nginx/1.2.1 Date: Mon, 26 Oct 2015 20:09:25 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 1417 Connection: close Cache-Control: no-cache Pragma: no-cache Expires: 0 Access-Control-Allow-Origin: * Via: 1.1 zimmermann.mayfirst.org $ ./socks5 --byname --user foo12 --pass bar3 jirk5u4osbsr34t5.onion 11371 HTTP/1.1 200 OK Server: nginx/1.8.0 Date: Mon, 26 Oct 2015 20:09:30 GMT Content-Type: application/xhtml+xml Content-Length: 8259 Last-Modified: Sun, 25 Oct 2015 15:20:50 GMT Connection: close ETag: "562cf352-2043" Accept-Ranges: bytes Thus we get a different server after trying a few times with different user/password. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ag4ve.us at gmail.com Mon Oct 26 21:43:33 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 26 Oct 2015 16:43:33 -0400 Subject: GnuPG Github mirrors In-Reply-To: References: <562E796D.2020506@sumptuouscapital.com> Message-ID: On Mon, Oct 26, 2015 at 3:58 PM, Jeroen Ooms wrote: > On Mon, Oct 26, 2015 at 8:05 PM, Kristian Fiskerstrand > wrote: >> why would anyone want to move away from libre repository hosting (and issue tracker, wiki etc) in favor of a proprietary solution where you potentially have no control of your own data in the future? > > It's a *mirror*, I'm not sure where exactly you got the moving away > part. Think of it as a similar role as ftp mirrors, but then for > browsable code, commits, etc. Using it is entirely optional, you don't > have to give out control of your data to anyone. > I think the majority don't really care if a service hosting us has closed code of their own. However, this might pose an issue if github is ever owned and someone subverts gpg code - might i suggest signing *something*: % git lg | head -3 gits/gnupg (master) swlap1 * a6c2c09 - (HEAD, origin/master, origin/HEAD, master) gpg: Do not call an extra get_validity if no-show-uid-validity is used. (58 minutes ago) [N] * 91015d0 - gpg: Ensure all weak digest rejection notices are shown (5 hours ago) [N] * 0d37a40 - w32: Make it build again if Tofu support is not available. (5 hours ago) [N] % git log --tags --simplify-by-decoration --pretty="format:%ai %d [%G?]" | head -3 gits/gnupg (master) swlap1 2015-10-09 17:13:35 +0200 (tag: gnupg-2.1.9, origin/STABLE-BRANCH-2-2) [N] 2015-09-10 16:40:37 +0200 (tag: gnupg-2.1.8) [N] 2015-08-11 13:54:29 +0200 (tag: gnupg-2.1.7) [N] Ofcourse, no one linux kernel stuff and nothing *real bad* has happened to it yet, so FWIW. From ag4ve.us at gmail.com Mon Oct 26 21:44:43 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 26 Oct 2015 16:44:43 -0400 Subject: GnuPG Github mirrors In-Reply-To: References: <562E796D.2020506@sumptuouscapital.com> Message-ID: > Ofcourse, no one linux kernel stuff and nothing *real bad* has > happened to it yet, so FWIW. *no one signs linux kernel commits/tags/etc From dkg at fifthhorseman.net Mon Oct 26 23:14:48 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 26 Oct 2015 18:14:48 -0400 Subject: GnuPG Github mirrors In-Reply-To: References: <562E796D.2020506@sumptuouscapital.com> Message-ID: <87y4ep5lbb.fsf@alice.fifthhorseman.net> On Mon 2015-10-26 15:58:47 -0400, Jeroen Ooms wrote: > On Mon, Oct 26, 2015 at 8:05 PM, Kristian Fiskerstrand > wrote: >> why would anyone want to move away from libre repository hosting (and >> issue tracker, wiki etc) in favor of a proprietary solution where you >> potentially have no control of your own data in the future? > > It's a *mirror*, I'm not sure where exactly you got the moving away > part. Think of it as a similar role as ftp mirrors, but then for > browsable code, commits, etc. Using it is entirely optional, you don't > have to give out control of your data to anyone. Hi Jeroen-- Thanks for taking steps to try to help with the GnuPG community. It looks to me like you've taken more steps rapidly without consultation than others in the community are excited about. This is a community that has strong opinions about software and network service freedom, maintainability, and longevity. It's possible that the community as a whole will decide that github isn't the right place for the GnuPG project (even for a mirror), but hopefully that won't put you off from helping with the GnuPG community in other ways. Let me clarify some of the things that seem like they might be premature: Kristian has brought up the non-free tooling concern. This is a real issue, and it's clear that the centralization github provides has specific risks to a community that relies on it (it also has advantages, of course!). As users of free software and free network services, we can be more in control of our own data. GnuPG already has relationships with mirror servers in place: https://gnupg.org/mirrors.html It's not clear that a source repository mirror has the same properties or user interaction features. Github also has the capability for people to enter pull requests. (it also offers issue tracking, but it looks like that's turned off at the moment) Someone from the github scene might not realize that a pull request submitted to https://github.com/gpg/gnupg won't make its way to the upstream developers. Are you committing to forward these pull requests reliably to upstream? Do you plan to provide any sort of filtering or vetting of the pull requests? Other than the word "unofficial" at https://github.com/gpg, do you plan any other way to indicate the relationship between the github gpg project and the GNU Privacy Guard? All the best, --dkg From rjh at sixdemonbag.org Tue Oct 27 04:44:26 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 26 Oct 2015 23:44:26 -0400 Subject: GnuPG Github mirrors In-Reply-To: References: Message-ID: <562EF31A.2050407@sixdemonbag.org> > Following other GNU projects such as Linux and R, the GnuPG git server > is now mirrored on Github: > > https://github.com/gpg You certainly have the right to do this under the GPL, but is it wise? Without community signoff your repo is going to be an unofficial mirror. People will file bug reports there and not on our bug tracker; worse, since you're the owner, they'll expect you to fix their issues. If the community decides to go the GitHub route, these problems go away. But I don't think you'll have much success with that until you clearly articulate *why* such a move is a good thing. I currently have commit privs to the GnuPG FAQ, for instance, so convince me: why should I abandon a system that works well for GitHub? From dkg at fifthhorseman.net Tue Oct 27 05:01:32 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Oct 2015 00:01:32 -0400 Subject: [STABLE-BRANCH-1-4 PATCH 2/2] gpg: Add option --weak-digest to gpg and gpgv. In-Reply-To: <1445918492-15054-1-git-send-email-dkg@fifthhorseman.net> References: <1445918492-15054-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1445918492-15054-2-git-send-email-dkg@fifthhorseman.net> * g10/options.h: Add weak_digests linked list to opts. * g10/main.h: Declare weakhash linked list struct and additional_weak_digest() function to insert newly-declared weak digests into opts. * g10/misc.c: (additional_weak_digest): New function. (print_digest_algo_note): Check for deprecated digests. * g10/sig-check.c: (do_check): Reject all weak digests. * g10/gpg.c: Add --weak-digest option to gpg. * doc/gpg.texi: Document gpg --weak-digest option. * g10/gpgv.c: Add --weak-digest option to gpgv. * doc/gpgv.texi: Document gpgv --weak-digest option. -- gpg and gpgv treat signatures made over MD5 as unreliable, unless the user supplies --allow-weak-digests to gpg. Signatures over any other digest are considered acceptable. Despite SHA-1 being a mandatory-to-implement digest algorithm in RFC 4880, the collision-resistance of SHA-1 is weaker than anyone would like it to be. Some operators of high-value targets that depend on OpenPGP signatures may wish to require their signers to use a stronger digest algorithm than SHA1, even if the OpenPGP ecosystem at large cannot deprecate SHA1 entirely today. This changeset adds a new "--weak-digest DIGEST" option for both gpg and gpgv, which makes it straightforward for anyone to treat any signature or certification made over the specified digest as unreliable. This option can be supplied multiple times if the operator wishes to deprecate multiple digest algorithms, and will be ignored completely if the operator supplies --allow-weak-digests (as before). MD5 is always considered weak, regardless of any further --weak-digest options supplied. Signed-off-by: Daniel Kahn Gillmor (this is a rough cherry-pick of applying the following commits to STABLE-BRANCH-1-4: 76afaed65e3b0ddfa4923cb577ada43217dd4b18 b98939812abf6c643c752ce7c325f98039a1a9e2 91015d021b3dcbe21ad0e580a4f34c523abf9e72 ) --- doc/gpg.texi | 17 ++++++++++++++--- doc/gpgv.texi | 8 ++++++++ g10/gpg.c | 7 +++++++ g10/gpgv.c | 5 +++++ g10/main.h | 9 +++++++++ g10/misc.c | 38 ++++++++++++++++++++++++++++++++++++-- g10/options.h | 1 + g10/sig-check.c | 25 ++++++++++++------------- 8 files changed, 92 insertions(+), 18 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index f7dad42..3c163ce 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2610,9 +2610,20 @@ message was tampered with intentionally by an attacker. @item --allow-weak-digest-algos @opindex allow-weak-digest-algos -Signatures made with the broken MD5 algorithm are normally rejected -with an ``invalid digest algorithm'' message. This option allows the -verification of signatures made with such weak algorithms. +Signatures made with known-weak digest algorithms are normally +rejected with an ``invalid digest algorithm'' message. This option +allows the verification of signatures made with such weak algorithms. +MD5 is the only digest algorithm considered weak by default. See also + at option{--weak-digest} to reject other digest algorithms. + + at item --weak-digest @code{name} + at opindex weak-digest +Treat the specified digest algorithm as weak. Signatures made over +weak digests algorithms are normally rejected. This option can be +supplied multiple times if multiple algorithms should be considered +weak. See also @option{--allow-weak-digest-algos} to disable +rejection of weak digests. MD5 is always considered weak, and does +not need to be listed explicitly. @item --no-default-keyring diff --git a/doc/gpgv.texi b/doc/gpgv.texi index 0cb2360..7172a8c 100644 --- a/doc/gpgv.texi +++ b/doc/gpgv.texi @@ -115,6 +115,14 @@ checks into warnings. @include opt-homedir.texi + at item --weak-digest @code{name} + at opindex weak-digest +Treat the specified digest algorithm as weak. Signatures made over +weak digests algorithms are normally rejected. This option can be +supplied multiple times if multiple algorithms should be considered +weak. MD5 is always considered weak, and does not need to be listed +explicitly. + @end table @mansect return value diff --git a/g10/gpg.c b/g10/gpg.c index 20d249a..9e37b88 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -377,6 +377,7 @@ enum cmd_and_opt_values oAllowMultipleMessages, oNoAllowMultipleMessages, oAllowWeakDigestAlgos, + oWeakDigest, oNoop }; @@ -689,6 +690,7 @@ static ARGPARSE_OPTS opts[] = { { oPersonalCipherPreferences, "personal-cipher-preferences", 2, "@"}, { oPersonalDigestPreferences, "personal-digest-preferences", 2, "@"}, { oPersonalCompressPreferences, "personal-compress-preferences", 2, "@"}, + { oWeakDigest, "weak-digest", 2, "@"}, /* Aliases. I constantly mistype these, and assume other people do as well. */ { oPersonalCipherPreferences, "personal-cipher-prefs", 2, "@"}, @@ -1927,6 +1929,8 @@ main (int argc, char **argv ) #endif opt.disable_keypad = 1; /* No keypad support; use gpg2 instead. */ #endif /*ENABLE_CARD_SUPPORT*/ + opt.weak_digests = NULL; + additional_weak_digest("MD5"); /* check whether we have a config file on the commandline */ orig_argc = argc; @@ -2797,6 +2801,9 @@ main (int argc, char **argv ) case oDisplay: opt.display = pargs.r.ret_str; break; case oTTYname: opt.ttyname = pargs.r.ret_str; break; case oTTYtype: opt.ttytype = pargs.r.ret_str; break; + case oWeakDigest: + additional_weak_digest(pargs.r.ret_str); + break; case oLCctype: opt.lc_ctype = pargs.r.ret_str; break; case oLCmessages: opt.lc_messages = pargs.r.ret_str; break; case oGroup: add_group(pargs.r.ret_str); break; diff --git a/g10/gpgv.c b/g10/gpgv.c index b679853..b2721ba 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -60,6 +60,7 @@ enum cmd_and_opt_values { aNull = 0, oStatusFD, oLoggerFD, oHomedir, + oWeakDigest, aTest }; @@ -75,6 +76,7 @@ static ARGPARSE_OPTS opts[] = { { oStatusFD, "status-fd" ,1, N_("|FD|write status info to this FD") }, { oLoggerFD, "logger-fd",1, "@" }, { oHomedir, "homedir", 2, "@" }, /* defaults to "~/.gnupg" */ + { oWeakDigest, "weak-digest", 2, "@" }, /* defaults to "~/.gnupg" */ {0} }; @@ -143,6 +145,7 @@ main( int argc, char **argv ) opt.keyserver_options.options|=KEYSERVER_AUTO_KEY_RETRIEVE; opt.trust_model = TM_ALWAYS; opt.batch = 1; + opt.weak_digests = NULL; opt.homedir = default_homedir (); @@ -151,6 +154,7 @@ main( int argc, char **argv ) dotlock_disable (); set_native_charset (NULL); /* Try to auto set the character set */ + additional_weak_digest("MD5"); pargs.argc = &argc; pargs.argv = &argv; @@ -164,6 +168,7 @@ main( int argc, char **argv ) case oStatusFD: set_status_fd( pargs.r.ret_int ); break; case oLoggerFD: log_set_logfile( NULL, pargs.r.ret_int ); break; case oHomedir: opt.homedir = pargs.r.ret_str; break; + case oWeakDigest: additional_weak_digest(pargs.r.ret_str); break; case oIgnoreTimeConflict: opt.ignore_time_conflict = 1; break; default : pargs.err = 2; break; } diff --git a/g10/main.h b/g10/main.h index dbc8d8f..f2fb818 100644 --- a/g10/main.h +++ b/g10/main.h @@ -53,6 +53,14 @@ struct groupitem struct groupitem *next; }; +struct weakhash +{ + int algo; + int rejection_shown; + struct weakhash *next; +}; + + /*-- gpg.c --*/ extern int g10_errors_seen; @@ -64,6 +72,7 @@ extern int g10_errors_seen; void print_pubkey_algo_note( int algo ); void print_cipher_algo_note( int algo ); void print_digest_algo_note( int algo ); +void additional_weak_digest (const char* digestname); /*-- armor.c --*/ char *make_radix64_string( const byte *data, size_t len ); diff --git a/g10/misc.c b/g10/misc.c index 2b38a8f..c863be4 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -332,6 +332,8 @@ print_cipher_algo_note( int algo ) void print_digest_algo_note( int algo ) { + const struct weakhash *weak; + if(algo >= 100 && algo <= 110) { static int warn=0; @@ -342,8 +344,11 @@ print_digest_algo_note( int algo ) digest_algo_to_string(algo)); } } - else if(algo==DIGEST_ALGO_MD5) - md5_digest_warn (1); + else + for (weak = opt.weak_digests; weak; weak = weak->next) + if (weak->algo == algo) + log_info (_("WARNING: digest algorithm %s is deprecated\n"), + digest_algo_to_string(algo)); } /* Return a string which is used as a kind of process ID */ @@ -1310,3 +1315,32 @@ path_access(const char *file,int mode) } #endif /*ndef __VMS*/ + +/* Ignore signatures and certifications made over certain digest + * algorithms. This allows users to deprecate support for algorithms + * they are not willing to rely on. + */ +void +additional_weak_digest (const char* digestname) +{ + struct weakhash *weak = NULL; + const int algo = string_to_digest_algo(digestname); + + if (algo == 0) + { + log_error(_("Unknown weak digest '%s'\n"), digestname); + return; + } + + /* Check to ensure it's not already present. */ + for (weak = opt.weak_digests; weak != NULL; weak = weak->next) + if (algo == weak->algo) + return; + + /* Add it to the head of the list. */ + weak = xmalloc(sizeof(*weak)); + weak->algo = algo; + weak->rejection_shown = 0; + weak->next = opt.weak_digests; + opt.weak_digests = weak; +} diff --git a/g10/options.h b/g10/options.h index 26d65e5..5aa3a04 100644 --- a/g10/options.h +++ b/g10/options.h @@ -164,6 +164,7 @@ struct prefitem_t *personal_cipher_prefs; prefitem_t *personal_digest_prefs; prefitem_t *personal_compress_prefs; + struct weakhash *weak_digests; int no_perm_warn; int no_mdc_warn; char *temp_dir; diff --git a/g10/sig-check.c b/g10/sig-check.c index 94f0cc5..6bac630 100644 --- a/g10/sig-check.c +++ b/g10/sig-check.c @@ -239,26 +239,25 @@ do_check( PKT_public_key *pk, PKT_signature *sig, MD_HANDLE digest, { MPI result = NULL; int rc=0; + struct weakhash *weak; if( (rc=do_check_messages(pk,sig,r_expired,r_revoked)) ) return rc; - if (sig->digest_algo == DIGEST_ALGO_MD5 - && !opt.flags.allow_weak_digest_algos) - { - static int shown; - - if (!shown) + if (!opt.flags.allow_weak_digest_algos) + for (weak = opt.weak_digests; weak; weak = weak->next) + if (sig->digest_algo == weak->algo) { - log_info - (_("Note: signatures using the %s algorithm are rejected\n"), - "MD5"); - shown = 1; + if (!weak->rejection_shown) + { + log_info + (_("Note: signatures using the %s algorithm are rejected\n"), + digest_algo_to_string(sig->digest_algo)); + weak->rejection_shown = 1; + } + return G10ERR_DIGEST_ALGO; } - return G10ERR_DIGEST_ALGO; - } - /* make sure the digest algo is enabled (in case of a detached signature)*/ md_enable( digest, sig->digest_algo ); -- 2.6.1 From dkg at fifthhorseman.net Tue Oct 27 05:01:31 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Oct 2015 00:01:31 -0400 Subject: [STABLE-BRANCH-1-4 PATCH 1/2] gpg: Reject signatures made with MD5. Message-ID: <1445918492-15054-1-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * g10/gpg.c: Add option --allow-weak-digest-algos. (main): Set option also in PGP2 mode. * g10/options.h (struct opt): Add flags.allow_weak_digest_algos. * g10/sig-check.c (do_check): Reject MD5 signatures. * tests/openpgp/gpg.conf.tmpl: Add allow_weak_digest_algos. -- (cherry picked from commit f90cfe6b66269de0154d810c5cee1fe9a5af475c) Resolved conflicts: g10/gpg.c - adjust. tests/openpgp/defs.inc - no changes --- checks/options | 1 + doc/gpg.texi | 9 ++++++++- g10/gpg.c | 7 +++++++ g10/options.h | 1 + g10/sig-check.c | 16 ++++++++++++++++ 5 files changed, 33 insertions(+), 1 deletion(-) diff --git a/checks/options b/checks/options index 7060a66..7db73be 100644 --- a/checks/options +++ b/checks/options @@ -3,3 +3,4 @@ no-secmem-warning no-permission-warning batch no-auto-check-trustdb +allow-weak-digest-algos diff --git a/doc/gpg.texi b/doc/gpg.texi index 27ae18c..f7dad42 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2178,7 +2178,7 @@ available, but the MIT release is a good common baseline. This option implies @option{--rfc1991 --disable-mdc --no-force-v4-certs - --escape-from-lines --force-v3-sigs + --escape-from-lines --force-v3-sigs --allow-weak-digest-algos --cipher-algo IDEA --digest-algo MD5 --compress-algo ZIP}. It also disables @option{--textmode} when encrypting. @@ -2608,6 +2608,13 @@ necessary to get as much data as possible out of the corrupt message. However, be aware that a MDC protection failure may also mean that the message was tampered with intentionally by an attacker. + at item --allow-weak-digest-algos + at opindex allow-weak-digest-algos +Signatures made with the broken MD5 algorithm are normally rejected +with an ``invalid digest algorithm'' message. This option allows the +verification of signatures made with such weak algorithms. + + @item --no-default-keyring @opindex no-default-keyring Do not add the default keyrings to the list of keyrings. Note that diff --git a/g10/gpg.c b/g10/gpg.c index 3f0d305..20d249a 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -376,6 +376,7 @@ enum cmd_and_opt_values oDisableDSA2, oAllowMultipleMessages, oNoAllowMultipleMessages, + oAllowWeakDigestAlgos, oNoop }; @@ -725,6 +726,7 @@ static ARGPARSE_OPTS opts[] = { { oDisableDSA2, "disable-dsa2", 0, "@"}, { oAllowMultipleMessages, "allow-multiple-messages", 0, "@"}, { oNoAllowMultipleMessages, "no-allow-multiple-messages", 0, "@"}, + { oAllowWeakDigestAlgos, "allow-weak-digest-algos", 0, "@"}, /* These two are aliases to help users of the PGP command line product use gpg with minimal pain. Many commands are common @@ -2880,6 +2882,10 @@ main (int argc, char **argv ) opt.flags.allow_multiple_messages=0; break; + case oAllowWeakDigestAlgos: + opt.flags.allow_weak_digest_algos = 1; + break; + case oNoop: break; default : pargs.err = configfp? 1:2; break; @@ -3047,6 +3053,7 @@ main (int argc, char **argv ) opt.pgp2_workarounds = 1; opt.ask_sig_expire = 0; opt.ask_cert_expire = 0; + opt.flags.allow_weak_digest_algos = 1; xfree(def_digest_string); def_digest_string = xstrdup("md5"); xfree(s2k_digest_string); diff --git a/g10/options.h b/g10/options.h index f3543b1..26d65e5 100644 --- a/g10/options.h +++ b/g10/options.h @@ -230,6 +230,7 @@ struct unsigned int utf8_filename:1; unsigned int dsa2:1; unsigned int allow_multiple_messages:1; + unsigned int allow_weak_digest_algos:1; unsigned int large_rsa:1; } flags; diff --git a/g10/sig-check.c b/g10/sig-check.c index b7709c1..94f0cc5 100644 --- a/g10/sig-check.c +++ b/g10/sig-check.c @@ -243,6 +243,22 @@ do_check( PKT_public_key *pk, PKT_signature *sig, MD_HANDLE digest, if( (rc=do_check_messages(pk,sig,r_expired,r_revoked)) ) return rc; + if (sig->digest_algo == DIGEST_ALGO_MD5 + && !opt.flags.allow_weak_digest_algos) + { + static int shown; + + if (!shown) + { + log_info + (_("Note: signatures using the %s algorithm are rejected\n"), + "MD5"); + shown = 1; + } + + return G10ERR_DIGEST_ALGO; + } + /* make sure the digest algo is enabled (in case of a detached signature)*/ md_enable( digest, sig->digest_algo ); -- 2.6.1 From dimitri.j.ledkov at intel.com Tue Oct 27 11:29:17 2015 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Tue, 27 Oct 2015 10:29:17 +0000 Subject: GnuPG Github mirrors In-Reply-To: <562EF31A.2050407@sixdemonbag.org> References: <562EF31A.2050407@sixdemonbag.org> Message-ID: On 27 October 2015 at 03:44, Robert J. Hansen wrote: >> Following other GNU projects such as Linux and R, the GnuPG git server >> is now mirrored on Github: >> >> https://github.com/gpg > > You certainly have the right to do this under the GPL, but is it wise? > Without community signoff your repo is going to be an unofficial mirror. > People will file bug reports there and not on our bug tracker; worse, > since you're the owner, they'll expect you to fix their issues. > In git, all mirrors are equal, including the one on my laptop. Bug tracker looks to be explicitly disabled there. > If the community decides to go the GitHub route, these problems go away. > But I don't think you'll have much success with that until you clearly > articulate *why* such a move is a good thing. I currently have commit > privs to the GnuPG FAQ, for instance, so convince me: why should I > abandon a system that works well for GitHub? I don't have upstream commit access. Nor do I have a publicly accessible git hosting. For me, github mirrors is a way to efficiently do server-side git repository clone and host my patches for others to discover / test / comment on / pull from. And trust me, none of the github users would be confused that the thing over there is a mirror. Especially how prominently it is shown that this repository is from git.gnupg.org in the top-level description and official sites are at gnupg.org from readme; issues disabled; and lack of "typical" github development activity on the github site. Think less about it as a thing for commiters to move to, but rather think of it as a service for non-commiter / prospective developers to fork from. From that standpoint it is exceptionally useful. From core developers point of view, github mirror is probably something like irrelevant to possibly marginally useful (if it ever results in recruiting / adding a core developer). -- Regards, Dimitri. 63 sleeps till Christmas, or less https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From jeroen.ooms at stat.ucla.edu Tue Oct 27 11:24:28 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Tue, 27 Oct 2015 11:24:28 +0100 Subject: GnuPG Github mirrors In-Reply-To: <562EF31A.2050407@sixdemonbag.org> References: <562EF31A.2050407@sixdemonbag.org> Message-ID: On Tue, Oct 27, 2015 at 4:44 AM, Robert J. Hansen wrote: > You certainly have the right to do this under the GPL, but is it wise? If nothing else it provides a nice way for Github users to monitor GnuPG development by subscribing to the repo or via the API. > Without community signoff your repo is going to be an unofficial mirror. People will file bug reports there and not on our bug tracker; worse, since you're the owner, they'll expect you to fix their issues. The repo is entirely read-only, issues and wiki are currently disabled. The mirror has been running for about 6 weeks and there have been zero incidents of people trying to send patches. Actually I also run a few other mirrors for much larger projects and these experiences suggest that users and developers are, almost without exception, sufficiently intelligent to find the original developers. But if we ever encounter such and incident I'll make sure to redirect those users to the official gnupg git server and mailing lists. > If the community decides to go the GitHub route, these problems go away. But I don't think you'll have much success with that until you clearly articulate *why* such a move is a good thing. I currently have commit privs to the GnuPG FAQ, for instance, so convince me: why should I abandon a system that works well for GitHub? I am not advocating GnuPG should move to Github. Obviously people have strong opinions about this. That said, the main argument why many open source projects enjoy Github is because it makes it so much easier for others to get involved and contribute, which catalyses development and discussion around your project. For example if I currently have a suggestion for a new GnuPG FAQ entry I would have to download the code, create a patch, send that to the mailing list, and then hope that you are actively reading the mailing list, apply the patch and push. In Github I would simply clone the repo, commit the changes, and send you a pull request in which we can together review/discuss/tweak the changes until you are pleased and merge. For a FAQ entry this might be minor, but for a significant code overhaul this is a more powerful way to collaborate than emailing patches. Either way this discussion has been had dozens of times over the internet, no need to repeat all arguments. In this video from earlier this year, Daniel Stenberg (maintainer of libcurl) explains why he decided to overcome skepticism and start accepting contributions from Github users: https://youtu.be/ovVZtFoglOA?t=140 . This was six months ago and there has been a significant increase in fixes and activity in the project since then. From aheinecke at intevation.de Tue Oct 27 15:30:23 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 27 Oct 2015 15:30:23 +0100 Subject: TOFU performance / DB format In-Reply-To: <87io5x8qbf.wl-neal@walfield.org> References: <87oagi9tm1.wl-neal@walfield.org> <87r3ko8ffk.wl-neal@walfield.org> <87io5x8qbf.wl-neal@walfield.org> Message-ID: <1546901.kC3nCEYk5U@esus> Hi, On Friday 23 October 2015 19:09:24 Neal H. Walfield wrote: > Unfortunately, this change only helps with the flat database format. > For the split forat, we're still looking at over 90 seconds for the > initial listing and 3 seconds for subsequent listings. I can confirm that thanks to your performance improvements initializing the flat db is now really as fast as I would expect. << 1second. :-) Great, Thanks! > I'd be interested to hear people's opinions about whether the split > format (with its ability to be more easily synced) is still > interesting despite the slow performance. I'm not sure that keeping two database formats and making them configurable is a good idea. - It makes things harder to maintain. Obviously you have two codepaths with different issues. e.g. The performance for the flat format is now fine while the performance for the split format is still bad. You will receive bug reports and you will always have to ask "are you using flat / split" The majority will use whatever is default but you will still have to maintain the code for the minority that uses another option. - It makes things harder to document. "If you are using tofu-db-split format you will have to sync that folder. If you are using tofo-db-flat format you will have to sync that db." etc. - I don't see how the split format solves two way sync: -- Two way sync is not really supported in GnuPG. We have the monolithic keyring and the trust.db and It's just not supported afaik two merge two gnupg home dirs. -- How should such a two-way sync work? If I would only use the "last updated" db from two systems how would I merge them in case of conflicts? With regards to easier sync. It can be easier Just to copy bulk data if it is small then lots and lots of different files. E.g with rsync to a system connected over the internet i see the following values: (Ok that is cheating a bit as the tofu.db does not really contain any data but the initialization) First run: rsync -rvzP tofu.d remote:/tmp/tofu.d 0.54s user 0.10s system 3% cpu 20.231 total rsync -rvzP tofu.db remote:/tmp/tofu.db 0.06s user 0.00s system 1% cpu 4.323 total Second run: rsync -rvzP tofu.d remote:/tmp/tofu.d 0.39s user 0.08s system 9% cpu 4.739 total rsync -rvzP tofu.db remote:/tmp/tofu.db 0.02s user 0.00s system 1% cpu 1.498 total 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: 181 bytes Desc: This is a digitally signed message part. URL: From pete at petertodd.org Tue Oct 27 15:06:34 2015 From: pete at petertodd.org (Peter Todd) Date: Tue, 27 Oct 2015 10:06:34 -0400 Subject: GnuPG Github mirrors In-Reply-To: References: <562E796D.2020506@sumptuouscapital.com> Message-ID: <20151027140634.GB31473@muck> On Mon, Oct 26, 2015 at 04:44:43PM -0400, shawn wilson wrote: > > Ofcourse, no one linux kernel stuff and nothing *real bad* has > > happened to it yet, so FWIW. > > *no one signs linux kernel commits/tags/etc Actually I just checked https://github.com/torvalds/linux, and lots of commits are signed. (mainly merges) Dunno how that's actually used in practice, but saying "no-one" signs Linux kernel commits is definitely wrong. FWIW, Bitcoin Core has an explicit policy of having git master be always signed, along with all tags. We also have hook scripts to enforce this. -- 'peter'[:-1]@petertodd.org 0000000000000000059b71192a95b5e19f91aa4eac2f1bb9f54befc39a84a9ae -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 650 bytes Desc: Digital signature URL: From bernhard at intevation.de Tue Oct 27 16:33:19 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 27 Oct 2015 16:33:19 +0100 Subject: BSI (DE) contract: preparing evaluation of GnuPG Message-ID: <201510271633.29674.bernhard@intevation.de> Hello! The German Federal Office for Information Security (BSI) [1] contracted the companies g10code/Intevation to harden and document the Free Software products Gpg4win and "Gpg4KDE" with the aim to prepare them for evaluation and a potential certification for documents that carry the German classification "restricted". Of course this is a lot about GnuPG with its both abilities in OpenPGP (for PGP/MIME) and CMS (for S/MIME). We expect all users to profit, because this is (another) check of the source code, architecture and GnuPG's documentation. Within the project we plan only small software changes: We will probably create a way to configure GnuPG/Kleopatra and its builds for Windows and GNU/Linux to run in a more restricted mode. This mode would only allow settings and algorithms that satisfy the regulations for exchanging emails and documents that are classified as "restricted" (the German "Verschlusssache - nur f?r den Dienstgebrauch", abbreviated as "VS-NfD"). If you are interested, look out for details and progress on wiki.gnupg.org as we add more details there within the next weeks. Let me know, if you have questions! Bernhard Details: From the announcement of the public tender [2] "194 Gpg4VSNfD": """ Das vom BSI weiterentwickelte und gef?rderte Windowsprogramm Gpg4win und die Linux-Variante Gpg4KDE sollen so geh?rtet und die Dokumentation aufgearbeitet werden, dass sie zur Benutzung f?r ?Verschlusssachen - Nur f?r den Dienstgebrauch? (VS-NfD) zugelassen werden k?nnen. Diese Produkte basieren auf einer gemeinsamen Codebasis f?r Linux und Windows. Mit diesem Projekt erfolgt die notwendige Aufarbeitung der Dokumentation und der Produkte Gpg4win und Gpg4KDE, so dass anschlie?end f?r eine spezifische Konfiguration der Produkte eine Evaluierung und Zulassung f?r VS-NfD f?r Windows bzw. Linux erfolgen kann. """ [1] https://www.bsi.bund.de/EN/Home/home_node.html [2] http://www.evergabe-online.de/home?id=96898 -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 wk at gnupg.org Tue Oct 27 16:31:08 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Oct 2015 16:31:08 +0100 Subject: GnuPG Github mirrors In-Reply-To: (Jeroen Ooms's message of "Tue, 27 Oct 2015 11:24:28 +0100") References: <562EF31A.2050407@sixdemonbag.org> Message-ID: <874mhcba6b.fsf@vigenere.g10code.de> On Tue, 27 Oct 2015 11:24, jeroen.ooms at stat.ucla.edu said: > For example if I currently have a suggestion for a new GnuPG FAQ entry > I would have to download the code, create a patch, send that to the > mailing list, and then hope that you are actively reading the mailing > list, apply the patch and push. In Github I would simply clone the > repo, commit the changes, and send you a pull request in which we can > together review/discuss/tweak the changes until you are pleased and We already discuss patches on the mailing list. Sending and applying patches via by mail is a native Git feature and all workflow has been optimized for this. Sending URLs is an alien thing and does only work if you have an online connection. Prospective developers with a GitHub mindset will have a hard time to get accustomed to regular Free Software development. I have seen people evangelizing for Git but didn't understand the basic commands because they come from Github. Sorry, you need to get your feet wet before diving into GnuPG development. > this year, Daniel Stenberg (maintainer of libcurl) explains why he Daniel is not known as a strong supporter of the Free Software idea and thus he sets other priorities. Anyway, feel free to mirror stuff wherever you like - after all this is what Free Software is about. To avoid confusion it would be nice to clearly state that the commonly used GnuPG version is hosted elsewhere. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Tue Oct 27 17:04:04 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 27 Oct 2015 12:04:04 -0400 Subject: GnuPG Github mirrors In-Reply-To: References: <562EF31A.2050407@sixdemonbag.org> Message-ID: <562FA074.2010506@sixdemonbag.org> > For example if I currently have a suggestion for a new GnuPG FAQ entry > I would have to download the code, create a patch, send that to the > mailing list, and then hope that you are actively reading the mailing > list, apply the patch and push. I don't accept patches to the FAQ. I never have. This is because it's important the FAQ have consistent grammar, syntax, spelling, and typography. (For instance, you'll see the FAQ uses proper ?curved? quotation marks rather than the normally-seen 'straight' ones.) When I receive a patch from someone, even from Werner, I propose it to the gnupg-users list, solicit community feedback, and if the community accepts it then I rewrite the contribution in Standard American English taking into account the community feedback. > merge. For a FAQ entry this might be minor, but for a significant code > overhaul this is a more powerful way to collaborate than emailing > patches. This may be true for other projects. I'm not convinced it's true for us. I've never heard anyone complain about it being too hard to submit patches to GnuPG. I've heard people complain about patches not being accepted, sure -- but never that it was too hard to contribute. From git at internot.info Tue Oct 27 17:30:51 2015 From: git at internot.info (Joshua Rogers) Date: Wed, 28 Oct 2015 03:30:51 +1100 Subject: GnuPG Github mirrors In-Reply-To: References: <562EF31A.2050407@sixdemonbag.org> Message-ID: <562FA6BB.8040406@internot.info> On 27/10/15 21:24, Jeroen Ooms wrote: > For example if I currently have a suggestion for a new GnuPG FAQ entry > I would have to download the code, create a patch, send that to the > mailing list, and then hope that you are actively reading the mailing > list, apply the patch and push. In Github I would simply clone the > repo, commit the changes, and send you a pull request in which we can > together review/discuss/tweak the changes until you are pleased and > merge. For a FAQ entry this might be minor, but for a significant code > overhaul this is a more powerful way to collaborate than emailing > patches. At the beginning of the year, I made a few patches that I sent to this list. I originally didn't know how to use git-send-email and the likes(I could have git --diff'd and sent it directly through my email client, however), but Daniel was more than happy to help me get on the right path to learning how to submit patches correctly. As Werner said, it's likely a good thing that people learn how to use git beyond just 'git push origin master'. It is likely a good thing that they expand their horizons beyond 'git' being just something used on Github, too. So, I don't think there is a "need" for moving to Github to be easier to access. On a personal note, by somebody that is not "involved" in the development or anything to do with GnuPG other than reading the mailing list, I see no problem with it being on Github, as long as it is made 100% clear it is not the official repository. Even now, there are 61 results that show up for gnupg on Github: https://github.com/search?l=C&q=Gnupg&type=Repositories&utf8=%E2%9C%93 And 1777 for 'gpg' : https://github.com/search?q=gpg&ref=searchresults&type=Repositories&utf8=%E2%9C%93 However, 'gpg' comes up with a lot of customized tools. Also.. > It's a *mirror*, I'm not sure where exactly you got the moving away > part. Think of it as a similar role as ftp mirrors, but then for > browsable code, commits, etc. Using it is entirely optional, you don't > have to give out control of your data to anyone. What's wrong with http://git.gnupg.org/cgi-bin/gitweb.cgi? Just my 2 cents. Thanks, -- -- Joshua Rogers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Oct 27 18:58:21 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Oct 2015 13:58:21 -0400 Subject: GnuPG Github mirrors In-Reply-To: <562FA6BB.8040406@internot.info> References: <562EF31A.2050407@sixdemonbag.org> <562FA6BB.8040406@internot.info> Message-ID: <87vb9s42iq.fsf@alice.fifthhorseman.net> On Tue 2015-10-27 12:30:51 -0400, Joshua Rogers wrote: > At the beginning of the year, I made a few patches that I sent to this > list. I originally didn't know how to use git-send-email and the likes(I > could have git --diff'd and sent it directly through my email client, > however), but Daniel was more than happy to help me get on the right > path to learning how to submit patches correctly. It would be a really useful contribution to the community for someone to publish concise documentation of their workflow of how they interact with the GnuPG project as a non-core developer. (hint, hint) I know we all have our own idiosyncrasies, and no one wants to inflict their workflow on anyone else. But one of the things that github offers is a standardized workflow across projects. I personally dislike that particular workflow (i don't like centralized servers; i prefer a detached, e-mail-oriented workflow) but it's true that it probably does facilitate participation by others simply because of its scale of adoption. that's the network effect for you :( Having someone be willing to act as a bridge between the github workflow and the mailing list workflow does seem like a useful contribution to the community, as much as we'd like to ultimately invite the github-influenced folks to come join us in happy fun e-mailed patches land. --dkg From ag4ve.us at gmail.com Tue Oct 27 19:08:31 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Tue, 27 Oct 2015 14:08:31 -0400 Subject: GnuPG Github mirrors In-Reply-To: References: <562EF31A.2050407@sixdemonbag.org> Message-ID: On Oct 27, 2015 7:29 AM, "Dimitri John Ledkov" wrote: > > On 27 October 2015 at 03:44, Robert J. Hansen wrote: > >> Following other GNU projects such as Linux and R, the GnuPG git server > >> is now mirrored on Github: > >> > >> https://github.com/gpg > > > > You certainly have the right to do this under the GPL, but is it wise? > > Without community signoff your repo is going to be an unofficial mirror. > > People will file bug reports there and not on our bug tracker; worse, > > since you're the owner, they'll expect you to fix their issues. > > > > In git, all mirrors are equal, including the one on my laptop. > Well kinda and no. Git was created like that but if you look at the majority of the repos most people have, you'll probably notice most use only one repo (which is probably a bare repo. This means that that repo is basically authoritative to them. Hence my comment about commits etc not being signed - I trust that code is how it was intended (or they'll find out they were owned almost a year ago and let everyone know they're going through a year long code audit to figure out if anything was messed with) if it's hosted by the maintainer. If hosted somewhere else is maintaining the server we may never know if they or someone else subverts the code. So while I don't fundamentally care if the code is hosted on github, bitbucket, sf, or whoever else, I do care if nothing is signed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Oct 27 20:54:14 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Oct 2015 15:54:14 -0400 Subject: [STABLE-BRANCH-1-4 PATCH] fix a typo Message-ID: <1445975654-1833-1-git-send-email-dkg@fifthhorseman.net> --- doc/gpg.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index 27ae18c..7a6b64b 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -532,7 +532,7 @@ This section explains the main commands for key management @item --gen-key @opindex gen-key -Generate a new key pair using teh current default parameters. This is +Generate a new key pair using the current default parameters. This is the standard command to create a new key. There is also a feature which allows you to create keys in batch -- 2.6.1 From dkg at fifthhorseman.net Tue Oct 27 22:09:40 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Oct 2015 17:09:40 -0400 Subject: [PATCH 1/4] clarify agent's KEYWRAP_KEY description Message-ID: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> * agent/command.c (hlp_keywrap_key): improve description about lifespan of KEYWRAP_KEY Signed-Off-By: Daniel Kahn Gillmor --- agent/command.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/agent/command.c b/agent/command.c index f09a2ff..509f457 100644 --- a/agent/command.c +++ b/agent/command.c @@ -1978,7 +1978,7 @@ static const char hlp_keywrap_key[] = "mechanism or not used at all if the key is a pre-shared key. In any\n" "case wrapping the import and export of keys is a requirement for\n" "certain cryptographic validations and thus useful. The key persists\n" - "a RESET command but may be cleared using the option --clear.\n" + "until a RESET command but may be cleared using the option --clear.\n" "\n" "Supported modes are:\n" " --import - Return a key to import a key into gpg-agent\n" -- 2.6.1 From dkg at fifthhorseman.net Tue Oct 27 22:09:41 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Oct 2015 17:09:41 -0400 Subject: [PATCH 2/4] clarify gpgkey2ssh usage In-Reply-To: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> References: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1445980183-4448-2-git-send-email-dkg@fifthhorseman.net> * tools/gpgkey2ssh.c: (main) improve gpgkey2ssh usage and error reporting -- This update makes the tool marginally more intelligible to a normal user, without changing its behavior. Signed-Off-By: Daniel Kahn Gillmor --- tools/gpgkey2ssh.c | 43 ++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git a/tools/gpgkey2ssh.c b/tools/gpgkey2ssh.c index d22c5ac..3b4b076 100644 --- a/tools/gpgkey2ssh.c +++ b/tools/gpgkey2ssh.c @@ -34,10 +34,13 @@ #include #include #include +#include #include "util.h" #include "sysutils.h" +#define PGM "gpgkey2ssh" + typedef struct pkdbuf @@ -75,7 +78,7 @@ retrieve_key_material (FILE *fp, const char *hexkeyid, int *algorithm_id, id = 0; /* Loop over all records until we have found the subkey - corresponsing to the fingerprint. Inm general the first record + corresponding to the fingerprint. In general the first record should be the pub record, but we don't rely on that. Given that we only need to look at one key, it is sufficient to compare the keyid so that we don't need to look at "fpr" records. */ @@ -242,6 +245,16 @@ key_to_blob (unsigned char **blob, size_t *blob_n, const char *identifier, ...) } int +gpgkey2ssh_usage (int n, FILE* f) +{ + fprintf(f, "Usage: " PGM " KEYID\n"); + fprintf(f, " KEYID must be a 16 hex-digit OpenPGP long key ID\n"); + fprintf(f, " an OpenSSH-style public key line produced\n"); + fprintf(f, " (only RSA and DSA keys are supported)\n"); + return n; +} + +int main (int argc, char **argv) { const char *keyid; @@ -256,6 +269,8 @@ main (int argc, char **argv) size_t blob_n; struct b64state b64_state; const char *identifier; + off_t n; + size_t arglen; pkdbuf = NULL; pkdbuf_n = 0; @@ -263,10 +278,19 @@ main (int argc, char **argv) algorithm_id = 0; /* (avoid cc warning) */ identifier = NULL; /* (avoid cc warning) */ - assert (argc == 2); + if (argc != 2) + return gpgkey2ssh_usage(1, stderr); keyid = argv[1]; + arglen = strlen(keyid); + if (arglen != 16) + return gpgkey2ssh_usage(1, stderr); + + for (n = 0; n < arglen; n++) + if (!isxdigit(keyid[n])) + return gpgkey2ssh_usage(1, stderr); + ret = asprintf (&command, "gpg --list-keys --with-colons --with-key-data '%s'", keyid); @@ -277,7 +301,20 @@ main (int argc, char **argv) err = retrieve_key_material (fp, keyid, &algorithm_id, &pkdbuf, &pkdbuf_n); assert (! err); - assert ((algorithm_id == 1) || (algorithm_id == 17)); + + if (algorithm_id == 0) + { + fprintf(stderr, PGM ": no key found matching keyid %s.\n", keyid); + return 1; + } + + if (!((algorithm_id == 1) || (algorithm_id == 17))) + { + fprintf(stderr, PGM ": The key %s is algorithm %d," + "which is neither RSA (1) nor DSA (17).\n", + keyid, algorithm_id); + return 1; + } if (algorithm_id == 1) { -- 2.6.1 From dkg at fifthhorseman.net Tue Oct 27 22:09:42 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Oct 2015 17:09:42 -0400 Subject: [PATCH 3/4] gpgkey2ssh: accept a 0x prefix for keyid argument In-Reply-To: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> References: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1445980183-4448-3-git-send-email-dkg@fifthhorseman.net> * tools/gpgkey2ssh.c (main): accept keyID argument written 0xlong format as well as normal long format. Signed-off-by: Daniel Kahn Gillmor --- tools/gpgkey2ssh.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/gpgkey2ssh.c b/tools/gpgkey2ssh.c index 3b4b076..f700f7a 100644 --- a/tools/gpgkey2ssh.c +++ b/tools/gpgkey2ssh.c @@ -283,6 +283,9 @@ main (int argc, char **argv) keyid = argv[1]; + if (keyid[0] == '0' && keyid[1] == 'x') + keyid = keyid + 2; + arglen = strlen(keyid); if (arglen != 16) return gpgkey2ssh_usage(1, stderr); -- 2.6.1 From dkg at fifthhorseman.net Tue Oct 27 22:09:43 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Oct 2015 17:09:43 -0400 Subject: [PATCH 4/4] fix typos In-Reply-To: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> References: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1445980183-4448-4-git-send-email-dkg@fifthhorseman.net> --- agent/ChangeLog-2011 | 2 +- common/ChangeLog-2011 | 2 +- common/ttyio.c | 2 +- doc/dirmngr.texi | 2 +- doc/tools.texi | 2 +- kbx/keybox-search.c | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/agent/ChangeLog-2011 b/agent/ChangeLog-2011 index f56be1f..d32d69c 100644 --- a/agent/ChangeLog-2011 +++ b/agent/ChangeLog-2011 @@ -2654,7 +2654,7 @@ to the control struct so that they are per connection. * gpg-agent.c (agent_init_default_ctrl): New. (main): Assign those command line options to new default_* variables. - Reset DISPLAY in server mode so that tehre is no implicit default. + Reset DISPLAY in server mode so that there is no implicit default. * command.c (start_command_handler): Initialize and deinitialize the control values. (option_handler): Work on the ctrl values and not on the opt. diff --git a/common/ChangeLog-2011 b/common/ChangeLog-2011 index 7fed0a7..4b95b35 100644 --- a/common/ChangeLog-2011 +++ b/common/ChangeLog-2011 @@ -1600,7 +1600,7 @@ (SPWQ_NO_PIN_ENTRY): New. * simple-pwquery.c (simple_pw_set_socket): New. (agent_open): Use it if GPG_AGENT_INFO is not set. - (simple_pwquery): Extended to allow returning of otehyr error codes. + (simple_pwquery): Extended to allow returning of other error codes. * util.h (GNUPG_MODULE_NAME_AGENT, GNUPG_MODULE_NAME_PINENTRY) (GNUPG_MODULE_NAME_SCDAEMON, GNUPG_MODULE_NAME_DIRMNGR) diff --git a/common/ttyio.c b/common/ttyio.c index 0f8c780..3b409e9 100644 --- a/common/ttyio.c +++ b/common/ttyio.c @@ -134,7 +134,7 @@ tty_get_ttyname (void) got_name = 1; } #endif /*HAVE_CTERMID*/ - /* Assume the standard tty on memory error or when tehre is no + /* Assume the standard tty on memory error or when there is no ctermid. */ return name? name : "/dev/tty"; } diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index 073cbc2..06da87e 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -1002,7 +1002,7 @@ as a binary blob. @c @c Here we may encounter a recursive situation: @c @code{validate_cert_chain} needs to look at other certificates and - at c also at CRLs to check whether tehse other certificates and well, the + at c also at CRLs to check whether these other certificates and well, the @c CRL issuer certificate itself are not revoked. FIXME: We need to make @c sure that @code{validate_cert_chain} does not try to lookup the CRL we @c are currently processing. This would be a catch-22 and may indicate a diff --git a/doc/tools.texi b/doc/tools.texi index 1dd1b35..425790e 100644 --- a/doc/tools.texi +++ b/doc/tools.texi @@ -1500,7 +1500,7 @@ The return value of this command is @item 0 The certificate under question is valid; i.e. there is a valid CRL -available and it is not listed tehre or teh OCSP request returned that +available and it is not listed there or the OCSP request returned that that certificate is valid. @item 1 diff --git a/kbx/keybox-search.c b/kbx/keybox-search.c index cb07c97..a0b778f 100644 --- a/kbx/keybox-search.c +++ b/kbx/keybox-search.c @@ -171,7 +171,7 @@ _keybox_get_flag_location (const unsigned char *buffer, size_t length, -/* Return one of the flags WHAT in VALUE from teh blob BUFFER of +/* Return one of the flags WHAT in VALUE from the blob BUFFER of LENGTH bytes. Return 0 on success or an raw error code. */ static gpg_err_code_t get_flag_from_image (const unsigned char *buffer, size_t length, -- 2.6.1 From bjk at luxsci.net Tue Oct 27 22:52:45 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Tue, 27 Oct 2015 17:52:45 -0400 Subject: [PATCH 3/4] gpgkey2ssh: accept a 0x prefix for keyid argument In-Reply-To: <1445980183-4448-3-git-send-email-dkg@fifthhorseman.net> References: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> <1445980183-4448-3-git-send-email-dkg@fifthhorseman.net> Message-ID: <1445982782-9805882.56848302.ft9RLqkaD030242@rs146.luxsci.com> On Tue, Oct 27, 2015 at 05:09:42PM -0400, Daniel Kahn Gillmor wrote: > * tools/gpgkey2ssh.c (main): accept keyID argument written 0xlong > format as well as normal long format. I was using this tool the other day and was wondering why popen() executes gpg rather than gpg2? -- Ben Kibbey From dkg at fifthhorseman.net Wed Oct 28 03:55:52 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Oct 2015 22:55:52 -0400 Subject: [PATCH 3/4] gpgkey2ssh: accept a 0x prefix for keyid argument In-Reply-To: <1445982782-9805882.56848302.ft9RLqkaD030242@rs146.luxsci.com> References: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> <1445980183-4448-3-git-send-email-dkg@fifthhorseman.net> <1445982782-9805882.56848302.ft9RLqkaD030242@rs146.luxsci.com> Message-ID: <87ziz33dmv.fsf@alice.fifthhorseman.net> On Tue 2015-10-27 17:52:45 -0400, Ben Kibbey wrote: > I was using this tool the other day and was wondering why popen() > executes gpg rather than gpg2? That's a good question. it seems like it should popen whatever the package is building as its g10/gpg.c target to me. --dkg From dgouttegattat at incenp.org Wed Oct 28 08:09:49 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 28 Oct 2015 08:09:49 +0100 Subject: [PATCH] doc: Document some changed default options. Message-ID: <1446016189-3176-1-git-send-email-dgouttegattat@incenp.org> * doc/gpg.texi: Update the description of some options which are now enabled by default. Signed-off-by: Damien Goutte-Gattat --- doc/gpg.texi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index ffd7a97..6e62917 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -1099,7 +1099,7 @@ give the opposite meaning. The options are: @item show-uid-validity @opindex list-options:show-uid-validity Display the calculated validity of user IDs during key listings. - Defaults to no. + Defaults to yes. @item show-unusable-uids @opindex list-options:show-unusable-uids @@ -1144,7 +1144,7 @@ the opposite meaning. The options are: @item show-policy-urls @opindex verify-options:show-policy-urls - Show policy URLs in the signature being verified. Defaults to no. + Show policy URLs in the signature being verified. Defaults to yes. @item show-notations @itemx show-std-notations @@ -1158,12 +1158,12 @@ the opposite meaning. The options are: @item show-keyserver-urls @opindex verify-options:show-keyserver-urls Show any preferred keyserver URL in the signature being verified. - Defaults to no. + Defaults to yes. @item show-uid-validity @opindex verify-options:show-uid-validity Display the calculated validity of the user IDs on the key that issued - the signature. Defaults to no. + the signature. Defaults to yes. @item show-unusable-uids @opindex verify-options:show-unusable-uids -- 1.8.4 From wk at gnupg.org Wed Oct 28 10:38:59 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Oct 2015 10:38:59 +0100 Subject: [PATCH 4/4] fix typos In-Reply-To: <1445980183-4448-4-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 27 Oct 2015 17:09:43 -0400") References: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> <1445980183-4448-4-git-send-email-dkg@fifthhorseman.net> Message-ID: <87bnbj9vt8.fsf@vigenere.g10code.de> Hi! Thanks, I applied patch 1 and 4 but gpgkeys2ssh needs further discussion (see my other mail). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 28 10:37:23 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Oct 2015 10:37:23 +0100 Subject: [PATCH 2/4] clarify gpgkey2ssh usage In-Reply-To: <1445980183-4448-2-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 27 Oct 2015 17:09:41 -0400") References: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> <1445980183-4448-2-git-send-email-dkg@fifthhorseman.net> Message-ID: <87fv0v9vvw.fsf@vigenere.g10code.de> On Tue, 27 Oct 2015 22:09, dkg at fifthhorseman.net said: > This update makes the tool marginally more intelligible to a normal > user, without changing its behavior. Frankly, I do not understand for what this tool is used. It states: gpgkey2ssh.c - Converter (Debug helper) but I can't remember that I ever used it. It has also a lot of problems for example the missing support for modern key algorithms. What are the use cases for it? Extracting public keys from an OpenPGP key to put it into authorized keys? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Wed Oct 28 11:12:32 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 28 Oct 2015 11:12:32 +0100 Subject: TOFU performance / DB format In-Reply-To: <1546901.kC3nCEYk5U@esus> References: <87oagi9tm1.wl-neal@walfield.org> <87r3ko8ffk.wl-neal@walfield.org> <87io5x8qbf.wl-neal@walfield.org> <1546901.kC3nCEYk5U@esus> Message-ID: <87bnbj8fov.wl-neal@walfield.org> Hi Andre, Thanks for sharing your concerns. At Tue, 27 Oct 2015 15:30:23 +0100, Andre Heinecke wrote: > On Friday 23 October 2015 19:09:24 Neal H. Walfield wrote: > > Unfortunately, this change only helps with the flat database format. > > For the split forat, we're still looking at over 90 seconds for the > > initial listing and 3 seconds for subsequent listings. > > I can confirm that thanks to your performance improvements initializing the flat > db is now really as fast as I would expect. << 1second. :-) > > Great, Thanks! Great. > > I'd be interested to hear people's opinions about whether the split > > format (with its ability to be more easily synced) is still > > interesting despite the slow performance. > > I'm not sure that keeping two database formats and making them configurable is > a good idea. > > - It makes things harder to maintain. Obviously you have two codepaths with > different issues. e.g. The performance for the flat format is now fine while the > performance for the split format is still bad. You will receive bug reports > and you will always have to ask "are you using flat / split" > > The majority will use whatever is default but you will still have to maintain > the code for the minority that uses another option. These are valid concerns, but I don't think they are major concerns. First, the code differences are rather minor. The code for updating a split format DB is nearly identical to that for updating the flat format. The primary difference is the routing, which is quite straightforward. Further, I've written some tests for the TOFU DB code and make check runs it twice: once using the flat format and once using the split format. > - It makes things harder to document. "If you are using tofu-db-split format > you will have to sync that folder. If you are using tofo-db-flat format you > will have to sync that db." etc. > > - I don't see how the split format solves two way sync: > > -- Two way sync is not really supported in GnuPG. We have the monolithic > keyring and the trust.db and It's just not supported afaik two merge > two gnupg home dirs. > -- How should such a two-way sync work? If I would only use the "last > updated" db from two systems how would I merge them in case of conflicts? > > With regards to easier sync. It can be easier Just to copy bulk data if it is > small then lots and lots of different files. E.g with rsync to a system > connected over the internet i see the following values: > > (Ok that is cheating a bit as the tofu.db does not really contain any data but > the initialization) > > First run: > rsync -rvzP tofu.d remote:/tmp/tofu.d 0.54s user 0.10s system 3% cpu 20.231 > total I think there might be a bit of confusion. rsync doesn't do two way synchronization. It can be used create a backup and update that backup. But, it doesn't do a two-way sync. A two-way sync works as follows. Consider my laptop (L) and my desktop (D). L and D initially have the exact same data. Now, I do some work on L and modify the file 'l'. Later, I do some work on D and modify the file 'd'. L and D have now not only diverged from the original, but they have diverged from each other. Thus, if we were to use rsync to synchronize L with D, the changes to 'd' would be lost. Likewise, if we were to use rsync to synchronize D with L, the changes to 'l' would be lost. Unison works by considering the files the basic unit of synchronization and memorizes the state of each file (by saving a check sum and the last modification time). When it synchronizes L and D, it sees that D has the original copy of 'l' and sends L's updated version of 'l' to D. Likewise it sees that L has the original version of 'd' and sends D's updated version of 'd' to L. Only if a file is updated on both L and D does the user need to manually intervene and either choose a copy or manually merge the changes. This approach isn't perfect, but in practice it works great: I rarely have to manually fix something. (I've been using this setup for about a decade, I think.) The difficulty with the TOFU data is that we update the DB whenever we see a new signed message. Thus, for active users of GnuPG, we expect there to be a fair amount of churn. Further, it is not possible to merge two DBs by hand. (We could and probably will write a tool to do this. Nevertheless, we'd then have to teach users about it, which is a pain.) By splitting the DB isn't many small, atomic chunks, the chance of a conflict decreases dramatically. But, equally important, if two chunks do diverge, choosing one copy randomly still results in a usable DB with little data loss. Personally, I find this improved ability to do two-synchronization is a big win. But, given the huge performance difference, I think it is reasonable to make the flat format the default DB format. Thanks, :) Neal From wk at gnupg.org Wed Oct 28 11:28:34 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Oct 2015 11:28:34 +0100 Subject: gpgsm --gen-key segfault with ECC key on smartcard In-Reply-To: (Bertrand Jacquin's message of "Mon, 26 Oct 2015 14:34:27 +0000") References: <20150819212750.GA12535@lady-voodoo.scabb> Message-ID: <877fm79til.fsf@vigenere.g10code.de> On Mon, 26 Oct 2015 15:34, bertrand at jacquin.bzh said: > On 19/08/2015 22:27, Bertrand Jacquin wrote: >> I'm getting a SEGV running gpgsm --gen-key with GnuPG 2.1.6. The issue >> comes from libksba. Here is a backtrace: Thanks for the data. I can't replicate this right now but the backtrace was helpful enough. The attached patch to libksba should fix the segv. I look into extending the table of curve names. Shalom-Salam, Werner ======== >From 9df0ac3a4afa0272dbff08d17e9064f13be95814 Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Wed, 28 Oct 2015 11:18:59 +0100 Subject: [PATCH] Fix lookup of ECC OIDs by name. * src/keyinfo.c (get_ecc_curve_oid): Fix obviously never tested table lookup. -- This led to a crash see https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030445.html The fix is obvious but I do not have test data for this. Signed-off-by: Werner Koch --- src/keyinfo.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/keyinfo.c b/src/keyinfo.c index 02dc7ae..3ea0cfa 100644 --- a/src/keyinfo.c +++ b/src/keyinfo.c @@ -322,10 +322,10 @@ get_ecc_curve_oid (const unsigned char *buf, size_t buflen, size_t *r_oidlen) if (buflen == strlen (curve_names[i].name) && !memcmp (buf, curve_names[i].name, buflen)) break; - if (curve_names[i].oid) + if (!curve_names[i].oid) return NULL; /* Not found. */ - buf = curve_names[i].name; - buflen = strlen (curve_names[i].name); + buf = curve_names[i].oid; + buflen = strlen (curve_names[i].oid); } if (_ksba_oid_from_buf (buf, buflen, &der_oid, r_oidlen)) -- 2.1.4 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aheinecke at intevation.de Wed Oct 28 12:03:21 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 28 Oct 2015 12:03:21 +0100 Subject: TOFU performance / DB format In-Reply-To: <87bnbj8fov.wl-neal@walfield.org> References: <87oagi9tm1.wl-neal@walfield.org> <1546901.kC3nCEYk5U@esus> <87bnbj8fov.wl-neal@walfield.org> Message-ID: <4219699.urCsCS7PuU@esus> Hi Neal, On Wednesday 28 October 2015 11:12:32 Neal H. Walfield wrote: > I think there might be a bit of confusion. rsync doesn't do two way > synchronization. It can be used create a backup and update that > backup. But, it doesn't do a two-way sync. I've tried to make two arguments. First that I don't see how the split DB solves two way sync. Secondly that I don't think that is a great improvement for backup / one way sync (Using the rsync example). > Unison works by considering the files the basic unit of > synchronization and memorizes the state of each file (by saving a > check sum and the last modification time). When it synchronizes L and > D, it sees that D has the original copy of 'l' and sends L's updated > version of 'l' to D. Likewise it sees that L has the original version > of 'd' and sends D's updated version of 'd' to L. Only if a file is > updated on both L and D does the user need to manually intervene and > either choose a copy or manually merge the changes. > > This approach isn't perfect, but in practice it works great: I rarely > have to manually fix something. (I've been using this setup for about > a decade, I think.) > > The difficulty with the TOFU data is that we update the DB whenever we > see a new signed message. Thus, for active users of GnuPG, we expect > there to be a fair amount of churn. Further, it is not possible to > merge two DBs by hand. (We could and probably will write a tool to do > this. Nevertheless, we'd then have to teach users about it, which is > a pain.) By splitting the DB isn't many small, atomic chunks, the > chance of a conflict decreases dramatically. But, equally important, > if two chunks do diverge, choosing one copy randomly still results in > a usable DB with little data loss. My problem with two way sync was exactly the "Merge" case. When I work on my Laptop and Desktop usually I'm in communication with similar partners. So I would expect a tofu db conflict would be the "usual" case. Similarly my pubring / trustdb files would diverge anyway, breaking a two way merge. For me it is easier to do a one way sync from time to time from / to my laptop if I know I've made changes I want to have on the other system. You say that the split DB makes it easier to do a two way merge, I can see the point of that. But as it does not really "solve" two way merges imo (as there still will be individual conflicts and other data with similar problems) I personally don't see that it has enough value to justify having redundant code and yet another config option to individualize a setup. > Personally, I find this improved ability to do two-synchronization is > a big win. Ok. If you think the advantages outweigh the problems I'm totally fine with it. I just wanted to raise my concerns from a support / maintenance perspective. Even the slightest behavioral differences tend to lead to individual Bugs. Even if the difference in the code is small now I think that the behavior of that code might be quite different between the split / flat format. And this is GnuPG once something is released it is usually maintained for a veeery long time ;-) So we probably have to decide now If we want to maintain two tofu database formats / layouts "forever" > But, given the huge performance difference, I think it is > reasonable to make the flat format the default DB format. Yes please :-) I have not tested it yet but I expect that the performance difference will be even more pronounced on Windows. 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: 181 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Oct 28 12:14:56 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Oct 2015 12:14:56 +0100 Subject: [PATCH] doc: Document some changed default options. In-Reply-To: <1446016189-3176-1-git-send-email-dgouttegattat@incenp.org> (Damien Goutte-Gattat's message of "Wed, 28 Oct 2015 08:09:49 +0100") References: <1446016189-3176-1-git-send-email-dgouttegattat@incenp.org> Message-ID: <87twpb8csv.fsf@vigenere.g10code.de> On Wed, 28 Oct 2015 08:09, dgouttegattat at incenp.org said: > * doc/gpg.texi: Update the description of some options which are > now enabled by default. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 28 14:47:33 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Oct 2015 14:47:33 +0100 Subject: Use of C99 features Message-ID: <87a8r385qi.fsf@vigenere.g10code.de> Hi! GnuPG has always been coded for a C90 compliant compiler. This greatly helps with porability but some features of C99 are nice enough to consider. After talking to people who run many different Unix flavours as weel as VMS, I'd like to allow ise of these features in GnuPG 2.x: 1.4.1 C99 language features ??????????????????????????? In GnuPG 2.x, but *not in 1.4* and not in most libraries, a limited set of C99 features may be used: ? Variadic macros: ????? ? #define foo(a,...) bar(a, __VA_ARGS__) ????? ? The predefined macro `__func__': ????? ? log_debug ("%s: Problem with foo\n", __func__); ????? ? Variable declaration inside a for(): ????? ? for (int i = 0; i < 5; ++) ? bar (i); ????? Although we usually make use of the `u16', `u32', and `u64' types, it is also possible to include `' and use `int16_t', `int32_t', `int64_t', `uint16_t', `uint32_t', and `uint64_t'. But do not use `int8_t' or `uint8_t'. We still need to evaluate whether to allow these features in other related packages. Salam-Shalom, Werner From git at internot.info Wed Oct 28 15:08:05 2015 From: git at internot.info (Joshua Rogers) Date: Thu, 29 Oct 2015 01:08:05 +1100 Subject: GnuPG Github mirrors In-Reply-To: <87vb9s42iq.fsf@alice.fifthhorseman.net> References: <562EF31A.2050407@sixdemonbag.org> <562FA6BB.8040406@internot.info> <87vb9s42iq.fsf@alice.fifthhorseman.net> Message-ID: <5630D6C5.6010603@internot.info> On 28/10/15 04:58, Daniel Kahn Gillmor wrote: > It would be a really useful contribution to the community for someone to > publish concise documentation of their workflow of how they interact > with the GnuPG project as a non-core developer. (hint, hint) This is actually something that would likely help all FOSS projects. It would allow an "outsider" with no previous knowledge of developmental procedures outside of Github/internal/etc. practices to participate, without causing hassles of 1. not knowing what to do thus not doing it, and 2. not impeding on others to spoon feed them. It may be something I will write up in the future. Thanks, -- -- Joshua Rogers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Oct 28 15:20:35 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 28 Oct 2015 10:20:35 -0400 Subject: Use of C99 features In-Reply-To: <87a8r385qi.fsf@vigenere.g10code.de> References: <87a8r385qi.fsf@vigenere.g10code.de> Message-ID: <5630D9B3.8070501@sixdemonbag.org> > GnuPG has always been coded for a C90 compliant compiler. This greatly > helps with portability... There's another benefit here: although I haven't done so recently, in the past it was possible to compile GnuPG with a C++ compiler. C++ has much stricter type rules, and in my experience C++ compilers are more demanding than C compilers in terms of what bad programming habits they will or won't accept. I used to run GnuPG through a C++ compiler as my own little smoke test, in order to see if there were any problems the C++ compiler saw which the C compiler didn't. It may be worth considering whether we'd like to hold onto this capability. Fortunately, the proposed changes so far preserve it. Every change proposed here is present in the C++11 standard, so... go for it. But there are other C99isms that break C++ compatibility, and I'd recommend we think about whether it's worth it. > Although we usually make use of the `u16', `u32', and `u64' types, it > is also possible to include `' and use `int16_t', `int32_t', > `int64_t', `uint16_t', `uint32_t', and `uint64_t'. But do not use > `int8_t' or `uint8_t'. I'd prefer to see the constants from stdint.h be used. From wk at gnupg.org Wed Oct 28 15:21:40 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Oct 2015 15:21:40 +0100 Subject: TOFU performance / DB format In-Reply-To: <4219699.urCsCS7PuU@esus> (Andre Heinecke's message of "Wed, 28 Oct 2015 12:03:21 +0100") References: <87oagi9tm1.wl-neal@walfield.org> <1546901.kC3nCEYk5U@esus> <87bnbj8fov.wl-neal@walfield.org> <4219699.urCsCS7PuU@esus> Message-ID: <874mhb845n.fsf@vigenere.g10code.de> On Wed, 28 Oct 2015 12:03, aheinecke at intevation.de said: > point of that. But as it does not really "solve" two way merges imo (as there > still will be individual conflicts and other data with similar problems) I > personally don't see that it has enough value to justify having We should also take in account that pubring.kbx is astlo often updated if you are using gpgsm. This is because an S/MIME commonly includes the public keys and gpgsm imports them. Some of those key may be expired after some time but that just adds another update to keyring.kbx). Now we could just ignore the S/MIME base but we should also consider that there are OpenPGP use suggestions which demand that the public key is send with each message. A dedicated ~/.gnupg sync system is IMHO better than a limited solution for just one class of objects. Fortunately, in the course of the Gpg4all project we need to look at synchronization issues anyway. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dgouttegattat at incenp.org Wed Oct 28 16:09:22 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 28 Oct 2015 16:09:22 +0100 Subject: [PATCH] doc: Clarify --completes-needed and --marginals-needed. Message-ID: <1446044962-10219-1-git-send-email-dgouttegattat@incenp.org> * doc/gpg.texi: Explain better how --completes-needed and --marginals-needed affect a user ID's validity. * doc/DETAILS: Ditto. -- It seems to me that the current explanation of the --completes-needed and --marginals-needed options is misleading. I understand `key signer' to mean `a key which is trusted to sign other keys' (that is, a key with full ownertrust). But those options only affect the calculated trust (that is, the validity) of a user ID, they do not affect the ownertrust assigned to a valid key. Signed-off-by: Damien Goutte-Gattat --- doc/DETAILS | 8 ++++---- doc/gpg.texi | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/DETAILS b/doc/DETAILS index 97079b0..06ffd49 100644 --- a/doc/DETAILS +++ b/doc/DETAILS @@ -250,10 +250,10 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB: - Field 4 :: Date trustdb was created in seconds since Epoch. - Field 5 :: Date trustdb will expire in seconds since Epoch. - - Field 6 :: Number of marginally trusted users to introduce a new - key signer (gpg's option --marginals-needed). - - Field 7 :: Number of completely trusted users to introduce a new - key signer. (gpg's option --completes-needed) + - Field 6 :: Number of signatures from marginally trusted keys to + fully validate a UID. (gpg's option --marginals-needed) + - FIeld 7 :: Number of signatures from completely trusted keys to + fully validate a UID. (gpg's option --completes-needed) - Field 8 :: Maximum depth of a certification chain. (gpg's option --max-cert-depth) diff --git a/doc/gpg.texi b/doc/gpg.texi index 6e62917..cfa2622 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -1682,13 +1682,13 @@ are available for all keyserver types, some common options are: @item --completes-needed @code{n} @opindex compliant-needed -Number of completely trusted users to introduce a new -key signer (defaults to 1). +Number of signatures emitted by completely trusted keys +to hold a user ID as fully valid (defaults to 1). @item --marginals-needed @code{n} @opindex marginals-needed -Number of marginally trusted users to introduce a new -key signer (defaults to 3) +Number of signatures emitted by marginally trusted keys +to hold a user ID as fully valid (defaults to 3). @item --tofu-default-policy @code{auto|good|unknown|bad|ask} @opindex tofu-default-policy -- 1.8.4 From wk at gnupg.org Wed Oct 28 16:37:14 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Oct 2015 16:37:14 +0100 Subject: Suggestions for gpgme on mingw-w64 In-Reply-To: (Jeroen Ooms's message of "Fri, 4 Sep 2015 16:55:25 +0200") References: <87fv2uh11x.fsf@vigenere.g10code.de> Message-ID: <87ziz36m39.fsf@vigenere.g10code.de> On Fri, 4 Sep 2015 16:55, jeroen.ooms at stat.ucla.edu said: > That would be really great. I just pushed bb600aa w32: Add new global flag "w32-inst-dir". @item "w32-inst-dir" On Windows GPGME needs to know its installation directory to find its spawn helper. This is in general no problem because a DLL has this information. Some applications however link statically to GPGME and thus GPGME can only figure out the installation directory of this application which may be wrong in certain cases. By supplying an installation directory as value to this flag, GPGME will assume that that directory is the installation directory. This flag has no effect on non-Windows platforms. > Yes, that makes sense. The full table on what > CSIDL_PROGRAM_FILES{,X86,X64} refer to for 32/64bit processes on > windows 32 and 64 is here: a82e9b1 w32: Improve locating gpgconf on 64 bit systems. and also bb2d11c w32: Add extra diagnostic about possible missing gpgme-w32spawn.exe I have not tested any of these changes, I would appreciate if you could give it a try. Please let me know if you need a tarball. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 28 16:47:56 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Oct 2015 16:47:56 +0100 Subject: Use of C99 features In-Reply-To: <5630D9B3.8070501@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 28 Oct 2015 10:20:35 -0400") References: <87a8r385qi.fsf@vigenere.g10code.de> <5630D9B3.8070501@sixdemonbag.org> Message-ID: <87twpb6llf.fsf@vigenere.g10code.de> On Wed, 28 Oct 2015 15:20, rjh at sixdemonbag.org said: > the past it was possible to compile GnuPG with a C++ compiler. C++ has > much stricter type rules, and in my experience C++ compilers are more > demanding than C compilers in terms of what bad programming habits they Please keep in mind that C and C++ are two different languages - there are subtle difference and thus using a C++ compiler for C code may work but is not suggested. > I'd prefer to see the constants from stdint.h be used. We are already using INT32_MAX if available to work a round an AIX problem. And frankly, I added stdint.h at one place without doing a configure test already last year ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Oct 28 16:51:19 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Oct 2015 11:51:19 -0400 Subject: [PATCH 2/4] clarify gpgkey2ssh usage In-Reply-To: <87fv0v9vvw.fsf@vigenere.g10code.de> References: <1445980183-4448-1-git-send-email-dkg@fifthhorseman.net> <1445980183-4448-2-git-send-email-dkg@fifthhorseman.net> <87fv0v9vvw.fsf@vigenere.g10code.de> Message-ID: <87lhant2iw.fsf@alice.fifthhorseman.net> On Wed 2015-10-28 05:37:23 -0400, Werner Koch wrote: > On Tue, 27 Oct 2015 22:09, dkg at fifthhorseman.net said: > >> This update makes the tool marginally more intelligible to a normal >> user, without changing its behavior. > > Frankly, I do not understand for what this tool is used. It states: > > gpgkey2ssh.c - Converter (Debug helper) > > but I can't remember that I ever used it. It has also a lot of problems > for example the missing support for modern key algorithms. These minor changes were preparation work to make it friendly enough to bother adding support for modern key algorithms. I'd be happy to work on adding these if you think it's useful. I can also write up some simple/minimalist documentation. > What are the use cases for it? Extracting public keys from an OpenPGP > key to put it into authorized keys? yes, this is what it's useful for. It might be nice to also extend it to being able to extract secret keys into the OpenSSH secret key format, but that would be a future project. --dkg From rjh at sixdemonbag.org Wed Oct 28 17:50:00 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 28 Oct 2015 12:50:00 -0400 Subject: Use of C99 features In-Reply-To: <87twpb6llf.fsf@vigenere.g10code.de> References: <87a8r385qi.fsf@vigenere.g10code.de> <5630D9B3.8070501@sixdemonbag.org> <87twpb6llf.fsf@vigenere.g10code.de> Message-ID: <5630FCB8.2040402@sixdemonbag.org> > Please keep in mind that C and C++ are two different languages - there > are subtle difference and thus using a C++ compiler for C code may work > but is not suggested. Yes and no. Bjarne Stroustrup himself has declared that every program in K&R's _The C Programming Language_ is a valid, well-formed C++ program. They are definitely different languages, but most sane C90 code will compile without complaint in C++. Of course, there's a lot of pretty insane C out there. From bernhard at intevation.de Wed Oct 28 17:50:18 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 28 Oct 2015 17:50:18 +0100 Subject: pinentry hide/show button In-Reply-To: <873838du2s.wl-neal@walfield.org> References: <87zj5gs5n5.fsf@vigenere.g10code.de> <87ioc4rvxn.fsf@vigenere.g10code.de> <873838du2s.wl-neal@walfield.org> Message-ID: <201510281750.25301.bernhard@intevation.de> On Thursday 07 May 2015 at 22:13:47, Neal H. Walfield wrote: > > There is a new screenshot with the warning dialog at > > ? https://wiki.gnupg.org/ScratchWK > This looks quite good, I think. When implementing this, a couple of folks here thought that warning dialog may be suboptimal. Thus I have created an issue in the tracker to document the design reasoning. https://bugs.gnupg.org/gnupg/issue2139 (pinentry option to see the password in cleartext) .. added more suggestions. What do you think? Overall I think this is a good feature to add to pinentries, so thanks for proposing and discussing this in the first place in May! Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 dkg at fifthhorseman.net Wed Oct 28 18:20:14 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Oct 2015 13:20:14 -0400 Subject: [PATCH] doc: Clarify --completes-needed and --marginals-needed. In-Reply-To: <1446044962-10219-1-git-send-email-dgouttegattat@incenp.org> References: <1446044962-10219-1-git-send-email-dgouttegattat@incenp.org> Message-ID: <87io5qucz5.fsf@alice.fifthhorseman.net> Hi Damien-- On Wed 2015-10-28 11:09:22 -0400, Damien Goutte-Gattat wrote: > * doc/gpg.texi: Explain better how --completes-needed and > --marginals-needed affect a user ID's validity. > * doc/DETAILS: Ditto. thanks for this fix! I think these are both improvements to the existing documentation. Now that you've got me looking at it, i'll propose even more improvements below. what do you think? I think the more we can be consistent about calling a signature-over-identity-plus-key-material a "certification", the better we'll be able to explain the difference between the C and S usage flags. Also, we use the term "full" ownertrust elsewhere, but "complete" ownertrust isn't defined as far as i can tell. I assume it means "either full or ultimate ownertrust", but that's not stated anywhere. Does that need to be improved? So how about we use "Number of certifications from..." in the DETAILS lines below? > diff --git a/doc/DETAILS b/doc/DETAILS > index 97079b0..06ffd49 100644 > --- a/doc/DETAILS > +++ b/doc/DETAILS > @@ -250,10 +250,10 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB: > > - Field 4 :: Date trustdb was created in seconds since Epoch. > - Field 5 :: Date trustdb will expire in seconds since Epoch. > - - Field 6 :: Number of marginally trusted users to introduce a new > - key signer (gpg's option --marginals-needed). > - - Field 7 :: Number of completely trusted users to introduce a new > - key signer. (gpg's option --completes-needed) > + - Field 6 :: Number of signatures from marginally trusted keys to > + fully validate a UID. (gpg's option --marginals-needed) > + - FIeld 7 :: Number of signatures from completely trusted keys to > + fully validate a UID. (gpg's option --completes-needed) > > - Field 8 :: Maximum depth of a certification chain. (gpg's option > --max-cert-depth) and more terminology cleanup in the .texi: > diff --git a/doc/gpg.texi b/doc/gpg.texi > index 6e62917..cfa2622 100644 > --- a/doc/gpg.texi > +++ b/doc/gpg.texi > @@ -1682,13 +1682,13 @@ are available for all keyserver types, some common options are: > > @item --completes-needed @code{n} > @opindex compliant-needed > -Number of completely trusted users to introduce a new > -key signer (defaults to 1). > +Number of signatures emitted by completely trusted keys > +to hold a user ID as fully valid (defaults to 1). > > @item --marginals-needed @code{n} > @opindex marginals-needed > -Number of marginally trusted users to introduce a new > -key signer (defaults to 3) > +Number of signatures emitted by marginally trusted keys > +to hold a user ID as fully valid (defaults to 3). > > @item --tofu-default-policy @code{auto|good|unknown|bad|ask} > @opindex tofu-default-policy I think "emitted" and "hold" are odd words here. Also, what if we invert the sentence so that the goal of the sentence comes first? That is, what about: --completes-needed: Consider a User ID (and its associated key) to be fully valid if we see certifications by at least this number of keys that have full or ultimate ownertrust. --marginals needed: Consider a User ID (and its associated key) to be fully valid if we see certifications by at least this number of keys that have marginal ownertrust. it's still an awkward way to express the situation. I wonder if we could do better if we switched out of text mode and into graphics. but that's another project, probably, and we should try to be clear in text where possible. --dkg From git at internot.info Wed Oct 28 20:12:35 2015 From: git at internot.info (Joshua Rogers) Date: Thu, 29 Oct 2015 06:12:35 +1100 Subject: GnuPG Github mirrors In-Reply-To: References: <562EF31A.2050407@sixdemonbag.org> <562FA6BB.8040406@internot.info> <87vb9s42iq.fsf@alice.fifthhorseman.net> <5630D6C5.6010603@internot.info> Message-ID: <56311E23.3030807@internot.info> On 29/10/15 05:58, RB wrote: > Write it up if you wish, but GnuPG follows the same development > process that existed for a large plurality of FOSS software prior to > Github. These models work, and have for literally decades before > Github even existed; the only difference is the SCM has changed. Right. Exactly. However, from what I've seen, new developers are being taught that places such as Github are the only way to develop and distribute code. Hell, I've seen people think that 'git' was just short for Github. Perhaps the point of this whole thread is an example of what I'm talking about. By documenting how things are done in certain projects, it 1. allows them to expand their knowledge, and 2., allows them to in the future possibly contribute code appropriately. > It's amusing and frustrating to see a wave of developers insisting > that any workflow but github must be backwards or nonexistent. > Emailed patchsets and communication prior to submission are a useful > workflow, especially for tools that must necessarily be conservative > in their development. I don't understand what you mean here. Maybe I'm too tired and am missing something, but I would think that you're in agreement that mailing list submissions are good? Apologies if I'm misinterpreting it. I think I've said everything I need to regarding my views on this matter, so I won't delve into it anymore. Thanks, -- -- Joshua Rogers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Oct 28 20:28:54 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Oct 2015 15:28:54 -0400 Subject: adns and TOR In-Reply-To: <22055.62681.859262.777669@chiark.greenend.org.uk> References: <87vba1n0nc.fsf@vigenere.g10code.de> <22054.22959.951094.201969@chiark.greenend.org.uk> <87h9llmk1m.fsf@vigenere.g10code.de> <22055.30470.407246.973906@chiark.greenend.org.uk> <87a8rchuku.fsf@vigenere.g10code.de> <22055.62681.859262.777669@chiark.greenend.org.uk> Message-ID: <87611qu70p.fsf@alice.fifthhorseman.net> On Wed 2015-10-21 16:26:01 -0400, Ian Jackson wrote: > Werner Koch writes ("Re: adns and TOR"): >> There is this torsocks script which LD_PRELOADs a wrapper to intercept >> all network related calls to send them to Tor or returns an error. >> [...] > > So this script ought to set suitable ADNS_* variable so tht naive > programs get an adns configuration which uses the Tor socks proxy for > dns lookups. Am I right ? While i don't think that torsocks is the right fix for GnuPG and dirmngr, better integration between torsocks and ADNS might be worth discussing with the torsocks developers. https://gitweb.torproject.org/torsocks.git/tree/README.md says: >>> Mailing list for help is and for >>> development use . You can find the >>> project also on IRC server irc.oftc.net (OFTC) in #tor and #tor-dev. hth, --dkg From dgouttegattat at incenp.org Wed Oct 28 20:35:29 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 28 Oct 2015 20:35:29 +0100 Subject: [PATCH] doc: Clarify --completes-needed and --marginals-needed. In-Reply-To: <87io5qucz5.fsf@alice.fifthhorseman.net> References: <1446044962-10219-1-git-send-email-dgouttegattat@incenp.org> <87io5qucz5.fsf@alice.fifthhorseman.net> Message-ID: <56312381.6090608@incenp.org> On 10/28/2015 06:20 PM, Daniel Kahn Gillmor wrote: > I think the more we can be consistent about calling a > signature-over-identity-plus-key-material a "certification", the better > we'll be able to explain the difference between the C and S usage flags. I agree. > Also, we use the term "full" ownertrust elsewhere, but "complete" > ownertrust isn't defined as far as i can tell. I assume it means > "either full or ultimate ownertrust", but that's not stated anywhere. > Does that need to be improved? Well, at least in the context of the --completes-needed option, "complete" means the same thing as "full", as this option has nothing to do with ultimately trusted keys. Only one certification from such a key is *always* enough to fully validate a UID, independently of the --completes-needed value (this is hardcoded). > So how about we use "Number of certifications from..." in the DETAILS > lines below? Fine for me. > Also, what if we invert the sentence so that the goal of the sentence > comes first? > > That is, what about: > > --completes-needed: > > Consider a User ID (and its associated key) to be fully valid if we see > certifications by at least this number of keys that have full or > ultimate ownertrust. Full ownertrust only (see my remark above). I do not really like that "if we see certifications"... How about "if it is certified" instead? --completes-needed: Consider a user ID (and its associated key) to be fully valid if it is certified by at least this number of keys that have full ownertrust. (or: "this number of fully trusted keys") Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From aoz.syn at gmail.com Wed Oct 28 19:58:38 2015 From: aoz.syn at gmail.com (RB) Date: Wed, 28 Oct 2015 12:58:38 -0600 Subject: GnuPG Github mirrors In-Reply-To: <5630D6C5.6010603@internot.info> References: <562EF31A.2050407@sixdemonbag.org> <562FA6BB.8040406@internot.info> <87vb9s42iq.fsf@alice.fifthhorseman.net> <5630D6C5.6010603@internot.info> Message-ID: On Wed, Oct 28, 2015 at 8:08 AM, Joshua Rogers wrote: > This is actually something that would likely help all FOSS projects. > It would allow an "outsider" with no previous knowledge of developmental > procedures outside of Github/internal/etc. practices to participate, > without causing hassles of 1. not knowing what to do thus not doing it, > and 2. not impeding on others to spoon feed them. > > It may be something I will write up in the future. Normally I just lurk, but with Daniel's comment and your response I couldn't just resist any more. Write it up if you wish, but GnuPG follows the same development process that existed for a large plurality of FOSS software prior to Github. These models work, and have for literally decades before Github even existed; the only difference is the SCM has changed. It's amusing and frustrating to see a wave of developers insisting that any workflow but github must be backwards or nonexistent. Emailed patchsets and communication prior to submission are a useful workflow, especially for tools that must necessarily be conservative in their development. Just because you've gone through the motions of forking a project on github and making your changes does not entitle you to those changes moving upstream. Most of these projects (Linux kernel included) are benevolent dictatorships, not a bazaar, and with good reason. Communicate a little. -- RB From sbellon at sbellon.de Wed Oct 28 20:10:48 2015 From: sbellon at sbellon.de (Stefan Bellon) Date: Wed, 28 Oct 2015 20:10:48 +0100 Subject: Use of C99 features In-Reply-To: <5630FCB8.2040402@sixdemonbag.org> References: <87a8r385qi.fsf@vigenere.g10code.de> <5630D9B3.8070501@sixdemonbag.org> <87twpb6llf.fsf@vigenere.g10code.de> <5630FCB8.2040402@sixdemonbag.org> Message-ID: <20151028201048.2b91e783@slim.localnet> On Wed, 28 Oct, Robert J. Hansen wrote: > > Please keep in mind that C and C++ are two different languages - > > there are subtle difference and thus using a C++ compiler for C > > code may work but is not suggested. > > Yes and no. Bjarne Stroustrup himself has declared that every program > in K&R's _The C Programming Language_ is a valid, well-formed C++ > program. They are definitely different languages, but most sane C90 > code will compile without complaint in C++. As soon as you use C++ keywords as identifiers in C, it's over. ;-) Greetings, Stefan -- Stefan Bellon From dkg at fifthhorseman.net Wed Oct 28 20:59:50 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Oct 2015 15:59:50 -0400 Subject: [PATCH] doc: Clarify --completes-needed and --marginals-needed. In-Reply-To: <56312381.6090608@incenp.org> References: <1446044962-10219-1-git-send-email-dgouttegattat@incenp.org> <87io5qucz5.fsf@alice.fifthhorseman.net> <56312381.6090608@incenp.org> Message-ID: <8737wuu5l5.fsf@alice.fifthhorseman.net> On Wed 2015-10-28 15:35:29 -0400, Damien Goutte-Gattat wrote: > Well, at least in the context of the --completes-needed option, > "complete" means the same thing as "full", as this option has nothing to > do with ultimately trusted keys. Only one certification from such a key > is *always* enough to fully validate a UID, independently of the > --completes-needed value (this is hardcoded). ah, thanks for this clarification. This makes the --completes-needed syntax even weirder. Maybe we should change this to be --fulls-needed and add a historical/compatibility --completes-needed alias? > Full ownertrust only (see my remark above). yep. > I do not really like that "if we see certifications"... How about "if it > is certified" instead? > > --completes-needed: > > Consider a user ID (and its associated key) to be fully valid if it is > certified by at least this number of keys that have full ownertrust. > > (or: "this number of fully trusted keys") I like both of these versions. "keys that have full ownertrust" is slightly more specific (it avoids the confusion arising from many folks calling valid user ID "trusted" instead of "valid"), but "fully trusted keys" is definitely easier to read and undersatnd if you don't have that confusion. --dkg From dkg at fifthhorseman.net Wed Oct 28 21:49:10 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Oct 2015 16:49:10 -0400 Subject: GnuPG Github mirrors In-Reply-To: References: <562EF31A.2050407@sixdemonbag.org> <562FA6BB.8040406@internot.info> <87vb9s42iq.fsf@alice.fifthhorseman.net> <5630D6C5.6010603@internot.info> Message-ID: <87twpasoqh.fsf@alice.fifthhorseman.net> On Wed 2015-10-28 14:58:38 -0400, RB wrote: > GnuPG follows the same development process that existed for a large > plurality of FOSS software prior to Github. These models work, and > have for literally decades before Github even existed; the only > difference is the SCM has changed. I agree with this, and i also prefer a patches-and-mail workflow for my own work. I'm happy that's an acceptable workflow within GnuPG. But if we count by number of users, there's probably an order of magnitude more developers in existence today who understand github's standard workflow than those who understand patches-and-mail. Joshua was talking about writing a guide to help more people understand patches-and-mail. That's something you'd like to see happen, right? I don't think any of us want patches-and-mail to be some sort of hazing ritual, where learning the tools was so painful that we have to justify it by thinking that the pain was necessary and anyone who hasn't suffered accordingly is somehow unworthy. Do we? Hazing is generally a silly and unfortunate squandering of resources and goodwill. > It's amusing and frustrating to see a wave of developers insisting > that any workflow but github must be backwards or nonexistent. Some probably do make this claim; but many others simply don't know the tools for an unfamiliar workflow. Sometimes that's expressed as "the workflow i already know is more intuitive". This demonstrates a lack of imagination about how intuitions are formed, i think, but it's hardly something to get snippy about. Let's welcome more developers and help them broaden their intuitions, instead of telling folks to just RTFM. > Emailed patchsets and communication prior to submission are a useful > workflow, especially for tools that must necessarily be conservative > in their development. Just because you've gone through the motions of > forking a project on github and making your changes does not entitle > you to those changes moving upstream. The selectivity of upstream patch adoption has little to do with workflow choice. You can have extremely conservative, rejection-heavy (or ignore-heavy) projects on github. And you can have extremely permissive, we'll-accept-anything projects using patches-and-mail. adoption of patches upstream should be gated on quality of the code and the utility of the features added/bugs removed. right? What we shouldn't have is the workflow itself gating access to patch submission. That's just needless exclusion, and it's as limiting to the projects that could get new contributions as it is to the would-be contributors. The kind of writeup Joshua proposed could help avoid that scenario. > Communicate a little. yes, agreed. this is what we all want. let's get more people connected and communicating about the project. Happy hacking, --dkg From dgouttegattat at incenp.org Wed Oct 28 22:24:00 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 28 Oct 2015 22:24:00 +0100 Subject: [PATCH] doc: Clarify --completes-needed and --marginals-needed. In-Reply-To: <8737wuu5l5.fsf@alice.fifthhorseman.net> References: <8737wuu5l5.fsf@alice.fifthhorseman.net> Message-ID: <1446067440-10601-1-git-send-email-dgouttegattat@incenp.org> * doc/gpg.texi: Explain better how --completes-needed and --marginals-needed affect a user ID's validity. * doc/DETAILS: Ditto. -- New version of previously proposed patch, with better wording. Signed-off-by: Damien Goutte-Gattat --- doc/DETAILS | 8 ++++---- doc/gpg.texi | 10 ++++++---- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/doc/DETAILS b/doc/DETAILS index 97079b0..78af8a9 100644 --- a/doc/DETAILS +++ b/doc/DETAILS @@ -250,10 +250,10 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB: - Field 4 :: Date trustdb was created in seconds since Epoch. - Field 5 :: Date trustdb will expire in seconds since Epoch. - - Field 6 :: Number of marginally trusted users to introduce a new - key signer (gpg's option --marginals-needed). - - Field 7 :: Number of completely trusted users to introduce a new - key signer. (gpg's option --completes-needed) + - Field 6 :: Number of certifications from marginally trusted keys to + fully validate a UID. (gpg's option --marginals-needed) + - Field 7 :: Number of certifications from completely trusted keys to + fully validate a UID. (gpg's option --completes-needed) - Field 8 :: Maximum depth of a certification chain. (gpg's option --max-cert-depth) diff --git a/doc/gpg.texi b/doc/gpg.texi index 6e62917..cd30415 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -1682,13 +1682,15 @@ are available for all keyserver types, some common options are: @item --completes-needed @code{n} @opindex compliant-needed -Number of completely trusted users to introduce a new -key signer (defaults to 1). +Consider a user ID (and its associated key) to be fully valid +if it is certified by at least @code{n} fully trusted keys +(defaults to 1). @item --marginals-needed @code{n} @opindex marginals-needed -Number of marginally trusted users to introduce a new -key signer (defaults to 3) +Consider a user ID (and its associated key) to be fully valid +if it is certified by at least @code{n} marginally trusted +keys (defaults to 3). @item --tofu-default-policy @code{auto|good|unknown|bad|ask} @opindex tofu-default-policy -- 1.8.4 From dgouttegattat at incenp.org Wed Oct 28 22:40:16 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 28 Oct 2015 22:40:16 +0100 Subject: [PATCH] doc: Clarify --completes-needed and --marginals-needed. In-Reply-To: <8737wuu5l5.fsf@alice.fifthhorseman.net> References: <1446044962-10219-1-git-send-email-dgouttegattat@incenp.org> <87io5qucz5.fsf@alice.fifthhorseman.net> <56312381.6090608@incenp.org> <8737wuu5l5.fsf@alice.fifthhorseman.net> Message-ID: <563140C0.1070809@incenp.org> On 10/28/2015 08:59 PM, Daniel Kahn Gillmor wrote: > I like both of these versions. "keys that have full ownertrust" is > slightly more specific (it avoids the confusion arising from many folks > calling valid user ID "trusted" instead of "valid"), but "fully trusted > keys" is definitely easier to read and undersatnd if you don't have that > confusion. I went for "fully trusted keys". I hope that, in the long term, constantly using "trusted" to refer strictly to the ownertrust and "valid" to refer to the validity will help avoiding the confusion you are mentionning. Besides, I would guess that anyone willing to tweak those options probably knows quite well the difference between trust and validity. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From bjk at luxsci.net Wed Oct 28 23:21:53 2015 From: bjk at luxsci.net (Ben Kibbey) Date: Wed, 28 Oct 2015 18:21:53 -0400 Subject: [PATCH] Make use of user passphrase handler during passwd. Message-ID: <1446070924-5542720.35807229.ft9SMLrKA009683@rs146.luxsci.com> * src/passwd.c (passwd_start): set engine passphrase command handler. -- This allows for inquiring a passphrase when changing a passphrase rather than requiring a pinentry. --- src/passwd.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/passwd.c b/src/passwd.c index ff30df0..c34f357 100644 --- a/src/passwd.c +++ b/src/passwd.c @@ -148,6 +148,14 @@ passwd_start (gpgme_ctx_t ctx, int synchronous, gpgme_key_t key, _gpgme_engine_set_status_handler (ctx->engine, passwd_status_handler, ctx); + if (ctx->passphrase_cb) + { + err = _gpgme_engine_set_command_handler + (ctx->engine, _gpgme_passphrase_command_handler, ctx, NULL); + if (err) + return err; + } + return _gpgme_engine_op_passwd (ctx->engine, key, flags); } -- 2.6.1 From astieger at suse.com Thu Oct 29 09:47:10 2015 From: astieger at suse.com (Andreas Stieger) Date: Thu, 29 Oct 2015 09:47:10 +0100 Subject: BSI (DE) contract: preparing evaluation of GnuPG In-Reply-To: <201510271633.29674.bernhard@intevation.de> References: <201510271633.29674.bernhard@intevation.de> Message-ID: <5631DD0E.5020307@suse.com> Hello, On 10/27/2015 04:33 PM, Bernhard Reiter wrote: > ... to harden and document .. Gpg4win and "Gpg4KDE" with the aim > to prepare them for evaluation and a potential certification > for documents that carry the German classification "restricted". On the certificate manager side, is work limited to Kleopatra, or was the GNU Privacy Assistant (GPA) considered? With kind regards, Andreas Stieger -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From neal at walfield.org Thu Oct 29 11:52:46 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 29 Oct 2015 11:52:46 +0100 Subject: Proposal: New keydb format Message-ID: <87a8r27xq9.wl-neal@walfield.org> Hi, Some people have complained that GnuPG is slow when accessing the key db (e.g., [1]). To mitigate this, GnuPG has some ugly caches (commit 492792), which are not completely transparent and introduce subtle bugs that are very hard to find (see, e.g., commits 60bc518 and ee7ec12, which demonstrate a cache inconsistency). Werner was the opinion that the performance problem is due to signature verification and not due to DB accesses. To test this theory, I did some measurements yesterday and I implemented a small prototype, which uses SQLite as the underlying storage engine. It can be retrieved from git on the neal/next branch. [1] https://bugs.gnupg.org/gnupg/issue2019 Here are some timing results. I use the Debian keyring (/usr/share/keyrings/debian-keyring.gpg), which contains 751 keys. Importing the keyring: 2 minutes (keybox) vs. 8 seconds (new): $ rm pubring.kdx; time gpg2 --no-default-keyring --primary-keyring gnupg-kbx:pubring.kdx --import debian-keyring.gpg >/dev/null gpg: Total number processed: 751 gpg: imported: 751 gpg: public key of ultimately trusted key 2183839A not found gpg: public key of ultimately trusted key BC15C85A not found gpg: public key of ultimately trusted key EE37CF96 not found real 1m52.560s user 0m6.268s sys 0m31.604s $ rm pubring.kdb; time gpg2 --no-default-keyring --primary-keyring gnupg-kdb:pubring.kdb --import debian-keyring.gpg >/dev/null gpg: Total number processed: 751 gpg: imported: 751 real 0m7.729s user 0m5.404s sys 0m0.332s Running --check-trustdb: 1 second (keybox) vs 0.2 seconds (new): $ time gpg2 --no-default-keyring --primary-keyring gnupg-kbx:pubring.kbx --check-trustdb real 0m0.975s user 0m0.012s sys 0m0.032s $ time gpg2 --no-default-keyring --primary-keyring gnupg-kdb:pubring.kdb --check-trustdb real 0m0.158s user 0m0.004s sys 0m0.004s Doing a sequential scan is a bit slower with the new format: 1.2s (keybox) vs 2.5s (new): $ time gpg2 --no-default-keyring --primary-keyring gnupg-kbx:pubring.kdx -k | grep ^pub | wc -l gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! 751 real 0m1.245s user 0m1.168s sys 0m0.076s $ time gpg2 --no-default-keyring --primary-keyring gnupg-kdb:pubring.kdb -k | grep ^pub | wc -l 751 real 0m2.515s user 0m2.432s sys 0m0.088s This is likely due to the impedance mismatch between the current interface for doing a full scan and SQLite API's interface for doing a full scan (we need to resume the search; currently I reexecute a query for each new result and skip the previous results). If we decide to use the new format, it shouldn't be hard to improve this. I'd be interested in any feedback as well as some more measurements of the performance in real conditions. Note: the code is incomplete, but the essentials should work. Thanks, :) Neal From dgouttegattat at incenp.org Thu Oct 29 12:22:02 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 29 Oct 2015 12:22:02 +0100 Subject: [PATCH 3/3] scute: Update manual. In-Reply-To: <1446117722-20487-1-git-send-email-dgouttegattat@incenp.org> References: <1446117722-20487-1-git-send-email-dgouttegattat@incenp.org> Message-ID: <1446117722-20487-3-git-send-email-dgouttegattat@incenp.org> * doc/manual/scute.texi: Update dependencies. Add a note about GnuPG 2.1 and the GPG_AGENT_INFO variable. Signed-off-by: Damien Goutte-Gattat --- doc/manual/scute.texi | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/doc/manual/scute.texi b/doc/manual/scute.texi index 01d4784..875796a 100644 --- a/doc/manual/scute.texi +++ b/doc/manual/scute.texi @@ -241,12 +241,12 @@ following packages at build time: @table @code @item libgpg-error Scute uses the GnuPG 2.0 framework for error handling, so it depends on -the GPG error library. The minimum version required is 0.7. +the GPG error library. The minimum version required is 1.4. @item libassuan Scute uses the GnuPG 2.0 framework for communication with the GPG Agent, so it depends on the Assuan library. The minimum version required is -0.6.10. +2.0.0. @end table At run-time, in addition to the run-time versions of the above @@ -265,6 +265,10 @@ that you fulfill this requirement before using Scute in an application, running the Scute test suite, or preparing certificates as described in @ref{Certificate Preparation}. @xref{Invoking GPG-AGENT, , , gnupg, Using the GNU Privacy Guard}, for details on how to run the GPG Agent. +Note that with GnuPG 2.1 or later, the @code{GPG_AGENT_INFO} environment +variable is no longer needed, but you must still make sure the GPG Agent +is started before using Scute, as Scute cannot start the agent on +demand. @item Pinentry Pinentry is a dependency of GnuPG 2.0, so it also needs to be installed -- 1.8.4 From dgouttegattat at incenp.org Thu Oct 29 12:22:00 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 29 Oct 2015 12:22:00 +0100 Subject: [PATCH 1/3] scute: Do not show deprecated gpgsm-gencert.sh. Message-ID: <1446117722-20487-1-git-send-email-dgouttegattat@incenp.org> * README: Show example of gpgsm --gen-key usage instead of deprecated gpgsm-gencert.sh. * doc/manual/scute.texi: Ditto. -- The gpgsm-gencert.sh script has been deprecated a long time ago and is no longer distributed with GpgSM. The proper way of generating a X.509 certificate request from a OpenPGP key is to call gpgsm --gen-key. Signed-off-by: Damien Goutte-Gattat --- README | 64 +++++++++++++++++++++++---------------------- doc/manual/scute.texi | 72 +++++++++++++++++++++++---------------------------- 2 files changed, 66 insertions(+), 70 deletions(-) diff --git a/README b/README index 42e7802..ac443dc 100644 --- a/README +++ b/README @@ -92,51 +92,53 @@ http://www.gnupg.org/(en)/howtos/card-howto/en/smartcard-howto.html Once the card is initialised, we have to generate a certificate signing request (CSR) to get the authentication key of the card (OPENPGP.3, the third key on the card) certified by the CA. This can -be done with the script "gpgsm-gencert.sh". For the CSR, a -distinguished name (DN) is required. Your CA will have more -information about what this DN should contain. Below we use an -example for a test-employee "Floppy Head" of the test-CA that ships -with OpenSSL ("Snake Oil, Ltd."). +be done with GPGSM. For the CSR, a distinguished name (DN) is +required. Your CA will have more information about what this DN +should contain. Below we use an example for a test-employee "Floppy +Head" of the test-CA that ships with OpenSSL ("Snake Oil, Ltd."). Generating the CSR is then just a matter of answering a few questions: -$ gpgsm-gencert.sh > /tmp/floppy.csr -Key type - [1] RSA - [2] existing key - [3] OPENPGP.1 - [4] OPENPGP.3 -Your selection: 4 -You selected: OPENPGP.3 -Key usage - [1] sign, encrypt - [2] sign - [3] encrypt -Your selection: 2 -You selected: sign -Name (DN) -> CN=Floppy Head,OU=Webserver Team,O="Snake Oil, Ltd",L=Snake Town,ST=Snake Desert,C=XY -E-Mail addresses (end with an empty line) +$ gpgsm --armor --output /tmp/floppy.csr --gen-key + +Please select what kind of key you want: + (1) RSA + (2) Existing key + (3) Existing key from card +Your selection: 3 + +Serial number of the card: D27600012401010100010000051B0000 +Available keys: + (1) 39820691E60A775AF9B979F4A960B23A2FC8892A OPENPGP.1 + (2) BE3918CCCC237E42AF6D15869DCAE291276C5548 OPENPGP.2 + (3) 386F81432E2C864085885251EB5D6D0B875D1E91 OPENPGP.3 +Your selection? 3 + +Possible actions for a RSA key: + (1) sign, encrypt + (2) sign + (3) encrypt +Your selection? 2 +Enter the X.509 subject name: CN=Floppy Head,OU=Webserver Team,O="Snake Oil, Ltd",L=Snake Town,ST=Snake Desert,C=XY +Enter email addresses (end with an empty line): > floppy at head.com -E-Mail addresses (end with an empty line) > -DNS Names (optional; end with an empty line) +Enter DNS names (optional; end with an empty line): > -URIs (optional; end with an empty line) +Enter URIs (optional; end with an empty line): > Parameters for certificate request to create: 1 Key-Type: card:OPENPGP.3 - 2 Key-Length: + 2 Key-Length: 1024 3 Key-Usage: sign 4 Name-DN: CN=Floppy Head,OU=Webserver Team,O="Snake Oil, Ltd",L=Snake Town,ST=Snake Desert,C=XY 5 Name-Email: floppy at head.com -Really create such a CSR? - [1] yes - [2] no -Your selection: 1 -You selected: yes +Really create request? (y/N) y +Now creating certificate request. This may take a while ... +gpgsm: about to sign CSR for key: &386F81432E2C864085885251EB5D6D0B875D1E91 gpgsm: certificate request created +Ready. You should now send this request to your CA. It is required to enter the signing PIN of the card to complete this step. The certificate can then be found in the file "/tmp/floppy.csr". diff --git a/doc/manual/scute.texi b/doc/manual/scute.texi index ceed13e..01d4784 100644 --- a/doc/manual/scute.texi +++ b/doc/manual/scute.texi @@ -310,52 +310,47 @@ Before you start, make sure that the GPG Agent is running, see create a CSR with the command: @example -$ gpgsm-gencert.sh > floppy-head.p10 -Key type - [1] RSA - [2] Existing key - [3] Direct from card -Your selection: 3 -You selected: Direct from card +$ gpgsm --armor --output floppy-head.p10 --gen-key + +Please select what kind of key you want: + (1) RSA + (2) Existing key + (3) Existing key from card +Your selection? 3 @end example -As we create a certificate for the OpenPGP Card, the option ``@code{[3] -Direct from card}'' should be selected. +As we create a certificate for the OpenPGP Card, the option ``@code{(3) +Existing key from card}'' should be selected. @example -Card with S/N D27600012401010100010000051B0000 found -gpg-agent uses OPENPGP.3 as ssh key -Select key - [1] OPENPGP.1 - [2] OPENPGP.2 - [3] OPENPGP.3 - [4] back -Your selection: 3 -You selected: OPENPGP.3 -Key usage - [1] sign, encrypt - [2] sign - [3] encrypt -Your selection: 2 -You selected: sign +Serial number of the card: D27600012401010100010000051B0000 +Available keys: + (1) 39820691E60A775AF9B979F4A960B23A2FC8892A OPENPGP.1 + (2) BE3918CCCC237E42AF6D15869DCAE291276C5548 OPENPGP.2 + (3) 386F81432E2C864085885251EB5D6D0B875D1E91 OPENPGP.3 +Your selection? 3 + +Possible actions for a RSA key: + (1) sign, encrypt + (2) sign + (3) encrypt +Your selection? 2 @end example The only operation currently supported is client authentication. For this, the authentication key has to be selected. This is the third key -on the card, so the options ``@code{[3] OPENPGP.3}'' and ``@code{[2] +on the card, so the options ``@code{(3) OPENPGP.3}'' and ``@code{(2) sign}'' should be chosen. Note that the key usage is only advisory, and the CA may assign different capabilities. @example -Name (DN) -> CN=Floppy Head,OU="Webserver Team",O="Snake Oil, Ltd",L="Snake Town",ST="Snake Desert",C=XY -E-Mail addresses (end with an empty line) +Enter the X.509 subject name: CN=Floppy Head,OU=Webserver Team,O="Snake Oil, Ltd",L=Snake Town,ST=Snake Desert,C=XY +Enter email addresses (end with an empty line): > floppy.head@@example.com -E-Mail addresses (end with an empty line) > -DNS Names (optional; end with an empty line) +Enter DNS names (optional; end with an empty line): > -URIs (optional; end with an empty line) +Enter URIs (optional; end with an empty line) > @end example @@ -370,16 +365,14 @@ it has gathered and ask whether to create the certificate request: @example Parameters for certificate request to create: 1 Key-Type: card:OPENPGP.3 - 2 Key-Length: + 2 Key-Length: 1024 3 Key-Usage: sign - 4 Name-DN: CN=Floppy Head,OU="Webserver Team",O="Snake Oil, Ltd",L="Snake Town",ST="Snake Desert",C=XY + 4 Name-DN: CN=Floppy Head,OU=Webserver Team,O="Snake Oil, Ltd",L=Snake Town,ST=Snake Desert,C=XY 5 Name-Email: floppy.head@@example.com -Really create such a CSR? - [1] yes - [2] no -Your selection: 1 -You selected: yes +Really create request? (y/N) y +Now creating certificate request. This may take a while ... +gpgsm: about to sign CSR for key: &386F81432E2C864085885251EB5D6D0B875D1E91 @end example GPGSM will now start working on creating the request. During this time @@ -389,7 +382,8 @@ key on the card. A pop up window will appear to ask for it. When it is ready, you should see the final notice: @example - gpgsm: certificate request created +gpgsm: certificate request created +Ready. You should now send this request to your CA. @end example Now, you may look at the created request: -- 1.8.4 From dgouttegattat at incenp.org Thu Oct 29 12:22:01 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 29 Oct 2015 12:22:01 +0100 Subject: [PATCH 2/3] scute: Update website infos. In-Reply-To: <1446117722-20487-1-git-send-email-dgouttegattat@incenp.org> References: <1446117722-20487-1-git-send-email-dgouttegattat@incenp.org> Message-ID: <1446117722-20487-2-git-send-email-dgouttegattat@incenp.org> * doc/website/download.xhtml: Update list of releases, dependencies and URL to the Git repository. Signed-off-by: Damien Goutte-Gattat --- doc/website/download.xhtml | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/doc/website/download.xhtml b/doc/website/download.xhtml index 2e395ff..3de42e1 100644 --- a/doc/website/download.xhtml +++ b/doc/website/download.xhtml @@ -56,25 +56,25 @@ be cross-built for Windows 32-bit using MingW32.

- The most recent release of Scute is version 1.2.0. The + The most recent release of Scute is version 1.4.0. The following files belong to this release. - + - - + +
The files released with Scute 1.2.0.The files released with Scute 1.4.0.
FileDescriptionSignature
Scute 1.2.0 source package - The source code of Scute 1.2.0Digital Signature
Scute 1.4.0 source package + The source code of Scute 1.4.0Digital Signature

- The previous release of Scute was version 1.1.0. The + The previous release of Scute was version 1.3.0. The following files belong to this release. - + - - + +
The files released with Scute 1.1.0.The files released with Scute 1.3.0.
FileDescriptionSignature
Scute 1.1.0 source package - The source code of Scute 1.1.0Digital Signature
Scute 1.3.0 source package + The source code of Scute 1.3.0Digital Signature

@@ -94,9 +94,9 @@ Compile-time dependencies of Scute PackageMin. Version libgpg-error0.7 + href="http://www.gnupg.org/related_software/libgpg-error/">libgpg-error1.3 libassuan0.6.10 + href="http://www.gnupg.org/related_software/libassuan/">libassuan2.0.0

Scute also requires the following packages to run: @@ -121,12 +121,12 @@

Development

- The source of Scute is managed with the version control - system Subversion. The - repository can be retrieved with the following command: + The source of Scute is managed with the Git distributed version control + system. The repository can be retrieved with the following + command: 

-	    $  svn co svn://cvs.gnupg.org/scute/trunk scute
+	    $ git clone git://git.gnupg.org/scute.git
Please send an e-mail to the GnuPG @@ -135,7 +135,7 @@

A web interface to the Scute + href="http://git.gnupg.org/cgi-bin/gitweb.cgi?p=scute.git;a=summary">Scute source repository is available on-line, and contains up-to-date as well as archived versions of all files included in the Scute source package, including the most -- 1.8.4 From wk at gnupg.org Thu Oct 29 14:44:08 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 29 Oct 2015 14:44:08 +0100 Subject: BSI (DE) contract: preparing evaluation of GnuPG In-Reply-To: <5631DD0E.5020307@suse.com> (Andreas Stieger's message of "Thu, 29 Oct 2015 09:47:10 +0100") References: <201510271633.29674.bernhard@intevation.de> <5631DD0E.5020307@suse.com> Message-ID: <877fm56b87.fsf@vigenere.g10code.de> On Thu, 29 Oct 2015 09:47, astieger at suse.com said: > On the certificate manager side, is work limited to Kleopatra, or was > the GNU Privacy Assistant (GPA) considered? The BSI once settled on KDE and thus GPA is of no interest to them. Well, except for one project where we could finish a milestone only by having implemented smartcard management in GPA (in particular for the Telesec cards). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Thu Oct 29 15:55:58 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 29 Oct 2015 15:55:58 +0100 Subject: BSI (DE) contract: preparing evaluation of GnuPG In-Reply-To: <877fm56b87.fsf@vigenere.g10code.de> References: <201510271633.29674.bernhard@intevation.de> <5631DD0E.5020307@suse.com> <877fm56b87.fsf@vigenere.g10code.de> Message-ID: <201510291556.04687.bernhard@intevation.de> Hi Andreas, On Thursday 29 October 2015 at 14:44:08, Werner Koch wrote: > On Thu, 29 Oct 2015 09:47, astieger at suse.com said: > > On the certificate manager side, is work limited to Kleopatra, or was > > the GNU Privacy Assistant (GPA) considered? GPA is not subject of the contract. However most of the work of providing a stricter configuration and a documentation for evaluation will be on lower levels. So GPA would potentially also profit. > The BSI once settled on KDE and thus GPA is of no interest to them. > Well, except for one project where we could finish a milestone only by > having implemented smartcard management in GPA (in particular for the > Telesec cards). It is a good thing to have one GNU/Linux variant in the contract. www.gpg4kde.org a few years ago gave a single name to a combination of products running GNU/Linux. For completeness: KDE is an initiative that produces a lot of nice Free Software products. While a lot of people do not use Plasma (the windows/desktop manager), many more use applications based on KDE Plattform 4 or the upcoming Frameworks 5 on their favorite operating system (Digikam on Windows for instance) or window/desktop manager. During the (separate) Gpg4all contract some work on Kleopatra will done. We hope to make it more lightweight, easier to hack by porting it to Qt5 and Frameworks 5. More details forthcoming in wiki.gnupg.org. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 guilhem at fripost.org Thu Oct 29 15:28:28 2015 From: guilhem at fripost.org (Guilhem Moulin) Date: Thu, 29 Oct 2015 15:28:28 +0100 Subject: Proposal: New keydb format In-Reply-To: <87a8r27xq9.wl-neal@walfield.org> References: <87a8r27xq9.wl-neal@walfield.org> Message-ID: <20151029142828.GA9973@localhost.localdomain> Hi Neal, On Thu, 29 Oct 2015 at 11:52:46 +0100, Neal H. Walfield wrote: > I'd be interested in any feedback as well as some more measurements of > the performance in real conditions. Note: the code is incomplete, but > the essentials should work. Thanks for working on this! I'd like to see if this new format also improves --list-sigs, which is very slow on a keybox, especially on 32 bits platforms (see issue1938). Assuming an index on 64-bit key IDs, I expect a significant performance boost when looking up the signer's key to display their primary UID. Unfortunately I wasn't able to benchmark issue1938 with the new format as the signers' primary UID is never printed (as if --fast-list-mode was always set): ~$ ./g10/gpg2 --homedir /run/shm/gnupg-kdb --with-colons --list-sigs | \ grep -E '^(sig|rev):' | \ grep -vE '^(sig|rev):([^:]*:){8}\[User ID not found\]:' Care to look into that? I'd be happy to resume the benchmark later. Also, probably due to the slow ?full scan? you mentioned, note that merely looking all sigs but avoiding nested lookups with ?--fast-list-mode --list-sigs? is much slower with kdb than with a keybox: ~$ time gpg --homedir /run/shm/gnupg-ring --fast-list-mode --list-sigs >/dev/null 0:02.15 (2.14 user, 0.01 sys) 11012k maxres ~$ time gpg2 --homedir /run/shm/gnupg-kbx --fast-list-mode --list-sigs >/dev/null 0:00.84 (0.82 user, 0.01 sys) 16536k maxres ~$ time ./g10/gpg2 --homedir /run/shm/gnupg-kdb --fast-list-mode --list-sigs >/dev/null 0:06.30 (6.23 user, 0.06 sys) 19280k maxres Cheers, -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From bernhard at intevation.de Fri Oct 30 09:52:09 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 30 Oct 2015 09:52:09 +0100 Subject: cert and key for problem reporting? Message-ID: <201510300952.15334.bernhard@intevation.de> Moin, occasionally I want people to send encrypted test emails so a problem can be reproduced [1]. I wonder if we have good documentation to make this easy. As I am not aware of any, I'd put something in the wiki. The question is: Which test key and cert should people use? In Git there are some test keys, e.g. in http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=tree;f=tests/openpgp there are secdemo.asc and the corresponding pubdemo.asc. Drawbacks are: These are many certs at once, while one would be enough. They are old (which should not influence an email structure, but maybe in other tests the choice of algorithms make a difference.) For my idea it would be cool to have a single cert and its key available, maybe two for each default (key creation) configuration that GnuPG has offered over time. Is there such a file with one or two keys for an 2048 rsa with subkeys default that could be used? If not, I propose to add one. Is there already documentation somewhere how to import, do the test and then delete the certs and keys again? Best, Bernhard [1] An example is this forum request by someone who cannot decrypt an gpgmail email. Having an example file by someone that uses gpgmail where the structure could be studied, would be good to have to provide assistance. https://wald.intevation.org/forum/forum.php?thread_id=1551&forum_id=21&group_id=11 -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by 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 dkg at fifthhorseman.net Thu Oct 29 21:25:35 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 30 Oct 2015 05:25:35 +0900 Subject: Proposal: New keydb format In-Reply-To: <87a8r27xq9.wl-neal@walfield.org> References: <87a8r27xq9.wl-neal@walfield.org> Message-ID: <871tcd2zi8.fsf@alice.fifthhorseman.net> Hi Neal-- On Thu 2015-10-29 06:52:46 -0400, "Neal H. Walfield" wrote: > Some people have complained that GnuPG is slow when accessing the key > db (e.g., [1]). To mitigate this, GnuPG has some ugly caches (commit > 492792), which are not completely transparent and introduce subtle > bugs that are very hard to find (see, e.g., commits 60bc518 and > ee7ec12, which demonstrate a cache inconsistency). > > Werner was the opinion that the performance problem is due to > signature verification and not due to DB accesses. To test this > theory, I did some measurements yesterday and I implemented a small > prototype, which uses SQLite as the underlying storage engine. It can > be retrieved from git on the neal/next branch. Wow, thank you for doing this work. I'm really glad to see it! > [1] https://bugs.gnupg.org/gnupg/issue2019 > > Here are some timing results. I use the Debian keyring > (/usr/share/keyrings/debian-keyring.gpg), which contains 751 keys. > > Importing the keyring: 2 minutes (keybox) vs. 8 seconds (new): > > $ rm pubring.kdx; time gpg2 --no-default-keyring --primary-keyring > gnupg-kbx:pubring.kdx --import debian-keyring.gpg >/dev/null > gpg: Total number processed: 751 > gpg: imported: 751 > gpg: public key of ultimately trusted key 2183839A not found > gpg: public key of ultimately trusted key BC15C85A not found > gpg: public key of ultimately trusted key EE37CF96 not found Out of curiosity, did you try these with --no-auto-check-trustdb? the three lines above suggest that you have some sort of ownertrust in use, so some of the time spent might be spent doing an automatic trustdb rebuild, which would confuse the measurements a bit. > real 1m52.560s > user 0m6.268s > sys 0m31.604s One interesting thing to note here is that the time spent by the CPU in userspace and the kernel is 38s -- the real ("wall") time is over three times that. This suggests that something is going on with your I/O subsystem (or that gpg itself is thrashing the kernel's disk I/O subsystem). still, 38s compared to the 6s from the kdb run is a signficant difference if we can rule out the trustdb check: > real 0m7.729s > user 0m5.404s > sys 0m0.332s Have you tried more delicate actions like concurrent updates or keyring merges? --dkg From neal at walfield.org Fri Oct 30 11:11:27 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 30 Oct 2015 11:11:27 +0100 Subject: Proposal: New keydb format In-Reply-To: <871tcd2zi8.fsf@alice.fifthhorseman.net> References: <87a8r27xq9.wl-neal@walfield.org> <871tcd2zi8.fsf@alice.fifthhorseman.net> Message-ID: <8737ws8y40.wl-neal@walfield.org> Hi Daniel, At Fri, 30 Oct 2015 05:25:35 +0900, Daniel Kahn Gillmor wrote: > On Thu 2015-10-29 06:52:46 -0400, "Neal H. Walfield" wrote: > > Some people have complained that GnuPG is slow when accessing the key > > db (e.g., [1]). To mitigate this, GnuPG has some ugly caches (commit > > 492792), which are not completely transparent and introduce subtle > > bugs that are very hard to find (see, e.g., commits 60bc518 and > > ee7ec12, which demonstrate a cache inconsistency). > > > > Werner was the opinion that the performance problem is due to > > signature verification and not due to DB accesses. To test this > > theory, I did some measurements yesterday and I implemented a small > > prototype, which uses SQLite as the underlying storage engine. It can > > be retrieved from git on the neal/next branch. > > Wow, thank you for doing this work. I'm really glad to see it! :) Out of curiosity, are you suggesting that the performance of kbx is a real problem for you in practice? If so, I'd like to understand your setup a bit better. (Feel free to reply off-list.) > > [1] https://bugs.gnupg.org/gnupg/issue2019 > > > > Here are some timing results. I use the Debian keyring > > (/usr/share/keyrings/debian-keyring.gpg), which contains 751 keys. > > > > Importing the keyring: 2 minutes (keybox) vs. 8 seconds (new): > > > > $ rm pubring.kdx; time gpg2 --no-default-keyring --primary-keyring > > gnupg-kbx:pubring.kdx --import debian-keyring.gpg >/dev/null > > gpg: Total number processed: 751 > > gpg: imported: 751 > > gpg: public key of ultimately trusted key 2183839A not found > > gpg: public key of ultimately trusted key BC15C85A not found > > gpg: public key of ultimately trusted key EE37CF96 not found > > Out of curiosity, did you try these with --no-auto-check-trustdb? the > three lines above suggest that you have some sort of ownertrust in use, > so some of the time spent might be spent doing an automatic trustdb > rebuild, which would confuse the measurements a bit. That's a good point. I'll try to keep that in mind the next time I run the benchmark. > > > > real 1m52.560s > > user 0m6.268s > > sys 0m31.604s > > One interesting thing to note here is that the time spent by the CPU in > userspace and the kernel is 38s -- the real ("wall") time is over three > times that. This suggests that something is going on with your I/O > subsystem (or that gpg itself is thrashing the kernel's disk I/O > subsystem). I observed this as well, but I didn't have an explanation other than latency, which is quite high given that I have an ssd and nothing else was running. > still, 38s compared to the 6s from the kdb run is a signficant > difference if we can rule out the trustdb check: FWIW, the trustdb check would have been done in both cases. > Have you tried more delicate actions like concurrent updates or keyring > merges? Not yet. This is just a small proof of concept. It's unclear whether this issue is important enough to dedicate resources to it. Feel free to make a case. Thanks! :) Neal From bertrand at jacquin.bzh Fri Oct 30 22:22:34 2015 From: bertrand at jacquin.bzh (Bertrand Jacquin) Date: Fri, 30 Oct 2015 21:22:34 +0000 Subject: gpgsm --gen-key segfault with ECC key on smartcard In-Reply-To: <877fm79til.fsf@vigenere.g10code.de> References: <20150819212750.GA12535@lady-voodoo.scabb> <877fm79til.fsf@vigenere.g10code.de> Message-ID: <20151030212234.GI6422@lady-voodoo.scabb> Hi Werner, On Wed, Oct 28, 2015 at 11:28:34AM +0100, Werner Koch wrote: > On Mon, 26 Oct 2015 15:34, bertrand at jacquin.bzh said: > > On 19/08/2015 22:27, Bertrand Jacquin wrote: > > >> I'm getting a SEGV running gpgsm --gen-key with GnuPG 2.1.6. The issue > >> comes from libksba. Here is a backtrace: > > Thanks for the data. I can't replicate this right now but the backtrace > was helpful enough. The attached patch to libksba should fix the segv. > I look into extending the table of curve names. Thanks for this. I've just tested that and in fact I'm not getting a SEGV anymore. Instead, I'm getting the following error: Proceed with creation? (y/N) y Now creating self-signed certificate. This may take a while ... gpgsm: error setting the siginfo: Wrong public key algorithm gpgsm: error creating certificate request: Wrong public key algorithm Is this expected for EdDSA keys ? Cheers, > Shalom-Salam, > > Werner > > ======== > From 9df0ac3a4afa0272dbff08d17e9064f13be95814 Mon Sep 17 00:00:00 2001 > From: Werner Koch > Date: Wed, 28 Oct 2015 11:18:59 +0100 > Subject: [PATCH] Fix lookup of ECC OIDs by name. > > * src/keyinfo.c (get_ecc_curve_oid): Fix obviously never tested table > lookup. > -- > > This led to a crash see > https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030445.html > > The fix is obvious but I do not have test data for this. > > Signed-off-by: Werner Koch > --- > src/keyinfo.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/keyinfo.c b/src/keyinfo.c > index 02dc7ae..3ea0cfa 100644 > --- a/src/keyinfo.c > +++ b/src/keyinfo.c > @@ -322,10 +322,10 @@ get_ecc_curve_oid (const unsigned char *buf, size_t buflen, size_t *r_oidlen) > if (buflen == strlen (curve_names[i].name) > && !memcmp (buf, curve_names[i].name, buflen)) > break; > - if (curve_names[i].oid) > + if (!curve_names[i].oid) > return NULL; /* Not found. */ > - buf = curve_names[i].name; > - buflen = strlen (curve_names[i].name); > + buf = curve_names[i].oid; > + buflen = strlen (curve_names[i].oid); > } > > if (_ksba_oid_from_buf (buf, buflen, &der_oid, r_oidlen)) > -- > 2.1.4 > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -- Bertrand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Digital signature URL: From wk at gnupg.org Fri Oct 30 23:25:41 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 30 Oct 2015 23:25:41 +0100 Subject: gpgsm --gen-key segfault with ECC key on smartcard In-Reply-To: <20151030212234.GI6422@lady-voodoo.scabb> (Bertrand Jacquin's message of "Fri, 30 Oct 2015 21:22:34 +0000") References: <20150819212750.GA12535@lady-voodoo.scabb> <877fm79til.fsf@vigenere.g10code.de> <20151030212234.GI6422@lady-voodoo.scabb> Message-ID: <87y4ek0za2.fsf@vigenere.g10code.de> On Fri, 30 Oct 2015 22:22, bertrand at jacquin.bzh said: > gpgsm: error creating certificate request: Wrong public key algorithm > > > Is this expected for EdDSA keys ? Yes, we don't have support for this in X.509. If there is an I-D which will likely reach RFC status, I'd glad to apply patches. However, X.509 is not a priority task and thus me or Neal won't work on it in the next few months. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Sat Oct 31 01:58:00 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 31 Oct 2015 01:58:00 +0100 Subject: Proposal: New keydb format In-Reply-To: <20151029142828.GA9973@localhost.localdomain> References: <87a8r27xq9.wl-neal@walfield.org> <20151029142828.GA9973@localhost.localdomain> Message-ID: <87vb9n7t2f.wl-neal@walfield.org> Hi Guilhem, Thanks for taking a look at the code! At Thu, 29 Oct 2015 15:28:28 +0100, Guilhem Moulin wrote: > On Thu, 29 Oct 2015 at 11:52:46 +0100, Neal H. Walfield wrote: > > I'd be interested in any feedback as well as some more measurements of > > the performance in real conditions. Note: the code is incomplete, but > > the essentials should work. > > Thanks for working on this! I'd like to see if this new format also > improves --list-sigs, which is very slow on a keybox, especially on 32 > bits platforms (see issue1938). > > Assuming an index on 64-bit key IDs, I expect a significant performance > boost when looking up the signer's key to display their primary UID. > Unfortunately I wasn't able to benchmark issue1938 with the new format > as the signers' primary UID is never printed (as if --fast-list-mode was > always set): > > ~$ ./g10/gpg2 --homedir /run/shm/gnupg-kdb --with-colons --list-sigs | \ > grep -E '^(sig|rev):' | \ > grep -vE '^(sig|rev):([^:]*:){8}\[User ID not found\]:' > > Care to look into that? I'd be happy to resume the benchmark later. I spent a little bit of time on this this evening and found the bug. I think --with-colons --list-sigs should now work. > Also, probably due to the slow ?full scan? you mentioned, note that > merely looking all sigs but avoiding nested lookups with > ?--fast-list-mode --list-sigs? is much slower with kdb than with a > keybox: I added a couple of optimizations as well. Please feel free to run some benchmarks. FWIW, I probably won't be working on this much in the near future as it is not currently a priority for us. :) Neal