Hi all!
A lot of time has passed since I last gave updates on the mailing list
about the arm64 port of Tails. I've been quite busy at work and I still
am (in fact, I am busier now than ever), but I've procrastinated writing
this email for 6+ months now, so I thought I'd better start writing it
now and finish whenever I finish :-) So here you go.
The first big update is last year I have upstreamed support for arm64
Linux to the Tor Browser and the Mullvad Browser [1]. In fact, the Tor
Project has been building official Linux arm64 nightlies since last
December, see e.g. [2]. Despite numerous requests from users and
sponsors alike [3-14], alpha and release builds have not been made
available yet. Oh, well. Because of this, my arm64 Tails images still
come with my own release builds of the Tor Browser installed [15]. The
code is the same as upstream, except that the build scripts are tweaked
so I can use an arm64 builder (specifically, an Apple M1 Mini running
Debian Forky) instead of the x86_64 (cross-)builders upstream uses.
The second update is more personal, but Tails-related nonetheless. A few
months ago I became a Debian Developer, uploading, to work on supporting
Apple Silicon machines and on Rust $STUFF. This is Tails-related first
of all because it is a spin-off of my work on the Tails port: to port
Tails to Apple Silicon, I first had to port Debian, and in the process I
learned a bunch of stuff which lead me to contribute to Debian and
ultimately to become a DD. In particular, I became a member of the
Bananas Team [16], which maintains all Apple Silicon related packages in
Debian. Additionally, still within the Bananas Team, I'm now maintaining
the infrastructure and extra packages (e.g. the Asahi kernel) needed to
run Debian on Apple Silicon, that can't be in Debian proper because they
are not fully upstreamed yet [17]. You can reach out to the Bananas Team
on IRC at #debian-bananas or via the mailing list
[email protected].
The second way that is related to Debian is, starting from version 7.0,
my Apple Silicon Tails port uses the same packages the Bananas Team is
distributing to Trixie users via the debian repository at
https://bananas-archive.debian.net/bananas-archive. Packages are built
in Salsa [18], Debian's Gitlab instance, and they are then distributed
using infrastructure which Thomas Glanzmann is generously lending to us.
I've talked about Thomas before: he's the guy who has been providing the
port of Debian Bookworm to Apple Silicon for years. He has now joined
the Bananas Team and we're working together to distribute Debian Trixie
to users.
Specifically, Tails 7.x for Apple Silicon -- which I now distribute at
[19], not in the shady MEGA folder anymore -- is just plain Tails 7.x
for arm64 plus the Asahi kernel, mesa drivers and u-boot bootloader.
This marks a huge difference with Tails 6.x, for which I had to backport
50+ of packages to Bookworm. All those packages are now included in
Debian Trixie proper, so they come straight from the Debian archive.
Actually, only the Asahi kernel is still needed in principle: the Asahi
mesa drivers are already in trixie-backports (I'm not installing them
from there, but rather from the Bananas archive, just so I don't have to
enable the extra trixie-backports sources) and the u-boot bootloader is
only needed for updating the bootloader itself, which is disabled at
this time anyway.
As for the arm64 port in general, vanilla Tails 7.0 for arm64 (i.e.
everything from the Debian archive, no meaningful departures from x86_64
Tails) was tested to work on a ThinkPad X13s with minor tweaks
(essentially, add the DTBs, a couple of scripts and some optional boot
parameters) which I've not merged to my main development branch
(wip/arm64) yet, since the Apple Silicon port is based on that too, and
I haven't had time to test the two of them in conjunction. I don't
expect they will conflict though. On the other hand, something broke
along the way of upgrading to Trixie in the Raspberry port (probably
some kernel module is missing) and, again, no time to fix, so I'm not
building that version for the moment.
I have one question for the Tails developers/infra maintainers. Is there
any chance Tails could provide time-based and tagged snapshots for arm64
packages in addition to amd64? Would it be too expensive? That would
greatly simplify the work of contributors (for instance, there was a
request to the mailing list just a few days ago), as at this time a
dirty DNS hack is required to make the build system install arm64
packages from Debian instead of from the Tails snapshot servers.
Cheers!
[1]
https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/1068
[2]
https://nightlies.tbb.torproject.org/nightly-builds/tor-browser-builds/tbb-nightly.2025.10.28/nightly-linux-aarch64/
[3]
https://forum.torproject.org/t/what-is-needed-for-tor-browser-on-non-x86-hardware/1031
[4] https://forum.torproject.org/t/tor-browser-for-arm-linux/5240
[5]
https://forum.torproject.org/t/issues-with-virtual-environment-on-m2-chip-mac/5960
[6]
https://forum.torproject.org/t/why-is-tor-download-page-serving-me-the-wrong-architecture/20084
[7]
https://forum.torproject.org/t/unable-to-install-tor-browser-on-ubuntu-25-04-for-raspberry-pi-5/18939/4
[8] https://github.com/mullvad/mullvad-browser/issues/11
[9] https://github.com/mullvad/mullvad-browser/issues/90
[10] https://github.com/mullvad/mullvad-browser/issues/498
[11] https://github.com/mullvad/mullvad-browser/issues/468
[12] https://github.com/mullvad/mullvad-browser/issues/473
[13]
https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/434
[14]
https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/473
[15] https://gitlab.com/NoisyCoil/tor-browser-build/-/releases
[16] https://wiki.debian.org/Teams/Bananas
[17] https://wiki.debian.org/InstallingDebianOn/Apple/M1
[18] https://salsa.debian.org/bananas-team/wip/
[19] https://tails.noisycoil.dev/images/
_______________________________________________
Tails-dev mailing list
[email protected]
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
[email protected].
