This looks very useful. I’ve been using git-remote-gcrypt for a long while but I’ve encountered issues and need a replacement as it no longer works for me. agebox looks like it could be what I need. The issues I’ve run into with gcrypt are:
More importantly, signing with SSH keys isn’t supported. Due to the pain of managing things in GPG I switched to ssh key based git signing as soon as it was widely available.
Update: I tried agebox but immediately hit an issue because my ~/.ssh is a symlink. I worked around that, then hit the same behaviour described in this issue from 2022 https://github.com/slok/agebox/issues/181 So, the search for a gcrypt replacement continues.
I personally don’t feel comfortable publishing secrets publicly in encrypted form. I don’t have strong reasons against doing so to provide for you. My reasoning mostly comes down to not trusting encryption as infallible and defense in depth.
Same. This is somewhat normalized in the NixOS community and drives me a bit nuts.
Encrypted secrets are only secure to the degree that cracking them is prohibitively expensive. Presently even RSA 1024 keys are still too hard to brute force. Unless Quantum has a big breakthrough, or more likely their’s an algorithmic weakness in the current tooling, I doubt we’ll see currently encrypted secrets be broken in 15-20 years
I use sops based secrets for my NixOS machines and have the secret files in a public repo. The level of comfort in that for me is mostly rooted in how quickly can I rotate secrets in the situation that I do end up making a mistake, which is extremely easy with age so it does not worry me too much.
I do also have an older repository that uses git-crypt which I haven’t migrated mostly out of laziness, and that I keep private because of the aforementioned key rotation problem which I personally find to be a complicated process with PGP.
It’s not any different to e.g. typing passwords/bank details into a website protected by TLS, where ciphertexts are not considered secret due to the possibility of eavesdropping.
Yes it is. In the TLS use case the attacker has to be in a privileged position in the network, at the right time. If you publish your git-crypt files, the attacker can be anyone, globally, and they can at any time decide to make a backup of your repo on a whim, just in case the crypto gets broken in 25 years or so.
… Just in case your key is leaked later somehow (eg exploit that can read ram, or file+keylogger).
Morever, say you publish encrypted secret at some point, then you can no longer effectively rotate any decryption key you think may have been compromised in the entire history of your project, and project membership (new junior dev X did what with their private key file?!) - someone might have a copy of the file encrypted with a (now) compromised key.
Offline attacks 25 years later don’t matter if the secrets in question are being rotated every “24 hours”, and the outer envelope key is also rotated regularly.
The TLS example is a pretty good analogue in the sense that every session has a different key. If we can get closer to that, here, you’re doing pretty good.
Where the TLS analogue breaks down is that the plaintext of the captured sessions might still be useful 25 years later. Encrypting secrets used to gain access to systems that have data, are much less likely to be useful 25 years later.
In my case I was storing secrets in git that could not be easily rotated. If you want easy rotation then git is not a good choice :-) I saw it as a stop-gap in the absence of a platform that could provide something like Hashicorp Vault.
A significant concern for me was whether the decryption keys might leak, the risks of staff turnover, things like that. WRT my other comment on this thread with proper separation of secrets and metadata it might even be possible that devs never need the decryption keys, which could reduce these worries a lot. But I never managed to get that far, and in most cases I would recommend spending the effort on a proper credential store instead.
I’m not a fan of tools that automatically decrypt secrets in my working copy. I prefer it if secrets are decrypted only when necessary, so that my working copy is normally a clean match to what is pushed to the repository server.
To make it easier to avoid decrypting secrets I found it helps to keep exactly one secret and nothing else in each encrypted file. Any metadata about the secret (eg, URLs, usernames, comments) goes in a separate cleartext file alongside the encrypted secret file. This setup means there’s no need to look at or edit a secret, it’s just a random blob, and your eyeballs or text editor can’t do anything useful with it. There are existing tools that mix secrets and metadata in one file which makes it hard to follow this rule strictly in all cases, but it mostly works well.
I’m well over a decade into having all my secrets in git-crypt. I sync, backup, and use my password manager databases, API tokens, and all the other juicy bits via git crypt in many repositories. I’d do it all over again in a heart beat,
That being said I only strongly recommend this tooling to folks who have and have to use PGP already. If you already have keys and have to handle them anyway, this is a great way to leverage them. If you don’t then maybe stay away from it if you can. PGP is awful. There isn’t an obvious successor yet and probably never will be for all the use cases, but there are some good entries in the space, especially for more specialized use cases. Hold off and/or experiment with some of the new encryption options unless you want to be having “fun” with PGP keys in another decade.
The git-crypt project itself is pretty solid as it stands, but at the same time is on the verge of being unmaintained. The original developer hasn’t been very active, has not passed the buck to anyone that could run with it, and weight hasn’t gathered around a fork yet.
I guess I can plug our open-source git-based secrets management solution here, which is made of command-line tool (for managing secrets) and an api that integrates directly into your application (for retrieving them dynamically at runtime). It’s a KISS secrets management system approach that eschews having servers to provide secrets to your projects at runtime; the implementation is standardized and has been ported to different languages and frameworks.
The approach is meant to be dependency-free and flexible in terms of how you deploy secrets into dev/staging/prod environments; we’ve seen people using it in creative ways.
“The Ansible [vault] based solution has worked … but … I have a nasty habit of leaving the file decrypted”
The “edit” feature on Ansible vault really prevents me from accidentally doing this. Granted - I don’t do a ton of this type work - but with my Ansible vault workflow there’s never a moment when the file is decrypted except when I’m working on exactly this file.
Since I find it difficult to wrap my head around PGP, I rely on agebox, which uses age as the name implies.
Thank you, I was hoping someone might post an alternative approach that doesn’t use PGP.
Neat! Sadly doesn’t seem to support plugin based keys, eg for yubikeys
This looks very useful. I’ve been using git-remote-gcrypt for a long while but I’ve encountered issues and need a replacement as it no longer works for me. agebox looks like it could be what I need. The issues I’ve run into with gcrypt are:
Update: I tried agebox but immediately hit an issue because my
~/.sshis a symlink. I worked around that, then hit the same behaviour described in this issue from 2022 https://github.com/slok/agebox/issues/181 So, the search for a gcrypt replacement continues.Considered doing something similar with the same use case of public git repo for infra, but with age instead of git-crypt.
Even knowing that the files are encrypted, it just feels wrong to post them publicly on GitHub.
Do other people feel the same? Is more people doing this? Good reasons in favor or against?
I personally don’t feel comfortable publishing secrets publicly in encrypted form. I don’t have strong reasons against doing so to provide for you. My reasoning mostly comes down to not trusting encryption as infallible and defense in depth.
Same. This is somewhat normalized in the NixOS community and drives me a bit nuts.
Encrypted secrets are only secure to the degree that cracking them is prohibitively expensive. Presently even RSA 1024 keys are still too hard to brute force. Unless Quantum has a big breakthrough, or more likely their’s an algorithmic weakness in the current tooling, I doubt we’ll see currently encrypted secrets be broken in 15-20 years
I use sops based secrets for my NixOS machines and have the secret files in a public repo. The level of comfort in that for me is mostly rooted in how quickly can I rotate secrets in the situation that I do end up making a mistake, which is extremely easy with age so it does not worry me too much.
I do also have an older repository that uses git-crypt which I haven’t migrated mostly out of laziness, and that I keep private because of the aforementioned key rotation problem which I personally find to be a complicated process with PGP.
It’s not any different to e.g. typing passwords/bank details into a website protected by TLS, where ciphertexts are not considered secret due to the possibility of eavesdropping.
Yes it is. In the TLS use case the attacker has to be in a privileged position in the network, at the right time. If you publish your
git-cryptfiles, the attacker can be anyone, globally, and they can at any time decide to make a backup of your repo on a whim, just in case the crypto gets broken in 25 years or so.… Just in case your key is leaked later somehow (eg exploit that can read ram, or file+keylogger).
Morever, say you publish encrypted secret at some point, then you can no longer effectively rotate any decryption key you think may have been compromised in the entire history of your project, and project membership (new junior dev X did what with their private key file?!) - someone might have a copy of the file encrypted with a (now) compromised key.
Offline attacks 25 years later don’t matter if the secrets in question are being rotated every “24 hours”, and the outer envelope key is also rotated regularly.
The TLS example is a pretty good analogue in the sense that every session has a different key. If we can get closer to that, here, you’re doing pretty good.
Where the TLS analogue breaks down is that the plaintext of the captured sessions might still be useful 25 years later. Encrypting secrets used to gain access to systems that have data, are much less likely to be useful 25 years later.
In my case I was storing secrets in git that could not be easily rotated. If you want easy rotation then git is not a good choice :-) I saw it as a stop-gap in the absence of a platform that could provide something like Hashicorp Vault.
A significant concern for me was whether the decryption keys might leak, the risks of staff turnover, things like that. WRT my other comment on this thread with proper separation of secrets and metadata it might even be possible that devs never need the decryption keys, which could reduce these worries a lot. But I never managed to get that far, and in most cases I would recommend spending the effort on a proper credential store instead.
I’m not a fan of tools that automatically decrypt secrets in my working copy. I prefer it if secrets are decrypted only when necessary, so that my working copy is normally a clean match to what is pushed to the repository server.
To make it easier to avoid decrypting secrets I found it helps to keep exactly one secret and nothing else in each encrypted file. Any metadata about the secret (eg, URLs, usernames, comments) goes in a separate cleartext file alongside the encrypted secret file. This setup means there’s no need to look at or edit a secret, it’s just a random blob, and your eyeballs or text editor can’t do anything useful with it. There are existing tools that mix secrets and metadata in one file which makes it hard to follow this rule strictly in all cases, but it mostly works well.
I’m well over a decade into having all my secrets in git-crypt. I sync, backup, and use my password manager databases, API tokens, and all the other juicy bits via
git cryptin many repositories. I’d do it all over again in a heart beat,That being said I only strongly recommend this tooling to folks who have and have to use PGP already. If you already have keys and have to handle them anyway, this is a great way to leverage them. If you don’t then maybe stay away from it if you can. PGP is awful. There isn’t an obvious successor yet and probably never will be for all the use cases, but there are some good entries in the space, especially for more specialized use cases. Hold off and/or experiment with some of the new encryption options unless you want to be having “fun” with PGP keys in another decade.
The
git-cryptproject itself is pretty solid as it stands, but at the same time is on the verge of being unmaintained. The original developer hasn’t been very active, has not passed the buck to anyone that could run with it, and weight hasn’t gathered around a fork yet.I guess I can plug our open-source git-based secrets management solution here, which is made of command-line tool (for managing secrets) and an api that integrates directly into your application (for retrieving them dynamically at runtime). It’s a KISS secrets management system approach that eschews having servers to provide secrets to your projects at runtime; the implementation is standardized and has been ported to different languages and frameworks.
Here’s the rust version: https://github.com/neosmart/securestore-rs and here’s a writeup that’s largely been superseded by the expanded README: https://neosmart.net/blog/securestore-open-secrets-format/
The approach is meant to be dependency-free and flexible in terms of how you deploy secrets into dev/staging/prod environments; we’ve seen people using it in creative ways.
“The Ansible [vault] based solution has worked … but … I have a nasty habit of leaving the file decrypted”
The “edit” feature on Ansible vault really prevents me from accidentally doing this. Granted - I don’t do a ton of this type work - but with my Ansible vault workflow there’s never a moment when the file is decrypted except when I’m working on exactly this file.
I do like git-crypt but it’s wildcards and ways to encrypt files have burned me more than once. Thanks for the agebox reference!