this post was submitted on 23 Apr 2026
615 points (99.7% liked)

Selfhosted

58738 readers
1411 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Nibodhika@lemmy.world 1 points 16 hours ago* (last edited 16 hours ago)

That article has lots of issues:

17% of the most popular Rust packages contain code that virtually nobody knows what it does

That's not true at all, the article where he got that information from says:

Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.

So, of the 999 most popular crates analyzed 0% contains code nobody knows what it does.

He then lists some ways packages can be maliciously compromised:

  1. Steal credentials and impersonate a dev
  2. Misleading package names
  3. Malicious macros (this one is interesting, had never considered it before)
  4. Malicious build script

And his solutions are:

  1. Bigger std library (solves none of the above)
  2. Source dependencies (solves none of the issues he showed, only the issue that happens in 0% of packages where binary doesn't match the source and is detectable)
  3. Decentralized packages (which worsens every security concern)
  4. Centralized Checksum database (so a centralized package manager is bad, but a centralized Checksum index is good? How does that work?)

Honestly I can't take that article seriously, it grossly misinterpreted another study, presents problems that exist on every single package manager ever, doesn't propose ANY valid solution, and the only thing he points to as a solution suffers from ALL of the same issues and then some.