Closed Bug 1069275 Opened 5 years ago Closed 3 years ago

crash in JS_NewStringCopyZ(JSContext*, char const*) via mime_write_message_body. compose with encrypted attachments?

Categories

(MailNews Core :: MIME, defect, critical)

x86
Windows NT
defect
Not set
critical

Tracking

(thunderbird_esr4551+ fixed, thunderbird51 fixed, thunderbird52 fixed, thunderbird53 fixed)

VERIFIED FIXED
Thunderbird 53.0
Tracking Status
thunderbird_esr45 51+ fixed
thunderbird51 --- fixed
thunderbird52 --- fixed
thunderbird53 --- fixed

People

(Reporter: wsmwk, Assigned: jorgk-bmo)

References

Details

(5 keywords, Whiteboard: [regression:TB31?])

Crash Data

Attachments

(1 file, 3 obsolete files)

#12 crash for TB31.1.1 
and common in TB34.0a1

all start with frame of mime_write_message_body

This bug was filed from the Socorro interface and is 
report bp-5ff6fcdb-afa3-4e00-8b37-9e8b12140916.
=============================================================
0 	mozjs.dll 	JS_NewStringCopyZ(JSContext*, char const*) 	js/src/jsapi.cpp
1 	xul.dll 	XPCConvert::NativeData2JS(JS::MutableHandle<JS::Value>, void const*, nsXPTType const&, nsID const*, tag_nsresult*) 	js/xpconnect/src/XPCConvert.cpp
2 	xul.dll 	nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) 	js/xpconnect/src/XPCWrappedJSClass.cpp
3 	xul.dll 	nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) 	js/xpconnect/src/XPCWrappedJS.cpp
4 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
5 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
6 	xul.dll 	mime_write_message_body(nsIMsgSend*, char const*, unsigned int) 	mailnews/compose/src/nsMsgSend.cpp

bp-b3886295-e04d-443b-be99-835f42140825
Perhps the same crash is TB35.0a2 signature  JS_NewStringCopyZ(JSContext*, char const*) | XPCConvert::NativeData2JS(JS::MutableHandle<JS::Value>, void const*, nsXPTType const&, nsID const*, tag_nsresult*) 
as in https://crash-stats.mozilla.com/report/index/d77090ce-42b3-4e55-b18e-eeda92141129 ... but I didnot compare source line numbers
Crash Signature: [@ JS_NewStringCopyZ(JSContext*, char const*)] → [@ JS_NewStringCopyZ(JSContext*, char const*)] [@ JS_NewStringCopyZ(JSContext*, char const*) | XPCConvert::NativeData2JS(JS::MutableHandle<JS::Value>, void const*, nsXPTType const&, nsID const*, tag_nsresult*) ]
Just ran into this crash, too, and all i did was try to send an e-mail for which I had just turned *off* S/MIME encryption before sending.

https://crash-stats.mozilla.com/report/index/4c863b95-6fa4-4dff-a50d-168292150216
This crash doesn't depend on the message (e-mail) IMHO. I send e-mails to spam reporting server very often and spam messages are sent as mail attachments. Sometimes (let's say for ca 2% sendings) the crash happens. But after Thunderbird restarts the same spam is sent correctly. So it doesn't depend on what is being sent. I also observed the crash while sending the first message after Thunderbird restart. Looks like some undefined variable randomly plays the game here.
Still topcrash in version 31.6.0. All crashes I check have enigmail installed.
cc: Patrick in case he has new ideas

