| 25 Oct 2021 |
 David Arnold (blaggacao) | As in nix (without IFD), you only have two stages: eval / build. I think TF also has a similar limitation and there is no recursive TF or such thing. | 17:43:42 |
| David Arnold (blaggacao) | A similarity, which is not a coincidence on a very fundamental level. | 17:44:24 |
 genadij.udarov | True. Back in the day, tf used to rely solely on tfstate to decide what API calls to do. I guess I could hack something that would generate tfstate from nix, if I'd need to. :-D
Thanks for the input, I think I'll be able to start hacking a PoC now. | 17:46:22 |
| David Arnold (blaggacao) | Cool! Just make sure you don't needlessly allow exogenous data to be input intor your gitops capsule. | 17:47:08 |
 @timdeh:matrix.org | I wonder if committing the tfstate file would be a possible solution 🤔 | 17:47:26 |
| David Arnold (blaggacao) | * Cool! Just make sure you don't _needlessly_ allow exogenous data to be input into your gitops capsule. | 17:47:26 |
| David Arnold (blaggacao) | If it doesn't hold secrets, yes. | 17:47:44 |
| @timdeh:matrix.org | speaking of which, I found yet another pass like yesterday 😅
https://share-secrets-safely.github.io/cli/compare.html | 17:48:20 |
| David Arnold (blaggacao) | If we plug an encryption workflow in front of it, then we need things like git smudge/clean or direct tf support for encrypted state fules. | 17:48:38 |
| David Arnold (blaggacao) | * If we plug an encryption workflow in front of it, then we need things like git smudge/clean or direct tf support for encrypted state files. | 17:48:52 |
| @timdeh:matrix.org | I was just considering if it would be possible to do some weaker form of forward secrecy with git and gpg by simply having a tool generate a new subkey on each commit, and burning it after each subsequent change to secrets 🤔 | 17:51:48 |
| @timdeh:matrix.org | usually with perfect forward secrecy that temporary session key would live only in memory, so it's not quite "perfect" forward secrecy, but it would be an improvement over having the entire agenix and/or git-crypt history accessible from the same key | 17:52:26 |
| David Arnold (blaggacao) | In reply to @timdeh:matrix.org
speaking of which, I found yet another pass like yesterday 😅
https://share-secrets-safely.github.io/cli/compare.html I have the impression that somebody needes a divnix/data-merge but for injecting secrets. This is interesting since pure nix does not allow to inject attributes. | 18:02:44 |
| @timdeh:matrix.org | that sounds like a very interesting idea, in theory at least 🤔 | 18:03:44 |
| David Arnold (blaggacao) | One pattern could be, though:
inputs.secrets.url = "path:./secrets.json where sheesy does preprocessing to (ehm) write secrets.json.
| 18:03:45 |
| David Arnold (blaggacao) | Or: we add pass-cpmpliant prim-ops to nix. | 18:04:29 |
| David Arnold (blaggacao) | builtins.fromPass -- a sheesy like built-in. | 18:04:45 |
| David Arnold (blaggacao) | * Or: we add pass-compliant prim-ops to `nix`. | 18:04:59 |
| @timdeh:matrix.org | the main reason I find sheesy interesting after reading up on it a bit is that they eventually plan to migrate to sequoia-pgp, which has a lot of interesting features and seems a lot more user friendly than gnupg | 18:05:04 |
| David Arnold (blaggacao) | * Or: we add pass-compliant primop to `nix`. | 18:05:08 |
| @timdeh:matrix.org | in particular, I read a whitepaper about including some sort of forward secrecy directly into sequoia yesterday. Not sure how far along that's come implementation wise though. | 18:05:33 |
| David Arnold (blaggacao) | They should just fork and push work on age. | 18:06:14 |
| David Arnold (blaggacao) | Maybe it's time to think about a "special" input for flakes. | 18:07:04 |
| David Arnold (blaggacao) | Such input, ingesta secrets, but otherwise tries to be as friendly as possible to the evaluation cache and makes sure that secrets do have string contexts which prevents decrypted versions thereof to be written to disk. | 18:07:49 |
| David Arnold (blaggacao) | Or a builtin that obly takes effect on nix eval but obfuscates on nix build. | 18:08:25 |
| David Arnold (blaggacao) | * Or a builtin that only takes effect on `nix eval` but obfuscates on `nix build`. | 18:08:31 |
| David Arnold (blaggacao) | * Such input, ingests secrets, but otherwise tries to be as friendly as possible to the evaluation cache and makes sure that secrets do have string contexts which prevents decrypted versions thereof to be written to disk. | 18:08:42 |
| David Arnold (blaggacao) | In reply to @blaggacao:matrix.org
Or a builtin that only takes effect on nix eval but obfuscates on nix build. I like this better. | 18:09:49 |
| David Arnold (blaggacao) | There is no language-conform way to handle secrets in the nix store without implementing an entire encryption framework. | 18:10:36 |
| David Arnold (blaggacao) | * There is no language-conform way to handle secrets in the nix store without implementing an entire _opinionated_ encryption framework. | 18:10:50 |
