changing all references of std::auto_ptr to std::unique_ptr and changing the implementation of get_directory_contents() to use readdir, which is now reentrant, instead of readdir_r.
Signed-off-by: Andrew Ayer <agwa@andrewayer.name>
Note: old implementations or readdir might not be re-entrant, but that's OK
because git-crypt is not multi-threaded.
If multiple GPG keys exist that could be used to decrypt the repository
key, but GPG fails on one of them (e.g., the first one because it is
stored on a SmartCard that is not plugged in), then no other keys are
used to try to decrypt it, failing entirely instead of trying the
additional GPG keys.
Modified-by: Andrew Ayer <agwa@andrewayer.name>
* Make exception variable const
* Make whitespace conform to project conventions
Signed-off-by: Andrew Ayer <agwa@andrewayer.name>
Closes: #88
There's a tradeoff. When the path is hardcoded, it's guaranteed that
git-crypt will be found no matter where you run git or what your $PATH is.
On the other hand, hardcoding means that things break if git-crypt changes
location, which could easily happen if you copy a repository to a different system
(see https://github.com/AGWA/git-crypt/issues/71 for example).
In hindsight, I think this was a bad tradeoff. Now, if git-crypt is
invoked as a bare filename (no slashes), the bare filename is placed
in .git/config under the assumption that it can be found via $PATH
(this assumption will be true as long as git-crypt wasn't resolved via
a relative path in $PATH). This logic was already being used on
non-Linux OSes and it seemed to work fine.
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).
