Bug #9020
Self-hosted setup for Tor Browser tarballs is fragile when upstream tarballs change
100%
Description
To save bandwith, the documentation produced in the initial implementation (Bug #8125) does not actually upload tarballs to our git-annex repository, but instead it adds such tarballs by URL (with git annex addurl
). If the tarballs found at these URLs change, then anyone who gets them later (using git annex copy
will get the updated tarballs, as opposed to the ones we initially meant to add.
This doesn’t fail in awful ways when building Tails, since what we publish over HTTP is actually use a clone of our master git-annex repository, synchronized very often, so as long as the upstream tarballs are not modified within ~1 hour, the tarballs we’re publishing will be the ones we meant.
Still, this means that our master git-annex repo doesn’t really contain the data we meant to store in there. The one that does is its (meant to be read-only) clone used on www.lizard. I think we should fix that. This means the release manager will have to download the tarballs over HTTP, then upload them with git annex… and then they’ll be downloading the tarballs again when they build an ISO image, unless they cheat and import the tarballs into their apt-cacher-ng
cache.
Subtasks
Related issues
Related to Tails - |
Resolved | 2014-10-15 |
History
#1 Updated by intrigeri 2015-03-06 11:58:13
- related to
Bug #8125: Self-host the Tor Browser tarballs we need added
#2 Updated by intrigeri 2015-03-07 12:13:30
- Status changed from Confirmed to Resolved
- % Done changed from 0 to 100
Applied in changeset commit:336bf4568ea3be0229844b54825730ce4cd34cc1.
#3 Updated by BitingBird 2015-03-22 11:58:31
- Target version changed from Tails_1.3.2 to Tails_1.3.1