Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

Post reply on HN
Print view View original

371–380 of 894 posts

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#371

Post by slavik81 »

latexr wrote: post #225
ghurtado wrote: post #210

Earlier quoted context omitted.

If we're taking suggestions, I'd like to propose "parsec" (not to be confused with the unit of distance of the same name) That way Han Solo can make sense in the infamous quote. EDIT: even Gemini gets this wrong: > In Star Wars, a parsec is a unit of distance, not time, representing approximately 3.26 light-years

> That way Han Solo can make sense in the infamous quote. They explained it in the Solo movie. https://www.reddit.com/r/MovieDetails/comments/ah3ptm/solo_a...

That had more or less been the explanation in the books for decades, and even in George Lucas' notes from 1977:

> It's a very simple ship, very economical ship, although the modifications he made to it are rather extensive – mostly to the navigation system to get through hyperspace in the shortest possible distance (parsecs).

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#372

Post by latexr »

binarymax wrote: post #334
latexr wrote: post #225

Earlier quoted context omitted.

> That way Han Solo can make sense in the infamous quote. They explained it in the Solo movie. https://www.reddit.com/r/MovieDetails/comments/ah3ptm/solo_a...

Making a whole movie just to retcon the parsec misuse in Ep IV was a choice

They made a movie to make money. I doubt anyone holding the purse strings cared one iota if that bit were corrected or not. It’s not really a retcon either because they didn’t change anything.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#373

Post by jeswin »

mrsmrtss wrote: post #265
bob1029 wrote: post #241

"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…

Fully agree with this! I think today .NET is probably the most batteries included platform you can get. This means that even if you use third-party libraries, these typically depend only on first-party dependencies, making it much less likely for something shady to sneak in.

And now with NativeAOT, you can use C# like go - you don't need to ship the CLR.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#374

Post by jeswin »

Imustaskforhelp wrote: post #292
mrsmrtss wrote: post #265

Earlier quoted context omitted.

Fully agree with this! I think today .NET is probably the most batteries included platform you can get. This means that even if you use third-party libraries, these typically depend only on first-party dependencies, making it much less likely for something shady to sneak in.

To me, I really like Golang's batteries included platform. I am not sure about .NET though

C#'s LINQ (code as data, like LISP) wins over golang for any type of data access. Strongly-typed, language-native queries. Go has its own advantages though.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#375

Post by sverhagen »

wongarsu wrote: post #319
zelphirkalt wrote: post #294

Earlier quoted context omitted.

I actually think it is not too bad a design, because seconds are the SI base unit for time. Putting something like "x days" requires additional parsing steps and therefore complexity in the implementation. Either knowing or calculating how many seconds there are in a day can be expected of anyone touching a project or configuration at this level of detail.

Seconds are also unambiguous. Depending on your chosen definition, "X days" may or may not be influenced by leap seconds and DST changes. I doubt anyone cares about an hour more or less in this context. But if you want multiple implementations to agree talking about seconds on a monotonic timer is a lot simpler

I came here to argue the opposite. Expressing it in seconds takes away questions about time zones and DST.

I think you're incorrect to say that second are also ambiguous. Maybe what you mean is that days are more practical, but that seems very much a personal preference.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#376

Post by raddan »

mrsmrtss wrote: post #265
bob1029 wrote: post #241

"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…

Fully agree with this! I think today .NET is probably the most batteries included platform you can get. This means that even if you use third-party libraries, these typically depend only on first-party dependencies, making it much less likely for something shady to sneak in.

With the notable exception of cross-platform audio.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#377

Post by freedomben »

cowl wrote: post #277
postalcoder wrote: post #26

PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scr…

min release age to 7 days about patch releases exposes you to the other side of the coin, you have an open 7 days window on zero-day exploits that might be fixed in a security release

Exactly what I thought too when I read this...

Urgent fix, patch released, invisible to dev team cause they put in a 7 day wait. Now our app is vulnerable for up to 7 days longer than needed (assuming daily deploys. If less often, pad accordingly). Not a great excuse as to why the company shipped an "updated" version of the app with a standing CVE in it. "Sorry we were blinded to the critical fix because set an arbitrary local setting to ignore updates until they are 7 days old". I wouldn't fire people over that, but we'd definitely be doing some internal training.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#378

Post by mikeryan »

berkes wrote: post #220
friendzis wrote: post #189

Earlier quoted context omitted.

Workdays! Think about it, if you set the delay in regular days/seconds the updated dependency can get pulled in on a weekend with only someone maybe on-call. (Hope your timezones and tzdata correctly identifies Easter bank holiday as non-workdays)

> Workdays! This is java script , not Java. In JavaScript something entirely new would be invented, to solve a problem that has long been solved and is documented in 20+ year old books on common design patterns. So we can all copy-paste `{ or: [{ days: 42, months: 2, hours: "DEFAULT", minutes: "IGNORE", seconds: null, timezone: "defer-by-ip" }, { timestamp: 17749453211*1000, unit: "ms"}]` without any clue as to what…

JavaScript Temporal. Not sure knowing what a "workday" is in each timezone is in it's scope but it's the much needed and improved JS, date API (granted with limited support to date)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#379

Post by grey-area »

junon wrote: post #264
a-french-anon wrote: post #258

Earlier quoted context omitted.

Why wouldn't the "fat std" thing work? Yes it's hard to design properly, both in scope and actual design (especially for an unstandardized language still moving fast), but throwing the towel and punting the problem to the "free market" of uncurated public repos is even worse. It's what we call in France "la fête du slip". PS: that's one reason I try to use git submodules in my Common Lisp projects instead of QuickLis…

Because fat std is rigid, impractical, and annoying.

In practice (e.g. Go) it’s actually pretty good and infinitely preferable to third party everything.
Post reply on HN