Finally open sourced an internal tool we've been using for managing secrets. It's similar to SOPS, but more opinionated, easier to configure/use correctly, and produces nicer git diffs. It also supports one-way encryption, so you don't have to know the private key to add secrets.
I like it. Simple & straightforward. However I'm interested in the usage of AGPL license. Do you think it would hinder adoption as many company fear of adopting AGPL due to its "virality"?
This type of approach would not pass a code review of something as security-critical as a secrets management tool.
E.g.: this generally prevents "reproducible builds", and allows you to "sneak in" changes even if downstream users aren't modifying anything themselves. It's a recipe for a supply-chain attack.
While admittedly I'm totally unfamiliar with Go package management, it's notable that the "shared" library reference in that link is un-versioned. It uses a pseudo-version of "v0.0.0-00010101000000-000000000000".
If I understand the sibling comment by the author[1] correctly, then the versioning of the "shared" module is via Git submodules, which point at a specific commit hash.
The only issue is that changes to submodule commit hashes are a little more difficult to audit, because they're embedded in the git repo files instead of the source code.
When used out-of-the-box, go.sum is what provides the cryptographic guarantees of the contents of modules retrieved using go.mod. There’s a distributed log system akin to the TLS certificate transparency log that hardens the system against the kinds of substitution you’ve referred to. You can read more about it here: https://sum.golang.org/
The replacement with ./shared means it's using exactly the version on disk (which is in a submodule here). The go-jsonnet replacement points to a specific commit.
That library you linked to is part of a shared repo we use for all of our stuff, https://github.com/candiddev/shared, it's versioned using git modules. We own all of the underlying code. We opted for git submodules because go modules hate CalVer, and we share a bunch of other stuff besides go libraries.
In the end, things are versioned like any other Go program, builds are 100% reproducible.
I just setup sops for a personal project today and wished it was slightly more opinionated much like this (I also like the age reference in your readme). Will definitely give this a go.
Yet another tool for managing secrets locally, wondering why should we use it over other tools? Tried to find it out on the fast, but couldn’t really. Would be nice to have it somehow documented i.e. by comparison to other similar tools.
The repo lists a few, but the main reasons are it lets you easily rekey to future encryption standards, and it supports one way encryption. Tools like SOPS require you have access to decrypt everything in order to add secrets (typically, though there are workarounds). With Rot, this works out of the box through another layer of asymmetric encryption.
