I have fixed this as a7349189f3af05822eba4bd17b62482fa2b0747f so I am closing this as a duplicate of T5982 because it is clear to me now that the problem was sending and no receiving such mails and was broken by 9f81ed6561c5f41e50d1a51333c9586a33ed2ef6

This was fixed by c0ca4f1b254f6879d719d1a5ed43a51ca9015b93 since the embedded message was not handled it was not extracted / parsed into an Attachment C++ Object which caused this error. I don't want to change the status of tasks which are not assigned to me but i saw it while looking over my open assigned tickets.

show English or Turkish strings?

Jan, you please run something like

I am sorry, that I can't give it a high priority. See the discussion on the mailing list. I'll try my best, though.

It's a bug I introduced when fixing T7309.
Fixed in rGaa36f6ae8bae: gpg: Fix key generation with existing key from card.

@uwi: We removed the ciphersuite from the server and tested with 4.2.0 that you get an update notification now. Because of some caching you may need to

This is due to an update of the server providing the version info. The server (Apache) uses a smaller hash than the ECC key. This is allowed behaviour and was fixed in our TLS library in 2022; see T6059. However, the new library was released only early this year an. We will check whether we can tell our Apache to use a more correct hash algorithm.

In T7454#195889, @ikloecker wrote:

Which dialogs? pinentry? If yes, then your assumption is correct. pinentry also gets the texts from GnuPG.

Which dialogs? pinentry? If yes, then your assumption is correct. pinentry also gets the texts from GnuPG.

There is another customer request for this too.

IIUC, simpler solution would be modifying m4/socklen.m4 adding Solaris variant specific code.
Tweaking _XOPEN_SOURCE requires the change of Autoconf (if done correctly), which would be larger surgery.

Not sure about gpg4win 4.2.0 but we had a bug in 4.3.0 which has been resolved with T6985

Tested with a Gpg4win-Beta and VSD-3.2.94.474-Beta:

Closing since the cause for this was identified.

My comment referred exclusively to Tobias's "In the future [...]" comment.

This is what Tobias means:

Isn't the name of the tab showing the imported certificates "Imported Certficates" or something like that? The filter "All" shows all imported certificates. And when you select the filter OpenPGP you see the subset of imported OpenPGP certificates. Therefore, I don't think it makes sense to add a custom filter.

tested with Gpg4win 4.4

@ilf: Yes these message are emitted using log_info in 2.4.7 and 2.5.2. Thus they don't case a failure exit. I will silence them with --quiet in 2.5.3.

https://lists.gnupg.org/pipermail/gnupg-devel/2024-December/035686.html <- is a question to see if the situation has changed meanwhile. (I've send it to the list because the topic affects several things in the application and thus ggoes beyond an issue like this one.)

This doesn't happen anymore now that we offer all valid user IDs and not just the primary user IDs.

Backported for VSD 3.3 / Gpg4win 4.4.1.

I'll backport this for VSD 3.3 / Gpg4win 4.4.1. Regression risk is minimal.

Gpg4win 4.4.0 has just been released. Creation of encrypted archives has been completely reworked with Gpg4win 4.3.0 already. I could create an encrypted archive containing the two files with GpgEX without problems.

Gpg4win 4.4.0 has just been released. I cannot reproduce unexpected results when doing a lookup on server. Unfortunately, many keyservers do not publish the user IDs (i.e. name and/or email address) anymore. Kleopatra does not list results without user IDs because GnuPG won't import them anyway.

This has been fixed in the meantime. If you should still experience this problem with Gpg4win 4.4.0 then reopen this ticket.

Gpg4win 4.4.0 has just been released. I assume that this has been fixed in the meantime. In particular, "General error" should happen a lot less. If the problem still occurs with Gpg4win 4.4.0 then reopen the ticket.

This ticket is obsolete

I assume the problem has been resolved because we never got feedback that the problem persists.

This problem has been fixed quite some time ago. See https://bugs.kde.org/show_bug.cgi?id=415168.

This doesn't look like a problem in Kleopatra.

We won't revert to the old UI which had its own share of problems. In the meantime Kleopatra supports certificate groups which should help if you often need to encrypt for the same keys.

I get this message even with --quiet:

Fixed in 2.5.0 and 2.4.6.

Fixed in 2.5.0 and 2.4.6.

Fixed in 2.4.6.

Fixed in 2.4.6.

Fixed in 2.4.6.

I believe this was fixed by T7386. Or it is now no hard lock up by T7402.
So, let me close this ticket.
If any new symptom, please add information into T7396.

Gpg4win-Beta-94: works

Well, T6893 was removed from this release, at least for the windows builds, therefore this ticket can not be tested on windows for vsd33

tested with Gpg4win-Beta-75++

For this ticket, I reviewed the code around my SOS changes.
Because I'd like to focus the point of retaining binary representation when doing import->export,
I created another thicket: T7426