99243 2012-10-13 00:35:49 -0700 FEImage::m_document is never cleared. Why not? 2012-11-01 06:57:37 -0700 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 abarth schenney commit-queue dino d-r eric fmalita inferno krit mjs pdr rniwa schenney senorblanco thorton webkit.review.bot zimmermann oldest_to_newest 741443 0 abarth 2012-10-13 00:35:49 -0700 As far as I can tell, there's no mechanism for clearing FEImage::m_document after the Document has been destroyed. Given that FEImage is RefCounted, it seems very likely that FEImage can be kept alive after the Document is destroyed. I tried to chase down how we might be able to do that, but I got lost in SVG filter land. 742153 1 schenney 2012-10-15 10:28:16 -0700 I'm in that space now. It's a complete disaster area. I'll try to figure this one out too. 742177 2 schenney 2012-10-15 10:50:55 -0700 I don't think this is a problem. The document is only used when the filter is actually applied, and as far as I know you cannot apply a filter unless it is in the document. Furthermore, if the filter leaves the document the FilterEffect objects will be destroyed or marked dirty (forcing regeneration). The RefCounted on such objects does not indicate that they are held outside of FilterData objects, rather it seems to be to simplify management of pointers in SVGFilterBuilder. The FEImage filter effect is SVG-only and is only held inside SVGFilterBuilder. 742485 3 abarth 2012-10-15 14:55:36 -0700 Thanks for investigating this issue! Would you be willing to add a comment explaining this to the m_document declaration so that we won't get scared the next time we audit this code? 742503 4 schenney 2012-10-15 15:17:46 -0700 Reopened to comment appropriately. 744522 5 169239 schenney 2012-10-17 12:58:23 -0700 Created attachment 169239 Patch Is this what you had in mind? 744540 6 169239 abarth 2012-10-17 13:14:03 -0700 Comment on attachment 169239 Patch Yes, great. I'll leave this patch for someone who can verify the comment to review. Thanks! 754406 7 schenney 2012-10-30 08:52:47 -0700 I added an assert to the destructor for the FEImage filter effect and verified that it is destructed when it's target is removed from the document. These tests demonstrate the behavior. The assert stacks show the FEImage being destructed whenever its target (the thing that will try to use it) is detached. To summarize: Only a target renderer ever tries to use the m_document in the filter effect. When the target is added to the document the filter is created. When the target is removed from the document the filters are destroyed. JS cannot hold references to this data - it is entirely internal. Hence, there is no point at which a filter can exist without a valid document. svg/filters/feImage-remove-target.svg svg/filters/feImage-target-reappend-to-document.svg svg/filters/feImage-target-remove-from-document.svg svg/filters/feImage-target-add-to-document.svg svg/filters/feImage-target-attribute-change-with-use-indirection.svg Is that sufficient verification to R+ the comment? 754444 8 krit 2012-10-30 09:36:36 -0700 If it is wrong, why not fixing it? The comment is not really helpful. Make this bug no security bug anymore and fix it. 754455 9 mjs 2012-10-30 09:55:44 -0700 If this pointer is not actually a dangling reference hazard, then there is nothing to fix. I can see the value of adding a comment explaining that, so no one goes on a wild goose chase, but it seems a bit verbose for WebKit style. Is there a way to get the point across more concisely? I think the comment can just state that the pointer can't be used to access free memory despite never being cleared, without giving the full detailed explanation. 754472 10 171475 schenney 2012-10-30 10:10:07 -0700 Created attachment 171475 Patch 754474 11 schenney 2012-10-30 10:15:03 -0700 Maciej is right that this is never dangling and there's no point in fixing it. The only possible code change would be to explicitly set m_document to null before destroying the object, but there's no point at all in that. I've come up with a one line comment (a bit longer). Actually, it just occurred to me that I should reference this bug, so I'll give it another pass. Also, there is no need for this to be a security issue. 754480 12 171478 schenney 2012-10-30 10:17:30 -0700 Created attachment 171478 Patch Much more concise, yet still informative. 754503 13 171478 eric 2012-10-30 10:44:23 -0700 Comment on attachment 171478 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=171478&action=review > Source/WebCore/svg/graphics/filters/SVGFEImage.h:58 > + // m_document will never be a dangling reference. See https://bugs.webkit.org/show_bug.cgi?id=99243 Better justification would be to explain why here as well. This is not an Element, so it doesn't keep the document alive. I assume this is held off of a renderer? Can this also be held off of a CSSValue? 754516 14 171478 schenney 2012-10-30 11:04:13 -0700 Comment on attachment 171478 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=171478&action=review >> Source/WebCore/svg/graphics/filters/SVGFEImage.h:58 >> + // m_document will never be a dangling reference. See https://bugs.webkit.org/show_bug.cgi?id=99243 > > Better justification would be to explain why here as well. This is not an Element, so it doesn't keep the document alive. I assume this is held off of a renderer? Can this also be held off of a CSSValue? This object is only held by a SVGFilterBuilder which in turn is held by a RenderSVGResourceFilter::FilterData object, which in turn is held by a RenderSVGResourceFilter object which is a renderer. Nothing else at all holds references to FEImage. Any changes to CSS properties (including SVG attributes) that affect the filter cause the FilterData and hence FEImage object to be destroyed and recreated. CSS Filters cannot use SVGFEImage. The only way that FEImage::m_document is used is to look up the renderer for the image it is drawing. It will only do that during applyResource, which is only called when the target for the filter (the thing that will draw it) is painted, which only happens if the target is in the document. If the target is in the document then FEImage::m_document is valid. If the target is not in the document then it both cannot be painted and there is no FEImage object to have a dangling reference. 754770 15 171478 krit 2012-10-30 16:18:29 -0700 Comment on attachment 171478 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=171478&action=review > Source/WebCore/ChangeLog:8 > + Adding a comment to explain why the failure to clear m_document is not a problem. Please say that this will be refactored with another patch. >>> Source/WebCore/svg/graphics/filters/SVGFEImage.h:58 >>> + // m_document will never be a dangling reference. See https://bugs.webkit.org/show_bug.cgi?id=99243 >> >> Better justification would be to explain why here as well. This is not an Element, so it doesn't keep the document alive. I assume this is held off of a renderer? Can this also be held off of a CSSValue? > > This object is only held by a SVGFilterBuilder which in turn is held by a RenderSVGResourceFilter::FilterData object, which in turn is held by a RenderSVGResourceFilter object which is a renderer. Nothing else at all holds references to FEImage. Any changes to CSS properties (including SVG attributes) that affect the filter cause the FilterData and hence FEImage object to be destroyed and recreated. CSS Filters cannot use SVGFEImage. > > The only way that FEImage::m_document is used is to look up the renderer for the image it is drawing. It will only do that during applyResource, which is only called when the target for the filter (the thing that will draw it) is painted, which only happens if the target is in the document. If the target is in the document then FEImage::m_document is valid. If the target is not in the document then it both cannot be painted and there is no FEImage object to have a dangling reference. Please add a link to this bug report, and open the bug report after landing again. Can be dependent on your refactoring patch later. After refactoring you just close it. 754791 16 171478 schenney 2012-10-30 16:47:04 -0700 Comment on attachment 171478 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=171478&action=review >> Source/WebCore/ChangeLog:8 >> + Adding a comment to explain why the failure to clear m_document is not a problem. > > Please say that this will be refactored with another patch. But it won't be refactored, at least not to my knowledge. The comment exists so that _if_ there is ever a patch that changes the behavior the patch author will know the situation. Or if anyone, like Adam, is doing a security review they will have context in which to understand why this is not a security problem. >>>> Source/WebCore/svg/graphics/filters/SVGFEImage.h:58 >>>> + // m_document will never be a dangling reference. See https://bugs.webkit.org/show_bug.cgi?id=99243 >>> >>> Better justification would be to explain why here as well. This is not an Element, so it doesn't keep the document alive. I assume this is held off of a renderer? Can this also be held off of a CSSValue? >> >> This object is only held by a SVGFilterBuilder which in turn is held by a RenderSVGResourceFilter::FilterData object, which in turn is held by a RenderSVGResourceFilter object which is a renderer. Nothing else at all holds references to FEImage. Any changes to CSS properties (including SVG attributes) that affect the filter cause the FilterData and hence FEImage object to be destroyed and recreated. CSS Filters cannot use SVGFEImage. >> >> The only way that FEImage::m_document is used is to look up the renderer for the image it is drawing. It will only do that during applyResource, which is only called when the target for the filter (the thing that will draw it) is painted, which only happens if the target is in the document. If the target is in the document then FEImage::m_document is valid. If the target is not in the document then it both cannot be painted and there is no FEImage object to have a dangling reference. > > Please add a link to this bug report, and open the bug report after landing again. Can be dependent on your refactoring patch later. After refactoring you just close it. There is a link to this bug report. Did you mean something else? Again, there is no plan for a future patch at this time. 755765 17 krit 2012-10-31 18:04:32 -0700 (In reply to comment #16) > (From update of attachment 171478 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=171478&action=review > > >> Source/WebCore/ChangeLog:8 > >> + Adding a comment to explain why the failure to clear m_document is not a problem. > > > > Please say that this will be refactored with another patch. > > But it won't be refactored, at least not to my knowledge. The comment exists so that _if_ there is ever a patch that changes the behavior the patch author will know the situation. Or if anyone, like Adam, is doing a security review they will have context in which to understand why this is not a security problem. > > >>>> Source/WebCore/svg/graphics/filters/SVGFEImage.h:58 > >>>> + // m_document will never be a dangling reference. See https://bugs.webkit.org/show_bug.cgi?id=99243 > >>> > >>> Better justification would be to explain why here as well. This is not an Element, so it doesn't keep the document alive. I assume this is held off of a renderer? Can this also be held off of a CSSValue? > >> > >> This object is only held by a SVGFilterBuilder which in turn is held by a RenderSVGResourceFilter::FilterData object, which in turn is held by a RenderSVGResourceFilter object which is a renderer. Nothing else at all holds references to FEImage. Any changes to CSS properties (including SVG attributes) that affect the filter cause the FilterData and hence FEImage object to be destroyed and recreated. CSS Filters cannot use SVGFEImage. > >> > >> The only way that FEImage::m_document is used is to look up the renderer for the image it is drawing. It will only do that during applyResource, which is only called when the target for the filter (the thing that will draw it) is painted, which only happens if the target is in the document. If the target is in the document then FEImage::m_document is valid. If the target is not in the document then it both cannot be painted and there is no FEImage object to have a dangling reference. > > > > Please add a link to this bug report, and open the bug report after landing again. Can be dependent on your refactoring patch later. After refactoring you just close it. > > There is a link to this bug report. Did you mean something else? > > Again, there is no plan for a future patch at this time. Hm, ok. Then land it :P 756183 18 schenney 2012-11-01 06:57:37 -0700 Committed r133158: <http://trac.webkit.org/changeset/133158> 169239 2012-10-17 12:58:23 -0700 2012-10-30 10:10:03 -0700 Patch bug-99243-20121017155711.patch text/plain 1679 schenney SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDEzMTYzMCkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE3IEBACisyMDEyLTEwLTE3ICBTdGVwaGVu IENoZW5uZXkgIDxzY2hlbm5leUBjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgRkVJbWFnZTo6bV9k b2N1bWVudCBhcHBlYXJzIHRvIGJlIHVzZWFibGUgYWZ0ZXIgZnJlZQorICAgICAgICBodHRwczov L2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9OTkyNDMKKworICAgICAgICBSZXZpZXdl ZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBBZGRpbmcgYSBjb21tZW50IHRvIGV4cGxh aW4gd2h5IHRoZSBmYWlsdXJlIHRvIGNsZWFyIG1fZG9jdW1lbnQgaXMgbm90IGEgcHJvYmxlbS4K KworICAgICAgICBObyBuZXcgdGVzdHMgYmVjYXVzZSBubyBjb2RlIGNoYW5nZSBhdCBhbGwuCisK KyAgICAgICAgKiBzdmcvZ3JhcGhpY3MvZmlsdGVycy9TVkdGRUltYWdlLmg6CisgICAgICAgIChG RUltYWdlKTogQWRkIGEgY29tbWVudCBvbiB0aGUgbGlmZXRpbWUgb2YgbV9kb2N1bWVudC4KKwog MjAxMi0xMC0xNyAgRGFuIENhcm5leSAgPGRjYXJuZXlAZ29vZ2xlLmNvbT4KIAogICAgICAgICBC aW5kIGlzb2xhdGVkV29ybGRTZWN1cml0eU9yaWdpbiB0byB3b3JsZApJbmRleDogU291cmNlL1dl YkNvcmUvc3ZnL2dyYXBoaWNzL2ZpbHRlcnMvU1ZHRkVJbWFnZS5oCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNv dXJjZS9XZWJDb3JlL3N2Zy9ncmFwaGljcy9maWx0ZXJzL1NWR0ZFSW1hZ2UuaAkocmV2aXNpb24g MTMxNjMwKQorKysgU291cmNlL1dlYkNvcmUvc3ZnL2dyYXBoaWNzL2ZpbHRlcnMvU1ZHRkVJbWFn ZS5oCSh3b3JraW5nIGNvcHkpCkBAIC01NCw2ICs1NCwxMiBAQCBwcml2YXRlOgogICAgIFJlbmRl ck9iamVjdCogcmVmZXJlbmNlZFJlbmRlcmVyKCkgY29uc3Q7CiAKICAgICBSZWZQdHI8SW1hZ2U+ IG1faW1hZ2U7CisKKyAgICAvLyBUaGUgbV9kb2N1bWVudCBoZXJlIGlzIGFzc2lnbmVkIHdoZW4g dGhlIEZpbHRlckVmZmVjdCBpcyBjcmVhdGVkIGFuZCBuZXZlciBtb2RpZmllZCBvdGhlcndpc2Uu CisgICAgLy8gVGhpcyBpcyBzYWZlLCBldmVuIGlmIHRoZSBkb2N1bWVudCBpcyBkZWxldGVkLCBi ZWNhdXNlIG1fZG9jdW1lbnQgaXMgb25seSB1c2VkIHdoZW4gdGhlCisgICAgLy8gZmlsdGVyIGlz IGFwcGxpZWQgYW5kIHRoZSBmaWx0ZXIgY2FuIG9ubHkgYmUgYXBwbGllZCB3aGVuIHRoZXJlIGlz IGEgZG9jdW1lbnQuCisgICAgLy8gRnVydGhlcm1vcmUsIHRoaXMgb2JqZWN0IGlzIGRlc3Ryb3ll ZCBhbmQgcmVjcmVhdGVkIHdoZW4gdGhlIGRvY3VtZW50IGNoYW5nZXMuCisgICAgLy8gVGhlcmUg aXMgbm8gQVBJIHRvIG90aGVyd2lzZSBhY2Nlc3MgbV9kb2N1bWVudC4KICAgICBEb2N1bWVudCog bV9kb2N1bWVudDsKICAgICBTdHJpbmcgbV9ocmVmOwogICAgIFNWR1ByZXNlcnZlQXNwZWN0UmF0 aW8gbV9wcmVzZXJ2ZUFzcGVjdFJhdGlvOwo= 171475 2012-10-30 10:10:07 -0700 2012-10-30 10:17:20 -0700 Patch bug-99243-20121030130832.patch text/plain 1426 schenney SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDEzMjkxOCkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE3IEBACisyMDEyLTEwLTMwICBTdGVwaGVu IENoZW5uZXkgIDxzY2hlbm5leUBjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgRkVJbWFnZTo6bV9k b2N1bWVudCBhcHBlYXJzIHRvIGJlIHVzZWFibGUgYWZ0ZXIgZnJlZQorICAgICAgICBodHRwczov L2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9OTkyNDMKKworICAgICAgICBSZXZpZXdl ZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBBZGRpbmcgYSBjb21tZW50IHRvIGV4cGxh aW4gd2h5IHRoZSBmYWlsdXJlIHRvIGNsZWFyIG1fZG9jdW1lbnQgaXMgbm90IGEgcHJvYmxlbS4K KworICAgICAgICBObyBuZXcgdGVzdHMgYmVjYXVzZSBubyBjb2RlIGNoYW5nZSBhdCBhbGwuCisK KyAgICAgICAgKiBzdmcvZ3JhcGhpY3MvZmlsdGVycy9TVkdGRUltYWdlLmg6CisgICAgICAgIChG RUltYWdlKTogQWRkIGEgY29tbWVudCBvbiB0aGUgbGlmZXRpbWUgb2YgbV9kb2N1bWVudC4KKwog MjAxMi0xMC0zMCAgTWlrZSBXZXN0ICA8bWt3c3RAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFdl YiBJbnNwZWN0b3I6IEFzc29jaWF0ZSBjb25zb2xlIG1lc3NhZ2VzIHdpdGggdGhlIHJlcXVlc3Rz IHRoYXQgY2F1c2VkIHRoZW0uCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9zdmcvZ3JhcGhpY3MvZmls dGVycy9TVkdGRUltYWdlLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvc3ZnL2dyYXBo aWNzL2ZpbHRlcnMvU1ZHRkVJbWFnZS5oCShyZXZpc2lvbiAxMzI5MTgpCisrKyBTb3VyY2UvV2Vi Q29yZS9zdmcvZ3JhcGhpY3MvZmlsdGVycy9TVkdGRUltYWdlLmgJKHdvcmtpbmcgY29weSkKQEAg LTU0LDYgKzU0LDggQEAgcHJpdmF0ZToKICAgICBSZW5kZXJPYmplY3QqIHJlZmVyZW5jZWRSZW5k ZXJlcigpIGNvbnN0OwogCiAgICAgUmVmUHRyPEltYWdlPiBtX2ltYWdlOworCisgICAgLy8gVGhp cyBGRUltYWdlIG9iamVjdCBuZXZlciBsaXZlcyBiZXlvbmQgdGhlIGxpZmUgb2YgdGhlIG1fZG9j dW1lbnQgc2V0IGF0IGNvbnN0cnVjdGlvbjsgbV9kb2N1bWVudCB3aWxsIG5ldmVyIGJlIGEgZGFu Z2xpbmcgcmVmZXJlbmNlLgogICAgIERvY3VtZW50KiBtX2RvY3VtZW50OwogICAgIFN0cmluZyBt X2hyZWY7CiAgICAgU1ZHUHJlc2VydmVBc3BlY3RSYXRpbyBtX3ByZXNlcnZlQXNwZWN0UmF0aW87 Cg== 171478 2012-10-30 10:17:30 -0700 2012-10-30 16:47:04 -0700 Patch bug-99243-20121030131555.patch text/plain 1383 schenney SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDEzMjkxOCkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE3IEBACisyMDEyLTEwLTMwICBTdGVwaGVu IENoZW5uZXkgIDxzY2hlbm5leUBjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgRkVJbWFnZTo6bV9k b2N1bWVudCBpcyBuZXZlciBjbGVhcmVkLiBXaHkgbm90PworICAgICAgICBodHRwczovL2J1Z3Mu d2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9OTkyNDMKKworICAgICAgICBSZXZpZXdlZCBieSBO T0JPRFkgKE9PUFMhKS4KKworICAgICAgICBBZGRpbmcgYSBjb21tZW50IHRvIGV4cGxhaW4gd2h5 IHRoZSBmYWlsdXJlIHRvIGNsZWFyIG1fZG9jdW1lbnQgaXMgbm90IGEgcHJvYmxlbS4KKworICAg ICAgICBObyBuZXcgdGVzdHMgYmVjYXVzZSBubyBjb2RlIGNoYW5nZSBhdCBhbGwuCisKKyAgICAg ICAgKiBzdmcvZ3JhcGhpY3MvZmlsdGVycy9TVkdGRUltYWdlLmg6CisgICAgICAgIChGRUltYWdl KTogQWRkIGEgY29tbWVudCBvbiB0aGUgbGlmZXRpbWUgb2YgbV9kb2N1bWVudC4KKwogMjAxMi0x MC0zMCAgTWlrZSBXZXN0ICA8bWt3c3RAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFdlYiBJbnNw ZWN0b3I6IEFzc29jaWF0ZSBjb25zb2xlIG1lc3NhZ2VzIHdpdGggdGhlIHJlcXVlc3RzIHRoYXQg Y2F1c2VkIHRoZW0uCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9zdmcvZ3JhcGhpY3MvZmlsdGVycy9T VkdGRUltYWdlLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvc3ZnL2dyYXBoaWNzL2Zp bHRlcnMvU1ZHRkVJbWFnZS5oCShyZXZpc2lvbiAxMzI5MTgpCisrKyBTb3VyY2UvV2ViQ29yZS9z dmcvZ3JhcGhpY3MvZmlsdGVycy9TVkdGRUltYWdlLmgJKHdvcmtpbmcgY29weSkKQEAgLTU0LDYg KzU0LDggQEAgcHJpdmF0ZToKICAgICBSZW5kZXJPYmplY3QqIHJlZmVyZW5jZWRSZW5kZXJlcigp IGNvbnN0OwogCiAgICAgUmVmUHRyPEltYWdlPiBtX2ltYWdlOworCisgICAgLy8gbV9kb2N1bWVu dCB3aWxsIG5ldmVyIGJlIGEgZGFuZ2xpbmcgcmVmZXJlbmNlLiBTZWUgaHR0cHM6Ly9idWdzLndl YmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTk5MjQzCiAgICAgRG9jdW1lbnQqIG1fZG9jdW1lbnQ7 CiAgICAgU3RyaW5nIG1faHJlZjsKICAgICBTVkdQcmVzZXJ2ZUFzcGVjdFJhdGlvIG1fcHJlc2Vy dmVBc3BlY3RSYXRpbzsK