GitLab

... and disable it by default.

This allows us to avoid showing the "Settings were loaded" notification
on the first boot after configuring the persistent volume.

This will not be required anymore once #11529 is done, i.e. settings are
persisted immediately after configuring the persistent volume.

... even on the first boot after creating the Persistent Storage, which
should not actually load any settings (see the comment in the code
explaining why this happened).

To fix the case that setting files are not created at all if they don't
exist in the persistent settings dir.

Turns out there was actually a good reason to have those, because we
only want to add additional settings if the loaded value is not the
default value and if they haven't been added before.

Also fixes a bug which caused the "Settings loaded" infobar to not be
shown if only region settings were loaded (the LocalizationSettingUI.load()
implementation did not return True if a setting was loaded).

Also, use shlex.quote() instead of the deprecated pipes.quote(). See
https://docs.python.org/2/library/pipes.html#pipes.quote

... so that we can detect when the hashed password becomes incompatible
with the PAM config (in case that the hash function used by PAM
changes).

We want to be able to persist the password file, so we can't delete it.
And since the password is now hashed and salted, we don't have to delete
it anymore.

Now that settings can be loaded from persistence, it's possible that a
setting's popover is opened without the add-setting-dialog ever being
created.

Settings are now saved to file immediately when the user changes them,
instead of before login. Beside making the code simpler, this makes it
easier to handle saving the admin password file (which we want to delete
if the user disabled the feature after loading a persistent password
file, but want to overwrite or leave untouched in other cases).

By calling chpasswd with the -e option, it uses the provided hashed and
salted password instead of hashing and salting it via PAM.

PAM uses SHA512 to hash the password, as configured in /etc/login.defs,
so in the call to mkpasswd we set --method=sha512crypt to also use SHA512.

We never call unlock() with the callback arguments, so lets remove them.

Instead of always calling update_value_label() after apply(), call it
inside apply().

This is a preparation for loading the settings in the Greeter when
persistence is unlocked.

We require to unlock the persistence via the "Unlock" button, to ensure
that the user gets some UI feedback when the persistent Greeter settings
are loaded.

The "Start Tails" is now insensitive if a password was entered in the
persistence password entry but persistence was not unlocked.

To make it easier to persist all of these settings.

Setting that env var does not seem to work.

KISS your nested list comprehensions goodbye! :)

I doesn't seem enough to wait for udev to settle after partprobe. See
this trace:

  [...]
  + MTOOLS_SKIP_CHECK=1 mlabel -i "${SYSTEM_PARTITION}" -n ::Tails
  init :: could not read boot sector
  Cannot initialize '::'
  mlabel: Cannot initialize drive

Perhaps it would be enough to just call the `settle` function I just
added only before `mlabel`, but who knows where a similar issue will
appear next kernel upgrade? It's cheap to spam it, so why not?

Respectively: Lithuanian, Malay, Thai.

Since upgrading Linux 5.4 → 5.6 (or 5.5) or udev 241-7~deb10u3 →
241-7~deb10u4 we need this, else the system partition isn't available
for the dd operation below, which then fails.