I don't trust windows with access to sensitive data, much less games. I do all banking, etc on my linux laptop. My desktop is for messing around with AI / ML / games
Whenever I look at a web project, it starts with "npm install" and literally dozens of libraries get downloaded.
The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.
For exactly this reason, when I write software, I go out of my way to avoid using external packages. For example, I recently wrote a tool in Python to synchronize weather-statation data to a local database. [1] It took only a little more effort to use the Python standard library to manage the downloads, as opposed to using an external package such as Requests [2], but the result is that I have no dependencies beyond what already comes with Python. I like the peace of mind that comes from not having to worry about a hidden tree of dependencies that could easily some day harbor a Trojan horse.
I always force myself to do this too. The only 3rd party python library I regularly use is "requests" basically —a dependency that comes with its own baggage, see the recent controversy about "chardet"— but I go out of my way to grab it from pip instead installing it via pip. :-)
Something like this:
try:
import requests
except ImportError:
from pip._vendor import requests
This is good wisdom, and I think this is a strong reason why language and runtime developers should ensure their standard library is (over)complete.
Go does this well, to the point where a lot of people in the community say "you don't need a library" for most use cases, only for e.g. database drivers. This is contrary to what a lot of developers believe, that they need e.g. a REST API library or enterprise application framework as soon as possible.
.NET is great because you use a FOSS library and then a month later the developer changes the licence and forces you to either pay a subscription for future upgrades or swap it out.
C#/.NET is a good example showing no matter how much programmers you have, how much capital you hold, it's still impossible to make a 'batteries-included' ecosystems because the real world is simply too vast.
Say what you want but I can write a production backend without any non-Microsoft dependencies. Everything from db and ORM to HTTP pipeline/middleware to json serialization to auth to advanced logging (OTel). Yes, sometimes we opt for 3rd party packages for advanced scenarios but those are few and far between, as opposed to npm/js where the standard library is small and there is little OOTB tooling and your choices are to reinvent a complex wheel or depend on a package that can be exploited. I argue the .NET model is winning the new development ecosystem.
I agree with you, almost all .NET code I write is within the .NET framework, yet when I look at C# repos, it's disheartening to see so many (new) projects just NuGet this NuGet that.
We have text.json now but I still see people use Newtonsoft JSON.
There's old repo's out there that should be archived and deprecated, yet I see new games use it when the repo is very questionable with automated whitespace or comment commits to keep up the appearance that it is still being maintained[0].
Right now I'm working on a Golang project and the dependency tree is a nightmare to say the least, I hope to be able to rip out the parts I don't need and compile it without the massive bulk that I do not need.
It's very frustrating to want me to trust the author, who trust the author, who trust the author. When I doubt they even audited or looked at what they imported.
I generally limit myself to what's available in my distribution, if the standard library doesn't provide it. But normally I never use requests because it's not worth it I think to have an extra dependency.
This might hold true for easy deps, but (let's be honest who would install is promise) if you have complex or domain specific stuff and you don't have the time to do yourself or the std lib does not have anything then yeh you might still fall into the pit, or you have to trust that the library does not have an supply chain chain issue itself.
> I go out of my way to avoid using external packages.
I go out of my way to avoid Javascript. Because in all my years of writing software, it has 100% of the time been the root cause for vulnerabilities. These days I just use LiveView.
There is a reason. The prevailing wisdom has thus far been: "don't re-invent the wheel", or it non-HN equivalent "there is an app for that". I am absolutely not suggesting everyone should be rolling their own crypto, but there must be a healthy middle ground between that and a library that lets you pick font color.
Anecdata from a JS developer who has been in this ecosystem for 14 years.
I'm actively moving away from Node.js and JavaScript in general. This has been triggered by recent spike in supply chain attacks.
Backend: I'm choosing to use Golang, since it has one of the most complete standard libraries. This means I don't have to install 3rd party libraries for common tasks. It is also quite performant, and has great support for DIY cross platform tooling, which I anticipate will become more and more important as LLMs evolve and require stricter guardrails and more complex orchestration.
Frontend: I have no real choice except JavaScript, of course. So I'm choosing ESBuild, which has 0 dependencies, for the build system instead of Vite. I don't mind the lack of HMR now, thanks to how quickly LLMs work. React happily also has 0 dependencies, so I don't need to switch away from there, and can roll my own state management using React Contexts.
Sort of sad, but we can't really say nobody saw this coming. I wish NPM paid more attention to supply chain issues and mitigated them early, for example with a better standard library, instead of just trusting 3rd party developers for basic needs.
Make sure you have a run of govulncheck [1] somewhere in your stack. It works OK as a commit hook, it runs quickly enough, but it can be put anywhere else as well, of course.
Go isn't immune to supply chain attacks, but it has built in a variety of ways of resisting them, including just generally shorter dependency chains that incorporate fewer whacky packages unless you go searching for them. I still recommend a periodic skim over go.mod files just to make sure nothing snuck in that you don't know what it is. If you go up to "Kubernetes" size projects it might be hard to know what every dependency is but for many Go projects it's quite practical to know what most of them are and get a sense they're probably dependable.
I'm going almost the same direction, for the same reasons. Golang seems very interesting. Rewriting some hobby projects to get an understanding of the language and ecosystem. I'm on Node/webpack now and don't love where things are going.
That won't happen, because time to market is the biggest obstacle between the developers and the monies.
If leftpad, electron, Anthropic, Zed, $shady_library$ gonna help developers beat that obstacle, they'll do it instantly, without thinking, without regret.
Because an app is not built to help you. It's built to make them monies. It's not about the user, never.
Note: I'm completely on the same page with you, with a strict personal policy of "don't import anything unless it's absolutely necessary and check the footprint first".
I'll say depends. Personally, my hobby projects are about me, just shared with the world because I believe in Free Software.
Yet, I'm not obliged to deliver anything to anyone. I'll develop the tool up to the point of my own needs and standards. I'm not on a time budget, I don't care.
Yes, I personally try to reach to the level of best ones out there, but I don't have a time budget. It's a best effort thing.
In reality you are always on a time budget that is correlated with the output of the software you develop.(I.e is it worth it your time?)
I’ve found out that the most important thing is to get feedback early even from yourself using whatever software you develop. If you develop a small effort piece of software you can ship it before other stuff is starting to compete for your time. But if it takes a year or more before even you can make any use of it I guarantee you that the chances of shipping it diminishes significantly.
Other stuff competes for your time(I.e family, other hobbies etc).
I think we tackle the same problem in different ways. For me, if something is not urgent, I do it in a best effort way, and the shipping time doesn't matter.
I generally judge whether I allocate time for something or not depending on the utility and general longevity of the tool. I hack high utility / short life tools, but give proper effort to long life tools I need. As a side-effect, a long life tool can start very crude and can develop over time to something more polished, making its development time pretty elastic and effort almost negligible on the long run.
For me shipping time is both very long (I tend to take notes and design a tool before writing it), yet almost instant: when I decide that the design is enough for V1, I just pull my template and fill in the blanks, getting a MVP for myself. Then I can add missing features one at a time, and polish the code step by step.
Currently I'm contemplating another tool which is simple in idea, but a bit messy in execution (low level / system programming is always like that), but when it's design is over, the only thing I'll do it is to implement it piece by piece, without no time crunch, because I know it'll be long-living tool.
I can time-share my other hobbies, but I have a few of them. I do this for fun. No need to torture myself. And, I can't realize my all ideas. Some doesn't make sense, some doesn't worth it, some will be eclipsed by other things.
This is wild shift that AI allows now. I am building stuff, but not all of it is for public consumption. Monies matter, but, so does my peace of mind. Maybe even more so these days.
i guess it's a market thing? because when i build stuff in a B2B scenario for customers, it is about the customer's users. Because the customer's users are the money.
That's exactly what I'm talking about. The end desire is money, not something else. Not users' comfort, for example. That B2B platform is present because everyone wants money.
Most tools (if not all) charge for services not merely for costs and R&D, but also for profit. Profit rules everything. Users' gained utility (or with the hip term "value") is provided just for money.
Yes, we need money to survive, but the aim is not to survive or earn a "living wage". The target is to earn money to be able to earn more monies. Trying to own all.
The customer is the money. If the customer cares about its users then they are the money.
Then you have the user is the product the customer is the advertiser situation. You please the customer enough to have a product to sell to advertiser.
And this before we even touch deceipt. E.g. lying to the customer to make more money.
companies work for their shareholders
kinda
they work for where the power lies. even shareholders get fucked too.
I think we've pulled way too much towards "software must be a constantly maintained, living item, and users should update often", thus the recklessness with dependencies. This has also exacerbated the other aspects of dependency hell. But not only does this not match reality, it makes projects very vulnerable to this supply chain hijacking stuff.
I think maybe the pendulum needs to swing back a little to being very selective about adding dependencies and expecting releases to be stable for the long term. Users shouldn't have to worry about needing to hack around code that was written just 3-4 years ago.
From a purely aesthetic point of view, this is what I enjoy so much about C and Fortran. You look up a Rust crate and it hasn't been touched in 5 years. That means it's unmaintained and unusable, don't add it to your project or you will have a bad time.
You find a C or fortran library that hasn't been touched in 20 years and (sometimes) it's just because it's complete and there hasn't been any reason to update any parts of it. You can just add it to your project and it will build and be usable immediately. I wish we had more of those.
> but there must be a healthy middle ground between that and a library that lets you pick font color.
When I was doing Perl more I actually highly liked the Mojolicious module for precisely this reason. It had very few external dependencies beyond Perl standard libs and because of this it was possible to use it without needing to be plugged into all of CPAN.
But with the libraries it provided on its own, it was extremely full featured, and it was otherwise very consistent with how you'd build a standard Web app in basically any modern language, so there was less of an issue with lockin if you did end up deciding you needed to migrate away.
I don't know many people who have shit on Java more than I have, but I have been using it for a lot of stuff in the last year primarily because it has a gigantic standard library, to a point where I often don't even need to pull in any external dependencies. I don't love Oracle, but I suspect that at least if there's a security vulnerability in the JVM or GraalVM, they will likely want to fix it else they risk losing those cushy support contracts that no one actually uses.
I've even gotten to a point where I will write my own HTTP server with NIO (likely to be open sourced once I properly "genericize" it). Admittedly, this is more for pissy "I prefer my own shit" reasons, but there is an advantage of not pulling in a billion dependencies that I am not realistically going to actually audit. I know this is a hot take, but I genuinely really like NIO. For reasons unclear to me, I picked it up and understood it and was able to be pretty productive with it almost immediately.
I think a large standard library is a good middle ground. There's built in crypto stuff for the JVM, for example.
Obviously, a lot of projects do eventually require pulling in dependencies because I only have a finite amount of time, but I do try and minimize this now.
Do you really need to roll your own NIO HTTP server? You could just use Jetty with virtual threads (still uses NIO under the hood though) and enjoy the synchronous code style (same as Go)
The answer is no, obviously I could use Jetty or Netty or Vert.x and have done all of those plenty of times; of course any of those would require pulling in a third party dependency.
And it's not like the stuff I write performs significantly better; usually I get roughly the same speed as Vert.x when I write it.
I just like having and building my own framework for this stuff. I have opinions on how things should be done, and I am decidedly not a luddite with this stuff. I abuse pretty much every Java 21 feature, and if I control every single aspect of the HTTP server then I'm able to use every single new feature that I want.
I would say the solution is to make it small and ugly, back to the way it was in the pre-Web-2.0 era, but SQL injections were a thing back then, and they're still a thing today, it's just now there are frameworks of frameworks built on top of frameworks that make fully understanding a seemingly-simple one liner impossible.
The only time I would agree with that is crypto. Don't roll your own crypto. Otherwise there's minimal downside to rewriting basic things directly, and often its unnecessary if your language has a complete standard library. The only place I feel differently is with something like C, where the standard library is far from complete, in that case it makes perfect sense to rely on many third-party libraries, however you should assess them for robustness and security.
I think the continuous churn of versions accelerates this disregard for supply chain. I complained a while back that I couldn't even keep a single version of Python around before end-of-life for many of the projects I work on these days. Not being able to get security updates without changing major versions of a language is a bit problematic, and maybe my use cases are far outside the norm.
But it seems that there's a common view that if there's not continually new things to learn in a programming language, that users will abandon it, or something. The same idea seems to have infected many libraries.
IME there’s a core set of very popular Java libs you can go very far without adopting obscure libraries you’ve never heard of. Eg apache-commons, spring, etc. the bar to adopt a 3p lib seems higher in some ecosystems than others.
How can node scripts write to files, make network requests, etc etc without any standard library? Of course it has a standard library. You could maybe say javascript doesn't have much of a standard library (Array, String, Promise, Error, etc) but js is used with a runtime that will have a standard library.
Lockfiles help more than people realize. If you're pinned and not auto-updating deps, a package getting sold and backdoored won't hit you until you actually update.
The scarier case is Dependabot opening a "patch bump" PR that probably gets merged because everyone ignores minor version bumps.
I mitigate this using a latest -1 policy or minimum age policy depending upon exactly which dependency we're talking about. Combined with explicit hash pins where possible instead of mutable version tags, it's saved me from a few close calls already... Most notably last year's breach of TJ actions
I wish those PRs made by the bot can have a diff of the source code of those upgraded libraries (right in the PR, because even if in theory you could manually hunt down the diffs in the various tags...in practise nobody does it).
Off topic, but this is why the whole "a vibe coded app is a security risk" trope is not quite right to me. That "vibe coder" doesn't know what Claude wrote, but the experienced dev also didn't know what all the packages, libraries and frameworks contained either. Is one worse than the other?
Maybe we should go back to kitchen-sink frameworks so most functionality you need is covered by the fat framework. I'm still using django and it keeps my python project's dependency relatively low :)
I too get worried when I see npm. Luckily I use bun install <everything> so it's all good. In seriousness I do at least have a 7d min age on the packages.
The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.
This is the best reason for letting users install from npm directly instead of bundling dependencies with the project.
I was really saying that if there is a compromised version that gets removed from NPM, then the projects using it do not need to be updated, unless of course they had the compromised version pinned.
Though plenty of orgs centralize dependencies with something like artifactory, and run scans.
That cannot work. Nor should it work. However can we make things so that users don't need to care in the first place?
Note that the above probably isn't 100% answerable. However it needs to be the goal. A few people need to care and take care of this for everyone. Few needs to be a large enough to not get overwhelmed by the side of the job.
Rust is like this too. Every time I open a Rust project I look at Cargo.lock and see hundreds of recursive dependencies. Compared to traditional C or C++ projects it's madness.
> Compared to traditional C or C++ projects it's madness.
Those projects typically rely on an external package manager to handle their dependencies for them. Apt, yum, etc. Otherwise you end up in dependency hell trying to get ./configure to find the development headers of whatever it needs. I don't miss those days. Rust/Cargo is a godsend.
It may be better from a DX perspective, but it's pure pain for distros like Debian who don't want to use cargo at build time to fetch arbitrary dependencies and instead use vetted system versions.
Nearly every package manager does this. You would never get work done if you had to inspect every package. Services like renovate and dependabot do this lifting at no cost to the js developer, and probably do it better.
I've been toying with the idea of a language whose packages have to declare which "permissions" they require (file io, network access, shell...) and devs have to specify which permissions they give to their dependencies.
This is a key vulnerability of package publication without peer review plus curation. Going to have to have many more automated behavioral code coverage analysis plus human reviewers rather than allowing unlimited, instant publication from anyone and everyone.
> There is zero chance that they have checked those libraries for supply chain attacks.
Even if they did, unless the project locked all underlying dependencies to git hashes, all it takes is a single update to one of those and you’re toast.
When I'm looking for a new NPM module to do some heavy lifting, I always look for modules with zero dependencies first. If I can't find one then I look for modules with the fewest dependencies second. No preinstall or postinstall scripts in package.json, not ever. It isn't perfect, but at least we try. We also don't update modules that frequently. If it isn't broken, don't fix it. That has saved us from some recent problems with module attacks.
And now you've figured out the benefit of a language with a strong set of core libraries and an stdlib that come with it.
Go has its opinions and I don't agree with many of them, but the upstream packages combined with golang.org/x allow you to build pretty much anything. And I really like the community that embraced a trend of getting close to zero dependencies for their projects and libraries.
The only dependency I usually have for my projects are C binding or eBPF related. For most of the other parts I can just choose the stdlib.
I'm sorry but does this have anything to do with npm? I just skimmed the article so maybe I missed it. So wordpress doesn't use npm, it doesn't even use composer, therefore this comment feels a bit disconnected. Maybe that's why?
I didn’t downvote it but it doesn’t seem particularly new or insightful. The points are quite shallow. Perhaps people come here for comments that offer an expert opinion or a bit more. As I say I didn’t downvote.
For the moment, governments claim to want only she verification "for the children". Let's be honest: governments like the UK and Germany (to name two) are prosecuting people for posting unwanted opinions, or - heaver forfend - for insulting politicians.
To pursue those prosecutions they need identities. Age verification is the first step towards requiring your real identity in social media.
So they're still getting a million impressions s month, and that's not interesting Anyway, putting something up on Instagram and then also on X - that's pretty low effort, no? Weird decision...
Also: 1500 posts per year, so around 4 per day - a bit much. There just aren't four important topics to talk about each and every day. Honestly, I wouldn't subscribe to that either. Maybe that's part of why their numbers are going down...
I guess I'm a dabbler - I have too many hobbies, none of which I take very seriously. Brewing, dry stone walls, math puzzles, etc.
That said, if you're looking for something meaningful, consider doing something with kids. Technical or not, it doesn't matter. Could be anything from volunteering at a local sports club to teaching part-time at a trade school.
Very mixed feelings on this. On the one hand, yes, soldiers should uphold high standards. On the other hand, war is horrible, things happen, and nothing is blach-and-white.
And on the gripping hand: Years after the fact, with zero evidence, relying solely on malleable human memory - is that really a basis for criminal prosecution?
I love it how they can't think of any other way to pay for parking than via smartphone, but if you just park there without paying, they'll offer you many ways to pay the fine.
They can think of other payment flows, they don't want them because an app gets them data they can resell or abuse.
I was (pleasantly?) surprised when my office parking lot implemented paid parking because it's doable via SMS and webpage (not an installed app). [thankfully my employer is picking up the tab, so I didn't have to do anything beyond providing my license plate numbers]
And sometimes, it seems like there's no fallback if you have no [working] smartphone. I knew someone who had a working smartphone, but a broken camera for few months. Couldn't scan any qrcodes to use these services till the phone was replaced.
The dude was hungry, what was he to do? We can't expect consumers to fix everything with dollar votes. They have lives, families, hobbies, things to do!
don't you understand that this means a data trail to your location and government ID ? connecting to your ability to pay a legal fine? You are consenting to that ?
BS. It's for control and censorship and data harvesting.
Meta alone spend $2 billion lobbying for age-restriction laws, which they tried to hide by pumping it through third parties. We don't know how much the other tech giants spent.
When you see the behemots of US tech coming together you can be sure it isn’t for anything good! These assholes are supporting and enabling the orange clown (a suspected pedophile) and they want us to believe that they suddenly care about the children.
It is like letting a policeman into your house to make sure you are not committing crimes. The methods (installing an AI module behind your defenses against criminal hackers that is programmed to betray you) are too invasive.
Real world analogies to tech usually don't work(I would download a car), but I think in this case it would be more like you hire a servant, and that servant helps you out with whatever you ask, but if your servant sees something absolutely disgusting and illegal, they call the police and tattle on you.
Or another analogy, back in the day, when nearly everyone was taking pictures with film cameras, the person doing the developing of your film would definitely call the cops on you if you had them develop child porn.
They already have one way of doing it therefore we should make a legal carve out to give them additional ways of doing it even though we don't want them to be able to in the first place.
That doesn't make sense. It's a defeatist attitude that serves only to advantage the opponent.
In terms of censorship, it is impossible to confirm that every hash in the database is what the database owner claims it to be.
Its also completely unacceptable for encrypted/private messages, according to some of the top experts on the subject, "Bugs in our Pockets: The Risks of Client-Side Scanning": https://arxiv.org/abs/2110.07450
That's not how that works, last I checked. AIUI it's much more fuzzy. Has to be, being scum doesn't automatically make you an idiot, and a single bit change would make plain old hashes entirely useless.
Insert your favourite dystopia to see where that ends up and how companies benefit from it.
I personally really prefer the "fingerprint" wording for those, but yes. The question is whether there is a workable area on the sliding scale between "too narrowly matching" and "too prone to malfunction/easy to manipulate/unpredictable". I think no, or rather, the point by which you "solve" this, it's not something you can call a "function" anymore. (e.g. heavier machine learning approaches)
I mean, you can do that already, you use your own domain name and can then change email providers at will, in theory.
But maybe you logged in to your domain registrar through google oauth. If your google account is locked you can't now get into your domain's settings to change your MX records.
The real problem isn't the email address itself, it's all the access that google owns on your behalf. Lose access to Google, lose access to everything.
Honestly, I don't trust game producers enough to grant then kernel access. Do you? Really?
reply