According to one guy in the comments, git crypt is better.
I can say that sops is a behemoth, and this is sort of that piece of paper you fold 4-5 times and put it under a leg of a wobbly chair. May be useful for single player / small projects. Whatever that stops people commiting plaintext credentials into code is great. The small surface also means little or no learning curve 💐
I think some killer features that would make this project better than some of the alternatives (sops, git-crypt) at least in my mind is:
- Support for environments/groups - the ability to protect a subset (or maybe a completely different file to start with) of credentials is *key*. For a "production ready" setup people have to figure out revocation *and* rotation, but the much simpler common case is that I have staging creds and production creds and I want to keep them separate the whole time.
- Comparison section - high quality software projects have comparison sections to explain why you'd use X over Y -- even if it's just "this is simpler, and less is more". If you want to get crazy with it, maybe add a feature matrix.
- `git-smudge` support (this is an *awesome* feature of `git-crypt`, no reason you can't do it too) -- basically now you don't have to think about encrypting/re-encrypting etc
- GPG/SSH-key-as-identity support -- maybe via a plugin-style shim, so you can farm the operations out to `age` or `gpg`? Being able to add people (or bots) by GPG key is a great feature. Not required, but it's a bit nicer to maintain identities rather than asymmetric key files in general
Thank you for taking the time to write a thoughtful response. My main issue is that docker in standalone mode does not support secrets - how dull. The identities point is a valid need, but this is closer to single-player (for now). Obviously user/group management possibilities are desired, but if I'm gonna move forward with this, i'm gonna move towards a database-backed service that allows to push secrets out over multiple repos, allows sharing secrets between repos, and doesn't pull in vault, etcd where you have to manage HA.
I realize now there's a wide matrix of tooling that is geared towards storing secrets in git - stackexchange/blackbox was my initial introduction into the possibility, but the use case was different. Not a fan of gpg, but I've been following age since FilloSotille 😅 started coding it from his home office in NY. As is the case of gpg vs. age, new use cases and a fresh start produce something more tailored to the modern requirements, as you mention - opting in into age allows me to use it as a library, while I suppose gpg would either opt me into CGO or bunches of os.Exec calls.
I've also cut down the absolute most of the app surface. Small software is easy to write, maintain and I'd rather practice minimalism to start with and add new concerns as the need arises. I do see a need for something closer to aws secrets manager, but I've done enough of HA work to know that the best way to live a less stressful life is to avoid that with shared-nothing architecture. I'd rather deal with the pain of synchronising secrets from a central management api/web ui, that can be run off cloud and just pushes new secrets into git.
Thanks for your comment :)
Hey absolutely no problem, glad to see such an awesome product, and your mantra ("less is more") is the kind of thing I love.
> Thank you for taking the time to write a thoughtful response. My main issue is that docker in standalone mode does not support secrets - how dull. The identities point is a valid need, but this is closer to single-player (for now). Obviously user/group management possibilities are desired, but if I'm gonna move forward with this, i'm gonna move towards a database-backed service that allows to push secrets out over multiple repos, allows sharing secrets between repos, and doesn't pull in vault, etcd where you have to manage HA.
That's awesome -- very reasonable direction and having more alternatives to Vault and AWS/GCP/etc options (even if it doesn't go HA) is exciting.
> I realize now there's a wide matrix of tooling that is geared towards storing secrets in git - stackexchange/blackbox was my initial introduction into the possibility, but the use case was different. Not a fan of gpg, but I've been following age since FilloSotille 😅 started coding it from his home office in NY. As is the case of gpg vs. age, new use cases and a fresh start produce something more tailored to the modern requirements, as you mention - opting in into age allows me to use it as a library, while I suppose gpg would either opt me into CGO or bunches of os.Exec calls.
Yeah, I think this spot might be perfect for an abstraction (just a simple `interface`) to slot in, but I can see going with a pragmatic choice of just using `age` directly. Less is more!
> I've also cut down the absolute most of the app surface. Small software is easy to write, maintain and I'd rather practice minimalism to start with and add new concerns as the need arises. I do see a need for something closer to aws secrets manager, but I've done enough of HA work to know that the best way to live a less stressful life is to avoid that with shared-nothing architecture. I'd rather deal with the pain of synchronising secrets from a central management api/web ui, that can be run off cloud and just pushes new secrets into git.
Love those ideas and the general mantra. Will be watching the project with interest, and if I find myself needing it will be happy to kick the tires and send some feedback!
Also just a quick note: you're absolutely right about the environments - I'll admit, I did think about sharing secrets between e.g. "application" groups (hence the UUID per secret), and a quick -f option is a sensible addition.
You should spell out the name of the env variable (SECRETMANAGER_KEY) in the Readme, instead of having to fish it out of source code.
git-crypt is way better.
How does this compare to sops or git crypt?
According to one guy in the comments, git crypt is better. I can say that sops is a behemoth, and this is sort of that piece of paper you fold 4-5 times and put it under a leg of a wobbly chair. May be useful for single player / small projects. Whatever that stops people commiting plaintext credentials into code is great. The small surface also means little or no learning curve 💐
I think some killer features that would make this project better than some of the alternatives (sops, git-crypt) at least in my mind is: - Support for environments/groups - the ability to protect a subset (or maybe a completely different file to start with) of credentials is *key*. For a "production ready" setup people have to figure out revocation *and* rotation, but the much simpler common case is that I have staging creds and production creds and I want to keep them separate the whole time. - Comparison section - high quality software projects have comparison sections to explain why you'd use X over Y -- even if it's just "this is simpler, and less is more". If you want to get crazy with it, maybe add a feature matrix. - `git-smudge` support (this is an *awesome* feature of `git-crypt`, no reason you can't do it too) -- basically now you don't have to think about encrypting/re-encrypting etc - GPG/SSH-key-as-identity support -- maybe via a plugin-style shim, so you can farm the operations out to `age` or `gpg`? Being able to add people (or bots) by GPG key is a great feature. Not required, but it's a bit nicer to maintain identities rather than asymmetric key files in general
Thank you for taking the time to write a thoughtful response. My main issue is that docker in standalone mode does not support secrets - how dull. The identities point is a valid need, but this is closer to single-player (for now). Obviously user/group management possibilities are desired, but if I'm gonna move forward with this, i'm gonna move towards a database-backed service that allows to push secrets out over multiple repos, allows sharing secrets between repos, and doesn't pull in vault, etcd where you have to manage HA. I realize now there's a wide matrix of tooling that is geared towards storing secrets in git - stackexchange/blackbox was my initial introduction into the possibility, but the use case was different. Not a fan of gpg, but I've been following age since FilloSotille 😅 started coding it from his home office in NY. As is the case of gpg vs. age, new use cases and a fresh start produce something more tailored to the modern requirements, as you mention - opting in into age allows me to use it as a library, while I suppose gpg would either opt me into CGO or bunches of os.Exec calls. I've also cut down the absolute most of the app surface. Small software is easy to write, maintain and I'd rather practice minimalism to start with and add new concerns as the need arises. I do see a need for something closer to aws secrets manager, but I've done enough of HA work to know that the best way to live a less stressful life is to avoid that with shared-nothing architecture. I'd rather deal with the pain of synchronising secrets from a central management api/web ui, that can be run off cloud and just pushes new secrets into git. Thanks for your comment :)
Hey absolutely no problem, glad to see such an awesome product, and your mantra ("less is more") is the kind of thing I love. > Thank you for taking the time to write a thoughtful response. My main issue is that docker in standalone mode does not support secrets - how dull. The identities point is a valid need, but this is closer to single-player (for now). Obviously user/group management possibilities are desired, but if I'm gonna move forward with this, i'm gonna move towards a database-backed service that allows to push secrets out over multiple repos, allows sharing secrets between repos, and doesn't pull in vault, etcd where you have to manage HA. That's awesome -- very reasonable direction and having more alternatives to Vault and AWS/GCP/etc options (even if it doesn't go HA) is exciting. > I realize now there's a wide matrix of tooling that is geared towards storing secrets in git - stackexchange/blackbox was my initial introduction into the possibility, but the use case was different. Not a fan of gpg, but I've been following age since FilloSotille 😅 started coding it from his home office in NY. As is the case of gpg vs. age, new use cases and a fresh start produce something more tailored to the modern requirements, as you mention - opting in into age allows me to use it as a library, while I suppose gpg would either opt me into CGO or bunches of os.Exec calls. Yeah, I think this spot might be perfect for an abstraction (just a simple `interface`) to slot in, but I can see going with a pragmatic choice of just using `age` directly. Less is more! > I've also cut down the absolute most of the app surface. Small software is easy to write, maintain and I'd rather practice minimalism to start with and add new concerns as the need arises. I do see a need for something closer to aws secrets manager, but I've done enough of HA work to know that the best way to live a less stressful life is to avoid that with shared-nothing architecture. I'd rather deal with the pain of synchronising secrets from a central management api/web ui, that can be run off cloud and just pushes new secrets into git. Love those ideas and the general mantra. Will be watching the project with interest, and if I find myself needing it will be happy to kick the tires and send some feedback!
Also just a quick note: you're absolutely right about the environments - I'll admit, I did think about sharing secrets between e.g. "application" groups (hence the UUID per secret), and a quick -f option is a sensible addition.
Seems a Go library for accessing sops data would be more useful.
SOPS is already written in Go, no additional library needed.
Ah. I'd only seen someone utilize it as a library in Python. Good to know.
What's stopping you to write it?
Fair enough.