7 ms·

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

by danjoc 9y ago

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.

KirinDave 9y ago
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.
- hedora 9y ago
  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.
- slackingoff2017 9y ago
  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.
  - jondubois 9y ago
    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.
    - camus2 9y ago
      > 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?
awinder 9y ago
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.
pfooti 9y ago
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?
- sbarre 9y ago
  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.
  - Ajedi32 9y ago
    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.
  - am1988 9y ago
    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.
- megous 9y ago
  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.
sanderjd 9y ago
Do you do that with all the transitive dependencies as well? With npm's small library ethos, it seems like that way lies madness.
pfooti 9y ago
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.
- LoSboccacc 9y ago
  Seems to scale well both for maven and basically all linux distroes, so there's that
- TeMPOraL 9y ago
  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.
- haggy 9y ago
  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.

by danjoc 9y ago

KirinDave 9y ago

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.

hedora 9y ago
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.
slackingoff2017 9y ago
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.
- jondubois 9y ago
  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.
  - camus2 9y ago
    > 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?

awinder 9y ago

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.

pfooti 9y ago

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?

sbarre 9y ago
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.
- Ajedi32 9y ago
  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.
- am1988 9y ago
  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.
megous 9y ago
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.

sanderjd 9y ago

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

pfooti 9y ago

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.

LoSboccacc 9y ago
Seems to scale well both for maven and basically all linux distroes, so there's that
TeMPOraL 9y ago
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.
haggy 9y ago
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.