Live data from Hacker News

We all dodged a bullet

xeiaso.net

411–420 of 498 posts

Re: We all dodged a bullet

#411

How would any normal person know that npmjs.help is phising, but npmjs.com is valid?

It wasn't a "normal person" it was a developer that put this into a README of his package > But beyond the technical aspects, there's something more critical: trust and long-term maintenance. I have been active in open source for over a decade, and I'm committed to keeping Chalk maintained. Smaller packages might seem appealing now, but there's no guarantee they will be around for the long term, or that they won't be…

Does this mean you verify EVERY domain you use? How to even do that?

Shouldn’t this be solved some other ways?

Re: We all dodged a bullet

#412
post #330

Earlier quoted context omitted.

Yes, dependency injection can help although injectors don't have any understanding of whether an object really needs a dependency. But that's not a god object in the sense it's normally meant. For one, it's injecting different objects :)

to be clear, I mean that the DI container/whatever is "the god object" - it holds essentially every dependency and every piece of your own code, knows how to construct every single one, and knows what everything needs. it's the biggest and most complicatedly-intertwined thing in pretty much any application, and it works so well that people forget it exists or how it works, and carrying permission-objects through that…

Yes, I do agree that integration with DI is one way to make progress on this problem that hasn't been tried before.

Re: We all dodged a bullet

#413

>> It sets a deadline a few days in the future. This creates a sense of urgency, and when you combine urgency with being rushed by life, you are much more likely to fall for the phishing link. Procrastination is a security strategy.

When we do the phishing awareness training at $WORK, we are told any sense of urgency is suspicious, especially from an established org. Most would give you at least a month before something as draconian as locking your account.

Re: We all dodged a bullet

#414

Earlier quoted context omitted.

It's harder than it looks. I wrote an essay exploring why here: https://blog.plan99.net/why-not-capability-languages-a8e6cbd...

Thanks, this was a good overview of some of the challenges involved with designing a capability language. I think I need to read up more on how to deal with (avoiding) changes to your public APIs when doing dependency injection, because that seems like basically what you're doing in a capability-based module system. I feel like there has to be some way to make such a system more ergonomic and make the common case of…

In Java DI you can add dependencies without changing your public API using field injection. But really there needs to be a language with integrated DI. A lot of the pain of using DI comes from the way it's been strapped on the side.

Re: We all dodged a bullet

#415
Not a security expert but I don’t think that requesting a reset of your 2FA credentials is reasonable.

I would be very worried about my 2FA provider if they asked me to do this.

And so I would not rate this phishing email a 10/10 at all.

Re: We all dodged a bullet

#416

Is there a tool that you can put between your npm client and npm web servers that serves package versions that are month old and possibly also tracks discovered malware and never serves infected versions?

Artifactory works fairly well. Although admittedly, when a user grabs a new dependency, they're downloading from the npmjs registry like anyone else.

Really, the killer combo would be to have some kind of LLM-based tool that would scan someone's artifactory. Something smart enough to notice that code changed, and there's code for accessing a crypto-wallet, etc. This would be too expensive for npmjs to host for free, but I could see this happen to hosted artifactory dependencies.

Re: We all dodged a bullet

#417

Earlier quoted context omitted.

It wasn't a "normal person" it was a developer that put this into a README of his package > But beyond the technical aspects, there's something more critical: trust and long-term maintenance. I have been active in open source for over a decade, and I'm committed to keeping Chalk maintained. Smaller packages might seem appealing now, but there's no guarantee they will be around for the long term, or that they won't be…

Does this mean you verify EVERY domain you use? How to even do that? Shouldn’t this be solved some other ways?

I do it by reading domain name and comparing it to what I expect it to be. It's not hard and when in doubt I can easily check WHOIS info or search online for references.

This is also easily avaidable by using password manager which will not autofill credentials on a page with a wrong domain.

Edit: And yes, I do this for every link emailed to me that does anythig more high stakes than point me to a newsletter article.

Re: We all dodged a bullet

#418
post #47

Earlier quoted context omitted.

OTOH, doesn't ICANN already sometimes restrict who has access to a given TLD? Would it really be that crazy for them to say "maybe we shouldn't let registrars sell npm. regardless of the TLD", and likewise for a couple dozen of the most obvious targets (google. , amazon. , etc.)? No one needs to pay for these domains if no one is selling them in the first place. I don't love the idea of special treatment for giant co…

>maybe we shouldn't let registrars sell npm. regardless of the TLD Cool, get big enough, become friends with the right people and you can squat an entire name on the internet. What, you're the Nepalese Party for Marxists, you've existed for 70 years and you want to buy npm.np ? Nope, tough luck, some random dude pushes shitty javascript packages over there. Sorry for the existing npm.org address too, we're going to e…

> Dare I remind you that the whole left-pad situation was because Kik, the company, stole (with NPM's assistance because they were big enough and friends with the right people) the kik package ?

And then never even did anything with it.

Re: We all dodged a bullet

#419

I know this isn't really possible for smaller guys but larger players (like NPM) really should buy up all the TLD versions of "npm" (that is: npm.io, npm.sh, npm.help, etc). One of the reasons this was so effective is that the attacker managed to snap up "npm.help"

First thing I do is check any domain that I don't recognize as official. Domain: NPMJS.HELP (85 similar domains) Registrar: Porkbun, LLC (4.84 million domains) Query Time: 8 Sep 2025 - 4:14 PM UTC [1 DAY BACK] [REFRESH] Registered: 5th September 2025 [4 days back] Expiry: 5th September 2026 [11 months, 25 days left] I'd be suspicious of anything registered with Porkbun discount registrar. 4 days ago, means it's fake.…

GoDaddy is in every way a much shadier company yet half the internet is hosted on top of it, would you be okay with them being used? Come on now.

Re: We all dodged a bullet

#420
post #368

Earlier quoted context omitted.

I would say Javascript's lack of a standard library is at least in part responsible for encouraging npm use, things just spiraled out of control from there.

[not a dev] why isn't there the equivalent of "Linux distributions" for npm? I know I know: because developers all need a different set of libs. But if there were thousands of packages required to provide basic "stdlib-like functionality" couldn't there be an npm distribution that you can safely use as a starting point, avoiding importing asinine stuff like 'istrue' (yea I'm kinda joking there). Or is that just what…

So basically, Boost for JavaScript?
Post reply on HN