Question, since I don't use much node.js. Doesn't the repository publish GPG-signing and a checksum hash of every file? The compromised package should have been rejected by the retrieval tool, no?
And this is a critical point. Gpg comes up constantly. It's a waste of everyone's time alive for this use case. If a developer with publish access is compromised, it doesn't help. If the infrastructure is compromised only hash history is required. Hashes are faster to compute in such an emergency, and more available on various mirroring/hosting solutions meaning more likely to have verification sets laying around.
A ledger of hashes of published packages that is run on separate infrastructure and consumed by the client would do just as well as signing for detection of both threats without a lot of complicated issues around third party key material handling, crypto library bugs, and the need for revocation processes.
Note: this is based on experience validating all gems after the yaml scare years ago.
I think in this particular case, the user's npm credentials were compromised. In a system where you have separate and independent credentials for generating a valid package and for publishing, this specific attack might have failed.
Clicking your heels three times and saying 'GPG', of course, doesn't fix much.
Once you identify a privileged user like this reusing credentials the steps to rooting their box and stealing everything else aren't far away. In this case it wasn't needed, but in any case the threat model and recovery model for packages remains unchanged and my recommendation stands.
A ledger of hashes doesn't prevent someone from publishing a new version of a package with the stolen credentials.
What you advocate in this thread is setting aside defense in depth. Could the attacker have used the stolen credentials to pivot to other machines and ultimately gain access to the GPG keys? Maybe, but it's a hurdle, and not a small one. The more hurdles we can place in the way, the less likely it is that small mistakes cascade into total system failure.
There may be legitimate reasons to not to use package signing, but this is definitely not one of them.
>2018-07-12 9:49 UTC: The attacker used the generated authentication token to publish eslint-config-eslint@5.0.2, which contained a malicious postinstall script that attempts to exfiltrate the local machine’s .npmrc authentication token.
>2018-07-12 18:42 UTC: npm revoked all access tokens generated before 2018-07-12 12:30 UTC.
Does this mean that potentially any version update (of ANY npm package) published between 9:49 and 18:42 could potentially be compromised? Someone's going to have to go through all of them with a fine tooth comb...
The maintainer whose account was compromised had reused their npm password on several other sites and did not have two-factor authentication enabled on their npm account.
I wonder how many accounts the attacker checked before hitting this account. This will definitely get a nice place in the bucket of examples I throw to people, when I see they are still reusing passwords.
Somehow people in the ESlint thread were defending the fact that NPM seems totally uninterested in this.
Yes, it doesn't solve all the problems and yes you still have to determine who to trust, but at least it makes it POSSIBLE to trust anything. Currently it's impossible to trust anything that you install—and packages can run arbitrary, unsandboxed code with access to the full filesystem when they are installed. That just seems insane to me.
The objections raised there are all legitimate. Generally usable public key infrastructure is, sadly, vaporware.
Yegge's security vs accessibility rant/monograph should be required reading. The NPM team's choice to favor accessibility is a reasonable choice. The trade-offs are significant.
How would GPG signing help? If someone can execute arbitrary code on your computer as your user account, the game is over, you are totally owned. An attacker can simply start signing their package with your GPG key. Since you are probably in sudoers, unless you have superhuman carefulness, they can also get root.
What you'd want is for the owner/maintainer to sign the code, rather than the repository. This wouldn't protect you against a malicious maintainer, but it would help in a case like this as long as the signing key or the maintainer's device isn't compromised along with their credentials. That would definitely raise the bar for attacks of this nature.
Alice installs malicious eslint.
Attacker has control of Alice's machine and signs a malicious version of Alice's package using Alice's key.
Attacker publishes a new version of Alice's package.
Bob installs Alice's (malicious) package.
Attacker has control of Bob's machine and signs a malicious version of Bob's package using Bob's key.
Attacker publishes a new version of Bob's package.
...repeat
IMO signing could only work if it were combined with 2FA so that each time a package is signed, the signing operation is verified by the user on a second device. Otherwise it doesn't really impede a worm significantly because the nature of this attack is that the maintainer's primary device gets completely owned. We are all very lucky that the eslint attack only stole npm credentials instead of installing rootkits.
In this attack, the maintainer's primary device was not owned. The maintainer's npm account was breached due to a reused password. Code signing would mitigate this because the attacker would be unable to release/sign a malicious version of the package.
Building a system that is immune against the maintainer's device being compromised puts you into "Reflections on trusting trust" territory. Just sticking two-factor authentication into that process won't change much (though it would of course also mitigate the password reuse vector).
> While the author tried really hard to prevent any errors from being thrown (going as far as wrapping an asynchronous https.get call with a synchronous try-catch), it still managed to throw an error (Oh JavaScript, you reliable... you).
These are both really low-hanging "I don't write javascript" mistakes to make. Most Node.js devs know that the response is a stream, right? Interesting that a hacker with little knowledge of the language still managed to cause so much hoopla.
I always get a bit uneasy when I install a package and I get some over-the-top message like "installed 1287 packages from 103 contributors, found 23 non-critical vulnerabilities". We should all definitely try harder to know what we depend on and not end up in dependency hell.
Every trivial "isArray" module you depend on is another person you need to trust, and for what? It takes a second to write a "utilities.js" file and throw in crap like:
I never really understood the true appeal of micromodules, but they are especially unappealing in the face of the combinatorial explosion of dependencies and the attack surface they bring with them. I mean if you want a left pad or an is array, is pulling in something established and trusted like lodash really that bad?
They make a lot of sense to people who like to think functionally. If you view modules as providing functions that you can composite into whatever it is that you need, micromodules are appealing because they offer just want you need and nothing more.
>micromodules are appealing because they offer just want you need and nothing more
But people don't import micromodules, they import entire dependency trees of arbitrary depth full of micromodules. The greater simplicity of the modules ironically leads to greater complexity in practice.
I suppose hacking is its own business domain, and these are domain experts writing shitty code to implement the business logic they need.
I've known programmers who couldn't program very well, but they understood the business domain and its rules so well that, while writing verbose unmaintainable crap they could be as productive as better programmers who did not know the domain as well.
The reason is that many people don't know how to write a proper isArray. Forgetting about security momentarily (and I promise we'll come back to it), rewriting code repeatedly is a path towards bugs and mistakes. Array.isArray didn't even exist until pretty recently, and was non-trivial to understand before then (x => x && Object.prototype.toString.apply(x) === "[object Array]", of course!). There's an entire separate discussion of why JavaScript doesn't build this stuff in to begin with, but now we're in historical land and not practical solution land.
Ultimately though, the goal needs to be to build tools where its hard to do something insecure regardless of how we otherwise feel about that programming practice. It can't be that the reason we shouldn't install is-array is because it can lead to catastrophic exploits -- that says something about the ecosystem not the validity of where we choose to draw the line of what merits a library.
Node is cursed in part by its success. In a lot of ways its like the early days of the web, it grew faster than we had time to figure stuff out in. That's OK if we learn quickly and adjust accordingly. We don't have to run node program's with access to everything -- but again, we don't have to run any kind of program with access to everything. Go to Homebrew's website (https://brew.sh). This is a developer tool and what they tell you to do is to blindingly copy a bash line that downloads a file from THE MASTER BRANCH on GitHub and runs it on your system:
Get access to this guy's password and you can compromise tons of systems too. As much as I hate the Mac App Store as a distribution mechanism, there's something to the "sandbox first" programming mentality it incidentally forces its apps into. Maybe we should be thinking more along those lines too.
Importing lots of code from others is a path towards bugs and mistakes. You end up not understanding your dependencies, importing far too much (because you want function x but also get a-z), amd dealing with changes you didn't want or need which mix security fixes with features.
Better to minimise dependencies particularly for trivial functions. Not just for security but for ease of development.
I love node - it's a really irresponsible way of programming. The objective is to make as much the concern of someone else as possible. "How do I know what an array is? I'm just writing this app that works with arrays.."
:-)
In seriousness though, there many ways to write an isArray. Just yesterday I was looking at the different things String::repeat() handles on Mozilla's site. What seems trivial can be defined slightly differently everywhere and I tend to reach into the npm bag if I know it's open to interpretation.
The point is that you just have to engineer your way to commit access on master once. If it at least pointed to a github release or an immutable equivalent, it'd be vetted by the author before millions of people point a ruby eval at it.
Is there a formal, npm-style registry for reusable snippets like this? It would be great to have a popular, well known registry of snippets where they could be named, searched, voted on, ranked, written about in top-10 articles, etc.
This was well written. NPM is basically run like Github. I had always thought it was some non-profit org, but that's not the case.
It is possible NPM could take the Github route with ssh tokens and only limit NPM publishes to certain authorized computers; a minor step, but you'd have to compromise the computer as well. That could probably be an option in the NPM settings as an extra step.
> But honestly, the amount of work we'd all need to put in to truly prevent this from happening again... it's just never going to happen.
To me this is the irresponsibility of the NPM maintainers. Require some kind of cryptographic proof you intended to change the code. Signing or TFA or we wont host your w̶o̶r̶m̶ code ...
This is especially necessary because a pull request can make arbitrary code change, like "print the npm access token", which would then run as part of the test suite and show up in the public logs.
> Well first we need to know how people would discover it. There's a couple obvious ones...
npm emails you by default whenever one of your packages has been published (even by you), so I imagine that would be the most likely way that the problem would be detected in practice.
What makes you say that? The "not recommended" action in their screenshot is to disable 2FA. (I did find the screen a little confusing when setting up 2FA just now, though; it wasn't clear that it was picking between three different actions.)
Making a Referrer handler like that is a great way to let me know that you're probably not worth the read anyway, because you're not likely one to listen to anybody else.
I've never once found HN a toxic place in the last 4 years. A place to meet people with different opinions and have discussions about those opinions, yeah, but that's beneficial -- literally the opposite of toxic.
Having had a few posts show up on HN from my site usually because I posted them (although not always), I can say that the comments are frequently nitpicky, unrelated to what you're talking about, and frequently unnecessarily critical. They rarely engage in the substance, and instead engage aggressively in minutiae. Not wanting to have to deal with the HN comments on your work is something I completely understand.
I'm not saying I don't understand, but I am saying that I've found it more valuable to engage with nitpickers (and learn their perspective while sharing mine) than to continue to do my work in a vacuum free of nitpickers.
I've got plenty of nits worth picking. I think most people do.
- HN is generally favorable than many other websites, but only because those websites are hopelessly toxic.
- Voting system works well for filtering non-informative contents out, but it does prefer some kinds of informative contents than others.
- Conflicts in HN are not common, but once started they are hard to control. HN is not a good place for managing conflicts; it's only good for mild discussions and it has no effective measure to stop discussions from becoming conflicts.
- Of course there are many different opinions less represented in HN. Some of them can be considered as to an inherent bias of HN.
You just rationalized being rejected from a website because you came from HN. The truth is that you don't know what "toxic" means by the author's own definition or what led him to think that way. It may or may have anything to do with "listening to other people". Perhaps this defense is toxic already. And just telling that some place is great for you does not mean that it's great for others.
A place to meet people with different opinions and have discussions about those opinions
It depends on the topic. Recently, many topics have laid bare the groupthink attitude of the HN community. Any comments even questioning those views, much less actually expressing an opposite view, are instantly downvoted and derided in replies. This attitude is pervasive, all the way up to management. I am currently rate-limited, for example, because I was against GDPR. I was told by @dang:
”I'd be happy to lift the rate limit after these repetitive GDPR controversy threads have died down.”
In other words, as soon as my opinion is irrelevant because there are no threads about it, I can speak again.
This seems really counterproductive to me. This post is extremely relevant to the HN community and could do a lot of good if people see it here. I read it before this message was put up and thought it was really well-written.
This interests me. I find HN to be one of the least toxic places on the internet. I mean, I left Twitter because the outrage constantly made me angry, I never joined Facebook or Instagram. I have a low tolerance for toxic. Yet HN, here I am, and have been for years.
I truly wonder, without judgment, why the author thinks that HN is toxic. I doubt he reads this but maybe some people who don't share my impression can guess?
You say that like verbal toxicity is bad. I like a good civil argument, there's nothing better for insight that thought-provoking discourse. And nothing worse than everybody repeating how much they agree with each other (nothing wrong with agreeing, it's just pointless in this context).
discussing different opinions doesn't need to become toxic however, so a civil discourse is possible even on polarizing topics. But having said discourse be civil is important, as otherwise both sides of the argument just get frustrated with no real progress in sight.
(An argument that holds very little water. Fascism/national socialism promotes mixed economies and is very far from libertarianism, which is Thiel's actual political ideology.
https://en.wikipedia.org/wiki/Fascism#Definitions )
I use a Firefox addon called RefControl. You can set it to handle referer differently on different sites. It can block sending referer completely, or send a custom referer string.
It's not easy to find a mobile browser that both:
- does not suck somehow, making me irritated
- and has good privacy options
So I got the message too.
On the other hand, I know we are on HN, but I know hundreds of technical people, but only few of them installs privacy extensions, just the adblock. People don't care I think. I care to the extreme and I have installed uMatrix on desktop. No sane person would do that.
Btw as "soon to have" startup business I need people to inform me where they came from.
Thanks for bringing this to my intention, it never occured to me to replace/remove the headers. RefControl is not working in the latest FF, but there is a new variant called referer-modifier: https://addons.mozilla.org/en-US/firefox/addon/referer-modif...
Because it doesn't link to the article in the title any longer. Whatever asinine reason they have for this referrer block doesn't preclude it from removal for no longer being available. :shrug:
Hacker news is definitely toxic and fairly prone to being unnecessarily down on npm and JavaScript in general. Although HN thinks HN is very intelligent and good at debate, it’s somewhat prone to promoting one opinion and in a very aggressive way. I read it because I like discussions, but they have been getting more and more one sided over time. Unfortunately, most users seem to think that this is reddit in my opinion.
HN is predominantly urban, male, OSS-loving, Trump-hating, NN-supporting, anti-GDPR, socially liberal, and fiscally conservative with tendancies towards old-school (C > JS) and estoteric (Rust > Go) tech.
But every community has some sort of bias. Otherwise, it's not really a community.
Yes, my comments about issues with NN are disagreed with and downvoted to oblivion, but there's very few verbal attacks, and generally well-reasoned arguments.
If I click the link, I get the following message:
"This page is unavailable when linked to fromn ews.ycombinator.com. Please find a less toxic place to spend your time."
Pressing F5 obviously works around this referrer trick, but I find it interesting that someone would (ab)use the HTTP referrer to send a message to visitors from a specific site.
This is quite an innocent one, as it is obvious. But what about news/informational sites that subtly modify their message and influce. At least I would not have noticed.
> It bothers me greatly that npm is a private company. It bothers me that npm is closed-source (the registry and server). It bothers me because I can't contribute. I can only inform the community of the problems.
NPM the repository is not open source? How does a non open source platform ended up being the default package repository for an open source project is a complete mystery (since NPM client IS bundled with node distribution). People should be allowed to run their own NPM mirror ... for without having to pay for a license. I don't have to pay for packagist or pip server, I can only if I want professional support, so what is this?
> They are all very popular “open source” ecosystem tools beholden to a for-profit corporation.
NPM server is not open source to begin with. Its client shouldn't be bundled with node, an open source project. I don't use Wordpress but pretty sure I don't have to pay a license to Wordpress to install its CMS on a server. And github server IS NOT open source.
> My fear is that they are refusing to do something here because they are a startup focused on growth. Their VCs are undoubtably demanding that growth.
It sounds like a sad conclusion, but really, what are other reasonable reasons not to fix that glaring security hole that affects millions of direct and indirect users?
104 comments
[ 8.6 ms ] story [ 1458 ms ] threadhttps://eslint.org/blog/2018/07/postmortem-for-malicious-pac...
The account of one of the eslint maintainers was compromised.
A ledger of hashes of published packages that is run on separate infrastructure and consumed by the client would do just as well as signing for detection of both threats without a lot of complicated issues around third party key material handling, crypto library bugs, and the need for revocation processes.
Note: this is based on experience validating all gems after the yaml scare years ago.
Clicking your heels three times and saying 'GPG', of course, doesn't fix much.
What you advocate in this thread is setting aside defense in depth. Could the attacker have used the stolen credentials to pivot to other machines and ultimately gain access to the GPG keys? Maybe, but it's a hurdle, and not a small one. The more hurdles we can place in the way, the less likely it is that small mistakes cascade into total system failure.
There may be legitimate reasons to not to use package signing, but this is definitely not one of them.
>2018-07-12 18:42 UTC: npm revoked all access tokens generated before 2018-07-12 12:30 UTC.
Does this mean that potentially any version update (of ANY npm package) published between 9:49 and 18:42 could potentially be compromised? Someone's going to have to go through all of them with a fine tooth comb...
The maintainer whose account was compromised had reused their npm password on several other sites and did not have two-factor authentication enabled on their npm account.
I wonder how many accounts the attacker checked before hitting this account. This will definitely get a nice place in the bucket of examples I throw to people, when I see they are still reusing passwords.
There was once a PR open, but it was rejected after sitting idle for over a year.
Yes, you read that right.
https://github.com/npm/npm/pull/4016#issuecomment-76316744
Yes, it doesn't solve all the problems and yes you still have to determine who to trust, but at least it makes it POSSIBLE to trust anything. Currently it's impossible to trust anything that you install—and packages can run arbitrary, unsandboxed code with access to the full filesystem when they are installed. That just seems insane to me.
Yegge's security vs accessibility rant/monograph should be required reading. The NPM team's choice to favor accessibility is a reasonable choice. The trade-offs are significant.
Building a system that is immune against the maintainer's device being compromised puts you into "Reflections on trusting trust" territory. Just sticking two-factor authentication into that process won't change much (though it would of course also mitigate the password reuse vector).
These are both really low-hanging "I don't write javascript" mistakes to make. Most Node.js devs know that the response is a stream, right? Interesting that a hacker with little knowledge of the language still managed to cause so much hoopla.
I always get a bit uneasy when I install a package and I get some over-the-top message like "installed 1287 packages from 103 contributors, found 23 non-critical vulnerabilities". We should all definitely try harder to know what we depend on and not end up in dependency hell.
Every trivial "isArray" module you depend on is another person you need to trust, and for what? It takes a second to write a "utilities.js" file and throw in crap like:
But people don't import micromodules, they import entire dependency trees of arbitrary depth full of micromodules. The greater simplicity of the modules ironically leads to greater complexity in practice.
Personally, I think this is an example of a failure of some people to appreciate the consequences of their preferences.
I've known programmers who couldn't program very well, but they understood the business domain and its rules so well that, while writing verbose unmaintainable crap they could be as productive as better programmers who did not know the domain as well.
Ultimately though, the goal needs to be to build tools where its hard to do something insecure regardless of how we otherwise feel about that programming practice. It can't be that the reason we shouldn't install is-array is because it can lead to catastrophic exploits -- that says something about the ecosystem not the validity of where we choose to draw the line of what merits a library.
Node is cursed in part by its success. In a lot of ways its like the early days of the web, it grew faster than we had time to figure stuff out in. That's OK if we learn quickly and adjust accordingly. We don't have to run node program's with access to everything -- but again, we don't have to run any kind of program with access to everything. Go to Homebrew's website (https://brew.sh). This is a developer tool and what they tell you to do is to blindingly copy a bash line that downloads a file from THE MASTER BRANCH on GitHub and runs it on your system:
Get access to this guy's password and you can compromise tons of systems too. As much as I hate the Mac App Store as a distribution mechanism, there's something to the "sandbox first" programming mentality it incidentally forces its apps into. Maybe we should be thinking more along those lines too.Better to minimise dependencies particularly for trivial functions. Not just for security but for ease of development.
:-)
In seriousness though, there many ways to write an isArray. Just yesterday I was looking at the different things String::repeat() handles on Mozilla's site. What seems trivial can be defined slightly differently everywhere and I tend to reach into the npm bag if I know it's open to interpretation.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
to be fair, there's nothing particular about the branch called 'master'.
> popular, well known registry of snippets
> named, searched, voted on, ranked, written about in top-10 articles
https://www.npmjs.com/
?
It is possible NPM could take the Github route with ssh tokens and only limit NPM publishes to certain authorized computers; a minor step, but you'd have to compromise the computer as well. That could probably be an option in the NPM settings as an extra step.
To me this is the irresponsibility of the NPM maintainers. Require some kind of cryptographic proof you intended to change the code. Signing or TFA or we wont host your w̶o̶r̶m̶ code ...
Travis CI intentionally avoids this sort of vulnerability by never providing encrypted environment variables when running pull requests from forks:
https://docs.travis-ci.com/user/encryption-keys/
This is especially necessary because a pull request can make arbitrary code change, like "print the npm access token", which would then run as part of the test suite and show up in the public logs.
npm emails you by default whenever one of your packages has been published (even by you), so I imagine that would be the most likely way that the problem would be detected in practice.
What makes you say that? The "not recommended" action in their screenshot is to disable 2FA. (I did find the screen a little confusing when setting up 2FA just now, though; it wasn't clear that it was picking between three different actions.)
But that is not all what happened here... Or am I reading this wrong?
I've never once found HN a toxic place in the last 4 years. A place to meet people with different opinions and have discussions about those opinions, yeah, but that's beneficial -- literally the opposite of toxic.
I've got plenty of nits worth picking. I think most people do.
- HN is generally favorable than many other websites, but only because those websites are hopelessly toxic.
- Voting system works well for filtering non-informative contents out, but it does prefer some kinds of informative contents than others.
- Conflicts in HN are not common, but once started they are hard to control. HN is not a good place for managing conflicts; it's only good for mild discussions and it has no effective measure to stop discussions from becoming conflicts.
- Of course there are many different opinions less represented in HN. Some of them can be considered as to an inherent bias of HN.
It depends on the topic. Recently, many topics have laid bare the groupthink attitude of the HN community. Any comments even questioning those views, much less actually expressing an opposite view, are instantly downvoted and derided in replies. This attitude is pervasive, all the way up to management. I am currently rate-limited, for example, because I was against GDPR. I was told by @dang:
”I'd be happy to lift the rate limit after these repetitive GDPR controversy threads have died down.”
In other words, as soon as my opinion is irrelevant because there are no threads about it, I can speak again.
That’s pretty much as toxic as it gets.
I truly wonder, without judgment, why the author thinks that HN is toxic. I doubt he reads this but maybe some people who don't share my impression can guess?
I love it here but sometimes it can be very negative. Any discussion of Bitcoin for instance used to bring out the worst of people.
Same goes for messaging networks (surprised me) and politics (not all that surprising after all.)
I find toxic subthreads from time to time but they are mostly flagged or already dead.
discussing different opinions doesn't need to become toxic however, so a civil discourse is possible even on polarizing topics. But having said discourse be civil is important, as otherwise both sides of the argument just get frustrated with no real progress in sight.
Perhaps partly because Peter Thield is a "fascist"?
https://refererhider.com/?https://www.jwz.org/blog/2017/02/n...
(An argument that holds very little water. Fascism/national socialism promotes mixed economies and is very far from libertarianism, which is Thiel's actual political ideology. https://en.wikipedia.org/wiki/Fascism#Definitions )
Edit. Found it here: https://news.ycombinator.com/item?id=17414652
EDIT: http://www.stardrifter.org/refcontrol/
So I got the message too.
On the other hand, I know we are on HN, but I know hundreds of technical people, but only few of them installs privacy extensions, just the adblock. People don't care I think. I care to the extreme and I have installed uMatrix on desktop. No sane person would do that.
Btw as "soon to have" startup business I need people to inform me where they came from.
Here's an archived copy of the page anyways: http://archive.is/sXaEz
If HN flags this article, then I might be slightly more inclined to agree with the author.
But every community has some sort of bias. Otherwise, it's not really a community.
Yes, my comments about issues with NN are disagreed with and downvoted to oblivion, but there's very few verbal attacks, and generally well-reasoned arguments.
What if, perhaps, they are deservedly [1][2].
[1] https://hackernoon.com/im-harvesting-credit-card-numbers-and...
[2] https://web.archive.org/web/20150515011238/https://nodejs.or...
> If you can't take the heat, get out of the kitchen.
That's exactly what he did, and I guess I don't blame him. The internet can be too much for some people.
Pressing F5 obviously works around this referrer trick, but I find it interesting that someone would (ab)use the HTTP referrer to send a message to visitors from a specific site.
This is quite an innocent one, as it is obvious. But what about news/informational sites that subtly modify their message and influce. At least I would not have noticed.
NPM the repository is not open source? How does a non open source platform ended up being the default package repository for an open source project is a complete mystery (since NPM client IS bundled with node distribution). People should be allowed to run their own NPM mirror ... for without having to pay for a license. I don't have to pay for packagist or pip server, I can only if I want professional support, so what is this?
Somebody has to pay the bills.
NPM server is not open source to begin with. Its client shouldn't be bundled with node, an open source project. I don't use Wordpress but pretty sure I don't have to pay a license to Wordpress to install its CMS on a server. And github server IS NOT open source.
It sounds like a sad conclusion, but really, what are other reasonable reasons not to fix that glaring security hole that affects millions of direct and indirect users?