Poor scriptability due to --name not being easily checkable

[nh2]

I'm scripting the creation of some encrypted ext4 folders by calling the fscrypt CLI.

While most of the CLI seems designed for scriptability (prompts can be overridden by passing the information with CLI arguments), an unresolved pain point seems to be key names:

• Using fscrypt metadata create protector as described here, or using fscrypt encrypt, requires passing --name.
• Passing an existing name give error there is already a protector named "myname".
• But there is no way to programmatically query existing key names.

The only workaround seems to be parsing the output of fscrypt status /, which does not look very stable at all.

The bash completion currently does that in this ugly parsing hack:

fscrypt/cmd/fscrypt/fscrypt_bash_completion

Lines 86 to 94 in 9770081

	# Output list of possible policy or protector IDs
	# $1: the mount point on which policies are looked for.
	# $2: the section (policy or protector) to retrieve
	_fscrypt_status_section()
	{
	local section=${2^^}
	fscrypt status "$1" 2>/dev/null | \
	command awk '/^[[:xdigit:]]{16}/ && section == "'"$section"'" { print $1; next; }
	{ section = $1 }'

---

Other parts of fscrypt provide programmatic queries of whether something already exists, e.g. to check whether a dir is already encrypted one can check the status code of fscrypt status, which as per --help

will fail if PATH is not setup for encryption with fscrypt

---

Some ideas to improve scriptability:

• Add a way to check if a key name is already taken.
  • Or add e.g. a --json flag that turns all output into JSON, similar to how Hashicorp tools like consul provide it.
    There's the request for Stable library API #175 but things as simple as key creation should be possible also from the command line.
• Make fscrypt metadata create protector succeed instead of fail if the key name already exists AND the given --source raw_key --key is the same as the one already stored (that is, make it idempotent), or add a flag to get that behaviour.

[nh2]

Another scripting pain point:

fscrypt unlock fails if already unlocked, and provides no way to check if it is.

So one has to resort to brittle stderr parsing for automatic unlocking:

LANG=C fscrypt unlock mydir/ --key secret.key 2>&1 >/dev/null | grep "already unlocked"

if one still wants other unlocking errors to manifest as exit codes.

[jamesps-ebi]

fscrypt unlock fails if already unlocked, and provides no way to check if it is.

+1 for some form of lock/unlock check. Being able to determine if a folder is locked or unlocked would be essential for using fscrypt in more complex scripts.