This is very bad PR for Node.js and open source in general.
4
☆ Yσɠƚԋσʂ ☆ - 2day
It's good PR for open source in general because these things are at least being found and reported. With closed source, they will often sit on critical things like this and not let anybody know. There are plenty of instances where security researchers tried to get companies to act on critical vulnerabilities and then ended up publishing the exploits publicly out of frustration.
17
haui - 2day
The most curious fact in this is that closed source helps governments hide backdoors. That is infinitely harder in foss.
6
burlemarx - 2day
I agree from a technical perspective. For political actors, on the other hand, they use the publicity of these security flaws to smear OSS from executives, policy makers and the general public.
Just FYI, I've worked on a big Brazilian state owned tech company and I heard multiple times from top executives sponsored by politicians of how closed source is better for security because the flaws aren't apparent, or because only employees of said company could touch the code base. We devs all knew that was all bullshit, but they use this kind of justification to the wide public in order to justify their shady business deals.
4
haui - 2day
Its dialectics in the end. On one hand you have the improved security through transparency, the objective reduction in bad actors to hide malicious code and the general ability for the masses to access key assets for use and reproduction. On the other hand companies and bad actors use it in a demagogic way to discredit open source.
It is the same as cuba, china and the ussr were (or are in some cases) backwards or different from the west. they have always been objectively better. the west used their backwardness to point fingers and brainwash the masses.
this does not make the states i just mention bad or should tell them to do anything different. it tells you that abusers will always abuse by any means they can. capitalism has the economics of a cancer cell (i love that quote) and it does not have morals, although it uses morals a lot.
From a purely amoral perspective, I have benefits from foss code being foss and from some asshole being less able to put their shit in there without my knowledge and that is all beneficial to me.
There is no world in where foss is a bad idea. if anything, foss is still too forgiving in exploitative measures as in should not be allowed to extract surplus value at all.
To drive this even further, I suggest a marxist license that allows software to be used only in a non extractionary manner. if a software uses that license, they must maintain equal treatment and payment of all profits towards the workers and none towards owners and such. of course, same as gpl the license must be viral and unchangeable.
Can someone please make a marxist gpl? PLEASE!
2
chgxvjh [he/him, comrade/them] - 2day
I think the problem is that a ton of Foss people have internalized that success=getting corpos to use your software. Even Foss enthusiasts who don't have that as their personal goal will mostly look for the opinions of Foss personalities who have succeeded in this way.
You basically have to be addicted to getting exploited for this to work as a volunteer Foss maintainer.
Marxist-GPL is a dead end imho. If you don't want corporate adoption, just don't put a license on it. Debian users might get annoyed but mostly people shouldn't really care about Foss licenses on small projects anyway, no maintainer is going to sue you. Best course of action is imho whatever FFmpeg is doing and turn it up a notch. Be as rude and demanding as possible to corpos that are depending on your software.
Oh the future of your billion dollar corporation depends on a vulnerability in my little project getting patched? Pay up.
They might fork you, at least they are doing something for their money now. And they are in too deep to fork and maintain everything themselves.
2
haui - 1day
I see your point, yet I think that it is not looking at the obvious existence of the gpl (or agpl i think) which essentially means you cant make money off of it and must license derivatives the same way. Going the marxist way would mean massively promoting cooperatives. I think there is a place for it. I might make it myself just to prove it can be done and then see what it does.
2
chgxvjh [he/him, comrade/them] - 1day
I just don't think that written code equals worker power. Ongoing development and maintainance does.
You put a bunch of clauses in your license, how are you enforcing it. You have to refer to the bourgeois legal system. I'm not completely opposed to it, just seems fairly impractical. It isn't my goal in life to be caught up in a decades spanning lawsuit to be eventually awarded 100k in damages (that's assuming I got everything right).
2
☆ Yσɠƚԋσʂ ☆ - 2day
exactly
4
chgxvjh [he/him, comrade/them] - 2day
Yeah with closed source you often very difficult to tell what dependencies they have included but it's almost certain they have some unvetted decencies.
4
Soviet Pigeon - 2day
Why for open source? A lot of important libraries are open source and this for a very long time. Here we have compromised libraries in the npm repository. NodeJS is also used in closed source applications. A supply chain attack could also happen in python. Golang simply uses github, which offers a lot of possibilities for a compromise - also used in this supply chain attack.
Difference is, that in NodeJS people use a lot of packages as dependencies. Even for stupid tasks like the legendary isEven. Its dependancy hell.
4
burlemarx - 2day
I think Python has a better overall philosophy with the batteries included concept. It's good to have a comprehensive set of libraries which don't need to rely so much in third party libraries, or where these third-party project solve very specific problems and are well known. Node.js ecosystem, on the other hand, is a huge mess...
I mean bad PR for open source because those issues are happening more and more frequently. And the widespread use of open source means more good and bad actors are posting their codes in GitHub and most of people who use it aren't aware of all the issues.
2
chgxvjh [he/him, comrade/them] - 2day
Batteries included is long dead in python.
Tinker is dead.
Nobody uses plain urllib
Everyone has been recommending lxml over the built in XML module for as long as I remember.
And this is just observations you could have made a decade ago too. More recently (well 5 years ago) I'd say the most damning thing is the removal of distutils without promoting setuptools to the status of a core library. Python now not even includes the tools to build a python module.
2
CriticalResist8 - 2day
Pythons a huge mess I mean, virtual environments started because just having the wrong libraries together on the system could break either one of them. On newer Linux distros they discourage you from installing pip system wide because the distros rely so much on python you could break something. So instead you do everything through venvs which is a cool mess to sort out when you want something to work system wide and it has to go through the venv.
Or some libraries exist as apt package but only like 10 of them it seems so it's just easier to set up a venv anyway.
And upgrades to python not being incremental meaning you need like 3 different versions of it installed because this one program needs 3.11 not 3.12, remembering which one to call, remembering which one needs to be the default system wide and making sure it stays that way...
3
chgxvjh [he/him, comrade/them] - 2day
And you have to install pip first too. At least they decided to include venv at some point.
1
burlemarx - 1day
Good to know... I don't use Python very often, so I'm always a bit oblivious of the recent changes. I'm mainly a Java developer (or Kotlin, when the employer is generous and let me pick the language). In this regard, JVM ecosystem seems to be a bit less chaotic. Maven and Gradle approach seem to be less of a mess than what I find in other ecosystems. The main issues on this ecosystem are some widespreadly used behemoths like Spring framework and Java EE, which often encapsulate and integrate other libraries in all sorts of creative ways and which can cause a big dependency hell if devs don't consider carefully their choices.
By the way, which is the better tool for virtual envs in Python, nowadays? Pipenv or venv?
2
chgxvjh [he/him, comrade/them] - 1day
I'd Java is more batteries included than python (not sure how that has been changed by Java 9 and later).
I never liked any frameworks that take over the main method. My first instinct working with Java frameworks was always to find the main method and use the debugger to step through all the code until I get to my code. Then try to make sense of everything in between.
Best virtual env tool is python right now is probably uv. Will be devastating when astral decides they need to start making money.
2
Soviet Pigeon - 1day
I think Python has a better overall philosophy with the batteries included concept.
But still you have dependency hell there. NodeJS ecosystem is a mess but I wouldn't say it python is that much better. All this virtual environment stuff is annoying as well. And also making a mistake while typing a package name to install can also lead to a compromise. However my point is, that this all is not a bad PR for open source.
NodeJS is a framework. And the language used in NodeJS is open source as well. And this is normal. C, C++, Python, Rust, Perl etc. are free to use. How can it be a bad for open source, if there are security risks in the ecosystem of a language?
And the widespread use of open source means more good and bad actors are posting their codes in GitHub and most of people who use it aren't aware of all the issues.
Look here. Is this also bad for open source? I mean, this are security problems. GitHub is just a repository hosting provider. Even if my repo is private, the same things could happen.
And we are talking about libraries. It is almost normal, that libraries used in a project have a open source licence. While it is not that normal, that open source software is used.
I think it is again bad PR for npm. But not for open source. And indeed, if I find a cool software but it is based on NodeJS, I will rather not use it. The ecosystem is bad and it is still JavaScript.
2
haui - 2day
Do we know yet why this has happened? With xz it was supposed to be a state actor because of the tons of resources that were used to implement this and likely it had a single, unidentifiable target (maybe a government agency, who knows). Or maybe it is microsoft trying to keep open source OSs in check?
3
chgxvjh [he/him, comrade/them] - 2day
It's just bound to happen in the NPM ecosystem.
I'm really surprised this didn't happen frequently until recently. The xz incident was very high effort compared to this.
NPM is basically anonymous, no vetting, no quality control. And it's very common to have thousands of NPM packages installed. Nobody is checking all of that.
yogthos in technology
GitLab discovers widespread npm supply chain attack
https://about.gitlab.com/blog/gitlab-discovers-widespread-npm-supply-chain-attack/JavaScript is the Windows of languages.
lol truly
This is very bad PR for Node.js and open source in general.
It's good PR for open source in general because these things are at least being found and reported. With closed source, they will often sit on critical things like this and not let anybody know. There are plenty of instances where security researchers tried to get companies to act on critical vulnerabilities and then ended up publishing the exploits publicly out of frustration.
The most curious fact in this is that closed source helps governments hide backdoors. That is infinitely harder in foss.
I agree from a technical perspective. For political actors, on the other hand, they use the publicity of these security flaws to smear OSS from executives, policy makers and the general public.
Just FYI, I've worked on a big Brazilian state owned tech company and I heard multiple times from top executives sponsored by politicians of how closed source is better for security because the flaws aren't apparent, or because only employees of said company could touch the code base. We devs all knew that was all bullshit, but they use this kind of justification to the wide public in order to justify their shady business deals.
Its dialectics in the end. On one hand you have the improved security through transparency, the objective reduction in bad actors to hide malicious code and the general ability for the masses to access key assets for use and reproduction. On the other hand companies and bad actors use it in a demagogic way to discredit open source.
It is the same as cuba, china and the ussr were (or are in some cases) backwards or different from the west. they have always been objectively better. the west used their backwardness to point fingers and brainwash the masses.
this does not make the states i just mention bad or should tell them to do anything different. it tells you that abusers will always abuse by any means they can. capitalism has the economics of a cancer cell (i love that quote) and it does not have morals, although it uses morals a lot.
From a purely amoral perspective, I have benefits from foss code being foss and from some asshole being less able to put their shit in there without my knowledge and that is all beneficial to me.
There is no world in where foss is a bad idea. if anything, foss is still too forgiving in exploitative measures as in should not be allowed to extract surplus value at all.
To drive this even further, I suggest a marxist license that allows software to be used only in a non extractionary manner. if a software uses that license, they must maintain equal treatment and payment of all profits towards the workers and none towards owners and such. of course, same as gpl the license must be viral and unchangeable.
Can someone please make a marxist gpl? PLEASE!
I think the problem is that a ton of Foss people have internalized that success=getting corpos to use your software. Even Foss enthusiasts who don't have that as their personal goal will mostly look for the opinions of Foss personalities who have succeeded in this way.
You basically have to be addicted to getting exploited for this to work as a volunteer Foss maintainer.
Marxist-GPL is a dead end imho. If you don't want corporate adoption, just don't put a license on it. Debian users might get annoyed but mostly people shouldn't really care about Foss licenses on small projects anyway, no maintainer is going to sue you. Best course of action is imho whatever FFmpeg is doing and turn it up a notch. Be as rude and demanding as possible to corpos that are depending on your software.
They might fork you, at least they are doing something for their money now. And they are in too deep to fork and maintain everything themselves.
I see your point, yet I think that it is not looking at the obvious existence of the gpl (or agpl i think) which essentially means you cant make money off of it and must license derivatives the same way. Going the marxist way would mean massively promoting cooperatives. I think there is a place for it. I might make it myself just to prove it can be done and then see what it does.
I just don't think that written code equals worker power. Ongoing development and maintainance does.
You put a bunch of clauses in your license, how are you enforcing it. You have to refer to the bourgeois legal system. I'm not completely opposed to it, just seems fairly impractical. It isn't my goal in life to be caught up in a decades spanning lawsuit to be eventually awarded 100k in damages (that's assuming I got everything right).
exactly
Yeah with closed source you often very difficult to tell what dependencies they have included but it's almost certain they have some unvetted decencies.
Why for open source? A lot of important libraries are open source and this for a very long time. Here we have compromised libraries in the npm repository. NodeJS is also used in closed source applications. A supply chain attack could also happen in python. Golang simply uses github, which offers a lot of possibilities for a compromise - also used in this supply chain attack.
Difference is, that in NodeJS people use a lot of packages as dependencies. Even for stupid tasks like the legendary isEven. Its dependancy hell.
I think Python has a better overall philosophy with the batteries included concept. It's good to have a comprehensive set of libraries which don't need to rely so much in third party libraries, or where these third-party project solve very specific problems and are well known. Node.js ecosystem, on the other hand, is a huge mess...
I mean bad PR for open source because those issues are happening more and more frequently. And the widespread use of open source means more good and bad actors are posting their codes in GitHub and most of people who use it aren't aware of all the issues.
Batteries included is long dead in python.
Tinker is dead.
Nobody uses plain urllib
Everyone has been recommending lxml over the built in XML module for as long as I remember.
And this is just observations you could have made a decade ago too. More recently (well 5 years ago) I'd say the most damning thing is the removal of distutils without promoting setuptools to the status of a core library. Python now not even includes the tools to build a python module.
Pythons a huge mess I mean, virtual environments started because just having the wrong libraries together on the system could break either one of them. On newer Linux distros they discourage you from installing pip system wide because the distros rely so much on python you could break something. So instead you do everything through venvs which is a cool mess to sort out when you want something to work system wide and it has to go through the venv.
Or some libraries exist as apt package but only like 10 of them it seems so it's just easier to set up a venv anyway.
And upgrades to python not being incremental meaning you need like 3 different versions of it installed because this one program needs 3.11 not 3.12, remembering which one to call, remembering which one needs to be the default system wide and making sure it stays that way...
And you have to install pip first too. At least they decided to include venv at some point.
Good to know... I don't use Python very often, so I'm always a bit oblivious of the recent changes. I'm mainly a Java developer (or Kotlin, when the employer is generous and let me pick the language). In this regard, JVM ecosystem seems to be a bit less chaotic. Maven and Gradle approach seem to be less of a mess than what I find in other ecosystems. The main issues on this ecosystem are some widespreadly used behemoths like Spring framework and Java EE, which often encapsulate and integrate other libraries in all sorts of creative ways and which can cause a big dependency hell if devs don't consider carefully their choices.
By the way, which is the better tool for virtual envs in Python, nowadays? Pipenv or venv?
I'd Java is more batteries included than python (not sure how that has been changed by Java 9 and later).
I never liked any frameworks that take over the main method. My first instinct working with Java frameworks was always to find the main method and use the debugger to step through all the code until I get to my code. Then try to make sense of everything in between.
Best virtual env tool is python right now is probably uv. Will be devastating when astral decides they need to start making money.
But still you have dependency hell there. NodeJS ecosystem is a mess but I wouldn't say it python is that much better. All this virtual environment stuff is annoying as well. And also making a mistake while typing a package name to install can also lead to a compromise. However my point is, that this all is not a bad PR for open source.
NodeJS is a framework. And the language used in NodeJS is open source as well. And this is normal. C, C++, Python, Rust, Perl etc. are free to use. How can it be a bad for open source, if there are security risks in the ecosystem of a language?
Look here. Is this also bad for open source? I mean, this are security problems. GitHub is just a repository hosting provider. Even if my repo is private, the same things could happen.
And we are talking about libraries. It is almost normal, that libraries used in a project have a open source licence. While it is not that normal, that open source software is used.
I think it is again bad PR for npm. But not for open source. And indeed, if I find a cool software but it is based on NodeJS, I will rather not use it. The ecosystem is bad and it is still JavaScript.
Do we know yet why this has happened? With xz it was supposed to be a state actor because of the tons of resources that were used to implement this and likely it had a single, unidentifiable target (maybe a government agency, who knows). Or maybe it is microsoft trying to keep open source OSs in check?
It's just bound to happen in the NPM ecosystem.
I'm really surprised this didn't happen frequently until recently. The xz incident was very high effort compared to this.
NPM is basically anonymous, no vetting, no quality control. And it's very common to have thousands of NPM packages installed. Nobody is checking all of that.