Hacker News Reader

Comment by KirinDave | Hacker News Reader

> I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist.

But they're right. What exactly would PKI do here? Someone is generating confusion.

You could argue that maybe a PKI solution could be used to inform the UI such that users are less likely to make mistakes, but browbeating NPM over this is silly. Maven has this problem (people really concerned built their own tools: https://github.com/whispersystems/gradle-witness), choclatey has this problem, pip has this problem, everyone has this problem.

The big difference is that the NPM ecosystem is just an order of magnitude bigger than most others, and its model of many small packages can hide many more key packages in the noise.

View on HN

Maven does not have this problem. That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. My packages are all cryptographically signed with my private key. Maven doesn't just offer code signing, it's mandatory to deploy projects to the central repo. The automated package verifier will reject you if you don't have it.

If someone gains access to my account and tries to modify my package without my private key it will not be accepted into the repo.

And actually, I'm pretty sure maven signs not just the code but also the documentation and everything else within your package.

Light-years ahead of NPM, even after their publicized issues.

How does "You need my private key to sign the cross-env package" stop someone from creating a "crossenv" package? What does the specific workflow look like that makes sure I don't add the wrong thing to my project?

It doesn't. They's not the problem being solved by signing. In all likelihood, if an end user got socially engineered to download the wrong package, there's very little to be done. Perhaps the install process can do a search and display similarly named packages, and the users could be more alert to irregularly named ones?

What's to be done is remove the package and try and dox the perpetrator to kingdom come, in hopes that law enforcement and social reputation can make an example of of them.

That method does not scale. Additionally, it assumes that members of law enforcement are not publishing malware.

I assure you my malice scales infinitely.

You should've stopped at the first "and". Advocating for vigilante justice helps solve no problems.

I think you're reading a lot more into my comment than I wrote. It's not "vigilante justice" to ban known scammers and circulate blacklists of them. It's how our community functions.

> dox the perpetrator to kingdom come, in hopes that law enforcement and social reputation can make an example of of them.

Is a hell of a lot closer to "vigilante justice" than the version you just said. Had you made the sane posting first (or not pretended you did the second time) I wouldn't have said anything and just upvoted in agreement.

Which part of the statement implied "vilgilate justice." The part with the law enforcement or the "social reputation" part that is exactly the words game theory uses when discussing bad actor in a problem.

Just so I can modify my words to avoid future misunderstanding.

> dox the perpetrator to kingdom come

I can't believe it wasn't obvious, but that's the part which implies vigilante justice.

From Wikipedia[0]:

A vigilante is a civilian or organization acting in a law enforcement capacity (or in the pursuit of self-perceived justice) without legal authority.

Doxing has a very specific meaning and it directly implies taking matters into your own hands, aka vigilante.

[0] https://en.m.wikipedia.org/wiki/Vigilante

Doxxing means sharing people's relevant personal details that you gained without the targets consent.

In the case of malicious scammers, doxxing them so they can be cut off from other code repositories seems less like "vigilante justice" and more like "a public responsibility."

I can't reply directly, but in another subtree you asked:

> Which part of the statement implied "vilgilate justice."

To put my own 2 cents in:

Doxxing someone is generally considered an attack, at least in some internet circles. It's pretty vigilante if you ask me, especially when we've seen some pretty striking examples of doxxing gone wrong in the past.

If you connect to my resources and use my systems to hurt other people, you don't really have an ethical leg to stand on if I share what details about you I have with law enforcement and other service providers.

It's absolutely an attack, but it's an "attack" of a kind that is acting to end misuse and widespread tampering. It's difficult to imagine a coherent ethical system that gives the author of malicious software an expectation of privacy as they attack other people, violating similar rights.

Doxxing in my experience implies publishing their info publicly. That's certainly what I thought you were saying.

I'm fine sharing with law enforcement, but sharing with other service providers seems to be a slippery slope. I imagine a dev losing access to their github account because they used a shitty password on their npm account and got compromised. That would suck.

I'd much rather we invent a better UI for dealing with software dependencies, but alas.

Like sibling says, doxxing implies that you'll post their personal info online.

The problem does not lie in attacking bad people, the problem is that there is a high risk that you THINK you've identified who the bad actor is but actually the person you decide to "retaliate" against had nothing to do with what was done to you. That's why we leave law enforcement to the law enforcement officials and justice to the justice system. Even they make a lot of mistakes but at least there is a process that gives a chance for the truth to be found.

But sharing info about a suspect with law enforcement is what you should do yes.

> Like sibling says, doxxing implies that you'll post their personal info online.

It's unfortunate that so many people don't know what the word means, because now we're redefining the word to a very specific and malicious definition that makes communication about nuances around the intersection of rights here more difficult.

> there is a high risk that you THINK you've identified who the bad actor is but actually the person you decide to "retaliate" against had nothing to do with what was done to you.

I mean, you'll know their IP address, login, email, ISP and whatnot at a minimum. If the target is a comprimised computer, notifying them is the bare minimum you should do. So I'm sort of confused what kind of final consequence you're imagining here.

I think folks just see the word "doxxing" and their pattern matching misfires.

> I think folks just see the word "doxxing" and their pattern matching misfires.

Or maybe you're trying to weasel out of what you said and are now going for broke.

Linking once again to define words, we go to Wikipedia[0]:

> Doxing is the Internet-based practice of researching and broadcasting private or identifiable information

> Doxing may be carried out for various reasons, including to aid law enforcement, business analysis, extortion, coercion, harassment, online shaming, AND VIGILANTE JUSTICE.

(Emphasis mine)

[0] https://en.m.wikipedia.org/wiki/Doxing

"Weasel?"

I can see this is going to be a constructive dialogue. If I had wanted to "weasel" I would have deleted the post last night when it passed under the negative point threshold.

I have absolutely 0 moral and ethical problems with publishing any details I have on a person who is using my system to attack other users. I think in fact this is a responsible thing to do, and necessary. In this specific case, I might be careful about the timing of the disclosure to try and round up any nasty packages in other systems they might have generated.

But I'd publish it. Happily. Gleefully even. I have 0 moral or ethical obligations not to. I have a clear ethical imperative to do so.

I guess fortunately for this scammer, I don't own NPM.

> "Weasel?" I can see this is going to be a constructive dialogue. If I had wanted to "weasel" I would have deleted the post last night when it passed under the negative point threshold.

I wasn't going to accuse you of being a weasel, but this is the most weasel-y thing I've ever seen.

> It's unfortunate that so many people don't know what the word means

Perhaps you can cite a history of the word, then maybe I'll trust your definition over some other.

You asked for clarification to avoid future misunderstanding and then proceed to reject our clarifications as if there's some nerd-word central authority that we're not aware of. We can't even agree on one 'x' or two.

> It's unfortunate that so many people don't know what the word means

When you're the one person in a conversation who has a totally different definition, you just might be wrong.

You're wrong. Give it up.

I'm confused what exactly you want me to do?

I've said I have 0 problems publishing their data publicly. I'm happy to own even the stronger model of doxxing you lay out. I've put a few time qualifiers on it you didn't like.

But I have no problem burning the the identity people who think they can use me or my infrastructure to defraud others. Quite the opposite.

Calling the police isn't doxxing someone, it's a reasonable response to a situation.

Vilifying them online isn't reasonable. It's how you end up with harassment, death threats, swatting, people going after your job, your family, etc...

It's a really shitty thing to do.

I can explain how it can be done. Let's say you need a new dependency. You can't just add it to the project. Management would kill you. There's a lot of checks you have to make. Like licenses and signatures.

In this case, you're concerned about signatures. I'll stick to that. If I believe I need crossenv, I see it advertises kent@doddsfamily.com as the author. I look up Kent Dodds. I find various bits of information about him. I find his twitter @kentcdodds for instance. He may even have a page published @doddsfamily.com to verify his key.

If the key has been around for a while, that's probably sufficient for me. If he doesn't have such a page, I send him a polite message, "Hi Kent. I'm evaluating your software for use in my project. Can I get you to verify your key please?" and Kent is a professional, so he agrees. I send kent@doddsfamily.com an encrypted message and he sends me an encrypted reply. Done. I'm satisfied that he controls the key.

At this point... oh, wow. That's not my key! Did you say crossenv? My package is cross-env! Alert the Node authorities! There's a malicious package pretending to be mine!

Is that 100% infallible? No, but here's the great thing. Even though my verification system may not be bulletproof, others with resources like DoD or FBI are out there verifying keys. They'll go see Mr Dodds, in person, if they have to. In this way, key verification is a bit like herd immunity. And the older the key is, the more trustworthy it probably is.

People who are here arguing against this system have a few things in common. They don't propose a better system, because they don't have one. They're also a bit like anti-vaxers. They irrationally refuse to participate in such a system to everyone elses' detriment. They're a bit like congress as well. They can't just look at a working system like single payer, and copy it. They refuse to accept that this is the best available option, so they fold their arms and actively fight any attempt to implement it, as is the case on that github 4016 issue.

So now that I've maybe offended everyone, strike me down with down votes. That's the basics of how I would go about it though.

Hashes already exist. The problem is not a lack of integrity verification. We have that. The problem is not a lack of identity verification, we haven't really shown that NPM is lacking for that.

The problem is one of addressing. People want to get packages by a utf8 and natural language string, followed by a version boundary check.

If people referred to packages by their proper hash (as one does when referencing values from IPFS), then we wouldn't have this problem. If people had a public key and added a key fingerprint that would also work, but would not provide any additional verification to the code (1).

But people don't want to do this. They want to address packages by relatively simple and memorable tuples. That is the problem.

> They're also a bit like anti-vaxers. They irrationally refuse to participate in such a system to everyone elses' detriment. They're a bit like congress as well. They can't just look at a working system like single payer, and copy it.

You aren't even in Keybase. Have you personally participated in any keysigning parties? Can I find your public key details here?

I can answer yes to all 3 above questions.

> So now that I've maybe offended everyone, strike me down with down votes. That's the basics of how I would go about it though.

You haven't actually offended everyone. What you haven't done is say anything that anyone else doesn't know already. We all know how signature verification worksheet and we all have seen it's problems in real world implementations.

Please reconsider paragraphs like this.

(1) :: The thing this would do is make it arguably more secure contacting the author or maintainers of the code, although given GPG's failure to achive widespread adoption or integration in popular tooling, it seems unlikely it'll see much utility.

I guess you are aguing that you can't find 10-ish core npm maintainers that can be bothered to sign keys for well-known developers and bootstrap a web of trust that would then provide crypto attestation and perform basic gatekeeping on new package submissions.

It's not like you'd have to write a bunch of software. Also, other mission-critical open source repos have been doing this for at least a decade, so you don't even have to invent and validate a new set of processes for this.

For me, this calls into question the reliability and quality of the whole npm infrastructure and the packages it hosts.

Also, blaming users because npm (knowingly, through willful negligence) hosts malicious packages that typo squat on legitimate packages doesn't seem appropriate to me.

Maven prevents this as well. To add a package to the global repository you need to show ownership of your namespace by posting your key, your website, your email, or most commonly these days your GitHub repo with identifying information. They do check to make sure you're allowed to use each package identifier.

All package submissions are hand-curated, which should catch typosquatters. There's a clearly laid out pattern for what package space you're allowed to use based on website or company ownership.

The system is highly automated but you have to wait to get your namespace approved. And it's not unrealistic to do this with npm, maven has somewhere over a million packages.

Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference.

> Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference.

Yes, there is a difference, released must be digitally signed on maven. They are not on NPM, so a hacker can hijack your packages just by obtaining your npm credentials.

That's crypto 101 and you can't tell the difference?

> so a hacker can hijack your packages just by obtaining your npm credentials.

Couldn't they 'just' steal your GPG key as well? If someone can trivially steal a strong password from you, I'd worry about key material as well.

> That's crypto 101 and you can't tell the difference?

Please reconsider sentences like these.

The issue is of who to trust, the package maintainer or the package repository?

It is comparatively trivial to steal a strong password when it is transmitted over the internet vs local key material.

Nation states with bad certs (china has done this) can steal your password, npm can steal your password, npm can be hacked and leak passwords, npm can be subject to a NSL and forced to hand over passwords, etc, etc.

There is a big difference between passwords and keys.

> The issue is of who to trust, the package maintainer or the package repository?

Interesting framing.

> It is comparatively trivial to steal a strong password when it is transmitted over the internet vs local key material.

"Comparatively trivial?" I don't really understand this. I think you're suggesting that SSL cert attacks are easier than evil maid attacks due to this paragraph:

> Nation states with bad certs (china has done this) can steal your password, npm can steal your password, npm can be hacked and leak passwords, npm can be subject to a NSL and forced to hand over passwords, etc, etc.

Pardon me, but we're so far afield of the actual reality and the logistics that plague it that I decline to continue this conversation. If your adversary is nation states, you need a code audit (preferably several). You can't trust the signatures precisely because nation states are so well equipped to perform evil maid attacks.

It is 2017, evil maid attacks are the reality of the nation-state intelligence industry. We're seeing examples of them leaking out. They're in active use not just in a targetted mechanism, but speculatively! We have evidence intelligence agencies sell comprimised USB keys in bulk near the physical locations targets are likely to enter just to see if they can catch them in a moment of bad opsec.

Honestly this all feels like an attempt to say, "We should use GPG because it is good." Maybe it is. I'm not so sure, given the logistical reality.

But it wouldn't prevent the attack we see in the tweet above. It wouldn't make the root post of this thread correct. And I'm not sure it would accomplish what you're saying.

I'm sorry, I simply don't have time to chase this degree of abstracted hypothetical on a day old thread. I'm writing this final message here as a courtesy to those involved.

Just consider: - China issues a bad cert for npm - Slurps up all passwords from Chinese maintainers en masse

Now we can't trust any package published from China.

This is a bigger deal than a targeted evil maid. Distributed trust is better than centralized trust.

Distributed trust isn't better than centralized trust. In fact, it'll fail more often. It's just that the failures have varying degrees of severity.

Same principle as saying, "I will make my website more reliable by adding more servers." In fact you make it less reliable by doing so, you just change the severity of the problems.

And we've seen economic mechanisms compromise signed star-shaped trust graphs. E.g., all these atom plugins with features/spyware circulating because a small handful of companies think it's a business model. That's literally just buying the property from folks and ruining it. That's a very powerful attack against a web of trust and often cheaper than the fake cert attack, which is actually something you can guard against if you feel inclined to do so.

There's a huge difference. I could put my private key on a hardware dongle completely isolated from my PC environment if I wanted.

Npm is a public internet login with a password of your choosing, probably the most insecure form of authentication there is bar doing nothing. I could be brute forcing your login credentials right now and you wouldn't even know.

Also, users are safe even if maven itself is compromised because attackers still can't validate my private key. I don't think you could say the same about npm...

Actually Maven Central has about 200K packages. Incidentally about the same number of packages by which npm has increased in the last year. So no, a hand-curated submission process is probably not reasonable

[1]: http://www.modulecounts.com

Thanks for bringing the numbers to this.

NPM is such a massive package repository, it's sort of a testament to the community that these sorts of things don't happen more often.

Yeah I'm not really following how users desiring a natural-language tuple-looking thing prevents proper identity verification. Even without namespacing strong identity controls (signature verification and preventing unauthorized accounts from posting under a taken name, for example) can prevent most attacks short of typosquatting.

Typosquatting is exactly what these malicious packages were doing. So you're agreeing that arguments re. identify verification is a useless distraction in this case?

You seem to have a handle on every aspect of this situation except what the actual attack we're discussing was.

It was typo squatting.

And you like to assume things.

Name canonicalization gets you part of the way there. But unless you want to go full-on namespacing then you must realize you are fighting a pointless battle.

You cannot reasonably expect to save users from themselves in every way.

Npm has namespacing.

> If people referred to packages by their proper hash (as one does when referencing values from IPFS), then we wouldn't have this problem. If people had a public key and added a key fingerprint that would also work, but would not provide any additional verification to the code (1).

The hash naturally changes with every release. The key fingerprint doesn't. Updating your dependencies to new releases is much, much more frequent than adding a new dependency; people are willing to put more effort into the latter than the former.

> You aren't even in Keybase. Have you personally participated in any keysigning parties? Can I find your public key details here?

Keybase encourages poor practices and as such I avoid it. But I've been to keysigning parties and my key's details are published any number of places. (Since adding one more is all to the good, the fingerprint is 400A C7D2 E7A1 802A AE2C C459 B1E5 712A 6D03 3D61)

I don't understand why you feel that the keybase question was directed at you. The decision to enter into this part of the discussion definitely hurt otherwise interesting post.

It's true that a signature is based around a component with longer lifespan than a hash. However the management and trust of that component damages this argument severely.

I am unaware of any web of trust in active use that could operate a npm scale existing today. Could you share one with me?

Because it was a direct reply to the individual. If used as an example you should give context, otherwise your comments are directed towards who you reply to.

I didn't reply to lmm. I asked that question of danjoc.

Is that not obvious from scrolling?

The part where you personally checked out who published the package and did due diligence would save you with NPM. That gpg protection scheme would prevent MITM attacks presumably. The presence of that key isn’t going to establish trust (though maybe you could build off of it so it’s foundational in that sense), or somehow enable the fbi and dod.

Why would the malicious user advertise the email associated with crossenv as kent@doddsfamily.com and not kent@dodds.family? Attacker could control the latter and hand you an evil cert?

One would think you would do more than send an email if you're trying to verify.

Websites, Twitter, Github, Keybase, etc..

It would be pretty hard for a bad actor to overtake the real author's entire Google-findable presence (assuming it's a reasonably popular package - why would you typosquat anything obscure).

