| Age | Commit message (Collapse) | Author |
|---|
|
v2 encryption policies are now recommended, due to various security and
usability advantages over v1 policies. Many people have been running
into the usability problems with v1, so it's desirable to get people
onto v2 without having to manually opt-in.
Therefore, when 'fscrypt setup' creates /etc/fscrypt.conf, enable
policy_version 2 automatically if the kernel supports it.
I decided to go with this solution over the policy_version "auto" I
suggested originally because this way is simpler, it can still be
changed to "auto" later if desired, and "auto" might require changing
how we parse the config file (since currently the config file is mapped
directly to a protobuf where policy_version is an 'int' and is shared
with EncryptionOptions).
Resolves https://github.com/google/fscrypt/issues/182
|
|
There's no real need to allow users to choose the key description prefix
(a.k.a. the "service"), since on ext4 and f2fs we can just use "ext4"
and "f2fs" for compatibility with all kernels both old and new, and on
other filesystems we can just use "fscrypt". So, let's do that.
Since this removes the point of the "--legacy" option to 'fscrypt setup'
and the "compatibility" field in /etc/fscrypt.conf, remove those too.
Specifically, we start ignoring the "compatibility" in existing config
files and not writing it to new ones. The corresponding protobuf field
number and name are reserved. We stop accepting the "--legacy" option
at all, although since it was default true and there was no real reason
for anyone to change it to false, probably no one will notice. If
anyone does, they should just stop specifying the option.
Note that this change only affects user keyrings and thus only affects
v1 encryption policies, which are deprecated in favor of v2 anyway.
|
|
When 'fscrypt setup' sees that /etc/fscrypt.conf doesn't exist, don't
ask for confirmation before creating it. Just do it. This is the
normal use, and there's not a good reason to ask the user to confirm it.
|
|
Make the global setup command also create the metadata directory at
/.fscrypt, since that's where login protectors are placed, even when the
actual encrypted directories are on a different filesystem.
Resolves https://github.com/google/fscrypt/issues/129
|
|
These were found by a combination of manual review and a custom script
that checks for common errors.
Also removed an outdated sentence from the comment for setupBefore().
|
|
The --user flag can now be used to have the targe user (the one whose
keyring and password will be used in fscrypt) be different than the
calling user. Very usefull for things like
sudo fscrypt purge /media/joerichey/usb --user=joerichey
which will now have privileges to drop caches, but will properly clear
the keys from the user's keyring.
|
|
This commit changes all the internal import paths from `fscrypt/foo` to
`github.com/google/fscrypt/foo` so that it can be built once we release
externaly. The documentation in README.md is updated accordingly.
Also, the README has a note noting that we do not make any guarantees
about project stability before 1.0 (when it ships with Ubuntu).
Change-Id: I6ba86e442c74057c8a06ba32a42e17f94833e280
|
|
This commit adds in the framework for adding commands and subcommands to
the fscrypt tool. This commit adds in the "setup", "encrypt", and
"unlock" commands. Additional information can be found by running:
fscrypt <command> --help.
This commit defines how flags are parsed and errors are handled. It also
creates an extensible framework for prompting the user for information.
Change-Id: I159d7f44ee2b2bbc5e072f0802850e082d9a13ce
|
