Bug#1070300: pmix_psquash_base_select failed during MPI_INIT on 32bit architectures
Hi, the problem already appears in OpenMPI's own autopkgtests, see [1] Best, Markus [1] https://ci.debian.net/packages/o/openmpi/unstable/i386/46207866/
Bug#1070300: pmix_psquash_base_select failed during MPI_INIT on 32bit architectures
Source: openmpi Version: 4.1.6-13 Severity: serious Justification: unkown Control: affects -1 src:dune-grid Dear Maintainer, I just uploaded a new version of package dune-grid and noticed that none of our parallel tests start successfully on 32bit architectures. 2/66 Test #2: scsgmappertest ***Failed0.15 sec -- It looks like pmix_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during pmix_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an PMIX developer): pmix_psquash_base_select failed --> Returned value -46 instead of PMIX_SUCCESS -- [arm-ubc-05:12560] PMIX ERROR: NOT-FOUND in file ../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/server/pmix_server.c at line 237 [arm-ubc-05:12559] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node in file ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at line 716 [arm-ubc-05:12559] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node in file ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at line 172 -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): orte_ess_init failed --> Returned value Unable to start a daemon on the local node (-127) instead of ORTE_SUCCESS -- -- It looks like MPI_INIT failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during MPI_INIT; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): ompi_mpi_init: ompi_rte_init failed --> Returned "Unable to start a daemon on the local node" (-127) instead of "Success" (0) -- *** An error occurred in MPI_Init *** on a NULL communicator *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, ***and potentially your MPI job) [arm-ubc-05:12559] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed! See [1] for a complete build where the tests using mpirun fail in this way. This happens on these architectures: armel, armhf, i386, hppa Best, Markus [1] https://buildd.debian.org/status/fetch.php?pkg=dune- grid=armel=2.9.0-4=1714724856=0 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/64 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openmpi-bin depends on: ii libc62.36-9+deb12u6 ii libevent-core-2.1-7 2.1.12-stable-8 ii libopenmpi3 4.1.4-3+b1 ii openmpi-common 4.1.4-3 ii openssh-client [ssh-client] 1:9.2p1-2+deb12u2 openmpi-bin recommends no packages. Versions of packages openmpi-bin suggests: ii gfortran [fortran-compiler] 4:12.2.0-3 -- no debconf information
Bug#1070296: compile freerdp2 with WITH_GSSAPI
Package: libfreerdp2-2 Version: 2.10.0+dfsg1-1 Remmina and other RDP clients are unable to connect to Windows RDP servers when the user is member of the group "Protected Users". The group "Protected Users" forces the user account to use Kerberos authentication and is recommended to prevent Kerberos Tickets and password hashes to be cached on the server. Typically these tickets and hashes are used for lateral movement after a breach. libfreerdp2-2 needs to be compiled with "WITH_GSSAPI=on" to be able to connect with user accounts protected in such a way. Kind Regads, Markus Wigge
Bug#1069967: fai-client: install_packages E: Unable to locate package ...
Package: fai-client Severity: wishlist Dear Maintainer, When a non-existing package is in the list of packages passed to install_packages apt-get responds with the following error message. E: Unable to locate package ... This in turn fails the installation of all the packages in the list. I know this is the default behavior of apt-get but I would like to request an option for install_packages to ignore non-existing packages and retry the installation again with the same list but without the non-existing package(s). If such an option won't be implemented then an option to isolate a list of packages to be installed could also work. Then a user could define a list of packages that they would be ok with not being installed due to reasons such as them being non-existing. -- Markus
Bug#1069492: Seems to be an OpenMPI problem
Hi, the problem occurs during startup of OpenMPI when running mpirun. I see similar problems for other packages during the same rebuild. Hence I don't think this is related to us but rather to OpenMPI. Best, Markus
Bug#1069581: pymongo: CVE-2024-21506 out-of-bound read
Package: pymongo X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for pymongo. CVE-2024-21506[0]: | Versions of the package pymongo before 4.6.3 are vulnerable to Out- | of-bounds Read in the bson module. Using the crafted payload the | attacker could force the parser to deserialize unmanaged memory. The | parser tries to interpret bytes next to buffer and throws an | exception with string. If the following bytes are not printable | UTF-8 the parser throws an exception with a single byte. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-21506 https://www.cve.org/CVERecord?id=CVE-2024-21506 Please adjust the affected versions in the BTS as needed. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1064762: Upstream has an incoming fix
Hi, seems like upstream already has a proposed fix, see [1] Best, Markus [1] https://gitlab.kitware.com/vtk/vtk/-/issues/19258#note_1510307
Bug#1065270: Unable to open VTK file with appended data that were fine with previous versions (invalid token in vtkXMLDataParser)
Hi, Note that this is kind of a duplicate of [0]. I have marked [0] as blocking this one. Some further information: I tried to follow this up a bit. Looking at the upstream expat bugs [1] [2] it might very well be that vtk9 was relying in internals of expat's xml processing and their assumptions broke when moving to 2.6.0. Hence this probably is an incompatibility on vtk9's side rather than a bug in expat. At least upstream thinks that way in in [1] and closed the bug. The stalled discussion about this in VTK9 can be found in [3]. Should we reassing this to vtk9? Best, Markus [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064762 [1] https://github.com/libexpat/libexpat/issues/857 [2] https://github.com/libexpat/libexpat/issues/840 [3] https://gitlab.kitware.com/vtk/vtk/-/issues/19258
Bug#1064762: Might be an incompatibility of vtk9 with expat/2.6.0
Hi. I tried to follow this up a bit. Looking at the upstream expat bugs [1] [2] it might very well be that vtk9 was relying in internals of expat's xml processing and their assumptions broke when moving to 2.6.0. Hence this probably is an incompatibility on vtk9's side rather than a bug in expat. At least upstream thinks that way in in [1] and closed the bug. The stalled discussion about this in VTK9 can be found in [3]. Should we reassing this to vtk9? Best, Markus [1] https://github.com/libexpat/libexpat/issues/857 [2] https://github.com/libexpat/libexpat/issues/840 [3] https://gitlab.kitware.com/vtk/vtk/-/issues/19258
Bug#1034420: grub-efi-amd64: Package update fails with error: installation script subprocess returned error exit status 128
Hi, I am running into the same problem. One of my machines fails the install with: installed grub-efi-amd64 package post-installation script subprocess returned error exit status 128 here the full log with -x in and DEBCONF_DEBUG=developer # dpkg --configure -a --debug=77 D01: root= admindir=/var/lib/dpkg D01: ensure_diversions: new, (re)loading D01: process queue pkg grub-efi:amd64 queue.len 1 progress 1, try 1 D40: checking dependencies of grub-efi:amd64 (- ) D000400: checking group ... D000400: checking possibility -> grub-common D000400: checking non-provided pkg grub-common:amd64 D000400: is installed, ok and found D000400: found 3 D000400: found 3 matched 0 possfixbytrig - D000400: checking group ... D000400: checking possibility -> grub-efi-amd64 D000400: checking non-provided pkg grub-efi-amd64:amd64 D000400: unpacked/halfconfigured, defer D000400: found 1 D000400: found 1 matched 0 possfixbytrig - D40: ok 1 msgs >><< D01: process queue pkg grub-efi-amd64:amd64 queue.len 1 progress 2, try 1 D40: checking dependencies of grub-efi-amd64:amd64 (- ) D000400: checking group ... D000400: checking possibility -> debconf D000400: checking non-provided pkg debconf:all D000400: is installed, ok and found D000400: found 3 D000400: found 3 matched 0 possfixbytrig - D000400: checking group ... D000400: checking possibility -> grub-common D000400: checking non-provided pkg grub-common:amd64 D000400: is installed, ok and found D000400: found 3 D000400: found 3 matched 0 possfixbytrig - D000400: checking group ... D000400: checking possibility -> grub2-common D000400: checking non-provided pkg grub2-common:amd64 D000400: is installed, ok and found D000400: found 3 D000400: found 3 matched 0 possfixbytrig - D000400: checking group ... D000400: checking possibility -> grub-efi-amd64-bin D000400: checking non-provided pkg grub-efi-amd64-bin:amd64 D000400: is installed, ok and found D000400: found 3 D000400: found 3 matched 0 possfixbytrig - D000400: checking group ... D000400: checking possibility -> ucf D000400: checking non-provided pkg ucf:all D000400: is installed, ok and found D000400: found 3 D000400: found 3 matched 0 possfixbytrig - D40: ok 2 msgs >><< D40: checking Breaks D000400: checking breaker grub2-common:amd64 virtbroken Setting up grub-efi-amd64 (2.06-13+deb12u1) ... D02: trigproc_activate_packageprocessing pkg=grub-efi-amd64:amd64 D02: fork/exec /var/lib/dpkg/info/grub-efi-amd64.postinst ( configure 2.06-3~deb11u6 ) + cached_available_ids= + case "$1" in + . /usr/share/debconf/confmodule ++ '[' '!' '' ']' ++ PERL_DL_NONLAZY=1 ++ export PERL_DL_NONLAZY ++ '[' '' ']' ++ exec /usr/share/debconf/frontend /var/lib/dpkg/info/grub-efi-amd64.postinst configure 2.06-3~deb11u6 debconf (developer): frontend started debconf (developer): frontend running, package name is grub-efi-amd64 debconf (developer): starting /var/lib/dpkg/info/grub-efi-amd64.config configure 2.06-3~deb11u6 debconf (developer): <-- SET grub2/linux_cmdline debconf (developer): --> 0 value set debconf (developer): <-- SET grub2/linux_cmdline_default module.sig_enforce=0 i915.preliminary_hw_support=1 intel_iommu=on amd_iommu=on kvm_amd.npt=1 kvm_amd.avic=1 iommu=pt debconf (developer): --> 0 value set debconf (developer): <-- debconf (developer): --> 20 Bad line "" received from confmodule. debconf (developer): <-- INPUT medium grub2/linux_cmdline debconf (developer): --> 30 question skipped debconf (developer): <-- INPUT medium grub2/linux_cmdline_default debconf (developer): --> 30 question skipped debconf (developer): <-- INPUT low grub2/enable_os_prober debconf (developer): --> 30 question skipped debconf (developer): <-- INPUT low grub2/force_efi_extra_removable debconf (developer): --> 30 question skipped debconf (developer): <-- INPUT low grub2/update_nvram debconf (developer): --> 30 question skipped debconf (developer): <-- GO debconf (developer): --> 0 ok dpkg: error processing package grub-efi-amd64 (--configure): installed grub-efi-amd64 package post-installation script subprocess returned error exit status 128 D02: post_script_tasks - ensure_diversions D01: ensure_diversions: same, skipping D02: post_script_tasks - trig_incorporate D01: process queue pkg grub-efi:amd64 queue.len 0 progress 1, try 1 D40: checking dependencies of grub-efi:amd64 (- ) D000400: checking group ... D000400: checking possibility -> grub-common D000400: checking non-provided pkg grub-common:amd64 D000400: is installed, ok and found D000400: found 3 D000400: found 3 matched 0 possfixbytrig - D000400: checking group ... D000400: checking possibility -> grub-efi-amd64 D000400: checking non-provided pkg grub-efi-amd64:amd64 D000400: not configured/able
Bug#1068514: bullseye-pu: package imlib2/1.7.1-2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: iml...@packages.debian.org, a...@debian.org
Control: affects -1 + src:imlib2
[ Reason ]
Fixing CVE-2024-25447, CVE-2024-25448 and CVE-2024-25450 in bullseye.
[ Impact ]
CVE remain unfixed in bullseye while they are already fixed in stable
and newer distributions.
[ Tests ]
Code changes are trivial
[ Risks ]
Code changes are trivial and are already present in bookworm. No
regressions have been reported.
[ 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 (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
A variable in the tgaflip function was multiplied with the height and not
the width which can cause a heap buffer overflow.
diff -Nru imlib2-1.7.1/debian/changelog imlib2-1.7.1/debian/changelog
--- imlib2-1.7.1/debian/changelog 2021-01-23 22:00:25.0 +0100
+++ imlib2-1.7.1/debian/changelog 2024-04-06 22:40:50.0 +0200
@@ -1,3 +1,11 @@
+imlib2 (1.7.1-2+deb11u1) bullseye; urgency=medium
+
+ * Fix CVE-2024-25447 and CVE-2024-25448 and CVE-2024-25450.
+A heap-buffer overflow vulnerability was discovered in imlib2 when using
+the tgaflip function in loader_tga.c
+
+ -- Markus Koschany Sat, 06 Apr 2024 22:40:50 +0200
+
imlib2 (1.7.1-2) unstable; urgency=medium
* Drop obsolete libltdl3-dev dependency.
diff -Nru
imlib2-1.7.1/debian/patches/CVE-2024-25447-and-CVE-2024-25448-and-CVE-2024-25450.patch
imlib2-1.7.1/debian/patches/CVE-2024-25447-and-CVE-2024-25448-and-CVE-2024-25450.patch
---
imlib2-1.7.1/debian/patches/CVE-2024-25447-and-CVE-2024-25448-and-CVE-2024-25450.patch
1970-01-01 01:00:00.0 +0100
+++
imlib2-1.7.1/debian/patches/CVE-2024-25447-and-CVE-2024-25448-and-CVE-2024-25450.patch
2024-04-06 22:40:50.0 +0200
@@ -0,0 +1,26 @@
+From: Markus Koschany
+Date: Fri, 5 Apr 2024 16:29:27 +0200
+Subject: CVE-2024-25447 and CVE-2024-25448 and CVE-2024-25450
+
+Origin:
https://git.enlightenment.org/old/legacy-imlib2/commit/e9c09deb08047c9e902ce37144e82b6edb8aedb6
+---
+ src/modules/loaders/loader_tga.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/modules/loaders/loader_tga.c
b/src/modules/loaders/loader_tga.c
+index e9729b0..ae96a3b 100644
+--- a/src/modules/loaders/loader_tga.c
b/src/modules/loaders/loader_tga.c
+@@ -595,9 +595,9 @@ tgaflip(DATA32 * in, int w, int h, int fliph, int flipv)
+ x2 = fliph ? w - 1 : 0;
+ for (x = 0; x < nx; x++, x2 += dx)
+ {
+- tmp = in[y * h + x];
+- in[y * h + x] = in[y2 * h + x2];
+- in[y2 * h + x2] = tmp;
++ tmp = in[y * w + x];
++ in[y * w + x] = in[y2 * w + x2];
++ in[y2 * w + x2] = tmp;
+ }
+ }
+ }
diff -Nru imlib2-1.7.1/debian/patches/series imlib2-1.7.1/debian/patches/series
--- imlib2-1.7.1/debian/patches/series 2021-01-23 22:00:25.0 +0100
+++ imlib2-1.7.1/debian/patches/series 2024-04-06 22:40:50.0 +0200
@@ -1 +1,2 @@
01_removed-data-dir.patch
+CVE-2024-25447-and-CVE-2024-25448-and-CVE-2024-25450.patch
Bug#1060381: tomcat10: catalina.out is not recreated after deletion
Control: tags -1 moreinfo [already CCed the submitter but forgot to add the bug report] Hello Daniel, On Wed, 10 Jan 2024 12:42:34 +0100 Daniel von Obernitz wrote: > Package: tomcat10 > Version: 10.1.6-1+deb12u1 > Severity: normal > X-Debbugs-Cc: t...@security.debian.org > > Dear Maintainer, > > when you stop tomcat10.service and delete the /var/log/tomcat10/catalina.out, the file will not be recreated after the next tomcat10.service start. [...] I don't understand the problem here. You deliberately deleted catalina.out. What stops you from using touch /var/log/tomcat10/catalina.out to recreate it? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Am Fri, Apr 05, 2024 at 05:58:15AM + schrieb Thorsten Glaser: > Markus Wichmann dixit: > >In any case, the emission of non-relative relocations is the issue here, > >and it is coming from the linker. > > They are present in the glibc static-pie binary as well, though. > And tbh they look to me like “just plug the absolute address of > the symbol here, please”, which is perfectly fine for things like > an array of strings when the actual string has already its own symbol. > > (Disclaimer: I know… barely anything about Unix relocation types, > a bit more about those on DOS and even TOS.) > Then glibc's static-pie startup code also processes symbolic relocations. musl's doesn't. It only processes relative relocations. And changing this would require some massive reworking. We'd somehow have to put stage 2 of the dynamic linker into rcrt1.o. A symbolic lookup doesn't really make sense for a static executable outside of FDPIC. The only difference in address space possible is a relative offset. In order to do a symbolic relocation, you also need the symbol lookup stuff, which - granted - for a static PIE is probably very simple because there can be only one symbol table, but still. I thought the whole point of static-PIE support was to only leave relative relocations around. Ciao, Markus
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Am Fri, Apr 05, 2024 at 05:04:37AM + schrieb Thorsten Glaser: > Should be correct: > > /usr/libexec/gcc/s390x-linux-gnu/13/collect2 -fno-lto -dynamic-linker > /lib/ld-musl-s390x.so.1 -nostdlib -static -static -pie --no-dynamic-linker -o > mksh /usr/lib/s390x-linux-musl/rcrt1.o /usr/lib/s390x-linux-musl/crti.o > /usr/lib/gcc/s390x-linux-gnu/13/crtbeginS.o -L/usr/lib/s390x-linux-musl -L > /usr/lib/gcc/s390x-linux-gnu/13/. -z relro -z now --as-needed -z text > --eh-frame-hdr lalloc.o edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o > lex.o main.o misc.o shf.o syn.o tree.o var.o ulimit.o --start-group > /usr/lib/gcc/s390x-linux-gnu/13/libgcc.a > /usr/lib/gcc/s390x-linux-gnu/13/libgcc_eh.a -lc --end-group > /usr/lib/gcc/s390x-linux-gnu/13/crtendS.o /usr/lib/s390x-linux-musl/crtn.o > > HTH & HAND, > //mirabilos I may not really know what I am talking about, so take this with a grain of salt, but isn't this missing a -Bsymbolic somewhere? Ironically, that switch causes ld to not emit symbolic relocations. I seem to remember reading long ago in Rich's initial -static-pie proposal that that was one of the switches added to the linker command line. In any case, the emission of non-relative relocations is the issue here, and it is coming from the linker. Ciao, Markus
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Hi, in static-pie, relocations get processed in _start, before main() is called. In musl, this is done by linking with rcrt1.o as start file instead of crt1.o. And that file processes all relative relocations. You can check with readelf -r what the relocation types are. If they are not relative, they will not be processed. What you are seeing seems indicative of missing relocation processing. Is it possible you are linking in the wrong start file? gcc -v should output the command line it feeds to the linker. Ciao, Markus
Bug#1043227: patch still valid? (opm-common: test failure on ppc64el with -O3)
Hi,
Concerning the patch: It seems like -O2 is the default in Debian now anyway.
Will the patch still work as it is?
I did some investigations on platti.debian.org. I have no idea what the problem
is. My hunch is that compiler optimization breaks the code here. If I add a
simple print statement like this then the test passes:
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$ git diff
opm/output/data/InterRegFlow.hpp
diff --git a/opm/output/data/InterRegFlow.hpp b/opm/output/data/InterRegFlow.hpp
index 0e1dadcc4..7e2aeabbe 100644
--- a/opm/output/data/InterRegFlow.hpp
+++ b/opm/output/data/InterRegFlow.hpp
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
namespace Opm { namespace data {
/// Intermediary Protocol to Linearise Per-Connection Flow Rates Into
Subrange.
@@ -271,7 +271,7 @@ namespace Opm { namespace data {
using sz_t = decltype(InterRegFlow::bufferSize());
const auto& [begin, end] = this->elements_;
-
+std::cout<<"distance=";//<< std::distance(begin, end);// << " size="<<
InterRegFlow::bufferSize()<(std::distance(begin, end))
== InterRegFlow::bufferSize();
}
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$
Best,
Markus
Bug#1055857: patch still valid? (opm-common: test failure on ppc64el with -O3)
Hi,
Concerning the patch: It seems like -O2 is the default in Debian now anyway.
Will the patch still work as it is?
I did some investigations on platti.debian.org. I have no idea what the problem
is. My hunch is that compiler optimization breaks the code here. If I add a
simple print statement like this then the test passes:
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$ git diff
opm/output/data/InterRegFlow.hpp
diff --git a/opm/output/data/InterRegFlow.hpp b/opm/output/data/InterRegFlow.hpp
index 0e1dadcc4..7e2aeabbe 100644
--- a/opm/output/data/InterRegFlow.hpp
+++ b/opm/output/data/InterRegFlow.hpp
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
namespace Opm { namespace data {
/// Intermediary Protocol to Linearise Per-Connection Flow Rates Into Subrange.
@@ -271,7 +271,7 @@ namespace Opm { namespace data {
using sz_t = decltype(InterRegFlow::bufferSize());
const auto& [begin, end] = this->elements_;
-
+std::cout<<"distance=";//<< std::distance(begin, end);// << " size="<<
InterRegFlow::bufferSize()<(std::distance(begin, end))
== InterRegFlow::bufferSize();
}
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$
Best,
Markus
Bug#1066983: monopd: Fails to start monopd.service
Hello Shriram, Am Mittwoch, dem 27.03.2024 um 15:10 +0530 schrieb Shriram Ravindranathan: > Dear Markus, > > On 27/03/24 13:01, Markus Koschany wrote: > > As this bug report proves, normal people tend to have problems with system > > services. A system administrator would have simply disabled or masked the > > service. There is nothing here what could not have been resolved with some > > systemctl commands. > I am sorry but I don't understand the point you are trying to make here. > I don't think it is in the right spirit that we should expect anybody > (even sysadmins) to bodge the package somehow and get it to work. > The package is not broken and the bug severity is incorrect. Sylvain already explained what you could have done with systemctl to solve this issue. signature.asc Description: This is a digitally signed message part
Bug#1066983: monopd: Fails to start monopd.service
Hi Sylvain, Am Montag, dem 25.03.2024 um 18:48 +0100 schrieb Sylvain Rochet: > Hi Markus, > > On Mon, Mar 25, 2024 at 02:36:59AM +0100, Markus Koschany wrote: > > Sylvain Rochet wrote: > > > Actually, the main problem is /lib/systemd/system/monopd.socket which > > > set Accept=yes while monopd needs Accept=no (which is the default value). > > > > I wonder if monopd needs a systemd socket file at all and if we should > > disable the service after the installation. We have been using this > > setting since the introduction of systemd. If monopd runs with > > Accept=no then we also don't need a service template file. At some > > point I also noticed the same warning as Shriram > > > > "monopd.socket is a disabled or a static unit not running, not > > starting it." and then followed [1] and added the required template > > file. > > Yeah, socket activation is not really useful for public servers > services, it is mostly used for local services that can be spawned on > the fly later. Furthermore, socket activation breaks monopd metaserver > registration because the daemon must be running to register, so better > only ship the service file. I let you decide whether the service should > be disabled or enabled by default (but unless something recently > changed, daemon usually runs by default on Debian. I admit having lost > track :D). Our Policy is still to enable autostarting a service but I also don't see a must directive in 9.3.3.1 [1], so if there is a good reason it should be OK to disable the service and let the local administrator re-enable it, if desired. > > I have been running monopd for the past decade and I also suspect the > > daemon is affected by some bugs which might be remotely exploitable. > > What makes you think that? > > My daemon is running attached to gdb so I can easily catch and trace any > issue that would kill the process. So far it's been over 10 years > without a single issue, some process lived for several years between > systems reboot. > > I am not saying it is bug free because nothing is bug free, but if it is > remotely exploitable and actively exploited, I would be aware of it on > my running instance. I have seen multiple lines like that in my log files before: monopd.service: main process exited, code=killed, status=11/SEGV It happens from time to time but at some time it was more frequent which made me believe that some players found a way to reproducibly crash the server. I can send you my log file but you probably can't easily debug the problem because there was no gdb attached to the process. > > Since users usually don't need the monopd server anyway, if they want > > to play a game, they should make a conscious decision to start it if > > they want to use it locally. For a simple internet game, the daemon is > > not required. > > Installing the server package isn't already a conscious decision? As this bug report proves, normal people tend to have problems with system services. A system administrator would have simply disabled or masked the service. There is nothing here what could not have been resolved with some systemctl commands. However I believe I just remove the systemd socket file now and be done with it. There are pros and cons for autostarting the service or disabling it but we don't need to overthink this. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1066983: monopd: Fails to start monopd.service
Sylvain Rochet wrote: > Actually, the main problem is /lib/systemd/system/monopd.socket which > set Accept=yes while monopd needs Accept=no (which is the default value). I wonder if monopd needs a systemd socket file at all and if we should disable the service after the installation. We have been using this setting since the introduction of systemd. If monopd runs with Accept=no then we also don't need a service template file. At some point I also noticed the same warning as Shriram "monopd.socket is a disabled or a static unit not running, not starting it." and then followed [1] and added the required template file. I have been running monopd for the past decade and I also suspect the daemon is affected by some bugs which might be remotely exploitable. Since users usually don't need the monopd server anyway, if they want to play a game, they should make a conscious decision to start it if they want to use it locally. For a simple internet game, the daemon is not required. [1] https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html signature.asc Description: This is a digitally signed message part
Bug#1051647: please ship a fd(1) binary
Severity: normal Hello there, Would love this too. Some tooling looks for an `fd` binary and won't find an `fd` alias. Another problem is that the shell completions for bash/zsh shipped with the package don't work, since they define a `_fd` completion function. You can work around it with either `alias fd=fdfind` or `alias _fdfind=_fd`, but it would be nice not to have to. Raising the severity to normal because of this (first time doing that, not sure if it will actually work :)) Thanks, Markus
Bug#1064762: Bug is actually in expat xml-parser
Hi, One of the DUNE developers has some more insight on this: https://gitlab.dune-project.org/core/dune-grid/-/issues/184#note_135809 This looks like being the same problem that I noted for Paraview on ubuntu. It seems that a bugfix in the xml-parser `expat` broke parsing binary data. Debian sid contains expat 2.6.2 where this is fixed. Ubuntu 23.10 has recently backported a fix to 2.5.0 which broke reading appended data in paraview for me. So the issue reported here may now also effect Ubuntu 23.10. * Bug report for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/expat/+bug/2058415 * Related discussion for arch: https://discourse.paraview.org/t/i-cannot-read-a-vtp-file-i-could-open-yesterday-can-someone-try-to-open-it/13938 * In the debian security tracker for expat one can the the CVEs that * have been fixed in sid but (so far) not in stable and testing. In * Ubuntu the patches for these CVEs have been backported already: * https://security-tracker.debian.org/tracker/source-package/expat Best, Markus
Bug#1001644: [Pkg-sssd-devel] Bug#1001644: libpam-sss: OTP-enabled users do not recieve OTP prompts from pam_sss.so
I like Sam's suggestions. Has a maintainer considered it? -- Markus
Bug#1067002: plymouth: Theme broken if config file is a symlink
Package: plymouth Version: 24.004.60-1+b2 Severity: minor Dear Maintainer, I used to have a symlink from /etc/plymouth/plymouthd.conf to my dotfiles repository, which resulted in a broken theme (a gray screen with three white dots). At some point I realized that the initramfs hook is copying the symlink itself, so I switched to a hardlink which resolved that issue. The problem is in /usr/share/initramfs-tools/hooks/plymouth which uses `cp -dRp` to copy certain files. Could that be changed to `cp -p` perhaps? I noticed that `cp -R` will still create symlinks when used with a single file, but recursion isn't necessary in these cases anyway. I also saw some other hooks explicitly use `cp -L`. Thanks, Markus -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-1-liquorix-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages plymouth depends on: ii init-system-helpers 1.66 ii initramfs-tools 0.142 ii libc62.37-15.1 ii libdrm2 2.4.120-2 ii libplymouth5 24.004.60-1+b2 ii systemd 255.4-1+b1 ii udev 255.4-1+b1 plymouth recommends no packages. Versions of packages plymouth suggests: ii desktop-base 12.0.6+nmu1 pn plymouth-themes -- Configuration Files: /etc/plymouth/plymouthd.conf changed: [Daemon] Theme=moonlight ShowDelay=0 -- no debconf information
Bug#1065913: opm-common: Please drop dependencies on python3-distutils
Hi, the dependency is alread gone version 2023.10+ds-2 and later (unstable). We just need to wait for their migration to testing. Best, Markus
Bug#1064762: Works with vtk9.3 installed in venv via pip (was Re: dune-grid: FTBFS: make[1]: *** [/usr/share/dune/dune-debian.mk:39: override_dh_auto_test] Error 1)
Hi, I did some further tests with the provided test case. If I install vtk (latest version 9.3) with pip in a venve. The script also does not report an error for the relative paths. Tested on stable and in a sid chroot. Best, Markus
Bug#1065914: opm-simulators: Please drop dependencies on python3-distutils
Hi, there is already a version (2023.10+ds-2) uploaded to unstable with the python3-distutils dependency. We just need to for it's migration. Best, Markus
Bug#1064762: dune-grid: FTBFS: make[1]: *** [/usr/share/dune/dune-debian.mk:39: override_dh_auto_test] Error 1
Hi, these tests write out vtk files and read them in using python3-vtk9. If parsing of the file succeeds then the test was successful. How the files are written did not change between Debian stable and Debian sid. I have verified that the files are the same. Attached is a small test case in python3-vtk9-test.tar.gz that mimics the problems. The script test/vtkcheckcomb.py will read the file vtktest-1D-leafview-nonconforming-appendedbase64.vtp using different relative paths with vtkXMLPolyDataReader. On Debian stable all those cases succeed (see log file tests/stable/vtkcheckcomb.log. On Debian sid all of the fail with this error of vtk xml parser: 2024-03-11 14:31:34.098 ( 0.123s) [A51E0740] vtkXMLParser.cxx:375ERR| vtkXMLDataParser (0x1659c80): Error parsing XML in stream at line 27, column 9, byte index 1562: not well-formed (invalid token) 2024-03-11 14:31:34.099 ( 0.123s) [A51E0740] vtkXMLReader.cxx:521ERR| vtkXMLPolyDataReader (0x15f4e90): Error parsing input file. ReadXMLInformation aborting. 2024-03-11 14:31:34.099 ( 0.123s) [A51E0740] vtkExecutive.cxx:752ERR| vtkCompositeDataPipeline (0x1631800): Algorithm vtkXMLPolyDataReader(0x15f4e90) returned failure for request: vtkInformation (0x166e920) Debug: Off Modified Time: 775 Reference Count: 1 Registered Events: (none) Request: REQUEST_INFORMATION ALGORITHM_AFTER_FORWARD: 1 FORWARD_DIRECTION: 0 I have no clue why this is the case. To me it is more likely that the problem is due a change in vtk9. Hence I am reassinging to vtk9 in the hope that the maintainers there have more clues than me. Best, Markus python3-vtk9-test.tar.gz Description: application/gzip
Bug#1060076: alberta: FTBS on ppc64el: Package fixed but Sponsor for uploading needed
Dear all, I was able to fix the FTBFS by backporting two upstream patches. You can find my changes in MR [1]. Note that this also adds the changes for the 64bit time_t transition made in version 3.0.3-1.1 to the repository. As I am not Debian Developer and not maintaining the alberta, Hence I need a sponsor from e.g. the Debian Science team that uploads the fixed package. alberta is marked for removal today. Thanks a lot. Best, Markus [1] https://salsa.debian.org/science-team/alberta/-/merge_requests/4 signature.asc Description: PGP signature
Bug#1064016: adwaita-icon-theme: v46 cursor theme is missing legacy X11 icon names expected by many applications
On Monday, 4 March 2024 at 22:08, Simon McVittie wrote: > If upgrading libmutter-13-0 (and other packages from the same source) > to 45.3-3 fixes this, then you were experiencing #1063640. If not, > we should open a separate bug. Oh yes I was indeed still on 45.3-2, upgrading to 45.3-3 fixes the crash! I still get the default cursor when dragging, but this seems to be by design: - 45.3 branch uses `dnd-none`: https://gitlab.gnome.org/GNOME/mutter/-/blob/45.3/src/backends/meta-cursor-sprite-xcursor.c?ref_type=tags#L75 - main branch now uses `default`: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/meta-cursor-sprite-xcursor.c?ref_type=heads#L75 Thanks, Markus
Bug#1064016: adwaita-icon-theme: v46 cursor theme is missing legacy X11 icon names expected by many applications
Oh no, sorry I meant to say "46~beta-4" in the first sentence. Copied it from the bottom and forgot to change it :)
Bug#1064016: adwaita-icon-theme: v46 cursor theme is missing legacy X11 icon names expected by many applications
Hello there, Not sure if this is the correct bug to report this, but I ran into a gnome-shell crash with adwaita-icon-theme 46~beta-3 when opening the overview (Super key) and trying to grab one of the windows: ``` No cursor theme available, please install a cursor theme Received an X Window System error. This probably reflects a bug in the program. The error was 'BadCursor (invalid Cursor parameter)'. (Details: serial 13601 error_code 6 request_code 95 (core protocol) minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the MUTTER_SYNC environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the mtk_x_error() function.) == Stack trace for context 0x58854fb38590 == #0 58854fbffa08 i resource:///org/gnome/shell/ui/init.js:21 (13c026970bf0 @ 48) ``` Running with MUTTER_SYNC=1 extends the stack trace a bit: ``` == Stack trace for context 0x631cbba61570 == #0 631cbbb28c18 i resource:///org/gnome/shell/ui/dnd.js:390 (21d3a36f80b0 @ 440) #1 631cbbb28b68 i resource:///org/gnome/shell/ui/dnd.js:168 (21d3a36f2c90 @ 235) #2 631cbbb28ad8 i resource:///org/gnome/shell/ui/init.js:21 (21d3a3670bf0 @ 48) ``` So it's trying to use the `DND_IN_DRAG` cursor at [1]. I also noticed now that this cursor is missing in Firefox when e.g. dragging a link, but at least Firefox is polite enough to not crash (it just displays the default cursor). Downgrading to adwaita-icon-theme 45.0-4 resolves this. I still get the crash with 46~beta-3, so I guess it's not related to the "more minimal set of aliases". I should also mention I'm using gnome-shell 45.3-2 from experimental. [1]: https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/96b91ec62c9c8133eb7b0e76e486a7cea6edebdb/js/ui/dnd.js#L390 Thanks and greetings, Markus
Bug#1064561: 1064561 dune-grid: FTBFS on i386: 98% tests passed, 1 tests failed out of 66
Hi,
I did look into this shortly. I must admit that I problems seeing what could
fail in this code.
The code reads the second line of a file using using scanf and checks that the
first number read is larger or equal 2.0 and less than or equal 2.2. Strangely
this works for all the other files read.
excerpt from dune/grid/io/file/gmshreader.hh
void readfile(FILE * file, int cnt, const char * format,
void* t1, void* t2 = 0, void* t3 = 0, void* t4 = 0,
void* t5 = 0, void* t6 = 0, void* t7 = 0, void* t8 = 0,
void* t9 = 0, void* t10 = 0)
{
off_t pos = ftello(file);
int c = fscanf(file, format, t1, t2, t3, t4, t5, t6, t7, t8, t9, t10);
if (c != cnt)
DUNE_THROW(Dune::IOError, "Error parsing " << fileName << " "
"file pos " << pos
<< ": Expected '" << format << "', only read " << c <<
" entries instead of " << cnt << ".");
}
[...]
// open file name, we use C I/O
fileName = f;
FILE* file = fopen(fileName.c_str(),"rb");
if (file==0)
DUNE_THROW(Dune::IOError, "Could not open " << fileName);
//=
// Header: Read vertices into vector
// Check vertices that are needed
//=
number_of_real_vertices = 0;
boundary_element_count = 0;
element_count = 0;
// process header
double version_number;
int file_type, data_size;
readfile(file,1,"%s\n",buf);
if (strcmp(buf,"$MeshFormat")!=0)
DUNE_THROW(Dune::IOError, "expected $MeshFormat in first line");
readfile(file,3,"%lg %d %d\n",_number,_type,_size);
if( (version_number < 2.0) || (version_number > 2.2) )
DUNE_THROW(Dune::IOError, "can only read Gmsh version 2 files");
[...]
File unitcube.sh:
$MeshFormat
2.2 0 8
$EndMeshFormat
$Nodes
...
I will need to reproduce this somehow. Just need to learn how.
Best,
Markus
Bug#1064267: fontconfig 2.15 breaks color emoji
Hey Jeremy, Haha well I was debating if even "important" is warranted, given it's just about fancy emoji in the end. But I guess people do feel passionate about them :) Also didn't know that "serious" prevents migration to testing, will keep that in mind for the future! Thanks, Markus On Sunday, 25 February 2024 at 14:04, Jeremy Bícha wrote: > > > Control: severity -1 serious > > Oh, I wish you had filed this regression as Serious to prevent the > update's migration to Testing. > > Thank you, > Jeremy Bícha
Bug#1064267: fontconfig 2.15 breaks color emoji
Found the upstream bug: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/400 > It seems the font is considered as a bitmap font now (wasn't the case in > 2.14.x) and because of no-bitmap.conf, the emoji font wouldn't load. Removing > this conf file makes the emoji font load fine. I am unsure whether to > consider this as a regression, but for now I will close this issue. After running "dpkg-reconfigure fontconfig-config" and enabling bitmap fonts the color emoji indeed work again. Greetings, Markus
Bug#1064267: fontconfig 2.15 breaks color emoji
Subject: fontconfig 2.15 breaks color emoji Package: fontconfig Version: 2.15.0-1 Severity: important Hello there, After the latest upgrade to 2.15.0 I noticed that color emoji from fonts-noto-color-emoji were broken, looks like matching doesn't work correctly anymore: ``` $ fc-match emoji NotoSans-Regular.ttf: "Noto Sans" "Regular" ``` Downgrading to 2.14.2-6+b1 fixes it: ``` $ fc-match emoji NotoColorEmoji.ttf: "Noto Color Emoji" "Regular" ``` Greetings, Markus -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.4-2-liquorix-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages fontconfig depends on: ii fontconfig-config 2.15.0-1 ii libc6 2.37-15 ii libfontconfig1 2.15.0-1 ii libfreetype6 2.13.2+dfsg-1+b1 fontconfig recommends no packages. fontconfig suggests no packages. -- no debconf information
Bug#1063868: O: xsecurelock -- X11 screen lock utility with the primary goal of security
Package: wnpp Severity: normal
Bug#1052714: firmware-amd-graphics: Missing firmware for AMD Radeon RX 7000 series cards
Seconding the suggestion for more frequent firmware updates to better align with the kernel packages. Maybe these could be provided in experimental/rc-buggy? I had a problem with my RX 7900 XT where it would reboot on resuming from suspend, which was fixed by grabbing the latest amdgpu firmware from the kernel tarball. Greetings, Markus
Bug#1061393: runescape: Runescape launcher won't start because of missing dependencies
Package: runescape Version: 0.8-2 Severity: important X-Debbugs-Cc: schm...@web.de After installing "runescape" (by "sudo apt install runescape") I could start the program "runescape", but it stopped executing at 98%. I could adjust the file "/usr/games/runescape" so that error messages were shown, which revealed a "java.lang.NoClassDefFoundError: java/util/jar/Pack200". The currently installed Java-Runtime is openjdk-17-jre. It appears that the Java-class Pack200 is deprecated since openjdk-11 (see: https://openjdk.org/jeps/336 ) and removed since openjdk-14 (see: https://openjdk.org/jeps/367 ). Therefore the package "runescape" won't work any longer. I don't see a way to fix this bug (other than adding old and deprecated java-classes). What do you think? -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages runescape depends on: ii 7zip [p7zip-full]23.01+dfsg-7 ii default-jre [java10-runtime] 2:1.17-75 ii openjdk-17-jre [java10-runtime] 17.0.10+7-1 ii p7zip-full 16.02+transitional.1 ii wget 1.21.4-1+b1 ii zenity 4.0.1-1 runescape recommends no packages. runescape suggests no packages. -- no debconf information
Bug#1060857: squid: updating to 4.6-1+deb10u9 causes empty responses for some HTTP requests
Hi, Am Dienstag, dem 16.01.2024 um 08:18 +0100 schrieb Lucas Nussbaum: > Hi, > > Adding debian-lts@l.d.o in the email loop, as asked on IRC. > > On 15/01/24 at 21:16 +0100, Lucas Nussbaum wrote: > > On 15/01/24 at 20:31 +0100, Lucas Nussbaum wrote: > > > Package: squid > > > Version: 4.6-1+deb10u9 > > > Severity: important > > > > > > Hi, > > > > > > After updating to 4.6-1+deb10u9, squid returns empty responses for some > > > URLs. > > I also confirmed that the regression is between 4.6-1+deb10u8 and 4.6- > 1+deb10u9 (4.6-1+deb10u8 is OK) Thank you for the report. I believe this is related to the fix for CVE-2023- 46846. I am currently investigating the problem. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1004844: games-finest: Consider adding endless-sky
Am Freitag, dem 12.01.2024 um 03:25 -0500 schrieb Dave Vasilevsky: > Hi again. It looks like endless-sky 0.10.2 has been in testing for awhile, > with no reported bugs. This version is quite new, updated in 2023. What do > you think about adding it to games-finest now? Hi, It's still on my todo list but with a low priority. As long as there are no major issue with endless-sky, it will be part of games-finest when I update src:debian-games again. Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#1060652: mate-control-center: "Raise selected Windows after delay" not working with WINE windows
Package: mate-control-center Version: 1.26.0-2+deb12u1 Severity: normal When you activate "Select windows when the mouse moves over them" there is a delay that you can set (Raise selected windows after XX seconds). I have set the delay to 1 second. The delay works unless the window being raised is a WINE application. In that case, the window is raised immediately, the delay is bypassed. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages mate-control-center depends on: ii caja-common 1.26.1-1 ii desktop-file-utils 0.26-1 ii gsettings-desktop-schemas 43.0-1 ii libaccountsservice0 22.08.8-6 ii libc6 2.36-9+deb12u3 ii libcairo-gobject2 1.16.0-7 ii libcairo2 1.16.0-7 ii libcanberra-gtk3-0 0.30-10 ii libcanberra00.30-10 ii libdconf1 0.40.0-4 ii libfontconfig1 2.14.1-4 ii libfreetype62.12.1+dfsg-5 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-02.74.6-2 ii libglib2.0-bin 2.74.6-2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libmarco-private2 1.26.1-3+deb12u2 ii libmate-desktop-2-171.26.0-2 ii libmate-slab0 1.26.0-2+deb12u1 ii libmate-window-settings11.26.0-2+deb12u1 ii libmatekbd4 1.26.0-1+deb12u1 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpolkit-gobject-1-0 122-3 ii libx11-62:1.8.4-2+deb12u2 ii libxcursor1 1:1.2.1-1 ii libxi6 2:1.8-1+b1 ii libxklavier16 5.4-4 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii libxss1 1:1.2.3-1 ii marco-common1.26.1-3+deb12u2 ii mate-control-center-common 1.26.0-2+deb12u1 ii mate-desktop1.26.0-2 ii mate-icon-theme 1.26.0-1 ii mate-menus 1.26.0-3 ii mate-settings-daemon1.26.0-1 mate-control-center recommends no packages. Versions of packages mate-control-center suggests: pn gconf2 -- no debconf information
Bug#1059545: webext-ublock-origin-firefox: I get YouTube ads when Private Browsing
Hello, > Hi, > Lately I've been getting YouTube ads when I play videos on private windows. > This among other YouTube bugs (slow loading and such) have been fixed for > testing and unstable. If they can be backported it would be great. > > > (can be reproduced on a VM with defaults) My intention was to backport ublock-origin to Bookworm in January 2024. This will be a normal point update as usual, so you have to enable bookworm proposed-updates for early access. I try to update Bullseye as well. Stay tuned and a happy new year 2024. Markus signature.asc Description: This is a digitally signed message part
Bug#1059520: opendkim: Crashes when postfix accesses opendkim.sock
Package: opendkim Version: 2.11.0~beta2-8+deb12u1 Severity: important X-Debbugs-Cc: markusmitsc...@gmail.com Dear Maintainer, when i send an email via postfix from localhost postfix logs the following: warning: milter unix:/run/opendkim/opendkim.sock: can't read SMFIC_EOH reply packet header: Application error when i inspect the opendkim log i see: opendkim.service: Failed with result 'signal'. opendkim.service: Main process exited, code=killed, status=11/SEGV running opendkim from command line with "-vf" gives "segmentation fault" in the moment i send an email. Please let me know if you need something else. Greetings, Markus -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-16-cloud-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opendkim depends on: ii adduser3.134 ii dns-root-data 2023010101 ii init-system-helpers1.65.2 ii libbsd00.11.7-2 ii libc6 2.36-9+deb12u3 ii libdb5.3 5.3.28+dfsg2-1 ii libldap-2.5-0 2.5.13+dfsg-5 ii liblua5.3-05.3.6-2 ii libmemcached11 1.1.4-1 ii libmilter1.0.1 8.17.1.9-2 ii libopendbx11.4.6-16+b1 ii libopendkim11 2.11.0~beta2-8+deb12u1 ii librbl12.11.0~beta2-8+deb12u1 ii libssl33.0.11-1~deb12u2 ii libunbound81.17.1-2+deb12u1 ii libvbr22.11.0~beta2-8+deb12u1 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages opendkim recommends: ii opendkim-tools 2.11.0~beta2-8+deb12u1 opendkim suggests no packages. -- Configuration Files: /etc/opendkim.conf changed: Syslog yes SyslogSuccess yes Canonicalizationrelaxed/simple Modesv OversignHeaders From UserID opendkim UMask 007 Socket local:/run/opendkim/opendkim.sock PidFile /run/opendkim/opendkim.pid TrustAnchorFile /usr/share/dns/root.key InternalHosts refile:/etc/opendkim/trusted ExternalIgnoreList refile:/etc/opendkim/trusted SigningTablerefile:/etc/opendkim/signing.table KeyTable/etc/opendkim/key.table SignatureAlgorithm rsa-sha256 -- no debconf information
Bug#1057940: swirc: FTBFS: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct _win_st’}
Alright, I will do so when I have time, but as soon as possible. Den 2023-12-10 kl. 23:17, skrev Santiago Vila: El 10/12/23 a las 22:09, Markus Uhlin escribió: My guess is that Ncurses is built with '--enable-opaque-curses' and defines NCURSES_OPAQUE=1. I'm currently running stable so I'm not able to reproduce the problem but if you can give me access to a computer where the problem occurs I can investigate it. Hmm, please note that when I say "if you can't reproduce it" it should be understood as "if you can't reproduce it using an unstable chroot". So, you should really use an unstable chroot in your own computer first (you can create it with debootstrap and then use it with schroot). Regarding the bug itself: Here is a very similar one which maybe gives you an idea about how to fix it, as it contains a fix at the end: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057553 Thanks.
Bug#1057940: swirc: FTBFS: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct _win_st’}
My guess is that Ncurses is built with '--enable-opaque-curses' and
defines NCURSES_OPAQUE=1.
I'm currently running stable so I'm not able to reproduce the problem
but if you can give me access to a computer where the problem occurs I
can investigate it.
Den 2023-12-10 kl. 20:18, skrev Santiago Vila:
invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct _win_st’}
Bug#1055147: seahorse-adventures: No keypress recognised
Hi Francesco, Am Sonntag, dem 03.12.2023 um 17:42 +0100 schrieb Francesco Ariis: > Il 03 dicembre 2023 alle 17:14 Markus Koschany ha scritto: > > I spoke too soon. Tested the wrong Debian release. So it appears the > > underlying > > problem is in python3-pygame which changed significantly between Bullseye > > and > > Bookworm but I'm not sure how I can fix this in seahorse-adventures right > > now. > > I managed to get keydown working like this: > - in /usr/share/games/seahorse-adventures/lib/menu.py > - go to line 119 > - substitute > if e.type is USEREVENT and e.action == 'down': > with > if e.type == USEREVENT and e.action == 'down': > - keydown will work again Thanks a lot for the report and your proposed patch. As soon as I'm back home tomorrow, I'll give it a try. Thanks for mentioning the other seahorse- adventures fork. Maybe there are even more improvements. I'll check that too. Best, Markus signature.asc Description: This is a digitally signed message part
Bug#1055147: seahorse-adventures: No keypress recognised
Control: severity -1 grave I spoke too soon. Tested the wrong Debian release. So it appears the underlying problem is in python3-pygame which changed significantly between Bullseye and Bookworm but I'm not sure how I can fix this in seahorse-adventures right now. signature.asc Description: This is a digitally signed message part
Bug#1057047: tomcat10-common: Tomcat 10 helper script doesn't look for temurin based jdk installs
On Tue, 28 Nov 2023 17:59:18 +0100 Joan wrote: > Package: tomcat10-common > Version: 10.1.15-1 > Severity: normal > X-Debbugs-Cc: aseq...@gmail.com > > Dear Maintainer, > > * What led up to the situation? > I am trying to use debian's tomcat 10 with java 21, since it's not present on debian I used the one from > https://adoptium.net/installation/linux/ that has a repository. [...] Hello, we support only OpenJDK and there is even openjdk-21-jre in unstable. For stable releases only one version of openjdk is supported in general, currently OpenJDK 17. signature.asc Description: This is a digitally signed message part
Bug#1057315: tiles: CVE-2023-49735
Am Sonntag, dem 03.12.2023 um 15:10 +0100 schrieb Moritz Muehlenhoff: > > But maybe we can set it as "no-dsa", is it only used as build > > dependency for libspring-java and not sensible outside? > > Spring is already marked as unsupported, so we can simply extend that. +1 This is sensible in this case. signature.asc Description: This is a digitally signed message part
Bug#1055147: seahorse-adventures: No keypress recognised
Control: severity -1 normal On Wed, 01 Nov 2023 09:25:19 +0100 Francesco Ariis wrote: > Package: seahorse-adventures > Version: 1.1+dfsg-6 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: fa...@ariis.it > > Dear Maintainer, > > to replicate: > > 1. Launch `seahorse-adventures` > 2. Now you are in the menu. > 3. Press any direction key > 3. The grey indicator in the menu does not move. It seems that keypresses > are not recognised. The game is thus unplayable. I could not reproduce your problem. The keys work as expected and I can navigate the menu and the game without any problems. signature.asc Description: This is a digitally signed message part
Bug#933264: gradle: Nearly 3-year-old version almost useless
Am Freitag, dem 01.12.2023 um 13:06 +0100 schrieb Matthias Geiger: > > Kotlin is now in debian, is there anything else blocking the update ? As a start I have built Gradle 4.6 from source with almost only system libraries but I hit a wall because there seems to be a bug in our Kotlin version or rather 4.6 requires a different version, so this version still relies on upstream's binary distribution of Kotlin. I will push this in a few days and then let's see how we can proceed from here on. Why still 4.6? Jumping to a newer version like 6.x (which is already superseded by 8.x) requires updates of many different system libraries which in turn requires updates of reverse-dependencies of said libraries and so on. So whenever you change something in Debian's Java eco system you have to be prepared to fix a bunch of other seemingly (un)related stuff as well. More details follow soon. Markus signature.asc Description: This is a digitally signed message part
Bug#1056754: marked as done (bouncycastle: CVE-2023-33202)
Hi tony, Am Donnerstag, dem 30.11.2023 um 21:02 -0800 schrieb tony mancill: > On Thu, Nov 30, 2023 at 09:51:09PM +, Debian Bug Tracking System wrote: > > Subject: Bug#1056754: fixed in bouncycastle 1.77-1 > > > > Source: bouncycastle > > Version: 1.77-1 > > Distribution: unstable > > Changed-By: Markus Koschany > > * New upstream version 1.77. (Closes: #1049356) > > Hi Markus, > > Thank you for your efforts to get BC updated. > > > * Remove backward-compatibility.patch. It is time to fix those issues > > properly in our reverse-dependencies. > > I agree completely. And thank you for filing bugs for the r-deps that > need to be addressed. thanks. Fortunately there is enough time to fix them. I'll try to help fixing them step by step. signature.asc Description: This is a digitally signed message part
Bug#1057171: libitext5-java: FTBFS with bouncycastle 1.77
Source: libitext5-java Version: 5.5.13.3-2 Severity: serious Tags: ftbfs sid User: a...@debian.org Usertags: bouncycastle-1.77 X-Debbugs-Cc: a...@debian.org Dear maintainer, libitext5-java fails to build from source with bouncycastle 1.77. The reason is the removal of long deprecated methods. The (hopefully) relevant error message from the build log. BUILD FAILURE [INFO] [INFO] Total time: 12.832 s [INFO] Finished at: 2023-11-30T13:27:49+01:00 [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler- plugin:3.10.1:compile (default-compile) on project itextpdf: Compilation failure: Compilation failure: [ERROR] /<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja va:[223,95] cannot find symbol [ERROR] symbol: method getObject() [ERROR] location: class org.bouncycastle.asn1.ASN1TaggedObject [ERROR] /<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja va:[246,109] cannot find symbol [ERROR] symbol: method getObject() [ERROR] location: class org.bouncycastle.asn1.ASN1TaggedObject [ERROR] /<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja va:[346,70] cannot find symbol [ERROR] symbol: method getObject() [ERROR] location: variable tg of type org.bouncycastle.asn1.ASN1TaggedObject [ERROR] /<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja va:[350,70] cannot find symbol [ERROR] symbol: method getObject() [ERROR] location: variable tg of type org.bouncycastle.asn1.ASN1TaggedObject [ERROR] /<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja va:[1286,28] cannot find symbol [ERROR] symbol: method getObject() [ERROR] location: variable tag of type org.bouncycastle.asn1.ASN1TaggedObject [ERROR] /<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja va:[1287,48] cannot find symbol [ERROR] symbol: method getObject() [ERROR] location: variable tag of type org.bouncycastle.asn1.ASN1TaggedObject [ERROR] /<>/itext/src/main/java/com/itextpdf/text/pdf/security/Certificate Util.java:[123,67] incompatible types: org.bouncycastle.asn1.ASN1IA5String cannot be converted to org.bouncycastle.asn1.DERIA5String [ERROR] -> [Help 1] [ERROR] signature.asc Description: This is a digitally signed message part
Bug#1057170: ssl-utils-clojure: FTBFS with bouncycastle 1.77
Source: ssl-utils-clojure Version: 3.5.0-2 Severity: serious Tags: ftbfs sid User: a...@debian.org Usertags: bouncycastle-1.77 X-Debbugs-Cc: a...@debian.org Dear maintainer, ssl-utils-clojure fails to build from source with bouncycastle 1.77. The reason is the removal of long deprecated methods. The (hopefully) relevant error message from the build log. lein jar Compiling 2 source files to /<>/target/classes /<>/src/java/com/puppetlabs/ssl_utils/ExtensionsUtils.java:632: error: cannot find symbol return asn1ObjToObj(taggedObj.getObject()); ^ symbol: method getObject() location: variable taggedObj of type ASN1TaggedObject 1 error Compilation of Java sources(lein javac) failed. make[1]: *** [debian/rules:19: override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:11: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 --- - signature.asc Description: This is a digitally signed message part
Bug#1057169: pdftk-java: FTBFS with bouncycastle 1.77
Source: pdftk-java Version: 3.3.3-1 Severity: serious Tags: ftbfs sid User: a...@debian.org Usertags: bouncycastle-1.77 X-Debbugs-Cc: a...@debian.org Dear maintainer, pdftk-java fails to build from source with bouncycastle 1.77. The reason is the removal of long deprecated methods. The (hopefully) relevant error message from the build log. [javac] /<>/java/com/gitlab/pdftk_java/com/lowagie/text/pdf/PdfPKCS7.java: 228: error: cannot find symbol [javac] ASN1Sequence content = (ASN1Sequence)((DERTaggedObject)signedData.getObjectAt(1)).getObject(); [javac] ^ [javac] symbol: method getObject() [javac] location: class DERTaggedObject [javac] /<>/java/com/gitlab/pdftk_java/com/lowagie/text/pdf/PdfPKCS7.java: 261: error: cannot find symbol [javac] DEROctetString rsaDataContent = (DEROctetString)((DERTaggedObject)rsaData.getObjectAt(1)).getObject(); [javac] ^ [javac] symbol: method getObject() [javac] location: class DERTaggedObject [javac] /<>/java/com/gitlab/pdftk_java/com/lowagie/text/pdf/PdfPKCS7.java: 297: error: cannot find symbol [javac] ASN1Sequence sseq = (ASN1Sequence)tagsig.getObject(); [javac] ^ [javac] symbol: method getObject() [javac] location: variable tagsig of type ASN1TaggedObject [javac] /<>/java/com/gitlab/pdftk_ signature.asc Description: This is a digitally signed message part
Bug#1057168: jdeb: FTBFS with bouncycastle 1.77
Source: jdeb Version: 1.9-1 Severity: serious Tags: ftbfs sid User: a...@debian.org Usertags: bouncycastle-1.77 X-Debbugs-Cc: a...@debian.org Dear maintainer, jdeb fails to build from source with bouncycastle 1.77. The reason is the removal of long deprecated methods. The (hopefully) relevant error message from the build log. ERROR] Failures: [ERROR] PGPSignerTestCase.testClearSign:79->Assert.assertEquals:146- >Assert.assertEquals:117 expected:<...[] -END PGP SIGNAT...> but was:<...[Sek] -END PGP SIGNAT...> [INFO] [ERROR] Tests run: 90, Failures: 1, Errors: 0, Skipped: 0 [INFO] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 14.039 s [INFO] Finished at: 2023-11-30T13:32:26+01:00 [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire- plugin:2.22.3:test (default-test) on project jdeb: There are test failures. [ERROR] [ERROR] Please refer to /<>/target/surefire-reports for the individual test results. [ERROR] Please refer to dump files (if any exist) [date].dump, [date]- jvmRun[N].dump and [date].dumpstream. [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException [0m[0mdh_auto_test: error: /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> - Dclassworlds.conf=/etc/maven/m2-debian.conf - Dproperties.file.manual=/<>/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings- debian.xml -Ddebian.dir=/<>/debian - Dmaven.repo.local=/<>/debian/maven-repo --batch-mode test returned exit code 1 make: *** [debian/rules:6: build] Error 25 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 signature.asc Description: This is a digitally signed message part
Bug#1057167: libapache-poi-java: FTBFS with bouncycastle 1.77
Source: libapache-poi-java Version: 4.0.1-4 Severity: serious Tags: ftbfs sid User: a...@debian.org Usertags: bouncycastle-1.77 X-Debbugs-Cc: a...@debian.org Dear maintainer, libapache-poi-java fails to build from source with bouncycastle 1.77. The reason is the removal of long deprecated methods. The (hopefully) relevant error message from the build log. ompile-ooxml: [javac] Compiling 589 source files to /<>/build/ooxml-classes [javac] Ignoring source, target and bootclasspath as release has been set [javac] /<>/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/facets/XAdESXLS ignatureFacet.java:235: error: cannot find symbol [javac] ASN1OctetString keyHashOctetString = (ASN1OctetString)derTaggedObject.getObject(); [javac] ^ [javac] symbol: method getObject() [javac] location: variable derTaggedObject of type DERTaggedObject [javac] /<>/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/facets/XAdESXLS ignatureFacet.java:239: error: cannot find symbol [javac] X500Name name = X500Name.getInstance(derTaggedObject.getObject()); [javac] ^ [javac] symbol: method getObject() [javac] location: variable derTaggedObject of type DERTaggedObject [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: /<>/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/SignaturePart.j ava uses unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 2 errors BUILD FAILED /<>/build.xml:1133: Compile failed; see the compiler error output for details. signature.asc Description: This is a digitally signed message part
Bug#1057166: pgpainless: FTBFS with bouncycastle 1.77
Source: pgpainless Version: 1.3.16-2 Severity: serious Tags: ftbfs sid User: a...@debian.org Usertags: bouncycastle-1.77 X-Debbugs-Cc: a...@debian.org Dear maintainer, pgpainless fails to build from source with bouncycastle 1.77. The reason is the removal of long deprecated methods. The (hopefully) relevant error message from the build log. It seems, in this case, just a test is failing now. Failures (1): JUnit Jupiter:CertifyCertificateTest:testKeyDelegation() MethodSource [className = 'org.pgpainless.key.certification.CertifyCertificateTest', methodName = 'testKeyDelegation', methodParameterTypes = ''] => org.pgpainless.exception.SignatureValidationException: Cannot verify direct-key signature correctness org.pgpainless.signature.consumer.SignatureValidator$17.verify(SignatureValidat or.java:547) org.pgpainless.signature.consumer.SignatureVerifier.verifyDirectKeySignature(Si gnatureVerifier.java:328) org.pgpainless.key.certification.CertifyCertificateTest.testKeyDelegation(Certi fyCertificateTest.java:98) java.base/java.lang.reflect.Method.invoke(Method.java:568) java.base/java.util.ArrayList.forEach(ArrayList.java:1511) [...] Caused by: org.bouncycastle.openpgp.PGPException: signature is not a key binding signature. org.bouncycastle.openpgp.PGPSignature.verifyCertification(Unknown Source) org.pgpainless.signature.consumer.SignatureValidator$17.verify(SignatureValidat or.java:539) [...] Test run finished after 44748 ms [ 240 containers found ] [ 0 containers skipped] [ 240 containers started] [ 0 containers aborted] [ 240 containers successful ] [ 0 containers failed ] [ 732 tests found ] [ 1 tests skipped ] [ 731 tests started ] [ 0 tests aborted ] [ 730 tests successful ] [ 1 tests failed ] signature.asc Description: This is a digitally signed message part
Bug#1057165: libitext-java: FTBFS with bouncycastle 1.77
Source: libitext-java
Version: 2.1.7-14
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org
Dear maintainer,
libitext-java fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.
compile:
[mkdir] Created dir: /<>/build/bin
[javac] /<>/ant/compile.xml:45: warning: 'includeantruntime'
was not set, defaulting to build.sysclasspath=last; set to false for repeatable
builds
[javac] Using javac -source 1.5 is no longer supported, switching to 7
[javac] Using javac -target 1.5 is no longer supported, switching to 7
[javac] Compiling 359 source files to /<>/build/bin
[javac] warning: [options] bootstrap class path not set in conjunction with
-source 7
[javac] warning: [options] source value 7 is obsolete and will be removed
in a future release
[javac] warning: [options] target value 7 is obsolete and will be removed
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use
-Xlint:-options.
[javac]
/<>/core/com/lowagie/text/pdf/MappedRandomAccessFile.java:58:
warning: [removal] AccessController in java.security has been deprecated and
marked for removal
[javac] import java.security.AccessController;
[javac] ^
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:356:
error: cannot find symbol
[javac] if (tag.getObject() instanceof ASN1Sequence) {
[javac]^
[javac] symbol: method getObject()
[javac] location: variable tag of type ASN1TaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:357:
error: cannot find symbol
[javac] seq = (ASN1Sequence)tag.getObject();
[javac]^
[javac] symbol: method getObject()
[javac] location: variable tag of type ASN1TaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:403:
error: cannot find symbol
[javac] ASN1Sequence content =
(ASN1Sequence)((DERTaggedObject)signedData.getObjectAt(1)).getObject();
[javac]
^
[javac] symbol: method getObject()
[javac] location: class DERTaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:435:
error: cannot find symbol
[javac] DEROctetString rsaDataContent =
(DEROctetString)((DERTaggedObject)rsaData.getObjectAt(1)).getObject();
[javac]
^
[javac] symbol: method getObject()
[javac] location: class DERTaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:488:
error: cannot find symbol
[javac] ASN1Sequence seqin =
(ASN1Sequence)tg.getObject();
[javac] ^
[javac] symbol: method getObject()
[javac] location: variable tg of type ASN1TaggedObject
[javac] /<>/core/com/lowagie/text/pdf/FontDetails.java:264:
warning: [removal] Integer(int) in Integer has been deprecated and marked for
removal
[javac] Integer codeKey = new Integer(code);
[javac] ^
[javac]
/<>/core/com/lowagie/text/pdf/TrueTypeFontUnicode.java:144:
warning: [removal] Integer(int) in Integer has been deprecated and marked for
removal
[javac] inverseCmap.put(new
Integer(metrics[0]), code);
[javac] ^
[javac]
/<>/core/com/lowagie/text/pdf/TrueTypeFontUnicode.java:150:
warning: [removal] Integer(int) in Integer has been deprecated and marked for
removal
[javac] return inverseCmap == null ? null : (Integer)
inverseCmap.get(new Integer(code));
[javac]
^
[javac]
/<>/core/com/lowagie/text/pdf/MappedRandomAccessFile.java:203:
warning: [removal] AccessController in java.security has been deprecated and
marked for removal
[javac] Boolean b = (Boolean) AccessController.doPrivileged(new
PrivilegedAction() {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 5 errors
[javac] 9 warnings
signature.asc
Description: This is a digitally signed message part
Bug#1057162: jglobus: FTBFS with bouncycastle 1.77
Source: jglobus Version: 2.1.0-8.1 Severity: serious Tags: ftbfs sid User: a...@debian.org Usertags: bouncycastle-1.77 X-Debbugs-Cc: a...@debian.org Dear maintainer, jglobus fails to build from source with bouncycastle 1.77. The reason is the removal of long deprecated methods. The (hopefully) relevant error message from the build log. [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /<>/ssl-proxies/src/main/java/org/globus/gsi/proxy/ext/ProxyPolicy.java:[63,46] cannot find symbol symbol: method getObject() location: class org.bouncycastle.asn1.DERTaggedObject [INFO] 1 error
Bug#1032164: bouncycastle: inconsistency in debian/rules?
Hi, On Tue, 28 Feb 2023 22:08:12 +0100 Thomas Uhle wrote: > Source: bouncycastle > Version: 1.72-1 > Severity: normal > > Dear maintainers, > > I wonder why in debian/rules the pom files were synchronized with the > ones from Maven having the suffix "-jdk18on" while for building the binary > packages still "ant/jdk15+.xml" is used instead of "ant/jdk18+.xml". Good question. Perhaps the jdk18+ jar files were breaking some reverse- dependencies in the past. The soon to be released 1.77 version of bouncycastle will require updates of several of those reverse-dependencies. As soon as those issues are fixed, we can rebuild everything with jdk18+ again. signature.asc Description: This is a digitally signed message part
Bug#1019488: bouncycastle: incomplete information in the manifest files
This problem still exists in 1.77 (to be released soon). That sounds like a bnd problem. I can find a reference to a bnd.sh script but it is not included in the source distribution. There is also a add_module.sh script. If we can't find a way to automate this build step, we could use jh_manifest which I would prefer over the patch. signature.asc Description: This is a digitally signed message part
Bug#1057077: rabbitmq-server: .erlang.cookie overwritten if 20 uppercase characters
Source: rabbitmq-server
Version: 3.10.8-3
Severity: normal
Dear Maintainer,
The postinst script will overwrite the `/var/lib/rabbitmq/.erlang.cookie`
file if it contains exactly 20 uppercase characters.
```
if grep -q -E '^[A-Z]{20}$' /var/lib/rabbitmq/.erlang.cookie ; then
OLD_UMASK=$(umask)
umask 077; openssl rand -base64 -out /var/lib/rabbitmq/.erlang.cookie 42
umask ${OLD_UMASK}
if [ ""$(ps --no-headers -o comm 1) = "systemd" ] ; then
if systemctl is-active --quiet rabbitmq-server.service ; then
systemctl restart rabbitmq-server.service
fi
fi
fi
```
The rabbitmq-server service failed to start on one of our nodes in our
cluster after the package was upgraded as the nodes in our cluster
happen to share a .erlang.cookie that match this condition.
This is a dangerous approach which the package should not enforce. If
20 uppercase characters is seen as insecure then the package should
instead inform the user of it and not simply overwriting the file.
This is bug report was requested by the Ubuntu package maintainers when
I filed a bug report on their tracker [1] as they use this source
package as their upstream.
[1] https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/2044248
Bug#1055857: transition: opm-common
Hi, Am Thu, Nov 23, 2023 at 09:32:31AM +0100 schrieb Sebastian Ramacher: On 2023-11-12 21:42:20 +0100, Markus Blatt wrote: Dear Debian release team, A new upstream release of OPM is available. To ease migration to testing I am requesting a mini-transition. Uploading to unstable would probably work even without a transition, but I would like to play it safe. This should only affect the OPM source packages opm-common, opm-grid, opm- models, opm-simulators and opm-upscaling. I have already uploaded new versions to experimental that seemed to have built without any issues, see [1]. (please explain about the transition: impacted packages, reason, ... for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) Ben file: title = "libopm-common-2023"; is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm- common-2023.10"; is_good = .depends ~ "libopm-common-2023.10"; is_bad = .depends ~ "libopm-common-2023.04"; libopm-common has a Provides: libopm-common-X, but the shared library included in libopm-common also has a SONAME of libopm-common.X. Why is the packaging not following the common practice of matching the package name with the SONAME? Thanks a lot for noticing. Indeed the library has an SONAME, but as upstream does not care about API changes, one cannot rely on them. Basically the SONAME is changed with every release. Releases happen twice a year in April/October. Hence we have 2022.04, 2022.10, 2023.04, 2023.10, etc. The problem probably is that there is no compatibility between 2023.04 and 2023.10. If we would do intermediate snapshot releases, then those might have slightly incompatibe APIs, too. The reason for the current situation probably is a combination of lack of knowledge on my side and inspiration taken from libdune-common-dev. I now realise that the situation is different here, though. Solving the SONAME issue might require quite some additional work. We would need to start with 2024.0 now and increase the major number with every release. If we do this only in Debian then those numbers would also differ from upstream, which might be a problem. What would your suggestion be? Cheers, Markus
Bug#1052589: Additional information
> > https://salsa.debian.org/java-team/apache-directory-server/-/merge_requests/1 > > The patch looks good to me. Markus, do you have a preference for this > patch over updating to M27? I haven't looked closely at the efforts to > update to M27 aside from the fact that our (other) patches will need to > be ported, and there could be some build adjustments for the dependency > on BouncyCastle. Hi tony and thanks Vladimir for preparing the patch. I only had a brief look at this issue but I am all for applying the patch now rather than wait before someone can upgrade apache-directory-server to a new upstream release. If it works, go for it. :) Cheers, Markus signature.asc Description: This is a digitally signed message part
Bug#975405: libwabt.js => sucess but need policy and help
Hey, Am Montag, dem 13.11.2023 um 09:19 + schrieb Bastien Roucariès: [...] > Apo can I add myself to your package ? Do you care to comaintain with > javascript team ? I assume you are referring to wabt and this bug report [1] ? Do you have a solution for the circular dependency that building libwabt.js would create? In general I would be totally fine if you or the Javascript team would completely take over wabt and binaryen because both of them and emscripten are closely related. See also #1052003; emscripten FTBFS with binaryen from experimental. Personally I only need wabt and binaryen to build WebAssembly code from source for the ublock-origin Firefox/Chromium addon but I'm not really interested in becoming more involved in the Javascript ecosystem. So feel free to take over both packages and remove me as the maintainer. Regards, Markus [1] https://bugs.debian.org/975405 signature.asc Description: This is a digitally signed message part
Bug#1055857: transition: opm-common
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-scie...@lists.debian.org Dear Debian release team, A new upstream release of OPM is available. To ease migration to testing I am requesting a mini-transition. Uploading to unstable would probably work even without a transition, but I would like to play it safe. This should only affect the OPM source packages opm-common, opm-grid, opm- models, opm-simulators and opm-upscaling. I have already uploaded new versions to experimental that seemed to have built without any issues, see [1]. (please explain about the transition: impacted packages, reason, ... for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) Ben file: title = "libopm-common-2023"; is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm- common-2023.10"; is_good = .depends ~ "libopm-common-2023.10"; is_bad = .depends ~ "libopm-common-2023.04"; Thanks a lot. Kind regards, Markus [1] https://qa.debian.org/developer.php?login=markus%40dr-blatt.de
Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl
Control: reassign -1 trapperkeeper-webserver-jetty9-clojure Control: found -1 1.7.0-2+deb10u1 Control: close -1 1.7.0-2+deb10u2 I have just released DLA 3647-1. I believe this problem is fixed in version 1.7.0-2+deb10u2 of trapperkeeper-webserver-jetty9-clojure now. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl
Am Sonntag, dem 05.11.2023 um 20:35 + schrieb Adam D. Barratt: > [...] > After a bit of searching, I happened across a discussion of a similar > change in a different product that mentioned the > SslContextFactory$Server syntax, so gave that a try. The resulting > package is now installed on handel.d.o and seems to work - at least, > it's been running for 45 minutes now (whereas the broken versions > lasted less than 5 minutes) and at least one client has successfully > made a "puppet agent" run in the meantime. > > I've attached a debdiff of the package we're now running, with the > revised patch. Great, thanks for the update. I feared the Java dot syntax couldn't be applied one-to-one to Clojure. I suggest we wait another 24h to confirm it works and if you don't see another regression then I'll release a new update tomorrow. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl
Am Sonntag, dem 05.11.2023 um 16:33 + schrieb Adam D. Barratt: > [...] > Do you have an idea how simple rebuilding the bullseye package on > buster would be? I'm happy to try that in general, but I've not really > looked at the Java ecosystem in Debian much. Sorry, I missed those new or updated dependencies. That complicates the matter a little. We also have to deal with clojure here, a LISP dialect of the Java language with a different build system (leiningen), but if all dependencies were in place a rebuild would be pretty simple. As a last resort I could bundle all those dependencies together with trapperkeeper-* the Java way TM but I hope we can avoid that. The most ideal solution is a patch for the current version in Buster. I have uploaded a new revision to people.debian.org with minimal changes here: https://people.debian.org/~apo/lts/buster/trapperkeeper-webserver-jetty9-clojure/ dget - x https://people.debian.org/~apo/lts/buster/trapperkeeper-webserver-jetty9-clojure/ trapperkeeper-webserver-jetty9-clojure_1.7.0-2+deb10u1.1.dsc should work as expected. I'm attaching the debdiff as well. My solution is to replace the old SslContextFactory class with the new inner SslContextFactory.Server class but I don't know if this change has the desired effect because I couldn't test it. FTR, the already applied 0005-maint-Disable-EndpointIdentification.patch (new in version +deb10u1) is related to the problem. Actually back then it did "fix" the SSL problem and I'm a bit surprised it resurfaced now. There is also a third alternative. I could revert the split change in jetty9. https://github.com/jetty/jetty.project/pull/3480/files#diff-58640db0f8f2cd84b7e653d1c1540913 If the new revision doesn't work for you, please send me your puppetdb config, and I try to figure out a solution myself without the feedback loop delay. Thanks in advance. Regards, Markus diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog --- trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog 2019-09-13 11:00:50.0 +0200 +++ trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog 2023-11-05 18:06:31.0 +0100 @@ -1,3 +1,10 @@ +trapperkeeper-webserver-jetty9-clojure (1.7.0-2+deb10u1.1) buster-security; urgency=medium + + * Non-maintainer upload. + * Replace deprecated class SslContextFactory with SslContextFactory.Server. + + -- Markus Koschany Sun, 05 Nov 2023 18:06:31 +0100 + trapperkeeper-webserver-jetty9-clojure (1.7.0-2+deb10u1) buster; urgency=medium [ Manfred Stock ] diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/0005-maint-Disable-EndpointIdentification.patch trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/0005-maint-Disable-EndpointIdentification.patch --- trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/0005-maint-Disable-EndpointIdentification.patch 2019-09-13 10:54:48.0 +0200 +++ trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/0005-maint-Disable-EndpointIdentification.patch 2023-11-05 18:06:31.0 +0100 @@ -1,4 +1,3 @@ -From 9db4170381e07165078e544340e12b38676c2613 Mon Sep 17 00:00:00 2001 From: Justin Stoller Date: Fri, 24 May 2019 16:10:44 -0700 Subject: [PATCH] (maint) Disable EndpointIdentification @@ -30,10 +29,10 @@ 1 file changed, 1 insertion(+) diff --git a/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj b/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj -index 3a577bb..02e7c7d 100644 +index 99c9885..28cfef7 100644 --- a/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj +++ b/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj -@@ -197,6 +197,7 @@ +@@ -192,6 +192,7 @@ (.setKeyStore (:keystore keystore-config)) (.setKeyStorePassword (:key-password keystore-config)) (.setTrustStore (:truststore keystore-config)) @@ -41,6 +40,3 @@ ;; Need to clear out the default cipher suite exclude list so ;; that Jetty doesn't potentially remove one or more ciphers ;; that we want to be included. --- -2.20.1 - diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series --- trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series 2019-09-13 10:54:48.0 +0200 +++ trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series 2023-11-05 18:06:31.0 +0100 @@ -3,3 +3,4 @@ 0003-TK-369-Add-LifeCycleImplementingRequestLogImpl.patch 0004-Implement-LifeCycle-methods-missing-from-RequestLogI.patch 0005-maint-Disable-EndpointIdentification.patch +SslContextFactory.patch diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/SslContextFactory.patch trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/S
Bug#1055382: trapperkeeper-webserver-jetty9-clojure: end-of-life support for jetty9
Source: trapperkeeper-webserver-jetty9-clojure Version: 4.4.1-5 Severity: normal X-Debbugs-Cc: a...@debian.org Dear maintainer, this is a heads-up to let you know that jetty9 has reached its end-of-life and will not receive official upstream security support anymore. I plan to package a supported jetty version this release cycle which will replace jetty9 eventually. At the moment jetty 11 seems to be the best version because it supports the Jakarta servlet API but this is not finally decided yet. It seems trapperkeeper-webserver-jetty9-clojure is tightly coupled with puppetdb and jetty9 is currently the only supported version. Please prepare for the removal of jetty9 during the trixie release cycle. If this is not feasible then there will be no security support for jetty9 and thus puppetdb anymore. Regards, Markus
Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl
Hello, Am Samstag, dem 04.11.2023 um 17:03 + schrieb Adam D. Barratt: > Source: jetty9 > Version: 9.4.50-4+deb10u1 > Severity: serious > X-Debbugs-Cc: d...@debian.org > > Hi, > > Upgrading libjetty9-java and libjetty9-extra-java to the version from > DLA 3641-1 reliably causes PuppetDB to fail to start, with the > stacktrace shown below. Downgrading resolves the issue. > > I'm not sure which keystore is being referred to, but none of the files > listed in /etc/puppetdb/conf.d/jetty.ini appear to contain more than a > single certificate. thanks for the report. This looks like a bug in trapperkeeper-webserver-jetty9- clojure to me. Upstream commit https://github.com/puppetlabs/trapperkeeper-webserver-jetty9/commit/3ee6a410436c1a236ca33d511c5373c3328054ef appears to address the problem. The version in Buster lacks the InternalSslContextFactory class though. Instead the deprecated SslContextFactory class is referenced in jetty9_config.clj and jetty9_core.clj. My first idea is to change SslContextFactory occurrences to SslContextFactory.Server. Backporting the version of trapperkeeper-webserver-jetty9-clojure from Bullseye to Buster is the second one. AFAICS puppetdb and puppetserver are the only consumers. Could you install the version of trapperkeeper-webserver-jetty9-clojure from Bullseye and reinstall the jetty9 security update and report back if this solves your problem? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#840955: Status of ITP/RFP courier-zdkimfilter
Hello Helge, On 11/1/23 10:18, Helge Kreutzmann wrote: I haven't done anything besides doing a testbuild. Before proceeding further I wanted to inquire about the status of your work on this package, so I don't waste time redoing Debian integration. thanks for reaching out. Unfortunately, I can only tell you that I plan to abandon packaging of courier altogether. It's been a struggle for me to keep up the community work recently and many people were far less than appreciative. Noticing that upstream now runs their own packaging convinced me it's not worth for me to keep maintaining this for Debian proper. Sorry for the rather bad news. Markus
Bug#1054122: bookworm-pu: package axis/1.4-28
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
[ Reason ]
Fixing CVE-2023-40743: Axis allows potentially dangerous lookup
mechanisms which may lead to DoS, SSRF or even RCE.
[ Tests ]
The fix is trivial. If the name of the JNDI service contains a certain
string then do nothing. That filters out unsupported protocols
effectively.
[ Risks ]
Axis in Debian is mainly used to build other software packages and
serves no other purpose. It is very unlikely that it is used in third
party applications outside of Debian but better safe than sorry.
[ 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 (old)stable
[x] the issue is verified as fixed in unstable
Regards,
Markus
diff -Nru axis-1.4/debian/changelog axis-1.4/debian/changelog
--- axis-1.4/debian/changelog 2018-12-03 08:25:51.0 +0100
+++ axis-1.4/debian/changelog 2023-10-17 14:05:20.0 +0200
@@ -1,3 +1,15 @@
+axis (1.4-28+deb12u1) bookworm; urgency=medium
+
+ * Team upload.
+ * Fix CVE-2023-40743:
+When integrating Apache Axis 1.x in an application, it may not have been
+obvious that looking up a service through "ServiceFactory.getService"
+allows potentially dangerous lookup mechanisms such as LDAP. When passing
+untrusted input to this API method, this could expose the application to
+DoS, SSRF and even attacks leading to RCE. (Closes: #1051288)
+
+ -- Markus Koschany Tue, 17 Oct 2023 14:05:20 +0200
+
axis (1.4-28) unstable; urgency=medium
* Fixed the build failure with Java 11 (Closes: #911187)
diff -Nru axis-1.4/debian/patches/CVE-2023-40743.patch
axis-1.4/debian/patches/CVE-2023-40743.patch
--- axis-1.4/debian/patches/CVE-2023-40743.patch1970-01-01
01:00:00.0 +0100
+++ axis-1.4/debian/patches/CVE-2023-40743.patch2023-10-17
14:05:20.0 +0200
@@ -0,0 +1,32 @@
+From: Markus Koschany
+Date: Tue, 17 Oct 2023 00:46:49 +0200
+Subject: CVE-2023-40743
+
+Origin:
https://github.com/apache/axis-axis1-java/commit/7e66753427466590d6def0125e448d2791723210
+---
+ src/org/apache/axis/client/ServiceFactory.java | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/src/org/apache/axis/client/ServiceFactory.java
b/src/org/apache/axis/client/ServiceFactory.java
+index 33054a5..73e89ee 100644
+--- a/src/org/apache/axis/client/ServiceFactory.java
b/src/org/apache/axis/client/ServiceFactory.java
+@@ -106,6 +106,10 @@ public class ServiceFactory extends
javax.xml.rpc.ServiceFactory
+
+ if (context != null) {
+ String name = (String)environment.get("jndiName");
++
++ if(name!=null && (name.toUpperCase().indexOf("LDAP")!=-1 ||
name.toUpperCase().indexOf("RMI")!=-1 || name.toUpperCase().indexOf("JMS")!=-1
|| name.toUpperCase().indexOf("JMX")!=-1) ||
name.toUpperCase().indexOf("JRMP")!=-1 ||
name.toUpperCase().indexOf("JAVA")!=-1 ||
name.toUpperCase().indexOf("DNS")!=-1) {
++ return null;
++}
+ if (name == null) {
+ name = "axisServiceName";
+ }
+@@ -120,6 +124,7 @@ public class ServiceFactory extends
javax.xml.rpc.ServiceFactory
+ context.bind(name, service);
+ } catch (NamingException e1) {
+ // !!! Couldn't do it, what should we do here?
++ return null;
+ }
+ }
+ } else {
diff -Nru axis-1.4/debian/patches/series axis-1.4/debian/patches/series
--- axis-1.4/debian/patches/series 2018-12-03 00:33:50.0 +0100
+++ axis-1.4/debian/patches/series 2023-10-17 14:05:20.0 +0200
@@ -8,3 +8,4 @@
java9-compatibility.patch
java11-compatibility.patch
CVE-2018-8032.patch
+CVE-2023-40743.patch
Bug#1054121: bullseye-pu: package axis/1.4-28
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
[ Reason ]
Fixing CVE-2023-40743: Axis allows potentially dangerous lookup
mechanisms which may lead to DoS, SSRF or even RCE.
[ Tests ]
The fix is trivial. If the name of the JNDI service contains a certain
string then do nothing. That filters out unsupported protocols
effectively.
[ Risks ]
Axis in Debian is mainly used to build other software packages and
serves no other purpose. It is very unlikely that it is used in third
party applications outside of Debian but better safe than sorry.
[ 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 (old)stable
[x] the issue is verified as fixed in unstable
Regards,
Markus
diff -Nru axis-1.4/debian/changelog axis-1.4/debian/changelog
--- axis-1.4/debian/changelog 2018-12-03 08:25:51.0 +0100
+++ axis-1.4/debian/changelog 2023-10-17 14:05:20.0 +0200
@@ -1,3 +1,15 @@
+axis (1.4-28+deb11u1) bullseye; urgency=medium
+
+ * Team upload.
+ * Fix CVE-2023-40743:
+When integrating Apache Axis 1.x in an application, it may not have been
+obvious that looking up a service through "ServiceFactory.getService"
+allows potentially dangerous lookup mechanisms such as LDAP. When passing
+untrusted input to this API method, this could expose the application to
+DoS, SSRF and even attacks leading to RCE. (Closes: #1051288)
+
+ -- Markus Koschany Tue, 17 Oct 2023 14:05:20 +0200
+
axis (1.4-28) unstable; urgency=medium
* Fixed the build failure with Java 11 (Closes: #911187)
diff -Nru axis-1.4/debian/patches/CVE-2023-40743.patch
axis-1.4/debian/patches/CVE-2023-40743.patch
--- axis-1.4/debian/patches/CVE-2023-40743.patch1970-01-01
01:00:00.0 +0100
+++ axis-1.4/debian/patches/CVE-2023-40743.patch2023-10-17
14:05:20.0 +0200
@@ -0,0 +1,32 @@
+From: Markus Koschany
+Date: Tue, 17 Oct 2023 00:46:49 +0200
+Subject: CVE-2023-40743
+
+Origin:
https://github.com/apache/axis-axis1-java/commit/7e66753427466590d6def0125e448d2791723210
+---
+ src/org/apache/axis/client/ServiceFactory.java | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/src/org/apache/axis/client/ServiceFactory.java
b/src/org/apache/axis/client/ServiceFactory.java
+index 33054a5..73e89ee 100644
+--- a/src/org/apache/axis/client/ServiceFactory.java
b/src/org/apache/axis/client/ServiceFactory.java
+@@ -106,6 +106,10 @@ public class ServiceFactory extends
javax.xml.rpc.ServiceFactory
+
+ if (context != null) {
+ String name = (String)environment.get("jndiName");
++
++ if(name!=null && (name.toUpperCase().indexOf("LDAP")!=-1 ||
name.toUpperCase().indexOf("RMI")!=-1 || name.toUpperCase().indexOf("JMS")!=-1
|| name.toUpperCase().indexOf("JMX")!=-1) ||
name.toUpperCase().indexOf("JRMP")!=-1 ||
name.toUpperCase().indexOf("JAVA")!=-1 ||
name.toUpperCase().indexOf("DNS")!=-1) {
++ return null;
++}
+ if (name == null) {
+ name = "axisServiceName";
+ }
+@@ -120,6 +124,7 @@ public class ServiceFactory extends
javax.xml.rpc.ServiceFactory
+ context.bind(name, service);
+ } catch (NamingException e1) {
+ // !!! Couldn't do it, what should we do here?
++ return null;
+ }
+ }
+ } else {
diff -Nru axis-1.4/debian/patches/series axis-1.4/debian/patches/series
--- axis-1.4/debian/patches/series 2018-12-03 00:33:50.0 +0100
+++ axis-1.4/debian/patches/series 2023-10-17 14:05:20.0 +0200
@@ -8,3 +8,4 @@
java9-compatibility.patch
java11-compatibility.patch
CVE-2018-8032.patch
+CVE-2023-40743.patch
Bug#1053820: fixed in tomcat9 9.0.43-2~deb11u8
Am Dienstag, dem 17.10.2023 um 08:00 +1100 schrieb Sam Lander: > Hi Emmanuel > Last night, I re-enabled HTTP2 with the new (9.0.43-2~deb11u8) build. > Unfortunately, it did not fix my problem. > I am going to rummage with tcpdump and a purpose-installed debian VM to > investigate further. > Hopefully I can either track the problem down myself (not very likely), or at > least offer you a better quality bug report. > Hello Sam, there was another issue that we only found today. HTTP2 should work as expected in version 9.0.43-2~deb11u9 again. It will be released shortly. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1053535: Add support for timestamps with nanoseconds [patch]
Hello, > i'm not at all convinced that this is a useful change, in particular > in a backup/restore tool. A restore tool should, as its name says, restore the backup as most pristine as possible. Currently dump/restore (on linux) restores timestamps only with seconds, dropping micro- or nanoseconds. > please provide more information as to what benefits this change is > expected to provide, For more than a decade linux kernels and ext2/3/4 filesystems support timestamps with nanoseconds. Most userland utilities have been updated to use it. dump/restore is overdue. It is a severe deficit loosing a part of time information when restoring a backup. I believe nowadays most expect that a backup tool uses all facilities the underlying system supports. > and how those benefits are supposed to outweight > the massive downside of complete incompatibility with existing backups. Incompatibility with existing backups is an issue only, if backups are archived. Usually backups are overwritten regularly. (In my case every two months.) In order to prevent a mismatch a version information at the beginng of a dumpfile (or tape) would be useful. I did not manage to find the code locations where dump begins to write resp. where restore begins to read. I have found restore contains some code to convert "old headers". I could not figure out, what this means. The code for opening and reading a dumpfile is rather complicated and not well documented. Please note the patch does not introduce a "complete incompatibility". I did some tests with mixed combinations with old/new dumps and old/new restores. Directories and files where restored correctly but with erroneous timestamps. Please note there already is a mismatch between sizeof(dinode) and sizeof(ext2_inode) before applying the patch. assert(sizeof(dinode_old) <= sizeof(ext2_inode)) failes. See compat/include/bsdcompat.h and dump/traverse.c. I have sent my patch in in order to share it with the community. May be someone else picks it up and adds version information to the dumpfile. Markus
Bug#1053820: libtomcat9-java: ERR_HTTP2_PROTOCOL_ERROR in browsers after upgrade 9.0.43-2~deb11u7 over u6
Hello and thanks for the report, I am currently looking into some test failures caused by the recent changes to Tomcat's HTTP2 stack. The following tests fail for Tomcat9 now. Your issue might be related. If we can find out more about the problem, we will address it in a future update as soon as possible. [concat] TEST-org.apache.coyote.http2.TestAsync.NIO.txt [concat] TEST-org.apache.coyote.http2.TestAsync.NIO2.txt [concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_1.NIO.txt [concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_1.NIO2.txt [concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_2.NIO.txt [concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_2.NIO2.txt [concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_4.NIO.txt [concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_4.NIO2.txt [concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_5.NIO.txt [concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_5.NIO2.txt [concat] TEST-org.apache.coyote.http2.TestHttp2Timeouts.NIO.txt [concat] TEST-org.apache.coyote.http2.TestHttp2Timeouts.NIO2.txt Markus signature.asc Description: This is a digitally signed message part
Bug#1053713: webkit2gtk: Build with ENABLE_PDFJS=OFF?
Source: webkit2gtk Version: 2.40.3-2~deb12u1 Severity: wishlist Dear Maintainer, Recent webkits force PDF rendering in the browser using pdf.js. To me, this is a pain for several reasons, including pdf.js not having my usual PDF viewer's key bindings, and PDF rendering being entirely broken on sites I have disabled javascript for (i.e., almost all of them). Regrettably, as far as I can tell, at this point there is no way to turn off pdf.js at runtime. I suspect the sort of person that is running webkit-based browsers will typically have configured some PDF reader they like as well and will hence likely be about as annoyed if their browser ignores that choice as I am. Given that, the lack of a runtime switch, and the fact that building a webkit package takes the better part of a day on my box: Any chance you could build with ENABLE_PDFJS=OFF at least until upstream fiddles in a runtime switch? Thanks, Markus -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 6.1.38 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init)
Bug#1053552: gavodachs2-server: Error while setting up with postgresql 16
On Fri, Oct 06, 2023 at 09:56:41AM +0200, Ole Streicher wrote: > 108s alter role untrusted set extra_float_digits=3 > 108s > 108s The database engine reported: > 108s > 108s ERROR: permission denied to alter role > 108s DETAIL: Only roles with the CREATEROLE attribute and the ADMIN option > 108s on role "untrusted" may alter this role. > > I don't think that has anything to do with the astropy update. This > seems to be connected to Postgresql version (16.0-2); a similar install > (with Postgresql 15.4-3) succeeded. Oh bother. Yeah, that's unrelated to astropy and absolutely related to increasingly tight rules in postgres. I'll think about a workaround (to restore this workaround) on Monday. -- Markus
Bug#1053461: bookworm-pu: package openrefine/3.6.2-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
[ Reason ]
Fixing CVE-2023-41886 and CVE-2023-41887.
OpenRefine is a powerful free, open source tool for working with messy
data. Prior to this version, a remote code execution vulnerability
allows any unauthenticated user to execute code on the server.
[ Tests ]
I have verified that the new test case works as expected.
[ Risks ]
Low, leaf package, all tests work as expected.
[ 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 (old)stable
[x] the issue is verified as fixed in unstable
[ Other info ]
Please note that I have previously uploaded another bookworm-pu,
#1051429, to fix CVE-2023-37476. This update addresses the new CVE
mentioned in this bug report. CVE-2023-37476 has been fixed with
3.6.2-2+deb12u1 already.
diff --git a/debian/changelog b/debian/changelog
index 16033d8..37acbbf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+openrefine (3.6.2-2+deb12u2) bookworm; urgency=medium
+
+ * Fix CVE-2023-41887 and CVE-2023-41886:
+OpenRefine is a powerful free, open source tool for working with messy
+data. Prior to this version, a remote code execution vulnerability allows
+any unauthenticated user to execute code on the server.
+
+ -- Markus Koschany Wed, 04 Oct 2023 15:02:45 +0200
+
openrefine (3.6.2-2+deb12u1) bookworm; urgency=medium
* Fix CVE-2023-37476:
diff --git a/debian/patches/CVE-2023-41887-and-CVE-2023-41886.patch
b/debian/patches/CVE-2023-41887-and-CVE-2023-41886.patch
new file mode 100644
index 000..274b758
--- /dev/null
+++ b/debian/patches/CVE-2023-41887-and-CVE-2023-41886.patch
@@ -0,0 +1,183 @@
+From: Markus Koschany
+Date: Wed, 4 Oct 2023 14:39:55 +0200
+Subject: CVE-2023-41887 and CVE-2023-41886
+
+Origin:
https://github.com/OpenRefine/OpenRefine/commit/693fde606d4b5b78b16391c29d110389eb605511
+---
+ .../extension/database/DatabaseConfiguration.java | 16
+ .../database/mariadb/MariaDBConnectionManager.java | 12 +---
+ .../database/mysql/MySQLConnectionManager.java | 11 +--
+ .../database/pgsql/PgSQLConnectionManager.java | 11 +--
+ .../database/sqlite/SQLiteConnectionManager.java| 9 -
+ .../database/DatabaseConfigurationTest.java | 21 +
+ 6 files changed, 48 insertions(+), 32 deletions(-)
+ create mode 100644
extensions/database/tests/src/com/google/refine/extension/database/DatabaseConfigurationTest.java
+
+diff --git
a/extensions/database/src/com/google/refine/extension/database/DatabaseConfiguration.java
b/extensions/database/src/com/google/refine/extension/database/DatabaseConfiguration.java
+index 47dad7f..3f0dd57 100644
+---
a/extensions/database/src/com/google/refine/extension/database/DatabaseConfiguration.java
b/extensions/database/src/com/google/refine/extension/database/DatabaseConfiguration.java
+@@ -29,6 +29,9 @@
+ package com.google.refine.extension.database;
+
+
++import java.net.URI;
++import java.net.URISyntaxException;
++
+ public class DatabaseConfiguration {
+
+ private String connectionName;
+@@ -128,4 +131,17 @@ public class DatabaseConfiguration {
+
+
+
++public URI toURI() {
++try {
++return new URI(
++"jdbc:" + databaseType.toLowerCase(),
++databaseHost + ((databasePort == 0) ? "" : (":" +
databasePort)),
++"/" + databaseName,
++useSSL ? "useSSL=true" : null,
++null
++);
++} catch (URISyntaxException e) {
++throw new IllegalArgumentException(e);
++}
++}
+ }
+diff --git
a/extensions/database/src/com/google/refine/extension/database/mariadb/MariaDBConnectionManager.java
b/extensions/database/src/com/google/refine/extension/database/mariadb/MariaDBConnectionManager.java
+index 4af014a..04c7dc8 100644
+---
a/extensions/database/src/com/google/refine/extension/database/mariadb/MariaDBConnectionManager.java
b/extensions/database/src/com/google/refine/extension/database/mariadb/MariaDBConnectionManager.java
+@@ -139,7 +139,7 @@ public class MariaDBConnectionManager {
+
+ Class.forName(type.getClassPath());
+ DriverManager.setLoginTimeout(10);
+-String dbURL = getDatabaseUrl(databaseConfiguration);
++String dbURL = databaseConfiguration.toURI().toString();
+ connection = DriverManager.getConnection(dbURL,
databaseConfiguration.getDatabaseUser(),
+ databaseConfiguration.getDatabasePassword());
+
+@@ -173,14 +173,4 @@ public class MariaDBConnectionManager {
+ }
+
+ }
+-
+-
+-
+-private static St
Bug#1052575: jss: CVE-2022-4132
Package: jss X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for jss. CVE-2022-4132[0]: Tomcat: Memory leak in JSS If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-4132 https://www.cve.org/CVERecord?id=CVE-2022-4132 Please adjust the affected versions in the BTS as needed. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1052572: hoteldruid: CVE-2023-43371 CVE-2023-43373 CVE-2023-43374 CVE-2023-43375 CVE-2023-43376 CVE-2023-43377
Package: hoteldruid X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for hoteldruid. CVE-2023-43371[0]: | Hoteldruid v3.0.5 was discovered to contain a SQL injection | vulnerability via the numcaselle parameter at | /hoteldruid/creaprezzi.php. CVE-2023-43373[1]: | Hoteldruid v3.0.5 was discovered to contain a SQL injection | vulnerability via the n_utente_agg parameter at | /hoteldruid/interconnessioni.php. CVE-2023-43374[2]: | Hoteldruid v3.0.5 was discovered to contain a SQL injection | vulnerability via the id_utente_log parameter at | /hoteldruid/personalizza.php. CVE-2023-43375[3]: | Hoteldruid v3.0.5 was discovered to contain multiple SQL injection | vulnerabilities at /hoteldruid/clienti.php via the annonascita, | annoscaddoc, giornonascita, giornoscaddoc, lingua_cli, mesenascita, | and mesescaddoc parameters. CVE-2023-43376[4]: | A cross-site scripting (XSS) vulnerability in | /hoteldruid/clienti.php of Hoteldruid v3.0.5 allows attackers to | execute arbitrary web scripts or HTML via a crafted payload injected | into the nometipotariffa1 parameter. CVE-2023-43377[5]: | A cross-site scripting (XSS) vulnerability in | /hoteldruid/visualizza_contratto.php of Hoteldruid v3.0.5 allows | attackers to execute arbitrary web scripts or HTML via a crafted | payload injected into the destinatario_email1 parameter. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-43371 https://www.cve.org/CVERecord?id=CVE-2023-43371 [1] https://security-tracker.debian.org/tracker/CVE-2023-43373 https://www.cve.org/CVERecord?id=CVE-2023-43373 [2] https://security-tracker.debian.org/tracker/CVE-2023-43374 https://www.cve.org/CVERecord?id=CVE-2023-43374 [3] https://security-tracker.debian.org/tracker/CVE-2023-43375 https://www.cve.org/CVERecord?id=CVE-2023-43375 [4] https://security-tracker.debian.org/tracker/CVE-2023-43376 https://www.cve.org/CVERecord?id=CVE-2023-43376 [5] https://security-tracker.debian.org/tracker/CVE-2023-43377 https://www.cve.org/CVERecord?id=CVE-2023-43377 Please adjust the affected versions in the BTS as needed. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1052553: bookworm-pu: package libapache-mod-jk/1:1.2.48-2
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
[ Reason ]
Fixing CVE-2023-41081 in Bookworm.
Unintended exposure of the status worker and/or bypass security constraints
configured in httpd by using implicit mapping.
[ Tests ]
Implicit mapping no longer works with this update and users must
explicitly configure it. Otherwise an error message is logged now
which means the update works as intended.
[ Risks ]
Users who unintentionally relied on the implicit mapping functionality
will have to update their configuration but this is intended and
needed to avoid the bypass of other security constraints.
[ 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 (old)stable
[x] the issue is verified as fixed in unstable
Regards,
Markus
diff -Nru libapache-mod-jk-1.2.48/debian/changelog
libapache-mod-jk-1.2.48/debian/changelog
--- libapache-mod-jk-1.2.48/debian/changelog2023-02-18 19:17:18.0
+0100
+++ libapache-mod-jk-1.2.48/debian/changelog2023-09-24 16:40:59.0
+0200
@@ -1,3 +1,20 @@
+libapache-mod-jk (1:1.2.48-2+deb12u1) bookworm; urgency=high
+
+ * Fix CVE-2023-41081:
+The mod_jk component of Apache Tomcat Connectors, an Apache 2 module to
+forward requests from Apache to Tomcat, in some circumstances, such as when
+a configuration included "JkOptions +ForwardDirectories" but the
+configuration did not provide explicit mounts for all possible proxied
+requests, mod_jk would use an implicit mapping and map the request to the
+first defined worker. Such an implicit mapping could result in the
+unintended exposure of the status worker and/or bypass security constraints
+configured in httpd. As of this security update, the implicit mapping
+functionality has been removed and all mappings must now be via explicit
+configuration. This issue affects Apache Tomcat Connectors (mod_jk only).
+(Closes: #1051956)
+
+ -- Markus Koschany Sun, 24 Sep 2023 16:40:59 +0200
+
libapache-mod-jk (1:1.2.48-2) unstable; urgency=medium
* Declare compliance with Debian Policy 4.6.2.
diff -Nru libapache-mod-jk-1.2.48/debian/patches/CVE-2023-41081.patch
libapache-mod-jk-1.2.48/debian/patches/CVE-2023-41081.patch
--- libapache-mod-jk-1.2.48/debian/patches/CVE-2023-41081.patch 1970-01-01
01:00:00.0 +0100
+++ libapache-mod-jk-1.2.48/debian/patches/CVE-2023-41081.patch 2023-09-24
16:40:59.0 +0200
@@ -0,0 +1,47 @@
+From: Markus Koschany
+Date: Sun, 24 Sep 2023 16:39:43 +0200
+Subject: CVE-2023-41081
+
+Bug-Debian: https://bugs.debian.org/1051956
+Origin:
https://github.com/apache/tomcat-connectors/commit/0095b6cb84f41313ee4c0364b49c766168790792
+---
+ native/apache-2.0/mod_jk.c | 19 ---
+ 1 file changed, 19 deletions(-)
+
+diff --git a/native/apache-2.0/mod_jk.c b/native/apache-2.0/mod_jk.c
+index b755116..d9345d7 100644
+--- a/native/apache-2.0/mod_jk.c
b/native/apache-2.0/mod_jk.c
+@@ -2767,17 +2767,6 @@ static int jk_handler(request_rec * r)
+ rconf->rule_extensions = e;
+ }
+ }
+-else if (worker_env.num_of_workers == 1) {
+- /** We have a single worker ( the common case ).
+- ( lb is a bit special, it should count as a single worker but
+- I'm not sure how ). We also have a manual config directive that
+- explicitly give control to us. */
+-worker_name = worker_env.worker_list[0];
+-if (JK_IS_DEBUG_LEVEL(xconf->log))
+-jk_log(xconf->log, JK_LOG_DEBUG,
+- "Single worker (%s) configuration for %s",
+- worker_name, r->uri);
+-}
+ else {
+ if (!xconf->uw_map) {
+ if (JK_IS_DEBUG_LEVEL(xconf->log))
+@@ -2804,14 +2793,6 @@ static int jk_handler(request_rec * r)
+ r->uri = clean_uri;
+ }
+ }
+-
+-if (worker_name == NULL && worker_env.num_of_workers) {
+-worker_name = worker_env.worker_list[0];
+-if (JK_IS_DEBUG_LEVEL(xconf->log))
+-jk_log(xconf->log, JK_LOG_DEBUG,
+- "Using first worker (%s) from %d workers for %s",
+- worker_name, worker_env.num_of_workers, r->uri);
+-}
+ }
+ if (worker_name)
+ apr_table_setn(r->notes, JK_NOTE_WORKER_NAME, worker_name);
diff -Nru libapache-mod-jk-1.2.48/debian/patches/series
libapache-mod-jk-1.2.48/debian/patches/series
--- libapache-mod-jk-1.2.48/debian/patches/series 2023-02-18
19:17:18.0 +0100
+++ libapache-mod-jk-1.2.48/debian/patches/series 2023-09-24
16:40:59.0
Bug#1052552: bullseye-pu: package libapache-mod-jk/1:1.2.48-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
[ Reason ]
Fixing CVE-2023-41081 in Bullseye.
Unintended exposure of the status worker and/or bypass security constraints
configured in httpd by using implicit mapping.
[ Tests ]
Implicit mapping no longer works with this update and users must
explicitly configure it. Otherwise an error message is logged now
which means the update works as intended.
[ Risks ]
Users who unintentionally relied on the implicit mapping functionality
will have to update their configuration but this is intended and
needed to avoid the bypass of other security constraints.
[ 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 (old)stable
[x] the issue is verified as fixed in unstable
Regards,
Markus
diff -Nru libapache-mod-jk-1.2.48/debian/changelog
libapache-mod-jk-1.2.48/debian/changelog
--- libapache-mod-jk-1.2.48/debian/changelog2020-06-04 21:42:29.0
+0200
+++ libapache-mod-jk-1.2.48/debian/changelog2023-09-24 17:09:51.0
+0200
@@ -1,3 +1,20 @@
+libapache-mod-jk (1:1.2.48-1+deb11u1) bullseye; urgency=high
+
+ * Fix CVE-2023-41081:
+The mod_jk component of Apache Tomcat Connectors, an Apache 2 module to
+forward requests from Apache to Tomcat, in some circumstances, such as when
+a configuration included "JkOptions +ForwardDirectories" but the
+configuration did not provide explicit mounts for all possible proxied
+requests, mod_jk would use an implicit mapping and map the request to the
+first defined worker. Such an implicit mapping could result in the
+unintended exposure of the status worker and/or bypass security constraints
+configured in httpd. As of this security update, the implicit mapping
+functionality has been removed and all mappings must now be via explicit
+configuration. This issue affects Apache Tomcat Connectors (mod_jk only).
+(Closes: #1051956)
+
+ -- Markus Koschany Sun, 24 Sep 2023 17:09:51 +0200
+
libapache-mod-jk (1:1.2.48-1) unstable; urgency=medium
* New upstream version 1.2.48.
diff -Nru libapache-mod-jk-1.2.48/debian/patches/CVE-2023-41081.patch
libapache-mod-jk-1.2.48/debian/patches/CVE-2023-41081.patch
--- libapache-mod-jk-1.2.48/debian/patches/CVE-2023-41081.patch 1970-01-01
01:00:00.0 +0100
+++ libapache-mod-jk-1.2.48/debian/patches/CVE-2023-41081.patch 2023-09-24
17:09:51.0 +0200
@@ -0,0 +1,47 @@
+From: Markus Koschany
+Date: Sun, 24 Sep 2023 16:39:43 +0200
+Subject: CVE-2023-41081
+
+Bug-Debian: https://bugs.debian.org/1051956
+Origin:
https://github.com/apache/tomcat-connectors/commit/0095b6cb84f41313ee4c0364b49c766168790792
+---
+ native/apache-2.0/mod_jk.c | 19 ---
+ 1 file changed, 19 deletions(-)
+
+diff --git a/native/apache-2.0/mod_jk.c b/native/apache-2.0/mod_jk.c
+index b755116..d9345d7 100644
+--- a/native/apache-2.0/mod_jk.c
b/native/apache-2.0/mod_jk.c
+@@ -2767,17 +2767,6 @@ static int jk_handler(request_rec * r)
+ rconf->rule_extensions = e;
+ }
+ }
+-else if (worker_env.num_of_workers == 1) {
+- /** We have a single worker ( the common case ).
+- ( lb is a bit special, it should count as a single worker but
+- I'm not sure how ). We also have a manual config directive that
+- explicitly give control to us. */
+-worker_name = worker_env.worker_list[0];
+-if (JK_IS_DEBUG_LEVEL(xconf->log))
+-jk_log(xconf->log, JK_LOG_DEBUG,
+- "Single worker (%s) configuration for %s",
+- worker_name, r->uri);
+-}
+ else {
+ if (!xconf->uw_map) {
+ if (JK_IS_DEBUG_LEVEL(xconf->log))
+@@ -2804,14 +2793,6 @@ static int jk_handler(request_rec * r)
+ r->uri = clean_uri;
+ }
+ }
+-
+-if (worker_name == NULL && worker_env.num_of_workers) {
+-worker_name = worker_env.worker_list[0];
+-if (JK_IS_DEBUG_LEVEL(xconf->log))
+-jk_log(xconf->log, JK_LOG_DEBUG,
+- "Using first worker (%s) from %d workers for %s",
+- worker_name, worker_env.num_of_workers, r->uri);
+-}
+ }
+ if (worker_name)
+ apr_table_setn(r->notes, JK_NOTE_WORKER_NAME, worker_name);
diff -Nru libapache-mod-jk-1.2.48/debian/patches/series
libapache-mod-jk-1.2.48/debian/patches/series
--- libapache-mod-jk-1.2.48/debian/patches/series 2020-06-04
21:42:29.0 +0200
+++ libapache-mod-jk-1.2.48/debian/patches/series 2023-09-24
17:09:51.0 +0200
@@ -1,2
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
I have just rebuilt and uploaded xorgxrdp 0.2.12-1+deb11u1 to bullseye- security. That should resolve the problem at hand. However I recommend to keep this bug report open and try to address the dependency problem between xrdp and xorgxrdp. If you claim that without a rebuild of xorgxrdp a new upstream version of xrdp would be broken, then this is a strong indication that xorgxrdp should be more than a recommendation in Debian terms: From the Debian Policy "Declaring relationships between packages" "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." If xrdp only works with a specific version of xorgxrdp then this is true in my opinion and the recommendation should be changed to a Depends. We had a similar issue with librhino-java and shrinksafe in the recent past. librhino-java had to declare a versioned Breaks on shrinksafe and shrinksafe had to add a versioned (Build-)Depends on rhino/librhino-java. In my opinion we have the exact same situation here. In any case I leave that to the maintainers of xrdp/xorgxrdp to resolve. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
Hello, the new Bullseye version of xrdp is identical to the version in Bookworm. Thus the underlying problem is probably more complex and I don't suspect that something is wrong with xrdp itself but more likely with a configuration option or related software packages which do something different than in Bookworm. I have tried to reproduce the problem on Bullseye with Gnome 3 installed. The problem here is that gnome-remote-desktop appears to interfere with xrdp, so I'm not totally sure what is caused by Gnome and what might be a bug in xrdp. Then I restarted the session with Gnome in Xorg mode and a remote connection to the xrdp server succeeded. However I got a black background instead of the normal wallpaper I have. Applications were shown correctly though. I definitely need more information about your setup or xrdp in general to debug this issue. Possible reasons for the behavior may be: 1. TLS / connection problem ? Did you do "adduser xrdp ssl-cert" ? Maybe a new TLS configuration option in 0.9.21.1? 2. graphic drivers ? I read that hardware accelerated drivers may cause such problems. Maybe try to disable them and use software rendering only? LIBGL_ALWAYS_SOFTWARE = true Please also upload the following log files: /var/log/xrdp-sesman.log /var/log/xrdp.log ~/.xsession-errors and journalctl -S -2m or something similar may provide more information about error messages, etc. ~/.xorgxrdp.10.log seems to belong to xorgxrdp. The package is only recommended but I wonder if the problem is potentially caused by it. xrdp is a build- dependency which suggests it might need a rebuild? But on the other hand then recommending the package would be wrong and it should be added to Depends. Someone else would have stumbled upon this sooner I guess. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1050502: gnome-shell crash when restarting with ALT+F2, "r" on nvidia-graphics-drivers
linux-gnu/../gi/closure.cpp:184 #31 0x7fe2b1ff4884 in Gjs::Closure::marshal(_GValue*, unsigned int, _GValue const*, void*, void*) (this=0x56199c720bb0, return_value=0x7ffe91cc6330, n_param_values=, param_values=0x7ffe91cc63c0, invocation_hint=, marshal_data=) at /usr/include/mozjs-102/js/RootingAPI.h:613 #36 0x7fe2b27a0243 in 0x56199ae01960 [MetaDisplay]> (instance=instance@entry=0x56199ae01960, signal_id=, detail=detail@entry=0) at ../../../gobject/gsignal.c:3675 #32 0x7fe2b2785540 in g_closure_invoke (closure=0x56199c720bb0, return_value=0x7ffe91cc6330, n_param_values=1, param_values=0x7ffe91cc63c0, invocation_hint=0x7ffe91cc6310) at ../../../gobject/gclosure.c:832 #33 0x7fe2b2798afc in signal_emit_unlocked_R (node=node@entry=0x7ffe91cc6470, detail=detail@entry=0, instance=instance@entry=0x56199ae01960, emission_return=emission_return@entry=0x7ffe91cc64f0, instance_and_params=instance_and_params@entry=0x7ffe91cc63c0) at ../../../gobject/gsignal.c:3980 #34 0x7fe2b2799d51 in signal_emit_valist_unlocked (instance=instance@entry=0x56199ae01960, signal_id=signal_id@entry=178, detail=detail@entry=0, var_args=var_args@entry=0x7ffe91cc65d0) at ../../../gobject/gsignal.c:3625 #35 0x7fe2b27a0186 in g_signal_emit_valist (instance=0x56199ae01960, signal_id=178, detail=0, var_args=0x7ffe91cc65d0) at ../../../gobject/gsignal.c:3355 #37 0x7fe2b1aceea2 in meta_display_request_restart (display=display@entry=0x56199ae01960 [MetaDisplay]) at ../src/core/display.c:2601 #38 0x7fe2b1ae46a3 in restart_check_ready (context=0x56199a795c80 [MetaContextMain]) at ../src/core/restart.c:64 #39 restart_check_ready (context=0x56199a795c80 [MetaContextMain]) at ../src/core/restart.c:58 #40 restart_helper_read_line_callback (source_object=, res=, user_data=0x56199a795c80) at ../src/core/restart.c:92 #41 0x7fe2b22c8ec3 in g_task_return_now (task=task@entry=0x5619a4068fe0 [GTask]) at ../../../gio/gtask.c:1371 #42 0x7fe2b22c9b63 in g_task_return (type=, task=0x5619a4068fe0 [GTask]) at ../../../gio/gtask.c:1440 #43 g_task_return (task=0x5619a4068fe0 [GTask], type=) at ../../../gio/gtask.c:1397 #44 0x7fe2b226abe7 in g_data_input_stream_read_complete (task=0x5619a4068fe0 [GTask], read_length=7, skip_length=1) at ../../../gio/gdatainputstream.c:986 #45 0x7fe2b2263506 in async_fill_callback_wrapper (source_object=0x5619a403cc00 [GDataInputStream], res=0x5619a3a3ede0, user_data=0x5619a4068fe0) at ../../../gio/gbufferedinputstream.c:451 #46 0x7fe2b22c8ec3 in g_task_return_now (task=task@entry=0x5619a3a3ede0 [GTask]) at ../../../gio/gtask.c:1371 #47 0x7fe2b22c9b63 in g_task_return (type=, task=0x5619a3a3ede0 [GTask]) at ../../../gio/gtask.c:1440 #48 g_task_return (task=0x5619a3a3ede0 [GTask], type=) at ../../../gio/gtask.c:1397 #49 0x7fe2b2262efa in fill_async_callback (source_object=, result=, user_data=0x5619a3a3ede0) at ../../../gio/gbufferedinputstream.c:1051 #50 0x7fe2b229458e in async_ready_callback_wrapper (source_object=0x56199be0a2b0 [GUnixInputStream], res=0x5619a3759840, user_data=0x5619a3a3ede0) at ../../../gio/ginputstream.c:565 #51 0x7fe2b22c8ec3 in g_task_return_now (task=task@entry=0x5619a3759840 [GTask]) at ../../../gio/gtask.c:1371 #52 0x7fe2b22c9b63 in g_task_return (type=, task=0x5619a3759840 [GTask]) at ../../../gio/gtask.c:1440 #53 g_task_return (task=0x5619a3759840 [GTask], type=) at ../../../gio/gtask.c:1397 #54 0x7fe2b2292980 in read_async_pollable (stream=0x56199be0a2b0, task=0x5619a3759840 [GTask]) at ../../../gio/ginputstream.c:1403 #55 0x7fe2b22929fd in read_async_pollable_ready (stream=, user_data=) at ../../../gio/ginputstream.c:1368 #56 0x7fe2b2124099 in g_main_dispatch (context=context@entry=0x56199a7978b0) at ../../../glib/gmain.c:3476 #57 0x7fe2b21272d7 in g_main_context_dispatch_unlocked (context=0x56199a7978b0) at ../../../glib/gmain.c:4284 #58 g_main_context_iterate_unlocked (context=0x56199a7978b0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4349 #59 0x7fe2b2127bdf in g_main_loop_run (loop=0x56199cd05ce0) at ../../../glib/gmain.c:4551 #60 0x7fe2b1ada039 in meta_context_run_main_loop (context=context@entry=0x56199a795c80 [MetaContextMain], error=error@entry=0x7ffe91cc69e0) at ../src/core/meta-context.c:482 #61 0x5619990919a3 in main (argc=, argv=) at ../src/main.c:683 (gdb) Broadcast message from system@station (Sun 2023-09-17 12:21:49 CEST): The system will reboot now! Broadcast message from system@station (Sun 2023-09-17 12:21:49 CEST): The system will reboot now! Connection to station closed by remote host. Connection to station closed. pi@pi:~$ Best regards, Markus
Bug#1042140: trophy: FTBFS: undefined reference to `pthread_mutexattr_setkind_np'
Control: reassign -1 src:clanlib Control: tags -1 pending This is actually a bug in clanlib which surfaced because of the recent uploads / rebuilds against glibc > 2.34. The pthread_mutexattr_setkind_np symbol is obsolete and has been replaced by pthread_mutexattr_settype. signature.asc Description: This is a digitally signed message part
Bug#1052003: emscripten: FTBFS with binaryen in experimental
Package: emscripten
Version: 3.1.6~dfsg-5
Severity: important
X-Debbugs-Cc: a...@debian.org
Dear maintainer,
emscripten fails to build from source with the latest version of
binaryen, currently 116, in experimental.
I'm attaching the complete build log. I intend to upload a new version
of binaryen to unstable next year because I know that emscripten has
no real maintainer and is currently maintained by the QA team. I will
ping this bug report again before I do the upload but I hope someone
else can look into this problem before that.
I wonder if emscripten should embed the exact version of binaryen
required to build the package to avoid a circular dependency (because
then I could use emscripten to build wabt.js for example).
These are the last log lines when emscripten fails:
embuilder:INFO: building struct_info
cache:INFO: generating system asset:
sysroot/lib/wasm32-emscripten/struct_info.json... (this will be cached in
"/<>/debian/em_cache/sysroot/lib/wasm32-emscripten/struct_info.json"
for subsequent builds)
emscripten:ERROR: emscript: failure to parse metadata output from
wasm-emscripten-finalize. raw output is:
Traceback (most recent call last):
File "/<>/emcc.py", line 3947, in
sys.exit(main(sys.argv))
^^
File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
^^^
File "/<>/emcc.py", line 3940, in main
ret = run(args)
^
File "/<>/emcc.py", line 1199, in run
phase_post_link(options, state, wasm_target, wasm_target, target)
File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
^^^
File "/<>/emcc.py", line 2753, in phase_post_link
phase_emscript(options, in_wasm, wasm_target, memfile)
File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
^^^
File "/<>/emcc.py", line 2781, in phase_emscript
emscripten.run(in_wasm, wasm_target, final_js, memfile)
File "/<>/emscripten.py", line 932, in run
emscript(in_wasm, out_wasm, outfile_js, memfile)
File "/<>/emscripten.py", line 297, in emscript
metadata = finalize_wasm(in_wasm, out_wasm, memfile)
^
File "/<>/emscripten.py", line 521, in finalize_wasm
metadata = get_metadata_binaryen(infile, outfile, modify_wasm, args)
^
File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
^^^
File "/<>/emscripten.py", line 406, in get_metadata_binaryen
metadata = load_metadata_json(stdout)
^^
File "/<>/emscripten.py", line 851, in load_metadata_json
metadata_json = json.loads(metadata_raw)
File "/usr/lib/python3.11/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
^^
File "/usr/lib/python3.11/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
^^
File "/usr/lib/python3.11/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
FAIL: Compilation failed!: ['emcc', '-D_GNU_SOURCE', '-o',
'/tmp/tmp3mop6qgt.js', '/tmp/tmpelb1y5rp.c', '-O0', '-Werror', '-Wno-format',
'-nostdlib',
'/<>/debian/em_cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a',
'-sMEMORY64=0', '-sBOOTSTRAPPING_STRUCT_INFO=1', '-sLLD_REPORT_UNDEFINED=1',
'-sSTRICT', '-sSINGLE_FILE', '-Wno-error=version-check', '-Wno-deprecated']
make[1]: *** [debian/rules:195: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:378: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
emscripten_3.1.6~dfsg-5.gz
Description: application/gzip
Bug#1029064: Lintian Bug
Control: forwarded -1 https://github.com/WebAssembly/binaryen/issues/5947 signature.asc Description: This is a digitally signed message part
Bug#1015358: binaryen: ftbfs with LTO (link time optimization) enabled
Control: forwarded -1 https://github.com/WebAssembly/binaryen/issues/5946 signature.asc Description: This is a digitally signed message part
Bug#1051920: RM: opm-common/experimental -- ROM; NVIU
Package: ftp.debian.org Severity: normal Please the remove the version (2022.10+ds-5) that is currently in experimental as it is much older than the version 2023.04+ds-5 in unstable. Thanks a lot. Kind regards, Markus
Bug#1051429: bookworm-pu: package openrefine/3.6.2-2
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
[ Reason ]
Fixing CVE-2023-37476 in Bookworm.
[ Tests ]
The patch checks if file paths inside Zip/Tar archives are valid and do not
try to escape their root directory. The code looks reasonable to me.
[ Risks ]
The code is trivial.
[ 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 (old)stable
[x] the issue is verified as fixed in unstable
diff -Nru openrefine-3.6.2/debian/changelog openrefine-3.6.2/debian/changelog
--- openrefine-3.6.2/debian/changelog 2023-04-05 20:20:17.0 +0200
+++ openrefine-3.6.2/debian/changelog 2023-09-07 21:22:17.0 +0200
@@ -1,3 +1,13 @@
+openrefine (3.6.2-2+deb12u1) bookworm; urgency=medium
+
+ * Fix CVE-2023-37476:
+OpenRefine is a free, open source tool for data processing. A carefully
+crafted malicious OpenRefine project tar file can be used to trigger
+arbitrary code execution in the context of the OpenRefine process if a user
+can be convinced to import it. (Closes: #1041422)
+
+ -- Markus Koschany Thu, 07 Sep 2023 21:22:17 +0200
+
openrefine (3.6.2-2) unstable; urgency=medium
* Depend on libjoda-time-java and liboro-java.
diff -Nru openrefine-3.6.2/debian/patches/CVE-2023-37476.patch
openrefine-3.6.2/debian/patches/CVE-2023-37476.patch
--- openrefine-3.6.2/debian/patches/CVE-2023-37476.patch1970-01-01
01:00:00.0 +0100
+++ openrefine-3.6.2/debian/patches/CVE-2023-37476.patch2023-09-07
21:22:17.0 +0200
@@ -0,0 +1,24 @@
+From: Markus Koschany
+Date: Thu, 17 Aug 2023 21:33:50 +0200
+Subject: CVE-2023-37476
+
+Bug-Debian: https://bugs.debian.org/1041422
+Origin:
https://github.com/OpenRefine/OpenRefine/commit/c40c84d8170c4d61c6a0926531b552a50caa5651
+---
+ main/src/com/google/refine/io/FileProjectManager.java | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/main/src/com/google/refine/io/FileProjectManager.java
b/main/src/com/google/refine/io/FileProjectManager.java
+index 09197f7..c913199 100644
+--- a/main/src/com/google/refine/io/FileProjectManager.java
b/main/src/com/google/refine/io/FileProjectManager.java
+@@ -167,6 +167,9 @@ public class FileProjectManager extends ProjectManager {
+
+ while ((tarEntry = tin.getNextTarEntry()) != null) {
+ File destEntry = new File(destDir, tarEntry.getName());
++if
(!destEntry.toPath().normalize().startsWith(destDir.toPath().normalize())) {
++throw new IllegalArgumentException("Zip archives with files
escaping their root directory are not allowed.");
++}
+ File parent = destEntry.getParentFile();
+
+ if (!parent.exists()) {
diff -Nru openrefine-3.6.2/debian/patches/series
openrefine-3.6.2/debian/patches/series
--- openrefine-3.6.2/debian/patches/series 2023-04-05 20:20:17.0
+0200
+++ openrefine-3.6.2/debian/patches/series 2023-09-07 21:22:17.0
+0200
@@ -4,3 +4,4 @@
log4j-api.patch
no-java-files.patch
gdata-extension.patch
+CVE-2023-37476.patch
Bug#1050502: gnome-shell crashes when restarting it with ALT+F2 and "r"
I tried obtaining a stack and JS trace using GDB for an already running gnome-shell like discribed here: https://wiki.gnome.org/GettingInTouch/Bugzilla/GettingTraces/Details#Obtaining_a_stack_and_JS_trace_using_GDB_for_an_already_running_gnome-shell But inbetween gnome-shell crashed and I had to logout- and in again to get the journalctl logs. The gdb.txt: [Thread 0x7f81d54096c0 (LWP 18756) exited] [New Thread 0x7f81d54096c0 (LWP 18825)] [New Thread 0x7f81d4c086c0 (LWP 18826)] [Thread 0x7f81d4c086c0 (LWP 18826) exited] [New Thread 0x7f81d4c086c0 (LWP 18932)] [New Thread 0x7f81b3fff6c0 (LWP 18933)] [Thread 0x7f81d4c086c0 (LWP 18932) exited] [New Thread 0x7f81d4c086c0 (LWP 18934)] [New Thread 0x7f81b2ffd6c0 (LWP 18935)] [Thread 0x7f81b3fff6c0 (LWP 18933) exited] [Thread 0x7f81d4c086c0 (LWP 18934) exited] [Thread 0x7f81b2ffd6c0 (LWP 18935) exited] [Detaching after fork from child process 18936] [New Thread 0x7f81b2ffd6c0 (LWP 18938)] [New Thread 0x7f81d4c086c0 (LWP 18939)] [Thread 0x7f81b2ffd6c0 (LWP 18938) exited] [Thread 0x7f81d4c086c0 (LWP 18939) exited] Thread 1 "gnome-shell" received signal SIGSEGV, Segmentation fault. 0x7f82013fbf63 in _XSend () from /lib/x86_64-linux-gnu/libX11.so.6 #0 0x7f82013fbf63 in _XSend () at /lib/x86_64-linux-gnu/libX11.so.6 #1 0x7f82013f2331 in XQueryExtension () at /lib/x86_64-linux-gnu/libX11.so.6 #2 0x7f81fe957d66 in () at /lib/x86_64-linux-gnu/libXext.so.6 #3 0x7f81fe9584b4 in XSyncTriggerFence () at /lib/x86_64-linux-gnu/libXext.so.6 #4 0x7f820190a340 in meta_sync_free (self=0x55df71f4b2c0) at ../src/compositor/meta-sync-ring.c:392 i = 0 ring = 0x7f8201a50800 __func__ = "meta_sync_ring_destroy" #5 meta_sync_ring_destroy () at ../src/compositor/meta-sync-ring.c:470 i = 0 ring = 0x7f8201a50800 __func__ = "meta_sync_ring_destroy" #6 0x7f8201908da5 in meta_compositor_x11_dispose (object=0x55df71f1fa00) at ../src/compositor/meta-compositor-x11.c:520 compositor_x11 = 0x55df71f1fa00 compositor = 0x55df71f1fa00 stage = 0x55df71b88220 #7 0x7f8202514d0a in g_object_run_dispose () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x7f82018aca19 in meta_compositor_destroy (compositor=0x55df71f1fa00) at ../src/compositor/compositor.c:198 #9 0x7f82018cc08d in meta_display_close (display=0x55df71b8c430, timestamp=) at ../src/core/display.c:1178 _pp = 0x55df71b8c570 _ptr = compositor = laters = 0x55df71f0f110 #10 0x7f82022274ae in shell_global_reexec_self (global=0x55df71bb9810) at ../src/shell-global.c:1339 arr = 0x7f81e4262c40 len = 21 meta_context = buf = 0x55df73d6ef90 "/usr/bin/gnome-shell" buf_p = buf_end = error = 0x0 #11 0x7f8200fb2f7a in () at /lib/x86_64-linux-gnu/libffi.so.8 #12 0x7f8200fb240e in () at /lib/x86_64-linux-gnu/libffi.so.8 #13 0x7f8200fb2b0d in ffi_call () at /lib/x86_64-linux-gnu/libffi.so.8 #14 0x7f8201dcbfa7 in () at /lib/x86_64-linux-gnu/libgjs.so.0 #15 0x7f8201dcc698 in () at /lib/x86_64-linux-gnu/libgjs.so.0 #16 0x7f81fef96620 in () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #17 0x7f81fef89d67 in () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #18 0x7f81fef95de3 in () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #19 0x7f81fef96267 in () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #20 0x7f81fef9682c in () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #21 0x7f81ff03fb1d in JS_CallFunctionValue(JSContext*, JS::Handle, JS::Handle, JS::HandleValueArray const&, JS::MutableHandle) () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #22 0x7f8201da8ed1 in () at /lib/x86_64-linux-gnu/libgjs.so.0 #23 0x7f8201dfc884 in () at /lib/x86_64-linux-gnu/libgjs.so.0 #24 0x7f820250e3f8 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #25 0x7f820252101c in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #26 0x7f82025221b1 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #27 0x7f8202528552 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #28 0x7f82025285ff in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #29 0x7f82018cc2fe in meta_display_request_restart (display=display@entry=0x55df71b8c430) at ../src/core/display.c:2601 result = 0 #30 0x7f82018e15b3 in restart_check_ready (context=0x55df71511c80) at ../src/core/restart.c:64 display = 0x55df71b8c430 context = 0x55df71511c80 error = 0x0 length = 7 line = #31 restart_check_ready (context=0x55df71511c80) at ../src/core/restart.c:58 context = 0x55df71511c80 error = 0x0 length = 7 line = #32 restart_helper_read_line_callback (source_object=, res=, user_data=0x55df71511c80) at ../src/core/restart.c:92 context = 0x55df71511c80 error = 0x0
Bug#1050731: libmutter-12-0: gnome-shell libmutter-12 segfault
Dear Maintainer, The same bug happens on my machine. I sent a bug report to the gnome-shell maintainers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050502 Best regards, Markus
Bug#1050044: bullseye-pu: package rar/2:5.5.0-1
There was another vulnerability, CVE-2023-40477, fixed in version 2:6.23- 1~deb11u1 now. signature.asc Description: This is a digitally signed message part
Bug#1050612: bookworm-pu: package rar/2:6.20.0.1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: a...@debian.org Please see Debian bug #1050044. Same reasoning applies to Bookworm. Here rar is only affected by CVE-2023-40477 though. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable rar is a binary blob which is why I cannot provide a useful debdiff. Regards, Markus
Bug#1050119: bullseye-pu: package unrar-nonfree/1:6.0.3-1+deb11u1
Another security vulnerability was discovered in unrar-nonfree, CVE-2023-40477.
This issue has been corrected in 1:6.0.3-1+deb11u3. I'm attaching the new
debdiff.
Regards,
Markus
diff -Nru unrar-nonfree-6.0.3/debian/changelog unrar-nonfree-6.0.3/debian/changelog
--- unrar-nonfree-6.0.3/debian/changelog 2022-05-10 13:26:16.0 +0200
+++ unrar-nonfree-6.0.3/debian/changelog 2023-08-23 17:36:17.0 +0200
@@ -1,3 +1,19 @@
+unrar-nonfree (1:6.0.3-1+deb11u3) bullseye; urgency=high
+
+ * Fix CVE-2023-40477
+
+ -- YOKOTA Hiroshi Thu, 24 Aug 2023 00:36:17 +0900
+
+unrar-nonfree (1:6.0.3-1+deb11u2) bullseye; urgency=high
+
+ [ Markus Koschany ]
+ * Fix CVE-2022-48579:
+It was discovered that UnRAR, an unarchiver for rar files, allows
+extraction of files outside of the destination folder via symlink chains.
+(Closes: #1050080)
+
+ -- YOKOTA Hiroshi Thu, 17 Aug 2023 21:04:50 +0900
+
unrar-nonfree (1:6.0.3-1+deb11u1) bullseye; urgency=high
* Fix CVE-2022-30333 (Closes: #1010837)
diff -Nru unrar-nonfree-6.0.3/debian/patches/0013-CVE-2022-48579.patch unrar-nonfree-6.0.3/debian/patches/0013-CVE-2022-48579.patch
--- unrar-nonfree-6.0.3/debian/patches/0013-CVE-2022-48579.patch 1970-01-01 01:00:00.0 +0100
+++ unrar-nonfree-6.0.3/debian/patches/0013-CVE-2022-48579.patch 2023-08-23 17:36:17.0 +0200
@@ -0,0 +1,429 @@
+From: Markus Koschany
+Date: Mon, 14 Aug 2023 15:43:54 +0200
+Subject: CVE-2022-48579
+
+Origin: https://github.com/pmachapman/unrar/commit/2ecab6bb5ac4f3b88f270218445496662020205f
+---
+ arcread.cpp | 4 ++-
+ extinfo.cpp | 89 +++
+ extinfo.hpp | 3 +-
+ extract.cpp | 44 +
+ extract.hpp | 6
+ hardlinks.cpp | 2 --
+ model.cpp | 6 ++--
+ os.hpp| 1 +
+ pathfn.cpp| 14 +++---
+ timefn.hpp| 11
+ ulinks.cpp| 6 ++--
+ win32stm.cpp | 9 --
+ 12 files changed, 170 insertions(+), 25 deletions(-)
+
+diff --git a/arcread.cpp b/arcread.cpp
+index d1df6c0..63858d9 100644
+--- a/arcread.cpp
b/arcread.cpp
+@@ -1441,7 +1441,9 @@ bool Archive::ReadSubData(Array *UnpData,File *DestFile,bool TestMode)
+ {
+ if (SubHead.UnpSize>0x100)
+ {
+- // So huge allocation must never happen in valid archives.
++ // Prevent the excessive allocation. When reading to memory, normally
++ // this function operates with reasonably small blocks, such as
++ // the archive comment, NTFS ACL or "Zone.Identifier" NTFS stream.
+ uiMsg(UIERROR_SUBHEADERUNKNOWN,FileName);
+ return false;
+ }
+diff --git a/extinfo.cpp b/extinfo.cpp
+index 5cb90a4..0f25f31 100644
+--- a/extinfo.cpp
b/extinfo.cpp
+@@ -112,6 +112,68 @@ static bool LinkInPath(const wchar *Name)
+ }
+
+
++// Delete symbolic links in file path, if any, and replace them by directories.
++// Prevents extracting files outside of destination folder with symlink chains.
++bool LinksToDirs(const wchar *SrcName,const wchar *SkipPart,std::wstring )
++{
++ // Unlike Unix, Windows doesn't expand lnk1 in symlink targets like
++ // "lnk1/../dir", but converts the path to "dir". In Unix we need to call
++ // this function to prevent placing unpacked files outside of destination
++ // folder if previously we unpacked "dir/lnk1" -> "..",
++ // "dir/lnk2" -> "lnk1/.." and "dir/lnk2/anypath/poc.txt".
++ // We may still need this function to prevent abusing symlink chains
++ // in link source path if we remove detection of such chains
++ // in IsRelativeSymlinkSafe. This function seems to make other symlink
++ // related safety checks redundant, but for now we prefer to keep them too.
++ //
++ // 2022.12.01: the performance impact is minimized after adding the check
++ // against the previous path and enabling this verification only after
++ // extracting a symlink with ".." in target. So we enabled it for Windows
++ // as well for extra safety.
++//#ifdef _UNIX
++ wchar Path[NM];
++ if (wcslen(SrcName)>=ASIZE(Path))
++return false; // It should not be that long, skip.
++ wcsncpyz(Path,SrcName,ASIZE(Path));
++
++ size_t SkipLength=wcslen(SkipPart);
++
++ if (SkipLength>0 && wcsncmp(Path,SkipPart,SkipLength)!=0)
++SkipLength=0; // Parameter validation, not really needed now.
++
++ // Do not check parts already checked in previous path to improve performance.
++ for (uint I=0;Path[I]!=0 && ISkipLength)
++ SkipLength=I;
++
++ wchar *Name=Path;
++ if (SkipLength>0)
++ {
++// Avoid converting symlinks in destination path part specified by user.
++Name+=SkipLength;
++while (IsPathDiv(*Name))
++ Name++;
++ }
++
++ for (wchar *s=Path+wcslen(Path)-1;s>Name;s--)
++if (IsPathDiv(*s))
++{
++ *s=0;
++ FindData FD;
++ if (FindFile::FastFind(Path,,true) &
