git-crypt 0.5.0
git-crypt 0.5.0 brings a substantial performance boost to 'git-crypt
unlock' and 'git-crypt lock' under Git 1.8.5 and higher. The improvement
should be particularly noticeable in repositories with lots of files.
In addition, there are some minor bug fixes and usability improvements.
'git-crypt gpg-add-user' now has a --trusted option which you can use
to force the addition of a user even if GPG doesn't trust the key.
Finally, git-crypt now has a man page! To install it, pass ENABLE_MAN=yes
to 'make' and 'make install' (this will be the default once I iron out
the build system).
See the NEWS file, or the Git commit history, for a more detailed list
of changes.
Rename HAS_DOCBOOK option to ENABLE_MAN.
Allow xsltproc to fetch the Docbook stylesheet from the Internet if it's
not installed locally. This will hopefully make it easier for folks
to build the man page.
Previously, lock/unlock needed to spawn a separate `git check-attr`
process for every single file in the repository (whether encrypted
or not). This was extremely inefficient, especially on Windows.
Now, git-crypt spawns a single `git check-attr` process and communicates
with it over stdin. In a repository with thousands of files, this
results in a speedup of nearly 100x.
This relies on the --stdin and -z options to `git check-attr`, which
were only added in Git 1.8.5 (released 27 Nov 2013). With older versions
of Git, git-crypt falls back to the old and slower code.
This will be useful as we start to gate code on the version of Git that's installed.
A lot of code out in the wild seems to assume that the output of `git version`
is "git version $VERSION", so I'm assuming it's safe for git-crypt to rely
on that too.
If this option is specified, then the GPG users are added even
if their keys are not trusted by GPG.
In addition, if a full fingerprint, prefixed by 0x, is specified,
it is assumed to be trusted, regardless of its trust level in the
GPG trustdb.
When the with-fingerprint option is enabled, the gpg command invoked by
git-crypt to look up a GPG user ID returns a fingerprint for both primary
keys and sub-keys. Previously, this misled git-crypt into thinking that
the user ID matched more than one public key. Now, git-crypt ignores
fingerprints for sub-keys.
Non-files (symlinks and gitlinks (used by sub-modules)) cannot be
encrypted, so we shouldn't try messing with them. This fixes `git-crypt
status` when used on a repository with sub-modules or symlinks when the
path to the sub-module or symlink has the git-crypt attribute (which
can happen inadvertently when using wildcards in .gitattributes).
It will force a lock even if working directory is unclean. Useful
for deconfiguring git-crypt if you've accidentally unlocked with the
wrong key or gotten into a similarly sticky situation.
This will let us run 'git lock' even if no filters are configured.
This logic is more complicated than I would like because running
'git config --remove-section' on a non-existent section results in
a noisy error (with text printed to stderr and an exit code of 128)
instead of a quiet error like the other 'git config' commands.
git-crypt 0.4.2
git-crypt 0.4.2 is a bugfix-only release that fixes the unlock (and lock)
commands under Git 2.2.2 and newer. Due to an optimization introduced in
Git 2.2.2, 'git-crypt unlock' would not decrypt files in the working tree.
In addition, this version of git-crypt officially drops support for
versions of Git older than 1.7.2.
Previously, git-crypt claimed to support Git as old as 1.6.0 (albeit
with degraded operation). However, this has not been true for some time,
since Git 1.6.0 does not support the --porcelain option to `git status`.
Since Git 1.7.2 was the first version of Git to support filters with
`git blame`, was released almost five years ago (in July 2010), and is
even in Debian Squeeze, it seems like a good minimum version to require.
Starting with Git 2.2.2, `git checkout -f HEAD` no longer checks out
files if their mtimes haven't changed. This causes files to remain
encrypted in the work tree after running `git-crypt unlock`, and to
remain decrypted after running `git-crypt lock`'.
To fix this, git-crypt now figures out what files are encrypted (by
checking `git check-attr` on every file output by `git ls-files`),
touches those files, and then runs `git checkout` on them.
