Can't encode object graphs with aliased objects or cycles

[amomchilov]

One thing I've noticed in the passed is that you can't* use Swift's Codable facilities to express aliased objects (multiple references to the same object), or cycles in the object graph.

Basically, by the point you're getting init(from decoder: Decoder) called on your type, you're already "locked into" having to make a new instance (it was already made, actually, you're just initializing it). Unlike an Objective C initializer, you can't return an object that isn't self.

This means that if you want to express one object of class Foo being referenced from multiple other objects, you can't just implement that object-aliasing logic in the decoding logic of Foo. You need to instead override the encoding logic of every single class that makes references to Foo.

Contrast this with Objective-C's NSCoding, where you can call awakeAfterUsingCoder: to substitute one object for another

Though this restriction isn't caused by this package, this package inherits it from Swift's Codable system. Should we document it explicitly?

[jakaplan]

My initial thoughts are this shouldn't be documented as part of this framework, or any other framework which makes use of Codable. This is the defined behavior of the Swift standard library.

While it's true this behavior is not that of Objective C and NSCoding, they're two very different languages. In particular Swift has a strong bias towards structs with memory copying semantics.

[amomchilov]

this shouldn't be documented as part of this framework, or any other framework which makes use of Codable. This is the defined behavior of the Swift standard library.

I would generally agree, but I think this restriction might pose an integration trap for people who are used to NSXPCConnection (where object cycles/aliases work so naturally that they might are taken for granted).

I think it's worth a mention before people get too deep and get stuck by mid-way into adopting this framework.

[jakaplan]

Looking into this more, can NSCoding be used with Objective-C's XPC API? According to this documentation beyond some primitive and collection types, conformance must be to the NSSecureCoding protocol. The documentation for awakeAfterUsingCoder: doesn't make any mention of NSSecureCoding which makes sense as its description is "A protocol that enables encoding and decoding in a manner that is robust against object substitution attacks."

[amomchilov]

I don't think NSSecureCoding precludes cycles or aliasing, but I'll confirm once I get deeper into building out this feature in my app. It's side project work, so progress is slow.

robust against object substitution attacks.

I believe what they mean by that is that they want to protect against unexpected classes from being instantiated. I don't think substituting one Foo object for another Foo object in an object graph poses any particular security concern.

I'll confirm this and update you here once I get this far into my implementation :)

[amomchilov]

I can confirm that the NSXPCEncoder/NSXPCDecoder handles aliased objects correctly without doing anything special. Object cycles do cause an issue:

Exception: decodeObjectOfClass:forKey: too many nested collections

---

Here's the setup code I used:

@objc protocol PrivilegedHelperProtocol {
	func echo(_ input: NSObject, _ reply: @escaping (NSObject) -> Void)
}

/// Used as a common source-of-truth that the client and server can both used to define the XPC interface
func PrivilegedHelperProtocol_asXPCInterface() -> NSXPCInterface {
	let interface = NSXPCInterface(with: PrivilegedHelperProtocol.self)

	let classes = NSSet(objects: Node.self, NSArray.self) as! Set<AnyHashable>
	interface.setClasses(classes, for: #selector(PrivilegedHelperProtocol.echo(_:_:)), argumentIndex: 0, ofReply: false)
	interface.setClasses(classes, for: #selector(PrivilegedHelperProtocol.echo(_:_:)), argumentIndex: 0, ofReply: true)

	return NSXPCInterface(with: PrivilegedHelperProtocol.self)
}

My service just implements echo as:

class PrivilegedHelperService: PrivilegedHelperProtocol {
	func echo(_ input: NSObject, _ reply: @escaping (NSObject) -> Void) {
		reply(input)
	}
}

Here's my test set up for testing aliased objects:

let aliasedObject = Node(value: 3)
let rootObjects: NSArray = [
	Node(value: 1, next: aliasedObject),
	Node(value: 2, next: aliasedObject),
]

proxyObject.echo(rootObjects) { response in print(response) }

Here's the print-out, which shows that nodes 1 and 2 both point a common node 3:

(
    "<Node: 0x60000210ebe0, value: 1, next: <Node: 0x60000210e0c0, value: 3, next: nil>>",
    "<Node: 0x600002135380, value: 2, next: <Node: 0x60000210e0c0, value: 3, next: nil>>"
)

Here's my test set up for testing object cycles (yes, this leaks memory because of the strong reference cycle, but it's just for demonstration):

let n3 = Node(value: 3, next: nil)
let n2 = Node(value: 2, next: n3)
let n1 = Node(value: 1, next: n2)
n3.next = n1

proxyObject.echo(rootObjects) { response in print(response) }

[jakaplan]

Thanks for testing that out, I've updated the README

[amomchilov]

I've got another Interesting finding.

So I remembered correctly, NSKeyed(Una|A)rchiver handles aliases and cycles just fine, but to handle cycles you need to "opt in" by archiving your object graph using -[NSArchiver encodeRootObject:] (which is now deprecated? 🧐). But as you can see here, the encoding done by NSXPCEncoder is done with the "plain old" _encodeObject::

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1
    frame #0: 0x0000000100f8a934 Demo Privileged Helper App`Node.encode(coder=0x00000001138bf000, self=0x0000600001e07dc0) at PrivilegedHelperProtocol.swift:47:16
    frame #1: 0x0000000100f8aad8 Demo Privileged Helper App`@objc Node.encode(with:) at <compiler-generated>:0
  * frame #2: 0x000000018a66e5f4 Foundation`-[NSXPCEncoder _encodeObject:] + 520
    frame #3: 0x000000018a674314 Foundation`_NSXPCSerializationAddInvocationWithOnlyObjectArgumentsArray + 120
    frame #4: 0x000000018a6741c0 Foundation`-[NSXPCEncoder _encodeInvocationObjectArgumentsOnly:count:typeString:selector:isReply:into:] + 212
    frame #5: 0x000000018a66c7d8 Foundation`-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 1420
    frame #6: 0x000000018a6740b0 Foundation`-[NSXPCConnection _sendSelector:withProxy:arg1:arg2:] + 144
    frame #7: 0x000000018a673fc8 Foundation`_NSXPCDistantObjectSimpleMessageSend2 + 76
    frame #8: 0x0000000100f84578 Demo Privileged Helper App`ViewController.echo(sender=0x000000012370f160, self=0x0000600002c39170) at ViewController.swift:70:29

So if you want to handle cycles in the NSXPC APIs, you'll need to roll your own. Luckily, I can confirm that - [NSObject awakeAfterUsingCoder:] is still called, so you can perform object substitution there. Interestingly, it appears the NSXPC APIs hide their coder, and don't let you assign a delegate similar to NSKeyedArchiverDelegate

[jakaplan]

I perhaps read too much into the "object" part of "object substitution attacks". Technically I believe what you're describing is protecting against class substitution attacks.

Let me know what you find and I'd be happy to update the documentation with a helpful note if in fact this is the case. I just don't want to be providing a note that isn't actually applicable and therefore is more confusing than helpful.