If all you do is send an email, then you haven't really done "due diligence" in any acceptable form.

What if the attacker instead advertises `some-totally-different-person@gmail.com`? How are you even supposed to know who wrote the legitimate version of the package in the first place? And if you _do_ know who wrote the package, you don't need a GPG key to verify that; just their NPM username or even the actual, real package name will do fine for preventing this specific attack.

Should I book a plane ticket to go verify 2 pieces of photo ID in person?

This idea that everyone will just verify with the author is insane.

Presumably you inspect the thing you're including in your project first, if it seems trustworthy you mark whatever key you have as somewhat trustworthy. Then you inspect differences on version updates of your npm deps. If it still looks ok, you update your trust of the key.

It's the same way you gain trust in something in real life, by watching actual behavior of someone over time. It is just assisted by technology.

Then you can ignore the issue of email completely, because you're not basing your trust on authority of the author, but on his track record as determined by you.

I bet you'll not find many attackers who would maintain some hijacked package for a few months, before launching their attack. Original author would probably notice something fishy too, given enough time.

Do you do that with all the transitive dependencies as well? With npm's small library ethos, it seems like that way lies madness.

One of the central problems of trust is that simple solutions don't scale well. Back in the day, one acquired a .com address by sending someone an email, because everyone knew everyone.

