207404 2020-02-07 13:55:29 -0800 Ephemeral session data leaks between processes 2020-02-19 16:40:59 -0800 1 1 1 Unclassified WebKit WebKit2 WebKit Nightly Build All macOS 10.15 RESOLVED FIXED InRadar P2 Normal --- 1 pfeldman pfeldman achristensen ap beidson bfulgham cdumez darin ggaren inspector-bugzilla-changes joepeck sihui_liu webkit-bug-importer oldest_to_newest 1616347 0 pfeldman 2020-02-07 13:55:29 -0800 When new network session is created, sessionID is used as an identifierBase: WebKit/NetworkProcess/mac/RemoteNetworkingContext.mm: networkProcess.ensureSession(sessionID, parameters.networkSessionParameters.shouldUseTestingNetworkSession, makeString(base, '.', sessionID.toUInt64()), WTFMove(uiProcessCookieStorage)); WebKit/NetworkProcess/NetworkProcess.cpp: storageSession = adoptCF(createPrivateStorageSession(cfIdentifier.get())); As a result, when there is more than one instance of the same application, sessions with the same sessionIDs use the same private store. SessionID's ephemeral session id is a simple counter from 0x8000000000000001 and on. So they will always be clashing between the processes. I can follow up with the fix and am asking for your preference. One way would be to make SessionIDs cryptographically unique: SessionID SessionID::generateEphemeralSessionID() { ASSERT(isMainThread()); RELEASE_ASSERT(!generationProtectionEnabled); uint64_t sessionId; cryptographicallyRandomValues(&sessionId, sizeof(sessionId)); sessionId = sessionId | SessionConstants::EphemeralSessionMask; return SessionID(sessionId); } Another way would be blending proccess ID into the identifier base in RemoteNetworkingContext.mm. I like the random sessionID because it would solve similar clashes once and for all, but I'm looking for your advice. 1616428 1 390140 pfeldman 2020-02-07 15:49:47 -0800 Created attachment 390140 Patch 1616582 2 390140 ap 2020-02-08 12:58:01 -0800 Comment on attachment 390140 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=390140&action=review > Source/WebCore/PAL/ChangeLog:7 > + Before the change, session ids were sequential and the data was leaking > + between ephemeral sessions of different processes. Have you observed the symptom? I just opened two instances of STP, opened a private browsing window in each, logged in to Bugzilla in one, and verified that I wasn't logged in in another. 1616709 3 pfeldman 2020-02-09 15:28:18 -0800 Yes, that's why I was looking into it. Steps to reproduce are: 1) Run Minibrowser #1 2) Run Minibrowser #2 3) In Minibrowser #1 pick "New WebKit2 Private Window" menu item 4) Log into bugs.webkit.org 5) In Minibrowser #2 pick "New WebKit2 Private Window" menu item 6) You are logged in 1616710 4 pfeldman 2020-02-09 15:31:51 -0800 I can repro with Safari Version 12.1.1 (14607.2.6.1.1) as well, same steps. 1616711 5 pfeldman 2020-02-09 15:36:11 -0800 (you'd need to run Safari as "open -n -a Safari" to make sure there are indeed two instances running) 1616861 6 390140 achristensen 2020-02-10 08:02:20 -0800 Comment on attachment 390140 Patch I don't think random session ids will solve this. Does it fix the symptom for you? Does this already-being-logged-in symptom reproduce for non-bugzilla sites? This sounds like it's getting something out of the keychain, but I'd have to look into it more. 1616908 7 pfeldman 2020-02-10 09:32:03 -0800 It fixes the symptoms, check out the exact lines of code that I pointed to in the first comment - they explain why this happens. There are also options for fixing, so it does not need to be random ids option. But random ones prevents similar problems from happening in the future. It is not localized to bugs.webkit.org, it is about all cookies in general that end up in a single store for seemingly isolated private sessions. 1617041 8 ap 2020-02-10 13:00:39 -0800 I can reproduce with Safari Tech Preview and steps in comment 3. I think that I had steps 4 and 5 reversed the last time. It's definitely not the keychain. I think that ultimately this is a CFNetwork issue - it probably should isolate ephemeral sessions even between processes with same bundle ID. But the patch seems like an improvement, because it at the very least avoids accidental leaks. Appending a PID of Networking or WebContent process may be reasonable too. Alex, what do you think? 1618643 9 pfeldman 2020-02-13 12:14:16 -0800 As per comment above, restoring r? for it to get another look. 1618761 10 390140 achristensen 2020-02-13 15:50:24 -0800 Comment on attachment 390140 Patch Not only does this not avoid collision with SessionID::LegacyPrivateSessionID, but it does not solve the real issue, which is probably something having to do with the cookie storage in NetworkSessionCocoa::NetworkSessionCocoa 1618762 11 achristensen 2020-02-13 15:50:51 -0800 We do not give CFNetwork this identifier 1618771 12 achristensen 2020-02-13 16:14:49 -0800 We implicitly give this to CFNetwork in _CFURLStorageSessionCreate 1618772 13 390702 achristensen 2020-02-13 16:18:25 -0800 Created attachment 390702 Patch 1618773 14 achristensen 2020-02-13 16:22:11 -0800 Pavel, using the PID would also not be as secure as we would like because PIDs are reused and there could be race conditions that still leak data. This solution is very similar to Pavel's suggested solution. With your permission I would like to list you as a coauthor of this patch. 1619037 15 pfeldman 2020-02-14 09:23:03 -0800 > Not only does this not avoid collision with SessionID::LegacyPrivateSessionID I believe it does. Collision here implies that the crypto-secure random is equal to en exact number, which is far less likely than the hardware DRAM error. > But it does not solve the real issue, which is probably something having to do with the cookie storage in NetworkSessionCocoa::NetworkSessionCocoa I believe it does since the solution you are proposing is addressing it via modifying the exact same token. > We do not give CFNetwork this identifier I believe we do, in the line you change |identifierBase| is built from the sessionID value. I pointed to the line in RemoteNetworkingContext.mm where we do it in my first comment to the bug. > This solution is very similar to Pavel's suggested solution. With your permission I would like to list you as a coauthor of this patch. Sure thing. But could you elaborate on why this could not be in a form of the review comment that I would address? 1619085 16 pfeldman 2020-02-14 10:55:11 -0800 Btw, I'm currently "inactive" reviewer, so I can't r+ your patch. I'm in the process of collecting patches to re-gain the status. All in all it looks good to me. I'd still prefer to randomize sessoinID so that it did not bite us in other places, but it addresses the issue in hand as is, so all is good. 1619524 17 390702 darin 2020-02-16 17:09:34 -0800 Comment on attachment 390702 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=390702&action=review > Source/WebKit/NetworkProcess/NetworkProcess.cpp:514 > + RetainPtr<CFStringRef> cfIdentifier = makeString(identifierBase, ".PrivateBrowsing.", createCanonicalUUIDString()).createCFString(); Why not just use a UUID? Is it important to include the identifier and the word “PrivateBrowsing”? Is that used in debugging or something? > Source/WebKitLegacy/WebCoreSupport/NetworkStorageSessionMap.cpp:89 > + RetainPtr<CFStringRef> cfIdentifier = makeString(identifierBase, ".PrivateBrowsing.", createCanonicalUUIDString()).createCFString(); Ditto. 1619842 18 pfeldman 2020-02-17 13:31:02 -0800 I don't think it is used anywhere, so using just the UUID should also work. 1619998 19 achristensen 2020-02-17 17:17:39 -0800 My claim "We do not give CFNetwork this identifier" was what we intend to be correct, but it is incorrect, hence the need for this change. Another reason I am opposed to randomizing session IDs is because the sessionID is a very useful debugging tool, and right now it is easy to see that this is the first ephemeral session, the second ephemeral session, etc. If we randomized it that would go away. We use a string that contains the bundle ID and "PrivateBrowsing" and now a UUID to help with debugging. I'd prefer to keep that rather than just use a UUID. 1619999 20 achristensen 2020-02-17 17:19:58 -0800 http://trac.webkit.org/r256792 1620000 21 webkit-bug-importer 2020-02-17 17:20:15 -0800 <rdar://problem/59533067> 1620180 22 darin 2020-02-18 09:23:22 -0800 (In reply to Alex Christensen from comment #19) > right now it is easy to see > that this is the first ephemeral session, the second ephemeral session, etc. > If we randomized it that would go away. I want to understand, but I don’t yet. I was looking and I don’t see a number that says "this is first, this is second", just a UUID. How is this not randomized? 1620231 23 achristensen 2020-02-18 11:05:54 -0800 (In reply to Darin Adler from comment #22) > (In reply to Alex Christensen from comment #19) > > right now it is easy to see > > that this is the first ephemeral session, the second ephemeral session, etc. > > If we randomized it that would go away. > > I want to understand, but I don’t yet. I was looking and I don’t see a > number that says "this is first, this is second", just a UUID. How is this > not randomized? PAL::SessionID::toUInt64 returns a value that returns such an integer. In other use of PAL::SessionID that was not changed in this patch, I often use this value in logging to debug things. 1620497 24 darin 2020-02-18 20:17:29 -0800 (In reply to Alex Christensen from comment #23) > PAL::SessionID::toUInt64 returns a value that returns such an integer. In > other use of PAL::SessionID that was not changed in this patch, I often use > this value in logging to debug things. OK, but what does PAL::SessionID have to do with the storage session identifier string? 1620943 25 pfeldman 2020-02-19 16:40:59 -0800 I believe the first comment to this bug contains the answer to your question. 390140 2020-02-07 15:49:47 -0800 2020-02-13 16:18:23 -0800 Patch bug-207404-20200207154946.patch text/plain 1988 pfeldman U3VidmVyc2lvbiBSZXZpc2lvbjogMjU2MDUxCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9Q QUwvQ2hhbmdlTG9nIGIvU291cmNlL1dlYkNvcmUvUEFML0NoYW5nZUxvZwppbmRleCA5NjgyNDg0 YjA2MGM5MjhiNTY5NTM3NjMzMDhlOTJjOGMyYjUxOTMzLi5kOTQ0NTY2YzZiZTI3MzVlYTQ1M2Ux OTQwNjY2Yjk4MzVmMTk1MDYwIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9QQUwvQ2hhbmdl TG9nCisrKyBiL1NvdXJjZS9XZWJDb3JlL1BBTC9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxNiBAQAor MjAyMC0wMi0wNyAgUGF2ZWwgRmVsZG1hbiAgPHBhdmVsLmZlbGRtYW5AZ21haWwuY29tPgorCisg ICAgICAgIEdlbmVyYXRlIGNyeXB0b2dyYXBoaWNhbGx5IHNlY3VyZSByYW5kb20gZXBoZW1lcmFs IFNlc3Npb25JRHMuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNn aT9pZD0yMDc0MDQKKworICAgICAgICBCZWZvcmUgdGhlIGNoYW5nZSwgc2Vzc2lvbiBpZHMgd2Vy ZSBzZXF1ZW50aWFsIGFuZCB0aGUgZGF0YSB3YXMgbGVha2luZworICAgICAgICBiZXR3ZWVuIGVw aGVtZXJhbCBzZXNzaW9ucyBvZiBkaWZmZXJlbnQgcHJvY2Vzc2VzLgorCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogcGFsL1Nlc3Npb25JRC5jcHA6Cisg ICAgICAgIChQQUw6OlNlc3Npb25JRDo6Z2VuZXJhdGVFcGhlbWVyYWxTZXNzaW9uSUQpOgorCiAy MDIwLTAyLTA3ICBTYW0gV2VpbmlnICA8d2VpbmlnQGFwcGxlLmNvbT4KIAogICAgICAgICBNb3Zl IHRyaXZpYWwgZGVmaW5pdGlvbnMgZnJvbSBGZWF0dXJlRGVmaW5lcy54Y2NvbmZpZyB0byBQbGF0 Zm9ybUVuYWJsZUNvY29hLmgKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL1BBTC9wYWwvU2Vz c2lvbklELmNwcCBiL1NvdXJjZS9XZWJDb3JlL1BBTC9wYWwvU2Vzc2lvbklELmNwcAppbmRleCA2 YjMwYjRhMDZiYWI0OGNhNjllNDk1NWU1MmNiNDE2MmJiMjA3ODBmLi43MGRlNDBhMzgxMzAwOWM1 MTZhZDRkZjczZGIxYWY5MTkxY2ZjOTJmIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9QQUwv cGFsL1Nlc3Npb25JRC5jcHAKKysrIGIvU291cmNlL1dlYkNvcmUvUEFML3BhbC9TZXNzaW9uSUQu Y3BwCkBAIC0yNiwxMiArMjYsMTIgQEAKICNpbmNsdWRlICJjb25maWcuaCIKICNpbmNsdWRlICJT ZXNzaW9uSUQuaCIKIAorI2luY2x1ZGUgPHd0Zi9DcnlwdG9ncmFwaGljYWxseVJhbmRvbU51bWJl ci5oPgogI2luY2x1ZGUgPHd0Zi9NYWluVGhyZWFkLmg+CiAKIG5hbWVzcGFjZSBQQUwgewogCiBz dGF0aWMgdWludDY0X3QgY3VycmVudFBlcnNpc3RlbnRJRCA9IFNlc3Npb25JRDo6RGVmYXVsdFNl c3Npb25JRDsKLXN0YXRpYyB1aW50NjRfdCBjdXJyZW50RXBoZW1lcmFsSUQgPSBTZXNzaW9uSUQ6 OkxlZ2FjeVByaXZhdGVTZXNzaW9uSUQ7CiBzdGF0aWMgYm9vbCBnZW5lcmF0aW9uUHJvdGVjdGlv bkVuYWJsZWQ7CiAKIFNlc3Npb25JRCBTZXNzaW9uSUQ6OmdlbmVyYXRlUGVyc2lzdGVudFNlc3Np b25JRCgpCkBAIC00Nyw3ICs0NywxMCBAQCBTZXNzaW9uSUQgU2Vzc2lvbklEOjpnZW5lcmF0ZUVw aGVtZXJhbFNlc3Npb25JRCgpCiAgICAgQVNTRVJUKGlzTWFpblRocmVhZCgpKTsKICAgICBSRUxF QVNFX0FTU0VSVCghZ2VuZXJhdGlvblByb3RlY3Rpb25FbmFibGVkKTsKIAotICAgIHJldHVybiBT ZXNzaW9uSUQoKytjdXJyZW50RXBoZW1lcmFsSUQpOworICAgIHVpbnQ2NF90IHNlc3Npb25JZDsK KyAgICBjcnlwdG9ncmFwaGljYWxseVJhbmRvbVZhbHVlcygmc2Vzc2lvbklkLCBzaXplb2Yoc2Vz c2lvbklkKSk7CisgICAgc2Vzc2lvbklkID0gc2Vzc2lvbklkIHwgU2Vzc2lvbkNvbnN0YW50czo6 RXBoZW1lcmFsU2Vzc2lvbk1hc2s7CisgICAgcmV0dXJuIFNlc3Npb25JRChzZXNzaW9uSWQpOwog fQogCiB2b2lkIFNlc3Npb25JRDo6ZW5hYmxlR2VuZXJhdGlvblByb3RlY3Rpb24oKQo= 390702 2020-02-13 16:18:25 -0800 2020-02-16 17:09:34 -0800 Patch bug-207404-20200213161824.patch text/plain 3770 achristensen SW5kZXg6IFNvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJL aXQvQ2hhbmdlTG9nCShyZXZpc2lvbiAyNTY1NzEpCisrKyBTb3VyY2UvV2ViS2l0L0NoYW5nZUxv Zwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDIwIEBACisyMDIwLTAyLTEzICBBbGV4IENocmlz dGVuc2VuICA8YWNocmlzdGVuc2VuQHdlYmtpdC5vcmc+CisKKyAgICAgICAgRXBoZW1lcmFsIHNl c3Npb24gZGF0YSBsZWFrcyBiZXR3ZWVuIHByb2Nlc3NlcworICAgICAgICBodHRwczovL2J1Z3Mu d2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjA3NDA0CisKKyAgICAgICAgUmV2aWV3ZWQgYnkg Tk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgSWYgdHdvIHByb2Nlc3NlcyB3aXRoIHRoZSBzYW1l IGJ1bmRsZSBpZGVudGlmaWVyIGNyZWF0ZSBhbiBlcGhlbWVyYWwgV0tXZWJzaXRlRGF0YVN0b3Jl LCB3ZSB3ZXJlIGNhbGxpbmcKKyAgICAgICAgX0NGVVJMU3RvcmFnZVNlc3Npb25DcmVhdGUgd2l0 aCB0aGUgc2FtZSBzdHJpbmcsIHdoaWNoIGNhdXNlZCBvdXIgY29va2llcyB0byBiZSBzaGFyZWQu ICBUbyBwcmV2ZW50IHRoaXMsCisgICAgICAgIGFkZCBhIFVVSUQgdG8gdGhlIGlkZW50aWZpZXIg dG8gbWFrZSB0aGVtIHRydWx5IHVuaXF1ZS4KKworICAgICAgICBXZSBkb24ndCBoYXZlIHRlc3Qg aW5mcmFzdHJ1Y3R1cmUgZm9yIG11bHRpcGxlIFVJIHByb2Nlc3NlcyBhdCB0aGUgc2FtZSB0aW1l LCBidXQgSSBtYW51YWxseSB2ZXJpZmllZAorICAgICAgICB0aGF0IHRoaXMgZml4ZXMgdGhlIGJ1 Zy4KKworICAgICAgICAqIE5ldHdvcmtQcm9jZXNzL05ldHdvcmtQcm9jZXNzLmNwcDoKKyAgICAg ICAgKFdlYktpdDo6TmV0d29ya1Byb2Nlc3M6OmVuc3VyZVNlc3Npb24pOgorCiAyMDIwLTAyLTEz ICBCcmVudCBGdWxnaGFtICA8YmZ1bGdoYW1AYXBwbGUuY29tPgogCiAgICAgICAgIFJFR1JFU1NJ T04gKHIyNTU5NjEpOiBEZWZhdWx0IHN0YXRlIGZvciBkYXRhIFVSTCBoYW5kbGluZyBpcyBpbmNv cnJlY3QKSW5kZXg6IFNvdXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3MvTmV0d29ya1Byb2Nlc3Mu Y3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3MvTmV0d29ya1By b2Nlc3MuY3BwCShyZXZpc2lvbiAyNTYzNDYpCisrKyBTb3VyY2UvV2ViS2l0L05ldHdvcmtQcm9j ZXNzL05ldHdvcmtQcm9jZXNzLmNwcAkod29ya2luZyBjb3B5KQpAQCAtODYsNiArODYsNyBAQAog I2luY2x1ZGUgPHd0Zi9PcHRpb25TZXQuaD4KICNpbmNsdWRlIDx3dGYvUHJvY2Vzc1ByaXZpbGVn ZS5oPgogI2luY2x1ZGUgPHd0Zi9SdW5Mb29wLmg+CisjaW5jbHVkZSA8d3RmL1VVSUQuaD4KICNp bmNsdWRlIDx3dGYvVW5pcXVlUmVmLmg+CiAjaW5jbHVkZSA8d3RmL3RleHQvQXRvbVN0cmluZy5o PgogCkBAIC01MTAsNyArNTExLDcgQEAgdm9pZCBOZXR3b3JrUHJvY2Vzczo6ZW5zdXJlU2Vzc2lv bihjb25zdAogICAgIAogI2lmIFBMQVRGT1JNKENPQ09BKQogICAgIFJldGFpblB0cjxDRlVSTFN0 b3JhZ2VTZXNzaW9uUmVmPiBzdG9yYWdlU2Vzc2lvbjsKLSAgICBSZXRhaW5QdHI8Q0ZTdHJpbmdS ZWY+IGNmSWRlbnRpZmllciA9IFN0cmluZyhpZGVudGlmaWVyQmFzZSArICIuUHJpdmF0ZUJyb3dz aW5nIikuY3JlYXRlQ0ZTdHJpbmcoKTsKKyAgICBSZXRhaW5QdHI8Q0ZTdHJpbmdSZWY+IGNmSWRl bnRpZmllciA9IG1ha2VTdHJpbmcoaWRlbnRpZmllckJhc2UsICIuUHJpdmF0ZUJyb3dzaW5nLiIs IGNyZWF0ZUNhbm9uaWNhbFVVSURTdHJpbmcoKSkuY3JlYXRlQ0ZTdHJpbmcoKTsKICAgICBpZiAo c2Vzc2lvbklELmlzRXBoZW1lcmFsKCkpCiAgICAgICAgIHN0b3JhZ2VTZXNzaW9uID0gYWRvcHRD RihjcmVhdGVQcml2YXRlU3RvcmFnZVNlc3Npb24oY2ZJZGVudGlmaWVyLmdldCgpKSk7CiAgICAg ZWxzZQpJbmRleDogU291cmNlL1dlYktpdExlZ2FjeS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g U291cmNlL1dlYktpdExlZ2FjeS9DaGFuZ2VMb2cJKHJldmlzaW9uIDI1NjU3MSkKKysrIFNvdXJj ZS9XZWJLaXRMZWdhY3kvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTMgQEAK KzIwMjAtMDItMTMgIEFsZXggQ2hyaXN0ZW5zZW4gIDxhY2hyaXN0ZW5zZW5Ad2Via2l0Lm9yZz4K KworICAgICAgICBFcGhlbWVyYWwgc2Vzc2lvbiBkYXRhIGxlYWtzIGJldHdlZW4gcHJvY2Vzc2Vz CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yMDc0MDQK KworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICAqIFdlYkNv cmVTdXBwb3J0L05ldHdvcmtTdG9yYWdlU2Vzc2lvbk1hcC5jcHA6CisgICAgICAgIChOZXR3b3Jr U3RvcmFnZVNlc3Npb25NYXA6OmVuc3VyZVNlc3Npb24pOgorCiAyMDIwLTAyLTExICBGdWppaSBI aXJvbm9yaSAgPEhpcm9ub3JpLkZ1amlpQHNvbnkuY29tPgogCiAgICAgICAgIEZpeCBkZWNsYXJh dGlvbnMgbWFya2VkIGJ5IHdyb25nIGV4cG9ydCBtYWNyb3MgKFdFQkNPUkVfRVhQT1JUIGFuZCBX VEZfRVhQT1JUKQpJbmRleDogU291cmNlL1dlYktpdExlZ2FjeS9XZWJDb3JlU3VwcG9ydC9OZXR3 b3JrU3RvcmFnZVNlc3Npb25NYXAuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJLaXRMZWdh Y3kvV2ViQ29yZVN1cHBvcnQvTmV0d29ya1N0b3JhZ2VTZXNzaW9uTWFwLmNwcAkocmV2aXNpb24g MjU2MzQ2KQorKysgU291cmNlL1dlYktpdExlZ2FjeS9XZWJDb3JlU3VwcG9ydC9OZXR3b3JrU3Rv cmFnZVNlc3Npb25NYXAuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0zMCw2ICszMCw3IEBACiAjaW5j bHVkZSA8d3RmL01haW5UaHJlYWQuaD4KICNpbmNsdWRlIDx3dGYvUHJvY2Vzc0lELmg+CiAjaW5j bHVkZSA8d3RmL1Byb2Nlc3NQcml2aWxlZ2UuaD4KKyNpbmNsdWRlIDx3dGYvVVVJRC5oPgogI2lu Y2x1ZGUgPHd0Zi90ZXh0L1N0cmluZ0NvbmNhdGVuYXRlTnVtYmVycy5oPgogCiBzdGF0aWMgc3Rk Ojp1bmlxdWVfcHRyPFdlYkNvcmU6Ok5ldHdvcmtTdG9yYWdlU2Vzc2lvbj4mIGRlZmF1bHROZXR3 b3JrU3RvcmFnZVNlc3Npb24oKQpAQCAtODUsNyArODYsNyBAQCB2b2lkIE5ldHdvcmtTdG9yYWdl U2Vzc2lvbk1hcDo6ZW5zdXJlU2VzCiAgICAgaWYgKCFhZGRSZXN1bHQuaXNOZXdFbnRyeSkKICAg ICAgICAgcmV0dXJuOwogCi0gICAgUmV0YWluUHRyPENGU3RyaW5nUmVmPiBjZklkZW50aWZpZXIg PSBTdHJpbmcoaWRlbnRpZmllckJhc2UgKyAiLlByaXZhdGVCcm93c2luZyIpLmNyZWF0ZUNGU3Ry aW5nKCk7CisgICAgUmV0YWluUHRyPENGU3RyaW5nUmVmPiBjZklkZW50aWZpZXIgPSBtYWtlU3Ry aW5nKGlkZW50aWZpZXJCYXNlLCAiLlByaXZhdGVCcm93c2luZy4iLCBjcmVhdGVDYW5vbmljYWxV VUlEU3RyaW5nKCkpLmNyZWF0ZUNGU3RyaW5nKCk7CiAKICAgICBSZXRhaW5QdHI8Q0ZVUkxTdG9y YWdlU2Vzc2lvblJlZj4gc3RvcmFnZVNlc3Npb247CiAgICAgaWYgKHNlc3Npb25JRC5pc0VwaGVt ZXJhbCgpKQo=