Bug#924397: corekeeper: insecure use of world-writable /var/crash
On Wed, 13 Mar 2019 20:31:12 +0800 Paul Wise wrote: > Hmm, so the upgrade has to deal with that automatically in a variety of > situations. This is going to be annoying, maybe it should just change > the permissions in the postinst based on the core pattern sysctl? Do you have any suggestions for how to deal with the postinst permissions update? I'm guessing it should just update the permissions on upgrade between the two versions and not if a statoverride is set? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#924291: marked as done (netrek-client-cow: build can loop indefinitely on failure)
Your message dated Thu, 21 Mar 2019 00:50:38 + with message-id and subject line Bug#924291: fixed in netrek-client-cow 3.3.1-2 has caused the Debian Bug report #924291, regarding netrek-client-cow: build can loop indefinitely on failure to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 924291: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924291 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: netrek-client-cow Version: 3.3.1-1 Severity: serious Justification: breaks build infrastructure When mkkey fails to run, netrek-client-cow has a very bad failure mode. It loops until mkkey succeeds: | until ./mkkey key.cow.linux "Client Of Win" "automatic packaged key" "qu...@us.netrek.org" "netrek.org/files/COW/" "inl,standard2"; do sleep 1; done When mkkey fails reliably and produces output, this causes the build to run indefinitely as sbuild only abort a build that has no output for a prologned time. This behaviour can make buildds and QA infrastructure hang. I suggest using a bounded loop and failing hard after a number of attempts. That's a very simple solution to the problem at hand. For instance: | attempts=32; until ./mkkey ...; do attempts=$((attempts - 1)); test $attempts -le 0 && exit 1; sleep 1; done Furthermore I question why a key should be created at build time and then be distributed to consumers of the package. That seems to run counter to the concept of a "key". If the key is to protect anything, it must not be public. Maybe the best course of action would be not creating this key at all during build. Helmut --- End Message --- --- Begin Message --- Source: netrek-client-cow Source-Version: 3.3.1-2 We believe that the bug you reported is fixed in the latest version of netrek-client-cow, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 924...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Markus Koschany (supplier of updated netrek-client-cow package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 20 Mar 2019 21:31:57 +0100 Source: netrek-client-cow Architecture: source Version: 3.3.1-2 Distribution: unstable Urgency: medium Maintainer: Debian Games Team Changed-By: Markus Koschany Closes: 924291 Changes: netrek-client-cow (3.3.1-2) unstable; urgency=medium . * Team upload. * Fix possible infinite loop. (Closes: #924291) * Move the package to salsa.debian.org. Checksums-Sha1: 8340e4036998c3c3a35eee94837d050cde1c8af5 2244 netrek-client-cow_3.3.1-2.dsc b68b6c0421a50911e0707621b3f97ce8d2c18fea 7076 netrek-client-cow_3.3.1-2.debian.tar.xz 3a1533e687f3bffc40e02b2596fa7100e5e2a01e 11613 netrek-client-cow_3.3.1-2_amd64.buildinfo Checksums-Sha256: 10da3134d9d48d43c4a2bc6e6adc71e531594dd569740b96498077921bb55df5 2244 netrek-client-cow_3.3.1-2.dsc 57d273ba54b6e69f6dd438b100a3c06200301010015d834b772f9a75909e78fd 7076 netrek-client-cow_3.3.1-2.debian.tar.xz 8b902688ca12292d3e23ed282727548039ef3239a2b9901fdc20bcdae5b9cc1d 11613 netrek-client-cow_3.3.1-2_amd64.buildinfo Files: c5e6a7ebf87b30fb876a981f741f969c 2244 games optional netrek-client-cow_3.3.1-2.dsc fa123d743932fdc64bfb481c40924ade 7076 games optional netrek-client-cow_3.3.1-2.debian.tar.xz d4e901bd7fd92e2f828304c4e98ccb9e 11613 games optional netrek-client-cow_3.3.1-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQKjBAEBCgCNFiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAlyS141fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQPHGFwb0BkZWJp YW4ub3JnAAoJENmtFLlRO1HkbpQQAMzNPIcST5Zlfov9hLmPzYPdnnfuwMg7gIvK Lz1LHGjqn7UlrFenX7w9WBChO+YyFERO/NEknmQOfWZpFfLX49GDrBS5Xi6/HdCN wTN8R+ykrtxslTpDiJuqgdxudLlPtDJBWpAWpnfwyMdZQH5ws7BcUJz44eQmR9dm 0nAHoa+7SNTzdXenR9A1huDIyZ5jdSPeQPpf25fIW1eC786tDTyZEPyTPTb0ab3E 6CBdeoRHecT3uyJJdzxR2gKIegj6lqg0FtjVO/m1h2m+zFM+OHijxkzq2xT9QQ4Z PGs6nzGOF3MzCYww02KTtuqPUniVhs4/ruxjVaQOJqbxOIPSKDLWrQRGqKW2trCL uKjFEGMa7LvxIUhEtRMyxusS7HDuOIVBe94Cv/8q5ILCC8uL9I3ZHIJfJGTkwg+/ 8xsnLFQ3EQ4vqtilyv79iVtLJmWs/7FaVyg+1aIq4YHreOYChzKstZvA+6/HegBm AINDTujySAU2HspG8mtgvNNtfcLH45fNIfmwQ+Z2E7wR5HzzKncg7+tgOCLw36RI
Bug#924583: spamassassin: razor2 had unknown error during get_server_info at /usr/share/perl5/Mail/SpamAssassin/Plugin/Razor2.pm line 186
I have received a response from cloudmark and they appear to have fixed the issue. $ telnet 208.83.139.205 2703 Trying 208.83.139.205... Connected to 208.83.139.205. Escape character is '^]'. sn=D=670=l=cg a=g=csl -csl=? c302.cloudmark.com c303.cloudmark.com c301.cloudmark.com . a=g=nsl -nsl=? n004.cloudmark.com n002.cloudmark.com n001.cloudmark.com n003.cloudmark.com ~$ telnet 208.83.137.117 2703 Trying 208.83.137.117... Connected to 208.83.137.117. Escape character is '^]'. sn=D=670=l=cg a=g=csl -csl=? c302.cloudmark.com c303.cloudmark.com c301.cloudmark.com . a=g=nsl -nsl=? n002.cloudmark.com n003.cloudmark.com n004.cloudmark.com n001.cloudmark.com . $ telnet 208.83.137.118 2703 Trying 208.83.137.118... Connected to 208.83.137.118. Escape character is '^]'. sn=D=670=l=cg a=g=csl -csl=? c301.cloudmark.com c303.cloudmark.com c302.cloudmark.com . a=g=nsl -nsl=? n001.cloudmark.com n003.cloudmark.com n002.cloudmark.com n004.cloudmark.com .
Processed: tagging 909417
Processing commands for cont...@bugs.debian.org: > tags 909417 + patch Bug #909417 [src:gtk-vnc] gtk-vnc: FTBFS randomly (vncconnectiontest fails with "assertion failed") Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 909417: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909417 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#909417: gtk-vnc: FTBFS randomly (vncconnectiontest fails with "assertion failed")
On Sat, Mar 09, 2019 at 07:26:52PM +0100, Santiago Vila wrote:
> Whoever wants to reproduce this (and possibly debug it), *please*
> contact me privately and I will gladly provide ssh access to a machine
> where it happens very often.
I've looked briefly into this.
First, to reproduce this reliably, simply restrict it to one core
(taskset -c 0 /build/gtk3/src/vncconnectiontest). The reason will be fairly
clear from the text below.
As far as I can see, this test simulates a broken VNC server (to test the
client's robustness). It says it's got a 100x100 true color display, but then
goes on and starts sending a color map.
As soon as the client receives the information about the color map,
it realizes something is wrong, and a race starts. Now the client wants to
close the connection at the same time as the fake server wants to keep
sending the cmap data. If you've got two cores, the server just keeps on
sending data happily; by the time it's noticed that the client is gone,
the test has passed and all is fine. But if you've only got one, then the
first byte of the cmap causes a context switch over to the client, which then
gets ample time to read the data and close the socket before the server gets
to send the next byte. The server thus gets EPIPE, and test_send_u16()
breaks.
I believe the right fix is to send every byte after the first “set color map”
byte using a non-asserting send. When we've done something invalid, we'd
better be ready for sending data to fail.
Please try the attached diff; it fixes the problem for me. I can NMU if the
maintainers want.
/* Steinar */
--
Homepage: https://www.sesse.net/
Index: gtk-vnc-0.9.0/src/vncconnectiontest.c
===
--- gtk-vnc-0.9.0.orig/src/vncconnectiontest.c
+++ gtk-vnc-0.9.0/src/vncconnectiontest.c
@@ -56,12 +56,23 @@ static void test_send_u8(GOutputStream *
g_assert(g_output_stream_write_all(os, , 1, NULL, NULL, NULL));
}
+static void send_u8(GOutputStream *os, guint8 v)
+{
+g_output_stream_write_all(os, , 1, NULL, NULL, NULL);
+}
+
static void test_send_u16(GOutputStream *os, guint16 v)
{
v = GUINT16_TO_BE(v);
g_assert(g_output_stream_write_all(os, , 2, NULL, NULL, NULL));
}
+static void send_u16(GOutputStream *os, guint16 v)
+{
+v = GUINT16_TO_BE(v);
+g_output_stream_write_all(os, , 2, NULL, NULL, NULL);
+}
+
static void test_send_u32(GOutputStream *os, guint32 v)
{
v = GUINT32_TO_BE(v);
@@ -429,18 +440,18 @@ static void test_unexpected_cmap_server(
test_recv_u16(is, 100);
test_recv_u16(is, 100);
-/* set color map */
+/* set color map -- after this, the client may close the connection at any time */
test_send_u8(os, 1);
/* pad */
-test_send_u8(os, 0);
+send_u8(os, 0);
/* first color, ncolors */
-test_send_u16(os, 0);
-test_send_u16(os, 1);
+send_u16(os, 0);
+send_u16(os, 1);
/* r,g,b */
-test_send_u16(os, 128);
-test_send_u16(os, 128);
-test_send_u16(os, 128);
+send_u16(os, 128);
+send_u16(os, 128);
+send_u16(os, 128);
}
@@ -505,11 +516,13 @@ static void test_overflow_cmap_server(GI
test_send_u16(os, 65535);
test_send_u16(os, 2);
+/* after this, the client may close the connection at any time */
+
/* r,g,b */
for (int i = 0 ; i < 2; i++) {
-test_send_u16(os, i);
-test_send_u16(os, i);
-test_send_u16(os, i);
+send_u16(os, i);
+send_u16(os, i);
+send_u16(os, i);
}
}
Bug#909865: diff for 2.2.1-4.1 NMU
Hi, I've uploaded an NMU for this bug in DELAYED/7-day. Please see the attached diff. /* Steinar */ -- Homepage: https://www.sesse.net/ diff -Nru openexr-2.2.1/debian/changelog openexr-2.2.1/debian/changelog --- openexr-2.2.1/debian/changelog 2018-03-11 14:10:23.0 +0100 +++ openexr-2.2.1/debian/changelog 2019-03-20 22:40:43.0 +0100 @@ -1,3 +1,11 @@ +openexr (2.2.1-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * bug909865.patch: Add -ffloat-store when compiling tests, to fix test +failures on i386. Patch backported from experimental. (Closes: #909865) + + -- Steinar H. Gunderson Wed, 20 Mar 2019 22:40:43 +0100 + openexr (2.2.1-4) unstable; urgency=medium * Upload to unstable diff -Nru openexr-2.2.1/debian/patches/bug909865.patch openexr-2.2.1/debian/patches/bug909865.patch --- openexr-2.2.1/debian/patches/bug909865.patch 1970-01-01 01:00:00.0 +0100 +++ openexr-2.2.1/debian/patches/bug909865.patch 2019-03-20 22:40:02.0 +0100 @@ -0,0 +1,17 @@ +Description: Usual double rounding issue with x87 +Author: Mathieu Malaterre +Bug-Debian: https://bugs.debian.org/909865 +Forwarded: https://github.com/openexr/openexr/issues/346 +Last-Update: 2018-12-19 + +--- openexr-2.3.0.orig/IlmImfTest/Makefile.am openexr-2.3.0/IlmImfTest/Makefile.am +@@ -54,6 +54,8 @@ IlmImfTest_SOURCES = main.cpp tmpDir.h t + + AM_CPPFLAGS = -DILM_IMF_TEST_IMAGEDIR=\"$(srcdir)/\" + ++AM_CPPFLAGS += -ffloat-store ++ + if BUILD_IMFHUGETEST + IlmImfTest_SOURCES += testDeepScanLineHuge.cpp testDeepScanLineHuge.h + AM_CPPFLAGS += -DENABLE_IMFHUGETEST diff -Nru openexr-2.2.1/debian/patches/series openexr-2.2.1/debian/patches/series --- openexr-2.2.1/debian/patches/series 2018-02-19 23:18:13.0 +0100 +++ openexr-2.2.1/debian/patches/series 2019-03-20 22:40:02.0 +0100 @@ -9,3 +9,4 @@ bigendian_step2.patch bug815594.patch #CVE-2017-911x.patch +bug909865.patch
Bug#924916: RM: python-django-openstack-auth -- RoM; provided by python3-django-horizon
On 3/19/19 2:49 PM, Andreas Beckmann wrote: > On 2019-03-18 15:29, Thomas Goirand wrote: >> On 3/18/19 12:56 PM, Andreas Beckmann wrote: >>> I'm again investigating openstack-dashboard related upgrade failures. > >> Indeed, django-openstack-auth has been removed upstream and included >> directly in django-horizon. I'm not sure what's the best way to get >> completely rid of it on upgrades and get Horizon the best way >> possible... I thought I did well, but you're telling me the opposite. >> So, any advice would be welcome. > > I just reran the openstack-dashboard upgrade test locally which now > succeeded. The removal from sid (which propagated to testing already) > seems to have been sufficient to no longer give apt the opportunity to > take a wrong decision :-) Haaa! Nice news. Thanks for taking the time to investigate. Cheers, Thomas Goirand (zigo)
Bug#925155: marked as done (Build on all release critical platforms)
Your message dated Wed, 20 Mar 2019 20:38:48 + with message-id and subject line Bug#925155: fixed in kdepim-runtime 4:18.08.3-2 has caused the Debian Bug report #925155, regarding Build on all release critical platforms to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 925155: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925155 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: ftp.debian.org Severity: normal The fix for #910731 indroduces new depdendencies: akonadi-server and kdepim-runtime. kdepim-runtime is not available for a lot of archs, as it depdends on qtwebengine-opensource-src. So unfortunatelly I need to request the removal of kaddressbook for [armel, mips, mips64el, ppc64el, s390x] to let kaddressbook to migrate to Buster. regards, hefee (part of the Qt/KDE mantainer team) --- End Message --- --- Begin Message --- Source: kdepim-runtime Source-Version: 4:18.08.3-2 We believe that the bug you reported is fixed in the latest version of kdepim-runtime, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 925...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Sandro Knauß (supplier of updated kdepim-runtime package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 20 Mar 2019 21:20:53 +0100 Source: kdepim-runtime Architecture: source Version: 4:18.08.3-2 Distribution: unstable Urgency: medium Maintainer: Debian/Kubuntu Qt/KDE Maintainers Changed-By: Sandro Knauß Closes: 925155 Changes: kdepim-runtime (4:18.08.3-2) unstable; urgency=medium . * Team upload. . [ Sandro Knauß ] * Fix "Build on all release critical platforms" (Closes: #925155) - Add patch to make libkf5gapi optional. - Update Build-deps: make libkf5gapi optional. Checksums-Sha1: 7d2a5523eaa9b58026cb84c8bd8032d11c128c45 3882 kdepim-runtime_18.08.3-2.dsc 4d128552b6286e33842aef7a002039c4a9137960 22640 kdepim-runtime_18.08.3-2.debian.tar.xz 2bc493b776c027eba6a3b37726632bc3c5cf58ac 24084 kdepim-runtime_18.08.3-2_source.buildinfo Checksums-Sha256: 76887c80468a2ef56e5f18f4218f5d3f2870d96e3255bd9fce8b1e0ad21758bc 3882 kdepim-runtime_18.08.3-2.dsc 26d85893ed6bdec99ccdea8c4ee1a85c24c977130600264fbaec11228174f25c 22640 kdepim-runtime_18.08.3-2.debian.tar.xz b1f378f645402d5bcd001176d7815ba8ae067fca7a3aa05ca70c71624a809079 24084 kdepim-runtime_18.08.3-2_source.buildinfo Files: 0a2496d9f3473efcfc78370fd4d63ba3 3882 x11 optional kdepim-runtime_18.08.3-2.dsc fa52c55481a890cf76afa5f4a3e4694e 22640 x11 optional kdepim-runtime_18.08.3-2.debian.tar.xz 6afabe22d2dbccde511065b8dce62711 24084 x11 optional kdepim-runtime_18.08.3-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEOewRoCAWtykmSRoG462wCFBgVjYFAlySoMwRHGhlZmVlQGRl Ymlhbi5vcmcACgkQ462wCFBgVjZyBg//Xy93REesvlltpzOqG6znwDpAy/sRw6lm Q8U5WfxRGNY+U4AgORTMmo7fSVGnEx3t44X+/Jav8NGYvITd9dqZL5/nNhcQ+FKr hJ1gI4twdhvr1Hrd+tpL9L4vgv2AaF52LVS+47tlAHiTsrOu9XunF1Kf3CkKZ6gf VD5DCtH1Yczynbwvm12zqb3Hp4gx1PBQF+fbtEsF8Bmyo65KGuctE8mRWxAWPAvZ TO/pTVTeGQnKUa7hYiNMuonwGAgUbMarrwg6lWrpWAMxWWML0Qq9hXSlWgRuOzG0 1Htu41W6gLbZVE1JGvGGB+sl1iu1vZcXuQZJLHvWmCJZy5l1r+b7GhZpM1DCc3Vy Luo6n+DMGMLZKkr5iYoy/txH2sEsNfB+zjb3KvUSkhg2eDW57uig5HaB+dClYPIL GHnJ0cpegu5D5HrZur6eda8H0kRBnc3t3SQOu/1Q1x0FJ7c+Ytx1kuJ2Y/DL978z 2H9dXCZK9FsIZudq9yhqNzuPDvE86xg89C2hw3XcmshMzm0N6Ib3TGzWWW44VOKX DsO+Ga40AhBv91OCIotLntCqO/OXuahEpHRN1X8atimFjDR5nkZmiXvxFR66bNcS mk/0Zvhud8iw7L/ZhvEjY04c6F0APsTJ3gaTXIjVx+WjzbriGw/7Qveen07Dh35h hA/rJ3oQZ9c= =oPYJ -END PGP SIGNATURE End Message ---
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
On 2019-03-20 15:49:07 [+0100], Christoph Berg wrote: > PostgreSQL is BSD-licensed, so there is no problem in PostgreSQL > itself. (We use libedit instead of libreadline in psql to avoid the > libssl problem.) Also unlike the mariadb case, we have been shipping > libpq linked against libssl for at least a decade, so there is no > regression. Upstream is working on supporting alternate crypto > providers, but that will not happen before PostgreSQL 13. I can't tell if this of any help but the next openssl release (3.0.0, not 1.1.1 something) will be under the Apache v2 license [0]. [0] https://www.openssl.org/source/license.html Sebastian
Processed: Re: Bug#925155: RM: kaddressbook [armel, mips, mips64el, ppc64el, s390x] -- ANAIS; kdddressbook now depends on kdepim-runtime, that is not available in all archs.
Processing control commands: > reassign -1 kdepim-runtime 4:18.08.3-1 Bug #925155 [ftp.debian.org] RM: kaddressbook [armel, mips, mips64el, ppc64el, s390x] -- ANAIS; kdddressbook now depends on kdepim-runtime, that is not available in all archs. Bug reassigned from package 'ftp.debian.org' to 'kdepim-runtime'. Ignoring request to alter found versions of bug #925155 to the same values previously set Ignoring request to alter fixed versions of bug #925155 to the same values previously set Bug #925155 [kdepim-runtime] RM: kaddressbook [armel, mips, mips64el, ppc64el, s390x] -- ANAIS; kdddressbook now depends on kdepim-runtime, that is not available in all archs. Marked as found in versions kdepim-runtime/4:18.08.3-1. > retitle -1 Build on all release critical platforms Bug #925155 [kdepim-runtime] RM: kaddressbook [armel, mips, mips64el, ppc64el, s390x] -- ANAIS; kdddressbook now depends on kdepim-runtime, that is not available in all archs. Changed Bug title to 'Build on all release critical platforms' from 'RM: kaddressbook [armel, mips, mips64el, ppc64el, s390x] -- ANAIS; kdddressbook now depends on kdepim-runtime, that is not available in all archs.'. > tags -1 -moreinfo Bug #925155 [kdepim-runtime] Build on all release critical platforms Removed tag(s) moreinfo. > severity -1 serious Bug #925155 [kdepim-runtime] Build on all release critical platforms Severity set to 'serious' from 'normal' -- 925155: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925155 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#925176: closing 925176
close 925176 7.52-2+deb9u7 thanks Will be released in DSA with 7.52-2+deb9u7. Bug was filled for easier tracking given no CVE assigned.
Processed: closing 925176
Processing commands for cont...@bugs.debian.org: > close 925176 7.52-2+deb9u7 Bug #925176 [src:drupal7] drupal7: SA-CORE-2019-004: XSS vulnerability The source 'drupal7' and version '7.52-2+deb9u7' do not appear to match any binary packages Marked as fixed in versions drupal7/7.52-2+deb9u7. Bug #925176 [src:drupal7] drupal7: SA-CORE-2019-004: XSS vulnerability Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 925176: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925176 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#925176: drupal7: SA-CORE-2019-004: XSS vulnerability
Source: drupal7 Version: 7.52-2+deb9u6 Severity: grave Tags: security upstream Justification: user security hole Hi >From https://www.drupal.org/SA-CORE-2019-004 > Description: > > Under certain circumstances the File module/subsystem allows a > malicious user to upload a file that can trigger a cross-site > scripting (XSS) vulnerability. Regards, Salvatore
Bug#870267: #870267 : still relevant ?
Hi Frédéric, On Wed, Mar 20, 2019 at 4:03 PM Frédéric Bonnard wrote: > is this bug still relevant ? It was never a bug in GraphicsMagick, see the discussion starting about it[1]. A buildd admin later confirmed it's (it was) a bug on their side only with the ppc64el-unicamp-01 buildd and they could fix it. > Furthermore, this bug is RC, so may we close it now ? It's up to you, after Adrian was aggressive about it I let it go. It has no effect on the package (no migration problem or autoremoval). Regards, Laszlo/GCS [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870267#10
Processed: Retitle 921559
Processing commands for cont...@bugs.debian.org: > retitle 921559 MTP broken for number of phones with "LIBMTP PANIC: Unable to > initialize device" Bug #921559 [libmtp9] kio-extras: MTP browsing stopped working (after recent udev upgrade?) with "The file or folder udi=/org/kde... does not exist." Changed Bug title to 'MTP broken for number of phones with "LIBMTP PANIC: Unable to initialize device"' from 'kio-extras: MTP browsing stopped working (after recent udev upgrade?) with "The file or folder udi=/org/kde... does not exist."'. > End of message, stopping processing here. Please contact me if you need assistance. -- 921559: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921559 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: kio-extras: MTP browsing stopped working (after recent udev upgrade?) with "The file or folder udi=/org/kde... does not exist."
Processing control commands: > forwarded -1 https://sourceforge.net/p/libmtp/bugs/1818/ Bug #921559 [libmtp9] kio-extras: MTP browsing stopped working (after recent udev upgrade?) with "The file or folder udi=/org/kde... does not exist." Set Bug forwarded-to-address to 'https://sourceforge.net/p/libmtp/bugs/1818/'. -- 921559: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921559 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#921559: kio-extras: MTP browsing stopped working (after recent udev upgrade?) with "The file or folder udi=/org/kde... does not exist."
Control: forwarded -1 https://sourceforge.net/p/libmtp/bugs/1818/ Looks like there are problems with more phones (forwarded to bug about Moto G regression).
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
On Wed, 20 Mar 2019 15:59:40 + Dimitri John Ledkov wrote: > On Wed, 20 Mar 2019 16:31:25 +0100 Ansgar Burchardt wrote: > > Hi, > > > > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger > > than just libpq5: just looking at a small sample of the direct rdeps of > > libssl1.1, one can find the following GPL-licensed programs linking it: > > > > cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete > > > > Cryptsetup has a linking exception for OpenSSL: > https://tracker.debian.org/media/packages/c/cryptsetup/changelog-22.1.0-2 It has half of an exception. COPYING includes the following: +--- | In addition, as a special exception, the copyright holders give | permission to link the code of portions of this program with the | OpenSSL library under certain conditions as described in each | individual source file, and distribute linked combinations | including the two. +--- But the "certain conditions as described in each individual source file" are nowhere to be found; instead source files only say they are licensed under GPL (without any exception). Also, libcryptsetup12 has GPL-2+ rdeps (w/o any exception). So the problem only gets ever larger... Examples: libcryptsetup12 -> cryptmount (GPL-2+, no exception) libcryptsetup12 -> libvolume-key1 (GPL-2, no exception) -> libblockdev-crypto2 (LGPL-2.1+, no problem) -> udisks2 (GPL-2+, no exception) And indeed: +--- | % ldd /usr/lib/udisks2/udisksd | grep libssl | libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x7ff0c6009000) +--- Ansgar
Processed: Re: kio-extras: MTP browsing stopped working (after recent udev upgrade?) with "The file or folder udi=/org/kde... does not exist."
Processing control commands: > found -1 1.1.16-1 Bug #921559 [libmtp9] kio-extras: MTP browsing stopped working (after recent udev upgrade?) with "The file or folder udi=/org/kde... does not exist." Marked as found in versions libmtp/1.1.16-1. > severity -1 serious Bug #921559 [libmtp9] kio-extras: MTP browsing stopped working (after recent udev upgrade?) with "The file or folder udi=/org/kde... does not exist." Severity set to 'serious' from 'normal' -- 921559: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921559 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#924858: doxygen: FTBFS: make[4]: *** [doc/CMakeFiles/doxygen_pdf.dir/build.make:62: doc/CMakeFiles/doxygen_pdf] Error 1
unreproducible here, relevant part: ... make[4]: ingresso nella directory "/tmp/doxygen-1.8.13/build" [100%] Generating Doxygen Manual PDF. cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/cmake -E remove refman.tex cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/cmake -E copy /tmp/doxygen-1.8.13/build/doc/doxygen_manual.tex . cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/cmake -E copy /tmp/doxygen-1.8.13/build/doc/manual.sty . cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/epstopdf /tmp/doxygen-1.8.13/doc/doxygen_logo.eps --outfile=doxygen_logo.pdf cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/pdflatex -shell-escape doxygen_manual.tex This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) (preloaded format=pdflatex) \write18 enabled. entering extended mode (./doxygen_manual.tex LaTeX2e <2018-12-01> cd /tmp/doxygen-1.8.13/build/latex && /usr/bin/makeindex doxygen_manual.idx ... Paolo
Processed: found 910455 in 0.18.0~~rc2~dfsg-1, reassign 924940 to sponsorship-requests
Processing commands for cont...@bugs.debian.org: > found 910455 0.18.0~~rc2~dfsg-1 Bug #910455 [src:bitcoin] bitcoin FTBFS on 32bit: test failure Marked as found in versions bitcoin/0.18.0~~rc2~dfsg-1. > reassign 924940 sponsorship-requests Bug #924940 [fonts-myanmar] RFP: fonts-myanmar/0.1-1 [ITP] -- Prease Sponsor for myanmar-font pack Warning: Unknown package 'fonts-myanmar' Bug reassigned from package 'fonts-myanmar' to 'sponsorship-requests'. No longer marked as found in versions 0.1-1. Ignoring request to alter fixed versions of bug #924940 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 910455: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910455 924940: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924940 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
Hi, On Wed, 2019-03-20 at 16:31 +0100, Ansgar Burchardt wrote: > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger > than just libpq5: just looking at a small sample of the direct rdeps > of > libssl1.1, one can find the following GPL-licensed programs linking > it: > > cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete > > Also amanda-client, validns as they contain patches in d/patches > licensed under the GPL. > > There are probably lots more, especially when you start looking at > libraries (and their whole dependency trees). > > There is also cups which was reported to switch to Apache-2 which is > also GPL-2-incompatible... That has lots of rdeps too (including for > example all GTK applications). Also Python programs which often use libssl and are GPL-licensed. > Fedora treats OpenSSL as a "system library"[1]. I would guess they > might do the same for libcups too. I also came up with another interesting problem: libgcc and other low- level runtime libraries are licensed under GPL-3+-with-some-exception. However for a GPL-2-only program FOO with *no* system library exception, the complete source code would include libgcc and would require libgcc do be available under a GPL-2-compatible license... The runtime exception from libgcc doesn't help as FOO would need an exception... (I.e. the same problem just with libgcc instead of libssl) Ansgar
Bug#925051: diffoscope: FTBFS in stretch (failing tests)
Control: tag -1 pending On Tue, Mar 19, 2019 at 03:29:52PM -0400, Chris Lamb wrote: > > Ok, but this still should be fixed in stretch, right? > > (Packages in stretch must build in stretch). > > Sure thing, but this would require a stable update which seems a > little overkill, especially at this point in the buster release cycle…? > > Fancy pinging the SRMs on this? Not had to deal with this before. Cherry-picked the related patches, and uploaded. Also, pu bug opened for tracking at #925161 . -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Processed: Re: Bug#925051: diffoscope: FTBFS in stretch (failing tests)
Processing control commands: > tag -1 pending Bug #925051 [src:diffoscope] diffoscope: FTBFS in stretch (failing tests) Added tag(s) pending. -- 925051: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925051 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#924374: busybox ip --oneline displays nothing
Control: tag -1 + patch
Hi,
> I use LTSP which requires the following command to show a list of interfaces
> in which it can use.
> The following command worked in 1.27 of busybox but broke in the 1.30.1-2
> version;
> busybox ip -oneline link show
>
> This stopped all my thin clients from booting.
here's what happened:
busybox upstream found out that their ip address show command, with the
oneline option, includes link layer addresses, which iproute2 normally
doesn't. They patched that, without realising their ip link show code
ultimately calls their ip address show code.
Attached debdiff reverts this change. This makes the ip address show
behaviour "wrong" again, but including too much in a machine-readable
output seems less broken than this regression.
-nik
diff -Nru busybox-1.30.1/debian/changelog busybox-1.30.1/debian/changelog
--- busybox-1.30.1/debian/changelog 2019-03-02 09:11:13.0 +0100
+++ busybox-1.30.1/debian/changelog 2019-03-20 17:20:27.0 +0100
@@ -1,3 +1,10 @@
+busybox (1:1.30.1-2.1) UNRELEASED; urgency=high
+
+ * Non-maintainer upload.
+ * Re-enable ip -oneline. (Closes: #924374)
+
+ -- Dominik George Wed, 20 Mar 2019 17:20:27 +0100
+
busybox (1:1.30.1-2) unstable; urgency=high
* Complete the fix for [CVE-2018-20679] Closes: #918846
diff -Nru busybox-1.30.1/debian/patches/fix-ip-oneline.patch
busybox-1.30.1/debian/patches/fix-ip-oneline.patch
--- busybox-1.30.1/debian/patches/fix-ip-oneline.patch 1970-01-01
01:00:00.0 +0100
+++ busybox-1.30.1/debian/patches/fix-ip-oneline.patch 2019-03-20
17:20:22.0 +0100
@@ -0,0 +1,14 @@
+--- a/networking/libiproute/ipaddress.c
b/networking/libiproute/ipaddress.c
+@@ -570,10 +570,7 @@ int FAST_FUNC ipaddr_list_or_flush(char
+ }
+
+ for (l = linfo; l; l = l->next) {
+- if (no_link
+- || (oneline || print_linkinfo(>h) == 0)
+- /* ^ "ip -oneline a" does not print link info */
+- ) {
++ if (no_link || print_linkinfo(>h) == 0) {
+ struct ifinfomsg *ifi = NLMSG_DATA(>h);
+ if (G_filter.family != AF_PACKET)
+ print_selected_addrinfo(ifi->ifi_index, ainfo);
diff -Nru busybox-1.30.1/debian/patches/series
busybox-1.30.1/debian/patches/series
--- busybox-1.30.1/debian/patches/series2019-03-02 09:07:28.0
+0100
+++ busybox-1.30.1/debian/patches/series2019-03-20 17:19:08.0
+0100
@@ -12,3 +12,4 @@
stop-checking-ancient-kernel-version.patch
install-readlink-in-bin.patch
stop-overriding-stack-alignment-on-i386.patch
+fix-ip-oneline.patch
signature.asc
Description: PGP signature
Processed: Re: busybox ip --oneline displays nothing
Processing control commands: > tag -1 + patch Bug #924374 [busybox] busybox ip -oneline link show displays nothing Added tag(s) patch. -- 924374: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924374 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#923427: marked as done (mergechanges: Regression: --indep/source breaks multi-line Binary fields)
Your message dated Wed, 20 Mar 2019 16:19:14 + with message-id and subject line Bug#923427: fixed in devscripts 2.19.4 has caused the Debian Bug report #923427, regarding mergechanges: Regression: --indep/source breaks multi-line Binary fields to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 923427: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923427 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: devscripts Version: 2.19.3 Severity: serious Justification: regression Hi Not sure on the severity, but better safe than sorry, please downgrade as needed or see it fitting better. I had prepared an upload where I issued mergechanges --indep on the _amd64.changes to produce a changes to include only source packages and architecture-independent packages. $ mergechanges --indep -f linux_4.9.161-1_amd64.changes linux_4.9.161-1_amd64.changes Error: acpi-modules-4.9.0-9-amd64-di not found in Binary field b4ae0b22174cb1c7bf009bfcf0deaee8 10304 debian-installer extra acpi-modules-4.9.0-9-amd64-di_4.9.161-1_amd64.udeb This seems related to the change included in the 2.19.3 version, as the version in stretch creates the _multi.changes correctly. I'm attaching the original amd64.changes, plus the multi.changes produced with 2.17.6+deb9u2 and the multi.changes.broken produced with (2.19.3). Regards, Salvatore linux_4.9.161-1_amd64.changes.xz Description: application/xz linux_4.9.161-1_multi.changes.xz Description: application/xz linux_4.9.161-1_multi.changes.broken.xz Description: application/xz --- End Message --- --- Begin Message --- Source: devscripts Source-Version: 2.19.4 We believe that the bug you reported is fixed in the latest version of devscripts, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 923...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Mattia Rizzolo (supplier of updated devscripts package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 20 Mar 2019 16:57:59 +0100 Source: devscripts Architecture: source Version: 2.19.4 Distribution: unstable Urgency: medium Maintainer: Devscripts Maintainers Changed-By: Mattia Rizzolo Closes: 921334 921641 922975 923271 923427 923441 923499 924026 924977 Changes: devscripts (2.19.4) unstable; urgency=medium . [ Antonio Terceiro ] * debrepro: + Include --before-second-build option in output of --help. . [ Adam D. Barratt ] * scripts/Makefile: + Fix building / testing of shell-based scripts. Closes: #923271 . [ Paul Wise ] * chdist: + Drop Dir::State::status as apt doesn't hard-code it since 1.3~pre3 . [ Mattia Rizzolo ] * Apply patch from Jakub Wilk to fix a weird spacing in devscripts(1). Closes: #922975 * sadt: + Ignore a UserWarning from debian.deb822.PkgRelation.parse_relations after #712513 changed its format. Closes: #924026 * wrap-and-sort: + Do not try to sort the paragraphs in d/tests/control. Closes: #923499 * tests: + Introduce a chronic_sh() bash function, reimplementing chronic(1). + Quiet down the uscan_git tests by using the new chronic_sh() thing, and tweaking a few command calls here and there. + Rename the TMPDIR variable to avoid overloading it, and with it affect the behaviour of mktemp(1) when it was already exported. Closes: #924977 This affected only some uscan tests. + Also tweak a few mktemp(1) calls to place their files in SHUNIT_TMPDIR, and name them after the tests they are running. + export GIT_CONFIG_NOGLOBAL=1, HOME=, XDG_CONFIG_HOME= in a few tests (uscan_git and salsa) to prevent the local configuration from affecting the tests. Closes: #921334 . [ Xavier Guimard ] * salsa: + Allow `checkout --all`, to checkout all repos in a group. MR: !109 + Return 1 when lists are empty. MR: !110 + Fix disable/enable options. MR: !114 + Add KGB options configuration. Closes: #921641; MR: !115 * uscan: + Fix bad check for "verbose" in Config.pm. Closes: #923441; MR:
Bug#924977: marked as done (Building devscripts messes with $HOME)
Your message dated Wed, 20 Mar 2019 16:19:14 + with message-id and subject line Bug#924977: fixed in devscripts 2.19.4 has caused the Debian Bug report #924977, regarding Building devscripts messes with $HOME to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 924977: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924977 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: devscripts Version: 2.19.3 Severity: grave Running `dpkg-buildpackage` in a devscripts git checkout does weird things to $HOME. I don't think it's deleting any files (or else I would have opened this as critical), but this needs some attention. The first symptom is that there's temporary files in $HOME after building/trying to build: drwxrwxr-x 6 cbe cbe 4096 Mär 19 11:44 foo-0.0/ -rw-rw-r-- 1 cbe cbe 301 Mär 19 11:44 foo-0.0.tar.gz -rw-rw-r-- 1 cbe cbe 833 Mär 19 11:44 foo-0.0.tar.gz.asc drwxrwxr-x 6 cbe cbe 4096 Mär 19 11:44 foo-1.0/ -rw-rw-r-- 1 cbe cbe 301 Mär 19 11:44 foo-1.0.tar.gz -rw-rw-r-- 1 cbe cbe 833 Mär 19 11:44 foo-1.0.tar.gz.asc drwxrwxr-x 6 cbe cbe 4096 Mär 19 11:44 foo-2.0/ -rw-rw-r-- 1 cbe cbe 301 Mär 19 11:44 foo-2.0.tar.gz -rw-rw-r-- 1 cbe cbe 833 Mär 19 11:44 foo-2.0.tar.gz.asc One build attempt showed a lot of this on the console at which point I hit ^C: find: ‘./.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/device/driver/LNXTHERM:01/thermal_zone/cdev7/device/physical_node/node0/cpu7/firmware_node/subsystem/devices/device:2d/device:30/physical_node/device/driver/2-1.2/2-1.2:1.2/subsystem/devices/2-1/port/firmware_node/device:23/physical_node/device/2-1.1:1.0/0003:413C:2003.0001/driver/0003:1050:0407.000C/subsystem/devices/0003:413C:3012.0004/input/input2/mouse0/subsystem/input9/device/device/subsystem/devices/:00:1f.2/ata2/ata_port/ata2/subsystem/ata1/device/host0/target0:0:0/0:0:0:0/block/sda/bdi/subsystem/7:0/subsystem’: Zu viele Ebenen aus symbolischen Links find: ‘./.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/device/driver/LNXTHERM:01/thermal_zone/cdev7/device/physical_node/node0/cpu7/firmware_node/subsystem/devices/device:2d/device:30/physical_node/device/driver/2-1.2/2-1.2:1.2/subsystem/devices/2-1/port/firmware_node/device:23/physical_node/device/2-1.1:1.0/0003:413C:2003.0001/driver/0003:1050:0407.000C/subsystem/devices/0003:413C:3012.0004/input/input2/mouse0/subsystem/input9/device/device/subsystem/devices/:00:1f.2/ata2/ata_port/ata2/subsystem/ata1/device/host0/target0:0:0/0:0:0:0/block/sda/bdi/subsystem/253:6/subsystem’: Zu viele Ebenen aus symbolischen Links I think the problem is around the uscan test: 127.0.0.1 - - [19/Mar/2019 11:54:41] code 404, message File not found 127.0.0.1 - - [19/Mar/2019 11:54:41] "HEAD /foo-1.tgz.sign HTTP/1.1" 404 - testGitHead mktemp: konnte das Verzeichnis nicht mittels Schablone „/home/cbe/tmp/tmp.CPAf1zk7Db/tmp.XX“ erstellen: Datei oder Verzeichnis nicht gefunden mkdir: das Verzeichnis „/foo“ kann nicht angelegt werden: Keine Berechtigung mkdir: das Verzeichnis „/foo“ kann nicht angelegt werden: Keine Berechtigung mkdir: das Verzeichnis „/repo“ kann nicht angelegt werden: Keine Berechtigung ./test_uscan_git: 36: cd: can't cd to /repo Bestehendes Git-Repository in /home/cbe/debian/devscripts/devscripts/test/.git/ neuinitialisiert Auf Branch master Unversionierte Dateien: Makefile bashisms/ [...] test_uscan_online uscan/ nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien [master 158990d] Releasing 1.0 2 files changed, 3 insertions(+) fatal: Tag 'v1.0' existiert bereits [master a406494] Releasing 2.0 2 files changed, 3 insertions(+) fatal: Tag 'v2.0' existiert bereits ./test_uscan_git: 73: eval: cannot create /foo/debian/watch: Directory nonexistent ./test_uscan_git: 79: eval: cannot create /foo/debian/changelog: Directory nonexistent ./test_uscan_git: 86: eval: cannot create /foo/debian/source/format: Directory nonexistent cp: reguläre Datei '/foo/debian/upstream/signing-key.asc' kann nicht angelegt werden: Datei oder Verzeichnis nicht gefunden ./test_uscan_git: 103: eval: cannot create /foo/debian/watch: Directory nonexistent ./test_uscan_git: 120: cd: can't cd to /foo testExcludeXZ testRepackZip_XZ ok 147 ok 148 [...] testSuffix Ran 2 tests. FAILED (failures=1) make[3]: *** [Makefile:24: test_debrepro.test] Fehler 1 make[3]: *** Es wird auf noch nicht beendete Prozesse gewartet gpgv: Signatur vom Di 19 Mär 2019 11:54:42 CET gpgv:mittels RSA-Schlüssel CF218F0E7EABF584B7E20402C77E2D6872543FAF gpgv: Korrekte
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
On Wed, 20 Mar 2019 16:31:25 +0100 Ansgar Burchardt wrote: > Hi, > > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger > than just libpq5: just looking at a small sample of the direct rdeps of > libssl1.1, one can find the following GPL-licensed programs linking it: > > cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete > Cryptsetup has a linking exception for OpenSSL: https://tracker.debian.org/media/packages/c/cryptsetup/changelog-22.1.0-2
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
Hi, the OpenSSL ./. GPL problem (if one sees it as a problem) is larger than just libpq5: just looking at a small sample of the direct rdeps of libssl1.1, one can find the following GPL-licensed programs linking it: cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete Also amanda-client, validns as they contain patches in d/patches licensed under the GPL. There are probably lots more, especially when you start looking at libraries (and their whole dependency trees). There is also cups which was reported to switch to Apache-2 which is also GPL-2-incompatible... That has lots of rdeps too (including for example all GTK applications). Fedora treats OpenSSL as a "system library"[1]. I would guess they might do the same for libcups too. Ansgar [1] https://fedoraproject.org/wiki/Licensing:FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F
Bug#870267: #870267 : still relevant ?
Hi, is this bug still relevant ? Version 1.3.26 is not used anymore and I didn't see this happening since a long time in all the builds since then (including on the ppc64el-unicamp-01 builder) : : https://buildd.debian.org/status/logs.php?pkg=graphicsmagick Furthermore, this bug is RC, so may we close it now ? Regards, F. pgpVtdd3DmXnO.pgp Description: PGP signature pgprxoQtVWXce.pgp Description: PGP signature
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
Control: tag -1 = help Re: Robie Basak 2019-03-20 <20190320142403.ge30...@mal.justgohome.co.uk> > > > It is well understood that the OpenSSL license is not "compatible" with > > > the GPL (either version 2 or 3); and furthermore, Debian has long taken > > > the position that, unless a license exception is granted by the > > > copyright holders, a package which is distributed under the GPL must > > > only link to libraries whose licenses are also GPL-compatible in order > > > for it to be included in Debian. > > > > How is that a problem in libpq5, and not in the other packages? > > libpq5 seemed like a reasonable place to file this bug in the first > instance. I don't intend to dictate how or where this must be resolved. > > To help put this into perpspective: > > There are 140 source packages that build a binary that depends on > libpq5. > > 84 of these mention GPL in debian/copyright, but apparently have no > linking exception (heuristically and not checked but this is hopefully > enough for an indication). PostgreSQL is BSD-licensed, so there is no problem in PostgreSQL itself. (We use libedit instead of libreadline in psql to avoid the libssl problem.) Also unlike the mariadb case, we have been shipping libpq linked against libssl for at least a decade, so there is no regression. Upstream is working on supporting alternate crypto providers, but that will not happen before PostgreSQL 13. What is less clear is if we have a giant problem now, or if we can get out of the situation by claiming that the reverse dependencies do not use libssl directly. Theoretically, we could ship a libpq5-nossl.deb which I believe would have the same symbol signature. Input from ftp-master, debian-release, and/or debian-legal on this is needed, I cannot say what to do with licensing terms in all those reverse-dependers. > Of these 84, based on my glance at their debian/copyright files > manually, and without deeper investigation: > > * 12[1] appear to be GPL-2 only, so are affected today and will > continue to be affected in the upcoming OpenSSL upstream > relicensing. > > * 27[2] look like they're GPL-2+, GPL-3 or GPL-3+, so are affected > today but can be expected to become compatible in the future with a > newer release of OpenSSL upstream. However this does not help for > buster. > > So that's at least approximately 39 of 140 reverse dependencies that > appear affected based on a quick glance through. I've been fairly > conservative in my superficial analysis - I skipped reverse dependencies > where I couldn't see any compatibility problem from a quick glance. > > [1] bandwidthd-pgsql dballe inspircd libnss-pgsql2 libodb-pgsql-2.4 > pmacct r-cran-rpostgresql saga sphinxsearch tora ulogd2-pgsql > yubikey-server-c > > [2] clisp cvm cyphesis-cpp gammu gnokii gnu-smalltalk gnunet grass > libpg-perl libpreludedb motion newlisp osm2pgrouting osm2pgsql pam-pgsql > libzdb perdition pgmodeler postgis pspp pvpgn qgis repmgr sqlsmith > sysbench w1retap zabbix Christoph signature.asc Description: PGP signature
Processed: Re: Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
Processing control commands: > tag -1 = help Bug #924937 [libpq5] libpq5: OpenSSL license contamination of GPL reverse-dependencies Added tag(s) help; removed tag(s) moreinfo. -- 924937: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: libpolkit-qt5-1-1
Processing control commands: > severity -1 wishlist Bug #923200 [libpolkit-qt5-1-1] libpolkit-qt5-1-1: has a false dependency on libpam-systemd Severity set to 'wishlist' from 'serious' -- 923200: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923200 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#923200: libpolkit-qt5-1-1
Control: severity -1 wishlist The dependency seems correct. policykit without a working logind session seems pretty much useless. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Processed: Affects reverse dependencies
Processing commands for cont...@bugs.debian.org: > affects 924937 + bandwidthd-pgsql dballe inspircd libnss-pgsql2 > libodb-pgsql-2.4 pmacct r-cran-rpostgresql saga sphinxsearch tora > ulogd2-pgsql yubikey-server-c clisp cvm cyphesis-cpp gammu gnokii > gnu-smalltalk gnunet grass libpg-perl libpreludedb motion newlisp > osm2pgrouting osm2pgsql pam-pgsql libzdb perdition pgmodeler postgis pspp > pvpgn qgis repmgr sqlsmith sysbench w1retap zabbix Bug #924937 [libpq5] libpq5: OpenSSL license contamination of GPL reverse-dependencies Added indication that 924937 affects bandwidthd-pgsql, dballe, inspircd, libnss-pgsql2, libodb-pgsql-2.4, pmacct, r-cran-rpostgresql, saga, sphinxsearch, tora, ulogd2-pgsql, yubikey-server-c, clisp, cvm, cyphesis-cpp, gammu, gnokii, gnu-smalltalk, gnunet, grass, libpg-perl, libpreludedb, motion, newlisp, osm2pgrouting, osm2pgsql, pam-pgsql, libzdb, perdition, pgmodeler, postgis, pspp, pvpgn, qgis, repmgr, sqlsmith, sysbench, w1retap, and zabbix > thanks Stopping processing here. Please contact me if you need assistance. -- 924937: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
On Tue, Mar 19, 2019 at 10:49:06AM +0100, Christoph Berg wrote: > Re: Robie Basak 2019-03-18 <20190318165800.gc12...@mal.justgohome.co.uk> > > It is well understood that the OpenSSL license is not "compatible" with > > the GPL (either version 2 or 3); and furthermore, Debian has long taken > > the position that, unless a license exception is granted by the > > copyright holders, a package which is distributed under the GPL must > > only link to libraries whose licenses are also GPL-compatible in order > > for it to be included in Debian. > > How is that a problem in libpq5, and not in the other packages? libpq5 seemed like a reasonable place to file this bug in the first instance. I don't intend to dictate how or where this must be resolved. To help put this into perpspective: There are 140 source packages that build a binary that depends on libpq5. 84 of these mention GPL in debian/copyright, but apparently have no linking exception (heuristically and not checked but this is hopefully enough for an indication). Of these 84, based on my glance at their debian/copyright files manually, and without deeper investigation: * 12[1] appear to be GPL-2 only, so are affected today and will continue to be affected in the upcoming OpenSSL upstream relicensing. * 27[2] look like they're GPL-2+, GPL-3 or GPL-3+, so are affected today but can be expected to become compatible in the future with a newer release of OpenSSL upstream. However this does not help for buster. So that's at least approximately 39 of 140 reverse dependencies that appear affected based on a quick glance through. I've been fairly conservative in my superficial analysis - I skipped reverse dependencies where I couldn't see any compatibility problem from a quick glance. [1] bandwidthd-pgsql dballe inspircd libnss-pgsql2 libodb-pgsql-2.4 pmacct r-cran-rpostgresql saga sphinxsearch tora ulogd2-pgsql yubikey-server-c [2] clisp cvm cyphesis-cpp gammu gnokii gnu-smalltalk gnunet grass libpg-perl libpreludedb motion newlisp osm2pgrouting osm2pgsql pam-pgsql libzdb perdition pgmodeler postgis pspp pvpgn qgis repmgr sqlsmith sysbench w1retap zabbix signature.asc Description: PGP signature
Processed: Bug #924977 in devscripts marked as pending
Processing control commands: > tag -1 pending Bug #924977 [devscripts] Building devscripts messes with $HOME Added tag(s) pending. -- 924977: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924977 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#924977: Bug #924977 in devscripts marked as pending
Control: tag -1 pending Hello, Bug #924977 in devscripts reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/devscripts/commit/9a21338c53ce51faf5cc5ad7e343c711b437ae18 Merge branch fixing a TMPDIR variable poisoning, and preventing the local git config from affecting the tests Closes: #924977 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/924977
Processed: Bug #925117 in mariadb-10.3 marked as pending
Processing control commands: > tag -1 pending Bug #925117 [src:mariadb-10.3] mariadb-10.3: drop the transitional libmariadbclient18 package Ignoring request to alter tags of bug #925117 to the same tags previously set -- 925117: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925117 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#925117: Bug #925117 in mariadb-10.3 marked as pending
Control: tag -1 pending Hello, Bug #925117 in mariadb-10.3 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/549127e099eca45538be9b1e4283f32533990bb9 Drop the transitional libmariadbclient18 package (Closes: #925117) (this message was generated automatically) -- Greetings https://bugs.debian.org/925117
Bug#924762: -T foo
I tried emacs -T foo Mär19 but to no avail: the X-server crashed. (For a split second, the widget "foo" appeared) Martin
Bug#925117: Bug #925117 in mariadb-10.3 marked as pending
Control: tag -1 pending Hello, Bug #925117 in mariadb-10.3 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/0b82f2ae51276f1fc95fe0358372d902b376b544 Drop the transitional libmariadbclient18 package (Closes: #925117) (this message was generated automatically) -- Greetings https://bugs.debian.org/925117
Processed: Bug #925117 in mariadb-10.3 marked as pending
Processing control commands: > tag -1 pending Bug #925117 [src:mariadb-10.3] mariadb-10.3: drop the transitional libmariadbclient18 package Added tag(s) pending. -- 925117: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925117 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#924762: further information: window manager
On Sun, 17 Mar 2019 16:38:23 +0100 zieg...@uni-freiburg.de wrote: > I use xfce4 as a window-manager. The bug does NOT occur > under icewm. This looks like a bad interaction between emacs and xfce4, I'd guess then emacs is sending the file name to xfc4 to set the widget title. Could you try to reproduce the bug while passing "-T foo" option to emacs ? This will set the widget title to "foo" instead of "mär19" HTH
Bug#878983:
For the record, I've briefly looked into this. The initially reported build error can be fixed by applying https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/commit/020feca404095bcc08ebfa6deebaecbbc7399852. There are, however, some other build errors due to the reference to OCaml source files in Makefile. The upstream cduce-next branch can be built with Debian's OCaml 4.05. I've asked upstream (Giuseppe Castagna) to make a new release and I was told that they will do it soon. Best, Andy
Bug#925051: diffoscope: FTBFS in stretch (failing tests)
Hi, On Tue, Mar 19, 2019 at 04:13:46PM -0400, Chris Lamb wrote: > > The relevant thing, IMO, is that proposed-updates and point > > releases still exist for stretch, so I don't see it overkill > > Sure. Can you still loop the SRMs in on this before I backport this > patch and create a stretchpu bug, etc. etc.? Thanks. :) That kind of things are done by the person doing the update, and from my experience the release team doesn't really deal nicely with requests without a working diff, etc. I will take this on, directly uploading to stretch as I am confident they will approve it directly. tbh I totally forgot about stretch itself while fixing that bug… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
* Kurt Roeckx [2019-03-20 07:31]: > On Tue, Mar 19, 2019 at 11:21:19PM +0100, Holger Weiß wrote: > > * Kurt Roeckx [2019-03-19 22:59]: > > > On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote: > > > > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹ > > > > unexpectedly returns NULL. I now avoid the function to work around the > > > > issue. > > > > > > This is documented here: > > > https://wiki.openssl.org/index.php/TLS1.3#PSKs > > > > Thanks. I'm still using the TLSv1.2 callbacks indeed, but from reading > > that text it's not obvious to me why SSL_get_psk_identity() would fail. > > (Note that I'm not using identity *hints* anywhere, which is the thing > > TLSv1.3 dropped.) However, I can easily imagine the bug(?) being > > related to the changes mentioned in that text. > > If you think there is a bug, please file a bug on github. Done: https://github.com/openssl/openssl/issues/8534
Bug#925136: help2man: FTBFS in unstable (dh_clean fails)
Package: help2man Version: 1.47.9 Severity: serious Looks like README needs a newer timestamp wrt help2man.PL file? APT_CONFIG=/var/lib/sbuild/apt.conf DEB_BUILD_OPTIONS=parallel=4 HOME=/sbuild-nonexistent LC_ALL=POSIX LOGNAME=buildd PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games SCHROOT_ALIAS_NAME=sid-amd64-sbuild SCHROOT_CHROOT_NAME=sid-amd64-sbuild SCHROOT_COMMAND=env SCHROOT_GID=1009 SCHROOT_GROUP=buildd SCHROOT_SESSION_ID=sid-amd64-sbuild-f190c122-7391-4aaa-be5e-e45efc144c1c SCHROOT_UID=2952 SCHROOT_USER=buildd SHELL=/bin/sh USER=buildd XDG_RUNTIME_DIR=/run/user/2952 XDG_SESSION_ID=2 dpkg-buildpackage - dpkg-buildpackage: info: source package help2man dpkg-buildpackage: info: source version 1.47.9 dpkg-buildpackage: info: source distribution unstable dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean test README -nt help2man.PL # maintainer sanity check make: *** [debian/rules:40: clean] Error 1 dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 2 Build finished at 2019-03-18T08:59:52Z Finished Gianfranco
Bug#925134: grub-efi-amd64-signed: doesn't mount cryptodisk
Package: grub-efi-amd64 Version: 2.02+dfsg1-13 Severity: critical Dear Maintainer, this is a continuation of BUG #917117, that is archived. In that bug every GRUB2 update removes cryptomount call from /boot/efi/EFI/debian/grub.cfg, and thus breaks the boot. Now if I call update-grub, all is fine, but every package update (this happens for 2.02+dfsg1-12 and 2.02+dfsg1-13) removes cryptomount call from /boot/efi/EFI/debian/grub.cfg again, and breaks the boot. I have GRUB_ENABLE_CRYPTODISK=y in /etc/default/grub and /boot/efi/EFI/debian/grub.cfg was: insmod luks insmod lvm cryptomount (hd0,gpt2) search.fs_uuid 0c4e1d15-07b4-4757-9fd4-02a8e0c42e1b root lvmid/iRGCxh-2PcK-EDWe-zWim-n3Qu-F0KP-HMOfJi/bzEuy6-onGG-oFyt-fAIn-q69G-c9RE-t0iHce set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg and becomes search.fs_uuid 0c4e1d15-07b4-4757-9fd4-02a8e0c42e1b root lvmid/iRGCxh-2PcK-EDWe-zWim-n3Qu-F0KP-HMOfJi/bzEuy6-onGG-oFyt-fAIn-q69G-c9RE-t0iHce set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg I've tried apt install --reinstall grub-efi-amd64 and the /boot/efi/EFI/debian/grub.cfg was changed again. -- Mandi. Paolo
Bug#891434: Bug#923839: shim-signed: setup of shim-signed failed with 'Could not delete variable: No space left on device'
On Sun, 10 Mar 2019 21:57:02 + Colin Watson wrote: > Control: reassign 891434 src:grub2 > Control: forcemerge 891434 923839 > > On Tue, Mar 05, 2019 at 03:43:31PM -0800, Steve Langasek wrote: > > But I'm reassigning this bug to grub2, because I think the right answer for > > nearly all efibootmgr write failures on update of the bootloader packages is > > that grub should not be writing to nvram at all. Rather, in the common case > > of a bootloader upgrade, the contents being written to nvram will match what > > is already there. By detecting that there are no changes, we save ourselves > > a write, which in the exceptional cases sidesteps a write failure, and in > > the common case, reduces wear on the nvram which may have limited write > > cycles. > > This is the same as #891434, which I've been working on recently, and at > a high level you and I have reached the same conclusions about what's > needed. (I've also been discussing it with Steve McIntyre, again > reaching similar conclusions.) > > [...] > > I got this almost working at the Cambridge BSP today before I ran out of > time (very nearly bricking my own laptop in the process ...). I need to > add suitable --debug messages, finish getting it working, ensure that > it's only rewriting variables where needed, and generally tidy up the > fairly large pile of code involved, so there's still probably at least > four hours of work left to do on it, not to mention upstream review. > However, I'm reasonably hopeful that I'll have this done for buster. > > -- > Colin Watson [cjwat...@debian.org] > > Hi Colin, Thanks for working on this. :) I am glad to hear that we might have something almost ready thanks to your hard work. :) Thanks, ~Niels
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
On Tue, Mar 19, 2019 at 11:21:19PM +0100, Holger Weiß wrote: > * Kurt Roeckx [2019-03-19 22:59]: > > On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote: > > > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹ > > > unexpectedly returns NULL. I now avoid the function to work around the > > > issue. > > > > This is documented here: > > https://wiki.openssl.org/index.php/TLS1.3#PSKs > > Thanks. I'm still using the TLSv1.2 callbacks indeed, but from reading > that text it's not obvious to me why SSL_get_psk_identity() would fail. > (Note that I'm not using identity *hints* anywhere, which is the thing > TLSv1.3 dropped.) However, I can easily imagine the bug(?) being > related to the changes mentioned in that text. If you think there is a bug, please file a bug on github. Kurt
