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'm seeing this behavior as well. For a test keyring with 13 keys, 49 User
IDs, and 7227 signatures, stored on a tmpfs on linux kernel 3.16, gpg2
--list-sigs with a pubring.kbx takes over 3 seconds (mostly kernelspace), but
with an old-style pubring.gpg takes 0.6 seconds (mostly userspace)

Maybe it makes more sense to mmap the keybox rather than trying to seek and read
inside it?

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 is related to the "ALIGN (3)" mpi code that caused a compile
problem on FreeBSD 10.1 (I changed it to "ALIGN (2)" and it compiled,
but I'm not sure if that will break something).

We did not changed anything in this code for many many years. This seems to be
a configure problem: The configure script (actually mpi/config.links) figured
that you are using BSD_SYNTAX but in reality as(1) requires ELF_SYNAX.

What is the cpu-os-vendor string? Look at mpi/asm-syntax.h in the build
directory - the top 3 lines shows this.

be an as(1) problem.

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 .

Thanks. Fix pushed to the repo.

D293: 592_0001-Use-assert-to-print-diagnosicts-before-calling-abort.patch

Can you please apply the attached patch which should help to get a more precise
error message. It might also be useful to show the file
src/lock-obj-pub.native.h
which is created int the build directory.

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.

Fixed with pinentry 0.9.1.

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.

Thanks. Fixed with commit dc10d46.

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.

Patch attached. I left the previous behavior intact in case it's needed for
backward-compat.

D290: 590_0001-GPGME_SIGSUM_KEY_REVOKED-not-set-on-revoked-key.patch

Pushed your patch to master and 2.0. Thanks.