Bug 282866 – git-webkit find 267815.308@safari-7617.1.11.12-branch fails to find commit

• Status: NEW
• Component: Tools / Tests

[Sam Sneddon [:gsnedders]]

gsnedders@gsnedders-margot OpenSource % ./Tools/Scripts/git-webkit find 267815.308@safari-7617.1.11.12-branch
Failed to retrieve revision count for main..safari-7617.1.11.12-branch

gsnedders@gsnedders-margot OpenSource % git branch --all | grep safari-7617.1.11.12-branch
  remotes/apple/safari-7617.1.11.12-branch
  remotes/origin/safari-7617.1.11.12-branch

gsnedders@gsnedders-margot OpenSource % git --no-pager log -1 --grep='267815.308@safari-7617.1.11.12-branch' remotes/origin/safari-7617.1.11.12-branch
commit 87942a9f69fd (tag: WebKit-7617.1.11.12.1)
Author: Alex Christensen <[e-mail]>
Date:   Tue Oct 10 20:53:40 2023 -0700

    Cherry-pick 80c45a1e6ff2. rdar://113527046
    
        Fix crashes from hardening _WKRemoteObjectRegistry decoding
        https://bugs.webkit.org/show_bug.cgi?id=262983
        rdar://113527046
    
        Reviewed by David Kilzer.
    
        In April 2023, I made _WKRemoteObjectRegistry deserialization stricter by not allowing subclasses
        of the specified class to be deserialized.  To make this transition as smooth as possible, I added
        a set of common and safe always-allowed subclasses including NSMutableString and several others.
        Telemetry indicates this increased the crash rate and this is to bring that crash rate back down.
    
        After analyzing 100% of the recent crash reports with useful data, I found 4 things that will help:
        1. Allowing a class named "NSDecimalNumberPlaceholder" which is a subclass of NSDecimalNumber that
           some internal frameworks apparently use and give to Safari in a path that serializes it.  Allow this.
        2. Some crash logs indicate that NSDate objects are failing to decode because they are not in the
           set of allowed classes.  There are some JS to ObjC object converters (such as the one used in
           WKWebView.callAsyncJavaScript) that can produce an NSDate, and this is ok and safe.  Allow this too.
        3. There are logs that indicate that sometimes a class is being sent from one process to another,
           and the receiving process has not loaded the dylib containing the ObjC class so the ObjC runtime
           can't find it.  Add telemetry to get this class name for future diagnosis.
        4. There are logs that indicate that sometimes a class is being sent that does not conform to
           NSSecureCoding according to NSCoder.  Also add telemetry to get this class name for future diagnosis,
           but in this case I needed to add a @try/@catch because validateClassSupportsSecureCoding either
           returns YES or throws an ObjC exception, so to get the class name to CRASH_WITH_INFO I need to catch.
    
        * Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm:
        (alwaysAllowedClasses):
        (validateClass):
        (decodeObject):
    
        Canonical link: https://commits.webkit.org/269185@main
    Identifier: 267815.308@safari-7617.1.11.12-branch

[Radar WebKit Bug Importer]

<rdar://problem/139548822>