Open Bug 1675742 Opened 2 years ago Updated 3 months ago

Thunderbird crashes when using GPGME for smartcard integration on macOS

Categories

(MailNews Core :: Security: OpenPGP, defect)

defect

Tracking

(Not tracked)

People

(Reporter: me, Unassigned, NeedInfo)

References

Details

(Keywords: crash)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

Thunderbird auto-upgraded me to version 78, which broke my GPG smartcard integration with Enigmail. Once I figured out that I need to install GPGME (thanks to https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards), a subprocess of Thunderbird started to crash (noticeable due to the "Report problem to Apple" dialog) whenever I wanted to read an email which was encrypted for a key on my smartcard.

Actual results:

Signing a message also fails with the following message in the error console:

mimeEncrypt.js: caught exception: Error
Message: 'failure in finishCryptoEncapsulation'
File: chrome://openpgp/content/modules/mimeEncrypt.jsm
Line: 588

The report of the crashed process, which I could send to Apple, includes:

Process: thunderbird [4076]
Path: /Applications/Thunderbird.app/Contents/MacOS/thunderbird
Identifier: thunderbird
Version: 78.4.0 (78.4.0)
Code Type: X86-64 (Native)
Parent Process: thunderbird [4073]
Responsible: thunderbird [4073]
User ID: 503

Date/Time: 2020-11-06 12:25:40.928 +0100
OS Version: Mac OS X 10.15.7 (19H2)
Report Version: 12

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [4076]

Application Specific Information:
crashed on child side of fork pre-exec

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_malloc.dylib 0x00007fff727aae41 nanov2_forked_calloc + 7
1 libsystem_malloc.dylib 0x00007fff72795f59 malloc_zone_calloc + 99
2 libsystem_malloc.dylib 0x00007fff72795ed9 calloc + 24
3 libobjc.A.dylib 0x00007fff7142a603 allocateBuckets(unsigned int) + 29
4 libobjc.A.dylib 0x00007fff7142a096 cache_fill + 283
5 libobjc.A.dylib 0x00007fff71429b27 lookUpImpOrForward + 530
6 libobjc.A.dylib 0x00007fff71429399 _objc_msgSend_uncached + 73
7 libsystem_asl.dylib 0x00007fff7261da9a _asl_mt_shim_fork_child + 33
8 libSystem.B.dylib 0x00007fff6f5c3aae libSystem_atfork_child + 49
9 libsystem_c.dylib 0x00007fff7263d8ad fork + 40
10 libgpgme.11.dylib 0x000000012852dd6f _gpgme_io_spawn + 356
11 libgpgme.11.dylib 0x000000012852f895 read_gpgconf_dirs + 208
12 libgpgme.11.dylib 0x000000012852f1a0 get_gpgconf_item + 295
13 libgpgme.11.dylib 0x000000012851d74c gpgme_get_engine_info + 99
14 libgpgme.11.dylib 0x000000012851db52 _gpgme_engine_info_copy + 365
15 libgpgme.11.dylib 0x0000000128530acb gpgme_new + 388
16 XUL 0x000000011434ac3c ffi_call_unix64 + 76
17 XUL 0x000000011434a41f ffi_call + 895
18 XUL 0x0000000113a4b936 0x10f9f4000 + 67467574

Expected results:

