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

311–320 of 894 posts

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

#311

Post by hypeatei »

a-french-anon wrote: post #258
vsgherzi wrote: post #63

Not to beat a dead horse but I see this again and again with dependencies. Each time I get more worried that the same will happen with rust. I understand the fat std library approach won’t work but I really still want a good solution where I can trust packages to be safe and high quality.

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…

Fat std library mistakes/warts would likely result in third party packages being used anyway.

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

#312

Post by bob1029 »

christophilus wrote: post #295
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…

Honestly, you can get pretty far with just Bun and a very small number of dependencies. It’s what I love most about Bun. But, I do agree with you generally. .NET is about as good as I’ve ever seen for being batteries included. I just hate the enterprisey culture that always seems to pervade .NET shops.

I agree about the culture. If I take my eye off the dev team for too long, I'll come back and we'll be using entity framework and a 20 page document about configuring code cleanup rules in visual studio.

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

#314

Post by pjc50 »

hresvelgr wrote: post #211
pjc50 wrote: post #154

Earlier quoted context omitted.

Package managers are now basically a requirement for language adoption. Doing it manually is not a solution, in an automated world. What is a problem is library quality. Which is downstream of nobody getting paid for it, combined with an optimistic but unrealistic "all packages are equal" philosophy. > High quality C libraries > OpenSSL OpenSSL is one of the ones where there's a ground up rewrite happening because th…

> Package managers are now basically a requirement for language adoption. Doing it manually is not a solution, in an automated world. Absolute nonsense. What does automated world even mean? Even if one could infer reasonably, it's no justification. Appealing to "the real world" in lieu of any further consideration is exactly the kind of mindlessness that has led to the present state of affairs. Automation of dependen…

> What does automated world even mean?

People are trying to automate the act of programming itself, with AI, let alone all the bits and pieces of build processes and maintenance.

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

#317

Post by dxdm »

mort96 wrote: post #176
layer8 wrote: post #149

Earlier quoted context omitted.

Or require the value to specify a unit.

At that point, you're making all your configuration fields strings and adding another parsing step after the json/toml/yaml parser is done with it. That's not ideal either; either you write a bunch of parsing code (not terribly difficult but not something I wanna do when I can just not), or you use some time library to parse a duration string, in which case the programming language and time library you happen to use…

> adding another parsing step after the json/toml/yaml parser is done with it. That's not ideal either

I'd argue that it is ideal, in the sense that it's the sweet spot for a general config file format to limit itself to simple, widely reusable building blocks. Supporting more advanced types can get in the way of this.

Programs need their own validation and/or parsing anyway, since correctness depends on program-specific semantics and usually only a subset of the values of a more simply expressed type is valid. That same logic applies across inputs: config may come from files, CLI args, legacy formats, or databases, often in different shapes. A single normalization and validation path simplifies this.

General formats must also work across many languages with different type systems. More complex types introduce more possible representations and therefore trade-offs. Even if a file parser implements them correctly (and consistently with other such parsers), it must choose an internal form that may not match what a program needs, forcing extra, less standard transformation and adding complexity on both sides for little gain.

Because acceptable values are defined by the program, not the file, a general format cannot fully specify them and shouldn’t try. Its role is to be a medium and provide simple, human-usable (for textual formats), widely supported types, avoid forcing unnecessary choices, and get out of the way.

All in all, I think it can be more appropriate for a program to pick a parsing library for a more complex type, than to add one consistently to all parsers of a given file format.

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

#318

Post by pamcake »

red_admiral wrote: post #305

There's a package manager discussion, but the bit that stands out to me is that this started with a credential compromise. At some point when a project gets big enough like axios, maybe the community could chip in to buy the authors a couple of YubiHSM or similar. I wish that _important keys live in hardware_ becomes more standard given the stakes. Dealing with dependencies is another question; if it's stupid stuff l…

Or those people can (fund) separate repackaging and redistribution with more stringent and formalized review process.

Maybe not all users should pull all packages straight from what devs are pushing.

There's no reason we can't have "node package distributions" like we have Linux distributions. Maybe we should stop expecting devs and maintainers and Microsoft to take responsibility for our supply-chain.

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

#319

Post by wongarsu »

zelphirkalt wrote: post #294
x0x0 wrote: post #158

Earlier quoted context omitted.

You have to admire the person who designed the flexibility to have 87239 seconds not be old enough, but 87240 to be fine.

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

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

#320

Post by berkes »

nesarkvechnep wrote: post #273
whatisthiseven wrote: post #230

Earlier quoted context omitted.

But you know that Java solution will continue working even after we no longer use the Gregorian Calendar, the collapse and annexation of Malaysia to some foreign power, and then us finally switching to a 4-day work week; so it'd be worth it.

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-PatchLibID (note, the older J3EE16-PatchLib-ids aren't compatible), attainable from your regional Oracle account-manager.

Post reply on HN