You can implemnnt something like this using 2.1 and the --extra-socket feature.
Give the extra socket appropriate permissions/ACLs

Fixed in master with commit 64e809b Will go into 2.1.4.

I changed that to a feature but I agree that the subkey selection mechanism
should take smartcards into account.

It would be surpising that suddendly a different subkey will be used for signing
if a smartcard is not available. Right, most users with several subkeys are
experts and know what they are going but nevertheless this is a change in behaviour.

Sorry, I don't understand why you have a ENOMEM problem there. You are using
Linux and thus you have copy-on-write which should not lead to such problem.
Right there are some corner cases but I doubt that they kick in here.

What kind garbage collector are you using? Can you check with the guix folks
whether they have a similar problem? IIRC, Guile also uses gpgme

You can't use SIGCHLD in a library.

My point is not speed of forking, but memory pressure. We have problems with
Nix package manager forking any apps, unless it uses vfork() (either
directly, or indirectly via posix_spawn).

If zombies are the only reason for double forking, there are other ways
around, e. g. ignoring SIGCHLD.

And speaking of bugs, don't we have tests? :-)

That would be a large change which for sure would introduce a lot of new bugs.
In comparison to other operations required for gpg startup the pissible speedup
between fork and vfork will be minor. In any case vfork is an ugly hack which
is not required on modern OSes with MMU. Using posix_spawn is not possible
because we do double forking.

If you have a real problem with the performance, we should first evaluate the
problem and then find a solution. Thus: Please describe the use case and why
you think that the process creation is the performance hog. GPGME has been
designed to overcome such performance problems by eventually introducing
co-porcesses so to fork gpg only once for many operations. We do this with
gpgsm already but have not yet seen an urgent need to also also change this for
gpg. However, if there is a real need for it we can do that.

Old plain fork is expensive, even on Linux, maybe because of garbage
collector.

https://github.com/zalora/defnix/commit/987a49aa77be5596ec2a352c1c758bce532b
5818
https://github.com/zalora/nix-
exec/commit/ea6eb396f0fa67df6568e1bf5dada41fb70a6ca2

Can you give a reason why you need this?

That is not a bug but due to non-supported certificate policy constraints.

If you want to ignore them as a workaround you may modify the function
unknown_criticals which you find in
gnupg/dirmngr/validate.c and gnupg/sm/validate.c. Add to the
"known" array the strings "2.5.29.36" and "2.5.29.54".

c3po: There is no need to sighup gpg-agent.
gpgconf --reload (or --kill) dirmngr is sufficent

I would also like to see this.

Maybe --refresh-keys without arguments for "the entire keyring" should also ask
for a confirmation "This will leak your entire keyring to the keyserver and
possibly an attacker. Do you really want to do this? (y/N)", or "--yes".

Please see T1930. And if you have time, please
test it for PC/SC.
For GnuPG's internal CCID driver, you can use reader-port=1 for the case of a).
I don't know if partial match will be useful for internal CCID driver.

D291: 599_gpg2-scd-issue-1930-patch.diff

Thank you for your patch. I think that it is more useful.
Well, it will change the semantics of "reader-port" option slightly (exact match
to partial match).
In this case, isn't it more useful for users to allow default reader when no
match (my patch attached)?

Please let me know your name so that I can acknowledge your name as original
patch author.
Please test my patch.

Well, I commited a change to gnupg and for documentation reasons also to pinentry.

When calling pinentry with a known key (but not for PIN or during key creation)
the internal cache id is converted to a keyinfo string and send to Pinentry.
example:

  SETKEYINFO n/FD692BD59D6640A84C8422573D469F84F3B98E53

That string identifies a key. It is prefixed with a letter with a secret
meaning (actually n = normal key, s = used for ssh). Pinnetries should not
interpret the string but take it as opaque data.

It is possible to backport this to 2.0 if there is an interest in this.

I would like to see this happen. It would be great if dirmngr could make
parcimonie obsolete, for example.

(should this be "category: dirmngr" instead of just adding it as a topic?)

Let me confirm. Does this bus still exist in recent version of gpg 1.4 and/or
2.0, 2.1?

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.