- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 12 2021
Aug 11 2021
@fvogt I've now added a logging category. Thanks for the suggestion.
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.
Aug 9 2021
Aug 5 2021
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.
Okay, the problem with run-encrypt (and maybe also Kleopatra if it also uses gpgme_data_... and sets a size hint) is that gpgme_data_seek casts the result of seek(..., 0, SEEK_END) which is of type gpgme_off_t to int to accommodate as tracing macro/function:
return TRACE_SYSRES ((int)offset);
Changing this line to a simple
return offset;
fixes the progress reporting of run-encrypt.
Hmm, nope. gpg outputs
[GNUPG:] PROGRESS largefile5G ? 0 5120 MiB
if I run
$ gpg --symmetric --enable-progress-filter --status-fd 1 --output /dev/null largefile5G
I have added some debug output to _gpgme_progress_status_handler. For the 5G file gpg seems to output
-&11 ? 0 1048576 KiB
for PROGRESS. So, the value of total is already wrong in gpg.
This can be easily reproduced with run-encrypt from gpgme/tests:
$ fallocate -l 1G largefile1G $ fallocate -l 2G largefile2G $ fallocate -l 3G largefile3G $ fallocate -l 4G largefile4G $ fallocate -l 5G largefile5G $ ./run-encrypt --progress --loopback largefile1G >/dev/null progress for '-&11' 0% (0 of 1048576) progress for '-&11' 0% (64 of 1048576) progress for '-&11' 6% (66816 of 1048576) progress for '-&11' 16% (172928 of 1048576) ^C $ ./run-encrypt --progress --loopback largefile2G >/dev/null progress for '-&11' 0 progress for '-&11' 65536 progress for '-&11' 56896 progress for '-&11' 155776 progress for '-&11' 249344 ^C $ ./run-encrypt --progress --loopback largefile3G >/dev/null progress for '-&11' 0 progress for '-&11' 65536 progress for '-&11' 105216 progress for '-&11' 212480 ^C $ ./run-encrypt --progress --loopback largefile4G >/dev/null progress for '-&11' 0 progress for '-&11' 57856 progress for '-&11' 168768 ^C $ ./run-encrypt --progress --loopback largefile5G >/dev/null progress for '-&11' 0% (0 of 1048576) progress for '-&11' 0% (64 of 1048576) progress for '-&11' 11% (115840 of 1048576) ^C
The progress callback of run-encrypt looks like this:
static void progress_cb (void *opaque, const char *what, int type, int current, int total) { (void)opaque; (void)type;
Aug 2 2021
Should now work for pinentry-qt on Wayland even if DISPLAY is not set.
This has been fixed with rP9dd46926f8d5: qt: Fix showing of pinentry window on Wayland.
Notification when trying to enter empty passphrase:
Notification when trying to enter passphrase that does not satisfy multiple constraints:
Notification when trying to enter passphrase that is too short:
I propose the following patch to inform the user about the obsolete --secret-keyring option. The same is done for many other obsolete options.
Jul 28 2021
Jul 26 2021
@aheinecke Please test this on Windows
Jul 22 2021
Implemented for X11 and Windows.
Jul 21 2021
GnuPG 2.2.29 does not use keys.gnupg.net anymore. What it does is mapping keys.gnupg.net that is read from an (old) keyserver setting in the configuration files to a (hopefully) working keyserver. The documentation of gpg and dirmngr does indeed still mention keys.gnupg.net. The main problem with updating the documentation is that there isn't a good replacement for keys.gnupg.net and since keys.gnupg.net still works (via the aforementioned internal mapping) it is probably the best option for now.
Jul 19 2021
For formatting there are four modes: Formatting forced off (the default)/force on/on/off. The latter two modes allow the user to change the option.
This is a duplicate of T5522: gpgme: qt: t-various.cpp TestVarious::testSignKeyWithExpiration fails on 32 bit.
Jul 15 2021
Jul 12 2021
Jul 8 2021
Jul 7 2021
What do you mean by "exporting revocation certificates"? Once such a certificate is imported you simply export the public key including the revocation signature. Otherwise, simply takes the revocation certificates from ${GNUPGHOME}/openpgp-revocs.d where they are written to, if you generate a key. Kleopatra uses gpg directly to generate a revocation certificate mimicking what gpgme would do: See https://dev.gnupg.org/source/kleo/browse/master/src/commands/genrevokecommand.cpp.