Too bad we don't have more than 7 months of crash data. I can only get back as far as 31.0 - examples: bp-e60e03fa-5017-4083-be67-bd3282141009 bp-d00f2a9a-1fdb-42ee-be72-8ac592141006.  We do however have ludo's bug 990594 reported against 31.0a1 buildid 20140329030204 bp-3660fe06-ce9a-4859-a297-6b19c2140401.
http://hg.mozilla.org/releases/comm-beta/annotate/aaeb4113ff88/mailnews/compose/src/nsMsgSend.cpp#l1225
bugzilla@1692 1219  if (!output)
hg@0 	      1220    return NS_MSG_ERROR_WRITING_FILE;
hg@0 	      1221
hg@0 	      1222  state->GetCryptoclosure(getter_AddRefs(crypto_closure));
hg@0 	      1223  if (crypto_closure)
hg@0 	      1224  {
hg@0 	      1225    return crypto_closure->MimeCryptoWriteBlock (buf, size);

Crash was common in version 34 beta. But in 2015 for all non-release channels we only have these:
bp-d77090ce-42b3-4e55-b18e-eeda92141129 TB35.0a2
bp-4ef2d64e-933c-4c9a-b3ab-2d6902150311 TB36.0b1
bp-b11a01a8-dead-4332-ae06-93e602150330 TB37.0b1 Build ID 20150311003753 

So perhaps it is gone in 38. We await proof via affected users testing version 38. :)
http://hg.mozilla.org/comm-central/filelog/1e8d5c907a77/mailnews/compose/src/nsMsgSend.cpp
Keywords: dataloss
See Also: → 990594
Summary: crash in JS_NewStringCopyZ(JSContext*, char const*) via mime_write_message_body. compose with attachments? → crash in JS_NewStringCopyZ(JSContext*, char const*) via mime_write_message_body. compose with encrypted attachments?
Whiteboard: [regression:TB??] → [regression:TB31?]
bp-31e9bdfa-73d3-4860-9291-115132150318 "GnuPG (via Enigmail) dialog came up to unlock signing key; not sure if related to Enigmail or just the attempt to send (or to nothing at all). "
bp-bceecf91-39b6-438d-af02-de6432150405 " Just entered password for PGP key to sign mail in Enigmail"
There is an important difference here between Thunderbird with and without Enigmail.

Without Enigmail, the method called is this (i.e. C++):
http://mxr.mozilla.org/comm-beta/source/mailnews/extensions/smime/src/nsMsgComposeSecure.cpp#954

With Enigmail installed, the method called is this (i.e. JavaScript):
https://sourceforge.net/p/enigmail/source/ci/master/tree/package/mimeEncrypt.js#l294
Blocks: 990594
See Also: 990594
In version 38.1.0 this appears to be JS_NewStringCopyZ(JSContext*, char const*) | XPCConvert::NativeData2JS(JS::MutableHandle<T>, void const*, nsXPTType const&, nsID const*, nsresult*) 
currently ranged #50

bp-dabf0856-2b14-484e-bf49-d73312150809
 0 	xul.dll	JS_NewStringCopyZ(JSContext*, char const*)	js/src/jsapi.cpp
1 	xul.dll	XPCConvert::NativeData2JS(JS::MutableHandle<JS::Value>, void const*, nsXPTType const&, nsID const*, nsresult*)	js/xpconnect/src/XPCConvert.cpp
2 	xul.dll	nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)	js/xpconnect/src/XPCWrappedJSClass.cpp
3 	xul.dll	nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)	js/xpconnect/src/XPCWrappedJS.cpp
4 	xul.dll	PrepareAndDispatch	xpcom/reflect/xptcall/md/win32/xptcstubs.cpp
5 	xul.dll	SharedStub	xpcom/reflect/xptcall/md/win32/xptcstubs.cpp
6 	xul.dll	mime_write_message_body(nsIMsgSend*, char const*, unsigned int)	c:/builds/moz2_slave/tb-rel-c-esr38-w32_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:1203
7 	xul.dll	nsMsgSendPart::PushBody(char const*, int)	c:/builds/moz2_slave/tb-rel-c-esr38-w32_bld-0000000/build/mailnews/compose/src/nsMsgSendPart.cpp:287
8 	xul.dll	nsMsgSendPart::Write()	c:/builds/moz2_slave/tb-rel-c-esr38-w32_bld-0000000/build/mailnews/compose/src/nsMsgSendPart.cpp:608
9 	xul.dll	nsMsgComposeAndSend::GatherMimeAttachments()	c:/builds/moz2_slave/tb-rel-c-esr38-w32_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:909
10 		@0x1865cfff
Crash Signature: [@ JS_NewStringCopyZ(JSContext*, char const*)] [@ JS_NewStringCopyZ(JSContext*, char const*) | XPCConvert::NativeData2JS(JS::MutableHandle<JS::Value>, void const*, nsXPTType const&, nsID const*, tag_nsresult*) ] → [@ JS_NewStringCopyZ(JSContext*, char const*)] [@ JS_NewStringCopyZ(JSContext*, char const*) | XPCConvert::NativeData2JS(JS::MutableHandle<JS::Value>, void const*, nsXPTType const&, nsID const*, tag_nsresult*) ] [@ JS_NewStringCopyZ(JSContext*, char c…
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Crash Signature: , char const*) | XPCConvert::NativeData2JS(JS::MutableHandle<T>, void const*, nsXPTType const&, nsID const*, nsresult*) ] → , char const*) | XPCConvert::NativeData2JS(JS::MutableHandle<T>, void const*, nsXPTType const&, nsID const*, nsresult*) ] [@ JS_NewStringCopyZ] [@ JS_NewStringCopyZ | XPCConvert::NativeData2JS ]
https://crash-stats.mozilla.com/report/index/3478eca9-daa9-42f9-af35-425a02151229 

