I was working on some demo code investigating the use of secure archiving, since I guess we all have to adopt that if we can. I have a simple container class (a linked list) that I decided to make secure archivable. It works, but when dearchiving, I need to dearchive the ‘payload’ of the list nodes, which can be anything at all - it’s defined as an id<NSObject>. So when I ask for this item securely, I use
2022-02-24 17:59:55.701579+1100 GCSimpleContainers[25591:31009796] [general] *** -[NSKeyedUnarchiver validateAllowedClass:forKey:]: NSSecureCoding allowed classes list contains [NSObject class], which bypasses security by allowing any Objective-C class to be implicitly decoded. Consider reducing the scope of allowed classes during decoding by listing only the classes you expect to decode, or a more specific base class than NSObject. This will become an error in the future. Allowed class list: {(
"'NSObject' (0x7ff85c7c2b88) [/usr/lib]"
)}
I get what it’s saying — that asking for NSObject is too open-ended, and it renders the secure coding moot. But what else can I do? I don’t know the payload class, I want it to be as flexible as possible. Forcing this to be a subclass of NSObject of my own means I lose the ability to store all standard Cocoa objects ‘as is’ in my container. Adding a wrapper class doesn’t help because it would still need to archive what it wrapped. It strikes me that Apple themselves must run into this when archiving NSDictionary, since keys can be anything, but that works, so perhaps they use an internal bit of trickery.
It concerns me that they say “this will become an error in the future”. I can go back to traditional archiving with no security, no errors there, but then what’s the point of secure coding?
A way to simply suppress the log of the message would do for now. It’s extra bad because it logs this every time it happens, not just once. Is this a case of Apple being too zealous in overlooking a common use-case, or have I missed something?
