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:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
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.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
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!
Don't. Use. Npm.
That applies to pip and crate and all the other shitty lang package managers that totally fail at security
What should be used instead?
Easy, just vendor all your dependencies! Can't have a supply chain attack if you are the supply chain.
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?
Wouldn't verion pinning solve this problem?
Does this include the brew version?
lots of people recommend bitwarden, but i am more at peace with an offline password manager that i control like Keepass. You can also go the GNU route and use "pass" on Linux too
Or use a physical key like Yubikey to login
I use Enpass since 1Password became shit. It’s alright.
Only if yubibkey worked for more than the handful of sites/services. I have one for my bitwarden as majority of places want to send a text or us totp.
I've been trialing Vaultwarden for a while and while I do like the server sync setup and clean web access, the Bitwarden browser plugin is just okay despite being an "enterprise" solution. It misses probably about 20% of websites when creating a new account, forcing you to grab the password from the generator history and make a new entry manually.
KeepassXC is much better in that regard, and it's almost as good as the default credential handler of Firefox, and it lets you set up a bunch of custom stuff to extend the functionality if you want. Plus it has some neat kbdx options aside from AES256.
Only downside is syncing, which I'm debating how I'll deal with something better than syncthing on android (protocol is great, android makes it a PITA to have a background process if its not Google spyware).
It misses probably about 20% of websites when creating a new account, forcing you to grab the password from the generator history and make a new entry manually.
This makes me so fucking angry. How can a password manager be so bad at storing passwords, it's like it's only job. It even is generating the password for you! Aaaaaaaaaaaaaah!
TIL about the generator history
Not super helpful, because every time you open it, it generates a new one, so how do you know which one is the one it generated?
Can we stop using npm now?
I swear to god the number of attacks like this or spawned from other attacks like this is fucking stupid. I’ve gender seen anything like it.
Npm probably has the biggest attack surface and many of the libraries hosted there are in extremely widespread use. They've taken some steps to mitigate these supply chain attacks, but as we've seen with more recent examples, it's unrealistic to think they can be prevented completely. Most of these attacks use stolen developer credentials, which invalidates almost all potential security measures on the registry side and the best you can hope for is catching a malicious package quickly. To be clear: I think the JS ecosystem is uniquely positioned to be the prime target of supply chain attacks and while that doesn't excuse the slow implementation of security measures from the npm team, the people arguing that other package managers and registries aren't vulnerable to this have to be huffing fumes.
That’s fair, I won’t pretend pypi/pip and running uvx is much safer than npx.
But why hasn’t JavaScript established a defacto stdlib to replace ask the left pads and is even type packages?
I’ve taken a near zero dependency policy on my personal projects regardless, and now I run most code in containers to sandbox it.
As someone completely unfamiliar with the JavaScript mess, are these security issues specific to npm the actual repository or npm the package manager?
If it's the latter, does using something else like yarn or bun instead help?
It's not, it's a problem of every package manager that do not use sources and checksums, like rust and python. Take a look at this article that does a better job then me at explaining the situation.
In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.
17%!
Let me rephrase this, 17% of the most popular Rust packages contain code that virtually nobody knows what it does (I can't imagine about the long tail which receives less attention).
Given that he lied about the results of the analysis he is using to prove his point, I find it hard to trust anything in this article.
In the analysis, Harvey said only 8 repositories did not match their upstream repos. The other problems were issues like not including the VCS info, squashing history, etc.
EDIT: Also, I just noticed that he called it a "recent" analysis. It's roughly a two year old analysis. I expect things have improved a bit since then, especially since part of the problem was packaging using older versions of Cargo.
The good news is that there already is a gold standard for supply chain security: the Go programming language.
Lmfao
Competent standard lib + decentralized libs + checksum db.
While the article is a bit theatralic, it offers important arguments.
I think npm allows installation scripts which do make this worse, as a package can run arbitrary command at install time.
Npm has gotten a few config options that prevent this behaviour. We can only hope that they will become the default eventually.
This problem has nothing to do with NPM. Checkmarx was compromised last month, and during that compromise there were malicious VS Code extensions published to Visual Studio Code Marketplace. A Bitwarden developer says that somebody ran one of those malicious extensions, and GitHub API keys were stolen which were used in publishing the malicious CLI package.
It's probably better that it happened on NPM. If the CLI were only downloadable from the Bitwarden website, it would have likely taken longer for somebody to notice something was wrong.
Yes, but NPM has been had countless security problems, this isn't a new problem. Even tho this instance is not a problem of NPM itself, it still has been proven as one of the most unreliable and insecure package managers out there.
I'm not a particular fan of npm, but you'll probably see this kind of thing with any package manager of similar size. More a matter of what's the most attractive target than the package tech itself.
But why does NPM enable post install scripts by default? Why is there no way to define a minimum release age for dependency versions? It’s just poor design choices.
Genuine question. How is NPM more vulnerable than other repos? Haven't similar supply chain attacks succeeded at least as well as this one through GitHub itself and even Linux package repos?
Larger standard libraries do a lot. It's a lot harder to sneak vulnerabilities into the basic C# or Java or C++ libraries than it is to add a vulnerability to something one dude maintains in the javascript ecosystem.
And since javascript libraries tend to be so small and focused, it's become standard practice for even other libraries to pull in as many of those as they want.
And it stacks. Your libraries pull in other libraries which can pull in their own libraries. I had a project recently where I had maybe a dozen direct dependencies and they ended up pulling in 1,311 total libraries, largely all maintained by different people.
In a more sane ecosystem like C#, all the basics like string manipulation, email, or logging have libraries provided by Microsoft that have oversight when they're changed. There can be better, third-party libraries for these things (log4net is pretty great), but they have to compete with their reputation and value over the standard library, which tends to be a high bar. And libraries made on top of that system are generally pulling all those same, certified standard libraries. So you pull in 3 libraries and only one of those pulls in another third party single library. And you end up with 4 total third party libraries.
Javascript just doesn't really have a certified standard library.
(This certified standard library doesn't have to be proprietary. Microsoft has made C# open source, and Linus Torvalds with the Linux Kernel Organization holds ultimate responsibility for the Linux kernel.)
I will almost always choose .NET as my development platform when greenfielding a project for exactly this reason. It's an incredibly robust standard library that virtually guarantees I won't need to pull in a litany of additional utility libraries, and I can also expect that what libraries I do choose to bring in are highly unlikely to drag along a ridiculous parade of dependencies.
will almost always choose .NET as my development
Do you feel its still worth learning now?
Probably more worth than it was 15 years ago since you're no longer restricted to Windows and it's now open source. I've heard a lot of people say it's nicer than Spring for enterprise stuff. Haven't tried it much myself though. Was fairly easy to set up a simple API, but I then got distracted by other projects.
And since javascript libraries tend to be so small and focused
Lol, LMAO even
Left-pad tho
Part of the problem is also how many packages people bring in, even for the simplest of things.
I'll just keep using keepass.
Keep ass?
You know it
Yeah, as in keep it closed so you don't get fucked by the hackers.
It has only been available for 2h30 on NPM, so unless you had the misfortune of installing the latest version in this short window, you should be fine. Thankfully people have been able to quickly catch this.
This is one of the reasons why I update a version or two behind. The other reason is because I'm lazy.
reposting the tl;dr I wrote from another community...
Yesterday, for about 1h30min (starting at 5:57pm ET / 21:57 UTC) anyone installing the latest version of the command line interface of bitwarden was installing malware.
The malware steals GitHub/npm tokens, .ssh, .env, shell history, GitHub Actions and cloud secrets, then exfiltrates the data to private domains and as GitHub commits and doesn't seem to be targeting Bitwarden specifically, or user vaults.
There's no evidence that end user vault data was accessed or at risk, or that production data or production systems were compromised, according to their official statement.
It seems there were 334 bitwarden CLI downloads in this time period, some or many of which might have been from bots, so this is a higher bound to the number of affected users.