Same problem, Enigmail is running. Thunderbird crash when sending the mail !
(In reply to services from comment #9)
> https://crash-stats.mozilla.com/report/index/3478eca9-daa9-42f9-af35-
> 425a02151229 
> 
> Same problem, Enigmail is running. Thunderbird crash when sending the mail !

@services, can you reproduce?
Flags: needinfo?(services)
(In reply to Patrick Brunschwig from comment #6)
> There is an important difference here between Thunderbird with and without
> Enigmail.
> 
> Without Enigmail, the method called is this (i.e. C++):
> http://mxr.mozilla.org/comm-beta/source/mailnews/extensions/smime/src/
> nsMsgComposeSecure.cpp#954

Thanks for the info.  I don't see ScopedCERTCertificat in the stacks of bp-31e9bdfa-73d3-4860-9291-115132150318 and bp-bceecf91-39b6-438d-af02-de6432150405.  

> With Enigmail installed, the method called is this (i.e. JavaScript):
> https://sourceforge.net/p/enigmail/source/ci/master/tree/package/mimeEncrypt.
> js#l294

What should we see in the stack for this case?


Ignoring all the other signatures for the moment...

100% of JS_NewStringCopyZ | XPCConvert::NativeData2JS has enigmail
https://crash-analysis.mozilla.com/crash_analysis/20160306/20160306_Thunderbird_38.6.0-interesting-addons-with-versions.txt
eg bp-166decf1-bd73-49cd-a74f-2e5d92160306
Flags: needinfo?(patrick)
the reporter of bp-166decf1-bd73-49cd-a74f-2e5d92160306 claims it never crashes when using the send button. only happens when using ctrl+enter
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #10)
> (In reply to services from comment #9)
> > https://crash-stats.mozilla.com/report/index/3478eca9-daa9-42f9-af35-
> > 425a02151229 
> > 
> > Same problem, Enigmail is running. Thunderbird crash when sending the mail !
> 
> @services, can you reproduce?

Can't reproduce. It happens sometimes. Doesn't crash when I don't cypher DRAFTS.
Flags: needinfo?(services)
Hum It crashed this morning sorry... The mail had a picture in it...
(In reply to services from comment #13)
> (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment
> #10)
> > (In reply to services from comment #9)
> > > https://crash-stats.mozilla.com/report/index/3478eca9-daa9-42f9-af35-
> > > 425a02151229 
> > > 
> > > Same problem, Enigmail is running. Thunderbird crash when sending the mail !
> > 
> > @services, can you reproduce?
> 
> Can't reproduce. It happens sometimes. Doesn't crash when I don't cypher
> DRAFTS.

Are you saying it only happens if you enable auto-saving of drafts??
Flags: needinfo?(services)
Duplicate of this bug: 1274970
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #15)
> (In reply to services from comment #13)
> > (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment
> > #10)
> > > (In reply to services from comment #9)
> > > > https://crash-stats.mozilla.com/report/index/3478eca9-daa9-42f9-af35-
> > > > 425a02151229 
> > > > 
> > > > Same problem, Enigmail is running. Thunderbird crash when sending the mail !
> > > 
> > > @services, can you reproduce?
> > 
> > Can't reproduce. It happens sometimes. Doesn't crash when I don't cypher
> > DRAFTS.
> 
> Are you saying it only happens if you enable auto-saving of drafts? 


No, after some times the problem occurs even if autosaving draft is enabled.
Duplicate of this bug: 1278475
Today I hit the same crash, first TB crash in 4y :-)

https://crash-stats.mozilla.com/report/index/772f76a4-ee8c-4fad-a15a-b32642160812

It happens after Enigmail prompted me for the password.

This is repeatable for me:

https://crash-stats.mozilla.com/report/index/eed4fbdf-273c-419b-90bf-bd52d2160812


What I did:
1) I have an IMAP account.

2) In that IMAP account I select a message I want to reply to and click the "Reply" button.

3) I write my reply and attach a *.log file per Drag&Drop.

4) I now click the Enigma buttons in the toolbar of the message window to enable encryption (lock) and signing (pen) for that message.

5) Now I press "Save" to make sure my draft is saved (lost my first mail due to that problem). I do not save my drafts encrypted.

6) Now I click the "Send" button.

7) Enigmail is prompts me like:

> Send  PGP/MIME SIGNED ENCRYPTED message to <recipient-address>?
> 
> Note: The message is encrypted for the following User ID's / Keys: 0x123456789

8) After clicking "Send message" Enigmail I am seeing the pinentry window asking me for my passphrase. Thunderbird is displaying "Creating mail" in the background. 

