| 27 Oct 2023 |
K900 | Huh | 06:16:41 |
K900 | Why does xserver have 2k reverse-dependencies | 06:16:50 |
K900 | /me checks | 06:18:15 |
K900 | OK great it's not xserver | 06:23:06 |
K900 | It's luit -> xterm -> 800+ individual packages | 06:23:13 |
K900 | (wat) | 06:23:14 |
K900 | As far as I can tell the luit update is not security | 06:24:44 |
hexa | open-vm-tools
https://www.openwall.com/lists/oss-security/2023/10/27/1
https://www.openwall.com/lists/oss-security/2023/10/27/2 | 10:52:49 |
raboof | https://www.cve.org/CVERecord?id=CVE-2023-46604 | 15:11:17 |
hexa | In reply to @raboof:matrix.org https://www.cve.org/CVERecord?id=CVE-2023-46604 https://github.com/NixOS/nixpkgs/pull/263804 | 15:12:35 |
| 29 Oct 2023 |
| zzywysm joined the room. | 00:08:43 |
ris_ | libsass has 3 unfixed vulnerabilities https://nvd.nist.gov/vuln/detail/CVE-2022-26592 https://nvd.nist.gov/vuln/detail/CVE-2022-43357 https://nvd.nist.gov/vuln/detail/CVE-2022-43358. they're all stack overflows, so likely not more than a DoS. but upstream states that libsass is deprecated & unmaintained, so that makes me feel we should knownVulnerabilities them - but it would break a number of packages | 14:25:11 |
hexa | "break" | 14:26:59 |
hexa | I get your point, but I think setting meta.knownVulnerabilities is the correct move and then users can decide to allow it | 14:28:05 |
ris_ | yeah i guess my only hesitation is how knownVulnerabilities puts dependent packages off our radar for spotting further breakages (via hydra and nixpkgs-review), which can be a death sentence | 14:35:14 |
hexa | if noone cares for them (upstream and/or downstream) that is a reasonable outcome | 14:36:14 |
hexa | I think best case we can ping every maintainer of affected packages, and make sure they take this upstream | 14:36:43 |
ris_ | or remove the dependency if it's trivial/optional | 14:38:52 |
ris_ | of course, npm packages will be bundling it for years to come | 14:39:15 |
ris_ | gtk3 and gtk4 depend on saasc :) | 15:26:36 |
ris_ | it's not clear if libsass has any existing mechanism to limit stack depth | 15:29:49 |
ris_ | aha https://github.com/sass/libsass/blob/2102188d21d2b7577c2b3edb12832e90786a2831/src/eval.cpp#L961 | 15:31:11 |
ris_ | looks like the problem is it's building a circular reference during the parse phase and then recursing into that via the has_real_parent_ref methods | 18:12:49 |
ris_ | i think the reference cycle gets completed at https://github.com/sass/libsass/blob/2102188d21d2b7577c2b3edb12832e90786a2831/src/ast_selectors.cpp#L1032 | 18:35:06 |
ris_ | in other news i think we're going to have to mark freeimage as vulnerable to a bunch of things too | 19:18:22 |
| SomeoneSerge (matrix works sometimes) changed their display name from SomeoneSerge (UTC+1) to SomeoneSerge (UTC+2). | 22:41:25 |
| 30 Oct 2023 |
| zzywysm set a profile picture. | 14:27:04 |
| toonn changed their profile picture. | 19:51:20 |
| 31 Oct 2023 |
ris_ | what do people think about https://github.com/NixOS/nixpkgs/pull/264226 and marking it with knownVulnerabilities (and by extension hylafax+) | 21:55:16 |
| 1 Nov 2023 |
| cafkafk left the room. | 10:41:33 |