Duplicate of T2171

You can now. Thus is not a bug but a feature request.

Note that we do not use Microsoft compilers but use gcc and in cross build
environment.

Just as a note, this bug is for the "MIME Aware" interface with event driven
sign / encrypt.

Actually we are working on a 64 bit version.

GpgOL-1.4 which we will include in 2.3.1 will have an option dialog where you
can enable and disable S/MIME. Default in 1.4 is off.

-> Testing until 2.3.1 is released.

Hi Arthur,
sorry for the late reply:

Outlook 2010 has new code for supporting OpenPGP and S/MIME,
we will tackling the problem differently there.
I think that the last code for GPgOL for Outlook 2007 uses
encryption.

If this is still relevant for you: Can you retest?

Hi,

as the extended support period of Outlook 2003 ended in 2014,
we will not get around fixing this for Outlook 2003.

Please open a new issue, if you encounter problems with a more recent version.

Best,
Bernhard

Since the last activity on this report, GpgOL was changed a lot.
Probably the original reporter does not use the Windows/Outlook combination
anymore. Thus closing this report.

Reading about
http://www.heise.de/security/meldung/Erpressungs-Trojaner-verschluesselt-mit-PGP-3116677.html

made me think that signing all binaries may not be the best idea. For our
installer we can rule out that it does something malicious as we control what it
does. So signing it is fine. Same goes probably for GpgOL etc.

But the actual encryption stuff (libgcrypt / gnupg) can, of course, be used for
malicious purposes. So there would be the potential for malware using binaries
signed by us. This could hurt our reputation. (technically in terms of Windows
Code Signing Reputation or Anti Virus software)

At least something we should keep in mind while thinking about changes to what
we sign.

MDK7MX, did you retry ?

File? No hardware token?

I would rather add a "Sign all binaries" installed by us capability to the
packaging process then a special case handling for GpgOL. Especially for the
Uninstaller this would make sense at it requires privileged execution and is
currently unsigned.

But this would mean that we either need to split up the packaging process to
first create the binaries and on a different system (with the code signing
certificate available) create the NSIS Packages.

Or that we expose the CodeSigning certificate to the build system, which
probably makes the most sense as the build system already should be a secured
environment and we only build / execute code which we verified.

I could imagine implementing this as a configure option --with-codesigning-cert
or something thats optional during the build and which you can provide with the
certificate file.

since Outlook 2007 there is no Word editor option anymore. We will not add
support for this to Outlook 2003 as Outlook 2003 is End of Life.

Sorry that this bug was never fixed.

Regards,
Andre

Great to hear that! And again let me Thank YOU for your incredible patience and
assistance with logs to help track down / fix this problem. This was really a
nasty bug.

After installing gpg4win 2.3.0 (GpgOL 1.3.0) I had no more crashes.
Thanks for your fix.

Sorry that there has been no response on this but we did not have time to work
on gpgOL.

GpgOL for Outlook 2003 is no longer maintained and support for this in gpg4win
is likely to be dropped soonish.

I'm closing this as nobug to help us clean up the bugtracker. The word editor is
not supported in Outlook 2003 and we will not add support for this. Sorry.

Uhm five years and not reply ;-) Sorry but we did not have much time to work on
GpgOL and the little time we had we spent on Outlook 2010 and later (which is a
different codebase)

The code for 2003 and 2007 is still basically unmaintained. We are looking into
the possibility to remove 2003 support and use the 2010 and later codebase for
2007, too. From your debug output it looks like you are using exchange. This is
not supported for the < 2010 addon. (It is supporeted in the current development
version that will be part of gpg4win 3.0.0)

