Update to NSS 3.19.1

RESOLVED FIXED in Firefox 39, Firefox OS v2.0

Status

()

Core
Security: PSM
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: mt, Assigned: RyanVM)

Tracking

({sec-other})

unspecified
mozilla41
sec-other
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox38 wontfix, firefox38.0.5 wontfix, firefox39+ fixed, firefox40+ fixed, firefox41+ fixed, firefox-esr3139+ fixed, firefox-esr3839+ fixed, b2g-v2.0 fixed, b2g-v2.0M fixed, b2g-v2.1 fixed, b2g-v2.1S fixed, b2g-v2.2 fixed, b2g-master fixed)

Details

(Whiteboard: [adv-main39-][adv-esr38.1-][adv-esr31.8-] fixes sec-high security bugs [b2g-adv-main2.2-]])

Attachments

(5 attachments)

(Reporter)

Description

3 years ago
Marking this private, since bug1138554 is under embargo for another day.
(Assignee)

Comment 1

3 years ago
This is going to have to land basically everywhere given the deps. Not sure we we'd do a 38.x chemspill, though.
status-b2g-v2.0: --- → affected
status-b2g-v2.0M: --- → affected
status-b2g-v2.1: --- → affected
status-b2g-v2.1S: --- → affected
status-b2g-v2.2: --- → affected
status-b2g-master: --- → affected
status-firefox38: --- → affected
status-firefox38.0.5: --- → affected
status-firefox39: --- → affected
status-firefox40: --- → affected
status-firefox41: --- → affected
status-firefox-esr31: --- → affected
status-firefox-esr38: --- → affected
tracking-firefox-esr31: --- → ?
tracking-firefox-esr38: --- → ?
(Reporter)

Comment 2

3 years ago
Yep, agreed on the chemspill.  I'd wait for the next release opportunity.  It's bad, but not that bad.
(Assignee)

Updated

3 years ago
status-firefox38: affected → wontfix
status-firefox38.0.5: affected → wontfix
Keywords: sec-other
Whiteboard: fixes sec-high security bugs
I have a slight worry about ESR-31: does this update to NSS remove support for features that will break websites, whether that's roots, ciphers, protocols?
tracking-firefox39: --- → +
tracking-firefox40: --- → +
tracking-firefox41: --- → +
tracking-firefox-esr31: ? → 39+
tracking-firefox-esr38: ? → 39+
(Reporter)

Comment 4

3 years ago
Of the changes since 3.16 that apply to Firefox and HTTPS, here are the ones to watch:

Bug 753136 makes NSS stricter in its handling of badly formed TLS extensions.  In the time that this has been in Firefox (it landed in 3.17) we've only seen improvements in connection rates.

Bug 1086145 makes NSS less tolerant of illegal handshake ordering.

