Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm surprised the blockchain gang isn't coming up with a solution for trustless npm packages or is it that a blockchain can't solve the problem of a trusted developer suddenly becoming untrustworthy?


Blockchain is a solution to a problem that doesn't exist in the real world in any appreciable sense.


Oh it definitely exists, and this might be one place where it could help, but it's not sexy, and it won't make you rich, so nobody is bothering.

A lot easier to pretend NFTs are more important than collecting stamps.


I think this is the right answer


> solve the problem of a trusted developer suddenly becoming untrustworthy?

This would be an exceptionally hard problem to solve, with-or-without blockchain.

Could you develop a system where any new releases are required to be reviewed and "signed off" by a random assortment of users before becoming "active"? Sure.

Is "blockchain" necessary for that? No.


I find this line of thinking frustrating and dismissive of new(er) technology. Is "blockchain" necessary for anything? Probably not. Is it potentially the best solution when compared to the alternatives and weighed on its pros and cons? Maybe - but one has to be willing to investigate before dismissing it.


Don't get me wrong, there are definitely areas where blockchain tech is (or may be) a good solution. Those are for problems where distributed trust and consensus between (potentially) adversarial agents is necessary; where a central authority either doesn't exist, or can't be trusted.

In this situation, you are downloading code from a central authority, and have placed your trust there already. What benefit does a distributed solution give here?


This exists, it's called crev: https://github.com/crev-dev/crev

As you note, this doesn't require a blockchain. crev uses a web-of-trust model which is pretty well suited to the task.


Oh wow, this is cool. I refuse to use npm because these issues keep cropping up and no solution gets implemented, but this looks good. I was just looking at an interesting static site generator today until I saw it used nodejs and noped out of there.

In contrast, Powershell on Windows won't even let you use scriipts you've written yourself on your local hard drive unless you call them in a way the lets PS know you approve them. Scripts off the net have to be signed.

Methods of signing scripts https://docs.microsoft.com/en-us/powershell/module/microsoft...


crev is so neat, I have really been expecting npm/pypa/... to pick it up any day, for years. It solves those problems without taking power away from the package repository, and with minimal changes needed to the repository itself. With a spec already complete, I would expect an organization with the resources of npm could implement it in a few days, and I am really confused (and disappointed) that it is still not taking off.

Signatures from the author doesn't solve much unfortunately. You would still need a mechanism to build trust (or review the script manually) and once you put that trust in the author, all that a cryptographic signature gets you is automatic trust in the next version... so the Faker attack slips through.


Packages are written by people not algorithms. People you have to explicitly trust to install the package.


Ethereum scripts are written by people too


... and trusting them is in no way "trustless". You have to audit every version of them, just like you can do with npm.

Ethereum provides trust in the results given trust in the code, nothing more.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: