This has been addressed with T6878: Kleopatra: Subkey expiry date improvements by showing the expiration date of the primary key if the subkey doesn't have an expiration date.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 30 2024
Sep 27 2024
Yes, for historical reasons (i.e. we haven't changed this) the width of the name and email columns always defaults to 260.
Sep 26 2024
V5 keys should now work as good as V4 keys in Kleopatra. For testing create a "Curve 448" key and then try a few things. Everything should just work because it works for gpg. Kleopatra doesn't really do anything special for V5 keys.
Done. I don't think this needs to be tested extensively because it's just some UI texts that now show the Key ID (with 16 hex chars) instead of the short Key ID (8 hex chars). And for files including key material we also use the Key ID (of primary key and/or subkey) now for the filenames, e.g. when exporting a public/secret key/subkey.
The change will also be included in VSD 3.3.
The version check can now be extended to 2.2.45 <= gpg < 2.3.0.
werner: Can you also backport listing of "default-new-key-adsk" with gpgconf so that Kleopatra can check whether a default ADSK is set?
Fixed. Ready for testing.
Backported for VSD 3.3.
The fix needs to be backported for VSD 3.3.
Backtrace:
#0 0x00007ffff6643d10 in QAbstractItemView::selectionModel() const () at /lib64/libQt6Widgets.so.6
#1 0x00000000006fe608 in Kleo::KeyListController::Private::updateActions(KActionCollection*)
(this=0x7fffe4005540, collection=0xdd7ae0) at /home/ingo/dev/kde/kleopatra/src/view/keylistcontroller.cpp:1141
#2 0x00007ffff51da593 in () at /lib64/libQt6Core.so.6
#3 0x00007ffff7ad2655 in Kleo::KeyCache::insert(std::vector<GpgME::Key, std::allocator<GpgME::Key> > const&)
(this=<optimized out>, keys=<optimized out>) at /home/ingo/dev/kde/libkleo/src/models/keycache.cpp:1422
#4 0x00007ffff7ad3072 in Kleo::KeyCache::refresh(std::vector<GpgME::Key, std::allocator<GpgME::Key> > const&)
(this=<optimized out>, keys=<optimized out>) at /home/ingo/dev/kde/libkleo/src/models/keycache.cpp:1255
#5 0x00007ffff7ad5968 in Kleo::KeyCache::RefreshKeysJob::Private::updateKeyCache() (this=0xc81ff0)
at /home/ingo/dev/kde/libkleo/src/models/keycache.cpp:1566
[...]Sep 25 2024
Sep 24 2024
Fixed. The fix is in gpg4win so that it will automatically apply for VSD 3.3.
This is a regression of a fix for T6073: Kleopatra: Fix issues with high contrast resp. inverted color scheme.
For comparison: That's how it looks like with the Breeze style on Linux. The highlighting background on Windows is way too light.
What about all other filters? For example "Not Certified", "Not Fully Certified", "My Own", "OpenPGP"? Should the disabled certificates also be excluded for those filters?
Possible fix:
From 24e8191ab5de7245cf6063be778b6d3ceec4414b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ingo=20Kl=C3=B6cker?= <dev@ingo-kloecker.de> Date: Tue, 24 Sep 2024 10:44:31 +0200 Subject: [PATCH] gpg: Fix --quick-set-expire for V5 subkey fingerprints
Sep 23 2024
Sep 20 2024
The test with Gpg4win 4.3.1 (using GnuPG 2.4) seems to indicate that:
- gpg didn't update the trustdb automatically after importing the extended trusted certificate.
- gpg updated the trustdb automatically after deleting and re-importing the expired trusted certificate, but Kleopatra still showed the certificates signed by the trusted certificate as "certified". This could be a bug in the trustdb calculation (note the log message "Schlüssel C5D6C919005F36A4 ist als ultimativ vertrauenswürdig gekennzeichnet" which could indicate that gpg treats the key as valid although it's expired). On the other hand, my test with GnuPG 2.4 on Linux doesn't reproduce this problem.
gpgme now checks for a SUCCESS status emitted by gpgtar when creating a signed and/or encrypted archive. If gpgtar is killed (or exits without emitting SUCCESS for some other reason) then the partially created archive is removed and Kleopatra reports a failure.
Sep 19 2024
I'm unable to reproduce the problem with Kleopatra master (Qt 6) and GnuPG 2.4.
It's possible that the file system watcher does not yet support keyboxd. (Ideally, keyboxd would report changes via assuan to processes listening for changes. The file system watcher is obviously just a workaround.)
Sep 18 2024
Kleopatra does a full key listing after an import (triggered by the file system watcher noticing changes in GNUPGHOME). In general, Kleopatra always does full key listings.
Status messages on successful creation of signed & encrypted archive
2024-09-18 15:21:33 gpgme[3250.d47] _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar c 0 3<LF> 2024-09-18 15:21:33 gpgme[3250.d47] _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar s 0 62 B<LF>
Tobias is working on this
I don't see how Kleopatra is responsible for updating the trustdb. As Andre correctly commented, Kleopatra sets "no-auto-check-trustdb" only for the initial key listing.
Setting to Testing and WiP to reflect status of the subtasks and to get it removed from the Open Tasks list.
This was implemented by Tobias
Sep 17 2024
Sep 16 2024
Backported the changes in Kleopatra for VSD 3.3.
Sep 5 2024
Additionally to performing the lookup also for OpenPGP cards the status messages that are emitted during the lookup are now shown in the status bar instead of with a label above the key list.
Sep 4 2024
This ticket got superseded by T7262: gpgme: Move C++ bindings, Qt bindings and Python bindings to separate git repositories.
Since VSD 3.3 will likely include this change in gpgme I add the vsd33 tag.
Sep 2 2024
Fixed.
I can reproduce this: It works with setuptools 72.1.0 and it fails with setuptools 72.2.0.
Aug 30 2024
As far as I know the practice to have separate -dev packages is very common among Linux distributions.
Aug 29 2024
Does alpine split the development files of libgpg-error into a separate *-devel (or similar) package like most other distros? If yes, then you need to install this development package.
Aug 28 2024
Backported for VSD 3.3
The bug doesn't occur when the normal certification process is used because there we specifically tell gpg which user IDs to sign (excluding the revoked one).
The interactor log shows what's happening:
EditInteractor: 0 -> nextState( GET_LINE, keyedit.prompt ) -> 1 EditInteractor: action result "lsign" EditInteractor: error now 0 (Erfolg) EditInteractor: 1 -> nextState( GOT_IT, ) -> 1 EditInteractor: no action executed EditInteractor: error now 0 (Erfolg)
gpg asks what to do. Kleopatra answers "lsign".
