The discussion centers on whether Claude Code's 'Don't Ask Again' feature is at fault for leaking secrets into public repositories or if the issue stems entirely from user negligence in committing local settings files. Conversely, defenders argue that manual review is fundamentally unsustainable at scale and that the industry must shift toward automated approval or robust sandboxing despite current flaws.
429 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4AGWA
git-crypt
C++2013–2026
AGWA / git-crypt
git-crypt
Transparent file encryption in git
38Distinct people
42Mentions
0Explicit recommenders
10KGitHub stars
What to know before exploring
What it is
Transparent file encryption in git
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- getsops/sops · linked in 4 of the same discussions
- elasticdog/transcrypt · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.
Mentions over time
HN mentions by year42 dated mentions
Observed mentions: 2013-02-06 22:09:18 UTC to 2026-03-27 21:29:25 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
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.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
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
#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
Read the full README on GitHubWhat Hacker News says
42 sourcesI've not tried this, however
https://github.com/AGWA/git-crypt
Apparently someone has developed something similar to this
In If you don't opt out by Apr 24 GitHub will train on your private reposI’ve been using git-crypt⁽¹⁾ which is transparent (you put the patterns you want to encrypt in .gitattributes) and lets you use GPG keys or symmetric keys. And it's been around for quite a while.
⁽¹⁾https://github.com/AGWA/git-crypt
In Show HN: Lockenv – Simple encrypted secrets storage for GitGit-crypt is a dead product with numerous unresolved issues and drawbacks.
Newer versions of git cause git to crash when invoking git-crypt[0].
It doesn’t scale with users: Off-boarding a key is a commit in git. Since it is trivially easy to rewind a git repo before the revocation commit and then decrypt with the revoked key, this means you need to rotate every key under management when any revoke is performed.
It provides the illusion of asymmetric key encryption, but your asymmetric key wraps a shared symmetric key used to encrypt the entire repository. This also means a user could roll the repository back before a key was revoked and steal the symmetric key used to protect the repository and then use that key to decrypt the repository any time in the future.
It doesn’t scale with the number of files under management. As a result of how
Read the rest
it’s implemented, every invocation is a separate process launch. This means every file triggers an asymmetric unwrap of the symmetric key. If you’re protecting your GPG key with hardware keyfob, decrypting the repository will take a long time.
This product seemed like a cool idea for a while but it’s implementation leave much to be desired and has not stood the test of time…
Password-store[1] does a better job than git-crypt for single user git based gpg encrypted password management.
For multi-user git repo encryption I prefer Mozilla SOPS[2], especially when coupled with something like AWS KMS…
But then you might consider stepping up to something like Hashicorp Vault[3] or Infisical[4].
[0] https://github.com/AGWA/git-crypt/issues/273
[1] https://www.passwordstore.org/
[2] https://github.com/getsops/sops
[3] https://www.vaultproject.io/
[4] https://infisical.com/
DMNO creator here - sensitive config values are able to be retrieved from a variety of backends using a flexible plugin system. We are certainly not telling you that you have to use the encrypted file method, and depending on the security requirements of your project it may not be a good choice. You can also mix and match those plugins, and segment items however you see fit - so it's not always a single key being passed around.
That said, it is a valid way that some folks use (see
https://dotenvx.com/, https://github.com/AGWA/git-crypt, https://github.com/getsops/sops) which can make sense for simpler projects with less stringent security needs. The bonus here is it does not require setting up, paying for, or integrating any external service, and helps save you from "secret sprawl".
We have a plugin for 1password (which many teams are alr
Read the rest
eady using anyway) and have plugins planned for many other popular tools, including Infisical.
Many other tools only really make sense for bigger enterprises, either due to cost, complexity, or both. Our goal here (or one of them anyway) is to make a tool that provides enough value to use in all cases, from very small and simple to very large and complex.
There are varying degrees to this but I'll focus on the early stage, low effort approaches I've found work.
For an easy, slightly hacky version I've used git-crypt (https://github.com/AGWA/git-crypt) with tiny teams. You'll need to share the decryption key (e.g. via 1password shared vaults).
As your need for security grows (but you're still not working with a giant team) you're better off using non-committed .env files locally (with need-to-be-shared dev keys stored in shared vaults in 1password) and prod GCP/AWS secrets managers remotely.
Once you work with a bigger team you'll need to start minting API keys limited in scope to each individual, for them to work with locally. The prod keys will only live in the remote environment, managed by some kind of secret manager offered by the platform and will need to be rotated frequently.
In Ask HN: What tools should I use to manage secrets from env files?Years ago, before going full on Vault, I was using git-crypt, a git plugin that uses gpg to encrypt files before committing them to the repo.
Not sure if it’s still fine, I see their last release is 2 years old nowadays.
https://github.com/AGWA/git-crypt
In Ask HN: How do you share and sync .env files and secrets with your teamThese?
[0] https://github.com/AGWA/git-crypt
[1] https://github.com/getsops/sops
In Age is a simple, modern and secure file encryption tool, format, and Go libraryI’ve used git-crypt[0] with great success. It uses git smudge so you never commit secrets if you set it up properly the first time.
Unfortunately, it doesn’t support groups.
For a solution that scales to teams, check out SOPS[1]. You have to do a little more work to be sure that secrets are ignored in the repo but it works reasonably well and is well known.
Transparent support at the editor level (age.el) sounds really nice though.
[0] https://github.com/AGWA/git-crypt
[1] https://github.com/getsops/sops
In Age is a simple, modern and secure file encryption tool, format, and Go library> The only non-theoretical use of a PGP encryption key [that would use keys published on a keyserver] is email.
I use this on some repos
https://github.com/AGWA/git-crypt
And occasionally to encrypt files, or receive encrypted files.
These are practical things which are non-theoretical.
> Using multiple keys don't offer added security or secrecy.
Depends on how careful you are or want to be, with your private key. My house key isn't the same as my car key isn't the same as my bike key.
> This is nothing like data harvesting
Alright fair, bad example. What I was grumbling about was more the lack of any clear communication that you've been auto-opted-in to a feature on protonmail, with no user interface signal indicating so, leading to confusion for a couple months like in TFA. I definitely wasn't casting shade on the opengpg keyserver,
Read the rest
nor protonmail. It's the "hey! I didn't check a box for this, and it's not mentioned anywhere in the protonmail docs" hidden functionality which could do with some clarification.
I'm a forgetful creature. If I intentionally put my key on a keyserver, because I'm playing around and learning about PGP, will I make the connection between it and protonmail a few months down the line if I move my email account to them? Unlikely.
It's a nice automated feature. Protonmail-to-protonmail e2e encryption makes a lot of sense. I just think protonmail-to-non-protonmail e2e needs a tooltip in the UI, and the option to opt out, potentially with the ability to opt out for specific email addresses. I wouldn't at all assume it would be on by default even IF I've been actively using PGP in my email clients, because it's something you usually have to manually set up yourself, very explicitly. That, and 99.9% of emails are plaintext.
Anyhoo, one thing I forgot which kind of negates the "what if I have multiple encryption keys tied to my email" is the fact that the opengpg keyserver does tie 1 email address to 1 key so you can't publish multiple encryption keys, fair enough. Git-crypt and file encryption, I set my associated email address to use +tags eg me+git@email.com, so as far as protonmail etc are concerned there's only one key per logical email address.
It's not a problem. Here you go: https://github.com/AGWA/git-crypt
In The Twelve-Factor App (2011)You can use something like git-crypt[0] to e2e encrypt it.
[0]: https://github.com/AGWA/git-crypt
In Joplin – An open-source note taking and to-do application with synchronisationHow about encryption?
https://github.com/AGWA/git-crypt has been solid for me
In GitHub Private Repos Considered Private-IshI hesitate to append this but one option I have seen thrown around and also debated is git-crypt [1] Here [2] is a discussion on HN about git-crypt. There are many caveats to doing this as any integrations that would need to read the file contents would also need to be able to decrypt the files so this may not be entirely useful and may add many levels of complexity and fragility. In theory one could encrypt specific files and then check them into any of the cloud hosted git repositories but anything that needs to read the contents of the file will need a mechanism to decrypt them automatically. That thread also mentions transcrypt [3]
If doing this I would strongly recommend also having a local non-encrypted weekly snapshot of your files in the event that nobody is able to decrypt your committed files.
[1] - https://github.com/AGWA/gi
Read the rest
There are a number of possible solutions:
git-remote-gcrypt: https://github.com/spwhitton/git-remote-gcrypt
git-crypt: https://github.com/AGWA/git-crypt
git-secret: https://github.com/sobolevn/git-secret
However, most people who self-host their Git repository are fine with just transport-level encryption (TLS).
In Using GNU Stow to manage your dotfiles (2012)Git-crypt: Transparent file encryption in Git
2 points · Open discussionShowing the 15 most recent of 42 sources. Enable JavaScript to search and browse every indexed mention.