GpgOl was just deactived in my testing setup because the startup was too slow.

This makes this issue more urgent.

This should not happen anymore with the new MIME code in GpgOL for Outlook 2010
and later.
With the "Decrypt Body" function we had in Outlook 2010 and later you could
store the plaintext if you decrypted a mail and then confirmed the "Do you want
to save" dialog.

But for messages which are now automatically decrypted / verified the plain text
should never be stored persistently. T2138 might have caused this but this
was because GpgOL was deactivated before it prevented Outlook from storing the
plaintext.

I clicked on an e-mail today and it got decrypted (although others didn't).

That means that it was a valid PGP/Mime or PGP/Inline mail and you encountered
the new handler code which works similar to the old mail handling we had for
Outlook 2007 and earlier in that it decrypts / verifies automatically and then
shows the plaintext in the mail body.

This e-mails have been left decrypted (see T1106). So I wanted to
disable gpgol

It should not have been left decrypted. GpgOL now prevents that. If Addin
deactivation was involved you might have run into T2138 which I only fixed
on Monday and the fix for this was not in your version.

Pic2.png shows the message we inject in the Mail Body when we encounter Outlooks
"Write event" to avoid just such a leak.

The latest Version (Currently beta-85) also has a fix for the confusing "The
properties of the Mail have changed do you want to save dialog" (Where clicking
yes also brings up the message of Pic2.png)

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgol.git;a=commit;h=452477949fe2f1d8ca36ebbad31c6f3c6607e30e

and when I tried to do so Outlook crashed again.
Because I deinstalled PDF Architect there is no such addin!
Unfortunately there must be another reason.
I'll append gpgol.txt, an excerpt of windows eventlog and screenshots of > the
addins still activated in archiv.tar.gpg.

The debug output / event log match here. It crashes on Release in the destructor
of the Addin object. There might be a bug there if we Release / delete an
invalid object. I'll investigate and test this some more. Thanks.

Because I had serveral crashes the last 2 days I decided to disable gpgol
add-in. I'll see what it's going to happen the next days.

Ok. Please let us know how it works out and if you still see random crashes. And
thanks again for your feedback / testing.

I would prefer if for Windows GnuPG would not use iconv at all as the Windows
API already provides encoding conversion calls. Win-iconv is a small wrapper
around Windows API calls to provide iconv API so that no code changes would be
necessary.

https://github.com/win-iconv/win-iconv

It could be treated as just another POSIX helper / wrapper and included directly
in GnuPG (licensed as public domain).

I have no idea what a trusted extension is and I can happily read / modify the
body through OOM.

I'm marking this as resolved as I don't see anything to do here.

Fixed with: b942f73

If GpgOL is deactivated it cleans up after itself and wipes the plaintext from
mails / session encrypts attachments.
If that fails it shows a warning message.

just installed the free version of PDF Architect 3 in a test VM and after
clicking around a bit I got a crash in Outlook.

Then restarted and got an "Runtimeerror" in the GetCustomUI callback of PDF
Architect 3. (These errors are normally not shown if you don't enable them under
"Erweitert -> Entwickler -> Add-In-Benutzeroberflächenfehler anzeigen")

This addin looks fishy.

I've come up with a theory to explain what we are seeing here:

You have another addin that does some things asynchronously (in a different
thread) this addin then makes a callback into the Outlook Object model. This is
not supported and you should not do this according to documentation. But it
might just work.

