I honestly cannot understand the motivation of allowing arbitrary function execution in an NSPredicate at all. That seems like an unbounded complexity risk, especially when serialized. They've just defined a fun little scripting language in this random corner of Foundation. Testing it appropriately seems nightmarish, and the wrong inputs would just crash the app.
A system that only allows a small set of permitted functions, or implements hard-coded functions like the first version (min, max, avg) just seems far more ... reasonable.
It's the job of an API framework provider to be defensive against these kinds of vectors especially when they may not deprecate this for like, 10+ years. How this made it through Apple's API review is beyond me.
If I saw someone try and pull something like this at the office I would immediately make sure the design was rejected.
NSPredicate dates from before when Objective-C had closures. Objective-C didn’t have closures because it was a thin layer on top of C, and C uses callbacks not closures.
NSPredicate is serialisable because you might want to include it in e.g. a schema. These schemas would be loaded from the app bundle so there’s no security concerns unless your threat model includes modifying the app bundle (which is more of an OS level issue).
The issue is that the serialization needs to distinguish between data that is serialized by the developer of the app at build-time, and data that is serialized at runtime.
I remember, I was a macOS engineer when it came out.
I think NSPredicate, even a serializable one, makes sense. What doesn't make any sense is arbitrary selector invocation. Not just because it's a security risk, but also because it's a stringly-typed method name that isn't checked by the compiler. The name of the selector changing would just cause it to crash - without a compile-time check. A plist with a serialized selector that no longer exists would cause the app to crash. A plist with a malicious selector would cause the app to crash. And crashing seems like a best case outcome.
A system that only allows a small set of permitted functions, or implements hard-coded functions like the first version (min, max, avg) just seems far more ... reasonable.
It's the job of an API framework provider to be defensive against these kinds of vectors especially when they may not deprecate this for like, 10+ years. How this made it through Apple's API review is beyond me.
If I saw someone try and pull something like this at the office I would immediately make sure the design was rejected.