| 10 Feb 2022 |
 Winter (she/her) | seems like no solution is | 04:42:50 |
| Winter (she/her) | which is what i'm complaining about, lol
isn't ideal but it's what we have, ig | 04:43:10 |
| Winter (she/her) | the SSH certificate thing looks cool, i'll definitely look into it -- how do you handle stuff like Git forges who won't trust CAs, tho? do you just have a key for those? | 04:44:23 |
 Zhaofeng Li | For the random software problem, perhaps we need stronger compartmentization between applications, like in Qubes and lately SpectrumOS (with Nix) | 04:44:48 |
| Zhaofeng Li | In reply to @winterqt:nixos.dev
the SSH certificate thing looks cool, i'll definitely look into it -- how do you handle stuff like Git forges who won't trust CAs, tho? do you just have a key for those? True, for those use cases you would still need a regular key đ | 04:45:38 |
| Winter (she/her) | how well does Vault work as a CA, btw? | 04:56:30 |
| Zhaofeng Li | In reply to @winterqt:nixos.dev
how well does Vault work as a CA, btw? Fairly usable I'd say. The user experience is slightly awkward for the client certificate, because you pretty much need a helper script or alias to avoid typing the long vault ssh ... or vault login && vault write ... && ssh incantation | 05:10:23 |
| Zhaofeng Li | I followed this blog post for the setup: https://brian-candler.medium.com/using-hashicorp-vault-as-an-ssh-certificate-authority-14d713673c9a | 05:11:35 |
| Winter (she/her) | hm, neat. | 13:33:51 |
 @github:maunium.net | [zhaofengli/colmena] pinpox opened
issue
#57: Option to remove secrets
Would it be possible to add some mechanism to remove secrets when they are removed from the configuration?
Consider two configured secrets like this:
keys = {
"test-secret1" = {
keyCommand = [ "pass" "show" "nixos-secrets/ahorn/borg/passphrase" ];
destDir = "/var/src/colmena-keys";
};
};
| 14:01:20 |
| @github:maunium.net | [zhaofengli/colmena] pinpox edited
issue
#57: Option to remove secrets
| 14:03:44 |
| @github:maunium.net | [zhaofengli/colmena] pinpox edited
issue
#57: Option to remove secrets
| 14:06:04 |
|  pinpox joined the room. | 14:16:35 |
| pinpox | Whops, sorry for the "edited issue.." spam. | 14:17:32 |
| pinpox | Hey, does anyone have a solution on how to make sure secrets no longer present in deployment.keys are deleted? | 16:03:29 |
| pinpox | Can I use system.activationScripts for it? | 16:03:42 |
 Jane Jasperous | Maybe you can deploy into tmpfs and use impermanence module | 16:11:53 |
| Zhaofeng Li | In reply to @pinpox:matrix.org
Can I use system.activationScripts for it? I commented with a potential solution. | 18:57:37 |
| Zhaofeng Li | In reply to @pinpox:matrix.org
Whops, sorry for the "edited issue.." spam. No worries - I'm planning to replace the bot regardless since it's pretty spammy even in the normal case (3 link previews for a message) | 18:58:17 |
| 11 Feb 2022 |
| pinpox | Zhaofeng Li: Just saw it, thank you! | 07:43:22 |
| pinpox | That is a possible solution, but wouldn't it be nice to have an option to execute commands preo/post deployment anyways? I imagine that could come in handy regardless of secrets | 07:44:10 |
|  Chinchilla Washington joined the room. | 07:51:13 |
| @github:maunium.net | [zhaofengli/colmena] Repo forked into lheckemann/colmena | 14:41:31 |
| @github:maunium.net | [zhaofengli/colmena] lheckemann opened
pull request
#58: streaming evaluator: respect eval-nodes-limit
| 14:42:02 |
| @github:maunium.net | [zhaofengli/colmena] lheckemann edited
pull request
#58: streaming evaluator: respect eval-nodes-limit
| 14:42:51 |
| Winter (she/her) |
// FIXME: nix-eval-jobs currently does not support IFD with builders
What are the implications of this, and how would it be fixed? | 15:28:31 |
| Winter (she/her) | additionally: won't https://github.com/zhaofengli/colmena/blob/f674ddf1739aa79ac9dcad38771cc89c662eaa6a/src/nix/deployment/mod.rs#L539 always be false if the configuration was built on the target? | 15:41:50 |
| Zhaofeng Li | In reply to @winterqt:nixos.dev
// FIXME: nix-eval-jobs currently does not support IFD with builders
What are the implications of this, and how would it be fixed? Import From Derivation is when you do import (some derivation) to use the results of a derivation during evaluation, meaning that the normally platform-agnostic evaluation process now requires building a derivation which is platform-specific. In order to build foreign derivations for IFD using configured builders, I normally pass --options builders to nix-instantiate. | 21:01:17 |
| Zhaofeng Li | However, this is disabled in nix-eval-jobs for some magical reason âšī¸ https://github.com/nix-community/nix-eval-jobs/blob/a08cada21d1c2eb6a49e39da4ad83d0557cb88b2/src/nix-eval-jobs.cc#L291-L292 | 21:01:35 |
| Zhaofeng Li | I presume Mic92 didn't dig in deeper and more investigation is needed. This means IFD with foreign derivations won't work with nix-eval-jobs unless you set up binfmt so the local machine can build them without using builders (not possible on macOS). | 21:03:19 |
