Feature #15949

Possible to block/warn user from updating and/or installing packages which are modified by Tails devs?

Added by letthemeatpie 2018-09-13 10:28:34 . Updated 2019-06-02 15:19:23 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2018-09-13
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

As the ‘Additional Software’ feature gains use[1], shouldn’t there be an up to date list and method of protection/warning somewhere for important packages modified by the Tails devs which shouldn’t be touched? (because they would break something, function differently in Tails, and/or override Tails dev intents)

When a user attempts to +,, or update Tails sensitive packages, should they receive a warning and reason? (just as the user would if they tried to break their system by +,, or updating package(s) which modify/remove critical components of the DE/OS/etc.)

I’ve read the warnings across the web, both on ML and elsewhere about being careful of which packages you should mess with in Tails, but I believe this should grow into something more effective, to protect users rather than leaving them on their own to wreck their system, and possibly curtail extra bug reports which may stem from the users overriding critical Tails packages without their knowledge. Possibly leading devs to hammer out issues which could’ve been prevented - and would these users include the fact they modified critical files in their bug reports? Probably not.

[1] And a lot of people have been using package management manually anyway, prior to this feature.

Subtasks

History

#1 Updated by goupille 2018-10-16 10:52:57

  • Assignee set to intrigeri
  • Type of work changed from Discuss to Research

upgrading any package in tails seems a bad idea : the only supported way to do so is to upgrade to a new stable Tails…

I also assume that apt is preventing the user to upgrade some of the packages through pining priority.

that said, maybe having a clear sentence somewhere in the documentation saying that upgrading packages is not supported would be a good idea ?

#2 Updated by intrigeri 2018-10-16 12:56:30

  • Assignee changed from intrigeri to sajolida

From a doc PoV:

But the request here is about automation, not about documentation, so:

  • upgrading: it would probably not be that hard to warn the user when upgrading a package included in Tails
  • installing: we could certainly have a list of known-dangerous packages; here also, it should not be that hard to warn the user when installing those

sajolida, do you think this would be a worthy improvement wrt. UX?

#3 Updated by sajolida 2018-11-18 19:31:34

  • Assignee changed from sajolida to intrigeri
  • QA Check set to Info Needed

I would be an improvement of course but I don’t know if it would be worth it…

I think we should prevent upgrades (configure additional software for packages that are already in Tails), even silently:

  • When the user installs/upgrades a package that is already installed in Tails (eg. `tzdata` right now), Additional Software doesn’t prompt the user to add it to the list. So we’re good.
  • We do upgrade packages when the user manually adds such a package to /live/persistence/TailsData_unlocked/live-additional-software.conf or when we start including a package in Tails that some users already have in their Additional Software. We could fix this by:
    • Ignoring them from the list when installing/upgrading additional software, maybe even silently as a first implementation.
    • Removing them from the list, maybe with a prompt: “Hey, $package is already in Tails. You should remove it from your list of additional software. [Remove]”

Regarding possibly dangerous packages that are not included in Tails, this would mean maintaining a list of them. This might be costly and error prone to maintain. Also, not showing a warning when installing a dangerous package that we don’t have in our list yet might give people confidence that it’s fine to use.

So I’m not really sure what’s worth doing for this second case. What I could do is list the additional software I see in WhisperBack reports and see how dangerous are the packages that people install. I guess that through WhisperBack we should get as dangerous as can be :)

intrigeri: What do you think?

#4 Updated by intrigeri 2018-11-19 16:31:31

  • Assignee changed from intrigeri to sajolida

> I think we should prevent upgrades (configure additional software for packages that are already in Tails), even silently:

> * We do upgrade packages when the user manually adds such a package to /live/persistence/TailsData_unlocked/live-additional-software.conf or when we start including a package in Tails that some users already have in their Additional Software. We could fix this by:
> Ignoring them from the list when installing/upgrading additional software, maybe even silently as a first implementation.

Agreed if it’s cheap (it takes special effort and technical skills to shoot oneself in the foot like this and I’d rather focus our time on issues that affect more common use cases).
I guess this can be done quite cheaply.

Too bad, in the past I have used live-additional-software.conf ($package/$distro) to ensure I have the latest version of a package installed from sid ;)

> So I’m not really sure what’s worth doing for this second case. What I could do is list the additional software I see in WhisperBack reports and see how dangerous are the packages that people install. I guess that through WhisperBack we should get as dangerous as can be :)

> intrigeri: What do you think?

For now, I would say: let’s keep this in mind and incrementally build a list (on a blueprint?) of software we’ve seen users install via this feature, that’s either dangerous or breaks Tails functionality somehow because our code is not prepared for it. We’ll need help desk collaboration for this so they update the list when their analysis of a bug report shows that it’s caused by an incompatible additional package.

#5 Updated by sajolida 2019-01-15 11:33:39

  • blocks Feature #16080: Core work 2018Q4 → 2019Q2: User experience added

#6 Updated by mercedes508 2019-01-27 15:10:27

  • Status changed from New to Confirmed

#7 Updated by alant 2019-03-03 18:46:19

intrigeri wrote:
> > I think we should prevent upgrades (configure additional software for packages that are already in Tails), even silently:
>
> > * We do upgrade packages when the user manually adds such a package to /live/persistence/TailsData_unlocked/live-additional-software.conf or when we start including a package in Tails that some users already have in their Additional Software. We could fix this by:
> > Ignoring them from the list when installing/upgrading additional software, maybe even silently as a first implementation.
>
> Agreed if it’s cheap (it takes special effort and technical skills to shoot oneself in the foot like this and I’d rather focus our time on issues that affect more common use cases).
> I guess this can be done quite cheaply.
>
It can be done quite cheaply I think, but…

> Too bad, in the past I have used live-additional-software.conf ($package/$distro) to ensure I have the latest version of a package installed from sid ;)
>
…I also used this to install a package from backports, and I think this can be harmless, depending on the package. Adding to this that manualy editing the configuration file is geeky, I’m not sure this feature would have more benefits than drawbacks.

> > So I’m not really sure what’s worth doing for this second case. What I could do is list the additional software I see in WhisperBack reports and see how dangerous are the packages that people install. I guess that through WhisperBack we should get as dangerous as can be :)
>
> > intrigeri: What do you think?
>
> For now, I would say: let’s keep this in mind and incrementally build a list (on a blueprint?) of software we’ve seen users install via this feature, that’s either dangerous or breaks Tails functionality somehow because our code is not prepared for it. We’ll need help desk collaboration for this so they update the list when their analysis of a bug report shows that it’s caused by an incompatible additional package.

I agree with that. Implementing a warning or filtering a package from that list would be quite cheap, the question seems to be more about maintaining that list, as already mentionned.

#8 Updated by intrigeri 2019-06-02 15:19:23

  • Assignee deleted (sajolida)
  • QA Check deleted (Info Needed)

#9 Updated by sajolida 2019-06-03 17:12:58

  • blocked by deleted (Feature #16080: Core work 2018Q4 → 2019Q2: User experience)