Skip to content
This repository has been archived by the owner on May 3, 2022. It is now read-only.

Don't expose "std:kv-storage" in the module map in insecure contexts #53

Closed
wants to merge 3 commits into from

Conversation

littledan
Copy link

@littledan littledan commented Mar 2, 2019

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

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 domenic added the needs tests Pull request is waiting on tests before merging label Mar 5, 2019
Copy link
Collaborator

@domenic domenic left a 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.

spec.bs Outdated Show resolved Hide resolved
domenic and others added 2 commits March 5, 2019 19:54
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
@domenic domenic closed this in 13ceeaf Jun 24, 2019
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.
Labels
needs tests Pull request is waiting on tests before merging
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants