51599 2010-12-24 12:14:00 -0800 The web process is using the Mac OS X keychain for HTTP authentication 2010-12-24 18:18:16 -0800 1 1 1 Unclassified WebKit WebKit2 528+ (Nightly build) All All REOPENED InRadar P2 Normal --- 1 mitz webkit-unassigned abarth ap beidson eric webkit.review.bot oldest_to_newest 326713 0 mitz 2010-12-24 12:14:00 -0800 <rdar://problem/8758386> 326714 1 77426 mitz 2010-12-24 12:19:27 -0800 Created attachment 77426 Prevent the web process from using its credential storage and use the UI process’s credential storage 326715 2 77426 andersca 2010-12-24 12:21:10 -0800 Comment on attachment 77426 Prevent the web process from using its credential storage and use the UI process’s credential storage View in context: https://bugs.webkit.org/attachment.cgi?id=77426&action=review > WebKit2/WebProcess/mac/WebProcessMainMac.mm:107 > + SecKeychainSetPreferenceDomain(kSecPreferencesDomainSystem); Please add a comment indicating what this does. 326716 3 mitz 2010-12-24 12:26:42 -0800 Fixed in <http://trac.webkit.org/changeset/74648>. 326733 4 webkit.review.bot 2010-12-24 12:58:35 -0800 http://trac.webkit.org/changeset/74648 might have broken Qt Linux Release 326738 5 mitz 2010-12-24 13:13:55 -0800 (In reply to comment #4) > http://trac.webkit.org/changeset/74648 might have broken Qt Linux Release r74652 326756 6 ap 2010-12-24 14:59:51 -0800 This change looks surprising for several reasons. - Why do we even want this? There is no explanation in Bugzilla, and the one I see in Radar isn't fully convincing. - IPC doesn't come free - at least chromium tries hard to limit the number of messages. - Doesn't this break default credentials (see ResourceHandle::createNSURLConnection()) - sometimes credentials must be sent preemptively, without waiting for a challenge)? Please CC Brady and myself when making changes to HTTP authentication. 326757 7 mitz 2010-12-24 15:05:50 -0800 (In reply to comment #6) > This change looks surprising for several reasons. > - Why do we even want this? For security and correctness. The credentials belongs to the client, not to WebKit. > There is no explanation in Bugzilla, and the one I see in Radar isn't fully convincing. > - IPC doesn't come free - at least chromium tries hard to limit the number of messages. > - Doesn't this break default credentials (see ResourceHandle::createNSURLConnection()) - sometimes credentials must be sent preemptively, without waiting for a challenge)? How can there be a default credential for a protection space if there was never a challenge for that protection space? > Please CC Brady and myself when making changes to HTTP authentication. OK. 326759 8 ap 2010-12-24 15:16:51 -0800 > For security and correctness. The credentials belongs to the client, not to WebKit. I'm not sure about that, but I may be missing something. Cookies are global (per OS user), and stored credentials seem to be global, too. What makes them private to the client? Maybe Keychain credentials being private to application is how it should be in ideal world, but it doesn't seem to be the case in CFNetwork model. > How can there be a default credential for a protection space if there was never a challenge > for that protection space? Default credentials work when making requests after the first one (ignoring CFNetwork connection pool and per-connection auth schemes like NTLM for simplicity). So, you authenticate to a Basic protection space once, and then all requests to resources in the same space carry credentials upfront. if (shouldUseCredentialStorage && firstRequest().url().protocolInHTTPFamily()) { if (d->m_user.isEmpty() && d->m_pass.isEmpty()) { // <rdar://problem/7174050> - For URLs that match the paths of those previously challenged for HTTP Basic authentication, // try and reuse the credential preemptively, as allowed by RFC 2617. d->m_initialCredential = CredentialStorage::get(firstRequest().url()); Note that WebCore credential storage isn't consulted for default credentials if shouldUseCredentialStorage is false (of course). I'm surprised if this patch didn't break default credential tests. Are those disabled for WebKit2? 326761 9 mitz 2010-12-24 15:31:30 -0800 (In reply to comment #8) > > For security and correctness. The credentials belongs to the client, not to WebKit. > > I'm not sure about that, but I may be missing something. Cookies are global (per OS user), and stored credentials seem to be global, too. What makes them private to the client? The default credential store is global, but different clients have access to different credentials. > Maybe Keychain credentials being private to application is how it should be in ideal world, but it doesn't seem to be the case in CFNetwork model. Regardless of API, that is how things behave on Mac OS X. > > > How can there be a default credential for a protection space if there was never a challenge > > for that protection space? > > Default credentials work when making requests after the first one (ignoring CFNetwork connection pool and per-connection auth schemes like NTLM for simplicity). So, you authenticate to a Basic protection space once, and then all requests to resources in the same space carry credentials upfront. So the first request is made without credentials, an authentication challenge is issues, and then the credential storage is populated with a default credential, which is used in subsequent requests? > if (shouldUseCredentialStorage && firstRequest().url().protocolInHTTPFamily()) { > if (d->m_user.isEmpty() && d->m_pass.isEmpty()) { > // <rdar://problem/7174050> - For URLs that match the paths of those previously challenged for HTTP Basic authentication, > // try and reuse the credential preemptively, as allowed by RFC 2617. > d->m_initialCredential = CredentialStorage::get(firstRequest().url()); > > Note that WebCore credential storage isn't consulted for default credentials if shouldUseCredentialStorage is false (of course). I think the above code’s interpretation of shouldUseCredentialStorage may need to be corrected. > I'm surprised if this patch didn't break default credential tests. Are those disabled for WebKit2? Strange. If this in fact broke something, please file a new bug. 326763 10 ap 2010-12-24 16:11:25 -0800 > The default credential store is global, but different clients have access to different credentials. How does this work? I've always been thinking that unsigned apps didn't have access to passwords unless the user approved, but there wasn't any compartmentalization. I've just verified that a test app sees all credentials in keychain, but calling -[NSURLCredential password] resulted in a confirmation dialog. > So the first request is made without credentials, an authentication challenge is issues, and then the credential storage is populated with a default credential, which is used in subsequent requests? Yes, that's correct. > I think the above code’s interpretation of shouldUseCredentialStorage may need to be corrected. Do you have a specific suggestion? WebCore credential storage isn't properly maintained when the client says that it shouldn't be used, even though it's sometimes written to. > > I'm surprised if this patch didn't break default credential tests. Are those disabled for WebKit2? > Strange. If this in fact broke something, please file a new bug. I expected you to check that, as the person who made this change. I'm still not convinced that this patch general direction is right. If you don't have the time to keep working on this, perhaps it should be rolled out? In fact, our basic-auth-default test is currently disabled with a bogus comment: # WebKit2 needs to support authentication http/tests/appcache/auth.html http/tests/security/credentials-in-referer.html http/tests/xmlhttprequest/basic-auth.html http/tests/xmlhttprequest/basic-auth-default.html http/tests/xmlhttprequest/logout.html http/tests/xmlhttprequest/re-login-async.html 326764 11 mitz 2010-12-24 16:26:07 -0800 (In reply to comment #10) > > The default credential store is global, but different clients have access to different credentials. > > How does this work? I've always been thinking that unsigned apps didn't have access to passwords unless the user approved, but there wasn't any compartmentalization. Keychain items have access control lists. > > I've just verified that a test app sees all credentials in keychain, but calling -[NSURLCredential password] resulted in a confirmation dialog. The access control list applies to the secret, not other parts of the keychain item. > > So the first request is made without credentials, an authentication challenge is issues, and then the credential storage is populated with a default credential, which is used in subsequent requests? > > Yes, that's correct. > > > I think the above code’s interpretation of shouldUseCredentialStorage may need to be corrected. > > Do you have a specific suggestion? > > WebCore credential storage isn't properly maintained when the client says that it shouldn't be used, even though it's sometimes written to. I will probably need to know more about what that function is trying to do and the expected lifetime of the default credential once it’s entered into the store. In particular, if it is expected to persist across closing all WKViews in an app (which terminates the web process), then it should probably be managed by the UI process. > > > I'm surprised if this patch didn't break default credential tests. Are those disabled for WebKit2? > > Strange. If this in fact broke something, please file a new bug. > > I expected you to check that, as the person who made this change. I'm still not convinced that this patch general direction is right. If you don't have the time to keep working on this, perhaps it should be rolled out? I will see what I can find out using the tests you listed below! > > In fact, our basic-auth-default test is currently disabled with a bogus comment: > > # WebKit2 needs to support authentication > http/tests/appcache/auth.html > http/tests/security/credentials-in-referer.html > http/tests/xmlhttprequest/basic-auth.html > http/tests/xmlhttprequest/basic-auth-default.html > http/tests/xmlhttprequest/logout.html > http/tests/xmlhttprequest/re-login-async.html 326765 12 ap 2010-12-24 16:43:16 -0800 > The access control list applies to the secret, not other parts of the keychain item. Thanks, understood. Perhaps we need to find some way to only ask the UI process when it consults the Keychain. Is there is a way to check that the process has access to a secret without displaying UI? I think that there is another loose end here. You changed it so that the web process doesn't read keychain credentials, but it still writes them on its own AFAICT. 326766 13 mitz 2010-12-24 16:47:21 -0800 (In reply to comment #11) > > In fact, our basic-auth-default test is currently disabled with a bogus comment: That test is failing in the same way in r74647 and in r74648. > > http/tests/xmlhttprequest/logout.html This is the only test of the six that changed after r74648. It is now failing. I am going to investigate. 326767 14 mitz 2010-12-24 16:52:46 -0800 (In reply to comment #12) > > The access control list applies to the secret, not other parts of the keychain item. > > Thanks, understood. > > Perhaps we need to find some way to only ask the UI process when it consults the Keychain. Is there is a way to check that the process has access to a secret without displaying UI? There is a way, but the web process should never have access to secrets in the keychain anyway. > I think that there is another loose end here. You changed it so that the web process doesn't read keychain credentials, but it still writes them on its own AFAICT. Setting the preference domain is supposed to prevent this. 326769 15 ap 2010-12-24 16:55:18 -0800 > > basic-auth-default test is currently disabled with a bogus comment: > That test is failing in the same way in r74647 and in r74648. Did default credentials work in the browser? I don't see how this change could not be breaking them (or making them more difficult to fix if they were broken). 326772 16 mitz 2010-12-24 17:05:12 -0800 (In reply to comment #15) > > > basic-auth-default test is currently disabled with a bogus comment: > > That test is failing in the same way in r74647 and in r74648. > > Did default credentials work in the browser? I don't see how this change could not be breaking them (or making them more difficult to fix if they were broken). Yes, the test does appear to pass when run in the browser prior to r74648, but not after the change. I am going to use bug 51603 to track this. 326774 17 ap 2010-12-24 17:16:05 -0800 > I think that there is another loose end here. You changed it so that the web process doesn't read keychain credentials, but it still writes them on its own AFAICT. > Setting the preference domain is supposed to prevent this. I have a difficulty following this. So, the web process still writes the credentials to Keychain, but in a way that it can't read them, but Safari can? What if the client is not Safari, and it is not signed? Or if the web process doesn't write to Keychain any more, then who does? > I am going to use bug 51603 to track this. Thanks for checking! FWIW, it would be easier for me to review a single patch that fixes <rdar://problem/8758386> without introducing regressions than to follow a trail of follow-ups. If it's split into multiple patches, it's harder to keep track of what remains broken. 326787 18 mitz 2010-12-24 17:55:21 -0800 Reverted in <http://trac.webkit.org/changeset/74657>. 326788 19 mitz 2010-12-24 17:58:05 -0800 (In reply to comment #17) > > I think that there is another loose end here. You changed it so that the web process doesn't read keychain credentials, but it still writes them on its own AFAICT. > > Setting the preference domain is supposed to prevent this. > > I have a difficulty following this. So, the web process still writes the credentials to Keychain, but in a way that it can't read them, but Safari can? What if the client is not Safari, and it is not signed? > > Or if the web process doesn't write to Keychain any more, then who does? The UI process should be in charge of read/write access to all permanent credentials, but currently, when a WKCredential with permanent persistence is created in the UI process, it never stores it in the keychain. This, too, will need to be fixed along with this bug. 326791 20 ap 2010-12-24 18:18:16 -0800 Currently, CFNetwork writes it. It may take some effort to match its behavior - I don't even know if it writes any "permanent" credential, or if it only does that after authentication succeeds. I haven't checked if WebCore credential storage behavior matches CFNetwork in this regard. 77426 2010-12-24 12:19:27 -0800 2010-12-24 17:55:39 -0800 Prevent the web process from using its credential storage and use the UI process’s credential storage 8758386_r2.diff text/plain 5646 mitz SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA3NDY0NykKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTMgQEAKKzIwMTAtMTItMjQgIERhbiBCZXJuc3RlaW4gIDxtaXR6QGFwcGxlLmNv bT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICA8cmRh cjovL3Byb2JsZW0vODc1ODM4Nj4gVGhlIHdlYiBwcm9jZXNzIHVzZXMgaXRzIG93biBjcmVkZW50 aWFsIHN0b3JhZ2UKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dp P2lkPTUxNTk5CisKKyAgICAgICAgKiBXZWJDb3JlLmV4cC5pbjogRXhwb3J0IENyZWRlbnRpYWxT dG9yYWdlOjpnZXRGcm9tUGVyc2lzdGVudFN0b3JhZ2UoKSwgQ3JlZGVudGlhbDo6aGFzUGFzc3dv cmQoKSwKKyAgICAgICAgYW5kIENyZWRlbnRpYWw6OmlzRW1wdHkoKS4KKwogMjAxMC0xMi0yNCAg WXVyeSBTZW1pa2hhdHNreSAgPHl1cnlzQGNocm9taXVtLm9yZz4KIAogICAgICAgICBSZXZpZXdl ZCBieSBEYXJpbiBBZGxlci4KSW5kZXg6IFdlYkNvcmUvV2ViQ29yZS5leHAuaW4KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gV2ViQ29yZS9XZWJDb3JlLmV4cC5pbgkocmV2aXNpb24gNzQ2MDcpCisrKyBXZWJDb3Jl L1dlYkNvcmUuZXhwLmluCSh3b3JraW5nIGNvcHkpCkBAIC00MzUsNiArNDM1LDcgQEAgX19aTjdX ZWJDb3JlMTZlbmNsb3NpbmdJbnRSZWN0RVJLN19OU1JlYwogX19aTjdXZWJDb3JlMTZlbmNsb3Np bmdJbnRSZWN0RVJLTlNfOUZsb2F0UmVjdEUKIF9fWk43V2ViQ29yZTE2aXNFbmRPZlBhcmFncmFw aEVSS05TXzE1VmlzaWJsZVBvc2l0aW9uRU5TXzI3RWRpdGluZ0JvdW5kYXJ5Q3Jvc3NpbmdSdWxl RQogX19aTjdXZWJDb3JlMTZqc1N0cmluZ1Nsb3dDYXNlRVBOM0pTQzlFeGVjU3RhdGVFUk5TMF85 V2Vha0dDTWFwSVBOM1dURjEwU3RyaW5nSW1wbEVQTlMwXzhKU1N0cmluZ0VFRVM2XworX19aTjdX ZWJDb3JlMTdDcmVkZW50aWFsU3RvcmFnZTI0Z2V0RnJvbVBlcnNpc3RlbnRTdG9yYWdlRVJLTlNf MTVQcm90ZWN0aW9uU3BhY2VFCiBfX1pON1dlYkNvcmUxN0NyZWRlbnRpYWxTdG9yYWdlM2dldEVS S05TXzE1UHJvdGVjdGlvblNwYWNlRQogX19aTjdXZWJDb3JlMTdET01JbXBsZW1lbnRhdGlvbjEz aXNYTUxNSU1FVHlwZUVSS04zV1RGNlN0cmluZ0UKIF9fWk43V2ViQ29yZTE3RE9NSW1wbGVtZW50 YXRpb24xNGlzVGV4dE1JTUVUeXBlRVJLTjNXVEY2U3RyaW5nRQpAQCAtOTMzLDggKzkzNCwxMCBA QCBfX1pON1dlYkNvcmU5cGxhaW5UZXh0RVBLTlNfNVJhbmdlRU5TXzIwCiBfX1pON1dlYkNvcmU5 dG9FbGVtZW50RU4zSlNDN0pTVmFsdWVFCiBfX1pOSzNKU0M4QmluZGluZ3MxMFJvb3RPYmplY3Qx Mmdsb2JhbE9iamVjdEV2CiBfX1pOSzNXVEY2U3RyaW5nMTRjcmVhdGVDRlN0cmluZ0V2CitfX1pO SzdXZWJDb3JlMTBDcmVkZW50aWFsMTFoYXNQYXNzd29yZEV2CiBfX1pOSzdXZWJDb3JlMTBDcmVk ZW50aWFsMTFwZXJzaXN0ZW5jZUV2CiBfX1pOSzdXZWJDb3JlMTBDcmVkZW50aWFsNHVzZXJFdgor X19aTks3V2ViQ29yZTEwQ3JlZGVudGlhbDdpc0VtcHR5RXYKIF9fWk5LN1dlYkNvcmUxMENyZWRl bnRpYWw4cGFzc3dvcmRFdgogX19aTks3V2ViQ29yZTEwRmxvYXRQb2ludGN2OF9OU1BvaW50RXYK IF9fWk5LN1dlYkNvcmUxMFBsdWdpbkRhdGExNnN1cHBvcnRzTWltZVR5cGVFUktOM1dURjZTdHJp bmdFCkluZGV4OiBXZWJLaXQyL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJLaXQyL0NoYW5n ZUxvZwkocmV2aXNpb24gNzQ2NDcpCisrKyBXZWJLaXQyL0NoYW5nZUxvZwkod29ya2luZyBjb3B5 KQpAQCAtMSwzICsxLDE5IEBACisyMDEwLTEyLTI0ICBEYW4gQmVybnN0ZWluICA8bWl0ekBhcHBs ZS5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAg PHJkYXI6Ly9wcm9ibGVtLzg3NTgzODY+IFRoZSB3ZWIgcHJvY2VzcyB1c2VzIGl0cyBvd24gY3Jl ZGVudGlhbCBzdG9yYWdlCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVn LmNnaT9pZD01MTU5OQorCisgICAgICAgICogVUlQcm9jZXNzL1dlYlBhZ2VQcm94eS5jcHA6Cisg ICAgICAgIChXZWJLaXQ6OldlYlBhZ2VQcm94eTo6ZGlkUmVjZWl2ZUF1dGhlbnRpY2F0aW9uQ2hh bGxlbmdlKTogVHJ5IHRvIGFuc3dlciB0aGUgY2hhbGxlbmdlIHVzaW5nCisgICAgICAgIHRoZSBV SSBwcm9jZXNz4oCZcyBjcmVkZW50aWFsIHN0b3JhZ2UgZmlyc3QuCisgICAgICAgICogV2ViUHJv Y2Vzcy9XZWJDb3JlU3VwcG9ydC9XZWJGcmFtZUxvYWRlckNsaWVudC5jcHA6CisgICAgICAgIChX ZWJLaXQ6OldlYkZyYW1lTG9hZGVyQ2xpZW50OjpzaG91bGRVc2VDcmVkZW50aWFsU3RvcmFnZSk6 IFByZXZlbnQgdGhlIHdlYiBwcm9jZXNzIGZyb20gdXNpbmcKKyAgICAgICAgaXRzIG93biBjcmVk ZW50aWFsIHN0b3JhZ2UuCisgICAgICAgICogV2ViUHJvY2Vzcy9tYWMvV2ViUHJvY2Vzc01haW5N YWMubW06CisgICAgICAgIChXZWJLaXQ6OldlYlByb2Nlc3NNYWluKTogRGl0dG8uCisKIDIwMTAt MTItMjMgIERhbiBCZXJuc3RlaW4gIDxtaXR6QGFwcGxlLmNvbT4KIAogICAgICAgICBSZXZpZXdl ZCBieSBTYW0gV2VpbmlnLgpJbmRleDogV2ViS2l0Mi9VSVByb2Nlc3MvV2ViUGFnZVByb3h5LmNw cAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBXZWJLaXQyL1VJUHJvY2Vzcy9XZWJQYWdlUHJveHkuY3BwCShyZXZp c2lvbiA3NDYxNSkKKysrIFdlYktpdDIvVUlQcm9jZXNzL1dlYlBhZ2VQcm94eS5jcHAJKHdvcmtp bmcgY29weSkKQEAgLTI3LDYgKzI3LDcgQEAKIAogI2luY2x1ZGUgIkF1dGhlbnRpY2F0aW9uQ2hh bGxlbmdlUHJveHkuaCIKICNpbmNsdWRlICJBdXRoZW50aWNhdGlvbkRlY2lzaW9uTGlzdGVuZXIu aCIKKyNpbmNsdWRlICJBdXRoZW50aWNhdGlvbk1hbmFnZXJNZXNzYWdlcy5oIgogI2luY2x1ZGUg IkRhdGFSZWZlcmVuY2UuaCIKICNpbmNsdWRlICJEcmF3aW5nQXJlYVByb3h5LmgiCiAjaW5jbHVk ZSAiRmluZEluZGljYXRvci5oIgpAQCAtNjEsNiArNjIsNyBAQAogI2luY2x1ZGUgIldlYlByb3Rl Y3Rpb25TcGFjZS5oIgogI2luY2x1ZGUgIldlYlNlY3VyaXR5T3JpZ2luLmgiCiAjaW5jbHVkZSAi V2ViVVJMUmVxdWVzdC5oIgorI2luY2x1ZGUgPFdlYkNvcmUvQ3JlZGVudGlhbFN0b3JhZ2UuaD4K ICNpbmNsdWRlIDxXZWJDb3JlL0Zsb2F0UmVjdC5oPgogI2luY2x1ZGUgPFdlYkNvcmUvTUlNRVR5 cGVSZWdpc3RyeS5oPgogI2luY2x1ZGUgPFdlYkNvcmUvV2luZG93RmVhdHVyZXMuaD4KQEAgLTE5 ODIsNiArMTk4NCwxNCBAQCB2b2lkIFdlYlBhZ2VQcm94eTo6ZGlkUmVjZWl2ZUF1dGhlbnRpY2F0 CiAgICAgV2ViRnJhbWVQcm94eSogZnJhbWUgPSBwcm9jZXNzKCktPndlYkZyYW1lKGZyYW1lSUQp OwogICAgIE1FU1NBR0VfQ0hFQ0soZnJhbWUpOwogCisgICAgaWYgKCFjb3JlQ2hhbGxlbmdlLnBy ZXZpb3VzRmFpbHVyZUNvdW50KCkpIHsKKyAgICAgICAgQ3JlZGVudGlhbCBkZWZhdWx0Q3JlZGVu dGlhbCA9IENyZWRlbnRpYWxTdG9yYWdlOjpnZXRGcm9tUGVyc2lzdGVudFN0b3JhZ2UoY29yZUNo YWxsZW5nZS5wcm90ZWN0aW9uU3BhY2UoKSk7CisgICAgICAgIGlmICghZGVmYXVsdENyZWRlbnRp YWwuaXNFbXB0eSgpICYmIGRlZmF1bHRDcmVkZW50aWFsLmhhc1Bhc3N3b3JkKCkgJiYgIWRlZmF1 bHRDcmVkZW50aWFsLnBhc3N3b3JkKCkuaXNFbXB0eSgpKSB7CisgICAgICAgICAgICBwcm9jZXNz KCktPnNlbmQoTWVzc2FnZXM6OkF1dGhlbnRpY2F0aW9uTWFuYWdlcjo6VXNlQ3JlZGVudGlhbEZv ckNoYWxsZW5nZShjaGFsbGVuZ2VJRCwgZGVmYXVsdENyZWRlbnRpYWwpLCBwYWdlSUQoKSk7Cisg ICAgICAgICAgICByZXR1cm47CisgICAgICAgIH0KKyAgICB9CisKICAgICBSZWZQdHI8QXV0aGVu dGljYXRpb25DaGFsbGVuZ2VQcm94eT4gYXV0aGVudGljYXRpb25DaGFsbGVuZ2UgPSBBdXRoZW50 aWNhdGlvbkNoYWxsZW5nZVByb3h5OjpjcmVhdGUoY29yZUNoYWxsZW5nZSwgY2hhbGxlbmdlSUQs IHRoaXMpOwogICAgIAogICAgIG1fbG9hZGVyQ2xpZW50LmRpZFJlY2VpdmVBdXRoZW50aWNhdGlv bkNoYWxsZW5nZUluRnJhbWUodGhpcywgZnJhbWUsIGF1dGhlbnRpY2F0aW9uQ2hhbGxlbmdlLmdl dCgpKTsKSW5kZXg6IFdlYktpdDIvV2ViUHJvY2Vzcy9XZWJDb3JlU3VwcG9ydC9XZWJGcmFtZUxv YWRlckNsaWVudC5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViS2l0Mi9XZWJQcm9jZXNzL1dlYkNvcmVT dXBwb3J0L1dlYkZyYW1lTG9hZGVyQ2xpZW50LmNwcAkocmV2aXNpb24gNzQ2MDcpCisrKyBXZWJL aXQyL1dlYlByb2Nlc3MvV2ViQ29yZVN1cHBvcnQvV2ViRnJhbWVMb2FkZXJDbGllbnQuY3BwCSh3 b3JraW5nIGNvcHkpCkBAIC0xNjEsNyArMTYxLDcgQEAgdm9pZCBXZWJGcmFtZUxvYWRlckNsaWVu dDo6ZGlzcGF0Y2hXaWxsUwogCiBib29sIFdlYkZyYW1lTG9hZGVyQ2xpZW50OjpzaG91bGRVc2VD cmVkZW50aWFsU3RvcmFnZShEb2N1bWVudExvYWRlciosIHVuc2lnbmVkIGxvbmcgaWRlbnRpZmll cikKIHsKLSAgICByZXR1cm4gdHJ1ZTsKKyAgICByZXR1cm4gZmFsc2U7CiB9CiAKIHZvaWQgV2Vi RnJhbWVMb2FkZXJDbGllbnQ6OmRpc3BhdGNoRGlkUmVjZWl2ZUF1dGhlbnRpY2F0aW9uQ2hhbGxl bmdlKERvY3VtZW50TG9hZGVyKiwgdW5zaWduZWQgbG9uZywgY29uc3QgQXV0aGVudGljYXRpb25D aGFsbGVuZ2UmIGNoYWxsZW5nZSkKSW5kZXg6IFdlYktpdDIvV2ViUHJvY2Vzcy9tYWMvV2ViUHJv Y2Vzc01haW5NYWMubW0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViS2l0Mi9XZWJQcm9jZXNzL21hYy9XZWJQ cm9jZXNzTWFpbk1hYy5tbQkocmV2aXNpb24gNzQ2MDcpCisrKyBXZWJLaXQyL1dlYlByb2Nlc3Mv bWFjL1dlYlByb2Nlc3NNYWluTWFjLm1tCSh3b3JraW5nIGNvcHkpCkBAIC0xMDQsNiArMTA0LDgg QEAgaW50IFdlYlByb2Nlc3NNYWluKGNvbnN0IENvbW1hbmRMaW5lJiBjbwogICAgICAgICByZXR1 cm4gMjsKICAgICB9CiAKKyAgICBTZWNLZXljaGFpblNldFByZWZlcmVuY2VEb21haW4oa1NlY1By ZWZlcmVuY2VzRG9tYWluU3lzdGVtKTsKKwogI2lmICFTSE9XX0NSQVNIX1JFUE9SVEVSCiAgICAg Ly8gSW5zdGFsbHMgc2lnbmFsIGhhbmRsZXJzIHRoYXQgZXhpdCBvbiBhIGNyYXNoIHNvIHRoYXQg Q3Jhc2hSZXBvcnRlciBkb2VzIG5vdCBzaG93IHVwLgogICAgIHNpZ25hbChTSUdJTEwsIF9leGl0 KTsK