- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 27 2019
Strangely, if I look at my upgrade history, it cannot be caused by gnupg or libusb update. Everything was working fine in February 2019.
BTW in 2.2.15 you can also do
I forgot: Instead of importing the missing internal CA, this works:
I agree, the question is which CRL is checked when how. Maybe there is some mistake on my side. Here is a recipe for Debian:
I don't think this is a bug. Failure to encrypt when CRL check fails is expected.
Mar 26 2019
In T4427#123774, @werner wrote:Can you please run
gpg --debug ipc -vKwhich will also start gpg-agent and print some diagnostics. You may want to redact the output. You can also run
Actually you should never use --debug-all; we have more specific log levels. Use --debug help to see them.
From: aheinecke (Andre Heinecke)
Sent: Montag, 28. Januar 2019 19:25
fwiw. Your patch is beautiful in which it follows our coding style and
debug output. I'm confident that we will accept it but currently I have
to read up on Job's a bit.
Is there a way I could help you with this? This issue is hampering adoption
of GnuPG 2 here.
--
Jan Echternach
News for 1.13.0:
- Support GPGME_AUDITLOG_DIAG for gpgsm. [T4426]
I changed it. My rationale to check for <=0 here was to catch "-1" invalid handle values that might be somehow created / passed and not caught earlier.
Many thanks for the fast fix! Decryption works now. I'll report another bug for encryption.
Trying to install the update manually (according to windows update my windows is fully updated) it says "This update is not meant for your computer" and aborts.
This has been implemented.
I've started some documentation how to repair a broken archive under: https://wiki.gnupg.org/TroubleShooting#Restoring_corrupted_Archives_created_by_Kleopatra
Doesn't look like T4347 in that no errors show
stopping daemons and restarting kleoptra "sometimes" fixes it and pinentry windows shows, until it does all operations fail with pinentry missing
running pinentry-qt.exe I get
Please note that you don't have secure memory on this system
OK Pleased to meet you
We seem to have stopped it happening by randomly changing settings - generating blank conf files, reinstalling pgp4win but cannot pinpoint exactly what change fixes the error and because it's intermittent we may just be getting lucky
If the filename embedded in the encrypted message differs from the filename Kleopatra uses (which is derived from the file system filename) Kleopatra will now show the filename. This should cover the case where users receive an "Attachment.pgp" and do not know what that is.
A quick note: The second workaround above does not work.
The presence or absence of the expired certificate in my keyring does not matter. The check by dirmngr fails regardless.
The reason for the problem is that we check all configured keys to print a note about expired and otherwise unusable keys. This should be warnings but due to the way we use shared code the error counter is bumped and operations stops. With the fix these will just be warnings and decryption continues.
Could it be that you are running into: T4347 ? Maybe this will just be fixed for you then in the next version.
Hi,
I'm pretty sure that I finally understood it and fixed it. There was a data mismatch between the IMAPISecureMessage and IMAPIMessage which somehow only happened for sent mails. This case is now handled.
There was indeed a problem. With a test card I could reproduce the issue and fix it.
in I think a related scenario we are having the pinentry window not spawn at all, leading to "no pinentry" errors
Win 10 latest patches Mar 2019
Version 3.1.4-gpg4win-3.1.5
We've tried a few hacks including adding the .conf file to C:\Program Files (x86)\GnuPG\bin with
pinentry-program "C:\Program Files (x86)\Gpg4win\bin\pinentry-qt.exe"