| 4 Jul 2025 |
 Christian Theune | so ... anyway ... i'll have to clean this up a bit more. i'll also need to rework the locking (with systemd 258 we could leverage the slice parallel unit limits, but i'll do a small change to get rid of the static hashing from build time to put it into a runtime solution as an intermediate step) | 13:45:05 |
| Christian Theune | off from the sprint for now ... | 13:45:09 |
 emily | everything libdns supports | 14:31:00 |
| emily | it's pretty extensive | 14:31:05 |
| emily | https://github.com/orgs/libdns/repositories?type=all | 14:31:20 |
| Christian Theune | ah, that sounds interesting. ok. i'll still try to wrap up my stuff over the next days and maybe take a fresh look after. i think it was definitely worthwhile to understand what the current system does ... | 15:01:23 |
| 6 Jul 2025 |
 m1cr0man | The test suite really is the most valuable bit of the acme module at this point. If you can get everything to pass, then you can be reasonably confident there are no major regressions. | 13:12:27 |
| m1cr0man | I can't remember any concrete reason right now as to why it was introduced. Removing it may be difficult, as people definitely are using it.
I understand you are reworking this for your own use case which sounds quite complex and large-scale, but keep in mind that most people use the ACME module for the simplest of cases - they have a vhost, they set enableACME = true, and they magically have certs. Making the ACME module work for as many use cases as possible is important to reduce fragmentation in the community, but there is a limit.
I definitely think there is a solution here where we can keep the self signed cert optionality and what you are trying to do. Your primary concern seems to be around the lack of a syntactically valid cert being present for consumer services. If this option is explicitly set to false, then it can be assumed that users do not care about this guarantee.
| 13:19:06 |
| emily | the one talking about OCSP stapling is at least obsolete :) | 13:32:26 |
| 7 Jul 2025 |
| Christian Theune | m1cr0man: yeah, not breaking things by introducing my own use case is absolutely on my list. thanks for the github search ... going through the list, the use case is basically DNS-01 where you can get certificates up early. I'll ponder the optionality. Also, I can try to get in touch with the users ... so thanks again for that list. | 05:09:40 |
| 8 Jul 2025 |
| Christian Theune | One aspect about not using self-signed certificates is that dependencies become really tricky without. You could end up with services that both rely on and don't rely on self-signed certificates and then ordering needs to be to run acme orders for non-self-signed first, then start the services that depend on self-signed certificates (once all non-self-signed are there) or you end up with invalid intermediate runtime states ... 🙈 | 11:34:26 |
 Zhaofeng Li | It's okay to start them services as long as they can reload certificates automatically (or get restarted), right? There is also the need to make sure they don't get traffic until it's actually healthy | 20:16:03 |
| Zhaofeng Li | * It's okay to start the services as long as they can reload certificates automatically (or get restarted), right? There is also the need to make sure they don't get traffic until they're actually healthy | 20:16:43 |
| 9 Jul 2025 |
| Christian Theune | Well, that's the core of the issue about self-signed certificates: the services are always configured with the names of the (final) certificate names. If you have a mixture of validations using HTTP-01 then those vhosts will need self-signed certificates. If you have another set of vhosts that use DNS-01 then those don't need self signed certificates. However, if the DNS-01 ones are then configured without self-signed certificates, then the server can't start at all unless the DNS-01 has been successfully validated. That also means that any errors in the DNS-01 verifications will completely block starting the server unless that is fixed. | 07:12:47 |
| Christian Theune | From my experience, this kind of dependencies quickly leads to an operational nightmare when something goes unexpectedly wrong. Designing for a "everything is sunny in california" environment doesn't resonate very well with me. Especially because the complexity is getting so high that making predictions about reliability and not forgetting some corner case is becoming impossible. | 07:14:07 |
| Christian Theune | IMHO the overall design would be much better off if we ripped out the "no self signed certificates" knob ... | 07:14:41 |
| Christian Theune | This will let us have a single straight path in the dependencies to ensure servers come up somehow and then let users deal with partial degradations instead of complete failure that then becomes impossible to fix because of opposing dependencies. | 07:15:46 |
| Christian Theune | m1cr0man: Just to make sure: I completely agree with the tradeoffs you mention regrading community needs. I've read through the original PR that introduces the knob (https://github.com/NixOS/nixpkgs/pull/15562) and I see that it was kind of a given to use a knob - this has been 9 years ago and I think we were in a state of expansion on ACME capabilities back then. From todays perspective I don't see a strong reason to support turning it off as it's such a core case of people using HTTP-01... | 07:27:33 |
| Christian Theune | oooh, and the management of ownership/permissions in the .lego/ directory is inconsistent. it partially wants 600 for the files (and verifies that in a test) but then again the setup script broadly sets them back to 640 | 09:33:41 |
| Christian Theune | but the tests never saw that due to selective permission checking. | 09:33:56 |
| Christian Theune | I'd say keeping the files consistently on 640 with the right group is fine ... ? | 09:34:14 |
| Christian Theune | not sure why we'd go to the extra lengths of having them 600 and 640 ... | 09:34:27 |
| m1cr0man | Where is it inconsistent exactly? I don't remember all the permissions checks | 19:43:33 |
| m1cr0man | Sure, I'm sold :) | 19:47:44 |
|  alina arielle amelie🏳️⚧️🐾 changed their profile picture. | 21:01:28 |
| alina arielle amelie🏳️⚧️🐾 changed their display name from alina to alina arielle amelie🏳️⚧️🐾. | 21:02:13 |
| 10 Jul 2025 |
| Christian Theune | finally ... i got all tests working. one last cleanup regarding the lock handling, but then I should be ready for more eyes ... | 09:39:08 |
| Christian Theune | alright ... m1cr0man emily if you'd like to take a look https://github.com/NixOS/nixpkgs/pull/422076 is now ready. it's a lot more changes than I anticipated and I really tried my best to keep it down. | 12:43:41 |
| Christian Theune | hexa: if you have oppinions, then I'm all ear, too. | 12:43:59 |
| Christian Theune | Arian: and you taking another look is of course appreciated as well | 12:44:17 |
