Thanks for the info. So I guess me added that restrictions to be on the safe side regarding the VS-Nfd evaluation. For 1.9 we can and should lift that.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 5 2020
Please see [1] appendix F - I tested it more or less on all major CPUs, small
and large, old and new:
Jun 4 2020
AFAIK, Stephan evaluated it only for x86, let me ask him ...
Jun 3 2020
Done.
Thanks. I bumped it up to be in sync with GnuPG 2.2. It also does not make sense to require a Libgcrypt which has reached end-of-life; Thus we now need 1.8.
I bumped up the requirement to 1.25 because we also use error codes defined there. To be on the safe side with older distros I defined the missing error code instead of requiring 1.27.
Thanks for the report.
I now describe the shortcuts as development and 2.2 stable branch.
Jun 2 2020
The problem is with the code for T3656
Thanks for the report. I can reproduce this by replying to S/MIME enc & sign mails.
@Angel: The mail server log showed 0 bytes for the affected messages.
While triaging issues this looks to me more like a support case. And not an issue of the software itself. So I'm closing this issue.
As of now we doubt that the proposed patch helps and we even fear that it could make things worst. Thus, as long as there is we have no description of an attack we won't do anything about it.
Jun 1 2020
Are they actually zero-byte mails, or is the content mungled as an attachment? (which those replying probably overlooked, and would still be hard to interpret, as it would containe MIME parts)
May 29 2020
Although this is a standard behaviour for Unix tools, you are right that it makes sense to tell the user about the problems. And well, the version info should not appear either.
May 28 2020
May 27 2020
I observe the same problem since I installed gpg4win 3.1.11 (german) in Outlook, Office Professional Plus 2019, Version 2004: Occasionally "zero byte mails" are sent by replying to an s/mine certified and encrypted mail. In my case the option s/mine support is disabled in GpgOL menu.
May 21 2020
Fixed in master and applied to 2.2 branch too.
May 20 2020
Sorry, I was reading the next commit (libdns: Avoid using compound literals (3)).
I have to disagree. Unless I am completely confused the modified functions use automatic buffer variable and then basically return it.
Robin H. Johnson created a patch for this:
Possibly, it would be dns_p_init which was caught. If so, it's false positive; It returns a pointer given to the function (which is automatic variable of parent function), but it is valid within the scope of parent function.
Could you please show more information, a specific point of the bug?
I can't locate any place where a function returns a pointer to automatic buffer.
May 19 2020
Seems to be fixed now.
Closing with Info Needed.
May 18 2020
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?
May 17 2020
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.
May 16 2020
"Wyszukaj na na serwerze..." has been changed to "Wyszukaj na serwerze..." and should appear in the next release of Kleopatra.
May 15 2020
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:
May 14 2020
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.
May 12 2020
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.
May 11 2020
May 10 2020
The fix has been submitted to Kleopatra master
@aheinecke right, it's also fixed.
May 8 2020
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.
May 5 2020
2022-01-01 00:00:00 aka 2021-12-31 24:00:00
May 4 2020
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
gpg -k --with-colons KEYID | awk -F: '$1=="pub" {print $7}'
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).
May 3 2020
Apr 30 2020
Any progress on this one?
I debugged some more.
Apr 29 2020
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.
Apr 27 2020
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.
- gpg2 --full-gen-key
- Insert stuff.
- 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>"
Apr 26 2020
Ok. Renamed ist "ttytype_l" (l for local) and found the button to upload a file.
Hope it helps.