Bug#1065794: 1065794 is pending

[Maximilian Engelhardt]

Control: tags -1 + pending

Hi Sebastian,

Thanks for your report. We (the Debian xen team) are aware of this issue and 
are currently preparing an upload fixing this problem. It should be uploaded 
to the archive soon.

Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#1029998: [Pkg-xen-devel] Bug#1039422: xen and systemd support

[Maximilian Engelhardt]

resending so this also appears in #1029998.

Hi Yann,

Thanks for your mail.

> Maybe one of those bugs should be marked as dup?
Yes, doing so now.

> I noticed that building this package with libsystemd-dev installed
> causes a build failure, as unit files are then generated but not shipped
> by any package.  So technically today we seem to miss a Build-Conflicts:
> libsystemd-dev.
>
> However, it is likely better to move forward and enable it. I could see
> no comment in the BTS talking about any problems around that, are there
> any blockers going forward?
There is a related bug to this: https://bugs.debian.org/1028251

Basically the situation is a bit more complex, Knorrie wrote some good 
explanation in #1028251, I am going to copy the relevant part here to make it 
easier to understand the situation.


Yeah, well, so, the thing here is...

When Debian started to package Xen (thanks! Bastian, in 200X), the
upstream init scripts were copy pasted, and adjusted to have the ability
to have different Hypervisor-ABI-incompatible versions installed at the
same time. Also, this is related to the collection of Makefile patches
we carry around to have ABI-incompatible stuff end up in a directory
like /usr/lib/xen-4.14/ and /usr/lib/xen-4.17/ !

What does this mean? Well, in the most basic sense it means that you
could apt-get (dist-)upgrade and then still be able to xl shutdown a
domU afterwards before doing reboot, because it will choose the right
tools which match with the ABI of the *now* running hypervisor instead
of being left with a dumpster fire, which in the end causes you to shout
curse words and cause you to have to go to the machine and hold the
power button for 5 seconds to force power it off.

This is the thing about where you upgrade from Xen 4.14 to Xen 4.17
during the upgrade from Debian 11/Bullseye to Debian 12/Bookworm, it
will allow you, if booting the whole new thing is a huge failure, to
reset the computer, and in grub, choose to use the previous Xen (and
possibly do that in combination with previous Debian linux kernel) and
then have a system where you again at least can start your domUs again
*) and first have a good rest, night of sleep before starting to dig
into what's going wrong.

So, this is exactly the same way of doing stuff like how you can also
reboot back into the previous Linux kernel (ABI-compatible) one during a
system upgrade, even if you're not using Xen at all!

I like this very much. This is the kind of thing that helps admins of
systems that have just local disks and a few domUs. Like, the case where
you support some non-profit organization with their server stuff running
on donated hardware. (Yes, I also do some of those, I do!) And, in case
something does fail (there could always be something like a misbehaving
mpt3sas card in the hardware or anything that no one else spotted yet),
the admin does not have to end up in total panic mode after doing the
upgrade on a Friday afternoon lying upside down inside a broom closet,
but they can just at least recover from the situation and have something
that's running again, and then a day later, or 2 or 3 days or a week
later return on another planned moment to fix it, after asking around.

Upstream Xen stuff doesn't have anything like that.

But, they actually look at us, and they think, ooh, this is actually
nice, we should have that also by default.

The fact that we have this changed/altered/divergent init scripts in
Debian is the main reason that we cannot just enable systemd things
which will put upstream whatever on the system.

So, what could we do about this?

The project plan (that could be drafted on an A4 paper) could look like,
gather around all distro maintainers of Linux distro's that are shipping
Xen, and then search for a 'Project owner', which we totally need to be
someone that is actually employed at a company that actually cares about
getting the results of this.

Then we go look at the Debian stuff and fix upstream to do the same
thing, also fixing all the init/systemd stuff that got lost along the
way, and then we can push it down to all other distro's as well again.

And after all of that is done, there will be a time where we actually
(at Debian) can have a different response to everything init script
related than "sorry, probably won't happen".

If you look at the init script stuff in Xen upstream already, it quickly
shows that it's just a total dumpster fire. Someone cobbled up something
in the year 2005, and after that, only changes have been made by people
who actually tried to touch it for a few seconds with a 10-foot pole.

So, nobody is really caring about this. There is not an actual person
upstream who is involved into this. As long as that's the case, it's not
a healthy thing for ourselves to start to try fixing all of that from a
downstream POV.

We're currently doing 'good' with the Debian Xen Team, I think. We can
keep up with security updates, and we're in some sort of OK position to
get 

Bug#1039422: [Pkg-xen-devel] Bug#1039422: xen and systemd support

[Maximilian Engelhardt]

Control: forcemerge 1039422 1029998

Hi Yann,

Thanks for your mail.

> Maybe one of those bugs should be marked as dup?
Yes, doing so now.

> I noticed that building this package with libsystemd-dev installed
> causes a build failure, as unit files are then generated but not shipped
> by any package.  So technically today we seem to miss a Build-Conflicts:
> libsystemd-dev.
> 
> However, it is likely better to move forward and enable it. I could see
> no comment in the BTS talking about any problems around that, are there
> any blockers going forward?
There is a related bug to this: https://bugs.debian.org/1028251

Basically the situation is a bit more complex, Knorrie wrote some good 
explanation in #1028251, I am going to copy the relevant part here to make it 
easier to understand the situation.


Yeah, well, so, the thing here is...

When Debian started to package Xen (thanks! Bastian, in 200X), the
upstream init scripts were copy pasted, and adjusted to have the ability
to have different Hypervisor-ABI-incompatible versions installed at the
same time. Also, this is related to the collection of Makefile patches
we carry around to have ABI-incompatible stuff end up in a directory
like /usr/lib/xen-4.14/ and /usr/lib/xen-4.17/ !

What does this mean? Well, in the most basic sense it means that you
could apt-get (dist-)upgrade and then still be able to xl shutdown a
domU afterwards before doing reboot, because it will choose the right
tools which match with the ABI of the *now* running hypervisor instead
of being left with a dumpster fire, which in the end causes you to shout
curse words and cause you to have to go to the machine and hold the
power button for 5 seconds to force power it off.

This is the thing about where you upgrade from Xen 4.14 to Xen 4.17
during the upgrade from Debian 11/Bullseye to Debian 12/Bookworm, it
will allow you, if booting the whole new thing is a huge failure, to
reset the computer, and in grub, choose to use the previous Xen (and
possibly do that in combination with previous Debian linux kernel) and
then have a system where you again at least can start your domUs again
*) and first have a good rest, night of sleep before starting to dig
into what's going wrong.

So, this is exactly the same way of doing stuff like how you can also
reboot back into the previous Linux kernel (ABI-compatible) one during a
system upgrade, even if you're not using Xen at all!

I like this very much. This is the kind of thing that helps admins of
systems that have just local disks and a few domUs. Like, the case where
you support some non-profit organization with their server stuff running
on donated hardware. (Yes, I also do some of those, I do!) And, in case
something does fail (there could always be something like a misbehaving
mpt3sas card in the hardware or anything that no one else spotted yet),
the admin does not have to end up in total panic mode after doing the
upgrade on a Friday afternoon lying upside down inside a broom closet,
but they can just at least recover from the situation and have something
that's running again, and then a day later, or 2 or 3 days or a week
later return on another planned moment to fix it, after asking around.

Upstream Xen stuff doesn't have anything like that.

But, they actually look at us, and they think, ooh, this is actually
nice, we should have that also by default.

The fact that we have this changed/altered/divergent init scripts in
Debian is the main reason that we cannot just enable systemd things
which will put upstream whatever on the system.

So, what could we do about this?

The project plan (that could be drafted on an A4 paper) could look like,
gather around all distro maintainers of Linux distro's that are shipping
Xen, and then search for a 'Project owner', which we totally need to be
someone that is actually employed at a company that actually cares about
getting the results of this.

Then we go look at the Debian stuff and fix upstream to do the same
thing, also fixing all the init/systemd stuff that got lost along the
way, and then we can push it down to all other distro's as well again.

And after all of that is done, there will be a time where we actually
(at Debian) can have a different response to everything init script
related than "sorry, probably won't happen".

If you look at the init script stuff in Xen upstream already, it quickly
shows that it's just a total dumpster fire. Someone cobbled up something
in the year 2005, and after that, only changes have been made by people
who actually tried to touch it for a few seconds with a 10-foot pole.

So, nobody is really caring about this. There is not an actual person
upstream who is involved into this. As long as that's the case, it's not
a healthy thing for ourselves to start to try fixing all of that from a
downstream POV.

We're currently doing 'good' with the Debian Xen Team, I think. We can
keep up with security updates, and we're in some sort of OK position to
get the 

Bug#1063270: xen: NMU diff for 64-bit time_t transition

[Maximilian Engelhardt]

Control: found -1 4.17.2+76-ge1f9cb16e2-1

Hi Steve,

Thanks for taking care about the 64-bit time_t transition.

Unfortunately your attached patch looks a bit strange to me. It adds 
autogenerated files, but especially FTBFS in your experimental upload.

You can find an updated patch attached to this mail that only contains the 
relevant changes and does the rename in one more place to fix the FTBFS.

With this mail I also mark the xen version currently in testing as affected so 
this bug does not prevent the migration of the xen version currently in 
unstable (4.17.3+10-g091466ba55-1).

I also did compile xen in qemu for armhf one time with the current unstable 
version and one time with the change below to test the time_t transition.
The resulting binaries were the same (thanks xen is buildable reproducibly).
So maybe the transition is not needed for xen, but unfortunately my knowledge 
is not that much that I can say this for sure.


--- a/debian/rules
+++ b/debian/rules
@@ -12,6 +12,10 @@ export DEB_VERSION
 # DEB_MAINTAINER is used by our delta queue
 export DEB_MAINTAINER := $(shell sed -ne 's/^Maintainer: \(.*\)$$/\1/p' 
debian/control)
 
+export DEB_BUILD_OPTIONS=abi=+lfs
+export _FILE_OFFSET_BITS=64
+export _TIME_BITS=64
+
 # This influences dpkg-buildflags to specify better linker
 # options.  See https://wiki.debian.org/Hardening
 # Apparently some of these might incur silent breakage