cross-env has had 1.3 million downloads in the last month. How many of those "hey, I am evaluating your library" emails can Dodds field?

Most node projects have hundreds of dependencies, if you include transitive dependencies. How many of those can you test?

If simple solutions worked, they'd be used.

Seems to scale well both for maven and basically all linux distroes, so there's that

I suppose that to get an estimate of the number of actual users, you have to scale that number of downloads down by a factor of 10 - 1000, depending on if and what kind of dependency cache JS toolchains use (esp. around CI/CD).

But yeah, everyone contacing an author directly doesn't scale at all.

I do see what youre saying but that 1.3 million downloads is not unique. That number is mainly comprised of automated builds pulling in the package (either directly or transitively), not new devs trying it out.

GPG-signing doesn't prove maliciousness, it just proves authenticity; that it was written by a particular person. The web-of-trust is used to enforce social reputation - if a user is malicious, their key is revoked. If a user signs up poor-quality other users, their key is revoked. Blacklists go stale and are also hard to get off if you've landed on one in error. Webs-of-trust are more work, but more robust.

Maybe I just don't understand, so could you explain to me how gpg signatures actually fix this problem? Would they fix this problem for npm?

I'm asking about the specific attack detailed in the tweet.

I'm guessing maven feels safer because its packages must be compiled against a specific interface and few if any execute any code during setup. Maven is rarely if ever used to install interactive tools like npm very often is. Maven is not a reasonable analog here.

