[philplckthun]

> Despite a short lifespan on the npm portal, the library was downloaded more than 370 times

It’s probably worth mentioning that this doesn’t sound like the back door was successful at all. Every package typically has around ~100-200 downloads immediately due to scanners and proxies.

This security response of under a day really sounds like a good improvement, although I still wish npm had some support for signatures so trusted packages can be trusted indefinitely.

[LinuxBender]

I would love to see these things GPG signed. This has been done with Linux packages for ages. This is a real problem at my workplace. We pull in python and ruby files, mirror them in artifactory and have no way to know for sure where they actually came from. We use tools to scan the files, but these tools are really just looking for known CVE's and not likely they would find subtle changes that dial home and execute code.

[wolfgke]

GPG signature only ensures that the package was signed by the owner of the key. It does not by itself ensure that the owner of the key is who he claims to be.

[LinuxBender]

Very true and good point. What would be a good low friction way to solve that?

[gravitas]

Distributions who have built GPG keychecks into the process use the keyparts distributed by themselves; meaning that on RHEL systems (and the clones - CentOS, OracleLinux, etc.) use the GPG keyparts delivered via the vendor "release" packages sitting in /etc/pki/rpm-gpg/, an Arch system uses "archlinux-keyring" which populates /use/share/pacman/keyrings/ and so forth. A 3rd party vendor source (think Nginx, Percona MySQL, Zabbix, etc.) who runs their own yum repo provides their own trusted GPG key and signs their packages with their key, so you install the "foobarvendor-release" package which contains their keys.

System package installs then do a GPG check against those known good keyparts from trusted vendors which you've allowed and stop you when you have an unsigned package (being a bit light on detail here, each distribution handles it their own way). So the NPM (or Artifactory, etc.) ecosystem could invent an installable package of their GPG keys, and require all packages sourced from their server to be signed with this key -- this is how the EPEL 3rd party community repo works for example. These are all based on trusted humans having access to the signing keys and process, so there are layers of vetted/known folks required (not just anyone can walk into Mordor here).

This does not work though for some Linux distributions such as Ubuntu due to their original design. Debian/Ubuntu systems for example are at somewhat of a disadvantage here; from the beginning the DEB system design has eschewed GPG signing individual packages and instead sign repositories (which tends to also get disable/ignored if even used), they're at least now recommending HTTPS around apt which is nice.

[asimpletune]

In just the most general sense, you do this by associating a public key with something else that is already presumed to be trusted, eg belonging to the alleged owner.

For example, a DNS record belonging to twillio.com, saying their npm public key is “xyz”.

Then, to the point others mentioned here, you include the logic to verify this in the package managers, ie compare the signed package with the trustee public key. Although the verification would also be something that could easily be done by a human as well.

Your points of failure here are a) trusting the DNS system, which is acceptable for most use cases, and b) trusting the package manager, which is a similar situation to a above.

There are a few types of dns records that are meant for this already, depending on the specific, but probably a txt record is fine and I think what most people do now, though I could be wrong about that.

[lftl]

A popularity score that combines age of the package, number of downloads, and the number of packages that depend on the package in question could give a quick metric for cases like this, helping people realize that this probably isn't the official Twilio package.

All of that is roughly available on the npm website, but isn't really exposed in the CLI.

[ethanwillis]

I read it in a different way, not to say your reading is invalid! My interpretation was that a malicious actor could be holding a compromised key.

[im3w1l]

I believe Debian uses a web of trust and irl verifications to build that web. Hierarchical trust like the x509 certs we use for https, sounds like a more convenient alternative.

[dr-detroit]

Be able to read and comprehend your dependencies. Reduce dependencies. Eschew learning-frameworks like create-react-app for production projects.

[ethanwillis]

I think this is an important skill that enough people don't cultivate nowadays.

At some level there's always going to be some dependencies unless you literally bootstrap the universe from first principles. And people like to use that as a rationalization for why they shouldn't bother going a little bit lower level than they normally would.

I recently put together my own personal blog after years of putting it off and letting domains go unused. I've thought about using Hugo, Jekyll, even Wordpress. But I just hated the thought of everything extra that comes with them.

But I also didn't want to handwrite all of my HTML, manually move files around, etc. So instead I wrote my own thing in about 20 lines of bash. Super easy to comprehend and I can fit it to exactly what I'm doing. It feels nicer versus typical Node stuff I do where it feels like I'm stuffing clowns in a car.

[brundolf]

> so trusted packages can be trusted indefinitely

If you specify an exact package version, you can trust that to be immutable. NPM doesn't allow replacing of existing versions, only addition of new versions.