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 I think the convention is to allocated
MAX_PASSPHRASE_LEN+1 bytes for the buffer.
Thanks!
:) Neal
From wk at gnupg.org Thu Oct 1 13:26:14 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 01 Oct 2015 13:26:14 +0200
Subject: ssh: Fix allocation of pinentry buffer
In-Reply-To: <560CB62B.6030303@fsij.org> (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 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.
@@ -94,9 +94,9 @@
Compile-time dependencies of Scute
Package | Min. Version |
libgpg-error | 0.7 |
+ href="http://www.gnupg.org/related_software/libgpg-error/">libgpg-error1.3 |
libassuan | 0.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