Mon, Nov 5
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"
Jul 7 2017
--with-fingerprint is an option to modify the output of --list-keys and not a command. There are other --with-xxxx options for other purposes. There is no command to list a keyring. This is why gpg meanwhile prints a warning when used without a command.
I don't think anyone is suggesting the use of gpg without a command. However, use WITH the --with-fingerprint command seems to be broken. Thank you for providing a correct way of doing what we want, but please either explain why the use of the --with-fingerprint command isn't working, or put this back as a bug.
The use of gpg without a command is simply wrong. This has never been specified and could actually lead to surprises.
You need to import the key first and then look at it with -k (--list-keys) or --fingerprint.
Apr 28 2017
Apr 27 2017
Apr 20 2017
Sorry, merging/closing is not good. This should be a subtask of T2291.
We need to change how to access scdaemon from gpg frontend. Thus, I merge this to T2291: Smartcard interaction improvement (was: Shadowed private key design (for smartcard)), setting its priority to High. Please continue at T2291.
Apr 19 2017
Apr 3 2017
Mar 30 2017
Dec 20 2016
Dec 19 2016
Dec 4 2016
Little update with latest 1.0.0 release:
– nothing new regarding pinentry-gnome3, still working nicely;
– nothing new regarding pinentry-gtk-2, but I know why it doesn’t take into
account my dead keys anymore and it’s not an issue on pinentry side;
– thanks to the new “show passphrase” button, I’ve been able to figure where the
issue lies with pinentry-qt: while invoked in the terminal, it does take into
account my dead keys, but while invoked via Thunderbird/Enigmail, it does not
(altought pinentry-gnome3 does).
So I suppose this is in fact an issue with Enigmail… Any hints on what they
could be doing wrong so that I can report this to them?