4 ms·

In Linux, if libssl is compromised, you install a new libssl. In Plan 9, if libssl is compromised, you re-install Plan 9. That's static linking for you.

by snarfy 8y ago

IshKebab 8y ago
Yeah that works if your app is in the Debian's software repository (and Ubuntu's and Red Hat's and Gentoo's and etc. etc.). If that is the case it is trivial to update all apps that depend on libssl anyway, even if they use static linking. In practice it is far easier for a lot of software to distribute Windows-like binaries where all but the most basic dependencies are included (e.g. Flatpak or Snappy). In that case dynamic linking doesn't help at all.
- fao_ 8y ago
  Exactly. Modern Ubuntu systems rely on Snap or Flatpak for a lot of software. What these systems do (as I understand it) is package a large amount of the dynamic libraries that would be provided by the operating system, and stick them in a compressed file (or virtual file system, whatever). So what you essentially get is a 200MiB 'binary' without any of the benefits of dynamic linking (being able to swap out a library given a vulnerability without recompiling) OR static linking (a single file, with the extraneous code removed, etc. etc.).
  - vetinari 8y ago
    With flatpak, you can update the runtime (a bundle of libraries) independently of the app, so you can swap out a library with a vulnerability without recompiling.
    - IshKebab 8y ago
      That's not why runtimes exist though - it's too save disk space.
- vetinari 8y ago
  Flatpak has a concept of runtimes, shared among multiple applications, which are basically a well-defined bundles of libraries. So yes, dynamic linking helps there.
simias 8y ago
I think it's silly to dismiss static linking like TFA seems to do but I don't think your point is very fair. Assuming that you have a proper package manager upgrading all applications that link to libssl would definitely be a much larger download that merely libssl.so but it could be handled automatically and without too much fuss.
ddevault 8y ago
The entire plan9 system takes less than 10 minutes to compile from scratch on one core of my 11 year old laptop. OpenSSL alone takes 2-3x that on two cores.
- bakul 8y ago
  On the original RaspberryPi it took a minute to recompile the kernel from scratch and 4 minutes to recompile all the standard programs. In comparison it took 10 to 11 hours to recompile the Linux kernel. Cross-compiling the plan9 kernel on a 2009 era amd64 computer took 20 seconds computer. And rebooting took few seconds.
AnIdiotOnTheNet 8y ago
> In Linux, if libssl is compromised, you install a new libssl. And then you pray that the interface and behavior have not changed enough to break things that depend on it.
muraiki 8y ago
> One of the primary reasons for the redesign of the Plan 9 security infrastructure was to remove the authentication method both from the applications and from the kernel. Cryptographic code is large and intricate, so it should be packaged as a separate component that can be repaired or modified without altering or even relinking applications and services that depend on it. If a security protocol is broken, it should be trivial to repair, disable, or replace it on the fly. Similarly, it should be possible for multiple programs to use a common security protocol without embedding it in each program. > Some systems use dynamically linked libraries (DLLs) to address these configuration issues. The problem with this approach is that it leaves security code in the same address space as the program using it. The interactions between the program and the DLL can therefore accidentally or deliberately violate the interface, weakening security. Also, a program using a library to implement secure services must run at a privilege level necessary to provide the service; separating the security to a different program makes it possible to run the services at a weaker privilege level, isolating the privileged code to a single, more trustworthy component. The paper goes on to explain how the various cryptographic services are exposed as a file server. This is the Plan 9 way of doing things: have lots of small programs that talk to one another. http://doc.cat-v.org/plan_9/4th_edition/papers/auth http://doc.cat-v.org/plan_9/4th_edition/papers/auth

In Linux, if libssl is compromised, you install a new libssl. In Plan 9, if libssl is compromised, you re-install Plan 9. That's static linking for you.

by snarfy 8y ago

In Linux, if libssl is compromised, you install a new libssl. In Plan 9, if libssl is compromised, you re-install Plan 9. That's static linking for you.

IshKebab 8y ago

Yeah that works if your app is in the Debian's software repository (and Ubuntu's and Red Hat's and Gentoo's and etc. etc.). If that is the case it is trivial to update all apps that depend on libssl anyway, even if they use static linking. In practice it is far easier for a lot of software to distribute Windows-like binaries where all but the most basic dependencies are included (e.g. Flatpak or Snappy). In that case dynamic linking doesn't help at all.

fao_ 8y ago
Exactly. Modern Ubuntu systems rely on Snap or Flatpak for a lot of software. What these systems do (as I understand it) is package a large amount of the dynamic libraries that would be provided by the operating system, and stick them in a compressed file (or virtual file system, whatever). So what you essentially get is a 200MiB 'binary' without any of the benefits of dynamic linking (being able to swap out a library given a vulnerability without recompiling) OR static linking (a single file, with the extraneous code removed, etc. etc.).
- vetinari 8y ago
  With flatpak, you can update the runtime (a bundle of libraries) independently of the app, so you can swap out a library with a vulnerability without recompiling.
  - IshKebab 8y ago
    That's not why runtimes exist though - it's too save disk space.
vetinari 8y ago
Flatpak has a concept of runtimes, shared among multiple applications, which are basically a well-defined bundles of libraries. So yes, dynamic linking helps there.

simias 8y ago

I think it's silly to dismiss static linking like TFA seems to do but I don't think your point is very fair. Assuming that you have a proper package manager upgrading all applications that link to libssl would definitely be a much larger download that merely libssl.so but it could be handled automatically and without too much fuss.

ddevault 8y ago

The entire plan9 system takes less than 10 minutes to compile from scratch on one core of my 11 year old laptop. OpenSSL alone takes 2-3x that on two cores.

bakul 8y ago
On the original RaspberryPi it took a minute to recompile the kernel from scratch and 4 minutes to recompile all the standard programs. In comparison it took 10 to 11 hours to recompile the Linux kernel. Cross-compiling the plan9 kernel on a 2009 era amd64 computer took 20 seconds computer. And rebooting took few seconds.

AnIdiotOnTheNet 8y ago

> In Linux, if libssl is compromised, you install a new libssl. And then you pray that the interface and behavior have not changed enough to break things that depend on it.

muraiki 8y ago

> One of the primary reasons for the redesign of the Plan 9 security infrastructure was to remove the authentication method both from the applications and from the kernel. Cryptographic code is large and intricate, so it should be packaged as a separate component that can be repaired or modified without altering or even relinking applications and services that depend on it. If a security protocol is broken, it should be trivial to repair, disable, or replace it on the fly. Similarly, it should be possible for multiple programs to use a common security protocol without embedding it in each program. > Some systems use dynamically linked libraries (DLLs) to address these configuration issues. The problem with this approach is that it leaves security code in the same address space as the program using it. The interactions between the program and the DLL can therefore accidentally or deliberately violate the interface, weakening security. Also, a program using a library to implement secure services must run at a privilege level necessary to provide the service; separating the security to a different program makes it possible to run the services at a weaker privilege level, isolating the privileged code to a single, more trustworthy component. The paper goes on to explain how the various cryptographic services are exposed as a file server. This is the Plan 9 way of doing things: have lots of small programs that talk to one another. http://doc.cat-v.org/plan_9/4th_edition/papers/auth http://doc.cat-v.org/plan_9/4th_edition/papers/auth