5 ms·

The risk of a supply chain attack, roughly speaking, is then multiplied by all 73 dependencies. If any of those are compromised, the shell and system are compro

The risk of a supply chain attack, roughly speaking, is then multiplied by all 73 dependencies. If any of those are compromised, the shell and system are compromised. To ameliorate the risk, the security of all 73 dependencies would need to be at least an order of magnitude greater, just to catch up to shells with no dependencies. The irony is that this lack of "dependency-safety" is far more easily exploitable than any previous lack of "memory-safety". Of course, this can be easily fixed if developers stop multiplying third-party dependencies, so that importing a dependency involves O(1) risk, not O(?).

perlgeek 7y ago
> But this can be easily fixed. Developers need to stop using third-party dependencies, so that importing a dependency should involve O(1) risk, not O(N^2). How is this an easy fix? Now developers need to develop and maintain O(N) instead of O(1) software projects. I guess that if nushell had a zero dependency policy, it would have never happened. And there is a significant risk to spreading your resources thin when reimplementing sensitive dependencies, like crypto or network / http libraries.
- jorangreef 7y ago
  > How is this an easy fix? Now developers need to develop and maintain O(N) instead of O(1) software projects. At some point, developers need to take responsibility for the security of their projects. If your project is larger, you will need to maintain more code, whether directly or indirectly. You can't simply import a dependency but never audit it. And if you're taking the trouble to audit a third-party dependency, at some point it becomes worth maintaining directly. > sensitive dependencies, like crypto or network / http libraries. I am not suggesting that developers reimplement TCP.
  - sterlind 7y ago
    I've had to reinvent the wheel, over and over again, throughout my career. Sometimes it was because our environment was constrained (no cloud, needs to be up for major disasters), or because the architecture was unique (no primary, all protocols must be decentralized), or because what I needed didn't exist for my stack. It's pain and sorrow all the way down and I find more bugs in my reinvented wheels than in the actu code I set out to write. How about this: 0. Rebuild from latest stable dependencies, or latest updates to your LTSB, whenever you or your dependencies have a bug. 1. Prefer static linking or lib incorporation if feasible, or use a package manager that properly guarantees you the right versions. 2. Stick to popular repos with responsive maintainers, or 3. Fork the dependency yourself, audit the code and know how to debug it. 4. Watch upstream for security bugs.
    - jorangreef 7y ago
      Sure, and 5 would be: Prefer dependencies with smaller flatter dependency trees.
  - perlgeek 7y ago
    > At some point, developers need to take responsibility for the security of their projects. Agreed, but that could be through careful selection instead of rolling your own. And it would be great if there was better tooling for that. Imagine an ecosystem where every module author automatically gets not just a public repo and issue tracker, but also a way to deal with security issues, an indication if all contributors used 2FA for code contribution and package uploads. Then there could be a search for packages where you can say "only give me those with 2FA and a defined security disclosure process, including all transitive dependencies". That wouldn't be perfect, but much, much better than any ecosystem I've seen so far.
- bpicolo 7y ago
  This is sorta why things like Guava and Boost exist - audited / trustworthy libraries for common asks where you know more or less what to expect in terms of quality. The approach the Rust community is taking with a sort of decoupled-STL approach is interesting, but I do wish they found a way to collect the known-good-bits in a common namespace.
seaish 7y ago
This isn't a problem if versions are pinned.
nailer 7y ago
What shells, if any, have no dependencies?
- deleted 7y ago
  [deleted]
- johnisgood 7y ago
  An example: https://www.archlinux.org/packages/core/x86_64/dash/ https://www.archlinux.org/packages/core/x86_64/dash/ Or look at bash: https://www.archlinux.org/packages/core/x86_64/bash/ https://www.archlinux.org/packages/core/x86_64/bash/ I would say many shells that are written in C will have an extremely short list of dependencies in contrast to Rust.
  - nailer 7y ago
    On my phone, but ldd bash? Also compare cost of maintaining your own custom secure functions Vs using well known ones.
    - johnisgood 7y ago
      You do not have to maintain your own, you can use a popular and audited one that many other projects depend on so it is typically installed. The point is not to not have any dependencies, just do not have in the hundreds, especially not if they are not shared; it would take up too much space! As per your request: $ ldd /usr/bin/bash linux-vdso.so.1 (0x00007ffce8b8c000) libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007fd76a0dd000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fd76a0d8000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fd769f15000) libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007fd769ea6000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd76a266000) Those files are generally installed on all major Linux distributions. For completeness: $ ldd /usr/bin/dash linux-vdso.so.1 (0x00007ffdbadce000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f6f2cd28000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f6f2cf58000) Note that these files are shared between projects, you do not have to download and compile them per project. Can you do the same using Cargo? According to my experience with it from two years ago, I had to download and build over 400 dependencies for all projects, separately. I do not know how many dependencies Rust projects have on average.

