From dkg at fifthhorseman.net  Wed Mar  1 01:23:08 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 28 Feb 2017 16:23:08 -0800
Subject: continuous integration?
In-Reply-To: <874lzg8r7r.fsf@iwagami.gniibe.org>
References: <877f4dtkb7.fsf@alice.fifthhorseman.net>
 <874lzg8r7r.fsf@iwagami.gniibe.org>
Message-ID: <87lgsprgk3.fsf@alice.fifthhorseman.net>

On Sun 2017-02-26 15:31:04 -0800, NIIBE Yutaka wrote:
> Thanks to Justus, we have the jenkins server (now, with IPv4 address)
> at:
>
>     https://jenkins.gnupg.org/
>
> At XMPP channel of gnupg-devel at conference.jabber.gnupg.org, the jenkins
> server emits message of each build.  IIUC, it builds for
> debian/macos/openbsd/w32 at each new commit and for sanitizer/distcheck
> daily on some conditions.

Thanks, i'm really glad to hear this is in place.  This kind of
infrastructure is important and really useful, and i look forward to
seeing it develop and improve even further.

       --dkg


From justus at g10code.com  Wed Mar  1 14:22:08 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 01 Mar 2017 14:22:08 +0100
Subject: Please help us test the behavior of different Unices
Message-ID: <8760jtb08v.fsf@europa.jade-hamburg.de>

Hello,

I have written a small test program and I would like to ask you to run
it on UNIX platforms that you care about.  (Care as in you want to be
able to run GnuPG on it the future).

This program tests how different UNIX implementations cope with UNIX
domain sockets being created in paths that exceed sizeof (struct
sockaddr_un.sun_path).

The hypothesis is that it is okay to create sockets there, as long as
one uses relative paths for bind and connect.

Building and running this program should be as easy as:

  % make test-unix-sockets && ./test-unix-sockets

This is an example output:

System: GNU:0.9:GNU-Mach 1.8-686-dbg/Hurd-0.9
sizeof addr.sun_path: 108
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '', addrlen: 3
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned '', addrlen: 3
Running test with strlen (cwd): 130, name: 'socket'
  getsockname returned '', addrlen: 3
Running test with strlen (cwd): 1102, name: 'socket'
  getsockname returned '', addrlen: 3

Please post the results here.


Thanks,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170301/361719dd/attachment-0001.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-unix-sockets.c
Type: text/x-csrc
Size: 4114 bytes
Desc: The test program.
URL: </pipermail/attachments/20170301/361719dd/attachment-0001.c>

From gabrielfrancosouza at gmail.com  Wed Mar  1 15:30:50 2017
From: gabrielfrancosouza at gmail.com (Gabriel Souza Franco)
Date: Wed, 1 Mar 2017 11:30:50 -0300
Subject: Can't resolve DNS since 2.1.17
In-Reply-To: <CABaesJL8+LjpZqU2d+HwcPFw3aALuz4vodFSikUwFojAddG30w@mail.gmail.com>
References: <CABaesJJC28PN=Foi5LiuQCQ7CMDJcMGsKjKnrGjS+7F3fZ_V+w@mail.gmail.com>
 <87tw8f3blu.fsf@wheatstone.g10code.de>
 <CABaesJK-BYSoHLRActfQvx_a23GzwWuXXRaDQWCJzh8j_N78pw@mail.gmail.com>
 <CABaesJJeXKsyHsDW9Y8sLarF7G+4n9OHRMyoc=saQxdUZbSXDA@mail.gmail.com>
 <87zihqneen.fsf@alice.fifthhorseman.net>
 <CABaesJLbHxQT62BCRGyoN3=donjx_Wk_fipZwjimPVVYO5bbeQ@mail.gmail.com>
 <87o9y5od12.fsf@alice.fifthhorseman.net>
 <CABaesJKqWrax7UYpfO2z8knaHn=cDfvDaYHk7UjHmL-FGUjsUQ@mail.gmail.com>
 <87inodoc87.fsf@alice.fifthhorseman.net>
 <CABaesJL8+LjpZqU2d+HwcPFw3aALuz4vodFSikUwFojAddG30w@mail.gmail.com>
Message-ID: <CABaesJLLUBB9+gznUmcuWasiTACVh0jVpWXow-1OX_ZrHWNX9w@mail.gmail.com>

On Mon, Feb 13, 2017 at 11:01 PM, Gabriel Souza Franco
<gabrielfrancosouza at gmail.com> wrote:
> On Mon, Feb 13, 2017 at 10:19 PM, Daniel Kahn Gillmor
> <dkg at fifthhorseman.net> wrote:
>>
>> I believe the PTR requests themselves are a bug, so not making them
>> seems just fine to me:
>>
>>   https://bugs.gnupg.org/gnupg/issue2928
>>
>> So it looks to me like the stock behavior is the correct behavior for
>> dirmngr to me, given a broken DNS resolver that cannot handle SRV
>> queries.
>>
>> Can you explain what you would expect to be done differently?
>>
>>        --dkg
>
> Not bailing out on a FORMERR from a SRV query. Note that my problem
> isn't that my resolver can't handle SRV, but that it gives the wrong
> answer instead of a NXDOMAIN. This marks the keyserver as dead even
> with successful A and AAAA replies.
>
> $ gpg --refresh-keys
> gpg: refreshing [?] keys from hkps://hkps.pool.sks-keyservers.net
> gpg: keyserver refresh failed: No keyserver available

Ping. I would really like to see a solution for this.


From patrick at enigmail.net  Wed Mar  1 15:44:01 2017
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Wed, 1 Mar 2017 15:44:01 +0100
Subject: Please help us test the behavior of different Unices
In-Reply-To: <8760jtb08v.fsf@europa.jade-hamburg.de>
References: <8760jtb08v.fsf@europa.jade-hamburg.de>
Message-ID: <800e5972-1526-1e22-6158-37e23c2e1572@enigmail.net>

On 01.03.17 14:22, Justus Winter wrote:
> Hello,
> 
> I have written a small test program and I would like to ask you to run
> it on UNIX platforms that you care about.  (Care as in you want to be
> able to run GnuPG on it the future).
> 
> This program tests how different UNIX implementations cope with UNIX
> domain sockets being created in paths that exceed sizeof (struct
> sockaddr_un.sun_path).
> 
> The hypothesis is that it is okay to create sockets there, as long as
> one uses relative paths for bind and connect.
> 
> Building and running this program should be as easy as:
> 
>   % make test-unix-sockets && ./test-unix-sockets
> 
> This is an example output:
> 
> System: GNU:0.9:GNU-Mach 1.8-686-dbg/Hurd-0.9
> sizeof addr.sun_path: 108
> Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
>   getsockname returned '', addrlen: 3
> Running test with strlen (cwd): 22, name: 'socket'
>   getsockname returned '', addrlen: 3
> Running test with strlen (cwd): 130, name: 'socket'
>   getsockname returned '', addrlen: 3
> Running test with strlen (cwd): 1102, name: 'socket'
>   getsockname returned '', addrlen: 3
> 
> Please post the results here.

macOS Sierra (10.12):

System: Darwin:16.4.0:Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21
PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64
sizeof addr.sun_path: 104
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 106
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 126, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 1062, name: 'socket'
  getsockname returned 'socket', addrlen: 106

-Patrick


From jochen at intevation.de  Wed Mar  1 15:48:26 2017
From: jochen at intevation.de (Jochen Saalfeld)
Date: Wed, 01 Mar 2017 15:48:26 +0100
Subject: Please help us test the behavior of different Unices
In-Reply-To: <8760jtb08v.fsf@europa.jade-hamburg.de>
References: <8760jtb08v.fsf@europa.jade-hamburg.de>
Message-ID: <6478600.Gqcn9pSIpf@archimedes>

Hi Justus,

System: Linux:4.9.11-1-ARCH:#1 SMP PREEMPT Sun Feb 19 13:45:52 UTC 2017
sizeof addr.sun_path: 108
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 32
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 9
Running test with strlen (cwd): 130, name: 'socket'
  getsockname returned 'socket', addrlen: 9
Running test with strlen (cwd): 1102, name: 'socket'
  getsockname returned 'socket', addrlen: 9

Cheers,
Jochen

On Wednesday, March 1, 2017 2:22:08 PM CET Justus Winter wrote:
> Hello,
> 
> I have written a small test program and I would like to ask you to run
> it on UNIX platforms that you care about.  (Care as in you want to be
> able to run GnuPG on it the future).
> 
> This program tests how different UNIX implementations cope with UNIX
> domain sockets being created in paths that exceed sizeof (struct
> sockaddr_un.sun_path).
> 
> The hypothesis is that it is okay to create sockets there, as long as
> one uses relative paths for bind and connect.
> 
> Building and running this program should be as easy as:
> 
>   % make test-unix-sockets && ./test-unix-sockets
> 
> This is an example output:
> 
> System: GNU:0.9:GNU-Mach 1.8-686-dbg/Hurd-0.9
> sizeof addr.sun_path: 108
> Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
>   getsockname returned '', addrlen: 3
> Running test with strlen (cwd): 22, name: 'socket'
>   getsockname returned '', addrlen: 3
> Running test with strlen (cwd): 130, name: 'socket'
>   getsockname returned '', addrlen: 3
> Running test with strlen (cwd): 1102, name: 'socket'
>   getsockname returned '', addrlen: 3
> 
> Please post the results here.
> 
> 
> Thanks,
> Justus


-- 
jochen at intevation.de | intevation.de/ | 0541335083214 | PGPkey: 0x64B67DF4
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170301/8b3ca2a7/attachment.sig>

From ilf at zeromail.org  Wed Mar  1 17:40:55 2017
From: ilf at zeromail.org (ilf)
Date: Wed, 1 Mar 2017 17:40:55 +0100
Subject: Please help us test the behavior of different Unices
In-Reply-To: <8760jtb08v.fsf@europa.jade-hamburg.de>
References: <8760jtb08v.fsf@europa.jade-hamburg.de>
Message-ID: <20170301164055.GN22285@zeromail.org>

Justus Winter:
> Please post the results here.

System: FreeBSD:7.3-STABLE

sizeof addr.sun_path: 104
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 106
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 126, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 1062, name: 'socket'
  getsockname returned 'socket', addrlen: 106

-- 
ilf

?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
		-- Eine Initiative des Bundesamtes f?r Tastaturbenutzung
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170301/6d9b2344/attachment.sig>

From dkg at fifthhorseman.net  Wed Mar  1 18:44:44 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 01 Mar 2017 09:44:44 -0800
Subject: Please help us test the behavior of different Unices
In-Reply-To: <8760jtb08v.fsf@europa.jade-hamburg.de>
References: <8760jtb08v.fsf@europa.jade-hamburg.de>
Message-ID: <87h93cq4c3.fsf@alice.fifthhorseman.net>

On Wed 2017-03-01 05:22:08 -0800, Justus Winter wrote:
> I have written a small test program and I would like to ask you to run
> it on UNIX platforms that you care about.  (Care as in you want to be
> able to run GnuPG on it the future).

System: Linux:4.9.0-1-amd64:#1 SMP Debian 4.9.6-3 (2017-01-28)
sizeof addr.sun_path: 108
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 32
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 9
Running test with strlen (cwd): 130, name: 'socket'
  getsockname returned 'socket', addrlen: 9
Running test with strlen (cwd): 1102, name: 'socket'
  getsockname returned 'socket', addrlen: 9

Regards,

        --dkg


From wk at gnupg.org  Wed Mar  1 20:27:00 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 01 Mar 2017 20:27:00 +0100
Subject: [Announce] GnuPG 2.1.19 released
Message-ID: <87d1e0bxx7.fsf@wheatstone.g10code.de>

Hello!

The GnuPG team is pleased to announce the availability of a new release
of GnuPG: version 2.1.19.  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.  As an Universal Crypto
Engine GnuPG provides support for S/MIME and Secure Shell in addition to
OpenPGP.

There are two major flavours of GnuPG:

- GnuPG 2.1 (dubbed "modern") comes with the latest features and is
  suggested for most users.  This announcement is about this branch.

- GnuPG 2.0 is an older but widely used branch which we will maintain
  until 2017-12-31.

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.


Noteworthy changes in version 2.1.19
====================================

  * gpg: Print a warning if Tor mode is requested but the Tor daemon
    is not running.

  * gpg: New status code DECRYPTION_KEY to print the actual private
    key used for decryption.

  * gpgv: New options --log-file and --debug.

  * gpg-agent: Revamp the prompts to ask for card PINs.

  * scd: Support for multiple card readers.

  * scd: Removed option --debug-disable-ticker.  Ticker is used
    only when it is required to watch removal of device/card.

  * scd: Improved detection of card inserting and removal.

  * dirmngr: New option --disable-ipv4.

  * dirmngr: New option --no-use-tor to explicitly disable the use of
    Tor.

  * dirmngr: The option --allow-version-check is now required even if
    the option --use-tor is also used.

  * dirmngr: Handle a missing nsswitch.conf gracefully.

  * dirmngr: Avoid PTR lookups for keyserver pools.  The are only done
    for the debug command "keyserver --hosttable".

  * dirmngr: Rework the internal certificate cache to support classes
    of certificates.  Load system provided certificates on startup.
    Add options --tls, --no-crl, and --systrust to the "VALIDATE"
    command.

  * dirmngr: Add support for the ntbtls library.

  * wks: Create mails with a "WKS-Phase" header.  Fix detection of
    Draft-2 mode.

  * The Windows installer is now build with limited TLS support.

  * Many other bug fixes and new regression tests.

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


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

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

GnuPG 2.1.19 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:

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

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

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.19_20170301.exe  (3670k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.19_20170301.exe.sig
or here
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.19_20170301.exe
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.19_20170301.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.  The Windows installer now comes with
TOFU support, many translations, support for Tor, and limited support
for HKPS and Web Key Directory.


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.19.tar.bz2 you would use this command:

     gpg --verify gnupg-2.1.19.tar.bz2.sig gnupg-2.1.19.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 the end of this mail 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.19.tar.bz2, you run the command like this:

     sha1sum gnupg-2.1.19.tar.bz2

   and check that the output matches the next line:

10a088a6716789ac5c5cce2776952d8f4a5c57fc  gnupg-2.1.19.tar.bz2
2614462170937abae1293cf227cacfb1028a11d3  gnupg-w32-2.1.19_20170301.exe
abcfb15a59abb2bf05e9182133df53e5c5666272  gnupg-w32-2.1.19_20170301.tar.xz


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

This version of GnuPG has support for 26 languages with Chinese, Czech,
French, German, Japanese, Norwegian, Russian, and Ukrainian being almost
completely translated.  Due to expected changes in forthcoming releases
some strings pertaining to the TOFU code are not yet translated.


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 4 full-time developers, one part-timer, and
one contractor.  They all work exclusivly on GnuPG and closely related
software like Libgcrypt, GPGME, 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.


The GnuPG hackers,

   Andre, dkg, gniibe, Justus, Neal, and Werner



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

p.p.s
List of 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: 2020-10-30]
  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)

The keys are 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.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20170301/389f9b48/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From sms at antinode.info  Wed Mar  1 23:37:08 2017
From: sms at antinode.info (Steven M. Schweda)
Date: Wed, 1 Mar 2017 16:37:08 -0600 (CST)
Subject: Please help us test the behavior of different Unices
Message-ID: <17030116370862_2020D3F2@antinode.info>

From: Justus Winter <justus at g10code.com>

> [...]  UNIX platforms that you care about.  (Care as in you want to be
> able to run GnuPG on it the future).

   I don't claim to care about any of the systems shown below, but
someone might.  (And my junk collection could use the exercise.)

> Building and running this program should be as easy as:
> 
>   % make test-unix-sockets && ./test-unix-sockets

   Thare's an optimist.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   HP-UX 11.11 (PA-RISC):

dy# uname -a
HP-UX dy B.11.11 U 9000/785 2012616114 unlimited-user license

dy# gcc --version
gcc (GCC) 4.4.2
[...]

dy# gcc -o test-unix-sockets test-unix-sockets.c

dy# ./test-unix-sockets
System: HP-UX:B.11.11:U
sizeof addr.sun_path: 92
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 94
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 94
Running test with strlen (cwd): 114, name: 'socket'
  getsockname returned 'socket', addrlen: 94
Running test with strlen (cwd): 1034, name: 'socket'
  getsockname returned 'socket', addrlen: 94

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   HP-UX 11.31 (IA64):

rux# uname -a
HP-UX rux B.11.31 U ia64 1678555272 unlimited-user license

rux# cc -V   
(Bundled) cc: HP C/aC++ B3910B A.06.12 [Oct 11 2006]

rux# cc -o test-unix-sockets test-unix-sockets.c
"test-unix-sockets.c", line 101: warning #2167-D: argument of type
          "socklen_t *" is incompatible with parameter of type "int *"
    if (getsockname (server, (struct sockaddr *) &addr, &addrlen) < 0)
                                                        ^

rux# ./test-unix-sockets                          
System: HP-UX:B.11.31:U
sizeof addr.sun_path: 92
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 94
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 94
Running test with strlen (cwd): 114, name: 'socket'
  getsockname returned 'socket', addrlen: 94
Running test with strlen (cwd): 1034, name: 'socket'
  getsockname returned 'socket', addrlen: 94

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Solaris 10 (SPARC):

ra# uname -a
SunOS ra 5.10 Generic_141444-09 sun4u sparc SUNW,UltraSPARC-IIi-cEngine

ra# cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
[...]

ra# cc -o test-unix-sockets test-unix-sockets.c
Undefined                       first referenced
 symbol                             in file
bind                                test-unix-sockets.o
getsockname                         test-unix-sockets.o
accept                              test-unix-sockets.o
listen                              test-unix-sockets.o
socket                              test-unix-sockets.o
connect                             test-unix-sockets.o
ld: fatal: Symbol referencing errors. No output written to test-unix-sockets

ra# cc -o test-unix-sockets test-unix-sockets.c -lsocket

ra# ./test-unix-sockets
System: SunOS:5.10:Generic_141444-09
sizeof addr.sun_path: 108
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 110
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 110
Running test with strlen (cwd): 130, name: 'socket'
  getsockname returned 'socket', addrlen: 110
Running test with strlen (cwd): 1102, name: 'socket'
  getsockname returned 'socket', addrlen: 110

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Solaris 11 (x86):

soli7# uname -a
SunOS soli7 5.11 11.1 i86pc i386 i86pc

soli7# cc -V
cc: Sun C 5.12 SunOS_i386 2011/11/16

soli7# cc -o test-unix-sockets test-unix-sockets.c
Undefined                       first referenced
 symbol                             in file
bind                                test-unix-sockets.o
getsockname                         test-unix-sockets.o
accept                              test-unix-sockets.o
listen                              test-unix-sockets.o
socket                              test-unix-sockets.o
connect                             test-unix-sockets.o
ld: fatal: symbol referencing errors. No output written to test-unix-sockets

soli7# cc -o test-unix-sockets test-unix-sockets.c -lsocket

soli7# ./test-unix-sockets
System: SunOS:5.11:11.1
sizeof addr.sun_path: 108
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 110
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 110
Running test with strlen (cwd): 130, name: 'socket'
  getsockname returned 'socket', addrlen: 110
Running test with strlen (cwd): 1102, name: 'socket'
  getsockname returned 'socket', addrlen: 110

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Tru64 V5.1B:

urtx# uname -a
OSF1 urtx.antinode.info V5.1 2650 alpha

urtx# sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Wed Feb 17 22:59:59 CST 2016

urtx# cc -V
Compaq C V6.5-303 (dtk) on HP Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-302 (dtk) cc Driver

urtx# cc -o test-unix-sockets test-unix-sockets.c
cc: Error: test-unix-sockets.c, line 57: In this declaration,
 "socklen_t" must specify a type. (badparsedecl)
  socklen_t addrlen;
--^
cc: Error: test-unix-sockets.c, line 99: In this statement, "addrlen" is
 not declared. (undeclared)
  addrlen = sizeof addr;
--^

urtx# cc -o test-unix-sockets -D_XOPEN_SOURCE=500 test-unix-sockets.c

urtx# ./test-unix-sockets
System: OSF1:V5.1:2650
sizeof addr.sun_path: 104
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 106
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 126, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 1062, name: 'socket'
  getsockname returned 'socket', addrlen: 106

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

   Steven M. Schweda               sms at antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547


From gnupg-devel at spodhuis.org  Thu Mar  2 03:58:13 2017
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Thu, 2 Mar 2017 02:58:13 +0000
Subject: Please help us test the behavior of different Unices
In-Reply-To: <20170301164055.GN22285@zeromail.org>
References: <8760jtb08v.fsf@europa.jade-hamburg.de>
 <20170301164055.GN22285@zeromail.org>
Message-ID: <20170302025813.GA45959@tower.spodhuis.org>

On 2017-03-01 at 17:40 +0100, ilf wrote:
> Justus Winter:
> > Please post the results here.
> 
> System: FreeBSD:7.3-STABLE

Ditto on FreeBSD:10.3-RELEASE series (kernel -p11)

No difference in output whether compiled with the system compiler (clang
3.4.1) or gcc 4.9.4.  Didn't expect any, but didn't hurt to check.

System: FreeBSD:10.3-RELEASE-p11:FreeBSD 10.3-RELEASE-p11 #0: Mon Oct 24 18:49:24 UTC 2016     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
sizeof addr.sun_path: 104
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 106
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 126, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 1062, name: 'socket'
  getsockname returned 'socket', addrlen: 106

-Phil


