works in 3.1.27.0-beta44

This has been solved loooong ago.

Actually this is about improving an error message.

@tlaurion Thank you for the report, but your particular problem is irrelevant to this ticket.
I lightly looked the log and noticed that the cross build would have some confusions for pkg-config, however, that's not our problem but yours.
For the particular failures in your build, the issues look like a problem of musl linker. It seems that it requires all dependency of libraries to be used, even if an executable doesn't use a library directly.
If it is the case, we need a patch... something like:

@gniibe
Trying to crosscompile newer 2.4 gpg toolstack from Heads OSF under PR https://github.com/osresearch/heads/pull/1350

It seems like you're having trouble decrypting an old email after upgrading to Debian Stretch and encountering issues with the GnuPG version 2.1.18. It appears that you have followed the recommended migration process by having the .gpg-v21-migrated file and the empty private-keys-v1.d directory. However, you are still unable to decrypt your email 🔑.

Fixed in master (of libgpg-error).
Pushed the change to libgcrypt (master and 1.10 branch).

works in gnupg24.

I'd say yes.

Thank you for the bug report.

@gniibe: Would you mind to look at this?

README and INSTALL now suggest to to use a build directory.

Error checking of the parameter file is usually enhanced when adding new features. Keeping this task open for this specific request does not make sense,

Fixed.

FYI: Quite some more days than a few passed by. I still did not found the time for this, sorry.

Hi @werner,
I understand we should use --with-libksba-prefix, but it doesn't work:

That is not a bug but required for backward compatibility. See me/ksba.m4:

Hint: When the user disabled GpgOL -> Automation -> Automatically secure messages in the configuration of GpgOL he could see the email body again.

This isn't a support forum. You'd better ask on the gnupg-users mailing list before assuming that you found a bug.

Closing this one - see T6378

Fixed in 2.2 need to check 2.4

Ooops. We do not have the automatic chnage of key type in the WRITEKEY command of scdaemon. This is only done when generating a key.

There is actually a regression wit Yubikeys. The fix for 2.2 is in T5100: rG08cc34911470 - for 2.4 I need to check

I agree. Something called READ... shouldn't change existing data. (Updating existing data to a new format that doesn't alter the semantics of the existing data is okay.)

Ignoring the error seems to be the best choice. I also think that --force should not overwrite a shadow key file. It seems safer to explicitly delete the key first. A --force option for READKEY does not sound right.

I did some reworking and the outcome of the READKEY command is now (agent log):

I checked it: There was an empty bin/gpgconf.ctl, and there still is.
Trying it again today, I still get error messages most notably about failed self-tests, but surprisingly the window is no longer empty.
Instead it seems to take an eternity (minutes, actually still not finished after three minutes) until the certificate cache is loaded.
Maybe the problem is the "Check Point Endpoint Security" being active on the client. It looks as if it prevents use of Kleopatra.
As I don't have administrator rights ("for security reasons"), I cannot analyze what's actually going on.

It seems that you are missing the step "Create a new file called gpgconf.ctl in the folder Gpg4win_Portable/bin."

I am pretty sure we have the same problem in 2.4 - due to different access patterns it might not exhibit itself.

I've run into a variant of this, too. If I generate they key just using (genkey (ecc (curve "Ed25519"))). One needs to use (genkey (ecc (curve "Ed25519")(flags eddsa)))

Its not used, so it can't harm.

Also recall that Antivirus software needs to search for a competitive advantage over other vendors and in particular over Windows Defender. Thus they need to show some extra positives compared to the Windows Defender. Who care whether this is a false positive - ppl like to get some evidence that their new AV software has a (phoney) advantage.

Many thanks for the information. I suspected it also, but wanted your assessment.

Well, virus checkers aren't perfect. If 1 out of 65 checkers reports a finding, then the probability that this finding is a false positive is very high. You would better report this to the vendor of NANO-Antivirus, so that they can fix the false positive warning.

Applied your patch (from gitlab) to both (master and 1.10).

Applied to both (1.10 and master).

You are right, there is no way to use DRBG with SHA384 by libgcrypt.

Applied to both (1.10 and master).

Applied to both (of 1.10 and master).

Thank you!

Looks like the TERM alacritty was the culprit, I'm ssh'ing into the freebsd machine from my archlinux laptop.

We discussed this further with the lab and there are more problematic flags that we need to "cut" and we can not do that always in the code as for example the RFC6979 (deterministic ECDSA signatures) are not allowed in the current version of the FIPS documents, but it is used in the selftests (which is weirdly enough allowed) so we just need to mark it unapproved. Lets discuss this further tomorrow.

I don't know what is going here really. I have installed alacritty and I can reproduce T4924 easily if I provide an empty passphrase on an narrow window. At least I get pinentry-curses popping up.

@ikloecker not sure we are there yet. I was able to set a weak password on a terminal that was 42 characters wide. I think the problem here is unrelated to FreeBSD but to the fact that @capitol uses acritty https://github.com/alacritty/alacritty

If agent_write_shadow_key does now also check for an existing private key file, then I'd replace following code in cmd_readkey:

if (agent_key_available (grip))
  {
    /* Shadow-key is not available in our key storage.  */
    rc = agent_write_shadow_key (0, grip, serialno, keyid, pkbuf, 0,
                                 dispserialno);
  }
else
  {
    /* Shadow-key is available in our key storage but ne check
     * whether we need to update it with a new display-s/n or
     * whatever.  */
    rc = agent_write_shadow_key (1, grip, serialno, keyid, pkbuf, 0,
                                 dispserialno);
  }

with a simple call of agent_write_shadow_key (removing the maybe_update flag) and let agent_write_shadow_key do all checking for an already existing private key file and whether it's a stub file that needs updating.

Could this be a duplicate of T4924: pinentry: pinentry-curses doesn't allow to set no password or weak passwords on 80 char width and smaller terminals?

I think we should make it explicit - this will be safer. As of now agent_write_shadow_key will do a check only in its special update mode which should be okay for now.

I can't see any explicit thing there.

$term is 'alacritty', stty -a is:

speed 38400 baud; 54 rows; 180 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
	-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
	-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff -ixany -imaxbel -ignbrk
	brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
	-dtrflow -mdmbuf rtsdtr
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
	eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
	lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
	status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

The agent.log says that the error comes from pinentry-curses:

Hi, thanks for the quick turnaround

I tried to reproduce on my FreeBSD 14 machine and didn't get an error....

Make sure that the fix doesn't break "gpg --edit-key; keytocard; save" which explicitly does replace the private key with a stub file.

I doubt that the bug is only in 2.2. The code in 2.4 is different but it may happen there anyway. It depends on the usage pattern.