Bug#1070801: bookworm-pu: package qemu/1:7.2+dfsg-7+deb12u6
09.05.2024 14:53, Michael Tokarev wrote: Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: q...@packages.debian.org, pkg-qemu-de...@lists.alioth.debian.org Control: affects -1 + src:qemu [ Reason ] There were 2 qemu stable/bugfix releases (7.2.10 and 7.2.11) since the previous debian release, fixing a number of various issues. It would be nice to have these fixes in debian too, so debian users will benefit from the qemu stable series. Among others, this release fixes several (low-priority) security issues: CVE-2024-3446 CVE-2024-3447 CVE-2024-26327 CVE-2024-26328 I forgot to mention here which I already mentioned in the previous qemu pu report (#1062044). In this debian release of qemu, I removed revert of a change which supposedly broke suspend-resume cycle of qemu-based VMs and hence broke cryptsetup autopkgtests. The change in question, which is a bugfix, monitor-only-run-coroutine-commands-in-qemu_aio_context.patch, has exactly nothing to do with suspend-resume, it's a red herring. The issue depends on the guest kernel instead, - I *think* it is a memory layout issue instead. With current bookworm kernels, with or without the patch in question, this suspend-resume issue is present for current qemu and for a few older qemu releases too. So I'm dropping this revert in this release, hence making debian qemu sources to match the upstream. Thanks, /mjt
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
On Tue, 6 Feb 2024 19:37:46 +0300 Michael Tokarev wrote: 03.02.2024 12:47, Michael Tokarev wrote: >>> It looks like we broke suspend/resume in this version of qemu. >> Oops. Is that related to the cryptsetup failure, or a separate issue? > > Yes, it is related to cryptsetup autopkgtest failure. It looks > like this is the only place where suspend/resume code in qemu > is actually being used, - it's rather rare to suspend (hybernate) > a virtual machine, and cryptsetup performs testing of how the > encrypted filesystem is unlocked (or not) on resume. So, while the problematic upstream commit fixes quite a few real potential qemu lockups, it introduces a new lockup in suspend- resume-hibernate cycle. The problem isn't understood yet, and we're getting close to the 12.5 release. The problematic upstream commit (on master) is this one: https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 It has links to 2 bugs it is fixing, and there are quite a few other bugs which are fixed too. It turned out this commit was innocent. The bug most likely is somewhere in qemu, but it is triggered by the guest kernel, it looks like, not by this qemu commit. Current bookworm kernels (6.1.19 and 6.1.20) fails in this same suspend/resume test in all current versions of qemu, including the ones with this commit applied, including current qemu master, and including versions much older than that, - including original qemu as initially released with bookworm, before all updates. It is not yet clear what's going on here. But we'll have to live with that somehow, and, - I guess - have to live with the broken cryptsetup autopkgtests. I'm preparing a new upstream stable/bugfix version of qemu 7.2.x for bookworm, which will include a few CVE fixes, many other fixes all other the place, and re-introduction of this commit too, - which, as it turns out, has actually nothing to do with the broken suspend-resume. Thanks, /mjt
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
06.02.2024 20:55, Adam D. Barratt : On Tue, 2024-02-06 at 20:49 +0300, Michael Tokarev wrote: .. The change isn't small per se, as the commit is rather large (mostly due to many changed tests, - it changes order of output in quite some places). Here's the diffstat: monitor/qmp.c | 17 + qapi/qmp-dispatch.c | 24 +- -- This is the relevant bit for size IMO. If you're happy with the result then please upload as soon as you're ready. Yes, I'm happy with the result. Well, - as much as one can be happy here, choosing between one bug or another, - but it is at least a status-quo and we don't have known regressions in debian stable due to this. I just re-ran upstream testsuite just to be extra sure, and am running my bunch of guests as well, everything works as expected so far. I wont try to reproduce the issues this patch (which I'm reverting) fixed, though ;) Uploaded +deb12u5 now, waiting to be picked up. Thank you for the patience and all the work! /mjt
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
06.02.2024 20:33, Adam D. Barratt: On Tue, 2024-02-06 at 19:37 +0300, Michael Tokarev wrote: problematic upstream commit (on master) is this one: https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 Technically we already froze p-u for 12.5 on Sunday evening, as previously announced. If you could get an upload just fixing that single issue with a small change uploaded today then I'd be tempted to accept it anyway. Oh. I knew we're getting late, but not *that* late. The change isn't small per se, as the commit is rather large (mostly due to many changed tests, - it changes order of output in quite some places). Here's the diffstat: monitor/qmp.c | 17 + qapi/qmp-dispatch.c | 24 +--- tests/qemu-iotests/060.out|4 ++-- tests/qemu-iotests/071.out|4 ++-- tests/qemu-iotests/081.out| 16 tests/qemu-iotests/087.out| 12 ++-- tests/qemu-iotests/108.out|2 +- tests/qemu-iotests/109|4 ++-- tests/qemu-iotests/109.out| 78 +- tests/qemu-iotests/117.out|2 +- tests/qemu-iotests/120.out|2 +- tests/qemu-iotests/127.out|2 +- tests/qemu-iotests/140.out|2 +- tests/qemu-iotests/143.out|2 +- tests/qemu-iotests/156.out|2 +- tests/qemu-iotests/176.out| 16 tests/qemu-iotests/182.out|2 +- tests/qemu-iotests/183.out|4 ++-- tests/qemu-iotests/184.out| 32 tests/qemu-iotests/185|6 +++--- tests/qemu-iotests/185.out| 45 + tests/qemu-iotests/191.out| 16 tests/qemu-iotests/195.out| 16 tests/qemu-iotests/223.out| 12 ++-- tests/qemu-iotests/227.out| 32 tests/qemu-iotests/247.out|2 +- tests/qemu-iotests/273.out|8 tests/qemu-iotests/308|4 ++-- tests/qemu-iotests/308.out|2 +- tests/qemu-iotests/tests/qsd-jobs.out |4 ++-- 30 files changed, 173 insertions(+), 201 deletions(-) (as you can see, first two are the gist of it, the rest are the consequences). I'm including a complete revert of this single commit together with all the testsuite changes, ie, exactly as it is, - while the upstream testsuite isn't used in debian directly, it still works, and I'm running it right now locally just to be sure (though it definitely worked before that commit has been initially applied, so it should be okay). Presumably the bugs being fixed by that commit already exist in bookworm's qemu, so not including the commit isn't a regression? Yes, exactly, that's why I wrote about the status-quo. Please also attach a debdiff against the previous upload. Attached.diff -Nru qemu-7.2+dfsg/debian/changelog qemu-7.2+dfsg/debian/changelog --- qemu-7.2+dfsg/debian/changelog 2024-01-30 19:15:04.0 +0300 +++ qemu-7.2+dfsg/debian/changelog 2024-02-06 20:38:06.0 +0300 @@ -1,3 +1,12 @@ +qemu (1:7.2+dfsg-7+deb12u5) bookworm; urgency=medium + + * +revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch +Revert a single upstream change in 7.2.9 which, while fixed a few qemu +lockup bugs, introduced a regression in suspend-resume-hibernate cycle +(triggered by cryptsetup autopkgtest) + + -- Michael Tokarev Tue, 06 Feb 2024 20:38:06 +0300 + qemu (1:7.2+dfsg-7+deb12u4) bookworm; urgency=medium [ Michael Tokarev ] diff -Nru qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch --- qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch 1970-01-01 03:00:00.0 +0300 +++ qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch 2024-02-06 20:36:21.0 +0300 @@ -0,0 +1,1544 @@ +From 84a139b0289470994f8a518034d69186f5ad5bb9 Mon Sep 17 00:00:00 2001 +From: Michael Tokarev +Date: Tue, 6 Feb 2024 20:35:22 +0300 +Subject: [PATCH] Revert "monitor: only run coroutine commands in + qemu_aio_context" + +This reverts commit 8ec90598e922a604c222bdbc6289bed7279dced6. +Causes a regression at least in suspend-resume-hibernate cycle, +let's revert it to restore the status quo for now. +--- + monitor/qmp.c | 17 ++ + qapi/qmp-dispatch.c | 24 + + tests/qemu-iotests/060.out| 4
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
03.02.2024 12:47, Michael Tokarev wrote: It looks like we broke suspend/resume in this version of qemu. Oops. Is that related to the cryptsetup failure, or a separate issue? Yes, it is related to cryptsetup autopkgtest failure. It looks like this is the only place where suspend/resume code in qemu is actually being used, - it's rather rare to suspend (hybernate) a virtual machine, and cryptsetup performs testing of how the encrypted filesystem is unlocked (or not) on resume. So, while the problematic upstream commit fixes quite a few real potential qemu lockups, it introduces a new lockup in suspend- resume-hibernate cycle. The problem isn't understood yet, and we're getting close to the 12.5 release. The problematic upstream commit (on master) is this one: https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 It has links to 2 bugs it is fixing, and there are quite a few other bugs which are fixed too. I can add a revert of this single commit (with all tests) for debian stable (for deb12u5 release) on top of current deb12u4. I think this would be best, despite the way it goes, - first the change is added in v7.2.9.diff, and next removed in a followup revert, - because this way we follow upstream releases, and this patch will be easy to remove in subsequent update. Alternatively we probably can ignore cryptsetup autopkgtest failure, but this smells somewhat wrong, I think it's better to restore the status quo for now, even in such a weird way (applying and reverting a patch). What do you think? Sure thing, if the solution will be found in a couple of days, I'll try to push that one instead, but it also depends on the complexity and possible risks there, and timeline. Thanks, /mjt
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
03.02.2024 12:43, Adam D. Barratt : .. I'm aware of the autopkgtest failure with cryptsetup, working on it now. It looks like we broke suspend/resume in this version of qemu. Oops. Is that related to the cryptsetup failure, or a separate issue? Yes, it is related to cryptsetup autopkgtest failure. It looks like this is the only place where suspend/resume code in qemu is actually being used, - it's rather rare to suspend (hybernate) a virtual machine, and cryptsetup performs testing of how the encrypted filesystem is unlocked (or not) on resume. I already found the upstream commit which broke this (in all supported versions of upstream qemu, including master), dunno yet what to do with it, - trying to reduce the cryptroot test to some manageable minimum. It'd be sad to avoid updating of qemu due to this. But let's see.. Thanks, /mjt
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
01.02.2024 11:40, Adam D Barratt : .. Package: qemu Version: 7.2+dfsg-7+deb12u4 Explanation: new upstream stable release; irtio-net: correctly copy vnet header when flushing TX [CVE-2023-6693]; fix null pointer dereference issue [CVE-2023-6683] There's a typo here, should be virtio-net. I'm aware of the autopkgtest failure with cryptsetup, working on it now. It looks like we broke suspend/resume in this version of qemu. Thanks, /mjt
Bug#1052648: bookworm-pu: package unbound/1.17.1-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: unbo...@packages.debian.org
Control: affects -1 + src:unbound
[ Reason ]
There's a mode of operation of the server (which is becoming
more common with time) which makes it to loop endlessly and
to become useless, and to flood system log. This happens with
libssl3 (which we have in bookworm).
This release has a single bugfix for #1038243 from upstream.
Unstable/testing has a next upstream release already, where
this fix is included.
[ Tests ]
I did a local test of the installed package and observe the
issue is now fixed.
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in (old)stable
[*] the issue is verified as fixed in unstable
diff -Nru unbound-1.17.1/debian/changelog unbound-1.17.1/debian/changelog
--- unbound-1.17.1/debian/changelog 2023-04-09 15:59:14.0 +0300
+++ unbound-1.17.1/debian/changelog 2023-09-25 18:45:40.0 +0300
@@ -1,3 +1,11 @@
+unbound (1.17.1-2+deb12u1) bookworm; urgency=medium
+
+ * fix-812-fix-846-by-using-the-SSL_OP_IGNORE_UNEXPECTE.patch from upstream
+to fix error log flooding when using DNS over TLS with openssl 3.0.
+Closes: #1038243
+
+ -- Michael Tokarev Mon, 25 Sep 2023 18:45:40 +0300
+
unbound (1.17.1-2) unstable; urgency=medium
* unbound-helper: return 0 explicitly in a few places
diff -Nru
unbound-1.17.1/debian/patches/fix-812-fix-846-by-using-the-SSL_OP_IGNORE_UNEXPECTE.patch
unbound-1.17.1/debian/patches/fix-812-fix-846-by-using-the-SSL_OP_IGNORE_UNEXPECTE.patch
---
unbound-1.17.1/debian/patches/fix-812-fix-846-by-using-the-SSL_OP_IGNORE_UNEXPECTE.patch
1970-01-01 03:00:00.0 +0300
+++
unbound-1.17.1/debian/patches/fix-812-fix-846-by-using-the-SSL_OP_IGNORE_UNEXPECTE.patch
2023-09-25 18:45:40.0 +0300
@@ -0,0 +1,68 @@
+From: George Thessalonikefs
+Date: Fri, 17 Mar 2023 14:39:37 +0100
+Subject: Fix #812, fix #846, by using the SSL_OP_IGNORE_UNEXPECTED_EOF option
+ to ignore the unexpected eof while reading in openssl >= 3.
+Origin: upstream,
https://github.com/NLnetLabs/unbound/commit/d7e776114114c16816570e48ab3a27eedc401a0e
+Forwarded: not needed
+Bug: https://github.com/NLnetLabs/unbound/issues/812
+Bug-Debian: https://bugs.debian.org/1038243
+
+---
+ doc/Changelog | 4
+ util/net_help.c | 21 +
+ 2 files changed, 25 insertions(+)
+
+#diff --git a/doc/Changelog b/doc/Changelog
+#index 62d2b4c84..25b63ce76 100644
+#--- a/doc/Changelog
+#+++ b/doc/Changelog
+#@@ -1,3 +1,7 @@
+#+17 March 2023: George
+#+ - Fix #812, fix #846, by using the SSL_OP_IGNORE_UNEXPECTED_EOF option
+#+ to ignore the unexpected eof while reading in openssl >= 3.
+#+
+# 16 March 2023: Wouter
+# - Fix ssl.h include brackets, instead of quotes.
+#
+diff --git a/util/net_help.c b/util/net_help.c
+index 54fad6986..de2d771bd 100644
+--- a/util/net_help.c
b/util/net_help.c
+@@ -1005,6 +1005,16 @@ listen_sslctx_setup(void* ctxt)
+ log_crypto_err("could not set cipher list with
SSL_CTX_set_cipher_list");
+ }
+ #endif
++#if defined(SSL_OP_IGNORE_UNEXPECTED_EOF)
++ /* ignore errors when peers do not send the mandatory close_notify
++ * alert on shutdown.
++ * Relevant for openssl >= 3 */
++ if((SSL_CTX_set_options(ctx, SSL_OP_IGNORE_UNEXPECTED_EOF) &
++ SSL_OP_IGNORE_UNEXPECTED_EOF) != SSL_OP_IGNORE_UNEXPECTED_EOF) {
++ log_crypto_err("could not set SSL_OP_IGNORE_UNEXPECTED_EOF");
++ return 0;
++ }
++#endif
+
+ if((SSL_CTX_set_options(ctx, SSL_OP_CIPHER_SERVER_PREFERENCE) &
+ SSL_OP_CIPHER_SERVER_PREFERENCE) !=
+@@ -1233,6 +1243,17 @@ void* connect_sslctx_create(char* key, char* pem, char*
verifypem, int wincert)
+ SSL_CTX_free(ctx);
+ return 0;
+ }
++#endif
++#if defined(SSL_OP_IGNORE_UNEXPECTED_EOF)
++ /* ignore errors when peers do not send the mandatory close_notify
++ * alert on shutdown.
++ * Relevant for openssl >= 3 */
++ if((SSL_CTX_set_options(ctx, SSL_OP_IGNORE_UNEXPECTED_EOF) &
++ SSL_OP_IGNORE_UNEXPECTED_EOF) != SSL_OP_IGNORE_UNEXPECTED_EOF) {
++ log_crypto_err("could not set SSL_OP_IGNORE_UNEXPECTED_EOF");
++ SSL_CTX_free(ctx);
++ return 0;
++ }
+ #endif
+ if(key && key[0]) {
+ if(!SSL_CTX_use_certificate_chain_file(ctx, pem)) {
+--
+2.39.2
+
diff -Nru unbound-1.17.1/debian/patches/series
unbound-1.17.1/debian/patches/series
--- unbound-1.17.1/debian/patches/series2022-08-12 13:04:20.0
+0300
+++ unbound-1.17.1/debian/patches/series2023-09-17 09:17:32.0
+0300
@@ -1,3 +1,4 @@
unbound-control-se
Bug#1049955: bookworm-pu: package qemu/1:7.2+dfsg-7+deb12u2
23.09.2023 23:45, Adam D. Barratt wrote: Control: tags -1 confirmed On Thu, 2023-08-17 at 12:54 +0300, Michael Tokarev wrote: There's a next upstream qemu stable/bugfix release, fixing a big number of various issues, including 3 (minor) security issues too. The full list is in the changelog below and in the upstream git (mirrored in salsa too). ... Please go ahead. It is a "good" timing, Adam. Just 2 days ago I sent announcement for a new qemu stable-7.2.6 release fixing a bunch of more bugs, and fixing an important class of security issues too. https://lore.kernel.org/qemu-devel/bf422038-5f0a-e9ca-1eb3-ed25442c7...@tls.msk.ru/ "Good" because I forgot to send a note to this bug report about the upcoming release (it was planned) and as a result we clashed. I prepared debian package (based on this new 7.2.6), it is in testing now on my local machine. Will it be easier to upload the reviewed 7.2+dfsg-7+deb12u2 (based on 7.2.5) and close this bug#, and later make 7.2+dfsg-7+deb12u3 (based on 7.2.6), or update current bug# with new release? I guess it's better to do it step by step, closing this bug# and filing a new one. Thank you! /mjt
Bug#1051594: bookworm-pu: package samba/2:4.17.11+dfsg-0+deb12u1
10.09.2023 13:11, Michael Tokarev: Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: sa...@packages.debian.org, pkg-samba-ma...@lists.alioth.debian.org Control: affects -1 + src:samba [ Reason ] There's a next upstream stable/bugfix release of samba series 4.17, with a next share of bugfixes. This is the last regular stable release, 4.17 switched to security-only bugfix mode once 4.19 is out. Every change in there is worth having in debian stable, as it fixes some bug. Generally I think it is better to follow upstream stable in case of samba as they tend to pick only important fixes for their stable series. [ Tests ] Usual upstream testsuite is obviously passed. Additionally, I run this debian release on a few our boxes, both AD-DC mode and stand- alone server mode, for quite some time. [ Risks ] There's always a risk to break something. As usual for samba stable releases though, this risk is minimal. [ Checklist ] [*] *all* changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in (old)stable [*] the issue is verified as fixed in unstable (unstable has next upstream major release from which all commits were picked up) [ Changes ] Here's the changelog entry in qeustion. For the upstream release, it links each change to a bug report at the upstream bug tracker. Additionally, there are 2 minor debian-specific changes - it is the switch to bookworm branch in the git packaging (Vcs-Git link, specific to bookworm, not in sid), and a slight rewording of description of samba-common-bin package (comes from sid). samba (2:4.17.11+dfsg-0+deb12u1) bookworm; urgency=medium * new upstream stable/bugfix release 4.17.11, including: o https://bugzilla.samba.org/show_bug.cgi?id=9959 Windows client join fails if a second container CN=System exists somewhere o https://bugzilla.samba.org/show_bug.cgi?id=15342 Spotlight sometimes returns no results on latest macOS o https://bugzilla.samba.org/show_bug.cgi?id=15346 2-3min delays at reconnect with smb2_validate_sequence_number: bad message_id 2 o https://bugzilla.samba.org/show_bug.cgi?id=15384 net ads lookup (with unspecified realm) fails o https://bugzilla.samba.org/show_bug.cgi?id=15401 Improve GetNChanges to address some (but not all "Azure AD Connect") syncronisation tool looping during the initial user sync phase o https://bugzilla.samba.org/show_bug.cgi?id=15407 Samba replication logs show (null) DN o https://bugzilla.samba.org/show_bug.cgi?id=15417 Renaming results in NT_STATUS_SHARING_VIOLATION if previously attempted to remove the destination o https://bugzilla.samba.org/show_bug.cgi?id=15419 Weird filename can cause assert to fail in openat_pathref_fsp_nosymlink() o https://bugzilla.samba.org/show_bug.cgi?id=15420 reply_sesssetup_and_X() can dereference uninitialized tmp pointer o https://bugzilla.samba.org/show_bug.cgi?id=15427 Spotlight results return wrong date in result list o https://bugzilla.samba.org/show_bug.cgi?id=15430 Missing return in reply_exit_done() o https://bugzilla.samba.org/show_bug.cgi?id=15432 TREE_CONNECT without SETUP causes smbd to use uninitialized pointer o https://bugzilla.samba.org/show_bug.cgi?id=15435 Regression DFS not working with widelinks = true o https://bugzilla.samba.org/show_bug.cgi?id=15441 samba-tool ntacl get segfault if aio_pthread appended o https://bugzilla.samba.org/show_bug.cgi?id=15446 DCERPC_PKT_CO_CANCEL and DCERPC_PKT_ORPHANED can't be parsed o https://bugzilla.samba.org/show_bug.cgi?id=15449 mdssvc: Do an early talloc_free() in _mdssvc_open() o https://bugzilla.samba.org/show_bug.cgi?id=15451 ctdb_killtcp fails to work with --enable-pcap and libpcap ≥ 1.9.1 o https://bugzilla.samba.org/show_bug.cgi?id=15453 File doesn't show when user doesn't have permission if aio_pthread is loaded o https://bugzilla.samba.org/show_bug.cgi?id=15463 macOS mdfind returns only 50 results * d/control: indicate the git branch in Vcs-Git URL (-b bookworm) * d/control: fix description of samba-common-bin (samba-client) -- Michael Tokarev Sun, 10 Sep 2023 12:48:29 +0300 There's one more small change which I'd love to have here too on top of the above, in addition to Vcs-Git bookworm fix, it's this commit: commit 24c89104279a12c17582b9b508cb4a9973032c13 (HEAD -> bookworm) Author: Michael Tokarev Date: Sun Sep 10 14:53:00 2023 +0300 d/salsa-ci.yml: set RELEASE to bookworm diff --git a/debian/changelog b/debian/changelog index 39291672047..14b7852bf8b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -45,6 +45,7 @@ samba (2:4.17.11+dfsg-0+deb12u1) bookworm; urgency=medium macOS mdfind re
Bug#1049955: bookworm-pu: package qemu/1:7.2+dfsg-7+deb12u2
: Fix pending HDEC when entering PM state - target/ppc: Fix VRMA page size for ISA v3.0 - target/i386: Check CR0.TS before enter_mmx - Update version for 7.2.5 release Closes: CVE-2023-3255, CVE-2023-3354, CVE-2023-3180 [ Other info ] - debdiff follows diff -Nru qemu-7.2+dfsg/debian/changelog qemu-7.2+dfsg/debian/changelog --- qemu-7.2+dfsg/debian/changelog 2023-07-11 23:07:58.0 +0300 +++ qemu-7.2+dfsg/debian/changelog 2023-08-17 12:33:57.0 +0300 @@ -1,3 +1,59 @@ +qemu (1:7.2+dfsg-7+deb12u2) bookworm; urgency=medium + + * d/rules: add the forgotten --enable-virtfs for the xen build. +This makes 9pfs virtual filesystem available for xen hvm domUs. +This adds no new runtime dependencies. Closes: #1049925. + * update to upstream 7.2.5 stable/bugfix release, v7.2.5.diff, +https://gitlab.com/qemu-project/qemu/-/commits/v7.2.5 : + - hw/ide/piix: properly initialize the BMIBA register + - ui/vnc-clipboard: fix infinite loop in inflate_buffer (CVE-2023-3255) + - qemu-nbd: pass structure into nbd_client_thread instead of plain char* + - qemu-nbd: fix regression with qemu-nbd --fork run over ssh + - qemu-nbd: regression with arguments passing into nbd_client_thread() + - target/s390x: Make CKSM raise an exception if R2 is odd + - target/s390x: Fix CLM with M3=0 + - target/s390x: Fix CONVERT TO LOGICAL/FIXED with out-of-range inputs + - target/s390x: Fix ICM with M3=0 + - target/s390x: Make MC raise specification exception when class >= 16 + - target/s390x: Fix assertion failure in VFMIN/VFMAX with type 13 + - target/loongarch: Fix the CSRRD CPUID instruction on big endian hosts + - virtio-pci: add handling of PCI ATS and Device-TLB enable/disable + - vhost: register and change IOMMU flag depending on Device-TLB state + - virtio-net: pass Device-TLB enable/disable events to vhost + - hw/arm/smmu: Handle big-endian hosts correctly + - target/arm: Avoid writing to constant TCGv in trans_CSEL() + - target/ppc: Disable goto_tb with architectural singlestep + - linux-user/armeb: Fix __kernel_cmpxchg() for armeb + - qga/win32: Use rundll for VSS installation + - thread-pool: signal "request_cond" while locked + - xen-block: Avoid leaks on new error path + - io: remove io watch if TLS channel is closed during handshake + - target/nios2: Pass semihosting arg to exit + - target/nios2: Fix semihost lseek offset computation + - target/m68k: Fix semihost lseek offset computation + - hw/virtio-iommu: Fix potential OOB access in virtio_iommu_handle_command() + - virtio-crypto: verify src buffer length for sym request + - target/hppa: Move iaoq registers and thus reduce generated code size + - pci: do not respond config requests after PCI device eject + - hw/i386/intel_iommu: Fix trivial endianness problems + - hw/i386/intel_iommu: Fix endianness problems related to VTD_IR_TableEntry + - hw/i386/intel_iommu: Fix struct VTDInvDescIEC on big endian hosts + - hw/i386/intel_iommu: Fix index calculation in vtd_interrupt_remap_msi() + - hw/i386/x86-iommu: Fix endianness issue in x86_iommu_irq_to_msi_message() + - include/hw/i386/x86-iommu: Fix struct X86IOMMU_MSIMessage for big endian hosts + - vfio/pci: Disable INTx in vfio_realize error path + - vdpa: Fix possible use-after-free for VirtQueueElement + - vdpa: Return -EIO if device ack is VIRTIO_NET_ERR in _load_mac() + - vdpa: Return -EIO if device ack is VIRTIO_NET_ERR in _load_mq() + - target/ppc: Implement ASDR register for ISA v3.0 for HPT + - target/ppc: Fix pending HDEC when entering PM state + - target/ppc: Fix VRMA page size for ISA v3.0 + - target/i386: Check CR0.TS before enter_mmx + - Update version for 7.2.5 release +Closes: CVE-2023-3255, CVE-2023-3354, CVE-2023-3180 + + -- Michael Tokarev Thu, 17 Aug 2023 12:33:57 +0300 + qemu (1:7.2+dfsg-7+deb12u1) bookworm; urgency=medium * d/rules: add the forgotten --enable-libusb for the xen build. diff -Nru qemu-7.2+dfsg/debian/patches/series qemu-7.2+dfsg/debian/patches/series --- qemu-7.2+dfsg/debian/patches/series 2023-07-11 15:43:48.0 +0300 +++ qemu-7.2+dfsg/debian/patches/series 2023-08-17 11:24:13.0 +0300 @@ -2,6 +2,7 @@ v7.2.2.diff v7.2.3.diff v7.2.4.diff +v7.2.5.diff microvm-default-machine-type.patch skip-meson-pc-bios.diff linux-user-binfmt-P.diff diff -Nru qemu-7.2+dfsg/debian/patches/v7.2.5.diff qemu-7.2+dfsg/debian/patches/v7.2.5.diff --- qemu-7.2+dfsg/debian/patches/v7.2.5.diff1970-01-01 03:00:00.0 +0300 +++ qemu-7.2+dfsg/debian/patches/v7.2.5.diff2023-08-17 11:24:01.0 +0300 @@ -0,0 +1,1575 @@ +diff --git a/VERSION b/VERSION +index 2bbaead448..8aea167e72 100644 +--- a/VERSION b/VERSION +@@ -1 +1 @@ +-7.2.4 ++7.2.5 +diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c +index e09b9c13b7..bbca3a8db3 100644 +--- a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c +@@ -193,8 +193,7 @@ sta
Re: Bug#1039604: glusterfs: Drop support for 32-bit architectures
20.07.2023 11:40, Patrick Matthäi wrote: .. I have uploaded glusterfs 11.0-1 to experimental, it is limited to these architectures: amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64 Build-Depends: architecture-is-64-bits fwiw, anyway. Ok. So if nobody rises up I would start to fill bugs for the reverse dependencies in the next days and after that uploading glusterfs 11.x to unstable. It's an unfortunate timing: I uploaded new qemu a few minutes before this your reply. Sure thing it went in without the gluster-related changes. I now fixed the [architecture] list in there in qemu - next upload will have no deps on gluster on 32bits. Doing the same for samba as well now, - next samba will have no deps on glusterfs on 32bits too. What happens with stable, there I do not have an answer, yet. What's about stable? the version of gluster in stable should not be affected. IMO the best way would be continue to use dh_install, there you can also limit the architectures: [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64] debian/tmp/usr/lib/foo/gluster.so That's dh-exec, but yes. Somehow I dislike dh_exec personally :) /mjt
Re: Bug#1039604: glusterfs: Drop support for 32-bit architectures
14.07.2023 20:02, Patrick Matthäi wrote: *ping* (also adding some other maintainers of reverse depends) I don't remember seeing this before. Yes, I use libglusterfs-dev in Build-Depends of samba and qemu. I think it is already reduced to 64bits on ubuntu for samba (or, rather, i386 is excluded). The question is: how to specify dependencies properly and more important, how to specify lists of files to install? Right now I have: d/control: Build-Depends: libglusterfs-dev d/foo.install: /usr/lib/foo/gluster.so I can change the first one to be something like Build-Depends: libglusterfs-dev [amd64 arm64] (with a few questions remaining: what is the complete list? How about non-linux?). But what to do with the second, - move the handling to d/rules, like if [ -f debian/tmp/usr/lib/foo/gluster.so ]; then install -D debian/tmp/usr/lib/foo/gluster.so -t debian/foo/usr/lib/foo/ fi ? Thanks, /mjt
Bug#1041037: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u3
This is https://bugs.debian.org/1041043 - #1041043, I forgot to file debian bug report about this issue. It's closed now by the sid upload of samba. /mjt
Bug#1041037: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u3
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: sa...@packages.debian.org, pkg-samba-de...@lists.alioth.debian.org
Control: affects -1 + src:samba
[ Reason ]
Microsoft released Jul-2023 updates for current windows versions,
with some changes in the auth/trust process. This revealed a bug
in samba, which result in a serious loss of service not only within
samba itself but also within whole windows domain network, resulting
in users not being able to log in to their windows computers anymore.
This is tracked in the samba bug tracker, see
https://bugzilla.samba.org/show_bug.cgi?id=15418
and on the samba mailing list. A lot of users are affected worldwide.
The problem is that with this update, windows started trying to negotiate
a new security level (l2) which isn't documented. Per the specs, an
implementation should reject unknown security levels with "unsupported"
error, so the client trying a new level knows it not supported. But
samba does not reject it immediately and tries to process, just to reject
it later with a different error. As a result, windows treats this as
actual trust error instead of an unsupported optional feature.
[ Impact ]
Many users are affected worldwide after the current windows update has
been installed, being unable to log in to their windows computers.
[ Tests ]
The fix has been verified by multiple independent users. I can confirm
the updated package fixes the issue on our site too.
[ Risks ]
The change is rather simple, - it is just moving the check for unsupported
level to be one of the first checks and return correct code immediately
instead of trying to process an unknown-format request.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
(See debdiff below)
[ Other info ]
The same fix is already uploaded to sid (for the version of samba in sid)
and is released by other major distributions. The fix is on top of a previous
bookworm-pu update which has been discussed and accepted previously.
I'm uploading the updated package while sending this email,
hopefully it is okay.
Thanks,
/mjt
diff -Nru samba-4.17.9+dfsg/debian/changelog samba-4.17.9+dfsg/debian/changelog
--- samba-4.17.9+dfsg/debian/changelog 2023-07-09 09:44:29.0 +0300
+++ samba-4.17.9+dfsg/debian/changelog 2023-07-14 12:34:30.0 +0300
@@ -1,3 +1,11 @@
+samba (2:4.17.9+dfsg-0+deb12u3) bookworm; urgency=medium
+
+ * +fix-unsupported-netr_LogonGetCapabilities-l2.patch
+Fix windows logon/trust issues with 2023-07 windows updates:
+https://bugzilla.samba.org/show_bug.cgi?id=15418
+
+ -- Michael Tokarev Fri, 14 Jul 2023 12:34:30 +0300
+
samba (2:4.17.9+dfsg-0+deb12u2) bookworm; urgency=medium
* link with -latomic explicitly on a few architectures where gcc misses it
diff -Nru
samba-4.17.9+dfsg/debian/patches/fix-unsupported-netr_LogonGetCapabilities-l2.patch
samba-4.17.9+dfsg/debian/patches/fix-unsupported-netr_LogonGetCapabilities-l2.patch
---
samba-4.17.9+dfsg/debian/patches/fix-unsupported-netr_LogonGetCapabilities-l2.patch
1970-01-01 03:00:00.0 +0300
+++
samba-4.17.9+dfsg/debian/patches/fix-unsupported-netr_LogonGetCapabilities-l2.patch
2023-07-14 12:33:32.0 +0300
@@ -0,0 +1,68 @@
+From af355243e55a4baf17126339eb66432d438c4f16 Mon Sep 17 00:00:00 2001
+From: Stefan Metzmacher
+Date: Fri, 14 Jul 2023 10:20:05 +0200
+Subject: [PATCH] s3+s3/rpc_server: fix unsupported netr_LogonGetCapabilities
+ level 2
+Origin: upstream, https://bugzilla.samba.org/attachment.cgi?id=17983
+
+BUG: https://bugzilla.samba.org/show_bug.cgi?id=15418
+---
+ source3/rpc_server/netlogon/srv_netlog_nt.c | 9 +
+ source4/rpc_server/netlogon/dcerpc_netlogon.c | 8
+ 2 files changed, 9 insertions(+), 8 deletions(-)
+
+diff --git a/source3/rpc_server/netlogon/srv_netlog_nt.c
b/source3/rpc_server/netlogon/srv_netlog_nt.c
+index 3ba58e61206f..2018dc28eb67 100644
+--- a/source3/rpc_server/netlogon/srv_netlog_nt.c
b/source3/rpc_server/netlogon/srv_netlog_nt.c
+@@ -2284,6 +2284,11 @@ NTSTATUS _netr_LogonGetCapabilities(struct pipes_struct
*p,
+ struct netlogon_creds_CredentialState *creds;
+ NTSTATUS status;
+
++ if (r->in.query_level != 1) {
++ p->fault_state = DCERPC_NCA_S_FAULT_INVALID_TAG;
++ return NT_STATUS_NOT_SUPPORTED;
++ }
++
+ become_root();
+ status = dcesrv_netr_creds_server_step_check(p->dce_call,
+ p->mem_ctx,
+@@ -2296,10 +2301,6 @@ NTSTATUS _netr_LogonGetCapabilities(struct pipes_struct
*p,
+ return status;
+ }
+
+- if (r->in.query_level != 1) {
+- return NT_STATUS_NOT_SUPPORTED;
+- }
+-
+
Bug#1040519: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u1
09.07.2023 10:05, Michael Tokarev wrote:
...
Now after thought about all this in the morning, I think the following should
do it:
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+samba (2:4.17.9+dfsg-0+deb12u2) bookworm; urgency=medium
+
+ * link with -latomic explicitly on a few architectures where gcc misses it
+ (notable armel & mipsel), to fix FTBFS there, - the same as on sid.
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
+
+ -- Michael Tokarev Sun, 09 Jul 2023 09:44:29 +0300
+
samba (2:4.17.9+dfsg-0+deb12u1) bookworm-proposed-updates; urgency=medium
* d/copyright: filter out autogenerated manpages from the upstream source
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -103,6 +103,20 @@ with-ceph =
with-glusterfs =
endif
+ifneq (,$(filter armel mipsel m68k powerpc sh4,${DEB_HOST_ARCH}))
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
+# on these platforms gcc does not link with -latomic, resulting in
+# third_party/heimdal/lib/krb5/krcache.c.55.o: in function
`krcc_get_principal':
+# third_party/heimdal/lib/krb5/krcache.c:1395: undefined reference to
`__atomic_load_8'
+# ids.krcu_cache_and_princ_id =
heim_base_atomic_load(>krc_cache_and_principal_id);
+# third_party/heimdal/lib/base/heimbase-atomics.h:
+# #include
+# #define heim_base_atomic_load(x) atomic_load((x))
+# include a workaround for now
+# (-latomic and comes from gcc, --as-needed is already in use)
+LDFLAGS := ${LDFLAGS} -latomic
+endif
+
config-args += $(if ${with-ceph},\
--enable-cephfs --enable-ceph-reclock,\
--disable-cephfs)
(this is the same changes as on sid, *plus* a bit more, which updates the
comment
with the gcc bug reference and drops -Wl,--no-as-needed, - since this one is
already
enabled).
So I built this on armel and mipsel (and on amd64 too) and verified it works
fine.
Uploading the fixed package (with the above diff from -0+deb12u1) now, feel
free to
accept it as the fix for the previous broken upload.
Thank you for your time!
/mjt
Bug#1040519: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u1
09.07.2023 01:45, Adrian Bunk wrote:
On Sun, Jul 09, 2023 at 01:13:55AM +0300, Michael Tokarev wrote:
09.07.2023 01:01, Adrian Bunk wrote:
This does apparently need the -latomic workaround from 2:4.18.3+dfsg-3:
https://buildd.debian.org/status/package.php?p=samba=bookworm
Sigh!
This is the kerberos in-kernel tickets.. :(
I haven't realized until now that atomic8 thing come into the game after
I enabled the in-kernel kerberos tickets. I was sure it was due to some
toolchain changes.
FTR, the underlying toolchain bug is not new:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
Now I know why we weren't able to reproduce this issue
with upstream, - because it happens in the code which is enabled by this
change.
...
The error message is a bit cryptic, but it basically says in which lines
in krcache.c the 64bit loads/stores are for which the CPU has no
instructions and needs libatomic.
Not linking with libatomic automatically for C11 atomics is the gcc bug.
Yeah, I know this is a gcc issue (though I haven't found the gcc bugreport
about this, - thank you for the link! - updated comments now). I just didn't
connect the dots when it happened, - I didn't think my kerberos changes in
samba were the trigger for this issue to pop up, I thought it was somehting
else outside of samba (as you can see, the comments in d/rules in sid samba
package refers to this same place in source), - instead of realizing it is
due to me enabling new code which weren't used in samba before.
Now after thought about all this in the morning, I think the following should
do it:
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+samba (2:4.17.9+dfsg-0+deb12u2) bookworm; urgency=medium
+
+ * link with -latomic explicitly on a few architectures where gcc misses it
+(notable armel & mipsel), to fix FTBFS there, - the same as on sid.
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
+
+ -- Michael Tokarev Sun, 09 Jul 2023 09:44:29 +0300
+
samba (2:4.17.9+dfsg-0+deb12u1) bookworm-proposed-updates; urgency=medium
* d/copyright: filter out autogenerated manpages from the upstream source
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -103,6 +103,20 @@ with-ceph =
with-glusterfs =
endif
+ifneq (,$(filter armel mipsel m68k powerpc sh4,${DEB_HOST_ARCH}))
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
+# on these platforms gcc does not link with -latomic, resulting in
+# third_party/heimdal/lib/krb5/krcache.c.55.o: in function
`krcc_get_principal':
+# third_party/heimdal/lib/krb5/krcache.c:1395: undefined reference to
`__atomic_load_8'
+# ids.krcu_cache_and_princ_id =
heim_base_atomic_load(>krc_cache_and_principal_id);
+# third_party/heimdal/lib/base/heimbase-atomics.h:
+# #include
+# #define heim_base_atomic_load(x)atomic_load((x))
+# include a workaround for now
+# (-latomic and comes from gcc, --as-needed is already in use)
+LDFLAGS := ${LDFLAGS} -latomic
+endif
+
config-args += $(if ${with-ceph},\
--enable-cephfs --enable-ceph-reclock,\
--disable-cephfs)
(this is the same changes as on sid, *plus* a bit more, which updates the
comment
with the gcc bug reference and drops -Wl,--no-as-needed, - since this one is
already
enabled).
I'm building it on a mipsel qemu chroot right now to verify, and think it's a
better fix than to revert kerberos keyring changes for deb12u2.
BTW, I'm not sure why dch used "bookworm" in the Distribution field in
d/changelog
when I run `dch -r' - the previous distribution was bookworm-p-u. Now I'm a bit
confused which value should be used there.
Thank you Adrian for all the help!
/mjt
Bug#1040519: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u1
09.07.2023 01:01, Adrian Bunk wrote: This does apparently need the -latomic workaround from 2:4.18.3+dfsg-3: https://buildd.debian.org/status/package.php?p=samba=bookworm Sigh! This is the kerberos in-kernel tickets.. :( I haven't realized until now that atomic8 thing come into the game after I enabled the in-kernel kerberos tickets. I was sure it was due to some toolchain changes. Now I know why we weren't able to reproduce this issue with upstream, - because it happens in the code which is enabled by this change. I'll see what can be done tomorrow. Apparently it might be better to revert this keyring change for bookworm and fix it for good in trixie first. Either way, it's for tomorrow. The very good thing is that now I know the context which I thought is entirely different. Thank you! /mjt
Bug#1040519: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u1
07.07.2023 10:58, Jonathan Wiltshire wrote: Control: tag -1 confirmed On Fri, Jul 07, 2023 at 10:03:07AM +0300, Michael Tokarev wrote: [ Reason ] Here's the next stable/bugfix release of samba, 4.17.9. As has been the case with samba stable/bugfix releases, this one is of an excellent quality, well tested and with all changes well selected as well. Please go ahead with the full proposal (upstream and your package fixes). Uploaded just now instead of yesterday, - I wanted to verify once more it is in a good shape after the above two additional modifications. Thank you! /mjt
Bug#1040519: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u1
difference between different upstream releases huge, and I have to filter the manpages to get it back into a manageable size. So I'd love to add 3 patterns to d/copyright filtering out docs/manpages/*.[1-8], ctdb/doc/*.[1-8] and ctdb/doc/*.[1-8].html and regenerate +dfsg.orig.tar.gz. This will make the diff even larger once, but will a) ensure everything is rebuilt during the build process (and we don't re-use stuff built by someone else), make subsequent diffs small, but it does not affect the resulting binaries in any way. This change is already included in samba package in sid, and I verified it works the same way with 4.17 samba too. And second, I had numerous requests to let samba work with kernel-based keystore in context of kerberos. Initially it was thought this requires switching from heimdal to mit-krb5 kerberos implementation (which isn't supported upstream for running in ad-dc mode), but it turned out (again, too late in the bookworm release cycle) heimdal also supports this for a long time, the prob is that the samba configure procedure for heimdal (heimdal is built from samba-shipped sources) just does not enable it by mistake. In order to enable this, a trivial patch for the build system and libkeyutils-dev build- dependency are needed, 2 commits from 4.18 branch (sid/trixie): https://salsa.debian.org/samba-team/samba/-/commit/1d25241e573ed2e2fe38ed168168e994d3104c69 https://salsa.debian.org/samba-team/samba/-/commit/8235a95ec450427acf0cd7ddfb3b91b6ebe15302 The talk is about #1023609 here, and I continue receiving requests to enable it for bookworm too. So, if such changes are possible during stable release cycle, please let me know and I'll include them too on top of the current bunch. Thank you! /mjt diff -Nru --exclude '*.[1-8]' --exclude '*.[1-8].html' samba-4.17.8+dfsg/debian/changelog samba-4.17.9+dfsg/debian/changelog --- samba-4.17.8+dfsg/debian/changelog 2023-05-24 22:54:43.0 +0300 +++ samba-4.17.9+dfsg/debian/changelog 2023-07-06 23:00:33.0 +0300 @@ -1,3 +1,32 @@ +samba (2:4.17.9+dfsg-0+deb12u1) bookworm-proposed-updates; urgency=medium + + * new upstream stable/bugfix release, with the following fixes: + * https://bugzilla.samba.org/show_bug.cgi?id=14030 + named crashes on DLZ zone update + (this was in debian in previous upload) + * https://bugzilla.samba.org/show_bug.cgi?id=15275 + smbd_scavenger crashes when service smbd is stopped + * https://bugzilla.samba.org/show_bug.cgi?id=15361 + winbind recurses into itself via rpcd_lsad + * https://bugzilla.samba.org/show_bug.cgi?id=15374 + aes256 smb3 encryption algorithms are not allowed in smb3_sid_parse() + * https://bugzilla.samba.org/show_bug.cgi?id=15378 + vfs_fruit might cause a failing open for delete + * https://bugzilla.samba.org/show_bug.cgi?id=15382 + cli_list loops 100% CPU against pre-lanman2 servers + * https://bugzilla.samba.org/show_bug.cgi?id=15391 + smbclient leaks fds with showacls + * https://bugzilla.samba.org/show_bug.cgi?id=15403 + smbget memory leak if failed to download files recursively + * https://bugzilla.samba.org/show_bug.cgi?id=15404 + Backport --pidl-developer fixes + * https://bugzilla.samba.org/show_bug.cgi?id=15413 + winbindd gets stuck on NT_STATUS_RPC_SEC_PKG_ERROR + * remove dnsserver-rename-dns_name_equal.patch +(included upstream) + + -- Michael Tokarev Thu, 06 Jul 2023 23:00:33 +0300 + samba (2:4.17.8+dfsg-2) unstable; urgency=medium * dnsserver-rename-dns_name_equal.patch diff -Nru --exclude '*.[1-8]' --exclude '*.[1-8].html' samba-4.17.8+dfsg/debian/patches/dnsserver-rename-dns_name_equal.patch samba-4.17.9+dfsg/debian/patches/dnsserver-rename-dns_name_equal.patch --- samba-4.17.8+dfsg/debian/patches/dnsserver-rename-dns_name_equal.patch 2023-05-24 22:54:43.0 +0300 +++ samba-4.17.9+dfsg/debian/patches/dnsserver-rename-dns_name_equal.patch 1970-01-01 03:00:00.0 +0300 @@ -1,255 +0,0 @@ -Commit-Id: fcecdfa8e5c651d4a27f8fcd5df6e9bce37ed8a7 -From: Samuel Cabrero -Date: Wed, 18 Jan 2023 17:25:29 +0100 -Subject: s4:dnsserver: Rename dns_name_equal() to samba_dns_name_equal() -Bug-Debian: https://bugs.debian.org/1036587 -Bug-Debian: https://bugs.debian.org/927747 -Bug: https://bugzilla.samba.org/show_bug.cgi?id=14030 - -This function already exists in bind9 but takes different arguments, so when -the DLZ is loaded and this function is called bind crashes: - - named[1523]: samba_dlz: allowing update of signer=DESKTOP-8BUKMBK\$\@AFOREST.AD name=118.101.168.192.in-addr.arpa tcpaddr=192.168.101.118 type=PTR key=1264-ms-7.1-2ac9.9ef238e1-9747-11ed-9f95-525400dc6981/159/0 - named[1523]: samba_dlz: allowing update of signer=DESKTOP-8BUKMBK\$\@AFOREST.AD name=118.101.168.192.in-addr.arpa tcpaddr=192.168.101.118 type=PTR key=1264-ms-7.1-2ac9.9ef238e1-9747-11ed-9f95-525400dc6981/159/0 - named[1523]: client @0x7f26caa90f68 192.168.101.118#58223/key DESKT
Bug#1036741: unblock: samba/2:4.17.8+dfsg-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sa...@packages.debian.org, pkg-samba-ma...@lists.alioth.debian.org
Control: affects -1 + src:samba
Please unblock package samba
[ Reason ]
This is an easy one. There's a single patch from upstream applied
to -2 debian release of samba package. Its only purpose is to
rename a single internal-to-samba function which also exists in
named. The prob is that when samba DLZ pluging is loaded into
named, named crashes with high probability. There are 2 bug
reports open about this, with high severity: #1036587, #927747.
It's been too long, upstream identified this issue quite some
time too, but the fix were fogotten. Now we have a chance to
have working DNS with samba and the only real supported nameserver.
[ Impact ]
If the unblock isn't granted, we'll have non-working DNS with
named as we had before. It is probably not a huge deal since it
was broken for a very long time, but it is definitely worth to
fix. Either way this fix will be in next upstream stable/bugfix
release, and I'll push it to stable-proposed-updates, - so it
is not exactly necessary to unblock this release.
[ Tests ]
This release passes usual samba testsuite (run locally).
[ Risks ]
I don't expect any breakage here since the whole thing is a
global search-n-replace of one internally used symbol to
another, and I verified there's no other usages of this
symbol left.
[ 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 samba/2:4.17.8+dfsg-2
diff -Nru samba-4.17.8+dfsg/debian/changelog samba-4.17.8+dfsg/debian/changelog
--- samba-4.17.8+dfsg/debian/changelog 2023-05-11 10:52:40.0 +0300
+++ samba-4.17.8+dfsg/debian/changelog 2023-05-24 22:54:43.0 +0300
@@ -1,3 +1,16 @@
+samba (2:4.17.8+dfsg-2) unstable; urgency=medium
+
+ * dnsserver-rename-dns_name_equal.patch
+(forgotten) patch from upstream targetting next stable
+Fixes crashes of named with samba DLZ plugin due to
+symbol name conflict (dns_name_equal() function).
+There's no resulting code changes, just a symbol
+rename.
+https://bugzilla.samba.org/show_bug.cgi?id=14030
+Closes: #1036587, #927747
+
+ -- Michael Tokarev Wed, 24 May 2023 22:54:43 +0300
+
samba (2:4.17.8+dfsg-1) unstable; urgency=medium
* upstream stable/security/bugfix release, fixing the following issues:
diff -Nru
samba-4.17.8+dfsg/debian/patches/dnsserver-rename-dns_name_equal.patch
samba-4.17.8+dfsg/debian/patches/dnsserver-rename-dns_name_equal.patch
--- samba-4.17.8+dfsg/debian/patches/dnsserver-rename-dns_name_equal.patch
1970-01-01 03:00:00.0 +0300
+++ samba-4.17.8+dfsg/debian/patches/dnsserver-rename-dns_name_equal.patch
2023-05-24 22:54:43.0 +0300
@@ -0,0 +1,255 @@
+Commit-Id: fcecdfa8e5c651d4a27f8fcd5df6e9bce37ed8a7
+From: Samuel Cabrero
+Date: Wed, 18 Jan 2023 17:25:29 +0100
+Subject: s4:dnsserver: Rename dns_name_equal() to samba_dns_name_equal()
+Bug-Debian: https://bugs.debian.org/1036587
+Bug-Debian: https://bugs.debian.org/927747
+Bug: https://bugzilla.samba.org/show_bug.cgi?id=14030
+
+This function already exists in bind9 but takes different arguments, so when
+the DLZ is loaded and this function is called bind crashes:
+
+ named[1523]: samba_dlz: allowing update of
signer=DESKTOP-8BUKMBK\$\@AFOREST.AD name=118.101.168.192.in-addr.arpa
tcpaddr=192.168.101.118 type=PTR
key=1264-ms-7.1-2ac9.9ef238e1-9747-11ed-9f95-525400dc6981/159/0
+ named[1523]: samba_dlz: allowing update of
signer=DESKTOP-8BUKMBK\$\@AFOREST.AD name=118.101.168.192.in-addr.arpa
tcpaddr=192.168.101.118 type=PTR
key=1264-ms-7.1-2ac9.9ef238e1-9747-11ed-9f95-525400dc6981/159/0
+ named[1523]: client @0x7f26caa90f68 192.168.101.118#58223/key
DESKTOP-8BUKMBK\$\@AFOREST.AD: updating zone '101.168.192.in-addr.arpa/NONE':
deleting rrset at '118.101.168.192.in-addr.ar
+ named[1523]: name.c:664: REQUIRE(((name1) != ((void *)0) && ((const
isc__magic_t *)(name1))->magic == ((('D') << 24 | ('N') << 16 | ('S') << 8 |
('n') failed, back trace
+
+Backtrace:
+
+ #0 0x7f2716c957ec in __pthread_kill_implementation () from
/lib64/libc.so.6
+ #1 0x7f2716c42816 in raise () from /lib64/libc.so.6
+ #2 0x7f2716c2b81c in abort () from /lib64/libc.so.6
+ #3 0x55d4de847995 in assertion_failed (file=,
line=,
+ type=, cond=) at
/usr/src/debug/bind-9.18.10/bin/named/main.c:237
+ #4 0x7f27176388fc in isc_assertion_failed
(file=file@entry=0x7f27173b0df6 "name.c",
+ line=line@entry=664, type=type@entry=isc_assertiontype_require,
+ cond=cond@entry=0x7f27173b0268 "((name1) != ((void *)0) && ((const
isc__magic_t *)(name1))->magic == ((('D') << 24 | ('N') << 16 | ('S') << 8 |
('n'")
+ at
Bug#1036040: unblock: qemu/1:7.2+dfsg-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: q...@packages.debian.org, pkg-qemu-de...@lists.alioth.debian.org
Control: affects -1 + src:qemu
Please unblock package qemu
This is an easy one.
[ Reason ]
This release contains a fix for a trivial packaging bug, --
a forgotten Depends during package split. See the changelog
entry for more details.
[ Risks ]
There's no risks. The fix just works (tm).
[ 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
(even in such a trivial case, I managed to forget to format the Closes:
line properly, This does not affect the package thogh)
unblock qemu/1:7.2+dfsg-7
diff -Nru qemu-7.2+dfsg/debian/changelog qemu-7.2+dfsg/debian/changelog
--- qemu-7.2+dfsg/debian/changelog 2023-04-29 13:02:55.0 +0300
+++ qemu-7.2+dfsg/debian/changelog 2023-05-14 11:29:12.0 +0300
@@ -1,3 +1,24 @@
+qemu (1:7.2+dfsg-7) unstable; urgency=medium
+
+ * d/control: qemu-system-xen: add ipxe-qemu dependency (#1035676)
+
+When installing qemu-system-xen on a new system, the boot roms are
+not installed. Unfortunately this means HVM Xen DomUs can not be used
+at all, because the boot roms are hard requiriment for qemu since 2014,
+it fails to start without the boot roms even if (network) booting is
+not requested.
+
+Before bookworm, when qemu-system-xen was part of regular
+qemu-system-x86 package, the dependency on ipxe-qemu was coming from
+that package. But when splitting qemu-system-xen out of it, we forgot
+that the boot roms are hard dependency now. This makes qemu-system-xen
+unusable on a new install until ipxe-qemu is installed too.
+
+An alternative would be to revert upstream commit 178e785fb
+(from 2014) to make rom loading failure a non-fatal error.
+
+ -- Michael Tokarev Sun, 14 May 2023 11:29:12 +0300
+
qemu (1:7.2+dfsg-6) unstable; urgency=medium
[ Michael Tokarev ]
diff -Nru qemu-7.2+dfsg/debian/control qemu-7.2+dfsg/debian/control
--- qemu-7.2+dfsg/debian/control2023-04-29 12:31:07.0 +0300
+++ qemu-7.2+dfsg/debian/control2023-05-11 17:28:22.0 +0300
@@ -400,7 +400,7 @@
Multi-Arch: no
# do we really need qemu-system-data? keymaps only?
Depends: ${shlibs:Depends}, ${misc:Depends}, qemu-system-data (>>
${source:Upstream-Version}~),
- seabios
+ seabios, ipxe-qemu
Recommends: qemu-utils,
ovmf,
Description: QEMU full system emulation (Xen helper package)
diff -Nru qemu-7.2+dfsg/debian/control-in qemu-7.2+dfsg/debian/control-in
--- qemu-7.2+dfsg/debian/control-in 2023-04-29 12:05:13.0 +0300
+++ qemu-7.2+dfsg/debian/control-in 2023-05-07 21:55:26.0 +0300
@@ -412,7 +412,7 @@
Multi-Arch: no
# do we really need qemu-system-data? keymaps only?
Depends: ${shlibs:Depends}, ${misc:Depends}, qemu-system-data (>>
${source:Upstream-Version}~),
- seabios
+ seabios, ipxe-qemu
Recommends: qemu-utils,
ovmf,
:ubuntu:# For the transition from the former qemu-system-x86-xen name
Bug#1035927: unblock: samba/2:4.17.8+dfsg-1
12.05.2023 11:05, Sebastian Ramacher пишет: Control: tags -1 moreinfo On 2023-05-11 12:58:00 +0300, Michael Tokarev wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: sa...@packages.debian.org, pkg-samba-ma...@lists.alioth.debian.org Control: affects -1 + src:samba Please unblock package samba This uploaded caused the autpkgtests of libsoup2.4 and libsoup3 to regress on s390x. Could you please check (with the libsoup maintainers) if that is an issue in libsoup or samba? Thanks Yeah I've seen it today already, - unfortunately it's common for libsoup to sporadically fail here or there. Here's the typical (from current log): # Apache command: '/usr/sbin/apache2' '-d' '/usr/libexec/installed-tests/libsoup-3.0' '-f' 'httpd.conf' '-c' 'ErrorLog /tmp/test-tmp-libsoup-3.0_auth-test.test-049S41/error.log' '-c' 'PidFile /tmp/test-tmp-libsoup-3.0_auth-test.test-049S41/httpd.pid' '-k' 'start' (98)Address already in use: AH00072: make_sock: could not bind to address 127.0.0.1:47524 no listening sockets available, shutting down Usually repeating a test does the "trick", but sure thing it'd be nice if it worked by its own without a need for such babysitting. Obviously this has exactly nothing to do with samba, they start test apache instance on the same listening port and sometimes it happens "too fast", or they don't stop it properly from the previous test. I'll ping libsoap folks once more. Thanks, /mjt
Bug#1035927: unblock: samba/2:4.17.8+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: sa...@packages.debian.org, pkg-samba-ma...@lists.alioth.debian.org Control: affects -1 + src:samba Please unblock package samba [ Reason ] This is a next upstream samba stable/bugfix release (4.17.8) fixing a long number of various bugs all over the place, including a security fix (additional changes addressing CVE-2020-25720). It is definitely a good thing to have it all in bookworm. [ Tests ] First of all, samba upstream has an excellent testsuite ensuring there's no regressions. Plus they pick changes for stable release series very carefully. This release is not an exception. My basic local tests of basic samba file server and AD/DC functionality does not reveal any issues either. [ Risks ] The risk of this update is quite low, due to the way how the upstream stable release is being done. [ 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 ] The debdiff is rather large due to big number of changes. The complete changeset is available in git on salsa.d.o, https://salsa.debian.org/samba-team/samba/-/commits/upstream/4.17.8+dfsg/ When preparing debdiff, I filtered all manpages (*.[15678] - this goes for docs/manpages/ and ctdb/doc/, - unfortunately upstream includes generated manpages in the source tarball, and those are regenerated on every release with current timestamps. I'll strip it all out from the orig source tarball in trixie. The diffstat is still large. d/changelog is at the top. unblock samba/2:4.17.8+dfsg-1 diff -Nru --exclude '*.[1578]' samba-4.17.7+dfsg/debian/changelog samba-4.17.8+dfsg/debian/changelog --- samba-4.17.7+dfsg/debian/changelog 2023-03-29 17:59:17.0 +0300 +++ samba-4.17.8+dfsg/debian/changelog 2023-05-11 10:52:40.0 +0300 @@ -1,3 +1,56 @@ +samba (2:4.17.8+dfsg-1) unstable; urgency=medium + + * upstream stable/security/bugfix release, fixing the following issues: + * https://bugzilla.samba.org/show_bug.cgi?id=14810 + CVE-2020-25720 Create Child permission should not allow + full write to all attributes (additional changes) + * https://bugzilla.samba.org/show_bug.cgi?id=15143 + New filename parser doesn't check veto files smb.conf parameter + * https://bugzilla.samba.org/show_bug.cgi?id=15302 + log flood: smbd_calculate_access_mask_fsp: Access denied: message + level should be lower (this was included in Debian package already) + * https://bugzilla.samba.org/show_bug.cgi?id=15306 + Floating point exception (FPE) via cli_pull_send + at source3/libsmb/clireadwrite.c + * https://bugzilla.samba.org/show_bug.cgi?id=15313 + Large directory optimization broken for non-lcomp path elements + * https://bugzilla.samba.org/show_bug.cgi?id=15317 + winbindd idmap child contacts the domain controller without a need + * https://bugzilla.samba.org/show_bug.cgi?id=15318 + idmap_autorid may fail to map sids of trusted domains for the + * https://bugzilla.samba.org/show_bug.cgi?id=15319 + idmap_hash doesn't use ID_TYPE_BOTH for reverse mappings + * https://bugzilla.samba.org/show_bug.cgi?id=15323 + net ads search -P doesn't work against servers in other domains + * https://bugzilla.samba.org/show_bug.cgi?id=15325 + dsgetdcname: assumes local system uses IPv4 + * https://bugzilla.samba.org/show_bug.cgi?id=15328 + test_tstream_more_tcp_user_timeout_spin fails intermittently + on Rackspace GitLab runners + * https://bugzilla.samba.org/show_bug.cgi?id=15329 + Reduce flapping of ridalloc test + * https://bugzilla.samba.org/show_bug.cgi?id=15329 + Reduce flapping of ridalloc test + * https://bugzilla.samba.org/show_bug.cgi?id=15338 + DS ACEs might be inherited to unrelated object classes + * https://bugzilla.samba.org/show_bug.cgi?id=15351 + large_ldap test is unreliable + * https://bugzilla.samba.org/show_bug.cgi?id=15353 + Temporary smbXsrv_tcon_global.tdb can't be parsed + * https://bugzilla.samba.org/show_bug.cgi?id=15354 + mdssvc may crash when initializing + * https://bugzilla.samba.org/show_bug.cgi?id=15357 + streams_depot fails to create streams + * https://bugzilla.samba.org/show_bug.cgi?id=15358 + shadow_copy2 and streams_depot don't play well together + * https://bugzilla.samba.org/show_bug.cgi?id=15360 + Setting veto files = /.*/ break listing directories + * https://bugzilla.samba.org/show_bug.cgi?id=15366 + wbinfo -u fails on ad dc with >1000 users + * d/gbp.conf: switch debian-branch to "bookworm" + + -- Michael Tokarev Thu, 11 May 2023 10:52:40 +0300 + samba (2:4.17.7+dfsg-1) unstable; urgency=high * upstream stable/security/bugfix release, fixing the following issues: diff -Nru --exclude '*.[1578]' samba-4.17.7+dfsg/debian/gbp.conf samba-4.17.
Bug#1035297: unblock: qemu/1:7.2+dfsg-6
04.05.2023 00:00, Sebastian Ramacher wrote: .. 1. sync with upstream qemu stable/bugfix 7.2.1 release, by removing all patches in debian/patches/master/ and replacing them all with single debian/patches/v7.2.1.diff which is a diff between upstream qemu 7.2.0 and 7.2.1 releases. This is a bulk of the changes in there. See "Other info" section below for more information. 2. Includes upstream qemu stable/bugfix 7.2.2 release. Upstream 7.2.2 needs its own comment. Historically, qemu stable were managed up until next major release is out. Here, 7.2.2 was planned to be tagged the next day after 8.0.0 has been released (8.0 release didn't follow its schedule because of the amount of bugfixes needed there). So by the historical practice 7.2.2 should not be released. But I plan to change this practice, by providing a bit more support for previous major release of qemu, past the next major release date, and also plan to perform at least one more 7.2 upstream stable/bugfix release. We're discussing this on the qemu side. Either way, 7.2.2 is officially tagged in the upstream qemu git tree: https://gitlab.com/qemu-project/qemu/-/tags/v7.2.2 so it's only matter of making a tarball out of it and making an official announcement. So why is that added as a patch instead of uploading the new upstream release? It's been done this way in qemu debian package for ages, for decades. I don't remember anymore why it is. All previous stable qemu releases has been applied as patches to debian. It's always qemu-n.m (instead of qmu-n.m.p) and a patch n.m.p.diff on top. I think it might be relate to the huge size of orig.tar.gz and tiny stable/bugfix release difference on top (but later we reduced orig.tar.gz greatly by removing submodules which exists as separate packages in debian). Maybe we should stop doing this strange thing, but that's not bookworm material I guess. I already packaged 8.0 instead of 8.0.0 for bookworm+1 :) This wont make the diff smaller though. Speaking of actual 7.2.2, I can't reach Michael Roth, who did all official qemu releases during recent years (it is his gpg key which is used to sign the tarballs). I hope to get 7.2.2 out for real. Thanks! /mjt
Bug#1035297: unblock: qemu/1:7.2+dfsg-6
30.04.2023 11:07, Michael Tokarev пишет: ... branch, and also includes the forgotten .desktop file which results in a missing icon file for qemu-system processes. And as I found out later, I should not ship debian-specific qemu.desktop file, since upstream provides its own, I just forgot to include it into the binary package. In the next qemu release I removed d/qemu.desktop amd added a line to d/qemu-system-common.install instead, but forgot to do the same for bookworm. /mjt
Bug#1035297: unblock: qemu/1:7.2+dfsg-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org Please unblock package qemu This debian release has the following: 1. sync with upstream qemu stable/bugfix 7.2.1 release, by removing all patches in debian/patches/master/ and replacing them all with single debian/patches/v7.2.1.diff which is a diff between upstream qemu 7.2.0 and 7.2.1 releases. This is a bulk of the changes in there. See "Other info" section below for more information. 2. Includes upstream qemu stable/bugfix 7.2.2 release. Upstream 7.2.2 needs its own comment. Historically, qemu stable were managed up until next major release is out. Here, 7.2.2 was planned to be tagged the next day after 8.0.0 has been released (8.0 release didn't follow its schedule because of the amount of bugfixes needed there). So by the historical practice 7.2.2 should not be released. But I plan to change this practice, by providing a bit more support for previous major release of qemu, past the next major release date, and also plan to perform at least one more 7.2 upstream stable/bugfix release. We're discussing this on the qemu side. Either way, 7.2.2 is officially tagged in the upstream qemu git tree: https://gitlab.com/qemu-project/qemu/-/tags/v7.2.2 so it's only matter of making a tarball out of it and making an official announcement. 3. Includes a few more fixes which are taken from the upstream development mailing list, targetting next upstream releases (including stable), which fixes known issues. 4. Includes minor changes in the debian packaging, like fixing FTBFS due to unportable usage of \n escapes with echo and switching gbp.conf from master branch to debian-bookworm branch, and also includes the forgotten .desktop file which results in a missing icon file for qemu-system processes. The whole thing seems quite large, and when you look at the diffstat it is large: >3k LOC changed. But this is mostly due to the conversion from debian/patches/master/* to debian/patches/v7.2.1.diff. [ Reason ] This debian release has numerous bug fixes which affects many aspects of qemu functionality within debian. I will be targetting bookworm proposed updates with the same functionality if it misses initial bookworm release. This also includes a fix for relatively old issue which is more specific to debian: aptitude segfaulted within qemu-user environments, #811087. [ Tests ] The release is well-tested, as it is usual for all qemu stable releases, due to qemu excellent CI/testsuite. I verified it, together with extra changes, wihin my set of tests too. The extra changes (on top of 7.2.2) has also been discussed and tested. [ Risks ] As usual, the risk of breaking something do exists. Some unusual use case or guest which we didn't cover by testing and don't yet know about. Still, the amount of real, actual fixes included is much more than possible breakage. [ 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 ] Since the direct diff between 1:7.2+dfsg-5 and 1:7.2+dfsg-6 is quite large, it's difficult to review. So I'm including 2 diffs instead. 1. 7.2+dfsg-6~no-v7.2.2.diff - I made an intermediate "syncing point" debian "release", which is just a sync with upstream 7.2.1. This diff is a difference in *source* (excluding debian/ but including d/patches parts) between extracted 7.2+dfsg-5 and 7.2+dfsg-6 but without the v7.2.2.diff and the extra 7.2+dfsg-6 patches. This diff shows just the sync between debian qemu and 7.2.1 upstream qemu release, plus the changes in d/patches which made it. The change in here is just 4 commits: version bump to 7.2.1 block: Handle curl 7.55.0, 7.85.0 version changes build-sys: fix crlf-ending C code (only affects win32 builds) tests/tcg: fix unused variable in linux-test (fix test failure) all can be found here: https://gitlab.com/qemu-project/qemu/-/commits/v7.2.1 2. From 7.2+dfsg~6-no-v7.2.2, there's another diff to the final 7.2+dfsg-6 release, now comparing debian/ parts only. This includes addition of v7.2.2.diff (and removal of CVE-2022-1050.patch), addition of 3 other patches to the source fixing more bugs, and other changes to debian/. All individual changes in v7.2.2.diff are available at https://gitlab.com/qemu-project/qemu/-/commits/v7.2.2 - it contains a bunch of various bugfixes in individual commits with descriptions. If this is too difficult for the release team to handle, I'm open to changing it somehow. All changes, in my opinion, are worth to have in bookworm, each and all were thought about with care. unblock qemu/1:7.2+dfsg-6 === begin changelog qemu (1:7.2+dfsg-6) unstable; urgency=medium [ Michael Tokarev ] * sync with upstream v7.2
Bug#1034298: unblock: unbound/1.17.1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package unbound
[ Reason ]
There was a small bug in one of the package scripts (#1019140)
which results in unbound being unable to start (and package
failure) depending on the system configuration (quite common
configurations are affected). I hoped do fix this issue together
with another unbound package upload but forgot about that one,
and the issue went into the freeze period.
[ Impact ]
System upgrade failure or unbound failing to startup in
certain configurations.
[ Tests ]
The issue is well-located so it was easy to verify the bug is
fixed after the change. The whole thing is rather trivial.
[ Risks ]
The thing is trivial once you see what's going on.
And the change is trivial too, see the (helper) startup script
diff below.
[ 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 unbound/1.17.1-2
diff -Nru unbound-1.17.1/debian/changelog unbound-1.17.1/debian/changelog
--- unbound-1.17.1/debian/changelog 2023-01-12 18:28:54.0 +0300
+++ unbound-1.17.1/debian/changelog 2023-04-09 15:59:14.0 +0300
@@ -1,3 +1,10 @@
+unbound (1.17.1-2) unstable; urgency=medium
+
+ * unbound-helper: return 0 explicitly in a few places
+(Closes: #1019140)
+
+ -- Michael Tokarev Sun, 09 Apr 2023 15:59:14 +0300
+
unbound (1.17.1-1) unstable; urgency=medium
[ Michael Tokarev ]
diff -Nru unbound-1.17.1/debian/unbound-helper
unbound-1.17.1/debian/unbound-helper
--- unbound-1.17.1/debian/unbound-helper2022-08-12 13:04:20.0
+0300
+++ unbound-1.17.1/debian/unbound-helper2023-01-12 18:49:26.0
+0300
@@ -24,7 +24,7 @@
fi
do_resolvconf_start() {
-[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return
+[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return 0
unbound-checkconf $CHROOT_DIR/$UNBOUND_CONF -o interface | {
default=yes
@@ -44,13 +44,13 @@
}
do_resolvconf_stop() {
-[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return
+[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return 0
/sbin/resolvconf -d lo.unbound
}
do_chroot_setup() {
-[ -n "$CHROOT_DIR" -a -d "$CHROOT_DIR" ] || return
+[ -n "$CHROOT_DIR" -a -d "$CHROOT_DIR" ] || return 0
if [ "$CHROOT_DIR" != "$UNBOUND_BASE_DIR" ]; then
# we probably should not do the force-recreate but just a refresh
rm -rf "$CHROOT_DIR/$UNBOUND_BASE_DIR"
Bug#1034296: unblock: seabios/1.16.2-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org
Please unblock package seabios
[ Reason ]
This debian release syncronizes with the upstream stable/bugfix
release of 1.16.2. Previous debian release of this package had
1.16.1 difference as a patch because upstream forgot to publish
the tarball. 1.16.2-1 has exactly the same stuff the previous
debian revision had (1.16.1), plus two more changes from upstream
stable/bugfix release 1.16.2.
One of the changes is a bugfix for usb hid devices init (which
I've hit myself but thought it's some difficult to diagnose
QEMU bug). It's definitely worth to have this one on bookworm.
The second change is not strictly necessary for bookworm, but
I thought there's no good reason to remove it from the upstream
stable/bugfix release. It is related to the way how seabios
detects Xen, for the rare HVM Xen domU. This change will be
useful for more recent qemu (8.0+) though.
[ Impact ]
There's a relatively small issue with USB HID devices init which
can only trigger in certain configurations, which will be unfixed.
Plus it will be just a bit more work for the further package
maintenance.
[ Tests ]
I tested the new bios package locally with both qemu (bookworm
one and the next version), *and* with actual Xen HVM domU, the
change does not break my setups, but allows new qemu to run
Xen HVM domains too. Upstream has it integrated into the QEMU
CI tests.
[ Risks ]
I don't see much risks with this change. All involved code paths
are quite well tested.
[ 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 ]
Unfortunately the debdiff isn't very useful due to 1.16.1=>upstream
source move. So I'm also adding the diff with patches applied,
which shows only the 2 changes I mentioned above. First comes the
diff, next comes the debdiff.
unblock seabios/1.16.2-1
== begin diff ==
--- seabios-1.16.0/debian/changelog 2022-12-01 17:06:24.0 +0300
+++ seabios-1.16.2/debian/changelog 2023-04-11 16:08:25.0 +0300
@@ -1,3 +1,14 @@
+seabios (1.16.2-1) unstable; urgency=medium
+
+ * sync with upstream stable 1.16.2 release (rel-1.16.2 tag):
+this brings up to the exactly same state as our rel-1.16.1.patch
+did, and brings up 2 more fixes:
+- usb: fix wrong init of keyboard/mouse's if first interface
+ is not boot protocol
+- xen: require Xen info structure at 0x1000 to detect Xen
+
+ -- Michael Tokarev Tue, 11 Apr 2023 16:08:25 +0300
+
seabios (1.16.0-5) unstable; urgency=medium
* d/rules: vgabios.bin compatibility symlink for qemu (Closes: #1024382)
diff -u -r -x '*.pc/*' seabios-1.16.0/debian/patches/series
seabios-1.16.2/debian/patches/series
--- seabios-1.16.0/debian/patches/series2022-12-01 17:06:12.0
+0300
+++ seabios-1.16.2/debian/patches/series2023-04-11 16:07:44.0
+0300
@@ -1,2 +1 @@
nogitversion.patch
-rel-1.16.1.patch
diff -u -r -x '*.pc/*' seabios-1.16.0/src/fw/xen.c seabios-1.16.2/src/fw/xen.c
--- seabios-1.16.0/src/fw/xen.c 2022-03-02 04:29:02.0 +0300
+++ seabios-1.16.2/src/fw/xen.c 2023-02-02 04:14:39.0 +0300
@@ -40,16 +40,25 @@
u32 e820_nr;
} PACKED;
-static void validate_info(struct xen_seabios_info *t)
+static struct xen_seabios_info *validate_info(void)
{
-if ( memcmp(t->signature, "XenHVMSeaBIOS", 14) )
-panic("Bad Xen info signature\n");
+struct xen_seabios_info *t = (void *)INFO_PHYSICAL_ADDRESS;
-if ( t->length < sizeof(struct xen_seabios_info) )
-panic("Bad Xen info length\n");
+if ( memcmp(t->signature, "XenHVMSeaBIOS", 14) ) {
+dprintf(1, "Bad Xen info signature\n");
+return NULL;
+}
+
+if ( t->length < sizeof(struct xen_seabios_info) ) {
+dprintf(1, "Bad Xen info length\n");
+return NULL;
+}
-if (checksum(t, t->length) != 0)
-panic("Bad Xen info checksum\n");
+if (checksum(t, t->length) != 0) {
+dprintf(1, "Bad Xen info checksum\n");
+return NULL;
+}
+return t;
}
void xen_preinit(void)
@@ -86,7 +95,10 @@
dprintf(1, "No Xen hypervisor found.\n");
return;
}
-PlatformRunningOn = PF_QEMU|PF_XEN;
+if (validate_info())
+PlatformRunningOn = PF_QEMU|PF_XEN;
+else
+dprintf(1, "Not enabling Xen support due to lack of Xen info\n");
}
static int hypercall_xen_version( int cmd, void *arg)
@@ -122,10 +134,14 @@
void xen_biostable_setup(void)
{
-struct xen_seabios_info *info = (void *)INFO_PHYSICAL_ADDRESS;
-void **tables = (void*)info->tables;
+struct xen_seabios_info *info = validate_info();
+void
Bug#1019096: bullseye-pu: package cifs-utils/2:6.11-3.1+deb11u2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu There's a FTBFS issue with cifs-utils on bullseye, #993014. This update address that FTBFS issue only, with no other changes [ Reason ] The package fails to build from source when doing non-parallel build (or actually when doing parallel build too, sometimes), due to wrong ordering/dependencies in the upstream Makefile system. The problem is that the install target is two-part, and "second" part relies on mkdir done in "first" part, while not enforcing it. This (usually) succeeds when doing parallel build, but always fails when doing non-parallel build. [ Impact ] There's no other impact for the user besides the failure to build from source. [ Tests ] The build succeeded when doing either parallel or non-parallel build. Since there's no actual code changes, no other testing is necessary. [ Risks ] There's no risks here, since there's no code changes done. Only the build (ordering) fix, the same as applied to testing. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] The changelog entry: cifs-utils (2:6.11-3.1+deb11u2) bullseye; urgency=medium * Fix non-parallel build. Closes: #993014. The fix adds an ordering/dependency rule to the Makefile, which ensures that the mkdir is done first and files created there only after that. [ Other info ] [ Debdiff ] diff -Nru cifs-utils-6.11/debian/changelog cifs-utils-6.11/debian/changelog --- cifs-utils-6.11/debian/changelog2022-05-10 23:12:42.0 +0300 +++ cifs-utils-6.11/debian/changelog2022-08-27 03:20:00.0 +0300 @@ -1,3 +1,9 @@ +cifs-utils (2:6.11-3.1+deb11u2) bullseye; urgency=medium + + * Fix non-parallel build. Closes: #993014. + + -- Michael Tokarev Sat, 27 Aug 2022 02:20:00 +0200 + cifs-utils (2:6.11-3.1+deb11u1) bullseye-security; urgency=high * Non-maintainer upload by the Security Team. diff -Nru cifs-utils-6.11/debian/patches/root_sbindir-hook.patch cifs-utils-6.11/debian/patches/root_sbindir-hook.patch --- cifs-utils-6.11/debian/patches/root_sbindir-hook.patch 1970-01-01 03:00:00.0 +0300 +++ cifs-utils-6.11/debian/patches/root_sbindir-hook.patch 2022-08-27 03:20:00.0 +0300 @@ -0,0 +1,11 @@ +--- a/Makefile.am b/Makefile.am +@@ -118,7 +118,7 @@ + + SUBDIRS = contrib + +-install-exec-hook: ++install-exec-hook: install-root_sbinPROGRAMS + (cd $(DESTDIR)$(ROOTSBINDIR) && ln -sf mount.cifs mount.smb3) + + install-data-hook: diff -Nru cifs-utils-6.11/debian/patches/series cifs-utils-6.11/debian/patches/series --- cifs-utils-6.11/debian/patches/series 2022-05-10 23:12:42.0 +0300 +++ cifs-utils-6.11/debian/patches/series 2022-08-27 03:20:00.0 +0300 @@ -5,3 +5,4 @@ 0011-fix-regression-for-CVE-2021-20208.patch CVE-2022-27239-mount.cifs-fix-length-check-for-ip-op.patch mount.cifs-fix-verbose-messages-on-option-parsing.patch +root_sbindir-hook.patch
Bug#1011267: "No test result" for superficial tests is misleading
Package: release.debian.org
Severity: minor
User: release.debian@packages.debian.org
Usertags: britney
When a package provides only superficial tests, tracker.d.o page shows
"No test results" "result" for the autopkgtests. This is misleading,
especially since it links to a successful test result, - it looks like
autopkgtest infrastructure is broken or the result hasn't been updated
yet (like the same page shows "missing build on $arch" while it just
built on $arch, - the page just hasn't been updated to reflect the
build on this architecture).
In order to remove this confusion, the wording for this case should be
changed. I'm not a native English speaker, but I do have some suggestions
for
https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py#L61
EXCUSES_LABELS = {
"NEUTRAL": 'No test results',
(and OLD_NEUTRAL too). It might be "Nonconclusive" (or "Inconclusive"),
or "Superficial/Skipped" (depending on the reasons why "NEUTRAL" result
can happen), or even "Neutral", - instead of "No test results".
Thanks,
/mjt
Bug#1009726: bullseye-pu: package samba/2:4.13.13+dfsg-1+deb11u4
So, is there anything else needed on my side to help this? I can re-send the debdiff (the change against the previous one was the removal of closing of #1002059 from d/changelog which slipped there by mistake, and going from -1+deb11u4 to -1~deb11u4 per carnil@ suggestion. Thanks, /mjt
Bug#1009726: bullseye-pu: package samba/2:4.13.13+dfsg-1+deb11u4
26.04.2022 10:37, Salvatore Bonaccorso wrote: Hi, On Fri, Apr 15, 2022 at 05:12:38PM +0300, Michael Tokarev wrote: * switch from weird ~deb11uN to the usual +deb11uN release numbering scheme since a more recent upstream version is available in testing now It is not really a change per se, just an indication that the versioning scheme is finally back to normal. I'm not speaking autoritatively here, but please do not do that. It changes the semantics and meaning what's happening and doe not sort anymore before the 2:4.13.13+dfsg-1. Ok, I reverted this very change now. It's definitely not a big deal, I just thought it will be a good thing to do. Let it be the way it has already been in bullseye. Thank you! /mjt
Bug#1009726: bullseye-pu: package samba/2:4.13.13+dfsg-1+deb11u4
23.04.2022 11:28, Michael Tokarev wrote: ... This also fixes a *sporaric* (rare) broken build which actually happened with previous security update: #1006935, #1009855, #1002059 The #1002059 slipped there by a mistake. It is a different problem, most likely a misconfiguration on the OP side. So I had to remove mention of this bug# from the changelog. The rest of it is okay. Please excuse me for the extra noise. There's just too many bugs - still open and being closed by this update too. Thanks, /mjt
Bug#1009726: bullseye-pu: package samba/2:4.13.13+dfsg-1+deb11u4
ber and the changes in lib/ldb/ which are packaged separately. * 4 patches from upstream to fix possible serious data corruption issue with windows client cache poisoning, Closes: #1005642 https://bugzilla.samba.org/show_bug.cgi?id=14928 This comes from upstream targetting later samba series, backported to all relevant stable series. The prob has been fixed after 4.13.17 went end-of-life. * two patches from upstream to fix coredump when connecting to shares with var substitutions, Closes: #998423 https://bugzilla.samba.org/show_bug.cgi?id=14809 Ditto. * samba-common-bin.postinst: mkdir /run/samba before invoking samba binaries Closes: #953530 This simple change helps new installs on systemd-less systems * remove file creation+deletion from previously applied combined patches CVE-2021-23192-only-4.13-v2.patch & CVE-2021-3738-dsdb-crash-4.13-v03.patch to make patch deapply happy (quilt does not notice this situation) This one is kinda interesting. Previous security upload included two cumulative .patch files (containing several git commits in single file), with first of them adding a file, and second removing that just-added file. This does not work right with quilt, it keeps such "phantom" file in the source tree when deapplying patches, so subsequent apply fails due to the file already exist. So I had to remove parts of these combined patches which adds and deletes these files to make quilt happy. This change does not affect the resulting code in any way, the result of applying the cleaned-up patches is *exactly* the same, it just helps with the package building process. The files being added+removed are small (these are just lists of tests known to fail which gets cleaned up when the actual fix is applied) so it's easy to see what's going on there. * switch from weird ~deb11uN to the usual +deb11uN release numbering scheme since a more recent upstream version is available in testing now It is not really a change per se, just an indication that the versioning scheme is finally back to normal. * d/salsa-ci.yml: target bullseye This does nothing to the code, but in order to run salsa-ci tests I had to change "experimental" to "bullseye" in there. It successfully passed all tests which it passed before. Please consider accepting this release of samba to bullseye-pu. Having in mind the current situation with the i386 build ( #1006935, #1009855, #1002059 ), maybe we can go a faster route. Tho, for these i386 issues, a simple rebuild will most likely fix all 3 issues, since this is a very rare event to get a broken build.. - debdiff follows - diff -Nru samba-4.13.13+dfsg/debian/changelog samba-4.13.13+dfsg/debian/changelog --- samba-4.13.13+dfsg/debian/changelog 2022-02-03 23:54:02.0 +0300 +++ samba-4.13.13+dfsg/debian/changelog 2022-04-23 11:13:39.0 +0300 @@ -1,3 +1,40 @@ +samba (2:4.13.13+dfsg-1+deb11u4) bullseye; urgency=medium + + * fix the order of everything during build by exporting PYTHONHASHSEED=1 +for waf. This should fix the broken i386 build of the last security +upload. Closes: #1006935, #1009855, #1002059 + * Import the left-over patches from 4.13.17 upstream stable branch: + - s3-winbindd-fix-allow-trusted-domains-no-regression.patch + https://bugzilla.samba.org/show_bug.cgi?id=14899 + Closes: #999876, winbind fails to start with `allow trusted domains: no` + - IPA-DC-add-missing-checks.patch + https://bugzilla.samba.org/show_bug.cgi?id=14903 + - CVE-2020-25717-s3-auth-fix-MIT-Realm-regression.patch + https://bugzilla.samba.org/show_bug.cgi?id=14922 + Closes: #1001053, MIT-kerberos auth broken after 4.13.13+dfsg-1~deb11u2 + - dsdb-Use-DSDB_SEARCH_SHOW_EXTENDED_DN-when-searching.patch + https://bugzilla.samba.org/show_bug.cgi?id=14656 + https://bugzilla.samba.org/show_bug.cgi?id=14902 + - s3-smbd-Fix-mkdir-race-condition-allows-share-escape.patch + https://bugzilla.samba.org/show_bug.cgi?id=13979 + Closes: #1004691, CVE-2021-43566: mkdir race condition allows share escape + * 4 patches from upstream to fix possible serious data corruption issue +with windows client cache poisoning, Closes: #1005642 +https://bugzilla.samba.org/show_bug.cgi?id=14928 + * two patches from upstream to fix coredump when connecting to shares +with var substitutions, Closes: #998423 +https://bugzilla.samba.org/show_bug.cgi?id=14809 + * samba-common-bin.postinst: mkdir /run/samba before invoking samba binaries +Closes: #953530 + * remove file creation+deletion from previously applied combined patches +CVE-2021-23192-only-4.13-v2.patch & CVE-2021-3738-dsdb-crash-4.13-v03.patch +to make patch deapply happy (quilt does not notice this situation) + * switch from weird ~deb11uN to the usual +deb11uN release numbering scheme +since a more recent upstream version is available in testing now + * d/salsa-ci.yml: target bull
Bug#1009726: broken build of samba_4.13.13+dfsg-1~deb11u3 on i386
Hello! It turned out the security-uploaded build of samba on i386 is broken. There were several reports about smbd segfaulting at startup or other weirdness. This is specific to i386 build, the x64 build is fine (and I know nothing about the other architectures). An example bugreport is #1006935 - it has several items in the list of broken things, but this list is definitely not complete. Also #1009855 #1002059. I tried to rebuild the same source package in a local clean bullseye chroot, apparently with the same versions of everything, in the same environment, and I'm getting *significantly* different binaries. Updating just one package - switching from debian-built one into my locally-built one immediately fixes the problem for me, samba starts working as it should without weird errors or crashes. The issue at hand seems to be the usage of python hashes in samba build procedure for everything including lists of include or library paths, lists of object files for link and everything. By default, python hashes are randomly-ordered, - this means the order of all this is unpredictable and each time we're getting VERY different binaries. Since samba overrides many system-provided functions, and the order of objects to link is important, in this particular build we got an order which made it use wrong functions in the end, and the thing started to behave in a weird way. Upstream tried to fix this by using PYTHONHASHSEED=1 (which *still* gives an order which depends on the architecture, but this is a different issue). So we have to fix this one in bullseye. I already prepared a bullseye-pu version of samba - #1009726 - the bug#), which does not include this fix. I'll update it today (the fix is trivial) and resubmit. The bullseye-pu version has some more fixes than is usually okay to bring to security@ but most of them are worth the effort. Now since the prob is quite serious, maybe we can fix this some faster way? Thanks, /mjt
Bug#1009726: bullseye-pu: package samba/2:4.13.13+dfsg-1+deb11u4
pply fails due to the file already exist. So I had to remove parts of these combined patches which adds and deletes these files to make quilt happy. This change does not affect the resulting code in any way, the result of applying the cleaned-up patches is *exactly* the same, it just helps with the package building process. The files being added+removed are small (these are just lists of tests known to fail which gets cleaned up when the actual fix is applied) so it's easy to see what's going on there. * switch from weird ~deb11uN to the usual +deb11uN release numbering scheme since a more recent upstream version is available in testing now It is not really a change per se, just an indication that the versioning scheme is finally back to normal. * d/salsa-ci.yml: target bullseye This does nothing to the code, but in order to run salsa-ci tests I had to change "experimental" to "bullseye" in there. It successfully passed all tests which it passed before. [ Other info ] (Anything else the release team should know.) --- diff -Nru samba-4.13.13+dfsg/debian/changelog samba-4.13.13+dfsg/debian/changelog --- samba-4.13.13+dfsg/debian/changelog 2022-02-03 23:54:02.0 +0300 +++ samba-4.13.13+dfsg/debian/changelog 2022-04-15 16:25:59.0 +0300 @@ -1,3 +1,30 @@ +samba (2:4.13.13+dfsg-1+deb11u4) bullseye; urgency=medium + + * Import the left-other patches from 4.13.17 upstream stable branch: + - s3-winbindd-fix-allow-trusted-domains-no-regression.patch + Closes: #999876, winbind fails to start with `allow trusted domains: no` + - IPA-DC-add-missing-checks.patch + - CVE-2020-25717-s3-auth-fix-MIT-Realm-regression.patch + Closes: #1001053, MIT-kerberos auth broken after 4.13.13+dfsg-1~deb11u2 + - dsdb-Use-DSDB_SEARCH_SHOW_EXTENDED_DN-when-searching.patch + - s3-smbd-Fix-mkdir-race-condition-allows-share-escape.patch + Closes: #1004691, CVE-2021-43566: + mkdir race condition allows share escape + * 4 patches from upstream to fix possible serious data corruption issue +with windows client cache poisoning, Closes: #1005642 + * two patches from upstream to fix coredump when connecting to shares +with var substitutions, Closes: #998423 + * samba-common-bin.postinst: mkdir /run/samba before invoking samba binaries +Closes: #953530 + * remove file creation+deletion from previously applied combined patches +CVE-2021-23192-only-4.13-v2.patch & CVE-2021-3738-dsdb-crash-4.13-v03.patch +to make patch deapply happy (quilt does not notice this situation) + * switch from weird ~deb11uN to the usual +deb11uN release numbering scheme +since a more recent upstream version is available in testing now + * d/salsa-ci.yml: target bullseye + + -- Michael Tokarev Fri, 15 Apr 2022 16:25:59 +0300 + samba (2:4.13.13+dfsg-1~deb11u3) bullseye-security; urgency=high * Non-maintainer upload by the Security Team. diff -Nru samba-4.13.13+dfsg/debian/libwbclient0.symbols samba-4.13.13+dfsg/debian/libwbclient0.symbols --- samba-4.13.13+dfsg/debian/libwbclient0.symbols 2022-02-03 23:54:02.0 +0300 +++ samba-4.13.13+dfsg/debian/libwbclient0.symbols 2022-04-15 16:24:01.0 +0300 @@ -276,6 +276,7 @@ nt_time_to_full_timespec@SAMBA_UTIL_0.0.1 2:4.12.0+dfsg nt_time_to_unix@SAMBA_UTIL_0.0.1 2:4.11.0 nt_time_to_unix_timespec@SAMBA_UTIL_0.0.1 2:4.11.0 + nt_time_to_unix_timespec_raw@SAMBA_UTIL_0.0.1 2:2.4.13+dfsg-1~deb11u4 nttime_to_timeval@SAMBA_UTIL_0.0.1 2:4.11.0 null_nttime@SAMBA_UTIL_0.0.1 2:4.11.0 null_time@SAMBA_UTIL_0.0.1 2:4.11.0 diff -Nru samba-4.13.13+dfsg/debian/patches/bug1005642-lib-util-Add-a-function-nt_time_to_unix_timespec_raw.patch samba-4.13.13+dfsg/debian/patches/bug1005642-lib-util-Add-a-function-nt_time_to_unix_timespec_raw.patch --- samba-4.13.13+dfsg/debian/patches/bug1005642-lib-util-Add-a-function-nt_time_to_unix_timespec_raw.patch 1970-01-01 03:00:00.0 +0300 +++ samba-4.13.13+dfsg/debian/patches/bug1005642-lib-util-Add-a-function-nt_time_to_unix_timespec_raw.patch 2022-04-15 16:24:01.0 +0300 @@ -0,0 +1,77 @@ +From 43530db58aa8b7cd4e6f5365fd12ab9ee7861c0d Mon Sep 17 00:00:00 2001 +From: Jeremy Allison +Date: Thu, 6 Jan 2022 13:58:20 -0800 +Subject: [PATCH 1/4] lib: util: Add a function nt_time_to_unix_timespec_raw(). + +Not yet used. Does no checks on the converted values. + +A later cleanup will allow us to move nt_time_to_unix_timespec() +and nt_time_to_full_timespec() to use common code. + +BUG: https://bugzilla.samba.org/show_bug.cgi?id=14928 + +Signed-off-by: Jeremy Allison +Reviewed-by: Christof Schmitt +(cherry picked from commit 29d69c22a0d945193ce3dac27e1083dbc5c53f03) +--- + lib/util/time.c | 30 ++ + lib/util/time.h | 2 ++ + 2 files changed, 32 insertions(+) + +diff --git a/lib/util/time.c b/lib/util/time.c +index 0fac5e2e397..b49d2fa6f30 100644 +--- a/lib/util/time.c b/lib/util/time.c +@@ -865,6 +865,36
Bug#995469: bullseye-pu: package libslirp/4.4.0-1+deb11u2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu There are a few security bugs found in libslirp, a user-level networking library used in qemu and other places, in version in bullseye. These bugs has already been fixed in -testing by a new upstream version of the library, but these CVEs are still listed for it in bullseye. The impact of these bugs are relatively low, - this is why the security team decided to not release a DSA for them. However they're security issues still, and I'd be really glad to clear the list of security issues for this package. I asked the security team about pushing this to bullseye-security and the answer was to go the bullseye-proposed-updates route. The way how libslirp is used in qemu makes every bug in libslirp to be basically non-essential, since user-level networking is only good for some quick testing, it is not supposed to be used in production. However I don't know how this library is used in other places. [ Tests ] There's no automated tests tried for this library. Neither do I have reproducers for all the issues involved. However I tested the user-mode networking of qemu with this proposed version of libslirp and gave it as much stress testing as I can, especially trying to hit the areas changed. Run a bunch of various stress testing and manually did stuff including various UDP protocols, tftp transfers, and BOOTP debugging. So far everything seems to work correctly. After submitting the previous release I found another issue which was the most simple and which for some reason I weren't tested, and fixed it by another, later change from upstream, - which fixed a regression if one of the fix. This is actually the most typical usage scenario, and now I'm certain the most common case is working too. No other changes upstream are relevant. The same changes were made upstream (these *are* changes taken from upstream, with very minor editing of context so eg function declarations will find their way in the header file which, in a later version, contained more declarations than in the version in bullseye), - and these upstream changes has been tested by numerous people including debian testing. I hadn't need to backport the changes, the code is the same (if not counting the context in header file). [ Risks ] Again, due to the nature of this package which is mostly aimed for testing and not real production, the risk of breaking it is rather small. It can affect quite some people ofcourse. Having in mind this is the same set of changes already used by many people in a more recent version, I don't expect a big issue there. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Here are the changelog entry for the new release: libslirp (4.4.0-1+deb11u2) bullseye; urgency=medium * fix-DHCP-broken-in-libslirp-v4.6.0.patch from upstream this fixes previous change in this area (bootp-limit-vendor-area-to-input-packet-CVE-2021-3592.patch). https://gitlab.freedesktop.org/slirp/libslirp/-/issues/48 -- Michael Tokarev Fri, 01 Oct 2021 19:10:39 +0300 libslirp (4.4.0-1+deb11u1) bullseye; urgency=medium * import a few patches from upstream to fix 4 security issues: - add-mtod_check.patch (preparational) - bootp-limit-vendor-area-to-input-packet-CVE-2021-3592.patch, bootp-check-bootp_input-buffer-size-CVE-2021-3592.patch Closes: #989993, CVE-2021-3592: invalid pointer init in bootp_init() - tftp-check-tftp_input-buffer-size-CVE-2021-3595.patch, tftp-introduce-a-header-structure-CVE-2021-3595.patch Closes: #989996, CVE-2021-3595: invalid pointer init in tftp_input() - udp-check-upd_input-buffer-size-CVE-2021-3594.patch Closes: #989995, CVE-2021-3594: invalid pointer init in udp_input() - upd6-check-udp6_input-buffer-size-CVE-2021-3593.patch Closes: #989994, CVE-2021-3593: invalid pointer init in udp6_input() -- Michael Tokarev Thu, 30 Sep 2021 21:08:51 +0300 [ Other info ] And here's the debdiff. Thanks! /mjt diff -Nru libslirp-4.4.0/debian/changelog libslirp-4.4.0/debian/changelog --- libslirp-4.4.0/debian/changelog 2020-12-19 18:36:33.0 +0300 +++ libslirp-4.4.0/debian/changelog 2021-10-01 19:10:39.0 +0300 @@ -1,3 +1,29 @@ +libslirp (4.4.0-1+deb11u2) bullseye; urgency=medium + + * fix-DHCP-broken-in-libslirp-v4.6.0.patch from upstream +this fixes previous change in this area +(bootp-limit-vendor-area-to-input-packet-CVE-2021-3592.patch). +https://gitlab.freedesktop.org/slirp/libslirp/-/issues/48 + + -- Michael Tokarev Fri, 01 Oct 2021 19:10:39 +0300 + +libslirp (4.4.0-1+deb11u1) bullseye; urgency=medium + + * import a few patches from upstream to fix 4 security issues: + - add
Bug#995439: bullseye-pu: package libslirp/4.4.0-1+deb11u1
Control: tag -1 moreinfo Actually this particular upload does break some things, it seems. I'm investigating.. /mjt
Bug#995439: bullseye-pu: package libslirp/4.4.0-1+deb11u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu There are a few security bugs found in libslirp, a user-level networking library used in qemu and other places, in version in bullseye. These bugs has already been fixed in -testing by a new upstream version of the library, but these CVEs are still listed for it in bullseye. The impact of these bugs are relatively low, - this is why the security team decided to not release a DSA for them. However they're security issues still, and I'd be really glad to clear the list of security issues for this package. I asked the security team about pushing this to bullseye-security and the answer was to go the bullseye-proposed-updates route. The way how libslirp is used in qemu makes every bug in libslirp to be basically non-essential, since user-level networking is only good for some quick testing, it is not supposed to be used in production. However I don't know how this library is used in other places. [ Tests ] There's no automated tests tried for this library. Neither do I have reproducers for all the issues involved. However I tested the user-mode networking of qemu with this proposed version of libslirp and gave it as much stress testing as I can, especially trying to hit the areas changed. Run a bunch of various stress testing and manually did stuff including various UDP protocols, tftp transfers, and BOOTP debugging. So far everything seems to work correctly. The same changes were made upstream (these *are* changes taken from upstream, with very minor editing of context so eg function declarations will find their way in the header file which, in a later version, contained more declarations than in the version in bullseye), - and these upstream changes has been tested by numerous people including debian testing. I hadn't need to backport the changes, the code is the same (if not counting the context in header file). [ Risks ] Again, due to the nature of this package which is mostly aimed for testing and not real production, the risk of breaking it is rather small. It can affect quite some people ofcourse. Having in mind this is the same set of changes already used by many people in a more recent version, I don't expect a big issue there. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Here are the changelog entry for the new release: libslirp (4.4.0-1+deb11u1) bullseye; urgency=medium * import a few patches from upstream to fix 4 security issues: - add-mtod_check.patch (preparational) - bootp-limit-vendor-area-to-input-packet-CVE-2021-3592.patch, bootp-check-bootp_input-buffer-size-CVE-2021-3592.patch Closes: #989993, CVE-2021-3592: invalid pointer init in bootp_init() - tftp-check-tftp_input-buffer-size-CVE-2021-3595.patch, tftp-introduce-a-header-structure-CVE-2021-3595.patch Closes: #989996, CVE-2021-3595: invalid pointer init in tftp_input() - udp-check-upd_input-buffer-size-CVE-2021-3594.patch Closes: #989995, CVE-2021-3594: invalid pointer init in udp_input() - upd6-check-udp6_input-buffer-size-CVE-2021-3593.patch Closes: #989994, CVE-2021-3593: invalid pointer init in udp6_input() -- Michael Tokarev Thu, 30 Sep 2021 21:08:51 +0300 [ Other info ] And here's the debdiff. Thanks! /mjt diff -Nru libslirp-4.4.0/debian/changelog libslirp-4.4.0/debian/changelog --- libslirp-4.4.0/debian/changelog 2020-12-19 18:36:33.0 +0300 +++ libslirp-4.4.0/debian/changelog 2021-09-30 21:08:51.0 +0300 @@ -1,3 +1,20 @@ +libslirp (4.4.0-1+deb11u1) bullseye; urgency=medium + + * import a few patches from upstream to fix 4 security issues: + - add-mtod_check.patch (preparational) + - bootp-limit-vendor-area-to-input-packet-CVE-2021-3592.patch, + bootp-check-bootp_input-buffer-size-CVE-2021-3592.patch + Closes: #989993, CVE-2021-3592: invalid pointer init in bootp_init() + - tftp-check-tftp_input-buffer-size-CVE-2021-3595.patch, + tftp-introduce-a-header-structure-CVE-2021-3595.patch + Closes: #989996, CVE-2021-3595: invalid pointer init in tftp_input() + - udp-check-upd_input-buffer-size-CVE-2021-3594.patch + Closes: #989995, CVE-2021-3594: invalid pointer init in udp_input() + - upd6-check-udp6_input-buffer-size-CVE-2021-3593.patch + Closes: #989994, CVE-2021-3593: invalid pointer init in udp6_input() + + -- Michael Tokarev Thu, 30 Sep 2021 21:08:51 +0300 + libslirp (4.4.0-1) unstable; urgency=medium * new upstream release diff -Nru libslirp-4.4.0/debian/patches/add-mtod_check.patch libslirp-4.4.0/debian/patches/add-mtod_check.patch --- libslirp-4.4.0/debian/patches/add-mtod_check.patch 1970-01-01 03:00:00.0 +0300 +++ libslirp-4.4.0/debian/patches/add-mtod_check.patch 2021-09-30 20:50
Bug#991246: unblock: qemu/1:5.2+dfsg-11
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-qemu-de...@alioth-lists.debian.net
Please unblock package qemu
[ Reason ]
The new qemu release fixes a few security bugs, and fixes one
non-security-related bug which especially affects upgrades from
buster to bullseye, where some virtual machines, notable Windows,
fails badly when migrated from buster qemu to bullseye qemu.
All the changes has been taken from upstream - either already
released in 6.0, or addressed in qemu stable series.
[ Impact ]
The main issue here is the brokeness of Virtual Machines when
upgraded from buster to bullseye. This is #990675. In my opinion,
it should definitely be fixed for bullseye, or else we will have
broken systems after the upgrade.
The rest are the security issues fixed by this release.
The debdiff is rather large, but this is mostly because of the
amount of changes, not because of the size of the changes.
[ Tests ]
Most tests has been done by the upstream qemu and its users.
All the changes I used in this release are already included upstream.
I tested at least the ide change (#983575), it does not seem to limit
the regular operations of the emulated device, while it fixes the
corner case which is what this bug is about.
I also tested migration buster=>bullseye, and now with the fix for
#990675, it works as expected.
[ Risks ]
Most of the areas which are touched by this update are rarely used in
practice. In particular, 3 bugs in pvrdma code are about vmware
compatibility, so should not affect most users of qemu. For 2 USB
changes there should be more active users but these seems to be easy,
at least they look right to me.
While qemu has become one of the key packages, we should try to keep
it in line with upstream fixes, I think.
[ 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 ]
(Anything else the release team should know.)
unblock qemu/1:5.2+dfsg-11
diff -Nru qemu-5.2+dfsg/debian/changelog qemu-5.2+dfsg/debian/changelog
--- qemu-5.2+dfsg/debian/changelog 2021-04-16 12:43:36.0 +0300
+++ qemu-5.2+dfsg/debian/changelog 2021-07-18 16:14:41.0 +0300
@@ -1,3 +1,23 @@
+qemu (1:5.2+dfsg-11) unstable; urgency=medium
+
+ * i386-acpi-restore-device-paths-for-pre-5.1-vms.patch
+This fixes a serious issue in some VMs (in particuar, Windows & MacOS)
+when migrating from buster qemu to bullseye qemu.
+(Closes: #990675)
+ * pvrdma-fix-possible-mremap-overflow-in-pvrdma-device-CVE-2021-3582.patch
+(Closes: #990565, CVE-2021-3582)
+ * pvrdma-ensure-correct-input-on-ring-init-CVE-2021-3607.patch
+(Closes: #990564, CVE-2021-3607)
+ * pvrdma-fix-the-ring-init-error-flow-CVE-2021-3608.patch
+(Closes: #990563, CVE-2021-3608)
+ * ide-atapi-check-logical-block-address-and-read-size-CVE-2020-29443.patch
+(Closes: #983575, CVE-2020-29443)
+ * usb-limit-combined-packets-to-1-MiB-CVE-2021-3527.patch
+usb-redir-avoid-dynamic-stack-allocation-CVE-2021-3527.patch
+(Closes: #988157, CVE-2021-3527)
+
+ -- Michael Tokarev Sun, 18 Jul 2021 16:14:41 +0300
+
qemu (1:5.2+dfsg-10) unstable; urgency=medium
* 5 sdhci fixes from upstream:
diff -Nru
qemu-5.2+dfsg/debian/patches/i386-acpi-restore-device-paths-for-pre-5.1-vms.patch
qemu-5.2+dfsg/debian/patches/i386-acpi-restore-device-paths-for-pre-5.1-vms.patch
---
qemu-5.2+dfsg/debian/patches/i386-acpi-restore-device-paths-for-pre-5.1-vms.patch
1970-01-01 03:00:00.0 +0300
+++
qemu-5.2+dfsg/debian/patches/i386-acpi-restore-device-paths-for-pre-5.1-vms.patch
2021-07-05 21:47:06.0 +0300
@@ -0,0 +1,98 @@
+Commit-Id: 0a343a5add75f9f90c65e932863d57ddbcb28f5c
+From: Vitaly Cheptsov
+Date: Mon, 1 Mar 2021 22:59:18 +0300
+Subject: i386/acpi: restore device paths for pre-5.1 vms
+Bug-Debian: http://bugs.debian.org/990675
+
+After fixing the _UID value for the primary PCI root bridge in
+af1b80ae it was discovered that this change updates Windows
+configuration in an incompatible way causing network configuration
+failure unless DHCP is used. More details provided on the list:
+
+https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg08484.html
+
+This change reverts the _UID update from 1 to 0 for q35 and i440fx
+VMs before version 5.2 to maintain the original behaviour when
+upgrading.
+
+Cc: qemu-sta...@nongnu.org
+Cc: qemu-de...@nongnu.org
+Reported-by: Thomas Lamprecht
+Suggested-by: Michael S. Tsirkin
+Signed-off-by: Vitaly Cheptsov
+Message-Id: <20210301195919.9333-1-chept...@ispras.ru>
+Tested-by: Thomas Lamprecht
+Reviewed-by: Igor Mammedov
+Reviewed-by: Michael S. Tsirkin
+Signed-off-by: Michael S. Tsirkin
+Fixes: af1b80ae56c9 ("i386/acpi: fix inconsistent QEMU/OVMF device paths")
+---
+ hw/i386/acpi-build.c | 4 ++--
+ hw/i386/pc_piix.c| 2 ++
+ h
Bug#988186: unblock: qemu/1:5.2+dfsg-10
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package qemu
The version in unstable contains just 2 (or 4 when counting
repeated ones) CVE fixes both taken from upstream stable.
It took me 20 days to realize the package will NOT migrate
automatically :)
The debdiff is rather large because one of the fixes turned out
to be a patch SET rather than a single fix, because the area of
the problem is quite wide and there are actually numerous probs
in there, not a single problem. This is the 5 sdhci device
emulation fixes. Another fix is for mptsas device emulation.
Both the risks and the impact are rather low because both
(virtual) devices are not very commonly used. However it
is better to fix security holes when possible, and the
resulting binaries can now pass all the trigger testcases
for the problems which I were able to find (qemu package
still does not have automatic testsuite).
The debdiff is below.
[ 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 qemu/1:5.2+dfsg-10
---
diff -Nru qemu-5.2+dfsg/debian/changelog qemu-5.2+dfsg/debian/changelog
--- qemu-5.2+dfsg/debian/changelog 2021-03-17 21:02:30.0 +0300
+++ qemu-5.2+dfsg/debian/changelog 2021-04-16 12:43:36.0 +0300
@@ -1,3 +1,18 @@
+qemu (1:5.2+dfsg-10) unstable; urgency=medium
+
+ * 5 sdhci fixes from upstream:
+dont-transfer-any-data-when-command-time-out.patch
+dont-write-to-SDHC_SYSAD-register-when-transfer-is-in-progress.patch
+correctly-set-the-controller-status-for-ADMA.patch
+limit-block-size-only-when-SDHC_BLKSIZE-register-is-writable.patch
+reset-the-data-pointer-of-s-fifo_buffer-when-a-different-block-size...patch
+(Closes: #986795, #970937, CVE-2021-3409, CVE-2020-17380, CVE-2020-25085)
+ * mptsas-remove-unused-MPTSASState.pending-CVE-2021-3392.patch
+fix possible use-after-free in mptsas_free_request
+(Cloese: #984449, CVE-2021-3392)
+
+ -- Michael Tokarev Fri, 16 Apr 2021 12:43:36 +0300
+
qemu (1:5.2+dfsg-9) unstable; urgency=medium
* do not make qemu-system-data dependent on qemu-system-foo
diff -Nru
qemu-5.2+dfsg/debian/patches/mptsas-remove-unused-MPTSASState.pending-CVE-2021-3392.patch
qemu-5.2+dfsg/debian/patches/mptsas-remove-unused-MPTSASState.pending-CVE-2021-3392.patch
---
qemu-5.2+dfsg/debian/patches/mptsas-remove-unused-MPTSASState.pending-CVE-2021-3392.patch
1970-01-01 03:00:00.0 +0300
+++
qemu-5.2+dfsg/debian/patches/mptsas-remove-unused-MPTSASState.pending-CVE-2021-3392.patch
2021-04-16 12:43:36.0 +0300
@@ -0,0 +1,61 @@
+From: Michael Tokarev
+Date: Fri, 16 Apr 2021 13:18:59 +0300
+Subject: mptsas: remove unused MPTSASState.pending (CVE-2021-3392)
+Bug-Debian: http://bugs.debian.org/984449
+
+During previous attempt to fix CVE-2021-3392 it was discovered
+that MPTSASState.pending is actually not used. So instead of
+fixing the prob, just remove the offending code entirely
+
+Signed-off-by: Michael Tokarev
+Cc: Prasad J Pandit
+Cc: qemu-sta...@nongnu.org
+---
+ hw/scsi/mptsas.c | 4
+ hw/scsi/mptsas.h | 1 -
+ 2 files changed, 5 deletions(-)
+
+diff --git a/hw/scsi/mptsas.c b/hw/scsi/mptsas.c
+index 7416e78706..5abbc742aa 100644
+--- a/hw/scsi/mptsas.c
b/hw/scsi/mptsas.c
+@@ -257,7 +257,6 @@ static void mptsas_free_request(MPTSASRequest *req)
+ req->sreq->hba_private = NULL;
+ scsi_req_unref(req->sreq);
+ req->sreq = NULL;
+-QTAILQ_REMOVE(>pending, req, next);
+ }
+ qemu_sglist_destroy(>qsg);
+ g_free(req);
+@@ -303,7 +302,6 @@ static int mptsas_process_scsi_io_request(MPTSASState *s,
+ }
+
+ req = g_new0(MPTSASRequest, 1);
+-QTAILQ_INSERT_TAIL(>pending, req, next);
+ req->scsi_io = *scsi_io;
+ req->dev = s;
+
+@@ -1319,8 +1317,6 @@ static void mptsas_scsi_realize(PCIDevice *dev, Error
**errp)
+
+ s->request_bh = qemu_bh_new(mptsas_fetch_requests, s);
+
+-QTAILQ_INIT(>pending);
+-
+ scsi_bus_new(>bus, sizeof(s->bus), >qdev, _scsi_info,
NULL);
+ }
+
+diff --git a/hw/scsi/mptsas.h b/hw/scsi/mptsas.h
+index b85ac1a5fc..c046497db7 100644
+--- a/hw/scsi/mptsas.h
b/hw/scsi/mptsas.h
+@@ -79,7 +79,6 @@ struct MPTSASState {
+ uint16_t reply_frame_size;
+
+ SCSIBus bus;
+-QTAILQ_HEAD(, MPTSASRequest) pending;
+ };
+
+ void mptsas_fix_scsi_io_endianness(MPIMsgSCSIIORequest *req);
+--
+2.30.2
+
diff -Nru
qemu-5.2+dfsg/debian/patches/sdhci/correctly-set-the-controller-status-for-ADMA.patch
qemu-5.2+dfsg/debian/patches/sdhci/correctly-set-the-controller-status-for-ADMA.patch
---
qemu-5.2+dfsg/debian/patches/sdhci/correctly-set-the-controller-status-for-ADMA.patch
1970-01-01 03:00:00.0 +0300
+++
qemu-5.2+dfsg/debian/patches/sdhci/correctly-set-the-controller-sta
Bug#965254: RM: openhackware/0.4.1+git-20140423.c559da7c-4.1
28.07.2020 10:53, Paul Gevers wrote: .. > These request should normally be filed against ftp.debian.org and the > package should be removed from unstable first (and then it's > automatically removed from testing). Is there any reason why you request > the removal from testing or should the bug just be reassigned? Hmm, now I'm confused. Initially I was about to file the bugreport against ftp.d.o, but reportbug, after asking questions, told me I should use release.d.o instead and stopped.. so I did just that.. :) Dunno if I answered the questions wrong or there's an issue in reportbug. After all, RM isn't a very-often-thing to happen, and this is my first RM so I have no prior expirence at all. Given this background, I'm kindly asking for little help on this, is just a reassign enough or should I do something else? reportbug does quite some housekeeping.. Yes it definitely should be removed from unstable, not from testing, testing should follow. Thank you! /mjt
Bug#965254: RM: openhackware/0.4.1+git-20140423.c559da7c-4.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm The package openhackware builds a single binary blob, ppc_rom.bin, which is a bios/firmware for old PowerPC machines. This firmware were used by qemu package (namely, qemu-system-ppc) to emulate PowerPC hardware. However, since version 5.0, support for this old PowerPC machine type has been removed from qemu, so this package is basically useless now. There's no other purpose for this single binary ROM image in the Debian archive. Please remove openhackware package from testing. Thanks, /mjt
Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi!
I've prepared next release of the qemu debian package, with
a few bugfixes, and am asking if it's okay to upload these
changes to unstable (targetting buster). The change includes
3 security fixes which should go anyway, and 2 "other" fixes
which are questionable, hence the pre-approval bugreport/question.
All changes are "easy" ones, and are mostly one-liners and are
easy for review. All bugfixes has been appied upstream too.
Is it okay for the changes to go to buster?
Thanks,
/mjt
diff -Nru qemu-3.1+dfsg/debian/changelog qemu-3.1+dfsg/debian/changelog
--- qemu-3.1+dfsg/debian/changelog 2019-03-27 14:24:06.0 +0300
+++ qemu-3.1+dfsg/debian/changelog 2019-05-27 07:49:25.0 +0300
@@ -1,3 +1,23 @@
+qemu (1:3.1+dfsg-8) unstable; urgency=high
+
+ * sun4u-add-power_mem_read-routine-CVE-2019-5008.patch
+fixes a null-pointer dereference in sparc/sun4u emulated hw
+Closes: #927439, CVE-2019-5008
+ * enable-md-no.patch & enable-md-clear.patch
+mitigation for MDS (Microarchitectural Data Sampling) issues
+Closes: #929067,
+CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091
+ * qxl-check-release-info-object-CVE-2019-12155.patch
+fixes null-pointer deref in qxl cleanup code
+Closes: #929353, CVE-2019-12155
+ * aarch32-exception-return-to-switch-from-hyp-mon.patch
+fixes booting U-Boot in UEFI mode on aarch32
+Closes: #927763
+ * stop qemu-system-common pre-depending on adduser
+ Closes: #929261
+
+ -- Michael Tokarev Mon, 27 May 2019 07:49:25 +0300
+
qemu (1:3.1+dfsg-7) unstable; urgency=high
[ Michael Tokarev ]
diff -Nru qemu-3.1+dfsg/debian/control qemu-3.1+dfsg/debian/control
--- qemu-3.1+dfsg/debian/control2019-03-11 14:35:35.0 +0300
+++ qemu-3.1+dfsg/debian/control2019-05-27 07:49:25.0 +0300
@@ -191,7 +191,6 @@
Package: qemu-system-common
Architecture: amd64 arm arm64 armel armhf i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el
s390x sparc sparc64 x32
Multi-Arch: foreign
-Pre-Depends: adduser
Replaces: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
Breaks: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
Depends: ${misc:Depends}, ${shlibs:Depends},
diff -Nru qemu-3.1+dfsg/debian/control-in qemu-3.1+dfsg/debian/control-in
--- qemu-3.1+dfsg/debian/control-in 2019-03-11 14:19:34.0 +0300
+++ qemu-3.1+dfsg/debian/control-in 2019-05-27 07:49:25.0 +0300
@@ -196,7 +196,6 @@
Package: qemu-system-common
Architecture: amd64 arm arm64 armel armhf i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el
s390x sparc sparc64 x32
Multi-Arch: foreign
-Pre-Depends: adduser
Replaces: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
Breaks: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
Depends: ${misc:Depends}, ${shlibs:Depends},
diff -Nru
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
---
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
1970-01-01 03:00:00.0 +0300
+++
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
2019-05-27 07:46:35.0 +0300
@@ -0,0 +1,56 @@
+From: Alexander Graf
+Date: Mon, 21 Jan 2019 10:23:11 +
+Subject: target/arm: Allow Aarch32 exception return to switch from Mon->Hyp
+Commit-Id: 2d2a4549cc29850aab891495685a7b31f5254b12
+Bug-Debian: http://bugs.debian.org/927763
+
+In U-boot, we switch from S-SVC -> Mon -> Hyp mode when we want to
+enter Hyp mode. The change into Hyp mode is done by doing an
+exception return from Mon. This doesn't work with current QEMU.
+
+The problem is that in bad_mode_switch() we refuse to allow
+the change of mode.
+
+Note that bad_mode_switch() is used to do validation for two situations:
+
+ (1) changes to mode by instructions writing to CPSR.M
+ (ie not exception take/return) -- this corresponds to the
+ Armv8 Arm ARM pseudocode Arch32.WriteModeByInstr
+ (2) changes to mode by exception return
+
+Attempting to enter or leave Hyp mode via case (1) is forbidden in
+v8 and UNPREDICTABLE in v7, and QEMU is correct to disallow it
+there. However, we're already doing that check at the top of the
+bad_mode_switch() function, so if that passes then we should allow
+the case (2) exception return mode changes to switch into Hyp mode.
+
+We want to test whether we're trying to return to the nonexistent
+"secure Hyp" mode, so we need to look at arm_is_secure_below_el3()
+rather than arm_is_secure(), since the latter is always true if
+we'
Bug#926441: unblock: qemu/1:3.1+dfsg-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package qemu
The version currently in -unstable fixes 2 security issues
(CVE-2019-9824 and CVE-2018-20815), patches taken from
upstream, and fixes a mistake in previous version of
one of the binary packages (qemu-guest-agent) - we misplaced
a new config file, putting it to a subdir (/etc/qemu/fsfreeze-hook/
instead of /etc/qemu/fsfreeze-hook), -- this last issue required
some work fixing it and moving the file into proper place. All
various corner cases of this, including when the user modified
that file locally _and_ fixed its location too, where tested and
all works ok. This is Ubuntu bug (LP: #1820291) which slipped to
Debian too.
Here's the debdiff against 1:3.1+dfsg-5 currently in testing:
diff -Nru qemu-3.1+dfsg/debian/changelog qemu-3.1+dfsg/debian/changelog
--- qemu-3.1+dfsg/debian/changelog 2019-03-11 14:30:44.0 +0300
+++ qemu-3.1+dfsg/debian/changelog 2019-03-27 14:24:06.0 +0300
@@ -1,3 +1,26 @@
+qemu (1:3.1+dfsg-7) unstable; urgency=high
+
+ [ Michael Tokarev ]
+ * device_tree-don-t-use-load_image-CVE-2018-20815.patch
+fix heap buffer overflow while loading device tree blob
+(Closes: CVE-2018-20815)
+
+ [ Christian Ehrhardt ]
+ * qemu-guest-agent: fix path of fsfreeze-hook (LP: #1820291)
+ - d/qemu-guest-agent.install: use correct path for fsfreeze-hook
+ - d/qemu-guest-agent.pre{rm|inst}/.postrm: special handling for
+ mv_conffile since the new path is a directory in the old package
+ version which can not be handled by mv_conffile.
+
+ -- Michael Tokarev Wed, 27 Mar 2019 14:24:06 +0300
+
+qemu (1:3.1+dfsg-6) unstable; urgency=high
+
+ * slirp-check-sscanf-result-when-emulating-ident-CVE-2019-9824.patch
+fix information leakage in slirp code (Closes: CVE-2019-9824)
+
+ -- Michael Tokarev Mon, 18 Mar 2019 14:41:51 +0300
+
qemu (1:3.1+dfsg-5) unstable; urgency=high
* i2c-ddc-fix-oob-read-CVE-2019-3812.patch fixes
diff -Nru
qemu-3.1+dfsg/debian/patches/device_tree-don-t-use-load_image-CVE-2018-20815.patch
qemu-3.1+dfsg/debian/patches/device_tree-don-t-use-load_image-CVE-2018-20815.patch
---
qemu-3.1+dfsg/debian/patches/device_tree-don-t-use-load_image-CVE-2018-20815.patch
1970-01-01 03:00:00.0 +0300
+++
qemu-3.1+dfsg/debian/patches/device_tree-don-t-use-load_image-CVE-2018-20815.patch
2019-03-27 14:16:54.0 +0300
@@ -0,0 +1,35 @@
+From: Peter Maydell
+Date: Fri, 14 Dec 2018 13:30:52 +
+Subject: device_tree.c: Don't use load_image() (CVE-2018-20815)
+Commit-Id: da885fe1ee8b4589047484bd7fa05a4905b52b17
+
+The load_image() function is deprecated, as it does not let the
+caller specify how large the buffer to read the file into is.
+Instead use load_image_size().
+
+Signed-off-by: Peter Maydell
+Reviewed-by: Richard Henderson
+Reviewed-by: Stefan Hajnoczi
+Reviewed-by: Michael S. Tsirkin
+Reviewed-by: Eric Blake
+Message-id: 20181130151712.2312-9-peter.mayd...@linaro.org
+---
+ device_tree.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/device_tree.c b/device_tree.c
+index 6d9c9726f66..296278e12ae 100644
+--- a/device_tree.c
b/device_tree.c
+@@ -91,7 +91,7 @@ void *load_device_tree(const char *filename_path, int *sizep)
+ /* First allocate space in qemu for device tree */
+ fdt = g_malloc0(dt_size);
+
+-dt_file_load_size = load_image(filename_path, fdt);
++dt_file_load_size = load_image_size(filename_path, fdt, dt_size);
+ if (dt_file_load_size < 0) {
+ error_report("Unable to open device tree file '%s'",
+ filename_path);
+--
+2.11.0
+
diff -Nru qemu-3.1+dfsg/debian/patches/series
qemu-3.1+dfsg/debian/patches/series
--- qemu-3.1+dfsg/debian/patches/series 2019-03-11 14:30:08.0 +0300
+++ qemu-3.1+dfsg/debian/patches/series 2019-03-27 14:16:54.0 +0300
@@ -7,3 +7,5 @@
scsi-generic-avoid-possible-oob-access-to-r-buf-CVE-2019-6501.patch
slirp-check-data-length-while-emulating-ident-function-CVE-2019-6778.patch
i2c-ddc-fix-oob-read-CVE-2019-3812.patch
+slirp-check-sscanf-result-when-emulating-ident-CVE-2019-9824.patch
+device_tree-don-t-use-load_image-CVE-2018-20815.patch
diff -Nru
qemu-3.1+dfsg/debian/patches/slirp-check-sscanf-result-when-emulating-ident-CVE-2019-9824.patch
qemu-3.1+dfsg/debian/patches/slirp-check-sscanf-result-when-emulating-ident-CVE-2019-9824.patch
---
qemu-3.1+dfsg/debian/patches/slirp-check-sscanf-result-when-emulating-ident-CVE-2019-9824.patch
1970-01-01 03:00:00.0 +0300
+++
qemu-3.1+dfsg/debian/patches/slirp-check-sscanf-result-when-emulating-ident-CVE-2019-9824.patch
2019-03-18 14:41:28.0 +0300
@@ -0,0 +1,49 @@
+From: Samuel Thibault
+Date: Thu, 7 Mar 2019 12:51:34 +0100
+Message-Id: <20190307115143.780-5-samuel.thiba...@ens-lyon.org>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Subject:
Bug#859599: unblock: qemu/1:2.8+dfsg-4
19.04.2017 14:31, Michael Tokarev пишет: > Control: tag -1 - moreinfo > > 18.04.2017 11:06, Niels Thykier wrote: > >>> unblock qemu/1:2.8+dfsg-4 > >> Hi Michael, >> >> Please go ahead with this change set and let us know once it has been >> built on all relevant release architectures in unstable. > > Thank you very much! It wasn't an easy job on your part. > > It's uploaded and built on all release architectures now. One more thing I forgot to mention. Besides the already discussed debdiff there's ONE MORE change I added to the uploaded version, very small, I forgot to mention debian bug# for CVE-2017-7377 fix. Here's the diff between the unblock request and the actual upload (the change is in the changelog, mentioning closing of #859854, and modified patch headers to include the same info): diff -u -r qemu-2.8+dfsg-4_/debian/changelog qemu-2.8+dfsg-4/debian/changelog --- qemu-2.8+dfsg-4_/debian/changelog 2017-04-19 18:35:46.086278674 +0300 +++ qemu-2.8+dfsg-4/debian/changelog2017-04-03 16:28:49.0 +0300 @@ -21,7 +21,7 @@ vmxnet3-fix-memory-corruption-on-vlan-header-stripping-CVE-2017-6058.patch * bump seabios dependency to 1.10.2 due to ahci fix in 2.8.1 * 9pfs-fix-file-descriptor-leak-CVE-2017-7377.patch -Closes: CVE-2017-7377 +(Closes: #859854, CVE-2017-7377) * dma-rc4030-limit-interval-timer-reload-value-CVE-2016-8667.patch Closes: #840950, CVE-2016-8667 * make d/control un-writable to stop users from changing a generated file diff -u -r qemu-2.8+dfsg-4_/debian/patches/9pfs-fix-file-descriptor-leak-CVE-2017-7377.patch qemu-2.8+dfsg-4/debian/patches/9pfs-fix-file-descriptor-leak-CVE-2017-7377.patch --- qemu-2.8+dfsg-4_/debian/patches/9pfs-fix-file-descriptor-leak-CVE-2017-7377.patch 2017-04-19 18:35:46.086278674 +0300 +++ qemu-2.8+dfsg-4/debian/patches/9pfs-fix-file-descriptor-leak-CVE-2017-7377.patch 2017-04-03 16:28:49.0 +0300 @@ -1,8 +1,8 @@ From: Li Qiang <liq...@gmail.com> Date: Mon, 27 Mar 2017 21:13:19 +0200 -Subject: 9pfs: fix file descriptor leak +Subject: 9pfs: fix file descriptor leak (CVE-2017-7377) Commit-Id: d63fb193e71644a073b77ff5ac6f1216f2f6cf6e -Bug-Debian: http://security-tracker.debian.org/tracker/CVE-2017-7377 +Bug-Debian: http://bugs.debian.org/859854 The v9fs_create() and v9fs_lcreate() functions are used to create a file on the backend and to associate it to a fid. The fid shouldn't be already
Bug#859599: unblock: qemu/1:2.8+dfsg-4
Control: tag -1 - moreinfo 18.04.2017 11:06, Niels Thykier wrote: >> unblock qemu/1:2.8+dfsg-4 > Hi Michael, > > Please go ahead with this change set and let us know once it has been > built on all relevant release architectures in unstable. Thank you very much! It wasn't an easy job on your part. It's uploaded and built on all release architectures now. Unfortunately there are a few new security bugs has been discovered, so another upload is on the way, but it will be singnificantly more easy. Thanks! /mjt
Bug#859599: unblock: qemu/1:2.8+dfsg-4
12.04.2017 20:25, Niels Thykier wrote: [] >>> Just to be sure, are you recommending 1:2.8+dfsg-4 or that we go with >>> upstream's 2.8.1 release? >> >> Historically, for some reason I don't remember what, we >> kept the "major" upstream version and source in qemu and >> used just a patch (v2.8.1.patch in this case) pulled from >> upstream (tarball or git difference, which is the same in >> this case). > I don't remember that reason either and no one was able to remind me. :) > > Could I convince you to do a debdiff of the upstream release as an > actual new upstream release (and not just stuff into a big patch wrapped > up with fake version number)? :) I'm not sure what's the reason to update the tarball. Maybe that actually was a reason to do it this way really, -- the changes are small compared with the size of the tarball, and DFSG-ification of it is rather complex. At the same time we already have big number of patches from current upstream stable release, so the version number is better be like this, as it is "based" on 2.8. If there's no strong reason, I'd rather not change or touch the release procedure this late in the release cycle, I did a number of mistakes in DFSG-ification already in the past. I can split the upstream v2.8.1 patch into individual patches if that'll help. This way there won't be much moving in the debdiff (there will be the same amount of patch moving if I'll base it on actual 2.8.1 tarball). Or, provided there's already 2.9 upstream release coming out, just give up on stretch version and focus on backports instead, the same way as we did in jessie (I weren't able to convince the release team to accept a single bugfix release from upstream). Unfortunately upstream does not keep stable series alive, so there wont be any further updates for 2.8 series. Thanks, /mjt
Bug#859599: unblock: qemu/1:2.8+dfsg-4
05.04.2017 20:42, Niels Thykier wrote: > Control: tags -1 moreinfo > > On Wed, 05 Apr 2017 09:35:19 +0300 Michael Tokarev <m...@tls.msk.ru> wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> Please unblock package qemu >> >> Upstream released a new stable/bugfix version which >> includes many changes we already had in debian >> package, but picked up more accurately (especially >> the 9pfs changes), and includes other bugfixes which >> were found since 2.8.0 release. After careful review >> of the changes upstream released I tend to think it >> is better to have whole set than to cherry-pick from >> a cherry-pick. >> >> I'd rather follow upstream here than to roll our own >> selection which no one knows how to deal with :) >> >> [...] >> > > Just to be sure, are you recommending 1:2.8+dfsg-4 or that we go with > upstream's 2.8.1 release? Historically, for some reason I don't remember what, we kept the "major" upstream version and source in qemu and used just a patch (v2.8.1.patch in this case) pulled from upstream (tarball or git difference, which is the same in this case). Note that the version number has just 2 components, and the unblock request is for 2.8+dfsg-4, which includes v2.8.1.patch as a single upstream patch. The bulk of the debdiff (about 90% of it) is due to patch rearrangement, -- all of the upstream patches being removed are actually moved to v2.8.1.patch (with additions). Besides, it just occured to me that I can, at least, make a set of git differences which where already included in current debian release, and which are being added in the proposed v2.8.1.patch. If that helps, I'll do this. Thanks! /mjt
Bug#859417: unblock: seabios/1.10.2-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package seabios
This package is only used by qemu system emulator on x86
(qemu-system-x86 package). Upstream qemu just released
a new stable/bugfix release of current qemu code, of
version 2.8.1, which I intend to upload to be shipped
in stretch. This release, among other things, includes
updated seabios version 1.10.2 (the one I'm currently
asking to unblock).
Primary reason for this version requiriment is due to
a bugfix in qemu which triggered a bug in seabios which
is fixed in this release. It is the ahci changes, needed
for proper guest reboot with fixed qemu.
However, there are other changes in seabios - especially
the fw_cfg changes - which might look somewhat larger than
it would be good. These changes are specific to a small
area (fw_cfg interface is how qemu iteracts with seabios),
and intend to fix another, while rare to hit, bug, -
memory corruption due to lost memory pointers after guest
resume from S3 state. Rare because it's very rare to put
a guest to sleep.
I can, ofcourse, backport just the single ahci change -
5 new lines of code in src/hw/ahci.c, below in the
debdiff. If the release team chooses that it's better
way I'll do that. But I don't really want to diviege
from upstream for too much - history shows that this
leads to difficult to diagnose issues which no one can
help with, because upstream behavour is different.
Here's the git shortlog between upstream 1.10.1 and 1.10.2:
Ben Warren (5):
QEMU DMA: Add DMA write capability
romfile-loader: Switch to using named structs
QEMU fw_cfg: Add command to write back address of file
QEMU fw_cfg: Add functions for accessing files by key
QEMU fw_cfg: Write fw_cfg back on S3 resume
Kevin O'Connor (1):
ps2port: Disable keyboard/mouse prior to resetting ps2 controller
Ladi Prosek (1):
ahci: Set upper 32-bit registers to zero
Paul Menzel (1):
vgasrc: Increase debug level
Unblock request for qemu follows shortly.
Thank you!
/mjt
unblock seabios/1.10.2-1
diff -Nru seabios-1.10.1/debian/changelog seabios-1.10.2/debian/changelog
--- seabios-1.10.1/debian/changelog 2016-12-26 23:43:43.0 +0300
+++ seabios-1.10.2/debian/changelog 2017-04-03 13:51:52.0 +0300
@@ -1,3 +1,12 @@
+seabios (1.10.2-1) unstable; urgency=medium
+
+ * new upstream stable/bugfix release,
+required for qemu 2.8.1+ due to ahci changes,
+plus fixes for guest resume from S3
+and ps/2 keyboard/mouse handling
+
+ -- Michael Tokarev <m...@tls.msk.ru> Mon, 03 Apr 2017 13:47:29 +0300
+
seabios (1.10.1-1) unstable; urgency=medium
* new upstream release
diff -Nru seabios-1.10.1/src/fw/paravirt.c seabios-1.10.2/src/fw/paravirt.c
--- seabios-1.10.1/src/fw/paravirt.c2016-11-21 18:56:36.0 +0300
+++ seabios-1.10.2/src/fw/paravirt.c2017-02-24 17:01:20.0 +0300
@@ -253,6 +253,20 @@
}
static void
+qemu_cfg_write(void *buf, int len)
+{
+if (len == 0) {
+return;
+}
+
+if (qemu_cfg_dma_enabled()) {
+qemu_cfg_dma_transfer(buf, len, QEMU_CFG_DMA_CTL_WRITE);
+} else {
+warn_internalerror();
+}
+}
+
+static void
qemu_cfg_skip(int len)
{
if (len == 0) {
@@ -280,6 +294,18 @@
}
}
+static void
+qemu_cfg_write_entry(void *buf, int e, int len)
+{
+if (qemu_cfg_dma_enabled()) {
+u32 control = (e << 16) | QEMU_CFG_DMA_CTL_SELECT
+| QEMU_CFG_DMA_CTL_WRITE;
+qemu_cfg_dma_transfer(buf, len, control);
+} else {
+warn_internalerror();
+}
+}
+
struct qemu_romfile_s {
struct romfile_s file;
int select, skip;
@@ -303,6 +329,36 @@
return file->size;
}
+// Bare-bones function for writing a file knowing only its unique
+// identifying key (select)
+int
+qemu_cfg_write_file_simple(void *src, u16 key, u32 offset, u32 len)
+{
+if (offset == 0) {
+/* Do it in one transfer */
+qemu_cfg_write_entry(src, key, len);
+} else {
+qemu_cfg_select(key);
+qemu_cfg_skip(offset);
+qemu_cfg_write(src, len);
+}
+return len;
+}
+
+int
+qemu_cfg_write_file(void *src, struct romfile_s *file, u32 offset, u32 len)
+{
+if ((offset + len) > file->size)
+return -1;
+
+if (!qemu_cfg_dma_enabled() || (file->copy != qemu_cfg_read_file)) {
+warn_internalerror();
+return -1;
+}
+return qemu_cfg_write_file_simple(src, qemu_get_romfile_key(file),
+ offset, len);
+}
+
static void
qemu_romfile_add(char *name, int select, int skip, int size)
{
@@ -321,6 +377,18 @@
}
u16
+qemu_get_romfile_key(struct romfile_s *file)
+{
+struct qemu_romfile_s *qfile;
+if (file->copy != qemu_cfg_read_file) {
+warn_internalerror();
+return 0;
+}
+qfile = container_of(file, struct qemu_ro
Bug#856721: unblock: libcacard/1:2.5.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libcacard
It includes a security fix - #856501, CVE-2017-6414,
and another bugfix pulled from upstream.
unblock libcacard/1:2.5.0-3
diff -Nru libcacard-2.5.0/debian/changelog libcacard-2.5.0/debian/changelog
--- libcacard-2.5.0/debian/changelog2015-11-07 13:03:01.0 +0300
+++ libcacard-2.5.0/debian/changelog2017-03-04 11:57:45.0 +0300
@@ -1,3 +1,11 @@
+libcacard (1:2.5.0-3) unstable; urgency=high
+
+ * smartcard-fix-memory-leak-in-vcard_apdu_new-CVE-2017-6414.patch
+Closes: #856501, CVE-2017-6414
+ * dont-fail-if-caller-didn-t-pick-previous-response.patch
+
+ -- Michael Tokarev <m...@tls.msk.ru> Sat, 04 Mar 2017 11:57:23 +0300
+
libcacard (1:2.5.0-2) unstable; urgency=medium
* add remove-requires.private.patch to remove Requires.private
diff -Nru
libcacard-2.5.0/debian/patches/dont-fail-if-caller-didn-t-pick-previous-response.patch
libcacard-2.5.0/debian/patches/dont-fail-if-caller-didn-t-pick-previous-response.patch
---
libcacard-2.5.0/debian/patches/dont-fail-if-caller-didn-t-pick-previous-response.patch
1970-01-01 03:00:00.0 +0300
+++
libcacard-2.5.0/debian/patches/dont-fail-if-caller-didn-t-pick-previous-response.patch
2017-03-04 11:57:07.0 +0300
@@ -0,0 +1,47 @@
+From: Jakub Jelen <jje...@redhat.com>
+Date: Fri, 12 Aug 2016 11:31:37 +0200
+Subject: Do not fail, if the caller didn't pick up response from previous call
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+Commit-Id: ad591057c301d3120c3f7e5a5826342c8bf523bc
+
+During our testing of a new CAC driver in OpenSC, with this library, we
+encountered a problem with |libcacard| failing and the driver returning
+only a fraction of the requested objects.
+
+The problem is that the Emulator wants to return the data (properly
+signalized by 61 (RESPONSE BYTES) in SW1), but this is ignored for some
+reason in some of our calls from OpenSC. The Emulator should not fail
+hard for the next independent request, rather silently drop the buffer
+and serve the ongoing APDU request (I would left for consideration to
+somehow log such problem).
+
+Patch was successfully tested on Fedora 24 host and solves our problem
+(though we worked around the problem already in the driver too).
+
+Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com>
+---
+ src/card_7816.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/src/card_7816.c b/src/card_7816.c
+index 8b12689..b598ef9 100644
+--- a/src/card_7816.c
b/src/card_7816.c
+@@ -732,11 +732,9 @@ vcard_process_apdu(VCard *card, VCardAPDU *apdu,
VCardResponse **response)
+ }
+ buffer_response = vcard_get_buffer_response(card);
+ if (buffer_response && apdu->a_ins != VCARD7816_INS_GET_RESPONSE) {
+-/* clear out buffer_response, return an error */
++/* clear out buffer_response, do not return an error */
+ vcard_set_buffer_response(card, NULL);
+ vcard_buffer_response_delete(buffer_response);
+-*response = vcard_make_response(VCARD7816_STATUS_EXC_ERROR);
+-return VCARD_DONE;
+ }
+
+ status = vcard_process_applet_apdu(card, apdu, response);
+--
+2.1.4
+
diff -Nru libcacard-2.5.0/debian/patches/series
libcacard-2.5.0/debian/patches/series
--- libcacard-2.5.0/debian/patches/series 2015-11-07 12:50:06.0
+0300
+++ libcacard-2.5.0/debian/patches/series 2017-03-04 11:57:07.0
+0300
@@ -1 +1,3 @@
remove-requires.private.patch
+smartcard-fix-memory-leak-in-vcard_apdu_new-CVE-2017-6414.patch
+dont-fail-if-caller-didn-t-pick-previous-response.patch
diff -Nru
libcacard-2.5.0/debian/patches/smartcard-fix-memory-leak-in-vcard_apdu_new-CVE-2017-6414.patch
libcacard-2.5.0/debian/patches/smartcard-fix-memory-leak-in-vcard_apdu_new-CVE-2017-6414.patch
---
libcacard-2.5.0/debian/patches/smartcard-fix-memory-leak-in-vcard_apdu_new-CVE-2017-6414.patch
1970-01-01 03:00:00.0 +0300
+++
libcacard-2.5.0/debian/patches/smartcard-fix-memory-leak-in-vcard_apdu_new-CVE-2017-6414.patch
2017-03-04 11:56:50.0 +0300
@@ -0,0 +1,40 @@
+From: Li Qiang <liq...@gmail.com>
+Date: Tue, 21 Feb 2017 22:34:20 -0800
+Subject: smartcard: fix memory leak in vcard_apdu_new
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+Commit-Id: 9113dc6a303604a2d9812ac70c17d076ef11886c
+Bug-Debian: http://bugs.debian.org/856501
+
+In the error path, 'new_apdu->a_data' is not freed.
+This can be triggered by the guest continuely.
+
+Signed-off-by: Li Qiang <liqiang...@360.cn>
+Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com>
+---
+ src/card_7816.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/card_7816.c b/src/card_7816.c
+index b598ef9
Bug#856591: unblock: qemu/1:2.8+dfsg-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package qemu There's a large pile of security bugs fixed in this release, all fixes comes from upstream. Plus a few other non-security bugs, some more serious, some less, but all of them are annoying enough and does not allow usage of qemu in certain environments or for certain tasks. Again, everything comes from upstream. Not every bugfix has corresponding bug in Debian BTS. Plus a few very small fixes here and there - for example, ubuntu changes which are _not_, in any way, change debian packaging, only ubuntu part of the control-in file. This is in order for us to easily work together during stretch life cycle. I especially picked only the changes which are not changing Debian parts, to simplify review/unblock. The bulk of the changes (the debdiff is quite large) comes from one patch, which is a fix for CVE-2016-9602, #853006, which is a 9pfs symlink attack issue. The patch is a combination of 28 patches from upstream fold into one file, with the diffstat: hw/9pfs/9p-local.c | 1023 ++- hw/9pfs/9p-local.h | 20 + hw/9pfs/9p-posix-acl.c | 44 +- hw/9pfs/9p-util.c | 69 hw/9pfs/9p-util.h | 54 +++ hw/9pfs/9p-xattr-user.c | 24 +- hw/9pfs/9p-xattr.c | 166 +++- hw/9pfs/9p-xattr.h | 87 +--- hw/9pfs/Makefile.objs |2 +- 9 files changed, 893 insertions(+), 596 deletions(-) create mode 100644 hw/9pfs/9p-local.h create mode 100644 hw/9pfs/9p-util.c create mode 100644 hw/9pfs/9p-util.h This is because the _architecture_ of 9pfs needed to be changed in order to fix the issue. There are other issues similar to this one pending in 9pfs, but that's it for now. I'm sorry for this large changeset this late in the release cycle, but here we go - it is 99.9% bugs... I can't do anything with these except patching :) Thanks, /mjt unblock qemu/1:2.8+dfsg-3 diff -Nru qemu-2.8+dfsg/debian/changelog qemu-2.8+dfsg/debian/changelog --- qemu-2.8+dfsg/debian/changelog 2017-01-23 14:06:54.0 +0300 +++ qemu-2.8+dfsg/debian/changelog 2017-03-01 12:32:26.0 +0300 @@ -1,3 +1,63 @@ +qemu (1:2.8+dfsg-3) unstable; urgency=high + + * urgency high due to security fixes + + [ Michael Tokarev ] + * serial-fix-memory-leak-in-serial-exit-CVE-2017-5579.patch +Closes: #853002, CVE-2017-5579 + * cirrus-ignore-source-pitch-as-needed-in-blit_is_unsafe.patch +(needed for the next patch, CVE-2017-2620 fix) + * cirrus-add-blit_is_unsafe-to-cirrus_bitblt_cputovideo-CVE-2017-2620.patch +Closes: #855791, CVE-2017-2620 + * nbd_client-fix-drop_sync-CVE-2017-2630.diff +Closes: #855227, CVE-2017-2630 + * sd-sdhci-check-transfer-mode-register-in-multi-block-CVE-2017-5987.patch +Closes: #855159, CVE-2017-5987 + * vmxnet3-fix-memory-corruption-on-vlan-header-stripping-CVE-2017-6058.patch +Closes: #855616, CVE-2017-6058 + * 3 CVE fixes from upstream for #853996: +sd-sdhci-check-data-length-during-dma_memory_read-CVE-2017-5667.patch +megasas-fix-guest-triggered-memory-leak-CVE-2017-5856.patch +virtio-gpu-fix-resource-leak-in-virgl_cmd_resource-CVE-2017-5857.patch +Closes: #853996, CVE-2017-5667, CVE-2017-5856, CVE-2017-5857 + * usb-ccid-check-ccid-apdu-length-CVE-2017-5898.patch +Closes: #854729, CVE-2017-5898 + * virtio-crypto-fix-possible-integer-and-heap-overflow-CVE-2017-5931.patch +Closes: #854730, CVE-2017-5931 + * xhci-apply-limits-to-loops-CVE-2017-5973.patch +Closes: #855611, CVE-2017-5973 + * net-imx-limit-buffer-descriptor-count-CVE-2016-7907.patch +Closes: #839986, CVE-2016-7907 + * cirrus-fix-oob-access-issue-CVE-2017-2615.patch +Closes: #854731, CVE-2017-2615 + * 9pfs-symlink-attack-fixes-CVE-2016-9602.patch +Closes: #853006 + * vnc-do-not-disconnect-on-EAGAIN.patch +Closes: #854032 + * xhci-fix-event-queue-IRQ-handling.patch (win7 xhci issue fix) + * xhci-only-free-completed-transfers.patch +Closes: #855659 + * char-fix-ctrl-a-b-not-working.patch +Closes: https://bugs.launchpad.net/bugs/1654137 + * char-drop-data-written-to-a-disconnected-pty.patch +Closes: https://bugs.launchpad.net/bugs/1667033 + * s390x-use-qemu-cpu-model-in-user-mode.patch +Closes: #854893 + * d/control is autogenerated, add comment + * check if debootstrap is available in qemu-debootstrap +Closes: #846497 + + [ Christian Ehrhardt ] + * (ubuntu) no more skip enable libiscsi (now in main) + * (ubuntu) Disable glusterfs (Universe dependency) + * (ubuntu) have qemu-system-arm suggest: qemu-efi; +this should be a stronger relationship, but qemu-efi is still +in universe right now. + * (ubuntu) change dependencies for fix of wrong acl for newly +created device node on ubuntu + + -- Michael Tokarev <m...@tls.msk.ru> Tue, 28 Feb 2017 11:40:18 +0300 + qemu (1:2.8+dfsg-2) unstable; u
Bug#852417: unblock: qemu/1:2.8+dfsg-2
After some thoughts, I think this should be pushed to testing faster. Because the features I enabled which are currently in testing are just plain buggy, there are multiple security bugs in virtio-3d display (which is being disabled in sid), and because with just 2 weeks of this being in testing, it will come to a big surprize for users if it hits stretch and there will be as much complaints about new dependencies as I'm receiving now. In short, we need 1:2.8+dfsg-2 in stretch, and the faster it will be there, the better, because we'll at least have some chances (including bpo version) to see what else could be missing/broken and fix that. I already prepared bpo version which is waiting this version to hit testing. Also there are a few more security fixes being accumulated, and also a few non-security probs being worked on, which should be in stretch, -- especially probs with migration from older qemu. Maintaining 1:2.8+dfsg-1 (with gtk and 3d) in stretch will be difficult. I understand this is my fault to enable large features this close to the release, hence I'm trying to fix that before it is too late. I waited for upstream 2.8 version in a hope there will be modular display support so it'll be possible to make graphics packages/dependencies optional, but these patches weren't accepted. Please consider shortening the waiting period for this version. Thank you! /mjt
Bug#852417: unblock: qemu/1:2.8+dfsg-2
nd too large, +bringing too much graphics stuff for headless servers, +will re-think this for stretch+1. +sdl1 back: Closes: #851509 +virtio-3d bugs: Closes: #849798, #852119 + * mention closing of #769983 (multi-threaded linux-user) by 2.7 + * mention closing of #842455, CVE-2016-9101 by 2.8 + * audio-ac97-add-exit-function-CVE-2017-5525.patch (Closes: #852021) + * audio-es1370-add-exit-function-CVE-2017-5526.patch (Closes: #851910) + * watchdog-6300esb-add-exit-function-CVE-2016-10155.patch (Closes: #852232) + + -- Michael Tokarev <m...@tls.msk.ru> Mon, 23 Jan 2017 14:06:54 +0300 + qemu (1:2.8+dfsg-1) unstable; urgency=medium * new upstream release @@ -26,6 +51,7 @@ Closes: #847496, CVE-2016-9913 CVE-2016-9914 CVE-2016-9915 CVE-2016-9916 Closes: #847960, CVE-2016-9921 CVE-2016-9922 Closes: #847957, CVE-2016-9923 + Closes: #842455, CVE-2016-9101 (git2634ab7fe29b3f75d0865b719caf8f310d634aae) Closes: #819755, #833162 Hopefully closes: #844361 * remove unicore32 linux-user target, removed upstream @@ -72,6 +98,7 @@ * New upstream release, 2.7 (Closes: #748043, #839292) Closes: #838850, CVE-2016-7161 Closes: #473240 (qcow encryption support has been removed) +Closes: #769983 (multi-threaded linux-user) * removed patches which went upstream, refreshed use-data-path.patch * renamed remaining patches to include CVE#s and added Bug-Debian headers * added Depends on lsb-base to qemu-guest-agent (Closes: #840740) diff -Nru qemu-2.8+dfsg/debian/control qemu-2.8+dfsg/debian/control --- qemu-2.8+dfsg/debian/control2016-12-28 15:08:25.0 +0300 +++ qemu-2.8+dfsg/debian/control2017-01-23 13:34:27.0 +0300 @@ -18,8 +18,8 @@ acpica-tools, # --enable-linux-aio linux-* libaio-dev [linux-any], -# --audio-drv-list=pa,alsa,oss linux-* -# --audio-drv-list=pa,oss kfreebsd-* +# --audio-drv-list=pa,alsa,sdl,oss linux-* +# --audio-drv-list=pa,oss,sdl kfreebsd-* libasound2-dev [linux-any], # for virtfs # --enable-attr @@ -39,16 +39,12 @@ libfdt-dev, # --enable-gnutls gnutls-dev, -# gtk display (see also sdl display) -# --enable-gtk --with-gtkabi=3.0 --enable-vte - libgtk-3-dev, libvte-2.91-dev, -# opengl for sdl2 and gtk3 -# --enable-opengl -# libegl1-mesa-dev is here b/c libepoxy-dev includes header from it - libdrm-dev, libgbm-dev, libepoxy-dev, libx11-dev, libegl1-mesa-dev, -# virglrenderer: virtio gpu support for guest -# --enable-virglrenderer - libvirglrenderer-dev, +# gtk ui is almost the same as sdl but adds bloat +# --disable-gtk +## --with-gtkabi=2.0 +# libgtk2.0-dev, libvte-dev (>> 0.18.0~), +# vte is used together with gtk +# --disable-vte # libiscsi is debian-only since ubuntu/libiscsi is in universe # --enable-libiscsi libiscsi-dev (>> 1.9.0~), @@ -70,10 +66,9 @@ glusterfs-common, # --enable-vnc-sasl libsasl2-dev, -# sdl display (see also gtk display) # note: libsdl2-dev is in universe on ubuntu -# --disable-sdl --with-sdlabi=1.2 -# libsdl1.2-dev (>> 1.2.1), +# --enable-sdl --with-sdlabi=1.2 + libsdl1.2-dev (>> 1.2.1), # --enable-seccomp linux-amd64|linux-i386 libseccomp-dev (>> 2.1.0) [linux-amd64 linux-i386], # --enable-spice linux-amd64|linux-i386 @@ -89,6 +84,8 @@ # vde is debian-only since ubuntu/vde2 is in universe # --enable-vde libvdeplug-dev, +# needed for sdl + libx11-dev, # --enable-xen linux-amd64|linux-i386 libxen-dev [linux-amd64 linux-i386], # XXX need to check minimum linux-headers requiriment diff -Nru qemu-2.8+dfsg/debian/control-in qemu-2.8+dfsg/debian/control-in --- qemu-2.8+dfsg/debian/control-in 2016-12-28 15:08:13.0 +0300 +++ qemu-2.8+dfsg/debian/control-in 2017-01-23 13:04:57.0 +0300 @@ -20,8 +20,8 @@ acpica-tools, # --enable-linux-aio linux-* libaio-dev [linux-any], -# --audio-drv-list=pa,alsa,oss linux-* -# --audio-drv-list=pa,oss kfreebsd-* +# --audio-drv-list=pa,alsa,sdl,oss linux-* +# --audio-drv-list=pa,oss,sdl kfreebsd-* libasound2-dev [linux-any], # for virtfs # --enable-attr @@ -41,16 +41,12 @@ libfdt-dev, # --enable-gnutls gnutls-dev, -# gtk display (see also sdl display) -# --enable-gtk --with-gtkabi=3.0 --enable-vte - libgtk-3-dev, libvte-2.91-dev, -# opengl for sdl2 and gtk3 -# --enable-opengl -# libegl1-mesa-dev is here b/c libepoxy-dev includes header from it - libdrm-dev, libgbm-dev, libepoxy-dev, libx11-dev, libegl1-mesa-dev, -# virglrenderer: virtio gpu support for guest -# --enable-virglrenderer - libvirglrenderer-dev, +# gtk ui is almost the same as sdl but adds bloat +# --disable-gtk +## --with-gtkabi=2.0 +# libgtk2.0-dev, libvte-dev (>> 0.18.0~), +# vte is used together with gtk +# --disable-vte # libiscsi is debian-only since ubuntu/libiscsi is in universe :debian:# --enable-libiscsi :debian: libiscsi-dev (>> 1.9.0~), @@ -72,10 +68,9 @@ glusterfs-common, # --enable-vnc-sasl lib
Bug#798969: jessie-pu: package qemu/1:2.1+dfsg-12+deb8u5
28.06.2016 12:17, Julien Cristau wrote: > Control: tag -1 moreinfo > > On Sat, Feb 20, 2016 at 18:19:49 +, Julien Cristau wrote: Hmm. I haven't seen this email back in February. Basically I gave up waiting for almost a year for this, I don't even remember anymore what was in version 2.1. Most likely it isn't worth pushing anymore, since freeze of stretch is on horizon. Thanks, /mjt
Bug#798969: jessie-pu: package qemu/1:2.1+dfsg-12+deb8u4
Control: retitle -1 jessie-pu: package qemu/1:2.1+dfsg-12+deb8u5 14.09.2015 18:04, Michael Tokarev wrote: > Package: release.debian.org > Severity: normal > Tags: jessie > User: release.debian@packages.debian.org > Usertags: pu > > I'd like to update qemu in jessie to the next upstream stable point release. [...] > The attached debdiff is made on the debian-jessie-proposed branch of qemu > alioth git tree, > > http://anonscm.debian.org/cgit/pkg-qemu/qemu.git/log/?h=debian-jessie-proposed > and is made on top of not-yet-available in public archives jessie-security > version, 2.1+dfsg-12+deb8u3, which should be available shortly. Due to > the amount of security bugs discovered in qemu recently, I'm not sure this > version will be right at the time of the next jessie point release, so > the changes might need to be rebased on top of further security changes. Since yesterday I updated qemu again fixing 2 new vulns found meanwhile, the "next" version number becomes 1:2.1+dfsg-12+deb8u5 not ...deb8u4, with the same changes as before. I updated the mentioned above git branch. Thank you for your time! /mjt
Re: bastardizing packages or stepping down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 06.03.2015 15:02, Sam Hartman wrote: [] So, you're involving the TC because you're hoping to better understand why your unblock was not approved? How are you hoping the TC can help? Here are some options I see: * Some folks on the TC are fairly good at release engineering and have been involved in this either in Debian, for other projects or for other distributions. We could look over the situation and try to help you understand why someone might decide not to approve those unblocks. Since we weren't the one acting on the request we can give you an understanding of why someone might think that way, but not why they did. * Alternatively you could be asking for help engaging with the release team and Cyril to explain the actual reasoning involved. Or perhaps you're asking for something else. I asked for understanding mostly. But as I wrote at the very beginning of my first email, I don't have much hope. This email has been sent to 3 places: d-i team who rejected busybox, d-release team and TC, so maybe at least one party can find something to say or do. What I see here are 3 possible solutions to this problem. I guess I ordered them right, starting with most unlikely but best, and ending in most likely but worst. a) allow current busybox to migrate from unstable to testing. This is what I asked when filing an unblock-udeb request initially in #771208, which was filed before jessie freeze. This is what will make everyone happy, I think, including current people involved with the package because there wont be any reason anymore to do the same work twice (including making another crippled release for jessie with unneeded-for-debian security bugfix but without needed- for-jessie other fixes), there wont be any need anymore to bastardize the package. Disadvantages are none, to my view anyway, except that in this case, people who rejected the unblock request will have to agree it was a mistake. That, I think, is one of important points here, because Cyril is one of them (if not the only one), and he's an important person for the project, and no one want to make him unhappy. But since this hasn't happened so far, and even my main questions went unanswered this far in the release cycle, I've no hope for this. b) someone -- be it TC, or D-I team, or the Release team, explain to me why the changes hasn't been accepted. I asked this several times, but always got the same answer: the changes are fixing jessie-ignore bug and introduce uneeded-for-jessie changes for things which are now history already (glibc bug). To which I answered initially in the very first unblock request: the jessie-ignore thing was only because that bug was _difficult_ to fix in time for jessie (but I did that and I was in time), so not to introduce an RC bug which is unlikely to be fixed, and that these changes are _needed_ for jessie, not anything past jessie, exactly because it isn't yet history for jessie, as buildd story demonstrates, and because fixed glibc hasn't even been released upstream at the time -- if not for jessie users, this helps derived distributions and in other situations, like backporting and whatnot. But even more: all this, which I voluntary explained, is hardly relevant for the unblock-UDEB request, because none of the changes in question EVER affect D-I in any way whatsoever. So I don't really understand why an unblock-UDEB request has been denied in a background that the changes aren't needed for jessie, BEFORE jessie has been frozen? And another question which I asked several times is, even if the changes aren't exactly necessary, does it HURT any? Does the new stuff break anything? If not, again, why to work more when it's that simple to do less and make everyone happy? So, basically, it'd be good to understand why. Maybe TC can help, maybe the release team can, or maybe d-i team, I dunno. c) lacking a) and b), I don't have any choice but to step down. The reason is plain and simple. I don't understand why, see b), why even such small, easy to review, carefully selected, tested and needed changes can't be accepted, and why my questions goes on unanswered while freeze progresses, and why it is better to do more work _instead_ of the same work which I already did. Since I don't understand why my work isn't needed for debian, and instead, debian prefers to do MORE work, I see this as I'm not helping debian but instead disturbing its work. So I can't continue, I don't want to make life for others harder. So I _have_ to go. I can't even change the way I do things to make it easier for debian, because I don't understand what is going on so don't know the direction to change myself. So, if c) is the only choice I have, I request that my name be removed from all packages which, at leaat, produces udebs (these are busybox and mdadm so far) on the next upload, and I'm stopping maintaining these packages, because I don't
Re: bastardizing packages or stepping down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 05.03.2015 15:08, Sam Hartman wrote: Adam == Adam D Barratt a...@adam-barratt.org.uk writes: Adam Hi, Making no comment on the remainder of the mail: Adam On 2015-03-05 10:38, Michael Tokarev wrote: And since I can't do my work, I'm stepping down from being busybox maintainer, and am kindly asking the release team to remove my name from debian/control file in busybox, so that people don't blame me for things I can't do. Adam I don't believe it would be appropriate for us to do so. We Adam have no control or say in who maintains packages (beyond that Adam available to any other DD or interested contributor). michael, I'd like to ask if I'm hearing you correctly. So, what I'm hearing is very strong frustration. You had hoped that you would have the power to produce a package that you'd be happy being responsible for. However you don't believe that you have that power; you're saying that changes you consider essential to creating a busybox you're comfortable being responsible for are rejected. Am I hearing you correctly? Well. It is not about being happy or being powerful. It is about at least understanding the reasons why we should take bad and have more work instead of taking good and have peace. This is the main source of frustration, and this is the main question which went unanswered so far. The main changes I've made (this build-using thing plus a build-time glibc check) are _only_ needed for jessie, since after jessie this whole single issue will really be history, while for jessie it isn't history yet, like a story with buildds demonstrating. Another source of frustration is the fact that all the changes in question does not break things, it does not hurt anyone, and especially does not affect the D-I in any way whatsoever, but are being rejected on the D-I side. Another frustration comes because much more intrusive but much less needed changes are being happily accepted after the deadlines, even if here, I missed the deadlines because of factors not under my control, but trying my best. So, the main point is that apparently it is better to do more work and make everyone frustrated than to just accept already (hopefully well-) done work and continue peacfully. I don't see the reason WHY (hence I Cc'd ctte). It is not about power. Adam, let's assume for the moment I've got that right. I'm trying to connect with the frustration I'd feel if I were told that I didn't even have the power to distance myself from something I couldn't in good conscious claim to support. I hope that there's some way that michael can approach stepping away from the package in jessie if he wants to. If what you're saying is that his proposed mechanism for doing that is the wrong one, would you be willing to help him out and suggest a mechanism you believe to be more appropriate? (Perhaps you'd approve an ublock for an upload that simply changed maintainer to debian-qa?) There's no need to change maintainer, it is debian-boot (d-i team) and it remains like that, at least in busybox. In busybox my name is in Uploaders: field only. For mdadm, on the other hand, even if it is set as team-maintained, the sole maintainer is me, so that'd be appropriate to change maintainer to debian-qa. Both packages affects d-i, and for the reasons I already described, I can't do that myself, since I'll face the same unblock request process from the D-I team. More, I don't really want to keep my name as the author of last changelog entry in this case. If what you're saying is that you see no mechanism for him to step away from a package he no longer feels he can maintain because he and the release team disagree with the desired contents of that package in Jessie, then I respectfully ask you to reconsider that position. That sort of thing would likely drive me away from the entire project, not just one package. Actually this was my first reaction, but I thought I'd wait for a bit and just point out a possible defect in debian, possible request for discussion. Micahel, one final question to you. Are you firmly committed to the path of stepping away from busybox maintenance, or would you be willing to re-evaluate that decision after we see what comes of your request for understanding? I don't believe there's any other alternative actually. I dunno, it is difficult to think. I wanted to understand the WHY first, because clearly, as I tried to describe, I don't see, at all, why this is done. I don't really feel powerless, that's not the problem, after all no single person should have absolute powers (including Cyril, no matter how respectful I or anyone else is for him due to his work). After all I always have absolute power to continue maintaining the package locally, and that's what I definitely will do, because I depend on it and I don't want it to become in that really bad shape it was before me. But so
bastardizing packages or stepping down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I didn't really want to write this email, but it looks I now have to, even if, for reasons which whill be shown below, don't expect any good news from this. Trying to make the story short. For quite some time we had a bug in glibc in jessie which resulted in statically-linked applications malfunctioning when using any of nsswitch-related functionality (eg gethostbyname() etc), #757941. This glibc bug resulted in bugreport about busybox package -- #769190 (#757941 has been filed against busybox too, initially). The problem was that many busybox applets didn't work in static build. That bug was rather fun, because even if it is fixed in glibc, your package depends on the fixed version to be present on all buildds, or else the resulting binary will be buggy again. This is exactly what happened with #769190 -- to work around initial #757941 in bb, it has been bin-NMUed and rebuilt with a fixed glibc. But once I uploaded a next release of busybox to the archive, it was rebuilt using older, unfixed glibc, and the original problem reappeared. For added fun, since glibc package names are architecture-dependent, it is rather difficult to express all necessary build-depends correctly. Having all this, and having in mind that at least initially you don't know if this particular build of your package is affected or not, another bug has been filed against busybox -- #768876, requesting that busybox-static have a Built-Using field to allow seeing which glibc version it was built against, at least. This bugreport (#768876, built-using) is of serious severity and is tagged with jessie-ignore, not because it is irrelevant for jessie but because it is _difficult_ to fix and the package already received manual treatment to be rebuilt against a fixed glibc version. Understanding the actual severity of this problem, I tried to fix this before jessie, because I know it is important to do so (see below). I had fever at that time, and fixing it turned out rather difficult and required several iterations to finally get it right. I especially tried to fix that as fast as possible despite the fever, because it was near jessie freeze so, even if I was absolutely sure it wont be a problem to accept these changes to jessie, I didn't want to add more work for already busy enough release team to review and accept the changes. But at that time things didn't go right, because it turned out many buildds are still having old version of glibc and the resulting binary is buggy again. So I tried to add a versioned build-dependency on glibc, which too took several iterations because glibc package names are arch-specific and because I wanted to keep ability of busybox to be compiled against old version of glibc (eg for backports), both of which finally worked. Also I added a built-time test which builds a tiny static program which does getpwnam(root), to verify before build that the build environment is able to produce static executables at all. At least this should ensure we wont have known-broken binary after a successful build. All 3 changes -- the generation of Built-Using field, the build-time test to ensure static linking works, and addition of extra build-depends field -- are small and self-contained in d/rules (or d/control) file, easy to review or remove when it all really becomes history. Meanwhile I fixed another, unrelated, buglet in the package which annoyed me enough during these multiple uploads -- I changed d/rules so it does not produce arch-all package (busybox-syslogd) when asked only to produce arch-specific packages. This was a bit larger change in d/rules but is a well tested in other packages. Neither of these changes, and this is important point, -- neither of these changes affects the resulting binary packages on a system where glibc is fixed. The changes adds one extra field (Built-Using) to busybox-static package, ensures the build environment is able to produce a static binary and introduces a versioned build-depends on libc which allows us to build the package either with fixed glibc version or with glibc which does not have that bug yet. After all this it turned out that several buildds were still having issues with the new build-depends, so the package were attempted to build multiple times - some buildds had unfixed glibc so build-depends were impossible to satisfy. More, it turned out hurd-i386 build env is not able to produce a working statically-linked getpwnam(root) binary at all. So I pinged buildd maintainers asking to update glibc, I also contacted hurd people asking what to do (hurd is not a release arch but it is in buildd and if I can fix hurd before freeze so I wont need to add more work for the release team that'd be nice). But time was, ofcourse, ticking. (Btw, I received no replies to my inquires about release-goal buildds, however after numerous attempts buildd network finally was able to produce working busybox
Re: Re: Last hints for d-i, upload tomorrow
From aa57d3cc600de9d9ff3e318dc4beed33cfcfd9f3 Mon Sep 17 00:00:00 2001 From: Cyril Brulebois k...@debian.org Date: Thu, 11 Dec 2014 11:29:36 +0100 Subject: [PATCH] Document the jessie branching. --- debian/changelog | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index e78827c..7c18a73 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,7 +1,13 @@ -busybox (1:1.22.0-10) UNRELEASED; urgency=low +busybox (1:1.22.0-14+deb8u1) UNRELEASED; urgency=low + [ Michael Tokarev ] * lzop-add-overflow-check-CVE-2014-4607.patch (Closes: #768945) + [ Cyril Brulebois ] + * Branch jessie from master to only include the security fix; other changes +between 1:1.22.0-9 and 1:1.22.0-14 are invasive and not needed for jessie. +Cheat a bit with the revision number to avoid bumping the epoch. So you're continuing to ruin my (hard in this case) work, spreading lies (invasive) and confirming you're against others working on debian. That's fine with me too. I can continue maintain local copy of busybox the same way as I did before I took over its maintenance, because in debian it was in *awful* state and mostly unusable. (For the record: all the recent changes I made in busybox is needed for jessie, I especially and carefully selected the minimal set. We had it in broken state for too long.) Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54c71d86.8000...@msgid.tls.msk.ru
Re: Last hints for d-i, upload tomorrow
27.01.2015 08:59, Christian PERRIER пишет: (CC'ed in case you guys subscribed to -release. I am subscribed so please no CC) Quoting Michael Tokarev (m...@tls.msk.ru): So you're continuing to ruin my (hard in this case) work, spreading lies (invasive) and confirming you're against others working on debian. Given that Cyril is THE person that currently makes Debian Installer to happen, I would kindly ask you to refrain on such claims, please. Yes, I understand full well Cyril's role in the D-I, and I apprecate it and I'm grateful for that. Really. However in this very case, I told exactly what I think and feel. And I stand on my words, because I think it is true and I'm not quite ready to lie yet. Maybe the same can be expressed differently and worded better. Also, the changes in question has nothing to do with the D-I itself, these are minor changes in packaging and build process which result in the same binary as used by d-i previously. So judjing here with D-I hat on is not exactly wise, because the changes don't affect D-I. You may have disagreements (which I don't share) but please keep the tone low and polite. We have a good release manager for D-I and, believe me, this is hard to find and you probably don't imagine the hard work he has for every release. For people who follow Debian closely, they probably noticed that Cyril obviously went through hard times recently and I felt some kind of demotivation in his mails, sometimes. I would prefer that nobody pushes harder in that direction. Agreed 100%. So, well, your work on busybox is very highly appreciated and valued. Yes, it was in a bad state and you definitely revived it. We're all deeply thankful for that. That's fine with me too. I can continue maintain local copy of busybox the same way as I did before I took over its maintenance, because in debian it was in *awful* state and mostly unusable. (For the record: all the recent changes I made in busybox is needed for jessie, I especially and carefully selected the minimal set. We had it in broken state for too long.) If these changes are needed for jessie, please follow the Debian release managers guidelines : point which release critical bugs are fixed by these fixes, and aruge with the Release Team about unblocks by providing patches (or just copy/pasting them from git) so that one release manager can make his|her own decision, with the help of Cyril. That's the exact procedure I followed, after missing the deadline by a few days because I was ill myself, and after a long delay dealing with the static link issue in glibc (#769190). The RC bug has been filed exactly due to that issue with static linking (#768876), so, being ill myself, I rushed to fix it to ensure we wont have the same problem again somewhere else during jessie lifecycle, thinking it is really essential to fix it for jessie. Yes, #768876 is tagged jessie-ignore, but that was just because Aurelien didn't want to add a hard (as it turned out) bug before freeze. And yes it took me several iterations to finally fix it for real. Now, the only questionable difference between testing and what I think must be in testing is this adding of Built-Using field for busybox-static (which does not affect d-i in any way as I mentioned before), and minor changes to the build procedure to stop building arch-all package when only arch-specific build is requested - again, does not affect d-i. While the build changes (arch-all vs arch-specific) aren't exactly essential (it was trivial to fix, I was just tired stumbling upon dpkg warning when rebuilding the package while trying to fix #768876), #768876 itself is essential, well-tested finally, and simple. Yet these (packaging-only) changes are being rejected, and I yet to see a reason for that. And while doing that, maintainer (me) is being pissed off and discoraged from even thinking to work on this package again, *and* much more work is being done to cherry-pick the really-really-necessary changes to fix stupid bugs which are unimportant (because busybox isn't used in debian in environments where these bugs can be triggered). This is unfair and even stupid thing to do, because it is a way to have more work to undo the _necessary_ things and to redo them again in favour of things which actually aren't important. Why do more when we already have enough and the work is already done?? If that doesn't happen, then you can't hardly complain. Yes that may be a PITA work to do because this is indeed really a mandatory step. This indeed explains why important changes are better done *before* freezes than during freezes. And, yes, sometimes, the timing is not so good, given that all upstreams have their own schedule that doesn't fit Debian's. But we have to live with that. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775164: unblock: mdadm/3.3.2-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mdadm
It contains a single noticeable change which fixes a bug which is important
for upgrades from wheezy -- #770883 (https://bugs.debian.org/770883).
The original problem is that udev in wheezy does not understand $devnode
variable in its .rules file, so new mdadm will not work with old udev,
and mdadm does not declare versioned dependency on udev. Instead of
introducing a versioned dependency (with larger breakage potential), I
decided to fix this by using a variant of .rules file which will work
equally well with both old and new versions of udev.
There are 2 other changes in the package - adding forgotten bug numbers
into debian/changelog to the points/versions when these bugs has been
fixed.
The package has been in testing in this form for a long time already.
When unblocking mdadm, it should be unblocked for the debian installer
too since it produces udeb too.
Thanks,
/mjt
unblock mdadm/3.3.2-5
unblock-udev mdadm/3.3.2-5
diff -Nru mdadm-3.3.2/debian/changelog mdadm-3.3.2/debian/changelog
--- mdadm-3.3.2/debian/changelog2014-12-05 17:29:22.0 +0300
+++ mdadm-3.3.2/debian/changelog2014-12-20 11:48:54.0 +0300
@@ -1,8 +1,20 @@
+mdadm (3.3.2-5) unstable; urgency=medium
+
+ * use-tempnode-not-devnode.patch: change udev rules file to use
+$tempnode which works both on wheezy and jessie udev, instead
+of $devnode which only works in jessie. At this stage it is
+better to make rules file compatible with old version instead
+of adding versioned dependency. Should be removed for jessie+1.
+(Closes: #770883)
+ * fix Closes: list in previous entry (Closes: #771852)
+
+ -- Michael Tokarev m...@tls.msk.ru Sat, 20 Dec 2014 11:48:44 +0300
+
mdadm (3.3.2-4) unstable; urgency=medium
* really remove /var/lib/mdadm in postinst, fixing a brown-paper bag
bug in previous upload (I fixed it earlier but forgot to commit it
-before 3.3.2-3 release). (Closes: #764036 #771852)
+before 3.3.2-3 release). (Closes: #764036, #771852)
* mention closing of #588965 #599352 #694513 by 3.3-1
-- Michael Tokarev m...@tls.msk.ru Fri, 05 Dec 2014 17:29:22 +0300
@@ -84,7 +96,7 @@
mdadm (3.3-1) unstable; urgency=low
[ Michael Tokarev ]
- * new upstream 3.3 release (Closes: #718896 #588965 #599352 #694513)
+ * new upstream 3.3 release (Closes: #718896, #588965, #599352, #694513)
See ANNOUNCE-3.3 for details.
Patches:
- refreshed debian-conffile-location.diff
diff -Nru mdadm-3.3.2/debian/patches/series mdadm-3.3.2/debian/patches/series
--- mdadm-3.3.2/debian/patches/series 2014-11-14 19:16:41.0 +0300
+++ mdadm-3.3.2/debian/patches/series 2014-12-05 18:59:42.0 +0300
@@ -2,6 +2,7 @@
debian-no-Werror.diff
sha1-includes.diff
use-external-blkid.diff
+use-tempnode-not-devnode.patch
build-sys-no-check_rundir.patch
rebuildmap-strip-local-host-name-from-device-name.patch
readlink-path.patch
diff -Nru mdadm-3.3.2/debian/patches/use-tempnode-not-devnode.patch
mdadm-3.3.2/debian/patches/use-tempnode-not-devnode.patch
--- mdadm-3.3.2/debian/patches/use-tempnode-not-devnode.patch 1970-01-01
03:00:00.0 +0300
+++ mdadm-3.3.2/debian/patches/use-tempnode-not-devnode.patch 2014-12-05
19:10:18.0 +0300
@@ -0,0 +1,31 @@
+From: Michael Tokarev m...@tls.msk.ru
+Subject: use tempnode not devnode in udev rules
+Bug-Debian: http://bugs.debian.org/770883
+Forwarded: no
+
+udev in wheezy does not understand $devnode construct
+in rules file, while upstream uses it in mdadm rules
+files. udev in jessie has $devnode and it also supports
+old $tempnode which is the way it worked in wheezy and
+before, even if $tempnode in jessie's udev is not documented.
+So on jessie, both $tempnode and $devnode works fine, while
+in wheezy, only $tempnode works.
+
+Use $tempnode instead of $devnode. Since mdadm is important
+enough for system functionality and easily can break system
+by making it unbootable, and this is the only incompatibility
+between wheezy's and jessie's udev wrt mdadm, it is better than
+having a versioned dependency on udev.
+
+This patch is debian-specific and should be dropped for jessie+1.
+
+--- a/udev-md-raid-arrays.rules
b/udev-md-raid-arrays.rules
+@@ -20 +20 @@
+-IMPORT{program}=BINDIR/mdadm --detail --export $devnode
++IMPORT{program}=BINDIR/mdadm --detail --export $tempnode
+--- a/udev-md-raid-assembly.rules
b/udev-md-raid-assembly.rules
+@@ -30 +30 @@
+-ACTION==add|change, IMPORT{program}=BINDIR/mdadm --incremental --export
$devnode --offroot ${DEVLINKS}
++ACTION==add|change, IMPORT{program}=BINDIR/mdadm --incremental --export
$tempnode --offroot ${DEVLINKS}
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org
Bug#773859: unblock: edk2/0~20131112.2590861a-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package edk2
Current package in testing has 2 FTBFS bugs due to testing switched to
gcc4.9 and edk2 in testing not supporting it. Version in unstable contains
two fixes for these 2 FTBFS bugs, plus a clarification of why it is not
part of debian main archive (it is in non-free). The package in unstable
builds and works fine.
Overall, edk2, being a UEFI firmware, is a leaf package -- it builds only
ovmf binary package which is optional, to be used with qemu-system to emulate
an UEFI system. Nothing else depends on it, so unblock should not affect
anything. On the other hand, if it is to be removed, qemu will need to be
modified to remove ovmf from the list of recommends.
unblock edk2/0~20131112.2590861a-3
Thanks,
/mjt
Debdiff (please note: some files are with MS-DOS (CR/LF) line endings):
diff -Nru edk2-0~20131112.2590861a/debian/changelog
edk2-0~20131112.2590861a/debian/changelog
--- edk2-0~20131112.2590861a/debian/changelog 2014-02-25 22:49:07.0
+0400
+++ edk2-0~20131112.2590861a/debian/changelog 2014-12-19 10:23:06.0
+0300
@@ -1,3 +1,17 @@
+edk2 (0~20131112.2590861a-3) unstable; urgency=medium
+
+ [ Steve Langasek ]
+ * debian/copyright: include a Disclaimer field to document clearly why
+this package is not in main. Closes: #742589.
+
+ [ Michael Tokarev ]
+ * apply gcc-4.9-align.patch kindly provided by dann frazier to fix ftbfs
+with gcc-4.9 (Closes: #771114)
+ * apply upstream fix-undefined-behavior-in-vfrcompiler.patch, kindly provided
+by dann frazier, to fix another ftbfs (Closes: #773492)
+
+ -- Michael Tokarev m...@tls.msk.ru Fri, 19 Dec 2014 10:16:14 +0300
+
edk2 (0~20131112.2590861a-2) unstable; urgency=medium
* debian/ovmf.links: create a OVMF.fd link for qemu
diff -Nru edk2-0~20131112.2590861a/debian/copyright
edk2-0~20131112.2590861a/debian/copyright
--- edk2-0~20131112.2590861a/debian/copyright 2014-02-25 22:49:07.0
+0400
+++ edk2-0~20131112.2590861a/debian/copyright 2014-12-19 09:52:21.0
+0300
@@ -4,6 +4,10 @@
and https://efi-shell.svn.sourceforge.net/svnroot/efi-shell/trunk/Shell,
with .efi binary files removed from the source at package generation time.
See get-orig-source in debian/rules for details.
+Disclaimer: This package is not part of Debian because it does not meet
+ Debian's license standards due to the licensing on the Intel FAT driver
+ (see License: Intel-Fat-Driver below). With this exception, all other
+ code in this package meets the Debian Free Software Guidelines.
Files: *
Copyright: 1999-2013, Intel Corporation
diff -Nru
edk2-0~20131112.2590861a/debian/patches/fix-undefined-behavior-in-vfrcompiler.patch
edk2-0~20131112.2590861a/debian/patches/fix-undefined-behavior-in-vfrcompiler.patch
---
edk2-0~20131112.2590861a/debian/patches/fix-undefined-behavior-in-vfrcompiler.patch
1970-01-01 03:00:00.0 +0300
+++
edk2-0~20131112.2590861a/debian/patches/fix-undefined-behavior-in-vfrcompiler.patch
2014-12-19 10:22:48.0 +0300
@@ -0,0 +1,35 @@
+Description: Fix undefined behavior in VfrCompiler.
+Origin: http://sourceforge.net/p/edk2-buildtools/code/2667/
+Bug-Debian: http://bugs.debian.org/773492
+Author: Reza Jelveh reza.jel...@tuhh.de
+Reviewed-by: Eric Dong eric.d...@intel.com
+Last-Update: 2014-12-18
+Applied-Upstream: commit:r2667
+
+Index: edk2-0~20131112.2590861a/BaseTools/Source/C/VfrCompile/VfrCompiler.cpp
+===
+--- edk2-0~20131112.2590861a.orig/BaseTools/Source/C/VfrCompile/VfrCompiler.cpp
edk2-0~20131112.2590861a/BaseTools/Source/C/VfrCompile/VfrCompiler.cpp
+@@ -372,6 +372,8 @@ CVfrCompiler::CVfrCompiler (
+ mPreProcessCmd = (CHAR8 *) PREPROCESSOR_COMMAND;
+ mPreProcessOpt = (CHAR8 *) PREPROCESSOR_OPTIONS;
+
++ SET_RUN_STATUS (STATUS_STARTED);
++
+ OptionInitialization(Argc, Argv);
+
+ if ((IS_RUN_STATUS(STATUS_FAILED)) || (IS_RUN_STATUS(STATUS_DEAD))) {
+Index: edk2-0~20131112.2590861a/BaseTools/Source/C/VfrCompile/VfrCompiler.h
+===
+--- edk2-0~20131112.2590861a.orig/BaseTools/Source/C/VfrCompile/VfrCompiler.h
edk2-0~20131112.2590861a/BaseTools/Source/C/VfrCompile/VfrCompiler.h
+@@ -61,7 +61,8 @@ typedef struct {
+ } OPTIONS;
+
+ typedef enum {
+- STATUS_INITIALIZED = 1,
++ STATUS_STARTED = 0,
++ STATUS_INITIALIZED,
+ STATUS_PREPROCESSED,
+ STATUS_COMPILEED,
+ STATUS_GENBINARY,
diff -Nru edk2-0~20131112.2590861a/debian/patches/gcc-4.9-align.patch
edk2-0~20131112.2590861a/debian/patches/gcc-4.9-align.patch
--- edk2-0~20131112.2590861a/debian/patches/gcc-4.9-align.patch 1970-01-01
03:00:00.0 +0300
+++ edk2-0~20131112.2590861a/debian/patches/gcc-4.9-align.patch 2014-12-19
10:21:22.0 +0300
@@ -0,0 +1,30 @@
+Description: Update linker script for gcc-4.9 which
Bug#771208: unblock: busybox/1:1.22.0-14
11.12.2014 10:52, Ivo De Decker wrote: [] As the libc issue with the static binary seems to be fixed in the libc version in both jessie and sid, the only remaining issue is the missing build-using, which can wait till after jessie. Could you do a new upload with only the security fix? I'll leave this and other maintenance of busybox to others. I especially selected only the changes which I think are necessary for jessie. But since we obviously have different criteria for this, and for some other things too, I'd rather not mess up with the package further. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548967db.4050...@msgid.tls.msk.ru
Bug#771208: unblock: busybox/1:1.22.0-14
11.12.2014 13:02, Cyril Brulebois wrote: Hi, Hello can you please still push your master branch and tags to the git repository? Last commit there points to debian/1.22.0-9 which is 5 revisions old, at least if I'm reading cgit and gitk properly. Oh yeah. I'm sorry about that. Pushed now. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54896d0a.70...@msgid.tls.msk.ru
Bug#772832: unblock: qemu/2.1+dfsg-11
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please consider unblocking package qemu.
The current release in sid fixes one serious bug (#772127) which has been
introduced during jessie development and made more serious by recent changes
in qemu packaging. Basically, many qemu-system emulators didn't work due
to missing vgabios (part of seabios) and pxe boot roms (ipxe-qemu package).
The fix includes re-working a (debian-specific) patch which introduces a
build-time search PATH instead of a single directory as used by qemu (since
upstream qemu source includes firmware blobs from various projects in a
single directory, this is enough for upstream qemu; but in Debian we have
these blobs in different packages), and also adds Recommends entries to
several qemu-system packages.
I didn't want to use Depends because at least in theory, these systems
can function without the firmware, and also because adding extra Depends
at this stage is a bit risky.
Meanwhile, unfortunately, I mistakenly uploaded a new upstream version of
qemu (2.2), which aimed at experimental, to unstable. So I had to re-
upload 2.1 version again, bumping the epoch number, to cancel 2.2 upload.
So in addition to fixing that single bug, there's also epoch number
increment.
There's no other changes.
Debdiff between version in jessie/testing and current sid is below.
unblock qemu/2.1+dfsg-11
Thanks,
/mjt
diff -Nru qemu-2.1+dfsg/debian/changelog qemu-2.1+dfsg/debian/changelog
--- qemu-2.1+dfsg/debian/changelog 2014-12-04 16:57:09.0 +0300
+++ qemu-2.1+dfsg/debian/changelog 2014-12-10 00:53:52.0 +0300
@@ -1,3 +1,26 @@
+qemu (1:2.1+dfsg-11) unstable; urgency=medium
+
+ * bump epoch and reupload to cancel 2.2+dfsg-1exp upload
+mistakenly done to unstable. No other changes.
+
+ -- Michael Tokarev m...@tls.msk.ru Wed, 10 Dec 2014 00:52:28 +0300
+
+qemu (2.1+dfsg-10) unstable; urgency=medium
+
+ * make (debian-specific) x86 data path (with seabios and ipxe
+in it) non-x86-specific, since other arches use firmware
+files too (Closes: #772127)
+ * add seabios to Recommends to qemu-system-misc, qemu-system-mips,
+qemu-system-ppc and qemu-system-sparc packages, because these
+packages contains emulators using vgabios which is part of
+seabios package (#772127).
+ * add ipxe-qemu to Recommends to qemu-system-misc, qemu-system-arm,
+qemu-system-mips, qemu-system-ppc, qemu-system-sparc packages,
+because these packages contains emulators using network boot
+roms (#772127), in a similar way.
+
+ -- Michael Tokarev m...@tls.msk.ru Tue, 09 Dec 2014 13:47:36 +0300
+
qemu (2.1+dfsg-9) unstable; urgency=high
* apply upstream patches for CVE-2014-8106
diff -Nru qemu-2.1+dfsg/debian/control qemu-2.1+dfsg/debian/control
--- qemu-2.1+dfsg/debian/control2014-12-04 16:53:29.0 +0300
+++ qemu-2.1+dfsg/debian/control2014-12-10 00:54:52.0 +0300
@@ -190,7 +190,10 @@
Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64
x32
Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}, qemu-system-common (
2.0.0+dfsg-7~)
-Recommends: qemu-utils
+Recommends: qemu-utils,
+# alpha uses vgabios
+# alpha m68k sh4 uses bootroms
+ seabios, ipxe-qemu (= 1.0.0+git-2013.c3d1e78-1~)
Suggests: samba, vde2
Provides: ${sysprovides:misc}
Breaks: qemu-system ( 1.3.0+dfsg-5)
@@ -215,7 +218,9 @@
Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64
x32
Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}, qemu-system-common (
2.0.0+dfsg-7~)
-Recommends: qemu-utils
+Recommends: qemu-utils,
+# aarch64 arm uses bootroms
+ ipxe-qemu (= 1.0.0+git-2013.c3d1e78-1~)
Suggests: samba, vde2
Provides: ${sysprovides:arm}
Breaks: qemu-system ( 1.3.0+dfsg-5),
@@ -237,7 +242,9 @@
Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64
x32
Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}, qemu-system-common (
2.0.0+dfsg-7~)
-Recommends: qemu-utils
+Recommends: qemu-utils,
+# all mips targets uses vgabios and bootroms
+ seabios, ipxe-qemu (= 1.0.0+git-2013.c3d1e78-1~)
Suggests: samba, vde2
Provides: ${sysprovides:mips}
Breaks: qemu-system ( 1.3.0+dfsg-5)
@@ -263,7 +270,9 @@
# ubuntu can't Depend on openbios-ppc and openhackware as they're in universe
openbios-ppc (= 1.1+svn1229), openhackware
Suggests: samba, vde2,
-Recommends: qemu-utils
+Recommends: qemu-utils,
+# ppc targets use vgabios-stdvga and bootroms
+ seabios, ipxe-qemu (= 1.0.0+git-2013.c3d1e78-1~)
Provides: ${sysprovides:ppc}
Breaks: qemu-system ( 1.3.0+dfsg-5),
Replaces: qemu-system ( 1.3.0+dfsg-5),
@@ -286,7
Bug#772832: unblock: qemu/2.1+dfsg-11
11.12.2014 17:23, Michael Tokarev wrote: ... The fix includes re-working a (debian-specific) patch which introduces a build-time search PATH instead of a single directory as used by qemu (since upstream qemu source includes firmware blobs from various projects in a single directory, this is enough for upstream qemu; but in Debian we have these blobs in different packages), and also adds Recommends entries to several qemu-system packages. In addition to regular debdiff, here's a link to the changes in the mentioned debian-specific patch: http://anonscm.debian.org/cgit/pkg-qemu/qemu.git/commit/?id=e0b29d29cad40046ac460c544a63f7d65517d75f since I renamed the patch file to reflect reality, debdiff includes removal of old patch file and addition of another. The link above shows differece between the two files, -- these differences makes it clear that the changes aren't that large compared with whole file removal+addition. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5489b817.5060...@msgid.tls.msk.ru
Bug#772071: unblock: qemu/2.1+dfsg-9
Package: release.debian.org
Severity: important
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package qemu.
The current package in unstable, 2.1+dfsg-9, is one release
ahead of previously unblocked version, 2.1+dfsg-8, see #771771 .
This newly uploaded release fixes a newly discovered security
issue in qemu-system, which is CVE-2014-8106 #772025 -- the
bug is serious enough to warrant a quick fix. Stable (wheezy)
already received the same fix, and I'm waiting for unstable
to migrate to testing to fix this in bpo70 too, which is already
uploaded early today.
Since 2.1+dfsg-8 has already been unblocked, I'm attaching debdiff
against that one, not against the version in testing. The debdiff
contains 2 added patches from upstream plus the corresponding debian
files changes. If this is not enough please indicate as such, I'll
include complete debdiff.
Setting severity to important because the security problem is really
serious and needs urgent action, especially for bpo70.
Thank you!
/mjt
unblock qemu/2.1+dfsg-9
diff -Nru qemu-2.1+dfsg/debian/changelog qemu-2.1+dfsg/debian/changelog
--- qemu-2.1+dfsg/debian/changelog 2014-11-27 18:32:45.0 +0300
+++ qemu-2.1+dfsg/debian/changelog 2014-12-04 16:57:09.0 +0300
@@ -1,3 +1,11 @@
+qemu (2.1+dfsg-9) unstable; urgency=high
+
+ * apply upstream patches for CVE-2014-8106
+(cirrus: insufficient blit region checks)
+(Closes: #772025 CVE-2014-8106)
+
+ -- Michael Tokarev m...@tls.msk.ru Thu, 04 Dec 2014 00:10:43 +0300
+
qemu (2.1+dfsg-8) unstable; urgency=low
[ Michael Tokarev ]
diff -Nru
qemu-2.1+dfsg/debian/patches/cirrus-don-t-overflow-CirrusVGAState-cirrus_bltbuf-CVE-2014-8106.patch
qemu-2.1+dfsg/debian/patches/cirrus-don-t-overflow-CirrusVGAState-cirrus_bltbuf-CVE-2014-8106.patch
---
qemu-2.1+dfsg/debian/patches/cirrus-don-t-overflow-CirrusVGAState-cirrus_bltbuf-CVE-2014-8106.patch
1970-01-01 03:00:00.0 +0300
+++
qemu-2.1+dfsg/debian/patches/cirrus-don-t-overflow-CirrusVGAState-cirrus_bltbuf-CVE-2014-8106.patch
2014-12-04 16:53:22.0 +0300
@@ -0,0 +1,31 @@
+From bf25983345ca44aec3dd92c57142be45452bd38a Mon Sep 17 00:00:00 2001
+From: Gerd Hoffmann kra...@redhat.com
+Date: Wed, 19 Nov 2014 13:27:28 +0100
+Subject: cirrus: don't overflow CirrusVGAState-cirrus_bltbuf
+Bug-Debian: http://bugs.debian.org/772025
+
+This is CVE-2014-8106.
+
+Signed-off-by: Gerd Hoffmann kra...@redhat.com
+---
+ hw/display/cirrus_vga.c |4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c
+index d54fb06..2725264 100644
+--- a/hw/display/cirrus_vga.c
b/hw/display/cirrus_vga.c
+@@ -293,6 +293,10 @@ static bool blit_is_unsafe(struct CirrusVGAState *s)
+ assert(s-cirrus_blt_width 0);
+ assert(s-cirrus_blt_height 0);
+
++if (s-cirrus_blt_width CIRRUS_BLTBUFSIZE) {
++return true;
++}
++
+ if (blit_region_is_unsafe(s, s-cirrus_blt_dstpitch,
+ s-cirrus_blt_dstaddr s-cirrus_addr_mask)) {
+ return true;
+--
+1.7.10.4
+
diff -Nru
qemu-2.1+dfsg/debian/patches/cirrus-fix-blit-region-check-CVE-2014-8106.patch
qemu-2.1+dfsg/debian/patches/cirrus-fix-blit-region-check-CVE-2014-8106.patch
---
qemu-2.1+dfsg/debian/patches/cirrus-fix-blit-region-check-CVE-2014-8106.patch
1970-01-01 03:00:00.0 +0300
+++
qemu-2.1+dfsg/debian/patches/cirrus-fix-blit-region-check-CVE-2014-8106.patch
2014-12-04 16:53:22.0 +0300
@@ -0,0 +1,126 @@
+From d3532a0db02296e687711b8cdc7791924efccea0 Mon Sep 17 00:00:00 2001
+From: Gerd Hoffmann kra...@redhat.com
+Date: Wed, 19 Nov 2014 11:37:42 +0100
+Subject: cirrus: fix blit region check
+Bug-Debian: http://bugs.debian.org/772025
+
+Issues:
+ * Doesn't check pitches correctly in case it is negative.
+ * Doesn't check width at all.
+
+Turn macro into functions while being at it, also factor out the check
+for one region which we then can simply call twice for src + dst.
+
+This is CVE-2014-8106.
+
+Reported-by: Paolo Bonzini pbonz...@redhat.com
+Signed-off-by: Gerd Hoffmann kra...@redhat.com
+Reviewed-by: Paolo Bonzini pbonz...@redhat.com
+---
+ hw/display/cirrus_vga.c | 61 ++-
+ 1 file changed, 44 insertions(+), 17 deletions(-)
+
+diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c
+index 8a5b76c..d54fb06 100644
+--- a/hw/display/cirrus_vga.c
b/hw/display/cirrus_vga.c
+@@ -173,20 +173,6 @@
+
+ #define CIRRUS_PNPMMIO_SIZE 0x1000
+
+-#define BLTUNSAFE(s) \
+-( \
+-( /* check dst is within bounds */ \
+-(s)-cirrus_blt_height * ABS((s)-cirrus_blt_dstpitch) \
+-+ ((s)-cirrus_blt_dstaddr (s)-cirrus_addr_mask) \
+-(s)-vga.vram_size \
+-) || \
+-( /* check src is within bounds */ \
+-(s)-cirrus_blt_height * ABS((s)-cirrus_blt_srcpitch) \
+-+ ((s
Bug#769129: What's next?
03.12.2014 21:37, Jonathan Wiltshire wrote: Control: tag -1 moreinfo On Sun, Nov 30, 2014 at 03:42:56PM +0100, Diederik de Haas wrote: What needs to be done further so that busybox transitions into testing? -- GPG: 0x138E41915C7EFED6 Well, sid now has 1:1.22.0-14, so the best thing is probably for the maintainer to talk us through the sum total debdiff. Since #769129 [1] has been closed, I opened #771208 [2] with the new version, and that one has complete debdiff for -14. This has been done at Nov-27. [1] https://bugs.debian.org/769129 [2] https://bugs.debian.org/771208 Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f5e37.2080...@msgid.tls.msk.ru
Bug#771771: unblock: qemu/2.1+dfsg-8
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package qemu.
The package accumulated a large list of important and security
fixes - either from upstream/stable branch or with debian
packaging.
Here's the annotated changelog (complete debdiff is below):
qemu (2.1+dfsg-8) unstable; urgency=low
[ Michael Tokarev ]
* add Built-Using control field for qemu-user-static package:
take contents of qemu-user ${shlibs:Depends} and transform it
into list of source packages with versions. (Closes: #768926)
This is a difficult one. Since qemu is building static executables
(in qemu-user-static package), it is essential to know which libs
were used to build it, to understand if the given build has security
issues present in these libraries.
After experimenting with this field in busybox package, it was easy
to add it to qemu.
However, we have a prob between x86 buildds and DAK, and this prob is
happening for several days already. The prob is that on x86 buildds,
libc is old for some reason, and when the package is build successfully
it is being rejected by DAK who thinks the package has been built
using non-existing version of glibc, because that old version has
already been removed from the archive. I plan to ping the builddd
team about this, the only thing needed is to update x86 buildds to
include a more recent libc.
* run remove-alternatives in qemu-system.postinst (the metapkg)
too, not only in qemu-system-XX.postinst, to handle upgrades
from wheezy (Closes: #768244)
This is handling an upgrade-from-wheezy case with left-over alternatives.
I merely forgot about this case when doing things initially. Alternatives
should be removed completely, they're not used.
* several fixes for debian/qemu-user.1 manpage. It needs more
work, but at least some easy and obvious errors are fixed now.
(Closes: #763841)
Trivial changes for qemu-user manpage.
* migration-fix-parameter-validation-on-ram-load.patch from upstream
(Closes: #769451 CVE-2014-7840)
Another security fix from upstream, from a familiar theme (loading of
migration stream).
* fix x86_64 binfmt mask to allow more values in ELF_OSABI field
(byte7). Current gcc/binfmt sometimes produces binaries with
this field set to 3 (OSABI_GNU) not 0 (OSABI_SYSV) as used to be.
Set mask to 0xfb not 0xff here, to allow 0 (traditional SYSV),
1 (HPUX), 2 (NETBSD) or 3 (GNU). This lets 2 more types than
necessary, but qemu will reject wrong types so no harm is done.
Some other binfmts ignore this field completely (with mask=0).
Maybe some day we'll have 2 different binfmt registrations for
the 2 different ABI types. (Closes: #763043)
This one is a questionable change as it registers qemu for more
executable formats than necessary. However the same is already
done with other architectures (in some cases we don't check this
ELF_OSABI byte at all, by masking it). And it actually fixes a
wide problem, in particular, almost all statically-linked x86
binaries produced by current toolchain hasn't been recognized
by the binfmt registration before this change.
* usb-host-fix-usb_host_speed_compat-tyops.patch -- fix host usb devices
attach, without this patch many USB devices does not work
There's no debian bug# for this (again, I can add one if necessary).
Trivial change from upstream fixing typos in usb device assignment
code, it resulted in essentially most usb devices being unable to
be used inside guest. The problem is important enough to warrant
a bugfix.
* qdev-monitor-fix-segmentation-fault-on-qdev_device_h.patch - trivial
patch from upstream to fix segfault in -device foo,help (Closes: #770880)
Another trivial change from upstream closes a segfault. Not hugely
important issue by itself but having in mind simplicity of fix and
the fact that users will see this prob quite often I think it is worth
to fix it too.
[ Aurelien Jarno ]
* Add tcg-mips-fix-store-softmmu-slow-path.patch from upstream to fix
TCG support on mips/mipsel hosts (Closes: #769470).
An important case -- in previous versions of qemu in debian, mips
emulation was essentially non-functional. This change from upstream
fixes it.
[ Ian Campbell ]
* Backport patch to fix unmapping of persistent grants in the Xen qdisk
backend (Closes: #770468).
This is a xen-specific problem (qemu is used by xen too), basically, xen
support was broken before this patch.
-- Michael Tokarev m...@tls.msk.ru Thu, 27 Nov 2014 18:32:45 +0300
Please consider unblocking this package.
Thank you!
/mjt
unblock qemu/2.1+dfsg-8
diff -Nru qemu-2.1+dfsg/debian/binfmt-update-in qemu-2.1+dfsg/debian/binfmt-update-in
--- qemu-2.1+dfsg/debian/binfmt-update-in 2014-10-06 19:43:35.0 +0400
+++ qemu-2.1+dfsg/debian/binfmt-update-in 2014-11-14 14:45:53.0 +0300
@@ -45,7 +45,11 @@
sparc64_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00
Bug#771208: unblock: busybox/1:1.22.0-14
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package busybox. Last upload has one security bugfix (CVE-2014-4607, #768945), the fix is from upstream stable branch, fixing an integer overflow in lzo decompressor; it adds a Built-Using control field for busybox-static variant (#768926), and also arranges build system to only produce binary or indep .debs (or both), depending on the d/rules target (binary-all vs binary-indep vs binary) -- this is a long-standing lintian bug which I overlooked previously. The busybox-static fix turned out to be a fun case, because I needed a way to build-conflict on a non-broken libc (because the original prob is in libc due to #754813), and that turned out to be a not-so- trivial task, which resulted in several iterations. Meanwhile I discovered that current glibc is not able to produce working stati- cally linked executables on hurd which uses nss functions -- statically linked executable on hurd just segfaults. So now, after a fix for #768926, busybox package does not build on hurd, while previously it silently produced failing busybox-static. Hurd people are working on the fix. (The Built-Using field generation is a bit fun here: I asked on IRC how people identify which libc is in use, and got various somewhat- incpmplete replies (the prob is that on different arches, libc package is named differently). So I invented my own way for busybox, because this package allows me to do that -- I took the contents of $shlibs:Depends variable for the dynamically-linked version, and transformed it into a list of sources required for Built-Using using dpkg-query.) There's no code changes except the lzo decompression bugfix, only packaging changes. Since busybox is used in d-i too, I kindly request for a udeb-unblock too. Previously I submitted an unblock request for busybox 1.22.0-10, as #769129, but that turned out to be a bit preliminary because of the fun with libc versioned build dependency iterations. Thank you! /mjt unblock busybox/1:1.22.0-14 diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog --- busybox-1.22.0/debian/changelog 2014-09-30 08:50:20.0 +0400 +++ busybox-1.22.0/debian/changelog 2014-11-14 12:53:24.0 +0300 @@ -1,3 +1,46 @@ +busybox (1:1.22.0-14) medium; urgency=low + + * one more attempt to fix the glibc build-depend for #769190, now +using versioned build-dependency on libc-dev-bin which is named +this way on all architectures (unlike libc6|libc6.1|libc0.1|libc0.3) + + -- Michael Tokarev m...@tls.msk.ru Fri, 14 Nov 2014 12:52:18 +0300 + +busybox (1:1.22.0-13) unstable; urgency=medium + + * really fix #769190 the hard way, by build-conflicting with all +arch-specific names of libc with version 2.19-12 (Closes: #769190) + * check if glibc can produce working statically linked binaries +by performing a getpwnam(root) call before building (#754813) + + -- Michael Tokarev m...@tls.msk.ru Wed, 12 Nov 2014 23:59:30 +0300 + +busybox (1:1.22.0-12) unstable; urgency=medium + + * fix the previous changelog entry (wrong bug# was fixed and typos) + * ensure we build against non-broken glibc (=2.19-12) (Closes: #769190) + + -- Michael Tokarev m...@tls.msk.ru Wed, 12 Nov 2014 12:37:11 +0300 + +busybox (1:1.22.0-11) unstable; urgency=medium + + * fix the built-using generation in the previous upload -- did not +work correctly for != 1 dependency and #588505 in dpkg + + -- Michael Tokarev m...@tls.msk.ru Tue, 11 Nov 2014 19:24:21 +0300 + +busybox (1:1.22.0-10) unstable; urgency=high + + * lzop-add-overflow-check-CVE-2014-4607.patch (Closes: #768945) + * add Built-Using control field for -static, deriving it from +regular build (this will be glibc) (Closes: #768876) + * install only arch/indep deb as requested by binary-arch or binary-indep +target. This fixes a long-standing lintian error, when package build +always produces busybox-syslogd package which is arch:all and should not +be built on a buildd. + + -- Michael Tokarev m...@tls.msk.ru Tue, 11 Nov 2014 17:07:34 +0300 + busybox (1:1.22.0-9) unstable; urgency=medium * cherry-pick find /BITS patch from upstream (Closes: #760637) diff -Nru busybox-1.22.0/debian/control busybox-1.22.0/debian/control --- busybox-1.22.0/debian/control 2014-09-30 08:35:20.0 +0400 +++ busybox-1.22.0/debian/control 2014-11-14 12:52:17.0 +0300 @@ -5,7 +5,10 @@ Uploaders: Bastian Blank wa...@debian.org, Michael Tokarev m...@tls.msk.ru Build-Depends: debhelper (= 9), # needs for testsuite to run - zip + zip, +# glibc static-nss #754813, 2.19..2.19-11, -12 is ok. Depend on libc-dev-bin +# as it is the package which is named the same on all architectures + libc-dev-bin ( 2.19-12~) | libc-dev-bin ( 2.19), Standards-Version: 3.9.5 Vcs-Git: git://anonscm.debian.org/d-i/busybox.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=d-i
Bug#771208: unblock: busybox/1:1.22.0-14
27.11.2014 19:00, Cyril Brulebois wrote: (Putting on my d-i RM fedora.) Thank you for your review. Michael Tokarev m...@tls.msk.ru (2014-11-27): Please unblock package busybox. Last upload has one security bugfix (CVE-2014-4607, #768945), the fix is from upstream stable branch, fixing an integer overflow in lzo decompressor; it adds a Built-Using control field for busybox-static variant (#768926), and also arranges build system to only produce binary or indep .debs (or both), depending on the d/rules target (binary-all vs binary-indep vs binary) -- this is a long-standing lintian bug which I overlooked previously. #768926 is still not #768876: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768926#28 Yes you're right. I fixed it in the changelog but not in this unblock request. Actual bug fixed here is #768876. [] #768876 is tagged jessie-ignore so I'm really unconvinced by the debian/rules changes. It is jessie-ignore just to be non-RC. The fun with static linking and bugs it discovered shows that proper Built-Using field is really necessary (it is what #768876 is about). However, bulk of d/rules changes are due to another build fix, to stop building arch-all package (busybox-syslogd) when building binary-arch. Plus one block of added lines to check whenever libc is able to produce working statically-linked executables. At this stage, I'd rather see the security fix only. Release team people, what's your take on this? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54774c91.9080...@msgid.tls.msk.ru
Bug#769129: unblock: busybox/1:1.22.0-10
14.11.2014 12:42, Julien Cristau wrote:
FWIW I don't believe build-conflicts on libc achieve anything, so I'm
unhappy with -13.
I'm not happy with it either, but why do you say it does not achieve
anything? Why do you say so, is this control field ignored?
At any rate I changed that to build-depend on libc-dev-bin (2.19-13 | 2.19).
Can you say something about the FTBFS on hurd-i386 with the new test of
getpwnam() (not)working, as seen in the buildd logs? It sigsegvs on the
following one-line program:
int main(void) { return getpwnam(root) ? 0 : 1; }
cc -static test.c
Should I do anything with it? The same happens on exodar.debian.net too
(hurd-i386 porterbox) -- this small program segfaults there.
I'd like to address this prob before uploading -14 :)
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5465d31c.6040...@msgid.tls.msk.ru
Bug#769129: unblock: busybox/1:1.22.0-10
14.11.2014 13:12, Julien Cristau wrote: On Fri, Nov 14, 2014 at 13:02:04 +0300, Michael Tokarev wrote: 14.11.2014 12:42, Julien Cristau wrote: FWIW I don't believe build-conflicts on libc achieve anything, so I'm unhappy with -13. I'm not happy with it either, but why do you say it does not achieve anything? Why do you say so, is this control field ignored? Its only effect is to get that package removed if it's installed. Somehow removing libc doesn't seem like a good idea. Well, so it is clear that building will not succeed if only old glibc is installed. Note the amd64 build log for example: current build-conflict causes the buildd to upgrade libc6, because it has 2.12-11 installed which conflicts with building busybox, so the condition is actually working. https://buildd.debian.org/status/fetch.php?pkg=busyboxarch=amd64ver=1%3A1.22.0-13stamp=1415831665 But it is ugly at least, I agree with that. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5465d76b.3090...@msgid.tls.msk.ru
Bug#769129: unblock: busybox/1:1.22.0-10
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package busybox. Last upload has one security bugfix
(CVE-2014-4607, #768945), the fix is from upstream stable branch,
fixing an integer overflow in lzo decompressor; it adds a Built-Using
control field for busybox-static variant (#768926), and also arranges
build system to only produce binary or indep .debs (or both), depending
on the d/rules target (binary-all vs binary-indep vs binary) -- this
is a long-standing lintian bug which I overlooked previously.
(The Built-Using field generation is a bit fun here: I asked on IRC
how people identify which libc is in use, and got various somewhat-
incpmplete replies (the prob is that on different arches, libc package
is named differently). So I invented my own way for busybox, because
this package allows me to do that -- I took the contents of $shlibs:Depends
variable for the dynamically-linked version, and transformed it into
a list of sources required for Built-Using using dpkg-query.
There's no code changes except the lzo decompression bugfix, only
packaging changes.
Thank you!
/mjt
unblock busybox/1:1.22.0-10
diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2014-09-30 08:50:20.0 +0400
+++ busybox-1.22.0/debian/changelog 2014-11-11 17:07:46.0 +0300
@@ -1,3 +1,15 @@
+busybox (1:1.22.0-10) unstable; urgency=high
+
+ * lzop-add-overflow-check-CVE-2014-4607.patch (Closes: #768945)
+ * add Built-Using control field for -static, deriving it from
+regular build (this will be glibc) (Closes: #768926)
+ * install only arch/indep deb as requested by binary-arch or binary-indep
+target. This fixes a long-standing lintian error, when package build
+alway produces busybox-syslogd package which is arch:all and should not
+be built on a buildd.
+
+ -- Michael Tokarev m...@tls.msk.ru Tue, 11 Nov 2014 17:07:34 +0300
+
busybox (1:1.22.0-9) unstable; urgency=medium
* cherry-pick find /BITS patch from upstream (Closes: #760637)
diff -Nru busybox-1.22.0/debian/control busybox-1.22.0/debian/control
--- busybox-1.22.0/debian/control 2014-09-30 08:35:20.0 +0400
+++ busybox-1.22.0/debian/control 2014-11-10 15:06:53.0 +0300
@@ -33,6 +33,7 @@
Package: busybox-static
Architecture: any
+Built-Using: ${built-using}
Depends: ${shlibs:Depends}, ${misc:Depends}
Conflicts: busybox
Replaces: busybox
diff -Nru
busybox-1.22.0/debian/patches/lzop-add-overflow-check-CVE-2014-4607.patch
busybox-1.22.0/debian/patches/lzop-add-overflow-check-CVE-2014-4607.patch
--- busybox-1.22.0/debian/patches/lzop-add-overflow-check-CVE-2014-4607.patch
1970-01-01 03:00:00.0 +0300
+++ busybox-1.22.0/debian/patches/lzop-add-overflow-check-CVE-2014-4607.patch
2014-11-10 15:06:53.0 +0300
@@ -0,0 +1,67 @@
+From a9dc7c2f59dc5e92870d2d46316ea5c1f14740e3 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko vda.li...@googlemail.com
+Date: Mon, 30 Jun 2014 10:14:34 +0200
+Subject: lzop: add overflow check
+Bug-Debian: http://bugs.debian.org/768945
+
+See CVE-2014-4607
+http://www.openwall.com/lists/oss-security/2014/06/26/20
+
+function old new delta
+lzo1x_decompress_safe 10101031 +21
+
+Signed-off-by: Denys Vlasenko vda.li...@googlemail.com
+---
+ archival/libarchive/liblzo.h |2 ++
+ archival/libarchive/lzo1x_d.c |3 +++
+ 2 files changed, 5 insertions(+)
+
+diff --git a/archival/libarchive/liblzo.h b/archival/libarchive/liblzo.h
+index 843997c..4596620 100644
+--- a/archival/libarchive/liblzo.h
b/archival/libarchive/liblzo.h
+@@ -76,11 +76,13 @@
+ #define TEST_IP (ip ip_end)
+ #define NEED_IP(x) \
+ if ((unsigned)(ip_end - ip) (unsigned)(x)) goto input_overrun
++#define TEST_IV(x) if ((x) (unsigned)0 - (511)) goto
input_overrun
+
+ #undef TEST_OP /* don't need both of the tests here */
+ #define TEST_OP 1
+ #define NEED_OP(x) \
+ if ((unsigned)(op_end - op) (unsigned)(x)) goto output_overrun
++#define TEST_OV(x) if ((x) (unsigned)0 - (511)) goto
output_overrun
+
+ #define HAVE_ANY_OP 1
+
+diff --git a/archival/libarchive/lzo1x_d.c b/archival/libarchive/lzo1x_d.c
+index 9bc1270..40b167e 100644
+--- a/archival/libarchive/lzo1x_d.c
b/archival/libarchive/lzo1x_d.c
+@@ -92,6 +92,7 @@ int lzo1x_decompress_safe(const uint8_t* in, unsigned in_len,
+ ip++;
+ NEED_IP(1);
+ }
++ TEST_IV(t);
+ t += 15 + *ip++;
+ }
+ /* copy literals */
+@@ -224,6 +225,7 @@ int lzo1x_decompress_safe(const uint8_t* in, unsigned
in_len,
+ ip
Bug#769129: unblock: busybox/1:1.22.0-10
11.11.2014 18:08, Michael Tokarev wrote: Please unblock package busybox. Last upload has one security bugfix (CVE-2014-4607, #768945), the fix is from upstream stable branch, fixing an integer overflow in lzo decompressor; it adds a Built-Using control field for busybox-static variant (#768926), and also arranges build system to only produce binary or indep .debs (or both), depending on the d/rules target (binary-all vs binary-indep vs binary) -- this is a long-standing lintian bug which I overlooked previously. (The Built-Using field generation is a bit fun here: I asked on IRC how people identify which libc is in use, and got various somewhat- incpmplete replies (the prob is that on different arches, libc package is named differently). So I invented my own way for busybox, because this package allows me to do that -- I took the contents of $shlibs:Depends variable for the dynamically-linked version, and transformed it into a list of sources required for Built-Using using dpkg-query. So this was a bit preliminary (following the notify the release team early rule too aggressively) -- this very Built-Using generation was broken due to an error on my part (trivial) and due to bug in dpkg, #588505. I just uploaded new release fixing this, 1:1.22.0-11, will see how it goes first, and will ping this bug if everything is okay. (Yes, I verified the fixed release builds on kfreebsd-amd64 where the problematic release failed). Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5462412b.7060...@msgid.tls.msk.ru
Bug#768007: unblock: qemu/2.1+dfsg-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please consider unblocking package qemu. Current version has 2 security
fixes (CVE-2014-3689 and CVE-2014-7815) and a fix for possible data
corrupter which has biten several people already (this one does not have
a bug# in debian, but ofc. I can file one too, original discussion was at
https://bugs.launchpad.net/qemu/+bug/1368815 ).
Besides that, it has several other bugfixes - #747636, #755740, #760949,
#765075 - these are easy changes not touching critical paths in the package.
All code changes are from upstream.
And besides that, there are a few tweaks in build system, which has been
tested extensively to ensure nothing breaks, which will help us to maintain
this package together with ubuntu guys without a need for forking - this
is something I really wanted to get into debian before freeze, because it
will be the common ground for quite some time.
Complete list of changes (from 2 releases combined):
* urgency is high due to 2 security fixes
and because of possible data corruption bugfix
* vnc-sanitize-bits_per_pixel-from-the-client-CVE-2014-7815.patch
from upstream (Closes: CVE-2014-7815)
* add two patches from upstream for block/raw-posix.c to work around
probs in FS_IOC_FIEMAP ioctl and to prefer seek_hole over fiemap.
This should fix a long-standing ghost data corruption observed
in various places.
* mention closing of CVE-2014-3615 by 2.1.2 (2.1+dfsg-5)
* 9p-use-little-endian-format-for-xattr-values.patch (Closes: #755740)
* mention closing of #760386
* mention closing of more CVEs by 2.1+dfsg-1
* recognize ppc64el in qemu-debootstrap (Luca Falavigna) (Closes: #760949)
* use dpkg-vendor to let derived distros to use our d/rules
* use /usr/share/dpkg/architecture.mk to get DEB_HOST_* and DEB_BUILD_*
variables. This restores cross building support.
* use /usr/share/dpkg/buildflags.mk for CFLAGS LDFLAGS Co
* pass -DVENDOR_{DEBIAN,UBUNTU} to compiler
* do not treat ppc* and ppc*le as compatible for binfmt registrations
* mention ACPI SLIC to RSDT id copying if slic table is supplied,
thank you Tim Small for the patch (Closes: #765075)
* apply 5 patches from upstream to fix a security issue in
vmware-vga (Closes: #765496 CVE-2014-3689)
* apply two patches from upstream to make qemu to work with samba4
(Closes: #747636)
unblock qemu/2.1+dfsg-7
-- System Information:
Debian Release: 7.7
APT prefers stable
APT policy: (990, 'stable'), (500, 'oldstable'), (199, 'testing'), (50,
'unstable'), (40, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
powerpc
Kernel: Linux 3.10-amd64 (SMP w/8 CPU cores)
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20141104053546.1635.95466.reportbug@gandalf.local
Bug#742386: wheezy-pu: package qemu/1.1.2+dfsg-6a+deb7u1
18.04.2014 15:40, Adam D. Barratt wrote: On 2014-04-13 19:05, Michael Tokarev wrote: [] There's a pending security update for qemu fixing CVE-2014-0150 (#744221), which uploads +deb7u1 for both qemu and qemu-kvm, fwiw. Okay, thanks. I guess the stable updates should be +deb7u2 then, incorporating the u1 upload, once it's released. Yes indeed. And I want to take care of this, again, once security fix will be released. I noticed that the security updates have now been released. Not wishing to chase, just a gentle reminder that the window for getting updates in to 7.5 closes over the weekend. (Although getting in to 7.6 instead is presumably not a huge problem.) I've another security bugfix for qemu+qemu-kvm, CVE-2014-2894, assigned today, see https://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg02016.html The fix is also one-liner. Maybe we can combine the two - this #742386 and CVE-2014-2894 - into single pu? If not, I guess I'll go with this #742386 first and CVE-2014-2894 on top of it. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53511284.7070...@msgid.tls.msk.ru
Bug#742386: wheezy-pu: package qemu/1.1.2+dfsg-6a+deb7u1
13.04.2014 21:39, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sun, 2014-03-23 at 12:45 +0100, Gabriele Giacone wrote: On Sun, Mar 23, 2014 at 01:48:34PM +0400, Michael Tokarev wrote: Please note that the same changes should be done for qemu-kvm package on wheezy. Also note that the names of patches does not reflect reality. These are fixing real bugs in qemu, not hurd-specific issues. Renamed patches, attached qemu-kvm one too. Please go ahead. There's a pending security update for qemu fixing CVE-2014-0150 (#744221), which uploads +deb7u1 for both qemu and qemu-kvm, fwiw. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534ace24.60...@msgid.tls.msk.ru
Bug#742386: wheezy-pu: package qemu/1.1.2+dfsg-6a+deb7u1
13.04.2014 22:04, Adam D. Barratt wrote: On Sun, 2014-04-13 at 21:49 +0400, Michael Tokarev wrote: 13.04.2014 21:39, Adam D. Barratt wrote: On Sun, 2014-03-23 at 12:45 +0100, Gabriele Giacone wrote: On Sun, Mar 23, 2014 at 01:48:34PM +0400, Michael Tokarev wrote: Please note that the same changes should be done for qemu-kvm package on wheezy. Also note that the names of patches does not reflect reality. These are fixing real bugs in qemu, not hurd-specific issues. Renamed patches, attached qemu-kvm one too. Please go ahead. There's a pending security update for qemu fixing CVE-2014-0150 (#744221), which uploads +deb7u1 for both qemu and qemu-kvm, fwiw. Okay, thanks. I guess the stable updates should be +deb7u2 then, incorporating the u1 upload, once it's released. Yes indeed. And I want to take care of this, again, once security fix will be released. Thank you Gabriele for the work! /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534ad200.9000...@msgid.tls.msk.ru
Bug#742386: wheezy-pu: package qemu/1.1.2+dfsg-6a+deb7u1
23.03.2014 05:31, Gabriele Giacone wrote: Package: release.debian.org Severity: normal Tags: wheezy User: release.debian@packages.debian.org Usertags: pu Hello, this upload would fix two bugs with severity important regarding booting GNU/Hurd machines. Please note that the same changes should be done for qemu-kvm package on wheezy. Also note that the names of patches does not reflect reality. These are fixing real bugs in qemu, not hurd-specific issues. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/532eadf2.20...@msgid.tls.msk.ru
Bug#718767: Bug#710650: Bug#718767: transition: ocaml 4.00.1
06.09.2013 10:42, Stéphane Glondu write: [] Now, xen-api FTBFS because of what looks like an API change in some (C) dependency: [] On the other hand, there is a new upstream release (upstream version is 1.6 and unstable version is 1.3.2). It doesn't make sense to me to invest time in this without updating the package, which goes beyond the scope of an NMU. Fixing #713349 was already borderline since there is also a new upstream release there... but it was easy. The FTBFS bug has been reported in June. I told some of the maintainers (in-person, in CC) to update this package during debconf. No activity since them. IMHO, this package is neglected and should be removed from testing. The situation with xen-api, as far as I can see from my non-maintainer not xen-related view - is quite a bit difficult. The upstream is very much redhat-specific, and they ported the previous version to debian, which required quite some work. I don't know the details there, but I looked briefly at the git diff between redhat and deboan versions - it was quite large and didn't end up just replacing /usr/libexec/ into /usr/lib/ and the like. Now, it looks like similar porting effort is needed to port the new upstream version. Which no one want to do, apparently... ;) That's the reason - again, as far as I can see - why the inactivity is happening. I tried to do something with it because xen-api stops qemu migration and users are asking about it quite often. But I don't know anything about either xen or ocaml or other related stuff, and especially with this porting stuff, it looks like I'm not the right candidate to sort it out. There are a few reverse-dependencies, but they all look somehow connected: nova, guest-templates, xcp-*... My take would be to remove (from testing) all of them. I'd vote for the same, but again, I'm not a user of any of these, so it's easy for me... ;) Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5229800c.20...@msgid.tls.msk.ru
Bug#702278: busybox upload
Control: reopen -1 05.05.2013 12:00, Michael Tokarev wrote: Control: retitle -1 pu: busybox/1:1.20.0-8 Hmm. I didn't notice the bug has been closed... Reopening it (now re-titled as a pu), instead of submiting a new report, so that all the information is in one place. Thanks, and sorry for all the noize. /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518b5fde.20...@msgid.tls.msk.ru
Bug#702278: busybox upload
Control: retitle -1 pu: busybox/1:1.20.0-8 17.04.2013 22:54, Adam D. Barratt wrote: user release.debian@packages.debian.org tags 686502 + wheezy-ignore usertags 686502 + wheezy-can-defer thanks On Mon, 2013-04-08 at 09:51 +0200, Cyril Brulebois wrote: Michael Tokarev m...@tls.msk.ru (08/04/2013): We're unlikely to met all the conditions for this bug in d-i or initramfs during wheezy lifetime, -- _provided_ that some future _wheeze_ update will not contain such concatenated xz streams produced by, say, an improved version of dpkg (which utilizes multiple cores for compression), -- but this is an unlikely situation. Agreed, and unlikely means I'm not going to approve of such a chance at this point. Based on the above, I think it's fair to say the changes aren't going to make wheezy r0. Maybe we could revisit some (or all) of the fixes for a point release? I already has been biten by #686502 - this bug may be not relevant for the d-i, since all xz stuff there is more or less controlled, but for regular busybox usage it's important. Anyway, I'm retitling this bug (#702278), turning it into pu. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518611a6.7020...@msgid.tls.msk.ru
Bug#702278: busybox upload
08.04.2013 11:57, Cyril Brulebois wrote: Forgot to mention one thing: Cyril Brulebois k...@debian.org (08/04/2013): My take is: until we hit real bugs in real situations, we keep busybox as it is. If release managers want to cherry-pick a few fixes, I won't stop them from requesting so. But as far as I'm concerned, I'd really like to see practical issues before getting busybox updated. Nonetheless, I do appreciate your efforts in trying to get things fixed, especially when done by cherry-picking things from upstream, instead of insisting for our moving to latest master. It's just too late for that, for bugs that don't seem to be hit in real life©®™. We've at least two bugs which do hit us in real life - this is the xz multi-stream issue (already seen on kernel.org) and non-working grep -w. But I repeat myself. FWIW. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51627a15.9020...@msgid.tls.msk.ru
Bug#702278: busybox upload
I'm pinging this bug, as we're getting seriously out of time. Now, I guess, we should either let the whole thing go (it has already been unblocked for, only d-i block remains), or mark the relevant bugs as non-RC for wheezy. Thanks, /mjt 25.03.2013 15:38, Michael Tokarev wrote: Let me start from scratch please. I wasn't aware of this bugreport/discussion, and I made a mistake by not filing a proper unblock request when I uploaded the busybox package with all the fixes. So here are descriptions of every change. A sort of a fore-word first. Busybox is kind of unusual package in a way that it re-implements functionality of various existing packages. Base debian system uses other implementations of the same functionality usually. So from this PoV, any busybox bug is not that important for a user's debian system, since a typical user does not use any busybox applets at all. Busybox _is_ used on almost every end-user system because it provides the set of basic *nix utilities for initramfs, and it is used in debian-installer. But these are very restricted environments with much better defined components and much less chance to have a combination which triggers one or another bug. So, any bug in busybox which does not affect basic initramfs or d-i functionality directly can't be important enough for whole debian system, so to say. On the other hand, sometimes, since busybox is almost always installed and available on any debian system, it gets used by users in various much less restricted environments, which leads to situations where the bugs are actually gets hit. This is minority of users (again, so to say). So this is about whenever we really care about this minority or not, _plus_ about _possible_ issues in d-i or initramfs. Another source of unusuality comes from the fact that busybox implements a ton of _independent_ applets, so that a change in one does not affect anything else (if we don't count changes in, say, memory layout which triggers bugs elsewhere - this has already happened at least once during wheezy development cycle, when we discovered bug with unaligned memory access which was hidden because the objects were actually aligned properly before we changed something unrelated in memory). So, back to the changes. busybox (1:1.20.0-8) unstable; urgency=low * grep-fix-grep--Fw-not-respecting-the--w-option.patch - implement fgrep -w correctly (Closes: #695862) As has been said before, this is a feature fix. It is not. The problem initially has been raized in some other package which had initramfs hook which didn't work. I don't remember which package it was, the context was that it tried to find some CPU feature by grepping /proc/cpuinfo with -w flag to grep, used to remove false positives, and it didn't work. (/proc/cpuinfo is just an example, I don't really remember what it was). This is one of these bugs which makes other, unrelated components fails in unexpected and difficult to debug ways. The fix is somewhat large, because it had to deal with logic of operations in grep applet. On the plus side, it comes with additional testcases which checks for this issue, and there are lots of other grep-related testcases already present. Unfortunatly busybox debian package still does not run any testcases during build (this is on my TODO list of first things to do for jessie), but having in mind the situation (deep freeze) and importance of the applet I ran provided and a few more testcases against the resulting grep on x86, ppc and mips platforms (on debian porterboxes) manually to ensure the fix does not break anything else and actually fixes the bug. If you ask me, this is about the same importance as #686502, but it is less obvious. This grep-w bug does not lead to data loss directly, the problem is that we can't rely on grep doing the right thing when we use it in a familiar, natural way - like when we try to fix a false positive by adding -w _somewhere else_ (in some other package that is), and it stops working. That's why it isn't a feature fix, busybox claimed to support grep-w but it does not work. What we're fixing here mostly is about _further_ d-i or initramfs changes (including possibility to have these changes in wheezy too) which looks completely correct and obvious but don't work in practice. Plus some random rare end-users usage of busybox grep, of these are exists. What we risk here is almost nothing, at least according to my tests on several platforms. * xz-support-concatenated-xz-streams.patch (Closes: #686502) This is the main RC bug currently filed against busybox. The rationale for it being RC is because it causes _silent_ data loss when decompressing certain kinds of XZ streams. Again, the severuty can be argued for sure, due to whole nature of busybox as a second-kind sitizen as mentioned at the beginning of this mail. First, not everyone
Bug#702278: t-p-u busybox upload (was: Re: busybox/1:1.20.0-8)
25.03.2013 13:37, Didier Raboud wrote: Hi all, I propose to upload busybox to t-p-u with only the RC bugfixes (#686502 and #701965, CVE-2013-1813). I have cherry-picked thoses changes on top of wheezy's. The resulting debdiff is attached, with version 1:1.20.0-7+deb7u0.1. I really hoped it can go as-is without any further reduction of fixes, all other stuff is also carefully picked and are fixes for real issues. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51501e00.3080...@msgid.tls.msk.ru
Bug#702278: t-p-u busybox upload
25.03.2013 13:54, Didier Raboud wrote: I propose to upload busybox to t-p-u with only the RC bugfixes (#686502 and #701965, CVE-2013-1813). IRC feedback on that subject lead to dropping the fix for #701965, rationale being http://bugs.debian.org/702278#17 . That's lovely. I haven't even seen this bugreport and this discussion before now. This message #17 mentions few feature fixes, which is completely wrong -- all these are real fixes for serious enough problems. I can only guess by feature fixes Adam meant the grep -w thing. It is not a feature fix, it is a bugfix for incorrectly working grep -w, which already lead to a costly bughunting in another place which relied on correctly implemented grep -w. This has nothing to do at all with the freeze. The CVE-2013-1813 fix is indeed not really interesting (even while the fix is rather stright-forward, it isn't exactly a one-liner and is somewhat ugly) -- I thought we'd fix the CVE anyway, since this is a very specific subsystem and does not affect anything else. But the rest really should go to wheezy. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51502268.8080...@msgid.tls.msk.ru
Bug#702278: busybox upload
Let me start from scratch please. I wasn't aware of this bugreport/discussion, and I made a mistake by not filing a proper unblock request when I uploaded the busybox package with all the fixes. So here are descriptions of every change. A sort of a fore-word first. Busybox is kind of unusual package in a way that it re-implements functionality of various existing packages. Base debian system uses other implementations of the same functionality usually. So from this PoV, any busybox bug is not that important for a user's debian system, since a typical user does not use any busybox applets at all. Busybox _is_ used on almost every end-user system because it provides the set of basic *nix utilities for initramfs, and it is used in debian-installer. But these are very restricted environments with much better defined components and much less chance to have a combination which triggers one or another bug. So, any bug in busybox which does not affect basic initramfs or d-i functionality directly can't be important enough for whole debian system, so to say. On the other hand, sometimes, since busybox is almost always installed and available on any debian system, it gets used by users in various much less restricted environments, which leads to situations where the bugs are actually gets hit. This is minority of users (again, so to say). So this is about whenever we really care about this minority or not, _plus_ about _possible_ issues in d-i or initramfs. Another source of unusuality comes from the fact that busybox implements a ton of _independent_ applets, so that a change in one does not affect anything else (if we don't count changes in, say, memory layout which triggers bugs elsewhere - this has already happened at least once during wheezy development cycle, when we discovered bug with unaligned memory access which was hidden because the objects were actually aligned properly before we changed something unrelated in memory). So, back to the changes. busybox (1:1.20.0-8) unstable; urgency=low * grep-fix-grep--Fw-not-respecting-the--w-option.patch - implement fgrep -w correctly (Closes: #695862) As has been said before, this is a feature fix. It is not. The problem initially has been raized in some other package which had initramfs hook which didn't work. I don't remember which package it was, the context was that it tried to find some CPU feature by grepping /proc/cpuinfo with -w flag to grep, used to remove false positives, and it didn't work. (/proc/cpuinfo is just an example, I don't really remember what it was). This is one of these bugs which makes other, unrelated components fails in unexpected and difficult to debug ways. The fix is somewhat large, because it had to deal with logic of operations in grep applet. On the plus side, it comes with additional testcases which checks for this issue, and there are lots of other grep-related testcases already present. Unfortunatly busybox debian package still does not run any testcases during build (this is on my TODO list of first things to do for jessie), but having in mind the situation (deep freeze) and importance of the applet I ran provided and a few more testcases against the resulting grep on x86, ppc and mips platforms (on debian porterboxes) manually to ensure the fix does not break anything else and actually fixes the bug. If you ask me, this is about the same importance as #686502, but it is less obvious. This grep-w bug does not lead to data loss directly, the problem is that we can't rely on grep doing the right thing when we use it in a familiar, natural way - like when we try to fix a false positive by adding -w _somewhere else_ (in some other package that is), and it stops working. That's why it isn't a feature fix, busybox claimed to support grep-w but it does not work. What we're fixing here mostly is about _further_ d-i or initramfs changes (including possibility to have these changes in wheezy too) which looks completely correct and obvious but don't work in practice. Plus some random rare end-users usage of busybox grep, of these are exists. What we risk here is almost nothing, at least according to my tests on several platforms. * xz-support-concatenated-xz-streams.patch (Closes: #686502) This is the main RC bug currently filed against busybox. The rationale for it being RC is because it causes _silent_ data loss when decompressing certain kinds of XZ streams. Again, the severuty can be argued for sure, due to whole nature of busybox as a second-kind sitizen as mentioned at the beginning of this mail. First, not everyone is using busybox unxz (which is used in busybox tar and other archivers too), second, concatenaed xz streams aren't frequent either (but this becomes more and more of a problem, because such streams are produced by parallel xz, and this already seen in the wild - in particular, recent kernel sources on kernel.org are of this kind). We're unlikely to met all the conditions for this
Bug#702278: busybox upload
And sure thing I forgot to Cc debian-boot@. I think if this needs to be discussed further, debian-boot@ should receive it too. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5150384a.4050...@msgid.tls.msk.ru
Bug#691710: unblock: mdadm/3.2.5-4 (pre-upload)
28.01.2013 05:07, Cyril Brulebois wrote: Julien Cristau jcris...@debian.org (26/01/2013): 3.2.5-5 unblocked. unblock-udeb pending d-i ack, probably post-rc1. Looks like post-rc1 material to me indeed. FWIW (not insisting for earlier inclusion, just noting), for the d-i, the noticeable change is the inclusion of an extra binary, mdmon, which is unused on all currently working setups and is only used internally by mdadm when it tries to assemble a fakeraid IMSM array. The bugfixes (code fixes) included in this release does^Wshould not affect d-i, these are mostly about routine array maintenance which isn't done in d-i. A bit wider testing, however, is veery welcome, -- for one, I don't know whenever it will work in d-i or not, because I don't have hardware where I can test it. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5106334b.4030...@msgid.tls.msk.ru
Bug#691710: unblock: mdadm/3.2.5-4 (pre-upload)
replay (which is done even on a read-only mount) can not be completed, so an uncleanly umounted ext4 can't be mounted. And we need to just provide mdmon binary in initramfs for the whole thing to start working. But we also need 3 extra steps _after_ such an array is started: first, we need to restart mdmon from real root once the system is booted, in order to release initramfs. Second, we need to ensure that these mdmon processes will not be killed by sendsigs during shutdown, because mdmon might still be needed after sendsigs is done - when umounting filesystems etc. And third, we need to wait for such arrays to settle down (to sync metadata etc) at the very end of the shutdown process (mdmon need to finish its task there), or else at next boot the array will not be clean. And one more thing -- the udeb now includes mdmon binary -- for exactly the same reason, mere presence of this binary is enough to start such non-native raid array from within the installer. There's no other changes which affects udeb/d-i in this release. Miquel provided a patch implementing all this, and I reworked it a bit. -- The resulting package has been in -experimental for these 3 months already (I understand it does not say much but.). The changes -- at leaat the changes not related to mdmon/fakeraid -- are necessary for wheezy, the bugfixes are important enough. I think that supporting fakeraid arrays in debian is also very important. We had no enough testing for fakeraid part unfortunately (esp. since there was no d-i built with this functionality so far), but it is at least an attempt to do something. D-i with current mdadm will just hang when the target system has fakeraid array (it will try to remount it read-write and kernel will wait for mdmon to catch up forever). And I tried to ensure that the differences does not affect non-fakeraid usage in any way (*). So, I'm kindly asking, after patiently waiting for 3 months, to unblock mdadm/3.2.5-5 (*) There is one change for non-fakeraid arrays introduced by this mdmon/fakeraid changes. Namely, mdadm-waitidle script now ensures that all arrays which are still running at the very end of the boot process - like, for example, the array on which root filesystem is located -- this script ensures that these arrays are in idle state, ie, that all superblocks are written to disk safely. This closes the possibility that md arrays may become dirty on the next boot. So it is a change with a good effect even for non-fakeraid arrays. Thanks, /mjt 29.10.2012 00:42, Michael Tokarev wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock This is a pre-upload unblock request for mdadm/3.2.5-4. Recently, upstream released a new version of mdadm, v3.2.6, which contains only bugfixes or documentation improvements. I'm cherry-picking only the most important changes from this version. These changes fixes a number of important bugs, each of which is not of RC severity, but important enough to be included into wheezy in my point of view. Each of the bug has relatively low impact or probability, or can be seen in only very specific configurations, but once you hit it, it might be difficult to recover the data which was on the raid array in question. This is why I consider these to be good candidates for wheezy. This unblock request consists of two parts. First, the main part, which talks about several bugfixes: Here are the list of changelog entries of this nature: * Fix 'enough' function for RAID10, to prevent starting of a RAID10 array which does not have required minimum of component devices. (Closes: #691668). * fix segfaults in Detail() - mdadm --detail may segfault if a drive has been removed from the array (Closes: #691670) * super0: do not override uuid with homehost. The bug prevented re-creating an array with v0.90 superblock with the specified uuid when homehost is also specified. (Closes: #686703) Each of the above 3 patches fixes specific bugs relevant to data stability, so to say. * several fixes for mdmon argument processing (Closes: #691671): - allow --takeover when original was started with --offroot - fix arg parsing. - fix arg processing for -a The last series - mdmon argument processing fixes - is not directly relevant for version of the package currently in wheezy, since mdmon utility there is not used right now. For this reason, the fixes above are of zero risk for configurations which are directly supported by mdadm debian package infrastructure. However, mdmon is required to support raid arrays with external metadata, which are all the fakeraid arrays (ahci and other in-chipset implementations), found in almost all modern motherboards or PCs. These tiny bugfixes allows usage of such arrays in saner way. More about mdmon is below. While at it, I'm also fixing 2 minor issues with packaging which were slipped in - one debian
Bug#698221: unblock: qemu/1.1.2+dfsg-5 qemu-kvm/1.1.2+dfsg-5
19.01.2013 15:23, Julien Cristau wrote:
qemu{,-kvm} unblocked.
Thank you very much Julien!
/mjt
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50fd25b0.8070...@msgid.tls.msk.ru
Bug#698221: unblock: qemu/1.1.2+dfsg-5 qemu-kvm/1.1.2+dfsg-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package qemu The updated release includes 3 bugfixes. Changelog with comments: * e1000-discard-oversized-packets-based-on-SBP_LPE.patch: the second half of the fix for CVE-2012-6075. (Finally Closes: #696051) This is a security fix for CVE-2012-6075. As it turned out, there are 2 sides of this issue, and 2 halves for the fix. While we thought the change in previous release (1.1.2+dfsg-3) was enough, it actually is not, since the bug can be triggered using another conditions too. Complete fix contains in 2 changes (which touches the same area): e1000-discard-packets-that-are-too-long-if-not-SBP-and-not-LPE.patch (which was included in 1.1.2+dfsg-3 release) and e1000-discard-oversized-packets-based-on-SBP_LPE.patch (being included now). These patches are used in a recent qemu qemu-kvm security update in squeeze (stable-security) too. Both patches are from upstream. I tried my usual pile of guests here trying to verify there's no visible regressions due to that, all guests seems to continue working fine. The changes only affects e1000 device emulation, and has no impact on other parts of qemu. * linux-user-fix-mips-32-on-64-prealloc-case.patch (Closes: #668658) This is a simple patch which unbreaks MIPS 32bit emulation on 64bit host. Before this patch, mips32 were completely unusable/unworking on any 64bit host, including the most commonly used amd64 one. Also a low-risk change, since it is specific to this architecture (and only for the 32-on-64 case), and makes previously completely non-working stuff working. It is a fix for bug of priority Important, but I think it really is important to fix this for wheezy and not let wheezy be released without it, since emulation of mips is important enough. * fix USB regression introduced in 1.1 (Closes: #683983) uhci-don-t-queue-up-packets-after-one-with-the-SPD-flag-set.patch Big thanks to Peter Schaefer (https://bugs.launchpad.net/bugs/1033727) for the help identifying the fix. This is another fix for Important bug. As it turned out, many real USB devices which worked in previous versions of qemu[-kvm] (in wheezy/testing, before 1.1 version) were broken since 1.1 version. I've got many reports about various devices not working anymore. It turned out that only certain sequence of events triggers this issue, and not all guests and not all devices triggers it, but general result of this bug is quite bad. Supporting USB in a more or less reliable way is important because qemu is often used to run proprietary windows-only programs to flash a phone over USB or things like that, where there's no other good choice available (short of purchasing a separate PC just for that). I'm requesting to unblock both qemu and qemu-kvm at once, since the two are kept in the same state, and since the fixes applicable to both at the same time. However, the mips-related fix is not needed for qemu-kvm, since this one is x86-only. So qemu-kvm change does not include the mips-related fix. Other than that, the changes are exactly the same, including version numbers. Debdiff between qemu/1.1.2+dfsg-3 (currently in testing) and qemu/1.1.2+dfsg-5: -- diff -Nru qemu-1.1.2+dfsg/debian/changelog qemu-1.1.2+dfsg/debian/changelog --- qemu-1.1.2+dfsg/debian/changelog2012-12-16 23:24:01.0 +0400 +++ qemu-1.1.2+dfsg/debian/changelog2013-01-14 12:20:29.0 +0400 @@ -1,3 +1,20 @@ +qemu (1.1.2+dfsg-5) unstable; urgency=low + + * fix USB regression introduced in 1.1 (Closes: #683983) +uhci-don-t-queue-up-packets-after-one-with-the-SPD-flag-set.patch +Big thanks to Peter Schaefer (https://bugs.launchpad.net/bugs/1033727) +for the help identifying the fix. + + -- Michael Tokarev m...@tls.msk.ru Mon, 14 Jan 2013 12:20:29 +0400 + +qemu (1.1.2+dfsg-4) unstable; urgency=medium + + * linux-user-fix-mips-32-on-64-prealloc-case.patch (Closes: #668658) + * e1000-discard-oversized-packets-based-on-SBP_LPE.patch: the second +half of the fix for CVE-2012-6075. (Finally Closes: #696051) + + -- Michael Tokarev m...@tls.msk.ru Wed, 09 Jan 2013 23:05:17 +0400 + qemu (1.1.2+dfsg-3) unstable; urgency=low * add build-dependency on libcap-dev [linux-any] to enable virtfs support diff -Nru qemu-1.1.2+dfsg/debian/patches/e1000-discard-oversized-packets-based-on-SBP_LPE.patch qemu-1.1.2+dfsg/debian/patches/e1000-discard-oversized-packets-based-on-SBP_LPE.patch --- qemu-1.1.2+dfsg/debian/patches/e1000-discard-oversized-packets-based-on-SBP_LPE.patch 1970-01-01 03:00:00.0 +0300 +++ qemu-1.1.2+dfsg/debian/patches/e1000-discard-oversized-packets-based-on-SBP_LPE.patch 2013-01-14 12:13:18.0 +0400 @@ -0,0 +1,39 @@ +commit 2c0331f4f7d241995452b99afaf0aab00493334a +Author: Michael Contreras mich...@inetric.com +Date: Wed Dec 5 13:31:30 2012 -0500 +Bug-Debian: http
Bug#691710: unblock: mdadm/3.2.5-4 (pre-upload)
attached file, named mdadm_3.2.5-4+mdmon.debdiff,
there's incremental debdiff between version described above,
and the one which implements this mdmon functionality.
And one more thing -- the udeb now includes mdmon binary -- for
exactly the same reason, mere presence of this binary is enough
to start such non-native raid array from within the installer.
There's no other changes which affects udeb/d-i in this release.
Both set of changes is included into mdadm_3.2.5-4+mdmon which
I uploaded to experimental today.
I don't know which changes the release team will decide to be
okay or not okay for wheezy, -- so I'm asking first, before
uploading it to unstable.
I'll upload will be okay for the release team (and for the d-i team
as well!) to unstable, if at all.
Thank you for your time!
/mjt
diff -Nru mdadm-3.2.5/debian/changelog mdadm-3.2.5/debian/changelog
--- mdadm-3.2.5/debian/changelog 2012-08-25 23:29:05.0 +0400
+++ mdadm-3.2.5/debian/changelog 2012-10-28 21:12:37.0 +0400
@@ -1,3 +1,26 @@
+mdadm (3.2.5-4) UNRELEASED; urgency=low
+
+ * fix `/etc/init.d/mdadm-raid status' inverse logic (Closes: #686100)
+ * /etc/init.d/mdadm: change RUNDIR to /run instead of /var/run.
+Mdadm itself uses /run internally, we properly depend on initscripts
+version which creates /run, and the initscript itself is started
+after local_fs is processed, so this is merely a no-op, but let's
+do it for consistency.
+ * Fix 'enough' function for RAID10, to prevent starting of a RAID10
+array which does not have required minimum of component devices.
+(Closes: #691668).
+ * fix segfaults in Detail() - mdadm --detail may segfault if a drive
+has been removed from the array (Closes: #691670)
+ * super0: do not override uuid with homehost. The bug prevented
+re-creating an array with v0.90 superblock with the specified uuid
+when homehost is also specified. (Closes: #686703)
+ * several fixes for mdmon argument processing (Closes: #691671):
+- allow --takeover when original was started with --offroot
+- fix arg parsing.
+- fix arg processing for -a
+
+ -- Michael Tokarev m...@tls.msk.ru Sat, 20 Oct 2012 19:20:12 +0400
+
mdadm (3.2.5-3) unstable; urgency=low
* revert Drop unused debconf templates change -- the templates
@@ -21,7 +44,7 @@
* some cleanups for checkarray:
- change --help printing and shorten/simplify the text
- make --quiet cumulative and stop documenting --real-quiet
- - do not prduce help in case of incorrect usage, and exit with 1
+ - do not produce help in case of incorrect usage, and exit with 1
* fixes for initramfs integration (Closes: #644389, #678262, #685161):
- check INITRDSTART=none early
- do not explicitly load raid level modules (modprobe/kmod does this)
diff -Nru mdadm-3.2.5/debian/mdadm.init mdadm-3.2.5/debian/mdadm.init
--- mdadm-3.2.5/debian/mdadm.init 2012-06-22 11:16:25.0 +0400
+++ mdadm-3.2.5/debian/mdadm.init 2012-10-28 21:12:37.0 +0400
@@ -22,7 +22,7 @@
set -eu
MDADM=/sbin/mdadm
-RUNDIR=/var/run/mdadm
+RUNDIR=/run/mdadm
PIDFILE=$RUNDIR/monitor.pid
DEBIANCONFIG=/etc/default/mdadm
diff -Nru mdadm-3.2.5/debian/mdadm-raid mdadm-3.2.5/debian/mdadm-raid
--- mdadm-3.2.5/debian/mdadm-raid 2012-06-22 11:57:47.0 +0400
+++ mdadm-3.2.5/debian/mdadm-raid 2012-10-20 19:20:03.0 +0400
@@ -249,7 +249,7 @@
;;
status)
-if [ -f /proc/mdstat ]; then
+if [ ! -f /proc/mdstat ]; then
log_problem no MD subsystem loaded
exit 1
else
diff -Nru mdadm-3.2.5/debian/patches/fix-enough-function-for-RAID10.patch mdadm-3.2.5/debian/patches/fix-enough-function-for-RAID10.patch
--- mdadm-3.2.5/debian/patches/fix-enough-function-for-RAID10.patch 1970-01-01 03:00:00.0 +0300
+++ mdadm-3.2.5/debian/patches/fix-enough-function-for-RAID10.patch 2012-10-28 20:34:26.0 +0400
@@ -0,0 +1,46 @@
+From 2117ad1dd1b79cf6d02a065d9e38076aa9f4788d Mon Sep 17 00:00:00 2001
+From: NeilBrown ne...@suse.de
+Date: Thu, 27 Sep 2012 16:58:44 +1000
+Subject: Fix 'enough' function for RAID10.
+Bug-Debian: http://bugs.debian.org/691668
+Comment: from stable/bugfix 3.2.6 upstream version
+
+The 'enough' function is written to work with 'near' arrays only
+in that is implicitly assumes that the offset from one 'group' of
+devices to the next is the same as the number of copies.
+In reality it is the number of 'near' copies.
+
+So change it to make this number explicit.
+
+Reported-by: Jakub Husák ja...@gooseman.cz
+Signed-off-by: NeilBrown ne...@suse.de
+---
+ util.c |7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/util.c b/util.c
+index 83f3187..eef0d6f 100644
+--- a/util.c
b/util.c
+@@ -332,14 +332,15 @@ int enough(int level, int raid_disks, int layout, int clean, char *avail)
+ /* there must be one of the 'copies' form 'first' */
+ int n = copies;
+ int cnt=0;
++ int this = first;
+ while (n--) {
+-if (avail[first
Bug#684355: unblock: autofs/5.0.6-3
On 10.10.2012 20:06, Julien Cristau wrote: On Thu, Aug 9, 2012 at 09:39:22 +0400, Michael Tokarev wrote: diff -Nru autofs-5.0.6/debian/autofs.init autofs-5.0.6/debian/autofs.init [] +NAME=autofs +PIDFILE=/run/$NAME.pid the PIDFILE here is broken. Please fix it and let me know after 5.0.7-3 is in sid, I'll unblock the package. Thank you very much Julien for this hard work - reviewing autofs changes is quite a bit disgusting. And especially thank you very much for finding this my bug - it is the second, forgotten, half of the fix for #682675. I just uploaded the new release, which contains this fix and a tiny debian/changelog change (not mentioned itself in the changelog), just word-wrapping of a line for which lintian complained, no wording changes. Here's the debdiff between 5.0.7-2 and 5.0.7-3: --- cut --- diff -Nru autofs-5.0.7/debian/autofs.init autofs-5.0.7/debian/autofs.init --- autofs-5.0.7/debian/autofs.init 2012-06-07 23:41:38.0 +0400 +++ autofs-5.0.7/debian/autofs.init 2012-10-10 21:25:12.0 +0400 @@ -18,7 +18,7 @@ PROG=automount DAEMON=/usr/sbin/$PROG NAME=autofs -PIDFILE=/run/$NAME.pid +PIDFILE=/var/run/$NAME.pid test -e $DAEMON || exit 0 diff -Nru autofs-5.0.7/debian/changelog autofs-5.0.7/debian/changelog --- autofs-5.0.7/debian/changelog 2012-10-06 13:06:37.0 +0400 +++ autofs-5.0.7/debian/changelog 2012-10-10 21:28:41.0 +0400 @@ -1,3 +1,10 @@ +autofs (5.0.7-3) unstable; urgency=low + + * pidfile is in /var/run not /run: fix the initscript +(forgotten part of #682675) + + -- Michael Tokarev m...@tls.msk.ru Wed, 10 Oct 2012 21:28:40 +0400 + autofs (5.0.7-2) unstable; urgency=low * force transfer ucf autofs5=autofs ownership for all ucf-managed @@ -16,8 +23,8 @@ - fixes for nfs handling to be more robust - several fixes for multi-mount entries - several fixes for NFSv4 mounts (Closes: #675798) -and a few more small/misc fixes. This is all-bugfix changes, making -the code more robust and less buggy. +and a few more small/misc fixes. This is all-bugfix changes, +making the code more robust and less buggy. * removed --disable-mount-move configure option, not needed anymore. * removed autofs-5.0.6-upstream-git.patch. * refreshed manpages-hyphen.patch. --- cut --- /mjt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5075c6fc.2050...@msgid.tls.msk.ru
Bug#684355: unblock: autofs/5.0.7-2
Control: retitle -1 unblock: autofs/5.0.7-2 Since the previous email, one more neat way to break ucf file ownership tansfer when renaming a package has been found, #689747, which I just fixed. Initially we queried just one file which is supposed to be owned by old autofs5 - default/autofs, but it turned out that each file has to be handled separately, which is now implemented. This all is a result of a bugfix in 5.0.6-3, when I stopped transferring ucf-ownership forcible but started doing it conditionally, only of previously ownership belonged to autofs5. That was a bugfix without a separate BTS entry. Initial issue is that I do not want to transfer ownership of these files if they currently belong to some other package, if that's _ever_ possible, so using --force unconditionally does not look sane. Maybe I'm wrong here and always using --force for ucf file registration is okay, but the current version look more or less robust anyway. The small debdiff between 5.0.7-1 and 5.0.7-2 follows. Please consider unblocking the package. unblock autofs/5.0.7-2 Thank you for your time! /mjt diff -Nru autofs-5.0.7/debian/autofs.postinst autofs-5.0.7/debian/autofs.postinst --- autofs-5.0.7/debian/autofs.postinst 2012-09-03 08:52:07.0 +0400 +++ autofs-5.0.7/debian/autofs.postinst 2012-10-06 13:00:26.0 +0400 @@ -2,17 +2,15 @@ set -e if [ $1 = configure ]; then - # transfer ownership from old autofs5 package - case $(ucfq -w /etc/default/autofs) in -*:autofs5:*) force=--force ;; -*) force= ;; - esac - for map in master net misc smb; do -ucfr $force autofs /etc/auto.$map -ucf /usr/share/autofs/conffiles/auto.$map /etc/auto.$map + for file in auto.master auto.net auto.misc auto.smb default/autofs; do +# transfer ownership from old autofs5 package +case `ucfq -w /etc/$file` in + *:autofs5:*) force=--force ;; + *) force= ;; +esac +ucfr $force autofs /etc/$file +ucf /usr/share/autofs/conffiles/$file /etc/$file done - ucfr $force autofs /etc/default/autofs - ucf /usr/share/autofs/conffiles/default/autofs /etc/default/autofs fi # In version 5.0.6 (wheezy), the package has been renamed diff -Nru autofs-5.0.7/debian/changelog autofs-5.0.7/debian/changelog --- autofs-5.0.7/debian/changelog 2012-09-26 21:15:05.0 +0400 +++ autofs-5.0.7/debian/changelog 2012-10-06 13:06:37.0 +0400 @@ -1,3 +1,10 @@ +autofs (5.0.7-2) unstable; urgency=low + + * force transfer ucf autofs5=autofs ownership for all ucf-managed +files (Closes: #689747) + + -- Michael Tokarev m...@tls.msk.ru Sat, 06 Oct 2012 13:06:37 +0400 + autofs (5.0.7-1) unstable; urgency=low * new upstream (5.0.7) release. It brings the following changes: -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/506ff95d.1090...@msgid.tls.msk.ru
Bug#684355: unblock: autofs/5.0.6-3
Control: retitle -1 unblock: autofs/5.0.7-1 Please unblock package autofs There are a few relatively small changes fixing some bugs and making the package more accurate. Also, per request from the previous maintainer, debian/control is changed to list new maintainer address - this is important change by its own. I uploaded the package into unstable, adding a few more changes on the way - manpage hyphen fix and usage of hardening flags. The new debdiff is attached. We reviewed remaining upstream changes between 5.0.6 and 5.0.7 releases (debian 5.0.6-2+ package was based on a middle of 5.0.7 upstream release) and realized that all changes in 5.0.7 and even PAST 5.0.7 are bugfixes, and many are important as well. So we went on and packaged upstream release 5.0.7 plus almost all past-5.0.7 changes from upstream git. Since the amount of bugs in autofs is really huge, any bugfixing is important, that's why we decided to package 5.0.7 to start with. Complete debdiff between 5.0.6-2 which is currently in wheezy and proposed 5.0.7-1 is large: 72 files changed, 3611 insertions(+), 7322 deletions(-) but this is because we initially included half of the upstream git changes past 5.0.6, debian/patches/autofs-5.0.6-upstream-git.patch, which was 6015 lines long, and with all that now is within various files in orig.tar.gz. Actual differences between upstream 5.0.7 and debian 5.0.6+ is this: 31 files changed, 744 insertions(+), 574 deletions(-) this since commit 09d4edb2469f9415f6ca33760d83b3c85b517de7, autofs-5.0.6 - fix libtirpc name clash: http://git.kernel.org/?p=linux/storage/autofs/autofs.git;a=shortlog in there, basically, all changes between 2012-06-28 (by Leonardo Chiquitto) and up to release_5_0_7 tag. We also included 4 out of 5 fixes past 5.0.7 in there - omitting a larger, ipv6-related change fix ipv6 proximity calculation, which has some breaking potential. Here's the changelog since 5.0.6-2 (wheezy) version: autofs (5.0.7-1) unstable; urgency=low * new upstream (5.0.7) release. It brings the following changes: - fixed remount deadlock, and several other locking fixes - fixed umount recovery for busy direct mounts - removed old code (mount-move which was fixed in 5.0.6-4 #686438) - fix hosts lookup module to be more robust - implemented abilty to re-read indirect maps on the fly (sighup) - fixes for nfs handling to be more robust - several fixes for multi-mount entries - several fixes for NFSv4 mounts (Closes: #675798) and a few more small/misc fixes. This is all-bugfix changes, making the code more robust and less buggy. * removed --disable-mount-move configure option, not needed anymore. * removed autofs-5.0.6-upstream-git.patch. * refreshed manpages-hyphen.patch. * added selected fixes from upstream git, up to upstream/master commit 9872cdbf9f1588174121e6ffe6f7509cde2d98e9: - 0001-autofs-5.0.7-fix-nobind-sun-escaped-map-entries.patch (Closes: #678408) - 0002-autofs-5.0.7-fix-use-cache-entry-after-free-mistake.patch - 0004-autofs-5.0.7-fix-parse-buffer-initialization.patch - 0005-autofs-5.0.7-fix-typo-in-automount-8.patch * added remove-kernel-mount.nfs-version-check.patch to stop automount from checking for very old mount.nfs or kernel. The check isn't necessary (that's pre-squeeze versions, so not even versioned Breaks are needed anymore), but it is also harmful, since automount spawns mount.nfs at startup and confuses upstart and systemd who start tracking wrong process. The patch just removes these checks assuming we always use recent enough versions. (Closes: #678555) -- Michael Tokarev m...@tls.msk.ru Wed, 26 Sep 2012 21:15:05 +0400 autofs (5.0.6-4) unstable; urgency=low * configure with --disable-mount-move -- upstream even removed the code in question for 5.0.7 release (Closes: #686438) * remove autofs5.postrm in autofs.postinst to cope with old maintscript removing our configfiles. See comments in autofs.postinst for more details (Closes: #686146) * added allow-nsswitch.conf-to-not-contain-automount-lines.patch (submitted to upstream too) to stop automount from complaining when nsswitch.conf does not mention autofs (which is almost every install anyway). (Closes: #682266, #602090) -- Michael Tokarev m...@tls.msk.ru Sat, 22 Sep 2012 13:07:46 +0400 autofs (5.0.6-3) unstable; urgency=low [Michael Tokarev] * almost completely rewrote the startup script, make it cleaner, consistent and actually returning proper exit codes. Removed $ constructs too, dash apparently does not understand these. (Closes: #677520, #683936) * transfer ownership of ucf-conffiles forcibly only if they're owned by autofs5, not by any other package. * run ucf --purge in postrm only if it is installed, and in the right order too (Closes: #685468) * added filagdir.patch - fix a typo in configure.in which prevents from
Bug#684355: unblock: autofs/5.0.6-3
On 26.09.2012 23:49, Michael Tokarev wrote:
[]
Debdiff between wheezy and sid version will be sent in a separate
email, since it is large. The same but without upstream changes
(which are easily visible in the git tree referenced above) and
the removal of half-5.0.7 upstream diff from debian/patches is
below. The diffstat for this short version:
16 files changed, 489 insertions(+), 86 deletions(-)
And ofcource I forgot to add the debdiff. Attached now.
/mjt
diff -Nru autofs-5.0.6/debian/autofs.init autofs-5.0.7/debian/autofs.init
--- autofs-5.0.6/debian/autofs.init 2012-06-01 16:12:48.0 +0400
+++ autofs-5.0.7/debian/autofs.init 2012-06-07 23:41:38.0 +0400
@@ -1,7 +1,5 @@
#! /bin/sh
#
-# rc file for automount using a Sun-style master map.
-#
### BEGIN INIT INFO
# Provides: autofs
@@ -17,11 +15,10 @@
# Location of the automount daemon and the init directory
#
-DAEMON=/usr/sbin/automount
-prog=`basename $DAEMON`
-DEVICE=autofs
-NAME=autofs
-PIDFILE=/var/run/${NAME}.pid
+PROG=automount
+DAEMON=/usr/sbin/$PROG
+NAME=autofs
+PIDFILE=/run/$NAME.pid
test -e $DAEMON || exit 0
@@ -37,103 +34,78 @@
. /etc/default/autofs
fi
+start_stop_autofs() {
+ start-stop-daemon $@ --pidfile $PIDFILE --exec $DAEMON -- \
+ $OPTIONS --pid-file $PIDFILE
+}
+
start() {
- log_action_begin_msg Starting $prog $prog
+ log_action_begin_msg Starting $PROG
- # Make sure autofs4 module is loaded
- if ! grep -q autofs /proc/filesystems
+ if ! grep -qw autofs /proc/filesystems
then
- # Try load the autofs4 module fail if we can't
- modprobe autofs4 /dev/null 21
- if [ $? -eq 1 ]
+ if ! modprobe autofs4 /dev/null 21
then
log_action_end_msg 1 failed to load autofs4 module
return 1
fi
elif [ -f /proc/modules ] grep -q ^autofs[^4] /proc/modules
then
- # wrong autofs filesystem module loaded
log_action_end_msg 1 autofs kernel module is loaded, autofs4
required
return 1
fi
- start-stop-daemon --start --exec $DAEMON --oknodo -- $OPTIONS
--pid-file $PIDFILE
- RETVAL=$?
- if [ $RETVAL -eq 0 ] ; then
- log_end_msg 0
- else
+ if ! start_stop_autofs --start --oknodo --quiet ; then
log_action_end_msg 1 no valid automount entries defined.
+ return 1
fi
+ log_end_msg 0
return 0
}
stop() {
- log_action_begin_msg $Stopping $prog:
- count=0
- while [ -n `pidof $prog` -a $count -lt 15 ] ; do
- start-stop-daemon --stop --exec $DAEMON --oknodo
- [ -z `pidof $prog` ] || sleep 3
- count=`expr $count + 1`
- done
- if [ -z `pidof $prog` ] ; then
- RETVAL=0
- log_action_end_msg 0
- else
- RETVAL=1
+ log_action_begin_msg Stopping $PROG
+ if ! start_stop_autofs --stop --retry 5 --oknodo --quiet ; then
log_action_end_msg 1
+ return 1
fi
- return $RETVAL
-}
-
-restart() {
- stop
- start
+ log_end_msg 0
+ return 0
}
reload() {
- pid=`pidof $prog`
- if [ -z $pid ]; then
- log_action_msg $$prog not running
- RETVAL=1
- else
- kill -HUP $pid 2 /dev/null
- log_action_msg $Reloading maps
- RETVAL=0
+ log_action_begin_msg Reloading $PROG maps
+ if ! start_stop_autofs --stop --signal=HUP --quiet
+ then
+ log_action_end_msg 1 $PROG not running
+ return 1
fi
- return $RETVAL
+ log_action_end_msg 0
+ return 0
}
-RETVAL=0
+forcestart() {
+ OPTIONS=$OPTIONS --force
+ start
+}
case $1 in
- start)
- start
- ;;
- forcestart)
- OPTIONS=$OPTIONS --force
- start
- ;;
- stop)
- stop
+ start|forcestart|stop|reload)
+ $1
;;
restart|force-reload)
- restart
+ stop
+ start
;;
forcerestart)
- OPTIONS=$OPTIONS --force
- restart
- ;;
- reload)
- reload
+ stop
+ forcestart
;;
status)
- status_of_proc -p $PIDFILE $DAEMON $prog
+ status_of_proc -p $PIDFILE $DAEMON $PROG
;;
*)
- echo $Usage: $0
{start|forcestart|stop|restart|forcerestart|reload|force-reload|status}
- exit 1;
+ echo Usage: $0
{start|forcestart|stop|restart|forcerestart|reload|force-reload|status}
+ exit 1
