From aixtools at gmail.com Sun Mar 1 20:09:14 2015 From: aixtools at gmail.com (Michael Felt) Date: Sun, 1 Mar 2015 20:09:14 +0100 Subject: PKA updates In-Reply-To: <87sidqr84c.fsf@alice.fifthhorseman.net> References: <874mqaugf9.fsf@vigenere.g10code.de> <87385tspau.fsf@alice.fifthhorseman.net> <87lhjlt6k0.fsf@vigenere.g10code.de> <87sidqr84c.fsf@alice.fifthhorseman.net> Message-ID: My two cents - more organizational than technical. Any technology, to gain acceptance, needs to be easy to implement - so that the benefit overwhelms you. The technology might not be perfect - a 1st generation, basically by definition - never is. However, if the benefit is clear - AND minimal/no (further) organizational/management load to provide "some additional" security - then, even if not perfect adoption starts. What I read above is that the technology will be able to (better) support management in how to setup "this new feature" and it will be easier to automate better secrecy (aka encryption) of e-mails than now. I hope I got that part right at least. So, a choice between nothing, or something AND easy to implement, may be a first step into gaining ADOPTION of PKA, DNSSEC, XXX. Maybe - rather than being initially concerned with the encryption of messages - a way to automate the signing and verification of messages will be something that will interest users. In short - fulfill a need and technology (improvements) will follow. Michael On Sat, Feb 28, 2015 at 5:08 AM, Daniel Kahn Gillmor wrote: > On Thu 2015-02-26 03:34:23 -0500, Werner Koch wrote: > > On Wed, 25 Feb 2015 21:34, dkg at fifthhorseman.net said: > > > >> https://tools.ietf.org/html/draft-ietf-dane-openpgpkey ? Should we try > >> to support this draft? > > > > I looked at this again. > > > > - It requires a new record type > > I'm not sure that a new record type is much of a problem. Most DNS > servers support generic types these days, and the hash-slinger code > can produce hex-encoded records that should be acceptable. > > http://people.redhat.com/pwouters/hash-slinger/ > > > - It merges the first time key retrieval with the validation of the > > key. > > The draft allows for validation of the key via DNS fetch, but it doesn't > require that the MUA treat the dnssec validation as authoritative. > > > [ - Why using SHA224 for hashing if this is just for maiing the > > local-part. ] > > i'm not sure what the issue is here. can you explain further? My > understanding is that the digest is to avoid DNS labels that are either > too long, or contain unwieldy characters, not as an attempt to mask the > identity being looked up. > > > That was my original idea behind PKA. I don't think that is anymore > > justified. However, if you trust DNSSEC gpg can already be tweaked to > > that that in account by using "--verify-options pka-trust-increase" etc. > > Can you explain more why you no longer think that using dnssec as a > corroborative channel is justified? I'm personally wary of the > hierarchical model for DNSSEC, but i don't think that invalidates it for > corroboration. > > >> There are other kinds of security at issue, though: DNS provides a > >> pretty nasty leakage channel, since confidential DNS query mechanisms > >> are not widely deployed. I'd hope that DNS lookups aren't necessarily > > > > I think this decision should be left to the MUAs. If it is enabled by > > default, that would be better than sending mails in the clear. Thus for > > a first time non-expert installation enabling such a feature by default > > would be the Right Thing. > > Well, sending mail in the clear over a STARTTLS submission channel only > leaks the To: information to the user's sending MTA, while the DNS query > leaks the same information to every machine along the network path to > the DNS server. > > But i think you're right that this is something that can be mitigated > with sensible MUA operation, caching results, etc. > > --dkg > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Mon Mar 2 02:46:36 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 02 Mar 2015 02:46:36 +0100 Subject: unapplied Danish localization on STABLE-BRANCH-1-4 Message-ID: <87pp8s9nnn.fsf@alice.fifthhorseman.net> Hi Werner-- it looks to me like this Danish translation, which was supposed to be against STABLE-BRANCH-1-4 was never applied: http://lists.gnupg.org/pipermail/gnupg-i18n/2014-November/000310.html It doesn't apply cleanly right now either, unfortunately, but i think there are at least a couple translations that should be useful (i don't speak Danish, though). Regards, --dkg From wk at gnupg.org Wed Mar 4 15:21:58 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Mar 2015 15:21:58 +0100 Subject: [PATCH] Point to the correct URLs for the FAQ In-Reply-To: <1424585545-16279-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sun, 22 Feb 2015 01:12:25 -0500") References: <1424585545-16279-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <878ufcalmh.fsf@vigenere.g10code.de> On Sun, 22 Feb 2015 07:12, dkg at fifthhorseman.net said: > * doc/FAQ: correct URLs, use https Done. > The old FAQ URLs (http://www.gnupg.org/faq/GnuPG-FAQ.html) return > versions from the end of 2012. We probably also want to replace those > with an HTTP redirect to the correct page. Thanks for noting. There is some cruft in the top directory which needs to be cleaned up. I replaced that with a symlink to the real FAQ. I will also repalce the old HTML with links to their new versions. The old FAQ has been renamed to GnuPG-FAQ.old.txt at ftp.gnupg.org/gcrypt/gnupg > I also note that the plaintext version of the FAQ is sent by the web > server with the following header: > > Content-Type: text/plain > > Note the lack of a charset parameter. The file itself appears to Oh yes. I think Boa has no support for this. I'll check whether I can fix that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Wed Mar 4 15:44:08 2015 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 4 Mar 2015 14:44:08 +0000 Subject: DETAILS file correction Message-ID: Werner, In a couple of places the DETAILS file of recent versions of the 1.4 and 2.1 series refers to 'sbb' records. I think it means 'ssb'. A search and replace should find it. This had me scratching my head for a little! N. From dkg at fifthhorseman.net Thu Mar 5 02:33:47 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 5 Mar 2015 02:33:47 +0100 Subject: [PATCH] common: Check option arguments for a valid range [STABLE-BRANCH-2-0] Message-ID: <1425519227-15932-1-git-send-email-dkg@fifthhorseman.net> From: Werner Koch * common/argparse.h (ARGPARSE_INVALID_ARG): New. * common/argparse.c: Include limits h and errno.h. (initialize): Add error strings for new error constant. (set_opt_arg): Add range checking. Signed-off-by: Werner Koch [ This is a backport of 0d73a242cb53522669cf712b5ece7d1ed05d003a from master to STABLE-BRANCH-2-0 ] Signed-off-by: Daniel Kahn Gillmor --- jnlib/argparse.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++-------- jnlib/argparse.h | 1 + 2 files changed, 47 insertions(+), 8 deletions(-) diff --git a/jnlib/argparse.c b/jnlib/argparse.c index 184b0f6..49f50ec 100644 --- a/jnlib/argparse.c +++ b/jnlib/argparse.c @@ -27,6 +27,9 @@ #include #include #include +#include +#include +#include #include "libjnlib-config.h" #include "mischelp.h" @@ -198,6 +201,8 @@ initialize( ARGPARSE_ARGS *arg, const char *filename, unsigned *lineno ) s = _("keyword too long"); else if ( arg->r_opt == ARGPARSE_MISSING_ARG ) s = _("missing argument"); + else if ( arg->r_opt == ARGPARSE_INVALID_ARG ) + s = _("invalid argument"); else if ( arg->r_opt == ARGPARSE_INVALID_COMMAND ) s = _("invalid command"); else if ( arg->r_opt == ARGPARSE_INVALID_ALIAS ) @@ -214,6 +219,8 @@ initialize( ARGPARSE_ARGS *arg, const char *filename, unsigned *lineno ) if ( arg->r_opt == ARGPARSE_MISSING_ARG ) jnlib_log_error (_("missing argument for option \"%.50s\"\n"), s); + else if ( arg->r_opt == ARGPARSE_INVALID_ARG ) + jnlib_log_error (_("invalid argument for option \"%.50s\"\n"), s); else if ( arg->r_opt == ARGPARSE_UNEXPECTED_ARG ) jnlib_log_error (_("option \"%.50s\" does not expect an " "argument\n"), s ); @@ -524,7 +531,7 @@ optfile_parse (FILE *fp, const char *filename, unsigned *lineno, p[strlen(p)-1] = 0; } if (!set_opt_arg (arg, opts[idx].flags, p)) - jnlib_free(buffer); + jnlib_free(buffer); } } break; @@ -966,23 +973,54 @@ arg_parse( ARGPARSE_ARGS *arg, ARGPARSE_OPTS *opts) } - +/* Returns: -1 on error, 0 for an integer type and 1 for a non integer + type argument. */ static int -set_opt_arg(ARGPARSE_ARGS *arg, unsigned flags, char *s) +set_opt_arg (ARGPARSE_ARGS *arg, unsigned flags, char *s) { int base = (flags & ARGPARSE_OPT_PREFIX)? 0 : 10; + long l; switch ( (arg->r_type = (flags & ARGPARSE_TYPE_MASK)) ) { - case ARGPARSE_TYPE_INT: - arg->r.ret_int = (int)strtol(s,NULL,base); - return 0; case ARGPARSE_TYPE_LONG: - arg->r.ret_long= strtol(s,NULL,base); + case ARGPARSE_TYPE_INT: + errno = 0; + l = strtol (s, NULL, base); + if ((l == LONG_MIN || l == LONG_MAX) && errno == ERANGE) + { + arg->r_opt = ARGPARSE_INVALID_ARG; + return -1; + } + if (arg->r_type == ARGPARSE_TYPE_LONG) + arg->r.ret_long = l; + else if ( (l < 0 && l < INT_MIN) || l > INT_MAX ) + { + arg->r_opt = ARGPARSE_INVALID_ARG; + return -1; + } + else + arg->r.ret_int = (int)l; return 0; + case ARGPARSE_TYPE_ULONG: - arg->r.ret_ulong= strtoul(s,NULL,base); + while (isascii (*s) && isspace(*s)) + s++; + if (*s == '-') + { + arg->r.ret_ulong = 0; + arg->r_opt = ARGPARSE_INVALID_ARG; + return -1; + } + errno = 0; + arg->r.ret_ulong = strtoul (s, NULL, base); + if (arg->r.ret_ulong == ULONG_MAX && errno == ERANGE) + { + arg->r_opt = ARGPARSE_INVALID_ARG; + return -1; + } return 0; + case ARGPARSE_TYPE_STRING: default: arg->r.ret_str = s; diff --git a/jnlib/argparse.h b/jnlib/argparse.h index dd9b30b..74f2040 100644 --- a/jnlib/argparse.h +++ b/jnlib/argparse.h @@ -177,6 +177,7 @@ typedef struct #define ARGPARSE_AMBIGUOUS_COMMAND (-9) #define ARGPARSE_INVALID_ALIAS (-10) #define ARGPARSE_OUT_OF_CORE (-11) +#define ARGPARSE_INVALID_ARG (-12) int arg_parse( ARGPARSE_ARGS *arg, ARGPARSE_OPTS *opts); -- 2.1.4 From nicholas.cole at gmail.com Thu Mar 5 10:36:22 2015 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 5 Mar 2015 09:36:22 +0000 Subject: Determining what curves are available Message-ID: Dear List, Since the ECC curves available depends upon an external library, it can be hard to work out exactly what gnupg 2.1 supports based on the version number. Could the supported curves be added to the --version output? N. From heirecka at exherbo.org Thu Mar 5 22:08:35 2015 From: heirecka at exherbo.org (Heiko Becker) Date: Thu, 05 Mar 2015 22:08:35 +0100 Subject: [PATCH] Add new lock-obj-pub for i686-pc-linux-gnu Message-ID: <54F8C5D3.30100@exherbo.org> Hello, I've created the file according the instructions in the README file and successfully built libgpg-error and ran its tests afterwards. -- Best regards, Heiko Becker -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-new-lock-obj-pub-for-i686-pc-linux-gnu.patch Type: text/x-patch Size: 1002 bytes Desc: not available URL: From wk at gnupg.org Fri Mar 6 10:40:20 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Mar 2015 10:40:20 +0100 Subject: [PATCH] Add new lock-obj-pub for i686-pc-linux-gnu In-Reply-To: <54F8C5D3.30100@exherbo.org> (Heiko Becker's message of "Thu, 05 Mar 2015 22:08:35 +0100") References: <54F8C5D3.30100@exherbo.org> Message-ID: <87y4na4g6z.fsf@vigenere.g10code.de> On Thu, 5 Mar 2015 22:08, heirecka at exherbo.org said: > I've created the file according the instructions in the README file and > successfully built libgpg-error and ran its tests afterwards. Thanks. However, I realized that config.sub should actually do that but it does not. For our purpose it is better to have additional aliasing table in mkheader to avoid having several syscfg files which only > --- a/src/syscfg/lock-obj-pub.i586-pc-linux-gnu.h > +++ b/src/syscfg/lock-obj-pub.i686-pc-linux-gnu.h > @@ -1,4 +1,4 @@ > -## lock-obj-pub.i586-pc-linux-gnu.h > +## lock-obj-pub.i686-pc-linux-gnu.h differ in a comment. Can you please try the latest commit? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Mar 6 10:41:12 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Mar 2015 10:41:12 +0100 Subject: Determining what curves are available In-Reply-To: (Nicholas Cole's message of "Thu, 5 Mar 2015 09:36:22 +0000") References: Message-ID: <87twxy4g5j.fsf@vigenere.g10code.de> On Thu, 5 Mar 2015 10:36, nicholas.cole at gmail.com said: > Since the ECC curves available depends upon an external library, it > can be hard to work out exactly what gnupg 2.1 supports based on the > version number. Could the supported curves be added to the --version > output? Can you please file your request with bugs.gnupg.org? Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Mar 6 10:57:41 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Mar 2015 10:57:41 +0100 Subject: DETAILS file correction In-Reply-To: (Nicholas Cole's message of "Wed, 4 Mar 2015 14:44:08 +0000") References: Message-ID: <87lhja4fe2.fsf@vigenere.g10code.de> On Wed, 4 Mar 2015 15:44, nicholas.cole at gmail.com said: > In a couple of places the DETAILS file of recent versions of the 1.4 > and 2.1 series refers to 'sbb' records. I think it means 'ssb'. A Changed in master all to ssb (aka J3E modulation). Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Fri Mar 6 15:41:59 2015 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 6 Mar 2015 14:41:59 +0000 Subject: Determining what curves are available In-Reply-To: <87twxy4g5j.fsf@vigenere.g10code.de> References: <87twxy4g5j.fsf@vigenere.g10code.de> Message-ID: On Fri, Mar 6, 2015 at 9:41 AM, Werner Koch wrote: > On Thu, 5 Mar 2015 10:36, nicholas.cole at gmail.com said: > >> Since the ECC curves available depends upon an external library, it >> can be hard to work out exactly what gnupg 2.1 supports based on the >> version number. Could the supported curves be added to the --version >> output? > > Can you please file your request with bugs.gnupg.org? Thanks. Done. From gniibe at fsij.org Sat Mar 7 10:11:58 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 07 Mar 2015 18:11:58 +0900 Subject: scd: fix for 64-bit arch Message-ID: <54FAC0DE.3090805@fsij.org> Hello, I was careless about 64-bit architecture when I added EdDSA support for scdaemon. Here's an obvious fix. I don't push this change today, and postpone until tomorrow. Because I am sleepy now and not that confident. I'll review it again, and push. diff --git a/agent/pksign.c b/agent/pksign.c index d737bad..1d3d3d8 100644 --- a/agent/pksign.c +++ b/agent/pksign.c @@ -363,12 +363,13 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, *buf = 0; } - rc = gcry_sexp_build (&s_sig, NULL, "(sig-val(rsa(s%b)))", len, buf); + rc = gcry_sexp_build (&s_sig, NULL, "(sig-val(rsa(s%b)))", + (int)len, buf); } else if (is_EdDSA) { rc = gcry_sexp_build (&s_sig, NULL, "(sig-val(eddsa(r%b)(s%b)))", - len/2, buf, len/2, buf + len/2); + (int)len/2, buf, (int)len/2, buf + len/2); } else if (is_ECDSA) { diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 6583fb2..10bd64e 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -1496,7 +1496,7 @@ get_public_key (app_t app, int keyno) if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA) { err = gcry_sexp_build (&s_pkey, NULL, "(public-key(rsa(n%b)(e%b)))", - mlen, mbuf, elen, ebuf); + (int)mlen, mbuf, (int)elen, ebuf); if (err) goto leave; @@ -1518,7 +1518,7 @@ get_public_key (app_t app, int keyno) err = gcry_sexp_build (&s_pkey, NULL, "(public-key(ecc(curve%s)(q%b)))", - curve_name, mlen, mbuf); + curve_name, (int)mlen, mbuf); if (err) goto leave; @@ -1541,7 +1541,7 @@ get_public_key (app_t app, int keyno) err = gcry_sexp_build (&s_pkey, NULL, "(public-key(ecc(curve%s)(flags eddsa)(q%b)))", - curve_name, mlen, mbuf); + curve_name, (int)mlen, mbuf); if (err) goto leave; -- From wk at gnupg.org Sun Mar 8 19:56:56 2015 From: wk at gnupg.org (Werner Koch) Date: Sun, 08 Mar 2015 19:56:56 +0100 Subject: scd: fix for 64-bit arch In-Reply-To: <54FAC0DE.3090805@fsij.org> (NIIBE Yutaka's message of "Sat, 07 Mar 2015 18:11:58 +0900") References: <54FAC0DE.3090805@fsij.org> Message-ID: <87y4n71fnr.fsf@vigenere.g10code.de> On Sat, 7 Mar 2015 10:11, gniibe at fsij.org said: > I don't push this change today, and postpone until tomorrow. Because > I am sleepy now and not that confident. I'll review it again, and The fix looks right. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From yuri at rawbw.com Mon Mar 9 04:43:20 2015 From: yuri at rawbw.com (Yuri) Date: Sun, 08 Mar 2015 20:43:20 -0700 Subject: pinentry fails for no apparent reason (ERR canceled) Message-ID: <54FD16D8.2010605@rawbw.com> I have pinentry failing in case it is invoked from gpg4usb, and succeeding when called from gpg itself. The succeeding case is when I paste an encrypted text into console with running gpg. Successful case has these options set, failing doesn't have them: OPTION ttyname=/dev/pts/16 OPTION lc-ctype=en_US.UTF-8 OPTION lc-messages=en_US.UTF-8 Failure message: ERR 83886179 canceled Why would pinentry fail like this? pinentry-0.9.0 gnupg-2.1.2 All from ports on FreeBSD 10.1 Yuri --- log: successful input (called from gpg) --- OPTION grab OPTION ttyname=/dev/pts/16 OPTION ttytype=xterm OPTION lc-ctype=en_US.UTF-8 OPTION lc-messages=en_US.UTF-8 OPTION default-ok=_OK OPTION default-cancel=_Cancel OPTION default-prompt=PIN: OPTION touch-file=/home/yuri/.gnupg/S.gpg-agent GETINFO pid SETDESC Please enter the passphrase to unlock the OpenPGP secret key:%0A%22MyKey1 (Main Key) %22%0A4096-bit RSA key, ID 97C87935,%0Acreated 2015-03-08 (main key ID D4C77447).%0A SETPROMPT Passphrase: GETPIN BYE --- log: successful output (called from gpg) --- OK Your orders please OK OK OK OK OK OK OK OK OK D 29030 OK OK OK D ActualPasswordHere OK OK closing connection --- log: failing input (called from gpg4usb) --- OPTION grab OPTION ttytype=xterm OPTION default-ok=_OK OPTION default-cancel=_Cancel OPTION default-prompt=PIN: OPTION touch-file=/home/yuri/.gnupg/S.gpg-agent GETINFO pid SETDESC Please enter the passphrase to unlock the OpenPGP secret key:%0A%22MyKey1 (Main Key) %22%0A4096-bit RSA key, ID 97C87935,%0Acreated 2015-03-08 (main key ID D4C77447).%0A SETPROMPT Passphrase: GETPIN BYE --- log: failing output (called from gpg4usb) --- OK Your orders please OK OK OK OK OK OK D 29082 OK OK OK ERR 83886179 canceled OK closing connection From wk at gnupg.org Tue Mar 10 10:42:20 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Mar 2015 10:42:20 +0100 Subject: Mass filing of clang warnings Message-ID: <87siddtchv.fsf@vigenere.g10code.de> Hi! While looking at the bug tracker, I figured that a few days ago one guy filed dozens of bugs which in most cases are warnings issued by Clang. I closed most of them and tagged them as mistaken because pasting just warnings along with comments like "makes me nervous" do not make good bug reports. It took me more than 2 hours to close them and briefly check some of them. I might have missed some real things due to that torrent of reports, though. An example of faulty warnings is https://bugs.g10code.com/gnupg/issue1912 where one of the warnings is iobuf.c:1325:3: warning: String copy function overflows destination buffer strcpy (fcx->fname, fname); ^~~~~~~~~~~~~~~~~~~~~~~~~~ Looking at the code in question: --8<---------------cut here---------------start------------->8--- fcx = xmalloc (sizeof *fcx + strlen (fname)); fcx->fp = fp; fcx->print_only_name = print_only; strcpy (fcx->fname, fname); --8<---------------cut here---------------end--------------->8--- the last line is 1325. It is pretty easy to see that FCX->FNAME has been allocated 3 lines earlier using a standard C pattern to use a dynamically sized struct (for FCX): --8<---------------cut here---------------start------------->8--- typedef struct { gnupg_fd_t fp; /* Open file pointer or handle. */ int keep_open; int no_cache; int eof_seen; int print_only_name; /* Flags indicating that fname [...] */ char fname[1]; /* Name of the file. */ } file_filter_ctx_t; --8<---------------cut here---------------end--------------->8--- The xmalloc (which is a common name for a malloc wrapper) allocates the size of the struct including the one byte for fname (from the definition) and adds the strlen of the SOURCE string to the allocation size. Thus the total allocation for FCX->FNAME is (1 + strlen(SOURCE)) and a final strcpy works as expected without any overflow. Now, how useful is an analyzer which does not grok one of the oldest C coding pattern? Frankly, I have not seen that before and thus I assume that this and other warnings are due to a regression in that version of Clang or due to wrong use. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Mar 11 14:52:54 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Mar 2015 14:52:54 +0100 Subject: Determining what curves are available In-Reply-To: (Nicholas Cole's message of "Fri, 6 Mar 2015 14:41:59 +0000") References: <87twxy4g5j.fsf@vigenere.g10code.de> Message-ID: <87mw3jmyix.fsf@vigenere.g10code.de> On Fri, 6 Mar 2015 15:41, nicholas.cole at gmail.com said: >> Can you please file your request with bugs.gnupg.org? Thanks. > > Done. Done: --8<---------------cut here---------------start------------->8--- $ gpg --with-colons --list-config curve curveoid 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! cfg:curve:ed25519;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1 cfg:curveoid:1.3.6.1.4.1.11591.15.1;1.2.840.10045.3.1.7;1.3.132.0.34;1.3.132.0.35;1.3.36.3.3.2.8.1.1.7;1.3.36.3.3.2.8.1.1.11;1.3.36.3.3.2.8.1.1.13;1.3.132.0.10 --8<---------------cut here---------------end--------------->8--- Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Mar 11 14:51:42 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Mar 2015 14:51:42 +0100 Subject: PKA updates In-Reply-To: <87sidqr84c.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 27 Feb 2015 23:08:03 -0500") References: <874mqaugf9.fsf@vigenere.g10code.de> <87385tspau.fsf@alice.fifthhorseman.net> <87lhjlt6k0.fsf@vigenere.g10code.de> <87sidqr84c.fsf@alice.fifthhorseman.net> Message-ID: <87r3svmykx.fsf@vigenere.g10code.de> On Sat, 28 Feb 2015 05:08, dkg at fifthhorseman.net said: > I'm not sure that a new record type is much of a problem. Most DNS It needs to be standardized and I do not see a reason for this given that we already have CERT record with all kind of options. And GnuPG has support for CERT records for for ages. >> [ - Why using SHA224 for hashing if this is just for maiing the >> local-part. ] > > i'm not sure what the issue is here. can you explain further? My Why the longer SHA224 if SHA1 is sufficient? I guess that is due to a false interpretation of the IETF rule that SHA-1 shall not be used in new crypto protocols - this is not an issue here. >> That was my original idea behind PKA. I don't think that is anymore >> justified. However, if you trust DNSSEC gpg can already be tweaked to >> that that in account by using "--verify-options pka-trust-increase" etc. > > Can you explain more why you no longer think that using dnssec as a > corroborative channel is justified? I'm personally wary of the It is of course up to you and if we can work a metric on how to use it for key validation - along with other methods - that is fine. I myself don't think anymore that DNSSEC is a suitable tool against mass surveillance. > Well, sending mail in the clear over a STARTTLS submission channel only > leaks the To: information to the user's sending MTA, while the DNS query > leaks the same information to every machine along the network path to > the DNS server. That is the meta data problem which we can't solve with the currently deployed networks and standard protocols. I don't care about this for now. First we need to increase the use of encryption and in a second step, while the TLAs are working on the deployment of new attacks, we switch to an overlay network. Increasing the surveillance costs for the TLAs is what we can do now. The costs of mass surveillance is an easier to understand and usable argument on the political level than any technical or human rights argument. > But i think you're right that this is something that can be mitigated > with sensible MUA operation, caching results, etc. Or switch from DNS to something else. But DNS is easy right now and gives us time to work out and deploy other solutions. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Wed Mar 11 15:21:35 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 11 Mar 2015 10:21:35 -0400 Subject: Mass filing of clang warnings In-Reply-To: <87siddtchv.fsf@vigenere.g10code.de> References: <87siddtchv.fsf@vigenere.g10code.de> Message-ID: <55004F6F.6090206@guardianproject.info> Hey Werner, While I do not thing that mass filing of bugs without warning is a good idea, I do think you should reconsider the usefulness of static code analyzers like clang's warnings and cppcheck. It is true that they are not as intelligent as people, and don't always understand every valid variant of C code. But what they do far better than people is tirelessly run again and again, checking the entire code base on every commit. cppcheck did catch real issues that you fixed. I ran it and reported it here, and you confirmed some of them and fixed them. Also, anyone can use these tools automatically on the any public code base. So they can instead use them to tirelessly search for exploits in GnuPG. To use these tools effectively, that means that the devs have to write code that the static analyzers understand. This usually also means that the code is easier for humans to understand, that is also a big benefit. It does mean doing some annoying work sometimes, and fixing little annoyances here and there, but I think using static analyzers pays off in a big way overall. .hc Werner Koch: > Hi! > > While looking at the bug tracker, I figured that a few days ago one guy > filed dozens of bugs which in most cases are warnings issued by Clang. I > closed most of them and tagged them as mistaken because pasting just > warnings along with comments like "makes me nervous" do not make good bug > reports. It took me more than 2 hours to close them and briefly check > some of them. I might have missed some real things due to that torrent > of reports, though. > > An example of faulty warnings is > > https://bugs.g10code.com/gnupg/issue1912 > > where one of the warnings is > > iobuf.c:1325:3: warning: String copy function overflows destination buffer > strcpy (fcx->fname, fname); > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > > Looking at the code in question: > > --8<---------------cut here---------------start------------->8--- > fcx = xmalloc (sizeof *fcx + strlen (fname)); > fcx->fp = fp; > fcx->print_only_name = print_only; > strcpy (fcx->fname, fname); > --8<---------------cut here---------------end--------------->8--- > > the last line is 1325. It is pretty easy to see that FCX->FNAME has > been allocated 3 lines earlier using a standard C pattern to use a > dynamically sized struct (for FCX): > > --8<---------------cut here---------------start------------->8--- > typedef struct > { > gnupg_fd_t fp; /* Open file pointer or handle. */ > int keep_open; > int no_cache; > int eof_seen; > int print_only_name; /* Flags indicating that fname [...] */ > char fname[1]; /* Name of the file. */ > } file_filter_ctx_t; > --8<---------------cut here---------------end--------------->8--- > > The xmalloc (which is a common name for a malloc wrapper) allocates the > size of the struct including the one byte for fname (from the > definition) and adds the strlen of the SOURCE string to the allocation > size. Thus the total allocation for FCX->FNAME is > > (1 + strlen(SOURCE)) > > and a final strcpy works as expected without any overflow. > > Now, how useful is an analyzer which does not grok one of the oldest C > coding pattern? Frankly, I have not seen that before and thus I assume > that this and other warnings are due to a regression in that version of > Clang or due to wrong use. > > > Salam-Shalom, > > Werner > > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 From rjh at sixdemonbag.org Wed Mar 11 15:29:16 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Mar 2015 10:29:16 -0400 Subject: Mass filing of clang warnings In-Reply-To: <55004F6F.6090206@guardianproject.info> References: <87siddtchv.fsf@vigenere.g10code.de> <55004F6F.6090206@guardianproject.info> Message-ID: <5500513C.8090804@sixdemonbag.org> I rarely agree with HC, but I think he's completely right here. Static analysis is a wonderful tool for producing better code. This is why I prefer to develop C code with a C++ compiler, just for the C++ compiler's stronger static analysis. (Yes, yes, I switch to a C compiler for release builds. But for development, the more fastidious C++ compiler is a great boon.) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From wk at gnupg.org Wed Mar 11 16:45:52 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Mar 2015 16:45:52 +0100 Subject: gpg 2.1: no error message if gpg-agent or pinentry fail In-Reply-To: <54DA437F.2020509@enigmail.net> (Patrick Brunschwig's message of "Tue, 10 Feb 2015 18:44:31 +0100") References: <54DA437F.2020509@enigmail.net> Message-ID: <87bnjzmtan.fsf@vigenere.g10code.de> On Tue, 10 Feb 2015 18:44, patrick at enigmail.net said: > If pinentry can't be launched, then gpg 2.0 will report an error saying > something like "problem with gpg-agent". But if you try to decrypt a > message with gpg 2.1 and pinentry doesn't work, then there is absolutely > no error message. You simply see "missing key xyz" messages. Well I see an error message here. To trigger such an error I use this script as pinentry: --8<---------------cut here---------------start------------->8--- #!/bin/sh echo "OK - what's up?" while read cmd rest; do echo "cmd=$cmd rest=$rest" >&2 case "$cmd" in \#*) ;; GETPIN) echo "D ${PINENTRY_USER_DATA}" echo "ERR 42" ;; BYE) echo "OK" exit 0 ;; *) echo "OK" ;; esac done --8<---------------cut here---------------end--------------->8--- Trying to decrypt something gives these messages: [...] gpg: public key decryption failed: Tribute to D. A. [GNUPG:] ERROR pkdecrypt_failed 67108906 [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_FAILED gpg: decryption failed: No secret key [GNUPG:] END_DECRYPTION Right you can't see the source of the error. Thus we need to look at the ERROR status line: $ gpg-error 67108906 67108906 = (4, 42) = (GPG_ERR_SOURCE_GPGAGENT, GPG_ERR_TRIBUTE_TO_D_A) = (GPG Agent, Tribute to D. A.) Okay, so the source is gpg-agent. This is not correct because Pinentry should have set an error source which it did not. There are also some other errors which technically correctly assign gpg-agent as source of the error but the actual cause for the error is a problem with Pinentry and thus it should say so. To trigger such an error use "FOO 42" instead if "ERR 42" in the pinentry script. I now fixed the gpg-agent to assign Pinentry as error source for all unexpected errors. With that change the decryption shows this: gpg: public key decryption failed: Tribute to D. A. [GNUPG:] ERROR pkdecrypt_failed 83886122 [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_FAILED gpg: decryption failed: No secret key [GNUPG:] END_DECRYPTION The dame as above but the error code changed: $ gpg-error 83886122 83886122 = (5, 42) = (GPG_ERR_SOURCE_PINENTRY, GPG_ERR_TRIBUTE_TO_D_A) = (Pinentry, Tribute to D. A.) Thus a script may now detect that this is a problem with pinentry. It would of course be possible to print the error source in the human readable messages but I hesitate to do this due to the required string changes. It might be possible to print a separate help message if such a condition is detected. There may be other error sources and thus I think it is better to help the user by better describing how to debug the IPC between gpg-agent and gpg. With that the cause for the problem can be easily seen. All error codes from calling pinentry are now also written to the gpg-agent log with "--debug 1024". Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Mar 11 17:43:12 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Mar 2015 17:43:12 +0100 Subject: Mass filing of clang warnings In-Reply-To: <5500513C.8090804@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 11 Mar 2015 10:29:16 -0400") References: <87siddtchv.fsf@vigenere.g10code.de> <55004F6F.6090206@guardianproject.info> <5500513C.8090804@sixdemonbag.org> Message-ID: <87sidblc2n.fsf@vigenere.g10code.de> On Wed, 11 Mar 2015 15:29, rjh at sixdemonbag.org said: > I rarely agree with HC, but I think he's completely right here. Static > analysis is a wonderful tool for producing better code. This is why I I like to see these reports too but the point here was a mass filing of more or less indentical warnings and way too many false positives. See my example. Throwing compiler output at a developer is not helpful without some basic analyzing of the problem. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Mar 11 17:50:31 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Mar 2015 17:50:31 +0100 Subject: Mass filing of clang warnings In-Reply-To: <55004F6F.6090206@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 11 Mar 2015 10:21:35 -0400") References: <87siddtchv.fsf@vigenere.g10code.de> <55004F6F.6090206@guardianproject.info> Message-ID: <87oanzlbqg.fsf@vigenere.g10code.de> On Wed, 11 Mar 2015 15:21, hans at guardianproject.info said: > people is tirelessly run again and again, checking the entire code base on > every commit. cppcheck did catch real issues that you fixed. I ran it and > reported it here, and you confirmed some of them and fixed them. Also, anyone Right. That were high quality reports with the obvious false positives sorted out. Please look, at the bug reports at hand to see the problem: 1864--1916. Agree, simply closing most of them is not the fine way but I somehow need to handle such a DoS. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Wed Mar 11 19:12:13 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 11 Mar 2015 14:12:13 -0400 Subject: Mass filing of clang warnings In-Reply-To: <87oanzlbqg.fsf@vigenere.g10code.de> References: <87siddtchv.fsf@vigenere.g10code.de> <55004F6F.6090206@guardianproject.info> <87oanzlbqg.fsf@vigenere.g10code.de> Message-ID: <5500857D.5060803@guardianproject.info> Werner Koch: > On Wed, 11 Mar 2015 15:21, hans at guardianproject.info said: > >> people is tirelessly run again and again, checking the entire code base on >> every commit. cppcheck did catch real issues that you fixed. I ran it and >> reported it here, and you confirmed some of them and fixed them. Also, anyone > > Right. That were high quality reports with the obvious false positives > sorted out. Please look, at the bug reports at hand to see the problem: > 1864--1916. > > Agree, simply closing most of them is not the fine way but I somehow > need to handle such a DoS. I completely agree that mass filing bugs is not the way. I'm responding to your bits about the clang warnings pointing to valid C code. You had a similar response to a number of the cppcheck warnings. I propose that GnuPG instead adjust bits of code like that to make cppcheck/clang happy, even though those bits of code are correct according to a human. Then we can setup an automated cppcheck/clang test to catch any new errors. In my experience with cppcheck, it will better understand the code if that code does not include bits that cppcheck is confused by. I have changed little things in response to cppcheck warnings, and that then made cppcheck find real issues. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 From hanno at hboeck.de Thu Mar 12 10:33:52 2015 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Thu, 12 Mar 2015 10:33:52 +0100 Subject: how does pka relate to openpgpkey Message-ID: <20150312103352.2e8bd8c5@pc1.fritz.box> Hi, I'm somewhat confused about this. Werner recently postet some things about PKA records. Now there seems to be work done to create a new standard OPENPGPKEY that is, as far as I can see, basically doing the same, just different: Distributing PGP keys through DNS: https://openpgpkey.info/ How do these relate to each other? Is openpgpkey supposed to replace pka? (I still think this is all misguided from the start because it relies on dnssec being a real thing, but if this is the way people want to go it probably is the worst idea to deploy two standards basically doing something very similar at the same time) cu, -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Mar 12 11:25:55 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Mar 2015 11:25:55 +0100 Subject: Mass filing of clang warnings In-Reply-To: <5500857D.5060803@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 11 Mar 2015 14:12:13 -0400") References: <87siddtchv.fsf@vigenere.g10code.de> <55004F6F.6090206@guardianproject.info> <87oanzlbqg.fsf@vigenere.g10code.de> <5500857D.5060803@guardianproject.info> Message-ID: <87fv9ajyvg.fsf@vigenere.g10code.de> On Wed, 11 Mar 2015 19:12, hans at guardianproject.info said: > In my experience with cppcheck, it will better understand the code if that > code does not include bits that cppcheck is confused by. I have changed little > things in response to cppcheck warnings, and that then made cppcheck find real I showed a real standard coding pattern. If cppcheck is not able to detect this very basic technique it produces too many false positives. Clobbering the code with annotations for such a thing is not going to work. Another example (bug 1908): t-ed25519.c:182:10: warning: Dereference of null pointer (loaded from variable 'p') *p = 0; ~ ^ Now look at the code: if (!p) die ("input line %d not terminated or too long\n", *lineno); *p = 0; Now can that happen? Analyzing the static function die() would have shown that it will never return. Okay, it would have been possible to use __attribute__ ((__noreturn__)) which I often use for non-test programs but a simple analysis of die should have come to the same result. Or look at bug 1906 - I can only conclude that the used version of ccc-analyzer is broken. I have seen way better reports from Clang. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Mar 12 12:05:10 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Mar 2015 12:05:10 +0100 Subject: how does pka relate to openpgpkey In-Reply-To: <20150312103352.2e8bd8c5@pc1.fritz.box> ("Hanno =?utf-8?Q?B?= =?utf-8?Q?=C3=B6ck=22's?= message of "Thu, 12 Mar 2015 10:33:52 +0100") References: <20150312103352.2e8bd8c5@pc1.fritz.box> Message-ID: <878uf2jx21.fsf@vigenere.g10code.de> On Thu, 12 Mar 2015 10:33, hanno at hboeck.de said: > How do these relate to each other? Is openpgpkey supposed to replace > pka? I don't understand either. In particular I wonder why PKA was not mentioned given that gpg support it since 10 years. I asked Paul Wouters why he came up with a new record type instead of use the CERT record (which was updated to support PGP after I did the PKA thing using TXT records). He claims that the CERT record is too complex, not supported by all DNS libraries, and nobody is using it. Further the DNS WG does not anymore like subtypes (eg. PGP, IPGP, PKIX, IPKIX for CERT) because you can't request a certain subtype and an application has to pick one from the responses. I can't agree to that because we have full support for CERT record in gpg on Unix and on Windows. Implementing it was not that hard. The real problem with all DNS methods is that most people can't add a record to the DNS. This is why keyservers lower the entry barrier. I do not plan to cease support for PKA. In fact I redefined PKA to only take care of the first time association of a key with a mail address and not to deliver the actual key. Keyservers or other methods (CERT allows to add a canonical URL to the PKA record) are much easier to use than a service from your provider to upload an updated key. And access to the key via fingerprint is anyway required for signature verification - DANE can't do that. Consider the case that you lost access to you mail provider: You would need to rely on your former provider to distribute a revocation certificate and that the provider won't reuse your mail address. Using the IPGP CERT subtype allows to get a key for a first time encrypted communication - after that you do not need it anymore. This would be used to seed a TOFU trust model - implementing that is on the GnuPG shortlist. For the DANE system the new _openpgpg.DOMAIN stuff makes sense. However, not re-using an existing standard (CERT records, RFC-4398) and adding yet another thing for the same purpose is not a good idea. It would have been sufficient to define the local-part hashing and the _openpgp prefix. The kdns keyserver helper would then immediately be usable by all gpg versions. I do not understand why there has been no recent discussion at the OpenPGP WG mailing list. There was a brief discussion in Summer 2013 and short message from Paul in January 2014. After that the discussion seem to have moved to the DANE group with no traces at the OpenPGP WG. After all it is about OpenPGP and thus that would have been the right place for it. Well, the OpenPGP WG has been concluded because after RFC-4880 the IETF lost all interest in OpenPGP and settled for S/MIME. Anyway, it is still the place were OpenPGP people come together. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marcozehe-ml at mailbox.org Thu Mar 12 12:42:35 2015 From: marcozehe-ml at mailbox.org (Marco Zehe) Date: Thu, 12 Mar 2015 12:42:35 +0100 Subject: how does pka relate to openpgpkey In-Reply-To: <878uf2jx21.fsf@vigenere.g10code.de> References: <20150312103352.2e8bd8c5@pc1.fritz.box> <878uf2jx21.fsf@vigenere.g10code.de> Message-ID: <7F3A6025-C638-4741-B019-0D368274186D@mailbox.org> Well, it looks like some providers start picking up on this new standard already, as this (German) news article on Heise from March 10 shows: http://www.heise.de/netze/meldung/Mail-Verschluesselung-Mail-de-bringt-automatisierte-PGP-Schluesselverwaltung-2571867.html Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hans at guardianproject.info Fri Mar 13 15:48:09 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 13 Mar 2015 10:48:09 -0400 Subject: Mass filing of clang warnings In-Reply-To: <87fv9ajyvg.fsf@vigenere.g10code.de> References: <87siddtchv.fsf@vigenere.g10code.de> <55004F6F.6090206@guardianproject.info> <87oanzlbqg.fsf@vigenere.g10code.de> <5500857D.5060803@guardianproject.info> <87fv9ajyvg.fsf@vigenere.g10code.de> Message-ID: <5502F8A9.5010709@guardianproject.info> Werner Koch: > On Wed, 11 Mar 2015 19:12, hans at guardianproject.info said: > >> In my experience with cppcheck, it will better understand the code if that >> code does not include bits that cppcheck is confused by. I have changed little >> things in response to cppcheck warnings, and that then made cppcheck find real > > I showed a real standard coding pattern. If cppcheck is not able to > detect this very basic technique it produces too many false positives. > Clobbering the code with annotations for such a thing is not going to > work. I'm more interested in cppcheck, I don't know much about clang so I'm not going to comment on its results. If you look back at my original post about cppcheck, it seems to me that you were unwilling to accept trivial changes to placate cppcheck: http://lists.gnupg.org/pipermail/gnupg-devel/2014-April/028417.html That's the kind of stuff that I'm talking about. The key point I'm talking about is not about whether the code that triggers the warning is correct or not. It is about making it correct AND simple enough for cppcheck to understand. That last point is what I'm discussing. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 From wk at gnupg.org Fri Mar 13 21:32:35 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Mar 2015 21:32:35 +0100 Subject: Mass filing of clang warnings In-Reply-To: <5502F8A9.5010709@guardianproject.info> (Hans-Christoph Steiner's message of "Fri, 13 Mar 2015 10:48:09 -0400") References: <87siddtchv.fsf@vigenere.g10code.de> <55004F6F.6090206@guardianproject.info> <87oanzlbqg.fsf@vigenere.g10code.de> <5500857D.5060803@guardianproject.info> <87fv9ajyvg.fsf@vigenere.g10code.de> <5502F8A9.5010709@guardianproject.info> Message-ID: <87ioe4d4f0.fsf@vigenere.g10code.de> On Fri, 13 Mar 2015 15:48, hans at guardianproject.info said: > That's the kind of stuff that I'm talking about. The key point I'm talking > about is not about whether the code that triggers the warning is correct or > not. It is about making it correct AND simple enough for cppcheck to > understand. That last point is what I'm discussing. I know. However it depends on the case. A change like - char buffer[BUFFER_SIZE]; + char buffer[BUFFER_SIZE] = ""; // make cppcheck happy this wrong. BUFFER is not expected to be initialized. A flow analysis may later come and warn about a useless initialization of BUFFER. Agreed, I do that sometimes for scalars or pointers which are for example controlled by a flag variable. I really hate to do that but I need to shut up gcc in some cases. The problem behind such dummy initialization is that improved compilers won't be able to detect a really non-initialized variable or complain about initialized but not used variable. It is always a tradeoff. Also recall that there are more compilers than gcc and Clang. Some even provided better warnings many years ago. If there would only be an annotation format which keeps the actual source readable (ie. in a separate automagically maintained file). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hanno at hboeck.de Sun Mar 15 11:16:29 2015 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Sun, 15 Mar 2015 11:16:29 +0100 Subject: how does pka relate to openpgpkey In-Reply-To: <7F3A6025-C638-4741-B019-0D368274186D@mailbox.org> References: <20150312103352.2e8bd8c5@pc1.fritz.box> <878uf2jx21.fsf@vigenere.g10code.de> <7F3A6025-C638-4741-B019-0D368274186D@mailbox.org> Message-ID: <20150315111629.3defb553@pc1.fritz.box> On Thu, 12 Mar 2015 12:42:35 +0100 Marco Zehe wrote: > Well, it looks like some providers start picking up on this new > standard already, as this (German) news article on Heise from March > 10 shows: > http://www.heise.de/netze/meldung/Mail-Verschluesselung-Mail-de-bringt-automatisierte-PGP-Schluesselverwaltung-2571867.html Just to add to that: This news was the reason I was asking, because I've been asked to write an article as well about the mail.de news. It's now online: http://www.golem.de/news/openpgpkey-domain-name-system-speichert-pgp-schluessel-1503-112927.html -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Mar 16 18:39:56 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Mar 2015 13:39:56 -0400 Subject: [LIBGPG-ERROR PATCH] Update Czech translation Message-ID: <1426527596-6851-1-git-send-email-dkg@fifthhorseman.net> From: Petr P?sa? Forwarded: http://lists.gnupg.org/pipermail/gnupg-i18n/2014-November/000348.html --- po/cs.po | 126 +++++++++++++++++++++------------------------------------------ 1 file changed, 41 insertions(+), 85 deletions(-) diff --git a/po/cs.po b/po/cs.po index 4a62316..dc78d6a 100644 --- a/po/cs.po +++ b/po/cs.po @@ -1,7 +1,7 @@ # Czech translation of libgpg-error. # Copyright (C) 2009 Free Software Foundation, Inc. # This file is distributed under the same license as the libgpg-error package. -# Petr Pisar , 2009, 2012. +# Petr Pisar , 2009, 2012, 2014. # # certificate chain ? ?et?zec (posloupnost) certifik?t? # keybox ? schr?nka (na kl??e) @@ -12,9 +12,9 @@ # msgid "" msgstr "" -"Project-Id-Version: libgpg-error 1.10\n" +"Project-Id-Version: libgpg-error 1.18\n" "Report-Msgid-Bugs-To: translations at gnupg.org\n" -"PO-Revision-Date: 2013-02-23 20:08+0100\n" +"PO-Revision-Date: 2014-11-27 19:31+0100\n" "Last-Translator: Petr Pisar \n" "Language-Team: Czech \n" "Language: cs\n" @@ -72,7 +72,7 @@ msgid "Assuan" msgstr "Assuan" msgid "TLS" -msgstr "" +msgstr "TLS" msgid "Any source" msgstr "Nespecifikovan? zdroj" @@ -327,10 +327,8 @@ msgstr "Neplatn? odpov??" msgid "No agent running" msgstr "Agent neb???" -#, fuzzy -#| msgid "agent error" msgid "Agent error" -msgstr "chyba agenta" +msgstr "Chyba agenta" msgid "Invalid data" msgstr "Neplatn? data" @@ -663,48 +661,32 @@ msgstr "Neplatn? eliptick? k?ivka" msgid "Unknown elliptic curve" msgstr "Nezn?m? eliptick? k?ivka" -#, fuzzy -#| msgid "Duplicated value" msgid "Duplicated key" -msgstr "Zdvojen? hodnota" +msgstr "Zdvojen? kl??" -#, fuzzy -#| msgid "Ambiguous name" msgid "Ambiguous result" -msgstr "Nejednozna?n? jm?no" +msgstr "Nejednozna?n? v?sledek" -#, fuzzy -#| msgid "No crypto engine" msgid "No crypto context" -msgstr "Chyb? kryptografick? jednotka" +msgstr "Chyb? kryptografick? kontext" -#, fuzzy -#| msgid "No crypto engine" msgid "Wrong crypto context" -msgstr "Chyb? kryptografick? jednotka" +msgstr "Chybn? kryptografick? kontext" -#, fuzzy -#| msgid "Invalid crypto engine" msgid "Bad crypto context" -msgstr "Neplatn? kryptografick? jednotka" +msgstr "?patn? kryptografick? kontext" msgid "Conflict in the crypto context" -msgstr "" +msgstr "Rozpor v?kryptografick?m kontextu" -#, fuzzy -#| msgid "No public key" msgid "Broken public key" -msgstr "??dn? ve?ejn? kl??" +msgstr "Rozbit? ve?ejn? kl??" -#, fuzzy -#| msgid "No secret key" msgid "Broken secret key" -msgstr "??dn? tajn? kl??" +msgstr "Rozbit? tajn? kl??" -#, fuzzy -#| msgid "Invalid digest algorithm" msgid "Invalid MAC algorithm" -msgstr "Neplatn? hashovac? algoritmus" +msgstr "Neplatn? algoritmus MAC" msgid "Operation fully cancelled" msgstr "Operace zcela zru?ena" @@ -770,116 +752,90 @@ msgstr "P??li? dlouh? ??dek" msgid "Object is in termination state" msgstr "" -#, fuzzy -#| msgid "Bad certificate chain" msgid "No certificate chain" -msgstr "Chybn? ?et?zec certifik?t?" +msgstr "Chyb? ?et?zec certifik?t?" -#, fuzzy -#| msgid "Certificate too young" msgid "Certificate is too large" -msgstr "Certifik?t je p??li? mlad?" +msgstr "Certifik?t je p??li? velk?" -#, fuzzy -#| msgid "Invalid card" msgid "Invalid record" -msgstr "Neplatn? karta" +msgstr "Neplatn? z?znam" msgid "The MAC does not verify" -msgstr "" +msgstr "Ov??en? MAC selhalo" -#, fuzzy -#| msgid "Unexpected tag" msgid "Unexpected message" -msgstr "Neo?ek?van? zna?ka" +msgstr "Neo?ek?van? zpr?va" msgid "Compression or decompression failed" -msgstr "" +msgstr "Komprese nebo dekomprese selhala" msgid "A counter would wrap" -msgstr "" +msgstr "Po??tadlo by p?eteklo" msgid "Fatal alert message received" -msgstr "" +msgstr "P?ijata nep?ekonateln? chybov? zpr?va" -#, fuzzy -#| msgid "Invalid cipher algorithm" msgid "No cipher algorithm" -msgstr "Neplatn? ?ifrovac? algoritmus" +msgstr "??dn? ?ifrovac? algoritmus" -#, fuzzy -#| msgid "Missing issuer certificate" msgid "Missing client certificate" -msgstr "Chyb? certifik?t vydavatele" +msgstr "Chyb? certifik?t klienta" -#, fuzzy -#| msgid "Certificate revoked" msgid "Close notification received" -msgstr "Certifik?t odvol?n" +msgstr "P?ijato ozn?men? o?uzav?en?" -#, fuzzy -#| msgid "Key expired" msgid "Ticket expired" -msgstr "Kl??i vypr?ela platnost" +msgstr "L?stku vypr?ela platnost" -#, fuzzy -#| msgid "Bad public key" msgid "Bad ticket" -msgstr "Chybn? ve?ejn? kl??" +msgstr "Chybn? l?stek" -#, fuzzy -#| msgid "Unknown packet" msgid "Unknown identity" -msgstr "Nezn?m? packet" +msgstr "Nezn?m? toto?nost" -#, fuzzy -#| msgid "Bad certificate chain" msgid "Bad certificate message in handshake" -msgstr "Chybn? ?et?zec certifik?t?" +msgstr "Chybn? zpr?va s?certifik?tem v?zah?jen?" msgid "Bad certificate request message in handshake" -msgstr "" +msgstr "Chybn? zpr?va s?po?adavkem na certifik?t v?zah?jen?" msgid "Bad certificate verify message in handshake" -msgstr "" +msgstr "Chybn? zpr?va o?ov??en? certifik?tu v?zah?jen?" msgid "Bad change cipher messsage in handshake" -msgstr "" +msgstr "Chybn? zpr?va se zm?nou ?ifry v?zah?jen?" msgid "Bad client hello message in handshake" -msgstr "" +msgstr "Chybn? zpr?va s?pozdravem klienta v?zah?jen?" msgid "Bad server hello message in handshake" -msgstr "" +msgstr "Chybn? zpr?va s?pozdravem serveru v?zah?jen?" msgid "Bad server hello done message in hanshake" -msgstr "" +msgstr "Chybn? zpr?va o?dokon?en? pozdravu serveru v?zah?jen?" msgid "Bad finished message in handshake" -msgstr "" +msgstr "Chybn? zpr?va o?dokon?en? v?zah?jen?" msgid "Bad server key exchange message in handshake" -msgstr "" +msgstr "Chybn? zpr?va o?v?m?n? kl??e serveru v?zah?jen?" msgid "Bad client key exchange message in handshake" -msgstr "" +msgstr "Chybn? zpr?va o?v?m?n? kl??e klienta v?zah?jen?" msgid "Bogus string" -msgstr "" +msgstr "Chybn? ?et?zec" msgid "Forbidden" msgstr "" -#, fuzzy -#| msgid "Key expired" msgid "Key disabled" -msgstr "Kl??i vypr?ela platnost" +msgstr "Kl?? zak?z?n" msgid "Not possible with a card based key" -msgstr "" +msgstr "Nelze prov?st s?kl??em na kart?" -#, fuzzy -#| msgid "Invalid object" msgid "Invalid lock object" msgstr "Neplatn? objekt" -- 2.1.4 From dkg at fifthhorseman.net Mon Mar 16 18:40:12 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Mar 2015 13:40:12 -0400 Subject: [LIBGPG-ERROR PATCH] avoid breakage with gcc 5 Message-ID: <1426527612-6939-1-git-send-email-dkg@fifthhorseman.net> * src/Makefile.am: add -P to the C preprocessor when building mkerrcodes.h, to avoid a noisy intermediate pipeline. -- With gcc 5 without this patch, we see many errors like the following: gcc -I. -I. -o mkerrcodes ./mkerrcodes.c In file included from ./mkerrcodes.c:26:0: ./mkerrcodes.h:9:5: error: expected expression before ?,? token { , "GPG_ERR_E2BIG" }, ^ ./mkerrcodes.h:10:5: error: expected expression before ?,? token { , "GPG_ERR_EACCES" }, ^ This patch cleans up the generated mkerrcodes.h by making the intermediate stage clean for all the versions of gcc i tested (4.x and 5). Debian-Bug-Id: 777374 Signed-Off-By: Daniel Kahn Gillmor --- src/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Makefile.am b/src/Makefile.am index 99c2c53..f847a80 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -213,7 +213,7 @@ code-to-errno.h: Makefile mkerrnos.awk errnos.in # It is correct to use $(CPP). We want the host's idea of the error codes. mkerrcodes.h: Makefile mkerrcodes.awk $(gpg_extra_headers) $(AWK) -f $(srcdir)/mkerrcodes1.awk $(srcdir)/errnos.in >_$@ - $(CPP) $(CPPFLAGS) $(extra_cppflags) _$@ | grep GPG_ERR_ | \ + $(CPP) $(CPPFLAGS) $(extra_cppflags) -P _$@ | grep GPG_ERR_ | \ $(AWK) -f $(srcdir)/mkerrcodes.awk >$@ -rm _$@ -- 2.1.4 From hans at guardianproject.info Mon Mar 16 18:56:43 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 16 Mar 2015 13:56:43 -0400 Subject: Mass filing of clang warnings In-Reply-To: <87ioe4d4f0.fsf@vigenere.g10code.de> References: <87siddtchv.fsf@vigenere.g10code.de> <55004F6F.6090206@guardianproject.info> <87oanzlbqg.fsf@vigenere.g10code.de> <5500857D.5060803@guardianproject.info> <87fv9ajyvg.fsf@vigenere.g10code.de> <5502F8A9.5010709@guardianproject.info> <87ioe4d4f0.fsf@vigenere.g10code.de> Message-ID: <5507195B.6080205@guardianproject.info> Werner Koch: > On Fri, 13 Mar 2015 15:48, hans at guardianproject.info said: > >> That's the kind of stuff that I'm talking about. The key point I'm talking >> about is not about whether the code that triggers the warning is correct or >> not. It is about making it correct AND simple enough for cppcheck to >> understand. That last point is what I'm discussing. > > I know. However it depends on the case. A change like > > - char buffer[BUFFER_SIZE]; > + char buffer[BUFFER_SIZE] = ""; // make cppcheck happy > > this wrong. BUFFER is not expected to be initialized. A flow analysis > may later come and warn about a useless initialization of BUFFER. > > Agreed, I do that sometimes for scalars or pointers which are for > example controlled by a flag variable. I really hate to do that but I > need to shut up gcc in some cases. The problem behind such dummy > initialization is that improved compilers won't be able to detect a > really non-initialized variable or complain about initialized but not > used variable. It is always a tradeoff. > > Also recall that there are more compilers than gcc and Clang. Some even > provided better warnings many years ago. > > If there would only be an annotation format which keeps the actual > source readable (ie. in a separate automagically maintained file). At this point, I'm not talking about compilers. I'm talking about cppcheck, which actually found issues that you confirmed and fixed. That specific example is not particularly worth discussion IMHO. I am sure there is a way to make cppcheck happy that makes sense in the code. That way, GnuPG can gain the real benefits of automatic runs of cppcheck. Right now, it does not seem worthwhile to try to figure the correct way because you have only expressed opposition to the idea of adjusting the code to make cppcheck work better. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 From albrecht.dress at arcor.de Mon Mar 16 21:13:53 2015 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Mon, 16 Mar 2015 21:13:53 +0100 Subject: Mass filing of clang warnings In-Reply-To: <5507195B.6080205@guardianproject.info> (from hans@guardianproject.info on Mon Mar 16 18:56:43 2015) Message-ID: <98Pia2X5j+DHTKGkWcRv2L@dxNJaeayWQ9fqsMw/AoDc> Am 16.03.15 18:56 schrieb(en) Hans-Christoph Steiner: > I am sure there is a way to make cppcheck happy that makes sense in the code. That way, GnuPG can gain the real benefits of automatic runs of cppcheck. I think what you are basically requesting is a coding guideline... Such guidelines are *very* common for safety-related applications. E.g. they are explicitly required when writing C software according to IEC 61508 (Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems), or for automotive (ISO 26262, the coding guideline is MISRA [1]), or for aviation (DO-178C [2]), etc. etc. A well-known freely available set of rules (with some overlap with MISRA) are the CERT Secure Coding Standards [3]. IMHO, a /security/ application could also benefit from using standards developed for /safety/ related stuff... Unfortunately, cppcheck cannot validate (afaik) against the aforementioned standards. At work I have to write software according to MISRA (for IEC 61508 compliance) and use Flexelint [4] for the validation, which not oss, but one of the cheaper tools available (compared to Eclair, LDRA, ...). Needless to mention that it produces tons of false-positives, too... Best, Albrecht. [1] [2] [3] [4] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From coruus at gmail.com Mon Mar 16 23:03:45 2015 From: coruus at gmail.com (David Leon Gil) Date: Mon, 16 Mar 2015 15:03:45 -0700 Subject: [openpgp] "OpenPGP Simple" In-Reply-To: References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> Message-ID: On Monday, March 16, 2015, David Shaw wrote: > On Mar 16, 2015, at 5:15 PM, David Leon Gil > wrote: > > > > Re Jon's comment above: The five-octet, new-format thing is what the > End-to-End extension does. > > > > On Monday, March 16, 2015, Werner Koch > > wrote: > > On Mon, 16 Mar 2015 19:12, singpolyma at singpolyma.net > said: > > > > > Yes. Last time I checked, gnupg < 2 (which is still the default on > > > most of my systems) only generates old-style headers, whereas my > > > > That depends on how you invoke gpg and whether the new packer headers > > are required. That is required for PGP-2 compatibility. > > > > Is there an option to completely disable this? > > Not in the current code, but you can of course patch it. > > > Relatedly, is there any option to not use new-format partial lengths? > > A partial length is needed to handle content as a stream - say some > program that generates gigabytes of data (like a backup). Something large > enough that you really don't want to have to buffer the whole thing before > encrypting it. > I agree on that. But I think this really requires a different mode of operation / standard. See, e.g., https://www.imperialviolet.org/2014/06/27/streamingencryption.html I'm not sure that an OpenPGP WG is the right place to do this. (Which is why I said that the scope should be limited to email-length messages.) -- But, e.g., GnuPG (always?) emits partial lengths, even for data it already knows the length of (and is << even 2^20 bytes). -------------- next part -------------- An HTML attachment was scrubbed... URL: From coruus at gmail.com Mon Mar 16 22:15:28 2015 From: coruus at gmail.com (David Leon Gil) Date: Mon, 16 Mar 2015 14:15:28 -0700 Subject: [openpgp] "OpenPGP Simple" In-Reply-To: <87d2484tg4.fsf@vigenere.g10code.de> References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> Message-ID: Re Jon's comment above: The five-octet, new-format thing is what the End-to-End extension does. On Monday, March 16, 2015, Werner Koch wrote: > On Mon, 16 Mar 2015 19:12, singpolyma at singpolyma.net said: > > > Yes. Last time I checked, gnupg < 2 (which is still the default on > > most of my systems) only generates old-style headers, whereas my > > That depends on how you invoke gpg and whether the new packer headers > are required. That is required for PGP-2 compatibility. > Is there an option to completely disable this? Relatedly, is there any option to not use new-format partial lengths? Partial lengths are really a nuisance to parse. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Mon Mar 16 22:30:55 2015 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 16 Mar 2015 17:30:55 -0400 Subject: [openpgp] "OpenPGP Simple" In-Reply-To: References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> Message-ID: On Mar 16, 2015, at 5:15 PM, David Leon Gil wrote: > > Re Jon's comment above: The five-octet, new-format thing is what the End-to-End extension does. > > On Monday, March 16, 2015, Werner Koch wrote: > On Mon, 16 Mar 2015 19:12, singpolyma at singpolyma.net said: > > > Yes. Last time I checked, gnupg < 2 (which is still the default on > > most of my systems) only generates old-style headers, whereas my > > That depends on how you invoke gpg and whether the new packer headers > are required. That is required for PGP-2 compatibility. > > Is there an option to completely disable this? Not in the current code, but you can of course patch it. > Relatedly, is there any option to not use new-format partial lengths? A partial length is needed to handle content as a stream - say some program that generates gigabytes of data (like a backup). Something large enough that you really don't want to have to buffer the whole thing before encrypting it. > Partial lengths are really a nuisance to parse. No argument there... David From dkg at fifthhorseman.net Tue Mar 17 00:28:31 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Mar 2015 19:28:31 -0400 Subject: Encrypting / Signing the mail subject? In-Reply-To: <1424628876.3637.1@deneb.(none)> References: <1424628876.3637.1@deneb.(none)> Message-ID: <87fv94r080.fsf@alice.fifthhorseman.net> Hi Albrecht-- Sorry for the late followup -- this has now been raised on openpgp at ietf.org, so i'm moving the follow up there. On Sun 2015-02-22 13:14:36 -0500, Albrecht Dre? wrote: > I am currently working on the implementation of your proposal for Balsa [1], and would like to add a few comments. I'm glad to hear this! > Am 16.01.15 21:29 schrieb(en) Daniel Kahn Gillmor: >> PGP/MIME messages are the only reliably structured mail OpenPGP e-mail messages anyway [0]. > > As your proposal is fully transparent, I think it could also be used > for RFC 2633 S/MIME (i.e. multipart/signed; > application/pkcs7-signature as well as for application/pkcs7-mime). yep, this seems correct to me, but i don't know enough about the S/MIME world to take the proposal there. Maybe we should find some S/MIME folks to chime in on this. >> The embedded header part (F, above) should be Content-Disposition: >> inline, and should be subject to all the usual rules of parsing mail >> message headers. > > In your example, you added a "charset" parameter to the mime type. > IMHO, this contradicts the RFC 6522 statement that it shall have > neither required nor optional parameters. I think it's unneeded > anyway, as all headers shall be encoded as required by RFC 2047. > Applying the "usual" header parsing rules will of course decode them > properly. yep, you're right about this. > The whole part /should/ be encoded quoted-printable, though, as > required by RFC 3156, sect. 3. The headers /should/ be 7-bit clean, > but you never know for sure... I think this also makes sense. >> This e-mail message contains a signed set of embedded headers in the >> way i've proposed. How does it render in your unaware MUA? feel >> free to send me a private report if you like. > > What do you think about always adding a header, > e.g. "X-Protected-Headers", which includes a short info about the > purpose of that part (as in this example)? Otherwise, it might be > somewhat confusing if such a MUA displays the header twice. If we can > agree on a standard name, it also assists MUA's to detect the block. Are you thinking of having this line in the embedded header or in the external header? I'm not sure that this is useful to have in the external header at all. In particular, it won't be cryptographically authenticated, and it won't be encrypted. So an attacker could (for example) strip out the external header and cause the MUA to ignore the embedded part. As for the embedded header, i'm not sure it's useful there either. it seems like a bit of a chicken-and-egg problem. >> signed_headers: >> * Subject >> * Date >> * From >> * To >> * Cc > > As including more headers doesn't cost much, I propose to also add the following: > - Reply-To: and Disposition-Notification-To:. Rationale: an attacker might tamper them as to provoke sending information to arbitrary recipients (at least for inattentive users, or for MUA's sending MDN's automatically). > - References: and In-Reply-To:. Rationale: avoids breaking the threading information by an attacker. I agree about the ones you mention here. Mail-Followup-To also seems relevant. >> encrypted_headers: >> * (Subject,"ENCRYPTED SUBJECT") >> * (In-Reply-To,) >> * (References,) > > IMHO, the list of encrypted headers could be the same as above. i think the list of encrypted headers might arguably be *all* of the headers except for some dummy block that is generated per-message. >> We'd also need to define what happens if more than one >> text/rfc822-headers part shows up in a multipart message -- most >> simply, we could say that we only process text/rfc822-headers if it >> happens to be the first non-multipart part within the >> multipart/signed or multipart/encrypted part. > > I think this should read: "if the text/rfc822-headers part is > * the first part of a multipart/mixed, which in turn is the first part of the top-level multipart/signed or application/pkcs7-mime, or > * the first part of the top-level decrypted multipart/mixed for unsigned, but encrypted messages." That seems more narrowly scoped, which is probably a good thing, but it might be more brittle too; are there specific cases that you're trying to carve out from my broader suggestion? >> This prevents the receiving MUA from applying text/rfc822-headers from a forwarded (attached) signed/encrypted message. > > It would make sense, though, to verify if the headers of forwarded and > signed message/rfc822 parts against the (embedded) text/rfc822-headers > parts. what kind of verification should an MUA do? Is there any reason for an MUA to prefer the external headers where the embedded headers and external headers differ? For encrypted headers, we'd *assume* that they would differ, right, otherwise, there's nothing to gain from stuffing them inside the encrypted section. --dkg From wk at gnupg.org Tue Mar 17 12:18:20 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Mar 2015 12:18:20 +0100 Subject: [openpgp] "OpenPGP Simple" In-Reply-To: (David Shaw's message of "Mon, 16 Mar 2015 17:30:55 -0400") References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> Message-ID: <87zj7b3m9v.fsf@vigenere.g10code.de> On Mon, 16 Mar 2015 22:30, dshaw at jabberwocky.com said: > A partial length is needed to handle content as a stream - say some program that generates gigabytes of data (like a backup). Something large enough that you really don't want to have to buffer the whole thing before encrypting it. And to support > 4GiB files on systems without LFS support. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Tue Mar 17 16:34:43 2015 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 17 Mar 2015 11:34:43 -0400 Subject: [openpgp] "OpenPGP Simple" In-Reply-To: <87zj7b3m9v.fsf@vigenere.g10code.de> References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> <87zj7b3m9v.fsf@vigenere.g10code.de> Message-ID: <3A820350-6B24-4735-965A-7D8265578BAC@jabberwocky.com> On Mar 17, 2015, at 7:18 AM, Werner Koch wrote: > > On Mon, 16 Mar 2015 22:30, dshaw at jabberwocky.com said: > >> A partial length is needed to handle content as a stream - say some program that generates gigabytes of data (like a backup). Something large enough that you really don't want to have to buffer the whole thing before encrypting it. > > And to support > 4GiB files on systems without LFS support. Right, good point. I think it's safe to say there are enough uses for partial length / streaming that it should be kept. Not all the world is email. What if the encoding was really simple - something like 4 bytes always, and the leftmost bit would mean "partial". So any packet 2^31 or less could be encoded in one piece, but we could still do partial for those situations that needed it. We could have any number of partial lengths, but it would always end with a non-partial final length. David From lists-gnupgdev at lina.inka.de Tue Mar 17 21:24:24 2015 From: lists-gnupgdev at lina.inka.de (lists-gnupgdev at lina.inka.de) Date: Tue, 17 Mar 2015 21:24:24 +0100 Subject: [openpgp] "OpenPGP Simple" In-Reply-To: <3A820350-6B24-4735-965A-7D8265578BAC@jabberwocky.com> References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> <87zj7b3m9v.fsf@vigenere.g10code.de> <3A820350-6B24-4735-965A-7D8265578BAC@jabberwocky.com> Message-ID: <20150317212424.00000db6.ecki@lina.inka.de> Am Tue, 17 Mar 2015 11:34:43 -0400 schrieb David Shaw : > Right, good point. I think it's safe to say there are enough uses > for partial length / streaming that it should be kept. Not all the > world is email. If only the parts would be authenticated and it would actually be safe to use a streaming pgp. A modern file format should support segments and integrity checks for them. And to keep it simple, it could be the only mode (as for emails the payload might fit into a single segment anyway). Gruss Bernd From wk at gnupg.org Tue Mar 17 21:47:38 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Mar 2015 21:47:38 +0100 Subject: [openpgp] "OpenPGP Simple" In-Reply-To: (David Leon Gil's message of "Mon, 16 Mar 2015 14:15:28 -0700") References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> Message-ID: <87pp871hcl.fsf@vigenere.g10code.de> On Mon, 16 Mar 2015 22:15, coruus at gmail.com said: > Is there an option to completely disable this? Relatedly, is there any > option to not use new-format partial lengths? No. In fact I started with GnuPG before OpenPGP and one of the first additions to the RFC-1991 PGP-2 format was my own version of partial lengths. This has been removed in favor of the OpenPGP and PGP-5 partial length format. You really really want partial length. A major problem with PGP-2 was that it required large temporary files for certain operations - you can't do backups this way. Up until DKIM all Internet protocols have been carefully designed to allow streaming of data (ie. the Unix way) and the IETF should continue to stress the importance of this. > Partial lengths are really a nuisance to parse. Yeah the OpenPGP encoding is a bit over-engineered to save octets. But even its partial format is easier to implement than the HTTP counterpart. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Mar 18 18:16:13 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 18 Mar 2015 13:16:13 -0400 Subject: how to improve tools that test for $GPG_AGENT_INFO Message-ID: <87zj7ai5uq.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- as i'm thinking about moving debian toward GnuPG 2.1, i find there are several packages in debian that decide whether to use the agent or not based on the presence (or absence) of the $GPG_AGENT_INFO environment variable. In 2.1, that environment variable isn't set, and programs that use this test (e.g. mutt, aiui) are likely to think that they shouldn't use the agent. there are a lot of packages that look at this variable: http://codesearch.debian.net/perpackage-results/GPG_AGENT_INFO I'd like to suggest fixes for those tools to be compatible with gpg2.1 without breaking compatibility for them with 2.0 or 1.4. At a baseline, if they see GPG_AGENT_INFO in the environment, i think they should try to use the agent (and not deal with passphrase caching themselves). What else should they test? Some ideas of what they should do if they don't see GPG_AGENT_INFO in the environment: * run "gpg-agent -q" -- if the return code is 0, then you should use the agent. * run "gpg --version" look at the output. If you see 2.1.x or later, then you should use the agent. Is there some cheaper, simpler test that i could recommend to gpg dependencies that wouldn't involve spawning a subprocess? Any preferences or suggestions? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dgouttegattat at incenp.org Wed Mar 18 20:11:05 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 18 Mar 2015 20:11:05 +0100 Subject: how to improve tools that test for $GPG_AGENT_INFO In-Reply-To: <87zj7ai5uq.fsf@alice.fifthhorseman.net> References: <87zj7ai5uq.fsf@alice.fifthhorseman.net> Message-ID: <5509CDC9.700@incenp.org> On 03/18/2015 06:16 PM, Daniel Kahn Gillmor wrote: > Some ideas of what they should do if they don't see GPG_AGENT_INFO in > the environment: > > * run "gpg-agent -q" -- if the return code is 0, then you should use > the agent. > > * run "gpg --version" look at the output. If you see 2.1.x or later, > then you should use the agent. Another possibility (which still requires to spawn a new process) would be the --use-standard-socket-p option. If "gpg-agent --use-standard-socket-p" returns 0, then you know you can use the agent even if there is no GPG_AGENT_INFO in the environment. This should work with both GnuPG 2.0 and GnuPG 2.1. -------------- 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 Thu Mar 19 12:18:20 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Mar 2015 12:18:20 +0100 Subject: how to improve tools that test for $GPG_AGENT_INFO In-Reply-To: <5509CDC9.700@incenp.org> (Damien Goutte-Gattat's message of "Wed, 18 Mar 2015 20:11:05 +0100") References: <87zj7ai5uq.fsf@alice.fifthhorseman.net> <5509CDC9.700@incenp.org> Message-ID: <87a8z9xmkj.fsf@vigenere.g10code.de> On Wed, 18 Mar 2015 20:11, dgouttegattat at incenp.org said: > Another possibility (which still requires to spawn a new process) I don't think that there is a way to avoid this. > If "gpg-agent --use-standard-socket-p" returns 0, then you know you > can use the agent even if there is no GPG_AGENT_INFO in the (That is what gpg uses internally to check whether gpg-agent has been configured to use a standard socket and works for 2.0 and 2.1.) I think that is the best option. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Mar 20 16:35:46 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 20 Mar 2015 11:35:46 -0400 Subject: how to improve tools that test for $GPG_AGENT_INFO In-Reply-To: <87a8z9xmkj.fsf@vigenere.g10code.de> References: <87zj7ai5uq.fsf@alice.fifthhorseman.net> <5509CDC9.700@incenp.org> <87a8z9xmkj.fsf@vigenere.g10code.de> Message-ID: <871tkjfzql.fsf@alice.fifthhorseman.net> On Thu 2015-03-19 07:18:20 -0400, Werner Koch wrote: > On Wed, 18 Mar 2015 20:11, dgouttegattat at incenp.org said: > >> Another possibility (which still requires to spawn a new process) > > I don't think that there is a way to avoid this. > >> If "gpg-agent --use-standard-socket-p" returns 0, then you know you >> can use the agent even if there is no GPG_AGENT_INFO in the > > (That is what gpg uses internally to check whether gpg-agent has been > configured to use a standard socket and works for 2.0 and 2.1.) > > I think that is the best option. Thanks, this is useful guidance. I note that --use-standard-socket-p isn't mentioned in the gpg-agent(1) man page. Could it be added? I suspect tools that rely on gpg will be more comfortable relying on a documented stable interface than just a mailing list post. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From hanno at hboeck.de Sun Mar 22 12:58:48 2015 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Sun, 22 Mar 2015 12:58:48 +0100 Subject: Analyzing key server data Message-ID: <20150322125848.218ee839@pc1> Hi, I think this could be interesting for a couple of people: I had a project running in private for quite a while, I now published the details: I wrote a script that analyzes the dumps from key servers and puts the crypto values into a mysql database. This can be used to search for vulnerable keys or signatures on large scale. I did this for two potential threats: DSA signatures with duplicate k values and RSA keys with shared factors. The overall result is a good one: It seems OpenPGP implementations with completely broken random number generators exist, but they are a rare thing. Code: https://github.com/hannob/pgpecosystem Background paper: http://eprint.iacr.org/2015/262 cu, -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From diafygi at gmail.com Sun Mar 22 16:33:01 2015 From: diafygi at gmail.com (Daniel Roesler) Date: Sun, 22 Mar 2015 08:33:01 -0700 Subject: [Sks-devel] Analyzing key server data In-Reply-To: <20150322125848.218ee839@pc1> References: <20150322125848.218ee839@pc1> Message-ID: Great paper! Thanks! >From the paper: > However when trying to calculate the private keys it turns out most > of these results aren't real signatures. I was under the impression that SKS verified signature packets both during upload and during gossip. If so, how did invalid or corrupt signature packets make it into the database? Do you have a count of the total number of invalid signature packets? Daniel On Sun, Mar 22, 2015 at 4:58 AM, Hanno B?ck wrote: > Hi, > > I think this could be interesting for a couple of people: > > I had a project running in private for quite a while, I now published > the details: I wrote a script that analyzes the dumps from key servers > and puts the crypto values into a mysql database. > > This can be used to search for vulnerable keys or signatures on large > scale. I did this for two potential threats: DSA signatures with > duplicate k values and RSA keys with shared factors. > > The overall result is a good one: It seems OpenPGP implementations with > completely broken random number generators exist, but they are a rare > thing. > > Code: > https://github.com/hannob/pgpecosystem > > Background paper: > http://eprint.iacr.org/2015/262 > > cu, > -- > Hanno B?ck > http://hboeck.de/ > > mail/jabber: hanno at hboeck.de > GPG: BBB51E42 > > _______________________________________________ > Sks-devel mailing list > Sks-devel at nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > From dkg at fifthhorseman.net Sun Mar 22 22:47:45 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 22 Mar 2015 16:47:45 -0500 Subject: Encrypting / Signing the mail subject? In-Reply-To: References: Message-ID: <87h9tcd7r2.fsf@alice.fifthhorseman.net> Hi Albrecht-- On Sun 2015-03-22 11:56:42 -0500, Albrecht Dre? wrote: > Am 17.03.15 00:28 schrieb(en) Daniel Kahn Gillmor: >> Are you thinking of having this line in the embedded header or in the >> external header? > > Only in the embedded, signed headers block. [...] >> As for the embedded header, i'm not sure it's useful there either. >> it seems like a bit of a chicken-and-egg problem. > > Hmmm, yes, thinking again about it, you're right. The only use of > that header would be informing the recipient of a message about the > purpose of this part if the MUA does not perform any further action > with it (see the attached screen shot as example). Hm, if the goal is human-friendliness, then we probably want to think about how to be even friendlier -- english text plus a URL to an en_US-only webpage isn't very nice to the majority of the world either :P >> i think the list of encrypted headers might arguably be *all* of the >> headers except for some dummy block that is generated per-message. > > What do you mean with "some dummy block"? the "dummy block" is the headers that get wrapped around the outside of the message. Alexey Melnikov just pointed me to this draft: https://tools.ietf.org/html/draft-melnikov-smime-header-signing-00 which has a similar mechanism (and is designed for S/MIME), and it refers to the same idea as a "stub value" https://tools.ietf.org/html/draft-melnikov-smime-header-signing-00#section-3 > BTW, the Message-Id header may also leak information if uses the > recommended form of RFC 5322, sect 3.6.4 (domain or FQDN as right-hand > side). The 'dot-atom-text - "@" - dot-atom-text' format with random > data on both sides (which is also explicitly allowed) should be > preferred IMHO, as long as it is guaranteed to be unique. good point! >>> I think this should read: "if the text/rfc822-headers part is >>> * the first part of a multipart/mixed, which in turn is the first part of the top-level multipart/signed or application/pkcs7-mime, or >>> * the first part of the top-level decrypted multipart/mixed for unsigned, but encrypted messages." >> >> That seems more narrowly scoped, which is probably a good thing, but >> it might be more brittle too; are there specific cases that you're >> trying to carve out from my broader suggestion? > > I think your definition would try to match the text/rfc822-headers > part to the message headers in the following weird case: > > multipart/signed > +- multipart/mixed <-- message #1 does *not* contain protected headers > | +- text/pain > | +- message/rfc822 <-- forwarded message #2 *with* protected headers > | +- multipart/signed > | +- multipart/mixed > | | +- text/rfc822-headers <-- protected headers of forwarded message #2 > | | +- text/plain > | +- application/pgp-signature > +- application/pgp-signature > > Here, text/rfc822-headers *is* the first non-multipart part within a > multipart/signed, but it doesn't belong to the (top-level) message #1, > so it's wrong to compare them. I think, my definition would catch > this case. You're right. I think this distinction is useful. PS i love the content type "text/pain" -- can we register that one officially, please? ;) Melnikov's draft proposes a content-type parameter "forwarded" to be used on the message/rfc822 element, to distinguish these cases. I haven't thought through the consequences of the way this his draft sets it up, though -- it seems possible to misinterpret the lack of a header from a non-compatible sender forwarding a message. --dkg From dkg at fifthhorseman.net Sun Mar 22 22:50:28 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 22 Mar 2015 16:50:28 -0500 Subject: [Sks-devel] Analyzing key server data In-Reply-To: References: <20150322125848.218ee839@pc1> Message-ID: <87egogd7mj.fsf@alice.fifthhorseman.net> On Sun 2015-03-22 10:33:01 -0500, Daniel Roesler wrote: > I was under the impression that SKS verified signature packets both > during upload and during gossip. SKS does no cryptographic verification. :( Even if it were to start doing verification, it's not clear how that would work with certifications from keys it doesn't know about. And the introduction of cryptographic verification would segment the SKS keyserver network into those that do verification and those that do not; it's like applying a filter -- it either needs to be done on all SKS instances or none of them :/ --dkg From neal at g10code.de Mon Mar 23 20:14:04 2015 From: neal at g10code.de (Neal H. Walfield) Date: Mon, 23 Mar 2015 20:14:04 +0100 Subject: LDAP Keyserver Support in v2.1 Message-ID: <87a8z38r2b.wl%neal@walfield.org> Hi, I've spent the past few weeks forward porting and rewriting the LDAP Keyserver support for GnuPG 2.1. I've just pushed it to master. To test it, you can run the following: $ gpg2 --keyserver ldap://keys.eika.no --search-keys kf at eika.no $ gpg2 --keyserver ldap://keys.eika.no --send-key 664D7444 $ gpg2 --keyserver ldap://keys.eika.no --recv-key 664D7444 (keys.eika.no is a publically available LDAP keyserver. If you want to set up your own, you can try following [1].) If you need to log in to access the LDAP server, use the following URI: ldap://HOST/????bindname=uid=USER%2cou=PGP%20Users%2cdc=EXAMPLE%2cdc=ORG,password=PASSWORD You'll need to replace USER, dc=EXAMPLE%2cdc=ORG and PASSWORD. Make sure to include four question marks. Note that the values are percent escaped. Thus, spaces are replaced with %2c and commas with %2c. In addition to the ldap protocol, you can access the server using the ldaps (TLS) and ldapi protocols. I'm interested in both problems you may have as well as success. Thanks, Neal [1] http://wiki.gnupg.org/LDAPKeyserver From albrecht.dress at arcor.de Sun Mar 22 17:56:42 2015 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Sun, 22 Mar 2015 17:56:42 +0100 Subject: Encrypting / Signing the mail subject? In-Reply-To: <87fv94r080.fsf@alice.fifthhorseman.net> (from dkg@fifthhorseman.net on Tue Mar 17 00:28:31 2015) Message-ID: A non-text attachment was scrubbed... Name: not available Type: text/rfc822-headers Size: 552 bytes Desc: not available URL: -------------- next part -------------- Hi Daniel: Thanks a lot for your input! Am 17.03.15 00:28 schrieb(en) Daniel Kahn Gillmor: > this has now been raised on openpgp at ietf.org, so i'm moving the follow up there. Thanks for that hint - I also subscribed there. >> What do you think about always adding a header, e.g. "X-Protected-Headers", which includes a short info about the purpose of that part (as in this example)? Otherwise, it might be somewhat confusing if such a MUA displays the header twice. If we can agree on a standard name, it also assists MUA's to detect the block. > > Are you thinking of having this line in the embedded header or in the external header? Only in the embedded, signed headers block. > I'm not sure that this is useful to have in the external header at all. In particular, it won't be cryptographically authenticated, and it won't be encrypted. So an attacker could (for example) strip out the external header and cause the MUA to ignore the embedded part. Yes, I fully agree with you! > As for the embedded header, i'm not sure it's useful there either. it seems like a bit of a chicken-and-egg problem. Hmmm, yes, thinking again about it, you're right. The only use of that header would be informing the recipient of a message about the purpose of this part if the MUA does not perform any further action with it (see the attached screen shot as example). > I agree about the ones you mention here. Mail-Followup-To also seems relevant. Good point, I missed that one. > i think the list of encrypted headers might arguably be *all* of the headers except for some dummy block that is generated per-message. What do you mean with "some dummy block"? BTW, the Message-Id header may also leak information if uses the recommended form of RFC 5322, sect 3.6.4 (domain or FQDN as right-hand side). The 'dot-atom-text - "@" - dot-atom-text' format with random data on both sides (which is also explicitly allowed) should be preferred IMHO, as long as it is guaranteed to be unique. >> I think this should read: "if the text/rfc822-headers part is >> * the first part of a multipart/mixed, which in turn is the first part of the top-level multipart/signed or application/pkcs7-mime, or >> * the first part of the top-level decrypted multipart/mixed for unsigned, but encrypted messages." > > That seems more narrowly scoped, which is probably a good thing, but it might be more brittle too; are there specific cases that you're trying to carve out from my broader suggestion? I think your definition would try to match the text/rfc822-headers part to the message headers in the following weird case: multipart/signed +- multipart/mixed <-- message #1 does *not* contain protected headers | +- text/pain | +- message/rfc822 <-- forwarded message #2 *with* protected headers | +- multipart/signed | +- multipart/mixed | | +- text/rfc822-headers <-- protected headers of forwarded message #2 | | +- text/plain | +- application/pgp-signature +- application/pgp-signature Here, text/rfc822-headers *is* the first non-multipart part within a multipart/signed, but it doesn't belong to the (top-level) message #1, so it's wrong to compare them. I think, my definition would catch this case. >> It would make sense, though, to verify if the headers of forwarded and signed message/rfc822 parts against the (embedded) text/rfc822-headers parts. > > what kind of verification should an MUA do? Is there any reason for an MUA to prefer the external headers where the embedded headers and external headers differ? No, I think that the headers validation should be applied recursively to embedded massages, not only to the top-level message. Example: multipart/signed <-- message #1 w/ genuine headers +- multipart/mixed | +- text/rfc822-headers <-- headers match message #1 headers | +- text/pain | +- message/rfc822 <-- forwarded message #2 w/ modified headers | +- multipart/signed | +- multipart/mixed | | +- text/rfc822-headers <-- headers *do not* match message #2 headers | | +- text/plain | +- application/pgp-signature <-- correct signature +- application/pgp-signature <-- correct signature In this case, the MUA might tell the user the following: * the signature of the main message #1 verifies * the signature of the embedded message #2 verifies * the headers of the main message #1 are genuine * the headers of the embedded message #2 have been modified by someone Best, Albrecht. -------------- next part -------------- A non-text attachment was scrubbed... Name: Headers.png Type: image/png Size: 56905 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From wk at gnupg.org Tue Mar 24 09:33:12 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Mar 2015 09:33:12 +0100 Subject: Encrypting / Signing the mail subject? In-Reply-To: ("Albrecht =?utf-8?Q?Dre=C3=9F=22's?= message of "Sun, 22 Mar 2015 17:56:42 +0100") References: Message-ID: <87384uokvr.fsf@vigenere.g10code.de> On Sun, 22 Mar 2015 17:56, albrecht.dress at arcor.de said: > X-Protected-Headers: protected message headers, see > Do you want to write a short text explaining this so we can setup a page https://gnupg.org/faq/protected-headers.html ? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Tue Mar 24 22:53:02 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 24 Mar 2015 22:53:02 +0100 Subject: LDAP Keyserver Support in v2.1 In-Reply-To: <87a8z38r2b.wl%neal@walfield.org> References: <87a8z38r2b.wl%neal@walfield.org> Message-ID: <5511DCBE.1010604@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/23/2015 08:14 PM, Neal H. Walfield wrote: > Hi, > > I've spent the past few weeks forward porting and rewriting the > LDAP Keyserver support for GnuPG 2.1. I've just pushed it to > master. > > To test it, you can run the following: > Thanks, this now works when specifying keyserver in gpg.conf and restarting dirmngr. > $ gpg2 --keyserver ldap://keys.eika.no --search-keys kf at eika.no $ > gpg2 --keyserver ldap://keys.eika.no --send-key 664D7444 $ gpg2 > --keyserver ldap://keys.eika.no --recv-key 664D7444 > > (keys.eika.no is a publically available LDAP keyserver. If you > want to set up your own, you can try following [1].) Yup, there is also gpg --keyserver ldap://keys.sumptuouscapital.com --search kf at sumptuouscapital.com that is an OpenLDAP frontend for a HKP keyservers (in this case using SKS as backend hosting my personal keys). > > I'm interested in both problems you may have as well as success. > The issue that has been discussed earlier still applies regarding specifying a keyserver for a single operation, so gpg --keyserver ldap://keys.eika.no --search kf at eika.no gpg: data source: http://keys2.kfwebs.net:11371 (which is the keyserver I normally use in gpg.conf, don't mind the non-hkp part, the host entry ensure it is only accessible over a VPN to my LAN) Would it be possible to get a fix in for --keyserver in 2.1? Also, does it make sense to introduce a way to specify a mapping file to set a preferred keyserver for a key from the client side (I normally disable honoring preferred keyserver for keys, but I would like to enable it for some lookups, in particular on a per key/domain basis) - -- - ---------------------------- 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 - ---------------------------- Dura necessitas Necessity is harsh -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVEdy2AAoJEP7VAChXwav6oFwH/2Lp1SF2uyubsqe4p2PZDOGJ plaGtx4+2a1EZMJ4CS9efxRHL4h/tnT4UkBOpdq724+VNGL8n24/iKcRhw2yXyW/ DHIwlqrAAze4J3dWGFtH9Eat/Si15RTy68tGcYW6VU1tIFPETU3DPCiiveTHvv3x ruzkRirYOckfU9CssrxHLv55JvJMWh/E2ZvkZPa4i1cKDPKONeb8Bvvs22yU+VX4 agDiySHNmx6BCSZJHQbg0Sbq+sKRNO6S3U5J6YYvjtQzy5HiezI7R6wA1DupbVVf GGEnxA5xA20BxeLfhD3PstmQuPxT0wi3Sz7xSE4TjcrwFuUzAzBlhSyI4DkV8co= =5I0w -----END PGP SIGNATURE----- From neal at walfield.org Wed Mar 25 11:04:50 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 25 Mar 2015 11:04:50 +0100 Subject: LDAP Keyserver Support in v2.1 In-Reply-To: <5511DCBE.1010604@sumptuouscapital.com> References: <87a8z38r2b.wl%neal@walfield.org> <5511DCBE.1010604@sumptuouscapital.com> Message-ID: <87oanh75q5.wl%neal@walfield.org> Hi Kristian, At Tue, 24 Mar 2015 22:53:02 +0100, Kristian Fiskerstrand wrote: > The issue that has been discussed earlier still applies regarding > specifying a keyserver for a single operation, so > gpg --keyserver ldap://keys.eika.no --search kf at eika.no > > gpg: data source: http://keys2.kfwebs.net:11371 > (which is the keyserver I normally use in gpg.conf, don't mind the > non-hkp part, the host entry ensure it is only accessible over a VPN > to my LAN) I think the problem that you are reporting is that gpg --keyserver doesn't override the keyserver setting in gpg.conf. I just tried it here locally and it works fine. Perhaps I'm misunderstanding the problem. Either way, can you please elaborate a bit so I can reproduce your issue. Thanks, Neal From kristian.fiskerstrand at sumptuouscapital.com Wed Mar 25 11:21:14 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 25 Mar 2015 11:21:14 +0100 Subject: LDAP Keyserver Support in v2.1 In-Reply-To: <87oanh75q5.wl%neal@walfield.org> References: <87a8z38r2b.wl%neal@walfield.org> <5511DCBE.1010604@sumptuouscapital.com> <87oanh75q5.wl%neal@walfield.org> Message-ID: <55128C1A.7060001@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/25/2015 11:04 AM, Neal H. Walfield wrote: > Hi Kristian, > > At Tue, 24 Mar 2015 22:53:02 +0100, Kristian Fiskerstrand wrote: ... > > I think the problem that you are reporting is that gpg --keyserver > doesn't override the keyserver setting in gpg.conf. I just tried > it here locally and it works fine. Perhaps I'm misunderstanding > the problem. Either way, can you please elaborate a bit so I can > reproduce your issue. it is discussed in the thread surrounding [0], known issue in 2.1... References: [0] http://lists.gnupg.org/pipermail/gnupg-devel/2014-December/029230.html - -- - ---------------------------- 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 - ---------------------------- "Action is the foundational key to all success" (Pablo Picasso) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVEowVAAoJEP7VAChXwav6sgMIALW36/FpomqUoqHD/FBatkmu WzIiIQoupa9CTcZLTdtRXzFMyve+S469K8UfUjzZh3jKX09QWgodhEWYaqR+cj34 v3INdQI8pW9MQp8g60STF3/LLPNy6aq47mnbQETo8Sdv2mI9ZMlv/CqqS+2dKxjd cEXNPBjIH5lYw7ygvQB0ESTgaGkAfrIHvZH3u6CrUeXIBXLSXA+a+6438M358Mz3 IjUeLnj2O+/J78H7/EBGpy2Z1Lw4DblPQrq3eqmHlvE4pUpGhwK/hfSLKs0SpoBX FDv63YdND8y3rASzsPtHRjaE6PfNBUkcs+tqOLXJUDumuMOMOBYm/S+O3vf075s= =6Goz -----END PGP SIGNATURE----- From neal at walfield.org Wed Mar 25 11:08:43 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 25 Mar 2015 11:08:43 +0100 Subject: LDAP Keyserver Support in v2.1 In-Reply-To: <5511DCBE.1010604@sumptuouscapital.com> References: <87a8z38r2b.wl%neal@walfield.org> <5511DCBE.1010604@sumptuouscapital.com> Message-ID: <87mw3175jo.wl%neal@walfield.org> At Tue, 24 Mar 2015 22:53:02 +0100, Kristian Fiskerstrand wrote: > Also, > does it make sense to introduce a way to specify a mapping file to set > a preferred keyserver for a key from the client side (I normally > disable honoring preferred keyserver for keys, but I would like to > enable it for some lookups, in particular on a per key/domain basis) This is possible. Could you please file a bug report at https://bugs.gnupg.org. Perhaps with details of how you imagine this mechanism working. In particular, please mention the types of filters you want and how to imagine expressing them. Since this is a bit of a special use case (as I understand it), it's unlikely that we'll get to it soon. Thanks, Neal From neal at walfield.org Wed Mar 25 11:32:16 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 25 Mar 2015 11:32:16 +0100 Subject: LDAP Keyserver Support in v2.1 In-Reply-To: <55128C1A.7060001@sumptuouscapital.com> References: <87a8z38r2b.wl%neal@walfield.org> <5511DCBE.1010604@sumptuouscapital.com> <87oanh75q5.wl%neal@walfield.org> <55128C1A.7060001@sumptuouscapital.com> Message-ID: <87lhil74gf.wl%neal@walfield.org> Hi Kristian, At Wed, 25 Mar 2015 11:21:14 +0100, Kristian Fiskerstrand wrote: > On 03/25/2015 11:04 AM, Neal H. Walfield wrote: > > At Tue, 24 Mar 2015 22:53:02 +0100, Kristian Fiskerstrand wrote: > > I think the problem that you are reporting is that gpg --keyserver > > doesn't override the keyserver setting in gpg.conf. I just tried > > it here locally and it works fine. Perhaps I'm misunderstanding > > the problem. Either way, can you please elaborate a bit so I can > > reproduce your issue. > > it is discussed in the thread surrounding [0], known issue in 2.1... Thanks for pointing me to this. Neal From aheinecke at intevation.de Wed Mar 25 17:34:11 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 25 Mar 2015 17:34:11 +0100 Subject: LDAP Keyserver Support in v2.1 In-Reply-To: <55128C1A.7060001@sumptuouscapital.com> References: <87a8z38r2b.wl%neal@walfield.org> <87oanh75q5.wl%neal@walfield.org> <55128C1A.7060001@sumptuouscapital.com> Message-ID: <2863364.FqMMkHcxJU@esus> Hi, On Wednesday, March 25, 2015 11:21:14 AM Kristian Fiskerstrand wrote: > it is discussed in the thread surrounding [0], known issue in 2.1... > > References: > [0] http://lists.gnupg.org/pipermail/gnupg-devel/2014-December/029230.html I've opened an issue for this as known issues should have numbers. :-) https://bugs.g10code.com/gnupg/issue1933 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 infinity0 at pwned.gg Fri Mar 27 11:38:36 2015 From: infinity0 at pwned.gg (Ximin Luo) Date: Fri, 27 Mar 2015 11:38:36 +0100 Subject: gpg 2.1 gpg-agent over ssh Message-ID: <5515332C.5080006@pwned.gg> When running gpg 2.1.2 over SSH with a secret-key operation, the gpg in the ssh client appears to hang. What is actually happening is that the gpg-agent it's connecting to, is running a pinentry that's associated with the display on the desktop session the *gpg-agent* is attached to, rather than the ssh client, and there's no way for the ssh user to reach this. $ pgrep -a gpg-agent 17902 gpg-agent --homedir /home/infinity0/.gnupg --use-standard-socket --daemon $ kill -HUP 17902 # flush all secret keys $ pgrep -af pinentry (exit 1) $ gpg2 -as < From infinity0 at pwned.gg Fri Mar 27 13:01:18 2015 From: infinity0 at pwned.gg (Ximin Luo) Date: Fri, 27 Mar 2015 13:01:18 +0100 Subject: gpg 2.1 gpg-agent over ssh In-Reply-To: <5515332C.5080006@pwned.gg> References: <5515332C.5080006@pwned.gg> Message-ID: <5515468E.4090402@pwned.gg> On 27/03/15 11:38, Ximin Luo wrote: > When running gpg 2.1.2 over SSH with a secret-key operation, the gpg in the ssh client appears to hang. > > What is actually happening is that the gpg-agent it's connecting to, is running a pinentry that's associated with the display on the desktop session the *gpg-agent* is attached to, rather than the ssh client, and there's no way for the ssh user to reach this. > > $ pgrep -a gpg-agent > 17902 gpg-agent --homedir /home/infinity0/.gnupg --use-standard-socket --daemon > $ kill -HUP 17902 # flush all secret keys > $ pgrep -af pinentry > (exit 1) > > $ gpg2 -as < test > EOF > > ^C > gpg: signal Interrupt caught ... exiting > > (exit 130) > (exit 130) > $ pgrep -af pinentry > 22048 > # this process sticks around and you need to kill it manually > What's worse - if you don't kill this process, subsequent attempts to use secret-key operations (even from the desktop session!) fail because I guess gpg-agent queues up pinentry operations, and it's waiting on this one. This wouldn't be obvious to most users. > But physically going back to the desktop session doesn't show a pinentry popup, for some reason. > > It's unclear the best way to solve this. Thoughts? > A workaround is to use `ssh -X`. I'm not sure if this translates into a solution for the original non-X case. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sat Mar 28 12:21:44 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 28 Mar 2015 12:21:44 +0100 Subject: gpg 2.1 gpg-agent over ssh In-Reply-To: <5515332C.5080006@pwned.gg> (Ximin Luo's message of "Fri, 27 Mar 2015 11:38:36 +0100") References: <5515332C.5080006@pwned.gg> Message-ID: <87sicpe59z.fsf@vigenere.g10code.de> On Fri, 27 Mar 2015 11:38, infinity0 at pwned.gg said: > What is actually happening is that the gpg-agent it's connecting to, > is running a pinentry that's associated with the display on the > desktop session the *gpg-agent* is attached to, rather than the ssh > client, and there's no way for the ssh user to reach this. Sure. If you want to switch your active X-server you need to tell it gpg-agent: gpg-connect-agent updatestartuptty /bye > $ pgrep -a gpg-agent > 17902 gpg-agent --homedir /home/infinity0/.gnupg --use-standard-socket --daemon > $ kill -HUP 17902 # flush all secret keys gpgconf --reload gpg-agent is easier ;-) > But physically going back to the desktop session doesn't show a pinentry popup, for some reason. It shows up there until it times out. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Sat Mar 28 12:40:32 2015 From: infinity0 at pwned.gg (Ximin Luo) Date: Sat, 28 Mar 2015 12:40:32 +0100 Subject: gpg 2.1 gpg-agent over ssh In-Reply-To: <87sicpe59z.fsf@vigenere.g10code.de> References: <5515332C.5080006@pwned.gg> <87sicpe59z.fsf@vigenere.g10code.de> Message-ID: <55169330.9020203@pwned.gg> On 28/03/15 12:21, Werner Koch wrote: > On Fri, 27 Mar 2015 11:38, infinity0 at pwned.gg said: > >> What is actually happening is that the gpg-agent it's connecting to, >> is running a pinentry that's associated with the display on the >> desktop session the *gpg-agent* is attached to, rather than the ssh >> client, and there's no way for the ssh user to reach this. > > Sure. If you want to switch your active X-server you need to tell it > gpg-agent: > > gpg-connect-agent updatestartuptty /bye > What is this supposed to do? Also, I don't *want* my SSH session to be associated with X. Ideally gpg-agent should pop up a pinentry-curses dialog box. $DISPLAY isn't even set. >> But physically going back to the desktop session doesn't show a pinentry popup, for some reason. > > It shows up there until it times out. > It doesn't, though. I am physically at both sessions at the same time. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From infinity0 at pwned.gg Sat Mar 28 12:42:49 2015 From: infinity0 at pwned.gg (Ximin Luo) Date: Sat, 28 Mar 2015 12:42:49 +0100 Subject: gpg 2.1 gpg-agent over ssh In-Reply-To: References: <5515332C.5080006@pwned.gg> <5515468E.4090402@pwned.gg> Message-ID: <551693B9.2030200@pwned.gg> (back to the list) No, it doesn't solve it. :( I am not sure why you think it would solve it... the man page says "Treat input files as text and store them in the OpenPGP canonical text form " which does not have anything to do with X or the lack of it or tty and consoles. X On 27/03/15 14:09, Jim Hansson wrote: > does not using --textmode solve the non-X case? > But should not the normal case when no DISPLAY variable is defined be --textmode, I think so, this sounds more looks like you have some weird setup, I will try to replicate it tonight. > > > On Fri, Mar 27, 2015 at 1:01 PM, Ximin Luo > wrote: > > On 27/03/15 11:38, Ximin Luo wrote: > > When running gpg 2.1.2 over SSH with a secret-key operation, the gpg in the ssh client appears to hang. > > > > What is actually happening is that the gpg-agent it's connecting to, is running a pinentry that's associated with the display on the desktop session the *gpg-agent* is attached to, rather than the ssh client, and there's no way for the ssh user to reach this. > > > > $ pgrep -a gpg-agent > > 17902 gpg-agent --homedir /home/infinity0/.gnupg --use-standard-socket --daemon > > $ kill -HUP 17902 # flush all secret keys > > $ pgrep -af pinentry > > (exit 1) > > > > $ gpg2 -as < > test > > EOF > > > > ^C > > gpg: signal Interrupt caught ... exiting > > > > (exit 130) > > (exit 130) > > $ pgrep -af pinentry > > 22048 > > # this process sticks around and you need to kill it manually > > > > What's worse - if you don't kill this process, subsequent attempts to use secret-key operations (even from the desktop session!) fail because I guess gpg-agent queues up pinentry operations, and it's waiting on this one. > > This wouldn't be obvious to most users. > > > But physically going back to the desktop session doesn't show a pinentry popup, for some reason. > > > > It's unclear the best way to solve this. Thoughts? > > > > A workaround is to use `ssh -X`. I'm not sure if this translates into a solution for the original non-X case. > > X > > -- > GPG: 4096R/1318EFAC5FBBDBCE > git://github.com/infinity0/pubkeys.git > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > > > > -- > // Jim Hansson > // Tel: 0722019664 > // http://se.linkedin.com/in/jimhansson > // ===== GPG ===== > // key: 9AA942ED > // Fingerprint: 6947 5F70 7D4E D55D FCE2 > // 3A1E 0C21 D543 9AA9 42ED > // =============== -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From jim.hansson at gmail.com Sat Mar 28 13:30:22 2015 From: jim.hansson at gmail.com (Jim Hansson) Date: Sat, 28 Mar 2015 13:30:22 +0100 Subject: gpg 2.1 gpg-agent over ssh In-Reply-To: <551693B9.2030200@pwned.gg> References: <5515332C.5080006@pwned.gg> <5515468E.4090402@pwned.gg> <551693B9.2030200@pwned.gg> Message-ID: sorry, miss-read your original message to be something like a display variable that was maybe pointing in the wrong direction. And mixed up the command line for gpg with another program so i was thinking --textmode was for forcing a textmode entry of passphrases. On Sat, Mar 28, 2015 at 12:42 PM, Ximin Luo wrote: > (back to the list) > > No, it doesn't solve it. :( > > I am not sure why you think it would solve it... the man page says "Treat > input files as text and store them in the OpenPGP canonical text form " > which does not have anything to do with X or the lack of it or tty and > consoles. > > X > > On 27/03/15 14:09, Jim Hansson wrote: > > does not using --textmode solve the non-X case? > > But should not the normal case when no DISPLAY variable is defined be > --textmode, I think so, this sounds more looks like you have some weird > setup, I will try to replicate it tonight. > > > > > > On Fri, Mar 27, 2015 at 1:01 PM, Ximin Luo infinity0 at pwned.gg>> wrote: > > > > On 27/03/15 11:38, Ximin Luo wrote: > > > When running gpg 2.1.2 over SSH with a secret-key operation, the > gpg in the ssh client appears to hang. > > > > > > What is actually happening is that the gpg-agent it's connecting > to, is running a pinentry that's associated with the display on the desktop > session the *gpg-agent* is attached to, rather than the ssh client, and > there's no way for the ssh user to reach this. > > > > > > $ pgrep -a gpg-agent > > > 17902 gpg-agent --homedir /home/infinity0/.gnupg > --use-standard-socket --daemon > > > $ kill -HUP 17902 # flush all secret keys > > > $ pgrep -af pinentry > > > (exit 1) > > > > > > $ gpg2 -as < > > test > > > EOF > > > > > > ^C > > > gpg: signal Interrupt caught ... exiting > > > > > > (exit 130) > > > (exit 130) > > > $ pgrep -af pinentry > > > 22048 > > > # this process sticks around and you need to kill it manually > > > > > > > What's worse - if you don't kill this process, subsequent attempts > to use secret-key operations (even from the desktop session!) fail because > I guess gpg-agent queues up pinentry operations, and it's waiting on this > one. > > > > This wouldn't be obvious to most users. > > > > > But physically going back to the desktop session doesn't show a > pinentry popup, for some reason. > > > > > > It's unclear the best way to solve this. Thoughts? > > > > > > > A workaround is to use `ssh -X`. I'm not sure if this translates > into a solution for the original non-X case. > > > > X > > > > -- > > GPG: 4096R/1318EFAC5FBBDBCE > > git://github.com/infinity0/pubkeys.git < > http://github.com/infinity0/pubkeys.git> > > > > > > _______________________________________________ > > Gnupg-devel mailing list > > Gnupg-devel at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > > > > > > > > > -- > > // Jim Hansson > > // Tel: 0722019664 > > // http://se.linkedin.com/in/jimhansson > > // ===== GPG ===== > > // key: 9AA942ED > > // Fingerprint: 6947 5F70 7D4E D55D FCE2 > > // 3A1E 0C21 D543 9AA9 42ED > > // =============== > > > -- > GPG: 4096R/1318EFAC5FBBDBCE > git://github.com/infinity0/pubkeys.git > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > -- // Jim Hansson // Tel: 0722019664 // http://se.linkedin.com/in/jimhansson // ===== GPG ===== // key: 9AA942ED // Fingerprint: 6947 5F70 7D4E D55D FCE2 // 3A1E 0C21 D543 9AA9 42ED // =============== -------------- next part -------------- An HTML attachment was scrubbed... URL: From albrecht.dress at arcor.de Sat Mar 28 15:19:54 2015 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Sat, 28 Mar 2015 15:19:54 +0100 Subject: [openpgp] Encrypting / Signing the mail subject? In-Reply-To: <87h9tcd7r2.fsf@alice.fifthhorseman.net> Message-ID: A non-text attachment was scrubbed... Name: not available Type: text/rfc822-headers Size: 522 bytes Desc: not available URL: -------------- next part -------------- Hi David: Sorry for replying so late, I've been packed with my ? work this week... :-/ Am 22.03.15 22:47 schrieb(en) Daniel Kahn Gillmor: > Hm, if the goal is human-friendliness, then we probably want to think about how to be even friendlier -- english text plus a URL to an en_US-only webpage isn't very nice to the majority of the world either :P Yes, that's of course correct! Werner already proposed to refer to a FAQ web page (which might offer a language selection), which is an excellent idea IMHO. My extra header field was just a proposition of something which /might/ be helpful for confused users of old MUA's which don't implement the new scheme... And, yes, I missed RFC 6648 which deprecates X-something headers - maybe a "Comments:" header might be used instead of it? > Alexey Melnikov just pointed me to this draft: > > https://tools.ietf.org/html/draft-melnikov-smime-header-signing-00 > > which has a similar mechanism (and is designed for S/MIME), and it refers to the same idea as a "stub value" Ah! That's interesting, I didn't know about the header protection mechanism of RFC 5751, sect. 3.1. Using a message/rfc822 instead of the extra text/rfc822-headers part is also an interesting idea. However, I think your proposal advantageous as the *only* use for the latter up to now seems to be the optional third part of a RFC 3462 multipart/report, whereas message/rfc822 is widely used afaict. Thus I believe it's easier to detect the "protected" part with your proposal. OTOH, it might be better to use the same scheme for s/mime *and* for pgp/mime as to avoid different implementations for the same goal in MUA's. Hmmm.... > PS i love the content type "text/pain" -- can we register that one officially, please? ;) Ouch. Might be a good one for spam (although it's mostly text/paintml these days... ;-) > Melnikov's draft proposes a content-type parameter "forwarded" to be used on the message/rfc822 element, to distinguish these cases. I haven't thought through the consequences of the way this his draft sets it up, though -- it seems possible to misinterpret the lack of a header from a non-compatible sender forwarding a message. To be honest, I am not sure if this is a good idea. As you already pointed out, older MUA's simply don't know about and thus omit it, which leads to perfect confusion. And I think it's not necessary if RFC 5751 would simply define that the "inner" protected message container *must* have the same Message-ID as the "outer" one. If anyone is concerned that this violates the requirement of uniqueness (RFC 5322, sect. 3.6.4), the inner container could have instead of the "Message-ID" (which is *not* required!) something like a "Protected-Message-ID" with the same value. If someone tampered with the "outer" message-id, the receiving MUA could still detect this case by the presence of the "Protected-Message-ID". This approach would *not* break compatibility with existing implementations. Best, Albrecht. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From neal at walfield.org Sat Mar 28 17:04:47 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 28 Mar 2015 17:04:47 +0100 Subject: LDAP Keyserver Support in v2.1 In-Reply-To: <2863364.FqMMkHcxJU@esus> References: <87a8z38r2b.wl%neal@walfield.org> <87oanh75q5.wl%neal@walfield.org> <55128C1A.7060001@sumptuouscapital.com> <2863364.FqMMkHcxJU@esus> Message-ID: <87ego96rc0.wl%neal@walfield.org> Hi Kristian, At Wed, 25 Mar 2015 17:34:11 +0100, Andre Heinecke wrote: > On Wednesday, March 25, 2015 11:21:14 AM Kristian Fiskerstrand wrote: > > it is discussed in the thread surrounding [0], known issue in 2.1... > > > > References: > > [0] http://lists.gnupg.org/pipermail/gnupg-devel/2014-December/029230.html > > I've opened an issue for this as known issues should have numbers. :-) > > https://bugs.g10code.com/gnupg/issue1933 I've now resolved the issue. This was a change in behavior in 2.1 (relative to 2.0 / 1.4) in which instead of taking the last specified key server, all key servers were used. I've now reverted this in f26ba14028d34845ae10aae552b90681907e377d. This fixes the test case for me. Neal From dkg at fifthhorseman.net Sat Mar 28 19:57:12 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 28 Mar 2015 14:57:12 -0400 Subject: [Enigmail] Paste passphrase from clipboard into pinentry dialogbox In-Reply-To: <5513361E.4010003@sixdemonbag.org> References: <55132B60.4090806@andre-lahmann.de> <55132C45.1000708@yanovich.net> <5513361E.4010003@sixdemonbag.org> Message-ID: <87lhiht0fr.fsf@alice.fifthhorseman.net> [redirecting to gnupg-devel, setting mail-followup-to: there] On Wed 2015-03-25 18:26:38 -0400, Robert J. Hansen wrote: >> My guess is that this is for added security. > > Correct. Werner Koch has said several times that he will not change the > code to permit C&P into the dialog box, as that would leave sensitive > data in your clipboard -- and the clipboard, by definition, can be read > by any application, including malware. If the only concern is leaving sensitive data in the clipboard after use, maybe pinentry could *accept* pastes, but then also clear the clipboard after it was pasted into? I understand that this still "encourages" people to put their passphrases into the clipboard, but that seems to be happening anyway. What if, upon accepting a paste, pinentry was to expand the dialog a bit and show a warning that says something like: Pasted! Your clipboard has also been emptied, so that your passphrase isn't exposed to other applications. GnuPG recommends never copying your passphrase to the clipboard. --dkg From wk at gnupg.org Sun Mar 29 16:07:14 2015 From: wk at gnupg.org (Werner Koch) Date: Sun, 29 Mar 2015 16:07:14 +0200 Subject: gpg 2.1 gpg-agent over ssh In-Reply-To: <55169330.9020203@pwned.gg> (Ximin Luo's message of "Sat, 28 Mar 2015 12:40:32 +0100") References: <5515332C.5080006@pwned.gg> <87sicpe59z.fsf@vigenere.g10code.de> <55169330.9020203@pwned.gg> Message-ID: <87619jdhil.fsf@vigenere.g10code.de> On Sat, 28 Mar 2015 12:40, infinity0 at pwned.gg said: > What is this supposed to do? Also, I don't *want* my SSH session to be > associated with X. Ideally gpg-agent should pop up a pinentry-curses > dialog box. $DISPLAY isn't even set. $ gpg-connect-agent 'help updatestartuptty' /bye # UPDATESTARTUPTTY # # Set startup TTY and X11 DISPLAY variables to the values of this # session. This command is useful to pull future pinentries to # another screen. It is only required because there is no way in the # ssh-agent protocol to convey this information. OK Thus it is for X and curses. > It doesn't, though. I am physically at both sessions at the same time. I don't know. You may want to install a wrapper pinentry to see what's going on. Something like this: --8<---------------cut here---------------start------------->8--- #!/bin/sh printenv >/tmp/pinentry.env #exec strace -o /tmp/pinentry.trc -e read=0 /usr/local/bin/pinentry-gtk-2 -e -d "$@" 2>/tmp/pinentry.err exec /usr/local/bin/pinentry-gtk-2 "$@" --8<---------------cut here---------------end--------------->8--- Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Sun Mar 29 16:29:07 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 29 Mar 2015 10:29:07 -0400 Subject: windows 2.1.2 binary? Message-ID: <874mp3ubbg.fsf@alice.fifthhorseman.net> Hi folks-- ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.1_20141216.exe is apparently a windows binary for 2.1.1, but there is no comparable windows binary released for 2.1.2. This has caused some confusion/failure for users, as noted here: https://sourceforge.net/p/enigmail/bugs/465/ I wonder if it's possible to either add an equivalent 2.1.2 to ftp.gnupg.org, or to remove or mark the 2.1.1 as deprecated. (or maybe, if the answer is "use gpg4win", to provide a gnupg-w32-2.1.2.txt that says "Please use gpg4win" or something like that) --dkg From guilhem at fripost.org Mon Mar 30 14:07:38 2015 From: guilhem at fripost.org (Guilhem Moulin) Date: Mon, 30 Mar 2015 14:07:38 +0200 Subject: GnuPG 2.1.2 making tons of syscalls (was: Benchmarking key listing: pubring.kbx vs pubring.gpg, 1.4 vs 2.1) In-Reply-To: <20150225091420.GA2052@localhost> References: <20150225091420.GA2052@localhost> Message-ID: <20150330120738.GA10435@localhost> On Wed, 25 Feb 2015 at 10:14:20 +0100, Guilhem Moulin wrote: > $ time gpg --homedir /tmp/gnupg1 --list-sigs >/dev/null > 1:57.54 (83.55 user, 33.57 sys) 9264k maxres > $ time gpg2 --homedir /tmp/gnupg2 --list-sigs >/dev/null > 2:24:34 (564.61 user, 8083.49 sys) 14936k maxres > [?] > The second timming is really odd: over 2h of system time? Surely it > must be a bug. > [?] > $ time gpg --homedir /tmp/gnupg1 --list-sigs 0x39278DA8109E6244 >/dev/null > 0:17.24 (11.72 user, 5.46 sys) 8852k maxres > $ time gpg2 --homedir /tmp/gnupg2 --list-sigs 0x39278DA8109E6244 >/dev/null > 0:30.85 (3.26 user, 27.50 sys) 14564k maxres Doesn't anyone acknowledge this behavior and the fact that it's a bug? I can't believe all these syscalls are intended, somehow. Incidentally, Jesus Cea made a similar observation (with 2.0.27) when updating the trustdb: http://lists.gnupg.org/pipermail/gnupg-users/2015-March/053343.html -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From brian at minton.name Mon Mar 30 19:39:02 2015 From: brian at minton.name (Brian Minton) Date: Mon, 30 Mar 2015 13:39:02 -0400 Subject: GPGHOME in make test Message-ID: When trying to run make test from the latest git (f26ba14028d34845ae10aae552b90681907e377d), I got a bunch of test failures with the message "GNUPGHOME not set to the cwd". Am I doing something wrong? Or is this a bug, in which case I can submit a bug report. From neal at walfield.org Tue Mar 31 20:26:48 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 31 Mar 2015 20:26:48 +0200 Subject: TOFU - motivation Message-ID: <87bnj9f2fr.wl-neal@walfield.org> Hi, I'm thinking about how to implement trust on first use (TOFU) in GnuPG. In this note, I want to lay the ground work. This is probably uncontroversial, but I think it is important to state it explicitly. TOFU is good for checking an association between an identity (in our case, an email address) and a key. The idea is the following. The first time that we observe a message from a particular email address, we record the email and the key. After that, each time we receive a message, we check that the same key is used. If not, then we issue a warning and the user can decide what to do. There are a few reasons that the key associated with an email address could change. First, the user may have a new (or another) key. In this case, we want to associate all valid keys with the address. Second, there is an active MITM attack. TOFU can detect this if the MITM is not always successful. Finally, the from line was faked and a different key was used to sign the message. TOFU can also reliably detect this. In all three cases, the user may not realize what happened if TOFU is not used. There are two convincing reasons to implement TOFU in GnuPG and not in the user's MUA. First, we want to preserve the trust database even if the user changes MUAs. This is significantly easier if all MUAs use the same infrastructure. Second, we want to reduce the burden on the MUA authors. If the MUA authors implement all the infrastructure themselves, then there will be N implementations. If GnuPG implements it, there will be just one and each MUA will need to interface with GnuPG, which is probably significantly easier. Implementing the logic in GnuPG has a small trade-off: it's not quite the right level of abstraction. That is, it is probably easier to implement TOFU in an MUA. For instance, if there is a mismatch, the MUA should dialog asking the user what to do. This requires that GnuPG make an upcall to the MUA. However, the previous arguments are stronger. Neal From calestyo at scientia.net Tue Mar 31 21:14:05 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Tue, 31 Mar 2015 21:14:05 +0200 Subject: TOFU - motivation In-Reply-To: <87bnj9f2fr.wl-neal@walfield.org> References: <87bnj9f2fr.wl-neal@walfield.org> Message-ID: <1427829245.17032.41.camel@scientia.net> On Tue, 2015-03-31 at 20:26 +0200, Neal H. Walfield wrote: > I'm thinking about how to implement trust on first use (TOFU) in > GnuPG. In this note, I want to lay the ground work. This is probably > uncontroversial, but I think it is important to state it explicitly. Actually TOFU can be quite controversially discussed. Especially since TOFU *if at all* has just benefits for "improving" security of anonymous communication. It would completely break the security of things like package signature verification, if any new keys would be trusted on first use. If anything special for this should be implemented in GnuPG, it shouldn't become default in order not to break expected behaviour. > TOFU is good for checking an association between an identity (in our > case, an email address) Actually, the identity should typically be the name and less the address, since the later can change at any time, in many cases even if the owner doesn't want to. > and a key. The idea is the following. The > first time that we observe a message from a particular email address, > we record the email and the key. After that, each time we receive a > message, we check that the same key is used. If not, then we issue a > warning and the user can decide what to do. I don't see much difference to current behaviour. What your scenario misses (or silently assumes) is the "T" in TOFU, i.e. the "Trust". Trust, in GnuPG is typically gained by signing another key (well not exactly but usually the two are connected). And I defenitely wouldn't want to have any other keys signed nor trusted just because and email with them pops up. But *if* you seriously consider that to be desirable (and notice that it would be even weaker than X.509's strict hierarchical PKI, since in that case you may trust keys/IDs for which *no* verification has been made at all - in contrast to X.509 where at least "something" is claimed to be done by the CAs)... than nothing keeps you from doing it now in GPG. Just sign and/or trust every public key as soon as you encounter it. > Second, there is an active MITM attack. TOFU can detect this if the > MITM is not always successful. But TOFU can generally not attack when the MitM runs from the beginning on, which is the weak point on it, making it basically fully anonymously authenticated. > There are two convincing reasons to implement TOFU Hehe "convincin" and "TOFU" are for me mutually exclusive ;) > in GnuPG and not in > the user's MUA. As said before, this would break the security assumptions of countless of programs relying on GnuPG providing strong and authenticated (in contrast to anonymously authenticated) security. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue Mar 31 21:51:35 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 31 Mar 2015 15:51:35 -0400 Subject: TOFU - motivation In-Reply-To: <87bnj9f2fr.wl-neal@walfield.org> References: <87bnj9f2fr.wl-neal@walfield.org> Message-ID: <551AFAC7.3020805@sixdemonbag.org> > I'm thinking about how to implement trust on first use (TOFU) in > GnuPG. Don't. Seriously. GnuPG is a toolbox. TOFU is a policy. Keep 'em separated and everyone will be happier. That isn't to say you can't do TOFU, just don't expect people to be cheerful about the prospect of putting policy into GnuPG. > TOFU is good for checking an association between an identity (in our > case, an email address) and a key. This handwaves "identity". I'll go so far as to say that I don't consider an email address to be an identity -- there's absolutely no assurance that it identifies a specific person. That doesn't make TOFU a bad idea. In certain contexts it makes a lot of sense. But let's not oversell it by claiming TOFU checks associations between identities and certificates. > There are two convincing reasons to implement TOFU in GnuPG and not in > the user's MUA. I'm completely unconvinced. > First, we want to preserve the trust database even if > the user changes MUAs. No, we don't. One email system might be TOFU, and another email system might require strong identity checks. Or what about the case of two TOFU systems: should system A be required to trust the certificates entered by system B? They're both writing to the same GnuPG trust DB, after all. This is why we don't do policy in GnuPG. :) > Second, we want to reduce the burden on the MUA authors. We want to reduce *unnecessary* burden. But if you're establishing policy, then it's up to you to develop tools to support that policy. :) > Implementing the logic in GnuPG has a small trade-off: it's not quite > the right level of abstraction. Correct. It's not the right level to solve it at. > For instance, if there is a mismatch, the > MUA should dialog asking the user what to do. This requires that > GnuPG make an upcall to the MUA. As it currently stands, TOFU would (should) be done at the MUA level. When the MUA receives a message, it can call GnuPG to discover the certificate used for signing. If the certificate used is not what the MUA expects, it can ask the dialog what to do: no upcall required. In other words, you're assuming the existence of a TOFU-aware GnuPG as a justification for why we need a TOFU-aware GnuPG. That's just not going to fly. :) -------------- 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 Mar 31 21:58:29 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 31 Mar 2015 15:58:29 -0400 Subject: TOFU - motivation In-Reply-To: <87bnj9f2fr.wl-neal@walfield.org> References: <87bnj9f2fr.wl-neal@walfield.org> Message-ID: <878uedhrbu.fsf@alice.fifthhorseman.net> Hi Neal-- Thanks for this thought-provoking suggestion. I've tried to think this through more concretely, and written up my thoughts below. I'm not prepared to drive this project, but i agree that it could be valuable for the GnuPG community if it was done right. On Tue 2015-03-31 14:26:48 -0400, Neal H. Walfield wrote: > I'm thinking about how to implement trust on first use (TOFU) in > GnuPG. In this note, I want to lay the ground work. This is probably > uncontroversial, but I think it is important to state it explicitly. > > TOFU is good for checking an association between an identity (in our > case, an email address) and a key. The idea is the following. The > first time that we observe a message from a particular email address, > we record the email and the key. After that, each time we receive a > message, we check that the same key is used. If not, then we issue a > warning and the user can decide what to do. > > There are a few reasons that the key associated with an email address > could change. First, the user may have a new (or another) key. In > this case, we want to associate all valid keys with the address. > Second, there is an active MITM attack. TOFU can detect this if the > MITM is not always successful. Finally, the from line was faked and a > different key was used to sign the message. TOFU can also reliably > detect this. In all three cases, the user may not realize what > happened if TOFU is not used. > > There are two convincing reasons to implement TOFU in GnuPG and not in > the user's MUA. First, we want to preserve the trust database even if > the user changes MUAs. This is significantly easier if all MUAs use > the same infrastructure. Second, we want to reduce the burden on the > MUA authors. If the MUA authors implement all the infrastructure > themselves, then there will be N implementations. If GnuPG implements > it, there will be just one and each MUA will need to interface with > GnuPG, which is probably significantly easier. I think this responsibility should be shared between the MUA and GnuPG. GnuPG manages the keyring, and should therefore record the state of the TOFU data. the MUA interfaces with the user and with the user's mail store, and should know how to tell GnuPG about these TOFU transitions simply. The devil is in the details, though. TOFU about what? ================ We have to be clear what we think TOFU is about: is it related to an e-mail address or to a User ID? If it were a full User ID, and you received mail from "John Smith " then i could trick you into accepting a new key for "John Q Smith " and your system would be no wiser. So i think we're talking about a TOFU mapping from an e-mail addresses to a primary key. Right? How to get there ================ If we want to do this effectively, we need to make sure that all users of GnuPG understand how TOFU-style annotation, insertion, and update should work. This is probably work that needs doing at two levels within the GnuPG project itself: 0) figure out how TOFU assertions should be stored by GnuPG 1) figure out if GnuPG should offer any more-convenient interface to set and update these assertions (this would facilitate work by consumers of the GnuPG interface) 0 seems like the easier job to me, so i'll start there: Storing e-mail TOFU assertions in the keyring ============================================= I think the way to store this sort of thing internally would be non-exportable certifications (possibly issued by a dedicated key) marked with a particular OpenPGP notation to indicate that they're from this TOFU approach. OpenPGP Notations: https://tools.ietf.org/html/rfc4880#section-5.2.3.16 This leaves a few relatively simple questions still unanswered: a) what name/value should the notation have? tofu at gnupg.org seems plausible for the name, if werner is ok with it. I'm not sure what we'd need in the value here. maybe a version of the TOFU scheme, just in case there's a revision to this later? b) what "cert-level" should this use? I tend to believe that cert-levels are not useful, and are possibly dangerous [0], so i recommend using generic certification (0x10). Alternately, this could be one case (maybe the only case) where cert-levels could actually find a use: if these TOFU certifications were all done with "persona certification" (0x11), and gpg could be configured to believe or not believe this level of certification from a given key, this could help to keep TOFU certifications out of accidental/normal use. c) should the notation be marked as critical or not? I tend to think it should be marked as critical to avoid other systems importing or relying on these certifications without understanding the nature of the TOFU approach. Additional e-mail TOFU interfaces ================================= here are some proposed TOFU interfaces that gpg could provide: Options: gpg --email-tofu-issuer $KEYFPR gpg --no-email-tofu These options would turn on (or off) TOFU support, using $KEYFPR as the issuer of all internal TOFU signatures. Commands: gpg --email-tofu-seen $EMAIL $KEYFPR If gpg already thinks that $KEYFPR is valid for a user ID that maps to $EMAIL, then this returns 0 ("everything is OK") and terminates. If --no-email-tofu is set, this returns 1 ("email tofu not configured") and terminates. If there is some other key that is valid for any User ID that maps to $EMAIL, this returns 1 ("unable to associate"). This is a signal to the higher-level system that it should trigger whatever it thinks best for disambiguation (maybe refresh from keyservers, log the problem, or punt to the user for confirmation?) If no key is already valid for any User ID that maps to $EMAIL, gpg should craft a TOFU certification (see above) and return 0 ("association mapped"). I think this is the minimal interface that we'd want to expose, and i think that higher-level tools could make sense of it. Tools that want to use TOFU in a key selection sense would just use the standard gpg key selection mechanism of "" (though maybe we'd want to improve that search mechanism by ensuring that matching keys are returned in order of highest-uid-validity). I'd love to hear feedback on this, or what sort of use cases it might miss. --dkg [0] https://www.debian-administration.org/users/dkg/weblog/98 From dkg at fifthhorseman.net Tue Mar 31 22:04:34 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 31 Mar 2015 16:04:34 -0400 Subject: TOFU - motivation In-Reply-To: <878uedhrbu.fsf@alice.fifthhorseman.net> References: <87bnj9f2fr.wl-neal@walfield.org> <878uedhrbu.fsf@alice.fifthhorseman.net> Message-ID: <87619hhr1p.fsf@alice.fifthhorseman.net> On Tue 2015-03-31 15:58:29 -0400, Daniel Kahn Gillmor wrote: > How to get there > ================ > > If we want to do this effectively, we need to make sure that all users > of GnuPG understand how TOFU-style annotation, insertion, and update > should work. > > This is probably work that needs doing at two levels within the GnuPG > project itself: > > 0) figure out how TOFU assertions should be stored by GnuPG > > 1) figure out if GnuPG should offer any more-convenient interface to > set and update these assertions (this would facilitate work by > consumers of the GnuPG interface) I should follow up here to point out that pretty much all of the above seems possible to do today, maybe with the exception of accepting the use of persona certifications. It's probably not done more widely because: a) doing this in an automated way is pretty clunky at the moment. b) there's no common way to do it, which means that tools which share the gpg keyring for e-mail don't have a common convention on how to collaborate in such a TOFU scheme. embedding these features to gpg itself would address these two caveats somewhat, and could make for a more usable (and portable) mechanism. --dkg From rjh at sixdemonbag.org Tue Mar 31 22:15:01 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 31 Mar 2015 16:15:01 -0400 Subject: TOFU - motivation In-Reply-To: <87619hhr1p.fsf@alice.fifthhorseman.net> References: <87bnj9f2fr.wl-neal@walfield.org> <878uedhrbu.fsf@alice.fifthhorseman.net> <87619hhr1p.fsf@alice.fifthhorseman.net> Message-ID: <551B0045.40403@sixdemonbag.org> > b) there's no common way to do it, which means that tools which > share the gpg keyring for e-mail don't have a common convention on > how to collaborate in such a TOFU scheme. Or even if they *want* to collaborate. It's easy for me to imagine a setup where application A doesn't trust the certifications-of-use made by application B. Imagine that you've got AmeriTrade and E*Trade (two major online stock brokerages here in the U.S.). They both need to communicate with oversight at sec.gov. However, neither one of them might be willing to trust an introduction to oversight at sec.gov made by the other one, even if both apps exist on the same user's computer. "Screw this, I'll only trust oversight at sec.gov if *I'm* the one putting it in the DB!" The Web of Trust handles this by allowing people to decide their own trusted introducers. But for system-wide TOFU, *every* application with write access to the DB is a trusted introducer. That doesn't sit well with me. It really gives me the heebie-jeebies, to be honest. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Mar 31 22:21:12 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 31 Mar 2015 16:21:12 -0400 Subject: TOFU - motivation In-Reply-To: <878uedhrbu.fsf@alice.fifthhorseman.net> References: <87bnj9f2fr.wl-neal@walfield.org> <878uedhrbu.fsf@alice.fifthhorseman.net> Message-ID: <551B01B8.7020804@sixdemonbag.org> > GnuPG manages the keyring, and should therefore record the state of > the TOFU data. I have nothing against this idea. Storing data is sensible (we already do that, so it's hard to argue we shouldn't do that). > I think the way to store this sort of thing internally would be > non-exportable certifications (possibly issued by a dedicated key) > marked with a particular OpenPGP notation to indicate that they're > from this TOFU approach. Also store the providing application, so that apps can make informed decisions about whether to trust other applications' TOFU entries. > b) what "cert-level" should this use? I tend to believe that > cert-levels are not useful, and are possibly dangerous [0] Completely agreed, but that's a total rant on my part -- ask me about it sometime, though, if you want to see me get thoroughly irritated. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From neal at walfield.org Tue Mar 31 22:28:33 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 31 Mar 2015 22:28:33 +0200 Subject: TOFU - motivation In-Reply-To: <1427829245.17032.41.camel@scientia.net> References: <87bnj9f2fr.wl-neal@walfield.org> <1427829245.17032.41.camel@scientia.net> Message-ID: <877ftwgbda.wl-neal@walfield.org> Hi Christoph, Thanks for your comments. At Tue, 31 Mar 2015 21:14:05 +0200, Christoph Anton Mitterer wrote: > > On Tue, 2015-03-31 at 20:26 +0200, Neal H. Walfield wrote: > > I'm thinking about how to implement trust on first use (TOFU) in > > GnuPG. In this note, I want to lay the ground work. This is probably > > uncontroversial, but I think it is important to state it explicitly. > Actually TOFU can be quite controversially discussed. I guess I wasn't clear. I realize that TOFU is controversial. What I was trying to say is: under the assumption that we want TOFU, my claim was that the rest of my message is rather uncontroversial (but perhaps that is not the case :). > Especially since TOFU *if at all* has just benefits for "improving" > security of anonymous communication. > It would completely break the security of things like package signature > verification, if any new keys would be trusted on first use. > > If anything special for this should be implemented in GnuPG, it > shouldn't become default in order not to break expected behaviour. Absolutely. It is not intended that TOFU become the default trust model. However, I think that for casual users, TOFU can provide a benefit. It certainly provides a benefit for OpenSSH. > > TOFU is good for checking an association between an identity (in our > > case, an email address) > Actually, the identity should typically be the name and less the > address, since the later can change at any time, in many cases even if > the owner doesn't want to. I'm not convinced that names are the right identifier. It's true that email addresses can change, but names are definately not unique. > > and a key. The idea is the following. The > > first time that we observe a message from a particular email address, > > we record the email and the key. After that, each time we receive a > > message, we check that the same key is used. If not, then we issue a > > warning and the user can decide what to do. > I don't see much difference to current behaviour. > What your scenario misses (or silently assumes) is the "T" in TOFU, i.e. > the "Trust". What we are trying to do is identify inconsistencies in time. This is more than we can do without signatures. Clearly, direct verification is better, but, for many users, getting signatures is too much of a burden. We are looking for a middle ground. > Trust, in GnuPG is typically gained by signing another key (well not > exactly but usually the two are connected). > And I defenitely wouldn't want to have any other keys signed nor trusted > just because and email with them pops up. > > But *if* you seriously consider that to be desirable (and notice that it > would be even weaker than X.509's strict hierarchical PKI, since in that > case you may trust keys/IDs for which *no* verification has been made at > all - in contrast to X.509 where at least "something" is claimed to be > done by the CAs)... than nothing keeps you from doing it now in GPG. > Just sign and/or trust every public key as soon as you encounter it. The TOFU stuff is orthogonal to the web of trust. When we see a key for the first time and the user acks it, then we don't generate a signature. > > Second, there is an active MITM attack. TOFU can detect this if the > > MITM is not always successful. > But TOFU can generally not attack when the MitM runs from the beginning > on, which is the weak point on it, making it basically fully anonymously > authenticated. Yes, I said this, but you have said it more explicitly. Thanks, Neal From dkg at fifthhorseman.net Tue Mar 31 22:30:53 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 31 Mar 2015 16:30:53 -0400 Subject: TOFU - motivation In-Reply-To: <551B01B8.7020804@sixdemonbag.org> References: <87bnj9f2fr.wl-neal@walfield.org> <878uedhrbu.fsf@alice.fifthhorseman.net> <551B01B8.7020804@sixdemonbag.org> Message-ID: <87zj6shptu.fsf@alice.fifthhorseman.net> On Tue 2015-03-31 16:21:12 -0400, Robert J. Hansen wrote: >> I think the way to store this sort of thing internally would be >> non-exportable certifications (possibly issued by a dedicated key) >> marked with a particular OpenPGP notation to indicate that they're >> from this TOFU approach. > > Also store the providing application, so that apps can make informed > decisions about whether to trust other applications' TOFU entries. perhaps this is the value that should be stored in the cert-notation? --dkg