NSItemProvider throwing exception related to secure coding

@eskimo http://gngrwzrd.com/NSItemProvider.zip

@eskimo http://gngrwzrd.com/NSItemProvider.zip

Yes in iOS 17.4 simulator it still happens.

You really want to be testing this on a device rather than the sim, but let’s assume that it fails there for the moment.

The issue is Objective-C VS Swift.

Interesting. I’m struggling to come up with any explanation for that.

At this point I’m going to recommend that you open a DTS tech support incident and discuss this with my colleague who supports this technology.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@eskimo Were you able to see the demo I built?

@qiuyg Have you seen updates from this thread? I put together a demo project. What I see is Objc throws the exception, but a swift implementation doesn't have any errors.

Were you able to see the demo I built?

Yes.

However, per my response yesterday, I recommend that you start a DTS TSI for this. We’ve reached the limit of my expertise here. Specifically, we’ve strayed from Foundation and secure coding, which is very much my bailiwick, into Safari extensions, which is very much not.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@eskimo We've already updated ours to use the Swift equivalent API and it fixes it. If I open a DTS TSI for this does it count against us? Can you just forward my demo to your contact at Apple?

If I open a DTS TSI for this does it count against us?

Generally a TSI is ‘consumed’ if the assigned DTS engineer spends a significant amount of time working on it. As I’ve mentioned above, I’m not the expert in this area and thus this TSI won’t come to me and thus I can’t offer guidance as to its eventual fate.

I will say that, if you’re going to open a TSI, it’s best to have a specific goal in mind.

Can you just forward my demo to your contact at Apple?

To what end? If you think that this is a bug that should be fixed, you can put this in your bug report. OTOH, if you have a specific question you want answered, you can open a TSI and include it there.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We ran into this issue as well.

Our Action Share extension worked properly in iOS 17.2.x but failed with this exception in 17.4.x:

Exception: value for key 'NS.objects' was of unexpected class 'NSString'

(
	0   CoreFoundation                      0x00007ff8004cd571 __exceptionPreprocess + 242
	1   libobjc.A.dylib                     0x00007ff8000837e8 objc_exception_throw + 48
	2   Foundation                          0x00007ff800fb2f5e -[NSXPCDecoder _validateAllowedClass:forKey:allowingInvocations:] + 474
	3   Foundation                          0x00007ff800fb393e _decodeObject + 733
	4   Foundation                          0x00007ff800fb4c11 __44-[NSXPCDecoder _decodeArrayOfObjectsForKey:]_block_invoke + 40
	5   Foundation                          0x00007ff800fcba65 _NSXPCSerializationIterateArrayObject + 192
	6   Foundation                          0x00007ff800fb4bc4 -[NSXPCDecoder _decodeArrayOfObjectsForKey:] + 205
	7   Foundation                          0x00007ff800dcd106 -[NSDictionary(NSDictionary) initWithCoder:] + 173
	8   Foundation                          0x00007ff800fb3b31 _decodeObject + 1232
	9   Foundation                          0x00007ff800fb4c11 __44-[NSXPCDecoder _decodeArrayOfObjectsForKey:]_block_invoke + 40
	10  Foundation                          0x00007ff800fcba65 _NSXPCSerializationIterateArrayObject + 192
	11  Foundation                          0x00007ff800fb4bc4 -[NSXPCDecoder _decodeArrayOfObjectsForKey:] + 205
	12  Foundation                          0x00007ff800dcd106 -[NSDictionary(NSDictionary) initWithCoder:] + 173
	13  Foundation                          0x00007ff800fb3b31 _decodeObject + 1232
	14  Foundation                          0x00007ff800fb35d6 -[NSXPCDecoder _decodeObjectOfClasses:atObject:] + 128
	15  Foundation                          0x00007ff800e1b28b _NSXPCSerializationDecodeTypedObjCValuesFromArray + 942
	16  Foundation                          0x00007ff800e1baf8 _NSXPCSerializationDecodeInvocationArgumentArray + 552
	17  Foundation                          0x00007ff800fb44fb -[NSXPCDecoder __decodeXPCObject:allowingSimpleMessageSend:outInvocation:outArguments:outArgumentsMaxCount:outMethodSignature:outSelector:isReply:replySelector:] + 822
	18  Foundation                          0x00007ff800fb41a6 -[NSXPCDecoder _decodeReplyFromXPCObject:forSelector:] + 78
	19  Foundation                          0x00007ff800fa42b4 -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] + 212
	20  Foundation                          0x00007ff800fa8fd7 __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_3 + 205
	21  libxpc.dylib                        0x00007ff8000c8bec _xpc_connection_reply_callout + 36
	22  libxpc.dylib                        0x00007ff8000bd40c _xpc_connection_call_reply_async + 69
	23  libdispatch.dylib                   0x00007ff80017973e _dispatch_client_callout3 + 8
	24  libdispatch.dylib                   0x00007ff800197c37 _dispatch_mach_msg_async_reply_invoke + 609
	25  libdispatch.dylib                   0x00007ff800180f59 _dispatch_lane_serial_drain + 424
	26  libdispatch.dylib                   0x00007ff800181e17 _dispatch_lane_invoke + 406
	27  libdispatch.dylib                   0x00007ff80018d9a8 _dispatch_root_queue_drain_deferred_wlh + 276
	28  libdispatch.dylib                   0x00007ff80018cf72 _dispatch_workloop_worker_thread + 552
	29  libsystem_pthread.dylib             0x0000000108ec7c47 _pthread_wqthread + 327
	30  libsystem_pthread.dylib             0x0000000108ec6b97 start_wqthread + 15
)

Looks like there may be an Apple bug within NSXPCDecoder

As noted, the swift variant outputs this warning/error but still includes the applicable data:

-[_EXSinkLoadOperator loadItemForTypeIdentifier:completionHandler:expectedValueClass:options:] nil expectedValueClass allowing {(
    NSArray,
    NSMutableDictionary,
    NSUUID,
    NSDate,
    NSMutableData,
    _EXItemProviderSandboxedResource,
    NSValue,
    NSMutableArray,
    UIImage,
    NSNumber,
    NSError,
    NSMutableString,
    NSData,
    NSURL,
    NSDictionary,
    NSString,
    CKShare
)}

As a workaround, to get the Objective C variant to work we've adjusted our loadItemForTypeIdentifier:options:completionHandler: method code from this:

                [itemProvider loadItemForTypeIdentifier:(NSString *)kUTTypePropertyList options:nil completionHandler:^(NSDictionary *itemDict, NSError *error) {
                    // process itemDict
                }];

to this:

                [itemProvider loadItemForTypeIdentifier:(NSString *)kUTTypePropertyList options:nil completionHandler:^(id item, NSError *error) {
                    NSDictionary *itemDict = (NSDictionary *)item;
                    // process itemDict
                }];

which outputs the same warning/error as the swift variant but properly includes the data.

@eskimo Should I report this through feedback assistant as a bug? If so which "area" is appropriate to submit it under?

Should I report this through feedback assistant as a bug?

Yes. If nothing else, this is a binary compatibility regression.

If so which "area" is appropriate to submit it under?

Choose Developer Technologies & SDKs at the top level, and pick a framework from the technologies popup. For this and other tips, see Bug Reporting: How and Why?.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"