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.

I've checked that 2.1.10 still has the problem. So back to you.

You can ping me directly if you need any debug logs or so.

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

Thanks for helping keep track of all these issues.

Yes this only fixes the problem that has already been fixed in the last Gpg4win
Versions. So that this will be fixed in future gnupg-2.1 versions.

Still to help us better seperate the problems I would like to close this as for
me this bug was about "Wrong encoding in a localized version".

• the more critical "passphrase with non ASCII characters" problem (as reported

only here, see T1691 (andreaerdna on Aug 19 2014, 02:36 AM / Roundup)); does this bug need a
dedicated new Issue to be addressed and solved?

I actually overlooked this in this issue. Can you please open another issue for
that. And add me to the Nosy.

• the "utf-8 encoding of encrypted filenames" / "strange behaviour of --utf8-

strings, --no-utf8-strings and --charset options" (as reported in Issue 1409 ad
probably similar to Gpgtar Issue 1624 / Gpa Issue 2185)

If this problem was still existing with gpg4win this is still a problem.

• the "charset weirdness searching keyserver for some non-ASCII user IDs under

non-UTF-8 locales" (as reported in Issue 1514).

This appears not to be windows specific. Also I think this works except for
cases where the Key in question is problematic. If I search on windows for
emanuel@intevation.de I get the correct Umlauts shown. Might be a Problem though
for characters that are unrepresentable in the 8 Bit codepage.

I'll try to look into that.

if there is a behavioral change regarding the encoding a difference between qt4
and qt5 this would be a bug. Both convert the input to UTF-8, I think GTK does
too. I've just tested it and it worked.

So they should be the same. Can you provide an example test case by starting
pinentry from the command line and using "getpin"?

After some more discussion and testing in the development jabber channel werner
agreed to include this patch. Pushed to libgpg-error with 823e858. So this will
hopefully be part of the first gnupg modern release that will include localization.

Btw. this was patched in Gpg4win for over a year now. So I expect we would have
heard if this caused regressions.

I've opened T2185 for the GPA Problem so i can change the topic here and we
can cleanly close this issue when the gpgtar fix is applied upstream.

We might also want to create a new fix for UTF-16 support in gpgtar once this is
closed. But the attached patch would improve the current situation already a lot.

D210: 737_0001-Fix-windows-8bit-encoding-conversion.patch

Updated Patch against libgpg-error where this code now lives.

Please apply this patch or something similiar.

The problem I can see is that with this code in libgpg-error now GUI
applications may use it which want to get "GUI Native".

Probably better to introduce a new function "wchar_to_console" ? And use it from
GnuPG. Does GPA use that conversion function?

Might be a good time for this now where gnupg master already depends on new
symbols in libgpg-error.

Also reproducible under GNU/Linux with KDE 4.14 not reproducible with git master.

Secure deletion is a hard problem that depends on the operating system and the
file system used and might even depend on the hardware. I'm not sure if the way
mentioned in this wish would result in "Secure deletion".

GnuPG is not the tool for this.

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 :-)

Test data from: http://keyserver.borgnet.us/dump/sks-dump-0000.pgp.bz2

In one console window:
mkdir c:\test-issue2135
set GNUPGHOME=c:\test-issue2135
gpg2 --import c:\users\aheinecke\Desktop\sks-dump-0000.pgp

in another:
set GNUPGHOME=c:\test-issue2135
gpg2 -k

Triggers this: (And the error messages also look wrong)

