Bug#1072488: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:rocksdb Hi RMs, I don't know how long the transition queue is, but this is the small rocksdb (8.9 to 9.2 soname) transition request. Only two packages are affected: balboa and sortmerna. Both build fine with the new rocksdb release already in experimental. Thanks for consideration, Laszlo/GCS
Bug#1070977: transition: snappy
On Mon, May 13, 2024 at 2:04 PM Emilio Pozuelo Monfort wrote: > Why is there a libsnappy1v5 transitional package? Serves several purposes. As noted, upstream soname is _not_ changed, so I can't let the old library package be present as it would contain the same named library file conflicting with the one in the new, normally named library package name. In short, I must do a file move between packages. Then the old libsnappy1v5 package has a conflict with the then old libsnappy1 package name. Thus this conflict needs to be removed. > Also has upstream been contacted in order to do a proper SONAME bump? > Otherwise > libsnappy1 will have to conflict with libsnappy1v5, and that will make both > the > transition and upgrades harder, as they have to be done in lockstep. If they > broke the ABI, then a SONAME bump is in order, and that will make it easier > for > us too. Yup, in such cases a soname bump is needed. Then upstream is Google and as I remember years back I had a somewhat similar problem with one of their library package. If I'm correct, I got a similar answer that in such cases they just recompile the dependent sources and don't change the soname. Then the public source tree is hosted on GitHub [1] without the issues (report) area enabled. The AUTHORS file contains a general email address (opensou...@google.com) [2] meaning I'm not sure if I get any answer or I will get one soon. But I can try it if you insist. Regards, Laszlo/GCS [1] https://github.com/google/snappy [2] https://github.com/google/snappy/blob/1.2.0/AUTHORS
Bug#1070977: transition: snappy
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:snappy Hi RMs, Upstream of snappy changed function signatures [1] breaking other applications with the 1.2.0 release. I've added back the original function signatures calling the new ones to restore the immediate problem, to restore the ABI. But then this creates ambiguity in the Compress method signatures [2] making (only) ceph FTBFS. While it can be patched to avoid it, a proper transition should be done. I've renamed back the library name which was done due to the C++11 ABI change with g++ 5.0 back in 2015. Thanks for considering, Laszlo/GCS [1] https://bugs.debian.org/1070217 [2] https://bugs.debian.org/1070785
Bug#1070266: nmu: chromium_124.0.6367.118-1
Control: tags -1 +moreinfo On Fri, May 3, 2024 at 12:57 AM Andres Salomon wrote: > Snappy 1.2.0-1 was uploaded with broken symbols (see > https://bugs.debian.org/1070217). This is fixed in snappy 1.2.0-2, but > chromium in sid had already built against the broken version of snappy. Nope, the symbols were _not_ broken, some were missing as of the 1.1.10-1 version. I have added those back in the 1.2.0-2 package version. > Please rebuild chromium against snappy 1.2.0-2 to fix its broken symbol > dependencies. Because this chromium release has CVE fixes (and there's > 20-something pending CVEs in trixie already that would be fixed by > chromium migration), I'm filing this with a higher severity than usual. It is _not_ needed. the ABI of 1.2.0-1 is not changed in 1.2.0-2, I've even installed the new snappy library version and can still use chromium without problems. Do you experience any odd behaviour? Regards, Laszlo/GCS
Bug#1059026: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:rocksdb Hi RMs, Small transition of RocksDB to the 8.9.1 release, available from experimental. Affected packages are balboa, oxigraph and sortmerna. While oxigraph is Sid only currently, all three build fine with this version of RocksDB as well. Thanks for considering, Laszlo/GCS
Bug#1055944: bookworm-pu: package vips/8.14.1-3+deb12u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bookworm Severity: normal Control: affects -1 + src:vips Hi RMs, [ Reason ] A specially crafted SVG input can cause libvips versions 8.14.3 or earlier to segfault when attempting to parse a malformed UTF-8 character. It is considered a security issue and has the CVE-2023-40032 identifier. [ Impact ] It is an application crash and can't be used for more. Hence the Security Team decided it doesn't get a DSA. But it would be nice to get the package updated. [ Tests ] Upstream testsuite and Sid update doesn't report any regressions. [ Risks ] The proposed change has very little risk of side-effects. [ Checklist ] [x] *all* changes are documents in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in bookworm [x] the issue is verified as fixed in unstable Thanks for considering, Laszlo/GCS diff -Nru vips-8.14.1/debian/changelog vips-8.14.1/debian/changelog --- vips-8.14.1/debian/changelog 2023-02-13 10:48:58.0 +0100 +++ vips-8.14.1/debian/changelog 2023-11-14 16:05:39.0 +0100 @@ -1,3 +1,10 @@ +vips (8.14.1-3+deb12u1) bookworm; urgency=medium + + * Backport upstream security fix for CVE-2023-40032: svgload: fix +null-pointer dereference. + + -- Laszlo Boszormenyi (GCS) Tue, 14 Nov 2023 16:05:39 +0100 + vips (8.14.1-3) unstable; urgency=medium * Double self-testing timeout on mips64el and mipsel architectures. diff -Nru vips-8.14.1/debian/patches/CVE-2023-40032.patch vips-8.14.1/debian/patches/CVE-2023-40032.patch --- vips-8.14.1/debian/patches/CVE-2023-40032.patch 1970-01-01 01:00:00.0 +0100 +++ vips-8.14.1/debian/patches/CVE-2023-40032.patch 2023-11-14 16:05:39.0 +0100 @@ -0,0 +1,71 @@ +From e091d65835966ef56d53a4105a7362cafdb1582b Mon Sep 17 00:00:00 2001 +From: Kleis Auke Wolthuizen +Date: Sun, 13 Aug 2023 15:48:54 +0200 +Subject: [PATCH] svgload: fix null-pointer dereference (#3604) + +`g_utf8_find_next_char()` might return NULL when called with a +non-NULL second argument, indicating that the end of the string +has been reached. +--- + ChangeLog | 4 + libvips/foreign/svgload.c | 18 +++--- + 2 files changed, 19 insertions(+), 3 deletions(-) + +diff --git a/ChangeLog b/ChangeLog +index e47ee86bb4..b7544219e5 100644 +--- a/ChangeLog b/ChangeLog +@@ -1,3 +1,7 @@ ++TBD 8.14.4 ++ ++- fix null-pointer dereference during svgload [kleisauke] ++ + TBD 8.14.2 + + - dedupe FITS header write [ewelot] +diff --git a/libvips/foreign/svgload.c b/libvips/foreign/svgload.c +index 94072581d4..aefd412ed2 100644 +--- a/libvips/foreign/svgload.c b/libvips/foreign/svgload.c +@@ -145,7 +145,7 @@ vips_foreign_load_svg_zfree( void *opaque, void *ptr ) + /* Find a utf-8 substring within the first len_bytes (not characters). + * + * - case-insensitive +- * - needle must be zero-terminated, but hackstack need not be ++ * - needle must be zero-terminated, but haystack need not be + * - haystack can be null-terminated + * - if haystack is shorter than len bytes, that'll end the search + * - if we hit invalid utf-8, we return NULL +@@ -191,11 +191,14 @@ vips_utf8_strcasestr( const char *haystack_start, const char *needle_start, + b == (gunichar) -2 ) + return( NULL ); + +-/* End of haystack. There can't be a complete needle +- * anywhere. ++/* Disallow codepoint U+ as it's a nul byte. ++ * This is redundant with GLib >= 2.63.0, see: ++ * https://gitlab.gnome.org/GNOME/glib/-/merge_requests/967 + */ ++#if !GLIB_CHECK_VERSION( 2, 63, 0 ) + if( a == (gunichar) 0 ) + return( NULL ); ++#endif + + /* Mismatch. + */ +@@ -205,6 +208,15 @@ vips_utf8_strcasestr( const char *haystack_start, const char *needle_start, + haystack_char = + g_utf8_find_next_char( haystack_char, + haystack_start + len_bytes ); ++ ++/* End of haystack. There can't be a complete needle ++ * anywhere. ++ */ ++if( haystack_char == NULL ) ++return( NULL ); ++ ++/* needle_char will never be NULL. ++ */ + needle_char = + g_utf8_find_next_char( needle_char, NULL ); + } diff -Nru vips-8.14.1/debian/patches/series vips-8.14.1/debian/patches/series --- vips-8.14.1/debian/patches/series 2023-02-12 08:52:21.0 +0100 +++ vips-8.14.1/debian/patches/series 2023-11-14 16:05:39.0 +0100 @@ -1,2 +1,3 @@ dedupe_fits_header.patch fix_target_pnm_write.patch +CVE-2023-40
Bug#1053608: bullseye-pu: zeromq3/4.3.4-1+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: sdu...@centreon.com Control: affects -1 + src:zeromq3 Hi RMs, [ Reason ] I got a bug report that fork() is not detected correctly for zeromq3 when GCC 7 or 8 is used [1]. [ Impact ] For some workflows it causes an assertion which was reported upstream [2] and fixed [3]. The fix is applied and a package update is prepared, debdiff is attached to this email. [ Tests ] Upstream testsuite still works. The build log now contains the positive changelog message that fork() is now detected correctly. [ Risks ] Very little as the change is not a source change but a configure check fix. With newer GCC versions (ie Bookworm and later) the configure check works and fork() is used as expected. [ Checklist ] [x] *all* changes are documents in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in bullseye [x] the issue is verified as fixed in unstable Thanks for considering, Laszlo/GCS [1] https://bugs.debian.org/1053448 [2] https://github.com/zeromq/libzmq/issues/3313 [3] https://github.com/zeromq/libzmq/commit/5a9c174dab9f8f7cd675360db2af302cb48d961a diff -Nru zeromq3-4.3.4/debian/changelog zeromq3-4.3.4/debian/changelog --- zeromq3-4.3.4/debian/changelog 2021-02-03 08:46:36.0 +0100 +++ zeromq3-4.3.4/debian/changelog 2023-10-07 11:22:30.0 +0200 @@ -1,3 +1,9 @@ +zeromq3 (4.3.4-1+deb11u1) bullseye; urgency=medium + + * Apply fix for fork() detection on GCC 7 (closes: #1053448). + + -- Laszlo Boszormenyi (GCS) Sat, 07 Oct 2023 11:22:30 +0200 + zeromq3 (4.3.4-1) unstable; urgency=medium * New upstream release. diff -Nru zeromq3-4.3.4/debian/patches/fix_fork_detection_with_gcc_7.patch zeromq3-4.3.4/debian/patches/fix_fork_detection_with_gcc_7.patch --- zeromq3-4.3.4/debian/patches/fix_fork_detection_with_gcc_7.patch 1970-01-01 01:00:00.0 +0100 +++ zeromq3-4.3.4/debian/patches/fix_fork_detection_with_gcc_7.patch 2023-10-07 11:22:30.0 +0200 @@ -0,0 +1,85 @@ +From 240e36af4e0300a529c99b0a05c4bf391bbcd6f5 Mon Sep 17 00:00:00 2001 +From: David Gloe +Date: Tue, 23 Nov 2021 15:39:42 + +Subject: [PATCH 1/2] Problem: Fix fork detection on gcc 7 + +Solution: When compiling with gcc 7 and newer, the program produced by +AC_CHECK_FUNCS(fork) produces a warning, which results in configure +incorrectly disabling fork support. Fix the issue by using an +AC_COMPILE_IFELSE which correctly detects fork availability. +Tested by running configure and make check on a system with gcc 7 +installed, and verifying that HAVE_FORK was defined correctly. + +See issue #3313. +--- + configure.ac | 19 --- + 1 file changed, 16 insertions(+), 3 deletions(-) + +diff --git a/configure.ac b/configure.ac +index 227e37b488..1a571291eb 100644 +--- a/configure.ac b/configure.ac +@@ -771,9 +771,24 @@ AC_LANG_POP([C++]) + + # Checks for library functions. + AC_TYPE_SIGNAL +-AC_CHECK_FUNCS(perror gettimeofday clock_gettime memset socket getifaddrs freeifaddrs fork mkdtemp accept4) ++AC_CHECK_FUNCS(perror gettimeofday clock_gettime memset socket getifaddrs freeifaddrs mkdtemp accept4) + AC_CHECK_HEADERS([alloca.h]) + ++# AC_CHECK_FUNCS(fork) fails on gcc 7 ++AC_MSG_CHECKING([whether fork is available]) ++AC_COMPILE_IFELSE( ++ [AC_LANG_PROGRAM( ++ [[#include ]], ++ [[return fork();]]) ++ ],[ ++ AC_MSG_RESULT([yes]) ++ AC_DEFINE(HAVE_FORK, [1], [fork is available]) ++ AM_CONDITIONAL(HAVE_FORK, true) ++ ],[ ++ AC_MSG_RESULT([no]) ++ AM_CONDITIONAL(HAVE_FORK, false) ++]) ++ + # string.h doesn't seem to be included by default in Fedora 30 + AC_MSG_CHECKING([whether strnlen is available]) + AC_COMPILE_IFELSE( +@@ -971,8 +986,6 @@ LIBZMQ_CHECK_GETRANDOM([ + [Whether getrandom is supported.]) + ]) + +-AM_CONDITIONAL(HAVE_FORK, test "x$ac_cv_func_fork" = "xyes") +- + if test "x$cross_compiling" = "xyes"; then + # Enable draft by default when cross-compiling + defaultval=yes + +From 72b5359049664458e117f2609d174dc5213fc19b Mon Sep 17 00:00:00 2001 +From: David Gloe +Date: Tue, 23 Nov 2021 16:27:52 + +Subject: [PATCH 2/2] Problem: Missing relicense statement for dgloe-hpe + +Solution: Add new author to the existing HPE relicense statement. +--- + RELICENSE/hewlett_packard_enterprise.md | 6 -- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/RELICENSE/hewlett_packard_enterprise.md b/RELICENSE/hewlett_packard_enterprise.md +index 9a0741984d..067ce39cbc 100644 +--- a/RELICENSE/hewlett_packard_enterprise.md b/RELICENSE/hewlett_packard_enterprise.md +@@ -5,9 +5,11 @@ that grants permission to relicense its copyrights in the libzmq C++ + library (ZeroMQ) under the Mozilla Public License v2 (MPLv2). + + A portion of the commits made by the Github handle "brc859844", with +-commit author "Brett Cameron &
Bug#1052026: transition: thrift
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:thrift Hi RMs, Small transition to 0.19.0 release of thrift. The only reverse dependency is gnuradio which builds fine with the new thrift release. There are two things to consider. First is that gnuradio is also involved in the fmtlib, qwt and boost1.81 transitions as well. Then it is scheduled to be removed from testing on 14th of October due to depending on bladerf which has an open RC bug [1].with a patch since the end of August. Thanks for considering, Laszlo/GCS [1] https://bugs.debian.org/1050943
Bug#1051380: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:rocksdb Hi RMs, Small transition of rocksdb as only two packages are affected: balboa and sortmerna. Both build fine with the 8.5.3 version of rocksdb already in experimental. Only thing to mention is that the testing version of sortmerna doesn't build with the new rocksdb version - but as I know it doesn't cause any issue as binNMUs happen in unstable. Thanks for considering, Laszlo/GCS
Bug#1041776: transition: libwebsockets
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:libwebsockets Hi RMs, This transition missed Bookworm, but now I would like to start it. All reverse dependencies are built correctly on amd64. I'm going to test i386 as well, but I do not expect any failure. Thanks for considering, Laszlo/GCS
Bug#1040639: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:rocksdb Control: forwarded -1 https://release.debian.org/transitions/html/auto-rocksdb.html Hi RMs, Small transition for RocksDB as only two reverse dependencies are in the archives: balboa and sortmerna. Both build fine with the rocksdb 8.3.2-1 version already in experimental. The only thing you might wait for is that it's not yet started to build on mips64el. I don't expect any failure as it was built fine on other release architectures. Regards, Laszlo/GCS
Bug#1036449: unblock: vice/3.7.1+dfsg1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Control: affects -1 + src:vice Hi RMs, [ Reason ] My bad was still using non-official categories in desktop files. Now this is corrected. [ Impact ] Find shortcuts to emulation binaries in the right place finally for Bookworm. [ Tests ] Local check was made and already in Sid for a week. [ Risks ] None. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock vice/3.7.1+dfsg1-2 Thanks for considering, Laszlo/GCS diff -Nru vice-3.7.1+dfsg1/debian/changelog vice-3.7.1+dfsg1/debian/changelog --- vice-3.7.1+dfsg1/debian/changelog 2023-04-29 10:58:51.0 +0200 +++ vice-3.7.1+dfsg1/debian/changelog 2023-05-14 07:41:04.0 +0200 @@ -1,3 +1,10 @@ +vice (3.7.1+dfsg1-2) unstable; urgency=medium + + * Use valid Freedesktop.org categories for desktop files +(closes: #626518, #958959). + + -- Laszlo Boszormenyi (GCS) Sun, 14 May 2023 07:41:04 +0200 + vice (3.7.1+dfsg1-1) unstable; urgency=medium * Remove mps803.bin printer ROM from source (closes: #1035079). diff -Nru vice-3.7.1+dfsg1/debian/desktop/x128.desktop vice-3.7.1+dfsg1/debian/desktop/x128.desktop --- vice-3.7.1+dfsg1/debian/desktop/x128.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/x128.desktop 2023-05-13 23:20:01.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/c128icon-32x28.xpm Exec=/usr/bin/x128 Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator; diff -Nru vice-3.7.1+dfsg1/debian/desktop/x64.desktop vice-3.7.1+dfsg1/debian/desktop/x64.desktop --- vice-3.7.1+dfsg1/debian/desktop/x64.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/x64.desktop 2023-05-13 23:20:07.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/c64icon-32x28.xpm Exec=/usr/bin/x64sc Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator; diff -Nru vice-3.7.1+dfsg1/debian/desktop/xcbm2.desktop vice-3.7.1+dfsg1/debian/desktop/xcbm2.desktop --- vice-3.7.1+dfsg1/debian/desktop/xcbm2.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/xcbm2.desktop 2023-05-13 23:20:12.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/cbm2icon-32x28.xpm Exec=/usr/bin/xcbm2 Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator; diff -Nru vice-3.7.1+dfsg1/debian/desktop/xpet.desktop vice-3.7.1+dfsg1/debian/desktop/xpet.desktop --- vice-3.7.1+dfsg1/debian/desktop/xpet.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/xpet.desktop 2023-05-13 23:20:16.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/peticon-32x28.xpm Exec=/usr/bin/xpet Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator; diff -Nru vice-3.7.1+dfsg1/debian/desktop/xplus4.desktop vice-3.7.1+dfsg1/debian/desktop/xplus4.desktop --- vice-3.7.1+dfsg1/debian/desktop/xplus4.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/xplus4.desktop 2023-05-13 23:20:32.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/plus4icon-32x28.xpm Exec=/usr/bin/xplus4 Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator; diff -Nru vice-3.7.1+dfsg1/debian/desktop/xvic.desktop vice-3.7.1+dfsg1/debian/desktop/xvic.desktop --- vice-3.7.1+dfsg1/debian/desktop/xvic.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/xvic.desktop 2023-05-13 23:20:35.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/vic20icon-32x28.xpm Exec=/usr/bin/xvic Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator;
Bug#1035339: unblock: vice/3.7.1+dfsg1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Control: affects -1 + src:vice Hi RMs, [ Reason ] Upstream source contains several ROM files for Commodore machines and floppy drives, including printers. All these have a size of 2k and multiples. A script under debian/ directory called mangle-source.sh remove those. There's a printer ROM file which turned out to be an exception to this size rule. Meaning this non-free file slipped to the source tree and to the package itself. This is filed as a serious bug [1] already. I've fixed it by removing the file and updating the removal script. [ Impact ] It will make the package DFSG free and users can still have it in Bookworm. [ Tests ] This file is unused for package build and only needed if someone would like to emulate the Commodore printer. That is, no extra tests are required. [ Risks ] Nothing. The change is only a file removal, replace it with the text 'dummy' and a source repack shell script update. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] Uploaded, built on all architectures and package is working. unblock vice/3.7.1+dfsg1-1 Thanks for considering, Laszlo/GCS [1] https://bugs.debian.org/1035079 Binary files /tmp/Vc_Z6BwILs/vice-3.7.1+dfsg/data/PRINTER/mps803.bin and /tmp/e6SEihfSew/vice-3.7.1+dfsg1/data/PRINTER/mps803.bin differ diff -Nru vice-3.7.1+dfsg/debian/changelog vice-3.7.1+dfsg1/debian/changelog --- vice-3.7.1+dfsg/debian/changelog 2023-02-17 21:06:12.0 +0100 +++ vice-3.7.1+dfsg1/debian/changelog 2023-04-29 10:58:51.0 +0200 @@ -1,3 +1,9 @@ +vice (3.7.1+dfsg1-1) unstable; urgency=medium + + * Remove mps803.bin printer ROM from source (closes: #1035079). + + -- Laszlo Boszormenyi (GCS) Sat, 29 Apr 2023 10:58:51 +0200 + vice (3.7.1+dfsg-2) unstable; urgency=medium * Clarify license of CBM.ttf (closes: #1029260). diff -Nru vice-3.7.1+dfsg/debian/mangle-source.sh vice-3.7.1+dfsg1/debian/mangle-source.sh --- vice-3.7.1+dfsg/debian/mangle-source.sh 2023-01-14 20:56:30.0 +0100 +++ vice-3.7.1+dfsg1/debian/mangle-source.sh 2023-04-29 10:58:51.0 +0200 @@ -24,6 +24,9 @@ echo dummy > $FILE fi done + # non-standard size + rm data/PRINTER/mps803.bin + echo dummy > data/PRINTER/mps803.bin # replace non-free font echo replace font 1>&2 rm data/common/C64_Pro_Mono-STYLE.ttf 1>&2
Bug#1034646: [pre-approval] unblock: fuse3/3.14.0-4
Control: tags -1 -moreinfo On Thu, Apr 27, 2023 at 7:56 AM Paul Gevers wrote: > Please go ahead and remove the moreinfo tag once the upload happens. Thanks, uploaded and built on all architectures. Piuparts and package tests are done as well. Cheers, Laszlo/GCS
Bug#1034646: [pre-approval] unblock: fuse3/3.14.0-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: Cyril Brulebois Control: affects -1 + src:fuse3 Hi RMs, Two issues in src:fuse3 I would like to have fixed for Bookworm. [ Reason ] There's a memory leak in the high level API [1] and the fuse CLI doesn't propagate the allowed maximum threads to use [2]. [ Impact ] In special cases like fuse3 would get a signal during its start it would leak some memory. Users can't set usage constraints in terms of threads (CPU) usage. These are not common situations but would be better to handle these. [ Tests ] Upstream test suite. Tested and built correctly in experimental. Waiting for your permission to upload to Sid. [ Risks ] Minimal, the fixes are small and very targeted. Should not affect the installer creation (as it uses the fuse3 udeb), but kibi is also pinged for an extra check. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock fuse3/3.14.0-4 Thanks for considering, Laszlo/GCS [1] https://github.com/libfuse/libfuse/pull/781 [2] https://github.com/libfuse/libfuse/pull/742 diff -Nru fuse3-3.14.0/debian/changelog fuse3-3.14.0/debian/changelog --- fuse3-3.14.0/debian/changelog 2023-03-17 20:51:05.0 +0100 +++ fuse3-3.14.0/debian/changelog 2023-04-18 23:07:15.0 +0200 @@ -1,3 +1,11 @@ +fuse3 (3.14.0-4) unstable; urgency=medium + + * Backport upstream fixes: +- fix max_threads command line parameter propagation, +- fix memory leak in high level API. + + -- Laszlo Boszormenyi (GCS) Tue, 18 Apr 2023 23:07:15 +0200 + fuse3 (3.14.0-3) unstable; urgency=medium [ Helge Deller ] diff -Nru fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch --- fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch 1970-01-01 01:00:00.0 +0100 +++ fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch 2023-04-17 21:34:29.0 +0200 @@ -0,0 +1,24 @@ +From ab5ca07af03b7dbb33193666c13b938534bde0e4 Mon Sep 17 00:00:00 2001 +From: Sarath Lakshman +Date: Sat, 11 Mar 2023 16:58:31 +0530 +Subject: [PATCH] Fix max_threads command line parameter propagation + +The fuse_main_real() method doesn't apply the max_threads parameter +parsed through the commandline arguments. This commit fixes the wiring +of max_threads argument. +--- + lib/helper.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/lib/helper.c b/lib/helper.c +index 35c6a98c..14a0df33 100644 +--- a/lib/helper.c b/lib/helper.c +@@ -377,6 +377,7 @@ int fuse_main_real(int argc, char *argv[], const struct fuse_operations *op, + fuse_loop_cfg_set_clone_fd(loop_config, opts.clone_fd); + + fuse_loop_cfg_set_idle_threads(loop_config, opts.max_idle_threads); ++ fuse_loop_cfg_set_max_threads(loop_config, opts.max_threads); + res = fuse_loop_mt(fuse, loop_config); + } + if (res) diff -Nru fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch --- fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch 1970-01-01 01:00:00.0 +0100 +++ fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch 2023-04-17 21:34:29.0 +0200 @@ -0,0 +1,66 @@ +From fcd293f675fc7bfa0522186c5d68ef932eec6945 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Matthias=20G=C3=B6rgens?= +Date: Fri, 14 Apr 2023 19:19:03 +0800 +Subject: [PATCH] Fix memory leak in high level API (#781) + +Previously, in the high level API if we received a signal between +setting up signal handlers and processing INIT, we would leak + +``` +$ ./example/hello -s -d -f mountpoint/ +[9/9] Linking target example/hello_ll +FUSE library version: 3.14.1 +nullpath_ok: 0 + += +==178330==ERROR: LeakSanitizer: detected memory leaks + +Direct leak of 352 byte(s) in 1 object(s) allocated from: +#0 0x7fbb19abf411 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77 +#1 0x7fbb1a0efd3b in fuse_fs_new ../lib/fuse.c:4814 +#2 0x7fbb1a0f02b5 in fuse_new_31 ../lib/fuse.c:4913 +#3 0x7fbb1a10ec5e in fuse_main_real ../lib/helper.c:345 +#4 0x5625db8ab418 in main ../example/hello.c:176 +#5 0x7fbb1983c78f (/usr/lib/libc.so.6+0x2378f) + +SUMMARY: AddressSanitizer: 352 byte(s) leaked in 1 allocation(s). +``` + +That's because `fuse_lowlevel.c`s `fuse_session_destroy` would only call +the user supplied `op.destroy`, if INIT had been processed, but the high +level API relied on `op.destroy` to free `f->fs`. + +This patch moves the freeing into `fuse_destroy` that will always be +called by our high-level API. +--- + lib/fuse.c | 3 +-- + 1 file changed
Bug#1034645: unblock: graphicsmagick/1.4+really1.3.40-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:graphicsmagick
Hi RMs,
Two security fixes were added to graphicsmagick and I would like to
get those to Bookworm.
[ Reason ]
It was found that the MIFF reader was somehow able to provide
attribute data in a way which resulted in a heap overflow. There is
also a memory leak fix.
[ Impact ]
The heap overflow was detected by ASAN, meaning it might be
exploitable. The memory leak is in the handling of the
EXIF:Orientation key, common in images.
[ Tests ]
Upstream test suite.
[ Risks ]
Minimal but if there would be any issue upstream is quick to address them.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock graphicsmagick/1.4+really1.3.40-4
Thanks for considering,
Laszlo/GCS
diff -Nru graphicsmagick-1.4+really1.3.40/debian/changelog graphicsmagick-1.4+really1.3.40/debian/changelog
--- graphicsmagick-1.4+really1.3.40/debian/changelog 2023-01-19 19:44:45.0 +0100
+++ graphicsmagick-1.4+really1.3.40/debian/changelog 2023-04-17 19:17:10.0 +0200
@@ -1,3 +1,19 @@
+graphicsmagick (1.4+really1.3.40-4) unstable; urgency=medium
+
+ * Remove development ifdef from memory leak fix.
+
+ -- Laszlo Boszormenyi (GCS) Mon, 17 Apr 2023 19:17:10 +0200
+
+graphicsmagick (1.4+really1.3.40-3) unstable; urgency=high
+
+ * Backport security fixes:
+- MIFF reader able to provide attribute data in way which results in
+ a heap overflow,
+- SetImageAttribute(): eliminate memory leak when handling attribute
+ with key "EXIF:Orientation".
+
+ -- Laszlo Boszormenyi (GCS) Sun, 16 Apr 2023 14:21:32 +0200
+
graphicsmagick (1.4+really1.3.40-2) unstable; urgency=medium
* Don't force tiff dependency, let shlibs handle it (closes: #1029212).
diff -Nru graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch
--- graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch 1970-01-01 01:00:00.0 +0100
+++ graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch 2023-04-17 19:17:10.0 +0200
@@ -0,0 +1,115 @@
+
+# HG changeset patch
+# User Bob Friesenhahn
+# Date 1681598921 18000
+# Node ID 3ce01217413bb5b476460bbc8ab11020205eeda0
+# Parent 8bec800dbaef2d72da0e7e997ad45bece0e95893
+SetImageAttribute(): Eliminate memory leak when handling attribute with key "EXIF:Orientation"
+
+diff -r 8bec800dbaef -r 3ce01217413b ChangeLog
+--- a/ChangeLog Sat Apr 08 18:31:31 2023 -0500
b/ChangeLog Sat Apr 15 17:48:41 2023 -0500
+@@ -1,3 +1,9 @@
++2023-04-15 Bob Friesenhahn
++
++ * magick/attribute.c (SetImageAttribute): Eliminate memory leak
++ when handling attribute with key "EXIF:Orientation". (SourceForge
++ issue #707 "memory leaks in gm").
++
+ 2023-04-08 Bob Friesenhahn
+
+ * coders/mpc.c (ReadMPCImage): If an attribute appears multiple
+diff -r 8bec800dbaef -r 3ce01217413b coders/miff.c
+--- a/coders/miff.c Sat Apr 08 18:31:31 2023 -0500
b/coders/miff.c Sat Apr 15 17:48:41 2023 -0500
+@@ -761,6 +761,8 @@ SetNewImageAttribute(Image *image,const
+ MagickPassFail
+ status;
+
++ status = SetImageAttribute(image,key,value);
++
+ if (GetImageAttribute(image,key) == (const ImageAttribute *) NULL)
+ status = SetImageAttribute(image,key,value);
+ else
+diff -r 8bec800dbaef -r 3ce01217413b magick/attribute.c
+--- a/magick/attribute.c Sat Apr 08 18:31:31 2023 -0500
b/magick/attribute.c Sat Apr 15 17:48:41 2023 -0500
+@@ -3178,9 +3178,6 @@
+ register ImageAttribute
+ *p;
+
+- int
+-orientation;
+-
+ /*
+ Initialize new attribute.
+ */
+@@ -3271,6 +3268,9 @@
+
+ if (LocaleCompare(attribute->key,"EXIF:Orientation") == 0)
+ {
++ int
++orientation = 0;
++
+ /*
+ Special handling for EXIF orientation tag.
+ If new value differs from existing value,
+@@ -3278,17 +3278,19 @@
+ is valid. Don't append new value to existing value,
+ replace it instead.
+ */
+- orientation = MagickAtoI(value);
+- if (orientation > 0 || orientation <= (int)LeftBottomOrientation)
+-SetEXIFOrientation(image, orientation);
+-
+- /* Replace current attribute with new one */
+- attribute->next = p->next;
+- if (p->previous == (ImageAttribute *) NULL)
+-image->attributes=attribute;
+- else
+-p->previous->next = attribute;
+-
Bug#1034330: unblock: protobuf/3.21.12-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:protobuf
Hi RMs,
Please unblock package protobuf. It's running build time tests with those fixes.
[ Reason ]
It was discovered late that build time tests are not run [1] and the
fix is easy. Reporter stated firmly that he is even going to NMU the
package in unstable and/or stable to fix this issue. My bad that I
thought this change was fully tested and I only checked it on amd64.
Then it turned out build time tests are broken on 32 bit platforms [2].
[ Impact ]
I took my time and fixed build tests. On hppa I had to extend the
ignorance of a static_assert() due to over alignment on this platform.
Now it has a working self-check on package changes including security
ones during Bookworm lifecycle.
[ Tests ]
Upstream test suite. Done build tests with the following rdeps:
clementine and grpc on both i386 and amd64 including tests of those
packages. Those worked without a hitch.
Package tests for migration also worked.
[ Risks ]
Low, the changes are pretty straightforward and only affects the
self-testing parts of the package.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
Uploaded four days ago, built on all previous architectures and no new
bug reports are filed.
unblock protobuf/3.21.12-3
Thanks for considering,
Laszlo/GCS
[1] https://bugs.debian.org/1033989
[2] https://bugs.debian.org/1033998
diff -Nru protobuf-3.21.12/debian/changelog protobuf-3.21.12/debian/changelog
--- protobuf-3.21.12/debian/changelog 2022-12-17 09:18:06.0 +0100
+++ protobuf-3.21.12/debian/changelog 2023-04-09 07:50:55.0 +0200
@@ -1,3 +1,16 @@
+protobuf (3.21.12-3) unstable; urgency=medium
+
+ * Fix build-time tests on 32 bit architectures (closes: #1033998).
+
+ -- Laszlo Boszormenyi (GCS) Sun, 09 Apr 2023 05:50:55 +
+
+protobuf (3.21.12-2) unstable; urgency=medium
+
+ [ Helmut Grohne ]
+ * Reenable build-time testing (closes: #1033989).
+
+ -- Laszlo Boszormenyi (GCS) Wed, 05 Apr 2023 21:57:20 +0200
+
protobuf (3.21.12-1) unstable; urgency=medium
* New upstream release.
diff -Nru protobuf-3.21.12/debian/elpa-test protobuf-3.21.12/debian/elpa-test
--- protobuf-3.21.12/debian/elpa-test 1970-01-01 01:00:00.0 +0100
+++ protobuf-3.21.12/debian/elpa-test 2023-04-05 21:57:20.0 +0200
@@ -0,0 +1 @@
+disable=please_do_run_dh_auto_test
diff -Nru protobuf-3.21.12/debian/patches/build_32_bit_tests.patch protobuf-3.21.12/debian/patches/build_32_bit_tests.patch
--- protobuf-3.21.12/debian/patches/build_32_bit_tests.patch 1970-01-01 01:00:00.0 +0100
+++ protobuf-3.21.12/debian/patches/build_32_bit_tests.patch 2023-04-05 21:57:20.0 +0200
@@ -0,0 +1,140 @@
+From 01c340d0bb9abb2654554afc732df2c89774ce81 Mon Sep 17 00:00:00 2001
+From: Mike Kruskal <62662355+mkruskal-goo...@users.noreply.github.com>
+Date: Mon, 19 Sep 2022 09:50:19 -0700
+Subject: [PATCH] Adding full build to 32 bit tests (#10589)
+
+* Adding full build to 32 bit tests
+
+* Running C++ tests in 32 bit builds
+
+* Patching static assert test failure
+
+* Test fixes for 32-bit architectures
+
+* Cleanup after CMake build
+
+* Save protoc before cleanup
+
+* Route protoc better
+---
+ .../compiler/cpp/message_size_unittest.cc | 2 +-
+ src/google/protobuf/extension_set_unittest.cc | 6 ++--
+ .../protobuf/io/zero_copy_stream_unittest.cc | 3 ++
+ .../protobuf/repeated_field_unittest.cc | 4 +--
+ src/google/protobuf/util/time_util_test.cc| 28 +++
+ 8 files changed, 42 insertions(+), 20 deletions(-)
+
+diff --git a/src/google/protobuf/compiler/cpp/message_size_unittest.cc b/src/google/protobuf/compiler/cpp/message_size_unittest.cc
+index a75d77a70cb..ed4a90e223f 100644
+--- a/src/google/protobuf/compiler/cpp/message_size_unittest.cc
b/src/google/protobuf/compiler/cpp/message_size_unittest.cc
+@@ -139,9 +139,9 @@ TEST(GeneratedMessageTest, OneStringSize) {
+
+ TEST(GeneratedMessageTest, MoreStringSize) {
+ struct MockGenerated : public MockMessageBase { // 16 bytes
+-int has_bits[1]; // 4 bytes
+ int cached_size; // 4 bytes
+ MockRepeatedPtrField data; // 24 bytes
++// + 4 bytes padding
+ };
+ GOOGLE_CHECK_MESSAGE_SIZE(MockGenerated, 48);
+ EXPECT_EQ(sizeof(protobuf_unittest::MoreString), sizeof(MockGenerated));
+diff --git a/src/google/protobuf/extension_set_unittest.cc b/src/google/protobuf/extension_set_unittest.cc
+index 8b436bc20c9..84da3c5465a 100644
+--- a/src/google/protobuf/extension_set_unittest.cc
b/src/google/protobuf/extension_set_unittest.cc
+@@ -852,8 +852,10 @@ TEST(ExtensionSetTest, SpaceUsedExcludingSelf) {
+ const size_t old_ca
Bug#1033203: unblock: fuse3/3.14.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Cyril Brulebois
Control: affects -1 + src:fuse3
Hi RMs,
[ Reason ]
The self-testing of fuse3 only works on little-endian machines. I've
already disabled it on big-endian release architectures. Missed hppa
which is not added to the list.
Compiling examples didn't work due to outdated Makefile and using an
outdated header name in one of the files.
[ Impact ]
With the changes fuse3 is compiled on hppa now. As the installer needs
its udeb it can be created on that architecture as well from now on.
One of the example files was patched to use the current header file
name and now compiles with all of the other example files.
[ Tests ]
I've tested the examples compilation and those are OK now. Compilation
on hppa is now working as can be seen in the buildd logs [1].
[ Risks ]
None of the changes affect the working of the package itself.
As fuse3 has an udeb I put kibi to the loop if extra ACK is needed.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock fuse3/3.14.0-3
Thanks for considering,
Laszlo/GCS
[1] https://buildd.debian.org/status/logs.php?pkg=fuse3=hppa
diff -Nru fuse3-3.14.0/debian/changelog fuse3-3.14.0/debian/changelog
--- fuse3-3.14.0/debian/changelog 2023-02-18 07:22:30.0 +0100
+++ fuse3-3.14.0/debian/changelog 2023-03-17 20:51:05.0 +0100
@@ -1,3 +1,15 @@
+fuse3 (3.14.0-3) unstable; urgency=medium
+
+ [ Helge Deller ]
+ * Add the big-endian hppa platform to the disabled self-testing list
+(closes: #1032187).
+
+ [ Laszlo Boszormenyi (GCS) ]
+ * Update fuse header name in examples.
+ * Fix Makefile for examples (closes: #1031544).
+
+ -- Laszlo Boszormenyi (GCS) Fri, 17 Mar 2023 20:51:05 +0100
+
fuse3 (3.14.0-2) unstable; urgency=medium
* Revert upgrade of fuse_kernel.h for not being upstreamed yet
diff -Nru fuse3-3.14.0/debian/examples/Makefile fuse3-3.14.0/debian/examples/Makefile
--- fuse3-3.14.0/debian/examples/Makefile 2014-06-20 08:23:50.0 +0200
+++ fuse3-3.14.0/debian/examples/Makefile 2023-03-17 20:51:05.0 +0100
@@ -1,12 +1,16 @@
-CFLAGS := -Wall $(shell pkg-config fuse --cflags)
-LDFLAGS := $(shell pkg-config fuse --libs)
+CFLAGS := -Wall $(shell pkg-config fuse3 --cflags)
+LDFLAGS := $(shell pkg-config fuse3 --libs)
-targets = fusexmp fusexmp_fh hello hello_ll null
+targets = cuse cuse_client hello hello_ll \
+ invalidate_path ioctl ioctl_client \
+ notify_inval_entry notify_inval_inode notify_store_retrieve \
+ null passthrough passthrough_fh passthrough_ll \
+ poll poll_client printcap
-all: $(targets)
+%: %.c
+ $(CC) $(CFLAGS) $< -o $@ $(LDFLAGS)
-fusexmp_fh: fusexmp_fh.c
- $(CC) $(CFLAGS) $(LDFLAGS) -lulockmgr $< -o $@
+all: $(targets)
clean:
rm -f *.o
diff -Nru fuse3-3.14.0/debian/patches/series fuse3-3.14.0/debian/patches/series
--- fuse3-3.14.0/debian/patches/series 2023-02-18 07:22:30.0 +0100
+++ fuse3-3.14.0/debian/patches/series 2023-03-17 20:51:05.0 +0100
@@ -1 +1,2 @@
revert_upgrade_of_fuse_kernel.h.patch
+update_header_name.patch
diff -Nru fuse3-3.14.0/debian/patches/update_header_name.patch fuse3-3.14.0/debian/patches/update_header_name.patch
--- fuse3-3.14.0/debian/patches/update_header_name.patch 1970-01-01 01:00:00.0 +0100
+++ fuse3-3.14.0/debian/patches/update_header_name.patch 2023-03-17 20:51:05.0 +0100
@@ -0,0 +1,21 @@
+Description: use new header name of fuse
+ Just rename fuse_config.h to libfuse_config.h
+Author: Laszlo Boszormenyi (GCS)
+Bug-Debian: https://bugs.debian.org/1031544
+Forwarded: no
+Last-Update: 2023-03-17
+
+---
+
+
+--- fuse3-3.14.0.orig/example/poll_client.c
fuse3-3.14.0/example/poll_client.c
+@@ -19,7 +19,7 @@
+ * \include poll_client.c
+ */
+
+-#include
++#include
+
+ #include
+ #include
diff -Nru fuse3-3.14.0/debian/rules fuse3-3.14.0/debian/rules
--- fuse3-3.14.0/debian/rules 2023-01-22 08:17:08.0 +0100
+++ fuse3-3.14.0/debian/rules 2023-03-17 20:51:05.0 +0100
@@ -54,7 +54,7 @@
override_dh_auto_test:
ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
-ifeq (,$(findstring $(DEB_BUILD_ARCH),powerpc ppc64 sparc64 s390x))
+ifeq (,$(findstring $(DEB_BUILD_ARCH),powerpc ppc64 sparc64 s390x hppa))
(cd obj-${DEB_HOST_GNU_TYPE}; python3 -m pytest test/) \
|| true
endif
Bug#1033197: unblock: sqlite3/3.40.1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Cyril Brulebois
Control: affects -1 + src:sqlite3
Hi RMs,
[ Reason ]
Cyril Brulebois (kibi) who is the maintainer of crowdsec found out
that partial upgrade of Bullseye to Bookworm may render it unable to
start. Reason is, sqlite3 with 3.37.0-1 changed its internal
table_info representation. Previously the column types were in
lowercase letters and from this version these are using uppercase
letters - confusing the Bullseye version of crowdsec. With the version
in Bookworm it is already fixed.
[ Impact ]
Upgrading only libsqlite3-0 but not crowdsec makes the latter unusable
as it will not start. To prevent such situations I've added breaks on
old crowdsec versions.
[ Tests ]
Kibi did the testing [1] and the fix only prevents incompatible
versions of the mentioned packages to be installed.
[ Risks ]
Basically nothing.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock sqlite3/3.40.1-2
Thanks for consideration,
Laszlo/GCS
[1] https://bugs.debian.org/1033029
diff -Nru sqlite3-3.40.1/debian/changelog sqlite3-3.40.1/debian/changelog
--- sqlite3-3.40.1/debian/changelog 2022-12-31 09:41:40.0 +0100
+++ sqlite3-3.40.1/debian/changelog 2023-03-16 19:54:28.0 +0100
@@ -1,3 +1,12 @@
+sqlite3 (3.40.1-2) unstable; urgency=medium
+
+ [ Cyril Brulebois ]
+ * Add Breaks against crowdsec as found in bullseye, as it relies on a
+particular table_info format, which changes between 3.36.0 and 3.37.0
+(closes: #1033029).
+
+ -- Laszlo Boszormenyi (GCS) Thu, 16 Mar 2023 19:54:28 +0100
+
sqlite3 (3.40.1-1) unstable; urgency=medium
* New upstream release.
diff -Nru sqlite3-3.40.1/debian/control sqlite3-3.40.1/debian/control
--- sqlite3-3.40.1/debian/control 2022-12-31 09:41:40.0 +0100
+++ sqlite3-3.40.1/debian/control 2023-03-16 19:54:28.0 +0100
@@ -52,7 +52,7 @@
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
-Breaks: python-migrate (<< 0.11.0-4~), python3-migrate (<< 0.11.0-4~)
+Breaks: python-migrate (<< 0.11.0-4~), python3-migrate (<< 0.11.0-4~), crowdsec (<< 1.4)
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Description: SQLite 3 shared library
Bug#1032526: [pre-approval] unblock: dar/2.7.8-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: jgoer...@complete.org
Control: affects -1 + src:dar
Hi RMs,
Please pre-approve a feature enabled version of dar.
[ Reason ]
John Goerzen updated build dependencies to reflect the libext2fs-dev
rename, added delta changes support with rsync (previously I've not
enabled it as it didn't have the static library to use with
dar-static) and use Linux capabilities support.
[ Impact ]
Users will get a more feature rich version of dar.
[ Tests ]
The delta changes testing done by John, I did only build and basic testing.
[ Risks ]
I don't know any. No code change, only enable features that are
present in the source code already.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
Thanks for consideration,
Laszlo/GCS
diff -Nru dar-2.7.8/debian/changelog dar-2.7.8/debian/changelog
--- dar-2.7.8/debian/changelog 2022-12-04 15:57:33.0 +0100
+++ dar-2.7.8/debian/changelog 2023-03-08 18:14:41.0 +0100
@@ -1,3 +1,17 @@
+dar (2.7.8-2) unstable; urgency=medium
+
+ [ John Goerzen ]
+ * Support delta changes via librsync.
+ * Update dep on e2fslibs-dev to new name libext2fs-dev
+ * Add dep on libcap-dev to eneable proper capability handling.
+ * Add build-dependency on dot to ensure figures for docs are always
+built.
+
+ [ Laszlo Boszormenyi (GCS) ]
+ * Build depend on libcap-dev only on Linux architectures.
+
+ -- Laszlo Boszormenyi (GCS) Wed, 08 Mar 2023 18:14:41 +0100
+
dar (2.7.8-1) unstable; urgency=medium
* New upstream release.
diff -Nru dar-2.7.8/debian/control dar-2.7.8/debian/control
--- dar-2.7.8/debian/control 2022-12-04 15:57:33.0 +0100
+++ dar-2.7.8/debian/control 2023-03-08 18:14:41.0 +0100
@@ -3,9 +3,11 @@
Priority: optional
Maintainer: Laszlo Boszormenyi (GCS)
Build-Depends: debhelper-compat (= 13), pkg-config, zlib1g-dev, libbz2-dev,
- libzstd-dev, liblzo2-dev, liblzma-dev, liblz4-dev, e2fslibs-dev,
- libgcrypt20-dev, libgpgme-dev, libassuan-dev, libargon2-dev, doxygen, groff
-Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev, librsync-dev
+ libzstd-dev, liblzo2-dev, liblzma-dev, liblz4-dev, libext2fs-dev,
+ libgcrypt20-dev, libgpgme-dev, libassuan-dev, libargon2-dev,
+ librsync-dev, libcap-dev [linux-any],
+ doxygen, groff, graphviz
+Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev
Standards-Version: 4.6.1
Rules-Requires-Root: no
Homepage: http://dar.linux.free.fr/
diff -Nru dar-2.7.8/debian/rules dar-2.7.8/debian/rules
--- dar-2.7.8/debian/rules 2022-12-04 15:57:33.0 +0100
+++ dar-2.7.8/debian/rules 2023-03-08 18:14:41.0 +0100
@@ -4,13 +4,18 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
+DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
+
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
DEB_CONFIGURE_EXTRA_FLAGS := --disable-upx --disable-python-binding \
--enable-mode=64
DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
-BUILT_USING_PACKAGES = libc-dev-bin libattr1-dev libbz2-dev libgcrypt20-dev libgpgme-dev liblzo2-dev zlib1g-dev libzstd-dev liblz4-dev libargon2-dev libassuan-dev
+BUILT_USING_PACKAGES = libc-dev-bin libbz2-dev libgcrypt20-dev libgpgme-dev liblzo2-dev zlib1g-dev libzstd-dev liblz4-dev libargon2-dev libassuan-dev librsync-dev libext2fs-dev
+ifeq ($(DEB_HOST_ARCH_OS), linux)
+BUILT_USING_PACKAGES += libcap-dev
+endif
BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W $(BUILT_USING_PACKAGES))
Bug#1027283: transition: tiff
On Tue, Jan 10, 2023 at 10:32 PM Sebastian Ramacher wrote: > On 2023-01-08 09:07:37 +0100, László Böszörményi wrote: > > Transition can start anytime upon RM decision. > > Please go ahead. Thanks, uploaded yesterday evening. Almost all builds are already done. Cheers, Laszlo/GCS
Bug#1027283: transition: tiff
On Sat, Dec 31, 2022 at 1:04 PM Sebastian Ramacher wrote: > On 2022-12-29 18:19:58 +0100, László Böszörményi wrote: > > As tiff is used commonly and has security issues from time to time it > > would be good to have its latest release in Debian. I don't know if > > the old version will get any fixes or not. > > Understood. Please let us know once you're done with the test rebuilds > and have filed all bugs. The situation has improved: gtk4 has been fixed and I've provided drop-in patches for the other two, qtimageformats-opensource-src and hylafax. Transition can start anytime upon RM decision. Regards, Laszlo/GCS
Bug#1028118: transition: rocksdb
On Sat, Jan 7, 2023 at 11:53 AM Sebastian Ramacher wrote: > On 2023-01-07 08:42:37 +0100, László Böszörményi wrote: > > I hope this transition gets green light despite this dependency > > problem that needs to be resolved anyway. Main reason is a specific > > memory corruption error fix in the 7.8.1 version of RocksDB. > > Please go ahead. Thanks, uploaded and just got accepted. Cheers, Laszlo/GCS
Bug#1028118: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Small transition of RocksDB to version 7.8.3 as the affected packages are limited to balboa and sortmerna. Both build fine on amd64 with this new RocksDB version. While version 7.8.3 [1] has some new features, but has a bunch of bug fixes that would be good to have for Bookworm. The only drawback is sortmerna which is no longer built on i386 [2] since the end of last November and can't migrate to testing due to this. Reason seems to be either architecture misdetection or just that it doesn't support i386 architectures anymore. Failing message is: error: inlining failed in call to ‘always_inline’ ‘_mm_set1_epi8’: target specific option mismatch I hope this transition gets green light despite this dependency problem that needs to be resolved anyway. Main reason is a specific memory corruption error fix in the 7.8.1 version of RocksDB. Thanks for considering, Laszlo/GCS [1] https://github.com/facebook/rocksdb/releases/tag/v7.8.3 [2] https://buildd.debian.org/status/logs.php?pkg=sortmerna=i386
Bug#1027283: transition: tiff
Control: tags -1 -moreinfo On Sat, Dec 31, 2022 at 1:04 PM Sebastian Ramacher wrote: > On 2022-12-29 18:19:58 +0100, László Böszörményi wrote: > > As tiff is used commonly and has security issues from time to time it > > would be good to have its latest release in Debian. I don't know if > > the old version will get any fixes or not. > Understood. Please let us know once you're done with the test rebuilds > and have filed all bugs. Tested all affected packages on amd64 except Sid only ones. Failing qtimageformats-opensource-src and gtk4 due to self-testing those; bugs are filed with patches [1][2]. There's one package in question, hylafax which seems to have dead upstream and low popcon [3]. It uses internal tiff constant arrays which are no longer being exported. If the package is about to be kept in the archives, it needs to copy those arrays to its source. Unfortunately its package maintainers seems to be inactive with this package at least. Regards, Laszlo/GCS [1] https://bugs.debian.org/1027679 [2] https://bugs.debian.org/1027680 [3] https://bugs.debian.org/1027681
Bug#1027283: transition: tiff
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Unplanned transition of tiff as its new release is just recently out. The API seems to be the same, but the ABI is changed. Basic reason is that its behaviour is changed and returns quicker from processing invalid images. While it's a big transition, nine levels deep, test rebuilds show in the first five levels only two package self-testing breaks. I've already patched one of them. Currently it only hard breaks hylafax which seems to be a dead project since 2012; a memory corruption and a security fix was committed to it, but even those happened in 2018 or earlier. Anyway, I've notified tiff upstream and will act accordingly. As tiff is used commonly and has security issues from time to time it would be good to have its latest release in Debian. I don't know if the old version will get any fixes or not. Regards, Laszlo/GCS
Bug#1027264: bullseye pu: traceroute/2.1.0-2+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Hi RMs,
Quite recently a new traceroute version was released. Most importantly
it fixes an excessive CPU consumption on one core (it's not
multi-threaded). It's easy to trigger it, but not considered a
security issue. All you have to do is to try an IPv4 mapped IPv6
address:
$ traceroute :::127.0.0.1
One CPU core will go on 100% and it will not stop until you ^C or kill
it. The fix is small and could be backported easily. It is tested,
builds correctly and fixes this issue on Bullseye.
Thanks for considering,
Laszlo/GCS
diff -Nru traceroute-2.1.0/debian/changelog traceroute-2.1.0/debian/changelog
--- traceroute-2.1.0/debian/changelog 2016-08-29 17:45:51.0 +0200
+++ traceroute-2.1.0/debian/changelog 2022-12-29 08:27:50.0 +0100
@@ -1,3 +1,10 @@
+traceroute (1:2.1.0-2+deb11u1) bullseye; urgency=medium
+
+ * Backport upstream fix to interpret ipv4-mapped ipv6 addresses
+(:::A.B.C.D) as true ipv4.
+
+ -- Laszlo Boszormenyi (GCS) Thu, 29 Dec 2022 08:27:50 +0100
+
traceroute (1:2.1.0-2) unstable; urgency=low
* Update Standards-Version to 3.9.8 .
diff -Nru traceroute-2.1.0/debian/patches/08-interpret_ipv4-mapped_ipv6_addresses.patch traceroute-2.1.0/debian/patches/08-interpret_ipv4-mapped_ipv6_addresses.patch
--- traceroute-2.1.0/debian/patches/08-interpret_ipv4-mapped_ipv6_addresses.patch 1970-01-01 01:00:00.0 +0100
+++ traceroute-2.1.0/debian/patches/08-interpret_ipv4-mapped_ipv6_addresses.patch 2022-12-29 01:32:42.0 +0100
@@ -0,0 +1,18 @@
+--- a/traceroute/traceroute.c 2016-03-07 23:17:23.0 +0100
b/traceroute/traceroute.c 2022-12-27 01:28:15.0 +0100
+@@ -223,6 +223,15 @@
+
+ freeaddrinfo (res);
+
++ /* No v4mapped addresses in real network, interpret it as ipv4 anyway */
++ if (addr->sa.sa_family == AF_INET6 &&
++ IN6_IS_ADDR_V4MAPPED (>sin6.sin6_addr)
++ ) {
++ if (af == AF_INET6) return -1;
++ addr->sa.sa_family = AF_INET;
++ addr->sin.sin_addr.s_addr = addr->sin6.sin6_addr.s6_addr32[3];
++ }
++
+ return 0;
+ }
+
diff -Nru traceroute-2.1.0/debian/patches/series traceroute-2.1.0/debian/patches/series
--- traceroute-2.1.0/debian/patches/series 2016-08-29 17:45:51.0 +0200
+++ traceroute-2.1.0/debian/patches/series 2022-12-29 01:34:20.0 +0100
@@ -5,3 +5,4 @@
05-manpage-p.patch
06-build.patch
07-reproducible-build.patch
+08-interpret_ipv4-mapped_ipv6_addresses.patch
Bug#1025541: transition: grpc
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Hi RMs,
Small transition of grpc as only a few packages are reverse
dependencies - even if llvm-toolchain-* are heavy ones.
I've provided patches for fastnetmon [1] and open-vm-tools [2]. Then
llvm-toolchain-13 already has two FTBFS problems, didn't encounter a
new one with grpc or just failed to build before I could experience
that.
I've provided the solution for llvm-toolchain-1{4,5} [3][4], but I
couldn't find time to fix those by myself.
Regards,
Laszlo/GCS
[1] https://bugs.debian.org/1025490
[2] https://bugs.debian.org/1025491
[3] https://bugs.debian.org/1025529
[4] https://bugs.debian.org/1025530
Bug#1023535: transition: protobuf
Hi Sebastian, On Thu, Nov 24, 2022 at 9:03 PM Sebastian Ramacher wrote: > On 2022-11-21 20:42:41 +0100, Sebastian Ramacher wrote: > > Please go ahead > > protobuf's autopkgtests are failing. Could you please take a look at > them? Thanks Indeed, my bad. Fixed and uploaded. Regards, Laszlo/GCS
Bug#1022248: transition: icu
On Tue, Nov 8, 2022 at 2:00 AM Sebastian Ramacher wrote: > On 2022-10-30 14:08:55 +0100, László Böszörményi wrote: > > Package 0ad and gnucash fail to build [1][2] with ICU 72.1 and bugs are > > filed. > > Package supercollider failed to build due to another issue [3]. Its > > packaging Git has a working fix and after applying that it was built > > with ICU 72.1 as well. > > Alright, please go ahead. Friendly ping on what needs to be done for this transition? ICU itself migrated to testing more than a week ago. Thunderbird, the last reverse dependency needed for this transition, just migrated. Other reverse dependencies are already Sid only. How can I check what's still missing? Thanks, Laszlo/GCS
Bug#1023955: transition: rocksdb
On Sun, Nov 13, 2022 at 1:54 PM Sebastian Ramacher wrote: > It doesn't conflict with any other ongoing transitions, so please go > ahead. Thanks, uploaded. Cheers, Laszlo/GCS
Bug#1023955: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Simple transition of RocksDB to version 7.7.3 as only balboa is affected. It builds fine with the new RocksDB version in experimental as well. I think it may start immediately, but it's your decision of course. Regards, Laszlo/GCS
Bug#1023535: transition: protobuf
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, There's a long awaited transition of Protobuf. It clashes with the ruby3.1-default transition, but as I know its rebuilds are just starting[1]. On the other hand I'm done with the rebuilds and patched all issues, this transition may start immediately at your decision. The only downside is that the Sid version of cura-engine is FTBFS and to fix it, the libarcus transition (only affecting this package) will need to be done. Failing packages and fixes in detail. Level 2: android-platform-frameworks-base has my patch already applied [2] for experimental (not Sid!). libarcus builds in Sid, but not the version in experimental for which I provided a fix [3]. target-factory changed library symbols [4], maintainer will need to update that. Level 3: cura-engine fails with the Sid version [5], with the libarcus transition done it compiles fine. grpc-java for which I provided the fix [6], the maintainer noted he will be ready to update the package. llvm-toolchain-13 for which I provided the fix [7], other problems seem to be fixed with the upload just happened. llvm-toolchain-14 for which I also provided the fix [8], its other problem [9] might be wrongly closed by cross referenced llvm-toolchain-15 package - but Sylvestre Ledru seems to be aware of issues anyway. Thanks for considering, Laszlo/GCS [1] https://bugs.debian.org/1023495#5 [2] https://bugs.debian.org/1012572 [3] https://bugs.debian.org/1023497 [4] https://bugs.debian.org/1023496 [5] https://bugs.debian.org/1023498 [6] https://bugs.debian.org/1023500 [7] https://bugs.debian.org/1023532 [8] https://bugs.debian.org/1023532 [9] https://bugs.debian.org/1023444
Bug#1022248: transition: icu
Control: tags -1 -moreinfo On Thu, Oct 27, 2022 at 11:39 PM Sebastian Ramacher wrote: > On 2022-10-22 19:17:58 +0200, László Böszörményi wrote: > > Transition is similar to the previous ones, this time boost1.74 needs > > to be binNMUed after level1 before other level2 packages and pyicu > > will need a sourceful upload (its Git version seems to be ready, but I > > wait for its release). > > I've set up the tracker. Please remove the moreinfo tag once the test > builds are done. I can report the following. Rebuilds are done and pyicu (Python wrapper for ICU) supporting 72.1 is released and packaged. Two immediate problems were found and fixed by its upstream. It can be binNMUed for ICU 72.1 version. Package nodejs further updated for Sid, flaky test remained. Wile it builds on buildd machines, locally I get: not ok 3161 sequential/test-debugger-preserve-breaks # TODO : Fix flaky test duration_ms: 31.372 severity: flaky exitcode: 1 Package 0ad and gnucash fail to build [1][2] with ICU 72.1 and bugs are filed. Package supercollider failed to build due to another issue [3]. Its packaging Git has a working fix and after applying that it was built with ICU 72.1 as well. Cheers, Laszlo/GCS [1] https://bugs.debian.org/1023121 [2] https://bugs.debian.org/1023122 [3] https://bugs.debian.org/1019995
Bug#1022248: transition: icu
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, My intention is to release Bookworm with ICU 72.1 which is already packaged and is in experimental. As Sid has the previous,71.1 release the transition is plain, I don't expect any breakage. The rebuilds are ongoing and only level1 and level2 are ready at this time. Transition is similar to the previous ones, this time boost1.74 needs to be binNMUed after level1 before other level2 packages and pyicu will need a sourceful upload (its Git version seems to be ready, but I wait for its release). The only FTBFS is from the Sid version of nodejs (18.10.0+dfsg-6) due to a flaky self-test - its experimental version (18.11.0+dfsg-3) doesn't suffer from it. I will post more when I build all levels of the transition. Regards, Laszlo/GCS
Bug#1020685: transition: thrift
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Small transition of Thrift as the only reverse dependency is gnuradio. It builds fine with the 0.17.0 version of Thrift already in experimental. Thanks for considering, Laszlo/GCS
Bug#1020684: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Small transition of RocksDB as the only reverse dependency is balboa. It builds fine with the 7.6.0 version of RocksDB already in experimental. Thanks for considering, Laszlo/GCS
Bug#1018214: bullseye-pu: package rocksdb/6.11.4-3+deb11u1
Package: release.debian.org
User: release.debian@packages.debian.org
Tags: bullseye
Severity: normal
Hi RMs,
Another DD reported and patched [1] a SIGILL in RocksDB on specific
arm64 platforms. The patch is official and quite straight forward,
attached.
As the bug is in a common, low level function (CRC calculation) it
prevents him from using this package on his computer.
Thanks for consideration,
Laszlo/GCS
[1] https://bugs.debian.org/1015224
diff -Nru rocksdb-6.11.4/debian/changelog rocksdb-6.11.4/debian/changelog
--- rocksdb-6.11.4/debian/changelog 2020-12-10 18:13:16.0 +0100
+++ rocksdb-6.11.4/debian/changelog 2022-08-27 08:59:02.0 +0200
@@ -1,3 +1,10 @@
+rocksdb (6.11.4-3+deb11u1) bullseye; urgency=medium
+
+ [ Daniel Leidert ]
+ * Fix illegal instruction on arm64 (closes: #1015224).
+
+ -- Laszlo Boszormenyi (GCS) Sat, 27 Aug 2022 08:59:02 +0200
+
rocksdb (6.11.4-3) unstable; urgency=medium
* Explicitly link shared library with dynamic linking library
diff -Nru rocksdb-6.11.4/debian/patches/fix_illegal_instruction.patch rocksdb-6.11.4/debian/patches/fix_illegal_instruction.patch
--- rocksdb-6.11.4/debian/patches/fix_illegal_instruction.patch 1970-01-01 01:00:00.0 +0100
+++ rocksdb-6.11.4/debian/patches/fix_illegal_instruction.patch 2022-08-27 08:55:55.0 +0200
@@ -0,0 +1,225 @@
+From 29f7bbef995bdf83098963799c66af742e95373f Mon Sep 17 00:00:00 2001
+From: Yuqi Gu
+Date: Tue, 22 Sep 2020 10:39:54 -0700
+Subject: [PATCH] Fix RocksDB SIGILL error on Raspberry PI 4 (#7233)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Summary:
+Issue：https://github.com/facebook/rocksdb/issues/7042
+
+No PMULL runtime check will lead to SIGILL on a Raspberry pi 4.
+
+Leverage 'getauxval' to get Hardware-Cap to detect whether target
+platform does support PMULL or not in runtime.
+
+Consider the condition that the target platform does support crc32 but not support PMULL.
+In this condition, the code should leverage the crc32 instruction
+rather than skip all hardware crc32 instruction.
+
+Pull Request resolved: https://github.com/facebook/rocksdb/pull/7233
+
+Reviewed By: jay-zhuang
+
+Differential Revision: D23790116
+
+fbshipit-source-id: a3ebd821fbd4a38dd2f59064adbb7c3013ee8140
+---
+ util/crc32c.cc | 6 +++
+ util/crc32c_arm64.cc | 111 ++-
+ util/crc32c_arm64.h | 1 +
+ 3 files changed, 74 insertions(+), 44 deletions(-)
+
+Index: rocksdb-6.11.4/util/crc32c.cc
+===
+--- rocksdb-6.11.4.orig/util/crc32c.cc
rocksdb-6.11.4/util/crc32c.cc
+@@ -41,6 +41,10 @@
+
+ #endif
+
++#if defined(__linux__) && defined(HAVE_ARM64_CRC)
++bool pmull_runtime_flag = false;
++#endif
++
+ namespace ROCKSDB_NAMESPACE {
+ namespace crc32c {
+
+@@ -494,6 +498,7 @@ std::string IsFastCrc32Supported() {
+ if (crc32c_runtime_check()) {
+ has_fast_crc = true;
+ arch = "Arm64";
++pmull_runtime_flag = crc32c_pmull_runtime_check();
+ } else {
+ has_fast_crc = false;
+ arch = "Arm64";
+@@ -1224,6 +1229,7 @@ static inline Function Choose_Extend() {
+ return isAltiVec() ? ExtendPPCImpl : ExtendImpl;
+ #elif defined(__linux__) && defined(HAVE_ARM64_CRC)
+ if(crc32c_runtime_check()) {
++pmull_runtime_flag = crc32c_pmull_runtime_check();
+ return ExtendARMImpl;
+ } else {
+ return ExtendImpl;
+Index: rocksdb-6.11.4/util/crc32c_arm64.cc
+===
+--- rocksdb-6.11.4.orig/util/crc32c_arm64.cc
rocksdb-6.11.4/util/crc32c_arm64.cc
+@@ -14,6 +14,9 @@
+ #ifndef HWCAP_CRC32
+ #define HWCAP_CRC32 (1 << 7)
+ #endif
++#ifndef HWCAP_PMULL
++#define HWCAP_PMULL (1 << 4)
++#endif
+
+ #ifdef HAVE_ARM64_CRYPTO
+ /* unfolding to compute 8 * 3 = 24 bytes parallelly */
+@@ -35,6 +38,8 @@
+ } while (0)
+ #endif
+
++extern bool pmull_runtime_flag;
++
+ uint32_t crc32c_runtime_check(void) {
+ #ifdef ROCKSDB_AUXV_GETAUXVAL_PRESENT
+ uint64_t auxv = getauxval(AT_HWCAP);
+@@ -44,6 +49,15 @@ uint32_t crc32c_runtime_check(void) {
+ #endif
+ }
+
++bool crc32c_pmull_runtime_check(void) {
++#ifdef ROCKSDB_AUXV_GETAUXVAL_PRESENT
++ uint64_t auxv = getauxval(AT_HWCAP);
++ return (auxv & HWCAP_PMULL) != 0;
++#else
++ return false;
++#endif
++}
++
+ #ifdef ROCKSDB_UBSAN_RUN
+ #if defined(__clang__)
+ __attribute__((__no_sanitize__("alignment")))
+@@ -58,6 +72,13 @@ uint32_t crc32c_arm64(uint32_t crc, unsi
+ int length = (int)len;
+ crc ^= 0x;
+
++ /*
++ * Pmull runtime check here.
++ * Raspberry Pi supports crc32 but doesn't support pmull.
++ * Skip Crc32c Parallel computation if no crypto extension available.
++ */
++ if (pmull_runtime_flag) {
++/* Macro (HAVE_ARM64_CRYPTO) is used for compiling check */
+ #ifdef HAVE_ARM64_CRYPTO
+ /* Crc32c Parallel computation
+ * Algori
Bug#1016724: transition: libwebsockets
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Long overdue transition of libwebsockets. Its dependencies with two notes compiles well with the new 4.1.6 version from experimental as well. Note 1 is that forked-daapd is not tried, already FTBFS due to other reasons and already Sid only due to that. Note 2: For the first time the _self testing_ of swupdate failed to build with parallelity of -j12. The linker couldn't find its symbols. With -j1 and next -j12 setting, it built fine. Thanks in advance, Laszlo/GCS
Bug#1016405: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Small transition of RocksDB from 7.2.2 to 7.3.1 which affects only balboa. I've rebuilt it successfully. Thanks for considering, Laszlo/GCS
Re: FUSE 3 transition
On Thu, Jul 28, 2022 at 9:56 PM Ben Hutchings wrote: > - Is there a plan to change reverse-dependencies to depend on fuse3, so > that such conflicts don't occur? Please note I do not maintain the reverse dependent fuse2 packages. But I will ping those maintainers as I don't want to ship Bookworm with fuse2. Its development stopped two years ago and fuse3 is here for six years. I think it was enough time to adapt to it. Laszlo/GCS
Bug#1012348: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Transition request to show my intentions and track what's blocking. Two packages, balboa and python-rocksdb are affected with the rocksdb 7.2.2 transition. The former builds fine while the latter uses a library header that was changed big and renamed. Its upstream did some updates [1] but not finished. Package maintainer is noted days ago [2]. I don't know how long python-rocksdb upstream will take for the update. :( Thanks for considering, Laszlo/GCS [1] https://github.com/NightTsarina/python-rocksdb/commit/be185cc96df366dc81bd46466341e7057d7775b6 [2] https://bugs.debian.org/1012074
Bug#1007905: transition: icu
On Fri, Apr 22, 2022 at 7:30 PM Sebastian Ramacher wrote: > Control: tags -1 = confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-icu.html > > On 2022-04-13 17:24:20 +0200, László Böszörményi wrote: > > LibreOffice self-testing, especially its break iterator test fails for > > the Lao language. Otherwise everything was fine. But I think I might > > redo the rebuilds (only on amd64 now) to test everything with the > > final release of ICU. If that's not mandatory, I think ICU is quite OK > > for a transition soon. > > Please go ahead Thanks! Quick status update. ICU uploaded (with an additional functionality and one security fix from upstream) and built on all release and other !kfreebsd architectures already (well, alpha still building it). There's an autopkgtest regression with rspamd on i386 with its 'install' check: it is installed and started, but curl can't connect to the listening socket; I don't see it's due to ICU and I think I'll ask for its testing again. Package boost1.74 was binNMUed already, rebuilt on all architectures, expect on hppa where its bootstrap failed with 'Unknown target type EXE'. Doesn't sound ICU related. Matching pyicu was also uploaded and built on all possible architectures. I'm going to file an RM bug for icu-le-hb for being an abandoned (and unused) project for a while now. Meaning these two packages don't need a binNMU. I have to attend an event this afternoon but will continue watching this transition and act if needed. Regards, Laszlo/GCS
Bug#1007905: transition: icu
On Fri, Apr 15, 2022 at 8:48 AM Rene Engelhard wrote: > Am 13.04.22 um 17:52 schrieb Rene Engelhard: > > Am 13.04.22 um 17:24 schrieb László Böszörményi (GCS): > >> LibreOffice self-testing, especially its break iterator test fails for > >> the Lao language. > > > > https://cgit.freedesktop.org/libreoffice/core/commit/?id=263961306ede0656ebb7904034a2172615ce81d0 > > Nevermind, that one is already there. > > But it fails because it does != 70 and 71 still is affected. > > So we just need to extend it. Submitted it uptream in > https://gerrit.libreoffice.org/c/core/+/133063/1/i18npool/qa/cppunit/test_breakiterator.cxx > and will backport it to the 7.3.3 packages. Your patch has a glitch. The U_ICU_VERSION_MAJOR_NUM check must be strictly lower than 70 for word boundary equal to nine. If it's ICU version 70 or higher, the else case should be hit. Ie: #if (U_ICU_VERSION_MAJOR_NUM < 70) is the correct check IMHO. Regards, Laszlo/GCS
Bug#1007905: transition: icu
On Wed, Apr 13, 2022 at 2:36 PM Jeremy Bicha wrote: > mozjs78 and mozjs91 now no longer have an ICU dependency in Unstable. > > 0ad was fixed also. Thanks. Did the rebuild locally on i386 and amd64; started with the ICU 71.1 RC release and finished with the final release if that matters. Only used Sid versions, didn't try the ones in experimental. The following is the result. icu-le-hb is outdated, need to be removed; pyicu needs an update that I've locally. gnucash self-testing fails with its C and Golang tests. The former can be fixed by adding tzdata build dependency and not yet checked the latter. LibreOffice self-testing, especially its break iterator test fails for the Lao language. Otherwise everything was fine. But I think I might redo the rebuilds (only on amd64 now) to test everything with the final release of ICU. If that's not mandatory, I think ICU is quite OK for a transition soon. Regards, Laszlo/GCS
Bug#1008823: transition: thrift
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, A quick transition of thrift from 0.13.0 to 0.16.0 as the only reverse build dependency is gnuradio. It builds with the new thrift version as well. Thanks for considering, Laszlo/GCS
Bug#1007905: transition: icu
On Sat, Mar 19, 2022 at 8:28 AM Adrian Bunk wrote: > On Fri, Mar 18, 2022 at 06:05:38PM +, Simon McVittie wrote: > > Obviously all these copies of essentially the same codebase are quite > > unfortunate, but mozjs and ICU seem to be sufficiently tightly-coupled > > that perhaps using its vendored version of ICU, at least temporarily, > > would be wiser than using the system copy? > > IMHO unblocking GNOME by temporarily making mozjs91 use its vendored > version until the ICU transition would be a reasonable approach. OK. > > On Fri, 18 Mar 2022 at 18:26:41 +0100, László Böszörményi (GCS) wrote: > > > Speak of the devil. ICU 71.1 RC [1] just released. Final is expected > > > in April (two-three weeks). Would you two mind if I package it and ask > > > for testing of your packages (mozjs91 and nodejs) against it? > > > > Speaking only for myself, I'm flexible about timings for this; but Ubuntu > > has already done the ICU 70.1 transition and is currently using it for > > their next LTS release, and 2-3 weeks is probably too late for them to > > do another transition before their freeze deadline. Can you elucidate why Ubuntu would be forced to do the ICU 71.1 transition for their current to be released LTS version? > Does Ubuntu even care either way? I think no. > AFAIK both now and in 2-3 weeks is inside their freeze. Exactly. As Matthias noted, we were in contact and helped them a bit for doing the transition in Ubuntu. Blame me that I didn't start ICU transition at the same time for Debian. Now a status update in short. ICU 71.1 RC looks identical in API sense to ICU 70.1 meaning all packages fail or build the same way with both versions. I've packaged ICU 71.1 RC at least and restarted the rebuilds on i386 _and_ amd64 parallel. This slowed me down, but I can report the following. Package haskell-text-icu FTBFS, but the patch I've provided [1] still fixes the issue. As noted, mozjs78 and 0ad FTBFS in my pbuilder setups. Other packages are built with ICU 70.1 and I'm at level3 with ICU 71.1 RC. Already built ceph, chromium and postgresql-14 with it on that level. Any objection not to upload ICU 71.1 RC to experimental right now? Regards, Laszlo/GCS [1] https://bugs.debian.org/1004093
Bug#1007905: transition: icu
On Fri, Mar 18, 2022 at 5:38 PM László Böszörményi (GCS) wrote: > I didn't file those bugs, but started patching those and filed only > when succeeded. At this point I remember only two packages that FTBFS > with ICU 70.1 and I couldn't fix those. One is mozjs78 and the other > is 0ad. I had trouble with PostgreSQL, but that has a new major > upstream release uploaded since then, meaning it needs to be > re-tested. Speak of the devil. ICU 71.1 RC [1] just released. Final is expected in April (two-three weeks). Would you two mind if I package it and ask for testing of your packages (mozjs91 and nodejs) against it? Regards, Laszlo/GCS [1] https://icu.unicode.org/download/71
Bug#1007905: transition: icu
Hi all, On Fri, Mar 18, 2022 at 1:42 PM Sebastian Ramacher wrote: > On 2022-03-18 13:06:13, Jérémy Lal wrote: > > FYI same here, i had to fallback to nodejs 14 instead of 16 because of that. > > Last time I asked, icu maintainer had issues fixing icu reverse > > build-dependencies. > > He probably needs help ? > > Have those bugs already been filed? Otherwise, filing bugs for the > reverse dependencies that FTBFS would be a good first step. I didn't file those bugs, but started patching those and filed only when succeeded. At this point I remember only two packages that FTBFS with ICU 70.1 and I couldn't fix those. One is mozjs78 and the other is 0ad. I had trouble with PostgreSQL, but that has a new major upstream release uploaded since then, meaning it needs to be re-tested. My box has an issue at the moment and I need to finish converting my 4 Tb big (badly chosen) BTRFS filesystem to ext4 over an USB link. It's not that fast and may still need an hour or two. Going to restart the rebuilds after this and report all issues I find. Regards, Laszlo/GCS
Bug#1007230: transition: google-glog
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi Release Team, ABI changed back with 0.5.0 and further with 0.6.0 (release candidate at this time) by moving an internal function to the public API. Packaged for experimental and built on all release architectures. Reverse dependencies are built correctly, only src:pytorch needs a patch. I've submitted that [1] and asked its maintainer for testing. Waiting for feedback, but the package build is working for sure. Thanks for considering, Laszlo/GCS [1] https://bugs.debian.org/1007200
Bug#1006551: bullseye-pu: package tiff/4.2.0-1+deb11u1
Package: release.debian.org User: release.debian@packages.debian.org Tags: bullseye Severity: normal Hi RMs, A security update of tiff for issues not warrant a DSA but still would be good to have fixed. Work done by Thorsten Alteholz that I've double checked. Debdiff is attached. Thanks for consideration, Laszlo/GCS diff -Nru tiff-4.2.0/debian/changelog tiff-4.2.0/debian/changelog --- tiff-4.2.0/debian/changelog 2020-12-21 15:06:46.0 +0100 +++ tiff-4.2.0/debian/changelog 2022-02-27 17:02:02.0 +0100 @@ -1,3 +1,20 @@ +tiff (4.2.0-1+deb11u1) bullseye; urgency=high + + [ Thorsten Alteholz ] + * CVE-2022-22844 +out-of-bounds read in _TIFFmemcpy in certain situations involving a +custom tag and 0x0200 as the second word of the DE field. + * CVE-2022-0562 +Null source pointer passed as an argument to memcpy() function within +TIFFReadDirectory(). This could result in a Denial of Service via +crafted TIFF files. + * CVE-2022-0561 +Null source pointer passed as an argument to memcpy() function within +TIFFFetchStripThing(). This could result in a Denial of Service via +crafted TIFF files. + + -- Laszlo Boszormenyi (GCS) Sun, 27 Feb 2022 17:02:02 +0100 + tiff (4.2.0-1) unstable; urgency=medium * New upstream release. diff -Nru tiff-4.2.0/debian/patches/CVE-2022-0561.patch tiff-4.2.0/debian/patches/CVE-2022-0561.patch --- tiff-4.2.0/debian/patches/CVE-2022-0561.patch 1970-01-01 01:00:00.0 +0100 +++ tiff-4.2.0/debian/patches/CVE-2022-0561.patch 2022-02-27 16:57:51.0 +0100 @@ -0,0 +1,26 @@ +From eecb0712f4c3a5b449f70c57988260a667ddbdef Mon Sep 17 00:00:00 2001 +From: Even Rouault +Date: Sun, 6 Feb 2022 13:08:38 +0100 +Subject: [PATCH] TIFFFetchStripThing(): avoid calling memcpy() with a null + source pointer and size of zero (fixes #362) + +--- + libtiff/tif_dirread.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +Index: tiff-4.2.0/libtiff/tif_dirread.c +=== +--- tiff-4.2.0.orig/libtiff/tif_dirread.c 2022-02-22 23:56:43.727328819 +0100 tiff-4.2.0/libtiff/tif_dirread.c 2022-02-22 23:56:43.727328819 +0100 +@@ -5765,8 +5765,9 @@ + _TIFFfree(data); + return(0); + } +-_TIFFmemcpy(resizeddata,data,(uint32)dir->tdir_count*sizeof(uint64)); +-_TIFFmemset(resizeddata+(uint32)dir->tdir_count,0,(nstrips-(uint32)dir->tdir_count)*sizeof(uint64)); ++if( dir->tdir_count ) ++_TIFFmemcpy(resizeddata,data, (uint32)dir->tdir_count * sizeof(uint64)); ++_TIFFmemset(resizeddata+(uint32)dir->tdir_count, 0, (nstrips - (uint32)dir->tdir_count) * sizeof(uint64)); + _TIFFfree(data); + data=resizeddata; + } diff -Nru tiff-4.2.0/debian/patches/CVE-2022-0562.patch tiff-4.2.0/debian/patches/CVE-2022-0562.patch --- tiff-4.2.0/debian/patches/CVE-2022-0562.patch 1970-01-01 01:00:00.0 +0100 +++ tiff-4.2.0/debian/patches/CVE-2022-0562.patch 2022-02-27 16:57:51.0 +0100 @@ -0,0 +1,24 @@ +From 561599c99f987dc32ae110370cfdd7df7975586b Mon Sep 17 00:00:00 2001 +From: Even Rouault +Date: Sat, 5 Feb 2022 20:36:41 +0100 +Subject: [PATCH] TIFFReadDirectory(): avoid calling memcpy() with a null + source pointer and size of zero (fixes #362) + +--- + libtiff/tif_dirread.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +Index: tiff-4.2.0/libtiff/tif_dirread.c +=== +--- tiff-4.2.0.orig/libtiff/tif_dirread.c 2022-02-22 23:56:49.919326843 +0100 tiff-4.2.0/libtiff/tif_dirread.c 2022-02-22 23:56:49.915326845 +0100 +@@ -4173,7 +4173,8 @@ + goto bad; + } + +-memcpy(new_sampleinfo, tif->tif_dir.td_sampleinfo, old_extrasamples * sizeof(uint16)); ++if (old_extrasamples > 0) ++memcpy(new_sampleinfo, tif->tif_dir.td_sampleinfo, old_extrasamples * sizeof(uint16)); + _TIFFsetShortArray(>tif_dir.td_sampleinfo, new_sampleinfo, tif->tif_dir.td_extrasamples); + _TIFFfree(new_sampleinfo); + } diff -Nru tiff-4.2.0/debian/patches/CVE-2022-22844.patch tiff-4.2.0/debian/patches/CVE-2022-22844.patch --- tiff-4.2.0/debian/patches/CVE-2022-22844.patch 1970-01-01 01:00:00.0 +0100 +++ tiff-4.2.0/debian/patches/CVE-2022-22844.patch 2022-02-27 16:57:51.0 +0100 @@ -0,0 +1,45 @@ +From 03047a26952a82daaa0792957ce211e0aa51bc64 Mon Sep 17 00:00:00 2001 +From: 4ugustus +Date: Tue, 25 Jan 2022 16:25:28 + +Subject: [PATCH] tiffset: fix global-buffer-overflow for ASCII tags where + count is required (fixes #355) + +--- + tools/tiffset.c | 16 +--- + 1 file changed, 13 insertions(+), 3 deletions(-) + +Index: tiff-4.2.0/tools/tiffset.c +=== +--- tiff-4.2.0.orig/tools/tiffset.c 2022-02-2
Bug#1006550: buster-pu: package tiff/4.1.0+git191117-2~deb10u4
Package: release.debian.org User: release.debian@packages.debian.org Tags: buster Severity: normal Hi RMs, A security update of tiff for issues not warrant a DSA but still would be good to have fixed. Work done by Thorsten Alteholz that I've double checked. Debdiff is attached. Thanks for consideration, Laszlo/GCS diff -Nru tiff-4.1.0+git191117/debian/changelog tiff-4.1.0+git191117/debian/changelog --- tiff-4.1.0+git191117/debian/changelog 2021-10-31 09:31:11.0 +0100 +++ tiff-4.1.0+git191117/debian/changelog 2022-02-27 17:01:41.0 +0100 @@ -1,3 +1,20 @@ +tiff (4.1.0+git191117-2~deb10u4) buster; urgency=high + + [ Thorsten Alteholz ] + * CVE-2022-22844 +out-of-bounds read in _TIFFmemcpy in certain situations involving a +custom tag and 0x0200 as the second word of the DE field. + * CVE-2022-0562 +Null source pointer passed as an argument to memcpy() function within +TIFFReadDirectory(). This could result in a Denial of Service via +crafted TIFF files. + * CVE-2022-0561 +Null source pointer passed as an argument to memcpy() function within +TIFFFetchStripThing(). This could result in a Denial of Service via +crafted TIFF files. + + -- Laszlo Boszormenyi (GCS) Sun, 27 Feb 2022 17:01:41 +0100 + tiff (4.1.0+git191117-2~deb10u3) buster-security; urgency=high * Non-maintainer upload by the Security Team. diff -Nru tiff-4.1.0+git191117/debian/patches/CVE-2022-0561.patch tiff-4.1.0+git191117/debian/patches/CVE-2022-0561.patch --- tiff-4.1.0+git191117/debian/patches/CVE-2022-0561.patch 1970-01-01 01:00:00.0 +0100 +++ tiff-4.1.0+git191117/debian/patches/CVE-2022-0561.patch 2022-02-27 16:58:38.0 +0100 @@ -0,0 +1,26 @@ +From eecb0712f4c3a5b449f70c57988260a667ddbdef Mon Sep 17 00:00:00 2001 +From: Even Rouault +Date: Sun, 6 Feb 2022 13:08:38 +0100 +Subject: [PATCH] TIFFFetchStripThing(): avoid calling memcpy() with a null + source pointer and size of zero (fixes #362) + +--- + libtiff/tif_dirread.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +Index: tiff-4.1.0+git191117/libtiff/tif_dirread.c +=== +--- tiff-4.1.0+git191117.orig/libtiff/tif_dirread.c 2022-02-22 23:44:35.619605527 +0100 tiff-4.1.0+git191117/libtiff/tif_dirread.c 2022-02-22 23:46:28.843560813 +0100 +@@ -5682,8 +5682,9 @@ + _TIFFfree(data); + return(0); + } +-_TIFFmemcpy(resizeddata,data,(uint32)dir->tdir_count*sizeof(uint64)); +-_TIFFmemset(resizeddata+(uint32)dir->tdir_count,0,(nstrips-(uint32)dir->tdir_count)*sizeof(uint64)); ++if( dir->tdir_count ) ++_TIFFmemcpy(resizeddata,data, (uint32)dir->tdir_count * sizeof(uint64)); ++_TIFFmemset(resizeddata+(uint32)dir->tdir_count, 0, (nstrips - (uint32)dir->tdir_count) * sizeof(uint64)); + _TIFFfree(data); + data=resizeddata; + } diff -Nru tiff-4.1.0+git191117/debian/patches/CVE-2022-0562.patch tiff-4.1.0+git191117/debian/patches/CVE-2022-0562.patch --- tiff-4.1.0+git191117/debian/patches/CVE-2022-0562.patch 1970-01-01 01:00:00.0 +0100 +++ tiff-4.1.0+git191117/debian/patches/CVE-2022-0562.patch 2022-02-27 16:58:38.0 +0100 @@ -0,0 +1,24 @@ +From 561599c99f987dc32ae110370cfdd7df7975586b Mon Sep 17 00:00:00 2001 +From: Even Rouault +Date: Sat, 5 Feb 2022 20:36:41 +0100 +Subject: [PATCH] TIFFReadDirectory(): avoid calling memcpy() with a null + source pointer and size of zero (fixes #362) + +--- + libtiff/tif_dirread.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +Index: tiff-4.1.0+git191117/libtiff/tif_dirread.c +=== +--- tiff-4.1.0+git191117.orig/libtiff/tif_dirread.c 2022-02-22 23:46:41.891555692 +0100 tiff-4.1.0+git191117/libtiff/tif_dirread.c 2022-02-22 23:48:35.983511234 +0100 +@@ -4126,7 +4126,8 @@ + goto bad; + } + +-memcpy(new_sampleinfo, tif->tif_dir.td_sampleinfo, old_extrasamples * sizeof(uint16)); ++if (old_extrasamples > 0) ++memcpy(new_sampleinfo, tif->tif_dir.td_sampleinfo, old_extrasamples * sizeof(uint16)); + _TIFFsetShortArray(>tif_dir.td_sampleinfo, new_sampleinfo, tif->tif_dir.td_extrasamples); + _TIFFfree(new_sampleinfo); + } diff -Nru tiff-4.1.0+git191117/debian/patches/CVE-2022-22844.patch tiff-4.1.0+git191117/debian/patches/CVE-2022-22844.patch --- tiff-4.1.0+git191117/debian/patches/CVE-2022-22844.patch 1970-01-01 01:00:00.0 +0100 +++ tiff-4.1.0+git191117/debian/patches/CVE-2022-22844.patch 2022-02-27 16:58:38.0 +0100 @@ -0,0 +1,45 @@ +From 03047a26952a82daaa0792957ce211e0aa51bc64 Mon Sep 17 00:00:00 2001 +From: 4ugustus +Date: Tue, 25 Jan 2022 16:25:28 + +Subject: [PATCH] tiffset: fix global-buffer-overflow for ASCII tags w
Bug#1004389: transition: botan
On Sat, Jan 29, 2022 at 10:11 AM Sebastian Ramacher wrote: > On 2022-01-26 16:21:37 +0100, László Böszörményi wrote: > > Straightforward transition of botan. Affected packages are biboumi, > > rnp and thunderbird. > > All builds fine with the botan 2.19.1+dfsg-1 version from experimental. > > Go ahead Uploaded and already built on all primary architectures. You can schedule binNMUs as your time permits. Thanks, Laszlo/GCS
Bug#1004389: transition: botan
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Straightforward transition of botan. Affected packages are biboumi, rnp and thunderbird. All builds fine with the botan 2.19.1+dfsg-1 version from experimental. Regards, Laszlo/GCS
Bug#1002912: buster-pu: package graphicsmagick/1.4+really1.3.35-1~deb10u2
Package: release.debian.org
User: release.debian@packages.debian.org
Tags: buster
Severity: normal
Hi RMs,
There's a low priority security issue (CVE-2020-12672: heap-based
buffer overflow in ReadMNGImage in coders/png.c) in GraphicsMagick in
Buster.
Thorsten Alteholz backported the fix for this package version, debdiff
is attached. It would be nice if it can be accepted.
Thanks in advance,
Laszlo/GCS
diff -Nru graphicsmagick-1.4+really1.3.35/debian/changelog graphicsmagick-1.4+really1.3.35/debian/changelog
--- graphicsmagick-1.4+really1.3.35/debian/changelog 2020-04-18 18:30:17.0 +0200
+++ graphicsmagick-1.4+really1.3.35/debian/changelog 2021-12-31 16:41:12.0 +0100
@@ -1,3 +1,11 @@
+graphicsmagick (1.4+really1.3.35-1~deb10u2) buster; urgency=high
+
+ [ Thorsten Alteholz ]
+ * CVE-2020-12672
+Fix for a heap-based buffer overflow in ReadMNGImage() in coders/png.c.
+
+ -- Laszlo Boszormenyi (GCS) Fri, 31 Dec 2021 16:41:12 +0100
+
graphicsmagick (1.4+really1.3.35-1~deb10u1) buster-security; urgency=high
* Security backport for Buster.
diff -Nru graphicsmagick-1.4+really1.3.35/debian/patches/CVE-2020-12672.patch graphicsmagick-1.4+really1.3.35/debian/patches/CVE-2020-12672.patch
--- graphicsmagick-1.4+really1.3.35/debian/patches/CVE-2020-12672.patch 1970-01-01 01:00:00.0 +0100
+++ graphicsmagick-1.4+really1.3.35/debian/patches/CVE-2020-12672.patch 2021-12-31 16:41:08.0 +0100
@@ -0,0 +1,49 @@
+Index: graphicsmagick-1.4+really1.3.35/coders/png.c
+===
+--- graphicsmagick-1.4+really1.3.35.orig/coders/png.c 2021-12-30 00:10:05.139412435 +0100
graphicsmagick-1.4+really1.3.35/coders/png.c 2021-12-30 00:10:05.131412440 +0100
+@@ -5689,7 +5689,28 @@
+
+ if (logging)
+ (void) LogMagickEvent(CoderEvent,GetMagickModule(),
+- " Processing MNG MAGN chunk");
++ " Processing MNG MAGN chunk: MB=%u, ML=%u,"
++ " MR=%u, MT=%u, MX=%u, MY=%u,"
++ " X_method=%u, Y_method=%u",
++ mng_info->magn_mb,mng_info->magn_ml,
++ mng_info->magn_mr,mng_info->magn_mt,
++ mng_info->magn_mx,mng_info->magn_my,
++ mng_info->magn_methx,
++ mng_info->magn_methy);
++
++ /*
++If the image width is 1, then X magnification is done
++by simple pixel replication.
++ */
++ if (image->columns == 1)
++ mng_info->magn_methx = 1;
++
++ /*
++If the image height is 1, then Y magnification is done
++by simple pixel replication.
++ */
++ if (image->rows == 1)
++ mng_info->magn_methy = 1;
+
+ if (mng_info->magn_methx == 1)
+ {
+@@ -5734,12 +5755,10 @@
+ Image
+ *large_image;
+
+- int
+-yy;
+-
+ long
+ m,
+-y;
++y,
++yy;
+
+ register long
+ x;
diff -Nru graphicsmagick-1.4+really1.3.35/debian/patches/series graphicsmagick-1.4+really1.3.35/debian/patches/series
--- graphicsmagick-1.4+really1.3.35/debian/patches/series 2019-07-25 18:43:39.0 +0200
+++ graphicsmagick-1.4+really1.3.35/debian/patches/series 2021-12-31 16:41:08.0 +0100
@@ -1,2 +1,4 @@
link-demos.diff
semaphore_O0_ppc64el.patch
+
+CVE-2020-12672.patch
Bug#992613: buster-pu: package icu/63.1-6+deb10u2
On Sat, Dec 4, 2021 at 6:40 PM Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2021-08-21 at 09:10 +0200, László Böszörményi wrote: > > ICU had a non-standard tool for revealing its headers and libs paths, > > compiler switches needed for development. This tool, icu-config, was > > removed after being deprecated over pkg-config for years. > > Please go ahead, thanks. Uploaded. Please note, there was a security upload after I've filed this PU. Thus the changes were made on top of that, resulting 63.1-6+deb10u3 as the new package revision. But no other change was made. Regards, Laszlo/GCS
Bug#996030: transition: libsidplayfp
On Mon, Oct 11, 2021 at 9:45 PM Sebastian Ramacher wrote: > On 2021-10-10 17:25:10 +0200, László Böszörményi wrote: > > Small transition of libsidplayfp, affecting audacious-plugins, mpd and > > qmmp. > > I will upload its counterpart, sidplayfp when the transition is > > allowed to start. > > Please go ahead and while you're at it please also remove the > unnecessary Breaks+Replaces from libsidplayfp6. Correct, removed and uploaded. Thanks, Laszlo/GCS
Bug#996030: transition: libsidplayfp
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Small transition of libsidplayfp, affecting audacious-plugins, mpd and qmmp. I will upload its counterpart, sidplayfp when the transition is allowed to start. Regards, Laszlo/GCS
Bug#992063: bullseye-pu: package fetchmail/6.4.16-4+deb11u1
Control: tags -1 -moreinfo On Tue, Sep 7, 2021 at 9:48 AM Jonathan Wiltshire wrote: > On Sun, Sep 05, 2021 at 09:58:48AM +0200, László Böszörményi (GCS) wrote: > > Just to make sure, you accept the updated patch [1], right? > > Yes please! Uploaded, thanks. Cheers, Laszlo/GCS
Bug#992616: transition: botan
On Wed, Sep 1, 2021 at 10:41 AM Sebastian Ramacher wrote: > On 2021-08-21 10:49:04 +0200, László Böszörményi wrote: > > Again a small transition of botan to 2.18.1 version. Reverse > > dependencies are biboumi, rnp (sid only) and thunderbird. All build > > fine with the new botan version in experimental. Actually there's a > > new upstream version of Thunderbird in experimental, that's built fine > > as well with the new Botan release. > > biboumi is also involved in the ongoing libidn transition. So let's > postpone this transition until libidn is done. That's just done. Am I clear to go with botan? Regards, Laszlo/GCS
Bug#992063: bullseye-pu: package fetchmail/6.4.16-4+deb11u1
Hi Jonathan, On Sat, Sep 4, 2021 at 11:59 AM Jonathan Wiltshire wrote: > Control: tag -1 confirmed moreinfo [...] > Please go ahead, and remove this bug's moreinfo tag when it is uploaded. Just to make sure, you accept the updated patch [1], right? Thanks, Laszlo/GCS [1] https://bugs.debian.org/992063#10
Bug#992616: transition: botan
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Again a small transition of botan to 2.18.1 version. Reverse dependencies are biboumi, rnp (sid only) and thunderbird. All build fine with the new botan version in experimental. Actually there's a new upstream version of Thunderbird in experimental, that's built fine as well with the new Botan release. Thanks in advance, Laszlo/GCS
Bug#992613: buster-pu: package icu/63.1-6+deb10u2
Package: release.debian.org
User: release.debian@packages.debian.org
Tags: buster
Severity: normal
Hi RMs,
ICU had a non-standard tool for revealing its headers and libs paths,
compiler switches needed for development. This tool, icu-config, was
removed after being deprecated over pkg-config for years. Then another
ICU tool, pkgdata remained to use that [1]. It seems some projects
still didn't switch to pkg-config but use the mentioned ICU one.
There's an upstream fix for this, included in newer ICU releases -
meaning it's proven in Bullseye and Sid as well.
The only packaging change following this, pkg-data became a dependency
for icu-devtools due to its usage in pkgdata.
[ Reason ]
ICU tool pkgdata still would like to get headers and library data via
its removed icu-config. Upstream fixed it for newer ICU releases to
use pkg-config instead.
[ Impact ]
Code that compiles with ICU and uses pkgdata to reveal its headers and
libraries will work again.
[ Tests ]
Local tests and problem reporter confirmed the fix. It's also part of
Bullseye and Sid versions of ICU, working correctly.
[ Risks ]
None.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in buster
[x] the issue is verified as fixed in unstable
Thanks for considering,
Laszlo/GCS
[1] https://bugs.debian.org/992591
diff -Nru icu-63.1/debian/changelog icu-63.1/debian/changelog
--- icu-63.1/debian/changelog 2020-03-13 19:49:33.0 +0100
+++ icu-63.1/debian/changelog 2021-08-21 07:28:38.0 +0200
@@ -1,3 +1,13 @@
+icu (63.1-6+deb10u2) buster; urgency=medium
+
+ * Add pkg-config dependency to icu-devtools.
+
+ [ Scott Talbert ]
+ * Backport upstream fix for pkgdata to work without icu-config
+(closes: #992591).
+
+ -- Laszlo Boszormenyi (GCS) Sat, 21 Aug 2021 07:28:38 +0200
+
icu (63.1-6+deb10u1) buster-security; urgency=high
* Backport upstream security fix for CVE-2020-10531: SEGV_MAPERR in
diff -Nru icu-63.1/debian/control icu-63.1/debian/control
--- icu-63.1/debian/control 2019-01-23 17:51:20.0 +0100
+++ icu-63.1/debian/control 2021-08-21 07:28:38.0 +0200
@@ -51,7 +51,7 @@
Architecture: any
Multi-Arch: foreign
Pre-Depends: ${misc:Pre-Depends}
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}, pkg-config
Replaces: libicu-dev (<< ${binary:Version}), icu-tools (<< 63.1-1~)
Breaks: libicu-dev (<< ${binary:Version}), icu-tools (<< 63.1-1~)
Description: Development utilities for International Components for Unicode
diff -Nru icu-63.1/debian/patches/ICU-20924-Use-pkg-config-to-generate-the-path-to-pkg.patch icu-63.1/debian/patches/ICU-20924-Use-pkg-config-to-generate-the-path-to-pkg.patch
--- icu-63.1/debian/patches/ICU-20924-Use-pkg-config-to-generate-the-path-to-pkg.patch 1970-01-01 01:00:00.0 +0100
+++ icu-63.1/debian/patches/ICU-20924-Use-pkg-config-to-generate-the-path-to-pkg.patch 2021-08-20 23:53:11.0 +0200
@@ -0,0 +1,139 @@
+From 5aae52d3ef316b3fd3c43b3f974a8032d279e6fc Mon Sep 17 00:00:00 2001
+From: Hugh McMaster
+Date: Mon, 23 Dec 2019 22:11:05 +1100
+Subject: [PATCH] ICU-20924 Use pkg-config to generate the path to pkgdata.inc
+
+---
+ icu4c/source/tools/pkgdata/pkgdata.cpp | 84 +-
+ 1 file changed, 43 insertions(+), 41 deletions(-)
+
+diff --git a/icu4c/source/tools/pkgdata/pkgdata.cpp b/icu4c/source/tools/pkgdata/pkgdata.cpp
+index 7235a7f669..6406fcc7a5 100644
+--- a/source/tools/pkgdata/pkgdata.cpp
b/source/tools/pkgdata/pkgdata.cpp
+@@ -95,7 +95,7 @@ static int32_t pkg_archiveLibrary(const char *targetDir, const char *version, UB
+ static void createFileNames(UPKGOptions *o, const char mode, const char *version_major, const char *version, const char *libName, const UBool reverseExt, UBool noVersion);
+ static int32_t initializePkgDataFlags(UPKGOptions *o);
+
+-static int32_t pkg_getOptionsFromICUConfig(UBool verbose, UOption *option);
++static int32_t pkg_getPkgDataPath(UBool verbose, UOption *option);
+ static int runCommand(const char* command, UBool specialHandling=FALSE);
+
+ #define IN_COMMON_MODE(mode) (mode == 'a' || mode == 'c')
+@@ -309,7 +309,7 @@ main(int argc, char* argv[]) {
+
+ #if !defined(WINDOWS_WITH_MSVC) || defined(USING_CYGWIN)
+ if(!options[BLDOPT].doesOccur && uprv_strcmp(options[MODE].value, "common") != 0) {
+- if (pkg_getOptionsFromICUConfig(options[VERBOSE].doesOccur, [BLDOPT]) != 0) {
++ if (pkg_getPkgDataPath(options[VERBOSE].doesOccur, [BLDOPT]) != 0) {
+ fprintf(stderr, " required parameter is missing: -O is required for static and shared builds.\n");
+ fprintf(stderr, "Run '%s --help' for help.\n", progname);
+ return 1;
+@@ -2158,41 +2158,46 @@ static void loadLists(UPKGOptions *o, UErrorCode *status)
+ } /* for each
Bug#992063: bullseye-pu: package fetchmail/6.4.16-4+deb11u1
Hi RMs,
On Tue, Aug 10, 2021 at 4:21 PM László Böszörményi wrote:
> Asking for a fetchmail package update, fixing a regression in its last
> security fix. This is a one liner, moving down an 'endif'.
Another issue has emerged, a regression since Buster. With certain
configurations, fetchmail crashes immediately.
[ Reason ]
Some options don't always have value. But code tried to strdup() that
- a non-existent value.
[ Impact ]
With such configurations, users can't use fetchmail anymore. Upstream
fix corrects the behaviour.
[ Tests ]
Local tests mostly. But the fix also went to Sid and it works for all users.
[ Risks ]
None.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in bullseye
[x] the issue is verified as fixed in unstable
Thanks for considering,
Laszlo/GCS
diff -Nru fetchmail-6.4.16/debian/changelog fetchmail-6.4.16/debian/changelog
--- fetchmail-6.4.16/debian/changelog 2021-07-29 00:18:56.0 +0200
+++ fetchmail-6.4.16/debian/changelog 2021-08-09 20:06:48.0 +0200
@@ -1,3 +1,11 @@
+fetchmail (6.4.16-4+deb11u1) bullseye; urgency=medium
+
+ * Backport upstream regression fix for 6.4.20's security (CVE-2021-36386)
+fix.
+ * Fix envelope segmentation fault (closes: #992400).
+
+ -- Laszlo Boszormenyi (GCS) Mon, 09 Aug 2021 20:06:48 +0200
+
fetchmail (6.4.16-4) unstable; urgency=high
* Backport upstream security fix for CVE-2021-36386: denial of service or
diff -Nru fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch
--- fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch 1970-01-01 01:00:00.0 +0100
+++ fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch 2021-08-09 20:06:48.0 +0200
@@ -0,0 +1,76 @@
+From d3db2da1d13bd2419370ad96defb92eecb17064c Mon Sep 17 00:00:00 2001
+From: Matthias Andree
+Date: Mon, 9 Aug 2021 17:42:29 +0200
+Subject: [PATCH] Fix --logfile and message truncation issue.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Regression in 6.4.20's security fix (Git commit c546c829).
+
+We doubly incremented partial_message_size_used on modern systems
+(stdard.h/vsnprintf), once in report_vbuild() and then again in
+report_build(), so the 2nd and subsequent report_build() fragments
+landed too late in the buffer. This will not cause overruns due to the
+reallocation prior to the vsnprintf/sprintf, but it write starts behind
+the '\0' byte, instead of right over it, so the string also gets
+truncated to the first fragment written with report_vbuild().
+
+Fix by moving the increment back into the #else...#endif part that does
+not use report_vbuild().
+
+Reported by: Jürgen Edner, Erik Christiansen
+---
+ NEWS | 18 ++
+ report.c | 3 ++-
+ 2 files changed, 20 insertions(+), 1 deletion(-)
+
+diff --git a/NEWS b/NEWS
+index 0cd3f968..b98f15d2 100644
+--- a/NEWS
b/NEWS
+@@ -64,6 +64,24 @@ removed from a 6.5.0 or newer release.)
+ for end-of-life OpenSSL versions may be removed even from patchlevel releases.
+
+
++fetchmail-6.4.21 (released 2021-08-09, 30042 LoC):
++
++# REGRESSION FIX:
++* The new security fix in 6.4.20 for CVE-2021-36386 caused truncation of
++ messages logged to buffered outputs, predominantly --logfile.
++
++ This also caused lines in the logfile to run into one another because
++ the fragment containing the '\n' line-end character was usually lost.
++
++ Reason is that on all modern systems (with header and vsnprintf()
++ interface), the length of log message fragments was added up twice, so
++ that these ended too deep into a freshly allocated buffer, after the '\0'
++ byte. Unbuffered outputs flushed the fragments right away, which masked the
++ bug.
++
++ Reported by: Jürgen Edner, Erik Christiansen.
++
++
+ fetchmail-6.4.20 (not yet released):
+
+ # SECURITY FIX:
+diff --git a/report.c b/report.c
+index aea6b3ea..2db7d0a9 100644
+--- a/report.c
b/report.c
+@@ -286,10 +286,11 @@ report_build (FILE *errfp, message, va_alist)
+ n = snprintf (partial_message + partial_message_size_used,
+ partial_message_size - partial_message_size_used,
+ message, a1, a2, a3, a4, a5, a6, a7, a8);
+-#endif
+
+ if (n > 0) partial_message_size_used += n;
+
++#endif
++
+ if (unbuffered && partial_message_size_used != 0)
+ {
+ partial_message_size_used = 0;
+--
+GitLab
+
diff -Nru fetchmail-6.4.16/debian/patches/13_fix_envelope_segfault.patch fetchmail-6.4.16/debian/patches/13_fix_envelope_segfault.patch
--- fetchmail-6.4.16/debian/patches/13_fix_envelope_segfault.patch
Bug#992063: bullseye-pu: package fetchmail/6.4.16-4+deb11u1
Package: release.debian.org
User: release.debian@packages.debian.org
Tags: bullseye
Severity: normal
Hi RMs,
Asking for a fetchmail package update, fixing a regression in its last
security fix. This is a one liner, moving down an 'endif'.
The reason is, partial_message_size_used was double incremented and
messages got truncated (the size limit reached much sooner). Updated
package is already in Sid, I would like to get it for Bullseye too.
Debdiff is attached.
Thanks for consideration,
Laszlo/GCS
diff -Nru fetchmail-6.4.16/debian/changelog fetchmail-6.4.16/debian/changelog
--- fetchmail-6.4.16/debian/changelog 2021-07-29 00:18:56.0 +0200
+++ fetchmail-6.4.16/debian/changelog 2021-08-09 20:06:48.0 +0200
@@ -1,3 +1,10 @@
+fetchmail (6.4.16-4+deb11u1) bullseye; urgency=medium
+
+ * Backport upstream regression fix for 6.4.20's security (CVE-2021-36386)
+fix.
+
+ -- Laszlo Boszormenyi (GCS) Mon, 09 Aug 2021 20:06:48 +0200
+
fetchmail (6.4.16-4) unstable; urgency=high
* Backport upstream security fix for CVE-2021-36386: denial of service or
diff -Nru fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch
--- fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch 1970-01-01 01:00:00.0 +0100
+++ fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch 2021-08-09 20:06:48.0 +0200
@@ -0,0 +1,76 @@
+From d3db2da1d13bd2419370ad96defb92eecb17064c Mon Sep 17 00:00:00 2001
+From: Matthias Andree
+Date: Mon, 9 Aug 2021 17:42:29 +0200
+Subject: [PATCH] Fix --logfile and message truncation issue.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Regression in 6.4.20's security fix (Git commit c546c829).
+
+We doubly incremented partial_message_size_used on modern systems
+(stdard.h/vsnprintf), once in report_vbuild() and then again in
+report_build(), so the 2nd and subsequent report_build() fragments
+landed too late in the buffer. This will not cause overruns due to the
+reallocation prior to the vsnprintf/sprintf, but it write starts behind
+the '\0' byte, instead of right over it, so the string also gets
+truncated to the first fragment written with report_vbuild().
+
+Fix by moving the increment back into the #else...#endif part that does
+not use report_vbuild().
+
+Reported by: Jürgen Edner, Erik Christiansen
+---
+ NEWS | 18 ++
+ report.c | 3 ++-
+ 2 files changed, 20 insertions(+), 1 deletion(-)
+
+diff --git a/NEWS b/NEWS
+index 0cd3f968..b98f15d2 100644
+--- a/NEWS
b/NEWS
+@@ -64,6 +64,24 @@ removed from a 6.5.0 or newer release.)
+ for end-of-life OpenSSL versions may be removed even from patchlevel releases.
+
+
++fetchmail-6.4.21 (released 2021-08-09, 30042 LoC):
++
++# REGRESSION FIX:
++* The new security fix in 6.4.20 for CVE-2021-36386 caused truncation of
++ messages logged to buffered outputs, predominantly --logfile.
++
++ This also caused lines in the logfile to run into one another because
++ the fragment containing the '\n' line-end character was usually lost.
++
++ Reason is that on all modern systems (with header and vsnprintf()
++ interface), the length of log message fragments was added up twice, so
++ that these ended too deep into a freshly allocated buffer, after the '\0'
++ byte. Unbuffered outputs flushed the fragments right away, which masked the
++ bug.
++
++ Reported by: Jürgen Edner, Erik Christiansen.
++
++
+ fetchmail-6.4.20 (not yet released):
+
+ # SECURITY FIX:
+diff --git a/report.c b/report.c
+index aea6b3ea..2db7d0a9 100644
+--- a/report.c
b/report.c
+@@ -286,10 +286,11 @@ report_build (FILE *errfp, message, va_alist)
+ n = snprintf (partial_message + partial_message_size_used,
+ partial_message_size - partial_message_size_used,
+ message, a1, a2, a3, a4, a5, a6, a7, a8);
+-#endif
+
+ if (n > 0) partial_message_size_used += n;
+
++#endif
++
+ if (unbuffered && partial_message_size_used != 0)
+ {
+ partial_message_size_used = 0;
+--
+GitLab
+
diff -Nru fetchmail-6.4.16/debian/patches/series fetchmail-6.4.16/debian/patches/series
--- fetchmail-6.4.16/debian/patches/series 2021-07-29 00:18:56.0 +0200
+++ fetchmail-6.4.16/debian/patches/series 2021-08-09 20:06:48.0 +0200
@@ -5,3 +5,4 @@
09_fix_memory_leak_in_timeout_situation.patch
10_update_manpage.patch
11_fix_CVE-2021-38386.patch
+12_fix_logfile_and_message_truncation_issue.patch
Bug#992054: unblock: fetchmail/6.4.16-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi RMs,
I would like to ask for unblocking fetchmail, fixing a regression in
its last security fix. This is a one liner, moving down an 'endif'.
[ Reason ]
partial_message_size_used was double incremented and messages got
truncated (the size limit reached much sooner).
[ Impact ]
Normal logging in all cases.
[ Tests ]
Local tests. Built on all architectures, piuparts are OK. But
autopkgtests are still running for arm64 and are already OK for all
other architectures.
[ Risks ]
None.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock fetchmail/6.4.16-5
Thanks for consideration,
Laszlo/GCS
diff -Nru fetchmail-6.4.16/debian/changelog fetchmail-6.4.16/debian/changelog
--- fetchmail-6.4.16/debian/changelog 2021-07-29 00:18:56.0 +0200
+++ fetchmail-6.4.16/debian/changelog 2021-08-09 20:06:48.0 +0200
@@ -1,3 +1,10 @@
+fetchmail (6.4.16-5) unstable; urgency=medium
+
+ * Backport upstream regression fix for 6.4.20's security (CVE-2021-36386)
+fix.
+
+ -- Laszlo Boszormenyi (GCS) Mon, 09 Aug 2021 20:06:48 +0200
+
fetchmail (6.4.16-4) unstable; urgency=high
* Backport upstream security fix for CVE-2021-36386: denial of service or
diff -Nru fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch
--- fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch 1970-01-01 01:00:00.0 +0100
+++ fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch 2021-08-09 20:06:48.0 +0200
@@ -0,0 +1,76 @@
+From d3db2da1d13bd2419370ad96defb92eecb17064c Mon Sep 17 00:00:00 2001
+From: Matthias Andree
+Date: Mon, 9 Aug 2021 17:42:29 +0200
+Subject: [PATCH] Fix --logfile and message truncation issue.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Regression in 6.4.20's security fix (Git commit c546c829).
+
+We doubly incremented partial_message_size_used on modern systems
+(stdard.h/vsnprintf), once in report_vbuild() and then again in
+report_build(), so the 2nd and subsequent report_build() fragments
+landed too late in the buffer. This will not cause overruns due to the
+reallocation prior to the vsnprintf/sprintf, but it write starts behind
+the '\0' byte, instead of right over it, so the string also gets
+truncated to the first fragment written with report_vbuild().
+
+Fix by moving the increment back into the #else...#endif part that does
+not use report_vbuild().
+
+Reported by: Jürgen Edner, Erik Christiansen
+---
+ NEWS | 18 ++
+ report.c | 3 ++-
+ 2 files changed, 20 insertions(+), 1 deletion(-)
+
+diff --git a/NEWS b/NEWS
+index 0cd3f968..b98f15d2 100644
+--- a/NEWS
b/NEWS
+@@ -64,6 +64,24 @@ removed from a 6.5.0 or newer release.)
+ for end-of-life OpenSSL versions may be removed even from patchlevel releases.
+
+
++fetchmail-6.4.21 (released 2021-08-09, 30042 LoC):
++
++# REGRESSION FIX:
++* The new security fix in 6.4.20 for CVE-2021-36386 caused truncation of
++ messages logged to buffered outputs, predominantly --logfile.
++
++ This also caused lines in the logfile to run into one another because
++ the fragment containing the '\n' line-end character was usually lost.
++
++ Reason is that on all modern systems (with header and vsnprintf()
++ interface), the length of log message fragments was added up twice, so
++ that these ended too deep into a freshly allocated buffer, after the '\0'
++ byte. Unbuffered outputs flushed the fragments right away, which masked the
++ bug.
++
++ Reported by: Jürgen Edner, Erik Christiansen.
++
++
+ fetchmail-6.4.20 (not yet released):
+
+ # SECURITY FIX:
+diff --git a/report.c b/report.c
+index aea6b3ea..2db7d0a9 100644
+--- a/report.c
b/report.c
+@@ -286,10 +286,11 @@ report_build (FILE *errfp, message, va_alist)
+ n = snprintf (partial_message + partial_message_size_used,
+ partial_message_size - partial_message_size_used,
+ message, a1, a2, a3, a4, a5, a6, a7, a8);
+-#endif
+
+ if (n > 0) partial_message_size_used += n;
+
++#endif
++
+ if (unbuffered && partial_message_size_used != 0)
+ {
+ partial_message_size_used = 0;
+--
+GitLab
+
diff -Nru fetchmail-6.4.16/debian/patches/series fetchmail-6.4.16/debian/patches/series
--- fetchmail-6.4.16/debian/patches/series 2021-07-29 00:18:56.0 +0200
+++ fetchmail-6.4.16/debian/patches/series 2021-08-09 20:06:48.0 +0200
@@ -5,3 +5,4 @@
09_fix_memory_leak_in_timeout_situation.patch
10_update_ma
Bug#991731: unblock: fetchmail/6.4.16-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi RMs,
I would like to ask for unblocking fetchmail, fixing a security issue.
[ Reason ]
When logging long messages, fetchmail might segfault or leak
information to logs.
[ Impact ]
Normal logging in all cases.
[ Tests ]
Local tests.
[ Risks ]
None.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock fetchmail/6.4.16-4
Thanks for considering,
Laszlo/GCS
diff -Nru fetchmail-6.4.16/debian/changelog fetchmail-6.4.16/debian/changelog
--- fetchmail-6.4.16/debian/changelog 2021-06-26 23:53:00.0 +0200
+++ fetchmail-6.4.16/debian/changelog 2021-07-29 00:18:56.0 +0200
@@ -1,3 +1,10 @@
+fetchmail (6.4.16-4) unstable; urgency=high
+
+ * Backport upstream security fix for CVE-2021-36386: denial of service or
+information disclosure when logging long messages.
+
+ -- Laszlo Boszormenyi (GCS) Thu, 29 Jul 2021 00:18:56 +0200
+
fetchmail (6.4.16-3) unstable; urgency=medium
* Fix operation autopkgtest.
diff -Nru fetchmail-6.4.16/debian/patches/11_fix_CVE-2021-38386.patch fetchmail-6.4.16/debian/patches/11_fix_CVE-2021-38386.patch
--- fetchmail-6.4.16/debian/patches/11_fix_CVE-2021-38386.patch 1970-01-01 01:00:00.0 +0100
+++ fetchmail-6.4.16/debian/patches/11_fix_CVE-2021-38386.patch 2021-07-29 00:18:56.0 +0200
@@ -0,0 +1,258 @@
+From c546c8299243a10a7b85c638e0e61396ecd5d8b5 Mon Sep 17 00:00:00 2001
+From: Matthias Andree
+Date: Wed, 7 Jul 2021 16:22:57 +0200
+Subject: [PATCH] Fix SIGSEGV when resizing report*() buffer.
+
+Reported (with a different patch suggestion) by
+Christian Herdtweck .
+
+Note that vsnprintf() calls va_arg(), and depending on operating system,
+compiler, configuration, this will invalidate the va_list argument
+pointer, so that va_start has to be called again before a subsequent
+vsnprintf(). However, it is better to do away with the loop and the
+trial-and-error, and leverage the return value of vsnprintf instead for
+a direct one-off resizing, whilst taking into account that on SUSv2
+systems, the return value can be useless if the size argument to
+vsnprintf is 0.
+---
+ NEWS | 18
+ report.c | 138 +++
+ 2 files changed, 95 insertions(+), 61 deletions(-)
+
+diff --git a/NEWS b/NEWS
+index 04239b16..67dc1f9e 100644
+--- a/NEWS
b/NEWS
+@@ -64,6 +64,24 @@ removed from a 6.5.0 or newer release.)
+ for end-of-life OpenSSL versions may be removed even from patchlevel releases.
+
+
++fetchmail-6.4.20 (not yet released):
++
++# SECURITY FIX:
++* When a log message exceeds c. 2 kByte in size, for instance, with very long
++ header contents, and depending on verbosity option, fetchmail can crash or
++ misreport each first log message that requires a buffer reallocation.
++ fetchmail then reallocates memory and re-runs vsnprintf() without another
++ call to va_start(), so it reads garbage. The exact impact depends on
++ many factors around the compiler and operating system configurations used and
++ the implementation details of the stdarg.h interfaces of the two functions
++ mentioned before. To fix CVE-2021-38386.
++
++ Reported by Christian Herdtweck of Intra2net AG, Tübingen, Germany.
++
++ He also offered a patch, which I could not take for fetchmail 6.4 because
++ it required a C99 system and I'd promised earlier that 6.4 would remain
++ compatible with C89 systems.
++
+ fetchmail-6.4.16 (released 2021-02-08, 27707 LoC):
+
+ # BUG FIXES
+diff --git a/report.c b/report.c
+index 1466802a..aea6b3ea 100644
+--- a/report.c
b/report.c
+@@ -44,6 +44,8 @@ static unsigned int partial_message_size = 0;
+ static unsigned int partial_message_size_used = 0;
+ static char *partial_message;
+ static int partial_suppress_tag = 0;
++/* default size for the allocation of the report buffer */
++const size_t defaultsize = 4096;
+
+ static unsigned unbuffered;
+ static unsigned int use_syslog;
+@@ -177,6 +179,27 @@ void report_init(int mode /** 0: regular output, 1: unbuffered output, -1: syslo
+ }
+ }
+
++static void rep_ensuresize(size_t increment) {
++if (partial_message_size == 0)
++{
++ /* initialization */
++ partial_message_size_used = 0;
++ /* avoid too many small allocations initially */
++ if (increment < defaultsize) increment = defaultsize;
++ partial_message_size = increment;
++ partial_message = (char *)MALLOC (partial_message_size);
++}
++else /* already have buffer -> resize if too little room */
++{
++ if (increment < defaultsize) increment = defaultsize;
++ if (partial_message_size - partial_message_size_used &l
Bug#991457: unblock: graphicsmagick/1.4+really1.3.36+hg16481-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi RMs, I would like to ask for unblocking GraphicsMagick, with a simple but important fix of freeing used memory[1]. [ Reason ] Fixes a simple regression - writing labelled PDF files. [ Impact ] No more assertion on normal and common usage. [ Tests ] Good upstream test suite. [ Risks ] None. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock graphicsmagick/1.4+really1.3.36+hg16481-2 Thanks for considering, Laszlo/GCS [1] http://hg.graphicsmagick.org/hg/GraphicsMagick/rev/22aaff86b4aa diff -Nru graphicsmagick-1.4+really1.3.36+hg16481/debian/changelog graphicsmagick-1.4+really1.3.36+hg16481/debian/changelog --- graphicsmagick-1.4+really1.3.36+hg16481/debian/changelog 2021-02-28 23:26:56.0 +0100 +++ graphicsmagick-1.4+really1.3.36+hg16481/debian/changelog 2021-07-24 11:42:42.0 +0200 @@ -1,3 +1,10 @@ +graphicsmagick (1.4+really1.3.36+hg16481-2) unstable; urgency=medium + + * Backport fix for use appropriate memory deallocator for memory returned +by StringToList() (closes: #991380). + + -- Laszlo Boszormenyi (GCS) Sat, 24 Jul 2021 11:42:42 +0200 + graphicsmagick (1.4+really1.3.36+hg16481-1) unstable; urgency=high * Mercurial snapshot, fixing the following security issues: diff -Nru graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/series graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/series --- graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/series 2020-06-03 17:49:58.0 +0200 +++ graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/series 2021-07-24 11:42:42.0 +0200 @@ -1,2 +1,3 @@ link-demos.diff semaphore_O0_ppc64el.patch +use_appropriate_memory_deallocator.patch diff -Nru graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/use_appropriate_memory_deallocator.patch graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/use_appropriate_memory_deallocator.patch --- graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/use_appropriate_memory_deallocator.patch 1970-01-01 01:00:00.0 +0100 +++ graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/use_appropriate_memory_deallocator.patch 2021-07-24 11:42:42.0 +0200 @@ -0,0 +1,52 @@ + +# HG changeset patch +# User Bob Friesenhahn +# Date 1626915582 18000 +# Node ID 22aaff86b4aa34c10b3fbfb104adaaeef8653a36 +# Parent acf305f9ef3e85e6273d62e72d81cce03440eb3d +WritePDFImage(): Use appropriate memory deallocator for memory returned by StringToList(). + +diff -r acf305f9ef3e -r 22aaff86b4aa ChangeLog +--- a/ChangeLog Wed Jul 21 19:47:33 2021 -0500 b/ChangeLog Wed Jul 21 19:59:42 2021 -0500 +@@ -1,3 +1,9 @@ ++2021-07-21 Bob Friesenhahn ++ ++* coders/pdf.c (WritePDFImage): Use appropriate memory deallocator ++for memory returned by StringToList(). Fixes SourceForge issue ++646 "Assertion failed using -label with PDF". ++ + 2021-02-28 Bob Friesenhahn + + * configure.ac: Add tests for Jasper jp2_decode(), jpc_decode(), +diff -r acf305f9ef3e -r 22aaff86b4aa coders/pdf.c +--- a/coders/pdf.c Wed Jul 21 19:47:33 2021 -0500 b/coders/pdf.c Wed Jul 21 19:59:42 2021 -0500 +@@ -1046,9 +1046,9 @@ + FormatString(buffer,"(%.1024s) Tj\n",labels[i]); + (void) WriteBlobString(image,buffer); + (void) WriteBlobString(image,"ET\n"); +- MagickFreeResourceLimitedMemory(labels[i]); ++ MagickFreeMemory(labels[i]); + } +- MagickFreeResourceLimitedMemory(labels); ++ MagickFreeMemory(labels); + } + FormatString(buffer,"%g 0 0 %g %ld %ld cm\n",x_scale,y_scale,geometry.x, +geometry.y); +diff -r acf305f9ef3e -r 22aaff86b4aa www/Changelog.html +--- a/www/Changelog.html Wed Jul 21 19:47:33 2021 -0500 b/www/Changelog.html Wed Jul 21 19:59:42 2021 -0500 +@@ -35,6 +35,12 @@ + + + ++2021-07-21 Bob Friesenhahn bfriesensimpledallastxus ++ ++* coders/pdf.c (WritePDFImage): Use appropriate memory deallocator ++for memory returned by StringToList(). Fixes SourceForge issue ++646 Assertion failed using -label with PDF. ++ + 2021-02-28 Bob Friesenhahn bfriesensimpledallastxus + + * configure.ac: Add tests for Jasper jp2_decode(), jpc_decode(),
Bug#990630: unblock: fuse3/3.10.3-2
On Sat, Jul 3, 2021 at 7:21 AM László Böszörményi wrote:
> [ Checklist ]
> [x] all changes are documented in the d/changelog
> [x] I reviewed all changes and I approve them
> [x] attach debdiff against the package in testing
Then I really attach the debdiff.
Regards,
Laszlo/GCS
diff -Nru fuse3-3.10.3/debian/changelog fuse3-3.10.3/debian/changelog
--- fuse3-3.10.3/debian/changelog 2021-04-21 14:34:39.0 +0200
+++ fuse3-3.10.3/debian/changelog 2021-06-20 15:45:33.0 +0200
@@ -1,3 +1,9 @@
+fuse3 (3.10.3-2) unstable; urgency=medium
+
+ * Do not try to alter cuse device permissions (closes: #947229, #989977).
+
+ -- Laszlo Boszormenyi (GCS) Sun, 20 Jun 2021 15:45:33 +0200
+
fuse3 (3.10.3-1) unstable; urgency=medium
* New upstream release:
diff -Nru fuse3-3.10.3/debian/fuse3.postinst fuse3-3.10.3/debian/fuse3.postinst
--- fuse3-3.10.3/debian/fuse3.postinst 2021-01-29 16:59:06.0 +0100
+++ fuse3-3.10.3/debian/fuse3.postinst 2021-06-20 15:45:33.0 +0200
@@ -14,10 +14,6 @@
case "${1}" in
configure)
- if [ -c /dev/cuse ] && ! chrooted
- then
- chmod 0600 /dev/cuse > /dev/null 2>&1
- fi
if ! dpkg-statoverride --list /bin/fusermount3 > /dev/null 2>&1
then
chmod 4755 /bin/fusermount3
Bug#990630: unblock: fuse3/3.10.3-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi RMs, I would like to update the fuse3 package for Bullseye. [ Reason ] The fuse3 package has an old postinst snippet to alter cuse device permissions. That's double wrong, doesn't work with RO /dev and can fail in chroot environments. [ Impact ] Failed package install [1] in some cases. [ Tests ] Tested chroot installation and now it works. [ Risks ] None. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] Builds an udeb and needs a d-i hint as well. unblock fuse3/3.10.3-2 Thanks, Laszlo/GCS [1] https://bugs.debian.org/989977
Bug#990629: unblock: icu/67.1-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi RMs,
I would like to update the ICU (International Components for Unicode)
package to fix CVE-2021-30535 [1] for Bullseye.
[ Reason ]
Fix a security issue which makes it possible for a remote attacker to
potentially exploit heap corruption in applications using the ICU
library.
[ Impact ]
Application crash due to double free.
[ Tests ]
Upstream tests.
[ Risks ]
None.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
None.
unblock icu/67.1-7
Thanks,
Laszlo/GCS
[1] https://github.com/unicode-org/icu/pull/1698
diff -Nru icu-67.1/debian/changelog icu-67.1/debian/changelog
--- icu-67.1/debian/changelog 2021-01-13 06:45:13.0 +0100
+++ icu-67.1/debian/changelog 2021-06-30 18:07:32.0 +0200
@@ -1,3 +1,10 @@
+icu (67.1-7) unstable; urgency=high
+
+ * Backport upstream security fix for CVE-2021-30535: crash caused by locale
+assign/move operators.
+
+ -- Laszlo Boszormenyi (GCS) Wed, 30 Jun 2021 18:07:32 +0200
+
icu (67.1-6) unstable; urgency=medium
* Add pkg-config build dependency to build-test of autopkg tests.
diff -Nru icu-67.1/debian/patches/locid_operators.patch icu-67.1/debian/patches/locid_operators.patch
--- icu-67.1/debian/patches/locid_operators.patch 1970-01-01 01:00:00.0 +0100
+++ icu-67.1/debian/patches/locid_operators.patch 2021-04-21 15:42:38.0 +0200
@@ -0,0 +1,41 @@
+diff --git a/patches/locid_operators.patch b/patches/locid_operators.patch
+new file mode 100644
+index 000..7428558
+--- /dev/null
b/patches/locid_operators.patch
+@@ -0,0 +1,35 @@
++diff --git a/source/common/locid.cpp b/source/common/locid.cpp
++index 0d506293..4743db53 100644
++--- a/source/common/locid.cpp
+ b/source/common/locid.cpp
++@@ -469,14 +469,18 @@ Locale& Locale::operator=(Locale&& other) U_NOEXCEPT {
++ if ((baseName != fullName) && (baseName != fullNameBuffer)) uprv_free(baseName);
++ if (fullName != fullNameBuffer) uprv_free(fullName);
++
++-if (other.fullName == other.fullNameBuffer) {
+++if (other.fullName == other.fullNameBuffer || other.baseName == other.fullNameBuffer) {
++ uprv_strcpy(fullNameBuffer, other.fullNameBuffer);
+++}
+++if (other.fullName == other.fullNameBuffer) {
++ fullName = fullNameBuffer;
++ } else {
++ fullName = other.fullName;
++ }
++
++-if (other.baseName == other.fullName) {
+++if (other.baseName == other.fullNameBuffer) {
+++baseName = fullNameBuffer;
+++} else if (other.baseName == other.fullName) {
++ baseName = fullName;
++ } else {
++ baseName = other.baseName;
++@@ -2696,6 +2700,9 @@ Locale::setKeywordValue(const char* keywordName, const char* keywordValue, UErro
++ if (fullName != fullNameBuffer) {
++ // if full Name is already on the heap, need to free it.
++ uprv_free(fullName);
+++if (baseName == fullName) {
+++baseName = newFullName; // baseName should not point to freed memory.
+++}
++ }
++ fullName = newFullName;
++ status = U_ZERO_ERROR;
diff -Nru icu-67.1/debian/patches/series icu-67.1/debian/patches/series
--- icu-67.1/debian/patches/series 2020-08-18 17:39:36.0 +0200
+++ icu-67.1/debian/patches/series 2021-06-30 18:07:32.0 +0200
@@ -5,3 +5,4 @@
layout-test-fix.patch
#flaky-tests.patch
ICU-13786_Fix_addLikelySubtags_minimizeSubtags.patch
+locid_operators.patch
Bug#988350: Fwd: unblock: graphviz/2.42.2-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi Release Managers,
I would like to update graphviz due to a security fix, preventing a
heap overflow[1].
[ Reason ]
It's a security fix handling bad data correctly.
[ Impact ]
None on valid data, only fixing buffer length checking.
[ Tests ]
Just the Debian ones, passed.
[ Risks ]
None.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock graphviz/2.42.2-5
Thanks,
Laszlo/GCS
[1] https://gitlab.com/graphviz/graphviz/-/issues/1700
diff -Nru graphviz-2.42.2/debian/changelog graphviz-2.42.2/debian/changelog
--- graphviz-2.42.2/debian/changelog 2020-04-26 07:25:24.0 +0200
+++ graphviz-2.42.2/debian/changelog 2021-05-08 11:09:59.0 +0200
@@ -1,3 +1,10 @@
+graphviz (2.42.2-5) unstable; urgency=high
+
+ * Fix CVE-2020-18032: out of bounds write on invalid label
+(closes: #988000).
+
+ -- Laszlo Boszormenyi (GCS) Sat, 08 May 2021 11:09:59 +0200
+
graphviz (2.42.2-4) unstable; urgency=medium
* Build with Guile 3.0 (closes: #885198).
diff -Nru graphviz-2.42.2/debian/patches/fix_out-of-bounds_write_on_invalid_label.patch graphviz-2.42.2/debian/patches/fix_out-of-bounds_write_on_invalid_label.patch
--- graphviz-2.42.2/debian/patches/fix_out-of-bounds_write_on_invalid_label.patch 1970-01-01 01:00:00.0 +0100
+++ graphviz-2.42.2/debian/patches/fix_out-of-bounds_write_on_invalid_label.patch 2021-05-08 11:09:33.0 +0200
@@ -0,0 +1,35 @@
+commit 784411ca3655c80da0f6025ab20634b2a6ff696b
+Author: Matthew Fernandez
+Date: Sat Jul 25 19:31:01 2020 -0700
+
+fix: out-of-bounds write on invalid label
+
+When the label for a node cannot be parsed (due to it being malformed), it falls
+back on the symbol name of the node itself. I.e. the default label the node
+would have had if it had no label attribute at all. However, this is applied by
+dynamically altering the node's label to "\N", a shortcut for the symbol name of
+the node. All of this is fine, however if the hand written label itself is
+shorter than the literal string "\N", not enough memory would have been
+allocated to write "\N" into the label text.
+
+Here we account for the possibility of error during label parsing, and assume
+that the label text may need to be overwritten with "\N" after the fact. Fixes
+issue #1700.
+
+diff --git a/lib/common/shapes.c b/lib/common/shapes.c
+index 0a0635fc3..9dca9ba6e 100644
+--- a/lib/common/shapes.c
b/lib/common/shapes.c
+@@ -3546,9 +3546,10 @@ static void record_init(node_t * n)
+ reclblp = ND_label(n)->text;
+ len = strlen(reclblp);
+ /* For some forgotten reason, an empty label is parsed into a space, so
+- * we need at least two bytes in textbuf.
++ * we need at least two bytes in textbuf, as well as accounting for the
++ * error path involving "\\N" below.
+ */
+-len = MAX(len, 1);
++len = MAX(MAX(len, 1), (int)strlen("\\N"));
+ textbuf = N_NEW(len + 1, char);
+ if (!(info = parse_reclbl(n, flip, TRUE, textbuf))) {
+ agerr(AGERR, "bad label format %s\n", ND_label(n)->text);
diff -Nru graphviz-2.42.2/debian/patches/series graphviz-2.42.2/debian/patches/series
--- graphviz-2.42.2/debian/patches/series 2019-10-06 00:04:01.0 +0200
+++ graphviz-2.42.2/debian/patches/series 2021-05-08 11:09:50.0 +0200
@@ -8,3 +8,4 @@
gvmap.sh_bashism.patch
build_with_libann.patch
update_documentation_link.patch
+fix_out-of-bounds_write_on_invalid_label.patch
Bug#987561: [pre-approval] unblock: fuse3/3.10.3-1
Control: tags -1 -moreinfo On Thu, Apr 29, 2021 at 9:40 PM Paul Gevers wrote: > On 25-04-2021 18:34, László Böszörményi (GCS) wrote: > > While it's a new upstream release, it only contains a bugfix [1] and > > correcting spelling mistakes. > > The actual change is in lib/fuse.c and very small [2]. Other changes > > are for the example and tests to keep those in sync. > > Please go ahead and remove the moreinfo tag once the package is in the > archive. Package is uploaded, built on all architectures. Piuparts and autopkg tests are OK. Regards, Laszlo/GCS
Bug#987561: [pre-approval] unblock: fuse3/3.10.3-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
[ Reason ]
While it's a new upstream release, it only contains a bugfix [1] and
correcting spelling mistakes.
The actual change is in lib/fuse.c and very small [2]. Other changes
are for the example and tests to keep those in sync.
[ Impact ]
Would provide a fixed and consistent working of fuse3.
[ Tests ]
Rebuilt all reverse dependencies and those are fine.
[ Risks ]
Contains an udeb and currently I don't know how to test it.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
Thanks for considering,
Laszlo/GCS
[1]
https://github.com/libfuse/libfuse/commit/bdd2d4110fbc6d2059eb699efad2cca4a7eacccb
[2]
https://github.com/libfuse/libfuse/commit/bdd2d4110fbc6d2059eb699efad2cca4a7eacccb#diff-0a915c0d19eddb55a580a696b995dab0574ae0f7f04f9136c60d2f3c8a90ac39
diff -Nru --exclude html fuse3-3.10.2/AUTHORS fuse3-3.10.3/AUTHORS
--- fuse3-3.10.2/AUTHORS 2021-02-05 10:07:28.0 +0100
+++ fuse3-3.10.3/AUTHORS 2021-04-12 12:18:08.0 +0200
@@ -82,6 +82,7 @@
HazelFZ
Heiko Becker
Hendrik Brueckner
+Hookey
human
Ikey Doherty
itsdeepak
@@ -163,6 +164,7 @@
Tej Chajed
tenzap <46226844+ten...@users.noreply.github.com>
therealnewo...@gmail.com
+Tobias Nießen
Tomasz Kulasek <34129113+tkula...@users.noreply.github.com>
Tom Callaway
Tom Callaway
diff -Nru --exclude html fuse3-3.10.2/ChangeLog.rst fuse3-3.10.3/ChangeLog.rst
--- fuse3-3.10.2/ChangeLog.rst 2021-02-05 10:07:28.0 +0100
+++ fuse3-3.10.3/ChangeLog.rst 2021-04-12 12:18:08.0 +0200
@@ -1,3 +1,8 @@
+libfuse 3.10.3 (2021-04-12)
+===
+
+* Fix returning d_ino and d_type from readdir(3) in non-plus mode
+
libfuse 3.10.2 (2021-02-05)
===
diff -Nru --exclude html fuse3-3.10.2/debian/changelog fuse3-3.10.3/debian/changelog
--- fuse3-3.10.2/debian/changelog 2021-02-24 23:28:30.0 +0100
+++ fuse3-3.10.3/debian/changelog 2021-04-21 14:34:39.0 +0200
@@ -1,3 +1,12 @@
+fuse3 (3.10.3-1) unstable; urgency=medium
+
+ * New upstream release:
+- fix returning d_ino and d_type by readdir(3) in non-plus mode,
+- remove unused fuse_worker bufsize,
+- fix typos.
+
+ -- Laszlo Boszormenyi (GCS) Wed, 21 Apr 2021 14:34:39 +0200
+
fuse3 (3.10.2-2) unstable; urgency=medium
* Mark libfuse3-dev as Multi-Arch same.
diff -Nru --exclude html fuse3-3.10.2/example/passthrough.c fuse3-3.10.3/example/passthrough.c
--- fuse3-3.10.2/example/passthrough.c 2021-02-05 10:07:28.0 +0100
+++ fuse3-3.10.3/example/passthrough.c 2021-04-12 12:18:08.0 +0200
@@ -55,6 +55,8 @@
#include "passthrough_helpers.h"
+static int fill_dir_plus = 0;
+
static void *xmp_init(struct fuse_conn_info *conn,
struct fuse_config *cfg)
{
@@ -132,7 +134,7 @@
memset(, 0, sizeof(st));
st.st_ino = de->d_ino;
st.st_mode = de->d_type << 12;
- if (filler(buf, de->d_name, , 0, FUSE_FILL_DIR_PLUS))
+ if (filler(buf, de->d_name, , 0, fill_dir_plus))
break;
}
@@ -551,6 +553,18 @@
int main(int argc, char *argv[])
{
+ enum { MAX_ARGS = 10 };
+ int i,new_argc;
+ char *new_argv[MAX_ARGS];
+
umask(0);
- return fuse_main(argc, argv, _oper, NULL);
+ /* Process the "--plus" option apart */
+ for (i=0, new_argc=0; (ist_mode;
+ if (f->conf.use_ino)
+e.attr.st_ino = statp->st_ino;
+ }
if (!f->conf.use_ino && f->conf.readdir_ino) {
e.attr.st_ino = (ino_t)
lookup_nodeid(f, dh->nodeid, name);
diff -Nru --exclude html fuse3-3.10.2/lib/fuse_loop_mt.c fuse3-3.10.3/lib/fuse_loop_mt.c
--- fuse3-3.10.2/lib/fuse_loop_mt.c 2021-02-05 10:07:28.0 +0100
+++ fuse3-3.10.3/lib/fuse_loop_mt.c 2021-04-12 12:18:08.0 +0200
@@ -32,7 +32,6 @@
struct fuse_worker *prev;
struct fuse_worker *next;
pthread_t thread_id;
- size_t bufsize;
// We need to include fuse_buf so that we can properly free
// it when a thread is terminated by pthread_cancel().
diff -Nru --exclude html fuse3-3.10.2/meson.build fuse3-3.10.3/meson.build
--- fuse3-3.10.2/meson.build 2021-02-05 10:07:28.0 +0100
+++ fuse3-3.10.3/meson.build 2021-04-12 12:18:08.0 +0200
@@ -1,4 +1,4 @@
-project('libfuse3', ['c'], version: '3.10.2',
+project('libfuse3', ['c'], version: '3.10.3',
meson_version: '>= 0.42',
default_options: [ 'buildtype=debugoptimized' ])
diff -Nru --exclude html fuse3-3.10.2/test/readdir_inode.c fuse3-3.10.3/test/readdir_inode.c
--- fuse3-3.10.2/test/readdir_inode.c 2021-02-05 10:07:28.0 +0100
+++ fuse3-3.10.3/test/readdir_inode.c 2021-04-12 12:18:08.0 +0200
@@ -1,7 +1,8 @@
/*
- * Prints each directory entry and its inode as returned by 'readdir'.
+ * Prints each directory entry, its inode and d_type as returned by
Bug#986870: unblock: lrzip/0.641-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi RMs,
While the current lrzip version in Bullseye (0.640-1) works, with some
100 MB+ sized files it has a big regression. For example a user
reported [1] the compression ratio dropped from 92% to 60%.
[ Reason ]
Fixes a big regression.
[ Impact ]
Poor compression ratio with large files.
[ Tests ]
Mostly upstream tests.
[ Risks ]
Low.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
While not being an RC bug in Debian, upstream (Con Kolivas) call it
'critical bugfix' and ask for an update in Bullseye [2]. Original
fixing commit [3].
unblock lrzip/0.641-1
Thanks for consideration,
Laszlo/GCS
[1] https://bugs.debian.org/986396#5
[2] https://bugs.debian.org/986396#10
[3]
https://github.com/ckolivas/lrzip/commit/042eb57e034c05250a4ca8007f5cebee4068ec32
diff -Nru lrzip-0.640/configure.ac lrzip-0.641/configure.ac
--- lrzip-0.640/configure.ac 2021-02-16 05:53:30.0 +0100
+++ lrzip-0.641/configure.ac 2021-03-06 00:20:42.0 +0100
@@ -2,7 +2,7 @@
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
m4_define([v_maj], [0])
m4_define([v_min], [6])
-m4_define([v_mic], [40])
+m4_define([v_mic], [41])
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
m4_define([v_v], m4_join([], v_min, v_mic))
m4_define([v_ver], [v_maj.v_v])
diff -Nru lrzip-0.640/debian/changelog lrzip-0.641/debian/changelog
--- lrzip-0.640/debian/changelog 2021-02-19 17:38:21.0 +0100
+++ lrzip-0.641/debian/changelog 2021-04-09 17:50:44.0 +0200
@@ -1,3 +1,10 @@
+lrzip (0.641-1) unstable; urgency=medium
+
+ * New upstream release:
+- fix low compression ratio with large files (closes: #986396).
+
+ -- Laszlo Boszormenyi (GCS) Fri, 09 Apr 2021 17:50:44 +0200
+
lrzip (0.640-1) unstable; urgency=medium
* New upstream release:
diff -Nru lrzip-0.640/stream.c lrzip-0.641/stream.c
--- lrzip-0.640/stream.c 2021-02-16 05:53:30.0 +0100
+++ lrzip-0.641/stream.c 2021-03-06 00:20:42.0 +0100
@@ -1882,11 +1882,8 @@
so do not compress any block that is incompressible by lz4. */
static int lz4_compresses(rzip_control *control, uchar *s_buf, i64 s_len)
{
- int in_len, test_len = s_len, save_len = s_len;
- int dlen;
+ int dlen, test_len;
char *c_buf = NULL, *test_buf = (char *)s_buf;
- /* set minimum buffer test size based on the length of the test stream */
- int buftest_size = (test_len > 5 * STREAM_BUFSIZE ? STREAM_BUFSIZE : STREAM_BUFSIZE / 4096);
int ret = 0;
int workcounter = 0; /* count # of passes */
int best_dlen = INT_MAX; /* save best compression estimate */
@@ -1894,40 +1891,37 @@
if (!LZ4_TEST)
return 1;
- in_len = MIN(test_len, buftest_size);
- dlen = STREAM_BUFSIZE + STREAM_BUFSIZE / 16 + 64 + 3;
-
+ dlen = MIN(s_len, STREAM_BUFSIZE);
+ test_len = MIN(dlen, STREAM_BUFSIZE >> 8);
c_buf = malloc(dlen);
if (unlikely(!c_buf))
fatal_return(("Unable to allocate c_buf in lz4_compresses\n"), 0);
/* Test progressively larger blocks at a time and as soon as anything
compressible is found, jump out as a success */
- while (test_len > 0) {
+ do {
int lz4_ret;
workcounter++;
lz4_ret = LZ4_compress_default((const char *)test_buf, c_buf, test_len, dlen);
- if (!lz4_ret) // Bigger than dlen, no point going further
- break;
+ if (!lz4_ret) // Bigger than dlen
+ lz4_ret = test_len;
if (lz4_ret < best_dlen)
best_dlen = lz4_ret;
if (lz4_ret < test_len) {
ret = 1;
break;
}
- /* expand and move buffer */
- test_len -= in_len;
- if (test_len) {
- test_buf += (ptrdiff_t)in_len;
- if (buftest_size < STREAM_BUFSIZE)
-buftest_size <<= 1;
- in_len = MIN(test_len, buftest_size);
- }
+ /* expand test length */
+ test_len <<= 1;
+ } while (test_len <= dlen);
+
+ if (!ret)
+ print_maxverbose("lz4 testing FAILED for chunk %ld. %d Passes\n", workcounter);
+ else {
+ print_maxverbose("lz4 testing OK for chunk %ld. Compressed size = %5.2F%% of chunk, %d Passes\n",
+s_len, 100 * ((double) best_dlen / (double) test_len), workcounter);
}
- print_maxverbose("lz4 testing %s for chunk %ld. Compressed size = %5.2F%% of chunk, %d Passes\n",
- (ret == 0? "FAILED" : "OK"), save_len,
- 100 * ((double) best_dlen / (double) in_len), workcounter);
dealloc(c_buf);
diff -Nru lrzip-0.640/WHATS-NEW lrzip-0.641/WHATS-NEW
--- lrzip-0.640/WHATS-NEW 2021-02-16 05:53:30.0 +0100
+++ lrzip-0.641/WHATS-NEW 2021-03-06 00:20:42.0 +0100
@@ -1,6 +1,11 @@
Changelog will be moved to git entirely from this point forward.
-lrzip-0.650
+lrzip-0.641
+
+Critical bugfix for broken lz4 testing which would prevent secondary
+compression from being enabled.
+
+lrzip-0.6
Bug#982180: nmu: cc1541_3.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, Please build cc1541 on amd64 buildd as it's a new package cleared from the NEW queue. nmu cc1541 3.2-1 . amd64 . unstable . -m "Rebuild amd64 on buildds after clearing NEW." Thanks, Laszlo/GCS
Bug#981453: buster-pu: package fetchmail/6.4.0~beta4-3+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi RMs,
There are two SSL related bugs in fetchmail that affect Buster. The
first cause is that otherwise working SSL connections fail sometimes
[1]. The fix is in 6.4.0~rc1 and in Bullseye since Aug, 2019.
The second is removing a forced OpenSSL version check that breaks
fetchmail. Fixed for Bullseye since November, 2020 [2].
Proposed patch is attached.
Thanks for consideration,
Laszlo/GCS
[1]
https://gitlab.com/fetchmail/fetchmail/-/commit/080d4632298636a9a1b21c3419c059b95fb3cd37.patch
[2] https://packages.qa.debian.org/f/fetchmail/news/20201119T192017Z.html
diff -Nru fetchmail-6.4.0~beta4/debian/changelog fetchmail-6.4.0~beta4/debian/changelog
--- fetchmail-6.4.0~beta4/debian/changelog 2019-02-06 17:33:00.0 +0100
+++ fetchmail-6.4.0~beta4/debian/changelog 2021-01-31 11:13:50.0 +0100
@@ -1,3 +1,11 @@
+fetchmail (6.4.0~beta4-3+deb10u1) buster; urgency=medium
+
+ * Backport fix to no longer reports System error during SSL_connect():
+Success (closes: #928916).
+ * Remove forced OpenSSL version check (closes: #980766).
+
+ -- Laszlo Boszormenyi (GCS) Sun, 31 Jan 2021 11:13:50 +0100
+
fetchmail (6.4.0~beta4-3) unstable; urgency=medium
* Backport fix potential SIGSEGV in pop3_delete (closes: #921450).
diff -Nru fetchmail-6.4.0~beta4/debian/patches/07_fix_System_error_during_SSL_connect_Success.patch fetchmail-6.4.0~beta4/debian/patches/07_fix_System_error_during_SSL_connect_Success.patch
--- fetchmail-6.4.0~beta4/debian/patches/07_fix_System_error_during_SSL_connect_Success.patch 1970-01-01 01:00:00.0 +0100
+++ fetchmail-6.4.0~beta4/debian/patches/07_fix_System_error_during_SSL_connect_Success.patch 2021-01-31 11:13:50.0 +0100
@@ -0,0 +1,55 @@
+From 080d4632298636a9a1b21c3419c059b95fb3cd37 Mon Sep 17 00:00:00 2001
+From: Matthias Andree
+Date: Mon, 5 Aug 2019 23:11:43 +0200
+Subject: [PATCH] fetchmail no longer reports System error during
+ SSL_connect(): Success.
+
+Fixes Debian Bug#928916, reported by Paul Kimoto.
+---
+ NEWS | 2 +
+ driver.c | 2 +-
+ po/de.po | 231 ---
+ socket.c | 9 ++-
+ 4 files changed, 127 insertions(+), 117 deletions(-)
+
+diff --git a/driver.c b/driver.c
+index 74e1b28a..3e382d3a 100644
+--- a/driver.c
b/driver.c
+@@ -1107,7 +1107,7 @@ static int do_session(
+ >remotename) == -1)
+ {
+ set_timeout(0);
+- report(stderr, GT_("SSL connection failed.\n"));
++ report(stderr, "%s: %s", ctl->sslcommonname ? ctl->sslcommonname : realhost, GT_("SSL connection failed.\n"));
+ err = PS_SOCKET;
+ goto cleanUp;
+ }
+diff --git a/socket.c b/socket.c
+index b3eaaecc..cb93b60e 100644
+--- a/socket.c
b/socket.c
+@@ -1225,14 +1225,17 @@ int SSLOpen(int sock, char *mycert, char *mykey, const char *myproto, int certck
+ if (SSL_set_fd(_ssl_context[sock], sock) == 0
+ || (ssle_connect = SSL_connect(_ssl_context[sock])) < 1) {
+ int e = errno;
+- unsigned long ssle_err_from_queue = ERR_peek_error();
+ unsigned long ssle_err_from_get_error = SSL_get_error(_ssl_context[sock], ssle_connect);
++ unsigned long ssle_err_from_queue = ERR_peek_error();
+ ERR_print_errors_fp(stderr);
+ if (SSL_ERROR_SYSCALL == ssle_err_from_get_error && 0 == ssle_err_from_queue) {
+ if (0 == ssle_connect) {
+- report(stderr, GT_("Server shut down connection prematurely during SSL_connect().\n"));
++ /* FIXME: the next line was hacked in 6.4.0-rc1 so the translation strings don't change.
++ * The %s could be merged to the inside of GT_(). */
++ report(stderr, "%s: %s", servercname, GT_("Server shut down connection prematurely during SSL_connect().\n"));
+ } else if (ssle_connect < 0) {
+- report(stderr, GT_("System error during SSL_connect(): %s\n"), strerror(e));
++ report(stderr, "%s: ", servercname);
++ report(stderr, GT_("System error during SSL_connect(): %s\n"), e ? strerror(e) : GT_("handshake failed at protocol or connection level."));
+ }
+ }
+ SSL_free( _ssl_context[sock] );
+--
+GitLab
+
diff -Nru fetchmail-6.4.0~beta4/debian/patches/08_remove_forced_OpenSSL_check.patch fetchmail-6.4.0~beta4/debian/patches/08_remove_forced_OpenSSL_check.patch
--- fetchmail-6.4.0~beta4/debian/patches/08_remove_forced_OpenSSL_check.patch 1970-01-01 01:00:00.0 +0100
+++ fetchmail-6.4.0~beta4/debian/patches/08_remove_forced_OpenSSL_check.patch 2021-01-31 11:13:50.0 +0100
@@ -0,0 +1,26 @@
+Description: Remove forced OpenSSL version check
+ Not needed, linker should take care of proper library loading.
+Author: Laszlo Boszormenyi (GCS)
+Bug-Debian: https://bugs.debian.org/973472
+Forwarded: no
+Last-Update: 2020-11-19
+
+---
+
+--- fetchmail-6.4.13.orig/socket.c
fetchmail-6.4.13/
Bug#979397: transition: ntfs-3g
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Only three packages are affected: partclone, testdisk and wimlib. Test rebuilds are fine on amd64 but as freeze is around the corner I can test it on more architectures if needed. The main note that it has an udeb so probably KiBi also would like to ACK / NACK this transition. Regards, Laszlo/GCS
Bug#978072: transition: libcrypto++
On Fri, Dec 25, 2020 at 3:21 PM Sebastian Ramacher wrote: > Control: tags -1 confirmed Thanks, uploaded and already built on all primary and most secondary (port) architectures. Cheers, Laszlo/GCS
Bug#978072: transition: libcrypto++
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, I would like to ship the recently released Crypto++ 8.3.0 release for Bullseye. List of reverse dependencies are as follows: amule clementine codecrypt entropybroker securefs tegrarcm [non-free] Currently entropybroker fails to build with this Crypto++ release, but its upstream has a fix for that. Package maintainer noted about this [1]. Thanks for consideration, Laszlo/GCS [1] https://bugs.debian.org/978071
Bug#976732: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Small transition of RocksDB from 5.17 to 6.11 which affects two packages: balboa and vg. Both built fine with the new version of RocksDB. Thanks for consideration, Laszlo/GCS
Bug#976019: buster-pu: package vips/8.7.4-1+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi SRMs, There's a minor information leak, CVE-2020-20739 in VIPS which doesn't warrant a DSA. I would like to fix it with a PU, proposed patch is attached. Thanks for consideration, Laszlo/GCS diff -Nru vips-8.7.4/debian/changelog vips-8.7.4/debian/changelog --- vips-8.7.4/debian/changelog 2019-01-18 18:07:38.0 +0100 +++ vips-8.7.4/debian/changelog 2020-11-21 17:50:57.0 +0100 @@ -1,3 +1,9 @@ +vips (8.7.4-1+deb10u1) buster; urgency=medium + + * Fix CVE-2020-20739: variable used-before-set error in im_vips2dz() . + + -- Laszlo Boszormenyi (GCS) Sat, 21 Nov 2020 17:50:57 +0100 + vips (8.7.4-1) unstable; urgency=medium * New upstream release. diff -Nru vips-8.7.4/debian/patches/fix-used-before-set_error-in-im_vips2dz.patch vips-8.7.4/debian/patches/fix-used-before-set_error-in-im_vips2dz.patch --- vips-8.7.4/debian/patches/fix-used-before-set_error-in-im_vips2dz.patch 1970-01-01 01:00:00.0 +0100 +++ vips-8.7.4/debian/patches/fix-used-before-set_error-in-im_vips2dz.patch 2020-11-21 17:50:57.0 +0100 @@ -0,0 +1,26 @@ +From 2ab5aa7bf515135c2b02d42e9a72e4c98e17031a Mon Sep 17 00:00:00 2001 +From: John Cupitt +Date: Tue, 3 Sep 2019 13:17:18 +0100 +Subject: [PATCH] fix a used-before-set error in im_vips2dz + +we were reading an uninited string in a vips7 compatibility wrapper, thanks +yifengchen-cc + +see https://github.com/libvips/libvips/issues/1419 +--- + libvips/deprecated/im_vips2dz.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/libvips/deprecated/im_vips2dz.c b/libvips/deprecated/im_vips2dz.c +index 6dbde78c3..aafe8f99d 100644 +--- a/libvips/deprecated/im_vips2dz.c b/libvips/deprecated/im_vips2dz.c +@@ -75,6 +75,8 @@ im_vips2dz( IMAGE *in, const char *filename ) + *p = '\0'; + im_strncpy( mode, p + 1, FILENAME_MAX ); + } ++ else ++ strcpy( mode, "" ); + + strcpy( buf, mode ); + p = [0]; diff -Nru vips-8.7.4/debian/patches/series vips-8.7.4/debian/patches/series --- vips-8.7.4/debian/patches/series 2018-07-24 21:17:08.0 +0200 +++ vips-8.7.4/debian/patches/series 2020-11-21 17:50:57.0 +0100 @@ -1 +1,2 @@ reproducible-build.patch +fix-used-before-set_error-in-im_vips2dz.patch
Bug#974737: transition: botan
On Sun, Nov 15, 2020 at 10:11 PM Sebastian Ramacher wrote: > Control: tags -1 + confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-botan.html > > On 2020-11-14 13:37:03 +0100, László Böszörményi wrote: > > Last botan 2.x release (botan version 3 is a new upstream project) is > > in experimental. It would be good to have it for Bullseye. The only > > one reverse dependency is Thunderbird which builds fine with this > > version as well. > > Please go ahead Uploaded and it was built already. Cheers, Laszlo/GCS
Bug#974737: transition: botan
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Last botan 2.x release (botan version 3 is a new upstream project) is in experimental. It would be good to have it for Bullseye. The only one reverse dependency is Thunderbird which builds fine with this version as well. Thanks, Laszlo/GCS
Bug#973541: transition: botan
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, I would like to upload botan/2.16.0+dfsg-1 to Sid and only Thunderbird will need to be binNMUed. I've tested and it builds correctly with this botan version as well. Thanks, Laszlo/GCS
Bug#973518: transition: libsidplayfp
On Sun, Nov 1, 2020 at 9:29 AM Sebastian Ramacher wrote: > Control: tags -1 confirmed [...] > > Small transition of libsidplayfp affecting four packages: > > audacious-plugins, mpd, qmmp and sidplayfp itself. All built with > > libsidplayfp/2.0.5-1 correctly. Hope this can be allowed. > > Please go ahead. Thanks, uploaded and already built on all architectures except Hurd/i386 where it is still in the queue. I've uploaded the matching sidplayfp to Sid. This makes only audacious-plugins, mpd and qmmp to be binNMUed. Cheers, Laszlo/GCS
Bug#973518: transition: libsidplayfp
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Small transition of libsidplayfp affecting four packages: audacious-plugins, mpd, qmmp and sidplayfp itself. All built with libsidplayfp/2.0.5-1 correctly. Hope this can be allowed. Thanks, Laszlo/GCS
Bug#972115: buster-pu: package sqlite3/3.27.2-3+deb10u1
On Sat, Oct 24, 2020 at 8:51 PM Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Mon, 2020-10-12 at 22:50 +0200, Moritz Muehlenhoff wrote: > > A number of security fixes in sqlite, which don't warrant a DSA. [...] > Please go ahead. Thanks, uploaded. Cheers, Laszlo/GCS
Bug#972115: buster-pu: package sqlite3/3.27.2-3+deb10u1
On Mon, Oct 12, 2020 at 10:54 PM Moritz Muehlenhoff wrote: > A number of security fixes in sqlite, which don't warrant a DSA. > This has been tested on a Buster system (along with validating > included test cases that issues are correctly fixed). I don't know if it counts, but being the original maintainer and I do second the work of Moritz. My time is limited nowadays, but I did a quick check and the proposed update is correct. Please let it enter Buster. Thanks Moritz, Laszlo/GCS
Bug#971958: transition: libpgm
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, I'm asking for a small transition of libpgm. Two packages are affected, libxs and zeromq3. The latter builds fine with libpgm 5.3 in experimental. The question is libxs because while I submitted a patch [1] that fixes its FTBFS with libpgm 5.3, it seems to be a dead weight. The upstream of it [2] disappeared. Popcon shows nine users and its maintainer didn't update it for four and half years (ie Standards-Version is still 3.9.7, debhelper level is 9). Thanks, Laszlo/GCS [1] https://bugs.debian.org/971957 [2] https://github.com/crossroads-io/libxs
Bug#971024: transition: botan
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, I would like to update Botan from libbotan-2-13 to libbotan-2-15 in Sid. Bit complex situation. Transition tracker shows biboumi as the only reverse dependency. I didn't try to build it with the new Botan as it fails to build with GCC 10 anyway. For this, an RC bug already exists and the package was removed from testing some time ago. Last maintainer upload was over two years ago. But Thunderbird also affected, if only the version in experimental. Build tested it with the new Botan version. Builds correctly, but I doubt you will binNMU it there. Thanks, Laszlo/GCS
Bug#966203: transition: grpc
On Fri, Jul 24, 2020 at 6:24 PM László Böszörményi wrote: > Transition of gRPC that I've already uploaded. The only affected > package is src:collectd - the Sid upload of that FTBFS on armel and > mipsel due to a problem in the previous gRPC version. This new upload > should fix that, so please binNMU collectd on all architectures. Note that our recent gRPC and collectd uploads have collided. Now collectd needs to be binNMUed against gRPC 1.30.2-2 / libgrpc10 only on mips64el and mipsel (it will fix the build failure). Laszlo/GCS
Bug#966203: transition: grpc
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Transition of gRPC that I've already uploaded. The only affected package is src:collectd - the Sid upload of that FTBFS on armel and mipsel due to a problem in the previous gRPC version. This new upload should fix that, so please binNMU collectd on all architectures. Thanks, Laszlo/GCS
Bug#963728: transition: protobuf
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, The new soname release of Protobuf is available in experimental for some time. Packages starting to need it, thus time for the transition. According to my testing, the only failing to build packages are mozc, onnx, vg, ignition-fuel-tools, ignition-transport and gazebo. Filed bugs for these and recently got a message[1] that another maintainer re-tested ignition-fuel-tools, ignition-transport and gazebo. A binNMU would be sufficient for these as well. The only remaining FTBFS packages are mozc, onnx and vg. Thanks, Laszlo/GCS [1] https://bugs.debian.org/963248#10
Bug#961979: transition: libwebsockets
On Thu, Jun 11, 2020 at 4:10 PM Paul Gevers wrote: > On 11-06-2020 13:46, László Böszörményi (GCS) wrote: > > Basically the transition is over. > > Only when everything is in testing. Indeed, that's what I meant it's (only) basically over. The migration of packages (when this transition can be closed) only depends on time now. Sorry for the confusion, Laszlo/GCS
Bug#961979: transition: libwebsockets
On Thu, Jun 11, 2020 at 9:02 AM László Böszörményi (GCS) wrote: > On Wed, Jun 10, 2020 at 9:51 PM Sebastian Ramacher > wrote: > > Please go ahead with the upload to unstable. > Thanks, 4.0.15-2 was uploaded, built and installed on most architectures. Then all reverse dependencies are (re-)built and installed on all primary architectures. Basically the transition is over. Thanks, Laszlo/GCS
Bug#961979: transition: libwebsockets
On Wed, Jun 10, 2020 at 9:51 PM Sebastian Ramacher wrote: > > Small transition with four affected packages: driftnet, forked-daapd, > > janus and mosquitto. > > All build fine with the libwebsockets 4.0.13 version in experimental. > > Please go ahead with the upload to unstable. Thanks, 4.0.15-2 was uploaded, built and installed on most architectures. Cheers, Laszlo/GCS
Bug#960193: ICU rebuilds in experimental
Hi, On Tue, Jun 9, 2020 at 12:15 PM Pino Toscano wrote: > can you please rebuild for the ICU transition also the packages in > experimental? I can't schedule binNMUs myself, but Sebastian can. Please, if you have time schedule binNMUs of the following packages with ICU 67.1 in _experimental_: > dcmtk > gnustep-base > gnustep-gui > libqalculate > performous > qtbase-opensource-src > qtlocation-opensource-src > qtwebkit-opensource-src > webkit2gtk > zimwriterfs Thanks, Laszlo/GCS
Bug#960193: transition: icu
On Mon, Jun 1, 2020 at 2:53 PM Sebastian Ramacher wrote: > On 2020-06-01 12:40:32, László Böszörményi wrote: > > @Sebastian: As I see, that's finished for some time now. > > Indeed, so please go ahead with upload of icu to unstable. I will binNMU > boost1.71 immediately and once those are done Giovanni can upload the > boost-defaults switch. ICU just built on most and all primary architectures. Boost builds are coming in - regressed on riscv64 due to GCC ICE, but given back on an other buildd. Thanks, Laszlo/GCS
Bug#961979: transition: libwebsockets
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Small transition with four affected packages: driftnet, forked-daapd, janus and mosquitto. All build fine with the libwebsockets 4.0.13 version in experimental. Thanks for consideration, Laszlo/GCS
