[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2761: self-update command

[Tahoe-LAFS]

#2761: self-update command
-------------------------+---------------------------
 Reporter:  warner       |          Owner:
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:  undecided
Component:  packaging    |        Version:  1.10.2
 Keywords:               |  Launchpad Bug:
-------------------------+---------------------------
 I had a wild idea this morning, related to #2055.

 Start by using a [https://pip.pypa.io/en/stable/reference/pip_install
 /#hash-checking-mode hash-enabled requirements.txt] file for the primary
 install: the install process would look like:

 {{{
 % wget https://tahoe-lafs.org/downloads/tahoe-lafs-requirements.txt
 % virtualenv ~/.tahoe-venv
 % ~/.tahoe-venv/bin/pip install --require-hashes -r tahoe-lafs-
 requirements.txt
 % ~/.tahoe-venv/bin/tahoe --version
 }}}

 The first wget is TOFU (and depends upon TLS and the CAs), but after that
 you're installing exactly whatever the tahoe project said you should be
 installing.

 Maybe we even encapsulate all that into an installer stub, like the
 "lightweight" installers that a lot of professional apps (Firefox,
 Dropbox, Chrome) are using. You download the (small) installer application
 in your browser, you run it, then that does the longer full download
 itself (with retries and hash-checking and localization and nicer error
 messages and install instructions).

 (hm, maybe [https://github.com/mitsuhiko/pipsi/ pipsi] should acquire a
 `--requirements=` mode, that'd be even easier)

 Now here's the wild part: if Tahoe knows that it's installed in a
 virtualenv, then it could run "pip" to upgrade things. We could add a
 "tahoe admin upgrade" command which:

 * downloads the current `tahoe-lafs-requirements.txt` file
 * checks an !Ed25519 signature against a baked-in release key
 * checks that the version string is greater than the current one
 * build wheels of all necessary dependencies, with `--require-hashes`
 * install those wheels into the current virtualenv

 The process would we safer than the original install: the reliance set is
 only that !Ed25519 key (and the people who use it to sign the requirements
 file).

 I suspect Google's cloud-services CLI tool (`gcloud`) does something
 similar. And it's safer than a `pip install -U` of everything that `pip
 list --outdated` reports: we can stick with specific versions (and hashes)
 that we've tested.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2761>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage