| 9 Jun 2025 |
|  Spaenny changed their display name from Spaenny to Philipp. | 20:46:49 |
| 12 Jun 2025 |
|  sugi changed their profile picture. | 11:48:58 |
| 27 Jun 2025 |
|  redstone-menace changed their display name from Redstone to R̴̨͕͇͍̞̮̐̅͆̌̀̉̐͋̈́̃̀͒́̎̅̚̚̚͠͝Ĕ̵̡̛͖͖̟̙̫̱͈̘̞̭͍͍͑̌̄͑̓̋̓̀̈̏̈́͊̇͊͆̉͂̏̀̃̚͘͝͝ͅͅD̶̡̢͔̱̖̮͙͉̘̺͓͍̩̮͈͍͗̃̀̏͌͘͜ͅŚ̸̬̭̯̬͙͇͓̬̩̳̤͚͓̤̩̺͉͖̉͛̓̿̎͊̿̆́̐͂̇͌̄̇̓͘ͅͅT̴̞̫̘̝͇͔̟̪̪̦͂̔̎̀̎ͅŎ̷̡̬̹̪͈̭̣͈̭̭͉̦̖̝̘̪͖͔̥̦̘̻̳Ṋ̶̛̫͈̳̘͚̜̔̋͆̅̈́͊̑͊̉̌̈́̾͑̈́̚ͅË̸̡̨̨̛͇̜̖͔͖̻̟̗̠̙͓̘̗̥͉͇̜͑͆͊͑͑̀̓͒͜͝͝. | 00:55:22 |
| redstone-menace changed their profile picture. | 00:56:28 |
| 30 Jun 2025 |
 emily | We have deleted the email addresses provided to Let’s Encrypt via the ACME API that were stored in our CA database in association with issuance data. This doesn’t affect addresses signed up to mailing lists and other systems. They are managed in a separate ISRG system unassociated with issuance data.
Going forward, if an email address is provided to Let’s Encrypt via the ACME API, Let’s Encrypt will not store the address but will instead forward it to the general ISRG mailing list system unassociated with any account data. If the email address has not been seen before, that system may send an onboarding email with information about how to subscribe to various sources of updates.
| 12:49:54 |
| emily | https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended/ | 12:49:56 |
| emily | we currently require email right? could probably stop | 12:50:01 |
 hexa | if lego is ok with that | 14:13:52 |
| 3 Jul 2025 |
| hexa | https://github.com/go-acme/lego/issues/277 | 14:46:03 |
|  Christian Theune joined the room. | 14:46:09 |
| Christian Theune | I'm working on a bit of a refactoring with Arian supervising. I've had a question this morning which I managed to solve with a draft so far. I'm still working on it, but the current state is here: https://github.com/NixOS/nixpkgs/pull/422076. The second commit is currently in draft and needs a further refactoring (and also has a race condition and is likely incomplete), but I have to stop working for today). If you want to take a look, feel free to give feedback. I'm also happy to explain/discuss things face to face if that helps understanding. It's a quite complicated situation and I'm trying to make it cleaner ... | 14:48:16 |
| hexa | an acme-renew unit cannot work, when the initial run did not succeed 🤔 but since the failure of the run might be transient having a combined unit that makes the run vs renew decision makes sense | 14:57:35 |
| hexa | * an acme-renew unit on a timer cannot work, when the initial run did not succeed 🤔 but since the failure of the run might be transient having a combined unit that makes the run vs renew decision makes sense | 14:57:46 |
|  @alina:catgirl.cloud joined the room. | 16:15:22 |
|  Alyssa Ross joined the room. | 16:34:34 |
 Arian | We could have the .timer have a Requires=acme-order-XX.service then it wont start the timer if the initial run did not succeed | 16:56:39 |
 m1cr0man | If this ends up working, it will probably solve the long standing issue of s-t-c in containers nuking the startup if the network isn't online | 22:00:48 |
| m1cr0man | * If this ends up working, it will probably solve the long standing issue of boot in containers nuking the startup if the network isn't online | 22:00:54 |
| 4 Jul 2025 |
| Christian Theune | hexa: the combined unit is cause for a lot of complexity with drawbacks, so i'm trying to get it working with separate units. what's the concern that the renew unit won't work? if the order unit fails then that is something that needs to be handled in the order unit... | 05:05:55 |
| Christian Theune | m1cr0man: yeah i noticed that the container path shouldn't be special any longer with this change. | 05:06:26 |
| Christian Theune | but i don't have a test / environment that uses this, so happy for feedback. | 05:06:40 |
| Christian Theune | Arian: yeah, i could upgrade the wants/after to requires, so a failed order unit won't trigger a subsequent renewal failure | 06:17:16 |
| Christian Theune | (or well maybe it does, not sure but then it would fail due to a dependency and not an internal failure) | 06:17:38 |
| Christian Theune | ah but then the "inversion of control" pattern makes it ugly again. | 06:18:45 |
| Christian Theune | Reminder to self: overall i'm trying to get complexity and the relationships and maybe even the number of units down. | 06:31:00 |
| Christian Theune | One aspect: we basically need one assurance and one signal to interact with certificate consumer units (nginx, postfix, ...): | 06:31:33 |
| Christian Theune |
- the assurance: the files referenced in your config file are now available and are valid ssl certificates. Go forth and start!
| 06:31:58 |
| Christian Theune |
- the signal: the content of the files has changed and you likely want to reload/restart to pick up the new content.
| 06:32:22 |
| Christian Theune | The assurance doesn't really even have to be a valid/current/... acme certificate, but basically something that allows the service to start (e.g. the self signed certificates or maybe even an outdated acme cert). | 06:32:53 |
| Christian Theune | Which is already used for things like allowing bootstrapping the infrastructure to answer HTTP-01. | 06:33:46 |
