
Package managers should be immutable, distributed and decentralized - treve
https://evertpot.com/npm-revoke-breaks-the-build/
======
Mithaldu
Asking for Immutable / Append-only is insanity, due to the fact that
eventually someone WILL clutter the hell out of it, which all of your mirrors
will hate you for, as well as downstream ecosystem toolchains. The only viable
way to allow it is by vetting every upload, and uh, good luck finding
volunteers for that.

Decentralized / Distributed is a good thing to have and prior art already
exists.

Source: Experience with the grand daddy CPAN.

~~~
thresh
> The only viable way to allow it is by vetting every upload, and uh, good
> luck finding volunteers for that.

Debian seems to have no problems with that.

~~~
lisivka
Why parrent comment was downvoted?

Major Linux distributions (Fedora/Debian/SuSE/etc.) are excellent example of
proper solution for the "dependency hell" problem for C programs. JavaScript
is the new C, but for web, so same solution will appear for same problem.

------
sorpaas
Nix ([https://nixos.org/nix](https://nixos.org/nix)), probably?

~~~
cwp
Yeah, they're getting there. The binary package cache is a start. If it cached
upstream tarballs and git revs as well as builds, it would mitigate the sort
of thing the OP talks about.

Nix still needs some sort of distributed trust model, though. Without that,
nixos.org is a single point of failure.

~~~
manveru
You can use your own binary caches and of course your own clone of nixpkgs
repo. I think moving the binary caches to IPFS would also be a fun project.

------
stormbrew
A really powerful thing that I think is extremely underutilized for this is
the ability to sign git tags. Using that it should be very possible to allow
for trusted pinning against a source code version that is easily replicated in
mirrors.

~~~
eru
Why not pin against the git hash?

~~~
jon-wood
Because while its difficult, I don't think its impossible to force a hash
collision, making it theoretically possible to push malicious code that would
look as if it was the trusted version you want to use.

~~~
pflanze
Signed Git tags reference the same hash (commit id) that you could pin against
directly.

------
cat-dev-null
We needs blockchains for releases, projects, etc. are addressed by hash.
Search for your project, the name can freely change, but the hashes are
immutable and release hashes guarantee integrity of all subordinate artifacts
(files, metadata). Perhaps if you want to public a new project, you have to
first find a free "block", with basically linear (slowly increasing) proof-of-
work. Then, for distribution, something like BitTorrent to distribute
bandwidth and resilience across many systems (companies can choose to host
their own complete public mirrors).

------
chromakode
To achieve decentralization, we need a better model of trust for OSS at Github
scale. If there was a way to verify the authenticity of packages, we could
even use existing centralized repositories. I've been tinkering on an approach
to this at
[https://github.com/chromakode/signet](https://github.com/chromakode/signet)
as a proof of concept.

------
dpc_pw
I hope one day Cargo (package manager for Rust) will run over IPFS. :)

~~~
nikolay
As far as I know (after searching), there's no IPFS module for Rust. IPFS +
GPG would be ideal and I think by being one of the youngest major languages,
Rust should not wait and lead in this other aspect of security!

~~~
bergie
The good thing is that IPFS exposes an HTTP API, so doing language bindings
should be quite easy. For example, JS bindings for IPFS:
[https://github.com/ipfs/js-ipfs-api](https://github.com/ipfs/js-ipfs-api)

~~~
nikolay
Yeah, that's a way to do it!

------
giancarlostoro
Go technically would of been immune to such an attack unless of course they
took down the project's github repository, but it's possible to host your Go
code anywhere with git or other VCS. One thing that I always loved about Go
was this altogether.

~~~
diggan
Not saying that NPM is perfect but you can host your node modules wherever you
want as well. Supports tarballs/folders/git out of the box.

~~~
giancarlostoro
If that's the case, then why don't the users of that package update their
dependencies to his github repositories? I know it sounds like a pain, but
users shouldn't be so reliant on a service that could one day disappear, which
is one reason I like Go's approach.

------
bradgessler
[https://ipfs.io](https://ipfs.io) would be able to accomplish this goal.

------
chewxy
Semi related but recently Sam Boyer wrote a good article about writing a
package manager. He explores the topic quite well, indicating that there are
several things that are conflated as package managers

[https://medium.com/@sdboyer/so-you-want-to-write-a-
package-m...](https://medium.com/@sdboyer/so-you-want-to-write-a-package-
manager-4ae9c17d9527#.740o43vxi)

------
ClayFerguson
The issues here are 1) authenticity (tampering impossible) as well as 2)
distributed source control (GIT already is a best-in-class FOSS for SC). So we
need to make GIT able to publish something that is a BlockChain-encoded item
(File metadata + Content bytes, on a tree/directory structure) then we're
done!

Come to think of it GIT already _is_ able to map commits to checksums. That's
practically everything that is needed. As soon as someone implements a
BLOCKCHAIN GIT protocol, we're done. The problem will essentially be solved.
Or in summary: Implementing a BLOCKCHAIN that stores GIT commits, along with
some metadata for each commit.

BlockChain is good for finance, as well as source control is the main point
here. BlockChain can store anything but the point here is redundant,
verifiable storage, of all sources.

~~~
visarga
What if an archived version of a module is found to contain errors or security
holes? How would they fix that when the module is frozen in the BlockChain?
Add a blacklist?

~~~
X-Cubed
No, you just publish a new release with a suitable semantic version number.
The point of the blockchain is immutability of each release, not limiting a
package to only ever exist as a single release.

~~~
bergie
Something like an Ethereum contract could be used for this. And the smart
contract could also allow for deprecating/flagging bad releases as long as the
transaction comes from the original author.

------
andmarios
A clickbait title (also not the original title) with buzz keywords.

A package manager should be fast, easy to use, with good conflict resolution
—and useful information when this fail, fast downloads and a web of trust
behind it.

Not incidentally, you get this from major GNU/Linux distributions.

~~~
pc86
I wonder why this article has gone 10 hours without a title change?

------
memracom
We already have the immutable repo that you are looking for. We do all our
builds from a caching proxy server that pulls in new binary objects when we
need them, but serves up the old one for the 99% majority of repeat builds.

Artifactory is one package that does all of this, but in the past I have
rolled my own using various packages to cache maven repos, Ubuntu packages,
Python Pypi packages. It is not that hard and makes you mostly unaffected by
Internet outages and repos that go away for some reason.

And since the cache is under your control you can publish your own binary
objects to it, and clean it up too if you really want to get rid of something.

------
advanderveer
An example would be
"[https://github.com/whyrusleeping/gx"](https://github.com/whyrusleeping/gx"),
a Go package manager build on IPFS

------
banachtarski
Happy archlinux pacman user chiming in.

~~~
hvidgaard
Unless it changed since I used Arch last time some years back, Pacman still
don't have mandatory package signing.

~~~
irremediable
Pretty sure it has changed since then. At least, I used to make the same
complaint as you, and a friend who uses Arch recently told me what I'm saying
is way out of date.

[https://wiki.archlinux.org/index.php/Pacman/Package_signing](https://wiki.archlinux.org/index.php/Pacman/Package_signing)

~~~
hvidgaard
Well, then it has changed. That is good.

------
drinchev
NPM has a huge and strong community. There will be no more than a couple of
days and you could see replacements of those modules again on npm, but with a
different name.

Not to mention most of the modules on NPM that are maintained by one person
are usually less than 1k lines of code.

If you have a small project then it would not be a huge thing to replace them,
if you have a big project, you've probably already did that.

~~~
awinder
Unless one of those modules is used as a dependency in a lot of the other
modules that you use, in which case a bunch of different people all need to
update before your project is fixed. Which is exactly what happened in this
case.

~~~
drinchev
Sadly there's even something worse that can happen at this point.
[https://news.ycombinator.com/item?id=11343985](https://news.ycombinator.com/item?id=11343985)

------
EGreg
Why even have package managers? Serious question.

Do you really enjoy bloating your projects with 3 versions of the same package
because it is required by 3 other packages that have been independently
maintained?

Why would you not want to know what is in your app, if you spend so many man-
hours building it?

Version control for all projects seems to be a much better solution than
package management.

~~~
oldmanjay
If that is truly a serious question and not just feigning surprise, then I
have a serious question for you; have you ever worked on a project with so
many people and so much history there is no way that you can personally
understand it all?

~~~
EGreg
Yes.

------
grimmdude
It's pretty crazy to me to think that so many people were relying on a module
that merely left pads a string.

------
strictfp
I think trusting people is actually a good thing which the node community has
going for them. The opposite culture of vetting everything and making it
really cumbersome to publish artifacts would most likely have led to that
'left-pad' would never hav been published.

------
LukeB_UK
> _...they can even modify already-released packages._

I keep seeing people say that, but NPM rejects it if you try to publish a
version that already exists. Am I misunderstanding what the author is saying?

~~~
fweespee_ch
It may be considering unpublishing as a modification.

------
yjgyhj
Using hashes as identity rather than names would solve these problems.

------
kyled
What about secure? So much software, so little is being reviewed...

------
juanpabloaj
and use dht_rss for management of versions over bittorrent?

[http://libtorrent.org/dht_rss.html](http://libtorrent.org/dht_rss.html)

------
aioprisan
Another reason to use blockchain technology for trust management.

