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).

The settings are now split into different files.

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.

Fix importing OpenPGP keys from GNOME Files

See merge request !15

On !15, inadvertently, e6053152 + reverting it
somehow made us lose some an important improvement to this documented
workaround: namely, recommending users import keys via GNOME Files, rather than
on the command line. Given the only benefit of !15 is precisely to make
"import OpenPGP keys via GNOME Files" work, let's use this in our doc :)

refs: #17183