mirror of
https://github.com/AGWA/git-crypt.git
synced 2025-12-12 07:40:32 -08:00
Remove plaintext README and NEWS files
It's easier to just have the markdown files. Fixes: #274
This commit is contained in:
79
NEWS
79
NEWS
@@ -1,79 +0,0 @@
|
||||
v0.8.0 (2025-09-23)
|
||||
* Remove OpenSSL 1.0 support, fix compilation with OpenSSL 3.
|
||||
* Avoid use of problematic short GPG key IDs.
|
||||
|
||||
v0.7.0 (2022-04-21)
|
||||
* Avoid "argument list too long" errors on macOS.
|
||||
* Fix handling of "-" arguments.
|
||||
* Minor documentation improvements.
|
||||
|
||||
v0.6.0 (2017-11-26)
|
||||
* Add support for OpenSSL 1.1 (still works with OpenSSL 1.0).
|
||||
* Switch to C++11 (gcc 4.9 or higher now required to build).
|
||||
* Allow GPG to fail on some keys (makes unlock work better if there are
|
||||
multiple keys that can unlock the repo but only some are available).
|
||||
* Allow the repo state directory to be configured with the
|
||||
git-crypt.repoStateDir git config option.
|
||||
* Respect the gpg.program git config option.
|
||||
* Don't hard code path to git-crypt in .git/config on Linux (ensures
|
||||
repo continues to work if git-crypt is moved).
|
||||
* Ensure git-crypt's gpg files won't be treated as text by Git.
|
||||
* Minor improvements to build system, documentation.
|
||||
|
||||
v0.5.0 (2015-05-30)
|
||||
* Drastically speed up lock/unlock when used with Git 1.8.5 or newer.
|
||||
* Add git-crypt(1) man page (pass ENABLE_MAN=yes to make to build).
|
||||
* Add --trusted option to 'git-crypt gpg-add-user' to add user even if
|
||||
GPG doesn't trust user's key.
|
||||
* Improve 'git-crypt lock' usability, add --force option.
|
||||
* Ignore symlinks and other non-files when running 'git-crypt status'.
|
||||
* Fix compilation on old versions of Mac OS X.
|
||||
* Fix GPG mode when with-fingerprint enabled in gpg.conf.
|
||||
* Minor bug fixes and improvements to help/error messages.
|
||||
|
||||
v0.4.2 (2015-01-31)
|
||||
* Fix unlock and lock under Git 2.2.2 and higher.
|
||||
* Drop support for versions of Git older than 1.7.2.
|
||||
* Minor improvements to some help/error messages.
|
||||
|
||||
v0.4.1 (2015-01-08)
|
||||
* Important usability fix to ensure that the .git-crypt directory
|
||||
can't be encrypted by accident (see RELEASE_NOTES-0.4.1.md for
|
||||
more information).
|
||||
|
||||
v0.4 (2014-11-16)
|
||||
(See RELEASE_NOTES-0.4.md for important details.)
|
||||
* Add optional GPG support: GPG can be used to share the repository
|
||||
between one or more users in lieu of sharing a secret key.
|
||||
* New workflow: the symmetric key is now stored inside the .git
|
||||
directory. Although backwards compatibility has been preserved
|
||||
with repositories created by old versions of git-crypt, the
|
||||
commands for setting up a repository have changed. See the
|
||||
release notes file for details.
|
||||
* Multiple key support: it's now possible to encrypt different parts
|
||||
of a repository with different keys.
|
||||
* Initial 'git-crypt status' command to report which files are
|
||||
encrypted and to fix problems that are detected.
|
||||
* Numerous usability, documentation, and error reporting improvements.
|
||||
* Major internal code improvements that will make future development
|
||||
easier.
|
||||
* Initial experimental Windows support.
|
||||
|
||||
v0.3 (2013-04-05)
|
||||
* Fix 'git-crypt init' on newer versions of Git. Previously,
|
||||
encrypted files were not being automatically decrypted after
|
||||
running 'git-crypt init' with recent versions of Git.
|
||||
* Allow 'git-crypt init' to be run even if the working tree contains
|
||||
untracked files.
|
||||
* 'git-crypt init' now properly escapes arguments to the filter
|
||||
commands it configures, allowing both the path to git-crypt and the
|
||||
path to the key file to contain arbitrary characters such as spaces.
|
||||
|
||||
v0.2 (2013-01-25)
|
||||
* Numerous improvements to 'git-crypt init' usability.
|
||||
* Fix gitattributes example in README: the old example showed a colon
|
||||
after the filename where there shouldn't be one.
|
||||
* Various build fixes and improvements.
|
||||
|
||||
v0.1 (2012-11-29)
|
||||
* Initial release.
|
||||
160
README
160
README
@@ -1,160 +0,0 @@
|
||||
ABOUT GIT-CRYPT
|
||||
|
||||
git-crypt enables transparent encryption and decryption of files in a
|
||||
git repository. Files which you choose to protect are encrypted when
|
||||
committed, and decrypted when checked out. git-crypt lets you freely
|
||||
share a repository containing a mix of public and private content.
|
||||
git-crypt gracefully degrades, so developers without the secret key can
|
||||
still clone and commit to a repository with encrypted files. This lets
|
||||
you store your secret material (such as keys or passwords) in the same
|
||||
repository as your code, without requiring you to lock down your entire
|
||||
repository.
|
||||
|
||||
git-crypt was written by Andrew Ayer <agwa@andrewayer.name>. For more
|
||||
information, see <https://www.agwa.name/projects/git-crypt>.
|
||||
|
||||
|
||||
BUILDING GIT-CRYPT
|
||||
|
||||
See the INSTALL file.
|
||||
|
||||
|
||||
USING GIT-CRYPT
|
||||
|
||||
Configure a repository to use git-crypt:
|
||||
|
||||
$ cd repo
|
||||
$ git-crypt init
|
||||
|
||||
Specify files to encrypt by creating a .gitattributes file:
|
||||
|
||||
secretfile filter=git-crypt diff=git-crypt
|
||||
*.key filter=git-crypt diff=git-crypt
|
||||
secretdir/** filter=git-crypt diff=git-crypt
|
||||
|
||||
Like a .gitignore file, it can match wildcards and should be checked into
|
||||
the repository. See below for more information about .gitattributes.
|
||||
Make sure you don't accidentally encrypt the .gitattributes file itself
|
||||
(or other git files like .gitignore or .gitmodules). Make sure your
|
||||
.gitattributes rules are in place *before* you add sensitive files, or
|
||||
those files won't be encrypted!
|
||||
|
||||
Share the repository with others (or with yourself) using GPG:
|
||||
|
||||
$ git-crypt add-gpg-user USER_ID
|
||||
|
||||
USER_ID can be a key ID, a full fingerprint, an email address, or anything
|
||||
else that uniquely identifies a public key to GPG (see "HOW TO SPECIFY
|
||||
A USER ID" in the gpg man page). Note: `git-crypt add-gpg-user` will
|
||||
add and commit a GPG-encrypted key file in the .git-crypt directory of
|
||||
the root of your repository.
|
||||
|
||||
Alternatively, you can export a symmetric secret key, which you must
|
||||
securely convey to collaborators (GPG is not required, and no files
|
||||
are added to your repository):
|
||||
|
||||
$ git-crypt export-key /path/to/key
|
||||
|
||||
After cloning a repository with encrypted files, unlock with GPG:
|
||||
|
||||
$ git-crypt unlock
|
||||
|
||||
Or with a symmetric key:
|
||||
|
||||
$ git-crypt unlock /path/to/key
|
||||
|
||||
That's all you need to do - after git-crypt is set up (either with
|
||||
`git-crypt init` or `git-crypt unlock`), you can use git normally -
|
||||
encryption and decryption happen transparently.
|
||||
|
||||
|
||||
CURRENT STATUS
|
||||
|
||||
The latest version of git-crypt is 0.8.0, released on 2025-09-23.
|
||||
git-crypt aims to be bug-free and reliable, meaning it shouldn't
|
||||
crash, malfunction, or expose your confidential data. However,
|
||||
it has not yet reached maturity, meaning it is not as documented,
|
||||
featureful, or easy-to-use as it should be. Additionally, there may be
|
||||
backwards-incompatible changes introduced before version 1.0.
|
||||
|
||||
|
||||
SECURITY
|
||||
|
||||
git-crypt is more secure than other transparent git encryption systems.
|
||||
git-crypt encrypts files using AES-256 in CTR mode with a synthetic IV
|
||||
derived from the SHA-1 HMAC of the file. This mode of operation is
|
||||
provably semantically secure under deterministic chosen-plaintext attack.
|
||||
That means that although the encryption is deterministic (which is
|
||||
required so git can distinguish when a file has and hasn't changed),
|
||||
it leaks no information beyond whether two files are identical or not.
|
||||
Other proposals for transparent git encryption use ECB or CBC with a
|
||||
fixed IV. These systems are not semantically secure and leak information.
|
||||
|
||||
|
||||
LIMITATIONS
|
||||
|
||||
git-crypt relies on git filters, which were not designed with encryption
|
||||
in mind. As such, git-crypt is not the best tool for encrypting most or
|
||||
all of the files in a repository. Where git-crypt really shines is where
|
||||
most of your repository is public, but you have a few files (perhaps
|
||||
private keys named *.key, or a file with API credentials) which you
|
||||
need to encrypt. For encrypting an entire repository, consider using a
|
||||
system like git-remote-gcrypt <https://spwhitton.name/tech/code/git-remote-gcrypt/>
|
||||
instead. (Note: no endorsement is made of git-remote-gcrypt's security.)
|
||||
|
||||
git-crypt does not encrypt file names, commit messages, symlink targets,
|
||||
gitlinks, or other metadata.
|
||||
|
||||
git-crypt does not hide when a file does or doesn't change, the length
|
||||
of a file, or the fact that two files are identical (see "Security"
|
||||
section above).
|
||||
|
||||
git-crypt does not support revoking access to an encrypted repository
|
||||
which was previously granted. This applies to both multi-user GPG
|
||||
mode (there's no del-gpg-user command to complement add-gpg-user)
|
||||
and also symmetric key mode (there's no support for rotating the key).
|
||||
This is because it is an inherently complex problem in the context
|
||||
of historical data. For example, even if a key was rotated at one
|
||||
point in history, a user having the previous key can still access
|
||||
previous repository history. This problem is discussed in more detail in
|
||||
<https://github.com/AGWA/git-crypt/issues/47>.
|
||||
|
||||
Files encrypted with git-crypt are not compressible. Even the smallest
|
||||
change to an encrypted file requires git to store the entire changed file,
|
||||
instead of just a delta.
|
||||
|
||||
Although git-crypt protects individual file contents with a SHA-1
|
||||
HMAC, git-crypt cannot be used securely unless the entire repository is
|
||||
protected against tampering (an attacker who can mutate your repository
|
||||
can alter your .gitattributes file to disable encryption). If necessary,
|
||||
use git features such as signed tags instead of relying solely on
|
||||
git-crypt for integrity.
|
||||
|
||||
Files encrypted with git-crypt cannot be patched with git-apply, unless
|
||||
the patch itself is encrypted. To generate an encrypted patch, use `git
|
||||
diff --no-textconv --binary`. Alternatively, you can apply a plaintext
|
||||
patch outside of git using the patch command.
|
||||
|
||||
git-crypt does not work reliably with some third-party git GUIs, such
|
||||
as Atlassian SourceTree <https://jira.atlassian.com/browse/SRCTREE-2511>
|
||||
and GitHub for Mac. Files might be left in an unencrypted state.
|
||||
|
||||
|
||||
GITATTRIBUTES FILE
|
||||
|
||||
The .gitattributes file is documented in the gitattributes(5) man page.
|
||||
The file pattern format is the same as the one used by .gitignore,
|
||||
as documented in the gitignore(5) man page, with the exception that
|
||||
specifying merely a directory (e.g. `/dir/`) is NOT sufficient to
|
||||
encrypt all files beneath it.
|
||||
|
||||
Also note that the pattern `dir/*` does not match files under
|
||||
sub-directories of dir/. To encrypt an entire sub-tree dir/, use `dir/**`:
|
||||
|
||||
dir/** filter=git-crypt diff=git-crypt
|
||||
|
||||
The .gitattributes file must not be encrypted, so make sure wildcards don't
|
||||
match it accidentally. If necessary, you can exclude .gitattributes from
|
||||
encryption like this:
|
||||
|
||||
.gitattributes !filter !diff
|
||||
Reference in New Issue
Block a user