- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 21 2022
Jul 20 2022
Using SLOT doesn't work anymore. The "slot" needs to be a std::function<void(bool)> (e.g. a lambda) now. Moreover, the trailing false, true is not required anymore (because of suitable enum value defaults for those action_data members).
I have used the same header blurb as gpg-agent (https://dev.gnupg.org/source/gnupg/browse/master/agent/trustlist.c$60-73) with an additional comment about the include-default statement.
To add an icon:
I have added accessible names to all icon-only buttons created in libkleo and kleopatra. There may be buttons created by Qt or KDE Frameworks which lack an accessible name.
Jul 19 2022
I think the accessibility is okay now. It could be further improved with useful shortcuts for the different buttons, but the DN attribute order configuration is a rather unimportant UI of Kleopatra.
The command needs to be ported away from running gpg --export-secret-key via QProcess to using QGpgME::ExportJob. I'll give this a low priority.
But then again: The three other apostrophes that occur in the text are represented by single quote characters. Maybe sticking to ASCII characters is the better fix after all.
Typographically the apostrophe character ’ is a different character than the single quote character '. So, the correct fix would be to fix the probably wrong encoded apostrophe instead of replacing it by a single quote character.
Kleopatra now silently ends the "backup secret key" operation if the password dialog was canceled.
It turns out that gpg does report an error via status-fd, but it doesn't report via status-fd that the operation was canceled (Update: The error code 83886179 in the status message corresponds to GPG_ERR_CANCELED, i.e. gpg reports that the user canceled the operation.)
$ gpg --status-fd 1 --export-secret-keys --armor -- 3A8536D46F57779C49F0CF542C0444CB59852D29 [GNUPG:] KEY_CONSIDERED 3A8536D46F57779C49F0CF542C0444CB59852D29 0 [GNUPG:] PINENTRY_LAUNCHED 6899 qt 1.2.1-beta1 /dev/pts/47 xterm-256color :0 20600/1000/5 1000/100 0 gpg: key 79BF2044FA53B3A492B361882353B5828F9B391C: error receiving key from agent: Operation cancelled - skipped [GNUPG:] ERROR export_keys.secret 83886179 [GNUPG:] PINENTRY_LAUNCHED 6907 qt 1.2.1-beta1 /dev/pts/47 xterm-256color :0 20600/1000/5 1000/100 0 -----BEGIN PGP PRIVATE KEY BLOCK-----
The second pinentry window comes up to ask for the passphrase that protects your subkey. Usually, gpg will try to use the passphrase entered for the primary key also for the subkey, but since you canceled the first pinentry there's no passphrase to re-use.
Jul 18 2022
as of 2.3.7 (which I just updated to) this works. ticket can be closed
Thank you.
I have improved the cursor positioning:
- Keep the cursor position when a key/group is updated in the background.
- Move the cursor to the start when the user finishes editing (with Return), selects a key/group via the selection dialog, or moves focus to another UI element.
- Otherwise, we keep the default behavior.
Please give us more information.
- Do you change SSH program?
- If so, please check if adding configuration https://dev.gnupg.org/T5935#157674 for ssh works.
- Do you mean, reinstalling gpg 2.3.4 fixes your issue?
- Are you using with smartcard/token? Which one (Yubikey/Zeitcontrol/Gnuk), if it's the case?
It's in 2.3.7 and 2.2.36.
@ikloecker KWatchGnuPG does not work on Windows. And this also does not work with Kleopatra logging and GPGME logging, Kleopatra logging needs Dbgview on Windows, which can be spammed by other software and GPGME logging requires an enviornment variable. So having this in a logging view would be good for support.
Yes, this sadly happened with 3.1.23 for Gpg4win 4.0.3 this was noticed and fixed with rW3cdf0b10d39c844b6f3557a85dc39dc2b9242b53 as we are planning 3.1.24 anyway this issue pushed the timeline for this a bit earlier so we should have a relase very soon.