4 ms·

You’ll find more quality libraries in C because people don’t care about splitting them down to microscopic parcels. Even something like ‘just’ have tens of dep

You’ll find more quality libraries in C because people don’t care about splitting them down to microscopic parcels. Even something like ‘just’ have tens of deps, including one to check that something is executable. https://github.com/casey/just/blob/master/Cargo.toml https://github.com/casey/just/blob/master/Cargo.toml That’s just asking for trouble down the line.

pheggs 9mo ago
yes, the average amount of dependencies used per dependency appears to be much larger in rust and thats what I meant and is worrying me. In theory C can be written in a memory safe manner, and in theory rust can be used without large junks of supply vulnerabilities. both of these are not the case in practice though
- dbdr 9mo ago
  One difference is that it's an incredibly hard problem to check whether your C code is memory safe since every single line of your code is a risk. On the other hand, it's easy to at least assess where your supply vulnerabilities lie (read Cargo.toml), and you can enforce your policy of choice (e.g. whitelist a few specific dependencies only, vendor them, etc).
  - pheggs 9mo ago
    I would argue that almost all major rust projects use dependencies. Checking the dependencies for vulnerabilities might be just as difficult as checking C code for memory safety, maybe even worse, because dependencies have dependencies and the amount of code to be checked can easily sky rocket. The problem gets even worse if you consider that not all rust code is safe, and that C libraries can be included and so on
    - dbdr 9mo ago
      Yes, but I believe that results in a cost/benefit analysis. If there are readily available rust crates that do something you need, and the cost of a possible vulnerability is not huge, most projects might decide (right or wrong) that it is worth it. It's an interesting question why projects tend to make different decisions in different languages, but it does not necessarily mean that you have to make the same decisions. My point is that if you put a very high emphasis on avoiding vulnerabilities, you can either write the code in C with no/limited dependencies (and still risk memory safety bugs), or write the code in Rust with no/limited dependencies and no/limited unsafe code, and get much stronger guarantees for the same/less effort.
      - pheggs 9mo ago
        Fair, you see the perspective from someone writing the software and it makes sense. But when I see it though the lenses of someone choosing software to run, I would rather choose a C program with potential memory bugs than a rust program with a lot of dependencies - because I am more scared about supply chain attacks than someone being able to exploit a memory bug. But then again, this obviously changes if the rust program has no dependencies.
- kibwen 9mo ago
  > both of these are not the case in practice though No, people routinely write Rust with no third-party dependencies, and yet people do not routinely write C code that is memory-safe. Your threat model needs re-evaluating. Also keep in mind that the most common dependencies (rand, serde, regex, etc) are literally provided by the Rust project itself, and are no more susceptible to supply chain attacks than the compiler.
  - pheggs 9mo ago
    I know it's a sensitive topic for a lot of people, but as I said, I love rust. I don't know a lot of rust projects though that don't use any dependencies. In my humble opinion, disregarding the risks of such supply chain attacks is at least as bad as people disregarding the risk of memory unsafe code. But keep in mind, I'm not saying don't use rust.
  - mamma_mia 9mo ago
    mamma mia! one day anyhow and anyerror will be backdoored it's inevitable
  - ceteia 9mo ago
    People also write Rust code that is not memory-safe. https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
    - joshuamorton 9mo ago
      But not "routinely".
      - ceteia 9mo ago
        How can you be sure? When I looked at for instance sudo-rs, it proclaimed loudly that it is memory safe, but its code has lots of unsafe. https://github.com/trifectatechfoundation/sudo-rs https://github.com/trifectatechfoundation/sudo-rs https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo-rs&f.repo.pattern=sudo&q=unsafe https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo... And Miri is very popular in Rust. Even if a Rust project doesn't have unsafe, sometimes people still run Miri with it, since dependencies might have messed up their unsafe usage.
bigfatkitten 9mo ago
You also won’t typically find C/C++ developers blinding yolo’ing the latest version of a dependency from the Internet into their CI/CD pipeline. They’ll stick with a stable version that has the features they need until they have a good reason to move. That version will be one they’ve decided to ship themselves, or it’ll be provided by someone like Debian or Red Hat.
- pjmlp 9mo ago
  Unless of course they are using vcpkg, conan or FetchContent. Most corporations are already using the likes of Nexus or JFrog Artifactory, regardless of the programming language.

