Woops, :-s I forgot to also add all these details from additional investigations I already did (obviously assuming it might be helpful ones for definitely fixing issue I reported (and my apologies in advance for whom might find lenght of all this really excessive, 8-) since I simply tried to comprehensively summarize results...)

My apologies for further delay before also providing this screenshot bitmap of error found (because of initially not finding specific site info about best browser to use and not seeing 'cloud symbol' (many thanks werner :-D ) I obviously had to switch from IE11 to MSEdge and then also manually import proper cookies needed for this site :-(( )

In the editor you find a cloud symbol with an arrow to upload a file. Use this and and the file id will be pasted at the cursos, like here

Apologies for my (newbie) comment on this bug reporting system. Since I have a screen shot bitmap better showing error I described, could anyone tell me how to attach to this bug ?

Fixed in 2.3 and 2.2

(I closed this by accident)

looks good to me. Tested now with master 47e425e07995454573e28c13c08229d2f8a75642 and all tests pass for me in and out of FIPS mode as well as in the "soft" one.

I think this issue is solved. For systemd, I need to run this as --supervised option not the --daemon option. The --daemon option has bug.

You could use --disable-keyboxd which should fix this. However, there will eventually be no more way to build w/o Sqlite and thus I would suggest not to allow disabling of sqlite.

This works for me:

I think the behavior makes perfect sense for Unix but the default delimiter for .txt in Windows is \r\n.

The OP wants to do symmetric encryption. This isn't about the passphrase that protects a key.

Yes, we read up to the first LF. This has been the traditional way of PGP2 and is still used by mail programs like Mutt.

I'm guessing gpg in Unix has stripped the \n if present? I don't have access to a real Unix system at the moment.

I see that problem but gpg has traditionally not interpreted the passphrase in any way. Right, for Windows we could strip the CR but I fear that this might break other users scripts/passphrases. However there should be a warning in the manual.

The actual problem is not that --list-packets produces weird output, but that --decrypt fails with

gpg: [don't know]: invalid packet (ctb=4f)
[GNUPG:] NODATA 3

causing confusing errors in Kleopatra.

Based on GCC bugzilla, affected released GCC versions are 11.1 and 11.2.

(ab | ba) >= 0 is used to make optimization analysis for compiler more difficult. I see that with (ab | ba) == 0, it would be much easier for compiler to conclude than loop could exit early as soon as first a[i] != b[i] is seen.

Aihhh, my fault. seems that a new version it not too far away.

See description above.

We will look into it but nevertheless I have to remark that this this portable thing is dangerous to use and you should avoid it.

The same problem. Portable mode is completely broken in v2.3.2 and v2.2.30 on Windows.

Hello Mr. Koch,

I wonder about the spelling errors. For particular

Please show us the output of

Just for the record, Kleopatra and Gpg4win work totally fine for me on Windows-11 preview.

Code for avoiding the COMMON section has been there, because of RISC OS.
I think that it will be easier to enable that for all (but not for RISC OS only).

It is quite likeley that things don't work on a non-released Windows version. We have not tested with the released version but some of us already tried Windows-11 and the gog4win development versions do work. Please wait for the next Gpg4win version or an update of the Windows-11 preview.

Im using Windows 11
Before the restore, he are working fine
Im trying to sign a file
The kleopatra dont show more error info

Package maintainer from PLD here. We still ship Qt4 and therefore provide pinentry qt4 for as long as it's supported. I have no problem with dropping it if it's no longer support, but last release still supported Qt4, there's no mention of dropping such support in NEWS and both code as well as configure.ac appear to still carry Qt4 support which is a bit confusing.

Qt4 is no longer supported. Please use the previous released version plus commit rP2859eddfb0c9: qt: Fix build against Qt4 to build pinentry for Qt4. For everything else use 1.2.0.

Will only be fixed for 2.3 and that has already been released.

I tried applied the bulk of the patch to 2.2 but w/o reading the key creation time from the card. We don't have the supporting code for latter in 2.2. However this does not make sense. Users should switch to 2.3 if they needs this feature.

I have rather created D536 as IMO the timeout should be changed, not the documentation.

We need a more detailed bug report to evaluate your problem. Please tell us your Windows version, any special software installed on the system (if any), a step by step description how to reproduce the bug, and any other information which can help us.

Thanks fro the report. Unfortunately I am not able to reproduce this on our systems. It might be an issue with other software on your system or a problem in our code. This is the first such report and as long as we don't get reports from other users, we can't do much for you. Please try installing on a different system or if you can provide more information feel free to re-open this bug report.

Will do.

To fix this, rG48251cf9a7d3: gpg: Improve generation of keys stored on card (brainpool,cv25519). for GnuPG 2.3 should be backported.

Fixed in libgcrypt 1.9.4.

Fixed in 2.3.2.

It must be fixed in 2.3.2. If not, please report.

Oh yes, I was blind.

Here is the place:
https://dev.gnupg.org/source/gnupg/browse/master/g10/pubkey-enc.c$151

A cursory look doesn't show me where list->result is set to something else than -1. Can you give me a hint?

In GnuPG 2.3, the procedure of decryption has been changed;
It now collects all ENC_TO packet, keeping it to ->PKENC_LIST field, and then process ENCRYPTED packet with the list.

So it is related to code page. Screenshots may be more informative:

After several days of observation, after modifying the configuration file options , the problem has indeed been greatly alleviated.

Fallout from the fact that the @cbiedl left us and had an internal non-tagged ticket left open (T5456)

I see whats going on. The GitHub gpgme mirror (https://github.com/gpg/gpgme) is no longer updated. The last commit is from June 22, 2021. Changing the source link to the official (https://dev.gnupg.org/source/gpgme) URL gets the latest updates, and now builds successfully.

This has already been fixed with rM4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e

Frankly, I don fully understand your report. Can you please clarify?
Note that with 2.2.8 we introduced full Unicode support on the command line. If you see scrambled output you may want to "chcp 65001" to get the output correctly rendered.

I have recently been busy with the new features and mechanisms of the GpgFrontend project.

In T5436#148656, @cnp1234 wrote:

I added "disable-application piv" to ~/.gnupg/scdaemon.conf and the behavior went back to pin caching working as before. Since I don't use PIV, this is an acceptable workaround for me.

I added some asserts. However I doubt that it can be hit by LibKSBA. I also fixed a real bug related to VALTYPE_BOOL - but that is also not used in Libksba.