tails issueshttps://gitlab.tails.boum.org/tails/tails/-/issues2024-03-04T08:41:21Zhttps://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.https://gitlab.tails.boum.org/tails/tails/-/issues/20239Upgrade to po4a 0.692024-02-29T11:59:25ZintrigeriUpgrade to po4a 0.69See #18667 wrt. how we did it last time. Does the reason why we needed a coordinated upgrade still apply to the 0.62 → 0.69 upgrade?See #18667 wrt. how we did it last time. Does the reason why we needed a coordinated upgrade still apply to the 0.62 → 0.69 upgrade?https://gitlab.tails.boum.org/tails/tails/-/issues/20235Release process: $TEST_IUK_SOURCE_VERSIONS wrong for Debian major version bumps2024-03-01T14:41:50ZanonymRelease process: $TEST_IUK_SOURCE_VERSIONS wrong for Debian major version bumpsFirst of all, I'm a bit annoyed by the lack of concise and precise terminology for when we bump version `N.x` → `(N+1).y`, which is what I mean with "major version bumps" in the title. But "major" isn't great as we already talk about "m...First of all, I'm a bit annoyed by the lack of concise and precise terminology for when we bump version `N.x` → `(N+1).y`, which is what I mean with "major version bumps" in the title. But "major" isn't great as we already talk about "major versions" (e.g. `$NEXT_PLANNED_MAJOR_VERSION`) and "major releases" (e.g. `$MAJOR_RELEASE`). If any one has a suggestion how to improve this, please let me know!
Any way, while being RM for Tails 6.0 I had an issue with how `rm-config` calculates `$TEST_IUK_SOURCE_VERSIONS`: it became `5.22 6.0~rc1`, which is incorrect since we only provided IUKs from 6.0~rc1. As a consequence the "Wait until the IUKs are available" code snippet resulted in me waiting for 2 hours extra for the mirrors to sync before I noticed that it was looking for the non-existent `5.22_to_6.0` IUK. So in this case `$TEST_IUK_SOURCE_VERSIONS` should have been only `6.0~rc1`.Tails_7.0https://gitlab.tails.boum.org/tails/tails/-/issues/20234Test suite: Opening GNOME menus is flaky2024-02-28T11:11:30ZsegfaultTest suite: Opening GNOME menus is flakyScenario "Do not localize the XDG User Dirs to be able to use those dirs in Tor Browser" failed in https://jenkins.tails.boum.org/job/test_Tails_ISO_exit-on-idle/21 because the GNOME menu was not opened.Scenario "Do not localize the XDG User Dirs to be able to use those dirs in Tor Browser" failed in https://jenkins.tails.boum.org/job/test_Tails_ISO_exit-on-idle/21 because the GNOME menu was not opened.https://gitlab.tails.boum.org/tails/tails/-/issues/20231Changing locale in the Welcome Screen doesn't change it for Accessibility menu2024-02-27T14:50:37ZboyskaChanging locale in the Welcome Screen doesn't change it for Accessibility menu... nor for the date widget or anything else, actually
<img src="/uploads/a181fd8a8fac4534956b479677a7474c/Screenshot_tails-amd64-6.0_2024-02-27_12_49_58.png" width="300px" />... nor for the date widget or anything else, actually
<img src="/uploads/a181fd8a8fac4534956b479677a7474c/Screenshot_tails-amd64-6.0_2024-02-27_12_49_58.png" width="300px" />https://gitlab.tails.boum.org/tails/tails/-/issues/20226syntax error in gdm-shell-tails.desktop2024-02-29T09:58:17Zboyskasyntax error in gdm-shell-tails.desktopI found these errors in the journal. I don't know how serious is that, but maybe we should investigate?
```
gdm-shell-tails.desktop[4953]: syntax error: line 1 of stdin
gdm-shell-tails.desktop[4953]: Errors encountered in stdin; not com...I found these errors in the journal. I don't know how serious is that, but maybe we should investigate?
```
gdm-shell-tails.desktop[4953]: syntax error: line 1 of stdin
gdm-shell-tails.desktop[4953]: Errors encountered in stdin; not compiled
```https://gitlab.tails.boum.org/tails/tails/-/issues/20216OnionShare has no app icon2024-02-20T18:35:30ZsegfaultOnionShare has no app iconThe OnionShare version backported in https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1375 is shown with the fallback app icon.The OnionShare version backported in https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1375 is shown with the fallback app icon.https://gitlab.tails.boum.org/tails/tails/-/issues/20215Check if workaround for cursor size in QT applications is still needed2024-02-21T09:02:38ZsegfaultCheck if workaround for cursor size in QT applications is still neededSee https://gitlab.tails.boum.org/tails/tails/-/issues/20206.See https://gitlab.tails.boum.org/tails/tails/-/issues/20206.Tails_7.0https://gitlab.tails.boum.org/tails/tails/-/issues/20214Update po_translatable_pages for Tails 7.02024-02-20T15:04:14ZintrigeriUpdate po_translatable_pages for Tails 7.0On each release n of Tails 3.0, 4.0, etc. `po_translatable_pages` should be updated to disable translations of `news/version_*` for release n-2.
* [ ] in tails/tails
* [ ] in tails/puppet-tails
* [ ] create a new related issue to do the...On each release n of Tails 3.0, 4.0, etc. `po_translatable_pages` should be updated to disable translations of `news/version_*` for release n-2.
* [ ] in tails/tails
* [ ] in tails/puppet-tails
* [ ] create a new related issue to do the same in N+1.0
The best time to do this is in the days before or after the Tails N.0 release.
The best place to do this initially is on `master` rather than on the branch where that release is being prepared (`testing`): this avoids having to coordinate the deployment of the Puppet changes with the release process. Once this has been done on `master` and on the production website, merge `master` → `stable` → `testing` → `devel`.Tails_7.0https://gitlab.tails.boum.org/tails/tails/-/issues/20209Upgrade to Bookworm 12.62024-02-19T09:35:38ZintrigeriUpgrade to Bookworm 12.6> The next point release for "bookworm" (12.6) is scheduled for Saturday, April 6th. Processing of new uploads into bookworm-proposed-updates will be frozen during the preceeding weekend.> The next point release for "bookworm" (12.6) is scheduled for Saturday, April 6th. Processing of new uploads into bookworm-proposed-updates will be frozen during the preceeding weekend.Tails_6.2https://gitlab.tails.boum.org/tails/tails/-/issues/20204Rename "Language & Region" as "Language & Formats"2024-03-26T23:46:53Zsajolidasajolida@pimienta.orgRename "Language & Region" as "Language & Formats"Someone wrote us thinking that the time zone would be set to their country since it was selected in the "Region" settings.
The real solution to their problem would be #12094.
Still, people might find "Formats" more neutral than "Region...Someone wrote us thinking that the time zone would be set to their country since it was selected in the "Region" settings.
The real solution to their problem would be #12094.
Still, people might find "Formats" more neutral than "Region" in the sense that it's not linked to their location (even though I don't remember this being an issue in usability tests).sajolidasajolida@pimienta.orgsajolidasajolida@pimienta.orghttps://gitlab.tails.boum.org/tails/tails/-/issues/20203Update our doc to Tails 6.0 (Trixie)2024-02-14T22:31:59Zsajolidasajolida@pimienta.orgUpdate our doc to Tails 6.0 (Trixie)Tails_7.0https://gitlab.tails.boum.org/tails/tails/-/issues/20202Improve the translation process and documentation2024-02-14T14:50:51ZZen FuImprove the translation process and documentationIn Dec 2023 we ran a small survey to find out what was the current state of translation teams:
- tails#19999+
- [Results and initial analysis](https://gitlab.tails.boum.org/tails/summit/-/wikis/Teams/Translation_Platform/State-of-transl...In Dec 2023 we ran a small survey to find out what was the current state of translation teams:
- tails#19999+
- [Results and initial analysis](https://gitlab.tails.boum.org/tails/summit/-/wikis/Teams/Translation_Platform/State-of-translation-teams-on-Dec-2023)
This issue intends to come up with changes that could be implemented to improve the translation process and documentation, as a follow-up of those findings. We shoud also consider changes to the role of the Translation Platform maintainers (see [this comment](https://gitlab.tails.boum.org/tails/tails/-/issues/20047#note_221680) for context).https://gitlab.tails.boum.org/tails/tails/-/issues/20201Buggy startup notification for WhisperBack2024-02-14T17:02:59ZintrigeriBuggy startup notification for WhisperBackGNOME Shell does not detect when WhisperBack has finished starting: the spinner in the task bar keeps spinning (and once #19920 is fixed, I suppose the spinner on the desktop will do the same). Reproduced on 5.22 and 6.0~rc1.
This looks...GNOME Shell does not detect when WhisperBack has finished starting: the spinner in the task bar keeps spinning (and once #19920 is fixed, I suppose the spinner on the desktop will do the same). Reproduced on 5.22 and 6.0~rc1.
This looks very much like #18330, which @boyska fixed with !457.
My hunch is that the fix for #19997 included in !1290 broke this by letting sudo drop the environment variable we need for this functionality.https://gitlab.tails.boum.org/tails/tails/-/issues/20198Upgrade to OnionShare 2.6+, take 22024-03-23T20:28:16ZintrigeriUpgrade to OnionShare 2.6+, take 2In %"Tails_6.0" we had to revert (!1375) to the version from Bullseye due to tails/tails#20135 and to a lesser degree tails/tails#20140.
That's not ideal.
Ideally we want to get OnionShare 2.6+ working in Debian Bookworm (+ backports),...In %"Tails_6.0" we had to revert (!1375) to the version from Bullseye due to tails/tails#20135 and to a lesser degree tails/tails#20140.
That's not ideal.
Ideally we want to get OnionShare 2.6+ working in Debian Bookworm (+ backports), potentially coordinating with the OnionShare upstream. (cc @hefee, @nodens)
But if this is not resolved on the medium-term we need to check if `bin/needed-package-updates` handles this situation properly (e.g. will it detect if one of the forward-ported packages has a security update in Bullseye?)Tails_6.2hefeehefeehttps://gitlab.tails.boum.org/tails/tails/-/issues/20194Design future improvements to backups2024-02-13T00:02:55Zsajolidasajolida@pimienta.orgDesign future improvements to backupsIn the past years, we didn't prioritize working on backups from the core team. It was still a very hot topic, so as a result, other people starting pushing for incremental changes to improve the situation: @david-a-wheeler in #18504, @se...In the past years, we didn't prioritize working on backups from the core team. It was still a very hot topic, so as a result, other people starting pushing for incremental changes to improve the situation: @david-a-wheeler in #18504, @segfault in #7049, and @BenWestgate in a bunch of places.
I'm very excited to see that other people are contributing very important improvements outside of the limitations of the core team, but I feel like we're reaching a point where all this would need a bit more coordination, deeper thoughts, less context-switching, and more upfront design. For example, right now `tails-backup` and `tails-cloner` feel a bit like duplicates, they work independently from `tails-persistent-storage`, etc.
So, before we start working on another bit of backup tooling, I'd propose @foundations-team to sit down with me design better the broader picture of what backup system we want in the end. Once we have a plan, we could still make it possible for other people to implement this plan bit by bit, but with more coordination.
We're aiming at 2024Q2 for that.sajolidasajolida@pimienta.orgsajolidasajolida@pimienta.orghttps://gitlab.tails.boum.org/tails/tails/-/issues/20189Migrate to new bug triaging setup2024-03-04T11:24:32ZintrigeriMigrate to new bug triaging setupBased on the discussion we had on tails/tails#19719, @boyska and @intrigeri designed the following plan.
[[_TOC_]]
Things we want
=================
Security
---------
boyska considers IMAP equivalent to a ticketing webapplication in...Based on the discussion we had on tails/tails#19719, @boyska and @intrigeri designed the following plan.
[[_TOC_]]
Things we want
=================
Security
---------
boyska considers IMAP equivalent to a ticketing webapplication in terms of security (very quick analysis)
- assuming WhisperBack reports are stored in cleartext server-side in both cases?
- I'm assuming that breaking Thunderbird security is easier than breaking even a simple basicauth on a webserver. (if you expose a web application directly, than it might be a different story, but screening it is usually simple, effective, and not too geeky)
Spam filtering
----------------
As painless as possible.
Automatic spam filtering is great.
Manual spam filtering (maybe to complement the automatic one) is better done only once.
Track conversation
--------------------
Knowing the answer of this question:
- "Has someone already handled this?"
- "How many bug reports have not been processed by anyone last month?"
- Has someone made it clear to UX (or segfault or whoever) that they'd better look at this?
Categorization
----------------
We might want to signify that a message is "hardware issue" / tps / TorConnection / etc.
Efficiency
----------
We have a large volume of incoming messaging, that include large logs. Some of us developed their own tricks/tooling for doing that better. In finding new solutions, we should consider how feasible it is for them to quickly scan messages.
Split 2 problems?
=================
- Email sent by humans or robot spammers to tails-support-private@ aka. tails-bugs@
- Lots of spam
- Efficiency challenges don't apply
- No need for any semi-open relay setup
- Email sent by the WhisperBack app from Tails
- No spam
- Efficiency challenges apply
- Need some sort of semi-open relay setup
Step 1: Convert tails-support-private@ into a "normal" mailbox
====================================================================
## Migration process
We need to:
- #20221+
- #20222+
- #20223+
- #20224+
- #20225+
## Goals of this first iteration
This should solve the "spam filtering" problem.
This allows us to start experimenting with shared mailbox IMAP-based workflows for "track conversation" and "categorization".
This forces intrigeri to use some IMAP-enabled email client more, which can be a good preparation for the future (when we want to migrate the WhisperBack reports to this setup).
This doesn't allow much experimenting with the "efficiency" problem: the volume of emails on tails-support-private@ is small compared to tails-bugs@; and there's not much point in "grepping" or other form of advanced searching in human-written emails.
## Email client support requirements
We want this to work with the most common clients around us:
- Thunderbird is a must
- bonus points if it plays nicely with offlineimap+notmuch
- Roundcube webmail is NOT a must
(XXX: but would our workflow work, with the current rules?)
## Principles
### The shared mailbox is a database, not a discussion list
- if you want to reply to an individual human being or a team, put them in "To" or "Cc".
- If you want to add metadata to the machine, reply to the support mailbox + place the sent copy in INBOX.
- Optionally we can set up a SIEVE filter that moves to trash the email sent by this mailbox to itself so we don't have a 2nd copy of this message.
- If you want to reply to the Bug Reporter, do so.
### No broad categorization expected by default
E.g. "Persistent Storage", "Tor Connection", "hardware failure", etc.
Is it worth the effort to label every incoming report with 1 of these categories?
It might be if we could automate this server-side when receiving reports, but this won't work for WhisperBack messages, which are the ones where the benefit would be the biggest (they're in bigger number, and they contain log strings which are easier to match): they're encrypted so the server cannot parse them.
Let's not do that manually.
### Fine-grained categorization
The way we categorize reports, e.g. to annotate them with GitLab issue IDs, is primarily optimized for the efficiency of triaging: they should not spend time doing busywork that'll never be useful to anyone else.
This means that different triagers might add metadata differently, based on what they prefer: copying subjects on a pad, putting whisperback IDs on the issue, replying...
But categorization should be made accessible to non-triagers when they need it to do their job. E.g. if a developer commits to working on issue #XYZ, they should have a way to see reports that were identified, while triaging, as instances of #XYZ.
It's OK if this requires an extra step at the time someone actually commits to working on #XYZ, e.g. the triager will search for these reports and copy them to a dedicated folder, on demand.
## Server-side setup
### Convert the mailbox
The email mailbox we will be talking about in the whole section is a "regular" mailbox hosted on a trusted provider with a decent anti-spam setup.
### Anti-spam
Note: let's avoid confusion between WhisperBack "open" relay and spam problem.
There are two channels to send us spam:
1. directly to tails-support-private@
2. to Whisperback's open relay
While channel 2 is perfect for spammers, they don't seem to know: all of the spam we receive is sent to tails-support-private@; it does not go through WhisperBack nor its open relay, but it goes through Schleuder.
In this proposed setup, our support email address, that received this spam, is hosted at an email provider with decent anti-spam capabilities, and without Schleuder in the loop, so presumably most of the spam will be filtered server side and we will never see it.
### SIEVE filter
- server-side filter
- Condition (AND):
- From=tails-support-private@boum.org
- To=tails-support-private@boum.org
- Action: moves to trash
## Setup for anyone with access to the support mailbox
### Put replies (and forwarded messages) in the same folder of the message you are replying to
Under the Account Settings, _Copies & Folders_ , _Place replies in the folder of the message being replied to_.
### Don't mark messages as read automatically
That's not really required, but maybe you want to give it a try since the "Unread" flag is so important. Or at least, be super intentional about what state a message is in once you context switch out of it: only leave it as read if you're done processing it and nobody has to look at it again.
Thunderbird supports this with a global option.
## Workflow
detailed in https://gitlab.tails.boum.org/tails/summit/-/wikis/Teams/Foundations_Team/Bug_Triaging/workflow
Step 2: move WhisperBack reports to this shared mailbox
=======================================================
## Server-side setup
Solution to the WhisperBack "open" relay problem, relaying to a destination address hosted at a email provider that enforces modern standards: to send email, our server should authenticate to an SMTP account at whatever email provider + rewrite From to match that account. Keep accepting any incoming email with the expected destination address.
## Workflow
### Answering a bug reporter writing to Whisperback reports, if they come through a Schleuder mailing list
Assumption: tails-support-private@ is subscribed to the tails-bugs@ Schleuder mailing list.
- Reply to the bug reporter
- Mark the message as read
- We get 1 copy of the reply: the "sent" message
- We also get the copy message from schleuder
Slight problem: we get 2 copies.
This could be better handled by removing schleuder from the loop.
### Answering a bug reporter writing to Whisperback reports, if we replace the Schleuder instance running on tails-bugs@boum.org with some "forwarder"
(assuming they even specified an email address)
- Reply
- Press reply
- Fix the recipient getting the actual email address from the body.
- send your reply
- Mark the message as read
- We get 1 copy of the reply: the "sent" message
Optional follow-up steps
========================
## Auto-reply
It never really delivered what we were hoping for, because:
- We have no Help Desk anymore.
- The process for changing the contents of the auto-reply message is not smooth, so we don't point users to current "hot known issues" and their workaround.
- We never implemented replying to WhisperBack reports (when users provide an email address).
Technically, we could re-implement it as an IMAP client (inspiration: https://git.lattuga.net/boyska/imaptab).
Is it useful?
If we want to do that, then we want to actually improve it: the status quo is already not great. Specifically, we'd want to improve the process for changing the contents of the auto-reply. And perhaps make it support WhisperBack reports too.
If it fits in S11 or another funding opportunity, this could be nice.
We think it's a SHOULD that shall not block step 1 nor 2.Tails_6.2https://gitlab.tails.boum.org/tails/tails/-/issues/20187Close Tor Connection when the user clicks *Start Tor Browser*2024-02-07T17:59:37Zsajolidasajolida@pimienta.orgClose Tor Connection when the user clicks *Start Tor Browser*Credits: @segfault in https://gitlab.tails.boum.org/tails/tails/-/issues/19603#note_225818.
It would mitigate #19603 in this important scenario. After Tails connected to Tor, the *Tor Connection* window is a bit garbage and users would ...Credits: @segfault in https://gitlab.tails.boum.org/tails/tails/-/issues/19603#note_225818.
It would mitigate #19603 in this important scenario. After Tails connected to Tor, the *Tor Connection* window is a bit garbage and users would close it anyway.https://gitlab.tails.boum.org/tails/tails/-/issues/20184tps-frontend: consider adding UI for adding custom persistent features2024-03-04T11:27:31Zanonymtps-frontend: consider adding UI for adding custom persistent features10 years ago we rejected this in #5383 as part of a large security push for the persistence implementation in Tails 0.21. Other than that it is unclear to me why we do not allow this, although I've seen it explicitly mentioned without ex...10 years ago we rejected this in #5383 as part of a large security push for the persistence implementation in Tails 0.21. Other than that it is unclear to me why we do not allow this, although I've seen it explicitly mentioned without explanation, e.g. in #17803 there is: "This would be consistent with the fact we don't support adding [custom persistence features] from the UI".
So, are there good reasons for us not to do this now? After all, we can't anticipate all user needs on this front, and even if we could it would be impractical to include many more persistence features than we already do. I guess the most compelling one for me is that the average user wouldn't be able to identify which folder stores the settings/data/cache for their favorite application. But I still see value for it as an advanced feature we don't promote heavily.
Design/implementation considerations:
* The implementation should be using a file chooser
* What if the target is not a folder?
- If `tpsd` supports persisting regular files (the old `live-boot` persistence system did *not*) I guess we don't have to do extra work to disallow it
- Symlinks? Dereferencing seems like a bad idea, probably we just remove it and replace it with an empty folder (or file if we support that per the previous point).
* What about overlapping targets, when the chosen target is the same as another persistence feature's target, or one is contained in the other?
* While the old persistence feature didn't require the `source=` option `tpsd` does, but maybe we can make it as simple as: when making `$PATH` persistent, we add this line to `persistence.conf`: `$PATH source=custom/$PATH` which actually is what the old persistence system did when `source=` was omitted (but without the `custom/`-prefix). Overlapping targets need some handling here. Another option is: `$PATH source=$(uuidgen $PATH)`.
* Maybe we want a blacklist for problematic targets, e.g. `$HOME/.conf`: "too general", and similar?
* Maybe we should limit the file chooser to pick targets within `$HOME`? Otherwise we have to deal with problems like:
- What about problematic targets like `/`, `/dev`, `/etc`, `/home`? It would significantly increase the balcklist, as proposed above.
- What about permission issues for paths outside of `$HOME` vs the file chooser? Can a privileged file chooser "remain in" `tps-frontend` after it drops privileges?https://gitlab.tails.boum.org/tails/tails/-/issues/20180Adapt VeraCrypt automated test scenarios vs GNOME automounting2024-02-06T08:11:09ZanonymAdapt VeraCrypt automated test scenarios vs GNOME automountingSince enabling automounting (#15900) of encrypted media (#15767) GNOME will automatically try to unlock plugged VeraCrypt devices. So far we are basically working around that by just cancelling the prompt and using VeraCrypt mounter or G...Since enabling automounting (#15900) of encrypted media (#15767) GNOME will automatically try to unlock plugged VeraCrypt devices. So far we are basically working around that by just cancelling the prompt and using VeraCrypt mounter or GNOME disks (7e126bb9c9b59bb3b3a692d62312f9b32cd07e93) so we are not testing what users most likely will do, which is not good.
We should at least add VeraCrypt scenarios for using GNOME's automount prompt, maybe completely replacing the VeraCrypt scenarios patched in 7e126bb9c9b59bb3b3a692d62312f9b32cd07e93.
Details: https://gitlab.tails.boum.org/tails/tails/-/issues/20155#note_225490