Remove code guarded by !HAVE(WK_SECURE_CODING_NSURLREQUEST)

Component: WebKit Cocoa IPC serialization | 36f536e

Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.h

Source/WebKit/Scripts/webkit/tests/GeneratedSerializers.cpp

WebKit's Cocoa IPC historically encoded arbitrary NSSecureCoding objects with NSKeyedArchiver and decoded them in the receiving process with NSKeyedUnarchiver, restricted by an allowed-class list. Unarchiving data from a potentially compromised WebContent process is a long-standing source of sandbox-escape bugs, because class allow-lists can be bypassed through nested or gadget classes. WebKit replaced this type by type with CoreIPC* wrapper classes that serialize explicit fields and rebuild the ObjC object in the receiver. NSURLRequest was the last type converted, and the legacy path stayed behind !HAVE(WK_SECURE_CODING_NSURLREQUEST) even after the flag was set unconditionally for Cocoa.

This commit removes the legacy decode path, most of which was compiled out by that guard, along with its infrastructure: CoreIPCRetainPtr.h, CoreIPCSecureCoding.serialization.in and the implementation inside CoreIPCSecureCoding.{h,mm} (constructor, toID, objectClass, crashWithClassName, exemption helpers), the SecureCodingAllowed serializer attribute, Decoder::decodeWithAllowedClasses, the WKSecureCodingURLWrapper/WKSecureCodingCGColorWrapper archiving shims, and the classNamesExemptFromSecureCodingCrash process-creation parameter. That parameter and the SecureCoding::applyProcessCreationParameters call were not behind the guard, so its removal also changes the AuxiliaryProcessCreationParameters IPC wire format.

Before (HAVE=1 on Cocoa):

RetainPtr<T> decode
  └─► decodeWithAllowedClasses<T>              [live]
        ├─► m_allowedClasses = ...             [compiled out]
        └─► decodeRequiringAllowedClasses<T>   [live]
              ├─► decodeObjectDirectlyRequiringAllowedClasses<T>
              │     ├─► per-type CoreIPC decoder   [live path]
              │     └─► NSObject<NSSecureCoding> specialization
              │           └─► NSKeyedUnarchiver    [compiled out]
              └─► ASSERT(isObjectClassAllowed)     [compiled out]

After:

RetainPtr<T> decode
  └─► decodeObjectDirectly<T>
        └─► per-type CoreIPC decoder

Significance

PlatformHave.h already defined HAVE_WK_SECURE_CODING_NSURLREQUEST as 1 on all Cocoa platforms, so the guarded NSKeyedUnarchiver code and allow-list plumbing were unreachable, and removing them shrinks the IPC decoding surface that needs auditing. The unguarded classNamesExemptFromSecureCodingCrash plumbing was compiled in but most likely inert. The commit finishes a migration begun in 2022.

Audit directions

This is mostly attack-surface removal of already-unreachable code, but the cleanup touches shared decoding code that remains. ArgumentCoder<RetainPtr<T>>::decode now calls decodeObjectDirectly<U> directly, decodeObjectDirectlyRequiringAllowedClasses was renamed, CoreIPCNSCFObject::valueIsAllowed was deleted while valueFromID was modified, and generate-serializers.py lost its allowed-classes decode branch. The removed isObjectClassAllowed check was assertion-only and guarded by !HAVE, so no release-mode validation was lost there. CoreIPCNSCFObject::valueIsAllowed was deleted while valueFromID was modified. Check whether valueIsAllowed enforced anything in release builds and, if it did, whether valueFromID now covers it. Narrow: review the renamed paths for mistakes in the mechanical rename and for generated decoders that now rely solely on per-type validation. Wider: grep for remaining callers or serialization specs that assumed the generic NSSecureCoding fallback.