Thu, Nov 14
This is a bug tracker and not a general help line. You are better off asking on the gnupg-uisers mailing list.
Sep 30 2019
Sep 27 2019
Do not use this legacy debug stuff. Use --debug CATEGORY. For example
May 2 2019
Users keep showing up in our support, confused by this inconsistency. here's the most recent ones:
Mar 18 2019
No we can't we need to know the IP addresses to handle the pools. I have given a workaround for you in my previous comment. You can also use install Tor which we can use for DNS resolving.
Feb 4 2019
First of all I find PIN a very bad term. "Personal Identification Number" for example for my Gnuk token is confusing. I use a string there,... So let us use PIN only where it really has to be a number. Otherwise it is a Password.
Despite that I created this task, I am still not not convinced that removing the term passphrase is a good idea. If we do this in gnupg we would need to change all strings to make it clear that the passphrase is used to protect one's own key and has nothing to do with encryption etc. In fact the term PIN would be better because it is common knowledge that you use a PIN to get access to something you own. There would be less confusion on the purpose of the passphrase. Sure PIN is usually considered to be a number. However my bank allows a string to be used as, what they call, PIN.
There has been some progress here. At least we no longer use "passphrase" in new code. We still have not yet replaced all old occurances.
Dec 28 2018
I contacted Microsoft Security Response Center (MSRC) in regard to this matter. They confirmed the failed PGP key verification, but have not yet any explanation for that.
Dec 21 2018
What are MS doing when they get it right, though? I'd look at the differences between those two to identify what they've messed up here.
Thanks. The mail is a standard, non-crypto mail with one attachment. That attachment is a TNEF file which has according to ytnef(1) just one file. That file has the name gpgolPGP.dat and contains a clearsigned message.
Sure, I zipped the eml which failed and I´ll send it by e-mail to you
Is it possible that you upload or send me a copy of such a mail (wk gnupg.org)? ZIP or tar the eml file and send it in an encrypted mail to me to make sure it won't be modified on the transport.
Dec 20 2018
I checked my mails in detail, and I can confirm that the error occurs only with "Microsoft security update releases". Indeed "Microsoft security advisory notification" and "Microsoft security update summary for..." will be verified correctly.
I agree. It also happens to me. But only with mails coming from "Microsoft security update releases". Mails coming form "Microsoft security advisory notification" and Microsoft security update summary for..." are ok and are signed by the same key. It could be some trouble in MS automated email treatment.
Dec 14 2018
So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.
Dec 11 2018
Nov 5 2018
Jun 6 2018
BTW, you now need to use --rfc2440 to create a non-mdc message for testing.
Jun 1 2018
It's nice. Although for now I've only added a message in the legacy_cipher_nomdc case:
I justed commited some gadgets to gpgme which might be helpful But please show warnings etc before you use that new option.
Apr 13 2018
Apr 11 2018
You are right in that enigmail uses no-auto-check-trustdb
As far as I understand your comment there is already a timeout of 15s per connection. But as you wrote, it doesn't fit all cases. In my case, gpg.exe just stayed open indefinitely.
Jan 19 2018
Jan 18 2018
There can't be an MDC warning if MDC is not used ;-)
As far as I can see GnuPG does not emit appropriate status lines:
Jan 8 2018
In the folder %APPDATA%\gnupg create a file named gpg.conf (or edit it if it exists) and put the line "ignore-mdc-error" in there. This should globally set this option and gpgol will also respect this.
Jan 6 2018
Andre, I assign this to you. If you don't think that a better warning in Kleopatra is needed, please close the report.
Jan 5 2018
OK. Thank you for that.
Thanks for asking. We may need to put this into the FAQ, so here is my answer:
Forgive me if I'm completely off the mark here. In no way do I claim to fully understand gpg etc.
The last line shows that gpg decided that to return a failure because the message does not use the MDC scheme. Since the introduction of modern algorithms with a _blocklength_ of 128 bit (e.g. AES) gpg always uses the MDC encryption system even if it is not announced by the respective key flags. The reason for theses algorithms are newer than the MDC system and thus we can expect that all applications supporting AES will also support MDC.
Nov 13 2017
I've added a note about this in the wiki: https://wiki.gnupg.org/TroubleShooting#Passphrase_on_the_command_line
Nov 6 2017
Thanks you very much for your quick reply. I added your code to my invocations for decryption and signing and all is well now. You probably saved me many hours of searching with your kind reply!
However you can tell gpg-agent to let gpg ask for the passphrase. Add
Oct 20 2017
Aug 3 2017
Jul 17 2017
@werner I request re-consideration. I *have* read the discussion, and remain convinced that a parameter that allows shared access is necessary.
Jul 12 2017
That issue is best taken up with the enigmail maintainers. If you report it there, feel free to add a link here. Thanks!
Jul 10 2017
This is on purpose. Please read the discussions. Use card-timeout in scdaemon.conf or "gpgconf --kill scdaemon"