Show HN: Rot - Offline secrets management(github.com)
github.com
Show HN: Rot - Offline secrets management
https://github.com/candiddev/rot
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.
14 comments
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"?
They seems to have a very interesting licensing where company can pay 300 USD per year to be exempt from AGPL license.
https://rotx.dev/pricing/
https://rotx.dev/pricing/
The selling of exceptions to the GPL is also considered ethical:
https://www.gnu.org/philosophy/selling-exceptions.en.html
It's something that enables projects to become free software.
https://www.gnu.org/philosophy/selling-exceptions.en.html
It's something that enables projects to become free software.
The first thing I noticed is that the cryptographic packages are referenced by an unversioned GitHub URL. E.g.: https://github.com/candiddev/rot/blob/9168285d9ccfe783dc8234...
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.
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.
I think you’re misunderstanding how Go imports work. In Go projects, the versioning happens in the go.mod file [0].
[0]: https://github.com/candiddev/rot/blob/9168285d9ccfe783dc8234...
[0]: https://github.com/candiddev/rot/blob/9168285d9ccfe783dc8234...
[deleted]
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.
[1] https://news.ycombinator.com/item?id=38596700
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.
[1] https://news.ycombinator.com/item?id=38596700
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/
You only looked at the pseudo version and missed the important replace directives
replace github.com/candiddev/shared => ./shared
replace github.com/google/go-jsonnet => github.com/thequailman/go-jsonnet v0.0.0-20230924031349-110b4ca1dc1a
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.
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.
Here's a diagram of Rot's secrets wrapping works: https://rotx.dev/docs/explanations/secret-wrapping/
Here's a diagram of Rot's secrets wrapping works: https://rotx.dev/docs/explanations/secret-wrapping/
Huh, nitializing the submodule with GH requires key-based auth. Learned a lot just setting it up locally.