perlgeek 7y ago

> But this can be easily fixed. Developers need to stop using third-party dependencies, so that importing a dependency should involve O(1) risk, not O(N^2). How is this an easy fix? Now developers need to develop and maintain O(N) instead of O(1) software projects. I guess that if nushell had a zero dependency policy, it would have never happened. And there is a significant risk to spreading your resources thin when reimplementing sensitive dependencies, like crypto or network / http libraries.

jorangreef 7y ago
> How is this an easy fix? Now developers need to develop and maintain O(N) instead of O(1) software projects. At some point, developers need to take responsibility for the security of their projects. If your project is larger, you will need to maintain more code, whether directly or indirectly. You can't simply import a dependency but never audit it. And if you're taking the trouble to audit a third-party dependency, at some point it becomes worth maintaining directly. > sensitive dependencies, like crypto or network / http libraries. I am not suggesting that developers reimplement TCP.
- sterlind 7y ago
  I've had to reinvent the wheel, over and over again, throughout my career. Sometimes it was because our environment was constrained (no cloud, needs to be up for major disasters), or because the architecture was unique (no primary, all protocols must be decentralized), or because what I needed didn't exist for my stack. It's pain and sorrow all the way down and I find more bugs in my reinvented wheels than in the actu code I set out to write. How about this: 0. Rebuild from latest stable dependencies, or latest updates to your LTSB, whenever you or your dependencies have a bug. 1. Prefer static linking or lib incorporation if feasible, or use a package manager that properly guarantees you the right versions. 2. Stick to popular repos with responsive maintainers, or 3. Fork the dependency yourself, audit the code and know how to debug it. 4. Watch upstream for security bugs.
  - jorangreef 7y ago
    Sure, and 5 would be: Prefer dependencies with smaller flatter dependency trees.
- perlgeek 7y ago
  > At some point, developers need to take responsibility for the security of their projects. Agreed, but that could be through careful selection instead of rolling your own. And it would be great if there was better tooling for that. Imagine an ecosystem where every module author automatically gets not just a public repo and issue tracker, but also a way to deal with security issues, an indication if all contributors used 2FA for code contribution and package uploads. Then there could be a search for packages where you can say "only give me those with 2FA and a defined security disclosure process, including all transitive dependencies". That wouldn't be perfect, but much, much better than any ecosystem I've seen so far.
bpicolo 7y ago
This is sorta why things like Guava and Boost exist - audited / trustworthy libraries for common asks where you know more or less what to expect in terms of quality. The approach the Rust community is taking with a sort of decoupled-STL approach is interesting, but I do wish they found a way to collect the known-good-bits in a common namespace.

seaish 7y ago

This isn't a problem if versions are pinned.

nailer 7y ago

What shells, if any, have no dependencies?

deleted 7y ago
[deleted]
johnisgood 7y ago
An example: https://www.archlinux.org/packages/core/x86_64/dash/ https://www.archlinux.org/packages/core/x86_64/dash/ Or look at bash: https://www.archlinux.org/packages/core/x86_64/bash/ https://www.archlinux.org/packages/core/x86_64/bash/ I would say many shells that are written in C will have an extremely short list of dependencies in contrast to Rust.
- nailer 7y ago
  On my phone, but ldd bash? Also compare cost of maintaining your own custom secure functions Vs using well known ones.
  - johnisgood 7y ago
    You do not have to maintain your own, you can use a popular and audited one that many other projects depend on so it is typically installed. The point is not to not have any dependencies, just do not have in the hundreds, especially not if they are not shared; it would take up too much space! As per your request: $ ldd /usr/bin/bash linux-vdso.so.1 (0x00007ffce8b8c000) libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007fd76a0dd000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fd76a0d8000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fd769f15000) libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007fd769ea6000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd76a266000) Those files are generally installed on all major Linux distributions. For completeness: $ ldd /usr/bin/dash linux-vdso.so.1 (0x00007ffdbadce000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f6f2cd28000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f6f2cf58000) Note that these files are shared between projects, you do not have to download and compile them per project. Can you do the same using Cargo? According to my experience with it from two years ago, I had to download and build over 400 dependencies for all projects, separately. I do not know how many dependencies Rust projects have on average.