Somewhat agreed, maven is a build tool and packages it downloads do not execute code through maven. This does not preclude malicious typosquatting packages making it into applications built using it, but does provide some option for reducing the attack surface.

In practice I think most developers would be running their project on the same exact box as they use for building it, which nullifies the separation of build/runtime environment. The reason that we don't typically see egregious typosquatting in the Java ecosystem is that Sonatype has a manual check on the claimed namespace for the organization publishing a project (among other checks). npm, Inc. could do this, but they so far have chosen not to.

Edit: Typos/clarity

People keep saying this, but it's easy to imagine that the malicious code in a maven-included package only works when it detects it's being invoked in a unit test, which puts it in build time easily.

It's true it doesn't immediately build on site, but it sure could run in the developer's machine.

Does maven really reliably validate packages these days?

I once did a mvn build on a southwest flight and got stuff like "Syntax error: <h1>Click here for free TV..." all over my console.

This was ~4 years ago. If I remember right, maven "supported" package validation, but it was certainly not the de facto standard.

Great point. I think that Maven Central is great about checking incoming packages. But most maven clients are really bad.

The default in maven client is usually to download via http. The default is usually to _not_ check the hash. There is not a great way to pin a library to a repository which, when coupled with the ease of third-party repositories slipping into your project, means that you can download things like your crypto oauth library from some random server on the web.

