I have a fix. I'll commit it later.

I've been studying the source code. When a fingerprint suffixed with ! is given as argument, the [do_delete_key](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/delkey.c;h=cc567384612ccf0dfd41d9e620d6cd5e759fd7b6;hb=HEAD#l50) function correctly classifies the search descriptor as exact and finds the correct key using [keydb_search](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/keydb.c;h=8c067e1dfbfa7a6394e44dbed3bfaef5a4fa7c43;hb=HEAD#l1853). However, the handle returned by [keydb_get_keyblock](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/keydb.c;h=8c067e1dfbfa7a6394e44dbed3bfaef5a4fa7c43;hb=HEAD#l1352) apparently includes the primary key and all subkeys associated with it. After confirming the action with the user, the function iterates over all PKT_PUBLIC_KEY and PKT_PUBLIC_SUBKEY packets present in the keyblock, obtains the keygrip of each key and asks gpg-agent to delete it.

One of the things that dirmngr has going for it is that it tracks the current network state, and it would be nice to be able to reuse that state across sessions. If an ephemeral keyring can't use a shared dirmngr, there are fewer arguments for having dirmngr in the first place, and people might be more justified in replacing it with things like https://gitlab.com/anarcat/scripts/blob/master/openpgp-key-get

I don't anymore think this is a high priority request. BTW, A more real problem than several dirmngr instances is multi-user access to smartcards.

Here's an ugly hack to make this work (patch based on v2.2.15).

@vsrinu26f No worries, looks like we are on the same page :)

Sorry i think i blabbered without understanding context.

I wish gnupg natively supports creating backup cards. To be able to import
private key material to do another keyto card. And every time it moves that
to card and removes from gnupg.

For exactly same key material on tokens. Just before writing first token
backup .gnupg folder or export all key info. Do key to card. Delete .gnupg
folder and restore from backup and keytocard second token.

Both tokens should have same material.

On the other hand if we want to track which token is used by having multiple unexpired signing subkeys and each token have its own subkey is a possible usecase where multiple admins have the tokens.

I think if we have to update one token then we have to update backup token as well if moved to new subkey.

@vsrinu26f Yes I'm using subkeys with YubiKey.

Sorry, ignore my comment if there is something with subkeys and you are
already using latest gnupg.

This is already implemented by yutaka.

Sorry for jumping in out of the blue but the idea of automatically selecting the available signing key sounds also very appealing to me.

I don't anymore think that it makes sense to fix it. Further there is no cache for PINs; that is entirely up to the card.

Thanks.

Great. Let me know when the newest gpg4win is released.

(fwiw, all of this testing is done with GnuPG 2.2.14-1, using the package that is in debian/experimental right now; i'd welcome any corroboration with other versions)

as i experiment with this, i find an even weirder result with certificate re-ordering: the function above is not idempotent.

Here is a horrible bash function for doing the kind of stripping and re-importing that *does* cause signature re-ordering:

werner wrote:

Great. Thank you.

We are aiming for this week.

When will the new gnupg program be released so I can install it?

Charles

So where can I get the corrected file to install? I suppose I need the
new gpg4win, it hasn't been updated yet. If I need the signature or TAR
from your website how can I implement that?

Charles

Where can I get the new thing file to install?

Thanks! I've confirmed that it works for me.

The secret import code actually had a bug in that it silently imported the secret key anyway, so that after importing the public key the secret key showed up. That was not intended because we do not want to allow importing arbitrary keys or subkeys if the don't have a corresponding public (sub)key with the mandatory key-binding signature. This has now been fixed. A fix for the actual problem will come soon.

Ok. Let me know so I can try it out.

Yes, I think that if I see an import result with "secret-keys-read && w/o userId's" I can just do a second try.

Checking the OpenPGP specs again, there is actually an "exit" clause for this PGP bug. Or well, what I would consider to be a bug. A fix for this is not easy because it would require to detect this at an outer level (the ascii armor) which we don't do because gpg is build along a streaming concept as almost all Unix tools. What we can do is to allow import of a secret key in that PGP format iff a public key is already there. In practise this would mean to run the import two times and ignore the errors from the first import.

I meant the abbreviations. PGP is based on a code base dating back to 1992; for example we mostly used the term keyblock instead of certificate in the code.

Those terms are not arbitrary, they are in the RFC.

Thanks. [I wonder why the looong established terms public-keyblock and key-signature must be replace by arbitrary new terms.]

• TPK: transferable public key (an "OpenPGP certificate")
• TPS: Third-party signature (any certification within a TPK that is not made by the primary key, and is not a cross-sig made by a subkey over the primary)

Thank you very much for the analysis. I'll forward the info.

The creating software is broken in regard to non-ASCII characters in the UID:

Good idea.

for user ID selection, you could also potentially match on substring, so uid dkg could select/deselect all user IDs that contain "dkg".

Mnemonics can be made language independent by implementing wordlists for every language. In bip39, each word represents a number, 0 through 2047 (their index in the wordlist).

I don't think the cause of the corruptions is user interference. Users which report that don't even know about the GnuPG home directory in advance. I think we have some kind of rare bug which causes the keyring to break.

It seems it's Ubuntu specific: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1796563

It became common, because many people now use larger keys.
For RSA-4096, three simultaneous connections for decryption may cause the failure.
In the experimental patch of D472: Limit active connections for gpg-agent, I limit gpg-agent to accept two connections only.

Agreed this looks like it should be made default behavior. This has affected many people I work with, and even with searching, this ticket never came up. I only found out about it by making a ticket myself. This issue looks like it has generated at least 3 tickets in this bug tracker, and the agent is raising memory errors during normal usage, which still smells like a bug to me.

The usual reasons for corruptions of binary data are FTP transfers in text mode; or opening a file with a Windows editor.

Got another reliable report in the Wald Forum about this. https://wald.intevation.org/forum/message.php?msg_id=6371&group_id=11

Uhm, if this option is useful why isn't it default behavior?

Not a bug :-). I should have read my own docs before starting a long debug session. The things is that the auto expanding of the secmem area is only done for xmalloc_secure and the internal MPI allocation functions. It is not dne for any memory which is allocated with xtrymalloc becuase those properly return an error to the caller. The idea is that if the caller wants to get an error back he has also the assurance that them memory is allocated in the non-swappable memory (i.e. not in the expanded parts of the secmem).

For my case, with $GNUPGHOME/gpg-agent.conf having debug-all, I observed that rsa_decrypt failes with 'Cannot allocate memory', after debug output of 'res'.
Reading libgcrypt/cipher/rsa.c, it is line 1439, where it calls sexp_build (MPI of PLAIN into SEXP of R_PLAIN).
I think that it does indeed memory failure here.
Having "auto-expand-secmem" in gpg-agent.conf, it goes well.

I can easily replicate this; it is a problem somewhere in the secure memory code of Libgcrypt.

Fix was released with 2.2.11

Thanks.