Is limit-card-insert-tries a working option?

Chip Senkbeil chip.senkbeil at
Fri May 31 19:53:06 CEST 2019

Maybe my setup is like you described? I thought it was a reasonable setup, but being a gpg beginner, I'll take any advice I can get!

I've got a master key that I've used to create subkeys for encryption, signing, and authentication. Here's my current setup below:

sec   rsa4096/0x6CA6A08DBA640677 2019-03-01 [SC]
uid                   [ultimate] Chip Senkbeil (My mail & pass key) <chip at>
ssb>  rsa4096/0x588B4B090695884C 2019-03-01 [E]
ssb>  rsa4096/0x8A6B3DB2C23EB74B 2019-05-08 [E]
ssb>  rsa4096/0x95B67753BA414327 2019-05-08 [E]
ssb>  rsa4096/0x231C4CB425985243 2019-05-28 [S] [expires: 2024-05-26]
ssb>  rsa4096/0x1F3D585E398D11B1 2019-05-28 [S] [expires: 2024-05-26]
ssb>  rsa4096/0x5487424ABA6BDDDB 2019-05-28 [S] [expires: 2024-05-26]
ssb>  rsa4096/0x68F5987A509841B2 2019-05-28 [A] [expires: 2024-05-26]
ssb>  rsa4096/0x70B8AA34DA9D2413 2019-05-28 [A] [expires: 2024-05-26]
ssb>  rsa4096/0xDD69ABE5B8BCF75C 2019-05-28 [A] [expires: 2024-05-26]

I've moved one encryption, signing, and authentication subkey to each of my three smart cards from Yubico. I'd deleted the master key from my laptop after that, but added it back from a backup to create the signing and authentication subkeys. I'll be deleting it again shortly.

>From what I can tell from the pass tool, it marks your own keys as recipients so you can decrypt the passwords you encrypt (to inject elsewhere).

Putting that aside for a moment, I dug through the gnupg codebase a little more and I think the functionality for --limit-card-insert-tries was removed in some update. The CLI option is still there, but the logic that was previously specified in cardglue.c is gone (as is that file itself).

It looks like the last commit I can see that had the functionality in master was from tag gnupg-1.4.5 (commit 21de807d1a170d44dabcb34f37ce90504e303b81), located in g10/cardglue.c

    rc = app_select_openpgp (app);
    if (opt.limit_card_insert_tries
        && ++retry_count >= opt.limit_card_insert_tries)
    else if (rc && !opt.batch)

The cardglue.c file was removed (presumably refactored?) in the next commit 8c219602515ae1dba5bc0da31077852dab61809e, which seems to be a large update labeled, "Moved 1.9 branch to trunk". I'm guessing development happened separately from the master branch and was merged in several versions later.

I'm assuming the logic could be added back in at agent/divert-scd.c in the main loop of the ask_for_card function.

Should I move over the limit-card-insert-tries functionality discussion to gnupg-devel?

On Thu, May 30, 2019 at 05:46:55PM -0400, Tony Lane wrote:
> Hash: SHA512
> I don't know much about this 'pass' tool so I can't give you much advice for that.
> But more importantly, your setup seems a little... odd. If I'm understanding this correctly, you have *multiple* smartcards with (what I presume are your) unique identities on each of them but registered to the same email address? I'm not sure if I understand your exact setup, but if I have it right, I don't think this is optimal.
> You should have your cert-only (master key) private key stored away somewhere offline registered to your email address.
> Under this cert-key, you'd have at least 2 subkeys signed by it... an encryption subkey and signing subkey. You can have more than one of these and you can specify which one to use with: gpg -u <key-id>! for signing or: gpg -e -r <key-id>! for encrypting. Note that with encrypting however, you typically use *other* people's key ids to encrypt to. Well, you could add yourself as the recipient so you could decrypt it as well.
> And yes, you can use an email address and GPG will be smart enough to pick and choose which key to use. You typically don't explicitly specify key-id! for signing unless you have multiple signing subkeys and need to use a specific one, and likewise don't typically use key-id! for encrypting unless your recipients have multiple encrypting subkeys and they request you to use a specific one (perhaps they have a subkey for work-related stuff and another for at home?).
> In any case you should have only one cert key and all of your subkeys stem from that.
> > From what I've seen from the `pass` tool, if I'm editing an already-encrypted file, it decrypts the file - producing a copy that I can edit - and then re-encrypts the file. Here's an example from my multiple subkey setup:
> >     gpg2 -e -r keyid1! -r keyid2! -r keyid3! -o content.gpg --quiet --yes --compress-algo=none --no-encrypt-to --batch --use-agent /path/to/content.txt
> > Where keyid1, keyid2, etc. are in the long form of 0x0123456789ABCDEF
> If you're getting prompted for a passphrase multiple times for this, I think what may be happening is that a subset of your recipients' public keys are partitioned across the two smart cards. You should just have the public keys all in one card. Public encryption keys can be freely exchanged and shared without risk.
> 05lFAgd0xQc+OhmAAHCoHC1G4kEQcuelrECubAC0uxjclZZGFWmZ6iKXeoexke0f
> hI7NdsW0HjCl+J05J66HH/hxFxesjwIJAfyBZWlHkEMKlTnIMkBHtCDzYyyQLH/m
> pQ0cRp6FT/eO25jq9/sNL/qzWWpR9+4PZB1xKgA6DEBrEW4I+YjOC9+o
> =ZTAw
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at

More information about the Gnupg-users mailing list