Show HN: Rot - Offline secrets management

by candiddevmike • 3 years ago

116 13 3 years ago

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.

neverrroot• 3 years ago

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.

candiddevmike2• 3 years ago

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/

jiggawatts2• 3 years ago

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.

candiddevmike2• 3 years ago

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.

jay-barronville• 3 years ago

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...

jiggawatts2• 3 years ago

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

azophy_2• 3 years ago

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"?

phantomathkg• 3 years ago

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/

matheusmoreira• 3 years ago

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.

jhot• 3 years ago

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.

phnofive• 3 years ago

Huh, nitializing the submodule with GH requires key-based auth. Learned a lot just setting it up locally.

Show HN: Rot - Offline secrets management

Related Stories