10 Oct 2024 |
f0x | ah, I noticed it on search.nixos.org, so probably just hydra then? | 11:06:19 |
hexa | Download image.png | 11:06:56 |
f0x | oh I got confused by the differences in versions across releases, it's just firefox-devedition-bin that's still on 131.0b9 | 11:09:11 |
hexa | oh, we have those as well? sigh | 11:09:34 |
hexa | I didn't know | 11:09:49 |
| p4cmanus3r joined the room. | 13:26:30 |
Alyssa Ross | In reply to @hexa:lossy.network cc Alyssa Ross fixed | 16:03:52 |
Alyssa Ross | (thanks for telling me) | 16:04:30 |
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 |