I've heard good things about work done by this guy Linus. I'm pretty sure that I've used his work.
I think he comes from a country that borders Russia, so should we be worried?
I've done OSS for decades; mostly by myself, but sometimes, in teams of volunteers.
If anyone has any experience, working in teams of volunteers, it can be ... challenging.
It can definitely work, but not as often as you'd think. If it works, there's usually some "BDFL," or a common goal that has everyone on the same beam. In my case, it was usually the latter.
Not only that, but Linus's parents were politically active communists and young Linus was a pioneer (like a boy scout but for communists). His father also lived in Moscow for several years on two separate occasions.
I don't think Russia (or China, either) has been truly communist, in a long time.
Not sure there are any real communist nations left. It's one of those ideologies that looks good on paper, but falls apart, as soon as humans get added to the soup.
Idealists never seem to account for base human nature.
Your parent comment labeled themselves off-topic but I'd say they were still pretty on it, but you're like way too off-topic. The point isn't whether some country or some people are real communists or not, but that an individual shouldn't be harassed for maintaining open source software and can somehow be linked to some rival of the West.
Being a Young Pioneer or joining the Komsomol was not officially mandatory, but it functioned as a gatekeeper for any kind of advancement. Party membership operated the same way.
So, by themselves, they don't tell you whether the person in question is a communist.
I feel like there's a lot of misunderstanding of this issue in the software community, because primarily, supply chain risk isn't a software or engineering issue. It's a governance issue.
Someone doesn't have to be a bad actor for a project to have supply chain risk. Nor do all who evaluate supply chain risk have the same security posture and evaluate risks the same as others might. The DoD likely has a very different set of risks they evaluate against for their security posture than you do.
Most supply chain risks are not an indictment of somebody's code or somebody's character. A lot of one person projects are risky just because they're only one person. Having a bus factor of one is a supply chain risk in and of itself.
And while most people don't prepare for war while choosing their packages, it's not unreasonable for a military to do so. During a war, the ability for people to govern themselves and their own projects often changes dramatically, even in democratic countries. It is entirely routine for countries to require cooperation by the force of law in war time, even the US can and has forced private companies to cooperate with war efforts. This is probably not in the security posture calculation for most of us. But it is for some.
> So while NPM has over 4 million single person projects, they have about 900,000 maintainers for those 4 million single person projects. This will be an important data point at the end.
Am I missing something or was it not, in fact, an important data point at the end?
But if you had a "perfect" piece of software that used Log4j in 2020, it wouldn't have been perfect for long.
Unfortunately, there's a lot of reasons that software needs maintenance, even if it was thought to be perfect when it was originally written.
Hardware changes. The software landscape changes. Dependencies are deprecated, or are found to have their own problems. Vulnerabilities are discovered. Vulnerabilities are found that aren't even the fault of your software, maybe they are a flaw in the hardware your software runs on, and the only way to fix it is via a software mitigation. These are all real things that happen to otherwise perfect software.
I was once forced to use older (but not deprecated) LTS Ubuntu and I hated it. New software come out and you're gonna want to use them (often forced to use them), and they of course use newer dependencies. I had to do the distribution maintainer job and package a bunch of software myself.
Well, when you talk about a distribution there's a different issue.
The entire Linux ecosystem is constantly shifting with each package releasing new versions, and therefore everything else must be updated to accommodate the changes in the dependency tree.
You could get away with some stuff being only stable versions, but things like mesa, x11, chrome, etc... would still be constantly changing as would their dependency trees.
The DoD is very efficient at finding something they are getting for free and convincing everyone it's in their best interest to pay a team of contractors for it.
It's interesting to see the periodic rediscovery of "capitalism + technology relies on unpaid, voluntary labour", or as the author puts it, "Open source, the thing that drives the world, the thing Harvard says has an economic value of 8.8 trillion dollars".
The one flaw that I see in the author's analysis though is that they don't seem to account for whether the packages accounted for by their source have dependents or monthly downloads. There's *a lot* of dead code out there. When excluding abandoned packages, I bet the picture is still grim, but it might be less so.
It does go in the direction I thought it would though. I'd be curious to see (or to take) a look a little deeper at what those thousand of packages are.
that and, i would argue that npm in particular is filled with lots of small projects and only very few large ones simply by the nature of the ecosystem. it is the wrong place to look. something better would probably be to eg count the contributors on github, or, on npm, analyze project dependencies and distinguish projects that are directly downloaded vs those that are loaded as a dependency. arguably, dependencies can be replaced by the developers of the project using it, so a developer of a dependency disappearing is less dramatic than if you use that project directly.
technically speaking, if you have a large project with many contributors, every contributor is often still only responsible for one small part of the project. linux kernel drivers and subsystems most have their dedicated developers. and very few of them each.
The title of the register article is completely disgusting
> Putin on the code: DoD reportedly relies on utility written by Russian dev
then in the article:
> Hunted Labs told us that it didn't speak to Malinochkin prior to publication of its report today, and that it found no ties between him and any threat actor.
Not necessarily, Australia has a law allowing the government to compel software devs to add backdoors and gag them to prevent people hearing about the backdoors.
Some of the best engineers that I've worked with (in the US and Europe) are Russian. I've also been quite impressed with other former Iron Curtain developers. A lot of Chinese folks I've worked with have been good.
I know that some nations are known for threatening the relatives of expats, to get them to work on their behalf. Not very nice.
But state-sponsored Russian (or other nations, as well) is definitely something to be concerned about. I suspect a number of folks are concerned about the influence of American programmers. The CIA is known for using fairly innocuous employees of NPOs. My father was one.
The FSB is looking for people they can recruit, even here, on HackerNews, too. Look at the HN news history. You will find stories about Russian history or culture. In comments, some people are expressing their fascination with Russia or its culture. This is how FSB identifies potential sympathizers, who are
easy to recruit. Most likely, some of those, who expressed their sympathy under such news articles a year or two ago, are already recruited by FSB.
I've heard good things about work done by this guy Linus. I'm pretty sure that I've used his work.
I think he comes from a country that borders Russia, so should we be worried?
I've done OSS for decades; mostly by myself, but sometimes, in teams of volunteers.
If anyone has any experience, working in teams of volunteers, it can be ... challenging.
It can definitely work, but not as often as you'd think. If it works, there's usually some "BDFL," or a common goal that has everyone on the same beam. In my case, it was usually the latter.
(Off topic.)
Not only that, but Linus's parents were politically active communists and young Linus was a pioneer (like a boy scout but for communists). His father also lived in Moscow for several years on two separate occasions.
I don't think Russia (or China, either) has been truly communist, in a long time.
Not sure there are any real communist nations left. It's one of those ideologies that looks good on paper, but falls apart, as soon as humans get added to the soup.
Idealists never seem to account for base human nature.
Your parent comment labeled themselves off-topic but I'd say they were still pretty on it, but you're like way too off-topic. The point isn't whether some country or some people are real communists or not, but that an individual shouldn't be harassed for maintaining open source software and can somehow be linked to some rival of the West.
Fair point.
But, to be fair, the note about not taking human nature into account, applies everywhere.
> Linus was a pioneer
Being a Young Pioneer or joining the Komsomol was not officially mandatory, but it functioned as a gatekeeper for any kind of advancement. Party membership operated the same way.
So, by themselves, they don't tell you whether the person in question is a communist.
I feel like there's a lot of misunderstanding of this issue in the software community, because primarily, supply chain risk isn't a software or engineering issue. It's a governance issue.
Someone doesn't have to be a bad actor for a project to have supply chain risk. Nor do all who evaluate supply chain risk have the same security posture and evaluate risks the same as others might. The DoD likely has a very different set of risks they evaluate against for their security posture than you do.
Most supply chain risks are not an indictment of somebody's code or somebody's character. A lot of one person projects are risky just because they're only one person. Having a bus factor of one is a supply chain risk in and of itself.
And while most people don't prepare for war while choosing their packages, it's not unreasonable for a military to do so. During a war, the ability for people to govern themselves and their own projects often changes dramatically, even in democratic countries. It is entirely routine for countries to require cooperation by the force of law in war time, even the US can and has forced private companies to cooperate with war efforts. This is probably not in the security posture calculation for most of us. But it is for some.
> So while NPM has over 4 million single person projects, they have about 900,000 maintainers for those 4 million single person projects. This will be an important data point at the end.
Am I missing something or was it not, in fact, an important data point at the end?
And even in projects that are maintained by more than one person, it's usually just a single person responsible for most of the commits.
I find it more concerning that the DoD uses node.
I might be wrong but npm etc feels like a very large attack surface.
The DoD is a huge organization, so I'd guess they use almost everything.
> The DoD is a huge organization
That's an understatement if there ever was one.
https://en.wikipedia.org/wiki/List_of_largest_employers
If they had done an activity check they would have seen that half of all projects have zero maintainers.
software once "perfected" (working well enough long enough) needs NO maintenance. No cleaning. No calibrating/tunning.
updating is a systemic issue, not a per-project matter
Under a microscope, maybe.
But if you had a "perfect" piece of software that used Log4j in 2020, it wouldn't have been perfect for long.
Unfortunately, there's a lot of reasons that software needs maintenance, even if it was thought to be perfect when it was originally written.
Hardware changes. The software landscape changes. Dependencies are deprecated, or are found to have their own problems. Vulnerabilities are discovered. Vulnerabilities are found that aren't even the fault of your software, maybe they are a flaw in the hardware your software runs on, and the only way to fix it is via a software mitigation. These are all real things that happen to otherwise perfect software.
Ironically if you didn’t upgrade from 1.x you didn’t get the new features or the bug you’re referring to
2.x had been out for about six years by the time the vulnerability was discovered.
Maybe we need a Linux distro based on "inactive" software and look how reliably it performs.
I was once forced to use older (but not deprecated) LTS Ubuntu and I hated it. New software come out and you're gonna want to use them (often forced to use them), and they of course use newer dependencies. I had to do the distribution maintainer job and package a bunch of software myself.
s/inactive/stable/
Well, when you talk about a distribution there's a different issue.
The entire Linux ecosystem is constantly shifting with each package releasing new versions, and therefore everything else must be updated to accommodate the changes in the dependency tree.
You could get away with some stuff being only stable versions, but things like mesa, x11, chrome, etc... would still be constantly changing as would their dependency trees.
This reminds me of the observation that adding people to a project doesn't necessarily increase productivity that much...
The DoD is very efficient at finding something they are getting for free and convincing everyone it's in their best interest to pay a team of contractors for it.
The city of Troy kind of got fucked that one time by free shit.
[Relevant xkcd.](https://xkcd.com/2347/)
It's interesting to see the periodic rediscovery of "capitalism + technology relies on unpaid, voluntary labour", or as the author puts it, "Open source, the thing that drives the world, the thing Harvard says has an economic value of 8.8 trillion dollars".
The one flaw that I see in the author's analysis though is that they don't seem to account for whether the packages accounted for by their source have dependents or monthly downloads. There's *a lot* of dead code out there. When excluding abandoned packages, I bet the picture is still grim, but it might be less so.
half way down the page:
> So now, let’s look at the number of maintainers for projects with over 1 million downloads this month.
Fair point, I glossed over that part a bit fast.
It does go in the direction I thought it would though. I'd be curious to see (or to take) a look a little deeper at what those thousand of packages are.
Huh, I just checked stats on ecosyste.ms
It looks they consider as maintainer only those people who listed on package.json, not a real number of contributors on github or anything.
So all conclusions in this post is based on wrong assumption and incorrect data interpretation. That's all you need to know about it.
I think you could list random people on github in your package.json to looks cool in eyes of stats cultists.
that and, i would argue that npm in particular is filled with lots of small projects and only very few large ones simply by the nature of the ecosystem. it is the wrong place to look. something better would probably be to eg count the contributors on github, or, on npm, analyze project dependencies and distinguish projects that are directly downloaded vs those that are loaded as a dependency. arguably, dependencies can be replaced by the developers of the project using it, so a developer of a dependency disappearing is less dramatic than if you use that project directly.
technically speaking, if you have a large project with many contributors, every contributor is often still only responsible for one small part of the project. linux kernel drivers and subsystems most have their dedicated developers. and very few of them each.
The title of the register article is completely disgusting
> Putin on the code: DoD reportedly relies on utility written by Russian dev
then in the article:
> Hunted Labs told us that it didn't speak to Malinochkin prior to publication of its report today, and that it found no ties between him and any threat actor.
They're also from Great Britain which seems to have the most irrational hatred for everything Russian.
Aren't Russian developers on average more susceptible to the "wrench attack" though?
Not necessarily, Australia has a law allowing the government to compel software devs to add backdoors and gag them to prevent people hearing about the backdoors.
https://scarff.id.au/blog/2023/state-actors-can-add-a-backdo...
Many of them don't live in Russia.
Some of the best engineers that I've worked with (in the US and Europe) are Russian. I've also been quite impressed with other former Iron Curtain developers. A lot of Chinese folks I've worked with have been good.
I know that some nations are known for threatening the relatives of expats, to get them to work on their behalf. Not very nice.
But state-sponsored Russian (or other nations, as well) is definitely something to be concerned about. I suspect a number of folks are concerned about the influence of American programmers. The CIA is known for using fairly innocuous employees of NPOs. My father was one.
> Many of them don't live in Russia.
Well Malinochkin does. His GitHub profile says he is located in a suburb 30 minutes from the Kremlin.
Of course, there's a lot of smart software engineers in major cities all around the world.
The FSB is looking for people they can recruit, even here, on HackerNews, too. Look at the HN news history. You will find stories about Russian history or culture. In comments, some people are expressing their fascination with Russia or its culture. This is how FSB identifies potential sympathizers, who are easy to recruit. Most likely, some of those, who expressed their sympathy under such news articles a year or two ago, are already recruited by FSB.
they would probably still fake their identity to hide their tracks.
[dead]
[flagged]