Should avoid the problem. Then import or create n OpenPGp key first and the next time you should(tm) not be bnotered by the bug.

Okay, I took your suggestion but also improved the documentation. Fixed in 2.2

Thanks for your reports.
I can finally reproduce this on a new Test VM which I gave little resources. Most of the time it does not work. Sometimes it works. Looks like a timing issue, on my main development VM which is fairly quick it always works. I'll work on it.

Oh that is not good. A passed arg should not be closed by the called fucntion unless that fucntion is documented as gaining ownership of it. Let me check.

Sorry for the confusion. We tried to reduce the interactions necessary to encrypt a file and our rationale was that users mostly want to either always use textmode or never. (Also See T3486 )

Thanks for your feedback. But this is intentional. There were two problems with with this:

Thank you Werner. Do you know when the next release will be? Is there a way for me to temporarily fix the current version in the code?

But this does not explain why it works on the same system with GPG 2.1.11 instead of 2.2.2.
Here is what happens after applying the suggested quick fixes:

--- ~ » sudo pcscd
--- ~ » sudo chown enno /dev/bus/usb/002/005                        1 ↵
--- ~ » sudo chgrp users /dev/bus/usb/002/005                      2 ↵
--- ~ » ls -l /dev/bus/usb/002/005
crw-rw-r-- 1 enno users 189, 132 16 nov.  15:17 /dev/bus/usb/002/005
--- ~ » gpg --card-status
gpg: selecting openpgp failed: Aucun périphérique de ce type
gpg: la carte OpenPGP n'est pas disponible : Aucun périphérique de ce type

So you either need to start pcscd or you fix the permission of the device so that GnuPG's scdaemon can access the card reader using its internal access method. There are probably some udev rules which need to be adjusted. For a quick check you can manually change the owner or group to your own user or one of your groups. Then it should work again.

Dear Werner,

Entering on the shell

lsusb | grep USB

This is verly likely be fixed with commit 5ecef193bc2144e6d51a6bd5727bfd08a0d28b66 which will be released with the next gpg4win version.

Add the tag of npth (forgotten).

Done for libassuan

This has been fixed a while ago my having dirmngr print a hint on the possible problem. gpg will then print a warning about a problem with the Tor configuration and with --verbose print the hint on solving this as well.

I am connected via IMAP. Sometimes Outlook also crashes when I handle a message that is in a local inbox not directly associated with an account. It may be relevant that I have two IMAP accounts configured that run on different key pairs and all messages are shifted to a local inbox on arrival.

This was only for multipart/alternative HTML mails which was a fairly recent feature for GpgOL.
The encoding for html mails was handled incorrectly as it took the encoding of the text/plain part and not the text/html part. Fixed now.

Indeed. Thanks for your report I can reproduce this. Funny how this was missed through all the Beta's and pre release testing.

How are you connected to your server? I mean IMAP, or Exchange MAPI or is it a Hotmai / Outlook.com account?

Outlook 2007 is deprecated and we will only fix security issues there (or remove it altogether in the future as Outlook 2007 is no longer maintained by MS). GpgOL for Outlook 2010 and Later in Gpg4win 3 has HTML Mail support.

FWIW, I added a gpgtar.1

Pushed to 2.2

You could use the --directory option. However< I agree that your suggested changes is less surprising then the current behaviour. Thus I would consider this a bug fix. Can you please apply to 2.2?

That does not look like a GnuPG or GPGME bug but more like an incompatibility in python-gnupg. Please report this to the maintainers of python-gnupg. I would have suggested to use the GPGME Python bindings but unfortunately we don't have a Windows version on them yet.

I prefer plain git patches. Thanks.

That should be emitted only in verbose mode. I have verbose almost always enabled so I didn't caught it. Thanks.

I created a Differential request for this change; not sure which you prefer.

I am building on a CentOS system that comes with gnupg 2.0 and I'm trying to make an isolated test install of 2.2. It would probably work fine with the right PATH, but I thought the --with-*-pgm options might help assure the new install was used.

Multiple bugs fixed here:

Tested with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.

The Documentation is installed. You can find it under Help -> Gpg4win Compendium in Kleopatras menu.

I enabled the error and did the following with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 7 (64bit) with Outlook 2010

In T3442#105339, @aheinecke wrote:

In T3442#104402, @JochenSaalfeld wrote:

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

Fixed with 474cc15d8e331c9def298dbbfe3b99e6c8cf8035

What is your use case for these configure option?

@tstreibl thanks for helping with your feedback!
Please note that this issue (T3442) still has the status "testing", because we want to perform some more tests before declaring it resolved. :)

In T3442#105466, @tstreibl wrote:

Starting Outlook still bring up the "Fehler in der Benutzeroberfläche von XML von "GpgOL .....Unbekannte Office.Steuerelemente-ID: TabComposerTool" Message Box.

Sorry for my inpatience...but it's a little bit hard to understand why the above, very simple test procedure obviously isn't reproducible on your systems.

