I wonder if we can find a middle ground between strict enforcement and advisory-only? Maybe the auditing tool could have an integration into regular SwiftPM flows where e.g. users could enable running the auditing after fetching binaries if they prefer a stricter model.
2 Likes
@lukasa has a great point that having the tool available would already be a huge help in debugging.
I don't think we can make the tool a part of the SwiftPM integration flow. With the current proposed design, the tool relies on being run inside the Docker container (built from the provided image) to catch all potential compatibility concerns between libc versions. For example if we just run the tool locally and the build host has a newer libc than the runtime host we would end up potentially missing a usage of a newer missing libc symbol.
As I said upthread, I'm very empathetic to the point of ensuring that binary artifacts are correct and the end binary runs on the host where it's going to be deployed. I think achieving a guarantee that a produced binary is working on the host is almost impossible (leaving aside the case of fully statically linked binaries). Especially in scenarios where the runtime host is different than the build host. I also want us all to be aware that Swift PM supports cross compilation so any auditing would need to be able to run in the build target environment. That's why the proposed audit tool here needs to use docker to check what the static library links.
For me this proposal is primarily aimed to level the playing field between our supported platforms. On Darwin we can do the exact same thing with XCFrameworks without having any audit tools in place. Even on Darwin developers can produce XCFrameworks that build and link correctly but fail at runtime.
While this proposal tries to be as defensive as possible about allowing static binaries, I personally strongly believe that we need to give developers this escape hatch to potentially distribute arbitrary static binaries on all platforms. If somebody wants to produce a package that exports a static binary which requires certain system dependencies they should have a way to do this. The current state of the ecosystem is that either you can build the static binary from source via SwiftPM (e.g. swift-cassandra-client or swift-kafka-client), or you expect your users to install certain dependencies via the platform dependency manager, or worse some packages vend specific docker images.
6 Likes
I'm very much in favour of this pitch, and hope that it goes through. We're working with both Server-Side Linux systems (usually container based) and Embedded Linux systems.
This has been a repeating wish we'd like to have. I've ran into both stated reasons for needing this feature multiple times. And I'm recently also interested in building Static Swift libraries, so I'm hopeful that this future direction becomes reality, too.
In particular, I think the development experience with Embedded Swift will greatly improve with this feature.
1 Like