Page MenuHome GnuPG
Create Task
Maniphest T7241

GpgOL: Crashes after decryption and key update
Closed, InvalidPublic
Actions

Description

If I test GpgOL a bit harder with a current build of master GPGME and GpgOL I can pretty reliably get outlook to crash after decrypting a signed and ecnrypted mail fropm myself. This is not fully reproducable but by openening multiple explorers viewing the mail multiole times seesm to at least increase the chance for this crash. The last lines ion the log are pretty much unspectacular

 canCertify:    1
 canAuth:       0
 canRenc:       0
 canTimestanp:  0
 isSecret:      1
 isGroupOwned:  0
 isQualified:   0
 isDeVs:        1
 isCardKey:     0
 cardSerialNumber:<null>)
GpgME::Subkey(
 fingerprint:   46ED5D7758C1BD71C27AF928FFA2FCCB2EC589F8
 keyGrip:       8B8713E028E9DC05A4FEA1B70A21B293C2081819
 creationTime:  1678274145
 expirationTime:0
 isRevoked:     0
 isExpired:     0
 isInvalid:     0
 isDisabled:    0
 canSign:       0
 canEncrypt:    1
 canCertify:    0
 canAuth:       0
 canRenc:       0
 canTimestanp:  0
 isSecret:      1
 isGroupOwned:  0
 isQualified:   0
 isDeVs:        1
 isCardKey:     0
 cardSerialNumber:<null>)
 revocationKeys:
)
11:25:42/5864/windowmessages.cpp:do_in_ui_thread: Sending message of type 1102
11:25:42/9248/keycache.cpp:do_update updating: "F8D51DE0EE16E9B57009B8DE458612006D8E6F0D" with protocol OpenPGP
11:25:42/8552/windowmessages.cpp:gpgol_window_proc: Recieved user msg: 1102
11:25:42/8552/DBG_OOM/Mail 233b0fd0 Parsing done for parser num 2: 28125a80
11:25:42/8552/keycache.cpp:getFromMap using "F8D51DE0EE16E9B57009B8DE458612006D8E6F0D" for "F8D51DE0EE16E9B57009B8DE458612006D8E6F0D"
11:25:42/8552/keycache.cpp:getByFpr Cache hit for F8D51DE0EE16E9B57009B8DE458612006D8E6F0D.
11:25:42/8552/mail.cpp:updateSigstate: Classified sender as verified uid validity: 5 origin: 0
11:25:42/8552/DBG_OOM/oomhelp.cpp:get_oom_object: looking for 37cf2630->`Parent.Store'
11:25:42/8552/DBG_OOM/oomhelp.cpp:get_oom_object:411 AddRef on 37cf47e8
11:25:42/8552/DBG_OOM/oomhelp.cpp:get_oom_object:411 AddRef on 37cf4ed0
11:25:42/8552/DBG_OOM/oomhelp.cpp:get_oom_object: looking for 37cf4ed0->`Categories'
11:25:42/8552/DBG_OOM/oomhelp.cpp:get_oom_object:411 AddRef on 37cf47e8
11:25:42/9248/keycache.cpp:insertOrUpdateInFprMap Lost secret info on update. Merging.
11:25:42/9248/keycache.cpp:do_update Update job done

Which seems okay. Since this would be how a successful decryption always ends.

Revisions and Commits

rO GpgOL
rO7a82754a2ed7 Statically link winpthread

Event Timeline

• aheinecke triaged this task as High priority.Aug 5 2024, 1:31 PM
• aheinecke created this task.
• aheinecke closed this task as Invalid.Aug 5 2024, 4:26 PM

As I could not reproduce the issue with different builds I realized that I was compiling and linking GpgOL for development using a very different version of winpthread.
When I switch to a consistent build and runtime library the crash no longer happens. I wonder if we can maybe statically link winpthread, too. But I think that is coming from Gpgme++ since GpgOL only uses windows threads.

• aheinecke added a commit: rO7a82754a2ed7: Statically link winpthread.Aug 5 2024, 5:01 PM