Starting Outlook still bring up the "Fehler in der Benutzeroberfläche von XML von "GpgOL .....Unbekannte Office.Steuerelemente-ID: TabComposerTool" Message Box.

tested your new .dll. Created a new email. Choosed "sign". Pasted an email adress from outlook address book into the "an" field. Outlook crashs. Took me 2 seconds to test. What the hell are you testing?

Thank you very much. Both the signed only and the encrypted mail are fully valid for me (checked on the IMAP server and with kmail) and don't contain any references to gpgolXXX.dat. This means they were correctly converted to valid PGP/MIME Mails.

Dear Andre

Thanks for the report. This is indeed badly broken. I'll work on this now.
I can reproduce and also have a reproducable crash when trying to encrypt a special folder. This must be a recent regression because I tested this some months ago and it worked fine.

This might be a reason that we got multiple reports for Kleopatra since 3.0 was released that it hangs on keylisting: https://bugs.kde.org/show_bug.cgi?id=381910

Everything works correctly but the warning message is probably too cryptic. It means that the signature could not be checked because the public key that created this signature is not found. It needs to downloaded, imported and verified. (See: https://www.gpg4win.org/package-integrity.html )
We improved the warning message with gpg4win-3.0

This means that the MAPI to MIME conversion did not happen.

Jochen could you please test this on one of our test VM's again and resolve this then?

A new binary for GpgOL can be found under: http://files.gpg4win.org/Beta/gpgol/2.0.2-beta8/ or for http://files.gpg4win.org/Beta/gpgol/2.0.2-beta8_x64/

Nagi: The third suggestion (adding "--pinentry-mode loopback" to your command) should work in that case.

@aheinecke Regarding closing: I'd say that we should have a test on this one and then close it for only the refocussed "send-folder problem".
Can you provide an updated gpgol.dll drop in replacement?
Some of the users in the forum may be willing to test as well.

I think this is resolved here. As we now have the check in the installer to warn on Vista and disable Kleo / pinentry-qt

I'm not sure why a special case should be needed -- failure to create
the .kbx should not be a failure for a decryption operation in general.

Ah well, no rules without exception.

I don't recall, but I suppose I did. It may not have been a manual invocation, but possibly a batch job from mutt or something.

In T3442#104402, @JochenSaalfeld wrote:

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

This indeed is a mixup of the protocol detection and likely a regression from a fix for exchange support. (On Exchange emails from exchange to exchange look the same as sent mails as both don't go through the MIME conversion)

On Fri, 10 Nov 2017 13:17, noreply@dev.gnupg.org said:

This error looks like an element might be referenced that is not available in Outlook 2010. In that case the problem should be reproducible for users that have Developer Options -> Show Add-In Errors enabled.

Fwiw I don't want to patch KDE Librarys to work with older Qt Versions and don't want to patch Qt to support older Windows Versions. I think greying out is a good solution.

Duplicated problem. Solution for the installer is described in: T3434

In T3434#103995, @werner wrote:

Indeed the notes for QT 5.9 do not anymore show Vista as supported. Stupid decision if you ask me.

In light of this I would suggest to tweak the installer to grey out QT applications for all platforms older than Windows 7. We also need to make pinentry-gtk the default in this case. Of course there should also be notes in the docs about these restrictions. And that should be done immediately.

Both my coworker and I have the same issue. We just started using gpg for git commit signing. Works the first time. Then sometime later, no window pops up and will hang git indefinitely because it's waiting on the agent. Kill the agent and gpg process let git error out. try again, gpg-agent window prompting for password shows up and works.

It might be easier to include a regexp implementation in GnUPG proper. This way we have a well defined behaviour and it will work also on Windows. The gpg-check-pattern tool might slightly change its behaviour, though.

Right, we can't do anything in Libgcrypt except for adding a way to return the open fds. This is the usual problem with libraries and the required closing of fds before an exec. Anyway the FIPS mode is questionable because it has not been adjusted for many years and does not take account newer requirements.

No, I was not accurate. EXAMPLE.COM works, while example.com doesn't work.

I confirmed this is same bug in T2923: trust signature domain restrictions don't work, I am closing this one as duplicate.

Henry Spencer wrote three implementations (old, BSD, and Tcl): https://garyhouston.github.io/regex/
Indeed, for the one in old library and BSD library, \ + CHAR means that single CHAR.
For one in Tcl library, \s, \S, \w, \W is supported (just like GNU), and \d, \D (digit) is also supported.

ECDH on Curve25519 is fully supported in libgcrypt. You can see GnuPG supports ECDH on Curve25519.
Lower layer routines (point addition and point duplication) are not implemented, though.
That's because ECDH only requires point multiplication and it is better to implement point multiplication by Montgomery Ladder for Curve25519.

Fixed both for master and 1.8 branch.

The thing is that I don't see this bug with verbose logging enabled. So we need to do more code starring or instrument the code

Is there a more detailed logging that i can switch on? Perhaps i can help you to get diagnostic files. Nearly every day i notice this bug. In the log (with "verbose" in gpg-agent.conf) are the same entries i already posted.