Added [SecureContext] to the subtle attribute

Added [SecureContext] to the subtle attribute

Intent to remove: https://groups.google.com/a/chromium.org/d/msg/Blink-dev/ZD3NWqkk-bo/1txGi7hiBgAJ
Spec: https://w3c.github.io/webcrypto/Overview.html#crypto-interface

BUG=641526
Review-Url: https://codereview.chromium.org/2838603002
Cr-Commit-Position: refs/heads/master@{#467919}
Committed: https://chromium.googlesource.com/chromium/src/+/7d57a8fa0d13db4fcb178bb58bb9389fa7670d74

[andypaicu, 2017-04-24 13:28:12]

The CQ bit was checked by andypaicu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-24 13:28:33]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[andypaicu, 2017-04-24 13:48:52]

The CQ bit was checked by andypaicu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-24 13:49:16]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[andypaicu, 2017-04-24 13:49:33]

andypaicu@chromium.org changed reviewers:
+ mkwst@chromium.org

[Mike West, 2017-04-24 14:19:20]

mkwst@chromium.org changed reviewers:
+ rsleevi@chromium.org

[Mike West, 2017-04-24 14:19:22]

Thanks Andy! A few small comments inline.

+Ryan for tests. I'm not sure who can evaluate these, but spot-checking the
results looks like they're better than status quo. I'm happy to just stamp them
in this patch, as they're just renames from `.html` to `.https.html` in order to
move into a secure context, but it would be nice if someone who knows what the
expectations should look like could take a look at some point.

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/idlharness.https.html
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/idlharness.https.html:27:
request.open("GET", "WebCryptoAPI.idl");
I think you need to add `[SecureContext]` to this data file as well.

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/crypto/Crypto.idl (right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/crypto/Crypto.idl:36: [SecureContext] readonly
attribute SubtleCrypto subtle;
This should also let us remove a few other things:

1.  The `SecureContextCheck` enum from `ExecutionContext`, as I believe this API
is the only one that uses `kWebCryptoSecureContextCheck`. Since we'll now only
have one code-path, we can drop the enum entirely from the codebase.

2.  The `CanAccessWebCrypto` check from `SubtleCrypto.cpp` (you can replace it
with DCHECKs if you like, but I think we can just drop it entirely and rely on
the generated IDL checks).

3.  The `kSubtleCryptoOnlyStrictSecureContextCheckFailed` UseCounter enum value.

[Ryan Sleevi, 2017-04-24 14:24:31]

rsleevi@chromium.org changed reviewers:
+ eroman@chromium.org

[Ryan Sleevi, 2017-04-24 14:24:32]

I spot-checked some, but I'll add Eric just in case :)

[Mike West, 2017-04-24 14:34:05]

On 2017/04/24 at 14:24:32, rsleevi wrote:
> I spot-checked some, but I'll add Eric just in case :)

It's simplest to expand-all and then look for "FAIL". For instance "FAIL P-521
with null length assert_true: Derived correct bits expected true got false" in
`third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_ecdh_bits.https-expected.txt`
might mean that we don't implement that algorithm?

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/wrapKey_unwrapKey/test_wrapKey_unwrapKey.https-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/wrapKey_unwrapKey/test_wrapKey_unwrapKey.https-expected.txt:2:
FAIL WebCryptoAPI: wrapKey() and unwrapKey() Uncaught ReferenceError: run_test
is not defined
This seems broken?

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/wrapKey_unwrapKey/wrapKey_unwrapKey.https.js
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/wrapKey_unwrapKey/wrapKey_unwrapKey.https.js:1:
// Tests for wrapKey and unwrapKey round tripping
Does this need to be renamed? It seems to break the `wrapKey_unwrapKey` tests.

[commit-bot: I haz the power, 2017-04-24 14:55:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-24 14:55:02]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Ryan Sleevi, 2017-04-24 19:54:20]

Did a bunch of extra spot checks to be sure, and documented for future CL
archivists.

