Live data from Hacker News

We all dodged a bullet

xeiaso.net

491–498 of 498 posts

Re: We all dodged a bullet

#491
post #405

Earlier quoted context omitted.

That's true but it's like saying most everyone has a small chance of crashing their car. Yet when someone crashes their car because they were texting while driving, speeding, or drunk, we justifiably blame them for it instead of calling them unlucky. We can blame them because there are clear rules they are supposed to know for safety when driving, just as there are for electronic security. The rule for avoid phishing…

Yeah but society doesn't act as if it's an unthinkable event we never planned for when a car crash happens. Blame someone or don't, but there are going to be emergency responders used to dealing with car crashes coming, because we know that car crashes happen (a lot) and we need to be ready for it.

Yes of course we need to defend against scammers at multiple levels because none of them are bulletproof, so putting too much trust in individual developers also a problem here. Even if they didn't get hacked, they could have just become the hacker themselves.

Re: We all dodged a bullet

#493
post #490
post #486

Earlier quoted context omitted.

how did you evaluate the sender address via DKIM to get "clean" response? I mean I know there are methods to verify stuff about a received email, DKIM by itself only handles message integrity and not sender details, for that you need to fold in DMARC -- but there are all WILDLY technical details that are certainly not what anyone is gonna do before clicking a link in a message body > As for URL scheme, I mean the for…

I think you are missing a lot of information I've posted elsewhere in this thread and the original HN post. I didn't minimize anything; I would hope most agree that if anything I've maximized the message as much as I possibly could to prevent further damage. 1. My email client does the validation of certain integrity and security checks and shows a checkmark next to senders that pass. Since npmjs.help was a domain le…

> The URLs appeared to match the official npm's site.

The domain "npmjs.help" is pretty clearly malicious at a glance, just from the ".help" TLD alone, but yeah as you say

> Once I had it in my head (erroneously) that .help was fine, nothing else about the attack stood out as suspicious when it came to the URL or domains.

well except that presumably you clicked on a npmjs.help link and the new tab ended up at npmjs.com? but yeah it's a tough break, don't mean to needle you, hopefully learning experience

Re: We all dodged a bullet

#494

Earlier quoted context omitted.

Well, consider that a lot of these functions that were exploited are simple things. We use a library to spare ourselves the drugdery of rewriting them, but now that we have AI, what's it to me if I end up with my own string-colouring functions for output in some file under my own control, vs. bringing in an external dependency that puts me on a permanent upgrade treadmill and opens the risk to supply chain attacks? L…

> but now that we have AI, what's it to me if I end up with my own string-colouring functions for output in some file under my own control Before AI code generation, we would have called that copy-and-paste, and a code smell compared to proper reuse of a library. It's not any better with AI. That's still code you'd have to maintain, and debug. And duplicated effort from all the other code doing the same thing, and no…

> a code smell

Smells are changing, friend. Now, when I see a program with 20000 library dependencies that I have to feed into a SAST and SCA system and continually point-version-bump and rebuild, it smells a hell of a lot worse to me than something self-contained.

At this point, I feel like I can protect the latter from being exploited better than the former.

Re: We all dodged a bullet

#495
post #240

Earlier quoted context omitted.

It is not a one-in-a-million opportunity though. I hate to take this to the next level, but as criminal elements wake up to the fact that a few "geeks" can possibly get them access to millions of dollars expect much worse to come. As a maintainer of any code that could gain bad guys access, I would be seriously considering how well my physical identity is hidden on-line.

This is why banks make you approve transactions on your phone now. The fact that a random NPM package can redirect your money is a massive issue

This attack was enabled by the normalization of orgs' aggressive 2FA postures.

Re: We all dodged a bullet

#496

Earlier quoted context omitted.

> but now that we have AI, what's it to me if I end up with my own string-colouring functions for output in some file under my own control Before AI code generation, we would have called that copy-and-paste, and a code smell compared to proper reuse of a library. It's not any better with AI. That's still code you'd have to maintain, and debug. And duplicated effort from all the other code doing the same thing, and no…

> a code smell Smells are changing, friend. Now, when I see a program with 20000 library dependencies that I have to feed into a SAST and SCA system and continually point-version-bump and rebuild, it smells a hell of a lot worse to me than something self-contained. At this point, I feel like I can protect the latter from being exploited better than the former.

> At this point, I feel like I can protect the latter from being exploited better than the former.

I expect that your future CVEs will say otherwise. People outside your organization have seen those library dependencies, and can update them when they discover bugs or security issues, and you can automatically audit a codebase to make sure it's using a secure version of each dependency.

Bespoke AI-generated code will have bespoke bugs and bespoke security issues.

Re: We all dodged a bullet

#497

Earlier quoted context omitted.

It was the Microsoft’s official Python extension, as far as I recall. It was possible to use some other extension for typechecking but there were some other issues with it. (Now everything works perfectly in Neovim, and my setup respects to only use typing stubs I specify in the project.)

The Microsoft official Python extension uses Pylance, which is a closed-source extension of Pyright with additional features such as built-in type stubs. This is probably what you saw.

If they were truly built-in I would not mind, but I found a bunch of third-party stubs in a dependency tree of the virtual Python environment VSC created (and ran obviously unsandboxed). What’s worse is that stubs, in addition to not being specified by me, were often pulled at the wrong version compared to the package I was using, leading to typing mismatches and runtime errors.

Re: We all dodged a bullet

#498
post #389

I wrote the first commit for slice-ansi in 2015 to solve a baby problem for a cli framework I was building, and worked with Qix a little on the chalk org after it. It's wild looking back and seeing how these things creep in influence over time.

Didn't expect things to grow how they have, that's for sure! Hope you've been well :)

Good to hear from you man, you too :)
Post reply on HN