Bug 1138554 makes NSS refuse to accept small DH shares (this naturally has a compatibility impact, but it's in the order of 0.2%, see the bug).

Of these, the only one with compatibility issues is the last one and we need that to happen, it's $50 for server impersonation otherwise.  Other than that, I think I'd be safe in saying that the biggest source of connection failures is the changes we've made in PSM, not NSS.
Group: core-security
(Reporter)

Comment 5

3 years ago
Tag NSS_3_19_1_BETA1 added.  RyanVM, this should be OK for everything short of ESR31.  I will make the changes necessary tomorrow (we need to revert some root CA changes for that).
Flags: needinfo?(ryanvm)
(Assignee)

Comment 6

3 years ago
I can run some Try pushes off BETA1, but we can't ship anything other than RTM versions to the release channels.
Flags: needinfo?(ryanvm)
(Assignee)

Comment 7

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/38ff380719e4

Note: This doesn't bump the configure.in version number check yet. That'll need to wait until the final release.
Keywords: leave-open
(Assignee)

Comment 8

3 years ago
Backed out for test_WebCrypto_DH.html failures.
https://treeherder.mozilla.org/logviewer.html#?job_id=10027515&repo=mozilla-inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/e446922ca04d
Created attachment 8608467 [details] [diff] [review]
0001-Bug-1166031-Use-1024-bit-prime-for-WebCrypto-s-DH-te.patch

Use a 1024-bit prime for DH tests.
Attachment #8608467 - Flags: review?(rlb)
Also xpcshell, https://treeherder.mozilla.org/logviewer.html#?job_id=10029113&repo=mozilla-inbound
(In reply to Phil Ringnalda (:philor) from comment #10)
> Also xpcshell,
> https://treeherder.mozilla.org/logviewer.html#?job_id=10029113&repo=mozilla-
> inbound
Flags: needinfo?(dkeeler)
Which required a clobber to get rid of when it persisted past the backout, so it might well require a clobber on landing to not happen - we've seen troubles with the coreconf.dep hack not actually successfully causing an NSS rebuild before.
Created attachment 8608941 [details] [diff] [review]
PSM xpcshell test update

The failing testcase presented a 1008-bit RSA key for verification with the expectation that PSM would terminate the connection in an overridable manner due to the small key size. Now that the minimum RSA key size according to NSS is the same as PSM's current policy, NSS terminates the handshake before PSM can get to it. The error code is different and it isn't overridable. This patch reflects these changes.
Flags: needinfo?(dkeeler)
Attachment #8608941 - Flags: review?(cykesiopka.bmo)

Comment 14

3 years ago
I would consider 768-bit DHE minimum for ESR, given that enterprises are more likely to run Java.
(Reporter)

Comment 15

3 years ago
If this goes to ESR, it's going full strength.  The only consideration we have at the moment is for ESR 31 where we committed to retaining 1024 root CAs.

On a related note, I've asked for expedited review of this: 

  https://addons.mozilla.org/en-US/firefox/addon/disable-dhe/

Comment 16

3 years ago
Comment on attachment 8608941 [details] [diff] [review]
PSM xpcshell test update

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

LGTM.
Attachment #8608941 - Flags: review?(cykesiopka.bmo) → review+
(Reporter)

Comment 17

3 years ago
Comment on attachment 8608467 [details] [diff] [review]
0001-Bug-1166031-Use-1024-bit-prime-for-WebCrypto-s-DH-te.patch

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

This matches up.  Do you have a try run to show us all that it fixed the problem?
Attachment #8608467 - Flags: review?(rlb) → review+
(In reply to Martin Thomson [:mt] from comment #17)
> This matches up.  Do you have a try run to show us all that it fixed the
> problem?

I'm quite confident they don't fail, the only thing they could do is time out on slow Android debug runs. You didn't ask David for a try push but I guess it doesn't hurt to include his patch too:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=cfceb71f03a1
(Reporter)

Comment 19

3 years ago
Thanks Tim (I didn't r+ David's patch).
Keywords: checkin-needed
(Reporter)

Comment 20

3 years ago
This needs checkin for m-c; let's wait until Monday for Aurora, and Thursday for Beta (as agreed with :lizzard).

RyanVM, do you think that you can handle the landing?
Flags: needinfo?(ryanvm)
(Assignee)

Comment 21

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/5b0d7c8c9cda
https://hg.mozilla.org/integration/mozilla-inbound/rev/c2c83077fe1c
https://hg.mozilla.org/integration/mozilla-inbound/rev/5039f49a256b

Friendly reminder that we'll need an RTM tagging before anything beyond Aurora can be updated.
Assignee: nobody → ryanvm
Flags: needinfo?(ryanvm)
Keywords: checkin-needed
(Reporter)

Comment 22

3 years ago
Reminder acknowledged.  RTM will be tagged next Thursday all going well.

I'm treating the 31 changes with less urgency, since I'm told that we won't need that for a few more weeks.  I need to consult with :kaie about what is needed.
(Assignee)

Updated

3 years ago
Depends on: 1125025
https://hg.mozilla.org/mozilla-central/rev/5b0d7c8c9cda
https://hg.mozilla.org/mozilla-central/rev/c2c83077fe1c
https://hg.mozilla.org/mozilla-central/rev/5039f49a256b
(Assignee)

Comment 24

3 years ago
Created attachment 8609924 [details]
Update NSS to version 3.19.1

Approval Request Comment
[Feature/regressing bug #]: N/A
[User impact if declined]: Security issues noted in the blocking bugs.
[Describe test coverage new/current, TreeHerder]: In-tree NSS test coverage, nightly coverage for a couple days.
[Risks and why]: Martin can correct me, but the risk seems fairly low. Bug 1138554 references some intranet sites potentially having issues.
[String/UUID change made/needed]: N/A
Attachment #8609924 - Flags: approval-mozilla-aurora?
Attachment #8609924 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 25

3 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/3fc58c44e86b
https://hg.mozilla.org/releases/mozilla-aurora/rev/9da10de1195c
https://hg.mozilla.org/releases/mozilla-aurora/rev/3df9581c43e5
status-firefox40: affected → fixed
Flags: in-testsuite+
Blocks: 1166515
(Assignee)

Updated

3 years ago
Blocks: 1146026
(Assignee)

Comment 26

3 years ago
Comment on attachment 8609924 [details]
Update NSS to version 3.19.1

NSS_3_19_1_RTM has been tagged. Let's get this on the other release branches. Note that a modified version of 3.19.1 is being created for ESR31 uplift that backs out 1024bit CA cert changes that affect compat.
Attachment #8609924 - Flags: approval-mozilla-esr38?
Attachment #8609924 - Flags: approval-mozilla-esr31?
Attachment #8609924 - Flags: approval-mozilla-beta?
(Assignee)

Updated

3 years ago
Flags: needinfo?(lhenry)
Keywords: leave-open
(Assignee)

Updated

3 years ago
No longer blocks: 1146026, 1166515
Depends on: 1166515, 1146026
Summary: Update to NSS 3.19.1 (when ready) → Update to NSS 3.19.1
(Assignee)

Comment 27

3 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/a7ddb5c68c1c

Comment 28

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/3990e393c4f6
(Assignee)

Comment 29

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/3990e393c4f6
Comment on attachment 8609924 [details]
Update NSS to version 3.19.1

Approved for uplift to beta, esr31 and esr38 based on discussion with Ryan and Martin.
Flags: needinfo?(lhenry)
Attachment #8609924 - Flags: approval-mozilla-esr38?
Attachment #8609924 - Flags: approval-mozilla-esr38+
Attachment #8609924 - Flags: approval-mozilla-esr31?
Attachment #8609924 - Flags: approval-mozilla-esr31+
Attachment #8609924 - Flags: approval-mozilla-beta?
Attachment #8609924 - Flags: approval-mozilla-beta+
(Assignee)

Comment 31

3 years ago
https://hg.mozilla.org/releases/mozilla-beta/rev/a74ce2833a96
https://hg.mozilla.org/releases/mozilla-beta/rev/b239d4243b6b
https://hg.mozilla.org/releases/mozilla-beta/rev/dc9c305024f4
status-firefox39: affected → fixed

Comment 32

3 years ago
I think enterprises should be allowed some time to upgrade the old Java JSSE stacks.

Comment 33

3 years ago
Please use this tag for Firefox ESR 31.x :
  NSS_3_19_1_WITH_CKBI_1_98_RTM
(Assignee)

Comment 34

3 years ago
(In reply to Kai Engert (:kaie) from comment #33)
> Please use this tag for Firefox ESR 31.x :
>   NSS_3_19_1_WITH_CKBI_1_98_RTM

How should I handle the version number in configure.in?

Comment 35

3 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #34)
> (In reply to Kai Engert (:kaie) from comment #33)
> > Please use this tag for Firefox ESR 31.x :
> >   NSS_3_19_1_WITH_CKBI_1_98_RTM
> 
> How should I handle the version number in configure.in?

Using 3.19.1 is fine.
Both tags identify themselves as version 3.19.1

Comment 36

3 years ago
(In reply to Kai Engert (:kaie) from comment #35)
> Using 3.19.1 is fine.
> Both tags identify themselves as version 3.19.1

Those distributors who are willing to pick up the root CA changes can use the regular 3.19.1 release.

Mozilla will use the special release.

All distributors that want the old root CA certificates can distribute the special 3.19.1 release will old root CA set.
(Reporter)

Comment 37

3 years ago
(In reply to Yuhong Bao from comment #32)
> I think enterprises should be allowed some time to upgrade the old Java JSSE
> stacks.

How old?  JSSE 6 supports 1024-bit DH.  Enterprises have already had plenty of time there.  http://www.oracle.com/technetwork/java/eol-135779.html

NSS_3_19_1_WITH_CKBI_1_98_RTM is a one-off for Firefox ESR 31.  Affected enterprises can remain on Firefox 31, but know that support for that ends relatively soon.

Comment 38

3 years ago
JSSE client != JSSE server.
(In reply to Yuhong Bao from comment #38)

IE also banned the short DHE key without any backward compatible options.
I don't understand why do you insist ancient JSSE version while trying to drop WinXP SP2 support. Please be consistent at least.

Comment 40

3 years ago
Enterprises don't typically run XP SP2, and Java 7 is not nearly as "ancient".
Java 7 supports 1024-bit DHE keys, no? Please cite a reference if not.
(Assignee)

Comment 42

3 years ago
My ESR31 Try push is seeing test_CSP_evalscript_getCRMFRequest.html failures:
https://treeherder.mozilla.org/logviewer.html#?job_id=7999693&repo=try

dkeeler says I'm OK to just disable the test as this is expected PSM behavior now (and the test itself was removed back in the Gecko 34 days).

https://hg.mozilla.org/releases/mozilla-esr31/rev/eba99d1ad886
https://hg.mozilla.org/releases/mozilla-esr31/rev/9cddd14f9c22
status-firefox-esr31: affected → fixed

Comment 43

3 years ago
(In reply to Masatoshi Kimura [:emk] from comment #41)
> Java 7 supports 1024-bit DHE keys, no? Please cite a reference if not.

On the client side. On the server side it still used 768-bit DHE. I filed an IcedTea bug on this: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2250
(Reporter)

Comment 44

3 years ago
While I'm a little sad about making older Java unreachable, I think that filing bug reports with Java implementations is the right answer.  DHE at 768-bits is far too weak.

Comment 45

3 years ago
And my point is that I doubt one month is enough time to upgrade.
(Assignee)

Comment 46

3 years ago
https://hg.mozilla.org/releases/mozilla-esr38/rev/b68c2aa2ba17
https://hg.mozilla.org/releases/mozilla-esr38/rev/e4122cc66111
https://hg.mozilla.org/releases/mozilla-esr38/rev/104927365946
status-firefox-esr38: affected → fixed
(Assignee)

Comment 47

3 years ago
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a84adb412f87
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/239793ea749a
status-b2g-v2.0: affected → fixed
(Assignee)

Updated

3 years ago
status-b2g-master: affected → fixed
(Assignee)

Comment 48

3 years ago
Unfortunately, the Try pushes for b2g34/b2g37 are having some xpcshell issues. Both are failing in test_cert_overrides.js with the following error:
17:53:39 INFO - found pre-defined host 'inadequate-key-size-ee.example.com'
17:53:39 INFO - found pre-defined host 'inadequate-key-size-ee.example.com'
17:53:39 INFO - TEST-INFO | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/head_psm.js | "handling inadequate-key-size-ee.example.com"
17:53:39 INFO - TEST-PASS | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/head_psm.js | [add_connection_test/</< : 315] 2153394044 == 2153394044
17:53:39 INFO - PR_Recv failed: SSL_ERROR_INSUFFICIENT_SECURITY_ALERT
17:53:39 WARNING - TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_cert_overrides.js | [object XPCWrappedNative_NoHelper] == null - See following stack:
17:53:39 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_cert_overrides.js:add_non_overridable_test/<:45
17:53:39 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/head_psm.js:add_connection_test/</<:317
17:53:39 INFO - resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:Handler.prototype.process:865
17:53:39 INFO - resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:this.PromiseWalker.walkerLoop:744
17:53:39 INFO - /builds/slave/test/build/tests/xpcshell/head.js:_do_main:191
17:53:39 INFO - /builds/slave/test/build/tests/xpcshell/head.js:_execute_test:405
17:53:39 INFO - -e:null:1
17:53:39 INFO - null:null:0

Additionally, b2g34 is also failing in test_keysize.js with:
17:55:03 INFO - TEST-INFO | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js | "cert cn=dsa-eeOK-intOK-caOK"
17:55:03 INFO - TEST-INFO | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js | "cert issuer cn=dsa-intOK-caOK"
17:55:03 WARNING - TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js | -16382 == 0 - See following stack:
17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js:check_cert_err_generic:31
17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js:check_cert_err:35
17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js:check_ok:39
17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js:check_for_key_type:60
17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js:run_test:77
17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/head.js:_execute_test:403
17:55:03 INFO - -e:null:1
17:55:03 INFO - null:null:0

Full log link:
https://treeherder.mozilla.org/logviewer.html#?job_id=8004661&repo=try
Flags: needinfo?(dkeeler)
(Assignee)

Comment 49

3 years ago
https://hg.mozilla.org/mozilla-central/rev/3990e393c4f6
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox41: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Created attachment 8613120 [details] [diff] [review]
test_keysize update

For the test_keysize.js failures, it looks like openssl was generating DSA keys that NSS considers to be 1023 bits, not 1024. I upped the size and regenerated the affected keys. Note that I didn't investigate the further question of if openssl is doing the right thing or if NSS is doing the right thing. The reason this isn't failing in more recent branches is that we removed support for these certificates from firefox entirely.
Flags: needinfo?(dkeeler)
Attachment #8613120 - Flags: review?(cykesiopka.bmo)
Created attachment 8613126 [details] [diff] [review]
test_cert_overrides update

Thus far PSM has relied on a convention where if certificate verification results in a non-overridable error, no ssl status object will be set on the transport security info object representing the connection. It turns out, if both NSS and PSM encounter an error, this assumption can be violated. Some of our tests rely on this assumption, which is why test_cert_overrides.js broke. I don't think there's an easy fix. This just modifies the relevant test to verify what we can verify, which is that the appropriate error is recorded. Note that while this is a bad state to be in, it isn't a security disaster because if NSS encounters an error, it will not let the connection continue, no matter what PSM says.
Attachment #8613126 - Flags: review?(cykesiopka.bmo)
(Reporter)

Comment 52

3 years ago
(In reply to David Keeler [:keeler] (use needinfo?) from comment #50)
> For the test_keysize.js failures, it looks like openssl was generating DSA
> keys that NSS considers to be 1023 bits, not 1024. 

That's odd.  We only reject DSA values at 1022 or less (DSA_MIN_P_BITS is 1023).
I should have been more specific: before 38, mozilla::pkix would use NSS to determine a key's strength in bits. As of 3.19.1, SECKEY_PublicKeyStrengthInBits appears to return 1023 for the keys in the test. mozilla::pkix's limit is 1024, so they were rejected.

Comment 54

3 years ago
Comment on attachment 8613120 [details] [diff] [review]
test_keysize update

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

DSA, please stop haunting us.

Anyways, LGTM. Try push would be nice, but I assume RyanVM will take care of that.
Attachment #8613120 - Flags: review?(cykesiopka.bmo) → review+

Comment 55

3 years ago
Comment on attachment 8613126 [details] [diff] [review]
test_cert_overrides update

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

Interesting, thanks for the explanation.

Anyways, LGTM.
Attachment #8613126 - Flags: review?(cykesiopka.bmo) → review+
(Assignee)

Comment 56

3 years ago
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/1ad8a7e8dcfb
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/76bd11cf59e9
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/fbf1127b1313
status-b2g-v2.2: affected → fixed
(Assignee)

Comment 57

3 years ago
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/685bd8d49ce3
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/f22235875dc0
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/94d943fadb06
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/eb6e7d9d336a
status-b2g-v2.1: affected → fixed
Depends on: 1170833
(Assignee)

Comment 58

3 years ago
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/685bd8d49ce3
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/f22235875dc0
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/94d943fadb06
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/eb6e7d9d336a

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/a84adb412f87
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/239793ea749a
status-b2g-v2.0M: affected → fixed
status-b2g-v2.1S: affected → fixed

Updated

3 years ago
Depends on: 1171502
Depends on: 1171713

Comment 59

3 years ago
Also see: https://bugs.openjdk.java.net/browse/JDK-6956398 
Notice the backports to 7u85 and 6u101. We should at least make sure that these are released before trying to disable 768-bit DHE.
(Reporter)

Updated

3 years ago
See Also: → bug 1176097
(Reporter)

Updated

3 years ago
See Also: → bug 1176101
Whiteboard: fixes sec-high security bugs → [adv-main39-][adv-esr38.1-][adv-esr31.8-] fixes sec-high security bugs

Updated

3 years ago
Blocks: 1172917
Whiteboard: [adv-main39-][adv-esr38.1-][adv-esr31.8-] fixes sec-high security bugs → [adv-main39-][adv-esr38.1-][adv-esr31.8-] fixes sec-high security bugs [b2g-adv-main2.2-]]
You need to log in before you can comment on or make changes to this bug.