Since the git-crypt mailing lists have barely been used, and mailing
lists seem to be falling out of fashion for open source projects, I've
decided to shut down the git-crypt mailing lists in favor of functionality
provided by GitHub.
For announcements of new releases, you can watch the git-crypt
repository (https://github.com/AGWA/git-crypt) for new releases.
For bug reports, you can file an issue:
https://github.com/AGWA/git-crypt/issues
For discussions, you can use GitHub's new discussions feature:
https://github.com/AGWA/git-crypt/discussions
This allows the following command to work properly:
git-crypt export-key -
Previously, you had to run this command, because - was being interpreted
as an option argument:
git-crypt export-key -- -
gitattributes now supports '**' to mean 'entire subtree'.
Using '*' instead of '**' is an easy mistake to make with pretty
bad consequences. Hopefully this added emphasis will make
it less likely users make the mistake.
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.
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.
