Earlier quoted context omitted.
There's an xckd for that :) The one with 12 competing standards going to 13 competing standards, or something like that.
Pretty sure Microsoft is exponentially bigger than 99% of the library authors out there, and add to that the giant communication channel that GitHub gives it over developers, so the analogy breaks pretty fast.
GitLab discovers widespread NPM supply chain attack
101–110 of 263 posts
Re: GitLab discovers widespread NPM supply chain attack
#102Re: GitLab discovers widespread NPM supply chain attack
#103I'm a victim of this. In addition to concerns about npm, I'm now hesitant to use the GitHub CLI, which stores a highly privileged OAuth token in plain text in the HOME directory. After the attacker accesses it, they can do almost anything on behalf of me, for example, they turned many of my private repos to public.
this, this, this All our tokens should be in is protected keychain and there are no proper cross-platform solutions for this. All gclouds, was aww sdks, gh and other tools just store them in dotfile. And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.
Also this is a complete non-issue on Unix(-like) systems, because everything is designed around passing small strings between programs. Getting a secret from another program is the same amount of code, as reading it from a text file, since everything is a file.
Re: GitLab discovers widespread NPM supply chain attack
#104I have an friend that starts an project next month that will rely on npm. He is quite a noob and didn't code in ages. He will have almost no clue how to harden against this, he will probably not even notice if he becomes a victim until something really bad happens. Pretty sad.
Re: GitLab discovers widespread NPM supply chain attack
#105Earlier quoted context omitted.
Larger attack surface (JS has been the #1 language on GitHub for years now) and more amateur developers (who are more likely to blindly install dependencies, not harden against dev attack vectors, etc).
Unfortunately, blindly installing dependencies at compile-time is something that many projects will do by default nowadays. It's not just "more amateur developers" who are at risk here. I've even seen "setup scripts" for projects that will use root (with your permission) to install software. Such scripts are less common now with containers, but unfortunately containers aren't everything.
I consider this to be a sign that someone is still an amateur, and this is a reason to not use the software and quickly delete it.
If you need a dependency, you can call the OS package manager, or tell me to compile it myself. If you start a network connection, you are malware in my eyes.
Re: GitLab discovers widespread NPM supply chain attack
#106Earlier quoted context omitted.
This was largely the reason I rejected "real name verification" ideas at GitHub after the xz attack. (Especially if they are state sponsored) it's not that hard for a dedicated actor (which xz certainly was) to get a quality stolen identity. The inevitable evolution of such a feature is a button on your repo saying" block all contributors from China, Russia, and N other countries". I personally think that's the antit…
That would be easily defeated by a VPN. The inevitable evolution would be some kind of in-person attestation of identity backed up with some kind of insurance on the contributor's work, and, well you're converging on the employer-employee relationship then.
Re: GitLab discovers widespread NPM supply chain attack
#107The credential harvesting aspect is what concerns me most for the average developer. If you've ever run `npm install` on an affected package, your environment variables, .npmrc tokens, and potentially other cached credentials may have been exfiltrated. The action item for anyone potentially affected: rotate your npm tokens, GitHub PATs, and any API keys that were in environment variables. And if you're like most deve…
Previously, you had isolated places to clean up a compromise and you were good to go again. This attack approaches the semi-distributed nature and attacks the ecosystem as a whole and i am affraid this approch will get more sophisticated in the future. It reminds me a little of malicious transactions written into a distributed ledger.
Re: GitLab discovers widespread NPM supply chain attack
#108Lucky for us C programmers. Each distro provides its own trusted libc, and my code has no other dependencies. :)
Do you rewrite fundamental data structures over and over, like maps, of just not use them?
What it doesn't have is a hashmap type, but in C types are cheap and are created on an ad-hoc basis. As long as it corresponds to the correct interface, you can declare the type anyway you like.
Re: GitLab discovers widespread NPM supply chain attack
#109Everyone is blaming npm but GitHub should be put on blast too for allowing the repos to be created and not quickly flagged. GitHub has a massive malware problem as it is and it doesn’t get enough attention.
I love! how Github, as a corporate company now owned by Microsoft, is directly tied to GoLang as the main repository of the vast majority of packages/dependencies. Imagine the number of things that can go wrong when they try to regulate or introduce restrictions for build workflows for the purpose of making some extra money... lol The original Java platform is a good example to think about.
And (to put on my Go defender hat), the Go ecosystem doesn't like having many dependencies, in part because of supply chain attack vectors and the fact that Node's ecosystem went a bit overboard with libraries.
Re: GitLab discovers widespread NPM supply chain attack
#110Is there any reason to keep using postinstall scripts allowed instead of asking e.g. the user? Are they even needed in most cases?