@@ -26,7 +30,7 @@ export DEB_MAINTAINER := $(shell sed -ne 's/^Maintainer: 
\(.*\)$$/\1/p' debian/c
 # Inexplicably, if you tell make `export V=value' and `$(shell ...)'
 # it does not pass V to the shell.  WTF.  So we set a variable
 # dbmo which we include in the relevant $(shell ...) invocations.
-dbmo= DEB_BUILD_MAINT_OPTIONS="hardening=+all"
+dbmo= DEB_BUILD_MAINT_OPTIONS="hardening=+all abi=+lfs" _FILE_OFFSET_BITS=64 
_TIME_BITS=64
 
 # Architecture handling.
 #

diff -Nru xen-4.17.3+10-g091466ba55/debian/changelog xen-4.17.3+10-g091466ba55/debian/changelog
--- xen-4.17.3+10-g091466ba55/debian/changelog	2024-02-04 13:45:17.0 +0100
+++ xen-4.17.3+10-g091466ba55/debian/changelog	2024-02-05 23:37:19.0 +0100
@@ -1,3 +1,10 @@
+xen (4.17.3+10-g091466ba55-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Mon, 05 Feb 2024 22:37:19 +
+
 xen (4.17.3+10-g091466ba55-1) unstable; urgency=medium
 
   * Update to new upstream version 4.17.3+10-g091466ba55, which also contains
diff -Nru xen-4.17.3+10-g091466ba55/debian/control xen-4.17.3+10-g091466ba55/debian/control
--- xen-4.17.3+10-g091466ba55/debian/control	2024-02-04 13:45:17.0 +0100
+++ xen-4.17.3+10-g091466ba55/debian/control	2024-02-05 23:37:19.0 +0100
@@ -212,16 +212,16 @@
 Section: libdevel
 Architecture: amd64 arm64 armhf
 Depends: ${shlibs:Depends}, ${misc:Depends},
-	 libxenmisc4.17 (= ${binary:Version}),
-	 libxencall1 (= ${binary:Version}),
-	 libxendevicemodel1 (= ${binary:Version}),
-	 libxenevtchn1 (= ${binary:Version}),
-	 libxenforeignmemory1 (= ${binary:Version}),
-	 libxengnttab1 (= ${binary:Version}),
-	 libxenstore4 (= ${binary:Version}),
-	 libxentoolcore1 (= ${binary:Version}),
-	 libxentoollog1 (= ${binary:Version}),
-	 libxenhypfs1 (= ${binary:Version}),
+	 libxenmisc4.17t64 (= ${binary:Version}),
+	 libxencall1t64 (= ${binary:Version}),
+	 libxendevicemodel1t64 (= ${binary:Version}),
+	 libxenevtchn1t64 (= ${binary:Version}),
+	 libxenforeignmemory1t64 (= ${binary:Version}),
+	 libxengnttab1t64 (= ${binary:Version}),
+	 libxenstore4t64 (= ${binary:Version}),
+	 libxentoolcore1t64 (= ${binary:Version}),
+	 libxentoollog1t64 (= ${binary:Version}),
+	 libxenhypfs1t64 (= ${binary:Version}),
 Description: Public headers and libs for Xen
  This package contains the public headers and static libraries for Xen.
  .
@@ -236,7 +236,10 @@
  Most of the other included libraries are internal, and intended for
  use by the Xen toolstack, rather than directly.
 
-Package: libxenmisc4.17
+Package: libxenmisc4.17t64
+Provides: ${t64:Provides}
+Replaces: libxenmisc4.17
+Breaks: libxenmisc4.17 (<< ${source:Version})
 Section: libs
 Architecture: amd64 arm64 armhf
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -247,7 +250,10 @@
  knowledge of hypervisor-version-specific hypercall ABIs.
 Multi-Arch: same
 
-Package: libxencall1
+Package: libxencall1t64
+Provides: ${t64:Provides}
+Replaces: libxencall1
+Breaks: libxencall1 (<< ${source:Version})
 Section: libs
 Architecture: amd64 arm64 armhf
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -255,7 +261,10 @@
  Shared library for Xen utilities.
 Multi-Arch: same
 
-Package: libxendevicemodel1
+Package: libxendevicemodel1t64
+Provides: ${t64:Provides}
+Replaces: libxendevicemodel1
+Breaks: libxendevicemodel1 (<< ${source:Version})
 Section: libs
 Architecture: amd64 arm64 armhf
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -263,7 +272,10 @@
  Shared library for Xen utilities.
 Multi-Arch: 

Bug#1063035: bookworm-pu: package xen/4.17.3+10-g091466ba55-1~deb12u1

[Maximilian Engelhardt]

1.16.0
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
 
-QEMU_TRADITIONAL_REVISION ?= xen-4.17.1
+QEMU_TRADITIONAL_REVISION ?= xen-4.17.3
 
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
diff -Nru xen-4.17.2+76-ge1f9cb16e2/debian/changelog xen-4.17.3+10-g091466ba55/debian/changelog
--- xen-4.17.2+76-ge1f9cb16e2/debian/changelog	2023-12-02 17:58:08.0 +0100
+++ xen-4.17.3+10-g091466ba55/debian/changelog	2024-02-04 16:31:59.0 +0100
@@ -1,7 +1,32 @@
+xen (4.17.3+10-g091466ba55-1~deb12u1) bookworm; urgency=medium
+
+  * Rebuild 4.17.3+10-g091466ba55-1 for Bookworm to address the security
+issues since last Debian stable update.
+
+ -- Hans van Kranenburg   Sun, 04 Feb 2024 16:31:59 +0100
+
+xen (4.17.3+10-g091466ba55-1) unstable; urgency=medium
+
+  * Update to new upstream version 4.17.3+10-g091466ba55, which also contains
+security fixes for the following issues:
+- arm32: The cache may not be properly cleaned/invalidated (take two)
+  XSA-447 CVE-2023-46837
+- pci: phantom functions assigned to incorrect contexts
+  XSA-449 CVE-2023-46839
+- VT-d: Failure to quarantine devices in !HVM builds
+  XSA-450 CVE-2023-46840
+  * Note that the following XSA are not listed, because...
+- XSA-448 has patches for the Linux kernel.
+  * Compilation with Python 3.12 has been fixed in upstream commit 4000522008
+("Only compile the hypervisor with -Wdeclaration-after-statement")
+(Closes: #1062048)
+
+ -- Hans van Kranenburg   Sun, 04 Feb 2024 13:45:17 +0100
+
 xen (4.17.2+76-ge1f9cb16e2-1~deb12u1) bookworm; urgency=medium
 
   * Rebuild for bookworm to address the security issues since
-4.17.1+2-gb773c48e36-1 listed below.
+4.17.1+2-gb773c48e36-1 listed blow.
   * d/salsa-ci.yml: Set RELEASE variable to bookworm
 
  -- Maximilian Engelhardt   Sat, 02 Dec 2023 17:58:08 +0100
diff -Nru xen-4.17.2+76-ge1f9cb16e2/debian/.gitignore xen-4.17.3+10-g091466ba55/debian/.gitignore
--- xen-4.17.2+76-ge1f9cb16e2/debian/.gitignore	2023-12-02 17:58:08.0 +0100
+++ xen-4.17.3+10-g091466ba55/debian/.gitignore	1970-01-01 01:00:00.0 +0100
@@ -1,39 +0,0 @@
-.debhelper
-*.debhelper.*
-*.preinst.debhelper
-*.postinst.debhelper
-*.prerm.debhelper
-*.postrm.debhelper
-*.substvars
-*.stamp
-tmp
-*-[0-9]*.bug-control
-*-[0-9]*.postinst
-*-[0-9]*.postrm
-*.tmp
-files
-xen-doc
-xen-hypervisor-common
-xen-system-amd64
-xen-system-armhf
-xen-system-arm64
-xen-hypervisor-[0-9]*[0-9]
-xen-hypervisor-[0-9]*[0-9].install
-xen-hypervisor-[0-9]*[0-9].lintian-overrides
-xen-utils-[0-9]*[0-9]
-xen-utils-[0-9]*[0-9].install
-xen-utils-[0-9]*[0-9].NEWS
-xen-utils-[0-9]*[0-9].README.Debian
-xen-utils-[0-9]*[0-9].lintian-overrides
-xen-utils-[0-9]*[0-9].prerm
-libxenmisc[0-9]*[0-9].lintian-overrides
-libxenmisc[0-9]*[0-9]
-libxenmisc[0-9]*[0-9].install
-libxenmisc[0-9]*[0-9].lintian-overrides
-libxen-dev
-libxen*[0-9]
-xen-utils-common
-xenstore-utils
-autoreconf.before
-autoreconf.after
-debhelper-build-stamp
diff -Nru xen-4.17.2+76-ge1f9cb16e2/debian/patches/prefix-abiname/config-prefix.diff xen-4.17.3+10-g091466ba55/debian/patches/prefix-abiname/config-prefix.diff
--- xen-4.17.2+76-ge1f9cb16e2/debian/patches/prefix-abiname/config-prefix.diff	2023-12-02 17:58:08.0 +0100
+++ xen-4.17.3+10-g091466ba55/debian/patches/prefix-abiname/config-prefix.diff	2024-02-04 16:31:59.0 +0100
@@ -9,7 +9,7 @@
  2 files changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/Config.mk b/Config.mk
-index 4864033..2e9b672 100644
+index 8d91e4c..fc90691 100644
 --- a/Config.mk
 +++ b/Config.mk
 @@ -78,7 +78,7 @@ EXTRA_LIB += $(EXTRA_PREFIX)/lib
diff -Nru xen-4.17.2+76-ge1f9cb16e2/docs/misc/xen-command-line.pandoc xen-4.17.3+10-g091466ba55/docs/misc/xen-command-line.pandoc
--- xen-4.17.2+76-ge1f9cb16e2/docs/misc/xen-command-line.pandoc	2023-11-23 12:24:12.0 +0100
+++ xen-4.17.3+10-g091466ba55/docs/misc/xen-command-line.pandoc	2024-02-02 08:04:33.0 +0100
@@ -2758,6 +2758,15 @@
 
 Permit use of x2apic setup for SMP environments.
 
+### x2apic-mode (x86)
+> `= physical | cluster | mixed`
+
+> Default: `physical` if **FADT** mandates physical mode, otherwise set at
+>  build time by CONFIG_X2APIC_{PHYSICAL,LOGICAL,MIXED}.
+
+In the case that x2apic is in use, this option switches between modes to
+address APICs in the system as interrupt destinations.
+
 ### x2apic_phys (x86)
 > `= `
 
@@ -2768,6 +2777,9 @@
 clustered mode.  The default, given no hint from the **FADT**, is cluster
 mode.
 
+**WARNING: `x2apic_phys` is deprecated and superseded by `x2apic-mode`.
+The latter takes precedence if both are set.**
+
 ### xenheap_megabytes (arm32)
 > `= `
 
diff -Nru xen-4.17.2+76-ge1f9cb16e2/stubdom/Makefile xen-4.17.3+10-g091466ba55/stubdom/Makefile
--- xen-4.17.2+76-ge1f9cb16e2/stubdom/Makefile	2023-11-23 12:24:12.0 +0100
+++ xen-4.17.3+10-g091466ba55/stubdom/Makefile	2024

Bug#1062048: xen: FTBFS with Python 3.12 as default

[Maximilian Engelhardt]

Control: tags -1 +fixed-upstream

Hi,

this issue has been fixed upstream by
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=40be6307ec005539635e7b8fcef67e989dc441f6

and was backported to the upstream stable-4.17 branch in
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=4000522008711b1329a7cbb24612dfc355f3e46c

We will include the fix in the next upload.

signature.asc
Description: This is a digitally signed message part.

Bug#1057959: dhcpcd gets stopped during upgrade but never started again

[Maximilian Engelhardt]

On Mittwoch, 13. Dezember 2023 22:20:40 CET Martin-Éric Racine wrote:
> I've uploaded the fix to unstable.
> 
> Since this is not the sort of urgent issue that would warrant a
> separate update to Bookworm, I won't upload it there for now. However,
> I'll definitely include it if there ever is a security issue that
> requires an upload to Bookworm.
> 
> Martin-Éric

Hi Martin-Éric,

Thanks for the quick response and fix. I agree it does not make sense to fix 
the bug on it's own in bookworm as one won't run into this problem without the 
release of a new version.

Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#1057959: dhcpcd gets stopped during upgrade but never started again

[Maximilian Engelhardt]

On Montag, 11. Dezember 2023 08:51:36 CET Martin-Éric Racine wrote:
[...]
> 
> Unless I misunderstood, this is due to a change of debhelper behavior
> since compatibility level 10. This leaves me with two possible
> solutions:
> 
> 1) No dh_install option. This will restart after upgrade (default since dh
> 10).
> 
> 2) Add --no-stop-on-upgrade --no-restart-after-upgrade options. This
> will explicitely disable stop and restart actions.
> 
> Maximilian, which one of these two would make the most sense to you?
> 
> Here, I only use the binaries via ifupdown (i.e. only dhcpcd-base), so
> I have no preference.
> 
> Martin-Éric

Hi Martin-Éric,

I think for me both options should work. I guess for maximising uptime it 
would make sense to not restart dhcpcd and if it is important enough (e.g. due  
a security bug) inform the user (e.g. via NEWS) that a manual restart should 
happen as soon as possible.

Now that I think more about it, not stopping and starting automatically is 
probably the better option, because if something goes wrong during the update 
or the update is just stuck at a prompt it could else leave the system without 
network connectivity.
Better that stopping and starting again some time later would probably be just 
doing an restart once (stop and directly start again without delay) if that's 
possible.

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#1057959: dhcpcd gets stopped during upgrade but never started again

[Maximilian Engelhardt]

Package: dhcpcd
Version: 1:9.4.1-24~deb12u3
Severity: normal
X-Debbugs-Cc: m...@daemonizer.de

Hi,
during the recent point release I noticed that during the unattended-upgrades 
run dhcpcd was stopped but never started again. This is undesired as it breaks 
internet connection for me and I need to manually start it again.

The behaviour can be easily reproduces by these commands:

$ systemctl status dhcpcd.service | grep Active
 Active: active (running) since Mon 2023-12-11 00:13:36 CET; 1min 52s ago
$ apt reinstall dhcpcd
$ systemctl status dhcpcd.service | grep Active
 Active: inactive (dead) since Mon 2023-12-11 00:16:02 CET; 4s ago

Examining dhcpcd.preinst and dhcpcd.postinst scripts indeed shows that dhcpcd 
gets stopped in the preinst script, but never started again anywhere.

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#1053246: Security support ended for Xen 4.14 in Bullseye

[Maximilian Engelhardt]

On Montag, 2. Oktober 2023 19:18:49 CET Santiago Ruano Rincón wrote:
> El 30/09/23 a las 00:09, Hans van Kranenburg escribió:
> > Package: debian-security-support
> > Version: 1:11+2023.05.04
> > Severity: normal
> > 
> > Hi,
> > 
> > Upstream security support for Xen 4.14 has ended recently. This also
> > means that security support for Debian Bullseye has ended.
> > 
> > The complexity of the software involved does not really allow for anyone
> > else than the upstream developers, with a deep understanding of the
> > inner workings of the hypervisor code, to apply/backport new patches.
> > 
> > For security-support-ended.deb11, this could be a line like:
> > 
> > xen 4.14.6-1 2023-09-21
> > https://xenbits.xen.org/docs/4.14-testing/SUPPORT.html#release-support
> > 
> > Note: This 4.14.6-1 package version is not visible for bullseye yet,
> > right now, in the archive. It was submitted for the bullseye point
> > release, and has just been accepted into it:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053177
> > 
> > Thanks,
> > Hans
> 
> Hello,
> 
> Could you please wait a little bit before moving forward. In the Debian
> bullseye LTS context, we would like to know if there are interest from
> LTS users, and look for help to maintain it. At least, partially.
> 
> Thank you,
> 
>  -- Santiago

Hi Santiago,

Any update on this?
As upstream security support for xen 4.14 has ended, the Debian xen team 
doesn't have the knowledge and resources to provide further security support.
So if there are people with the resources and knowledge to further provide 
security support for xen in bullseye it would be good to know this is 
happening.
But if not, it would also be good to inform our users that there is no longer 
security support for xen in bullseye.

Thanks,
Maxi


signature.asc
Description: This is a digitally signed message part.

Bug#1042102: Also fixed in upstream stable-4.17 branch

[Maximilian Engelhardt]

This commit got also included in the upstream stable-4.17 branch:

https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=a91b946345b0c0550d0ee28816a15d3fc16abc50

signature.asc
Description: This is a digitally signed message part.

Bug#1038901: xen dom0 erroneous detected as 'xen' virtualization by systemd-detect-virt

[Maximilian Engelhardt]

Package: systemd
Version: 252.6-1
Severity: normal
X-Debbugs-Cc: m...@daemonizer.de
Control: affects -1 + src:xen

When running the xen hypervisor, systemd-detect-virt erroneous detects 'xen'
virtualization on the dom0:

$ systemd-detect-virt
xen

The expected output should be 'none', in case of a dom0 with no other
virtualization. The documentation [1] says 'xen' corresponds to "Xen 
hypervisor (only domU, not dom0)".

Here is some more debug output in the hope it will be helpful:

On a dom0 (detect wrongly):
$ SYSTEMD_LOG_LEVEL=debug systemd-detect-virt
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
No virtualization found in DMI vendor table.
DMI BIOS Extension table does not indicate virtualization.
UML virtualization not found in /proc/cpuinfo.
Virtualization XEN found (/proc/xen exists)
Virtualization XEN, found /sys/hypervisor/properties/features with value 
000228f0, XENFEAT_dom0 (indicating the 'hardware domain') is set.
Virtualization found, CPUID=XenVMMXenVMM
Found VM virtualization xen
xen

On a domU (detected correctly):
$ SYSTEMD_LOG_LEVEL=debug systemd-detect-virt
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
No virtualization found in DMI vendor table.
Unable to read /sys/firmware/dmi/entries/0-0/raw, using the virtualization 
information found in DMI vendor table, ignoring: No such file or directory
UML virtualization not found in /proc/cpuinfo.
Virtualization XEN found (/proc/xen exists)
Virtualization XEN, found /sys/hypervisor/properties/features with value 
00012305, XENFEAT_dom0 (indicating the 'hardware domain') is not set.
Found VM virtualization xen
xen

XENFEAT_dom0 seems to be detected correctly in both cases, but the dom0 has 
one additional line which is not present in the domU output:
Virtualization found, CPUID=XenVMMXenVMM

This behavior is especially a problem since the smartmontools service file has
"ConditionVirtualization=no" and thus does not get started on the dom0.

This problem might be related to the upstream bug [2], but the symptoms are a
bit different.

[1] https://manpages.debian.org/bookworm/systemd/systemd-detect-virt.1.en.html
[2] https://github.com/systemd/systemd/issues/28113


signature.asc
Description: This is a digitally signed message part.

Bug#1036601: xenstore-utils: broken symlink /usr/bin/xenstore-control

[Maximilian Engelhardt]

Control: retitle -1 xenstore-utils: broken symlink /usr/bin/xenstore-control

This is a bit more complicated:

Up to bullseye the binaries in the xenstore-utils package were independent of 
the running xen version (as the xenstore interface is more or less supposed to 
be stable).

Starting with bookworm the xenstore-control binary is now linked against 
unstable xen api libraries (libxenguest.so and libxenctrl.so) which are 
included in the libxenmisc4.17 package.
The upstream commit for this change is [1] and the documentation also says 
that the control command interface is not xen version independent.

Because of the additional shared library dependencies our shuffle-binaries 
script [3] kicks in and sets up the xen-utils-wrapper for xenstore-control.

The xen-utils-wrapper is only included in the xen-utils-common package. But 
adding that dependency would not be enough. It would make the /usr/bin/
xenstore-control symlink not broken, but the wrapper would not find the real 
binary, as it is included in the xen-utils-4.17 package at the /usr/lib/
xen-4.17/bin/xenstore-control path.

Installing only xenstore-utils and xen-utils-common in a dom-U gives the 
following output when executing xenstore-control:
$ xenstore-control 
ERROR:  Can't find version 4.17 of xen utils (maybe xen-utils-4.17 was already 
removed before rebooting out of Xen 4.17), bailing out!


Some options I see for fixing this:

[a] make xenstore-utils depend on xen-utils-V
[b] move the /usr/bin/xenstore-control symlink to xen-utils-V
[c] split the xenstore-utils package in a xen version independent and xen 
version dependent package.

Disadvantage from [a] is that xenstore-utils can also be used inside a dom-U 
and would pull lots of unused stuff. [c] seems to be a bit overkill for only 
one binary file, so I currently see [b] as the best option.

So does anybody have any opinion, ideas or something else to say about all 
this? Or any better ideas?


[1] 
https://salsa.debian.org/xen-team/debian-xen/-/commit/7f97193e6aa858df03be501440e0ade8cceb9ec5
[2] 
https://salsa.debian.org/xen-team/debian-xen/-/blob/master/docs/misc/xenstore.txt#L378
[3] 
https://salsa.debian.org/xen-team/debian-xen/-/blob/master/debian/shuffle-binaries


signature.asc
Description: This is a digitally signed message part.

Bug#1036475: unblock: xen/4.17.1+2-gb773c48e36-1

[Maximilian Engelhardt]

emu-alpine-arm64.sh	2023-05-16 17:23:29.0 +0200
@@ -2,14 +2,6 @@
 
 set -ex
 
-apt-get -qy update
-apt-get -qy install --no-install-recommends u-boot-qemu \
-u-boot-tools \
-device-tree-compiler \
-cpio \
-curl \
-busybox-static
-
 # DomU Busybox
 cd binaries
 mkdir -p initrd
diff -Nru xen-4.17.0+74-g3eac216e6e/automation/scripts/qemu-alpine-x86_64.sh xen-4.17.1+2-gb773c48e36/automation/scripts/qemu-alpine-x86_64.sh
--- xen-4.17.0+74-g3eac216e6e/automation/scripts/qemu-alpine-x86_64.sh	2023-03-21 13:47:52.0 +0100
+++ xen-4.17.1+2-gb773c48e36/automation/scripts/qemu-alpine-x86_64.sh	2023-05-16 17:23:29.0 +0200
@@ -2,10 +2,6 @@
 
 set -ex
 
-apt-get -qy update
-apt-get -qy install --no-install-recommends cpio \
-busybox-static
-
 # DomU Busybox
 cd binaries
 mkdir -p initrd
diff -Nru xen-4.17.0+74-g3eac216e6e/automation/scripts/qemu-smoke-arm32.sh xen-4.17.1+2-gb773c48e36/automation/scripts/qemu-smoke-arm32.sh
--- xen-4.17.0+74-g3eac216e6e/automation/scripts/qemu-smoke-arm32.sh	2023-03-21 13:47:52.0 +0100
+++ xen-4.17.1+2-gb773c48e36/automation/scripts/qemu-smoke-arm32.sh	2023-05-16 17:23:29.0 +0200
@@ -2,12 +2,6 @@
 
 set -ex
 
-export DEBIAN_FRONTEND=noninteractive
-apt-get -qy update
-apt-get -qy install --no-install-recommends device-tree-compiler \
-curl \
-cpio
-
 cd binaries
 # Use the kernel from Debian
 curl --fail --silent --show-error --location --output vmlinuz http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/current/images/netboot/vmlinuz
diff -Nru xen-4.17.0+74-g3eac216e6e/automation/scripts/qemu-smoke-arm64.sh xen-4.17.1+2-gb773c48e36/automation/scripts/qemu-smoke-arm64.sh
--- xen-4.17.0+74-g3eac216e6e/automation/scripts/qemu-smoke-arm64.sh	2023-03-21 13:47:52.0 +0100
+++ xen-4.17.1+2-gb773c48e36/automation/scripts/qemu-smoke-arm64.sh	2023-05-16 17:23:29.0 +0200
@@ -38,15 +38,6 @@
 "
 fi
 
-export DEBIAN_FRONTEND=noninteractive
-apt-get -qy update
-apt-get -qy install --no-install-recommends u-boot-qemu \
-u-boot-tools \
-device-tree-compiler \
-busybox-static \
-cpio \
-curl
-
 # XXX QEMU looks for "efi-virtio.rom" even if it is unneeded
 curl -fsSLO https://github.com/qemu/qemu/raw/v5.2.0/pc-bios/efi-virtio.rom
 ./binaries/qemu-system-aarch64 \
diff -Nru xen-4.17.0+74-g3eac216e6e/Config.mk xen-4.17.1+2-gb773c48e36/Config.mk
--- xen-4.17.0+74-g3eac216e6e/Config.mk	2023-03-21 13:47:52.0 +0100
+++ xen-4.17.1+2-gb773c48e36/Config.mk	2023-05-16 17:23:29.0 +0200
@@ -229,15 +229,15 @@
 MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
 OVMF_UPSTREAM_REVISION ?= 7b4a99be8a39c12d3a7fc4b8db9f0eab4ac688d5
-QEMU_UPSTREAM_REVISION ?= qemu-xen-4.17.0
-MINIOS_UPSTREAM_REVISION ?= xen-RELEASE-4.17.0
+QEMU_UPSTREAM_REVISION ?= qemu-xen-4.17.1
+MINIOS_UPSTREAM_REVISION ?= xen-RELEASE-4.17.1
 
 SEABIOS_UPSTREAM_REVISION ?= rel-1.16.0
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
 
