Remove plaintext README and NEWS files

It's easier to just have the markdown files.

Fixes: #274
This commit is contained in:
Andrew Ayer
2025-09-24 09:05:56 -04:00
parent 2322f618e1
commit dd1b1f4e2a
2 changed files with 0 additions and 239 deletions

79
NEWS
View File

@@ -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
View File

@@ -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