Use Kleopatra which constructs the DN for you ;-).

I tested this with OpenPGP and 2.4.3-beta19 on Windows. Worked nicely.

I have now disabled the rewriting in the 2.4 branch. Those who want to keep the old behaviour may add

And of course we also need to adjust GPGME

We also need PROGRESS lines in gpgsm.

Thanks, we will take care of this.

With my fixes I now get this:

Actually two bugs. Easy to test on Unix with a small (e.g. 10MiB partition).

And thanks gniibe! I have tested 2.4.1 several times in this month (including existing and new keys), the warning was never shown again.

Hi zhangguangzhi, I think that it's version-specific problem.
I traced the chain and this warning message was added in release 2.3.3 T5565.
The problem should be able to reproduce between 2.3.3 and 2.4.0.

Hi，i try to reproduce the problem, my platform is linux and gnupg2-2.2.32-3, but i can't find “gpg: warning: lower 3 bits of the secret key are not cleared". Excuse me, is this a platform-specific or version-specific problem, or is it my operation wrong.

FWIW: I have not done any tests but the comment below is about the case I suspected to be the cuase for your problem:

See rG0988e49c45 which implements time and group but not yet the split thing because we are not shure that is good idea to have this w/o any implementation support.

There is an easy workaround: Append an exclamation mark to the adsk key. This way gpg will only search for this subkey.
An example with my test keys:

For the record, we've removed the SRV record for keys.gentoo.org for now, to work around the problem. Without the SRV record, everything works as expected.

Kleopatra test case (similar to gpg):

Seems it gets a record but is not able to parse it (gnupg/dirmngr/dns-stuff.c:getsrv-standard) in your setup. Not sure why it loops - need to debug it.

Fixed in 2.4

I will review the issue. A likely outcome will be to follow your suggestion but to add an option for the old behaviour to avoid further security discussions.

The fix is in 2.4.1.
It's not perfect fix, but it catches the problem when it's not encrypted secret key.

Closing. A small change in Kleopatra (T6472) should help to avoid using this hack in common cases.

The workaround works.

Okay, that was easy to check.

Not easy to fix because gpg --card-edit/-status has some support form other cards. Eventually these commands will be replaced by gpg-card. In the meantime we can use this hack:

@gniibe, will you be so kind an check the provided patches

To replicate the problem it is best to use Windows. Should be solved with my commit. Note that the bug is specific to 2.4 dues to irts multi-card and app support. There was no problem on 2.2.

gpg_encrypt (engine-gpg.c) passes --output - to gpg, i.e. it reads the result of gpg --encrypt from stdout unless I misread this. Not sure, why this seems to work on Windows. The real problem is probably something completely different.

my Yubikey works, too, if I disable PIV. With enabled PIV:

On Windows we always use --status-fd=1 but with gpg it is not a problem because we use a differenrt fd for output.

Unfortunately I can't replicate that with my Yubikey on 2.4.1. Tried several variant and with and without keyboxd. My Yubikey has PIV disabled but I doubt that this is the problem.

Test with GnuPG 2.4.1-beta76 failed with "error getting current key info: invalid name":

I'll add new error codes to gpgrt

Sorry, it took time (for me) to understand the issue, as this is not 100%-reproducible bug. And it was not clear (for me) that how passphrase were offered in the interaction, so, I was not possible to see if it's encrypted or not.

closed, as the remaining subtask is found at T6436

works in 3.1.27.0-beta44

works in gnupg24.