From wk at gnupg.org  Fri Jul  1 17:13:18 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 01 Jul 2016 17:13:18 +0200
Subject: gpg's new --import-filter and --export-filter options
Message-ID: <87oa6hqtm9.fsf@wheatstone.g10code.de>

Hi!

I just pushed some code to implement a framework for filtering packets
during import and export.   Say you have a file with a key and you want
to strip it down so that it has only one user id.  This can even be done
without the need to store and later delete the key from the keyring:

  gpg --no-options --import-options import-export       \
      --import-filter keep-uid='mbox = joe at example.org' \
      --import  < full-key.pub > key-with-one-uid.pub

the notable features are

  - "import-export" which writes the key to stdout instead of storing it
     in the keyring.

  - "--import-filter TYPE=EXPR" which does the actual filtering.

Wiithout "import-export" the key would be imported with only the given
user id (it might get merged with an ecxisting one, though).  If you
want to import more user IDs you could change the value of
--import-filter for example to

   keep-uid='mbox =~ @example.org' 

to keep all user ids with that domain in the addr-spec, or
  
   keep-uid='mbox !~ @example.org && mbox !~ @example.net' 

to import all user ids except for those from that two example domains.

The export filter works similar.  The filter options and their
properties are described in the man page ("uid" and "mbox" - "primary
does not yet work correctly).  The description of the expression syntax
is not yet in the man page but below you will find the respective source
code comment.


Shalom-Salam,

   Werner


===========
/* Parse an expression.  The expression syntax is:
 *
 *   [<lc>] {{<flag>} PROPNAME <op> VALUE [<lc>]}
 *
 * A [] indicates an optional part, a {} a repetition.  PROPNAME and
 * VALUE may not be the empty string.  White space between the
 * elements is ignored.  Numerical values are computed as long int;
 * standard C notation applies.  <lc> is the logical connection
 * operator; either "&&" for a conjunction or "||" for a disjunction.
 * A conjunction is assumed at the begin of an expression and
 * conjunctions have higher precedence than disjunctions.  If VALUE
 * starts with one of the characters used in any <op> a space after
 * the <op> is required.  A VALUE is terminated by an <lc> unless the
 * "--" <flag> is used in which case the VALUE spans to the end of the
 * expression.  <op> may be any of
 *
 *   =~  Substring must match
 *   !~  Substring must not match
 *   =   The full string must match
 *   <>  The full string must not match
 *   ==  The numerical value must match
 *   !=  The numerical value must not match
 *   <=  The numerical value of the field must be LE than the value.
 *   <   The numerical value of the field must be LT than the value.
 *   >=  The numerical value of the field must be GT than the value.
 *   >=  The numerical value of the field must be GE than the value.
 *   -n  True if value is not empty (no VALUE parameter allowed).
 *   -z  True if value is empty     (no VALUE parameter allowed).
 *   -t  Alias for "PROPNAME != 0"  (no VALUE parameter allowed).
 *   -f  Alias for "PROPNAME == 0"  (no VALUE parameter allowed).
 *
 * Values for <flag> must be space separated and any of:
 *
 *   --  VALUE spans to the end of the expression.
 *   -c  The string match in this part is done case-sensitive.
 *
 * For example four calls to recsel_parse_expr() with these values for
 * EXPR
 *
 *  "uid =~ Alfa"
 *  "&& uid !~ Test"
 *  "|| uid =~ Alpha"
 *  "uid !~ Test"
 *
 * or the equivalent expression
 *
 *  "uid =~ Alfa" && uid !~ Test" || uid =~ Alpha" && "uid !~ Test"
 *
 * are making a selector for records where the "uid" property contains
 * the strings "Alfa" or "Alpha" but not the String "test".

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From tomastrnka at gmx.com  Sun Jul  3 21:27:31 2016
From: tomastrnka at gmx.com (=?utf-8?B?VG9tw6HFoQ==?= Trnka)
Date: Sun, 03 Jul 2016 21:27:31 +0200
Subject: [libksba PATCH] Encode OCSP nonce value as an octet string (RFC 6960)
Message-ID: <2972767.SifToO5Cpo@merope>

* src/ocsp.c (ksba_ocsp_set_nonce): Stop removing the sign bit.
 (write_request_extensions): Encode nonce as octet string.
 (parse_response_extensions): Decode nonce as octet string.

Signed-off-by: Tom?? Trnka <tomastrnka at gmx.com>
--
The type of nonce value was not specified back in RFC 2560, but RFC
6960 has clarified the situation by requiring an octet string. This
is also what OpenSSL does since 0.9.7d. Doing the same improves
interoperability with some responders (and Wireshark packet dissectors).
---
 src/ocsp.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/src/ocsp.c b/src/ocsp.c
index 56d2b55..4b26f8d 100644
--- a/src/ocsp.c
+++ b/src/ocsp.c
@@ -401,10 +401,6 @@ ksba_ocsp_set_nonce (ksba_ocsp_t ocsp, unsigned char *nonce, size_t noncelen)
   if (noncelen)
     {
       memcpy (ocsp->nonce, nonce, noncelen);
-      /* Reset the high bit.  We do this to make sure that we have a
-         positive integer and thus we don't need to prepend a leading
-         zero which would be needed then. */
-      ocsp->nonce[0] &= 0x7f;
     }
   ocsp->noncelen = noncelen;
   return noncelen;
@@ -492,7 +488,7 @@ write_request_extensions (ksba_ocsp_t ocsp, ksba_writer_t wout)
     err = _ksba_ber_write_tl (w1, TYPE_OCTET_STRING, CLASS_UNIVERSAL, 0,
                               2+ocsp->noncelen);
   if (!err)
