Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Static Linux SDK

swift.org

Post reply on HN
Print view View original

201–210 of 274 posts

Re: Swift Static Linux SDK

#201

Post by School-Cotton »

palata wrote: post #183
kibwen wrote: post #125

Earlier quoted context omitted.

> I just don't want you to force me. Rust supports dynamic linking, and has since well before 1.0.

In practice, it feels like everybody assumes that Rust is installed through Rustup and dependencies are statically linked from cargo. I have tried going the dynamic linking way, it's painful when it's not impossible.

Regardless of what "everybody assumes", you can in fact build rust binaries without using rustup or cargo. Distros do this. Yes, it's more painful for end users than just typing `cargo build`, but that's irrelevant to distro maintainers.

Re: Swift Static Linux SDK

#202

Post by tracker1 »

amszmidt wrote: post #154
kibwen wrote: post #124

Earlier quoted context omitted.

I hear the refrain "you'll have to rebuild your packages" a lot in these discussions, and I confess I don't see how this is a problem. Maybe it's a holdover from C and C++ veterans for whom figuring out how to build any given project is a Herculean effort, but for every other language with a first-class build system it's trivial.

Debian has about 59000 packages. Even rebuilding 1k of that is a significant pain on build infrastructure, specially in one go, if say a vulnerable library is found. You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated… Compare to upgrading a single shared library.

Most USERS only run a handful of applications any given month. I think upgrading 1-2 applications is easier to reason with over even a hundred packages.

Re: Swift Static Linux SDK

#203

Post by tracker1 »

amszmidt wrote: post #197
eviks wrote: post #170

Earlier quoted context omitted.

Do you know whether someone has made an estimate based on the history of actual vulnerabilities of how much rebuilding would need to be done in a non-shared library approach?

