| 10 Oct 2024 |
 Alyssa Ross | performance will be degraged for approximately three hours while it recovers | 16:06:29 |
| Alyssa Ross | (the yellow question mark btw means that checking that branch failed, which usually means something has gone wrong on the backend) | 16:10:19 |
| 11 Oct 2024 |
|  tollb1 joined the room. | 13:21:06 |
| 12 Oct 2024 |
 ElvishJerricco | Jan Tojnar, emily: So what do we want to do about the gdm-autologin LUKS exfiltration thing? I have a working demo of the problem. | 17:35:53 |
 emily | we should decide on a fix for ourselves and write up an advisory of the vulnerability and send it to oss-security, cc'ing the arch security team, probably requesting a CVE too however that's done | 17:36:46 |
| ElvishJerricco | It's worth noting that it's a very niche problem, in the sense that the autologin'd user is almost certainly owned by the same human being who just entered the LUKS password in the first place. | 17:37:05 |
| ElvishJerricco | but yea I don't think that will affect the severity rating of it | 17:37:18 |
| emily | there are still viable threat models & niche security vulnerabilities should still be reported | 17:37:27 |
| emily | i think the CVSS probably won't be too bad but we can brainstorm it here | 17:37:34 |
| emily | I might not be able to do too much today but if you start drafting up an advisory I can probably help tomorrow | 17:37:49 |
| ElvishJerricco | but that means having to know how to write an advisory :P | 17:38:41 |
| emily | look at the calamares one :p | 17:39:54 |
| emily | I can help write it if it'd be easier, just have things on my TODO today | 17:40:28 |
| emily | remind me tomorrow maybe | 17:40:34 |
| ElvishJerricco | As for the fix for ourselves, I don't know if we should disable it by default or if we should just include a noticeable warning in whatever option description | 17:40:35 |
| emily | I think we should do both | 17:41:35 |
| emily | it's too dodgy to be leaking LUKS keys to non-root userspace | 17:41:50 |
| emily | or really to be retaining them at all in userspace after they're loaded | 17:41:59 |
| ElvishJerricco | yea that's fair | 17:42:34 |
| ElvishJerricco | actually, it makes me wonder if systemd ought to be clearing the cryptsetup keyring key before reaching sysinit.target | 17:43:07 |
| ElvishJerricco | like After=cryptsetup.target and Before=sysinit.target, have a service that removes that key | 17:43:28 |
| ElvishJerricco | because leaving that key even in the kernel keyring for an extended period of time seems a little odd to me | 17:43:48 |
| emily | it's in kernel RAM anyway right? but sure | 17:44:12 |
| ElvishJerricco | well the master key is (and can be dumped from userspace), but this is the passphrase that unwraps the master key | 17:44:34 |
| 13 Oct 2024 |
 Tristan Ross | How are hardening options enabled by default in nixpkgs? It looks like in the stdenv? | 06:34:44 |
| Tristan Ross | Interesting, it all comes from pkgs/build-support/bintools-wrapper/default.nix | 06:37:02 |
| Tristan Ross | Next question, what sort of impact on build failures could we see if we did stackclashprotection by default? | 06:37:43 |
| emily | you'd want to talk to ris | 06:47:49 |
 hexa | betterbird is on 115.9.0 on release-24.05 while master has 115.14.0, latest is 115.16.1 | 16:56:07 |
| hexa | I think it should not live in nixpkgs if this is how it gets maintained | 16:57:32 |