gpg: waiting for lock c:/test-issue2135/pubring.gpg.lock...
gpg: renaming c:/test-issue2135/pubring.gpg' to c:/test-issue2135/pubring.bak'
failed: Permission
denied
gpg: error writing keyring `c:/test-issue2135/pubring.gpg': Permission denied
gpg: key CBB511F4: public key "[User ID not found]" imported
gpg: error reading `c:\\Users\\aheinecke\\Desktop\\sks-dump-0000.pgp':
Permission denied
gpg: import from `c:\\Users\\aheinecke\\Desktop\\sks-dump-0000.pgp' failed:
Permission denied
gpg: Total number processed: 278
gpg: w/o user IDs: 14
gpg: imported: 265 (RSA: 82)
gpg: renaming c:/test-issue2135/pubring.gpg' to c:/test-issue2135/pubring.bak'
failed: Permission
denied
gpg: failed to rebuild keyring cache: Permission denied
gpg: no ultimately trusted keys found

Clarified title.

Bernhard:

I've tried out KDE 5 and noticed that the standard password dialog there already
has such an option. http://www.aelog.org/password-visibility-in-kpassworddialog/

My strong preference for Pinentry-qt would be to make it similar. As a unified
UI adds value and pinentry-qt is afail most often used with Windows and KDE
desktops. And the solution outlined in the link above is also very similar to
the Windows 10 password entry.

For GTK we should implement it the way werner has outlined and as has been
discussed on the mailing list. So that users with more "Keyboard centric"
workflow have the GTK alternative available.

Would this be acceptable for you?

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.

Werner, I know that nothing much in pinentry has changed since 0.9.6 but this
bug is pretty bad for pinentry-qt. It would be good to have a new release.

In this case I'm pretty sure that it does not. I check that I can come up with a
testcase that does not involve kleo.

I had a look at your logs. Indeed I can see where it crashes, and it really
looks like gpgol did something at the time of the crash. It crashed after a Mail
was Loaded by outlook and before it was read. I've read the related code again
and could not find a problem.

If you are testing again anyway Please set your EnableDebug value to 1536. This
enables Debug output related to outlooks internal data model and could help.

We don't see any more crashes in testing and we had some other people test
1.3.0. before the release. Is it crashing or does outlook freeze up / not
responding?

Just to ensure that we have comparible setups, have you enabled other plugins
again? If so which?

I'll take a look at your debug output to see if I find something out of the
ordinary.

There was only a crash at the very beginning when I started outlook and forwared
an email with encryption to myself. Outlook crashed but module MSPTLS.DLL has
been reported to be the cause of the failure.

I'll try it out.

In the log file of gpgol I noticed that there is a huge amount of messages
in.lock taken or released and the same for out.lock. Is it possible to disable
selectively these lines because it floods the disk and I'd like to have some
debug lines enabled if some problem might occur.

Yes just set the enableDebug registry setting of GPGOL
(HKEY_CURRENT_CUSER/Software/GNU/GpgOL) to 1
You currently probably have it at a much higher level.
This will disable the most spamming debug outputs and leave the important stuff
active.

I think that I found and fixed the problem.

There is a method COM addins have to implement to indicate weather or not it's
Ok for them to be unloaded. I totally forgot about that method as I've
implemented it years ago as part of the standard "stuff you have to implement
for COM".
This method used bad values to check if an unload is ok (which basically should
be never as long as we are not deactivated).

My current understanding is that the trigger here was that after exporting
contacts some internal cleanup code in Outlook checks if there are Addons that
are no longer needed and unloads them if they tell Outlook that this is Ok.
Which we dit. So Outlook unloaded us and any more calls to GpgOL crashed.

I could confirm with debug output that this was called right before GpgOL was
unloaded and we told Outlook that it's Ok to unload us.

This cleanup can probably happen under other circumstances, which would also
explain the random crashes you've seen before.

Thanks again for your patience and your excellent feedback in this issue which
made it possible to find and fix this.

The fix is:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgol.git;a=commit;h=1362563c9370cc9c00463293a7f6eeb91b9424de

A binary with the fix is:
https://files.gpg4win.org/Beta/gpgol/1.3.0-beta108/gpgol.dll

There will be a gpg4win release with this Version soon.

Please let me know if you are still seeing crashes ;-) I could not reproduce any
more crashes with this version.

I'm marking this as resolved as the currently released version of pinentry
compiles with gcc-5.1

I understand whats happening here now. I still don't undestand the Why.
For my tests I've disabled all other Addons to rule out interference.

In the crashing case Outlook unloads GpgOL from it's memory. This happens
regularly with the test described in T1837 (aheinecke on Nov 16 2015, 08:07 PM / Roundup). But as the original Report
mentioned crashes at other points I'm not really sure what causes this but
Exporting contacts seems to be a good trigger.

This Unload does not call any of the Registered Cleanup methods like
"OnDisconnect" etc. and GpgOL is never Unregistered in Outlook. The only thing I
can see is that DLLMain is called with "PROCESS_DETACH". And that ProcessExlorer
no longer shows GpgOL as loaded.

Any callback outlook calls into gpgol, getCustomUI, ApplicationEvents ItemLoad
etc. will cause a crash as the memory behind those callbacks is invalid. This is
why we've seen crashes apperantly all over the place.

Ok now that we know the What. We have to figure out the Why. A websearch about
this has not brought up anything.

My current speculation is that there is some interference with out old
ExchangeExtensionCode that might be activated by exporting contacts (this dialog
looks really old).

Well but at least we are getting closer. In fact in my development version I
have a nice messagebox popup "Gpgol was unloaded Outlook will now crash" :-) But
yeah thats not really helpful...

While Werner mentioned that he might have solved this in previous versions I'm
not seeing this in the code. I'll have to test with GPA as it might be that
progress information causes gpgol to temporarily yield the event loop.

Tested this and GPA also blocks Outlook the same way as Kleo. Which was expected
as the blocking happens in GpgOL.

I was able to reproduce this five times. It appears that time is also a factor
here. When I start GpgOL look at a mail, go to contacts ands export them I dont
get crashes.

But when I wait ~10 minutes after opening the contacts view I get the crashes
pretty reliably.

Funny thing is and I see from your logs that something similar happened at least
once for you that the last Debugoutput of GpgOL is way before the crash.

e.g.

• switch to contacts at 18:30
• wait 10 minutes
• export contacts, switch to mail.
• Crash.

Last debug output before the crash is from 18:30 eventlog shows the crash at
18:40 and the restart of gpgol and the startup procedure is logged at 18:40.

But the ItemLoad event where the EventLog says gpgol is crashing is what gpgol
should be getting once we switch back from the contacts view to the mail view.
But gpgol does not get it. I've added debug output in the first line of that
function and it is not called.
The handler for the ItemLoad event is also not deleted and still valid.

Next step will be for me to look at the address of GpgOL's event handler
function and at the address which is called when outlook crashes... I still
don't even have a theory what's happening here.

Datei->Optionen->Erweitert->Exportieren->In Datei exortieren->Weiter->Outlook
Datendatei (.pst)->Weiter->Weiter->specify file name for the export->Fertig
Stellen->OK.

\o/ This way I was able to reproduce the crash after switching back to the Inbox
and Outlook complained that GpgOL caused the crash.

Wow. This will be fun to debug, we are doing absoluetly nothing with contacts.

Just to recap:

• You can export Contacts with GpgOL disabled.
• When you have GpgOL enabled Exporting contacts Crashes Outlook.

How do you export contacts? I've tried with selecting "Personen (probably
Persons)" tab and dragged & dropped my contacts to a folder in the filesystem.
.msg Files for those contacts are created and no crash. I can switch back to
Mails, decrypt mails etc. no crashes for me :-/

This is with outlook 2013 and 2016 and either with or without an Exchange
Account. (But exchange without Active Directory)

Can you again send me a log of such a crash please? Maybe with all the added
debug output I can see something out of the ordinary.

Ah and with regards to the mime-send variant. That is a variant of GpgOL that
has experimental support to send PGP/MIME mails. (e.g. Mails that follow a
proper standard for crypto mails and are more interoperable with thunderbird and
gpgmail)

Then you won't have to encrypt the body anymore and add encrypted attachments
etc. but rather you just mark "this mail should be encrypted" and when you send
it it will be encrypted including all attachments etc.

Once we release 1.3.0 this will be the basis for the next version for now we
mainly use it for internal testing and as a proof of concept. The UI is not
where we want it to be. I'll write something about it in the wiki.

Btw. I've tried to explain a bit how the MIME Support in 1.3.0 works in the wiki
already: https://wiki.gnupg.org/GpgOL/MIMESupport

Ah and with regards to the mime-send variant. That is a variant of GpgOL that
has experimental support to send PGP/MIME mails. (e.g. Mails that follow a
proper standard for crypto mails and are more interoperable with thunderbird and
gpgmail)

Then you won't have to encrypt the body anymore and add encrypted attachments
etc. but rather you just mark "this mail should be encrypted" and when you send
it it will be encrypted including all attachments etc.

Once we release 1.3.0 this will be the basis for the next version for now we
mainly use it for internal testing and as a proof of concept. The UI is not
where we want it to be. I'll write something about it in the wiki.

Btw. I've tried to explain a bit how the MIME Support in 1.3.0 works in the wiki
already: https://wiki.gnupg.org/GpgOL/MIMESupport

A change I did for the 64 bit version of Outlook caused the load problem. This
did not happen for my development builds as they were not run cleanly (in
contrast to the builds I upload)

Fixed with https://files.gpg4win.org/Beta/gpgol/1.3.0-beta104/

Apologies and thanks for your feedback!

I can reproduce the problem that this dll does not load.

Weird the same version compiled directly works for me. I'll investigate what
happens on the build system / with the buildscript.

Yes there is a new version available from the usual place. beta 103 is currently
the latest. I'll probably publish a beta installer containing that version later
today.

I've disabled the automatic keylisting while an import job is running in
Kleopatra as this is a good idea anyway.

Still this should be fixed although we might want to give it a try with 2.1
instead as it is no longer a hard issue for gpg4win with the workarond in kleo
in place.

The import with 2.0.29 is also very slow on Windows. Over two minutes to import
650 keys while the same import with 2.1.9 on GNU/Linux only takes 20seconds.

Hi,

The "crash on disable" from T1837 (kjathome on Nov 03 2015, 06:44 PM / Roundup) was indeed a bug in gpgol. I've fixed it
with rev. 4f8c746e (included in beta100 and later). It only happened under
circumstances that did not occur in my development environment.

Have you seen crashes while gpgol was disabled?

Regards,
Andre

I've fixed this in the KDE translations.

Updated translations need to be put in gpg4win.

For the record Rolf Eike Beer still maintains KGpg (I was not aware of this when
i wrote T2048 (aheinecke on Aug 28 2015, 10:54 PM / Roundup))
And he is planning to port it to Qt5.
See: https://mail.kde.org/pipermail/kde-community/2015q3/001651.html

Please leave this issue closed here. This bug either belongs in the Fedora
Bugtracker or in KDE's bugtracker.