9) After entering my passphrase and HITTING [ENTER] key, Thunderbird crashed.


I am emphasizing that I hit the return key in the passphrase dialog because on my 3rd attempt I just clicked the button in the passphrase dialog and the mail was sent, no crash.
(In reply to Igor from comment #19)
> Today I hit the same crash, first TB crash in 4y :-)
> 
> https://crash-stats.mozilla.com/report/index/772f76a4-ee8c-4fad-a15a-
> b32642160812
> 
> It happens after Enigmail prompted me for the password.
> 
> This is repeatable for me:
> 
> https://crash-stats.mozilla.com/report/index/eed4fbdf-273c-419b-90bf-
> bd52d2160812
> 
> 
> What I did:
> 1) I have an IMAP account.
> 
> 2) In that IMAP account I select a message I want to reply to and click the
> "Reply" button.
> 
> 3) I write my reply and attach a *.log file per Drag&Drop.
> 
> 4) I now click the Enigma buttons in the toolbar of the message window to
> enable encryption (lock) and signing (pen) for that message.
> 
> 5) Now I press "Save" to make sure my draft is saved (lost my first mail due
> to that problem). I do not save my drafts encrypted.
> 
> 6) Now I click the "Send" button.
> 
> 7) Enigmail is prompts me like:
> 
> > Send  PGP/MIME SIGNED ENCRYPTED message to <recipient-address>?
> > 
> > Note: The message is encrypted for the following User ID's / Keys: 0x123456789
> 
> 8) After clicking "Send message" Enigmail I am seeing the pinentry window
> asking me for my passphrase. Thunderbird is displaying "Creating mail" in
> the background. 
> 
> 9) After entering my passphrase and HITTING [ENTER] key, Thunderbird crashed.
> 
> 
> I am emphasizing that I hit the return key in the passphrase dialog because
> on my 3rd attempt I just clicked the button in the passphrase dialog and the
> mail was sent, no crash.

Damn... here TB has already crashed several times since I installed Enigmail.

Do you mean you are able to reproduce it?

I have tried all I could to reproduce it but here it always happens randomly.

I have added R Kent to Cc.

I hope it will now be possible to fix it.
I did not trace through all of the code, but looking at the IDL for the call:

void mimeCryptoWriteBlock(in string aBuf, in long aLen)

and the actual call:

return crypto_closure->MimeCryptoWriteBlock (buf, size);

it looks to me like the call should have been marked [noscript] as defined, because I assume that the buf is not assumed to be null terminated. IIUC, JS will attempt to convert the buf to a string assuming it is null terminated. If no nulls are actually encountered, Bad Things can happen.