Assuming (because you don't see random crashes where gpgol is not involved) that
this works in the majority of cases but when outlook is busy executing third
party code (like gpgol) this causes the crash.

In that case Outlook would think that it crashed in gpgol as the main thread of
Outlook was executing gpgol code at the time of the crash although gpgol did
nothing wrong.

This theory could be validated if you leave GpgOL active but start to disable
other addins and check that the crashes disappear.

I've added werner to the nosy list. Maybe he has another idea.

Both those Event log entries are bogous.

If you take a look at the application events callback:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgol.git;a=blob;f=src/application-events.cpp#l58

In case it is called with NewMailEx (0x0000FAB5) or OptionsPagesAdd (0x0000F005)
as the event log entries suggest.

The only lines executed are:

USE_INVOKE_ARGS (which is a helper macro to reduce compiler warnings. Does nothing)

log_oom_extra ("%s:%s: Unhandled Event: %lx \n", SRCNAME, func, dispid);

and
return S_OK;

There is simply no way that this can crash.

The previous crash you've reported in ApplicationEvents was for the ItemLoad
event. This does some more stuff so I accepted that there might be a crash in there.

But there is no way that the Event handler could crash in the other two events
from T1837 (kjathome on Oct 30 2015, 04:56 PM / Roundup) and T1837 (kjathome on Oct 30 2015, 04:46 PM / Roundup)

looking at the data from 20152029.tar.gpg:

At the point where the Eventlog reports the crash GpgOL was not doing anything
according to the debug output. I'm not sure what the Windows event log wants to
tell me with "gpgol.dll_unloaded" in the error message.

And with exporting contacts. There is absolutely no code in GpgOL that does
anything with contacts. :-/

I've talked with Werner (who handled gpgol development before me) about this bug
and that I am clueless how a static function like GetCustonUI could sometimes
crash and sometimes not. And he thinks that the EventLog information may just be
wrong.

E.g. It just prints the last function called in gpgol. While the actual problem
might be caused by a different addin.

I should probably ask on the gpg4win-users mailing list if others are seeing
those random crashes too. But with the frequencies you are seeing I would expect
that we had more reports about this.

If you can reproduce this with exporting contacts, maybe you can disable the
other addins you are using in Outlook and check if it still crashes?

Or disable GpgOL and check if the crash dissapears?

Btw. The Windows 10 login screen implements this as a button that you can not
tab to and only shows the password for as long as you keep clicking it.
It also disables / hides the show password button once the password entry field
loses input focus.

They use a heavily abstracted eye icon and no tooltip. Probably with the
rationale that if a user clicks there and it shows the password
(unintentionally) he can quickly release the mouse button again before someone
can read the password.

I've never seen this but there is code for it in case op_assuan_sign is called
without a sender.

Should not happen except in bug cases. So it would probably be better just to
show an error in that case rather then a weird "GpgOL is annoyed with Kleopatra"
email address.

I've just disabled the unit tests in Kleopatra that expose this bug.
The tests should be renabled depending on a version check for a version of gpgme
where the problems are fixed.

Fixed with 694a6e4 was indeed the same problem I had with my buttons. (local8
bit encoding passed to put_oom_string which expects utf8)

I'm directly resolving this as I tested myself.

Uh that's an embarassing error.

Thanks for your analysis and fix. I haven't seen problems with this in my tests
but the UTF8 Byte array is indeed temporary and the pin pointer is invalid after
it's destruction.

I've commited the your fix (with an ammended commit message so it confirms to
the msg style used in pinentry) with f143d21

Werner I've assigned it to you as this needs a release :/ Sorry.

I've just uploaded a new binary:

http://files.gpg4win.org/Beta/gpgol/1.3.0-beta71/

Debug output looks ok.

Please check that the old version (as included in gpg4win 2.2.6) does not show
the same behavior in your setup.

If It's not a regression I'm inclined to mark this as a wontfix.

Ok. Thats what I thought.

The problem is that
" 90695/8872/mailitem-events.cpp:Invoke: Unloaded. " Is unrelated to the
function the event log says caused the crash (application-events.cpp:Invoke).
And is the usual last line of a "normal" mail item unload..

In Application Events the first log entry would have been "Installing event sink
on mailitem: ..." [1]

But as we did not see that before the crash I've added a check if parms is NULL
in that call (Which according to msdn it should never be and that function is
called by outlook and not by us). And added debug output before the first
function call in that function (But that function call is just an Error wrapper
around a QueryInterface call which should also never ever crash ;-) )

Weird.

1:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgol.git;a=blob;f=src/application-events.cpp;hb=560cea7e5bbf7f0404e4f1977b42710245f26b1f

Thanks!

Did you obtain the log right after the crash or have you started / shut down
outlook once after the crash? (From the debug output it looks that way).

Or did the crash happen when closing Outlook?

I've just commited a change to the logging format so that the current UTC Date
Time is included in the log and it can be better correlated with EventLog entries
and I don't have to ask such questions in the future ;-)

I've also added a guard against an invalid parmeter in the function now reported
to crash (The Application ItemLoad event handler) and even more debug output in
that function (because I doubt that the invalid parameter caused the crash).

I'll give you a ping here when I've uploaded a new version.

With the informsec code we had "decent" support for encrypted / decrypted
attachments.

With 1.3.0 we have very nice read support for MIME Attachments (including
Outlook's internal preview). And send support is on the roadmap.

But this is event based code. I'd say we can close this issue.

Emanuel can you check if this is still the case with the current version? I
think it should still be the case as I have tried to leave this all intact.

But the problem is likely the same as for
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgol.git;a=commit;h=1bab2eba47249b258759ad7d897ef96e76bb9557

And easy to fix.

Duplicate of T1826

Please try the latest 1.3.0 beta version which is available from:

https://wiki.gnupg.org/GpgOL/Development/Testversions

This version has experimental read support for PGP/MIME mails.

I'm closing this issue as a duplicate of T1826 which already tracks PGP-MIME
support in gpgol.

I have to check if this is possible (Depending on the parameters in the forward
reply events this could even be trivial)

You may want to try out the latest 1.3.0 Beta version which supports reading
PGP/MIME mails. See:

https://wiki.gnupg.org/GpgOL/Development/Testversions

I've just uploaded a Test Version of a new GpgOL and documented it under:
https://wiki.gnupg.org/GpgOL/Development/Testversions

While the main focus for that Testversion is MIME support I've also added a lot
of debug output in the functions you see crashing:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgol.git;a=commitdiff;h=7016fec9aef7be53f164829f7c76e28c6a83e228

If you are willing it would be a great help if you would install that version
and provide me with the gpgol debug log after you encounter the next crash.

They just might also be gone because of the changes mentioned in T1837 (aheinecke on Oct 13 2015, 12:06 PM / Roundup) but I
doubt it.

This can happen if you block connections to localhost or if you have changed the
IP Address localhost resolves to. (The reason for this is Interprocess
communication)

You can try to look at the debug output with debugview:
https://technet.microsoft.com/en-us/library/bb896647.aspx

This might help track down the problem.

An option to explicitly disable qt5 was added as part of T2105

Thanks for the info (and again apologies for your trouble)

btnDecryptLarge and btnDecrypt are also functions that only fetch resource data
like GetCustomUI. I don't understand why they would crash only some time and not
always.

From looking at the code the only possible problem I see is that an invalid
result pointer is passed to that function. There is not check for that. I'm
adding one.

With regards to getcustomui:

In the current mime-addin development branch I'm currently working on I have
modified the ribbon ui function to use a dynamically allocated string. But this
should not the problem because the locale strings should not change.

Another theory that I need to check is that the pointers to the localized string
I use there are not guaranteed to be valid when they are used in the sprintf
call. They should be, but maybe there is a problem with our gettext
implementation. So I'll reduce the lifetime of the pointers to the function call.

Right. Hopefully fixed with 48ab8cd

I wonder why this worked for me. If I try to run your testcase it fails with
bash / dash / zsh.

I've fixed the variable assignment with rev. e9d063e
Sorry. Worked for me on debian jessie with dash.

Haven't seen this problem for months and npth-1.2 contains the fix.

-> Resolved.

Yes only on Windows. Works for me on GNU/Linux, too.

The rationale behind this was that it should just compile with Qt > 4.4 and take
the newest version available. But yes with Qt packaging in different names
between 4 and 5 etc. I can see that this can be problematic.

With: 08ec9556c8a384ea7bb5d42d3f6aab6c2f6a8786 I've added an option
"disable-pinentry-qt5" to explicitly disable looking for qt5.

Does this solve your problem?

You've actually added code to handle the hostname:port string with rev: 54e55149

But this does not work as the parse_uri check before hat is called with
"no_scheme_check" and so already passes a hostname:port uri as valid and does
not go into the fallback code that adds the http scheme.

D329: 685_0001-Dirmngr-Default-to-http-protocol-for-http-proxy.patch

Regardless of that, I find this is a regression. With my configuration I was
able to search on keyservers with 2.0.x and then with 2.1.x keyserver search no
longer works with the same configuration.

And it's probably easier to default to http protocol for a http-proxy in gnupg /
dirmngr again then it is for me to warn users in Kleopatra / Gpg4win that their
configuration no longer works with 2.1.

I can't reproduce this problem.

GpgOL tries to talk to Kleopatra through a file in %APPDATA%\gnupg

please make sure the permissions on this folder are correct. If you started
things with Administrator privileges before there might be files in there that
are only accessible for administrators and not with normal user rights.

Duplicate of T2000

This was causing some other problems so it got treated as a bug in T2000 it
is fixed in the latest 2.0 and 2.1 releases.

I've searched for the context in question and it turns out the last 1000 lines
are not nearly enough to follow it.

So here is the full log of that run.

I can still see the asserts and segfaults when running the tests in gdb or with
logging enabled. So it's not a heisenbug ;-) (Although I was never able to get a
backtrace from kleopatras unit test. That test passed when running in gdb)

