Dear all,
Congratulations on the 6.2 release. You will find its arm64 port in the usual MEGA directory. The images are built on my 6.2-{arm64,asahi,raspi} tags (6.2/{arm64,asahi,raspi} branches). This time around the only big changes involve the Raspberry images. Let me take a step back first, I'll come back to RPi in a moment.
Recently, I came across this issue:
https://gitlab.tails.boum.org/tails/tails/-/issues/20347. Starting from v6.6 of Debian's linux kernel, the kernel modules will be compressed using xz, and as a result two build-time hooks (plus one initramfs hook) will misbehave. Now, the failure of one of them, 80-block-network, has security implications: since 80-block-network is unable to find the network drivers' modules anymore (they are renamed from *.ko to *.ko.xz), it fails (silently!) to populate /etc/modprobe.d/all-net-blocklist.conf - that is, the blocklist used to disable networking at Tails's boot. As a result, neither network blocking at boot, nor e.g. disabling networking using the Welcome screen, work. Patching this is quite simple, and I've already submitted a MR (
https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1499). To be very clear, x86_64 Tails uses linux 6.1, so it is not affected by this issue.
On the other hand, it so happens that the Raspberry kernel uses module compression already in linux 6.1, which is currently in the arm64 images. Thus the Raspi 6.1 Tails images are affected by this security issue. To fix it in Tails/RPi 6.2, I've already merged !1499 to all my branches (together with the uBlock patch which was the subject of previous emails), including those (arm64 and asahi) which do not use module compression (yet).
For the record, the test suite would have detected this issue easily. In fact, it actually did: I came across it while testing (unreleased, unpublished) Tails/Asahi builds with linux 6.6 in place of the currently installed 6.5. However, the Raspberry images use a non-virtualizable kernel, so I can't run the test suite on them. As I said previously, this is unfortunate since the RPi images include a decent number of custom Raspberry packages which - as you can see - makes testing a necessity.
Best,
NC
P.S.: I believe that an earlier version of the Asahi images was also affected by the same issue: it used a non-Debian kernel with compressed modules which would trigger the hooks' failure. At that time (before 6.1) I was not using the test suite yet. Avoiding these kind of things is the main reason why I switched to my own kernel builds, which are just the regular Debian kernel with the Asahi patches.
