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

Selfhosted

58738 readers
1244 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
[–] quick_snail@feddit.nl 43 points 1 day ago (6 children)

Don't. Use. Npm.

That applies to pip and crate and all the other shitty lang package managers that totally fail at security

[–] Einskjaldi@lemmy.world 1 points 3 hours ago

What about using pip just to download basic common libraries for offline use?

[–] captcha_incorrect@lemmy.world 40 points 1 day ago (2 children)
[–] quick_snail@feddit.nl 7 points 20 hours ago (1 children)

A package manager that uses cryptographic signatures. Apt had this since 2005 iirc. Use apt.

[–] AtHeartEngineer@lemmy.world 7 points 18 hours ago (1 children)

if the dev(s) gets compromised there's the same issue, except with an extra checkmark on it.

[–] quick_snail@feddit.nl 2 points 17 hours ago (1 children)

Packages are reviewed by package maintainers.

Humans are required to solve a malicious insider. But most supply chain vulns of these shitty software dependency managers were resolved decades ago by freely available cryptography

[–] AtHeartEngineer@lemmy.world 2 points 13 hours ago

Human review really should be what's needed, maybe not even just by the package maintainers.

[–] grandma@sh.itjust.works 22 points 1 day ago

Easy, just vendor all your dependencies! Can't have a supply chain attack if you are the supply chain.

[–] HubertManne@piefed.social 3 points 19 hours ago (2 children)

so many workplaces I have been at used npm.

[–] victorz@lemmy.world 1 points 13 hours ago

We just recently switched from npm to pnpm, due to all the supply chain attacks. I did the PR for it, even.

Our release schedule is like a year though so we don't really have to worry much about releasing compromised dependencies. But still, better to be on the safer side.

[–] quick_snail@feddit.nl 3 points 17 hours ago

Yep. And so many workplaces have had security vulnerabilities caused by dumb decisions that could have been easily avoided

[–] rmrf@lemmy.ml 6 points 23 hours ago (4 children)

Honestly just fine use computers at all, completely eliminate the remote attack vector. And only drink rain water since city water can be compromised.

Or, recognize this is a normal part of using software and have more than 1 thing between you and a breach

[–] quack@lemmy.zip 30 points 20 hours ago (1 children)

The rules of cybersecurity:

  1. Under no circumstances should you own a computer.

  2. If you absolutely must own a computer, under no circumstances should you connect it to the internet.

  3. If you absolutely must connect it to the internet, it’s too late and they already have you

[–] HubertManne@piefed.social 3 points 19 hours ago

I know this is a joke but im old enough we used to install the os and had it on the network and eventually update it but then it got to the point were like being connected to the internet for like a minute and the machines were compromised. Thats when we got off our duffs and started making custom installs that had updates and configurations and software pre installed before we even connected it to the net.

Dude, rain water is full of pollutants too. 😂

[–] quick_snail@feddit.nl 3 points 20 hours ago (1 children)
[–] stardreamer@lemmy.blahaj.zone 6 points 18 hours ago* (last edited 18 hours ago) (1 children)

And how would apt help in this particular case? A supply chain attack can happen with any particular package manager. In this case, the compromised package was detected and mitigated within 93 minutes, affecting a total of ~330 users. Which is a lot better than how a lot of distros handled the xz breach last year.

All reasonably secure package managers (and https) operate on a chain of trust. There is little that can be done if that chain of trust is broken.

Based on this the cause was a malicious VSCode extension that stole credentials that were later used to trigger a deployment CI/CD pipeline. If there's anything to learn from this, it's probably to not use VSCode.

[–] quick_snail@feddit.nl 2 points 17 hours ago (1 children)

With cryptography. X.509 is trash. They should pin the public key.

[–] stardreamer@lemmy.blahaj.zone 3 points 17 hours ago (1 children)
  1. If your assumption is that X509 is trash, does that mean you hold the same amount of distrust to TLS?
  2. How do you propose the scaling of key management? Do you have a reasonable alternative to users blindly trusting every single key they come across?
  3. Back to my original question: what prevents a VSCode extension from stealing a private signing key (as opposed to an API key) and causing the same issues described here?
[–] quick_snail@feddit.nl 1 points 6 hours ago (1 children)

TLS is fine with certificate pinning m

[–] stardreamer@lemmy.blahaj.zone 1 points 5 hours ago

That still leaves two out of three questions unanswered. Most importantly the last one, which was addressed towards the original complaint.

[–] kahoodd@reddthat.com 1 points 21 hours ago

it's much more convenient when you use something like btrfs-snapshots

[–] wizzim@infosec.pub 2 points 1 day ago (4 children)

Unfortunately I have to use node for home project (Jellyfin tizen)

I was wondering: would it be possible to run node in a sandbox to lower the scope of the attack? (i.e. not compromise my home computer) Or is maybe a full VM a better solution?

[–] PumaStoleMyBluff@lemmy.world 5 points 21 hours ago

Technically you can use node without npm.

[–] quick_snail@feddit.nl 3 points 20 hours ago (1 children)
[–] wizzim@infosec.pub 2 points 18 hours ago (1 children)

I need to build it, jellyfin-tizen is a separate project for Samsung TVs

[–] quick_snail@feddit.nl 5 points 17 hours ago

I think you need to throw out the Samsung TV to be secure

[–] captcha_incorrect@lemmy.world 6 points 1 day ago (1 children)

Wouldn't verion pinning solve this problem?

[–] dieTasse@feddit.org 1 points 16 hours ago

In case of NPM version pinning is a good practice. But also set it to ignore post install scripts. They are a bad practice and only about 2 % of all packages use it so it is unlikely it will bother you. They, the post install scripts, were used in recent supply chain attacks btw (the axios). You can either set it project wide in .npmrc file, add ignore-scripts=true, that is good for project where multiple people collaborate. And/Or system wide by running npm config set ignore-scripts true for your personal workspace. You can also achieve it by using --ignore-scripts flag during npm install, but that is way too impractical to always think about it. Also I would recommend checking npq, its a wrapper around npm cli that will give you some security summary before installing anything (and it is able to give you warning about post install scripts).

[–] quick_snail@feddit.nl 2 points 20 hours ago

Full VM and network isolation. and dont put anything important there (nor a reused password for auth)