> On Apr 6, 2017, at 8:59 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Apr 5, 2017, at 7:56 PM, Douglas Gregor <dgre...@apple.com> 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.
When we design serialization behavior for key paths, I think it'd be reasonable to require opt-in decoration on the particular storage declarations that need to be encodable. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
