4 ms·

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

by taeric 4y ago

Gigachad 4y ago
You are going to see more security improvement by using Rust than the unlikely but possible chance of having your C library incidentally updated.
- palata 4y ago
  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.
jessermeyer 4y ago
There is obviously a trade off here, but categorically speaking, new releases introduce new bugs and security exploits too.
- palata 4y ago
  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.
  - jessermeyer 4y 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.
pornel 4y ago
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.
- DelightOne 4y ago
  So.. how do you rebuild apps without having access to their source code?
  - pornel 4y ago
    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.
    - DelightOne 4y ago
      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.
      - pornel 4y ago
        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.
Jach 4y ago
I like SDL2's approach to enable both: https://old.reddit.com/r/linux_gaming/comments/1upn39/sdl2_adds_dynamic_api_magic_to_allow_updating_it/ 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.
- palata 4y ago
  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...
  - Jach 4y ago
    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.

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

by taeric 4y ago

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

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

palata 4y ago
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.

jessermeyer 4y ago

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

palata 4y ago
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.
- jessermeyer 4y 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.

pornel 4y ago

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.

DelightOne 4y ago
So.. how do you rebuild apps without having access to their source code?
- pornel 4y ago
  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.
  - DelightOne 4y ago
    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.
    - pornel 4y ago
      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.

Jach 4y ago

I like SDL2's approach to enable both: https://old.reddit.com/r/linux_gaming/comments/1upn39/sdl2_adds_dynamic_api_magic_to_allow_updating_it/ 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.

palata 4y ago
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...
- Jach 4y ago
  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.