-QEMU_TRADITIONAL_REVISION ?= xen-4.17.0
+QEMU_TRADITIONAL_REVISION ?= xen-4.17.1
 
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
diff -Nru xen-4.17.0+74-g3eac216e6e/debian/changelog xen-4.17.1+2-gb773c48e36/debian/changelog
--- xen-4.17.0+74-g3eac216e6e/debian/changelog	2023-03-23 22:22:48.0 +0100
+++ xen-4.17.1+2-gb773c48e36/debian/changelog	2023-05-18 21:26:30.0 +0200
@@ -1,3 +1,15 @@
+xen (4.17.1+2-gb773c48e36-1) unstable; urgency=medium
+
+  * Update to new upstream version 4.17.1+2-gb773c48e36, which also contains
+security fixes for the following issues:
+- x86 shadow paging arbitrary pointer dereference
+  XSA-430 CVE-2022-42335
+  (Closes: #1034842)
+- Mishandling of guest SSBD selection on AMD hardware
+  XSA-431 CVE-2022-42336
+
+ -- Maximilian Engelhardt   Thu, 18 May 2023 21:26:30 +0200
+
 xen (4.17.0+74-g3eac216e6e-1) unstable; urgency=medium
 
   * Update to new upstream version 4.17.0+74-g3eac216e6e, which also contains
diff -Nru xen-4.17.0+74-g3eac216e6e/debian/patches/prefix-abiname/config-prefix.diff xen-4.17.1+2-gb773c48e36/debian/patches/prefix-abiname/config-prefix.diff
--- xen-4.17.0+74-g3eac216e6e/debian/patches/prefix-abiname/config-prefix.diff	2023-03-23 22:22:48.0 +0100
+++ xen-4.17.1+2-gb773c48e36/debian/patches/prefix-abiname/config-prefix.diff	2023-05-18 21:26:30.0 +0200
@@ -9,7 +9,

Bug#1033676: unblock: xen/4.17.0+74-g3eac216e6e-1

[Maximilian Engelhardt]

Control: retitle -1 unblock: xen/4.17.0+74-g3eac216e6e-1

On Sonntag, 2. April 2023 21:51:11 CEST Sebastian Ramacher wrote:
> On 2023-03-29 23:27:11 +0200, Maximilian Engelhardt wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: x...@packages.debian.org, m...@daemonizer.de,
> > t...@security.debian.org Control: affects -1 + src:xen
> > 
> > Please approve an upload of xen to unstable and later unblock package
> > xen. See the "Other info" section below on why this is a pre-approval
> > request.
> 
> Please go ahead
> 
> Cheers

Thanks, xen/4.17.0+74-g3eac216e6e-1 has been uploaded to unstable and already 
built on all architectures.

> > [ Reason ]
> > Xen in bookworm (and unstable) is currently affected by CVE-2022-42331,
> > CVE-2022-42332, CVE-2022-42333 and CVE-2022-42334 (see #1033297).
> > 
> > [ Impact ]
> > The above mentioned CVEs are not fixed.
> > 
> > [ Tests ]
> > The Debian package is based only on upstream commits that have passed
> > the upstream automated tests.
> > The Debian package has been successfully tested by the xen packaging
> > team on their test machines.
> > 
> > [ Risks ]
> > There could be upstream changes unrelated to the above mentioned
> > security fixes that cause regressions. However upstream has an automated
> > testing machinery (osstest) that only allows a commit in the upstream
> > stable branch if all test pass.
> > 
> > [ Checklist ]
> > 
> >   [x] all changes are documented in the d/changelog
> >   [x] I reviewed all changes and I approve them
> >   [x] attach debdiff against the package in testing
> > 
> > [ Other info ]
> > This security fix is based on the latest upstream stable-4.17 branch.
> > The branch in general only accepts bug fixes and does not allow new
> > features, so the changes there are mainly security and other bug fixes.
> > This does not exactly follow the "only targeted fixes" release policy,
> > so we are asking for a pre-approval.
> > The package we have prepared is exactly what we would have done as a
> > security update in a stable release, what we have historically done
> > together with the security team and are planning to continue to do.
> > As upstream does extensive automated testing on their stable branches
> > chances for unnoticed regressions are low. We believe this way the risk
> > for bugs is lower than trying to manually pick and adjust patches
> > without all the deep knowledge that upstream has. This approach is
> > similar to what the linux package is doing.
> > 
> > unblock xen/4.17.0+74-g3eac216e6e-1
> > 
> > Thanks
> > 


signature.asc
Description: This is a digitally signed message part.

Bug#1033676: unblock: xen/4.17.0+74-g3eac216e6e-1 (pre-approval)

[Maximilian Engelhardt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: x...@packages.debian.org, m...@daemonizer.de, 
t...@security.debian.org
Control: affects -1 + src:xen

Please approve an upload of xen to unstable and later unblock package
xen. See the "Other info" section below on why this is a pre-approval
request.

[ Reason ]
Xen in bookworm (and unstable) is currently affected by CVE-2022-42331,
CVE-2022-42332, CVE-2022-42333 and CVE-2022-42334 (see #1033297).

[ Impact ]
The above mentioned CVEs are not fixed.

[ Tests ]
The Debian package is based only on upstream commits that have passed
the upstream automated tests.
The Debian package has been successfully tested by the xen packaging
team on their test machines.

[ Risks ]
There could be upstream changes unrelated to the above mentioned
security fixes that cause regressions. However upstream has an automated
testing machinery (osstest) that only allows a commit in the upstream
stable branch if all test pass.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
This security fix is based on the latest upstream stable-4.17 branch.
The branch in general only accepts bug fixes and does not allow new
features, so the changes there are mainly security and other bug fixes.
This does not exactly follow the "only targeted fixes" release policy,
so we are asking for a pre-approval.
The package we have prepared is exactly what we would have done as a
security update in a stable release, what we have historically done
together with the security team and are planning to continue to do.
As upstream does extensive automated testing on their stable branches
chances for unnoticed regressions are low. We believe this way the risk
for bugs is lower than trying to manually pick and adjust patches
without all the deep knowledge that upstream has. This approach is
similar to what the linux package is doing.

unblock xen/4.17.0+74-g3eac216e6e-1

Thanksdiff -Nru xen-4.17.0+46-gaaf74a532c/debian/changelog xen-4.17.0+74-g3eac216e6e/debian/changelog
--- xen-4.17.0+46-gaaf74a532c/debian/changelog	2023-02-24 18:06:42.0 +0100
+++ xen-4.17.0+74-g3eac216e6e/debian/changelog	2023-03-23 22:22:48.0 +0100
@@ -1,3 +1,16 @@
+xen (4.17.0+74-g3eac216e6e-1) unstable; urgency=medium
+
+  * Update to new upstream version 4.17.0+74-g3eac216e6e, which also contains
+security fixes for the following issues: (Closes: #1033297)
+- x86 shadow plus log-dirty mode use-after-free
+  XSA-427 CVE-2022-42332
+- x86/HVM pinned cache attributes mis-handling
+  XSA-428 CVE-2022-42333 CVE-2022-42334
+- x86: speculative vulnerability in 32bit SYSCALL path
+  XSA-429 CVE-2022-42331
+
+ -- Maximilian Engelhardt   Thu, 23 Mar 2023 22:22:48 +0100
+
 xen (4.17.0+46-gaaf74a532c-1) unstable; urgency=medium
 
   * Update to new upstream version 4.17.0+46-gaaf74a532c, which also contains
diff -Nru xen-4.17.0+46-gaaf74a532c/docs/misc/xen-command-line.pandoc xen-4.17.0+74-g3eac216e6e/docs/misc/xen-command-line.pandoc
--- xen-4.17.0+46-gaaf74a532c/docs/misc/xen-command-line.pandoc	2023-02-22 15:14:33.0 +0100
+++ xen-4.17.0+74-g3eac216e6e/docs/misc/xen-command-line.pandoc	2023-03-21 13:47:52.0 +0100
@@ -287,10 +287,15 @@
 protection.
 
 The option is available when `CONFIG_XEN_SHSTK` is compiled in, and
-defaults to `true` on hardware supporting CET-SS.  Specifying
+generally defaults to `true` on hardware supporting CET-SS.  Specifying
 `cet=no-shstk` will cause Xen not to use Shadow Stacks even when support
 is available in hardware.
 
+Some hardware suffers from an issue known as Supervisor Shadow Stack
+Fracturing.  On such hardware, Xen will default to not using Shadow Stacks
+when virtualised.  Specifying `cet=shstk` will override this heuristic and
+enable Shadow Stacks unilaterally.
+
 *   The `ibt=` boolean controls whether Xen uses Indirect Branch Tracking for
 its own protection.
 
@@ -721,6 +726,11 @@
 * `all`: just one runqueue shared by all the logical pCPUs of
  the host
 
+Regardless of the above choice, Xen attempts to respect
+`sched_credit2_max_cpus_runqueue` limit, which may mean more than one runqueue
+for the `all` value. If that isn't intended, raise
+the `sched_credit2_max_cpus_runqueue` value.
+
 ### dbgp
 > `= ehci[  | @pci:. ]`
 > `= xhci[  | @pci:. ][,share=|hwdom]`
@@ -2624,6 +2634,17 @@
 ,  and  must be integers. The values will be
 encoded in guest CPUID 0x4002 if viridian enlightenments are enabled.
 
+### vm-notify-window (Intel)
+> `= `
+
+> Default: `0`
+
+Specify the value of the VM Notify window used to detect locked VMs. Set to -1
+to disable the feature.  Value is in units of crystal clock cycles.
+
+Note the hardware might add a threshold to the

Bug#1003002: some more information - possible solution

[Maximilian Engelhardt]

On Sonntag, 4. Dezember 2022 01:42:14 CET Christian Kastner wrote:
> Can anyone else give this patch a try before I submit an MR?

Uh, this is great news and an easy fix.

I did some tests and can confirm that your patch fixes this problem for me.



signature.asc
Description: This is a digitally signed message part.

Bug#1003002: some more information

[Maximilian Engelhardt]

I did some more tests as I also ran into this problem. Here is what I could 
find out until now:

I start qemu manually in a similar way as done by autopkgtest with the 
following command:

$ qemu-system-arm -machine virt -m 1024 -smp 1 -display none -net 
nic,model=virtio -net user,hostfwd=tcp:127.0.0.1:10022-:22 -object 
rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0,id=rng-device0 -monitor unix:monitor,server=on,wait=off 
-virtfs 
local,id=autopkgtest,path=shared,security_model=none,mount_tag=autopkgtest 
-serial unix:ttyS0,server=on,wait=off -chardev 
socket,path=hvc0,server=on,wait=off,id=hvc0 -device virtio-serial -device 
virtconsole,chardev=hvc0 -chardev socket,path=hvc1,server=on,wait=off,id=hvc1 
-device virtio-serial -device virtconsole,chardev=hvc1 -chardev 
socket,path=hvc2,server=on,wait=off,id=hvc2 -device virtio-serial -device 
virtconsole,chardev=hvc2 -drive 
index=0,file=overlay-tmp/overlay.img,cache=unsafe,if=virtio,discard=unmap,format=qcow2
 -drive 
if=pflash,format=raw,unit=0,read-only,file=/usr/share/AAVMF/AAVMF32_CODE.fd 
-drive if=pflash,format=raw,unit=1,file=overlay-tmp/efivars.fd

I added a third console hvc2 to illustrate my findings better, see below.

Before being able to start this qemu command, I had to do some preparations:

$ qemu-img create -f qcow2 -F qcow2 -b 
/var/local/autopkgtest-unstable-armhf.img overlay-tmp/overlay.img
$ cp /usr/share/AAVMF/AAVMF32_VARS.fd overlay-tmp/efivars.fd

After starting qemu, I can attach to the serial ports with:
$ socat -,echo=0,icanon=0 unix-connect:ttyS0
$ socat -,echo=0,icanon=0 unix-connect:hvc0
$ socat -,echo=0,icanon=0 unix-connect:hvc1
$ socat -,echo=0,icanon=0 unix-connect:hvc2

What I noticed after booting the autopkgtest image is the following:

ttyAMA0 inside the vm is ttyS0 outside
hvc0 inside the vm is hvc1 outside
hcv1 inside the vm is hvc2 outside
hvc0 outside the vm doesn't seem to do anything

So that's the problem, the hvc console numbers are all shifted by one. If you 
leave out hvc2 in the qemu command line (to get the same as done by 
autopkgtest), then hcv1 inside the vm does not exist: "No such device".

But there is more interesting stuff:

When I log into the vm and execute the following commands, the numbering 
changes:

# rmmod virtio_console
# modprobe virtio_console

Now hvc0 inside the vm is also hvc0 outside. And the same for hvc1 and hvc2. 
So everything is now as I would expect it.

I have no idea what's going on here. Is this a bug in the Linux kernel? The 
kernel I did my tests with is 5.16.0-2-armmp-lpae.
I could imagine this is a race somewhere, which might also explain Christian's 
observations with arm64.

I still have an old autopkgtest armhf image from Jun 6 2021 that has linux 
5.10.0-7-armmp-lpae and doesn't show that behaviour. So some change after that 
must have broken the console numbering.

signature.asc
Description: This is a digitally signed message part.

Bug#1006300: src:libvirt: libvirt should no longer build the libvirt-daemon-driver-xen package on i386

[Maximilian Engelhardt]

Package: src:libvirt
Version: 8.0.0-1
Severity: normal
Tags: patch

Hi,

Starting with version 4.16, the xen package in Debian stopped building xen on
the i386 architecture. We only realized shortly after uploading to unstable
that this change also affects the packages that depend on us.

One step to clean this up now is to adjust libvirt accordingly and stop
building the libvirt-daemon-driver-xen package on i386.
Attached is a patch that does this by removing i386 from ARCHES_XEN as well as
adjusting package dependencies. Please review and apply the patch.

If you have any questions feel free to ask on #debian-xen or on the
pkg-xen-de...@lists.alioth.debian.org list.

Thanks,
Maxidiff -Nru libvirt-8.0.0/debian/changelog libvirt-8.0.0/debian/changelog
--- libvirt-8.0.0/debian/changelog	2022-01-22 19:22:57.0 +0100
+++ libvirt-8.0.0/debian/changelog	2022-02-21 23:13:01.0 +0100
@@ -1,3 +1,11 @@
+libvirt (8.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove i386 from ARCHES_XEN. Starting with xen version 4.16, xen is no
+longer built on the i386 architecture in Debian.
+
+ -- Maximilian Engelhardt   Mon, 21 Feb 2022 23:13:01 +0100
+
 libvirt (8.0.0-1) unstable; urgency=medium
 
   * [a26cc81] New upstream version 8.0.0
diff -Nru libvirt-8.0.0/debian/control libvirt-8.0.0/debian/control
--- libvirt-8.0.0/debian/control	2022-01-22 19:22:57.0 +0100
+++ libvirt-8.0.0/debian/control	2022-02-20 23:35:29.0 +0100
@@ -45,7 +45,7 @@
  libtirpc-dev,
  libudev-dev [linux-any],
  libwireshark-dev,
- libxen-dev [amd64 arm64 armhf i386],
+ libxen-dev [amd64 arm64 armhf],
  libxml2-dev,
  libxml2-utils,
  libyajl-dev,
@@ -221,7 +221,7 @@
 
 Package: libvirt-daemon-driver-xen
 Section: admin
-Architecture: amd64 arm64 armhf i386
+Architecture: amd64 arm64 armhf
 Multi-Arch: no
 Depends:
  libvirt-daemon (= ${binary:Version}),
@@ -474,7 +474,7 @@
 Multi-Arch: same
 Depends:
  libvirt0 (= ${binary:Version}),
- libxen-dev [i386 amd64 armhf arm64],
+ libxen-dev [amd64 armhf arm64],
  ${misc:Depends},
 Recommends:
  pkg-config,
diff -Nru libvirt-8.0.0/debian/rules libvirt-8.0.0/debian/rules
--- libvirt-8.0.0/debian/rules	2022-01-22 19:22:57.0 +0100
+++ libvirt-8.0.0/debian/rules	2022-02-20 23:38:09.0 +0100
@@ -16,7 +16,7 @@
 include /usr/share/dpkg/buildflags.mk
 
 ARCHES_LXC  = alpha amd64 arm64 armel armhf hppa i386 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
-ARCHES_XEN  = amd64 arm64 armhf i386
+ARCHES_XEN  = amd64 arm64 armhf
 ARCHES_VBOX = amd64 i386
 
 ifneq (,$(findstring $(DEB_HOST_ARCH_OS), linux))


signature.asc
Description: This is a digitally signed message part.

Bug#1006250: src:collectd: collectd should no longer build the xencpu plugin on i386

[Maximilian Engelhardt]

Package: src:collectd
Version: 5.12.0-8
Severity: normal
Tags: patch

Hi,

Starting with version 4.16, the xen package in Debian stopped building xen on
the i386 architecture. We only realized shortly after uploading to unstable 
that this change also affects the packages that depend on us.

One step to clean this up now is to adjust collectd accordingly and stop
building the xencpu plugin on i386. Please review and apply my attached patch 
which disables the xencpu plugin on i386.

If you have any questions feel free to ask on #debian-xen or on the
pkg-xen-de...@lists.alioth.debian.org list.

Thanks,
Maxidiff -Nru collectd-5.12.0/debian/changelog collectd-5.12.0/debian/changelog
--- collectd-5.12.0/debian/changelog	2022-01-20 15:40:42.0 +0100
+++ collectd-5.12.0/debian/changelog	2022-02-20 23:41:12.0 +0100
@@ -1,3 +1,11 @@
+collectd (5.12.0-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't build the xencpu plugin on i386. Starting with xen version 4.16, xen
+is no longer built on the i386 architecture in Debian.
+
+ -- Maximilian Engelhardt   Sun, 20 Feb 2022 23:41:12 +0100
+
 collectd (5.12.0-8) unstable; urgency=medium
 
   [ Kentaro Hayashi ]
diff -Nru collectd-5.12.0/debian/control collectd-5.12.0/debian/control
--- collectd-5.12.0/debian/control	2022-01-20 15:40:42.0 +0100
+++ collectd-5.12.0/debian/control	2022-02-20 23:40:32.0 +0100
@@ -52,7 +52,7 @@
  libupsclient-dev | libupsclient1-dev,
  libvarnishapi-dev,
  libvirt-dev (>= 0.4.0-6) [linux-any],
- libxen-dev [amd64 arm64 armhf i386],
+ libxen-dev [amd64 arm64 armhf],
  libxml2-dev,
  libyajl-dev,
  linux-libc-dev (>= 2.6.25-4) [linux-any] | linux-libc-dev (<< 2.6.25-1) [linux-any],
diff -Nru collectd-5.12.0/debian/rules collectd-5.12.0/debian/rules
--- collectd-5.12.0/debian/rules	2022-01-20 15:40:42.0 +0100
+++ collectd-5.12.0/debian/rules	2022-02-20 23:40:59.0 +0100
@@ -217,7 +217,7 @@
 endif
 
 # This plugin is x86 and arm specific.
-ifeq (,$(filter amd64 arm64 armhf i386, $(DEB_HOST_ARCH)))
+ifeq (,$(filter amd64 arm64 armhf, $(DEB_HOST_ARCH)))
 	confflags += \
 		--disable-xencpu
 endif


signature.asc
Description: This is a digitally signed message part.

Bug#1004269: Linker segfault while building src:xen

[Maximilian Engelhardt]

Control: found -1 2.37.90.20220123-2
Control: affects -1 src:xen

Hi,

this bug is still present in my sbuild chroot (updated about an hour ago) when 
compiling xen 4.14.3+32-g9de3671772-1 from unstable. I managed to run 
x86_64-linux-gnu-ld inside gdb to catch the segmentation fault. Please see the 
output below. I hope this is helpful to somebody tracking down the problem.

Please note for the xen case:
in
https://sources.debian.org/src/xen/4.14.3+32-g9de3671772-1/xen/arch/x86/Makefile/?hl=185#L185
the linker is checked for PE support. If it segfaults during this check the 
build system will disable building some parts below in this Makefile. So in 
this case it might never try to call the command from my gdb output below.
In my sbuild this check command randomly completes with return code 0 or with 
a segmentation fault using the following command:
$ x86_64-linux-gnu-ld -mi386pep --subsystem=10 --image-base=0x1 
--stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x20 
--file-alignment=0x20 --major-image-version=4 --minor-image-version=14 
--major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 
--minor-subsystem-version=0 -o efi/check.efi efi/check.o


$ gdb -batch -n -ex 'set pagination off' -ex 'run -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 --strip-debug 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=14 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp   
--build-id=sha1 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o 
/build/xen-Hf5EN0/xen-4.14.3+32-g9de3671772/xen/common/symbols-dummy.o -b 
pe-x86-64 efi/buildid.o -o 
/build/xen-Hf5EN0/xen-4.14.3+32-g9de3671772/xen/.xen.efi.0x82d04000.0 
&&  x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d08000 --stack=0,0 --heap=0,0 --strip-debug 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=14 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp   
--build-id=sha1 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o 
/build/xen-Hf5EN0/xen-4.14.3+32-g9de3671772/xen/common/symbols-dummy.o -b 
pe-x86-64 efi/buildid.o -o 
/build/xen-Hf5EN0/xen-4.14.3+32-g9de3671772/xen/.xen.efi.0x82d08000.0' 
-ex bt -ex 'bt full' --args x86_64-linux-gnu-ld

Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x77f6bbac in coff_write_auxent_fname.isra.0 (str=0x23527e , auxent=auxent@entry=0x7fffe208, 
string_size_p=string_size_p@entry=0x7fffe2d8, abfd=, 
abfd=) at ../../bfd/coffgen.c:856
#2  0x77f3806d in coff_write_symbol (abfd=0x55701b20, 
symbol=0x77973780, native=native@entry=0x7fffe1c0, 
written=0x7fffe2d0, string_size_p=0x7fffe2d8, 
debug_string_section_p=debug_string_section_p@entry=0x0, 
debug_string_size_p=0x0) at ../../bfd/coffgen.c:1043
#3  0x77f3834e in coff_write_alien_symbol (abfd=, 
symbol=, isym=0x7fffe310, iaux=0x7fffe2e0, 
written=, string_size_p=, 
debug_string_section_p=0x0, debug_string_size_p=0x0) at ../../bfd/coffgen.c:1154
#4  0x77f2e74a in _bfd_coff_final_link (abfd=, 
info=0x556fa3c0 ) at ../../bfd/cofflink.c:928
#5  0x5559b53f in ldwrite () at ../../ld/ldwrite.c:545
#6  main (argc=, argv=) at ../../ld/ldmain.c:513
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
No locals.
#1  0x77f6bbac in coff_write_auxent_fname.isra.0 (str=0x23527e , auxent=auxent@entry=0x7fffe208, 
string_size_p=string_size_p@entry=0x7fffe2d8, abfd=, 
abfd=) at ../../bfd/coffgen.c:856
str_length = 
filnmlen = 
#2  0x77f3806d in coff_write_symbol (abfd=0x55701b20, 
symbol=0x77973780, native=native@entry=0x7fffe1c0, 
written=0x7fffe2d0, string_size_p=0x7fffe2d8, 
debug_string_section_p=debug_string_section_p@entry=0x0, 
debug_string_size_p=0x0) at ../../bfd/coffgen.c:1043
auxesz = 18
j = 
numaux = 1
type = 
n_sclass = 
output_section = 
buf = 0x558abf00
symesz = 
#3  0x77f3834e in coff_write_alien_symbol (abfd=, 
symbol=, isym=0x7fffe310, iaux=0x7fffe2e0, 
written=, string_size_p=, 
debug_string_section_p=0x0, debug_string_size_p=0x0) at ../../bfd/coffgen.c:1154
native = 0x7fffe1c0
dummy = {{offset = 1, fix_value = 0, fix_tag = 0, fix_end = 0, 
fix_scnlen = 0, fix_line = 0, u = {auxent = {x_sym = {x_tagndx = {l = 
435610543662, p = 0x656c69662e}, x_misc = {x_lnsz = {x_lnno = 46240, x_size = 
63456}, x_fsize = 140737352086688}, x_fcnary = {x_fcn = {x_lnnoptr = 
140737350733261, 

Bug#989560: xen-hypervisor-common: generates broken grub configuration on armhf

[Maximilian Engelhardt]

Package: xen-hypervisor-common
Version: 4.14.1+11-gb0b734a8b3-1
Severity: important

Installing xen-system-armhf in a test vm and running update-grub left me with 
a grub configuration that cannot boot the xen hypervisor and gets stuck in the 
grub menu. It's still possible to boot the normal linux kernel after manual 
selection. Grub outputs the following error:


Loading Xen 4.14-armhf ...
error: can't find command `multiboot'.
Loading Linux 5.10.0-7-armmp-lpae ...
error: can't find command `module'.
Loading initial ramdisk ...
error: can't find command `module'.

Press any key to continue...


The problem is that the /etc/grub.d/20_linux_xen file from the grub-common 
package generates a multiboot line for the xen hypervisor but there is no 
multiboot module available for grub on armhf.

I did a bit research but could not come up with a way to boot the xen 
hypervisor from grub on armhf, maybe somebody has more knowledge here.

This may be a bug in 20_linux_xen, but only installing xen-hypervisor-common 
causes a not working grub configuration to be generated, so I'm filing this 
against this package now. Feel free to reassign.

signature.asc
Description: This is a digitally signed message part.

Bug#988901: xen: installing xen-system-amd64 does not always properly update grub configuration

[Maximilian Engelhardt]

Source: xen
Severity: normal
Version: 4.14.1+11-gb0b734a8b3-1

I noticed that installing xen-system-amd64 does not always lead to a grub 
configuration that will boot into the xen hypervisor. As a quick fix 
"update-grub" can be run manually after installation of xen-system-amd64 to 
generate the proper grub configuration.

The issue leading to this is the following:

* xen-system-amd6 depends on xen-hypervisor-4.14-amd64, xen-hypervisor-common 
and xen-utils-4.14.

* xen-hypervisor-4.14-amd64 recommends xen-hypervisor-common and xen-
utils-4.14.

xen-hypervisor-common ships the conffile /etc/default/grub.d/xen.cfg which 
configures grub to boot into the xen hypervisor.

xen-hypervisor-4.14-amd64 has a postinst maintainer script which calls 
"update-grub".

The problem is that because xen-hypervisor-common is only a recommendation of 
xen-hypervisor-4.14-amd64 it may not be configured when the postinst script of 
xen-hypervisor-4.14-amd64 is run and within it update-grub is called.

When xen-hypervisor-common gets installed it first creates the file "/etc/
default/grub.d/xen.cfg.dpkg-new". Only after it gets configured the final file 
will be "/etc/default/grub.d/xen.cfg"

So when the update-grub command gets called the grub configuration file does 
not end in ".cfg" and this is ignored by update-grub.

I see the following possibilities to fix this:

* make xen-hypervisor-common a dependency of xen-hypervisor-4.14-amd64 which 
then should make sure xen-hypervisor-common is configures before the postinst 
script in xen-hypervisor-4.14-amd64 run. Of course this makes it no longer 
possible to install xen-hypervisor-4.14-amd64 without xen-hypervisor-common.

* Additionally run "update-grub" in the postinst maintainer script of xen-
hypervisor-common. This makes sens as the package ships a grub configuration 
file and if something changes there then update-grub should be called.
I also think that if xen-hypervisor-4.14-amd64 is already installed and xen-
hypervisor-common only gets installed later, update-grub currently is never 
run (I didn't verify this) and this change would also fix this.
The only downside I can see is that update-grub will be called twice if xen-
hypervisor-4.14-amd64 and xen-hypervisor-common get installed together.
Maybe this is not really an issue as update-grub usually should be quite fast.

I think the second option seems reasonable, but maybe someone else has a 
better idea how to fix this issue.

Thanks
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#975160: NMU still in DELAYED queue

[Maximilian Engelhardt]

Ping to avoid autoremoval. The NMU from Adrian Bunk should hit the archive 
within one day now.

signature.asc
Description: This is a digitally signed message part.

Bug#975822: patch attached

[Maximilian Engelhardt]

Control: tags -1 + patch

Attached is a simple patch fixing this issue in my local test build.

Adrian Bunk, you marked this bug as pending, are you planning to upload a 
fixed version or has this been a mix up in bug numbers like in your other mail 
in this bug?

Thanks,
Maxidiff -ur pyramid-jinja2-2.7+dfsg/debian/control new/pyramid-jinja2-2.7+dfsg/debian/control
--- pyramid-jinja2-2.7+dfsg/debian/control	2019-09-15 07:04:51.0 +0200
+++ new/pyramid-jinja2-2.7+dfsg/debian/control	2021-02-03 19:50:23.514196939 +0100
@@ -10,6 +10,7 @@
  python3-jinja2,
  python3-zope.deprecation,
  python3-pyramid,
+ python3-webtest,
 Standards-Version: 3.9.8
 Homepage: https://pypi.python.org/pypi/pyramid_jinja2
 X-Python3-Version: >= 3.2


signature.asc
Description: This is a digitally signed message part.

Bug#980310: dh-python: python dependency not generated for private directories

[Maximilian Engelhardt]

Package: dh-python
Version: 4.20201102
Severity: normal
Tags: patch

Hi,

if there are only python files in private directories and they only use a
"/usr/bin/python3" shebang, dh-python does not add any dependencies in
${python3:Depends}, although a dependency to python3 should be added.

I proposed a fix for this issue here:

https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/16

Thanks,
Maxi



-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#976597: A proposed fix, but blocked by a dh-python bug

[Maximilian Engelhardt]

Control: tags -1 + patch
Control: block -1 980303

I implemented a fix for this issue in [1], however this is currently blocked 
due to a bug in dh_python.

[1] 
https://salsa.debian.org/myx/debian-xen/-/commits/myx/fix_python_dependencies

signature.asc
Description: This is a digitally signed message part.

Bug#980303: dh-python: doesn't recognize "python3-dev:any" as a python-dev build dependency

[Maximilian Engelhardt]

Package: dh-python
Version: 4.20201102
Severity: normal
Tags: patch

Hi,

dh-python does not properly handle build dependencies with the ":any" suffix.
This leads to a dependency like "python3-dev:any" not being recognized as a
python-dev build dependency in the python_dev_in_bd variable (file
dhpython/depends.py line 56).

I implemented a simple fix for this issue here:

https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/15

It basically just ignores the ":any" suffix when parsing the build
dependencies.

Thanks,
Maxi



-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-python depends on:
ii  python33.7.3-1
ii  python3-distutils  3.7.3-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev  1.19.7
ii  libdpkg-perl  1.19.7

-- no debconf information


signature.asc
Description: This is a digitally signed message part.

Bug#980253: libsdl1.2debian: unexpected key down release

[Maximilian Engelhardt]

Package: libsdl1.2debian
Version: 1.2.15+dfsg2-4
Severity: important
Tags: patch

Hi,

since some time I noticed a problem within a game (Unreal Tournament 2004)
using libsdl1.2 that the forward movement suddenly stopped, while I still had
the forward key pressed. This is an quite annoying bug when playing the game.
The bug likely also affects many other games using libsdl1.2.

I traced this behavior down to change [1] in the X server. Further analysis
showed that patches solving this issue haven been added to libsdl2. I opened an
upstream bug about backporting these to the SDL-1.2 branch and they have been
quickly accepted in [2].

A cherry-pick of the upstream patch from the SDL-1.2 fixing the issue is
available as merge request here:

https://salsa.debian.org/sdl-team/libsdl1.2/-/merge_requests/2

It would be really great to get this included in bullseye.

Thanks,
Maxi

[1]
https://cgit.freedesktop.org/xorg/xserver/commit/?id=c67f2eac56518163981af59f5accb7c79bc00f6a
[2] https://hg.libsdl.org/SDL/rev/336bcaa9432c



-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#923464: carbon-cache unusable in Buster

[Maximilian Engelhardt]

severity 923464 important
thanks

Hi,

we also ran into this bug and I can confirm the attached patch by Mark fixed 
the issue for us.
This should definitely be fixed in unstable/testing and then also in buster.

I set the severity to important as the repeated crashes of carbon-cache caused 
regular metric data loss on our server as well as oom situations (where was 
not clear what was happening in the beginning) and fast filling up of /var/log 
due to excessive traceback logging.

Thanks,
Maxi

On Sat, 11 Jan 2020 12:05:17 + Mark Hymers  wrote:
> On Thu, 07, Nov, 2019 at 10:57:23AM +0100, Morten Brekkevold spoke thus..
> > The carbon-cache package in Debian Buster is definitely BROKEN - it just
> > keeps crashing.
> 
> Hi,
> 
> We've been running with the attached patch since December which fixes
> the problem.
> 
> Thorsten (as you're the last uploader) - I'm happy to prepare a stable
> update to fix this, but the version is the same in stable/testing so
> can't do so currently.  There are two point release (1.1.5 and 1.1.6)
> for this package but they seem to be tied into other graphite-* package
> updates too.  Would you accept an NMU to unstable with just this patch
> and then an accompanying stable update?  This problem basically makes
> graphite-carbon unusable in buster.
> 
> Thanks.
> 
> Mark
> 
> -- 
> Mark Hymers 


signature.asc
Description: This is a digitally signed message part.

Bug#942308: Maybe duplicate of #930919

[Maximilian Engelhardt]

Could this be the same problem as described in this bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930919

There is also a patch linked that you could try.

signature.asc
Description: This is a digitally signed message part.

Bug#887733: Should this bug be closed?

[Maximilian Engelhardt]

This bug is still open but has been marked as fixed in the versions currently 
in testing/unstable and stable. It also has been fixed in oldstable-security. 
Should it be closed or is there any reason to still keep it open?

signature.asc
Description: This is a digitally signed message part.

Bug#922172: knot 2.7.6 in Buster?

[Maximilian Engelhardt]

Hi Ondřej,

You uploaded knot 2.7.6 to unstable some days ago. I've seen it's currently 
blocked from testing migration by a regression in the knot-resolver package:
https://qa.debian.org/excuses.php?package=knot

This turned out to be due to a change in kdig exit code behavior which needs 
adjustments in the knot-resolver roundtrip test.

I created Debian Bug #922172 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922172
for this issue and also a patch for it. I've seen Daniel Salzman committed a 
similar fix for this to knot-resolver git shortly after.

Do you have any plans to upload a new version of knot-resolver to unstable 
with this fix included? This should allow knot 2.7.6 to migrate to testing in 
time for the full freeze (March 12.).

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#922172: [src:knot-resolver] autopkgtest fails with knot 2.7.6-1

[Maximilian Engelhardt]

Package: src:knot-resolver
Version: 3.2.0-1
Severity: important
Tags: patch
Control: affects -1 knot

I'm nut sure about the correct severity, so I'm filing this as important. Feel 
free to adjust.

With knot   2.7.6-1 (currently in unstable) autopkgtest for knot-resolver 
fails:

https://ci.debian.net/data/autopkgtest/testing/amd64/k/knot-resolver/1912888/log.gz

The problem is a change in behavior of kdig. A patch for the autopkgtest of 
knot-resolver can be found here:

https://salsa.debian.org/dns-team/knot-resolver/merge_requests/1

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#914211: Processed: fixed in 5.54.1-1

[Maximilian Engelhardt]

On Samstag, 19. Januar 2019 08:15:20 CET Pino Toscano wrote:
> In data sabato 19 gennaio 2019 01:12:38 CET, Debian Bug Tracking System ha 
scritto:
> > Processing commands for cont...@bugs.debian.org:
> > > fixed 914211 5.54.1-1
> > 
> > Bug #914211 [src:kio] [src:kio] please remove insecure TLS version
> > fall-back mechanism Marked as fixed in versions kio/5.54.1-1.
> > 
> > > thanks
> > 
> > Stopping processing here.
> 
> Closing the bug then.
> 
> Maximilian, please follow the right procedure for closing bugs:
> https://www.debian.org/Bugs/Developer.en.html#closing
> 
> Thanks,

Hi Pino,

I didn't close the bug because the version in stable is still affected by it. 
I filed my initial report against both versions, stable and testing/unstable at 
that time, because I was told on #debian-devel IRC to do so.
So if this bug is closed how can/should the version in stable be tracked?

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#918479: freecad autopkgtest

[Maximilian Engelhardt]

Hi,

I had a quick look at this bug and notices the upstream parameters for 
launching the test command changed in [1]. Maybe it's enough to adjust the 
commands in 'debian/tests/freecadtest' [2] from

  freecadcmd -t 1
  freecadcmd -t 2

to 

  freecadcmd -t 0

However I currently don't have a proper system to test this, so there might be 
other bugs.

Thanks,
Maxi

[1] https://github.com/FreeCAD/FreeCAD/pull/331
[2] 
https://sources.debian.org/src/freecad/0.17+dfsg1-6/debian/tests/freecadtest/

signature.asc
Description: This is a digitally signed message part.

Bug#915866: [python3-dnspython] crashes on parsing DNS zone file with NSEC3

[Maximilian Engelhardt]

Package: python3-dnspython
Version: 1.15.0-1
Severity: normal
Tags: patch

Hi,

python3-dnspython crashes while parsing my zone files with DNSSEC and NSEC3. 
The zone files are generated by the knot DNS server and I thus believe them to 
be correct and valid.

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dns/zone.py", line 691, in _rr_line
self.current_origin, False) 

  File "/usr/lib/python3/dist-packages/dns/rdata.py", line 428, in from_text  
return cls.from_text(rdclass, rdtype, tok, origin, relativize)
  File "/usr/lib/python3/dist-packages/dns/rdtypes/ANY/NSEC3.py", line 133, in 
from_text
windows.append((window, ''.join(bitmap[0:octets]))) 
TypeError: sequence item 0: expected str instance, int found


I found the problem has been fixed upstream in [1]. Please add the fix to 
Debian. I can confirm that the patch fixes the crash for me. Looking at the 
latest upstream git commits there also seems to be a new release (1.16.0) with 
this fix included in the pipeline.

I also can create a merge request on salsa for this patch if preferred.

[1] 
https://github.com/rthalley/dnspython/commit/fed4e0c5371ed513dbc2d4ad477ce1bd1c940114

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#914211: link to other bug report

[Maximilian Engelhardt]

Please also see the bug report of this issue in libkio5 (src:kde4libs) here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914212

signature.asc
Description: This is a digitally signed message part.

Bug#914212: link to other bug reports

[Maximilian Engelhardt]

Please also see the bug report of this issue in src:kio here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914211

If you consider fixing this in stretch please also have a look at this bug 
report about adding TLSv1.2 support for smtp connections to kde4libs in 
stretch:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891254

signature.asc
Description: This is a digitally signed message part.

Bug#914211: [src:kio] please remove insecure TLS version fall-back mechanism

[Maximilian Engelhardt]

Package: src:kio
Version: 5.49.0-1
Severity: important
Tags: patch
Control: found -1 5.28.0-2

Hi,

Until recently KDE kio had a custom TLS version fall-back mechanism which made 
it possible to downgrade a TLS connection to TLSv1.0 even if the server and 
client support a higher TLS version. This has been fixed upstream in [1], [2] 
and is also included in KDE Frameworks 5.52.0 [3].

Please consider backporting the patch from [2] or shipping a newer KDE 
Frameworks version, so this fix can be included in buster.

Attached you also find a backported version of [2] for the version in stretch. 
Please consider also fixing this in stretch.

[1] https://phabricator.kde.org/D16344
[2] https://cgit.kde.org/kio.git/commit/src/core/tcpslavebase.cpp?
id=e11d4d18f66ad1c6927b058be84e11d46d9de55a
[3] https://www.kde.org/announcements/kde-frameworks-5.52.0.php

Thanks for your work on Debian!
backport https://cgit.kde.org/kio.git/commit/src/core/tcpslavebase.cpp?id=e11d4d18f66ad1c6927b058be84e11d46d9de55a
to stretch.
--- a/src/core/tcpslavebase.cpp
+++ b/src/core/tcpslavebase.cpp
@@ -335,111 +335,51 @@
 }
 }
 
-/*
-   SSL handshake is attempted in the following order:
+const int timeout = (connectTimeout() * 1000); // 20 sec timeout value
 
-   1.) KTcpSocket::SecureProtocols
-   2.) KTcpSocket::TlsV1_2
-   3.) KTcpSocket::TlsV1_1
-   4.) KTcpSocket::TlsV1_0
-
-   Note that we indivially attempt connection with each TLS version
-   because some sites don't support SSL negotiation. #275524
-
-   The version used to successfully make encrypted connection with the
-   remote server is cached within the process to make subsequent
-   connection requests to the same server faster.
- */
-
-const int lastSslVerson = config()->readEntry("LastUsedSslVersion", static_cast(KTcpSocket::SecureProtocols));
-KTcpSocket::SslVersion trySslVersion = static_cast(lastSslVerson);
-KTcpSocket::SslVersions alreadyTriedSslVersions = trySslVersion;
+disconnectFromHost();  //Reset some state, even if we are already disconnected
+d->host = host;
 
-const int timeout = (connectTimeout() * 1000); // 20 sec timeout value
-while (true) {
-disconnectFromHost();  //Reset some state, even if we are already disconnected
-d->host = host;
-
-d->socket.connectToHost(host, port);
-/*const bool connectOk = */d->socket.waitForConnected(timeout > -1 ? timeout : -1);
-
-/*qDebug() << "Socket: state=" << d->socket.state()
-  << ", error=" << d->socket.error()
-  << ", connected?" << connectOk;*/
+d->socket.connectToHost(host, port);
+/*const bool connectOk = */d->socket.waitForConnected(timeout > -1 ? timeout : -1);
 
-if (d->socket.state() != KTcpSocket::ConnectedState) {
-if (errorString) {
-*errorString = host + QLatin1String(": ") + d->socket.errorString();
-}
-switch (d->socket.error()) {
-case KTcpSocket::UnsupportedSocketOperationError:
-return ERR_UNSUPPORTED_ACTION;
-case KTcpSocket::RemoteHostClosedError:
-return ERR_CONNECTION_BROKEN;
-case KTcpSocket::SocketTimeoutError:
-return ERR_SERVER_TIMEOUT;
-case KTcpSocket::HostNotFoundError:
-return ERR_UNKNOWN_HOST;
-default:
-return ERR_CANNOT_CONNECT;
-}
+/*qDebug() << "Socket: state=" << d->socket.state()
+<< ", error=" << d->socket.error()
+<< ", connected?" << connectOk;*/
+
+if (d->socket.state() != KTcpSocket::ConnectedState) {
+if (errorString) {
+*errorString = host + QLatin1String(": ") + d->socket.errorString();
 }
+switch (d->socket.error()) {
+case KTcpSocket::UnsupportedSocketOperationError:
+return ERR_UNSUPPORTED_ACTION;
+case KTcpSocket::RemoteHostClosedError:
+return ERR_CONNECTION_BROKEN;
+case KTcpSocket::SocketTimeoutError:
+return ERR_SERVER_TIMEOUT;
+case KTcpSocket::HostNotFoundError:
+return ERR_UNKNOWN_HOST;
+default:
+return ERR_CANNOT_CONNECT;
+}
+}
 
-//### check for proxyAuthenticationRequiredError
+//### check for proxyAuthenticationRequiredError
 
-d->ip = d->socket.peerAddress().toString();
-d->port = d->socket.peerPort();
+d->ip = d->socket.peerAddress().toString();
+d->port = d->socket.peerPort();
 
-if (d->autoSSL) {
-SslResult res = d->startTLSInternal(trySslVersion, timeout);
-if ((res & ResultFailed) && (res & ResultFailedEarly)) {
-if (!(alreadyTriedSslVersions & KTcpSocket::SecureProtocols)) {
-trySslVersion = KTcpSocket::SecureProtocols;
-alreadyTriedSslVersions |= trySslVersion;
-continue;
-  

Bug#914212: [libkio5] please remove insecure TLS version fall-back mechanism

[Maximilian Engelhardt]

Package: libkio5
Version: 4:4.14.26-2
Severity: important
Tags: patch

Hi,

Until recently KDE kio had a custom TLS version fall-back mechanism which made 
it possible to downgrade a TLS connection to TLSv1.0 even if the server and 
client support a higher TLS version. This has been fixed upstream in [1], [2] 
and is also included in KDE Frameworks 5.52.0 [3].

I backported the patch from [2] for the kio code in kde4libs. Please also 
consider fixing this in stretch.

[1] https://phabricator.kde.org/D16344
[2] 
https://cgit.kde.org/kio.git/commit/src/core/tcpslavebase.cpp?id=e11d4d18f66ad1c6927b058be84e11d46d9de55a
[3] https://www.kde.org/announcements/kde-frameworks-5.52.0.php

Thanks for your work on Debian!backport https://cgit.kde.org/kio.git/commit/src/core/tcpslavebase.cpp?id=e11d4d18f66ad1c6927b058be84e11d46d9de55a
to stretch.
--- a/kio/kio/tcpslavebase.cpp
+++ b/kio/kio/tcpslavebase.cpp
@@ -349,106 +349,50 @@
 }
 }
 
-/*
-  By default the SSL handshake attempt uses these settings in the order shown:
-
-  1.) Protocol: KTcpSocket::SecureProtocols   SSL compression: OFF (DEFAULT)
-  2.) Protocol: KTcpSocket::TlsV1 SSL compression: OFF
-  3.) Protocol: KTcpSocket::SslV3 SSL compression: OFF
-
-  If any combination other than the one marked DEFAULT is used to complete
-  the SSL handshake, then that combination will be cached using KIO's internal
-  meta-data mechanism in order to speed up future connections to the same host.
-*/
-
 QSslConfiguration sslConfig = d->socket.sslConfiguration();
+const int timeout = (connectTimeout() * 1000); // 20 sec timeout value
 
-#if QT_VERSION >= 0x040800
-// NOTE: Due to 'CRIME' SSL attacks, compression is always disabled.
-sslConfig.setSslOption(QSsl::SslOptionDisableCompression, true);
-#endif
-
-const int lastSslVerson = config()->readEntry("LastUsedSslVersion", static_cast(KTcpSocket::SecureProtocols));
-KTcpSocket::SslVersion trySslVersion = static_cast(lastSslVerson);
-KTcpSocket::SslVersions alreadyTriedSslVersions = trySslVersion;
+disconnectFromHost();  //Reset some state, even if we are already disconnected
+d->host = host;
 
-const int timeout = (connectTimeout() * 1000); // 20 sec timeout value
-while (true) {
-disconnectFromHost();  //Reset some state, even if we are already disconnected
-d->host = host;
-
-d->socket.connectToHost(host, port);
-const bool connectOk = d->socket.waitForConnected(timeout > -1 ? timeout : -1);
-
-kDebug(7027) << "Socket: state=" << d->socket.state()
- << ", error=" << d->socket.error()
- << ", connected?" << connectOk;
+d->socket.connectToHost(host, port);
+const bool connectOk = d->socket.waitForConnected(timeout > -1 ? timeout : -1);
 
-if (d->socket.state() != KTcpSocket::ConnectedState) {
-if (errorString)
-*errorString = host + QLatin1String(": ") + d->socket.errorString();
-switch (d->socket.error()) {
-case KTcpSocket::UnsupportedSocketOperationError:
-return ERR_UNSUPPORTED_ACTION;
-case KTcpSocket::RemoteHostClosedError:
-return ERR_CONNECTION_BROKEN;
-case KTcpSocket::SocketTimeoutError:
-return ERR_SERVER_TIMEOUT;
-case KTcpSocket::HostNotFoundError:
-return ERR_UNKNOWN_HOST;
-default:
-return ERR_COULD_NOT_CONNECT;
-}
+kDebug(7027) << "Socket: state=" << d->socket.state()
+ << ", error=" << d->socket.error()
+ << ", connected?" << connectOk;
+
+if (d->socket.state() != KTcpSocket::ConnectedState) {
+if (errorString)
+*errorString = host + QLatin1String(": ") + d->socket.errorString();
+switch (d->socket.error()) {
+case KTcpSocket::UnsupportedSocketOperationError:
+return ERR_UNSUPPORTED_ACTION;
+case KTcpSocket::RemoteHostClosedError:
+return ERR_CONNECTION_BROKEN;
+case KTcpSocket::SocketTimeoutError:
+return ERR_SERVER_TIMEOUT;
+case KTcpSocket::HostNotFoundError:
+return ERR_UNKNOWN_HOST;
+default:
+return ERR_COULD_NOT_CONNECT;
 }
+}
 
-//### check for proxyAuthenticationRequiredError
+//### check for proxyAuthenticationRequiredError
 
-d->ip = d->socket.peerAddress().toString();
-d->port = d->socket.peerPort();
+d->ip = d->socket.peerAddress().toString();
+d->port = d->socket.peerPort();
 
-if (d->autoSSL) {
-SslResult res = d->startTLSInternal(trySslVersion, sslConfig, timeout);
-if ((res & ResultFailed) && (res & ResultFailedEarly)) {
-if (!(alreadyTriedSslVersions & KTcpSocket::SecureProtocols)) {
-trySslVersion = 

Bug#911457: [src:xen] please add Homepage and Version Control System fields to debian/control

[Maximilian Engelhardt]

Package: src:xen
Version: 4.11.1~pre.20180911.5acdd26fdc+dfsg-5
Severity: wishlist

Hi,

please consider adding Homepage, Vcs-Browser and Vcs-Git fields in debian/
control so they will show up in tracker (and probably other places too).

Something like this should work:

Homepage: https://xenproject.org/
Vcs-Browser: https://salsa.debian.org/xen-team/debian-xen
Vcs-Git: https://salsa.debian.org/xen-team/debian-xen.git

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#910680: [tucnak] New upstream version available

[Maximilian Engelhardt]

Package: tucnak
Version: 4.09-1
Severity: wishlist

Tucnak version 4.14 has been released upstream at 07.07.2018. The version 4.09 
currently in unstable has been released over one and a half years ago. It 
would be great to have a more modern version in unstable (and in the next 
Debian release).







signature.asc
Description: This is a digitally signed message part.

Bug#851560: dhcpcd5: update to new upstream version

[Maximilian Engelhardt]

The latest version of dhcpcd is currently 7.0.7:

https://roy.marples.name/archives/dhcpcd-discuss/0002151.html

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#891253: Related bugs

[Maximilian Engelhardt]

Please also see the related bugs for smtp
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891254
and imap
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891255

signature.asc
Description: This is a digitally signed message part.

Bug#891254: Related bugs

[Maximilian Engelhardt]

Please also see the related bugs for sieve
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891253
and imap
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891255

signature.asc
Description: This is a digitally signed message part.

Bug#891255: Related bugs

[Maximilian Engelhardt]

Please also see the related bugs for sieve
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891253
and smtp
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891254

signature.asc
Description: This is a digitally signed message part.

Bug#891254: [src:kde4libs] Please enable TLSv1.2 for smtp connections in stretch

[Maximilian Engelhardt]

Package: src:kde4libs
Version: 4:4.14.26-2
Severity: important
Tags: patch, stretch

--- Please enter the report below this line. ---

kmail in stretch only supports TLSv1.0 which hinders it to connect to mail 
servers that only support TLSv1.2 or TLSv.1.1.

The attached patch is a backport of the upstream fix from here:
https://bugs.kde.org/show_bug.cgi?id=342567
https://git.reviewboard.kde.org/r/129031/

It is necessary for smtp connections.

I primary reported the patches here 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797844#33
but was told on irc to file separate bug reports.

I tested this patch for some weeks on my system without any issues.
Pleas let me know if you have any questions.

Thank you for maintaining KDE packages in Debian!

--- System information. ---
Architecture: 
Kernel:   Linux 4.9.0-6-amd64

Debian Release: 9.3
  500 stable-updates  deb.debian.org 
  500 stable  deb.debian.org 
  100 stretch-backports deb.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.



--- a/kio/kio/tcpslavebase.cpp
+++ b/kio/kio/tcpslavebase.cpp
@@ -499,7 +499,7 @@
 {
 if (d->usingSSL)
 return false;
-return d->startTLSInternal(KTcpSocket::TlsV1) & ResultOk;
+return d->startTLSInternal(KTcpSocket::SecureProtocols) & ResultOk;
 }
 
 TCPSlaveBase::SslResult TCPSlaveBase::TcpSlaveBasePrivate::startTLSInternal (KTcpSocket::SslVersion version,


signature.asc
Description: This is a digitally signed message part.

Bug#891253: [src:libkf5ksieve] Please enable TLSv1.2 for sieve connections in stretch

[Maximilian Engelhardt]

Package: src:libkf5ksieve
Version: 4:16.04.3-2
Severity: important
Tags: patch, stretch

--- Please enter the report below this line. ---

kmail in stretch only supports TLSv1.0 which hinders it to connect to mail 
servers that only support TLSv1.2 or TLSv.1.1.

The attached patch is a backport of the upstream fix from here:
https://bugs.kde.org/show_bug.cgi?id=342567
https://git.reviewboard.kde.org/r/129029/

It is necessary for sieve connections.

I primary reported the patches here 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797844#33
but was told on irc to file separate bug reports.

I tested this patch for some weeks on my system without any issues.
Pleas let me know if you have any questions.

Thank you for maintaining KDE packages in Debian!

--- System information. ---
Architecture: 
Kernel:   Linux 4.9.0-6-amd64

Debian Release: 9.3
  500 stable-updates  deb.debian.org 
  500 stable  deb.debian.org 
  100 stretch-backports deb.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.



--- a/src/kmanagesieve/sessionthread.cpp
+++ b/src/kmanagesieve/sessionthread.cpp
@@ -453,7 +453,7 @@
 m_sslCheck->setInterval(60 * 1000);
 connect(m_sslCheck, ::timeout, this, ::slotSslTimeout);
 }
-m_socket->setAdvertisedSslVersion(KTcpSocket::TlsV1);
+m_socket->setAdvertisedSslVersion(KTcpSocket::SecureProtocols);
 m_socket->ignoreSslErrors();
 connect(m_socket, ::encrypted, this, ::slotEncryptedDone);
 m_sslCheck->start();


signature.asc
Description: This is a digitally signed message part.

Bug#891255: [src:kimap] Please enable TLSv1.2 for imap connections in stretch

[Maximilian Engelhardt]

Package: src:kimap
Version: 16.04.2-1
Severity: important
Tags: patch, stretch

--- Please enter the report below this line. ---

kmail in stretch only supports TLSv1.0 which hinders it to connect to mail 
servers that only support TLSv1.2 or TLSv.1.1.

The attached patch is a backport of the upstream fix from here:
https://bugs.kde.org/show_bug.cgi?id=342567
https://git.reviewboard.kde.org/r/129030/

It is necessary for imap connections.

I primary reported the patches here 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797844#33
but was told on irc to file separate bug reports.

I tested this patch for some weeks on my system without any issues.
Pleas let me know if you have any questions.

Thank you for maintaining KDE packages in Debian!

--- System information. ---
Architecture: 
Kernel:   Linux 4.9.0-6-amd64

Debian Release: 9.3
  500 stable-updates  deb.debian.org 
  500 stable  deb.debian.org 
  100 stretch-backports deb.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-==
kio | 5.28.0-2
libc6 (>= 2.14) | 
libgcc1  (>= 1:3.0) | 
libkf5codecs5   (>= 4.96.0) | 
libkf5coreaddons5   (>= 4.97.0) | 
libkf5i18n5 (>= 4.97.0) | 
libkf5kiocore5  (>= 4.96.0) | 
libkf5mime5   (>= 15.07.90) | 
libqt5core5a (>= 5.7.0) | 
libsasl2-2  | 
libstdc++6   (>= 4.1.1) | 


Package's Recommends field is empty.

Package's Suggests field is empty.



--- a/src/loginjob.cpp
+++ b/src/loginjob.cpp
@@ -383,7 +383,7 @@
 
 switch (d->authState) {
 case LoginJobPrivate::StartTls:
-d->sessionInternal()->startSsl(KTcpSocket::TlsV1);
+d->sessionInternal()->startSsl(KTcpSocket::SecureProtocols);
 break;
 
 case LoginJobPrivate::Capability:


signature.asc
Description: This is a digitally signed message part.

Bug#797844: kmail: TLSv1.1 and TLSv1.2 are not supported

[Maximilian Engelhardt]

tag 797844 + patch
thanks

Hi,

I recently ran into this bug when my mail server switched to TLS 1.2 only.

I backported the upstream changes to the Debian stretch packages and are 
running them now without problems.

The patches are are attached to this mail. Affect source packages are kimap, 
libkf5ksieve and kde4libs.

As the patches are fairly trivial can this be applied to Debian stable? If I 
remember correctly severity important classifies for fixing in stable.

Pleas let me know if you have any questions.

Thank you for maintaining KDE packages in Debian!--- a/kio/kio/tcpslavebase.cpp
+++ b/kio/kio/tcpslavebase.cpp
@@ -499,7 +499,7 @@
 {
 if (d->usingSSL)
 return false;
-return d->startTLSInternal(KTcpSocket::TlsV1) & ResultOk;
+return d->startTLSInternal(KTcpSocket::SecureProtocols) & ResultOk;
 }
 
 TCPSlaveBase::SslResult TCPSlaveBase::TcpSlaveBasePrivate::startTLSInternal (KTcpSocket::SslVersion version,
--- a/src/loginjob.cpp
+++ b/src/loginjob.cpp
@@ -383,7 +383,7 @@
 
 switch (d->authState) {
 case LoginJobPrivate::StartTls:
-d->sessionInternal()->startSsl(KTcpSocket::TlsV1);
+d->sessionInternal()->startSsl(KTcpSocket::SecureProtocols);
 break;
 
 case LoginJobPrivate::Capability:
--- a/src/kmanagesieve/sessionthread.cpp
+++ b/src/kmanagesieve/sessionthread.cpp
@@ -453,7 +453,7 @@
 m_sslCheck->setInterval(60 * 1000);
 connect(m_sslCheck, ::timeout, this, ::slotSslTimeout);
 }
-m_socket->setAdvertisedSslVersion(KTcpSocket::TlsV1);
+m_socket->setAdvertisedSslVersion(KTcpSocket::SecureProtocols);
 m_socket->ignoreSslErrors();
 connect(m_socket, ::encrypted, this, ::slotEncryptedDone);
 m_sslCheck->start();


signature.asc
Description: This is a digitally signed message part.

Bug#859560: fixed in xen 4.8.1-1

[Maximilian Engelhardt]

On Dienstag, 25. April 2017 00:08:20 CEST Ivar Smolin wrote:
> On Tue, 18 Apr 2017 17:34:15 + Ian Jackson
> 
>  wrote:
> > Source: xen
> > Source-Version: 4.8.1-1
> > 
> > We believe that the bug you reported is fixed in the latest version of
> > xen, which is due to be installed in the Debian FTP archive.
> 
> Thanks for fixing!
> 
> This bug affects also Xen 4.4.x, Jessie is still vulnerable.


Hi, what's the status of this in Jessie?

According to https://security-tracker.debian.org/tracker/CVE-2017-7228 Jessie 
is still vulnerable.

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#850620: [Pkg-utopia-maintainers] Bug#850620: [network-manager] does not update lifetime of temporary ipv6 addresses anymore, resulting in connection breakage

[Maximilian Engelhardt]

On Sonntag, 8. Januar 2017 17:34:09 CET Michael Biebl wrote:
> Hi
> 
> Am 08.01.2017 um 16:48 schrieb Maximilian Engelhardt:
> > Package: network-manager
> > Version: 1.4.4-1
> > Severity: important
> > 
> > --- Please enter the report below this line. ---
> > 
> > After updating to network-manger 1.4.4-1 I noticed a lot of breakages in
> > ssh connections.  It turned out this is related to temporary ipv6
> > addresses being deprecated, deleted and newly created at a rapid rate,
> > thus after a short time the address used by my ssh connection vanishes.
> > 
> > Having a closer look with "ip addr show" explained what is going on. My
> > router advertisements have a short lifetime configured. A new router
> > advertisement does only update the lifetime of the mngtmpaddr but not the
> > temporary addresses. This causes them to time out and permanently being
> > deleted and newly created.
> > 
> > Disabling network-manager doesn't show this problem. Also downgrading
> > network- manager to version 1.4.2-3 fixes this issue for me.
> 
> This doesn't look like a downstream specific issue, so it would be great
> if you can file this upstream at
> https://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager
> 
> You might check if it has already been reported at
> https://bugzilla.gnome.org/page.cgi?id=browse.html=NetworkManager
> 
> Once you have an upstream bug number, please report back so we can mark
> this bug accordingly.
> 
> Regards,
> Michael

I can confirm this is fixed by the upstream patch.

It would be great to get this fixed for stretch. In my test I just had to 
backport the upstream fix.

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#850620: [network-manager] does not update lifetime of temporary ipv6 addresses anymore, resulting in connection breakage

[Maximilian Engelhardt]

Package: network-manager
Version: 1.4.4-1
Severity: important

--- Please enter the report below this line. ---

After updating to network-manger 1.4.4-1 I noticed a lot of breakages in ssh 
connections.  It turned out this is related to temporary ipv6 addresses being 
deprecated, deleted and newly created at a rapid rate, thus after a short time 
the address used by my ssh connection vanishes.

Having a closer look with "ip addr show" explained what is going on. My router 
advertisements have a short lifetime configured. A new router advertisement 
does only update the lifetime of the mngtmpaddr but not the temporary 
addresses. This causes them to time out and permanently being deleted and 
newly created.

Disabling network-manager doesn't show this problem. Also downgrading network-
manager to version 1.4.2-3 fixes this issue for me.

This bugs breaks all ipv6 network connections that are active longer than a 
few minutes for me.

Thanks,
Maxi

--- System information. ---
Architecture: 
Kernel:   Linux 4.8.0-2-amd64

Debian Release: stretch/sid
  500 testing httpredir.debian.org 
  500 stable  security.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-=
libaudit1 (>= 1:2.2.1) | 1:2.6.7-1
libbluetooth3(>= 4.91) | 5.43-1
libc6(>= 2.17) | 
libglib2.0-0   (>= 2.43.2) | 
libgnutls30 (>= 3.5.0) | 
libgudev-1.0-0(>= 165) | 
libmm-glib0 (>= 1.0.0) | 
libndp0   (>= 1.2) | 
libnewt0.52| 
libnl-3-200(>= 3.2.21) | 
libnm0  (>= 1.4.0) | 
libpolkit-agent-1-0  (>= 0.99) | 
libpolkit-gobject-1-0   (>= 0.104) | 
libreadline7  (>= 6.0) | 
libselinux1  (>= 1.32) | 
libsoup2.4-1 (>= 2.40) | 
libsystemd0   (>= 209) | 
libteamdctl0  (>= 1.9) | 
libuuid1 (>= 2.16) | 
init-system-helpers (>= 1.18~) | 
lsb-base   (>= 3.2-14) | 
wpasupplicant (>= 0.7.3-1) | 
dbus(>= 1.1.2) | 
udev   | 
adduser| 
libpam-systemd | 
policykit-1| 


Recommends(Version) | Installed
===-+-
ppp | 2.4.7-1+4
dnsmasq-base| 2.76-5
iptables| 1.6.0+snapshot20161117-4
modemmanager| 
crda| 3.13-1+b2
isc-dhcp-client (>= 4.1.1-P1-4) | 4.3.5-1
iputils-arping  | 3:20161105-1


Suggests   (Version) | Installed
-+-===
libteam-utils| 






signature.asc
Description: This is a digitally signed message part.

Bug#850462: [src:libkf5ksieve] managing sieve scripts in kmail stops working after some time

[Maximilian Engelhardt]

Package: src:libkf5ksieve
Version: 4:16.04.3-1
Severity: normal

--- Please enter the report below this line. ---
Hello,

After a fresh start of kmail managing sieve scripts does work as expected. 
After some time it doesn't work any more. Opening Settings -> Manage Sieve 
Scripts... only shows a never ending spinning wheel and is not loading the 
available scripts. Restarting kmail temporary fixed this.

I've seen upstream has some fixes for sieve connection management and 
backporting the following commits does indeed fix this:

https://cgit.kde.org/libksieve.git/commit/?
id=8fb821950bd8caae0c4a86e1d2ecb4caabab1689
https://cgit.kde.org/libksieve.git/commit/?
id=ee4afdd78597cb9379a39951b9eca94a8e927f98
https://cgit.kde.org/libksieve.git/commit/?
id=6862737561a9ee5fadcd78bd0655d0b45c893534
https://cgit.kde.org/libksieve.git/commit/?
id=9bbf8a1dd9f3683000228773eef5dbeb12e0d008
https://cgit.kde.org/libksieve.git/commit/?
id=3176d1cdf6e36429ac9c6b4ee79b37c22b4273c9

I didn't have a closer look if all of the patches are needed, but applying 
them all solved the problem for me.
All of these are included in 16.08.0 but not in 16.04.3.

It would be nice to get this fixed for streatch. 

Thanks,
Maxi

--- System information. ---
Architecture: 
Kernel:   Linux 4.8.0-2-amd64

Debian Release: stretch/sid
  500 testing httpredir.debian.org 
  500 stable  security.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.





signature.asc
Description: This is a digitally signed message part.

Bug#849326: amarok: deleting/renaming errmsg.sys solves the problem

[Maximilian Engelhardt]

On Donnerstag, 5. Januar 2017 19:39:52 CET Maria wrote:
> Dear Maintainer,
> 
> deleting or renaming /usr/share/kde4/apps/amarok/mysqle/errmsg.sys to
> errmsg.sys.old solves the problem!
> 
> Thanks - Maria

Hi,

Unfortunate this doesn't work for me because amarok then uses the errmsg.sys 
from the mariadb-server-core-10.0 package:
/usr/share/mysql/english/errmsg.sys
You probably don't have this installed, but on my system akonadi-backend-mysql 
depends on it.

However I was able to fix this by compiling amarok against mariadb-server-
core-10.1 instead of default-mysql-server-core.

According to Bug #850147 this change is planned in the near future. A rebuild 
of amarok then should fix this.
Pleas keep in mind you also need my patch from Bug #849598 to compile amarok 
at all.

Here is the patch I used for testing this:

diff -ur debian.buildfix/control debian/control
--- debian.buildfix/control 2017-01-06 16:21:18.0 +0100
+++ debian/control  2017-01-06 16:55:33.0 +0100
@@ -18,7 +18,7 @@
  libavformat-dev (>= 4:0.5), libofa0-dev, libaio-dev [linux-any],
  libgcrypt20-dev,
  libmygpo-qt-dev (>= 1.0.9-2~),
-Build-Depends-Indep: default-mysql-server-core | virtual-mysql-server-core
+Build-Depends-Indep: mariadb-server-core-10.1 | virtual-mysql-server-core
 Standards-Version: 3.9.8
 Homepage: http://amarok.kde.org
 Vcs-Git: https://anonscm.debian.org/git/pkg-kde/kde-extras/amarok.git

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#849598: [Pkg-kde-extras] Bug#849598: amarok: FTBFS (cannot find -lmysqlclient)

[Maximilian Engelhardt]

This is fixed by adding libmariadbclient-dev-compat to the build dependencies. 
I'm not sure why this is needed now.

diff -ur debian.orig/control debian/control
--- debian.orig/control 2016-12-23 16:05:31.0 +0100
+++ debian/control  2017-01-06 16:21:18.0 +0100
@@ -11,7 +11,7 @@
  kdelibs5-dev (>= 4:4.8.4),
  libmtp-dev (>= 1.0.0), libqjson-dev,
  libglib2.0-dev, libgpod-nogtk-dev (>= 0.7.0) | libgpod-dev (>= 0.7.0),
- libmariadbd-dev,
+ libmariadbd-dev, libmariadbclient-dev-compat,
  libwrap0-dev,
  libcurl4-gnutls-dev, libxml2-dev, libloudmouth1-dev,
  libgtk2.0-dev, libqca2-dev, liblastfm-dev (>= 1.0.3),


signature.asc
Description: This is a digitally signed message part.

Bug#845798: patch for amarok

[Maximilian Engelhardt]

Hi,

I created a patch for amarok that switches to using mariadb. I don't see how 
the current mysql-defaults system can be used in amarok, as there is no 
default-mysqld-dev package.

$ diff -u debian.orig/amarok-2.8.0/debian/control 
debian/amarok-2.8.0/debian/control
--- debian.orig/amarok-2.8.0/debian/control 2016-12-01 20:16:40.0 
+0100
+++ debian/amarok-2.8.0/debian/control  2016-12-15 20:26:31.791265529 +0100
@@ -11,12 +11,12 @@
  kdelibs5-dev (>= 4:4.8.4),
  libmtp-dev (>= 1.0.0), libqjson-dev,
  libglib2.0-dev, libgpod-nogtk-dev (>= 0.7.0) | libgpod-dev (>= 0.7.0),
- libmysqld-pic (>= 5.5.23+dfsg), libwrap0-dev,
+ libmariadbd-dev, libwrap0-dev,
  libcurl4-gnutls-dev, libxml2-dev, libloudmouth1-dev,
  libgtk2.0-dev, libqca2-dev, liblastfm-dev (>= 1.0.3),
  libavformat-dev (>= 4:0.5), libofa0-dev, libaio-dev [linux-any],
  libgcrypt20-dev
-Build-Depends-Indep: mysql-server-core-5.6 | virtual-mysql-server-core
+Build-Depends-Indep: mariadb-server-core-10.0 | virtual-mysql-server-core
 Standards-Version: 3.9.8
 Homepage: http://amarok.kde.org
 Vcs-Git: https://anonscm.debian.org/git/pkg-kde/kde-extras/amarok.git

I compile tested the patch in pbuilder and tested the resulting .debs on my 
system.

It would be great If this could get reviewed and if acceptable uploaded to 
unstable so we can get an amarok in stretch.

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#830288: status of updated wireless-regdb

[Maximilian Engelhardt]

Hi,

I just wanted to ask about the status of this. Are there any problems beside 
missing resources for packaging?

It would be good to have an updated wireless-regdb for stretch.

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#843534: workaround

[Maximilian Engelhardt]

I ran into this bug today. For me this is really a grave bug as is completely 
broke my mail setup.

I found two ways how I could work around this bug:

(A) install mysql-server and purge it again.
(B) execute the following commands as root:
   # mkdir -m700 /var/lib/mysql-files
   # chown mysql:mysql /var/lib/mysql-files

purging mysql-server leaves this directory existent, this is why (A) also 
worked.

Probably the /var/lib/mysql-files directory should be created by some other 
package or the dependencies my need to be adjusted.

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#841458: [src:libkf5ksieve] managing sieve scripts broken in kmail

[Maximilian Engelhardt]

Package: src:libkf5ksieve
Version: 4:16.04.2-2
Severity: important
Tags: patch

--- Please enter the report below this line. ---
Hi,

Managing sieve scripts from kmail is currently broken.  When trying to edit 
the rules I get this error:

Sieve operation failed.
The server responded:
require "fileinto";

This has been reported upstream here:
https://bugs.kde.org/show_bug.cgi?id=364394

Which seems to be caused by a broken fix of
https://bugs.kde.org/show_bug.cgi?id=328246

Cherry-picking upstream commit abc329d2b4d3a8efb489b0aa8dfb9cc2d2da9472 [1] 
(which reverts commit aa295b6cf15ee67a980b2858ccad6e6e8e769585 [2]) does 
indeed fix the problem.

So it would be great if ether a new upstream version with this fix included 
could be uploaded or if the fix can be backported to the current version.

[1] 
https://quickgit.kde.org/?p=libksieve.git=commit=abc329d2b4d3a8efb489b0aa8dfb9cc2d2da9472
[2] 
https://quickgit.kde.org/?p=libksieve.git=commit=aa295b6cf15ee67a980b2858ccad6e6e8e769585

Thanks,
Maxi


--- System information. ---
Architecture: amd64
Kernel:   Linux 4.7.0-1-amd64

Debian Release: stretch/sid
  500 testing httpredir.debian.org 
  500 stable  security.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-
libkf5ksieve-data(= 4:16.04.2-2) | 4:16.04.2-2
libc6  (>= 2.14) | 
libkf5i18n5  (>= 4.97.0) | 
libkf5kiocore5   (>= 4.96.0) | 
libkf5kiowidgets5(>= 4.96.0) | 
libkf5widgetsaddons5 (>= 4.96.0) | 
libqt5core5a (>= 5.6.0~beta) | 
libqt5network5   (>= 5.4.0~) | 
libqt5widgets5   (>= 5.4.0~) | 
libsasl2-2   | 
libstdc++6(>= 4.1.1) | 


Package's Recommends field is empty.

Package's Suggests field is empty.


signature.asc
Description: This is a digitally signed message part.

Bug#779495: upstream avr-libc-2.0.0 available

[Maximilian Engelhardt]

Hi,

in the meantime avr-libc-2.0.0 has been released upstream. I don't know if 
this helps with the issues you mentioned but maybe it's worth having a look.

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#752446: wsjtx: Upstream v1.3 is available

[Maximilian Engelhardt]

Any news on this?

Currently Version 1.6.0 is available.

signature.asc
Description: This is a digitally signed message part.

Bug#714836: Any news on the qucs package?

[Maximilian Engelhardt]

It seems there has been some upstream progress with the issues. Also upstream 
seems to have at least some interest in a Debian package.
See this mailing list post from march this year:
https://sourceforge.net/p/qucs/mailman/message/34967589/

signature.asc
Description: This is a digitally signed message part.

Bug#822817: [src:linux] sound stops working and dmesg spammed with hpet1: lost XXX rtc interrupts

[Maximilian Engelhardt]

Hi Dietz,

Thanks for your information. In my case I need the irqpoll option because of 
this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=47191

However, setting the "hpet=disable" option additionally seems to work well for 
me.

Does anyone know if this can have any negative implications?

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#822817: bug still present in 4.6

[Maximilian Engelhardt]

Hi,

This bug is still present for me in Linux 4.6 from experimental.

However I found that booting with "hpet=disable" results in a usable system 
again.

Is this something I should report upstream?

Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#821033: [avrdude] new upstream version (6.3) available

[Maximilian Engelhardt]

Package: avrdude
Version: 6.2-5
Severity: wishlist

--- Please enter the report below this line. ---

Hi,

A new upstream version of avrdude is available:

"AVRDUDE 6.3 released" 
https://savannah.nongnu.org/forum/forum.php?forum_id=8461

Please consider packaging it in Debian.

Thanks,
Maxi

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.4.0-1-amd64

Debian Release: stretch/sid
  500 testing security.debian.org 
  500 testing httpredir.debian.org 
  500 stable  security.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-==
libc6(>= 2.15) | 
libelf1 (>= 0.142) | 
libftdi1 (>= 0.20) | 
libncurses5(>= 5.5-5~) | 
libreadline6  (>= 6.0) | 
libtinfo5  | 
libusb-0.1-4 (>= 2:0.1.12) | 


Package's Recommends field is empty.

Suggests (Version) | Installed
==-+-===
avrdude-doc| 




signature.asc
Description: This is a digitally signed message part.

Bug#786772: [dhcpcd5] please package a newer version

[Maximilian Engelhardt]

Package: dhcpcd5
Version: 6.0.5-2
Severity: wishlist

--- Please enter the report below this line. ---

A new upstream version (currently 6.9.0) is available with many bug fixes, 
improvements and features. The version currently in Debian (6.0.5, upstream 
release Aug 2013) is quite old and for me has problems with IPv6 support. It 
would be nice if Debian could ship a more recent version.

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.0.0-1-amd64

Debian Release: stretch/sid
  500 testing security.debian.org 
  500 testing httpredir.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.




signature.asc
Description: This is a digitally signed message part.

Bug#786774: [xul-ext-https-everywhere] a newer upstream version is available

[Maximilian Engelhardt]

Package: xul-ext-https-everywhere
Version: 4.0.3-1
Severity: wishlist

--- Please enter the report below this line. ---

Upstream currently ships version 5.0.4 while Debian still has 4.0.3. It 
probably makes sens to update to the latest upstream version.

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.0.0-1-amd64

Debian Release: stretch/sid
  500 testing security.debian.org 
  500 testing httpredir.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-=
iceweasel (= 20)  | 38.0.1-1
 OR icedove   (= 17.0.5)  | 
 OR iceape  (= 2.17)  | 
 OR conkeror   | 


Package's Recommends field is empty.

Package's Suggests field is empty.




signature.asc
Description: This is a digitally signed message part.

Bug#785153: [src:linux] Please enable support for DVBSky T9580

[Maximilian Engelhardt]

Package: src:linux
Version: 4.0.2-1
Severity: wishlist

--- Please enter the report below this line. ---

Please set CONFIG_DVB_SMIPCIE=m to enable support for the DVBSky T9580 card. I 
did a test build with this option enabled on linux-image-3.19 and the card did 
work without problems.

Regards,
Maxi


--- System information. ---
Architecture: amd64
Kernel:   Linux 4.0.0-1-amd64

Debian Release: stretch/sid
  500 testing security.debian.org 
  500 testing httpredir.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.



signature.asc
Description: This is a digitally signed message part.

Bug#770659: WebRTC in chromium

[Maximilian Engelhardt]

The handling of this bug is really bad, nobody seems to care about it and it's 
broken now a long time.

I see two possible solutions for this issue. Either WebRTC in chromium should 
be fixed or it should be disabled in the Debian version of chromium. It simply 
doesn't make any sens to ship a chromium version with WebRTC enabled when it 
clearly doesn't work. This will just annoy users.

Of course the preferred way is to to fix the issue. I have proposed a patch in 
[1] by using the libsrtp shipped with chromium sources. I did verify this 
still works in chromium-41.
The other solution would be to find out what's broken with using the system 
(Debian) version of libsrtp and get a fix for this. My guess it that it has to 
do with the chromium sandbox and it's separation. I don't have the time and 
knowledge to debug this any further, so more debugging on this has to be done 
by someone else.

Luckily multistream support for WebRTC is arriving in Firefox, so hopefully 
soon I won't need chromium anymore.

Regards,
Maxi

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

signature.asc
Description: This is a digitally signed message part.

Bug#770659: Workaround to get WebRTC working again

[Maximilian Engelhardt]

Package: chromium
Version: 40.0.2214.91-1

I had another look at this today and noticed that it seems to be related to 
the chromium sandbox and the external libsrtp.

I found that a workaround to get WebRTC running on Debian is disabling the 
sandbox:

$ chromium --no-sandbox

With this parameter WebRTC does work again for me.


signature.asc
Description: This is a digitally signed message part.

Bug#775005: [macchanger] MAC randomization doesn't generate a random MAC

[Maximilian Engelhardt]

Package: macchanger
Version: 1.7.0-3.2
Severity: grave

Trying to randomize the MAC address of an interface toggles between two MAC 
addresses instead of setting a random MAC address. See the following example:

$ macchanger -A wlan8
Current MAC:   00:05:01:98:56:c3 (CISCO SYSTEMS, INC.)
Permanent MAC: 24:fd:52:XX:XX:XX (Liteon Technology Corporation)
New MAC:   00:05:01:98:26:05 (CISCO SYSTEMS, INC.)
$ macchanger -A wlan8
Current MAC:   00:05:01:98:26:05 (CISCO SYSTEMS, INC.)
Permanent MAC: 24:fd:52:XX:XX:XX (Liteon Technology Corporation)
New MAC:   00:05:01:98:56:c3 (CISCO SYSTEMS, INC.)
$ macchanger -A wlan8
Current MAC:   00:05:01:98:56:c3 (CISCO SYSTEMS, INC.)
Permanent MAC: 24:fd:52:XX:XX:XX (Liteon Technology Corporation)
New MAC:   00:05:01:98:26:05 (CISCO SYSTEMS, INC.)
$ macchanger -A wlan8
Current MAC:   00:05:01:98:26:05 (CISCO SYSTEMS, INC.)
Permanent MAC: 24:fd:52:XX:XX:XX (Liteon Technology Corporation)
New MAC:   00:05:01:98:56:c3 (CISCO SYSTEMS, INC.)


The problem here seems to be in the random_seed function where macchanger 
tries to open different devices for random numbers and takes the first one 
where open() is successful but never checks if the following read() is 
successful.

http://sources.debian.net/src/macchanger/1.7.0-5/src/main.c/#L92

also see this strace snippet:

open(/dev/hwrng, O_RDONLY)= 3
read(3, 0x7fffe23909ec, 4)  = -1 ENODEV (No such device)
close(3)= 0


I don't know why I do have this non-working /dev/hwrng device. It gets somehow 
automatically created by loading the b43 kernel module.

Macchanger should check if the read() was successful and if not try the next 
entropy device or at least abort with an error instead pretending to set a 
random MAC address which clearly is not random.


Another problem I spotted is that if reading from an entropy device does work 
only sizeof(unsigned int) entropy is read, which is only guaranteed to be 2 
octets. However from these are then up to 6 octets of random data generated 
(in case of a fully random MAC) which clearly does not work as expected.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.18.0-trunk-amd64

Debian Release: 8.0
  500 testing security.debian.org 
  500 testing mirror.stusta.mhn.de 
  500 testing http.debian.net 

--- Package information. ---
Depends (Version) | Installed
=-+-=
libc6(= 2.4) | 
dpkg (= 1.15.4)  | 
 OR install-info  | 


Package's Recommends field is empty.

Package's Suggests field is empty.

signature.asc
Description: This is a digitally signed message part.

Bug#770659: seems to be related to using the Debian srtp library

[Maximilian Engelhardt]

I did some tests to track this down a bit.

starting chromium with --enable-logging --v=4 I do get this in my 
.config/chromium/chrome_debug.log:

[49:62:1219/210401:VERBOSE3:channel.cc(783)] Installing keys from DTLS-SRTP on 
audio RTP
[49:62:1219/210401:VERBOSE1:srtpfilter.cc(699)] Failed to init SRTP, err=5
[49:62:1219/210401:VERBOSE2:channel.cc(853)] DTLS-SRTP key installation failed


So the problem seems to be somewhere in or related to srtp. I had a quick look 
at the corresponding code, but I'm not sure what is the problem there. The 
error message from my log comes from here:

http://sources.debian.net/src/chromium-browser/39.0.2171.71-2/third_party/libjingle/source/talk/session/media/srtpfilter.cc/#L699

and is the return value of the srtp_init() function from the srtp source here:

http://sources.debian.net/src/srtp/1.4.5~20130609~dfsg-1.1/srtp/srtp.c/#L1235

The functions crypto_kernel_init() and crypto_kernel_load_debug_module() can 
be found here:

http://sources.debian.net/src/srtp/1.4.5~20130609~dfsg-1.1/crypto/kernel/crypto_kernel.c/


I couldn't see any obvious problem there but I only had a very rough look at 
the code.

So suspecting this might be caused by the system srtp library I disabled it by 
removing use_system_libsrtp=1 from the debian/rules file and got a chromium 
with working webrtc.


At the moment I have no idea where the real problem is or how it should be 
fixed, this is just what I found out so far. It might also be the case that 
it's not chromium or srtp's fault but the real cause of this problem is 
somewhere else. Probably someone with more knowledge on all this should have a 
look at it.


Some things I also noticed that might be of interest. I did a build of 
chromium-browser-37.0.2062.120 on jessie and it also seems to be affected by 
this bug. If I remember correctly I did test chromium 37 (not sure anymore 
which versions, but I think all that went to the Debian archive) from 
snapshots.debian.org some time ago and they all worked.

I also tested chromium from an Ubuntu live stick and webrtc does work there. 
However as far as I could see this the build of chromium on Ubuntu doesn't use 
any system libraries.


signature.asc
Description: This is a digitally signed message part.

Bug#770659: WebRTC camera/microphone sharing does not work

[Maximilian Engelhardt]

I can confirm this.

If I remember my tests correctly in all versions of chromium 37 that hit the 
Debian archive webrtc was working and in all versions 38 it is broken.

Sadly I have no idea what might be the cause of this.

signature.asc
Description: This is a digitally signed message part.

Bug#763683: [kicad] cvpcb shows Load Error on start

[Maximilian Engelhardt]

Package: kicad
Version: 0.20140622+bzr4027-3
Severity: normal

--- Please enter the report below this line. ---

when starting cvpcb on a new project I get the following Load Error:

Some files could not be found!
* smd_crystaloscillator.mod
* smd_dil.mod


This seems to be caused by module entries in 
/usr/share/kicad/template/kicad.pro which link to modules that are not shipped 
with the package. It seems this file is used as a template for new projects.

While I can simply ignore the error and fix the library paths in pcbnew this 
still is a bit annoying and might be confusing to users.

I also noticed that there are many more libraries and modules shipped in 
/usr/share/kicad/library/ and /usr/share/kicad/modules/ that are not listed in 
the kicad.pro file, so perhaps it makes sense to add them here.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16-2-amd64

Debian Release: jessie/sid
  500 testing security.debian.org 
  500 testing mirror.stusta.mhn.de 
  500 testing http.debian.net 

--- Package information. ---
Depends (Version) | Installed
=-+-==
kicad-common(= 0.20140622+bzr4027-2) | 0.20140622+bzr4027-3
libc6   (= 2.14) | 
libgcc1  (= 1:4.1.1) | 
libgl1-mesa-glx   | 
 OR libgl1| 
libglu1-mesa  | 
 OR libglu1   | 
libstdc++6   (= 4.9) | 
libwxbase3.0-0 (= 3.0.1) | 
libwxgtk3.0-0  (= 3.0.1) | 
libx11-6  | 
libxext6  | 
zlib-bin  | 


Package's Recommends field is empty.

Suggests (Version) | Installed
==-+-===
extra-xdg-menus| 1.0-4
kicad-doc-en   | 0.20140622+bzr4027-3
 OR kicad-doc-fr   | 
 OR kicad-doc-de   | 
 OR kicad-doc-es   | 
 OR kicad-doc-hu   | 
 OR kicad-doc-ru   | 
 OR kicad-doc-zh-cn| 





signature.asc
Description: This is a digitally signed message part.

Bug#756842: [linux-image-3.16-rc6-amd64] please enable CONFIG_SND_BEBOB

[Maximilian Engelhardt]

Package: linux-image-3.16-rc6-amd64
Version: 3.16~rc6-1~exp1
Severity: wishlist

Hello,

Please enable CONFIG_SND_BEBOB which has been newly added to the kernel in 
3.16. This provides a in-kernel driver for BeBob Firewire audio devices.

You probably might also want to enable
CONFIG_SND_DICE
CONFIG_SND_ISIGHT
CONFIG_SND_SCS1X
CONFIG_SND_FIREWORKS
to support the other Firewire chip sets too.

Greetings,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#741743: [src:kicad] FTBFS on all architectures

[Maximilian Engelhardt]

Source: kicad
Version: 0.20140224+bzr4027-3
Severity: serious

Hello,

kicad currently FTBFS on all architectures.

See here for the build logs:
https://buildd.debian.org/status/package.php?p=kicad

Maxi



signature.asc
Description: This is a digitally signed message part.

Bug#733319: [psi-plus-plugins] OTR conversations between psi-plus and pidgin sometimes don't work

[Maximilian Engelhardt]

Hi Boris,

Thanks for your patch. Today I had some time to test it and is does fix all 
the OTR problems I had before. So I can confirm that the patch fixes this bug.

Greetings,
Maxi


signature.asc
Description: This is a digitally signed message part.

Bug#733319: [psi-plus-plugins] OTR conversations between psi-plus and pidgin sometimes don't work

[Maximilian Engelhardt]

Package: psi-plus-plugins
Version: 0.16.262-1
Severity: normal

First, I'm not sure this bug is in psi-plus-plugins, but at the moment it 
seems to be the most likely package, so feel free to reassign if you think 
this has to be fixed somewhere else.

How to reproduce:
You need two XMPP accounts, configure one in psi-plus and the other in pidgin. 
Check OTR support in enabled in both clients. Then start both clients and try 
to start an OTR session.

When I'm trying to start a OTR session from pidgin I get We received a 
malformed data message from myaccountname@myserver in an endless loop on the 
pidgin client.

Trying to start a OTR session from psi-plus seems to work as it should,
however if I then try to refresh the session from pidgin the endless We 
received a malformed data message from myaccountname@myserver loop starts 
again. Refreshing the session from psi-plus seems to work without problems.

In my test I did use pidgin 2.10.7-2 and pidgin-otr 4.0.0-1 together with psi-
plus and psi-plus-plugins 0.16.262-1.

OTR sessions with other clients seem to work mostly as I haven't noticed any 
serious problems there, but I also didn't do any further investigation.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.12-1-amd64

Debian Release: jessie/sid
  500 testing security.debian.org 
  500 testing mirror.stusta.mhn.de 
  500 testing http.debian.net 

--- Package information. ---
Depends (Version) | Installed
=-+-==
libc6   (= 2.14) | 
libgcc1  (= 1:4.1.1) | 
libgcrypt11(= 1.4.5) | 
libotr5(= 4.0.0) | 
libqt4-dbus  (= 4:4.5.3) | 
libqt4-network   (= 4:4.5.3) | 
libqt4-xml   (= 4:4.5.3) | 
libqtcore4 (= 4:4.7.0~beta1) | 
libqtgui4(= 4:4.8.0) | 
libqtwebkit4(= 2.1.0~2011week13) | 
libstdc++6 (= 4.1.1) | 
libtidy-0.99-0| 
libx11-6  | 
psi-plus  (= 0.16.262-1)  | 
 OR psi-plus-webkit(= 0.16.262-1) | 


Package's Recommends field is empty.

Package's Suggests field is empty.

signature.asc
Description: This is a digitally signed message part.

Bug#733319: [psi-plus-plugins] OTR conversations between psi-plus and pidgin sometimes don't work

[Maximilian Engelhardt]

On Saturday 28 December 2013 18:55:59 Boris Pek wrote:
 control: reassign 733319 libotr 4.0.0~rc1-1
 
 Hi,
 
  ...
  When I'm trying to start a OTR session from pidgin I get We received a
  malformed data message from myaccountname@myserver in an endless loop on
  the pidgin client.
  
  Trying to start a OTR session from psi-plus seems to work as it should,
  however if I then try to refresh the session from pidgin the endless We
  received a malformed data message from myaccountname@myserver loop starts
  again. Refreshing the session from psi-plus seems to work without
  problems.
  ...
 
 As I know this is the problem in libotr = 4.0.0.
 
 In Psi+ this bug was not fixed directly, but workaround was added [1].
 That is why Psi+ works fine.
 
 [1]
 https://github.com/psi-plus/psi-plus-snapshots/blob/0.16.262/src/plugins/ge
 neric/otrplugin/changelog.txt#L3
 
 Best regards,
 Boris

Hi Boris,

Thank you for this information. I guess the problem is known upstream then. Do 
you have any links to the upstream report?

PS: I think you meant to reassign the bug to either src:libotr or libotr5 
(probably the latter) as there is no libotr = 4.0.0~rc1-1 in Debian.

Greetings,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#721742: [arduino] Please provide arduino version 1.5

[Maximilian Engelhardt]

Package: arduino
Version: 1:1.0.5+dfsg2-1
Severity: wishlist

--- Please enter the report below this line. ---

Hello,

I recently got an Arduino Due and notices that it is not supported by the 
arduino version in Debian. For support of the Arduino Due one needs Arduino 
version 1.5. Currently the latest upstream version is 1.5.3. As this version 
is still marked as Beta it might make sense to only provide it in experimental 
for now.

Greetings,
Maximilian Engelhardt

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.10-2-amd64

Debian Release: jessie/sid
  500 testing security.debian.org 
  500 testing mirror.stusta.mhn.de 
  500 testing http.debian.net 

--- Package information. ---
Depends (Version) | Installed
=-+-
default-jre   | 
 OR java6-runtime | 
libjna-java   | 3.2.7-4+b1
librxtx-java   (= 2.2pre2-3) | 2.2pre2-11
arduino-core  (= 1:1.0.5+dfsg2-1) | 1:1.0.5+dfsg2-1


Recommends   (Version) | Installed
==-+-===
extra-xdg-menus| 1.0-4
policykit-1| 0.105-3


Package's Suggests field is empty.

signature.asc
Description: This is a digitally signed message part.

Bug#718707: [gnuradio] gnuradio from experimental uninstallable

[Maximilian Engelhardt]

Package: gnuradio
Version: 3.7.0-3
Severity: normal

--- Please enter the report below this line. ---

gnuradio from experimental (version 3.7.0-3) depends on version 3.7.1 of 
libvolk0.0.0 which isn't available in Debian. However there is libvolk0.0.0  
version 3.7.0-3, which is built from the same sources as gnuradio. It seems 
like this is the version gnuradio should depend on.

Greeting,
Maxi


signature.asc
Description: This is a digitally signed message part.

Bug#718310: [gnuradio-dev] Please ship GnuradioConfig.cmake and GnuradioConfigVersion.cmake

[Maximilian Engelhardt]

Package: gnuradio-dev
Version: 3.7.0-2
Severity: wishlist
Tags: patch


Please ship these two files in gnuradio-dev:
/usr/lib/cmake/gnuradio/GnuradioConfig.cmake
/usr/lib/cmake/gnuradio/GnuradioConfigVersion.cmake

The following patch should do this:

--- gnuradio-3.7.0.old/debian/gnuradio-dev.install  2013-06-21 
18:00:36.0 +0200
+++ gnuradio-3.7.0/debian/gnuradio-dev.install  2013-07-29 03:45:14.420601000 
+0200
@@ -1,3 +1,4 @@
 usr/include
 usr/lib/*/*.so
 usr/lib/*/pkgconfig/*.pc
+usr/lib/cmake/gnuradio


Thanks,
Maxi

signature.asc
Description: This is a digitally signed message part.

Bug#657122: fixed in collectd 5.2.0-1

[Maximilian Engelhardt]

This bug is still present in testing/unstable. Are there any plans to fix it 
there?

signature.asc
Description: This is a digitally signed message part.

Bug#698584: [collectd] collectd crashes when enabling ethstat plugin

[Maximilian Engelhardt]

Package: collectd
Version: 5.1.0-3
Severity: normal
Tags: patch

--- Please enter the report below this line. ---
When enabling the ethstat plugin collectd crashes on startup:

$ /etc/init.d/collectd start
[] Starting statistics collection and monitoring daemon: collectd*** glibc 
detected *** /usr/sbin/collectd: munmap_chunk(): invalid pointer: 
0x008cd980 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x76d76)[0x7f988c731d76]
/usr/sbin/collectd(cf_util_get_string+0x37)[0x409537]
/usr/lib/collectd/ethstat.so(+0xf80)[0x7f988b495f80]
/usr/sbin/collectd(cf_read+0x231)[0x409aa1]
/usr/sbin/collectd(main+0xc9)[0x406079]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f988c6d9ead]
/usr/sbin/collectd[0x40696d]
=== Memory map: 
0040-00422000 r-xp  fd:00 800730 
/usr/sbin/collectd
00621000-00622000 r--p 00021000 fd:00 800730 
/usr/sbin/collectd
00622000-00623000 rw-p 00022000 fd:00 800730 
/usr/sbin/collectd
008aa000-008ec000 rw-p  00:00 0  [heap]
7f98859af000-7f98859c4000 r-xp  fd:00 1704299
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f98859c4000-7f9885bc4000 ---p 00015000 fd:00 1704299
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f9885bc4000-7f9885bc5000 rw-p 00015000 fd:00 1704299
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f9885bc5000-7f9885bc7000 r-xp  fd:00 800668 
/usr/lib/collectd/vmem.so
7f9885bc7000-7f9885dc6000 ---p 2000 fd:00 800668 
/usr/lib/collectd/vmem.so
7f9885dc6000-7f9885dc7000 r--p 1000 fd:00 800668 
/usr/lib/collectd/vmem.so
7f9885dc7000-7f9885dc8000 rw-p 2000 fd:00 800668 
/usr/lib/collectd/vmem.so
7f9885dc8000-7f9885dc9000 r-xp  fd:00 800708 
/usr/lib/collectd/users.so
7f9885dc9000-7f9885fc8000 ---p 1000 fd:00 800708 
/usr/lib/collectd/users.so
7f9885fc8000-7f9885fc9000 r--p  fd:00 800708 
/usr/lib/collectd/users.so
7f9885fc9000-7f9885fca000 rw-p 1000 fd:00 800708 
/usr/lib/collectd/users.so
7f9885fca000-7f9885fcc000 r-xp  fd:00 800693 
/usr/lib/collectd/uptime.so
7f9885fcc000-7f98861cb000 ---p 2000 fd:00 800693 
/usr/lib/collectd/uptime.so
7f98861cb000-7f98861cc000 r--p 1000 fd:00 800693 
/usr/lib/collectd/uptime.so
7f98861cc000-7f98861cd000 rw-p 2000 fd:00 800693 
/usr/lib/collectd/uptime.so
7f98861cd000-7f98861cf000 r-xp  fd:00 798364 
/usr/lib/collectd/swap.so
7f98861cf000-7f98863ce000 ---p 2000 fd:00 798364 
/usr/lib/collectd/swap.so
7f98863ce000-7f98863cf000 r--p 1000 fd:00 798364 
/usr/lib/collectd/swap.so
7f98863cf000-7f98863d rw-p 2000 fd:00 798364 
/usr/lib/collectd/swap.so
7f98863d-7f98863d5000 r-xp  fd:00 1068051
/usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f98863d5000-7f98865d4000 ---p 5000 fd:00 1068051
/usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f98865d4000-7f98865d5000 rw-p 4000 fd:00 1068051
/usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f98865d5000-7f98865d7000 r-xp  fd:00 1068043
/usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f98865d7000-7f98867d7000 ---p 2000 fd:00 1068043
/usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f98867d7000-7f98867d8000 rw-p 2000 fd:00 1068043
/usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f98867d8000-7f98867ff000 r-xp  fd:00 1707727
/lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f98867ff000-7f98869ff000 ---p 00027000 fd:00 1707727
/lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f98869ff000-7f9886a01000 r--p 00027000 fd:00 1707727
/lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f9886a01000-7f9886a02000 rw-p 00029000 fd:00 1707727
/lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f9886a02000-7f9886a3e000 r-xp  fd:00 1707764
/lib/x86_64-linux-gnu/libpcre.so.3.13.1
7f9886a3e000-7f9886c3e000 ---p 0003c000 fd:00 1707764
/lib/x86_64-linux-gnu/libpcre.so.3.13.1
7f9886c3e000-7f9886c3f000 rw-p 0003c000 fd:00 1707764
/lib/x86_64-linux-gnu/libpcre.so.3.13.1
7f9886c3f000-7f9886c4b000 r-xp  fd:00 1068201
/usr/lib/x86_64-linux-gnu/libffi.so.5.0.10
7f9886c4b000-7f9886e4b000 ---p c000 fd:00 1068201
/usr/lib/x86_64-linux-gnu/libffi.so.5.0.10
7f9886e4b000-7f9886e4c000 rw-p c000 fd:00 1068201
/usr/lib/x86_64-linux-gnu/libffi.so.5.0.10
7f9886e4c000-7f9886e4d000 r-xp  fd:00 1049169  

Bug#639667: [telepathy-gabble] Claims my server's certificate is self-signed

[Maximilian Engelhardt]

Package: telepathy-gabble
Version: 0.16.1-1

I think this is the same problem I have. I tried three different jabber server 
of which I know they have valid certificates and other jabber clients validate 
them just fine, but telepathy-gabble always gives me this error that the 
certificate is self-signed. Tested with empathy and telepathy-kde.

I did enable telepathy-gabble logging, but couldn't find anything wrong in the 
logs. I seems to load system certificates from /etc/ssl/certs/ca-
certificates.crt fine, but somehow is unable to validate the server 
certificate. I tried searching for this problem on the internet, but all I 
found was this bug report or some people complaining about what seems to be 
the same problem on some Ubuntu forums. I also tried searching the upstream 
bugzilla, but couldn't find anything relevant.

So for me this looks a bit strange. It seems like only people from Debian or 
Ubuntu are affected, but I couldn't find any effort to track this down. So 
either there is something special about Debian (and Ubuntu) that triggers this 
bug only there or nobody tried it on other distributions or everybody just 
enabled the ignore ssl errors flag (which IMHO is a bad thing to do).

I also tried building the upstream git version of telepathy-gabble, but it has 
the same problem for me.

For me this very much looks like an upstream bug, however I wonder why this 
hasn't been noticed and reported anywhere then. So I will open an upstream bug 
about this issue soon, unless someone convinces me this is a Debian specific 
problem.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.4-trunk-rt-amd64

Debian Release: wheezy/sid
  500 testing security.debian.org 
  500 testing mirror.stusta.mhn.de 
  500 testing ftp.de.debian.org 
1 experimentalmirror.stusta.mhn.de 

--- Package information. ---
Depends (Version) | Installed
=-+-===
libc6(= 2.7) | 
libdbus-1-3(= 1.1.1) | 
libdbus-glib-1-2(= 0.88) | 
libglib2.0-0  (= 2.31.8) | 
libgnutls26(= 2.12.17-0) | 
libnice10  (= 0.1.0) | 
libsoup2.4-1   (= 2.4.0) | 
libsqlite3-0   (= 3.5.9) | 
libtelepathy-glib0(= 0.18.0) | 
libxml2(= 2.7.4) | 


Package's Recommends field is empty.

Package's Suggests field is empty.




signature.asc
Description: This is a digitally signed message part.

Bug#645822: [gcc-avr] FTBFS on mips, mipsel and sparc

[Maximilian Engelhardt]

Package: gcc-avr
Version: 1:4.5.3-1
Severity: normal

gcc-avr failed to build on mips, mipsel and sparc. Thus it can't migrate to 
testing. See this link here:

http://release.debian.org/migration/testing.pl?package=gcc-avr


It would be nice to see this fixed, so avr-gcc can enter testing again and be 
released with the next stable Debian version (wheezy).

Greetings,
Maxi


signature.asc
Description: This is a digitally signed message part.

Bug#640457: [openssl] some Verisign certificates fail to verify

[Maximilian Engelhardt]

On Friday 14 October 2011 07:28:00 Kyle Moffett wrote:
  So chain-0 can be verified by chain-1 and chain-1 can be verified by the
  system installed CAs.
  
  The problem is that
  VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt
  got updated in ca-certificates 20110421.
  And the last certificated sent by the server (chain-2) is the old version
  of this same certificate.
  
  $ openssl x509 -noout -subject -issuer -in
  /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_-
  _G5.pem
  subject= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
  VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
  Primary Certification Authority - G5
  issuer= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
  VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
  Primary Certification Authority - G5
  
  So it seems like openssl first uses the certificate that's send from the
  server, but then fails to verify it (as it can't find an appropriate root
  certificate). Instead it should ignore the sent certificate and use the
  one that is installed on the local system and thus trusted as root
  certificate.
  
  This behaviour is especially a problem for me since konqueror uses
  openssl to verify the certificates and there are quite some sites that
  deliver the old certificate in the chain.
  
  Also note that gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt
  -p 443 signin.ebay.de does verify the certificate just fine.
 
 This PHP bug-report seems basically identical:
   https://bugs.php.net/bug.php?id=49419
 
 Based on my understanding of TLS and from that PHP bug-report... I'm
 actually pretty sure that this is not a bug.  According to the TLS
 standard (RFC2246):
certificate_list
This is a sequence (chain) of X.509v3 certificates. The sender's
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the
root certificate authority may optionally be omitted from the
chain, under the assumption that the remote end must already
possess it in order to validate it in any case.
 
 The certificates passed in the protocol must be a strict sequence.
 Any server sending out-of-order or bogus certificates in the chain is
 not complying with the TLS protocol requirements, and cannot
 reasonably expect to validate correctly.  It's entirely possible that
 some implementations are much more lenient than others, but the
 standard itself seems very obvious as to the requirement.
 
 As far as I can tell, OpenSSL implements a very safe default for SSL
 certificate chain construction and requires the application to
 implement a more advanced model if desired.  This is basically a
 server configuration problem, and at best this should be a feature
 request against konqueror to better handle broken server
 configurations.
 
 Please note that GnuTLS has historically been missing a number of the
 stricter checks that OpenSSL provides by default, and that those tend
 to get added to GnuTLS when their absence is identified.  For example,
 OpenSSL has always checked certificate validity times by default, but
 prior to CVE-2009-1417, the GnuTLS library relied upon the application
 to perform those checks (and most did not).
 
 Let me know if you want me to reassign this bug to konqueror or close
 it as wontfix.
 
 Cheers,
 Kyle Moffett

Hello Kyle,

thanks for your detailed explanation. So this seems to be a Konqueror bug, 
perhaps even an upstream KDE bug.

On the other hand this might also be a ca-certificates bug, since it doesn't 
ship the old Verisign root certificate anymore, but without that certificate 
openssl will fail to verify any chain that uses it (and it seems to be wildly 
used).

I'm not really sure if it's a Konqueror or a ca-certificates bug, so feel free 
to reassign it to whatever you think fits best, perhaps Konqueror, as you did 
suggest in your last mail.

I'm wondering how many other programs that use openssl experience the same 
problem.

Greetings and thanks for you work,
Maxi


signature.asc
Description: This is a digitally signed message part.

Bug#640457: [openssl] some VeriSign certificates fail to verify

[Maximilian Engelhardt]

Package: openssl
Version: 1.0.0d-3
Severity: important

Hello,

I'm having problems verifying some VeriSign certificates.

As far as I traced this back I think this is a problem with openssl. But if 
you think this bug should be fixed elsewhere feel free to reassign the report.


Here is a detailed description about the problem. I'm using signin.ebay.de as 
an example, but many other sites are also affected by this.

$ openssl s_client -host signin.ebay.de -port 443 -CApath /etc/ssl/certs/ -
showcerts
CONNECTED(0003)
depth=2 C = US, O = VeriSign, Inc., OU = VeriSign Trust Network, OU = (c) 
2006 VeriSign, Inc. - For authorized use only, CN = VeriSign Class 3 Public 
Primary Certification Authority - G5
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 
s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private
 
Organization/serialNumber=2871352/C=US/postalCode=95125/ST=California/L=San 
Jose/street=2145 Hamilton Ave/O=eBay Inc./OU=Site 
Operations/CN=signin.ebay.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL 
CA
-BEGIN CERTIFICATE-
MIIIXjCCB0agAwIBAgIQPqLLa6xb3tYmpa6m2RTjDDANBgkqhkiG9w0BAQUFADCB
ujELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE0MDIGA1UEAxMr
VmVyaVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBDQTAeFw0x
MTAxMTkwMDAwMDBaFw0xMzAxMjMyMzU5NTlaMIIBCjETMBEGCysGAQQBgjc8AgED
EwJVUzEZMBcGCysGAQQBgjc8AgECEwhEZWxhd2FyZTEdMBsGA1UEDxMUUHJpdmF0
ZSBPcmdhbml6YXRpb24xEDAOBgNVBAUTBzI4NzEzNTIxCzAJBgNVBAYTAlVTMQ4w
DAYDVQQRFAU5NTEyNTETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxQIU2Fu
IEpvc2UxGjAYBgNVBAkUETIxNDUgSGFtaWx0b24gQXZlMRIwEAYDVQQKFAllQmF5
IEluYy4xGDAWBgNVBAsUD1NpdGUgT3BlcmF0aW9uczEYMBYGA1UEAxQPc2lnbmlu
LmViYXkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3fF7qsUm
ltnVU395Tlg8wEMITNv3X1hCXr4Engs3DLnta2LzDH2HR2hkAZhs7QwFADlCZ0/I
6LLQ6HChhF91HcrL3fbM9eQphBMrQ5QhqKqDZa2YMR2VJy3OaxqHjTlrgseES2CJ
B0DJoQ31NxEpj4dETfkK2fDHhvFYj//RyneIFIkvaw0F2hOBYbKWBfMx0uK/VX9/
4LYKQw6xBp/2T9MSXU0jP1pqwrtg8c0l6vB9ijF/SY5pLZZOYMmJ7QLpSRIflqLs
P4Voz1c4RDmyhm/RS421SaUzlarPeMnof1HoTsO/hUXow0vhfYt4OklKV3T6gcZ2
+DR2jnUL6QjRdwIDAQABo4IECzCCBAcwggIUBgNVHREEggILMIICB4IPc2lnbmlu
LmViYXkuY29tgg5zaWduaW4uZWJheS5hdIIOc2lnbmluLmViYXkuYmWCDnNpZ25p
bi5lYmF5LmNhgg5zaWduaW4uZWJheS5jaIIOc2lnbmluLmViYXkuZGWCDnNpZ25p
bi5lYmF5LmVzgg5zaWduaW4uZWJheS5mcoIOc2lnbmluLmViYXkuaWWCDnNpZ25p
bi5lYmF5Lmlugg5zaWduaW4uZWJheS5pdIIOc2lnbmluLmViYXkubmyCDnNpZ25p
bi5lYmF5LnBogg5zaWduaW4uZWJheS5wbIIRc2lnbmluLmViYXkuY28udWuCEnNp
Z25pbi5lYmF5LmNvbS5hdYISc2lnbmluLmViYXkuY29tLmhrghJzaWduaW4uZWJh
eS5jb20ubXmCEnNpZ25pbi5lYmF5LmNvbS5zZ4ITc2lnbmluLmJlZnIuZWJheS5i
ZYITc2lnbmluLmJlbmwuZWJheS5iZYITc2lnbmluLmNhZnIuZWJheS5jYYIXc2ln
bmluLmV4cHJlc3MuZWJheS5jb22CFHNpZ25pbi5oYWxmLmViYXkuY29tghxzaWdu
aW4ubGl2ZWF1Y3Rpb25zLmViYXkuY29tghhzaWduaW4uc2hvcHBpbmcuZWJheS5j
b22CG3NpZ25pbi53b3JsZG9mZ29vZC5lYmF5LmNvbTAJBgNVHRMEAjAAMB0GA1Ud
DgQWBBTgXmYC0gjb9HFTji+RYF/OtcPJWTALBgNVHQ8EBAMCBaAwQgYDVR0fBDsw
OTA3oDWgM4YxaHR0cDovL0VWU2VjdXJlLWNybC52ZXJpc2lnbi5jb20vRVZTZWN1
cmUyMDA2LmNybDBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcGMCowKAYIKwYBBQUH
AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwHQYDVR0lBBYwFAYIKwYB
BQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQYMBaAFPyKULqeuSVae1WFT5UAY4/pWGtD
MHwGCCsGAQUFBwEBBHAwbjAtBggrBgEFBQcwAYYhaHR0cDovL0VWU2VjdXJlLW9j
c3AudmVyaXNpZ24uY29tMD0GCCsGAQUFBzAChjFodHRwOi8vRVZTZWN1cmUtYWlh
LnZlcmlzaWduLmNvbS9FVlNlY3VyZTIwMDYuY2VyMG4GCCsGAQUFBwEMBGIwYKFe
oFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4myms
SweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAN
BgkqhkiG9w0BAQUFAAOCAQEAOEmD2bGiV4C0ba2GKakTphtGPA7uIVn6b0TeSUIF
6YHzzNlxU/yxumI1ghdmqaLUARvLVdNoEk4m7HoWLEDRVTJO6/BDGUK4I06c8u20
F2oW7qJCSgQbtyg62n/NeSmN4zMJo8JLTXfyIeZ6kjRj1SdKupyI/DnQVWaQNBv7
4IMelo0yQNeeNEF4/INZxaLdc6o1x8A0FOvKaM+16MrnJSsNXO0sioufC22zRIPw
o6rJ7sQx6ZhEefUgxBCgSJcpBkUUP6II0a/cQzMP5OUXkcKTnfoYAqSQmKRVSKCR
CqXkeyEODiBRQyvG2jsFFpYWKSQlLR08qs1usFHkx363Cw==
-END CERTIFICATE-
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL 
CA
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, 
Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary 
Certification Authority - G5
-BEGIN CERTIFICATE-
MIIF5DCCBMygAwIBAgIQW3dZxheE4V7HJ8AylSkoazANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMDYxMTA4MDAwMDAwWhcNMTYxMTA3MjM1OTU5WjCBujEL

Bug#617317: autofs5: crashed in a nested setup in combination with negative lookups on *

[Maximilian Engelhardt]

tags 617317 +patch
thanks

I was working together with Johannes on this bug and we found that it is 
already fixed upstream by [1].

Applying this patch on the current squeeze version (5.0.4-3.2) fixes the 
mentioned crash for us.

It would be nice to see this fixed in Squeeze as it might affect other users 
too.

If you want I can send additional information how I fixed it, but basically it 
is just applying the path from [1] and rebuilding the package.


[1] 
http://www.kernel.org/pub/linux/daemons/autofs/v5/autofs-5.0.5-mapent-becomes-negative-during-lookup.patch

Greetings,
Maxi


signature.asc
Description: This is a digitally signed message part.

Bug#597476: dovecot: Exp, Sid packages for Dovecot 2

[Maximilian Engelhardt]

Any progress on this?

Now that Squeeze is released I don't see any reason why Dovecot 2 can't be 
uploaded to unstable (or at least experimental).

I've seen there is a debian-2.0 branch in the dovecot git repository on 
git.debian.org that seems to be quite well maintained. I compiled dovecot 2 
from there and am running it on my server now for some time without any 
problems.

Also are there any plans to provide packages of Dovecot 2 for squeeze via 
backports?

Greetings,
Maxi


signature.asc
Description: This is a digitally signed message part.

Bug#533406: cssh real name / given name handling changed in 3.26, breaking some known_hosts

[Maximilian Engelhardt]

On Wednesday 02 December 2009 10:24:21 Duncan Ferguson wrote:
 On 20 Nov 2009, at 10:20, Josip Rodin wrote:
  A couple of us noticed and reported a problem with cssh 3.26 in Debian
  at http://bugs.debian.org/533406 that you may be interested in fixing.
 
 I have just put a code fix into git - can you try it out and let me
 know if its now OK for you.

I just tried the latest git version and it fixed this bug for me. Thanks a lot.

Greetings
Maxi


signature.asc
Description: This is a digitally signed message part.

Bug#561637: [isatapd] New version available (0.9.6)

[Maximilian Engelhardt]

Package: isatapd
Version: 0.9.5-1
Severity: wishlist

Hello,

A new version (0.9.6) of isatapd has been released. Among other things it fixes 
isatapd for kernels  2.6.31
It would be nice to have it in debian.

Greetings,
Maxi


signature.asc
Description: This is a digitally signed message part.

Bug#552152: [geda] new stable version available (1.6.0)

[Maximilian Engelhardt]

Package: geda
Version: 1:1.4.0.2
Severity: wishlist

A new stable version (1.6.0) of geda has been released. See the announcement
http://www.seul.org/pipermail/geda-announce/2009-October/89.html
and the download page
http://www.gpleda.org/sources.html

It would be nice to see geda 1.6.0 in debian.


Greetings,
Maxi


signature.asc
Description: This is a digitally signed message part.

Bug#541653: kdelibs5: several (https) SSL certificates cannot be validated for internal reasons

[Maximilian Engelhardt]

I can confirm this bug.

I have a laptop with Debian unstable and KDE 4.3 and a desktop PC with Debian 
testing and KDE 4.2 and both are affected by this bug. However on my desktop 
PC (KDE 4.2) this problem just occurred recently, so I don't think it's caused 
by kdelibs5.

I think the real cause is a package that has recently migrated to testing (and 
of course is also in unstable). Sadly I have no idea what it could be.



signature.asc
Description: This is a digitally signed message part.

Bug#483561: [eagle] New version available (5.0.0)

[Maximilian Engelhardt]

Package: eagle
Version: 4.16r2-1
Severity: wishlist

--- Please enter the report below this line. ---

There is a new version of eagle available (5.0.0) at 
http://www.cadsoft.de/download.htm

It would be nice to see it in debian.

--- System information. ---
Architecture: i386
Kernel:   Linux 2.6.26-rc4

Debian Release: lenny/sid
  500 unstableftp2.de.debian.org 
  500 unstabledebian.netcologne.de 
  500 unstabledeb.opera.com 
  500 testing security.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-=
eagle-data  (= 4.16r2-1) | 4.16r2-1
libc6 (= 2.6-1) | 2.7-11
libx11-6 | 2:1.0.3-7
libxext6 | 2:1.0.4-1
debconf(= 0.5)  | 1.5.22
 OR debconf-2.0  | 



signature.asc
Description: This is a digitally signed message part.

Bug#477221: [libfreebob0] new version available (1.0.11)

[Maximilian Engelhardt]

Package: libfreebob0
Version: 1.0.7-1
Severity: wishlist

--- Please enter the report below this line. ---

There is a new version of libfreebob available. It would be nice to see it in 
debian. More information can be found here:

http://article.gmane.org/gmane.linux.audio.users/46958
http://article.gmane.org/gmane.linux.audio.users/47196

--- System information. ---
Architecture: i386
Kernel:   Linux 2.6.25

Debian Release: lenny/sid
  500 unstableftp2.de.debian.org 
  500 unstabledebian.netcologne.de 
  500 unstabledeb.opera.com 
  500 testing security.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-
libavc1394-0   (= 0.5.3) | 0.5.3-1+b1
libc6  (= 2.7-1) | 2.7-10
libgcc1   (= 1:4.1.1-21) | 1:4.3.0-3
libiec61883-0  (= 1.1.0) | 1.1.0-2
libraw1394-8  | 1.3.0-3
libstdc++6   (= 4.2.1-4) | 4.3.0-3
libxml2   (= 2.6.27) | 2.6.32.dfsg-1



signature.asc
Description: This is a digitally signed message part.

Bug#476122: [psi] psi crashes with qt4.4 when last tab is closed

[Maximilian Engelhardt]

Package: psi
Version: 0.11-7
Severity: important
Tags: patch

--- Please enter the report below this line. ---

When I close the last tab of the chatwindow psi crashes. This started with 
upgrading my system to qt4.4. A patch fixing this can be found in upstream 
svn rev 1101:
http://dev.psi-im.org/websvn/comp.php?repname=Psipath=%2F[EMAIL 
PROTECTED][EMAIL PROTECTED]

--- System information. ---
Architecture: i386
Kernel:   Linux 2.6.25-rc8

Debian Release: lenny/sid
  500 unstableftp2.de.debian.org 
  500 unstabledebian.netcologne.de 
  500 unstabledeb.opera.com 
  500 testing security.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-
libaspell15 (= 0.60) | 0.60.5-2.1
libc6  (= 2.7-1) | 2.7-10
libgcc1   (= 1:4.1.1-21) | 1:4.3.0-3
libqca2   | 2.0.0-4
libqt4-core(= 4.3.4) | 4.4.0~rc1-3
libqt4-gui (= 4.3.4) | 4.4.0~rc1-3
libqt4-qt3support  (= 4.3.4) | 4.4.0~rc1-3
libstdc++6  (= 4.1.1-21) | 4.3.0-3
libx11-6  | 2:1.0.3-7
libxss1   | 1:1.1.3-1
zlib1g   (= 1:1.1.4) | 1:1.2.3.3.dfsg-12



signature.asc
Description: This is a digitally signed message part.

Bug#421194: (no subject)

[Maximilian Engelhardt]

Package: psi
Version: 0.11-3

--- Please enter the report below this line. ---
I think this is the same Problem I got after updating my system some days ago.
When starting Psi with gpg enabled it should ask for the pgp passphrase, but 
the dialog is never shown, so it just hangs waiting for a passphrase.

I talked to the Psi developers about this Problem and got the the following 
patch which fixed the Problem. The patch is also in Psi svn.


Index: src/passphrasedlg.cpp
===
--- src/passphrasedlg.cpp   (revision 856)
+++ src/passphrasedlg.cpp   (working copy)
@@ -34,7 +34,7 @@
 void PassphraseDlg::promptPassphrase(const QString name)
 {
setWindowTitle(tr(%1: OpenPGP Passphrase).arg(name));
-   resize(minimumSize());
+   resize(minimumSizeHint());
 }

 QString PassphraseDlg::getPassphrase() const


--- System information. ---
Architecture: i386
Kernel:   Linux 2.6.24-rc7

Debian Release: lenny/sid
  500 unstableftp.hosteurope.de 
  500 unstabledebian.netcologne.de 
  500 unstabledeb.opera.com 
  500 testing security.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-==
libaspell15   (= 0.60) | 0.60.5-1
libc6  (= 2.6.1-1) | 2.7-5
libgcc1(= 1:4.2.1) | 1:4.3-20080104-1
libqca2 | 2.0.0-3
libqt4-core  (= 4.3.2) | 4.3.3-2
libqt4-gui   (= 4.3.2) | 4.3.3-2
libqt4-qt3support(= 4.3.2) | 4.3.3-2
libstdc++6   (= 4.2.1) | 4.3-20080104-1
libx11-6| 2:1.0.3-7
libxext6| 1:1.0.3-2
libxss1 | 1:1.1.2-1
zlib1g(= 1:1.2.3.3.dfsg-1) | 1:1.2.3.3.dfsg-8




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]