Many of these issues can be mitigated by running your own repository that mirrors what you need. Most big corporate shops do this. I think that approach works for any package management system. I guess open source devs and hobbiests are screwed?

Yes

https://github.com/s4u/pgpverify-maven-plugin

There's also this,

https://jeremylong.github.io/DependencyCheck/dependency-chec...

Because you want to know when a dependency has a vulnerability, even when the developers are legit.

The repository enforces it. The client doesn't check by default which is a poor default, but at least checking is possible for those who care.

> That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever.

That something hasn't been updated in two years because it's feature complete and does what it's supposed to: verifies the integrity of dependencies for Signal [1].

> If someone gains access to my account and tries to modify my package without my private key it will not be accepted into the repo.

This isn't true. Sonatype/Maven Central requires PGP signatures on all new artifacts, but there is no requirement to use the same key. It will happily accept a signature from _any_ key for new releases.

[1] https://github.com/WhisperSystems/Signal-Android/blob/ae9303...

Yes, this is important: Maven Central/Sonatype only checks if the submitted artifacts are signed (regardless of the used key).

The work is shifted to client, but there's currently no standardized way on how to verify dependencies and plugins.

There's an issue in the Maven bug tracker with the idea to extend the POM to allow trust information: https://issues.apache.org/jira/browse/MNG-6026

