I fixed the problem (which I identified above) in gniibe/t7759 branch. There might be other causes/problems for the particular symptom, so, I don't know the fix resolves the symptom or not.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Wed, Aug 27
tooltip suggestion for d, not trusted and expired:
Ask the sender for an updated certificate and when you receive it, follow the procedure to establish trust and certify it.
or:
Ask the sender for an updated certificate. When you receive it, you need to establish trust and certify it.
Similar situation could happen with gpgsm + gpg-agent, when gpg-agent is invoked by gpgsm.
(1) No gpg-agent.
(2) In gpgme, by engine-gpgsm, gpgsm is invoked with --logger.
(3) In gpgsm_keylist, it makes sure gpg-agent is available by GETINFO agent-check, using gpgsm_assuan_simple_command.
(4) In the server side, it tries to connect gpg-agent, invokes gpg-agent, and connect to the agent again.
(5) On Windows, it may takes time to invoke gpg-agent. And it may try to connect multiple times. Each trial may generate debug messages.
(6) When it takes too much time, the debug messages are too much. It may fill the pipe.
(7) And it blocks at log_string in my_libassuan_log_handler.
(8) ... it hangs.
Hypothetical scenario (gpgsm --server + dirmngr):
(0) It may hang when much debug messages are generated by libassuan to the pipe of --logger (diag_cb).
(1) In gpgme, by engine-gpgsm, gpgsm is invoked with --logger.
(2) If it's the case of standard gpgme interactions which uses gpgsm_io_event, no problem. Because the data on diag_cb is consumed well.
(3) In case of gpgsm_encrypt (or other commands), it uses gpgsm_assuan_simple_command which does not consume the data on diag_cb pipe at all.
(4) In particular, in set_recipients, gpgsm_assuan_simple_command is called by the number of recipients.
(5) IIUC, in the server side, dirmngr is used by the call chain of:
- gpgsm_add_to_certlist
- gpgsm_validate_chain...
- gpgsm_dirmngr_isvalid
(6) In gpgsm_dirmngr_isvalid function, libassuan is used as client side, it generates debug messages.
(7) When there are many recipients, the debug message may be big enough to fill the pipe.
(8) When pipe is filled, it blocks by log_string in my_libassuan_log_handler, waiting the data in pipe is consumed.
(9) ... it hangs.
Tue, Aug 26
Mon, Aug 25
Thu, Aug 21
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Nope: There are many different error codes returned, Kleopatra may want to map them to a common one.
Backported for VSD 3.4
Backported for VSD 3.4
Wed, Aug 20
the issue is the same in Gpg4win-5.0.0-beta357:
Tue, Aug 19
Mostly looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10
(tested with 10 restarts)
looks correct
Mostly looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10
We decided to remove one more item:
Copy to cardBecause it is only doe once, usually.
We decided to remove one more item:
- Copy to card
Because it is only doe once, usually.
https://invent.kde.org/pim/kleopatra/-/merge_requests/410 has been merged for the accelerators
Mon, Aug 18
This task is not really actionable. Moreover, it proposes a technical solution instead of just stating the problem that needs to be solved. There may be better solutions, e.g. in the Notepad I decided to move the focus to the message widget that contains the result to make the screen reader read the result.
I've also fixed the problem that a file named mail.P7M was not treated as encrypted email message. I think this could be tested/verified.
After studying the logs created by NVDA and its source code I strongly suspect that the problem needs to be fixed in NVDA. NVDA tries to avoid repeating the text of common ancestors of the old and the new focus object, but it fails to detect the Create OpenPGP Certificate dialog as common ancestor of the text edit field in this dialog and the Error (child) window.
Fri, Aug 15
Wed, Aug 13
We need a better error code from gpg to change this
We decided that gpg should emit a status message for success, too.
gpgme should then look for that status message instead of only absence of error.
Fixed by adding a patch for Qt 6 (and a patch for Qt 5 in gpg4win-4-branch for VSD 3.4).