3 ms·
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
by zarzavat 5y ago
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.
- arcticbull 5y agoI 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.