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.
We all dodged a bullet
491–498 of 498 posts
Re: We all dodged a bullet
#492Re: We all dodged a bullet
#493Earlier 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 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
#494Earlier 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…
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
#495Earlier 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
Re: We all dodged a bullet
#496Earlier 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.
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
#497Earlier 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.
Re: We all dodged a bullet
#498I 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 :)