| 13 Jun 2023 |
 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 |
| emily | "N instances of this service per X period of time" | 13:23:17 |
| emily | i'm guessing systemd probably wouldn't go for that though | 13:23:22 |
