Arch on IPFS

I have been using the project described here for some time now to get Archlinux package updates, even going so far as to join the pinning cluster, but I’m not sure how much longer that is going to last. As of five days ago, the cluster has stopped getting updates, and according to the status page, the cluster is offline for the foreseeable future. The quick(ish) fix is to roll the IPFS software back from the development version of ipfs-0.9.0 to the latest stable version that is not affected by the referenced bugs.

That being said, I’m not sure how much longer I am going to participate in this cluster. An idea has been forming thorough today on a decentralized cluster utilizing IPFS for file transfer and libp2p pubsub for cluster coordination that acts as a caching proxy server cluster. I have found it is possible to verify the signature on an Archlinux package without installing that package by using the command pacman-key -v $PACKAGE.sig.

As they say, if you want something done right, do it yourself.

How I expect it to work:

  1. User installs cluster proxy software
    1. On first run, an IPFS repo is initialized for the proxy’s use, and /etc/pacman.d/mirrorlist is imported
    2. On every other run, it starts a HTTP server on localhost
  2. The server joins a pubsub channel and listens for package hash announces, and provides its own announces of packages that have been locally verified. The announces are stored in a local cache. Some of these may be randomly downloaded from IPFS and verified locally.
  3. If configured to do so, some number of random packages are downloaded from the upstream repo and verified locally and added to the announce set.
  4. When pacman -Syu is run, the proxy server downloads the core, community, etc., repo files and stores locally.
  5. When a packages is downloaded, the proxy server checks the local cache for an IPFS version and uses that after verifying the package signature is valid. If not valid, a copy is downloaded from an upstream repo, verified, provided to the HTTP client, then added to IPFS and the hash is added to the local cache for later announcement.
  6. A folder for each repo is created with the repo database file and links to the package hashes in MFS, then published to the IPFS key.

A current downside is that the repository database files are not signed, and therefore cannot be verified client-side as being valid, requiring that these files are always downloaded from the upstream repository. If the Archlinux started signing these files, and ensure the repo data includes a date when the repo was created, all the files can be verified locally, regardless of whether the files were downloaded from an official repo site or from IPFS.

Comments