| 9 Jun 2025 |
|  Fernando Rodrigues joined the room. | 13:15:35 |
|  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 |
|  R̴̨͕͇͍̞̮̐̅͆̌̀̉̐͋̈́̃̀͒́̎̅̚̚̚͠͝Ĕ̵̡̛͖͖̟̙̫̱͈̘̞̭͍͍͑̌̄͑̓̋̓̀̈̏̈́͊̇͊͆̉͂̏̀̃̚͘͝͝ͅͅD̶̡̢͔̱̖̮͙͉̘̺͓͍̩̮͈͍͗̃̀̏͌͘͜ͅŚ̸̬̭̯̬͙͇͓̬̩̳̤͚͓̤̩̺͉͖̉͛̓̿̎͊̿̆́̐͂̇͌̄̇̓͘ͅͅT̴̞̫̘̝͇͔̟̪̪̦͂̔̎̀̎ͅŎ̷̡̬̹̪͈̭̣͈̭̭͉̦̖̝̘̪͖͔̥̦̘̻̳Ṋ̶̛̫͈̳̘͚̜̔̋͆̅̈́͊̑͊̉̌̈́̾͑̈́̚ͅË̸̡̨̨̛͇̜̖͔͖̻̟̗̠̙͓̘̗̥͉͇̜͑͆͊͑͑̀̓͒͜͝͝ changed their display name from Redstone to R̴̨͕͇͍̞̮̐̅͆̌̀̉̐͋̈́̃̀͒́̎̅̚̚̚͠͝Ĕ̵̡̛͖͖̟̙̫̱͈̘̞̭͍͍͑̌̄͑̓̋̓̀̈̏̈́͊̇͊͆̉͂̏̀̃̚͘͝͝ͅͅD̶̡̢͔̱̖̮͙͉̘̺͓͍̩̮͈͍͗̃̀̏͌͘͜ͅŚ̸̬̭̯̬͙͇͓̬̩̳̤͚͓̤̩̺͉͖̉͛̓̿̎͊̿̆́̐͂̇͌̄̇̓͘ͅͅT̴̞̫̘̝͇͔̟̪̪̦͂̔̎̀̎ͅŎ̷̡̬̹̪͈̭̣͈̭̭͉̦̖̝̘̪͖͔̥̦̘̻̳Ṋ̶̛̫͈̳̘͚̜̔̋͆̅̈́͊̑͊̉̌̈́̾͑̈́̚ͅË̸̡̨̨̛͇̜̖͔͖̻̟̗̠̙͓̘̗̥͉͇̜͑͆͊͑͑̀̓͒͜͝͝. | 00:55:22 |
| R̴̨͕͇͍̞̮̐̅͆̌̀̉̐͋̈́̃̀͒́̎̅̚̚̚͠͝Ĕ̵̡̛͖͖̟̙̫̱͈̘̞̭͍͍͑̌̄͑̓̋̓̀̈̏̈́͊̇͊͆̉͂̏̀̃̚͘͝͝ͅͅD̶̡̢͔̱̖̮͙͉̘̺͓͍̩̮͈͍͗̃̀̏͌͘͜ͅŚ̸̬̭̯̬͙͇͓̬̩̳̤͚͓̤̩̺͉͖̉͛̓̿̎͊̿̆́̐͂̇͌̄̇̓͘ͅͅT̴̞̫̘̝͇͔̟̪̪̦͂̔̎̀̎ͅŎ̷̡̬̹̪͈̭̣͈̭̭͉̦̖̝̘̪͖͔̥̦̘̻̳Ṋ̶̛̫͈̳̘͚̜̔̋͆̅̈́͊̑͊̉̌̈́̾͑̈́̚ͅË̸̡̨̨̛͇̜̖͔͖̻̟̗̠̙͓̘̗̥͉͇̜͑͆͊͑͑̀̓͒͜͝͝ 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 |
|  Theuni joined the room. | 14:46:09 |
| Theuni | 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 |
| Theuni | 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 |
| Theuni | m1cr0man: yeah i noticed that the container path shouldn't be special any longer with this change. | 05:06:26 |
| Theuni | but i don't have a test / environment that uses this, so happy for feedback. | 05:06:40 |
| Theuni | 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 |
| Theuni | (or well maybe it does, not sure but then it would fail due to a dependency and not an internal failure) | 06:17:38 |
| Theuni | ah but then the "inversion of control" pattern makes it ugly again. | 06:18:45 |
| Theuni | Reminder to self: overall i'm trying to get complexity and the relationships and maybe even the number of units down. | 06:31:00 |
| Theuni | One aspect: we basically need one assurance and one signal to interact with certificate consumer units (nginx, postfix, ...): | 06:31:33 |
| Theuni |
- the assurance: the files referenced in your config file are now available and are valid ssl certificates. Go forth and start!
| 06:31:58 |
| Theuni |
- 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 |
| Theuni | 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 |
