- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 12 2021
I can confirm that Kleopatra seems to use the system's locale and not the system language, using English language with Dutch locales myself. The language selection dialog shows the correct languages (en_GB as primary and en_US as fallback) but the interface is Dutch.
Kleopatra 3.1.16 on Windows 10 21H1
Aug 11 2021
@fvogt I've now added a logging category. Thanks for the suggestion.
Yes, I infer that the problem lies in the network-related modules. Because this waiting time is too long, it is probably not a problem of calculation and disk.
Which reminds me that we should add a cronjob feature to dirmngr (which already does some background tasks) so that we can easiliy make use of --no-auto-check-trustdb on Windows.
Aug 10 2021
This could be caused by the periodic automatic update of the Web of Trust information. See --auto-check-trustdb in man gpg.
Let me try, this problem sometimes happens, so it may takes some time to come to a conclusion.
But what I know is that after experiencing slow loading, it will not appear again when it is opened again later.
Is there any change if you enable the keyboxd to store the keys? Put
Aug 9 2021
Yeah, that sounds good to me.
Aug 8 2021
In T5551#148510, @werner wrote:I would prefer to see a fix/hack in pinentry-qt instead.
Aug 7 2021
Aug 6 2021
I see. Thanks!
To minimize the risk of regressions.
Not to be bothersome, but why? DISPLAY seems like the universal method of selecting a display to put things on, where a lot of applications don't support --display or equivalent, especially now there's no equivalent for wayland. It's especially confusing to me when the keep-display option will pass DISPLAY instead of --display. This would also prevent other such scenarios with 3rd party qt/gtk plugins or alternative pinentry implementations.
I would prefer to see a fix/hack in pinentry-qt instead.
Proposed patch:
--- gnupg-2.2.27.orig/agent/call-pinentry.c +++ gnupg-2.2.27/agent/call-pinentry.c @@ -202,13 +202,14 @@
Here is the documentation of the new way of single-threaded execution:
https://www.gnu.org/software/libc/manual/html_node/Single_002dThreaded.html
Aug 5 2021
We also need to update m4/threadlib.m4.
Now, it's maintained in gnulib.
See the changes in:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=12b5b00f93c6433c3df8176fc9674d7600f8b268
Aug 4 2021
AllowSetForegroundWindow did not work but the code from pinentry works even without the minimize / raise. The minimize raise is only required for the proper input focus and a nice animation for pinentry but the QWindowsWindowBehavior is already sufficient.
I am pretty sure that an AllowSetForegroundWindow in the kuniqueservice_win implementation in Kleopatra will alleviate this issue. Since we pass a double click on a file which has foreground window permissions to the existing process which at this point may not have foreground window permissions. If this still does not help we can do the minimize / maximize trick.
Ingo, I have tested this on Windows with NV Access and was able to symmetrically encrypt and decrypt a file with closed eyes. I went through the windows explorer context menu to select sign & encrypt on selected files.
Can you also do some more tests on Linux ( I do not know how to properly enable a screenreader there ) and if you find anything ugly fix it.
As far as I understood, $WAYLAND_DISPLAY does not need to be set because there is a well-defined default, but I guess most of the time it's set anyway.
Ah, I understand the point (at least, partially); My understanding is: With FIPS mode, at the module boundary (== libgcrypt), it ensures that all cipher/digest/etc. operations are done under the standard compliance, and it is considered wrong (violation) when non-FIPS mode operation (such as SHA-1) and FIPS mode operation are mixed.
Aug 3 2021
QGuiApplication checks $XDG_SESSION_TYPE maybe to find out whether to use X11 or Wayland if $DISPLAY and $WAYLAND_DISPLAY are both set.
The fix in gpgme fixes the progress when encrypting/decrypting large files with Kleopatra. At least, on Linux.
In RHEL, we do not have anything about PCT so the PCT requirement is not completely clear to me: https://git.centos.org/rpms/libgcrypt/blob/c8s/f/SOURCES
Cool