Encrypt with (r)age

[blaggacao]

Is your feature request related to a problem? Please describe.
I finally want to use age / rage.

Describe the solution you'd like

Something around those lines... (not well thought through)

secrets/** filter=crypt
[filter "crypt"]
	clean = rage -r $(cat ~/.ssh/id_ed25519.pub)
	smudge = rage --decrypt -i ~/.ssh/id_ed25519
	required

Describe alternatives you've considered
none / sops, but sops has ugly configmgt domain overlap with nix.

Additional context

https://git-scm.com/docs/gitattributes

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[nrdxp]

I've been exploring possibly integrating agenix support, so that we can store encrypted secrets properly. More experimentation is needed.

[adrian-gierakowski]

ugly configmgt domain overlap with nix

@blaggacao I’m curious what you meant by this. Would you be able to elaborate? Thanks!

[blaggacao]

Sure. Its direct manifestation is that sops has a separate yaml config file. I really like the agenix since it keeps the configuration domain within the (power of the) nix language entirely.

@FlorianFranzen for practical reasons, I'll probably using git-crypt as provided currently by this repo, too. But I think agenix is really a very good idea for those inclined to try stuff out. I feel it has real chances to become the better alternative...

[nrdxp]

Personally, I'd just like to have secrets that aren't world readable when deployed. I'll still probably keep git-crypt available even if we do add support for agenix since they address separate concerns, i.e:

git-crypt -> protects secrets stored in the repo
agenix -> protects secrets deployed to nix-store

Of course, I still have to experiment with agenix to see how well it delivers on this promise.

[blaggacao]

I researched a little. I seems at least conceivable in principle that agenix can extend its scope to support the git crypt use case in an unified way.

[blaggacao]

ryantm/agenix#12

[blaggacao]

please, if anyone feels (more) competent / confident (than me), take over: ryantm/agenix#14

[blaggacao]

There has been made an important argument here:

Unless we can come up with some better plan for how to import the files into the NixOS configuration, they need to be encrypted at rest.

meaning git.filter.agenix.smudge and git.filter.agenix.clean are vetoed for the time being (agenix has agenix --edit <file> for the remainder of the use case), leaving us with git.diff.agenix.textconv — yaay!

[ymarkus]

Is there any progress with secrets? I don't really care how it's done, but I would really like a solution integrated in this template. I've thought about doing something like sops-nix or something with pass?

[nrdxp]

@ymarkus, unfortunately not, but it's on the agenda. After reviewing the options, my prefered solution would use gopass, but I've yet to work out all the details. I'll have more time this month than last, so hopefully we can get this knocked out soon.

[codygman]

I don't quite understand this statement:

sops has ugly configmgt domain overlap with nix.

I was just investigating sops-nix after having lots of issues with git-crypt (maybe because I'm using an ed25519 gpg key) and it seemed like the most convenient option here.

I'm not sure how a gopass based solution might work though.

[Pacman99]

Personal opinion: devos shouldn't include secrets management, outside of git-crypt - just to protect new users.

secrets management is a very wide concern and everyone has different requirements. And with the extern folder, its really easy to set up stuff yourself. I was able to use agenix with my server, by just adding the input then the module in extern. Then I just followed agenix instructions with creating a secrets.nix file in the secrets folder.

What could be useful is maybe adding documentation on how to integrate different secrets management tools with devos.

[blaggacao]

I don't quite understand this statement:

sops has ugly configmgt domain overlap with nix.

This question actually came up before. Expanding on my previous reply...

From the asciinema animation on the github repo:

SOPS encrypts the values of a yaml or json file not the keys.

Hence, the tool was designed to do work on and as a function of an authoritative yaml/json file.

I think divnix/devos tries to put all (core) configuration management under the domain of the nix (later maybe nickel) language. Insofar sops appears (to me) a bit incompatible with this repository's goals and philosophy, and agenix seems like the better option.

[nrdxp]

@blaggacao, I agree. I looked at sops and it didn't seem appealing for this project. Honestly, none of the options are absolutely ideal, and I keep wondering why Nix hasn't solved this problem by now, as it was one of the earliest issues opened on the GitHub tracker, some 9 years ago: NixOS/nix#8. I must be missing something important, because changing permissions inside the nix store, or perhaps having a separate nix/secret-store with secure permissions doesn't seem like it should be all that difficult.

Alas...

[blaggacao]

https://github.com/FiloSottile/age/releases/tag/v1.0.0-rc.1 (breaking news 😸 )

[blaggacao]

Thought fodder:

• https://christine.website/blog/nixos-encrypted-secrets-2021-01-20

After reading through this blog post, one realizes, this issue perfectly meats with #163 to shoot two birds with one shot.

/cc @Xe