- It's cute that you truncated the most important part of the other commenter's message; "your security failure is that you use a package manager [that allows third-parties push arbitrary code into your product with no oversight]."
> I'd wager a large portion of people with `npm` don't actually realize they have `npm`.
Recklessness is not a defense.
> But the fact is that you can do something like `brew install foo` and foo has a dependency that has a dependency that has node as a dependency.
That's good to know. I've never looked at brew and wasn't planing on using it, but I will stay away from it in the future. It sounds like you learned your lesson though, right?
Because if you haven't, that sounds like negligence. You can't be unaccountable for your actions by admitting that you did not expect those outcomes when you did not do your due diligence. And if you don't hold yourself accountable, then you sure aren't about to hold others accountable either. So your whole ecosystem is screwed.
> Yes, this is victim blaming. Just in the same way people blame a rape victim for what they wear.
Not even remotely. I can say and it's bad for people to abuse exploits and they don't deserve that. At the same time, if I put my private key without a passphrase into the public, or commit secrets to git and share them with the public, I am being negligent.
You are leaving your car unlocked with the windows rolled down in a dodgy part of town overnight. And when it's gone/pilfered in the morning, it's completely fair to say that you did a stupid thing.
We can say that is negligent without saying that you deserved it or that it ought to have happened. And it's absolutely okay for me, or anybody else, to say that you should have known better, without you comparing me to a rape apologist.
> In the real world nobody can read all the lines of code. There's just too many lines of code!
I don't know why you went on that rant when you quoted me talking about "trust". I wouldn't need trust if I could fully understand everything about every machine I use and only rely on myself.
> So stop this bullshit rhetoric of "know what you're running" because it is ignoring the reality of the situation.
Naw, it isn't. I trust packages from my operating system's package manager. The issues we see with left-pad and shai-hulud, have never and will never happen to me using those packages because they simply do not accept the kinds of garbage people put up on npm, or brew apparently as you pointed out.
I avoid running stuff like on-my-zsh because I don't have the patience to audit that and I certainly don't want to run untrusted stuff in my shell as root. But it's a very popular package because people, like you, have a greater risk tolerance. And that's fine, as long as you accept the consequences of that risk tolerance. You aren't paying for support or liability, you aren't reading the code, you are putting trust in random sources and hoping that things work out.
If you want the luxury running untrusted code as root, or the luxury of leaving your car open in a dodgy part of town overnight, then maybe maybe what you want is a surveillance state, idk. There is a cost to that. A tradeoff. If that's what you want and that's your goal, then I can't stop you. But it's you could also just ... not do such risky things.
- I've heard the term used for servers before but not version control repositories. I just don't understand what it would mean for a git repo to be a cattle vs a pet. Like what is an example of a cattle repo vs a pet repo. The metaphore just sounds like gibberish to me idk.
Unless all it means is that that you can have more than a few like the other commenter said but I didn't think that was what the metaphore meant with respect to servers so again I have no idea lol
- I made a service using something like a 64 bit wide ULID but there was never a presumption that data is be inserted or updated earlier than the most recent record.
If the domain is modeling something like external events (in my case), and that external timestamp is packed into your primary key, and you support receiving events out of chronological order, then it just follows that you might insert stuff ealrier than you latest record.
You're gonna have problems "backdating" if you mix up time of insertion with when the event you model actually ocurred. Like id you treat those as the same thing when they aren't.
- At some point you must be open to being compelled to read code you run or ship. Otherwise, if that's to hard, then I don't know what to tell you. We'll just never agree.
If you find a better solution than being responsible for what you do and who you trust, I'm all for it. Until then, that's part of the job.
When I was a junior, our company payed a commercial license for some of the larger libraries we used and it included support. Or manage risk by using fewer and more trustworthy projects like Django instead of reaching for a new dependency from some random person every time you need to solve a simple problem.
> What no appetite? I just don't like your solution.
When I say "appetite" I am being very deliberate. You are hungry but you won't eat your vegetables. When you say "I just don't like your vegetables", then you aren't that hungry. You don't have the appetite. You'd rather accept the risk. Which is fine but then don't complain when stuff like this happens and everyone is compromised.
- I agree with you that I shouldn't have to treat my libraries like untrusted code. I don't know what the rest of your comment means. I don't see how I'm preventing anybody from looking at other solutions to npm, they just don't want to do it because it's hard. And I have similar criticisms for cargo as it just copies npm and inherits all of its problems. I hate that.
npm has had a bad ecosystem since its inception. The left-pad thing being some of my earliest memories of it [1]. So none of this is new.
But all of this is still an issue because it's too convenient and that's the most important thing. Even cargo copies npm because they want to be seen as convenient and the risk is acknowledged. Nobody has the appetite to be held accountable for who they put their trust in.
- > There were no code assist tools in 2022, but jobs disappeared.
In 2020 there was a global pandemic called COVID-19 that had a pronounced affect on the world economy. Stimulus cheques were given to companies to keep them afloat through this time. Tech companies spent that new capital on hiring and them layed off a lot of workers when they weren't able to sustain them.
A big reason you saw layoffs is because we had massive hiring sprees from short term capital through stimulus cheques.
These days, when a company tells you they are laying off good workers and replacing them, with software that cannot fact check its output, because their audience cannot tell the difference, you should believe them and consider if that is really what you want the world to become.
- It's telling that you compare specialized creative work, like making art, to "jobs" like standing in an elevator.
Nobody would miss washroom attendants disappearing either. That is different from automating away the stuff that makes life interesting. Like AI startups telling you that their robot will spend time with your friends and family, so you don't have to. Being disgusted by that is not being a luddite, it's being a well adjusted human with aspirations beyond doomscrolling AI slop on tiktok/youtube.
- It isn't victim blaming. People like you make it impossible to avoid attacks like these because you have no appetite for a better security model.
I run npm under bubblewrap because npm has a culture of high risk; of using too many dependencies from untrusted authors. But being scrupulous and responsible is a cost I pay with my time and attention. But it is important because if I run some untrusted code and am compromised it can affect others.
But that is challenging when every time some exploit rolls around people, like you, brush it off as "unlucky". As if to say it's inavoidable. That nobody can be expected to be responsible for the libraries they use because that is too hard or whatever. You simply lack the appetite for good hygene and it makes it harder for the minority of us who care about how our actions affect others.
- They aren't "bitching and moaning" they are moving communities and platforms. GitHub is user hostile run by a company with a pattern for that. Alternatives to GitHub exist and supporting them is not "bitching and moaning", it's building and creating. The fact you can't or won't recognize that is telling.
- The homepage for this project has this video [1] under the heading "See it in action". It starts off with background music that progressively gets lounder and at about 30s the vocals start to drown out the narrator. Why do people do this? Did nobody watch this video before uploading it? What was going through the mind of whoever made this video? Wild.
- Not even remotely.
There is no Obama or Biden counterpart to Trump's extrajudicial killings in the Venezuelan coast. Nor Trump's coercion over private industry through his tariffs and lawsuits. Even the far-right's fictions about foreign leaders buying access to Biden through Hunter is so incredibly tame to how Trump does this stuff in public with his crypto or like when talking to that Indonesian leader the other day -- that whole weird "I am a good boy" thing from Eric Trump.
Equivocating these things is a derangement syndrome entirely of its own design.
- > The commits are imperfect steps along the way.
The workflow you're describing here is fine for staging or stashing or commits that you don't intend to publish. I'll sometimes commit something unfinished, then make changes and either stash those if it doesn't work out, or commit with --amend (and sometimes --patch) to make a single commit that is clean and coherent. The commits aren't always small, but they're meaningful and it's easier to do this along the way than at the very end when it's not so clear or easy to remember all the details from commits that you made days ago.
> It seems some people treat every commit like it's its own little tidy PR
Pull requests are not always "little". But I'm nitpicking.
It sounds like a big difference between the workflows is that you don't amend or stash anything locally along the way. I guess I find it easier and more valuable to edit and squash changes locally into commits before publishing them. Instead of at the very end as a single pull request. For me, I can easily document my process with good commit messages when everything is fresh in my mind.
The end result is that some commits can be pretty big. Sometimes there is no good opportunity to break them down along the way. That is part of the job. But the end result is that these problems concerning a messy history shouldn't be there. The commits I write should be written with the intent of being meaningful for those who might read it. And it's far easier to do that along the way then at the end when it's being merged. So it's difficult to understand some of the complaints people make when they say it's confusing or messy or whatever.
Even if requirements change along the way while the pull request is open, and more commits are added as a response. I've just never had a situation come up where I'm blaming code or something and looking back at the commit history and struggling to understand what was going on in a way where it would be more clear if it had been squashed. Because the commits are already clean and, again, it's just easier to do this along the way.
But again, I use `git commit --verbose --amend --patch` liberally to publish commits intentionally. And that's why it feels like a bit of busywork and violence when people advocate for squashing those.
- > If you want lessons learned put it in a wiki or a special branch.
You already have the information in a commit. Moving that to another database like a wiki or markdown file is work and it is lossy. If you create branches to archive history you end up with branches that stick around indefinitely which I think most would feel is worse.
> Main should be a clear, concise log of changes.
No, that's what a changelog is for.
You can already view a range of commits as one diff in git. You don't need to squash them in the history to do that.
I am beginning to think that the people who advocate for squashing everything have `git commit` bound to ctrl+s and smash that every couple minutes with an auto-generated commit message. The characterization that commits are necessarily messy and need to be squashed as to "minimize the cognitive load" is just not my experience.
Nobody who advocates for squashing even talks about how they reason about squashing the commit messages. Like it doesn't come into their calculation. Why is that? My guess is, they don't write commit messages. And that's a big reason why they think that commits have high "cognitive load".
Some of my commit messages are longer than the code diffs. Other times, the code diffs are substantial and there are is a paragraph or three explaining it in the commit message.
Having to squash commits with paragraphs of commit messages always loses resolution and specificity. It removes context and creates more work for me to try to figure out how to squash it in a way where the messages can be understood with the context removed by the squash. I don't know why you would do that to yourself?
If you have a totally different workflow where your commits are not deliberate, then maybe squashing every merge as a matter of policy makes sense there. But don't advocate that as a general rule for everyone.
- The proof of work isn't really the crux. They've been pretty clear about this from the beginning.
I'll just quote from their blog post from January.
https://xeiaso.net/blog/2025/anubis/
Anubis also relies on modern web browser features:
- ES6 modules to load the client-side code and the proof-of-work challenge code.
- Web Workers to run the proof-of-work challenge in a separate thread to avoid blocking the UI thread.
- Fetch API to communicate with the Anubis server.
- Web Cryptography API to generate the proof-of-work challenge.
This ensures that browsers are decently modern in order to combat most known scrapers. It's not perfect, but it's a good start.
This will also lock out users who have JavaScript disabled, prevent your server from being indexed in search engines, require users to have HTTP cookies enabled, and require users to spend time solving the proof-of-work challenge.
This does mean that users using text-only browsers or older machines where they are unable to update their browser will be locked out of services protected by Anubis. This is a tradeoff that I am not happy about, but it is the world we live in now.
- I scrolled down the page to figure out why all the hate, and the first link is to a page on Request Smuggling.
Maybe I'm out of the loop but isn't request smuggling a vulnerability in HTTP proxies that try to convert HTTP2 to HTTP1? Why not showcase vulnerabilities in the HTTP1 spec that are solved in HTTP2?
A doomsday clock for a vulnerability in a bad http proxy, doing something that should probably never be attemped anyway, is a bit dramatic.
- This is well known to be solved by using generational indexes. Its not a big deal. The author's entire post is an overreaction/rage-bait.
Basically any data structure like this where you want it relocatable in memory is going to use indirection like indexes or something instead of pointers. Its a very common use case outside of rust.
- My usage isn't high. I was rate limited to like 5 requests per minute. It was a repo with several small files.
And seriously if they keep this up, with limits on their web interface but leave unauthenticated cloning allowed, I'd rather clone the repo than log in.
GitHub code browsing went south since microsoft bought them anyway. Having a simple proxy that clones a repo and serves it would solve problems with rate limits and their awful UX.
- I encountered this on github last week. Very agressive rate limiting. My browser and IP is very ordinary.
Since Microsoft is struggling to make ends meet, maybe they could throw a captcha or proof of work like Anubis by xe iaso.
They already disabled code search for unauthenticated users. Its totally plausible they will disable code browsing as well.
- Again, argument parsing is not that hard most of the time. You dont have to make your own conventions. Thats just weird.
If youve never thought about it, it might seem like you need an off-the-shelf dependency. But as programmers sometimes we should think a bit more before we make that decision.
- I'm thankful argparse exists in pythons stdlib. But argument parsing is not that hard especially for simpler programs. programmers should be able to think for a minute and figure it out instead of always reaching for clap, thats how you get dependency hell.
Argument parsing, in partucular, is a great place to start realizing that you can implement what you need without adding a dozen dependencies
> Rob studied the man's face and vaguely remembered him as Ronnie Lockwood, someone he would occasionally see at Sunday School as a boy and who he was told to be kind to as he was a "bit different".
> Ronnie was then almost 30 and had been without a home from the age of 15, living in and around Cardiff and moving from job to job - Rob would sometimes see him at a youth club he ran.
> The pair planned to let him stay until the day after Christmas, but when the day came, they couldn't bring themselves to cast Ronnie out and sought advice from the authorities.
You aren't entirely wrong, but this wasn't a random person and they did contact a homeless centre for advice.
Given that Ronnie had apparently already gone through some sort of system to end up at a "school for subnormal boys", it seems pretty clear that Ronnie lived a much better life through this family's actions and generosity.