| 25 Oct 2023 |
 K900 | https://github.com/NixOS/nixpkgs/pull/263317 kernel update with a potentially pretty spooky KVM vuln | 11:07:42 |
| K900 | https://www.phoronix.com/news/X.Org-Halloween-Bugs-2023 and a bunch of X11 vulns because duh | 11:19:48 |
| K900 | @Artturin what's the status on the X11 untangling PR? | 11:20:09 |
 Artturin | In reply to @k900:0upti.me
https://www.phoronix.com/news/X.Org-Halloween-Bugs-2023 and a bunch of X11 vulns because duh Haven't started manual moving so just update like normal | 17:26:58 |
| 26 Oct 2023 |
|  @lotte:chir.rs changed their profile picture. | 06:50:34 |
 felschr | https://github.com/NixOS/nixpkgs/pull/263399
https://github.com/NixOS/nixpkgs/pull/263401 | 12:17:26 |
|  streets joined the room. | 12:33:50 |
| felschr | PRs now have one approval each | 21:44:21 |
| 27 Oct 2023 |
|  @federicodschonborn:matrix.org changed their profile picture. | 01:24:45 |
 vcunat | In reply to @k900:0upti.me
https://www.phoronix.com/news/X.Org-Halloween-Bugs-2023 and a bunch of X11 vulns because duh I wonder how bad they are - rebuilds vs. speed of update:
https://github.com/NixOS/nixpkgs/pull/263689#issuecomment-1782340466 | 06:15:31 |
| 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 |
