fscrypt.git/actions/recovery_test.go, branch v0.3.5 Go tool for managing Linux filesystem encryption Stop using deprecated package io/ioutil 2022-12-04T22:07:39+00:00 Eric Biggers ebiggers@google.com 2022-12-04T21:27:43+00:00 02875cef9010633b6689cfd1e2ceec9107b756b4 Since Go 1.16 (which recently became the minimum supported Go version for this project), the package io/ioutil is deprecated in favor of equivalent functionality in the io and os packages. staticcheck warns about this. Address all the warnings by switching to the non-deprecated replacement functions. 
Since Go 1.16 (which recently became the minimum supported Go version
for this project), the package io/ioutil is deprecated in favor of
equivalent functionality in the io and os packages.  staticcheck warns
about this.  Address all the warnings by switching to the non-deprecated
replacement functions.
Adjust recovery passphrase generation 2021-10-05T22:30:30+00:00 Eric Biggers ebiggers@google.com 2021-09-14T21:12:39+00:00 7fed63a84963cbd790e86a0e59ff14724bcf33c4 As per the feedback at https://github.com/google/fscrypt/issues/115 where users didn't understand that the recovery passphrase is important, restore the original behavior where recovery passphrase generation happens automatically without a prompt. This applies to the case where 'fscrypt encrypt' is using a login protector on a non-root filesystem. However, leave the --no-recovery option so that the recovery passphrase can still be disabled if the user really wants to. Also, clarify the information provided about the recovery passphrase. Update https://github.com/google/fscrypt/issues/115 
As per the feedback at https://github.com/google/fscrypt/issues/115
where users didn't understand that the recovery passphrase is important,
restore the original behavior where recovery passphrase generation
happens automatically without a prompt.  This applies to the case where
'fscrypt encrypt' is using a login protector on a non-root filesystem.

However, leave the --no-recovery option so that the recovery passphrase
can still be disabled if the user really wants to.  Also, clarify the
information provided about the recovery passphrase.

Update https://github.com/google/fscrypt/issues/115
Automatically generate recovery passphrase when useful 2020-01-23T03:05:06+00:00 Eric Biggers ebiggers@google.com 2019-11-27T20:04:13+00:00 8cd1b3ba2e7a12cd68e2dfd0cbb5ec09ff92783b If a user re-installs their system (or otherwise loses the /.fscrypt directory on the root filesystem) they also lose access to any login passphrase-protected directories on other filesystems, unless additional protectors were manually added. This can be unexpected, as it may be expected that the old login passphrase would still work. We can't really fix this by storing a login protector on every filesystem because: - If a user were to have N login protectors, it would take them N times longer to log in, as every login protector would need to be unlocked. - If a user were to change their login passphrase while any external volumes were unmounted, login protectors would get out of sync. - It's preferable that an external volume isn't unlockable by itself using only a login passphrase, as login passphrases are often weak. Instead, generate a recovery passphrase when creating a login passphrase-protected directory on a non-root filesystem. The recovery passphrase is added as a custom_passphrase protector, thus giving the policy two protectors: one pam_passphrase and one custom_passphrase. Then this passphrase is written to a file in the new encrypted directory. Writing the passphrase to a file here is okay since it's encrypted, but it's obviously useless by itself; it's up to the user to store this passphrase somewhere else if they need it. Use a recovery passphrase instead of a "recovery code" that encodes the policy key directly because a passphrase is more user-friendly: it can safely be made much shorter than a key, and it works just like any other fscrypt protector. Also, it's not as critical to allow recovery when the .fscrypt directory on the *same* filesystem is deleted. Resolves https://github.com/google/fscrypt/issues/164 
If a user re-installs their system (or otherwise loses the /.fscrypt
directory on the root filesystem) they also lose access to any login
passphrase-protected directories on other filesystems, unless additional
protectors were manually added.  This can be unexpected, as it may be
expected that the old login passphrase would still work.

We can't really fix this by storing a login protector on every
filesystem because:

- If a user were to have N login protectors, it would take them N times
  longer to log in, as every login protector would need to be unlocked.

- If a user were to change their login passphrase while any external
  volumes were unmounted, login protectors would get out of sync.

- It's preferable that an external volume isn't unlockable by itself
  using only a login passphrase, as login passphrases are often weak.

Instead, generate a recovery passphrase when creating a login
passphrase-protected directory on a non-root filesystem.

The recovery passphrase is added as a custom_passphrase protector, thus
giving the policy two protectors: one pam_passphrase and one
custom_passphrase.  Then this passphrase is written to a file in the new
encrypted directory.  Writing the passphrase to a file here is okay
since it's encrypted, but it's obviously useless by itself; it's up to
the user to store this passphrase somewhere else if they need it.

Use a recovery passphrase instead of a "recovery code" that encodes the
policy key directly because a passphrase is more user-friendly: it can
safely be made much shorter than a key, and it works just like any other
fscrypt protector.  Also, it's not as critical to allow recovery when
the .fscrypt directory on the *same* filesystem is deleted.

Resolves https://github.com/google/fscrypt/issues/164