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

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

441–450 of 796 posts

Re: NPM debug and chalk packages compromised

#441

Post by crabmusket »

palmfacehn wrote: post #189
nine_k wrote: post #30

Earlier quoted context omitted.

Having a module for every little trivial thing allows you to only bring these modules inside the JS bundle you serve to your client. If there's a problem in one trivial-thing function, other unrelated trivial things can still be used, because they are not bundled in the same package. A comprehensive library might offer a more neat DX, but you'd have to ship library code you don't use. (Yes, tree-shaking exists, but s…

Things like this are good illustrations as to why many feel that the entire JS ecosystem is broken. Even if you have a standard lib included in a language, you wouldn't expect a bigger binary because of the standard lib. The JS solution is often more duct tape on top of a bad design. In this case tree shaking, which may or may not work as intended.

I agree with you, but I'd ask- what other language needs to distribute to an unknown runtime environment over the network?

If it's the browser's job to implement the standard library, how do you ensure that all browsers do this in a compliant and timely fashion? And if not, how do you optimise code-on-demand delivery over the internet?

I don't deny there are/could be solutions to this. But historically JS devs have wrestled with these issues as best they can and that has shaped what we see today.

Re: NPM debug and chalk packages compromised

#442

Post by 9dev »

__MatrixMan__ wrote: post #380
DDerTyp wrote: post #52

One of the most insidious parts of this malware's payload, which isn't getting enough attention, is how it chooses the replacement wallet address. It doesn't just pick one at random from its list. It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker's address that is visually most similar to the original one. This is a brilliant…

We should be displaying hashes in a color scheme determined by the hash (foreground/background colors for each character determined by a hash of the hash, salted by that character's index, adjusted to ensure sufficient contrast). That way it's much harder to make one hash look like another.

As someone with red/green vision deficiency: if you do this, please don’t forget people like me are unable to distinguish many shades of colours, which would be very disadvantageous here!

Re: NPM debug and chalk packages compromised

#443

Post by crabmusket »

palmfacehn wrote: post #223
0cf8612b2e1e wrote: post #196

Earlier quoted context omitted.

Given how fat a modern website is, I am not sure that a kitchen sink library would change much. It could actually improve things because there would be fewer redundant libraries for basic functionality. Say there is neoleftpad and megaleftpad - both could see widespread adoption, so you are transitively dependent on both.

There's also the option of including that standard lib with the runtime.

That is exactly what happens today. JS has a standard library. It's just not evenly distributed.

Re: NPM debug and chalk packages compromised

#444

Post by tracker1 »

hunter2_ wrote: post #310
Dayshine wrote: post #262

Earlier quoted context omitted.

Consider adding the widget/action to your quick actions: then to don't need to copy paste at least

For those of us unfamiliar, can you describe the resulting UI pattern? Do you give focus to the password field and then tap a button at the top of the notification shade which automatically types (or gives a choice, if multiple are saved) whatever the password manager has for that site? I'm slightly surprised that something running in that context would know what site the browser has open.

It appears to work... I wasn't even really aware I could add such a thing until the GP comment. I also managed to get the integrated use working... apparently there's now a separate config option for "chrome integration" and "brave integration" etc.

Re: NPM debug and chalk packages compromised

#445

Post by [deleted] »

wer232essf wrote: post #366
winwang wrote: post #68

Earlier quoted context omitted.

Just want to agree with everyone who is thanking you for owning up (and so quickly). Got phished once while drunk in college (a long time ago), could have been anyone. NPM being slowish to get back to you is a bit surprising, though. Seems like that would only make attacks more lucrative.

[dead]

[deleted]

Re: NPM debug and chalk packages compromised

#446

Post by hunter2_ »

dmitrygr wrote: post #404
hunter2_ wrote: post #326

Earlier quoted context omitted.

I would agree if this were one of those `curl | sh` scenarios, but don't we consider things like `brew` to be sufficiently low-risk, akin to `apt`, `dnf`, and the like?

> don't we consider things like `brew` to be sufficiently low-risk, Like ... npm?

I thought getting code into brew is blocked by some vetting (potentially insufficient, which could be argued for all supply chains), whereas getting code into npm involves no vetting whatsoever.

Re: NPM debug and chalk packages compromised

#447

Post by wonger_ »

tracker1 wrote: post #84
thewebguyd wrote: post #32

Earlier quoted context omitted.

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

Worth mentioning... https://jsr.io/@std

How is this different than npm? It looks like a bunch of third-party packages, just prefixed with std.

Re: NPM debug and chalk packages compromised

#448

Post by 9dev »

palmfacehn wrote: post #223
0cf8612b2e1e wrote: post #196

Earlier quoted context omitted.

Given how fat a modern website is, I am not sure that a kitchen sink library would change much. It could actually improve things because there would be fewer redundant libraries for basic functionality. Say there is neoleftpad and megaleftpad - both could see widespread adoption, so you are transitively dependent on both.

There's also the option of including that standard lib with the runtime.

And never ever be able to correct your past mistakes, because some sites might still be using them? The web platform is no .NET runtime you can just update.

Re: NPM debug and chalk packages compromised

#449

Post by crabmusket »

stathibus wrote: post #222
paulddraper wrote: post #29

Earlier quoted context omitted.

Which of these would you prefer to reimplement? Debug, chalk, ansi-styles? --- You can pretend like this is unique to JS ecosystem, but xz was compromised for 3 years.

A common refrain here seems to be that there is no good std lib, which makes sense for something like "chalk" (used for pretty printing?) That being said, let's take color printing in terminal as an example. In any sane environment how complicated would that package have to be, and how much work would you expect it to take to maintain? To me the answer is "not much" and "basically never." There are pretty-print libra…

Skimming chalk's releases page, I did find some quick confirmation of what I expected: recent releases, at least breaking ones, are to do with keeping up with ecosystem changes:

https://github.com/chalk/chalk/releases

5.0: moving to ESM

4.0: dropping support for Node 3.0: indeed some substantive API and functionality changes

I got to 2.0 which added truecolor support. I was amused to note also that 3.0 and 2.0 come with splashy banner images in their GitHub releases

This is a pattern I've seen often with "connector" packages, e.g. "glue library X into framework Y". They get like 10 major versions just because they have to keep updating major versions of X and Y they are compatible with, or do some other ecosystem maintenance.

Re: NPM debug and chalk packages compromised

#450

Post by cyanydeez »

junon wrote: post #9

Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…

maybe you should work with feross to make a website-api that simply gives you a "true/false" on "can I safely update my dependencies right now" that gives an outofband way to mark the current or all versions thereof, of compromised packages.
Post reply on HN