I maintain what is probably the most popular Ethereum simulator (Ganache) and it uses the npm ecosystem.
Years ago I chose to pin/lock all dependencies, even transitive dependencies (direct dependencies' dependencies) to much disagreement from the semver purists.
Crypto developers are extra high value targets because they likely access their wallet from the same machine they develop on. So I've taken a very hard stance on this, even feel we should do even better by disallowing updates for new releases (I realize adequate security here is not practical/feasible for most).
To make matters worse: devs often install npm packages with sudo (and I have a canned response for sudo related issues telling them that they must now format their drives to fix it, and even that might not be enough as their bios and other embedded firmware could also be compromised).
Meanwhile, yarn, a popular npm alternative, will NOT respect a package author's wishes to lock transitive dependencies. It's maddening (don't use yarn until/unless they fix this).
The only time a dependency shouldn't be pinned is if you are also the author of that dependency.
Anyway, people would say I'm fun at parties, but they stopped inviting me long ago.
My preferred fix for Yarn dependency tracking is to use zero installs[1] as there is no command to run and dependencies can be exactly what ships in the repo and nothing more (with the right flags). If accepting PRs from third-parties, the check-cache flag can run in CI to validate checksums from untrusted contributors — plus, you know, reading dependency source code when you have the time or reason to do so would be great within a PR review also.
I wish more tools were able to concisely show you the differences between dependencies, but… sometimes dependencies have binaries and at that point you might need to fork or clone and build your own version of a dependency. I’d suggest only using dependencies when you can read and understand the code, but there are always limits. I can’t think of the last time I thought of a glibc dependency except when using Alpine or compiling something for Cgo. But it’s still something to keep in mind: that sometimes your project will be simpler and easier with fewer, smaller dependencies where you can read the code in full.
It's maddening the crypto world relies on Javascript so heavily. As a language it would never be my first, second, or even third choice for financial services.
I didn't know that about yarn transitives, do you have a link explaining more about the problem? I assumed a yarn.lock would.. lock, interesting to know more.
I appreciate your thoughtfulness, and someone who thinks deeply about things with a touch of self-deprecation is the exact kind of conversation I enjoy at parties ;)
I feel like if you're a maintainer that does, or has done, this sort of thing you should not be maintaining software in FOSS. The FOSS ecosystem is built on a lot of trust and actions like this violate that foundation.
On the other hand, the people that sent SWAT teams to his door and sent death threats are equally threatening the trust foundations of FOSS.
To me it’s just a reminder that you can’t just rely on trust and good faith when building systems including the internet itself. You have to design for bad actors or the honest people suffer.
Just shows how well the trust system works. There is no foundation, unless some certified org wants to take it upon them to verify OSS. And that costs money.
That people call SWAT teams on the maintainer, I hadn't heard, but that's so much worse. The effect is also rather different. I don't have much OSS, and certainly nothing of any importance, but I'm going to keep the project I'm working on private. Too bad if someone else might have been interested.
IANAL but I would go a lot further and say this behavior should be prosecuted. If this isn't a violation of the CFAA or something like it, it should be amended to include it.
This is career suicide and undermines the ecosystem due to the loss of trust.
Honest question, what can be done to address this type of issue? Lock fines are great and all but people rarely dig into their dependencies when upgrading.
> Honest question, what can be done to address this type of issue?
It is hard.
* Minimize dependencies. This is a problem for small organizations that really don't want to rewrite the world.
* Encourage dependencies on organizations that you have trust relationships or contractual relationships with. It is way less likely (though not impossible) that some malicious code will end up in an apache package than some random npm package owned by an individual person.
* Audit dependency changes. At the very least, have systems that detect various known-dangerous APIs showing up in OSS dependencies.
* Make it somebody's job to keep 3rd party code in check. This means pulling updates, auditing updates, and retiring unnecessary dependencies. People at your company should be able to get promoted by saying "we reduced the number of warranty-free dependencies in our codebase by 50%."
Honestly, the way I wish we could fix this is to go back to people paying for software they rely on.
It would be (in my opinion) a fascinating court case to sue a company which got hacked which used lots of OSS, which all had a warranty that says "may not be fit for purpose".
If you built a house out of wood labelled "no warranty, may not be fit for purpose", and it fell down, I imagine you would be held responsible.
We are freezing our dependencies and aiming at almost never upgrading or updating things when possible. We rarely need the new things these modules come with in newer versions especially because some enhancements are security concern disguised as features.
It seems that in the past 2 years people became more pissed about the current state of things than normal. Since fakerjs incident I no longer trust maintainers by default.
You know how some people get very funny in the head discussing politics? This seems to be entering the field of programming bit by bit after programmers slowly realized they are the ones who shape the world. Some people don't know how to handle that level of responsibility so they see 'contributing' as a means to having a lot of power so that when something pokes them wrong they can unleash all their anger and it's not on a 140-character tweet that does nothing and instead it is on all the companies they managed to hold ransom over the free work he was going over the time people were treating him right.
Short-term: The only way out of this is to review + whitelist every package before it hits the NPM registry. This is something my company is building and we did a write up about it (and Node-ipc) here[0].
Longer term answer: Something like Deno needs to take off that adds permissions per dependency. We need to sandbox all untrusted code by default.
> Honest question, what can be done to address this type of issue?
Limit your number of (transitive) dependencies, to lower the risk. Yes, this often needs more work on your side.
Use a curated package repository such as Debian/Ubuntu or Fedora (or a repository your company maintains), and only use dependencies from there. Yes, this is very painful for ecosystems that are still moving fast such as JS/Go/Rust, because many packages are not available yet, and non-security updates are less frequent.
Mostly paying for some expensive software which says it protects us from this sort of crap but all it does is allow us to tick the compliance box while the engineers on the project flip between bouts of paranoia and insomnia.
I wish I was even joking.
At this point I tend to avoid importing anything if I can. I’ve written lots of stuff recently using Go and no imported packages because I trust the vendor more than I trust an open source package repo with 10,000 unknown contributors and dependencies.
In this case it was pretty much addressed: few people have installed the malicious version, due to lockfiles and it being quickly blackholed from the ecosystem, by the major package through which this dependency snuck in (vue-cli, IIRC) quickly pinning its dependency to the unaffected version.
Nope, I'd still hire them and this tells me the ecosystem is dealing with a threat in an appropriate way. Russia citizens have given up their right to play with the rest of the tech world. The fact that this is a silly way to do it doesn't change that In 2022 I'm having to explain that if your citizens are cheering you on as you invade a sovereign nation while indiscriminately killing civilian you will face some reprocussians from those of us who have said enough is enough.
Anything short of literally killing Russians, including a embargo is fair game.
Disagree? Go explain it to the Ukrainian father burying his daughter. I don't want to hear it.
you don't. unless your lib has an advisory, why would you upgrade? if it works it works. this whole movement of "move fast and break things" is braindamaged and it's about time it comes crashing unto itself.
Only auto-upgrade for security fixes. For all others, wait between month to a year to update a dependency, unless one specifically fixes a bug you are experiencing.
Supplier-side: multi-party code review for acceptance of changes into widely-used software.
Consumer-side: multi-party review prior to upgrades of dependencies in applications.
(note that neither of these necessarily require knowing the identity of the software author(s). in fact, perhaps reviews would be less biased in the absence of that information)
> Honest question, what can be done to address this type of issue?
Paid subscription-based NPM ? Yes, you could download a dependency directly from the repository on Github for free, but if do so through the paid NPM they assure you that the package is malware-free.
I think first thing would be to remove wildcards from version specs and lock them to your known, tested versions. Then only do upgrades after some time of stability in the ecosystem (i'd wait months, not days, for that)
For extra irony, observe that node-ipc was previously released under the "Don't Be A Dick" license¹, only switching to MIT in late 2020². The DBAD license includes this:
Being a dick includes - but is not limited to - the following instances:
(...)
1c. Modifying the original work to contain hidden harmful content. That would make you a PROPER dick.
By the terms of its original license, I think we can therefore assert that the author is, indeed, a proper dick.
GitHub really needs to explain itself here. I reported this repo, and of course they never really tell you what they decide to do. However, I asked them specifically to clarify themselves on their malware policies. Since from the looks of it, GitHub declared this as malicious code, but then still left the repo up and the maintainer has apparently suffered no consequences, since he later reverted the malicious code.
So the message they are apparently sending here is that means that it's totally OK to host malware on GitHub, given that it's targeted against a politically unpopular group of people, and if you later revert the change after it's done a bunch of damage.
Are some of those Russian developers assholes who support the Ukrainian genocide? Probably yes, but it's an extremely bad precedent to set to allow someone to use your platform for this just because it's politically fashionable.
And yes, I know that there are other things that other people might consider "malware" on GitHub under an overbroad definition of it (exploit PoCs, things like yt-dl, etc.), but this is pretty clear cut, since it hid this "feature" from users and very clearly caused destruction. Either the developer is incompetent at writing obfuscated code and the wiping functionality was a mistake (unlikely), or they are just that dishonest about what their motives actually were. Or just plain delusions of grandeur, equating cyberwarfare with peace...
Apparently though, it's all OK in this instance since it's collective punishment against the right group of people. I think the thing that makes me most angry about this is that the malware developer used the assumption that geo-ip databases are always 100% accurate...
It looks like the node-ipc has become a target for spam issues lately[0]. This reminds me of what happened with Notepad++[1] (except that was nothing compared to what the node-ipc maintainer did.)
EDIT: looks like Notepad++ also made a political statement about the crisis in Ukraine[2].
What the node ipc maintainer did was prove there was at least one person with scruples in this industry. Reading the rest of this thread is proving he's a minority though, depressing.
Also if you're going to delete my comments just delete my account. I'm done ignoring my industry will gladly enable dictators and pretending we are neutral. We are complicit and we need to take a stand... Or maybe we all just want to collect our fat paychecks while inventing more ways to kill people. Shrug.
Does anyone have an idea as to why OSS maintainers are doing this more and more often? Are they fed up with the sustainability of OSS that this is an opportunity to retaliate? I think this is the third "supply chain attack" through protest in two months. Is this the right way to protest?
I guess that the only solution for malicious packages problem would be to have someone review the code. As there's lot of code and reviewing takes time, this has to be a paid service - for a pay you get access to a "safe" repository.
I am not sure if it could be viable business model though. People who use open source got used that it is free and are unlikely to pay.
Tangential question(s): is there a way to lock node projects within a folder, that is, prevent any scripting action going outside its source folder? Creating a group that has permissions to specific folder helps? How can one isolate these projects (possible) harmful behaviour?
Treating this as "malicious" isn't helping fight Russian disinformation, which is even more concerning seeing as Russian developers are openly dismissing genocide in Ukraine, and unironically citing Putinist "anti-nazi" propaganda.
[+] [-] 0x0000000|4 years ago|reply
[+] [-] davidmurdoch|4 years ago|reply
Years ago I chose to pin/lock all dependencies, even transitive dependencies (direct dependencies' dependencies) to much disagreement from the semver purists.
Crypto developers are extra high value targets because they likely access their wallet from the same machine they develop on. So I've taken a very hard stance on this, even feel we should do even better by disallowing updates for new releases (I realize adequate security here is not practical/feasible for most).
To make matters worse: devs often install npm packages with sudo (and I have a canned response for sudo related issues telling them that they must now format their drives to fix it, and even that might not be enough as their bios and other embedded firmware could also be compromised).
Meanwhile, yarn, a popular npm alternative, will NOT respect a package author's wishes to lock transitive dependencies. It's maddening (don't use yarn until/unless they fix this).
The only time a dependency shouldn't be pinned is if you are also the author of that dependency.
Anyway, people would say I'm fun at parties, but they stopped inviting me long ago.
[+] [-] lstamour|4 years ago|reply
I wish more tools were able to concisely show you the differences between dependencies, but… sometimes dependencies have binaries and at that point you might need to fork or clone and build your own version of a dependency. I’d suggest only using dependencies when you can read and understand the code, but there are always limits. I can’t think of the last time I thought of a glibc dependency except when using Alpine or compiling something for Cgo. But it’s still something to keep in mind: that sometimes your project will be simpler and easier with fewer, smaller dependencies where you can read the code in full.
1: https://yarnpkg.com/features/zero-installs#does-it-have-secu...
[+] [-] datalopers|4 years ago|reply
[+] [-] bushbaba|4 years ago|reply
[+] [-] nhoughto|4 years ago|reply
[+] [-] Gigachad|4 years ago|reply
[+] [-] glenngillen|4 years ago|reply
[+] [-] mhio|4 years ago|reply
Do you mean locking transitive dependencies across an upgrade of a direct dependencies? How does npm do that?
[+] [-] jaquers|4 years ago|reply
[+] [-] alisonkisk|4 years ago|reply
[deleted]
[+] [-] kodah|4 years ago|reply
On the other hand, the people that sent SWAT teams to his door and sent death threats are equally threatening the trust foundations of FOSS.
Link to the vice article talking about SWATing: https://www.vice.com/en/article/dypeek/open-source-sabotage-...
[+] [-] hombre_fatal|4 years ago|reply
[+] [-] tgv|4 years ago|reply
That people call SWAT teams on the maintainer, I hadn't heard, but that's so much worse. The effect is also rather different. I don't have much OSS, and certainly nothing of any importance, but I'm going to keep the project I'm working on private. Too bad if someone else might have been interested.
[+] [-] user3939382|4 years ago|reply
[+] [-] tedunangst|4 years ago|reply
[+] [-] tejohnso|4 years ago|reply
Where are you getting this?
[+] [-] arriu|4 years ago|reply
Honest question, what can be done to address this type of issue? Lock fines are great and all but people rarely dig into their dependencies when upgrading.
How are you guys dealing with upgrades?
[+] [-] UncleMeat|4 years ago|reply
It is hard.
* Minimize dependencies. This is a problem for small organizations that really don't want to rewrite the world.
* Encourage dependencies on organizations that you have trust relationships or contractual relationships with. It is way less likely (though not impossible) that some malicious code will end up in an apache package than some random npm package owned by an individual person.
* Audit dependency changes. At the very least, have systems that detect various known-dangerous APIs showing up in OSS dependencies.
* Make it somebody's job to keep 3rd party code in check. This means pulling updates, auditing updates, and retiring unnecessary dependencies. People at your company should be able to get promoted by saying "we reduced the number of warranty-free dependencies in our codebase by 50%."
[+] [-] CJefferson|4 years ago|reply
It would be (in my opinion) a fascinating court case to sue a company which got hacked which used lots of OSS, which all had a warranty that says "may not be fit for purpose".
If you built a house out of wood labelled "no warranty, may not be fit for purpose", and it fell down, I imagine you would be held responsible.
[+] [-] Gravyness|4 years ago|reply
It seems that in the past 2 years people became more pissed about the current state of things than normal. Since fakerjs incident I no longer trust maintainers by default.
You know how some people get very funny in the head discussing politics? This seems to be entering the field of programming bit by bit after programmers slowly realized they are the ones who shape the world. Some people don't know how to handle that level of responsibility so they see 'contributing' as a means to having a lot of power so that when something pokes them wrong they can unleash all their anger and it's not on a 140-character tweet that does nothing and instead it is on all the companies they managed to hold ransom over the free work he was going over the time people were treating him right.
[+] [-] freeqaz|4 years ago|reply
Short-term: The only way out of this is to review + whitelist every package before it hits the NPM registry. This is something my company is building and we did a write up about it (and Node-ipc) here[0].
Longer term answer: Something like Deno needs to take off that adds permissions per dependency. We need to sandbox all untrusted code by default.
0: https://www.lunasec.io/docs/blog/node-ipc-protestware
[+] [-] progval|4 years ago|reply
Limit your number of (transitive) dependencies, to lower the risk. Yes, this often needs more work on your side.
Use a curated package repository such as Debian/Ubuntu or Fedora (or a repository your company maintains), and only use dependencies from there. Yes, this is very painful for ecosystems that are still moving fast such as JS/Go/Rust, because many packages are not available yet, and non-security updates are less frequent.
[+] [-] hughrr|4 years ago|reply
I wish I was even joking.
At this point I tend to avoid importing anything if I can. I’ve written lots of stuff recently using Go and no imported packages because I trust the vendor more than I trust an open source package repo with 10,000 unknown contributors and dependencies.
[+] [-] kevinsundar|4 years ago|reply
[+] [-] Vinnl|4 years ago|reply
[+] [-] jddil|4 years ago|reply
Anything short of literally killing Russians, including a embargo is fair game.
Disagree? Go explain it to the Ukrainian father burying his daughter. I don't want to hear it.
[+] [-] avereveard|4 years ago|reply
[+] [-] throwaway984393|4 years ago|reply
Only auto-upgrade for security fixes. For all others, wait between month to a year to update a dependency, unless one specifically fixes a bug you are experiencing.
[+] [-] jka|4 years ago|reply
Consumer-side: multi-party review prior to upgrades of dependencies in applications.
(note that neither of these necessarily require knowing the identity of the software author(s). in fact, perhaps reviews would be less biased in the absence of that information)
[+] [-] the42thdoctor|4 years ago|reply
Paid subscription-based NPM ? Yes, you could download a dependency directly from the repository on Github for free, but if do so through the paid NPM they assure you that the package is malware-free.
[+] [-] ugh123|4 years ago|reply
[+] [-] rosndo|4 years ago|reply
Unlikely.
> undermines the ecosystem due to the loss of trust.
Good, that trust was always misplaced. At least it’s only Russia and Belarus getting screwed instead of everybody getting hit by ransomware.
[+] [-] Gigachad|4 years ago|reply
[+] [-] rossmohax|4 years ago|reply
[+] [-] inopinatus|4 years ago|reply
[1] http://dbad-license.org/
[2] https://github.com/RIAEvangelist/node-ipc/commit/9a1ad86d17a...
[+] [-] 4oo4|4 years ago|reply
So the message they are apparently sending here is that means that it's totally OK to host malware on GitHub, given that it's targeted against a politically unpopular group of people, and if you later revert the change after it's done a bunch of damage.
Are some of those Russian developers assholes who support the Ukrainian genocide? Probably yes, but it's an extremely bad precedent to set to allow someone to use your platform for this just because it's politically fashionable.
And yes, I know that there are other things that other people might consider "malware" on GitHub under an overbroad definition of it (exploit PoCs, things like yt-dl, etc.), but this is pretty clear cut, since it hid this "feature" from users and very clearly caused destruction. Either the developer is incompetent at writing obfuscated code and the wiping functionality was a mistake (unlikely), or they are just that dishonest about what their motives actually were. Or just plain delusions of grandeur, equating cyberwarfare with peace...
Apparently though, it's all OK in this instance since it's collective punishment against the right group of people. I think the thing that makes me most angry about this is that the malware developer used the assumption that geo-ip databases are always 100% accurate...
[+] [-] tentacleuno|4 years ago|reply
EDIT: looks like Notepad++ also made a political statement about the crisis in Ukraine[2].
[0]: https://github.com/RIAEvangelist/node-ipc/issues?q=is%3Aissu... [1]: https://news.ycombinator.com/item?id=21400526 [2]: https://notepad-plus-plus.org/news/v833-make-apps-not-war/
[+] [-] jddil|4 years ago|reply
Also if you're going to delete my comments just delete my account. I'm done ignoring my industry will gladly enable dictators and pretending we are neutral. We are complicit and we need to take a stand... Or maybe we all just want to collect our fat paychecks while inventing more ways to kill people. Shrug.
[+] [-] thenerdhead|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] userbinator|4 years ago|reply
[+] [-] codedokode|4 years ago|reply
I am not sure if it could be viable business model though. People who use open source got used that it is free and are unlikely to pay.
[+] [-] rickstanley|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] SodiumMerchant0|4 years ago|reply
[deleted]
[+] [-] lizardactivist|4 years ago|reply
[deleted]
[+] [-] Artur96|4 years ago|reply