GitLab

because understanding regexp is too hard

We've started to regularly skip using the feature/ and bugfix/ prefixes
in our branch names. As a result, our Jenkins lib fails to extract
the issue number from these branch names, and thus some CI mechanisms
won't work. For example, reproducibility testing won't ever be run
on such branches. This commit fixes this.

We don't manage to foresee CA changes and keep this up-to-date before it harms
our users. This provides little extra security, and ironically, when we fail to
update the CA, we expose our users to the very same practical effects as the
attack this mechanism is meant to protect against.

For details, see
#18324 (comment 169820)

Closes #18324

The Dotfiles feature symlinks specific files and not entire directories.

Thanks kwadronaut <kwadronaut@autistici.org> for the patch!

Tails::IUK::LWP::UserAgent::WithProgress: display correct progress status when resuming a previously failed download

Previously, when a download failed and was resumed, the progress bar started
back at 0% on every retry.

It'll need to know:

 - which temporary files we're downloading to
 - the expected total size of the download

… so it can compute the current progress status accurately, based on the total
amount of data already downloaded, while currently it only knows about the
amount of data downloaded during the current attempt, ignoring what we already
had before resuming the download.

This gives other methods than run() access to this information:
the LWP::UserAgent-based object will need it soon.

Retry failed upgrade downloads, reusing the previously downloaded data, and fallback to the DNS mirror pool

This is the solution called "C + fallback DNS pool" on #15875.

Incidentally, since the SocksPort we're using has IsolateDestAddr and
IsolateDestPort, this also gives us "C + new Tor circuit" for the last retry in
most cases (that is, unless the mirror picked from mirrors.json, that we tried
to download from previously, is in the DNS pool, and we pick it again from from
the DNS pool).

This should allow the Upgrader to recover, transparently for the user, from
a number of failure modes, such as:

 - We picked a mirror that's down or flaky.
 - We picked an out-of-sync mirror that lacks the data we need to download.
 - The user's Internet connection is flaky.
 - We picked a flaky Tor circuit.

Regarding the added test scenarios:

 - For the "Successfully resuming an interrupted download, from the same mirror"
   scenario, I failed to find a simple enough way to set up a webserver that would
   fail once and then start working again, so I implemented the webserver mocking
   code directly in Tails::IUK::TargetFile::Download, which is not ideal.

 - For the "Successfully resuming an interrupted download, using the fallback
   mirror pool" scenario, I could have run a broken webserver and a functioning
   fallback one. But once I had the mocking code mentioned above, it was vastly
   simpler to just use it here as well.

refs #15875

This option leaves the door open to some persistent local privilege
exploitation. IIRC kurono verified that it was not a problem in practice,
but I find it safer not to take any chances, and I prefer not having
to constantly reason about whether that remains safe enough.

This option was only used by one step of our manual test suite, which:

 - required a complex local setup that most manual testers don't have
   (even I haven't had it ready anymore since years)

 - is now useless not only because our release process publishes the UDFs on the
   test channel, but also because when a manual tester reaches this point, IUKs
   are supposed to be available on most mirrors already (and even the RM took
   a risky shortcut, with #15287, the delay caused by uploading the IUKs goes
   away, so the chances the IUKs are available is higher).

This will fix filesystems affected by #17902 (phantom space occupied on the
system partition by previously deleted obsolete automatic upgrades), for users
who:

 - Either, still have enough usable free space to automatically upgrade to
   a release that includes this fix.

 - Or, will manually upgrade to a release that includes this fix.

And more generally, it's good practice to fsck filesystems at boot time:
this will automatically recover from other failure modes.

refs #17902

we could reach 10 veth devices, so let's avoid those messaging spamming
us. Thanks, @anonym!

right now it makes no difference, because there is only one. But it can
help when we will have more than just one!

unfortunately that dedicated socket is a UNIX domain socket, not a tcp
socket. this means it's actually usable by any other process running as
amnesia. That's, at least, not a regression!

no new features, no fixes