| 3 Jan 2022 |
 Winter (she/her) | Sure, will do. | 14:02:25 |
 m1cr0man | V curious to know what the answer is. Acme isn't the only module that is a dependency in other modules (namely I'm thinking of all the services that can auto configure virtual hosts). There doesn't seem to be a set place for these sort of helpers right now | 14:04:23 |
| Winter (she/her) | In reply to @m1cr0man:m1cr0man.com
V curious to know what the answer is. Acme isn't the only module that is a dependency in other modules (namely I'm thinking of all the services that can auto configure virtual hosts). There doesn't seem to be a set place for these sort of helpers right now The answer is that the solution I described (moving acme.nix to acme/default.nix and making a new file with the function in it to import) is fine, and is apparently how problems like this are currently handled in tree. | 14:55:26 |
| Winter (she/her) | I’ll try to get a patch out tonight. | 14:55:43 |
| 4 Jan 2022 |
 hexa | acme inside nixos containers are a temporary lookup failure waiting to happen | 19:35:31 |
| hexa | * acme (dns01) inside nixos containers are a temporary lookup failure waiting to happen | 19:52:14 |
| 6 Jan 2022 |
| Winter (she/her) | m1cr0man: I promise I haven't forgotten about the assertions, it's just been a long week and want to do this the right way. If not sometime this week, I'll get a PR open this weekend. My apologies! | 03:24:19 |
| m1cr0man | In reply to @winterqt:nixos.dev
m1cr0man: I promise I haven't forgotten about the assertions, it's just been a long week and want to do this the right way. If not sometime this week, I'll get a PR open this weekend. My apologies! Yeah don't worry about it! First week of a new year is always a busy one, I doubt I'd have time to review until the weekend anyway 😅 | 07:00:30 |
| 8 Jan 2022 |
| Winter (she/her) | https://github.com/NixOS/nixpkgs/pull/153942 | 03:45:48 |
| Winter (she/her) | there we go! | 03:45:51 |
| Winter (she/her) | I also have a very small documentation change I wanna get in at some point, but I'll probably wait till this lands. | 03:47:32 |
| Winter (she/her) | * I also have a very small documentation change I wanna get in at some point, but I'll probably wait till this lands. (It's not related to this, else I'd sneak it into here.) | 03:47:46 |
| Winter (she/her) | m1cr0man: Sorry about that — I know we did have that conversation so I have no clue how that slipped my mind.
However, this is now a bit more complicated, and I’m not really sure what the best way to proceed is. Ideally, the assertion would handle both the case where only a single service is using the certificate (where the original assertion would work), and when multiple services are using it (this would check the members of the acme group). But I’m not really sure how to make it handle both since there’s no way we can track the number of usages of a certificate in a configuration. Do you have any ideas? | 15:29:51 |
| Winter (she/her) | Of course, we could just enforce using the acme group, but that would break existing manual configurations (like the one I currently use, for example), so that’s not ideal. | 15:38:18 |
| m1cr0man | So my thought was that you could simply check that a service' user is in the assigned group, as per that feature I was questioning before. So I think this would work (OR'd with the current assertion)
builtins.any (v: v == config.services.nginx.user) config.users.groups.${config.security.acme.certs.${certName}.group}.members
| 16:13:15 |
| m1cr0man | (Completely untested, I just wrote that in element as-is ;) ) | 16:13:31 |
| m1cr0man | not I'm not assuming the acme group was used for the cert, even. I can imagine someone assigning a group at some stage, later needing to use the certs for another service, and assigning that new service's user to whatever group was assigned to the cert (aka, being lazy and not standardising on the acme group) | 16:15:59 |
| Winter (she/her) | Oh, that’s… much simpler than what I was thinking. | 16:18:27 |
| Winter (she/her) | I have absolutely no clue how I didn’t think of that 🤦♀️ | 16:18:41 |
| Winter (she/her) | Sorry about that | 16:18:49 |
| Winter (she/her) | * Oh, that’s… much simpler than what I was thinking (and much more obvious). | 16:19:18 |
| Winter (she/her) | * Sorry about that! | 16:19:27 |
| m1cr0man | Hah no bother! 😅 I mean, it's not that simple really, there's a lot of nesting there, and a lot of background info required | 17:01:36 |
| m1cr0man | Winter (she/her) sorry meant to approve that earlier in the night but done now, nice job | 23:04:53 |
| Winter (she/her) | you did half of the work tbh, but thanks! | 23:05:18 |
| 9 Jan 2022 |
| m1cr0man | Aaaand I'm finally using wildcard certs for my own domain, lol. It sounds kinda bad given I maintain it, but really I was maintaining a much larger system using acme + DNS challenges up until last year | 01:20:40 |
| 10 Jan 2022 |
| m1cr0man | whOOOps. I was today years old when I learned that a wildcard cert would not actually cover the root of the domain :P Matrix synapse silently broke overnight, since everyone started rejecting my domain | 19:24:44 |
| Winter (she/her) | Oh yeah I learned that too lol, I just changed to adding the wildcard to extraDomains and keeping it named the root domain | 19:40:37 |
| Winter (she/her) | Very fun | 19:40:43 |
| hexa | In reply to @m1cr0man:m1cr0man.com
whOOOps. I was today years old when I learned that a wildcard cert would not actually cover the root of the domain :P Matrix synapse silently broke overnight, since everyone started rejecting my domain you mean … the origin? | 20:11:18 |
