| 13 Jun 2023 |
 m1cr0man | Yeah, I fully agree, and I'm in no rush too. If we make a migration again, it has to be done with a lot of research + evaluation.
Wrt caddy modules, that seems easy enough to solve through the same system we have right now for lego where user specifies dnsProvider and then, like the filesystems options, we can introduce the appropriate modules as necessary. Do they have to be compiled in or are they dynamically loaded?
| 20:49:32 |
|  K900 changed their display name from K900 to K900 (Old). | 20:50:10 |
| m1cr0man | Oh also as for my stance on lego... I don't totally hate it, I mean it works for small and medium scale deployments, but I do agree that there could be a better solution out there that is simpler for us to implement. I'm just not convinced it's worth passing the pain to the module users yet. | 20:50:54 |
 emily | they are compiled in and it runs into Go module hash issues :P we have an open issue in nixpkgs for making that nicer for web server cases but I think it's basically going to come down to "call some derivation, pass in the modules you need, fill in a hash". obviously we can't provide an upstream hash for every combination of DNS providers people could use so in that case we should probably just provide a prebuilt package that bundles them all. | 20:53:29 |
| m1cr0man | oh I see right | 20:53:55 |
| emily | (it's literally just "they have a tool that fills out a Go file with all the package imports you list and a main that just calls into Caddy's main and compiles and runs that", so you can also just supply your own main.go) | 20:54:01 |
| emily | I do think that if we do any migration we should have a structured interface for DNS providers and name the escape hatch for unsupported ones something like customDnsProviderSettingsThisWillBreakHereBeDragonsNoWarranty :V | 20:55:05 |
| emily | but it will be annoying to support them all (actually we could probably generate them automatically since Caddy already has a standardized structured configuration interface that all the providers declare their setting names/types with but that's its own bikeshed) | 20:55:28 |
| m1cr0man | I was thinking/hoping we could generate them yeah :) | 20:55:44 |
| emily | In reply to @emilazy:matrix.org
(in terms of "ACME quality of implementation and best operational practices" I think Caddy has very few competitors and would solve a lot of our problems; we can start up a single long-running daemon and get rid of basically all our gross shell logic. but it's not all sunshine and roses; for one thing, using DNS providers would require us to have a story for Caddy modules (though we could probably just build a mega-ACME-Caddy with all the first-party providers out of the box), and also you can certainly do better in terms of hardening (Go is memory safe, but AFAIK there's no privilege separation going on: it's possible that exploits could leak private key material through confused deputy or Go runtime exploits)) (another caveat is no multiple-SAN certificates which I forget if we even support and are not considered best practice (cf. https://github.com/https-dev/docs/blob/a00aed0ec4a6e7963fde33aeda725209bfa4a89d/acme-ops.md#use-one-name-per-certificate from the developers). but if we do support them I'm sure somebody is using them.) | 20:59:39 |
| m1cr0man | oh, no we use SANs quite a bit. extraDomainNames puts them all in as SANs effectively. For example nginx does it by default https://github.com/NixOS/nixpkgs/blob/nixos-unstable/nixos/modules/services/web-servers/nginx/default.nix#L1293 | 21:15:50 |
|  K900 (deprecated) joined the room. | 21:36:39 |
| emily | we should probably consider not doing it by default :) | 21:50:27 |
| emily | but that's another matter | 21:50:30 |
| 15 Jun 2023 |
| K900 (deprecated) | https://hydra.nixos.org/build/224218205 | 13:16:42 |
| K900 (deprecated) | Test failed again | 13:16:44 |
| K900 (deprecated) | Not restarting cause there's multiple evals queued after that already | 13:17:03 |
 hexa |
Test "Can request certificate with Lego's built in web server" failed with error: "unit "acme-finished-http.example.test.target" is inactive and there are no pending jobs"
| 13:26:26 |
| hexa | In reply to @hexa:lossy.network
Test "Can request certificate with Lego's built in web server" failed with error: "unit "acme-finished-http.example.test.target" is inactive and there are no pending jobs"
same as here 🥳 | 13:26:38 |
| hexa | saved to https://gist.github.com/mweinelt/0bf207904ea0a32e30f0aadd3e0b1bba | 13:27:07 |
|  ribosomerocker joined the room. | 16:40:24 |
| 19 Jun 2023 |
 Arian | https://github.com/systemd/systemd/issues/28075 | 10:43:36 |
| emily | heh, convenient | 10:56:36 |
 raitobezarius | systemd folks seemed more interested to implement this via implementing service limits on a slice | 13:02:23 |
| emily | on the issue or through your own communication with systemd people? | 13:10:33 |
| emily | I think on the issue we were just pushing back on "more bespoke complexity in the service scripts" by all means necessary :p | 13:10:49 |
| raitobezarius | on the systemd dev chat | 13:12:04 |
| raitobezarius | s/systemd folks/poettering | 13:12:24 |
| emily | right | 13:22:29 |
| emily | In reply to @m1cr0man:m1cr0man.com
okay yeah, so these are pretty lenient for most people. I think I was only concerned about the concurrent one that the ticket opener mentioned:
the “new-nonce”, “new-account”, “new-order”, and “revoke-cert” endpoints on the API have an Overall Requests limit of 20 per second.
Right now this one is very easy to do
tbh given ^ and the other limits we discussed at that time, some kind of time-based limits might be what we'd really want | 13:23:05 |
