Note: If i set an invalid path in "Software\\GnuPG:Install Directory"
- the gpgconf -X output does not change
- the self-test Config File 'libkleopatrarc' fails with Error in archive definition tar: 'pack-command-openpgp' empty or not found
Note: If i set an invalid path in "Software\\GnuPG:Install Directory"
This probably can only be tested with signed releases?
Looks good to me on gpg4win-5.0.0-beta369 @ win10:
Notepad window Text to process edit Either enter a text you want to sign or encrypt, or an encrypted or signed text you want to decrypt or verify. You can also enter certificates in text form to import them. blank t e s t Signing and encrypting notepad... Successfully encrypted and signed the notepad
Looks good to me on gpg4win-5.0.0-beta369 @ win10
Looks good to me on gpg4win-5.0.0-beta369 @ win10 (no lines omitted or duplicate readings):
pinentry-qt dialog Enter passphrase Passphrase: edit protected blank [...] does not match - try again dialog OK button Enter
Looks good to me on gpg4win-5.0.0-beta369 @ win10
Tested on gpg4win-5.0.0-beta369 @ win10.
Looks good to me on gpg4win-5.0.0-beta369 @ win10.
Can't reproduce it anymore, message is S/MIME decrypted instantly:
Looks good to me on gpg4win-5.0.0-beta369 @ win10: The dialog with the progress bar is showing up instantly now.
Uses gpgme-2.0.0 with the above mentioned patches. I have seen no problems in my quick tests.
Key Approval dialog used by GpgOL (VSD only) looks good to me on gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10 (compliance mode):
How to test this? The follwing happens for an attachment of an encrypted mail on gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10:
Moving an encrypted message on Gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10 into an inbox subfolder of Ted.Tester and back works for me, too. Does this confirm, that it's working now?
i've included logfiles for gpg-agent and scdaemon with debug-level 10. the files include
Notes for testing (and maybe documentation update):
We will do a new gpg4win beta soon.
@m.eik Could you please enable debug option for gpg-agent and get the log output for the crash?
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, though. Anyhow, I believe that this is an improvement.
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 times.
(5) IIUC, in the server side, to handle RECIPIENT command, dirmngr is used by the call chain of:
(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 at log_string in my_libassuan_log_handler, waiting the data in pipe is consumed.
(9) ... it hangs.
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.
In the meantime pinentry has been updated also for VSD 3.4.
Backported for VSD 3.4
Backported for VSD 3.4
the issue is the same in Gpg4win-5.0.0-beta357:
Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10
(tested with 10 restarts)
We decided to remove one more item:
Copy to cardBecause it is only doe once, usually.
We decided to remove one more item:
Because it is only doe once, usually.