4 ms·

The main problem the author is talking about is actually about version updates, which in Maven as well as crates.io is up to each lib's author, and is not curat

by brabel 3y ago

The main problem the author is talking about is actually about version updates, which in Maven as well as crates.io is up to each lib's author, and is not curated in any way. There's no technical solution to that, really. Do you think Nexus Firewall can pick up every exploit, or even most? How confident of that are you, and what data do you have to back that up? I don't have any myself, but would not be surprised at all if "hackers" can easily work around their scanning. However, I don't have a better approach than using scanning tools like Nexus, or as the author proposes, use a curated library repository like Debian is doing (which hopefully gets enough eyeballs to remain secure) or the https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev project (manually reviewed code) also mentioned. It's interesting that they mention C/C++ just rely on distros providing dynamic libs instead which means you don't even control your dependencies versions, some distro does (how reliable is the distro?)... I wonder if that could work for other languages or if it's just as painful as it looks in the C world.

jjgreen 3y ago
Coding mainly in C for 20 years, I've never had a program break on minor version of system shared library conflict. Occasionally need to recompile on OS version update when the major version increments.
- goodpoint 3y ago
  That does not solve supply chain attacks.
  - mid-kid 3y ago
    It solves most supply chain attacks. Distro maintainers are users, not developers. They put the needs of a user first, and their work is reviewed during submission. If one of them goes rogue, the damage is usually caught before reaching the user and otherwise minimal, as the update is simply reverted by other maintainers and a different maintainer can take over their packages.
    - goodpoint 3y ago
      Sorry, I misread jjgreen's comment. I 100% agree with what you are saying.
- lmm 3y ago
  The C community basically doesn't bother with libraries. They're so cumbersome to do in C that you'll tend to only have, like, 20 giant libraries in your (non-vendored) dependencies.
mid-kid 3y ago
It works in the C world because everyone is super fixated on library compatibility, and the programs are expected to be rebuilt by the distribution when necessary. When an API is broken, this entails a new major version and installing both versions side by side until all maintained software is ported. This doesn't happen often enough to be an issue - that's the perk of having a really mature ecosystem.
- Aerbil313 3y ago
  On the other hand, having tasted Nix, the process you are describing seems as backwards and archaic as operating punched card computers to me. So much wasted human time, serving a need (of an ecosystem) now obsolete, thanks to Nix.
  - brabel 3y ago
    I'm trying to use Guix (just prefer it due to the language, Guile, over Nix) but unfortunately it doesn't have a lot of software packaged yet. I tried to build a project I have but it doesn't even have a "builder" for the language I used , Dart (which compiles to binary on all OSs), and I can't find out how to create a "builder" for it... someone did this for Nix to build pub packages so it's possible, but it seems if you want to use Nix/Guix you're stuck on a very limited set of things you can use? Is that a fair analysis? Do you have hints to build your own software when it's not available on Nix/Guix?
    - Aerbil313 3y ago
      See https://news.ycombinator.com/item?id=38171379 https://news.ycombinator.com/item?id=38171379 Also, nix can do arbitrary building (arbitrary commands). You don’t need a specialized builder. You can write a specialized builder for your language too, if it doesn’t exist.
    - dannymi 3y ago
      In general adding a build system to Guix works like this: 1. Git clone https://git.savannah.gnu.org/git/guix.git https://git.savannah.gnu.org/git/guix.git 2. Nicolò Balzarotti already has a work in progress patchset adding Dart itself--see https://issues.guix.gnu.org/44926 https://issues.guix.gnu.org/44926 . Patch your guix checkout with the files you can download on that page via the downarrow buttons on the right. 3. Create a file guix/build-system/dart.scm (I'd copy it from guix/build-system/dub.scm and then s/dub/dart/g and s/ldc/dartcc/g) or whatever it is. This file is the "front end" and is support for dart for the guix package manager script. 4. Create a file guix/build/dart-build-system.scm (I'd copy it from guix/build/dub-build-system.scm and then s/dub/dart/g). This file is the "back end" and is responsible for the build of your package inside a new container. 5. Add references to your new files to gnu/local.mk 6. In your user package script (whatever you want to compile in dart), add #:use-module (guix build-system dart) near the top and then add (build-system dart-build-system) to your package. 7. guix environment --pure guix 8. ./bootstrap 9. ./configure --localstatedir=/var 10. make -j5 11. exit 12. ./pre-inst-env guix build -f yourpackage.scm or whatever 13. Fiddle with the "invoke" parts in guix/build/dart-build-system.scm until your user package works. 14. Submit your results to 44926@debbugs.gnu.org or guix-devel@gnu.org (no need to be subscribed). As you can see, adding a new programming environment is quite some work. Because every programming environment has its own idiosyncracies, I don't think it can be avoided even in principle.
