tails issueshttps://gitlab.tails.boum.org/tails/tails/-/issues2024-03-27T10:47:55Zhttps://gitlab.tails.boum.org/tails/tails/-/issues/20281Test suite: Scenario "Use Unlock VeraCrypt Volumes to unlock a basic VeraCryp...2024-03-27T10:47:55ZsegfaultTest suite: Scenario "Use Unlock VeraCrypt Volumes to unlock a basic VeraCrypt file container with a PIM" is flakyWaiting for the unlock dialog to close in `try_for(10) { !gnome_shell_unlock_dialog? }` in `features/step_definitions/veracrypt.rb` times out:
```
try_for() timeout expired (Timeout::Error)
./features/support/helpers/misc_helpers.rb:145...Waiting for the unlock dialog to close in `try_for(10) { !gnome_shell_unlock_dialog? }` in `features/step_definitions/veracrypt.rb` times out:
```
try_for() timeout expired (Timeout::Error)
./features/support/helpers/misc_helpers.rb:145:in `rescue in try_for'
./features/support/helpers/misc_helpers.rb:51:in `try_for'
./features/step_definitions/veracrypt.rb:206:in `/^I unlock and mount this VeraCrypt (volume|file container) with Unlock VeraCrypt Volumes$/'
features/veracrypt.feature:32:in `And I unlock and mount this VeraCrypt file container with Unlock VeraCrypt Volumes'
```
Failed test runs:
* https://jenkins.tails.boum.org/job/test_Tails_ISO_stable/4723/cucumber-html-reports/report-feature_40_3251716293.htmlTails_6.2segfaultsegfaulthttps://gitlab.tails.boum.org/tails/tails/-/issues/20280unlock-veracrypt-volumes opens second unlock dialog2024-03-27T10:47:56Zsegfaultunlock-veracrypt-volumes opens second unlock dialogFrom the journal from https://jenkins.tails.boum.org/job/test_Tails_ISO_stable/4723/cucumber-html-reports/report-feature_40_3251716293.html:
```
Mar 18 12:03:17 amnesia unlock-veracrypt-volumes.desktop[10105]: INFO:unlock_veracrypt_volu...From the journal from https://jenkins.tails.boum.org/job/test_Tails_ISO_stable/4723/cucumber-html-reports/report-feature_40_3251716293.html:
```
Mar 18 12:03:17 amnesia unlock-veracrypt-volumes.desktop[10105]: INFO:unlock_veracrypt_volumes.volume:Unlocking volume /dev/loop1
Mar 18 12:03:17 amnesia unlock-veracrypt-volumes.desktop[10105]: ERROR:unlock_veracrypt_volumes.volume:g-io-error-quark: An operation is already pending (36)
Mar 18 12:03:17 amnesia unlock-veracrypt-volumes.desktop[10105]: Traceback (most recent call last):
Mar 18 12:03:17 amnesia unlock-veracrypt-volumes.desktop[10105]: File "/usr/lib/python3/dist-packages/unlock_veracrypt_volumes/volume.py", line 265, in mount_cb
Mar 18 12:03:17 amnesia unlock-veracrypt-volumes.desktop[10105]: gio_volume.mount_finish(result)
Mar 18 12:03:17 amnesia unlock-veracrypt-volumes.desktop[10105]: gi.repository.GLib.GError: g-io-error-quark: An operation is already pending (36)
```
Manual testing shows that unlock-veracrypt-volumes indeed opens a second unlock dialog. I assume that the first one is opened by GNOME automatically since 0d87fae3887a20dd6b32417f87cc41f0db8c2009.Tails_6.2segfaultsegfaulthttps://gitlab.tails.boum.org/tails/tails/-/issues/20278Consider disabling Nvidia shader cache2024-03-28T14:31:17ZgroenteConsider disabling Nvidia shader cacheWhile working on #20261 i noticed back in November the Tor folks added the following line to their start-browser script:
``export __GL_SHADER_DISK_CACHE=0``
But this doesn't seem to be reflected in our tor-browser.sh script. Perhaps it...While working on #20261 i noticed back in November the Tor folks added the following line to their start-browser script:
``export __GL_SHADER_DISK_CACHE=0``
But this doesn't seem to be reflected in our tor-browser.sh script. Perhaps it should?
For more info, see https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/commit/f72fe52817c9a5eb990a7e070d9b94a369030c8fTails_6.2anonymanonymhttps://gitlab.tails.boum.org/tails/tails/-/issues/20277AppArmor regex in `common_steps.rb` soon to become obsolete2024-03-27T10:47:57ZNoisyCoilAppArmor regex in `common_steps.rb` soon to become obsolete[Commit 8c4b785](https://github.com/torvalds/linux/commit/8c4b785a86be) in the mainline Linux kernel, "apparmor: add mediation class information to auditing", introduced a new field - the mediation class - to the audit kernel logs starti...[Commit 8c4b785](https://github.com/torvalds/linux/commit/8c4b785a86be) in the mainline Linux kernel, "apparmor: add mediation class information to auditing", introduced a new field - the mediation class - to the audit kernel logs starting from v6.2. Due to this change, the [AppArmor regex](features/step_definitions/common_steps.rb#L1308) in the step definition `When /^AppArmor has (not )?denied "([^"]+)" from opening "([^"]+)"$/` will soon become obsolete (bookworm-backports and testing are both on v6.6, and unstable is on v6.7).
One possible fix maintaining backwards compatibility is
```
- 'apparmor="DENIED" operation="open" profile="%<profile>s" name="%<file>s"',
+ 'apparmor="DENIED" operation="open" \(class="[a-zA-Z]*" \)\?profile="%<profile>s" name="%<file>s"',
```
In Tails tests, the new `class` field only takes on the value `"file"` currently, but this may change in the future and I doubt defining a new step variable would be of much use.Tails_6.2segfaultsegfaulthttps://gitlab.tails.boum.org/tails/tails/-/issues/20272Disable PCI WiFi if USB Wifi Dongle Plugged in2024-03-18T18:47:37Zarrco4y7Disable PCI WiFi if USB Wifi Dongle Plugged inProblem: If not possible to disable PCI wifi in BIOS and if it is soldered on the mainboard users cannot protect themselvess against wifi fingerpinting as mentioned in issue #17831.
Issue Summary:
As per the previous issue (#17831), dis...Problem: If not possible to disable PCI wifi in BIOS and if it is soldered on the mainboard users cannot protect themselvess against wifi fingerpinting as mentioned in issue #17831.
Issue Summary:
As per the previous issue (#17831), disabling PCI WiFi is crucial for protecting users against wifi fingerprinting for a high thread model while using Tails OS. However, not all users have the option to disable PCI WiFi in their BIOS settings or may have a built-in PCI WiFi on their mainboard, making it difficult to protect themselves from this issue.
Proposed Solution:
To address this problem temporarily, it would be beneficial to add an option in the login screen that allows users to disable the PCI WiFi before the network manager starts. This will ensure that users can use Tails OS without exposing their identity through wifi fingerprinting of the PCI card and use USB WiFi dongles instead that can be thrown be replaced and switched easily.
Another possible solution and may be even preferred, is to automatically disable PCI WiFi when a USB WiFi dongle is connected during the boot process. This will provide an added layer of protection for users who may not be aware of the potential risks associated with wifi fingerprinting of the PCI network card.
Referenced Issues:
#17831
https://gitlab.tails.boum.org/tails/tails/-/issues/17831
#17779
https://gitlab.tails.boum.org/tails/tails/-/issues/17779https://gitlab.tails.boum.org/tails/tails/-/issues/20271Cannot add printer on 6.0 if CUPS configuration persisted from 5.x2024-03-23T20:28:20ZintrigeriCannot add printer on 6.0 if CUPS configuration persisted from 5.xI did not try to reproduce this myself yet, but the OP says it happened on 2 different Tails installations where the Printers persistence feature was enabled before upgrading to 6.0: if they try to add a printer, nothing shows up. But th...I did not try to reproduce this myself yet, but the OP says it happened on 2 different Tails installations where the Printers persistence feature was enabled before upgrading to 6.0: if they try to add a printer, nothing shows up. But this is fixed if they reset the CUPS configuration (Persistent Storage → disable Printers feature → delete data, then re-enable the Printers feature).
This suggests that CUPS config from 5.x breaks stuff on Bookworm.
Tentatively setting as a 6.1 goal because this could potentially impact tons of users, it breaks important use cases, the workaround is not obvious at all, and the fact it was only reported once so far may only be because one does not often add a new printer.Tails_6.2boyskaboyskahttps://gitlab.tails.boum.org/tails/tails/-/issues/20268Incorporate vm-scripts.git goodies into the early_patch machinery2024-03-15T10:55:57ZanonymIncorporate vm-scripts.git goodies into the early_patch machinerysegfault's [`vm-scripts.git`](https://gitlab.tails.boum.org/segfault/vm-scripts/) contains things that can improve the developer experience and should be available directly in Tails' Git:
* [`copy-new-includes`](https://gitlab.tails.bou...segfault's [`vm-scripts.git`](https://gitlab.tails.boum.org/segfault/vm-scripts/) contains things that can improve the developer experience and should be available directly in Tails' Git:
* [`copy-new-includes`](https://gitlab.tails.boum.org/segfault/vm-scripts/-/blob/main/copy-new-includes): on tails!1440 there is a discussion on how making it possible to run this code after `early_patch` time, when Tails is up an running, would be an improved `--late-patch` handling stuff like removed files, ownership/permissions etc. So also less code duplication.
* [`mount-new-includes`](https://gitlab.tails.boum.org/segfault/vm-scripts/-/blob/main/mount-new-includes): enabling this in a development VM booting Tails enables rapid development loops since the files you are changing in the Git tree on your host are bind-mounted to the corresponding places inside the running Tails guest. Again, it would be nice to be able to run this after Tails has booted to update the bind mounts, in case you start changing new files.
* [`symlink-new-includes`](https://gitlab.tails.boum.org/segfault/vm-scripts/-/blob/main/symlink-new-includes), but I'm not sure why we want this when we have `mount-new-includes` so probably we skip this one (?)
* [`install-packages`](https://gitlab.tails.boum.org/segfault/vm-scripts/-/blob/main/install-packages) seems useful (BTW, if we do we should just temporarily disabled `auto-update` to retain normal behavior)
* [`apply-updated-package-lists`](https://gitlab.tails.boum.org/segfault/vm-scripts/-/blob/main/apply-updated-package-lists) could be useful, but it seems inconvenient to not get the computed `$ADDED_PACKAGES` somehow available on the host so one can easily `apt download` them. From the top of my head the only solution I could think of is if there also is a read-write filesystem share where the Tails guest can dump `$ADDED_PACKAGES` to on the host. Actually, such a share is useful for times when one wants to extract other stuff to the host, so why not?
* There's a bunch more that I haven't look at yet.
While we're at it, I think there are some general improvements for `early_patch` itself that fits into this work:
* As mentioned above, being able to run it the `early_patch` machinery (or parts of it?) after booting has many uses. If it was enable on the kernel commandline this could be done without admin privileges, otherwise (without thinking too much about it) I think it's safest that admin privileges are required.
* Perhaps `early_patch` should always set a default root password (unless `rootpw=` was explicitly set on the kernel commandline) like `a` or whatever? Seems convenient, and something that otherwise easily could be forgotten and require a reboot.
* Personally I think `early_patch` should default to `mount-new-includes`, and only run the `hook` script if told so explicitly, e.g. something like `early_patch=hook`. At least for me that (and the default root password) would cover 99% of what I use `early_patch` for without having to mess with the `hook` script.
* Maybe it would be nice to make a nice library one can source in one's `hook` script to get convenient functions like `bind` that bind-mounts a file from `config/chroot_local-includes/` and similar? My current `hook` script has like a hundred lines of functions like that there's no reason we all re-implement individually.
* Other arguments to `early_patch=` beyond the current only argument `umount`:
* `bind`: `mount-new-includes`, this one is assumed unless `copy`, `link` or `hook` are explicitly enabled, and should raise an error if `umount` is enabled, or if combined with `copy`/`link` (same applies for them).
* `copy`: `copy-new-includes`, which is assumed if `umount` is enabled and `bind`, `link` or `hook` are not passed.
* `link`: `symlink-new-includes` if we want it (doubtful).
* `hook`: the only way to run the `hook` script given the new default. Runs after (?) `copy`/`bind`/`link` if they are explicitly enabled.
* `debs`: `install-packages` if we want it. Packages are installed before `copy`/`bind`/`link`/`hook` so they can override or use the package contents.
* `pkgs`, `packages`: `apply-updated-package-lists` if we want it.
* If `early_patch` fails due to an unknown argument, write the complete help when dropping to the rescue shell so the developer quickly can see what their error was and correct it when rebooting. Similarly, if the required filesystem share isn't present (`mount`ing it fails) it should tell the developer to add the required filesystem share and dump the required XML. Mentioning the docs might be worth it even if the text can only by read by Human Eyeball™ and not copied/clicked.
* Let's move the mount point to `/mnt/tails.git` and change the `target` `dir=` to `tails.git`. I sometimes have other filesystem shares I want to mount (like my host's `src` dir, which I used to call `src` for a decade before `early_patch` came along :angry:), and then a subdir under `/mnt` is convenient. If we want to import `install-packages` they could be sourced from a filesystem share mounted on `/mnt/tails.debs` with `target` `dir=` as `tails.debs`.
* Maybe just rename it to `patch` which is easier to type? Maybe even `p` can be an alias?anonymanonymhttps://gitlab.tails.boum.org/tails/tails/-/issues/20267Figure out how we should prioritize adding WebTunnel support2024-03-16T22:31:30ZintrigeriFigure out how we should prioritize adding WebTunnel supportThe benefits are quite clearly described in
https://blog.torproject.org/introducing-webtunnel-evading-censorship-by-hiding-in-plain-sight/
What would the cost look like?The benefits are quite clearly described in
https://blog.torproject.org/introducing-webtunnel-evading-censorship-by-hiding-in-plain-sight/
What would the cost look like?https://gitlab.tails.boum.org/tails/tails/-/issues/20265iBus input switcher in GNOME top bar is hidden while a password input field h...2024-03-14T20:40:52ZmelteddolliBus input switcher in GNOME top bar is hidden while a password input field has the focus in Tor BrowserThis is about the "en" button in the top bar, next to the user menu. It comes back once something else is focused. If I focus a non-password text input field in Tor Browser, such as the search box on our website, the exact same warnings ...This is about the "en" button in the top bar, next to the user menu. It comes back once something else is focused. If I focus a non-password text input field in Tor Browser, such as the search box on our website, the exact same warnings appear in the Journal, but the iBus input selection widget remains visible.
I can reproduce the problem with the Unsafe Browser. But I can't reproduce the problem in few other password fields that I've tried: GNOME Disks, KeePassXC. So it might be specific to Firefox.
On Tails 5.x we don't display that widget when using the default (English US) keyboard layout. And even if I choose a non-default layout in the Welcome Screen, I can't reproduce the bug.
On my sid I can't reproduce this in Tor Browser nor in Chromium.
Somewhat similar/related issues:
- https://askubuntu.com/questions/1214208/input-language-switching-in-password-fields
- https://bugs.launchpad.net/ubuntu-gnome/+bug/1566357
# Original report
Tails 6.0 has an easily reproducible bug where when you click in the “password” box on just about any website, to register or login, the “en” in the top right panel part of the screen will disappear and the following error is shown in ‘journalctl’ and repeats:[1]
amnesia gnome-shell[#####]: The XKEYBOARD keymap compiler (xkbcomp) reports:
amnesia gnome-shell[#####]: > Warning: Unsupported maximum keycode 708, clipping.
amnesia gnome-shell[#####]: > X11 cannot support keycodes above 255.
amnesia gnome-shell[#####]: Errors from xkbcomp are not fatal to the X server
[1] removed date/time and numbers in boxes
When one then clicks anywhere else outside of the password box, the “en” reappears in the panel at the top right.
###
What wasn't tested: I didn't try testing this with another language other than English so I don't know whether or not other languages are impacted.
###
= There is a forum thread about this:
https://forum.torproject.org/t/tails-6-0-bug-clicking-in-password-boxes-on-websites-causes-en-in-panel-to-disappear/11867https://gitlab.tails.boum.org/tails/tails/-/issues/20263Test suite: Step "all notifications have disappeared" is flaky2024-03-27T14:23:54ZsegfaultTest suite: Step "all notifications have disappeared" is flakyRelevant excerpt from the debug.log:
```
And I start Tails from USB drive "__internal" with network unplugged and I login with persistence enabled (failed) # features/step_definitions/common_ste...Relevant excerpt from the debug.log:
```
And I start Tails from USB drive "__internal" with network unplugged and I login with persistence enabled (failed) # features/step_definitions/common_steps.rb:280
execution expired (RemoteShell::Timeout)
./features/support/helpers/remote_shell.rb:56:in `read'
./features/support/helpers/remote_shell.rb:56:in `block (3 levels) in communicate'
./features/support/helpers/remote_shell.rb:55:in `block (2 levels) in communicate'
./features/support/helpers/remote_shell.rb:42:in `loop'
./features/support/helpers/remote_shell.rb:42:in `block in communicate'
./features/support/helpers/remote_shell.rb:37:in `communicate'
./features/support/helpers/remote_shell.rb:174:in `execute'
./features/support/helpers/remote_shell.rb:185:in `initialize'
./features/support/helpers/dogtail.rb:80:in `new'
./features/support/helpers/dogtail.rb:80:in `run'
./features/support/helpers/dogtail.rb:70:in `initialize'
./features/step_definitions/common_steps.rb:714:in `new'
./features/step_definitions/common_steps.rb:714:in `/^all notifications have disappeared$/'
./features/step_definitions/common_steps.rb:297:in `/^I start Tails from (.+?) drive "(.+?)"( with network unplugged)?( and I login( with persistence enabled)?( with the changed persistence passphrase)?( (?:and|with) an administration password)?)?$/'
features/additional_software_packages.feature:35:in `And I start Tails from USB drive "__internal" with network unplugged and I login with persistence enabled'
```
What happened is that the `gnome_shell = Dogtail::Application.new('gnome-shell')` command in step `all notifications have disappeared` in `common_steps.rb` (used to be on line 714 in the commit the above failure happened on, on current stable its on line 713) failed with `RemoteShell::Timeout`.
During the subsequent test cleanup, the remote shell is also unresponsive, so we get no journal. The remote shell and Dogtail were responsive before in the same scenario though (e.g. in the Welcome Screen).
Failing test runs:
* https://jenkins.tails.boum.org/job/test_Tails_ISO_stable/4703/cucumber-html-reports/report-feature_6_4113196806.html
* ~~https://jenkins.tails.boum.org/job/test_Tails_ISO_20219-pipewire/14//cucumber-html-reports/overview-failures.html~~ (cleaned up by Jenkins, not sure if it was the exact same error)
* https://jenkins.tails.boum.org/job/test_Tails_ISO_stable/4727/cucumber-html-reports/report-feature_7_295607190.html
* https://jenkins.tails.boum.org/job/test_Tails_ISO_20280-fix-second-unlock-dialog/1//cucumber-html-reports/overview-failures.htmlsegfaultsegfaulthttps://gitlab.tails.boum.org/tails/tails/-/issues/20260(Security bypass) WebGL runs on the Safer security level in some situations2024-03-12T02:05:25Zcypher punks(Security bypass) WebGL runs on the Safer security level in some situationsI think I've accidentally discovered a WebGL bypass in Tor Browser. It allows running WebGL code even if the security level is set "Safer". I can't find a minimal way to reproduce it 100% of the time, but these steps seem to work:
1. Se...I think I've accidentally discovered a WebGL bypass in Tor Browser. It allows running WebGL code even if the security level is set "Safer". I can't find a minimal way to reproduce it 100% of the time, but these steps seem to work:
1. Set the security level to Safer.
2. Upload some file to https://wormhole.app/.
3. Copy the download link that it creates onto a paste website like https://bpa.st/.
4. Highlight the plaintext link with your cursor, right-click, and click "Open link in new tab".
Expected behavior: The website loads with a click-to-play option for WebGL.
Actual behavior: A distracting Doctor Who-esque WebGL-powered swirling wormhole animation plays in the background. This does NOT happen if the link is opened any other way (such as being pasted into the URL bar or clicked as hyperlink) or if webgl.disabled is set to true in about:config.
This doesn't always happen, and it doesn't seem to happen with any other WebGL-enabled sites that I've seen, but the fact that it ever happens when WebGL is disabled via the security level is a problem. It also only seems to happen when opening a download link in a new tab and can't be triggered on the front page.
I can do a screen recording of myself triggering the issue if it is necessary.https://gitlab.tails.boum.org/tails/tails/-/issues/20259"Application is not responding" during upgrade with Tails Cloner2024-03-13T10:11:02ZErik Moeller"Application is not responding" during upgrade with Tails ClonerOn Tails 6, when applying the new Tails version to a 64 GB USB drive using the Tails Cloner, I repeatedly got the "Application is not responding | Force Quit | Wait" dialog while Tails was writing to the drive I updated. The drive I upda...On Tails 6, when applying the new Tails version to a 64 GB USB drive using the Tails Cloner, I repeatedly got the "Application is not responding | Force Quit | Wait" dialog while Tails was writing to the drive I updated. The drive I updated had a persistent volume.
Repeatedly clicking "Wait" resolved the issue, and the drive was successfully updated.https://gitlab.tails.boum.org/tails/tails/-/issues/20258Docs/screenshots for manually updating Tails lack the "clone the current pers...2024-03-28T02:05:50ZErik MoellerDocs/screenshots for manually updating Tails lack the "clone the current persistent storage" optionThe [manual update docs](https://tails.net/upgrade/tails/index.en.html) are a bit outdated.
Notably, the screenshot misses the "clone the current persistent storage" checkbox, and an explanation of what option the user should set for th...The [manual update docs](https://tails.net/upgrade/tails/index.en.html) are a bit outdated.
Notably, the screenshot misses the "clone the current persistent storage" checkbox, and an explanation of what option the user should set for that checkbox. This creates some potential for confusion, as cloning the "current" persistent storage (of the drive holding the version they'll upgrade to) is most likely _not_ what they want when upgrading another Tails.
I'm also not sure if the "Click Delete All Data and Install to confirm" instruction is still accurate -- I do not recall seeing that prompt when upgrading. Again, there's some potential for confusion here as to what data will be deleted/preserved.sajolidasajolida@pimienta.orgsajolidasajolida@pimienta.orghttps://gitlab.tails.boum.org/tails/tails/-/issues/20254coreboot systems are not supported2024-03-21T02:31:33Zintrigericoreboot systems are not supportedI don't know if this affects *all* coreboot systems or only some, but we receive quite a few "Resizing system partition failed" reports, because our 1st boot partitioning hook can't do its job: `$FSUUID is unset, probably because the boo...I don't know if this affects *all* coreboot systems or only some, but we receive quite a few "Resizing system partition failed" reports, because our 1st boot partitioning hook can't do its job: `$FSUUID is unset, probably because the boot medium is an ISO, and not a USB image. Skipping partitioning.` So automatic upgrades and creating Persistent Storage won't work.
It seems we might need to ship a GRUB compiled for coreboot to solve that.
For now I'm recording this as a known issue and "great patches welcome". We'll see if we ever want, and can afford, to prioritize this any higher.https://gitlab.tails.boum.org/tails/tails/-/issues/20253Power off button in the user menu of the Welcome Screen does not work in 6.02024-03-27T01:09:00ZintrigeriPower off button in the user menu of the Welcome Screen does not work in 6.0Reported in wb:9166e7bf9b8975b0599328185aaefae3. It's not a huge deal because the **Shutdown** button in the Welcome Screen window works, but still, it feels unpolished.
I doubt that's worth spending any non-trivial developer time on, s...Reported in wb:9166e7bf9b8975b0599328185aaefae3. It's not a huge deal because the **Shutdown** button in the Welcome Screen window works, but still, it feels unpolished.
I doubt that's worth spending any non-trivial developer time on, so not flagging for FT, but maybe @sajolida thinks differently :)https://gitlab.tails.boum.org/tails/tails/-/issues/20249Upgrade Vagrant basebox to Debian Trixie2024-03-25T08:35:20ZintrigeriUpgrade Vagrant basebox to Debian Trixie# When
- After Debian Trixie is released.
# Tasks
- [ ] Make our version of `live-build` work with `hostname` and `start-stop-daemon` moved to `/usr`: https://bugs.debian.org/1064408
# Note
- Technically this is orthogonal to 7.0, b...# When
- After Debian Trixie is released.
# Tasks
- [ ] Make our version of `live-build` work with `hostname` and `start-stop-daemon` moved to `/usr`: https://bugs.debian.org/1064408
# Note
- Technically this is orthogonal to 7.0, but still, it could be a good time to do that.
- We _need_ to do it: we can keep the Bookworm one until Debian 14 is released. We should at some point switch to LTS security support, but it might be the case (to be investigated) that this time we don't actually need to do anything.Tails_7.0https://gitlab.tails.boum.org/tails/tails/-/issues/20248Some apps don't honor Dark Mode2024-03-27T00:13:12ZintrigeriSome apps don't honor Dark ModeIn the 6.0 release notes we boasted about the new Dark Mode feature. Unfortunately, not all apps honor it.
Users reported that these apps don't honor it:
- [ ] Onion Circuits
- [ ] TerminalIn the 6.0 release notes we boasted about the new Dark Mode feature. Unfortunately, not all apps honor it.
Users reported that these apps don't honor it:
- [ ] Onion Circuits
- [ ] Terminalhttps://gitlab.tails.boum.org/tails/tails/-/issues/20247Manual upgrade doc refers to non-existing confirmation step2024-03-28T02:07:30ZintrigeriManual upgrade doc refers to non-existing confirmation stephttps://tails.net/upgrade/clone/ has "Read the warning message in the confirmation dialog" and "Click Delete All Data and Install to confirm" steps. A user reported this step did not match reality: they did not see this message when upgr...https://tails.net/upgrade/clone/ has "Read the warning message in the confirmation dialog" and "Click Delete All Data and Install to confirm" steps. A user reported this step did not match reality: they did not see this message when upgrading. I've confirmed by testing. And a look at the code & test suite suggests this message is only displayed when *installing* (on a stick with no Persistent Storage), not when upgrading.https://gitlab.tails.boum.org/tails/tails/-/issues/20241Drop VirtualBox support2024-03-28T17:04:00ZanonymDrop VirtualBox supportTails' VirtualBox support is really bad (e.g. #19324, #18781) due to lack of guest additions (#18728).
The manual test we do each release ~~feels~~ is really useless. In fact, when the test was originally added it was specifically about...Tails' VirtualBox support is really bad (e.g. #19324, #18781) due to lack of guest additions (#18728).
The manual test we do each release ~~feels~~ is really useless. In fact, when the test was originally added it was specifically about the guest additions, presumably because they kept breaking. What do we get from testing Tails in VirtualBox without guest additions? If we get anything I doubt it is worth it, and that there are more important things we do not manually test.
I don't think we in good faith can continue to [advertise VirtualBox support to users](https://tails.net/doc/advanced_topics/virtualization/virtualbox/) in this poor state. We we're already considering completely dropping VirtualBox support back in Oct 2021 when we stopped compiling the guest additions, but we had some optimistic ideas that didn't pan out (https://gitlab.tails.boum.org/tails/tails/-/issues/18643#note_179126, #18666), and here we are now, over two years later, still pretending things are good or are going to get better. IMHO it is high time to drop it, and even if someone comes up with another optimistic plan I don't think it should prevent us from dropping it, instead let them restore the docs/tests when they actually land the fix in Tails.Tails_6.2boyskaboyskahttps://gitlab.tails.boum.org/tails/tails/-/issues/20240GitLab Webhook to automatically set Doing and Needs Validation labels2024-03-04T08:41:21ZsegfaultGitLab Webhook to automatically set Doing and Needs Validation labelsI keep forgetting to manually change the issue status to "Doing" and "Needs Validation".
I would love to have a GitLab webhook which automatically:
* Sets the Doing label and unsets any "To Do" or "Needs Validation" labels if a draft MR...I keep forgetting to manually change the issue status to "Doing" and "Needs Validation".
I would love to have a GitLab webhook which automatically:
* Sets the Doing label and unsets any "To Do" or "Needs Validation" labels if a draft MR is created or an MR is marked as draft.
* Sets the "Needs Validation" label and unsets any "To Do" or "Doing" labels if an non-draft MR is created or an MR is marked as ready.