This is going to become an issue for a lot of managers, not just npm. Npm is clearly a very viable target right now, though. They're going to get more and more sophisticated.
Lock files wouldn't work if they were locking transitive dependencies; otherwise the version solver would not have any work to actually do and you'd have many, many versions of the same package rather than a few versions that satisfy all of the version range constraints.
Lots of good ideas since last week, the one I like most being that published packages, especially those that are high in download count, don't actually go publish for a while until after publishing, allowing security scanners to do their thing.
In the Rust ecosystem, you only publish lock files for binary crates. So yeah then you get churn like https://github.com/cargo-bins/cargo-binstall/releases/tag/v1... bumping transitive deps, but this churn/noise doesn't exist for library crates - because the lock file isn't published for them.
That Cargo.lock will only be used for the library's own CI though (and also for development if you git clone it). It will not be used by downstream dependencies at all.
Cubesats in most cases must have documented materials that are burnt up in the atmosphere upon reentry, for this exact reason. They don't stay up there forever.
I didn't like working with posthog when I had to because the level of analytics they do goes against my personal ethics viewpoint but I do have to say they do very good technical work. The landing page is a good reflection of the skill they have even in the product itself. Very neat landing page, and I chuckled at their "cookie banner".
> the link in the email went to an obviously invalid domain, hovering the mouse cursor over the link in the email would have made this immediately clear, so even clicking that link should have never happened in the first place. red flag 1
The link went to the same domain as the From address. The URL scheme was 1:1 identical to the real npm's.
> but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no? red flag 2
Why wouldn't I be? I don't stay logged into npm at all.
the from: address in every email is an arbitrary and unverified text string that the sender provides, anyone can send an email to anyone else and specify a from: president@whitehouse.gov and that's how it will show up to the recipient
what do you mean by the URL scheme? a URL scheme is the http or https part of it? and for sure the host part of the URL was not the same as the real npm's host part of their URL?
i'm not sure what this comment is trying to accomplish, it parses as FUD
how did you evaluate the sender address via DKIM to get "clean" response? I mean I know there are methods to verify stuff about a received email, DKIM by itself only handles message integrity and not sender details, for that you need to fold in DMARC -- but there are all WILDLY technical details that are certainly not what anyone is gonna do before clicking a link in a message body
> As for URL scheme, I mean the format and layout of URLs - because it was an MITM attack, they matched 1:1.
"scheme" is a well-defined domain term that refers to the e.g. `https://` part of a URL/URI -- but that aside, I still don't get what you're saying here? what is "format and layout of URLs" and how does that relate to "mitm attack"?
to cut to the chase, a malicious email maybe contains a link, to a URL, that a victim can click on. but if that link says it goes to `https://npm.org` then it actually does go to `https://npm.org` and there isn't like any special secret way for an email to hijack or mitm that domain or URL resolution. if the link is actually `https://npn.org` then that's a totally different thing, it's not a mitm attack, there is no concept of "format or layout" of that totally different URL "matching 1:1" with `https://npm.org` -- unless you're talking about something totally different to what I'm understanding?
edit: wait are we talking about an email sent from a domain `npmjs.help`? DKIM and DMARC and URL scheme validation don't even enter the picture here, this was no kind of mitm attack by any definition -- "npmjs.help" is clear-as-day a malicious domain, and any email from it a clear-as-day phishing attempt.. ! it's fine, we're all human and etc. but it just underscores the issue here being minimizing blast radius of failures, and not anything related to any specific user/human
I think you are missing a lot of information I've posted elsewhere in this thread and the original HN post. I didn't minimize anything; I would hope most agree that if anything I've maximized the message as much as I possibly could to prevent further damage.
1. My email client does the validation of certain integrity and security checks and shows a checkmark next to senders that pass. Since npmjs.help was a domain legitimately owned by the attackers, it passed.
2. The link in the email lead to their site at the same domain, most likely performing a MITM between my browser and npm's official servers.
3. You're arguing semantics about "scheme". Please try to understand what I'm attempting to convey: The URLs appeared to match the official npm's site. There was no <a href> trickery. Once I had it in my head (erroneously) that .help was fine, nothing else about the attack stood out as suspicious when it came to the URL or domains.
4. Emails themselves are not MITM attacks, no. I didn't respond to an email with my credentials. I would never do that. But that isn't what I've ever claimed to have happened.
5. The URLs being similar or identical to npm's isn't how they technically achieved the MITM. The URLs being similar was to avoid arousing suspicion.
> The URLs appeared to match the official npm's site.
The domain "npmjs.help" is pretty clearly malicious at a glance, just from the ".help" TLD alone, but yeah as you say
> Once I had it in my head (erroneously) that .help was fine, nothing else about the attack stood out as suspicious when it came to the URL or domains.
well except that presumably you clicked on a npmjs.help link and the new tab ended up at npmjs.com? but yeah it's a tough break, don't mean to needle you, hopefully learning experience
If everyone signed commits with well published keys, -and- if NPM would stop rejecting every PR and feature request for clients to verify signatures from authors that opt in, this problem would not exist for packages from those authors.
Unfortunately the official position of NPM since 2013 is that hashes solve the same security problem as signatures and that the signatures might make non signing package authors second class citizens. So no security for anyone, to avoid scaring off lazy maintainers.
reply