141–150 of 184 posts
Earlier quoted context omitted.
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...
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.
Yeah, the subtle way to plant an idea. It's a crime again to a person have "certain nationalities".
For example, I am an American citizen, but I have extended family in Russia, and I would fully expect a place like DoD to be wary of that solely on the basis that it makes me susceptible to blackmail by Russian govt agencies by threatening my family.
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
A perfected software that had existed >5 years with zero updates, tweaks, ports, or fixes?
Earlier quoted context omitted.
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.
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 differen…
Huh? The DoD would not have used the package if they hadn't read every line, locked it down for updates, and were ready to patch it themselves if needed. Can you really imagine in a war they'd be like "damn, if only there were a second person we also don't trust at all to do this work for us cause otherwise we'd just be SOL"
I've also been in a sealed environment, where I literally had to hand copy jQuery from an internet connected computer on one side of the room to an internal dev computer on the other side of the room... no disks, usb drives, etc allowed. That was a few days of "fun."
Has anyone seen any stats on what happens to a single maintainer project when said person is hit by a bus (or meets some other demise)? With that many data points, there should be enough of them by now to study it. Is the project taken over by another, single developer? Is it replaced by a similar project? Does it just go away?
It depends. More common than getting hit by a bus is that the maintainer loses interest, or doesn't have the time to put into it anymore. When that happens I've seen all of the following happen: * Someone forks the project, and eventually the fork replaces the original * Another, possibly new, project that fills the same niche becomes more popular, and eventually replaces most usages of the first project. * The origi…
Choose what I feel is the best option. Trying to avoid dead packages, but not afraid to deal with older packages if they aren't just stale, but functionally complete. The shift towards ES import statements and TypeScript defs has also influenced my selection process.
I've seen plenty of cases where either a fork or new option effectively takes over. A lot of people are leaning towards Zod over Yue or Hono over Express. There's instances where the dev goes off the rails like with Faker and the community comes together to fork a solution.
All of the above examples definitely happen in practice. I'm guessing many packages all over the place have replaced various dependencies over the years.
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 visualisations could be improved by binning number of maintainer 1 / 2-10 / 11-n or by plotting cumulative distribution (ie. x% of projects have less than y contributors)
Too bad the notion of completed/finished/done software is very weak. In theory, there it nothing wrong with an OSS project made by one person. I would like to see the LOC these one-person projects with >1M downloads have. I suspect most of these are a simple Node/browser/OS API single-file wrappers that are simple to get right and treat it as complete. At the same time such projects are easy to verify upon adding as…
const sleep = (ms) => new Promise(r => setTimeout(r, ms));