In T6679#174951, @werner wrote:

The copy of the database we received for this case is not damaged. A possible problem might be insufficient rights to read the database. For example created with an Admin account and then later used by a different user.

The copy of the database we received for this case is not damaged. A possible problem might be insufficient rights to read the database. For example created with an Admin account and then later used by a different user.

Not easy do decide whether something is a PIN or a PUK and we will need to check a lot of places. So, not now.

Turning this into a feature request: We should create P12 files using AES instead of 3DES

It may be better to open a separate issue for the issue in gpg, so that it's not overlooked/forgotten when the issue in gpgtar is fixed.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

This looks like the same problem I encountered in Gentoo's Portage. To unlock the binary package signing key, Portage will run the equivalent of gpg --homedir ... --digest-algo ... --local-user ... --output /dev/null /dev/null. If unlocking fails (due to e.g. wrong password), /dev/null is removed: https://bugs.gentoo.org/912808

Needs to be checked for 2.4 - no backport to 2.2, though.

Needs to be checked again with stable. No backport to 2..2, though.

Won't be backported to 2.2 once we got something in 2.4.

Sorry, I only now noticed that you used the --export-secret-ssh-key. Unfortunately commit
rGafe5fcda52e88438c7a7278117b2e03f510a9c1c states in the comment:
"Due to time constraints the code is not yet ready." Let's turn this into a feature request.

I do not find this that important because while users tend to repeat actions to ensure that they are _really_ done (e.g. my nephew always saves games twice to ensure that it really was saved) no real harm is done here.

Dear Werner, have you had any toughts about this ?

Thanks for the pointer! I'll see how I can do what ecdh_param_str_from_pk does in gpgme.

The relevant commit is rGc03ba92576e34f791430ab1c68814ff16c81407b

We had to add the parameters because some keys don't use the default paramters PGP and gpg have used since the introduction of ECC 12 years ago. So yes, we could fallback to the standard parameters but it would bet better if Kleopatra could extract them from the public key (maybe via a GPGME helper).

The relevant logs are

2023-07-27 12:08:01 scdaemon[28156] opgp: ecdh parameters missing
2023-07-27 12:08:01 scdaemon[28156] operation writekey result: Invalid value

I can't find a missing forward port; need to debug this issue with gpg4win 4.2.0

yeah, sorry, didn't test different key types yesterday.
NIST encryption keys do not work either, so only RSA encryption keys can be moved with Kleopatra to a smart card in gpg4win 4.2.0.
I can confirm that authentication keys work.

In T6379#172803, @ebo wrote:

Noticed in gpg4win 4.2.0-beta373:

For Brainpool and ed/cv25519 keys it is not possible to move a subkey to a smart card with Kleopatra. The error message is "invalid value".
Moving the main key works, though. The command line works for all keys types, of course.

Noticed in gpg4win 4.2.0-beta373:

Actually it has been fixed for the PBES2 case in 2.2 and 2.4. PBES2 is used with AES128 and AES256. I doubt that there is any value in adding such support for the legacy RC2 and 3DES methods.

with the new gpg.exe you gave me for testing it looks good now:

No. Missing mapping in iobuf.

gpgrt version?

I get a failure status, but a different one.
Seems to be an other issue? But wasn't (ec=112) disk full?
And the disk of the Windows VM must have been running full with that file, before the start there were ~2,6 GB free:

Partly done for 2.4. The cram-octet-string stuff is missing, though.

Closing since the problem doesn't seem to occur if the operation is canceled properly.

Sorry about that. I tested an old build which didn't call gpgme_cancel_async and therefore probably didn't properly close the channels. It seems to work if gpgme_cancel_async is called to cancel the operation.

This option is already used. Running pgrep -a gpg in a loop (and ignoring gpg-agent processes) I get:

Mo 26. Jun 11:29:11 CEST 2023
19111 gpgtar --batch --status-fd 60 --gpg-args --no-tty --gpg-args --charset=utf8 --gpg-args --enable-progress-filter --gpg-args --exit-on-status-write-error --gpg-args --display=:0 --gpg-args --ttyname=/dev/pts/37 --gpg-args --ttytype=xterm-256color --decrypt --directory /tmp/kleopatra-JqIiXu/src -- /home/ingo/dev/g10/src.tar.gpg
19112 gpg --batch --status-fd=60 --output - --decrypt --no-tty --charset=utf8 --enable-progress-filter --exit-on-status-write-error --display=:0 --ttyname=/dev/pts/37 --ttytype=xterm-256color -- /home/ingo/dev/g10/src.tar.gpg

Can you please test by adding --exit-on-status-write-error to the gpg invocation by gpgtar?

We had one request to support this back in 2017 but it was closed because the respective CA stopped using this extension. See T2039.

rGb1ecc8353ae3 is just what I meant, so that we can recommend such an option in the future as a workaround until a new update becomes available which supports such an extension.

Nah, the description for that extension is pretty strict and I won't feel comfortable to just ignore it. BTW there is also T6398 (nameConstraints) which needs support. But for debugging a ignore extension makes sense.

For support reasons I would say that it might make sense to also ignore the extensions from "ignore-cert-extension" when checking CRLs?

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.