Run 'git-crypt add-collab KEYID' to authorize the holder of the given
GPG secret key to access the encrypted files. The secret git-crypt key
will be encrypted with the corresponding GPG public key and stored in the
root of the Git repository under .git-crypt/keys.
After cloning a repo with encrypted files, run 'git-crypt unlock'
(with no arguments) to use a secret key in your GPG keyring to unlock
the repository.
Multiple collaborators are supported, however commands to list the
collaborators ('git-crypt ls-collabs') and to remove a collaborator
('git-crypt rm-collab') are not yet supported.
The active key is now stored in .git/git-crypt/key instead of being
stored outside the repo. This will facilitate GPG support, where the
user may never interact directly with a key file. It's also more
convenient, because it means you don't have to keep the key file
around in a fixed location (which can't be moved without breaking
git-crypt).
'git-crypt init' now takes no arguments and is used only when initializing
git-crypt for the very first time. It generates a brand-new key, so
there's no longer a separate keygen step.
To export the key (for conveyance to another system or to a collaborator),
run 'git-crypt export-key FILENAME'.
To decrypt an existing repo using an exported key, run 'git-crypt unlock
KEYFILE'. After running unlock, you can delete the key file you passed
to unlock.
Key files now use a new format that supports key versioning (which will
facilitate secure revocation in the future).
I've made these changes as backwards-compatible as possible. Repos
already configured with git-crypt will continue to work without changes.
However, 'git-crypt unlock' expects a new format key. You can use
the 'git-crypt migrate-key KEYFILE' command to migrate old keys to the
new format.
Note that old repos won't be able to use the new commands, like
export-key, or the future GPG support. To migrate an old repo, migrate
its key file and then unlock the repo using the unlock command, as
described above.
While making these changes, I cleaned up the code significantly, adding
better error handling and improving robustness.
Next up: GPG support.
Rationale:
* /dev/random blocks unpredictably on Linux, leading to slow
key generation.
* OpenSSL's RNG is more cross-platform than /dev/(u)random.
Some platforms might not have a (u)random device, or worse,
have a /dev/(u)random that produces insecure random numbers
(like Cygwin, apparently).
* Display message asking user to move the mouse, etc. to generate more
entropy.
* Disable buffering on the fstream so we don't read more randomness
than we have to.
* Refuse to overwrite an existing key file.
At some point between Git 1.7.1 and Git 1.8.1.3, both 'git reset' and
'git status' stopped noticing that files were modified after their
smudge filter changed. Consequentially, 'git reset --hard HEAD' would
not decrypt existing encrypted files in the repo.
This commit changes 'git-crypt init' to use 'git checkout -f HEAD
/top/of/repo' instead, which does the job.
Untracked files are not touched by git reset, so git-crypt init
is safe even with untracked files present.
This relies on the -u option to git-status, which was added in Git
1.6.0, which was released in 2008. Add Git 1.6.0 as a requirement in
the README.
* Correctly check for existence of HEAD (use 'git rev-parse' instead
of 'git show-ref'). Fixes bug where hard reset might be skipped
after running 'git init'.
* Don't require working directory to be clean if HEAD doesn't exist.
(If HEAD doesn't exist, we won't be hard resetting so the working
directory doesn't need to be clean.)
* Overwrite existing git config values (instead of --add'ing them) so
'git-crypt init' can be idempotent.
* In the error message for a disrty working directory, advise user to
commit changes or 'git stash' them.
Even though arpa/inet.h is "networky" and this isn't a network
application, arpa/inet.h is in POSIX whereas endian.h is non-standard.
This should let git-crypt build on Mac OS X.
Although glibc's implementation of mkstemp creates temporary files with
a safe (i.e. 0600) mode, POSIX does not mandate any particular mode. So
to ensure maximum cross-platform safety, we must set a umask of 0077
before calling mkstemp.
