Bug#1070680: freeipa-client: unable to convert the attribute 'cacertificate;binary' value

[Martin Pitt]

Package: python3-ipaclient
Severity: important
Version: 4.11.1-2
Tags: upstream, fixed-upstream
Forwarded: 
https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedorahosted.org/thread/PLR7R2FIZXNOQFMT3XWMBK3UYI7FWVMY/

Hello,

A few days ago, python-cryptography 42.0 entered Debian testing. This
unfortunately breaks FreeIPA. When joining an existing IPA server (running on
CentOS 8, but doesn't matter much), joining the domain fails with

| unable to convert the attribute 'cacertificate;binary' value b'0\x82[...]' to 
type 
| Cannot obtain CA certificate
| 'ldap://f0.cockpit.lan' doesn't have a certificate.

/var/log/ipaclient-install.log has a very long traceback, excerpts:

| 2024-05-07T04:16:52Z DEBUG Traceback (most recent call last):
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 1031, in 
decode
| return x509.load_der_x509_certificate(val)
|^^^
|   File "/usr/lib/python3/dist-packages/ipalib/x509.py", line 445, in 
load_der_x509_certificate
| return IPACertificate(
|^^^
| TypeError: Can't instantiate abstract class IPACertificate with abstract 
methods not_valid_after_utc, not_valid_before_utc
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 374, in 
_sync_attr
| value = self._conn.decode(value, name)
| ^^
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 1037, in 
decode
| raise ValueError(msg)
| ValueError: unable to convert the attribute 'cacertificate;binary' value 
b'[...]' to type 
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
|   File "/usr/lib/python3/dist-packages/ipaclient/install/client.py", line 
1739, in get_certs_from_ldap
| certs = certstore.get_ca_certs(conn, base_dn, realm, ca_enabled)
| 
|   File "/usr/lib/python3/dist-packages/ipalib/install/certstore.py", line 
310, in get_ca_certs
| for cert in entry.get('cACertificate;binary', []):
| ^
|   File "", line 774, in get
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 510, in 
__getitem__
| return self._get_nice(name)
|
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 485, in 
_get_nice
| self._sync_attr(name)
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 376, in 
_sync_attr
| raise ValueError("{error} in LDAP entry '{dn}'".format(
| ValueError: unable to convert the attribute 'cacertificate;binary' value [...]

This was already reported upstream (see "Forwarded:" above), and fixed in
upstream git 4 months ago:

   
https://pagure.io/freeipa/c/a45a7a20d96af51d463a285cb9318582720be708?branch=master

Unfortunately there hasn't been a new release since then. But I applied the
patch straight to /usr/lib/python3/dist-packages/ , it applies with some fuzz,
and joining the domain works fine afterwards.

Thanks,

Martin

Bug#1069059: cockpit update from DSA-5655-1 without binary builds (build failures)

[Martin Pitt]

Control: tag -1 upstream fixed-upstream patch
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/19790

Hello Salvatore and Santiago,

Salvatore Bonaccorso [2024-04-15 19:28 +0200]:
> The update for cockpit in DSA 5655-1 had problems with the
> test-sshbridge test, causing FTBFS:
>
> >From the tail of the test failure:
>
> # cockpit-protocol-DEBUG: test-ssh: output queue empty
>
> (cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702: 
> (src/ssh/cockpitsshrelay.c:1423):cockpit_ssh_connect: runtime check failed: 
> (ssh_options_set (data->session, SSH_OPTIONS_HOST, host) == 0)
>
> (cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702: 
> (src/ssh/cockpitsshrelay.c:1424):cockpit_ssh_connect: runtime check failed: 
> (ssh_options_parse_config (data->session, NULL) == 0)
> # cockpit-protocol-DEBUG: test-ssh: reading input 1
> # cockpit-protocol-DEBUG: test-ssh: received a 82 byte payload
> # cockpit-protocol-DEBUG: test-ssh: want more data
> **
> cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init: 
> assertion failed (json_object_get_string_member (init, "command") == "init"): 
> ("authorize" == "init")
> Bail out! 
> cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init: 
> assertion failed (json_object_get_string_member (init, "command") == "init"): 
> ("authorize" == "init")
> cockpit-ssh-Message: 20:51:17.704: cockpit-ssh some_host: -1 couldn't 
> connect: Hostname required 'some_host' '22'
> cockpit-ssh-Message: 20:51:17.704: couldn't write control message: Broken pipe
> cockpit-ssh-Message: 20:51:17.704: couldn't write authorize message: 
> Inappropriate ioctl for device
> FAIL test-sshbridge (exit status: 134)

Argh, I can reproduce. The test passes with the previous
http://snapshot.debian.org/package/libssh/0.10.5-3/ but fails with current 
0.10.6-0+deb12u1.

The reason is annoyingly mundane, and already got fixed upstream half a year 
ago:
https://github.com/cockpit-project/cockpit/commit/518d36c3492020525

I prepared a package update with that fix cherry-picked. See attached debdiff.
It builds fine in a clean bookworm container now.
But I don't know how exactly to target and upload this: to bookworm-security or
-updates? It's a follow-up for a previous security update to make that actually
work, but not a security update in itself.

Santiago Vila [2024-04-15 20:28 +0200]:
> For completeness: this was already happening in bullseye and bookworm
> before the DSA. (Reminder for myself: report all the bugs I found
> last week while rebuilding bullseye and bookworm).

Right, that makes sense. There are no C code changes between 287 and 287.1.

Thanks, and sorry for the trouble,

Martin
diff -Nru cockpit-287.1/debian/changelog cockpit-287.1/debian/changelog
--- cockpit-287.1/debian/changelog  2024-04-02 11:11:19.0 +0200
+++ cockpit-287.1/debian/changelog  2024-04-16 09:20:17.0 +0200
@@ -1,3 +1,11 @@
+cockpit (287.1-0+deb12u2) bookworm-security; urgency=medium
+
+  * Add 0001-ssh-Use-valid-host-name-in-test-sshbridge.patch:
+Use valid host name in test-sshbridge. Fixes FTBFS due to unit test
+failure when building against libssh 0.10.6. (Closes: #1069059)
+
+ -- Martin Pitt   Tue, 16 Apr 2024 09:20:17 +0200
+
 cockpit (287.1-0+deb12u1) bookworm-security; urgency=medium
 
   * New upstream security update:
diff -Nru 
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
 
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
--- 
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
   1970-01-01 01:00:00.0 +0100
+++ 
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
   2024-04-16 09:19:18.0 +0200
@@ -0,0 +1,36 @@
+From 518d36c349202052578a459872c3657760226648 Mon Sep 17 00:00:00 2001
+From: Martin Pitt 
+Date: Fri, 29 Dec 2023 07:12:11 +0100
+Subject: [PATCH] ssh: Use valid host name in test-sshbridge
+
+libssh 0.10.6 made host name parsing stricter. `some_host` is not a
+valid general host name, and is rejected with the latest version.
+---
+ src/ssh/test-sshbridge.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/ssh/test-sshbridge.c b/src/ssh/test-sshbridge.c
+index e0ff9a7a9..9c561e29a 100644
+--- a/src/ssh/test-sshbridge.c
 b/src/ssh/test-sshbridge.c
+@@ -323,7 +323,7 @@ setup (TestCase *tc,
+   if (!fixture->knownhosts_home)
+   g_assert_cmpint (mkdir (tc->home_ssh_dir, 0700), ==, 0);
+ 
+-  g_string_append (content, "Host some_host\n");
++  g_string_append (content, "Host somehost\n");
+   g_string_append_printf (content, "\tHostname %s\n", hostname);
+ 
+   if (fixture->ssh_confi

Bug#1067208: umockdev: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Martin Pitt]

Control: forwarded -1 https://github.com/martinpitt/umockdev/issues/216
Control: tag -1 upstream pending

Hello all,

Thorsten Glaser [2024-03-20  3:05 +]:
> /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed 
> only with _FILE_OFFSET_BITS=64"
>26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
>   | ^
>
>
> I admit I don’t exactly see what’s going on here. Does it
> maybe #unset _FILE_OFFSET_BITS or something?

Yes, it currently does on main/latest release, see 
https://github.com/martinpitt/umockdev/issues/216

Simon McVittie [2024-03-21 12:30 +]:
> I don't think the proposed fix in kmod is correct, and I don't think
> an equivalent in umockdev would be correct either. Since glibc 2.34,
> on 32-bit architectures all such LD_PRELOAD modules will need updating
> to also wrap __lstat64_time64(), __stat64_time64(), __fstat64_time64()
> and __fstatat64_time64() on architectures where they exist - otherwise,
> programs and libraries compiled with 64-bit time_t will bypass the
> wrapped stat(), stat64() etc. and call __stat64_time64() instead, and
> therefore the wrapping will be ineffective and umockdev's mock devices
> will not be seen.

Correct.

As it happens, the latest Ubuntu package got fixes for both of these issues
recently, thanks to Steve Langasek and Zixing Liu! I'll integrate them upstream
and then make a new release.

Martin

Bug#1062354: libatomic1: 14-20240127-1 missing libat_test_and_set_1_i2

[Martin Pitt]

Control: severity 1061370 grave
Control: forcemerge -1 1061370

Matthias Klose [2024-02-01  8:30 +0100]:
> please don't file duplicate reports, see #1061370

Ah, sorry -- it wasn't clear from the title that it was about this problem, nor
was it RC. Marking a duplicate, so that it's easier to find.

Pitti

Bug#1062354: libatomic1: 14-20240127-1 missing libat_test_and_set_1_i2

[Martin Pitt]

Package: libatomic1
Version: 14-20240127-1
Severity: grave
Justification: breaks a lot of unrelated packages

Hello,

yesterday's cockpit armel build failed [1] on armel like this in the
./configure test for the PCP library:

| configure:6158: gcc -o conftest  -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro 
conftest.c -lssh  >&5
| /usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: undefined reference to 
`libat_test_and_set_1_i2'

PCP hasn't changed since the previous build [2]; however, libatomic1 (via
gcc-14) did -- [2] built against libatomic1/gcc 13.2.0-9.

I spot-checked a few of the autopkgtest regressions on the PTS [3], and they
all failed on the exact same issue, e.g. [4].

Thanks!

Martin

[1] 
https://buildd.debian.org/status/fetch.php?pkg=cockpit=armel=310-1=1706722995=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=cockpit=armel=309-1=1705590895=0
[3] https://tracker.debian.org/pkg/gcc-14
[4] https://ci.debian.net/packages/3/389-ds-base/testing/armel/42559327/

Bug#1061825: python-dbusmock autopkg tests fail with Python 3.12

[Martin Pitt]

Control: tag -1 pending

Hallo Matthias,

Matthias Klose [2024-01-29 21:27 +0100]:
> 636s NO TESTS RAN (skipped=4)
> 637s autopkgtest [01:57:06]: test upstream: ---]
> 637s autopkgtest [01:57:06]: test upstream:  - - - - - - - - - - results - -
> - - - - - - - -
> 637s upstream FAIL non-zero exit status 5
>
> now exits with exit value 5 when no tests are run

Thanks for reporting! I can reproduce easily (thanks for making python3.12
available in unstable!). This is indeed a rather welcome change.

Fixed in
https://salsa.debian.org/python-team/packages/python-dbusmock/-/commit/35eccabe574c3d7427a59c201256c2c1e817bace

Pitti

Bug#1061725: Info received (Bug#1061725: libvirt-daemon: Deleting external snapshot for non-running system VM fails with Permission Denied)

[Martin Pitt]

I can't make head or tail of this. aa-complain still enforces deny
rules, there is no (discoverable) way to log deny rules, and

  grep -r deny /etc/apparmor.d | grep virt | grep -v /sys | grep -v /dev

doesn't show anything which would apply to /var/lib/libvirt/.

`aa-disable 
/etc/apparmor.d/libvirt/libvirt-a5aa3a67-6967-43a5-9d61-b0b380bd14e6` also
doesn't work because it references a non-existing
libvirt/libvirt-a5aa3a67-6967-43a5-9d61-b0b380bd14e6.files.

The only thing that works is

  aa-disable libvirtd
  systemctl restart libvirtd

(That requires apparmor-utils)

After that, the snapshot-delete command works.

I don't know what else I could try here to debug this properly, so a hint from
someone AppArmor-savvy would be much appreciated.

Bug#1061725: libvirt-daemon: Deleting external snapshot for non-running system VM fails with Permission Denied

[Martin Pitt]

Control: retitle -1 libvirt-daemon: Deleting external snapshot for non-running 
system VM fails with AppArmor

when stracing libvirt, this is what happens:

6557  openat(AT_FDCWD, "/var/lib/libvirt/images/test2.qcow2", O_RDWR|O_CLOEXEC) 
= -1 EACCES (Permission denied)
6557  sendmsg(13, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="{\"id\": 
\"libvirt-443\", \"error\": {\"class\": \"GenericError\", \"desc\
": \"Could not open '/var/lib/libvirt/images/test2.qcow2': Permission 
denied\"}}\r\n", iov_len=142}], msg_iovlen=1, msg_controllen=0, msg_flags
=0}, 0 

and the most recent geteuid() call responded with "0". So it actually *does*
smell like an AppArmor issue, even though it's weird that it would work for a
running VM then. Running `aa-teardown` before the creation of the VM doesn't
work, nor does "aa-complain libvirtd". But after `dpkg -P apparmor; reboot` it
does work.

So AppArmor breaks this without even logging about it, i.e. some "deny" rule. I
don't know how to make AA log deny rules -- the profile has tons of them
(albeit to /proc, /dev/, etc.), and it's further complicated by the dynamic
profile creation through virt-aa-helper.

As this works in current Ubuntu, it's perhaps worth looking at
https://patches.ubuntu.com/libv/libvirt/libvirt_9.6.0-1ubuntu2.patch
The most plausible one may be 
debian/patches/ubuntu-aa/0031-virt-aa-helper-Ask-for-no-deny-rule-for-readonly-dis.patch
but that requires rebuilding libvirt. But also, that patch is from 2017, and
it's still broken in Ubuntu 22.04.

Bug#1061725: libvirt-daemon: Deleting external snapshot for non-running system VM fails with Permission Denied

[Martin Pitt]

Package: libvirt-daemon
Version: 10.0.0-1

When creating a trivial VM and doing an external snapshot if the VM is *not* 
running,
deleting the snapshot fails. As root:

  qemu-img create -f qcow2 /var/lib/libvirt/images/test1.qcow2 10G
  virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 
--wait 0 --name test1 --disk target=vda,path=/var/lib/libvirt/images/test1.qcow2
  virsh destroy test1
  virsh snapshot-create-as --domain test1 --name snap1 --disk-only --diskspec 
vda,snapshot=external,file=/var/lib/libvirt/images/test1-snap1
  virsh snapshot-delete test1 snap1

The last command fails with

| error: Failed to delete snapshot snap1
| error: internal error: unable to execute QEMU command 'block-commit': Could 
not open '/var/lib/libvirt/images/test1.qcow2': Permission denied

The error message may be a bit misleading -- this is the *image* file, which
has wide-open libvirt-qemu:libvirt-qemu 666 permissions. "test1-snap1" in the
same directory is much more restrictive root:root 644; but even trying to
chown/chmod that doesn't unbreak this. So perhaps it's trying to do something
funky to the actual image file after all.

It also happens with the automatically created disk image, which will then be
IDE "hda", not virtio "vda":

  virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 
--wait 0 --name test2
  virsh destroy test2
  virsh snapshot-create-as --domain test2 --name snap1 --disk-only --diskspec 
hda,snapshot=external,file=/var/lib/libvirt/images/test2-snap1
  virsh snapshot-delete test2 snap1

It works when doing a snapshot from a *running* VM, either disk-only or with 
memory:

  virsh start test1
  virsh snapshot-create-as --domain test1 --name snap2 --disk-only --diskspec 
vda,snapshot=external,file=/var/lib/libvirt/images/test1-snap2
  virsh snapshot-create-as --domain test1 --name snap3 --memspec 
file=/var/lib/libvirt/qemu/snapshot/test1-snap3-memory  --diskspec 
vda,snapshot=external,file=/var/lib/libvirt/images/test1-snap3

Then both snap2 and snap3 can be deleted. But still not snap1, so the running
state matters at the time of snapshot creation, not deletion.

This also happens with libvirt 9.0.0-4 in Debian stable and libvirt
8.0.0-1ubuntu7.8 in Ubuntu 22.04 LTS, but curiously not with libvirt
9.6.0-1ubuntu1 in Ubuntu 23.10. It also works fine in Fedora, CentOS/RHEL 8/9,
and Arch Linux, so this is somehow specific to Debian.

I tried `aa-teardown` just in case it's apparmor, but that doesn't seem to
influence it.

There is no useful/relevant journal message about this other than the
"Permission denied" line that's already on stderr.

I also tried this as user:

  virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 
--wait 0 --name test1
  virsh destroy test1
  virsh snapshot-create-as --domain test1 --name snap1 --disk-only --diskspec 
hda,snapshot=external,file=$HOME/.local/share/libvirt/images/test1-snap1
  virsh snapshot-delete test1 snap1

This works as well. So this is specific to qemu:///system, session works fine.

Martin

Bug#1058214: sosreport: FTBFS -- NMU debdiff

[Martin Pitt]

Hello again,

as promised, I uploaded the fix with the attached debdiff.

Martin
diff -Nru sosreport-4.0/debian/changelog sosreport-4.0/debian/changelog
--- sosreport-4.0/debian/changelog  2021-01-27 15:29:24.0 +0100
+++ sosreport-4.0/debian/changelog  2024-01-10 08:16:54.0 +0100
@@ -1,3 +1,12 @@
+sosreport (4.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/0004-unittest-assertEquals.patch: unittest.TestCase.assertEquals() was
+deprecated in Python 3, and finally dropped in Python 3.12. Fixes FTBFS
+due to unit tests failing. (Closes: #1058214)
+
+ -- Martin Pitt   Wed, 10 Jan 2024 08:16:54 +0100
+
 sosreport (4.0-2) unstable; urgency=medium
 
   * d/p/0003-systemd-prefer-resolvectl-over-systemd-resolve.patch:
diff -Nru sosreport-4.0/debian/patches/0004-unittest-assertEquals.patch 
sosreport-4.0/debian/patches/0004-unittest-assertEquals.patch
--- sosreport-4.0/debian/patches/0004-unittest-assertEquals.patch   
1970-01-01 01:00:00.0 +0100
+++ sosreport-4.0/debian/patches/0004-unittest-assertEquals.patch   
2024-01-10 08:16:40.0 +0100
@@ -0,0 +1,545 @@
+Description: [tests] Drop obsolete TestCase.assertEquals()
+Author: Martin Pitt 
+Bug: https://github.com/sosreport/sos/pull/3467
+Bug-Debian: https://bugs.debian.org/1058214
+
+Index: sosreport-4.0/tests/archive_tests.py
+===
+--- sosreport-4.0.orig/tests/archive_tests.py
 sosreport-4.0/tests/archive_tests.py
+@@ -92,7 +92,7 @@ class TarFileArchiveTest(unittest.TestCa
+ self.tf.add_string('this is my content', 'tests/string_test.txt')
+
+ afp = self.tf.open_file('tests/string_test.txt')
+-self.assertEquals('this is my content', afp.read())
++self.assertEqual('this is my content', afp.read())
+
+ def test_rewrite_file(self):
+ """Test that re-writing a file with add_string() modifies the content.
+@@ -101,7 +101,7 @@ class TarFileArchiveTest(unittest.TestCa
+ self.tf.add_string('this is my new content', 'tests/string_test.txt')
+
+ afp = self.tf.open_file('tests/string_test.txt')
+-self.assertEquals('this is my new content', afp.read())
++self.assertEqual('this is my new content', afp.read())
+
+ def test_make_link(self):
+ self.tf.add_file('tests/ziptest')
+Index: sosreport-4.0/tests/cleaner_tests.py
+===
+--- sosreport-4.0.orig/tests/cleaner_tests.py
 sosreport-4.0/tests/cleaner_tests.py
+@@ -41,12 +41,12 @@ class CleanerMapTests(unittest.TestCase)
+
+ def test_mac_map_skip_ignores(self):
+ _test = self.mac_map.get('ff:ff:ff:ff:ff:ff')
+-self.assertEquals(_test, 'ff:ff:ff:ff:ff:ff')
++self.assertEqual(_test, 'ff:ff:ff:ff:ff:ff')
+
+ def test_mac_map_avoid_duplicate_obfuscation(self):
+ _test = self.mac_map.get('ab:cd:ef:fe:dc:ba')
+ _dup = self.mac_map.get(_test)
+-self.assertEquals(_test, _dup)
++self.assertEqual(_test, _dup)
+
+ def test_ip_map_obfuscate_v4_with_cidr(self):
+ _test = self.ip_map.get('192.168.1.0/24')
+@@ -68,7 +68,7 @@ class CleanerMapTests(unittest.TestCase)
+
+ def test_ip_skip_ignores(self):
+ _test = self.ip_map.get('127.0.0.1')
+-self.assertEquals(_test, '127.0.0.1')
++self.assertEqual(_test, '127.0.0.1')
+
+ def test_hostname_obfuscate_domain_options(self):
+ _test = self.host_map.get('www.redhat.com')
+Index: sosreport-4.0/tests/option_tests.py
+===
+--- sosreport-4.0.orig/tests/option_tests.py
 sosreport-4.0/tests/option_tests.py
+@@ -34,10 +34,10 @@ class GlobalOptionTest(unittest.TestCase
+ ]
+
+ def test_simple_lookup(self):
+-self.assertEquals(self.plugin.get_option('test_option'), 'foobar')
++self.assertEqual(self.plugin.get_option('test_option'), 'foobar')
+
+ def test_cascade(self):
+-self.assertEquals(self.plugin.get_option(('baz')), False)
++self.assertEqual(self.plugin.get_option(('baz')), False)
+
+
+ if __name__ == "__main__":
+Index: sosreport-4.0/tests/plugin_tests.py
+===
+--- sosreport-4.0.orig/tests/plugin_tests.py
 sosreport-4.0/tests/plugin_tests.py
+@@ -123,36 +123,36 @@ class PluginToolTests(unittest.TestCase)
+ ['this is only a test', 'there are only two lines'])
+ test_fo = StringIO(test_s)
+ matches = regex_findall(r".*lines$", test_fo)
+-self.assertEquals(matches, ['there are only two lines'])
++self.assertEqual(matches, ['there are only two lines'])
+
+ def test_regex_findall_miss(self):
+ test_s = u"\n".join(
+ ['this is only a test', 'there are only two lines'])
+ test_fo = StringI

Bug#1058214: sosreport: FTBFS: AttributeError: 'TailTest' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- NMU announcement

[Martin Pitt]

Control: forwarded -1 https://github.com/sosreport/sos/pull/3467
Control: tag -1 upstream pending

Hello Lucas and Eric,

I sent an upstream fix for this to the PR above. Their CI didn't even spot that
error yet (argh big testing gaps).

This has been open for a month now. As this threatens to make all cockpit
packages fall out of testing, I'm going to do an NMU now. The package is
essentially orphaned in Debian: last upload 3 years ago, VCS repo is lagging
behind even more, and Ubuntu package is much newer. So I won't bother with any
extra bureaucracy like delayed uploads. But of course I will attach the NMU
debdiff here.

Thanks,

Martin

Bug#1059467: python-dbusmock: new version 0.30.1-1 causes upower's autopkgtest to fail

[Martin Pitt]

Control: reassign -1 upower 1.90.2-7
Control: tag -1 fixed-upstream pending

The upower test adjustment landed upstream, I'll cherry-pick it into Debian.

Martin

Bug#1059467: python-dbusmock: new version 0.30.1-1 causes upower's autopkgtest to fail

[Martin Pitt]

Control: tag -1 upstream
Control: forwarded -1 
https://gitlab.freedesktop.org/upower/upower/-/merge_requests/207

Hello Luca,

Luca Boccassi [2023-12-26 12:46 +0100]:
> Not sure whether it was a legitimate change and upower's tests need an
> update, or if it is a new bug, but 0.30.1-1 causes src:upower
> autopkgtest to fail and stops migration of a bunch of unrelated
> packages from unstable to testing as debci bundles new packages
> together when testing for regressions, and everything is held back.

Thanks for the report and sorry for the trouble! This is better fixed in
upower's tests IMHO. I sent a fix for upower's tests to the above MR. I'll give
it three days to review (it's holiday season, after all), and will then upload
the fix to Debian's upower either as a cherry-pick or a downstream patch.

Martin

Bug#1059061: libssh: CVE-2023-6004

[Martin Pitt]

Martin Pitt [2023-12-25 11:25 +0100]:
> The new upstream release plus regression fix have propagated to testing, to
> Ubuntu devel, and also is progressing well into Fedora. By now the tests have
> validated it enough for me to be confident in the fixes.
>
> I prepared the security update for Debian 12 bookworm, including a debdiff:
> https://people.debian.org/~mpitt/tmp/

This contains the update for Debian 11 bullseye (oldstable) as well now.

> I'll coordinate the update to oldstable with Sean (see the other thread).

I meant oldoldstable (Debian 10 buster), sorry. I'll leave that to Sean.

Thanks,

Martin

Bug#1059061: libssh: CVE-2023-6004

[Martin Pitt]

Hello Salvatore and all,

Salvatore Bonaccorso [2023-12-22 20:34 +0100]:
> On Fri, Dec 22, 2023 at 04:39:46PM +0100, Martin Pitt wrote:
> > Salvatore Bonaccorso [2023-12-22 13:20 +0100]:
> > > > However, the fix for CVE-2023-6004 caused a regression:
> > > > https://gitlab.com/libssh/libssh-mirror/-/issues/227
> > > > I will monitor this, and include the fix in the security upload once it 
> > > > is
> > > > available (or presumably they'll do a 0.10.7). So if it's alright with 
> > > > you,
> > > > I'll delay the stable-security update for a few days.
> > >
> > > Rigth, it's not that pressing that we get updates out, so let's
> > > monitor this, have 0.10.7 uploaded and exposed as well then to
> > > unstable for a while and then look at bookworm-security. Btw, we will
> > > as well need bullseye-security.
> >
> > Ack. The fix landed upstream, and they said they won't do a 0.10.7 
> > immediately,
> > so I backported it and uploaded as 0.10.6-2 to sid. I threw the whole 
> > cockpit
> > integration test suite at it (which exercises libssh pretty thoroughly via
> > cockpit-ssh), and it is happy.
> >
> > I'll let that simmer for a few days to let it go into testing, and prepare 
> > the
> > security updates soon.
>
> Thanks, that sounds good.

The new upstream release plus regression fix have propagated to testing, to
Ubuntu devel, and also is progressing well into Fedora. By now the tests have
validated it enough for me to be confident in the fixes.

I prepared the security update for Debian 12 bookworm, including a debdiff:
https://people.debian.org/~mpitt/tmp/

Please feel free to dput it yourself, or I can do it if/when you ack.

I'll coordinate the update to oldstable with Sean (see the other thread).

Thanks,

Martin

Bug#1059061: libssh: CVE-2023-6004

[Martin Pitt]

Hello Salvatore,

Salvatore Bonaccorso [2023-12-22 13:20 +0100]:
> > However, the fix for CVE-2023-6004 caused a regression:
> > https://gitlab.com/libssh/libssh-mirror/-/issues/227
> > I will monitor this, and include the fix in the security upload once it is
> > available (or presumably they'll do a 0.10.7). So if it's alright with you,
> > I'll delay the stable-security update for a few days.
>
> Rigth, it's not that pressing that we get updates out, so let's
> monitor this, have 0.10.7 uploaded and exposed as well then to
> unstable for a while and then look at bookworm-security. Btw, we will
> as well need bullseye-security.

Ack. The fix landed upstream, and they said they won't do a 0.10.7 immediately,
so I backported it and uploaded as 0.10.6-2 to sid. I threw the whole cockpit
integration test suite at it (which exercises libssh pretty thoroughly via
cockpit-ssh), and it is happy.

I'll let that simmer for a few days to let it go into testing, and prepare the
security updates soon.

Martin

Bug#1059061: libssh: CVE-2023-6004

[Martin Pitt]

Hello Salvatore,

Salvatore Bonaccorso [2023-12-19 22:34 +0100]:
> The following vulnerability was published for libssh.
>
> CVE-2023-6004[0]:
> | ProxyCommand/ProxyJump features allow injection of malicious code
> | through hostname

I uploaded the new upstream security fix release 0.10.6 to unstable. It can
have a round of autopkgtest regression tests now.

I checked the non-CVE commits between 0.10.5 (in current stable) and 0.10.6:
https://git.libssh.org/projects/libssh.git/log/?h=stable-0.10
and IMHO they are all harmless/useful/targetted enough to be suitable for
stable-security. We did that in the last round as well [1].

However, the fix for CVE-2023-6004 caused a regression:
https://gitlab.com/libssh/libssh-mirror/-/issues/227
I will monitor this, and include the fix in the security upload once it is
available (or presumably they'll do a 0.10.7). So if it's alright with you,
I'll delay the stable-security update for a few days.

Thanks,

Martin

[1] 
https://tracker.debian.org/news/1431896/accepted-libssh-097-0deb11u1-source-into-stable-security/

Bug#1058577: scour: mark packages as "multi-arch: foreign"

[Martin Pitt]

Control: tag -1 pending

Hello IOhannes,

IOhannes m zmoelnig [2023-12-13  8:57 +0100]:
> However, since 'scour' is not marked "Multi-Arch: foreign" (or "Multi-Arch:
> allowed") which makes it somewhat awkward to use when cross-building packages
> (that depend on 'scour').
>
> I would therefore like to ask, whether you could mark the package as being
> usable for cross-building by setting the "Multi-Arch" field as appropriate.

Good idea! That is indeed missing, I added it.

Thanks,

Martin

Bug#1054415: cockpit-ws: remotectl command missing?

[Martin Pitt]

Wim Bertels [2023-10-23 16:06 +]:
> if the manpages are generated correctly:
> https://manpages.debian.org/unstable/cockpit-ws/remotectl.8.en.html
> remotectl is present in unstable and testing as well?

No, it's not any more in testing and unstable: 
https://packages.debian.org/trixie/amd64/cockpit-ws/filelist
it seems manpages.d.o didn't remove the dropped manpage.

> https://manpages.debian.org/bullseye/cockpit-ws/remotectl.8.en.html

It *is* still present in stable (aka bullseye):
https://packages.debian.org/bullseye/amd64/cockpit-ws/filelist , i.e. that
link is correct/current.

Martin

Bug#1054415: cockpit-ws: remotectl command missing?

[Martin Pitt]

Control: tag -1 wontfix

Hello Wim,

wim [2023-10-23 17:16 +0200]:
> it seems the remotectl command is missing (from bookworm and 
> bookworm-backports)?
> (as it was included in bullseye, and is included in testing)

This is intended, see https://cockpit-project.org/blog/cockpit-252.html

Out of interest, why do you need it? If you want to set up a key for cockpit-ws
in advance, there are usually better tools (ansible, linux-system-roles,
LetsEncrypt, etc.), and in the worst case you can still call
/usr/lib/cockpit/cockpit-certificate-ensure .

Martin

Bug#1053112: cockpit FTBFS when systemd.pc changes systemdsystemunitdir

[Martin Pitt]

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/19407
Control: tag -1 upstream pending

Hello Helmut,

Helmut Grohne [2023-09-27 13:46 +0200]:
> We want to change the value of systemdsystemunitdir in systemd.pc to
> point below /usr. cockpit's upstream build system consumes this variable
> while the packaging hard codes its current value. When we change it,
> cockpit will FTBFS. Consider applying the attached patch to avoid the
> failure.

Thanks! I'll handle that via upstream, see the above GitHub PR. That will still
require some CI juggling, but I'll deal with that tomorrow.

Thanks,

Martin

Bug#1044095: cockpit: Fails to build source after successful build

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/19232

Lucas Nussbaum [2023-08-13 16:33 +0200]:
> This package fails to build a source package after a successful build
> (dpkg-buildpackage ; dpkg-buildpackage -S).
> > dpkg-source: error: cannot represent change to 
> > tmp/wheel/cockpit-298-py3-none-any.whl: binary file contents changed
> > dpkg-source: error: add tmp/wheel/cockpit-298-py3-none-any.whl in 
> > debian/source/include-binaries if you want to store the modified binary in 
> > the debian tarball

Thanks for your report! I sent a packaging fix upstream.

Martin

Bug#1043810: cockpit-podman: Fails to build source after successful build

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 
https://github.com/cockpit-project/cockpit-podman/pull/1377

Lucas Nussbaum [2023-08-13 15:17 +0200]:
> > dpkg-source: info: building cockpit-podman using existing 
> > ./cockpit-podman_74.orig.tar.xz
> > dpkg-source: info: local changes detected, the modified files are:
> >  cockpit-podman-74/po/LINGUAS
> > dpkg-source: error: aborting due to unexpected upstream changes, see 
> > /tmp/cockpit-podman_74-1.diff.oxKlRx

Thanks for your report! I sent a PR to fix this.

Martin

Bug#1043775: cockpit-machines: Fails to build source after successful build

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 
https://github.com/cockpit-project/cockpit-machines/pull/1183

Lucas Nussbaum [2023-08-13 15:17 +0200]:
> > dpkg-source: info: building cockpit-machines using existing 
> > ./cockpit-machines_296.orig.tar.xz
> > dpkg-source: info: local changes detected, the modified files are:
> >  cockpit-machines-296/po/LINGUAS
> > dpkg-source: error: aborting due to unexpected upstream changes, see 
> > /tmp/cockpit-machines_296-1.diff.3514Kf

Thanks for your report! I sent an upstream PR to fix this.

Martin

Bug#1043322: cockpit-tests: prone to loosing /lib/systemd/system/cockpit.service.d during /usr-merge

[Martin Pitt]

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/19188

Hello Helmut,

Helmut Grohne [2023-08-08 12:38 +0200]:
> cockpit-tests has a non-trivial aspect when it comes to finalizing the
> /usr-merge. As we move all files from / to /usr, we'll likely also move
> /lib/systemd/system/cockpit.service.d. Such a move is currently
> prevented by the CTTE moratorium, but we are preparing for lifting that
> and this bug is part of that preparation. When performing that move for
> cockpit-tests, dpkg will delete this particular directory during package
> upgrade. Thus the dpkg database will be inconsistent with the actual
> filesystem, which generally is a bad outcome.

Thanks for pointing this out! I'm all for clearing up all obstacles for getting
usrmerge over the line at last. I wasn't even aware that we ship that
directory. https://packages.debian.org/sid/amd64/cockpit-tests/filelist
doesn't have it, but I suppose that doesn't show empty directories.

> I'm attaching a patch for your convenience and hope you agree.

You didn't actually, but it's fairly straightforward (I think). I sent an
upstream PR to fix that. I didn't test it at all, let's see what CI says -- but
I'm fairly sure about it.

If all goes well, that can go into today's release, then I can fix this in sid
in the next day or two.

Cheers!

Martin

Bug#1042367: bookworm cloud images missing since 20230725 (only backports images)

[Martin Pitt]

Package: cloud.debian.org

Until https://cloud.debian.org/images/cloud/bookworm/daily/20230724-1451/ we
still had debian-12-{azure,ec2,generic,...}. But in
https://cloud.debian.org/images/cloud/bookworm/daily/20230725-1452/ and also
https://cloud.debian.org/images/cloud/bookworm/daily/20230726-1453/ there are
only debian-12-backports-* variants.

We could adjust our scripts for the renaming, but this smells like a bug --
it may be nice to have cloud images with some/all backports enabled, but can we
also have the "pure bullseye" images back?

Thank you!

Martin

Bug#1040803: Please update dependency on libblockdev-mdraid2

[Martin Pitt]

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/19092
Control: tag -1 pending

Hello Michael,

Michael Biebl [2023-07-10 22:37 +0200]:
> the latest update of libblockdev from version 2.28 to 3.0 has seen some
> major changes, among them an SONAME bump.
>
> Please test cockpit(-storaged) against the new libblockdev and update
> the libblockdev-mdraid2 dependency to libblockdev-mdraid3.

Thanks for the heads-up! I'll fix this for this Wednesday's release, see PR
above.

Pitti

Bug#1038925: Acknowledgement (Leaving IPA domain fails: Some installation state for ntp has not been restored)

[Martin Pitt]

One workaround that I found is to delete the [ntp] section from
/var/lib/ipa-client/sysrestore/sysrestore.state after joining.

  sed -i '/\[ntp\]/,/^$/ d' /var/lib/ipa-client/sysrestore/sysrestore.state

Bug#1038689: pbuilder: creates /etc/pbuilderrc with invalid (debug repo) MIRRORSITE -- does not parse *.sources files

[Martin Pitt]

Hello all,

Thorsten Glaser [2023-06-20 19:39 +]:
> Ideally, let debootstrap use its default if no pbuilderrc.

Yes, agreed.

Thanks,

Martin

Bug#1038689: pbuilder: creates /etc/pbuilderrc with invalid (debug repo) MIRRORSITE -- does not parse *.sources files

[Martin Pitt]

Package: pbuilder
Version: 0.231

I am trying to create a pbuilder on today's amd64 cloud image.

`pbuilder --create --debug` eventually fails with

| + debootstrap --include=apt --cache-dir=/var/cache/pbuilder/aptcache/ 
--variant=buildd --force-check-gpg bookworm /var/cache/pbuilder/build/26079 
http://debug.mirrors.debian.org/debian-debug/
| E: Failed getting release file 
http://debug.mirrors.debian.org/debian-debug/dists/bookworm/Release

This is a wrong URL -- the suite is called "bookworm-debug", i.e. it should be
http://debug.mirrors.debian.org/debian-debug/dists/bookworm-debug/Release
(which does exist).

My only customization is

| # cat ~/.pbuilderrc
| DISTRIBUTION=bookworm
| PBUILDERSATISFYDEPENDSCMD=true

/etc/pbuilderrc has

> MIRRORSITE=http://debug.mirrors.debian.org/debian-debug/

which is wrong -- this ought to be a mirror for the main repo, not
for the debug one. /usr/share/pbuilder/pbuilderrc certainly has
"MIRRORSITE=http://deb.debian.org/debian; as default. So, something on "apt
install pbuilder" causes /etc/pbuilderrc to be created like the above.

So the auto-detection goes wrong. /etc/apt/sources.list is empty, the only
sources that I have is the default one:

| # cat /etc/apt/sources.list.d/debian.sources
| Types: deb deb-src
| URIs: mirror+file:///etc/apt/mirrors/debian.list
| Suites: bookworm bookworm-updates bookworm-backports
| Components: main
|
| Types: deb deb-src
| URIs: mirror+file:///etc/apt/mirrors/debian-security.list
| Suites: bookworm-security
| Components: main

and my custom one:

# cat /etc/apt/sources.list.d/dbgsym.list
deb http://debug.mirrors.debian.org/debian-debug/ bookworm-debug main

I tried to rename dbgsym.list to debug.list (so that it sorts after
"debian.sources"), and purging/reinstalling pbuilder still creates a wrong
MIRRORSITE. When I remove dbgsym.list entirely, installing pbuilder brings up a
debconf prompt about "Default mirror not found".

So it smells like pbuilder's auto-detection cannot parse the (not-so-)new style
*.sources files?

Thanks,

Martin

Bug#1036026: unblock: libssh/0.10.5-1

[Martin Pitt]

Control: tag -1 -moreinfo
Control: retitle -1 unblock: libssh/0.10.5-2

Hello Sebastian,

Sebastian Ramacher [2023-05-16 22:49 +0200]:
> It's too late for debhelper compat bumps. See 
> https://release.debian.org/bookworm/FAQ.html
>
> Please re-upload without that change and remove the moreinfo tag once
> that happened.

Good point. I reverted the change [1], resulting in attached debdiff. Uploaded
as libssh_0.10.5-2.dsc.

Thanks,

Martin

[1] https://salsa.debian.org/debian/libssh/-/commit/49823ffd5c9ce8
diff -Nru libssh-0.10.5/debian/changelog libssh-0.10.5/debian/changelog
--- libssh-0.10.5/debian/changelog  2023-05-10 06:00:26.0 +
+++ libssh-0.10.5/debian/changelog  2023-05-17 19:56:56.0 +
@@ -1,3 +1,10 @@
+libssh (0.10.5-2) unstable; urgency=medium
+
+  * Revert "Bump debhelper from old 12 to 13."
+This is not appropriate at this point of the release cycle any more.
+
+ -- Martin Pitt   Wed, 17 May 2023 19:56:56 +
+
 libssh (0.10.5-1) unstable; urgency=high
 
   [ Martin Pitt ]
diff -Nru libssh-0.10.5/debian/control libssh-0.10.5/debian/control
--- libssh-0.10.5/debian/control2023-05-10 06:00:26.0 +
+++ libssh-0.10.5/debian/control2023-05-17 19:56:56.0 +
@@ -4,7 +4,7 @@
 Maintainer: Laurent Bigonville 
 Uploaders: Mike Gabriel , Martin Pitt 
 Build-Depends: cmake (>= 2.8.5),
-   debhelper-compat (= 13),
+   debhelper-compat (= 12),
libcmocka-dev ,
libgcrypt-dev,
libkrb5-dev | heimdal-dev,


signature.asc
Description: PGP signature

Bug#1036153: packagekit: Regression: installing 1.2.6-4 stopped providing `pkcon` due to not recommending -tools any more

[Martin Pitt]

Package: packagekit
Severity: important
Version: 1.2.6-4

With the latest update to Debian testing, existing installations lost the
`pkcon` program. We explicitly install `packagekit` into our VMs, and so far
this has always provided pkcon.

The recent release dropped the recommendation from the library [1], which seems
fine. However, it also had another change "packagekit: Recommend, instead of
suggest appstream"; that commit also demoted the "packagekit-tools"
recommendation to suggests. This was not documented, and I suppose it was just
an accident?

Can you please revert this? Not really RC, but a rather unexpected change that
late in the release cycle.

Thanks!

Martin

[1] 
https://salsa.debian.org/pkgutopia-team/packagekit/-/commit/45f033c60bbced49ea4954dcef83df9f3ca269f2
[2] 
https://salsa.debian.org/pkgutopia-team/packagekit/-/commit/95cd3a7d069865502ef9afd805a00f6b89d0d5c5

Bug#1036026: unblock: libssh/0.10.5-1

[Martin Pitt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: lib...@packages.debian.org
Control: affects -1 + src:libssh

Hello,

a few days ago, a new libssh upstream microrelease [1] was published which fixes
two CVEs. I packaged it for unstable four days ago, it built everywhere, and
thus passed the (rather extensive) upstream tests, as well as the autopkgtest
integration tests everywhere [2]. I know one big consumer of libssh well -- 
cockpit
-- which also has successful tests against 0.10.5.

The packaging git already had a few rather harmless updates from the Debian
janitor [3] which I included into the unstable upload. I attached the debian/*
parts of the debdiff between current testing and unstable. If you want to
inspect the full upstream diff as  well, I suggest the upstream git view for
the stable 0.10 branch [4], or the full debdiff view  on salsa[5].

Salvatore Bonaccorso from the security team pointed out that libssh won't
auto-migrate any more at this point in time, so I'd like to coordinate these
two CVEs with you for fixing testing. If you consider 0.10.5 too risky at this
point, I can also prepare a backport similar to the update that I prepared for
stable-security, but it's more work, and backporting non-trivial patches is
also not risk-free. This gets coordinated in [6].

Thanksk,

Martin

unblock libssh/0.10.5-1


[1] 
https://www.libssh.org/2023/05/04/libssh-0-10-5-and-libssh-0-9-7-security-releases/
[2] https://tracker.debian.org/pkg/libssh
[3] 
https://salsa.debian.org/debian/libssh/-/commit/45b9437b4c4711584dba7debe6600aa2a2d7f6c4

https://salsa.debian.org/debian/libssh/-/commit/5feb4c4e0405e6af69d6d448ab934f7876d2ea90

https://salsa.debian.org/debian/libssh/-/commit/8e55b07477c194630bd60c049ca28c57da2881fd
[4] https://git.libssh.org/projects/libssh.git/log/?h=stable-0.10
[5] 
https://salsa.debian.org/debian/libssh/-/compare/4066480562aa1d2682bd5c831c1acd2a2777...debian?from_project_id=20695=false
[6] https://bugs.debian.org/1035832
--- libssh-0.10.4/debian/changelog  2022-09-19 08:41:22.0 +
+++ libssh-0.10.5/debian/changelog  2023-05-10 06:00:26.0 +
@@ -1,3 +1,26 @@
+libssh (0.10.5-1) unstable; urgency=high
+
+  [ Martin Pitt ]
+  * New upstream security release (thus high urgency):
+- Fix authenticated remote DoS through potential NULL dereference during 
rekeying
+  with algorithm guessing (CVE-2023-1667)
+  https://www.libssh.org/security/advisories/CVE-2023-1667.txt
+- Client authentication bypass in pki_verify_data_signature() in low-memory
+  conditions with OpenSSL backend; gcrypt backend is not affected
+  https://www.libssh.org/security/advisories/CVE-2023-2283.txt
+  (CVE-2023-2283, Closes: #1035832)
+  * Bump Standards-Version to 4.6.2. No changes necessary.
+  * Drop debian/source/lintian-overrides. It now causes a "mismatched-override"
+warning, and apparently is not necessary any more.
+  * debian/copyright: Drop files which don't exist any more.
+Spotted by lintian's "superfluous-file-pattern" warnings.
+
+  [ Debian Janitor ]
+  * Bump debhelper from old 12 to 13.
+  * Avoid explicitly specifying -Wl,--as-needed linker flag.
+
+ -- Martin Pitt   Wed, 10 May 2023 08:00:26 +0200
+
 libssh (0.10.4-2) unstable; urgency=medium

   * autopkgtest: Drop valgrind run. This hasn't worked for years on many
diff -Nru libssh-0.10.4/debian/control libssh-0.10.5/debian/control
--- libssh-0.10.4/debian/control2022-09-19 08:41:22.0 +
+++ libssh-0.10.5/debian/control2023-05-10 06:00:26.0 +
@@ -4,7 +4,7 @@
 Maintainer: Laurent Bigonville 
 Uploaders: Mike Gabriel , Martin Pitt 
 Build-Depends: cmake (>= 2.8.5),
-   debhelper-compat (= 12),
+   debhelper-compat (= 13),
libcmocka-dev ,
libgcrypt-dev,
libkrb5-dev | heimdal-dev,
@@ -15,7 +15,7 @@
pkg-config,
python3:any ,
 Build-Depends-Indep: doxygen , graphviz 
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Vcs-Git: https://salsa.debian.org/debian/libssh.git
 Vcs-Browser: https://salsa.debian.org/debian/libssh
@@ -97,6 +97,7 @@
 Suggests: doc-base
 Depends: ${misc:Depends}
 Build-Profiles: 
+Multi-Arch: foreign
 Description: tiny C SSH library - Documentation files
  The ssh library was designed to be used by programmers needing a working SSH
  implementation by the mean of a library. The complete control of the client
diff -Nru libssh-0.10.4/debian/copyright libssh-0.10.5/debian/copyright
--- libssh-0.10.4/debian/copyright  2022-09-19 08:41:22.0 +
+++ libssh-0.10.5/debian/copyright  2023-05-10 06:00:26.0 +
@@ -23,7 +23,6 @@
tests/client/torture_connect.c
tests/client/torture_knownhosts.c
tests/client/torture_session.c
-   tests/te

Bug#1035832: libssh: CVE-2023-1667 CVE-2023-2283 -- stable (bullseye) update prepared

[Martin Pitt]

Hello security team,

Martin Pitt [2023-05-10  8:19 +0200]:
> I'll attempt to backport the fixes for stable now.
> https://git.libssh.org/projects/libssh.git/log/?h=stable-0.9 has quite some
> changes before and beyond the actual security fix: some memory leak fixes,
> moving some code around, indentation fixes, more unit tests. Personally I'd
> rather trust upstream's release validation and update to 0.9.7 wholesale than
> trying to pick it apart, but how is the Debian security team stanza wrt.
> upstream microreleases these days?

I prepared a security update for the two CVEs, plus four "reformat code"
cherry-picks which changed the actual security fix from "hairy and risky" to
"only causes minor and obvious conflicts".

  
https://salsa.debian.org/debian/libssh/-/commit/5aa68cee3d2e8a50402ef77623ff8ceac9eb183c
  
https://salsa.debian.org/debian/libssh/-/commit/baa5cda9287580b16d3ecd9ecfc7fef82f2e12c2

They were taken from
https://git.libssh.org/projects/libssh.git/log/?h=stable-0.9 as "95% clean"
cherry-picks, which I found the best compromise wrt. minimizing risk. See the
Debian commit messages for details. I built the package in a clean bullseye
container, unit tests and autopkgtest pass.

The commit messages are more wordy than appropriate for the changelog. I'd use
a similar format as for unstable [1], e.g.

-- ✂️ --
   * Fix authenticated remote DoS through potential NULL dereference
 during rekeying with algorithm guessing (CVE-2023-1667)
 https://www.libssh.org/security/advisories/CVE-2023-1667.txt
   * Fix client authentication bypass in pki_verify_data_signature()
 in low-memory conditions with OpenSSL backend; gcrypt backend is
 not affected (CVE-2023-2283, Closes: #1035832)
 https://www.libssh.org/security/advisories/CVE-2023-2283.txt
-- ✂️ --

I'm happy to upload to the queue if/once you give me the signal, or massage the
patches/changelog according to your liking.

Thanks,

Martin

[1] https://git.libssh.org/projects/libssh.git/log/?h=stable-0.9

Bug#1035832: libssh: CVE-2023-1667 CVE-2023-2283

[Martin Pitt]

Control: tag -1 pending

Hello Salvatore,

Salvatore Bonaccorso [2023-05-09 22:30 +0200]:
> The following vulnerabilities were published for libssh.
>
> CVE-2023-1667[0]:
> | Potential NULL dereference during rekeying with algorithm guessing
>
> CVE-2023-2283[1]:
> | Authorization bypass in pki_verify_data_signature
>
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

I uploaded the new upstream release to unstable, with urgency=high to hopefully
make it into the release in time. With upstream's extensive unit tests and
Debian's reverse dependency autopkgtesting etc. I have enough confidence in
that.

I also checked buster. It's not affected by CVE-2023-2283, that code does not
exist in the 0.8 branch at all. The code for CVE-2023-1667 does exist, but it
is wildly different. Upstream does not maintain the 0.8 branch any more, and
I'm afraid I will not have the time/skills to analyze, understand, and backport
the patches myself, at least not to an extent where I'd have faith in them.

I'll attempt to backport the fixes for stable now.
https://git.libssh.org/projects/libssh.git/log/?h=stable-0.9 has quite some
changes before and beyond the actual security fix: some memory leak fixes,
moving some code around, indentation fixes, more unit tests. Personally I'd
rather trust upstream's release validation and update to 0.9.7 wholesale than
trying to pick it apart, but how is the Debian security team stanza wrt.
upstream microreleases these days?

Thanks,

Martin

Bug#1035546: python3-pip: pip install ignores explicit --prefix=/usr (even with --root)

[Martin Pitt]

Hello again,

I just locally reverted [1], and it's still the same, so that Debian patch
actually isn't to blame.

I also tried --prefix=/opt which then gets me /opt/local/{bin,lib}. So this
behaviour directly contradicts the --help documentation:

>  --prefix   Installation prefix where lib, bin and other
>  top-level folders are placed

It's also not about my local wheel --

rm -rf /tmp/i; python3 -m pip install --root=/tmp/i --prefix=/opt 
small-timer
find /tmp/i

again gives /tmp/i/opt/local/lib/python3.11/dist-packages/small_timer

So this "/local" thing is both sticky and hard to avoid..

Martin

[1] 
https://salsa.debian.org/python-team/packages/python-pip/-/blob/master/debian/patches/hands-off-system-packages.patch

Bug#1035546: python3-pip: pip install ignores explicit --prefix=/usr (even with --root)

[Martin Pitt]

Hello all,

Is that patch even necessary still? In Fedora with python3-pip 2.22.3,
`sudo pip install python-dbusmock` installs into
/usr/local/lib/python3.11/site-packages/dbusmock/ , i.e. does not conflict
with /usr any more. They do have a more targetted protection of /usr [1], but
no general path mangling in their other patches [2].

Thanks,

Martin

[1] 
https://src.fedoraproject.org/rpms/python-pip/blob/rawhide/f/remove-existing-dist-only-if-path-conflicts.patch
[2] https://src.fedoraproject.org/rpms/python-pip/tree/rawhide

Bug#1035546: python3-pip: pip install ignores explicit --prefix=/usr (even with --root)

[Martin Pitt]

Package: python3-pip
Version: 23.0.1+dfsg-1

My upstream project (cockpit) is soon going to deliver a new Python component,
where it installs a locally built wheel (i.e. some Python packages and
auto-generated executable wrappers) with

python3 -m pip install --no-index --force-reinstall --root='$(DESTDIR)/' 
--prefix='$(prefix)' tmp/pybuild/dist/*.whl

This works fine on Fedora, but not on Debian:

   rm -rf /tmp/i
   python3 -m pip install --no-index --force-reinstall --root=/tmp/i 
--prefix=/usr tmp/pybuild/dist/*.whl
   find /tmp/i

This shows that everything gets installed into /tmp/i/usr/local , i.e. /bin,
lib/python3.11, etc.

I'm quite sure this is somehow related to the Debian magic of not installing
into /usr [1][2], but this is happening during *building* a Debian package,
with --root.

It seems to me that (1) explicitly specifying --prefix=/usr should still be
respected, and not silently be changed to /usr/local (as a *default*,
/usr/local/ is fine of course). And (2) perhaps this change shouldn't be
applied with --root?

Do you know a workaround for this? I can't simply move debian/tmp/usr/local/*
to debian/tmp/usr/, as the upstream build system already assumes that a wheel
binary lands in DESTDIR/usr/bin/, i.e. `make install` is just broken.

Thanks,

Martin

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771794
[2] 
https://salsa.debian.org/python-team/packages/python-pip/-/blob/master/debian/patches/hands-off-system-packages.patch

Bug#1033963: curl: 7.88 breaks --unix connection

[Martin Pitt]

Package: curl
Version: 7.88.1-7
Severity: important
Tags: upstream fixed-upstream

Upstream version 7.88 broke the `--unix` option. When doing something like

curl -k --unix /run/cockpit/sock https://dummy

it now fails with

curl: (7) Failed to connect to dummy port 443 after 0 ms: Couldn't connect 
to server

i.e. it tries to connect to the TCP port 443, instead of the Unix socket. This
was reported [1] and fixed [2] upstream over a month ago.

Filing severity important, as I wouldn't want to see bookworm released with
this regression -- curl is an important debugging and scripting tool, and this
has the potential to cause quite a lot of frustration and breakage. So feel
free to raise to "serious" even.

This is fixed in curl 8.0.0. Upstream says "curl8 is fully compatible to 7.88
and introduces no new features", so it may even be appropriate for
unstable→testing at this point. Or you backport the fix [2], which is fairly
confined.

Thanks for considering,

Martin

[1] https://github.com/curl/curl/issues/10633
[2] https://github.com/curl/curl/pull/10641

Bug#1032990: podman: user containers are completely broken with sssd: insufficient UIDs or GIDs available in user namespace

[Martin Pitt]

Control: reassign -1 sssd-common 2.8.2-3
Control: affects -1 podman
Control: retitle -1 sssd-common" subids nsswitch.conf entry breaks user 
sub[ug]ids
Control: severity -1 serious

Matej Marusak [2023-04-03 14:00 +]:
> This is easily reproducible by:
> - Download newest image, e.g. 
> https://cloud.debian.org/images/cloud/bullseye/daily/20230403-1339/debian-11-genericcloud-amd64-daily-20230403-1339.qcow2
> - Install podman and sssd-tools and sssd-dbus. It works fine without sssd
> - Login as 'admin' user
> - podman pull debian
>
> This command fails with:
> ERRO[0004] While applying layer: ApplyLayer stdout:  stderr: potentially 
> insufficient UIDs or GIDs available in user namespace (requested 0:42 for 
> /etc/gshadow): Check /etc/subuid and /etc/subgid if configured locally and 
> run podman-system-migrate: lchown /etc/gshadow: invalid argument exit status 1
> Error: copying system image from manifest list: writing blob: adding layer 
> with blob 
> "sha256:3e440a7045683e27f8e2fa04000e0e078d8dfac0c971358ae0f8c65c13321c8e": 
> ApplyLayer stdout:  stderr: potentially insufficient UIDs or GIDs available 
> in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and 
> /etc/subgid if configured locally and run podman-system-migrate: lchown 
> /etc/gshadow: invalid argument exit status 1

Indeed this is a regression in sssd-common. Its postinst now does

| # Automatically added by dh_installnss/1.7
| if [ "$1" = "configure" ] && [ -f 
"${DPKG_ROOT}/etc/nsswitch.conf.nss.${DPKG_MAINTSCRIPT_PACKAGE}-will-install" ] 
&& [ -e "${DPKG_ROOT}/etc/nsswitch.conf" ] ; then
| if ! grep -q -E  -e '^subid:[^#]*\s(sss)(\s|#|$)' 
"${DPKG_ROOT}/etc/nsswitch.conf" ; then
| # Installing subid/sss from sssd-common in position last
| sed -E -i "${DPKG_ROOT}/etc/nsswitch.conf" -e 
'/^subid:\s[^#]*$/ s/$/ sss/' -e '/^subid:\s.*#/ s/#/ sss #/'
| fi
| rm 
"${DPKG_ROOT}/etc/nsswitch.conf.nss.${DPKG_MAINTSCRIPT_PACKAGE}-will-install"
| fi

Which the previous version didn't do. This causes this entry in
/etc/nsswitch.conf:

   subid:  sss

... which is broken:

   # getsubids admin
   Error fetching ranges

It works with "subuid: files sss" or with dropping that line altogether, so
that it goes back to reading /etc/sub[ug]id:

   # getsubids admin
   0: admin 10 65536

Either this postinst snippet forgets to add "files" or it forgets to systemctl
enable whichever service is supposed to respond to the "sss" service for
"subid".

Raising to RC, as this breaks unrelated software, and this change happened
during freeze already.

Thanks,

Martin

Bug#1032990: podman: Better reproducer

[Martin Pitt]

Control: retitle -1 podman: user containers are completely broken with sssd: 
insufficient UIDs or GIDs available in user namespace

Matej Marusak [2023-04-03 14:00 +]:
> The original reproducer was not clear how important this failure is. It
> efectively means that rootless podman is unusable on any system with
> sssd.

Thanks Matej, retitling accordingly to make this easier to find. The original
title is too obscure.

Martin

Bug#1027050: growing image fails to boot: /scripts/local-bottom/growroot: line 97: wait-for-root: not found

[Martin Pitt]

Hello Santiago,

Santiago Vila [2023-02-18  0:26 +0100]:
> Martin Pitt wrote:
> > The "flock: not found" is #1014662, but that is already present in our 
> > current
> > image with cloud-initramfs-tools 0.18.debian8, and does not seem fatal. So 
> > far
> > the "wait-for-root: not found" seems to be the culprit?
>
> That's what it seems, yes. There is a fix here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014662#34
>
> I've just tested it and it seems to work.

I tested it as well, and confirm that it works. I left a review in the Salsa MR:
https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/2

Thanks!

Martin

Bug#1027050: growing image fails to boot: /scripts/local-bottom/growroot: line 97: wait-for-root: not found

[Martin Pitt]

Package: cloud-initramfs-growroot
Version: 0.18.debian11
Severity: important

In our CI we recently tried to refresh our Debian testing image [1], which
exposed a regression: Trying to resize the image with

qemu-resize  20G

leads to a boot failure:

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... 
done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.38.1
[/sbin/fsck.ext4 (1) -- /dev/vda1] fsck.ext4 -a -C0 /dev/vda1
/dev/vda1: clean, 118601/647168 files, 1027851/2588667 blocks
done.
[1.064055] EXT4-fs (vda1): mounted filesystem with ordered data mode. 
Quota mode: none.
done.
Begin: Running /scripts/local-bottom ... [1.086933] EXT4-fs (vda1): 
unmounting filesystem.
GROWROOT: WARNING: resize failed: failed [flock:127] flock -x 9
/sbin/growpart: line 714: flock: not found
FAILED: Error while obtaining exclusive lock on /dev/vda
[1.114862] GPT:Primary header thinks Alt. header is not at the end of 
the disk.
[1.115544] GPT:20971519 != 41943039
[1.115927] GPT:Alternate GPT header not at the end of the disk.
[1.116488] GPT:20971519 != 41943039
[1.116806] GPT: Use GNU Parted to correct GPT errors.
[1.117273]  vda: vda1 vda14 vda15
/scripts/local-bottom/growroot: line 97: wait-for-root: not found
done.
Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev 
failed: No such file or directory
mount: mounting /dev on /root/dev failed: No such file or directory
done.
mount: mounting /run on /root/run failed: No such file or directory
BusyBox v1.35.0 (Debian 1:1.35.0-4) multi-call binary.

Usage: run-init [-d CAP,CAP...] [-n] [-c CONSOLE_DEV] NEW_ROOT NEW_INIT 
[ARGS]
[...]

and it lands in the (initramfs) interactive prompt. Pressing Enter then just
quickly fails to boot:

(initramfs)
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
/init: line 331: can't open /root/dev/console: no such file
[   10.166875] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0100

The "flock: not found" is #1014662, but that is already present in our current
image with cloud-initramfs-tools 0.18.debian8, and does not seem fatal. So far
the "wait-for-root: not found" seems to be the culprit?

The image build log [2] has a list of all package changes at the bottom. This
includes the kernel (6.0.10-2 -> 6.0.12-1) and two handful of other packages,
but the single one that stands out is

  cloud-initramfs-tools (0.18.debian8 -> 0.18.debian11)

Thanks,

Martin

[1] https://github.com/cockpit-project/bots/pull/4189
[2] 
https://cockpit-logs.us-east-1.linodeobjects.com/image-refresh-logs/debian-testing-20221220-225656.log

Bug#1025556: cockpit-system: recommends transitional policykit-1 package

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/18000

Hey Simon,

Simon McVittie [2022-12-06 13:20 +]:
> This package has a Recommends on the transitional package policykit-1,
> which has been separated into polkitd, pkexec and (deprecated)
> polkitd-pkla packages. The Recommends is on sudo | policykit-1, which I
> suspect should probably become sudo | pkexec.

Thanks for the notice! I sent an upstream PR to update the dependency.

> For packages that are expected to be backported to bullseye, it's OK to
> use an alternative dependency: polkitd | policykit-1 and/or
> pkexec | policykit-1.

That's very much necessary still, as I both backport to Debian 11, and Ubuntu
did not even get the package split yet. It's stuck in proposed for a month:
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#policykit-1
mostly due to duktape not being in main (that needs a main inclusion
report/check first), and some gvfs regression.

Thanks,

Martin

Bug#1025455: libssh-dev: DSA support is disabled by default

[Martin Pitt]

Hello Vagrant,

CC'ing the upstream maintainers, in case I speak nonsense here.

Vagrant Cascadian [2022-12-04 16:45 -0800]:
> In libssh 0.10.x versions, DSA support is deprecated and disabled by
> default.

This was indeed intended [1].

> This causes test suite failures when building guile-ssh which
> tests support for DSA keys.
>
> The attached patch enables DSA support, as was supported in previous
> versions.
> -DEB_CMAKE_EXTRA_FLAGS := -DBUILD_STATIC_LIB=ON 
> -DLIB_INSTALL_DIR=/usr/lib/$(DEB_HOST_MULTIARCH) -DUNIT_TESTING=$(if $(filter 
> nocheck,$(DEB_BUILD_OPTIONS)),OFF,ON) -DWITH_GSSAPI=ON
> +DEB_CMAKE_EXTRA_FLAGS := -DBUILD_STATIC_LIB=ON 
> -DLIB_INSTALL_DIR=/usr/lib/$(DEB_HOST_MULTIARCH) -DUNIT_TESTING=$(if $(filter 
> nocheck,$(DEB_BUILD_OPTIONS)),OFF,ON) -DWITH_GSSAPI=ON -DWITH_DSA=ON

> If that is not an option in time for bookworm freeze, please let me know
> ASAP so I can patch guile-ssh instead.

If at all possible, I'd rather not enable it in the Debian package. DSA isn't
an acceptable crypt algorithm any more, and I'd rather not support it for
another Debian release. OpenSSH deprecated it two years ago [2], the Fedora
package does not enable it either [3], and libssh upstream will remove it in
the next major version.

Can guile-ssh be built easily without DSA support? If so, that'd be great (and
then let's reassign or just close this bug). Otherwise I can have a look and
help you with disabling the DSA feature in guile.

Thanks,

Martin

[1] https://www.libssh.org/2022/08/26/libssh-0-10-0/
[2] http://www.openssh.com/legacy.html
[3] https://src.fedoraproject.org/rpms/libssh/blob/rawhide/f/libssh.spec#_74


signature.asc
Description: PGP signature

Bug#1022788: cockpit: FTBFS on armel/mipsel/mips64el: dh_auto_test failures

[Martin Pitt]

Control: tag -1 fixed-upstream pending

Hello again,

Martin Pitt [2022-10-26  6:04 +0200]:
> Argh, this keeps haunting us. We already tried to fix that in [1] and [2], but
> no way. Why must glib be so unpredictable? 

> [2] https://github.com/cockpit-project/cockpit/pull/17755

Nevermind.. [2] is part of release 278, and I just didn't package that yet 
will do now!

Martin

Bug#1022788: cockpit: FTBFS on armel/mipsel/mips64el: dh_auto_test failures

[Martin Pitt]

Hello Michael, hello Lis,

Michael Biebl [2022-10-26  1:41 +0200]:
> cockpit seems to fail its test suite on the aforementioned architectures

Thanks for the report!

> on armel:
> ~
> Bail out! GLib-FATAL-WARNING: GChildWatchSource: Exit status of a child 
> process was requested but ECHILD was received by waitpid(). See the 
> documentation of g_child_watch_source_new() for possible causes.
>
> (test-channelresponse:13227): GLib-WARNING **: 11:53:58.590: 
> GChildWatchSource: Exit status of a child process was requested but ECHILD 
> was received by waitpid(). See the documentation of 
> g_child_watch_source_new() for possible causes.
> **

Argh, this keeps haunting us. We already tried to fix that in [1] and [2], but
no way. Why must glib be so unpredictable? 

Lis, WDYT about just running this particular check in upstream CI (env var or
so?), and not during downstream `make check`?

Thanks,

Martin

[1] https://github.com/cockpit-project/cockpit/pull/17728
[2] https://github.com/cockpit-project/cockpit/pull/17755

Bug#1019260: libssh: Import new upstream version

[Martin Pitt]

Hello Bastian,

Bastian Germann [2022-09-06 14:21 +0200]:
> Please update libssh to the latest 0.10.x version.
> This has many added features including official OpenSSL 3 support.

Indeed, it's been on my radar for a while. I held it back as there was quite a
serious regression with handling old DSS keys 
(https://gitlab.com/libssh/libssh-mirror/-/issues/145).

This got fixed and released now 
(https://www.libssh.org/2022/09/05/libssh-0-10-3/),
so I think it's time to package it. I'll get to it in the next days.

Martin

Bug#1016064: rpcbind: rpcbind.service fails with "cannot get uid of '_rpc': Success"

[Martin Pitt]

Martin Pitt [2022-07-26 11:58 +0200]:
> A fresh installation of rpcbind fails to start the service:

This can also be seen on package installation [1]:

   Setting up rpcbind (1.2.6-5) ...
   /usr/lib/tmpfiles.d/rpcbind.conf:2: Failed to resolve user '_rpc': No such 
process

Martin

[1] https://logs.cockpit-project.org/logs/image-refresh-3664-20220726-100606/log


signature.asc
Description: PGP signature

Bug#1016064: rpcbind: rpcbind.service fails with "cannot get uid of '_rpc': Success"

[Martin Pitt]

Package: rpcbind
Version: 1.2.6-4
Severity: serious

A fresh installation of rpcbind fails to start the service:

systemd[1]: Starting RPC bind portmap service...
rpcbind[314]: cannot get uid of '_rpc': Success
systemd[1]: rpcbind.service: Main process exited, code=exited, 
status=1/FAILURE
systemd[1]: rpcbind.service: Failed with result 'exit-code'.
systemd[1]: Failed to start RPC bind portmap service.

That's because the `_rpc` user does not exist. Upgrading from an earlier image
(with 1.2.6-3) works because earlier versions created it:

# id _rpc
uid=108(_rpc) gid=65534(nogroup) groups=65534(nogroup)

Release -4 said "Remove obsolete debian/postinst file", and most of it may be
obsolete, but not this bit:

if [ "$1" = configure ] ; then
# run daemon as non-root (see #852066)
adduser --force-badname --system --quiet --home /run/rpcbind 
--no-create-home _rpc

Please put this back. Or better yet, use systemd's User=, DynamicUser=, and
RuntimeDirectory= options to contain all of the setup in the unit.

Thanks!

Martin


signature.asc
Description: PGP signature

Bug#1015286: python-dbusmock: let ofono unit tests of lomiri-indicator-network succeed

[Martin Pitt]

Control: tag -1 upstream fixed-upstream pending
Control: forwarded -1 https://github.com/martinpitt/python-dbusmock/pull/138

Hello Mike,

Mike Gabriel [2022-07-18 20:59 +]:
> Ratchanan from the UBports dev team has very recently fixed all unit tests
> in (lomiri-)indicator-network against Qt5.15 (and Debian unstable in
> general). I plan to bring that package to Debian, but I'd love to see the
> following PR on python-dbusmock upstream cherry-picked in advance into
> Debian unstable's version of python-dbusmock:
>
> https://github.com/martinpitt/python-dbusmock/pull/138/files

Whoops, sorry for breaking this, and thanks for the fix! I want to do some
build system updates still, and will release 0.28.4 today or early tomorrow,
and then upload that to Debian unstable. From there it'll go into Ubuntu devel
within a day or so, but of course feel free to do a direct upload there if it's
urgent.

Thanks,

Martin


signature.asc
Description: PGP signature

Bug#1015068: python-dbusmock: FTBFS: AssertionError: Regex didn't match: b'[0-9.]+ Notify "fooApp" 0 "warning_icon" "title" "my text" \\[\\] {"urgency": 1} 27\n' not found in b'1657951521.419 GetServe

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 https://github.com/martinpitt/python-dbusmock/pull/139

Ça va Lucas,

Lucas Nussbaum [2022-07-16 15:32 +0200]:
> > ==
> > FAIL: test_options (tests.test_notification_daemon.TestNotificationDaemon)
> > notify-send with some options
> > --
> > Traceback (most recent call last):
> >   File 
> > "/<>/.pybuild/cpython3_3.9/build/tests/test_notification_daemon.py",
> >  line 68, in test_options
> > self.assertRegex(log, b'[0-9.]+ Notify "fooApp" 0 "warning_icon" 
> > "title" "my text" \\[\\] {"urgency": 1} 27\n')
> > AssertionError: Regex didn't match: b'[0-9.]+ Notify "fooApp" 0 
> > "warning_icon" "title" "my text" \\[\\] {"urgency": 1} 27\n' not found in 
> > b'1657951503.818 GetServerInformation\n1657951503.819 
> > GetServerInformation\n1657951503.820 Notify "fooApp" 0 "warning_icon" 
> > "title" "my text" [] {"urgency": 1, "sender-pid": 168975} 27\n'

Thanks for the report! The tests need to be adjusted to the new libnotify 0.8.
I fixed this upstream, and will do a new release ASAP.

Bonne soirée,

Martin

Bug#1014259: sscg: ftbfs on riscv64: (create_csr_test TIMEOUT 30.10s killed by signal 15 SIGTERM)

[Martin Pitt]

Control: forwarded -1 https://github.com/sgallagher/sscg/pull/60
Control: tag -1 upstream pending

Hello Bo,

Bo YU [2022-07-03 10:33 +0800]:
> The sscg package has a ftbfs issue on riscv64 arch, the full buildd
> log is here:
>
> https://buildd.debian.org/status/fetch.php?pkg=sscg=riscv64=3.0.2-1%2Bb1=1652893331=0

Thanks for your report! I sent an upstream PR to increase the test timeout. As
a short-term workaround I gave back the package build, and it succeeded:

https://buildd.debian.org/status/fetch.php?pkg=sscg=riscv64=3.0.2-1%2Bb1=1657605907=0

Martin


signature.asc
Description: PGP signature

Bug#1011207: autopkgtest: supports Ubuntu click packages, but is this still relevant?

[Martin Pitt]

Hello Simon,

Simon McVittie [2022-05-18 11:13 +0100]:
> autopkgtest has a significant amount of code to deal with Ubuntu 'click'
> packages, mostly contributed by Martin Pitt (who I'm aware no longer
> works for Canonical, but I'm cc'ing him for context).
> 
> However, click seems to be dead

Confirmed, this was all dead 5 years ago already, so this can all go.

> Similarly, are setup-commands/ro-apt, setup-commands/ro-apt-update,
> ssh-setup/adb still relevant?

Probably not. ssh-setup/adb was quite nice back then in the days of Ubuntu
Mobile, but since then it just has bitrotted away. git history doesn't forget,
in case someone ever needs a new starting point for that 

Thanks,

Martin

Bug#1010958: sscg FTBFS with OpenSSL 3.0.3

[Martin Pitt]

Control: reassign -1 openssl 3.0.2-1
Control: affects -1 sscg 3.0.2-1
Control: tag -1 fixed-upstream

Kurt Roeckx [2022-05-15 23:05 +0200]:
> It looks like it's fixed here: https://github.com/openssl/openssl/pull/18247

Indeed, thank you! Updating bug status.

I see openssl 3.0.3-4 is supposed to fix that, I'll test and verify/close this
bug.

Martin

Bug#1010958: sscg FTBFS with OpenSSL 3.0

[Martin Pitt]

Control: tag -1 upstream confirmed
Control: retitle -1 sscg FTBFS with OpenSSL 3.0.3

Adrian Bunk [2022-05-14  9:48 +0300]:
> https://buildd.debian.org/status/logs.php?pkg=sscg=3.0.2-1%2Bb1
> 
> ...
>  1/10 generate_rsa_key_test FAIL  0.01s   killed by signal 11 
> SIGSEGV
> 04:32:21 MALLOC_PERTURB_=87 
> /<>/obj-x86_64-linux-gnu/generate_rsa_key_test

Trivially reproducible locally, see below. It still works with the previous
3.0.2-1 version, so this is a very recent regression.

I can't tell yet whether this is a bug in sscg or OpenSSL. Fedora still has
3.0.2, so Debian is just the first distro where we noticed.

I confirm this also still happens with current upstream main (02f0a22769a6).

| ❱❱❱ gdb ./generate_rsa_key_test
| Starting program: /var/home/martin/debian/sscg/b/generate_rsa_key_test
| [Thread debugging using libthread_db enabled]
| Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
| 
| Program received signal SIGSEGV, Segmentation fault.
| __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:141
| 141   ../sysdeps/x86_64/multiarch/strcmp-sse42.S: No such file or directory.
| (gdb) bt full
| #0  __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:141
| No locals.
| #1  0x77d471df in EVP_PKEY_Q_keygen (libctx=libctx@entry=0x0, 
propq=propq@entry=0x0, type=type@entry=0x60ef "RSA")
| at ../crypto/evp/evp_lib.c:1172
| args = {{gp_offset = 24, fp_offset = 32767, overflow_arg_area = 
0x7fffe6a0, reg_save_area = 0x7fffe650}}
| bits = 93824992239747
| name = 
| params = {{key = 0x0, data_type = 0, data = 0x0, data_size = 0, 
return_size = 0}, {key = 0x0, data_type = 0, data = 0x0,
| data_size = 0, return_size = 0}}
| ret = 0x0
| __func__ = "EVP_PKEY_Q_keygen"
| #2  0x537f in sscg_generate_rsa_key 
(mem_ctx=mem_ctx@entry=0x9300, bits=bits@entry=512,
| _key=_key@entry=0x7fffe6c8) at ../src/key.c:48
| ret = 
| pkey = 0x0
| tmp_ctx = 0x0
| #3  0x51b6 in main (argc=, argv=) 
at ../test/generate_rsa_key_test.c:46
| ret = 
| pkey = 0x
| j = 
| bits = {512, , , , 
}
| tmp_ctx = 0x9300
| (gdb)

Thanks,

Martin

Bug#1008209: freeipa-client: ipa-client-install --uninstall crashes in admintool.py ScriptError

[Martin Pitt]

Package: freeipa-client
Version: 4.9.8-1+b1

Installing the IPA client is broken due to some chrony FUBAR [1], but I worked
around that with a mock service:

| # cat /run/systemd/system/chrony.service
| [Service]
| Type=oneshot
| ExecStart=/bin/true
| # systemctl unmask chrony

After that, joining a domain works:

| # ipa-client-install --domain cockpit.lan --realm COCKPIT.LAN --principal 
admin -W
| This program will set up IPA client.
| Version 4.9.8
| 
| WARNING: conflicting time synchronization service 'ntp' will be disabled 
in favor of chronyd
| 
| Discovery was successful!
| Do you want to configure chrony with NTP server or pool address? [no]: 
| Client hostname: x0.cockpit.lan
| Realm: COCKPIT.LAN
| DNS Domain: cockpit.lan
| IPA Server: f0.cockpit.lan
| BaseDN: dc=cockpit,dc=lan
| 
| Continue to configure the system with these values? [no]: yes
| [...]
| The ipa-client-install command was successful

But leaving it crashes:

| # ipa-client-install --uninstall
| Unenrolling client from IPA server
| Removing Kerberos service principals from /etc/krb5.keytab
| Disabling client Kerberos and LDAP configurations
| Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to 
/etc/sssd/sssd.conf.deleted
| Restoring client configuration files
| Unconfiguring the NIS domain.
| nscd daemon is not installed, skip configuration
| nslcd daemon is not installed, skip configuration
| Some installation state for ntp has not been restored, see 
/var/lib/ipa/sysrestore/sysrestore.state
| Some installation state has not been restored.
| This may cause re-installation to fail.
| It should be safe to remove /var/lib/ipa-client/sysrestore.state but it may
|  mean your system hasn't been restored to its pre-installation state.
| Systemwide CA database updated.
| Client uninstall complete.
| The original nsswitch.conf configuration has been restored.
| You may need to restart services or reboot the machine.
| Do you want to reboot the machine? [no]: no
| The ipa-client-install command failed. See /var/log/ipaclient-uninstall.log 
for more information
|
| root@x0:~# echo $?
| 4

That log indeed has a rather non-descriptive stack trace:

| 022-03-24T11:22:02Z DEBUG   File 
"/usr/lib/python3/dist-packages/ipapython/admintool.py", line 180, in execute
| return_value = self.run()
|   File "/usr/lib/python3/dist-packages/ipapython/install/cli.py", line 342, 
in run
| return cfgr.run()
|   File "/usr/lib/python3/dist-packages/ipapython/install/core.py", line 360, 
in run
| return self.execute()
| [...]
|   File "/usr/lib/python3/dist-packages/ipaclient/install/client.py", line 
3659, in uninstall
| raise ScriptError(rval=rv)

But this doesn't seem to be related to chronyd or my hack.

(Fun fact: The uninstall log is *exactly* 6 bytes. )

I attach the full install and uninstall logs for reference.

Thanks,

Martin

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008195


ipaclient-install.log.xz
Description: application/xz
2022-03-24T11:21:56Z DEBUG Logging to /var/log/ipaclient-uninstall.log
2022-03-24T11:21:56Z DEBUG ipa-client-install was invoked with arguments [] and 
options: {'unattended': False, 'principal': None, 'prompt_password': False, 
'on_master': False, 'ca_cert_files': None, 'force': False, 'configure_firefox': 
False, 'firefox_dir': None, 'keytab': None, 'mkhomedir': False, 'force_join': 
False, 'ntp_servers': None, 'ntp_pool': None, 'no_ntp': False, 'force_ntpd': 
False, 'nisdomain': None, 'no_nisdomain': False, 'ssh_trust_dns': False, 
'no_ssh': False, 'no_sshd': False, 'no_sudo': False, 'no_dns_sshfp': False, 
'kinit_attempts': None, 'request_cert': False, 'ip_addresses': None, 
'all_ip_addresses': False, 'fixed_primary': False, 'permit': False, 
'enable_dns_updates': False, 'no_krb5_offline_passwords': False, 
'preserve_sssd': False, 'automount_location': None, 'domain_name': None, 
'servers': None, 'realm_name': None, 'host_name': None, 'verbose': False, 
'quiet': False, 'log_file': None, 'uninstall': True}
2022-03-24T11:21:56Z DEBUG IPA version 4.9.8
2022-03-24T11:21:56Z DEBUG IPA platform debian
2022-03-24T11:21:56Z DEBUG IPA os-release Debian GNU/Linux 
2022-03-24T11:21:56Z DEBUG Loading Index file from 
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2022-03-24T11:21:56Z DEBUG Loading StateFile from 
'/var/lib/ipa-client/sysrestore/sysrestore.state'
2022-03-24T11:21:56Z DEBUG Loading StateFile from 
'/var/lib/ipa-client/sysrestore/sysrestore.state'
2022-03-24T11:21:56Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2022-03-24T11:21:56Z DEBUG Loading Index file from 
'/var/lib/ipa/sysrestore/sysrestore.index'
2022-03-24T11:21:56Z DEBUG httpd is not configured
2022-03-24T11:21:56Z DEBUG kadmin is not configured
2022-03-24T11:21:56Z DEBUG dirsrv is not configured
2022-03-24T11:21:56Z DEBUG pki-tomcatd is not configured
2022-03-24T11:21:56Z DEBUG install is not configured
2022-03-24T11:21:56Z DEBUG krb5kdc is not configured
2022-03-24T11:21:56Z 

Bug#1008195: Joining a domain fails on chrony.service in all scenarios

[Martin Pitt]

Package: freeipa-client
Version: 4.9.8-1+b1

Despite several attempts to fix it [1][2], interaction with chrony is still
broken on current Debian testing.

freeipa-client Recommends: chrony, so it is installed by default. Trying to
join a domain on a clean system:

| # ipa-client-install --domain cockpit.lan --realm COCKPIT.LAN --principal 
admin -W
| This program will set up IPA client.
| Version 4.9.8
| 
| WARNING: conflicting time synchronization service 'ntp' will be disabled 
in favor of chronyd
| 
| Discovery was successful!
| Do you want to configure chrony with NTP server or pool address? [no]: yes
| Enter NTP source server addresses separated by comma, or press Enter to skip:
| Enter a NTP source pool address, or press Enter to skip:
| Client hostname: x0.cockpit.lan
| Realm: COCKPIT.LAN
| DNS Domain: cockpit.lan
| IPA Server: f0.cockpit.lan
| BaseDN: dc=cockpit,dc=lan
| 
| Continue to configure the system with these values? [no]: yes
| Synchronizing time
| No SRV records of NTP servers found and no NTP server or pool address was 
provided.
| Using default chrony configuration.
| CalledProcessError(Command ['/bin/systemctl', 'restart', 'chrony.service'] 
returned non-zero exit status 1: 'Failed to restart chrony.service: Unit 
chrony.service is masked.\n')
| The ipa-client-install command failed. See /var/log/ipaclient-install.log for 
more information

ipaclient-install.log doesn't really say anything different, it just has a
large traceback for essentially the same thing.

Now, the chrony package is indeed rather weird/broken:

| root@x0:~# find /etc/systemd -name '*chrony*' | xargs ls -l
| lrwxrwxrwx 1 root root  9 Mar 24 05:54 /etc/systemd/system/chrony.service -> 
/dev/null
| lrwxrwxrwx 1 root root 34 Mar 23 04:31 /etc/systemd/system/chronyd.service -> 
/lib/systemd/system/chrony.service
| lrwxrwxrwx 1 root root 34 Mar 23 04:31 
/etc/systemd/system/multi-user.target.wants/chrony.service -> 
/lib/systemd/system/chrony.service

| # systemctl status chrony chronyd
| Warning: The unit file, source configuration file or drop-ins of 
chronyd.service changed on disk. Run 'systemctl daemon-reload' to relo>
| ○ chrony.service
|  Loaded: masked (Reason: Unit chrony.service is masked.)
|  Active: inactive (dead)
| 
| ○ chronyd.service
|  Loaded: error (Reason: Unit chronyd.service failed to load properly, 
please adjust/correct and reload service manager: File exists)
|  Active: inactive (dead)

Again, this is unconfigured and out of the box -- the idea is that FreeIPA
sets up everything and configures NTP/chrony/etc. to listen to the FreeIPA
server.

Purging chrony doesn't really help, though:

| dpkg -P chrony
| # no '*chrony*' files in /etc any more

Exactly the same failure, and it still tries to configure chrony even though
it's not there any more:

| WARNING: conflicting time synchronization service 'ntp' will be disabled 
in favor of chronyd
| 
| Discovery was successful!
| Do you want to configure chrony with NTP server or pool address? [no]: yes
| Enter NTP source server addresses separated by comma, or press Enter to skip:
| Enter a NTP source pool address, or press Enter to skip:
| Client hostname: x0.cockpit.lan
| Realm: COCKPIT.LAN
| DNS Domain: cockpit.lan
| IPA Server: f0.cockpit.lan
| BaseDN: dc=cockpit,dc=lan
| 
| Continue to configure the system with these values? [no]: yes
| Synchronizing time
| No SRV records of NTP servers found and no NTP server or pool address was 
provided.
| Using default chrony configuration.
| CalledProcessError(Command ['/bin/systemctl', 'restart', 'chrony.service'] 
returned non-zero exit status 5: 'Failed to restart chrony.service: Unit 
chrony.service not found.\n')
| The ipa-client-install command failed. See /var/log/ipaclient-install.log for 
more information

And even if I say "no" to the NTP question:

| # ipa-client-install --domain cockpit.lan --realm COCKPIT.LAN --principal 
admin -W
| This program will set up IPA client.
| Version 4.9.8
| 
| WARNING: conflicting time synchronization service 'ntp' will be disabled 
in favor of chronyd
| 
| Discovery was successful!
| Do you want to configure chrony with NTP server or pool address? [no]:
| Client hostname: x0.cockpit.lan
| Realm: COCKPIT.LAN
| DNS Domain: cockpit.lan
| IPA Server: f0.cockpit.lan
| BaseDN: dc=cockpit,dc=lan
| 
| Continue to configure the system with these values? [no]: yes
| Synchronizing time
| No SRV records of NTP servers found and no NTP server or pool address was 
provided.
| Using default chrony configuration.
| CalledProcessError(Command ['/bin/systemctl', 'restart', 'chrony.service'] 
returned non-zero exit status 5: 'Failed to restart chrony.service: Unit 
chrony.service not found.\n')
| The ipa-client-install command failed. See /var/log/ipaclient-install.log for 
more information

There's probably two bugs -- chrony having a broken default config, and
ipa-client-install not being able to detect and handle it. But at this point
I'm not even sure what 

Bug#1008194: nslookup -type is too verbose

[Martin Pitt]

Package: bind9-dnsutils
Version: 1:9.18.0-2

Querying DNS for a particular record type should look roughly like this:

| # nslookup -type=SRV localhost
| Server:   172.27.0.3
| Address:  172.27.0.3#53
| 
| *** Can't find localhost: No answer

That's the case with 1:9.16.27-1~deb11u1 in Debian stable, or
1:9.16.15-1ubuntu1.2 in Ubuntu 21.10, or bind-utils-9.16.27-1.fc35.x86_64 in
Fedora 35.

However, in Debian testing is now a wall of debug logging, which makes the
result really hard to see:

| # nslookup -type=SRV localhost
| main parsing localhost
| addlookup()
| make_empty_lookup()
| make_empty_lookup() = 0x7f76e759e000->references = 1
| looking up localhost
| lock_lookup dighost.c:4184
| success
| start_lookup()
| setup_lookup(0x7f76e759e000)
| resetting lookup counter.
| cloning server list
| clone_server_list()
| make_server(10.111.112.100)
| idn_textname: localhost
| trying origin cockpit.lan
| trying idn origin cockpit.lan
| recursive query
| add_question()
| starting to render the message
| done rendering
| create query 0x7f76e75dd000 linked to lookup 0x7f76e759e000
| dighost.c:2083:lookup_attach(0x7f76e759e000) = 2
| dighost.c:2587:new_query(0x7f76e75dd000) = 1
| do_lookup()
| start_udp(0x7f76e75dd000)
| dighost.c:2936:query_attach(0x7f76e75dd000) = 2
| working on lookup 0x7f76e759e000, query 0x7f76e75dd000
| dighost.c:2981:query_attach(0x7f76e75dd000) = 3
| unlock_lookup dighost.c:4186
| dighost.c:2898:query_attach(0x7f76e75dd000) = 4
| recving with lookup=0x7f76e759e000, query=0x7f76e75dd000, handle=(nil)
| recvcount=1
| have local timeout of 5000
| dighost.c:2847:query_attach(0x7f76e75dd000) = 5
| sending a request
| sendcount=1
| dighost.c:1676:query_detach(0x7f76e75dd000) = 4
| dighost.c:2918:query_detach(0x7f76e75dd000) = 3
| send_done(0x7f76e6427000, success, 0x7f76e75dd000)
| sendcount=0
| lock_lookup dighost.c:2615
| success
| dighost.c:2629:lookup_attach(0x7f76e759e000) = 3
| dighost.c:2648:query_detach(0x7f76e75dd000) = 2
| dighost.c:2649:lookup_detach(0x7f76e759e000) = 2
| check_if_done()
| list empty
| unlock_lookup dighost.c:2652
| recv_done(0x7f76e6427000, success, 0x7f76e6ffa010, 0x7f76e75dd000)
| lock_lookup dighost.c:3577
| success
| recvcount=0
| dighost.c:3589:lookup_attach(0x7f76e759e000) = 3
| before parse starts
| after parse
| next_origin()
| following up localhost
| requeue_lookup()
| clone_lookup()
| make_empty_lookup()
| make_empty_lookup() = 0x7f76e642d000->references = 1
| clone_server_list()
| make_server(10.111.112.100)
| before insertion, init@0x7f76e759e000 -> 0x, 
new@0x7f76e642d000 -> 0x
| after insertion, init -> 0x7f76e759e000, new = 0x7f76e642d000, new -> (nil)
| dighost.c:1995:_cancel_lookup()
| dighost.c:2669:query_detach(0x7f76e75dd000) = 1
| check_if_done()
| list full
| pending lookup 0x7f76e642d000
| dighost.c:4079:query_detach(0x7f76e75dd000) = 0
| dighost.c:4079:destroy_query(0x7f76e75dd000) = 0
| dighost.c:1634:lookup_detach(0x7f76e759e000) = 2
| dighost.c:4081:_cancel_lookup()
| check_if_done()
| list full
| pending lookup 0x7f76e642d000
| dighost.c:4087:lookup_detach(0x7f76e759e000) = 1
| clear_current_lookup()
| dighost.c:1759:lookup_detach(0x7f76e759e000) = 0
| destroy_lookup
| freeing server 0x7f76e7595400 belonging to 0x7f76e759e000
| start_lookup()
| setup_lookup(0x7f76e642d000)
| idn_textname: localhost
| using root origin
| recursive query
| add_question()
| starting to render the message
| done rendering
| create query 0x7f76e75dd000 linked to lookup 0x7f76e642d000
| dighost.c:2083:lookup_attach(0x7f76e642d000) = 2
| dighost.c:2587:new_query(0x7f76e75dd000) = 1
| do_lookup()
| start_udp(0x7f76e75dd000)
| dighost.c:2936:query_attach(0x7f76e75dd000) = 2
| working on lookup 0x7f76e642d000, query 0x7f76e75dd000
| dighost.c:2981:query_attach(0x7f76e75dd000) = 3
| unlock_lookup dighost.c:4091
| dighost.c:2898:query_attach(0x7f76e75dd000) = 4
| recving with lookup=0x7f76e642d000, query=0x7f76e75dd000, handle=(nil)
| recvcount=1
| have local timeout of 5000
| dighost.c:2847:query_attach(0x7f76e75dd000) = 5
| sending a request
| sendcount=1
| dighost.c:1676:query_detach(0x7f76e75dd000) = 4
| dighost.c:2918:query_detach(0x7f76e75dd000) = 3
| send_done(0x7f76e6427300, success, 0x7f76e75dd000)
| sendcount=0
| lock_lookup dighost.c:2615
| success
| dighost.c:2629:lookup_attach(0x7f76e642d000) = 3
| dighost.c:2648:query_detach(0x7f76e75dd000) = 2
| dighost.c:2649:lookup_detach(0x7f76e642d000) = 2
| check_if_done()
| list empty
| unlock_lookup dighost.c:2652
| recv_done(0x7f76e6427300, success, 0x7f76e6ffa010, 0x7f76e75dd000)
| lock_lookup dighost.c:3577
| success
| recvcount=0
| dighost.c:3589:lookup_attach(0x7f76e642d000) = 3
| before parse starts
| after parse
| printmessage()
| Server:   10.111.112.100
| Address:  10.111.112.100#53
| 
| *** Can't find localhost: No answer
| still pending.
| dighost.c:4079:query_detach(0x7f76e75dd000) = 1
| dighost.c:4081:_cancel_lookup()
| 

Bug#1007916: virtinst: VM creation fails: Could not open '/var/lib/libvirt/qemu/nvram/VmNotInstalled_VARS.fd'

[Martin Pitt]

Control: reassign -1 libvirt 7.0.0-3
Control: forcemerge 1006324 -1

Hello Simon,

Simon Kobyda [2022-03-18 14:48 +0100]:
> ERRORinternal error: process exited while connecting to monitor:
> 2022-03-18T13:45:43.472848Z qemu-system-x86_64: -blockdev
> {"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/VmNotInstalled_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}:
> Could not open '/var/lib/libvirt/qemu/nvram/VmNotInstalled_VARS.fd':
> Permission denied

This was already reported in https://bugs.debian.org/1006324 , merging as
duplicate. This is already fixed upstream and in Debian experimental, the fix
just needs to propagate to unstable/testing now.

Thanks,

Martin

Bug#1006576: sscg: FTBFS with OpenSSL 3.0

[Martin Pitt]

Control: tag -1 upstream fixed-upstream
Control: forwarded -1 https://github.com/sgallagher/sscg/pull/51

Hello Sebastian,

Sebastian Andrzej Siewior [2022-02-27 23:36 +0100]:
> Your package is failing to build using OpenSSL 3.0 with the
> following error:

Thanks for the report! This got fixed upstream a while ago, but not in a new
release yet. I asked upstream about a new one, if not I'll just backport the
patch. But salsa is down ATM, so this will need to wait for a bit (hopefully
not too long).

Martin

Bug#1006324: Info received (Bug#1006324: In debian bookworm: virt-install fails to reinstall VM when automatic UEFI firmware is set)

[Martin Pitt]

Control: tag -1 upstream
Control: forwarded -1 https://gitlab.com/libvirt/libvirt/-/merge_requests/140

I forwarded the tested fix to an upstream PR.

Martin

Bug#1006324: Info received (Bug#1006324: In debian bookworm: virt-install fails to reinstall VM when automatic UEFI firmware is set)

[Martin Pitt]

Control: reassign -1 libvirt-daemon-system 8.0.0-1
Control: found -1 7.0.0-3

Sorry for the merry-go-round -- the AppArmor profiles are actually shipped by
libvirt-daemon-system (libvirt source package).

Bug#1006324: In debian bookworm: virt-install fails to reinstall VM when automatic UEFI firmware is set

[Martin Pitt]

Control: reassign -1 apparmor 3.0.4-2
Control: found -1 apparmor 2.13.6-10

Thanks for the report!

I cleaned up the reproducer a bit: Drop the line breaks, automate the
firmware='efi' bit, and create the missing novell.iso; it just needs to exist,
it does not have to have any actual content for this reproducer.

I also reassign it to AppArmor. I believe virt-install/libvirt is within its
rights here, and the AA profile needs to be fixed. This also affects Debian 11,
so adding the affects.

  virt-install --connect qemu:///system --quiet --os-variant fedora28 --memory 
128 --name test --wait -1 --disk size=0.125,format=qcow2 --graphics 
vnc,listen=127.0.0.1 --graphics spice,listen=127.0.0.1 --print-xml 1 | sed 
"s/ /tmp/test1.xml
  virsh define /tmp/test1.xml
  touch /var/lib/libvirt/novell.iso
  virt-install --connect qemu:///system --reinstall test --wait -1 
--noautoconsole --cdrom /var/lib/libvirt/novell.iso --autostart

This is now a copy reproducer that works on a clean debian testing cloud
image, with virt-install and apparmor installed.

Thanks,

Martin

Bug#1005325: pcp: pmlogger.service fails with "protocol-error"

[Martin Pitt]

Package: pcp
Version: 5.2.6-1
Severity: important
Tags: upstream fixed-upstream

Hello,

Debian stable's pcp version has a rather annoying bug: after a while,
pmlogger.service fails to start up:

systemd[1]: pmlogger.service: Failed with result 'protocol'.
systemd[1]: Failed to start Performance Metrics Archive Logger.
systemd[1]: pmlogger.service: Scheduled restart job, restart counter is at 
1.

Then it retries a few times and eventually fails. The root cause is that
something during the startup completely whacks up the log permissions:

# ls -ld /var/log/pcp/pmlogger
drwxrwxr-x 3 1000 wheel 4096 Sep 19 22:13 /var/log/pcp/pmlogger

The only way out of this is to run

chown -R pcp:pcp /var/log/pmlogger

I think this is the same problem as reported in
https://bugzilla.redhat.com/show_bug.cgi?id=2013937 , and there was a
corresponding upstream fix:

  https://github.com/performancecopilot/pcp/commit/b9ff7d65b5e11

The essence of that is to drop the -C option from pmlogger_check.service.

However, I tried to apply this to Debian 11 by appending

  PMLOGGER_CHECK_PARAMS="--skip-primary"

to /etc/default/pmlogger_timers. But unfortunately that still doesn't help, our
tests keep running into this bug:

  
https://logs.cockpit-project.org/logs/pull-16979-20220211-085507-4343f4f8-debian-stable/log.html#298

At this point I'm running out of ideas. This feels like quite a major bug, as
it's not at all obvious how to get out of the situation, and how to prevent it
from happening.

Note that this does not affect any other operating system that cockpit tests on
(Debian testing, Ubuntu 20.04 and 21.10, Fedora 34/35, CentOS/RHEL 8/9, Arch),
only Debian 11. So I'm fairly sure this is fixed in current upstream versions.

Thanks,

Martin

Bug#1005004: lots of missing entries in debian/copyright

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/16928

I sent an upstream PR to add the missing node_modules/ copyrights. If there is
anything else wrong, I'll need more information (see my previous reply).

Thanks!

Martin

Bug#1005004: lots of missing entries in debian/copyright

[Martin Pitt]

tag -1 moreinfo

Hallo Thorsten,

Thorsten Alteholz [2022-02-05  9:40 +]:
> please rework your debian/copyright. Especially everything from node_modules
> seems to be missing. Please also check other releases.

The webpack bits in dist/ are autogenerated, and we have spent quite some
effort to make sure that this is correct and up to date. Over the last year it
shrank significantly, as we were able to drop a lot of npm modules (such as
jquery, mustache, or PatternFly 3).

Indeed copyright for the three node_modules/ are missing (these are test
dependencies for the integration test); they are not shipped in debs, but in
the source package, so they should be mentioned. That part is clear.

However, your report sounds like you found other problems apart from
node_modules/ -- what are they? Do you have an example?

Thanks,

Martin

Bug#1003349: scour: autopkgtest needs update for new version of librsvg: DeprecationWarning: Rsvg.Handle.render_cairo is deprecated

[Martin Pitt]

Control: tag -1 pending

Hello Simon,

Simon McVittie [2022-01-08 19:02 +]:
> librsvg 2.52.x has deprecated Rsvg.Handle.render_cairo, which causes
> scour's autopkgtest to fail

Thanks for the excellent report! Fixed in

  
https://salsa.debian.org/debian/scour/-/commit/143effbd8c64aee00932727680cd5db42422a2c4

The new API is less convenient, but works fine.

Martin

Bug#1002598: libssh: reduce Build-Depends

[Martin Pitt]

Control: tag -1 pending

Hello Helmut,

Helmut Grohne [2021-12-25  9:31 +0100]:
> +  * Reduce Build-Depends for architecture bootstrap. (Closes: #-1)

Thank you, much appreciated! I pushed the changes [1], as two separate
commits. I'll still do some maintenance updates (lintian looks pretty sad), and
do an upload ASAP.

Happy holidays,

Pitti

[1] https://salsa.debian.org/debian/libssh/-/commits/debian

Bug#1001377: sssd-dbus: sssd_ifp messes up existing /var/log/sssd/p11_child.log permissions

[Martin Pitt]

Control: retitle -1 pam_sss messes up existing /var/log/sssd/p11_child.log 
permissions
Control: reassign -1 libpam-sss 2.6.1-1
Control: severity -1 important

Turns out this is both much simpler to reproduce and also much more severe --
one doesn't actually need all the certificate setup and
FindByValidCertificate() stuff -- that's just one of the "natural" ways (aside
from direct smart card login through PAM on the console) how
/var/log/sssd/p11_child.log would be created.

However, it is entirely sufficient to simply create an empty file, and then
doing any login with pam_sss being active (i.e. having sssd running with a
trivial config).

Updated and simplified reproducer attached. The gist is

  - touch /var/log/sssd/p11_child.log
  - log into the machine
  → /var/log/sssd/p11_child.log permissions broken

Thanks,

Martin


repr2.sh
Description: Bourne shell script

Bug#1001377: sssd-dbus: sssd_ifp messes up existing /var/log/sssd/p11_child.log permissions

[Martin Pitt]

Package: sssd-dbus
Version: 2.6.1-1

I am testing the new FindByValidCertificate() infopipe API from 2.6.1, to
provide safe certificate authentication for cockpit. During that I ran into a
curious bug, where triggering p11-kit validation in sssd messes up the
permissions of /var/log/sssd/p11_child.log if it exists.

I first set up an sssd.conf for a local certificate mapping rule. I don't think
the details matter, the point is just that asking sssd to validate and check a
certificate will trigger the p11-kit child process, which logs into
/var/log/sssd/p11_child.log. Then, once that exists, a subsequent login
(through ssh or VT) will scramble the log file's permissions:

   -rw--- 1 64 bin 1463 Dec  9 10:03 /var/log/sssd/p11_child.log

After that, any subsequent attempt to do any certificate validation fails:

sssd_ifp[4412]: Could not open file [/var/log/sssd/p11_child.log]. Error: 
[13][Permission denied]

I attach a reproducer shell script that works in a clean Debian testing
environment with sssd installed (I am using the current cloud image, but that
shouldn't matter so much).

❗ WARNING: repr.sh scribbles over /etc/sssd/sssd.conf and creates/removes an
"alice" user, so please don't run this on a production machine.

In the end it fails like this:

| + stat -c %u /var/log/sssd/p11_child.log
| FAIL:
| + [ 64 = 0 ]
| + echo FAIL:
| + ls -l /var/log/sssd/p11_child.log
| -rw--- 1 64 bin 1463 Dec  9 10:11 /var/log/sssd/p11_child.log
| + exit 1

and reproduces that broken situation. After that, calling
FindByValidCertificate() again triggers the "Permission denied" error.

I am filing this against Debian as I cannot reproduce this on current Fedora 35
with sssd-2.6.1-1.fc35.x86_64, i.e. exact same upstream version.

Thanks,

Martin


repr.sh
Description: Bourne shell script

Bug#991324: micro-httpd: systemd install dependency fails if binding to IP other than 0.0.0.0

[Martin Pitt]

Control: tag -1 pending
Control: tag 991324 pending
Control: tag 991884 pending

Hello Martin-Éric,

> +micro-httpd (20140814-2.1) unstable; urgency=medium

Thanks! Reading https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983232#15
scared me a bit (users shouldn't use edit --full normally, and daemon-reload is
not necessary then), but your debdiff has this correct. The main parts all look
sensible to me, thanks!

I just wondered about that unfuzzing of the patch -- that might disrupt the
patch workflow from git, and is not really necessary for the NMU. It's easy
enough to revert (i.e. simply not apply to git) of course. But for that reason
I uploaded it to DELAYED/2 for now, in case you change your mind or Sudip
objects.

Thanks!

Martin

Bug#996476: libvirt-daemon: Does not show host veth interfaces as host devices any more

[Martin Pitt]

Package: libvirt-daemon
Version: 7.6.0-1

Since the upgrade of Debian 11 to current testing, libvirt has a regression: It
does not recognize veth devices as "nodedevs" (devices available on the host
and known by libvirt) any more. This breaks assigning them to VMs for
networking or PXE booting.

  # ip link add name eth42 type veth peer name v_eth42
  # virsh nodedev-list --cap net
  net_eth0_52_54_00_12_34_56
  net_lo_00_00_00_00_00_00

→ No trace of eth42 and v_eth42.

This still works fine on Debian 11,  with libvirt 7.0.0-3, systemd 247.3-6, and
kernel 5.10.0-8-cloud-amd64:

  # ip link add name eth42 type veth peer name v_eth42
  # virsh nodedev-list --cap net
  net_eth0_52_54_00_12_34_56
  net_eth42_ba_f8_89_e3_96_41
  net_lo_00_00_00_00_00_00
  net_v_eth42_c2_28_c1_aa_03_0b

I file this against Debian, as none of our other cockpit-tested operating
systems show this regression (Ubuntu 20.04 LTS/21.10, Fedora 34/35, RHEL/CentOS
8/9, etc.). In particular current Fedora 35 has the exact same libvirt version
7.6.0, just a newer systemd (249.4 in Fedora, 247.9 in Debian testing).

I don't think it's related to udev: In both Debian 11 and testing the device
looks exactly alike in `udevadm info --export-db`:

  P: /devices/virtual/net/eth42
  L: 0
  E: DEVPATH=/devices/virtual/net/eth42
  E: SUBSYSTEM=net
  E: INTERFACE=eth42
  E: IFINDEX=6
  E: USEC_INITIALIZED=106226972
  E: ID_MM_CANDIDATE=1
  E: ID_NET_DRIVER=veth
  E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
  E: ID_NET_NAME=eth42
  E: NM_UNMANAGED=1
  E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth42
  E: TAGS=:systemd:
  E: CURRENT_TAGS=:systemd:

Thanks,

Martin

Bug#995693: cockpit-machines: Request to build for bullseye-backports

[Martin Pitt]

Control: tag -1 pending

Hello José,

José Miguel Gonçalves [2021-10-04 10:29 +0100]:
> I would like to try cockpit-machines v251 in bullseye but that is currently 
> not possible because, while cockpit v251 package is released in 
> bullseye-backports, cockpit-machines is not.
> Please build cockpit-machines v251 for bullseye-backports. 

Thanks for the reminder! I wanted to do that anyway. I uploaded
cockpit-machines_251-1~bpo10+1.dsc, it'll be in the backports NEW queue for a
while.

Martin

Bug#995672: cockpit-machines: 253-1 fails to build via apt-src

[Martin Pitt]

Control: severity -1 normal
Control: tag -1 unreproducible moreinfo

Hello Friedemann,

Friedemann Schorer [2021-10-03 23:40 +0200]:
> Severity: serious

That feels inflated to me. The package builds fine in official buildds [1], in
upstream CI (which uses pbuilder) and locally in a debian-sid container, and it
is really quite harmless -- the build is more or less "install a bunch of
files". Also, the error message below doesn't even get to the point where it
even attempts to build c-machines, it seems to fail early in apt-src's
name-to-location mapping? So that's certainly not a regression compared to the
testing version.

[1] https://buildd.debian.org/status/package.php?p=cockpit-machines

> Got the latest source packages for cockpit-machines 253-1, unpacked them
> locally via 'dpkg-source -x', made the source known to apt-src ('apt-src
> import cockpit-machines --location cockpit-machines-253') and tried to
> build it.
> Here's the output:
> 
>  ~/build: apt-src list
>  
> i   cockpit-machin 253-1  /home/frschorer/build/cockpit-machines-253  
>  
>  ~/build: apt-src build cockpit-machines  
> 
> E: Not installed
> 
> When I import the sourcetree of cockpit 254-1 from unstable sources,
> too,  and then try to build cockpit-machines apt-src builds the other cockpit 
> packages instead.

I never used apt-src, so I'm trying to reproduce this:

  sudo apt install -y apt-src
  cd /tmp 
  apt-get source cockpit-machines
  apt-src import cockpit-machines --location cockpit-machines-253/
  apt-src build cockpit-machines
  
the latter works:

> dpkg-buildpackage: info: source package cockpit-machines
> dpkg-buildpackage: info: source version 253-1
> [...]
> dpkg-deb: building package 'cockpit-machines' in 
> '../cockpit-machines_253-1_all.deb'.
> dpkg-buildpackage: info: binary-only upload (no source included)
> I: Successfully built in /tmp/cockpit-machines-253

Do these exact commands work for you? What did you do differently? How does your
~/.apt-src/status file look like? If you move it away, or try this as a
different user, what result do you get?

Thanks,

Martin

Bug#995248: umockdev 0.16.3-1 breaks autopkgtest of bolt

[Martin Pitt]

Control: reassign -1 bolt  0.9.1-1
Control: affects -1 umockdev
Control: tag -1 upstream pending
Control: forwarded -1 
https://gitlab.freedesktop.org/bolt/bolt/-/merge_requests/246

Hello Christian,

as I mentioned on the LP bug already, I noticed that bolt regression and sent
an upstream fix for bolt.

Thanks,

Martin

Bug#993046: libssh: CVE-2021-3634 - bullseye update prepared

[Martin Pitt]

Hello Salvatore and Laurent,

Salvatore Bonaccorso [2021-08-26 22:21 +0200]:
> The following vulnerability was published for libssh.
> 
> CVE-2021-3634[0]:
> | Possible heap-buffer overflow when rekeying
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

I backported the security fix, the AEAD handshake failure fix, and two
(trivial) memory leak fixes, in the first three commits here:

  https://salsa.debian.org/debian/libssh/-/commits/bullseye-security

The fourth is just administrative (tell git-buildpackage about the new
bullseye-security branch) and not user-visible.

The (mostly autogenerated) changelook would look like this:

libssh (0.9.5-1+deb11u1) bullseye-security; urgency=high

  * dh-gex: Avoid memory leaks.
Add 0001-dh-gex-Avoid-memory-leaks.patch: Backported from upstream 0.9.6
release.
  * Fix handshake bug with AEAD ciphers and no HMAC overlap.
Add 0002-Fix-handshake-bug-with-AEAD-ciphers-and-no-HMAC-over.patch and 
0003-Add-initial-server-algorithm-test-for-no-HMAC-overla.patch:
Backport fix and test from upstream 0.9.6 release.
  * Create a separate length for session_id.
Add 0004-CVE-2021-3634-Create-a-separate-length-for-session_i.patch and 
0005-tests-Simple-reproducer-for-rekeying-with-different-.patch:
Backport fix and test from upstream 0.9.6 release.
CVE-2021-3634 (Closes: #993046)

 -- Martin Pitt   Sat, 28 Aug 2021 13:52:11 +0200

Is that ok with you, in particular the not-quite-CVE patches? Should I upload
directly or put the dsc somewhere?

Laurent, ok with you or do you have something else?

Thanks,

Martin

Bug#993046: libssh: CVE-2021-3634

[Martin Pitt]

Control: tag -1 pending
Control: notfound -1 0.7.3-2+deb9u2
Control: notfound -1 0.8.1-1~bpo9+1
Control: notfound -1 0.8.7-1+deb10u1

Salvatore Bonaccorso [2021-08-26 22:21 +0200]:
> CVE-2021-3634[0]:
> | Possible heap-buffer overflow when rekeying

Thanks for the report! For unstable/testing I am currently preparing the new
upstream 0.9.6 release. According to the upstream advisory [1] this only
affects version ≥ 0.9.1, thus I mark oldstable (buster) and oldoldstable
(stretch) as not affected.

For stable-security I'll prepare some backports, of that CVE and the AEAD
handshake (and possibly some other important) bugs.

Pitti

[1] https://www.libssh.org/security/advisories/CVE-2021-3634.txt

Bug#989137: cockpit-ws: No sysvinit script

[Martin Pitt]

Hello Simon,

Simon Walter [2021-05-27 10:17 +0900]:
> I was trying to make it quicker to deploy for those who run it like this
> anyway, but I understand not wanting to be responsible for partially
> functioning software. In that case, shall I open a bug to make systemd a
> dependency?

This is already the case, in Debian testing (and thus upcoming Debian 11),
cockpit-ws has a Depends: systemd (>= 235).

Thanks!

Martin

Bug#988897: cockpit-ws: broken symlinks: /usr/share/cockpit/branding/opensuse/*

[Martin Pitt]

Control: tag -1 pending

Hello Andreas,

Andreas Beckmann [2021-05-20 21:52 +0200]:
> 5m1.4s ERROR: FAIL: Broken symlinks:
>   /usr/share/cockpit/branding/opensuse/default-1920x1200.jpg -> 
> ../../../wallpapers/default-1920x1200.jpg (cockpit-ws)
>   /usr/share/cockpit/branding/opensuse/favicon.ico -> 
> ../../../pixmaps/distribution-logos/favicon.ico (cockpit-ws)
>   /usr/share/cockpit/branding/opensuse/square-hicolor.svg -> 
> ../../../pixmaps/distribution-logos/square-hicolor.svg (cockpit-ws)

thanks for the report! I sent a fix to
https://github.com/cockpit-project/cockpit/pull/15851

Martin

Bug#986012: fatrace: autopkgtest regression: ^rm(.*): D /tmp/autopkgtest-lxc.yky1gevw/downtmp/build.jzI/src$ not found in log

[Martin Pitt]

Control: tag -1 pending

Paul Gevers [2021-03-27 21:43 +0100]:
> https://ci.debian.net/data/autopkgtest/testing/amd64/f/fatrace/11288159/log.gz
> 
> autopkgtest [23:08:44]: test fatrace-currentmount: [---
> ^rm(.*): D /tmp/autopkgtest-lxc.yky1gevw/downtmp/build.jzI/src$ not
> found in log

I finally found some time to reproduce this with [1]. I tested fatrace
manually, and I don't find any way any more to get open_by_handle_at() or
fanotify to work in an LXC container with the default security profile any
more. As I don't have any influence over the container setting in production
debci, I'm afraid my only way out is to apply "isolation-machine" to
fatrace-currentmount as well.

At least all the tests are runnning both in upstream and Ubuntu CI.

Thanks,

Martin

[1] https://ci.debian.net/doc/file.MAINTAINERS.html

Bug#986830: ITP: sscg -- simple SSL certificate generator

[Martin Pitt]

Control: tag -1 pending

Martin Pitt [2021-04-12 16:23 +0200]:
> * Package name: sscg

I packaged this at https://salsa.debian.org/debian/sscg and uploaded to
experimental. It's in the NEW queue now:
https://ftp-master.debian.org/new/sscg_2.6.2-1.html

Martin

Bug#986830: ITP: sscg -- simple SSL certificate generator

[Martin Pitt]

Package: wnpp
Severity: wishlist
Owner: Martin Pitt 

* Package name: sscg
  Version : 2.6.2
  Upstream Author : Stephen Gallagher 
* URL : https://github.com/sgallagher/sscg/
* License : GPL-3+ with OpenSSL exception
  Description :
   sscg is a utility to aid in the creation of more secure "self-signed"
   certificates. The certificates created by this tool are generated in a
   way so as to create a CA certificate that can be safely imported into a
   client machine to trust the service certificate without needing to set
   up a full PKI environment and without exposing the machine to a risk of
   false signatures from the service certificate.

See this blog post for details:
https://sgallagh.wordpress.com/2016/05/02/self-signed-ssltls-certificates-why-they-are-terrible-and-a-better-alternative/

Cockpit's web server makes use of sscg if it is available, as a slightly better
alternative than direct self-signed certificates.

CC'ing upstream author Stephen for questions about the functionality.

I recently sent the Debian packaging to the upstream project, where it will run
in CI for each PR: https://github.com/sgallagher/sscg/pull/22

Thanks,

Martin


signature.asc
Description: PGP signature

Bug#985768: ITP: cockpit-machines -- Cockpit user interface for virtual machines (source splitout from cockpit)

[Martin Pitt]

Package: wnpp
Severity: wishlist
Owner: Martin Pitt 

* Package name: cockpit-machines
  Version : 241
  Upstream Author : Cockpit development team 

* URL : https://github.com/cockpit-project/cockpit-machines/
* License : LGPL-2.1+
  Description :
   The Cockpit Web Console enables users to administer GNU/Linux servers using a
   web browser.
   .
   This package adds an user interface for managing virtual machines.
   .
   If the "virtinst" package is installed, you can also create new virtual
   machines.

This has existed as a binary package [1] built from the cockpit source [2] for
quite some time already. For various reasons split out this component into a
separate project [3], and will remove it from cockpit.git soon. This is similar
to cockpit-podman [4].

The first upstream release 241 [5] is a clean code copy. This provides a clean
upgrade path from the last official cockpit release 240 which still built
-machines. As such I hope to get it into experimental relatively soon, so that
uploading new cockpit releases don't get blocked for too long.

Thanks,

Martin

[1] https://packages.debian.org/sid/cockpit-machines
[2] https://tracker.debian.org/pkg/cockpit
[3] https://github.com/cockpit-project/cockpit-machines/
[4] https://tracker.debian.org/pkg/cockpit-podman
[5] https://github.com/cockpit-project/cockpit-machines/releases/tag/241


signature.asc
Description: PGP signature

Bug#983514: cockpit-ws: cockpit tries to write in /etc

[Martin Pitt]

Control: tag -1 upstream fixed-upstream pending
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15438

Hello Nicolas,

Nicolas George [2021-02-25 12:27 +0100]:
> When trying for a read-only root filesystem, I am blocked by the fact
> that cockpit tries to write in /etc at startup:
> 
> Feb 03 17:12:09 kruppe systemd[1]: Starting Cockpit Web Service...
> Feb 03 17:12:09 kruppe remotectl[693]: remotectl: couldn't set certificate 
> permissions: /etc/cockpit/ws-certs.d/0-self-signed.cert: Read-only file system
> Feb 03 17:12:09 kruppe systemd[1]: cockpit.service: Control process exited, 
> code=exited, status=1/FAILURE

Thanks for your report! I sent an upstream PR to fix this.

Martin

Bug#983218: cockpit: please use correct Debian logo

[Martin Pitt]

Control: reassign -1 debconf
Control: forcemerge 983200 -1

Hello again,

Martin Pitt [2021-02-23 15:48 +0100]:
> Philip Hands [2021-02-21 10:28 +0100]:
> > Rather than waiting for debconf to be updated to provide you with a new 
> > image to
> > play with, I'd suggest going to the source, and using the SVG here:
> > 
> >   https://www.debian.org/logos/openlogo-nd.svg
> 
> Thanks, very well spotted! That's what I did, and I rendered it (in GIMP) as
> 48x48. I submitted it here: 
> https://github.com/cockpit-project/cockpit/pull/15408

Sorry, this was a thinko. Our *source code* contains a
src/branding/debian/favicon.ico, but it's not actually being used. The deb just
installs it as a symlink to the generic distro-wide icon from debconf:

   lrwxrwxrwx 1 root root 32 Feb  4 14:48 
/usr/share/cockpit/branding/debian/favicon.ico -> 
../../../pixmaps/debian-logo.png

So I'm marking this a duplicate of the debconf bug, and will submit an upstream
PR to just remove the obsolete logo file from the source.

Thanks!

Martin

Bug#983218: cockpit: please use correct Debian logo

[Martin Pitt]

Hello Philip,

Philip Hands [2021-02-21 10:28 +0100]:
> Rather than waiting for debconf to be updated to provide you with a new image 
> to
> play with, I'd suggest going to the source, and using the SVG here:
> 
>   https://www.debian.org/logos/openlogo-nd.svg

Thanks, very well spotted! That's what I did, and I rendered it (in GIMP) as
48x48. I submitted it here: 
https://github.com/cockpit-project/cockpit/pull/15408

It is now 9 kB, instead of the previous 1, but it looked rather crappy when I
lowered the BPP and/or alpha depth. If you know how to make a better/smaller
one, I'd appreciate of course!

Thanks,

Martin

Bug#983102: casync FTCBFS: python3-sphinx dependency not installable

[Martin Pitt]

Control: tag -1 pending

Hello Helmut,

Helmut Grohne [2021-02-19  7:29 +0100]:
> As such I propose simply annotating the dependency :native and doing so is
> sufficient to make casync cross buildable. Please consider applying the
> attached patch.

Thanks for fixing that! I applied your patch to git. I'll do some other
house-keeping now, and do an upload today.

Martin

Bug#982613: NetworkManager triggers assert in python-dbusmock test suite

[Martin Pitt]

Control: reassign -1 network-manager 1.29.90-1
Control: tag -1 upstream fixed-upstream
Control: forwarded -1 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/662

This eventually *did* turn out to be a bug in NetworkManager itself, and only
became visible now because of the beta version number.

I validated that the fix

  
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/e1e9abdf041b4cc

backports cleanly on top of 1.29.90 and fixes the assertion and the
python-dbusmock tests. Thus moving this bug back to NM.

I don't think this beta version should move into testing, as it's prone to
cause assertion crashes in real-life situations as well. But of course Michael
has the last word on this.

Thanks Thomas and Michael for your help here!

Martin

Bug#982613: NetworkManager triggers assert in python-dbusmock test suite

[Martin Pitt]

Martin Pitt [2021-02-14 11:41 +0100]:
> So this is some weird NM build system issue that breaks something for any tag
> (i.e. minor/micro version in configure.ac) >= 1.28.0. Note that the 1.28-rc* 
> tags
> have version 1.27.x.

I checked out tag 1.30-rc1 (aka version 1.29.0), and changed
configure.ac+meson.build from 1.29.90 → 1.30.0, and voilà, it works. So it's
not something specific to 28, but specific to doing a final release.

Setting the version to 1.30.90 also works, and it's enough to change
configure.ac, leaving meson.build alone. (Debian's package still uses automake,
not meson). And here we have the explanation at last: configure.ac sets
`more_asserts_default` for odd (development) minor versions, i.e. non-release
versions are built with --with-more-asserts=100.

So now I need to figure out what the (dbobj->obj_state >=
NML_DBUS_OBJ_STATE_ON_DBUS) assertion is really about, and mock this harder. So
reassigning to dbusmock was justified, this is not a regression in NM, and thus
the autopkgtest regression should be ignored/overridden.

Martin

[1] 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/master/configure.ac#L1066

Bug#982613: NetworkManager triggers assert in python-dbusmock test suite

[Martin Pitt]

Hello all,

CC'ing Thomas, maybe he has some idea about this. Thomas, please see [0] for
the python-dbusmock failure that triggered this bug report.

Adrian Bunk [2021-02-12 16:22 +0200]:
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz
> test_one_wifi_with_accesspoints (__main__.TestNetworkManager) ... **
> libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: assertion 
> failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS)
> Bail out! libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: 
> assertion failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS)
> ERROR

I enabled tests on Debian unstable upstream now [1] to reproduce the failure 
[2].

I first ran a bisect between tags 1.28.0 (which works) and 1.30-rc1 (which is
release 1.29.90, and fails). Curiously that came out as "release: bump version
to 1.29.0 (development) is the first bad commit".

It turns out that the 1.29.0-dev branch got based off 1.28-rc1, not 1.28.0, and
`git shortlog 1.28-rc1..1.28.0` has a good deal of changes. I confirmed that
1.28-rc1 itself also has that failure (otherwise I'd really be 勞), and so does
1.28-rc2.

Then I ran a bisect between 1.28-rc2 and 1.28.0, and again it resulted in the
first bad version being "release: bump version to 1.28.0" [3] (which is again
trivial). I used a test script [4] which builds everything from a clean git
tree, and I uninstalled network-manager from the container that I'm running
this in, so there are no stale files between builds.

The NM dbusmock [5] does not have any version check or other version sensitive
code.

So this is some weird NM build system issue that breaks something for any tag
(i.e. minor/micro version in configure.ac) >= 1.28.0. Note that the 1.28-rc* 
tags
have version 1.27.x.

I grepped the NM source for '1_28' and '\b1\b.*\b28\b', but that did not spot
anything obvious. I also checked for '\b1\b.*\b27\b' (just in case there is
some condition on <= 1.27), but that does not hit anything relevant.

So at the moment I'm totally stumped about this. Thomas, are you aware of any
version sensitive magic in NM's build?

Thanks!

Martin

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982613#5
[1] https://github.com/martinpitt/python-dbusmock/commit/8350ab65eb
[2] https://github.com/martinpitt/python-dbusmock/actions/runs/565487941
[3] 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/6f32c5c10736

[4]
#!/bin/sh
set -eux
cd /tmp/NetworkManager
git clean -ffdx
./autogen.sh --with-crypto=gnutls --with-iptables=/usr/sbin/iptables
make -j4 clients/cli/nmcli

cd /source
PATH=/tmp/NetworkManager/clients/cli:$PATH PYTHONPATH=. python3 
tests/test_networkmanager.py TestNetworkManager.test_one_wifi_with_accesspoints

[5] 
https://github.com/martinpitt/python-dbusmock/blob/master/dbusmock/templates/networkmanager.py

Bug#982613: Debian Python Team

[Martin Pitt]

Control: reassign -1 0.22.0-1
Control: affects -1 network-manager

Adrian Bunk [2021-02-12 16:22 +0200]:
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz
> test_one_wifi_with_accesspoints (__main__.TestNetworkManager) ... **
> libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: assertion 
> failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS)
> Bail out! libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: 
> assertion failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS)
> ERROR

This is almost surely not a bug in NM itself, but that the current dbusmock
does not properly emulate the new NM 1.29.90. Reassigning, I'll take a look.

Martin

Bug#981813: Acknowledgement (API regression: Could not get either XDG_CONFIG_HOME or HOME)

[Martin Pitt]

Control: notfound -1 2.1.1+dfsg1-4
Control: found -1 2.1.1+dfsg1-5
Control: found -1 2.2.1+dfsg1-1
Control: notfound 3.0.0~rc2+dfsg1-2
Control: tag -1 pending

Capturing the affected versions as per the initial report.

Bug#981813: API regression: Could not get either XDG_CONFIG_HOME or HOME

[Martin Pitt]

Package: podman
Version: 2.1.1+dfsg1-5

A few days ago, our cockpit-podman tests started to fail on Debian testing [1]
(screenshot [2]) for committing images. This coincides with the testing update
of 2.1.1+dfsg1-4 (last known good version) to 2.1.1+dfsg1-6.

CLI reproducer (as root):

# start from a clean slate, especially after package down/upgrades
podman rm -f --all; podman rmi testimg; systemctl stop io.podman.service 
podman.service
# create container
podman run --name test -d quay.io/libpod/busybox sleep infinity
# commit it through the API
curl -XPOST --unix-socket /run/podman/podman.sock -v 
'http://d/v1.0.0/libpod/commit?container=test=testimg'

This started to fail like this:

< HTTP/1.1 500 Internal Server Error
< Api-Version: 1.40
< Content-Type: application/json
< Libpod-Api-Version: 2.0.0
< Server: Libpod/2.0.0 (linux)
< Date: Thu, 04 Feb 2021 06:48:56 GMT
< Content-Length: 185
<
{"cause":"could not get either XDG_CONFIG_HOME or 
HOME","message":"CommitFailure: error resolving name \"testimg:latest\": could 
not get either XDG_CONFIG_HOME or HOME","response":500}

The `podman commit` CLI API works fine, this just affects the REST API.

After a successful operation, there should be a committed image:

# podman images
REPOSITORYTAG IMAGE ID  CREATEDSIZE
localhost/testimg latest  b30349f6d1ea  3 seconds ago  1.46 MB


I tested various podman package versions from snapshot.d.o. (no other binary
package changes):

2.1.1+dfsg1-4: works
2.1.1+dfsg1-5: fails
2.1.1+dfsg1-6: fails
2.1.1+dfsg1-7: fails
2.2.1+dfsg1-1: fails
3.0.0~rc2+dfsg1-2: works

(I'm going to mark the affected/unaffected versions in a follow-up email once
BTS imports this new bug)

The changes between -4 and -5 seem rather unrelated:
https://salsa.debian.org/debian/libpod/-/commit/e6685dfe282cf9049db2980d91bc85e57e1bb8d7
So I can only imagine this is due to some changed go dependencies?

Fedora 33 has podman 2.2.1, and that works fine. This corroborates that this is
not in the podman code itself, but some dependency.

Since this works again in current Debian unstable, I'm mostly filing this to
(1) track the fix in testing, and (2) satisfy our automatic upstream regression
tracker.

Thanks,

Martin


[1] https://github.com/cockpit-project/cockpit-podman/pull/663
[2] 
https://logs.cockpit-project.org/logs/pull-663-20210201-073807-b9dbbbd7-debian-testing/TestApplication-testBasicSystem-debian-testing-127.0.0.2-2301-FAIL.png

Bug#981127: cockpit: FTBFS on hppa - test timeout is way too small

[Martin Pitt]

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15223
Control: tag -1 upstream pending

Hello John,

Ugh, is HPPA know to have such a poor threading performance in general?
Thanks for doing the manual build!

> We either need to skip the test-tls-certfile on hppa or greatly extend the
> timeout.

Let's do the former then. That test isn't that important, it mostly checks that
our threading logic does not have race conditions. But that should not be very
architecture specific.

I sent an upstream PR to do that, it'll be in 237.

Thanks!

Martin

Bug#943500: my NMU made it FTBFS

[Martin Pitt]

Hello Helmut,

Helmut Grohne [2020-12-30  8:44 +0100]:
> unfortunately, my NMU made cracklib2 FTBFS on various architectures. It
> turns out that the py_builddir_sh also needs the _PYTHON_* variables or
> it will disagree with them. I've immediately uploaded another to fix it.
> It further simplifies my previous version and simply exports then on the
> top level. That was not possible on the initial posting as their value
> differed for python 3.8, which is no longer covered.
> 
> Sorry for the FTBFS. NMU diff attached.

No worries, thanks a lot for this fix! (And yay that it's simpler now!)

Greetings,

Martin

Bug#978135: cockpit: should recommend sudo

[Martin Pitt]

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15074

Hello Cesare,

Cesare Leonardi [2020-12-26 16:16 +0100]:
> For this reason I believe that cockpit package should at least
> recommend "sudo".

Thanks for your report! I sent a PR upstream to adjust the dependencies
accordingly.

Martin

Bug#978310: umockdev: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1

[Martin Pitt]

Control: tag -1 fixed-upstream pending
Control: forwarded -1 https://github.com/martinpitt/umockdev/issues/115

Hello Lucas,

Lucas Nussbaum [2020-12-26 22:57 +0100]:
> > Bail out! ERROR:../tests/test-umockdev.c:1135:t_testbed_usb_lsusb: 
> > assertion failed (exit_status == 0): (256 == 0)

I noticed that a few days as well, and someone else also noticed in 
https://github.com/martinpitt/umockdev/issues/115

The fix is already upstream, I'll do a new release ASAP.

Thanks for your report and your continous rebuild efforts! These are much
appreciated.

Martin

Bug#928436: cracklib2 NMU with delay 10

[Martin Pitt]

Hello Helmut,

Helmut Grohne [2020-12-26 17:39 +0100]:
> given the prolonged silence on these bugs, I've uploaded a NMU with
> delay 10 fixing both and adding a Multi-Arch stanza. All of the changes
> seem quite safe to me. I've performed local test builds for various
> configurations (nocheck, nopython, cross, ...). A .debdiff of the
> proposed changes is attached. Please let me know if I should delay this
> any longer.

Thanks for the fixes! These look good to me, no objections from my side to not
just upload this with a smaller or no delay. Jan has the last word on this,
though.

Happy holidays,

Martin

Bug#900381: Fails to boot cirros QEMU image with tuned running

[Martin Pitt]

Hello Evgeni,

as this bug report is quite old, I first re-checked this with the versions in
testing from a few days ago:

qemu-system-x86  1:5.1+dfsg-4+b2
tuned2.10.0-1
linux-image-5.9.0-4-cloud-amd64  5.9.11-1

Without tuned, cirros boots, and gets stuck after a while trying to find a
cloud-init source:

  checking http://169.254.169.254/2009-04-04/instance-id
  failed 1/20: up 9.66. request failed
  [...

But that's fine. With tuned, the symptoms are a bit different now: QEMU does
not show "warning: host doesn't support requested feature: CPUID" any more; but
we already established that this was just a red herring.

I see the "GRUB loading, please wait..." for several seconds, then the screen
gets cleared, and nothing happens any more.  QEMU is spinning at 100% CPU. So
aside from the warning, it's still the same.

I then dist-upgraded this VM to current sid:

qemu-system-x86  1:5.2+dfsg-2
tuned2.14.0-1
linux-image-5.9.0-5-cloud-amd64  5.9.15-1

The behaviour is still the same.

This is in our cockpit test VMs, which are based on the official testing cloud
images, but they install some additional packages.

I re-tested this straight from the current official cloud images:

  curl -o sid.qcow2 
https://cloud.debian.org/images/cloud/sid/daily/20201220-490/debian-sid-nocloud-amd64-daily-20201220-490.qcow2
  qemu-system-x86_64 -cpu host -nographic -m 2048 -device virtio-rng-pci -drive 
file=sid.qcow2,if=virtio -snapshot

The `-cpu host` option is necessary to provide /dev/kvm inside the VM (the
default "QEMU Virtual CPU" does not).

Log in as "root" (no password), then run

  apt update
  apt install -y --no-install-recommends qemu-system-x86 tuned

  curl -L -O https://download.cirros-cloud.net/0.3.5/cirros-0.3.5-i386-disk.img
  qemu-system-x86_64 -enable-kvm -nographic cirros-0.3.5-i386-disk.img -snapshot

The boot hangs as above. Again, when not installing or stopping tuned, it
works.

Thanks,

Martin