pheggs 9mo ago

yes, the average amount of dependencies used per dependency appears to be much larger in rust and thats what I meant and is worrying me. In theory C can be written in a memory safe manner, and in theory rust can be used without large junks of supply vulnerabilities. both of these are not the case in practice though

dbdr 9mo ago
One difference is that it's an incredibly hard problem to check whether your C code is memory safe since every single line of your code is a risk. On the other hand, it's easy to at least assess where your supply vulnerabilities lie (read Cargo.toml), and you can enforce your policy of choice (e.g. whitelist a few specific dependencies only, vendor them, etc).
- pheggs 9mo ago
  I would argue that almost all major rust projects use dependencies. Checking the dependencies for vulnerabilities might be just as difficult as checking C code for memory safety, maybe even worse, because dependencies have dependencies and the amount of code to be checked can easily sky rocket. The problem gets even worse if you consider that not all rust code is safe, and that C libraries can be included and so on
  - dbdr 9mo ago
    Yes, but I believe that results in a cost/benefit analysis. If there are readily available rust crates that do something you need, and the cost of a possible vulnerability is not huge, most projects might decide (right or wrong) that it is worth it. It's an interesting question why projects tend to make different decisions in different languages, but it does not necessarily mean that you have to make the same decisions. My point is that if you put a very high emphasis on avoiding vulnerabilities, you can either write the code in C with no/limited dependencies (and still risk memory safety bugs), or write the code in Rust with no/limited dependencies and no/limited unsafe code, and get much stronger guarantees for the same/less effort.
    - pheggs 9mo ago
      Fair, you see the perspective from someone writing the software and it makes sense. But when I see it though the lenses of someone choosing software to run, I would rather choose a C program with potential memory bugs than a rust program with a lot of dependencies - because I am more scared about supply chain attacks than someone being able to exploit a memory bug. But then again, this obviously changes if the rust program has no dependencies.
kibwen 9mo ago
> both of these are not the case in practice though No, people routinely write Rust with no third-party dependencies, and yet people do not routinely write C code that is memory-safe. Your threat model needs re-evaluating. Also keep in mind that the most common dependencies (rand, serde, regex, etc) are literally provided by the Rust project itself, and are no more susceptible to supply chain attacks than the compiler.
- pheggs 9mo ago
  I know it's a sensitive topic for a lot of people, but as I said, I love rust. I don't know a lot of rust projects though that don't use any dependencies. In my humble opinion, disregarding the risks of such supply chain attacks is at least as bad as people disregarding the risk of memory unsafe code. But keep in mind, I'm not saying don't use rust.
- mamma_mia 9mo ago
  mamma mia! one day anyhow and anyerror will be backdoored it's inevitable
- ceteia 9mo ago
  People also write Rust code that is not memory-safe. https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
  - joshuamorton 9mo ago
    But not "routinely".
    - ceteia 9mo ago
      How can you be sure? When I looked at for instance sudo-rs, it proclaimed loudly that it is memory safe, but its code has lots of unsafe. https://github.com/trifectatechfoundation/sudo-rs https://github.com/trifectatechfoundation/sudo-rs https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo-rs&f.repo.pattern=sudo&q=unsafe https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo... And Miri is very popular in Rust. Even if a Rust project doesn't have unsafe, sometimes people still run Miri with it, since dependencies might have messed up their unsafe usage.

bigfatkitten 9mo ago

You also won’t typically find C/C++ developers blinding yolo’ing the latest version of a dependency from the Internet into their CI/CD pipeline. They’ll stick with a stable version that has the features they need until they have a good reason to move. That version will be one they’ve decided to ship themselves, or it’ll be provided by someone like Debian or Red Hat.

pjmlp 9mo ago
Unless of course they are using vcpkg, conan or FetchContent. Most corporations are already using the likes of Nexus or JFrog Artifactory, regardless of the programming language.