oblio 3y ago
Everyone is focusing on Nexus Firewall. Nexus/Artifactory themselves are private repos/proxies/caches that are in widespread use in the Java world so up to a point most companies prune their own repos. This is NOT standard practice in the JS/Python/PHP/whatever world because these products do not exist or are not widely available, everyone "drinks" directly from the open internet source. Yes, again, solutions exist, technically, but how many companies do you know, especially smaller ones, that do this? For Java almost every company bigger than 5 devs tends to set up their own Maven repo at some point, many do it on day 1 because at least 1 dev is familiar with this practice from their former BigCo and it's easy to set up Nexus/Artifactory.
- claudex 3y ago
  Artifactory works well with as a proxy for pip for Python
  - oblio 3y ago
    Yeah, I know that these days they can do everything, but the cultural bias is there. The average Java dev will try to reach for Artifactory/Nexus much sooner than the average Python/Ruby/PHP/Javascript/... dev, in my experience.
    - pjmlp 3y ago
      Only because of company culture, in most enterprise projects I work on, doesn't matter the stack, everything gets legal and IT approvement into the internal Nexus. Devs might do whatever they feel locally, however if those files are going through CI/CD their dependencies better be in Nexus.
- TeeMassive 3y ago
  We use Artifactory as a PyPI mirror and a private package index and it works really great.