Do you want me to provide you with logs?

Here is an example segfault:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffe50f01700 (LWP 25135)]
0x00007ffff7babfe3 in _gpgme_wait_on_condition (ctx=ctx@entry=0x7fff6c0070e0,
cond=0x6a8844002920, cond@entry=0x7fff6c007f20,

op_err_p=op_err_p@entry=0x0) at wait-private.c:155

155 if (cond && *cond)
(gdb) bt
#0 0x00007ffff7babfe3 in _gpgme_wait_on_condition
(ctx=ctx@entry=0x7fff6c0070e0, cond=0x6a8844002920, cond@entry=0x7fff6c007f20,

op_err_p=op_err_p@entry=0x0) at wait-private.c:155

#1 0x00007ffff7bb3236 in gpgme_op_keylist_next (ctx=0x7fff6c0070e0,
r_key=r_key@entry=0x7ffe50f00ef8) at keylist.c:996
#2 0x00000000004010de in start_keylist (arg=<optimized out>) at
t-thread-keylist-verify.c:62
#3 0x00007ffff798c0a4 in start_thread (arg=0x7ffe50f01700) at pthread_create.c:309
#4 0x00007ffff76c104d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Attached is the corresponding gpgme-log (issue-2092-gpgme-log-1.txt)

D327: 678_0001-Add-tests-for-threading-problems-in-keylist.patch

AESNI is enabled in the gnupg 2.1 installer which we will use with gpg4win 3.0

This problem still occurs with libgcrypt from current master:
libgcrypt 1.7.0-beta259

#0 0x655f24a7 in _gcry_aes_aesni_do_setkey (ctx=0x97f868,

key=0x656621b4 <key_128>

"\350\351\352\353\355\356\357\360\362\363\364\365\367\370\371\372\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004",
<incomplete sequence \343>) at rijndael-aesni.c:117

Forgot to resolve this as superseeded.

With gcrypt compiled with -mstackrealign as analyzed in T2085 this problem
is also fixed.

So I'm marking this as a duplicate of T2085.

Duplicate of T2085