searching for reviewer(ttaubert)
69ca265a87712c4192be6f84f12df2daee5ab5c8: Bug 1463170 - Set AuthenticatorAssertionResponse.userHandle to null. r=ttaubert, r=smaug, a=RyanVM
J.C. Jones <jjones@mozilla.com> - Mon, 21 May 2018 09:04:50 -0700 - rev 802273
Push 111850 by bmo:tom@mozilla.com at Thu, 31 May 2018 16:41:37 +0000
Bug 1463170 - Set AuthenticatorAssertionResponse.userHandle to null. r=ttaubert, r=smaug, a=RyanVM Summary: The WebAuthn spec says to set `AuthenticatorAssertionResponse.userHandle` to null when the authenticator returns no user handle (e.g., when allowList is set), but we return an empty ArrayBuffer. This is because of the defaults in AuthenticatorAssertionResponse.h, as the field is itself unset. We missed this change to the spec that happened in December [2], so this also has a corresponding WebIDL update. I don't see any other instances of WebIDL differences. [1] https://w3c.github.io/webauthn/#ref-for-dom-authenticatorassertionresponse-userhandle%E2%91%A0 [2] https://github.com/w3c/webauthn/commit/3b2a1d141cbd8f2954f073a6b6598d954398a986 Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=59a2ab255ef14e935c1aa9f457276f8e61e5d779 Reviewers: smaug, ttaubert Bug #: 1463170 Differential Revision: https://phabricator.services.mozilla.com/D1337
1db563cfbd926edc4e8c9acd667f876b91404b6d: Bug 1460767 - Return device ineligible when appropriate for U2F. r=ttaubert, a=jcristau
J.C. Jones <jjones@mozilla.com> - Thu, 10 May 2018 16:36:18 -0700 - rev 802234
Push 111850 by bmo:tom@mozilla.com at Thu, 31 May 2018 16:41:37 +0000
Bug 1460767 - Return device ineligible when appropriate for U2F. r=ttaubert, a=jcristau Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269
36c03b72db500ae707a6876cc34c811a639d1ad7: Bug 1463170 - Set AuthenticatorAssertionResponse.userHandle to null. r=ttaubert, r=smaug, a=RyanVM
J.C. Jones <jjones@mozilla.com> - Mon, 21 May 2018 09:04:50 -0700 - rev 801595
Push 111693 by bmo:khudson@mozilla.com at Wed, 30 May 2018 15:07:47 +0000
Bug 1463170 - Set AuthenticatorAssertionResponse.userHandle to null. r=ttaubert, r=smaug, a=RyanVM Summary: The WebAuthn spec says to set `AuthenticatorAssertionResponse.userHandle` to null when the authenticator returns no user handle (e.g., when allowList is set), but we return an empty ArrayBuffer. This is because of the defaults in AuthenticatorAssertionResponse.h, as the field is itself unset. We missed this change to the spec that happened in December [2], so this also has a corresponding WebIDL update. I don't see any other instances of WebIDL differences. [1] https://w3c.github.io/webauthn/#ref-for-dom-authenticatorassertionresponse-userhandle%E2%91%A0 [2] https://github.com/w3c/webauthn/commit/3b2a1d141cbd8f2954f073a6b6598d954398a986 Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=59a2ab255ef14e935c1aa9f457276f8e61e5d779 Reviewers: smaug, ttaubert Bug #: 1463170 Differential Revision: https://phabricator.services.mozilla.com/D1337
3c95faed62ee89a0597ef181f8df9f9b50e98b3f: Bug 1463170 - Set AuthenticatorAssertionResponse.userHandle to null r=ttaubert r=smaug
J.C. Jones <jjones@mozilla.com> - Mon, 21 May 2018 09:04:50 -0700 - rev 799485
Push 111081 by choller@mozilla.com at Thu, 24 May 2018 20:05:57 +0000
Bug 1463170 - Set AuthenticatorAssertionResponse.userHandle to null r=ttaubert r=smaug Summary: The WebAuthn spec says to set `AuthenticatorAssertionResponse.userHandle` to null when the authenticator returns no user handle (e.g., when allowList is set), but we return an empty ArrayBuffer. This is because of the defaults in AuthenticatorAssertionResponse.h, as the field is itself unset. We missed this change to the spec that happened in December [2], so this also has a corresponding WebIDL update. I don't see any other instances of WebIDL differences. [1] https://w3c.github.io/webauthn/#ref-for-dom-authenticatorassertionresponse-userhandle%E2%91%A0 [2] https://github.com/w3c/webauthn/commit/3b2a1d141cbd8f2954f073a6b6598d954398a986 Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=59a2ab255ef14e935c1aa9f457276f8e61e5d779 Reviewers: smaug, ttaubert Bug #: 1463170 Differential Revision: https://phabricator.services.mozilla.com/D1337
594d4ff3b55bca69fedc366b0573bf17e204f118: Bug 1460767 - Return device ineligible when appropriate for U2F. r=ttaubert, a=RyanVM
J.C. Jones <jjones@mozilla.com> - Thu, 10 May 2018 16:36:18 -0700 - rev 797186
Push 110422 by bmo:khudson@mozilla.com at Fri, 18 May 2018 18:23:40 +0000
Bug 1460767 - Return device ineligible when appropriate for U2F. r=ttaubert, a=RyanVM Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269
5166f4f5af706b3c37982ac1e94498d979b8198d: Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert
J.C. Jones <jjones@mozilla.com> - Thu, 10 May 2018 16:36:18 -0700 - rev 794955
Push 109827 by mozilla@noorenberghe.ca at Mon, 14 May 2018 20:13:54 +0000
Bug 1460767 - Return device ineligible when appropriate for U2F r=ttaubert Summary: FIDO U2F's specification says that when the wrong security key responds to a signature, or when an already-registered key exists, that the UA should return error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things for WebAuthn and now we don't. This changes the soft token to return that at the appropriate times, and updates the expectations of U2F.cpp that it should use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE. Also, note that WebAuthn's specification says that if any authenticator returns "InvalidStateError" that it should be propagated, as it indicates that the authenticator obtained user consent and failed to complete its job [1]. This change to the Soft Token affects the WebAuthn tests, but in a good way. Reading the WebAuthn spec, we should not be returning NotAllowedError when there is consent from the user via the token (which the softtoken always deliveres). As such, this adjusts the affected WebAuthn tests, and adds a couple useful checks to test_webauthn_get_assertion.html for future purposes. [1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new credential", Step 20, Note 2: "If any authenticator returns an error status equivalent to "InvalidStateError"..." Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4 Reviewers: ttaubert Bug #: 1460767 Differential Revision: https://phabricator.services.mozilla.com/D1269
141a3103a248206af8178cdac0e5c90cb4f7efec: Bug 1443248 - Update u2fhid to core-foundation-sys 0.5. r=ttaubert
Matt Brubeck <mbrubeck@mozilla.com> - Mon, 05 Mar 2018 11:13:13 -0800 - rev 764162
Push 101686 by bmo:dburns@mozilla.com at Wed, 07 Mar 2018 10:32:55 +0000
Bug 1443248 - Update u2fhid to core-foundation-sys 0.5. r=ttaubert MozReview-Commit-ID: 4xTSQpvHHAV
7a630b29a6938e594f6fc677a405df7afdb38aa7: Bug 1443248 - Update u2fhid to core-foundation-sys 0.5. r?ttaubert draft
Matt Brubeck <mbrubeck@mozilla.com> - Mon, 05 Mar 2018 11:13:13 -0800 - rev 763329
Push 101404 by bmo:mbrubeck@mozilla.com at Mon, 05 Mar 2018 19:20:32 +0000
Bug 1443248 - Update u2fhid to core-foundation-sys 0.5. r?ttaubert MozReview-Commit-ID: 4xTSQpvHHAV
62646c1718b29026bb0fc8dddc2bcbe894a025f7: Bug 1436078 - Hard-code U2F permissions for Google Accounts r=ttaubert
J.C. Jones <jjones@mozilla.com> - Tue, 06 Feb 2018 16:59:00 -0700 - rev 752242
Push 98202 by bmo:standard8@mozilla.com at Wed, 07 Feb 2018 19:25:55 +0000
Bug 1436078 - Hard-code U2F permissions for Google Accounts r=ttaubert This patch support already-enrolled U2F devices at Google Accounts by adding a hard-coded "OK" into the U2F EvaluateAppID method, per the intent-to-ship [1]. This adds no tests, as this is not testable in our infrastructure. It will require cooporation with Google Accounts to validate. [1] https://groups.google.com/d/msg/mozilla.dev.platform/Uiu3fwnA2xw/201ynAiPAQAJ MozReview-Commit-ID: 1YLd5sfeTKv
89ac5a28c228649e436cd8dbcec0d395c231e4e1: Bug 1436078 - Hard-code U2F permissions for Google Accounts r=ttaubert
J.C. Jones <jjones@mozilla.com> - Tue, 06 Feb 2018 16:59:00 -0700 - rev 752220
Push 98202 by bmo:standard8@mozilla.com at Wed, 07 Feb 2018 19:25:55 +0000
Bug 1436078 - Hard-code U2F permissions for Google Accounts r=ttaubert This patch support already-enrolled U2F devices at Google Accounts by adding a hard-coded "OK" into the U2F EvaluateAppID method, per the intent-to-ship [1]. This adds no tests, as this is not testable in our infrastructure. It will require cooporation with Google Accounts to validate. [1] https://groups.google.com/d/msg/mozilla.dev.platform/Uiu3fwnA2xw/201ynAiPAQAJ MozReview-Commit-ID: 1YLd5sfeTKv
818739b96ea454ff8b4366fe8996ee4bbee2e564: Bug 1436078 - Hard-code U2F permissions for Google Accounts r?ttaubert draft
J.C. Jones <jjones@mozilla.com> - Tue, 06 Feb 2018 16:59:00 -0700 - rev 752169
Push 98184 by bmo:jjones@mozilla.com at Wed, 07 Feb 2018 17:20:50 +0000
Bug 1436078 - Hard-code U2F permissions for Google Accounts r?ttaubert This patch support already-enrolled U2F devices at Google Accounts by adding a hard-coded "OK" into the U2F EvaluateAppID method, per the intent-to-ship [1]. This adds no tests, as this is not testable in our infrastructure. It will require cooporation with Google Accounts to validate. [1] https://groups.google.com/d/msg/mozilla.dev.platform/Uiu3fwnA2xw/201ynAiPAQAJ MozReview-Commit-ID: 1YLd5sfeTKv
a6a124a1412347a6eaca9d5d02b12d6f01fa7365: Bug 1436078 - Hard-code U2F permissions for Google Accounts r?ttaubert draft
J.C. Jones <jjones@mozilla.com> - Tue, 06 Feb 2018 16:59:00 -0700 - rev 752123
Push 98171 by bmo:jjones@mozilla.com at Wed, 07 Feb 2018 15:48:01 +0000
Bug 1436078 - Hard-code U2F permissions for Google Accounts r?ttaubert This patch support already-enrolled U2F devices at Google Accounts by adding a hard-coded "OK" into the U2F EvaluateAppID method, per the intent-to-ship [1]. This adds no tests, as this is not testable in our infrastructure. It will require cooporation with Google Accounts to validate. [1] https://groups.google.com/d/msg/mozilla.dev.platform/Uiu3fwnA2xw/201ynAiPAQAJ MozReview-Commit-ID: 1YLd5sfeTKv
312f8937eab9cedd27ba298aea5ef2d8a1bf96e5: Bug 1436078 - Hard-code U2F permissions for Google Accounts r?ttaubert draft
J.C. Jones <jjones@mozilla.com> - Tue, 06 Feb 2018 16:59:00 -0700 - rev 752116
Push 98166 by bmo:jjones@mozilla.com at Wed, 07 Feb 2018 15:29:32 +0000
Bug 1436078 - Hard-code U2F permissions for Google Accounts r?ttaubert This patch support already-enrolled U2F devices at Google Accounts by adding a hard-coded "OK" into the U2F EvaluateAppID method, per the intent-to-ship [1]. This adds no tests, as this is not testable in our infrastructure. It will require cooporation with Google Accounts to validate. [1] https://groups.google.com/d/msg/mozilla.dev.platform/Uiu3fwnA2xw/201ynAiPAQAJ MozReview-Commit-ID: 1YLd5sfeTKv
fc07ef40b196d164219adb66e3abdd6998296e50: Bug #1436078 - Hard-code U2F permissions for Google Accounts r?ttaubert draft
J.C. Jones <jjones@mozilla.com> - Tue, 06 Feb 2018 16:59:00 -0700 - rev 752107
Push 98161 by bmo:jjones@mozilla.com at Wed, 07 Feb 2018 14:52:04 +0000
Bug #1436078 - Hard-code U2F permissions for Google Accounts r?ttaubert This patch support already-enrolled U2F devices at Google Accounts by adding a hard-coded "OK" into the U2F EvaluateAppID method, per the intent-to-ship [1]. This adds no tests, as this is not testable in our infrastructure. It will require cooporation with Google Accounts to validate. [1] https://groups.google.com/d/msg/mozilla.dev.platform/Uiu3fwnA2xw/201ynAiPAQAJ MozReview-Commit-ID: 1YLd5sfeTKv
8cf89476ec6ca1d5d929339ed411f427199d30a7: Bug #1436078 - Hard-code U2F permissions for Google Accounts r?ttaubert draft
J.C. Jones <jjones@mozilla.com> - Tue, 06 Feb 2018 16:59:00 -0700 - rev 751831
Push 98071 by bmo:jjones@mozilla.com at Wed, 07 Feb 2018 00:00:41 +0000
Bug #1436078 - Hard-code U2F permissions for Google Accounts r?ttaubert This patch support already-enrolled U2F devices at Google Accounts by adding a hard-coded "OK" into the U2F EvaluateAppID method, per the intent-to-ship [1]. This adds no tests, as this is not testable in our infrastructure. It will require cooporation with Google Accounts to validate. [1] https://groups.google.com/d/msg/mozilla.dev.platform/Uiu3fwnA2xw/201ynAiPAQAJ MozReview-Commit-ID: 1YLd5sfeTKv
e21956fd51a330cad2301e49bb458e2ca94c5368: bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r=mt,ttaubert
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:44:01 -0800 - rev 750354
Push 97629 by bmo:continuation@gmail.com at Thu, 01 Feb 2018 23:06:34 +0000
bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r=mt,ttaubert MozReview-Commit-ID: 2mhvHsC5Nil
0d42218045d9de6b746b09669dedb0e30e8005c3: bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r=mt,ttaubert
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:29:08 -0800 - rev 750353
Push 97629 by bmo:continuation@gmail.com at Thu, 01 Feb 2018 23:06:34 +0000
bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r=mt,ttaubert MozReview-Commit-ID: ErL7ZjAGVVC
ecb9941ee0344bd6952724e371589c3d0834e30d: bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r=mt,ttaubert
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 12:22:56 -0800 - rev 750352
Push 97629 by bmo:continuation@gmail.com at Thu, 01 Feb 2018 23:06:34 +0000
bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r=mt,ttaubert MozReview-Commit-ID: DlS16pHE0Ik
b2b6ca8d0f70173d7b18bca53fa4e7a57dba9a14: bug 1421084 - part 1/4 - remove now-unnecessary nsNSSShutDownPreventionLock r=mt,ttaubert
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 10:37:47 -0800 - rev 750351
Push 97629 by bmo:continuation@gmail.com at Thu, 01 Feb 2018 23:06:34 +0000
bug 1421084 - part 1/4 - remove now-unnecessary nsNSSShutDownPreventionLock r=mt,ttaubert As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and does nothing anyway). This series of changesets removes the remaining pieces in a way that is hopefully easy to confirm is correct. MozReview-Commit-ID: 8Y5wpsyNlGc
ddb13567a81d15be5bfd70f1292bbe55f338e8db: bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:44:01 -0800 - rev 750215
Push 97581 by bmo:dkeeler@mozilla.com at Thu, 01 Feb 2018 18:39:40 +0000
bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r?ttaubert,mt MozReview-Commit-ID: 2mhvHsC5Nil
99445aaec08ee31272a2df71f6408fb437eb5ad0: bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:29:08 -0800 - rev 750214
Push 97581 by bmo:dkeeler@mozilla.com at Thu, 01 Feb 2018 18:39:40 +0000
bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r?ttaubert,mt MozReview-Commit-ID: ErL7ZjAGVVC
b1ab279c6ebe1671e2dd3e88d8a6e9e6a243b6a6: bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 12:22:56 -0800 - rev 750213
Push 97581 by bmo:dkeeler@mozilla.com at Thu, 01 Feb 2018 18:39:40 +0000
bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r?ttaubert,mt MozReview-Commit-ID: DlS16pHE0Ik
d647beb1d38e9c70035c7b4069b420a817fabf66: bug 1421084 - part 1/4 - remove now-unnecessary nsNSSShutDownPreventionLock r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 10:37:47 -0800 - rev 750212
Push 97581 by bmo:dkeeler@mozilla.com at Thu, 01 Feb 2018 18:39:40 +0000
bug 1421084 - part 1/4 - remove now-unnecessary nsNSSShutDownPreventionLock r?ttaubert,mt As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and does nothing anyway). This series of changesets removes the remaining pieces in a way that is hopefully easy to confirm is correct. MozReview-Commit-ID: 8Y5wpsyNlGc
e3ef641e67fc134aa7a09d72fa3ca79cf67dce5a: bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:44:01 -0800 - rev 749623
Push 97464 by bmo:dkeeler@mozilla.com at Wed, 31 Jan 2018 21:01:00 +0000
bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r?ttaubert,mt MozReview-Commit-ID: 2mhvHsC5Nil
53b72e499e2c2631e1ead8d5c93c2355f1de1d34: bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:29:08 -0800 - rev 749622
Push 97464 by bmo:dkeeler@mozilla.com at Wed, 31 Jan 2018 21:01:00 +0000
bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r?ttaubert,mt MozReview-Commit-ID: ErL7ZjAGVVC
360b0196c4949cd1e77880458dcb46f5c82d6d83: bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 12:22:56 -0800 - rev 749621
Push 97464 by bmo:dkeeler@mozilla.com at Wed, 31 Jan 2018 21:01:00 +0000
bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r?ttaubert,mt MozReview-Commit-ID: DlS16pHE0Ik
270812bffa3d60d56fededdd1ca51d5212aafeb7: bug 1421084 - part 1/4 - remove now-unnecessary nsNSSShutDownPreventionLock r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 10:37:47 -0800 - rev 749620
Push 97464 by bmo:dkeeler@mozilla.com at Wed, 31 Jan 2018 21:01:00 +0000
bug 1421084 - part 1/4 - remove now-unnecessary nsNSSShutDownPreventionLock r?ttaubert,mt As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and does nothing anyway). This series of changesets removes the remaining pieces in a way that is hopefully easy to confirm is correct. MozReview-Commit-ID: 8Y5wpsyNlGc
28017bf6c7e1cea4a970d018ede9b45c96411193: bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:44:01 -0800 - rev 747789
Push 97008 by bmo:dkeeler@mozilla.com at Fri, 26 Jan 2018 21:16:24 +0000
bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r?ttaubert,mt MozReview-Commit-ID: 2mhvHsC5Nil
9ac1104da0e8a22438012ecc6a4aad03dccac509: bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:29:08 -0800 - rev 747788
Push 97008 by bmo:dkeeler@mozilla.com at Fri, 26 Jan 2018 21:16:24 +0000
bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r?ttaubert,mt MozReview-Commit-ID: ErL7ZjAGVVC
41562409c0227425536e5c99f33100882ec4b1f8: bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 12:22:56 -0800 - rev 747787
Push 97008 by bmo:dkeeler@mozilla.com at Fri, 26 Jan 2018 21:16:24 +0000
bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r?ttaubert,mt MozReview-Commit-ID: DlS16pHE0Ik
1a6b9f8a93f82bc5da6e27fb35e273395a680bf3: bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:44:01 -0800 - rev 747782
Push 97006 by bmo:dkeeler@mozilla.com at Fri, 26 Jan 2018 20:56:29 +0000
bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r?ttaubert,mt MozReview-Commit-ID: 2mhvHsC5Nil
a40f3c19d10fe69ff3c8062fb6d9ca6f6f967ca0: bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:29:08 -0800 - rev 747781
Push 97006 by bmo:dkeeler@mozilla.com at Fri, 26 Jan 2018 20:56:29 +0000
bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r?ttaubert,mt MozReview-Commit-ID: ErL7ZjAGVVC
05a2d23e9c2aef7e08eb0b9ab4dcdb9589b56954: bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 12:22:56 -0800 - rev 747780
Push 97006 by bmo:dkeeler@mozilla.com at Fri, 26 Jan 2018 20:56:29 +0000
bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r?ttaubert,mt MozReview-Commit-ID: DlS16pHE0Ik
f4ad117874fff4388fe5ccba9be26088df14f1fb: bug 1421084 - part 1/4 - remove now-unnecessary nsNSSShutDownPreventionLock r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 10:37:47 -0800 - rev 747779
Push 97006 by bmo:dkeeler@mozilla.com at Fri, 26 Jan 2018 20:56:29 +0000
bug 1421084 - part 1/4 - remove now-unnecessary nsNSSShutDownPreventionLock r?ttaubert,mt As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and does nothing anyway). This series of changesets removes the remaining pieces in a way that is hopefully easy to confirm is correct. MozReview-Commit-ID: 8Y5wpsyNlGc
c8356046df381fa8f77177d15593a246ebf3f68b: bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:44:01 -0800 - rev 747214
Push 96844 by bmo:dkeeler@mozilla.com at Thu, 25 Jan 2018 18:35:01 +0000
bug 1421084 - part 4/4 - remove nsNSSShutDown.h and (hopefully) all references to it r?ttaubert,mt MozReview-Commit-ID: 2mhvHsC5Nil
f84484950ae7dda360fbe374d3ad210e7ca08b34: bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Wed, 24 Jan 2018 14:29:08 -0800 - rev 747213
Push 96844 by bmo:dkeeler@mozilla.com at Thu, 25 Jan 2018 18:35:01 +0000
bug 1421084 - part 3/4 - remove nsNSSShutDownObject::shutdown and virtualDestroyNSSReference r?ttaubert,mt MozReview-Commit-ID: ErL7ZjAGVVC
6668b8ba01840f24c501d42194b07488e186d300: bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 12:22:56 -0800 - rev 747212
Push 96844 by bmo:dkeeler@mozilla.com at Thu, 25 Jan 2018 18:35:01 +0000
bug 1421084 - part 2/4 - remove nsNSSShutDownObject::isAlreadyShutDown() r?ttaubert,mt MozReview-Commit-ID: DlS16pHE0Ik
e1ba01e6a07bf11195d1c794f3e6fa9e9dac0eca: bug 1421084 - part 1/4 - remove now-unnecessary nsNSSShutDownPreventionLock r?ttaubert,mt draft
David Keeler <dkeeler@mozilla.com> - Tue, 23 Jan 2018 10:37:47 -0800 - rev 747211
Push 96844 by bmo:dkeeler@mozilla.com at Thu, 25 Jan 2018 18:35:01 +0000
bug 1421084 - part 1/4 - remove now-unnecessary nsNSSShutDownPreventionLock r?ttaubert,mt As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and does nothing anyway). This series of changesets removes the remaining pieces in a way that is hopefully easy to confirm is correct. MozReview-Commit-ID: 8Y5wpsyNlGc
c2e41df3f41f38fe9a38282610f7c1daf519f87c: Bug 1428916 - WebAuthn: Draft Attestation Preference r=smaug,ttaubert
J.C. Jones <jjones@mozilla.com> - Tue, 23 Jan 2018 12:21:15 -0700 - rev 724079
Push 96631 by sfraser@mozilla.com at Wed, 24 Jan 2018 12:46:30 +0000
Bug 1428916 - WebAuthn: Draft Attestation Preference r=smaug,ttaubert The WebAuthn spec lets RPs ask to specifically get direct attestation certificates during credential creation using the "Attestation Conveyance Preference" [1]. This change adds that field into the WebIDL and ignores it for now. This is pre-work to Bug #1430150 which will make this useful (which in turn requires Bug #1416056's support for anonymizing those attestation certificates). [1] https://www.w3.org/TR/webauthn/#attestation-convey MozReview-Commit-ID: 763vaAMv48z
f146c5a9ab2f706ab47757fcf53be1aa60288ed6: Bug 1428916 - WebAuthn: Draft Attestation Preference r?smaug r?ttaubert draft
J.C. Jones <jjones@mozilla.com> - Tue, 23 Jan 2018 12:21:15 -0700 - rev 723873
Push 96563 by bmo:jjones@mozilla.com at Wed, 24 Jan 2018 00:02:35 +0000
Bug 1428916 - WebAuthn: Draft Attestation Preference r?smaug r?ttaubert The WebAuthn spec lets RPs ask to specifically get direct attestation certificates during credential creation using the "Attestation Conveyance Preference" [1]. This change adds that field into the WebIDL and ignores it for now. This is pre-work to Bug #1430150 which will make this useful (which in turn requires Bug #1416056's support for anonymizing those attestation certificates). [1] https://www.w3.org/TR/webauthn/#attestation-convey MozReview-Commit-ID: 763vaAMv48z
aff59dd959f5278018de682a34d6d501ad951685: Bug 1428916 - WebAuthn: Draft Attestation Preference r?smaug r?ttaubert draft
J.C. Jones <jjones@mozilla.com> - Tue, 23 Jan 2018 12:21:15 -0700 - rev 723819
Push 96541 by bmo:jjones@mozilla.com at Tue, 23 Jan 2018 21:36:02 +0000
Bug 1428916 - WebAuthn: Draft Attestation Preference r?smaug r?ttaubert The WebAuthn spec lets RPs ask to specifically get direct attestation certificates during credential creation using the "Attestation Conveyance Preference" [1]. This change adds that field into the WebIDL and ignores it for now. This is pre-work to Bug #1430150 which will make this useful (which in turn requires Bug #1416056's support for anonymizing those attestation certificates). [1] https://www.w3.org/TR/webauthn/#attestation-convey MozReview-Commit-ID: 763vaAMv48z
85b877dc1fe236312cf540c4f369dfdc0992c898: Bug 1428916 - WebAuthn: Draft Attestation Preference r?smaug r?ttaubert draft
J.C. Jones <jjones@mozilla.com> - Tue, 23 Jan 2018 12:21:15 -0700 - rev 723793
Push 96526 by bmo:jjones@mozilla.com at Tue, 23 Jan 2018 19:53:17 +0000
Bug 1428916 - WebAuthn: Draft Attestation Preference r?smaug r?ttaubert The WebAuthn spec lets RPs ask to specifically get direct attestation certificates during credential creation using the "Attestation Conveyance Preference" [1]. This change adds that field into the WebIDL and ignores it for now. This is pre-work to Bug #1430150 which will make this useful (which in turn requires Bug #1416056's support for anonymizing those attestation certificates). [1] https://www.w3.org/TR/webauthn/#attestation-convey MozReview-Commit-ID: 763vaAMv48z
d67a47719c805b8db375d6708f08a7b0f8335976: Bug 1407789 - Prohibit cross-site iframes for Credential Management r=baku,keeler,ttaubert
J.C. Jones <jjones@mozilla.com> - Thu, 12 Oct 2017 18:18:39 -0700 - rev 717604
Push 94740 by bmo:gasolin@mozilla.com at Tue, 09 Jan 2018 09:59:05 +0000
Bug 1407789 - Prohibit cross-site iframes for Credential Management r=baku,keeler,ttaubert Credential Management defines a parameter `sameOriginWithAncestors` which is set true if the responsible document is not either in a top-level browsing context, or is in a nested context whose heirarchy is all loaded from the same origin as the top-level context [1][2]. The individual credential types of CredMan can use this flag to make decisions on whether to error or not. Our Credential Management implementation right now is a shim to Web Authentication, which says that if `sameOriginWithAncestors` is false, return `"NotAllowedError"`. This ensures that https://webauthn.bin.coffee/iframe.html works, but the cross-origin https://u2f.bin.coffee/iframe-webauthn.html does not. [1] https://w3c.github.io/webappsec-credential-management/#algorithm-request [2] https://w3c.github.io/webappsec-credential-management/#algorithm-create [3] https://w3c.github.io/webauthn/#createCredential [4] https://w3c.github.io/webauthn/#getAssertion MozReview-Commit-ID: KIyakgl0kGv
42eaabb434873337234bc0123a0e45ee6954b0dd: Bug 1420760 - order webauthn CBOR map keys; r?ttaubert draft
Adam Langley <agl@chromium.org> - Sun, 31 Dec 2017 15:37:27 -0800 - rev 715098
Push 94055 by bmo:agl@chromium.org at Sun, 31 Dec 2017 23:39:06 +0000
Bug 1420760 - order webauthn CBOR map keys; r?ttaubert MozReview-Commit-ID: 6BsiL45dxa3
28c602f0f5ebed4e20321bf961c668f8ef8a4738: Bug 1407789 - Prohibit iframes for Credential Management r?baku r?ttaubert draft
J.C. Jones <jjones@mozilla.com> - Thu, 12 Oct 2017 18:18:39 -0700 - rev 712672
Push 93392 by bmo:jjones@mozilla.com at Mon, 18 Dec 2017 15:37:38 +0000
Bug 1407789 - Prohibit iframes for Credential Management r?baku r?ttaubert Credential Management defines a parameter `sameOriginWithAncestors` which is set true if the responsible document is not either in a top-level browsing context, or is in a nested context whose heirarchy is all loaded from the same origin as the top-level context [1][2]. The individual credential types of CredMan can use this flag to make decisions on whether to error or not. Our Credential Management implementation right now is a shim to Web Authentication, which says that if `sameOriginWithAncestors` is false, return `"NotAllowedError"`. This ensures that https://webauthn.bin.coffee/iframe.html works, but the cross-origin https://u2f.bin.coffee/iframe-webauthn.html does not. baku: Please check my logic for IsNotInAFrameOrIsSameOrigin - it appears to work, but I'm no DOM expert! [1] https://w3c.github.io/webappsec-credential-management/#algorithm-request [2] https://w3c.github.io/webappsec-credential-management/#algorithm-create [3] https://w3c.github.io/webauthn/#createCredential [4] https://w3c.github.io/webauthn/#getAssertion MozReview-Commit-ID: KIyakgl0kGv
4c3feee4dfd2d0efac06bf03c872cffd6f89ddc9: Bug 1247124 - Limit FIDO U2F to Secure Contexts r=ttaubert,smaug
J.C. Jones <jjones@mozilla.com> - Wed, 13 Dec 2017 17:02:38 -0600 - rev 712198
Push 93268 by bmo:ntim.bugs@gmail.com at Fri, 15 Dec 2017 19:51:27 +0000
Bug 1247124 - Limit FIDO U2F to Secure Contexts r=ttaubert,smaug Use the [SecureContext] webidl notation to hide the powerful "window.u2f" feature and its interface when not loaded in a secure context. MozReview-Commit-ID: 7en8b5ieI85
7ff7a963bd2e7ab26971a345495bc57c776f4b7c: Bug 1247124 - Limit FIDO U2F to Secure Contexts r?ttaubert r?smaug draft
J.C. Jones <jjones@mozilla.com> - Wed, 13 Dec 2017 17:02:38 -0600 - rev 712046
Push 93234 by bmo:jjones@mozilla.com at Fri, 15 Dec 2017 15:33:26 +0000
Bug 1247124 - Limit FIDO U2F to Secure Contexts r?ttaubert r?smaug Use the [SecureContext] webidl notation to hide the powerful "window.u2f" feature and its interface when not loaded in a secure context. MozReview-Commit-ID: 7en8b5ieI85
4339e8f78af13ea28640e5fc020c9c0161ee92d1: Bug 1247124 - Limit FIDO U2F to Secure Contexts r?ttaubert r?smaug draft
J.C. Jones <jjones@mozilla.com> - Wed, 13 Dec 2017 17:02:38 -0600 - rev 711875
Push 93185 by bmo:jjones@mozilla.com at Thu, 14 Dec 2017 22:58:13 +0000
Bug 1247124 - Limit FIDO U2F to Secure Contexts r?ttaubert r?smaug Use the [SecureContext] webidl notation to hide the powerful "window.u2f" feature and its interface when not loaded in a secure context. MozReview-Commit-ID: 7en8b5ieI85
2520da3acc408fd5b020f5004f8e3f6058fa3720: Bug 1247124 - Limit FIDO U2F to Secure Contexts r?qdot r?ttaubert r?smaug draft
J.C. Jones <jjones@mozilla.com> - Wed, 13 Dec 2017 17:02:38 -0600 - rev 711867
Push 93181 by bmo:jjones@mozilla.com at Thu, 14 Dec 2017 22:17:33 +0000
Bug 1247124 - Limit FIDO U2F to Secure Contexts r?qdot r?ttaubert r?smaug Use the [SecureContext] webidl notation to hide the powerful "window.u2f" feature and its interface when not loaded in a secure context. MozReview-Commit-ID: 7en8b5ieI85
8e3f5e278310b969f2bb5c5adb33d81d12bece45: Bug 1407789 - Prohibit iframes for Credential Management r?baku r?ttaubert draft
J.C. Jones <jjones@mozilla.com> - Thu, 12 Oct 2017 18:18:39 -0700 - rev 711824
Push 93163 by bmo:jjones@mozilla.com at Thu, 14 Dec 2017 20:47:17 +0000
Bug 1407789 - Prohibit iframes for Credential Management r?baku r?ttaubert Credential Management defines a parameter `sameOriginWithAncestors` which is set true if the responsible document is not either in a top-level browsing context, or is in a nested context whose heirarchy is all loaded from the same origin as the top-level context [1][2]. The individual credential types of CredMan can use this flag to make decisions on whether to error or not. Our Credential Management implementation right now is a shim to Web Authentication, which says that if `sameOriginWithAncestors` is false, return `"NotAllowedError"`. This ensures that https://webauthn.bin.coffee/iframe.html works, but the cross-origin https://u2f.bin.coffee/iframe-webauthn.html does not. baku: Please check my logic for IsNotInAFrameOrIsSameOrigin - it appears to work, but I'm no DOM expert! [1] https://w3c.github.io/webappsec-credential-management/#algorithm-request [2] https://w3c.github.io/webappsec-credential-management/#algorithm-create [3] https://w3c.github.io/webauthn/#createCredential [4] https://w3c.github.io/webauthn/#getAssertion MozReview-Commit-ID: KIyakgl0kGv