Hacker News Reader

Comment by xd1936 | Hacker News Reader

xd1936

I wish apt, dnf/rpm, flatpak, etc utilized a decentralized distribution option, like IPFS or BEP46 Mutable Torrents. It would be neat if the project leads seeded new package update hashes, volunteers ran seedboxes instead of http mirrors, and clients had (default-on?) seeding of package binaries in addition to only downloading. It would be neat to see the open source community contributing to support each other's experience.

View on HN

You could update Archlinux with pacman over ipfs from around 2015 until last year. https://github.com/ipfs/notes/issues/84

Then the mirror became too slow and couldn't handle the amount of package data and was shut down: https://github.com/RubenKelevra/pacman.store

It worked rather well and even automatically mirrored the packages on my LAN. Maybe it'll be back some day.

I'm not quite following (including trying to skim your links) - what mirror? I thought the point was that it was decentralized and should scale arbitrarily?

It worked like this: rsync2ipfs-cluster fetched the packages from a rsync mirror into an IPFS-MFS-Folder updated the link in IPNS and then added this folder to a running IPFS instance/cluster.

All of those packages are then available for pacman under the (unchanging) IPNS name and the packages themselves are stored in IPFS as usual files. All you had to was add `http://x86-64.archlinux.pkg.pacman.store.ipns.localhost:8080...` to your mirror list after running your ipfs node (or use a public ipfs gateway).

The website sadly is down now. It had a nicer explanation. None of this still works now however.

EDIT: the folder/list of files was managed by the user hosting the project. The files/packages themselves were distributed. That's just how IPFS/IPNS works. Somebody has to put them into IPFS.

EDIT2: technically the example I posted is a DNSLink which points to a (now gone) TXT record which points to an IPNS name (which is a mutable pointer) that contained the directory of all current archlinux packages.

I hope that was comprehensible.

Ah, so when you say "Then the mirror became too slow and couldn't handle the amount of package data and was shut down" you're talking about the side that added packages to IPFS and did the initial seeding. That's what I wasn't following, thx.

Exactly. As I understood the problem lies in the import of new packages. That was hanging and the deletion of one single file from the folder took ~30s. In the older versions <=0.9 this was working faster. This caused the IPFS mirror to be days out of date. Then the project was discontinued.

I have a local MITM Squid proxy on my home network to try and alleviate this problem, but it's why the prevalence of TLS with no protocol design for how we do proxying has gotten pretty annoying.

I did try doing something fun with network-interface scripts and avahi to make this more dynamic - the idea was my desktop and laptop both ran squid proxies, and then dynamically set peer proxies if they detected each other on the network. It didn't work great given the overhead.

It really feels like there should be a better way to do this in general, and without having to break TLS directly for things which are not really "secret".

Why aren't packages based on torrents? Most distros come with a torrent client.

Torrents tank when there is lack of popularity. Linux can be configured for a wide variety of purposes, from IoT driver to gaming workstation, so not all packages are equally popular with all people, and just because a package is unpopular doesn't mean it isn't important. If I'm the one person in the world running a service that everyone else relies on, then the packages which support that service are important even if no one else uses them.

Therefore to use torrents requires one of two choices, neither of which are really viable when you think about it. Either:

* Require everyone who uses the distribution to torrent releases of the full set of packages for the distribution. (And remember that packages regularly get updated even in LTS releases, due to backporting security fixes etc.) It means everyone using the distro really needs to be running dozens or hundreds of torrents.

* Everyone torrents only the packages they need, so access to packages becomes up to popular vote instead of actual importance.

Torrents are fine for isos but intractible for ongoing package management.

Right, it wouldn't eliminate the need for mirrors (or seeds in the torenting case). But it would greatly reduce the bandwidth needed for those mirrors.

It shouldn't be any worse than hosting old versions of packages on an HTTP file server.

A couple thoughts:

* You can mitigate the popularity thing by using webseeds; if it's popular then it's p2p, and if not then it just falls back to HTTP

* Alternatively, you can 80/20 it; only torrent the 10 biggest and 10 most popular packages (changing 10 to taste), which is a relatively small number of torrents to run while minimizing load on mirrors

If every torrent includes a webseed, then you're still left with the problem of needing to build a full HTTP CDN, and now have to also maintain the largest tracker infrastructure ever deployed for Bittorrent.

Under normal conditions with well behaved clients, raw bandwidth for the large packages is essentially never the issue. Misbehaving clients, cache thrashing, IOPS are the sort of issues that cause pain for mirrors.

Does torrent have addition overhead that regular hosting does not ?

Some ISPs try to block traffic that looks torrent like.

I would love my package manager to support a simple fetch helper protocol to plug-in distributed caches from torrents (with webseeds), to mDNS, heck just a Redis service tracking which systems should have which packages cached per site, to something not much more complex than an old fashioned HTTP caching proxy.

Well if you use apt you might be in luck. There's a bunch of apt transports. I don't know the maturity of them but you can google apt-transport-debtorrent, apt-transport-s3, and one for ipfs.

https://github.com/JaquerEspeis/apt-transport-ipfs

Torrents don't handle frequent updates very well. You'd have tons of outdated torrent floating around. They work well for archives and installation media though that doesn't change that often.

Honestly, default behavior should be to at least share package files on the local network. But sharing to the wider internet should be fairly trivial in <current year>, we have no shortage of technologies that accomplish this.

I wish more systems had this kind of feature. I have a fat fiber connection, I'd be thrilled to pop up an unofficial mirror for something like a Linux distro. I've tried mirroring Linux ISO torrents, but it seems almost nobody ever downloads from a torrent, so I end up never actually uploading any of these images.

This would make it so much easier for end users to cache/host a mirror than the myriad of tools and hacks like squid.

I'm sure this will happen once the Linux community standardizes on a package format /s.

At the end of the day, there's a trust issue. The way distribution works nowadays, mitigates a lot of those. Making it decentralised would be a step backwards.

Aren't the RPMs signed?

Packages can be and generally are signed and verified.

You know that packages are signed right? That's why everyone can be a libreoffice or ArchLinux Mirror...or Fedora?

And because of this, these mirrors are often non https so your ISP can actually intercept and provide the data to you directly.

This is why torrents would actually work fine in this model.

>ISP can actually intercept and provide the data to you directly

What a nice gesture! However my mirror-servers are https plus rsync (for some projects). But are there not some ISP's that block torrent-traffic completely?

BitTorrent is hard to block completely from my understanding of how the protocol works, but I may be wrong.

Unless you can break the SHA1 hashes for the torrent chunks and the global hash torrents also authenticate the content. If you have a valid "info" dictionary at least.

Where intercept usually means point DNS for the mirror domains to the ISP's local mirror, and ISP could mean your cloud provider.

A digital signature does not protect you against a malicious actor who starts distributing outdated, vulnerable versions to you.

How do i know you don't know what your talking about?....a mystery ;)

I mean replay attack and freeze attack as described in https://doi.org/10.1145/1455770.1455841 . It's very likely that I'm not up to date on mitigations in individual package managers.

>all of these package managers have vulnerabilities that can be exploited by a man-in-the-middle or a malicious mirror.

Well, that's how software is, but that article is from 2008 and things have gotten a lot better in the meantime (I think archlinux wasn't even signing their packages back then).

If the distribution's private keyring isn't compromised and you don't have third-party repos, your packages are as trustworthy as your distribution team (and upstream).

Reply on news.ycombinator.com