Right, this is simply done by multiplying by 365. I would consider thuis a
minor bug. Should we add a priority "minor bug" to this tracker?

Thanks for the information.
I think the complete IDNA and co are an big mining field until to day.

OpenPGP requires the use of UTF-8. OpenPGP does not even know about mail or IDNA.
The translation from UTF-8 needs to be done in your MUA.

kbxutil merely dumps the meta data stored in the file and does no parsing at
all. It will never be possible to achieve the same speed: The meta data is only
used to quickly search for certain attributes but not to list them in an
appropriate way. I will thus close this issue.

Just to be clear (it isn't clear to me that these issues are the same),
issue1938 is related to --list-sigs being extremely slow and spending all its
time in kernel mode, while in T1939 I merely wish that doing a keyring dump
with --list-keys was as fast as using kbxutils.

That is the same as T1938.

Duplicate of T1938

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

It is fixed by the commit: f82c4a6d0d76e716b6a7b22ca964fa2da1f962a0
This is not a perfect solution (it updates key storage by "learn --force" command
of gpg-agent), but it works fine usually.

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.

Confirmed. I think that this is a regression.
EXPORT_KEY command of gpg-agent should return the stub secret key.

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.

This was a change in behavior in 2.1 (relative to 2.0 / 1.4) in which instead of
taking the last specified key server, all key servers were used. I've now
reverted this in f26ba14028d34845ae10aae552b90681907e377d.

It has already been fixed for 2.0.27 and I just fixed it for 1.4:

f34d883 gpg: Remove left-over debug message.

Thanks for noting.

Changing component to gnupg with topic dirmngr in the hope to get more
visibility and because dirmngr is part of the gnupg repo in 2.1

Never mind. Just pushed the changes for the 2.0 branch.

Thanks!

Is there a need to backport it to 2.0 ?

No

Done for master (gpg21). 2.1.3 will be released in a few days.

Is there a need to backport it to 2.0 ?

Fixed for master (2.1).
Will not be backported to 2.0.

Please take this to gnupg-users. I assume this is a misunderstanding we can't
solve here.

I am sorry but I am not a gnupg developer and I can only understand what the
code effectively does, respective to what I need to know, not what that implies
to your development ideas.

I saw no handling of empty passphrases in 2.1.2. Could be because it doesn't
exist, could be because it was moved somewhere else now. I don't know what you
know about this. But I can clearly see from multiple instances that you do not
read my comments (e.g. you suggest secring.gpg which is inside ~/.gnupg which I
explicitly said to have removed two times now). Which implies that you cannot
have a clear understanding of the issue at all.

The archlinux gnupg is original with flags --enable-maintainer-mode
--enable-symcryptrun --enable-gpgtar .

The archlinux pinentry is 0.9.0 original with flags --enable-fallback-curses
--enable-pinentry-curses .

You are mixing two very different things. The gpg from 2.1 and the one from 2.0
are entirely different when it comes to gpg-agent communication. "Some kind of
failure" is not very helpful in this regard.

I can only suggest to post your problem to gnupg-users to get more comments.

Please read my comments more carefully to understand them. Or maybe you
overlooked the title of the bug?

In order to create my ugly hack, I looked at the source code of both gnupg
versions. The issue is the following:

1. GnuPG calls gpg-agent/pinentry/assuan_transact or whatever you name it.

(2.1.2 & 2.0.26)

2. gpg-agent returns some kind of failure on empty passphrase (2.1.2 & 2.0.26)
3. Now in 2.0.26 gnupg inserted an empty passphrase manually into the buffer,

however, in 2.1.2 it seems that it was desired to not let gnupg have access to
the passphrase at all in the binary. The new code speaks of some kind of
SPK2asdfsa incompatibility. Therefore this easy workaround for gnupgs inability
to handle keys with empty passphrases was no longer possible and developers
chose to just break it.

I really wish there was an alternative for gnupg, named pe-gnupg. Whereas "p" is
for "pragmatic" and e is for "enduser". Because those are both humongous
deficits of gnupg.

Pretty please do not spam the bug tracker with silly keywords spam!

I do not understand your comments.

Is this about 2.1.2 or a 2.0.x version?
Did you read the README with the notes on the removal of secring.gpg?

The only known bug with empty passphrases is that you need to enter the empty
passphrase two times when creating the key.

Does archlinux uses a vanilla source or do they have some extra patches? Please
ask over there or at gnupg-users.

ATTENTION GOOGLERS: SUPER UGLY HACK AVAILABLE

Works better than *EVER* before if you only use keys with an empty passphrase.

1. Download gnupg-2.0.26 source
2. edit g10/call-agent.c
3. go into function agent_get_passphrase
4. comment code from line " rc = start_agent (0); " to " line[DIM(line)-1] = 0;

" (excluding that line)

5. comment whole function call " rc = assuan_transact (agent_ctx, line, ..."

found directly after

6. compile, use it like it should have worked in the first place

Keywords: zero string passphrase empty string passphrase empty key password
empty password gpg linux gpg-agent store passphrase empty pass save password
gpg-agent make gpg agent remember password never enter password gpg private key
password empty no password gpg-agent pinentry no password

I downgraded the package and now sacrificed some hours of my life to test this
again. Like mentioned, I started with a new .gnupg directory hence did not need
to adjust for any changes.

1. You cannot create a new key with an empty passphrase

gpg --gen-key will open a password dialogue, allow the empty key after
confirmation, then ask again for a key again after collecting random data. Also
it then crashed after I moved the mouse coursor to another screen in my
multihead setup (:0.3 to :0.4). You can however create a key when using a passphrase

2. You cannot import keys with empty passphrases

The error behavior if importing the secret key that worked before is identical
as described before. Seemingly gnupg is unable to deal with empty passphrases
entirely and treats it as unsupplied passphrases.

D292: 591_gnupg-2.0.27-pkcs11_reader_match.patch

Done with commit bebab54. See also the comment for 783a4a9.

Works only with kbx files.

Thanks. That was helpful.

Fixed with commit cf83ff0. You should now see no more leading zero bytes and
correct bit lengths after decrypting a protected key. Internally GnuPG may use
a leading zero byte but with an gpg --export it will be removed.

Well, that makes sense.

Use a backslash and it should work.

Agreed, at most places gpg takes a normal slash just fine and the Windows API is
also specified to work with it. I will consider to also test for a forward slash.