While writing the documention, I found that "GPG user" was less confusing
terminology than "GPG key," since you aren't really adding a "key"
to git-crypt, and git-crypt already uses "key" to refer to other concepts
(cf. the -k/--key-name options).
* Change the wording for 'git-crypt lock'.
* Move 'git-crypt lock' to 'Common commands' section since it's
common to both GPG and symmetric mode.
* Reduce whitespace in the output so it fits in 80 characters.
This does the reverse of what git-crypt unlock does:
- unconfigures the git filters
- forcibly checks out HEAD version
Usage:
git crypt lock locks repo using the "default" key
git crypt lock -k NAME locks the repo, using unlocked key named NAME
git crypt lock --key-name=NAME
git crypt lock -a locks the repo, removing ALL unlocked keys
git crypt lock --all
Result is that you can now decrypt and then revert back to encrypted
form of files and vice versa.
Modified-by: Andrew Ayer <agwa@andrewayer.name>
* Make argv argument to lock() const.
* Minor whitespace/style fixes to conform to project conventions.
Signed-off-by: Andrew Ayer <agwa@andrewayer.name>
Since Git consults the checked-out .gitattributes instead of the
.gitattributes in effect at the time the file was committed, Git
may invoke the smudge filter on old versions of a file that were
committed without encryption.
Instead of using umask to ensure sensitive files are created with
restrictive permissions, git-crypt now does:
create_protected_file(filename);
std::ofstream out(filename);
// ...
create_protected_file can have different Unix and Windows implementations.
create_protected_file should be easier to implement on Windows than a
umask equivalent, and this pattern keeps the amount of platform-specific
code to a minimum and avoids #ifdefs.
Git-crypt's position has always been that authentication is best left
to Git, since 1) Git provides immutable history based on SHA-1 hashes
as well as GPG-signed commits and tags, and 2) git-crypt can't be used
safely anyways unless the overall integrity of your repository is assured.
But, since git-crypt already has easy access to a (truncated) HMAC of the
file when decrypting, there's really no reason why git-crypt shouldn't
just verify it and provide an additional layer of protection.
This will allow the use of different crypto libraries in the future.
Modified-by: Andrew Ayer <agwa@andrewayer.name>
* Don't include openssl/err.h from git-crypt.cpp
* Fix whitespace and other style to conform to project conventions
* Remove unnecessary operators from Aes_ctr_encryptor
* Rename crypto_init to init_crypto, for consistency with init_std_streams()