From wk at gnupg.org  Thu Mar  2 08:55:47 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 02 Mar 2017 08:55:47 +0100
Subject: [PATCH] g10: fix typo
In-Reply-To: <CAFOnWk=Tvtm11RyCUui+iuOaoUOCqDDpN5jo-OZ4btwruAyrNQ@mail.gmail.com>
 (Manish Goregaokar's message of "Fri, 24 Feb 2017 20:41:39 -0800")
References: <CAFOnWk=Tvtm11RyCUui+iuOaoUOCqDDpN5jo-OZ4btwruAyrNQ@mail.gmail.com>
Message-ID: <871sug9kos.fsf@wheatstone.g10code.de>

Hi!

On Sat, 25 Feb 2017 05:41, manish at mozilla.com said:
> I already have copyright assignment with the FSF for GDB. I don't think
> I'll need to do the DCO thing.

The FSF requires copyright assignments on a per project base.  A very
few companies onec had catch-all assignments.  For exmaple my company
until we terminated it.

Anyway, your patch is small enough and not copyright-able so that dkg
had no problems to apply it.

Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170302/d75834cd/attachment.sig>

From wk at gnupg.org  Thu Mar  2 09:02:45 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 02 Mar 2017 09:02:45 +0100
Subject: Can't resolve DNS since 2.1.17
In-Reply-To: <CABaesJL8+LjpZqU2d+HwcPFw3aALuz4vodFSikUwFojAddG30w@mail.gmail.com>
 (Gabriel Souza Franco's message of "Mon, 13 Feb 2017 23:01:27 -0200")
References: <CABaesJJC28PN=Foi5LiuQCQ7CMDJcMGsKjKnrGjS+7F3fZ_V+w@mail.gmail.com>
 <87tw8f3blu.fsf@wheatstone.g10code.de>
 <CABaesJK-BYSoHLRActfQvx_a23GzwWuXXRaDQWCJzh8j_N78pw@mail.gmail.com>
 <CABaesJJeXKsyHsDW9Y8sLarF7G+4n9OHRMyoc=saQxdUZbSXDA@mail.gmail.com>
 <87zihqneen.fsf@alice.fifthhorseman.net>
 <CABaesJLbHxQT62BCRGyoN3=donjx_Wk_fipZwjimPVVYO5bbeQ@mail.gmail.com>
 <87o9y5od12.fsf@alice.fifthhorseman.net>
 <CABaesJKqWrax7UYpfO2z8knaHn=cDfvDaYHk7UjHmL-FGUjsUQ@mail.gmail.com>
 <87inodoc87.fsf@alice.fifthhorseman.net>
 <CABaesJL8+LjpZqU2d+HwcPFw3aALuz4vodFSikUwFojAddG30w@mail.gmail.com>
Message-ID: <87vars6r8a.fsf@wheatstone.g10code.de>

On Tue, 14 Feb 2017 02:01, gabrielfrancosouza at gmail.com said:

> Not bailing out on a FORMERR from a SRV query. Note that my problem
> isn't that my resolver can't handle SRV, but that it gives the wrong
> answer instead of a NXDOMAIN. This marks the keyserver as dead even

I don't think that it is the responsibility of dirmngr to work around
bugs in some rarely used software.  In fact I believe that a box running
such faulty software is security problem in itself because it tricks
users into using all kind of workarounds.

What we could do is to provide a variant of the --nameserver option to
be used in the non-Tor case.  Thus bypassing nsswitch completely.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170302/a0a86d82/attachment.sig>

From jochen at intevation.de  Thu Mar  2 09:44:56 2017
From: jochen at intevation.de (Jochen Saalfeld)
Date: Thu, 02 Mar 2017 09:44:56 +0100
Subject: Please help us test the behavior of different Unices
In-Reply-To: <8760jtb08v.fsf@europa.jade-hamburg.de>
References: <8760jtb08v.fsf@europa.jade-hamburg.de>
Message-ID: <3368818.gMFguMIuVf@archimedes>

Hi again,

some additional Information from other sources[1]:

NetBSD 6, 7 and current are all the same on multiple architectures:
System: NetBSD:6.1_STABLE:NetBSD 6.1_STABLE (LUNA-$Revision: 6.2 $) #0: Mon 
Jan  9 21:39:01 UTC 2017  john at chi.zia.io:/usr/release/obj-vax/sys/arch/vax/
compile/LUNA
sizeof addr.sun_path: 104
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 106
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 126, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 1062, name: 'socket'
  getsockname returned 'socket', addrlen: 106

Mac OS X (PowerPC, amd64) are the same:
System: Darwin:9.8.0:Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 
2009; root:xnu-1228.15.4~1/RELEASE_PPC
sizeof addr.sun_path: 104
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 106
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 126, name: 'socket'
  getsockname returned 'socket', addrlen: 106
Running test with strlen (cwd): 1062, name: 'socket'
  getsockname returned 'socket', addrlen: 106

On IBM Power8 running Ubuntu GNU/Linux (ppc64le):
System: Linux:4.4.0-64-generic:#85-Ubuntu SMP Mon Feb 20 17:05:51 UTC 2017
sizeof addr.sun_path: 108
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 32
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 9
Running test with strlen (cwd): 130, name: 'socket'
  getsockname returned 'socket', addrlen: 9
Running test with strlen (cwd): 1102, name: 'socket'
  getsockname returned 'socket', addrlen: 9

Kind regards,
Jochen

[1] - https://www.reddit.com/r/GnuPG/comments/5ww75f/
please_help_us_test_the_behavior_of_different/deemis8/?context=3

On Wednesday, March 1, 2017 2:22:08 PM CET Justus Winter wrote:
> Hello,
> 
> I have written a small test program and I would like to ask you to run
> it on UNIX platforms that you care about.  (Care as in you want to be
> able to run GnuPG on it the future).
> 
> This program tests how different UNIX implementations cope with UNIX
> domain sockets being created in paths that exceed sizeof (struct
> sockaddr_un.sun_path).
> 
> The hypothesis is that it is okay to create sockets there, as long as
> one uses relative paths for bind and connect.
> 
> Building and running this program should be as easy as:
> 
>   % make test-unix-sockets && ./test-unix-sockets
> 
> This is an example output:
> 
> System: GNU:0.9:GNU-Mach 1.8-686-dbg/Hurd-0.9
> sizeof addr.sun_path: 108
> Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
>   getsockname returned '', addrlen: 3
> Running test with strlen (cwd): 22, name: 'socket'
>   getsockname returned '', addrlen: 3
> Running test with strlen (cwd): 130, name: 'socket'
>   getsockname returned '', addrlen: 3
> Running test with strlen (cwd): 1102, name: 'socket'
>   getsockname returned '', addrlen: 3
> 
> Please post the results here.
> 
> 
> Thanks,
> Justus


-- 
jochen at intevation.de | intevation.de/ | 0541335083214 | PGPkey: 0x64B67DF4
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170302/bf5f26b4/attachment.sig>

From gniibe at fsij.org  Thu Mar  2 11:46:06 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 02 Mar 2017 19:46:06 +0900
Subject: Please help us test the behavior of different Unices
In-Reply-To: <8760jtb08v.fsf@europa.jade-hamburg.de>
References: <8760jtb08v.fsf@europa.jade-hamburg.de>
Message-ID: <8737ew6jo1.fsf@fsij.org>

Hello,

Justus Winter <justus at g10code.com> writes:
>   % make test-unix-sockets && ./test-unix-sockets

$ uname -a
AIX power-aix 1 7 00F84C0C4C00
$ make CC=gcc test-unix-sockets
        gcc -O  test-unix-sockets.c -o test-unix-sockets
$ ./test-unix-sockets 
System: AIX:1:7
sizeof addr.sun_path: 1023
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 1025
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 1025
chdir: File name too long
$ 


$ uname -a
AIX power8-aix 2 7 00FA74164C00
$ make CC=gcc test-unix-sockets
        gcc -O  test-unix-sockets.c -o test-unix-sockets
$ ./test-unix-sockets 
System: AIX:2:7
sizeof addr.sun_path: 1023
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 1025
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 1025
chdir: File name too long
$ 
-- 


From justus at g10code.com  Thu Mar  2 13:00:53 2017
From: justus at g10code.com (Justus Winter)
Date: Thu, 02 Mar 2017 13:00:53 +0100
Subject: Please help us test the behavior of different Unices
In-Reply-To: <8737ew6jo1.fsf@fsij.org>
References: <8760jtb08v.fsf@europa.jade-hamburg.de> <8737ew6jo1.fsf@fsij.org>
Message-ID: <877f47c2h6.fsf@europa.jade-hamburg.de>

Hi,

NIIBE Yutaka <gniibe at fsij.org> writes:
> $ ./test-unix-sockets 
> System: AIX:1:7
> sizeof addr.sun_path: 1023

That is amazing.  Well, I guess we wouldn't have these kind of problems
on AIX in the first place.

> Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
>   getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 1025
> Running test with strlen (cwd): 22, name: 'socket'
>   getsockname returned 'socket', addrlen: 1025
> chdir: File name too long

I guess we're hitting PATH_MAX here, and AIX is actually serious about
it.

I have revised the test program to be a little more conservative here.
Would you be so kind to rerun it?

(There is no need to rerun the test on systems where the previous
version succeeded.)


Thanks,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170302/b28d2a38/attachment-0001.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-unix-sockets.c
Type: text/x-csrc
Size: 4124 bytes
Desc: The revised test.
URL: </pipermail/attachments/20170302/b28d2a38/attachment-0001.c>

From gniibe at fsij.org  Thu Mar  2 13:27:47 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 02 Mar 2017 21:27:47 +0900
Subject: Please help us test the behavior of different Unices
In-Reply-To: <877f47c2h6.fsf@europa.jade-hamburg.de>
References: <8760jtb08v.fsf@europa.jade-hamburg.de> <8737ew6jo1.fsf@fsij.org>
 <877f47c2h6.fsf@europa.jade-hamburg.de>
Message-ID: <87zih36eyk.fsf@fsij.org>

Justus Winter <justus at g10code.com> writes:
> I have revised the test program to be a little more conservative here.
> Would you be so kind to rerun it?

Here they are.


$ ./test-unix-sockets 
System: AIX:1:7
sizeof addr.sun_path: 1023
PATH_MAX: 1023
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 1025
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 1025
Running test with strlen (cwd): 122, name: 'socket'
  getsockname returned 'socket', addrlen: 1025
Running test with strlen (cwd): 822, name: 'socket'
  getsockname returned 'socket', addrlen: 1025
$ 

$ ./test-unix-sockets 
System: AIX:2:7
sizeof addr.sun_path: 1023
PATH_MAX: 1023
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'
  getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 1025
Running test with strlen (cwd): 22, name: 'socket'
  getsockname returned 'socket', addrlen: 1025
Running test with strlen (cwd): 122, name: 'socket'
  getsockname returned 'socket', addrlen: 1025
Running test with strlen (cwd): 822, name: 'socket'
  getsockname returned 'socket', addrlen: 1025
$ 
-- 


From aheinecke at intevation.de  Fri Mar  3 17:33:11 2017
From: aheinecke at intevation.de (Andre Heinecke)
Date: Fri, 03 Mar 2017 17:33:11 +0100
Subject: Gpg4win-3.0-beta215, we are getting there
Message-ID: <6782477.MjsgaSxcGq@esus>

Hi,

After some more time of hot development I've just uploaded a new beta 
installer for Gpg4win. We are getting there but sadly this is not yet a real 
Release Candidate as we still have some missing features / known issues we 
want for 3.0.

(See https://wiki.gnupg.org/Gpg4win/Testversions )

It contains GnuPG-2.1.19 and a largely reworked GpgOL.

My personal Opinion is that this is the first Version of GpgOL that is actually 
fun to use and has a good Quality already. :-)

There probably still are some bugs (thats why it's beta) as a lot of the code 
was changed but in principle the inner workings of GpgOL should be more solid 
and reliable now.


Some of the biggest changes compared to the last beta are:

- GpgOL no longer modifies your MAPI Stores (no spurious syncs, no "do you want 
to save changes bugs etc.)

- It does decryption / verification by itself and shows the Signature / Crypto 
state itself.

- GpgOL now fully supports HTML Mails (even with embedded images)

- GpgOL and GnuPG now support Web Key Directories (if configured accordingly)

Sadly what did not make it into the beta was a new and improved key selection 
dialog for GpgOL. This will come soon.

Kleopatra also got some love:

- Kleopatra has a new Key Details dialog (which needs some more work but it's 
already an improvement)

- Kleopatra can now manage PGP smartcards.

- File encryption can now again create multiple files instead of only archives.

There are many more things and of course the updated GnuPG in itself has seen 
lots of changes. E.g. Some hangs of the agent which happend with the previous 
version should now be gone.


Please help us with your feedback.
Thanks,

Andre

P.S.
Maybe we'll anounce the beta on gpg4win-announce later after we have done some 
more testing internally.

-- 
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: 228 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170303/4e327a29/attachment.sig>

From aheinecke at intevation.de  Fri Mar  3 18:41:39 2017
From: aheinecke at intevation.de (Andre Heinecke)
Date: Fri, 03 Mar 2017 18:41:39 +0100
Subject: Gpg4win-3.0-beta215, we are getting there
In-Reply-To: <6782477.MjsgaSxcGq@esus>
References: <6782477.MjsgaSxcGq@esus>
Message-ID: <3266438.79Frl28rQC@esus>

On Friday 03 March 2017 17:33:11 Andre Heinecke wrote:
> After some more time of hot development I've just uploaded a new beta
> installer for Gpg4win. We are getting there but sadly this is not yet a real
> Release Candidate as we still have some missing features / known issues we
> want for 3.0.

Urgs, I sent this to the wrong list. That mail was meant for gpg4win-devel and 
not gnupg-devel.

Sorry for the noise,
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: 228 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170303/3102272f/attachment.sig>

From gnupg-devel at spodhuis.org  Sat Mar  4 07:10:29 2017
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Sat, 4 Mar 2017 01:10:29 -0500
Subject: assertion failure / key-locate local / macOS
Message-ID: <20170304061029.GA13739@breadbox.private.spodhuis.org>

On macOS with GnuPG 2.1.19 installed via Homebrew
(homebrew/versions/gnupg21 bottled) the failure was initially seen with:

  % gpg --auto-key-locate dane --locate-keys phil.pennock at spodhuis.org
  gpg: Ohhhh jeeee: Assertion "uid->ref > 0" in free_user_id failed (free-packet.c:310)
  zsh: abort      gpg --auto-key-locate dane --locate-keys phil.pennock at spodhuis.org

This seems to be tied to the implicit `local` ahead of the dane.  I
can't yet narrow down what other pre-requisites exist in state.

I am unable to reproduce with my Linux build, despite both being GnuPG
2.1.19 with libgcrypt 1.7.6.  The `clear` and `nodefault` parameter
values don't impact upon it.  I've tried on Linux without a secret
keyring, with a secret keyring with that secret key and with a secret
keyring with a different key.

I can't reproduce with an empty GNUPGHOME.

If I use `--auto-key-locate nodefault,dane` then it does not crash.  I
do NOT set `auto-key-locate` in the ~/.gnupg/gpg.conf on this box.

  for M in cert pka dane wkd ldap keyserver keyserver-URL local
  do
    echo $M
    gpg --auto-key-locate nodefault,$M --locate-keys phil.pennock at spodhuis.org
    echo
  done
=> only one failure:

  local
  gpg: please do a --check-trustdb
  gpg: automatically retrieved 'phil.pennock at spodhuis.org' via Local
  gpg: Ohhhh jeeee: Assertion "uid->ref > 0" in free_user_id failed (free-packet.c:310)

I also had a warning about an old gpg-agent (2.1.18), so I used gpgconf
to kill it and tried the loop again; no failures.  So I tried the
original command again (first in this mail) and it died in the same way
again.  Running the loop again thereafter, I see the assertion failure.

Killing the gpg-agent again does not cause gpg to dodge the assertion
failure on the next run.

The secret keyring on this box does have two different keys with that
email address on them, _not_ the key in DNS via PKA / OPENPGPKEY:

------------------------8< macOS secret keys >8-------------------------
sec   nistp256 2016-02-06 [SC] [expires: 2018-09-01]
      D4605F3B81A2F275F3D3F5F46313DCDBCA8A9567
uid           [ultimate] Phil Pennock (Laptop & exposed) <phil.pennock at spodhuis.org>

sec   rsa2048 2016-09-01 [SC]
      AB882DD64035A24758F69688D231BDA6A79FCEE0
uid           [ultimate] Phil Pennock (keybase) <phil at pennock-tech.com>
uid           [ultimate] Phil Pennock (keybase) <phil.pennock at spodhuis.org>
ssb   rsa2048 2016-09-01 [E]
------------------------8< macOS secret keys >8-------------------------

The key being retrieved is my main key, reduced to only non-expired
self-sigs (using a git-HEAD build on the Linux machine where that
keyring lives).

Reading the source at that line just tells me that `free_user_id()` was
called for a uid with a ref-count of zero.

I have been unable to trigger this assertion failure in a temporary
GnuPG home, no matter what order I try the options in; the temporary
GnuPG home is setup with just:

  export GNUPGHOME=$(mktemp -d)

The build recipe for the assertion-violating macOS install is at:

  https://github.com/Homebrew/homebrew-versions/blob/master/gnupg21.rb

% otool -L =gpg
/usr/local/bin/gpg:
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
	/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
	/usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.5.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1348.28.0)
	/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 253.0.0)
	/usr/local/opt/libgcrypt/lib/libgcrypt.20.dylib (compatibility version 22.0.0, current version 22.6.0)
	/usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib (compatibility version 22.0.0, current version 22.0.0)
	/usr/local/opt/libassuan/lib/libassuan.0.dylib (compatibility version 8.0.0, current version 8.3.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

% readlink /usr/local/opt/{libgcrypt,libgpg-error,libassuan,gettext}
../Cellar/libgcrypt/1.7.6
../Cellar/libgpg-error/1.26
../Cellar/libassuan/2.4.3_1
../Cellar/gettext/0.19.8.1


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 996 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170304/90819794/attachment.sig>

From wk at gnupg.org  Sat Mar  4 09:45:57 2017
From: wk at gnupg.org (Werner Koch)
Date: Sat, 04 Mar 2017 09:45:57 +0100
Subject: assertion failure / key-locate local / macOS
In-Reply-To: <20170304061029.GA13739@breadbox.private.spodhuis.org> (Phil
 Pennock's message of "Sat, 4 Mar 2017 01:10:29 -0500")
References: <20170304061029.GA13739@breadbox.private.spodhuis.org>
Message-ID: <87k2851lbu.fsf@wheatstone.g10code.de>

Hi!

Thanks for the detailed report

>   % gpg --auto-key-locate dane --locate-keys phil.pennock at spodhuis.org
>   gpg: Ohhhh jeeee: Assertion "uid->ref > 0" in free_user_id failed (free-packet.c:310)

Can you please run it also under gdb (or another debugger), set a
breakpoint at _log_assert and when it gets hit produce a stack backtace
("bt full")?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170304/5ed9f752/attachment.sig>

From gnupg-devel at spodhuis.org  Sat Mar  4 23:35:25 2017
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Sat, 4 Mar 2017 17:35:25 -0500
Subject: assertion failure / key-locate local / macOS
In-Reply-To: <87k2851lbu.fsf@wheatstone.g10code.de>
References: <20170304061029.GA13739@breadbox.private.spodhuis.org>
 <87k2851lbu.fsf@wheatstone.g10code.de>
Message-ID: <20170304223524.GA17770@breadbox.private.spodhuis.org>

On 2017-03-04 at 09:45 +0100, Werner Koch wrote:
> >   % gpg --auto-key-locate dane --locate-keys phil.pennock at spodhuis.org
> >   gpg: Ohhhh jeeee: Assertion "uid->ref > 0" in free_user_id failed (free-packet.c:310)
> 
> Can you please run it also under gdb (or another debugger), set a
> breakpoint at _log_assert and when it gets hit produce a stack backtace
> ("bt full")?

Check mailman administration queue, 69KiB message body got held for
moderation.  Can also shove the backtrace on a server and repost if
you'd rather.

In case Werner spares the list by forwarding to himself instead of
releasing: rebuilt GnuPG on macOS to roughly match Homebrew with a
couple of small changes, done from Git and declaring itself
"2.1.20-beta14" and could still reproduce issue; backtrace in lldb, with
full variables via some Python lldb extension stuff I found online
reviewed/bugfixed.

-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 996 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170304/dfb65ede/attachment.sig>

From gnupg-devel at spodhuis.org  Sat Mar  4 23:02:06 2017
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Sat, 4 Mar 2017 17:02:06 -0500
Subject: assertion failure / key-locate local / macOS
In-Reply-To: <87k2851lbu.fsf@wheatstone.g10code.de>
References: <20170304061029.GA13739@breadbox.private.spodhuis.org>
 <87k2851lbu.fsf@wheatstone.g10code.de>
Message-ID: <20170304220205.GA17582@breadbox.private.spodhuis.org>

On 2017-03-04 at 09:45 +0100, Werner Koch wrote:
> >   % gpg --auto-key-locate dane --locate-keys phil.pennock at spodhuis.org
> >   gpg: Ohhhh jeeee: Assertion "uid->ref > 0" in free_user_id failed (free-packet.c:310)
> 
> Can you please run it also under gdb (or another debugger), set a
> breakpoint at _log_assert and when it gets hit produce a stack backtace
> ("bt full")?

Found/reviewed some Python to give lldb the same "full" functionality,
but no frame variables available in the binary.

Installed from git; gettext dep for autogen resolved by rsync'ing the
autogen result files from the Linux box.  Resulting build (details
below) failed only in the svg generation, but otherwise installs fine,
and declares itself to be "gpg (GnuPG) 2.1.20-beta14".

Typescript of debugging is attached.  The "gbt" command is, at its core,
from <http://idrisr.com/2016/05/29/Improving-LLDBs-Backtrace.html>.

-Phil

------------------------8< install log notes >8-------------------------

Built with:

  CFLAGS=-ggdb ./configure --prefix=$HOME/usr \
     --disable-nls --disable-ldap --enable-key-cache=16384 --enable-wks-tools \
     --with-pinentry-pgm=/usr/local/opt/pinentry/bin/pinentry-curses \
     --with-libgpg-error-prefix=/usr/local/opt/libgpg-error \
     --with-libassuan-prefix=/usr/local/opt/libassuan \
     --with-libgcrypt-prefix=/usr/local/opt/libgcrypt \
     --with-ksba-prefix=/usr/local/opt/libksba \
     --with-npth-prefix=/usr/local/opt/npth \
     --enable-symcryptrun

Configure warnings:

*** The config script /usr/local/opt/libgpg-error/bin/gpg-error-config was
*** built for x86_64-apple-darwin16.3.0 and thus may not match the
*** used host x86_64-apple-darwin16.4.0.
*** You may want to use the configure option --with-gpg-error-prefix
*** to specify a matching config script or use $SYSROOT.

*** The config script /usr/local/opt/libgcrypt/bin/libgcrypt-config was
*** built for x86_64-apple-darwin16.3.0 and thus may not match the
*** used host x86_64-apple-darwin16.4.0.
*** You may want to use the configure option --with-libgcrypt-prefix
*** to specify a matching config script or use $SYSROOT.

*** The config script /usr/local/opt/npth/bin/npth-config was
*** built for x86_64-apple-darwin16.0.0 and thus may not match the
*** used host x86_64-apple-darwin16.4.0.
*** You may want to use the configure option --with-npth-prefix
*** to specify a matching config script.

-------------- next part --------------
Script started on Sat Mar  4 16:58:57 2017
]2;pdp at tungsten.lan:~%                                                                                                                                   
 

[2]-pdp@tungsten.lan:s010[16:58]3D(1001)~% [?2004hlldb gpg2 -- --auto-key-locate dane --locate-keys phil.pennock at spodhuis.orglldb gpg2 -- --auto-key-locate dane --locate-keys phil.pennock@spodhuis.org[?2004l

(lldb) target create "gpg2"
Current executable set to 'gpg2' (x86_64).
(lldb) settings set -- target.run-args  "--auto-key-locate" "dane" "--locate-keys" "phil.pennock at spodhuis.org"
(lldb) (lldb) breakpoint set -n _log_assert
Breakpoint 1: where = gpg2`_log_assert + 35 at logging.c:1087, address = 0x00000001000d5973
(lldb) (lldb) run
Process 50844 launched: '/Users/pdp/usr/bin/gpg2' (x86_64)
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!

gpg: It is only intended for test purposes and should NOT be

gpg: used in a production environment or with production keys!

gpg: please do a --check-trustdb

Process 50844 stopped
* thread #1: tid = 0xd114f, 0x00000001000d5973 gpg2`_log_assert(expr="uid->ref > 0", file="free-packet.c", line=310, func="free_user_id") + 35 at logging.c:1087, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001000d5973 gpg2`_log_assert(expr="uid->ref > 0", file="free-packet.c", line=310, func="free_user_id") + 35 at logging.c:1087
   1084	_log_assert (const char *expr, const char *file, int line, const char *func)
   1085	{
   1086	  log_log (GPGRT_LOG_BUG, "Assertion \"%s\" in %s failed (%s:%d)\n",
-> 1087	           expr, func, file, line);
   1088	  abort (); /* Never called; just to make the compiler happy.  */
   1089	}
   1090	#else /*!GPGRT_HAVE_MACRO_FUNCTION*/
(lldb) (lldb) bt
* thread #1: tid = 0xd114f, 0x00000001000d5973 gpg2`_log_assert(expr="uid->ref > 0", file="free-packet.c", line=310, func="free_user_id") + 35 at logging.c:1087, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00000001000d5973 gpg2`_log_assert(expr="uid->ref > 0", file="free-packet.c", line=310, func="free_user_id") + 35 at logging.c:1087
    frame #1: 0x0000000100023afd gpg2`free_user_id(uid=0x00000001006194f0) + 77 at free-packet.c:310
    frame #2: 0x0000000100027457 gpg2`get_best_pubkey_byname(ctrl=0x00000001006003c0, retctx=0x00007fff5fbfe568, pk=0x0000000000000000, name="phil.pennock at spodhuis.org", ret_keyblock=0x00007fff5fbfe560, include_unusable=1, no_akl=0) + 423 at getkey.c:1612
    frame #3: 0x000000010005ce7e gpg2`locate_one(ctrl=0x00000001006003c0, names=0x0000000100600460) + 158 at keylist.c:650
    frame #4: 0x000000010005cd7e gpg2`public_key_list(ctrl=0x00000001006003c0, list=0x0000000100600460, locate_mode=1) + 686 at keylist.c:141
    frame #5: 0x0000000100005ccf gpg2`main(argc=0, argv=0x00007fff5fbfef50) + 20799 at gpg.c:4317
    frame #6: 0x00007fffc4011255 libdyld.dylib`start + 1
    frame #7: 0x00007fffc4011255 libdyld.dylib`start + 1
(lldb) (lldb) gbt
thread #1: tid = 0xd114f, 0x00000001000d5973 gpg2`_log_assert(expr="uid->ref > 0", file="free-packet.c", line=310, func="free_user_id") + 35 at logging.c:1087, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  frame #0: 0x00000001000d5973 gpg2`_log_assert(expr="uid->ref > 0", file="free-packet.c", line=310, func="free_user_id") + 35 at logging.c:1087
	(const char *) expr = 0x00000001000fe1c3 "uid->ref > 0"
	(const char *) file = 0x00000001000fe1a5 "free-packet.c"
	(int) line = 310
	(const char *) func = 0x00000001000fe1d0 "free_user_id"
	(estream_t) logstream = 0x0000000100600320
	(int) with_prefix = 1
	(int) with_pid = 0
	(int) running_detached = 0
	(int) force_prefixes = 0
	(int) missing_lf = 0
	(const char *(*)()) socket_dir_cb = 0x00000001000dc950 (gpg2`gnupg_socketdir at homedir.c:624)
	(int (*)(unsigned long *)) get_pid_suffix_cb = 0x0000000000000000
	(int) with_time = 0
	(char [80]) prefix_buffer = "gpg"
	(int) errorcount = 0
	(int) log_socket = 2
  frame #1: 0x0000000100023afd gpg2`free_user_id(uid=0x00000001006194f0) + 77 at free-packet.c:310
	(PKT_user_id *) uid = 0x00000001006194f0
	((anonymous struct)) glo_ctrl = (in_auto_key_retrieve = 0, lasterr = 0)
	((anonymous struct)) opt = {
  verbose = 0
  quiet = 0
  debug = 0
  armor = 0
  outfile = 0x0000000000000000
  outfp = 0x0000000000000000
  max_output = 0
  input_size_hint = 0
  dry_run = 0
  autostart = 1
  list_only = 0
  mimemode = 0
  textmode = 0
  expert = 0
  def_sig_expire = 0x00000001000f5f91 "0"
  ask_sig_expire = 0
  def_cert_expire = 0x00000001000f5f91 "0"
  ask_cert_expire = 0
  batch = 0
  answer_yes = 0
  answer_no = 0
  check_sigs = 0
  with_colons = 0
  with_key_data = 0
  with_icao_spelling = 0
  with_fingerprint = 0
  with_subkey_fingerprint = 0
  with_keygrip = 0
  with_tofu_info = 0
  with_secret = 0
  with_wkd_hash = 0
  fingerprint = 0
  list_sigs = 0
  no_armor = 0
  list_packets = 0
  def_cipher_algo = 0
  force_mdc = 0
  disable_mdc = 0
  def_digest_algo = 0
  cert_digest_algo = 0
  compress_algo = -1
  compress_level = -1
  bz2_compress_level = -1
  bz2_decompress_lowmem = 0
  def_secret_key = 0x0000000100600130
  def_recipient = 0x0000000000000000
  def_recipient_self = 1
  secret_keys_to_try = 0x0000000000000000
  sender_list = 0x0000000000000000
  def_cert_level = 0
  min_cert_level = 2
  ask_cert_level = 1
  emit_version = 0
  marginals_needed = 3
  completes_needed = 1
  max_cert_depth = 5
  agent_program = 0x0000000000000000
  dirmngr_program = 0x0000000000000000
  def_new_key_algo = 0x0000000000000000
  session_env = 0x00000001004024d0
  lc_ctype = 0x0000000000000000
  lc_messages = 0x0000000000000000
  skip_verify = 0
  skip_hidden_recipients = 0
  trust_model = TM_PGP
  tofu_default_policy = TOFU_POLICY_AUTO
  force_ownertrust = 0
  compliance = CO_GNUPG
  keyid_format = KF_NONE
  shm_coprocess = 0
  set_filename = 0x0000000000000000
  comments = 0x0000000000000000
  throw_keyids = 0
  photo_viewer = 0x0000000000000000
  s2k_mode = 3
  s2k_digest_algo = 0
  s2k_cipher_algo = 7
  s2k_count = '\0'
  not_dash_escaped = 0
  escape_from = 1
  lock_once = 1
  keyserver = 0x00000001006001e0
  keyserver_options = (options = 32, import_options = 2, export_options = 2, http_proxy = 0x0000000000000000)
  exec_disable = 0
  exec_path_set = 0
  import_options = 0
  export_options = 2
  list_options = 2614
  verify_options = 62
  def_preference_list = 0x00000001006000b0 "SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES BZIP2 ZLIB ZIP"
  def_keyserver_url = 0x00000001006001b0 "hkp://ha.pool.sks-keyservers.net/"
  personal_cipher_prefs = 0x0000000000000000
  personal_digest_prefs = 0x0000000100600380
  personal_compress_prefs = 0x0000000000000000
  weak_digests = 0x0000000100402550
  no_perm_warn = 0
  no_mdc_warn = 0
  temp_dir = 0x0000000000000000
  no_encrypt_to = 0
  encrypt_to_default_key = 0
  interactive = 0
  sig_notations = 0x0000000000000000
  cert_notations = 0x0000000000000000
  sig_policy_url = 0x0000000000000000
  cert_policy_url = 0x0000000000000000
  sig_keyserver_url = 0x0000000000000000
  cert_subpackets = 0x0000000000000000
  sig_subpackets = 0x0000000000000000
  allow_non_selfsigned_uid = 0
  allow_freeform_uid = 0
  no_literal = 0
  set_filesize = 0
  fast_list_mode = 0
  legacy_list_mode = 0
  ignore_time_conflict = 0
  ignore_valid_from = 0
  ignore_crc_error = 0
  ignore_mdc_error = 0
  command_fd = -1
  override_session_key = 0x0000000000000000
  show_session_key = 0
  gpg_agent_info = 0x0000000000000000
  try_all_secrets = 0
  no_expensive_trust_checks = 0
  no_sig_cache = 0
  no_auto_check_trustdb = 1
  preserve_permissions = 0
  no_homedir_creation = 0
  grouplist = 0x0000000000000000
  mangle_dos_filenames = 0
  enable_progress_filter = 0
  screen_columns = 80
  screen_lines = 24
  show_subpackets = 0x0000000000000000
  rfc2440_text = 0
  exit_on_status_write_error = 0
  limit_card_insert_tries = 0
  flags = {
    require_cross_cert = 1
    use_embedded_filename = 0
    utf8_filename = 1
    dsa2 = 0
    allow_multiple_messages = 0
    allow_weak_digest_algos = 0
    large_rsa = 0
    disable_signer_uid = 0
    rfc4880bis = 0
  }
  auto_key_locate = 0x0000000100600250
  passphrase_repeat = 1
  pinentry_mode = 0
  unwrap_encryption = 0
  only_sign_text_ids = 0
}
	(int) iobuf_debug_mode = 0
	(int) memory_stat_debug_mode = 0
	(int) memory_debug_mode = 0
  frame #2: 0x0000000100027457 gpg2`get_best_pubkey_byname(ctrl=0x00000001006003c0, retctx=0x00007fff5fbfe568, pk=0x0000000000000000, name="phil.pennock at spodhuis.org", ret_keyblock=0x00007fff5fbfe560, include_unusable=1, no_akl=0) + 423 at getkey.c:1612
	(ctrl_t) ctrl = 0x00000001006003c0
	(GETKEY_CTX *) retctx = 0x00007fff5fbfe568
	(PKT_public_key *) pk = 0x0000000000000000
	(const char *) name = 0x000000010060046c "phil.pennock at spodhuis.org"
	(KBNODE *) ret_keyblock = 0x00007fff5fbfe560
	(int) include_unusable = 1
	(int) no_akl = 0
	(int) rc = 0
	(getkey_ctx_s *) ctx = 0x0000000100600570
	(pubkey_cmp_cookie) best = {
  valid = 1
  key = {
    timestamp = 1382417802
    expiredate = 0
    max_expiredate = 0
    revoked = {
      date = 0
      keyid = ([0] = 0, [1] = 0)
      algo = '\0'
    }
    hdrbytes = '\x03'
    version = '\x04'
    selfsigversion = '\x04'
    pubkey_algo = '\x01'
    pubkey_usage = '\x05'
    req_usage = '\0'
    has_expired = 0
    main_keyid = ([0] = 1293848590, [1] = 348244996)
    keyid = ([0] = 1293848590, [1] = 348244996)
    prefs = 0x0000000100515a20
    flags = {
      mdc = 1
      disabled_valid = 1
      disabled = 0
      primary = 1
      revoked = 0
      maybe_revoked = 0
      valid = 1
      dont_cache = 0
      backsig = 0
      serialno_valid = 0
      exact = 0
    }
    user_id = 0x000000010061c360
    revkey = 0x0000000000000000
    numrevkeys = 0
    trust_timestamp = 0
    trust_depth = '\0'
    trust_value = '\0'
    trust_regexp = 0x0000000000000000
    serialno = 0x0000000000000000
    seckey_info = 0x0000000000000000
    pkey = ([0] = 0x00000001005158c0, [1] = 0x00000001005156b0, [2] = 0x0000000000000000, [3] = 0x0000000000000000, [4] = 0x0000000000000000, [5] = 0x0000000000000000, [6] = 0x0000000000000000)
  }
  uid = 0x000000010061c360
  validity = 6
  creation_time = 1472278988
}
	(pubkey_cmp_cookie) new = {
  valid = 1
  key = {
    timestamp = 1472694340
    expiredate = 0
    max_expiredate = 0
    revoked = {
      date = 0
      keyid = ([0] = 0, [1] = 0)
      algo = '\0'
    }
    hdrbytes = '\x03'
    version = '\x04'
    selfsigversion = '\x04'
    pubkey_algo = '\x01'
    pubkey_usage = '\x05'
    req_usage = '\0'
    has_expired = 0
    main_keyid = ([0] = 3932611014, [1] = 1016984634)
    keyid = ([0] = 3932611014, [1] = 1016984634)
    prefs = 0x0000000000000000
    flags = {
      mdc = 1
      disabled_valid = 0
      disabled = 0
      primary = 1
      revoked = 0
      maybe_revoked = 0
      valid = 1
      dont_cache = 0
      backsig = 0
      serialno_valid = 0
      exact = 0
    }
    user_id = 0x0000000000000000
    revkey = 0x0000000000000000
    numrevkeys = 0
    trust_timestamp = 0
    trust_depth = '\0'
    trust_value = '\0'
    trust_regexp = 0x0000000000000000
    serialno = 0x0000000000000000
    seckey_info = 0x0000000000000000
    pkey = ([0] = 0x0000000000000000, [1] = 0x0000000000000000, [2] = 0x0000000000000000, [3] = 0x0000000000000000, [4] = 0x0000000000000000, [5] = 0x0000000000000000, [6] = 0x0000000000000000)
  }
  uid = 0x00000001006194f0
  validity = 1
  creation_time = 1472694340
}
	(KBNODE) new_keyblock = 0x000000010063ccc0
	(int) diff = 1
	((anonymous struct)) glo_ctrl = (in_auto_key_retrieve = 0, lasterr = 0)
	(int) pk_cache_entries = 0
	((anonymous struct)) opt = {
  verbose = 0
  quiet = 0
  debug = 0
  armor = 0
  outfile = 0x0000000000000000
  outfp = 0x0000000000000000
  max_output = 0
  input_size_hint = 0
  dry_run = 0
  autostart = 1
  list_only = 0
  mimemode = 0
  textmode = 0
  expert = 0
  def_sig_expire = 0x00000001000f5f91 "0"
  ask_sig_expire = 0
  def_cert_expire = 0x00000001000f5f91 "0"
  ask_cert_expire = 0
  batch = 0
  answer_yes = 0
  answer_no = 0
  check_sigs = 0
  with_colons = 0
  with_key_data = 0
  with_icao_spelling = 0
  with_fingerprint = 0
  with_subkey_fingerprint = 0
  with_keygrip = 0
  with_tofu_info = 0
  with_secret = 0
  with_wkd_hash = 0
  fingerprint = 0
  list_sigs = 0
  no_armor = 0
  list_packets = 0
  def_cipher_algo = 0
  force_mdc = 0
  disable_mdc = 0
  def_digest_algo = 0
  cert_digest_algo = 0
  compress_algo = -1
  compress_level = -1
  bz2_compress_level = -1
  bz2_decompress_lowmem = 0
  def_secret_key = 0x0000000100600130
  def_recipient = 0x0000000000000000
  def_recipient_self = 1
  secret_keys_to_try = 0x0000000000000000
  sender_list = 0x0000000000000000
  def_cert_level = 0
  min_cert_level = 2
  ask_cert_level = 1
  emit_version = 0
  marginals_needed = 3
  completes_needed = 1
  max_cert_depth = 5
  agent_program = 0x0000000000000000
  dirmngr_program = 0x0000000000000000
  def_new_key_algo = 0x0000000000000000
  session_env = 0x00000001004024d0
  lc_ctype = 0x0000000000000000
  lc_messages = 0x0000000000000000
  skip_verify = 0
  skip_hidden_recipients = 0
  trust_model = TM_PGP
  tofu_default_policy = TOFU_POLICY_AUTO
  force_ownertrust = 0
  compliance = CO_GNUPG
  keyid_format = KF_NONE
  shm_coprocess = 0
  set_filename = 0x0000000000000000
  comments = 0x0000000000000000
  throw_keyids = 0
  photo_viewer = 0x0000000000000000
  s2k_mode = 3
  s2k_digest_algo = 0
  s2k_cipher_algo = 7
  s2k_count = '\0'
  not_dash_escaped = 0
  escape_from = 1
  lock_once = 1
  keyserver = 0x00000001006001e0
  keyserver_options = (options = 32, import_options = 2, export_options = 2, http_proxy = 0x0000000000000000)
  exec_disable = 0
  exec_path_set = 0
  import_options = 0
  export_options = 2
  list_options = 2614
  verify_options = 62
  def_preference_list = 0x00000001006000b0 "SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES BZIP2 ZLIB ZIP"
  def_keyserver_url = 0x00000001006001b0 "hkp://ha.pool.sks-keyservers.net/"
  personal_cipher_prefs = 0x0000000000000000
  personal_digest_prefs = 0x0000000100600380
  personal_compress_prefs = 0x0000000000000000
  weak_digests = 0x0000000100402550
  no_perm_warn = 0
  no_mdc_warn = 0
  temp_dir = 0x0000000000000000
  no_encrypt_to = 0
  encrypt_to_default_key = 0
  interactive = 0
  sig_notations = 0x0000000000000000
  cert_notations = 0x0000000000000000
  sig_policy_url = 0x0000000000000000
  cert_policy_url = 0x0000000000000000
  sig_keyserver_url = 0x0000000000000000
  cert_subpackets = 0x0000000000000000
  sig_subpackets = 0x0000000000000000
  allow_non_selfsigned_uid = 0
  allow_freeform_uid = 0
  no_literal = 0
  set_filesize = 0
  fast_list_mode = 0
  legacy_list_mode = 0
  ignore_time_conflict = 0
  ignore_valid_from = 0
  ignore_crc_error = 0
  ignore_mdc_error = 0
  command_fd = -1
  override_session_key = 0x0000000000000000
  show_session_key = 0
  gpg_agent_info = 0x0000000000000000
  try_all_secrets = 0
  no_expensive_trust_checks = 0
  no_sig_cache = 0
  no_auto_check_trustdb = 1
  preserve_permissions = 0
  no_homedir_creation = 0
  grouplist = 0x0000000000000000
  mangle_dos_filenames = 0
  enable_progress_filter = 0
  screen_columns = 80
  screen_lines = 24
  show_subpackets = 0x0000000000000000
  rfc2440_text = 0
  exit_on_status_write_error = 0
  limit_card_insert_tries = 0
  flags = {
    require_cross_cert = 1
    use_embedded_filename = 0
    utf8_filename = 1
    dsa2 = 0
    allow_multiple_messages = 0
    allow_weak_digest_algos = 0
    large_rsa = 0
    disable_signer_uid = 0
    rfc4880bis = 0
  }
  auto_key_locate = 0x0000000100600250
  passphrase_repeat = 1
  pinentry_mode = 0
  unwrap_encryption = 0
  only_sign_text_ids = 0
}
	(int) iobuf_debug_mode = 0
	(user_id_db_t) user_id_db = 0x0000000100403b00
	(int) memory_stat_debug_mode = 0
	(int) uid_cache_entries = 5
	(int) memory_debug_mode = 0
	(pk_cache_entry_t) pk_cache = 0x0000000000000000
	(int) pk_cache_disabled = 0
  frame #3: 0x000000010005ce7e gpg2`locate_one(ctrl=0x00000001006003c0, names=0x0000000100600460) + 158 at keylist.c:650
	(ctrl_t) ctrl = 0x00000001006003c0
	(strlist_t) names = 0x0000000100600460
	(int) rc = 0
	(strlist_t) sl = 0x0000000100600460
	(GETKEY_CTX) ctx = 0x0000000000000000
	(KBNODE) keyblock = 0x0000000100600b20
	(keylist_context) listctx = {
  check_sigs = 0
  good_sigs = 0
  inv_sigs = 0
  no_key = 0
  oth_err = 0
  no_validity = 0
}
	((anonymous struct)) glo_ctrl = (in_auto_key_retrieve = 0, lasterr = 0)
	((anonymous struct)) opt = {
  verbose = 0
  quiet = 0
  debug = 0
  armor = 0
  outfile = 0x0000000000000000
  outfp = 0x0000000000000000
  max_output = 0
  input_size_hint = 0
  dry_run = 0
  autostart = 1
  list_only = 0
  mimemode = 0
  textmode = 0
  expert = 0
  def_sig_expire = 0x00000001000f5f91 "0"
  ask_sig_expire = 0
  def_cert_expire = 0x00000001000f5f91 "0"
  ask_cert_expire = 0
  batch = 0
  answer_yes = 0
  answer_no = 0
  check_sigs = 0
  with_colons = 0
  with_key_data = 0
  with_icao_spelling = 0
  with_fingerprint = 0
  with_subkey_fingerprint = 0
  with_keygrip = 0
  with_tofu_info = 0
  with_secret = 0
  with_wkd_hash = 0
  fingerprint = 0
  list_sigs = 0
  no_armor = 0
  list_packets = 0
  def_cipher_algo = 0
  force_mdc = 0
  disable_mdc = 0
  def_digest_algo = 0
  cert_digest_algo = 0
  compress_algo = -1
  compress_level = -1
  bz2_compress_level = -1
  bz2_decompress_lowmem = 0
  def_secret_key = 0x0000000100600130
  def_recipient = 0x0000000000000000
  def_recipient_self = 1
  secret_keys_to_try = 0x0000000000000000
  sender_list = 0x0000000000000000
  def_cert_level = 0
  min_cert_level = 2
  ask_cert_level = 1
  emit_version = 0
  marginals_needed = 3
  completes_needed = 1
  max_cert_depth = 5
  agent_program = 0x0000000000000000
  dirmngr_program = 0x0000000000000000
  def_new_key_algo = 0x0000000000000000
  session_env = 0x00000001004024d0
  lc_ctype = 0x0000000000000000
  lc_messages = 0x0000000000000000
  skip_verify = 0
  skip_hidden_recipients = 0
  trust_model = TM_PGP
  tofu_default_policy = TOFU_POLICY_AUTO
  force_ownertrust = 0
  compliance = CO_GNUPG
  keyid_format = KF_NONE
  shm_coprocess = 0
  set_filename = 0x0000000000000000
  comments = 0x0000000000000000
  throw_keyids = 0
  photo_viewer = 0x0000000000000000
  s2k_mode = 3
  s2k_digest_algo = 0
  s2k_cipher_algo = 7
  s2k_count = '\0'
  not_dash_escaped = 0
  escape_from = 1
  lock_once = 1
  keyserver = 0x00000001006001e0
  keyserver_options = (options = 32, import_options = 2, export_options = 2, http_proxy = 0x0000000000000000)
  exec_disable = 0
  exec_path_set = 0
  import_options = 0
  export_options = 2
  list_options = 2614
  verify_options = 62
  def_preference_list = 0x00000001006000b0 "SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES BZIP2 ZLIB ZIP"
  def_keyserver_url = 0x00000001006001b0 "hkp://ha.pool.sks-keyservers.net/"
  personal_cipher_prefs = 0x0000000000000000
  personal_digest_prefs = 0x0000000100600380
  personal_compress_prefs = 0x0000000000000000
  weak_digests = 0x0000000100402550
  no_perm_warn = 0
  no_mdc_warn = 0
  temp_dir = 0x0000000000000000
  no_encrypt_to = 0
  encrypt_to_default_key = 0
  interactive = 0
  sig_notations = 0x0000000000000000
  cert_notations = 0x0000000000000000
  sig_policy_url = 0x0000000000000000
  cert_policy_url = 0x0000000000000000
  sig_keyserver_url = 0x0000000000000000
  cert_subpackets = 0x0000000000000000
  sig_subpackets = 0x0000000000000000
  allow_non_selfsigned_uid = 0
  allow_freeform_uid = 0
  no_literal = 0
  set_filesize = 0
  fast_list_mode = 0
  legacy_list_mode = 0
  ignore_time_conflict = 0
  ignore_valid_from = 0
  ignore_crc_error = 0
  ignore_mdc_error = 0
  command_fd = -1
  override_session_key = 0x0000000000000000
  show_session_key = 0
  gpg_agent_info = 0x0000000000000000
  try_all_secrets = 0
  no_expensive_trust_checks = 0
  no_sig_cache = 0
  no_auto_check_trustdb = 1
  preserve_permissions = 0
  no_homedir_creation = 0
  grouplist = 0x0000000000000000
  mangle_dos_filenames = 0
  enable_progress_filter = 0
  screen_columns = 80
  screen_lines = 24
  show_subpackets = 0x0000000000000000
  rfc2440_text = 0
  exit_on_status_write_error = 0
  limit_card_insert_tries = 0
  flags = {
    require_cross_cert = 1
    use_embedded_filename = 0
    utf8_filename = 1
    dsa2 = 0
    allow_multiple_messages = 0
    allow_weak_digest_algos = 0
    large_rsa = 0
    disable_signer_uid = 0
    rfc4880bis = 0
  }
  auto_key_locate = 0x0000000100600250
  passphrase_repeat = 1
  pinentry_mode = 0
  unwrap_encryption = 0
  only_sign_text_ids = 0
}
	(int) iobuf_debug_mode = 0
	(int) memory_stat_debug_mode = 0
	(estream_t) attrib_fp = 0x0000000000000000
	(int) memory_debug_mode = 0
  frame #4: 0x000000010005cd7e gpg2`public_key_list(ctrl=0x00000001006003c0, list=0x0000000100600460, locate_mode=1) + 686 at keylist.c:141
	(ctrl_t) ctrl = 0x00000001006003c0
	(strlist_t) list = 0x0000000100600460
	(int) locate_mode = 1
	((anonymous struct)) glo_ctrl = (in_auto_key_retrieve = 0, lasterr = 0)
	((anonymous struct)) opt = {
  verbose = 0
  quiet = 0
  debug = 0
  armor = 0
  outfile = 0x0000000000000000
  outfp = 0x0000000000000000
  max_output = 0
  input_size_hint = 0
  dry_run = 0
  autostart = 1
  list_only = 0
  mimemode = 0
  textmode = 0
  expert = 0
  def_sig_expire = 0x00000001000f5f91 "0"
  ask_sig_expire = 0
  def_cert_expire = 0x00000001000f5f91 "0"
  ask_cert_expire = 0
  batch = 0
  answer_yes = 0
  answer_no = 0
  check_sigs = 0
  with_colons = 0
  with_key_data = 0
  with_icao_spelling = 0
  with_fingerprint = 0
  with_subkey_fingerprint = 0
  with_keygrip = 0
  with_tofu_info = 0
  with_secret = 0
  with_wkd_hash = 0
  fingerprint = 0
  list_sigs = 0
  no_armor = 0
  list_packets = 0
  def_cipher_algo = 0
  force_mdc = 0
  disable_mdc = 0
  def_digest_algo = 0
  cert_digest_algo = 0
  compress_algo = -1
  compress_level = -1
  bz2_compress_level = -1
  bz2_decompress_lowmem = 0
  def_secret_key = 0x0000000100600130
  def_recipient = 0x0000000000000000
  def_recipient_self = 1
  secret_keys_to_try = 0x0000000000000000
  sender_list = 0x0000000000000000
  def_cert_level = 0
  min_cert_level = 2
  ask_cert_level = 1
  emit_version = 0
  marginals_needed = 3
  completes_needed = 1
  max_cert_depth = 5
  agent_program = 0x0000000000000000
  dirmngr_program = 0x0000000000000000
  def_new_key_algo = 0x0000000000000000
  session_env = 0x00000001004024d0
  lc_ctype = 0x0000000000000000
  lc_messages = 0x0000000000000000
  skip_verify = 0
  skip_hidden_recipients = 0
  trust_model = TM_PGP
  tofu_default_policy = TOFU_POLICY_AUTO
  force_ownertrust = 0
  compliance = CO_GNUPG
  keyid_format = KF_NONE
  shm_coprocess = 0
  set_filename = 0x0000000000000000
  comments = 0x0000000000000000
  throw_keyids = 0
  photo_viewer = 0x0000000000000000
  s2k_mode = 3
  s2k_digest_algo = 0
  s2k_cipher_algo = 7
  s2k_count = '\0'
  not_dash_escaped = 0
  escape_from = 1
  lock_once = 1
  keyserver = 0x00000001006001e0
  keyserver_options = (options = 32, import_options = 2, export_options = 2, http_proxy = 0x0000000000000000)
  exec_disable = 0
  exec_path_set = 0
  import_options = 0
  export_options = 2
  list_options = 2614
  verify_options = 62
  def_preference_list = 0x00000001006000b0 "SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES BZIP2 ZLIB ZIP"
  def_keyserver_url = 0x00000001006001b0 "hkp://ha.pool.sks-keyservers.net/"
  personal_cipher_prefs = 0x0000000000000000
  personal_digest_prefs = 0x0000000100600380
  personal_compress_prefs = 0x0000000000000000
  weak_digests = 0x0000000100402550
  no_perm_warn = 0
  no_mdc_warn = 0
  temp_dir = 0x0000000000000000
  no_encrypt_to = 0
  encrypt_to_default_key = 0
  interactive = 0
  sig_notations = 0x0000000000000000
  cert_notations = 0x0000000000000000
  sig_policy_url = 0x0000000000000000
  cert_policy_url = 0x0000000000000000
  sig_keyserver_url = 0x0000000000000000
  cert_subpackets = 0x0000000000000000
  sig_subpackets = 0x0000000000000000
  allow_non_selfsigned_uid = 0
  allow_freeform_uid = 0
  no_literal = 0
  set_filesize = 0
  fast_list_mode = 0
  legacy_list_mode = 0
  ignore_time_conflict = 0
  ignore_valid_from = 0
  ignore_crc_error = 0
  ignore_mdc_error = 0
  command_fd = -1
  override_session_key = 0x0000000000000000
  show_session_key = 0
  gpg_agent_info = 0x0000000000000000
  try_all_secrets = 0
  no_expensive_trust_checks = 0
  no_sig_cache = 0
  no_auto_check_trustdb = 1
  preserve_permissions = 0
  no_homedir_creation = 0
  grouplist = 0x0000000000000000
  mangle_dos_filenames = 0
  enable_progress_filter = 0
  screen_columns = 80
  screen_lines = 24
  show_subpackets = 0x0000000000000000
  rfc2440_text = 0
  exit_on_status_write_error = 0
  limit_card_insert_tries = 0
  flags = {
    require_cross_cert = 1
    use_embedded_filename = 0
    utf8_filename = 1
    dsa2 = 0
    allow_multiple_messages = 0
    allow_weak_digest_algos = 0
    large_rsa = 0
    disable_signer_uid = 0
    rfc4880bis = 0
  }
  auto_key_locate = 0x0000000100600250
  passphrase_repeat = 1
  pinentry_mode = 0
  unwrap_encryption = 0
  only_sign_text_ids = 0
}
	(int) iobuf_debug_mode = 0
	(int) memory_stat_debug_mode = 0
	(estream_t) attrib_fp = 0x0000000000000000
	(int) memory_debug_mode = 0
  frame #5: 0x0000000100005ccf gpg2`main(argc=0, argv=0x00007fff5fbfef50) + 20799 at gpg.c:4317
	(int) print_dane_records = 0
	(int) print_pka_records = 0
	(int) argc = 0
	(char **) argv = 0x00007fff5fbfef50
	(ARGPARSE_ARGS) pargs = {
  argc = 0x00007fff5fbfeef8
  argv = 0x00007fff5fbfeef0
  flags = 32769
  err = 0
  r_opt = 0
  r_type = 0
  r = (ret_int = 0, ret_long = 0, ret_ulong = 0, ret_str = 0x0000000000000000)
  internal = (idx = 4, inarg = 0, stopped = 1, last = "phil.pennock at spodhuis.org", aliases = 0x0000000000000000, cur_alias = 0x0000000000000000, iio_list = 0x0000000000000000)
}
	(IOBUF) a = 0x00007fff5fbfef10
	(int) rc = 0
	(int) orig_argc = 5
	(char **) orig_argv = 0x00007fff5fbfef28
	(const char *) fname = 0x00007fff5fbff1f2 "phil.pennock at spodhuis.org"
	(char *) username = 0x00007fff5fbfef58 "\f?_?\x7f"
	(int) may_coredump = 0
	(strlist_t) sl = 0x0000000100600460
	(strlist_t) remusr = 0x0000000100600180
	(strlist_t) locusr = 0x0000000000000000
	(strlist_t) nrings = 0x0000000000000000
	(armor_filter_context_t *) afx = 0x0000000000000000
	(int) detached_sig = 0
	(FILE *) configfp = 0x0000000000000000
	(char *) configname = 0x0000000000000000
	(char *) save_configname = 0x00000001004022b0 "@"
	(char *) default_configname = 0x0000000100402560 "@"
	(unsigned int) configlineno = 44
	(int) parse_debug = 0
	(int) default_config = 0
	(int) default_keyring = 1
	(int) greeting = 0
	(int) nogreeting = 1
	(char *) logfile = 0x0000000000000000
	(int) use_random_seed = 1
	(cmd_and_opt_values) cmd = aLocateKeys
	(const char *) debug_level = 0x0000000000000000
	(const char *) trustdb_name = 0x0000000000000000
	(char *) def_cipher_string = 0x0000000000000000
	(char *) def_digest_string = 0x0000000000000000
	(char *) compress_algo_string = 0x0000000000000000
	(char *) cert_digest_string = 0x0000000000000000
	(char *) s2k_cipher_string = 0x0000000000000000
	(char *) s2k_digest_string = 0x0000000000000000
	(char *) pers_cipher_list = 0x0000000000000000
	(char *) pers_digest_list = 0x00000001006000f0 "SHA256 SHA512 SHA384 SHA1"
	(char *) pers_compress_list = 0x0000000000000000
	(int) eyes_only = 0
	(int) multifile = 0
	(int) pwfd = -1
	(int) ovrseskeyfd = -1
	(int) fpr_maybe_cmd = 0
	(int) any_explicit_recipient = 0
	(int) require_secmem = 0
	(int) got_secmem = 1
	(assuan_malloc_hooks) malloc_hooks = {
  malloc = 0x00000001001f9f40 (libgcrypt.20.dylib`gcry_malloc)
  realloc = 0x00000001001f9f80 (libgcrypt.20.dylib`gcry_realloc)
  free = 0x00000001001fa000 (libgcrypt.20.dylib`gcry_free)
}
	(ctrl_t) ctrl = 0x00000001006003c0
	(debug_flags_s [15]) debug_flags = {
  [0] = (flag = 1, name = "packet")
  [1] = (flag = 2, name = "mpi")
  [2] = (flag = 4, name = "crypto")
  [3] = (flag = 8, name = "filter")
  [4] = (flag = 16, name = "iobuf")
  [5] = (flag = 32, name = "memory")
  [6] = (flag = 64, name = "cache")
  [7] = (flag = 128, name = "memstat")
  [8] = (flag = 256, name = "trust")
  [9] = (flag = 512, name = "hashing")
  [10] = (flag = 1024, name = "ipc")
  [11] = (flag = 4096, name = "clock")
  [12] = (flag = 8192, name = "lookup")
  [13] = (flag = 16384, name = "extprog")
  [14] = (flag = 0, name = 0x0000000000000000)
}
	(int) g10_errors_seen = 0
	(int) utf8_strings = 1
	(int) maybe_setuid = 0
	((anonymous struct)) glo_ctrl = (in_auto_key_retrieve = 0, lasterr = 0)
	((anonymous struct)) opt = {
  verbose = 0
  quiet = 0
  debug = 0
  armor = 0
  outfile = 0x0000000000000000
  outfp = 0x0000000000000000
  max_output = 0
  input_size_hint = 0
  dry_run = 0
  autostart = 1
  list_only = 0
  mimemode = 0
  textmode = 0
  expert = 0
  def_sig_expire = 0x00000001000f5f91 "0"
  ask_sig_expire = 0
  def_cert_expire = 0x00000001000f5f91 "0"
  ask_cert_expire = 0
  batch = 0
  answer_yes = 0
  answer_no = 0
  check_sigs = 0
  with_colons = 0
  with_key_data = 0
  with_icao_spelling = 0
  with_fingerprint = 0
  with_subkey_fingerprint = 0
  with_keygrip = 0
  with_tofu_info = 0
  with_secret = 0
  with_wkd_hash = 0
  fingerprint = 0
  list_sigs = 0
  no_armor = 0
  list_packets = 0
  def_cipher_algo = 0
  force_mdc = 0
  disable_mdc = 0
  def_digest_algo = 0
  cert_digest_algo = 0
  compress_algo = -1
  compress_level = -1
  bz2_compress_level = -1
  bz2_decompress_lowmem = 0
  def_secret_key = 0x0000000100600130
  def_recipient = 0x0000000000000000
  def_recipient_self = 1
  secret_keys_to_try = 0x0000000000000000
  sender_list = 0x0000000000000000
  def_cert_level = 0
  min_cert_level = 2
  ask_cert_level = 1
  emit_version = 0
  marginals_needed = 3
  completes_needed = 1
  max_cert_depth = 5
  agent_program = 0x0000000000000000
  dirmngr_program = 0x0000000000000000
  def_new_key_algo = 0x0000000000000000
  session_env = 0x00000001004024d0
  lc_ctype = 0x0000000000000000
  lc_messages = 0x0000000000000000
  skip_verify = 0
  skip_hidden_recipients = 0
  trust_model = TM_PGP
  tofu_default_policy = TOFU_POLICY_AUTO
  force_ownertrust = 0
  compliance = CO_GNUPG
  keyid_format = KF_NONE
  shm_coprocess = 0
  set_filename = 0x0000000000000000
  comments = 0x0000000000000000
  throw_keyids = 0
  photo_viewer = 0x0000000000000000
  s2k_mode = 3
  s2k_digest_algo = 0
  s2k_cipher_algo = 7
  s2k_count = '\0'
  not_dash_escaped = 0
  escape_from = 1
  lock_once = 1
  keyserver = 0x00000001006001e0
  keyserver_options = (options = 32, import_options = 2, export_options = 2, http_proxy = 0x0000000000000000)
  exec_disable = 0
  exec_path_set = 0
  import_options = 0
  export_options = 2
  list_options = 2614
  verify_options = 62
  def_preference_list = 0x00000001006000b0 "SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES BZIP2 ZLIB ZIP"
  def_keyserver_url = 0x00000001006001b0 "hkp://ha.pool.sks-keyservers.net/"
  personal_cipher_prefs = 0x0000000000000000
  personal_digest_prefs = 0x0000000100600380
  personal_compress_prefs = 0x0000000000000000
  weak_digests = 0x0000000100402550
  no_perm_warn = 0
  no_mdc_warn = 0
  temp_dir = 0x0000000000000000
  no_encrypt_to = 0
  encrypt_to_default_key = 0
  interactive = 0
  sig_notations = 0x0000000000000000
  cert_notations = 0x0000000000000000
  sig_policy_url = 0x0000000000000000
  cert_policy_url = 0x0000000000000000
  sig_keyserver_url = 0x0000000000000000
  cert_subpackets = 0x0000000000000000
  sig_subpackets = 0x0000000000000000
  allow_non_selfsigned_uid = 0
  allow_freeform_uid = 0
  no_literal = 0
  set_filesize = 0
  fast_list_mode = 0
  legacy_list_mode = 0
  ignore_time_conflict = 0
  ignore_valid_from = 0
  ignore_crc_error = 0
  ignore_mdc_error = 0
  command_fd = -1
  override_session_key = 0x0000000000000000
  show_session_key = 0
  gpg_agent_info = 0x0000000000000000
  try_all_secrets = 0
  no_expensive_trust_checks = 0
  no_sig_cache = 0
  no_auto_check_trustdb = 1
  preserve_permissions = 0
  no_homedir_creation = 0
  grouplist = 0x0000000000000000
  mangle_dos_filenames = 0
  enable_progress_filter = 0
  screen_columns = 80
  screen_lines = 24
  show_subpackets = 0x0000000000000000
  rfc2440_text = 0
  exit_on_status_write_error = 0
  limit_card_insert_tries = 0
  flags = {
    require_cross_cert = 1
    use_embedded_filename = 0
    utf8_filename = 1
    dsa2 = 0
    allow_multiple_messages = 0
    allow_weak_digest_algos = 0
    large_rsa = 0
    disable_signer_uid = 0
    rfc4880bis = 0
  }
  auto_key_locate = 0x0000000100600250
  passphrase_repeat = 1
  pinentry_mode = 0
  unwrap_encryption = 0
  only_sign_text_ids = 0
}
	(int) iobuf_debug_mode = 0
	(int) memory_stat_debug_mode = 0
	(int) memory_debug_mode = 0
	(ARGPARSE_OPTS [384]) opts = {
  [0] = (short_opt = 300, long_opt = 0x0000000000000000, flags = 0, description = "@Commands:\n ")
  [1] = (short_opt = 115, long_opt = "sign", flags = 128, description = "make a signature")
  [2] = (short_opt = 510, long_opt = "clear-sign", flags = 128, description = "make a clear text signature")
  [3] = (short_opt = 510, long_opt = "clearsign", flags = 128, description = "@")
  [4] = (short_opt = 98, long_opt = "detach-sign", flags = 128, description = "make a detached signature")
  [5] = (short_opt = 101, long_opt = "encrypt", flags = 128, description = "encrypt data")
  [6] = (short_opt = 507, long_opt = "encrypt-files", flags = 128, description = "@")
  [7] = (short_opt = 99, long_opt = "symmetric", flags = 128, description = "encryption only with symmetric cipher")
  [8] = (short_opt = 511, long_opt = "store", flags = 128, description = "@")
  [9] = (short_opt = 100, long_opt = "decrypt", flags = 128, description = "decrypt data (default)")
  [10] = (short_opt = 509, long_opt = "decrypt-files", flags = 128, description = "@")
  [11] = (short_opt = 537, long_opt = "verify", flags = 128, description = "verify a signature")
  [12] = (short_opt = 538, long_opt = "verify-files", flags = 128, description = "@")
  [13] = (short_opt = 107, long_opt = "list-keys", flags = 128, description = "list keys")
  [14] = (short_opt = 107, long_opt = "list-public-keys", flags = 128, description = "@")
  [15] = (short_opt = 539, long_opt = "list-signatures", flags = 128, description = "list keys and signatures")
  [16] = (short_opt = 539, long_opt = "list-sigs", flags = 128, description = "@")
  [17] = (short_opt = 550, long_opt = "check-signatures", flags = 128, description = "list and check key signatures")
  [18] = (short_opt = 550, long_opt = "check-sigs", flags = 128, description = "@")
  [19] = (short_opt = 588, long_opt = "fingerprint", flags = 128, description = "list keys and fingerprints")
  [20] = (short_opt = 75, long_opt = "list-secret-keys", flags = 128, description = "list secret keys")
  [21] = (short_opt = 514, long_opt = "generate-key", flags = 128, description = "generate a new key pair")
  [22] = (short_opt = 514, long_opt = "gen-key", flags = 128, description = "@")
  [23] = (short_opt = 512, long_opt = "quick-generate-key", flags = 128, description = "quickly generate a new key pair")
  [24] = (short_opt = 512, long_opt = "quick-gen-key", flags = 128, description = "@")
  [25] = (short_opt = 522, long_opt = "quick-add-uid", flags = 128, description = "quickly add a new user-id")
  [26] = (short_opt = 522, long_opt = "quick-adduid", flags = 128, description = "@")
  [27] = (short_opt = 523, long_opt = "quick-add-key", flags = 128, description = "@")
  [28] = (short_opt = 523, long_opt = "quick-addkey", flags = 128, description = "@")
  [29] = (short_opt = 524, long_opt = "quick-revoke-uid", flags = 128, description = "quickly revoke a user-id")
  [30] = (short_opt = 524, long_opt = "quick-revuid", flags = 128, description = "@")
  [31] = (short_opt = 525, long_opt = "quick-set-expire", flags = 128, description = "quickly set a new expiration date")
  [32] = (short_opt = 513, long_opt = "full-generate-key", flags = 128, description = "full featured key pair generation")
  [33] = (short_opt = 513, long_opt = "full-gen-key", flags = 128, description = "@")
  [34] = (short_opt = 551, long_opt = "generate-revocation", flags = 128, description = "generate a revocation certificate")
  [35] = (short_opt = 551, long_opt = "gen-revoke", flags = 128, description = "@")
  [36] = (short_opt = 532, long_opt = "delete-keys", flags = 128, description = "remove keys from the public keyring")
  [37] = (short_opt = 533, long_opt = "delete-secret-keys", flags = 128, description = "remove keys from the secret keyring")
  [38] = (short_opt = 520, long_opt = "quick-sign-key", flags = 128, description = "quickly sign a key")
  [39] = (short_opt = 521, long_opt = "quick-lsign-key", flags = 128, description = "quickly sign a key locally")
  [40] = (short_opt = 518, long_opt = "sign-key", flags = 128, description = "sign a key")
  [41] = (short_opt = 519, long_opt = "lsign-key", flags = 128, description = "sign a key locally")
  [42] = (short_opt = 531, long_opt = "edit-key", flags = 128, description = "sign or edit a key")
  [43] = (short_opt = 531, long_opt = "key-edit", flags = 128, description = "@")
  [44] = (short_opt = 570, long_opt = "change-passphrase", flags = 128, description = "change a passphrase")
  [45] = (short_opt = 570, long_opt = "passwd", flags = 128, description = "@")
  [46] = (short_opt = 552, long_opt = "generate-designated-revocation", flags = 128, description = "@")
  [47] = (short_opt = 552, long_opt = "desig-revoke", flags = 128, description = "@")
  [48] = (short_opt = 546, long_opt = "export", flags = 128, description = "export keys")
  [49] = (short_opt = 540, long_opt = "send-keys", flags = 128, description = "export keys to a keyserver")
  [50] = (short_opt = 541, long_opt = "receive-keys", flags = 128, description = "import keys from a keyserver")
  [51] = (short_opt = 541, long_opt = "recv-keys", flags = 128, description = "@")
  [52] = (short_opt = 543, long_opt = "search-keys", flags = 128, description = "search for keys on a keyserver")
  [53] = (short_opt = 544, long_opt = "refresh-keys", flags = 128, description = "update all keys from a keyserver")
  [54] = (short_opt = 542, long_opt = "locate-keys", flags = 128, description = "@")
  [55] = (short_opt = 545, long_opt = "fetch-keys", flags = 128, description = "@")
  [56] = (short_opt = 547, long_opt = "export-secret-keys", flags = 128, description = "@")
  [57] = (short_opt = 548, long_opt = "export-secret-subkeys", flags = 128, description = "@")
  [58] = (short_opt = 549, long_opt = "export-ssh-key", flags = 128, description = "@")
  [59] = (short_opt = 535, long_opt = "import", flags = 128, description = "import/merge keys")
  [60] = (short_opt = 536, long_opt = "fast-import", flags = 128, description = "@")
  [61] = (short_opt = 567, long_opt = "card-status", flags = 128, description = "print the card status")
  [62] = (short_opt = 568, long_opt = "edit-card", flags = 128, description = "change data on a card")
  [63] = (short_opt = 568, long_opt = "card-edit", flags = 128, description = "@")
  [64] = (short_opt = 569, long_opt = "change-pin", flags = 128, description = "change a card's PIN")
  [65] = (short_opt = 526, long_opt = "list-config", flags = 128, description = "@")
  [66] = (short_opt = 527, long_opt = "list-gcrypt-config", flags = 128, description = "@")
  [67] = (short_opt = 528, long_opt = "gpgconf-list", flags = 128, description = "@")
  [68] = (short_opt = 529, long_opt = "gpgconf-test", flags = 128, description = "@")
  [69] = (short_opt = 530, long_opt = "list-packets", flags = 128, description = "@")
  [70] = (short_opt = 561, long_opt = "export-ownertrust", flags = 128, description = "@")
  [71] = (short_opt = 562, long_opt = "import-ownertrust", flags = 128, description = "@")
  [72] = (short_opt = 557, long_opt = "update-trustdb", flags = 128, description = "update the trust database")
  [73] = (short_opt = 556, long_opt = "check-trustdb", flags = 128, description = "@")
  [74] = (short_opt = 558, long_opt = "fix-trustdb", flags = 128, description = "@")
  [75] = (short_opt = 563, long_opt = "dearmor", flags = 128, description = "@")
  [76] = (short_opt = 563, long_opt = "dearmour", flags = 128, description = "@")
  [77] = (short_opt = 564, long_opt = "enarmor", flags = 128, description = "@")
  [78] = (short_opt = 564, long_opt = "enarmour", flags = 128, description = "@")
  [79] = (short_opt = 554, long_opt = "print-md", flags = 128, description = "print message digests")
  [80] = (short_opt = 553, long_opt = "gen-prime", flags = 128, description = "@")
  [81] = (short_opt = 565, long_opt = "gen-random", flags = 128, description = "@")
  [82] = (short_opt = 571, long_opt = "server", flags = 128, description = "run in server mode")
  [83] = (short_opt = 572, long_opt = "tofu-policy", flags = 128, description = "|VALUE|set the TOFU policy for a key")
  [84] = (short_opt = 301, long_opt = 0x0000000000000000, flags = 0, description = "@\nOptions:\n ")
  [85] = (short_opt = 97, long_opt = "armor", flags = 0, description = "create ascii armored output")
  [86] = (short_opt = 97, long_opt = "armour", flags = 0, description = "@")
  [87] = (short_opt = 114, long_opt = "recipient", flags = 2, description = "|USER-ID|encrypt for USER-ID")
  [88] = (short_opt = 82, long_opt = "hidden-recipient", flags = 2, description = "@")
  [89] = (short_opt = 102, long_opt = "recipient-file", flags = 2, description = "@")
  [90] = (short_opt = 70, long_opt = "hidden-recipient-file", flags = 2, description = "@")
  [91] = (short_opt = 114, long_opt = "remote-user", flags = 2, description = "@")
  [92] = (short_opt = 607, long_opt = "default-recipient", flags = 2, description = "@")
  [93] = (short_opt = 608, long_opt = "default-recipient-self", flags = 0, description = "@")
  [94] = (short_opt = 609, long_opt = "no-default-recipient", flags = 0, description = "@")
  [95] = (short_opt = 716, long_opt = "temp-directory", flags = 2, description = "@")
  [96] = (short_opt = 717, long_opt = "exec-path", flags = 2, description = "@")
  [97] = (short_opt = 718, long_opt = "encrypt-to", flags = 2, description = "@")
  [98] = (short_opt = 720, long_opt = "no-encrypt-to", flags = 0, description = "@")
  [99] = (short_opt = 719, long_opt = "hidden-encrypt-to", flags = 2, description = "@")
  [100] = (short_opt = 721, long_opt = "encrypt-to-default-key", flags = 0, description = "@")
  [101] = (short_opt = 117, long_opt = "local-user", flags = 2, description = "|USER-ID|use USER-ID to sign or decrypt")
  [102] = (short_opt = 814, long_opt = "sender", flags = 2, description = "@")
  [103] = (short_opt = 610, long_opt = "try-secret-key", flags = 2, description = "@")
  [104] = (short_opt = 122, long_opt = 0x0000000000000000, flags = 1, description = "|N|set compress level to N (0 disables)")
  [105] = (short_opt = 642, long_opt = "compress-level", flags = 1, description = "@")
  [106] = (short_opt = 643, long_opt = "bzip2-compress-level", flags = 1, description = "@")
  [107] = (short_opt = 644, long_opt = "bzip2-decompress-lowmem", flags = 0, description = "@")
  [108] = (short_opt = 573, long_opt = "mimemode", flags = 0, description = "@")
  [109] = (short_opt = 116, long_opt = 0x0000000000000000, flags = 0, description = "@")
  [110] = (short_opt = 574, long_opt = "textmode", flags = 0, description = "use canonical text mode")
  [111] = (short_opt = 575, long_opt = "no-textmode", flags = 0, description = "@")
  [112] = (short_opt = 576, long_opt = "expert", flags = 0, description = "@")
  [113] = (short_opt = 577, long_opt = "no-expert", flags = 0, description = "@")
  [114] = (short_opt = 578, long_opt = "default-sig-expire", flags = 2, description = "@")
  [115] = (short_opt = 579, long_opt = "ask-sig-expire", flags = 0, description = "@")
  [116] = (short_opt = 580, long_opt = "no-ask-sig-expire", flags = 0, description = "@")
  [117] = (short_opt = 581, long_opt = "default-cert-expire", flags = 2, description = "@")
  [118] = (short_opt = 582, long_opt = "ask-cert-expire", flags = 0, description = "@")
  [119] = (short_opt = 583, long_opt = "no-ask-cert-expire", flags = 0, description = "@")
  [120] = (short_opt = 584, long_opt = "default-cert-level", flags = 1, description = "@")
  [121] = (short_opt = 585, long_opt = "min-cert-level", flags = 1, description = "@")
  [122] = (short_opt = 586, long_opt = "ask-cert-level", flags = 0, description = "@")
  [123] = (short_opt = 587, long_opt = "no-ask-cert-level", flags = 0, description = "@")
  [124] = (short_opt = 111, long_opt = "output", flags = 2, description = "|FILE|write output to FILE")
  [125] = (short_opt = 501, long_opt = "max-output", flags = 20, description = "@")
  [126] = (short_opt = 502, long_opt = "input-size-hint", flags = 2, description = "@")
  [127] = (short_opt = 118, long_opt = "verbose", flags = 0, description = "verbose")
  [128] = (short_opt = 113, long_opt = "quiet", flags = 0, description = "@")
  [129] = (short_opt = 664, long_opt = "no-tty", flags = 0, description = "@")
  [130] = (short_opt = 693, long_opt = "force-mdc", flags = 0, description = "@")
  [131] = (short_opt = 694, long_opt = "no-force-mdc", flags = 0, description = "@")
  [132] = (short_opt = 695, long_opt = "disable-mdc", flags = 0, description = "@")
  [133] = (short_opt = 696, long_opt = "no-disable-mdc", flags = 0, description = "@")
  [134] = (short_opt = 813, long_opt = "disable-signer-uid", flags = 0, description = "@")
  [135] = (short_opt = 110, long_opt = "dry-run", flags = 0, description = "do not make any changes")
  [136] = (short_opt = 105, long_opt = "interactive", flags = 0, description = "prompt before overwriting")
  [137] = (short_opt = 500, long_opt = "batch", flags = 0, description = "@")
  [138] = (short_opt = 600, long_opt = "yes", flags = 0, description = "@")
  [139] = (short_opt = 601, long_opt = "no", flags = 0, description = "@")
  [140] = (short_opt = 602, long_opt = "keyring", flags = 2, description = "@")
  [141] = (short_opt = 603, long_opt = "primary-keyring", flags = 2, description = "@")
  [142] = (short_opt = 604, long_opt = "secret-keyring", flags = 2, description = "@")
  [143] = (short_opt = 605, long_opt = "show-keyring", flags = 0, description = "@")
  [144] = (short_opt = 606, long_opt = "default-key", flags = 2, description = "@")
  [145] = (short_opt = 708, long_opt = "keyserver", flags = 2, description = "@")
  [146] = (short_opt = 709, long_opt = "keyserver-options", flags = 2, description = "@")
  [147] = (short_opt = 710, long_opt = "import-options", flags = 2, description = "@")
  [148] = (short_opt = 711, long_opt = "import-filter", flags = 2, description = "@")
  [149] = (short_opt = 712, long_opt = "export-options", flags = 2, description = "@")
  [150] = (short_opt = 713, long_opt = "export-filter", flags = 2, description = "@")
  [151] = (short_opt = 714, long_opt = "list-options", flags = 2, description = "@")
  [152] = (short_opt = 715, long_opt = "verify-options", flags = 2, description = "@")
  [153] = (short_opt = 701, long_opt = "display-charset", flags = 2, description = "@")
  [154] = (short_opt = 701, long_opt = "charset", flags = 2, description = "@")
  [155] = (short_opt = 611, long_opt = "options", flags = 2, description = "@")
  [156] = (short_opt = 612, long_opt = "debug", flags = 2, description = "@")
  [157] = (short_opt = 613, long_opt = "debug-level", flags = 2, description = "@")
  [158] = (short_opt = 614, long_opt = "debug-all", flags = 0, description = "@")
  [159] = (short_opt = 615, long_opt = "debug-iolbf", flags = 0, description = "@")
  [160] = (short_opt = 616, long_opt = "status-fd", flags = 1, description = "@")
  [161] = (short_opt = 617, long_opt = "status-file", flags = 2, description = "@")
  [162] = (short_opt = 618, long_opt = "attribute-fd", flags = 1, description = "@")
  [163] = (short_opt = 619, long_opt = "attribute-file", flags = 2, description = "@")
  [164] = (short_opt = 622, long_opt = "completes-needed", flags = 1, description = "@")
  [165] = (short_opt = 623, long_opt = "marginals-needed", flags = 1, description = "@")
  [166] = (short_opt = 624, long_opt = "max-cert-depth", flags = 1, description = "@")
  [167] = (short_opt = 754, long_opt = "trusted-key", flags = 2, description = "@")
  [168] = (short_opt = 625, long_opt = "load-extension", flags = 2, description = "@")
  [169] = (short_opt = 626, long_opt = "compliance", flags = 2, description = "@")
  [170] = (short_opt = 627, long_opt = "gnupg", flags = 0, description = "@")
  [171] = (short_opt = 627, long_opt = "no-pgp2", flags = 0, description = "@")
  [172] = (short_opt = 627, long_opt = "no-pgp6", flags = 0, description = "@")
  [173] = (short_opt = 627, long_opt = "no-pgp7", flags = 0, description = "@")
  [174] = (short_opt = 627, long_opt = "no-pgp8", flags = 0, description = "@")
  [175] = (short_opt = 628, long_opt = "rfc2440", flags = 0, description = "@")
  [176] = (short_opt = 629, long_opt = "rfc4880", flags = 0, description = "@")
  [177] = (short_opt = 630, long_opt = "rfc4880bis", flags = 0, description = "@")
  [178] = (short_opt = 631, long_opt = "openpgp", flags = 0, description = "use strict OpenPGP behavior")
  [179] = (short_opt = 632, long_opt = "pgp6", flags = 0, description = "@")
  [180] = (short_opt = 633, long_opt = "pgp7", flags = 0, description = "@")
  [181] = (short_opt = 634, long_opt = "pgp8", flags = 0, description = "@")
  [182] = (short_opt = 636, long_opt = "rfc2440-text", flags = 0, description = "@")
  [183] = (short_opt = 637, long_opt = "no-rfc2440-text", flags = 0, description = "@")
  [184] = (short_opt = 697, long_opt = "s2k-mode", flags = 1, description = "@")
  [185] = (short_opt = 698, long_opt = "s2k-digest-algo", flags = 2, description = "@")
  [186] = (short_opt = 699, long_opt = "s2k-cipher-algo", flags = 2, description = "@")
  [187] = (short_opt = 700, long_opt = "s2k-count", flags = 1, description = "@")
  [188] = (short_opt = 638, long_opt = "cipher-algo", flags = 2, description = "@")
  [189] = (short_opt = 639, long_opt = "digest-algo", flags = 2, description = "@")
  [190] = (short_opt = 640, long_opt = "cert-digest-algo", flags = 2, description = "@")
  [191] = (short_opt = 641, long_opt = "compress-algo", flags = 2, description = "@")
  [192] = (short_opt = 641, long_opt = "compression-algo", flags = 2, description = "@")
  [193] = (short_opt = 688, long_opt = "throw-keyids", flags = 0, description = "@")
  [194] = (short_opt = 689, long_opt = "no-throw-keyids", flags = 0, description = "@")
  [195] = (short_opt = 690, long_opt = "show-photos", flags = 0, description = "@")
  [196] = (short_opt = 691, long_opt = "no-show-photos", flags = 0, description = "@")
  [197] = (short_opt = 692, long_opt = "photo-viewer", flags = 2, description = "@")
  [198] = (short_opt = 78, long_opt = "set-notation", flags = 2, description = "@")
  [199] = (short_opt = 503, long_opt = "sig-notation", flags = 2, description = "@")
  [200] = (short_opt = 504, long_opt = "cert-notation", flags = 2, description = "@")
  [201] = (short_opt = 302, long_opt = 0x0000000000000000, flags = 0, description = "@\n(See the man page for a complete listing of all commands and options)\n")
  [202] = (short_opt = 303, long_opt = 0x0000000000000000, flags = 0, description = "@\nExamples:\n\n -se -r Bob [file]          sign and encrypt for user Bob\n --clear-sign [file]        make a clear text signature\n --detach-sign [file]       make a detached signature\n --list-keys [names]        show keys\n --fingerprint [names]      show fingerprints\n")
  [203] = (short_opt = 555, long_opt = "print-mds", flags = 128, description = "@")
  [204] = (short_opt = 559, long_opt = "list-trustdb", flags = 128, description = "@")
  [205] = (short_opt = 534, long_opt = "delete-secret-and-public-keys", flags = 128, description = "@")
  [206] = (short_opt = 566, long_opt = "rebuild-keydb-caches", flags = 128, description = "@")
  [207] = (short_opt = 645, long_opt = "passphrase", flags = 2, description = "@")
  [208] = (short_opt = 646, long_opt = "passphrase-fd", flags = 1, description = "@")
  [209] = (short_opt = 647, long_opt = "passphrase-file", flags = 2, description = "@")
  [210] = (short_opt = 648, long_opt = "passphrase-repeat", flags = 1, description = "@")
  [211] = (short_opt = 649, long_opt = "pinentry-mode", flags = 2, description = "@")
  [212] = (short_opt = 650, long_opt = "command-fd", flags = 1, description = "@")
  [213] = (short_opt = 651, long_opt = "command-file", flags = 2, description = "@")
  [214] = (short_opt = 652, long_opt = "debug-quick-random", flags = 0, description = "@")
  [215] = (short_opt = 653, long_opt = "no-verbose", flags = 0, description = "@")
  [216] = (short_opt = 654, long_opt = "trustdb-name", flags = 2, description = "@")
  [217] = (short_opt = 759, long_opt = "auto-check-trustdb", flags = 0, description = "@")
  [218] = (short_opt = 760, long_opt = "no-auto-check-trustdb", flags = 0, description = "@")
  [219] = (short_opt = 673, long_opt = "force-ownertrust", flags = 2, description = "@")
  [220] = (short_opt = 655, long_opt = "no-secmem-warning", flags = 0, description = "@")
  [221] = (short_opt = 656, long_opt = "require-secmem", flags = 0, description = "@")
  [222] = (short_opt = 657, long_opt = "no-require-secmem", flags = 0, description = "@")
  [223] = (short_opt = 658, long_opt = "no-permission-warning", flags = 0, description = "@")
  [224] = (short_opt = 659, long_opt = "no-mdc-warning", flags = 0, description = "@")
  [225] = (short_opt = 660, long_opt = "no-armor", flags = 0, description = "@")
  [226] = (short_opt = 660, long_opt = "no-armour", flags = 0, description = "@")
  [227] = (short_opt = 661, long_opt = "no-default-keyring", flags = 0, description = "@")
  [228] = (short_opt = 662, long_opt = "no-keyring", flags = 0, description = "@")
  [229] = (short_opt = 663, long_opt = "no-greeting", flags = 0, description = "@")
  [230] = (short_opt = 665, long_opt = "no-options", flags = 0, description = "@")
  [231] = (short_opt = 667, long_opt = "homedir", flags = 2, description = "@")
  [232] = (short_opt = 666, long_opt = "no-batch", flags = 0, description = "@")
  [233] = (short_opt = 595, long_opt = "with-colons", flags = 0, description = "@")
  [234] = (short_opt = 597, long_opt = "with-tofu-info", flags = 0, description = "@")
  [235] = (short_opt = 596, long_opt = "with-key-data", flags = 0, description = "@")
  [236] = (short_opt = 598, long_opt = "with-sig-list", flags = 0, description = "@")
  [237] = (short_opt = 599, long_opt = "with-sig-check", flags = 0, description = "@")
  [238] = (short_opt = 107, long_opt = "list-key", flags = 128, description = "@")
  [239] = (short_opt = 539, long_opt = "list-sig", flags = 128, description = "@")
  [240] = (short_opt = 550, long_opt = "check-sig", flags = 128, description = "@")
  [241] = (short_opt = 668, long_opt = "skip-verify", flags = 0, description = "@")
  [242] = (short_opt = 669, long_opt = "skip-hidden-recipients", flags = 0, description = "@")
  [243] = (short_opt = 670, long_opt = "no-skip-hidden-recipients", flags = 0, description = "@")
  [244] = (short_opt = 584, long_opt = "default-cert-check-level", flags = 1, description = "@")
  [245] = (short_opt = 671, long_opt = "always-trust", flags = 0, description = "@")
  [246] = (short_opt = 672, long_opt = "trust-model", flags = 2, description = "@")
  [247] = (short_opt = 807, long_opt = "tofu-default-policy", flags = 2, description = "@")
  [248] = (short_opt = 674, long_opt = "set-filename", flags = 2, description = "@")
  [249] = (short_opt = 675, long_opt = "for-your-eyes-only", flags = 0, description = "@")
  [250] = (short_opt = 676, long_opt = "no-for-your-eyes-only", flags = 0, description = "@")
  [251] = (short_opt = 677, long_opt = "set-policy-url", flags = 2, description = "@")
  [252] = (short_opt = 678, long_opt = "sig-policy-url", flags = 2, description = "@")
  [253] = (short_opt = 679, long_opt = "cert-policy-url", flags = 2, description = "@")
  [254] = (short_opt = 680, long_opt = "show-policy-url", flags = 0, description = "@")
  [255] = (short_opt = 681, long_opt = "no-show-policy-url", flags = 0, description = "@")
  ...
}
  frame #6: 0x00007fffc4011255 libdyld.dylib`start + 1
  frame #7: 0x00007fffc4011255 libdyld.dylib`start + 1
(lldb) (lldb) ^D
%                                                                                                                                   
 

[2]-pdp@tungsten.lan:s010[16:59]3D(1002)~% [?2004h[?2004l


Script done on Sat Mar  4 16:59:30 2017
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 996 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170304/c2ec0e36/attachment-0001.sig>

From wk at gnupg.org  Sun Mar  5 23:26:10 2017
From: wk at gnupg.org (Werner Koch)
Date: Sun, 05 Mar 2017 23:26:10 +0100
Subject: assertion failure / key-locate local / macOS
In-Reply-To: <20170304061029.GA13739@breadbox.private.spodhuis.org> (Phil
 Pennock's message of "Sat, 4 Mar 2017 01:10:29 -0500")
References: <20170304061029.GA13739@breadbox.private.spodhuis.org>
Message-ID: <87a88zwebh.fsf@wheatstone.g10code.de>

Hi!

Thanks for the backtrace.  Please try the attached patch.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gpg-Fix-attempt-to-double-free-an-UID-structure.patch
Type: text/x-diff
Size: 1990 bytes
Desc: not available
URL: </pipermail/attachments/20170305/618d2555/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170305/618d2555/attachment.sig>

From gnupg-devel at spodhuis.org  Mon Mar  6 02:36:32 2017
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Sun, 5 Mar 2017 20:36:32 -0500
Subject: assertion failure / key-locate local / macOS
In-Reply-To: <87a88zwebh.fsf@wheatstone.g10code.de>
References: <20170304061029.GA13739@breadbox.private.spodhuis.org>
 <87a88zwebh.fsf@wheatstone.g10code.de>
Message-ID: <20170306013632.GA23458@breadbox.private.spodhuis.org>

On 2017-03-05 at 23:26 +0100, Werner Koch wrote:
> Thanks for the backtrace.  Please try the attached patch.

Patch works for me.

% openssl dgst -sha256 0001-gpg-Fix-attempt-to-double-free-an-UID-structure.patch
SHA256(0001-gpg-Fix-attempt-to-double-free-an-UID-structure.patch)= 2fa4d9929cba0ff8e0ee5a57621fb0cd5c6163e2dcf8b60e64ecddf103c0c0dd

Applied on git tree at: 67c203b6bf8d6dd489ceef3391f609986e7b7a49

Unable to trigger assertion failure with that patch applied.

Thanks!
-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 996 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170305/20f7a629/attachment.sig>

From michael.haubenwallner at ssi-schaefer.com  Mon Mar  6 18:04:12 2017
From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner)
Date: Mon,  6 Mar 2017 18:04:12 +0100
Subject: [PATCH] Cygwin needs -no-undefined libtool flag.
Message-ID: <20170306170412.27837-1-michael.haubenwallner@ssi-schaefer.com>

* configure.ac: Set AM_CONDITIONAL(HAVE_UNDEFINED_SYMS) for mingw32 and
cygwin systems.
* src/Makefile.am: Use -no-undefined libtool flag when we do not
HAVE_UNDEFINED_SYMS, instead of when we HAVE_W32_SYSTEM only.

Cygwin is not a "real" Win32 system, but uses the Win32 binary format,
so libtool needs the -no-undefined flag.
---
 configure.ac    | 8 ++++++++
 src/Makefile.am | 8 ++++++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index a44f0c8..17a6392 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,17 +85,24 @@ AC_GNU_SOURCE
 have_w32_system=no
 have_w64_system=no
 have_w32ce_system=no
+have_undefined_syms=yes
 case "${host}" in
     x86_64-*mingw32*)
         have_w32_system=yes
         have_w64_system=yes
+        have_undefined_syms=no
         ;;
     *-mingw32ce*)
         have_w32_system=yes
         have_w32ce_system=yes
+        have_undefined_syms=no
         ;;
     *-mingw32*)
         have_w32_system=yes
+        have_undefined_syms=no
+        ;;
+    *-cygwin*)
+        have_undefined_syms=no
         ;;
     *)
        ;;
@@ -495,6 +502,7 @@ fi
 AM_CONDITIONAL(HAVE_W32_SYSTEM, test "$have_w32_system" = yes)
 AM_CONDITIONAL(HAVE_W64_SYSTEM, test "$have_w64_system" = yes)
 AM_CONDITIONAL(HAVE_W32CE_SYSTEM, test "$have_w32ce_system" = yes)
+AM_CONDITIONAL(HAVE_UNDEFINED_SYMS, test "$have_undefined_syms" = yes)
 AM_CONDITIONAL(CROSS_COMPILING, test x$cross_compiling = xyes)
 AM_CONDITIONAL(FORCE_USE_SYSCFG, test x$force_use_syscfg = xyes)
 
diff --git a/src/Makefile.am b/src/Makefile.am
index 398ec5e..63710de 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -120,7 +120,6 @@ SUFFIXES = .rc .lo
 	$(LTRCCOMPILE) -i "$<" -o "$@"
 
 gpg_error_res = versioninfo.lo
-no_undefined = -no-undefined
 export_symbols = -export-symbols gpg-error.def
 # i686-w64-mingw32.gcc version 4.9.1 takes the long long helper
 # functions from libgcc_s_sjlj-1.dll and not from a static libgcc.  As
@@ -149,7 +148,6 @@ else
 #
 arch_sources = posix-lock.c posix-lock-obj.h posix-thread.c
 gpg_error_res =
-no_undefined =
 export_symbols =
 extra_ltoptions =
 
@@ -163,6 +161,12 @@ endif
 # }}} End Unix part
 #
 
+if HAVE_UNDEFINED_SYMS
+no_undefined =
+else
+no_undefined = -no-undefined
+endif
+
 if HAVE_LD_VERSION_SCRIPT
   libgpg_error_vers_opt = -Wl,--version-script=$(srcdir)/gpg-error.vers
 else
-- 
2.10.2



From michael.haubenwallner at ssi-schaefer.com  Tue Mar  7 13:54:49 2017
From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner)
Date: Tue,  7 Mar 2017 13:54:49 +0100
Subject: [PATCH] gpgscm: Use system strlwr if available.
Message-ID: <20170307125449.12005-1-michael.haubenwallner@ssi-schaefer.com>

* tests/gpgscm/scheme.c: Define local strlwr only when HAVE_STRLWR is
not defined in config.h.
---
 tests/gpgscm/scheme.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/gpgscm/scheme.c b/tests/gpgscm/scheme.c
index b2ff721..25515ed 100644
--- a/tests/gpgscm/scheme.c
+++ b/tests/gpgscm/scheme.c
@@ -12,6 +12,8 @@
  *
  */
 
+#include <config.h>
+
 #define _SCHEME_SOURCE
 #include "scheme-private.h"
 #ifndef WIN32
@@ -88,7 +90,7 @@ static int stricmp(const char *s1, const char *s2)
 }
 #endif /* __APPLE__ */
 
-#if USE_STRLWR
+#if USE_STRLWR && !defined(HAVE_STRLWR)
 static const char *strlwr(char *s) {
   const char *p=s;
   while(*s) {
-- 
2.10.2



From justus at g10code.com  Tue Mar  7 14:36:11 2017
From: justus at g10code.com (Justus Winter)
Date: Tue, 07 Mar 2017 14:36:11 +0100
Subject: [PATCH] gpgscm: Use system strlwr if available.
In-Reply-To: <20170307125449.12005-1-michael.haubenwallner@ssi-schaefer.com>
References: <20170307125449.12005-1-michael.haubenwallner@ssi-schaefer.com>
Message-ID: <8737epus38.fsf@europa.jade-hamburg.de>

Michael Haubenwallner <michael.haubenwallner at ssi-schaefer.com> writes:

> * tests/gpgscm/scheme.c: Define local strlwr only when HAVE_STRLWR is
> not defined in config.h.

Merged slightly amended, many thanks!

May I ask what compiler you are using?


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

From michael.haubenwallner at ssi-schaefer.com  Tue Mar  7 14:49:01 2017
From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner)
Date: Tue, 7 Mar 2017 14:49:01 +0100
Subject: [PATCH] gpgscm: Use system strlwr if available.
In-Reply-To: <8737epus38.fsf@europa.jade-hamburg.de>
References: <20170307125449.12005-1-michael.haubenwallner@ssi-schaefer.com>
 <8737epus38.fsf@europa.jade-hamburg.de>
Message-ID: <717be7db-658a-cf94-a8b2-d7b4d4ac8cfe@ssi-schaefer.com>



On 03/07/2017 02:36 PM, Justus Winter wrote:
> Michael Haubenwallner <michael.haubenwallner at ssi-schaefer.com> writes:
> 
>> * tests/gpgscm/scheme.c: Define local strlwr only when HAVE_STRLWR is
>> not defined in config.h.
> 
> Merged slightly amended, many thanks!

Thanks a lot!

An other idea was to use strlwr from common/stringhelp.h instead,
but that failed to me with lots of strange compiler errors...

> May I ask what compiler you are using?

This is gcc on Cygwin (where's another patch pending for - with libgpg-error).

/haubi/


From wk at gnupg.org  Tue Mar  7 20:27:43 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 07 Mar 2017 20:27:43 +0100
Subject: [PATCH] Cygwin needs -no-undefined libtool flag.
In-Reply-To: <20170306170412.27837-1-michael.haubenwallner@ssi-schaefer.com>
 (Michael Haubenwallner's message of "Mon, 6 Mar 2017 18:04:12 +0100")
References: <20170306170412.27837-1-michael.haubenwallner@ssi-schaefer.com>
Message-ID: <87bmtcq440.fsf@wheatstone.g10code.de>

On Mon,  6 Mar 2017 18:04, michael.haubenwallner at ssi-schaefer.com said:

> Cygwin is not a "real" Win32 system, but uses the Win32 binary format,
> so libtool needs the -no-undefined flag.

This needs to be patched in libtool and not in libgpg-error et al.  it
might be that upstream libtool already has that.  However due to
problems we had with the upstream version we keep our version which has
a few patches we require.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170307/9c3220ab/attachment.sig>

From michael.haubenwallner at ssi-schaefer.com  Wed Mar  8 13:02:50 2017
From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner)
Date: Wed, 8 Mar 2017 13:02:50 +0100
Subject: [PATCH] Cygwin needs -no-undefined libtool flag.
In-Reply-To: <87bmtcq440.fsf@wheatstone.g10code.de>
References: <20170306170412.27837-1-michael.haubenwallner@ssi-schaefer.com>
 <87bmtcq440.fsf@wheatstone.g10code.de>
Message-ID: <a112c458-f6ef-c82f-0239-a5d9b83bbfed@ssi-schaefer.com>


On 03/07/2017 08:27 PM, Werner Koch wrote:
> On Mon,  6 Mar 2017 18:04, michael.haubenwallner at ssi-schaefer.com said:
> 
>> Cygwin is not a "real" Win32 system, but uses the Win32 binary format,
>> so libtool needs the -no-undefined flag.
> 
> This needs to be patched in libtool and not in libgpg-error et al.  it
> might be that upstream libtool already has that.  However due to
> problems we had with the upstream version we keep our version which has
> a few patches we require.

Well, there's nothing libtool can do about here.  Instead, there's a
(widespread) misinterpretation about the -no-undefined libtool flag.

Agreed this might be easier to understand when it were not a "no-"flag,
but this is for historical reasons when there were static libraries only.


Please let me try to explain:

Creating a static library does not need to know which libraries to link
against, as no linking is done at all.  So libtool does not require
library maintainers to specify enough libraries to resolve all symbols.

But with the introduction of shared libraries this requirement changed:
While each operating system does "support" undefined symbols with static
libraries, some operating systems also do support undefined symbols with
shared libraries, but some don't.

On the other hand, each operating system supporting shared libraries
obviously does support shared libraries without undefined symbols.

Without the -no-undefined flag, libtool assumes the library does have
undefined symbols, and does not create the shared library when the
operating system is known to lack support for undefined symbols in
shared libraries.

With the -no-undefined flag, libtool knows that the library maintainer
does provide necessary libraries to resolve all symbols, so libtool can
create the shared library even on operating systems without support for
undefined symbols in shared libraries.


As far as I can see, libgpg-error does not rely on undefined symbols at all.

So -no-undefined really makes sense for any platform here, as proposed in
https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032186.html

Beyond that: With linkers that support yelling on undefined symbols (like
GNU ld with -zdefs flag), the -no-undefined flag allows to unhide obscure
bugs related to undefined symbols at library linking time already.

However, because of the -zdefs (or similar) linker flag (where supported),
I can understand not to add the -no-undefined flag in minor releases,
to not unhide bugs that do not (seem to) harm when left hidden.

Uhm, lots of inversive logic here...

Thanks!
/haubi/


From wk at gnupg.org  Sat Mar 11 18:27:25 2017
From: wk at gnupg.org (Werner Koch)
Date: Sat, 11 Mar 2017 18:27:25 +0100
Subject: ADMIN: Some mail addresses are now rewritten (was: Test mail from
 Outlook)
In-Reply-To: <43387B6C-C35B-4448-8B55-35763D94CAC4@microsoft.com> (Jeffrey
 Stedfast via Gnupg-users's message of "Sat, 11 Mar 2017 14:02:17
 +0000")
References: <43387B6C-C35B-4448-8B55-35763D94CAC4@microsoft.com>
Message-ID: <87varf911e.fsf@wheatstone.g10code.de>

Hi!

You may have noted that the From address has been rewritten to show the
list address instead of your address.  In addition a reply-to header has
been set so that your address is also known. 

The reason for this is that some mail sites now have a DMARC reject
policy which leads to a bounce for all subscribers whose mail provider
honors this DMARC policy - for example gmail.  After a few bounces
message delivery to those subscribers will blocked by our Mailman.

I have meanwhile unblocked all those addresses but the mails since
Thursday or Friday have not been delivered to the affected accounts.

The mitigation is to either use the list address as From: address or a
modify the From: address to make it invalid (e.g. append the reserved
domain "invalid").  Mailman offers the first option and that is what is
now in use for every poster which an address where a reject policy is
is advertised.

The problem with this rewriting is that it breaks quoting.  For example
here is how I would have replied to Jeff's test mail:

  On Sat, 11 Mar 2017 15:02, gnupg-users at gnupg.org said:
  
  > Just a simple test message as asked by Werner to test something?
  
  Thank you.

Thus I think marking the address invalid would have been a better choice
for Mailman - but there is no option for this yet.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170311/1dd076bc/attachment.sig>

From bernhard at intevation.de  Mon Mar 13 11:30:27 2017
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 13 Mar 2017 11:30:27 +0100
Subject: Stable GnuPG interface, git should use GPGME
In-Reply-To: <CACBZZX4Av-D6hxE9ceDFPuG-_qUQbH_6KW5JKsJf0SuH62jkuQ@mail.gmail.com>
References: <201703101100.15214.bernhard.reiter@intevation.de>
 <CACBZZX4Av-D6hxE9ceDFPuG-_qUQbH_6KW5JKsJf0SuH62jkuQ@mail.gmail.com>
Message-ID: <201703131130.31623.bernhard@intevation.de>

Am Freitag 10 M?rz 2017 15:23:27 schrieb ?var Arnfj?r? Bjarmason:
> On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter wrote
> > please consider using libgpgme interfacing to GnuPG, because the gpg
> > command-line interface is not considered an official API to GnuPG by the
> > GnuPG-devs and thus potentially unstable.

> > == Usability problem with `gpg2` vs `gpg`
> >
> > My use case today was signing and git by default found the `gpg` binary
> > by default and the command failed.

I've mentioned this as one example for a possible advantage using libgpgme
when interfacing with GnuPG.

> > The reason is that I have `gpg2` 
> > installed and most applications use it right away. So git failed signing
> > because the .gnupg configuration of the user was not ready for the old
> > `gpg` which is still installed on Debian GNU/Linux for purposes of the
> > operating system. If git would have used libgpgme, gpgme would have
> > choosen the most uptodate version of `gpg` available (or configured)
> > without me intervening via gpg.program. Now because of this problem you
> > could adding a check for `gpg2` and fallback to `gpg`, but even better
> > would be to move to libgpgme. >:)
>
> I'm on Debian but haven't had these issues. What's your gpg & gpg2
> --version & Debian release? And what in particular failed?

If you use options in your configuration that only gpg2 understands, gpg(1)
will barf. For example the following lines in ~/.gnupg/gpg.conf

  debug-level basic
  log-file socket:///home/bern/.gnupg/log-socket

will lead to
LANG=C gpg -K
  gpg: /powerhome/bern/.gnupg/gpg.conf:102: argument not expected
  gpg: /powerhome/bern/.gnupg/gpg.conf:103: invalid option
where gpg2 works as expected.

As a number of application already uses gpg2 (via libgpgme or not), this may 
go unnoticed for a while. So when I've started to sign with git on this 
machine I ran into the problem (current Jessie default versions):

  dpkg -s gnupg | grep ^Version
  #Version: 1.4.18-7+deb8u3
  dpkg -s gnupg2 | grep ^Version
  #Version: 2.0.26-6+deb8u1

Workarounds are:
 * Use a different config for gpg2 and gpg, e.g. ~/.gnupg/gpg.conf-2
   (https://www.gnupg.org/documentation/manuals/gnupg-2.0/Invoking-GPG.html )
 * or set gpg.program for git to gpg2.

> And what git version was this? I see we've had a couple of workarounds
> for gpg2, in particular Linus's v2.8.4-1-gb624a3e67f, but if you have
> v2.10.0 or later that won't fix whatever issue you had.

dpkg -s git | grep ^Version
Version: 1:2.1.4-2.1+deb8u2
(I've checked the most current master source to see that git still calls 
gpg.program, otherwise followed advise on https://git-scm.com/community
to send reports and questions to the list.)

> Using the library sounds good, but a shorter-term immediate fix would
> be to figure out what bug you encountered in our use of the
> command-line version, and see if we've fixed that already or not.
> Regardless of what we do with a gpg library in the future some distros
> might want to backport such a small patch if we can come up with it.

I guess a good simple approach would be to try "gpg2" first and then fall back 
to "gpg" or "gpgv" in case only these version are available.
(Here is a report that puts forward using gpgv in some situations 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852684 )

As there are other subtle potential issues with directly calling a gpg binary,
using libgpgme by default probably has other advantages as well. And if there 
are important functions missing the GnuPG-devs would like to hear about them.

Regards,
Bernhard

-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170313/965c3077/attachment.sig>

From gniibe at fsij.org  Tue Mar 14 02:33:10 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 14 Mar 2017 10:33:10 +0900
Subject: [PATCH] g10: Support multiple cards
Message-ID: <87tw6w63s9.fsf@fsij.org>

Hello,

Attached is a patch to improve --card-status when there are multiple
cards (with internal CCID driver).

The change is a bit larger than I expected, because we need to change
how "LEARN" command works.  Yet, I don't know the impact for other
cases (like Scute and Poldi).  So, I won't push this change soon, but
try more testing.

Here is an example output.

==========================
$ ./g10/gpg --card-status --verbose
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!


Reader ...........: 234B:0000:FSIJ-1.2.2-87022128:0
Application ID ...: D276000124010200F517000000010000
Version ..........: 2.0
Manufacturer .....: FSIJ
Serial number ....: 00000001
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 46
Signature key ....: 1241 24BD 3B48 62AF 7A0A  42F1 00B4 5EBD 4CA7 BABE
      created ....: 2010-10-15 06:46:33
Encryption key....: 42E1 E805 4E6F 1F30 26F2  DC79 79A7 9093 0842 39CF
      created ....: 2010-10-15 06:46:33
Authentication key: B4D9 7142 C42D 6802 F5F7  4E70 9C33 B6BA 5BB0 65DC
      created ....: 2010-10-22 06:06:36
General key info..: pub  rsa2048/00B45EBD4CA7BABE 2010-10-15 NIIBE Yutaka <gniibe at fsij.org>
sec>  rsa2048/00B45EBD4CA7BABE  created: 2010-10-15  expires: never     
                                card-no: F517 00000001
ssb#  secp256k1/824E72CE975B9053  created: 2014-01-16  expires: never     
ssb>  rsa2048/79A79093084239CF  created: 2010-10-15  expires: never     
                                card-no: F517 00000001
ssb>  rsa2048/9C33B6BA5BB065DC  created: 2010-10-22  expires: never     
                                card-no: F517 00000001
Reader ...........: 234B:0000:FSIJ-1.2.2-87193059:0
Application ID ...: D276000124010200FFFE871930590000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87193059
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: ed25519 cv25519 ed25519
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 51
Signature key ....: 249C B377 1750 745D 5CDD  323C E267 B052 364F 028D
      created ....: 2015-08-12 07:10:48
Encryption key....: E228 AB42 0F73 3B1D 712D  E50C 850A F040 D619 F240
      created ....: 2015-08-12 07:10:48
Authentication key: E63F 31E6 F203 20B5 D796  D266 5F91 0521 FAA8 05B1
      created ....: 2015-08-12 07:16:14
General key info..: pub  ed25519/E267B052364F028D 2015-08-12 NIIBE Yutaka <gniibe at debian.org>
sec>  ed25519/E267B052364F028D  created: 2015-08-12  expires: never     
                                card-no: FFFE 87193059
ssb>  ed25519/5F910521FAA805B1  created: 2015-08-12  expires: never     
                                card-no: FFFE 87193059
ssb>  cv25519/850AF040D619F240  created: 2015-08-12  expires: never     
                                card-no: FFFE 87193059
$ 
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: card-status-change-20170313.diff
Type: text/x-diff
Size: 12324 bytes
Desc: g10 patch for multiple cards
URL: </pipermail/attachments/20170314/21c90cfd/attachment.diff>

From dkg at fifthhorseman.net  Wed Mar 15 21:30:14 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Mar 2017 16:30:14 -0400
Subject: test suite failures in tofu.scm on 2.1.19
Message-ID: <87a88mqo4p.fsf@alice.fifthhorseman.net>

Hey all--

In trying to build 2.1.19 for debian, i'm seeing a test suite failure in
tofu.scm.

In particular:


0 dkg at alice:~/src/pkg-gnupg/gnupg2/build/tests/openpgp$ LC_ALL=C EXEEXT= PATH=../gpgscm:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/dkg/bin TMP=/tmp srcdir=/home/dkg/src/pkg-gnupg/gnupg2/build/../tests/openpgp objdir=/home/dkg/src/pkg-gnupg/gnupg2/build GPGSCM_PATH=/home/dkg/src/pkg-gnupg/gnupg2/build/../tests/gpgscm:/home/dkg/src/pkg-gnupg/gnupg2/build/../tests/openpgp /home/dkg/src/pkg-gnupg/gnupg2/build/tests/gpgscm/gpgscm  run-tests.scm  version.scm tofu.scm
> PASS: setup.scm 
Printing the GPG version 
PASS: version.scm 
gpgconf: option trust-model not supported by backend GnuPG
gpgconf: fatal error (exit status 1)
: ()
0: tests.scm:140: (throw (:stderr result))
1: defs.scm:146: (call-popen `(,(tool-hardcoded 'gpgconf) , at args) input)
2: defs.scm:177: (gpg-conf' (string-append key ":0:" (percent-encode value')) `(--change-options ,component))
3: tofu.scm:37: ((*colon-hook* 'update trust-model) "tofu")
FAIL: tofu.scm 
2 tests run, 1 succeeded, 1 failed, 0 skipped. 
Failed tests: tofu.scm 
1 dkg at alice:~/src/pkg-gnupg/gnupg2/build/tests/openpgp$


So somehow it looks like the test suite is pulling from the system gpg
instead of the just-built gpg.


Wrapping the whole thing in strace to look at what calls to execve are
being done, i see:

1869  16:02:33.088593 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgconf", ["gpgconf", "--build-prefix", "/home/dkg/src/pkg-gnupg/gnupg2/build", "--list-components"], [/* 54 vars */]) = 0 <0.000836>
1870  16:02:33.110198 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/g10/gpg", ["gpg", "--gpgconf-test", "--always-trust"], [/* 54 vars */] <unfinished ...>
1909  16:02:35.006865 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgconf", ["gpgconf", "--remove-socketdir"], [/* 55 vars */]) = 0 <0.000146>
1914  16:02:35.077300 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgconf", ["gpgconf", "--build-prefix", "/home/dkg/src/pkg-gnupg/gnupg2/build", "--list-components"], [/* 54 vars */]) = 0 <0.000164>
1915  16:02:35.091913 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/g10/gpg", ["gpg", "--gpgconf-test", "--always-trust"], [/* 54 vars */]) = 0 <0.000256>
1916  16:02:35.130254 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgconf", ["gpgconf", "--create-socketdir"], [/* 55 vars */]) = 0 <0.000433>
1925  16:02:36.190134 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgconf", ["gpgconf", "--remove-socketdir"], [/* 55 vars */]) = 0 <0.000334>
1935  16:02:36.286487 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgconf", ["gpgconf", "--build-prefix", "/home/dkg/src/pkg-gnupg/gnupg2/build", "--list-components"], [/* 54 vars */]) = 0 <0.000237>
1936  16:02:36.302993 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/g10/gpg", ["gpg", "--gpgconf-test", "--always-trust"], [/* 54 vars */] <unfinished ...>
1937  16:02:36.383087 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgconf", ["gpgconf", "--create-socketdir"], [/* 55 vars */]) = 0 <0.000508>
1953  16:02:37.453386 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgconf", ["gpgconf", "--change-options", "gpg"], [/* 55 vars */]) = 0 <0.000364>
1954  16:02:37.459441 execve("/usr/bin/gpg", ["gpg", "--gpgconf-list"], [/* 55 vars */]) = 0 <0.000298>
1955  16:02:37.505012 execve("/home/dkg/src/pkg-gnupg/gnupg2/build/tools/gpgconf", ["gpgconf", "--remove-socketdir"], [/* 55 vars */]) = 0 <0.000333>

So the final thing isn't invoking the right gpg, even though the first
ones are.

I'm not sure how to best debug this next.  Any pointers?

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170315/3b34d41a/attachment-0001.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Mar 15 22:45:32 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 15 Mar 2017 22:45:32 +0100
Subject: test suite failures in tofu.scm on 2.1.19
In-Reply-To: <87a88mqo4p.fsf@alice.fifthhorseman.net>
References: <87a88mqo4p.fsf@alice.fifthhorseman.net>
Message-ID: <15F24DA2-D7A8-4913-AB86-D76E56AABAF7@sumptuouscapital.com>

On March 15, 2017 9:30:14 PM GMT+01:00, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>Hey all--
>
>In trying to build 2.1.19 for debian, i'm seeing a test suite failure
>in

>
>
>So somehow it looks like the test suite is pulling from the system gpg
>instead of the just-built gpg.
>


>
>So the final thing isn't invoking the right gpg, even though the first
>ones are.
>
>I'm not sure how to best debug this next.  Any pointers?
>

We also observed similar behavior in gentoo (but in other parts of test suite). Likely related to 
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=a98459d3f4ec3d196fb0adb0e90dadf40abc8c81

And correspondig bug identified in commit msg


--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP certificate at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


From dkg at fifthhorseman.net  Wed Mar 15 22:54:08 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Mar 2017 17:54:08 -0400
Subject: test suite failures in tofu.scm on 2.1.19
In-Reply-To: <15F24DA2-D7A8-4913-AB86-D76E56AABAF7@sumptuouscapital.com>
References: <87a88mqo4p.fsf@alice.fifthhorseman.net>
 <15F24DA2-D7A8-4913-AB86-D76E56AABAF7@sumptuouscapital.com>
Message-ID: <87shmep5of.fsf@alice.fifthhorseman.net>

On Wed 2017-03-15 17:45:32 -0400, Kristian Fiskerstrand wrote:
> We also observed similar behavior in gentoo (but in other parts of test suite). Likely related to 
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=a98459d3f4ec3d196fb0adb0e90dadf40abc8c81
>
> And correspondig bug identified in commit msg

ah, thx for the pointer, i'll take a look at that.

    --dkg


From wk at gnupg.org  Thu Mar 16 21:06:16 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 16 Mar 2017 21:06:16 +0100
Subject: Fwd: Incentives/open source participation survey
Message-ID: <87shmdt29z.fsf@wheatstone.g10code.de>

Hi!

This may help our community and thus I pass it on:

Shalom-Salam,

   Werner


-------- Forwarded Message --------

Hi,

I recently met a postdoctoral researcher doing some work for Mozilla
since they are facing some serious retention issues for their free and
open source projects. Her particular project is looking at current
incentives in open source software development. She has a survey and I
offered to spread the word:

https://www.surveymonkey.com/r/YF6G69N

If you are part of other open source technical endeavors, feel free to
pass on as well.

All best,

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170316/4f07425b/attachment.sig>

From dkg at fifthhorseman.net  Fri Mar 17 17:27:14 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 17 Mar 2017 12:27:14 -0400
Subject: 2.1.19 testing failures on the debian build daemons
Message-ID: <877f3noom5.fsf@alice.fifthhorseman.net>

Hey all--

the debian build daemons are all failing to build 2.1.19-1 (which
includes many post-release bugfix patches, on top of 2.1.19 itself):

https://buildd.debian.org/status/logs.php?pkg=gnupg2&ver=2.1.19-1&suite=experimental

The failures are in the test suite.

(the one visible success -- m68k -- is a build daemon that deliberately
doesn't run the test suites)

An example of the failures is:

make[3]: Leaving directory '/?PKGBUILDDIR?/build/tests/gpgscm'
Making check in openpgp
make[3]: Entering directory '/?PKGBUILDDIR?/build/tests/openpgp'
LC_ALL=C EXEEXT= PATH=../gpgscm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games srcdir=/?PKGBUILDDIR?/build/../tests/openpgp objdir=/?PKGBUILDDIR?/build GPGSCM_PATH=/?PKGBUILDDIR?/build/../tests/gpgscm:/?PKGBUILDDIR?/build/../tests/openpgp /?PKGBUILDDIR?/build/tests/gpgscm/gpgscm \
  run-tests.scm  version.scm enarmor.scm mds.scm decrypt.scm decrypt-multifile.scm decrypt-dsa.scm decrypt-session-key.scm sigs.scm sigs-dsa.scm encrypt.scm encrypt-multifile.scm encrypt-dsa.scm compression.scm seat.scm clearsig.scm encryptp.scm detach.scm detachm.scm armsigs.scm armencrypt.scm armencryptp.scm signencrypt.scm signencrypt-dsa.scm armsignencrypt.scm armdetach.scm armdetachm.scm genkey1024.scm conventional.scm conventional-mdc.scm multisig.scm verify.scm verify-multifile.scm gpgv-forged-keyring.scm armor.scm import.scm import-revocation-certificate.scm ecc.scm 4gb-packet.scm tofu.scm gpgtar.scm use-exact-key.scm default-key.scm export.scm ssh-import.scm ssh-export.scm quick-key-manipulation.scm key-selection.scm delete-keys.scm gpgconf.scm issue2015.scm issue2346.scm issue2417.scm issue2419.scm issue2929.scm issue2941.scm
("/?PKGBUILDDIR?/build/tools/gpg-connect-agent" --verbose "--agent-program=/?PKGBUILDDIR?/build/agent/gpg-agent|--debug-quick-random" /bye) failed: ("gpg-connect-agent: no running gpg-agent - starting '/?PKGBUILDDIR?/build/agent/gpg-agent|--debug-quick-random'\ngpg-connect-agent: waiting for the agent to come up ... (5s)\ngpg-connect-agent: waiting for the agent to come up ... (4s)\ngpg-connect-agent: waiting for the agent to come up ... (3s)\ngpg-connect-agent: waiting for the agent to come up ... (2s)\ngpg-connect-agent: waiting for the agent to come up ... (1s)\ngpg-connect-agent: can't connect to the agent: File name too long\ngpg-connect-agent: error sending standard options: No agent running\n")
FAIL: setup.scm 
("/?PKGBUILDDIR?/build/tools/gpg-connect-agent" --verbose "--agent-program=/?PKGBUILDDIR?/build/agent/gpg-agent|--debug-quick-random" /bye) failed: ("gpg-connect-agent: no running gpg-agent - starting '/?PKGBUILDDIR?/build/agent/gpg-agent|--debug-quick-random'\ngpg-connect-agent: waiting for the agent to come up ... (5s)\ngpg-connect-agent: waiting for the agent to come up ... (4s)\ngpg-connect-agent: waiting for the agent to come up ... (3s)\ngpg-connect-agent: waiting for the agent to come up ... (2s)\ngpg-connect-agent: waiting for the agent to come up ... (1s)\ngpg-connect-agent: can't connect to the agent: IPC connect call failed\ngpg-connect-agent: error sending standard options: No agent running\n")
FAIL: version.scm
("/?PKGBUILDDIR?/build/tools/gpgtar" --extract --directory=. "/?PKGBUILDDIR?/build/tests/openpgp/gpgscm-20170317T084956-run-tests-UA2ct9/gpgscm-20170317T084956-run-tests-SYHm3M/environment-cache") failed: ("gpgtar: error opening '/?PKGBUILDDIR?/build/tests/openpgp/gpgscm-20170317T084956-run-tests-UA2ct9/gpgscm-20170317T084956-run-tests-SYHm3M/environment-cache': No such file or directory\n")
0: tests.scm:133: (throw (string-append (stringify what) " failed") (:stderr result))
1: defs.scm:435: (call-check `(,(tool 'gpgtar) --extract --directory=. ,(cadr *args*)))

unpacking those first failures, it looks like "gpg-connect-agent" call
is failing, because the agent fails to start the gpg-agent daemon.

in this case, the path for the tests in question is:

  /build/gnupg2-K_EEBD/gnupg2-2.1.19/build/tests/openpgp

which should be short enough if it were used as a homedir, though i
think setup.scm uses an ephemeral homedir -- whose path i haven't
tracked down yet.

the version.scm failure shows:

 gpgtar: error opening
 '/build/gnupg2-K_EEBD/gnupg2-2.1.19/build/tests/openpgp/gpgscm-20170317T084956-run-tests-UA2ct9/gpgscm-20170317T084956-run-tests-SYHm3M/environment-cache':
 No such file or directory

if that's the test path, then it certainly is longer than sun-path.  I
don't understand why there would be two nested directories named
gpgscm-$TIMESTAMP-run-tests-$SUFFIX though.

Doing the build myself in a normal environment *doesn't* have these
failures, but building in a pbuilder/cowbuilder environment *does* show
them.

Any suggestions?

Sorry to keep raising these build process hiccups.  clearly the build
process and test suite are more brittle than we'd like them to be.  are
there checks we should be doing up front in the test process to detect
whether the local system is one we can actually run the tests on?

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

From justus at g10code.com  Fri Mar 17 20:09:59 2017
From: justus at g10code.com (Justus Winter)
Date: Fri, 17 Mar 2017 20:09:59 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <877f3noom5.fsf@alice.fifthhorseman.net>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
Message-ID: <874lyrlny0.fsf@europa.jade-hamburg.de>

Hi :)

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> Hey all--
>
> the debian build daemons are all failing to build 2.1.19-1 (which
> includes many post-release bugfix patches, on top of 2.1.19 itself):
>
> https://buildd.debian.org/status/logs.php?pkg=gnupg2&ver=2.1.19-1&suite=experimental
>
> The failures are in the test suite.
>
> (the one visible success -- m68k -- is a build daemon that deliberately
> doesn't run the test suites)
>
> An example of the failures is:
>
> make[3]: Leaving directory '/?PKGBUILDDIR?/build/tests/gpgscm'
> Making check in openpgp
> make[3]: Entering directory '/?PKGBUILDDIR?/build/tests/openpgp'
> LC_ALL=C EXEEXT= PATH=../gpgscm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games srcdir=/?PKGBUILDDIR?/build/../tests/openpgp objdir=/?PKGBUILDDIR?/build GPGSCM_PATH=/?PKGBUILDDIR?/build/../tests/gpgscm:/?PKGBUILDDIR?/build/../tests/openpgp /?PKGBUILDDIR?/build/tests/gpgscm/gpgscm \
>   run-tests.scm  version.scm enarmor.scm mds.scm decrypt.scm decrypt-multifile.scm decrypt-dsa.scm decrypt-session-key.scm sigs.scm sigs-dsa.scm encrypt.scm encrypt-multifile.scm encrypt-dsa.scm compression.scm seat.scm clearsig.scm encryptp.scm detach.scm detachm.scm armsigs.scm armencrypt.scm armencryptp.scm signencrypt.scm signencrypt-dsa.scm armsignencrypt.scm armdetach.scm armdetachm.scm genkey1024.scm conventional.scm conventional-mdc.scm multisig.scm verify.scm verify-multifile.scm gpgv-forged-keyring.scm armor.scm import.scm import-revocation-certificate.scm ecc.scm 4gb-packet.scm tofu.scm gpgtar.scm use-exact-key.scm default-key.scm export.scm ssh-import.scm ssh-export.scm quick-key-manipulation.scm key-selection.scm delete-keys.scm gpgconf.scm issue2015.scm issue2346.scm issue2417.scm issue2419.scm issue2929.scm issue2941.scm
> ("/?PKGBUILDDIR?/build/tools/gpg-connect-agent" --verbose "--agent-program=/?PKGBUILDDIR?/build/agent/gpg-agent|--debug-quick-random" /bye) failed: ("gpg-connect-agent: no running gpg-agent - starting '/?PKGBUILDDIR?/build/agent/gpg-agent|--debug-quick-random'\ngpg-connect-agent: waiting for the agent to come up ... (5s)\ngpg-connect-agent: waiting for the agent to come up ... (4s)\ngpg-connect-agent: waiting for the agent to come up ... (3s)\ngpg-connect-agent: waiting for the agent to come up ... (2s)\ngpg-connect-agent: waiting for the agent to come up ... (1s)\ngpg-connect-agent: can't connect to the agent: File name too long\ngpg-connect-agent: error sending standard options: No agent running\n")
> FAIL: setup.scm

I bet gpgconf --create-socketdir fails.  Can you arrange make check to
be invoked with verbose=3?

(I'll change this to emit an error of course.)

> the version.scm failure shows:
>
>  gpgtar: error opening
>  '/build/gnupg2-K_EEBD/gnupg2-2.1.19/build/tests/openpgp/gpgscm-20170317T084956-run-tests-UA2ct9/gpgscm-20170317T084956-run-tests-SYHm3M/environment-cache':
>  No such file or directory

That is the tarball that setup.scm failed to create.

> if that's the test path, then it certainly is longer than sun-path.  I
> don't understand why there would be two nested directories named
> gpgscm-$TIMESTAMP-run-tests-$SUFFIX though.

It is not the test path, but we now create temporary directories below
<gnupg-obj>/tests/openpgp, so they are longer now.


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

From dkg at fifthhorseman.net  Sun Mar 19 23:48:59 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 19 Mar 2017 18:48:59 -0400
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <874lyrlny0.fsf@europa.jade-hamburg.de>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
Message-ID: <878to0naqs.fsf@alice.fifthhorseman.net>

Hi Justus--

On Fri 2017-03-17 15:09:59 -0400, Justus Winter wrote:
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>
>> the debian build daemons are all failing to build 2.1.19-1 (which
>> includes many post-release bugfix patches, on top of 2.1.19 itself):
>
> I bet gpgconf --create-socketdir fails.  Can you arrange make check to
> be invoked with verbose=3?

sure, will do.

I'm quite sure that --create-socketdir fails, fwiw.  I just tested this
on a user account which had a deliberately-locked-out /run/user/$(id -u)
directory.  That test failed in the same way.  if you care, trying to
run these commands directly looks like this:

0 abc123 at testsystem:~$ gpgconf --create-socketdir
gpgconf: socketdir is '/home/abc123/.gnupg'
gpgconf: 	general error
gpgconf: 	bad permissions
gpgconf: 	using homedir as fallback
gpgconf: error creating socket directory
gpgconf: fatal error (exit status 1)
1 abc123 at testsystem:~$ GNUPGHOME=$(mktemp -d) gpgconf --create-socketdir
gpgconf: socketdir is '/tmp/tmp.CHRspkaiJX'
gpgconf: 	general error
gpgconf: 	bad permissions
gpgconf: 	using homedir as fallback
gpgconf: error creating socket directory
gpgconf: fatal error (exit status 1)
1 abc123 at testsystem:~$


I believe that the debian build daemons are not guaranteed to have
/run/user/$(id -u) available during the build process.  The build may be
done inside of a chroot, or in some other particularly constrained
container that does not guarantee the presence of /run at all.

So i'm wondering what you think i should do about this.  I see a few
options (i'd be happy to entertain others if you can suggest them):

 a) i can try to update the debian builder infrastructure to always
    supply /run/user/$(id -u) as part of any package build process

 b) the GnuPG source can not require it as a part of the test suite

 c) i can just have the GnuPG package skip the test suite entirely.

 d) i can configure the GnuPG package to deliberately skip the parts of
    the test suite that require an active and present /run/user/$(id -u)


(a) is likely to take quite a long time (if it succeeds at all; i don't
know what kinds of pushback i'm likely to get).  If this is the desired
outcome, it may be a while before a new version of GnuPG is buildable on
debian's infrastructure.

(c) is easiest for me to do, but it sounds like a terrible plan -- the
test suite is a great thing for the GnuPG project, and i like the idea
of running it in as many environments as possible.

So i think that (b) would be my preference, though if there was a
straightforward way to do (d) i'd be willing to accept it as an interim
step.

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

From ag4ve.us at gmail.com  Mon Mar 20 05:06:15 2017
From: ag4ve.us at gmail.com (shawn wilson)
Date: Mon, 20 Mar 2017 00:06:15 -0400
Subject: pam_pkcs11
Message-ID: <CAH_OBic8dusVYWg5STDrs4POZbja_1LX5dGzX2gj6jK6Q_vNJQ@mail.gmail.com>

As I'm looking to implement smartcard local login, it looks like the
pam module doesn't use scdaemon. gpgsm can create my csr (which is
awesome), but opensc doesn't work when gpg-agent is running, so I'm
thinking that neither will pam. Since I use gpg to decrypt smtp/pop
non-interactive (obviously w/ a short-ish ttl set) I kinda want to
keep gpg-agent loaded (and working for a time) when I'm not logged in.
I also don't want to get myself locked out.

What's the advised way of doing this?
Is there any documentation on this (the only thing I've seen is not
using the pkcs11 module and the last time I found this brought up on a
mailing list was 2011)?

Also:
Is there any effort to allowing scdaemon work w/ browser sso and the
like? I see some really old mailing list threads on this and
scd-pkcs11, but as I'm guessing there are fewer eyes on that project,
I'd prefer to stay in the gpg ecosystem if at all possible.


From wk at gnupg.org  Mon Mar 20 10:34:06 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 20 Mar 2017 10:34:06 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <878to0naqs.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Sun, 19 Mar 2017 18:48:59 -0400")
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
Message-ID: <87shm8pa0h.fsf@wheatstone.g10code.de>

On Sun, 19 Mar 2017 23:48, dkg at fifthhorseman.net said:

> 0 abc123 at testsystem:~$ gpgconf --create-socketdir
> gpgconf: socketdir is '/home/abc123/.gnupg'
> gpgconf: 	general error

This is probably a failed stat(2).  That can be expected if the /run
directy etc does not exits ...

An strace would be very helpful to see exactly what is going wrong.

>  d) i can configure the GnuPG package to deliberately skip the parts of

   e) We fix how gpgconf is used.  Given that a GNUGHOME is set the
      regular code to locate the socketdir will use GNUPGHOME which is
      what we need.  Only gpgconf --create-socketdir is picky about
      permissions etc. and tells the user this.  I think this is correct
      behaviour because the user requested to create a socketdir.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170320/08d2716e/attachment.sig>

From crosser at average.org  Mon Mar 20 11:42:08 2017
From: crosser at average.org (Eugene Crosser)
Date: Mon, 20 Mar 2017 11:42:08 +0100
Subject: pam_pkcs11
In-Reply-To: <CAH_OBic8dusVYWg5STDrs4POZbja_1LX5dGzX2gj6jK6Q_vNJQ@mail.gmail.com>
References: <CAH_OBic8dusVYWg5STDrs4POZbja_1LX5dGzX2gj6jK6Q_vNJQ@mail.gmail.com>
Message-ID: <93e26782-2422-93a3-128e-ef700b0e97f3@average.org>

On 03/20/2017 05:06 AM, shawn wilson wrote:

> As I'm looking to implement smartcard local login, it looks like the
> pam module doesn't use scdaemon. gpgsm can create my csr (which is
> awesome), but opensc doesn't work when gpg-agent is running, so I'm
> thinking that neither will pam.

I wonder if it has something to do with this problem?

https://bugs.gnupg.org/gnupg/issue2053

I use Yubikey for local logins (not via its openpgp function), and I
have to run patched scdaemon in order to keep the token reachable by the
processes other than gnupg.

Eugene

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170320/09b970cf/attachment.sig>

From ag4ve.us at gmail.com  Mon Mar 20 13:37:37 2017
From: ag4ve.us at gmail.com (shawn wilson)
Date: Mon, 20 Mar 2017 08:37:37 -0400
Subject: pam_pkcs11
In-Reply-To: <93e26782-2422-93a3-128e-ef700b0e97f3@average.org>
References: <CAH_OBic8dusVYWg5STDrs4POZbja_1LX5dGzX2gj6jK6Q_vNJQ@mail.gmail.com>
 <93e26782-2422-93a3-128e-ef700b0e97f3@average.org>
Message-ID: <CAH_OBid8LAOD6uGnm0G=NS_GXHeV_-4fmDsbNr+kc=-ZjKB90w@mail.gmail.com>

On Mar 20, 2017 08:26, "Eugene Crosser" <crosser at average.org> wrote:

On 03/20/2017 05:06 AM, shawn wilson wrote:

> As I'm looking to implement smartcard local login, it looks like the
> pam module doesn't use scdaemon. gpgsm can create my csr (which is
> awesome), but opensc doesn't work when gpg-agent is running, so I'm
> thinking that neither will pam.

I wonder if it has something to do with this problem?

https://bugs.gnupg.org/gnupg/issue2053

I use Yubikey for local logins (not via its openpgp function), and I
have to run patched scdaemon in order to keep the token reachable by the
processes other than gnupg.

Eugene

That was what I was referring to wrt pkcs11_scd (he made a full scdaemon
replacement - possibly more stable / better)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170320/2052e9b8/attachment.html>

From dkg at fifthhorseman.net  Mon Mar 20 16:18:46 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 20 Mar 2017 11:18:46 -0400
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87shm8pa0h.fsf@wheatstone.g10code.de>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
Message-ID: <8760j4m0x5.fsf@alice.fifthhorseman.net>

On Mon 2017-03-20 05:34:06 -0400, Werner Koch wrote:
> On Sun, 19 Mar 2017 23:48, dkg at fifthhorseman.net said:
>
>> 0 abc123 at testsystem:~$ gpgconf --create-socketdir
>> gpgconf: socketdir is '/home/abc123/.gnupg'
>> gpgconf: 	general error
>
> This is probably a failed stat(2).  That can be expected if the /run
> directy etc does not exits ...
>
> An strace would be very helpful to see exactly what is going wrong.

Attached is an strace of:

  GNUPGHOME=$(mktemp -d) gpgconf --create-socketdir

>>  d) i can configure the GnuPG package to deliberately skip the parts of
>
>    e) We fix how gpgconf is used.  Given that a GNUGHOME is set the
>       regular code to locate the socketdir will use GNUPGHOME which is
>       what we need.  Only gpgconf --create-socketdir is picky about
>       permissions etc. and tells the user this.  I think this is correct
>       behaviour because the user requested to create a socketdir.

Thanks for this suggestion!  I'm hoping that the test suite would work
in either situation:

 a) where the build path is short enough, or
 b) where /run/user/$(id -u) is present and writable

and only fail when both conditions are not met.

I've tested it in a situation where the build path is insanely long, but
where /run/user/$(id -u) is available, and the test suite completes
fine.

So it's just the other way around that causes the tests to fail.  can
you suggest a patch?

thanks for the followup,

    --dkg

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gpgconf.strace
URL: </pipermail/attachments/20170320/8f97873d/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170320/8f97873d/attachment.sig>

From justus at g10code.com  Mon Mar 20 17:04:39 2017
From: justus at g10code.com (Justus Winter)
Date: Mon, 20 Mar 2017 17:04:39 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <8760j4m0x5.fsf@alice.fifthhorseman.net>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
Message-ID: <87y3w07x48.fsf@europa.jade-hamburg.de>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> Thanks for this suggestion!  I'm hoping that the test suite would work
> in either situation:
>
>  a) where the build path is short enough, or

There is no such thing as a short enough build path.  The days of the
test suite using obj/tests/openpgp as GNUPGHOME are long gone.  We are
creating one GNUPGHOME per test, sometimes a test creates ephemeral home
diretories on its own.

> 14661 10:21:44.762330 stat("/run/user/1003", {st_mode=S_IFDIR|000, st_size=100, ...}) = 0 <0.000020>

/run/user/1003 is not writable.


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

From dkg at fifthhorseman.net  Mon Mar 20 19:10:40 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 20 Mar 2017 14:10:40 -0400
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87y3w07x48.fsf@europa.jade-hamburg.de>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
Message-ID: <87r31rbyzj.fsf@alice.fifthhorseman.net>

On Mon 2017-03-20 12:04:39 -0400, Justus Winter wrote:
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>
>> Thanks for this suggestion!  I'm hoping that the test suite would work
>> in either situation:
>>
>>  a) where the build path is short enough, or
>
> There is no such thing as a short enough build path.  The days of the
> test suite using obj/tests/openpgp as GNUPGHOME are long gone.  We are
> creating one GNUPGHOME per test, sometimes a test creates ephemeral home
> diretories on its own.
>
>> 14661 10:21:44.762330 stat("/run/user/1003", {st_mode=S_IFDIR|000, st_size=100, ...}) = 0 <0.000020>
>
> /run/user/1003 is not writable.

yes, i know.  Some build daemons, which use extremely minimalist chroots
that don't even have /run at all, let alone a writable /run/user/1003 or
whatever.  Should the test suites fail in those cases?  if so, what
do you think i should do about getting newer versions of GnuPG in
debian?  If not, what needs to change?

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

From dkg at fifthhorseman.net  Mon Mar 20 20:07:59 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 20 Mar 2017 15:07:59 -0400
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <878to0naqs.fsf@alice.fifthhorseman.net>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
Message-ID: <87mvcfbwc0.fsf@alice.fifthhorseman.net>

On Sun 2017-03-19 18:48:59 -0400, Daniel Kahn Gillmor wrote:
> On Fri 2017-03-17 15:09:59 -0400, Justus Winter wrote:
>> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>> I bet gpgconf --create-socketdir fails.  Can you arrange make check to
>> be invoked with verbose=3?
>
> sure, will do.

2.1.19-2 includes the latest patches from the master branch, and has
verbose=3 set in the test suite.  You can see the failures and the logs
on different architectures linked from here:

  https://buildd.debian.org/status/logs.php?pkg=gnupg2&ver=2.1.19-2&suite=experimental

Let me know if you've got suggestions for how to proceed.

Thanks,

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

From quae at daurnimator.com  Tue Mar 21 00:11:23 2017
From: quae at daurnimator.com (Daurnimator)
Date: Tue, 21 Mar 2017 10:11:23 +1100
Subject: pam_pkcs11
In-Reply-To: <CAH_OBid8LAOD6uGnm0G=NS_GXHeV_-4fmDsbNr+kc=-ZjKB90w@mail.gmail.com>
References: <CAH_OBic8dusVYWg5STDrs4POZbja_1LX5dGzX2gj6jK6Q_vNJQ@mail.gmail.com>
 <93e26782-2422-93a3-128e-ef700b0e97f3@average.org>
 <CAH_OBid8LAOD6uGnm0G=NS_GXHeV_-4fmDsbNr+kc=-ZjKB90w@mail.gmail.com>
Message-ID: <CAEnbY+cNTn154mxybyfpn-LCNgYkzgTXs=g=rQtGTg3QAsxygQ@mail.gmail.com>

On 20 March 2017 at 23:37, shawn wilson <ag4ve.us at gmail.com> wrote:
> On Mar 20, 2017 08:26, "Eugene Crosser" <crosser at average.org> wrote:
> On 03/20/2017 05:06 AM, shawn wilson wrote:
>
>> As I'm looking to implement smartcard local login, it looks like the
>> pam module doesn't use scdaemon. gpgsm can create my csr (which is
>> awesome), but opensc doesn't work when gpg-agent is running, so I'm
>> thinking that neither will pam.
>
> I wonder if it has something to do with this problem?
>
> https://bugs.gnupg.org/gnupg/issue2053
>
> I use Yubikey for local logins (not via its openpgp function), and I
> have to run patched scdaemon in order to keep the token reachable by the
> processes other than gnupg.
>
> Eugene
>
> That was what I was referring to wrt pkcs11_scd (he made a full scdaemon
> replacement - possibly more stable / better)

This seems like something that could be fixed with my request about
decoupling gpg-agent from scdaemon.
http://gnupg-devel.gnupg.narkive.com/iZ6cvOeG/way-to-use-existing-scdaemon


From gniibe at fsij.org  Tue Mar 21 00:15:47 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 21 Mar 2017 08:15:47 +0900
Subject: pam_pkcs11
In-Reply-To: <CAH_OBic8dusVYWg5STDrs4POZbja_1LX5dGzX2gj6jK6Q_vNJQ@mail.gmail.com>
References: <CAH_OBic8dusVYWg5STDrs4POZbja_1LX5dGzX2gj6jK6Q_vNJQ@mail.gmail.com>
Message-ID: <87h92n8rq4.fsf@fsij.org>

I maintain Scute and Poldi in Debian.  I don't say I maintain them in
upstream.  It would be worth a try.

P.S.
My position for PKCS#11 is not so positive.  Historically speaking, it
worked as a kind of buzzword to invite proprietary software (drivers,
implementations, utilities).  Admittedly, it would be good than nothing,
though.
-- 


From ag4ve.us at gmail.com  Tue Mar 21 01:13:15 2017
From: ag4ve.us at gmail.com (shawn wilson)
Date: Mon, 20 Mar 2017 20:13:15 -0400
Subject: pam_pkcs11
In-Reply-To: <87h92n8rq4.fsf@fsij.org>
References: <CAH_OBic8dusVYWg5STDrs4POZbja_1LX5dGzX2gj6jK6Q_vNJQ@mail.gmail.com>
 <87h92n8rq4.fsf@fsij.org>
Message-ID: <CAH_OBifKpcF-ve=AbkXLcDogFJS_3D_7-6frXOQC5v+maj9F3Q@mail.gmail.com>

On Mar 20, 2017 19:15, "NIIBE Yutaka" <gniibe at fsij.org> wrote:

I maintain Scute and Poldi in Debian.  I don't say I maintain them in
upstream.  It would be worth a try.

P.S.
My position for PKCS#11 is not so positive.  Historically speaking, it
worked as a kind of buzzword to invite proprietary software (drivers,
implementations, utilities).  Admittedly, it would be good than nothing,
though.
--


And I'd prefer if I could just associate a fpr with a user and have
something generate a challenge for me to decrypt with my key. But there's
nothing in pam for that...

Obviously browser sso also requires a cert, so there's that too. If gpg is
able to do it all, I'd be thrilled. If it can't, I'll be trying to work
around it where it falls short.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170320/55678bd3/attachment.html>

From ag4ve.us at gmail.com  Tue Mar 21 01:18:21 2017
From: ag4ve.us at gmail.com (shawn wilson)
Date: Mon, 20 Mar 2017 20:18:21 -0400
Subject: pam_pkcs11
In-Reply-To: <CAH_OBifKpcF-ve=AbkXLcDogFJS_3D_7-6frXOQC5v+maj9F3Q@mail.gmail.com>
References: <CAH_OBic8dusVYWg5STDrs4POZbja_1LX5dGzX2gj6jK6Q_vNJQ@mail.gmail.com>
 <87h92n8rq4.fsf@fsij.org>
 <CAH_OBifKpcF-ve=AbkXLcDogFJS_3D_7-6frXOQC5v+maj9F3Q@mail.gmail.com>
Message-ID: <CAH_OBicPyB3YWP5hXCfX+=xpjpdHNSXbK=_e5CjNm9WYBJo8sQ@mail.gmail.com>

On Mar 20, 2017 20:13, "shawn wilson" <ag4ve.us at gmail.com> wrote:



On Mar 20, 2017 19:15, "NIIBE Yutaka" <gniibe at fsij.org> wrote:

I maintain Scute and Poldi in Debian.  I don't say I maintain them in
upstream.  It would be worth a try.

Oh and I'll check out those projects more thoroughly when I get home
(primary laptop being Fedora, but...). I saw poldi, but Idr why I didn't
like it - I'll look again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170320/427a4f1f/attachment.html>

From justus at g10code.com  Tue Mar 21 10:24:42 2017
From: justus at g10code.com (Justus Winter)
Date: Tue, 21 Mar 2017 10:24:42 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87r31rbyzj.fsf@alice.fifthhorseman.net>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
Message-ID: <8737e76kyt.fsf@europa.jade-hamburg.de>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On Mon 2017-03-20 12:04:39 -0400, Justus Winter wrote:
>> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>>
>>> Thanks for this suggestion!  I'm hoping that the test suite would work
>>> in either situation:
>>>
>>>  a) where the build path is short enough, or
>>
>> There is no such thing as a short enough build path.  The days of the
>> test suite using obj/tests/openpgp as GNUPGHOME are long gone.  We are
>> creating one GNUPGHOME per test, sometimes a test creates ephemeral home
>> diretories on its own.
>>
>>> 14661 10:21:44.762330 stat("/run/user/1003", {st_mode=S_IFDIR|000, st_size=100, ...}) = 0 <0.000020>
>>
>> /run/user/1003 is not writable.
>
> yes, i know.  Some build daemons, which use extremely minimalist chroots
> that don't even have /run at all, let alone a writable /run/user/1003 or
> whatever.  Should the test suites fail in those cases?  if so, what
> do you think i should do about getting newer versions of GnuPG in
> debian?  If not, what needs to change?

The test suite now uses longer gnupghomes.  This is a deliberate choice
I made.  Let me clarify my position.

First of all, I must stress that this is not a bug in the test suite.
The documentation does not state anywhere that gnupghomes must be "short
enough" (i.e. strlen (gnupghome) <= sizeof sun_path - 1 ('/') - max
strlen of any socket gpg uses - 1 ('\0')).  Furthermore, GnuPG does not
enforce such a restriction.  So until this changes, I consider the paths
the test suite uses slightly odd but valid.

We are not going to paper over any issues in GnuPG just to make the
tests happy.  Doing so defeats the purpose of testing the software, and
merely hides the real problem, making it pop up at our downstream users.

(E.g. https://notmuchmail.org/pipermail/notmuch/2017/024148.html)

GnuPG 2.x unreasonably restricting the length of gnupghomes, either by
documenting it or simply by failing, is a regression from GnuPG 1.4.

The test suite now relies on 'gpgconf --create-socketdir' to make
arbitrary gnupghomes work.

I believe that the problem of restricting the length of gnupghomes is
orthogonal to what 'gpgconf --create-socketdir' solves (even though
indeed separate socket directories solve it as a side effect), but I
have been unable to convince Werner of that.  So now we have to make
sure that 'gpgconf --create-socketdir' actually works everywhere and
robustly solves this problem too.


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

From kristian.fiskerstrand at sumptuouscapital.com  Tue Mar 21 10:52:58 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Tue, 21 Mar 2017 10:52:58 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <8737e76kyt.fsf@europa.jade-hamburg.de>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
Message-ID: <b32442b3-fe28-f6d2-2e97-29444c758b6b@sumptuouscapital.com>

On 03/21/2017 10:24 AM, Justus Winter wrote:
> The test suite now relies on 'gpgconf --create-socketdir' to make
> arbitrary gnupghomes work.

Seems like this introduces a requirement on the systemd behavior with
/run/user/${UID}/gnupg that may or may not be present in other systems?

> 
> I believe that the problem of restricting the length of gnupghomes is
> orthogonal to what 'gpgconf --create-socketdir' solves (even though
> indeed separate socket directories solve it as a side effect), but I
> have been unable to convince Werner of that.  So now we have to make
> sure that 'gpgconf --create-socketdir' actually works everywhere and
> robustly solves this problem too.


-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"Be a yardstick of quality. Some people aren't used to an environment
where excellence is expected."
(Steve Jobs)

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

From wk at gnupg.org  Tue Mar 21 10:53:13 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 21 Mar 2017 10:53:13 +0100
Subject: please include --hidden-recipients in gpgme
In-Reply-To: <87r32mt0l3.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Sat, 25 Feb 2017 16:36:08 -0500")
References: <87r32mt0l3.fsf@alice.fifthhorseman.net>
Message-ID: <877f3jlzw6.fsf@wheatstone.g10code.de>

On Sat, 25 Feb 2017 22:36, dkg at fifthhorseman.net said:

> But there appears to be no way to include a list of hidden recipients
> (in the sense of gpg's --hidden-recipient option).

I looked at this several times in the past but there is no easy
solution.  A function to set "processing" flags to a key object might do
the job but this is has the possible problem that those processing flags
would then always be used by all context working on that key object.

> I considered the possibility of adding a flag that forces all recipients
> to be hidden, but i think that --throw-keyids is too coarse of a hammer.

I implemented a THROW_KEYIDS flag anyway because it is easy enough and
might be useful for some applications.

> headers (though it is important to be able to hide the keyIDs of the
> recipients who are listed in Bcc during message composition).

That still gives the count of BCCed recipients and thus I think it is
better to use separate encryption for BCC mails.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170321/1badfa95/attachment.sig>

From wk at gnupg.org  Tue Mar 21 11:33:33 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 21 Mar 2017 11:33:33 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <8737e76kyt.fsf@europa.jade-hamburg.de> (Justus Winter's message
 of "Tue, 21 Mar 2017 10:24:42 +0100")
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
Message-ID: <87zigely0y.fsf@wheatstone.g10code.de>

On Tue, 21 Mar 2017 10:24, justus at g10code.com said:

> The test suite now uses longer gnupghomes.  This is a deliberate choice

I doubt that the need for long names for gnupghome just for testing is
justified.  In fact it is important to run test on a _local_ file
system.  This is the reason why switched to /var/run.  Now, when we
encountered problems creating a gnupg socket directory below /var/run we
should do the sensible thing, which is to fallback to standard Unix
behavior of having /tmp mounted locally.

> I believe that the problem of restricting the length of gnupghomes is
> orthogonal to what 'gpgconf --create-socketdir' solves (even though

We are using sockets for communication between the parts of GnuPG since
2002.  That are 15 years with only little trouble on some platforms.
The limited length of a socket file has never been a problem in
practice.  Well, things sometimes didn't build out of the box, but
moving the build to tmp has always been an option which has been in
active use for more than a decade, for example on some AIX
installations.

Note also that even GnuPG 1.x versions made use of sockets: For the EGD
and the Quintuple-agent (passphrase caching before gnupg 2.0)

ssh-agent also uses sockets without practical problems.  Bind and other
daemons have been using sockets for control operations for even longer
than ssh exists.  Stevens has enough example on how to use sockets and
warns about the limitations.  ustar, the only common tar standard, limit
the lengths of file names as well.

Please come up with a practical fix.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170321/f9ff1abd/attachment.sig>

From justus at g10code.com  Tue Mar 21 13:22:41 2017
From: justus at g10code.com (Justus Winter)
Date: Tue, 21 Mar 2017 13:22:41 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87zigely0y.fsf@wheatstone.g10code.de>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
Message-ID: <87zige6cq6.fsf@europa.jade-hamburg.de>

Werner Koch <wk at gnupg.org> writes:

> Please come up with a practical fix.

Fixed in 06f1f163e96f1039304fd3cf565cf9de1ca45849.


In the interest of moving the discussion forward, can we now agree on
the fact that 'gpgconf --create-socketdir' is not a sufficient solution
to the problem of overly long socket names?


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

From wk at gnupg.org  Tue Mar 21 19:40:08 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 21 Mar 2017 19:40:08 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87zige6cq6.fsf@europa.jade-hamburg.de> (Justus Winter's message
 of "Tue, 21 Mar 2017 13:22:41 +0100")
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
Message-ID: <87efxqlbhz.fsf@wheatstone.g10code.de>

On Tue, 21 Mar 2017 13:22, justus at g10code.com said:

> In the interest of moving the discussion forward, can we now agree on
> the fact that 'gpgconf --create-socketdir' is not a sufficient solution
> to the problem of overly long socket names?

Nope.  See also my comments on bug 2964.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170321/19dbcadd/attachment.sig>

From dkg at fifthhorseman.net  Tue Mar 21 21:46:56 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 21 Mar 2017 16:46:56 -0400
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87zige6cq6.fsf@europa.jade-hamburg.de>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
Message-ID: <87a88e9x33.fsf@alice.fifthhorseman.net>

On Tue 2017-03-21 08:22:41 -0400, Justus Winter wrote:
> Werner Koch <wk at gnupg.org> writes:
>
>> Please come up with a practical fix.
>
> Fixed in 06f1f163e96f1039304fd3cf565cf9de1ca45849.

thanks for this, Justus!  2.1.19-3 (which includes many of the
post-release patches after 2.1.19) is now building again on the debian
build daemons:

  https://buildd.debian.org/status/logs.php?pkg=gnupg2&ver=2.1.19-3&suite=experimental

I'll let that settle in for a day or two and then consider uploading it
to unstable, since it fixes several bugs from 2.1.18.

> In the interest of moving the discussion forward, can we now agree on
> the fact that 'gpgconf --create-socketdir' is not a sufficient solution
> to the problem of overly long socket names?

So we have a few different situations that make predictable socket
locations troubling in a universal sense.  Every possible candidate
location has at least one problem:

 a) $GNUPGHOME/S.gpg-agent : this might have a particularly long name,
    one that exceeds sun_path length.

 b) $GNUPGHOME/S.gpg-agent : this might be on a remote filesystem or a
    filesystem that cannot support unix-domain sockets (e.g. fat32 on a
    thumbdrive)

 c) anywhere under /tmp : this is not a predictable location that is
    safe to use, and inherently can't be on most systems where /tmp is
    shared and world-writable.

 d) /run/user/$(id -u)/gnupg/S.gpg-agent : We know that this user-owned
    directory isn't guaranteed to be available in every environment,
    including (sadly) chroots that are used by the debian build
    infrastructure.

Justus's clever use of relative paths resolves issue (a) and avoids the
problems associated with (c) and (d), but falls afoul of (b).

Where /run/user exists, using /run/user/$(id -u)/gnupg resolves issues
a, b, and c.  But as (d) points out it doesn't exist everywhere.

If we combine Justus's use of relative paths with the use of
/run/user/$(id -u)/gnupg where possible, then the only corner case we
cannot handle is:

 * $GNUPGHOME is on a filesystem that cannot support unix-domain
   sockets, and /run/user does not exist.

If anyone has a suggestion for how to handle this corner case, i'm all
ears.

        --dkg


From kristian.fiskerstrand at sumptuouscapital.com  Tue Mar 21 21:52:32 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Tue, 21 Mar 2017 21:52:32 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87a88e9x33.fsf@alice.fifthhorseman.net>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
Message-ID: <9478ab1e-0173-5649-5f73-12b29cd9f5f1@sumptuouscapital.com>

On 03/21/2017 09:46 PM, Daniel Kahn Gillmor wrote:
> If anyone has a suggestion for how to handle this corner case, i'm all
> ears.

Throw an error and point to part of documentation for how to use
%Assuan% socket= redirection?

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Nosce te ipsum!
Know thyself!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170321/469cf28a/attachment.sig>

From dkg at fifthhorseman.net  Tue Mar 21 22:06:39 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 21 Mar 2017 17:06:39 -0400
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <9478ab1e-0173-5649-5f73-12b29cd9f5f1@sumptuouscapital.com>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9478ab1e-0173-5649-5f73-12b29cd9f5f1@sumptuouscapital.com>
Message-ID: <874lym9w68.fsf@alice.fifthhorseman.net>

On Tue 2017-03-21 16:52:32 -0400, Kristian Fiskerstrand wrote:
> On 03/21/2017 09:46 PM, Daniel Kahn Gillmor wrote:
>> If anyone has a suggestion for how to handle this corner case, i'm all
>> ears.
>
> Throw an error and point to part of documentation for how to use
> %Assuan% socket= redirection?

When would this happen?  During an attempt to start up such a daemon?
During an attempt to communicate with such a daemon?  I agree that
explicit error messages with suggestions for how to help are better than
failing cryptically, but we need to think about where the error comes
from and how it gets to the user.

     --dkg


From peter at digitalbrains.com  Tue Mar 21 22:28:36 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 21 Mar 2017 22:28:36 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87a88e9x33.fsf@alice.fifthhorseman.net>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
Message-ID: <9d504743-4a19-19d4-2d4b-95f685e4a6f8@digitalbrains.com>

I hope my comments help with the perspective. If not, never mind.

On 21/03/17 21:46, Daniel Kahn Gillmor wrote:
>  a) $GNUPGHOME/S.gpg-agent : this might have a particularly long name,
>     one that exceeds sun_path length.

Has this actually ever been an issue for someone? I understand the
problem can be artificially induced, but has anyone ever reported
hitting the limit accidentally?

>  c) anywhere under /tmp : this is not a predictable location that is
>     safe to use, and inherently can't be on most systems where /tmp is
>     shared and world-writable.

What's the problem when it is a sticky directory and you create a
directory with mode 0700 under it? I think OpenSSH's agent uses it.

> If anyone has a suggestion for how to handle this corner case, i'm all
> ears.

If /tmp is safe after all, that seems like a good alternative.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

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

From wk at gnupg.org  Tue Mar 21 22:37:37 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 21 Mar 2017 22:37:37 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <9478ab1e-0173-5649-5f73-12b29cd9f5f1@sumptuouscapital.com>
 (Kristian Fiskerstrand's message of "Tue, 21 Mar 2017 21:52:32 +0100")
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9478ab1e-0173-5649-5f73-12b29cd9f5f1@sumptuouscapital.com>
Message-ID: <87var2jopq.fsf@wheatstone.g10code.de>

On Tue, 21 Mar 2017 21:52, kristian.fiskerstrand at sumptuouscapital.com
said:

> Throw an error and point to part of documentation for how to use
> %Assuan% socket= redirection?

I like to remove this hack in 2.3 - it requires too much admin work and
thus it is easier to simply create /run/user, for example in rc.local:

--8<---------------cut here---------------start------------->8---
[ ! -d /run/user ] && mkdir /run/user
awk -F: </etc/passwd '$3 >= 1000 && $3 < 65000 {print $3}' \
  | ( while read uid rest; do
        if [ ! -d "/run/user/$uid" ]; then
	  mkdir /run/user/$uid
	  chown $uid /run/user/$uid
	  chmod 700 /run/user/$uid
	fi
      done )
--8<---------------cut here---------------end--------------->8---

BTW, the use of /tmp is just fine as long as you create a sub directory.
This is how X has always worked.  In fact, the test suite does just
this.

Note also that the socket file system problem exists on many NFS or
Samba mounted home directories.  Not just on FAT file systems.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170321/b921f171/attachment.sig>

From dkg at fifthhorseman.net  Tue Mar 21 22:43:49 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 21 Mar 2017 17:43:49 -0400
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <9d504743-4a19-19d4-2d4b-95f685e4a6f8@digitalbrains.com>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9d504743-4a19-19d4-2d4b-95f685e4a6f8@digitalbrains.com>
Message-ID: <87shm68fvu.fsf@alice.fifthhorseman.net>

On Tue 2017-03-21 17:28:36 -0400, Peter Lebbing wrote:
> I hope my comments help with the perspective. If not, never mind.
>
> On 21/03/17 21:46, Daniel Kahn Gillmor wrote:
>>  a) $GNUPGHOME/S.gpg-agent : this might have a particularly long name,
>>     one that exceeds sun_path length.
>
> Has this actually ever been an issue for someone? I understand the
> problem can be artificially induced, but has anyone ever reported
> hitting the limit accidentally?

Yes.  I've seen the problem get hit repeatedly by software that depends
on GnuPG, and has a test suite that happens to be reasonably scoped.
Usually GnuPG itself is masked by one or two other layers of software
(e.g. gpgme, perl's GnuPG::Interface, etc) so even extracting the error
messages in a sane way isn't straightforward.  it just looks like
arbitrary test suite failures for someone who builds their software in
/home/users/mary/dayjob/software/open-source/libfoo-3.22, but no
failures for the developer who builds in /home/amy/src/foo.

It's a real concern, and this kind of idiosyncratic failure frustrates
developers who are trying to depend on GnuPG.

>>  c) anywhere under /tmp : this is not a predictable location that is
>>     safe to use, and inherently can't be on most systems where /tmp is
>>     shared and world-writable.
>
> What's the problem when it is a sticky directory and you create a
> directory with mode 0700 under it? I think OpenSSH's agent uses it.

The key word in (c) is "predictable".

The problem is communicating the location of the socket to use to the
clients.  If i'm a client using some particular GNUPGHOME, how do i find
the sockets of the associated agent?  We've tried the environment
variable approach (which OpenSSH's ssh-agent uses) and found a series of
problems with that -- how do you communicate that variable to each
client if you only start the agent later?

Also, gpg 2.1.x has a one-gpg-agent-per-GNUPGHOME model (and
one-dirmngr-per-GNUPGHOME) today, thanks to the "standard-socket".  I
don't know whether having two gpg-agents or two dirmngrs interacting
with the same GNUPGHOME will run into contention.

> If /tmp is safe after all, that seems like a good alternative.

how do you solve the predictability problem?

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

From dkg at fifthhorseman.net  Wed Mar 22 05:21:54 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 22 Mar 2017 00:21:54 -0400
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87var2jopq.fsf@wheatstone.g10code.de>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9478ab1e-0173-5649-5f73-12b29cd9f5f1@sumptuouscapital.com>
 <87var2jopq.fsf@wheatstone.g10code.de>
Message-ID: <87tw6m6ivx.fsf@alice.fifthhorseman.net>

On Tue 2017-03-21 17:37:37 -0400, Werner Koch wrote:
> On Tue, 21 Mar 2017 21:52, kristian.fiskerstrand at sumptuouscapital.com
> said:
>
>> Throw an error and point to part of documentation for how to use
>> %Assuan% socket= redirection?
>
> I like to remove this hack in 2.3 - it requires too much admin work and
> thus it is easier to simply create /run/user, for example in rc.local:
>
> --8<---------------cut here---------------start------------->8---
> [ ! -d /run/user ] && mkdir /run/user
> awk -F: </etc/passwd '$3 >= 1000 && $3 < 65000 {print $3}' \
>   | ( while read uid rest; do
>         if [ ! -d "/run/user/$uid" ]; then
> 	  mkdir /run/user/$uid
> 	  chown $uid /run/user/$uid
> 	  chmod 700 /run/user/$uid
> 	fi
>       done )
> --8<---------------cut here---------------end--------------->8---

Putting this in rc.local won't fix the situation where there's a chroot
(which is the case for many debian build daemons, and probably other
targeted/minimalist build environments)

> BTW, the use of /tmp is just fine as long as you create a sub directory.
> This is how X has always worked.  In fact, the test suite does just
> this.

The trouble with /tmp is figuring out which directory to use.  If
$GNUPGHOME itself is in /tmp, that's one thing -- the env var itself
points to a location that needs to be owned by the user.

But if GNUPGHOME is unset, or if it is not itself in /tmp, how are the
daemons and their client supposed to agree on a rendevous point in /tmp
?

> Note also that the socket file system problem exists on many NFS or
> Samba mounted home directories.  Not just on FAT file systems.

sure, that's what i described as point (b):

>>>  b) $GNUPGHOME/S.gpg-agent : this might be on a remote filesystem or a
>>>     filesystem that cannot support unix-domain sockets (e.g. fat32 on a
>>>     thumbdrive)

Regards,

        --dkg


From wk at gnupg.org  Wed Mar 22 08:02:42 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 22 Mar 2017 08:02:42 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87tw6m6ivx.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 22 Mar 2017 00:21:54 -0400")
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9478ab1e-0173-5649-5f73-12b29cd9f5f1@sumptuouscapital.com>
 <87var2jopq.fsf@wheatstone.g10code.de>
 <87tw6m6ivx.fsf@alice.fifthhorseman.net>
Message-ID: <87fui5kd4d.fsf@wheatstone.g10code.de>

On Wed, 22 Mar 2017 05:21, dkg at fifthhorseman.net said:

> Putting this in rc.local won't fix the situation where there's a chroot
> (which is the case for many debian build daemons, and probably other

Setting up a chroot or jail is a complex operation and adding something
to rc.local is not different than to make sure the required devices and
tools are all accessible.  Think /dev/random, /etc/hosts etc.

> The trouble with /tmp is figuring out which directory to use.  If
> $GNUPGHOME itself is in /tmp, that's one thing -- the env var itself

That is right.  However, we are talking about GnuPG's test suite, aren't
we?

For other software using

  GNUPGHOME=/tmp/$mydir gpg-agent --daemon testshell

is suitable approach.



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170322/c46b1697/attachment.sig>

From wk at gnupg.org  Wed Mar 22 08:04:57 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 22 Mar 2017 08:04:57 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87shm68fvu.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 21 Mar 2017 17:43:49 -0400")
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9d504743-4a19-19d4-2d4b-95f685e4a6f8@digitalbrains.com>
 <87shm68fvu.fsf@alice.fifthhorseman.net>
Message-ID: <87bmstkd0m.fsf@wheatstone.g10code.de>

On Tue, 21 Mar 2017 22:43, dkg at fifthhorseman.net said:

> Also, gpg 2.1.x has a one-gpg-agent-per-GNUPGHOME model (and
> one-dirmngr-per-GNUPGHOME) today, thanks to the "standard-socket".  I

That has actually been the case since 2.0.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170322/bf8d941f/attachment.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Mar 22 11:23:13 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 22 Mar 2017 11:23:13 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <9d504743-4a19-19d4-2d4b-95f685e4a6f8@digitalbrains.com>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9d504743-4a19-19d4-2d4b-95f685e4a6f8@digitalbrains.com>
Message-ID: <81a2ee66-c2ac-2a9a-1018-3994ebe41f3b@sumptuouscapital.com>

On 03/21/2017 10:28 PM, Peter Lebbing wrote:
> On 21/03/17 21:46, Daniel Kahn Gillmor wrote:
>>  a) $GNUPGHOME/S.gpg-agent : this might have a particularly long name,
>>     one that exceeds sun_path length.
> Has this actually ever been an issue for someone? I understand the
> problem can be artificially induced, but has anyone ever reported
> hitting the limit accidentally?
> 

We've had reported build issues due to this in Gentoo and chosen to
reduce the size of certain directory namings to mitigate it in the
default case.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Ne nuntium necare
Don't kill the messenger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170322/923756eb/attachment.sig>

From peter at digitalbrains.com  Wed Mar 22 13:15:57 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 22 Mar 2017 13:15:57 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87shm68fvu.fsf@alice.fifthhorseman.net>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9d504743-4a19-19d4-2d4b-95f685e4a6f8@digitalbrains.com>
 <87shm68fvu.fsf@alice.fifthhorseman.net>
Message-ID: <ce69fd80-4528-4a7e-a7af-8c93edcaaa0f@digitalbrains.com>

On 21/03/17 22:43, Daniel Kahn Gillmor wrote:
> It's a real concern, and this kind of idiosyncratic failure frustrates
> developers who are trying to depend on GnuPG.

Clear as rain. I didn't know that.

> The key word in (c) is "predictable".

Isn't this conflating two separate cases?

If the software being built in
/home/users/mary/dayjob/software/open-source/libfoo-3.22 wants to share
the GnuPG installation of mary, it will not set a GNUPGHOME itself and
look for sockets in predictable locations, like /run/user, for the agent
running for user mary. GNUPGHOME is then just as short as usual for mary.

If the software being built in
/home/users/mary/dayjob/software/open-source/libfoo-3.22 wants its own
GnuPG installation, with say specific .conf files and keyrings, it can
set a GNUPGHOME to /tmp/foo-gpg-home-Na1FYAjrLo and create a socket
there, fixing a) and b).

In fact, in general I wonder if it is a good idea to even look in the
predictable places at all when an explicit GNUPGHOME has been set. It
could then find an agent running with a different GNUPGHOME, and
encounter a completely different set of private keys (and different
settings in gpg-agent.conf) from what it has in its own GNUPGHOME.

> The problem is communicating the location of the socket to use to the
> clients.  If i'm a client using some particular GNUPGHOME, how do i find
> the sockets of the associated agent?  We've tried the environment
> variable approach (which OpenSSH's ssh-agent uses) and found a series of
> problems with that -- how do you communicate that variable to each
> client if you only start the agent later?

Why is it a good idea to run a single agent for multiple GNUPGHOMEs?

If it's not a good idea to run a single agent for multiple GNUPGHOMEs,
couldn't you just have a regular file in the GNUPGHOME that points out
where to find the socket?[1] It could automatically be created by an
agent that started without finding that file. There's a bit of raciness
there, but it seems solvable. But I get the feeling the purpose of this
whole exercise is to have a single agent running for a single user,
despite multiple GNUPGHOMEs some of which are actually test suites
running during a compilation. I don't really understand why.

(By way of clarification, I mean: GNUPGHOME is standard ~/.gnupg? Look
at standard locations like /run/user. GNUPGHOME something else? Look for
file with socket location in GNUPGHOME).

My 2 cents,

Peter.

[1] In the case of an ephemeral GNUPGHOME, like with test suites, it
makes more sense to just put the socket in GNUPGHOME and GNUPGHOME in /tmp.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

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

From wk at gnupg.org  Wed Mar 22 17:46:02 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 22 Mar 2017 17:46:02 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <81a2ee66-c2ac-2a9a-1018-3994ebe41f3b@sumptuouscapital.com>
 (Kristian Fiskerstrand's message of "Wed, 22 Mar 2017 11:23:13 +0100")
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9d504743-4a19-19d4-2d4b-95f685e4a6f8@digitalbrains.com>
 <81a2ee66-c2ac-2a9a-1018-3994ebe41f3b@sumptuouscapital.com>
Message-ID: <87tw6lp8dx.fsf@wheatstone.g10code.de>

On Wed, 22 Mar 2017 11:23, kristian.fiskerstrand at sumptuouscapital.com
said:

> We've had reported build issues due to this in Gentoo and chosen to
> reduce the size of certain directory namings to mitigate it in the
> default case.

In theory GnuPG could create /run/users on the fly.  However this
requires that the admin provides a way to do that, for example by
installing a userv(1) script or whatever the desktop folks use these
days.  But in that case the admin could also create /run/user directly.

The problem at hand is that certain special setups (Debian buildd) _had_
a problem with 2.1.19 due to wrong assumption in the test suite.  Justus
already fixed that.

The remaining problem are assumption that things may break in regression
tests or local installations of _other_ software.  That is nothing new:
before the introduction of /run/users they had to setup redirection
files to overcome the problem of too long socket filenames.  This should
still work (modulo the new --supervised mode) but has in any case been a
niche use case.  Those who are affected they can setup /run/user or
offer cake/beer/kudos to their sysadmin to do that.

GnuPG's README now recommends the creation of /run/user.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170322/c2f6759a/attachment.sig>

From wk at gnupg.org  Wed Mar 22 18:15:36 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 22 Mar 2017 18:15:36 +0100
Subject: Stable GnuPG interface, git should use GPGME
In-Reply-To: <201703171056.10468.bernhard.reiter@intevation.de> (Bernhard
 E. Reiter's message of "Fri, 17 Mar 2017 10:56:02 +0100")
References: <201703101100.15214.bernhard.reiter@intevation.de>
 <201703131350.00139.bernhard.reiter@intevation.de>
 <13c66211-9671-5bd3-f3eb-96ffd5c39975@drmicha.warpmail.net>
 <201703171056.10468.bernhard.reiter@intevation.de>
Message-ID: <87poh9p70n.fsf@wheatstone.g10code.de>

On Fri, 17 Mar 2017 10:56, bernhard.reiter at intevation.de said:

> As the command line is not a stable API to GnuPG, there were changes and there 
> will be changes to the command line over several versions. It maybe in the 

That is not true.  The command line interface has been stable for the
last 19 years.  We only removed a left over PGP-2 backward compatibility
in 2.1 (-kvv).  I doubt that this has even been noticed.

>> Unfortunately, gpgme does not solve the interoperability problems
>> between gpg (1, classic, stable maint mode) or gpg2.0 (stable) and
>> gpg2.1 (modern) key stores, and gpg2.2 (modern, stable) is not released
>> yet.

It actually does.  For the tasks git uses gpg you should not notice a
difference in gpgme between any of these versions.  BTW, 2.1 was
realeased more than 2 years ago and 2.0 will reach EOL in 9 months.

> That is right, I also believe gpgme does not solve all interoperability 
> problems. I guess it solves some, but I would do more research to come up 

The main arguments pro GPGME are

 - There is generic stable API and ABI which did not changes since 0.4.1
   (2003-06-06) when we decided to redesign the API.

 - Iff verification of signatures needs a speedup we can do this inside
   GPGME and GnuPG without the GPGME user noticing that.  Technically we
   will then run gpg as co-process controlled by GPGME; for gpgsm
   (S/MIME) this is already done but there has not yet been a need to do
   this also for gpg.  Git could be the trigger to implement that.

 - The GPGME API would allow to provide a rich and stable output with
   the pretty print format.  AFAICS the current %G* format characters
   are a bit limited and require that scripts need to look at the key
   for further information.

> The key store migration is mainly an orthogonal issue and the problems will 
> happen with or without using gpgme. As GnuPG 2.2 is under way, it makes sense 

Please note that 2.2 is more of a marketing term than a change.  2.1 is
already in use and will be the standard gpg version in several distros,
including Debian.

Interoperability with 1.4 is a bit cumbersome if you often add new keys.
However, "gpg --export | gpg1 --import" is not too complicated. 

Be aware that ECC keys will be used more and more and they are not
supported by gpg1.  Further we are currently defining a v5 key format to
be prepared for weaknesses in the SHA-1 based fingerprint.  It is very
unlikely that a v6 key format will be added to gpg1.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170322/cd2e16de/attachment.sig>

From peter at digitalbrains.com  Wed Mar 22 19:46:28 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 22 Mar 2017 19:46:28 +0100
Subject: Stable GnuPG interface, git should use GPGME
In-Reply-To: <87poh9p70n.fsf@wheatstone.g10code.de>
References: <201703101100.15214.bernhard.reiter@intevation.de>
 <201703131350.00139.bernhard.reiter@intevation.de>
 <13c66211-9671-5bd3-f3eb-96ffd5c39975@drmicha.warpmail.net>
 <201703171056.10468.bernhard.reiter@intevation.de>
 <87poh9p70n.fsf@wheatstone.g10code.de>
Message-ID: <bec6098f-3016-0a41-02b0-a4e541a66bc4@digitalbrains.com>

On 22/03/17 18:15, Werner Koch wrote:
> It actually does.  For the tasks git uses gpg you should not notice a
> difference in gpgme between any of these versions.

Bernhard wrote "interoperability problems between [...] key stores". I'm
under the impression you are actually answering the question "can GPGME
be used in the same way regardless of the GnuPG version" instead?

> Interoperability with 1.4 is a bit cumbersome if you often add new keys.
> However, "gpg --export | gpg1 --import" is not too complicated. 

This presumes that

1) Keys are only updated on the 2.1 side
2) Keys are not deleted
3) Secret keys are never changed

right?

1) is trivially solvable. 2) is trickier, but can be done.

3) is because GnuPG 1.4 cannot update a secret key at all. Adding a new
subkey fails with:

gpg: key DCDFDFA4: already in secret keyring
gpg: Total number processed: 1
gpg:       secret keys read: 1
gpg:  secret keys unchanged: 1

You could delete before re-importing, but what if the key on the 1.4
side is actually the newer one? You'd lose all changes. Worst case:
updates of a single key on both sides. But that is perhaps pushing the
limit of sane use. Perhaps not, perhaps the user likes to use two
different frontends which use different GnuPG versions as their backend.

Luckily, expiration extensions are picked up by just transferring the
public key part of a secret key, so that does work.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170322/5cbddf88/attachment.sig>

From dkg at fifthhorseman.net  Wed Mar 22 19:35:40 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 22 Mar 2017 14:35:40 -0400
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87fui5kd4d.fsf@wheatstone.g10code.de>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9478ab1e-0173-5649-5f73-12b29cd9f5f1@sumptuouscapital.com>
 <87var2jopq.fsf@wheatstone.g10code.de>
 <87tw6m6ivx.fsf@alice.fifthhorseman.net>
 <87fui5kd4d.fsf@wheatstone.g10code.de>
Message-ID: <87fui56txf.fsf@alice.fifthhorseman.net>

On Wed 2017-03-22 03:02:42 -0400, Werner Koch wrote:
> On Wed, 22 Mar 2017 05:21, dkg at fifthhorseman.net said:
>
>> Putting this in rc.local won't fix the situation where there's a chroot
>> (which is the case for many debian build daemons, and probably other
>
> Setting up a chroot or jail is a complex operation and adding something
> to rc.local is not different than to make sure the required devices and
> tools are all accessible.  Think /dev/random, /etc/hosts etc.

Yes, i agree.  There are many complex environments that people use to
set up chroots or jails for building software, and they have a set of
idiosyncratic nuances that they need to support.

Not all of them currently mandate the creation of per-user directories
(or filesystems) in /run/user/$(id -u).

I've started the process of proposing such a change for schroot in
particular (https://bugs.debian.org/858466), but there are many other
similar systems that might be relevant.

In the meantime, do we want to say that all of those build environments
that don't create /run/user/$(id -u) are not approved for building
GnuPG?  or do we want to try to make it work?

> That is right.  However, we are talking about GnuPG's test suite, aren't
> we?

I think we're talking about any software build/test process that might
invoke GnuPG at some point.  right?

> For other software using
>
>   GNUPGHOME=/tmp/$mydir gpg-agent --daemon testshell
>
> is suitable approach.

Is this documented somewhere for software that depends on GnuPG?  The
use of a statically-named /tmp/$mydir doesn't seem safe, since someone
else could already own that directory.  So maybe we should encourage the
use of mktemp -d explicitly?

And we probably want to ensure that the cleanup happens too, so that'd
be something just a bit more complicated, like:

-----
WORKDIR=$(mktemp -d /tmp/gpg.XXXXXXXX)
GNUPGHOME=$WORKDIR gpg-agent --daemon testshell
?
rm -rf "$WORKDIR"
-----

And what should we do for software that depends on GnuPG but doesn't
know it?  For example, software that relies on a PAM stack which might
include some gpg-related PAM module, or software that links to a library
that itself builds optionally against libgpgme, or software that calls
other potentially-GnuPG-dependent software during a test suite?  How
should we reach those software developers?

The more that we can get GnuPG to "Just Work"? without any additional
requirements or interactions, the less likely GnuPG is to break the
build processes of these other tools.

We don't want to discourage developers from depending on GnuPG, right?

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

From quae at daurnimator.com  Thu Mar 23 03:30:19 2017
From: quae at daurnimator.com (Daurnimator)
Date: Thu, 23 Mar 2017 13:30:19 +1100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87a88e9x33.fsf@alice.fifthhorseman.net>
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de> <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
Message-ID: <CAEnbY+dPeNP67q7rCd5p5e1vEQ_y-aZN7bhJ_=7FsHaewAEMiQ@mail.gmail.com>

On 22 March 2017 at 07:46, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>  a) $GNUPGHOME/S.gpg-agent : this might have a particularly long name,
>     one that exceeds sun_path length.

On FreeBSD you have the `bindat` and `connectat` syscalls to help with this.

There was a patch proposed to linux (multiple times) a few years ago.
Perhaps someone wants to bump an old thread?
https://www.spinics.net/lists/linux-containers/msg25516.html
http://lkml.iu.edu/hypermail/linux/kernel/1604.0/04290.html


From wk at gnupg.org  Thu Mar 23 07:52:16 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 23 Mar 2017 07:52:16 +0100
Subject: Stable GnuPG interface, git should use GPGME
In-Reply-To: <bec6098f-3016-0a41-02b0-a4e541a66bc4@digitalbrains.com> (Peter
 Lebbing's message of "Wed, 22 Mar 2017 19:46:28 +0100")
References: <201703101100.15214.bernhard.reiter@intevation.de>
 <201703131350.00139.bernhard.reiter@intevation.de>
 <13c66211-9671-5bd3-f3eb-96ffd5c39975@drmicha.warpmail.net>
 <201703171056.10468.bernhard.reiter@intevation.de>
 <87poh9p70n.fsf@wheatstone.g10code.de>
 <bec6098f-3016-0a41-02b0-a4e541a66bc4@digitalbrains.com>
Message-ID: <87mvcco57j.fsf@wheatstone.g10code.de>

On Wed, 22 Mar 2017 19:46, peter at digitalbrains.com said:
> under the impression you are actually answering the question "can GPGME
> be used in the same way regardless of the GnuPG version" instead?

Right.

> 3) is because GnuPG 1.4 cannot update a secret key at all. Adding a new
> subkey fails with:

Indeed, I was not anymore aware of this limitation in versions < 2.1.
There are even more conflicts when PGP-2 keys (to me the only valid
reason to use gpg1 along with gpg2) or ECC keys need to be considered.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170323/0677ddb7/attachment-0001.sig>

From wk at gnupg.org  Thu Mar 23 08:10:53 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 23 Mar 2017 08:10:53 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87fui56txf.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 22 Mar 2017 14:35:40 -0400")
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9478ab1e-0173-5649-5f73-12b29cd9f5f1@sumptuouscapital.com>
 <87var2jopq.fsf@wheatstone.g10code.de>
 <87tw6m6ivx.fsf@alice.fifthhorseman.net>
 <87fui5kd4d.fsf@wheatstone.g10code.de>
 <87fui56txf.fsf@alice.fifthhorseman.net>
Message-ID: <87inn0o4ci.fsf@wheatstone.g10code.de>

On Wed, 22 Mar 2017 19:35, dkg at fifthhorseman.net said:

> I've started the process of proposing such a change for schroot in
> particular (https://bugs.debian.org/858466), but there are many other
> similar systems that might be relevant.

Right, but they always had that problem with GnuPG 2.  Except for the
bug in 2.1.19 which broke things.

> In the meantime, do we want to say that all of those build environments
> that don't create /run/user/$(id -u) are not approved for building
> GnuPG?  or do we want to try to make it work?

This is the case only iff they are testing GnuPG in a directory with a
too long name or on a remote file system.  We have been living with this
limitation for a long time.  The wrokaround was either to switch to /tmp
or to disable the tests.

What about testing in configure for /run/user and printing a warning if
that does not exist?  This would only benefit the gnupg build process
and not other software but this should help to rise awareness.

> I think we're talking about any software build/test process that might
> invoke GnuPG at some point.  right?

Do we have an actual case here?

> Is this documented somewhere for software that depends on GnuPG?  The

Let me add this as a hint to the debugging section of the GnUPG manual.

> use of a statically-named /tmp/$mydir doesn't seem safe, since someone

I am sure you know hot to create an custum value for this.

> And what should we do for software that depends on GnuPG but doesn't
> know it?  For example, software that relies on a PAM stack which might
> include some gpg-related PAM module, or software that links to a library

/run/user is better than the other solutions.  IIRC we had more support
requests due to remote file systems than due to too long directory
names.

I mentioned it in some other mail: I would agree to try creating sub
directories below /run/user/$UID/gnupg instead of relying on
--create-socketdir.  In case we ever run into problems with that we can
add a configure options to disable this auto-creation.


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170323/5aa3e2c2/attachment.sig>

From michael.haubenwallner at ssi-schaefer.com  Thu Mar 23 08:51:45 2017
From: michael.haubenwallner at ssi-schaefer.com (Michael Haubenwallner)
Date: Thu, 23 Mar 2017 08:51:45 +0100
Subject: ping: [PATCH] Cygwin needs -no-undefined libtool flag.
In-Reply-To: <a112c458-f6ef-c82f-0239-a5d9b83bbfed@ssi-schaefer.com>
References: <20170306170412.27837-1-michael.haubenwallner@ssi-schaefer.com>
 <87bmtcq440.fsf@wheatstone.g10code.de>
 <a112c458-f6ef-c82f-0239-a5d9b83bbfed@ssi-schaefer.com>
Message-ID: <fe9d57d0-72a0-4664-8f44-28ae4370d775@ssi-schaefer.com>

Any further thoughts?
Thanks!
/haubi/

On 03/08/2017 01:02 PM, Michael Haubenwallner wrote:
> 
> On 03/07/2017 08:27 PM, Werner Koch wrote:
>> On Mon,  6 Mar 2017 18:04, michael.haubenwallner at ssi-schaefer.com said:
>>
>>> Cygwin is not a "real" Win32 system, but uses the Win32 binary format,
>>> so libtool needs the -no-undefined flag.
>>
>> This needs to be patched in libtool and not in libgpg-error et al.  it
>> might be that upstream libtool already has that.  However due to
>> problems we had with the upstream version we keep our version which has
>> a few patches we require.
> 
> Well, there's nothing libtool can do about here.  Instead, there's a
> (widespread) misinterpretation about the -no-undefined libtool flag.
> 
> Agreed this might be easier to understand when it were not a "no-"flag,
> but this is for historical reasons when there were static libraries only.
> 
> 
> Please let me try to explain:
> 
> Creating a static library does not need to know which libraries to link
> against, as no linking is done at all.  So libtool does not require
> library maintainers to specify enough libraries to resolve all symbols.
> 
> But with the introduction of shared libraries this requirement changed:
> While each operating system does "support" undefined symbols with static
> libraries, some operating systems also do support undefined symbols with
> shared libraries, but some don't.
> 
> On the other hand, each operating system supporting shared libraries
> obviously does support shared libraries without undefined symbols.
> 
> Without the -no-undefined flag, libtool assumes the library does have
> undefined symbols, and does not create the shared library when the
> operating system is known to lack support for undefined symbols in
> shared libraries.
> 
> With the -no-undefined flag, libtool knows that the library maintainer
> does provide necessary libraries to resolve all symbols, so libtool can
> create the shared library even on operating systems without support for
> undefined symbols in shared libraries.
> 
> 
> As far as I can see, libgpg-error does not rely on undefined symbols at all.
> 
> So -no-undefined really makes sense for any platform here, as proposed in
> https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032186.html
> 
> Beyond that: With linkers that support yelling on undefined symbols (like
> GNU ld with -zdefs flag), the -no-undefined flag allows to unhide obscure
> bugs related to undefined symbols at library linking time already.
> 
> However, because of the -zdefs (or similar) linker flag (where supported),
> I can understand not to add the -no-undefined flag in minor releases,
> to not unhide bugs that do not (seem to) harm when left hidden.
> 
> Uhm, lots of inversive logic here...
> 
> Thanks!
> /haubi/
> 


-- 
Michael Haubenwallner     Senior Software Engineer
SSI SCH?FER                      IT Solutions GmbH
Friesachstra?e 15  8114 Friesach bei Graz  Austria
Phone +43 3127 200-308         Fax +43 3127 200-22


From wk at gnupg.org  Thu Mar 23 11:56:14 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 23 Mar 2017 11:56:14 +0100
Subject: Stable GnuPG interface, git should use GPGME
In-Reply-To: <201703230829.40741.bernhard.reiter@intevation.de> (Bernhard
 E. Reiter's message of "Thu, 23 Mar 2017 08:29:31 +0100")
References: <201703101100.15214.bernhard.reiter@intevation.de>
 <201703171056.10468.bernhard.reiter@intevation.de>
 <87poh9p70n.fsf@wheatstone.g10code.de>
 <201703230829.40741.bernhard.reiter@intevation.de>
Message-ID: <87shm4mfch.fsf@wheatstone.g10code.de>

On Thu, 23 Mar 2017 08:29, bernhard.reiter at intevation.de said:

> I was under the impression (and I do remember you telling me a few times)
> that the output of the command line interaction did change a lot over times
> and using applications had issues. I've experienced a few of those over the 

Sure, but that is only for human consumption and not for scripts.

gpg introduced its --status-fd machine interface 19 years ago.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170323/46873dc7/attachment.sig>

From wk at gnupg.org  Thu Mar 23 12:14:51 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 23 Mar 2017 12:14:51 +0100
Subject: 2.1.19 testing failures on the debian build daemons
In-Reply-To: <87inn0o4ci.fsf@wheatstone.g10code.de> (Werner Koch's message of
 "Thu, 23 Mar 2017 08:10:53 +0100")
References: <877f3noom5.fsf@alice.fifthhorseman.net>
 <874lyrlny0.fsf@europa.jade-hamburg.de>
 <878to0naqs.fsf@alice.fifthhorseman.net>
 <87shm8pa0h.fsf@wheatstone.g10code.de>
 <8760j4m0x5.fsf@alice.fifthhorseman.net>
 <87y3w07x48.fsf@europa.jade-hamburg.de>
 <87r31rbyzj.fsf@alice.fifthhorseman.net>
 <8737e76kyt.fsf@europa.jade-hamburg.de>
 <87zigely0y.fsf@wheatstone.g10code.de>
 <87zige6cq6.fsf@europa.jade-hamburg.de>
 <87a88e9x33.fsf@alice.fifthhorseman.net>
 <9478ab1e-0173-5649-5f73-12b29cd9f5f1@sumptuouscapital.com>
 <87var2jopq.fsf@wheatstone.g10code.de>
 <87tw6m6ivx.fsf@alice.fifthhorseman.net>
 <87fui5kd4d.fsf@wheatstone.g10code.de>
 <87fui56txf.fsf@alice.fifthhorseman.net>
 <87inn0o4ci.fsf@wheatstone.g10code.de>
Message-ID: <87inn0mehg.fsf@wheatstone.g10code.de>

On Thu, 23 Mar 2017 08:10, wk at gnupg.org said:

> I mentioned it in some other mail: I would agree to try creating sub
> directories below /run/user/$UID/gnupg instead of relying on
> --create-socketdir.  In case we ever run into problems with that we can
> add a configure options to disable this auto-creation.

Below is such a patch.  


Salam-Shalom,

   Werner


From d6f8d35dce3375636164061a008cf8ecb72908f4 Mon Sep 17 00:00:00 2001
From: Werner Koch <wk at gnupg.org>
Date: Thu, 23 Mar 2017 09:38:19 +0100
Subject: [PATCH] common: Implicitly do a gpgconf --create-socketdir.

* common/homedir.c (_gnupg_socketdir_internal): Create the
sub-directory.
--

Although there is no auto cleanup (yet) this should be helpful.  Let's
see whether possibly leaving stale directories around is better than
running into trouble when --create-socketdir was not used.

Signed-off-by: Werner Koch <wk at gnupg.org>
---
 common/homedir.c | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/common/homedir.c b/common/homedir.c
index 3055a32..ee4438c 100644
--- a/common/homedir.c
+++ b/common/homedir.c
@@ -542,7 +542,7 @@ _gnupg_socketdir_internal (int skip_checks, unsigned *r_info)
 
   /* If a non default homedir is used, we check whether an
    * corresponding sub directory below the socket dir is available
-   * and use that.  We has the non default homedir to keep the new
+   * and use that.  We hash the non default homedir to keep the new
    * subdir short enough.  */
   if (non_default_homedir)
     {
@@ -566,16 +566,27 @@ _gnupg_socketdir_internal (int skip_checks, unsigned *r_info)
           goto leave;
         }
 
-      /* Stat that directory and check constraints.  Note that we
-       * do not auto create such a directory because we would not
-       * have a way to remove it.  Thus the directory needs to be
-       * pre-created.  The command
-       *    gpgconf --create-socketdir
-       * can be used tocreate that directory.  */
+      /* Stat that directory and check constraints.
+       * The command
+       *    gpgconf --remove-socketdir
+       * can be used to remove that directory.  */
       if (stat (name, &sb))
         {
           if (errno != ENOENT)
             *r_info |= 1; /* stat failed. */
+          else if (!skip_checks)
+            {
+              /* Try to create the directory and check again.  */
+              if (gnupg_mkdir (name, "-rwx"))
+                *r_info |= 16; /* mkdir failed.  */
+              else if (stat (prefix, &sb))
+                {
+                  if (errno != ENOENT)
+                    *r_info |= 1; /* stat failed. */
+                  else
+                    *r_info |= 64; /* Subdir does not exist.  */
+                }
+            }
           else
             *r_info |= 64; /* Subdir does not exist.  */
           if (!skip_checks)
-- 
2.8.1



-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170323/83fc823a/attachment.sig>

From dkg at fifthhorseman.net  Sat Mar 25 04:12:14 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 24 Mar 2017 23:12:14 -0400
Subject: problems with gpgscm on s390x 
Message-ID: <87lgru59td.fsf@alice.fifthhorseman.net>

hey all--

I posted https://bugs.gnupg.org/gnupg/issue3014 recently, in reference
to https://bugs.debian.org/858400 -- gpgscm is intermittently crashing
on the s390x platform since commit
49e2ae65e892f93be7f87cfaae3392b50a99e4b1 ("gpgscm: Use a compact vector
representation.")

This is a problem for debian because s390x is a release architecture
[0], and a failing test suite means a build failure, which means a delay
in acceptance of the package.

2.1.19 has several important bugfixes in it, and i'd like to try to get
them into debian in some form sooner rather than later.

I have access to an s390x machine where i managed to get this initial
diagnosis, and i have the usual suite of debugging tools there.  If i
can help get more information, please let me know.

Could someone more upstream than me (Justus, perhaps?) take a look at
issue3014?

Thanks,

    --dkg

[0] https://www.debian.org/ports/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170324/9f751706/attachment.sig>

From alon.barlev at gmail.com  Sat Mar 25 20:10:25 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sat, 25 Mar 2017 22:10:25 +0300
Subject: [TESTS] gnutls-3.5 key exchange fails in sparc for ecdhe x25519 rsa
Message-ID: <CAOazyz2k+ptFmFwA82v6KTATsih7rf6=P-SBGEpdVdwf4X19Kg@mail.gmail.com>

Hi,

Can anyone please assist in determine why sparc tests fails?
Logs are available here[1]
It seems that the ecdhe x25519 rsa is an issue.

Thanks!
Alon

[1] https://bugs.gentoo.org/show_bug.cgi?id=613418


From wk at gnupg.org  Sun Mar 26 09:52:35 2017
From: wk at gnupg.org (Werner Koch)
Date: Sun, 26 Mar 2017 09:52:35 +0200
Subject: [TESTS] gnutls-3.5 key exchange fails in sparc for ecdhe x25519
 rsa
In-Reply-To: <CAOazyz2k+ptFmFwA82v6KTATsih7rf6=P-SBGEpdVdwf4X19Kg@mail.gmail.com>
 (Alon Bar-Lev's message of "Sat, 25 Mar 2017 22:10:25 +0300")
References: <CAOazyz2k+ptFmFwA82v6KTATsih7rf6=P-SBGEpdVdwf4X19Kg@mail.gmail.com>
Message-ID: <877f3ceapo.fsf@wheatstone.g10code.de>

Hi Alon,

I guess you wanted to address this to gnugtls-devel at gnutls.org


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170326/d17af3ce/attachment-0001.sig>

From wk at gnupg.org  Tue Mar 28 17:08:08 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 28 Mar 2017 17:08:08 +0200
Subject: [Announce] GPGME 1.9.0 released
Message-ID: <87inmt782v.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce version 1.9.0 of GPGME.

GnuPG Made Easy (GPGME) is a C language library that allows to add
support for cryptography to a program.  It is designed to make access to
public key crypto engines like gpg and gpgsm easier for applications.
GPGME provides a high-level crypto API for encryption, decryption,
signing, signature verification, and key management.  GPGME comes with
language bindings for Common Lisp, C++, QT, Python 2 and 3.

See https://gnupg.org/software/gpgme for more.


Noteworthy changes in version 1.9.0
===================================

 * Clarified meaning of the 'expire' parameter of gpgme_op_createkey
   and gpgme_op_createsubkey.  New flag to force a key without an
   expiration date.

 * New function gpgme_op_keylist_from_data_start to list keys from
   data objects without importing them.

 * New function gpgme_op_set_uid_flag to flag a key as primary.

 * New function gpgme_op_decrypt_ext to run decryption with special
   flags.  This can for example be used to unwrap keys (remove only
   the encryption layer).

 * New encryption flags to wrap a key (adding an encryption layer to
   an OpenPGP message) or to create anonymously encrypted messages.

 * Support for adduid and revuid operations in the C++ bindings.

 * Support for smartcard key generation in the C++ bindings.

 * Several new functions for the Python binding.

 * Many smaller bug fixes.


Download
========

You may download this library and its OpenPGP signature from:

  ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.9.0.tar.bz2 (1312k)
  ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.9.0.tar.bz2.sig

or

  https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.9.0.tar.bz2 (1312k)
  https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.9.0.tar.bz2.sig

The SHA-1 checksum is

  870719cd3d2ef6a7fcb1d6af9ce5446edba7bfc3  gpgme-1.9.0.tar.bz2

but you better check the integrity using the provided signature. See
<https://gnupg.org/download/integrity_check.html> for details.


Support
=======

Please consult the archive of the gnupg-devel 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>.

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project employs 4 full-time developers, one part-timer, and
one contractor.  They all work exclusivly on GnuPG and closely related
software like Libgcrypt.  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.


Happy hacking,

  Andre, Justus, Werner



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

p.p.s 
List of 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 five 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)

  rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15]
  Key fingerprint = 5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (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 BCEF7E294B092E28

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.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20170328/5233f19a/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From alon.barlev at gmail.com  Tue Mar 28 19:35:38 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 28 Mar 2017 20:35:38 +0300
Subject: gnupg-1.9.0 fails qt TofuInfoTest test
Message-ID: <CAOazyz1Rcx1UZB60QY8XPEf1HQMcn+7jqSGC0pNT1NrBMqnXTw@mail.gmail.com>

********* Start testing of TofuInfoTest *********
Config: Using QtTest library 5.6.2, Qt 5.6.2 (x86_64-little_endian-lp64
shared (dynamic) release build; by GCC 4.9.3)
PASS   : TofuInfoTest::initTestCase()
PASS   : TofuInfoTest::testTofuNull()
FAIL!  : TofuInfoTest::testTofuInfo() '!strcmp(plaintext.constData(), "Just
GNU it!\n")' returned FALSE. ()
   Loc: [t-tofuinfo.cpp(215)]
FAIL!  : TofuInfoTest::testTofuSignCount() '!keys.empty()' returned FALSE.
()
   Loc: [t-tofuinfo.cpp(289)]
FAIL!  : TofuInfoTest::testTofuKeyList() '!keys.empty()' returned FALSE. ()
   Loc: [t-tofuinfo.cpp(320)]
QDEBUG : TofuInfoTest::testTofuPolicy() bravo at example.net not found
QDEBUG : TofuInfoTest::testTofuPolicy() Error:  Success
QDEBUG : TofuInfoTest::testTofuPolicy() Homedir is:
"/var/tmp/portage/app-crypt/gpgme-1.9.0/temp/t-tofuinfo-xaLTkj"
QDEBUG : TofuInfoTest::testTofuPolicy() pubring exists:  false  readable?
false  size:  0
QDEBUG : TofuInfoTest::testTofuPolicy() keybox exists:  true  readable?
true  size:  28993
FAIL!  : TofuInfoTest::testTofuPolicy() '!keys.empty()' returned FALSE. ()
   Loc: [t-tofuinfo.cpp(381)]
PASS   : TofuInfoTest::testTofuConflict()
PASS   : TofuInfoTest::cleanupTestCase()
Totals: 4 passed, 4 failed, 0 skipped, 0 blacklisted
********* Finished testing of TofuInfoTest *********
FAIL: t-tofuinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170328/a61400f5/attachment.html>

From alon.barlev at gmail.com  Tue Mar 28 19:36:45 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 28 Mar 2017 20:36:45 +0300
Subject: [gpgme][PATCH] build: tests: avoid build tests if not required
In-Reply-To: <CAOazyz1+2YfNrXqOyPUyq9Dv7ayoLAU0K1mwsu63+sPJARbisw@mail.gmail.com>
References: <1474663083-27507-1-git-send-email-alon.barlev@gmail.com>
 <87r381v6gy.fsf@wheatstone.g10code.de> <1781245.FIDAXHxsJN@esus>
 <CAOazyz1+2YfNrXqOyPUyq9Dv7ayoLAU0K1mwsu63+sPJARbisw@mail.gmail.com>
Message-ID: <CAOazyz3qsZ0inV49EWW+edAufou0f2KkfDo-KYUGi_E8OrrV5Q@mail.gmail.com>

On 30 September 2016 at 20:49, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>
> On 30 September 2016 at 19:36, Andre Heinecke
> <andre.heinecke at intevation.de> wrote:
> > Hi,
> >
> > On Friday 30 September 2016 15:54:05 Werner Koch wrote:
> >> On Fri, 23 Sep 2016 22:38, alon.barlev at gmail.com said:
> >> > test enables reducing dependencies for build if tests are not going to
> >> > run.
> >
> > Mmh reducing dependencies I might be responsible for this. Is this because the
> > Qt Testsuite additionally requires QTest?
> >
> > In that case I think it might be a better fix to build the Qt tests only if
> > QTest is available. Would this work for you?
>
> Yes.
> However, autodetect is worse than just not build.
> As if you ignore and run "make check" then nothing will run although it should.
> So far I patched it to avoid users require QTest if no tests are to be executed.
> I will follow whatever decision you may have, including forcing QTest
> for users unconditionally, but I thought you have done this by
> mistake.
>
> Thanks.

Hi,
I see that gnupg-1.9 also requires qttest unconditionally, can we
please remove this dependency as mandatory?
Thanks!


From alon.barlev at gmail.com  Tue Mar 28 19:38:35 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 28 Mar 2017 20:38:35 +0300
Subject: gpgme-1.9.0 fails qt TofuInfoTest test
Message-ID: <CAOazyz0KDowh1BW3fZ5AW04-X20cuT=H8O7NHhvFRkBJL=HTPA@mail.gmail.com>

Sorry had typo last message, it is gpgme not gnupg.

---

********* Start testing of TofuInfoTest *********
Config: Using QtTest library 5.6.2, Qt 5.6.2
(x86_64-little_endian-lp64 shared (dynamic) release build; by GCC
4.9.3)
PASS   : TofuInfoTest::initTestCase()
PASS   : TofuInfoTest::testTofuNull()
FAIL!  : TofuInfoTest::testTofuInfo() '!strcmp(plaintext.constData(),
"Just GNU it!\n")' returned FALSE. ()
   Loc: [t-tofuinfo.cpp(215)]
FAIL!  : TofuInfoTest::testTofuSignCount() '!keys.empty()' returned FALSE. ()
   Loc: [t-tofuinfo.cpp(289)]
FAIL!  : TofuInfoTest::testTofuKeyList() '!keys.empty()' returned FALSE. ()
   Loc: [t-tofuinfo.cpp(320)]
QDEBUG : TofuInfoTest::testTofuPolicy() bravo at example.net not found
QDEBUG : TofuInfoTest::testTofuPolicy() Error:  Success
QDEBUG : TofuInfoTest::testTofuPolicy() Homedir is:
"/var/tmp/portage/app-crypt/gpgme-1.9.0/temp/t-tofuinfo-xaLTkj"
QDEBUG : TofuInfoTest::testTofuPolicy() pubring exists:  false
readable?  false  size:  0
QDEBUG : TofuInfoTest::testTofuPolicy() keybox exists:  true
readable?  true  size:  28993
FAIL!  : TofuInfoTest::testTofuPolicy() '!keys.empty()' returned FALSE. ()
   Loc: [t-tofuinfo.cpp(381)]
PASS   : TofuInfoTest::testTofuConflict()
PASS   : TofuInfoTest::cleanupTestCase()
Totals: 4 passed, 4 failed, 0 skipped, 0 blacklisted
********* Finished testing of TofuInfoTest *********
FAIL: t-tofuinfo


From alon.barlev at gmail.com  Tue Mar 28 19:45:00 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 28 Mar 2017 20:45:00 +0300
Subject: [gpgme PATCH 2/3] build: python: add prepare target
In-Reply-To: <1475134258-19457-2-git-send-email-alon.barlev@gmail.com>
References: <87h993japj.fsf@europa.jade-hamburg.de>
 <1475134258-19457-1-git-send-email-alon.barlev@gmail.com>
 <1475134258-19457-2-git-send-email-alon.barlev@gmail.com>
Message-ID: <CAOazyz2+1TUVFhFzLcbfoizvUSs0KGfJrowpmcNdEM7g1cQU9g@mail.gmail.com>

Hi,

In gpgme-1.8 we added a "prepare" target to allow downstream packagers
to build python using their own python
wrappers skipping the custom autoconf/automake sequences.

The sequence was:
./configure
make
cd lang/python
make prepare
# run setup.py using standard distro distutils handling

In gpgme-1.9 this was broken as once again there is an assumption that
configure detects python versions and automake is capable of running
distutils, both are wrong assumptions.

It is OK that you try to improve the automake build/install of the
python module, however, please provide support for downstream to skip
this part without hacking/patching the package.

I will try to submit a patch to deal with this, please keep this
functionality intact.

Thanks!
Alon





On 29 September 2016 at 10:30, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> this enables preparing the package using autoconf then build using
> distutils as separate stage.
>
> Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
> ---
>  lang/python/Makefile.am | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am
> index 1d7aee8..ea37da9 100644
> --- a/lang/python/Makefile.am
> +++ b/lang/python/Makefile.am
> @@ -65,6 +65,9 @@ dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc: copystamp
>           $(PYTHON) setup.py sdist --verbose
>         gpg2 --detach-sign --armor dist/pyme3-$(VERSION).tar.gz
>
> +.PHONY: prepare
> +prepare: copystamp
> +
>  .PHONY: sdist
>  sdist: dist/pyme3-$(VERSION).tar.gz dist/pyme3-$(VERSION).tar.gz.asc
>
> --
> 2.7.3
>


From wk at gnupg.org  Tue Mar 28 20:57:59 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 28 Mar 2017 20:57:59 +0200
Subject: [gpgme PATCH 2/3] build: python: add prepare target
In-Reply-To: <CAOazyz2+1TUVFhFzLcbfoizvUSs0KGfJrowpmcNdEM7g1cQU9g@mail.gmail.com>
 (Alon Bar-Lev's message of "Tue, 28 Mar 2017 20:45:00 +0300")
References: <87h993japj.fsf@europa.jade-hamburg.de>
 <1475134258-19457-1-git-send-email-alon.barlev@gmail.com>
 <1475134258-19457-2-git-send-email-alon.barlev@gmail.com>
 <CAOazyz2+1TUVFhFzLcbfoizvUSs0KGfJrowpmcNdEM7g1cQU9g@mail.gmail.com>
Message-ID: <8737dx5ivc.fsf@wheatstone.g10code.de>

On Tue, 28 Mar 2017 19:45, alon.barlev at gmail.com said:

> I will try to submit a patch to deal with this, please keep this
> functionality intact.

Well we need a test for this to make sure it does not get lost.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170328/ed877157/attachment-0001.sig>

From alon.barlev at gmail.com  Tue Mar 28 21:48:11 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 28 Mar 2017 22:48:11 +0300
Subject: [gpgme] python3.4 codegen of gpg/gpgme.py is corrupted
Message-ID: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>

Hi,

When building using python2.7 gpg/gpgme.py is generated ok.

When building using python3.4 it is corrupted, examples:
---
def gpgme_err_make(source: 'gpgme_err_source_t', code:
'gpgme_err_code_t') -> "gpgme_error_t":
    """gpgme_err_make(source, code) -> gpgme_error_t"""
    return _gpgme.gpgme_err_make(source, code)

def gpgme_error(code: 'gpgme_err_code_t') -> "gpgme_error_t":
    """gpgme_error(code) -> gpgme_error_t"""
    return _gpgme.gpgme_error(code)

def gpgme_err_code(err: 'gpgme_error_t') -> "gpgme_err_code_t":
    """gpgme_err_code(err) -> gpgme_err_code_t"""
    return _gpgme.gpgme_err_code(err)
---

Please advise.

Thanks,
Alon


From alon.barlev at gmail.com  Tue Mar 28 20:55:59 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 28 Mar 2017 21:55:59 +0300
Subject: [PATCH GPGME] python: build: reinstate prepare target
Message-ID: <20170328185559.2109-1-alon.barlev@gmail.com>

* lang/python/Makefile.am: fix prepare target
* lang/python/setup.py.in: abs_top_builddir handling

--

prepare will prepare target at PREPAREDIR
the automake will make use of prepare target
downstream may also make use of prepare target
outcome of splitting it is standard make error checking for each command

running setup.py in-tree requires abs_top_builddir environment to be set
to avoid guessing process.

Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
---
 lang/python/Makefile.am | 25 +++++++++++++++----------
 lang/python/setup.py.in |  9 +++++----
 2 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/lang/python/Makefile.am b/lang/python/Makefile.am
index d91ead9..a18a014 100644
--- a/lang/python/Makefile.am
+++ b/lang/python/Makefile.am
@@ -44,17 +44,22 @@ COPY_FILES_GPG = \
 	$(srcdir)/gpg/results.py \
 	$(srcdir)/gpg/util.py
 
+.PHONY: prepare
+prepare:
+	test -n "$(PREPAREDIR)"
+	$(MKDIR_P)              "$(PREPAREDIR)/gpg"
+	cp -R $(COPY_FILES)     "$(PREPAREDIR)"
+	cp setup.py             "$(PREPAREDIR)"
+	cp gpg/version.py       "$(PREPAREDIR)/gpg"
+	ln -sf "$(abs_top_srcdir)/src/data.h" "$(PREPAREDIR)"
+	ln -sf "$(abs_top_builddir)/config.h" "$(PREPAREDIR)"
+	cp -R $(COPY_FILES_GPG) "$(PREPAREDIR)/gpg"
+
 # For VPATH builds we need to copy some files because Python's
 # distutils are not VPATH-aware.
 copystamp: $(COPY_FILES) $(COPY_FILES_GPG)
 	set -e ; for VERSION in $(PYTHON_VERSIONS); do \
-	  $(MKDIR_P)              python$${VERSION}-gpg/gpg ; \
-	  cp -R $(COPY_FILES)     python$${VERSION}-gpg ; \
-	  cp setup.py             python$${VERSION}-gpg ; \
-	  cp gpg/version.py       python$${VERSION}-gpg/gpg ; \
-	  ln -sf "$(abs_top_srcdir)/src/data.h" python$${VERSION}-gpg ; \
-	  ln -sf "$(abs_top_builddir)/config.h" python$${VERSION}-gpg ; \
-	  cp -R $(COPY_FILES_GPG) python$${VERSION}-gpg/gpg ; \
+	  $(MAKE) PREPAREDIR=python$${VERSION}-gpg prepare; \
 	done
 	touch $@
 
@@ -63,6 +68,7 @@ all-local: copystamp
 	  PYTHON="$$1" ; shift ; \
 	  cd python$${VERSION}-gpg && \
 	  CFLAGS="$(CFLAGS)" \
+	  abs_top_builddir="$(abs_top_builddir)" \
 	    $$PYTHON setup.py build --verbose ; \
 	  cd .. ; \
 	done
@@ -71,12 +77,10 @@ python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz \
 python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc: copystamp
 	cd python$(PYTHON_VERSION)-gpg && \
 	CFLAGS="$(CFLAGS)" \
+	abs_top_builddir="$(abs_top_builddir)" \
 	  $(PYTHON) setup.py sdist --verbose
 	gpg2 --detach-sign --armor python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz
 
-.PHONY: prepare
-prepare: copystamp
-
 .PHONY: sdist
 sdist: python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz \
        python$(PYTHON_VERSION)-gpg/dist/gpg-$(VERSION).tar.gz.asc
@@ -104,6 +108,7 @@ install-exec-local:
 	set -e ; set $(PYTHONS); for VERSION in $(PYTHON_VERSIONS); do \
 	  PYTHON="$$1" ; shift ; \
 	  cd python$${VERSION}-gpg ; \
+	  abs_top_builddir="$(abs_top_builddir)" \
 	  $$PYTHON setup.py install \
 	  --prefix $(DESTDIR)$(prefix) \
 	  --record files.txt \
diff --git a/lang/python/setup.py.in b/lang/python/setup.py.in
index bf4efa3..8ddbf27 100755
--- a/lang/python/setup.py.in
+++ b/lang/python/setup.py.in
@@ -34,12 +34,13 @@ in_tree = False
 extra_swig_opts = []
 extra_macros = dict()
 
-if os.path.exists("../../../src/gpgme-config"):
+abs_top_builddir = os.environ.get("abs_top_builddir")
+if abs_top_builddir:
     # In-tree build.
     in_tree = True
-    gpgme_config = ["../../../src/gpgme-config"] + gpgme_config_flags
-    gpgme_h = "../../../src/gpgme.h"
-    library_dirs = ["../../../src/.libs"] # XXX uses libtool internals
+    gpgme_config = [os.path.join(abs_top_builddir, "src/gpgme-config")] + gpgme_config_flags
+    gpgme_h = os.path.join(abs_top_builddir, "src/gpgme.h")
+    library_dirs = [os.path.join(abs_top_builddir, "src/.libs")] # XXX uses libtool internals
     extra_macros.update(
         HAVE_CONFIG_H=1,
         HAVE_DATA_H=1,
-- 
2.10.2



From alon.barlev at gmail.com  Tue Mar 28 21:48:11 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 28 Mar 2017 22:48:11 +0300
Subject: [gpgme] python3.4 codegen of gpg/gpgme.py is corrupted
Message-ID: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>

Hi,

When building using python2.7 gpg/gpgme.py is generated ok.

When building using python3.4 it is corrupted, examples:
---
def gpgme_err_make(source: 'gpgme_err_source_t', code:
'gpgme_err_code_t') -> "gpgme_error_t":
    """gpgme_err_make(source, code) -> gpgme_error_t"""
    return _gpgme.gpgme_err_make(source, code)

def gpgme_error(code: 'gpgme_err_code_t') -> "gpgme_error_t":
    """gpgme_error(code) -> gpgme_error_t"""
    return _gpgme.gpgme_error(code)

def gpgme_err_code(err: 'gpgme_error_t') -> "gpgme_err_code_t":
    """gpgme_err_code(err) -> gpgme_err_code_t"""
    return _gpgme.gpgme_err_code(err)
---

Please advise.

Thanks,
Alon


From alon.barlev at gmail.com  Tue Mar 28 21:50:50 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 28 Mar 2017 22:50:50 +0300
Subject: [PATCH GPGME] python: build: reinstate prepare target
In-Reply-To: <20170328185559.2109-1-alon.barlev@gmail.com>
References: <20170328185559.2109-1-alon.barlev@gmail.com>
Message-ID: <CAOazyz0-Rf4xVjXzo7w_613uGvE1njJG92bVS5UqJ6xkDCHq_Q@mail.gmail.com>

BTW:

there is abnormality in the build system that the sources are modified
if --build-base is specified, the following files are written to
source instead to build directory or build temp directory:
      errors.i
      gpgme.h
      gpgme_wrap.c
      gpg/gpgme.py

Please consider to avoid.

Doing so will enable us to prepare a single source and then build
using separate build base using multiple python versions. This is
actually how downstream builds.

Regards,
Alon


From justus at g10code.com  Wed Mar 29 11:11:16 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 29 Mar 2017 11:11:16 +0200
Subject: [PATCH GPGME] python: build: reinstate prepare target
In-Reply-To: <CAOazyz0-Rf4xVjXzo7w_613uGvE1njJG92bVS5UqJ6xkDCHq_Q@mail.gmail.com>
References: <20170328185559.2109-1-alon.barlev@gmail.com>
 <CAOazyz0-Rf4xVjXzo7w_613uGvE1njJG92bVS5UqJ6xkDCHq_Q@mail.gmail.com>
Message-ID: <87vaqsla6j.fsf@europa.jade-hamburg.de>

Alon Bar-Lev <alon.barlev at gmail.com> writes:

> Please consider to avoid.

We are a free software project.  Please consider to submit a patch.

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

From alon.barlev at gmail.com  Wed Mar 29 11:18:49 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 29 Mar 2017 12:18:49 +0300
Subject: [PATCH GPGME] python: build: reinstate prepare target
In-Reply-To: <87vaqsla6j.fsf@europa.jade-hamburg.de>
References: <20170328185559.2109-1-alon.barlev@gmail.com>
 <CAOazyz0-Rf4xVjXzo7w_613uGvE1njJG92bVS5UqJ6xkDCHq_Q@mail.gmail.com>
 <87vaqsla6j.fsf@europa.jade-hamburg.de>
Message-ID: <CAOazyz1kXuZ2hZwLpU3TVW6AFX3rjZG3d6JvSjtee3HSpgA00g@mail.gmail.com>

On 29 March 2017 at 12:11, Justus Winter <justus at g10code.com> wrote:
>
> Alon Bar-Lev <alon.barlev at gmail.com> writes:
>
> > Please consider to avoid.
>
> We are a free software project.  Please consider to submit a patch.

I was hoping we first agree that this is to be fixed so that the
effort will not be wasted.


From alon.barlev at gmail.com  Wed Mar 29 11:31:07 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 29 Mar 2017 12:31:07 +0300
Subject: gnupg-1.9.0 fails qt TofuInfoTest test
In-Reply-To: <1838052.YUe1um1Mzn@esus>
References: <CAOazyz1Rcx1UZB60QY8XPEf1HQMcn+7jqSGC0pNT1NrBMqnXTw@mail.gmail.com>
 <1838052.YUe1um1Mzn@esus>
Message-ID: <CAOazyz1pW+Qn5NuYVrSiO_K1kZiy1cZ6aBSSOi4A0YtD2hVdxA@mail.gmail.com>

On 29 March 2017 at 11:41, Andre Heinecke <andre.heinecke at intevation.de> wrote:
>
> Hi,
>
> Mmmh, looking at the test I tried to figure out how this is possible. One
> reason I can think of is that the test just checks for gnupg-2.1.16 but not if
> the used libgcrypt supports curve 25519 (which is used for the test keys). Can
> you please post the output of gpg2 (or gpg) --version of the system the tests
> run to either confirm or disregard that theory?
>
> Or just the version number of libgcrypt, assuming your libgcrypt did not have
> this specially disabled.

Here it is:

gpg (GnuPG) 2.1.18
libgcrypt 1.7.6
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/alonbl/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


From justus at g10code.com  Wed Mar 29 11:34:43 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 29 Mar 2017 11:34:43 +0200
Subject: [PATCH GPGME] python: build: reinstate prepare target
In-Reply-To: <20170328185559.2109-1-alon.barlev@gmail.com>
References: <20170328185559.2109-1-alon.barlev@gmail.com>
Message-ID: <87shlwl93g.fsf@europa.jade-hamburg.de>

Alon Bar-Lev <alon.barlev at gmail.com> writes:

> * lang/python/Makefile.am: fix prepare target
> * lang/python/setup.py.in: abs_top_builddir handling
>
> --
>
> prepare will prepare target at PREPAREDIR
> the automake will make use of prepare target
> downstream may also make use of prepare target
> outcome of splitting it is standard make error checking for each command
>
> running setup.py in-tree requires abs_top_builddir environment to be set
> to avoid guessing process.
>
> Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>

Merged, many thanks for your contribution :)

However, in the future, even if you cannot be bothered to read our
commit message guidelines, please just try to make your message blend in
with the others.


Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170329/763a1a50/attachment-0001.sig>

From justus at g10code.com  Wed Mar 29 11:36:18 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 29 Mar 2017 11:36:18 +0200
Subject: [gpgme] python3.4 codegen of gpg/gpgme.py is corrupted
In-Reply-To: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>
References: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>
Message-ID: <87poh0l90t.fsf@europa.jade-hamburg.de>

Alon Bar-Lev <alon.barlev at gmail.com> writes:

> Hi,
>
> When building using python2.7 gpg/gpgme.py is generated ok.
>
> When building using python3.4 it is corrupted, examples:
> ---
> def gpgme_err_make(source: 'gpgme_err_source_t', code:
> 'gpgme_err_code_t') -> "gpgme_error_t":
>     """gpgme_err_make(source, code) -> gpgme_error_t"""
>     return _gpgme.gpgme_err_make(source, code)
>
> def gpgme_error(code: 'gpgme_err_code_t') -> "gpgme_error_t":
>     """gpgme_error(code) -> gpgme_error_t"""
>     return _gpgme.gpgme_error(code)
>
> def gpgme_err_code(err: 'gpgme_error_t') -> "gpgme_err_code_t":
>     """gpgme_err_code(err) -> gpgme_err_code_t"""
>     return _gpgme.gpgme_err_code(err)
> ---
>
> Please advise.

What makes you say the code is corrupted?  I assume that your MUA
introduced linebreaks, but otherwise this looks ok.

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

From alon.barlev at gmail.com  Wed Mar 29 11:38:09 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 29 Mar 2017 12:38:09 +0300
Subject: [PATCH GPGME] python: build: reinstate prepare target
In-Reply-To: <87shlwl93g.fsf@europa.jade-hamburg.de>
References: <20170328185559.2109-1-alon.barlev@gmail.com>
 <87shlwl93g.fsf@europa.jade-hamburg.de>
Message-ID: <CAOazyz248HyL04cWCBC4JgpTj1wbmNgn9-gXrGEV+k-K+pOe0g@mail.gmail.com>

On 29 March 2017 at 12:34, Justus Winter <justus at g10code.com> wrote:
>
> Alon Bar-Lev <alon.barlev at gmail.com> writes:
>
> > * lang/python/Makefile.am: fix prepare target
> > * lang/python/setup.py.in: abs_top_builddir handling
> >
> > --
> >
> > prepare will prepare target at PREPAREDIR
> > the automake will make use of prepare target
> > downstream may also make use of prepare target
> > outcome of splitting it is standard make error checking for each command
> >
> > running setup.py in-tree requires abs_top_builddir environment to be set
> > to avoid guessing process.
> >
> > Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
>
> Merged, many thanks for your contribution :)
>
> However, in the future, even if you cannot be bothered to read our
> commit message guidelines, please just try to make your message blend in
> with the others.

I truly tried!!!
What have I missed this time?


From alon.barlev at gmail.com  Wed Mar 29 11:38:59 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 29 Mar 2017 12:38:59 +0300
Subject: [gpgme] python3.4 codegen of gpg/gpgme.py is corrupted
In-Reply-To: <87poh0l90t.fsf@europa.jade-hamburg.de>
References: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>
 <87poh0l90t.fsf@europa.jade-hamburg.de>
Message-ID: <CAOazyz2OBHFY7N5ZF8LiV88CinZkPQFGD3ztsX=PXOs9veENAQ@mail.gmail.com>

On 29 March 2017 at 12:36, Justus Winter <justus at g10code.com> wrote:
> Alon Bar-Lev <alon.barlev at gmail.com> writes:
>
>> Hi,
>>
>> When building using python2.7 gpg/gpgme.py is generated ok.
>>
>> When building using python3.4 it is corrupted, examples:
>> ---
>> def gpgme_err_make(source: 'gpgme_err_source_t', code:
>> 'gpgme_err_code_t') -> "gpgme_error_t":
>>     """gpgme_err_make(source, code) -> gpgme_error_t"""
>>     return _gpgme.gpgme_err_make(source, code)
>>
>> def gpgme_error(code: 'gpgme_err_code_t') -> "gpgme_error_t":
>>     """gpgme_error(code) -> gpgme_error_t"""
>>     return _gpgme.gpgme_error(code)
>>
>> def gpgme_err_code(err: 'gpgme_error_t') -> "gpgme_err_code_t":
>>     """gpgme_err_code(err) -> gpgme_err_code_t"""
>>     return _gpgme.gpgme_err_code(err)
>> ---
>>
>> Please advise.
>
> What makes you say the code is corrupted?  I assume that your MUA
> introduced linebreaks, but otherwise this looks ok.
>

I do not think:
"""
def gpgme_err_code(err: 'gpgme_error_t') -> "gpgme_err_code_t"
"""
Is valid python, also python does not think so... :)

Alon


From peter at digitalbrains.com  Wed Mar 29 12:25:46 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 29 Mar 2017 12:25:46 +0200
Subject: [gpgme] python3.4 codegen of gpg/gpgme.py is corrupted
In-Reply-To: <87poh0l90t.fsf@europa.jade-hamburg.de>
References: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>
 <87poh0l90t.fsf@europa.jade-hamburg.de>
Message-ID: <1efc17c3-dbed-7a80-40a9-7f6f17466815@digitalbrains.com>

On 29/03/17 11:36, Justus Winter wrote:
> What makes you say the code is corrupted?  I assume that your MUA
> introduced linebreaks, but otherwise this looks ok.

Hah! :-) To me, it looks like the layout is about the only thing that is
actually proper Python :-). "def" is on a single line, then comes a properly
indented docstring, then a return statement on one line. Maybe your MUA
introduced linebreaks?

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

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

From justus at g10code.com  Wed Mar 29 12:28:19 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 29 Mar 2017 12:28:19 +0200
Subject: [PATCH GPGME] python: build: reinstate prepare target
In-Reply-To: <CAOazyz248HyL04cWCBC4JgpTj1wbmNgn9-gXrGEV+k-K+pOe0g@mail.gmail.com>
References: <20170328185559.2109-1-alon.barlev@gmail.com>
 <87shlwl93g.fsf@europa.jade-hamburg.de>
 <CAOazyz248HyL04cWCBC4JgpTj1wbmNgn9-gXrGEV+k-K+pOe0g@mail.gmail.com>
Message-ID: <87mvc4l6m4.fsf@europa.jade-hamburg.de>

Alon Bar-Lev <alon.barlev at gmail.com> writes:

> On 29 March 2017 at 12:34, Justus Winter <justus at g10code.com> wrote:
>> However, in the future, even if you cannot be bothered to read our
>> commit message guidelines, please just try to make your message blend in
>> with the others.
>
> I truly tried!!!

Sorry.  To my eyes, your commit message looks so out-of-place.  We are
really mostly just following GNU changelog rules.  The commit messages
of every GNU project I have contributed to are looking more or less like
this.

> What have I missed this time?

Here we go:

> python: build: reinstate prepare target
  ^       ^ multiple components, better join them with comma.
                 ^ Please use whole sentences, start with a capital
                   letter, end with a full-stop.

> * lang/python/Makefile.am: fix prepare target
                           ^ Usually, giving some (context) is good, but
                             this is tricky with Makefiles.
                             ^ Please use whole sentences, start with
                               a capital letter, end with a full-stop.

> * lang/python/setup.py.in: abs_top_builddir handling
                             ^ Please use whole sentences, start with
                               a capital letter, end with a full-stop.

> prepare will prepare target at PREPAREDIR
  ^ Please use whole sentences, start with a capital letter, end with a
    full-stop.  Please reflow this text (meta-q).
> the automake will make use of prepare target
  ^ Likewise.
> downstream may also make use of prepare target
  ^ Likewise.
> outcome of splitting it is standard make error checking for each command
  ^ Likewise.
>
> running setup.py in-tree requires abs_top_builddir environment to be set
> to avoid guessing process.
  ^ Likewise.

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

From alon.barlev at gmail.com  Wed Mar 29 12:30:32 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 29 Mar 2017 13:30:32 +0300
Subject: [gpgme] python3.4 codegen of gpg/gpgme.py is corrupted
In-Reply-To: <1efc17c3-dbed-7a80-40a9-7f6f17466815@digitalbrains.com>
References: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>
 <87poh0l90t.fsf@europa.jade-hamburg.de>
 <1efc17c3-dbed-7a80-40a9-7f6f17466815@digitalbrains.com>
Message-ID: <CAOazyz0_CCSinRucO=CaroNkOETJebGDtbWZyjzJmvcwmtPG2g@mail.gmail.com>

On 29 March 2017 at 13:25, Peter Lebbing <peter at digitalbrains.com> wrote:
> On 29/03/17 11:36, Justus Winter wrote:
>> What makes you say the code is corrupted?  I assume that your MUA
>> introduced linebreaks, but otherwise this looks ok.
>
> Hah! :-) To me, it looks like the layout is about the only thing that is
> actually proper Python :-). "def" is on a single line, then comes a properly
> indented docstring, then a return statement on one line. Maybe your MUA
> introduced linebreaks?

No, something is wrong with the automatic processing of the docstrings
and generation of the file.
As I wrote, in python-2.7 it works properly.
I can send a complete file if it will help.

# here it is bad, notice at parameter source: 'xxx' which is invalid
# also notice at the -> "gpgme_error_t" which is invalid.
def gpgme_err_make(source: 'gpgme_err_source_t', code:
'gpgme_err_code_t') -> "gpgme_error_t":

# this is the docstring which is valid... but leftovers are not
removed from the above during generation
    """gpgme_err_make(source, code) -> gpgme_error_t"""
    return _gpgme.gpgme_err_make(source, code)


From justus at g10code.com  Wed Mar 29 12:33:45 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 29 Mar 2017 12:33:45 +0200
Subject: [gpgme] python3.4 codegen of gpg/gpgme.py is corrupted
In-Reply-To: <CAOazyz2OBHFY7N5ZF8LiV88CinZkPQFGD3ztsX=PXOs9veENAQ@mail.gmail.com>
References: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>
 <87poh0l90t.fsf@europa.jade-hamburg.de>
 <CAOazyz2OBHFY7N5ZF8LiV88CinZkPQFGD3ztsX=PXOs9veENAQ@mail.gmail.com>
Message-ID: <87k278l6d2.fsf@europa.jade-hamburg.de>

Alon Bar-Lev <alon.barlev at gmail.com> writes:

> On 29 March 2017 at 12:36, Justus Winter <justus at g10code.com> wrote:
>> Alon Bar-Lev <alon.barlev at gmail.com> writes:
>>
>>> Hi,
>>>
>>> When building using python2.7 gpg/gpgme.py is generated ok.
>>>
>>> When building using python3.4 it is corrupted, examples:
>>> ---
>>> def gpgme_err_make(source: 'gpgme_err_source_t', code:
>>> 'gpgme_err_code_t') -> "gpgme_error_t":
>>>     """gpgme_err_make(source, code) -> gpgme_error_t"""
>>>     return _gpgme.gpgme_err_make(source, code)
>>>
>>> def gpgme_error(code: 'gpgme_err_code_t') -> "gpgme_error_t":
>>>     """gpgme_error(code) -> gpgme_error_t"""
>>>     return _gpgme.gpgme_error(code)
>>>
>>> def gpgme_err_code(err: 'gpgme_error_t') -> "gpgme_err_code_t":
>>>     """gpgme_err_code(err) -> gpgme_err_code_t"""
>>>     return _gpgme.gpgme_err_code(err)
>>> ---
>>>
>>> Please advise.
>>
>> What makes you say the code is corrupted?  I assume that your MUA
>> introduced linebreaks, but otherwise this looks ok.
>>
>
> I do not think:
> """
> def gpgme_err_code(err: 'gpgme_error_t') -> "gpgme_err_code_t"
> """
> Is valid python, also python does not think so... :)

Yes it is.  This is a type hint.

https://www.python.org/dev/peps/pep-0484/

The pep suggests it is fully implemented in Python3.5, but the
documentation for Python3.4 suggests that this particular annotation is
supported too:

https://docs.python.org/3.4/reference/compound_stmts.html#function-definitions

Are you actually having a problem or did it just look weird to you?


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

From peter at digitalbrains.com  Wed Mar 29 12:36:34 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 29 Mar 2017 12:36:34 +0200
Subject: [gpgme] python3.4 codegen of gpg/gpgme.py is corrupted
In-Reply-To: <CAOazyz0_CCSinRucO=CaroNkOETJebGDtbWZyjzJmvcwmtPG2g@mail.gmail.com>
References: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>
 <87poh0l90t.fsf@europa.jade-hamburg.de>
 <1efc17c3-dbed-7a80-40a9-7f6f17466815@digitalbrains.com>
 <CAOazyz0_CCSinRucO=CaroNkOETJebGDtbWZyjzJmvcwmtPG2g@mail.gmail.com>
Message-ID: <5b14eb26-831a-2384-ffe3-cd74eb8ac0d9@digitalbrains.com>

On 29/03/17 12:30, Alon Bar-Lev wrote:
> No, something is wrong with the automatic processing of the docstrings
> and generation of the file.

Yes, I agree, I just thought it was funny that Justus said that it was proper
except for the layout, whereas it seemed to me that those function definition
lines were whacked as you say, but the layout checked out just fine. I think
this was ironic, but this is a risky statement because some people are really
picky about their iron.

> # here it is bad, notice at parameter source: 'xxx' which is invalid
> # also notice at the -> "gpgme_error_t" which is invalid.
> def gpgme_err_make(source: 'gpgme_err_source_t', code:
> 'gpgme_err_code_t') -> "gpgme_error_t":

And upon checking, this line was also in your first mail and has an invalid
linebreak, so the irony turned out to be less solid. But still, there was a
wrong linebreak, singular, not plural :-).

Sorry that my joke actually cost you time.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

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

From alon.barlev at gmail.com  Wed Mar 29 12:45:48 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 29 Mar 2017 13:45:48 +0300
Subject: [gpgme] python3.4 codegen of gpg/gpgme.py is corrupted
In-Reply-To: <87k278l6d2.fsf@europa.jade-hamburg.de>
References: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>
 <87poh0l90t.fsf@europa.jade-hamburg.de>
 <CAOazyz2OBHFY7N5ZF8LiV88CinZkPQFGD3ztsX=PXOs9veENAQ@mail.gmail.com>
 <87k278l6d2.fsf@europa.jade-hamburg.de>
Message-ID: <CAOazyz0XOHyD4hvBHUCYzd_W2806jxwoPWG9sej7AVfMmpC5Eg@mail.gmail.com>

On 29 March 2017 at 13:33, Justus Winter <justus at g10code.com> wrote:
>
> Yes it is.  This is a type hint.
>
> https://www.python.org/dev/peps/pep-0484/
>
> The pep suggests it is fully implemented in Python3.5, but the
> documentation for Python3.4 suggests that this particular annotation is
> supported too:
>
> https://docs.python.org/3.4/reference/compound_stmts.html#function-definitions
>
> Are you actually having a problem or did it just look weird to you?

OK, I was not aware that python2, python3 should generate a different
code, so I hit a problem with detection of correct version and trying
to compile using python2 what python3 generate. I will hack this
somehow, but root cause is the fact that these files are written into
sources directory while they are actually build artifacts. This
relates to our other thread.

Thanks for the help!


From justus at g10code.com  Wed Mar 29 12:56:26 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 29 Mar 2017 12:56:26 +0200
Subject: [gpgme] python3.4 codegen of gpg/gpgme.py is corrupted
In-Reply-To: <CAOazyz0XOHyD4hvBHUCYzd_W2806jxwoPWG9sej7AVfMmpC5Eg@mail.gmail.com>
References: <CAOazyz2S=QYN6DkOGa2ND=_h3SHhCB180QTKRYUwQptercfCGQ@mail.gmail.com>
 <87poh0l90t.fsf@europa.jade-hamburg.de>
 <CAOazyz2OBHFY7N5ZF8LiV88CinZkPQFGD3ztsX=PXOs9veENAQ@mail.gmail.com>
 <87k278l6d2.fsf@europa.jade-hamburg.de>
 <CAOazyz0XOHyD4hvBHUCYzd_W2806jxwoPWG9sej7AVfMmpC5Eg@mail.gmail.com>
Message-ID: <87h92cl5b9.fsf@europa.jade-hamburg.de>

Alon Bar-Lev <alon.barlev at gmail.com> writes:

> OK, I was not aware that python2, python3 should generate a different
> code,

Previously it did not.

> so I hit a problem with detection of correct version and trying
> to compile using python2 what python3 generate. I will hack this
> somehow, but root cause is the fact that these files are written into
> sources directory while they are actually build artifacts. This
> relates to our other thread.

Yes, I had to fix that fe65a26ab584bd70fad45c7c4d44330e30a748a4 before I
could merge d184dbbba8987d9f387feb25791ed891e108dabc.  I don't know why
you are having that problem.

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

From muelli at cryptobitch.de  Wed Mar 29 15:20:12 2017
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Wed, 29 Mar 2017 15:20:12 +0200
Subject: One-file version of gpgme documentation
In-Reply-To: <20160909084825.GX5050@cryptobitch.de>
References: <20160909084825.GX5050@cryptobitch.de>
Message-ID: <20170329132012.GA20784@cryptobitch.de>

Hi.

Would it be possible to offer a "one file" version of the
HTML documentation of gpgme along with the current multiple files version?

That will allow the curious to search for certain strings much easier.

Cheers,
  Tobi


From muelli at cryptobitch.de  Wed Mar 29 17:41:34 2017
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Wed, 29 Mar 2017 17:41:34 +0200
Subject: One-file version of gpgme documentation
In-Reply-To: <fe0cc731-b757-fd57-4904-8f48966e37a5@dephekt.net>
References: <20160909084825.GX5050@cryptobitch.de>
 <20170329132012.GA20784@cryptobitch.de>
 <fe0cc731-b757-fd57-4904-8f48966e37a5@dephekt.net>
Message-ID: <1490802094.32643.20.camel@cryptobitch.de>

Hi.

On Mi, 2017-03-29 at 10:13 -0500, Dan Snider wrote:
> https://www.gnupg.org/documentation/manuals/gpgme.pdf
> 
> Apologies if you already considered but for some reason cannot use the
> PDF format.
> 
Very good point. I didn't know about the PDF version.
I was looking at?https://gnupg.org/software/gpgme/index.html?and the
only direct link goes to the HTML version.
The PDF version is linked from?https://www.gnupg.org/documentation/manu
als.html?though.

Cheers,
? Tobi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20170329/a58f9a11/attachment.sig>

From dan at dephekt.net  Wed Mar 29 17:13:21 2017
From: dan at dephekt.net (Dan Snider)
Date: Wed, 29 Mar 2017 10:13:21 -0500
Subject: One-file version of gpgme documentation
In-Reply-To: <20170329132012.GA20784@cryptobitch.de>
References: <20160909084825.GX5050@cryptobitch.de>
 <20170329132012.GA20784@cryptobitch.de>
Message-ID: <fe0cc731-b757-fd57-4904-8f48966e37a5@dephekt.net>



On 03/29/2017 08:20 AM, Tobias Mueller wrote:
> Hi.
> 
> Would it be possible to offer a "one file" version of the
> HTML documentation of gpgme along with the current multiple files version?
> 
> That will allow the curious to search for certain strings much easier.
> 
> Cheers,
>   Tobi
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 

I realize you specifically asked about HTML documentation, but I would
like to bring your attention to the single-file PDF version of the GPGME
documentation which I use for similar "easy search" reasons in case that
helps.

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

Apologies if you already considered but for some reason cannot use the
PDF format.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170329/05f1f997/attachment.sig>

From wk at gnupg.org  Wed Mar 29 20:54:26 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 29 Mar 2017 20:54:26 +0200
Subject: One-file version of gpgme documentation
In-Reply-To: <1490802094.32643.20.camel@cryptobitch.de> (Tobias Mueller's
 message of "Wed, 29 Mar 2017 17:41:34 +0200")
References: <20160909084825.GX5050@cryptobitch.de>
 <20170329132012.GA20784@cryptobitch.de>
 <fe0cc731-b757-fd57-4904-8f48966e37a5@dephekt.net>
 <1490802094.32643.20.camel@cryptobitch.de>
Message-ID: <87fuhv3od9.fsf@wheatstone.g10code.de>

On Wed, 29 Mar 2017 17:41, muelli at cryptobitch.de said:

> Very good point. I didn't know about the PDF version.
> I was looking at?https://gnupg.org/software/gpgme/index.html?and the
> only direct link goes to the HTML version.

Ha, I added this only yesterday and asked myself whether people would
complain about the missing PDF version.  You have been quite fast :-)


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170329/f6d3305f/attachment.sig>

From aheinecke at intevation.de  Thu Mar 30 14:46:43 2017
From: aheinecke at intevation.de (Andre Heinecke)
Date: Thu, 30 Mar 2017 14:46:43 +0200
Subject: gnupg-1.9.0 fails qt TofuInfoTest test
In-Reply-To: <CAOazyz1pW+Qn5NuYVrSiO_K1kZiy1cZ6aBSSOi4A0YtD2hVdxA@mail.gmail.com>
References: <CAOazyz1Rcx1UZB60QY8XPEf1HQMcn+7jqSGC0pNT1NrBMqnXTw@mail.gmail.com>
 <1838052.YUe1um1Mzn@esus>
 <CAOazyz1pW+Qn5NuYVrSiO_K1kZiy1cZ6aBSSOi4A0YtD2hVdxA@mail.gmail.com>
Message-ID: <82830934.rki1kKvV0N@esus>

Hi,

On Wednesday 29 March 2017 12:31:07 Alon Bar-Lev wrote:
> gpg (GnuPG) 2.1.18
> libgcrypt 1.7.6

Ok so that theory is out of the window. But I realized that the tests don't 
check for TOFU support in gnupg but just assume it based on the version 
number. So I was able reproduce the test failure if I compile gnupg with --
disable-tofu (or if it's compiled without sqlite).

Should be fixed with:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=2c063a8d60418ee59ae80da221420c6f3fa19abb

Thanks for your report,
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: 228 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170330/4793742c/attachment.sig>

From alon.barlev at gmail.com  Thu Mar 30 14:51:38 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Thu, 30 Mar 2017 15:51:38 +0300
Subject: gnupg-1.9.0 fails qt TofuInfoTest test
In-Reply-To: <82830934.rki1kKvV0N@esus>
References: <CAOazyz1Rcx1UZB60QY8XPEf1HQMcn+7jqSGC0pNT1NrBMqnXTw@mail.gmail.com>
 <1838052.YUe1um1Mzn@esus>
 <CAOazyz1pW+Qn5NuYVrSiO_K1kZiy1cZ6aBSSOi4A0YtD2hVdxA@mail.gmail.com>
 <82830934.rki1kKvV0N@esus>
Message-ID: <CAOazyz0WS1q4bzDq0gmzFj-yHWSwD8ATDmGegmEsTpRMt3KDbw@mail.gmail.com>

On 30 March 2017 at 15:46, Andre Heinecke <aheinecke at intevation.de> wrote:
>
> Hi,
>
> On Wednesday 29 March 2017 12:31:07 Alon Bar-Lev wrote:
> > gpg (GnuPG) 2.1.18
> > libgcrypt 1.7.6
>
> Ok so that theory is out of the window. But I realized that the tests don't
> check for TOFU support in gnupg but just assume it based on the version
> number. So I was able reproduce the test failure if I compile gnupg with --
> disable-tofu (or if it's compiled without sqlite).
>
> Should be fixed with:
>
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=2c063a8d60418ee59ae80da221420c6f3fa19abb

Working, thanks!

>
> Thanks for your report,
> Andre
>
> --
> Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
> Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
> Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From gnupg-devel at spodhuis.org  Fri Mar 31 22:33:23 2017
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Fri, 31 Mar 2017 16:33:23 -0400
Subject: Bug: dirmngr latches SRV port cross-scheme
Message-ID: <20170331203323.GA9502@breadbox.private.spodhuis.org>

If using SRV records for a hostname, GnuPG 2.1.19 is now trying to use
`_pgpkey-http` and `_pgpkey-https` as SRV lookups, which is great.

The result is cached as part of the record for the hostname.

So if you use hkp://foo and then hkps://foo then the SRV result for
_pgpkey-http is used for hkps: instead of picking up the _pgpkey-https
result.  These should normally be expected to be different ports, rather
than sharing.

Not currently diving into the DNS/dirmngr internals to tackle this,
hoping this, and the appropriate test resources below, are enough to
help?

Below:
 * commands to reproduce
 * dirmngr log (debug 1024)
 * details of the setup

The setup is dual-cert RSA and ECC for "keyserver.spodhuis.org" as part
of my testing how well this might work with clients.

Thanks,
-Phil

% gpg --keyserver hkp://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04
[success]
% gpg --keyserver hkps://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04
gpg: refreshing 1 key from hkps://keyserver.spodhuis.org
gpg: keyserver refresh failed: No keyserver available
% gpgconf --kill dirmngr
% gpg --keyserver hkps://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04
[success]

2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> S KEYSERVER hkp://keyserver.spodhuis.org
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> OK
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 <- KS_GET -- 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04
2017-03-31 16:25:49 dirmngr[22935.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:25:49 dirmngr[22935.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:25:49 dirmngr[22935.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> S SOURCE http://keyserver.spodhuis.org:11374
2017-03-31 16:25:49 dirmngr[22935.6] DBG: (104202 bytes sent via D lines not shown)
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> OK
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 <- BYE

2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.spodhuis.org
2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 -> OK
2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 <- KEYSERVER
2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 -> S KEYSERVER hkps://keyserver.spodhuis.org
2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 -> OK
2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 <- KS_GET -- 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04
2017-03-31 16:25:54 dirmngr[22935.6] TLS handshake failed: An unexpected TLS packet was received.
2017-03-31 16:25:54 dirmngr[22935.6] error connecting to 'https://keyserver.spodhuis.org:11374': Network error
2017-03-31 16:25:54 dirmngr[22935.6] marking host 'keyserver.spodhuis.org' as dead
2017-03-31 16:25:54 dirmngr[22935.6] host 'keyserver.spodhuis.org' marked as dead
2017-03-31 16:25:54 dirmngr[22935.6] command 'KS_GET' failed: No keyserver available
2017-03-31 16:25:54 dirmngr[22935.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
2017-03-31 16:25:54 dirmngr[22935.6] DBG: chan_6 <- BYE

2017-03-31 16:26:13 dirmngr[22935.6] DBG: chan_6 <- KILLDIRMNGR

2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.spodhuis.org
2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 -> OK
2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 <- KEYSERVER
2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 -> S KEYSERVER hkps://keyserver.spodhuis.org
2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 -> OK
2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 <- KS_GET -- 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04
2017-03-31 16:26:16 dirmngr[22948.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:26:16 dirmngr[22948.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:26:16 dirmngr[22948.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:26:17 dirmngr[22948.6] DBG: chan_6 -> S SOURCE https://keyserver.spodhuis.org:11373
2017-03-31 16:26:17 dirmngr[22948.6] DBG: (104202 bytes sent via D lines not shown)
2017-03-31 16:26:17 dirmngr[22948.6] DBG: chan_6 -> OK
2017-03-31 16:26:17 dirmngr[22948.6] DBG: chan_6 <- BYE


The hostname "keyserver.spodhuis.org" has both sets of SRV records, on
non-standard ports; this hostname is an alias for "sks.spodhuis.org"
(same backend SKS keyserver) but different nginx server stanzas in front
of it.  I set this up in Dec 2012 and "keyserver" as a hostname is
primarily for testing by me.

The normal :443 port serves with SNI to select between the sks-keyservers.net
CA-issued cert for pool hostnames (pool.sks-keyservers.net
*.pool.sks-keyservers.net) and a Let's Encrypt cert for
"sks.spodhuis.org" itself.  For "keyserver.spodhuis.org", the HTTPS
cert still uses my own private CA.  This is on the normal :443 port and
also :11373; :11374 is non-TLS.

DNS:
_pgpkey-http._tcp.keyserver     IN      SRV     10 10 11374     keyserver
_pgpkey-https._tcp.keyserver    IN      SRV     10 10 11373     keyserver

Today I refreshed the HTTPS certs used for "keyserver", to make them
dual RSA+ECDSA.  I then tried to test how this worked with GnuPG and ran
smack into this problem.

The certs used for "keyserver.spodhuis.org" are issued from the two
roots at:
  https://www.security.spodhuis.org/

"globnixCA4" is an RSA-based root issuing certs for RSA keys.
"globnixCA5" is an ECC CA, on secp384r1, issuing certs for ECDSA keys.

I run with ~/.gnupg/dirmngr.conf specifying:
  hkp-cacert /Users/pdp/.gnupg/CA/hkp-cacerts.pem
(and equiv /home for other systems) and that file containing Kristian's
sks-keyservers.net root, my own roots and the Let's Encrypt roots.

-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 996 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170331/ae41cb25/attachment-0001.sig>