Hacker News Reader

Comment by taeric | Hacker News Reader

Security updates, though?

I mean, you aren't wrong. But there were other advantages to dynamic linking.

Dynamic linking is not the only way to deliver security fixes, just one particular, limited, C-oriented solution. Note that dynamic linking is also not sufficient to change C++ templates or C header-only libraries. It shifts all of the code replacement complexity from the OS (just replace a file) onto the language and library authors (ABI compat, fragile base classes, no inlining or generics).

Rust/Cargo gives you Cargo.lock (and more precise build plans if you want) that can be used to build a database of every binary that needs to be rebuilt to update a certain dependency. Distros could use it identify and update all affected packages. There are also caching solutions to avoid rebuilding everything. It's just something they didn't have to implement before, so naturally distros prefer all new languages to fit the old unbundled-C approach instead.

So.. how do you rebuild apps without having access to their source code?

You ask the vendor, since they need to look after their software anyway. Don't count on closed-source abandonware to conveniently have all vulnerabilities placed in external libraries.

I am talking about apps on the iPhone where Apple does not have access to developers' source code, right? We might be talking about different situations.

Updates of system libraries there are definitely a plus.

However, besides the OS itself Apple doesn't do anything about app security. Not only they don't require unbundling, they don't even support it. Even if you use dynamic libraries in your app, they will be bundled with your app, and never updated separately.

From App Store perspective there's absolutely no difference between a Swift app diligently split into frameworks and a Rust monolith library. They treat both as an opaque bundle.

That's what you would expect from the App Store as well, since why change a dynamic library when the code-controlling developer can just build a new version with his own code when the developer wants to update the app.

Injecting new (the nature of not being available on app-submission) framework versions on the developers' behalf would be scary, since these versions weren't tested with the app because the versions did not exist before. As you said, ABI compat is impossible when no one cares about that much.

Note that dynamic linking is also done in Java, C#, and any dynamic language. It's not something specific to C, not by a long shot.

I was confused by that line. I think they are mainly referring to most dynamic linking in linux? Not sure.

I do think the world lost a bit by not embracing cross language linking more. Not sure when that got lost.

I like SDL2's approach to enable both: https://old.reddit.com/r/linux_gaming/comments/1upn39/sdl2_a... A game can statically link the library, but the user can with an environmental variable override the functions to point at their dynamic library instead. Very useful especially with games as you can then keep them running on new platforms or fix certain bugs even though the developers have long since disappeared or moved on.

But then if it works with shared libs, you kind of lose the advantage of the static linking which was mostly (if I understand correctly) that dynamic library was not working well...

It's up to the user if they want to see whether the dynamic library is "working well". They work well for many people! But the statically linked version will be used unless their custom env variable is declared, everyone can be happy.

There is obviously a trade off here, but categorically speaking, new releases introduce new bugs and security exploits too.

But they do patch the known security exploits that are likely to be actively used. I'm happier with a security exploit (almost) nobody knows than with a published one that appears in hacking tutorials from 10 years ago.

There are two degrees of separation here though: The software vendors and then the linux distros.

If you sell software that requires your clients to upgrade their system-wide security stack, so they might not. If it is statically linked, no need for them to.

You are going to see more security improvement by using Rust than the unlikely but possible chance of having your C library incidentally updated.

Not convinced at all. Say a big exploit gets published for a very popular library: you probably want to patch it as fast as possible. Whereas Rust will help you have fewer security issues in your own code, which is likely not as popular as some of your critical deps.

Reply on news.ycombinator.com