Feature #6786

Be consistent when checking if persistence is enabled in tails-additional-software

Added by anonym 2014-02-27 01:59:19 . Updated 2020-03-23 20:55:53 .

Status:
In Progress
Priority:
Low
Assignee:
Category:
Persistence
Target version:
Start date:
2014-02-27
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
1
Affected tool:
Additional Software Packages
Deliverable for:

Description

Currently it checks whether /live/persistence/TailsData_unlocked exists, which works, but it’s inconsistent with how we check it in other places. See e.g. how it’s done in persistence_is_enabled() of config/chroot_local-includes/usr/local/lib/tails-shell-library/tails_greeter.sh.

This is definitely something for the Tails python library (Feature #6452).

Subtasks

Related issues

Related to Tails - Feature #6452: Factor out stuff into a Tails Python library Confirmed 2013-11-29
Related to Tails - Feature #14568: Additional Software Packages Resolved 2013-12-11 2018-06-26

History

#1 Updated by anonym 2014-02-27 02:07:37

  • Description updated

#2 Updated by intrigeri 2014-07-19 18:11:57

  • Category changed from 196 to Persistence

#3 Updated by intrigeri 2016-02-18 10:19:35

  • Affected tool set to Additional Software Packages

#4 Updated by Anonymous 2018-01-18 16:58:18

#5 Updated by alant 2018-07-27 22:10:12

  • Status changed from Confirmed to In Progress
  • Assignee changed from alant to anonym
  • QA Check changed from Dev Needed to Info Needed

This is now done in function has_unlocked_persistence of submodules/pythonlib/tailslib/persistence.py.

It checks for /live/persistence/TailsData_unlocked which means the persistence is actually unlocked, which looks better to me than checking if persistence has been enabled in the greeter (/var/lib/live/config/tails.persistence has TAILS_PERSISTENCE_ENABLED) which is what config/chroot_local-includes/usr/local/lib/tails-shell-library/tails-greeter.sh does.

#6 Updated by Anonymous 2018-08-07 14:30:03

  • Assignee changed from anonym to alant

@alant: I’m unsure what kind of info you need on this ticket. And it is very unlikely you’ll get that info from anonym. Please reassign this to intrigeri for review and/or further instructions who could review it. Thank you.

#7 Updated by alant 2018-08-09 20:26:34

  • Assignee changed from alant to intrigeri

u wrote:
> @alant: I’m unsure what kind of info you need on this ticket. And it is very unlikely you’ll get that info from anonym. Please reassign this to intrigeri for review and/or further instructions who could review it. Thank you.

This is a 4 years old ticket, asking:

- to do the check in the python library -> done
- to do the same check as in the greeter shell library -> I don’t think it’s a good idea, see my previous comment. But I may miss something. What do you think?

#8 Updated by intrigeri 2018-08-10 07:42:40

  • Assignee changed from intrigeri to alant

alant wrote:
> It checks for /live/persistence/TailsData_unlocked which means the persistence is actually unlocked, which looks better to me than checking if persistence has been enabled in the greeter (/var/lib/live/config/tails.persistence has TAILS_PERSISTENCE_ENABLED) which is what config/chroot_local-includes/usr/local/lib/tails-shell-library/tails-greeter.sh does.

Why does it look better to you?

#9 Updated by intrigeri 2019-06-02 15:28:43

  • QA Check deleted (Info Needed)

#10 Updated by intrigeri 2019-09-13 05:08:50

Thinking about it again, I can see pros & cons to both implementations. But IMO we should have one implementation, whichever it is: especially after Feature #16935 is done, it’ll feel awkward to have two competing implementations. So what about this:

  1. Add whatever code is needed in the Python version to support all our shell use cases (see git grep persistence_is_enabled).
  2. Make the persistence_is_enabled* shell functions call the Python code.
  3. Profit :)

?

#11 Updated by alant 2020-03-23 20:55:37

intrigeri wrote:
> Thinking about it again, I can see pros & cons to both implementations. But IMO we should have one implementation, whichever it is: especially after Feature #16935 is done, it’ll feel awkward to have two competing implementations. So what about this:
>
> # Add whatever code is needed in the Python version to support all our shell use cases (see git grep persistence_is_enabled).
> # Make the persistence_is_enabled* shell functions call the Python code.
> # Profit :)
>
> ?

From ASP point of view it looks great!

#12 Updated by alant 2020-03-23 20:55:54

  • Assignee deleted (alant)