166959 2017-01-11 18:36:06 -0800 [WebCrypto] WebCrypto API should be on top of SecureContext 2021-08-17 10:54:26 -0700 1 1 1 Unclassified WebKit WebCore Misc. WebKit Nightly Build Unspecified Unspecified RESOLVED DUPLICATE 227725 https://bugs.webkit.org/show_bug.cgi?id=173325 InRadar P2 Normal --- 158121 1 jiewen_tan dbates ap bfulgham buildbot cdumez dbates esprehn+autocc frederic.jacobs gsnedders jiewen_tan keith_miller kondapallykalyan mark.lam msaboff oliver saam webkit-bug-importer oldest_to_newest 1266025 0 jiewen_tan 2017-01-11 18:36:06 -0800 WebCrypto API should be on top of SecureContext per the latest spec: https://www.w3.org/TR/WebCryptoAPI/ Here are the updated IDLs: [Exposed=(Window,Worker)] interface Crypto { [SecureContext] readonly attribute SubtleCrypto subtle; ArrayBufferView getRandomValues(ArrayBufferView array); }; [SecureContext,Exposed=(Window,Worker)] interface CryptoKey { readonly attribute KeyType type; readonly attribute boolean extractable; readonly attribute object algorithm; readonly attribute object usages; }; [SecureContext,Exposed=(Window,Worker)] interface SubtleCrypto { Promise<any> encrypt(AlgorithmIdentifier algorithm, CryptoKey key, BufferSource data); Promise<any> decrypt(AlgorithmIdentifier algorithm, CryptoKey key, BufferSource data); Promise<any> sign(AlgorithmIdentifier algorithm, CryptoKey key, BufferSource data); Promise<any> verify(AlgorithmIdentifier algorithm, CryptoKey key, BufferSource signature, BufferSource data); Promise<any> digest(AlgorithmIdentifier algorithm, BufferSource data); Promise<any> generateKey(AlgorithmIdentifier algorithm, boolean extractable, sequence<KeyUsage> keyUsages ); Promise<any> deriveKey(AlgorithmIdentifier algorithm, CryptoKey baseKey, AlgorithmIdentifier derivedKeyType, boolean extractable, sequence<KeyUsage> keyUsages ); Promise<ArrayBuffer> deriveBits(AlgorithmIdentifier algorithm, CryptoKey baseKey, unsigned long length); Promise<CryptoKey> importKey(KeyFormat format, (BufferSource or JsonWebKey) keyData, AlgorithmIdentifier algorithm, boolean extractable, sequence<KeyUsage> keyUsages ); Promise<any> exportKey(KeyFormat format, CryptoKey key); Promise<any> wrapKey(KeyFormat format, CryptoKey key, CryptoKey wrappingKey, AlgorithmIdentifier wrapAlgorithm); Promise<CryptoKey> unwrapKey(KeyFormat format, BufferSource wrappedKey, CryptoKey unwrappingKey, AlgorithmIdentifier unwrapAlgorithm, AlgorithmIdentifier unwrappedKeyAlgorithm, boolean extractable, sequence<KeyUsage> keyUsages ); }; 1266026 1 webkit-bug-importer 2017-01-11 18:37:24 -0800 <rdar://problem/29982683> 1318778 2 dbates 2017-06-13 13:26:39 -0700 *** Bug 173323 has been marked as a duplicate of this bug. *** 1318787 3 dbates 2017-06-13 13:36:48 -0700 *** Bug 173325 has been marked as a duplicate of this bug. *** 1318789 4 312799 dbates 2017-06-13 13:37:19 -0700 Created attachment 312799 Patch We cannot test this change using a layout test as we do not support testing with a non-localhost server. We could write a TestWebKitAPI test for this change. I'm unclear how much value there is to do so given that we have existing unit tests to ensure SecurityOrigin::isPotentionallyTrustworthy(), the core algorithm for Secure Contexts, works correctly. Let me know if it would be preferred to add a unit test for this change. 1318791 5 312799 jiewen_tan 2017-06-13 13:44:58 -0700 Comment on attachment 312799 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=312799&action=review Thanks for adding the SecureContext attribute. > Source/JavaScriptCore/ChangeLog:9 > + Adds SubtleCrypto to the list of common identifiers so as to support toggling this Not familiar with this. Needs someone else to take a look. > Source/WebCore/ChangeLog:10 > + <https://w3c.github.io/webcrypto/Overview.html#crypto-interface> (W3C Editor's Draft 24 October 2016). Should we change this to https://www.w3.org/TR/WebCryptoAPI/ since it is official and has a newer date? 1318793 6 dbates 2017-06-13 13:47:56 -0700 (In reply to Jiewen Tan from comment #5) > > Source/WebCore/ChangeLog:10 > > + <https://w3c.github.io/webcrypto/Overview.html#crypto-interface> (W3C Editor's Draft 24 October 2016). > > Should we change this to https://www.w3.org/TR/WebCryptoAPI/ since it is > official and has a newer date? Will change before landing. 1318794 7 312799 saam 2017-06-13 13:47:58 -0700 Comment on attachment 312799 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=312799&action=review > Source/WebCore/ChangeLog:12 > + As a result of this change SubtleCrypto is only exposed in a secure context. That is, > + it is only available on an HTTPS page or an HTTPS page embedded in another HTTPS page. Can this be tested? 1318798 8 dbates 2017-06-13 13:51:26 -0700 (In reply to Saam Barati from comment #7) > Comment on attachment 312799 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=312799&action=review > > > Source/WebCore/ChangeLog:12 > > + As a result of this change SubtleCrypto is only exposed in a secure context. That is, > > + it is only available on an HTTPS page or an HTTPS page embedded in another HTTPS page. > > Can this be tested? See comment #4. 1318807 9 jiewen_tan 2017-06-13 13:58:38 -0700 (In reply to Daniel Bates from comment #4) > Created attachment 312799 [details] > Patch > > We cannot test this change using a layout test as we do not support testing > with a non-localhost server. We could write a TestWebKitAPI test for this > change. I'm unclear how much value there is to do so given that we have > existing unit tests to ensure SecurityOrigin::isPotentionallyTrustworthy(), > the core algorithm for Secure Contexts, works correctly. Let me know if it > would be preferred to add a unit test for this change. We have some imported W3C tests: LayoutTests/imported/w3c/web-platform-tests/WebCryptoAPI/secure_context/ Do your change make affect them properly? 1318822 10 dbates 2017-06-13 14:30:46 -0700 (In reply to Jiewen Tan from comment #9) > (In reply to Daniel Bates from comment #4) > > Created attachment 312799 [details] > > Patch > > > > We cannot test this change using a layout test as we do not support testing > > with a non-localhost server. We could write a TestWebKitAPI test for this > > change. I'm unclear how much value there is to do so given that we have > > existing unit tests to ensure SecurityOrigin::isPotentionallyTrustworthy(), > > the core algorithm for Secure Contexts, works correctly. Let me know if it > > would be preferred to add a unit test for this change. > > We have some imported W3C tests: > LayoutTests/imported/w3c/web-platform-tests/WebCryptoAPI/secure_context/ > > Do your change make affect them properly? No, because we need to add support infrastructure to run the test using a non-localhost server. 1318823 11 dbates 2017-06-13 14:32:03 -0700 (In reply to Daniel Bates from comment #10) > (In reply to Jiewen Tan from comment #9) > > (In reply to Daniel Bates from comment #4) > > > Created attachment 312799 [details] > > > Patch > > > > > > We cannot test this change using a layout test as we do not support testing > > > with a non-localhost server. We could write a TestWebKitAPI test for this > > > change. I'm unclear how much value there is to do so given that we have > > > existing unit tests to ensure SecurityOrigin::isPotentionallyTrustworthy(), > > > the core algorithm for Secure Contexts, works correctly. Let me know if it > > > would be preferred to add a unit test for this change. > > > > We have some imported W3C tests: > > LayoutTests/imported/w3c/web-platform-tests/WebCryptoAPI/secure_context/ > > > > Do your change make affect them properly? > > No, because we need to add support infrastructure to run the test using a > non-localhost server. I forgot to mention, that with the proposed patch (attachment #312799) applied then the tests in LayoutTests/imported/w3c/web-platform-tests/WebCryptoAPI/secure_context pass when you run them from a non-localhost server. 1318865 12 312799 jiewen_tan 2017-06-13 15:38:36 -0700 Comment on attachment 312799 Patch Saam and Dan have explained the concept of common identifiers to me. Looks good then. r=me. 1319351 13 ap 2017-06-14 16:11:38 -0700 Does this change mean that WebCrypto will no longer be available in http pages? If so, the benefit is unclear to me. 1319356 14 oliver 2017-06-14 16:20:16 -0700 (In reply to Alexey Proskuryakov from comment #13) > Does this change mean that WebCrypto will no longer be available in http > pages? If so, the benefit is unclear to me. It does not make sense to provide access to cryptographic APIs in an insecure environment, and i believe that we're the only browser left that has not restricted this. 1319380 15 312799 ap 2017-06-14 17:15:56 -0700 Comment on attachment 312799 Patch If that's the reason, I think that we should just plain not make this change. There is no benefit to anyone from it. 1319408 16 jiewen_tan 2017-06-14 18:25:07 -0700 (In reply to Alexey Proskuryakov from comment #15) > Comment on attachment 312799 [details] > Patch > > If that's the reason, I think that we should just plain not make this > change. There is no benefit to anyone from it. I think the committee add SecureContext mainly because they try to avoid leaking keying materials when they are transported between servers and clients. I am not involved in the discussions so I cannot recover more information. As for me, I am kind of neutral for this particular reason to add SecureContext. One thing is that I believe with all the functionalities we provided developers can protect their keying materials well without SecureContext. The other thing however is if developers begin to get used to SecureContext, they might solely rely on HTTPS to protect their keying materials. And therefore if users suddenly load those pages with HTTP, keying materials will be exposed then. To prevent this scenario, we should add support of SecureContext despite whether this idea itself is good or not. Or we could ask the committee to drop this requirement, which seems impossible for me. 1319451 17 ap 2017-06-14 21:41:02 -0700 I think that it's mostly about the idea that all new functionality in HTML should be limited to https, forcing people to use https. We generally don't respect that, and I don't think that we should start doing that. In this case, it was natural to claim security benefits, but I don't think that there is any validity to that claim. 1319522 18 frederic.jacobs 2017-06-15 02:56:55 -0700 Seconding this argument > The other thing however is if developers begin to get used to SecureContext, they might solely rely on HTTPS to protect their keying materials. And therefore if users suddenly load those pages with HTTP, keying materials will be exposed then. To prevent this scenario, we should add support of SecureContext despite whether this idea itself is good or not. If a website is using the WebCrypto API, it is likely store sensitive keying information on the client-side. It would be unfortunate that a downgrade attack to their server (either because of a HSTS bug or missing headers) would enable an attacker to get a signing oracle that signs or decrypt anything they want. I think it would be wise to follow the spec. 1319672 19 ap 2017-06-15 13:05:31 -0700 > If a website is using the WebCrypto API, it is likely store sensitive keying information on the client-side. I don't think that's accurate. There are lots of uses that don't involve storing secrets locally. WebCrypto is "subtle" for a reason, there are many mistakes that can be done with it. Yes, using http with anything sensitive would be a bad mistake, but guarding against it by blocking the feature is a truly weird idea. We don't block password form fields, which are a lot more sensitive in practice. 1319694 20 oliver 2017-06-15 13:54:26 -0700 (In reply to Alexey Proskuryakov from comment #19) > > If a website is using the WebCrypto API, it is likely store sensitive keying information on the client-side. > > I don't think that's accurate. There are lots of uses that don't involve > storing secrets locally. > > WebCrypto is "subtle" for a reason, there are many mistakes that can be done > with it. Yes, using http with anything sensitive would be a bad mistake, but > guarding against it by blocking the feature is a truly weird idea. We don't > block password form fields, which are a lot more sensitive in practice. Given your strong feelings on the matter, could you work with Hixie (or whoever the current editor is) to remove the SecureContext restriction from the spec? Otherwise we are needlessly violating the spec where every other browser is in compliance. My belief is that this should be restricted to sites that are secure to prevent accidental foot-gun interaction with user private data, and my understanding was that that was the consensus of the other browsers. Again, if you feel otherwise please make your case for a spec change and add a link to the thread into this bug so others can follow. If you don't believe that the spec is wrong then i'll happily r+ this as this is a low risk change, with a moderate-high reward depending on where you stand vis a vis the footgun effect :D 1319791 21 ap 2017-06-15 17:36:10 -0700 Do we argue against the other "https only" features, or are we silently ignoring those requirements? I thought it was the latter. 1320361 22 oliver 2017-06-17 01:07:51 -0700 (In reply to Alexey Proskuryakov from comment #21) > Do we argue against the other "https only" features, or are we silently > ignoring those requirements? I thought it was the latter. The only reason this hasn't come up before was because we did not implement the SecureContext component of the spec correctly, and have out of date IDL for some of the existing features. Again, if you feel that this is incorrect, could you raise the issue with the working group and get the secure context attribute remove from web crypto apis. Your current argument is literally "we don't already match the spec, so why should we fix this now?" 1320377 23 ap 2017-06-17 04:21:30 -0700 Sure, it would be good to improve the spec. It has seen a lot of influence from people new to web technologies. It would also be useful to discuss actual issues that need fixing. Frederic's comment 18 is actually somewhat convincing to me, except that blocking all crypto functionality seems like overkill. 1320777 24 jiewen_tan 2017-06-19 12:23:05 -0700 (In reply to Alexey Proskuryakov from comment #23) > Sure, it would be good to improve the spec. It has seen a lot of influence > from people new to web technologies. > > It would also be useful to discuss actual issues that need fixing. > Frederic's comment 18 is actually somewhat convincing to me, except that > blocking all crypto functionality seems like overkill. Actually, some people comments on the spec that at least hash could somehow be an exception. Maybe we could follow this by pointing out some functionalities are not necessarily protected by SecureContext. 1321090 25 frederic.jacobs 2017-06-20 04:46:18 -0700 Even if you only expose window.crypto.subtle.digest on non-SecureContext, I think that's detrimental to security. Someone out there will do an integrity check of some resource using window.crypto.subtle.digest, not realizing that any network attacker can redefine that function (and even his application source code). The idea of having things in window.crypto.subtle that require SecureContext and other not seems very confusing from a Web developers perspective. I'm fully aware that the compatibility is not good yet. But requiring developers in the future to check whether a sub-component of subtle is present is gonna be making cross-browser support really painful for frameworks who need to specify what is available over what origin. If you want to use browser crypto APIs, use HTTPS. I have trouble seeing why we're arguing so hard about not complying to a standard, especially when not doing so will likely result in developers shooting themselves in the foot and increased code/documentation complexity for us and web developers. 1335430 26 frederic.jacobs 2017-08-04 13:47:12 -0700 Both Chrome and Firefox are going along with deprecating it. Chrome already did it. FireFox says it's going to happen in 2017 Q4 or 2018 Q1. https://groups.google.com/forum/#!msg/mozilla.dev.platform/wwmN1eqeRyw/Bv7ELvsrAgAJ 1784872 27 gsnedders 2021-08-17 10:54:26 -0700 forward duping to where this fixed :( *** This bug has been marked as a duplicate of bug 227725 *** 312799 2017-06-13 13:37:19 -0700 2017-06-14 17:15:56 -0700 Patch bug-166959-20170613133719.patch text/plain 3605 dbates U3VidmVyc2lvbiBSZXZpc2lvbjogMjE4MTgwCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCBi ODkwNTVlMjgxMmU0ZDgwMzM0YzQ3YTAyYmM5ZTgyODIyMjBhMjdmLi45YTY0NTA3ZjFmZjY2ODFj YmQxYzljMzdjYzAzN2I3MWNjYTJmM2UyIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs MyArMSwxNiBAQAorMjAxNy0wNi0xMyAgRGFuaWVsIEJhdGVzICA8ZGFiYXRlc0BhcHBsZS5jb20+ CisKKyAgICAgICAgW1dlYkNyeXB0b10gV2ViQ3J5cHRvIEFQSSBzaG91bGQgYmUgb24gdG9wIG9m IFNlY3VyZUNvbnRleHQKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTE2Njk1OQorICAgICAgICA8cmRhcjovL3Byb2JsZW0vMjk5ODI2ODM+CisKKyAgICAg ICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgQWRkcyBTdWJ0bGVDcnlw dG8gdG8gdGhlIGxpc3Qgb2YgY29tbW9uIGlkZW50aWZpZXJzIHNvIGFzIHRvIHN1cHBvcnQgdG9n Z2xpbmcgdGhpcworICAgICAgICBpbnRlcmZhY2UgYXQgcnVudGltZS4KKworICAgICAgICAqIHJ1 bnRpbWUvQ29tbW9uSWRlbnRpZmllcnMuaDoKKwogMjAxNy0wNi0xMyAgRG9uIE9sbXN0ZWFkICA8 ZG9uLm9sbXN0ZWFkQHNvbnkuY29tPgogCiAgICAgICAgIFtKU0NdIFJlbW92ZSByZWR1bmRhbnQg aW5jbHVkZXMgaW4gY29uZmlnLmgKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxv ZyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCBhNTllNTgyZTNlOTNlNzYxZDQwNTJk OTJhN2M1ZDg2NjdmZWU5NjRkLi4wMzc0ZmViOTRlMTM4NDdiMzg4N2Q2ZGU5ZmVjYTdlODliYmQy N2YxIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dl YkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTkgQEAKKzIwMTctMDYtMTMgIERhbmllbCBCYXRl cyAgPGRhYmF0ZXNAYXBwbGUuY29tPgorCisgICAgICAgIFtXZWJDcnlwdG9dIFdlYkNyeXB0byBB UEkgc2hvdWxkIGJlIG9uIHRvcCBvZiBTZWN1cmVDb250ZXh0CisgICAgICAgIGh0dHBzOi8vYnVn cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNjY5NTkKKyAgICAgICAgPHJkYXI6Ly9wcm9i bGVtLzI5OTgyNjgzPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisg ICAgICAgIEFkZHMgdGhlIElETCBleHRlbmRlZCBhdHRyaWJ1dGUgU2VjdXJlQ29udGV4dCB0byB0 aGUgSURMIGF0dHJpYnV0ZSBTdWJ0bGVDcnlwdG8gYXMgcGVyCisgICAgICAgIDxodHRwczovL3cz Yy5naXRodWIuaW8vd2ViY3J5cHRvL092ZXJ2aWV3Lmh0bWwjY3J5cHRvLWludGVyZmFjZT4gKFcz QyBFZGl0b3IncyBEcmFmdCAyNCBPY3RvYmVyIDIwMTYpLgorICAgICAgICBBcyBhIHJlc3VsdCBv ZiB0aGlzIGNoYW5nZSBTdWJ0bGVDcnlwdG8gaXMgb25seSBleHBvc2VkIGluIGEgc2VjdXJlIGNv bnRleHQuIFRoYXQgaXMsCisgICAgICAgIGl0IGlzIG9ubHkgYXZhaWxhYmxlIG9uIGFuIEhUVFBT IHBhZ2Ugb3IgYW4gSFRUUFMgcGFnZSBlbWJlZGRlZCBpbiBhbm90aGVyIEhUVFBTIHBhZ2UuCisK KyAgICAgICAgKiBjcnlwdG8vU3VidGxlQ3J5cHRvLmlkbDoKKyAgICAgICAgKiBwYWdlL0NyeXB0 by5pZGw6CisKIDIwMTctMDYtMTMgIFdlbnNvbiBIc2llaCAgPHdlbnNvbl9oc2llaEBhcHBsZS5j b20+CiAKICAgICAgICAgVW5hYmxlIHRvIHBhc3RlIHRleHQgdGhhdCB3YXMgY29waWVkIGZyb20g YSBwYWdlIGludG8gdGhlIHVuaXZlcnNhbCBzZWFyY2ggZmllbGQKZGlmZiAtLWdpdCBhL1NvdXJj ZS9KYXZhU2NyaXB0Q29yZS9ydW50aW1lL0NvbW1vbklkZW50aWZpZXJzLmggYi9Tb3VyY2UvSmF2 YVNjcmlwdENvcmUvcnVudGltZS9Db21tb25JZGVudGlmaWVycy5oCmluZGV4IGJmMTA2YWJkODA0 YTFkMTgwZTE0ODRmNTRjZDQwNzkwYzdjZDM3YjcuLmNmNjI5YzRmODI4ZGEyNDVlNGY5M2M5NzAw NTdmMDk3MDU2NTlhZDQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9ydW50aW1l L0NvbW1vbklkZW50aWZpZXJzLmgKKysrIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL3J1bnRpbWUv Q29tbW9uSWRlbnRpZmllcnMuaApAQCAtMTI0LDYgKzEyNCw3IEBACiAgICAgbWFjcm8oU2hhcmVk QXJyYXlCdWZmZXIpIFwKICAgICBtYWNybyhTdGF0aWNSYW5nZSkgXAogICAgIG1hY3JvKFN0cmlu ZykgXAorICAgIG1hY3JvKFN1YnRsZUNyeXB0bykgXAogICAgIG1hY3JvKFN5bWJvbCkgXAogICAg IG1hY3JvKFN5bnRheEVycm9yKSBcCiAgICAgbWFjcm8oVHlwZUVycm9yKSBcCmRpZmYgLS1naXQg YS9Tb3VyY2UvV2ViQ29yZS9jcnlwdG8vU3VidGxlQ3J5cHRvLmlkbCBiL1NvdXJjZS9XZWJDb3Jl L2NyeXB0by9TdWJ0bGVDcnlwdG8uaWRsCmluZGV4IGFmNzgwNjkwNWQwOGJmNDJhYTY1ZTBmNDI2 ZDZjYzI2NmE4ZGMwMWMuLjQxOTYwNWRlZTYzZTY0ZGYxYzRkNGI0ZWVkYjg0NzI1Y2M3M2I1MDcg MTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL2NyeXB0by9TdWJ0bGVDcnlwdG8uaWRsCisrKyBi L1NvdXJjZS9XZWJDb3JlL2NyeXB0by9TdWJ0bGVDcnlwdG8uaWRsCkBAIC0yNyw2ICsyNyw3IEBA IGVudW0gS2V5Rm9ybWF0IHsgInJhdyIsICJzcGtpIiwgInBrY3M4IiwgImp3ayIgfTsKIAogWwog ICAgIENvbmRpdGlvbmFsPVNVQlRMRV9DUllQVE8sCisgICAgU2VjdXJlQ29udGV4dCwKICAgICBF eHBvc2VkPShXaW5kb3csV29ya2VyKSwKICAgICBHZW5lcmF0ZUlzUmVhY2hhYmxlPUltcGxTY3Jp cHRFeGVjdXRpb25Db250ZXh0LAogXSBpbnRlcmZhY2UgU3VidGxlQ3J5cHRvIHsKZGlmZiAtLWdp dCBhL1NvdXJjZS9XZWJDb3JlL3BhZ2UvQ3J5cHRvLmlkbCBiL1NvdXJjZS9XZWJDb3JlL3BhZ2Uv Q3J5cHRvLmlkbAppbmRleCAyNGZiNWNiYThiOTExNDBkN2Q5OTUwNThjNWU1MmFiOGUwODg1MzU5 Li5iYzc3NTc1NDZkYjU0MDRmMmYzOTQxZGNhZjZiZjk5ZDY3NDMyMDk4IDEwMDY0NAotLS0gYS9T b3VyY2UvV2ViQ29yZS9wYWdlL0NyeXB0by5pZGwKKysrIGIvU291cmNlL1dlYkNvcmUvcGFnZS9D cnlwdG8uaWRsCkBAIC0zMSw3ICszMSw3IEBACiAgICAgRXhwb3NlZD0oV2luZG93LFdvcmtlciks CiAgICAgR2VuZXJhdGVJc1JlYWNoYWJsZT1JbXBsU2NyaXB0RXhlY3V0aW9uQ29udGV4dCwKIF0g aW50ZXJmYWNlIENyeXB0byB7Ci0gICAgW0NvbmRpdGlvbmFsPVNVQlRMRV9DUllQVE9dIHJlYWRv bmx5IGF0dHJpYnV0ZSBTdWJ0bGVDcnlwdG8gc3VidGxlOworICAgIFtDb25kaXRpb25hbD1TVUJU TEVfQ1JZUFRPLCBTZWN1cmVDb250ZXh0XSByZWFkb25seSBhdHRyaWJ1dGUgU3VidGxlQ3J5cHRv IHN1YnRsZTsKICAgICBbQ3VzdG9tLCBNYXlUaHJvd0V4Y2VwdGlvbl0gQXJyYXlCdWZmZXJWaWV3 IGdldFJhbmRvbVZhbHVlcyhBcnJheUJ1ZmZlclZpZXcgYXJyYXkpOwogCiAgICAgLy8gV2lsbCBi ZSBkZXByZWNhdGVkLgo=