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

221–230 of 796 posts

Re: NPM debug and chalk packages compromised

#221

Post by Joker_vD »

a022311 wrote: post #169

After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.

Mmm. But how does the package registry know which signing keys to trust from you? You can't just log in and upload a signing key because that means that anyone who stole your 2FA will log in and upload their own signing key, and then sign their payload with that.

I guess having some cool down period after some strange profile activity (e.g. you've suddenly logged from China instead of Germany) before you're allowed to add another signing key would help, but other than that?

Re: NPM debug and chalk packages compromised

#222

Post by stathibus »

paulddraper wrote: post #29
stathibus wrote: post #18

As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?

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 libraries for OS terminals written in compiled languages from 25 years ago that still work just fine.

So, what else is wrong with javascript dev where something as simple as coloring console text has 32 releases and 58 github contributors?

Re: NPM debug and chalk packages compromised

#223

Post by palmfacehn »

0cf8612b2e1e wrote: post #196
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…

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.

Re: NPM debug and chalk packages compromised

#224

Post by notmyjob »

niwtsol wrote: post #214
notmyjob wrote: post #184

Earlier quoted context omitted.

Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.

The email says accounts will start locking Sept 10th and it was sent Sept 8th - so a 48 hour urgency window or an account would be locked is urgency IMO

Fair enough, was just thinking about many low effort scams that have “EMERGENCY!!! ACT NOW!!!” in red boldface. This, by being slightly? less aggressive is actually less likely to trip my “this is phishing” detector. Obviously ymmv.

Re: NPM debug and chalk packages compromised

#225

Post by goku12 »

tpxl wrote: post #183
goku12 wrote: post #99

Earlier quoted context omitted.

Every day brings me another reason to ask the question: "Why the hell did they throw away the idea of mutual TLS?". They then went onto invent mobile OTP, HOTP, TOTP, FIDO-U2F and finally came a full cycle by reinventing the same concept, but in a more complex incarnation - Passkeys.

Works this way for my government and my bank. I was given a cert matching my real name and the login just asks for my cert and pulls me through (with additional 2FA for the bank). Pretty amazing if you ask me.

Which government is this, if I may ask?

Re: NPM debug and chalk packages compromised

#226

Post by anonfordays »

parliament32 wrote: post #190
a022311 wrote: post #169

After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.

Real registries do[1], npm is just amateur-hour which is why its usage is typically forbidden in enterprise contexts. [1] https://www.debian.org/doc/manuals/securing-debian-manual/de...

[flagged]

Re: NPM debug and chalk packages compromised

#227

Post by grishka »

kelvinjps10 wrote: post #191
Deukhoofd wrote: post #87

Earlier quoted context omitted.

Also because Java, .NET, etc. all have very expansive standard libraries. You don't need to import most stuff, as it's already built-in.

But then you depend on Microsoft for everything. I prefer python where it's battery Included but you depend on a foundation

Hasn't .net been open-source for like 10 years?

Re: NPM debug and chalk packages compromised

#228

Post by skydhash »

zahlman wrote: post #70
skydhash wrote: post #49

Earlier quoted context omitted.

But why can’t we have a good library instead of those mini thingies?

Because you have to figure out what should be in it, and coordinate the distribution. It's not like there's a reference implementation of JavaScript maintained by a well-known team that you consciously install everywhere that you need it.

Node is pretty much everywhere regarding JavaScript cli and web apps (server side). As for the web it’s hard to argue for a slim library when most sites are dumping huge analytics bundle on us.

At this point, it’s just status-quo and lazyness

Re: NPM debug and chalk packages compromised

#229

Post by Klonoar »

dist-epoch wrote: post #33
stathibus wrote: post #18

As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?

This is spreading everywhere, Rust, Python, ...

Rust is an interesting case to me.

There are certainly a lot of libraries on crates.io, but I’ve noticed more projects in that ecosystem are willing to push back and resist importing unproven crates for smaller tasks. Most imported crates seem to me to be for bigger functionality that would be otherwise tedious to maintain, not something like “is this variable an array”.

(Note that I’m not saying Rust and Cargo are completely immune to the issue here)

Post reply on HN