This repository has been archived by the owner on May 3, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 18
Don't expose "std:kv-storage" in the module map in insecure contexts #53
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In WebIDL, the [SecureContext] extended attribute does not cause exceptions to be thrown when something is in an insecure context, but rather causes objects or methods to be entirely missing. This patch does the same for the "std:kv-storage" module.
domenic
approved these changes
Mar 5, 2019
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a reasonable change to me. I added a suggested phrasing change but probably also need to tweak the anchors block to make it compile.
Note to self: this can be tested by having a module with side effects that imports std:kv-storage, and seeing if those side effects happen or not.
I'll work on pushing this over the finish line with tests and final spec text.
Co-Authored-By: littledan <[email protected]>
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jun 21, 2019
Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jun 24, 2019
Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jul 2, 2019
Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jul 3, 2019
Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86
aarongable
pushed a commit
to chromium/chromium
that referenced
this pull request
Jul 15, 2019
Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1670572 Reviewed-by: Hiroshige Hayashizaki <[email protected]> Reviewed-by: Joshua Bell <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#677454}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jul 15, 2019
Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1670572 Reviewed-by: Hiroshige Hayashizaki <[email protected]> Reviewed-by: Joshua Bell <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#677454}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jul 16, 2019
Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1670572 Reviewed-by: Hiroshige Hayashizaki <[email protected]> Reviewed-by: Joshua Bell <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#677454}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this pull request
Jul 24, 2019
…tion and expand tests, a=testonly Automatic update from web-platform-tests KV Storage: tweak secure context restriction and expand tests Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1670572 Reviewed-by: Hiroshige Hayashizaki <[email protected]> Reviewed-by: Joshua Bell <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#677454} -- wpt-commits: b3a9dd55d31874e8f2d197b4b958c0dac96ea844 wpt-pr: 17424
xeonchen
pushed a commit
to xeonchen/gecko
that referenced
this pull request
Jul 25, 2019
…tion and expand tests, a=testonly Automatic update from web-platform-tests KV Storage: tweak secure context restriction and expand tests Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1670572 Reviewed-by: Hiroshige Hayashizaki <[email protected]> Reviewed-by: Joshua Bell <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#677454} -- wpt-commits: b3a9dd55d31874e8f2d197b4b958c0dac96ea844 wpt-pr: 17424
natechapin
pushed a commit
to natechapin/wpt
that referenced
this pull request
Aug 23, 2019
Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1670572 Reviewed-by: Hiroshige Hayashizaki <[email protected]> Reviewed-by: Joshua Bell <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#677454}
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-comments-removed
that referenced
this pull request
Oct 4, 2019
…tion and expand tests, a=testonly Automatic update from web-platform-tests KV Storage: tweak secure context restriction and expand tests Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1670572 Reviewed-by: Hiroshige Hayashizaki <hiroshigechromium.org> Reviewed-by: Joshua Bell <jsbellchromium.org> Commit-Queue: Domenic Denicola <domenicchromium.org> Cr-Commit-Position: refs/heads/master{#677454} -- wpt-commits: b3a9dd55d31874e8f2d197b4b958c0dac96ea844 wpt-pr: 17424 UltraBlame original commit: 81bbfa205f27cb1996d5843bcbf58cc98863012d
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified
that referenced
this pull request
Oct 4, 2019
…tion and expand tests, a=testonly Automatic update from web-platform-tests KV Storage: tweak secure context restriction and expand tests Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1670572 Reviewed-by: Hiroshige Hayashizaki <hiroshigechromium.org> Reviewed-by: Joshua Bell <jsbellchromium.org> Commit-Queue: Domenic Denicola <domenicchromium.org> Cr-Commit-Position: refs/heads/master{#677454} -- wpt-commits: b3a9dd55d31874e8f2d197b4b958c0dac96ea844 wpt-pr: 17424 UltraBlame original commit: 81bbfa205f27cb1996d5843bcbf58cc98863012d
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified-and-comments-removed
that referenced
this pull request
Oct 4, 2019
…tion and expand tests, a=testonly Automatic update from web-platform-tests KV Storage: tweak secure context restriction and expand tests Recent discussions on the KV Storage spec (WICG/kv-storage#53, WICG/kv-storage#68) have decided on a slightly different model for restricting modules to secure contexts, that is based on preventing them from entering the module map, instead of throwing an error at module evaluation time. This is mostly observably the same, with a few small differences: * The error type changes from DOMException "SecurityError" to TypeError. This CL updates the implementation's runtime check, and all associated tests, to match the new error type. * Not being present in the module map means module graph initialization fails earlier, preventing any side effects from earlier modules in the graph from being evaluated. This is tested in the new WPT kv-storage/secure-context/side-effects.html, which we fail for now. * Not being present in the module map means that import map failover works. This is is tested in the new WPT kv-storage/secure-context/import-maps.html, which we fail for now. https://crbug.com/977470 tracks the infrastructure work necessary to move from a runtime check to selectively filling the module map, which will allow us to pass the two newly-added tests. BUG=977470 Change-Id: I9371400e9beed5be4ed5fbb0c94747a7bc0b3e86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1670572 Reviewed-by: Hiroshige Hayashizaki <hiroshigechromium.org> Reviewed-by: Joshua Bell <jsbellchromium.org> Commit-Queue: Domenic Denicola <domenicchromium.org> Cr-Commit-Position: refs/heads/master{#677454} -- wpt-commits: b3a9dd55d31874e8f2d197b4b958c0dac96ea844 wpt-pr: 17424 UltraBlame original commit: 81bbfa205f27cb1996d5843bcbf58cc98863012d
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In WebIDL, the [SecureContext] extended attribute does not cause
exceptions to be thrown when something is in an insecure context,
but rather causes objects or methods to be entirely missing. This
patch does the same for the "std:kv-storage" module.
Preview | Diff