The current links should be replaced or removed.

You could verify this with another email address containing a +.

How can I check this, @ikloecker ?

Can you check whether the + character in the email addresses is causing this?

Because I'm just starting with GpgOL: Are we talking about adding links in the "Configure GpgOL" window or are there any other windows? If that is the right window maybe we could add a new tab "FAQ" and add the links there. At first I thought the links could be added to the tab "GpgOL" but there are already many entries and the other tabs don't fit well.

gpgol/doc/gpl.texi (line 9)
gpgol/COPYING-ICONS (line 52)

What are the other to places?

When I greped for links to the FSF page (grep with string "fsf" I found out that there is one link to https://emailselfdefense.fsf.org/en/infographic.html in line 722 of src/ribbon-callbacks.cpp. Is that the link that was meant?

I agree. @cklassen can you make a suggestion?

Fixed.

Please describe your problem in more detail. Also: Which version of GpgOl and Outlook are you using, SMTP/IMAP or Exchange?

I'm not sure. In KeyResolverCore::Private::resolve() line 668 reads

const bool pgpOnly = (!mEncrypt || !hasUnresolvedRecipients(mEncKeys, OpenPGP)) && (!mSign || mSigKeys.contains(OpenPGP));

I'd say this is supposed to check if there is an OpenPGP signing key, but I guess mSigKeys[OpenPGP] is an empty list. This may be a regression introduced by the resultion of key groups because in KeyResolverCore::Private::resolveSigningGroups() the entry mSigKeys[OpenPGP] is always set (unless we are in CMS-only mode).

Yes, unit tests still pass. So its ok with you to commit this?

Sounds familiar, that the signing keys are not considered. I think when I worked on this, I thought that is was a bad idea to mix resolving signing and encryption keys. Do the unit tests still pass with your change?

@ikloecker
If I test the resolver code from libkleo with gpg4win-tools keyresolver binary:

The problem is that we replace the encrypted text and attachments with the decrypted / verified parts. This would already be a modification even without such changes like the category.

As well as GnuPG VS-Desktop. 3.1.21. We should also do a new gpg4win release.

GpgOL 2.5.2 has been released

This and some other issues with draft encryption are now fixed in master and need a release of GpgOL.

We now autoselect the key.

I am tending towards wontfix. The reason is here that the sender attempts to send HTML with inline pgp. Which is not supported. Then that HTML apparently tries to be mutlipart/related which is not supported for inline PGP. Then it would require us to correct a wrongly sent content type of the inline attachment so that outlook does not interpret it as a png. And in that Format it could even be that Attachment1.pgp is not encrypted but instead png data, as the content type indicates.

Unfortunately same story for GpgOL v42.5.1. Tried disabling all non-Microsoft plugins, however to no avail. Signed and encrypted messages are shown as blank, whereas I can see the content of the signed e-mails in the Outlook web client and on my iOS device.

Tested both with the policies key and with the normal key and with HKLM fallback. Works as expected. There was also an issue where the error handling in case setting the HTML body failed did no longer work, probably since the verification preview changes. This was fixed with 76b43345cdd3e932dae7b677e5c021ca52191f8e

Enigmail's support for Thunderbird 68 ends in two days:
https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird

Should be mostly done. What's missing is selection of groups in the approval dialog. Groups are not (yet) supported by the KeySelectionCombo.

This feature does not use Outlook per se.. It's a problem with Exchange really. An Exchange Add-in would be needed to solve it, an Outlook add-in such as Gpgol can't do anything about it..

Hello,
it seems that the log got lost in the way for me at least, can you confirm you received it?

Well, this is a pure Windows bug. It easily shows up when running dozens of gpgsm processes each importing a different certificate (e.g. using Kleopatra's current importer, which spawns one process per cert). The only possible fix is to close all files before starting a long running operation *and* before locking the files.

Please test this with the Outlook plugin. It doesn't seem to be used elsewhere.

Hi Ingo,

@rjh reported a problem with keyboxd from the current 2.3 beta on the ML. This is also a locking problem and _might_ be related to this bug.

Notes to self:

• The function is called get_best_pubkey_byname (in g10/getkey.c).
• Recent changes:
  • rG390f597868a5: gpg: Fix selection of key.
  • rG7f3ce66ec56a: gpg: Remove support for PKA.

Any idea, what this could be? Misconfiguration from my side?

Released with gpg4win-3.1.15

The problem ist not an "ugly error message" but it does not recognize that the e-mail IS encyrpted by Symantec-PGP! But the plugin always says:

Hi,
the accounts are Exchange Accounts in Outlook 2016, getting Data from an Exchange Server 2016.

I think this works now with error handling. At least it works for me, but needs some more testing of course.