> On Apr 5, 2017, at 7:56 PM, Douglas Gregor <[email protected]> wrote: > > Hello Swift community, > > The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for > Swift" begins now and runs through April 9, 2017. The revised proposal is > available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
Something came to mind that I wanted to record, even though it's not directly addressed by this proposal. I know that one future direction here is that key paths ought to be equatable, serializable, etc. Serialization in particular is something that we're going to have to think about very carefully. In general, it's really bad for deserialization to be able to call arbitrary code in the program. There is a well-known security hole in various reflective deserialization libraries where they will happily call arbitrary functions or constructors if they're named in the serialized data. (Often, there's some way to limit this, but you have to know to use it — so it's merely the default that isn't secure, but that's no defense.) A Swift serialization library would hopefully be designed around a protocol that provided a (throwing) deserializing initializer, so that (1) types have to opt in to supporting deserialization and (2) deserialization doesn't call completely arbitrary code. But it's still a potential security hole if deserialization can construct a key path that, when accessed, will execute arbitrary code in the process. There are other concerns as well. It's a code-size and performance problem if we have to treat every property and subscript in the program as potentially used, and emit key-path metadata for them, just in case they might be used by a deserialized key path. And, of course, it potentially becomes a binary compatibility problem to remove a property or subscript, even a private one, if that was ever used in a key path that was serialized. But the biggest concern is security. Anyway, just a thought that shouldn't be allowed to derail this proposal. John. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
