| 13 Jun 2023 |
 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 |
