searching for reviewer(jcj)
7894fbb7c881f828e2cdf0af1e6541030c8a579d: Bug 1468222 - Initial updates to consolidate nsISSLStatus into nsITransportSecurityInfo. r?keeler,jcj draft
Dipen Patel <bugzilla@pansara.org> - Tue, 03 Jul 2018 23:28:23 -0700 - rev 813935
Push 115050 by bmo:bugzilla@pansara.org at Wed, 04 Jul 2018 06:30:32 +0000
Bug 1468222 - Initial updates to consolidate nsISSLStatus into nsITransportSecurityInfo. r?keeler,jcj MozReview-Commit-ID: C2C4IzNojtm
8ebf45b0854ace6848090c02d6c4935bc515fe0a: Bug 1468349 - Web Authentication - Add FreeBSD Support r=jcj
Greg V <greg@unrelenting.technology> - Tue, 12 Jun 2018 09:55:30 -0700 - rev 807632
Push 113180 by plingurar@mozilla.com at Fri, 15 Jun 2018 10:38:54 +0000
Bug 1468349 - Web Authentication - Add FreeBSD Support r=jcj Summary: Upstream PR: https://github.com/jcjones/u2f-hid-rs/pull/62 * Extract hidproto module from linux::hidraw Make the protocol parts independent of Linux code, in preparation for adding FreeBSD support. * Add FreeBSD (uhid + devd) support Tested with a YubiKey 4. Tags: #secure-revision Bug #: 1468349 Differential Revision: https://phabricator.services.mozilla.com/D1636 MozReview-Commit-ID: 8NNWRgTEMn2
edf774f0a993a18b59b5f8aa10e0977d94ea1de8: Bug 1468349 - Web Authentication - Add FreeBSD Support r=jcj draft
Greg V <greg@unrelenting.technology> - Tue, 12 Jun 2018 09:55:30 -0700 - rev 807432
Push 113106 by bmo:jjones@mozilla.com at Thu, 14 Jun 2018 16:42:17 +0000
Bug 1468349 - Web Authentication - Add FreeBSD Support r=jcj Summary: Upstream PR: https://github.com/jcjones/u2f-hid-rs/pull/62 * Extract hidproto module from linux::hidraw Make the protocol parts independent of Linux code, in preparation for adding FreeBSD support. * Add FreeBSD (uhid + devd) support Tested with a YubiKey 4. Tags: #secure-revision Bug #: 1468349 Differential Revision: https://phabricator.services.mozilla.com/D1636 MozReview-Commit-ID: 8NNWRgTEMn2
39f22b0351c2893b26cb7c04dcc879a093bfa78a: Bug 1468349 - Web Authentication - Add FreeBSD Support r=jcj draft
Greg V <greg@unrelenting.technology> - Tue, 12 Jun 2018 09:55:30 -0700 - rev 806902
Push 112984 by bmo:jjones@mozilla.com at Tue, 12 Jun 2018 18:23:49 +0000
Bug 1468349 - Web Authentication - Add FreeBSD Support r=jcj Summary: Upstream PR: https://github.com/jcjones/u2f-hid-rs/pull/62 * Extract hidproto module from linux::hidraw Make the protocol parts independent of Linux code, in preparation for adding FreeBSD support. * Add FreeBSD (uhid + devd) support Tested with a YubiKey 4. Tags: #secure-revision Bug #: 1468349 Differential Revision: https://phabricator.services.mozilla.com/D1636 MozReview-Commit-ID: 8NNWRgTEMn2
6d1d30406c8eecb46560dc3351d656552e58025d: Bug 1463936 - Set default security.pki.name_matching_mode to enforce (3) for all builds. r=jcj
Dipen Patel <bugzilla@pansara.org> - Mon, 11 Jun 2018 14:52:07 -0700 - rev 806872
Push 112976 by bmo:emilio@crisal.io at Tue, 12 Jun 2018 14:03:09 +0000
Bug 1463936 - Set default security.pki.name_matching_mode to enforce (3) for all builds. r=jcj MozReview-Commit-ID: CK3zoKfGfEr
883d21782f2b41fe7e7f152354dce96e6cca07db: Bug 1463936 - Set default security.pki.name_matching_mode to enforce (3) for all builds. r?jcj draft
Dipen Patel <bugzilla@pansara.org> - Mon, 11 Jun 2018 14:52:07 -0700 - rev 806781
Push 112954 by bmo:bugzilla@pansara.org at Mon, 11 Jun 2018 21:53:35 +0000
Bug 1463936 - Set default security.pki.name_matching_mode to enforce (3) for all builds. r?jcj MozReview-Commit-ID: CK3zoKfGfEr
ffd4b055fb8b33a0ac35c5526d8523e1659c8168: bug 1439383 - clean up the load loadable roots thread when we're done with it r=froydnj,jcj
David Keeler <dkeeler@mozilla.com> - Thu, 07 Jun 2018 15:11:49 -0700 - rev 806394
Push 112878 by rwood@mozilla.com at Sat, 09 Jun 2018 14:26:04 +0000
bug 1439383 - clean up the load loadable roots thread when we're done with it r=froydnj,jcj MozReview-Commit-ID: J5GnpwxYguz
dce03ac771f8789dd916511ce55c99c562646e54: bug 1439383 - clean up the load loadable roots thread when we're done with it r?froydnj,jcj draft
David Keeler <dkeeler@mozilla.com> - Thu, 07 Jun 2018 15:11:49 -0700 - rev 805491
Push 112683 by bmo:dkeeler@mozilla.com at Thu, 07 Jun 2018 22:12:36 +0000
bug 1439383 - clean up the load loadable roots thread when we're done with it r?froydnj,jcj MozReview-Commit-ID: J5GnpwxYguz
e942111bb1493cb7cd839f2d18cd505dd98832a6: bug 1461803 - minor cleanup in PSM: (re)move nsNSSErrors to NSSErrorsService r=jcj
David Keeler <dkeeler@mozilla.com> - Fri, 01 Jun 2018 16:23:17 -0700 - rev 804621
Push 112418 by bdanforth@mozilla.com at Wed, 06 Jun 2018 10:27:46 +0000
bug 1461803 - minor cleanup in PSM: (re)move nsNSSErrors to NSSErrorsService r=jcj Also removes displayUnknownCertErrorAlert, which was declared but never used. Also removes some unnecessary ns(I)CertOverrideService OID stuff. MozReview-Commit-ID: 4o7c1TkKeKJ
7f6ad245006f56a55d3e9cd364696e62eb9c4b45: bug 1466942 - avoid l10n string bundles in nsNSSComponent initialization r?jcj draft
David Keeler <dkeeler@mozilla.com> - Mon, 04 Jun 2018 17:07:06 -0700 - rev 804360
Push 112358 by bmo:dkeeler@mozilla.com at Tue, 05 Jun 2018 20:59:09 +0000
bug 1466942 - avoid l10n string bundles in nsNSSComponent initialization r?jcj Before this patch, nsNSSComponent initialization would call PK11_ConfigurePKCS11 with some localized strings, which contributed to startup time. Also, PK11_UnconfigurePKCS11 was never called, so the memory allocated to these strings would stick around forever. This patch addresses both of these problems by not calling PK11_ConfigurePKCS11. This means that some properties of NSS' internal "PKCS#11 slots/tokens" have to be localized when displaying them to the user. MozReview-Commit-ID: BbAgbgpFfFG
051ef1eb3d23f2030aa74b8df856942896741a46: bug 1465976 - remove all find*ByName APIs from PSM PKCS#11 module/slot/token interfaces r=fkiefer,jcj
David Keeler <dkeeler@mozilla.com> - Thu, 31 May 2018 14:46:06 -0700 - rev 804108
Push 112312 by bmo:standard8@mozilla.com at Tue, 05 Jun 2018 16:07:56 +0000
bug 1465976 - remove all find*ByName APIs from PSM PKCS#11 module/slot/token interfaces r=fkiefer,jcj Before this patch, we exposed a few interfaces that revolved around mapping a name to a specific PKCS#11 module, slot, or token. These APIs were all either problematic and/or unnecessary. In theory there could be two tokens in different modules with the same name, so nsIPK11TokenDB.findTokenByName wasn't guaranteed to return what the consumer expected it to. In general, these APIs were used by front-end code to go from a handle on the specific object in question to a string identifier and then back to a handle on the object. This was unnecessary - we can just retain the original handle. MozReview-Commit-ID: IbqLbV4wceA
741918e1528ec6bff350149173fcc36c345f2a26: bug 1461803 - minor cleanup in PSM: (re)move nsNSSErrors to NSSErrorsService r?jcj draft
David Keeler <dkeeler@mozilla.com> - Fri, 01 Jun 2018 16:23:17 -0700 - rev 803860
Push 112217 by bmo:dkeeler@mozilla.com at Mon, 04 Jun 2018 22:40:56 +0000
bug 1461803 - minor cleanup in PSM: (re)move nsNSSErrors to NSSErrorsService r?jcj Also removes displayUnknownCertErrorAlert, which was declared but never used. Also removes some unnecessary ns(I)CertOverrideService OID stuff. MozReview-Commit-ID: 4o7c1TkKeKJ
b4c7d1e7d2654221cf1d39a159bc4dc8ee7b3d10: bug 1465976 - remove all find*ByName APIs from PSM PKCS#11 module/slot/token interfaces r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Thu, 31 May 2018 14:46:06 -0700 - rev 803760
Push 112171 by bmo:dkeeler@mozilla.com at Mon, 04 Jun 2018 19:39:55 +0000
bug 1465976 - remove all find*ByName APIs from PSM PKCS#11 module/slot/token interfaces r?jcj,fkiefer Before this patch, we exposed a few interfaces that revolved around mapping a name to a specific PKCS#11 module, slot, or token. These APIs were all either problematic and/or unnecessary. In theory there could be two tokens in different modules with the same name, so nsIPK11TokenDB.findTokenByName wasn't guaranteed to return what the consumer expected it to. In general, these APIs were used by front-end code to go from a handle on the specific object in question to a string identifier and then back to a handle on the object. This was unnecessary - we can just retain the original handle. MozReview-Commit-ID: IbqLbV4wceA
0c8c4ba579c721a4b9cbd5a6eff0b219a2d16ff9: bug 1465976 - remove all find*ByName APIs from PSM PKCS#11 module/slot/token interfaces r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Thu, 31 May 2018 14:46:06 -0700 - rev 802497
Push 111894 by bmo:dkeeler@mozilla.com at Thu, 31 May 2018 21:53:53 +0000
bug 1465976 - remove all find*ByName APIs from PSM PKCS#11 module/slot/token interfaces r?jcj,fkiefer Before this patch, we exposed a few interfaces that revolved around mapping a name to a specific PKCS#11 module, slot, or token. These APIs were all either problematic and/or unnecessary. In theory there could be two tokens in different modules with the same name, so nsIPK11TokenDB.findTokenByName wasn't guaranteed to return what the consumer expected it to. In general, these APIs were used by front-end code to go from a handle on the specific object in question to a string identifier and then back to a handle on the object. This was unnecessary - we can just retain the original handle. MozReview-Commit-ID: IbqLbV4wceA
23e8076766f49098f02ae239d391568c71ed3363: bug 1465976 - remove all find*ByName APIs from PSM PKCS#11 module/slot/token interfaces r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Thu, 31 May 2018 14:46:06 -0700 - rev 802496
Push 111893 by bmo:dkeeler@mozilla.com at Thu, 31 May 2018 21:46:23 +0000
bug 1465976 - remove all find*ByName APIs from PSM PKCS#11 module/slot/token interfaces r?jcj,fkiefer Before this patch, we exposed a few interfaces that revolved around mapping a name to a specific PKCS#11 module, slot, or token. These APIs were all either problematic and/or unnecessary. In theory there could be two tokens in different modules with the same name, so nsIPK11TokenDB.findTokenByName wasn't guaranteed to return what the consumer expected it to. In general, these APIs were used by front-end code to go from a handle on the specific object in question to a string identifier and then back to a handle on the object. This was unnecessary - we can just retain the original handle. MozReview-Commit-ID: IbqLbV4wceA
f515f7469139fe27234141ae71f98da1711ab019: Bug 1460301 - Web Authentication - Don't use U2F_PING to initialize tokens. r=jcj, a=jcristau
Tim Taubert <ttaubert@mozilla.com> - Mon, 14 May 2018 17:37:47 +0200 - rev 802229
Push 111850 by bmo:tom@mozilla.com at Thu, 31 May 2018 16:41:37 +0000
Bug 1460301 - Web Authentication - Don't use U2F_PING to initialize tokens. r=jcj, a=jcristau Reviewers: jcj Reviewed By: jcj Bug #: 1460301 Differential Revision: https://phabricator.services.mozilla.com/D1270
f7ba2965406d08645df693bfe3ce8b798a512915: Bug 1427248 - Avoid changing certificate trust in nsNSSComponent initialization. r=fkiefer, r=jcj, a=jcristau
David Keeler <dkeeler@mozilla.com> - Tue, 15 May 2018 13:37:42 -0700 - rev 802195
Push 111850 by bmo:tom@mozilla.com at Thu, 31 May 2018 16:41:37 +0000
Bug 1427248 - Avoid changing certificate trust in nsNSSComponent initialization. r=fkiefer, r=jcj, a=jcristau If a user has set a master password on their NSS DB(s), when we try to change the trust of a certificate, we may have to authenticate to the DB. This involves bringing up a dialog box, executing javascript, spinning the event loop, etc. In some cases (particularly when antivirus software has injected code into Firefox), this can cause the nsNSSComponent to be initialized if it hasn't already been. So, it's a really, really bad idea to attempt to change the trust of a certificate while we're initializing nsNSSComponent, because this results in a recursive component dependency and everything breaks. To get around this, if we need to load 3rd party roots (e.g. enterprise roots or the family safety root), we defer any trust changes to a later event loop tick. In theory this could cause verification failures early in startup. We'll have to see if this is an issue in practice. MozReview-Commit-ID: FvjHP5dTmpP
f9132bdb0177c55fe6ebad201f3f3d6368cf15e8: bug 1464520 - hard-code the builtin roots module name to avoid a dependency on l10n in nsNSSComponent r=fkiefer,jcj
David Keeler <dkeeler@mozilla.com> - Fri, 25 May 2018 11:22:48 -0700 - rev 802047
Push 111814 by jodvarko@mozilla.com at Thu, 31 May 2018 10:42:52 +0000
bug 1464520 - hard-code the builtin roots module name to avoid a dependency on l10n in nsNSSComponent r=fkiefer,jcj nsNSSComponent startup and shutdown would be simpler if there were no direct dependencies on localized strings. This patch removes a dependency on the localized name of the builtin roots module by hard-coding the name internally and then mapping it to/from the localized version as appropriate. MozReview-Commit-ID: 30kbpWFYbzm
bcdac263d98f058513827f545c90ed63460ba57f: bug 1465258 - remove load group workaround in new OCSP code r=jcj
David Keeler <dkeeler@mozilla.com> - Tue, 29 May 2018 16:03:37 -0700 - rev 801914
Push 111768 by mak77@bonardo.net at Wed, 30 May 2018 23:05:31 +0000
bug 1465258 - remove load group workaround in new OCSP code r=jcj The patch for bug 1456489 included a workaround for the issue that origin attributes weren't honored on channels that didn't have a load group set (bug 1456742). Now that that's fixed, we don't need the workaround. MozReview-Commit-ID: I4ExIqt6dYo
7a8d360f8c818f8c762f68b795b151db629295a8: Bug 1464015 - Web Authentication - Rework IPC layer for future Android/Windows support r=jcj
Tim Taubert <ttaubert@mozilla.com> - Wed, 30 May 2018 16:06:09 +0200 - rev 801698
Push 111714 by paul@paul.cx at Wed, 30 May 2018 16:44:23 +0000
Bug 1464015 - Web Authentication - Rework IPC layer for future Android/Windows support r=jcj Reviewers: jcj Reviewed By: jcj Subscribers: mgoodwin Bug #: 1464015 Differential Revision: https://phabricator.services.mozilla.com/D1378
042c15e1f58ec8314ef7808752386c1028ab2420: bug 1464520 - hard-code the builtin roots module name to avoid a dependency on l10n in nsNSSComponent r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Fri, 25 May 2018 11:22:48 -0700 - rev 801279
Push 111624 by bmo:dkeeler@mozilla.com at Wed, 30 May 2018 00:11:29 +0000
bug 1464520 - hard-code the builtin roots module name to avoid a dependency on l10n in nsNSSComponent r?jcj,fkiefer nsNSSComponent startup and shutdown would be simpler if there were no direct dependencies on localized strings. This patch removes a dependency on the localized name of the builtin roots module by hard-coding the name internally and then mapping it to/from the localized version as appropriate. MozReview-Commit-ID: 30kbpWFYbzm
96bed6a4e83980865c4656a0206535ef03adb77b: bug 1465258 - remove load group workaround in new OCSP code r?jcj draft
David Keeler <dkeeler@mozilla.com> - Tue, 29 May 2018 16:03:37 -0700 - rev 801268
Push 111618 by bmo:dkeeler@mozilla.com at Tue, 29 May 2018 23:25:11 +0000
bug 1465258 - remove load group workaround in new OCSP code r?jcj The patch for bug 1456489 included a workaround for the issue that origin attributes weren't honored on channels that didn't have a load group set (bug 1456742). Now that that's fixed, we don't need the workaround. MozReview-Commit-ID: I4ExIqt6dYo
2a6f87c1d80e7a7fb26c1880381c504439ae224d: bug 1464520 - hard-code the builtin roots module name to avoid a dependency on l10n in nsNSSComponent r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Fri, 25 May 2018 11:22:48 -0700 - rev 801122
Push 111579 by bmo:dkeeler@mozilla.com at Tue, 29 May 2018 19:20:51 +0000
bug 1464520 - hard-code the builtin roots module name to avoid a dependency on l10n in nsNSSComponent r?jcj,fkiefer nsNSSComponent startup and shutdown would be simpler if there were no direct dependencies on localized strings. This patch removes a dependency on the localized name of the builtin roots module by hard-coding the name internally and then mapping it to/from the localized version as appropriate. MozReview-Commit-ID: 30kbpWFYbzm
45e4ca4916fa14b070a48a7e7145ec4f0390bc74: bug 1464520 - hard-code the builtin roots module name to avoid a dependency on l10n in nsNSSComponent r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Fri, 25 May 2018 11:22:48 -0700 - rev 801121
Push 111578 by bmo:dkeeler@mozilla.com at Tue, 29 May 2018 19:16:40 +0000
bug 1464520 - hard-code the builtin roots module name to avoid a dependency on l10n in nsNSSComponent r?jcj,fkiefer nsNSSComponent startup and shutdown would be simpler if there were no direct dependencies on localized strings. This patch removes a dependency on the localized name of the builtin roots module by hard-coding the name internally and then mapping it to/from the localized version as appropriate. MozReview-Commit-ID: 30kbpWFYbzm
857472522f42fa9ff55ac070d47383cdcb4b904d: bug 1464520 - hard-code the builtin roots module name to avoid a dependency on l10n in nsNSSComponent r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Fri, 25 May 2018 11:22:48 -0700 - rev 800090
Push 111269 by bmo:dkeeler@mozilla.com at Fri, 25 May 2018 21:12:22 +0000
bug 1464520 - hard-code the builtin roots module name to avoid a dependency on l10n in nsNSSComponent r?jcj,fkiefer nsNSSComponent startup and shutdown would be simpler if there were no direct dependencies on localized strings. This patch removes a dependency on the localized name of the builtin roots module by hard-coding the name internally and then mapping it to/from the localized version as appropriate. MozReview-Commit-ID: 30kbpWFYbzm
c33bba8634df638270b753a16ed85e73ad5fe27f: bug 1463901 - re-arrange some nsNSSComponent initialization/shutdown operations to avoid hanging r=jcj
David Keeler <dkeeler@mozilla.com> - Wed, 23 May 2018 15:39:38 -0700 - rev 799776
Push 111162 by bmo:dave.hunt@gmail.com at Fri, 25 May 2018 10:27:34 +0000
bug 1463901 - re-arrange some nsNSSComponent initialization/shutdown operations to avoid hanging r=jcj Before this patch, if nsNSSComponent initialization failed after allocating the XPCOM object for the component but before dispatching the load loadable roots task, BlockUntilLoadableRootsLoaded would block indefinitely in ShutdownNSS (called from ~nsNSSComponent). This patch re-arranges some things so that nsNSSComponent cleanup won't block on the load loadable roots task if it never fired. It also splits the cleanup into idempotent operations and operations that can only be run once. Unfortunately if nsNSSComponent initialization fails, Firefox is likely to exit or fail promptly anyway (since it is essential to so many other components). However, quitting outright is probably a better experience than hanging indefinitely. MozReview-Commit-ID: RWmBUV2pEU
016d137fd5b81a93d0d94c5918882ddcf824675b: bug 1463901 - re-arrange some nsNSSComponent initialization/shutdown operations to avoid hanging r?jcj draft
David Keeler <dkeeler@mozilla.com> - Wed, 23 May 2018 15:39:38 -0700 - rev 799546
Push 111099 by bmo:dkeeler@mozilla.com at Thu, 24 May 2018 21:56:22 +0000
bug 1463901 - re-arrange some nsNSSComponent initialization/shutdown operations to avoid hanging r?jcj Before this patch, if nsNSSComponent initialization failed after allocating the XPCOM object for the component but before dispatching the load loadable roots task, BlockUntilLoadableRootsLoaded would block indefinitely in ShutdownNSS (called from ~nsNSSComponent). This patch re-arranges some things so that nsNSSComponent cleanup won't block on the load loadable roots task if it never fired. It also splits the cleanup into idempotent operations and operations that can only be run once. Unfortunately if nsNSSComponent initialization fails, Firefox is likely to exit or fail promptly anyway (since it is essential to so many other components). However, quitting outright is probably a better experience than hanging indefinitely. MozReview-Commit-ID: RWmBUV2pEU
eecc2154838fe3b3e57f6e20fa87d0e8f51b258f: bug 1463901 - re-arrange some nsNSSComponent initialization/shutdown operations to avoid hanging r?jcj draft
David Keeler <dkeeler@mozilla.com> - Wed, 23 May 2018 15:39:38 -0700 - rev 799480
Push 111078 by bmo:dkeeler@mozilla.com at Thu, 24 May 2018 19:41:05 +0000
bug 1463901 - re-arrange some nsNSSComponent initialization/shutdown operations to avoid hanging r?jcj Before this patch, if nsNSSComponent initialization failed after allocating the XPCOM object for the component but before dispatching the load loadable roots task, BlockUntilLoadableRootsLoaded would block indefinitely in ShutdownNSS (called from ~nsNSSComponent). This patch re-arranges some things so that nsNSSComponent cleanup won't block on the load loadable roots task if it never fired. It also splits the cleanup into idempotent operations and operations that can only be run once. Unfortunately if nsNSSComponent initialization fails, Firefox is likely to exit or fail promptly anyway (since it is essential to so many other components). However, quitting outright is probably a better experience than hanging indefinitely. MozReview-Commit-ID: RWmBUV2pEU
d289cf8ab61c45a2326c4457afba5b2e3be1d433: bug 1463901 - re-arrange some nsNSSComponent initialization/shutdown operations to avoid hanging r?jcj draft
David Keeler <dkeeler@mozilla.com> - Wed, 23 May 2018 15:39:38 -0700 - rev 799456
Push 111062 by bmo:dkeeler@mozilla.com at Thu, 24 May 2018 18:09:19 +0000
bug 1463901 - re-arrange some nsNSSComponent initialization/shutdown operations to avoid hanging r?jcj Before this patch, if nsNSSComponent initialization failed after allocating the XPCOM object for the component but before dispatching the load loadable roots task, BlockUntilLoadableRootsLoaded would block indefinitely in ShutdownNSS (called from ~nsNSSComponent). This patch re-arranges some things so that nsNSSComponent cleanup won't block on the load loadable roots task if it never fired. It also splits the cleanup into idempotent operations and operations that can only be run once. Unfortunately if nsNSSComponent initialization fails, Firefox is likely to exit or fail promptly anyway (since it is essential to so many other components). However, quitting outright is probably a better experience than hanging indefinitely. MozReview-Commit-ID: RWmBUV2pEU
db3a97478cbfd90dbba53dc8c6026b5b14707454: bug 1461037 - lossily convert invalid UTF8 in certificates for display purposes r=jcj
David Keeler <dkeeler@mozilla.com> - Tue, 15 May 2018 16:41:46 -0700 - rev 799235
Push 110983 by plingurar@mozilla.com at Thu, 24 May 2018 11:05:18 +0000
bug 1461037 - lossily convert invalid UTF8 in certificates for display purposes r=jcj In debug builds, we assert if any UTF8-to-UTF16 conversion fails. If we have invalid UTF8 in a certificate, we don't want to assert. So, we now lossily convert invalid UTF8 in certificates for any display purposes. This also handles fields that are supposed to be ASCII in a similar way. MozReview-Commit-ID: 6TdVPDTmNlh
1e306d54edcb7bc891c57993f1dd76333c01b582: bug 1463901 - re-arrange some nsNSSComponent initialization/shutdown operations to avoid hanging r?jcj draft
David Keeler <dkeeler@mozilla.com> - Wed, 23 May 2018 15:39:38 -0700 - rev 799004
Push 110924 by bmo:dkeeler@mozilla.com at Wed, 23 May 2018 22:39:54 +0000
bug 1463901 - re-arrange some nsNSSComponent initialization/shutdown operations to avoid hanging r?jcj Before this patch, if nsNSSComponent initialization failed after allocating the XPCOM object for the component but before dispatching the load loadable roots task, BlockUntilLoadableRootsLoaded would block indefinitely in ShutdownNSS (called from ~nsNSSComponent). This patch re-arranges some things so that nsNSSComponent cleanup won't block on the load loadable roots task if it never fired. It also splits the cleanup into idempotent operations and operations that can only be run once. Unfortunately if nsNSSComponent initialization fails, Firefox is likely to exit or fail promptly anyway (since it is essential to so many other components). However, quitting outright is probably a better experience than hanging indefinitely. MozReview-Commit-ID: RWmBUV2pEU
6be79f22efde0a0d9be1f58c6a87891d379bf5d6: bug 1461037 - lossily convert invalid UTF8 in certificates for display purposes r?jcj draft
David Keeler <dkeeler@mozilla.com> - Tue, 15 May 2018 16:41:46 -0700 - rev 798882
Push 110870 by bmo:dkeeler@mozilla.com at Wed, 23 May 2018 17:18:33 +0000
bug 1461037 - lossily convert invalid UTF8 in certificates for display purposes r?jcj In debug builds, we assert if any UTF8-to-UTF16 conversion fails. If we have invalid UTF8 in a certificate, we don't want to assert. So, we now lossily convert invalid UTF8 in certificates for any display purposes. This also handles fields that are supposed to be ASCII in a similar way. MozReview-Commit-ID: 6TdVPDTmNlh
94eea0e9febabb7cdae914c483e5f46c95950d70: bug 1461037 - lossily convert invalid UTF8 in certificates for display purposes r?jcj draft
David Keeler <dkeeler@mozilla.com> - Tue, 15 May 2018 16:41:46 -0700 - rev 798510
Push 110770 by bmo:dkeeler@mozilla.com at Tue, 22 May 2018 23:12:28 +0000
bug 1461037 - lossily convert invalid UTF8 in certificates for display purposes r?jcj In debug builds, we assert if any UTF8-to-UTF16 conversion fails. If we have invalid UTF8 in a certificate, we don't want to assert. So, we now lossily convert invalid UTF8 in certificates for any display purposes. This also handles fields that are supposed to be ASCII in a similar way. MozReview-Commit-ID: 6TdVPDTmNlh
dd12c80cff71af9c113d5919577169538d2bc873: Bug 1460301 - Web Authentication - Don't use U2F_PING to initialize tokens. r=jcj, a=RyanVM
Tim Taubert <ttaubert@mozilla.com> - Mon, 14 May 2018 17:37:47 +0200 - rev 797179
Push 110422 by bmo:khudson@mozilla.com at Fri, 18 May 2018 18:23:40 +0000
Bug 1460301 - Web Authentication - Don't use U2F_PING to initialize tokens. r=jcj, a=RyanVM Reviewers: jcj Reviewed By: jcj Bug #: 1460301 Differential Revision: https://phabricator.services.mozilla.com/D1270
7c3cfe766b3771262df0256b2bbcd240fa09fe3a: Bug 1427248 - Avoid changing certificate trust in nsNSSComponent initialization. r=fkiefer, r=jcj, a=RyanVM
David Keeler <dkeeler@mozilla.com> - Mon, 07 May 2018 17:05:30 -0700 - rev 797171
Push 110422 by bmo:khudson@mozilla.com at Fri, 18 May 2018 18:23:40 +0000
Bug 1427248 - Avoid changing certificate trust in nsNSSComponent initialization. r=fkiefer, r=jcj, a=RyanVM If a user has set a master password on their NSS DB(s), when we try to change the trust of a certificate, we may have to authenticate to the DB. This involves bringing up a dialog box, executing javascript, spinning the event loop, etc. In some cases (particularly when antivirus software has injected code into Firefox), this can cause the nsNSSComponent to be initialized if it hasn't already been. So, it's a really, really bad idea to attempt to change the trust of a certificate while we're initializing nsNSSComponent, because this results in a recursive component dependency and everything breaks. To get around this, if we need to load 3rd party roots (e.g. enterprise roots or the family safety root), we defer any trust changes to a later event loop tick. In theory this could cause verification failures early in startup. We'll have to see if this is an issue in practice. MozReview-Commit-ID: FvjHP5dTmpP
47f7391d2bb0cdfea0cd05c91ed30a2fc067f6ee: Bug 1458720 - Make RunOnAllContentParents runnable from any thread. r=Ehsan, r=jcj, a=RyanVM
David Keeler <dkeeler@mozilla.com> - Wed, 02 May 2018 16:42:51 -0700 - rev 797134
Push 110422 by bmo:khudson@mozilla.com at Fri, 18 May 2018 18:23:40 +0000
Bug 1458720 - Make RunOnAllContentParents runnable from any thread. r=Ehsan, r=jcj, a=RyanVM In bug 1215723 RunOnAllContentParents was added to the DataStorage implementation so we could make more security state information available in child processes. It uses IPC APIs, which in general are not thread-safe. We need to make sure that these APIs are only accessed on the main thread, which means we have to copy any necessary data, create a runnable, and send it to the main thread to do the actual work. Note that the IPC APIs are async, so this dispatch can be async as well. MozReview-Commit-ID: HwkgSX1iORU
956f6dbae7e37d6c20af037428ee3a3b6549ea32: Bug 1462324 - Remove unused WebAuthnTransaction::mDirectAttestation r=jcj
Tim Taubert <ttaubert@mozilla.com> - Thu, 17 May 2018 18:32:53 +0200 - rev 796571
Push 110279 by bmo:gl@mozilla.com at Thu, 17 May 2018 19:42:48 +0000
Bug 1462324 - Remove unused WebAuthnTransaction::mDirectAttestation r=jcj Reviewers: jcj Reviewed By: jcj Bug #: 1462324 Differential Revision: https://phabricator.services.mozilla.com/D1301
0f5b9cd3d7107aa8d744036247d56dc9576e1dcf: Bug 1460301 - Web Authentication - Don't use U2F_PING to initialize tokens r=jcj
Tim Taubert <ttaubert@mozilla.com> - Mon, 14 May 2018 17:37:47 +0200 - rev 794958
Push 109827 by mozilla@noorenberghe.ca at Mon, 14 May 2018 20:13:54 +0000
Bug 1460301 - Web Authentication - Don't use U2F_PING to initialize tokens r=jcj Reviewers: jcj Reviewed By: jcj Bug #: 1460301 Differential Revision: https://phabricator.services.mozilla.com/D1270
33ae17f18193912b12e7a890175a4d8749d75d9a: bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r=fkiefer,jcj
David Keeler <dkeeler@mozilla.com> - Mon, 07 May 2018 17:05:30 -0700 - rev 794101
Push 109574 by bmo:dharvey@mozilla.com at Fri, 11 May 2018 10:59:04 +0000
bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r=fkiefer,jcj If a user has set a master password on their NSS DB(s), when we try to change the trust of a certificate, we may have to authenticate to the DB. This involves bringing up a dialog box, executing javascript, spinning the event loop, etc. In some cases (particularly when antivirus software has injected code into Firefox), this can cause the nsNSSComponent to be initialized if it hasn't already been. So, it's a really, really bad idea to attempt to change the trust of a certificate while we're initializing nsNSSComponent, because this results in a recursive component dependency and everything breaks. To get around this, if we need to load 3rd party roots (e.g. enterprise roots or the family safety root), we defer any trust changes to a later event loop tick. In theory this could cause verification failures early in startup. We'll have to see if this is an issue in practice. MozReview-Commit-ID: FvjHP5dTmpP
0693ec09dd681c54f3e0c8c64ec4dbc4916d10a1: bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r=fkiefer,jcj
David Keeler <dkeeler@mozilla.com> - Mon, 07 May 2018 17:05:30 -0700 - rev 794059
Push 109574 by bmo:dharvey@mozilla.com at Fri, 11 May 2018 10:59:04 +0000
bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r=fkiefer,jcj If a user has set a master password on their NSS DB(s), when we try to change the trust of a certificate, we may have to authenticate to the DB. This involves bringing up a dialog box, executing javascript, spinning the event loop, etc. In some cases (particularly when antivirus software has injected code into Firefox), this can cause the nsNSSComponent to be initialized if it hasn't already been. So, it's a really, really bad idea to attempt to change the trust of a certificate while we're initializing nsNSSComponent, because this results in a recursive component dependency and everything breaks. To get around this, if we need to load 3rd party roots (e.g. enterprise roots or the family safety root), we defer any trust changes to a later event loop tick. In theory this could cause verification failures early in startup. We'll have to see if this is an issue in practice. MozReview-Commit-ID: FvjHP5dTmpP
b1560bf14026064d0d4070046648763d9728f5c7: bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Mon, 07 May 2018 17:05:30 -0700 - rev 793823
Push 109511 by bmo:dkeeler@mozilla.com at Thu, 10 May 2018 20:50:36 +0000
bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r?jcj,fkiefer If a user has set a master password on their NSS DB(s), when we try to change the trust of a certificate, we may have to authenticate to the DB. This involves bringing up a dialog box, executing javascript, spinning the event loop, etc. In some cases (particularly when antivirus software has injected code into Firefox), this can cause the nsNSSComponent to be initialized if it hasn't already been. So, it's a really, really bad idea to attempt to change the trust of a certificate while we're initializing nsNSSComponent, because this results in a recursive component dependency and everything breaks. To get around this, if we need to load 3rd party roots (e.g. enterprise roots or the family safety root), we defer any trust changes to a later event loop tick. In theory this could cause verification failures early in startup. We'll have to see if this is an issue in practice. MozReview-Commit-ID: FvjHP5dTmpP
8ef5efda38f0dfcac307213f7db11a04a771daeb: bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Mon, 07 May 2018 17:05:30 -0700 - rev 793715
Push 109477 by bmo:dkeeler@mozilla.com at Thu, 10 May 2018 16:59:41 +0000
bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r?jcj,fkiefer If a user has set a master password on their NSS DB(s), when we try to change the trust of a certificate, we may have to authenticate to the DB. This involves bringing up a dialog box, executing javascript, spinning the event loop, etc. In some cases (particularly when antivirus software has injected code into Firefox), this can cause the nsNSSComponent to be initialized if it hasn't already been. So, it's a really, really bad idea to attempt to change the trust of a certificate while we're initializing nsNSSComponent, because this results in a recursive component dependency and everything breaks. To get around this, if we need to load 3rd party roots (e.g. enterprise roots or the family safety root), we defer any trust changes to a later event loop tick. In theory this could cause verification failures early in startup. We'll have to see if this is an issue in practice. MozReview-Commit-ID: FvjHP5dTmpP
28452fd08a415f3dbb59999b4e286e028759eaf5: bug 1460312 - cancel the timeout timer in OCSP request implementation r=jcj
David Keeler <dkeeler@mozilla.com> - Wed, 09 May 2018 10:06:49 -0700 - rev 793566
Push 109431 by ahalberstadt@mozilla.com at Thu, 10 May 2018 12:18:34 +0000
bug 1460312 - cancel the timeout timer in OCSP request implementation r=jcj Bug 1456489 cleaned up our OCSP request implementation a bit. One simplification it made was to not cancel the timeout timer. It turns out that if we don't, the OCSPRequest that constitutes the timeout callback's closure might not be valid if the request has completed (because the timer doesn't own a strong reference to it). The fix is simple: cancel the timer when the request completes. Note that we don't have to do the reverse because necko has a strong reference to the request. MozReview-Commit-ID: 2WHFLAcGBAw
3fb87768cb56e2787ce9e4a9fbb282519de8b4bf: bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Mon, 07 May 2018 17:05:30 -0700 - rev 793395
Push 109370 by bmo:dkeeler@mozilla.com at Wed, 09 May 2018 23:25:44 +0000
bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r?jcj,fkiefer If a user has set a master password on their NSS DB(s), when we try to change the trust of a certificate, we may have to authenticate to the DB. This involves bringing up a dialog box, executing javascript, spinning the event loop, etc. In some cases (particularly when antivirus software has injected code into Firefox), this can cause the nsNSSComponent to be initialized if it hasn't already been. So, it's a really, really bad idea to attempt to change the trust of a certificate while we're initializing nsNSSComponent, because this results in a recursive component dependency and everything breaks. To get around this, if we need to load 3rd party roots (e.g. enterprise roots or the family safety root), we defer any trust changes to a later event loop tick. In theory this could cause verification failures early in startup. We'll have to see if this is an issue in practice. MozReview-Commit-ID: FvjHP5dTmpP
9573afbf191a16e601324fe0257521e37a5a36a0: bug 1460312 - cancel the timeout timer in OCSP request implementation r?jcj draft
David Keeler <dkeeler@mozilla.com> - Wed, 09 May 2018 10:06:49 -0700 - rev 793195
Push 109310 by bmo:dkeeler@mozilla.com at Wed, 09 May 2018 17:07:10 +0000
bug 1460312 - cancel the timeout timer in OCSP request implementation r?jcj Bug 1456489 cleaned up our OCSP request implementation a bit. One simplification it made was to not cancel the timeout timer. It turns out that if we don't, the OCSPRequest that constitutes the timeout callback's closure might not be valid if the request has completed (because the timer doesn't own a strong reference to it). The fix is simple: cancel the timer when the request completes. Note that we don't have to do the reverse because necko has a strong reference to the request. MozReview-Commit-ID: 2WHFLAcGBAw
47d306cfac90a964882781e135cc70b3359b7a95: bug 1456489 - prevent making OCSP requests on the main thread r=fkiefer,jcj
David Keeler <dkeeler@mozilla.com> - Mon, 23 Apr 2018 18:09:35 +0200 - rev 792911
Push 109204 by kgupta@mozilla.com at Wed, 09 May 2018 00:40:28 +0000
bug 1456489 - prevent making OCSP requests on the main thread r=fkiefer,jcj OCSP requests cannot be performed on the main thread. If we were to wait for a response from the network, we would be blocking the main thread for an unnaceptably long time. If we were to spin the event loop while waiting (which is what we do currently), other parts of the code that assume this will never happen (which is essentially all of them) can break. As of bug 867473, no certificate verification happens on the main thread, so no OCSP requests happen on the main thread. Given this, we can go ahead and prohibit such requests. Incidentally, this gives us an opportunity to improve the current OCSP implementation, which has a few drawbacks (the largest of which is that it's unclear that its ownership model is implemented correctly). This also removes OCSP GET support. Due to recent OCSP server implementations (namely, the ability to cache OCSP POST request responses), OCSP GET is not a compelling technology to pursue. Furthermore, continued support presents a maintenance burden. MozReview-Commit-ID: 4ACDY09nCBA
c8c8d2257f3efa54d287dedc325255a402d0b551: bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Mon, 07 May 2018 17:05:30 -0700 - rev 792892
Push 109200 by bmo:dkeeler@mozilla.com at Tue, 08 May 2018 23:57:35 +0000
bug 1427248 - avoid changing certificate trust in nsNSSComponent initialization r?jcj,fkiefer If a user has set a master password on their NSS DB(s), when we try to change the trust of a certificate, we may have to authenticate to the DB. This involves bringing up a dialog box, executing javascript, spinning the event loop, etc. In some cases (particularly when antivirus software has injected code into Firefox), this can cause the nsNSSComponent to be initialized if it hasn't already been. So, it's a really, really bad idea to attempt to change the trust of a certificate while we're initializing nsNSSComponent, because this results in a recursive component dependency and everything breaks. To get around this, if we need to load 3rd party roots (e.g. enterprise roots or the family safety root), we defer any trust changes to a later event loop tick. In theory this could cause verification failures early in startup. We'll have to see if this is an issue in practice. MozReview-Commit-ID: FvjHP5dTmpP
2249d58c94c867628b83d6c32eb0b5f64812a05c: bug 1456489 - prevent making OCSP requests on the main thread r?jcj,fkiefer draft
David Keeler <dkeeler@mozilla.com> - Mon, 23 Apr 2018 18:09:35 +0200 - rev 792581
Push 109151 by bmo:dkeeler@mozilla.com at Tue, 08 May 2018 16:55:23 +0000
bug 1456489 - prevent making OCSP requests on the main thread r?jcj,fkiefer OCSP requests cannot be performed on the main thread. If we were to wait for a response from the network, we would be blocking the main thread for an unnaceptably long time. If we were to spin the event loop while waiting (which is what we do currently), other parts of the code that assume this will never happen (which is essentially all of them) can break. As of bug 867473, no certificate verification happens on the main thread, so no OCSP requests happen on the main thread. Given this, we can go ahead and prohibit such requests. Incidentally, this gives us an opportunity to improve the current OCSP implementation, which has a few drawbacks (the largest of which is that it's unclear that its ownership model is implemented correctly). This also removes OCSP GET support. Due to recent OCSP server implementations (namely, the ability to cache OCSP POST request responses), OCSP GET is not a compelling technology to pursue. Furthermore, continued support presents a maintenance burden. MozReview-Commit-ID: 4ACDY09nCBA
69c1887daefdf3c93b4d6d9227b389896f9cfd14: bug 1255120 - add telemetry for client certificate use r=jcj
David Keeler <dkeeler@mozilla.com> - Thu, 03 May 2018 14:29:38 -0700 - rev 792412
Push 109110 by kgupta@mozilla.com at Tue, 08 May 2018 12:47:39 +0000
bug 1255120 - add telemetry for client certificate use r=jcj MozReview-Commit-ID: Et8Fm78Ujxn
38e60f49b316258b72f8453387049c16d2005867: bug 1458720 - make RunOnAllContentParents runnable from any thread r=Ehsan,jcj
David Keeler <dkeeler@mozilla.com> - Wed, 02 May 2018 16:42:51 -0700 - rev 792411
Push 109110 by kgupta@mozilla.com at Tue, 08 May 2018 12:47:39 +0000
bug 1458720 - make RunOnAllContentParents runnable from any thread r=Ehsan,jcj In bug 1215723 RunOnAllContentParents was added to the DataStorage implementation so we could make more security state information available in child processes. It uses IPC APIs, which in general are not thread-safe. We need to make sure that these APIs are only accessed on the main thread, which means we have to copy any necessary data, create a runnable, and send it to the main thread to do the actual work. Note that the IPC APIs are async, so this dispatch can be async as well. MozReview-Commit-ID: HwkgSX1iORU