Closing this ticket, as the test version is now obsolete and the new one much improved. I'll open a new one for the remaining issue with scdaemon when I have more information
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mon, Sep 30
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.
Fri, Sep 27
Yes, for historical reasons (i.e. we haven't changed this) the width of the name and email columns always defaults to 260.
tested with gpg4win-Beta50:
FWIW, a related task is T7308
works, gpg4win-Beta-50
This is covered by T7302
Alright, we should do that in any case because two key caches are never a good idea and in particualr not if one of them needs too be reloaded too often. Thus re-using the one in Kleopatra is the proper solution. I recall that we looked at this at a time when we already started to design gpgol2 which would solve the problem anyway. However, at least for vsd we need to keep on using the classic gpgol for quite some more time. Thus the effort to improve the key resolving in gpgol is really justified.
The problem is that this is a just a band aid at best. The underlying problem that shows up in other places is not fixed. We should apply the band aid only if we say we don't fix the underlying problem.
Something which has high priority but has not been touch can't have a super high priority.
Please write at least a short description and give it a priority
Pretty brief description :-(
Either this has super high priority or we fix S/MIME keylistings in GnuPG. I will write a mail with details as that involves customer information.
Thu, Sep 26
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.
with gpg4win-Beta-50: "Rückstellcode" is shown correctly with an ü
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.
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 [...]
on gpg4win-Beta-50 things look much, much better.
More than a year old - we can reduce the priority.
This is implemented; just missing the backport that is requested in T7302
gpg4win-beta-50: There are no duplicate announcements of the entries in the result table of a keysearch with NVDA
ok, with gpg4win-Beta-50, a search result is only selected and highlighted if it is the only result.
Wed, Sep 25
For the "unknown recipients" there was the good suggestion to not show that line at all. As it has no additional information which is not included in the new explanation. I like that, but only in the case that there are no known recipients at all, as it would be confusing to list only e.g. one known recipients and then not mention the 5 unkown ones, IMHO.
Migration works for upgrade to gpg4win.beta-50, too:
A copy of kleopatrarc is written to the nwely created folder %APPDATA%/gnupg/kleopatra
Yes, this is a bit annoying but recall that for v3 keys you can't even deduce the keyid from its fingerprint.
Ingo suggested additional changes and due to the helpful screenshot in the MR I've got some, too.
ok. For the tooltip I would now favor the same addition to all current tool tips where it applies:
"(w/o disabled ones)", e.g. "All certificates (w/o disabled ones)".
Tue, Sep 24
Fixed. The fix is in gpg4win so that it will automatically apply for VSD 3.3.
works, gpg4win-beta-50
This is a regression of a fix for T6073: Kleopatra: Fix issues with high contrast resp. inverted color scheme.
icon is there, gpg4win-Beta-50
I would exclude them.
For comparison: That's how it looks like with the Breeze style on Linux. The highlighting background on Windows is way too light.
works, gpg4win-Beta-50. "Write" occurs at the right point now.
search for "example" works now, Gpg4win-Beta-50
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?
Okay, okay: s/private key/secret key/
ok, discussed this with Werner and Alexander, result was:
Mon, Sep 23
I'd write: "This means that the data you want to decrypt was not encrypted to any of your private keys."
Fri, Sep 20
Things look good on Windows. A quick test using gnupg24 with backported patches did not show any hangs. More testing will follow next week.
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.
Thu, Sep 19
Sounds very reasonable. Maybe the initial idea was to open the database directly after keyboxd start and before and connections are accepted. My usual try to optimize a mutex away :-(
I applied rGb804378f183f: kbx: Fix a race condition on DATABASE_HD. in master. Let us see how behavior changes.
I found one problem. This problem may result lock-up on Windows, I suppose.