To the maintainer of this repo, please make it accessible and easy to understand. The animated image is a bit too fast to read and follow, especially considering that there is absolutely no explanation right at the beginning for what the tool does AND why the tool is required for anyone. I had to scroll down a lot to get to the part where the important details are (which could answer the question "why should I even look at or consider this tool?").
Yes, only based on the animated image I guess that the goal of the tool could be to encrypt just the passwords which are expected to be present in some plain text files in some bigger setups.
It would help to have some explanation of what the goals and use scenarios are, and general assumptions.
This seems like a much easier-to-apply, automatic version of Ansible Vault's YAML variable encryption[0]. Personally I've never needed the extra per-YAML-entry control Ansible Vault gives you, so this seems a better approach.
If you like the configuration of SOPS but you want to use bitnamis sealed secrets as a K8s native approach feel free to have a look at my alternative cli https://github.com/dschniepp/sealit
I am surprised Mozilla developers chose to write this project in Go instead of Rust, but do not get me wrong, I like Go, it is my primary programming language at work, and I always try to advocate for the right tool for the job. I still find it curious, though. I guess it was easier to translate Python to Go than to Rust.
And a tool like that doesn't get any advantage from Rust - manual memory management would just be a chore with no benefits, and Go's crypto library is pretty good ( no idea about Rust's)
Neat! I like that it maintains everything in the same file. No need to mess with .gitignore
Have you tried BlackBox?
Projects like https://github.com/StackExchange/blackbox have the benefit of using GPG group encryption. Each person has their own secret key but any one key can decrypt the file. This makes key rotation easier.
Would really, really love to get an official release of sops with age support. Thanks for the tool--compared to GPG age is a complete breath of fresh air.
Keys are stored in a PGP keyring and/or cloud Key Management Service (KMS). This is mentioned in the opening statement of the readme, and usage is detailed in section 2 of the docs:
What is the purpose of encrypting just the values and not the keys? If you need to run the file through sops to decrypt the values before using it, why not just encrypt the entire file?
Is it just for easier debugging, so you can see the structure of the encrypted file?
When I review code related to security, I first start with the dependency list. I don't keep looking if they depend on 50 external packages (wc -l go.mod).
Even better, IMO, would be if all targets were also proxies and a client could choose -- at "query time" -- any combination of (proxy, target) that they prefer.
If you wanted to go a step further, you can even allow "chaining" of proxies, such that the path a query takes might be, in an extreme example, similar to how Tor operates:
Anyways, this is kinda sorta interesting, I guess, but honestly I'm more excited by and looking forward to the (hopefully!) eventual adoption and roll-out of "DNS SVCB and HTTPS RRs" [0] -- one of the other I-Ds (linked in the OP) on which ODoH is built -- and I suspect many other HN'ers will be as well (although I'd happily settle for SRV RR support in browsers).
I've copied it to the "Cloudflare and Apple design a new privacy-friendly internet protocol" [0] thread that it was intended for, but it's too late to delete it from this one.
Throwing another tiny open-source option into the arena: Envwarden[0] is a simple wrapper for managing server secrets with the Bitwarden[1] password manager. Not affiliated with Bitwarden in any way.
If you have many secrets you'll probably still end up breaking them out into different files to minimize conflicts between multiple in-progress branches. A good place to start is keeping a secrets file per environment+service:
My experience with git-crypt is it works fine until you have a merge conflict. This tool seems a lot more compelling in that regard, since only encrypting the subset of the file that needs to be secret I'd imagine diffs and merge conflict would be pretty seamless.
The format is language/platform agnostic and we’ve releases libraries for .NET/C# and rust, as well as developed two separate CLI utilities that can create and manage the stores.
33 comments
[ 2.7 ms ] story [ 83.0 ms ] threadhttps://www.gopass.pw/
I guess one could use Mozilla SOPS to create something like gopass...
It would help to have some explanation of what the goals and use scenarios are, and general assumptions.
[0] https://docs.ansible.com/ansible/latest/user_guide/vault.htm...
https://github.com/ansible-collections/community.sops
Have you tried BlackBox?
Projects like https://github.com/StackExchange/blackbox have the benefit of using GPG group encryption. Each person has their own secret key but any one key can decrypt the file. This makes key rotation easier.
https://github.com/mozilla/sops/tree/develop
https://github.com/mozilla/sops#usage
Generally found that setting that env var with anything mildly complicated (in go!) in terms of AWS roles helps.
Other libraries/clis/etc (in other languages) tend to transparently traverse the credentials chain for you.
Is it just for easier debugging, so you can see the structure of the encrypted file?
If you wanted to go a step further, you can even allow "chaining" of proxies, such that the path a query takes might be, in an extreme example, similar to how Tor operates:
--Anyways, this is kinda sorta interesting, I guess, but honestly I'm more excited by and looking forward to the (hopefully!) eventual adoption and roll-out of "DNS SVCB and HTTPS RRs" [0] -- one of the other I-Ds (linked in the OP) on which ODoH is built -- and I suspect many other HN'ers will be as well (although I'd happily settle for SRV RR support in browsers).
--
[0]: https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02
I've copied it to the "Cloudflare and Apple design a new privacy-friendly internet protocol" [0] thread that it was intended for, but it's too late to delete it from this one.
--
[0]: https://news.ycombinator.com/item?id=25344358
[0] https://github.com/envwarden/envwarden
[1] https://bitwarden.com/
https://github.com/mozilla/sops#48showing-diffs-in-cleartext...
If you have many secrets you'll probably still end up breaking them out into different files to minimize conflicts between multiple in-progress branches. A good place to start is keeping a secrets file per environment+service:
https://terragrunt.gruntwork.io/docs/reference/built-in-func...
Just to throw in another one, at my company we are using git-crypt [1], and it works pretty well in our case
[1] https://github.com/AGWA/git-crypt
The format is language/platform agnostic and we’ve releases libraries for .NET/C# and rust, as well as developed two separate CLI utilities that can create and manage the stores.