* 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()
Storing the key name in the key file makes it unnecessary to pass the
--key-name option to git-crypt unlock.
This breaks compatibility with post-revamp keys. On the plus side,
keys are now extensible so in the future it will be easier to make
changes to the format without breaking compatibility.
This will help distinguish keys encrypted with GPG from keys encrypted by
other means. (For example, a future version of git-crypt might support
passphrase-encrypted keys.)
The init, export-key, add-collab, and unlock commands now
take an optional -k (equivalently, --key-name) option to
specify an alternative key. Files can be encrypted with
the alternative key by specifying the git-crypt-KEYNAME filter
in .gitattributes. Alternative key support makes it possible
to encrypt different files with different keys.
Note that the -k option to unlock is temporary. Unlock
will eventually auto-detect the name of the key you're
unlocking, either by looking in the symmetric key file,
or by scanning the .git-crypt/keys directory.
Note that the layout of the .git/git-crypt and .git-crypt
directories has changed as follows:
* .git/git-crypt/key is now .git/git-crypt/keys/default
* .git-crypt/keys is now .git-crypt/keys/default
'git-crypt status' tells you which files are and aren't encrypted and
detects other problems with your git-crypt setup.
'git-crypt status -f' can be used to re-stage files that were incorrectly
staged unencrypted.
The UI needs work, and it needs to also output the overall repository
status (such as, is git-crypt even configured yet?), but this is a
good start.