So you can either switch to Outlook 2010 or later (and for now use the gpg4win
3.0.0 test version) ( https://wiki.gnupg.org/Gpg4win/Testversions ) or hope that
we will enable that codebase for 2007, too.

Sorry that I am marking this as nobug but we will not fix this for 2007 only and
in later versions it already works.

This is fixed in GpgOL master.

Fixed with rev. b879f5b

I wonder if this is a Problem for the new version that can send through
exchange. Available from ( https://wiki.gnupg.org/Gpg4win/Testversions ) We look
up the sender address with exchange a bit differently and I think it should
match the actual SMTP address used now.

The updated translation is part of gpg4win 2.3.0

I think this was fixed in 2.2.3 or so. (The dll search) so this should work now.
I'm currently testing mostly on Windows 10 and there are no problems with
regards to that of which I am aware. So I'm resolving this. Please reopen if
it's still an issue.

Oh, I was not aware of that bug and disabled S/MIME by default in the current
development version.

I'll make the default depending on the Outlook version.

Emanuel tested this. As I wrote, inline editors are another thing.

Should be fixed in git master. There is a small issue that sending encrypted
drafts from the inline reply window does not work. But if you open the draft in
a composer the Sign / Encrypt state is the same as it was when saving the draft.

The inline thingy is another issue. I can catch that and add a Messagebox to
tell the user she should open the messagecomposer to send.

More difficult then I thought.

For PGP/Inline this should currently work. I had the problem that I can't
manipulate the Body in MAPI but over Outlook in the write event this worked.

PGP/Clearsigned support i've disabled for now.

With regards to mime mails:

I could modify / restore the mail there already using old code. The message
is not formed correctly but this looks like just a bug in the revert code.

As it turns out this was totally an understatement ;-) The old revert code can't
have worked. Maybe for S/MIME under some circumstances but otherwise not.

The problem is the main part how Outlook builds the MIME message. Were we have
very limited control about it. Just removing our attachments and leaving the
original MIME attachment leads to a MIME structure like:

<quote>

This is a multipart message in MIME format.

------=_NextPart_000_0000_01D12C53.76E82C90
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0001_01D12C53.76E82C90"

------=_NextPart_001_0001_01D12C53.76E82C90
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

------=_NextPart_001_0001_01D12C53.76E82C90
Content-Type: text/html;
protocol="application/pgp-encrypted";
boundary="nextPart3167407.zD7nylcVYN";
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-W3CDTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
rmj.rmm.rup.rpr">
<TITLE></TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

</BODY>
</HTML>
------=_NextPart_001_0001_01D12C53.76E82C90--

------=_NextPart_000_0000_01D12C53.76E82C90
Content-Type: application/pgp-encrypted;
name="Unbenannte Anlage 00001.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Unbenannte Anlage 00001.dat"

Version: 1
------=_NextPart_000_0000_01D12C53.76E82C90
Content-Type: application/octet-stream;
name="msg.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="msg.asc"

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

hQEMAx7U8Lxs+8kSAQf/eB4zBTz/VSVBBI+ihh/PSorJ98BRh5earBqF8HjmGZce

<end quote>

This is nothing even an MUA like KMail can handle. And GpgOL can handle this
neither. So if we modify the message we have to do it somehow in a way that
Outlook builds a Mime structure again that users can work with.

As we can actually send MIME messages I looked at the code in mimemaker that
builds a message. Using some tricks from there I was able to recreate a PGP/MIME
mail. But this needs special handling for all our message classes.

Still too buggy to commit. Leaks plaintext and I have at least seen that it led
to a duplicated message once.

Modifying the mail in the afterwrite event did not work good. While the
attachment changes were synced to the server Outlook itself didn't reparse the
mail correctly. This let to a weird out of sync situation between MAPI and OOM.
But testing looks like this could work from the Write event indeed. Which would
be even better because we only have one write and we could replace the "Wipe
Message" code completely by just reverting the mail back to the original.

I'm optimistic this can be done. :-)

It's a bit iffy though and might be especially annoying from a performance side
for exchange users. Still it will be better then the Status Quo because you can
still use the mails with other clients.

The trick is not to revert back the message in the Write event, as we have to
work on the OOM in the Write event but in the AfterWrite event where we can work
on MAPI.

I could modify / restore the mail there already using old code. The message is
not formed correctly but this looks like just a bug in the revert code.

This is fixed in master. Kleopatra / GPA is now started on demand. E.g. The
first time a crypo operation actually happens. This also means that GpgOL is
more robust if the user shuts down Kleopatra.

The first crypto operation might take a bit longer but this is better then to
increase the startup time even if a user does not plan to use crypto in this
session. And if we fix T2136 this will hurt even less :-)

Clarified title.

We've added support for Outlook 2016 with gpg4win 2.3.0 (gpgol 1.3.0). Which has
just been released two days ago :-)
Please try this version.