Bug#1064293: less: CVE-2022-48624
On 2024-04-20 at 16:19, Christoph Anton Mitterer wrote: > On Sat, 2024-04-20 at 07:54 -0400, P. J. McDermott wrote: > > Then the salvage procedure can play out for the full 28+ days > > specified > > by developers-reference (21 days to allow the maintainer to object > > followed by a DELAYED/7 adoption upload). I've already soft-proposed > > to > > salvage in bug #1069280 yesterday. And as mentioned there I'm not > > yet a > > DD or DM, so I'd need to find a sponsor (and access to > > debian/less.git). > > In the light of the recent XZ backdoor, wouldn't it generally be more > desirable to get more co-maintainers, rather than replacing an existing > one? Sure, that's exactly the plan. I don't intend to remove or prevent anyone from co-maintaining src:less. Note that my proposal to adopt, co-maintain, or salvage (bug #1069280) said that I would keep the current maintainer in Uploaders or Maintainer unless he requests otherwise. My intent is not to force out the existing maintainer, but to help where he seems to have been too busy to properly maintain src:less for at least two years. (No shame in being busy, but it looks like the package could use some help keeping up with new upstream releases, security issues like these, etc.) And the repository is already in the "debian" Salsa group (formerly "collab-maint" on Alioth), where any DD can commit to it. Also, if I adopt or salvage src:less, I plan to allow low-threshold NMU[1]. Other than that, I don't know of an appropriate team for it. [1]: https://wiki.debian.org/LowThresholdNmu -- Patrick "P. J." McDermott: http://www.pehjota.net/ Lead Developer, ProteanOS: http://www.proteanos.com/ Founder and CEO, Libiquity: http://www.libiquity.com/
Bug#1064293: less: CVE-2022-48624
On 2024-04-19 at 15:55, Salvatore Bonaccorso wrote: > Hi, > > FWIW, I'm actually preparing a security update for the two CVEs and > for bookworm I was first planning to do a 590-2.1 reaching unstable, > and so then 590-2.1~deb12u1 for bookworm. > > But if you want to override it with a NMU and proposing to salvage the > package this is equally fine. Your DELAYED/2 NMU is probably the fastest and best way to get these CVEs fixed in unstable and bookworm, so that's fine, thanks. Any plans for 551-2 in bullseye? The two patches in your NMU apply cleanly there. Then the salvage procedure can play out for the full 28+ days specified by developers-reference (21 days to allow the maintainer to object followed by a DELAYED/7 adoption upload). I've already soft-proposed to salvage in bug #1069280 yesterday. And as mentioned there I'm not yet a DD or DM, so I'd need to find a sponsor (and access to debian/less.git). If your NMU and my salvaging procedure go through, I'll rebase my work upon and acknowledge your NMU. And I'd like to backport a 643-1 to bookworm and bullseye sloppy (and update bullseye-backports with your NMU, unless you do that). You and I both apparently made the exact same changes to backport the CVE-2024-32487 patch (except your patch still has the original upstream diffstat instead of the backport, which is fine), so that's a good confirmation that my patch was (and yours is) correct. -- Patrick "P. J." McDermott: http://www.pehjota.net/ Lead Developer, ProteanOS: http://www.proteanos.com/ Founder and CEO, Libiquity: http://www.libiquity.com/
Bug#1064293: less: CVE-2022-48624
On 2024-04-12 at 16:10, Christoph Anton Mitterer wrote: > Hey. > > There seems to be a somewhat similar issue reported by Jakub Wilk on > oss-security: > https://www.openwall.com/lists/oss-security/2024/04/12/5 > > where quoting causes troubles (though I couldn't replay the demo). That was since assigned CVE-2024-32487 and Debian bug #1068938. > Any chance to get both fixed in Debian unstable? While the maintainer appears to be somewhat active elsewhere in Debian, this package hasn't seen an upload in over a year and the packaged version is getting close to three years old. (Although I found that updating to the latest upstream release version introduces new test suite and lintian issues requiring some upstream patches backported and reverted/fixed.) In my Salsa fork[1] I have updated the package (fixing CVE-2022-48624) and backported (with necessary code changes) the CVE-2024-32487 fix. I would like to adopt, co-maintain, or if necessary salvage src:less (see bug #1069280). But the procedure[2] for that requires 28 days of waiting for the maintainer to respond. Perhaps in the meantime a new upstream version NMU is warranted, or should the procedure be sped up somehow? [1]: https://salsa.debian.org/pehjota/less [2]: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#how-to-salvage-a-package -- Patrick "P. J." McDermott: http://www.pehjota.net/ Lead Developer, ProteanOS: http://www.proteanos.com/ Founder and CEO, Libiquity: http://www.libiquity.com/
Bug#1063707: liblua5.4-0: C++ library missing all "lua*" function symbols
Control: tags -1 - patch After submitting the aforementioned merge request (and another one with other improvements including CI pipelines), I see now that the patch removal was intentional: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032533 On 2023-03-08 at 14:44, Jackson wrote: > This patchfile undermines that Lua can be built as C++ to manage unwinding > exceptions; according to the date, it has been in the Debian Lua repository > for > over seven years. For example, future releases of MAME (package: mame) will > break using USE_SYSTEM_LUA_LIB if this fallacy not resolved, since they link > their own copy. I'm not sure what this bug report is trying to say or how `extern "C"` (simply preventing C++ name mangling) could undermine or break anything in what is really a C library (C symbol names, just compiled to throw and catch C++ exceptions). (Does MAME link against both a system C++ Lua and its own C Lua copy?) But whatever. And from https://salsa.debian.org/lua-team/lua5.4/-/merge_requests/4#note_444235 > With this we found that the current c++ library in sid is probably broken > (and unused since nobody complained so far) Yes, it is broken, but I'm trying to use it for the upcoming wesnoth-1.18 which can now use a system copy of Lua (after over a month of work toward that goal): https://github.com/wesnoth/wesnoth/pull/8234 Since lua5.4 was promoted to Ubuntu main in 23.10 and Wesnoth now uses Lua without modifications, the goal is for wesnoth-1.18 to use the lua5.4 package supported in Ubuntu main (instead of Wesnoth's embedded code copy stuck in universe) before the Ubuntu Noble Debian Import Freeze on 2024-02-29. So I hope this can somehow be fixed well before then (wesnoth-1.18 still has to go through NEW before that date). I found that the reason it is broken with `extern "C"` removed and name mangling newly enabled is that debian/patches/0001-build-system.patch links using the export map debian/version-script which doesn't list the C++ symbols. Adding the C++ symbols to debian/version-script and debian/liblua5.4-0.symbols as I attempted in the updated merge requests would fix this, however C++ symbol names are architecture-specific. So we'll have to either collect arch-specific names with `(arch=foo)` tags[1] (by making buildds fail for a while[2]) or switch to using shlibs[3]. The wiki recommends shlibs: "For C++ libraries it is often better not to ship symbols files."[1] Sounds good, especially since going through multiple uploads and waiting for buildds to fail would take time. Except switching to shlibs means losing the version information noting that the mangled symbols didn't exist before now, so users who install a package (that uses the C++ library's mangled symbols) without updating liblua5.4-0 will see run-time linker errors. To solve that, we need to also bump the C++ library's SONAME version (which is appropriate anyway, given that the ABI completely changed). So unless you disagree (or beat me to it), I'll work on switching to shlibs and bumping the SONAME version. Restoring `extern "C"` would avoid all this mess and keep the previous unmangled symbols in case anyone was using the C++ library before now. But the previous bug report claims that this breaks something (so let's break everything else instead). [1]: https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries [2]: https://www.eyrie.org/~eagle/journal/2012-01/008.html [3]: https://www.eyrie.org/~eagle/journal/2012-02/001.html -- Patrick "P. J." McDermott: http://www.pehjota.net/ Lead Developer, ProteanOS: http://www.proteanos.com/ Founder and CEO, Libiquity: http://www.libiquity.com/
Bug#1063707: liblua5.4-0: C++ library missing all "lua_*" function symbols
tags -1 + patch thanks https://salsa.debian.org/lua-team/lua5.4/-/merge_requests/5 -- Patrick "P. J." McDermott: http://www.pehjota.net/ Lead Developer, ProteanOS: http://www.proteanos.com/ Founder and CEO, Libiquity: http://www.libiquity.com/
Bug#1063707: liblua5.4-0: C++ library missing all "lua_*" function symbols
Package: liblua5.4-0 Version: 5.4.6-2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: p...@pehjota.net Hi, Since version 5.4.6-1, liblua5.4-c++.so.0.0.0 defines no "lua_*" function symbols (only "lua_ident@@LUA_5.4"): $ readelf -s /usr/lib/x86_64-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F lua_ 101: 000315e0 129 OBJECT GLOBAL DEFAULT 15 lua_ident@@LUA_5.4 $ readelf -s /usr/lib/i386-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F lua_ 106: 00030600 129 OBJECT GLOBAL DEFAULT 15 lua_ident@@LUA_5.4 Version 5.4.4-3 is OK: $ readelf -s /usr/lib/x86_64-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F lua_ | head -n 5 102: a610 220 FUNCGLOBAL DEFAULT 13 lua_pus[...]@@LUA_5.4 103: a940 160 FUNCGLOBAL DEFAULT 13 lua_getfield@@LUA_5.4 104: a5e048 FUNCGLOBAL DEFAULT 13 lua_pus[...]@@LUA_5.4 105: b330 273 FUNCGLOBAL DEFAULT 13 lua_set[...]@@LUA_5.4 107: bbf086 FUNCGLOBAL DEFAULT 13 lua_toclose@@LUA_5.4 $ readelf -s /usr/lib/i386-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F lua_ | head -n 5 107: 678064 FUNCGLOBAL DEFAULT 13 lua_pus[...]@@LUA_5.4 108: 6a10 173 FUNCGLOBAL DEFAULT 13 lua_getfield@@LUA_5.4 109: 674060 FUNCGLOBAL DEFAULT 13 lua_pus[...]@@LUA_5.4 110: 74f0 253 FUNCGLOBAL DEFAULT 13 lua_set[...]@@LUA_5.4 112: 7c3085 FUNCGLOBAL DEFAULT 13 lua_toclose@@LUA_5.4 The problem is that 0003-extern_C.patch was refreshed but mistakenly removed from debian/patches/series in version 5.4.6-1 (commit d46ea48) and then removed completely from debian/patches/ in version 5.4.6-2 (commit 02278c6).
Bug#594967: Bug #594967: [poulsbo] grub-pc Hangs After Welcome to GRUB!
On 01/04/2011 07:46 AM, Colin Watson wrote: On Tue, Jan 04, 2011 at 12:06:54AM +, Colin Watson wrote: On Mon, Jan 03, 2011 at 12:13:01AM +, Colin Watson wrote: 2011-01-02 Colin Watson cjwat...@ubuntu.com * grub-core/bus/pci.c (grub_pci_iterate): Skip remaining functions on devices that do not implement function 0. I've applied this patch to trunk following an ack from Vladimir on IRC. I'll prepare an updated package for unstable shortly. Uploading now. I'd appreciate confirmation from affected folks that this is enough to make things boot. If it is, we can perhaps avoid worrying about the rest; otherwise, we'll have to get more creative. Thanks, Sorry I haven't responded to this more quickly; I was busy with some personal business last week. Thanks for the patch, and it does make GRUB 2's graphical menu load on my AO751h. :) I noticed an odd lingering aesthetics issue though; most of the background image is missing. The only parts of Squeeze's `spacefun-grub.png' that are visible are the bottom of Earth and the two stars on the top-right corner (basically, anything along the edges). I've consistently reproduced this on two installations (one is a fresh installation on a flash drive), even after purging and reinstalling grub-pc and grub-common. The odd thing though is that it only happens with desktop-base 6.0.5. The `spacefun-grub.png' from version 6.0.2 is displayed in full. P. J. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594967: Bug #594967: [poulsbo] grub-pc Hangs After Welcome to GRUB!
I'm Cc'ing everyone involved in this bug for information, since I don't know who's subscribed (I am though). I first noticed this issue a month or two ago on installing Squeeze onto my Acer Aspire One AO751h, though I didn't have time to do anything more than install the old working GRUB 2 version. Yesterday I made myself a Squeeze installation on a flash drive and tried to boot it on the AO751h, only to be reminded of the issue. I'm on break now, so today I began investigating the bug. I'm looking through the differences between 20100617-1 and 20100702-1 (thanks Steve for bisecting this). Considering the machines this is affecting (machines with the Poulsbo chipset) and the configuration workaround, I'd bet the issue lies in the video subsystem. So far, the changes in the video/ directory appear to be mostly code re-factoring, so I think my next step will be to add some debugging output to 20100702-1's kernel and see where GRUB hangs up or what isn't being done. Don't expect any miracles though, as this is my first time in the GRUB 2 code. ;) If anyone has any thoughts on what the problem might be or familiarity with the GRUB kernel's initialization of the video subsystem, that would be helpful. P. J. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594967: Bug #594967: [poulsbo] grub-pc Hangs After Welcome to GRUB!
On 01/01/2011 06:57 PM, Colin Watson wrote: On Sat, Jan 01, 2011 at 06:35:52PM -0500, P. J. McDermott wrote: Considering the machines this is affecting (machines with the Poulsbo chipset) and the configuration workaround, I'd bet the issue lies in the video subsystem. So far, the changes in the video/ directory appear to be mostly code re-factoring, so I think my next step will be to add some debugging output to 20100702-1's kernel and see where GRUB hangs up or what isn't being done. Don't expect any miracles though, as this is my first time in the GRUB 2 code. ;) If anyone has any thoughts on what the problem might be or familiarity with the GRUB kernel's initialization of the video subsystem, that would be helpful. I think (with respect) that Vladimir was mistaken when he said that the video changes in 20100702-1 only affected the EFI port. One effect of these changes was to load the video_cirrus and video_bochs modules by default (you can test whether this is the culprit by commenting them out in grub.cfg). I've seen a handful of systems that hang while trying to enumerate the PCI bus in GRUB; it so happens that those are the only modules that usually trigger GRUB's PCI bus enumeration in normal circumstances ... You can also verify this at a lower level by trying 'lspci' at a GRUB prompt. If it's the same problem, this will hang. I noticed the new bochs and cirrus files, but I didn't think they would affect a Poulsbo system. You're right though; I commented out those lines, and I'm now looking at a graphical menu for GNU GRUB version 1.98+20100804-11 (as installed by Squeeze beta1's debian-installer) on an AO751h. I suppose the problem then is in either grub_pci_iterate() or the hook functions passed to it by the cirrus and bochs modules? Unfortunately, I haven't had my hands on an affected machine for more than a day or so, and that was when I was under deadline pressure so a workaround was the best I could manage. Steve, is your affected system at home? Maybe I could visit at some point (for others on the bug, we're in the same city) ... I can do testing and debugging on my system as well, if it helps. I might poke around grub_pci_iterate() and the hook functions tonight or tomorrow sometime. P. J. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