To me, this looks like a segmentation fault in GPGME. I thought I can get more information when I enable logging for GPGME (see https://www.gnupg.org/documentation/manuals/gpgme/Debugging.html), so I executed:

export GPGME_DEBUG=9:~/gpgme/log.txt
/Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin

on my command line. To my surprise, everything worked (both decrypting incoming emails and signing outgoing emails). It turned out that the logging wasn't necessary: When I open Thunderbird by double-clicking its icon in the Finder, the GPG integration doesn't work. When I open Thunderbird through the command line (also when calling thunderbird instead of thunderbird-bin since the former is in Thunderbird's Info.plist file), it works. My Thunderbird version is 78.4.0 and I installed GPGME with Homebrew in version 1.14.0_1. Maybe it's purely a GPGME problem, which should be reported there. But maybe Thunderbird doesn't use GPGME correctly when opening Thunderbird with a double click.

If you can't do anything about this issue, you can ignore it. I've found a workaround which is acceptable to me. If anyone else encounters this issue, then the workaround is now publicly documented.

You've never gotten the crash reporter ?
https://support.mozilla.org/en-US/kb/mozilla-crash-reporter-tb

Component: Untriaged → Security: OpenPGP
Flags: needinfo?(me)
Product: Thunderbird → MailNews Core

I'm not sure what you mean. Such a window never opened, no. Is this something I have to enable/install? Since I use Thunderbird for sensitive communication (when I have to use GPG), I disabled all reporting to Mozilla. Do you need more stacktrace information?

What I realized: I probably have some environment variable, which Thunderbird doesn't receive when being started directly. Let me know if you have a suggestion of how we can narrow this down.

Flags: needinfo?(me)

The crash reporter is enabled by default. But if something is running in a process not attached to thunderbird then the reporter would not be invoked.

Flags: needinfo?(kaie)

Thanks for your report.

A while ago we heard a similar report. I believe what had helped the other user was the logging environment variable, and IIUC it was on Windows.
Maybe it's some timing issue.

In order to fix this bug, we need a developer who has access to the relevant hardware and can try to reproduce and debug in detail.

Flags: needinfo?(kaie)

Got the same case on the macOS.
Prerequisites:

  • macOS Catalina 10.15.7
  • no Thunderbird/GnuPG/gpgme previously installed.
  • Installed Thunderbird and gnupg/gpgme via homebrew.
  • Imported keys to the GnuPG, Yubikey works fine from the console.
  • Setup Thunderbird as it is described in the Wiki

Result: running Thunderbird and attempting to decrypt messages reports a crash in gpgme.
Signing doesn't work as well, but sure whether it crashes.

Debugged GPGME a bit and here are the details:

  • when opening Thunderbird from terminal via
export GPGME_DEBUG=9:~/Temp/gpgme.log
open /Applications/Thunderbird.app`

Got the following log piece:

GPGME 20201201T164713 6113  gpgme-dinfo: gpgconf='/usr/local/bin/gpgconf'
GPGME 20201201T164713 6113    _gpgme_io_pipe: enter: inherit_idx=1 (GPGME uses it for reading)
GPGME 20201201T164713 6113    _gpgme_io_pipe: leave: read fd=63 write fd=64
GPGME 20201201T164713 6113    _gpgme_io_spawn: enter: path=/usr/local/bin/gpgconf
GPGME 20201201T164713 6113    _gpgme_io_spawn: check: argv[ 0] = /usr/local/bin/gpgconf
GPGME 20201201T164713 6113    _gpgme_io_spawn: check: argv[ 1] = --list-dirs
GPGME 20201201T164713 6113    _gpgme_io_spawn: check: fd[0] = 0x40 -> 0x1
GPGME 20201201T164713 6113    _gpgme_io_spawn: check: waiting for child process pid=24860
GPGME 20201201T164713 6113    _gpgme_io_spawn:675: error: Undefined error: 0 (0)
...
GPGME 20201201T164713 6113  gpgme_op_decrypt_ext: enter: ctx=0x00000001341d2600 cipher=0x0000000138058400, plain=0x0000000138058c00
GPGME 20201201T164713 6113  gpgme_op_decrypt_ext:182: error: Unsupported protocol <GPGME>
GPGME 20201201T164713 6113  gpgme_data_release: call: dh=0x0000000138058400 
GPGME 20201201T164713 6113  gpgme_data_release_and_get_mem: enter: dh=0x0000000138058c00 r_len=0x000000013bcde4b0
GPGME 20201201T164713 6113    gpgme_data_get_prop: enter: dh=0x0000000138058c00 dserial=0 1
GPGME 20201201T164713 6113    gpgme_data_get_prop: leave: 
GPGME 20201201T164713 6113    gpgme_data_release: call: dh=0x0000000138058c00 

However, if I run it directly, via /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin:

GPGME 20201201T171253 6257  gpgme-dinfo: gpgconf='/usr/local/bin/gpgconf'
GPGME 20201201T171253 6257    _gpgme_io_pipe: enter: inherit_idx=1 (GPGME uses it for reading)
GPGME 20201201T171253 6257    _gpgme_io_pipe: leave: read fd=24 write fd=52
GPGME 20201201T171253 6257    _gpgme_io_spawn: enter: path=/usr/local/bin/gpgconf
GPGME 20201201T171253 6257    _gpgme_io_spawn: check: argv[ 0] = /usr/local/bin/gpgconf
GPGME 20201201T171253 6257    _gpgme_io_spawn: check: argv[ 1] = --list-dirs
GPGME 20201201T171253 6257    _gpgme_io_spawn: check: fd[0] = 0x34 -> 0x1
GPGME 20201201T171253 6257    _gpgme_io_spawn: check: waiting for child process pid=25179
GPGME 20201201T171253 6257      _gpgme_io_close: enter: fd=52
GPGME 20201201T171253 6257      _gpgme_io_close: leave: result=0
GPGME 20201201T171253 6257    _gpgme_io_spawn: leave: result=0

So, due to some reasons, running app directly via /Applications/Thunderbird.app fails right at the beginning, unable to launch gpgconf and detect gpg pathes and settings. Then most likely Thunderbird fails to understand this and does something wrong when gpgme returns gpgme_op_decrypt_ext:182: error: Unsupported protocol <GPGME>, causing the crash.

However the main question is why spawn of gpgconf fails? I'll try to debug it more, it could be some sort of permissions problems, piping whatever else.

Maybe Patrick has some ideas about it/experienced something similar with Enigmail/macOS?

Flags: needinfo?(patrick)

Some more information:
During failure gpgconf process exits with WIFSIGNALED(status) and WTERMSIG(status) is 11, i.e. SIGSEGV.

(In reply to Nickolay Olshevsky from comment #5)

Maybe Patrick has some ideas about it/experienced something similar with Enigmail/macOS?

I'm sorry, but I can't help here. Enigmail does not use gpgme, and I'm not using macOS.

Flags: needinfo?(patrick)

Oops, sorry, Patrick, for bugging you. Due to some unknown reasons I believed that Enigmail works via gpgme interface.

I am having the same exact issue. Installed GPGME via homebrew. (Only had GPG Tools before.)

Everything works if Thunderbird is launched via /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin.

When launching /Applications/Thunderbird.app, get the "failure in finishCryptoEncapsulation" error.

By the way, I am going the external GnuPG key route because Thunderbird doesn't yet support subkeys with primary key being offline.

(In reply to Patrick Nagurny from comment #9)

By the way, I am going the external GnuPG key route because Thunderbird doesn't yet support subkeys with primary key being offline.

Hopefully Thunderbird will support offline primary key + subkeys case soon, as we already implemented it in the RNP library.
Anyway, that strange SIGSEGV should be resolved as well, I'll try to invest some more time into investigation later.

I don't know if GPGME from homebrew is compatible with GPGTools.

You could try to use a single build that contains both component, which would then be known to be compatible with each other.

For example from here:
https://sourceforge.net/projects/gpgosx/files/

(Make sure to download the correct platform, don't use arm64 unless you're sure that's what you need.)

In my case (and I assume in Nickolay's case as well), I have both gnupg and gpgme installed via Homebrew. (At least both appear when I call brew list and the path of which gpg also seems to be right, namely /usr/local/bin/gpg.) For my Yubikey, I also have pinentry-mac from GPGTools installed via Homebrew but this doesn't seem to be the problem here.

It also worked for me (when run from Terminal of course) with standard pinentry-curses, so no GPGTools was involved.
Theoretically it could be something wrong with terminal allocation when run as a GUI application or so.

I'm scared when I read pinentry-curses. You have to configure gpg-agent such that a graphical version of pinentry is used. Neither Thunderbird nor gpgme can open a console window to use with pinentry.

(In reply to Patrick Brunschwig from comment #14)

I'm scared when I read pinentry-curses. You have to configure gpg-agent such that a graphical version of pinentry is used. Neither Thunderbird nor gpgme can open a console window to use with pinentry.

Yeah, it worked only when Thunderbird was run via the terminal. I meant that it's not a problem of GPGTools/pinentry-mac but something different.

Hello, I would like to confirm that I am hitting exactly the same issue: macOS 10.15.7, gpg, gpgme and pinentry-mac installed from Homebrew. When I run thunderbird binary manually everything works, but when I open Thunderbird.app folder, it crashes whenever it touches the gpgme library.

I can confirm this using macOS 10.15.7, dependencies installed via Homebrew. Crashing with this GPGME 20210119T115631 32B7 gpgme_op_decrypt_ext:182: error: Unsupported protocol <GPGME> error mentioned above.

Kai, could you please comment on quote from the discussion at https://dev.gnupg.org/T5250 :

Reading the bugzilla report it seems that TB is loading gpgme at runtime. In particular the hints on using externally build stuff (Homebrew) is worrying. Someone(tm) needs to check how gpgme is used by TB and that it is properly initialized. GPGME is actually not designed to be loaded at runtime but should be used as standard shared object or static library.

Flags: needinfo?(kaie)

Thunderbird only loads GPGME if it's on the user's system, it's not something we ship (nor would we ship it). I don't know much about linking, but I would say that rules out static linking?

Duplicate of this bug: 1684481

Reading the bugzilla report it seems that TB is loading gpgme at runtime. In particular the hints on using externally build stuff (Homebrew) is worrying. Someone(tm) needs to check how gpgme is used by TB and that it is properly initialized. GPGME is actually not designed to be loaded at runtime but should be used as standard shared object or static library.

I wasn't aware of this. The architecture of Thunderbird's implementation requires dynamic loading of the GPGME library.

At the time we load the library we call gpgme_check_version. The documentation sounds like it is the function that triggers the initialization that the module requires:
https://gnupg.org/documentation/manuals/gpgme/Library-Version-Check.html

If there are any other init steps we should perform, we can easily do that, prior to using the library.

Flags: needinfo?(kaie)

Thanks again for pointing me to the above gnupg ticket. I've commented upstream.

From what I understand, it seems that certain combinations of GPGME and GnuPG are incompatible.

It may be necessary to more clearly document our requirements for using the optional GPGME/GnuPG configuration, ensure you have a GUI-enabled version of pinentry installed, and ensure that the installed GPGME and GnuPG software uses compatible versions.

Not sure what changed (maybe some build settings?), but since of today's update to Thunderbird 78.8.1 issue is gone, and both decryption and signing works with external Yubikey via gpgme. I didn't install GnuPG for OSX and use once installed via the homebrew, with addition of pinentry-mac.

See Also: → 1681060

(Citing Nickolay Olshevsky from comment #24)

Not sure what changed (maybe some build settings?), but since of today's update to Thunderbird 78.8.1 issue is gone, and both decryption and signing works with external Yubikey via gpgme. I didn't install GnuPG for OSX and use once installed via the homebrew, with addition of pinentry-mac.

Can confirm that the bug seems to be fixed in 78.8.1. I have GnuPG for OSX instead of the Homebrew version and it also works flawlessly.

Version 78.8.1 is the one that upgraded RNP to version v0.14.0 - so maybe there was a hidden memory issue that is fixed in newer RNP?

Version 78.8.1 fixed the problem for me only the first time after the update – probably because the "Restart Thunderbird" functionality launches Thunderbird as documented in the workaround. If I start Thunderbird 78.8.1 by double-clicking the icon, I still get a "thunderbird quit unexpectedly." dialog without affecting the rest of Thunderbird when viewing encrypted messages.

Version 78.8.1 is the one that upgraded RNP to version v0.14.0 - so maybe there was a hidden memory issue that is fixed in newer RNP?

I do not recall anything like this during last months.

If I start Thunderbird 78.8.1 by double-clicking the icon, I still get a "thunderbird quit unexpectedly." dialog without affecting the rest of Thunderbird when viewing encrypted messages.

Confirmed, the same behaviour :-(

Can we avoid using GPGME, and instead call the GPG command-line tool ourselves, the way Enigmail did? That would avoid this problem entirely.

advantages of using GPGME

Can we avoid using GPGME, and instead call the GPG command-line tool ourselves, the way Enigmail did? That would avoid this problem entirely.

Calling "gpg" directly comes with its own set of problems and this why using GPGME is recommended
by the GnuPG people (e.g. see https://wiki.gnupg.org/APIs).

Most parts of the command line interface of GnuPG is designed for interactive use and while there is large effort made to keep it stable, it is less stable then using GPGME which encapsulates calling the binaries. Sooner or later you run into the same problems that your code has to solve anew and maintain, which have been solved in GPGME already.

And upstream is interested to weed out GPGME defects.
(I am part of the GnuPG development community.)

Back to the defect: Is it still there for everybody?

(First it seems to be gone, as I've commented on https://dev.gnupg.org/T5250 but reading more, there still seems to be defects, depending on how Thunderbird is started, and in some reports on the existance of a gui pinentry?)

The defect is gone for me. Running TB 78.12.0 on macOS 11.5.1.

(In reply to ondrej from comment #31)

The defect is gone for me. Running TB 78.12.0 on macOS 11.5.1.

Did you restart Thunderbird and run it in the common way? For me defect is still there with TB 78.12.0/macOS 10.15.7

(In reply to Nickolay Olshevsky from comment #32)

(In reply to ondrej from comment #31)

The defect is gone for me. Running TB 78.12.0 on macOS 11.5.1.

Did you restart Thunderbird and run it in the common way? For me defect is still there with TB 78.12.0/macOS 10.15.7

Yes, I start Thunderbird by clicking on the icon in the dock and it works for me. I use the default gpgme: stable 1.16.0 (bottled) from Homebrew.

Updated gpgme to 1.16.0, but still no luck. Maybe related to the macOS version or to the Yubikey which I use.

(In reply to Nickolay Olshevsky from comment #34)

Updated gpgme to 1.16.0, but still no luck. Maybe related to the macOS version or to the Yubikey which I use.

Is the defect still a crash and independent of the way you start Thunderbird?
So it happens always when you try to view an
(I presume that you have pinentry-mac installed, because it worked before.)

What you could try is some sanity checks on GnuPG and with another keypair there to outrule the Yubikey influcence.
(Both should not be an issue, so it is unlikely, but because we don't know what is triggering the defect, I suggest we check some stuff anyway.)

So:

  • Does GnuPG work on the command line with your yubikey as it should (listing secret-key(s), encrypting, decrypting, getting a gui pinentry up?)
    (Assuming that you are familiar how to do this on the command line, otherwise let us know.)
  • If you create a new keypair with GnuPG on the command line, does this work with Thunderbird? For this I recommend to set the GNUPGHOME variable early before starting anything to a different directory where you can have a separate setup for gpg. I don't know when MacOS starts things, on GNU/Linux you could do it in a shell like export GNUPGHOME=/home/bern/tmp/dot.gnupg, create the directory then try with 'gpg --verbose --list-secret-keys' that the directory exists. If all commands that start gpg, gpg-agent, dirmngr, gpg-agent have that environment variable set, they'll use that new configuration directory. So you can create a new keypair there and see if this changes the behaviour.

(In reply to bernhard from comment #35)

Is the defect still a crash and independent of the way you start Thunderbird?

It only crashes if I start Thunderbird from the GUI (i.e. double clicking on icon). Basically, it doesn't crash and continue to work, just macOS's crash window is displayed.
If I run it from the Terminal, it works fine with Yubikey, and macOS pinentry (actually, it worked with terminal pinentry as well).

So it happens always when you try to view an

Yeah, it happens when I try to view an encrypted message, didn't try to sign recently.

What you could try is some sanity checks on GnuPG and with another keypair there to outrule the Yubikey influcence.
(Both should not be an issue, so it is unlikely, but because we don't know what is triggering the defect, I suggest we check some stuff anyway.)

So:

  • Does GnuPG work on the command line with your yubikey as it should (listing secret-key(s), encrypting, decrypting, getting a gui pinentry up?)
    (Assuming that you are familiar how to do this on the command line, otherwise let us know.)

Sure, things work fine.

  • If you create a new keypair with GnuPG on the command line, does this work with Thunderbird?

I don't think the issue is with keypair, as crash is reported somewhere between running gpgconf from the gpgme (looks like as the same I reported at https://dev.gnupg.org/T5250 )

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       EXC_I386_GPFLT
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [73386]

Application Specific Information:
crashed on child side of fork pre-exec

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_malloc.dylib        	0x00007fff72559e41 nanov2_forked_calloc + 7
1   libsystem_malloc.dylib        	0x00007fff72544f59 malloc_zone_calloc + 99
2   libsystem_malloc.dylib        	0x00007fff72544ed9 calloc + 24
3   libobjc.A.dylib               	0x00007fff711d9603 allocateBuckets(unsigned int) + 29
4   libobjc.A.dylib               	0x00007fff711d9096 cache_fill + 283
5   libobjc.A.dylib               	0x00007fff711d8b27 lookUpImpOrForward + 530
6   libobjc.A.dylib               	0x00007fff711d8399 _objc_msgSend_uncached + 73
7   libsystem_asl.dylib           	0x00007fff723cca9a _asl_mt_shim_fork_child + 33
8   libSystem.B.dylib             	0x00007fff6f372aae libSystem_atfork_child + 49
9   libsystem_c.dylib             	0x00007fff723ec8ad fork + 40
10  libgpgme.11.dylib             	0x00000001338d3c5b _gpgme_io_spawn + 356
11  libgpgme.11.dylib             	0x00000001338d5781 read_gpgconf_dirs + 208
12  libgpgme.11.dylib             	0x00000001338d5099 get_gpgconf_item + 308
13  libgpgme.11.dylib             	0x00000001338c310c gpgme_get_engine_info + 99
14  libgpgme.11.dylib             	0x00000001338c3512 _gpgme_engine_info_copy + 365
15  libgpgme.11.dylib             	0x00000001338d69b7 gpgme_new + 388
16  XUL                           	0x000000011973d06c ffi_call_unix64 + 76
17  XUL                           	0x000000011973c84f ffi_call + 895
18  XUL                           	0x0000000118e3d7f6 0x114ded000 + 67438582

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x00007fff72559e3a  rbx: 0x0000000000000004  rcx: 0x00007fff711f7140  rdx: 0x0000000000000001
  rdi: 0x7974696361706143  rsi: 0x0000000000000040  rbp: 0x00007ffee13fc380  rsp: 0x00007ffee13fc358
   r8: 0x0000000000000003   r9: 0x00007ffee13fc3f8  r10: 0x0000000100000000  r11: 0x00007ffee13fc3f0
  r12: 0x00007fff98a98000  r13: 0x00007fff98aa56e8  r14: 0x0000000000000001  r15: 0x0000000000000040
  rip: 0x00007fff72559e41  rfl: 0x0000000000010246  cr2: 0x000000010e8801e8
  
Logical CPU:     6
Error Code:      0x00000000
Trap Number:     13

I also have this issue, Thunderbird not crashing but cannot use private key in GnuPG.

Launching Thunderbird via /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin will have everything working but not directly with /Applications/Thunderbird.app.

Only with macOS, Windows and Linux have no issue. Possibly only Apple Silicon Macs since one of my friend using an Intel Mac didn't have the issue, but I cannot confirm since I don't have one.

Full log when trying to compose a signed email:

Unexpected event profile-after-change URLQueryStrippingListService.jsm:224
Uncaught (in promise) undefined
Unknown Collection "thunderbird/query-stripping" RemoteSettingsClient.jsm:160
Successfully loaded OpenPGP library librnp.dylib version 0.15.2+git20210806.dd923a4e.MZLA from /Applications/Thunderbird.app/Contents/MacOS/librnp.dylib RNPLib.jsm:92:15
Found 3 public keys and 0 secret keys (0 protected, 0 unprotected) RNPLib.jsm:288:15
Successfully loaded optional OpenPGP library libgpgme.dylib from additional standard locations GPGMELib.jsm:69:13
gpgme version: 1.16.0 GPGMELib.jsm:241:15
Trying to load /Applications/Thunderbird.app/Contents/MacOS/libotr.dylib OTRLib.jsm:64:11
Trying to load libotr.dylib from system's standard library locations OTRLib.jsm:64:11
Trying to load libotr.5.dylib from system's standard library locations OTRLib.jsm:64:11
Trying to load libotr.dylib from system's standard library locations OTRLib.jsm:64:11
Error: Cannot load required OTR library
    loadExternalOTRLib resource:///modules/OTRLib.jsm:109
    init resource:///modules/OTRLib.jsm:115
    once resource:///modules/OTR.jsm:117
    init resource:///modules/OTR.jsm:138
    init resource:///modules/OTRUI.jsm:265
OTR.jsm:126:15
[Exception... "Favicon at "https://start.thunderbird.net/favicon.ico" failed to load: Not Found."  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource:///modules/FaviconLoader.jsm :: onStopRequest :: line 253"  data: no] FaviconLoader.jsm:253:22
    onStopRequest resource:///modules/FaviconLoader.jsm:253
in getEncryptionFlags, gSendEncrypted=false, gSendSigned=true enigmailMsgComposeOverlay.js:1607:13
Prompter: internal dialogs not available in this context. Falling back to window prompt. Prompter.jsm:1084
getCryptParams parameters: from=<key_id>, to=<email_addr>, bcc=, hash=SHA256, flags=37057, ascii=0, errorObj= 
Object { value: "" }
 , logObj= 
Object {  }
encryption.jsm:73:13
getCryptParams, got: to=<email_addr>, bcc= encryption.jsm:113:13
getCryptParams returning: encryption.jsm:190:13
Object { sender: "<key_id>", sign: true, signatureHash: "SHA256", sigTypeClear: false, sigTypeDetached: true, encrypt: false, encryptToSender: false, armor: true, senderKeyIsExternal: true, to: (1) […], … }
encryption.jsm:191:13
sendFlags=000090c1 encryption.jsm:426:13
Error: failure in finishCryptoEncapsulation, exitCode: -1
    finishCryptoEncapsulation chrome://openpgp/content/modules/mimeEncrypt.jsm:580
    createMessageFile resource:///modules/MimeMessage.jsm:86
mimeEncrypt.jsm:597:15
mailnews.send: 
Exception { name: "NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS", message: "[JavaScript Error: \"failure in finishCryptoEncapsulation, exitCode: -1\" {file: \"chrome://openpgp/content/modules/mimeEncrypt.jsm\" line: 580}]'[JavaScript Error: \"failure in finishCryptoEncapsulation, exitCode: -1\" {file: \"chrome://openpgp/content/modules/mimeEncrypt.jsm\" line: 580}]' when calling method: [nsIMsgComposeSecure::finishCryptoEncapsulation]", result: 2153185313, filename: "resource:///modules/MimeMessage.jsm", lineNumber: 86, columnNumber: 0, data: XPCWrappedNative_NoHelper, stack: "createMessageFile@resource:///modules/MimeMessage.jsm:86:27\n", location: XPCWrappedNative_NoHelper }
MessageSend.jsm:122:27
mimeEncrypt.js: caught exception: Error
Message: 'failure in finishCryptoEncapsulation, exitCode: -1'
File:    chrome://openpgp/content/modules/mimeEncrypt.jsm
Line:    580
Stack:   finishCryptoEncapsulation@chrome://openpgp/content/modules/mimeEncrypt.jsm:580:15
createMessageFile@resource:///modules/MimeMessage.jsm:86:27


Error: failure in finishCryptoEncapsulation, exitCode: -1 mimeEncrypt.jsm:580:15
mailnews.send: Sending failed; , exitCode=2153185313, originalMsgURI= MessageSend.jsm:321:27
Prompter: internal dialogs not available in this context. Falling back to window prompt. Prompter.jsm:1084
Prompter: internal dialogs not available in this context. Falling back to window prompt. Prompter.jsm:1084
NS_ERROR_NOT_AVAILABLE: 2 ActivityManager.jsm:129

This crash also happens with Thunderbird 91?
And a Thunderbird crash isn't generated which gives a crash ID in Help > More troubleshooting info ?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(ondrej)
Flags: needinfo?(me)
Keywords: crash
Blocks: 1681060
See Also: 1681060
Duplicate of this bug: 1681060

(In reply to Wayne Mery (:wsmwk) from comment #38)

This crash also happens with Thunderbird 91?
And a Thunderbird crash isn't generated which gives a crash ID in Help > More troubleshooting info ?

It is not actually "crashing", just shows "Secret key not available" when trying to decrypt messages.

I still have version 78.10.1 (64-bit) and it says that Thunderbird is up to date in the about dialog. Do you have any idea why I'm not being upgraded? On https://blog.thunderbird.net/2021/08/thunderbird-91-available-now/ it says that existing Thunderbird users will be updated to the newest version in the coming weeks.

(In reply to Kaspar Etter from comment #41)

I still have version 78.10.1 (64-bit) and it says that Thunderbird is up to date in the about dialog.

Thunderbird should be updating you to version 78.14.0. From there you would be updated to version 91, except right now we are blocking updates to 91 for Macs - we need to wait for version 91.3.0 for Macs. (This all assumes you are using a supported version of macOS.)

I found a workaround of this for ARM Macs, it was weird, but do works:

  • Make sure to install gnupg, gpgme and pinentry-mac
  • Open Thunderbird, setup everything and try to open an email encrypted using a secret key available in the GnuPG keychain, it should fail
  • Open Finder and navigate to Thunderbird.app, right click and select "Get Info", check the box "Open using Rosetta"
  • Open Thunderbird, this time you should see an permission window requesting Contacts permission, allow it (I haven't tested if the workaround still works if I disallow the permission)
  • GnuPG should still not function, quit Thunderbird
  • Open Finder and navigate to Thunderbird.app, right click and select "Get Info", deselect "Open using Rosetta"
  • Reopen Thunderbird and GnuPG should work

I have no idea why this would make GnuPG work, but it does. I tested and it works on both of my ARM Macs (including one that was just factory reset).

Kaspar how is version 91 ?

Severity: -- → S4
You need to log in before you can comment on or make changes to this bug.