Convert Figma logo to code with AI

AGWA logogit-crypt

Transparent file encryption in git

8,204
476
8,204
134
View on GitHub

Top Related Projects

getsops's avatar

sops

16,722

Simple and flexible tool for managing secrets

sobolevn's avatar

git-secret

3,705

:busts_in_silhouette: A bash-tool to store your private data inside a git repository.

StackExchange's avatar

blackbox

6,680

Safely store secrets in Git/Mercurial/Subversion

Quick Overview

Git-crypt is a transparent file encryption tool for Git repositories. It allows you to encrypt sensitive files within a Git repository while still allowing the repository to function normally for those with the decryption keys. This enables secure storage of secrets and sensitive data alongside your code.

Pros

  • Seamless integration with Git workflows
  • Transparent encryption/decryption process
  • Supports multiple users with different keys
  • Works with any Git hosting service (GitHub, GitLab, etc.)

Cons

  • Requires manual key management
  • Limited to symmetric encryption
  • Can be challenging to set up initially
  • Not suitable for very large files or high-security environments

Getting Started

  1. Install git-crypt:

    # On macOS with Homebrew
brew install git-crypt

# On Ubuntu/Debian
sudo apt-get install git-crypt

  2. Initialize git-crypt in your repository:

    cd your-repo
git-crypt init

  3. Create a .gitattributes file to specify which files to encrypt:

    echo "sensitive-file.txt filter=git-crypt diff=git-crypt" >> .gitattributes
git add .gitattributes

  4. Add and commit files as usual. Specified files will be encrypted automatically:

    git add sensitive-file.txt
git commit -m "Add sensitive file (encrypted)"

  5. To give others access, export a key and share it securely:

    git-crypt export-key /path/to/key-file

  6. Others can then unlock the repository using the key:

    git-crypt unlock /path/to/key-file

Competitor Comparisons

getsops logo

sops

16,722

Simple and flexible tool for managing secrets

Pros of sops

  • Supports multiple encryption methods (PGP, AWS KMS, GCP KMS, Azure Key Vault)
  • Allows partial file encryption, keeping structure visible
  • Integrates well with various cloud platforms and services

Cons of sops

  • More complex setup and usage compared to git-crypt
  • Requires external key management services for some features
  • May have a steeper learning curve for beginners

Code Comparison

git-crypt:

git-crypt init
git-crypt add-gpg-user USER_ID
git-crypt lock/unlock

sops:

sops -e -i secrets.yaml
sops -d secrets.yaml
sops --encrypt --gcp-kms projects/project/locations/global/keyRings/keyring/cryptoKeys/key secrets.yaml

git-crypt focuses on seamless Git integration and simplicity, while sops offers more flexibility and cloud service integration. git-crypt encrypts entire files, whereas sops can encrypt specific values within structured data. sops is better suited for complex, multi-cloud environments, while git-crypt excels in straightforward Git-based workflows with GPG encryption.

sobolevn logo

git-secret

3,705

:busts_in_silhouette: A bash-tool to store your private data inside a git repository.

Pros of git-secret

  • Uses GPG for encryption, allowing for easier key management and multiple user support
  • Provides a separate file for tracking encrypted files (.gitsecret/paths/mapping.cfg)
  • Offers a more modular approach, with separate commands for different operations

Cons of git-secret

  • Requires manual tracking of files to be encrypted
  • Slightly more complex setup process compared to git-crypt
  • Less seamless integration with Git workflows

Code Comparison

git-secret:

git secret init
git secret tell user@example.com
git secret add sensitive_file.txt
git secret hide

git-crypt:

git-crypt init
git-crypt add-gpg-user user@example.com
git add sensitive_file.txt
git commit -m "Add sensitive file"

Key Differences

  • git-secret requires explicit commands to add and hide files, while git-crypt integrates more seamlessly with standard Git commands
  • git-crypt automatically encrypts tracked files on commit, whereas git-secret requires a separate 'hide' step
  • git-secret stores encrypted files with a .secret extension, while git-crypt stores them in their original format

Both tools provide effective means of encrypting sensitive files in Git repositories, with git-crypt offering a more streamlined experience and git-secret providing more granular control over the encryption process.

StackExchange logo

blackbox

6,680

Safely store secrets in Git/Mercurial/Subversion

Pros of Blackbox

  • Supports multiple encryption tools (GPG, OpenSSL)
  • Allows for easier collaboration with multiple users
  • Provides a simple command-line interface for managing secrets

Cons of Blackbox

  • Requires manual encryption/decryption of files
  • Less seamless integration with Git workflows
  • May have a steeper learning curve for new users

Code Comparison

Blackbox:

blackbox_edit_start secret.txt
# Edit the file
blackbox_edit_end secret.txt

git-crypt:

git-crypt init
echo "secret.txt filter=git-crypt diff=git-crypt" >> .gitattributes
git add secret.txt .gitattributes
git commit -m "Add encrypted file"

Both tools aim to solve the problem of securely storing sensitive information in Git repositories. git-crypt offers a more transparent encryption process, automatically encrypting files based on .gitattributes. Blackbox requires manual encryption and decryption but provides more flexibility in terms of encryption tools and user management.

git-crypt integrates more seamlessly with Git workflows, while Blackbox offers a wider range of features and better support for team collaboration. The choice between the two depends on specific project requirements, team size, and desired level of integration with Git.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

git-crypt - transparent file encryption in git

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.md 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.7.0, released on 2022-04-21. 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 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 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