Last week GpgOL again destroyed an email with a BSI newsletter - it was shown as empty after I opened it a second time - and the same is true in such cases then in Windows 10 Mail as well as using Outlook Web Access:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 9 2019
But this problem remains for several versions for some time. I tried to find out the source of this "new option" in the communication, but I could not find anything about "GPG Agent" in the source code of openssh.
Sorry for the late answer, but I have been busy. Actually this happened against several ssh versions, for some time now.
The signature of the latest communication from German Buerger CERT Warnings could be read and the signature could be verified. I tried also with Hasso-Plattner-Institute (Identiy leak checker), the same result. I do not understand, why all signature verification failed last week, and they can be verified this week. However, at the moment it seems to work fine.
Sep 8 2019
Sep 7 2019
Oh, this report is about libgpg-error.
Sep 5 2019
Thanks for the sample certs. I noticed the posts but had not the time to look into them.
Sep 4 2019
I have the same problem since today with Outlook 2016. In the past months / weeks GpgOL version 2.4.2 worked fine. I received some mails today signed by the German Buerger CERT warnings. The signature as "asc" file was attached, but could not be verified. Today I received also a PGP signed e-mail from Hasso-Plattner-Institute (Identity leak checker), also this signature could not be checked. Both worked fine in the past and the public keys stored in Kleopatra are valid.
Would be great to see this fix rolled out! Absence of support for these keys disoriented me for months after switching to pinentry-tty. I use my longest passwords for GnuPG, so being able to fix typos (instead of abandoning password entry altogether) would be greatly appreciated.
Sep 2 2019
@werner How can I install libgpgme-develp package on windows 7?
Sorry, we don't use or support PIP. Please ask whoever packaged that for PIP.
Sep 1 2019
Aug 31 2019
Aug 30 2019
If helpful I can demonstrate or let you debug in a TeamViewer (I have a license) or VNC remote session in a fresh VM.
For sure this is not urgent for me. So, take your time!
Mmh, No Data usually means that our parser had a hickup. I'll look at your examples.
Mmh, No Data usually means that our parser had a hickup. I'll look at your examples.
The Python doc build system we implemented the last year is a complete mess - I had so much trouble the last time I did a release :-(.
Hi Andre,
Strange. Can you please go to the command line (cmd.exe) and run gpg --verify "c:\<path to>\gpg4win-3.1.10.exe.sig" "c:\<path to>\gpg4win-3.1.10.exe.sig"
can you hover over the GpgOL Icon and look at the tooltip? Maybe there was an error during validation.
Account disabled and I'm closing this as resolved.
Thanks. Fixed in stanble and master.
Aug 29 2019
I am sorry it just needed to be run as root.
Aug 28 2019
For information, I can’t reproduce here, either with GnuPG 2.2.17 / Pinentry 1.1.0 or with a fresh build from the tip of the master branches. Both pinentry-tty and pinentry-curses prompt for the password as expected, independently of whether the file to decrypt is specified as an argument or sent through standard input.
Aug 27 2019
i'm actually running make -j3 check, since make -j3 distcheck has the problems described in T4688.
So i've been able to (intermittently) reproduce the failures that i think @werner was alluding to here, but not under any circumstances where i can get them to happen reliably to understand what's going on.
Aug 26 2019
Please read my answer again. Posting to gnupg-users does not require a subscription.
Please do not force me subscribe to yet another mailing list to see the answer.
So do you have any plans to make new release? :)
Aug 24 2019
Aug 23 2019
oops: That was an accidential priority change
Implemented master and 2.2. Note that the comment in the master commit about possible reason for stucked keylisting in gpgsm is only related to master.
I implemented it nearly as suggested. However, the default AKL is used, which is "local,wkd" (local is not used with that command though).
Fixed for 2.2.18. To allow seeing these warnings this change will only have an effect if a listing of all keys is requested.
Done for 2.2.18
This was already fixed with version 2.2.5.
Will be in 2.2.18
I changed the suggestion to read:
The agent is an important part of gnupg and it does not make sense to single out cases when it might not be needed. I can't see any harm from having an agent running. In fact, one of th netxt versions will add yet another daemon which will then be needed in all cases.
Aug 22 2019
Thanks, @gniibe. From reading this patch (i haven't tested it), it looks like it would avoid most unnecessary agent launches (and agent communication) in the (b) case, which is a win over the status quo.
With me it happens all the time: Outlook 2013 x64 is half-maximized at
right border, and GPG asks for the passphrase on sending a mail from the
inline editor, on Windows 7 x64, then it always happens.
Thanks.
If it makes sense to warn a user for someone's preference when keys are imported,
here is a patch:
Aug 21 2019
i've just pushed rGc4b9eba1d6a63b73238dcbb644b365dc53563f3d to the dkg-fix-T4682 branch resolve this.
@dkg, I changed the title and adjusted the description to more accurately describe the situation.
Aug 20 2019
It was fixed in GnuPG master by rGc395f8315362: agent: Terminate pinentry process gracefully, by watching socket. and rG374a0775546b: agent: Close a dialog cleanly when gpg/ssh is killed for CONFIRM..
Those will be in GnuPG 2.3.
@skeeto can you edit the summary/title of this ticket to better reflect what you think the underlying issue is?
This appears to be https://bugs.debian.org/850946 and it does not appear to be fixed to me.
Aug 13 2019
Fixing t-lock is indeed a better solution however having an option to disable tests could be used in another context than fixing this issue.
For example, in the context of buildroot (which goal is to build a custom embedded linux system), this option could be used to save time during compilation as well as to save space on the embedded system.
Thanks for your report.
I think that adding an option for disabling tests is too much.
If it were AC_SUBST, we could use HAVE_PTHREAD in tests/Makefile.am.
In the current situation, just modifining t-lock is easier.
I think that I located the cause of this bug:
Those changes make the script work for me, specifically passing the input as an argument and not through standard input. Digging more, it looks like the underlying issue is related to using pinentry-tty (my case) or pinentry-curses when passing the OpenPGP input via standard input. This causes pinentry to give up before prompting. For pinentry-tty it fails with "ERR 83886340 Invalid IPC response" and pinentty-curses fails with "ERR 83918950 Inappropriate ioctl for device".
For my environment (Debian buster's 2.2.12 and another one from GnuPG master), both (no argument and foo) work well.
The invocation with argument let pinentry pop up to ask passphrase.
Aug 12 2019
Considering that early interop testing, you're probably right that this is a bug in the spec, not GnuPG. Otherwise this would have been pretty obvious long ago. The wording in RFC4880bis hasn't been corrected to match practice, so I should probably report this issue there.
Re-reading the original report from 2001 it seems that PGP and PGP do the same. Back then these were the only OpenPGP implementations (except for that book with the OpenPGP tool based implementation). We did quite some interop testing in the early years by passing OpenPGP data back and forth. So one could assume this is a bug in the specs becuase the specs are for large parts derived from the PGP 5 code base.
Aug 10 2019
Problem no longer exists. It has solved itself in the meantime. In addition, I ask for deletion of this account via the responsible administrator.
Are you seeing mixed-up MIME parts? or a different problem?
Aug 9 2019
No problem, I'm glad i could help, accented letters are always a pain between encoding.
Thanks for reporting.
