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#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#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#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#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#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#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#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#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#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#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#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#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#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) &
Bug#1050311: bookworm-pu: package imlib2/1.10.0-4
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: a...@debian.org [ Reason ] Fixing Debian bug #1041406 in Bookworm. imlib_clone_image() no longer preserves the alpha channel flag. [ Impact ] This was an unintentional upstream change which also affects libimage-imlib2-perl and every developer who relies on the preservation of the alpha channel flag in imlib_clone_image() [ Tests ] Debian bug #1041406 has a test program attached which demonstrates the regression in Bookworm and that 1.10.0-4+deb12u1 contains the fix. [ Risks ] Low. This is a straightforward fix with a clear reproducer. [ 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 imlib2-1.10.0/debian/changelog imlib2-1.10.0/debian/changelog --- imlib2-1.10.0/debian/changelog 2023-01-02 23:10:40.0 +0100 +++ imlib2-1.10.0/debian/changelog 2023-08-22 22:52:24.0 +0200 @@ -1,3 +1,10 @@ +imlib2 (1.10.0-4+deb12u1) bookworm; urgency=medium + + * Fix imlib_clone_image() no longer preserves the alpha channel flag. + (Closes: #1041406) + + -- Markus Koschany Tue, 22 Aug 2023 22:52:24 +0200 + imlib2 (1.10.0-4) unstable; urgency=medium * Really ignore libjxl-dev on s390x. diff -Nru imlib2-1.10.0/debian/patches/debian-bug-1041406.patch imlib2-1.10.0/debian/patches/debian-bug-1041406.patch --- imlib2-1.10.0/debian/patches/debian-bug-1041406.patch 1970-01-01 01:00:00.0 +0100 +++ imlib2-1.10.0/debian/patches/debian-bug-1041406.patch 2023-08-22 22:52:24.0 +0200 @@ -0,0 +1,38 @@ +From 173edae4bf72e01b0dada41a406d34f976b1fc28 Mon Sep 17 00:00:00 2001 +From: Kim Woelders +Date: Wed, 19 Jul 2023 18:11:08 +0200 +Subject: [PATCH] image: Fix preservation of alpha chanel flag in + imlib_clone_image() + +https://git.enlightenment.org/old/legacy-imlib2/issues/17: + +As per subject, the imlib_clone_image() function no longer preserves +the alpha channel value since imlib2 1.10.0. + +This bug report was initially filed by Niko Tyni in Debian's bug tracker. +If you follow the subsequent link you will also find a test program that +demonstrates the regression. + +https://bugs.debian.org/1041406 + +This upstream change is most likely the root cause of the problem + +b39d33c800 + +It looks like an oversight where other functions were adapted +to the new alpha channel implementation, but imlib_clone_image() remains +unchanged and only copies the flags and not the new alpha byte. +--- + src/lib/api.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/src/lib/api.c b/src/lib/api.c +@@ -1017,6 +1017,7 @@ imlib_clone_image(void) + return NULL; + } +memcpy(im->data, im_old->data, im->w * im->h * sizeof(uint32_t)); ++ im->has_alpha = im_old->has_alpha; +im->flags = im_old->flags; +IM_FLAG_SET(im, F_UNCACHEABLE); +im->moddate = im_old->moddate; diff -Nru imlib2-1.10.0/debian/patches/remove-data-dir.patch imlib2-1.10.0/debian/patches/remove-data-dir.patch --- imlib2-1.10.0/debian/patches/remove-data-dir.patch 2023-01-02 23:10:40.0 +0100 +++ imlib2-1.10.0/debian/patches/remove-data-dir.patch 2023-08-22 22:52:24.0 +0200 @@ -10,8 +10,6 @@ configure.ac | 3 --- 2 files changed, 1 insertion(+), 4 deletions(-) -diff --git a/Makefile.am b/Makefile.am -index 3371af3..d93301b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2,7 +2,7 @@ AUTOMAKE_OPTIONS = foreign @@ -23,8 +21,6 @@ if BUILD_DOC SUBDIRS += doc endif -diff --git a/configure.ac b/configure.ac -index 791f44d..8df303a 100644 --- a/configure.ac +++ b/configure.ac @@ -280,9 +280,6 @@ src/modules/Makefile diff -Nru imlib2-1.10.0/debian/patches/series imlib2-1.10.0/debian/patches/series --- imlib2-1.10.0/debian/patches/series 2023-01-02 23:10:40.0 +0100 +++ imlib2-1.10.0/debian/patches/series 2023-08-22 22:52:24.0 +0200 @@ -1 +1,2 @@ remove-data-dir.patch +debian-bug-1041406.patch
Bug#1050119: bullseye-pu: package unrar-nonfree/1:6.0.3-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org
Hi,
[ Reason ]
unrar-nonfree is affected by CVE-2022-48579 in Bullseye. non-free
packages are not supported by the security team but it makes still
sense to fix this issue via a point update.
[ Impact ]
unrar-nonfree would continue to be affected by CVE-2022-48579.
[ Tests ]
I have manually created a rar archive which includes several symlinks
pointing to each other, files with relative paths and special
characters and in all cases unrar-nonfree seems to do the right thing.
An official reproducer was not available.
[ Risks ]
If I made a mistake there should be an unpack error or something
similar, which is not the case. Command switches didn't change so an
external program like xarchiver continues to work as expected.
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in (old)stable
[*] the issue is verified as fixed in unstable
[ Other info ]
Maintainer approves point update. (#1050080)
diff -Nru unrar-nonfree-6.0.3/debian/changelog
unrar-nonfree-6.0.3/debian/changelog
--- unrar-nonfree-6.0.3/debian/changelog2022-05-10 13:26:16.0
+0200
+++ unrar-nonfree-6.0.3/debian/changelog2023-08-20 09:58:26.0
+0200
@@ -1,3 +1,13 @@
+unrar-nonfree (1:6.0.3-1+deb11u2) bullseye; urgency=high
+
+ * Non maintainer upload.
+ * 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)
+
+ -- Markus Koschany Sun, 20 Aug 2023 09:58:26 +0200
+
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-20 09:58:26.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.
++//#ifde
Bug#1040475: Broken symlinks cause Apache Directory Server to not work at all out-of-the-box
I believe the symlink problem is fixed in version 2.0.0~M26-2 but I'd like to test the apacheds server component more before I'm going to close this bug report. Markus signature.asc Description: This is a digitally signed message part
Bug#1050080: unrar: Fix CVE-2022-48579 for Debian 11
Hello, I wanted to prepare a fix for CVE-2022-48579 in Bullseye and release it via a bullsye point update. Do you want to take care of the upload instead? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1042757: ublock-origin: embded javascript lib
Am Samstag, dem 19.08.2023 um 06:13 + schrieb Bastien Roucariès:
> [...]
> No unfortunatly this is transpiled aka compiled by webpack
> see the first line
> export default (function() {
>
> This is make by webpack or rollup that are automated tools. This means that
> this code is transpiled and I do not know the extend of transpiling.
>
> it may be only the es6 upstream code:
> https://sources.debian.org/src/node-punycode/2.2.3-2/scripts/prepublish.js/
> or something worst that replace the constant by something else.
>
> if you see the original code here:
> https://sources.debian.org/src/node-punycode/2.2.3-2/punycode.js/
>
> you do not see the export default (function() {
> line
>
> Javascript is strange you could edit generated file and min.js is not the
> only problem
Ok, I see. I don't think this a problem though. This is still reasonably
modifiable and human readable.
Markus
signature.asc
Description: This is a digitally signed message part
Bug#1042757: ublock-origin: embded javascript lib
Am Montag, dem 31.07.2023 um 11:56 + schrieb Bastien Roucariès: > Source: ublock-origin > Severity: serious > Justification: not prefered form of modification > > Dear Maintainer, > > src/lib include a few library that are already packaged for debian. > > per se it is not a serious bug, but we should try if possible after testing > to > use packaged version > > The serious bug is due that for instance punycode was not in prefered form of > modification due to being wepackaged (transpiled) in order to be an ES > module. > > They may be other transpiled package in this subdirectory Hello Bastien, thanks for the report. I have reviewed the src/lib directory and replaced the embedded Javascript libraries of csstree and js-beautify with Debian's system libraries. I also added the source file of hsluv to debian/missing-sources and documented the licenses of these three Javascript libraries in debian/copyright. I decided against replacing punycode because punycode.js in ublock-origin looks like the preferred form for me. The file is not minified and can be edited without problems. I believe you were referring to hsluv instead. I believe this issue is fixed in version 1.51.0+dfsg-2 soon. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1050044: bullseye-pu: package rar/2:5.5.0-1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: a...@debian.org Hello, [ Reason ] I would like to update rar in bullseye because it is affected by CVE-2022-30333. This issue has been fixed in all other suites already and it makes sense to address this problem in bullseye too. A backport is the only sensible approach because rar is closed source. [ Impact ] The RAR archiver would continue to be vulnerable. [ Tests ] Unfortunately rar is just a non-free binary without source code, so I had to rely on manual testing. Since there was not enough information available to reproduce the problem, I created a normal rar archive with random files and folders and another one which consisted of several symlinks and files with relative paths. The extract operation seems to work correctly in both cases. [ Risks ] I'm not aware of any major changes like different command switches etc. but rar is non-free and closed source, so there is always some kind of risk. [ 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 [ Changes ] I don't attach a debdiff because of the closed source binary of rar.
Bug#1040226: tomcat10: deployment-time Java EE to Jakarta EE migration fails
Hi, Am Dienstag, dem 15.08.2023 um 14:52 +0200 schrieb J. Tóth Tamás: > Hi, > > > Please keep the bug report always in CC. > > I thought my 8 August mail contains no new information, so it makes no > sense to spam the BTS with it. But okay, next time (and this time) I’ll > use Reply All regardless of the message content. I'm not the only Debian developer who could help you. There may be other users too who are interested in this topic and who could provide valuable insight or suggestions. Hence why it's so important to have a public bug tracker with the record of our conversation. > > > > We’d like to gradually upgrade > > > to Bookworm, but I don’t want to make sysops’ lives more complicated by > > > giving them one WAR file to install on Bookworm and another one to > > > install on Bullseye. > > > > […] You can just manually run the tomcat-jakartaee-migration tool on > > your existing war files. All it mainly does is to replace the old > > occurrences of javax.* with jakarta.*. > > That’s exactly what I meant by “making sysops’ lives more complicated by > giving them one WAR file to install on Bookworm and another one to > install on Bullseye”, so it’s out of question for me in production. Ok, I'm not familiar with your workflow. Though I would never trust a tool to do the right thing on the fly. I would instruct my development team to port the application to Tomcat 10 and test it thoroughly and then my production team only would take care of the administration and deployment task as usual. > > > You could also send a patch with your proposed changes to Debian's tomcat10 > > > package and I take a look at it. > > I created https://salsa.debian.org/java-team/tomcat10/-/merge_requests/1 > – it’s quite likely wrong in its current form, but I hope it can be fixed. Thank you! I have merged your request and also pushed a new upstream version to our Git repository but I didn't upload the package yet. Patches should be added to the debian/patches/series file as well, otherwise they won't be applied. The rest looked good to me. However I still get a migration warning when I follow your initial steps with the basic "test" app. There is a DirectoryNotEmptyException. Initially tomcat migrates the test folder in webapps-javaee to a newx.tmp folder and then tries to remove the latter, which fails. What can we do to avoid this warning? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1040226: tomcat10: deployment-time Java EE to Jakarta EE migration fails
Hello, Am Montag, dem 07.08.2023 um 20:22 +0200 schrieb J. Tóth Tamás: > Hi, > > Did you notice my reply sent on 4 July? Yes, I did. Please keep the bug report always in CC. > We’d like to gradually upgrade > to Bookworm, but I don’t want to make sysops’ lives more complicated by > giving them one WAR file to install on Bookworm and another one to > install on Bullseye. I haven't had the time to investigate this problem yet. You don't have to wait for a solution of this bug though. You can just manually run the tomcat- jakartaee-migration tool on your existing war files. All it mainly does is to replace the old occurrences of javax.* with jakarta.*. You could also send a patch with your proposed changes to Debian's tomcat10 package and I take a look at it. Markus signature.asc Description: This is a digitally signed message part
Bug#1041346: RM: https-everywhere -- ROM; obsolete;major browsers offer native support;
debian-parl and boxer-data have been updated in unstable thus nothing in Debian references https-everywhere anymore. It should be ready to be removed now. signature.asc Description: This is a digitally signed message part
Bug#1041348: RM: https-everywhere/stable -- ROM; obsolete;major browsers offer native support now;
I have uploaded a new revision of boxer-data and debian-parl to Bookworm now. This update removes the dependency on webext-https-everywhere. Jonas agreed to this change. https://bugs.debian.org/1041350 AFAIK nothing else should prevent the removal of https-everywhere from Bookworm. Markus signature.asc Description: This is a digitally signed message part
Bug#1041446: bookworm-pu: package boxer-data/10.9.12
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: a...@debian.org [ Reason ] The https-everywhere browser addon is obsolete and boxer-data (and thus debian-parl) still references it. [ Impact ] We have to update boxer-data in order to fix Debian bug #1041350 in Bookworm. [ Risks ] https only mode is now a standard feature of all major browsers. Users just don't need the https-everywhere addon anymore which is a good thing. [ 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 boxer-data-10.9.12/bullseye/classes/Desktop/web/firefox/harden.yml boxer-data-10.9.12+deb12u1/bullseye/classes/Desktop/web/firefox/harden.yml --- boxer-data-10.9.12/bullseye/classes/Desktop/web/firefox/harden.yml 2020-11-10 13:20:34.0 +0100 +++ boxer-data-10.9.12+deb12u1/bullseye/classes/Desktop/web/firefox/harden.yml 2023-07-19 00:04:50.0 +0200 @@ -6,6 +6,5 @@ pkg: - include Firefox security plugins pkg: -- webext-https-everywhere - webext-privacy-badger - webext-ublock-origin-firefox diff -Nru boxer-data-10.9.12/CHANGELOG.md boxer-data-10.9.12+deb12u1/CHANGELOG.md --- boxer-data-10.9.12/CHANGELOG.md 2022-08-07 18:31:29.0 +0200 +++ boxer-data-10.9.12+deb12u1/CHANGELOG.md 2023-07-19 00:04:50.0 +0200 @@ -6,6 +6,11 @@ ## [Unreleased] +## [10.9.13] - 2023-07-19 + + * Fix class Desktop.web.firefox.harden. No longer install obsolete Firefox +addon https-everywhere. + ## [10.9.12] - 2022-08-07 ### Fixed diff -Nru boxer-data-10.9.12/debian/changelog boxer-data-10.9.12+deb12u1/debian/changelog --- boxer-data-10.9.12/debian/changelog 2022-08-07 18:31:45.0 +0200 +++ boxer-data-10.9.12+deb12u1/debian/changelog 2023-07-19 00:04:50.0 +0200 @@ -1,3 +1,11 @@ +boxer-data (10.9.12+deb12u1) bookworm; urgency=medium + + * Non-maintainer upload. + * Fix class Desktop.web.firefox.harden. No longer install obsolete Firefox +addon https-everywhere. + + -- Markus Koschany Wed, 19 Jul 2023 00:04:50 +0200 + boxer-data (10.9.12) unstable; urgency=medium * add class l10n.mythes.pt.BR since bookworm
Bug#1041406: libimlib2: imlib_clone_image() no longer preserves the alpha channel flag
Control: forwarded -1 https://git.enlightenment.org/old/legacy-imlib2/issues/17 Thanks for the report! signature.asc Description: This is a digitally signed message part
Bug#1041346: RM: https-everywhere -- ROM; obsolete;major browsers offer native support;
I was unaware about one r-dep that references https-everywhere. https://bugs.debian.org/1041350 I get back to you as soon as this problem has been resolved. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1041348: RM: https-everywhere/stable -- ROM; obsolete;major browsers offer native support now;
Hi, Am Montag, dem 17.07.2023 um 20:32 +0100 schrieb Adam D. Barratt: > # BCC control@ > reassign 1041348 release.debian.org > retitle 1041348 RM: https-everywhere -- ROM; obsolete;major browsers offer > native support now > user release.debian@packages.debian.org > usertags 1041348 = rm > tags 1041348 + bookworm moreinfo > thanks > > On Mon, 2023-07-17 at 21:07 +0200, Markus Koschany wrote: > > Dear ftp and release team, > > > > Just Release. Reassigning and fixing up the metadata. Perhaps we should change the reportbug template for ftp.debian.org because a stable removal bug report is a valid choice there. > > > please remove https-everywhere from stable. This addon for Firefox > > and > > Chromium has become obsolete because major browsers offer native > > support for HTTPS only mode now. > > > > https://www.eff.org/https-everywhere/set-https-default-your-browser > > > > See https://bugs.debian.org/1041335 > > > > Since there is no need for it anymore and development has stopped, it > > is safe to remove it from Bookworm. > > > > Not quite - it has an r-dep: > > Checking reverse dependencies... > # Broken Depends: > debian-parl: parl-desktop Whoops. I've just filed https://bugs.debian.org/1041350 I guess Jonas won't object against the removal. I get back to you as soon as possible. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1041350: parl-desktop: dependency on webext-https-everywhere is obsolete
Package: parl-desktop Version: 1.9.31 Severity: important X-Debbugs-Cc: a...@debian.org Dear maintainer, the addon https-everywhere has become obsolete. Nowadays all major browsers offer native support for HTTPS only mode. I have requested the removal of https-everywhere from Debian and your package is the only one that still references it. https://bugs.debian.org/1041346 I would also like to remove the addon from Bookworm because it is no longer developed. https://bugs.debian.org/1041348 Let me know if I should just remove the dependency on https-everywhere and upload a new revision of parl-desktop to Bookworm or if you prefer another solution. Regards, Markus
Bug#1041348: RM: https-everywhere/stable -- ROM; obsolete;major browsers offer native support now;
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-rele...@lists.debian.org, a...@debian.org Dear ftp and release team, please remove https-everywhere from stable. This addon for Firefox and Chromium has become obsolete because major browsers offer native support for HTTPS only mode now. https://www.eff.org/https-everywhere/set-https-default-your-browser See https://bugs.debian.org/1041335 Since there is no need for it anymore and development has stopped, it is safe to remove it from Bookworm. Regards, Markus
Bug#1041346: RM: https-everywhere -- ROM; obsolete;major browsers offer native support;
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: a...@debian.org Dear ftp team, please remove https-everywhere from Debian. This addon for Firefox and Chromium has become obsolete because major browsers offer native support for HTTPS only mode now. https://www.eff.org/https-everywhere/set-https-default-your-browser See https://bugs.debian.org/1041335 Regards, Markus
Bug#1041335: webext-https-everywhere: obsolete, should be deleted
Hi, Am Montag, dem 17.07.2023 um 17:41 +0200 schrieb michel: > Package: webext-https-everywhere > Severity: wishlist > Tags: upstream > X-Debbugs-Cc: okgomdjgbm...@gmail.com > > Dear Maintainer, > > > > https-everywhere is obsolete, it was sunset january 2023. It seams you forgot > about it. Thanks for the heads-up! Actually I didn't know about that. We can remove it from Bookworm too. That shouldn't be a problem. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1040226: tomcat10: deployment-time Java EE to Jakarta EE migration fails
Am Montag, dem 03.07.2023 um 18:28 +0200 schrieb Tamás J.Tóth: > > > The web app doesn't load. The Tomcat log contains the following: > > WARNING [main] org.apache.catalina.startup.HostConfig.migrateLegacyApp > Migration failure > java.lang.NoClassDefFoundError: org/apache/tomcat/jakartaee/Migration Thanks for the report. You have to install the tomcat-jakartaee-migration package. [1] I guess we could either suggest or recommend this package to make it more obvious. https://tracker.debian.org/pkg/tomcat-jakartaee-migration Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1039974: tomcat10: tomcat user has wrong home "/var/lib/tomcat" directory in /etc/passwd
Control: tags -1 moreinfo > deploy .war in tomcat10 > got errors from tomcat10 in "journalctl -f" > > * What exactly did you do that was effective ? > > change tomcat user home in /etc/passwd to /var/lib/tomcat10 > > * What was the outcome of this action? > > Problem solved You most likely don't have to change the user home of tomcat to solve your problem (which you did not specify at all) There is a difference between the operating system user and home directory and the applications' home directory. See Debian bug https://bugs.debian.org/926338 for reference. You have to tell your tomcat applications explicitly if they can write or read certain file system directories. See /usr/share/doc/tomcat10/README.Debian for more information. By default Debian's tomcat package is meant to be secure. It is the task of the system administrator to configure tomcat correctly. signature.asc Description: This is a digitally signed message part
Bug#1038426: renpy: Uncaught exception occurred when attempting to start
Control: severity -1 grave Control: tags -1 help Am Sonntag, dem 18.06.2023 um 04:23 + schrieb Zach: > File "/usr/share/games/renpy/renpy/sl2/slast.py", line 84, in compile_expr > return compile(expr, filename, "eval", flags, 1) > ValueError: AST node line range (628, 1) is not valid Thanks for the report. I can reproduce this problem in stable and unstable but I don't know what is causing the Python error at the moment. In any case this makes the game unusable and must be fixed eventually. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1037304: gnome-control-center: sharing non-accessible after fresh GNOME 3 installation
Package: gnome-control-center Version: 1:43.4.1-1 Severity: normal X-Debbugs-Cc: a...@debian.org I just installed GNOME 3 on a Lenovo X280 and X230i Thinkpad. I used the most recent Debian installer as of 10.06.2023 which was still an RC candidate for Bookworm. Open the gnome-control-center, click on the sharing menu item. Now the application starts to freeze and a dialogue opens whether I would like to wait or force quit the application. I waited for several minutes and retried the process but that didn't help. After removing gnome-remote-desktop, the menu item "Sharing" became accessible again. I just re-installed gnome-remote-desktop and now clicking on Sharing also works as expected which is weird. After rebooting my second Laptop Sharing also works again. Here I did not remove gnome-remote-desktop. So apparently there is something going on in the background which blocks the Sharing menu item on a very fresh GNOME 3 installation. I would have expected a more descriptive error message or that it just works TM right from the start. Regards, Markus -- System Information: Debian Release: 12.0 Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-control-center depends on: ii accountsservice 22.08.8-6 ii apg 2.2.3.dfsg.1-5+b2 ii colord1.4.6-2.2 ii desktop-base 12.0.6 ii desktop-file-utils0.26-1 ii gnome-control-center-data 1:43.4.1-1 ii gnome-desktop3-data 43.2-2 ii gnome-settings-daemon 43.0-4 ii gsettings-desktop-schemas 43.0-1 ii libaccountsservice0 22.08.8-6 ii libadwaita-1-01.2.2-1 ii libc6 2.36-9 ii libcairo2 1.16.0-7 ii libcolord-gtk4-1 0.3.0-3.1 ii libcolord21.4.6-2.2 ii libcups2 2.4.2-3 ii libepoxy0 1.5.10-1 ii libfontconfig12.14.1-4 ii libgcr-base-3-1 3.41.1-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgnome-bg-4-2 43.2-2 ii libgnome-bluetooth-ui-3.0-13 42.5-3 ii libgnome-desktop-4-2 43.2-2 ii libgnome-rr-4-2 43.2-2 ii libgnutls30 3.7.9-2 ii libgoa-1.0-0b 3.46.0-1 ii libgoa-backend-1.0-1 3.46.0-1 ii libgsound01.0.3-2 ii libgtk-3-03.24.37-2 ii libgtk-4-14.8.3+ds-2 ii libgtop-2.0-112.40.0-2 ii libgudev-1.0-0237-2 ii libibus-1.0-5 1.5.27-5 ii libkrb5-3 1.20.1-2 ii libmalcontent-0-0 0.11.0-4 ii libmm-glib0 1.20.4-1 ii libnm01.42.4-1 ii libnma-gtk4-0 1.10.6-1 ii libpango-1.0-01.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpolkit-gobject-1-0 122-3 ii libpulse-mainloop-glib0 16.1+dfsg1-2+b1 ii libpulse0 16.1+dfsg1-2+b1 ii libpwquality1 1.4.5-1+b1 ii libsecret-1-0 0.20.5-3 ii libsmbclient 2:4.17.8+dfsg-2 ii libsnapd-glib-2-1 1.63-5 ii libudisks2-0 2.9.4-4 ii libupower-glib3 0.99.20-2 ii libwacom9 2.6.0-1 ii libx11-6 2:1.8.4-2 ii libxi62:1.8-1+b1 ii libxml2 2.9.14+dfsg-1.2 ii webp-pixbuf-loader0.2.1-1 Versions of packages gnome-control-center recommends: ii cracklib-runtime 2.9.6-5+b1 ii cups-pk-helper0.2.6-1+b1 ii gkbd-capplet 3.28.1-1 ii gnome-bluetooth-sendto42.5-3 ii gnome-online-accounts 3.46.0-1 ii gnome-remote-desktop 43.3-1 ii gnome-user-docs 43.0-2 ii gnome-user-share 43.0-1 ii iso-codes 4.15.0-1 ii libcanberra-pulse 0.30-10 ii libnss-myhostname 252.6-1 ii libspa-0.2-bluetooth 0.3.65-3 ii malcontent-gui0.11.0-4 ii network-manager-gnome 1.30.0-2 ii polkitd 122-3 ii power-profiles-daemon 0.12-1+b1 ii realmd0.17.1-1 ii rygel 0.42.1-1 ii rygel-tracker 0.42.1-1 ii system-config-printer-common 1.5.18-1 Versions of packages gnome-control-center suggests: ii gnome-software 43.4-1 pn gstreamer1.0-pulseaudio ii pkexec 122-3 ii x11-xserver-utils7.7+9+b1 -- no debconf information
Bug#1015157: gnome-control-center: segfaults reproducibly on sharing panel
> We think this will be fixed in gnome-control-center 42.4 (not released yet). FTR: This is still a problem in Bookworm (43.4.1). Just did a clean GNOME 3 installation with the Debian installer and as soon as I click on the Sharing menu item in gnome-control-center, the whole application freezes. Removing gnome-remote-desktop works around the problem. signature.asc Description: This is a digitally signed message part
Bug#1009879: pypdf2: CVE-2022-24859: Manipulated inline images can cause Infinite Loop
Hi Andreas, Am Donnerstag, dem 08.06.2023 um 18:05 +0200 schrieb Andreas Beckmann: > Hi Markus, > > you took care of fixing this bug in stretch-lts. Can you look into > fixing this in buster-lts, too? Right now buster(-lts) has a lower > version than stretch-lts. Thanks! I'll take care of that soon. Markus signature.asc Description: This is a digitally signed message part
Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable
Thanks for your help and explanations Max. I am going to release an updated version for Buster soon. Apparently I somehow missed the io_kpse_check_permissions function despite following the "Patching older versions" paragraph. Best, Markus signature.asc Description: This is a digitally signed message part
Bug#1036967: fig2dev: insufficient Breaks+Replaces against transfig/jessie-elts
Am Mittwoch, dem 31.05.2023 um 14:41 +0200 schrieb Andreas Beckmann: > On 31/05/2023 14.26, Markus Koschany wrote: > > Hello Andreas, > > > > Neither fig2dev or transfig are supported in jessie-elts anymore. I > > appreciate > > the report though. Since Stretch is no longer supported by Debian I believe > > this issue is no longer actionable by the maintainer. > > Is fig2dev supported in stretch-elts? stretch-elts would be the natural > dist-upgrade target for jessie-elts. fig2dev is supported in stretch-elts but I don't think this issue warrants a separate ELA. Most customers install a certain release and keep it until it goes EOL and then they upgrade to the latest stable version anyway. signature.asc Description: This is a digitally signed message part
Bug#1036967: fig2dev: insufficient Breaks+Replaces against transfig/jessie-elts
Hello Andreas, Neither fig2dev or transfig are supported in jessie-elts anymore. I appreciate the report though. Since Stretch is no longer supported by Debian I believe this issue is no longer actionable by the maintainer. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable
Hi Hilmar, Am Dienstag, dem 30.05.2023 um 23:32 +0200 schrieb Preuße, Hilmar: > On 30.05.2023 20:37, Salvatore Bonaccorso wrote: > > Hi Salvatore, hi Markus, > > > No, buster is under LTS support which does not have point releases. > > But as I understand this is a regression from DLA DLA-3427-1, so a > > regression update might be worth to be issues for it, once there is a > > fix known. I can reproduce the problem on Buster and that it is not present on Bullseye. I don't see any patch differences though. The latex command appears to work too. This problem occurs when I install texlive-latex-base texlive-luatex from src:texlive-base. We only updated texlive-bin but the issue appears to be in texlive-base now ? Are there any major differences between those sources packages in Buster and Bullseye? I had to run mtxrun --script luatex-core.lua in src:texlive-bin to create luatex-core.c from scratch. I used the tool from Buster. Could this be the root cause of the problem? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1036894: unblock: closure-compiler/20130227+rhino-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: a...@debian.org Please unblock package closure-compiler [ Reason ] It turned out that closure-compiler would not function correctly with the latest version of librhino-java in Debian. I had to revert the previous patch to fix the FTBFS. I bundled the source package of rhino 1.7.7.2 with src:closure-compiler instead. This was the last one that worked correctly. Please see #1036249 for the full discussion. The debdiff is huge because of the new rhino sources hence why it is not attached to this bug report but I made only minimal changes to debian/rules and the build_xml.patch. [ Impact ] Half of closure-compiler's r-deps would FTBFS with a parsing error. [ Tests ] I have sucessfully rebuilt all reverse-dependencies twice. [ Risks ] Since rhino is now embedded, rebuilds are no longer required. The tool appears to work again as in February before I had to upgrade the system library of rhino. [ 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 testing unblock closure-compiler/20130227+rhino-1
Bug#1036892: unblock: tomcat9/9.0.70-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@debian.org
Please unblock package tomcat9
[ Reason ]
We can support only one major Tomcat version per release. I have
dropped all server packages and kept only the libtomcat9-java binary
package for compatibility reasons. It does not require security
support. Please see #1034824 for the full discussion.
[ Impact ]
We would have to support two major Tomcat versions in Bookworm.
[ Tests ]
I have successfully rebuilt all reverse-dependencies of
libtomcat9-java. There is currently no package in testing that
build-depends or depends on other binary packages from src:tomcat9.
[ Risks ]
None, if the test results are correct.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock tomcat9/9.0.70-2
diff -Nru tomcat9-9.0.70/debian/changelog tomcat9-9.0.70/debian/changelog
--- tomcat9-9.0.70/debian/changelog 2022-12-05 18:50:40.0 +0100
+++ tomcat9-9.0.70/debian/changelog 2023-05-27 17:51:32.0 +0200
@@ -1,3 +1,13 @@
+tomcat9 (9.0.70-2) unstable; urgency=medium
+
+ * Team upload.
+ * Drop tomcat9 server packages because only one Tomcat version is supported
+per release. Only retain libtomcat9-java because of compatibility reasons
+for now. Users are strongly encouraged to switch to Tomcat 10 instead.
+(Closes: #1034824)
+
+ -- Markus Koschany Sat, 27 May 2023 17:51:32 +0200
+
tomcat9 (9.0.70-1) unstable; urgency=medium
* New upstream release
diff -Nru tomcat9-9.0.70/debian/control tomcat9-9.0.70/debian/control
--- tomcat9-9.0.70/debian/control 2022-12-05 16:29:55.0 +0100
+++ tomcat9-9.0.70/debian/control 2023-05-27 17:51:32.0 +0200
@@ -29,67 +29,6 @@
Vcs-Browser: https://salsa.debian.org/java-team/tomcat9
Homepage: http://tomcat.apache.org
-Package: tomcat9-common
-Architecture: all
-Depends:
- default-jre-headless | java11-runtime-headless | java11-runtime,
- libtomcat9-java (>= ${source:Version}),
- ${misc:Depends}
-Description: Apache Tomcat 9 - Servlet and JSP engine -- common files
- Apache Tomcat implements the Java Servlet and the JavaServer Pages (JSP)
- specifications from Oracle, and provides a "pure Java" HTTP web
- server environment for Java code to run.
- .
- This package contains common files needed by the tomcat9 and tomcat9-user
- packages (Tomcat 9 scripts and libraries).
-
-Package: tomcat9
-Architecture: all
-Depends:
- lsb-base (>= 3.0-6),
- systemd (>= 238) | systemd-sysusers,
- systemd (>= 238) | systemd-tmpfiles,
- tomcat9-common (>= ${source:Version}),
- ucf,
- ${misc:Depends}
-Recommends:
- libtcnative-1 (>= 1.2.18)
-Suggests:
- tomcat9-admin (>= ${source:Version}),
- tomcat9-docs (>= ${source:Version}),
- tomcat9-examples (>= ${source:Version}),
- tomcat9-user (>= ${source:Version})
-Description: Apache Tomcat 9 - Servlet and JSP engine
- Apache Tomcat implements the Java Servlet and the JavaServer Pages (JSP)
- specifications from Oracle, and provides a "pure Java" HTTP web
- server environment for Java code to run.
- .
- This package contains only the startup scripts for the system-wide daemon.
- No documentation or web applications are included here, please install
- the tomcat9-docs and tomcat9-examples packages if you want them.
- Install tomcat9-user instead of this package if you don't want Tomcat to
- start as a service.
-
-Package: tomcat9-user
-Architecture: all
-Depends:
- netcat-openbsd,
- tomcat9-common (>= ${source:Version}),
- ${misc:Depends}
-Suggests:
- tomcat9 (>= ${source:Version}),
- tomcat9-admin (>= ${source:Version}),
- tomcat9-docs (>= ${source:Version}),
- tomcat9-examples (>= ${source:Version})
-Description: Apache Tomcat 9 - Servlet and JSP engine -- tools to create user
instances
- Apache Tomcat implements the Java Servlet and the JavaServer Pages (JSP)
- specifications from Oracle, and provides a "pure Java" HTTP web
- server environment for Java code to run.
- .
- This package contains files needed to create a user Tomcat instance.
- This user Tomcat instance can be started and stopped using the scripts
- provided in the Tomcat instance directory.
-
Package: libtomcat9-java
Architecture: all
Depends: libeclipse-jdt-core-java (>= 3.26.0), ${misc:Depends}
@@ -102,48 +41,4 @@
This package contains the Tomcat core classes which can be used by other
Java applications to embed Tomcat.
-Package: libtomcat9-embed-java
-Architecture: all
-Depends: libeclipse-jdt-core-java (>= 3.26.0), ${misc:Depends}
-Description: Apache Tomcat 9 - Servlet and JSP engine -- embed libraries
- Apache Tomcat implements the Java Servlet and the JavaServer Pages (JSP)
- specifications from Oracle, and provides a "pure Java" HTTP web
- server environment for Jav
Bug#1036890: unblock: jetty9/9.4.50-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@debian.org
Please unblock package jetty9
[ Reason ]
It was discovered that jetty9 would throw a ServiceConfigurationError
when running web applications. (#1036798) We couldn't find a targeted
fix to improve our tomcat10-migration.patch from the previous upload.
Time is running out hence why I have reverted back to libtomcat9-java.
[ Impact ]
Web applications will not work when using the jetty9 server package.
[ Tests ]
Confirmed that reverting back to libtomcat9-java fixes the problem.
[ Risks ]
We are back to square one.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock jetty9/9.4.50-4
diff -Nru jetty9-9.4.50/debian/changelog jetty9-9.4.50/debian/changelog
--- jetty9-9.4.50/debian/changelog 2023-02-19 13:41:00.0 +0100
+++ jetty9-9.4.50/debian/changelog 2023-05-27 16:28:19.0 +0200
@@ -1,3 +1,11 @@
+jetty9 (9.4.50-4) unstable; urgency=medium
+
+ * Team upload.
+ * Revert the switch to libtomcat10-java. For now Jetty 9 only works correctly
+with libtomcat9-java. (Closes: #1036798)
+
+ -- Markus Koschany Sat, 27 May 2023 16:28:19 +0200
+
jetty9 (9.4.50-3) unstable; urgency=medium
* Team upload.
diff -Nru jetty9-9.4.50/debian/control jetty9-9.4.50/debian/control
--- jetty9-9.4.50/debian/control2023-02-19 13:41:00.0 +0100
+++ jetty9-9.4.50/debian/control2023-05-27 16:28:19.0 +0200
@@ -29,7 +29,7 @@
libspring-beans-java,
libtaglibs-standard-impl-java,
libtaglibs-standard-spec-java,
- libtomcat10-java,
+ libtomcat9-java,
libwebsocket-api-java,
maven-debian-helper (>= 2.2.8~),
maven-repo-helper
@@ -60,7 +60,7 @@
libspring-beans-java,
libtaglibs-standard-impl-java,
libtaglibs-standard-spec-java,
- libtomcat10-java,
+ libtomcat9-java,
${misc:Depends}
Suggests: jetty9
Description: Java servlet engine and webserver -- extra libraries
diff -Nru jetty9-9.4.50/debian/jetty9.links jetty9-9.4.50/debian/jetty9.links
--- jetty9-9.4.50/debian/jetty9.links 2023-02-19 13:41:00.0 +0100
+++ jetty9-9.4.50/debian/jetty9.links 2023-05-27 16:28:19.0 +0200
@@ -50,22 +50,22 @@
usr/share/java/jetty9-xml.jar
usr/share/jetty9/lib/jetty-xml-${VERSION}.jar
usr/share/java/servlet-api.jar
usr/share/jetty9/lib/servlet-api-3.1.jar
-usr/share/java/tomcat10-annotations-api.jar
usr/share/jetty9/lib/annotations/javax.annotation.jar
+usr/share/java/tomcat9-annotations-api.jar
usr/share/jetty9/lib/annotations/javax.annotation.jar
usr/share/java/asm.jar
usr/share/jetty9/lib/annotations/asm.jar
usr/share/java/asm-analysis.jar
usr/share/jetty9/lib/annotations/asm-analysis.jar
usr/share/java/asm-commons.jar
usr/share/jetty9/lib/annotations/asm-commons.jar
usr/share/java/asm-tree.jar
usr/share/jetty9/lib/annotations/asm-tree.jar
usr/share/java/eclipse-jdt-core.jar
usr/share/jetty9/lib/apache-jsp/jdt-core.jar
-usr/share/java/tomcat10-api.jar
usr/share/jetty9/lib/apache-jsp/tomcat-api.jar
-usr/share/java/tomcat10-el-api.jar
usr/share/jetty9/lib/apache-jsp/tomcat-el-api.jar
-usr/share/java/tomcat10-jasper.jar
usr/share/jetty9/lib/apache-jsp/tomcat-jasper.jar
-usr/share/java/tomcat10-jasper-el.jar
usr/share/jetty9/lib/apache-jsp/tomcat-jasper-el.jar
-usr/share/java/tomcat10-jsp-api.jar
usr/share/jetty9/lib/apache-jsp/tomcat-jsp-api.jar
-usr/share/java/tomcat10-juli.jar
usr/share/jetty9/lib/apache-jsp/tomcat-juli.jar
-usr/share/java/tomcat10-util.jar
usr/share/jetty9/lib/apache-jsp/tomcat-util.jar
-usr/share/java/tomcat10-util-scan.jar
usr/share/jetty9/lib/apache-jsp/tomcat-util-scan.jar
+usr/share/java/tomcat9-api.jar
usr/share/jetty9/lib/apache-jsp/tomcat-api.jar
+usr/share/java/tomcat9-el-api.jar
usr/share/jetty9/lib/apache-jsp/tomcat-el-api.jar
+usr/share/java/tomcat9-jasper.jar
usr/share/jetty9/lib/apache-jsp/tomcat-jasper.jar
+usr/share/java/tomcat9-jasper-el.jar
usr/share/jetty9/lib/apache-jsp/tomcat-jasper-el.jar
+usr/share/java/tomcat9-jsp-api.jar
usr/share/jetty9/lib/apache-jsp/tomcat-jsp-api.jar
+usr/share/java/tomcat9-juli.jar
usr/share/jetty9/lib/apache-jsp/tomcat-juli.jar
+usr/share/java/tomcat9-util.jar
usr/share/jetty9/lib/apache-jsp/tomcat-util.jar
+usr/share/java/tomcat9-util-scan.jar
usr/share/jetty9/lib/apache-jsp/tomcat-util-scan.jar
usr/share/java/taglibs-standard-spec.jar
usr/share/jetty9/lib/apache-jstl/org.apache.taglibs.taglibs-standard-spec.jar
usr/share/java/tagl
Bug#1036740: [Pkg-netatalk-devel] Bug#1036740: Fix for CVE-2022-23123 causes afpd segfault with valid metadata
Am Donnerstag, dem 25.05.2023 um 19:22 -0700 schrieb Daniel Markstedt: > [...] > Thank you very much for taking swift action on this! > Please forgive my ignorance here, but are these patches active already > if I apt install netatalk (3.1.12~ds-3+deb10u1) on Buster? > Or do they have to be picked up by some build process that hasn't run yet? Those patches are already applied. You can download the source package of netatalk with apt source netatalk They are located in the debian/patches directory and are listed in the debian/patches/series file. > > I'm asking because I ran a few tests now and while EA metadata works, > the appledouble v2 metadata functionality is definitely broken, even > when you create a new shared volume from scratch. > > dmark@buster:~$ apt show netatalk > Package: netatalk > Version: 3.1.12~ds-3+deb10u1 > ... > May 25 18:51:08 buster afpd[7415]: ad->ad_ops->ad_header_read(path, > ad, pst) failed: Input/output error > May 25 18:51:08 buster afpd[7415]: getfilparams(Screenshot 2023-05-23 > at 10.36.39 AM.png): bad resource fork > May 25 18:51:08 buster afpd[7415]: parse_entries: bogus eid: 3, off: 182, > len: 8 > May 25 18:51:08 buster afpd[7415]: > ad_header_read(/home/dmark/afp-data): malformed AppleDouble > > So either more patches have to be cherry-picked or I need to be patient. :) Could you tell me which exact commands were used, so that I can try to reproduce the problem? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
Am Freitag, dem 26.05.2023 um 21:44 +0200 schrieb Emmanuel Bourg: > > The changes to jetty9 have to be reverted too, the package is broken > (#1036798). > > Sadly we can't do without tomcat9. The path forward implies packaging > Jetty 11 or 12 first and migrating all the reverse dependencies, but > that's a task for Trixie. Thanks for investigating Emmanuel. I'll take care of jetty9 too. Markus signature.asc Description: This is a digitally signed message part
Bug#1036778: ckbuilder: must be rebuilt against rhino 1.7.14
Hi, I have just rebuilt all reverse-dependencies of closure-compiler again, ckbuilder and ckeditor also build fine now. Thus the upload of ckbuilder 2.4.3+dfsg-2 was successful. > Should we clone this bug to ensure we have a proper (tracking) solution > after the bookworm release. If binaries need rebuilds for new versions > of build dependencies, we need to figure out how we can automatically > detect that. One way (very unpretty) is to hardcode the version which > it's going to be build against, than dose [1] will at least tell us. That's a good idea. In general the Javascript maintainers should be more considerate when it comes to packages like rhino or closure-compiler. The latter has been neglected for ten years but still many Javascript packages depend on it. It is only a matter of time when other issues in closure-compiler will surface. > > > The rebuild should be done after #1036249 in closure-compiler has been > > resolved. > > Which is not the case yet, is the 2.4.3+dfsg-2 upload futile and should > this bug be reopened? (To be safe, I'm reopening now). @yadd If you haven't done so already, could you please file an unblock request for ckbuilder? Thanks Markus signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
Hi, > Markus, can you please revert you logback change by tomorrow at the latest? Sure. I will take care if it. Do I understand you correctly, that we only ship libtomcat9-java in Bookworm now? Shall I upload a new revision of tomcat9 too? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
First of all trapperkeeper-webserver-jetty9-clojure should add a build- dependency on logback to detect such regressions in advance. #1036250 is mainly a logback problem, not a tomcat problem. I still would like to hear Emmanuel's opinion. We still could revert to libtomcat9-java, if we don't find a solution though. The tomcatjss / dogtag-pki situation is simple too. If there is no way to make the application work with Tomcat 10, then there are three options: 1. Embed Tomcat 9 in your application by creating a standalone jar 2. Continue to use the current Tomcat 9 package as is but make sure that nobody else than dogtag-pki uses it. (Package descriptions should be adjusted, and the binary tomcat9 package should be probably removed too) Nobody should think that we support two major Tomcat versions. In any case the dogtag-pki maintainers must commit to at least three years of security support, web application + Tomcat 9. Otherwise this is pointless. 3. Remove dogtag-pki and tomcatjss from testing and prepare backports as soon as dogtag-pki and Co support Tomcat 10. Markus signature.asc Description: This is a digitally signed message part
Bug#1036249: closure-compiler: #1036249
Sorry, that should have been #1036249. signature.asc Description: This is a digitally signed message part
Bug#1036249: closure-compiler: #1036159
Control: tags -1 patch Hello, I have been working on #1036159 and before I go ahead with my solution I would like to hear your opinion whether this is acceptable. Apparently closure-compiler embeds rhino classes and thus every time rhino is updated, closure-compiler must be rebuilt too. I did just that in revision -14 but still half of the reverse-dependencies FTBFS because of a parsing error. I tried to narrow this issue down and even reverted a commit in rhino which made closure-compiler FTBFS. We addressed the initial FTBFS in revision -13. Still that made no difference. Although rhino 1.7.14 and our ten year old closure- compiler package are seemingly compatible at the source level, there must be some subtle differences which cause the Javascript parsing errors. Since I could not find a targeted fix I decided to remove the dependency on rhino 1.7.14 and embedded rhino 1.7.7.2 instead, the last version that worked well for closure-compiler. You can find the results here: https://salsa.debian.org/java-team/closure-compiler/-/tree/bookworm I have rebuilt all reverse-dependencies and this would resolve the problem. The only exception is ckbuilder / ckeditor. The solution here is simple though. ckbuilder must be rebuilt against rhino 1.7.14. This is the original solution for #1026639 but the rebuilding part was forgotten. I have filed #1036778 as a reminder. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1036778: ckbuilder: must be rebuilt against rhino 1.7.14
Source: ckbuilder Version: 2.4.3+dfsg-1 Severity: serious X-Debbugs-Cc: a...@debian.org ckbuilder must be rebuilt against rhino 1.7.14. This is a no-change rebuild. Otherwise ckeditor will continue to FTBFS. This was already reported in #1026639. This issue has also been reported upstream as https://github.com/ckeditor/ckbuilder/issues/34 Back then we decided to upgrade rhino but in fact ckbuilder could have also added the --add-exports java.desktop/sun.java2d=ALL-UNNAMED flag. The rebuild should be done after #1036249 in closure-compiler has been resolved.
Bug#1036740: Fix for CVE-2022-23123 causes afpd segfault with valid metadata
Hello Daniel, Am Donnerstag, dem 25.05.2023 um 08:02 +0200 schrieb Salvatore Bonaccorso: > > > > These two commits in upstream addressed this: > > https://github.com/Netatalk/netatalk/commit/9d0c21298363e8174cdfca657e66c4d10819507b > > https://github.com/Netatalk/netatalk/commit/4140e5495bac42ecb9b11975229c81e84762cc98 Both patches have been backported to Buster. You can find them as CVE-2022- 23123_part3.patch and CVE-2022-23123_part4.patch. Did we miss something else? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1036249: reopen #1036249
I have identified the rhino upstream commit which caused the FTBFS in closure- compiler. If I revert said commit in rhino, then closure-compiler builds from source without any additional patches needed. https://github.com/mozilla/rhino/commit/fb77164ac4889ffa4be26d5d24cb538a8dbd632b However I still see the same runtime errors when I compile closure-compiler against this new rhino version. At the moment I am running out of ideas. Given that we approach full freeze in a few days, I am inclined to ship the last rhino version that worked for closure-compiler and bundle it together with src:closure-compiler. That should ensure all reverse-dependencies can be built from source again. We also don't have to touch src:rhino again. After the Bookworm release I recommend to file an RC bug against closure- compiler to ensure that someone either maintains it properly or it gets removed from Debian. Currently src:rhino already ships patches to maintain compatibility with a 10 year old version of closure-compiler and the burden should not be placed on other maintainers to keep it in Debian. signature.asc Description: This is a digitally signed message part
Bug#1036249: reopen #1036249
reopen 1036249 thanks The missing source files have been included with revision -14. Apparently closure-compiler embeds rhino classes but renames them to avoid conflicts. There is still a parsing error when closure-compiler tries to optimize Javascript files at runtime. E.g. ERROR - Parse error. Unsupported syntax: COMMENT This is likely related to src/com/google/javascript/jscomp/parsing/IRFactory.java method Node processUnaryExpression This was the only part of the code that failed to build with rhino 1.7.14. My patch to fix the FTBFS was incomplete and I am currently looking into a better solution. signature.asc Description: This is a digitally signed message part
Bug#1036250: trapperkeeper-webserver-jetty9-clojure: FTBFS in testing: MDCAccessLogConverter.java:54: error: cannot access HttpServletRequest
Control: tags -1 patch Hi, I am attaching a patch for this issue. Somehow your package fell through the cracks because it has no dependency on logback. Logback is pulled in by Jetty though. While Logback and Jetty use the Jakarta servlet API now, your package still depends on libservlet-api-java. The fix for that was trivial. However the test failure is caused by my tomcat10-migration.patch https://salsa.debian.org/java-team/logback/-/blob/master/debian/patches/tomcat10-migration.patch#L91 Back then I thought it was acceptable to work around a build failure by setting the accessEvent variable to null since it seemed no package existed in Debian which would be affected by it. The Logback developers fixed that problem in newer versions, but a new upstream release of logback would have been too intrusive. Long story short: please double-check my patch and if we can ignore the logging problem Regards, Markus diff -Nru trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/changelog trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/changelog --- trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/changelog 2023-02-10 23:15:30.0 +0100 +++ trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/changelog 2023-05-19 15:19:10.0 +0200 @@ -1,3 +1,14 @@ +trapperkeeper-webserver-jetty9-clojure (4.4.1-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Replace libservlet-api-java with libjakarta-servlet-api-java. + * Add jakarta.servlet.patch to fix FTBFS with latest Jetty and Logback +versions in Debian. (Closes: #1036250) + * Work around a test failure by disabling request-logging-test. +(Closes: #1034855) + + -- Markus Koschany Fri, 19 May 2023 15:19:10 +0200 + trapperkeeper-webserver-jetty9-clojure (4.4.1-5) unstable; urgency=medium * d/control: bump Breaks: on puppetserver diff -Nru trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/control trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/control --- trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/control 2023-02-10 23:15:30.0 +0100 +++ trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/control 2023-05-19 15:19:10.0 +0200 @@ -15,7 +15,7 @@ libtools-logging-clojure, libjanino-java, libordered-clojure, - libservlet-api-java, + libjakarta-servlet-api-java, libjetty9-java, libjetty9-extra-java, libprismatic-schema-clojure (>= 1.1.12), diff -Nru trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/libtrapperkeeper-webserver-jetty9-clojure.classpath trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/libtrapperkeeper-webserver-jetty9-clojure.classpath --- trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/libtrapperkeeper-webserver-jetty9-clojure.classpath 2023-02-10 23:15:30.0 +0100 +++ trapperkeeper-webserver-jetty9-clojure-4.4.1/debian/libtrapperkeeper-webserver-jetty9-clojure.classpath 2023-05-19 15:19:10.0 +0200 @@ -1 +1 @@ -usr/share/java/trapperkeeper-webserver-jetty9.jar /usr/share/java/clojure.jar /usr/share/java/java.jmx.jar /usr/share/java/tools.logging.jar /usr/share/java/janino.jar /usr/share/java/servlet-api.jar /usr/share/java/jetty9-server.jar /usr/share/java/jetty9-io.jar /usr/share/java/jetty9-security.jar /usr/share/java/jetty9-client.jar /usr/share/java/jetty9-servlet.jar /usr/share/java/jetty9-http.jar /usr/share/java/jetty9-util.jar /usr/share/java/jetty9-servlets.jar /usr/share/java/jetty9-webapp.jar /usr/share/java/jetty9-proxy.jar /usr/share/java/jetty9-jmx.jar /usr/share/java/jetty9-websocket-server.jar /usr/share/java/jetty9-websocket-api.jar /usr/share/java/jetty9-websocket-servlet.jar /usr/share/java/schema.jar /usr/share/java/ring-servlet.jar /usr/share/java/ring-codec.jar /usr/share/java/ssl-utils.jar /usr/share/java/kitchensink.jar /usr/share/java/trapperkeeper.jar /usr/share/java/puppetlabs-i18n.jar /usr/share/java/trapperkeeper-filesystem-watcher.jar /usr/share/java/jul-to-slf4j.jar +usr/share/java/trapperkeeper-webserver-jetty9.jar /usr/share/java/clojure.jar /usr/share/java/java.jmx.jar /usr/share/java/tools.logging.jar /usr/share/java/janino.jar /usr/share/java/jakarta-servlet-api.jar /usr/share/java/jetty9-server.jar /usr/share/java/jetty9-io.jar /usr/share/java/jetty9-security.jar /usr/share/java/jetty9-client.jar /usr/share/java/jetty9-servlet.jar /usr/share/java/jetty9-http.jar /usr/share/java/jetty9-util.jar /usr/share/java/jetty9-servlets.jar /usr/share/java/jetty9-webapp.jar /usr/share/java/jetty9-proxy.jar /usr/share/java/jetty9-jmx.jar /usr/share/java/jetty9-websocket-server.jar /usr/share/java/jetty9-websocket-api.jar /usr/share/java/jetty9-websocket-servlet.jar /usr/share/java/schema.jar /usr/share/java/ring-servlet.jar /usr/share/java/ring-codec.jar /usr/share/java/ssl-utils.jar /usr/share/java/kitchensink.jar /usr/share/java/trapperkeeper.jar /usr/share/java/puppetlabs-i18n.jar /usr/share/java/trapperkeeper-filesystem-watcher.jar /usr/share/java/jul-to-slf4j.jar diff -Nru trapperkeeper-webserver-jetty9-clojure-4.
Bug#1036244: unblock: noiz2sa/0.51a-13
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: a...@debian.org Please unblock package noiz2sa [ Reason ] A long time ago noiz2sa shipped a symlink from the noiz2sa-data /usr/share/doc directory to its arch-any /usr/share/doc directories to save 0.14159265359 KB of disk space. "This kind of overwriting another package's files cannot be detected by dpkg." And that's why we have to use dpkg-maintscript-helper to fix this issue. See also #1035632. [ Impact ] noiz2sa will be autoremoved. [ Tests ] piuparts agrees, it's all good now [ Risks ] A couple of nerds would be not amused to find out, that they cannot play their favorite game in Bookworm. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock noiz2sa/0.51a-13 diff -Nru noiz2sa-0.51a/debian/changelog noiz2sa-0.51a/debian/changelog --- noiz2sa-0.51a/debian/changelog 2021-11-02 14:55:01.0 +0100 +++ noiz2sa-0.51a/debian/changelog 2023-05-14 15:10:17.0 +0200 @@ -1,3 +1,10 @@ +noiz2sa (0.51a-13) unstable; urgency=medium + + * Add noiz2sa.maintscript: Handle symlink to directory conversion. +Thanks to Andreas Beckmann for the report. (Closes: #1035632) + + -- Markus Koschany Sun, 14 May 2023 15:10:17 +0200 + noiz2sa (0.51a-12) unstable; urgency=medium * d/control: Add Vcs fields. diff -Nru noiz2sa-0.51a/debian/noiz2sa.maintscript noiz2sa-0.51a/debian/noiz2sa.maintscript --- noiz2sa-0.51a/debian/noiz2sa.maintscript1970-01-01 01:00:00.0 +0100 +++ noiz2sa-0.51a/debian/noiz2sa.maintscript2023-05-14 15:10:17.0 +0200 @@ -0,0 +1 @@ +symlink_to_dir /usr/share/doc/noiz2sa noiz2sa-data 0.51a-13~
Bug#1036212: visualvm: Version 2.1.5 doesn't work with Java 17
Am Mittwoch, dem 17.05.2023 um 12:24 +0200 schrieb david: > Package: visualvm > Version: Version 2.1.5 doesn't work with Java 17 > Severity: normal > > Dear Maintainer, > > I have installed visualvm with Java 17 configured. The app doesn't work in > its > installed version. Trying 2.1.6, downloaded from visualvm web page, it works > without problem. Can we have this last version, please? visualvm 2.1.5 works with Java 17 signature.asc Description: This is a digitally signed message part
Bug#1036093: unblock: pokerth/1.1.2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@debian.org
Please unblock package pokerth
[ Reason ]
pokerth depends on gsfonts-x11 which has been replaced by
fonts-urw-base35. Some fonts names changed and symlinks pointing to
the old fonts no longer worked as expected. (#1020237) However after
looking into this issue, I discovered that those fonts are no longer
required. They were intended as a fallback solution but upstream
removed them years ago. There is also still DejaVuSans-Bold.ttf which
should suffice as well. Since it made no difference, I simply removed the
dependency on gsfonts-x11.
[ Impact ]
pokerth in testing would be shipped with dangling symlinks.
[ Tests ]
The game looks identical with or without those fonts.
[ Risks ]
None, since gsfonts-x11 is just obsolete
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock pokerth/1.1.2-2
diff -Nru pokerth-1.1.2/debian/changelog pokerth-1.1.2/debian/changelog
--- pokerth-1.1.2/debian/changelog 2020-12-19 19:37:17.0 +0100
+++ pokerth-1.1.2/debian/changelog 2023-05-15 00:44:03.0 +0200
@@ -1,3 +1,14 @@
+pokerth (1.1.2-2) unstable; urgency=medium
+
+ * Team upload.
+ * No longer depend on gsfonts-x11 which is replaced by fonts-urw-base35.
+We don't need these fonts because we still have DejaVuSans which is the
+better alternative. (Closes: #1020237)
+ * Remove the symlinks to gsfonts-x11 fonts.
+ * Rename VeraBd.ttf symlink to DejaVuSans-Bold.ttf.
+
+ -- Markus Koschany Mon, 15 May 2023 00:44:03 +0200
+
pokerth (1.1.2-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru pokerth-1.1.2/debian/control pokerth-1.1.2/debian/control
--- pokerth-1.1.2/debian/control2020-12-19 19:33:12.0 +0100
+++ pokerth-1.1.2/debian/control2023-05-15 00:44:03.0 +0200
@@ -65,7 +65,6 @@
Architecture: all
Depends:
fonts-dejavu-core,
- gsfonts-x11,
${misc:Depends}
Description: Texas hold'em game - common data files
pokerth is a free implementation of the Texas hold'em poker game which is
diff -Nru pokerth-1.1.2/debian/pokerth-data.links
pokerth-1.1.2/debian/pokerth-data.links
--- pokerth-1.1.2/debian/pokerth-data.links 2018-10-02 15:35:20.0
+0200
+++ pokerth-1.1.2/debian/pokerth-data.links 2023-05-15 00:44:03.0
+0200
@@ -1,3 +1 @@
-/usr/share/fonts/X11/Type1/c059013l.pfb
/usr/share/games/pokerth/fonts/c059013l.pfb
-/usr/share/fonts/X11/Type1/n019003l.pfb
/usr/share/games/pokerth/fonts/n019003l.pfb
-/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
/usr/share/games/pokerth/fonts/VeraBd.ttf
+/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
/usr/share/games/pokerth/fonts/DejaVuSans-Bold.ttf
Bug#1035995: bazel-bootstrap: Depend on libgeronimo-annotation-1.3-spec-java instead of libtomcat9-java
Control: tags -1 patch Hi, bazel-bootstrap already build-depends on libgeronimo-annotation-1.3-spec-java. The fix is trivial. Patch is attached. Regards, Markus signature.asc Description: This is a digitally signed message part