If this is the case, one possible fix would be to copy buf into a null terminated string at this point.

One possible fix, if my interpretation is correct,
What are we going to do with this bug? Do people still crash?

Should we make this [noscript] here:
https://dxr.mozilla.org/comm-central/rev/e69ced0974d588e438569c22f71a0fcbf84c2b8e/mailnews/compose/public/nsIMsgComposeSecure.idl#24

Patrick, can you give us an update, please. Also, the links from comment #6 are out-of-date.
(sorry, somehow bugzilla doesn't send me any mails anymore, event though my prefs say that I want mails...)

People don't report crashes to me, and I never experienced crashes either, so I can't really comment on the crash situation.

However, by making mimeCryptoWriteBlock [noscript] you make it impossible for Enigmail to create PGP/MIME messages, thus that's a no-go for me.
Flags: needinfo?(patrick)
Igor, stefan,  does it still reproduce for you?

Crash-stats indicates over 500 Windows users of current releases are affected in the past week.
Flags: needinfo?(stefan.hoelzle)
Flags: needinfo?(services)
Flags: needinfo?(igor.sverkos)
See Also: → 1281553
OK, we need to go with what Kent said in comment #21:
> one possible fix would be to copy buf into a null terminated string at this point.
TB just crashed moments ago when I inserted my key :(

Luckily I had saved the message before I pressed SEND.
I'll submit a patch in the next few days, this situation is really untenable.
Assignee: nobody → jorgk
Status: NEW → ASSIGNED
Attached patch 1069275-enigmail-crash.patch (v1) (obsolete) β€” β€” Splinter Review
I know you don't like crashing the app, but it would crash anyway ;-)
Flags: needinfo?(stefan.hoelzle)
Flags: needinfo?(igor.sverkos)
Attachment #8818958 - Flags: review?(rkent)
Comment on attachment 8818958 [details] [diff] [review]
1069275-enigmail-crash.patch (v1)

Review of attachment 8818958 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/compose/src/nsMsgSend.cpp
@@ +1237,5 @@
>    if (crypto_closure)
>    {
> +    // We know this used to crash in the JS glue if MimeCryptoWriteBlock() was
> +    // implemented in JS. So sadly we need to copy to a new buffer to be able
> +    // to null-terminate.

We could test buf[size] != 0 before copying everything. The is for the message body, so that's a lot to copy.

::: mailnews/extensions/smime/src/nsMsgComposeSecure.cpp
@@ +1201,5 @@
>  {
> +  // Better to crash here in a defined fashion than to crash in the JS glue
> +  // if MimeCryptoWriteBlock() is implemented in JS. So far no crashes are known.
> +  if (buf[size] != 0)
> +    NS_RUNTIMEABORT("Buffer not null-terminated");

Instead of crashing, we could copy here like in nsMsgSend.cpp.

Anyway, the test-rabbits can use the try build and report back ;-)
Attached patch version 2 (using nsCString) (obsolete) β€” β€” Splinter Review
I really prefer to use strings over malloc and free. I believe that you can create a standard string from a non-null terminated buffer, like this. If you agree with this approach, use this code and give my r+ with your assign.
Attachment #8819736 - Flags: review?(jorgk)
Thanks for looking at this.

Yes, your version is nice but you haven't answered my questions. I checked the call sites of MimeCryptoWriteBlock() and found two where null-termination is not guaranteed. Only one reports a crash. So my/your patch does this:

Null-terminated at the faulty call-site and NS_RUNTIMEABORT at the other. I understand that you don't like aborts.

I'd like to know how you assess the alternative:
At both call sites check for null-termination first, if already null-terminated, do nothing, otherwise, copy the string.

What do you think?
Flags: needinfo?(rkent)
I took your patch as the minimum that we need to do, and we could do that if you want with my suggested changes.

But I suppose you are asking me what we should really do.

The goal is that nsIMsgComposeSecure be scriptable, which means that the current description of mimeCryptoWriteBlock (which allows non-terminated strings) is incorrect and should be fixed. So I would use a different, renamed method (like mimeCryptoWriteString) without the length parameter, and change all internal uses to use that. Enigmail will need to make the minor change to rename and change the number of passed parameter. Internal uses can use the string classes as I suggested.
Flags: needinfo?(rkent)
Somehow we're not coming together here ;-(

I've thought about introducing a new method, but we'd still need to copy a potentially long message body to call it, so apart from being nicer, that doesn't buy us any better performance.

My question was this: How about changing your proposal to

  if (crypto_closure)
  {
    // Already null-terminated?
    if (buf[size] == 0)
      return crypto_closure->MimeCryptoWriteBlock (buf, size);

    // We know this used to crash in the JS glue if MimeCryptoWriteBlock() was
    // implemented in JS. So sadly we need to copy to a new buffer to be able
    // to null-terminate.
    nsCString bufWithNull;
    bufWithNull.Assign(buf, size);
    return crypto_closure->MimeCryptoWriteBlock(bufWithNull.get(), size);
  }

And the question is also whether to treat the other call site the same instead of using NS_RUNTIMEABORT.
Flags: needinfo?(rkent)
Duplicate of this bug: 1324762
This is what I meant in comment #36.

Now, strictly speaking I shouldn't access buf[size] if 'buf' is only allocated with size 'size'. We'd be extremely unlucky for this to cause a crash.

Since you didn't complain about the
+  if (buf[size] != 0)
+    NS_RUNTIMEABORT("Buffer not null-terminated");
I guess you share my view.
Attachment #8818958 - Attachment is obsolete: true
Attachment #8818958 - Flags: review?(rkent)
Comment on attachment 8820418 [details] [diff] [review]
1069275-enigmail-crash.patch (v3),  using nsCString and with test for null byte

OK, we are close.

I just want two things, and I apologize if I am being inconsistent.

First, I don't see the value of all of this:

+    // Check for null-termination, if not found, copy to new string so JS glue
+    // doesn't crash when MimeCryptoWriteBlock() is implemented in JS.
+    if (buf[size] == 0)
+      return crypto_closure->MimeCryptoWriteBlock (buf, size);

We have no reason to believe that buf is null terminated, so I would expect this would do nothing the vast majority of the time, and in doing the check you introduce the buf[size] risk that you mentioned. Just always null-terminate. This code is mostly used in Enigmail anyway, so it does not cause a performance hit in more typical operation.

Second, at least file a bug to fix MimeCryptoWriteBlock to remove the unneeded size attribute, or mark it as unscripted and replace with a scriptable version.
Flags: needinfo?(rkent)
Attachment #8820418 - Flags: review?(rkent) → review-
Hmm, so I removed the buf[size] test from *your* version 2 and we now null-terminate in both call sites.

I'll file a bug for the follow-up work.
Attachment #8820859 - Flags: review?(rkent)
Attachment #8819736 - Attachment is obsolete: true
Attachment #8819736 - Flags: review?(jorgk)
Attachment #8820859 - Flags: review?(rkent) → review+
Comment on attachment 8820859 [details] [diff] [review]
1069275-enigmail-crash.patch (v4), using nsCString

[Approval Request Comment]
Regression caused by (bug #): Seems to always have been wrong.
User impact if declined: TB crashes when sending and using Enigmail.
Testing completed (on c-c, etc.): To be honest, we didn't test it at all.
Risk to taking this patch (and alternatives if risky):
Low, simple change to create and pass a null-terminated string.
Attachment #8820859 - Flags: approval-comm-esr45?
Attachment #8820859 - Flags: approval-comm-beta+
Attachment #8820859 - Flags: approval-comm-aurora+
Further comfirmation, 52.0a2 had 1-2 crashes per week, but the last 52.0a2 crash is bp-1d808abe-d00f-40b4-b8b0-d3b802161214 20161212004003 
Definitely worthy of uplift.
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #46)
> Definitely worthy of uplift ...
... to TB 45.x. It's already in the 5x.y series ;-)
Comment on attachment 8820859 [details] [diff] [review]
1069275-enigmail-crash.patch (v4), using nsCString

https://hg.mozilla.org/releases/comm-esr45/rev/1fcfc79ad515
Attachment #8820859 - Flags: approval-comm-esr45? → approval-comm-esr45+
gone in v45.7.0 and 51 beta
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.