| 2 Oct 2024 |
|  tlaurion aka Insurgo [UTC-4] changed their display name from tlaurion aka Insurgo [UTC-4] (🛫🗺️🛬: Back 2024-10-01) to tlaurion aka Insurgo [UTC-4]. | 12:42:36 |
| 3 Oct 2024 |
 ElvishJerricco | emily: point was that you'd do your idea of storing per generation secrets in terms of their names, along with a store of name -> secret. That way any generation always gets the most up to date version of the secret for the name. But if the name changes, the old generation still gets whatever was stored for the old name | 18:02:39 |
 emily | (wrong emily :) ) | 18:03:02 |
| ElvishJerricco | damn autocorrect | 18:03:09 |
| emily | I don't think it's intuitive that the name is semantically relevant in a way that is dependent on previous generations | 18:03:24 |
| ElvishJerricco | * damn autocorrect autocomplete (that one was autocorrect) | 18:03:27 |
| emily | that's both a weird CVS-like model for versioning, and totally inconsistent with how NixOS configurations work in general | 18:03:38 |
| emily | you can at least explain the current model in terms of being a total hack that violates the model, which it is | 18:03:50 |
| ElvishJerricco | yea, I know it's more confusing, which is a good argument against it | 18:04:03 |
| emily | I don't think you can get anyone to expect that renaming their SSH host key affects the security properties of a rollback | 18:04:14 |
| ElvishJerricco | and you've made a fairly convincing point about generational secrets not being such an issue because rollbacks are always a security risk | 18:04:40 |
| ElvishJerricco | but I'm still convinced I don't want encrypted secrets in the store | 18:05:12 |
| ElvishJerricco | like, if encrypted forms of someone's iCloud photo library were publicly accessible on Apple's servers, I think they'd be rightly criticized for the leak, even if the files are hopefully useless | 18:05:57 |
| ElvishJerricco | and of course in the case of agenix that's more analogous to publishing your git repo with your age encrypted secrets in it to github (which many people do) rather than being readable by all users on one system | 18:06:46 |
| emily | people with that level of paranoia shouldn't let other users access the host filesystem, though | 18:07:19 |
| emily | anyway, I think it makes more sense to let the TPM handle all key management if possible rather than wrapping keys with TPM keys | 18:07:30 |
| emily | for preventing post-boot leaks, that's why you can use the TPM to make key access conditional on the stage of boot, right? | 18:07:42 |
| emily | (I haven't actually worked with TPM2 because the API is awful to me, but I believe this is meant to be part of the capabilities.) | 18:08:01 |
| ElvishJerricco | yes but nixos doesn't implement that right now because systemd wants you to be booting ukis for their tpm stuff to work | 18:08:34 |
| emily | well, so we fix that and then kill off initrd secrets :) | 18:08:52 |
| ElvishJerricco | meh | 18:09:01 |
| ElvishJerricco | initrd secrets are useful | 18:09:06 |
| emily | nobody should be relying on any of this for security without secure boot anyway | 18:09:09 |
| ElvishJerricco | There are things to use initrd secrets for, like clevis JWTs, and I'm still unconvinced that it's ok to just toss them in the store. | 18:09:59 |
| ElvishJerricco | now, we could implement it way better, but that's another matter | 18:10:57 |
| emily | worth nothing that e.g. WebAuthn depends on shipping around blobs of secure element-encrypted private keys | 18:11:29 |
| emily | * worth noting that e.g. WebAuthn depends on shipping around blobs of secure element-encrypted private keys | 18:11:33 |
| ElvishJerricco | I need to learn more about how WebAuthn actually works... | 18:12:24 |