>Maven has this problem

What malicious packages have been found on Maven central?

Why don't you google or follow the link I already gave?

Exactly what I thought. You can't name one. Coincidentally, Maven central requires GPG signatures.

As we all know you can only sign a piece of code if it is free of malicious software.

Heck, I read that you can't even make a GPG key without proving your virtue to Richard Stallman in festivus-style competition.

> everyone has this problem.

No, they don't. Some people actually implemented the "web of trust (sigh)".

Security is hard; the answer is not to just go "too hard, kick the can down the road" and then make excuses when the time comes for damage control. NPM being an order of magnitude larger means that more focus should be given to security, not less, since it has that extra noise acting as another way to hide malicious activity.

That's fine, but gpg signatures would do nothing to prevent this and widy scaled webs of trust don't exist.

Easy to say. Care explaining? These signatures seem like exactly the thing to prevent mitm attacks. I trust signature A; i won't load the package unless it's signed by signature A.

Most people won't be that strict in informal development, but that's not really what this is about.

Just signatures would indeed not help much in this particular case. Signatures plus other ways to establish trust will help. To give two examples:

- macOS apps need to be signed (to run without extra work). The keypair is associated with a developer ID account that has a credit card on file. Abuse is still possible (stolen credit card, stolen certificate), but a lot harder.

- Some open source project have their own WoT. For example, IIRC NetBSD required new developers to meet with one or two existing developers in person to verify their identity. (Pretty much like a regular PGP WoT.)

These are more work, but they also make the world safer for users.

> For example, IIRC NetBSD required new developers to meet with one or two existing developers in person to verify their identity. (Pretty much like a regular PGP WoT.)

Debian also requires OpenPGP keys and WoT for all developers.

What is WOT in this context? I thought Debian required that you register with them, not that there was some other trust threshold.

Apple doesn't have a web of trust. Microsoft and Google do not either. They bless your code for their marketplaces. Crypto is just coincidentally how they do it.

A web of trust implies transitive trust.

I'm pretty sure the same is true of Debian, but I don't know about the others. But these are NOT webs of trust.

What's more, other open source projects simply do not deal with the scale of NPM. The amount of data they move and offer is pretty brutal. Lots of dismissive engineers sneer at the javascript numeric tower and simply do not understand how difficult and perhaps even surprising the implementation of NPM as a platform is, given its scale.

Reply on news.ycombinator.com