[swift-evolution] [RFC] "Library Evolution Support in Swift ('Resilience')"
jgroff at apple.com
Wed Feb 10 21:46:16 CST 2016
I don't think there's a silver bullet here. Even if the implementation is inside the binary, you'll still have clients with vendored or statically linked copies of old versions of your library embedded in their distributions. Clients always have to share in the responsibility for maintaining their security.
> On Feb 10, 2016, at 6:08 PM, Drew Crawford via swift-evolution <swift-evolution at swift.org> wrote:
>> I think the solution is that you shouldn't mark security-critical code as being eligible for inlining. Anything else is just not going to be workable.
> There is no such thing as "I solemnly swear this function doesn't have a security bug, and if it does, we'll never patch it."
> If we have to choose between security and inlining, let's not allow inlining across versioned APIs.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution