Bug#1029121: bullseye-pu: package lxc/4.0.6-2+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-lxc-de...@lists.alioth.debian.org, gib...@debian.org
Control: affects -1 + src:lxc
[ Reason ]
The version of lxc in bullseye is affected by the low-severity
CVE-2022-47952 which was fixed in the recent release of lxc 5.0.2
(uploaded to unstable yesterday). As the fix was trivial to apply to
the version of lxc in bullseye, I think it would be beneficial to
include it in the next point release.
[ Impact ]
Affected versions of lxc suffer a minor information leak which allows a
local user to infer whether any file exists, even within a protected
directory tree.
[ Tests ]
A manual proof-of-concept test is provided in the upstream commit
fixing this issue.
[ Risks ]
There are no changes to any of the logic of lxc; the error messages
which are returned are modified to be identical in every error case,
preventing the information leak.
[ 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
[ Changes ]
Backport upstream commit 1b0469530d7a38b8f8990e114b52530d1bf7f3b8,
which fixes CVE-2022-47952. (The line numbers in the diff shifted
slightly, otherwise no changes to the patch.)
[ Other info ]
The source debdiff is attached.
diff -Nru lxc-4.0.6/debian/changelog lxc-4.0.6/debian/changelog
--- lxc-4.0.6/debian/changelog 2022-01-13 19:57:39.0 +
+++ lxc-4.0.6/debian/changelog 2023-01-18 02:53:46.0 +
@@ -1,3 +1,9 @@
+lxc (1:4.0.6-2+deb11u2) bullseye; urgency=medium
+
+ * Backport fix for CVE-2022-47952
+
+ -- Mathias Gibbens Wed, 18 Jan 2023 02:53:46 +
+
lxc (1:4.0.6-2+deb11u1) bullseye; urgency=medium
* lxc-download: Switch GPG server.
diff -Nru lxc-4.0.6/debian/patches/fix-CVE-2022-47952.patch lxc-4.0.6/debian/patches/fix-CVE-2022-47952.patch
--- lxc-4.0.6/debian/patches/fix-CVE-2022-47952.patch 1970-01-01 00:00:00.0 +
+++ lxc-4.0.6/debian/patches/fix-CVE-2022-47952.patch 2023-01-18 02:53:23.0 +
@@ -0,0 +1,69 @@
+From 1b0469530d7a38b8f8990e114b52530d1bf7f3b8 Mon Sep 17 00:00:00 2001
+From: Maher Azzouzi
+Date: Sun, 25 Dec 2022 13:50:25 +0100
+Subject: [PATCH] Patching an incoming CVE (CVE-2022-47952)
+
+lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may
+allow local users to infer whether any file exists, even within a
+protected directory tree, because "Failed to open" often indicates
+that a file does not exist, whereas "does not refer to a network
+namespace path" often indicates that a file exists. NOTE: this is
+different from CVE-2018-6556 because the CVE-2018-6556 fix design was
+based on the premise that "we will report back to the user that the
+open() failed but the user has no way of knowing why it failed";
+however, in many realistic cases, there are no plausible reasons for
+failing except that the file does not exist.
+
+PoC:
+> % ls /l
+> ls: cannot open directory '/l': Permission denied
+> % /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic delete lol lol /l/h/tt h h
+> cmd/lxc_user_nic.c: 1096: main: Failed to open "/l/h/tt" <- file does not exist.
+> % /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic delete lol lol /l/h/t h h
+> cmd/lxc_user_nic.c: 1101: main: Path "/l/h/t" does not refer to a network namespace path < file exist!
+
+Signed-off-by: MaherAzzouzi
+Acked-by: Serge Hallyn
+---
+ src/lxc/cmd/lxc_user_nic.c | 15 ++-
+ 1 file changed, 6 insertions(+), 9 deletions(-)
+
+diff --git a/src/lxc/cmd/lxc_user_nic.c b/src/lxc/cmd/lxc_user_nic.c
+index a91e2259d5..69bc6f17d1 100644
+--- a/src/lxc/cmd/lxc_user_nic.c
b/src/lxc/cmd/lxc_user_nic.c
+@@ -1088,20 +1088,17 @@ int main(int argc, char *argv[])
+ } else if (request == LXC_USERNIC_DELETE) {
+ char opath[LXC_PROC_PID_FD_LEN];
+
+- /* Open the path with O_PATH which will not trigger an actual
+- * open(). Don't report an errno to the caller to not leak
+- * information whether the path exists or not.
+- * When stracing setuid is stripped so this is not a concern
+- * either.
+- */
++ // Keep in mind CVE-2022-47952: It's crucial not to leak any
++ // information whether open() succeeded of failed.
++
+ netns_fd = open(args.pid, O_PATH | O_CLOEXEC);
+ if (netns_fd < 0) {
+- usernic_error("Failed to open \"%s\"\n", args.pid);
++ usernic_error("Failed while opening netns file for \"%s\"\n", args.pid);
+ _exit(EXIT_FAILURE);
+ }
+
+ if (!fhas_fs_type(netns_fd, NSFS_MAGIC)) {
+- usernic_error("Path \"%s\" does not refer to a network namespace path\n", args.pid);
++ usernic_error("Failed while opening netns file for \"%s\"\n", args.pid);
+ close(
Bug#1035564: unblock: lxd/5.0.2-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:lxd
Please unblock package lxd
[ Reason ]
Added a missing Replaces in d/control for bin:lxd-client to address an
upgrade edge case from bullseye where lxc was already installed and
some other package being upgraded Depends/Recommends lxd which could
potentially result in a dpkg error (see #1034971).
lxd has autopkgtests, but as we're now within 20 days of the full
freeze, a manual unblock is required.
[ Impact ]
There's a chance that an upgrade from bullseye to bookworm might fail.
Additionally, this upload of lxd to unstable reset the migration
counter before lxd 5.0.2-4 was able to migrate with a fix for running
with the version of qemu in testing.
[ Tests ]
I manually tested installing lxd-client on a bullseye system with lxc
installed:
> Preparing to unpack lxd-client_5.0.2-3_amd64.deb ...
> Unpacking lxd-client (5.0.2-3) ...
> dpkg: error processing archive lxd-client_5.0.2-3_amd64.deb (--install):
> trying to overwrite '/usr/share/bash-completion/completions/lxc', which is
> also in package lxc 1:4.0.6-2+deb11u2
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
With the fix:
> Preparing to unpack .../lxd-client_5.0.2-5_amd64.deb ...
> Unpacking lxd-client (5.0.2-5) ...
> Replacing files in old package lxc (1:4.0.6-2+deb11u2) ...
[ Risks ]
I don't believe there are any risks with this change.
[ 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 ]
As mentioned, lxd 5.0.2-4 had been on track to automatically migrate
around May 14 with a fix for use with the version of qemu in testing
(see #1030365). Since the requested debdiff is against the version of
lxd in testing, it contains changes from both -4 and -5.
unblock lxd/5.0.2-5
diff -Nru lxd-5.0.2/debian/changelog lxd-5.0.2/debian/changelog
--- lxd-5.0.2/debian/changelog 2023-03-08 02:27:33.0 +
+++ lxd-5.0.2/debian/changelog 2023-05-05 12:42:21.0 +
@@ -1,3 +1,16 @@
+lxd (5.0.2-5) unstable; urgency=medium
+
+ * Add missing Replaces in d/control for lxd-client to fix potential bullseye
+upgrade issue (Closes: #1034971)
+
+ -- Mathias Gibbens Fri, 05 May 2023 12:42:21 +
+
+lxd (5.0.2-4) unstable; urgency=medium
+
+ * Cherry-pick upstream fix for qemu >= 7.2 (Closes: #1030365)
+
+ -- Mathias Gibbens Sun, 23 Apr 2023 17:50:08 +
+
lxd (5.0.2-3) unstable; urgency=medium
* Cherry-pick upstream commit to fix issue with btrfs-progs >= 6.0
diff -Nru lxd-5.0.2/debian/control lxd-5.0.2/debian/control
--- lxd-5.0.2/debian/control 2023-03-08 02:27:33.0 +
+++ lxd-5.0.2/debian/control 2023-05-05 12:42:21.0 +
@@ -99,8 +99,9 @@
Package: lxd-client
# The lxc binary doesn't depend on liblxc1, so it can be built for any architecture
Architecture: any
-# lxc prior to 5.0.0 shipped a file that conflicts with LXD (see #1010843)
-Breaks: lxc (<< 1:5.0.0)
+# lxc prior to 5.0.1 shipped a file that conflicts with LXD (see #1010843, #1034971)
+Breaks: lxc (<< 1:5.0.1)
+Replaces: lxc (<< 1:5.0.1)
Depends: ${misc:Depends},
${shlibs:Depends}
Built-Using: ${misc:Built-Using}
diff -Nru lxd-5.0.2/debian/patches/006-cherry-pick-btrfs-fix.patch lxd-5.0.2/debian/patches/006-cherry-pick-btrfs-fix.patch
--- lxd-5.0.2/debian/patches/006-cherry-pick-btrfs-fix.patch 2023-03-08 02:27:33.0 +
+++ lxd-5.0.2/debian/patches/006-cherry-pick-btrfs-fix.patch 2023-05-05 12:42:21.0 +
@@ -1,3 +1,6 @@
+From: Mathias Gibbens
+Description: Cherry-pick upstream commit to fix issue with btrfs-progs >= 6.0
+Origin: https://github.com/lxc/lxd/pull/11333
From e7c852e43c0479060e630adb50342d2552a6cdad Mon Sep 17 00:00:00 2001
From: Thomas Parrott
Date: Tue, 7 Feb 2023 10:04:27 +
diff -Nru lxd-5.0.2/debian/patches/007-cherry-pick-qemu-fix.patch lxd-5.0.2/debian/patches/007-cherry-pick-qemu-fix.patch
--- lxd-5.0.2/debian/patches/007-cherry-pick-qemu-fix.patch 1970-01-01 00:00:00.0 +
+++ lxd-5.0.2/debian/patches/007-cherry-pick-qemu-fix.patch 2023-05-05 12:42:21.0 +
@@ -0,0 +1,90 @@
+From: Mathias Gibbens
+Description: Cherry-pick upstream fix for qemu >= 7.2, rebase, and drop SEV features not in current LTS release
+Origin: https://github.com/lxc/lxd/pull/11594
+diff --git a/lxd/instance/drivers/driver_qemu.go b/lxd/instance/drivers/driver_qemu.go
+index 9dcdd9da7..08211b034 100644
+--- a/lxd/instance/drivers/driver_qemu.go
b/lxd/instance/drivers/driver_qemu.go
+@@ -2878,17 +2878,11 @@ func (d *qemu) generateQemuConfigFile(mountInfo *storagePools.MountInfo, busName
+ // addCPUMemoryConfig adds the qemu config required for setting the number of virtualised CPUs and memory.
+ // If sb is nil
Re: Bug#1050256: autopkgtest fails on debci
Control: block 1038315 by -1 Control: block 1042880 by -1 I don't think we have a good understanding of the root cause of this issue. Initially we thought this was a known upstream issue with all- but very recent versions of apparmor and a corresponding lxc profile fix [0]. However, it appears this is a different issue that somehow depends on the interaction of bookworm's versions of the kernel, apparmor, and/or lxc. A minimal reproducer is to install bookworm and create a container with a systemd service using a hardening option like PrivateNetwork=yes. With the latest bookworm kernel (6.1.38-4), the service will fail. But, grab a kernel from testing (6.4.11-1) and then things work -- with no other changes required. I tried the "oldest" kernel on snapshot.d.o post 6.1 series (6.3.1+1~exp1 [1]) and the service works properly with that version as well. So, something changed in the kernel (either upstream or in Debian's packaging) between 6.1 and 6.3 that "unbreaks" services within lxc containers. Given that simply installing a newer kernel fixes things, I am hesitant to start making changes to lxc until we actually understand what's changed when running the newer kernel and how it's affecting lxc's behavior. On Thu, 2023-08-31 at 19:54 +0200, Christian Boltz wrote: > That said - the DENIED log entry translates to > > unix send type=dgram, > > You could try if adding this rule to the lxc-autopkgtest-lxc-iomhit_* > profile helps - but if the issue is really on the kernel side, my > hope is limited). I have tried tweaking the apparmor profile that's generated for containers (the relevant part is defined in the variable AA_PROFILE_UNIX_SOCKETS in src/lxc/lsm/apparmor.c), but haven't had any success in a workaround. I am not super familiar with apparmor, so maybe I'm not specifying things right, but I've previously tried the sort of rules Christian suggested, none of which have had any affect. On Fri, 2023-09-01 at 13:23 +0200, Michael Biebl wrote: > The only way to fix the container was to use the aforementioned > `lxc.apparmor.profile = unconfined`. > I think we should do that as the breakage is rather widespread and I > already see individual packages trying to work around that to at > least keep debci afloat. I strongly dislike the idea of blanketly disabling apparmor profiles by default for all lxc installs, since apparmor is one of the ways of helping to ensure isolation of containers. For the specific instance of debci, /etc/lxc/default.conf can be modified post-lxc install to change lxc.apparmor.profile from "generated" to "unconfined" for the time being. Mathias --- [0] -- https://github.com/lxc/lxc/issues/4333 [1] -- https://snapshot.debian.org/package/linux-signed-amd64/6.3.1%2B1~exp1/ signature.asc Description: This is a digitally signed message part
Re: Bug#1050256: autopkgtest fails on debci
On Mon, 2023-09-04 at 01:00 -0700, John Johansen wrote: > I took a quick look through v6.1..v6.3.1 > > there is a patch that I think is the likely fix, it first landed in v6.2 > > 1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets Thanks for the pointer John -- I think that is the fix we've been looking for! Commit 1cf26c3d2c4c doesn't apply cleanly to the v6.1 tree due to the other commits from the patchset of Oct 3, 2022 that modified a bunch of the apparmor code. Because I couldn't quickly cherry-pick all the changes without amassing a large diff, I made the small proof-of- concept patch at the end of this message and applied it to the 6.1.38- 4 kernel from bookworm. Booting with the patched kernel allows services to start up in containers without any issues. :) So, I think the next step should be to get that commit properly backported to the v6.1 longterm tree and included in an upstream release. Hopefully that would be able to happen in enough time so that it is bundled with the kernel updates for bookworm's point release next month. If not, we should be sure to get it into Debian's packaging so at least there's a proper fix available. I'm happy to help test any proposed patch for this fix on my end. Mathias - > --- a/security/apparmor/lib.c 2023-09-04 16:08:28.818066140 + > +++ b/security/apparmor/lib.c 2023-09-04 16:09:17.56661 + > @@ -355,6 +355,9 @@ > perms->allow |= map_other(dfa_other_allow(dfa, state)); > perms->audit |= map_other(dfa_other_audit(dfa, state)); > perms->quiet |= map_other(dfa_other_quiet(dfa, state)); > + > + // For testing only! > + perms->allow |= AA_MAY_LOCK; > } > > /** signature.asc Description: This is a digitally signed message part
Re: Bug#1050256: autopkgtest fails on debci
On Mon, 2023-09-04 at 12:39 -0700, John Johansen wrote: > On 9/4/23 12:32, Michael Biebl wrote: > > John, could you help with getting this fix into 6.1.x? > > yes, I am working on a patch. Hi John, I wanted to check in to see if you've had a chance to work on that patch for the 6.1 kernel. The deadline for package updates being included in the 12.2 point release is in roughly two weeks, but given this will be a patch for the kernel I'd really like to have something tested and handed over to the src:linux team well before then. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Re: Bug#1050256: autopkgtest fails on debci
On Mon, 2023-09-11 at 13:45 +0200, Michael Biebl wrote: > Am 09.09.23 um 14:20 schrieb intrigeri: > > > At this stage it seems clear that the bug and the corresponding > > ideal fix are in the AppArmor part of src:linux, and the bug > > affects at least src:apparmor and src:lxc. I'd like to reflect this > > in the metadata of #1050256 by reassigning the bug to Linux, and > > adding "affects" indications. I'll do so in the next few days > > unless someone objects soon. > > It also affects at least > src:systemd, src:pdns, src:policykit-1 > All those packages have added workarounds for this issue. > I'll revert the workaround in systemd and notify the maintainers of > pdns and policykit-1. > > > Doing so will also be an opportunity for me to sum up the problem > > for the maintainers of src:linux, and let them know about our > > desired timeline: ideally this would be fixed in the upcoming > > Bookworm point-release. Not having heard any objections, please feel free to reassign this bug. As you said, this will give the src:linux maintainers a heads up, even if the patch isn't quite ready yet (but hopefully in time for the 12.2 point release). Mathias signature.asc Description: This is a digitally signed message part
Bug#1052007: bookworm-pu: package lxcfs/5.0.3-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-lxc-de...@lists.alioth.debian.org, gib...@debian.org
Control: affects -1 + src:lxcfs
[ Reason ]
lxcfs 5.0.3-1 has a bug where /proc/cpuinfo is not properly reported
within a 32bit arm container when the 64bit host has more than ~13
CPUs. This was initially reported in #1036818 and impacts some
autopkgtests run on the ci.debian.net arm hosts.
I have uploaded lxcfs 5.0.4-1 to unstable with a fix cherry-picked from
the upstream main branch, and would like to include it in bookworm's
version of lxcfs so that the CI arm servers can operate properly.
[ Impact ]
autopkgtests run on the CI infrastructure have been erroneously failing
for some packages, requiring workarounds. Fixing this will allow
autopkgtests for armel/armhf runs to be useful once again.
[ Tests ]
I have tested the patch locally in a QEMU VM, both when initially
debugging the issue as well as installing the proposed update. The
changes have been reviewed and accepted by the upstream developers.
[ Risks ]
The risk of regression is limited -- the changes have been reviewed and
accepted by the upstream developers. The fix is small and targeted.
[ 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
[ Changes ]
Backport upstream commit fc8f593bda9eb4692daa07512ef6ba60dc39aded,
which was merged upstream earlier today and will be included in the
next release of lxcfs. There's also a small change to adjust the
default branch used by gbp to reflect the new branch for bookworm
fixes.
[ Other info ]
The source debdiff is attached.
diff -Nru lxcfs-5.0.3/debian/changelog lxcfs-5.0.3/debian/changelog
--- lxcfs-5.0.3/debian/changelog 2023-01-17 01:21:28.0 +
+++ lxcfs-5.0.3/debian/changelog 2023-09-15 21:32:11.0 +
@@ -1,3 +1,11 @@
+lxcfs (5.0.3-1+deb12u1) bookworm; urgency=medium
+
+ * Cherry-pick upstream fix for /proc/cpuinfo being empty within an arm32
+container with large numbers of CPUs (See: #1036818)
+ * Adjust branch in d/gbp.conf
+
+ -- Mathias Gibbens Fri, 15 Sep 2023 21:32:11 +
+
lxcfs (5.0.3-1) unstable; urgency=medium
[ Mathias Gibbens ]
diff -Nru lxcfs-5.0.3/debian/gbp.conf lxcfs-5.0.3/debian/gbp.conf
--- lxcfs-5.0.3/debian/gbp.conf 2023-01-17 01:21:28.0 +
+++ lxcfs-5.0.3/debian/gbp.conf 2023-09-15 21:32:07.0 +
@@ -1,3 +1,3 @@
[DEFAULT]
pristine-tar = True
-debian-branch = master
+debian-branch = debian/bookworm
diff -Nru lxcfs-5.0.3/debian/patches/000-fix-arm32-personality.patch lxcfs-5.0.3/debian/patches/000-fix-arm32-personality.patch
--- lxcfs-5.0.3/debian/patches/000-fix-arm32-personality.patch 1970-01-01 00:00:00.0 +
+++ lxcfs-5.0.3/debian/patches/000-fix-arm32-personality.patch 2023-09-15 21:32:07.0 +
@@ -0,0 +1,88 @@
+From fc8f593bda9eb4692daa07512ef6ba60dc39aded Mon Sep 17 00:00:00 2001
+From: Mathias Gibbens
+Date: Mon, 4 Sep 2023 00:13:57 +
+Subject: [PATCH] proc: Fix /proc/cpuinfo not respecting personality
+
+It was found that the personality within the container was not being
+properly respected, which for large numbers of CPUs would break
+reporting of /proc/cpuinfo in arm32 containers running on an arm64 host.
+
+Signed-off-by: Mathias Gibbens
+---
+ src/proc_fuse.c | 49 +++--
+ 1 file changed, 47 insertions(+), 2 deletions(-)
+
+diff --git a/src/proc_fuse.c b/src/proc_fuse.c
+index 25af10a1..40eb2680 100644
+--- a/src/proc_fuse.c
b/src/proc_fuse.c
+@@ -82,6 +82,45 @@ static off_t get_procfile_size(const char *path)
+ return answer;
+ }
+
++static off_t get_procfile_size_with_personality(const char *path)
++{
++ struct fuse_context *fc = fuse_get_context();
++ __u32 host_personality = liblxcfs_personality(), caller_personality;
++ bool change_personality;
++ int ret;
++ off_t procfile_size_ret;
++
++ if (get_task_personality(fc->pid, &caller_personality) < 0)
++ return log_error(0, "Failed to get caller process (pid: %d) personality", fc->pid);
++
++ /* do we need to change thread personality? */
++ change_personality = host_personality != caller_personality;
++
++ if (change_personality) {
++ ret = personality(caller_personality);
++ if (ret == -1)
++ return log_error(0, "Call to personality(%d) failed: %s\n",
++ caller_personality, strerror(errno));
++
++ lxcfs_debug("task (tid: %d) personality was changed %d -> %d\n",
++(int)syscall(SYS_gettid), ret, caller_personality);
++ }
++
++ procfile_size_ret = get_procfile_size(path);
++
++ if (change_personality) {
++ ret = personality(host_personality);
++ if (ret == -1)
++ return log_error(0, "Call to personality(%d) failed: %s\n",
++ hos
Bug#1052479: bookworm-pu: package lxc/1:5.0.2-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-lxc-de...@lists.alioth.debian.org, gib...@debian.org
Control: affects -1 + src:lxc
[ Reason ]
lxc 1:5.0.2-1 contains a typo in its IPv6 NAT rules, as reported in
#1049976. This prevents the lxc-net service from starting if
LXC_IPV6_NAT is set to true.
This was fixed in lxc version 5.0.3, which I have recently uploaded to
unstable. I would like to include this fix in bookworm's version of lxc
as it's a trivial fix affecting an actual Debian user.
[ Impact ]
IPv6 NAT is broken in bookworm's current version of lxc.
[ Tests ]
The changes have been reviewed and accepted by the upstream developers.
[ Risks ]
No risks -- a simple typo fix that has been fixed upstream since
February.
[ 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
[ Changes ]
Backport upstream commit 4de047f51365cc06a626ee9de49fec5f76556c66,
which was included in lxc version 5.0.3. There's also a small change to
adjust the default branch used by gbp to reflect the new branch for
bookworm fixes.
[ Other info ]
The source debdiff is attached.
diff -Nru lxc-5.0.2/debian/changelog lxc-5.0.2/debian/changelog
--- lxc-5.0.2/debian/changelog 2023-01-17 02:53:00.0 +
+++ lxc-5.0.2/debian/changelog 2023-09-22 16:35:52.0 +
@@ -1,3 +1,10 @@
+lxc (1:5.0.2-1+deb12u1) bookworm; urgency=medium
+
+ * Cherry-pick upstream "fix nftables syntax for IPv6 NAT" (Closes: #1049976)
+ * Adjust branch in d/gbp.conf
+
+ -- Mathias Gibbens Fri, 22 Sep 2023 16:35:52 +
+
lxc (1:5.0.2-1) unstable; urgency=medium
* New upstream release
diff -Nru lxc-5.0.2/debian/gbp.conf lxc-5.0.2/debian/gbp.conf
--- lxc-5.0.2/debian/gbp.conf 2023-01-17 02:53:00.0 +
+++ lxc-5.0.2/debian/gbp.conf 2023-09-22 16:35:47.0 +
@@ -1,3 +1,3 @@
[DEFAULT]
pristine-tar = True
-debian-branch = master
+debian-branch = debian/bookworm
diff -Nru lxc-5.0.2/debian/patches/0100-fix-nftables-ipv6.patch lxc-5.0.2/debian/patches/0100-fix-nftables-ipv6.patch
--- lxc-5.0.2/debian/patches/0100-fix-nftables-ipv6.patch 1970-01-01 00:00:00.0 +
+++ lxc-5.0.2/debian/patches/0100-fix-nftables-ipv6.patch 2023-09-22 16:35:47.0 +
@@ -0,0 +1,34 @@
+From 4de047f51365cc06a626ee9de49fec5f76556c66 Mon Sep 17 00:00:00 2001
+From: Quentin Lyons <36303164+n0...@users.noreply.github.com>
+Date: Sun, 12 Feb 2023 02:03:42 +
+Subject: [PATCH] lxc-net.in: fix nftables syntax for IPv6 NAT
+
+The nftables masquarade rule for IPv6 was using the IPv4 syntax. This
+resulted in the following error when starting the lxc-net.service with
+LXC_IPV6_NAT="true" and nftables:
+
+Feb 11 18:54:54 pc lxc-net[4936]: Error: conflicting protocols specified: ip6 vs. ip
+Feb 11 18:54:54 pc lxc-net[4936]:
+Feb 11 18:54:54 pc lxc-net[4917]: Failed to setup lxc-net.
+Feb 11 18:54:54 pc systemd[1]: lxc-net.service: Main process exited, code=exited, status=1/FAILURE
+Feb 11 18:54:54 pc systemd[1]: lxc-net.service: Failed with result 'exit-code'.
+Feb 11 18:54:54 pc systemd[1]: Failed to start LXC network bridge setup.
+
+Signed-off-by: Quentin Lyons <36303164+n0...@users.noreply.github.com>
+---
+ config/init/common/lxc-net.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/config/init/common/lxc-net.in b/config/init/common/lxc-net.in
+index efee9b96f0..e9ab88890a 100755
+--- a/config/init/common/lxc-net.in
b/config/init/common/lxc-net.in
+@@ -92,7 +92,7 @@ start_nftables() {
+ add table ip6 lxc;
+ flush table ip6 lxc;
+ add chain ip6 lxc postrouting { type nat hook postrouting priority 100; };
+-add rule ip6 lxc postrouting ip saddr ${LXC_IPV6_NETWORK} ip daddr != ${LXC_IPV6_NETWORK} counter masquerade;
++add rule ip6 lxc postrouting ip6 saddr ${LXC_IPV6_NETWORK} ip6 daddr != ${LXC_IPV6_NETWORK} counter masquerade;
+ "
+ fi
+ NFT_RULESET="${NFT_RULESET};
diff -Nru lxc-5.0.2/debian/patches/series lxc-5.0.2/debian/patches/series
--- lxc-5.0.2/debian/patches/series 2023-01-17 02:53:00.0 +
+++ lxc-5.0.2/debian/patches/series 2023-09-22 16:35:47.0 +
@@ -1,3 +1,4 @@
0004-apparmor.d-Sets-container-base-accordingly-to-container-base.in.patch
0005-lxc.service-Starts-after-remote-fs.target.patch
0004-nesting-Extend-mount-permissions-in-apparmor-to-allo.patch
+0100-fix-nftables-ipv6.patch
signature.asc
Description: This is a digitally signed message part
Bug#1052007: bookworm-pu: package lxcfs/5.0.3-1+deb12u1
On Sat, 2023-09-23 at 20:36 +0100, Adam D. Barratt wrote: > Please go ahead. Uploaded, thanks! Mathias signature.asc Description: This is a digitally signed message part
Bug#1052479: bookworm-pu: package lxc/1:5.0.2-1+deb12u1
On Sat, 2023-09-23 at 21:29 +0100, Adam D. Barratt wrote: > > Please go ahead. Uploaded, thanks! Mathias signature.asc Description: This is a digitally signed message part
Re: Coordingating/planning various golang transitions
On Sat, 2024-07-13 at 12:53 -0400, Reinhard Tartler wrote: > Hi, > > We currently ship docker version 20.10 in Debian oldstable, stable and > currently testing. This is an EOL version that I really don't think Debian > trixie should be shipping with. > > I've been working over the last couple of weeks (months?) on updating > podman and docker to recent versions, including: > > docker.io -> 26.1 > containerd -> 1.7 > podman -> 5 > > All of these packages are built successfully in experimental and I have > received test reports that they appear to work fine. So let's get them into > unstable/testing! > > While doing so, I've encountered that those new versions really require > updated versions of golang-grpc and protobuf. I've been looking at that set > of packages last month, see the thread starting at [1]. The situation is > not pretty. [snip] > Unfortunately, I won't be able to make it to Busan this year. It would be > amazing if these transitions could be discussed in person and a plan could > be devised that would end with trixie shipping a modern version of docker > and related packages. I will be attending DebCamp and DebConf, and during those couple of weeks can spend some focused time helping get these newer versions into unstable. Especially with Reinhard staging a lot of this in experimental, hopefully there won't be anything too unexpected or problematic. We're about six months out from the trixie freezes starting. I think that's more than enough time to complete these transitions and be confident adjacent dependencies haven't been accidentally broken in some manner. On Sun, 2024-07-14 at 02:37 +, weepingclown wrote: > First of all thank you for your hard work. I would like to help you > out, but am limited currently in time and my golang knowldege as a > whole. But my understanding is that the go team plans to have a bof > at the debconf this time, so probably this topic can be brought up > and hopefully you get good reinforcements. I myself will try to be > invovled depending on my availability. I don't think I've seen a Go Team BoF, but I did add a Go Team listing to the sprints wiki page: https://wiki.debian.org/DebConf/24/Sprints. Mathias signature.asc Description: This is a digitally signed message part
Re: Coordingating/planning various golang transitions
Are there any objections to starting the process of uploading packages to unstable, following the outline that Reinhard provided (quoted at the end of the message)? I'm here at DebCamp and would be happy to start working through the uploads and any other hand-holding to get the migration underway. I know we've got an item on the BoF to discuss this, but maybe by next week we could have a status update of how things are going? I've spend some time today checking things in experimental and building a few other packages against those versions, and at least from what I have testing things appear to be working OK with the newer versions. Mathias On Sat, 2024-07-13 at 20:48 -0400, Reinhard Tartler wrote: > My pitch would be to start with sourceful uploads of (and in that order): > > - golang-google-genproto > - golang-google-grpc > - golang-github-grpc-ecosystem-grpc-gateway.v2 > - golang-github-google-cel-go > - golang-opentelemetry-otel > - golang-github-googleapis-gnostic > - etcd > - golang-gogottrpc > - golang-github-containerd-btrfs > - golang-github-containerd-go-cni > - golang-github-containerd-go-runc > - golang-github-coreos-bbolt > - golang-github-google-certificate-transparency > - golang-github-lightstep-lightstep-tracer-common > - golang-github-kurin-blazer > - golang-google-cloud > - golang-github-containerd-cgroups > - golang-github-containerd-typeurl > - containerd > - golang-github-cloudflare-cfssl > - rootlesskit > - docker.io > - golang-github-fsouza-go-dockerclient > - golang-github-openshift-imagebuilder > - golang-github-containers-storage > - golang-github-containers-image > - golang-github-containers-common > - golang-github-containers-buildah > - libpod signature.asc Description: This is a digitally signed message part
Re: Coordingating/planning various golang transitions
On Thu, 2024-07-25 at 13:36 +0900, Graham Inggs wrote: > On Tue, 23 Jul 2024 at 16:38, Reinhard Tartler wrote: > > I am aware that right now we have a number of transitions going on right now > > https://release.debian.org/transitions/, however, none of them are > > obviously interfering > > with the transition I'm proposing below. Therefore it seems to me that > > now'ish might be > > a good time to start to give us enough time to deal with surprises. > > > > I have also not seen a response to my inquiry below in 10 days. I > > understand that > > at least some of you might be on vacation or traveling to Debcamp/Debconf. > > I am actively > > seeking your input, guidance, and ideally a simple "yes, the plan sounds > > agreeable and the > > risk is acceptable". In order to make this easier to track for you, I'm > > usertagging this bug > > and re-assigning this to "release.debian.org". > > > > I'm CC'ing the list of DDs who have agreed to help with triaging, fixing > > and uploading packages > > that are affected by this transition. I'm banking on the help of the whole > > golang team to > > assist with making this transition as smooth as humanly possible. > > > > I'd appreciate any kind of reply, ideally in the form of: "please hold of, > > here is a list > > of things we need to consider and/or look at first.". > > I'm not aware of anything that should block this, please go ahead. > > Feel free to update this bug if anything gets stuck migrating to testing. I will begin with uploading golang-google-genproto and golang-google- grpc to unstable shortly. Mathias signature.asc Description: This is a digitally signed message part
Migration status of golang-google-genproto
Hi, For the past ~4 days the testing excuses for golang-google-genproto has said that it would attempt migration to testing, but that hasn't happened yet. Is something else stuck, or somewhere I could look to see why it hasn't migrated yet? Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#1076109: Coordingating/planning various golang transitions
Here's an update, one week into the transition: ~35 packages have been successfully uploaded to unstable, including containerd, docker.io, etcd, and libpod. * siretart and zhsj have been working on containerd, packaging a few new dependencies and getting its autopkgtest passing again. * etcd needs some attention to its autopkgtests, I think zhsj might be looking into this * For some reason golang-google-genproto hasn't yet migrated into testing. I pinged the release team this morning to see if they can help figure out why. * golang-google-grpc needs some cleanup of DH_GOLANG_EXCLUDES in d/rules to properly exclude source files that can't compile due to other missing dependencies. (Probably can be done after this migration completes.) Getting etcd happy once again and a new upload of golang-google-grpc with an additional Breaks line should, I think, finally get a large chunk of the recently uploaded packages fully happy and able to migrate to testing. Mathias On Sat, 2024-07-13 at 12:53 -0400, Reinhard Tartler wrote: > Hi, > > We currently ship docker version 20.10 in Debian oldstable, stable and > currently testing. This is an EOL version that I really don't think Debian > trixie should be shipping with. > > I've been working over the last couple of weeks (months?) on updating > podman and docker to recent versions, including: > > docker.io -> 26.1 > containerd -> 1.7 > podman -> 5 > > All of these packages are built successfully in experimental and I have > received test reports that they appear to work fine. So let's get them into > unstable/testing! > > While doing so, I've encountered that those new versions really require > updated versions of golang-grpc and protobuf. I've been looking at that set > of packages last month, see the thread starting at [1]. The situation is > not pretty. > > My takeaway is that we need to update a large number of packages at the > same time, starting with src:golang-google-genproto > and src:golang-google-grpc. This will unblock a number of packages that are > currently in experimental, and will allow them to enter unstable. However, > this comes with the risk of breaking other packages. > > I've been chasing down the stack of dependency fairly far, but I feel I'm > reaching my capacity of how far I'm able to push this transition. I'm > therefore requesting help from the Debian release and golang teams. It is > simply not feasible for me to backtest that large amount of packages. I've > been going through that stack all the way to podman 5.0.3, and can tell > that it is feasible for us as a project. I'm asking for your expertise on > what's the best way to get this project through. > > I'd like to have these transitions coordinated so that we can minimize the > disruption for testing. Dear Release Team, please have a look at let me > know what you think. When would be a good time for me (or anyone else) to > start the transition? What kind of information would be useful for that > decision making? > > For your convenience, I believe the following listing is a good starting > set of packages to look at: > > siretart@x1:/ $ build-rdeps --distribution testing > golang-google-genproto-dev > Reverse Build-depends in testing/main: > -- > > caddy > cloudsql-proxy > containerd > crowdsec > crowdsec-custom-bouncer > crowdsec-firewall-bouncer > distrobuilder > docker-libkv > docker.io > etcd > fastnetmon > fever > gh > go-containerregistry > gobgp > golang-collectd > golang-entgo-ent > golang-github-anacrolix-dms > golang-github-anacrolix-ffprobe > golang-github-anacrolix-missinggo > golang-github-anacrolix-tagflag > golang-github-backblaze-blazer > golang-github-canonical-candid > golang-github-census-instrumentation-opencensus-proto > golang-github-checkpoint-restore-checkpointctl > golang-github-containerd-errdefs > golang-github-containerd-nri > golang-github-containerd-stargz-snapshotter > golang-github-containers-buildah > golang-github-containers-common > golang-github-containers-image > golang-github-containers-ocicrypt > golang-github-containers-psgo > golang-github-containers-storage > golang-github-crc-org-crc > golang-github-crowdsecurity-go-cs-bouncer > golang-github-docker-leadership > golang-github-expediadotcom-haystack-client-go > golang-github-francoispqt-gojay > golang-github-fsouza-go-dockerclient > golang-github-go-kit-kit > golang-github-gogo-status > golang-github-googleapis-gax-go > golang-github-googlecloudplatform-guest-logging-go > golang-github-grafana-grafana-plugin-model > golang-github-gravitational-trace > golang-github-grpc-ecosystem-go-grpc-middleware > golang-github-grpc-ecosystem-go-grpc-prometheus > golang-github-grpc-ecosystem-grpc-gateway > golang-github-grpc-ecosystem-grpc-opentracing > golang-github-hashicorp-go-discover > golang-github-hashicorp-go-getter > golang-github-hashicorp-go-plugin > golang-github-jacobsa-gcloud > golang-github-juju-persistent-cookiejar > golang
Re: Migration status of golang-google-genproto
> On 2024-07-31 21:50:33 +0000, Mathias Gibbens wrote: > > Hi, > > > > For the past ~4 days the testing excuses for golang-google-genproto > > has said that it would attempt migration to testing, but that hasn't > > happened yet. Is something else stuck, or somewhere I could look to see > > why it hasn't migrated yet? > > Migrating it makes other packages uninstallable: > > trying: golang-google-genproto > skipped: golang-google-genproto (169, 0, 618) > got: 38+6865: a-4:a-11:a-13:a-0:i-1:m-8:p-0:r-6865:s-1 > * amd64: golang-github-hashicorp-go-discover-dev, > golang-github-lightstep-lightstep-tracer-common-dev, > golang-github-smallstep-certificates-dev > > (from https://release.debian.org/britney/update_output.txt) Thanks for that pointer, Sebastian. It did help identify why that package hadn't yet migrated. Would be nice if that could be integrated into the excuses page at some point. Mathias signature.asc Description: This is a digitally signed message part
Bug#1057116: bookworm-pu: package lxc/1:5.0.2-1+deb12u2
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-lxc-de...@lists.alioth.debian.org, gib...@debian.org
Control: affects -1 + src:lxc
[ Reason ]
The version of lxc in bookworm fails to create ephemeral copies of
containers. This is affecting Debian users, as two different bugs have
been reported in addition to an upstream bug report.
A fix was merged into the upstream repo earlier today, and I have
cherry-picked it into the packaging for unstable which I have just
uploaded. I would like to get this fix into bookworm, as it is a
regression compared to lxc in bullseye.
[ Impact ]
The version of lxc currently in bookworm cannot create ephemeral copies
of containers.
[ Tests ]
The changes have been reviewed and accepted by the upstream developers.
I have tested that creation of normal and ephemeral containers works as
expected in bookworm with this patch.
[ Risks ]
Minor/none -- the specific variable being checked was fixed to be a
more correct one that could never be NULL, which was the root cause of
the bug. This does technically change the behavior of lxc by fixing the
bug, but I don't think there is any risk of a regression in other lxc
behavior.
[ 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
[ Changes ]
Cherry-pick and rebase upstream commit
0e932812ae2ac4dec58e413c0d95d581385b9756, which has been merged into
the upstream repo. There is also renaming of the `bdev_type` variable
to `__bdev_type` which was included in the upstream commit; I have left
that in, so the changes to bookworm packaging can be a direct cherry-
pick of the upstream fix.
[ Other info ]
The source debdiff is attached.
diff -Nru lxc-5.0.2/debian/changelog lxc-5.0.2/debian/changelog
--- lxc-5.0.2/debian/changelog 2023-09-22 16:35:52.0 +
+++ lxc-5.0.2/debian/changelog 2023-11-30 01:17:33.0 +
@@ -1,3 +1,9 @@
+lxc (1:5.0.2-1+deb12u2) bookworm; urgency=medium
+
+ * Cherry-pick upstream fix for creating ephemeral copies (See #1001713)
+
+ -- Mathias Gibbens Thu, 30 Nov 2023 01:17:33 +
+
lxc (1:5.0.2-1+deb12u1) bookworm; urgency=medium
* Cherry-pick upstream "fix nftables syntax for IPv6 NAT" (Closes: #1049976)
diff -Nru lxc-5.0.2/debian/patches/0101-cherry-pick-fix-ephemeral-copies.patch lxc-5.0.2/debian/patches/0101-cherry-pick-fix-ephemeral-copies.patch
--- lxc-5.0.2/debian/patches/0101-cherry-pick-fix-ephemeral-copies.patch 1970-01-01 00:00:00.0 +
+++ lxc-5.0.2/debian/patches/0101-cherry-pick-fix-ephemeral-copies.patch 2023-11-30 01:17:33.0 +
@@ -0,0 +1,155 @@
+From 0e932812ae2ac4dec58e413c0d95d581385b9756 Mon Sep 17 00:00:00 2001
+From: Christian Brauner
+Date: Wed, 29 Nov 2023 15:57:04 +0100
+Subject: [PATCH] conf: fix ephemeral copies
+
+Don't rely on rootfs->bdev_type because that may be NULL. Use storage->type
+instead which can't be NULL.
+
+Co-Developed-by: Mathias Gibbens
+Signed-off-by: Mathias Gibbens
+Reported-by: Mathias Gibbens
+Signed-off-by: Christian Brauner
+---
+ src/lxc/conf.c| 21 -
+ src/lxc/conf.h| 4 ++--
+ src/lxc/confile.c | 4 ++--
+ src/lxc/storage/storage.c | 4 ++--
+ src/lxc/storage/storage.h | 2 +-
+ 5 files changed, 19 insertions(+), 16 deletions(-)
+
+diff --git a/src/lxc/conf.c b/src/lxc/conf.c
+index 9158713..e338ed7 100644
+--- a/src/lxc/conf.c
b/src/lxc/conf.c
+@@ -536,16 +536,21 @@ int lxc_rootfs_init(struct lxc_conf *conf, bool userns)
+ struct stat st;
+ struct statfs stfs;
+ struct lxc_rootfs *rootfs = &conf->rootfs;
++ const char *type;
+
+ ret = lxc_storage_prepare(conf);
+ if (ret)
+ return syserror_set(-EINVAL, "Failed to prepare rootfs storage");
++ type = rootfs->storage->type;
++
++ if (!type)
++ return syserror_set(-EINVAL, "Storage type neither set nor automatically detected");
+
+ if (!is_empty_string(rootfs->mnt_opts.userns_path)) {
+ if (!rootfs->path)
+ return syserror_set(-EINVAL, "Idmapped rootfs currently only supported with separate rootfs for container");
+
+- if (rootfs->bdev_type && !strequal(rootfs->bdev_type, "dir"))
++ if (type && !strequal(type, "dir"))
+ return syserror_set(-EINVAL, "Idmapped rootfs currently only supports the \"dir\" storage driver");
+ }
+
+@@ -555,14 +560,12 @@ int lxc_rootfs_init(struct lxc_conf *conf, bool userns)
+ if (userns)
+ return log_trace(0, "Not pinning because container runs in user namespace");
+
+- if (rootfs->bdev_type) {
+- if (strequal(rootfs->bdev_type, "overlay") ||
+- strequal(rootfs->bdev_type, "overlayfs"))
+- return log_trace_errno(0,
Bug#1057116: bookworm-pu: package lxc/1:5.0.2-1+deb12u2
On Sat, 02 Dec 2023 19:17:28 + "Adam D. Barratt" wrote: > Please go ahead. Uploaded, thanks! Mathias signature.asc Description: This is a digitally signed message part
Bug#1063371: nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Tags: bookworm-backports Control: affects -1 + src:golang-github-go-jose-go-jose Control: affects -1 + src:golang-github-tinylib-msgp nmu golang-github-go-jose-go-jose_3.0.1-2~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" nmu golang-github-tinylib-msgp_1.1.9-1~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" I would like for the amd64 builds to happen on official buildds, rather than relying on my amd64 upload as part of processing through BACKPORTS-NEW. I'm not sure when the next update in unstable to either package will be, so I'd like to schedule a binNMU. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#1063371: nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp
Control: tags -1 bookworm-backports signature.asc Description: This is a digitally signed message part
Bug#1064869: nmu: cowsql, golang-github-cowsql-go-cowsql
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Tags: bookworm-backports Control: affects -1 + src:cowsql Control: affects -1 + src:golang-github-cowsql-go-cowsql nmu cowsql_1.15.4-1~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" nmu golang-github-cowsql-go-cowsql_1.22.0-2~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" I would like for the amd64 builds to happen on official buildds, rather than relying on my amd64 upload as part of processing through BACKPORTS-NEW. I'm not sure when the next update in unstable to either package will be, so I'd like to schedule a binNMU. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#1063371: nmu: golang-github-tinylib-msgp
Control: retitle -1 nmu: golang-github-tinylib-msgp Control: affects -1 - src:golang-github-go-jose-go-jose I've backported a newer version of golang-github-go-jose-go-jose, which resolves the need for a binNMU of that package. A binNMU is still requested for golang-github-tinylib-msgp in bookworm-backports. Mathias signature.asc Description: This is a digitally signed message part
Bug#1064869: nmu: golang-github-cowsql-go-cowsql
Control: retitle -1 nmu: golang-github-cowsql-go-cowsql Control: affects -1 - src:cowsql I've backported a newer version of cowsql, which resolves the need for a binNMU of that package. A binNMU is still requested for golang-github-cowsql-go-cowsql in bookworm-backports. Mathias signature.asc Description: This is a digitally signed message part
Bug#1091164: bookworm-pu: package lxc/1:5.0.2-1+deb12u3
On Thu, 2025-01-02 at 20:39 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sun, 2024-12-22 at 18:59 +, Mathias Gibbens wrote: > > The version of lxc in bookworm segfaults when attempting to use a > > shared host rootfs. Originally reported against lxc in sid as bug > > #1085241, I have verified the issue is also present in bookworm. > > Please go ahead. Uploaded, thanks! Mathias signature.asc Description: This is a digitally signed message part
Bug#1091164: bookworm-pu: package lxc/1:5.0.2-1+deb12u3
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-lxc-de...@lists.alioth.debian.org, gib...@debian.org Control: affects -1 + src:lxc [ Reason ] The version of lxc in bookworm segfaults when attempting to use a shared host rootfs. Originally reported against lxc in sid as bug #1085241, I have verified the issue is also present in bookworm. The fix was included in the lxc 6.0.3 release, which has recently migrated to testing. The relevant commit applies cleanly to lxc 5.0.2. [ Impact ] The version of lxc currently in bookworm will unexpectedly segfault if configured to use a shared rootfs. [ Tests ] This issue was fixed in lxc 6.0.3. I have verified that lxc no longer segfaults in bookworm with this fix applied. [ Risks ] Minor/none -- a missing check was added which will prevent null pointer dereferencing. [ 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 [ Changes ] Cherry-pick upstream commit d5c2d1efff92b2b992f10b29bd459a4b07875025, which was included in the lxc 6.0.3 release. [ Other info ] The source debdiff is attached. diff -Nru lxc-5.0.2/debian/changelog lxc-5.0.2/debian/changelog --- lxc-5.0.2/debian/changelog 2023-11-30 01:17:33.0 + +++ lxc-5.0.2/debian/changelog 2024-12-22 18:35:15.0 + @@ -1,3 +1,10 @@ +lxc (1:5.0.2-1+deb12u3) bookworm; urgency=medium + + * Cherry-pick upstream fix for null pointer dereference when using a shared +rootfs (See #1085241) + + -- Mathias Gibbens Sun, 22 Dec 2024 18:35:15 + + lxc (1:5.0.2-1+deb12u2) bookworm; urgency=medium * Cherry-pick upstream fix for creating ephemeral copies (See #1001713) diff -Nru lxc-5.0.2/debian/patches/0102-cherry-pick-fix-null-pointer-dereference.patch lxc-5.0.2/debian/patches/0102-cherry-pick-fix-null-pointer-dereference.patch --- lxc-5.0.2/debian/patches/0102-cherry-pick-fix-null-pointer-dereference.patch 1970-01-01 00:00:00.0 + +++ lxc-5.0.2/debian/patches/0102-cherry-pick-fix-null-pointer-dereference.patch 2024-12-20 03:27:46.0 + @@ -0,0 +1,27 @@ +From d5c2d1efff92b2b992f10b29bd459a4b07875025 Mon Sep 17 00:00:00 2001 +From: Steven Galgano +Date: Mon, 14 Oct 2024 15:16:36 -0400 +Subject: [PATCH] Avoid null pointer dereference when using shared rootfs. + rootfs->storage not set by lxc_storage_prepare when using a shared rootfs. + +Fixes: https://github.com/lxc/lxc/issues/4476 +Signed-off-by: Steven Galgano +--- + src/lxc/conf.c | 4 + 1 file changed, 4 insertions(+) + +diff --git a/src/lxc/conf.c b/src/lxc/conf.c +index 4b46d24bfe..6a14c60360 100644 +--- a/src/lxc/conf.c b/src/lxc/conf.c +@@ -341,6 +341,10 @@ int lxc_rootfs_init(struct lxc_conf *conf, bool userns) + ret = lxc_storage_prepare(conf); + if (ret) + return syserror_set(-EINVAL, "Failed to prepare rootfs storage"); ++ ++ if (!rootfs->storage) ++ return log_trace(0, "Not pinning because container does not have storage"); ++ + type = rootfs->storage->type; + + if (!type) diff -Nru lxc-5.0.2/debian/patches/series lxc-5.0.2/debian/patches/series --- lxc-5.0.2/debian/patches/series 2023-11-30 01:17:33.0 + +++ lxc-5.0.2/debian/patches/series 2024-12-22 18:33:00.0 + @@ -3,3 +3,4 @@ 0004-nesting-Extend-mount-permissions-in-apparmor-to-allo.patch 0100-fix-nftables-ipv6.patch 0101-cherry-pick-fix-ephemeral-copies.patch +0102-cherry-pick-fix-null-pointer-dereference.patch signature.asc Description: This is a digitally signed message part
Bug#1100970: pre-approval: qemu 10.0 for trixie
Just a heads up that this might impact Incus/LXD. The release of qemu 9.2 required several updates due to API changes; I haven't looked at qemu 10 at all, so I don't know what sort of changes were made in the upcoming release. I don't think this should block the upload of qemu to unstable, just be aware that updates to Incus/LXD might be needed if issues are found as we get further into the trixie freeze. Mathias signature.asc Description: This is a digitally signed message part
Bug#1100970: pre-approval: qemu 10.0 for trixie
On Tue, 2025-03-25 at 12:14 +0300, Michael Tokarev wrote: > 21.03.2025 18:34, Mathias Gibbens wrote: > > Just a heads up that this might impact Incus/LXD. The release of qemu > > 9.2 required several updates due to API changes; I haven't looked at > > qemu 10 at all, so I don't know what sort of changes were made in the > > upcoming release. > > I was able to find just one update which had to be done for incus for > qemu 9.2 - the bootindex json property, which were erroneously marked > as type string in qemu in the past, and 9.2 fixed this by requiring it > to be integer, as it should've been. Which other updates were required? Yes, fixing argument typing was one of the larger changes[1], along with dealing with the removal of virtfs-proxy-helper[2]. The need to fix argument types was an obvious change, but the removal of virtfs- proxy-helper wasn't notice until Colin filed a bug about it. There were a couple other smaller updates[3,4] as well. I did ping Stéphane, and he said he didn't see anything in the deprecation list for the qemu 10 release[5] that looks like it will affect Incus, but we'll still want to test things once qemu 10 is uploaded to unstable. Mathias [1] -- https://github.com/lxc/incus/pull/1531 [2] -- https://github.com/lxc/incus/pull/1547 [3] -- https://github.com/lxc/incus/pull/1601 [4] -- https://github.com/lxc/incus/pull/1594 [5] -- https://www.qemu.org/docs/master/about/deprecated.html signature.asc Description: This is a digitally signed message part
Bug#1100970: pre-approval: qemu 10.0 for trixie
On Thu, 2025-03-27 at 09:33 +0300, Michael Tokarev wrote: > I uploaded qemu 10.0.0-rc1 to unstable yesterday, now it is already built > and installed on all architectures, ready for testing. So far just one minor issue has been found, and is already fixed upstream[1]. I'll be updating the Incus package later today, and have the fix staged for LXD. Mathias [1] -- https://github.com/lxc/incus/pull/1871 signature.asc Description: This is a digitally signed message part
Bug#1104691: bookworm-pu: package logcheck/1.4.2+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: gib...@debian.org, richard.lewis.deb...@googlemail.com Control: affects -1 + src:logcheck [ Reason ] The version of logcheck in bookworm does not respect the removal of /etc/logcheck/header.txt in bullseye prior to updating to bookworm. Originally reported in bug #1049412, fixed by logcheck 1.4.4 uploaded to unstable yesterday. While likely academic at this point in the bookworm lifecycle, it's a fairly easy fix to include. [ Impact ] There's currently a minor regression for users upgrading from bullseye to bookworm who had previously removed /etc/logcheck/header.txt. [ Tests ] I have tested the bullseye->proposed-bookworm-update->trixie->sid upgrade path, both with and without removing the header.txt file, and verified it remains deleted if removed prior to starting the upgrade path. [ Risks ] Minor/none -- logic was added to logcheck's pre/postinst scripts to handle the removal of /etc/logcheck/header.txt. [ 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 [ Changes ] Cherry-pick relevant fix from unstable commit 8cc01d30a3156eaa2f21b14e468eccd0b0666c3c. [ Other info ] The source debdiff is attached. diff -Nru logcheck-1.4.2/debian/changelog logcheck-1.4.2+deb12u1/debian/changelog --- logcheck-1.4.2/debian/changelog 2023-03-01 22:49:39.0 + +++ logcheck-1.4.2+deb12u1/debian/changelog 2025-05-04 16:43:20.0 + @@ -1,3 +1,16 @@ +logcheck (1.4.2+deb12u1) bookworm; urgency=medium + + [ Mathias Gibbens ] + * Update d/gbp.conf for debian/bookworm branch + + [ Richard Lewis ] + * Ensure that if a user deleted /etc/logcheck/header.txt before +upgrading to bookworm then the file stays deleted (Closes: #1049412). +NB that the best way to suppress the header is to set INTRO=0 in +/etc/logcheck/logcheck.conf + + -- Mathias Gibbens Sun, 04 May 2025 16:43:20 + + logcheck (1.4.2) unstable; urgency=medium * More explicitly mention the default checking of the systemd journal diff -Nru logcheck-1.4.2/debian/gbp.conf logcheck-1.4.2+deb12u1/debian/gbp.conf --- logcheck-1.4.2/debian/gbp.conf 2023-03-01 22:49:39.0 + +++ logcheck-1.4.2+deb12u1/debian/gbp.conf 2025-05-04 16:43:20.0 + @@ -1,8 +1,8 @@ [DEFAULT] +debian-branch = debian/bookworm +dist = DEP14 [buildpackage] -#pbuilder = true -#export-dir = ../build-area sign-tags = true [import-orig] diff -Nru logcheck-1.4.2/debian/logcheck.postinst logcheck-1.4.2+deb12u1/debian/logcheck.postinst --- logcheck-1.4.2/debian/logcheck.postinst 2023-03-01 22:49:39.0 + +++ logcheck-1.4.2+deb12u1/debian/logcheck.postinst 2025-05-04 16:43:20.0 + @@ -66,6 +66,14 @@ chown logcheck:logcheck "$f" || true chmod u=rwx,g=rx,o= "$f" || true # drwxr-x--- done + + # remove once trixie is stable (see also preinst) + if [ -f /etc/logcheck/header.txt.was-deleted-before-bookworm ]; then + echo "Preserving user-deletion of /etc/logcheck/header.txt -- packaged version is left at /etc/logcheck/header.txt.dpkg-new" + mv -f /etc/logcheck/header.txt /etc/logcheck/header.txt.dpkg-new || true + rm -f /etc/logcheck/header.txt.was-deleted-before-bookworm || true + fi + ;; abort-upgrade|abort-remove|abort-deconfigure) diff -Nru logcheck-1.4.2/debian/logcheck.preinst logcheck-1.4.2+deb12u1/debian/logcheck.preinst --- logcheck-1.4.2/debian/logcheck.preinst 1970-01-01 00:00:00.0 + +++ logcheck-1.4.2+deb12u1/debian/logcheck.preinst 2025-05-04 16:43:20.0 + @@ -0,0 +1,10 @@ +#!/bin/sh +set -e + +# preserve deletion of /etc/logcheck/header.txt if upgrading from <= 1.4.1 --- see #1049412 +if [ "$1" = "upgrade" ] && [ ! -f /etc/logcheck/header.txt ] && dpkg --compare-versions "$2" le-nl 1.4.1; then + echo "You deleted /etc/logcheck/header.txt before bookworm: this deletion will be preserved. However, it would be better to set INTRO=0 in /etc/logcheck.conf instead." + touch /etc/logcheck/header.txt.was-deleted-before-bookworm || : +fi + +#DEBHELPER# signature.asc Description: This is a digitally signed message part
Bug#1104691: bookworm-pu: package logcheck/1.4.2+deb12u1
Uploaded, thanks! Mathias signature.asc Description: This is a digitally signed message part
Bug#1100970: pre-approval: qemu 10.0 for trixie
One minor regression involving NVME hotplugging has been identified; I've just opened bug #1104889 about this. While not a show-stopper, it does make the use of NVME virtual devices impossible in Incus. Mathias signature.asc Description: This is a digitally signed message part
Bug#1107459: unblock: openrct2/0.4.23+ds-1 (pre-approval)
Package: release.debian.org
Control: affects -1 + src:openrct2
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Michał Janiszewski , gib...@debian.org
Severity: normal
Please unblock package openrct2 (pre-approval)
[ Reason ]
I received the following request from one of the OpenRCT2 developers
today:
On Sat, 2025-06-07 at 21:18 +0200, Michał Janiszewski wrote:
> I'm one of the developers of OpenRCT2 and I wanted to ask if it would
> be possible to update the package in trixie to 0.4.23, our latest
> release? [snip] We have implemented a lot of performance-related
> improvements and it would be great to see those in use, especially on
> low-powered devices such as raspberry pi, when it eventually trickles
> there.
[ Impact ]
Without the update, trixie will include an older version of OpenRCT2
that is missing out on various performance-related improvements.
I do plan to provide backported versions of OpenRCT2 during trixie's
lifetime, similar to how I've done for bookworm.
[ Tests ]
I have been uploading new releases of openrct2 to experimental since
the soft freeze began and have installed them locally to verify the
game operates as expected.
[ Risks ]
None; openrct2 is a leaf package in contrib and I've performed my
normal play testing of the version uploaded to experimental.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[ ] attach debdiff against the package in testing
[ Other info ]
No debdiff, since it would be huge when comparing against 0.4.21+ds-1
in testing.
I've attached the relevant changelog entries for the two uploads to
unstable.
unblock openrct2/0.4.23+ds-1
openrct2 (0.4.23+ds-1~exp1) experimental; urgency=medium
* New upstream release
- Rebase patches as needed
-- Mathias Gibbens Sat, 07 Jun 2025 14:57:57 +
openrct2 (0.4.22+ds-1~exp1) experimental; urgency=medium
* New upstream release
- Drop patch to disable version check and rely on new cmake flag
- Rebase patches as needed
-- Mathias Gibbens Sun, 04 May 2025 19:37:24 +
signature.asc
Description: This is a digitally signed message part
Bug#1109244: unblock: b43-fwcutter/1:019-14 (pre-approval)
Package: release.debian.org
Control: affects -1 + src:b43-fwcutter
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gib...@debian.org
Severity: normal
Pre-approval request to unblock package b43-fwcutter
[ Reason ]
At some point, the site hosting b43 firmware referenced by this package
went offline. This causes the install of firmware-b43-installer to
fail, as reported in bug #1109025. A copy of the firmware exists in a
GitHub repo, and a single line change restores the package's
functionality.
[ Impact ]
Users are unable to automatically fetch the necessary b43 firmware for
their wireless network cards.
[ Tests ]
I verified installing the updated package in a clean trixie container
worked and was able to properly fetch and extract the firmware.
[ Risks ]
Singe line change in postinst script to adjust download URL.
There is a lingering issue about the redistributabilty of the firmware
by the remote end, but that issue pre-dates this package's postinst
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 ]
debdiff included below
unblock b43-fwcutter/1:019-14
-
diff -Nru b43-fwcutter-019/debian/changelog b43-fwcutter-019/debian/changelog
--- b43-fwcutter-019/debian/changelog 2024-11-30 22:44:53.0 +
+++ b43-fwcutter-019/debian/changelog 2025-07-14 05:52:41.0 +
@@ -1,3 +1,10 @@
+b43-fwcutter (1:019-14) unstable; urgency=medium
+
+ * QA upload.
+ * Update remote site where firmware can be fetched (Closes: #1109025)
+
+ -- Mathias Gibbens Mon, 14 Jul 2025 05:52:41 +
+
b43-fwcutter (1:019-13) unstable; urgency=medium
* QA upload.
diff -Nru b43-fwcutter-019/debian/firmware-b43-installer.postinst
b43-fwcutter-019/debian/firmware-b43-installer.postinst
--- b43-fwcutter-019/debian/firmware-b43-installer.postinst 2024-11-30
22:44:53.0 +
+++ b43-fwcutter-019/debian/firmware-b43-installer.postinst 2025-07-14
05:43:51.0 +
@@ -19,7 +19,7 @@
DOWNLOAD="${BROADCOM_WL}.tar.bz2"
-URL="https://www.lwfinger.com/b43-firmware/${DOWNLOAD}";
+URL="https://github.com/minios-linux/b43-firmware/releases/download/b43-firmware/${DOWNLOAD}";
FIRMWARE_INSTALL_DIR="/usr/lib/firmware"
signature.asc
Description: This is a digitally signed message part
Bug#1109763: bookworm-pu: package b43-fwcutter/1:019-8+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: gib...@debian.org
Control: affects -1 + src:b43-fwcutter
[ Reason ]
firmware-b43-installer fails to install in bookworm due to a brokenupstream URL.
[ Impact ]
Users running the current stable Debian release cannot properly install
the firmware required for their wireless NIC.
[ Tests ]
I have verified the package correctly fetches the firmware when using
the updated URL.
[ Risks ]
Minor/none -- single line change to update download URL.
[ 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
[ Changes ]
Cherry-pick relevant fix from unstable commit
5a328aadbd836a27ea3c320645fede7f1d272905.
[ Other info ]
The source debdiff is attached.
diff -Nru b43-fwcutter-019/debian/changelog b43-fwcutter-019/debian/changelog
--- b43-fwcutter-019/debian/changelog 2023-02-20 13:51:02.0 +
+++ b43-fwcutter-019/debian/changelog 2025-07-23 11:05:22.0 +
@@ -1,3 +1,10 @@
+b43-fwcutter (1:019-8+deb12u1) bookworm; urgency=medium
+
+ * QA upload.
+ * Update remote site where firmware can be fetched (Closes: #1109025)
+
+ -- Mathias Gibbens Wed, 23 Jul 2025 11:05:22 +
+
b43-fwcutter (1:019-8) unstable; urgency=medium
* QA upload.
diff -Nru b43-fwcutter-019/debian/firmware-b43-installer.postinst b43-fwcutter-019/debian/firmware-b43-installer.postinst
--- b43-fwcutter-019/debian/firmware-b43-installer.postinst 2023-02-20 13:51:02.0 +
+++ b43-fwcutter-019/debian/firmware-b43-installer.postinst 2025-07-23 11:05:22.0 +
@@ -19,7 +19,7 @@
DOWNLOAD="${BROADCOM_WL}.tar.bz2"
-URL="https://www.lwfinger.com/b43-firmware/${DOWNLOAD}";
+URL="https://github.com/minios-linux/b43-firmware/releases/download/b43-firmware/${DOWNLOAD}";
FIRMWARE_INSTALL_DIR="/lib/firmware"
signature.asc
Description: This is a digitally signed message part
Re: Bug#1109513: Likely golang-github-golang-protobuf-1-{3,5}-dev transition
What makes this tricky is that golang-github-golang-protobuf-1-3 provides pre-APIv2 protobuf libraries and golang-github-golang- protobuf-1-5 provides APIv2. While some code might compile with both versions, they are runtime incompatible and mixing resulting binaries will result most likely in crashes. I think that a Breaks+Replaces as suggested in bug #1109655 isn't correct. I'm not familiar enough with the details to be able to confidently suggest the correct solution to this problem. I did mention this on the debian-go mailing list hoping to solicit feedback from others. The affected packages in bugs #1109513-7 are all golang development libraries, which aren't expected to be used other than building golang packages. I think the odds of an end user encountering the upgrade issue is low, although it would still be good to fix. Mathias signature.asc Description: This is a digitally signed message part
RT: trixie-no-auto-remove request for #1109513 & friends
Release Team, I'd like to ask that you tag #1109513 & merged friends with trixie- no-auto-remove. Pretty late in the release freeze cycle a few bugs were filed against golang libraries that don't cleanly dist-upgrade from bookworm due to the golang-github-golang-protobuf-1-3-dev -> golang- github-golang-protobuf-1-5-dev transition last summer. Post trixie upgrade, a simple `apt install ...-dev` is enough to hit apt through installing the updated packages. protobuf-1-3 provides a pre-v2 API, while protobuf-1-5 provides the v2 API. As such, it's not a straightforward replacement exercise to update all golang packages to use the protobuf-1-5 library. A handful of additional bugs have been filed identifying golang packages that still depend on protobuf-1-3 (#1110159-64), but those might in turn have additional dependencies that would require an update and/or rebuild. Given that these are development libraries intended for building other golang packages, and therefore unlikely to be installed by an end user, and that we're in the final freeze, I would request that the trixie-no-auto-remove tag be applied since an autorm would remove a ton of other golang packages that really should be part of the trixie release. Once forky development opens up, we can then address the dependency issues. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#1109763: bookworm-pu: package b43-fwcutter/1:019-8+deb12u1
On Mon, 2025-07-28 at 22:26 +0100, Jonathan Wiltshire wrote: > Please go ahead. Uploaded, thanks. Mathias signature.asc Description: This is a digitally signed message part
