Bug#1059163: closed by Debian FTP Masters (reply to Anibal Monsalve Salazar ) (Bug#1059163: fixed in cpio 2.14+dfsg-1)
Hi Anibal, On Fri, Dec 22, 2023 at 06:21:04AM +, Debian Bug Tracking System wrote: > cpio (2.14+dfsg-1) unstable; urgency=medium > . >* New upstream release > Closes: #1049402 > Noteworthy changes in this release: > - New option --ignore-dirnlink >Valid in copy-out mode, it instructs cpio to ignore the actual number >of links reported for each directory member and always store 2 >instead. > - Changes in --reproducible option >The --reproducible option implies --ignore-dirlink. In other words, >it is equivalent to --ignore-devno --ignore-dirnlink --renumber-inodes. > - Use GNU ls algorithm for deciding timestamp format in -tv mode > - Bugfixes >- Fix cpio header verification. >- Fix handling of device numbers on copy out. >- Fix calculation of CRC in copy-out mode. >- Rewrite the fix for CVE-2015-1197. >- Fix combination of --create --append --directory. >- Fix appending to archives bigger than 2G. >* Update uploaders list > Closes: #925021 >* Standards-Version: 4.6.2 >* Fix Path traversal vulnerability due to partial revert of fix for > CVE-2015-1197 > Closes: #1059163 Thanks for this upload to unstable. Can you check if the upstream redone changes for CVE-2015-1197 are backportable, and if so can you address the issue in the upcoming point releases for bookworm and bullseye? Regards, Salvatore
Bug#1059251: ITP: node-git-url-parse -- High level git url parser for common git providers
Package: wnpp Severity: wishlist Owner: Israel Galadima X-Debbugs-CC: debian-de...@lists.debian.org * Package name : node-git-url-parse Version : 13.1.1 Upstream Author : Ionică Bizău (https://ionicabizau.net) * URL : https://github.com/IonicaBizau/git-url-parse * License : Expat Programming Lang: JavaScript Description : High level git url parser for common git providers A high level git url parser for common git providers. This package is part of my effort to package yarnpkg for Debian. Package will be maintained by the Debian JavaScript Team. OpenPGP_0x3679ECB87B7CEC0C.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059250: mate-screensaver: SIGSEGV of mate-screensaver while automatic activation and interfering with mouse pointer movement
Package: mate-screensaver Version: 1.26.1-1 Severity: normal Dear Maintainer, Screensaver was activating automatically, while darken the screen, I have interferred with mouse pointer. Screensaver was not able to lock anymore the screen because it crashed with SIGSEGV. regards, Joël -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mate-screensaver depends on: ii dbus-x11 1.14.10-3 ii libc62.37-13 ii libcairo21.18.0-1 ii libdbus-1-3 1.14.10-3 ii libdbus-glib-1-2 0.112-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3 ii libgl1 1.7.0-1 ii libglib2.0-0 2.78.3-1 ii libgtk-3-0 3.24.38-6 ii libmate-desktop-2-17 1.26.2-1 ii libmate-menu21.26.0-3 ii libmatekbd4 1.26.1-1 ii libnotify4 0.8.3-1 ii libpam0g 1.5.2-9.1 ii libpango-1.0-0 1.51.0+ds-3 ii librda0 0.0.5-1.1 ii libsystemd0 255-1 ii libx11-6 2:1.8.7-1 ii libxext6 2:1.3.4-1+b1 ii libxklavier165.4-5 ii libxss1 1:1.2.3-1 ii libxxf86vm1 1:1.1.4-1+b2 ii mate-desktop-common 1.26.2-1 ii mate-screensaver-common 1.26.1-1 ii mate-session-manager 1.26.1-2 Versions of packages mate-screensaver recommends: ii mate-power-manager 1.26.1-1 Versions of packages mate-screensaver suggests: pn rss-glx ii xscreensaver-data 6.06+dfsg1-3 -- no debconf information (gdb) thread apply all bt Thread 5 (Thread 0x7f80044cf6c0 (LWP 2033)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x7f8005c3da54 in g_cond_wait () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f8005bac16b in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f8005c100ca in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f8005c0fa41 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f80055c43ec in start_thread (arg=) at ./nptl/pthread_create.c:444 #6 0x7f8005644a5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 4 (Thread 0x7f8003cce6c0 (LWP 2034)): #0 0x7f8005637a1f in __GI___poll (fds=0x55826e608aa0, nfds=2, timeout=3355) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f8005be2277 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f8005be2930 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f8005be2981 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f8005c0fa41 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f80055c43ec in start_thread (arg=) at ./nptl/pthread_create.c:444 #6 0x7f8005644a5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 3 (Thread 0x7f8002c406c0 (LWP 2042)): #0 0x7f8005637a1f in __GI___poll (fds=0x7f7fec000b90, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f8005be2277 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f8005be2930 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f80045c54bd in () at /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so #4 0x7f8005c0fa41 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f80055c43ec in start_thread (arg=) at ./nptl/pthread_create.c:444 #6 0x7f8005644a5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 2 (Thread 0x7f80034cd6c0 (LWP 2035)): #0 0x7f8005637a1f in __GI___poll (fds=0x7f7ff8000b90, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f8005be2277 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f8005be2c1f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f8005df0eaa in () at /lib/x86_64-linux-gnu/libgio-2.0.so.0 #4 0x7f8005c0fa41 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f80055c43ec in start_thread (arg=) at ./nptl/pthread_create.c:444 #6 0x7f8005644a5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 1 (Thread 0x7f80045d3a80 (LWP 2017)): #0 0x7f80068873bd in g_type_check_instance () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #1 0x7f80068765fb in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #2 0x7f800687d186 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #3 0x7f800687d243 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #4 0x55826c9bb013 in () #5 0x7f8005bdf0d9 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x7f8005be2317 in () at
Bug#1036869: O: ghostscript -- interpreter for the PostScript language and for PDF
On Mon, 24 Oct 2022 15:17:20 +0200 Jonas Smedegaard wrote: > I have orphaned the ghostscript package, due to lack of time. I'm willing to take on -- and hopefully, share -- the ghostscript maintenance. If anyone wants to team up, let me know! -Steve signature.asc Description: This is a digitally signed message part.
Bug#1012720: golang-k8s-apimachinery: Please remove protected references from salsa repo
On Thu, Dec 21, 2023 at 11:01:23PM +0530 Nilesh Patra wrote: > On Wed, Dec 20, 2023 at 09:49:48AM +0100, Nicolas Schier wrote: > > On Wed, Dec 20, 2023 at 09:44:31AM +0100 Nicolas Schier wrote: > > ah, I forgot to mention that 'uscan' does choose the "correct" upstream > > version > > tag automatically: > > [...] > > > Can someone please remove the protected branch 'upstream' as well as the > > > upstream tag 'upstream/1.25.0_alpha0'? > > > > > > (Or remove the whole repo to allow re-creating it?) > > Do you still want the repo to be pruned or remove the upstream branch? yes, please. > > > [1]: > > > https://salsa.debian.org/go-team/packages/golang-k8s-apimachinery.git > > Best, > Nilesh signature.asc Description: PGP signature
Bug#1059249: designer-qt6: Segmentation fault in /usr/lib/qt6/bin/designer at launch
Package: designer-qt6 Version: 6.6.1-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: mlukow...@sdf.org Hey, Designer segfaults on launch; seems the bug might be with qt6 xcb integration. Valgrind reports the following output: matt@pancakehut:~$ valgrind /usr/lib/qt6/bin/designer ==947004== Memcheck, a memory error detector ==947004== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==947004== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==947004== Command: /usr/lib/qt6/bin/designer ==947004== ==947004== Syscall param writev(vector[0]) points to uninitialised byte(s) ==947004==at 0x6A911BD: __writev (writev.c:26) ==947004==by 0x6A911BD: writev (writev.c:24) ==947004==by 0x7D46FBF: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0x7D47800: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0x7D48E24: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0x7D48EA0: xcb_wait_for_reply (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0xA933D83: QXcbConnection::initializeScreensFromMonitor(xcb_screen_iterator_t*, int, QXcbScreen**, bool) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA934927: QXcbConnection::initializeScreens(bool) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA925F42: QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA950B15: QXcbIntegration::QXcbIntegration(QList const&, int&, char**) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0x486546F: ??? (in /usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so) ==947004==by 0x5C06F97: QGuiApplicationPrivate::createPlatformIntegration() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x5C08887: QGuiApplicationPrivate::createEventDispatcher() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004== Address 0xa2699c5 is 4,533 bytes inside a block of size 21,176 alloc'd ==947004==at 0x48459F3: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==947004==by 0x7D46990: xcb_connect_to_fd (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0x7D4B191: xcb_connect_to_display_with_auth_info (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==947004==by 0x6E8BD09: _XConnectXCB (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0) ==947004==by 0x6E7C0C6: XOpenDisplay (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0) ==947004==by 0xA92EB71: QXcbBasicConnection::QXcbBasicConnection(char const*) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA925CF4: QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA950B15: QXcbIntegration::QXcbIntegration(QList const&, int&, char**) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0x486546F: ??? (in /usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so) ==947004==by 0x5C06F97: QGuiApplicationPrivate::createPlatformIntegration() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x5C08887: QGuiApplicationPrivate::createEventDispatcher() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x6332545: QCoreApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt6Core.so.6.6.1) ==947004== ==947004== Invalid read of size 8 ==947004==at 0x637970A: ??? (in /usr/lib/x86_64-linux-gnu/libQt6Core.so.6.6.1) ==947004==by 0x5C0D9E5: QGuiApplication::screenAdded(QScreen*) (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x5C66DB8: QWindowSystemInterface::handleScreenAdded(QPlatformScreen*, bool) (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0xA934A6F: QXcbConnection::initializeScreens(bool) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA925F42: QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0xA950B15: QXcbIntegration::QXcbIntegration(QList const&, int&, char**) (in /usr/lib/x86_64-linux-gnu/libQt6XcbQpa.so.6.6.1) ==947004==by 0x486546F: ??? (in /usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so) ==947004==by 0x5C06F97: QGuiApplicationPrivate::createPlatformIntegration() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x5C08887: QGuiApplicationPrivate::createEventDispatcher() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x6332545: QCoreApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt6Core.so.6.6.1) ==947004==by 0x5C0890F: QGuiApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt6Gui.so.6.6.1) ==947004==by 0x54BCDDC:
Bug#1059248: ITP: python-cirpy -- Python interface for the Chemical Identifier Resolver (CIR)
Package: wnpp Severity: wishlist Owner: Yogeswaran Umasankar X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com * Package name: python-cirpy Version : 1.0.2 Upstream Contact: Matt Swain * URL : https://github.com/mcs07/CIRpy * License : Expat Programming Lang: Python Description : Python interface for the Chemical Identifier Resolver (CIR) CIRpy is a Python interface for the Chemical Identifier Resolver (CIR) by the CADD Group at the NCI/NIH. It is a web service that will resolve any chemical identifier to another chemical representation. It is a great tool for bio-informatics and chemistry.
Bug#1059247: stressant: crashes not finding /usr/share/doc/fio/examples/basic-verify.fio
Package: stressant Version: 0.7.0 Severity: important X-Debbugs-Cc: deb...@onerussian.com Dear Maintainer, Decided to try stressant on a freshly installed debian box. But it crashed with yoh@reproiner:~$ stressant --cpu ... INFO: Disk stress test Traceback (most recent call last): File "/usr/bin/stressant", line 491, in main() File "/usr/bin/stressant", line 479, in main testDrive(**vars(args)) File "/usr/bin/stressant", line 401, in testDrive with open(jobFile, 'rb') as source: ^^^ FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/doc/fio/examples/basic-verify.fio' only with apt-file I saw that there is also fio-examples that is only Suggests-ed by fio on which stressant depends. So it seems that stressant might need to Depend on fio-examples *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-16-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stressant depends on: ii python3 3.11.2-1+b1 ii python3-colorlog 6.7.0-1 ii python3-humanize 4.4.0-1 Versions of packages stressant recommends: ii fio3.33-3 ii hdparm 9.65+ds-1 ii iperf3 3.12-1+deb12u1 ii lshw 02.19.git.2021.06.19.996aaad9c7-2+b1 ii smartmontools 7.3-1+b1 ii stress-ng 0.15.06-2 stressant suggests no packages. -- no debconf information
Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...
* Sébastien Villemot [2023-12-21 15:23]:
Le jeudi 21 décembre 2023 à 08:49 +0100, Rafael Laboissière a écrit :
* Santiago Vila [2023-12-20 22:03]:
El 20/12/23 a las 21:08, Rafael Laboissière escribió:
HOME := $(shell mktemp -d)
so that the same directory is never used twice between consecutive builds.
Yes, this is a much better solution. Thanks for the suggestion. I am
just wondering: is there a simple way to delete the temporary
directory after he build is finished ?
I don't know, but most people build packages in temporary/disposable chroots,
so if the package just writes a few files which are also small, it's not
something for which I would worry too much.
Yes, it not really a worrisome issue. However, I have just noticed that
the solution that you proposed with mktemp is a little bit intrusive.
Indeed, a new temporary directory is created at each invocation of
debain/rules, such that I end up with five /tmp/tmp.* directories after
package building, with only the last one being actually used. I will try
another approach, probably by changing the dh_octave_check script, which
is the one that eventually needs a writable $HOME directory.
Note that within the context of a shell script, the following ensures
that the directory is automatically deleted upon exit:
tmpdir=$(mktemp -d)
cleanup ()
{
rm -rf "${tmpdir}"
}
trap cleanup EXIT
Thanks, Sébastien.
I think that it is possible to do something similar in Perl (the language
in which dh_octave_check is written) by using the %SIG hash. I will take
a look at it.
Best,
Rafael
Bug#1059241: [firefox] hi-dpi broken for vertical tab list
On Fri, 2023-12-22 at 11:08 +0900, Mike Hommey wrote: > Would you mind filing these issues upstream? > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Widget%3A%20Gtk > > Mike Okay, done!
Bug#1058701: pm-utils: unauthorised and uncommunicated removal
> I agree. > Removal request by maintainers are fine. > Removal requests by anyone for un-maintained packages are ok. > Removal requests by third-parties for packages with a maintainer are > a situation to take a closer look at least. Without: 1) my ftpteam hat on 2) any specific reference to this individual situation 3) this being a direct reply to the above (this isn't about your email gregor, I totally understand what you're saying; and I think if this was on a package that had recent uploads it would have triggered some additional scrutiny, which means we would do most of the above as status-quo) I will note a removal being done against a maintainer's wishes is incredibly rare. I think among the thousands of removals I've watched, I can not remember another instance of a removal being done to a package where the maintainer disagreed. This is all to say, adding to the layers of burden when processing a removal that was properly filed, and passed the sniff test (RoQA is inherently not by the maintainer, and the package /looked/ unmaintained, even if it wasn't in reality) for an issue that has only happened -- as far as I know -- once in modern history, would be a tough outcome. I don't see people weaponizing the removal process, and it seems like a pretty straight-forward thing to address if folks started to maliciously file removals. This specific situation seems unfortunate. I have every confidence the maintainers involved will collaborate in a good faith effort to move the distro forward. If that means re-uploading pm-utils, a fast-track trip through NEW isn't hard. I don't think this would impact any of our users in any meaningful sense (package is still installed, plus it's sid) -- I don't think a change to the process is warranted. This seems like a social problem folks ought to work through. Paul
Bug#519109:
close -1 All the missing information is in the manpage. I am closing this bug as no longer valid -- With best regards, b.
Bug#1059246: rust-laurel: add loongarch64 support
Source: rust-laurel
Version: 0.5.3-1.1
Severity: wishlist
Tags: patch ftbfs
User: debian-loonga...@lists.debian.org
Usertags: loong64
Dear maintainers,
I have submitted the LoongArch architecture support in rust-laurel
upstream [1], please see the pull-request link [2].
Please add support for loongarch64 (64-bit LoongArch) in rust-laurel
source package.
Please consider the patch I have attached.
Your opinions are welcome.
[1]:https://github.com/threathunters-io/laurel
[2]:https://github.com/threathunters-io/laurel/pull/186
thanks,
Dandan Zhang
Description: Add loongarch64 support
Last-Update: 2023-12-21
--- rust-laurel-0.5.3.orig/src/constants.rs
+++ rust-laurel-0.5.3/src/constants.rs
@@ -59,6 +59,7 @@ const ARCHS: &[(, u32)] = &[
("hexagon", 0x00a4),
("i386", 0x4003),
("ia64", 0xc032),
+("loongarch64", 0xc102),
("m32r", 0x0058),
("m68k", 0x0004),
("microblaze", 0x00bd),
Bug#1059163: cpio: Path traversal vulnerability
On Wed, 2023-12-20 19:55:30 +0100, Ingo Brückl wrote: > Package: cpio > Version: 2.13+dfsg-7.1 > Severity: grave > > The patch "revert-CVE-2015-1197-handling" (to close bugs #946267 and #946469) > re-enables path traversal vulnerability with maliciously crafted cpio > archives. Hello Ingo, I have been working on a new Debian version of cpio for the last couple of days. I hope to upload it today. I will appreciate it very much if you could give it a try after uploading it. Thank you for your previous messages related to this security vulnerability. I will send those messages to Salvatore. Kind regards, Aníbal
Bug#1058643: dnsdist: re-enable 32-bit support via _TIME_BITS=64
On Sun, Dec 17, 2023 at 11:54:56PM +0100, Chris Hofstaedtler wrote: > On Thu, Dec 14, 2023 at 12:06:59AM +, Matija Nalis wrote: > > export DEB_CXXFLAGS_APPEND="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" > > (and skipping dependency on architecture-is-64-bit, of course). > > My understanding is, doing this on an individual package level, is > not safe in any way. It might work when the stars align correctly, > but there are zero guarantees for anything. I agree, there would be issues in cases where 64-bit time_t is passed to library which was not compiled for 64-bit time_t. But as link below notes, that actually seems to happen not all that often. (and I have not seen it in my - admittedly somewhat basic - use of dnsdist) > I think we'll wait at the very least until Debian finishes the t64 > transition, and then we'll see what to do about 32bit archs. Yes, when transition happens (with tentative timeline of Jan 2024?), re-enabling 32-bit archs for dnsdist should "just work". More details (and suggestions for package maintainers how to prepare) are available at: https://wiki.debian.org/ReleaseGoals/64bit-time > In the meantime, dnsdist works on arm64, also on Raspberrys! It does, if one happens to have newer Rasperry Pi hardware (i.e. Cortex-A53+, not older Rpi1 & Rpi2 which are 32-bit only), and 64-bit distro (many are still 32-bit based by default for plug-in compatibility with older hardware and resource conservation, and people are somewhat understandably reluctant to reinstalling and reconfiguring their whole systems just to install one package) I did talk to people at #dnsdist IRC, and they referenced https://github.com/PowerDNS/pdns/pull/10933 If I understood correctly, it should just work when whole system is recompiled for 64-bit, but there were talks about improving tests suite so it can validated if 64bit dnsdist + 32libs would work fine too. (But it is, as always, the matter of priorities and available time...) -- Opinions above are GNU-copylefted.
Bug#1058701: pm-utils: unauthorised and uncommunicated removal
On Fri, 22 Dec 2023 02:04:52 +, Thorsten Glaser wrote: > I’ll argue for two things here: > • for a removal, if the requester is not the maintainer, check > back with the maintainer. Just always do that. I agree. Removal request by maintainers are fine. Removal requests by anyone for un-maintained packages are ok. Removal requests by third-parties for packages with a maintainer are a situation to take a closer look at least. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#1059245: gdm3: GDM3 fails to start on Wayland, maybe due to org.freedesktop.systemd1 failing to activate
Package: gdm3 Version: 45.0.1-1 Severity: grave Justification: renders package unusable Dear Maintainer, GDM3 doesn't seem to be able to start a Wayland session (nor a fallback Xorg session, but I'm less concerned about this, and this seems to be a separate permission issue). This seems to be related to org.freedesktop.systemd1 failing to activate (and triggering the fallback to Xorg). The smoking gun implicating org.freedesktop.systemd1 is déc. 22 03:17:17 desktop gdm-launch-environment][28769]: pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm(uid=113) by (uid=0) déc. 22 03:17:17 desktop /usr/libexec/gdm-wayland-session[28792]: dbus-daemon[28792]: [session uid=113 pid=28792] Activating service name='org.freedesktop.systemd1' requested by ':1.0' (uid=113 pid=28785 comm="/usr/libexec/gdm-wayland-session dbus-run-session ") déc. 22 03:17:17 desktop /usr/libexec/gdm-wayland-session[28792]: dbus-daemon[28792]: [session uid=113 pid=28792] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1 déc. 22 03:17:17 desktop /usr/libexec/gdm-wayland-session[28785]: Unable to register display with display manager déc. 22 03:17:17 desktop gdm-launch-environment][28769]: pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Rebooting the machine after a long uptime and some updates. This was with gdm3-43 on bookworm; the same is observed after installing gdm3-45 from testing. libgdm1:amd64 (43.0-3) was updated on 2023-10-10 via unattended upgrades, but the system successfully rebooted a few times since then. * What exactly did you do (or not do) that was effective (or ineffective)? * Re-rebooting the machine. * Making sure that the the system was not in degraded mode according to systemd (systemctl stop and systemctl reset-failed). * Configuring the Wi-Fi network with nmcli (in addition to pre-existing functional ethernet connectivity, just in case some network dependency blocked the org.freedesktop.systemd1 activatio) * Installing gdm3-45 from testing * What was the outcome of this action? Nothing fixed the issue. * What outcome did you expect instead? Getting a graphical login prompt. *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-15-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 22.08.8-6 ii adduser 3.134 ii dbus [default-dbus-system-bus]1.14.10-1~deb12u1 ii dbus-bin 1.14.10-1~deb12u1 ii dbus-daemon 1.14.10-1~deb12u1 ii dconf-cli 0.40.0-4 ii dconf-gsettings-backend 0.40.0-4 ii debconf [debconf-2.0] 1.5.82 ii gir1.2-gdm-1.045.0.1-1 ii gnome-session [x-session-manager] 43.0-1+deb12u1 ii gnome-session-bin 43.0-1+deb12u1 ii gnome-session-common 43.0-1+deb12u1 ii gnome-settings-daemon 43.0-4 ii gnome-shell 43.9-0+deb12u1 ii gnome-terminal [x-terminal-emulator] 3.46.8-1 ii gsettings-desktop-schemas 43.0-1 ii libaccountsservice0 22.08.8-6 ii libaudit1 1:3.0.9-1 ii libc6 2.36-9+deb12u3 ii libcanberra-gtk3-00.30-10 ii libcanberra0 0.30-10 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgdm1 45.0.1-1 ii libglib2.0-0 2.78.3-1 ii libglib2.0-bin2.78.3-1 ii libgtk-3-03.24.38-2~deb12u1 ii libgudev-1.0-0237-2 ii libkeyutils1 1.6.3-2 ii libpam-modules1.5.2-6+deb12u1 ii libpam-runtime1.5.2-6+deb12u1 ii libpam-systemd [logind] 252.19-1~deb12u1 ii libpam0g 1.5.2-6+deb12u1 ii librsvg2-common 2.54.7+dfsg-1~deb12u1 ii libselinux1 3.4-1+b6 ii libsystemd0 252.19-1~deb12u1 ii libx11-6 2:1.8.4-2+deb12u2 ii libxau6 1:1.0.9-1 ii libxcb1 1.15-1 ii libxdmcp6
Bug#1059241: [firefox] hi-dpi broken for vertical tab list
On Fri, Dec 22, 2023 at 01:50:34AM +, Lyndon Brown wrote: > On Fri, 2023-12-22 at 10:31 +0900, Mike Hommey wrote: > > What happens if you run with MOZ_ENABLE_WAYLAND=0 ? > > > > Mike > > Back to normal. I can scroll the full list, and the list is no longer > 100% of screen height, it's located just below the button and extends > down just short of the bottom of the screen. > > I happened to noticed that this also makes bug #1059242 go away. Would you mind filing these issues upstream? https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Widget%3A%20Gtk Mike
Bug#1058701: pm-utils: unauthorised and uncommunicated removal
Thorsten Alteholz dixit: > Where would have been a better place to draw your attention to it? Not Ian, but the *extremely* obvious and expected place would be eMail to the maintainer. (Actually, probably: an eMail to everyone who would have gotten an eMail if a bug against the package itself had been reported.) All those ways you noticed, save d-bugs-dist (which is high-volume and generic and therefore not a good way) are polling, not really suitable for notification. I’ll argue for two things here: • for a removal, if the requester is not the maintainer, check back with the maintainer. Just always do that. • perhaps a chance to extend debbugs to copy ftp.d.o bugs that affect a package, no matter what, to the bugreport recipients that that package would have gotten. bye, //mirabilos -- 21:49⎜ I have a question guys, ⎜Can I use my PC as SMTP server, I use Windows 7 . ⎜Already googled and Installed IIS ⎜but Still I can't send E-mail
Bug#1059244: grub-pc stops booting and its workaround
Hi, Follow-up to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059244 It looks like this problem has been around for 8 years. I saw: Debian netinstall 8.1 i386 GRUB2 does not copy i386-pc modules to /boot/grub - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790289 There he was able to boot just with /boot (not with / like me) by using the same workaround as I did. Anyway, I keep this bug separate so people will have easy time finding workaround by googling. Regards Osamu Minor correction: On Fri, 2023-12-22 at 01:34 +, Osamu Aoki wrote: ... > ## Thoughts on the hardware configuration trigger: > > Possible triggers I suspect: > - /boot on /dev/sda5 (not on MBR primary partition /dev/sda1 etc.) > - SSD size (500GB) and sector location of /boot Here, I should have said - `/` including `/boot` on /dev/sda5 (not on MBR primary partition /dev/sda1 etc.) - SSD size (500GB) and sector location of FS containing /boot
Bug#1059242: [firefox] quick scrolling tab list instead now shows context menu
Note, "correct" behaviour is restored when run with MOZ_ENABLE_WAYLAND=0
Bug#1059241: [firefox] hi-dpi broken for vertical tab list
On Fri, 2023-12-22 at 10:31 +0900, Mike Hommey wrote: > What happens if you run with MOZ_ENABLE_WAYLAND=0 ? > > Mike Back to normal. I can scroll the full list, and the list is no longer 100% of screen height, it's located just below the button and extends down just short of the bottom of the screen. I happened to noticed that this also makes bug #1059242 go away.
Bug#1059244: grub-pc stops booting and its workaround
Package: grub-pc
Version: 2.06-13+deb12u1
Severity: normal
X-Debbugs-Cc: os...@debian.org
I hope this helps people who tries to install Debian stable on MBR.
(I think modifying grub-pc install script for stable package to do what
I manually did is rather a low risk change with decent benefits. Please
consider.)
## Grub problem encountered and my workaround:
I encountered a dificult grub-pc install during my fresh install of
Bookworm/12 using NETINST USB to /dev/sda5 as root `/` holding partition
formatted as ext4. Here, /dev/sda is 500GB SSD formatted to use MBR.
When I initially encountered this bug, system data such as /boot, /var
and /usr were on /dev/sda5. So fancy mounting points listed below were
introduced after setting up my workaround to get grub-pc working.
When initially installed before my workaround, grub stoped booting
before showing the normal blue selection menu. I get presented with the
"GRUB RESCUE>" prompt and I can type "ls" and it lists installed SSDs.
It complained on missing `/boot/grub/i386-pc/normal.mod`
I copied the whole /usr/lib/grub/i386-pc/ directory to /boot/grub/ since
it was missing not just i386-pc/normal.mod file but i386-pc/ directory
itself.
(This system repair workaround was performed by booting the system with
SystemRescue USB stick. https://www.system-rescue.org/ )
Then my system boot without problem showing nice blue selection screen.
After booting, I see `/boot/grub/.background_cache.png` created.
## Thoughts on the packaging:
As I compaired grub install situation with my another system using UEFI,
there I see /boot/grub/x86_64-efi/ directory and all *.mod files.
UEFI system also had /usr/lib/grub/x86_64-efi with the same *.mod.
My question is why Debian packager decided not to do the same for
grub-pc? If he did the same for grub-pc, I didn't suffer broken grub
install.
## Thoughts on the hardware configuration trigger:
Possible triggers I suspect:
- /boot on /dev/sda5 (not on MBR primary partition /dev/sda1 etc.)
- SSD size (500GB) and sector location of /boot
## Few more background etc.
As you might have thought, I initially tried to boot using `/boot` (not
`/`) on /dev/sda5. Then I had `/` in LVM (Then not encrypted.). Back
then, error message was much more cryptic since it didn't print normal
path. It was looking for some partition with long label starting with "lvm".
So it took me a good amount of head-scratching before finding workable
solution.
With the above workaround, I may be able to use encrypted root on LVM.
I didn't test it. For now, I don't have an appetite to re-install this
PC.
With the current setup, I effectively have an encrypted system (except
for /etc and /boot. (I think I can also move /root to encrypted FS.)
This system comes with early UEFI system. But it was a bit problematic
one so I ended up to use it in legacy mode with MBR partition.
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/CRYPTO-BTRFS /usr btrfs
rw,relatime,ssd,space_cache=v2,subvolid=259,subvol=/@usr 0 0
/dev/mapper/CRYPTO-BTRFS /btrfs btrfs
rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/ 0 0
/dev/mapper/CRYPTO-BTRFS /opt btrfs
rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@opt 0 0
/dev/mapper/CRYPTO-BTRFS /home/osamu btrfs
rw,relatime,ssd,space_cache=v2,subvolid=261,subvol=/@osamu 0 0
/dev/mapper/CRYPTO-BTRFS /srv btrfs
rw,relatime,ssd,space_cache=v2,subvolid=257,subvol=/@srv 0 0
/dev/mapper/CRYPTO-BTRFS /var btrfs
rw,relatime,ssd,space_cache=v2,subvolid=258,subvol=/@var 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos5'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
Bug#1059243: [evolution] touch action on message body does not change focus
Package: evolution Version: 3.50.2-1 I have a laptop with a touchscreen. It's annoyed me for some time now that if I touch the main message body control, it fails to switch focus. Touch works just fine on the other controls. I could just tab to body from subject when ready, or I could click, when my touchpad isn't being temperamental, but I find myself often wanting to just reach forward and tap the large message body area on the screen to switch focus to it, but I can't because it doesn't work. Touching the screen does work to move the cursor location within my message body text however. The lack of focus switching seems to be a bug or small oversight.
Bug#1059241: [firefox] hi-dpi broken for vertical tab list
On Fri, Dec 22, 2023 at 01:09:01AM +, Lyndon Brown wrote: > Package: firefox > Version: 121.0-0 > Severity: important > > The vertical tab list (accessed via the 'down arrow' in the tab bar, to > the right of the new tab '+' button) is now no longer working correctly > for Hi-DPI as of version 121.0-1. > > I have many windows with many tabs. Previously with version 120 I had > no problem scrolling the entire tab list. Now, depending upon which tab > I have selected, I cannot scroll a certain number of tabs at the top > and/or bottom of the list into view. > > Notably when trying to scroll to the very top/bottom I see the > scrollbar going out of view beyond the limits of the screen height. > > I have a Hi-DPI screen set to 200% scaling. Experimenting, if I switch > to 100% scaling then the problem goes away, being able to scroll the > full list as previously (with the list drawn with 100% screen height > regardless of whether the window is maximized or not). > > So it seems that a small regression was introduced. > What happens if you run with MOZ_ENABLE_WAYLAND=0 ? Mike
Bug#1059242: [firefox] quick scrolling tab list instead now shows context menu
Package: firefox Version: 121.0-0 I have a laptop with a touchscreen. With previous versions if I touched and held my finger on the left or right arrow buttons either side of the tab list to scroll through them, it would "quick scroll" (as opposed to a single press making one short scroll movement). Now when I try this with version 121 it just results in a context menu being displayed with options like 'new tab'. Perhaps this was a deliberate change rather than a bug, I don't know, but disappointing if so as I used this all the time.
Bug#1059241: [firefox] hi-dpi broken for vertical tab list
Package: firefox Version: 121.0-0 Severity: important The vertical tab list (accessed via the 'down arrow' in the tab bar, to the right of the new tab '+' button) is now no longer working correctly for Hi-DPI as of version 121.0-1. I have many windows with many tabs. Previously with version 120 I had no problem scrolling the entire tab list. Now, depending upon which tab I have selected, I cannot scroll a certain number of tabs at the top and/or bottom of the list into view. Notably when trying to scroll to the very top/bottom I see the scrollbar going out of view beyond the limits of the screen height. I have a Hi-DPI screen set to 200% scaling. Experimenting, if I switch to 100% scaling then the problem goes away, being able to scroll the full list as previously (with the list drawn with 100% screen height regardless of whether the window is maximized or not). So it seems that a small regression was introduced.
Bug#1058701: pm-utils: unauthorised and uncommunicated removal
Hi Ian, On Thu, 21 Dec 2023, Ian Jackson wrote: I have just become aware of #1058701 via the automated email that resulted from the removal of pm-utils. this is sad. The RM bug appeared on the tracker page of the package, in your packages overview, on the ftpmaster removals page (or on the bug page). It was also sent to debian-bugs-dist@lists.debian.org. Where would have been a better place to draw your attention to it? I am still using this package. I'm sure others are. The package *is* maintained in Debian. Hmm, the standards version is 3.9.7, the VCS URLs point to a no longer existing repository, the last upload was in 2019. This looks rather like an abandoned package. But of course, your mileage may vary I intend to re-upload the last version shortly (and reopen all the bug reports). Yes, please do so. Thorsten
Bug#1059240: ITP: python-chemspipy -- A way to interact with ChemSpider in Python
Package: wnpp Severity: wishlist Owner: Yogeswaran Umasankar X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com * Package name: python-chemspipy Version : 2.0.0 Upstream Contact: Matt Swain * URL : https://github.com/mcs07/ChemSpiPy * License : Expat Programming Lang: Python Description : A way to interact with ChemSpider in Python ChemSpiPy provides a way to interact with ChemSpider in Python. It allows chemical searches, chemical file downloads, depiction and retrieval of chemical properties. It can be widely used in both chemistry and bio-informatics.
Bug#1059146: haskell-pandoc: diff for NMU version 3.0.1-3.1
Control: tags 1059146 + patch
Control: tags 1059146 + pending
Dear maintainer,
I've prepared an NMU for haskell-pandoc (versioned as 3.0.1-3.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru haskell-pandoc-3.0.1/debian/changelog
haskell-pandoc-3.0.1/debian/changelog
--- haskell-pandoc-3.0.1/debian/changelog 2023-12-06 17:21:57.0
+0100
+++ haskell-pandoc-3.0.1/debian/changelog 2023-12-21 21:20:26.0
+0100
@@ -1,3 +1,14 @@
+haskell-pandoc (3.0.1-3.1) unstable; urgency=medium
+
+ Non-maintainer update.
+
+ * revive and unfuzz patches lost in transition from src:pandoc:
++ 2001: avoid potential privacy breaches in templates
+ closes: bug#1059146
++ 2002: improve error message when pdf program is missing
+
+ -- Jonas Smedegaard Thu, 21 Dec 2023 21:20:26 +0100
+
haskell-pandoc (3.0.1-3) unstable; urgency=medium
* Apply upstream patch to fix FTBFS on 32-bit platforms
diff -Nru
haskell-pandoc-3.0.1/debian/patches/2001_templates_avoid_privacy_breach.patch
haskell-pandoc-3.0.1/debian/patches/2001_templates_avoid_privacy_breach.patch
---
haskell-pandoc-3.0.1/debian/patches/2001_templates_avoid_privacy_breach.patch
1970-01-01 01:00:00.0 +0100
+++
haskell-pandoc-3.0.1/debian/patches/2001_templates_avoid_privacy_breach.patch
2023-12-21 21:11:23.0 +0100
@@ -0,0 +1,138 @@
+Description: Avoid potential privacy breaches in templates
+Author: Jonas Smedegaard
+License: GPL-3+
+Last-Update: 2018-06-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/data/dzslides/template.html
b/data/dzslides/template.html
+@@ -48,7 +48,7 @@
+
+
+
+- http://placekitten.com/g/800/600;>
++
+ An image
+
+ Kittens are so cute!
+@@ -56,7 +56,7 @@
+
+
+
+- http://videos-cdn.mozilla.net/brand/Mozilla_Firefox_Manifesto_v0.2_640.webm;
poster="http://www.mozilla.org/images/about/poster.jpg;>
++
+ A video
+
+
+@@ -68,16 +68,13 @@
+
+
+
+-
+-
+-
+
+ html, .view body { background-color: black; counter-reset: slideidx; }
+ body, .view section { background-color: white; border-radius: 12px }
+ /* A section is a slide. It's size is 800x600, and this will never change */
+ section, .view head > title {
+ /* The font from Google */
+- font-family: 'Oswald', arial, serif;
++ font-family: 'DejaVu Sans Condensed', 'Liberation Sans', 'Nimbus Sans
L', arial, serif;
+ font-size: 30px;
+ }
+
+--- a/data/templates/default.dzslides
b/data/templates/default.dzslides
+@@ -20,15 +20,12 @@
+
+ $endfor$
+ $else$
+-
+-
+