Branch: refs/heads/safari-7617.1.11.12-branch
Home: https://github.com/WebKit/WebKit
Commit: 42a0fc235faabaca5a2f30fe53c10f12fe74681d
https://github.com/WebKit/WebKit/commit/42a0fc235faabaca5a2f30fe53c10f12fe74681d
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2023-10-16 (Mon, 16 Oct 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7617.1.11.12.1
Canonical link: https://commits.webkit.org/267815.307@safari-7617.1.11.12-branch
Commit: 87942a9f69fd7c2b1ee761f1f1dfb737c01b5f4e
https://github.com/WebKit/WebKit/commit/87942a9f69fd7c2b1ee761f1f1dfb737c01b5f4e
Author: Alex Christensen <achristen...@apple.com>
Date: 2023-10-16 (Mon, 16 Oct 2023)
Changed paths:
M Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm
Log Message:
-----------
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
Commit: 6af60fb521264fbcafe8e915bcd0d067c88e5706
https://github.com/WebKit/WebKit/commit/6af60fb521264fbcafe8e915bcd0d067c88e5706
Author: Myah Cobbs <mco...@apple.com>
Date: 2023-10-17 (Tue, 17 Oct 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7617.1.11.12.2
Identifier: 267815.309@safari-7617.1.11.12-branch
Compare: https://github.com/WebKit/WebKit/compare/42a0fc235faa%5E...6af60fb52126
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