Eric, one question for you below (your name is tagged at
https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
) to see what you think

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt:8:
FAIL Derived key of type name: AES-CBC length: 192  using short derivedKey,
normal salt, SHA-384, with normal info assert_unreached: deriveKey failed with
error OperationError: 192-bit AES keys are not supported Reached unreachable
code
The "reached unreachable code" comes from
https://github.com/w3c/web-platform-tests/blob/master/WebCryptoAPI/derive_bit...
which is expected (we don't support 192-bit)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt:20:
FAIL Derived key of type name: AES-CTR length: 192  using short derivedKey,
normal salt, SHA-384, with normal info assert_unreached: deriveKey failed with
error OperationError: 192-bit AES keys are not supported Reached unreachable
code
This is OK (see above)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt:32:
FAIL Derived key of type name: AES-GCM length: 192  using short derivedKey,
normal salt, SHA-384, with normal info assert_unreached: deriveKey failed with
error OperationError: 192-bit AES keys are not supported Reached unreachable
code
This is OK (see above)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt:44:
FAIL Derived key of type name: AES-KW length: 192  using short derivedKey,
normal salt, SHA-384, with normal info assert_unreached: deriveKey failed with
error OperationError: 192-bit AES keys are not supported Reached unreachable
code
This is OK (see above)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt:70:
FAIL short derivedKey, normal salt, SHA-384, with normal info with null length
assert_unreached: null length should have thrown an TypeError Reached
unreachable code
https://bugs.chromium.org/p/chromium/issues/detail?id=441033

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt:71:
FAIL short derivedKey, normal salt, SHA-384, with normal info with non-multiple
of 8 length assert_unreached: non-multiple of 8 length should have thrown an
OperationError Reached unreachable code
Eric: Do you know what's up here?

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt:81:
FAIL Derived key of type name: AES-CBC length: 192  using short derivedKey,
normal salt, SHA-384, with empty info assert_unreached: deriveKey failed with
error OperationError: 192-bit AES keys are not supported Reached unreachable
code
This is OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt:93:
FAIL Derived key of type name: AES-CTR length: 192  using short derivedKey,
normal salt, SHA-384, with empty info assert_unreached: deriveKey failed with
error OperationError: 192-bit AES keys are not supported Reached unreachable
code
This is OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/encrypt_decrypt/test_aes_cbc.https-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/encrypt_decrypt/test_aes_cbc.https-expected.txt:3:
FAIL importKey step: AES-CBC 192-bit key assert_unreached: importKey failed for
AES-CBC 192-bit key Reached unreachable code
This is OK (192-bit isn't supported)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/encrypt_decrypt/test_aes_cbc.https-expected.txt:6:
FAIL importKey step: AES-CBC 192-bit key with altered plaintext
assert_unreached: importKey failed for AES-CBC 192-bit key Reached unreachable
code
This is OK (192-bit isn't supported)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/encrypt_decrypt/test_aes_cbc.https-expected.txt:9:
FAIL importKey step for decryption: AES-CBC 192-bit key assert_unreached:
importKey failed for AES-CBC 192-bit key Reached unreachable code
This is OK (192-bit isn't supported)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/encrypt_decrypt/test_aes_cbc.https-expected.txt:12:
FAIL importKey step for decryption: AES-CBC 192-bit key with altered ciphertext
assert_unreached: importKey failed for AES-CBC 192-bit key Reached unreachable
code
This is OK (192-bit isn't supported)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/encrypt_decrypt/test_aes_cbc.https-expected.txt:15:
FAIL importKey step: AES-CBC 192-bit key without encrypt usage assert_unreached:
importKey failed for AES-CBC 192-bit key Reached unreachable code
This is OK (192-bit isn't supported)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/encrypt_decrypt/test_aes_cbc.https-expected.txt:21:
FAIL importKey step: AES-CBC 192-bit key without decrypt usage assert_unreached:
importKey failed for AES-CBC 192-bit key Reached unreachable code
This is OK (192-bit isn't supported)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/encrypt_decrypt/test_aes_cbc.https-expected.txt:26:
FAIL importKey step: AES-CBC 192-bit key, 192-bit IV assert_unreached: importKey
failed for AES-CBC 192-bit key, 192-bit IV Reached unreachable code
This is OK (192-bit isn't supported)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/encrypt_decrypt/test_aes_cbc.https-expected.txt:32:
FAIL importKey step: decryption AES-CBC 192-bit key, 192-bit IV
assert_unreached: importKey failed for AES-CBC 192-bit key, 192-bit IV Reached
unreachable code
This is OK (192-bit isn't supported)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/encrypt_decrypt/test_aes_cbc.https-expected.txt:40:
FAIL importKey step: decryption AES-CBC 192-bit key, inconsistentPadChars
assert_unreached: importKey failed for AES-CBC 192-bit key, inconsistentPadChars
Reached unreachable code
This is OK (192-bit isn't supported)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-CTR.https-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-CTR.https-expected.txt:65:
FAIL Success: generateKey({length: 192, name: AES-CTR}, true, [encrypt, decrypt,
wrapKey, unwrapKey, encrypt, decrypt, wrapKey, unwrapKey]) assert_unreached:
Threw an unexpected error: OperationError: 192-bit AES keys are not supported
Reached unreachable code
These are all OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-CTR.https-expected.txt:161:
FAIL Success: generateKey({length: 192, name: aes-ctr}, true, [encrypt, decrypt,
wrapKey, unwrapKey, encrypt, decrypt, wrapKey, unwrapKey]) assert_unreached:
Threw an unexpected error: OperationError: 192-bit AES keys are not supported
Reached unreachable code
These are all OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-CTR.https-expected.txt:257:
FAIL Success: generateKey({length: 192, name: Aes-ctr}, true, [encrypt, decrypt,
wrapKey, unwrapKey, encrypt, decrypt, wrapKey, unwrapKey]) assert_unreached:
Threw an unexpected error: OperationError: 192-bit AES keys are not supported
Reached unreachable code
These are all OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-GCM.https-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-GCM.https-expected.txt:65:
FAIL Success: generateKey({length: 192, name: AES-GCM}, true, [encrypt, decrypt,
wrapKey, unwrapKey, encrypt, decrypt, wrapKey, unwrapKey]) assert_unreached:
Threw an unexpected error: OperationError: 192-bit AES keys are not supported
Reached unreachable code
These are all OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-GCM.https-expected.txt:161:
FAIL Success: generateKey({length: 192, name: aes-gcm}, true, [encrypt, decrypt,
wrapKey, unwrapKey, encrypt, decrypt, wrapKey, unwrapKey]) assert_unreached:
Threw an unexpected error: OperationError: 192-bit AES keys are not supported
Reached unreachable code
These are all OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-GCM.https-expected.txt:257:
FAIL Success: generateKey({length: 192, name: Aes-gcm}, true, [encrypt, decrypt,
wrapKey, unwrapKey, encrypt, decrypt, wrapKey, unwrapKey]) assert_unreached:
Threw an unexpected error: OperationError: 192-bit AES keys are not supported
Reached unreachable code
These are all OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-KW.https-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-KW.https-expected.txt:17:
FAIL Success: generateKey({length: 192, name: AES-KW}, true, [wrapKey,
unwrapKey, wrapKey, unwrapKey]) assert_unreached: Threw an unexpected error:
OperationError: 192-bit AES keys are not supported Reached unreachable code
These are all OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-KW.https-expected.txt:41:
FAIL Success: generateKey({length: 192, name: aes-kw}, true, [wrapKey,
unwrapKey, wrapKey, unwrapKey]) assert_unreached: Threw an unexpected error:
OperationError: 192-bit AES keys are not supported Reached unreachable code
These are all OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/generateKey/test_successes_AES-KW.https-expected.txt:65:
FAIL Success: generateKey({length: 192, name: Aes-kw}, true, [wrapKey,
unwrapKey, wrapKey, unwrapKey]) assert_unreached: Threw an unexpected error:
OperationError: 192-bit AES keys are not supported Reached unreachable code
These are all OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/import_export/test_symmetric_importKey.https-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/import_export/test_symmetric_importKey.https-expected.txt:25:
FAIL Good parameters: 192 bits (jwk, {alg: A192CTR, k:
AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcY, kty: oct}, {name: AES-CTR}, false, [decrypt])
assert_unreached: Threw an unexpected error: OperationError: 192-bit AES keys
are not supported Reached unreachable code
All of these are OK (192-bit isn't supported)

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/import_export/test_symmetric_importKey.https-expected.txt:61:
FAIL Good parameters: 192 bits (jwk, {alg: A192CBC, k:
AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcY, kty: oct}, {name: AES-CBC}, false, [decrypt])
assert_unreached: Threw an unexpected error: OperationError: 192-bit AES keys
are not supported Reached unreachable code
All of these are OK

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/import_export/test_symmetric_importKey.https-expected.txt:97:
FAIL Good parameters: 192 bits (jwk, {alg: A192GCM, k:
AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcY, kty: oct}, {name: AES-GCM}, false, [decrypt])
assert_unreached: Threw an unexpected error: OperationError: 192-bit AES keys
are not supported Reached unreachable code
These

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/import_export/test_symmetric_importKey.https-expected.txt:133:
FAIL Good parameters: 192 bits (jwk, {alg: A192KW, k:
AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcY, kty: oct}, {name: AES-KW}, false, [unwrapKey])
assert_unreached: Threw an unexpected error: OperationError: 192-bit AES keys
are not supported Reached unreachable code
Still OK

[eroman, 2017-04-24 22:49:34]

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt:71:
FAIL short derivedKey, normal salt, SHA-384, with normal info with non-multiple
of 8 length assert_unreached: non-multiple of 8 length should have thrown an
OperationError Reached unreachable code
On 2017/04/24 19:54:19, Ryan Sleevi wrote:
> Eric: Do you know what's up here?

tl;dr -- thanks Ryan, I will follow-up on this!

What is happening here is the test calls deriveBits() for HKDF with a length of
44.

* The W3C test expects the implementation to throw an OperationError
* However Chrome allows it (and truncates the result by zeroing the unused
bits).

Chrome's implementation of HKDF predates its addition to the Web Crypto spec,
and unfortunately I didn't notice the difference when reviewing  its addition to
the spec in https://bugs.chromium.org/p/chromium/issues/detail?id=642045.

In fact, from what I can tell Web Crypto spec's wording is wrong - it describes
passing "length" as the "L" parameter to RFC 5869 expand step. However Web
Crypto's "length" parameter is in bits, whereas RFC 5869's "L" parameter is in
octets (this confusion is the result of its predecessor, HKDF-CTR having been in
bits and failing to reflect this when updating). The intent surely is to convert
to octets (and raise an error if the input is not a multiple of 8 as per this
test expectation).

In general, it is unfortunate that we couldn't align on a consistent policy for
how deriveBits() works for non-multiple of 8 bits, as was raised in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27403.

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/idlharness-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/idlharness-expected.txt:41:
FAIL SubtleCrypto must be primary interface of crypto.subtle assert_equals:
wrong typeof object expected "object" but got "undefined"
These tests shouldn't be failing.

[eroman, 2017-04-24 23:07:34]

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/derive_bits_keys/test_hkdf.https-expected.txt:71:
FAIL short derivedKey, normal salt, SHA-384, with normal info with non-multiple
of 8 length assert_unreached: non-multiple of 8 length should have thrown an
OperationError Reached unreachable code
On 2017/04/24 22:49:34, eroman wrote:
> On 2017/04/24 19:54:19, Ryan Sleevi wrote:
> > Eric: Do you know what's up here?
> 
> tl;dr -- thanks Ryan, I will follow-up on this!
> 
> What is happening here is the test calls deriveBits() for HKDF with a length
of
> 44.
> 
> * The W3C test expects the implementation to throw an OperationError
> * However Chrome allows it (and truncates the result by zeroing the unused
> bits).
> 
> Chrome's implementation of HKDF predates its addition to the Web Crypto spec,
> and unfortunately I didn't notice the difference when reviewing  its addition
to
> the spec in https://bugs.chromium.org/p/chromium/issues/detail?id=642045.
> 
> In fact, from what I can tell Web Crypto spec's wording is wrong - it
describes
> passing "length" as the "L" parameter to RFC 5869 expand step. However Web
> Crypto's "length" parameter is in bits, whereas RFC 5869's "L" parameter is in
> octets (this confusion is the result of its predecessor, HKDF-CTR having been
in
> bits and failing to reflect this when updating). The intent surely is to
convert
> to octets (and raise an error if the input is not a multiple of 8 as per this
> test expectation).
> 
> In general, it is unfortunate that we couldn't align on a consistent policy
for
> how deriveBits() works for non-multiple of 8 bits, as was raised in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27403.

FTR: https://bugs.chromium.org/p/chromium/issues/detail?id=714847

[andypaicu, 2017-04-25 10:52:56]

The CQ bit was checked by andypaicu@chromium.org to run a CQ dry run

[andypaicu, 2017-04-25 10:53:10]

On 2017/04/24 at 14:19:22, mkwst wrote:
> Thanks Andy! A few small comments inline.
> 
> +Ryan for tests. I'm not sure who can evaluate these, but spot-checking the
results looks like they're better than status quo. I'm happy to just stamp them
in this patch, as they're just renames from `.html` to `.https.html` in order to
move into a secure context, but it would be nice if someone who knows what the
expectations should look like could take a look at some point.
> 
>
https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
> File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/idlharness.https.html
(right):
> 
>
https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
>
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/idlharness.https.html:27:
request.open("GET", "WebCryptoAPI.idl");
> I think you need to add `[SecureContext]` to this data file as well.
> 
>
https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/modules/crypto/Crypto.idl (right):
> 
>
https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Sour...
> third_party/WebKit/Source/modules/crypto/Crypto.idl:36: [SecureContext]
readonly attribute SubtleCrypto subtle;
> This should also let us remove a few other things:
> 
> 1.  The `SecureContextCheck` enum from `ExecutionContext`, as I believe this
API is the only one that uses `kWebCryptoSecureContextCheck`. Since we'll now
only have one code-path, we can drop the enum entirely from the codebase.
> 
> 2.  The `CanAccessWebCrypto` check from `SubtleCrypto.cpp` (you can replace it
with DCHECKs if you like, but I think we can just drop it entirely and rely on
the generated IDL checks).
> 
> 3.  The `kSubtleCryptoOnlyStrictSecureContextCheckFailed` UseCounter enum
value.

Done

[commit-bot: I haz the power, 2017-04-25 10:53:11]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[andypaicu, 2017-04-25 10:53:59]

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/idlharness-expected.txt
(right):

https://codereview.chromium.org/2838603002/diff/10001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/WebCryptoAPI/idlharness-expected.txt:41:
FAIL SubtleCrypto must be primary interface of crypto.subtle assert_equals:
wrong typeof object expected "object" but got "undefined"
On 2017/04/24 at 22:49:34, eroman wrote:
> These tests shouldn't be failing.

This change is to make subtle be only available for secure contexts. This test
is ran on an non-secure context so it does not see crypto.subtle. I've added
another identical test on https and the tests pass on that one so I think it's
ok.

[Mike West, 2017-04-25 11:14:15]

LGTM, as eroman@ filed bugs on the test expectations that aren't expected. :)

Thanks for sifting through this with us, Andy!

[andypaicu, 2017-04-25 11:24:51]

On 2017/04/25 at 11:14:15, mkwst wrote:
> LGTM, as eroman@ filed bugs on the test expectations that aren't expected. :)
> 
> Thanks for sifting through this with us, Andy!

Thanks Mike,

Eric or Ryan, could I also get an LGTM from either of you?

[commit-bot: I haz the power, 2017-04-25 12:40:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-25 12:41:00]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[andypaicu, 2017-04-25 14:03:41]

The CQ bit was checked by andypaicu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-25 14:03:55]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ryan Sleevi, 2017-04-25 14:52:50]

lgtm

[eroman, 2017-04-25 15:24:19]

lgtm, thanks!

[commit-bot: I haz the power, 2017-04-25 16:10:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-25 16:10:28]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[andypaicu, 2017-04-26 14:05:37]

The CQ bit was checked by andypaicu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-26 14:06:06]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-26 15:35:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-26 15:35:52]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[andypaicu, 2017-04-27 08:23:01]

The CQ bit was checked by andypaicu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-27 08:23:13]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-27 09:26:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-27 09:26:55]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[andypaicu, 2017-04-27 10:39:46]

The CQ bit was checked by andypaicu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-27 10:40:04]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-27 13:09:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-27 13:09:39]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[andypaicu, 2017-04-28 06:18:55]

The CQ bit was checked by andypaicu@chromium.org

[andypaicu, 2017-04-28 06:18:57]

The patchset sent to the CQ was uploaded after l-g-t-m from mkwst@chromium.org,
eroman@chromium.org, rsleevi@chromium.org
Link to the patchset: https://codereview.chromium.org/2838603002/#ps60001
(title: "Magic test starts doing differnt things out of the blue. Need to handle
this properly. Avada Kedavr…")

[commit-bot: I haz the power, 2017-04-28 06:19:13]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-28 06:28:00]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1493360335659720,
"parent_rev": "18ec3f9860a0b3069fc6f32a28fd48b158e1f409", "commit_rev":
"7d57a8fa0d13db4fcb178bb58bb9389fa7670d74"}

[commit-bot: I haz the power, 2017-04-28 06:28:10]

Description was changed from

==========
Added [SecureContext] to the subtle attribute

Intent to remove:
https://groups.google.com/a/chromium.org/d/msg/Blink-dev/ZD3NWqkk-bo/1txGi7hi...
Spec: https://w3c.github.io/webcrypto/Overview.html#crypto-interface

BUG=641526
==========

to

==========
Added [SecureContext] to the subtle attribute

Intent to remove:
https://groups.google.com/a/chromium.org/d/msg/Blink-dev/ZD3NWqkk-bo/1txGi7hi...
Spec: https://w3c.github.io/webcrypto/Overview.html#crypto-interface

BUG=641526

Review-Url: https://codereview.chromium.org/2838603002
Cr-Commit-Position: refs/heads/master@{#467919}
Committed:
https://chromium.googlesource.com/chromium/src/+/7d57a8fa0d13db4fcb178bb58bb9...
==========

[commit-bot: I haz the power, 2017-04-28 06:28:17]

Committed patchset #7 (id:60001) as
https://chromium.googlesource.com/chromium/src/+/7d57a8fa0d13db4fcb178bb58bb9...

[jeffcarp, 2017-04-28 19:57:29]

On 2017/04/28 at 06:28:17, commit-bot wrote:
> Committed patchset #7 (id:60001) as
https://chromium.googlesource.com/chromium/src/+/7d57a8fa0d13db4fcb178bb58bb9...

An upstream PR in web-platform-tests was created for this CL but the Travis CI
results were unstable on Firefox, causing the PR not to be merged:
https://github.com/w3c/web-platform-tests/pull/5730

To resolve the issue we'll need to work together to patch the PR (or another
option is creating a new PR).

[eroman, 2017-05-03 00:45:49]

Andy, could you take a look at resolving the upstreaming of the .https renames?
(See Jeff Carpenter's comment)

The problem now is that the automated wpt-import is re-importing the upstream
(non-https) version of the tests, and then automatically rebasing everything to
failures.

... which is a notable regression from your changed, which fixed the tests to
actually run properly.

Cheers.

[andypaicu, 2017-05-03 07:16:01]

On 2017/05/03 at 00:45:49, eroman wrote:
> Andy, could you take a look at resolving the upstreaming of the .https
renames? (See Jeff Carpenter's comment)
> 
> The problem now is that the automated wpt-import is re-importing the upstream
(non-https) version of the tests, and then automatically rebasing everything to
failures.
> 
> ... which is a notable regression from your changed, which fixed the tests to
actually run properly.
> 
> Cheers.

Hi Eric,

Yes, I have been looking into the upstream tests and have talked with Jeff, the
failure log does not give very good hints as to what is wrong so we have
employed the help of people more familiar with firefox and testharness.

Perhaps we can [Skip] this whole folder for now until the upstream PR gets
merged?

[eroman, 2017-05-03 16:30:33]

Thanks a lot for following up on that!

Skipping the tests for now sounds like a good plan then.

(We have other test coverage, that historically has been good at catching
regressions, so I am not worried if we have to skip for O(weeks)).

[andypaicu, 2017-05-04 13:00:09]

On 2017/05/03 at 16:30:33, eroman wrote:
> Thanks a lot for following up on that!
> 
> Skipping the tests for now sounds like a good plan then.
> 
> (We have other test coverage, that historically has been good at catching
regressions, so I am not worried if we have to skip for O(weeks)).

I was about to raise a bug and submit a CL but
https://github.com/w3c/web-platform-tests/pull/5730 got updated and there's no
need anymore:

The PR has been merged manually as it was not the cause of the discovered issue.
Things should stop breaking now when re-importing.

[eroman, 2017-05-04 17:33:40]

wohoo!