I see no reason to not allow decryption of an entire folder recursively. The user knows what they are doing by right-clicking a folder instead of a file. You can show a progress dialog with a cancel button.

Signing using ECDSA does now also work. Tested with 3 in disk keys: nistp256, nistp384 and RSA and verified using gpgsm and Governikus Signer.

The fix has been submitted to Kleopatra master

@aheinecke right, it's also fixed.

Basic en- and decryption test against Governikus_Signer has now been done. Beware: I had to add a debug option to gpgsm to workaround non-compliance in algorithm support of Governikus; see the rG68b857df13c8a4e6cae5e3a29fd065bf90764547 for details.

Cool. Falls du einen Korrekturleser für die neue Fassung brauchst, sag gerne Bescheid. Ich hab da Erfahrung …

I'm not sure what to do here. The problem is that all users in clients without PGP/MIME Support will see the attachment names. That is why we use the names as they are.

hello
thanks for the feedback
it s indeed exchange 2007 (migration planned on long term)
we will try the imap workaround

There was a similar Problem in the past reported on our mailing list:

Thank you for your work, appreciated. Sorry I was a bit under the weather in April and could not get back to you earlier.

erstmal vielen dank für das Feedback. Ich habe momentan als Aufgabe ein neues Benutzerhandbuch auf Basis des Kompendiums zu erstellen und werde da die Hinweise auch mit Aufnehmen. Technisch ist sowohl der Inhalt als auch die Art wie das Handbuch erzeugt wird nicht mehr aktuell, wir brauchen da dringend etwas neues das wir auch online stellen können.
Sollte noch in diesem Jahr passieren.

Right. GpgEX is in serious need of polishing. I'm not sure if I'm in favor of processing all files recursively. But then the decrypt option should not even be shown.

From the commit message:

Thanks, I can reproduce the problem. I'll look into it, printing mails is important for some ;-)

@aheinecke thanks for commenting.

In T4932#134540, @aheinecke wrote:

If you have -g / -Og could you please provide a backtrace?

Does it decrypt then?

This is not the first report I have gotten about mailstore problems. My suspicion here is that the mail is opened read only or somehow got the wrong properties from mailstore.

Thanks for the patch, applied!
You are correct the NEWS file states that this was added in 1.9.0

I can reproduce this.

I've just tried the test suite of GnuPG 1.4.23 on debian buster and all tests pass.

I keep it open as testing so that we keep it in mind for a release.

There was a patch for this by david faure which added an
#undef ttytype after including curses.h

Thanks for the report.

I'm working on better support for Smartcards and esp. multiple smartcards in Kleopatra. IMO it should not be required for a user to explicitly write a reader port in the config.

I'm giving this an initial priority of "Normal" so that it's out of the triage list.

If you have -g / -Og could you please provide a backtrace?

Hi,
sorry we cannot help you with that. The keyservers might have unreliable results. It would only be a bug in Kleopatra if GnuPG on the Command line would find a key and kleopatra wont. Does it find other keys?
So you can try on the command line with "gpg --search foo@bar.baz" this would also show you on which server the keys are searched.

Thanks for the report I tried to reproduce this but cannot reproduce the mentioned behavior. So for now Low priority until we have found a way to reproduce it. I have tried unencrypted and encrypted mails and it works as expected.

I have opened T4939 to add the keylist mode with keygrip.

To end the failures I have modified the test, that needed to be done anyway since different versions of GnuPG behave differently.

Your guess is correct, but as this hole "Wizard" thing uses Qt Regular expressions its not super quick fix without having to introduce new strings etc.
So I just reduced the length. The new key generation in Kleopatra is pending a rewrite anyway. Requires way too many clicks ATM.

2022-01-01 00:00:00 aka 2021-12-31 24:00:00

Taking a look at other GNU manuals, both GNU make and GNU Bison have a better phrasing,
so I suggest the Bison way (https://www.gnu.org/software/bison/manual/html_node/index.html):

This manual (7 December 2019) is for GNU Bison (version 3.5), the GNU parser generator.

Ah, okay, then the phrasing is missleading, the sentence looks like libgcrypt was released on this date and not the manual.

Moscow time is 3 hours ahead of UTC, so we are talking about midnight 2022-01-01 00:00:00 aka 2021-12-31 24:00:00 . This is way we say we are 1 minute off. But I now see the problem, AWK's strftime needs another arg to to print in UTC. I am not so used strftime because I always use a my tool epoch2iso to convert Epoch times.

gpg -k --with-colons <anotherkeyid> | awk -F: '$1=="pub" { print strftime("%F %T", $7, 1) }'

So we are a minute off.