Thanks!
I'll test it. Any idea what could have caused this corruption in the first place?

I have pushed a fix: commit 09e8f35. If you are using libgpg-error from git,
please also update it.

The test case still takes quite long the first time but after that things are
better. The reason for this is that gpg does a --rebuild-keydb-caches.

Uh sorry, yes it terminates after over a minute. Sorry I should have waited
longer but 100% CPU for over a minute is quite a lot of calculations ;-).
Changed the title.

Are you sure that it is an endless loop? My tests only show that it takes loooong.

Here's how to reproduce it:

$ mkdir 1 2
$ chmod 700 1 2
$ cp ~/.gnupg/gpg-agent.conf 1
$ cp ~/.gnupg/gpg-agent.conf 2
$ gpg2 --homedir 1 --yes --quick-gen-key "Test User 1"
gpg: keybox '1/pubring.kbx' created
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: 1/trustdb.gpg: trustdb created
gpg: key E2D6B58A marked as ultimately trusted
gpg: directory '1/openpgp-revocs.d' created
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub rsa2048/E2D6B58A 2015-01-22

Key fingerprint = E618 DF9C A599 A3A5 D5B2  B8FE 57C0 450E E2D6 B58A

uid [ultimate] Test User 1
sub rsa2048/C3D1C503 2015-01-22

$ gpg2 --homedir 2 --yes --quick-gen-key "Test User 2"
gpg: keybox '2/pubring.kbx' created
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: 2/trustdb.gpg: trustdb created
gpg: key C767617A marked as ultimately trusted
gpg: directory '2/openpgp-revocs.d' created
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub rsa2048/C767617A 2015-01-22

Key fingerprint = 4741 1B55 ADF9 4000 DFE9  60CF DDF2 7707 C767 617A

uid [ultimate] Test User 2
sub rsa2048/BFC45B68 2015-01-22

$ gpg2 --homedir 1 --export | gpg2 --homedir 2 --import
gpg: key E2D6B58A: public key "Test User 1" imported
gpg: Total number processed: 1
gpg: imported: 1
$ gpg2 --homedir 2 --sign-key E2D6B58A

pub rsa2048/E2D6B58A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

sub rsa2048/C3D1C503

created: 2015-01-22  expires: never       usage: E

[ unknown] (1). Test User 1

pub rsa2048/E2D6B58A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

Primary key fingerprint: E618 DF9C A599 A3A5 D5B2 B8FE 57C0 450E E2D6 B58A

     Test User 1

Are you sure that you want to sign this key with your
key "Test User 2" (C767617A)

Really sign? (y/N) y

$ gpg2 --homedir 2 --export | gpg2 --homedir 1 --import
gpg: key C767617A: public key "Test User 2" imported
gpg: key E2D6B58A: "Test User 1" 1 new signature
gpg: Total number processed: 2
gpg: imported: 1
gpg: new signatures: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
$ gpg2 --homedir 1 --list-keys

1/pubring.kbx

pub rsa2048/E2D6B58A 2015-01-22
uid [ultimate] Test User 1
sub rsa2048/C3D1C503 2015-01-22

pub rsa2048/C767617A 2015-01-22
uid [ unknown] Test User 2
sub rsa2048/BFC45B68 2015-01-22

$ # Still ok!
$ gpg2 --homedir 1 --sign-key C767617A

pub rsa2048/C767617A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

sub rsa2048/BFC45B68

created: 2015-01-22  expires: never       usage: E

[ unknown] (1). Test User 2

pub rsa2048/C767617A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

Primary key fingerprint: 4741 1B55 ADF9 4000 DFE9 60CF DDF2 7707 C767 617A

     Test User 2

Are you sure that you want to sign this key with your
key "Test User 1" (E2D6B58A)

Really sign? (y/N) y

$ gpg2 --homedir 1 --list-keys
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 1 signed: 1 trust: 1-, 0q, 0n, 0m, 0f, 0u

1/pubring.kbx

pub rsa2048/E2D6B58A 2015-01-22
uid [ undef ] Test User 1
sub rsa2048/C3D1C503 2015-01-22

pub rsa2048/C767617A 2015-01-22
uid [ full ] Test User 2
sub rsa2048/BFC45B68 2015-01-22

$ # Broken!

I applied c595659 manually to 2.1.1, this doesn't change anything.

I'd try it with the latest git master, however I don't see any way to securely check it
out as it is only offered via the insecure git:// protocol.

FWIW: It is sufficient to just import the key in question.

I am not able to repeat that with the latest git version.
This is probably due to the fix by commit c595659.

That's fine... or just make the wording in the man page more clear. Under
--verify, it talks about using --output with cleartext signed data. That seemed
to imply (to me) that --output is used _with_ --verify. I think it should be
clearer that --output is to be used _without_ --verify or that --output has no
effect when using --verify.

So this could be treated as just a documentation bug rather than create yet
another new option.

For what it's worth, I don't think backward compatibility is an important
concern here. If someone was using --output with --verify before, they likely
were under the impression that the combination worked when in reality the two
options together just weren't a valid combination. It seems unlikely that
anyone would depend on --output being ignored when used with --verify, and so
making the combination work now should not cause legitimate compatibility problems.

If the combination of --output with --verify is not made to work, there should
probably be a warning emitted (in addition to fixing the documentation).

In summary, it seems to me that viable options are at least the following:

• make --output work with --verify (possibly bad for compatibility reasons in

the rare use case of someone depending on current behavior of the currently
invalid combination)

• fix man page in the --verify section - specifically, clarify the text

discussing using --output

• add some new option
• warn if an invalid combination of options exists (e.g., --verify with

--current in the current implementation <= 2.1.1)

These are not necessarily exclusive choices.

I guess I would prefer to allow the combination to work or warn and fix the
docs. Not as keen to add yet another new option - there's already a lot.

I can work up a patch if we can settle on a direction.

Applied as 091c35e. Thanks.

This has never been the case and for backward compatibility we can't simply
chnage it.

We can add a new command or option to allow that. I changed the title and
category to reflect this.

Ok, thanks for the feedback.

It is known that the secret keyrings easily gets out of sync. Thus do not rely
on that information. Always use the public key ring for such info.

We won't fix that in < 2.1

D281: 541_0001-Fix-a-problem-with-select-and-high-fds.patch

Given that it seems not easy to reproduce this bug can you please test
commit 8adb5ff or the attsched patch to see whether this helps.

If it does not help, can you do a gpg build with debug symbols and run your case
again. If possible attach a debugger for a backtrace or produce it with a dump file.

A patch has been submitted, which should fix the problem. commit c595659

D280: 540_gpg211-dirmngr.patch

Ok, the same seems to happen with just RSA keys. It seems the ultimate trust is killed
as soon as you sign someone who signs you. Increasing priority as a result, as this
means that even without any experimental features, GPG will complain about your own
signatures.

I noticed your address elsewhere and wondered whether my script can handle it.
They do. However, gpg has not a complete parser but tries to make sure that the
user id looks like a valid address.

Use --allow-freeform-uid and enter what ever you like.

Ok, it seems to be that the problem arises as soon as I sign a key which then in turn
signs me back. If I import a signature and have not signed that key myself, everything
works as expected. But if I then go to sign that key, it goes to undef. If, OTOH, I
sign someone's key and export that, everything is fine. But as soon as they sign me
back, it goes to undef.

Ok, it gets even funnier. Now I managed to trigger it reliably by having an RSA key
sign my Ed25519 key. Each time I import it, the signature goes from ultimate to undef.
If I import with --import-options import-minimal, it strips all signatures from my
Ed25519 key and the trust goes back to ultimate.

I just noticed: This only happens with an RSA key with 2 sub keys. I just successfully
signed an RSA key with only 1 sub key.

MD5 is not used bu OpenPGP. It is allowed for backward compatibility but even
that has been dropped for GnuPG 2.1.

The use of SHA-1 fingerprints is hardwired into OpenPGP and to change this a
complete new key format needs to be specified. In any case the fingerprints
are not a problem right now.

Using Base64 fingerprints are actually a bad idea because they are to hard to
compare for a human.

P.S.
SHA512 probably would be the right thing. If someone's too lazy to compare such
a long fingerprint, he can still choose just to compare just one half of it.

Sure, a standard for that would be great.

MD5 is pretty much broken for security purposes and I would wonder, if that's
not also true in the context of OpenPGP.

You're probably much closer to the people responsible for the OpenPGP standard.
Are there any efforts to introduce SHA512-BASE64 fingerprints? (or at least SHA256)

Such fingerprints are not specifed by OpenPGP. It is also questionable whether
this will be used, given that one could also print an 256 bit ECC key directly.
Yeah, that is a bit different than the fingerprint but it raises the importance
of have a standard before coming up with an arbitrary fingerprint scheme.

That is easy to fix - commit 3197f69 pushed.

Thanks.

Thanks for testing

It probably would have been better to create two issues:
a) Dataloss with Kleo in 2.2.2 (fixed now)
b) crash with gpa

Jonny, can you confirm that the problem is gone with 2.2.3?

Yes it works fine, sorry I did not respond earlier. I'm using your patch since
you published it:
https://github.com/SynoCommunity/spksrc/blob/develop/cross/libgcrypt/patches/001-asm-allow-building-x86-and-amd64-using-old-compilers.patch

I'm running Ubuntu 14.10 on x84_64.

The toolchain is... whatever it is that Linuxbrew uses?

Here is a gist with significantly more detail (stacktraces, logs, configure
output, etc.): https://gist.github.com/anonymous/38a7178239568f946cd2

Linux specific things are a no-go unless really needed.

Yes, things could be adjusted to wake up only if reallyneeded but it requires
more code.

What is the problem you try to solve? Do you have any measurements that show
that battery life is improved by changing this?

Please describe the problem and here and not just on some external tracker. Do
not forget to describe platform and toolchain used. Thanks.

Well if my reading is correct, the housekeeping happens in handle_tick(). 3
things are happening:

1. Checks for lost parent. This could be converted to a signal (at least on

linux)

2. Checks for socket permissions. This is checked only every 60 seconds, so we

don't need to wake up every two seconds to check it.

3. Checks for lost connection to scdaemon... does this have to happen so

frequently?

dirmngr also seems to wake up often to check the if it's time to do housekeeping
(which it does every 10 minutes). Seems like this could also be improved?

scdaemon does seem harder, but not everyone is using smartcards.

Fixed for 1.7 with commit 8174723.

Path is in the repo so it will go into 1.7. Might have also been backported to 1.6.

This has been fixed for 1.7. It will not be fixed for 1.5.