tails issueshttps://gitlab.tails.boum.org/tails/tails/-/issues2023-10-16T08:41:23Zhttps://gitlab.tails.boum.org/tails/tails/-/issues/14718Make Tails Upgrader a native Wayland app2023-10-16T08:41:23ZintrigeriMake Tails Upgrader a native Wayland app_Originally created by @intrigeri on [#14718 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/14718)_
Parent Task: tails/tails#12213
[[_TOC_]]
# Statu quo
- !838 made the Upgrader run under XWayland
- Making the U..._Originally created by @intrigeri on [#14718 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/14718)_
Parent Task: tails/tails#12213
[[_TOC_]]
# Statu quo
- !838 made the Upgrader run under XWayland
- Making the Upgrader GUI run as a native Wayland app, as the `amnesia` user, would have benefits
- But if we do #18086, we won't need to do that.
# Strategy
So let's see if we can _cheaply_ make the Upgrader GUI run as `amnesia` under Wayland.
This might be doable since all privileged operations it does already live in dedicated commands, run via sudo, which is quite close to what we would expect from a privileged backend API.
# Draft design
- privileged backend, similar to tca-portal:
- exposes an API for the operations currently done via `sudo`
- Current architecture: see "Privilege separation" in https://tails.boum.org/contribute/design/incremental_upgrades/, possibly a bit outdated but gives a good overview.
- Current implementation: https://gitlab.tails.boum.org/tails/tails/-/blob/stable/config/chroot_local-includes/etc/sudoers.d/zzz_upgrade`
- It could run the existing commands and pass the result to the frontend ⇒ could be implemented in Python, like `tca-portal`.
- listens on a Unix domain socket which is only accessible by root
- privileged wrapper for the frontend
- is started by `/usr/local/bin/tails-upgrade-frontend-wrapper`, which itself is started by `tails-upgrade-frontend.service`
- written in Python
- runs as root
- the amnesia user is allowed to run it as root
- connects to the backend's socket, then starts the frontend as the amnesia user, passing it that file descriptor
- frontend:
- runs as the amnesia user
- how to migrate the current code: replace every `sudo PROGRAM` with the corresponding API call to the backend
- Perl
- still uses Zenity: let's not invest more than necessary into this custom Upgrader
- privileged commands run by the backend
- no change needed there
- Perl
- porting the current [iuk test suite](https://gitlab.tails.boum.org/tails/tails/-/tree/stable/config/chroot_local-includes/usr/src/iuk):
- has to start the privileged backend with a bunch of `--override_*` option, just like it currently starts the frontend
- has to manage the life cycle of the backend: can be done with `systemd-run`, which is already used in that very test suite for nginx → no big problem
# Expected challenges
- Exposing download progress and speed in the GUI is tricky if we keep treating downloads as an operation that must run as non-amnesia: the backend would need to keep the frontend updated about this, as opposed to merely signaling completion.
- It's probably OK to run `tails-iuk-get-target-file` as the `amnesia` user, without using the privileged backend, which would solve this problem. But it has to download to a location that's not writable by other apps running as `amnesia`. How? Another file descriptor passed by the wrapper, and then we download to `/proc/$FRONTEND_PID/fd/$FD_ID`?
# Related issues
- **Blocks** tails/tails#17068intrigeriintrigerihttps://gitlab.tails.boum.org/tails/tails/-/issues/17068Unclickable URLs in Tails Upgrader2021-06-28T09:09:04Zsajolidasajolida@pimienta.orgUnclickable URLs in Tails Upgrader_Originally created by @sajolida on [#17068 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/17068)_
For example:
![](https://redmine.tails.boum.org/code/attachments/download/2417/upgrader_manual.png)
If I understa..._Originally created by @sajolida on [#17068 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/17068)_
For example:
![](https://redmine.tails.boum.org/code/attachments/download/2417/upgrader_manual.png)
If I understand correctly, this is due to Tails Upgrader running as a
different user (tails/tails#6509) and we’ve had this problem in other software
already. If it is the case, we’ll run into this problem time and time
again and I’d like to have a better idea of what it would take to solve
it, even if it’s quite a lot of work.
### Attachments
* [upgrader_manual.png](https://redmine.tails.boum.org/code/attachments/download/2417/upgrader_manual.png)
### Related issues
- **Blocked by** tails/tails#14718https://gitlab.tails.boum.org/tails/tails/-/issues/17312Prevent users from closing Tails Upgrader while an upgrade is being applied2023-05-17T10:18:47Zsajolidasajolida@pimienta.orgPrevent users from closing Tails Upgrader while an upgrade is being appliedThe current dialog can be closed by pressing "Esc".
The upgrade is still being applied in the background: tails-upgrader is
still running and the USB stick is flashing.
We should prevent people from closing this dialog until the upgrad...The current dialog can be closed by pressing "Esc".
The upgrade is still being applied in the background: tails-upgrader is
still running and the USB stick is flashing.
We should prevent people from closing this dialog until the upgrade is
fully applied.
At this point, Tails is offline and we recommended people to close
everything else. People click OK might wonder what should happen next
and we won’t display anything else before several minutes. I guess that
a lot of people might restart in doubt of what’s happening.
I guess that this is the root cause behind tails/tails#14754.https://gitlab.tails.boum.org/tails/tails/-/issues/17187Document manual upgrades from virt-manager with a Persistence2020-07-01T19:58:37Zsajolidasajolida@pimienta.orgDocument manual upgrades from virt-manager with a Persistence_Originally created by @sajolida on [#17187 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/17187)_
As per
<https://lists.autistici.org/message/20191023.005151.d943ba2f.en.html>.
### Related issues_Originally created by @sajolida on [#17187 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/17187)_
As per
<https://lists.autistici.org/message/20191023.005151.d943ba2f.en.html>.
### Related issueshttps://gitlab.tails.boum.org/tails/tails/-/issues/16685The Upgrader GUI is not readable by Orca2020-05-15T13:06:57ZintrigeriThe Upgrader GUI is not readable by Orca_Originally created by @intrigeri on [#16685 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/16685)_
Reported on tails-dev\\@
(\<6F6E8706-3D81-4281-96CD-F2026E53279C\\@gmail.com\>).
Parent Task: tails/tails..._Originally created by @intrigeri on [#16685 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/16685)_
Reported on tails-dev\\@
(\<6F6E8706-3D81-4281-96CD-F2026E53279C\\@gmail.com\>).
Parent Task: tails/tails#14522https://gitlab.tails.boum.org/tails/tails/-/issues/15768Use desktop background to warn users when their Tails needs to be updated2023-05-10T15:12:56ZhuertanixUse desktop background to warn users when their Tails needs to be updated_Originally created by @huertanix on [#15768 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/15768)_
When following up with Tails trainees a few months or more after an
initial training, most if not all of them will..._Originally created by @huertanix on [#15768 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/15768)_
When following up with Tails trainees a few months or more after an
initial training, most if not all of them will **not** have updated
Tails since the initial training. They are able to connect to the
internet and they see the Tails upgrade prompt but unfortunately inherit
the behavior learned from other operating systems: That it’s ok to
choose Upgrade Later and then never update. In order to better
communicate a sense of urgency to users to upgrade their Tails version,
it would be ideal to go a step further than a website notice and updater
prompt.
UX recommendations:
- If a version of Tails is found to be outdated, change the desktop
wallpaper color to a dark red, with a lighter
internationally-recognizable warning symbol (⚠) and localized text
explaining the need to upgrade in the center of the desktop, keeping
in mind the Gnome HIG writing style:
<https://developer.gnome.org/hig/stable/writing-style.html.en>.
Assuming Gnome desktop supports SVG images, it may be possible to
generate this programmatically without needing to maintain a set of
static images.
### Related issues
- **Related to** tails/tails#12003
- **Related to** tails/tails#14544https://gitlab.tails.boum.org/tails/tails/-/issues/15289Make Tails Upgrader suggest a manual upgrade to decrease future IUK sizes2021-05-31T15:17:08ZanonymMake Tails Upgrader suggest a manual upgrade to decrease future IUK sizes_Originally created by @anonym on [#15289 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/15289)_
When IUKs get “too big”, link to advanced doc for tails/tails#15288. Or, if we
detect that the upgrade took a long ti..._Originally created by @anonym on [#15289 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/15289)_
When IUKs get “too big”, link to advanced doc for tails/tails#15288. Or, if we
detect that the upgrade took a long time (1> hour), we can show the
link after the IUK was downloade1d (but before IUK installation).
### Related issues
- **Related to** tails/tails#15290
- **Related to** tails/tails#14544
- [ ] **Blocked by** tails/tails#15288https://gitlab.tails.boum.org/tails/tails/-/issues/15277Update our survey of non-NIH system upgrade solutions2021-11-16T12:12:57ZintrigeriUpdate our survey of non-NIH system upgrade solutions_Originally created by @intrigeri on [#15277 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/15277)_
Parent issue: #18086
The conclusion of the research I’ve done today on tails/tails#11131 is that the
most promisi..._Originally created by @intrigeri on [#15277 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/15277)_
Parent issue: #18086
The conclusion of the research I’ve done today on tails/tails#11131 is that the
most promising tool is RAUC once it has casync support; but a few other
options could be worth investigating. Let’s wait a bit for the dust to
settle, come back to it in a while and see where things are at. Then we
can investigate how much work is needed to switch to one of these tools.
Blueprint: https://tails.boum.org/blueprint/Endless_upgrades/#non-nih
### Related issues
- **Related to** tails/tails#15281
- **Related to** tails/tails#15875
- **Has duplicate** tails/tails#15869
- **Blocks** tails/tails#7499
- **Blocks** tails/tails#17815https://gitlab.tails.boum.org/tails/tails/-/issues/12493Have Tails Upgrader automatically point to manual upgrade if running from an ...2020-10-19T14:47:35Zsajolidasajolida@pimienta.orgHave Tails Upgrader automatically point to manual upgrade if running from an old version_Originally created by @sajolida on [#12493 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/12493)_
See tails/tails#12392.
“Old” here means “definitely too old to have an IUK”. We are currently
publishing IUKs for ..._Originally created by @sajolida on [#12493 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/12493)_
See tails/tails#12392.
“Old” here means “definitely too old to have an IUK”. We are currently
publishing IUKs for 2 versions so version older than 12 weeks will never
have IUKs.
Note that we might decide to publish more IUKs in the future. So it
would be good to have a mechanism in place to remember updating this
setting if we decide to ship more IUKs.
This mechanism would also become obsolete if we decide to do
https://gitlab.tails.boum.org/tails/tails/-/issues/11131#note_57704.
### Related issues
- **Related to** tails/tails#12492
- **Related to** tails/tails#14544
- **Related to** tails/tails#15288https://gitlab.tails.boum.org/tails/tails/-/issues/8434Automatically test that Tails Upgrader rejects valid certificates for the wro...2020-05-15T18:30:45ZintrigeriAutomatically test that Tails Upgrader rejects valid certificates for the wrong hostname_Originally created by @intrigeri on [#8434 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/8434)_
In
`features/download_upgrade-description_file/Download_Upgrade-Description_File.feature`,
we test some invalid cert..._Originally created by @intrigeri on [#8434 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/8434)_
In
`features/download_upgrade-description_file/Download_Upgrade-Description_File.feature`,
we test some invalid certificate cases, but we don’t test that a valid
certificate for a wrong hostname is rejected. We should.
Implementation-wise, we could:
- either get ourselves a valid certificate for a test-only hostname
(both the public and private keys will be in our iuk Git repo); this
requires the least amount of divergence between the code being
tested and the code run in production;
- or use something like
[TLSPretense](https://github.com/iSECPartners/tlspretense), that can
generate various kinds of flawed certificates on the fly; it
requires adding a CA used by TLSPretense to the list of those
trusted by the client; it adds firewall rules to intercept the
network traffichttps://gitlab.tails.boum.org/tails/tails/-/issues/7726Have upgrade-description files expire2020-05-15T18:51:48ZintrigeriHave upgrade-description files expire_Originally created by @intrigeri on [#7726 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/7726)_
The current security design of incremental upgrades currently allow for
“Rollback attacks”, “Indefinite freeze attac..._Originally created by @intrigeri on [#7726 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/7726)_
The current security design of incremental upgrades currently allow for
“Rollback attacks”, “Indefinite freeze attacks”, “Wrong software
installation” and “Vulnerability to key compromises”, *if* an attacker
can replace upgrade-description files with (e.g. older) other ones. To
conduct such an attack, one currently needs to either change the content
in the main Tails Git repo (but that would be noticed, most likely), or
to control the files served by our website, or to break the TLS
connection between `tails-iuk-check-upgrade-description-file` and
<https://tails.boum.org/>.
This class of problems could be fixed relatively easily by including a
`valid_before` field in the (signed) upgrade-description files, that
`tails-iuk-check-upgrade-description-file` would then verify against the
current date and time.
This idea was not included in the initial design of Tails incremental
upgrades for several reasons:
1. even without it, incremental upgrades were believed to be at least
as safe as the previous upgrade system against such attacks; so, it
seemed to be good enough for a first iteration;
2. having to periodically update upgrade-description files on our
website appeared to add too much work on our shoulders, with too
grave consequences if, for some reason, we forget or are unable to
do it.
The first point is still valid, but it should not prevent us from
improving things now that the first iterations were successfully
completed.
The second point is still a concern: automating this process would
require to have a *very* strongly trusted system on the Internet, that
pushes these updates to our website; I don’t believe that our
infrastructure/sysadmin team can handle that much pressure currently.
**However**, what we could do is to have the upgrade-description files,
that are generated when preparing a Tails release, be valid for two
release cycles, that is 12 weeks (plus a few days to be on the safe
side, possibly). This way:
- even if we skip a release, upgrade-description files don’t expire
too early, and then don’t need to be manually refreshed;
- (almost) no work is added to the release process;
- we can validate this idea and its implementation without too much
initial pressure. We can even mess up a little bit, in certain
affected areas, without causing any harm.
### Related issues
- **Related to** tails/tails#10122https://gitlab.tails.boum.org/tails/tails/-/issues/7878Offer option to download automatic upgrades without Tor2024-01-08T10:48:33ZsegfaultOffer option to download automatic upgrades without Tor_Originally created by @segfault on [#7878 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/7878)_
Downloading the upgrade from 1.1 to 1.1.1 took 5 hours. Without Tor, it
would take about 3 minutes. So I would actual..._Originally created by @segfault on [#7878 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/7878)_
Downloading the upgrade from 1.1 to 1.1.1 took 5 hours. Without Tor, it
would take about 3 minutes. So I would actually prefer downloading this
non-anonymously. After all it’s clear that I’m using Tails anyway \[1\].
\[1\] <https://tails.boum.org/doc/about/fingerprint/index.en.html>
### Related issues
- **Related to** tails/tails#14544https://gitlab.tails.boum.org/tails/tails/-/issues/7432Investigate security issues that may be caused by passing SSL_NO_VERIFY uncha...2020-10-06T10:28:12ZintrigeriInvestigate security issues that may be caused by passing SSL_NO_VERIFY unchanged to tails-upgrade-frontend_Originally created by @intrigeri on [#7432 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/7432)_
We pass `SSL_NO_VERIFY` unchanged via sudo from the `amnesia` user to
the `tails-upgrade-frontend` program. Presumab..._Originally created by @intrigeri on [#7432 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/7432)_
We pass `SSL_NO_VERIFY` unchanged via sudo from the `amnesia` user to
the `tails-upgrade-frontend` program. Presumably, an adversary who has
taken control of the `amnesia` user, and can actively MitM the
connection to <https://tails.boum.org/>, can e.g. serve an old
upgrade-description file that hides the availability of an upgrade
(indefinite freeze attack), or maybe even incitates the user to
downgrade to an older version of Tails (rollback attack). Note that the
upgrade-description file being served still needs to be signed by the
Tails signing key.
We should investigate the exact consequences of this all.
### Attachments
* [3.png](https://redmine.tails.boum.org/code/attachments/download/1069/3.png)https://gitlab.tails.boum.org/tails/tails/-/issues/7499Extend the upgrader to allow full (self) upgrade2022-06-06T08:28:52ZalantExtend the upgrader to allow full (self) upgrade_Originally created by @alant on [#7499 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/7499)_
I would be very nice to be able to have a few-clicks away full upgrade
process (incuding downloading the upgrade, veryfi..._Originally created by @alant on [#7499 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/7499)_
I would be very nice to be able to have a few-clicks away full upgrade
process (incuding downloading the upgrade, veryfing it and installing
it). This could either upgrade to an other device, or preferrabily the
source device.
An usecase for that is: someone got a Tails device created by a trusted
party using “Clone and upgrade”, they trust it but never went through
the manual verification and installation process and don’t know how to
use them, so they end up using an outdated version.
Blueprint: https://tails.boum.org/blueprint/Endless_upgrades/
### Related issues
- **Related to** tails/tails#11131
- **Related to** tails/tails#11627
- **Related to** tails/tails#8861
- **Related to** tails/tails#15281
- **Has duplicate** tails/tails#5981
- **Blocked by** tails/tails#15277https://gitlab.tails.boum.org/tails/tails/-/issues/7031Don't depend on a single hash algorithm for incremental upgrades2014-04-06T18:30:23ZintrigeriDon't depend on a single hash algorithm for incremental upgrades_Originally created by @intrigeri on [#7031 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/7031)_
Currently, our update-description files contain exactly one hashsum for
every target file. If the algorithm we use h..._Originally created by @intrigeri on [#7031 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/7031)_
Currently, our update-description files contain exactly one hashsum for
every target file. If the algorithm we use has flaws, then we have
problems. The approach APT uses is that instead, the package lists
contain hashsums computed with different algorithms, for every file
whose integrity/authenticity needs to be verified. We should probably do
the same.
The most important thing to start with is probably to extend the IUK
code, to make it able to verify an arbitrary number of hashsums. Note
that the upgrade-description file format already supports shipping
multiple hashsums.
Then, we can research the exact list of hashing algos we should use,
probably starting with the same list as Debian (iirc: MD5, SHA-1, and a
SHA-2 or two). It might make sense to add SHA-3 and the latest djb’s
algorithm to the mix.https://gitlab.tails.boum.org/tails/tails/-/issues/6591GUI to select another upgrade channel2014-01-10T10:35:04ZintrigeriGUI to select another upgrade channel_Originally created by @intrigeri on [#6591 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/6591)_
A GUI to select another upgrade channel (e.g. alpha or beta) would make
it much easier:
1. for us to document how ..._Originally created by @intrigeri on [#6591 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/6591)_
A GUI to select another upgrade channel (e.g. alpha or beta) would make
it much easier:
1. for us to document how to upgrade to a Tails release candidate;
2. for users to follow this documentation.
Implementation-wise:
- If implementing this in Perl: `Tails::RunningSystem` in our perl5lib
allows to trivially get the currently configured channel. Adding the
needed backend code there to change this setting and write
`/etc/os-release` should be pretty easy. Adding a frontend on top
should also be easy.
- If implementing this in another language (Python, shell): either do
the `/etc/os-release` parsing and writing yourself; or preferably
add a short Perl wrapper executable around our perl5lib, and build a
GUI on top using your preferred programming language; this way, the
channel reading and writing is kept in a single place, instead of
being duplicated in various programming languages; intrigeri may be
willing to write the needed Perl bits if it helps.https://gitlab.tails.boum.org/tails/tails/-/issues/6461Turn the Upgrader frontend into a wizard2023-05-17T10:17:56ZintrigeriTurn the Upgrader frontend into a wizardThe current UI flow (based on zenity dialog boxes) could be
clearer if merged into a single window. Otherwise, it’s not that clear
that all these dialog boxes are part of the same process, and it’s far
too easy to close one and have no p...The current UI flow (based on zenity dialog boxes) could be
clearer if merged into a single window. Otherwise, it’s not that clear
that all these dialog boxes are part of the same process, and it’s far
too easy to close one and have no progress information until the next
dialog box appears, while the upgrade process is still ongoing in the
background.
### Related issues
- Blocks #17312: Prevent users from closing Tails Upgrader while an upgrade is being appliedhttps://gitlab.tails.boum.org/tails/tails/-/issues/6471Block system shutdown and reboot while an incremental upgrade is being applied2020-07-15T06:30:03ZintrigeriBlock system shutdown and reboot while an incremental upgrade is being applied_Originally created by @intrigeri on [#6471 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/6471)_
If the system is stopped while an incremental upgrade is being applied,
the resulting system is likely to be broken ..._Originally created by @intrigeri on [#6471 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/6471)_
If the system is stopped while an incremental upgrade is being applied,
the resulting system is likely to be broken in various ways. We should
prevent that somehow.
### Related issues
* **Related to** tails/tails#17312https://gitlab.tails.boum.org/tails/tails/-/issues/17825Consider migrating Upgrader's UDF signature verification from GnuPG to Sequoi...2020-07-20T07:32:00ZintrigeriConsider migrating Upgrader's UDF signature verification from GnuPG to Sequoia SOPAn implementation of the [Stateless OpenPGP Command Line Interface](https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/?include_text=1) RFC is now in Debian: https://tracker.debian.org/pkg/rust-sequoia-sop
Such a simple, s...An implementation of the [Stateless OpenPGP Command Line Interface](https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/?include_text=1) RFC is now in Debian: https://tracker.debian.org/pkg/rust-sequoia-sop
Such a simple, stateless implementation of OpenPGP signature verification feels more confident-inspiring than our current implementation, that relies on communicating with `gpg` on the command line (abstracted away in the Perl `GnuPG::Interface` library, but still), which is hard to get right.https://gitlab.tails.boum.org/tails/tails/-/issues/17940Run the Upgrader's test suite in CI2022-09-26T06:45:54ZintrigeriRun the Upgrader's test suite in CI_Originally created by @intrigeri on [#6218 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/6218)_
# Update
As of 2022-09-26, with #17803 on tracks to be merged soon, the scope is now:
- perl5lib (mostly used by ..._Originally created by @intrigeri on [#6218 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/6218)_
# Update
As of 2022-09-26, with #17803 on tracks to be merged soon, the scope is now:
- perl5lib (mostly used by the Upgrader): test suite is already run on GitLab CI ⇒ nothing more to do here
- Upgrader, aka. iuk:
- keep #18086 in mind
- A small subset of the test suite is already run on GitLab CI. The rest of the test suite cannot be run in the default Docker environment used by GitLab CI.
# Initial report
**Party outdated**
For now the scope of this ticket is limited to our 3 Perl code bases
(perl5lib, persistence-setup, iuk)… simply because our other custom
programs (sadly) have no test suite.
One way to do this would be to run our custom programs’ test suite,
using Vagrant, on our existing isobuilders (that already have Vagrant
installed and some room for storing baseboxes) or isotesters (which
would feel more logical, because “testers”) or both. What it takes is:
- at the root of each Git repo we want to test:
- add a suitable Vagrantfile that installs all build/test deps
during provisioning
- add a Makefile/Rakefile/script that starts the Vagrant VM, runs
the test suite in there, and tears down the VM
- for each Git repo we want to test:
- create a Jenkins job that runs the aforementioned script / `rake
test` / `make test`
Open questions:
- how to deal with inter-dependencies between these code bases? e.g.
persistence-setup and iuk depend on perl5lib; our options:
- start by testing perl5lib that has no such problem, gain
experience with the general idea during this first iteration,
and think about this problem later iff. the general idea is
validated
- install current perl5lib master in the VM with `dzil install`:
this works iff. we don’t delegate to the Debian packaging
anything that’s required to use perl5lib (currently we install
MO files via `debian/rules`, but perhaps we can do without them
here)
- set up the APT source for our `devel` custom APT repo and treat
perl5lib just like any other build dependency
- how to avoid creating yet another complex setup for managing
baseboxes? our options:
- don’t keep any basebox persistently on the Jenkins “slaves” (sic
:/) that run the tests, instead download & provision them every
time; we can probably leverage our existing apt-cacher-ng to
speed things up (see
file:///usr/share/doc/apt-cacher-ng/html/howtos.html\#ssluse to
make caching of HTTPS downloads work). This option implies we
use Vagrant baseboxes published by third-parties (otherwise
we’re just moving the basebox management problem elsewhere)
which is probably acceptable here; an [official Debian Stretch
Vagrant box](https://app.vagrantup.com/debian/boxes/stretch64)
is available, and we can dist-upgrade it during provisioning to
whatever version of Debian we want to test on.
- use the baseboxes we already use & manage for building ISO
images: this probably requires quite some refactoring to extract
code from tails.git, and forces us to test only on whatever
snapshot of Debian we currently use, while we would like to test
on current Debian sid too.
- other ideas?
- how to store or compute build & test dependencies? We already store
them in two different places (`dist.ini` on the `master` branch,
`debian/control` on the `debian` branch) so it would be nice to
avoid adding a 3rd one. Likely the easiest way is to extract build
deps from the `debian/control` file and install them with something
like `controlfile=$(mktemp) ; git show origin/debian:debian/control
> $controlfile ; mk-build-deps -i -r --root-cmd sudo $controlfile ;
rm $controlfile`
- how does this relate to tails/tails#7036 and https://gitlab.tails.boum.org/tails/sysadmin/-/issues/6220#note_108077? Can we implement
this ticket in a way that also makes us progress on that other
front? At least having to deal with custom APT sources, APT
snapshots, build deps, will teach us a thing or three about the
issues we’ll face when we tackle that other project, but perhaps we
can do better.
Ideally we would run these tests both on Debian sid (to detect breakage
in advance and make our RM’s life easier), whatever snapshot of Debian
we currently use, and an unfrozen version of the Debian release we use.
But already running them on *one* of them (probably sid) would be a
pretty good start\!
See also #17636, that has additional thoughts on this issue.
### Subtasks
- sysadmin#6217
### Related issues
- **Related to** tails/tails#17636
- **Has duplicate** tails/tails#6442
- **Blocked by** tails/tails#7036https://gitlab.tails.boum.org/tails/tails/-/issues/18004Automate incremental upgrades manual test2020-11-07T13:08:19ZintrigeriAutomate incremental upgrades manual testImplementation idea:
Give this scenario the `@release` tag, and (once #17772 is done) add logic so that tag is run for releases. This also makes it easy to filter out this test when running locally, e.g. when developing tests and runnin...Implementation idea:
Give this scenario the `@release` tag, and (once #17772 is done) add logic so that tag is run for releases. This also makes it easy to filter out this test when running locally, e.g. when developing tests and running them against the latest release.
Parent task: tails/tails#10250https://gitlab.tails.boum.org/tails/tails/-/issues/18086Switch to a non-NIH upgrade system2023-01-23T09:41:13ZintrigeriSwitch to a non-NIH upgrade systemIn our 2020-2022 roadmap, we've added 1 big thing among this one, #10491, and #14567.
# Subtasks
- [ ] tails/tails#15277
# Related issues
* https://gitlab.tails.boum.org/tails/blueprints/-/wikis/Faster_builds
* Blocks #7499
* I part ...In our 2020-2022 roadmap, we've added 1 big thing among this one, #10491, and #14567.
# Subtasks
- [ ] tails/tails#15277
# Related issues
* https://gitlab.tails.boum.org/tails/blueprints/-/wikis/Faster_builds
* Blocks #7499
* I part of that, it would be great to give an option to rollback an upgrade to the previous version. Users are rightfully adverse to upgrades (think [Tails 5.8](https://tails.boum.org/news/version_5.8#issues)).https://gitlab.tails.boum.org/tails/tails/-/issues/18093Upgrader: retry download of mirrors.json on failure2020-12-23T08:00:30ZintrigeriUpgrader: retry download of mirrors.json on failureIt can happen that our Upgrader fails to download `mirrors.json` from our website, and then the user sees:
```
Error while choosing a download server
<b>Could not choose a download server.</b>
This should not happen. Please report a bug...It can happen that our Upgrader fails to download `mirrors.json` from our website, and then the user sees:
```
Error while choosing a download server
<b>Could not choose a download server.</b>
This should not happen. Please report a bug.
```
@anonym suggested on https://gitlab.tails.boum.org/tails/tails/-/issues/15875#note_162439 that we retry this HTTP request with a different Tor circuit, would solve this problem. In other cases (e.g. our web server is rebooting), it probably won't.https://gitlab.tails.boum.org/tails/tails/-/issues/18138Serve UDFs under a dedicated virtualhost with a TLS certificate signed by our...2021-05-25T15:41:15ZintrigeriServe UDFs under a dedicated virtualhost with a TLS certificate signed by our own CAThis was suggested by @zen on https://gitlab.tails.boum.org/tails/tails/-/issues/18127#note_163859:
> we could setup a special URL just for the upgrader, serve it using a CA we control, and pin that CA instead.
This would avoid problem...This was suggested by @zen on https://gitlab.tails.boum.org/tails/tails/-/issues/18127#note_163859:
> we could setup a special URL just for the upgrader, serve it using a CA we control, and pin that CA instead.
This would avoid problems like #18127.
I find this idea interesting and I think it could work: the only real-world-relevant client that needs to access the relevant files is our Upgrader.
I understand this implies serving the relevant files (UDFs) under a new, dedicated hostname, e.g. https://upgrade.tails.boum.org/ or similar.
To avoid complicating the release process, we could leave the UDFs in tails.git, and when we push to tails.git's master branch, on top of refreshing our website like we already do, this would also trigger copying the UDFs to that new virtualhost's static files directory.https://gitlab.tails.boum.org/tails/tails/-/issues/18241Allow resuming a partial upgrade download during a future Tails session2021-03-16T16:07:55ZintrigeriAllow resuming a partial upgrade download during a future Tails sessionContext: https://gitlab.tails.boum.org/tails/tails/-/issues/15875#note_20544
This is about "(S2) I don’t have the time to download everything in 1 session. Maybe I’m traveling (Cris) or maybe I have limited time on Tails (Kim). In this ...Context: https://gitlab.tails.boum.org/tails/tails/-/issues/15875#note_20544
This is about "(S2) I don’t have the time to download everything in 1 session. Maybe I’m traveling (Cris) or maybe I have limited time on Tails (Kim). In this case, I would like to resume my download the next time I start Tails."
To solve it, @sajolida proposed that "Tails Upgrader would offer to do an upgrade again next time, maybe with a slightly adjusted prompt, and then resume the download and the progress bar where it stopped."
This seems doable when the user has a Persistent Storage unlocked. Instead of downloading to /tmp, Tails Upgrader could download to the Persistent Storage.https://gitlab.tails.boum.org/tails/tails/-/issues/18242Support pausing and resuming the download of an upgrade2021-07-25T10:00:32ZintrigeriSupport pausing and resuming the download of an upgradeContext: https://gitlab.tails.boum.org/tails/tails/-/issues/15875#note_20544
This is about "(S3) The download is eating all my bandwidth and I need to pause it momentarily to do something else. In this case, I would like to be able to p...Context: https://gitlab.tails.boum.org/tails/tails/-/issues/15875#note_20544
This is about "(S3) The download is eating all my bandwidth and I need to pause it momentarily to do something else. In this case, I would like to be able to pause the download myself and resume it when convenient."
To solve this, @sajolida proposed: "If the user tries to close Tails Upgrader, another dialog could appear and offer to resume the download and the upgrade."
This seems doable when the user has a Persistent Storage unlocked. Instead of downloading to /tmp, Tails Upgrader could download to the Persistent Storage.https://gitlab.tails.boum.org/tails/tails/-/issues/18386Rename "upgrades" as "updates"2023-11-15T01:01:34Zsajolidasajolida@pimienta.orgRename "upgrades" as "updates"Based on #11649, people searched for "update" 32% more than for "upgrade", our own term.
It's also the Android and iPhone terminology:
* https://support.google.com/android/answer/7680439?hl=en
* https://support.apple.com/en-us/HT204204Based on #11649, people searched for "update" 32% more than for "upgrade", our own term.
It's also the Android and iPhone terminology:
* https://support.google.com/android/answer/7680439?hl=en
* https://support.apple.com/en-us/HT204204https://gitlab.tails.boum.org/tails/tails/-/issues/18705Tails freezes when Wi-Fi adapter removed during automatic upgrade2021-12-29T23:17:28ZcbrownsteinTails freezes when Wi-Fi adapter removed during automatic upgradeIt was reported to Help Desk (WB: f2cd1959749ba77c502406e900dcd497) that if the Wi-Fi adapter is removed during an automatic upgrade, after networking is disabled for security reasons but before the upgrade completes, Tails shuts down.
...It was reported to Help Desk (WB: f2cd1959749ba77c502406e900dcd497) that if the Wi-Fi adapter is removed during an automatic upgrade, after networking is disabled for security reasons but before the upgrade completes, Tails shuts down.
I'll try to reproduce this using the few external Wi-Fi adapters that I have.https://gitlab.tails.boum.org/tails/tails/-/issues/18861Advertize better the changes made to Tails2023-07-20T22:14:27Zsajolidasajolida@pimienta.orgAdvertize better the changes made to TailsFor example, we could:
- Try to integrate the release notes in the upgrade steps
During #19103, one participant stuck to 4.29 not to lose the *OpenPGP Applet* when upgrading to 5.0. He didn't know about the change to Kleopatra.
In thi...For example, we could:
- Try to integrate the release notes in the upgrade steps
During #19103, one participant stuck to 4.29 not to lose the *OpenPGP Applet* when upgrading to 5.0. He didn't know about the change to Kleopatra.
In this case, we could also have made this change more progressively and integrate some help in Tails.https://gitlab.tails.boum.org/tails/tails/-/issues/18914Upgrade by cloning instructions are only for PC2022-04-12T22:19:46Zsajolidasajolida@pimienta.orgUpgrade by cloning instructions are only for PCSee https://tails.boum.org/upgrade/clone/.
I *think* that I did this on purpose as a simplification: the people who follow our instructions to upgrade by cloning already have another Tails and probably know how to start it on their comp...See https://tails.boum.org/upgrade/clone/.
I *think* that I did this on purpose as a simplification: the people who follow our instructions to upgrade by cloning already have another Tails and probably know how to start it on their computer.
Still, if we wanted to tackle this better we could:
A. Not give detailed starting instructions neither for PC nor Mac and point to https://tails.boum.org/doc/first_steps/start/pc/ and https://tails.boum.org/doc/first_steps/start/mac/ instead.
B. Add a note about Mac pointing to https://tails.boum.org/doc/first_steps/start/mac/.
C. Have 2 different pages.
I think that my preferred option is A, but we should check how easily it could be done in our complex installation instructions.
A point in favor of A is that the troubleshooting instructions don't make much sense in the context of upgrading, especially the advice to try installing again on the same USB stick and try installing on a different USB stick. If we do something else than A, we should tackle this elsewhere.https://gitlab.tails.boum.org/tails/tails/-/issues/18921Consider having Tails use Onion service to connect to our infrastructure2022-11-30T09:55:10ZintrigeriConsider having Tails use Onion service to connect to our infrastructureOn #18289, @groente wrote "it might be worthwhile discussing whether we can replace all references to tails.boum.org with onion addresses in the tails OS, imho it would be good not to rely too heavily on dns".
# Does not use Onion servi...On #18289, @groente wrote "it might be worthwhile discussing whether we can replace all references to tails.boum.org with onion addresses in the tails OS, imho it would be good not to rely too heavily on dns".
# Does not use Onion services
- security check
- web browser homepage (related to tails/tails#17936+)
- Upgrader
- XXX: fill this list
# Already uses Onion services
- WhisperBack
- APT → custom APT repo (aka. deb.t.b.o)https://gitlab.tails.boum.org/tails/tails/-/issues/18971Buggy plural forms translations from Transifex2023-02-02T08:55:29ZintrigeriBuggy plural forms translations from TransifexFor a long time, recent Hungarian & Macedonian PO files from Transifex fail our linters, @emmapeel, did some research months ago, and [reported about it](https://lists.autistici.org/message/20220209.112900.96369380.en.html
) to tails-l10...For a long time, recent Hungarian & Macedonian PO files from Transifex fail our linters, @emmapeel, did some research months ago, and [reported about it](https://lists.autistici.org/message/20220209.112900.96369380.en.html
) to tails-l10n, which does not work as a way to reach out to developers (I, for one, am not subscribed to that mailing list). I stumbled upon this report by chance today.
emmapeel's initial analysis was that this is not something translators can fix by themselves: we first have to change some i18n bits in the code. intrigeri later analysis (see below) disagrees.https://gitlab.tails.boum.org/tails/tails/-/issues/19091Mitigating kernel vulnerabilities proactively using livepatch2023-03-01T02:29:46Zcypher punksMitigating kernel vulnerabilities proactively using livepatchAs suggested in #19081, I'm opening a new ticket to start a discussion on this subject. I've worked on this on another Linux distribution made specifically for a company I worked for, so I have some experience with it, including its bene...As suggested in #19081, I'm opening a new ticket to start a discussion on this subject. I've worked on this on another Linux distribution made specifically for a company I worked for, so I have some experience with it, including its benefits and shortcomings, and can assist with getting it up and running, as well as providing the livepatch mitigations themselves (which I already do for every Tails kernel vulnerability and have for years, although I only post them occasionally).
**Background:**
Many kernel vulnerabilities are extremely easy to mitigate using livepatch kernel modules. The livepatch system is a Linux feature which allows simple, precise, and stable mitigations that can be used to patch live systems without an update. Unlike manual kernel patches, livepatches are **temporary** and add no extra delta with upstream, as they do not need to be maintained at all and are specific to only one version of Tails and its kernel. Livepatch is also natively supported by the Debian kernel.
Using livepatch as a mitigation would reduce the period of vulnerability between a security bug's disclosure and it's eventual fixing in Tails. Because Tails uses snapshot releases, serious kernel vulnerabilities often end up going unfixed for weeks, as emergency releases are not always practical (or fast). It would also allow (most) emergency releases to be skipped entirely.
**Proposal:**
I propose using livepatch to solve this. Right now, Tails' infrastructure is not conducive to this. It would be more practical when automatic and rolling upgrades are made available (IIRC there was a ticket for that, but I can't find it at the moment). This is not something which could be implemented extremely quickly because it requires the infrastructure and client-side code to support it.
The UX would be simple and easy. When Tails boots up and checks for available upgrades, it could additionally check for available livepatches and give the user the option to install it with the click of a button using the same easy pop-up as the "You should upgrade to Tails X" notice. Clicking the install option would download a pre-compiled livepatch module and insert it on the system. Compressed, the average livepatch module is around 50 KiB in size.https://gitlab.tails.boum.org/tails/tails/-/issues/20025Audit Tails Upgrader2023-11-09T10:04:46Zsajolidasajolida@pimienta.orgAudit Tails UpgraderRescuing interesting bits from #14508.Rescuing interesting bits from #14508.https://gitlab.tails.boum.org/tails/tails/-/issues/20105Make "Upgrade Later" the default option in the first popup of Tails Upgrader2024-03-26T23:33:25Zsajolidasajolida@pimienta.orgMake "Upgrade Later" the default option in the first popup of Tails UpgraderCf. emails:
- Bug report: 76aa88d80defec7ac9ce950b3e2a491c, people on flaky connections getting the popup over and over again
- Bug report: 35e1b5581ff84afc10883586d2db928e
Alternatively, using a notification instead of a pop-up that s...Cf. emails:
- Bug report: 76aa88d80defec7ac9ce950b3e2a491c, people on flaky connections getting the popup over and over again
- Bug report: 35e1b5581ff84afc10883586d2db928e
Alternatively, using a notification instead of a pop-up that steals focus would address these problems.https://gitlab.tails.boum.org/tails/tails/-/issues/20290URLs in Tails Upgrader dialogs should be hyperlinks2024-03-25T11:22:53ZBen Westgatebenwestgate@protonmail.comURLs in Tails Upgrader dialogs should be hyperlinksI can't click these and copy and paste is extra work!
![image](/uploads/d4fa35269a7a593f9e7f7aa33cb5dc2b/image.png)
Line 523 & 526 here appear to be a culprit and may need tags to create a hyperlink.
https://gitlab.tails.boum.org/tails...I can't click these and copy and paste is extra work!
![image](/uploads/d4fa35269a7a593f9e7f7aa33cb5dc2b/image.png)
Line 523 & 526 here appear to be a culprit and may need tags to create a hyperlink.
https://gitlab.tails.boum.org/tails/tails/-/blob/stable/config/chroot_local-includes/usr/src/iuk/lib/Tails/IUK/Frontend.pm