4 ms·

Show HN: Rot - Offline secrets management

116 points by candiddevmike 3y 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 3y 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.
- candiddevmike 3y 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/ https://rotx.dev/docs/explanations/secret-wrapping/
jiggawatts 3y 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/9168285d9ccfe783dc82343ef1a6468fc21971a1/go/cmdDecrypt.go#L6 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.
- candiddevmike 3y ago
  That library you linked to is part of a shared repo we use for all of our stuff, https://github.com/candiddev/shared 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 3y 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/9168285d9ccfe783dc82343ef1a6468fc21971a1/go.mod#L9 https://github.com/candiddev/rot/blob/9168285d9ccfe783dc8234...
  - deleted 3y ago
    [deleted]
  - jiggawatts 3y 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 https://news.ycombinator.com/item?id=38596700
    - teeray 3y ago
      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/ https://sum.golang.org/
azophy_2 3y 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 3y 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/ https://rotx.dev/pricing/
  - matheusmoreira 3y ago
    The selling of exceptions to the GPL is also considered ethical: https://www.gnu.org/philosophy/selling-exceptions.en.html https://www.gnu.org/philosophy/selling-exceptions.en.html It's something that enables projects to become free software.
jhot 3y 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 3y ago
Huh, nitializing the submodule with GH requires key-based auth. Learned a lot just setting it up locally.

116 points by candiddevmike 3y ago

neverrroot 3y 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.

candiddevmike 3y 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/ https://rotx.dev/docs/explanations/secret-wrapping/

jiggawatts 3y 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/9168285d9ccfe783dc82343ef1a6468fc21971a1/go/cmdDecrypt.go#L6 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.

candiddevmike 3y ago
That library you linked to is part of a shared repo we use for all of our stuff, https://github.com/candiddev/shared 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 3y 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/9168285d9ccfe783dc82343ef1a6468fc21971a1/go.mod#L9 https://github.com/candiddev/rot/blob/9168285d9ccfe783dc8234...
- deleted 3y ago
  [deleted]
- jiggawatts 3y 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 https://news.ycombinator.com/item?id=38596700
  - teeray 3y ago
    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/ https://sum.golang.org/

azophy_2 3y 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 3y 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/ https://rotx.dev/pricing/
- matheusmoreira 3y ago
  The selling of exceptions to the GPL is also considered ethical: https://www.gnu.org/philosophy/selling-exceptions.en.html https://www.gnu.org/philosophy/selling-exceptions.en.html It's something that enables projects to become free software.

jhot 3y 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 3y ago

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