25 Oct 2021 |
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 |
David Arnold (blaggacao) | Nah, still a bad idea all together. Otoh, all that can be dome with pre-processing probably can be done with IFD-like. | 18:12:16 |
David Arnold (blaggacao) | Or what's the deal with builtins.exec ? | 18:12:33 |
@timdeh:matrix.org | I dunno, doesn't seem safe so I haven't use it 😅 | 18:12:49 |
@timdeh:matrix.org | * I dunno, doesn't seem safe so I haven't used it 😅 | 18:13:36 |
David Arnold (blaggacao) | allow-unsafe-native-code-during-evaluation | 18:14:07 |
genadij.udarov | In reply to @timdeh:matrix.org I wonder if committing the tfstate file would be a possible solution 🤔 We used to do that back in like 2016 or so, but realised that using S3 as a backend for the tfstate was better. :-D | 18:14:15 |
@timdeh:matrix.org | we use a vault-plugin for our tfstate atm | 18:14:43 |
tomberek | you can use exec to decrypt something for you at eval-time, but it would often leak into the /nix/store . You'd need a build-time exec . | 18:14:45 |
David Arnold (blaggacao) | Good resume; | 18:15:07 |
@timdeh:matrix.org | * we use a vault-plugin for our tfstate atm | 18:15:08 |
David Arnold (blaggacao) | * Good resume! | 18:15:13 |
David Arnold (blaggacao) | To de-throne the sheesy magic addition to manage configs, build time exec might be what's needed, though. | 18:15:50 |
@timdeh:matrix.org | That opens up a pretty huge can of impure worms though | 18:16:14 |
David Arnold (blaggacao) | For all that involves nixos or derivations, that would be very much self inflicting harm. | 18:16:38 |
David Arnold (blaggacao) | Yeah, sheesy 's serverless approach to rotation is a bit of a pain, too. | 18:17:49 |
tomberek | The idea is that decryption is either success or failure, so it's not impure, but either pure or impossible. | 18:17:53 |
David Arnold (blaggacao) | If we need identity, let's just use an attestor (such as vault or spiffe or step-ca ). | 18:18:22 |
@timdeh:matrix.org | which reminds me, I also found this yesterday:
https://openpgp-ca.org/ | 18:18:44 |
David Arnold (blaggacao) | If we just need to assert identity, a SViD based aproach might be a bit more inferoperable. | 18:19:41 |
David Arnold (blaggacao) | SVID = Certificate of Identity (X509) + spiffe ID | 18:20:05 |
David Arnold (blaggacao) | SpiffeID: spiffe://com.mydomain/me/and/my/dog | 18:20:41 |
tomberek | SPIFFE is good, but like anything x509, complex. | 18:21:02 |
David Arnold (blaggacao) | All that credentials actually do is to establish identity (in a very old-fashoined way) | 18:21:35 |
@timdeh:matrix.org | yeah I was about to say, x509 might be the only format even more frustrating to use than gnupg 😅 | 18:21:36 |
David Arnold (blaggacao) | X509 is very simple, and interpoerable with tls. | 18:22:10 |