Bug#991283: unblock: mesa/20.3.5-1
On 21.7.2021 11.12, Simon McVittie wrote: On Wed, 21 Jul 2021 at 10:15:12 +0300, Timo Aaltonen wrote: On 19.7.2021 19.44, Simon McVittie wrote: Should the mesa source package be unblocked for bullseye? ack For clarity: does this mean "yes, I would like mesa_20.3.5-1 to reach bullseye"? Correct, sorry for not requesting it before, and thanks for your attempt :) There don't seem to be any RC bugs open. The Mesa maintainers would know better than I do whether there have been non-RC regression reports. Does your ack mean no regressions have been reported? Right, I went through the debian-x mailbox and couldn't find any. [ ] I reviewed all changes and I approve them After looking at the filtered debdiff, do the Mesa maintainers approve this unblock request? Yes, though it does have debian/patches/llvm-12-build-fix.diff patch cruft (sigh..), it's harmless since it's not used. -- t
Bug#991360: marked as done (unblock: nftables/0.9.8-3.1)
Your message dated Thu, 22 Jul 2021 08:26:32 +0200 with message-id and subject line Re: Bug#991360: unblock: nftables/0.9.8-3.1 has caused the Debian Bug report #991360, regarding unblock: nftables/0.9.8-3.1 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.) -- 991360: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991360 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: Arturo Borrero Gonzalez Please unblock package nftables [ Reason ] Fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991309 Under certain conditions nftables tends to be greedy and can delete too much rules. This was identified via an issue to firewalld which had a test that failed on it [1] but was then found and fixed in nftables [2]. [ Impact ] The change looks bigger than it is as it moves code around to be available earlier in the code. It really comes down to dependency killing of rules and should not have a different impact to nftables than that. [ Tests ] While the Debian tests skip the tests e.g. of firewalld [3] I have uploaded the same to Ubuntu where all the tests (including those that failed due to the issue) already completed. On this upload the debci will again skip the tests that would have flagged this bug, others will run but they have worked before and will afterwards. [ Risks ] I'd hope that it is low as it is not just from git, but also part of an official release (0.9.9) already. We don't want to bump versions so late, but this gives some extra confidence in the testing that was done. As mentioned above the risk should be limited to the dependent rule removal. [ Other info ] * I've prepared a debdiff (attached) which matches testing vs unstable at the moment that the request here asks to unblock. * The unstable version has just been uploaded, please give it some time to build and be tested (by tools and myself), but I wanted to give a heads up as early as possible. P.S. The usual maintainer asked for an NMU and driving the unblocking, details on the bug we fix that is linked above. [1]: https://github.com/firewalld/firewalld/issues/752 [2]: https://git.netfilter.org/nftables/commit/?id=533565244d88a [3]: https://ci.debian.net/data/autopkgtest/testing/amd64/f/firewalld/13738304/log.gz -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd fix-debian-991309.debdiff Description: Binary data --- End Message --- --- Begin Message --- Unblocked.--- End Message ---
Bug#991374: unblock: krb5/1.18.3-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ka...@mit.edu Please unblock package krb5 Upstream krb5 recently fixed a CVE in the KDC (server) process whereby an unauthenticated request can trigger a NULL dereference. The krb5 maintainer notes that systemd will restart the KDC if this happens, but of course an attacker can send a flood of such crafted packets and effectively DoS the process. [ Reason ] The NULL dereference is a service crash triggerable by a remote unauthenticated attacker, and we should not have this DoS vulnerability in the stable release. [ Impact ] An unpatched KDC is vulnerable to denial of service by an unauthenticated remote attacker. [ Tests ] Upstream included a unit test to verify that a malformed packet does not crash the KDC. Upstream also has an extensive test suite that serves as a regression test. [ Risks ] The risk here is pretty minimal; the issue stems from a function that was written in an "if-ladder" style so that any operation that might write to "retval" has to be wrapped in a conditional so that the operation is skipped if an error had occurred previously. The fix is to add such a "retval == 0" check to a function call that takes a pointer to retval as a parameter and writes to it, causing any previous errors in the function to be ignored. (Upstream has since re-written the function to use a more robust coding style, but that is not a minimal fix suitable for unblock.) [ 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 krb5/1.18.3-6 diff -Nru krb5-1.18.3/debian/changelog krb5-1.18.3/debian/changelog --- krb5-1.18.3/debian/changelog2021-03-28 10:43:01.0 -0700 +++ krb5-1.18.3/debian/changelog2021-07-21 11:07:07.0 -0700 @@ -1,3 +1,10 @@ +krb5 (1.18.3-6) unstable; urgency=high + + * Pull in upstream patch to fix CVE-2021-36222 (KDC NULL dereference), +Closes: #991365 + + -- Benjamin Kaduk Wed, 21 Jul 2021 11:07:07 -0700 + krb5 (1.18.3-5) unstable; urgency=medium * Update breaks on libk5crypto3 toward other internal libraries because diff -Nru krb5-1.18.3/debian/patches/0010-Fix-KDC-null-deref-on-bad-encrypted-challenge.patch krb5-1.18.3/debian/patches/0010-Fix-KDC-null-deref-on-bad-encrypted-challenge.patch --- krb5-1.18.3/debian/patches/0010-Fix-KDC-null-deref-on-bad-encrypted-challenge.patch 1969-12-31 16:00:00.0 -0800 +++ krb5-1.18.3/debian/patches/0010-Fix-KDC-null-deref-on-bad-encrypted-challenge.patch 2021-07-21 11:06:53.0 -0700 @@ -0,0 +1,112 @@ +From: Joseph Sutton +Date: Wed, 7 Jul 2021 11:47:44 +1200 +Subject: Fix KDC null deref on bad encrypted challenge + +The function ec_verify() in src/kdc/kdc_preauth_ec.c contains a check +to avoid further processing if the armor key is NULL. However, this +check is bypassed by a call to k5memdup0() which overwrites retval +with 0 if the allocation succeeds. If the armor key is NULL, a call +to krb5_c_fx_cf2_simple() will then dereference it, resulting in a +crash. Add a check before the k5memdup0() call to avoid overwriting +retval. + +CVE-2021-36222: + +In MIT krb5 releases 1.16 and later, an unauthenticated attacker can +cause a null dereference in the KDC by sending a request containing a +PA-ENCRYPTED-CHALLENGE padata element without using FAST. + +[ghud...@mit.edu: trimmed patch; added test case; edited commit +message] + +(cherry picked from commit fc98f520caefff2e5ee9a0026fdf5109944b3562) + +ticket: 9007 +version_fixed: 1.18.4 + +(cherry picked from commit c4a406095b3ea4a67ae5b8ea586cbe9abdbae76f) +--- + src/kdc/kdc_preauth_ec.c | 3 ++- + src/tests/Makefile.in | 1 + + src/tests/t_cve-2021-36222.py | 46 +++ + 3 files changed, 49 insertions(+), 1 deletion(-) + create mode 100644 src/tests/t_cve-2021-36222.py + +diff --git a/src/kdc/kdc_preauth_ec.c b/src/kdc/kdc_preauth_ec.c +index 7e636b3..43a9902 100644 +--- a/src/kdc/kdc_preauth_ec.c b/src/kdc/kdc_preauth_ec.c +@@ -87,7 +87,8 @@ ec_verify(krb5_context context, krb5_data *req_pkt, krb5_kdc_req *request, + } + + /* Check for a configured FAST ec auth indicator. */ +-realmstr = k5memdup0(realm.data, realm.length, &retval); ++if (retval == 0) ++realmstr = k5memdup0(realm.data, realm.length, &retval); + if (realmstr != NULL) + retval = profile_get_string(context->profile, KRB5_CONF_REALMS, + realmstr, +diff --git a/src/tests/Makefile.in b/src/tests/Makefile.in +index 3f88f17..0ffbebf 100644 +--- a/src/tests/Makefile.in b/src/tests/Makefile.in +@@ -158,6 +158,7 @@ check-pytests: unlockiter s4u2self + $(RUNPYTEST) $(srcdir)/t_cve-2012-1015.py $(PYTESTFLAGS) + $(RUNPYTEST) $(srcdir)/t_cve-2013-1416.py $(PYTESTFLAGS) + $(RUNPYTEST) $(srcdir)/t
Bug#991372: unblock: glibc/2.31-13
Control: tags -1 confirmed d-i Hi Aurelien, On 21-07-2021 22:31, Aurelien Jarno wrote: > Please unblock package glibc Thanks, waiting for the ACK from kibi. Paul OpenPGP_signature Description: OpenPGP digital signature
Processed: Re: Bug#991372: unblock: glibc/2.31-13
Processing control commands: > tags -1 confirmed d-i Bug #991372 [release.debian.org] unblock: glibc/2.31-13 Added tag(s) d-i and confirmed. -- 991372: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991372 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#991372: unblock: glibc/2.31-13
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-b...@lists.debian.org
Please unblock package glibc
[ Reason ]
This new version fixes one serious bug (#990069) in the maintainer
scripts preventing the sshd daemon following a glibc upgrade on systems
where the ssh meta-package is not installed.
It also fixes a security issue in the wordexp() function
(CVE-2021-35942, #990542) by pulling the upstream stable branch.
[ Impact ]
On systems where the ssh meta-package is not installed, following the
upgrade from buster to bullseye, incoming SSH connections are not
accepted until the sshd daemon is restarted manually or the system is
rebooted. This can be an issue for systems upgraded remotely.
[ Tests ]
The change to the maintainer scripts are not covered by automatic tests
(except maybe by piuparts). They have however been manually tested by
multiple persons.
The change to the wordexp() function is covered by the upstream
testsuite. A new test has actually been added to catch the security
issue.
[ Risks ]
The change to the maintainer scripts is relatively simple and just
follow what is already done for other daemons where the package name is
not the same than the daemon name. The package has been in sid for 2
weeks, and no regression have been reported. The risk is therefore very
low.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
d-i team is Cc:ed.
unblock glibc/2.31-13
diff --git a/debian/changelog b/debian/changelog
index 7197d373..138f350a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+glibc (2.31-13) unstable; urgency=medium
+
+ [ Colin Watson ]
+ * debian/debhelper.in/libc.postinst, script.in/nsscheck.sh: Look for
+openssh-server package rather than ssh. Closes: #990069
+
+ [ Aurelien Jarno ]
+ * debian/patches/git-updates.diff: update from upstream stable branch:
+- Fix an arbitrary read in wordexp() (CVE-2021-35942). Closes:
+ #990542.
+
+ -- Aurelien Jarno Tue, 06 Jul 2021 21:16:59 +0200
+
glibc (2.31-12) unstable; urgency=medium
* debian/po/de.po: fix encoding declaration. Closes: #986450.
diff --git a/debian/debhelper.in/libc.postinst
b/debian/debhelper.in/libc.postinst
index 0b312dfa..f52a1430 100644
--- a/debian/debhelper.in/libc.postinst
+++ b/debian/debhelper.in/libc.postinst
@@ -33,9 +33,10 @@ then
check="$check boa cucipop courier-authdaemon cron cups exim"
check="$check exim4-base dovecot-common cucipop incron lprng lpr"
check="$check lpr-ppd mysql-server nis openbsd-inetd"
- check="$check openldapd postgresql-common proftpd postfix
postfix-tls"
- check="$check rsync samba sasl2-bin slapd smail sendmail snmpd ssh"
- check="$check spamassassin vsftpd wu-ftpd wu-ftpd-academ wwwoffle"
+ check="$check openldapd openssh-server postgresql-common proftpd"
+ check="$check postfix postfix-tls rsync samba sasl2-bin slapd"
+ check="$check smail sendmail snmpd spamassassin vsftpd"
+ check="$check wu-ftpd wu-ftpd-academ wwwoffle"
check="$check webmin dropbear gdm"
# NSS services check:
__NSS_CHECK__
diff --git a/debian/patches/git-updates.diff b/debian/patches/git-updates.diff
index 0e5aefae..e1cac4a1 100644
--- a/debian/patches/git-updates.diff
+++ b/debian/patches/git-updates.diff
@@ -3647,6 +3647,31 @@ index cba9cd1819..4580cefb9f 100644
dirlen = home_len + rest_len;
dirname_modified = 1;
}
+diff --git a/posix/wordexp-test.c b/posix/wordexp-test.c
+index ed1b22308e..cb3f989cba 100644
+--- a/posix/wordexp-test.c
b/posix/wordexp-test.c
+@@ -183,6 +183,7 @@ struct test_case_struct
+ { 0, NULL, "$var", 0, 0, { NULL, }, IFS },
+ { 0, NULL, "\"\\n\"", 0, 1, { "\\n", }, IFS },
+ { 0, NULL, "", 0, 0, { NULL, }, IFS },
++{ 0, NULL, "${1234567890123456789012}", 0, 0, { NULL, }, IFS },
+
+ /* Flags not already covered (testit() has special handling for these) */
+ { 0, NULL, "one two", WRDE_DOOFFS, 2, { "one", "two", }, IFS },
+diff --git a/posix/wordexp.c b/posix/wordexp.c
+index e082d94895..56289503a1 100644
+--- a/posix/wordexp.c
b/posix/wordexp.c
+@@ -1399,7 +1399,7 @@ envsubst:
+ /* Is it a numeric parameter? */
+ else if (isdigit (env[0]))
+ {
+- int n = atoi (env);
++ unsigned long n = strtoul (env, NULL, 10);
+
+ if (n >= __libc_argc)
+ /* Substitute NULL. */
diff --git a/stdlib/Makefile b/stdlib/Makefile
index 45214b59e4..4615f6dfe7 100644
--- a/stdlib/Makefile
diff --git a/debian/script.in/nsscheck.sh b/debian/script.in/nsscheck.sh
index 623278c0..8406a543 100644
--- a/debian/script.in/nsscheck.sh
+++ b/debian/script.in/nsscheck.sh
@@ -12,6 +12,7 @@
-
Bug#991362: marked as done (unblock: klog/1.4.6-1)
Your message dated Wed, 21 Jul 2021 21:11:40 +0200
with message-id
and subject line Re: Bug#991362: unblock: klog/1.4.6-1
has caused the Debian Bug report #991362,
regarding unblock: klog/1.4.6-1
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.)
--
991362: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991362
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ja...@debian.org
Please unblock package klog
[ Reason ]
KLog has evolved a lot since 1.4.6. It is now in 1.7 and a lot of bugs has
been solved since then by the upstream.
[ Impact ]
Debian (and derivatives) users will be blocked with an old version.
[ Tests ]
Manual tests have been done.
[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
Documented changes in the d/changelog are only affecting to the Debian
packages. Most of the changes are in the upstream.
There is also a list of fixed bugs in the upstream's Changelog
unblock klog/1.4.6-1
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/share/klog/translations/klog_ca.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_da.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_de.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_es.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_fi.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_fr.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_hr.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_it.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_ja.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_pl.qm
Control files: lines which differ (wdiff format)
Depends: libc6 (>= 2.14), libgcc-s1 (>= 3.0), libhamlib4, libqt5charts5 (>=
5.7.1), libqt5core5a (>= 5.15.1), libqt5gui5 (>= [-5.3.0)-] {+5.8.0)+} |
libqt5gui5-gles (>= [-5.3.0),-] {+5.8.0),+} libqt5network5 (>= 5.14.1),
libqt5printsupport5 (>= 5.0.2), libqt5serialport5 (>= 5.6.0), libqt5sql5 (>=
5.10.0), libqt5widgets5 (>= 5.2.0~alpha1), libstdc++6 (>= 4.1.1),
libqt5sql5-sqlite
Installed-Size: [-4461-] {+3289+}
Version: [-1.4.7-1-] {+1.7-1+}
--- End Message ---
--- Begin Message ---
Hi Jaime
On Wed, 21 Jul 2021 at 17:12, Jaime Robles wrote:
> [ Reason ]
> KLog has evolved a lot since 1.4.6. It is now in 1.7 and a lot of bugs has
> been solved since then by the upstream.
...
> [ Other info ]
> Documented changes in the d/changelog are only affecting to the Debian
> packages. Most of the changes are in the upstream.
> There is also a list of fixed bugs in the upstream's Changelog
Please refer to the 'Appropriate changes during Hard and Full Freeze'
section of the Bullseye Freeze Policy [1].
I see many bugs fixed in (what I assume is) upstream's Changelog [2],
but also many other changes. This upload is not suitable in the
current stage of the freeze and will not be unblocked.
Regards
Graham
[1] https://release.debian.org/bullseye/freeze_policy.html#appropriate
[2] https://github.com/ea4k/klog/blob/master/src/Changelog--- End Message ---
Processed: Re: Bug#991359: unblock: liquidsoap/1.4.3-3
Processing control commands: > tags -1 + moreinfo confirmed Bug #991359 [release.debian.org] unblock: liquidsoap/1.4.3-3 Added tag(s) moreinfo and confirmed. -- 991359: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991359 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#991359: unblock: liquidsoap/1.4.3-3
Control: tags -1 + moreinfo confirmed Hi Kyle Please go ahead and upload to unstable, then remove the moreinfo tag once it has built. Regards Graham
Bug#991366: nmu: varnish-modules_0.16.0-2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hello, Please do a BinNMU of "varnish-modules" to ensure that the "varnish" security fix can migrate to testing. Background: After upgrading "varnish" from 6.5.1 to 6.5.2, the module "bodyaccess" in this package fails to load, which was discovered with autopkgtest. The "bodyaccess" module has a stricter dependency on the Varnish version than the dependency declared in the "varnish-modules" package. Getting the correct dependency into "varnish-modules" is tracked in https://bugs.debian.org/991348, but a rebuild of "varnish-modules" against the new varnish package may be a faster fix due to the freeze. nmu varnish-modules_0.16.0-2.1 . ANY . unstable . -m "rebuild against new varnish"
Processed: Merge duplicates
Processing commands for cont...@bugs.debian.org:
> forcemerge 991345 991346
Bug #991345 {Done: Sebastian Ramacher }
[release.debian.org] unblock: aspell/0.60.8-3
Bug #991346 [release.debian.org] unblock: aspell/0.60.8-3
Marked Bug as done
Merged 991345 991346
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
991345: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991345
991346: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991346
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#991362: unblock: klog/1.4.6-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ja...@debian.org
Please unblock package klog
[ Reason ]
KLog has evolved a lot since 1.4.6. It is now in 1.7 and a lot of bugs has
been solved since then by the upstream.
[ Impact ]
Debian (and derivatives) users will be blocked with an old version.
[ Tests ]
Manual tests have been done.
[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
Documented changes in the d/changelog are only affecting to the Debian
packages. Most of the changes are in the upstream.
There is also a list of fixed bugs in the upstream's Changelog
unblock klog/1.4.6-1
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/share/klog/translations/klog_ca.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_da.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_de.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_es.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_fi.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_fr.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_hr.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_it.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_ja.qm
-rw-r--r-- root/root /usr/share/klog/translations/klog_pl.qm
Control files: lines which differ (wdiff format)
Depends: libc6 (>= 2.14), libgcc-s1 (>= 3.0), libhamlib4, libqt5charts5 (>=
5.7.1), libqt5core5a (>= 5.15.1), libqt5gui5 (>= [-5.3.0)-] {+5.8.0)+} |
libqt5gui5-gles (>= [-5.3.0),-] {+5.8.0),+} libqt5network5 (>= 5.14.1),
libqt5printsupport5 (>= 5.0.2), libqt5serialport5 (>= 5.6.0), libqt5sql5 (>=
5.10.0), libqt5widgets5 (>= 5.2.0~alpha1), libstdc++6 (>= 4.1.1),
libqt5sql5-sqlite
Installed-Size: [-4461-] {+3289+}
Version: [-1.4.7-1-] {+1.7-1+}
Processed: Block fix by unblock request
Processing commands for cont...@bugs.debian.org: > block 991332 by 991359 Bug #991332 [liquidsoap] Liquidsoap is searching at the wrong place for pervasives script libraries 991332 was not blocked by any bugs. 991332 was not blocking any bugs. Added blocking bug(s) of 991332: 991359 > End of message, stopping processing here. Please contact me if you need assistance. -- 991332: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991332 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#991360: unblock: nftables/0.9.8-3.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: Arturo Borrero Gonzalez Please unblock package nftables [ Reason ] Fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991309 Under certain conditions nftables tends to be greedy and can delete too much rules. This was identified via an issue to firewalld which had a test that failed on it [1] but was then found and fixed in nftables [2]. [ Impact ] The change looks bigger than it is as it moves code around to be available earlier in the code. It really comes down to dependency killing of rules and should not have a different impact to nftables than that. [ Tests ] While the Debian tests skip the tests e.g. of firewalld [3] I have uploaded the same to Ubuntu where all the tests (including those that failed due to the issue) already completed. On this upload the debci will again skip the tests that would have flagged this bug, others will run but they have worked before and will afterwards. [ Risks ] I'd hope that it is low as it is not just from git, but also part of an official release (0.9.9) already. We don't want to bump versions so late, but this gives some extra confidence in the testing that was done. As mentioned above the risk should be limited to the dependent rule removal. [ Other info ] * I've prepared a debdiff (attached) which matches testing vs unstable at the moment that the request here asks to unblock. * The unstable version has just been uploaded, please give it some time to build and be tested (by tools and myself), but I wanted to give a heads up as early as possible. P.S. The usual maintainer asked for an NMU and driving the unblocking, details on the bug we fix that is linked above. [1]: https://github.com/firewalld/firewalld/issues/752 [2]: https://git.netfilter.org/nftables/commit/?id=533565244d88a [3]: https://ci.debian.net/data/autopkgtest/testing/amd64/f/firewalld/13738304/log.gz -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd fix-debian-991309.debdiff Description: Binary data
Bug#991359: unblock: liquidsoap/1.4.3-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package liquidsoap
Liquidsoap is a scripting language for multimedia. It depends
on pervasive libraries to achieve much of the built-in
functions that user scripts can call. Currently these are installed in
the incorrect location, which cannot be found by liquidsoap (#991332).
The link is for the pervious version of the package and was accidentally
not updated when the latest upstream version was released. The new
changes attached correct the link and add autopkg tests to prevent a
regretion in future.
If this is not fixed user scripts that use any built-in functions would
be broken. This is almost all scripts, as even the get-started tutorial
script in the liquidsoap documentation uses 'mksafe' from those
functions [1]. There is a workaround that users can perform, but is not
very evident from the error message given by liquidsoap:
# mv /usr/share/liquidsoap/1.4.2 /usr/share/liquidsoap/1.4.3
Liquidsoap is a leaf package and this is a trvial change of an obvious
mistake.
[1]
https://www.liquidsoap.info/doc-1.4.4/quick_start.html#that-source-is-fallible
[ 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 liquidsoap/1.4.3-3
diff -Nru liquidsoap-1.4.3/debian/changelog liquidsoap-1.4.3/debian/changelog
--- liquidsoap-1.4.3/debian/changelog 2021-07-21 16:18:07.0 +0200
+++ liquidsoap-1.4.3/debian/changelog 2020-12-22 09:17:12.0 +0200
@@ -1,9 +1,3 @@
-liquidsoap (1.4.3-3) unstable; urgency=medium
-
- * Fix pervasive libraries symlink (Closes: 991332)
-
- -- Kyle Robbertze Wed, 21 Jul 2021 16:18:07 +0200
-
liquidsoap (1.4.3-2) unstable; urgency=medium
* Set BYTE install correctly (Closes: #972272)
diff -Nru liquidsoap-1.4.3/debian/liquidsoap.links
liquidsoap-1.4.3/debian/liquidsoap.links
--- liquidsoap-1.4.3/debian/liquidsoap.links2021-07-21 16:04:28.0
+0200
+++ liquidsoap-1.4.3/debian/liquidsoap.links2020-05-22 12:16:51.0
+0200
@@ -1 +1 @@
-usr/share/liquidsoap/libs usr/share/liquidsoap/1.4.3/libs
+usr/share/liquidsoap/libs usr/share/liquidsoap/1.4.2/libs
diff -Nru liquidsoap-1.4.3/debian/README.source
liquidsoap-1.4.3/debian/README.source
--- liquidsoap-1.4.3/debian/README.source 2021-07-21 14:16:57.0
+0200
+++ liquidsoap-1.4.3/debian/README.source 1970-01-01 02:00:00.0
+0200
@@ -1,6 +0,0 @@
-Updating the upstream source
-
-
-When the upstream version changes, you will need to update
-debian/liquidsoap.links to link the pervasive scripts into the correct
-directory.
diff -Nru liquidsoap-1.4.3/debian/tests/control
liquidsoap-1.4.3/debian/tests/control
--- liquidsoap-1.4.3/debian/tests/control 2021-07-21 15:40:31.0
+0200
+++ liquidsoap-1.4.3/debian/tests/control 1970-01-01 02:00:00.0
+0200
@@ -1 +0,0 @@
-Tests: pervasive-libraries
diff -Nru liquidsoap-1.4.3/debian/tests/pervasive-libraries
liquidsoap-1.4.3/debian/tests/pervasive-libraries
--- liquidsoap-1.4.3/debian/tests/pervasive-libraries 2021-07-21
16:06:10.0 +0200
+++ liquidsoap-1.4.3/debian/tests/pervasive-libraries 1970-01-01
02:00:00.0 +0200
@@ -1,4 +0,0 @@
-#!/usr/bin/liquidsoap --check
-stream = playlist("")
-source = output.icecast(%mp3, host="localhost", port=8000, mount="listen.m3u",
password="hackme")
-mksafe(source(mksafe(stream)))
Re: Finding a tentative bullseye release date
Hi, On Tue, 2021-07-20 at 22:35 +0200, Paul Gevers wrote: > We currently don't have any day yet with all involved > teams comfortably present, the one coming closest is 4 September. > Somebody from ftp available on 14 august? That should be doable. Ansgar
Bug#991336: marked as done (unblock: freedombox/21.4.4)
Your message dated Wed, 21 Jul 2021 10:07:23 + with message-id and subject line unblock freedombox has caused the Debian Bug report #991336, regarding unblock: freedombox/21.4.4 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.) -- 991336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991336 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: jvalle...@mailbox.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please unblock package freedombox [ Reason ] freedombox 21.4.4 is a fix for #991292. The freedombox dist-upgrade feature normally sets an apt-mark hold on the freedombox package, to prevent the system from becoming unreachable. The hold is set and removed within a try/finally block. However, it is possible that the upgrade process is killed before it is completed, and that the hold is left on the freedombox package. To recover from this state, we can check for a hold that is incorrectly left on the package. We just need to distinguish when the package is temporarily held during upgrade, or purposely held by administrator. We use a flag written to disk to indicate that a hold was placed by freedombox upgrade script. Here are the specific changes: * action_utils: Separate function to hold freedombox package * action_utils: Use flag to indicate freedombox package has been held * upgrades: Check for held freedombox package in manual update * upgrades: Check for held freedombox package daily * action_utils: Don't print when unholding freedombox package [ Impact ] The impact is that if FreedomBox users rely on the automatic dist-upgrade feature, there is a chance that after it completes, they will need to manually remove the hold on the freedombox package. [ Tests ] I tested the following: 1. A hold placed on the freedombox package by the freedombox upgrade script (indicated by flag on disk) will eventually be removed. 2. A hold on the freedombox package by system administrator (no flag on disk) will not be removed. 3. All applications available through FreedomBox can be installed, and no hold is left on freedombox package. 4. Package upgrades using unattended-upgrades are not impacted. [ Risks ] The code is fairly understandable and has been thoroughly tested in a FreedomBox system. No other packages are affected. [ 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 freedombox/21.4.4 -BEGIN PGP SIGNATURE- iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmD3TsUWHGp2YWxsZXJv eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICI3iD/9dSmDucHyok7iBIK/V9Z0aKsd3 0TwhR8el9UCpjqMprn9UkXDjwG5IPXWdRYe8KkShApeWTsxMY/3KrPirUa/1D4Hn 9bJiG//MTee8myeN3rYOC2WUupnm9Q0B4jvBBTo9rBGbRddu3nVfSTf6MLgRBKyB K+B4sJZE732JWbfGIw9e7sufKGHiXq1P3I+r/9LhVhvaOKMyQFHZgxT5I7KYJs0y usKRuwWValA9PSd2WVBPji3iJh5/w7HQKFmSsRR3H+xZ0jfR+x+e3bCj/jziR2ju 86U7yDVFfv8n/7JtwHm410GAd1ZgNYh45boPDTRONNGMU+NoukkWN/tbLI5hv5qs D9ftf0bYaYfJIBDWrKDea+1EGJUR9ZZKXTnwPoQxrQl5PhLSrDlgmH5/69Kqrli6 DQHBOtlxeortq92OwPHA4uUL2STL9p6G7+qGD61qI7OLZr1le8EQ/yooXg6cO7yq t4Tg7+kKWgRyTzn5uuLhO+mqBUK0+PFEeWyfXaZVOtGjmydZJDgBSMszq5pckwYG 9HEYPp6GH+W2LvWdZvuHZ5sAV8XG7xR7oHCAa8DP1YJko8yAK3IBHHz3mEznEttC TytO0YRlYG85P4mOiQaYpJXWLFR18opBkvoDFPhh2WWGParETHx5pyb34MDMU/Dt MfKQ3AT/LOFLvwyBOA== =xLE8 -END PGP SIGNATURE- diff -Nru freedombox-21.4.3/actions/packages freedombox-21.4.4/actions/packages --- freedombox-21.4.3/actions/packages 2021-07-07 10:32:34.0 -0400 +++ freedombox-21.4.4/actions/packages 2021-07-16 09:07:51.0 -0400 @@ -18,9 +18,8 @@ import apt_inst import apt_pkg from plinth import cfg -from plinth.action_utils import apt_hold, run_apt_command - -LOCK_FILE = '/var/lib/dpkg/lock' +from plinth.action_utils import (apt_hold_freedombox, is_package_manager_busy, + run_apt_command) logger = logging.getLogger(__name__) @@ -93,7 +92,7 @@ extra_arguments += ['-o', 'Dpkg::Options::=--force-confmiss'] subprocess.run(['dpkg', '--configure', '-a']) -with apt_hold(): +with apt_hold_freedombox(): run_apt_command(['--fix-broken', 'install']) returncode = run_apt_command(['install'] + extra_arguments + arguments.packages) @@ -115,12 +114,10 @@ def subcommand_is_package_manager_busy(_): -"""Return whether package manager is busy. -This command uses the `lsof` comma
Bug#991103: marked as done (unblock: collectd/5.12.0-7 (pre-approval))
Your message dated Wed, 21 Jul 2021 10:08:12 +
with message-id
and subject line unblock collectd
has caused the Debian Bug report #991103,
regarding unblock: collectd/5.12.0-7 (pre-approval)
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.)
--
991103: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991103
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ken...@xdump.org
Please unblock package collectd
[ Reason ]
Fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982294
If collection3 is set up(not enabled by default), the following error is sent
to logs repeatedly.
FastCGI sent in stderr: "CGI::param called in list context from
/usr/share/doc/collectd-core/examples/collection3/lib/
Collectd/Graph/Common.pm line 529, this can lead to vulnerabilities. See the
warning in "Fetching the value or values of a single named parameter" at
/usr/share/perl5/CGI.pm line 412"
This is not actually assigned as CVE-, but it is unexpected situation.
[ Impact ]
It doesn't break collectd behavior at all.
It only fixes the issue about generation of tons of warning messages
about inappropriate usage of param() via bundled web interface utility
(collection3).
[ Tests ]
Not ready for automated test because it need to run collection3 as a CGI.
So, I manually tested attached patch.
[ Risks ]
Low, because very limited reverse dependency and it is only affected when web
interface is enabled.
% LANG=C apt rdepends collectd
collectd
Reverse Depends:
Replaces: collectd-utils (<< 4.6.1-1~)
Recommends: kcollectd
Suggests: drraw
Suggests: libcollectdclient1
Replaces: collectd-core (<< 4.8.2-1~)
Recommends: collectd-utils
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
I've prepared debdiff patch.
unblock collectd/5.12.0-7
diff -Nru collectd-5.12.0/debian/changelog collectd-5.12.0/debian/changelog
--- collectd-5.12.0/debian/changelog 2021-06-02 00:56:33.0 +0900
+++ collectd-5.12.0/debian/changelog 2021-07-14 21:46:02.0 +0900
@@ -1,3 +1,10 @@
+collectd (5.12.0-7) unstable; urgency=medium
+
+ * Team upload.
+ * Fix CGI::param error in collection3 (Closes: 982294)
+
+ -- Kentaro Hayashi Wed, 14 Jul 2021 21:46:02 +0900
+
collectd (5.12.0-6) unstable; urgency=medium
* [b4e7861] collectd-dev: Add missing header files again.
diff -Nru collectd-5.12.0/debian/patches/cgi-param-in-list-context.patch collectd-5.12.0/debian/patches/cgi-param-in-list-context.patch
--- collectd-5.12.0/debian/patches/cgi-param-in-list-context.patch 1970-01-01 09:00:00.0 +0900
+++ collectd-5.12.0/debian/patches/cgi-param-in-list-context.patch 2021-07-14 21:46:02.0 +0900
@@ -0,0 +1,58 @@
+From: Kentaro Hayashi
+Subject: Fix CGI::param error in collection3
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982294
+Forwarded: https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/6
+
+When using collection3 as a CGI, the following error is sent to logs repeatedly.
+This MR fixes it:
+
+ FastCGI sent in stderr: "CGI::param called in list context from /usr/share/doc/collectd-core/examples/collection3/lib/Collectd/Graph/Common.pm line 529, this can lead to vulnerabilities. See the warning in "Fetching the value or values of a single named parameter" at /usr/share/perl5/CGI.pm line 412"
+
+This is caused by inappropriate usage of param(),
+it should be handled as a scalar or should be treated by multi_param() explicitly.
+
+Closes: #982294
+
+ref. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982294
+
+--- a/contrib/collection3/lib/Collectd/Graph/Common.pm
b/contrib/collection3/lib/Collectd/Graph/Common.pm
+@@ -526,7 +526,7 @@
+ for (qw(hostname plugin plugin_instance type type_instance))
+ {
+ my $part = $_;
+-my @temp = param ($part);
++my @temp = multi_param ($part);
+ if (!@temp)
+ {
+ next;
+@@ -547,9 +547,9 @@
+ sub get_timespan_selection
+ {
+ my $ret = 86400;
+- if (param ('timespan'))
++ if (scalar param ('timespan'))
+ {
+-my $temp = int (param ('timespan'));
++my $temp = int (scalar param ('timespan'));
+ if ($temp && ($temp > 0))
+ {
+ $ret = $temp;
+@@ -568,7 +568,7 @@
+ $ret{$_} = 0;
+ }
+
+- for (param ('hostname'))
++ for (multi_param ('hostname'))
+ {
+ my $host = _sanitize_generic_allow_minus ($_);
+ if (defined ($r
Bug#991345: marked as done (unblock: aspell/0.60.8-3)
Your message dated Wed, 21 Jul 2021 10:03:46 +
with message-id
and subject line unblock aspell
has caused the Debian Bug report #991345,
regarding unblock: aspell/0.60.8-3
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.)
--
991345: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991345
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package aspell
This upload deals with CVE-2019-25051, fixing a buffer overflow. This has
been reported in Debian BTS as severity grave #991307, closed by this
upload. Package is already built for all arches.
000-objstack-assert-that-the-alloc-size-will-fit-within-.patch is borrowed
from upstream (attached along with the debdiff for easier inspection).
Pasting from #991307 for further info:
--- 8< --
The following vulnerability was published for aspell.
CVE-2019-25051[0]:
| objstack in GNU Aspell 0.60.8 has a heap-based buffer overflow in
| acommon::ObjStack::dup_top (called from acommon::StringMap::add and
| acommon::Config::lookup_list).
https://github.com/google/oss-fuzz-vulns/blob/main/vulns/aspell/OSV-2020-521.yaml
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18462
Patch:
https://github.com/gnuaspell/aspell/commit/0718b375425aad8e54e1150313b862e4c6fd324a
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-2019-25051
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25051
Please adjust the affected versions in the BTS as needed.
--- 8< --
Regards,
unblock aspell/0.60.8-3
diff -Nru aspell-0.60.8/debian/changelog aspell-0.60.8/debian/changelog
--- aspell-0.60.8/debian/changelog 2020-12-28 15:24:45.0 +0100
+++ aspell-0.60.8/debian/changelog 2021-07-20 23:42:34.0 +0200
@@ -1,3 +1,11 @@
+aspell (0.60.8-3) unstable; urgency=medium
+
+ * 000-objstack-assert-that-the-alloc-size-will-fit-within-.patch:
+Fix CVE-2019-25051: objstack in GNU Aspell 0.60.8 has a heap-based
+buffer overflow (Closes: #991307).
+
+ -- Agustin Martin Domingo Tue, 20 Jul 2021 23:42:34 +0200
+
aspell (0.60.8-2) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch
--- aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch 1970-01-01 01:00:00.0 +0100
+++ aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch 2021-07-20 23:37:07.0 +0200
@@ -0,0 +1,102 @@
+From 0718b375425aad8e54e1150313b862e4c6fd324a Mon Sep 17 00:00:00 2001
+From: Kevin Atkinson
+Date: Sat, 21 Dec 2019 20:32:47 +
+Bug-Debian: https://bugs.debian.org/991307
+Subject: [PATCH] objstack: assert that the alloc size will fit within a chunk
+ to prevent a buffer overflow
+
+Bug found using OSS-Fuze.
+-
+https://security-tracker.debian.org/tracker/CVE-2019-25051
+---
+ common/objstack.hpp | 18 ++
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/common/objstack.hpp b/common/objstack.hpp
+index 3997bf7..bd97ccd 100644
+--- a/common/objstack.hpp
b/common/objstack.hpp
+@@ -5,6 +5,7 @@
+ #include "parm_string.hpp"
+ #include
+ #include
++#include
+
+ namespace acommon {
+
+@@ -26,6 +27,12 @@ class ObjStack
+ byte * temp_end;
+ void setup_chunk();
+ void new_chunk();
++ bool will_overflow(size_t sz) const {
++return offsetof(Node,data) + sz > chunk_size;
++ }
++ void check_size(size_t sz) {
++assert(!will_overflow(sz));
++ }
+
+ ObjStack(const ObjStack &);
+ void operator=(const ObjStack &);
+@@ -56,7 +63,7 @@ public:
+ void * alloc_bottom(size_t size) {
+ byte * tmp = bottom;
+ bottom += size;
+-if (bottom > top) {new_chunk(); tmp = bottom; bottom += size;}
++if (bottom > top) {check_size(size); new_chunk(); tmp = bottom; bottom += size;}
+ return tmp;
+ }
+ // This alloc_bottom will insure that the object is aligned based on the
+@@ -66,7 +73,7 @@ public:
+ align_bottom(align);
+ byte * tmp = bottom;
+ bottom += size;
+-if (bottom > top) {new_chunk(); goto loop;}
++if (bo
Bug#991346: unblock: aspell/0.60.8-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package aspell
This upload deals with CVE-2019-25051, fixing a buffer overflow. This has
been reported in Debian BTS as severity grave #991307, closed by this
upload. Package is already built for all arches.
000-objstack-assert-that-the-alloc-size-will-fit-within-.patch is borrowed
from upstream (attached along with the debdiff for easier inspection).
Pasting from #991307 for further info:
--- 8< --
The following vulnerability was published for aspell.
CVE-2019-25051[0]:
| objstack in GNU Aspell 0.60.8 has a heap-based buffer overflow in
| acommon::ObjStack::dup_top (called from acommon::StringMap::add and
| acommon::Config::lookup_list).
https://github.com/google/oss-fuzz-vulns/blob/main/vulns/aspell/OSV-2020-521.yaml
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18462
Patch:
https://github.com/gnuaspell/aspell/commit/0718b375425aad8e54e1150313b862e4c6fd324a
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-2019-25051
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25051
Please adjust the affected versions in the BTS as needed.
--- 8< --
Regards,
unblock aspell/0.60.8-3
diff -Nru aspell-0.60.8/debian/changelog aspell-0.60.8/debian/changelog
--- aspell-0.60.8/debian/changelog 2020-12-28 15:24:45.0 +0100
+++ aspell-0.60.8/debian/changelog 2021-07-20 23:42:34.0 +0200
@@ -1,3 +1,11 @@
+aspell (0.60.8-3) unstable; urgency=medium
+
+ * 000-objstack-assert-that-the-alloc-size-will-fit-within-.patch:
+Fix CVE-2019-25051: objstack in GNU Aspell 0.60.8 has a heap-based
+buffer overflow (Closes: #991307).
+
+ -- Agustin Martin Domingo Tue, 20 Jul 2021 23:42:34 +0200
+
aspell (0.60.8-2) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch
--- aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch 1970-01-01 01:00:00.0 +0100
+++ aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch 2021-07-20 23:37:07.0 +0200
@@ -0,0 +1,102 @@
+From 0718b375425aad8e54e1150313b862e4c6fd324a Mon Sep 17 00:00:00 2001
+From: Kevin Atkinson
+Date: Sat, 21 Dec 2019 20:32:47 +
+Bug-Debian: https://bugs.debian.org/991307
+Subject: [PATCH] objstack: assert that the alloc size will fit within a chunk
+ to prevent a buffer overflow
+
+Bug found using OSS-Fuze.
+-
+https://security-tracker.debian.org/tracker/CVE-2019-25051
+---
+ common/objstack.hpp | 18 ++
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/common/objstack.hpp b/common/objstack.hpp
+index 3997bf7..bd97ccd 100644
+--- a/common/objstack.hpp
b/common/objstack.hpp
+@@ -5,6 +5,7 @@
+ #include "parm_string.hpp"
+ #include
+ #include
++#include
+
+ namespace acommon {
+
+@@ -26,6 +27,12 @@ class ObjStack
+ byte * temp_end;
+ void setup_chunk();
+ void new_chunk();
++ bool will_overflow(size_t sz) const {
++return offsetof(Node,data) + sz > chunk_size;
++ }
++ void check_size(size_t sz) {
++assert(!will_overflow(sz));
++ }
+
+ ObjStack(const ObjStack &);
+ void operator=(const ObjStack &);
+@@ -56,7 +63,7 @@ public:
+ void * alloc_bottom(size_t size) {
+ byte * tmp = bottom;
+ bottom += size;
+-if (bottom > top) {new_chunk(); tmp = bottom; bottom += size;}
++if (bottom > top) {check_size(size); new_chunk(); tmp = bottom; bottom += size;}
+ return tmp;
+ }
+ // This alloc_bottom will insure that the object is aligned based on the
+@@ -66,7 +73,7 @@ public:
+ align_bottom(align);
+ byte * tmp = bottom;
+ bottom += size;
+-if (bottom > top) {new_chunk(); goto loop;}
++if (bottom > top) {check_size(size); new_chunk(); goto loop;}
+ return tmp;
+ }
+ char * dup_bottom(ParmString str) {
+@@ -79,7 +86,7 @@ public:
+ // always be aligned as such.
+ void * alloc_top(size_t size) {
+ top -= size;
+-if (top < bottom) {new_chunk(); top -= size;}
++if (top < bottom) {check_size(size); new_chunk(); top -= size;}
+ return top;
+ }
+ // This alloc_top will insure that the object is aligned based on
+@@ -88,7 +95,7 @@ public:
+ {loop:
+ top -= size;
+ align_top(align);
+-if (top < bottom) {new_chunk(); goto loop;}
++if (top < bottom) {check_size(size); new_chunk(); goto loop;}
+ return top;
+ }
+ char * dup_top(ParmString str) {
+@@ -117,6 +124,7 @@ public:
+ void * alloc_temp(size
Bug#991335: unblock: supertuxkart (pre-approval)
Control: tags -1 moreinfo On 2021-07-21 00:12:49, Reiner Herrmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Dear release team, > > this is a request for pre-approval of a supertuxkart upload. > > The upstream tarball of supertuxkart 1.2+ds-2 currently includes data > files that are not free (#990368). Additionaly the d/copyright file is > lacking license information for a few additional resources (only data files). > > To fix this bug, the two non-free karts will get removed from the upstream > tarball. But as removal of these files would cause a regression in online > multiplayer games, upstream provided two patches (+1 patch that fixes a > memory leak in one of these patches) that keep network compatibility with > other players intact. > > Additionaly I'm currently in contact with an upstream contributor who is > investigating the remaining copyright/license issues. > To fix them, the plan is to amend d/copyright where possible > (investigations are currently ongoing), or to replace unknown/non-free files > with free alternatives. > > I noticed that supertuxkart is marked for autoremoval on August 3rd > currently, which is probably after the bullseye release. > Does this mean supertuxkart 1.2+ds-2 will be part of bullseye and can > then still be fixed by a stable-proposed-update? Or does the upload > and migration to bullseye have to happen before July 31st? If a package is currently on the autoremoval list, we will make judgement calls on a case by case basis if the package should stay in bullseye or if we should remove it before the release. If the autoremoval date is after the tentative release date, this just means that we may manually remove the package if we deem that to be the right action. > Below is the full list of files that would get removed from the upstream > tarball: > > data/karts/beastie/beastie-icon.png > data/karts/beastie/beastie.spm > data/karts/beastie/beastie_kart_colorizationMask.png > data/karts/beastie/beastie_kart_diffuse.png > data/karts/beastie/beastie_kart_gloss.png > data/karts/beastie/beastie_kart_leftDoor.png > data/karts/beastie/beastie_kart_leftDoor_colorizationMask.png > data/karts/beastie/beastie_kart_leftDoor_gloss.png > data/karts/beastie/beastie_n_kart_wheel_colorizationMask.png > data/karts/beastie/beastie_n_kart_wheel_diffuse.png > data/karts/beastie/beastie_n_kart_wheel_gloss.png > data/karts/beastie/beastie_shadow.png > data/karts/beastie/beastie_texture.png > data/karts/hexley/hexley.spm > data/karts/hexley/hexley_dashboard_diffuse.png > data/karts/hexley/hexley_dashboard_gloss.png > data/karts/hexley/hexley_diffuse.png > data/karts/hexley/hexley_gloss.png > data/karts/hexley/hexley_kart_Normal.png > data/karts/hexley/hexley_kart_colorizationMask.png > data/karts/hexley/hexley_kart_diffuse.png > data/karts/hexley/hexley_kart_frontGlass.png > data/karts/hexley/hexley_kart_gloss.png > data/karts/hexley/hexley_shadow.png > data/karts/hexley/hexley_wheel_Normal.png > data/karts/hexley/hexley_wheel_colorizationMask.png > data/karts/hexley/hexley_wheel_diffuse.png > data/karts/hexley/hexley_wheel_gloss.png > data/karts/hexley/hexley_window.png > data/karts/hexley/hexleyicon.png > data/karts/hexley/hexleyicon32.png > > Attached are the mentioned upstream patches. Could you please provide a debdiff between the version in testing and what you propose to fix the DFSG issue? Cheers > > Kind regards, > Reiner > From 851290d4c866130abb22ee61114016378af4cb45 Mon Sep 17 00:00:00 2001 > From: Benau > Date: Sun, 18 Jul 2021 00:49:49 +0800 > Subject: [PATCH] Add code to generate official karts list > > --- > data/official_karts.xml | 21 ++ > sources.cmake| 2 +- > src/karts/official_karts.cpp | 128 +++ > src/karts/official_karts.hpp | 20 ++ > src/main.cpp | 9 +++ > 5 files changed, 179 insertions(+), 1 deletion(-) > create mode 100644 data/official_karts.xml > create mode 100644 src/karts/official_karts.cpp > create mode 100644 src/karts/official_karts.hpp > > diff --git a/data/official_karts.xml b/data/official_karts.xml > new file mode 100644 > index 000..671aadf369e > --- /dev/null > +++ b/data/official_karts.xml > @@ -0,0 +1,21 @@ > + > + > + length="0.943" gravity-shift="0 0.2829 0"/> > + length="1.476" gravity-shift="0 0.382 0"/> > + length="1.49" gravity-shift="0 0.4235 0"/> > + length="1.146" gravity-shift="0 0.3438 0"/> > + length="1.272" gravity-shift="0 0.307 0"/> > + length="1.345" gravity-shift="0 0.4035 0"/> > + length="1.608" gravity-shift="0 0.429 0"/> > + length="1.227" gravity-shift="0 0.3681 0"/> > + length="1.588" gravity-shift="0 0.4285 0"/> > + length="1.413" gravity-shift="0 0.3225 0"/> > + length="1.243" gravity-shift="0 0.3135 0"/> > + length="1.573" gravity-shift="0 0.3105 0"/> > + length="1.152" gra
Bug#991345: unblock: aspell/0.60.8-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package aspell
This upload deals with CVE-2019-25051, fixing a buffer overflow. This has
been reported in Debian BTS as severity grave #991307, closed by this
upload. Package is already built for all arches.
000-objstack-assert-that-the-alloc-size-will-fit-within-.patch is borrowed
from upstream (attached along with the debdiff for easier inspection).
Pasting from #991307 for further info:
--- 8< --
The following vulnerability was published for aspell.
CVE-2019-25051[0]:
| objstack in GNU Aspell 0.60.8 has a heap-based buffer overflow in
| acommon::ObjStack::dup_top (called from acommon::StringMap::add and
| acommon::Config::lookup_list).
https://github.com/google/oss-fuzz-vulns/blob/main/vulns/aspell/OSV-2020-521.yaml
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18462
Patch:
https://github.com/gnuaspell/aspell/commit/0718b375425aad8e54e1150313b862e4c6fd324a
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-2019-25051
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25051
Please adjust the affected versions in the BTS as needed.
--- 8< --
Regards,
unblock aspell/0.60.8-3
diff -Nru aspell-0.60.8/debian/changelog aspell-0.60.8/debian/changelog
--- aspell-0.60.8/debian/changelog 2020-12-28 15:24:45.0 +0100
+++ aspell-0.60.8/debian/changelog 2021-07-20 23:42:34.0 +0200
@@ -1,3 +1,11 @@
+aspell (0.60.8-3) unstable; urgency=medium
+
+ * 000-objstack-assert-that-the-alloc-size-will-fit-within-.patch:
+Fix CVE-2019-25051: objstack in GNU Aspell 0.60.8 has a heap-based
+buffer overflow (Closes: #991307).
+
+ -- Agustin Martin Domingo Tue, 20 Jul 2021 23:42:34 +0200
+
aspell (0.60.8-2) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch
--- aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch 1970-01-01 01:00:00.0 +0100
+++ aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch 2021-07-20 23:37:07.0 +0200
@@ -0,0 +1,102 @@
+From 0718b375425aad8e54e1150313b862e4c6fd324a Mon Sep 17 00:00:00 2001
+From: Kevin Atkinson
+Date: Sat, 21 Dec 2019 20:32:47 +
+Bug-Debian: https://bugs.debian.org/991307
+Subject: [PATCH] objstack: assert that the alloc size will fit within a chunk
+ to prevent a buffer overflow
+
+Bug found using OSS-Fuze.
+-
+https://security-tracker.debian.org/tracker/CVE-2019-25051
+---
+ common/objstack.hpp | 18 ++
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/common/objstack.hpp b/common/objstack.hpp
+index 3997bf7..bd97ccd 100644
+--- a/common/objstack.hpp
b/common/objstack.hpp
+@@ -5,6 +5,7 @@
+ #include "parm_string.hpp"
+ #include
+ #include
++#include
+
+ namespace acommon {
+
+@@ -26,6 +27,12 @@ class ObjStack
+ byte * temp_end;
+ void setup_chunk();
+ void new_chunk();
++ bool will_overflow(size_t sz) const {
++return offsetof(Node,data) + sz > chunk_size;
++ }
++ void check_size(size_t sz) {
++assert(!will_overflow(sz));
++ }
+
+ ObjStack(const ObjStack &);
+ void operator=(const ObjStack &);
+@@ -56,7 +63,7 @@ public:
+ void * alloc_bottom(size_t size) {
+ byte * tmp = bottom;
+ bottom += size;
+-if (bottom > top) {new_chunk(); tmp = bottom; bottom += size;}
++if (bottom > top) {check_size(size); new_chunk(); tmp = bottom; bottom += size;}
+ return tmp;
+ }
+ // This alloc_bottom will insure that the object is aligned based on the
+@@ -66,7 +73,7 @@ public:
+ align_bottom(align);
+ byte * tmp = bottom;
+ bottom += size;
+-if (bottom > top) {new_chunk(); goto loop;}
++if (bottom > top) {check_size(size); new_chunk(); goto loop;}
+ return tmp;
+ }
+ char * dup_bottom(ParmString str) {
+@@ -79,7 +86,7 @@ public:
+ // always be aligned as such.
+ void * alloc_top(size_t size) {
+ top -= size;
+-if (top < bottom) {new_chunk(); top -= size;}
++if (top < bottom) {check_size(size); new_chunk(); top -= size;}
+ return top;
+ }
+ // This alloc_top will insure that the object is aligned based on
+@@ -88,7 +95,7 @@ public:
+ {loop:
+ top -= size;
+ align_top(align);
+-if (top < bottom) {new_chunk(); goto loop;}
++if (top < bottom) {check_size(size); new_chunk(); goto loop;}
+ return top;
+ }
+ char * dup_top(ParmString str) {
+@@ -117,6 +124,7 @@ public:
+ void * alloc_temp(size
Processed: Re: Bug#991335: unblock: supertuxkart (pre-approval)
Processing control commands: > tags -1 moreinfo Bug #991335 [release.debian.org] unblock: supertuxkart (pre-approval) Added tag(s) moreinfo. -- 991335: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991335 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990990: unblock: libcgroup/2.0
El 20/07/21 a las 20:57, Thomas Goirand escribió: > On 7/19/21 3:07 PM, Santiago Ruano Rincón wrote: > > On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers wrote: > >> Hi, > >> > >> On 12-07-2021 18:45, Michael Biebl wrote: > >>> This was already discussed in > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022 > >>> > >>> My takeaway from that discussion was, that rdeps of cgroup-tools, would > >>> itself have to be made cgroupv2 aware, especially OpenStack and its > >>> components. > >> > >> That resembles my understanding of that discussion too. > > > > Mine too. > > > > zigo, are there any news from openstack about this? > > There is no way that Cinder and Nova produce a patch for OpenStack > Victoria (the release in Bullseye), which was released 9 months ago. > They are *planning* to use Cgroups v2 right now, but I'm not even sure > it's going to be ready for next version in October. > > >>> Have those rdeps been tested successfully with libcgroup/cgroup-tools > >>> from experimental? > >> > >> I'm not in favor of doing this transition now. > >> > > > > Please, keep in mind this comment, made before the release of 2.0: > > "we are planning something for next week. The version number will > > probably be 2.0 - with expectation that the v2 cycle will have > > continously breaking ABI. When we are happy where it is, we will push > > out v3 which will then maintain ABI through its lifetime." > > https://github.com/libcgroup/libcgroup/issues/12#issuecomment-825816328 > > This means that probably, it's best that Bullseye continues to support > Cgroups v1 (which isn't the case currently if we don't allow libcgroup > 2.0 in). I don't understand your sentences between parenthesis, sorry. What do you mean? > On 7/19/21 11:48 PM, Adrian Bunk wrote: > > Based on soname and package name, the libcgroup1 in experimental > > claims to be ABI compatible with the library in buster. > > Changes in bookworm would be a normal library transition. > > > > OpenStack uses cgroup-tools, which is the only reason why libcgroup > > stayed in bullseye at all. > > My suggestion was basically asking whether 2.0 would be better for > > using with the version of OpenStack in bullseye, this is similar to > > your question to Thomas above. > > > > If cgroup-tools in *bookworm* would be incompatible with OpenStack in > > bullseye, this could be resolved with Breaks on the bullseye versions > > of cinder-common/nova-compute - this is irrelevant for discussing > > which version of libcgroup to ship in bullseye. > > Maybe I'm not understanding fully, though what I think I've read in this > discussion, is that libcgroup in experimental makes it possible to use > cgcreate / cgset without any additional kernel command line parameters > (please let me know if I'm mistaking). That is partially true. Those kernel command lines parameters you are referring too enable cgroupv1 (from systemd, if I am not wrong) > On the OpenStack side, that's the > only thing which is needed. Not exactly. The file structure (and resources) differ between cgroupv1 and cgroupv2. One has a separate hierarchy of resources, the other has a unified hierarchy. See https://chrisdown.name/talks/cgroupv2/cgroupv2-fosdem.pdf I don't have my irc log here, but I think I already gave you an example of the changes needed. https://sources.debian.org/src/cinder/2:17.0.1-1/cinder/privsep/cgroup.py/?hl=28#L28 That blkio resource path from cgroupv1 is not supported in cgroupv2 and you have to replace it. For io.max, if I am not wrong. So your code also needs to know what version of control group is enabled to use the correct resource path. It shouldn't be a difficult patch, but someone has to do it, and test it. > Cinder isn't using any library directly, > they just use the cgroup userland binaries. As for Nova, I'm not even > sure it's doing anything but using features from Qemu/Libvirt (this > would have to be checked). At least, doing a "grep -r cgcreate" in the > Nova source code returns nothing. > > Cheers, > > Thomas Goirand (zigo)
Bug#990990: unblock: libcgroup/2.0
El 20/07/21 a las 00:48, Adrian Bunk escribió: > On Mon, Jul 19, 2021 at 03:07:49PM +0200, Santiago Ruano Rincón wrote: > > On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers wrote: > > > Hi, > > > > > > On 12-07-2021 18:45, Michael Biebl wrote: > > > > This was already discussed in > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022 > > > > > > > > My takeaway from that discussion was, that rdeps of cgroup-tools, would > > > > itself have to be made cgroupv2 aware, especially OpenStack and its > > > > components. > > > > > > That resembles my understanding of that discussion too. > > > > Mine too. > > > > zigo, are there any news from openstack about this? > > > > > > > > > Have those rdeps been tested successfully with libcgroup/cgroup-tools > > > > from experimental? > > > > > > I'm not in favor of doing this transition now. > > > > > > > Please, keep in mind this comment, made before the release of 2.0: > > "we are planning something for next week. The version number will > > probably be 2.0 - with expectation that the v2 cycle will have > > continously breaking ABI. When we are happy where it is, we will push > > out v3 which will then maintain ABI through its lifetime." > > https://github.com/libcgroup/libcgroup/issues/12#issuecomment-825816328 > > What kind of ABI is this referring to? I am afraid I haven't found any details about this, or asked for them (yet). Sorry for my quick answer. I intended to say that we can't expect the v2 cycle to be stable. But that doesn't necessarily mean it couldn't get into a debian stable release. Sorry if this was just noise. > > Based on soname and package name, the libcgroup1 in experimental > claims to be ABI compatible with the library in buster. > Changes in bookworm would be a normal library transition. Indeed. > > OpenStack uses cgroup-tools, which is the only reason why libcgroup > stayed in bullseye at all. > My suggestion was basically asking whether 2.0 would be better for > using with the version of OpenStack in bullseye, this is similar to > your question to Thomas above. > > If cgroup-tools in *bookworm* would be incompatible with OpenStack in > bullseye, this could be resolved with Breaks on the bullseye versions > of cinder-common/nova-compute - this is irrelevant for discussing which > version of libcgroup to ship in bullseye. Yes. Again, sorry for introducing noise. Just for the record, cgroup-tools (e.g. cgcreate or any other tool) in bookworm won't (or shouldn't) be incompatible with OpenStack in bullseye, since those cgroup-tools support cgroupv1 and cgroupv2. But the rdeps *also need to support cgroupv2* to make use of the correct resource paths. It is useless to have libcgroup supporting cgroupv2 in bullseye if the rdeps are not aware of it. I'll give more details in my answer to Thomas. Cheers, -- Santiago
Bug#991283: unblock: mesa/20.3.5-1
On Wed, 21 Jul 2021 at 10:15:12 +0300, Timo Aaltonen wrote: > On 19.7.2021 19.44, Simon McVittie wrote: > > Should the mesa source package be unblocked for bullseye? > > ack For clarity: does this mean "yes, I would like mesa_20.3.5-1 to reach bullseye"? > > There don't seem to be any RC bugs open. The Mesa maintainers would know > > better than I do whether there have been non-RC regression reports. Does your ack mean no regressions have been reported? > >[ ] I reviewed all changes and I approve them After looking at the filtered debdiff, do the Mesa maintainers approve this unblock request? Thanks, smcv
Bug#991283: unblock: mesa/20.3.5-1
On 19.7.2021 19.44, Simon McVittie wrote: Package: release.debian.org Severity: normal Tags: moreinfo User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: m...@packages.debian.org, Timo Aaltonen Should the mesa source package be unblocked for bullseye? It was uploaded to unstable several months ago. Please note that I am not a Mesa maintainer, and I don't know whether the uploader (cc'd) intended this to be for bullseye or not. I've tagged this bug as moreinfo until Mesa maintainers confirm whether they want this in bullseye. If we're too late for 11.0, another option would be to convert this into a mesa/20.3.5-0+deb11u1 upload targeting point release 11.1. [ Reason ] New upstream stable release with various bug fixes. The one I'm particularly interested in is https://bugs.debian.org/983390 which causes crashes and hangs when using third-party Vulkan layers like MangoHUD, but there are lots of bugfixes listed in the upstream release notes. [ Impact ] Users of bullseye who run games etc. will experience various crashes, hangs and rendering artifacts that could have been avoided. [ Tests ] I don't know, I'm not the maintainer. Presumably a lot of users of unstable have been using this version to run games and other graphically-intensive programs in the 116 days since it was uploaded. There don't seem to be any RC bugs open. The Mesa maintainers would know better than I do whether there have been non-RC regression reports. [ Risks ] It's a key package, involved in providing hardware support. If the changes that upstream made in their development branch and then backported into their stable branch are not all correct, then this version could introduce new crashes, hangs and artifacts of a scope similar to the ones it's fixing. [ Checklist ] [ ] all changes are documented in the d/changelog - debian/patches/llvm-12-build-fix.diff is not explicitly documented [ ] I reviewed all changes and I approve them [x] attach debdiff against the package in testing The attached debdiff is lightly filtered to remove changes that appear to be irrelevant (a copy of debian/patches/llvm-12-build-fix.diff in an unintended location, and the JSON file that upstream use to track which commits should/shouldn't be cherry-picked from their development branch). Thanks, smcv ack, and this neatly removes the embarrassing cruft on the source pkg.. -- t
