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.

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.

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

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

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.

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)

That is easy to fix - commit 3197f69 pushed.

Thanks.

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

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?

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.

Note that gpg-agent is responsible for this. The agent calibrates the s2k count
so that the KDF takes about 100ms. Actually this is the default since 2.0
something (at least a couple of years). Note that the s2k count is still used
for symmetric encryption.

It is an open question whether gpg should be allowed to change the s2k options
because the keys are a property of the agent and not of gpg. For export it
might hwoever make sense to be able to change that (think export for use on a
slower box).

The ticker is responsible for several house holding tasks and thus we can't
simply disable it or set it too a much higher value. Currently this might be
some easy things but at least the check whether the socket has been taken over
by a second instance (what you call "permission check") is important and can't
be delayed for too long. Given that dirmngr and more import scdaemon also have
such ticker jobs, I doubt that this would lead to any noticable power saving.

Note that some years ago the code was modified to make sure that gpg-agent wakes
up at the full second so that it matches the tickers of other processes.

werner: Please go ahead.
I don't have enough knowledge about keybox implementation (and its plan).
My message is basically to share information, and my proposed change is not the
real fix, but something
pointing the (major) cause.

Any objections to upping the value?

It looks like it's due to TIMERTICK_INTERVAL being set to 2 on UNIX platforms so
that it can call handle_tick() every 2 seconds. It looks like handle_tick() just
checks if we've lost our connection to scd, if we've lost our parent, and less
frequently that the socket permissions are correct.

I'm not sure why we would need to check these things every two seconds. Also we
could detect parent death (on linux at least) via PR_SET_PDEATHSIG instead of
polling.

i've tested this with gnupg 2.1.1, and gnupg 2.1.1 does provide a non-zero
return code if the passphrase fails.

gniibe: If you want to fix that, please assign the bug to you, otherwise I
assign it to me in a few days.

(removing the PPG-2 support wasn't the easy job expected)

In 2.1, secret key handling has been changed.
It's now *not* in secring.gpg but files under private-keys-v1.d.
I think that there were some migration problems for your environment (and GnuPG
2.1.0) and one of your secret key is not converted.

I don't know the reason, but I guess that your key is only available in
secring.gpg and not in pubring.gpg.

About secret key reference (in secring.gpg for 1.4/2.0, under private-keys-v1.d
for 2.1) can be generated by accessing card.
With 2.1.1, --card-status will register key reference. With 2.1.0, you can do:

  $ gpg-connect-agent learn /bye

Once you have public key entry and private key reference to your card, it should
work well.
Could you please try installing your public key with 2.1.0 and making private
key reference?

I confirmed that --check-trustdb results broken trustdb.
We can check by --list-trustdb.

It should be something like:

rec 30, trust A405E58AB3725B396ED1B85C1318EFAC5FBBDBCE, ot=6, d=0, vl=34
rec 31, valid 10FBD3A5C90C815ECDE1D7F3B64A505EB55CC999, v=6, next=0
rec 32, valid 669CC039409AA2E143FDA46B0636052BB5875E07, v=6, next=31
rec 33, valid 8797B8E208A2F9947790975948D15DF75034A882, v=6, next=32
rec 34, valid 3B623D1260F1F12E06655DB6182516BB82E8F60F, v=6, next=33
rec 35, trust 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9, ot=0, d=0, vl=38
rec 36, valid F5118E19309A256D9C802AF3B8179AC5AA9D04E4, v=5, next=0
rec 37, valid 867625B137AE05F8579F82DC29B5EAF274386304, v=5, next=36
rec 38, valid 328A5C6C1B2F0891125ECBE4624276B5A2296478, v=5, next=37

But 2.1.1 updates like:

rec 30, trust A405E58AB3725B396ED1B85C1318EFAC5FBBDBCE, ot=6, d=1, vl=34
rec 31, valid 10FBD3A5C90C815ECDE1D7F3B64A505EB55CC999, v=2, next=0
rec 32, valid 669CC039409AA2E143FDA46B0636052BB5875E07, v=2, next=31
rec 33, valid 8797B8E208A2F9947790975948D15DF75034A882, v=2, next=32
rec 34, valid 3B623D1260F1F12E06655DB6182516BB82E8F60F, v=2, next=33
rec 35, trust 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9, ot=0, d=0, vl=38
rec 36, valid F5118E19309A256D9C802AF3B8179AC5AA9D04E4, v=5, next=0
rec 37, valid 867625B137AE05F8579F82DC29B5EAF274386304, v=5, next=36
rec 38, valid 328A5C6C1B2F0891125ECBE4624276B5A2296478, v=5, next=37

That is, DEPTH=1 and VALIDITY=2, which is wrong.

I investigated and realized that keybox_search function in kbx/keybox-search.c
is not yet mature. That is, it doesn't support skipfnc yet.

In this situation, something like following is needed:
diff --git a/g10/trustdb.c b/g10/trustdb.c
index 1bf664b..a946c29 100644

• a/g10/trustdb.c

+++ b/g10/trustdb.c
@@ -1625,6 +1625,12 @@ validate_key_list (KEYDB_HANDLE hd, KeyHashTable full_trust,

merge_keys_and_selfsig (keyblock);
clear_kbnode_flags (keyblock);
pk = keyblock->pkt->pkt.public_key;

+ if (search_skipfnc (full_trust, pk->keyid, NULL))
+ {
+ release_kbnode(keyblock);
+ continue;
+ }
+

if (pk->has_expired || pk->flags.revoked)
  {
    /* it does not make sense to look further at those keys */

Yes, please send by private mail. You might already know my key:

pub dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31]

Key fingerprint = 8061 5870 F5BA D690 3336  86D0 F2AD 85AC 1E42 B367

uid [ full ] Werner Koch <wk@gnupg.org>

Reducing priority from critical to urgent since there is now a workaround known:

• move .gnupg to .gnupg.old
• gpg --import .gnupg.old/pubring.gpg
• gpg --import .gnupg.old/secring.gpg
• cp .gnupg.old/trustdb.gpg .gnupg

Also using a version with 94a5442 reverted and importing a new key seems to fix
this issue for me also when 94a5442 is applied again afterwards.

I can send you both versions of the keyring, a defect and a working one.

For comparison, running the below commands using gpg 1.4.18, does *not* exhibit
the bug - after importing dkg's key, my own key's validity remains as "ultimate".