-    err = _ksba_ber_write_tl (w1, TYPE_INTEGER, CLASS_UNIVERSAL, 0,
+    err = _ksba_ber_write_tl (w1, TYPE_OCTET_STRING, CLASS_UNIVERSAL, 0,
                               ocsp->noncelen);
   if (!err)
     err = ksba_writer_write (w1, ocsp->nonce, ocsp->noncelen);
@@ -907,7 +903,7 @@ parse_response_extensions (ksba_ocsp_t ocsp,
         goto leave;
       if (!strcmp (oid, oidstr_ocsp_nonce))
         {
-          err = parse_integer (&data, &datalen, &ti);
+          err = parse_octet_string (&data, &datalen, &ti);
           if (err)
             goto leave;
           if (ocsp->noncelen != ti.length
-- 
2.7.4

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2214 bytes
Desc: not available
URL: </pipermail/attachments/20160703/dfaf02d2/attachment.bin>

From tomastrnka at gmx.com  Sun Jul  3 21:34:03 2016
From: tomastrnka at gmx.com (=?utf-8?B?VG9tw6HFoQ==?= Trnka)
Date: Sun, 03 Jul 2016 21:34:03 +0200
Subject: [RFC PATCH] dirmngr: Try to recognize user-daemon mode
Message-ID: <1843343.drc1yOrXTc@merope>

* dirmngr/dirmngr.c (main): Detect user-daemon mode

Signed-off-by: Tom?? Trnka <tomastrnka at gmx.com>
--
Dirmngr needs to tell when it is started as an user daemon through
start_new_dirmngr(), in order to switch off code paths specific for
the systemwide case (internal OCSP validation, root-only remote
control etc.)

There's no reliable indication of the user-daemon mode, but
start_new_dirmngr() currently uses the combination of --daemon and
(hopefully) default --homedir. Let's thus make dirmngr understand
that for now.

Of course this is a horrible hack, it would be best to solve this by
introducing a new --user-daemon option, by signalling it through an
environment variable or something like that.
---
 dirmngr/dirmngr.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c
index 7e629db..7ba176c 100644
--- a/dirmngr/dirmngr.c
+++ b/dirmngr/dirmngr.c
@@ -716,6 +716,7 @@ main (int argc, char **argv)
   int rc;
   int homedir_seen = 0;
   struct assuan_malloc_hooks malloc_hooks;
+  char *abs_homedir;
 
   early_system_init ();
 
@@ -868,7 +869,17 @@ main (int argc, char **argv)
       socket_name = dirmngr_sys_socket_name ();
     }
   else if (dirmngr_user_socket_name ())
-    socket_name = dirmngr_user_socket_name ();
+    {
+      socket_name = dirmngr_user_socket_name ();
+
+      /* The combination of --daemon and --homedir $default_homedir
+         indicates we're being started as a user daemon by other GnuPG
+         components. Let's turn off special system-daemon behavior. */
+      abs_homedir = make_absfilename (default_homedir (), NULL);
+      if (strcmp(opt.homedir, abs_homedir) == 0)
+        opt.system_daemon = 0;
+      xfree (abs_homedir);
+    }
   else
     socket_name = dirmngr_sys_socket_name ();
 
-- 
2.7.4

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2214 bytes
Desc: not available
URL: </pipermail/attachments/20160703/ba2a762a/attachment.bin>

From joakim.lundborg at gmail.com  Mon Jul  4 12:02:42 2016
From: joakim.lundborg at gmail.com (Joakim Lundborg)
Date: Mon, 04 Jul 2016 12:02:42 +0200
Subject: Detecting and flushing cached pin in gpg-agent from gpgme
Message-ID: <1467626562.32378.4@smtp.gmail.com>

Hi,

I'm building a GUI password manager [1] based on gpg and password-store 
[2]  formatted entries. I'm using gpgme to interact with gpg, and it 
works just fine.

Now I would like to improve my app by giving the user an indication of 
whether or not the password for the gpg key used for encrypting the 
passwords is currently cached in gpg-agent. I also would like to flush 
this cache programmatically when the user is done, to keep things 
secure.

I couldn't find APIs for this in gpgme or in gpg, unless I'm missing 
something. For flushing, it seems to be possible to use send HUP 
signals to the gpg-agent process, but this seems a bit brutal, and is 
also reported to not work [4]

I have also found the documentation for gpg-connect-agent [3], which 
allows some level of control. This documentation seems a bit incomplete 
though, for example the following, which I also found in [4] works, but 
is not documented:

echo RELOADAGENT | gpg-connect-agent

Is there a recommended way of doing any of these things?

[1] https://github.com/cortex/gopass
[2] https://www.passwordstore.org/
[3] 
https://www.gnupg.org/documentation/manuals/gnupg/Controlling-gpg_002dconnect_002dagent.html#Controlling-gpg_002dconnect_002dagent





From wk at gnupg.org  Mon Jul  4 12:37:00 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 04 Jul 2016 12:37:00 +0200
Subject: Detecting and flushing cached pin in gpg-agent from gpgme
In-Reply-To: <1467626562.32378.4@smtp.gmail.com> (Joakim Lundborg's message of
 "Mon, 04 Jul 2016 12:02:42 +0200")
References: <1467626562.32378.4@smtp.gmail.com>
Message-ID: <87a8hxlmer.fsf@wheatstone.g10code.de>

On Mon,  4 Jul 2016 12:02, joakim.lundborg at gmail.com said:

> Now I would like to improve my app by giving the user an indication of
> whether or not the password for the gpg key used for encrypting the
> passwords is currently cached in gpg-agent. I also would like to flush

That can only be an estimation but it is possible:

  gpg-connect-agent 'help keyinfo' /bye

which outputs a line

  #  KEYINFO <keygrip> <type> <serialno> <idstr> <cached> <protection> <fpr>
  [...]
  # CACHED is 1 if the passphrase for the key was found in the key cache.
  #        If not, a '-' is used instead.

> I couldn't find APIs for this in gpgme or in gpg, unless I'm missing

You can directly connect to gpg-agent.  Use gpa/src/cardman.c as an
example:

  err = gpgme_new (&cardman->gpgagent);
  if (err)
    gpa_gpgme_error (err);

  err = gpgme_set_protocol (cardman->gpgagent, GPGME_PROTOCOL_ASSUAN);
  if (err)
    {
      if (gpg_err_code (err) == GPG_ERR_INV_VALUE)
        gpa_window_error (_("The GPGME library is too old to "
                            "support smartcards."), NULL);
      else
        gpa_gpgme_warning (err);
      gpgme_release (cardman->gpgagent);
      cardman->gpgagent = NULL;
    }

You run commands this way:

  if (!gpgme_op_assuan_transact_ext (cardman->gpgagent,
                                     "SCD RESTART",
                                     NULL, NULL, NULL, NULL,
                                     NULL, NULL, &operr)

In this example the gpg-agent is asked to send scdaemon a restart
command.  Unfortunately we do not have documentation for this API, thus
I can for now only refer to gpa as an example and looking into the code
of gpgme (gpgme/src/opassuan.c).  

> something. For flushing, it seems to be possible to use send HUP
> signals to the gpg-agent process, but this seems a bit brutal, and is
> also reported to not work [4]

I use it all the time.  Either pkill -1 gpg-agent or the platform
independet "gpgconf --reload gpg-agent".  The latter does a

  gpg-connect-agent --no-autostart REALODAGENT </dev/null

> echo RELOADAGENT | gpg-connect-agent

Better use

  gpg-connect-agent RELOADAGENT /bye

or use it interactive.  The normal mode is to run the commands given on
the command line and then fall into interactive mode; the /bye avoids
the fallback to interactive mode.

You may also use

  gpg-connect-agent --dirmngr

to directly connect to the dirmngr in the same way gpg does it.  To
access scdameon you should go via gpg-agent by prefixing scsaemon
command with "SCD " (you may also use lowercase command names).

All Assuan servers support "HELP" to list all comamnds and for most
commands you can do "HELP commandname".


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From rfkrocktk at gmail.com  Mon Jul  4 23:52:56 2016
From: rfkrocktk at gmail.com (Naftuli Tzvi Kay)
Date: Mon, 4 Jul 2016 14:52:56 -0700
Subject: Simply Display all Encryption Keys on a File?
Message-ID: <CAPTk+sZdSqT_g92-YHwdEY-vUZqdPR7bQYCaPhzXG0g-qQs5-Q@mail.gmail.com>

Hello,
Is there a way to take a GnuPG 2 encrypted file and simply display the key
ids that it was encrypted to? Obviously this probably won't work for
--hidden-encrypt-to, but is there a shorthand way of doing this? I've tried
using gpg2 --list-packets, but this attempts to decrypt the file first.

Thanks,
 - Naftuli Tzvi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160704/6d554fe8/attachment.html>

From wk at gnupg.org  Tue Jul  5 10:40:36 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 05 Jul 2016 10:40:36 +0200
Subject: Simply Display all Encryption Keys on a File?
In-Reply-To: <CAPTk+sZdSqT_g92-YHwdEY-vUZqdPR7bQYCaPhzXG0g-qQs5-Q@mail.gmail.com>
 (Naftuli Tzvi Kay's message of "Mon, 4 Jul 2016 14:52:56 -0700")
References: <CAPTk+sZdSqT_g92-YHwdEY-vUZqdPR7bQYCaPhzXG0g-qQs5-Q@mail.gmail.com>
Message-ID: <878txg5vgb.fsf@wheatstone.g10code.de>

On Mon,  4 Jul 2016 23:52, rfkrocktk at gmail.com said:

> Is there a way to take a GnuPG 2 encrypted file and simply display the key
> ids that it was encrypted to? Obviously this probably won't work for
> --hidden-encrypt-to, but is there a shorthand way of doing this? I've tried
> using gpg2 --list-packets, but this attempts to decrypt the file first.

This should work:

  $ cat enc-2-keys-2.gpg \
     | gpg --no-options --no-default-keyring --keyring /dev/null \
           --batch --status-fd 1 2>/dev/null \
     | awk  '$1=="[GNUPG:]" && $2=="ENC_TO" {print $3}'
  9185878E4FCD74C0
  1D777619BE310D79

Unfortunately there is no --skip-decrypt option and thus you need to
use the above trick.  Works with all gpg versions.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From rfkrocktk at gmail.com  Tue Jul  5 20:39:10 2016
From: rfkrocktk at gmail.com (Naftuli Tzvi Kay)
Date: Tue, 5 Jul 2016 11:39:10 -0700
Subject: Curve41417 Support
Message-ID: <CAPTk+sbNa9SB2EfRzm=UV1DuruS-ySjhwrHv2QYv9_D9n7s3jA@mail.gmail.com>

Hello,
Is there a good page that details elliptic curve support in GnuPG? I'm
curious if you guys are looking at implementing Curve41417, looks to be a
good curve courtesy of djb at 2^200 key strength. Of course Curve25519 is
good for now, but the more the merrier.

Thanks,
 - Naftuli Tzvi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160705/5306f3f9/attachment.html>

From rfkrocktk at gmail.com  Tue Jul  5 20:05:44 2016
From: rfkrocktk at gmail.com (Naftuli Tzvi Kay)
Date: Tue, 5 Jul 2016 11:05:44 -0700
Subject: Simply Display all Encryption Keys on a File?
In-Reply-To: <878txg5vgb.fsf@wheatstone.g10code.de>
References: <CAPTk+sZdSqT_g92-YHwdEY-vUZqdPR7bQYCaPhzXG0g-qQs5-Q@mail.gmail.com>
 <878txg5vgb.fsf@wheatstone.g10code.de>
Message-ID: <CAPTk+saUKXjjUX5DG8X-O9OBCOgfvfoPJAF0kipJ5_PMU4PbHw@mail.gmail.com>

Werner,
Thanks for your response, that answers my question. It might be nice to
have a utility, maybe called "gpg-file" which will display file information
about a GnuPG file. Being able to see things like symmetric encryption
algorithm, public keys encrypted to, compression(?), whether it's signed,
and the digest algorithm would be really nice. I know everyone is busy, but
just would like to put this out there.

Thanks,
 - Naftuli Tzvi

On Tue, Jul 5, 2016 at 1:40 AM, Werner Koch <wk at gnupg.org> wrote:

> On Mon,  4 Jul 2016 23:52, rfkrocktk at gmail.com said:
>
> > Is there a way to take a GnuPG 2 encrypted file and simply display the
> key
> > ids that it was encrypted to? Obviously this probably won't work for
> > --hidden-encrypt-to, but is there a shorthand way of doing this? I've
> tried
> > using gpg2 --list-packets, but this attempts to decrypt the file first.
>
> This should work:
>
>   $ cat enc-2-keys-2.gpg \
>      | gpg --no-options --no-default-keyring --keyring /dev/null \
>            --batch --status-fd 1 2>/dev/null \
>      | awk  '$1=="[GNUPG:]" && $2=="ENC_TO" {print $3}'
>   9185878E4FCD74C0
>   1D777619BE310D79
>
> Unfortunately there is no --skip-decrypt option and thus you need to
> use the above trick.  Works with all gpg versions.
>
>
> Shalom-Salam,
>
>    Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>  /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160705/36745bc7/attachment.html>

From dkg at fifthhorseman.net  Tue Jul  5 22:40:48 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 05 Jul 2016 16:40:48 -0400
Subject: Simply Display all Encryption Keys on a File?
In-Reply-To: <CAPTk+saUKXjjUX5DG8X-O9OBCOgfvfoPJAF0kipJ5_PMU4PbHw@mail.gmail.com>
References: <CAPTk+sZdSqT_g92-YHwdEY-vUZqdPR7bQYCaPhzXG0g-qQs5-Q@mail.gmail.com>
 <878txg5vgb.fsf@wheatstone.g10code.de>
 <CAPTk+saUKXjjUX5DG8X-O9OBCOgfvfoPJAF0kipJ5_PMU4PbHw@mail.gmail.com>
Message-ID: <87mvlvvmwf.fsf@alice.fifthhorseman.net>

On Tue 2016-07-05 14:05:44 -0400, Naftuli Tzvi Kay wrote:
> Thanks for your response, that answers my question. It might be nice to
> have a utility, maybe called "gpg-file" which will display file information
> about a GnuPG file. Being able to see things like symmetric encryption
> algorithm, public keys encrypted to, compression(?), whether it's signed,
> and the digest algorithm would be really nice. I know everyone is busy, but
> just would like to put this out there.

you might be interested in pgpdump (debian package "pgpdump"). It's
upstream homepage is:

 http://www.mew.org/~kazu/proj/pgpdump/en/

hope this helps,

 --dkg


From dkg at fifthhorseman.net  Tue Jul  5 23:01:12 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 05 Jul 2016 17:01:12 -0400
Subject: Curve41417 Support
In-Reply-To: <CAPTk+sbNa9SB2EfRzm=UV1DuruS-ySjhwrHv2QYv9_D9n7s3jA@mail.gmail.com>
References: <CAPTk+sbNa9SB2EfRzm=UV1DuruS-ySjhwrHv2QYv9_D9n7s3jA@mail.gmail.com>
Message-ID: <87bn2bvlyf.fsf@alice.fifthhorseman.net>

On Tue 2016-07-05 14:39:10 -0400, Naftuli Tzvi Kay wrote:
> Is there a good page that details elliptic curve support in GnuPG? I'm
> curious if you guys are looking at implementing Curve41417, looks to be a
> good curve courtesy of djb at 2^200 key strength. Of course Curve25519 is
> good for now, but the more the merrier.

I'm not convinced that "the more the merrier" is correct in this case (i
certainly wouldn't want the GnuPG developers to have to maintain
implementations for hundreds of distinct curves) but if GnuPG is going
to implement a stronger, new-style elliptic curve, i would hope it would
try for something like Ed448 instead, as that's more likely to be an
agreed-upon high-strength curve:

   https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-05

Regards,

   --dkg


From rfkrocktk at gmail.com  Tue Jul  5 23:26:40 2016
From: rfkrocktk at gmail.com (Naftuli Tzvi Kay)
Date: Tue, 5 Jul 2016 14:26:40 -0700
Subject: Curve41417 Support
In-Reply-To: <87bn2bvlyf.fsf@alice.fifthhorseman.net>
References: <CAPTk+sbNa9SB2EfRzm=UV1DuruS-ySjhwrHv2QYv9_D9n7s3jA@mail.gmail.com>
 <87bn2bvlyf.fsf@alice.fifthhorseman.net>
Message-ID: <CAPTk+sa5RZ3qkN7AHmprujMZ9U418cK6+vzihW89eKsfPtexUQ@mail.gmail.com>

I'm with you on "the more the merrier," Curve41417 is a good curve with
good properties that I think most people who care would like to see.
Regardless of whether it will be chosen by GnuPG for support, is there a
documentation page on which asymmetric key types that GnuPG currently
supports/plans to support?

Thanks,
 - Naftuli Tzvi

On Tue, Jul 5, 2016 at 2:01 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net>
wrote:

> On Tue 2016-07-05 14:39:10 -0400, Naftuli Tzvi Kay wrote:
> > Is there a good page that details elliptic curve support in GnuPG? I'm
> > curious if you guys are looking at implementing Curve41417, looks to be a
> > good curve courtesy of djb at 2^200 key strength. Of course Curve25519 is
> > good for now, but the more the merrier.
>
> I'm not convinced that "the more the merrier" is correct in this case (i
> certainly wouldn't want the GnuPG developers to have to maintain
> implementations for hundreds of distinct curves) but if GnuPG is going
> to implement a stronger, new-style elliptic curve, i would hope it would
> try for something like Ed448 instead, as that's more likely to be an
> agreed-upon high-strength curve:
>
>    https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-05
>
> Regards,
>
>    --dkg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160705/04d49c5c/attachment.html>

From gniibe at fsij.org  Wed Jul  6 02:41:03 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 6 Jul 2016 09:41:03 +0900
Subject: Curve41417 Support
In-Reply-To: <CAPTk+sa5RZ3qkN7AHmprujMZ9U418cK6+vzihW89eKsfPtexUQ@mail.gmail.com>
References: <CAPTk+sbNa9SB2EfRzm=UV1DuruS-ySjhwrHv2QYv9_D9n7s3jA@mail.gmail.com>
 <87bn2bvlyf.fsf@alice.fifthhorseman.net>
 <CAPTk+sa5RZ3qkN7AHmprujMZ9U418cK6+vzihW89eKsfPtexUQ@mail.gmail.com>
Message-ID: <869be6e4-dff8-507e-5054-72fd106770f0@fsij.org>

On 07/06/2016 06:26 AM, Naftuli Tzvi Kay wrote:
> Regardless of whether it will be chosen by GnuPG for support, is there a
> documentation page on which asymmetric key types that GnuPG currently
> supports/plans to support?

I found the wiki page:

    https://wiki.gnupg.org/ECC

and then, I added some information for ECC.

I put a column for availability of token implementation, as I'm
developing Gnuk.  :-)
-- 


From wk at gnupg.org  Wed Jul  6 07:58:00 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 06 Jul 2016 07:58:00 +0200
Subject: Curve41417 Support
In-Reply-To: <87bn2bvlyf.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 05 Jul 2016 17:01:12 -0400")
References: <CAPTk+sbNa9SB2EfRzm=UV1DuruS-ySjhwrHv2QYv9_D9n7s3jA@mail.gmail.com>
 <87bn2bvlyf.fsf@alice.fifthhorseman.net>
Message-ID: <87furnxq8n.fsf@wheatstone.g10code.de>

On Tue,  5 Jul 2016 23:01, dkg at fifthhorseman.net said:

> try for something like Ed448 instead, as that's more likely to be an
> agreed-upon high-strength curve:

Right.  That is what the IETF has agreed upon and even DJB agrees with
it.

Now, it is more important to deploy ECC capable implementations before
we add new curves.  The latter is much easier to do.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From wk at gnupg.org  Wed Jul  6 16:01:56 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 06 Jul 2016 16:01:56 +0200
Subject: New option --recipient-file
Message-ID: <87poqqvp9n.fsf@wheatstone.g10code.de>

Hi!

I just pushed the code for a new feature.  With 

  gpg --recipient-file FILENAME -e

or

  gpg -f FILENAME -e

it is now possible to bypass the keyring and take the public key
directly from a file.  That file may be a binary or an ascii armored key
and only the first keyblock from that file is used.  A key specified
with this option is always fully trusted.

This option may be mixed with the standard -r options.
--hidden-recipient-file (or -F) is also available.

To futher assist some use cases the option

  --no-keyring

has also been implemented.  This is similar to

  --no-default-keyring --keyring /dev/null

but portable to Windows and also ignores any keyring specified (command
line or config file).



Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From neal at walfield.org  Wed Jul  6 21:41:46 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 06 Jul 2016 21:41:46 +0200
Subject: New option --recipient-file
In-Reply-To: <87poqqvp9n.fsf@wheatstone.g10code.de>
References: <87poqqvp9n.fsf@wheatstone.g10code.de>
Message-ID: <87poqqo8p1.wl-neal@walfield.org>

On Wed, 06 Jul 2016 16:01:56 +0200,
Werner Koch wrote:
> To futher assist some use cases the option
> 
>   --no-keyring
> 
> has also been implemented.  This is similar to
> 
>   --no-default-keyring --keyring /dev/null
> 
> but portable to Windows and also ignores any keyring specified (command
> line or config file).

Aren't options usually parsed in order?  As such, shouldn't later
keyring/keybox options not be ignored?

Thanks!

:) Neal


From wk at gnupg.org  Thu Jul  7 10:18:10 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 07 Jul 2016 10:18:10 +0200
Subject: New option --recipient-file
In-Reply-To: <87poqqo8p1.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Wed, 06 Jul 2016 21:41:46 +0200")
References: <87poqqvp9n.fsf@wheatstone.g10code.de>
 <87poqqo8p1.wl-neal@walfield.org>
Message-ID: <87furlq2t9.fsf@wheatstone.g10code.de>

On Wed,  6 Jul 2016 21:41, neal at walfield.org said:

> Aren't options usually parsed in order?  As such, shouldn't later
> keyring/keybox options not be ignored?

I see no practical use for first giving --no-keyring and then specifying
a keyring.  The reason why --no-keyring is useful is that
--no-default-keyring without a --keyring option would use the default
keyring anyway.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From neal at walfield.org  Thu Jul  7 10:36:43 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 07 Jul 2016 10:36:43 +0200
Subject: New option --recipient-file
In-Reply-To: <87furlq2t9.fsf@wheatstone.g10code.de>
References: <87poqqvp9n.fsf@wheatstone.g10code.de>
 <87poqqo8p1.wl-neal@walfield.org>
 <87furlq2t9.fsf@wheatstone.g10code.de>
Message-ID: <87mvltondw.wl-neal@walfield.org>

On Thu, 07 Jul 2016 10:18:10 +0200,
Werner Koch wrote:
> 
> On Wed,  6 Jul 2016 21:41, neal at walfield.org said:
> 
> > Aren't options usually parsed in order?  As such, shouldn't later
> > keyring/keybox options not be ignored?
> 
> I see no practical use for first giving --no-keyring and then specifying
> a keyring.  The reason why --no-keyring is useful is that
> --no-default-keyring without a --keyring option would use the default
> keyring anyway.

I was thinking of scripts that specify some options, but allow the
caller to override them by providing later options.  This trivial with
gcc, for instance, in which the last -Ox option takes effect.  Thus, a
makefile can specify -On and the user can override it by specifying
something else in the CFLAGS.  In this particular case, it perhaps
really isn't that useful.  But to improve semantic consistency, I'd
prefer it.

Neal


From wk at gnupg.org  Thu Jul  7 11:19:19 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 07 Jul 2016 11:19:19 +0200
Subject: New option --recipient-file
In-Reply-To: <87mvltondw.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Thu, 07 Jul 2016 10:36:43 +0200")
References: <87poqqvp9n.fsf@wheatstone.g10code.de>
 <87poqqo8p1.wl-neal@walfield.org>
 <87furlq2t9.fsf@wheatstone.g10code.de>
 <87mvltondw.wl-neal@walfield.org>
Message-ID: <87k2gxolew.fsf@wheatstone.g10code.de>

On Thu,  7 Jul 2016 10:36, neal at walfield.org said:

> something else in the CFLAGS.  In this particular case, it perhaps
> really isn't that useful.  But to improve semantic consistency, I'd
> prefer it.

This woul require quite some code changes and a lot testing. 


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From neal at walfield.org  Thu Jul  7 11:36:10 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 07 Jul 2016 11:36:10 +0200
Subject: New option --recipient-file
In-Reply-To: <87k2gxolew.fsf@wheatstone.g10code.de>
References: <87poqqvp9n.fsf@wheatstone.g10code.de>
 <87poqqo8p1.wl-neal@walfield.org>
 <87furlq2t9.fsf@wheatstone.g10code.de>
 <87mvltondw.wl-neal@walfield.org>
 <87k2gxolew.fsf@wheatstone.g10code.de>
Message-ID: <87lh1dokmt.wl-neal@walfield.org>

On Thu, 07 Jul 2016 11:19:19 +0200,
Werner Koch wrote:
> 
> On Thu,  7 Jul 2016 10:36, neal at walfield.org said:
> 
> > something else in the CFLAGS.  In this particular case, it perhaps
> > really isn't that useful.  But to improve semantic consistency, I'd
> > prefer it.
> 
> This woul require quite some code changes and a lot testing. 

Oh, I thought --no-keyring was completely new.  Sorry.



From wk at gnupg.org  Thu Jul  7 17:44:54 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 07 Jul 2016 17:44:54 +0200
Subject: Removing --print-dane-records ?
Message-ID: <87inwhmozt.fsf@wheatstone.g10code.de>

Hi!

I added a new export option "export-dane" which yields the same output
with --export as "--print-dane-records" does in a key listing.  The
advantage of having this in the export code is that the other export
options and the new filter can also be applied.  And it is less
surprising to have this has an export option than as a special key
listing mode.

Are there any concerns of removing the --print-dane-records option?  I
doubt that it is widely used, anyway.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From wk at gnupg.org  Thu Jul  7 18:23:39 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 07 Jul 2016 18:23:39 +0200
Subject: New option --recipient-file
In-Reply-To: <87lh1dokmt.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Thu, 07 Jul 2016 11:36:10 +0200")
References: <87poqqvp9n.fsf@wheatstone.g10code.de>
 <87poqqo8p1.wl-neal@walfield.org>
 <87furlq2t9.fsf@wheatstone.g10code.de>
 <87mvltondw.wl-neal@walfield.org>
 <87k2gxolew.fsf@wheatstone.g10code.de>
 <87lh1dokmt.wl-neal@walfield.org>
Message-ID: <87oa69l8ms.fsf@wheatstone.g10code.de>

On Thu,  7 Jul 2016 11:36, neal at walfield.org said:

> Oh, I thought --no-keyring was completely new.  Sorry.

Yes it is.  But the code changes are trivial:

-	  case oNoDefKeyring: default_keyring = 0; break;
+	  case oNoDefKeyring:
+            if (default_keyring > 0)
+              default_keyring = 0;
+            break;
+	  case oNoKeyring:
+            default_keyring = -1;
+            break;

and later when actually adding the keyring:

-    if( ALWAYS_ADD_KEYRINGS
-        || (cmd != aDeArmor && cmd != aEnArmor && cmd != aGPGConfTest) )
+    if (default_keyring >= 0
+        && (ALWAYS_ADD_KEYRINGS
+            || (cmd != aDeArmor && cmd != aEnArmor && cmd != aGPGConfTest)))
       {
-	if (!nrings || default_keyring)  /* Add default ring. */
+	if (!nrings || default_keyring > 0)  /* Add default ring. */
 	    keydb_add_resource ("pubring" EXTSEP_S GPGEXT_GPG,
                                 KEYDB_RESOURCE_FLAG_DEFAULT);
 	for (sl = nrings; sl; sl = sl->next )

To do what you want, we would need to set and clear an extra flag and
for each string so that we later know which keys need to go in.

The adding of the keyrings is not done immediately because there are
commands which have no need for a keyring and we do not want to create a
new keyring if one of those commands is used.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From dkg at fifthhorseman.net  Thu Jul  7 19:46:43 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 07 Jul 2016 13:46:43 -0400
Subject: Removing --print-dane-records ?
In-Reply-To: <87inwhmozt.fsf@wheatstone.g10code.de>
References: <87inwhmozt.fsf@wheatstone.g10code.de>
Message-ID: <877fcxfiik.fsf@alice.fifthhorseman.net>

On Thu 2016-07-07 11:44:54 -0400, Werner Koch wrote:

> I added a new export option "export-dane" which yields the same output
> with --export as "--print-dane-records" does in a key listing.  The
> advantage of having this in the export code is that the other export
> options and the new filter can also be applied.  And it is less
> surprising to have this has an export option than as a special key
> listing mode.
>
> Are there any concerns of removing the --print-dane-records option?  I
> doubt that it is widely used, anyway.

it's not used anywhere in debian outside the gnupg2 package itself:

   https://codesearch.debian.net/search?q=print-dane-records

If you think it's a cleaner interface without, i'd say go ahead and
remove it.

That said, is it that much more intuitive as an export option?  All the
other export-options are filters that decide which packets should be
emitted.  This one actually transforms the output format entirely.  It
feels a bit more like the difference between --armor and --no-armor, or
between "--with-colons --list-keys" and --export :/

i'd be fine either way, but i agree with you that there should be only
one standard way to get gpg to emit the dane records, i just don't know
which one is preferable.

        --dkg


From wk at gnupg.org  Thu Jul  7 20:10:40 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 07 Jul 2016 20:10:40 +0200
Subject: Removing --print-dane-records ?
In-Reply-To: <877fcxfiik.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Thu, 07 Jul 2016 13:46:43 -0400")
References: <87inwhmozt.fsf@wheatstone.g10code.de>
 <877fcxfiik.fsf@alice.fifthhorseman.net>
Message-ID: <87shvljp3z.fsf@wheatstone.g10code.de>

On Thu,  7 Jul 2016 19:46, dkg at fifthhorseman.net said:

> If you think it's a cleaner interface without, i'd say go ahead and
> remove it.

Yes I think so.  The reason I originally implemented as an option for -k
was pure laziness.  Meanwhile I cleaned up the export code and it is now
possible to understand the code to some degree.

The other option was to add a filter like --export-filter to the -k
command but I had no clean idea on how this would be useful.

I also realized that large parts of the code for export and import
duplicate functionality and have minor semantic differences.  This
should eventually be folded into one

> That said, is it that much more intuitive as an export option?  All the
> other export-options are filters that decide which packets should be
> emitted.  This one actually transforms the output format entirely.  It

Well, --export takes care of --output which is sometimes useful.  There
used to be an export option to export as an s-expression which also
transformed the output.

> i'd be fine either way, but i agree with you that there should be only
> one standard way to get gpg to emit the dane records, i just don't know
> which one is preferable.

Yeah.  Right now it should be possible to remove the options so that we
do not need to carry an --fixed-list-mode around for more than a decade.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From guilhem at fripost.org  Fri Jul  8 23:09:40 2016
From: guilhem at fripost.org (Guilhem Moulin)
Date: Fri, 8 Jul 2016 23:09:40 +0200
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87k2hyx3ct.fsf@wheatstone.g10code.de>
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <87h9d3zu52.fsf@wheatstone.g10code.de>
 <8737onfuv8.fsf@alice.fifthhorseman.net>
 <87k2hyx3ct.fsf@wheatstone.g10code.de>
Message-ID: <20160708210939.GA28371@localhost.localdomain>

Hi Werner,

On Thu, 09 Jun 2016 at 08:50:42 +0200, Werner Koch wrote:
> On Wed,  8 Jun 2016 19:33, dkg at fifthhorseman.net said:
>> Also, is there an easy/automated way to query gpg for the hashed
>> directory?  it'd be nice for external tools to be able to do something
>> like:
>>
>> gpgconf --homedir $foo --print-socket-dir
> 
> gpgconf --list-dirs | grep ^agent-socket: | cut -d: -f2

By the way, the ?EXAMPLES? section of the gpg-agent(1) manpage should be
modified accordingly to show the new SSH_AUTH_SOCK assignation.  In
fact, using gpgconf seems to be more robust than building the path
manually and would also be more portable across versions.

However, while ?gpgconf --list-dirs? lists the gpg-agent socket path,
the ssh-agent agent socket path is missing.  If it's safe to merely
append the gpg-agent socket path with ?.ssh?, I guess it should be
documented in the manpage somehow (though adding a gpgconf entry for the
SSH agent socket would be cleaner IMHO).

Cheers,
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20160708/4ef57a92/attachment-0001.sig>

From yann.morin.1998 at free.fr  Sat Jul  9 14:05:38 2016
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Sat,  9 Jul 2016 14:05:38 +0200
Subject: [libgpg-error PATCH 2/3] tests: fix build without threads
In-Reply-To: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>
References: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>
Message-ID: <1468065939-27803-3-git-send-email-yann.morin.1998@free.fr>

Although ./configure checks for thread support, some tests still
include pthread.h unconditionally.

Guard that inclusion using the same condition as all other uses of
pthread-related code.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>
---
 tests/t-lock.c | 4 +++-
 tests/t-poll.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/tests/t-lock.c b/tests/t-lock.c
index 38c9cec..6add18b 100644
--- a/tests/t-lock.c
+++ b/tests/t-lock.c
@@ -31,7 +31,9 @@
 # include <windows.h>
 # include <time.h>
 #else
-# include <pthread.h>
+# ifdef USE_POSIX_THREADS
+#  include <pthread.h>
+# endif
 #endif
 
 #define PGM "t-lock"
diff --git a/tests/t-poll.c b/tests/t-poll.c
index 811f895..a26cbfa 100644
--- a/tests/t-poll.c
+++ b/tests/t-poll.c
@@ -34,7 +34,9 @@
 # include <windows.h>
 # include <time.h>
 #else
-# include <pthread.h>
+# ifdef USE_POSIX_THREADS
+#  include <pthread.h>
+# endif
 #endif
 
 #define PGM "t-lock"
-- 
2.7.4



From yann.morin.1998 at free.fr  Sat Jul  9 14:05:36 2016
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Sat,  9 Jul 2016 14:05:36 +0200
Subject: [libgpg-error PATCH 0/3] Fix build without pthreads
Message-ID: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>

Building libgpgp-error without threads is currently broken because the
some files unconditionally #include <pthread.h> even if ./configure
decided threads were not available.

The first two patches in the series fix that.

Finally, tests are sometimes unneeded, especially on embedded devices.

The third patch adds an option to disable building tests.

    [PATCH 1/3] gen-posix-lock-obj: fix build without threads
    [PATCH 2/3] tests: fix build without threads
    [PATCH 3/3] configure: add an option to disable tests

Regards,
Yann E. MORIN.


From yann.morin.1998 at free.fr  Sat Jul  9 14:05:37 2016
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Sat,  9 Jul 2016 14:05:37 +0200
Subject: [libgpg-error PATCH 1/3] gen-posix-lock-obj: fix build without threads
In-Reply-To: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>
References: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>
Message-ID: <1468065939-27803-2-git-send-email-yann.morin.1998@free.fr>

Although ./configure checks for thread support, gen-posix-lock-obj still
includes pthread.h unconditionally.

Guard that inclusion using the same condition as all other uses of
pthread-related code.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>
---
 src/gen-posix-lock-obj.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gen-posix-lock-obj.c b/src/gen-posix-lock-obj.c
index e32a3cd..e6f33ae 100644
--- a/src/gen-posix-lock-obj.c
+++ b/src/gen-posix-lock-obj.c
@@ -29,7 +29,9 @@
 #include <string.h>
 #include <stdio.h>
 #include <errno.h>
-#include <pthread.h>
+#ifdef USE_POSIX_THREADS
+# include <pthread.h>
+#endif
 
 #include "posix-lock-obj.h"
 
-- 
2.7.4



From yann.morin.1998 at free.fr  Sat Jul  9 14:05:39 2016
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Sat,  9 Jul 2016 14:05:39 +0200
Subject: [libgpg-error PATCH 3/3] configure: add an option to disable tests
In-Reply-To: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>
References: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>
Message-ID: <1468065939-27803-4-git-send-email-yann.morin.1998@free.fr>

Signed-off-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>
---
 Makefile.am  | 8 +++++++-
 configure.ac | 5 +++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index baeba14..7cfbeef 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -39,7 +39,13 @@ else
 doc =
 endif
 
-SUBDIRS = m4 src $(doc) tests po $(lang_subdirs)
+if BUILD_TESTS
+doc = doc
+else
+doc =
+endif
+
+SUBDIRS = m4 src $(doc) $(tests) po $(lang_subdirs)
 
 
 dist-hook: gen-ChangeLog
diff --git a/configure.ac b/configure.ac
index 682fd84..d19943d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -533,6 +533,11 @@ AC_ARG_ENABLE([doc], AC_HELP_STRING([--disable-doc],
                      build_doc=$enableval, build_doc=yes)
 AM_CONDITIONAL([BUILD_DOC], [test "x$build_doc" != xno])
 
+build_tests=yes
+AC_ARG_ENABLE([tests], AC_HELP_STRING([--disable-tests],
+                                    [do not build the tests]),
+                     build_tests=$enableval, build_tests=yes)
+AM_CONDITIONAL([BUILD_TESTS], [test "x$build_tests" != xno])
 
 #
 # Substitution
-- 
2.7.4



From yann.morin.1998 at free.fr  Sat Jul  9 16:24:19 2016
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Sat, 9 Jul 2016 16:24:19 +0200
Subject: [libgpg-error PATCH 3/3] configure: add an option to disable tests
In-Reply-To: <1468065939-27803-4-git-send-email-yann.morin.1998@free.fr>
References: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>
 <1468065939-27803-4-git-send-email-yann.morin.1998@free.fr>
Message-ID: <20160709142419.GA3797@free.fr>

All,

On 2016-07-09 14:05 +0200, Yann E. MORIN spake thusly:
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>
> ---
>  Makefile.am  | 8 +++++++-
>  configure.ac | 5 +++++
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index baeba14..7cfbeef 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -39,7 +39,13 @@ else
>  doc =
>  endif
>  
> -SUBDIRS = m4 src $(doc) tests po $(lang_subdirs)
> +if BUILD_TESTS
> +doc = doc
> +else
> +doc =
> +endif

Meh... s/doc/tests/

I forgot to amend the commit before sending the patches. I'll resubmit
a bit later, to let some time for others to review the series.

Sorry for the noise...

Regards,
Yann E. MORIN.

> +SUBDIRS = m4 src $(doc) $(tests) po $(lang_subdirs)
>  
>  
>  dist-hook: gen-ChangeLog
> diff --git a/configure.ac b/configure.ac
> index 682fd84..d19943d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -533,6 +533,11 @@ AC_ARG_ENABLE([doc], AC_HELP_STRING([--disable-doc],
>                       build_doc=$enableval, build_doc=yes)
>  AM_CONDITIONAL([BUILD_DOC], [test "x$build_doc" != xno])
>  
> +build_tests=yes
> +AC_ARG_ENABLE([tests], AC_HELP_STRING([--disable-tests],
> +                                    [do not build the tests]),
> +                     build_tests=$enableval, build_tests=yes)
> +AM_CONDITIONAL([BUILD_TESTS], [test "x$build_tests" != xno])
>  
>  #
>  # Substitution
> -- 
> 2.7.4
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'


From wk at gnupg.org  Sat Jul  9 17:06:50 2016
From: wk at gnupg.org (Werner Koch)
Date: Sat, 09 Jul 2016 17:06:50 +0200
Subject: [libgpg-error PATCH 0/3] Fix build without pthreads
In-Reply-To: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr> (Yann
 E. MORIN's message of "Sat, 9 Jul 2016 14:05:36 +0200")
References: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>
Message-ID: <87shviam0l.fsf@wheatstone.g10code.de>

On Sat,  9 Jul 2016 14:05, yann.morin.1998 at free.fr said:
> Building libgpgp-error without threads is currently broken because the
> some files unconditionally #include <pthread.h> even if ./configure
> decided threads were not available.

Thanks for the patches.  Can you please squash 1 and 2 and write a
commit log in our style.  See gnupg/doc/HACKING/.  For these small patches
we can do without a DCO.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From yann.morin.1998 at free.fr  Sat Jul  9 19:30:11 2016
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Sat, 9 Jul 2016 19:30:11 +0200
Subject: [libgpg-error PATCH 0/3] Fix build without pthreads
In-Reply-To: <87shviam0l.fsf@wheatstone.g10code.de>
References: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>
 <87shviam0l.fsf@wheatstone.g10code.de>
Message-ID: <20160709173011.GB3797@free.fr>

Werner, All,

On 2016-07-09 17:06 +0200, Werner Koch spake thusly:
> On Sat,  9 Jul 2016 14:05, yann.morin.1998 at free.fr said:
> > Building libgpgp-error without threads is currently broken because the
> > some files unconditionally #include <pthread.h> even if ./configure
> > decided threads were not available.
> 
> Thanks for the patches.  Can you please squash 1 and 2 and write a
> commit log in our style.  See gnupg/doc/HACKING/.

OK, will do.

>  For these small patches we can do without a DCO.

What do yuou mean by DCO? If you meant "Developer Certificate of Origin"
as is meant in the kernel, then I did sign-off each commit.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'


From wk at gnupg.org  Sat Jul  9 21:04:19 2016
From: wk at gnupg.org (Werner Koch)
Date: Sat, 09 Jul 2016 21:04:19 +0200
Subject: [libgpg-error PATCH 0/3] Fix build without pthreads
In-Reply-To: <20160709173011.GB3797@free.fr> (Yann E. MORIN's message of "Sat, 
 9 Jul 2016 19:30:11 +0200")
References: <1468065939-27803-1-git-send-email-yann.morin.1998@free.fr>
 <87shviam0l.fsf@wheatstone.g10code.de> <20160709173011.GB3797@free.fr>
Message-ID: <87poqm8wgc.fsf@wheatstone.g10code.de>

On Sat,  9 Jul 2016 19:30, yann.morin.1998 at free.fr said:

> OK, will do.

Thanks.

> What do yuou mean by DCO? If you meant "Developer Certificate of Origin"
> as is meant in the kernel, then I did sign-off each commit.

You need to send it to the list first, see gnupg/doc/HACKING.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From yann.morin.1998 at free.fr  Sun Jul 10 11:32:02 2016
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Sun, 10 Jul 2016 11:32:02 +0200
Subject: Sign-off DCO
Message-ID: <20160710093202.GA3688@free.fr>

Hello,

As per instructions, here is the DCO signed-off by me:

GnuPG Developer's Certificate of Origin.  Version 1.0
=====================================================

By making a contribution to the GnuPG project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the free software license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the
    best of my knowledge, is covered under an appropriate free
    software license and I have the right under that license to
    submit that work with modifications, whether created in whole
    or in part by me, under the same free software license
    (unless I am permitted to submit under a different license),
    as indicated in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including
    all personal information I submit with it, including my
    sign-off) is maintained indefinitely and may be redistributed
    consistent with this project or the free software license(s)
    involved.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: </pipermail/attachments/20160710/55945965/attachment.sig>

From yann.morin.1998 at free.fr  Sun Jul 10 11:38:45 2016
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Sun, 10 Jul 2016 11:38:45 +0200
Subject: [libgpg-error PATCHv2 0/2] Fix build without pthreads
Message-ID: <1468143527-31614-1-git-send-email-yann.morin.1998@free.fr>

Building libgpgp-error without threads is currently broken because some
files unconditionally #include <pthread.h> even if ./configure decided
threads were not available.

The first patch in the series fixes that.

Finally, tests are sometimes unneeded, especially on embedded devices.

The second patch adds an option to disable building tests.

    [PATCH 1/2] Fix build without threads
    [PATCH 2/2] Add an option to disable tests

Regards,
Yann E. MORIN.


From yann.morin.1998 at free.fr  Sun Jul 10 11:38:46 2016
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Sun, 10 Jul 2016 11:38:46 +0200
Subject: [libgpg-error PATCH 1/2] Fix build without threads
In-Reply-To: <1468143527-31614-1-git-send-email-yann.morin.1998@free.fr>
References: <1468143527-31614-1-git-send-email-yann.morin.1998@free.fr>
Message-ID: <1468143527-31614-2-git-send-email-yann.morin.1998@free.fr>

* src/gen-posix-lock-obj.c: properly guard inclusioin of pthread.h
* tests/t-lock.c: likewise
* tests/t-poll.c: likewise
--

Although ./configure checks for thread support, gen-posix-lock-obj and
two tests still include pthread.h unconditionally.

Guard that inclusion using the same condition as all other uses of
pthread-related code.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>
---
 src/gen-posix-lock-obj.c | 4 +++-
 tests/t-lock.c           | 4 +++-
 tests/t-poll.c           | 4 +++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/gen-posix-lock-obj.c b/src/gen-posix-lock-obj.c
index e32a3cd..e6f33ae 100644
--- a/src/gen-posix-lock-obj.c
+++ b/src/gen-posix-lock-obj.c
@@ -29,7 +29,9 @@
 #include <string.h>
 #include <stdio.h>
 #include <errno.h>
-#include <pthread.h>
+#ifdef USE_POSIX_THREADS
+# include <pthread.h>
+#endif
 
 #include "posix-lock-obj.h"
 
diff --git a/tests/t-lock.c b/tests/t-lock.c
index 38c9cec..6add18b 100644
--- a/tests/t-lock.c
+++ b/tests/t-lock.c
@@ -31,7 +31,9 @@
 # include <windows.h>
 # include <time.h>
 #else
-# include <pthread.h>
+# ifdef USE_POSIX_THREADS
+#  include <pthread.h>
+# endif
 #endif
 
 #define PGM "t-lock"
diff --git a/tests/t-poll.c b/tests/t-poll.c
index 811f895..a26cbfa 100644
--- a/tests/t-poll.c
+++ b/tests/t-poll.c
@@ -34,7 +34,9 @@
 # include <windows.h>
 # include <time.h>
 #else
-# include <pthread.h>
+# ifdef USE_POSIX_THREADS
+#  include <pthread.h>
+# endif
 #endif
 
 #define PGM "t-lock"
-- 
2.7.4



From yann.morin.1998 at free.fr  Sun Jul 10 11:38:47 2016
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Sun, 10 Jul 2016 11:38:47 +0200
Subject: [libgpg-error PATCH 2/2] Add an option to disable tests
In-Reply-To: <1468143527-31614-1-git-send-email-yann.morin.1998@free.fr>
References: <1468143527-31614-1-git-send-email-yann.morin.1998@free.fr>
Message-ID: <1468143527-31614-3-git-send-email-yann.morin.1998@free.fr>

* configure.ac: add an option to enable/disable building tests
* Makefile.am: conditionally build tests
--

On an embeded device, there is no reason to have the tests present in
a production release build. Add a configure-time option to disable
them.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>

---
Changes v1 -> v2:
  - use correct variable
---
 Makefile.am  | 8 +++++++-
 configure.ac | 5 +++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index baeba14..5abd97d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -39,7 +39,13 @@ else
 doc =
 endif
 
-SUBDIRS = m4 src $(doc) tests po $(lang_subdirs)
+if BUILD_TESTS
+tests = tests
+else
+tests =
+endif
+
+SUBDIRS = m4 src $(doc) $(tests) po $(lang_subdirs)
 
 
 dist-hook: gen-ChangeLog
diff --git a/configure.ac b/configure.ac
index 682fd84..d19943d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -533,6 +533,11 @@ AC_ARG_ENABLE([doc], AC_HELP_STRING([--disable-doc],
                      build_doc=$enableval, build_doc=yes)
 AM_CONDITIONAL([BUILD_DOC], [test "x$build_doc" != xno])
 
+build_tests=yes
+AC_ARG_ENABLE([tests], AC_HELP_STRING([--disable-tests],
+                                    [do not build the tests]),
+                     build_tests=$enableval, build_tests=yes)
+AM_CONDITIONAL([BUILD_TESTS], [test "x$build_tests" != xno])
 
 #
 # Substitution
-- 
2.7.4



From wk at gnupg.org  Mon Jul 11 12:11:17 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 11 Jul 2016 12:11:17 +0200
Subject: [Announce] OpenPGP.conf program published
Message-ID: <87eg704h8a.fsf@wheatstone.g10code.de>

Hello!

Seven week ago the GUUG published a call for presentations for the first
public conference on the OpenPGP protocol, taking place in Cologne on
September 8+9.  Meanwhile the program committee selected the talks and
published the schedule at

  https://www.openpgp-conf.org/program.html

I'd be pleased to see many of you there to discuss topics around
OpenPGP.  Registration recently opened; see

  https://www.openpgp-conf.org/registration.html

Here is a brief overview on the program; see the web page for more:

Thursday, September 8th:

 09:30 A Simple Solution to Key Discovery / Werner Koch
 10:15 Transparent Key Management at LEAP / meskio

 11:00 Coffee break 	

 11:30 The Mathematical Mesh: Management of Keys / Phillip Hallam-Baker
 12:15 OpenPGP.js and the Mailvelope Key Server  / Tankred Hase

 13:00 Lunch 	

 14:30 Building a Vision for GnuPG / Bernhard Reiter
 15:15 NEXTLEAP and Automatic E2E emails / Holger Krekel

 16:00 Coffee break 	

 16:30 A few concerns regarding PGP, new directions / Stefan 'stf' Marsiske
 17:15 History of OpenPGP / Lutz Donnerhacke

 18:00 Key signing 	
 18:30 Social event 	

Friday, September 9th:

 09:30 Automated use of GnuPG through GPGME / Andre Heinecke
 10:15 Gnuk 1.2 / Niibe Yutaka

 11:00 Coffee break 	

 11:30 OpenKeychain UX Decisions / Dominik S. and Vincent B.
 12:15 Bypass Pinentry for good via ... / Seiya Kawashima

 13:00 Lunch 	

 14:30 An analysis of OpenPGP key usage / Sven Braun
 15:15 GnuPG in Debian / Daniel Kahn Gillmor

 16:00 Coffee break 	

 16:30 Closing Event 	


Thanks to all who submitted their talk proposals.


Salam-Shalom,

   Werner


p.s.
https://openpgp-conf.org is mirrored at https://gnupg.org/conf

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: </pipermail/attachments/20160711/1ed73ec1/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From wk at gnupg.org  Mon Jul 11 13:12:31 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 11 Jul 2016 13:12:31 +0200
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <20160708210939.GA28371@localhost.localdomain> (Guilhem Moulin's
 message of "Fri, 8 Jul 2016 23:09:40 +0200")
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <87h9d3zu52.fsf@wheatstone.g10code.de>
 <8737onfuv8.fsf@alice.fifthhorseman.net>
 <87k2hyx3ct.fsf@wheatstone.g10code.de>
 <20160708210939.GA28371@localhost.localdomain>
Message-ID: <878tx84ee8.fsf@wheatstone.g10code.de>

On Fri,  8 Jul 2016 23:09, guilhem at fripost.org said:
> By the way, the ?EXAMPLES? section of the gpg-agent(1) manpage should be
> modified accordingly to show the new SSH_AUTH_SOCK assignation.  In
> fact, using gpgconf seems to be more robust than building the path
> manually and would also be more portable across versions.

Good idea.  I changed it to 

  unset SSH_AGENT_PID
  if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
    export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
  fi

> However, while ?gpgconf --list-dirs? lists the gpg-agent socket path,
> the ssh-agent agent socket path is missing.  If it's safe to merely

Added.  And also, as you can see above, there is a new mode to print
only the names specified on the command line - without percent-escaping.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From dkg at fifthhorseman.net  Mon Jul 11 15:44:56 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 11 Jul 2016 15:44:56 +0200
Subject: [PATCH] fix typo
Message-ID: <1468244696-16479-1-git-send-email-dkg@fifthhorseman.net>

---
 dirmngr/http.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dirmngr/http.c b/dirmngr/http.c
index 941ad4f..a512e9a 100644
--- a/dirmngr/http.c
+++ b/dirmngr/http.c
@@ -744,7 +744,7 @@ http_session_set_log_cb (http_session_t sess,
 
 /* Start a HTTP retrieval and on success store at R_HD a context
    pointer for completing the request and to wait for the response.
-   If HTTPHOST is not NULL it is used hor the Host header instead of a
+   If HTTPHOST is not NULL it is used for the Host header instead of a
    Host header derived from the URL. */
 gpg_error_t
 http_open (http_t *r_hd, http_req_t reqtype, const char *url,
-- 
2.8.1



From gniibe at fsij.org  Tue Jul 12 10:06:45 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 12 Jul 2016 17:06:45 +0900
Subject: Environment variables for UPDATESTARTUPTTY of gpg-agent
Message-ID: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>

Hello,

Recently, I changed the configuration so that gpg-agent is started by
systemd.  Then, I encounter this issue:

	https://bugs.debian.org/801247

For SSH, I can't get the dialog of pinentry-gnome3.

Something like this is needed, so that a user can update environment
variables by UPDATESTARTUPTTY.  What I need now is
DBUS_SESSION_BUS_ADDRESS only, but I think that it should be as same
as the variable of stdenvnames in common/session-env.c.

I think that this kind of bug is very difficult for users.  SSH just
fails but gpg-agent (and pinentry-gnome3) doesn't report any useful
information to a user; it should emit some message.


diff --git a/agent/command.c b/agent/command.c
index de5b184..2ab0f3a 100644
--- a/agent/command.c
+++ b/agent/command.c
@@ -2664,7 +2664,11 @@ static gpg_error_t
 cmd_updatestartuptty (assuan_context_t ctx, char *line)
 {
   static const char *names[] =
-    { "GPG_TTY", "DISPLAY", "TERM", "XAUTHORITY", "PINENTRY_USER_DATA",
NULL };
+    { "GPG_TTY", "TERM", "DISPLAY", "XAUTHORITY",
+      "XMODIFIERS", "GTK_IM_MODULE", "QT_IM_MODULE",
+      "DBUS_SESSION_BUS_ADDRESS",
+      "INSIDE_EMACS",
+      "PINENTRY_USER_DATA", NULL };
   ctrl_t ctrl = assuan_get_pointer (ctx);
   gpg_error_t err = 0;
   session_env_t se;
-- 


From wk at gnupg.org  Tue Jul 12 10:44:02 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 12 Jul 2016 10:44:02 +0200
Subject: [libgpg-error PATCHv2 0/2] Fix build without pthreads
In-Reply-To: <1468143527-31614-1-git-send-email-yann.morin.1998@free.fr> (Yann
 E. MORIN's message of "Sun, 10 Jul 2016 11:38:45 +0200")
References: <1468143527-31614-1-git-send-email-yann.morin.1998@free.fr>
Message-ID: <87oa63xn3h.fsf@wheatstone.g10code.de>

On Sun, 10 Jul 2016 11:38, yann.morin.1998 at free.fr said:

>     [PATCH 1/2] Fix build without threads
>     [PATCH 2/2] Add an option to disable tests

Thanks.  Both applied and pushed.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From wk at gnupg.org  Tue Jul 12 10:53:20 2016
From: wk at gnupg.org (Werner Koch)
Date: Tue, 12 Jul 2016 10:53:20 +0200
Subject: Environment variables for UPDATESTARTUPTTY of gpg-agent
In-Reply-To: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org> (NIIBE Yutaka's
 message of "Tue, 12 Jul 2016 17:06:45 +0900")
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
Message-ID: <87k2grxmnz.fsf@wheatstone.g10code.de>

On Tue, 12 Jul 2016 10:06, gniibe at fsij.org said:

> Recently, I changed the configuration so that gpg-agent is started by
> systemd.  Then, I encounter this issue:

You mean 2.0?  Since 2.1 auto starting the agent is the default and I
don't see why some other software should take part in it.  GnUPG would
not anymore be self-contained.  Anyway.


> DBUS_SESSION_BUS_ADDRESS only, but I think that it should be as same
> as the variable of stdenvnames in common/session-env.c.

Agreed.
 
I would prefer not to maintain a separate list in cmd_updatestartuptty
but to use a function from session-env.c to return the list of envvars.
The sub-command "std_env_names" from cmd_getinfo already does it this
way.



Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From justus at g10code.com  Tue Jul 12 12:20:42 2016
From: justus at g10code.com (Justus Winter)
Date: Tue, 12 Jul 2016 12:20:42 +0200
Subject: [PATCH] fix typo
In-Reply-To: <1468244696-16479-1-git-send-email-dkg@fifthhorseman.net>
References: <1468244696-16479-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <87d1mjqhs5.fsf@europa.jade-hamburg.de>

Applied, thanks!  But please do mind our commit message guidelines, they
can be found in doc/HACKING.

Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160712/c69f9583/attachment.sig>

From mail at tgries.de  Tue Jul 12 18:50:56 2016
From: mail at tgries.de (Thomas Gries)
Date: Tue, 12 Jul 2016 18:50:56 +0200
Subject: Environment variables for UPDATESTARTUPTTY of gpg-agent
In-Reply-To: <87k2grxmnz.fsf@wheatstone.g10code.de>
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
Message-ID: <bef29ba6-e408-9752-8db9-7aaf9d9119a6@tgries.de>

Am 12.07.2016 um 10:53 schrieb Werner Koch:
>> Recently, I changed the configuration so that gpg-agent is started by
>> systemd.  Then, I encounter this issue:
> You mean 2.0?  Since 2.1 auto starting the agent is the default and I
> don't see why some other software should take part in it.  GnUPG would
> not anymore be self-contained.  Anyway.
The problem is, that Debian 8 (Jessie) still has the 2.0x versions, and not
the 2.1x version, and you get these annoying "gnome-keyring hijacked GPG
agent" issue.

gpg (GnuPG) 2.0.26
libgcrypt 1.6.3

Any idea when this will change, and when the 2.1x will become available
in Debian 8 ?



From gniibe at fsij.org  Wed Jul 13 02:41:12 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 13 Jul 2016 09:41:12 +0900
Subject: Environment variables for UPDATESTARTUPTTY of gpg-agent
In-Reply-To: <87k2grxmnz.fsf@wheatstone.g10code.de>
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
Message-ID: <092ec467-5070-87f6-f4b7-13353f9cdbeb@fsij.org>

On 07/12/2016 05:53 PM, Werner Koch wrote:
> On Tue, 12 Jul 2016 10:06, gniibe at fsij.org said:
> 
>> Recently, I changed the configuration so that gpg-agent is started by
>> systemd.  Then, I encounter this issue:
> 
> You mean 2.0?  Since 2.1 auto starting the agent is the default and I
> don't see why some other software should take part in it.  GnUPG would
> not anymore be self-contained.  Anyway.

For my case, it's 2.1.  For desktop, I'm using Debian on Wandboard.
In Debian, gpg-agent used to be started by
/etc/X11/Xsession.d/90gpg-agent.  Now (with 2.1.13-x in experimental),
it is not.

Since I also use gpg-agent for SSH, it makes sense to start gpg-agent
when I login.  Currently, I'm testing systemd.  I think that the
feature of "systemctl --user" is good.

When I use VT console, I want to use to curses version of pinentry on
the terminal, while I want to use window version of pinentry on X.  I
use UPDATESTARTUPTTY of gpg-agent to switch.

> I would prefer not to maintain a separate list in cmd_updatestartuptty
> but to use a function from session-env.c to return the list of envvars.
> The sub-command "std_env_names" from cmd_getinfo already does it this
> way.

Thanks for your suggestion.  I modified following this suggestion.
Tested and pushed.
-- 


From gniibe at fsij.org  Wed Jul 13 03:47:03 2016
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 13 Jul 2016 10:47:03 +0900
Subject: Environment variables for UPDATESTARTUPTTY of gpg-agent
In-Reply-To: <bef29ba6-e408-9752-8db9-7aaf9d9119a6@tgries.de>
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
 <bef29ba6-e408-9752-8db9-7aaf9d9119a6@tgries.de>
Message-ID: <9f271a8f-bcf6-181b-a54e-a1b4ec031a3e@fsij.org>

On 07/13/2016 01:50 AM, Thomas Gries wrote:
> Am 12.07.2016 um 10:53 schrieb Werner Koch:
>>> Recently, I changed the configuration so that gpg-agent is started by
>>> systemd.  Then, I encounter this issue:
>> You mean 2.0?  Since 2.1 auto starting the agent is the default and I
>> don't see why some other software should take part in it.  GnUPG would
>> not anymore be self-contained.  Anyway.
> The problem is, that Debian 8 (Jessie) still has the 2.0x versions, and not
> the 2.1x version, and you get these annoying "gnome-keyring hijacked GPG
> agent" issue.
> 
> gpg (GnuPG) 2.0.26
> libgcrypt 1.6.3
> 
> Any idea when this will change, and when the 2.1x will become available
> in Debian 8 ?

I think that you are talking about different issue.  It's not a
problem of GnuPG (but problem of gnome-keyring), from the viewpoint of
mine.  In Debian, the bug reports in question are:

    SSH service: https://bugs.debian.org/623539
    gpg-agent: https://bugs.debian.org/760102

Per user basis, you can stop gnome-keyring for SSH service:

   https://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/

Or see the last message in 623539.

I do disable SSH service and gpg-agent emulation by gnome-keyring
system wide, because there are no reason to enable these (for me).
See:

    http://www.gniibe.org/memo/notebook/gnome3-gpg-settings.html



I don't know if GnuPG 2.1 will be backported to Jessie or not.  Even
if it will be backported, you need to disable gnome-keyring services
of SSH and gpg-agent emulation (or expect gnome-keyring backport).

While 760102 was closed, I'm not sure about the current status for the
newer version of gnome-keyring interference for SSH service.


Well, I escaped from GNOME3.  However, newer xfce4-session has this
issue:

    https://bugs.debian.org/791378

I did:

  $ xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled -n -t
bool -s false
  $ xfconf-query -c xfce4-session -p /startup/gpg-agent/enabled -n -t
bool -s false

to stop starting gpg-agent and ssh-agent by xfce4-session.
-- 


From mail at tgries.de  Wed Jul 13 10:40:10 2016
From: mail at tgries.de (Thomas Gries)
Date: Wed, 13 Jul 2016 10:40:10 +0200
Subject: Environment variables for UPDATESTARTUPTTY of gpg-agent
In-Reply-To: <9f271a8f-bcf6-181b-a54e-a1b4ec031a3e@fsij.org>
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
 <bef29ba6-e408-9752-8db9-7aaf9d9119a6@tgries.de>
 <9f271a8f-bcf6-181b-a54e-a1b4ec031a3e@fsij.org>
Message-ID: <e9573fa9-a289-d725-3bfa-a8bc77953f2a@tgries.de>

Am 13.07.2016 um 03:47 schrieb NIIBE Yutaka:
> On 07/13/2016 01:50 AM, Thomas Gries wrote:
>> Am 12.07.2016 um 10:53 schrieb Werner Koch:
>>>> Recently, I changed the configuration so that gpg-agent is started by
>>>> systemd.  Then, I encounter this issue:
>>> You mean 2.0?  Since 2.1 auto starting the agent is the default and I
>>> don't see why some other software should take part in it.  GnUPG would
>>> not anymore be self-contained.  Anyway.
>> The problem is, that Debian 8 (Jessie) still has the 2.0x versions, and not
>> the 2.1x version, and you get these annoying "gnome-keyring hijacked GPG
>> agent" issue.
>>
>> gpg (GnuPG) 2.0.26
>> libgcrypt 1.6.3
>>
>> Any idea when this will change, and when the 2.1x will become available
>> in Debian 8 ?
> I think that you are talking about different issue.  It's not a
> problem of GnuPG (but problem of gnome-keyring), from the viewpoint of
> mine.  In Debian, the bug reports in question are:
>
>     SSH service: https://bugs.debian.org/623539
>     gpg-agent: https://bugs.debian.org/760102
>
> Per user basis, you can stop gnome-keyring for SSH service:
>
>    https://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/
>
> Or see the last message in 623539.
>
> I do disable SSH service and gpg-agent emulation by gnome-keyring
> system wide, because there are no reason to enable these (for me).
> See:
>
>     http://www.gniibe.org/memo/notebook/gnome3-gpg-settings.html
>
>
>
I did this *already* on my system long time ago (before your information).
But the (non-) settings appear to have no positive consequences, so I
guess, these auostart setup is ignored on debian8.

gpg2 --card-status
gpg: WARNING: The GNOME keyring manager hijacked the GnuPG agent.
gpg: WARNING: GnuPG will not work properly - please configure that tool
to not interfere with the GnuPG system!


The only way which works for me is to "unset GPG_AGENT_INFO as in (for
example)


$ unset GPG_AGENT_INFO ; icedove &

or

$ unset GPG_AGENT_INFO ; gpg2 --card-status



And as far as I understand, only new GPG versions >= 2.1x will ignore
GPG_AGENT_INFO settings,

So something is totally weird wirg gnome & GPG.

GPG and Debian and Gnome people: *_/please fix it!/_*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160713/eb672d7f/attachment-0001.html>

From dkg at fifthhorseman.net  Wed Jul 13 14:10:27 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 13 Jul 2016 14:10:27 +0200
Subject: launching GnuPG daemons from the system session manager [was: Re:
 Environment variables for UPDATESTARTUPTTY of gpg-agent]
In-Reply-To: <87k2grxmnz.fsf@wheatstone.g10code.de>
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
Message-ID: <87vb09oi18.fsf@alice.fifthhorseman.net>

On Tue 2016-07-12 10:53:20 +0200, Werner Koch wrote:
> You mean 2.0?  Since 2.1 auto starting the agent is the default and I
> don't see why some other software should take part in it.  GnUPG would
> not anymore be self-contained.  Anyway.

The rationale for having systemd manage the daemon startup on systems
that are supported by systemd is twofold:

 * systemd can start up a daemon at login time; if you use gpg-agent for
   ssh before you ever use gpg, gpg-agent will not be automatically
   launched for you by any GnuPG tool if you are only manually invoking
   ssh.

 * systemd can also safely shut down the daemons when the user finally
   logs out.  GnuPG has no explicit support for cleanup/destruction of
   running daemons, since it doesn't know when the user is logging out.

on non-systemd operating systems, the same argument probably applies to
whatever integrated session management they offer.

           --dkg


From neal at walfield.org  Wed Jul 13 14:41:58 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 13 Jul 2016 14:41:58 +0200
Subject: launching GnuPG daemons from the system session manager [was: Re:
 Environment variables for UPDATESTARTUPTTY of gpg-agent]
In-Reply-To: <87vb09oi18.fsf@alice.fifthhorseman.net>
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
 <87vb09oi18.fsf@alice.fifthhorseman.net>
Message-ID: <87eg6xn209.wl-neal@walfield.org>

On Wed, 13 Jul 2016 14:10:27 +0200,
Daniel Kahn Gillmor wrote:
> 
> On Tue 2016-07-12 10:53:20 +0200, Werner Koch wrote:
> > You mean 2.0?  Since 2.1 auto starting the agent is the default and I
> > don't see why some other software should take part in it.  GnUPG would
> > not anymore be self-contained.  Anyway.
> 
> The rationale for having systemd manage the daemon startup on systems
> that are supported by systemd is twofold:
> 
>  * systemd can start up a daemon at login time; if you use gpg-agent for
>    ssh before you ever use gpg, gpg-agent will not be automatically
>    launched for you by any GnuPG tool if you are only manually invoking
>    ssh.
> 
>  * systemd can also safely shut down the daemons when the user finally
>    logs out.  GnuPG has no explicit support for cleanup/destruction of
>    running daemons, since it doesn't know when the user is logging out.
> 
> on non-systemd operating systems, the same argument probably applies to
> whatever integrated session management they offer.

I find it strange that gpg-agent is managed as part of the user's
session when it is independent of the session.  Concretely, if I have
multiple sessions open, e.g., desktop & multiple ssh instances, then I
expect them all to share the same gpg-agent.  Also, I wonder if this
doesn't negatively impact the use of --extra-socket.

:) Neal


From dkg at fifthhorseman.net  Wed Jul 13 15:30:35 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 13 Jul 2016 15:30:35 +0200
Subject: launching GnuPG daemons from the system session manager
In-Reply-To: <87eg6xn209.wl-neal@walfield.org>
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
 <87vb09oi18.fsf@alice.fifthhorseman.net> <87eg6xn209.wl-neal@walfield.org>
Message-ID: <87eg6xoebo.fsf@alice.fifthhorseman.net>

On Wed 2016-07-13 14:41:58 +0200, Neal H. Walfield wrote:
> I find it strange that gpg-agent is managed as part of the user's
> session when it is independent of the session.  Concretely, if I have
> multiple sessions open, e.g., desktop & multiple ssh instances, then I
> expect them all to share the same gpg-agent.  Also, I wonder if this
> doesn't negatively impact the use of --extra-socket.

You'll be happy to learn that this is exactly what systemd's --user
handling does, actually :) I think i was using the term "session"
loosely above, so let me try to be more specific.

In systemd, there is a "slice" allocated to each user, which contains
their user-specific systemd service process manager.  This slice
operates concurrently with every existing login session.  If there are
no login sessions, then the user's service management is terminated.  As
soon as the user's first session begins, the slice starts up the
services.

I might still be using the terms sloppily -- sorry!  Below is some
example structured output from "systemctl status" from my machine
"alice" that might make things clearer.  My user account is id 1234, and
i'm logged in via both an X11 login (session-13, triggered by "startx"
in this case) and on a second vt (session-449):

-------------
? alice
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Fri 2016-07-08 12:10:29 CEST; 5 days ago
   CGroup: /
           ??init.scope
           ? ??1 /lib/systemd/systemd --switched-root --system --deserialize 23
           ??system.slice
           ? ??dbus.service
           ? ? ??2049 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
           ? ??cron.service
           ? ? ??3592 /usr/sbin/cron -f
           ?[?]
           ? ??smartd.service
           ?   ??2061 /usr/sbin/smartd -n
           ??user.slice
             ??user-1234.slice
               ??session-13.scope
               ? ?? 2708 /bin/sh /usr/bin/startx
               ? ?? 2758 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /home/dkg/tmp/serverauth.QQfVGkGhWJ
               ? ?? 2759 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /home/dkg/tmp/serverauth.QQfVGkGhWJ
               ? ?? 2790 /usr/bin/dbus-launch --exit-with-session --sh-syntax
               ? ?? 2791 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
               ? ?? 2818 /usr/bin/openbox --startup /usr/lib/x86_64-linux-gnu/openbox-autostart OPENBOX
               ?[?]
               ? ??31291 rxvt -geometry 80x26
               ? ??31292 bash
               ? ??31308 systemctl status
               ??user at 1234.service
               ? ??gpg-agent.service
               ? ? ??2705 /usr/bin/gpg-agent --daemon --homedir /home/dkg/.gnupg
               ? ??dirmngr.service
               ? ? ??18958 /usr/bin/dirmngr --daemon --homedir /home/dkg/.gnupg
               ? ??init.scope
               ?   ??2696 /lib/systemd/systemd --user
               ?   ??2698 (sd-pam)                                                      
               ??session-449.scope
                 ?? 2408 /bin/login --    
                 ??31401 -bash

-------------

As you can see, user at 1234.service is managed independently from
session-13.scope and session-449.scope.  when i terminate both sessions,
and if no other scopes exist in my user slice, then systemd should tear
down user at 1234.service and all its dependent services.

I end up with clean automated startup and safe automated teardown that
coincides with the times that i'm actually authenticated to the machine,
regardless of how many sessions i have running concurrently.

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20160713/704ad0cf/attachment.sig>

From neal at walfield.org  Wed Jul 13 15:41:12 2016
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 13 Jul 2016 15:41:12 +0200
Subject: launching GnuPG daemons from the system session manager
In-Reply-To: <87eg6xoebo.fsf@alice.fifthhorseman.net>
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
 <87vb09oi18.fsf@alice.fifthhorseman.net>
 <87eg6xn209.wl-neal@walfield.org>
 <87eg6xoebo.fsf@alice.fifthhorseman.net>
Message-ID: <87d1mhmz9j.wl-neal@walfield.org>

Hi,

On Wed, 13 Jul 2016 15:30:35 +0200,
Daniel Kahn Gillmor wrote:
> On Wed 2016-07-13 14:41:58 +0200, Neal H. Walfield wrote:
> > I find it strange that gpg-agent is managed as part of the user's
> > session when it is independent of the session.  Concretely, if I have
> > multiple sessions open, e.g., desktop & multiple ssh instances, then I
> > expect them all to share the same gpg-agent.  Also, I wonder if this
> > doesn't negatively impact the use of --extra-socket.
> 
> You'll be happy to learn that this is exactly what systemd's --user
> handling does, actually :) I think i was using the term "session"
> loosely above, so let me try to be more specific.

Great!  This is (was?) a serious problem with D-Bus: there is a
session bus and a system bus, but no user bus.

> In systemd, there is a "slice" allocated to each user, which contains
> their user-specific systemd service process manager.  This slice
> operates concurrently with every existing login session.  If there are
> no login sessions, then the user's service management is terminated.  As
> soon as the user's first session begins, the slice starts up the
> services.
...
> I end up with clean automated startup and safe automated teardown that
> coincides with the times that i'm actually authenticated to the machine,
> regardless of how many sessions i have running concurrently.

This is quite nice, but I wonder if gpg-agent shouldn't persist or at
least persist for a little while and only be shutdown if there is no
new login within, say, 10 minutes.  Is that possible?  Do you agree
this makes sense?

Thanks!

:) neal


From wk at gnupg.org  Wed Jul 13 16:51:07 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 13 Jul 2016 16:51:07 +0200
Subject: launching GnuPG daemons from the system session manager
In-Reply-To: <87vb09oi18.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 13 Jul 2016 14:10:27 +0200")
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
 <87vb09oi18.fsf@alice.fifthhorseman.net>
Message-ID: <87shvdsias.fsf@wheatstone.g10code.de>

On Wed, 13 Jul 2016 14:10, dkg at fifthhorseman.net said:

>  * systemd can start up a daemon at login time; if you use gpg-agent for
>    ssh before you ever use gpg, gpg-agent will not be automatically
>    launched for you by any GnuPG tool if you are only manually invoking

You don't need to have systemd for this.  A simple "gpgconf --lauch
gpg-agent" in your login script does the same.

>  * systemd can also safely shut down the daemons when the user finally
>    logs out.  GnuPG has no explicit support for cleanup/destruction of
>    running daemons, since it doesn't know when the user is logging out.

You can do the same in .xesssion or another logout script.  It is a bit
more complicated but Unix has all the tools to do that.  And you have
full control on how to do that.

I don't want to start another systemd discussion here.  Those who like
that windowsiation of our precious Unix software, shall go for it.



Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From dkg at fifthhorseman.net  Wed Jul 13 18:48:11 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 13 Jul 2016 18:48:11 +0200
Subject: launching GnuPG daemons from the system session manager
In-Reply-To: <87shvdsias.fsf@wheatstone.g10code.de>
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
 <87vb09oi18.fsf@alice.fifthhorseman.net>
 <87shvdsias.fsf@wheatstone.g10code.de>
Message-ID: <87a8hlo56c.fsf@alice.fifthhorseman.net>

On Wed 2016-07-13 16:51:07 +0200, Werner Koch wrote:
> On Wed, 13 Jul 2016 14:10, dkg at fifthhorseman.net said:
>
>>  * systemd can start up a daemon at login time; if you use gpg-agent for
>>    ssh before you ever use gpg, gpg-agent will not be automatically
>>    launched for you by any GnuPG tool if you are only manually invoking
>
> You don't need to have systemd for this.  A simple "gpgconf --lauch
> gpg-agent" in your login script does the same.

agreed.

>>  * systemd can also safely shut down the daemons when the user finally
>>    logs out.  GnuPG has no explicit support for cleanup/destruction of
>>    running daemons, since it doesn't know when the user is logging out.
>
> You can do the same in .xesssion or another logout script.  It is a bit
> more complicated but Unix has all the tools to do that.  And you have
> full control on how to do that.

Also agreed, including that it's a bit more complicated, especially when
there are multiple concurrent sessions for the same user.

The reason i care here is i'm hoping to provide a simple and automatic
default experience for users who don't even know that they have login or
logout scripts, let alone how to edit them or what to put in them.

Users on such a system are still in full control -- they don't have to
enable (and can explicitly disable or mask) the systemd services, and
they can handle their login and logout scripts exactly as before as
well.

If these session scripts were already in place and were automatically
run by users without them having to do anything they didn't understand,
i'd happily integrate them into debian.  However, the scripts we've had
available thus far didn't do both setup and teardown cleanly; systemd
does.

I welcome patches for integrating these daemons automatically on
machines that don't run systemd.  We've had ongoing problems with either
setup or teardown in the fragile scripts we've shipped for years in
/etc/X11/Xsession.d/ -- so if someone wants to propose another solution
i'd be glad to see it.

Regards,

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20160713/c4a7f6a3/attachment.sig>

From wk at gnupg.org  Thu Jul 14 15:46:43 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 14 Jul 2016 15:46:43 +0200
Subject: [PATCH] dirmngr: fix handling of HTTP redirections
In-Reply-To: <1464533742-16455-1-git-send-email-dgouttegattat@incenp.org>
 (Damien Goutte-Gattat's message of "Sun, 29 May 2016 16:55:42 +0200")
References: <1456f449-ffc5-b793-d51d-ca4922b115a5@incenp.org>
 <1464533742-16455-1-git-send-email-dgouttegattat@incenp.org>
Message-ID: <874m7spc1o.fsf@wheatstone.g10code.de>

On Sun, 29 May 2016 16:55, dgouttegattat at incenp.org said:
>> So it does look like a bug in the handling of HTTP redirections.
>
> I dug a little further, and I came up with a possible fix.

Thanks.  I just pushed it and thus it will be available in 2.1.14.

Sorry for the delay.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From wk at gnupg.org  Thu Jul 14 17:59:58 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 14 Jul 2016 17:59:58 +0200
Subject: [Announce] Libgcrypt 1.7.2 released
Message-ID: <87r3awnrb5.fsf@wheatstone.g10code.de>

Hello!

The GnuPG Project is pleased to announce the availability of Libgcrypt
version 1.7.2.  This is a maintenace release.

Libgcrypt is a general purpose library of cryptographic building blocks.
It is originally based on code used by GnuPG.  It does not provide any
implementation of OpenPGP or other protocols.  Thorough understanding of
applied cryptography is required to use Libgcrypt.


Noteworthy changes in version 1.7.2
===================================

 * Bug fixes:

   - Fix setting of the ECC cofactor if parameters are specified.

   - Fix memory leak in the ECC code.

   - Remove debug message about unsupported getrandom syscall.

   - Fix build problems related to AVX use.

   - Fix bus errors on ARM for Poly1305, ChaCha20, AES, and SHA-512.

 * Internal changes:

   - Improved fatal error message for wrong use of gcry_md_read.

   - Disallow symmetric encryption/decryption if key is not set.


Download
========

Source code is hosted at the GnuPG FTP server and its mirrors as listed
at https://gnupg.org/download/mirrors.html .  On the primary server
the source tarball and its digital signature are:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.bz2 (2778k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.bz2.sig

That file is bzip2 compressed.  A gzip compressed version is here:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.gz (3318k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.gz.sig

The same files are also available via HTTP:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.bz2 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.bz2.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.gz 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.gz.sig

In order to check that the version of Libgcrypt you downloaded is an
original and unmodified file please follow the instructions found at
<https://gnupg.org/download/integrity_check.html>.  In short, you may
use one of the following methods:

 - Check the supplied OpenPGP signature.  For example to check the
   signature of the file libgcrypt-1.7.2.tar.bz2 you would use this
   command:

     gpg --verify libgcrypt-1.7.2.tar.bz2.sig libgcrypt-1.7.2.tar.bz2

   This checks whether the signature file matches the source file.  You
   should see a message indicating that the signature is good and made
   by one or more of the release signing keys. 

 - If you are not able to use GnuPG, you have to verify the SHA-1
   checksum:

     sha1sum libgcrypt-1.7.2.tar.bz2

   and check that the output matches the first line from the
   this list:

85a6a936bcab4c3c05f5efbf6ce847f23d35c0c4  libgcrypt-1.7.2.tar.bz2
8e34352e21744fe3fb0558f9d6af6b69e18cb563  libgcrypt-1.7.2.tar.gz

   You should also verify that the checksums above are authentic by
   matching them with copies of this announcement.  Those copies can be
   found at other mailing lists, web sites, and search engines.
   

Copying
=======

Libgcrypt is distributed under the terms of the GNU Lesser General
Public License (LGPLv2.1+).  The helper programs as well as the
documentation are distributed under the terms of the GNU General Public
License (GPLv2+).  The file LICENSES has notices about contributions
that require that these additional notices are distributed.


Support
=======

For help on developing with Libgcrypt you should read the included
manual and optional ask on the gcrypt-devel mailing list [1].  A
listing with commercial support offers for Libgcrypt and related
software is available at the GnuPG web site [2].

If you are a developer and you may need a certain feature for your
project, please do not hesitate to bring it to the gcrypt-devel
mailing list for discussion.

Maintenance and development of Libgcrypt is mostly financed by
donations; see <https://gnupg.org/donate/>.  We currently employ
3 full-time developers, one part-timer, and one contractor to work on
GnuPG and closely related software like Libgcrypt.


Thanks
======

We like to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.  Also many thanks to all our donors [3].


For the GnuPG hackers,

   Werner



p.s.
This is an announcement only mailing list.  Please send replies only to
the gcrypt-devel 'at' gnupg.org mailing list.


[1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
[2] https://www.gnupg.org/service.html
[3] https://gnupg.org/donate/kudos.html

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: </pipermail/attachments/20160714/04185faf/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From wk at gnupg.org  Thu Jul 14 17:55:34 2016
From: wk at gnupg.org (Werner Koch)
Date: Thu, 14 Jul 2016 17:55:34 +0200
Subject: [Announce] GnuPG 2.1.14 released
Message-ID: <87vb08nrih.fsf@wheatstone.g10code.de>

Hello!

The GnuPG team is pleased to announce the availability of a new release
of GnuPG modern: Version 2.1.14.  See below for a list of new features
and bug fixes.


About GnuPG
=============

The GNU Privacy Guard (GnuPG) is a complete and free implementation
of the OpenPGP standard which is commonly abbreviated as PGP.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  A wealth of frontend applications
and libraries making use of GnuPG are available.  Since version 2 GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom). It can
be freely used, modified and distributed under the terms of the GNU
General Public License.

Three different branches of GnuPG are actively maintained:

- GnuPG "modern" (2.1) is the latest development with a lot of new
  features.  This announcement is about this branch.

- GnuPG "stable" (2.0) is the current stable version for general use.
  This is what most users are still using.

- GnuPG "classic" (1.4) is the old standalone version which is most
  suitable for older or embedded platforms.

You may not install "modern" (2.1) and "stable" (2.0) at the same
time.  However, it is possible to install "classic" (1.4) along with
any of the other versions.


Noteworthy changes in version 2.1.14
====================================

 * gpg: Removed options --print-dane-records and --print-pka-records.
   The new export options "export-pka" and "export-dane" can instead
   be used with the export command.

 * gpg: New options --import-filter and --export-filter.

 * gpg: New import options "import-show" and "import-export".

 * gpg: New option --no-keyring.

 * gpg: New command --quick-revuid.

 * gpg: New options -f/--recipient-file and -F/--hidden-recipient-file
   to directly specify encryption keys.

 * gpg: New option --mimemode to indicate that the content is a MIME
   part.  Does only enable --textmode right now.

 * gpg: New option --rfc4880bis to allow experiments with proposed
   changes to the current OpenPGP specs.

 * gpg: Fix regression in the "fetch" sub-command of --card-edit.

 * gpg: Fix regression since 2.1 in option --try-all-secrets.

 * gpgv: Change default options for extra security.

 * gpgsm: No more root certificates are installed by default.

 * agent: "updatestartuptty" does now affect more environment
   variables.

 * scd: The option --homedir does now work with scdaemon.

 * scd: Support some more GEMPlus card readers.

 * gpgtar: Fix handling of '-' as file name.

 * gpgtar: New commands --create and --extract.

 * gpgconf: Tweak for --list-dirs to better support shell scripts.

 * tools: Add programs gpg-wks-client and gpg-wks-server to implement
   a Web Key Service.  The configure option --enable-wks-tools is
   required to build them; they should be considered Beta software.

 * tests: Complete rework of the openpgp part of the test suite.  The
   test scripts have been changed from Bourne shell scripts to Scheme
   programs.  A customized scheme interpreter (gpgscm) is included.
   This change was triggered by the need to run the test suite on
   non-Unix platforms.

 * The rendering of the man pages has been improved.

A detailed description of the changes found in the 2.1 branch can be
found at <https://gnupg.org/faq/whats-new-in-2.1.html>.

Please be aware that there are still known bugs which we are working on.
Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing
list archives for known problems and workarounds.


Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG 2.1.14 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.14.tar.bz2  (5572k)
 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.14.tar.bz2.sig
or here:
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.14.tar.bz2
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.14.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
minimal Pinentry tool is available here:

 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.14_20160714.exe  (3576k)
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.14_20160714.exe.sig
or here
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.14_20160714.exe
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.14_20160714.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.  This Windows installer comes with
Tofu support, translations, and support for Tor and the Tor browser.  It
is still missing HKPS support, though.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.1.14.tar.bz2 you would use this command:

     gpg --verify gnupg-2.1.14.tar.bz2.sig gnupg-2.1.14.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See below for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.1.14.tar.bz2, you run the command like this:

     sha1sum gnupg-2.1.14.tar.bz2

   and check that the output matches the next line:

bc7609a3a0daf0ed0efb22f77b43e82f28e20e34  gnupg-2.1.14.tar.bz2
8871e1b596a208403c7240498fa3d83c33ced4b2  gnupg-w32-2.1.14_20160714.exe
0d7f8831966dac737a15feae44ac78f6cce54fee  gnupg-w32-2.1.14_20160714.tar.xz


Release Signing Keys
====================

To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these four keys:

  2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048/E0856959 2014-10-29 [expires: 2019-12-31]
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>

  rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31]
  Key fingerprint = D238 EA65 D64C 67ED 4C30  73F2 8A86 1B1C 7EFD 60D9
  Werner Koch (Release Signing Key)

You may retrieve these keys from a keyserver using this command

  gpg --keyserver hkp://keys.gnupg.net --recv-keys  \
                  249B39D24F25E3B6 04376F3EE0856959 \
                  2071B08A33BD3F06 8A861B1C7EFD60D9

The keys are also available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese, Czech,
French, German, Japanese, Norwegian, Russian, and Ukrainian being almost
completely translated (2174 different strings).


Documentation
=============

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

The file gnupg.info has the complete user manual of the system.
Separate man pages are included as well but they have not all the
details available as are the manual.  It is also possible to read the
complete manual online in HTML format at

  https://gnupg.org/documentation/manuals/gnupg/

or in Portable Document Format at

  https://gnupg.org/documentation/manuals/gnupg.pdf .

The chapters on gpg-agent, gpg and gpgsm include information on how
to set up the whole thing.  You may also want search the GnuPG mailing
list archives or ask on the gnupg-users mailing lists for advise on
how to solve problems.  Many of the new features are around for
several years and thus enough public knowledge is already available.

You may also want to follow our postings at <https://gnupg.org/blob/>
and <https://twitter.com/gnupg>.


Support
========

Please consult the archive of the gnupg-users mailing list before
reporting a bug <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  If you need commercial
support check out <https://gnupg.org/service.html>.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project employs 3 full-time developers, one part-timer, and
one contractor.  They all work on GnuPG and closely related software
like Libgcrypt and GPA.  Please consider to donate via:

  https://gnupg.org/donate/



Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, answering questions on the mailing
lists, and donating money.

See you at OpenPGP.conf <https://openpgp-conf.org>.

For the GnuPG hackers,

   Werner


p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users'at'gnupg.org mailing list.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: </pipermail/attachments/20160714/59a43414/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From dkg at fifthhorseman.net  Fri Jul 15 02:52:25 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 15 Jul 2016 02:52:25 +0200
Subject: 2.1.14: tests/openpgp/gpgtar.scm failing under --disable-gpgtar
Message-ID: <878tx3lo3a.fsf@alice.fifthhorseman.net>

It looks like the gpgtar test fails when gpgtar is not built.

tests/openpgp/gpgtar.scm tries to address this with:

(unless (= 0 (call `(,(tool 'gpgtar) --help)))
	(skip "gpgtar not installed"))

but it looks like gpgscm chokes instead.  When building with ./configure
--disable-gpgtar, i get the following test suite failure:

gpgscm: error running '("/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgtar" --help)': probably not installed
(wait-process "(\"/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgtar\" --help)" 10504 #t): Configuration error 
FAIL: gpgtar.scm

let me know if you're unable to replicate the problem.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20160715/4cf346ba/attachment.sig>

From dkg at fifthhorseman.net  Fri Jul 15 03:06:12 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 15 Jul 2016 03:06:12 +0200
Subject: 2.1.14: tests/openpgp/gpgtar.scm failing under --disable-gpgtar
In-Reply-To: <878tx3lo3a.fsf@alice.fifthhorseman.net>
References: <878tx3lo3a.fsf@alice.fifthhorseman.net>
Message-ID: <8760s7lngb.fsf@alice.fifthhorseman.net>

On Fri 2016-07-15 02:52:25 +0200, Daniel Kahn Gillmor wrote:
> It looks like the gpgtar test fails when gpgtar is not built.

In addition, the tests in GnuPG 2.1.14's tests/migration/ directory both
fail with ./configure --disable-gpgtar:


make[4]: Entering directory '/home/dkg/src/pkg-gnupg/gnupg2/build/tests/migrations'
Testing a clean migration ... 
gpgscm: error running '("/home/dkg/src/pkg-gnupg/gnupg2/build/tests/migrations/../../tools/gpgtar" --extract --directory=. -)': probably not installed
(wait-processes ("(\"/home/dkg/src/pkg-gnupg/gnupg2/build/tests/migrations/../../tools/gpgtar\" --extract --directory=. -)" "(\"/home/dkg/src/pkg-gnupg/gnupg2/build/tests/migrations/../../g10/gpg\" --no-permission-warning --no-greeting --no-secmem-warning --batch \"--agent-program=/home/dkg/src/pkg-gnupg/gnupg2/build/tests/migrations/../../agent/gpg-agent|--debug-quick-random\" --dearmor)") (1653 1652) #t): Configuration error 
FAIL: from-classic.scm
Testing the extended private key format ... 
gpgscm: error running '("/home/dkg/src/pkg-gnupg/gnupg2/build/tests/migrations/../../tools/gpgtar" --extract --directory=. -)': probably not installed
(wait-processes ("(\"/home/dkg/src/pkg-gnupg/gnupg2/build/tests/migrations/../../tools/gpgtar\" --extract --directory=. -)" "(\"/home/dkg/src/pkg-gnupg/gnupg2/build/tests/migrations/../../g10/gpg\" --no-permission-warning --no-greeting --no-secmem-warning --batch \"--agent-program=/home/dkg/src/pkg-gnupg/gnupg2/build/tests/migrations/../../agent/gpg-agent|--debug-quick-random\" --dearmor)") (1660 1659) #t): Configuration error 
FAIL: extended-pkf.scm
=======================================
2 of 2 tests failed
Please report to https://bugs.gnupg.org
=======================================

        --dkg


From dkg at fifthhorseman.net  Fri Jul 15 03:39:37 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 15 Jul 2016 03:39:37 +0200
Subject: 2.1.14 -- dropping qualified.txt and com-certs.pem
Message-ID: <871t2vllwm.fsf@alice.fifthhorseman.net>

hi GnuPG folks--

in 2.1.14, c19b2061274cd50838e62a2acbdc7e7d24888e7e says:

   sm: Do not install cacert and other root certificates.
    
    * doc/Makefile.am (dist_pkgdata_DATA): Move qualified.txt and
    com-certs.pem to ...
    (EXTRA_DIST): here.
    --
    
    With Let's Encrypt there is no more need to push CA Cert.
    
    Signed-off-by: Werner Koch <wk at gnupg.org>

The result is that a "make install" ends up not shipping either
/usr/share/gnupg/com-certs.pem or /usr/share/gnupg/qualified.txt

The justification about Let's Encrypt covers CA Cert, but moving these
files to not be installed by "make install" seems like it also has an
effect on the STEED "nonthority" and on the list of qualified German
network authorities -- do you envision Let's Encrypt taking over both of
those roles as well?  Also, should GnuPG ship the Let's Encrypt
authority's certificate instead?  If not, how will users know how to
validate LE-signed sites?

Moreover, the info for gpgsm in 2.1.14 still implies that GnuPG ships
both files.

As a distributor, i'd like to ship documentation that matches what's
installed.  I see four options for the debian packaging:

 0) clean up the info/man pages to not claim that any of these files will
    be installed.

 1) go ahead and keep shipping the files from the source repo (they're
    still present) even though they aren't installed by "make install"

 2) decide on some new CAs to trust, write our own qualified.txt file,
    and install them both.

 3) point to other CA lists already installed by the OS, and generate
    qualified.txt from the same sort of system-level defaults (i don't
    know how to do this right now)

What do you think distros should do with this situation?

Thanks for the update and the new release!

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20160715/30b23c13/attachment.sig>

From patrick at enigmail.net  Fri Jul 15 10:20:21 2016
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Fri, 15 Jul 2016 10:20:21 +0200
Subject: GnuPG 2.1.14: errors with tests/gpgscm
Message-ID: <73c44165-1e6a-cd32-f4dc-9e09bc179516@enigmail.net>

tests/gpgscm is failing with:

gcc -imacros scheme-config.h -I/Users/pbr/enigmail/gpg21/dist64/include
-I/Users/pbr/enigmail/gpg21/dist64/include
-I/Users/pbr/enigmail/gpg21/dist64/include -Wall -Wno-pointer-sign
-Wpointer-arith  -arch x86_64 -Ofast
-L/Users/pbr/enigmail/gpg21/dist64/lib -arch x86_64
-L/Users/pbr/enigmail/gpg21/dist64/lib -o gpgscm gpgscm-main.o
gpgscm-ffi.o gpgscm-scheme.o  ../../common/libcommon.a
/Users/pbr/enigmail/gpg21/dist64/lib/libiconv.dylib -lreadline
-L/Users/pbr/enigmail/gpg21/dist64/lib -lgcrypt -lgpg-error
-L/Users/pbr/enigmail/gpg21/dist64/lib -lgpg-error

Undefined symbols for architecture x86_64:
  "_libintl_bind_textdomain_codeset", referenced from:
      _i18n_switchto_utf8 in libcommon.a(libcommon_a-i18n.o)
      _i18n_switchback in libcommon.a(libcommon_a-i18n.o)
      _i18n_utf8 in libcommon.a(libcommon_a-i18n.o)
[...]

It looks like like the Makefile is missing -lintl

I tried to build gpg 2.1.14 with --disable-tests, but tests/gpgscm is
built nevertheless

-Patrick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160715/ed80dd77/attachment-0001.sig>

From aheinecke at intevation.de  Fri Jul 15 10:32:13 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Fri, 15 Jul 2016 10:32:13 +0200
Subject: 2.1.14 -- dropping qualified.txt and com-certs.pem
In-Reply-To: <871t2vllwm.fsf@alice.fifthhorseman.net>
References: <871t2vllwm.fsf@alice.fifthhorseman.net>
Message-ID: <3358490.Ulsq1MHhmJ@esus>

Hi,

On Friday 15 July 2016 03:39:37 Daniel Kahn Gillmor wrote:
> hi GnuPG folks--
> 
> in 2.1.14, c19b2061274cd50838e62a2acbdc7e7d24888e7e says:
> 
>    sm: Do not install cacert and other root certificates.
...
> The result is that a "make install" ends up not shipping either
> /usr/share/gnupg/com-certs.pem or /usr/share/gnupg/qualified.txt

I requested the removal because now that Gpg4win uses the "official" 2.1 
installer internally we ended up importing these certificates and on the first 
Launch of Kleopatra users would have been asked if they should be trusted 
(allow-mark-trusted) which was bad. They also showed up as the only two 
certificates available after a fresh install which was also weird.
(Same also happend on GNU/Linux of course)

> The justification about Let's Encrypt covers CA Cert, but moving these
> files to not be installed by "make install" seems like it also has an
> effect on the STEED "nonthority" and on the list of qualified German
> network authorities -- do you envision Let's Encrypt taking over both of
> those roles as well?  Also, should GnuPG ship the Let's Encrypt
> authority's certificate instead?  If not, how will users know how to
> validate LE-signed sites?

My opinion is that Let's encrypt should have nothing to do with the removal. 
GnuPG should not be distributing "Trust" (apart from the release keys gnupg 
also controls to verify update integrity). CA trust should be set up by the 
Administrator as it's mostly an organisation policy thing.

> Moreover, the info for gpgsm in 2.1.14 still implies that GnuPG ships
> both files.

That should probably be fixed.

> 
> As a distributor, i'd like to ship documentation that matches what's
> installed.  I see four options for the debian packaging:
> 
>  0) clean up the info/man pages to not claim that any of these files will
>     be installed.

Yes, that would probably be best.

>  1) go ahead and keep shipping the files from the source repo (they're
>     still present) even though they aren't installed by "make install"

Imo they should be removed from the repo, too.

>  2) decide on some new CAs to trust, write our own qualified.txt file,
>     and install them both.

In that case they should be more appropiately be written down in the 
trustlist.txt and provided through dirmngr's extra-certs / trusted-certs 
mechanismn.

This means they will be avilable and trusted if needed but won't show up in 
the keyring of the user unless they are needed. This is how we are set up at 
my Company so that the German PKI infrastructure is available if neccessary 
but does not show up by default.

Afaik Qualified is just some extra thingy that is afaik not much used in 
practice.  It only marks that signatures verified by one of these chains have a 
special marker. (But I could be wrong)
As this doesn't imply trust but only provides some extra information about 
legality of Signatures in some countries I'm ok with distributing it. But the 
current list is completely outdated (afaik there is not one valid certificate 
in there anymore) so better to remove it if it is unmaintained.
 
>  3) point to other CA lists already installed by the OS, and generate
>     qualified.txt from the same sort of system-level defaults (i don't
>     know how to do this right now)

I would also be against this. For Windows it would mean to integrate 
with the Windows system store but that means that you will have > 100 Root 
CA's trusted for signatures and users may wish to keep that number much lower. 
Eg. only CA's that the Administrators have checked.

> What do you think distros should do with this situation?

Don't install any certificates but have nice documentation how to set up a Root 
CA base for System Administrators :-)


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: 648 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160715/dc12757d/attachment.sig>

From justus at g10code.com  Fri Jul 15 11:19:24 2016
From: justus at g10code.com (Justus Winter)
Date: Fri, 15 Jul 2016 11:19:24 +0200
Subject: GnuPG 2.1.14: errors with tests/gpgscm
In-Reply-To: <73c44165-1e6a-cd32-f4dc-9e09bc179516@enigmail.net>
References: <73c44165-1e6a-cd32-f4dc-9e09bc179516@enigmail.net>
Message-ID: <87twfrjm1v.fsf@europa.jade-hamburg.de>

Hi Patrick :)

Patrick Brunschwig <patrick at enigmail.net> writes:
> tests/gpgscm is failing with:
>
> [...]
>
> It looks like like the Makefile is missing -lintl

Thanks for reporting.  Having said that, I did ask to test this on other
platforms some months ago, we could have caught this earlier...

From the paths I guess this is on MacOS?

> I tried to build gpg 2.1.14 with --disable-tests, but tests/gpgscm is
> built nevertheless

Good point.


Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160715/321eb985/attachment.sig>

From wk at gnupg.org  Fri Jul 15 11:43:59 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 15 Jul 2016 11:43:59 +0200
Subject: 2.1.14 -- dropping qualified.txt and com-certs.pem
In-Reply-To: <871t2vllwm.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Fri, 15 Jul 2016 03:39:37 +0200")
References: <871t2vllwm.fsf@alice.fifthhorseman.net>
Message-ID: <878tx3me1s.fsf@wheatstone.g10code.de>

On Fri, 15 Jul 2016 03:39, dkg at fifthhorseman.net said:

> The result is that a "make install" ends up not shipping either
> /usr/share/gnupg/com-certs.pem or /usr/share/gnupg/qualified.txt

Right. 

For com-certs.pem.  We don't want to decide which root CAs are good (if
there are any at all).  In the pas ca-cert was distributed to give it a
push but cacert never took off except for geeks.  Well, there is one
exception: the certifciate for sks-keyservers.net.

The qualified.txt had only expired certificates and was thus useless.
Also the rules for qualified signatures changes a a couple of years ago.
It is not anymore possible to have a definitive list of root
certificates to indicate a certificate used for qualified signatures.
That whole qualified signature system is FUBAR.

> authority's certificate instead?  If not, how will users know how to
> validate LE-signed sites?

dirmngr uses the system provided certificates.

> As a distributor, i'd like to ship documentation that matches what's
> installed.  I see four options for the debian packaging:
>
>  0) clean up the info/man pages to not claim that any of these files will
>     be installed.

Okay, will do.

>  1) go ahead and keep shipping the files from the source repo (they're
>     still present) even though they aren't installed by "make install"

Isn't this a task for Debian's voliatile repo?

>  2) decide on some new CAs to trust, write our own qualified.txt file,
>     and install them both.

See above.

>  3) point to other CA lists already installed by the OS, and generate
>     qualified.txt from the same sort of system-level defaults (i don't
>     know how to do this right now)

See above


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From wk at gnupg.org  Fri Jul 15 12:02:39 2016
From: wk at gnupg.org (Werner Koch)
Date: Fri, 15 Jul 2016 12:02:39 +0200
Subject: 2.1.14: tests/openpgp/gpgtar.scm failing under --disable-gpgtar
In-Reply-To: <878tx3lo3a.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Fri, 15 Jul 2016 02:52:25 +0200")
References: <878tx3lo3a.fsf@alice.fifthhorseman.net>
Message-ID: <874m7rmd6o.fsf@wheatstone.g10code.de>

On Fri, 15 Jul 2016 02:52, dkg at fifthhorseman.net said:
> It looks like the gpgtar test fails when gpgtar is not built.

We use gpgtar to unpack a couple of test files which would otherwise
reach the gile length limit of tar.  We should better require gpgtar if
tests are built.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From dkg at fifthhorseman.net  Fri Jul 15 12:28:44 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 15 Jul 2016 12:28:44 +0200
Subject: 2.1.14: tests/openpgp/gpgtar.scm failing under --disable-gpgtar
In-Reply-To: <874m7rmd6o.fsf@wheatstone.g10code.de>
References: <878tx3lo3a.fsf@alice.fifthhorseman.net>
 <874m7rmd6o.fsf@wheatstone.g10code.de>
Message-ID: <87inw78aar.fsf@alice.fifthhorseman.net>

On Fri 2016-07-15 12:02:39 +0200, Werner Koch <wk at gnupg.org> wrote:
> On Fri, 15 Jul 2016 02:52, dkg at fifthhorseman.net said:
>> It looks like the gpgtar test fails when gpgtar is not built.
>
> We use gpgtar to unpack a couple of test files which would otherwise
> reach the gile length limit of tar.  We should better require gpgtar if
> tests are built.

or just remove the --{dis,en}able-gpgtar configure option entirely if
it's not really optional.  surely we want people building and running
the test suite?

    --dkg


From dkg at fifthhorseman.net  Fri Jul 15 12:38:25 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 15 Jul 2016 12:38:25 +0200
Subject: 2.1.14 -- dropping qualified.txt and com-certs.pem
In-Reply-To: <878tx3me1s.fsf@wheatstone.g10code.de>
References: <871t2vllwm.fsf@alice.fifthhorseman.net>
 <878tx3me1s.fsf@wheatstone.g10code.de>
Message-ID: <87furb89um.fsf@alice.fifthhorseman.net>

Hi Werner and Andre--

thanks for your fast responses.

On Fri 2016-07-15 11:43:59 +0200, Werner Koch <wk at gnupg.org> wrote:
> For com-certs.pem.  We don't want to decide which root CAs are good (if
> there are any at all).  In the pas ca-cert was distributed to give it a
> push but cacert never took off except for geeks.  Well, there is one
> exception: the certifciate for sks-keyservers.net.
>
> The qualified.txt had only expired certificates and was thus useless.
> Also the rules for qualified signatures changes a a couple of years ago.
> It is not anymore possible to have a definitive list of root
> certificates to indicate a certificate used for qualified signatures.
> That whole qualified signature system is FUBAR.

ok, this makes sense.  Would it also make sense, then, to look for
com-certs.pem and qualified.txt (if gpgsm looks for them at all) in
/etc/gnupg/ instead of /usr/share/gnupg/ ?  /etc is typically under
control of the local system administrator, while /usr/share/gnupg is
expected to be maintained by the package.

If the theory is that the package has no business shipping generic
certificate authorities (with a special carve-out for the SKS pool) then
/etc/ seems like the better place.

>> authority's certificate instead?  If not, how will users know how to
>> validate LE-signed sites?
>
> dirmngr uses the system provided certificates.

hm, i'm not actually seeing this behavior, but that's probably a
separate thread.

>>  0) clean up the info/man pages to not claim that any of these files will
>>     be installed.
>
> Okay, will do.

great, thanks!

>>  1) go ahead and keep shipping the files from the source repo (they're
>>     still present) even though they aren't installed by "make install"
>
> Isn't this a task for Debian's voliatile repo?

it's been called "stable-updates" since squeeze -- but sure, we can make
a separate package to handle standard certs if someone has a proposal
for what they should be.  Until that point, we can let the local system
administrator hand the situation, i guess.

              --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20160715/f6ea1c99/attachment.sig>

From patrick at enigmail.net  Fri Jul 15 12:57:33 2016
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Fri, 15 Jul 2016 12:57:33 +0200
Subject: GnuPG 2.1.14: errors with tests/gpgscm
In-Reply-To: <87twfrjm1v.fsf@europa.jade-hamburg.de>
References: <73c44165-1e6a-cd32-f4dc-9e09bc179516@enigmail.net>
 <87twfrjm1v.fsf@europa.jade-hamburg.de>
Message-ID: <b282fbc6-7615-ca52-b566-76875a693927@enigmail.net>

On 15.07.16 11:19, Justus Winter wrote:
> Hi Patrick :)
> 
> Patrick Brunschwig <patrick at enigmail.net> writes:
>> tests/gpgscm is failing with:
>>
>> [...]
>>
>> It looks like like the Makefile is missing -lintl
> 
> Thanks for reporting.  Having said that, I did ask to test this on other
> platforms some months ago, we could have caught this earlier...
> 
> From the paths I guess this is on MacOS?

yes, indeed.

-Patrick


From justus at g10code.com  Fri Jul 15 12:57:18 2016
From: justus at g10code.com (Justus Winter)
Date: Fri, 15 Jul 2016 12:57:18 +0200
Subject: GnuPG 2.1.14: errors with tests/gpgscm
In-Reply-To: <87twfrjm1v.fsf@europa.jade-hamburg.de>
References: <73c44165-1e6a-cd32-f4dc-9e09bc179516@enigmail.net>
 <87twfrjm1v.fsf@europa.jade-hamburg.de>
Message-ID: <87r3avjhip.fsf@europa.jade-hamburg.de>

Justus Winter <justus at g10code.com> writes:

> [ Unknown signature status ]
> Patrick Brunschwig <patrick at enigmail.net> writes:
>> tests/gpgscm is failing with:
>>
>> [...]
>>
>> It looks like like the Makefile is missing -lintl

(Hopefully) fixed in c49c43d7.

>> I tried to build gpg 2.1.14 with --disable-tests, but tests/gpgscm is
>> built nevertheless
>
> Good point.

No, I'm confused, there doesn't seem to be such an configure flag.

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160715/2cb66989/attachment-0001.sig>

From justus at g10code.com  Fri Jul 15 13:06:32 2016
From: justus at g10code.com (Justus Winter)
Date: Fri, 15 Jul 2016 13:06:32 +0200
Subject: 2.1.14: tests/openpgp/gpgtar.scm failing under --disable-gpgtar
In-Reply-To: <874m7rmd6o.fsf@wheatstone.g10code.de>
References: <878tx3lo3a.fsf@alice.fifthhorseman.net>
 <874m7rmd6o.fsf@wheatstone.g10code.de>
Message-ID: <87oa5zjh3b.fsf@europa.jade-hamburg.de>

Werner Koch <wk at gnupg.org> writes:

> On Fri, 15 Jul 2016 02:52, dkg at fifthhorseman.net said:
>> It looks like the gpgtar test fails when gpgtar is not built.

I fixed that test and the migration tests in 12a88705.

> We use gpgtar to unpack a couple of test files which would otherwise
> reach the gile length limit of tar.  We should better require gpgtar if
> tests are built.

We could also build it unconditionally and simply not install it if the
user specified --disable-gpgtar.  It is a tiny program, and I see no
harm in building it.  And untarring the test data with it is very
convenient.

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160715/abeca646/attachment.sig>

From mail at tgries.de  Sat Jul 16 09:27:02 2016
From: mail at tgries.de (Thomas Gries)
Date: Sat, 16 Jul 2016 09:27:02 +0200
Subject: why SHA-1 ?
Message-ID: <61ccdfb5-4638-2810-7203-d1aac775b97a@tgries.de>

Your checksum page https://www.gnupg.org/download/integrity_check.html
still uses SHA-1 (deprecated).

What is the rationale to use this deprecated algorithm and why don't you
use non-deprecated checksums such as SHA-256 or SHA-512 ?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160716/c142f333/attachment.html>

From rjh at sixdemonbag.org  Sat Jul 16 11:39:36 2016
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sat, 16 Jul 2016 05:39:36 -0400
Subject: why SHA-1 ?
In-Reply-To: <61ccdfb5-4638-2810-7203-d1aac775b97a@tgries.de>
References: <61ccdfb5-4638-2810-7203-d1aac775b97a@tgries.de>
Message-ID: <93f78d9a-5812-4b1f-da37-370d08cfa1c7@sixdemonbag.org>

> What is the rationale to use this deprecated algorithm and why don't you
> use non-deprecated checksums such as SHA-256 or SHA-512 ?

Deprecated by whom?  SHA-1's long-term prospects aren't good but we're
nowhere near preimage attacks.  It's still just fine for file verification.


From patrick at enigmail.net  Sat Jul 16 15:44:47 2016
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sat, 16 Jul 2016 15:44:47 +0200
Subject: dirmngr: Wrong certificate error?
Message-ID: <465ea677-4619-b326-b944-3c36236819ac@enigmail.net>

I tried to use dirmngr (2.1.14) with hkps://keys.mailvelope.com and got
a failure.

I first visited the web page using Firefox, exported the root CA
certificate (Starfield), and copied it into /etc/gnupg/trusted-certs.
Then I run dirmngr from the command line using:

dirmngr <<EOT
keyserver hkps://keys.mailvelope.com
ks_search patrick at enigmail.net
EOT

This gave me the error "TLS connection authentication failed: General error"

I have attached the complete output from dirmngr. I get the impression
that the reverse DNS lookup causes a problem here.

-Patrick

-------------- next part --------------
dirmngr[53927.0]: trusted certificate '/usr/local/gnupg-2.1/etc/gnupg/trusted-certs/StarfieldServicesRootCertificateAuthority-G2.crt' loaded
dirmngr[53927.0]: permanently loaded certificates: 1
dirmngr[53927.0]:     runtime cached certificates: 0
# Home: /Users/pbr/.gnupg
# Config: [none]
OK Dirmngr 2.1.14 at your service
keyserver hkps://keys.mailvelope.com
OK
ks_search test
dirmngr[53927.0]: DNS query returned an error or no records: No such domain (nxdomain)
dirmngr[53927.0]: resolve_dns_addr for 'keys.mailvelope.com': 'ec2-52-30-29-22.eu-west-1.compute.amazonaws.com'
dirmngr[53927.0]: resolve_dns_addr for 'keys.mailvelope.com': 'ec2-52-208-40-58.eu-west-1.compute.amazonaws.com'
dirmngr[53927.0]: TLS verification of peer failed: status=0x0042
dirmngr[53927.0]: TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown.
dirmngr[53927.0]: TLS verification of peer failed: hostname does not match
dirmngr[53927.0]: DBG: expected hostname: awseb-e-m-AWSEBLoa-DN7KGVOVU5WM-1656017105.eu-west-1.elb.amazonaws.com
dirmngr[53927.0]: DBG: BEGIN Certificate 'server[0]':
dirmngr[53927.0]: DBG:      serial: 0527087BF1E7D0DE11D278EAE063DA46
dirmngr[53927.0]: DBG:   notBefore: 2016-06-07 00:00:00
dirmngr[53927.0]: DBG:    notAfter: 2017-07-07 12:00:00
dirmngr[53927.0]: DBG:      issuer: CN=Amazon,OU=Server CA 1B,O=Amazon,C=US
dirmngr[53927.0]: DBG:     subject: CN=keys.mailvelope.com
dirmngr[53927.0]: DBG:   hash algo: 1.2.840.113549.1.1.11
dirmngr[53927.0]: DBG:   SHA1 fingerprint: CA8F102975140402D7A63F4A7133044A52662DB4
dirmngr[53927.0]: DBG: END Certificate
dirmngr[53927.0]: DBG: BEGIN Certificate 'server[1]':
dirmngr[53927.0]: DBG:      serial: 067F94578587E8AC77DEB253325BBC998B560D
dirmngr[53927.0]: DBG:   notBefore: 2015-10-22 00:00:00
dirmngr[53927.0]: DBG:    notAfter: 2025-10-19 00:00:00
dirmngr[53927.0]: DBG:      issuer: CN=Amazon Root CA 1,O=Amazon,C=US
dirmngr[53927.0]: DBG:     subject: CN=Amazon,OU=Server CA 1B,O=Amazon,C=US
dirmngr[53927.0]: DBG:   hash algo: 1.2.840.113549.1.1.11
dirmngr[53927.0]: DBG:   SHA1 fingerprint: 917E732D330F9A12404F73D8BEA36948B929DFFC
dirmngr[53927.0]: DBG: END Certificate
dirmngr[53927.0]: DBG: BEGIN Certificate 'server[2]':
dirmngr[53927.0]: DBG:      serial: 067F944A2A27CDF3FAC2AE2B01F908EEB9C4C6
dirmngr[53927.0]: DBG:   notBefore: 2015-05-25 12:00:00
dirmngr[53927.0]: DBG:    notAfter: 2037-12-31 01:00:00
dirmngr[53927.0]: DBG:      issuer: CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\, Inc.,L=Scottsdale,ST=Arizona,C=US
dirmngr[53927.0]: DBG:     subject: CN=Amazon Root CA 1,O=Amazon,C=US
dirmngr[53927.0]: DBG:   hash algo: 1.2.840.113549.1.1.11
dirmngr[53927.0]: DBG:   SHA1 fingerprint: 06B25927C42A721631C1EFD9431E648FA62E1E39
dirmngr[53927.0]: DBG: END Certificate
dirmngr[53927.0]: DBG: BEGIN Certificate 'server[3]':
dirmngr[53927.0]: DBG:      serial: 00A70E4A4C3482B77F
dirmngr[53927.0]: DBG:   notBefore: 2009-09-02 00:00:00
dirmngr[53927.0]: DBG:    notAfter: 2034-06-28 17:39:16
dirmngr[53927.0]: DBG:      issuer: OU=Starfield Class 2 Certification Authority,O=Starfield Technologies\, Inc.,C=US
dirmngr[53927.0]: DBG:     subject: CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\, Inc.,L=Scottsdale,ST=Arizona,C=US
dirmngr[53927.0]: DBG:   hash algo: 1.2.840.113549.1.1.11
dirmngr[53927.0]: DBG:   SHA1 fingerprint: 9E99A48A9960B14926BB7F3B02E22DA2B0AB7280
dirmngr[53927.0]: DBG: END Certificate
dirmngr[53927.0]: TLS connection authentication failed: General error
dirmngr[53927.0]: error connecting to 'https://ec2-52-208-40-58.eu-west-1.compute.amazonaws.com:443': General error
dirmngr[53927.0]: command 'KS_SEARCH' failed: General error <Unspecified source>
ERR 1 General error <Unspecified source>

From wk at gnupg.org  Sun Jul 17 09:12:01 2016
From: wk at gnupg.org (Werner Koch)
Date: Sun, 17 Jul 2016 09:12:01 +0200
Subject: Moving the agent's socket to /var/run ?
In-Reply-To: <87ziqjtua9.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Fri, 17 Jun 2016 16:49:50 -0400")
References: <87k2lv5u0y.fsf@wheatstone.g10code.de>
 <87h9d3zu52.fsf@wheatstone.g10code.de>
 <8737ocwybv.fsf@alice.fifthhorseman.net>
 <87a8iki9ll.fsf@wheatstone.g10code.de>
 <87ziqjtua9.fsf@alice.fifthhorseman.net>
Message-ID: <87bn1wg2m6.fsf@wheatstone.g10code.de>

On Fri, 17 Jun 2016 22:49, dkg at fifthhorseman.net said:
> One more wrinkle that i'm finding related to this setup -- what to do
> about overlong socket paths?

Actually that was one of the reasons to switch to /run with 2.1.13.

> might offer a fix.  I'm wondering whether it would make sense to use
> /run automatically on systems where /run/$UID/ is available and the
> standard-socket is prohibited by length (not just by filesystem type).

We alreay do that. If a /run/users/$UID directroy exists with the right
permissions, we create a gnupg subdirectory.

> fwiw, this isn't idle speculation.  I work on monkeysphere in
> /home/dkg/src/monkeysphere/monkeysphere, which is 39 characters in
> length.  the standard test suite operates in a tmpdir templated from the
> cwd as tmp/monkeyspheretest.XXXXXX (another 32 characters), and in the
> test suite tmpdir, there is a GNUPGHOME dir named authentication/sphere

Yes, several people reported that.  In particular on some AIX
installations this seems to be a problem.  We don't create a directory
below /run/users/$UID/gnupg automatically out of a fear that we would
clutter that directory with many subdir used only temporary.  The test
suite could of course remove that directory again.  Maybe we could run a
test first whether a /run directory will be required.

@justus: Can you please look into this?


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From wk at gnupg.org  Sun Jul 17 09:26:01 2016
From: wk at gnupg.org (Werner Koch)
Date: Sun, 17 Jul 2016 09:26:01 +0200
Subject: [RFC PATCH] dirmngr: Try to recognize user-daemon mode
In-Reply-To: <1843343.drc1yOrXTc@merope> (=?utf-8?B?IlRvbcOhxaE=?= Trnka"'s
 message of "Sun, 03 Jul 2016 21:34:03 +0200")
References: <1843343.drc1yOrXTc@merope>
Message-ID: <87r3asenee.fsf@wheatstone.g10code.de>

On Sun,  3 Jul 2016 21:34, tomastrnka at gmx.com said:

> Dirmngr needs to tell when it is started as an user daemon through
> start_new_dirmngr(), in order to switch off code paths specific for
> the systemwide case (internal OCSP validation, root-only remote

The idea with the system daemon was to share CRLs between users.
Meanhwile I doubt that this of of any real use given that the majority
of systems running GnuPG in an interactive mode have only one active
user.

For system services using gpgsm or dirmngr, it might be better to use a
dedicated user for dirmngr and don't use the system dirmngr feature.
That would allow us to remove all that extra code.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From dkg at fifthhorseman.net  Sun Jul 17 19:08:28 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 17 Jul 2016 19:08:28 +0200
Subject: [RFC PATCH] dirmngr: Try to recognize user-daemon mode
In-Reply-To: <87r3asenee.fsf@wheatstone.g10code.de>
References: <1843343.drc1yOrXTc@merope> <87r3asenee.fsf@wheatstone.g10code.de>
Message-ID: <87vb045h0z.fsf@alice.fifthhorseman.net>

On Sun 2016-07-17 09:26:01 +0200, Werner Koch wrote:
> The idea with the system daemon was to share CRLs between users.
> Meanhwile I doubt that this of of any real use given that the majority
> of systems running GnuPG in an interactive mode have only one active
> user.
>
> For system services using gpgsm or dirmngr, it might be better to use a
> dedicated user for dirmngr and don't use the system dirmngr feature.
> That would allow us to remove all that extra code.

I agree that a dedicated user running dirmngr in its standard mode would
be preferable to maintaining the specialized system mode.  less code ==
easier maintenance :)

   --dkg


From mail at tgries.de  Mon Jul 18 08:21:58 2016
From: mail at tgries.de (Thomas Gries)
Date: Mon, 18 Jul 2016 08:21:58 +0200
Subject: Environment variables for UPDATESTARTUPTTY of gpg-agent
In-Reply-To: <87k2grxmnz.fsf@wheatstone.g10code.de>
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
Message-ID: <967a402f-26c7-70ae-1220-bec5b790b483@tgries.de>

Update:

the  "gnome-keyring hijacked GPG agent" issue under Debian 8 Jessie has
gone (this was expected) after successfully (manually) compiling and
deploying the latest GnuPG 2.1.14 .

It appears to be important that Debian people start supplying the latest
GnuPG version 2.1.14 and stop packaging the 2.0.26.


Am 12.07.2016 um 10:53 schrieb Werner Koch:
>> Recently, I changed the configuration so that gpg-agent is started by
>> systemd.  Then, I encounter this issue:
> You mean 2.0?  Since 2.1 auto starting the agent is the default and I
> don't see why some other software should take part in it.  GnUPG would
> not anymore be self-contained.  Anyway.
The problem is, that Debian 8 (Jessie) still has the 2.0x versions, and not
the 2.1x version, and you get these annoying "gnome-keyring hijacked GPG
agent" issue.

gpg (GnuPG) 2.0.26
libgcrypt 1.6.3

Any idea when this will change, and when the 2.1x will become available
in Debian 8 ?



From wk at gnupg.org  Mon Jul 18 13:09:24 2016
From: wk at gnupg.org (Werner Koch)
Date: Mon, 18 Jul 2016 13:09:24 +0200
Subject: Environment variables for UPDATESTARTUPTTY of gpg-agent
In-Reply-To: <967a402f-26c7-70ae-1220-bec5b790b483@tgries.de> (Thomas Gries's
 message of "Mon, 18 Jul 2016 08:21:58 +0200")
References: <bc354d8d-ef49-9194-6320-b8de29f35a9e@fsij.org>
 <87k2grxmnz.fsf@wheatstone.g10code.de>
 <967a402f-26c7-70ae-1220-bec5b790b483@tgries.de>
Message-ID: <87k2gj9p97.fsf@wheatstone.g10code.de>

On Mon, 18 Jul 2016 08:21, mail at tgries.de said:

> The problem is, that Debian 8 (Jessie) still has the 2.0x versions, and not
> the 2.1x version, and you get these annoying "gnome-keyring hijacked GPG

The problem is with gnome-keyring and not with GnuPG.

> Any idea when this will change, and when the 2.1x will become available
> in Debian 8 ?

It won't, it is in testing though.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */



From dkg at fifthhorseman.net  Mon Jul 18 16:29:00 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 18 Jul 2016 16:29:00 +0200
Subject: dirmngr trusted authorities
Message-ID: <8737n73tqr.fsf@alice.fifthhorseman.net>

hi GnuPG folks--

according to its docs, dirmngr appears to look for X.509 certs as
DER-encoded files named *.crt or *.der in /etc/gnupg/trusted-certs/ (for
root authorities) and /etc/gnupg/extra-certs/ (for common intermediate
authorities).

however, in http_session_new() in dirmngr/http.c, it appears to also use
gnutls_certificate_set_x509_system_trust() in some cases (though i
haven't been able to follow the code well enough to understand
specifically when).

It seems awkward and potentially confusing to the user to have these two
distinct validation schemes.

I'd suggest that if the user doesn't supply any hkp-cacert config
either on the command line or in dirmngr.conf (and they're not using
the magic string hkps://hkps.pool.sks-keyservers.net/) and they've
specified hkps, then it seems like using the gnutls's system_trust would
be a reasonable default.

If someone wants to explicitly not use the system trust, then they could
set hkp-cacert to the empty string.

Is there a way that we can simplify this for the user?

    --dkg


From phoenyx33 at gmail.com  Mon Jul 18 18:30:53 2016
From: phoenyx33 at gmail.com (Kenneth Benson)
Date: Mon, 18 Jul 2016 12:30:53 -0400
Subject: Problems with gpg-agent
Message-ID: <CACGLP4PW-vW1Hgy-9+s0=EkMBxK4BGABSQ9G_5nUpk3JP7dOkw@mail.gmail.com>

First, the way I use gpg is on a usb drive with Thunderbird/Enigmail
installed. As my home `net is unstable, I frequently take this
usb drive to the local library which has free Internet and download my
email from my accounts to the usb. I can then view them
at my leisure at home. My problem is that after running
Thunderbird/Enigmail, when I try to eject the usb it refuses to because
something is in use. I tracked it down to gpg-agent.exe is left running in
the background. How can I stop gpg-agent to safely
dismount the usb? I tried renaming it but then the keys don't work with
arriving signed/encrypted emails. Please help. And I
apologize if this is the wrong list, please tell me which list to send it
to if needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160718/24ed86fb/attachment.html>

From bjk at luxsci.net  Tue Jul 19 00:51:30 2016
From: bjk at luxsci.net (Ben Kibbey)
Date: Mon, 18 Jul 2016 18:51:30 -0400
Subject: [PATCH] tofu: fix null pointer dereference.
Message-ID: <1468882322-9751103.70516274.fu6IMpU4g016514@rs146.luxsci.com>

* g10/tofu.c (tofu_closedbs): test for NULL.

Signed-off-by: Ben Kibbey <bjk at luxsci.net>
---
 g10/tofu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/g10/tofu.c b/g10/tofu.c
index 471aec6..b0686e5 100644
--- a/g10/tofu.c
+++ b/g10/tofu.c
@@ -1107,7 +1107,8 @@ tofu_closedbs (ctrl_t ctrl)
           while (-- skip > 0)
             old_head = old_head->next;
 
-          *old_head->prevp = NULL;
+          if (old_head)
+            *old_head->prevp = NULL;
 
           while (old_head)
             {
-- 
2.8.1



From bjk at luxsci.net  Tue Jul 19 02:16:46 2016
From: bjk at luxsci.net (Ben Kibbey)
Date: Mon, 18 Jul 2016 20:16:46 -0400
Subject: [PATCH] Fix including nil bytes in keylist output.
Message-ID: <1468887422-96655.7260537929.fu6J0Gk38007740@rs146.luxsci.com>

* src/gpgme-tool.c (cmd_keylist,gt_result): use strlen().

Signed-off-by: Ben Kibbey <bjk at luxsci.net>
---
 src/gpgme-tool.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gpgme-tool.c b/src/gpgme-tool.c
index 080b306..5ad5b25 100644
--- a/src/gpgme-tool.c
+++ b/src/gpgme-tool.c
@@ -1725,9 +1725,9 @@ gt_result (gpgme_tool_t gt, unsigned int flags)
 {
   int indent = 2;
 
-  gt_write_data (gt, xml_preamble1, sizeof (xml_preamble1));
+  gt_write_data (gt, xml_preamble1, strlen (xml_preamble1));
   gt_write_data (gt, NULL, 0);
-  gt_write_data (gt, xml_preamble2, sizeof (xml_preamble2));
+  gt_write_data (gt, xml_preamble2, strlen (xml_preamble2));
   gt_write_data (gt, NULL, 0);
   if (flags & GT_RESULT_ENCRYPT)
     result_encrypt_to_xml (gt->ctx, indent,
@@ -1753,7 +1753,7 @@ gt_result (gpgme_tool_t gt, unsigned int flags)
   if (flags & GT_RESULT_VFS_MOUNT)
     result_vfs_mount_to_xml (gt->ctx, indent,
 			     (result_xml_write_cb_t) gt_write_data, gt);
-  gt_write_data (gt, xml_end, sizeof (xml_end));
+  gt_write_data (gt, xml_end, strlen (xml_end));
 
   return 0;
 }
@@ -2853,9 +2853,9 @@ cmd_keylist (assuan_context_t ctx, char *line)
     }
   pattern[idx] = NULL;
 
-  gt_write_data (gt, xml_preamble1, sizeof (xml_preamble1));
+  gt_write_data (gt, xml_preamble1, strlen (xml_preamble1));
   gt_write_data (gt, NULL, 0);
-  gt_write_data (gt, xml_preamble2, sizeof (xml_preamble2));
+  gt_write_data (gt, xml_preamble2, strlen (xml_preamble2));
   gt_write_data (gt, NULL, 0);
   result_init (&state, indent, (result_xml_write_cb_t) gt_write_data, gt);
   result_xml_tag_start (&state, "keylist", NULL);
@@ -2930,7 +2930,7 @@ cmd_keylist (assuan_context_t ctx, char *line)
     }
 
   result_xml_tag_end (&state);  /* keylist */
-  gt_write_data (gt, xml_end, sizeof (xml_end));
+  gt_write_data (gt, xml_end, strlen (xml_end));
 
   server_reset_fds (server);
 
-- 
2.8.1



From bjk at luxsci.net  Tue Jul 19 03:11:48 2016
From: bjk at luxsci.net (Ben Kibbey)
Date: Mon, 18 Jul 2016 21:11:48 -0400
Subject: [PATCH] Add keygrip to LISTKEYS output.
Message-ID: <1468890724-292716.405388038.fu6J1BnQi002450@rs146.luxsci.com>

* src/gpgme.h.in: Add GPGME_KEYLIST_MODE_WITH_KEYGRIP.
(_gpgme_subkey): Add grp member.
* src/engine-gpg.c (gpg_keylist_build_options): Parse the new mode and
add gpg option --with-keygrip.
* src/gpgme-tool.c (result_add_grp): New.
(cmd_keylist): Add option --with-keygrip and grp XML result element.
* src/keylist.c (keylist_colon_handler): Set grp member to keygrip.
--

Not sure whether to add the keygrip to the output by default or not so
this is why --with-keygrip is added as an option to LISTKEYS.

Signed-off-by: Ben Kibbey <bjk at luxsci.net>
---
 src/engine-gpg.c |  2 ++
 src/gpgme-tool.c | 46 ++++++++++++++++++++++++++++++++++++++--------
 src/gpgme.h.in   |  4 ++++
 src/keylist.c    | 20 +++++++++++++++++++-
 4 files changed, 63 insertions(+), 9 deletions(-)

diff --git a/src/engine-gpg.c b/src/engine-gpg.c
index 16571a5..5537c33 100644
--- a/src/engine-gpg.c
+++ b/src/engine-gpg.c
@@ -2291,6 +2291,8 @@ gpg_keylist_build_options (engine_gpg_t gpg, int secret_only,
     err = add_arg (gpg, "--with-fingerprint");
   if (!err && (mode & GPGME_KEYLIST_MODE_WITH_SECRET))
     err = add_arg (gpg, "--with-secret");
+  if (!err && (mode & GPGME_KEYLIST_MODE_WITH_KEYGRIP))
+    err = add_arg (gpg, "--with-keygrip");
   if (!err
       && (mode & GPGME_KEYLIST_MODE_SIGS)
       && (mode & GPGME_KEYLIST_MODE_SIG_NOTATIONS))
diff --git a/src/gpgme-tool.c b/src/gpgme-tool.c
index 5ad5b25..cb6ce37 100644
--- a/src/gpgme-tool.c
+++ b/src/gpgme-tool.c
@@ -556,6 +556,14 @@ result_add_fpr (struct result_xml_state *state, char *name, char *fpr)
   return 0;
 }
 
+gpg_error_t
+result_add_grp (struct result_xml_state *state, char *name, char *grp)
+{
+  result_xml_tag_start (state, name, NULL);
+  result_xml_tag_data (state, grp);
+  result_xml_tag_end (state);
+  return 0;
+}
 
 gpg_error_t
 result_add_timestamp (struct result_xml_state *state, char *name,
@@ -2810,7 +2818,7 @@ cmd_delete (assuan_context_t ctx, char *line)
 
 
 static const char hlp_keylist[] =
-  "KEYLIST [--secret-only] [<patterns>]\n"
+  "KEYLIST [--secret-only] [--with-keygrip] [<patterns>]\n"
   "\n"
   "List all certificates or only those specified by PATTERNS.  Each\n"
   "pattern shall be a percent-plus escaped certificate specification.";
@@ -2825,16 +2833,36 @@ cmd_keylist (assuan_context_t ctx, char *line)
   int secret_only = 0;
   int idx, indent=2;
   const char *pattern[MAX_CMD_KEYLIST_PATTERN+1];
-  const char optstr[] = "--secret-only";
   char *p;
 
-  if (!strncasecmp (line, optstr, strlen (optstr)))
+  do
     {
-      secret_only = 1;
-      line += strlen (optstr);
-      while (*line && !spacep (line))
-	line++;
-    }
+      char *s, *l;
+
+      if ((s = strstr (line, "--secret-only")))
+        secret_only = 1;
+      else if ((s = strstr (line, "--with-keygrip")))
+        {
+          gpgme_keylist_mode_t mode = gpgme_get_keylist_mode (server->gt->ctx);
+
+          mode |= GPGME_KEYLIST_MODE_WITH_KEYGRIP;
+          err = gpgme_set_keylist_mode (server->gt->ctx, mode);
+          if (err)
+            return err;
+        }
+      else
+        break;
+
+      l = s;
+
+      while (*s && !spacep (s))
+        s++;
+
+      while (*s)
+        *l++ = *s++;
+
+      *l = 0;
+    } while (1);
 
   idx = 0;
   for (p=line; *p; line = p)
@@ -2901,6 +2929,8 @@ cmd_keylist (assuan_context_t ctx, char *line)
 	    result_add_keyid (&state, "keyid", subkey->keyid);
             if (subkey->fpr)
               result_add_fpr (&state, "fpr", subkey->fpr);
+            if (subkey->grp)
+              result_add_grp (&state, "grp", subkey->grp);
             result_add_value (&state, "secret", subkey->secret);
             result_add_value (&state, "is_cardkey", subkey->is_cardkey);
             if (subkey->card_number)
diff --git a/src/gpgme.h.in b/src/gpgme.h.in
index 49d56c3..d24978c 100644
--- a/src/gpgme.h.in
+++ b/src/gpgme.h.in
@@ -413,6 +413,7 @@ gpgme_protocol_t;
 #define GPGME_KEYLIST_MODE_WITH_SECRET       	16
 #define GPGME_KEYLIST_MODE_EPHEMERAL            128
 #define GPGME_KEYLIST_MODE_VALIDATE		256
+#define GPGME_KEYLIST_MODE_WITH_KEYGRIP		512
 
 typedef unsigned int gpgme_keylist_mode_t;
 
@@ -680,6 +681,9 @@ struct _gpgme_subkey
   /* The fingerprint of the subkey in hex digit form.  */
   char *fpr;
 
+  /* The keygrip of the subkey in hex digit form.  */
+  char *grp;
+
   /* The creation timestamp, -1 if invalid, 0 if not available.  */
   long int timestamp;
 
diff --git a/src/keylist.c b/src/keylist.c
index fcf574f..531bf51 100644
--- a/src/keylist.c
+++ b/src/keylist.c
@@ -427,7 +427,7 @@ keylist_colon_handler (void *priv, char *line)
   enum
     {
       RT_NONE, RT_SIG, RT_UID, RT_SUB, RT_PUB, RT_FPR,
-      RT_SSB, RT_SEC, RT_CRT, RT_CRS, RT_REV, RT_SPK
+      RT_SSB, RT_SEC, RT_CRT, RT_CRS, RT_REV, RT_SPK, RT_GRP
     }
   rectype = RT_NONE;
 #define NR_FIELDS 17
@@ -479,6 +479,8 @@ keylist_colon_handler (void *priv, char *line)
     rectype = RT_CRS;
   else if (!strcmp (field[0], "fpr") && key)
     rectype = RT_FPR;
+  else if (!strcmp (field[0], "grp") && key)
+    rectype = RT_GRP;
   else if (!strcmp (field[0], "uid") && key)
     rectype = RT_UID;
   else if (!strcmp (field[0], "sub") && key)
@@ -717,6 +719,22 @@ keylist_colon_handler (void *priv, char *line)
 	}
       break;
 
+    case RT_GRP:
+      /* Field 10 has the keygrip (take only the first one).  */
+      if (fields >= 10 && field[9] && *field[9])
+	{
+          /* Need to apply it to the last subkey because all subkeys
+             do have keygrips. */
+          subkey = key->_last_subkey;
+          if (!subkey->grp)
+            {
+              subkey->grp = strdup (field[9]);
+              if (!subkey->grp)
+                return gpg_error_from_syserror ();
+            }
+	}
+      break;
+
     case RT_SIG:
     case RT_REV:
       if (!opd->tmp_uid)
-- 
2.8.1



From aheinecke at intevation.de  Tue Jul 19 09:54:39 2016
From: aheinecke at intevation.de (Andre Heinecke)
Date: Tue, 19 Jul 2016 09:54:39 +0200
Subject: dirmngr trusted authorities
In-Reply-To: <8737n73tqr.fsf@alice.fifthhorseman.net>
References: <8737n73tqr.fsf@alice.fifthhorseman.net>
Message-ID: <1607420.X8Qa7ts4SL@esus>

Hi,

On Monday 18 July 2016 16:29:00 Daniel Kahn Gillmor wrote:
> according to its docs, dirmngr appears to look for X.509 certs as
> DER-encoded files named *.crt or *.der in /etc/gnupg/trusted-certs/ (for
> root authorities) and /etc/gnupg/extra-certs/ (for common intermediate
> authorities).

This is for GpgSM Certificates used for validation of CMS Certificates. I think 
trusted-certificates also have the special role that they are used for CRL / 
OCSP validation even if they are not marked as trusted in trustlist.txt

> however, in http_session_new() in dirmngr/http.c, it appears to also use
> gnutls_certificate_set_x509_system_trust() in some cases (though i
> haven't been able to follow the code well enough to understand
> specifically when).

This is for transport Certificates used for TLS / HTTPS but Yes I also don't 
know how HKPS (which is basically https) plays in there or what the role of 
hkp-cacert is.

> It seems awkward and potentially confusing to the user to have these two
> distinct validation schemes.

Which two are you referring to? HTTPS with System Certs and HKP-Cacert or the 
difference between CMS and TLS validation? I see the following validation ways:

1. CMS: extra-certs / trusted-certs with trusted certs used for CRL / OCSP
2. CMS: trustlist.txt (either systemwide or user) + extra-certs trusted-certs 
as "hidden repository of certificates that are imported when used" or keyring
3. TLS: hkp-cacert
4. TLS: GnuTLS "System store"

> I'd suggest that if the user doesn't supply any hkp-cacert config
> either on the command line or in dirmngr.conf (and they're not using
> the magic string hkps://hkps.pool.sks-keyservers.net/) and they've
> specified hkps, then it seems like using the gnutls's system_trust would
> be a reasonable default.

I agree, (Or if we ever get TLS on Windows I would want the Windows Store to 
be used)

> If someone wants to explicitly not use the system trust, then they could
> set hkp-cacert to the empty string.
>
> Is there a way that we can simplify this for the user?

Your suggestions sounds reasonable to me regarding TLS. But with regards to 
CMS certificates with extra-certs, trusted-certs I don't think that needs to be 
simplified.

In the usual "one user" installation a user should just use Case 2 import the 
certificates which are trusted. Extra-certs and trusted-certs are more for 
instutional users that have dedicated people to set things up.

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: 648 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160719/cf415c89/attachment-0001.sig>

From justus at g10code.com  Tue Jul 19 10:55:16 2016
From: justus at g10code.com (Justus Winter)
Date: Tue, 19 Jul 2016 10:55:16 +0200
Subject: [PATCH] tofu: fix null pointer dereference.
In-Reply-To: <1468882322-9751103.70516274.fu6IMpU4g016514@rs146.luxsci.com>
References: <1468882322-9751103.70516274.fu6IMpU4g016514@rs146.luxsci.com>
Message-ID: <87r3aqqa6j.fsf@europa.jade-hamburg.de>

Hi Ben :)

did you actually see this crash or are you fixing a compiler or static
analyzer warning?  Because...

Ben Kibbey <bjk at luxsci.net> writes:

> * g10/tofu.c (tofu_closedbs): test for NULL.
>
> Signed-off-by: Ben Kibbey <bjk at luxsci.net>
> ---
>  g10/tofu.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/g10/tofu.c b/g10/tofu.c
> index 471aec6..b0686e5 100644
> --- a/g10/tofu.c
> +++ b/g10/tofu.c
> @@ -1107,7 +1107,8 @@ tofu_closedbs (ctrl_t ctrl)

* old_head can only be NULL if db_cache_count was 0 before being
  incremented by count.

* Therefore, db_cache_count == count.

* We only free databases if db_cache_count > DB_CACHE_ENTRIES.

* Thus, count > DB_CACHE_ENTRIES, and

int skip = DB_CACHE_ENTRIES - count;

* skip < 0.

>            while (-- skip > 0)
>              old_head = old_head->next;

Which means it doesn't crash here (that was my first thought).

> -          *old_head->prevp = NULL;
> +          if (old_head)
> +            *old_head->prevp = NULL;
>  
>            while (old_head)

But it also means that we will never free a handle in this case.  Which
means while your patch fixes a crash, the code still doesn't work in
that case.  Care to fix it?

Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160719/17b6795b/attachment.sig>

From justus at g10code.com  Tue Jul 19 10:59:56 2016
From: justus at g10code.com (Justus Winter)
Date: Tue, 19 Jul 2016 10:59:56 +0200
Subject: Problems with gpg-agent
In-Reply-To: <CACGLP4PW-vW1Hgy-9+s0=EkMBxK4BGABSQ9G_5nUpk3JP7dOkw@mail.gmail.com>
References: <CACGLP4PW-vW1Hgy-9+s0=EkMBxK4BGABSQ9G_5nUpk3JP7dOkw@mail.gmail.com>
Message-ID: <87oa5uq9yr.fsf@europa.jade-hamburg.de>

Hi Kenneth :)

Kenneth Benson <phoenyx33 at gmail.com> writes:

> First, the way I use gpg is on a usb drive with Thunderbird/Enigmail
> installed. As my home `net is unstable, I frequently take this
> usb drive to the local library which has free Internet and download my
> email from my accounts to the usb. I can then view them
> at my leisure at home. My problem is that after running
> Thunderbird/Enigmail, when I try to eject the usb it refuses to because
> something is in use. I tracked it down to gpg-agent.exe is left running in
> the background. How can I stop gpg-agent to safely
> dismount the usb? I tried renaming it but then the keys don't work with
> arriving signed/encrypted emails.

You could try

   gpg-connect-agent.exe killagent /bye

That should terminate the agent closing any files.

> Please help. And I apologize if this is the wrong list, please tell me
> which list to send it to if needed.

It is indeed the wrong list, there is also gnupg-users which is more
appropriate for this kind of question.

Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160719/48018e92/attachment.sig>

From justus at g10code.com  Tue Jul 19 11:17:09 2016
From: justus at g10code.com (Justus Winter)
Date: Tue, 19 Jul 2016 11:17:09 +0200
Subject: [PATCH] Fix including nil bytes in keylist output.
In-Reply-To: <1468887422-96655.7260537929.fu6J0Gk38007740@rs146.luxsci.com>
References: <1468887422-96655.7260537929.fu6J0Gk38007740@rs146.luxsci.com>
Message-ID: <87lh0yq962.fsf@europa.jade-hamburg.de>

Ben Kibbey <bjk at luxsci.net> writes:

> * src/gpgme-tool.c (cmd_keylist,gt_result): use strlen().

Merged, thanks!

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160719/4c585996/attachment.sig>

From bjk at luxsci.net  Wed Jul 20 00:40:31 2016
From: bjk at luxsci.net (Ben Kibbey)
Date: Tue, 19 Jul 2016 18:40:31 -0400
Subject: [PATCH] Add keygrip to LISTKEYS output.
In-Reply-To: <1468890724-292716.405388038.fu6J1BnQi002450@rs146.luxsci.com>
References: <1468890724-292716.405388038.fu6J1BnQi002450@rs146.luxsci.com>
Message-ID: <1468968062-3742344.83031567.fu6JMeVqd031752@rs146.luxsci.com>

On Mon, Jul 18, 2016 at 09:11:48PM -0400, Ben Kibbey wrote:
> * src/gpgme.h.in: Add GPGME_KEYLIST_MODE_WITH_KEYGRIP.
> (_gpgme_subkey): Add grp member.
> * src/engine-gpg.c (gpg_keylist_build_options): Parse the new mode and
> add gpg option --with-keygrip.
> * src/gpgme-tool.c (result_add_grp): New.
> (cmd_keylist): Add option --with-keygrip and grp XML result element.
> * src/keylist.c (keylist_colon_handler): Set grp member to keygrip.
> --
> 
> Not sure whether to add the keygrip to the output by default or not so
> this is why --with-keygrip is added as an option to LISTKEYS.

This revised patch removes LISTKEYS --with-keygrip and will always add
the keygrip.

-- 
Ben Kibbey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-keygrip-to-LISTKEYS-output.patch
Type: text/x-diff
Size: 4042 bytes
Desc: not available
URL: </pipermail/attachments/20160719/7cffd852/attachment.patch>

From bjk at luxsci.net  Wed Jul 20 01:16:09 2016
From: bjk at luxsci.net (Ben Kibbey)
Date: Tue, 19 Jul 2016 19:16:09 -0400
Subject: [PATCH] tofu: fix null pointer dereference.
In-Reply-To: <87r3aqqa6j.fsf@europa.jade-hamburg.de>
References: <1468882322-9751103.70516274.fu6IMpU4g016514@rs146.luxsci.com>
 <87r3aqqa6j.fsf@europa.jade-hamburg.de>
Message-ID: <1468970222-2721957.76465868.fu6JNGA19004064@rs146.luxsci.com>

On Tue, Jul 19, 2016 at 10:55:16AM +0200, Justus Winter wrote:
> Hi Ben :)
> 
> did you actually see this crash or are you fixing a compiler or static
> analyzer warning?  Because...

Yeah, saw this crash.

> * Thus, count > DB_CACHE_ENTRIES, and
> 
> int skip = DB_CACHE_ENTRIES - count;
> 
> * skip < 0.

int skip = count - DB_CACHE_ENTRIES;
while (old_head && --skip > 0)

may fix it, but in my case old_head is aways NULL and is to the initial
db_cache near the start of the function.

> 
> >            while (-- skip > 0)
> >              old_head = old_head->next;
> 
> Which means it doesn't crash here (that was my first thought).
> 
> > -          *old_head->prevp = NULL;
> > +          if (old_head)
> > +            *old_head->prevp = NULL;
> >  
> >            while (old_head)
> 
> But it also means that we will never free a handle in this case.  Which
> means while your patch fixes a crash, the code still doesn't work in
> that case.  Care to fix it?

I'll leave it to you or someone else to fix it but if you need more
information I'd be glad to give it to you.

BTW, the command line I am using is:

gpg --list-keys --with-colons --fixed-list-mode --with-fingerprint
--with-fingerprint --with-secret

with 'trust-model' set to tofu+pgp in gpg.conf.

-- 
Ben Kibbey


From bjk at luxsci.net  Thu Jul 21 04:13:46 2016
From: bjk at luxsci.net (Ben Kibbey)
Date: Wed, 20 Jul 2016 22:13:46 -0400
Subject: [PATCH] Add keygrip to LISTKEYS output.
In-Reply-To: <1468968062-3742344.83031567.fu6JMeVqd031752@rs146.luxsci.com>
References: <1468890724-292716.405388038.fu6J1BnQi002450@rs146.luxsci.com>
 <1468968062-3742344.83031567.fu6JMeVqd031752@rs146.luxsci.com>
Message-ID: <1469067246-3859774.1970152.fu6L2DlKm025437@rs146.luxsci.com>

On Tue, Jul 19, 2016 at 06:40:31PM -0400, Ben Kibbey wrote:
> This revised patch removes LISTKEYS --with-keygrip and will always add
> the keygrip.

Fix memory leak. OK to push this?

-- 
Ben Kibbey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-keygrip-to-LISTKEYS-output.patch
Type: text/x-diff
Size: 4443 bytes
Desc: not available
URL: </pipermail/attachments/20160720/66b70185/attachment-0001.patch>

From bjk at luxsci.net  Sun Jul 24 03:01:56 2016
From: bjk at luxsci.net (Ben Kibbey)
Date: Sat, 23 Jul 2016 21:01:56 -0400
Subject: [PATCH] Create cache item for current key from previous.
Message-ID: <1469322122-2473733.12744896.fu6O11uXB007115@rs146.luxsci.com>

* agent/findkey.c (unprotect): Create cache item from previous and
current values.
--

Fixes the KEYINFO cache field for a key that previously failed do to not
being found in the cache but succeeded when the last_stored_cache_key
was tried. Use the last_stored_cache_key cached passphrase for the new
cache entry for the current keygrip.

Has the limitation that the key will need to be used at least once
before the cache field of KEYINFO is updated.

Signed-off-by: Ben Kibbey <bjk at luxsci.net>
---
 agent/findkey.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/agent/findkey.c b/agent/findkey.c
index c5ab0e9..838e17f 100644
--- a/agent/findkey.c
+++ b/agent/findkey.c
@@ -528,6 +528,7 @@ unprotect (ctrl_t ctrl, const char *cache_nonce, const char *desc_text,
                                     &result, &resultlen);
               if (!rc)
                 {
+                  agent_put_cache (hexgrip, cache_mode, pw, 0);
                   if (r_passphrase)
                     *r_passphrase = pw;
                   else
-- 
2.8.1



From justus at g10code.com  Mon Jul 25 10:22:05 2016
From: justus at g10code.com (Justus Winter)
Date: Mon, 25 Jul 2016 10:22:05 +0200
Subject: [PATCH] Create cache item for current key from previous.
In-Reply-To: <1469322122-2473733.12744896.fu6O11uXB007115@rs146.luxsci.com>
References: <1469322122-2473733.12744896.fu6O11uXB007115@rs146.luxsci.com>
Message-ID: <87bn1m6sb6.fsf@europa.jade-hamburg.de>

Hi :)

-------------- next part --------------
Ben Kibbey <bjk at luxsci.net> writes:

> * agent/findkey.c (unprotect): Create cache item from previous and
> current values.
> --
>
> Fixes the KEYINFO cache field for a key that previously failed do to not
> being found in the cache but succeeded when the last_stored_cache_key
> was tried. Use the last_stored_cache_key cached passphrase for the new
> cache entry for the current keygrip.

Thanks, can you please tell me how to reproduce this problem?

Justus

>
> Has the limitation that the key will need to be used at least once
> before the cache field of KEYINFO is updated.
>
> Signed-off-by: Ben Kibbey <bjk at luxsci.net>
> ---
>  agent/findkey.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/agent/findkey.c b/agent/findkey.c
> index c5ab0e9..838e17f 100644
> --- a/agent/findkey.c
> +++ b/agent/findkey.c
> @@ -528,6 +528,7 @@ unprotect (ctrl_t ctrl, const char *cache_nonce, const char *desc_text,
>                                      &result, &resultlen);
>                if (!rc)
>                  {
> +                  agent_put_cache (hexgrip, cache_mode, pw, 0);
>                    if (r_passphrase)
>                      *r_passphrase = pw;
>                    else
> -- 
> 2.8.1
>
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160725/dab62a21/attachment.sig>

From fgunbin at fastmail.fm  Mon Jul 25 21:17:56 2016
From: fgunbin at fastmail.fm (Filipp Gunbin)
Date: Mon, 25 Jul 2016 22:17:56 +0300
Subject: compilation error (2.1.14)
Message-ID: <m2bn1lr0gr.fsf@fastmail.fm>

Hi,

I was trying to compile gnupg-2.1.14 on MacOS X today and ran into the
following problem.

Seems that something like -lintl is missing from the compile line.

libiconv, gettext & adns are installed into /opt/local via MacPorts.

npth, libassuan, libksba, gpg-error, libgcrypt are built locally and
installed into /usr/local.

Thanks,
Filipp


CC=gcc-mp-5 ./configure --enable-maintainer-mode
--with-libiconv-prefix=/opt/local --with-adns=/opt/local
--with-libintl-prefix=/opt/local && make clean all

...
...

gcc-mp-5 -imacros scheme-config.h -I/usr/local/include -I/usr/local/include -I/usr/local/include -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith  -g -O2   -o gpgscm gpgscm-main.o gpgscm-ffi.o gpgscm-scheme.o  ../../common/libcommon.a  -L/opt/local/lib -liconv -lreadline -L/usr/local/lib -lgcrypt -lgpg-error -L/usr/local/lib -lgpg-error 

Undefined symbols for architecture x86_64:
  "_libintl_bind_textdomain_codeset", referenced from:
      _i18n_switchto_utf8 in libcommon.a(libcommon_a-i18n.o)
      _i18n_switchback in libcommon.a(libcommon_a-i18n.o)
  "_libintl_bindtextdomain", referenced from:
      _i18n_init in libcommon.a(libcommon_a-i18n.o)
      _i18n_localegettext in libcommon.a(libcommon_a-i18n.o)
  "_libintl_gettext", referenced from:
      _my_strusage in gpgscm-main.o
      _create_pipe_and_estream in libcommon.a(libcommon_a-exechelp-posix.o)
      _gnupg_spawn_process in libcommon.a(libcommon_a-exechelp-posix.o)
      _gnupg_spawn_process_fd in libcommon.a(libcommon_a-exechelp-posix.o)
      _gnupg_wait_processes in libcommon.a(libcommon_a-exechelp-posix.o)
      _gnupg_spawn_process_detached in libcommon.a(libcommon_a-exechelp-posix.o)
      _disable_core_dumps in libcommon.a(libcommon_a-sysutils.o)
      ...
  "_libintl_setlocale", referenced from:
      _i18n_init in libcommon.a(libcommon_a-i18n.o)
      _i18n_localegettext in libcommon.a(libcommon_a-i18n.o)
  "_libintl_textdomain", referenced from:
      _i18n_init in libcommon.a(libcommon_a-i18n.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status


From patrick at enigmail.net  Mon Jul 25 22:31:57 2016
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Mon, 25 Jul 2016 22:31:57 +0200
Subject: compilation error (2.1.14)
In-Reply-To: <m2bn1lr0gr.fsf@fastmail.fm>
References: <m2bn1lr0gr.fsf@fastmail.fm>
Message-ID: <e19b25e2-d898-b544-fedf-6ebaaa5b6c20@enigmail.net>

On 25.07.16 21:17, Filipp Gunbin wrote:
> Hi,
> 
> I was trying to compile gnupg-2.1.14 on MacOS X today and ran into the
> following problem.
> 
> Seems that something like -lintl is missing from the compile line.
> 
> libiconv, gettext & adns are installed into /opt/local via MacPorts.
> 
> npth, libassuan, libksba, gpg-error, libgcrypt are built locally and
> installed into /usr/local.
> 
> Thanks,
> Filipp
> 
> 
> CC=gcc-mp-5 ./configure --enable-maintainer-mode
> --with-libiconv-prefix=/opt/local --with-adns=/opt/local
> --with-libintl-prefix=/opt/local && make clean all
> 
> ...
> ...
> 
> gcc-mp-5 -imacros scheme-config.h -I/usr/local/include -I/usr/local/include -I/usr/local/include -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith  -g -O2   -o gpgscm gpgscm-main.o gpgscm-ffi.o gpgscm-scheme.o  ../../common/libcommon.a  -L/opt/local/lib -liconv -lreadline -L/usr/local/lib -lgcrypt -lgpg-error -L/usr/local/lib -lgpg-error 
> 
> Undefined symbols for architecture x86_64:
>   "_libintl_bind_textdomain_codeset", referenced from:
>       _i18n_switchto_utf8 in libcommon.a(libcommon_a-i18n.o)
>       _i18n_switchback in libcommon.a(libcommon_a-i18n.o)
>   "_libintl_bindtextdomain", referenced from:
>       _i18n_init in libcommon.a(libcommon_a-i18n.o)
>       _i18n_localegettext in libcommon.a(libcommon_a-i18n.o)
>   "_libintl_gettext", referenced from:
>       _my_strusage in gpgscm-main.o
>       _create_pipe_and_estream in libcommon.a(libcommon_a-exechelp-posix.o)
>       _gnupg_spawn_process in libcommon.a(libcommon_a-exechelp-posix.o)
>       _gnupg_spawn_process_fd in libcommon.a(libcommon_a-exechelp-posix.o)
>       _gnupg_wait_processes in libcommon.a(libcommon_a-exechelp-posix.o)
>       _gnupg_spawn_process_detached in libcommon.a(libcommon_a-exechelp-posix.o)
>       _disable_core_dumps in libcommon.a(libcommon_a-sysutils.o)
>       ...
>   "_libintl_setlocale", referenced from:
>       _i18n_init in libcommon.a(libcommon_a-i18n.o)
>       _i18n_localegettext in libcommon.a(libcommon_a-i18n.o)
>   "_libintl_textdomain", referenced from:
>       _i18n_init in libcommon.a(libcommon_a-i18n.o)
> ld: symbol(s) not found for architecture x86_64
> collect2: error: ld returned 1 exit status
> 

The patch referenced in the following message fixes this:
http://lists.gnupg.org/pipermail/gnupg-devel/2016-July/031362.html

-Patrick


From bjk at luxsci.net  Tue Jul 26 00:17:57 2016
From: bjk at luxsci.net (Ben Kibbey)
Date: Mon, 25 Jul 2016 18:17:57 -0400
Subject: [PATCH] Create cache item for current key from previous.
In-Reply-To: <87bn1m6sb6.fsf@europa.jade-hamburg.de>
References: <1469322122-2473733.12744896.fu6O11uXB007115@rs146.luxsci.com>
 <87bn1m6sb6.fsf@europa.jade-hamburg.de>
Message-ID: <1469485085-6695680.17668528.fu6PMHwLL017790@rs146.luxsci.com>

On Mon, Jul 25, 2016 at 10:22:05AM +0200, Justus Winter wrote:
> Hi :)

Hi

> > Fixes the KEYINFO cache field for a key that previously failed do to not
> > being found in the cache but succeeded when the last_stored_cache_key
> > was tried. Use the last_stored_cache_key cached passphrase for the new
> > cache entry for the current keygrip.

> Thanks, can you please tell me how to reproduce this problem?

Decrypt a message. Do a gpg-agent KEYINFO with the keygrip of the
decryption key and see that it is cached. Sign a new message.  The
signing keygrip is not cached although the decryption key is (as
expected). This is because last_stored_cache_key grip's passphrase is
tried as the signing key passphrase when its' grip is not in the cache,
which in this case is the decryption key grip. The patch sets a signing
key cache entry passphrase to the same as last_stored_cache_key when
unprotect() succeeds.

I can't think of a way to get the initial signing key cache status set
properly before doing sign operation even though last_stored_cache_key
may successfully do a sign operation without asking for a passphrase.
Would need to do at lease one sign before the cache status of KEYINFO is
updated.

-- 
Ben Kibbey


From fgunbin at fastmail.fm  Tue Jul 26 18:09:17 2016
From: fgunbin at fastmail.fm (Filipp Gunbin)
Date: Tue, 26 Jul 2016 19:09:17 +0300
Subject: compilation error (2.1.14)
In-Reply-To: <e19b25e2-d898-b544-fedf-6ebaaa5b6c20@enigmail.net> (Patrick
 Brunschwig's message of "Mon, 25 Jul 2016 22:31:57 +0200")
References: <m2bn1lr0gr.fsf@fastmail.fm>
 <e19b25e2-d898-b544-fedf-6ebaaa5b6c20@enigmail.net>
Message-ID: <m2fuqwidoy.fsf@fastmail.fm>

On 25/07/2016 22:31 +0200, Patrick Brunschwig wrote:

> The patch referenced in the following message fixes this:
> http://lists.gnupg.org/pipermail/gnupg-devel/2016-July/031362.html

Thanks Patrick!