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.

[FlorianFranzen]

I currently use git-crypt which works well for my use case.

[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

[codygman]

Don't want to be a bother, but I wanted to chime in and say for me personally having some solution for secrets is my biggest blocker for things like predictable mail setup on all machines, spotifyd setup on all machines, etc.

What are others doing/using in the interim? I suppose I could setup another syncthing folder and do a readFile for these things but I'd hate to do that if we're close to a solution.

It seems like it might be worth coming up with a temporary solution at this point though, so are there better ideas than mine?

[Pacman99]

You can take a look at my setup at: gitlab.com/coffeetablebrothers/myrddin. I use agenix and it was really easy to integrate with devos. Just added it as a flake input, and added the module in extern and the package to devShell. I dropped git-crypt, tbh the most annoying part you have to remove the git filter and move the directory, push and move the directory back and push. Then you just follow the directions in the agenix repo. Its agenix -e to edit secrets within secrets folder, then just add different secrets to your profiles with the agenix module.

[nrdxp]

This sounds pretty great. Do you think you'd be able to submit your workflow as a PR? It would help a lot to finally have something pushed toward this. Also, on an unrelated note (don't have an email for you yet @Pacman99), could you please contact me via email (available on my github profile). I have a proposition for you.

[Pacman99]

Yeah sure! I'll see if I cant setup something soon.

[blaggacao]

Also are you reachable under Pacman99#matrix.org ? (In occasions a backchannel can help make coordination more efficient)

[Pacman99]

Yeah good idea! my matrix id is @pachumicchu:myrdd.info.

[codygman]

I've been wanting this one more lately, so I just posted a $50 bounty for it 😃

[codygman]

Who should get the bounty? Lol

https://www.bountysource.com/issues/95491155-encrypt-with-r-age

[blaggacao]

I think @Pacman99, recently, has done the overwhelmingly largest chunk of the work. So I'd suggest him.

[codygman]

@Pacman99 can you claim that bounty?

[Pacman99]

Ohh yeah I already did, my bounty source user is also Pacman99. Thanks!

[Pacman99]

I think this is pretty much documentation. Let me know what you all think: #279

[Pacman99]

Although perhaps thats more of a testament to the new api :)

[cipharius]

I wanted to mention, that this discussion clarifies state of DevOS secret management better than the documentation page on secrets.

From reading just the docs, it wasn't clear that git-crypt and agenix are independent methods and that I shouldn't be using them side by side.

Judging by this thread, I understand that agenix supersedes git-crypt method and that the old method is only kept for backwards compatibility. Perhaps this should be reflected in the documentation, by explicitly mentioning that git-crypt is deprecated method and moving it's setup instructions to the bottom of page?

[Pacman99]

Good point thanks for bringing it up. I think I actually wrote that with the intention that git-crypt and agenix were supposed to be used side by side. But through some discussion on the PR we decided to eventually drop git-crypt, but I missed updating the docs to reflect that decision.

[Princemachiavelli]

I'm surprised agenix is intended to be a full replacement for git-crypt. While agenix has the advantage of keeping secrets safe in /nix/store - the process of using it is a very cumbersome compared to git-crypt. git-crypt has the advantage of being fully transparent & very reliable. Knowing that even if I forget to use agenix, the secrets directory is protected is a very useful feature since many user's have their devos repos public.

Currently agenix does not work with ssh agents and also changes the file hash on every rekey event (and just adding a file to the agenix system means you need to rekey as least that is the workflow I have seen & used). If these issues were fixed then maybe it would be just seamless as git-crypt but until then I think having both is necessary. I haven't had any issues using both together so I don't think it harms anything to keep the git-crypt examples & documentation.

[nrdxp]

The main reason I would like to deprecate git-crypt is that it breaks remote evaluation: e.g. nixos-rebuild --flake "github:nrdxp/devos#myCoolSystem" will fail with git-crypt, but not with agenix. With that said, the git-crypt support was only ever adding the git-crypt package and documenting it's usage, so even if we fully remove it, there is nothing stopping you from adding it back to your own devshell and continuing to use it happily.