Yes, the title is (slightly) provocative.

Context

We keep published ISO/IMG files and some metadata for all versions, in a git-annex powered repository. Files are made available on the web at https://iso-history.tails.boum.org/ (behind authentication).

Pushing to this specific repository has always been a pain, for every single release I’ve been responsible for (which give or take — since some releases have been shared across some release managers — means around 15 releases).

Until the switch to building IUKs on Jenkins to check their reproducibility, so early 4.x versions, it was “just” a matter of pushing files “at some point” during or after the release process. Worst case, you had to remember to check it went through.

Nowadays, we rely on those files to be available to build IUKs on Jenkins. This means having to move things around a little (see a follow-up to Bug #17659 where I’ll push another branch with my notes/proposed commits following the 4.6 release), so that the push to that repository has finished before we get to build IUKs on Jenkins.

For the record, building IUKs in a huge time sink on its own, see Feature #17657 and Bug #17658.

The Problem

With that in mind, it’s absolutely not acceptable to keep being stuck at ridiculous transfer rates when pushing to that repository. I’ve been mentioning that on tails-rm@ for a while, opened Bug #17414 4 months ago and we have made little progress. But for 4.6, we’ve reached an incredible situation, see https://redmine.tails.boum.org/code/issues/17647#note-10 → 56K-modem-from-30-years-ago transfer speed!!!

And that what when trying to reach the service directly (through a port redirection)! Since I remembered the documentation I received initially was using some onion address instead, I switched back to it, and got back the huge speed from my earlier releases, around 300 kB/s!

Bottom line

This has to stop. It’s ridiculous, frustrating, and excruciating to be wasting hours syncing files around, when we have to ship (like this is often the case) bug fixes to users that are rated somewhere between important and critical on the Firefox/Tor Browser side.

Therefore, I’ll be proposing two approaches (hence the title) as sub-tasks.

One of them will need to happen before 4.7.