Re: [Tails-dev] Paranoid magical
Hi, intrigeri: Hi sajolida, intrigeri (2024-03-07): I understand you're talking about a Windows setting called Fast Startup (as opposed to the Fast Boot BIOS option that we document already). Correct? For avoidance of doubt, could you perhaps share a screenshot or link to some online doc about the setting you changed? @sajolida, I think this might explain a great number of Wi-Fi problems I see reported by users. AFAICT we don't document this yet. I'll let you judge whether this has a place in the Wi-Fi troubleshooting instructions or similar! :) Kristian confirmed privately that this is about this setting, for which Lenovo has instructions for Windows 8.1, 10, and 11: https://support.lenovo.com/gt/en/solutions/ht501793-how-to-turn-on-or-off-fast-startup-in-windows-1081 I am not surprised that Windows keeps locks etc on devices when using fastboot which is somehow similar to hibernation and won't be surprised if other devices than WiFi have issues. For example, it is impossible to mount -o rw an (unencrypted) Windows/NTFS partition because Windows keep a lock on it when using fastboot (through https://wiki.archlinux.org/title/Dual_boot_with_Windows#Fast_Startup_and_hibernation seems to document the inverse behavior) Therefore, if a note is added in the documentation, it may worth to generalize it and maybe add it also at least to https://tails.net/doc/advanced_topics/internal_hard_disk/. (I was wondering If it won't be possible to get fastboot status using efivars, ex for whisperback if such reports are common, but did not manage to find a solution) geb ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] LUKS 2 vulnerability
Hi, gagz: > hsiff...@eclipso.ch: >> Hi, does the new LUKS 2 vulnerability affect all previous and current >> version >> of Tails? >> Should we be concerned about the persistent storage feature? > > If I understand correctly, no and no. > If I'm not mistaken, the vulnerability affects LUKS2 volumes created > using cryptsetup since version 2.2.0, but Tails ships 2.1. > > But I might be wrong. > > [...] > > This is sensitive topic so please double check what I'm saying! >> >> *CVE-2021-4122: cryptsetup 2.x: decryption through LUKS2 reencryption >> crash >> recovery* >> https://seclists.org/oss-sec/2022/q1/34 Thanks for the link and the explanation. After due verification, depending how much this bug gets public, it may worth to issue a short simple language statement on tails.boum.org/news or just even twitter, as the bug description and attack scenario could IMHO be a bit scarring for Tails users: https://bugzilla.redhat.com/show_bug.cgi?id=2032401 (through, well, an attacker could also modify the system in that case). cheers, geb ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Question: Tails in undercover mode?
Hello, Hans: > Dear list, > > I am wondering, why tails no more get an undercover mode. IMO it is very > dangerous for users, if their window manager is not looking like the normal > window manager used everywhere, especially in countries, where any "strange" > desktop might cause attention on authorities. > > This problem could be easily solved. Most users are running either windows or > MacOS. For windows you can just use XFCE + kali-undercover, for Mac-design > there are several windowmanagers available (there is coming ElementaryOS in > my > mind). > > As you do only need the window-manager design, there should be no risk change. > > I might remember, tails got this option some years ago, but somehow this is > gone. Dunno why This camouflage option has been removed because the theme that proposed this feature was not working anymore, and because of lack of resources to work on it. You can read a bit more about that here : https://gitlab.tails.boum.org/tails/tails/-/issues/10830 https://gitlab.tails.boum.org/tails/blueprints/-/wikis/update_camouflage_for_jessie/ Unfortunately, the problem is not that easy to solve. As you can see on the previous links, reintroducing this feature using gnome themes would requires lot of work (at least at the moment these links were updated). Proposing other desktop-environments may looks simpler, but it would requires even more work, for UX, documentation, testing, ensuring everything works fine, keeping the image small enough etc, not only when integrating these desktop environments, but also for every releases. That said, maybe things have improved since last updates on the previous links. So if you are interested to give a deeper look of how it could be done in practice, that may be a small but important step :-). I did a quick testing of https://www.gnome-look.org/p/1216281/ (which is nice also because it has been maintained since a few years now). It seems the menus are only for Cinnamon, but maybe I did not tested it enough. -- geb ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Documentation about BIOS and firmware attacks
Hello, syster via Tails-dev: > I've just been reading through the new /doc/about/warnings/. > > It includes "No operating system can protect against BIOS and firmware > attacks" and explains why that is, followed by a suggestion how to > reduce that issue. > > What I'm missing is a hint to use Libre/Coreboot as an option to prevent > some of such attacks. (at least that is my assumption) > > https://tails.boum.org/doc/about/warnings/ I am not sure how relevant it would be here : libreboot/coreboot computers is mostly a niche market, in general and especially if you consider the few models that can run 100% without firmware. Being a nice market, it is costly, hard to setup, and hard to find, especially 100% blob free hardware. I am not sure more than a few percents of the Tails audience would do the switch. Therefore I don't think it would qualify as an actionable input/advice, and so how relevant it would be to add it. Giving unactionable security advises is a bad practice: If users an unable to do anything based on it, except noting there are solutions which are not available to them, it make just them feel less safe, powerless, and thus sad... :/ (I found the page being great regarding this last problem btw: it warns the users, but immediately after, slow down and either mentions solutions if actionable ones exist, either remind them there are unlikely to encounter those attacks in real life, and should not worry to much (which is nicer, but also true) :-) ) ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Preparing the next monthly report
Hi, Tails: > We should start writing the monthly report for last month. > > A blueprint with the current report, who volunteered to curate it, and > tips on how to fill it can be found on: > > https://tails.boum.org/blueprint/monthly_report/ > > But *you* should make sure that the cool stuff that *you* did will be I was unable to find the page to edit on https://tails.boum.org/blueprint/monthly_report/, or by downloading the repo (https://gitlab.tails.boum.org/tails/blueprints/-/wiki/git_access). Can someone please send the relevant address or clarify if I am missing something (it looks 2021 draft pages has not already being created) ? Cheers, geb ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [Tails-project] Call for feedback: *test* migration to GitLab
Hello, emma peel: > intrigeri: >> >> To test our upcoming GitLab workflow: >> >> 1. Activate your GitLab user account >> >>Follow the "Activate your GitLab user account" section in >> >> https://salsa.debian.org/tails-team/tails/-/blob/feature/15878-gitlab/wiki/src/contribute/working_together/GitLab/transition.mdwn#L8 >> > > I followed this instructions, but then I got a bit stuck because the system > asked me for a confirmation email and didnt show me where to ask it, after > following those steps. > Finally I saw the 'resent confirmation email' link (this was after I > activated my account and decided on a new password) and got a second link to > click on, and now I am a confirmed email user. I had the same issue: I did reset my password, then I had to ask for a confirmation email. I did not expect this as the password reset procedure had in my opinion also confirmed my mail. For me that's a detail : I am not sure it may worth to make it work without this second step (maybe mention it quickly in the doc?), just wanted to confirm Emma's report. (In redmine, I changed the mail associated in my account a couple of time over the years... maybe that's why I had to confirm it ?) geb ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
