The two most common reasons that `mvt-ios decrypt-backup` can fail are
wrong passwords and not pointing to an actual backup.
We can distinguish these cases based on the kinds of errors thrown
from iOSbackup (at least for the current versions that i'm testing
with).
When we encounter those particular exceptions, just report a simple
summary and don't overwhelm the user with a backtrace. If we
encounter an unexpected exception, leave the reporting as-is.
Closes: #28, #36
If file_path has any whitespace or shell metacharacters in it, then
the invocation of subprocess.call would be likely to break (or even
accidentally execute code, depending on how perverse the pathnames
are).
It's generally a good plan to avoid shell=True for subprocess.call
where you can lay out the arguments deliberately in python. This one
looks relatively straightforward (but note, i have not tested it,
sorry!)
Note that if a name has a `"` character in it, we still fail, out of
safety reasons.
in particular, we want to avoid command injection into the sqlite
binary with particularly malicious names that look something like the
following:
```
foo.db"; .shell touch should-not-exist; .nullvalue "
```
Specifying the password on the command line with `--password XXX`
leaves the password itself visible to any process on the machine which
can scan the process table.
On some systems (including common GNU/Linux distributions) this
visibility is possible by default.
This change should make it possible to offer the password without
putting it into the process table; rather, the user puts the password
in the environment, and specifies the name of the environment
variable, like so:
```
$ export MVT_IOS_BACKUP_PASSWORD=WronglySconeRoundnessUnruffled
$ mvt-ios decrypt-backup -d /path/to/dest /path/to/data/XXXXXXXX-YYYYYYYYYYYYYYY/
$ unset MVT_IOS_BACKUP_PASSWORD
```
or you can do so using a prefixed env var, as described in the updated
check.md documentation.