I see.

BTW, the reason of the name "pkey" is that because gcry_pk_ctl is already occupied.
It will be changed, if needed.

Today, I pushed an example for RSA-PSS.

I have approved the commit in KDE's GitLab. For details see https://invent.kde.org/pim/kleopatra/-/merge_requests/8

Fixed in 2.3 and 2.2

The task is T5577 (which I accidently closed during triage)

(I closed this by accident)

This commit breaks decryption of symmetrically encrypted data. gpg-agent segfaults after one has entered the passphrase in pinentry.

I added couple of minor comments. I hope they went into somewhere.

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 created an experimental branch:
https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Fnew-pk-api/

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.

Nevermind, I found the appropriate link above, thanks again.

Thanks for noticing me but I can't access your git repository at https://dev.gnupg.org/source/gnupg.git and the github mirror at https://github.com/gpg/gpgme is not up to date. Do you have an other mirror?

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.

Thanks. This has already been fixed in July with rM4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e

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.

I filed a bug report to GCC, with modified test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102151

gpg verifies the content of the file and not its meta data (file name). Thus an empty file is identical to a non-existing file. The OpenPGP protocol does not allow to distinguish between a detached signature and an embedded signature if you sign an empty file.

I think this behaviour has something to do with "attached signature"?!

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

The problem was created during a migration of the host operating system and acme client tools.

See description above.