ntbtls fixed in e582e91e47a164816ac074b9078dbed8537601dc.

libgcrypt fixed in 654024081cfa103c87bb163b117ea3568171d408.

libksba fixed in 561d03a008150c201ece22b29c97b24a1f6bf590.

libassuan fixed in b26b73d04bff10852382113ae361ea5726661510.

libgpg-error fixed in 5e51b642f747547c737a7abbc37e65b0f630d188.

I addressed this for GPGME in 60273e8b2c11d42215a5707bc55e3e0d8f350e07 but
apparently forgot to mention that here.

I'll keep the bug open until I fixed this in all packages.

Fix pushed. Thanks.

Using a socket conenction would require new code. We use the standard ports
instead. Sometimes the socks5 code (and I assume also the Unix domain socket
code) takes some time to figure out whether Tor is actually running, Thus this
is not done at every request.

Doing a check for every request would also require a lot of new code because we
need to restart a connection attempt at a higher layer. Similar to HTTP 301
handling.

I implemented that but then I found this in the man page:

  This command differs from the default operation, as it never writes
  to the filename which is included in the file and it rejects files
  that don't begin with an encrypted message.

Thus decryption is the default operation. The problem is that the
code also tries to do other things if it does not find encrypted data.
Note that the "never writes to the filename which is included in the
file" is wrong because gpg does not do that by default.

Good idea.
The "This looks like foo" might be a bit complicated but the warning is easy to
implement. I will add that one immediately.

Thanks for this work (and sorry to have just blindly/wrongly assumed that
--no-use-tor already existed without checking it).

On modern debian systems, the default tor daemon will always be listening on
unix domain socket /run/tor/socks. So a simple attempt to connect to that
socket should be sufficient -- it should fail immediately if the socket isn't
present or if no one is listening on it.

This seems cheap and fast enough to be able to do it on every query to me,
rather than introducing additional runtime state to dirmngr. just try to
connect, and if it doesn't work, fall back to a normal connection (you'd want to
do that anyway in case the tor daemon goes away after dirmngr had been launched).

I went over the other programs, and did not see any glaring problems. I have
decided to ignore the socket configuration for now. I'm quite happy with the
changes, but feel free to reopen this bug.

Backported to LIBGCRYPT-1-7-BRANCH

I have now pushed a change to Libgcrypt master to implement auto-extending of
secre memory pools. Commit b6870cf but there are two cother commits which this
is based upon. My test shows that I can now decrypt a message encrypted to the
test-hugekey.key.

I will port this back to Libgcrypt 1.7.

commit a5910e00ace882b8a17169faf4607163ab454af9 should fix that. Will go into
2.1.17.

I pushed Ueno's patches for gpgme. In particular
dee56820cabde60c43c9bf8281b8d411cb2ad644

Oops; forgot to add the fix to 1.7.0

This has meanwhile been done.

Binary PGP messages are now detected. Not well tested but the run-verify test
tool can help to check the feature.

1.23 has meanwhile been released.

Fixed with commit 7ed1502 for 1.23. I used your method.

I applied your patch (commit 28fd0ab) and will do a new release soon.

It was fixed in db1ecc8212defdd183abbb6b1407fcc8d2dc9552 for 2.1.
In 2.1, HDRLEN=0 for all callers, so, there will be no same "Ohhhh jeeee" any more.

In 1.4 and 2.0, HDRLEN is used as a hint. There is no need to change 1.4 and
2.0. Detail is described in:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031178.html

Not really making it simpler but --quick-gen-key can now take an expiration date.

Let's keep this bug open to track other improvements.

We also have --quick-addkey now.

Done for new searches.

Fixed in 4711a1e1.

Quoting Ben McGinnes (2016-05-11 19:54:21)

On Wed, May 11, 2016 at 12:44:00PM +0000, Justus Winter via BTS wrote:

Justus Winter <justus@g10code.com> added the comment:

I have integrated the Python bindings into our build system. See branch
'justus/pyme3'.

Open issues:

• (API) Change the name of the Python module. Currently it is named 'pyme',

shouldn't we use 'gpgme' instead?

No, simply because other (abandoned) attempts at writing wrappers for
GPGME already exist in the Python ecosystem. If we rename a module to
match the name of an existing one this will break things somewhere.
It also makes us no different from poor Isis Lovecruft who selected
the name gnupg for her fork of python-gnupg, but the original was
always imported as just gnupg so when she increased the version number
of her fork she broke a *lot* of things in other people's code.

That's also why the entirely new thing I've called GPyGME, not just to
play word games with Pygmy, but also because the name is not used by
any existing Python module.

Please explain the version number you entered and from where you downloaded GPA

And there is also the new

  $ gpg --quick-gen-key "Otto Normalverbraucher <otto@example.invalid>"
  About to create a key for:
      "Otto Normalverbraucher <otto@example.invalid>"

  Continue? (Y/n)

which avoids almost all questions. Whether to set an expiration date by default
is a different question and is connected on how a key can be revoked.

Thanks for your suggestions. We have simplified the key generation process, do
you mind to re-evaluate it?

% gpg2 --gen-key
gpg: WARNING: unsafe permissions on homedir
'/home/teythoon/repos/g10/local/gnupghome'
gpg (GnuPG) 2.1.12-beta119; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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!
Note: Use "gpg2 --full-gen-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Otto Normalverbraucher
Email address: otto@example.invalid
You selected this USER-ID:

    "Otto Normalverbraucher <otto@example.invalid>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 81F88C88 marked as ultimately trusted
gpg: revocation certificate stored as
'/home/teythoon/repos/g10/local/gnupghome/openpgp-revocs.d/5FB9D2A5255C94E3D06B5B563C8167E481F88C88.rev'
public and secret key created and signed.

gpg: checking the trustdb
gpg: public key of ultimately trusted key 909DD699 not found
gpg: public key of ultimately trusted key 5F2FA2F6 not found
gpg: public key of ultimately trusted key 5B81A1FD not found
gpg: marginals needed: 3 completes needed: 1 trust model: PGP
gpg: depth: 0 valid: 5 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 5u
pub rsa2048/81F88C88 2016-04-05 [S]

Key fingerprint = 5FB9 D2A5 255C 94E3 D06B  5B56 3C81 67E4 81F8 8C88

uid [ultimate] Otto Normalverbraucher <otto@example.invalid>
sub rsa2048/3E5BDFAF 2016-04-05 []

Meanwhile I also commited the Fedora patch.

Great! Thank you, Werner.

We now require a 64 bit integer type for >= 1.7 (commit 897ccd2)

Fixed in c7cb4008. This will take effect next the web site is published.

I've tested it with pubring now too and it works.
Justus mentioned in jabber that he noticed some more errors after this patch in
the scheme tests. I've not tried them.

Okay, so I can backport this to 2.0 ?