with VS-Desktop-3.3.97.11-Beta (GnuPG 2.2.54-beta9)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Yesterday
Thu, Apr 16
Still does not work on vsd-3.3.7-beta90.9 @ win10. Essentially the same behavior as before:
Reporter has tested 2.5 - the code in 2.2 is identical; no need for separate testing
I reworked the reading using our dedicated line reading functions which is used at other places. Extra benefit is that the code now also prints a status line ERROR which gives information on the first faulty line. Thus gpg-connect-agent listtrusted /bye can be sued to quickly check for errors without configuring a log file.
Without GpgsmCompatibility set and with the trust in the Root-CA established in the global trustlist file (the local one does not work for vs-complicane without GpgsmCompatibility=de-vs-trustlist , as expected), the compliance of a signature or decryption is now shown correctly and in accordance with the certificate status shown in Kleopatra. If the Root-CA is only trusted locally, the certificate and the signature are shown as "certified" resp. "not-compliant".
In short: everything works as expected if GpgsmCompatibility is not set.
auto-key-upload should not be triggered on revocation cert import, so everything seems fine.
Looks good to me on vsd-3.3.7-beta90.9 @ win10.
Note: Keyserver has to start with ldap: for this to work, otherwise it is silently ignored.
Wed, Apr 15
In general looks good to me on vsd-3.3.90.9 / gpg 2.2.54-beta4.
with GnuPG-VS-Desktop-3.3.90.9-Beta-Standard gpgsm now never shows the line [GNUPG:] VERIFICATION_COMPLIANCE_MODE 23. Therefore Kleopatra always shows "not VS compliant" now on verification and decryption. Even though the certificate is shown a VS-compliant in the list an when encryping:
gnupg22 received this patch meanwhile: rG7bc969d388086b4f3aeee3c5389b7baf055689d7