| 13 Jun 2023 |
 emily | (but we can't just switch over to caddy without breakage because of all the lego-specific config we expose...) | 20:27:30 |
 m1cr0man | yeah, sadly | 20:27:38 |
| m1cr0man | it would be a major breaking change and people hate remembering how they set their certs up (me included) | 20:28:04 |
| m1cr0man | what would we need in lego to make this better? daemonising is out of the question, but there's a lot of logic in the renew script right now that could probably go into lego. In my own head, I had some sort of logic for offline renewal check on my list of things to try and contribute that would greatly reduce the complexity on our side today. | 20:29:09 |
| emily | I suspect the majority of people don't have any of the special lego options set. but the biggest breakage would be DNS challenge setups, esp. in terms of provider availability. | 20:29:15 |
| m1cr0man | In reply to @emilazy:matrix.org
I suspect the majority of people don't have any of the special lego options set. but the biggest breakage would be DNS challenge setups, esp. in terms of provider availability. yeah lego is pretty much unmatched for DNS support | 20:29:33 |
| emily | Caddy/certmagic/etc. do actually have a backwards compatibility layer for lego's providers | 20:29:34 |
| m1cr0man | oh? | 20:29:43 |
| 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 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 |
