Checked with version 4.0.0.250370 (Gpg4win-5.0.0-beta125):
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Fri, Mar 7
tested with version 4.0.0.250370 (Gpg4win-5.0.0-beta125): no pop-ups
works, Version 4.0.0.250370 (Gpg4win-5.0.0-beta125)
Version 4.0.0.250370 (Gpg4win-5.0.0-beta125):
After testing the feature again with Beta 5.0.0-125 I repeat myself: this works.
There is the action "Unblock card" for unblocking the card with the rest code / PUK.
I think "not certified" is ok if several UIDs with different certification states exist.
I think that major signal sources for K have been killed so far.
Thu, Mar 6
Sounds like the animation causes/relies on a deferred destruction. Do we/KF6 delete the popup manually?
Version 4.0.0.250370 (Gpg4win-5.0.0-beta125):
Works as described with Version 4.0.0.250370 (Gpg4win-5.0.0-beta125):
Making some progress on understanding this:
rG25d48663f9 seems to fix this for me. However in my test cases I got a hang in dirmngr simply by running several gpgsm instances to get the details of an X.509 key. I had different logging options enabled, though.
Please use "unbreak now" only for *released* software with a criticial bug.
I had this again yesterday. I don't think that scdaemon is involved. gpg-agent.log has this
2025-03-05 15:54:29 gpg-agent[1248] socket file removed - retrying binding 2025-03-05 15:54:29 gpg-agent[1248] Der Socket kann nicht an `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent' gebunden werden: Unknown error 2025-03-05 15:54:29 gpg-agent[1248] system error code: 0 (0x0) 2025-03-05 15:54:29 gpg-agent[1248] secmem usage: 0/32768 bytes in 0 blocks 2025-03-05 15:55:17 gpg-agent[2088] socket file removed - retrying binding 2025-03-05 15:55:17 gpg-agent[2088] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent' gehört 2025-03-05 15:55:17 gpg-agent[2088] socket file removed - retrying binding 2025-03-05 15:55:17 gpg-agent[2088] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent.extra' gehört 2025-03-05 15:55:17 gpg-agent[2088] socket file removed - retrying binding 2025-03-05 15:55:17 gpg-agent[2088] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent.browser' gehört 2025-03-05 15:55:17 gpg-agent[2088] socket file removed - retrying binding 2025-03-05 15:55:17 gpg-agent[2088] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent.ssh' gehört 2025-03-05 15:55:17 gpg-agent[2088] gpg-agent (GnuPG) 2.5.5-beta11 started
and scdaemon logged
2025-03-05 15:55:19 scdaemon[4100] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.scdaemon' gehört 2025-03-05 15:55:19 scdaemon[4100] Handhabungsroutine für fd -1 gestartet 2025-03-05 15:55:19 scdaemon[4100] DBG: chan_0x00000000000002d0 -> OK GNU Privacy Guard's Smartcard server ready, process 4100
i.e. there wasn't any scdaemon running before the second gpg-agent started successfully.
Thanks for the report! That's indeed a regression introduced by the changes for T7527: Keyring/keybox denial of service. Commenting/Removing line https://dev.gnupg.org/source/gnupg/browse/master/g10/getkey.c$343 seems to fix the regression, but (very likely) this would reintroduce the issues reported in T7527: Keyring/keybox denial of service.
We should only enable least leak implementation for 64-bit, as it's not as fast on 32-bit architecture.
We should only enable least leak implementation for 64-bit, as it's not as fast on 32-bit architecture.
Wed, Mar 5
When opening the notepad in Kleopatra, open it in a new (non modal) window.
This has the advantage that you can to open several notepads.
Kleopatra has currently only two views for the main window: "Certificates" and "Notepad". Using a separate window for the notepad removes necessity for the the "Certificate" button in the icon bar, as well as the corresponding entry in the "View" menu.
That would also make Kleopatra more homogeneous and cleaner.
whether you use --pinentry-mode=loopback or --pinentry-mode=cancel or --pinentry-mode=error, if gpg-agent has cached the password already, the decryption will work; otherwise, it will fail with an error like that describe above.
here's an example of no prompting at all using --pinentry-mode=loopback: