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.
Move Unix-specific code to util-unix.cpp, and place Windows equivalents
in util-win32.cpp. Most of the Windows functions are just stubs at
the moment, and we need a build system that works on Windows.
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.
