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.

The file has been completely rewritten for 1.6 and thus there is nothing to fix
for the current version. Thanks anyway for this report.

Sorry for the long delay. Fixed with commit 8c5eee5 for 1.7.

I won't backport it to 1.6 because the leak is only triggered by wrong usage of
the functions.

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).

Sorry, this is not a bug. If you configure with out TLS support it simply can't
do that. In case you are talking about the Windows installer, please note that
this binary version is marked as experimental with several limitations

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.

Done.

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.

This won't be fixed for 2.0 but I will consider to do something about it in one
of the next 2.1 releases.

No, you do not need a second bug for --delete-secret-key.

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)

I guess that is possible. gpgsm does not get much attention these days.

May be close this bug?

I changed this to a gpa bug. gpg4win does not yet use GnuPG 2.1

Yes, that is very likely. Check the list for a workaround.

Duplicate of T1793

The latest version is 0.9.7. Please report error only against the latest version.
It has likely been fixed.

edit: This is probably a duplicate of 1793

Could this case please get some attention. This is still an issue for me and
everyone else I know using GPA for windows. Can I help with any more information?