Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

421–430 of 894 posts

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

#421
post #169
post #133

Earlier quoted context omitted.

https://docs.astral.sh/uv/concepts/resolution/#dependency-co... > Define a dependency cooldown by specifying a duration instead of an absolute value. Either a "friendly" duration (e.g., 24 hours, 1 week, 30 days) or an ISO 8601 duration (e.g., PT24H, P7D, P30D) can be used.

My bad. This works for per project configuration, but not for global user configuration.

It should work for global configuration too, please file an issue if you’re observing otherwise.

(Make sure you’re on a version that actually supports relative times, please!)

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

#422

"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…

Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.

[deleted]

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

#423
post #308

Earlier quoted context omitted.

It's what linux distributions do.

Queue appimage or other packed binary and there go your finetuned packages.

Yes, that why those need to be 100% sandboxed by default (ideally a VM), unless they are provided by distro

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

#424
post #50

Genuinely how are you supposed to make sure that none of the software you have on your system pulls this in? It’s things like this that make me want to swap to Qubes permanently, simply as to not have my password manager in the same context as compiling software ever.

While it's not perfect, pinning specific versions and managing all updates directly has been a solid solution for my team. Things can of course still slip through, but we're never vulnerable to these just because there was a new package release and we opted into it by default.

Updating packages takes longer, but we try to keep packages to a minimum so it ends up not being that big deal.

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

#425
post #320

Earlier quoted context omitted.

It probably won’t work correctly from the get go. But it can be debugged everywhere so that’s good.

... and since it was architectured to allow runtime injection-patching of events before they hit the enterprise-service-bus, everyone using this library must first set fourteen ENV vars in their profile, and provide a /etc/java/springtime/enterprise-workday-handling/parse-event-mismatch.jar.patch. Which should fix the bug for you. You can find the patch files for your OSs by registering at Oracle with a J3EE8.4-Patch…

This isn’t even remotely funny.

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

#426
post #347

Earlier quoted context omitted.

Ah, so you've traded the possibility of bad dependencies for certainty.

How can you come to that conclusion, given the specific examples I have given, which are tedious to write, but easy to proof-read and test?

[deleted]

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

#428

Earlier quoted context omitted.

And we also need localization. Each country can have their own holidays

Don't forget about regional holidays, which might follow arbitrary borders that don't match any of the official subdivisions of the country. Or may even depend on the chosen faith of the worker

Pulaski day in Illinois. Or Reds Opening Day in Cincinnati.

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

#429

Earlier quoted context omitted.

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.

[flagged]
Post reply on HN