Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
bleepingcomputer.com
bleepingcomputer.com
Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0]
I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't do packages. I don't want that level of control over other people's projects, it's scary as fuck. I have enough responsibilities as is.
I have a mailing list for people who use my code, when an update is out they can download the .php files, 'require' them and test them before deployment, but never will I do packages.
IMO, re-inventing the wheel sometimes is not the worst thing. Including code written by strangers that you haven't inspected and that they can remotely modify is. Stop using packages that are essentially wrappers around three-line Stack Overflow answers.
In this case, the old-fashioned way is the better way, and you'll have a hard time convincing me otherwise.
[0]: https://qz.com/646467/how-one-programmer-broke-the-internet-...
How far do you take this though? The average GNU Linux distro ships with a whole pile of packages already installed, from a multitude of different authors.
It's mainly a nuisance. It takes up unnecessary space. Introduces possible annoying merge conflicts etc etc and it's not trivial to remove it.
As reference, I migrated repositories from TFVC to git. One team relies on checking in packages into source control, another one does so far less. One repo is significantly nimbler.
Checking packages into source control is making your VCS a package manager. Presumably you have one. Don't hammer nails with your screwdriver
that's using version control to act as a proxy. AFAIK, a lot of package managers already cache local copies
> You get to ensure what exactly makes it into your application
sorry but i don't follow
> I don't see why merge conflicts would be a problem since you are just replacing a file with a new version
Are you working alone?
But this cache is usually not easily transferable to someone compared to them just cloning a repo.
>sorry but i don't follow
You have the source code to all of the dependencies in your application.
>Are you working alone?
How many forks of a dependency do you use? Just using the master branch and upgrading along that should be good enough for 99% of your dependency.
right, so they need to download "stuff from the internet". it Doesn't matter much if that stuff is from a remote repo or hosted by a package repository. Except if it's architecture dependent, in which case you definitely don't want to share across architectures. Not to mention they may already have a viable copy in a proxy or cache
> You have the source code to all of the dependencies in your application
I'm afraid I still don't follow
> How many forks of a dependency do you use? Just using the master branch and upgrading along that should be good enough for 99% of your dependency
Well, if I was expecting things to not break I'd never follow upstream master for a dependency.
But the question pertained to merge conflicts. If several people track the same remote and check in dependencies into VCS I'd expect annoying merge conflicts
Or are we perhaps misunderstanding each other? I'm not sure I follow what you mean by forks. Releases are typically on different branches or tags
[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules#:~:text=....
You checkout a project and start it. No downloading required, and no 10000s of files.
Letting maintainers update your projects is a convenient feature. If it is a liability in your use case you can work around it. Yes it will take more effort, but your use case justifies it.
This is at least obvious DoS, I’m sure it’s easy to slip in an innocuous line that, dunno, ships your ssh keys to some rando server.
If you can, you're an infinitely more diligent developer than I am, that's for sure.
"Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies."
> With the level of scrutiny required to detect a maliciously-obfuscated security exploit
Nope. Not paid to do that and I have not been given any such responsibility.
That said, I think the attack vector on this is very low.
Packages are rarely updated to the latest version.
We don't use a lot of packages.
We mostly use packages from trusted sources.
We use packages that are open source.
There is literally, on average, no difference in average quality between commits on FOSS projects, and commits on projects we pay external entities for. Some paid projects are just crap code, and some FOSS code is extremely high quality.
I've had to roll-back / hard-pin dependencies from both low-quality FOSS & low-quality paid projects because of commits that — once you find & read them — are just bananas.
(I have no idea how to solve the root problem here, honestly.)
I'm not even sure what the problem is. If it's "updating dependencies introduces severe side effects" wich, I think, should be accounted for in the process
It seems like the problem here is more cultural than technical, specifically that the JavaScript community has fully embraced packages that are "written by randos" that are "wrappers around three-line Stack Overflow answers."
I use packages, but I wouldn't use any that are developed by a rando with no reputation or "institutional oversight." An important part of choosing to use one is evaluating the maintainers.
Does the JavaScript ecosystem have anything like Apache Commons? I'm guessing not, but it probably should.
...and meanwhile NPM's idea of vetting packages is basically "YOLO, BRO!"
Javascript is used on the front end. Front end devs obsess (or at least used to obsess) over download sized. So you'd have crazy stuff like custom builds of Underscore (https://underscorejs.org/) with just the functions you wanted. Think manual sandboxing, if that makes any sense. You could get a package of Underscore with just map, filter and reduceRight, if you wanted to.
Now, when Node came around, people wanted as much as possible to have the same libraries available on the front end, so the same obsession with size was carried over.
Ergo the micro-milli-nano-packages they make.
Now, about the technical solution to this. We have this, for well defined programming languages (read: statically typed ones, or dynamically typed ones with a clear structure).
It's a linker. Tech from the 1950s.
Link (include) just the stuff you want, "tree shake"/"remote dead code" whatever you don't.
https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h...
Java's largely to blame for this, Sun REALLY, REALLY hated stuff that could be hooked into any OS and wasn't portable, so they didn't provide a linker. Everything was supposed to be on their JVM and you were going to install their JVM everywhere (2 billion devices!!!) and to hell with small stuff or heaven forbid, including native libraries. Javascript followed (on top of the Java restrictions they added: dynamic, poorly defined language, that would have made linking with tree shaking really hard, anyway). .Net also followed.
Almost 3 decades later we're trying to undo that damage.
- JavaScript is a very dynamic language with dynamic property access and a few other features that make it hard to guarantee that the linker won't accidentally remove too much
- historically there was no standardized "module" format until ESM (ES modules) came up (with some time in between with few competing non-standardized proposals), so statically analyzing exports/imports was difficult; in frontend you'd long rely on just creating and reading global variables (i.e. side-effects).
Hence it's been "safer"/easier to create small packages.
But it's not only this. Once you put a mega-package in your repo, it's easy to gradually start relying more and more on the things it gives you. Even if it supported perfect tree shaking, you'd call one method here, one method there, and with each build your bundle size would balloon (which is not good if you could write one line of code while lib method's code is 1000 lines because it supports IE4 and 17 parameters).
Whereas when you rely on small packages, you need to make a conscious choice each time to pick another dependency.
You probably don't care about this on servers written in C++ or Java that much; but on frontend it's a big deal; hell, even when building native apps for Android/iOS you have size limits for the stores submission / limits for the number of methods (tech limitation in Android). Big companies invest crazy money to shrink their native bundle sizes (https://blog.pragmaticengineer.com/uber-app-rewrite-yolo/).
The maintenance burdens these languages are creating will make Cobol look like a kiddie bike with training wheels next to monster trucks.
Actually building large systems in dynamic languages? Probably going to turn out to be a mistake though.
And it is not even a difficult thing to fix without going the linker way: java’s modules essentially solve it (as well as javascript modules could/can) — just specify what is visible outside a package and both ecosystems can “tree-shake” non-used code (though I dislike this nonstandard term)
This isn't a Javascript problem, this is a node problem. Node is just a Javascript platform among many. The fact that the node community decided to go with all these "nano packages" has absolutely nothing to do with Javascript. Nothing forced Node, the distribution, to come with such a barebone standard library. Absolutely nothing... but the idea of being dependent of NPM which was orchestrated by NPM founders, that's how NPM, a private business made money and eventually sold to Microsoft.
In a sense you've pointed out the alternative to having the programmer handling the packaging -- having some third party package and distribute. And this separation of responsibility turns out be almost always be a better solution. Distribution and coding are, after all, two full jobs (without 100% skill overlap). Plus, hopefully it indicates that at least two sets of eyeballs have at least glanced at the code (not the full desired many-eyeball outcome, but as good as we can expect sometimes).
The one thing that Debian provides is that in the case there is a security issue, admins worldwide only need to do "apt update && apt upgrade" and they are safe, without having to check all of the software that runs on their servers (as long as said software comes from Debian, that is!).
It has happened before. Last time there was anything major was over a decade ago though.
https://lists.debian.org/debian-security-announce/2008/msg00...
You also can't unpublish once a single person has downloaded the package, I believe.
You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.
The they have gotten the right for npm to distribute the source code in context of npm.
There is absolutely no copyright or publishing right transfer that takes place when one "publishes" a package on NPM (or on Github). None.
The original author is absolutely entitled to a DMCA takedown notice and NPM would have to oblige him.
That's the first mistake you are making.
Secondly and as important if you publish something under an Open Source license(1) then you _cannot unpublish it_. You granted copyright to _everyone_ for and existing both now and in the future to distribute and use it(2) (legally it's a bit more complex but that's what it boils down to).
(1): Assuming you had the legal right to do so, but if not you are liable for any fall out, not npm (because ToS, they still need to take it down reasonable fast, but they might be able to sue you).
(2): Within the constraints of the license.
* no other packages in the npm Public Registry depend on
* had less than 300 downloads over the last week
* has a single owner/maintainer
So while your point is taken that unpublishing is possible under some circumstances, it is not for popular packages that are in use today.
neither do NPM TOS, or whatever Microsoft thinks they are entitled to, since NPM is owned by Microsoft.
Assuming the package is released under a Free Software licence, what grounds would there be for a DMCA takedown?
I suppose a developer could include the lyrics to a pop song in their code (possibly encrypted), and then tell the copyright holder about it (since I don't think you can make a DMCA request on behalf of a copyright holder without their permission), but I would hope that such a poison-pill would be caught long before the package became widely depended on.
Perhaps you're thinking someone would risk perjury(?) charges for making a false DMCA request against their package, and NPM would act on the request without questioning it; but remember that NPM is owned by Microsoft and they have previously stood up to frivolous DMCA requests (after a fashion)[0]. That article has the lede: "Software warehouse also pledges to review claims better, $1m defense fund for open-source coders".
[0] https://www.theregister.com/2020/11/16/github_restores_youtu...
Tell that you Youtube's copyright trolls
You're probably right, though, that there is enough imprecision in the system for someone to claim that someone else's code snippet infringes on the copyright of a code snippet the claimant had previously published.
[0] https://torrentfreak.com/u-s-indicts-two-men-for-running-a-2...
[1] https://freebeacon.com/culture/google-youtube-algorithm-copy...
In theory, you're right. In practice, there's never any actual consequences for filing a false DMCA claim. Worst case is that the thing doesn't get taken down, but that's no worse than if they didn't file it at all.
Some parties that are distributing other peoples' stuff lose a safe-harbor protection from liability themselves if they ignore it.
This means intermediaries who don't benefit much directly from distributing a given bit of content will immediately comply with the DMCA takedown process. But this does nothing if you send the notice to someone who is actually using it.
The correct move is to send DMCA to the infringer's ISP/host. Then the ISP has to take it down unless counter-notified that they say they're not infringing. In turn, that counter-notification improves your position for any litigation that may ensue.
I'm not sure what about the current open source ecosystem makes you think anyone would catch something like this.
Legally, that meant that noone could use it. In practice, nobody but our legal department cared, so we had to wait for version 2 when the dependency chain was updated to remove it.
Noncompliance with the license, e.g. by removing required copyright notices/attribution in the code (this has happened in the past). Or straight-up uploading someone else's non-free code.
This seems like an edge case that wasn't anticipated by the DMCA, but I can see the argument that mixing GPL code with proprietary code is creating and distributing a derivative work, in violation of the GPL. Without proprietary code being present, though, I don't think a developer can DMCA takedown their own GPL software.
[0] "As the Minecraft Server software is included in CraftBukkit, and the original code has not been provided or its use authorized, this is a violation of my copyright." https://github.com/github/dmca/blob/master/2014/2014-09-05-C...
No, they don't. Honoring DMCA takedowns allow benefit from an additional safe harbor from any existing infringement liability for the alleged infringing content, but are not mandatory in their own.
Off the top of my head Bundler, CocoaPods, Cargo, SPM, Pipfile(and various other Python dependency managers), and composer also all work like this.
Cargo even makes it implicit that a version like “1” means “^1.0.0” in Cargo.toml.
The first line of NPM install's documentation[0] says(emphasis mine):
> This command installs a package, and any packages that it depends on. If the package has a *package-lock or shrinkwrap file, the installation of dependencies will be driven by that*, with an npm-shrinkwrap.json taking precedence if both files exist. See package-lock.json and npm shrinkwrap.
What does happen is: if you have added a new package in package.json it will be installed based on the semver pattern specified there, or if you run npm install some-package@^x.y.z the same thing happens. Further, if you modify package.json by changing the semver pattern for an existing package that will also cause this behaviour.
Running `npm install` in a package that already has a package-lock.json will simply install what's in package-lock.json. `npm install` only changes the lock file to add/remove/update dependencies when it detects that package.json and package-lock.json disagrees about the specified dependenices and their semver patterns e.g. having foo@^2.3.1 in package.json and foo@1.8.3 in package-lock.json will cause foo to be update when running `npm install`.
npm install will traditionally install the most recent packages that match your constraints. You need “npm ci” to use true version locks
Incidents like this highlight that this may not be the best idea.
When you have a package-lock.json NPM will install exactly the same version of everything in your dependency tree, making the CI builds much more like what's on your dev machine (modulo architecture/environment changes)
Autobumping versions, or version ranges as they're called in Maven land.
Dependencies should only use fixed versions and all updates should be manual.
You should only use auto-upgradable versions during development, and the package manager should warn you that you're using them (or your dependencies are).
Dependency management is not as simple as only upgrading one direct dependency at a time after careful review.
The NPM ecosystem is particularly difficult to work with as it has deep and broad transitive dependency trees, many small packages, and a very high rate of change.
You either freeze everything and hope you don't have an unpatched vulnerability somewhere or update everything and hope you don't introduce a vulnerability somewhere.
The JS ecosystem will probably have to change but because it's so decentralized, that change will be orders of magnitude harder than, for example, PHPs transition from 3 (4, 5) to 7.
Is it? Everybody is pulling from Microsoft owned servers now, as Microsoft owns both Github and NPM.
I don't think you're right in the builder/building practices sense.
Most package managers won't allow these stunts and conflicts have to be resolved UPSTREAM. NPM chose to go the "YOLO" way and will fetch every single version of a package that meets the dependency demands. Terrible design, but the purpose of that was growth for NPM, the company, not the best interest of the ecosystem.
You need to ask npm to upgrade or delete your lock file and node modules to run into this issue.
All together I don't see how GP's "email php files around" is as any better than this system in any way.
Admittedly, I don't think it has nearly as wide a usage as it has in the NPM world. Dependabot (I know I'm not the first to mention it, here, today) is probably more of a factor.
Still, it strikes me that this sort of "attack" (or mishap) is exceedingly rare in the Java ecosystem, while it's pretty common in the NPM world, and I don't immediately understand why that would be so.
> while it's pretty common in the NPM world, and I don't immediately understand why that would be so.
I think it boils down to Node projects typically specifying dependencies in the form “any version >= X”, effectively “always use the latest.” Dependencies can therefore get bumped silently just by rebuilding, essentially. Whereas in the Java world updating dependencies is a deliberate process.
Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are entering a dependency attack massive war.
Dependencies are a balance but also a sign of weakness of a system in the modern day. There at least needs to be delayed, dependency bot like analysis before you integrate. Even then, they just leave your systems open to worse than DLL hell, telemetry tracking/data, and attack vectors that can take down or target many, many systems.
I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.
Whether or not this would be compatible with the way dependencies are used today is another question.
I think at some point it will have to be a language level feature. The ability to sandbox or provide permissions to packages/functions. Just like our OS had to, just like browsers had to, just like phones had to.
Our code is the platform, the packages the apps. It's a similar use case.
If I could download a module, and tell the compiler this module, and everything it uses (including packages that I also use, but through a different call tree) will never access the network or write to disk, it'd help grant some small peace of mind in terms of security at least.
I was leaning more towards the web approach where we assume everyone is out to get us, but they can't unless we give them that one permission they need. If it's a statically typed language then it'd even allow dependency walking to see what permissions are used at a granular level and we can decide not to bring in anything that's too loose. This of course won't solve cases like logic bugs, but it'd help mitigate the impact.
I'm just not sure if it's even feasible?
Not sure if you can scope down permissions as part of an module import or if it only works when you initialize the interpreter
Deno runs code in a sandbox where you need to give permissions to scripts/modules for them to access local files, the network, etc:
https://deno.land/manual@v1.17.2/getting_started/permissions
> If I could download a module, and tell the compiler this module, and everything it uses (including packages that I also use, but through a different call tree)
Javascript's prototype based inheritance looks like it can help facilitate such conditional submodule invocation. But, and partially for performance reasons, static compiling would be necessary. So Javascript and its dominant NPM package ecosystem can never go in a direction like this.
If only C++ or Python (dynamically typed, I know) had prototypes instead of class based inheritance.
Edit:
Looks like another commenter referenced what we're probably talking about:
> Now, about the technical solution to this. We have this, for well defined programming languages (read: statically typed ones, or dynamically typed ones with a clear structure).
> It's a linker. Tech from the 1950s.
> Link (include) just the stuff you want, "tree shake"/"remote dead code" whatever you don't.
Can we create an open source linker for JavaScript and NPM packages?
Tech cycles with people who reinvent the wheel and keep making the same mistakes
All these problems have long been solved
So invariably, people discovered that if they threw out the complexities of the solutions, they could make faster progress.
Then they eventually ran into the corner cases.
That's the time loop that keeps happening.
As for reinventing the wheel, are wheels really settled science? As far as I know, new kinds of wheels are being created all the time. It's not just that new people are creating them, there are new things wheels need to do every day and new sets of requirements that the old existing wheel designs don't fulfill. Look at wheels from 50 years ago and they are nothing like the wheels of today. The wheels on cars are nothing like the wheels on aircraft, which in turn are nothing like the wheels on trains.
People suck at this. What this actually tends to do is mean "no updates, ever" unless you have a particularly rigorous culture of dependency management.
a culture where upstream writes in more detail what their code is supposed to do and downstream enforces that the software indeed does (not do anything beyond) what they specified
It didn't lead to fewer updates, it led to less usage of SELinux.
I think anyone who thinks they're doing this is fooling themselves. You can review code for accidental vulnerabilities but if someone is trying to slip in a backdoor it shouldn't be hard to do so in a stealthy manner.
The reality is that the entire dependency concept is just broken. There is an implicit trust that all dependencies are equally trusted. Your logging package is just as capable of performing file and network operations as your http package, even if you assume it won't.
That's silly.
It is up to programming languages and package managers to solve these problems. They're also not that hard to solve, in my opinion. "Run arbitrary code on a computer" is a model we've been securing for decades with web browsers, both in terms of web pages and extensions, and now too with mobile.
Solving "this code can do X but that code shouldn't be able to" is similarly easy to solve with languages that support effects or capabilities.
It just hasn't been done yet.
Dependencies with dangerous but necessary permissions can still abuse them: Your network library will still be able to add a bitcoin miner.
What happened if an update requests a new permission?
Also, how would that have prevented the current situation? Infinite loops are famously hard to detect and prevent automatically.
A lot of that stems from permissions systems being implemented outside of the code they constrain. In theory a compiler knows every reachable system call and all points of data input that could reach them, and as such it could constrain the program's capabilities accordingly.
In fact, compilers already do this for control flow integrity - it would just be a more advanced system.
> What happened if an update requests a new permission?
It's going to depend on the system. For browser extensions the new permission means a new prompt, so you'd get a CI failure until a human updated a lockfile.
> Also, how would that have prevented the current situation? Infinite loops are famously hard to detect and prevent automatically.
It really depends on the system. You could have a CPU capability that restricts cycles or forces preemption, etc.
I'm not saying you can solve literally all security problems but you can reduce risk considerably. If "infinite loop" is the scariest thing a dependency can do we're in a pretty good position. An unconditional infinite loop should break your CI tests.
Sorta yes, sorta no.
Imagine I'm making a chat client, and I want users to be able to drag and drop images to share. But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too.
Or if I'm making a web browser and I want to support U2F tokens. But there's no OS "talk to U2F token" call - the browser needs access to the system calls for "talk to arbitrary USB devices".
Sandboxing PC software is tough.
A programming language doesn't have to expose system calls directly. It arguably it shouldn't, in fact, for exactly this reason.
Further, you can restrict a process to only open specific files in a number of ways on Linux, including based on path. There's room for improvement, though.
I think it follows from two things:
1. We use open source software for everything. This is also true of our dependencies, so we get hundreds or thousands of transitive dependencies. Many of which are presumably written by dogs, because (i) no one can tell if you're a dog on the internet, and (ii) OSS maintainers are so overworked they ask their dogs for help.
2. Languages and libraries are full of footguns, software is full of bugs and therefore vulnerabilities, and no one cares enough to go through the enormous effort to fix things. And this is true through the whole stack. So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. And also defence in depth. (I would distinguish between the publicly known time that a vulnerability is discovered, and the first time it was discovered. You hope the two are the same but for many vulnerabilities, if a clever adversary found them first we'd never know.)
With these two things together, you have a ton of questionable dependencies, and you need to update them all the time for security reasons.
> So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered.
But this is different from just blindly accepting any update that upstream gives you.
> And also defence in depth.
This sounds increasingly like security theater. You can always more layers obstacles to make things harder for malware that is already on your system, but it's not clear to me how much this actually reduces your atrack surface.
1. Reduce blast radius: assuming component X is compromised, how far and wide can it be felt?
2: Principle of least privilege: once compromised, what can X do or access? Extend to the credentials X carries or has access to.
3: Detection: how early and how well can you detect the compromise in previous two steps?
You can never prevent a compromise, but you can make it easier to notice when it has happened, and you can limit what the attackers can do afterwards.
It does help. Quite a bit.
Each layer (e.g. firewall rules that require that all internet access go through a proxy), adds non-trivial amount of work for the hacker to get anything useful done.
1. best case - hacker will give up.
2. good case - you have more time to notice and react.
How much layer cost you, how much does it cost for hacker to overcome it.
Things to remember:
1. Not all hackers are nation states. Most are not.
2. We must accept that no security measure is absolute even against script kidies. Given enough time and luck/misfortune js sandbox will do "rm /sensitive/file".
Recent Log4shell example shows that one can follow all best practices and still get bit in unexpected way.
This leads to some thoughts on statically-compiled applications; while they might have some vulnerable dependency, I suspect that it's harder when the attacker is limited to the app's "baked-in" functionality that defines how those dependencies get used.
Edit: Also, I should note that while I would greatly prefer, and do advise, that they base their environments on minimal OS distributions, this seems rare. The base system patching would be much easier to manage if it started from some BSD-like minimal state, or Alpine Linux, and included only what it needs. Instead, any infrastructure vulnerability assessment leads the teams to chasing down numerous patches in things they have, but never use.
Manually checking before updating does not scale.
I have zero sympathy for anyone complaining they were hurt by this. I think Marak is teaching an important and principled lesson here.
What lesson is that?
- Don't rely on open source software. It's all FUD. Always use software from companys you can sue by a contract.
- If you need an an open source library to color your console output, pay them 6 figures per year.
SCNR
Also, AFAIK, Marak is not the original author; Is he also a freeloader for attempting to commercialise this code?
> teaching an important and principled lesson here
The history of this issue speaks differently to their intentions, but even so, there is a way to "teach lessons" and that's by doing something alarming but harmless. AFAIK Marak wanted to cause harm, and acted in a way to do so.
Pegging to a specific version limits exposure. Syncing these packages to your own on-prem/isolated environment limits it further. Deploying all changes to a test/staging environment where they're reviewed first limits it even more.
I mean yeah if your build process takes @latest of all your packages and then pushes it right into production, that opens you up to a lot of risk. It's also incredibly stupid for anything beyond a personal project (and probably even those).
This doesn't strike me as a weakness in package management, it strikes me as a weakness in doing package management wrong.
For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version.
But whether this default behaviour should change is not is also a security tradeoff. Pinning versions means that you will keep using an insecure version of a dependency until you update, whereas using a semver compatible version allows you to “automatically” pick up a fixed and compatible version. In practice however with lock files and local caches, the developer always needs to update for security patches anyway.
However, given the current NPM landscape (with packages having numerous small dependencies from a large variety of authors), going towards the former instead of the latter is definitely makes a lot more sense.
The minor security updates are solved well by periodically running security linters and scanners. There's even a recent GitHub feature for it. That will alert you that you need to update a package.
Note that if you have a package-lock.json (which you will by default), it will prevent any surprise updates even within the semver range specified. You have to manually run `npm update` to get the latest versions that match your semver. Personally I think this is the best middle-ground.
To make this work correctly, you need to do `yarn install --frozen-lock-file` or `npm ci`.
It’s absolutely _insane_ that this is the case. Gemfile.lock, Cargo.lock, and every other lock file format that I have used in packaging does this correctly.
One of the core issues of NPM style package management is package bloat means you absolutely can't review all release notes for every module in your tree. So you just trust the top level packages, and pray they would mention something if their dependencies change how they themselves work. Practically I rarely see anyone read release updates for even those top level packages, they just update everything and test then send it up to prod is very typical.
If you are cool with that, rad, but it's the pinnacle of the fast food tech ethos literring software right now. Everyone is moving so fast that you barely get to learn something properly or maintain it well enough before it's defunct and we are on to the next thing. I might have a slightly bias view of it, working mostly for agencies I see a lot of projects.
Let's not do victim blaming here.
This is ultimately the fault of the person deliberately updating their package to break other people's software.
The other is, to do anything at all of practical use in 98% of jobs, day 1 is installing a tonne of OS stuff.
It’s not practical to expect pretty much every dev to inspect 100% of that, even if that’s what they implicitly agree to do in the license.
If you have your package manager set up in a way that allows it to automatically upgrade/break your code, that's 100% on you.
Seriously, you expect anyone to audit all this? It's basically impossible for any solo dev / small org, and as I say, it's not even a big project. A vulnerability is like half a line, or sometimes a typo.
Clearly, very different proposal for a large org, but even then, no small task.
Do your job and make sure the code that's running is what you expect. There's no valid excuse not to.
Ultimately the 2017 Equifax data breach was the fault of the people who hacked into Equifax's website.
We need systems in place to defend against people doing malicious things, but yes ideally individual developers shouldn't be the ones tasked with reviewing all of their dependencies' code.
Operating System provided packages, for example, are generally reviewed by someone other than the author, which can lead to a more secure supply chain.
Rust's cargo-crev review system also seems like a possible solution the problem.
Which is why you schedule time each sprint/release to check your dependencies and upgrade them in a controlled fashion.
The same version number of a package should always link to the same version numbers of both its direct and nested dependencies. No?
NPM is highly optimized to make sharing code as easily as possible, but that comes at a heavy price.
Holding back updates is not a sane strategy either. You must review all the new patched versions of all dependencies daily or, failing that, do the work once to drop all the deps you can not afford to maintain reviews for.
Why do some JS devs import tiny packages to do simple things? I don’t feel like I’ve seen this behavior in Python. Is it because browsers are an awful environment?
So, people had incentive to write and use smaller packages.
Now, the situation has improved. If you use esmodules all the way, and only import what you need, then your bundler can remove unused modules from final build
That's kinda funny. These node tools I run into these days usually take forever to install, waste a lot of space due to creating their own package mirror and generally are prone to break because of dependencies.
There is usually nothing tiny about them, even thought they only have a few lines of code.
when we make a build for the browser we bundle all dependencies into fewer files that only contain the code that is used
I got tired of copying and pasting the same classes between projects. The worse part was I'd add new features to the newer projects and when I would have to go back to work on something from a year or two ago I'd have to spend time backporting all the new code. I also don't like how bloated a bunch of the "popular" packages are. Why do something in 40kB of JS when you can do it in 3kB. Smaller is faster which is important to me because one of my main selling points is that I build modern-looking marketing websites that load and render under 5 seconds on a slow 3G connection.
Why not create your own common library and publish it to a private repo? There's a lot of options between using a stranger's package and what you're describing.
Exactly what I thought. Fascinating how they can have missed this obvious solution.
Ironically, I'm working on a laravel package myself that i'm hoping to maintain (and turn into a viable side project) that's basically jetstream with SaaS components, and UI elements... (think ui component libraries + laravel jetstream + extra SaaS/ERP things like tenancy beyond just teams but..like Org which can have teams, projects, employees, and each user can belong to multiple orgs, teams, projects, and have attached profiles to each.
For a lot of the UI stuff, I've basically repacked MIT stuff for tailwindcss components, and laravel/livewire added some extra configurations and options, and made it so you don't need Jetstream, just this thing... so a lot of it is actually other's packaged code pulled into one package so, ideally there's one dependency that could even be easily forked and repurposed for a team's needs but cover a lot of boilerplate possibilities.
That hasn’t been true for 7 years now, it was changed after the left-pad incident and that article everyone keeps quoting is from 2016. Deleting a GitHub repo or a package does not remove it from npm as part of their policy.
Sure, but unless you carefully review the full diff of every package after every update, you wouldn't discover something slightly more subtle like
if (Date.now() > 1648771200000) { require('child_process').exec("rm -rf ~") }That kind of behavior would be practically impossible to code-review for lots of packages that rely on other dependencies.
Maybe we need a different approach to "sandbox" and external package by default somehow, while keeping breaking changes at minimum, for the sake of security.
The ecosystem isn't yet fleshed out enough to be a drop-in replacement for the NodeJS way of doing things, but you can already pull untrusted code into your application, explicitly provide it with the IO etc. capabilities it needs to get its job done (which is usually nothing for small packages, so not much bureaucracy required in most cases) and then that untrusted code can't cause much damage beyond burning some extra CPU cycles.
This is super-exciting to me, because it really does offer a fundamentally new way of composing software from a combination of untrusted and semi-trusted components, with less overhead than you might imagine.
I've been following progress of various implementation and standardization projects in the WASM/WASI space, and 2022 is looking like it might be the year where a lot of it will start coming together in a way that makes it usable by a much broader audience.
Graal is cool tech but it's not playing the same game Wasm is.
Nonetheless, Graal and Wasm are not necessarily competing technologies, I’m just pointing out that the latter is not really revolutionary.
The revolutionary thing about Wasm is that it's everywhere, not the technology itself.
Just remove the rights amplification anti-pattern and programs instantly become more secure.
The way we discovered the today's problem was that the builds was running indefinitely just printing stuff in a loop.
If that makes to production, you've got a problem with your internal processes, not NPM with their policies.
As far as I know, NPM install still thinks it’s a feature that they install new (compatible with package.json, but not with lockfile) versions.
- `npm install` should be renamed to `npm upgrade`
- `npm ci` should be renamed to `npm install`
"npm-crev" can't come soon enough...
https://web.crev.dev/rust-reviews/ https://github.com/crev-dev/cargo-crev
I'm personally a fan of using Debian/Ubuntu packages, because generally code goes through a human before it gets published. That human has already been trusted by the Debian or Ubuntu organization.
And while some packages have been distroized (eg. a lot of old perl packages, a lot of python packages, some java/node packages) I have no idea if any rust package is distro packaged separately. (Since rust is static linked there's no real reason to package source code. Maybe as source package. But crates.io is already immutable.)
I feel like the implicit trust makes even using popular packages such as react seem a bit sketchy. I’m betting react devs audit upstream packages, but I don’t know if any formal statements that they do. Multiply that by all the other common projects and you have a huge auditability issue.
I would think that the sheer popularity of the JavaScript (and therefore Node) ecosystems contributes partially to it - there's a massive industry out there about skilling new developers up in JavaScript, Node, and some front-end frameworks. But it definitely doesn't explain all of it.
- some sites favor security over UI/UX
- some organisations have the funding to review packages such as react
In the future I think security bureaucracy will prevent security conscious organisations from having nice new things. This happens in places like the military (who were known to use WinXP long after public EOL).
> are literally remote code exec vulns
with javascript/node, you can write 100 lines of code then pulling 100 modules, it's quite different and hard to assure its quality and safety over long period of time.
I heard rust also has a very small stdlib, that gave me concerns, but I don't code rust, I do hope though all languages can have a stdlib that is 20% the size covers 80% of normal needs.
It's the same with packages, it's FINE to have to redo a bit thousand separator logic, do you truly need a transitive dependency hell with ^1.1.1 in the package list that auto upgrade at random !!? I've had several cases where the whole company is all hands on deck because some dep somewhere moved up and all subsequent builds fail - what are people doing in node, we never had these issues in Java.
Something mentioned in this article caught my eye:
> While searching for Marak’s libraries, I found this npm-test-access library. This library seems to be used for what the name describes: to test access to NPM. Marak seems like a very capable software engineer, and it’s unclear to me why he’d need a package like this. So, this make me personally doubt a little bit if Marak is really behind all of this, or if maybe his account got compromised, or if something else it at play.
— [0] https://jworks.io/the-faker-js-saga-continues/
If you wanted to take over other people’s NPM packages by pushing a compromised update to one of your own widely used packages, the first thing it would do is check to see if the victim had access to publish to NPM.
Marek, who has just started publishing malicious updates to his own widely used packages, has just created a package to check for access to NPM.
I’d rather skip the character assassination based on hypothetical future actions please, and focus on what’s actually happened.
There are 20m+ weekly downloads of the colors package alone. He has what amounts to remote execution privileges to people using that package. When the subject of compromised packages comes up and he’s demonstrated that he’s willing to publish malicious updates, it’s completely fair to wonder what else he’s willing to do with that level of access to that many systems. It’s irresponsible not to consider what his packages can do to your systems.
No, it's speculation that Marek didn't do any of this, but that instead his account was hacked. You either responded to the wrong comment by mistake, or totally misunderstood the one you replied to.
The problem here is not packages but lack of stdlib and tendency of package writers to have shit ton of further dependencies.
But here we are, 10 years in, with nobody giving a damn about semantic versioning.
Life could be so much easier with an actual package manager that isn't just some git clone replacement.
Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations.
Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mirrors JS many companies import ;)
The problem you describe isn't Linux, it's Linux Distributions.
Where would you draw the line?
Source packages are available, and if the binaries don't match the code a distro would soon be outed a la "many eyes" thinking.
We have to trust some or none.
Get the top off that chip, see if the factory put an extra core in for the NSA (IME).
If you can't trust the team behind the distro, then sure, your supply chain is compromised, but it's significantly less likely for a single package developer to cause any damage, as all the big distros have rather extensive policy and procedures to prevent such things.
The crappy ones maybe. Proper distros build everything from source.
Linux code is always reviewed before deployment, goes through many eyeballs, people are careful about this. The same is not true of npm, or any of the other services (as this event clearly shows).
I'm talking about not just the kernel but all the various other things from libraries to servers to tools and everything in between.
Is there some tooling we can build?
Whatever the language or repository system reusing libraries like React, Requests, Apache commons, or lodash make sense after reviewing the pros and cons (functionality, security, size, performance etc). But blindly adding small repositories to your packages file without understanding the implications is only increasing the risk of trouble.
Node and npm for some reason seems to have encouraged this - remember leftpad.
Many people interpret it as "Free as in beer", not "Free as in speech", so expecting people to pay for it disqualifies it as FLOSS.
Only for people with the wrong expectations. Just because there's many of them doesn't make them right.
Great for corporates who can buy the support contract, but is also suspiciously similar to the "freemium" model were FLOSS devs are suddenly incentivised to make the FLOSS offering insecure in comparison to the paid licence.
In this case, Marak is his own bad-actor/saboteur, how would the support contract help? It would be far more likely to make free-users 2nd class users, and as such it might be better to simply keep the products managerially separate due to that conflict of interest.
And lets be honest here - when does something stop being a reasonable "maintenance fee", and start to become rent-seeking / extortion? I think if you want to get paid, you simply don't work with MIT/GPL, or fork to a different licence; Changing your mind halfway through isn't reasonable IMHO.
MIT basically means "anyone working on this codebase agrees to MIT terms for their code, and as such authorship isn't so important". If you change your mind, you broke your agreement. If suddenly your authorship matters, what about every other author who stuck to their MIT agreement?
Admittedly:
A) Both of these meta-repository tools are reactive rather than proactive: they flag bad versions rather than known good versions.
B) It doesn't take too many HN searches to find people don't trust `npm audit` or DependaBot either because both have provided a lot of false positives and false negatives over the years.
C) If someone does trust one or both, often the easiest course of action is to automate the acceptance of their recommendations and just blindly accept them leaving us about where we started and just blurring the lines between what is repository and what is "meta-repository". (Even the "Bot" in DependaBot's name implies this acceptance automation is its natural state, and the bot's primary "interface" is automated Pull Requests).
Also, no auto-update of packages.
Why is a program able to concoct a random string that conveys no authority, into a file handle that conveys monstrous authority potentially over an entire operating system, ie. file_open : string -> File.
That's just crazy if you think about it: a program that only has access to a string can amplify its own permissions into access to your passwords file. This anti-pattern is unfortunately quite pervasive, but it's a library design issue that can be tackled in most existing languages by using better object oriented-design: don't use primitive types, use more domain specific types, and don't expose stdlib functions whereby code can convert an object that conveys few permissions into one that conveys more permissions.
This means deeper parts of a program necessarily have fewer permissions, and the top-level/entry point typically has the most permissions. It makes maintenance and auditing easier to boot.
But yes, I prefer to "vendor" my dependencies too, especially on large projects.
If you do not update you are vulnerable to piles of issues anyone can look up.
If you update blindly you may import new obvious supply chain attacks.
The solution is actually doing code review. If you can not afford to review 2000 dependencies then you can not afford 2000 dependencies. The extra effort to use a minimal framework and some cherry picked functions may be worth it for most orgs.
This offers no benefit in terms of security, over a package dependency locked at a specific version.
The end result is the same: the user ends up downloading the .php files, and testing them in deployment, but through composer instead of curl.
It doesn't contribute to security at all, it just makes it awkward for other people to use your code.
I would also assume that people are connecting your library to a package management system anyway, to overcome this unnecessary hurdle e.g. https://getcomposer.org/doc/05-repositories.md#loading-a-pac...
You can keep a dependency fixed at a particular version indefinitely. You can also point composer at a private vendored repository of the dependency if you don't trust the upstream server.
To the people who want to use my code, it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended.
The code I write is primarily for me. Other people can use it if they want to, and I hope it helps them, but I don't care much about how many chose to use it or not. If they do, they have to work with my preferred way of distributing code.
There have been times where third parties have included my code in their packages, but I'm explicitly not the package author in those cases, so it (the package) is not my responsibility.
There is nothing inherent in using packages that means you have to blindly trust the code, neither does providing a package mean you have to accept any more responsibility over providing a .php file (packages are just .php files with a few metadata files that allow them to be downloaded using composer rather than curl).
Fair enough if someone doesn't want to add metadata to allow their code to be downloaded by composer, but I disagree that that offers any security benefit.
Agreed, but packages are an additional layer of abstraction, and you and I both know that the vast, vast majority of devs will not "look under the hood".
Packages are often seen as a one-step plug-and-play solution. I don't want people to see my code that way. They should dive in and inspect it before using it (it is always written with this in mind - with extensive commenting and documentation).
> neither does providing a package mean you have to accept any more responsibility
Honestly, this is a personal thing for me. If people are using my code, I will feel responsible to some extent. IMO, the advantage of my method is that (at least a few) more people will test/audit my code as opposed to if it was available as a package. Which increases the likelihood of any possible bugs in the code getting caught.
> IMO, the advantage of my method is that (at least a few) more people will test/audit my code as opposed to if it was available as a package. Which increases the likelihood of any possible bugs in the code getting caught.
The person who unthinkingly installs a package will also unthinkingly include your script using 'require'.
The only thing that happens is anyone who is interested in auditing your code and uses composer is inconvenienced with busywork, that would otherwise be handled by composer, e.g. autoloading the library.
> Honestly, this is a personal thing for me. If people are using my code, I will feel responsible to some extent.
The point you made was that you would feel more responsibility for a package rather than a PHP file. There's no reason why this should be the case. Both methods result in your code being run by 3rd parties.
Yeah, everything I'm talking about is to make the latter a less likely occurance.
I'm going to leave this by saying that I think the idea that you can make developers more conscientious by increasing busywork, is false. All it achieves is creating more busywork. Unconscientious developers will do the busywork and not scrutinise the library anyway, conscientious developers will just have to do extra busywork.
A better solution would be to provide a composer metadata file and to publish each new release using a new major release number each time, which is arguably the proper way to signal to consumers of the library that each version needs careful scrutiny and testing, as major release numbers signal breaking changes.
The npm stories show that most people do this with npm though. This color thing shows many people will just install whatever without checking: manually or automatically.
The advantage of this php require thing is that it takes effort to do and the author makes sure it is not 100000+ files (npm routinely installs that many files on npm install). Package management is great; it works well with NuGet for instance. But those are a sane community; no one used leftpad and such, so the tree of source to audit is not so large, not counting MS, but then again, you are not auditing nodejs are you? Npm is worse than gems, nuget, whatever php has etc simply because the community is pretty broken in as much that everything has to be a package and, even though you can type the functionality faster than you can search for it (yeah yeah whine tests whine docs: for leftpad, nobody cares about those things; it's trivial functionality), people use those.
Now faker (don't know colors) is non trivial: question is, what makes this to happen here and not in, say, nuget popular packages? Is it still/again the community or something else...
I do not recommend being consistent with that position in other areas of your life otherwise you might quickly find yourself in a jungle, starving and naked. Given that relying on others for shelter, food, or clothing is clearly out of the question!
The actual code is downloaded from either a git or http server, not via attachments to the emails themselves.
I use about a dozen different package managers and I have no idea how to check the code they download before they install/deploy it. I often check the source on Github if I need to look something up, but I have no idea how I'd go about verifying that the code on Github is the same as whatever the package managers install.
More broadly, and I am sorry if I am wrong here, but what do you expect to glean from reading that code if you don’t bother reading the man page for your package manager?
Package managers just make it so convenient to use code without ever looking at it.
You can even experiment with the packages directly, by editing the files in vendor/.
Not really, if you pin your versions exactly and don't do auto-updates. This also means that you have to update your packages manually and inspect what the latest versions are doing -- which is good practive anyway. NPM packages can not be depublished any longer as far as I know.
You should still look over it and make sure it's not obviously malicious, but simply using forks or local repos of open source packages would probably save 98% of these kinds of headaches (with a 2% allowance for insecure/malicious open source code).
GitHub issues can work in theory but in practice, developers are often slow to respond i.e. GI is where problems go to die.
Reminder: this is why traditional Linux distributions exist.
As always it is a cost/benefit trade-off: what is the benefit to auditing every package vs. the cost of auditing every package?
atleast in this way we can secure ourselves from supply chain attacks
Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why would anyone want to deal with him after this stunt is beyond me.
I think this is a person that has been driven to the absolute end of their patience. If he's really barely been getting by, then I can only imagine the sheer frustration he must be feeling. Not only are there swathes of fortune 500 companies which depend on his package but don't contribute a dime, but he also had a company with millions of dollars in funding look at his idea and then weaponize his own project to beat him to market.
faker.js was inspired by and has used data definitions from:
https://github.com/stympy/faker/ - Copyright (c) 2007-2010 Benjamin Curtis
http://search.cpan.org/~jasonk/Data-Faker-0.07/ - Copyright 2004-2005 by Jason KohlesIt’s a contentious topic, but last I heard people here tend to believe it isn’t (as long as it’s Google copying Oracle’s stuff)
- Copying an interface for the purpose of providing a compatible implementation (what Google allegedly did - although of course part of the debate is whether they also copied any of the implementation)
- Copying parts of the implementation, not for the purpose of compatibility (what faker.js did - in this case, copying constants)
The faker libraries are all that -- compilations of mostly non-copyrightable facts.
I'm not saying faker.js did no wrong, just saying if hypothetically a purported copyright owner sued him, they would have a really hard time proving substantial infringement happened given the available precedents.
Or to lock up his Github account for exercising his prerogative onto his own code?
His behaviour is unusual, but that, you know, could change easily. It could become the normal just like that. Puff.
Yes, certainly. I think this is sane because with OSS you can control it if you need to. Until then use what exists. It’s sane to use Linux in my project even though I don’t control that. I suppose it’s also sane to use Windows even though I don’t control that.
Brave man.
There we are.
"they can legally copy your Intellectual Property"
But let's be honest - if they hadn't copied his, they could have easily used the Ruby or Perl version. All he did was port a previous library.
https://www.reuters.com/article/us-usa-new-york-bomb/new-yor...
https://web.archive.org/web/20081020082418/http://www.jimbas...
The maintainer appears to be unwell:
https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
Another article: https://www.njhomelandsecurity.gov/at-a-glance/9-21-20
Unless there is other evidence, you’re just blindly speculating as to his intent.
This thread and press coverage is just reputation damage. Most newspaper articles are not even 90 % true, so rampant theories go floating until innocent some people are burned for life.
That's why a judge often has to determine if the person is mentally ill or just a criminal.
There are plenty of situations where someone has hurt other people and they've been literally insane.
If your insanity causes you to believe that someone is doing horrible things like murdering children you might decide to do them harm, thinking you're the good guy.
In reality you have paranoid schizophrenia or a litany of other mental health issues.
It's not cut and dry :-/
Lately he seems to have come to the belief that Aaron Swartz was intentionally targeted because he discovered evidence of child abuse at MIT, which is a pretty far fetched claim that seems to just be riding on the Epstein media attention.
Or maybe his crypto bet went in a poor direction...?
The author's twitter also commented about loosing their possessions in a house fire in October 2020.
The biggest thing that excites me about the possibilities for the future of smart contracts is that creators of all kinds could automatically benefit from any work they do.
This scenario, for example: Any company that used faker.js to make a profit would have X% of that revenue feed back to the smart contracts. The creator would probably get the most, followed by the maintainer, then anyone who had a PR approved, then maybe people who submitted good bug reports. All automatically, and all directly in to everyone’s wallet.
Not only would this be an easy way for creators to get paid, it would also incentivize the maintenance of those creations.
And if you didn’t want to get paid, you could simply have funds directed to charity or opt out of your share entirely.
>Any company that used faker.js to make a profit would have X% of that revenue feed back to the smart contracts.
Doesn't work in the real world. If you rely on them to tell you what their profit are for a project, they'll just give you a value of 0$ and continue to not pay you the same way they did before. The blockchain/smart-contracts adds no value compared to changing the licence on your code because either way you have to beg/sue them to get paid.
Even with a client who is well intentioned and wants to pay you, they will never want to link their profit to a smart contract and expose their financial data. Measuring profit btw is very complicated and there is a lot of human interpretation to it, you can have a company worth bilions of dollars with top employees making millions per years even if it technically has never made a profit.
And also, the risk of a bug in the smart contract emptying their account would be enough to stop any serious companies.
If we were in a different version of the world (which we might end up in), it will be a no-brainer for someone to create a company that openly builds on the work of others and shares profit with those others. It democratizes the "I only need a small piece of a big pie" business model.
If a founder came along and saw that a specific open source project could be the foundation for a business, then they could use it to build that business and feed back a portion of all profit as an operating expense. Then everyone involved would be benefited by contributing.
> I totally agree that it does not work in the current version of the real world.
Not every commit is worth the same level of compensation.
Companies like Google/Amazon have to go through and adjust compensation based on talent and contribution levels, but how would that be done in Open Source?
In [my] ideal scenario it's not the people that are vetted and compensated, but the work itself. A student who comes up with a particularly genius contribution could be compensated as equally as someone who worked in the field for decades and proposed the same contribution.
Note: it also requires an environment where work is recorded publicly so that plagiarism is essentially impossible, though that brings it's own challenges.
Quick notes:
- I'm talking about a hypothetical ideal future as I see it, and why that's exciting to me
- I don't think we're anywhere close to where we need to be for this to be realistic. More like 50+ years when we figure out patents, copyright, delivery, and fine-detail privacy-friendly monetization (person X purchased Y because of seeing a billboard and having conversations with sales rep Z.)
- I like moonshots. I think that setting big ideals as goals is a great way to get to where we can be as a society and as a planet. No one else is obligated to share that mindset or those goals (or even agree that those ideals will get those goals)
But I don’t see how GitHub has the right to suspend him and rewind his work. I mean, that has to be a copyright infringement if there ever was one.
And the code is open-source under the MIT license, so GitHub can do with it as they see fit.
You can copy it and claim ownership over that, but it doesn’t allow you to remove the author from their work and then keep the work as your own.
The author has a right to delete it if they want to.
No he's not, and you're just trying to be outraged. Just fork the code if you don't trust him. Oh, but you don't want to take his place as the maintainer? Maybe deep down you know that there's still a difference between being in charge and submitting the occasional pull request?
Your actions contradict your words here.
A maintainer role could be to just accept some occasional pull request if he don't want to make it a bigger project.
Focusing on the troubles of this one person is a mistake. Of course the more "unbalanced" individuals will crack first. But we should expect more and more to go the same way (not necessarily by sabotaging their code though).
This model of software development is unsustainable.
I don’t think this is right. It seems very sustainable as evidenced by 30+ years of sustained OSS development.
It seems very sustainable as we live in a time of the best OSS software ever produced with more high quality software than ever produced by ideological volunteers.
I’ve seen statements similar to yours and they just seem so at odds with reality.
The big question is what happens when a maintainer wants to retire and a successor can't be found? Or (as in this case), when a maintainer gets so annoyed by their users that they refuse to continue co-operating with their user base.
We don't really have an answer for either of these questions yet, and we won't bump into them until maintainers get old or angry. But we have been predicting that this problem will happen.
Now we're bumping into this problem, it's our new reality. What's the solution?
That’s there’s only been a few problems like this despite millions of users is a sign of strength.
I hedge by pinning yo specific versions and keeping my own package manager (RStudio) to keep mirrors if the packages I scan. That the packages are open source means they are easier to scan or fork.
If a maintainer stops then the project can be forked. If nobody wants to fork then that probably means no one cares enough. And that’s ok.
Mostly it forces us to be flexible. I don’t think software is a thing but a process or cycle.
If a thing has an expiry date that is >10 years, then you're not going to see any problems for 10 years. That doesn't mean the expiry date doesn't exist, or that the thing won't hit it. It can be wildly successful for all those years and then hit the expiry date and stop immediately.
I’ll take a decade of success as a sign of sustainability over a package maintainer losing their shit as a sign of h sustainability.
I for one enjoy if anyone makes money with help of my code. I very well know I wouldn't have made it so far without many many others having chosen this way before.
I'm happy to contribute code, or documentation, but that's not the same thing.
_faker_ is already gone from our project. The parts of faker that we were using were almost trivial to implement ourselves... probably should have done that from the start.
I agree. It was an irresponsible prank. But Microsoft didn't fork the projects. They hijacked his digital identity on two of their platforms, instead. I find that much disconcerting than what this one maintainer did.
For them it must look like a malicious hacker took over the devs account, and reverting the malicious actors changes is exactly what I'd expect of a responsible custodian.
If you want to trick people into downloading malicious software, don't do it on someone else's platform.
Important NPM package colors from Marak causing console problems at the moment - https://news.ycombinator.com/item?id=29861560 - Jan 2022 (1 comment)
Creator of faker.js pushed an update of colors.js which has an infinite loop - https://news.ycombinator.com/item?id=29855397 - Jan 2022 (1 comment)
Marak adds infinite loop test to popular colors.js - https://news.ycombinator.com/item?id=29851065 - Jan 2022 (7 comments)
Marak's GitHub account suspended after he erased his faker project - https://news.ycombinator.com/item?id=29837473 - Jan 2022 (53 comments)
Faker.js Erased by Author - https://news.ycombinator.com/item?id=29822551 - Jan 2022 (2 comments)
Popular JavaScript package “Faker” replaced with message about Aaron Schwartz - https://news.ycombinator.com/item?id=29816532 - Jan 2022 (3 comments)
Faker.js Has Been Deleted - https://news.ycombinator.com/item?id=29806328 - Jan 2022 (9 comments)
1.It is totally in his prerogative to mess up the package he manages, but not to install into it malware. I am on the fence if this would count as malware. (Because of the open loop, but my leaning is that this is not malware.)
2. Github is, IMO, breaking any trust that I might have had by assuming control of the package, removing the last commit and keeping it online.
If they feel they have a reason to close it, they should. And, they then should fork it and put it up under their own name. Which would generate lots of bad press, but is at least within their rights.
3. I don't quite follow the logic of Github closing his account. Yes, I know that when you use $megacorp they WILL eventually close your account and make you sad. Google did it to me once and shut my gmail account. Tough luck for not being a millionaire.
4. You should always lock your NPM dependencies on a version, and update it when you can see what the results are.
5. Yes, the large corps really should be paying for all the work that is being done to help them, despite their hostile attitudes (being typed on a Mac. Guess who wrote the docs? Not Apple.)
6. Github has some perfectly good competitors, both SaaS (gitlab.com, sourcehut.org) and self-hosted (gitlab, gogs/gitea, etc)
Using them empowers you, and removes a wincy bit of leverage from $megacorp. Enough people follow suit, and the world will be a better place. And besides, Copilot won't steal or reveal your code.
7. There are more effective ways of making his point, but he worked out of emotion, not logic.
Eg. Perhaps he would have been able to change the license and demand compensation from all non-profits? That would provide both cash and publicity.
As a rule, it is always better to act out of logic than emotion, but us humans seem to have an issue with this. ;)
8. Is anyone stepping in to help the author get treatment?
What I find most interesting though are the ethics. The way I interpret (1.) on this comment in the context of this thread (other people have said similar things) is that the community considers the author here to be acting ethically, just annoyingly. When someone submits dubious patches to the linux kernel and wastes everyones time, it’s unethical (kernel maintainers are the victim). When researchers submit dubious CCPA requests to people on and waste peoples time, it’s unethical (webmasters are the victim). However, when a package maintainer throws a temper tantrum and fucks up everyones’ stuff and wastes a bunch of time, they’re in their right to do so and it’s pretty much just annoying but totally okay because the maintainer is the victim of something (either corporate greed or mental health issues, or both). Our society very much puts a premium on protecting victims.
… is this a bad thing?
For these particular packages? Very unlikely.
Especially since changing the license of a project from MIT to AGPL doesn't suddenly revoke your rights that you had under the MIT license -- only new code would be affected by the license change.
Faker has (had?) MIT license that basically has no restrictions. $megacorps have all rights to use it any way they want.
Why not change the license then? Why not amend the LICENSE file with "free to use unless you're big tech" clause? Correct me if I'm wrong.
"big tech should be paying for all the work that is being done to help them" -- They do offer their services and usually you don't need to pay for them _directly_, rather with personal data and opensource libs. Whether or not is it fair trade -- each one decides for their own.
Then everyone would use the old code under the old license and he’d have even less of a chance to get funding.
Just reply here and I'll see them.
If you use `require('colors/safe')` and only use the basic colors, then Chalk is more or less a drop-in replacement.
If you use the property values (e.g. `"my string".green`) then you'll need to change that to `chalk.green("my string")`.
Thank you so much for what you do.
Here are the links for colors and faker:
https://pkg.land/package/colors (chalk is top suggestion!)
I get my paycheck from my employer and I have always been successful convincing my employers that I do open source work on the side for my own interest.
For me, if I got donations that'd be great, but it'd not create a different sense of responsibility for my work, I'd keep doing exactly the same (unless I was explicitly hired as a contractor, but that's different). I do not particularly mind not being paid though, it's me who is putting my own code out there for people to use, for free!
Now I make mainly open source JS libraries and use the fairly liberal MIT, if I worked in end-products where there might be a bit more of a "competition" or a big company might literally repackage/resell your product I might release those under a different license, like dual-licensed or similar.
More reasonable than folks who release under a license, then complain when others do exactly what the license allows.
I see a lot of "but give nothing back" complaints from some open source folk, but I've looked hard and I don't see a "give something back" clause anywhere, at least not in the licenses I'm using.
What I do see are "give something forward" clauses, which explicitly target customers, not suppliers.
I like and use open source as much as the next guy, but for my day job I code for money. Alas so far Open Source pays no bills.
You're right about that, but there isn't a "this software works" clause either :D
I think there is a big psychological difference (and maybe a legal one?) between accepting donations for something you put up for public access vs. accepting payment for doing work.
As for the legal aspect, I'm speculating based on just a bit of knowl she about contract law: If you give something as a donation, I don't think that constitutes a contract. If you give something with the promise or expectation (by all parties) of something in return then it begins to strongly look like a contract.
I could imagine a lawsuit against a Patreon recipient if they collected $1m while promising something to supporters and never delivered. (I'm not sure people would bother with a lawsuit, but I could see grounds for one). I think it's a bit different if the exchange was more informal, like "Hey I'm making X for my own enjoyment, I hope you like it too. Click here if you want to send me coffee money" and then collected $1m on that but never finished the project.
There's a lot of subtleties though, and plenty of contract disputes revolve around whether or not a contract existed in the first place (written, verbal, or implied)
So, if you start saying "I will maintain foss project X if supporters average $Y/month" then I think that really muddies the water on legals obligations in many jurisdictions. It may not matter if you call them donations or not. After all even with donations to non profit there can be an expectation of return: a plaque on a wall, name on a building, etc.
What do you need to convince your employers of?
I totally understand that billionaire corporations use software like this for free. But the software maintainer has explicitly allowed _anyone_ to use it for free. If you don't want them to use it for free, license it as such.
What am I not seeing here?
I find it ironic that people are more upset at this guy for complaining about corporations, than they are about the corporations leaching...
the dev and hacker communities have really gone full on #HailCorporate haven't they. Where did my anti-establishment Libre community of the 90's go... I long for the good old days
There's no contract that says complaining is banned.
The license doesn't say any payment is necessary.
The license doesn't say new versions will still work.
The license doesn't say anything about complaints.
If it's valid to complain about code breaking, it should also be valid to complain about lack of payment. These complaints are outside of the legal mandates of the license.
Likewise, the license explicitly says that the software is provided for free, therefore it isn't valid to complain about people not paying for it.
Nobody's on the side of the big corps here, but "why aren't you paying for this thing that I've given to everyone explicitly for free" seems nonsensical.
I think both complaints are valid. Being legal and being beyond complaint are very different. "explicitly for free" is the legal contract, and it's okay to have norms that extend beyond that.
The point is, people apply legal logic to the payment and moral logic to breaking the code.
You can either agree that this guy is an asshole but these companies totally deserved it for leeching off his work, or you can say that they're both in their right according to the license.
But the argument that "he's an asshole because these companies had no obligation to pay him" is extremely dumb and hypocritical, and that's what many people are saying.
> THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
This makes it pretty clear: The author is NOT liable.
If I give away donuts for free and stop at some point, you have no right to complain. If I poison the donuts because you should've really thrown money at me for those donuts that I explicitly marked as free, I think you could complain after all.
Either you stay cautious, in which case you maintain your own forks for your own business or reinvent the wheel, so you don't rely on others that much, or you admit that you can't just reject this dependency - in which case it becomes either a public infrastructure, or a "donut business" on its own, and both should be financed as such. Take Linux as example, Linux is backed up by corporations and financing because everyone understands how crucial Linux is for our living. People took all the necessary steps to guarantee that kernel dev team is not going to disappear at any moment.
This is not the first and not the last time this happened. For some reason people think that open-source devs owe them something just because they had the right to bring their projects into existence. Javascript environment especially suffers from it because of unknown obsession of people to depend on packages which contain 1-2 lines of code at best, packages that can disappear at any moment.
Faker dev acted maliciously, but no one could guarantee that he wouldn't. No one was there to care about his mental state, or his wallet contents, and only relatively small companies and few people donated to his project, something he worked on for over a decade.
Sure, you can blame him all the way you want, but that won't undo the damage. If you rely on something maintained by an individual, you have to take into account that this individual is an actual human, this human actually exists and like any other human he is a subject of free will and uncertain futures, and whatever risks come with it. If you don't, this is what happens to you.
The linux kernel was not always as well-financed as it has become. Before it's recent about-face, Microsoft financed attempts to stifle Linux. Linux's continued existence has rested always on the merit of its utility, whether to hobbyists or to corporations.
The Faker dev may not owe the rest of the world anything, just as the world doesn't owe anything to him. But what about those who have payed or contributed to his work? Are you of the view the anyone who sincerely their money, time, and intellectual output into Faker deserved to be suckered? Those people are human beings too. They deserve something for their investments rather than being used as unwitting pawns for someone's mental breakdown-induced prank.
Taking your view of security to its natural conclusion, no person should use a computer if he/she didn't bake the silicon wafer himself/herself. Otherwise he/she shouldn't complain if he/she becomes a victim of fraud or misrepresentation.
If I rig the hammer with a grenade in the head, so that it will violently explode the first time you use it - do you still think this is covered under the terms of the MIT license?
If you're not going to support the development in any way, then you don't get to have an opinion on what should be done or complain about bugs.
Honestly, even then, I think we're stretching it. Maybe at the surface it seems like it should be that way, but this isn't just some tiny package that a few companies are using. We're talking about tens of millions of downloads every week. This package has essentially gone and become public infrastructure, much like log4j.
The companies relying on it should realize as much and understand that it's in their best interest to ensure that the package keeps on being maintained.
With the plate there's a sign that says both "take" and "leave". In this case there is also a sign (the license) which only says "take". The intent is clear in both.
It's further not comparable because taking a literal penny deprives the next person of it, whereas here using the software for free costs the other users nothing.
But I'm not trying to nitpick the analogy, I only want to point out the the obligations (both social and contractual) are not the same, neither are the consequences.
Again, if he wanted to make money from his software, he should've put it in the license and charged the big users for it.
The metaphorical sign does say take and leave, and the take vastly outweighs the leave.
> Again, if he wanted to make money from his software, he should've put it in the license and charged the big users for it.
A developer shouldn't have to ruin the open-source nature of the software to get there.
Maybe if we could invent some standardized almost-open-source license that doesn't terrify companies we could get there, but we can't even seem to define "commercial" in a way that doesn't break everything. Better still it would be nice if we could use social pressure to get companies to donate a small fraction of the money open source saves them.
Writing software under some variety of a free license is essentially a donation. Authors shouldn't expect to get back anything: Imagine a person donated a ventilator machine to a hospital and it saved a few dozen lives and helped out hundreds more. It would seem strange to me if that person was later ranting that the combined net worth of the people helped by that machine was in the $millions and yet they never got any of that money.
That's how it sounds to me when when foss authors complain about not getting paid. It sounds like the subtext is, "If I had known how useful and popular this would be I would have charged for it." Which seems like a strange attitude to have when making something you give away for free in the hope that others found it useful.
I support freedom of speech too; I explicitly allow you (or anyone) to be an asshole, but if everyone is an asshole all the time, I might pick up my toys and leave.
That's right, I prefer a world where people are nice and do nice things voluntarily and out of respect / compassion / desire to suppport / etc. instead of doing things a certain way because a law or contract requires it.
And so is largely my stance on free software (and more.. music, games, etc.). I would not expect most people to pay or donate, and it would be impossible to write a license that requires it without discriminating against those who can't or just don't find it worthwhile. Free software works best when it comes with no strings attached.
However, if something I made got really popular and thousands of companies started relying on it, I'd expect to see at least some support. And if everyone just kept taking but never showed any support, it's quite possible I'd get burned out on it, especially if popularity also came with a lot of demands and entitlement. And if everyone felt entitled to just take and never give, I would also feel totally entitled to replace my own project with "thanks for all the fish" when I'm done with it.
If I'm developing an app and wanted to use something outside of that "safe" registry, maybe I could, but I'd have to have a longer conversation with my enterprise's security org about why I'm using some new package that's not in the "safe" registry - and I'd probably have to pin or import it into my org's private repo.
It's up to package authors and this new Redhat-ish company that manages the "safe" repo to figure out how to split revenue back to package authors. The new company is definitely providing a service and should get to keep a cut, but hopefully there's enough left over to give some to the package authors - and that's incentive enough for the package authors to want to get their code included in the "safe" repo.
My company's security org is doing code scans/static analysis and version tracking and software BOM work of everything we're building, but ultimately none of this makes sense if I as an app developer can just add whatever I want and it's assumed to be safe if it passes the scans and doesn't have a CVE listed somewhere. We'd happily pay if someone was willing to try to vet packages (and take on some liability if they're wrong)
Imagine if npm allowed organizations to publish "vetted pointers" to packages. So redhat could publish a "{redhat}colors", which would include only the vetted versions.
When installing, you could choose to setup your installation to allow "redhat-vetted" versions only. And that would apply even to sub-dependencies.
This becomes a community tool if "redhat" could tell npm to vet anything vetted by another org.
People keep on claiming there is a need for a corporation like that. But Sun didn't really make any money with Java and had to sell to Oracle. Now all these silicon valley startup complain about Oracle costs.
Eventually, Microsoft will pull the same thing with NPM (and Github), they didn't acquire the package manager just for creds, they will make it profitable.
As for Redhat they are owned by IBM now.
New versions of packages are verified, approved, and mirrored.
(The revenue split part isn't really a part of that, but you're not really guaranteed revenue as soon as you choose an open source license. You have to make some kind of value-add like support or cloud services as a complementary upsell.)
Last I checked create-react-app pulls around 1k transitive dependencies. Can't really blame JS for that, can we?
> I will pay you cash to delete your npm module
So you won't gain anything from this type of dependency management, because it is way to complicate to understand and to manage for a developer.
I do think there is space for someone to ship an "unofficial meta-package" for languages like JS to wrap all this stuff (I tried to do an analysis of npm once to figure out what would make sense but got lost in the weeds....)
Python (for me one of the gold standards on this front) has been hyping for a future with a much smaller standard lib and it makes me sad.
You really need an organization which sponsors and directly hires coders that are maintaining critical infrastructure.
(Of course the npm world is a bit insane where stuff as trivial as leftpad can be critical infrastructure. Don't really think someone needs a $200k/yr salary to maintain just that)
There's an interesting bit of social psychology here where the top reaction to this isn't "lets try to sort out how to pay all the people who are doing all the free work" (and I'm really thinking more the log4j and openssl people and the whole broader ecosystem problem this highlights) and instead it is "how do we keep being exploitative and just outsource the hard job of vetting everything?" I'm pretty sure Google will probably get some AI people onto the problem though, there's clearly a business model there.
If you want to use this distro in your own company with full time support and continuous upgrades by yours truly, my yearly salary will be 220,000 USD, please--not counting any donations you decide to make to individual software authors to ensure your use case is covered by their software, as the above amount covers only my personal salary and considerable expenses.
A large discount is potentially available should other corporations avail themselves of this opportunity and also help cover my salary and expenses. Contact me at [email redacted].
I'm not holding my breath that anyone will take me up on this opportunity, so this distro will just have to remain for my exclusive use only, I'm afraid.
The way I’ve seen (and might not be the best way) people handle ownership is if a dev wants to use lets say ‘colors’ from npm, then they/their team takes ownership of that package internally. I guess an issue would arise if the big co is doing development on a public repo, so they’re forced to use npm/dockerhub/etc.
Point is, maybe 10 people. And that’s if you like ramen.
Moderately skilled it engineers other of backgrounds and devs can make much more than $200k, just go check levels.fyi
To the parent comments point
> It's a bit wild that the sum total money spent on salaries for engineers handling potential problems stemming from this or defending against the possibility in the future could probably have covered paying the maintainer a living wage many times over.
The collective effort across numerous companies is much more than just $200k and you can bet your butt on that.
Even in America outside of the coasts and outside of FAANG, making $140-$150+ as a senior developer is very good (and compared to almost all other industries is absurd) - salary.com which doesn't just rely on self-reported info as levels does reports the median salary + bonus for senior software engineers as $120k
https://www.salary.com/tools/salary-calculator/senior-softwa...
Outside of the US, even in more expensive places in the EU, even the equivalent of $100k for a super senior lead architect would be Very Good - I don't know a single SWE in the midwest in the US - including senior embedded systems engineers working on medical devices, senior firmware devs working on networking equipment, or any web engineer that makes more than $175k and I know plenty of Very Good senior full-stack web devs that make $125-$150
$125k a year is still a top of the top salary in the US, so don't cry for them tho
That's why the number they used for a living wage is so low too.
Dumb comments saying software engineers make 100x a living wage (as if this would be a bad thing) are the flavor du jour. It’s hard not to respond in kind.
But thank you, for what it’s worth. I remember you from 2010. It was quite a time.
Individual contributors in large companies, especially, would want their companies to fund FOSS projects they use. But approval processes are generally extremely complicated and there's nothing to gain internally by doing it. And we're talking about money that these corporations spend each millisecond. They barely need approvals for many other activities costing 10x, 100x in other domains.
In theory, this was enforced by copyleft requiring derivative works to also be free software. In practice, companies use software with permissible licenses instead because then they can reap the benefits without any requirement to pay it forward.
> If you’re expecting to get paid for it, it’s not FOSS.
Being paid for your time has nothing to do with whether your source code is public or what freedoms users have when using your software. Conflating free software with volunteer labor is exactly what leads to situations like this one, where the author's business based on faker got copied wholesale by a competitor who simply ignored their attempts to reach out.
> Deciding you can’t maintain a project anymore is fine, but pulling it out from under the people that are using it is incredibly anti-FOSS.
The mechanisms that allow a rug-pull are entirely choices made by the users of the libraries for their own convenience; the author did everything needed for you to download a working copy and use it in perpetuity. It's your fault for choosing to rely on NPM, choosing to not cache your dependencies, and choosing not to pin your dependencies.
If you want to fix this, stop contributing to permissively-licensed software. If you have a change you want to make, make or find a GPL fork of it and contribute it to that instead.
- They're contributing while at work and work only allows permissive licenses - They're familiar with permissive libraries because of the previous point - Permissive licenses are perceived as simpler - They've been pushed away from the free software movement by the FSF/Stallman/Linus - They don't think copyleft is the right form of enforcement
The OP is also attempting to use a proven failure of a business model, and then throwing a tantrum when it fails. Sure he’s within his rights to do so, but he has no moral high ground here, and I don’t think he’s entitled to any sympathy for adopting a business model that everybody knows for sure doesn’t work.
> it stops being yours, but you benefit from having a huge number of people improve it for you
It stops being yours, but somehow everyone who works on it can say they're helping you. This isn't fair. You don't have to pay for it, but fixing and adding features to the software that you use to make a living can't be counted as charity work.
But what happened here is that free/open source software doesn't have a consistent stance on paying maintainers or contributors, and this author feels that it's unfair and (potentially in the midst of other personal issues, it seems?) took advantage of a problem with how the ecosystem pulls in dependencies to complain about it.
As a matter of practicality, commercial entities using a maintainers' work should donate to maintainers to incentive them to, well, at least not go rogue, or to be on their good side when they rogue. Companies pay their employees to incentive them to function in the interests of the company. While this isn't fool-proof (principal-agent problem), it lowers the odds of a pissed off employee having the will/self-righteous fury to pursue something more aggressive than resigning in a huff.
FOSS is licensing, not religion. Rug-pulling a project from people who are enjoying using it isn't "anti-FOSS" IMO. This may not apply to you, but for all the contrast that OSS people project between their pragmatism and Free Software people being insane religious zealots on a jihad against money, OSS advocates seem to imbue a lot of flaky new agey spiritism into what FOSS is or isn't.
Why should this one developer collect payment but not everyone else who contributed it?
Regardless, it’s ridiculous to give something away openly under a permissive license and then later get angry when people use it exactly as you license it.
Doing your best to live in a bad system does not invalidate the complaints you have about that system.
That's the goal. Or at least one goal. But you can't just press a button and do that.
Being in charge of and an expert on open source software can be a way get people to buy your labor, but it's much harder than it should be. Instead many companies will demand you work for free, because it's open source!
Also trying to do something good for the world shouldn't make it so hard to make money. The companies get value but don't want to pay even a pittance.
It's hard to get paid when you decide to give your work away. If only there was some way a person could enter into a contract in order to guarantee payment in exchange for their work. What a radical idea...
2. You shouldn't have to take the option that hurts everyone else just to get paid.
Exactly, no one said _only_ the lead maintainer should be compensated. _All_ of the labor, not just the labor that happens to have a day job that benefits from it, should be compensated. That includes non-coding labor like support or community management, too.
The maintainer wants to have their cake and eat it too - they likely believe in FOSS for moral reasons yet consider it immoral when companies take their software and use it freely under the terms offered.
If you want people to pay you for your work, don't give it away for free. If you give it away for free, don't have a temper tantrum if someone gets rich off of your work without compensating you, because those were the rules you chose to play under.
right...
No human has been harmed here. No property has been substantially harmed either. Anything he "stole" should've been made public for free in the first place.
As another commenter said[0], this is malicious code and THAT is against the ToS of npm[1].
[0] https://news.ycombinator.com/item?id=29865977 [1] https://docs.npmjs.com/policies/open-source-terms#:~:text=Co...
> I don't understand why
If he can break his code because he is the owner then shouldn't the same reasoning apply for Github suspending the account?. It is their website and their rules. Keep in mind Github owns npm and the author has published a malicious package to npm which has 20 millions of downloads so I'm not surprised.
This is a library, not standalone software. Breaking it means breaking the code of every software which uses that library.
> No warranty means he isn't liable for any behavior of the software at all.
Somebody should tell all those computer virus authors, all they had to do was not include a warranty, and they're untouchable!
The users of this software pull it, explicitly, voluntarily. The author says it doesn't serve any particular purpose, and in using it you understand that. the software itself did nothing malicious, it just stopped working. It's not the same thing as slapping a license on a computer virus and forcibly foisting it onto an unwitting victim. It's not naive legalese loophole workaround thinking. When you choose to use the software you agree to abide by the license, which includes no promise of utility whatsoever.
No, those other programs importing it is what breaks them. They do that themselves. Or does he have push access to all their repositories?
If you perform action in obviously bad faith, your account will be suspended – it's very simple.
Github's terms of service must have somewhere detailed description about it.
Please, point me to the part where bugs, intentional or not, are disallowed.
Taking over someone's account is not justified; for this, definitely, but I'd say it's never is. Block the account yes; take over, no.
>GitHub has the right to suspend or terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately. GitHub reserves the right to refuse service to anyone for any reason at any time.
github owns your account -- if the github company thinks they should terminate your account, they will.
note that they didn't do that to faker, since it had a major revision: https://www.npmjs.com/package/faker?activeTab=versions
I'm not very familiar with npm/js, but isn't this policy since left-pad?
I would say that github is actually taking a stance that's reasonable of an "OSS author's union", if it existed - penalize one bad actor to recuperate the standing of all of us.
Github doesn't have the right to tell someone what to do with their own code. The only right thing to do in this situation is to fork the repositories and fix the situation on the npm side. Github doesn't get to ban this guy because he took a dump in his own backyard.
EDIT: I suppose the literal DoS attack in the code probably puts him squarely in the "malicious behaviour" category which then gives github the right to do this.
Obviously people wouldn't use that source code if they didn't want it.
> GitHub hosts a wide variety of collaborative projects from all over the world, and that collaboration only works when our users are able to work together in good faith. While using the service, you must follow the terms of this section, which include some restrictions on content you can post, conduct on the service, and other limitations. In short, be excellent to each other.
Yes they most certainly do.
Also, his landlord gets to ban this guy because he was building bombs in his apartment.
https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
https://www.qgazette.com/articles/more-charges-possible-for-...
https://nypost.com/2020/09/16/resident-of-nyc-home-with-susp...
https://www.reuters.com/article/us-usa-new-york-bomb/new-yor...
Are they now gatekeeping the kinds of code changes you can make to your own repo?
So some ToS could override the software license for your project? In that case I don't see why anyone would use github, ever.
I for one think that it makes sense - if I have an identity on github, it can only be turned off gradually, not immediately.
I would say, maybe suspend github services for the account and put a timer - 30 days - on suspending the github identity too.
I think someone should make a big deal about this. What would be the first step?
On the other hand, my GitHub was once suspended (and all repos shuttered) for posting gists that looked like spam to some algorithm. It was extremely unsettling, and they need to do a better job communicating. But they may have suspended the account because they thought it was hacked, which is almost reasonable.
I assume that GitHub now lives in Microsoft-liability-fear mode. Expect them to police commits in popular projects.
If losing your Github means losing your projects, that's on you for being lazy/irresponsible with them. Git is already decentralized, and anything important should be cloned on something you own.
He could've done far, far worse in terms of the technical impact of these changes. It's obvious that he was trying to make a statement, not exfiltrate data to sell on the dark web.
It's scary because, as a FOSS maintainer, your code is your responsibility to do with what you will until it's no longer in the market's interest. You don't have the right to expect any sort of compensation for it, but if your project somehow becomes successful and you upset the natural order, all of the work you were told belongs to you that you should be grateful is so successful without being compensated for is now no longer under your control. There was never a business relationship to sever in the first place.
The market doesn't want to come up with a way to compensate FOSS developers with high-profile projects like these, yet the general expectation is those individuals should just continue working on these libraries for companies to profit off of them.
I wouldn't have handled this situation the way this person did, but we're reaching this point where legitimate protest and speech is being met with erasure and confiscation of your work, and that should scare everybody.
> This guy abused Github to distribute malicious code to thousands of projects.
That's one way to look at it. An alternative view is that a bunch of companies took some free code and shoved it into their apps and then got mad that the free code is causing them problems. Instead of examining the inherent contradictions of the FOSS community, commercial interests would rather just erase the protestor.
That's how protesting often works. Deliberately interfering in normal affairs is a very common protest tactic. Just look at the interstate shutdowns after the George Floyd killing, or going back to Rosa Parks and the Montgomery bus boycott, worker strikes, etc. etc. That's exactly how protest works.
Forcing application code to print statements like "LIBERTY LIBERTY LIBERTY" is very, very different than trying to infiltrate commercial systems and exfiltrate sensitive data.
If you pull random unverified code from the internet don’t be surprised when something breaks.
Let's decide how serious this is. Exactly.
I am, for one, of the opinion that it is not at all serious. Not deserving of a lawsuit or an account ban. Not even newsworthy.
I mean, this could easily become the new normal for OSS. You use it – you're not insured against anything, for there is no formal contract.
There is no Zuckerverse contract.
No, I haven't seen many people try to argue that the intent wasn't malicious. Most people seem to be arguing that it's fine and npm and Github should allow it. Or the classic you shouldn't trust random software. If you ever wonder why people like the Apple app store just look at the Devs in this comment section. Makes it kinda hard to trust you.
2. You originally claimed, " no its a criminal act. crashing RANDOM servers that you DONT know what they do ...". That is far removed from what you're talking about here. Which is not only misplaced, but also ignorant.
3. Your original claim also implies that the intended effect of the change was to crash "RANDOM servers". I disagree with that claim, and with your subsequent claim that that proves malicious intent.
----
I understand that you're upset — I suspect because you've suffered either this or a fate similar to many unsuspecting users of the npm libraries in TFA — and would like to see whom you view as the cause behind it (i.e., the author) suffer some form of punishment. But that doesn't mean you should support just about any harm done to them by any entity in the world.
GitHub is not a software distribution platform/marketplace. It is not an "App Store". The relationship between one GitHub user and another is not very similar to the relationship between an app store user and publisher.
If you pull someone else's code through GitHub, you're clearly making a copy. From that point on, that copy is your responsibility. That is how the FOSS world has always worked, and so has GitHub's model of public repos.
Now, if you ask me about npm, that is a whole different thing.
He didn't go around submitting PRs to update the version of this. He didn't deploy anything into production.
You have the right to use the code for free, and he has the right to do terrible things with his code. If you don't like that arrangement, get him to sign a contract that includes responsibilities on his part like not shipping intentionally broken packages. Or get your distribution from someone that does have a responsibility to you.
I probably wouldn't do the same in his position, but I still support his (moral) right to do what he did. It's his project, and he can tank it if he wants to. Just like if I had a business, I could tank it if I wanted to. It's probably not a wise thing to do, but it is something I could do.
No, that's not what the TOS says.
In the same way that being an asshole isn't illegal, doing "bad things" is not against the TOS.
> This guy abused Github to distribute malicious code to thousands of projects.
1. AFAIK he didn't abuse Github. He used the typical method of uploading code, into his own repo.
2. He didn't distribute the code, that was npm.
3. The code being malicious is your interpretation. Can code not contain political or nonsensical messages? I think people should be free to share code with political messages, or with nonsense if they want.
It's an alarm that should be buzzing through sleepy programmer skulls. It should alert them to the fact that it's no longer the small company that respected programmers, where you felt your account was yours, and your repositories were yours.
The rules have changed with that acquisition, and Microsoft exploited the good reputation of that small company and the inertia of its users. Step by step, the site became more "social", and started suffering from the usual issues. Step by step, we see the same bigco policies that treat users as worker ants. When an ant starts making up a mind of its own, queen ant sends some soldier ants to cannibalize it.
Now, I realize here on HN the tired old rants of Moxie are considered gold. But if you want to skip being treated like an ant, run your own server, maybe support upcoming federation protocols to kill this centralization and bring down the nest, or at least migrate to some place that respects its users in the meantime.
> What’s amazing about Github is how it really brings the social aspect into play. Chris and Tom are showing us all visually how git development is supposed to work. I know I personally had some bing moments once I started pulling in commits from external git repos.
https://web.archive.org/web/20080514210148/http://github.com...
Yeah, you're right: they weren't "one of the good guys" even before the acquisition. Microsoft were only the biggest and most well-known proponent, but never a monopolist of EEE.
I have to say, though, that every time in recent memory that GitHub has popped up in the news, it's for something that's made me sigh. The only thing still keeping me one of their customers is the painfulness of transferring over all of my existing repositories.
You are, of course, entirely right: GitHub shouldn't be banning users for pushing code to their own repository (with the exception of if the commit contains copyrighted or illegal material, which clearly is not the case here), nor under any circumstances should they be commandeering their user's code and continuing to distribute it without the user's consent.
Even if you do want to set up your own instance, it's very easy to do so. It's one of the least resource-intensive server applications I've seen - roughly 200-300 MB of RAM used on most days, minimal background CPU usage, statically linked Go binary or a Docker container according to preference. A Raspberry Pi with a few hundred megs of spare RAM or a sub $5 VPS will be sufficient.
What's so painful about "git clone"?
Oh, you mean you've locked yourself into GH by using some of their proprietary extensions, that isn't present in vanilla git?
But how is this even possible? Whenever someone dares claim that Microsoft never abandoned its old "EEE" strategy ("Extend" being the middle of the three Es), legions of HNers always rush to defend them and praise their conversion to Good Guys!
It wouldn't surprise me if banning the guy's account was the decision of someone at the npm team.
What is "malicious code" anyway? Maybe Microsoft Windows is malicious. It does contain code to format your disk.
Windows contains the rm -rf code, but you, as a user, would have to knowingly trigger it and confirm. It's not like windows tricks you into formatting your drive.
Directing the argument into windows is just whataboutism.
The repository contains the console.log code, but you, as a user, would have to knowingly download it and run it. It's not like pushing code into a repository tricks you into running the code.
Trying to "win" by labeling something as "whataboutism" is just idiotism.
Can you not see a difference between this and between releasing a new package with a README saying "this module will print 'liberty liberty liberty' to your console in an infinite loop!"?
Every developer is responsible for what goes into his project, including dependencies. When a developer wants to update a dependency, he is responsible for the appropriateness of the update. In order to get an idea, he should audit the changes. For personal code, such an audit may constitute of a quick skim to determine that nothing breaks. For production code, it may also include a security audit.
When a dependency that used to do X now does Y and therefore breaks your stuff, you are the one responsible for dealing with it. The author disclaimed any warranty and any fitness of purpose for his project, and whether his intentions make sense or not is of no consequence.
My point was that there is no such thing as "malicious code". Code is code, and it's your responsibility to determine whether it fits the context. That someone put it out there with an MIT license means the responsibility is yours.
P.S. Ata nishma bachur magniv, lama macharta et ha'autobus? OK, ro'e she'ata gar be-Sverige achshav (Scandinavia ze ha'chalom sheli) az mevin.
1) GitHub and npm are supposed to be separate things. There might be stuff in that GH account that affects other ecosystems. By all means block the npm account, but that should be it.
2) in the end, one is responsible for the packages one pulls. We keep relearning that lesson over and over, because global package repositories made us lazy.
Is that going to be true forever? I would assume not. There is already much deeper integration between github and npm than there was a few years ago, and Github seems to be going fairly deeply into CI and distribution.
Microsoft owns both Github and NPM. There is an obvious conflict of interest here.
If the source was maintained on Bitbucket, why the hell would bitbucket nuke the developer's account access? That's not their problem what happens on NPM.
Github and NPM are defacto the exact same company on the other hand. Github actions are in retaliation of NPM "mispublishing".
People cannot argue that it is open source with a license which expressly doesn't have any warranties, and then cry foul if the author deletes it for whatever reason. If it was that important, you should've had better processes in place.
> license which expressly doesn't have any warranties,
The license is about legal liability and has nothing to do with social norms. Though now that you mention it, I’m not sure if the “no warranty” clause will hold up in court when the bug is malicious and the author admits it was intentional.
You don't?!? That's bizarre... Here, re-read your first sentence: "He got banned on GitHub for what he did to HIS GitHub repos." I added some helpful emphasis; did you catch it?
If not, riddle me this: How many people did he force to download stuff from his GitHub repositories?
a counter-factual that isn't known or proven.
May be bitbucket would also nuke the repo, if NPM asked them and show proof that it contains malicious code. It would prevent spread, and would prevent damage.
> a counter-factual that isn't known or proven.
No, it's a question. Questions can't be "known or proven"; only answers can.
It's fine to host code that contains any instructions, as long as the intent of that code is not to trick someone into running malicious software.
In this case, if the author had updated the documentation sufficiently along with the change to make it clear what the new behavior was, that would have been fine?
I agree that malware is unhostable. And in this case I think the author crossed the line. But I am concerned about getting that line defined in a way that restricts project owners from making whatever changes they want in their own self-interest without tricking people, per se.
This is obvious from the fact that GitHub won't suspend your account for releasing a new version of a package that has breaking changes... Clearly there is a scale here. The only disagreement is about where the line is.
IMO, if the package author had simply deleted the code - ie. published a new version with no functionality, then no action should be taken against them by GitHub or NPM. For this example, I think suspending the account is OTT, but I think NPM would be justified in reverting the package, since an infinite loop is somewhat malicious: and by that I mean that nobody would reasonably expect a package to hang just from importing it. If the package actually deleted data, then both the suspension and NPM revert would be justified.
In no other circumstances do I want GitHub patrolling what users commit to their own repositories.
Of course, if you pull my code and run it sight-unseen, and are damaged by it, you have a right to be upset at me (and possibly sue me) but that's not something I want GitHub to (try to) police.
If my code has a licence which provides no warranty, then you can use it, but any damage is your fault, that's the point of the MIT license.
the future is exhausting sometimes.
https://nypost.com/2020/09/16/resident-of-nyc-home-with-susp...
The irony is that the guy was once banned on here for spamming their startup Nodejitsu
Simple as that. None of them are under any obligation to pay, maintain, promote, or not clone your project.
I saw a project recently where the author released it to the public domain, but in the top he said something like "I know it's public domain, but please don't remove my name."
Sometimes people choose a liberal license like CC0 or MIT because they don't want to bother researching the boring details of licensing and/or don't care. But clearly that guy who wants his name on it, and the dev in the OP do care about the licensing details.
Releasing colors/faker under a liberal license was a mistake, and pushing out this malicious update was another (much worse) mistake.
What he should have done was updated his libraries to print out a warning like "This software has reached end-of-life and will no longer be maintained. It is being superseded by Colors PRO. Visit ... for more information.", and then started selling licenses/support contracts.
But now, not only is he not going to get paid for colors/faker, he probably won't ever get hired by any of the companies affected by this, he might get sued, and he might even go to prison if this gets misconstrued as hacking.
EDIT: Ok, after some more research, it looks like this guy is going through some serious shit: https://news.ycombinator.com/item?id=29868071
Everything I wrote up there was based on the assumption that he wasn't trying to build a bomb in his apartment...my bad.
Unfit software that causes damage is covered, intent or no.
Well, no, an assertion of nonliability isn’t a magical incantation; local law in whatever jurisdiction is applicable may limit the effect of such an assertion; in places with meaningful consumer protection laws there are limits on the ability to disclaim warranties, and even without decent consume protection law it's often impossible to disclaim liability for malicious torts.
Did he install this "malware" on people's computers?
> with meaningful consumer protection laws there are limits on the ability to disclaim warranties
"Consumer"... as in, "someone who bought something"? Oh well, I guess he'll have to pay them all back everything they paid for it. How much, exactly, was that again?
Pinning all dependencies to this extent is extremely inconvenient. More inconvenient, arguably, than to deal with this shit once in a while...
And even if all of that works, you still run head first into the issue once you inevitably upgrade the dependencies.
Dependencies change. Dependencies of dependencies change. You can't not update any of your dependencies for too long or there will be other problems. Something is gotta give.
If anything, this is the reason you use pull-through proxies. Your proxy will hold the version you depend on, regardless of upstream drama. Keep your proxy backed up and you'll be able to use those dependencies until the end of time, or you finally decide to migrate to an alternative.
If your package system allows this switch to another one, like, right now.
NPM, Cargo, etc. don't allow this (they "unlist" versions, but they don't "remove" them, i.e. you can't search for them, but they are still there).
I'd say the likelihood is about 50% you have a NPM package in your dependencies right now that pulls some binary or whatever from a random S3 bucket during installation.
And that's among the reasons people have started to commit their node_modules folders.
It has the neat side-effect of making people take a closer look at all the crap their pulling in too.
NPM no longer allows this.
You do that. Your coworkers don't. And they'll complain to your boss if you try to make them.
If your boss doesn't take your side, at least you can say "I told you" when things go wrong.
And their PRs aren't merged until they do, because we'd have talked about it before hand and achieved consent around the idea that pinning dependencies is a practice our team will start doing, or some other specific practice that solves this problem.
Really? Have I led a sheltered life? I cannot rightly apprehend the state of mind that would see pinning deps as bad. It only helps you!
The biggest churn in package-lock.json files is from using different npm versions. It’s worth keeping them aligned within a dev team.
save-exact = true
package-lock = false
update-notifier = falseBut I honestly don't care if companies "exploit" open-source software by making money using them and not donating to the developer. That may be unhealthy for the ecosystem, but neither side is entitled to anything. I would donate, but not expect a donation, and poisoning the well the way these developers did is not going to help any of us.
If someone publishes code for themselves, and at no time asks anyone to take it as a dependency, then at a later date they change that code in a way that breaks other people's use of it, do GH then take over the account?
I'm (honestly) trying to understand why GitHub can't just go ahead and remove any account as they see fit.
Edit: Am I being downvoted for asking a question?
If the intent of the push was to damage downstream users of the software then it is malicious towards them.
This is like arguing about whether the james webb telescope really is in space since we don't have a precise consensus about what altitude is considered the frontier with space.
To take a trickier example, say a GH user has a lib, then decides to re-architect it, breaks the API and for their own purposes pushes it to an existing version, breaking all other use of it. Now that's a nasty thing to do, but is it malice?
Another, real-world, example is I know of a user who publishes "honey PoCs" for security issues, where the repo. appears to be a exploit code but actually isn't. He's been accused of malice in doing this, but his intent is research for a talk on how people use code blindly without testing.
Is that malice, should GH take his account down?
By stepping into this area GH are going to have to find answers to this and also the problem of who maintains the repos of accounts they nuke?
I think they already have, those 2 examples you mentioned already happened and were dealt with.
I think intent is important to take into consideration, since after all that is the definition of malicious: intent to cause harm.
Your first example clearly has no intent to cause harm. That case probably happened thousands of time already since not everyone is willing/able to follow semver cleanly and strictly. Never heard about GH taking any measure against that. And I would definitely not expect them to as a user/maintainer.
For the second case, I think GH policy is that you can host that kind of PoCs, but the repo has to be clearly documented as doing such (e.g. you can't just add some vuln into some unrelated code "for research"), and the vulnerability cannot be an active one: "We understand that the publication and distribution of proof of concept exploit code has educational and research value to the security community, and our goal is to balance that benefit with keeping the broader ecosystem safe. In accordance with our Acceptable Use Policies, GitHub disabled the gist following reports that it contains proof of concept code for a recently disclosed vulnerability that is being actively exploited." - GitHub." [1]
Back to Marak's case, my opinion is that GH did the right thing: If he just had his code in a repo, with no semver, no other contributors/maintainers, and such, and decides to nuke it, then I hope GH would not have done anything.
But when you are using all the tools and trust of open source: Other people contributing to your repo, other people being active maintainers/admins and spending times out of their days to fix bugs on it, when you leverage NPM to make it easier for you to distribute your package to others widly etc, you give up the privilege being able to act unilaterally like an asshole without consequences.
[1]: https://www.bleepingcomputer.com/news/security/githubs-new-p...
For example in that first case, say all they had was a wave of people saying "x broke my application" it would look a lot like the case in the article, and they'd have to dig in to find out it was just a bad API change without semver being followed.
Also requires Github to have a staffed department to deal with this, now they've established themselves as the arbiters.
For me, there's a split between a repository (NPM) and a hosting company (Github). For this case I'd have forked the repo, rolled back the malicious change in the fork, and hooked the fork up to NPM, and leave the original GH account alone. That solves the problem of the breakage, without getting in to banning whole GH accounts.
Play silly games, win silly prizes.
If other people don't want that, then they shouldn't pull from his repositories. If they do that anyway, then that's their own fault. Nobody forced them to.
That's because the author themselves said in this case, that the reason to submit the malware was to give a "fuck you" to the big corps.
Yeah, so obviously he did want libraries that give a "fuck you" to the big corps (by printing blather in an infinite loop). Then it still can't be "malware" to put that in his own repositories.
And my point still stands: If other people -- you, big corps, whoever -- don't want that, then they shouldn't pull from his repositories. If they do that anyway, then that's still just as much their own fault. Because, still, nobody forced them to.
I see no code in there that checks if it is running in production. In fact, it is a reasonable expectation that people don't throw code into production blindly, but rather test any changes out first.
Yes, I do. I may not have a right to push malware onto unwilling victims, but I absolutely have a right to change _my_ software however I want.
> "wElL yOu ShOuLd HaVe Tested"
Please, no need to be childish here. I have not taken that tone, nor will I respond to it in kind here.
> no you shouldn't push software ... designed to crash apps that use it.
Show me where a `git push` == "push[ing] software ... to ... apps that use it". When the `git push` is to my own repository, mind you, not someone else's app.
> ... in bad faith ...
Finally, I agree with you on something.
Of course this was in bad faith! That was clearly the point. When I write software and put it out there, and somebody comes and uses it, and I break my software to spite them, I am obviously acting in bad faith towards my users.
But that does not make it malice, or my software malware. I did not reach down into other people's computers/apps and change what they run.
Good that you woke up to that.
He didn't force anyone to update to the new version, right? So how is it his problem? Some other entity had to go and update the version they depend on.
And if you now say "well, that happens automatically", I say; suites them right. They should have tested the stuff.
Not his problem.
What one usually gets in trouble for is causing destruction.
Regarding this case; wherever they ran in to problems, they probably should thank him for exposing that serious flaw in their release process.
Since it is his code; can you vandalize your own property?
> go back to the last good change and lock the developer out.
That's one reason for not using GitLab as source management tool. It gives them way too much power.
Surely, you mean GitHub.
Without a warranty, you're not held to strict liability, but you can probably be held liable under the default legal regime. If I buy real estate and get a quit-claim deed, there is no promise that the seller has unencumbered rights to the property. However, if I can show the seller intentionally defrauded me, they can still be held civilly and criminally liable for the fraud.
he's not, He's being held responsible for intentionally pushing malware
I don't get why people don't just pin versions, honestly.
I'm not saying he did a good thing. But neither did he push malware nor has he any obligation to publish unbroken packages. If you're using FOSS projects without a service contract, don't whine if something breaks.
Let's say I set up a lemonade stand in my neighborhood every weekend, where I pour a bunch of cups for people to take, put up a sign that says it's free, and I set out a tip jar.
After a few weeks, I get upset that people have been taking the lemonade without leaving tips, so the next time I set up the stand I add a toxin that I know will cause immediate damage to anyone who ingests it. To protect myself, I have of course been posting a sign every weekend that says the lemonade is provided as-is.
So – did I do something wrong, or not? Will a court look at this situation and say, "gee, he just poisoned his _own_ lemonade and set it out for public use, it's not like he forced anybody to drink it"?
This feels like 100% black-and-white criminal conduct, and I would hope anyone who pulls a malicious stunt like this would be held liable for it.
The maintainer has every right to change his mind and/or stop maintaining those packages at any time. However the outcome (Fortune 500 companies using his work for free) is consistent with the choice of the license. With insight that was a mistake to start with. Maybe a FOSS license plus a commercial one would have bought him money but maybe those packages wouldn't become as popular as they are now. Everybody should dual license for mutual protection.
Finally, breaking other FOSS projects and not only commercial ones is not the nicest way to complain against companies not paying him. Furthermore, honest question, did he ask them for those money?
I feel like people (and especially corporations thst have freely used the library for years) are overreacting a bit.
This is just a warning signal that we depend on random packages too easily. The only thing standing between many products and disaster is the decency of maintainers.
Nobody wants to acknowledge that (me included) since it’ll mean my job becomes much more of a pain.
1. A kind of "psychological contract" is in place between a package maintainer/creator and the developers using it and that is somewhere along the lines of "assuming good faith" or "good intentions" from the maintainer and giving back somekind of "kindness" to maintainer specially in cases of of some OSS (MIT, Apache, BSD-2/3 ...).
This maintainer broke this contract - the trust of its users. They are pissed and rightly so. He broke is because he also felt that another "psychological contract" was broken between himself and the market. So his users are pissed because they see this as retaliation from the maintainer to them without them doing anything to merit this.
2. Another aspect is that he could have gone multiple ways to try to get money from companies by pivoting his projects. But his action is an emotional response with a hint of political activism that caused damage also to developers who are not having the choice (they are not decision makers or not managing budgets) nor the desire to be part of this. So for them there is another breach of "contract" happening: using those libraries seems to have a hidden term "you will be used as collateral when needed in my fight against big companies" which they did not agreed and was not explicit.
No such thing was in place while money-rich corps got rich off his back. I can't blame him for getting fed up with this and reacting.
The author of the packages wants to use the fact that there are so many downloads to justify their position that they should pay him. The only reason the downloads exist was because he gave it away free.
If the author had started by charging a license fee, they would have close to 0 downloads. Someone else would have made a library to wrap strings in ansi-escape characters and pull random values out of data packages assembled by the Perl community.
The author does seem to be having some sort of mental health crisis at the moment. I hope they get the help they need.
In this case, it's a dev who decided to use his right of doing political activism at the cost of his reputation. But this it's a best-case scenario. Another dev of a popular NPM library could get hacked, and insert malware.
I wonder if there are zombie servers out there mining crypto or doing DDoS, just because an obscure library dependency of a dependency of a dependency, got compromised.
I don't think Marak was "right" (In bird culture that is considered a d*ck move), but legally he owned nothing to anyone. Adding a new update to production without testing first, it's in the hands of their devs of the apps, not him.
I am going to set up a self hosted git server for my personal projects straight away. I am thinking about Gitea, any one can share their experience with it? Or alternatives?
GitHub rarely takes action against accounts like that, don't let a sample size of one define them. There are lots of reasons to be annoyed with GitHub but this isn't one of them.
As for alternatives, check https://sr.ht
correct they don't enforce it but they make it such a royal PITA to switch accounts that I eventually gave up trying. They don't have an account switcher like Google etc.
> As for alternatives, check https://sr.ht
thank you! Checking it out.
Edit: it seems that sr.ht is not self-hosted though? I can see the link to create an account but I can't find instructions on how to install it on my own server.
If you are ever in need again, Firefox containers are great for this. They also allow you to bundle other corporate accounts, so you don't need any site-dependent switchers at all.
> Edit: it seems that sr.ht is not self-hosted though? I can see the link to create an account but I can't find instructions on how to install it on my own server.
SourceHut is a SaaS. It's created by a very open source friendly person, though.
Self-hosted alternatives are GitLab or Gitea/Gogs, if you are in need of something more lightweight.
But at the end of the day, sometimes I end up using my personal computer to file PRs that were inspired by a work situation. If for no other reason than at work I want my work email associated with commits, but I don't want to accidentally push it up to github.
well, this just made the Hacker News front page a few minutes ago :-D
DMCA is an entirely different beast, and it's not Github's fault that whole system is broken.
I'm reasoning about where my personal repos should be, and the answer is "not on Github", for the same reason that my email is not on Gmail: it's on someone else's server, they can close my account if they want, it happened before, might happen again.
Just because some things happen rarely, that doesn't mean you should not be prepared, as an example we know that airliners very rarely suffer from fatal accidents but that's not a good reason for you not to fasten the seat belt during certain phases of flight.
Microsoft and co. probably have the leverage to move that needle a little if they really wanted to.
Something like Netflix, I'm OK with, even if they close my account for some arcane reason, I'll just make a new one.
The services I'm going to avoid are those where losing the account would mean losing important data (email, docs, etc.) and those where a data breach could mean sensitive data being exposed (e.g. non-encrypted messaging apps, doctor's online booking systems etc.).
And yes I actively advocate for this with other people too. I'm not a fundamentalist or anything but I want people I care about to understand the risks associated to using online services that you don't really own.
Check it out here: https://git.unturf.com/engineering
Related: https://russell.ballestrini.net/russell-open-sources-remarkb...
If you want more of a one stop shop, Gitlab is a good alternative. The web UI is slower than Gitea, and the resource requirements specified really do match reality. Don't run it on less than quad core with 8GB of RAM, because it will be slow.
Nope, sorry.
> Or alternatives?
The answer is in the question: "git server". What's wrong with just git? Why do people think they need some other crap on top of it? (Sorry, stupid question, I know why: Because they've been conditioned to by GitHub's successful EEE campaign.)
What it should be training you to do is test updates first rather than blindly applying them in a production environment...
That GitHub is now the owner of NPM doesn't change that policy and maturing of the environment.
https://blog.npmjs.org/post/141577284765/kik-left-pad-and-np...
> We dropped the ball in not protecting you from a disruption caused by unrestricted unpublishing. We’re addressing this with technical and policy changes.
Still a reminder though that GitHub is a private service and they are within their right to remove your work at any time for any reason, or for no reason.
In essence, It seems to be the case of a developer getting screwed, being disillusioned, becoming political, making bombs?, attacking the ecosystem etc.
Many years ago, I recall another developer of popular NPM packages(Azer Koçulu) pulling a similar thing[0].
https://qz.com/646467/how-one-programmer-broke-the-internet-...
We followed each other on Twitter, I recall him being disillusioned with SV and angry to Wikipedia for some reason(I think he believed on some greater plan or agenda pushed by SV companies, including Wikipedia). I disagreed and got unfollowed and blocked. Later, if I recall correctly, he got married and was touring the world.
It's unclear if it's referring to current authoritarian turns in our western world, big corps using his software for free, or something else.
https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
https://www.qgazette.com/articles/more-charges-possible-for-...
https://nypost.com/2020/09/16/resident-of-nyc-home-with-susp...
He might have been the unibomber in training.
Don't want to pile on, but dude clearly seems to be going through mental issues.
He’s almost certainly going through major mental issues, along the lines of schizophrenia or something similar. He needs help.
as is usual with a lot of recent conspiracy theories, seems analogous to apophenia[0] to me, or something similar.
the non-conspiracy "fact" seems to be what most people here think about Swartz: that he killed himself after a overzealous prosecution. Nothing to do with Epstein or Swartz's role at Reddit.
The link seems to be “Swartz downloaded millions of scholarly articles using an MIT network, and Epstein/Maxwell donated money to MIT.” That seems to be about it? Not exactly a logical reason to conclude that Swartz was assassinated as part of an Epstein/Maxwell coverup.
Or both of those two.
I can't really see any positive outcome for him personally on this, although ironically any of the big companies he's talking about are learning the lesson not to trust other people's code updates without auditing.
But maybe this will change the mindset in open source package managers that updating to the latest version is always best. The older approach of something like git submodule and sticking with a tried-and-tested version until you make a deliberate choice to update seems much more appealing now.
This might be controversial, but I feel like the default position should be that every package over a certain number of monthly downloads should be considered as being added to the standard library (along with paying maintainers a stipend and helping integrate into a release process).
I think we can have our cake and eat it too on this topic
Problem is that package-lock.json files in node don't compose. I can't pull in a library that locks other libraries to a specific versions for me. It is possible there's another solution presented by DVCS, but it's not clear to me if it actually avoids the set of problems illustrated here or just dresses them up in different outfits.
Maybe if he included a backdoor in previous versions and now dispatched infinite loop from his C&C server, sure. But he published a new version of his library, which was literally pulled by the affected parties.
I’m pretty sure that was illegal in the US, but that’s multiple-felonies-a-day-land anyway.
The problem is not in what the code does it’s a problem with the agreement for use.
What if this was addressed at the “platform” level, I’m thinking the package manager here, NPM.
If npm had paid plans that would essentially mop up larger corporations they could then auto-distribute funds Spotify style based on “number of listens”.
I’d personally want to see this work mainly as enterprise plans.
This seems like a pretty decent idea…
For programmers, you'd be correct. That only really be a replacement for patreons, tips, and donations, which would typically be a miniscule amount. It just redistribute it instead. (Your $x subscription just automatically gets allotted instead of manually allotted).
Expecting compensation for a gift is the error.
If you intend to keep it as the original gift, it will be called abandoned.
The software maintenance is also given out as a gift. That's a choice.
So he's perfectly entitled to choose not to do that any more, no?
This model where someone develops something for free and then those that benefit the most don't contribute back isn't sustainable. I don't know if the packages owner was conscious about it but this was a political act and hopefully the impact will be positive.
From where we are we have two options: (1) companies find a way to make open source financially rewarding; (2) companies use their own crap instead.
It's a choice to distribute software for "free" as in "free beer".
Is there a license that is like MIT but with special clauses for people making big bucket?
I don't think I can just put an extra clause on it that says something on the line of "if you are using this to earn more than X big macs by year then you have to pay me or be subject to a fine".
This radically changes things as it may void the liability clause and also make code less fungible. And there's the issue of fairness to contributors.
- Devs do open source and get rewarded
- Devs get hired to make crappy alternative software for companies
Yes, it's called paid software, but don't worry, it's going to be trendy again soon.
The days of free software contribution are almost over.
Devs want to be paid for their work. too many corporations made billions from open source projects while maintainers live in quasi poverty.
What is needed is a proper market place for paid open source software. Github isn't one.
CVE are the proper marketing. The perspective of having a package with a vulnerability and no-one to provide a fix is frightening to any software maintainer.
I think I could be extorted dozens of thousands for a single upgrade. Heck, when the electrician auditor says our office is not certified for 2022, I pay $700 for a professional to fix it. Software will be the same very soon.
every time something like this happens, the reaction in the comments is the same: well you should test your dependencies. and yeah, i do that before release, but running an npm update on my dev branch and finding one of my dependencies has broken something is a bunch of work i could do without, and seems like work that is being duplicated by a ton of developers.
IT people for some reason tend not to be great at introspection which tells me this won't be fixed because this is more than just one asshole dude, this is a systemic issue with js and web development as a whole. This sort of thing would be really hard to accomplish in Linux for example because of the mentality they adopted early on when Linus had his first burn out moment, but the fact that even after leftpad nothing has changed really shows how systemically broken web dev is.
on a somewhat regular basis, as time allows, i run npm update to bring all my dependencies to the lastest version. then i test (including thorough manual testing / qa), commit, and release with updated dependencies. if some update is broken and i don't have time to fix it then yeah, i can roll back. but the point is to be on relatively up-to-date version of as much as possible, so if something is broken then it turns into a game of trying to figure out which library it was that broke things. i don't want to just not update any dependencies because something is broken.
A reasonable maintainer semvers their packages.
You shouldn't update to the latest version if you want to minimize the likelihood of issues. That's what stable releases are for
Fittingly enough, all four solutions for this particular issue all goes back to Snyk, as seen in the bottom of the blog post. Seems like they are labeling this a DoS to justify being able to publish something in their database and blog.
Common sense.
If the maintainers wasn't acting maliciously, they could change this new version to count as a major release, and then it wouldn't be a DoS.
I think it most definitely falls into "malicious code" that certainly is not done in good faith, and if not handled properly by downstream users, can cause a lot of unexpected problematic failures.
Whatever labels are used to characterize this, whether to call it a vulnerability/DoS or not, are just a matter of arguing over semantic meaning.
Anyone at any business trying to shame this dev for making an artistic statement through code is telling on themselves in terms of how much they value (or don't value) the freedom of such developers.
Drilling holes in your boat to sink it means yes, it is sinking "as intended", but it's still an act of sabotage.
I suppose you can specifically argue against the word corrupt as implying a corruption of the author's intention, but I think it also applies to "does not behave as anticipated".
(now, the interesting question is how fair is it to anticipate free work from an individual -- I don't know where to draw the line, but this seems to cross some boundary...)
I don't really see how this is relevant. Suddenly doing no more free work at all would have been perfectly fine, but this was intentionally breaking preexisting code.
I feel this language is used intentionally to smear the maintainer and paper over a real conversation over open source, responsibilities of maintainers and consumers, and the ecosystem as a whole. Instead it’s all about the “vulnerability” caused by the maintainers choices to commit “malicious” code.
Did the maintainer drastically change the software? You bet they did. Does that mean it’s malicious, a vulnerability, and/or corrupt? No. This isn’t an illicit cryptominer or process injection etc. the host machines are not being exploited in a malicious way.
You can disagree with the actions and what they are doing etc, but labels matter, and I think this is an intentional labeling of this to skirt around having real conversations around OSS, maintainability, the role of consumers etc
No, it's scuttling. "Sabotage" is when you do it to other people's stuff.
It was his code, so it can't have been sabotage.
What a terrible choice of metaphor. Apparently the author of this article has no idea what an actual brick is.
You can brick a device, but hardly do the same with an application, much less a web page.
I'm not convinced that GitHub has any business suspending his account.
It's a bit like me going to my bank to close the account and instead they throw me out and keep my money.
Honestly I don't understand why microsoft did anything at all. Can't people just pin a version?
Personally I think we should be auditing our packages' dependency chains to ensure they're not reliant upon this developer.
[0]: https://web.archive.org/web/20220109232136/https://github.co...
I use a ton of my own packages. Most of my published work is stuff that I developed for my own consumption. I publish them as standalone projects; complete with tests and documentation. Doing it this way, vastly improves the Quality of my work. It’s a pattern that I have been observing in highly competent engineers, for decades. I make these packages available for others to use, but don’t really care, whether or not they use them (which is good, because very few people use my stuff).
I think, in all my projects, I only use four external dependencies, and two of them are in an experimental project (one, being ffmpeg, and the other, a simple built-in Webserver package). A third, is a paid extension, in a “semi-experimental” project (a SOAP library in an ONVIF driver). The fourth, is a keychain wrapper that I use in a couple of projects. It is something I could write, myself, but appreciate not having to. I think I might use VLCLib somewhere, but I'm not sure if I have published it. I know that I played with it, at one time.
If I do use an external dependency, I check the code, and the author. I don’t do a full audit, but I make sure that it is well-written and maintainable, in case I need to pin/fork it. If they offer it as paid, I’ll often use that option, unless they are asking a ridiculous amount (in which case, I’ll find another option). The presence of a paid option is generally a sign that the developer is serious about supporting their library. I will check out the author. I tend to look for experience and competence, as general qualities.
If I find issues, or have requests, I’ll communicate with the author, through their preferred channel (like GitHub issues). I try to be respectful and polite.
I do use a number of StackOverflow-inspired (or other sources) snippets. When I do that, I never use the code directly, but take it apart, and put it back together, in my style. I also reference the source, in my headerdoc comments. I always make sure that I completely understand the code.
I only have one project that I authored, “go viral,” and I have turned it over, completely, to a very capable team of folks. I no longer have much to do with the project, and that’s by design. I”m very glad that it took off, as it helps a lot of folks, and I’m extremely grateful to the team that adopted it. I trust them to be good stewards.
* make a fork of the ones that are really, really important.
Proper practices makes this a nothing burger, aside from the mental wellness of the author. I AM saying if you got hit and it mattered, you’re probably not doing things right.
While it was seen as an unnecessary hurdle set up by us I hope it started some meaningful conversations in the teams and maybe even end up with them "reinventing" the wheel for the better.
I've seen it happen.*
EDIT: * While working in infosec, I'll add.
1. Robust build and deployment processes. Locked-down build servers, proxied/cached package registries, locked dependencies, automated dependency upgrades, tests, rollbacks, etc. Pretty much exactly what you need to mitigate unexpected breaking changes in dependencies, regardless of whether they're security risks or not.
2. Comprehensive dependency inventory. List of all your dependencies, where they're used, what vulnerabilities they're affected by, various other metadata, automated threat-hunting, manual review and annotation.
Trust but verify. No need for developers to fill out forms, wait on your (context-free) approval, resort to implementing worse versions of things themselves because they don't want to jump through hoops, etc.
Now pin an older version and if you want fork it and develop it yourself. Whooptidoo.
Most Linux distributions are using a single key for the signing of packages, and this might be an easier place to start changing over to a multiple signature model.
In this particular case is was a single jilted developer, but determined actor could easily attack someone with access to the keys to sign compromised packages, as per the obligatory xkcd on the matter https://xkcd.com/538/ .
Ideally you'd want a system which separates reputation from meatspace identity, so that well-trusted reviewers couldn't be easily targeted offline. Unfortunately that would require a lot of good opsec, and go against the financial incentive for someone to disclose their online identity as part of a salary negotiation, for example.
I'm not saying never use external libraries.
But recognise that each one of them is a potential ticking time bomb. Do you really need it, or is it a nice to have?
stop trying to save a couple of bucks by reusing functionality that's not that hard to just develop in-house maybe?
Everyone decloud and only use the standard libraries compilers provide. What a wonderful world! Everyone is forced to do some system programming. Going to be pain in the beginning but then whoever really passionate about programming (not shipping products but programming) is going to be happy.
OK just joke :/ Although I do secretly wish to wake up one morning and find out we have to do things like in the early 90s.
As the article states, AWS CDK depends on colors, if I want to use AWS CDK, I have to use colors too. I don't get the choice to re-implement that myself unless I want to stop using the official CDK library
Have any of these keyboard-warriors ever read a FOSS license? There's a huge fucking disclaimer at the bottom in all caps saying "this code does whatever use at your own risk".
So what? Is the author bound to the moral implications that their users assume the code actually works, but it's totally okay for amazon to completely disregard the open source ideal of "give and take" because the license technically allows them to?
In the worst case scenario, using 'stable' versions of Linux distributions like Debian.
But, in recent years, the trend was the one of young incompetent hipster devs: it is has been to not use the very last version of everything, and especially if we can get it directly from random sources on the internet.
This is especially true with npm/js and go developers.
It is not like no one tried to tell them and teach them about that, but they can't or won't understand...
Maintainers should be able to do whatever they want either their code
But if they vandalize their modules that should be a lifetime ban from the registry
It’s pretty obvious that node needs a better method for dealing with this by now
This would make libraries less popular and would make "stars"/"downloads" less of a misguided status symbol that is only making things worse, because the more "stars"/"downloads" people have the better they feel. Then comes hangover when reality hits and such person is left with silly numbers that are not going to buy anything but also not helping to land a job.
That would make people who should not be in a maintainer position not to be there as it would stop being so attractive.
In the end there would be libraries/frameworks created by corporations that can afford that or by real enthusiasts that understand what they sign up for.
Did Linus Torvalds made Linux to be famous - not - he did it because he liked to have it. He made it into career and got famous, but he is an exception not the rule. There is too much people who are in it for the wrong reasons that is my conclusion.
There is a reason why there is a large cottage industry doing security scanning of npm deps.
In the end it all depends on who you trust.
Working on Open Source a lot myself, I have absolutely no sympathy for the developer. If you do not like others to use your work, then don't do it. Whether the "other" is a large corporation or not is immaterial.
Now, this does point a problem which has bothered me before: The commoditization of every little aspect of functionality. That leads to 1000's or 10000's of dependencies that are impossible to track.
It just points out to the glaring need for the JS/Web STL library to grow.
If the author made the project GPL, someone else would create a similar library with a more permissive license, which would end up taking the market and making the original library irrelevant.
Totally understand the guy though
We all live in this 'wild wild west' of software that has no guarantees of quality or safety or rigor. We could really use a regulated license for software development, and minimum industry standards, so software can be certified to have the bare minimum of quality and safety processes.
Things like an upstream dependency breaking can be caught well before it makes it into downstream projects. But you need the process in place to catch it. We all know what we're supposed to be doing, but few people actually do it, for all sorts of reasons (no time, no money, didn't think it was important, didn't know how to do it, etc). I think we should have regulation to require it, and an actual body that regulates how this is done, just like in every other "real" engineering discipline.
The publishing side is irrelevant. Anybody can make any package available for free on the internet. The unwillingness of some private businesses, often billion dollar companies, to audit and vet libraries because obviously, it costs money and these businesses use open source as a way to cut cost at first place, is the issue. The entitlement.
Businesses don't really use open source to cut costs. Most businesses don't even know they're using open source. The business hires engineers and tells them what they want built, and the engineers choose to use open source, because they're lazy and it's quicker than trying to get proprietary vendors approved and licensing costs included in budget forecasts. Maybe some tiny companies that have no money really need to use FOSS, but the majority of businesses pay for software when they need to, they don't mind.
But conversely, if people are benefitting from something you've created then it's only fair for the person who created this value to get some financial compensation commensurate to the value they've created.
The author of this package has chosen a method to get some compensation for their work that has resulted in a lose-lose situation where neither the author nor the users are happy.
But it doesn't have to be this way.
The [Opensource guide][2] has some useful tips on [Getting Paid for Open Source Work][3]. For people interested in web3 and crypto, [Gitcoin][4] is platform where you can [get paid to work on open source software][5].
Hopefully, by becoming more informed on ways to make money from open source software we can avoid situations like this in the future and create a fairer system that works for everyone.
[1]: https://en.wikipedia.org/wiki/Public_good_(economics)
[2]: https://opensource.guide/
[3]: https://opensource.guide/getting-paid/
[4]: https://gitcoin.co/
If you don't want fortune 500 corps to use your software, use license like Affero GPL, nobody will touch it. Don't put it in MIT.
I think he has a right to torpedo his own projects, and GitHub should stay out of it. Pin your deps, folks.
On the other hand if brother wants to get paid and stop people exploiting his work, maybe don't use the MIT license? There's always AGPL. Of course, as with Elastic, these projects would never get off the ground (in terms of support) without actually using a commercial-compliant license.
I'm starting to get sick of developers who release open-source work but then are surprised when people use their work as released. If you want someone to pay you money, ask for money. If they don't want to pay you, do something else. Stop playing games with licensing and taking things down.
Is all these people are doing are ruining open source.
>This trains people not to update, 'coz stuff might break.
He says this as if it's a bad thing? Clearly depending on 300 libraries and auto-updating everything is a massive security risk.
Also very concerning that the dev's account has been suspended.
Was the developer being an arse? Yes, definitely.
Technically and morally correct are two very different things. And doing this sort of thing does have an impact on your reputation I suspect that the dev now have limited at least a few possibly-lucrative jobs down the line.
I am glad VsCode pops up a warning on all new repos - but that kind of warning will often end up getting dismissed because it occurs all too often.
Should all dev work happen in VMs? Docker?
Where is the web-of-trust solution for dependencies?
Where is the notary service for dependencies?
This all feels like a ticking bomb to me.
I created shrinkpack before left-pad and thankfully it meant that we were unaffected.
A lot of developers, understandably, baulk at checking in dependencies, but there is a concrete benefit in being able to continue uninterrupted during outages.
It is what it is. How would you fix it?
~~ Rich Hickey @richhickey
https://twitter.com/richhickey/status/1338893764702691334
Edit: "Open Source is Not About You" by Rich Hickey
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
Archived post: https://web.archive.org/web/20210516172305/https://marak.com...
A developer updating their code & packages in whatever way they see fit is their right. Those folk downstream consuming these packages are responsible for policing their supply chain with regard to security/quality/risk.
That being said, this is a significantly anti-social move that will (quite rightly) negatively impact their reputation, and the trust placed in them, their code, and the packages derived from their code.
I submitted that link here: https://news.ycombinator.com/item?id=29876749
Just a proxy that delays new version availability for a week would protect you from this.
But yarn add directly from the account of a madman who made your dependency is so much easier.
Pin dependendency versions, don't allow auto-upgrade. And cache your dependencies locally for as long as you depend on them.
Yes.
Or vet them thoroughly.
Sometimes folks get disillusioned which can lead to things like very real depression which can drive them to do things that otherwise they would not.
I don’t agree with the choices in this case personally, I do not think we should rake the maintainer over a fire over it without more evidence of actual wrongdoing.
This feels to me, if I was projecting myself as an armchair psychologist, that feelings of disillusionment have driven this behavior and I can understand how maintainers like this get there, especially when people build multi million dollar businesses on the back of your work without giving support or worse, demanding things they feel entitled to.
Is it fair? No. Should perhaps they handled this differently? I wouldn’t have done this, I think there is a more graceful way to retire projects personally. Is it true that legally they were licensing their work in a way where millions could do this? Of course.
However, ethos cut both ways. Companies and certain individuals like to ignore the ecosystem and not contribute back, lots of big ones, that make billions per quarter, and then chastise maintainers for not being responsive, or trying to change licensing to get more personal benefit etc. yet they don’t want to be held responsible for the other side of the ethos: contributing back to those which you built your success upon.
This is someone being a shit deliberately. They shouldn't be mentioned in the same article.
I’ve been running jsonip.com as a free simple IP lookup service for 11 ish years.
I used to be very politically active (shout out to Indymedia). Nowadays the sentiments are the same but the outreach, it is lacking.
After Trump got elected, I went through the same phase many people did: shouting into the void on Facebook and Twitter. I was pissed off and wanted to feel like someone was listening to me, rather than doing anything about it.
After a few months, that passed. And I honestly looked around for what I could do.
Well it turns out I had (still have) a free simple api service that serves a couple million requests per day. It’s not much of an “audience” but it was something.
What I ended up doing is adding some simple anti Trump messages to the api response. Yeah, on the surface this seems dumb and juvenile but let me out it into perspective. It’s my service that I’ve paid money every month for a decade. When in a situation where you have no voice, I feel it’s valid to use what you have.
Now here’s the critical intersection with the topic at hand. I absolutely never did anything that fundamentally changed the api. I had no intention of breaking the client contract just to get attention. I added a couple extra fields, but in no way did that break anyone’s usage of the jsonip service.
What this author did is really juvenile and crass.
It’s a 13 year old level of maturity that leads someone to break the software chain that many downstream clients rely on. How many hundreds or thousands of build breakage alerts went off when they did a package upgrade because of this? How many thousands of human hours were spent because of this?
There’s some minor argument being made in this that the author is pushing for some type of remuneration for their work, and I am entirely behind that. Maybe they should fork their packages into a paid model. Maybe setup a Patreon account. Maybe get a job at a company that uses their software. I dunno. But there are more mature and legit options for getting paid for your work than breaking the toolchain for who knows how many people and ruining your reputation at the same time.
… /end rant
The Retool people who decided to literally fuck this guy with his own project should be ashamed of themselves.
Why punish the majority of developers who contribute back to open source with patches, bug reports, comments, answers on Stack Overflow, etc?
And that's what the author did, he published a new version. You can blame your tools and package.json for automatically updating, but at that point it's a self-inflicted injury.
It's like if you went to work one day with a spray can hidden in your jacket and started graffitiing the office walls, but justified your actions by saying "Well you could have searched me before I entered to make sure I wasn't carrying that spray can".
Or perhaps a better example, what if some (free) binary application auto-updated, and included in the release notes or documentation a sentence stating that the "File > Open" option had been changed to instead delete the selected file. Would you still blame the victim for their "self-inflicted injury"?
Are the users updating the only ones wronged or first-time users too? Say you're installing a library for the first time. The library says it does A, you install it and realizes is does B, are you then allowed to sue the author? I guess it depends on how far A is from B and how malicious B is, but the author explicitly stated the code comes with no guarantees. Should anyone that installs "left-pad", but then realize the lib only does right-padding be able to successfully sue the author? The code explicitly comes with no guarantees! It seems very tricky and I'm not sure we can write deterministic black-or-white laws for this, but again, maybe I'm applying a higher standard based on SWE practices for other trades. As far as I know, the legal system is on the hands of politicians who write non-total functions and judges who interpret those functions as they wish.
How so? The license that you accept each time you install or update the library explicitly states:
"IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY [...]"
Use of automation software (npm, yarn) to auto-magically fetch newer versions of your dependencies doesn't absolve you of respecting the terms of the license. Newer versions could have a different license or contain completely different code, there are no guarantees and no contracts.
> It's like if you went to work one day with a spray can hidden in your jacket and started graffitiing the office walls
I don't think that's a good analogy at all. I think this is much closer to the truth:
It's like your boss called you into the office (i.e. explicit software update), gave you a signed waiver that said you couldn't be held liable for anything that you did to the building (i.e. LICENSE) and told you to go crazy (i.e. not auditing the update), so you spray painted the walls and left.
> Would you still blame the victim for their "self-inflicted injury"
No, because professional software developers and end users should be held to a different standard. The fact that you should be auditing your dependencies is well known, precisely because of such scenarios, but people still choose to ignore it because it's inconvenient. This should be the final wake-up call for devs to start pinning and auditing their dependencies.
For the casual end user, replacing functionality of "File > Open" button would be a dick move by the authors, but still within their rights (assuming MIT license).
All in all, developers should be outraged at the state of the NPM ecosystem and their own software development/release practices. He could have easily stolen everyone's AWS access keys and other tokens/secrets if he truly wanted to be malicious.
You can call him an asshole and you'd likely be right, but he was fully within his rights to do what he did.
A license isn't a "get out of jail free" card. If he had put in the license "the authors shall not be liable for murdering you" that would not count as a defence in court.
> doesn't absolve you of respecting the terms of the license.
You don't have to respect any term that isn't legally valid. If you sent someone an email attachment pretending to be spreadsheet, but it actually contained a destructive virus, with an accompanying licence saying "by running this code you agree to accept all the damage done to your computer", that licence would be legally void.
> It's like your boss called you into the office (i.e. explicit software update), gave you a signed waiver that said you couldn't be held liable for anything that you did to the building (i.e. LICENSE)
In this case the person granting the licence is also the one doing the damage, so it's like your boss calling you into his office and informing you that he was going to punch you in the face and that you couldn't sue him. Even if you signed an employment contract which said he could do that, it wouldn't override legislation which criminalises assault. (None of this is legal advice, and there are probably exceptions to all these rules).
> professional software developers and end users should be held to a different standard.
I don't know of any situation where a judge decided that a crime didn't happen because the victim was smart enough that they could have avoided being victimised. It's like saying "well if you didn't want the murderer to break your window and sneak into your house at night and kill your family, then you should have known that was a risk and put bars on the windows". It doesn't matter if someone is a home security expert, or a millionaire, or had any other advantage, it is still a crime to take advantage of someone's less-than-perfect security and murder people.
The whole point of having laws is that we can't put in place guarantees that crimes won't happen, and it makes more sense for society to put in place after-the-fact punishments to provide disincentives against people doing socially negative things. It doesn't matter if you could have prevented someone from harming you, you are still allowed to rely on the legal system to punish the person who causes that harm.
Obviously this is all predicated on whether a DoS attack really does meet the legal definition of "malicious" software, and I don't want to pre-empt what a jury would decide in this specific case, if it ever went to trial, but I think that there is enough evidence of intent and harm here to at least investigate it, and I don't see how a software licence can be used as a defence, any more than the "by accepting this brick through your window" defence, which was jokingly invented during the infamous Sony rootkit incident:
http://www.robhyndman.com/2005/11/22/by-accepting-this-brick...
But that's precisely what he didn't do, isn't it? He just put something up on his GitHub repositories. All the fuckwits who got bit by that, did so by knowingly and voluntarily downloading that stuff, or by knowingly and voluntarily using other software that did so.
colors.js => https://github.com/microsoft/rushstack/issues/3147#issuecomm...
Worst case everyone is going to invent their own wheels, which is beneficiary to all lower-echelon programmers (but not so for managers/tech leads as they have responsibility to ship things) because I as one definitely want to invent as many wheels as possible.
Why is he still using an open for all consumption license and then complaining that billion dollar companies are leeching him? (After hosting his library on said billion dollar company)
There's no other way.
Why? because determining if a package is malicious via static analysis or other automatic means would be the equivalent of creating a solution for the halting problem.
AKA peanuts.
I would think this would discourage a lot of people to contribute to NPM.
It's not about enforcement but the threat.
Maybe you can set a flag in your package.json which enables only the usage of packages from authors that have agreed.
npx depcheck colors
npx depcheck faker> get color and style in your node.js console
A picture is worth a thousand words → https://i.imgur.com/inxA7Pg.png
The library inserts ANSI escape sequences [1] between the text you want to colorize in order to, well, colorize it ¯\_(ツ)_/¯
Many people are obsessed with colors in the Terminal, and so, they reach out to libraries like this. They exist in every major programming language ecosystem, even though colorizing text is as simple as writing this \x1b[48;5;011<TEXT>\x1[0m . One of the disadvantages of this rudimentary colorization technique is that if you have short-term memory, you will quickly forget the meaning of these numbers, but you can solve that problem with constants, there is no reason to install a third-party library with potentially malicious code to add this type of functionality to a high-profile project like AWS-CDK [2].
I wish these libraries would support NO_COLOR [3] more consistently.
I have seen many “modern” CLI tools (the ones people like to build using Rust or Go) overuse colors with no option to disable them.
[1] https://stackoverflow.com/a/33206814
Laziness; and people’s infatuation for dependency trees, especially those in the Node.js & JavaScript ecosystems.
> even though colorizing text is as simple as writing this \x1b[48;5;011<TEXT>\x1[0m
JS devs will do anything to avoid this.
Supply chain attacks are one of the best attack vectors.
So vet your dependencies and assume them malicious.
That advantage may well be indirect such as reputational or learning. I just don’t grasp why people do it for nothing, to the advantage of large companies.
I am getting huge value from the people who built stuff before me. When I build stuff I can (hopefully) make the world better in the future. That's a "tangible, quantifiable advantage" to doing open source. It's just not an advantage to me personally. But lift your gaze an inch off the ground and you'll see we don't need to be ego centric sociopaths. We can build together. For the species. Everyone wins.
I don't know in what fairy tale you live in but the ego-centric billionaire sociopaths that exploit this system wins.
They get: meaning, status, influence, connections, reputation, and opportunities
The free and open nature of their contribution makes it much easier to get all these benefits than they would with a paid and proprietary solution.
It's fun to tinker. It's fun to put things out there into the ether. It's fun to exercise the brain and try new things and learn new ways to do things and publish things. The second it stops being fun, we stop.
Discussions now are about how you shouldn’t run your own server, and you should use popular stuff so you can speed up development and get your startup going.
I mean, I know about ycombinator and all. But it doesn’t seem to truly encompass the hacker spirit, if you ask me.
Necessity is the mother of invention after all.
And you know what? I support this kind of thinking.
I mean, if people can monetize videos on Youtube, shouldn't developers monetize their software too?