this post was submitted on 04 Jul 2024
10 points (81.2% liked)

Rust Programming

8168 readers
4 users here now

founded 5 years ago
MODERATORS
nutomic@lemmy.ml
Joe@lemmy.ml
AgreeableLandscape@lemmy.ml
10
Rust has a HUGE supply chain security problem | Sylvain Kerkour | July 2, 2024 (kerkour.com)
submitted 4 months ago by ericjmorey@programming.dev to c/rust@lemmy.ml
6 comments fedilink hide all child comments
 

cross-posted from: https://programming.dev/post/16349359

July 2, 2024

Sylvain Kerkour writes:

Rust adoption is stagnating not because it's missing some feature pushed by programming language theory enthusiasts, but because of a lack of focus on solving the practical problems that developers are facing every day.

... no company outside of AWS is making SDKs for Rust ... it has no official HTTP library.

As a result of Rust's lack of official packages, even its core infrastructure components need to import hundreds of third-party crates.

  • cargo imports over 400 crates.

  • crates.io has over 500 transitive dependencies.

...the offical libsignal (from the Signal messaging app) uses 500 third-party packages.

... what is really inside these packages. It has been found last month that among the 999 most popular packages on crates.io, the content of around 20% of these doesn't even match the content of their Git repository.

...how I would do it (there may be better ways):

A stdx (for std eXtended) under the rust-lang organization containing the most-needed packages. ... to make it secure: all packages in stdx can only import packages from std or stdx. No third-party imports. No supply-chain risks.

[stdx packages to include, among others]:

gzip, hex, http, json, net, rand

Read Rust has a HUGE supply chain security problem

Submitter's note:

I find the author's writing style immature, sensationalist, and tiresome, but they raise a number of what appear to be solid points, some of which are highlighted above.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] nik9000@programming.dev 6 points 4 months ago (4 children)

I dunno about stdx as a solution. It's just not a big enough list.

At work we build a big java thing and we:

  • Manually import all dependencies, including transitive dependencies.
  • Bless them by committing their hash to our repo. I think the cargo lock file does something similar.
  • Audit the dependencies by hand. Sometimes that's reading them all and sometimes thats less. Honestly, it's often less. A few times it's being members of the upstream community.
  • Don't allow running as root
  • Drop all permissions we don't need with seccomp including reading a bunch of stuff
  • Sandbox each thread based on what's on the stack. Untrusted code can do less stuff.

It's still not enough. But it helps.

Maybe a web of trust for audited dependencies would help. This version of this repo under this hash. I could see stdx stuff being covered by the rust core folks and I'm sure some folks would pay for bigger webs. We pay employees to audit dependencies. Sharing that cost via a trusted third party or foundation or something feels eminently corporate. Maybe even possible.

[โ€“] ssokolow@lemmy.ml 2 points 4 months ago

Maybe a web of trust for audited dependencies would help. This version of this repo under this hash.

It'll probably please you to know that the alternative lib.rs frontend for the crates repository integrates both cargo-vet and cargo-crev data via an "Audit" tab that appears on the pages for crates that have such information.

load more comments (3 replies)