The developer of these libraries intentionally introduced an infinite loop that bricked thousands of projects that depend on ’colors and ‘faker’.
I wonder if the person who wrote this actually knows what “bricked” means.
But beyond the problem of not understanding the difference between “bricked” and “broke”, this action did not break any builds that were set up responsibly; only builds which tell the system “just give me whatever version you feel like regardless of whether it works” which like … yeah, of course things are going to break if you do that! No one should be surprised.
Edit: for those who are not native English speakers, “bricked” refers to a change (usually in firmware on an embedded device) which not only causes the device to be non-functional, but also breaks whatever update mechanisms you would use to get it back into a good state. It means the device is completely destroyed and must be replaced since it cannot be used as anything but a brick.
GitHub has reportedly suspended the developer’s account
Hopefully this serves as a wakeup call for people about what a tremendously bad idea it is to have all your code hosted by a single company. Better late than never.
There have been plenty of wakeup calls for people using Github, and I doubt one additional one will change the minds of very many people (which doesn’t make it any less of a good idea for people to make their code hosting infrastructure independent from Github). The developer was absolutely trolling (in the best sense of the word) and a lot of people have made it cleared that they’re very eager for Github to deplatform trolls.
I don’t blame him certainly; he’s entitled to do whatever he wants with the free software he releases, including trolling by releasing deliberately broken commits in order to express his displeasure at companies using his software without compensating him in the way he would like.
The right solution here is for any users of these packages to do exactly what the developer suggested and fork them without the broken commits. If npm (or cargo, or any other programming language ecosystem package manager) makes it difficult for downstream clients to perform that fork, this is an argument for changing npm in order to make that easier. Build additional functionality into npm to make it easier to switch away from broken or otherwise-unwanted specific versions of a package anywhere in your project’s dependency tree, without having to coordinate this with other package maintainers.
The developer was absolutely trolling (in the best sense of the word)
To the extent there is any good trolling, it consists of saying tongue-in-cheek things to trigger people with overly rigid ideas. Breaking stuff belonging to people who trusted you is not good in any way.
I don’t blame him certainly; he’s entitled to do whatever he wants with the free software he releases, including trolling by releasing deliberately broken commits in order
And GitHub was free to dump his account for his egregious bad citizenship. I’m glad they did, because this kind of behavior undermines the kind of collaborative trust that makes open source work.
to express his displeasure at companies using his software without compensating him in the way he would like.
Take it from me: the way to get companies to compensate you “in six figures” for your code is to release your code commercially, not open source. Or to be employed by said companies. Working on free software and then whining that companies use it for free is dumbshittery of an advanced level.
It’s not foolish to trust, initially. What’s foolish is to keep trusting after you’ve been screwed. (That’s the lesson of the Prisoner’s Dilemma.)
A likely lesson companies will draw from this is that free software is a risk, and that if you do use it, stick to big-name reputable projects that aren’t built on a house of cards of tiny libraries by unknown people. That’s rather bad news for ecosystems like node or RubyGems or whatever.
Not if you’re being responsible and pinning your deps though?
Even if that weren’t true though, the maintainer doesn’t have any obligation to companies using their software. If the company used the software without acquiring a support contract, then that’s just a risk of business that the company should have understood. If they didn’t, that’s their fault, not the maintainer’s - companies successfully do this kind of risk/reward calculus all the time in other areas, successfully.
I know there are news reports of a person with the same name being taken into custody in 2020 where components that could be used for making bombs were found, but as far as I know, no property damage occurred then. Have there been later reports?
Yeah, like proprietary or in-house software. Great result for open source.
Really, if I were a suit at a company and learned that my product was DoS’d by source code we got from some random QAnon nutjob – that this rando had the ability to push malware into his Git repo and we’d automatically download and run it – I’d be asking hard questions about why my company uses free code it just picked up off the sidewalk, instead of paying a summer intern a few hundred bucks to write an equivalent library to printf ANSI escape sequences or whatever.
That’s inflammatory language, not exactly my viewpoint but I’m channeling the kind of thing I’d expect a high-up suit to say.
in order to express his displeasure at companies using his software without compensating him in the way he would like.
This sense of entitlement is amusing. This people totally miss the point of free software. They make something that many people find useful and use (Very much thanks to the nature of being released with a free license, mind you), then they feel in their right to some sort of material/monetary compensatiom.
This is not miss universe contest. It’s not too hard to understand that had this project been non free, it would have probably not gotten anywhere. This is the negative side of GitHub. GitHub has been an enormously valuable resource for free software. Unfortunately, when it grows so big, it will inevitably also attract this kind of people that only like the free aspect of free software when it benefits them directly.
This people totally miss the point of free software.
An uncanny number of companies (and people employed by said companies) also totally miss the point of free software. They show up in bug trackers all entitled like the license they praise in all their “empowering the community” slides doesn’t say THE SOFTWARE IS PROVIDED “AS IS” in all fscking caps. If you made a list of all the companies to whom the description “companies that only like the free aspect of free software when it benefits them directly” doesn’t apply, you could apply a moderately efficient compression algorithm and it would fit in a boot sector.
I don’t want to defend what the author did – as someone else put it here, it’s dumbshittery of an advanced level. But if entitlement were to earn you an iron “I’m an asshole” pin, we’d have to mine so much iron ore on account of the software industry that we’d trigger a second Iron Age.
This isn’t only on the author, it’s what happens when corporate entitlement meets open source entitlement. All the entitled parties in this drama got exactly what they deserved IMHO.
Now, one might argue that what this person did affected not just all those entitled product managers who had some tough explaining to do to their suit-wearing bros, but also a bunch of good FOSS “citizens”, too. That’s absolutely right, but while this may have been unprofessional, the burden of embarrassment should be equally shared by the people who took a bunch of code developed by an independent, unpaid developer, in their spare time – in other words, a hobby project – without any warranty, and then baked it in their super professional codebases without any contingency plan for “what if all that stuff written in all caps happens?”. This happened to be intentional but a re-enactment of this drama is just one half-drunk evening hacking session away.
It’s not like they haven’t been warned – when a new dependency is proposed, that part is literally the first one that’s read, and it’s reviewed by a legal team whose payment figures are eye-watering. You can’t build a product based only on the good parts of FOSS. Exploiting FOSS software only when it benefits yourself may also be assholery of an advanced level, but hoping that playing your part shields you from all the bad parts of FOSS is naivety of an advanced level, and commercial software development tends to punish that.
They show up in bug trackers all entitled like the license they praise in all their “empowering the community” slides doesn’t say THE SOFTWARE IS PROVIDED “AS IS” in all fscking caps
Slides about F/OSS don’t say that because expensive proprietary software has exactly the same disclaimer. You may have an SLA that requires bugs to be fixed within a certain timeframe, but outside of very specialised markets you’ll be very hard pressed to find any software that comes with any kind of liability for damage caused by bugs.
Well… I meant the license, not the slides :-P. Indeed, commercial licenses say pretty much the same thing. However, at least in my experience, the presence of that disclaimer is not quite as obvious with commercial software – barring, erm, certain niches.
Your average commercial license doesn’t require proprietary vendors to issue refunds, provide urgent bugfixes or stick by their announced deadlines for fixes and veatures. But the practical constraints of staying in business are pretty good at compelling them to do some of these things.
I’ve worked both with and without SLAs so I don’t want to sing praises to commercial vendors – some of them fail miserably, and I’ve seen countless open source projects that fix security issues in less time than it takes even competent large vendors to call a meeting to decide a release schedule for the fix. But expecting the same kind of commitment and approachability from Random J. Hacker is just not a very good idea. Discounting pathological arseholes and know-it-alls, there are perfectly human and understandable reasons why the baseline of what you get is just not the same when you’re getting it from a development team with a day job, a bus factor of 1, and who may have had a bad day and has no job description that says “be nice to customers even if you had a bad day or else”.
The universe npm has spawned is particularly susceptible to this. It’s a universe where adding a PNG to JPG conversion function pulls fourty dependencies, two of which are different and slightly incompatible libraries which handle emojis just in case someone decided to be cute with file names, and they’re going to get pulled even if the first thing your application does is throw non-alphanumeric characters out of any string, because they’re nth order dependencies with no config overrides. There’s a good chance that no matter what your app does, 10% of your dependencies are one-person resume-padding efforts that turned out to be unexpectedly useful and are now being half-heartedly maintained largely because you never know when you’ll have to show someone you’re a JavaScript ninja guru in this economy. These packages may well have the same “no warranty” sticker that large commercial vendors put on theirs, but the practical consequences of having that sticker on the box often differ a lot.
Edit: to be clear, I’m not trying to say “proprietary – good and reliable, F/OSS – slow and clunky”, we all know a lot of exceptions to both. What I meant to point out is that the typical norms of business-to-business relations just don’t uniformly apply to independent F/OSS devs, which makes the “no warranty” part of the license feel more… intense, I guess.
The entitlement sentiment goes both ways. Companies that expect free code and get upset if the maintainer breaks backward compatibility. Since when is that an obligation to behave responsibly?
When open source started, there wasn’t that much money involved and things were very much in the academic spirit of sharing knowledge. That created a trove of wealth that companies are just happy to plunder now.
releasing deliberately broken commits in order to express his displeasure at companies using his software without compensating him in the way he would like.
Was that honestly the intent? Because in that case: what hubris! These libraries were existing libraries translated to JS. He didn’t do any of the hard work.
There is further variation on the “bricked” term, at least in the Android hacker’s community. You might hear things like “soft bricked” which refers to a device that has the normal installation / update method not working, but could be recovered through additional tools, or perhaps using JTAG to reprogram the bootloader.
There is also “hard bricked” which indicates something completely irreversible, such as changing the fuse programming so that it won’t boot from eMMC anymore. Or deleting necessary keys from the secure storage.
this action did not break any builds that were set up responsibly; only builds which tell the system “just give me whatever version you feel like regardless of whether it works” which like … yeah, of course things are going to break if you do that! No one should be surprised.
OK, so, what’s a build set up responsibly?
I’m not sure what the expectations are for packages on NPM, but the changes in that colors library were published with an increment only to the patch version. When trusting the developers (and if you don’t, why would you use their library?), not setting in stone the patch version in your dependencies doesn’t seem like a bad idea.
When trusting the developers (and if you don’t, why would you use their library?), not setting in stone the patch version in your dependencies doesn’t seem like a bad idea.
No, it is a bad idea. Even if the developer isn’t actively malicious, they might’ve broken something in a minor update. You shouldn’t ever blindly update a dependency without testing afterwards.
Do you really think that a random developer, however well intentioned, is really capable of evaluating whether or not any given change they make will have any behavior-observable impact on downstream projects they’re not even aware of, let alone have seen the source for and have any idea how it consumes their project?
I catch observable breakage coming from “patch” revisions easily a half dozen times a year or more. All of it accidental “oh we didn’t think about that use-case, we don’t consume it like that” type stuff. It’s truly impossible to avoid for anything but the absolute tiniest of API surface areas.
The only sane thing to do is to use whatever your tooling’s equivalent of a lock file is to strictly maintain the precise versions used for production deploys, and only commit changes to that lock file after a full re-run of the test suite against the new library version, patch or not (and running your eyeballs over a diff against the previous version of its code would be wise, as well).
It’s wild to me that anyone would just let their CI slip version updates into a deploy willynilly.
This neatly shows why Semver is a broken religion: you can’t just rely on a version number to consider changes to be non-broken. A new version is a new version and must be tested without any assumptions.
To clarify, I’m not against specifying dependencies to automatically update to new versions per se, as long as there’s a CI step to build and test the whole thing before it goes it production, to give you a chance to pin the broken dependency to a last-known-good version.
Semver doesn’t guarantee anything though and doesn’t promise anything. It’s more of an indicator of what to expect. Sure, you should test new versions without any assumptions, but that doesn’t say anything about semver. What that versioning scheme allows you to do though is put minor/revision updates straight into ci and an automatic PR, while blocking major ones until manual action.
Amazon does this. Almost no-one else does this, but that’s a choice with benefits (saving the set up effort mostly) and consequences (all of this here)
I think it is bannable on any platform, because it is malicious behavior - that means he intentionally caused harm to people. It’s not about an exchange of money, it’s about intentional malice.
The behavior was intentionally malicious. It’s not about violating a contract or guarantee. For example, if he just decided that he was being taken advantage of and removed the code, I don’t think that would require a ban. But he didn’t do that - he added an infinite loop to purposefully waste people’s time. That is intentional harm, that’s not just providing a library of poor quality with no guarantee.
Beyond that, if that loop went unnoticed on a build server and costed the company money, I think he should be legally responsible for those damages.
I understand it wasn’t a nice thing to do, and that people are upset, but it’s his own code in his own repos. He even announced ahead of time he would do something like this, so “buyer” beware.
I realize GitHub TOS covers them to remove accounts and repos at their discretion, but it’s a little unsettling that they’ll actually do so arbitrarily without a clear TOS violation. It might be time I move everything to Sourcehut and treat GitHub as a mirror…
The Sourcehut guy has always seemed a little unstable to me (didn’t he get banned from this site, in fact?) So, why would I trust him any more than I trust GitHub?
I banned him and I would not call him unstable. Not just because that kind of insult is inappropriate here, but because it obviously doesn’t apply. He writes inflammatory hyperbole that’s not a good fit for this site, but he’s a skilled, accomplished professional who looks like he’s seeing a lot of success in his life.
I didn’t mean to insult him. Maybe “erratic” would have been a better word without any mental health connotations (which I absolutely didn’t intend)? Poor word choice on my part, I’m sorry for that.
…but he’s a skilled, accomplished professional who looks like he’s seeing a lot of success in his life.
Sure, same goes for the GitHub guys. A person who can’t tone it down enough to keep a Lobsters account just isn’t someone I feel I can trust to host my code, particularly given that he’s in charge of the whole operation. Obviously everyone is free to decide who to trust and for what reasons.
A person who can’t tone it down enough to keep a Lobsters account just isn’t someone I feel I can trust to host my code
Bear in mind, Linus Torvalds would also probably have been banned from here multiple times in the past.
I’d be perfectly happy to trust someone that volatile a lot (and I guess I do, running Linux since 1996 :) ). But I would be careful which groups and forums I invited them to :)
Very different, at least to me. If Linux was a service, control would have been taken away from Linus a long time ago (I mean, as it is they made him step back for awhile to work on his issues). But it’s not, it’s just code that other people then build into something, often applying patches in the process. If Linus had a meltdown there is already sufficient infrastructure in place that the vast majority of us wouldn’t even notice.
I wouldn’t trust a code hosting service Linus ran by himself either.
Nobody made Linus step back. He recognized that he had issues and took a sabbatical to deal with them himself. Are you saying you wouldn’t trust a service by a guy who has been diligently working on the same project for 30 years? Not to mention the guy who invented the base of all of the services discussed in this thread.
Why do people assume that “Bigger is better” when it comes to web services? The two most reliable services I use are Pinboard, run by an insanely opinionated and outspoken developer, and NewsBlur, who was, and may still be, a one man shop that just quietly does his own thing. In the same time as those services have been faithfully up and running, Google has shut down more services than I can count, because “It didn’t fit with their corporate vision”
We’ll probably never know for sure, but the subtext (well, and the text) of his announcement email sure makes it sound like his hand was forced, at least to me.
Are you saying you wouldn’t trust a service by a guy who has been diligently working on the same project for 30 years?
No, I’m saying I wouldn’t trust a service run by a guy who randomly goes off on people in totally inappropriate ways (his admission). Or, as is the case here, a guy who can’t even behave himself well enough to keep a Lobsters account.
Not to mention the guy who invented the base of all of the services discussed in this thread.
That has literally nothing to do with anything. A person can be productive or brilliant and also have other, undesirable, qualities.
Why do people assume that “Bigger is better” when it comes to web services?
I don’t, so I can’t answer that.
Google has shut down more services than I can count…
Agree with you there! I don’t trust Google for anything but search (I don’t even use Gmail), because that’s the one thing I don’t think they’ll ever kill (or break). I don’t think GitHub is going anywhere either, the worst case scenario is that Microsoft sells it.
It’s misguided, and harmful.
If there was a person who had the views you seem to ascribe to me, then I might agree!
That’s unfair to Drew. He’s passionate, and rude, and opinionated, and submissions here from his site generally stirred up giant flamewars. But I do believe he’s got what it takes to keep sourcehut running.
Not only is the sourcehut software available under the AGPL, the issue trackers and such give you export and import functions to pull your data into another instance easily. The software itself is not trivial to host, but it’s not prohibitively hard either. If I needed to eject because Drew became untrustworthy, I am very comfortable that I could do that.
Even though that’s a non-zero amount of work, GitHub gives me no comparable ability. That’s a good reason to trust him more than I trust GitHub, in my opinion.
The GitHub command line client provides this functionality, as does the API. Obviously, the data formats are specific to the way GH works, but there are ways to extract most if not all of the relevant data (I use this heavily with my team to script up our findings workflow, for example).
Interesting. Unless I’m missing something, you can’t stand up your own self-hosted instance of github, and import that, can you? The ability to stand up my own instance of the forge and import my data, to use on a self-hosted site, is what I meant by “comparable”. (That’s the angle I was coming from… if Drew won’t let me use his hosted service, I can just set up my own copy on any host I want since upstream is AGPL, then import my data from the sr.ht export since sr.ht exposes those functions.)
GitLab supports importing to a self-hosted instance from GitHub [1], although I’m sure it’s not perfect, so it may or may not be useful. It also isn’t clear to me based on a 15 second review whether you can import from some kind of local data dump or raw GitHub API responses or if your GitHub account needs to be currently active.
That looks much better than I thought, particularly if it turns out to work off saved data/responses. And it’s nice that Gitlab enable that for all their tiers.
Unless I’m missing something, you can’t stand up your own self-hosted instance of github, and import that, can you?
GitHub Enterprise can be bought as a GitHub-hosted or self-hosted thing. These support (most of) the same APIs as the public GitHub, so you can run your own instance if you are willing to pay.
It would be an interesting experiment to see whether they would sell an enterprise installation to someone whose account they forcibly closed. I was sort of assuming that if they won’t let you be a customer of their public service, they won’t sell you the private one, but that is uninformed speculation.
Because sourcehut is open source so nothing is lost when I leave. More than that chances are if sourcehut goes a bad route there would likely be others jumping in.
Not that you exactly claim otherwise, but Drew also makes some nice things and has created a business structure that enables at least one other developer to make some nice things.
Quite apart from that, though, and similarly quite apart from whether he has what it takes to keep sourcehut running, he’s given me an out so that I don’t, strictly speaking, need him to. He’s released the software that runs the forge under the AGPL, here. And it exposes ways for me to export the hosted stuff and import it into a self-hosted instance.
So regardless of whether I trust Drew personally, he’s made it so I don’t need to for this purpose.
If Drew got angry and decided I couldn’t be his customer anymore, I could stand up my own instance or pay someone to do that for me and import my data. My repos wouldn’t be down at all, my tickets, docs, etc. would be down for a day or so, and my mailing lists might see a bit more disruption than that. If github decided that I shouldn’t be their customer anymore, I’d have my repos. For the rest, I’d kind of be out of luck. (I think this last paragraph is more responsive to @glesica ‘s comment than the one I’m replying to, and I’m too lazy to split it to another reply.)
Consider hosting your own, instead. I published a blog post with a list of defunct code hosting sites which I update occasionally. Maybe that list is a good reminder. Remember, it’s not just code that goes away with such sites, it’s also issue queues and in some cases, wikis and mailing lists too.
Are you also start hosting a list of defunct private websites that used to host Git repos that are gone forever and where the disappearence came completely unexpected? I would trust Github more with staying online since that’s their job than a developer running a Gitweb on some VPS with some domain name that requires regular payment to stay online.
Kinda like I registered callcc.org after it lapsed to make sure the links to the CHICKEN website don’t break and it doesn’t get domain-squatted and I’m redirecting to the official website these days.
Are you also start hosting a list of defunct private websites that used to host Git repos that are gone forever and where the disappearence came completely unexpected?
I can’t think of anything offhand where I’ve taken a dependency that’s done that. But when I do take a dependency on something, I generally mirror the SCM repo if there is one. And I am very reluctant to take dependencies on things I can’t have the source to. Since the things I depend on generally haven’t gone away, I haven’t bothered to publish my mirrors, but I would if the license permits it.
But when I do take a dependency on something, I generally mirror the SCM repo if there is one.
I learned that the hard way when Rubyforge went down, a few employers ago. We weren’t that active in the Ruby community anymore, so we missed the notice. When the site went away and I had to do some small maintenance tasks on a legacy project, all the third party svn subtrees from Rubyforge were no longer working (and, more painfully, another project of ours was completely gone too). Note that Rubyforge was huge in the Ruby community back in the day.
I would trust Github more with staying online since that’s their job than a developer running a Gitweb on some VPS with some domain name that requires regular payment to stay online.
Like I said, history has shown these hosting sites are not as trustworthy as people like to believe they are. The GitHub company can get sold to an untrustworthy partner (har har, like that’d ever happen… oh wait) or go out of business (what if MS decides to sell the company to, I dunno, Oracle or something because it’s not making a profit?), or there might be some other new VCS that comes out that completely blows git out of the water. I’m sure nobody saw coming what happened to Bitbucket - it started out as a Mercurial hosting site, then started offering git and finally dropped Mercurial after Atlassian took over. Its founders probably never would have let that happen if it were still in their power.
From my own perspective, I’ve personally ran into at least five hosting sites who were hosting projects I started or heavily contributed to that are no longer available now (Rubyforge, Dutch govt OSOSS’ uitwisselplatform, Berlios, Bitbucket and Google Code). And then there’s Sourceforge which at least still hosts some of my defunct projects, but had for a while been injecting malware into downloads. If I or my employers (as the case may be) had hosted our own projects from the start, this pain would’ve been completely avoided. These are projects in which I had a stake, and it was in my interest to not let them die.
Now, having said that, I agree that from a third party perspective (someone who is using the hosted code) that’s different. I understand your point saying you don’t want to rely on some random developer’s VPS being up, and neither would I. But then, people change repositories on code hosting sites all the time, too. They move to other hosting sites, or rename repositories etc. Links rot and die, which is unfortunate and something we all have to live with.
Case in point:
Kinda like I registered callcc.org after it lapsed to make sure the links to the CHICKEN website don’t break and it doesn’t get domain-squatted and I’m redirecting to the official website these days.
Thanks for doing that. AFAIK this domain was never communicated as being official, but I might be wrong.
I don’t know what the GitHub rationale was, but the ‘limitation of liability’ bit in most open source licenses only goes so far. If I intentionally introduce malicious behaviour into one of my open source projects, knowing that it would damage downstream consumers, then I’d probably be liable under the Computer Misuse Act in the UK and similar legislation elsewhere. GitHub’s T&C’s don’t explicitly prohibit using their service for criminal purposes but that’s normally implicit: if GitHub didn’t act then they might end up being liable as an accessory (at least as an accessory after the fact). Their distribution channel (NPM) is being used by a malicious actor to attack other users.
It’s normally difficult to prove malicious intent in this kind of thing (incompetence and malice look similar) but it seems pretty clear here from the author’s own statements.
I don’t know what the GitHub rationale was, but the ‘limitation of liability’ bit in most open source licenses only goes so far.
This is disturbing. Software is provided as is, with no liability whatsoever, but the author should still be liable for what happens when other people use it, because it broke things?
What if the author decided to completely change the library’s API, or recycle it to just print squares of color, because they liked the name?
If find what the author did pretty stupid, but frankly, suggesting it falls into criminal behavior call for some stepping back and put things in perspective.
There is a difference, and it’s not subtle at all, between making a possibly unwanted change in software that is provided without any warranty, and deliberately making a crippling change with the express intent of breaking other people’s applications.
To put it another way: if you accidentally commit an integer overflow bug that causes batteries to blow up, that is, presumably, just bad engineering. But if you deliberately commit a clever hack that causes people’s batteries to blow up, with the express intent of getting people injured, or at least destroying their phones, I think it makes a little sense to not put it under “well, it did say no warranty of any kind on the box, didn’t it?”.
Obviously, this didn’t kill anyone, so I’m obviously not thinking it ought to be treated as murder. But “no warranty” is not a license to do anything.
It’s not like software is being given special treatment here, it’s how warranties work everywhere. If you sell boats with two years’ servicing warranty and they break down after three years, that’s one thing, but if you fit them with bombs that go off after two years and one day, with the express intent of killing anyone on them, that still falls under “murder”, not “what happens after two years isn’t our problem, it says so on the purchase contract”.
(Edit: obviously IANAL and this is not legal advice, either, I’m only parroting second-hand, non-lawyer advice about how insurance works for some high-stakes software projects)
My understanding is that it comes down to intent. If I upload a buggy piece of crap to GitHub with an open source license, and you use it, then it sucks to be you. If I upload something to GitHub, wait for you to deploy it and then intentionally introduce a vulnerability or other malicious behaviour in it then legally dubious. Normally it’s very difficult to prove intent. If I submit a patch to the Linux kernel that introduces a vulnerability, if you wanted to prosecute me then you’d have to prove that I did so knowing that the bug was there and with the intent to cause harm. That’s very difficult to do in the general case (the NSA null-pointer dereference bugs are a great case in point here: people suspect that the NSA knew about that vulnerability class and introduced it deliberately, but no one can prove it and there’s enough reasonable doubt that it would never stick in court unless there was some corroborating evidence - it could easily have been accidental). If, before I submit the patch, I post publicly about how I am going to intentionally break things for the people using my code and then I push a new version out to public repositories then it’s likely to be easy to prove malicious intent. The author of these packages did exactly that: posted saying that he was going to break things for people if they didn’t pay him and then, when they didn’t pay him, broke things. That may (again, not a lawyer) count as blackmail, as well as computer misuse.
Liability could only be disclaimed to the extent permitted by law. You cannot put a sign “free food, no liability whatsoever” and then put poison inside and expect that disclaimer to save you from prison. E.g., GPL states “THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.”
I think until they make a statement about it, nobody knows but them. But my assumption is that this happened on a weekend, and whoever was on call figured that the easiest thing to do to minimize disruption till Monday was to suspend the account and hard revert the content until more people could be brought in. I’m also assuming suspending the account just automatically says that you violated the ToS.
The author must feel very spiteful, to retroactively turn his gift into not only a transaction but a trap. I think it’d be better to learn a lesson about setting healthy boundaries when you decide to give of yourself so you don’t feel that others took advantage of you.
This. So much this. Also, it is quite possible the author is letting themselves be influenced too much by others’ whinging about companies using their free software for free.
On the one hand, it’s true that FLOSS is “under-sponsored” for the critical role some of it plays (and a color library and random value generator probably doesn’t fall in that category to begin with), but on the other hand all the attention this is getting lately is creating a lot of sour grapes and feelings of being wronged by corporations among developers. But these same developers are forgetting they originally created their software out of love/intellectual curiosity/boredom/whatever, yet they expect to get paid by people who never asked for the software in the first place. Of course, businesses now they are more than happy to use it while it’s there. Why wouldn’t they?
I wonder how a free software author defines success. Just making the contribution and feeling good about that? Seeing it used in a lot of places? Recognition? Patreon subscribers? It must be different for everybody, but I suspect there is some missing link here by which the author’s real goals were left unfulfilled.
But these same developers are forgetting they originally created their software out of love/intellectual curiosity/boredom/whatever, yet they expect to get paid by people who never asked for the software in the first place.
They didn’t ask for it, but they sure feel free to unilaterally prop a critical piece of their infrastructure solely on top of it, and then make millions, without paying a dime back.
Why wouldn’t they?
Well exactly, and that’s a fundamental flaw in “Open Source” as opposed to Free Software (Which to be honest, I also can’t fully agree with). Open Source was created from the start to exploit developers who were making things for other developers. It said, in big letters, “You can make money off people’s hard labour, and not have to pay them anything!”. How is that not exploitation? In any capitalist system it’s the sole definition of it! We have hundreds of thousands of pages and millions, perhaps billions, of words in our legal framework stating explicitly that people should get paid for their labour when they do work. It is, very literally, the only reason why copyright and patents exist in the first place – from the idea that, when people do work, the deserve compensation so that they can continue to exist.
Now, you can claim that they get paid through popularity, but how does that help the person tangibly? I can create a huge 1k, 10, 100k starred repo on Github, but I still have to go through the same interview process as anyone else. Except now I am (apparently) bound to maintain and document and correctly deploy my own personal projects, just because some fool at Microsoft decided it was a good idea to rest a chunk of their software stack on it?
But no, you are right, people should start choosing LICENSE files that deliberately do not give rights to companies unless there is financial exchange. It’s the only way that they will learn.
It’s more the fault of the downstream developers and companies, though, isn’t it? They decided to take someone’s code, use it to make money, and not throw a penny in their direction. It was the ‘Open Source’ philosophy that decide to turn “Here is a gift to my fellow developers” into “Here is a project I put my sweat and labour into, feel free to exploit it with no regard for the cost”, and people bought into it wholesale.
This repo was owned solely by the person who wrote it, and there’s no reason they have to consider downstream projects that they might not even be aware of, when they make changes to their code. I am not arguing for the guy, but I absolutely think his act here was justified, and a positive thing in the long run. There’s a reason for a liability waiver in the LICENSE file and if you’re just going to take code and ignore that liability waiver, then that’s up to you, buddy. Doubly so if you’re a tech lead and you’re evaluating the dependencies your company is going to use to build stuff, right at the start.
Hopefully, rather than blaming this on one erratic individual, companies will start paying money upstream to the projects that they make money off of. But I doubt it.
I don’t disagree that the license makes no guarantees, but that’s an unconvincing technicality when it comes to relating to one another as humans. The libraries were offered because they were useful, they were accepted in good faith, and then they were sabotaged in bad faith. To the author it may have felt like a righteous protest, but from the outside it just looks like taking your ball and going home.
I’ll add, Snyk flagged at least one of these libraries as vulnerable to DDOS today because of its deliberate infinite loop. That’s malware in my book, and that’s crossing a line.
I feel like if you’re going to impose an unstated and explicitly disclaimed responsibility (attempting to release only useful software) on the developer as a condition of good faith bargaining, it’s only fair to expect some compensation in consideration, particularly given the developer asked as much a year ago from what I recall. It’s still reasonable, in that good faith universe, to leave it under the MIT license to allow users to pay what they feel is fair.
But the reality is this is exactly why businesses use contract and licensing language to expressly indicate what parties can count on one another for. Good faith, in that world, means adhering to the spirit of that language, and in this case that language clearly indicated the developer could do whatever they wanted with the library and that anyone consuming it should be on notice to verify that it did what they wanted. For what it’s worth, that cuts both ways - GitHub is also acting in the spirit of the MIT license by continuing to distribute the older version, despite the developer’s wishes.
The malware thing is a good point though - I was under the impression this was breaking deployments and potentially causing downtime, both of which are in my opinion reasonable consequences of using something unreliable. But if the infinite loop introduced the ability for remote users to trigger downtime that’s subtly different in a way I agree crosses some kind of line.
Given that the owner of the colors.js repository replied to that Gist with a thank you, I think we can call it confirmed it is the same person. I don’t know about the Reuters article but it looks conceivable it was the same. Even if the latter turns out to be a different chap of the same name it seems like the FOSS world will be better off without relying on code from such a loose cannon.
Most elements of this seem to have worked out exactly as they should.
A developer creates software and releases it under an MIT license on GitHub, allowing it to be freely used and reach a wide audience, and maintains the software. Obviously they’re not doing it for money, but perhaps for reputation, experience, whatever.
Corporations use the software, paying what the developer asked - nothing.
The developer later changes their mind about what they want and alters the software. The changes do nothing particularly malicious - they just stop the software from doing the thing it was supposed to do. Obviously, they never signed on to any obligation to continue providing the software, as the license makes clear.
GitHub reverts the change and continues distributing the older version, which the MIT license clearly allows them to do, and locks access to the developer’s account, which GitHub’s ToS also clearly allow them to do.
Social media uproar happens, at least some of it aimed at changing GitHub’s mind about what they actually want to do.
In none of these events were there any real surprises - all of these actions were things that everybody involved should have been aware were reasonable possibilities.
The only real misstep here seems to have been on the part of organizations that didn’t just use the software, but clearly didn’t understand what they were getting into. Automated deployments to production directly from a third-party repo are madness, and that’s what I understand to have caused problems. If I’m wrong, please ignore the rest of this post and/or shame me for my ignorance.
If you have the resources to do automated deployments, your CI/CD pipeline should be pulling from a locally hosted copy that’s been validated in testing and only updated with new versions that have also been validated. If you don’t have those resources, no automated activity should have caused a deployment so this shouldn’t have caused anything more than brief befuddlement during manual development/testing. In any case, without contractual or licensing language that gives assurances otherwise, no organization should be using third-party code without budgeting for the possibility that it could spontaneously and suddenly fail.
Is that completely unsustainable in modern software development environments? Yes, probably. Businesses that pay developers have created a situation where it’s impossible to do the job properly, but then again software developers perpetuate that by agreeing to do their best under the circumstances. It’s hard to say where the blame should fall, though I would mainly lay it on corporations for thinking any of this was a good idea. High growth, high risk, I guess. The only reason it works so well as it does is because of just how effective trust and social forces are in the economy, but now I’m getting really off-topic so I’ll call it a post.
I understand that this is the last event in a long series, but when he refused in 2020 to stop supporting big corporations, why didn’t he change the license to a more restrictive one? To my knowledge, there are many big companies allergic to the GPL family of license, which would have lead to the wished outcome.
He didn’t even need to change the license file in the main, he could have just modified the license file to explicitly exclude companies by name, by market cap, by country, by any arbitrary condition he wanted. It would no longer have been considered an open source license by any definition of the term, but it would have been usable by everyone he wanted to use it.
Step two though, would have been license violation detection, which is a whole different issue, especially once the JavaScript gets minified. And we haven’t even gotten to enforcement.
This stuff is tricky and I believe in doing the right thing. But it is very easy for any company to do the wrong thing, intentionally or not. If you really really care about company’s not using your code, you might want to just consider not open sourcing.
I have a feeling this isn’t as much about companies not wanting to use your software as it is about getting paid for your work.
Which of course is tricky given the trivial nature of many of these packages: Yes. It’s very convenient to use a pre-existing package for emitting colors on the console, but also, yes, it’s much easier to either not emit colors or to quickly hack up something to emit the requires ANSI color bytes rather than going through all of the red-tape to get the author of that package paid.
And even if you do: The functionality offered by such a relatively simple package can be implemented by an engineer in less than a day, so as a company I’m wondering how much I’m actually willing to pay for this.
It gets worse though: While the packages in question were certainly downloaded by some big companies CI systems, it’s not even clear whether this was a direct dependency of their software. This might have very well been a package used by a package used by a package of some (much more high-value) dependency of theirs which they actually might be sponsoring in one way or another.
So is it now the expectation of open source projects which accept sponsorships to then further pay off all their dependencies? And their dependencies dependencies? What percentage of your income should you forward downstream?
Not to forget about who is deciding about what deps should be added to a library? Is it acceptable to add colored text output to a build tool? How necessary is it? Did anyone asked for it or did they added so the coloring lib can demand it’s share?
Is it acceptable to add colored text output to a build tool
that’s up to the build tool author to decide, but I would argue that nowadays it’s not just acceptable but required to be competitive with other build tools. It sucks, but that’s the world we live in. Bling sells.
But it should not matter for the Fortune 500 company C using (and sponsoring) build tool B whether that tool also happens to have library L as its dependency and whether that dependency is compensated for their effort.
You can’t expect company C to be going through the whole dependency graph of B and add micro-sponsorings to each of those deps, even more so as I would assume the author of library L wouldn’t be happy with whatever percentage of the sponsoring pie they would get from company C even though colored output on the command-line is only a tiny subset of their usage of B and possibly even disabled on the CI (but still downloaded).
So the author would still be disgruntled and this would still happen.
I fear the same thing happening in the Rust ecosystem some day, because you quickly pull in a non-trivial number of small libs even for a simple project, and most of them are hosted on GitHub and maintained often by separate individuals or small groups. I know there is version pinning, but how well is this followed? This might be a good idea for an explorative analysis, and maybe someone can say more about this concern, which probably has been addressed in some way.
As a side note, many think the circumstances of Aaron Swartz’ death raise a lot of questions, to put it lightly.
The rust ecosystem has a tool enforced rule that for all crates hosted by crates.io, all rust dependencies are also hosted by crates.io. Technically you can have a build.rs that manually downloads things from github (or elsewhere), but that is incredibly rare.
I know there is version pinning, but how well is this followed
Every time you run a build, it generates a Cargo.lock file pinning the version. Most people developing binaries commit this, that’s what the default .gitignore encourages, so it’s followed pretty well.
Dependencies update when you run cargo update, and not automatically. It’s not foolproof: if you don’t preserve Cargo.lock and use CI/Docker that naively wipes all state away, you’re going to get fresh(est) deps every time.
crates.io is lucky that it’s a step behind npm, so it can learn from npm’s mistakes. For example, from the start it prevented left-pad incidents by not deleting any packages (yanking only hides packages from UI, not direct downloads).
But it’s only a matter of time before the next big mess happens on crates.io too. Sadly, crates.io is understaffed, so there are several features/mitigations it probably should have, but hasn’t got yet.
There’s cargo-crev that aims to create a set of manually-verified trustworthy packages, but crates.io is growing by 70 releases a day, so it’s hard to keep up.
I think the feature is inherent. If you’re downloading stuff in apt, you’re trusting the people packaging that application (and their download servers). If you’re installing stuff manually, you’re trusting the people where you download it. And if you’re developing things you’ll have to trust the developers. And I’m certain at each of these steps are many “hidden dependencies” you don’t actually realize when downloading. It will fail somewhere in the future, and people will rally about how bad crates.io is, while the rest of the world moves on.
Automatic generated for all builds, should be committed for all applications:
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3
[[package]]
name = "actix-codec"
version = "0.4.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "13895df506faee81e423febbae3a33b27fca71831b96bb3d60adf16ebcfea952"
[...]
Today I was being polite and held the door for someone, but they looked like they wouldn’t be paying me for doing that, so I slammed the door at them and broke their fucking face. I can’t believe anybody is endorsing this behavior.
I hold the door open for you but my hand slips and it shuts on you and you get hurt. This is the kind of scenario where the disclaimer of warranty in most open source licenses covers: you made a best-effort attempt to do the nice thing, you failed, and someone got hurt.
I hold the door open for you and then slam it in your face as you get here. This is actively malicious behaviour that causes actual harm. In the metaphor, this would likely be covered by something like actual bodily harm. In the scenario in the article, this is likely covered by computer misuse laws. No disclaimer of warranty protects you.
I just want to address one line in the “Dependency Risk and Funding” post:
Daniel Stenberg of curl doesn’t wield that power (and probably also doesn’t want to).
Knowing what I know about Daniel, he probably does not want that power, as the author says.
However, he absolutely has that power.
Daniel could hide deliberate vulnerabilities in Curl that would allow him to take control of every machine running it. He could also hide code that would destroy those machines. In fact, he could hide code in Curl to delete itself and whatever code is using it, as well as mirrors of it, thus effectively wiping Curl off of the face of the Earth, even more so than what Marak did.
Just because people mirror Daniel’s code does not mean he doesn’t have the power to do serious damage.
I have commit and release power over a very popular library (Harfbuzz) that goes into millions of machines too. I also have distro packager signing keys for more than one Linux distro including Arch Linux. The issue here is not commit or even release power, the issue is visibility. I know full well that every freaking character I commit gets scrutinized by several folks with even more programming chops than myself. Even if I turned evil and wanted to hijack something I would be called up short and tarred and feathered so fast I’d never recover.
Daniel is in a similar boat. Not only is he a known entity but the code he writes is directly scrutinized by others and he would have to be very devious indeed over a long haul to get something really dangerous past all the watchers.
The NPM and other similar ecosystems with deep dependency trees (where most people writing and release apps don’t even know where most of the code is coming from at compile time) are different. It is ultimately quite easy to write and maintain something trivial but “useful” and then hijack high profile projects with a dependency attack in a way that it is not easy for actual maintainers of high profile projects to do directly on their own projects.
I believe that’s what the article was referring to when it said Daniel doesn’t have the same power. He would have to work a lot harder to get even something trivial through compared to how a lone actor deep in a Node dependency tree could so easily affect so many projects.
While I agree with an implicit conclusion that, eg, Go’s minimal versions approach would have helped with the issue, the specific reasoning looks flawed to me.
The argument reads to me as “you want to use a combination of versions someone else has tested before, so you need something like minver or transitive lockfiles”. I agree with the premise, but for me it leads to an exactly opposite conclusion. With Cargo’s rule-of-thumb “use lockfile for applications, not for libraries” and overnight CI, you get the ecosystem-wide testing for the all the latest versions. That is, the set of dependencies you get when creating a new lockfile is the specific combination which have been running on everyone else’s CI.
To put it another way, the problem with colors was exactly that testing was so good that everyone’s CI got broken. To me, it seems a useful property for both library and application authors. As a library author, I know that, if I publish a broken release, I’d be notified immediately and can yank. As an application developer, well, I dread running cargo update, but the fact that the version combination I get is what’s running on everyone else’s CI is at least a small consolation.
With something like minver, it seems that you are more likely to get an unique, untested combination of versions. If a depends on x 1.1 and y 1.2, and b depends on y 1.2 and x 1.1, than if I depend on both a and b, I get x 1.2 and y 1.2, a combination that was never tested. With maxver, the CI for a, b, and my project all get x 1.3 and y 1.4, the same set of versions.
The problem with maxver system is that it in general assumes good faith. That if you publish a broken update, that was accidental, and you are willing to yank it. If you deliberately publish a broken version and refuse to yank it, than, yeah, you create a lot of pain for the ecosystem which isn’t easy to resolve.
I don’t want my CI to break if there are no changes in my repository, because then I don’t know what even broke it. I pin everything and have it automatically update, merging that update commit if the tests pass.
Myself, I never pin dependencies in development branches unless I have to—if my code no longer works with the latest version of a dependency or the dependency itself is broken, I’ll rather know it sooner than later. It’s easy to pin when that happens, and a failed CI run isn’t a big price to pay in most cases.
As with the last few times this happened, I fetched the repo, ran tokei on the important bits, and skimmed them for content. This one is about 200 lines of ES5, most of which boils down to emitting ANSI codes for common colors.
This sort of thing should definitely be in the standard library, and it probably saved countless person-days of time by saving each downstream library a few minutes of writing their own ANSI code emitter.
But I suspect that, just like left-pad and the others, this was really written as a land grab in the early days of npm, and had outsized importance in the mind of its author compared to any of the companies they were hoping would pay for it. It’s “valuable” in the sense of a DNS name, not in the sense of coding skill or maintenance effort, and it sucks that the author conflated the two to the point of turning violent from perceived injustice.
I wonder if the person who wrote this actually knows what “bricked” means.
But beyond the problem of not understanding the difference between “bricked” and “broke”, this action did not break any builds that were set up responsibly; only builds which tell the system “just give me whatever version you feel like regardless of whether it works” which like … yeah, of course things are going to break if you do that! No one should be surprised.
Edit: for those who are not native English speakers, “bricked” refers to a change (usually in firmware on an embedded device) which not only causes the device to be non-functional, but also breaks whatever update mechanisms you would use to get it back into a good state. It means the device is completely destroyed and must be replaced since it cannot be used as anything but a brick.
Hopefully this serves as a wakeup call for people about what a tremendously bad idea it is to have all your code hosted by a single company. Better late than never.
There have been plenty of wakeup calls for people using Github, and I doubt one additional one will change the minds of very many people (which doesn’t make it any less of a good idea for people to make their code hosting infrastructure independent from Github). The developer was absolutely trolling (in the best sense of the word) and a lot of people have made it cleared that they’re very eager for Github to deplatform trolls.
I don’t blame him certainly; he’s entitled to do whatever he wants with the free software he releases, including trolling by releasing deliberately broken commits in order to express his displeasure at companies using his software without compensating him in the way he would like.
The right solution here is for any users of these packages to do exactly what the developer suggested and fork them without the broken commits. If npm (or cargo, or any other programming language ecosystem package manager) makes it difficult for downstream clients to perform that fork, this is an argument for changing npm in order to make that easier. Build additional functionality into npm to make it easier to switch away from broken or otherwise-unwanted specific versions of a package anywhere in your project’s dependency tree, without having to coordinate this with other package maintainers.
To the extent there is any good trolling, it consists of saying tongue-in-cheek things to trigger people with overly rigid ideas. Breaking stuff belonging to people who trusted you is not good in any way.
And GitHub was free to dump his account for his egregious bad citizenship. I’m glad they did, because this kind of behavior undermines the kind of collaborative trust that makes open source work.
Take it from me: the way to get companies to compensate you “in six figures” for your code is to release your code commercially, not open source. Or to be employed by said companies. Working on free software and then whining that companies use it for free is dumbshittery of an advanced level.
No I think the greater fool is the one who can’t tolerate changes like this in free software.
It’s not foolish to trust, initially. What’s foolish is to keep trusting after you’ve been screwed. (That’s the lesson of the Prisoner’s Dilemma.)
A likely lesson companies will draw from this is that free software is a risk, and that if you do use it, stick to big-name reputable projects that aren’t built on a house of cards of tiny libraries by unknown people. That’s rather bad news for ecosystems like node or RubyGems or whatever.
Thankyou. This is the point everybody seems to be missing.
The author of these libraries stopped whining and took action.
Worked out a treat, too.
I mean, it did. Hopefully companies will start moving to software stacks where people are paid for their effort and time.
He also set fire to the building making bombs at home, maybe he’s not a great model.
Not if you’re being responsible and pinning your deps though?
Even if that weren’t true though, the maintainer doesn’t have any obligation to companies using their software. If the company used the software without acquiring a support contract, then that’s just a risk of business that the company should have understood. If they didn’t, that’s their fault, not the maintainer’s - companies successfully do this kind of risk/reward calculus all the time in other areas, successfully.
I know there are news reports of a person with the same name being taken into custody in 2020 where components that could be used for making bombs were found, but as far as I know, no property damage occurred then. Have there been later reports?
Yeah, like proprietary or in-house software. Great result for open source.
Really, if I were a suit at a company and learned that my product was DoS’d by source code we got from some random QAnon nutjob – that this rando had the ability to push malware into his Git repo and we’d automatically download and run it – I’d be asking hard questions about why my company uses free code it just picked up off the sidewalk, instead of paying a summer intern a few hundred bucks to write an equivalent library to printf ANSI escape sequences or whatever.
That’s inflammatory language, not exactly my viewpoint but I’m channeling the kind of thing I’d expect a high-up suit to say.
Each new incident is another feather. For some, it’s the last one to break the camel’s back.
This sense of entitlement is amusing. This people totally miss the point of free software. They make something that many people find useful and use (Very much thanks to the nature of being released with a free license, mind you), then they feel in their right to some sort of material/monetary compensatiom.
This is not miss universe contest. It’s not too hard to understand that had this project been non free, it would have probably not gotten anywhere. This is the negative side of GitHub. GitHub has been an enormously valuable resource for free software. Unfortunately, when it grows so big, it will inevitably also attract this kind of people that only like the free aspect of free software when it benefits them directly.
An uncanny number of companies (and people employed by said companies) also totally miss the point of free software. They show up in bug trackers all entitled like the license they praise in all their “empowering the community” slides doesn’t say THE SOFTWARE IS PROVIDED “AS IS” in all fscking caps. If you made a list of all the companies to whom the description “companies that only like the free aspect of free software when it benefits them directly” doesn’t apply, you could apply a moderately efficient compression algorithm and it would fit in a boot sector.
I don’t want to defend what the author did – as someone else put it here, it’s dumbshittery of an advanced level. But if entitlement were to earn you an iron “I’m an asshole” pin, we’d have to mine so much iron ore on account of the software industry that we’d trigger a second Iron Age.
This isn’t only on the author, it’s what happens when corporate entitlement meets open source entitlement. All the entitled parties in this drama got exactly what they deserved IMHO.
Now, one might argue that what this person did affected not just all those entitled product managers who had some tough explaining to do to their suit-wearing bros, but also a bunch of good FOSS “citizens”, too. That’s absolutely right, but while this may have been unprofessional, the burden of embarrassment should be equally shared by the people who took a bunch of code developed by an independent, unpaid developer, in their spare time – in other words, a hobby project – without any warranty, and then baked it in their super professional codebases without any contingency plan for “what if all that stuff written in all caps happens?”. This happened to be intentional but a re-enactment of this drama is just one half-drunk evening hacking session away.
It’s not like they haven’t been warned – when a new dependency is proposed, that part is literally the first one that’s read, and it’s reviewed by a legal team whose payment figures are eye-watering. You can’t build a product based only on the good parts of FOSS. Exploiting FOSS software only when it benefits yourself may also be assholery of an advanced level, but hoping that playing your part shields you from all the bad parts of FOSS is naivety of an advanced level, and commercial software development tends to punish that.
Slides about F/OSS don’t say that because expensive proprietary software has exactly the same disclaimer. You may have an SLA that requires bugs to be fixed within a certain timeframe, but outside of very specialised markets you’ll be very hard pressed to find any software that comes with any kind of liability for damage caused by bugs.
Well… I meant the license, not the slides :-P. Indeed, commercial licenses say pretty much the same thing. However, at least in my experience, the presence of that disclaimer is not quite as obvious with commercial software – barring, erm, certain niches.
Your average commercial license doesn’t require proprietary vendors to issue refunds, provide urgent bugfixes or stick by their announced deadlines for fixes and veatures. But the practical constraints of staying in business are pretty good at compelling them to do some of these things.
I’ve worked both with and without SLAs so I don’t want to sing praises to commercial vendors – some of them fail miserably, and I’ve seen countless open source projects that fix security issues in less time than it takes even competent large vendors to call a meeting to decide a release schedule for the fix. But expecting the same kind of commitment and approachability from Random J. Hacker is just not a very good idea. Discounting pathological arseholes and know-it-alls, there are perfectly human and understandable reasons why the baseline of what you get is just not the same when you’re getting it from a development team with a day job, a bus factor of 1, and who may have had a bad day and has no job description that says “be nice to customers even if you had a bad day or else”.
The universe
npmhas spawned is particularly susceptible to this. It’s a universe where adding a PNG to JPG conversion function pulls fourty dependencies, two of which are different and slightly incompatible libraries which handle emojis just in case someone decided to be cute with file names, and they’re going to get pulled even if the first thing your application does is throw non-alphanumeric characters out of any string, because they’re nth order dependencies with no config overrides. There’s a good chance that no matter what your app does, 10% of your dependencies are one-person resume-padding efforts that turned out to be unexpectedly useful and are now being half-heartedly maintained largely because you never know when you’ll have to show someone you’re a JavaScript ninja guru in this economy. These packages may well have the same “no warranty” sticker that large commercial vendors put on theirs, but the practical consequences of having that sticker on the box often differ a lot.Edit: to be clear, I’m not trying to say “proprietary – good and reliable, F/OSS – slow and clunky”, we all know a lot of exceptions to both. What I meant to point out is that the typical norms of business-to-business relations just don’t uniformly apply to independent F/OSS devs, which makes the “no warranty” part of the license feel more… intense, I guess.
The entitlement sentiment goes both ways. Companies that expect free code and get upset if the maintainer breaks backward compatibility. Since when is that an obligation to behave responsibly?
When open source started, there wasn’t that much money involved and things were very much in the academic spirit of sharing knowledge. That created a trove of wealth that companies are just happy to plunder now.
Was that honestly the intent? Because in that case: what hubris! These libraries were existing libraries translated to JS. He didn’t do any of the hard work.
There is further variation on the “bricked” term, at least in the Android hacker’s community. You might hear things like “soft bricked” which refers to a device that has the normal installation / update method not working, but could be recovered through additional tools, or perhaps using JTAG to reprogram the bootloader.
There is also “hard bricked” which indicates something completely irreversible, such as changing the fuse programming so that it won’t boot from eMMC anymore. Or deleting necessary keys from the secure storage.
OK, so, what’s a build set up responsibly?
I’m not sure what the expectations are for packages on NPM, but the changes in that colors library were published with an increment only to the patch version. When trusting the developers (and if you don’t, why would you use their library?), not setting in stone the patch version in your dependencies doesn’t seem like a bad idea.
No, it is a bad idea. Even if the developer isn’t actively malicious, they might’ve broken something in a minor update. You shouldn’t ever blindly update a dependency without testing afterwards.
Commit
package-lock.jsonlike all of the documentation tells you to, and don’t auto-update dependencies without running CI.And use
npm shrinkwrapif you’re distributing apps and not libraries, so the lockfile makes it into the registry package.Do you really think that a random developer, however well intentioned, is really capable of evaluating whether or not any given change they make will have any behavior-observable impact on downstream projects they’re not even aware of, let alone have seen the source for and have any idea how it consumes their project?
I catch observable breakage coming from “patch” revisions easily a half dozen times a year or more. All of it accidental “oh we didn’t think about that use-case, we don’t consume it like that” type stuff. It’s truly impossible to avoid for anything but the absolute tiniest of API surface areas.
The only sane thing to do is to use whatever your tooling’s equivalent of a lock file is to strictly maintain the precise versions used for production deploys, and only commit changes to that lock file after a full re-run of the test suite against the new library version, patch or not (and running your eyeballs over a diff against the previous version of its code would be wise, as well).
It’s wild to me that anyone would just let their CI slip version updates into a deploy willynilly.
This neatly shows why Semver is a broken religion: you can’t just rely on a version number to consider changes to be non-broken. A new version is a new version and must be tested without any assumptions.
To clarify, I’m not against specifying dependencies to automatically update to new versions per se, as long as there’s a CI step to build and test the whole thing before it goes it production, to give you a chance to pin the broken dependency to a last-known-good version.
Semver doesn’t guarantee anything though and doesn’t promise anything. It’s more of an indicator of what to expect. Sure, you should test new versions without any assumptions, but that doesn’t say anything about semver. What that versioning scheme allows you to do though is put minor/revision updates straight into ci and an automatic PR, while blocking major ones until manual action.
The general form of the solution is this:
Download whatever source code you are using into a secure versioned repository that you control.
Test every version that you consider using for function before you commit to it in production/deployment/distribution.
Build your system from specific versions, not from ‘last update’.
Keep up to date on change logs, security lists, bug trackers, and whatever else is relevant.
Know what your back-out procedure is.
These steps apply to all upstream sources: language modules, libraries, OS packages… dependency management is crucial.
Amazon does this. Almost no-one else does this, but that’s a choice with benefits (saving the set up effort mostly) and consequences (all of this here)
If you trust the developers, why not give them root on your laptop? After all, you’re using their library so you must trust them, right?
There’s levels to trust.
I can believe you’rea good person by reading your public posts online, but I’m not letting you babysit my kids.
Why wouldn’t this behavior be banned by any company?
How do they ban them, they’re not paying them? Unless you mean the people who did not pin the dependencies?
I think it is bannable on any platform, because it is malicious behavior - that means he intentionally caused harm to people. It’s not about an exchange of money, it’s about intentional malice.
Because it’s his code and even the license says “no guarantees” ?
The behavior was intentionally malicious. It’s not about violating a contract or guarantee. For example, if he just decided that he was being taken advantage of and removed the code, I don’t think that would require a ban. But he didn’t do that - he added an infinite loop to purposefully waste people’s time. That is intentional harm, that’s not just providing a library of poor quality with no guarantee.
Beyond that, if that loop went unnoticed on a build server and costed the company money, I think he should be legally responsible for those damages.
Why did GitHub remove his account/projects?
That’s the part that bothers me.
I understand it wasn’t a nice thing to do, and that people are upset, but it’s his own code in his own repos. He even announced ahead of time he would do something like this, so “buyer” beware.
I realize GitHub TOS covers them to remove accounts and repos at their discretion, but it’s a little unsettling that they’ll actually do so arbitrarily without a clear TOS violation. It might be time I move everything to Sourcehut and treat GitHub as a mirror…
The Sourcehut guy has always seemed a little unstable to me (didn’t he get banned from this site, in fact?) So, why would I trust him any more than I trust GitHub?
I banned him and I would not call him unstable. Not just because that kind of insult is inappropriate here, but because it obviously doesn’t apply. He writes inflammatory hyperbole that’s not a good fit for this site, but he’s a skilled, accomplished professional who looks like he’s seeing a lot of success in his life.
I didn’t mean to insult him. Maybe “erratic” would have been a better word without any mental health connotations (which I absolutely didn’t intend)? Poor word choice on my part, I’m sorry for that.
Sure, same goes for the GitHub guys. A person who can’t tone it down enough to keep a Lobsters account just isn’t someone I feel I can trust to host my code, particularly given that he’s in charge of the whole operation. Obviously everyone is free to decide who to trust and for what reasons.
Bear in mind, Linus Torvalds would also probably have been banned from here multiple times in the past.
I’d be perfectly happy to trust someone that volatile a lot (and I guess I do, running Linux since 1996 :) ). But I would be careful which groups and forums I invited them to :)
Very different, at least to me. If Linux was a service, control would have been taken away from Linus a long time ago (I mean, as it is they made him step back for awhile to work on his issues). But it’s not, it’s just code that other people then build into something, often applying patches in the process. If Linus had a meltdown there is already sufficient infrastructure in place that the vast majority of us wouldn’t even notice.
I wouldn’t trust a code hosting service Linus ran by himself either.
Nobody made Linus step back. He recognized that he had issues and took a sabbatical to deal with them himself. Are you saying you wouldn’t trust a service by a guy who has been diligently working on the same project for 30 years? Not to mention the guy who invented the base of all of the services discussed in this thread.
Why do people assume that “Bigger is better” when it comes to web services? The two most reliable services I use are Pinboard, run by an insanely opinionated and outspoken developer, and NewsBlur, who was, and may still be, a one man shop that just quietly does his own thing. In the same time as those services have been faithfully up and running, Google has shut down more services than I can count, because “It didn’t fit with their corporate vision”
It’s misguided, and harmful.
We’ll probably never know for sure, but the subtext (well, and the text) of his announcement email sure makes it sound like his hand was forced, at least to me.
No, I’m saying I wouldn’t trust a service run by a guy who randomly goes off on people in totally inappropriate ways (his admission). Or, as is the case here, a guy who can’t even behave himself well enough to keep a Lobsters account.
That has literally nothing to do with anything. A person can be productive or brilliant and also have other, undesirable, qualities.
I don’t, so I can’t answer that.
Agree with you there! I don’t trust Google for anything but search (I don’t even use Gmail), because that’s the one thing I don’t think they’ll ever kill (or break). I don’t think GitHub is going anywhere either, the worst case scenario is that Microsoft sells it.
If there was a person who had the views you seem to ascribe to me, then I might agree!
That’s unfair to Drew. He’s passionate, and rude, and opinionated, and submissions here from his site generally stirred up giant flamewars. But I do believe he’s got what it takes to keep sourcehut running.
GitHub will keep running, too. I’m not sure we’ve answered the question of
Not only is the sourcehut software available under the AGPL, the issue trackers and such give you export and import functions to pull your data into another instance easily. The software itself is not trivial to host, but it’s not prohibitively hard either. If I needed to eject because Drew became untrustworthy, I am very comfortable that I could do that.
Even though that’s a non-zero amount of work, GitHub gives me no comparable ability. That’s a good reason to trust him more than I trust GitHub, in my opinion.
The GitHub command line client provides this functionality, as does the API. Obviously, the data formats are specific to the way GH works, but there are ways to extract most if not all of the relevant data (I use this heavily with my team to script up our findings workflow, for example).
Interesting. Unless I’m missing something, you can’t stand up your own self-hosted instance of github, and import that, can you? The ability to stand up my own instance of the forge and import my data, to use on a self-hosted site, is what I meant by “comparable”. (That’s the angle I was coming from… if Drew won’t let me use his hosted service, I can just set up my own copy on any host I want since upstream is AGPL, then import my data from the sr.ht export since sr.ht exposes those functions.)
GitLab supports importing to a self-hosted instance from GitHub [1], although I’m sure it’s not perfect, so it may or may not be useful. It also isn’t clear to me based on a 15 second review whether you can import from some kind of local data dump or raw GitHub API responses or if your GitHub account needs to be currently active.
[1] https://docs.gitlab.com/ee/user/project/import/github.html
That looks much better than I thought, particularly if it turns out to work off saved data/responses. And it’s nice that Gitlab enable that for all their tiers.
GitHub Enterprise can be bought as a GitHub-hosted or self-hosted thing. These support (most of) the same APIs as the public GitHub, so you can run your own instance if you are willing to pay.
It would be an interesting experiment to see whether they would sell an enterprise installation to someone whose account they forcibly closed. I was sort of assuming that if they won’t let you be a customer of their public service, they won’t sell you the private one, but that is uninformed speculation.
Because sourcehut is open source so nothing is lost when I leave. More than that chances are if sourcehut goes a bad route there would likely be others jumping in.
Not that you exactly claim otherwise, but Drew also makes some nice things and has created a business structure that enables at least one other developer to make some nice things.
Quite apart from that, though, and similarly quite apart from whether he has what it takes to keep sourcehut running, he’s given me an out so that I don’t, strictly speaking, need him to. He’s released the software that runs the forge under the AGPL, here. And it exposes ways for me to export the hosted stuff and import it into a self-hosted instance.
So regardless of whether I trust Drew personally, he’s made it so I don’t need to for this purpose.
If Drew got angry and decided I couldn’t be his customer anymore, I could stand up my own instance or pay someone to do that for me and import my data. My repos wouldn’t be down at all, my tickets, docs, etc. would be down for a day or so, and my mailing lists might see a bit more disruption than that. If github decided that I shouldn’t be their customer anymore, I’d have my repos. For the rest, I’d kind of be out of luck. (I think this last paragraph is more responsive to @glesica ‘s comment than the one I’m replying to, and I’m too lazy to split it to another reply.)
Because “more than I trust Microsoft” is a damn low bar.
It’s like a little devil hovering over my right shoulder, and a slightly less predictable devil hovering over the other.
From other options there’s also fediverse approach with Gitea, and p2p approach will be available soon with Radicle.
That time was years ago, but hey, better late than never.
Consider hosting your own, instead. I published a blog post with a list of defunct code hosting sites which I update occasionally. Maybe that list is a good reminder. Remember, it’s not just code that goes away with such sites, it’s also issue queues and in some cases, wikis and mailing lists too.
Are you also start hosting a list of defunct private websites that used to host Git repos that are gone forever and where the disappearence came completely unexpected? I would trust Github more with staying online since that’s their job than a developer running a Gitweb on some VPS with some domain name that requires regular payment to stay online.
Kinda like I registered callcc.org after it lapsed to make sure the links to the CHICKEN website don’t break and it doesn’t get domain-squatted and I’m redirecting to the official website these days.
I can’t think of anything offhand where I’ve taken a dependency that’s done that. But when I do take a dependency on something, I generally mirror the SCM repo if there is one. And I am very reluctant to take dependencies on things I can’t have the source to. Since the things I depend on generally haven’t gone away, I haven’t bothered to publish my mirrors, but I would if the license permits it.
I learned that the hard way when Rubyforge went down, a few employers ago. We weren’t that active in the Ruby community anymore, so we missed the notice. When the site went away and I had to do some small maintenance tasks on a legacy project, all the third party svn subtrees from Rubyforge were no longer working (and, more painfully, another project of ours was completely gone too). Note that Rubyforge was huge in the Ruby community back in the day.
Like I said, history has shown these hosting sites are not as trustworthy as people like to believe they are. The GitHub company can get sold to an untrustworthy partner (har har, like that’d ever happen… oh wait) or go out of business (what if MS decides to sell the company to, I dunno, Oracle or something because it’s not making a profit?), or there might be some other new VCS that comes out that completely blows git out of the water. I’m sure nobody saw coming what happened to Bitbucket - it started out as a Mercurial hosting site, then started offering git and finally dropped Mercurial after Atlassian took over. Its founders probably never would have let that happen if it were still in their power.
From my own perspective, I’ve personally ran into at least five hosting sites who were hosting projects I started or heavily contributed to that are no longer available now (Rubyforge, Dutch govt OSOSS’ uitwisselplatform, Berlios, Bitbucket and Google Code). And then there’s Sourceforge which at least still hosts some of my defunct projects, but had for a while been injecting malware into downloads. If I or my employers (as the case may be) had hosted our own projects from the start, this pain would’ve been completely avoided. These are projects in which I had a stake, and it was in my interest to not let them die.
Now, having said that, I agree that from a third party perspective (someone who is using the hosted code) that’s different. I understand your point saying you don’t want to rely on some random developer’s VPS being up, and neither would I. But then, people change repositories on code hosting sites all the time, too. They move to other hosting sites, or rename repositories etc. Links rot and die, which is unfortunate and something we all have to live with.
Case in point:
Thanks for doing that. AFAIK this domain was never communicated as being official, but I might be wrong.
I don’t know what the GitHub rationale was, but the ‘limitation of liability’ bit in most open source licenses only goes so far. If I intentionally introduce malicious behaviour into one of my open source projects, knowing that it would damage downstream consumers, then I’d probably be liable under the Computer Misuse Act in the UK and similar legislation elsewhere. GitHub’s T&C’s don’t explicitly prohibit using their service for criminal purposes but that’s normally implicit: if GitHub didn’t act then they might end up being liable as an accessory (at least as an accessory after the fact). Their distribution channel (NPM) is being used by a malicious actor to attack other users.
It’s normally difficult to prove malicious intent in this kind of thing (incompetence and malice look similar) but it seems pretty clear here from the author’s own statements.
This is disturbing. Software is provided as is, with no liability whatsoever, but the author should still be liable for what happens when other people use it, because it broke things? What if the author decided to completely change the library’s API, or recycle it to just print squares of color, because they liked the name?
If find what the author did pretty stupid, but frankly, suggesting it falls into criminal behavior call for some stepping back and put things in perspective.
There is a difference, and it’s not subtle at all, between making a possibly unwanted change in software that is provided without any warranty, and deliberately making a crippling change with the express intent of breaking other people’s applications.
To put it another way: if you accidentally commit an integer overflow bug that causes batteries to blow up, that is, presumably, just bad engineering. But if you deliberately commit a clever hack that causes people’s batteries to blow up, with the express intent of getting people injured, or at least destroying their phones, I think it makes a little sense to not put it under “well, it did say no warranty of any kind on the box, didn’t it?”.
Obviously, this didn’t kill anyone, so I’m obviously not thinking it ought to be treated as murder. But “no warranty” is not a license to do anything.
It’s not like software is being given special treatment here, it’s how warranties work everywhere. If you sell boats with two years’ servicing warranty and they break down after three years, that’s one thing, but if you fit them with bombs that go off after two years and one day, with the express intent of killing anyone on them, that still falls under “murder”, not “what happens after two years isn’t our problem, it says so on the purchase contract”.
(Edit: obviously IANAL and this is not legal advice, either, I’m only parroting second-hand, non-lawyer advice about how insurance works for some high-stakes software projects)
I guess that makes sense, when you put it that way :)
I am not a lawyer, this is not legal advice:
My understanding is that it comes down to intent. If I upload a buggy piece of crap to GitHub with an open source license, and you use it, then it sucks to be you. If I upload something to GitHub, wait for you to deploy it and then intentionally introduce a vulnerability or other malicious behaviour in it then legally dubious. Normally it’s very difficult to prove intent. If I submit a patch to the Linux kernel that introduces a vulnerability, if you wanted to prosecute me then you’d have to prove that I did so knowing that the bug was there and with the intent to cause harm. That’s very difficult to do in the general case (the NSA null-pointer dereference bugs are a great case in point here: people suspect that the NSA knew about that vulnerability class and introduced it deliberately, but no one can prove it and there’s enough reasonable doubt that it would never stick in court unless there was some corroborating evidence - it could easily have been accidental). If, before I submit the patch, I post publicly about how I am going to intentionally break things for the people using my code and then I push a new version out to public repositories then it’s likely to be easy to prove malicious intent. The author of these packages did exactly that: posted saying that he was going to break things for people if they didn’t pay him and then, when they didn’t pay him, broke things. That may (again, not a lawyer) count as blackmail, as well as computer misuse.
I think until they make a statement about it, nobody knows but them. But my assumption is that this happened on a weekend, and whoever was on call figured that the easiest thing to do to minimize disruption till Monday was to suspend the account and hard revert the content until more people could be brought in. I’m also assuming suspending the account just automatically says that you violated the ToS.
I could imagine that somebody identified this as a possible account hack and thus locked it.
They didn’t, they suspended his account so he can’t log in. You are still free to troll him on GitHub without any recourse whatsoever.
The author must feel very spiteful, to retroactively turn his gift into not only a transaction but a trap. I think it’d be better to learn a lesson about setting healthy boundaries when you decide to give of yourself so you don’t feel that others took advantage of you.
This. So much this. Also, it is quite possible the author is letting themselves be influenced too much by others’ whinging about companies using their free software for free.
On the one hand, it’s true that FLOSS is “under-sponsored” for the critical role some of it plays (and a color library and random value generator probably doesn’t fall in that category to begin with), but on the other hand all the attention this is getting lately is creating a lot of sour grapes and feelings of being wronged by corporations among developers. But these same developers are forgetting they originally created their software out of love/intellectual curiosity/boredom/whatever, yet they expect to get paid by people who never asked for the software in the first place. Of course, businesses now they are more than happy to use it while it’s there. Why wouldn’t they?
I wonder how a free software author defines success. Just making the contribution and feeling good about that? Seeing it used in a lot of places? Recognition? Patreon subscribers? It must be different for everybody, but I suspect there is some missing link here by which the author’s real goals were left unfulfilled.
They didn’t ask for it, but they sure feel free to unilaterally prop a critical piece of their infrastructure solely on top of it, and then make millions, without paying a dime back.
Well exactly, and that’s a fundamental flaw in “Open Source” as opposed to Free Software (Which to be honest, I also can’t fully agree with). Open Source was created from the start to exploit developers who were making things for other developers. It said, in big letters, “You can make money off people’s hard labour, and not have to pay them anything!”. How is that not exploitation? In any capitalist system it’s the sole definition of it! We have hundreds of thousands of pages and millions, perhaps billions, of words in our legal framework stating explicitly that people should get paid for their labour when they do work. It is, very literally, the only reason why copyright and patents exist in the first place – from the idea that, when people do work, the deserve compensation so that they can continue to exist.
Now, you can claim that they get paid through popularity, but how does that help the person tangibly? I can create a huge 1k, 10, 100k starred repo on Github, but I still have to go through the same interview process as anyone else. Except now I am (apparently) bound to maintain and document and correctly deploy my own personal projects, just because some fool at Microsoft decided it was a good idea to rest a chunk of their software stack on it?
But no, you are right, people should start choosing LICENSE files that deliberately do not give rights to companies unless there is financial exchange. It’s the only way that they will learn.
It’s more the fault of the downstream developers and companies, though, isn’t it? They decided to take someone’s code, use it to make money, and not throw a penny in their direction. It was the ‘Open Source’ philosophy that decide to turn “Here is a gift to my fellow developers” into “Here is a project I put my sweat and labour into, feel free to exploit it with no regard for the cost”, and people bought into it wholesale.
This repo was owned solely by the person who wrote it, and there’s no reason they have to consider downstream projects that they might not even be aware of, when they make changes to their code. I am not arguing for the guy, but I absolutely think his act here was justified, and a positive thing in the long run. There’s a reason for a liability waiver in the LICENSE file and if you’re just going to take code and ignore that liability waiver, then that’s up to you, buddy. Doubly so if you’re a tech lead and you’re evaluating the dependencies your company is going to use to build stuff, right at the start.
Hopefully, rather than blaming this on one erratic individual, companies will start paying money upstream to the projects that they make money off of. But I doubt it.
I don’t disagree that the license makes no guarantees, but that’s an unconvincing technicality when it comes to relating to one another as humans. The libraries were offered because they were useful, they were accepted in good faith, and then they were sabotaged in bad faith. To the author it may have felt like a righteous protest, but from the outside it just looks like taking your ball and going home.
I’ll add, Snyk flagged at least one of these libraries as vulnerable to DDOS today because of its deliberate infinite loop. That’s malware in my book, and that’s crossing a line.
I feel like if you’re going to impose an unstated and explicitly disclaimed responsibility (attempting to release only useful software) on the developer as a condition of good faith bargaining, it’s only fair to expect some compensation in consideration, particularly given the developer asked as much a year ago from what I recall. It’s still reasonable, in that good faith universe, to leave it under the MIT license to allow users to pay what they feel is fair.
But the reality is this is exactly why businesses use contract and licensing language to expressly indicate what parties can count on one another for. Good faith, in that world, means adhering to the spirit of that language, and in this case that language clearly indicated the developer could do whatever they wanted with the library and that anyone consuming it should be on notice to verify that it did what they wanted. For what it’s worth, that cuts both ways - GitHub is also acting in the spirit of the MIT license by continuing to distribute the older version, despite the developer’s wishes.
The malware thing is a good point though - I was under the impression this was breaking deployments and potentially causing downtime, both of which are in my opinion reasonable consequences of using something unreliable. But if the infinite loop introduced the ability for remote users to trigger downtime that’s subtly different in a way I agree crosses some kind of line.
This person seems to have serious issues https://www.reuters.com/article/us-usa-new-york-bomb/new-york-man-arrested-after-apartment-fire-explosive-materials-found-idUSKBN2672WQ
A quick web search turned up this as well, if it’s the same person….
https://gist.github.com/lclarkmichalek/716164
Given that the owner of the colors.js repository replied to that Gist with a thank you, I think we can call it confirmed it is the same person. I don’t know about the Reuters article but it looks conceivable it was the same. Even if the latter turns out to be a different chap of the same name it seems like the FOSS world will be better off without relying on code from such a loose cannon.
Most elements of this seem to have worked out exactly as they should.
In none of these events were there any real surprises - all of these actions were things that everybody involved should have been aware were reasonable possibilities.
The only real misstep here seems to have been on the part of organizations that didn’t just use the software, but clearly didn’t understand what they were getting into. Automated deployments to production directly from a third-party repo are madness, and that’s what I understand to have caused problems. If I’m wrong, please ignore the rest of this post and/or shame me for my ignorance.
If you have the resources to do automated deployments, your CI/CD pipeline should be pulling from a locally hosted copy that’s been validated in testing and only updated with new versions that have also been validated. If you don’t have those resources, no automated activity should have caused a deployment so this shouldn’t have caused anything more than brief befuddlement during manual development/testing. In any case, without contractual or licensing language that gives assurances otherwise, no organization should be using third-party code without budgeting for the possibility that it could spontaneously and suddenly fail.
Is that completely unsustainable in modern software development environments? Yes, probably. Businesses that pay developers have created a situation where it’s impossible to do the job properly, but then again software developers perpetuate that by agreeing to do their best under the circumstances. It’s hard to say where the blame should fall, though I would mainly lay it on corporations for thinking any of this was a good idea. High growth, high risk, I guess. The only reason it works so well as it does is because of just how effective trust and social forces are in the economy, but now I’m getting really off-topic so I’ll call it a post.
I understand that this is the last event in a long series, but when he refused in 2020 to stop supporting big corporations, why didn’t he change the license to a more restrictive one? To my knowledge, there are many big companies allergic to the GPL family of license, which would have lead to the wished outcome.
If he had already accepted outside contributions, it may have been difficult to get existing contributors to accept a license change.
Ah good point.
He didn’t even need to change the license file in the main, he could have just modified the license file to explicitly exclude companies by name, by market cap, by country, by any arbitrary condition he wanted. It would no longer have been considered an open source license by any definition of the term, but it would have been usable by everyone he wanted to use it.
Step two though, would have been license violation detection, which is a whole different issue, especially once the JavaScript gets minified. And we haven’t even gotten to enforcement.
This stuff is tricky and I believe in doing the right thing. But it is very easy for any company to do the wrong thing, intentionally or not. If you really really care about company’s not using your code, you might want to just consider not open sourcing.
Or use a copyleft license like the GPL, which will likely induce the companies you don’t want to use your software to voluntarily avoid using it.
I have a feeling this isn’t as much about companies not wanting to use your software as it is about getting paid for your work.
Which of course is tricky given the trivial nature of many of these packages: Yes. It’s very convenient to use a pre-existing package for emitting colors on the console, but also, yes, it’s much easier to either not emit colors or to quickly hack up something to emit the requires ANSI color bytes rather than going through all of the red-tape to get the author of that package paid.
And even if you do: The functionality offered by such a relatively simple package can be implemented by an engineer in less than a day, so as a company I’m wondering how much I’m actually willing to pay for this.
It gets worse though: While the packages in question were certainly downloaded by some big companies CI systems, it’s not even clear whether this was a direct dependency of their software. This might have very well been a package used by a package used by a package of some (much more high-value) dependency of theirs which they actually might be sponsoring in one way or another.
So is it now the expectation of open source projects which accept sponsorships to then further pay off all their dependencies? And their dependencies dependencies? What percentage of your income should you forward downstream?
Or in fewer words: This is a complicated mess
Not to forget about who is deciding about what deps should be added to a library? Is it acceptable to add colored text output to a build tool? How necessary is it? Did anyone asked for it or did they added so the coloring lib can demand it’s share?
that’s up to the build tool author to decide, but I would argue that nowadays it’s not just acceptable but required to be competitive with other build tools. It sucks, but that’s the world we live in. Bling sells.
But it should not matter for the Fortune 500 company C using (and sponsoring) build tool B whether that tool also happens to have library L as its dependency and whether that dependency is compensated for their effort.
You can’t expect company C to be going through the whole dependency graph of B and add micro-sponsorings to each of those deps, even more so as I would assume the author of library L wouldn’t be happy with whatever percentage of the sponsoring pie they would get from company C even though colored output on the command-line is only a tiny subset of their usage of B and possibly even disabled on the CI (but still downloaded).
So the author would still be disgruntled and this would still happen.
I fear the same thing happening in the Rust ecosystem some day, because you quickly pull in a non-trivial number of small libs even for a simple project, and most of them are hosted on GitHub and maintained often by separate individuals or small groups. I know there is version pinning, but how well is this followed? This might be a good idea for an explorative analysis, and maybe someone can say more about this concern, which probably has been addressed in some way.
As a side note, many think the circumstances of Aaron Swartz’ death raise a lot of questions, to put it lightly.
I mean, yeah, sure, but I’m having a hard time seeing how that is at all related to this situation.
It’s supposedly an integral part of the rantings of the developer in question.
Is there more background? I saw the hashtag in a tweet from Marak and was completely confused.
I just found this https://twitter.com/cubeghost/status/1480233259527286794
The rust ecosystem has a tool enforced rule that for all crates hosted by crates.io, all rust dependencies are also hosted by crates.io. Technically you can have a
build.rsthat manually downloads things from github (or elsewhere), but that is incredibly rare.Every time you run a build, it generates a
Cargo.lockfile pinning the version. Most people developing binaries commit this, that’s what the default .gitignore encourages, so it’s followed pretty well.The lock file also includes checksums for each dependency and crates.io doesn’t allow re-pushing the same version.
Dependencies update when you run
cargo update, and not automatically. It’s not foolproof: if you don’t preserveCargo.lockand use CI/Docker that naively wipes all state away, you’re going to get fresh(est) deps every time.crates.io is lucky that it’s a step behind npm, so it can learn from npm’s mistakes. For example, from the start it prevented
left-padincidents by not deleting any packages (yanking only hides packages from UI, not direct downloads).But it’s only a matter of time before the next big mess happens on crates.io too. Sadly, crates.io is understaffed, so there are several features/mitigations it probably should have, but hasn’t got yet.
There’s cargo-crev that aims to create a set of manually-verified trustworthy packages, but crates.io is growing by 70 releases a day, so it’s hard to keep up.
I think the feature is inherent. If you’re downloading stuff in apt, you’re trusting the people packaging that application (and their download servers). If you’re installing stuff manually, you’re trusting the people where you download it. And if you’re developing things you’ll have to trust the developers. And I’m certain at each of these steps are many “hidden dependencies” you don’t actually realize when downloading. It will fail somewhere in the future, and people will rally about how bad crates.io is, while the rest of the world moves on.
Automatic generated for all builds, should be committed for all applications:
Today I was being polite and held the door for someone, but they looked like they wouldn’t be paying me for doing that, so I slammed the door at them and broke their fucking face. I can’t believe anybody is endorsing this behavior.
Exactly. There are two very different scenarios:
I hold the door open for you but my hand slips and it shuts on you and you get hurt. This is the kind of scenario where the disclaimer of warranty in most open source licenses covers: you made a best-effort attempt to do the nice thing, you failed, and someone got hurt.
I hold the door open for you and then slam it in your face as you get here. This is actively malicious behaviour that causes actual harm. In the metaphor, this would likely be covered by something like actual bodily harm. In the scenario in the article, this is likely covered by computer misuse laws. No disclaimer of warranty protects you.
Can you un-publish a library on npm, and what happens if you do? If so, a third scenario would appear:
I stop opening the door for you and you run into it because you expected me to open it.
Un-publish in NPM has rules. If the door is not used that much (or just built in yesterday), you can leave it closed as you want.
It is in fact what happened back in 2016 with the infamous left-pad incident.
[Comment removed by moderator pushcx: You're replying to a thoughtless metaphor, but going into gender politics is definitely off-topic.]
I just want to address one line in the “Dependency Risk and Funding” post:
Knowing what I know about Daniel, he probably does not want that power, as the author says.
However, he absolutely has that power.
Daniel could hide deliberate vulnerabilities in Curl that would allow him to take control of every machine running it. He could also hide code that would destroy those machines. In fact, he could hide code in Curl to delete itself and whatever code is using it, as well as mirrors of it, thus effectively wiping Curl off of the face of the Earth, even more so than what Marak did.
Just because people mirror Daniel’s code does not mean he doesn’t have the power to do serious damage.
I think you missed the point. Let me explain.
I have commit and release power over a very popular library (Harfbuzz) that goes into millions of machines too. I also have distro packager signing keys for more than one Linux distro including Arch Linux. The issue here is not commit or even release power, the issue is visibility. I know full well that every freaking character I commit gets scrutinized by several folks with even more programming chops than myself. Even if I turned evil and wanted to hijack something I would be called up short and tarred and feathered so fast I’d never recover.
Daniel is in a similar boat. Not only is he a known entity but the code he writes is directly scrutinized by others and he would have to be very devious indeed over a long haul to get something really dangerous past all the watchers.
The NPM and other similar ecosystems with deep dependency trees (where most people writing and release apps don’t even know where most of the code is coming from at compile time) are different. It is ultimately quite easy to write and maintain something trivial but “useful” and then hijack high profile projects with a dependency attack in a way that it is not easy for actual maintainers of high profile projects to do directly on their own projects.
I believe that’s what the article was referring to when it said Daniel doesn’t have the same power. He would have to work a lot harder to get even something trivial through compared to how a lone actor deep in a Node dependency tree could so easily affect so many projects.
The only thing I can say here is:
Good, accelerate.While I agree with an implicit conclusion that, eg, Go’s minimal versions approach would have helped with the issue, the specific reasoning looks flawed to me.
The argument reads to me as “you want to use a combination of versions someone else has tested before, so you need something like minver or transitive lockfiles”. I agree with the premise, but for me it leads to an exactly opposite conclusion. With Cargo’s rule-of-thumb “use lockfile for applications, not for libraries” and overnight CI, you get the ecosystem-wide testing for the all the latest versions. That is, the set of dependencies you get when creating a new lockfile is the specific combination which have been running on everyone else’s CI.
To put it another way, the problem with colors was exactly that testing was so good that everyone’s CI got broken. To me, it seems a useful property for both library and application authors. As a library author, I know that, if I publish a broken release, I’d be notified immediately and can yank. As an application developer, well, I dread running
cargo update, but the fact that the version combination I get is what’s running on everyone else’s CI is at least a small consolation.With something like minver, it seems that you are more likely to get an unique, untested combination of versions. If a depends on x 1.1 and y 1.2, and b depends on y 1.2 and x 1.1, than if I depend on both a and b, I get x 1.2 and y 1.2, a combination that was never tested. With maxver, the CI for a, b, and my project all get x 1.3 and y 1.4, the same set of versions.
The problem with maxver system is that it in general assumes good faith. That if you publish a broken update, that was accidental, and you are willing to yank it. If you deliberately publish a broken version and refuse to yank it, than, yeah, you create a lot of pain for the ecosystem which isn’t easy to resolve.
I don’t want my CI to break if there are no changes in my repository, because then I don’t know what even broke it. I pin everything and have it automatically update, merging that update commit if the tests pass.
Myself, I never pin dependencies in development branches unless I have to—if my code no longer works with the latest version of a dependency or the dependency itself is broken, I’ll rather know it sooner than later. It’s easy to pin when that happens, and a failed CI run isn’t a big price to pay in most cases.
As with the last few times this happened, I fetched the repo, ran tokei on the important bits, and skimmed them for content. This one is about 200 lines of ES5, most of which boils down to emitting ANSI codes for common colors.
This sort of thing should definitely be in the standard library, and it probably saved countless person-days of time by saving each downstream library a few minutes of writing their own ANSI code emitter.
But I suspect that, just like left-pad and the others, this was really written as a land grab in the early days of npm, and had outsized importance in the mind of its author compared to any of the companies they were hoping would pay for it. It’s “valuable” in the sense of a DNS name, not in the sense of coding skill or maintenance effort, and it sucks that the author conflated the two to the point of turning violent from perceived injustice.
[Comment removed by moderator pushcx: Trying to map this event onto American politics is not going to stay on-topic or improve this discussion.]
[Comment removed by moderator pushcx: Trying to map this event onto American politics is not going to stay on-topic or improve this discussion.]