2026-01-01 15:14:52 <omni> !95294
2026-01-01 15:15:18 <omni> https://gpg.fail/
2026-01-01 15:16:31 <omni> I also saw that 2.4 (oldstable) is only supported until 2026-06-30, around the time our 3.20-stable reaches EoL
2026-01-01 15:17:05 <omni> but 3.21 through 3.23 are still on 2.4
2026-01-01 19:28:41 <omni> !95297 !95298 !95300
2026-01-01 19:29:38 <omni> I'll let someone else look at and get those in, they're also upgrades from 2.4.7 and 2.4.5 (3.20-stable)
2026-01-13 22:13:01 <omni> #17888 backport upgrade and/or patches? (was basically what I meant with my lazy comment on the issue)
2026-01-19 13:19:38 <ncopa> https://www.openwall.com/lists/oss-security/2026/01/17/2
2026-01-19 13:38:46 <achill> great /s
2026-01-19 21:13:01 <ncopa> any opinion on enabling compression in openssl? I believe it may have been ocmpletely disable due to https://en.wikipedia.org/wiki/CRIME but apparently that is fixed in TLS 1.3, and there may be other uses for compression, like compressing certificates? https://gitlab.alpinelinux.org/alpine/aports/-/issues/17815
2026-01-19 21:14:43 <ncopa> I think fedora builds without no-comp. they even have zlib: https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/openssl.spec#_269
2026-01-19 22:00:25 <jvoisin> ncopa: the file you linked seems to enable md2, RC5, camellia and sctp as well :P
2026-01-19 22:01:50 <jvoisin> https://docs.openssl.org/3.6/man3/SSL_CTX_set1_cert_comp_preference/#description
2026-01-19 22:02:55 <jvoisin> more seriously, I'm not convinced adding support for compressing TLS certificates is really worth it: they have a high entropy (so don't compress well) and are negligible in the grand scheme of the data being sent over the connection
2026-01-19 22:03:31 <jvoisin> this is the corresponding RFC: https://www.rfc-editor.org/rfc/rfc8879
2026-01-19 22:03:43 <jvoisin> > This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.
2026-01-25 08:43:48 <bananicorn> FYI there are two new high severity privilege escalation CVEs in incus and incus-feature, they are fixed in version 6.21 for incus-feature, I don't see a new tag for the 6.0.x branch yet but it is supposed to be coming too, see here for more info: https://linuxcontainers.org/incus/news/#security-fixes
2026-01-25 10:49:52 <omni> two of the commits from the 23rd in the stable branch https://github.com/lxc/incus/commits/stable-6.0/ perhaps they're easy to backport as patches
2026-01-25 11:14:59 <omni> !96441 !96442 !96443 !96444
2026-01-25 15:03:33 <bananicorn> Thank you for the very speedy fix! :)
2026-01-25 18:38:14 <omni> thanks for bringing attention to it
2026-01-30 17:09:43 <samueldr> hi! sorry for barging-in as a stranger with a question
2026-01-30 17:09:53 <samueldr> I see that in https://gitlab.alpinelinux.org/alpine/aports/-/commit/9d3347ac75830f725fe3036c01d7955948e56b50 CVE-2025-68972 was marked as fixed in gnupg 2.4.9, though I don't see any information from upstream stating so
2026-01-30 17:10:04 <samueldr> a fix could have been part of the change set from 2.4.8, but maybe due to my lack of familiarity with the codebase, I don't see any that is... was there a statement from upstream about that?
2026-01-30 17:10:11 <samueldr> there's no mention of the CVE in the upstream issue tracker, which is AFAICT the only place they cross-reference CVEs and their own bug/tasks identifiers
2026-01-30 17:13:08 <ikke> Sertonix[m]: https://nvd.nist.gov/vuln/detail/CVE-2025-68972 at least says up-to and including 2.4.8
2026-01-30 17:13:12 <ikke> samueldr: *
2026-01-30 17:17:19 <samueldr> yeah, I'm wondering if it's the ol' tradition of borderline dangerous CPE data :(
2026-01-30 17:17:51 <samueldr> the data was added on 2026-01-09, well after the 2.4.9 release was cut (2025-12-30)
2026-01-30 17:18:08 <ikke> samueldr: that's absolutely a posibility
2026-01-30 17:19:56 <samueldr> btw, just to be clear about my intent for asking: I'm curious to see if this was a mistake from i.e. exactly that bad information, or if there is more information about that... I'm not trying to cast any fault, blame, etc, only tie loose ends
2026-01-30 17:20:55 <ikke> samueldr: yes, understood
2026-01-30 17:21:00 <ikke> omni: ^
2026-01-30 17:24:26 <samueldr> AFAICT the only "security trackers" that claim to have it fixed, other than alpine linux, are those from alpine linux derivatives that apparently just copy the security tracking data from alpine (thus the quotes...) *sigh*
2026-01-30 17:25:10 <samueldr> (just to be clear: quotes not applicable to upstream alpine linux)
2026-01-30 17:50:30 <samueldr> hmmm... unsure if it's warranted to tell, and if it applies, but given the secdb data is CC-BY-NC-ND, and that they know it, the minimus "distroless"[sic] distro might not understand what those terms mean...
2026-01-30 17:52:41 <ikke> samueldr: where do you see that specific license? https://secdb.alpinelinux.org/license.txt Says CC-BY-SA
2026-01-30 17:53:47 <samueldr> (1) I should have read the actual upstream license, and (2) on their docs lol
2026-01-30 17:54:27 <samueldr> I assumed (wrongly) they know about the CC license and just copied a link to the license text
2026-01-30 17:55:03 <samueldr> anyway, link here if anyone cares https://docs.minimus.io/scanning/advisories-feed
2026-01-30 17:55:23 <samueldr> (I would have preferred not giving them any form of advertising, but eh)
2026-01-30 17:56:31 <ikke> Interesting
2026-01-30 17:58:21 <ikke> I guess they just copy the structure, not necessarily the data (and then again, the question is how copyrightable the data is in the first place)
2026-01-30 17:58:54 <samueldr> sure, by now I shared what I observed, it's out of my hands, as an outsider :)
2026-01-30 22:16:58 <omni> I'll have a look and see what I may have missed or gotten wrong
2026-01-30 22:41:07 <omni> samueldr: I may very well have jumped to a conclusion wrt CVE-2025-68972, trying to find where I got it from to add it
2026-01-30 22:46:57 <omni> I just read this thread https://lists.gnupg.org/pipermail/gnupg-devel/2026-January/036140.html
2026-01-30 22:47:13 <omni> should we nack CVE-2025-68972?
2026-01-30 23:00:59 <omni> ncopa: !96738 (can follow up and backport to older releases if accepted)
2026-01-30 23:05:30 <omni> another gnupg issue that I raised, when I got this in at the beginning of the year, is that 2.4.x (aka "oldstable") will only be supported for ca another six months, gnupg in 3.21 through 3.23-stable will need to be supported beyond that
2026-01-30 23:30:33 <samueldr> omni: thanks for checking! and thanks for finding out it's disputed
2026-01-30 23:33:59 <samueldr> I see why I didn't notice that response to the disclosures: it's not on gnupg dot org... fun!