2025-11-03 00:49:59 <ikke> https://lists.x.org/archives/xorg-announce/2025-October/003635.html
2025-11-03 00:50:06 <ikke> security advisory
2025-11-08 12:34:55 <omni> perhaps these patches could be easy to backport to our stable releases https://github.com/dolphin-emu/dolphin/pull/13443/commits
2025-11-11 10:39:19 <omni> not sure when I'll be able to dig deeper into !92874 / #17683 anyone is welcome to help out / take over (and I don't care about credit but getting it fixed)
2025-11-12 16:16:16 <Minus888> Hi Alpine Security team,
2025-11-12 16:16:16 <Minus888> (e.g. https://security.alpinelinux.org/srcpkg/supervisor
2025-11-12 16:16:16 <Minus888> The website currently associates CVE-2023-27482 with the source package “supervisor”
2025-11-12 16:16:16 <Minus888> “supervisor · CVE-2023-27482”). This appears incorrect.
2025-11-12 16:16:16 <Minus888>  and branch views showing
2025-11-12 16:16:18 <Minus888> CVE-2023-27482 is an authentication bypass in Home Assistant Supervisor,
2025-11-12 16:16:18 <Minus888> not the UNIX process-control tool “supervisor”.
2025-11-12 16:16:20 <Minus888> Upstream references:
2025-11-12 16:16:20 <Minus888> NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-27482
2025-11-12 16:16:22 <Minus888> Impact per upstream:
2025-11-12 16:16:22 <Minus888> Home Assistant disclosure: https://www.home-assistant.io/blog/2023/03/08/supervisor-security-disclosure/
2025-11-12 16:16:24 <Minus888> Affects Home Assistant Supervisor ≤ 2023.01.1
2025-11-12 16:16:24 <Minus888> Not related to the process-control “supervisor” package
2025-11-12 16:16:26 <Minus888> Request:
2025-11-12 16:16:26 <Minus888> Fixed in Supervisor 2023.03.1 / Core 2023.3.0+
2025-11-12 16:16:28 <Minus888> Please remove the linkage from the Alpine “supervisor” package and mark it as
2025-11-12 16:16:28 <Minus888> not affected / false positive for CVE-2023-27482 on the tracker.
2025-11-12 16:16:30 <Minus888> Tracker references:
2025-11-12 16:16:30 <Minus888> Source package page shows CVE-2023-27482 as unresolved for “supervisor”
2025-11-12 16:16:32 <Minus888> Branch pages (e.g. 3.18-main, 3.22-main) also list it
2025-11-12 16:16:32 <Minus888> Thanks!
2025-11-12 18:57:38 <Ariadne> ...
2025-11-12 19:20:42 <ikke> Ariadne: I've asked to open an issue: https://gitlab.alpinelinux.org/alpine/security/secdb/-/issues/15
2025-11-12 19:22:19 <Ariadne> i guess the solution there is to remap home assistant CPEs into a namespace where it cannot impact normal alpine packages
2025-11-12 19:22:36 <Ariadne> we already do that for some other CPEs
2025-11-12 19:26:06 <ikke> Ariadne: I've already pushed, but not yet deployed that 
2025-11-12 21:15:57 <Ariadne> ack
2025-11-12 23:32:45 <omni> libxml2 may still need patching in 3.19 and 3.20
2025-11-13 11:13:48 <achill> does someone want to do a security review on sudo-rs (!87750)
2025-11-13 11:24:56 <ikke> Relevant, though fixed in the latest version:
2025-11-13 11:24:58 <ikke> https://security-tracker.debian.org/tracker/CVE-2025-64517
2025-11-13 11:25:04 <ikke> https://security-tracker.debian.org/tracker/CVE-2025-64170
2025-11-13 15:20:06 <ikke> ftr, I don't consider myself qualified to audit rust code, so that's why I've been mostly referring to external audits
2025-11-14 13:37:23 <Sertonix[m]> What is the prefered place to discuss confidential security issues? Gitlab?
2025-11-14 13:38:07 <ikke> Yes
2025-11-15 13:44:59 <ikke> I'm thinking about how security.a.o works at the moment. Specifically about the list of "Vulnerable and fixed packages" per CVE.
2025-11-15 13:45:15 <ikke> The old logic was that it would only show the states of the currently published packages
2025-11-15 13:45:36 <ikke> That meant that as soon as a new version is pushed, the states would disappear
2025-11-15 13:46:35 <ikke> I removed the logic to unpublish versions once they have been published (the original goal was to wait showing a package was fixed until the apk was available)
2025-11-15 13:47:11 <ikke> That means right now, it shows all old vulnerable versions as fixed versions, but the order is random (I guess database insertion order)
2025-11-15 13:47:20 <ikke> which makes it messy
2025-11-15 13:47:54 <ikke> In my opionion, I think there is value in keeping older history
2025-11-15 13:50:00 <ikke> Another problem atm is that because the old packages are still marked as published, CVEs keep being marked as unresolved
2025-11-16 22:45:38 <ikke> The latter isue is fixed via https://gitlab.alpinelinux.org/alpine/security/secfixes-tracker/-/merge_requests/25
2025-11-17 21:14:59 <ikke> I've deployed another version which adds sorting to various lists instead of random order
2025-11-18 23:09:32 <invoked> i assume you folks are already aware of grub2 cves.
2025-11-18 23:11:00 <ikke> Nope
2025-11-18 23:12:12 <invoked> https://www.openwall.com/lists/oss-security/2025/11/18/1
2025-11-18 23:14:31 <invoked> are we not on the distros list?  i remember some discussion about it but can't recall
2025-11-18 23:14:51 <ikke> We are not
2025-11-18 23:15:11 <invoked> ah ok. that's why i assumed...
2025-11-19 08:32:48 <Foxboron> It's mostly relevant if you support secure boot, really
2025-11-22 15:02:26 <ikke> Four buffer overflow vulnerabilities fixed in libpng: https://www.openwall.com/lists/oss-security/2025/11/22/1
2025-11-27 06:15:07 <ncopa> morning. there are some CVE(s) in openssh that we need to backport
2025-11-27 06:17:34 <ikke> Are they all listed here? https://security.alpinelinux.org/srcpkg/openssh
2025-11-27 06:18:44 <ncopa> CVE-2025-61984.
2025-11-27 06:18:56 <ncopa> got email about it
2025-11-27 06:19:14 <ikke> https://security.alpinelinux.org/vuln/CVE-2025-61984
2025-11-27 06:20:36 <ncopa> I wonder if we should bump to 10.2
2025-11-27 06:20:47 <ncopa> need to read the changelog
2025-11-27 06:21:00 <ncopa> https://github.com/openssh/openssh-portable/commit/35d5917652106aede47621bb3f64044604164043
2025-11-27 13:12:51 <ikke> Ariadne: It appears the secfixes-tracker does not include a fixed vulnerability_state if the version range passes the constraints on the CPE match.
2025-11-27 13:13:03 <ikke> From my understanding it's due to this: https://gitlab.alpinelinux.org/alpine/security/secfixes-tracker/-/blob/master/secfixes_tracker/importers.py?ref_type=heads#L406-408
2025-11-27 13:14:03 <ikke> A new version of the package is pushed outside of the vulnerable constraint, that version does not match, so it bails out. No version with a fix is added to the database
2025-11-27 13:14:09 <ikke> Is that understanding correct?
2025-11-27 13:15:28 <ikke> Or is the issue that there is no secdb entry?
2025-11-27 13:16:18 <ikke> I guess the expectation is that the fixed version would be injected that way
2025-11-27 13:18:05 <ikke> Alternatively we could add logic to mark the vulnerability as fixed if there is no fixed version yet and the version is outside of the vulnerable version boundaries
2025-11-27 17:39:14 <ikke> There is a certain amount of irony when a security scanner has a vulnerability
2025-11-27 17:53:39 <ikke> I've added a new page to the secfixes-tracker: https://security.alpinelinux.org/recent
2025-11-27 17:53:54 <ikke> quickly see what CVEs have been added recently with matching packages
2025-11-27 17:57:46 <ikke> ncopa: so stricter username validation
2025-11-27 17:57:53 <ikke> for opeenssh
2025-11-27 18:55:50 <ncopa> Yeah, that’s how I understood 
2025-11-27 20:16:49 <Ariadne> ikke: yes, the thinking was that a package outside the version constraints was not vulnerable, and so there shouldn’t be any vulnerability record for it
2025-11-27 20:19:55 <ikke> Ok, but at least for me there is also value showing that the vulnerability has been addressed, even if by just upgrading the package
2025-11-27 20:20:41 <ikke> And, it would still show the vulnerability as unresolved if there is vuln state that has fixed=true
2025-11-27 20:20:55 <ikke> there is no*
2025-11-29 00:23:09 <invoked> https://github.com/OpenPrinting/cups/security/advisories/GHSA-8wpw-vfgm-qrrr https://github.com/OpenPrinting/cups/security/advisories/GHSA-hxm8-vfpq-jrfc
2025-11-29 00:33:46 <invoked> ^ didn't see anything in gitlab. i haven't studied either one, but hot take: the 1st isn't a big deal imo, the 2nd has rce potential, however unlikely
2025-11-29 00:42:14 <idkrnx[m]> Why does printing require root :(