amelius 3y ago
> There's no technical solution to that, really. There is. Theoretically speaking, you could confine libraries to their own sandbox. But Rust can't do that.
- pertique 3y ago
  Do you have other info on languages that do? In my mind, if a library is compromised and incorporated in software that touches sensitive data then there's no way to meaningfully sandbox it. Sure, the library lives in the sandbox, but so does the stuff you're trying to protect. I'm not sure that's a Rust-specific problem.
  - amelius 3y ago
    The library should live in its own sandbox, separated from the rest of the system including any other libraries. All system calls have to go through a permissions system that (e.g.) denies access by default. There is at least one language that tries to do that (someone posted it here in a comment some time ago, but I can't find it).
  - marwis 3y ago
    Java (look up Security Manager). Unfortunately it is deprecated and scheduled for removal because too much security is annoying and not enough people care to use it.

by brabel 3y ago

jjgreen 3y ago

Coding mainly in C for 20 years, I've never had a program break on minor version of system shared library conflict. Occasionally need to recompile on OS version update when the major version increments.

goodpoint 3y ago
That does not solve supply chain attacks.
- mid-kid 3y ago
  It solves most supply chain attacks. Distro maintainers are users, not developers. They put the needs of a user first, and their work is reviewed during submission. If one of them goes rogue, the damage is usually caught before reaching the user and otherwise minimal, as the update is simply reverted by other maintainers and a different maintainer can take over their packages.
  - goodpoint 3y ago
    Sorry, I misread jjgreen's comment. I 100% agree with what you are saying.
lmm 3y ago
The C community basically doesn't bother with libraries. They're so cumbersome to do in C that you'll tend to only have, like, 20 giant libraries in your (non-vendored) dependencies.

mid-kid 3y ago

It works in the C world because everyone is super fixated on library compatibility, and the programs are expected to be rebuilt by the distribution when necessary. When an API is broken, this entails a new major version and installing both versions side by side until all maintained software is ported. This doesn't happen often enough to be an issue - that's the perk of having a really mature ecosystem.

Aerbil313 3y ago
On the other hand, having tasted Nix, the process you are describing seems as backwards and archaic as operating punched card computers to me. So much wasted human time, serving a need (of an ecosystem) now obsolete, thanks to Nix.
- brabel 3y ago
  I'm trying to use Guix (just prefer it due to the language, Guile, over Nix) but unfortunately it doesn't have a lot of software packaged yet. I tried to build a project I have but it doesn't even have a "builder" for the language I used , Dart (which compiles to binary on all OSs), and I can't find out how to create a "builder" for it... someone did this for Nix to build pub packages so it's possible, but it seems if you want to use Nix/Guix you're stuck on a very limited set of things you can use? Is that a fair analysis? Do you have hints to build your own software when it's not available on Nix/Guix?
  - Aerbil313 3y ago
    See https://news.ycombinator.com/item?id=38171379 https://news.ycombinator.com/item?id=38171379 Also, nix can do arbitrary building (arbitrary commands). You don’t need a specialized builder. You can write a specialized builder for your language too, if it doesn’t exist.
  - dannymi 3y ago
    In general adding a build system to Guix works like this: 1. Git clone https://git.savannah.gnu.org/git/guix.git https://git.savannah.gnu.org/git/guix.git 2. Nicolò Balzarotti already has a work in progress patchset adding Dart itself--see https://issues.guix.gnu.org/44926 https://issues.guix.gnu.org/44926 . Patch your guix checkout with the files you can download on that page via the downarrow buttons on the right. 3. Create a file guix/build-system/dart.scm (I'd copy it from guix/build-system/dub.scm and then s/dub/dart/g and s/ldc/dartcc/g) or whatever it is. This file is the "front end" and is support for dart for the guix package manager script. 4. Create a file guix/build/dart-build-system.scm (I'd copy it from guix/build/dub-build-system.scm and then s/dub/dart/g). This file is the "back end" and is responsible for the build of your package inside a new container. 5. Add references to your new files to gnu/local.mk 6. In your user package script (whatever you want to compile in dart), add #:use-module (guix build-system dart) near the top and then add (build-system dart-build-system) to your package. 7. guix environment --pure guix 8. ./bootstrap 9. ./configure --localstatedir=/var 10. make -j5 11. exit 12. ./pre-inst-env guix build -f yourpackage.scm or whatever 13. Fiddle with the "invoke" parts in guix/build/dart-build-system.scm until your user package works. 14. Submit your results to 44926@debbugs.gnu.org or guix-devel@gnu.org (no need to be subscribed). As you can see, adding a new programming environment is quite some work. Because every programming environment has its own idiosyncracies, I don't think it can be avoided even in principle.

oblio 3y ago

Everyone is focusing on Nexus Firewall. Nexus/Artifactory themselves are private repos/proxies/caches that are in widespread use in the Java world so up to a point most companies prune their own repos. This is NOT standard practice in the JS/Python/PHP/whatever world because these products do not exist or are not widely available, everyone "drinks" directly from the open internet source. Yes, again, solutions exist, technically, but how many companies do you know, especially smaller ones, that do this? For Java almost every company bigger than 5 devs tends to set up their own Maven repo at some point, many do it on day 1 because at least 1 dev is familiar with this practice from their former BigCo and it's easy to set up Nexus/Artifactory.

claudex 3y ago
Artifactory works well with as a proxy for pip for Python
- oblio 3y ago
  Yeah, I know that these days they can do everything, but the cultural bias is there. The average Java dev will try to reach for Artifactory/Nexus much sooner than the average Python/Ruby/PHP/Javascript/... dev, in my experience.
  - pjmlp 3y ago
    Only because of company culture, in most enterprise projects I work on, doesn't matter the stack, everything gets legal and IT approvement into the internal Nexus. Devs might do whatever they feel locally, however if those files are going through CI/CD their dependencies better be in Nexus.
TeeMassive 3y ago
We use Artifactory as a PyPI mirror and a private package index and it works really great.

amelius 3y ago

> There's no technical solution to that, really. There is. Theoretically speaking, you could confine libraries to their own sandbox. But Rust can't do that.

pertique 3y ago
Do you have other info on languages that do? In my mind, if a library is compromised and incorporated in software that touches sensitive data then there's no way to meaningfully sandbox it. Sure, the library lives in the sandbox, but so does the stuff you're trying to protect. I'm not sure that's a Rust-specific problem.
- amelius 3y ago
  The library should live in its own sandbox, separated from the rest of the system including any other libraries. All system calls have to go through a permissions system that (e.g.) denies access by default. There is at least one language that tries to do that (someone posted it here in a comment some time ago, but I can't find it).
- marwis 3y ago
  Java (look up Security Manager). Unfortunately it is deprecated and scheduled for removal because too much security is annoying and not enough people care to use it.