Okay, makes sense.

No, it is widely understood as a means for reproducible builds and specified at: https://reproducible-builds.org/docs/source-date-epoch/

SOURCE_DATE_EPOCH is NixOS specific?

Well, I had simply accepted that the rule for defsincdate is always triggered. I looked a bit more into it, and the cause for triggering is that Nixpkgs patches dirmngr.texi, hence defsincdate is cleared by the rule above and the fallback behaviour is triggered.
But this also means my suggested patch wouldn't help here as the modification date of dirmngr.texi would be picked up.

Looking at the rules I do not understand why we have a problem here, the rule

I think an option to ignore certain files is a better way to do this. I'll give it a try.

"Wyszukaj na na serwerze..." has been changed to "Wyszukaj na serwerze..." and should appear in the next release of Kleopatra.

Thanks for the logs. I can see the crashes, but I can't make heads or tails of them. We crash in completely valid code. I really don't want to play the blame game here but to me this would be explainable if there is an issue with refcounting in the GFI plugin that would release the IMessage or ISecureMessage MAPI Object from the ItemLoad event once to many. In that case the object we work with might be deleted at random times and that would explain it.

After looking at this for 4h I could not see a way to detect it better when a print job is done. So we now treat every ItemLoad of a mail after we have seen the BeforePrint event as a print.

Outlook is a bit nasty here:

I added the log file.

Thanks. Applied. Will go into 1.4.0

It'll be fixed soon. Please use https://sourceforge.net/p/kdei18n-pl/mailman/kdei18n-pl-uwagi/ next time.

could you please go into the GpgOL setting and under "Debug" turn on logging on the highest level (+code trace) and then reproduce the crash and add the log here?
Including Data should not be needed so you can keep that checkbox unchecked to avoid having mail data in the logs.
This might help us to see where and why the crash occurs.

The fix has been submitted to Kleopatra master

@aheinecke right, it's also fixed.

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.

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

@aheinecke thanks for commenting.

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.

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

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.

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.

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

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

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?

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

Any progress on this one?

I debugged some more.

It is the pinentry-curses, which is needed to reproduce the problem.
Using tab and Return to navigate the dialog.
After pressing ok, the password question dialog reappears. I tried 20 times to press ok, every time the password question dialog reappeared.
If I press cancel, the process aborts. So I'm sure, I hit the right button.

And yes: If I install pinentry-gtk2 and follow the steps, it works as excepted.

Perhaps I explain the steps, I'm doing.
I'm on a minimal debian buster instance.

1. gpg2 --full-gen-key
2. Insert stuff.
3. See Dialog:

Real name: Test1 Tester
Email address: test1@example.com
Comment: no pw
You selected this USER-ID:

"Test1 Tester (no pw) <test1@example.com>"

Ok. Renamed ist "ttytype_l" (l for local) and found the button to upload a file.
Hope it helps.

Using a double underscore in a symbol should be avoided because such symbols are reserved for system use.
(To include a diff inline, please intend it by two spaces so that it is not not considered as marked up text.)

Thanks. I tried to install the latest released version, 1.4.23, but I got the same error.

That is a very old version (2015); please retry using the latest released version 1.4.23 (from 2018).

I just tried and Pinentry ask me whether I really want to use an unprotected key. Take care that you hit the right button.

The issue has been fixed in Kleopatra: https://commits.kde.org/kleopatra/15ce46717636cecd1c1b8949d12b0ab6c3fed69a

I back ported @jukivili's changes back to 2.2 which gives a CFB decryption speedup of 25%. I also implemented AEAD _decryption_ in 2.2 to be prepared for mixed 2.2 and 2.3 version use. And AEAD is really fast compared to CFB. Willbe in 2.2.21.

Thanks for testing. It's actually an error of generating _unicode_mapping.c, which utf8.c includes.

Thanks for reporting; the code is really new and not yet fully tested.

I can't find any places where it is interpreted as signed integer.

I'm honestly surprised this isn't being given any sort of priority.
gnupg for windows is simply broken. Even Kleopatra, its supplied and designated key management application doesn't work re: keyserver communication.

There are no betas; either you apply the patch mentioned above ( rG2f08a4f25df7) to a stock 2.2.20 or you build from the Git repo (STABLE-BRANCH-2-2, see https://gnupg.org/download/git.html).

thanks a lot dkg and werner :)

Could you guide me to where I find the beta or snapshot, so I could test it and give you feedback? I seem to be unable to find it on my own.

Noch was: Die Tipps für die Passphrase auf Seite 26 sind teilweise katastrophal. Der Tipp mit "jeden 3. Buchstaben" sollte entfallen. Die Überschrift heißt doch Passphrase, nicht Passwort. Eine Phrase kann gerne lang sein und auch vollständige Wörter enthalten, es müssen nur genug davon sein.

That's odd. :-)

FWIW, the code was written by the author of the specs and he note in his original patch (rGe0972d3d96) :

Thanks for your report. The problem of GnuPG was that it mandated padding length < 16 bytes, which is wrong.

In T4909#134002, @werner wrote:

• Is it a PGP 2 key (OpenPGP version 3 key format)? Support for this has been removed from gnupg 2 for security reasons.

The key was generated with gpg (not gpg2).

• Did you created or imported the key with gpg 1 after you installed GnuPG 2?

Yes.

In this cae, use gpg 1 to export the key and then import it again using gpg 2.

Importing the secret keys gives:

Please explain what your problems is. Setting arbitrary debug flags is not helpful for your or us.