| 11 Jun 2024 |
 @irenes:matrix.org | I had more leads on how to maybe do that, but I can't find my notes | 07:13:24 |
| @irenes:matrix.org | other unusual corner cases heh | 07:13:30 |
| @irenes:matrix.org | like notionally I could use a bespoke pinning solution instead of flakes, and then the problem wouldn't come up - it's only the extremely restricted evaluation mode introduced by flakes that makes this an issue | 07:14:16 |
| @irenes:matrix.org | but that would only solve it for me | 07:14:37 |
| @irenes:matrix.org | I want to figure out how to make flakes not be a feature regression compared to non-flakes, so other people can benefit heh | 07:15:11 |
 jade_ | In reply to @irenes:matrix.org
hmm, well, impure derivations and similar concepts don't do what I want for secrets management i really don't know what you're trying to do | 07:21:54 |
| jade_ | In reply to @irenes:matrix.org
like notionally I could use a bespoke pinning solution instead of flakes, and then the problem wouldn't come up - it's only the extremely restricted evaluation mode introduced by flakes that makes this an issue i am pretty sure you can just override it with --impure? | 07:22:17 |
| jade_ | but anyhow, is agenix busted for your needs? | 07:22:40 |
| jade_ | i guess i am somewhat confused what the model is that means that you can't use agenix, other than wanting to have the encrypted secrets outside the flake repo | 07:23:19 |
| @irenes:matrix.org | no yeah I mean I haven't explained it but | 07:29:21 |
| @irenes:matrix.org | sigh it's | 07:29:25 |
| @irenes:matrix.org | I haven't yet decided just how much I want to share about the security model I'm trying to implement, but I can't use agenix | 07:29:42 |
| jade_ | you could do it entirely out of band, and then have a reference to which version of the secrets you need, or something like that | 07:30:08 |
| @irenes:matrix.org | before flakes, this was easy because secrets just lived outside the repo | 07:30:08 |
 K900 | I wish we had real eval time secrets tbh | 07:30:27 |
| @irenes:matrix.org | yes - if I were to use a network-based key server, I could use __impure and put it out of band | 07:30:35 |
| @irenes:matrix.org | but I can't have a hash of the secrets in the pinning information (whether flake.lock or otherwise) | 07:30:49 |
| jade_ | i guess the thing is, like, regardless of if they are in the repo or out of it, if they're going in the store, that's not a good secret management strategy | 07:30:54 |
| @irenes:matrix.org | they need to be actually dynamic | 07:30:55 |
| jade_ | i don't think the secrets should be interacting with nix at all ideally | 07:31:11 |
| @irenes:matrix.org | keeping things out of the store is a separate problem really | 07:31:17 |
| @irenes:matrix.org | I mean I take that point and all but | 07:31:27 |
| @irenes:matrix.org | like there are cases where things can't be kept out of the store, that's how it is heh | 07:31:56 |
| @irenes:matrix.org | "secrets" is really a bit of a misnomer because, for example, I want my tool to handle both public and private keys, but only private keys are secret per se | 07:32:21 |
| jade_ | In reply to @irenes:matrix.org
keeping things out of the store is a separate problem really i do not agree | 07:32:24 |
| jade_ | these problems are one and the same | 07:32:28 |
| @irenes:matrix.org | I mean | 07:32:30 |
| @irenes:matrix.org | it's a per-package problem | 07:32:35 |
| @irenes:matrix.org | it's not a problem with a general solution as far as I can see | 07:32:42 |
| jade_ | you could even write a deploy script that shoves them on the other box out of band | 07:32:44 |
