Not yet.

For a regular private key wie have such an indentifier. We don't have it for
symmetric passphrases but they are very rarely used. There is also no need to
have any cache for a smart card PIN.

The OpenPGP information as conveyed with SETDESC ist not a stable idnetification
but I think I can add something else. Not for 2.1.3 but soon after it.

Done in c238340:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=c2383407bba5eefea486464a31e02846124c9da5

I know. It is a regression. I will look into it soon.

I understand your case.

As I wrote to #712744, distribution nowadays is conservative enough for its
default kernel settings, and it doesn't require each application to have special
settings.

I think that we will be able to close this soon.

I created (1938) a new issue for the extreme slowness of --list-sigs on a
keybox. 1938 is most likely a bug, while 1710 is merely a quickfix for an
algorithmic issue in --list-sigs. However if with keybox “random access to the
keys is now really fast”, maybe it a proper fix could easily be implemented
instead. See also

http://lists.gnupg.org/pipermail/gnupg-devel/2015-February/029541.html

I'm also seeing this extreme delay from gpg --list-sigs 2.1.2 on a large
keyring, particularly when using kbx. It seems likely that there is a bug here.

Thanks. Fix pushed to the repo.

D292: 591_gnupg-2.0.27-pkcs11_reader_match.patch

This shows up elsewhere too:

http://forum.yubico.com/viewtopic.php?f=26&t=1171

says:

For some inexplicable reason, GnuPG cannot extract the public key from a
smartcard except during generation. That means that to use the key from
another computer, you either have to copy the public key from the original
computer's GnuPG keyring, or you need to set the URL attribute to a file
which contains the PGP public key block. Otherwise, the token is effectively
locked to a single computer, and unuseable if you happen to trash your
keyring unless you regenerate a key.

It would be nice to streamline this case.

Done with commit 14af2be

$ gpg --with-colons --list-config curve
cfg:curve:ed25519;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1

Since then we did a lot of work on Libgcrypt so that the AES-NI code is
different from May 2012. It is possible that we accidently clobbered a register
which might have been the reason for the VirtualBox failure.

I can't remember the test case, but any use of AES should have hit it. Just use
gpg where AES is the default anyway. I suggest to revert that patch an see what
happens.

Yes it is not for a reason - checkout the comments to see why.

Sure it does not. This is C! What a plain silly warning.

No c+p of warnings please! Use gnupg-devel for such things.

Please write one and sent it to gcrypt-devel. You should also provide some
eveidence for your believe.

After trying some more, I found out some things.

I just have to run "gpg revoke.asc", without any options.

But then, the reason text that I entered when generating the revocation
certificate is not shown. Nor is the numeric reason.

gpg: standalone signature of class 0x20
gpg: Signature made 02/22/15 15:46:23 Eur using DSA key ID BACCF5EE
gpg: standalone revocation - use "gpg --import" to apply

And I dont understand what “class 0x20” means.

How much time would it take to migrate to QT5?

We already have that "confirm" flag for ssh and thus adding code to use it for
the extra-socket feature should be easy. The open question is how to disable
this feature on a per key base. A ~/.gnupg/confirmcontrol or similar file could
be used to record those keys which do not need confirmation or if persistance is
not required a checkbox in pinentry could be used to show the confirmation
dialog only once per session.

This will eventually be done but not right now. I keep this bug report as a
reminder.

I granted you permissions to edit other bug reports. However, this patch is not
required.

I just changed the remaining http references to gnupg.org to https (on master).
Thanks.
Changing them in coments and in the outdated FAQ does not make sense.

Nope. See my comments at
https://lists.gnupg.org/pipermail/gnupg-users/2015-February/052401.html

D282: 546_0001-Use-https-for-links-in-documentation.patch

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

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.

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.

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.

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.