@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.

So we are a minute off. The expiration timestamp is not stored in the key, instead the difference to the creation timestamp is give. This makes it a bit challenging to get it always right. Did you tried

Thanks

Nope, that is correct, the last update of the manual was

Oops, I am sorry for the confusion. This patch is the correct one. The patch originally attached contains also revert of the commit I've reported in the other bug report today.

@gniibe, will you be so kind and look into this?

It works for me(tm).

In T4933#134421, @werner wrote:

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

and that in ISO 8601 format

Right, we do have this option only in master (devel version).

I can't find such option.

How does it show when you specify --full-time-strings (in UTC by ISO time format)?
I wonder if it is valid as data, but there is a problem of showing key(s).

Attaching the actual program

Any progress on this one?

I debugged some more.

Yes, with current gnupg it works w/o problems. Well, unless systemd decided to remove the directory. There is a loginctl(1) way to avoid this.