In b2afce5c79, the db filename is
wrapped in double-quotes when passing it to the sqlite3 tool's
`.clone` helper command.
For parsing safety, we avoid performing this cleanup if the filename
itself has a double-quote character in it. Otherwise, a malformed
filename could lead to arbitrary injection into the sqlite3 command.
In be24680046, the sqlite3 wrapping
changes to single-quotes. Either the safety check should be amended
to block pathnames with single-quotes, or the sqlite3 wrapping should
revert to double-quotes.
I opted for the latter here because i think single-quotes are more
likely than double-quotes to show up in pathnames (e.g. a folder named
"Daniel's files"), but either change would be fine, of course.
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 "
```
