172758 2017-05-31 09:01:54 -0700 [GTK] Enable SUBTLE_CRYPTO in GTK+ releases 2017-09-19 12:03:47 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=177180 P2 Normal --- 1 zan webkit-unassigned aperez bugs-noreply cgarcia clopez jbicha jiewen_tan mcatanzaro oldest_to_newest 1314179 0 zan 2017-05-31 09:01:54 -0700 There's been discussions to enable the SUBTLE_CRYPTO (i.e. the WebCrypto API support) already in WebKitGTK+ releases. However, we also said that we'd prefer to use something like ENABLE_WEB_CRYPTO as the configuration flag, instead of the current ENABLE_SUBTLE_CRYPTO. What I don't know is how to execute this -- do we want to go out and propose changing ENABLE_SUBTLE_CRYPTO to ENABLE_WEB_CRYPTO throughout the code, or do we make an additional ENABLE_WEB_CRYPTO CMake option that aliases the ENABLE_SUBTLE_CRYPTO one? 1314549 1 cgarcia 2017-05-31 23:19:27 -0700 I think I would just rename the SUBTLE_CRYPTO as WEB_CRYPTO. 1314558 2 jiewen_tan 2017-06-01 01:11:36 -0700 (In reply to Carlos Garcia Campos from comment #1) > I think I would just rename the SUBTLE_CRYPTO as WEB_CRYPTO. That's not right. WebCrypto refers to the whole Crypto Interface while SubtleCrypto refers only to the SubtleCrypto interface. 1314609 3 mcatanzaro 2017-06-01 07:54:56 -0700 We can also keep both flags and only expose WEB_CRYPTO as public. (Exposing both is too much configurability.) 1314758 4 aperez 2017-06-01 12:10:00 -0700 (In reply to Michael Catanzaro from comment #3) > We can also keep both flags and only expose WEB_CRYPTO as public. (Exposing > both is too much configurability.) This is probably the path of least resistance, I'd go with this. 1314767 5 mcatanzaro 2017-06-01 12:38:05 -0700 Well the WEB_CRYPTO flag does not currently exist, so some work is required to figure out which parts of the API are the SubtleCrypto portions and which are higher-level. And then we're stuck with two flags that we expect will always be OFF or ON together; I doubt anybody would be interested in supporting subtle crypto without the rest of WebCrypto. So it doesn't seem like a clear choice to me. 1332289 6 cgarcia 2017-07-26 01:45:26 -0700 Do we really need a public build option? Can't we just enable current build options unconditionally? 1332364 7 mcatanzaro 2017-07-26 09:20:35 -0700 (In reply to Carlos Garcia Campos from comment #6) > Do we really need a public build option? Can't we just enable current build > options unconditionally? I think we can make it unconditional. Check the version of gcrypt available in Ubuntu 16.04 against our dependencies policy. It's probably fine. On that note, we can probably remove more options now, and e.g. require libhyphen etc. 1335684 8 cgarcia 2017-08-05 02:51:57 -0700 Could we fix this before the next release (next week)? I don't mind how, but I want this enabled by default in 2.18 and we are about to branch. 1335943 9 mcatanzaro 2017-08-07 07:08:20 -0700 Today is supposed to be feature freeze. I would say it's missed the boat for 2.18 at this point. But it's your call... if we're going to enable it, though, let's do so *now*. 1335950 10 cgarcia 2017-08-07 08:13:44 -0700 (In reply to Michael Catanzaro from comment #9) > Today is supposed to be feature freeze. I would say it's missed the boat for > 2.18 at this point. But it's your call... if we're going to enable it, > though, let's do so *now*. Yes, I'll branch and release tomorrow or on Wednesday. The thing is how to enable this, let's just find a good name and enable whatever builds flags are needed. 1335955 11 mcatanzaro 2017-08-07 08:25:30 -0700 (In reply to Jiewen Tan from comment #2) > That's not right. WebCrypto refers to the whole Crypto Interface while > SubtleCrypto refers only to the SubtleCrypto interface. I don't understand why it's not right. All of SubtleCrypto is part of WebCrypto, so using the WebCrypto flag should be just fine, right? But using a SubtleCrypto flag to guard other WebCrypto features would not be right. Have we really failed to implement any WebCrypto besides the SubtleCrypto interface, or do I misunderstand something? 1336401 12 zan 2017-08-08 01:01:44 -0700 (In reply to Michael Catanzaro from comment #11) > (In reply to Jiewen Tan from comment #2) > > That's not right. WebCrypto refers to the whole Crypto Interface while > > SubtleCrypto refers only to the SubtleCrypto interface. > > I don't understand why it's not right. All of SubtleCrypto is part of > WebCrypto, so using the WebCrypto flag should be just fine, right? But using > a SubtleCrypto flag to guard other WebCrypto features would not be right. > Have we really failed to implement any WebCrypto besides the SubtleCrypto > interface, or do I misunderstand something? SUBTLE_CRYPTO covers a subset of the Web Crypto API spec, the one that's exposed through `window.crypto.subtle`. There's also `window.crypto.getRandomValues()` that's not covered by SUBTLE_CRYPTO. https://www.w3.org/TR/WebCryptoAPI/#crypto-interface SUBTLE_CRYPTO does expose the prefixed (and to-be-deprecated) `window.crypto.webkitSubtle` interface. Most of that is not implemented. 1336402 13 zan 2017-08-08 01:05:48 -0700 IMO we don't need an additional flag. The existing one should be turned on unconditionally, but for it to work the libgcrypt dependency has to be of 1.7.0 version at minimum. The drawback is that at this point enabling SUBTLE_CRYPTO also exposes the prefixed WebKitSubtleCrypto interface, which would be deprecated in the future. But I don't remember this being a blocker in the past. 1336416 14 clopez 2017-08-08 02:19:54 -0700 (In reply to Zan Dobersek from comment #13) > IMO we don't need an additional flag. The existing one should be turned on > unconditionally, but for it to work the libgcrypt dependency has to be of > 1.7.0 version at minimum. > > The drawback is that at this point enabling SUBTLE_CRYPTO also exposes the > prefixed WebKitSubtleCrypto interface, which would be deprecated in the > future. But I don't remember this being a blocker in the past. Ubuntu 16.04 has libgcrypt 1.6.5. 1336443 15 mcatanzaro 2017-08-08 05:43:27 -0700 OK, so the only part of the WebCrypto API that is not SubtleCrypto is the get random numbers function? (In reply to Zan Dobersek from comment #13) > IMO we don't need an additional flag. The existing one should be turned on > unconditionally, but for it to work the libgcrypt dependency has to be of > 1.7.0 version at minimum. We have a distributor that wants to upgrade WebKit but isn't able to upgrade gcrypt for whatever reason (probably enterprise security policy). They have gcrypt 1.5.8. And anyway, Ubuntu having only 1.6.5 indicates this really must have a build flag. I would still expose a flag named ENABLE_WEB_CRYPTO flag and keep ENABLE_SUBTLE_CRYPTO private. ENABLE_SUBTLE_CRYPTO is fine to use in our code, if Jiewen doesn't want to rename it, but I still think it's too low-level to expose as a public option. We can make ENABLE_WEB_CRYPTO toggle ENABLE_SUBTLE_CRYPTO via a dependency. (In reply to Zan Dobersek from comment #13) > The drawback is that at this point enabling SUBTLE_CRYPTO also exposes the > prefixed WebKitSubtleCrypto interface, which would be deprecated in the > future. But I don't remember this being a blocker in the past. I don't really care. It would probably be better for web compatibility to match Apple anyway. 1336479 16 clopez 2017-08-08 08:14:16 -0700 (In reply to Michael Catanzaro from comment #15) > We have a distributor that wants to upgrade WebKit but isn't able to upgrade > gcrypt for whatever reason (probably enterprise security policy). They have > gcrypt 1.5.8. And anyway, Ubuntu having only 1.6.5 indicates this really > must have a build flag. I agree this should have a public build flag. I wonder if we should enable the flag by default now or not? If we enable it, that will mean the default build configuration won't be build-able on Ubuntu 16.04 anymore. However https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy doesn't say anything about the default configuration. 1336482 17 cgarcia 2017-08-08 08:19:48 -0700 (In reply to Carlos Alberto Lopez Perez from comment #16) > (In reply to Michael Catanzaro from comment #15) > > We have a distributor that wants to upgrade WebKit but isn't able to upgrade > > gcrypt for whatever reason (probably enterprise security policy). They have > > gcrypt 1.5.8. And anyway, Ubuntu having only 1.6.5 indicates this really > > must have a build flag. > > I agree this should have a public build flag. > > I wonder if we should enable the flag by default now or not? If we enable > it, that will mean the default build configuration won't be build-able on > Ubuntu 16.04 anymore. > However https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy doesn't > say anything about the default configuration. As long as old distros can just disable it, I don't think we should penalize users using newer versions. 1336483 18 cgarcia 2017-08-08 08:20:27 -0700 IIRC we want to enable this because it's required by popular web sites/apps. 1336485 19 aperez 2017-08-08 08:36:08 -0700 (In reply to Carlos Garcia Campos from comment #17) > (In reply to Carlos Alberto Lopez Perez from comment #16) > > (In reply to Michael Catanzaro from comment #15) > > > We have a distributor that wants to upgrade WebKit but isn't able to upgrade > > > gcrypt for whatever reason (probably enterprise security policy). They have > > > gcrypt 1.5.8. And anyway, Ubuntu having only 1.6.5 indicates this really > > > must have a build flag. > > > > I agree this should have a public build flag. > > > > I wonder if we should enable the flag by default now or not? If we enable > > it, that will mean the default build configuration won't be build-able on > > Ubuntu 16.04 anymore. > > However https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy doesn't > > say anything about the default configuration. > > As long as old distros can just disable it, I don't think we should penalize > users using newer versions. I agree with this. Let's use the wording of the policy to the advantage of our users and have the feature enabled by default. 1336667 20 mcatanzaro 2017-08-08 14:56:50 -0700 It should default to on. Ubuntu can just disable that option. 1336881 21 zan 2017-08-08 23:44:18 -0700 (In reply to Michael Catanzaro from comment #15) > OK, so the only part of the WebCrypto API that is not SubtleCrypto is the > get random numbers function? > Yes, but to alias ENABLE_SUBTLE_CRYPTO against a new ENABLE_WEB_CRYPTO option is still a bit misleading. 1336882 22 317683 cgarcia 2017-08-08 23:53:27 -0700 Created attachment 317683 Patch 1336891 23 cgarcia 2017-08-09 00:13:16 -0700 Committed r220445: <http://trac.webkit.org/changeset/220445> 1336925 24 clopez 2017-08-09 05:06:37 -0700 Done: * Debian Stable bot (on Jessie still): https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20Debian%20Stable%20%28Build%29 - Installed libgcrypt 1.7 from the jessie backports repository. * Ubuntu LTS Bot (16.04): https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20Ubuntu%20LTS%20%28Build%29 - Configured it to build with -DENABLE_WEB_CRYPTO=OFF via the environment variable BUILD_WEBKIT_ARGS supported by the script build-webkit. That way: * The default configuration of WebKitGTK+ remains build-able on Debian 8 (Jessie) (but you have to use a few packages from backports like clang-3.8 and newer libgcrypt) * The default configuration of WebKitGTK+ is not longer build-able on Ubuntu 16.04, but you can build without web crypto by simply passing -DENABLE_WEB_CRYPTO=OFF to CMake. This bot will test this to ensure no breakage happens with WEB_CRYPTO=OFF. 317683 2017-08-08 23:53:27 -0700 2017-08-09 00:02:23 -0700 Patch wk-web-crypto.diff text/plain 2730 cgarcia ZGlmZiAtLWdpdCBhL0NoYW5nZUxvZyBiL0NoYW5nZUxvZwppbmRleCAwZjE5MWFiYTJkOC4uMjVk ZDIxNmUzNGUgMTAwNjQ0Ci0tLSBhL0NoYW5nZUxvZworKysgYi9DaGFuZ2VMb2cKQEAgLTEsMyAr MSwxNCBAQAorMjAxNy0wOC0wOCAgQ2FybG9zIEdhcmNpYSBDYW1wb3MgIDxjZ2FyY2lhQGlnYWxp YS5jb20+CisKKyAgICAgICAgW0dUS10gRW5hYmxlIFNVQlRMRV9DUllQVE8gaW4gR1RLKyByZWxl YXNlcworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTcy NzU4CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgQWRk IEVOQUJMRV9XRUJfQ1JZUFRPIHB1YmxpYyBvcHRpb24gYW5kIG1ha2UgRU5BQkxFX1NVQlRMRV9D UllQVE8gZGVwZW5kIG9uIGl0LgorCisgICAgICAgICogU291cmNlL2NtYWtlL09wdGlvbnNHVEsu Y21ha2U6CisKIDIwMTctMDgtMDggIE1pY2hhZWwgQ2F0YW56YXJvICA8bWNhdGFuemFyb0BpZ2Fs aWEuY29tPgogCiAgICAgICAgIFtDTWFrZV0gUHJvcGVybHkgdGVzdCBpZiBjb21waWxlciBzdXBw b3J0cyBjb21waWxlciBmbGFncwpkaWZmIC0tZ2l0IGEvU291cmNlL2NtYWtlL09wdGlvbnNHVEsu Y21ha2UgYi9Tb3VyY2UvY21ha2UvT3B0aW9uc0dUSy5jbWFrZQppbmRleCBiMjkzNjM1MGYyMy4u YzE0ZTU4ODljZTggMTAwNjQ0Ci0tLSBhL1NvdXJjZS9jbWFrZS9PcHRpb25zR1RLLmNtYWtlCisr KyBiL1NvdXJjZS9jbWFrZS9PcHRpb25zR1RLLmNtYWtlCkBAIC04Nyw2ICs4Nyw3IEBAIFdFQktJ VF9PUFRJT05fREVGSU5FKEVOQUJMRV9QTFVHSU5fUFJPQ0VTU19HVEsyICJXaGV0aGVyIHRvIGJ1 aWxkIFdlYktpdFBsdWdpblByCiBXRUJLSVRfT1BUSU9OX0RFRklORShFTkFCTEVfUVVBUlRaX1RB UkdFVCAiV2hldGhlciB0byBlbmFibGUgc3VwcG9ydCBmb3IgdGhlIFF1YXJ0eiB3aW5kb3dpbmcg dGFyZ2V0LiIgUFVCTElDICR7R1RLM19TVVBQT1JUU19RVUFSVFp9KQogV0VCS0lUX09QVElPTl9E RUZJTkUoRU5BQkxFX1gxMV9UQVJHRVQgIldoZXRoZXIgdG8gZW5hYmxlIHN1cHBvcnQgZm9yIHRo ZSBYMTEgd2luZG93aW5nIHRhcmdldC4iIFBVQkxJQyAke0dUSzNfU1VQUE9SVFNfWDExfSkKIFdF QktJVF9PUFRJT05fREVGSU5FKEVOQUJMRV9XQVlMQU5EX1RBUkdFVCAiV2hldGhlciB0byBlbmFi bGUgc3VwcG9ydCBmb3IgdGhlIFdheWxhbmQgd2luZG93aW5nIHRhcmdldC4iIFBVQkxJQyAke0dU SzNfU1VQUE9SVFNfV0FZTEFORH0pCitXRUJLSVRfT1BUSU9OX0RFRklORShFTkFCTEVfV0VCX0NS WVBUTyAiV2hldGhlciB0byBlbmFibGUgc3VwcG9ydCBmb3IgV2ViIENyeXB0byBBUEkuIiBQVUJM SUMgT04pCiBXRUJLSVRfT1BUSU9OX0RFRklORShVU0VfTElCTk9USUZZICJXaGV0aGVyIHRvIGVu YWJsZSB0aGUgZGVmYXVsdCB3ZWIgbm90aWZpY2F0aW9uIGltcGxlbWVudGF0aW9uLiIgUFVCTElD IE9OKQogV0VCS0lUX09QVElPTl9ERUZJTkUoVVNFX0xJQkhZUEhFTiAiV2hldGhlciB0byBlbmFi bGUgdGhlIGRlZmF1bHQgYXV0b21hdGljIGh5cGhlbmF0aW9uIGltcGxlbWVudGF0aW9uLiIgUFVC TElDIE9OKQogV0VCS0lUX09QVElPTl9ERUZJTkUoVVNFX0xJQlNFQ1JFVCAiV2hldGhlciB0byBl bmFibGUgdGhlIHBlcnNpc3RlbnQgY3JlZGVudGlhbCBzdG9yYWdlIHVzaW5nIGxpYnNlY3JldC4i IFBVQkxJQyBPTikKQEAgLTEwNSw2ICsxMDYsNyBAQCBXRUJLSVRfT1BUSU9OX0RFUEVORChFTkFC TEVfQUNDRUxFUkFURURfMkRfQ0FOVkFTIEVOQUJMRV9PUEVOR0wpCiBXRUJLSVRfT1BUSU9OX0RF UEVORChFTkFCTEVfR0xFUzIgRU5BQkxFX09QRU5HTCkKIFdFQktJVF9PUFRJT05fREVQRU5EKEVO QUJMRV9QTFVHSU5fUFJPQ0VTU19HVEsyIEVOQUJMRV9YMTFfVEFSR0VUKQogV0VCS0lUX09QVElP Tl9ERVBFTkQoRU5BQkxFX1dFQkdMIEVOQUJMRV9PUEVOR0wpCitXRUJLSVRfT1BUSU9OX0RFUEVO RChFTkFCTEVfU1VCVExFX0NSWVBUTyBFTkFCTEVfV0VCX0NSWVBUTykKIFdFQktJVF9PUFRJT05f REVQRU5EKFVTRV9SRURJUkVDVEVEX1hDT01QT1NJVEVfV0lORE9XIEVOQUJMRV9PUEVOR0wpCiBX RUJLSVRfT1BUSU9OX0RFUEVORChVU0VfUkVESVJFQ1RFRF9YQ09NUE9TSVRFX1dJTkRPVyBFTkFC TEVfWDExX1RBUkdFVCkKIFdFQktJVF9PUFRJT05fREVQRU5EKFVTRV9HU1RSRUFNRVJfR0wgRU5B QkxFX09QRU5HTCkKQEAgLTE2OCw2ICsxNzAsNyBAQCBXRUJLSVRfT1BUSU9OX0RFRkFVTFRfUE9S VF9WQUxVRShFTkFCTEVfUkVNT1RFX0lOU1BFQ1RPUiBQUklWQVRFIE9OKQogV0VCS0lUX09QVElP Tl9ERUZBVUxUX1BPUlRfVkFMVUUoRU5BQkxFX1NNT09USF9TQ1JPTExJTkcgUFJJVkFURSBPTikK IFdFQktJVF9PUFRJT05fREVGQVVMVF9QT1JUX1ZBTFVFKEVOQUJMRV9VU0VSU0VMRUNUX0FMTCBQ UklWQVRFIE9OKQogV0VCS0lUX09QVElPTl9ERUZBVUxUX1BPUlRfVkFMVUUoRU5BQkxFX1VTRVJf TUVTU0FHRV9IQU5ETEVSUyBQUklWQVRFIE9OKQorV0VCS0lUX09QVElPTl9ERUZBVUxUX1BPUlRf VkFMVUUoRU5BQkxFX1NVQlRMRV9DUllQVE8gUFJJVkFURSBPTikKIFdFQktJVF9PUFRJT05fREVG QVVMVF9QT1JUX1ZBTFVFKEVOQUJMRV9WSURFT19UUkFDSyBQUklWQVRFIE9OKQogV0VCS0lUX09Q VElPTl9ERUZBVUxUX1BPUlRfVkFMVUUoRU5BQkxFX1dFQkdMIFBSSVZBVEUgT04pCiAK