Conversation

Notices

1. Embed this notice
   Jerry 🦙💝🦙 (jerry@infosec.exchange)'s status on Wednesday, 26-Nov-2025 04:36:05 JST Jerry 🦙💝🦙

   Adding compromised npm packages to your app like

   • Embed this notice
     Bill (sempf@infosec.exchange)'s status on Wednesday, 26-Nov-2025 04:36:03 JST Bill

     in reply to

     • creativegamingname

     @creativegamingname FINE JUST BE A DOWNER!

     No, you are exactly right. I dunno how we are gonna do it. Though, we have set standards with the IEEE and W3C and like that so maybe it is possible that way. Not enforced, just standard. Better than nothing.

     Steve's Place repeated this.
   • Embed this notice
     Cat 🐈🥗 (D.Burch) :paw:⁠:paw: (catsalad@infosec.exchange)'s status on Wednesday, 26-Nov-2025 04:36:03 JST Cat 🐈🥗 (D.Burch) :paw:⁠:paw:

     in reply to

     • Bill
     • Eleanor Saitta
     • creativegamingname

     @Sempf @creativegamingname Eleanor (@dymaxion) has a good solution that greatly mitigates this, given the small window of compromise.

     https://infosec.exchange/@dymaxion/115604160846695280

   • Embed this notice
     Bill (sempf@infosec.exchange)'s status on Wednesday, 26-Nov-2025 04:36:04 JST Bill

     in reply to

     • creativegamingname

     @creativegamingname So far as my actual answer is concerned, we already have something similar to this basic concept with the idea of code signing. Code signing is really common in binaries, but we need to be signing the hashes of JavaScript components and stuff as well.

     That doesn't solve the problem straight up because if the attacker is altering the underlying code, that hash won't save you. What the hash will do, though, is confirm that you're running the right version—the not vulnerable version—of the code. That would be a step in the right direction, and we already have the pattern in place for code signing.

   • Embed this notice
     creativegamingname (creativegamingname@infosec.exchange)'s status on Wednesday, 26-Nov-2025 04:36:04 JST creativegamingname

     in reply to

     • Bill

     @Sempf I think it would be difficult to design, implement, and kickstart.

     Once it was in place I imagine it would be almost self-regulating? But getting it there, and without the drama that it would build, would be tricky to navigate.

     And then attackers could just manipulate what it means when a user types npm.

   • Embed this notice
     Bill (sempf@infosec.exchange)'s status on Wednesday, 26-Nov-2025 04:36:05 JST Bill

     in reply to

     @jerry I gotta come up woth a solution for this shit. Problem is, we are bumping up against human nature. "Tough programming problem? Here, take this free code that will solve it for you!"

     But we can't live like that. I said it when we started, what, 20 years ago. I was right. But now what the fuck do we do? I'm stuck for ideas.

   • Embed this notice
     creativegamingname (creativegamingname@infosec.exchange)'s status on Wednesday, 26-Nov-2025 04:36:05 JST creativegamingname

     in reply to

     • Bill

     @Sempf
     Since we're no different than other organic systems maybe we could look at them for solutions?

     I don't mean something sci-fi or silly. I mean, look at what happens in other structures that have similar problems and the solutions they use to come up with it.

     My first thoughts are things like signal sharing. Some kind of like... marker that could be attached to the package that authenticated it. And the marker itself was authenticated through a community-chain. Sort of a system that would "authenticate" if the PR was from a safe source.

     It sounds like crypto... and I hate that, but perhaps building on the actual underlying philosophy?

     Apologies, this is something that leans heavily into my areas of interest

     @jerry