[swift-evolution] [RFC] "Library Evolution Support in Swift ('Resilience')"

[Drew Crawford]

When someone vendors or statically links a library, they know what they are getting into.  I mean, sometimes people do silly things, but they should know.

Whereas "inlining across dynamically linked libraries" is a novel Swiftism (Or it may be a Rustism as well but in any case) nobody expects it. They will assume that replacing the dynamic library actually replaces the dynamic library's code, because that is the social contract for dynamic linkage.

More broadly, I see inlining dynamic libraries as a "nice to have", but dynamic linkage that actually works as "critical".  This proposal inverts that value system, telling me that I will get inlined performance, and I might get a correctly linked program.  That seems backwards.

Or stated another way: if I can't relink my program afterwards, why am I using dynamic linkage?  I should statically link everything.

Let me advance an independent argument why I think this is the wrong behavior: LGPL compliance.  Eliding LGPLv3 §4)d)1:

> You may convey a Combined Work... if you... Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.


and §4)e:

> Provide Installation Information... to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. 


I suspect that linking an LGPLed library under this proposals' semantics may be a lawsuit foot-gun.

...inb4 "don't use the LGPL", but I think this (and the security problem) generalize to a very broad class of issues.  Dynamic linkage has a certain "social contract" since time immemorial.  Breaking this contract has consequences that I am not sure we have thought through entirely.


> On Feb 10, 2016, at 9:46 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> 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.
> 
> -Joe
> 
>> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160211/1ee55c10/attachment.html>