You have the problem only if hidden recipients are used. With 2.1 you
may use this option:

  --try-secret-key name

    For hidden recipients GPG needs to know the keys to use for trial
    decryption.  The key set with --default-key is always tried first,
    but this is often not sufficient.  This option allows to set more
    keys to be used for trial decryption.  Although any valid user-id
    specifica- tion may be used for name it makes sense to use at
    least the long keyid to avoid ambiguities.  Note that gpg-agent
    might pop up a pinentry for a lot keys to do the trial decryption.
    If you want to stop all further trial decryption you may use
    close-window button instead of the cancel button.

This won't be backported to 2.0.

This is not a bug. You need to install a Pinentry and adjust for the changes in
2.1. Please check with ArchLinux or ask at gnupg-users.

Can you please lookup the description or the symbol for the ERRNO value 141 ?
find /usr/include -name errno.h | xargs grep 141
might reveal it.

But the secret subkeys are not used. Or well, the keyflags should be taken from
the public key. That might not always be the case - in particular not if you
re-create the public key from the secret key.

You can of course repair it using 2.1 because there --export-secret-key takes
the public key and only adds the secret parameters.

What's not clear to me if it is possible to recover a private key that is
damaged this way? If you change expiration with 1.4, the self-signatures are
lost and some key flags are changed. Is it possible to recover from that? That
is the problem I'm concerned with -- if it isn't possible to recover, it seems
people end up with damaged secret subkeys after changing expiration date on a
subkey with gnupg 1.4/2.0.

I just verified that it is not a problem in 2.1.

I am not sure whether it makes sense to fix it in 1.4 given that it is easier to
change it with 2.1, export and import it then to 1.4. I feel it is better to
use my time to fix some missing export options in 2.1

Should be fixed by commit 017c6f8fba9ae141a46084d6961ba60c4230f97a
on 2014-06-24.

Backported to 2.0: commit 2424028.

All release tags are signed.

Signed commits are a bit cumbersome becuase I would have to insert the smartcard
for all commits. Signing with my on-disk standard key would be possible, though.

Ok, I'll give it a try with 09e8f35d3808d6e49f891360c341aae3869e8650 this weekend.

Regarding https: Yes, this is more security, even though only slightly as you will have
to trust CAs. Without it, an attacker could just give you a different repo and you'd
never notice if you don't compare commit checksums with someone else. Then again, that
someone else could also get the wrong repo, because your government decided that
everybody should get a backdoor'd GPG. With https, you also need to get a valid
certificate that's in the CAs. That's not helping against a government wanting to
backdoor GPG, but it at least helps against script kiddies and the like.

Speaking about signed commits and tags: Why not do that? I tried it with git and it
works great.

Fixed with commit 071ed43. Will go into 0.9.8.

Sorry for delaying it for so long.

Works for me now. Thanks again. -> resolved.

Okay, that took long :-(: commit da4db172 - will go into 2.1.2.

    I added options shown with --help but missing in the man page.
    However, --help won't show everything listed in the man age and
    frankly there are even more options not listed anywhere (to see them
    use --dump-options).

I also kept one British translation ;-)
Thanks for the report.

s/GPG-2/PGP-2/ of course

Tt is not really corrupted. There are just GPG-2 keys at the wrong place.

Well, some keys are duplicated but I do not think that this created the test case.
The reason for the duplication might be 1.4.12 which may not include the latest
locking code.

Regarding git: An https:// access is not in any way safer - it only hides what
you are doing on the remote repo. The security from git is due to the chain of
hashes. Thus if you see a full commit id you can be sure that we are talking
about the very same code.

Right, I could have given the full commit id, but that won't help either because
you should not trust this bug tracker. The only reliabale task is by starting
from a signed commit or tag and review all code up to there.
Fortunately any tmapering with git.gnupg.org would soon trigger a lot of
complains from people pulling updates and checking commit ids.

Okay, I was able to replicate your test case with an older gpg version. I am not
sure which version that was, though. I would need to bisect to find it.

However, with the latest version (commit 09e8f35d3808d6e49f891360c341aae3869e8650)
the problem has gone.

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.