Not to my knowledge. But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. If there is a bug in a shared library, one can replace it with a interm one very easily, and the whole operating system will use it. One can even replace it with a different implementation assuming ABI compatibility, without having to do "much". Enclaves like Go, Rust, Swift (things that insi…

For what it's worth, Rust uses libc by default in Linux.

On the other side, there are quite a few self-updating applications out there (browsers), and source control systems like Github will push notifications, and even pull requests for out of date dependencies. So pushing out a new version of a given application is pretty easy. If the application comes through Flathub or self-updates then it doesn't have to wait for the distro maintainers to get the update out.

Re: Swift Static Linux SDK

#204

Post by seabrookmx »

School-Cotton wrote: post #18
e63f67dd-065b wrote: post #11

Earlier quoted context omitted.

Yeah, I'm really glad for the trend of statically linked binaries that came with Rust/Go. No more version incompatibilities, fights with downstream packagers, weird build configs, etc, just distribute the binary and that's it.

Rust binaries (at least on Linux) are not statically linked by default. They depend on libc.

Same with golang! You need the CGO_ENABLED=0 flag IIRC to make static binaries on Linux.

Re: Swift Static Linux SDK

#205

Post by whytevuhuni »

School-Cotton wrote: post #178
LtWorf wrote: post #166

Earlier quoted context omitted.

Rust supports compiling each crate as a separate .so and then linking all of them? That's not at all how debian packages written in rust are linked. So the person I replied to is incorrect. I suspect you're incorrect as well and what you claim doesn't exist at all, but you're claiming a different thing.

> Rust supports compiling each crate as a separate .so and then linking all of them? Yes, by passing crate-type=dylib to the compiler.

Due to the lack of ABI stability, the resulting dynamic library is tied to the exact binary hash of the Rust compiler (which includes the dependencies rustc was built from).

Those dynamic libraries will also not remain ABI stable if their code changes (because Rust's semver specifically applies to the public API, but the public API is free to pass around structs with private fields, which may alter the layout drastically even for minor semver-compatible changes).

So this helps with some aspects (such as libraries being reused between binaries, reducing disk usage).

But it does not help with the issue most discussed in this thread: that of security updates (all libraries have to be rebuilt whenever rustc changes or a dependency changes, all programs (potentially the entire operating system) have to be redownloaded by all users, etc).

Re: Swift Static Linux SDK

#206

Post by cesarb »

amszmidt wrote: post #197
eviks wrote: post #170

Earlier quoted context omitted.

Do you know whether someone has made an estimate based on the history of actual vulnerabilities of how much rebuilding would need to be done in a non-shared library approach?

Not to my knowledge. But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. If there is a bug in a shared library, one can replace it with a interm one very easily, and the whole operating system will use it. One can even replace it with a different implementation assuming ABI compatibility, without having to do "much". Enclaves like Go, Rust, Swift (things that insi…

> But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc.

AFAIK, the reason most Linux distributions have an allergic reaction to static linking is because of zlib. There was a vulnerability in zlib some time ago, and it required the distributions to find every single program which had its own copy of zlib (vendoring zlib used to be common back then), update these copies with the security fix (not necessarily trivial, since the vendored copy might be a customized variant of an older zlib release), and rebuild all these packages (which is a lot of "fun" when some of the packages are in a "failed to build from source" aka FTBFS state). The distributions learned their lesson back then.

Re: Swift Static Linux SDK

#207

Post by amszmidt »

cesarb wrote: post #206
amszmidt wrote: post #197

Earlier quoted context omitted.

Not to my knowledge. But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. If there is a bug in a shared library, one can replace it with a interm one very easily, and the whole operating system will use it. One can even replace it with a different implementation assuming ABI compatibility, without having to do "much". Enclaves like Go, Rust, Swift (things that insi…

> But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. AFAIK, the reason most Linux distributions have an allergic reaction to static linking is because of zlib. There was a vulnerability in zlib some time ago, and it required the distributions to find every single program which had its own copy of zlib (vendoring zlib used to be common back then), update these cop…

The aversion to static linkage predates that, back many years static linkage also had other issues that have been solved today (ALSR ..). Many of the very basic points that Ulrich Drepper made some odd 20 years back (https://akkadia.org/drepper/no_static_linking.html) still hold.

Re: Swift Static Linux SDK

#208

Post by amszmidt »

tracker1 wrote: post #203
amszmidt wrote: post #197

Earlier quoted context omitted.

Not to my knowledge. But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. If there is a bug in a shared library, one can replace it with a interm one very easily, and the whole operating system will use it. One can even replace it with a different implementation assuming ABI compatibility, without having to do "much". Enclaves like Go, Rust, Swift (things that insi…

For what it's worth, Rust uses libc by default in Linux. On the other side, there are quite a few self-updating applications out there (browsers), and source control systems like Github will push notifications, and even pull requests for out of date dependencies. So pushing out a new version of a given application is pretty easy. If the application comes through Flathub or self-updates then it doesn't have to wait fo…

That is a very, very tiny subset of things that are installed on any GNU or BSD system, and that need to get security fixes. Just recall the xz/sshd/system debacle, to patch your system all you needed was to replace libxz / libzma -- a DSO! This obviously ignores lots of other work -- but that work would have ballooned if standard practise was to statically link everything.

The amount of work spent finding usages of static linkage, and figuring out which version of libxz (or whatever it was called) just to be very sure that one wasn't using the compromised version was atrocious, no thanks.

Re: Swift Static Linux SDK

#210

Post by Longhanks »

manmal wrote: post #5
palata wrote: post #2

> Additionally, a program built for a particular distribution, or even a particular major version of a particular distribution, would not necessarily run on any other distribution or in some cases even on a different major version of the same distribution. Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? Say my Linux distribution distributes…

A Swift program for a particular distribution will dynamically link some system libraries from the distro, and these libs might change on every distro update. They mention in the post that dynamic linking can cause versioning issues. > Say my Linux distribution distributes some Swift runtime That runtime would need to be compatible with the Swift program. Nowadays that’s not a big issue due to ABI stability ( https:/…

AFAIK they claim ABI stability only for Apple platforms, explicitly neither Linux, nor Windows. Has that changed?
Post reply on HN