184068 2018-03-27 19:34:25 -0700 WebSocket::didReceiveMessage() may construct a SecurityOrigin object on a non-main thread 2018-04-05 10:32:33 -0700 1 1 1 Unclassified WebKit WebCore Misc. WebKit Nightly Build Unspecified Unspecified RESOLVED WONTFIX InRadar P2 Normal --- 184059 1 cdumez cdumez ap dbates webkit-bug-importer youennf oldest_to_newest 1409758 0 cdumez 2018-03-27 19:34:25 -0700 WebSocket::didReceiveMessage() may construct a SecurityOrigin object on a non-main thread, which is not safe. 1409759 1 336637 cdumez 2018-03-27 19:35:36 -0700 Created attachment 336637 Patch 1409773 2 336641 cdumez 2018-03-27 20:34:53 -0700 Created attachment 336641 Patch 1410007 3 336641 youennf 2018-03-28 13:09:45 -0700 Comment on attachment 336641 Patch Maybe we could assert in SecurityOriginData::toString that URL is http/https/ws/wss. 1410013 4 336641 cdumez 2018-03-28 13:17:09 -0700 Comment on attachment 336641 Patch Clearing flags on attachment: 336641 Committed r230042: <https://trac.webkit.org/changeset/230042> 1410014 5 cdumez 2018-03-28 13:17:10 -0700 All reviewed patches have been landed. Closing bug. 1410016 6 webkit-bug-importer 2018-03-28 13:18:14 -0700 <rdar://problem/38969197> 1410150 7 336641 dbates 2018-03-28 18:41:44 -0700 Comment on attachment 336641 Patch This patch is not right. SecurityOriginData::toString() is not equivalent to SecurityOrigin::toString(). We need to stop and think before transitioning any any more WebCore code to SecurityOriginData. It is not safe to do so. 1410152 8 youennf 2018-03-28 18:59:14 -0700 (In reply to Daniel Bates from comment #7) > Comment on attachment 336641 [details] > Patch > > This patch is not right. SecurityOriginData::toString() is not equivalent to > SecurityOrigin::toString(). We need to stop and think before transitioning > any any more WebCore code to SecurityOriginData. It is not safe to do so. In that particular case, the URL is ws or wss, so I think this patch is correct as per https://url.spec.whatwg.org/#concept-url-origin. 1410166 9 dbates 2018-03-28 20:13:22 -0700 (In reply to youenn fablet from comment #8) > (In reply to Daniel Bates from comment #7) > > Comment on attachment 336641 [details] > > Patch > > > > This patch is not right. SecurityOriginData::toString() is not equivalent to > > SecurityOrigin::toString(). We need to stop and think before transitioning > > any any more WebCore code to SecurityOriginData. It is not safe to do so. > > In that particular case, the URL is ws or wss, so I think this patch is > correct as per https://url.spec.whatwg.org/#concept-url-origin. This is not the correct section of the spec. to reference. Take m_url to be the parsed URL corresponding to ws://example.com. Let D be the result of SecurityOriginData::fromURL(m_url) and S be the result of SecurityOrigin::create(m_url). Then D.toString() = "ws://example.com:0" != "ws://example.com" = S.toString(). Disregarding the aforementioned correctness issue, this patch is self-contradictory because it only "fixes" the usage of SecurityOrigin in WebSocket::didReceiveMessage(). It does not fix other uses of SecurityOrigin::create(m_url) in WebSocket::didReceiveBinaryData(). Regardless, I disagree with the approach of transitioning code from SecurityOrigin to SecurityOriginData in WebCore. 1410168 10 cdumez 2018-03-28 20:18:53 -0700 (In reply to Daniel Bates from comment #9) > (In reply to youenn fablet from comment #8) > > (In reply to Daniel Bates from comment #7) > > > Comment on attachment 336641 [details] > > > Patch > > > > > > This patch is not right. SecurityOriginData::toString() is not equivalent to > > > SecurityOrigin::toString(). We need to stop and think before transitioning > > > any any more WebCore code to SecurityOriginData. It is not safe to do so. > > > > In that particular case, the URL is ws or wss, so I think this patch is > > correct as per https://url.spec.whatwg.org/#concept-url-origin. > > This is not the correct section of the spec. to reference. > > Take m_url to be the parsed URL corresponding to ws://example.com. Let D be > the result of SecurityOriginData::fromURL(m_url) and S be the result of > SecurityOrigin::create(m_url). Then D.toString() = "ws://example.com:0" != > "ws://example.com" = S.toString(). Where is "ws://example.com:0" coming from? D.toString() would return "ws://example.com" (as of last week end). > > Disregarding the aforementioned correctness issue, this patch is > self-contradictory because it only "fixes" the usage of SecurityOrigin in > WebSocket::didReceiveMessage(). It does not fix other uses of > SecurityOrigin::create(m_url) in WebSocket::didReceiveBinaryData(). I am still going though the assertion failures and fixing them as I find them. > Regardless, I disagree with the approach of transitioning code from > SecurityOrigin to SecurityOriginData in WebCore. 1410173 11 dbates 2018-03-28 20:30:04 -0700 (In reply to Chris Dumez from comment #10) > (In reply to Daniel Bates from comment #9) > > (In reply to youenn fablet from comment #8) > > > (In reply to Daniel Bates from comment #7) > > > > Comment on attachment 336641 [details] > > > > Patch > > > > > > > > This patch is not right. SecurityOriginData::toString() is not equivalent to > > > > SecurityOrigin::toString(). We need to stop and think before transitioning > > > > any any more WebCore code to SecurityOriginData. It is not safe to do so. > > > > > > In that particular case, the URL is ws or wss, so I think this patch is > > > correct as per https://url.spec.whatwg.org/#concept-url-origin. > > > > This is not the correct section of the spec. to reference. > > > > Take m_url to be the parsed URL corresponding to ws://example.com. Let D be > > the result of SecurityOriginData::fromURL(m_url) and S be the result of > > SecurityOrigin::create(m_url). Then D.toString() = "ws://example.com:0" != > > "ws://example.com" = S.toString(). > > Where is "ws://example.com:0" coming from? D.toString() would return > "ws://example.com" (as of last week end). > Oops, I was looking at an old revision. I see that <https://trac.webkit.org/changeset/229954/> fixed up SecurityOriginData::toString(). Regardless, I do not like the direction of where we are going with SecurityOriginData. Both SecurityOrigin::toString() and SecurityOriginData::toString() are implementing some subset of the origin serialization algorithm. 1410174 12 cdumez 2018-03-28 20:33:53 -0700 (In reply to Daniel Bates from comment #11) > (In reply to Chris Dumez from comment #10) > > (In reply to Daniel Bates from comment #9) > > > (In reply to youenn fablet from comment #8) > > > > (In reply to Daniel Bates from comment #7) > > > > > Comment on attachment 336641 [details] > > > > > Patch > > > > > > > > > > This patch is not right. SecurityOriginData::toString() is not equivalent to > > > > > SecurityOrigin::toString(). We need to stop and think before transitioning > > > > > any any more WebCore code to SecurityOriginData. It is not safe to do so. > > > > > > > > In that particular case, the URL is ws or wss, so I think this patch is > > > > correct as per https://url.spec.whatwg.org/#concept-url-origin. > > > > > > This is not the correct section of the spec. to reference. > > > > > > Take m_url to be the parsed URL corresponding to ws://example.com. Let D be > > > the result of SecurityOriginData::fromURL(m_url) and S be the result of > > > SecurityOrigin::create(m_url). Then D.toString() = "ws://example.com:0" != > > > "ws://example.com" = S.toString(). > > > > Where is "ws://example.com:0" coming from? D.toString() would return > > "ws://example.com" (as of last week end). > > > > Oops, I was looking at an old revision. I see that > <https://trac.webkit.org/changeset/229954/> fixed up > SecurityOriginData::toString(). Regardless, I do not like the direction of > where we are going with SecurityOriginData. Both SecurityOrigin::toString() > and SecurityOriginData::toString() are implementing some subset of the > origin serialization algorithm. What is your alternative proposal here? Note that there are more usage of SecurityOrigin::create() on non-main threads than we originally thought. Maybe we should just give up and make SecurityOrigin::create() safe to call from a background thread? What do you guys think? 1410177 13 youennf 2018-03-28 20:46:32 -0700 It seems to me that what we need is a thread safe way to serialize an origin directly from an URL. Maybe this is simpler to implement than a fully thread safe SecurityOrigin. 1410178 14 cdumez 2018-03-28 20:51:18 -0700 (In reply to youenn fablet from comment #13) > It seems to me that what we need is a thread safe way to serialize an origin > directly from an URL. Maybe this is simpler to implement than a fully thread > safe SecurityOrigin. We are saying the same thing, I never said anything about making SecurityOrigin (fully) thread safe. I just want to make it OK to call SecurityOrigin::create(url) from a background thread. Similar to String. It is safe to construct a String on any thread. It is not safe to pass a string to another thread unless you isolatecopy. We could do the same for SecurityOrigin. 1410181 15 dbates 2018-03-28 21:00:52 -0700 (In reply to Chris Dumez from comment #10) > > > > Disregarding the aforementioned correctness issue, this patch is > > self-contradictory because it only "fixes" the usage of SecurityOrigin in > > WebSocket::didReceiveMessage(). It does not fix other uses of > > SecurityOrigin::create(m_url) in WebSocket::didReceiveBinaryData(). > I am still going though the assertion failures and fixing them as I find > them. > This is playing whack-a-mole with our security and thread safety. This does not seem like a good strategy that will lead to high confidence of correctness and quality software. This strategy assumes that we have perfect test coverage both covering all WebCore lines of code AND covering all possible test cases because we only hit an assertion failure if execution passes over the asserted code. I would hope we have test coverage to cover WebSocket::didReceiveBinaryData() being called from a background thread. I do not have the list of tests that cause assertion failures that you are working through (please file bugs instead of keeping them in your head or waiting for others to hit the assertion failures). According to <https://bugs.webkit.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&chfield=%5BBug%20creation%5D&chfieldfrom=2018-03-27&chfieldto=2018-03-28&email1=cdumez%40apple.com&emailreporter1=1&emailtype1=substring&list_id=3588091&query_format=advanced> I see only two bugs about assertion failures filed between yesterday and today: (This bug) WebSocket::didReceiveMessage() may construct a SecurityOrigin object on a non-main thread <https://bugs.webkit.org/show_bug.cgi?id=184068> And Thread safety issue in IDBFactory' shouldThrowSecurityException() <https://bugs.webkit.org/show_bug.cgi?id=184064> Instead I suggest we use the assertion failures are a guide, together with a strategy of grep'ing for all SecurityOrigin usage around the assert that failed (would have caught the issue in WebSocket::didReceiveBinaryData()), as well as grep'ing all of WebCore and auditing threaded code. Filed bug #184125 to fix up WebSocket::didReceiveBinaryData(). 1410185 16 cdumez 2018-03-28 21:30:17 -0700 (In reply to Daniel Bates from comment #15) > (In reply to Chris Dumez from comment #10) > > > > > > Disregarding the aforementioned correctness issue, this patch is > > > self-contradictory because it only "fixes" the usage of SecurityOrigin in > > > WebSocket::didReceiveMessage(). It does not fix other uses of > > > SecurityOrigin::create(m_url) in WebSocket::didReceiveBinaryData(). > > I am still going though the assertion failures and fixing them as I find > > them. > > > > This is playing whack-a-mole with our security and thread safety. This does > not seem like a good strategy that will lead to high confidence of > correctness and quality software. This strategy assumes that we have perfect > test coverage both covering all WebCore lines of code AND covering all > possible test cases because we only hit an assertion failure if execution > passes over the asserted code. I would hope we have test coverage to cover > WebSocket::didReceiveBinaryData() being called from a background thread. I > do not have the list of tests that cause assertion failures that you are > working through (please file bugs instead of keeping them in your head or > waiting for others to hit the assertion failures). According to > <https://bugs.webkit.org/buglist. > cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOP > ENED&bug_status=RESOLVED&chfield=%5BBug%20creation%5D&chfieldfrom=2018-03- > 27&chfieldto=2018-03-28&email1=cdumez%40apple. > com&emailreporter1=1&emailtype1=substring&list_id=3588091&query_format=advanc > ed> I see only two bugs about assertion failures filed between yesterday and > today: > > (This bug) WebSocket::didReceiveMessage() may construct a SecurityOrigin > object on a non-main thread > <https://bugs.webkit.org/show_bug.cgi?id=184068> > > And > > Thread safety issue in IDBFactory' shouldThrowSecurityException() > <https://bugs.webkit.org/show_bug.cgi?id=184064> > > Instead I suggest we use the assertion failures are a guide, together with a > strategy of grep'ing for all SecurityOrigin usage around the assert that > failed (would have caught the issue in WebSocket::didReceiveBinaryData()), > as well as grep'ing all of WebCore and auditing threaded code. > > Filed bug #184125 to fix up WebSocket::didReceiveBinaryData(). I have landed at least 5 patches already and still not done. SecurityOrigin is already almost safe to construct from a background thread and making it fully safe would likely be less work and avoid annoying refactorings (especially if you do not want to use SecurityOriginData in WebCore). 1410187 17 youennf 2018-03-28 22:16:34 -0700 Some thoughts. From what I see, for serializing an origin from an URL, calling shouldTreatAsPotentiallyTrustworthy is not needed. The serialization just needs to know a SecurityOriginData and a isUnique boolean. We could have something like: - A "String serializeURLOrigin(const URL&)" utility function. - serializeURLOrigin and SecurityOrigin would use an underlying function taking a SecurityOriginData and a isUnique boolean. As of the computation of the isUnique value from background threads, we could make shouldTreatAsUniqueOrigin thread safe. It seems that http/https/ws/wss/ftp/data/blob could be special cased for efficiency. Not sure about blobs though. Maybe callOnMainThreadAndWait to create a temporary SecurityOrigin is good enough. 1410261 18 cdumez 2018-03-29 08:10:44 -0700 (In reply to youenn fablet from comment #17) > Some thoughts. > > From what I see, for serializing an origin from an URL, calling > shouldTreatAsPotentiallyTrustworthy is not needed. > The serialization just needs to know a SecurityOriginData and a isUnique > boolean. > > We could have something like: > - A "String serializeURLOrigin(const URL&)" utility function. > - serializeURLOrigin and SecurityOrigin would use an underlying function > taking a SecurityOriginData and a isUnique boolean. > > As of the computation of the isUnique value from background threads, we > could make shouldTreatAsUniqueOrigin thread safe. > It seems that http/https/ws/wss/ftp/data/blob could be special cased for > efficiency. > > Not sure about blobs though. > Maybe callOnMainThreadAndWait to create a temporary SecurityOrigin is good > enough. this is not just about serialization. What if we need to know if an URL is cross origin synchronously from a background thread? Then we’d need canAccess() too. 1410287 19 youennf 2018-03-29 09:33:00 -0700 > this is not just about serialization. What if we need to know if an URL is > cross origin synchronously from a background thread? Then we’d need > canAccess() too. Yeah... then it seems that making SecurityOrigin fully thread-safe seems like the safest approach. FWIW, looking at CSP implementation, we might need to sync some SchemeRegistries to NetworkProcess. It seems natural then to try syncing all of them and make SecurityOrigin usable in NetworkProcess. That would extend the scope of usage of SecurityOrigin, which would increase the risk for unnoticed usage of SecurityOrigin in background threads. I think that for now it will be main thread only. 1410305 20 dbates 2018-03-29 10:35:39 -0700 (In reply to Chris Dumez from comment #12) > (In reply to Daniel Bates from comment #11) > > (In reply to Chris Dumez from comment #10) > > > (In reply to Daniel Bates from comment #9) > > > > (In reply to youenn fablet from comment #8) > > > > > (In reply to Daniel Bates from comment #7) > > > > > > Comment on attachment 336641 [details] > > > > > > Patch > > > > > > > > > > > > This patch is not right. SecurityOriginData::toString() is not equivalent to > > > > > > SecurityOrigin::toString(). We need to stop and think before transitioning > > > > > > any any more WebCore code to SecurityOriginData. It is not safe to do so. > > > > > > > > > > In that particular case, the URL is ws or wss, so I think this patch is > > > > > correct as per https://url.spec.whatwg.org/#concept-url-origin. > > > > > > > > This is not the correct section of the spec. to reference. > > > > > > > > Take m_url to be the parsed URL corresponding to ws://example.com. Let D be > > > > the result of SecurityOriginData::fromURL(m_url) and S be the result of > > > > SecurityOrigin::create(m_url). Then D.toString() = "ws://example.com:0" != > > > > "ws://example.com" = S.toString(). > > > > > > Where is "ws://example.com:0" coming from? D.toString() would return > > > "ws://example.com" (as of last week end). > > > > > > > Oops, I was looking at an old revision. I see that > > <https://trac.webkit.org/changeset/229954/> fixed up > > SecurityOriginData::toString(). Regardless, I do not like the direction of > > where we are going with SecurityOriginData. Both SecurityOrigin::toString() > > and SecurityOriginData::toString() are implementing some subset of the > > origin serialization algorithm. > > What is your alternative proposal here? > > Note that there are more usage of SecurityOrigin::create() on non-main > threads than we originally thought. Maybe we should just give up and make > SecurityOrigin::create() safe to call from a background thread? What do you > guys think? Make SecurityOrigin thread-safe. 1410310 21 cdumez 2018-03-29 10:41:40 -0700 (In reply to Daniel Bates from comment #20) > (In reply to Chris Dumez from comment #12) > > (In reply to Daniel Bates from comment #11) > > > (In reply to Chris Dumez from comment #10) > > > > (In reply to Daniel Bates from comment #9) > > > > > (In reply to youenn fablet from comment #8) > > > > > > (In reply to Daniel Bates from comment #7) > > > > > > > Comment on attachment 336641 [details] > > > > > > > Patch > > > > > > > > > > > > > > This patch is not right. SecurityOriginData::toString() is not equivalent to > > > > > > > SecurityOrigin::toString(). We need to stop and think before transitioning > > > > > > > any any more WebCore code to SecurityOriginData. It is not safe to do so. > > > > > > > > > > > > In that particular case, the URL is ws or wss, so I think this patch is > > > > > > correct as per https://url.spec.whatwg.org/#concept-url-origin. > > > > > > > > > > This is not the correct section of the spec. to reference. > > > > > > > > > > Take m_url to be the parsed URL corresponding to ws://example.com. Let D be > > > > > the result of SecurityOriginData::fromURL(m_url) and S be the result of > > > > > SecurityOrigin::create(m_url). Then D.toString() = "ws://example.com:0" != > > > > > "ws://example.com" = S.toString(). > > > > > > > > Where is "ws://example.com:0" coming from? D.toString() would return > > > > "ws://example.com" (as of last week end). > > > > > > > > > > Oops, I was looking at an old revision. I see that > > > <https://trac.webkit.org/changeset/229954/> fixed up > > > SecurityOriginData::toString(). Regardless, I do not like the direction of > > > where we are going with SecurityOriginData. Both SecurityOrigin::toString() > > > and SecurityOriginData::toString() are implementing some subset of the > > > origin serialization algorithm. > > > > What is your alternative proposal here? > > > > Note that there are more usage of SecurityOrigin::create() on non-main > > threads than we originally thought. Maybe we should just give up and make > > SecurityOrigin::create() safe to call from a background thread? What do you > > guys think? > > Make SecurityOrigin thread-safe. Ok, then I think we are now all in agreement. Let's do this. It will be easier and less error-prone. 1412088 22 cdumez 2018-04-05 10:32:15 -0700 Reverted r230042 for reason: It is no longer needed now that it is safe to construct a SecurityOrigin from an on-main thread Committed r230305: <https://trac.webkit.org/changeset/230305> 1412089 23 cdumez 2018-04-05 10:32:33 -0700 No longer needed. 336637 2018-03-27 19:35:36 -0700 2018-03-27 20:34:52 -0700 Patch bug-184068-20180327193535.patch text/plain 1764 cdumez U3VidmVyc2lvbiBSZXZpc2lvbjogMjMwMDE4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggMDMxNTNlY2E5NGEyNjQz OGNlYzA2NTE5OTBjMmU1Y2Q0MWVmNjJjOS4uMTA5NjAwZDU3MWI3NTdkNzU1Yjc3MDc3YjhjN2Uw M2UxMzgyOGZlYiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE3IEBACisyMDE4LTAzLTI3ICBDaHJp cyBEdW1leiAgPGNkdW1lekBhcHBsZS5jb20+CisKKyAgICAgICAgV2ViU29ja2V0OjpkaWRSZWNl aXZlTWVzc2FnZSgpIG1heSBjb25zdHJ1Y3QgYSBTZWN1cml0eU9yaWdpbiBvYmplY3Qgb24gYSBu b24tbWFpbiB0aHJlYWQKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTE4NDA2OAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisg ICAgICAgIFdlYlNvY2tldDo6ZGlkUmVjZWl2ZU1lc3NhZ2UoKSBtYXkgY29uc3RydWN0IGEgU2Vj dXJpdHlPcmlnaW4gb2JqZWN0IG9uIGEgbm9uLW1haW4gdGhyZWFkLAorICAgICAgICB3aGljaCBp cyBub3Qgc2FmZS4gV2Ugbm93IHVzZSBTZWN1cml0eU9yaWdpbkRhdGEgc2luY2Ugd2Ugb25seSBu ZWVkIGFuIG9yaWdpbiBTdHJpbmcgYW5kCisgICAgICAgIGl0IGlzIHNhZmUgdG8gY29uc3RydWN0 IGEgU2VjdXJpdHlPcmlnaW5EYXRhIG9uIGFueSB0aHJlYWQuCisKKyAgICAgICAgKiBNb2R1bGVz L3dlYnNvY2tldHMvV2ViU29ja2V0LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OldlYlNvY2tldDo6 ZGlkUmVjZWl2ZU1lc3NhZ2UpOgorCiAyMDE4LTAzLTI3ICBDaHJpcyBEdW1leiAgPGNkdW1lekBh cHBsZS5jb20+CiAKICAgICAgICAgTWFrZSBpdCBwb3NzaWJsZSB0byBjYWxsIENvbnRlbnRTZWN1 cml0eVBvbGljeTo6dXBncmFkZUluc2VjdXJlUmVxdWVzdElmTmVlZGVkKCkgZnJvbSBub24tbWFp biB0aHJlYWRzCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9Nb2R1bGVzL3dlYnNvY2tldHMv V2ViU29ja2V0LmNwcCBiL1NvdXJjZS9XZWJDb3JlL01vZHVsZXMvd2Vic29ja2V0cy9XZWJTb2Nr ZXQuY3BwCmluZGV4IGQwMDJjMGIxODI2NDNlMTAyOGE5ZjRkOTYwOTE5ZDQ0ZTdlZjYxMmYuLmM3 NjAzYWY5MGE3YTc2MGFlZWNlZTk2MGUwYTMyMDNmYjA4MGYwZDAgMTAwNjQ0Ci0tLSBhL1NvdXJj ZS9XZWJDb3JlL01vZHVsZXMvd2Vic29ja2V0cy9XZWJTb2NrZXQuY3BwCisrKyBiL1NvdXJjZS9X ZWJDb3JlL01vZHVsZXMvd2Vic29ja2V0cy9XZWJTb2NrZXQuY3BwCkBAIC01NzIsNyArNTcyLDcg QEAgdm9pZCBXZWJTb2NrZXQ6OmRpZFJlY2VpdmVNZXNzYWdlKGNvbnN0IFN0cmluZyYgbXNnKQog ICAgIGlmIChtX3N0YXRlICE9IE9QRU4pCiAgICAgICAgIHJldHVybjsKICAgICBBU1NFUlQoc2Ny aXB0RXhlY3V0aW9uQ29udGV4dCgpKTsKLSAgICBkaXNwYXRjaEV2ZW50KE1lc3NhZ2VFdmVudDo6 Y3JlYXRlKG1zZywgU2VjdXJpdHlPcmlnaW46OmNyZWF0ZShtX3VybCktPnRvU3RyaW5nKCkpKTsK KyAgICBkaXNwYXRjaEV2ZW50KE1lc3NhZ2VFdmVudDo6Y3JlYXRlKG1zZywgU2VjdXJpdHlPcmln aW5EYXRhOjpmcm9tVVJMKG1fdXJsKS0+dG9TdHJpbmcoKSkpOwogfQogCiB2b2lkIFdlYlNvY2tl dDo6ZGlkUmVjZWl2ZUJpbmFyeURhdGEoVmVjdG9yPHVpbnQ4X3Q+JiYgYmluYXJ5RGF0YSkK 336641 2018-03-27 20:34:53 -0700 2018-03-28 13:17:09 -0700 Patch bug-184068-20180327203453.patch text/plain 1763 cdumez U3VidmVyc2lvbiBSZXZpc2lvbjogMjMwMDE4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggMDMxNTNlY2E5NGEyNjQz OGNlYzA2NTE5OTBjMmU1Y2Q0MWVmNjJjOS4uMTA5NjAwZDU3MWI3NTdkNzU1Yjc3MDc3YjhjN2Uw M2UxMzgyOGZlYiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE3IEBACisyMDE4LTAzLTI3ICBDaHJp cyBEdW1leiAgPGNkdW1lekBhcHBsZS5jb20+CisKKyAgICAgICAgV2ViU29ja2V0OjpkaWRSZWNl aXZlTWVzc2FnZSgpIG1heSBjb25zdHJ1Y3QgYSBTZWN1cml0eU9yaWdpbiBvYmplY3Qgb24gYSBu b24tbWFpbiB0aHJlYWQKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTE4NDA2OAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisg ICAgICAgIFdlYlNvY2tldDo6ZGlkUmVjZWl2ZU1lc3NhZ2UoKSBtYXkgY29uc3RydWN0IGEgU2Vj dXJpdHlPcmlnaW4gb2JqZWN0IG9uIGEgbm9uLW1haW4gdGhyZWFkLAorICAgICAgICB3aGljaCBp cyBub3Qgc2FmZS4gV2Ugbm93IHVzZSBTZWN1cml0eU9yaWdpbkRhdGEgc2luY2Ugd2Ugb25seSBu ZWVkIGFuIG9yaWdpbiBTdHJpbmcgYW5kCisgICAgICAgIGl0IGlzIHNhZmUgdG8gY29uc3RydWN0 IGEgU2VjdXJpdHlPcmlnaW5EYXRhIG9uIGFueSB0aHJlYWQuCisKKyAgICAgICAgKiBNb2R1bGVz L3dlYnNvY2tldHMvV2ViU29ja2V0LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OldlYlNvY2tldDo6 ZGlkUmVjZWl2ZU1lc3NhZ2UpOgorCiAyMDE4LTAzLTI3ICBDaHJpcyBEdW1leiAgPGNkdW1lekBh cHBsZS5jb20+CiAKICAgICAgICAgTWFrZSBpdCBwb3NzaWJsZSB0byBjYWxsIENvbnRlbnRTZWN1 cml0eVBvbGljeTo6dXBncmFkZUluc2VjdXJlUmVxdWVzdElmTmVlZGVkKCkgZnJvbSBub24tbWFp biB0aHJlYWRzCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9Nb2R1bGVzL3dlYnNvY2tldHMv V2ViU29ja2V0LmNwcCBiL1NvdXJjZS9XZWJDb3JlL01vZHVsZXMvd2Vic29ja2V0cy9XZWJTb2Nr ZXQuY3BwCmluZGV4IGQwMDJjMGIxODI2NDNlMTAyOGE5ZjRkOTYwOTE5ZDQ0ZTdlZjYxMmYuLjgy ODcxMGMyZWQ5MzQ1NTQwNTljNzE1YmM3MjcwZTQ1ZDlmNzM5NWUgMTAwNjQ0Ci0tLSBhL1NvdXJj ZS9XZWJDb3JlL01vZHVsZXMvd2Vic29ja2V0cy9XZWJTb2NrZXQuY3BwCisrKyBiL1NvdXJjZS9X ZWJDb3JlL01vZHVsZXMvd2Vic29ja2V0cy9XZWJTb2NrZXQuY3BwCkBAIC01NzIsNyArNTcyLDcg QEAgdm9pZCBXZWJTb2NrZXQ6OmRpZFJlY2VpdmVNZXNzYWdlKGNvbnN0IFN0cmluZyYgbXNnKQog ICAgIGlmIChtX3N0YXRlICE9IE9QRU4pCiAgICAgICAgIHJldHVybjsKICAgICBBU1NFUlQoc2Ny aXB0RXhlY3V0aW9uQ29udGV4dCgpKTsKLSAgICBkaXNwYXRjaEV2ZW50KE1lc3NhZ2VFdmVudDo6 Y3JlYXRlKG1zZywgU2VjdXJpdHlPcmlnaW46OmNyZWF0ZShtX3VybCktPnRvU3RyaW5nKCkpKTsK KyAgICBkaXNwYXRjaEV2ZW50KE1lc3NhZ2VFdmVudDo6Y3JlYXRlKG1zZywgU2VjdXJpdHlPcmln aW5EYXRhOjpmcm9tVVJMKG1fdXJsKS50b1N0cmluZygpKSk7CiB9CiAKIHZvaWQgV2ViU29ja2V0 OjpkaWRSZWNlaXZlQmluYXJ5RGF0YShWZWN0b3I8dWludDhfdD4mJiBiaW5hcnlEYXRhKQo=