Thanks for your report.

An FYI... Once we cleared the earlier findings GnuPG tested OK under Asan. GnuPG itself had no findings, and it did not cause any dependent libraries to generate findings.

Thanks for the tests. I just fixed this one and will do replace some code in master, soon.

This patch tested OK.

It looks like this patch clears this finding:

It looks like this patch clears this finding:

We fixed this bug already in the repo. See T4459.

It appears this issue was first identified and triaged in 2016: T2879
The subkey deletion feature also showed up in other issues since then:

Diffs downloaded from the revisions don't include commit messages for some reason. Here are all the commits I submitted for review as patch files with messages:

@werner could you review the patches posted here by @matheusmoreira ? This looks concretely useful, and i would like to have this fixed.

The digest algorithm used is computed based on the preferences in the key if encryption is also used. Thus this should always work and any decent key has sha256 in its preferences. In case sha1 has a higher precedence, as seen on old keys, --personal-digest-preferences can be used to prefer sha256. However, it is way better to fix the key. The easisies way to do that is to change the expiration date - then the new standard preferences will be used.

Revision D482 adds an extra confirmation prompt before deleting the secret primary key.
Revision D483 adds portuguese translation for the primary key deletion confirmation message.

@werner Here are the patches:

If you have a patch please send it either by mail to gnupg-devel or attach it here. Thanks.

In T4457#124752, @matheusmoreira wrote:

I thought about building a list of keys targeted for deletion so gpg can then ask the user to confirm the deletion of each key individually.

@dkg, thanks for the feedback. I read [doc/HACKING](https://www.gnupg.org/faq/HACKING.html) and revised the commit message so that it contains ChangeLog entries and a marker line before my description. I compared my new message to prior log entries and they seem to match now. Is this appropriate? If so, I will revise my other commits in the same manner.

Thanks for this work, @matheusmoreira ! I personally think a reusable function in common/ would be preferable, but it's probably up to @werner to decide what's best here.

@dkg Sure! I thought I was supposed to email the patches to the development mailing list. [I've uploaded my delete-secret-subkey branch to GitHub.](https://github.com/matheusmoreira/gnupg/tree/delete-secret-subkey) You can see a comparison here. I'll describe my changes.

@werner This issue also applies to GPA. Looking at the edit key interface I can't see how we can handle this. Am I overlooking something or do we just loose the error information / is it not emited by gnupg?

nice, i'm glad to hear you've got something working, @matheusmoreira ! if you can point to your branch, or send patches here so that other folks can review, that would be great.

Ha, fancy that, I just added the method of using gpg-connect-agent to our new handbook, I agree that having a --delete-secret-subkeys command would be incredibly handy here.

I managed to make it work on my branch: gpg --delete-secret-key FPR! deletes just that key and no others! I will prepare a patch for this specific change and then try to implement the --delete-secret-subkeys command.

FWIW, with 4a130bbc2c2f4be6e8c6357512a943f435ade28f I fixed a similar report by @syscomet but lacking a test case this was a blind flight ("This patch is not tested but a good guess."). Thanks for tracking it down.

This bug makes it impossible to use gpg-agent as ssh-agent for keys generated from gnupg.
(How should I understand what passphrase should I enter?)
The only way is to load them with ssh-add.

Paul Wouters writes to me:

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.]