| 13 Jun 2023 |
 m1cr0man | I was thinking we could use unit retry logic + ConditionPathExists for really easy locking and semaphores | 20:24:44 |
 emily | maybe I'm missing some verbiage that applies it's restart-specific but it seems to mostly note that as a side thing? | 20:25:27 |
| m1cr0man | afaik "Units which are started" means "for each unit started" rather than "for all units started", so dynamic services would all be individual services and have their own startlimits | 20:25:31 |
| emily | but I have a suspicion that it may treat all @ unit instantiations as separate in which case it wouldn't help us anyway. sigh, ACME issuance should really be handled as a daemon | 20:25:52 |
| m1cr0man | yarp | 20:26:02 |
| m1cr0man | at what point do I just right NixCerts-rs | 20:26:15 |
| m1cr0man | * at what point do I just write NixCerts-rs | 20:26:19 |
| emily | we are constantly trying to piece together what would be pretty simple logic for a long-running daemon out of paperclips and tape | 20:26:31 |
| emily | heh, I don't envy anyone trying to implement ACME from scratch | 20:26:51 |
| m1cr0man | ... maybe we need an RFC, to propose a new solution for acme | 20:27:00 |
| emily | something with certmagic would probably be pretty easy to do | 20:27:11 |
| 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 |
