Sender | Message | Time |
---|---|---|
13 Jun 2023 | ||
emily | and probably the most first party DNS providers outside of lego too (https://github.com/libdns) | 20:29:51 |
m1cr0man | oh. wow | 20:30:34 |
emily | https://github.com/caddy-dns/lego-deprecated is the shim | 20:31:07 |
Arian | I think cert-manager comes close. But it requires Kubernetes | 20:34:12 |
Arian | It does all the queueing and concurrency stuff | 20:34:49 |
m1cr0man | ugh jeez | 20:37:19 |
emily | I think Caddy would be an easier sell than Kubernetes at least :P | 20:40:27 |
emily | (but also I don't think we should rush into any major change; we've had this setup - which is janky in many ways because of lego's insufficiencies but works fine in most cases and is much better than the old simp_le one - for years, we can afford to stew on what we actually want to do and how much it would improve things for us. I'm personally sick of lego but maybe we can make it work and even if we can't it will pay to do a lot of assessment and testing of any potential replacement before making any moves. the worst thing we can do is tell people we're making things better with some one-time transition pain and then we just get a new set of problems or even end up migrating again.) | 20:45:23 |
emily | (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)) | 20:48:06 |
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 | 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(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 |
| 13:26:26 |
hexa | In reply to @hexa:lossy.networksame as here 🥳 | 13:26:38 |
hexa | saved to https://gist.github.com/mweinelt/0bf207904ea0a32e30f0aadd3e0b1bba | 13:27:07 |
ribosomerocker joined the room. | 16:40:24 |