| Age | Commit message (Collapse) | Author |
|
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
|
|
Update https://github.com/google/fscrypt/issues/220
|
|
ErrBadOwners:
Rename to ErrDirectoryNotOwned for clarity, move it from
cmd/fscrypt/ to metadata/ where it better belongs, and improve
the message.
ErrEncrypted:
Rename to ErrAlreadyEncrypted for clarity, and include the path.
ErrNotEncrypted:
Include the path.
ErrBadEncryptionOptions:
Include the path and bad options.
ErrEncryptionNotSupported:
ErrEncryptionNotEnabled:
Don't wrap with "get encryption policy %s", in preparation for
wrapping these with filesystem-level context instead.
Also avoid mixing together the error handling for the "get policy" and
"set policy" ioctls. Make it very clear how we're handling the errors
from each ioctl.
|
|
ErrProtectorName:
Rename to ErrLoginProtectorName for clarity, and include the
name and user.
ErrMissingProtectorName:
Include the correct protector source.
ErrDuplicateName:
Rename to ErrProtectorNameExists for clarity, and remove a level
of wrapping by including the name directly.
ErrDuplicateUID:
Rename to ErrLoginProtectorExists for clarity, and remove a
level of wrapping by including the user directly.
|
|
Test encrypting a directory using a login (pam_passphrase) protector.
|