Bug#1065486: sbd: FTBFS due to hardcoded libaio SONAME used in dlopen()

[Ferenc Wágner]

This is already fixed in unstable,  waiting for pacemaker to migrate.

Bug#1006146: also useful for other Gnome settings

[Ferenc Wágner]

For example in my case gsd-rfkill was necessary for enabling the
Bluetooth settings in gnome-control-center.  It is also provided by
/usr/lib/systemd/user/gnome-session@gnome-flashback-metacity.target.d
(for xmonad 0.17.1-1 in Debian bookworm).
-- 
Feri.

Bug#848972: Fixed in Ubuntu

[Ferenc Wágner]

On Sun, 11 Feb 2024 13:11:51 +0100 Holger Wansing  wrote:

> Ferenc Wágner  wrote (Mon, 26 Jun 2023 12:27:49 +0200):
>
>> This issue was fixed in 1.178ubuntu12, as detailed at
>> https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1824227
>> Please consider taking over the fix.
> 
> I have grabbed the changings from
> https://git.launchpad.net/ubuntu/+source/console-setup/commit/?h=applied/ubuntu/disco=dc3395232928c2a3f53c7e5e29ad25a2638ddcae
> Patch attached.  Any objections?

Hi Holger,

None from my part, FWIW (very little).  I'd thank the original
author in the changelog entry, though.
-- 
Thanks for you work,
Feri.

Bug#1056931: libgphoto2-6: Move files into /usr (incl. DEP17 P7 mitigation)

[Ferenc Wágner]

2023-12-06 19:00 időpontban Andreas Metzler ezt írta:

On 2023-12-06 Chris Hofstaedtler  wrote:
[...]

Are there any blockers, or could this move forward?



I expect all other packages will have fixes in unstable on December
10th, and then I would like to continue with the next steps for the
udev rules migrations.


I have just made the upload. - I guess Ferenc is busy, and afaiui this
kind of change would even be OK to NMU.


Hi,

Sorry for the silence, I was very busy indeed in the past weeks (and
also had problems with email access and delivery). I glanced at the
proposed patch and didn't find it obvious at first sight, so I refrained
from quickly applying it. I'm happy that Andreas confidently applied
and uploaded it.
--
Thanks,
Feri.

Bug#1043201: slirp: immediate exit at startup

[Ferenc Wágner]

Hi,

I finally managed to get back to this and arrived at the patch bundle
below.  The first patch fixes the actual problem for me, the second one
aligns the corresponding debug logs (which aren't enabled in the current
build, but were useful during debugging), and the third one fixes a
compilation error with debugging enabled.  The explanation is in the
commit message.  I didn't test on 32-bit architectures, only on 64-bit
under UML, but briefly contemplated adding an autopkgtest.  Nothing too
involved, because I doubt slirp sees wide use, but we can talk about
this later if you're interested.

Please review and consider incorporating the fix, or I can do an NMU if
you prefer that.

Thanks,
Feri.

>From 247d6e3563512cf41d8af279a8be23d22699f80d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ferenc=20W=C3=A1gner?= 
Date: Fri, 20 Oct 2023 21:05:31 +0200
Subject: [PATCH 1/3] Do not convert tmp_time to unsiged before assigning to
 tv_usec

When tmp_time is set to the sentinel value -1 that conversion results
2^32-1, which is out of range for suseconds_t on 32-bit platforms, so
the assignment invokes undefined behaviour (which apparently happened
to give -1, working good enough for the task by chance).  However, on
64-bit platforms 2^32-1 fits in the range of suseconds_t (long int)
and definitely does not equal -1 in the following check, leading to
EINVAL when passed into the select() call and immediately exiting
slirp on startup.
---
 src/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/main.c b/src/main.c
index 6e15a74..1c01732 100644
--- a/src/main.c
+++ b/src/main.c
@@ -933,7 +933,7 @@ cont_1:
 * Take the minimum of the above calculated timeouts
 */
if ((timeout.tv_usec < 0) || (tmp_time >= 0 && tmp_time < 
timeout.tv_usec))
-   timeout.tv_usec = (u_int)tmp_time;
+   timeout.tv_usec = tmp_time;
 #endif
DEBUG_MISC((dfd, " timeout.tv_usec = %u",
(u_int)timeout.tv_usec));
-- 
2.39.2


>From d20acd8f16cc884611bcf3fd8ad5665876a22f0a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ferenc=20W=C3=A1gner?= 
Date: Fri, 20 Oct 2023 21:22:46 +0200
Subject: [PATCH 2/3] Log tv_usec as the signed long it is

---
 src/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/main.c b/src/main.c
index 1c01732..6384810 100644
--- a/src/main.c
+++ b/src/main.c
@@ -935,8 +935,8 @@ cont_1:
if ((timeout.tv_usec < 0) || (tmp_time >= 0 && tmp_time < 
timeout.tv_usec))
timeout.tv_usec = tmp_time;
 #endif
-   DEBUG_MISC((dfd, " timeout.tv_usec = %u",
-   (u_int)timeout.tv_usec));
+   DEBUG_MISC((dfd, " timeout.tv_usec = %ld",
+   (long)timeout.tv_usec));
if (time_fasttimo) {
DEBUG_MISC((dfd, ", need fasttimo\n"));
} else {
-- 
2.39.2


>From ed538e8fae21a6f802e412b5b38a19944ac5d631 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ferenc=20W=C3=A1gner?= 
Date: Sat, 21 Oct 2023 17:06:00 +0200
Subject: [PATCH 3/3] Add missing FILE argument to DEBUG_ERROR macro invocation

---
 src/misc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/misc.c b/src/misc.c
index e2849b8..dc6e593 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -988,7 +988,7 @@ static int slirp_vsnprintf(char *str, size_t size,
 int rv = vsnprintf(str, size, format, args);
 
 if (rv < 0) {
-DEBUG_ERROR(("vsnprintf() failed: %s", strerror(errno)));
+DEBUG_ERROR((dfd, "vsnprintf() failed: %s", strerror(errno)));
 }
 
 return rv;
-- 
2.39.2

Bug#977674: Corrupt changes file when built with --source-only-changes

[Ferenc Wágner]

On Mon, 25 Jan 2021 17:45:29 +0100 Johannes Schauer Marin Rodrigues 
 wrote:

> The problem is, that when you combine --source-only-changes with --keyid, then
> debsign will be run twice (once for the normal changes file and once for the
> source-only changes file) and both times with --re-sign.  This means, that the
> second invocation will possibly also change the signature of files that were
> already processed by the first invocation and this means that the checksum of
> the first changes file doesn't match anymore.
> 
> To fix the problem, one might suggest to just run the second invocation of
> debsign with --no-re-sign so that everything that is already signed does not
> get changed and only those things that don't have a signature get signed.
> 
> But this triggers a bug in debsign where the dsc will not even be considered
> for signing if the buildinfo was already signed.

Since the buildinfo file of an upload contains the checksums of the dsc, this
behaviour makes sense, as signing the dsc would break the buildinfo.  On the
other hand for the same reason, if the buildinfo is signed the dsc should
already be signed as well.  In the sbuild --source --source-only-changes case
it most certainly will be, because the first debsign invocation signed it.
What use case would using --no-re-sign for the second call break?
-- 
Regards,
Feri.

Bug#962114: Updating the pngquant Uploaders list

[Ferenc Wágner]

On Tue, 19 Sep 2023 23:33:28 +0200 Bastian Germann  wrote:

> Version: 2.0.1-1

Hi Bastian,

pngquant 2.0.1-1 seems to have Nelson in its Uploaders field[1], that
line was removed by 862d6537026411d378b8a8be6c578b43b8e9fcd0 and
uploaded in 2.13.1-1.  Did you mistype the version or did you mean to
close a different bug perhaps?

[1] 
https://salsa.debian.org/debian-phototools-team/pngquant/-/blob/b5a7e70897374549bd0ad648405a0035afa8c9fd/debian/control
-- 
Regards,
Feri.

Bug#1052221: man-db: cache cleanup race

[Ferenc Wágner]

Package: man-db
Version: 2.10.2-1
Severity: normal
Tags: upstream

Dear Maintainer,

I experienced this on an Ubuntu jammy system, but the current Debian
unstable version is probably affected as well (based on the sources
available on salsa.debian.org).

Please consider these logs:

05:29:32 hn systemd[1]: Starting Cleanup of Temporary Directories...
05:29:32 hn systemd[1]: Starting Daily man-db regeneration...
05:29:32 hn find[31023]: /usr/bin/find: ‘/var/cache/man/de’: No such file or 
directory
05:29:32 hn find[31023]: /usr/bin/find: ‘/var/cache/man/pt’: No such file or 
directory
[... bunch of similar error messages omitted ...]
05:29:32 hn systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
05:29:32 hn systemd[1]: Finished Cleanup of Temporary Directories.
05:29:32 hn find[31023]: /usr/bin/find: ‘/var/cache/man/cat9’: No such file or 
directory
05:29:32 hn systemd[1]: man-db.service: Main process exited, code=exited, 
status=1/FAILURE
05:29:32 hn systemd[1]: man-db.service: Failed with result 'exit-code'.
05:29:32 hn systemd[1]: Failed to start Daily man-db regeneration.

I suppose this happened because the cleanup prescribed by
/usr/lib/tmpfiles.d/man-db.conf and the "manual" cleanup implemented by
the find call in /lib/systemd/system/man-db.service ran concurrently.
This results in man-db.service spuriously entering failed state,
triggering false monitoring alarms.  Please avoid this by choosing one
cleanup method only (if the above analysis is correct).
-- 
Thanks,
Feri.

Bug#1043201: slirp: immediate exit at startup

[Ferenc Wágner]

Roberto Lumbreras  writes:

> timeout is defined as "struct timeval":
>
>struct timeval {
>time_t   tv_sec;   /* Seconds */
>suseconds_t  tv_usec;  /* Microseconds */
>};
>
> timeout.tv_used is suseconds_t == time_t == int, so I can't understand
> why it's unsigned in your case.

Hi Roberto,

I probably missed the starting 's', suseconds_t is indeed documented as
signed, and is actually a long int here.  So my patch shouldn't work.
What's sure:

# gdb slirp
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from slirp...
Reading symbols from 
/usr/lib/debug/.build-id/e1/1ce5371d887d06c3b97a0c6a68463ba1cc8bcf.debug...
(gdb) b main.c:960
Breakpoint 1 at 0x1408b: file ./main.c, line 960.
(gdb) r
Starting program: /usr/bin/slirp 
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Slirp v1.0.17 (BETA)

Copyright (c) 1995,1996 Danny Gasparovski and others.
All rights reserved.
This program is copyrighted, free software.
Please read the file COPYRIGHT that came with the Slirp
package for the terms and conditions of the copyright.

IP address of Slirp host: 172.17.0.2
IP address of your DNS(s): 10.12.1.5, 10.10.1.10
Your address is 10.0.2.15
(or anything else you want)

Type five zeroes (0) to exit.

[autodetect SLIP/CSLIP, MTU 1500, MRU 1500, 115200 baud]

SLiRP Ready ...

Breakpoint 1, main_loop () at ./main.c:960
warning: Source file is more recent than executable.
960 ret = select(nfds+1, , , , );
(gdb) p timeout
$1 = {tv_sec = 0, tv_usec = 4294967295}
(gdb) p/x timeout.tv_usec
$2 = 0x
(gdb) p nfds
$3 = 0
(gdb) n
962 if (ret < 0) {
(gdb) p ret
$4 = -1
(gdb) p errno
$5 = 22
(gdb) n
963 if (errno == EINTR)
(gdb) 
965 slirp_exit(1);
(gdb) 
[Inferior 1 (process 4349) exited with code 01]

> If you dig in src/main.c there are more lines with timeout.tv_used
> being compared with negative numbers, your patch may work but I think
> it has to be something else.

Yes, I've got another theory now: timeout.tv_usec is a long int of
8 bytes size, but at main.c:935 it gets assigned a 4-byte unsigned:

if ((timeout.tv_usec < 0) || (tmp_time >= 0 && tmp_time < timeout.tv_usec))
timeout.tv_usec = (u_int)tmp_time;

This results in the value of 4294967295 above instead of the expected
-1, so timeout does not get reset to {5, 0} and select() gets the
invalid timeout value, immediately breaking the loop.

> Have you tried just compiling the slirp package? Maybe it's a problem
> with libc6 linking, https://tracker.debian.org/pkg/slirp warns that
> slirp "Fails to build during reproducibility testing". I'm looking
> into this.

Reproducibility probably does not factor into this, but I'll do some
more checks as I get to it.
-- 
Regards,
Feri.

Bug#1043201: slirp: immediate exit at startup

[Ferenc Wágner]

Package: slirp
Severity: important
Tags: patch upstream

Dear Maintainer,

When trying to use slirp with user-mode-linux (eth0=slirp) under Debian
bookworm (amd64), I noticed that as soon as I up the virtual interface,
slirp prints its usual banner and immediately exits with status 1.  The
slirp process started by UML becomes a zombie and there's no network
connectivity.  Some debugging led me to believe that the cause is
signedness difference at src/main.c:955 in the

if (timeout.tv_usec == -1) { ... }

comparison, which makes the condition always false, thus reaching the
select() call with timeout.tv_usec (of unsiged type) set to 0x
(that is -1 converted to unsigned) and thus hitting EINVAL.  Adding an
explicit cast via the below patch helped.  This problem might affect
64-bit architectures only; I tested on amd64.  Please consider fixing
this one way or another.

Thanks,
Feri.

$ cat slirp-1.0.17/debian/patches/018-tv_usec-is-unsigned.patch 
Index: slirp-1.0.17/src/main.c
===
--- slirp-1.0.17.orig/src/main.c2023-08-07 11:49:03.0 +0200
+++ slirp-1.0.17/src/main.c 2023-08-07 11:57:06.850518113 +0200
@@ -859,7 +859,7 @@
 * First, see the timeout needed by *timo
 */
timeout.tv_sec = 0;
-   timeout.tv_usec = -1;
+   timeout.tv_usec = (unsigned)-1;
/*
 * If a slowtimo is needed, set timeout to 500ms from the last
 * slow timeout. If a fast timeout is needed, set timeout within
@@ -952,7 +952,7 @@
 * This will make timings (like idle timer and "wait" timer)
 * up to 10 seconds late, but will be more system friendly
 */
-   if (timeout.tv_usec == -1) {
+   if (timeout.tv_usec == (unsigned)-1) {
timeout.tv_usec = 0;
timeout.tv_sec = 5; /* XXX */
}

Bug#1040165: pacemaker: Migration regression after upgrading bullseye to bookworm

[Ferenc Wágner]

Florent Carli  writes:

> I could not reproduce with the packages you mentionned, so it's a good sign

Hi,

Pacemaker 2.1.5-1+deb12u1 is already available in the
bookworm-proposed-updates archive.  It also contains the two other
patches Ken mentioned [1], please give it some testing if you can.

[1] https://bugs.clusterlabs.org/show_bug.cgi?id=5521#c10.
-- 
Thanks,
Feri.

Bug#1040415: bullseye-pu: package pacemaker/2.1.5-1+deb12u1

[Ferenc Wágner]

"Adam D. Barratt"  writes:

> Assuming that all of the changes are in unstable (or not required
> there), please go ahead.

Hi Adam,

All three patches are cherry-picks (although one required manual
backporting) from 2.1.6, which is already in testing.
Source-only upload done, hope it's all right.
-- 
Thanks,
Feri.

Bug#1040415: bullseye-pu: package pacemaker/2.1.5-1+deb12u1

[Ferenc Wágner]

Control: tag -1 - confirmed

Jonathan Wiltshire  writes:

> On Wed, Jul 05, 2023 at 07:14:09PM +0200, Ferenc Wágner wrote:
>
>> Shortly after the release of bookworm we got a report that Pacemaker
>> regressed in certain migration scenarios when compared to the bullseye
>> version.  Upstream identified the cause (a bug already fixed in 2.1.6),
>> and after backporting the fix the submitter acknowledged that they can't
>> reproduce the bug anymore with the proposed packages.
>> https://bugs.clusterlabs.org/show_bug.cgi?id=5521
>> Pacemaker package bug opened after discussion on the mailing list:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040165
>
> Please go ahead, and bear in mind the upload window closes next weekend.

Thanks, Jonathan!  Does it mean that I have to upload before 15th of July?

On the other hand, meanwhile upstream notified me that to fully fix this
bug I need to backport one more patch, which in turn required including
a third one.  So the debdiff grew a little, please reconfirm the upload:

$ debdiff pacemaker_2.1.5-1.dsc pacemaker_2.1.5-1+deb12u1.dsc
dpkg-source: warning: extracting unsigned source package 
(/home/wferi/ha/pacemaker/pacemaker_2.1.5-1.dsc)
diff -Nru pacemaker-2.1.5/debian/changelog pacemaker-2.1.5/debian/changelog
--- pacemaker-2.1.5/debian/changelog2023-01-22 16:38:34.0 +0100
+++ pacemaker-2.1.5/debian/changelog2023-07-09 23:10:45.0 +0200
@@ -1,3 +1,17 @@
+pacemaker (2.1.5-1+deb12u1) bookworm; urgency=medium
+
+  * [0c22be8] New patches fixing migration regression.
+Backport of https://github.com/ClusterLabs/pacemaker/pull/3020/ to
+Pacemaker 2.1.5 (without the CTS changes, which we don't ship):
+5754a2af9 Refactor: scheduler: improve xpath efficiency when unpacking
+3f6f524f1 Low: scheduler: unknown_on_node() should ignore pending actions
+ad9fd9548 Fix: scheduler: handle cleaned migrate_from history correctly
+The starting refactor is required by the other two patches, but the
+third patch still needed backporting.
+Thanks to Ken Gaillot (Closes: #1040165)
+
+ -- Ferenc Wágner   Sun, 09 Jul 2023 23:10:45 +0200
+
 pacemaker (2.1.5-1) unstable; urgency=medium
 
   * [5792d59] Work around lazy loading of GitHub release pages in watch file
diff -Nru pacemaker-2.1.5/debian/gbp.conf pacemaker-2.1.5/debian/gbp.conf
--- pacemaker-2.1.5/debian/gbp.conf 2023-01-22 13:10:39.0 +0100
+++ pacemaker-2.1.5/debian/gbp.conf 2023-07-09 22:33:06.0 +0200
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/bookworm
 upstream-branch = upstream/latest
 
 [import-orig]
diff -Nru 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
--- 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
  1970-01-01 01:00:00.0 +0100
+++ 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
  2023-07-09 23:07:30.0 +0200
@@ -0,0 +1,30 @@
+From: Ken Gaillot 
+Date: Wed, 1 Feb 2023 17:12:13 -0600
+Subject: Fix: scheduler: handle cleaned migrate_from history correctly
+
+Fixes T623
+---
+ lib/pengine/unpack.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/lib/pengine/unpack.c b/lib/pengine/unpack.c
+index e9fcae1..99a2dc4 100644
+--- a/lib/pengine/unpack.c
 b/lib/pengine/unpack.c
+@@ -2937,6 +2937,16 @@ unpack_migrate_to_success(pe_resource_t *rsc, pe_node_t 
*node, xmlNode *xml_op,
+ }
+ 
+ } else { // Pending, or complete but erased
++
++/* If there is no history at all for the resource on an online 
target, then
++ * it was likely cleaned. Just return, and we'll schedule a probe. 
Once we
++ * have the probe result, it will be reflected in target_newer_state.
++ */
++if ((target_node != NULL) && target_node->details->online
++&& unknown_on_node(rsc, target)) {
++return;
++}
++
+ /* If the resource has newer state on the target, this migrate_to no
+  * longer matters for the target.
+  */
diff -Nru 
pacemaker-2.1.5/debian/patches/Low-scheduler-unknown_on_node-should-ignore-pending-actio.patch
 
pacemaker-2.1.5/debian/patches/Low-scheduler-unknown_on_node-should-ignore-pending-actio.patch
--- 
pacemaker-2.1.5/debian/patches/Low-scheduler-unknown_on_node-should-ignore-pending-actio.patch
  1970-01-01 01:00:00.0 +0100
+++ 
pacemaker-2.1.5/debian/patches/Low-scheduler-unknown_on_node-should-ignore-pending-actio.patch
  2023-07-09 23:07:30.0 +0200
@@ -0,0 +1,80 @@
+From: Ken Gaillot 
+Date: Thu, 2 Feb 2023 10:25:53 -0600
+Subject: Low: scheduler: unknown_on_node() should ignore pending actions
+
+Previously, unknown

Bug#1040415: bullseye-pu: package pacemaker/2.1.5-1+deb12u1

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

Dear Stable Release Team,

[ Reason ]
Shortly after the release of bookworm we got a report that Pacemaker
regressed in certain migration scenarios when compared to the bullseye
version.  Upstream identified the cause (a bug already fixed in 2.1.6),
and after backporting the fix the submitter acknowledged that they can't
reproduce the bug anymore with the proposed packages.
https://bugs.clusterlabs.org/show_bug.cgi?id=5521
Pacemaker package bug opened after discussion on the mailing list:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040165

[ Impact ]
Core HA functionality is impacted, there's no easy way to work around
the problem.  Pacemaker 2.1.5-1 is unsuitable for big portion of its
intended applications.

[ Tests ]
The submitter tested and confirmed the fix.

[ Risks ]
The patch is small but the backport wasn't trivial due to extensive
refactorings meanwhile.  I asked upstream to sanity-check it, but
haven't got a reply yet.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

$ debdiff pacemaker_2.1.5-1.dsc pacemaker_2.1.5-1+deb12u1.dsc
diff -Nru pacemaker-2.1.5/debian/changelog pacemaker-2.1.5/debian/changelog
--- pacemaker-2.1.5/debian/changelog2023-01-22 16:38:34.0 +0100
+++ pacemaker-2.1.5/debian/changelog2023-07-02 21:39:59.0 +0200
@@ -1,3 +1,11 @@
+pacemaker (2.1.5-1+deb12u1) bookworm; urgency=medium
+
+  * [20411a8] New patch: Fix: scheduler: handle cleaned migrate_from history
+correctly.
+Thanks to Ken Gaillot (Closes: #1040165)
+
+ -- Ferenc Wágner   Sun, 02 Jul 2023 21:39:59 +0200
+
 pacemaker (2.1.5-1) unstable; urgency=medium

   * [5792d59] Work around lazy loading of GitHub release pages in watch file
diff -Nru pacemaker-2.1.5/debian/gbp.conf pacemaker-2.1.5/debian/gbp.conf
--- pacemaker-2.1.5/debian/gbp.conf 2023-01-22 13:10:39.0 +0100
+++ pacemaker-2.1.5/debian/gbp.conf 2023-07-02 21:39:59.0 +0200
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/bookworm
 upstream-branch = upstream/latest

 [import-orig]
diff -Nru 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
--- 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
  1970-01-01 01:00:00.0 +0100
+++ 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
  2023-07-02 21:39:59.0 +0200
@@ -0,0 +1,30 @@
+From: Ken Gaillot 
+Date: Wed, 1 Feb 2023 17:12:13 -0600
+Subject: Fix: scheduler: handle cleaned migrate_from history correctly
+
+Fixes T623
+---
+ lib/pengine/unpack.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/lib/pengine/unpack.c b/lib/pengine/unpack.c
+index 5fcba3b..abfd06f 100644
+--- a/lib/pengine/unpack.c
 b/lib/pengine/unpack.c
+@@ -2920,6 +2920,16 @@ unpack_migrate_to_success(pe_resource_t *rsc, pe_node_t 
*node, xmlNode *xml_op,
+ }
+
+ } else { // Pending, or complete but erased
++
++/* If there is no history at all for the resource on an online 
target, then
++ * it was likely cleaned. Just return, and we'll schedule a probe. 
Once we
++ * have the probe result, it will be reflected in target_newer_state.
++ */
++if ((target_node != NULL) && target_node->details->online
++&& unknown_on_node(rsc->id, target, data_set)) {
++return;
++}
++
+ /* If the resource has newer state on the target, this migrate_to no
+  * longer matters for the target.
+  */
diff -Nru pacemaker-2.1.5/debian/patches/series 
pacemaker-2.1.5/debian/patches/series
--- pacemaker-2.1.5/debian/patches/series   2023-01-22 13:31:42.0 
+0100
+++ pacemaker-2.1.5/debian/patches/series   2023-07-02 21:39:59.0 
+0200
@@ -5,3 +5,4 @@
 Shipping-the-CTS-is-not-useful.patch
 Always-run-Inkscape-under-the-C.UTF-8-locale.patch
 Fix-typos-resouce-resource.patch
+Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
diff -Nru pacemaker-2.1.5/debian/salsa-ci.yml 
pacemaker-2.1.5/debian/salsa-ci.yml
--- pacemaker-2.1.5/debian/salsa-ci.yml 2023-01-22 13:10:39.0 +0100
+++ pacemaker-2.1.5/debian/salsa-ci.yml 2023-07-02 21:39:59.0 +0200
@@ -5,6 +5,7 @@

 variables:
   SALSA_CI_REPROTEST_ENABLE_DIFFOSCOPE: 1
+  RELEASE: bookworm

 autopkgtest:
   extends: .test-autopkgtest
-- 
Thanks,
Feri.

Bug#1040165: pacemaker: Migration regression after upgrading bullseye to bookworm

[Ferenc Wágner]

Hi,

I've pushed the proposed backported fix to
https://salsa.debian.org/ha-team/pacemaker/-/commits/wferi/debian/bookworm/,
it would be great if you could test it.  You can download the build
artifacts from https://salsa.debian.org/ha-team/pacemaker/-/pipelines/547159
if you don't want to build the packages yourselves.  If they don't
exhibit the bug, I'll ask for a stable update.
-- 
Regards,
Feri.

Bug#1040165: pacemaker: Migration regression after upgrading bullseye to bookworm

[Ferenc Wágner]

Package: pacemaker
Version: 2.1.5-1
Severity: important
Tags: patch

As reported on the mailing list by Florent Carli 
https://alioth-lists.debian.net/pipermail/debian-ha-maintainers/2023-June/008761.html:

I encountered a regression with pacemaker when upgrading from debian
bullseye to bookworm. First I contacted pacemaker maintainers and I
explained the problematic behavior:
https://bugs.clusterlabs.org/show_bug.cgi?id=5521

But then I tried with pacemaker 2.1.6 (compiled from source) and I could
not reproduce.

Pacemaker maintainers confirmed that: "We did a bunch of other
refactoring related to migrations (including partial migrations) in
preparation for that fix:
https://github.com/ClusterLabs/pacemaker/commits/main?after=44647f62c012f4305bf5d2e03cfde89356d831bd+34=main%5B%5D=lib%5B%5D=pengine%5B%5D=unpack.c_name=refs%2Fheads%2Fmain;

So I'm now turning to you, hoping you will consider upgrading pacemaker
package in debian stable to 2.1.6.

As added later by Yoann CONGAL :

>From one of the pacemaker authors the precise fix seems to be
https://github.com/ClusterLabs/pacemaker/commit/ad9fd9548f02a38885fa36765af9742a5a88576e
But this is based on a bunch of refactoring so this patch does not
apply on the 2.1.5 debian branch :(

Reproducing this bug should be simple :
* 3 node cluster (node1, node2, node3)
* a VirtualDomain resource (debian1)
* debian1 has a location constraint on node2
* Gracefully shutdown pacemaker service on node2 (debian1 moves away
e.g. to node1)
* Restart pacemaker service on node2

Here, debian1 should cleanly migrate back to node2 but this migration fails :
* There is no migrate_to task generated in node1
* migrate_from task on node2 timeouts
* debian1 get restarted by a "forced recovery"

Bug#848972: Fixed in Ubuntu

[Ferenc Wágner]

Control: tag + patch

Hi,

This issue was fixed in 1.178ubuntu12, as detailed at
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1824227
Please consider taking over the fix.
-- 
Thanks,
Feri.

Bug#1037948: xmltooling: Parsing of KeyInfo elements can cause remote resource access

[Ferenc Wágner]

Source: xmltooling
Severity: important
Tags: patch upstream security

Shibboleth Service Provider Security Advisory [12 June 2023]

An updated version of the XMLTooling library that is part of the
OpenSAML and Shibboleth Service Provider software is now available
which corrects a server-side request forgery (SSRF) vulnerability.

Parsing of KeyInfo elements can cause remote resource access.
=
Including certain legal but "malicious in intent" content in the
KeyInfo element defined by the XML Signature standard will result
in attempts by the SP's shibd process to dereference untrusted
URLs.

While the content of the URL must be supplied within the message
and does not include any SP internal state or dynamic content,
there is at minimum a risk of denial of service, and the attack
could be combined with others to create more serious vulnerabilities
in the future.

This issue is *not* specific to the V3 XMLTooling software and is
believed to impact all versions prior to V3.2.4.

Recommendations
===
Update to V3.2.4 or later of the XMLTooling library, which is
now available. Note that on Linux and similar platforms, upgrading
this component will require restarting the shibd process to correct
the bug.

The updated version of the library has been included in a V3.4.1.3
patch release of the Service Provider software on Windows.

Other Notes
===
The xmltooling git commit containing the fix for this issue is
6080f6343f98fec085bc0fd746913ee418cc9d30 and may be in general terms
applicable to V2 of the library.

Credits
===
Juriën de Jong, an independent security researcher in the Netherlands

URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20230612.txt

Bug#1034041: Should firmware-amd-graphics be automatically installed?

[Ferenc Wágner]

Cyril Brulebois  writes:

> I'm implying that installation images produced by debian-cd (and available
> on cdimage.d.o) should have firmware packages available and ready to deploy,
> and should do that automatically; while netboot images (produced by the
> debian-installer build system) don't, and won't be able to deploy firmware
> packages unless tweaked beforehand via the procedure documented on that
> page.

Yes, that'f perfectly fine.  My question was whether the relavant
firmware packages should be present on the installed system even if the
installer itself did not use/load them.  The netboot installer installs
everything from the network after all, so it could install firmware
packages just as it installs desktop packages for example.  Apparently
it does not, which is fine again, but I wasn't certain of the intent.
-- 
Cheers,
Feri.

Bug#1034041: Should firmware-amd-graphics be automatically installed?

[Ferenc Wágner]

Cyril Brulebois  writes:

> Ferenc Wágner  (2023-05-22):
>> Cyril Brulebois  writes:
>> > Which installer did you use?
>> 
>> Its lsb-release says:
>> 
>> DISTRIB_ID=Debian
>> DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
>> DISTRIB_RELEASE="12 (bookworm) - installer build 20230401"
>> X_INSTALLATION_MEDIUM=netboot
>> 
>> so it must have been bookworm RC 1.  The date was 22nd of April.  I
>> started the kernel+initrd.gz from GRUB.
>
> In other words you were also using netboot.
>
> https://wiki.debian.org/DebianInstaller/NetbootFirmware should have
> details about how to deal with firmware when netbooting. It's been there
> since ~ forever, and has been updated for Bookworm.

Thanks for the pointer.  Are you implying that if some firmware isn't
loaded during installation, it isn't expected to be present on the
installed system either?  If so, then it worked for me as intended.
(Actually, my Ethernet driver also tries to load some Realtek firmware,
but apparenetly works just fine without it, so I only installed it later
to reduce warnings from update-initramfs.  The graphics firmware was a
must for desktop usage, though.)
-- 
Thanks,
Feri.

Bug#1034041: Should firmware-amd-graphics be automatically installed?

[Ferenc Wágner]

Cyril Brulebois  writes:

> Ferenc Wágner  (2023-05-22):
>
>> I had a similar experience with a desktop system containing a Radeon
>> RX470 graphics card.  The text-based installation went all right and
>> then even the Gnome desktop opened after reboot, but it ran in a
>> low-resolution mode until I manually installed firmware-amd-graphics
>> (the non-free-firmware archive component was already enabled).
>> 
>> Is this the intended behaviour?
>
> Which installer did you use?

Its lsb-release says:

DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230401"
X_INSTALLATION_MEDIUM=netboot

so it must have been bookworm RC 1.  The date was 22nd of April.  I
started the kernel+initrd.gz from GRUB.
-- 
Feri.

Bug#1034041: Should firmware-amd-graphics be automatically installed?

[Ferenc Wágner]

Hi,

I had a similar experience with a desktop system containing a Radeon
RX470 graphics card.  The text-based installation went all right and
then even the Gnome desktop opened after reboot, but it ran in a
low-resolution mode until I manually installed firmware-amd-graphics
(the non-free-firmware archive component was already enabled).

Is this the intended behaviour?
-- 
Thanks,
Feri.

Bug#919724: cxxtest: git snapshot breaks compatibility with official release

[Ferenc Wágner]

b...@debian.org writes:

> cxxtest has historically a limitation with
> TS_ASSERT_EQUALS/TS_ASSERT_DIFFERS, which validates the following test:
>
>     char str[] = "toto";
>     char* str2 = strdup(str);
>     TS_ASSERT_EQUALS(str, str2);
>     TS_ASSERT_DIFFERS(str, str2);
>
> With the new Git snapshot, this test now does not pass.
> Whether this is a sensible result or not, this breaks existing
> testsuites, AFAICS without notice from the package or the maintainer
> (the ChangeLog is still from 4.4), nor a way to determine the cxxtest
> variant (release/snapshot) installed by the end user.
>
> Could you document the reason why Debian ships a Git snapshot rather
> than an official release?

Hi,

I'm not the maintainer of cxxtest, but I guess one reason for shipping
this Git snapshot is that the above bug is fixed here, see
https://github.com/CxxTest/cxxtest/issues/122 and the corresponding pull
request: https://github.com/CxxTest/cxxtest/pull/123.  Unfortunately
there was no release (or any activity) since that merge.

> In addition, do you think it is better to revert the Debian version,
> document this behavior change, or check with upstream how to implement
> an upgrade plan?

>From the linked issue it seems pretty clear that upstream considers the
EQUALS/DIFFERS inconsistency a bug, so test suites depending on it
should be fixed.  At least that's my interpretation.
-- 
Regards,
Feri.

Bug#1031823: socat: lots of self tests skipped due to missing utilities

[Ferenc Wágner]

Package: socat
Version: 1.7.4.1-3
Severity: wishlist

Dear Maintainer,

The buildd logs show lots of skipped tests, for example:

test  43 LISTEN_PF_IP4: pf=4 overrides option -6 on listen... TCP4 not available
test  44 LISTEN_PF_IP6: pf=6 overrides option -4 on listen... TCP4 not available

These are skipped because the ping utility is not found.

Then there is:

test 230 UDP4LISTEN_SIGCHLD: test if UDP4-LISTEN child becomes zombie... 
./test.sh: line 1908: ps: command not found
OK
test 231 UDP4RECVFROM_SIGCHLD: test if UDP4-RECVFROM child becomes zombie... 
./test.sh: line 1908: ps: command not found
OK

which is broken, but clearly misses the ps utility.

There may be other offenders, but please consider adding iputils-ping
and procps to the Build-Deps as a first step.  It won't be enough in
itself, because this reveals four failing tests: 216 309 310 399, so
extending 08-test.sh-fixes.patch will be necessary as well (if fixing
the actual problems is unfeasible).
-- 
Thanks,
Feri.

Bug#1031292: lvm2: Please ship the lvmautoactivation man page

[Ferenc Wágner]

Package: lvm2
Version: 2.03.11-2.1
Severity: normal

Dear Maintainer,

The lvmautoactivation(7) man page is missing from the lvm2 binary
package.  Please consider looking for other possible omissions as well.
-- 
Thanks,
Feri.

Bug#1029566: transition: shibboleth-sp

[Ferenc Wágner]

Ferenc Wágner  writes:

> Sebastian Ramacher  writes:
>
>> ACK, please go ahead.
>
> Great, shibboleth-sp was uploaded and is already fully green in the
> transition tracker.  Please schedule the binNMUs for
> shibboleth-resolver.

Hi,

The transition tracker is already all green.
-- 
Thanks for your help!
Feri.

Bug#1029566: transition: shibboleth-sp

[Ferenc Wágner]

Sebastian Ramacher  writes:

> ACK, please go ahead.

Great, shibboleth-sp was uploaded and is already fully green in the
transition tracker.  Please schedule the binNMUs for
shibboleth-resolver.
-- 
Thanks,
Feri.

Bug#1029566: transition: shibboleth-sp

[Ferenc Wágner]

control: tags -1 - moreinfo

Sebastian Ramacher  writes:

> On 2023-01-24 17:17:36 +0100, Ferenc Wágner wrote:
>
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> 
>> When reporting #1028286 (transition: xml-security-c) I totally missed
>> that one of the mentioned planned upper layer uploads is the
>> shibboleth-sp 3.3 -> 3.4 upgrade, which, contrary to the xml-security-c
>> transition, actually entails an SONAME change.  Since this wasn't
>> explicit in the original bug, we decided to ask for your ACK again.
>> As you can see in the autogenerated tracker at
>> https://release.debian.org/transitions/html/auto-shibboleth-sp.html,
>> there are only two reverse dependencies, both of which are internal to
>> the Shibboleth ecosystem (thus maintained by us) and both build without
>> changes against shibboleth-sp 3.4.1+dfsg-1.
>
> What would be the consequences of postponing this transition to trixie?

There are no significant functional changes in this transition.  Our
main reason for proposing it is to ship bookworm with the "current
stable release" as much as possible, because upstream provides security
support for the latest two stable releases only [1], and Shibboleth,
being security software, heavily depends on being patched in a timely
manner to stay useful.  While upstream actively works with us on
preparing updates during the embargo periods, this may not be enough if
we have to backport the fixes ourselves, so we strive to minimize such
exposure.  Since this transition affects only two packages, which we
need to rebuild anyway, we'd welcome the additional safety this upgrade
would mean in providing security support for bookworm.

[1] 
https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/1134625008/ProductVersioning
-- 
Best regards,
Feri.

Bug#1029566: transition: shibboleth-sp

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

When reporting #1028286 (transition: xml-security-c) I totally missed
that one of the mentioned planned upper layer uploads is the
shibboleth-sp 3.3 -> 3.4 upgrade, which, contrary to the xml-security-c
transition, actually entails an SONAME change.  Since this wasn't
explicit in the original bug, we decided to ask for your ACK again.
As you can see in the autogenerated tracker at
https://release.debian.org/transitions/html/auto-shibboleth-sp.html,
there are only two reverse dependencies, both of which are internal to
the Shibboleth ecosystem (thus maintained by us) and both build without
changes against shibboleth-sp 3.4.1+dfsg-1.

Ben file:

title = "shibboleth-sp";
is_affected = .depends ~ "libshibsp10" | .depends ~ "libshibsp11";
is_good = .depends ~ "libshibsp11";
is_bad = .depends ~ "libshibsp10";

Bug#1028286: transition: xml-security-c

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

In a recent message [1] Shibboleth upstream strongly recommended
building xml-security-c without Xalan support to reduce the attack
surface of Shibboleth installations, because Xalan is dead upstream and
pulling it in carries a considerable risk.  The Shibboleth stack is the
only consumer of the xml-security-c library in Debian, so we'd like to
follow upstream's recommendation.  This means flipping a configure
switch, which removes some features (and a dependency) of the library,
but does not change the library SONAME.  The resulting new library
version is usable as-is by the upper layers of Shibboleth stack, which
does not use the dropped functionality, so this wouldn't be a transition
in that sense, but we (the Shibboleth packaging team) still wanted to
run this by you.  We don't expect any fallout, xml-security-c was built
without Xalan until version 2.0.2-2 without issues.  Some maintenance
uploads of the upper layers were planned and will be done anyway.

[1] 
https://alioth-lists.debian.net/pipermail/pkg-shibboleth-devel/2023-January/005929.html

Unusable Ben file:

title = "xml-security-c";
is_affected = .depends ~ "libxml-security-c20" | .depends ~ 
"libxml-security-c20";
is_good = .depends ~ "libxml-security-c20";
is_bad = .depends ~ "libxml-security-c20";

Bug#987941: buster-pu: package pacemaker/2.0.1-5+deb10u2

[Ferenc Wágner]

"Adam D. Barratt"  writes:

> I'm not hugely happy that this has ended up not being in stretch, to
> be quite honest.

Agreed.  I was pushing for it in vain, unfortunately.

> We're in the process of organising the final point release for buster,
> as support for it moves over to the LTS team, so please go ahead.

Uploaded.

> +A new upstream release instroduced as security update 1.1.24-
> 0+deb9u1 in
>
> s/instroduced/introduced/

With this fix included.
-- 
Thanks,
Feri

Bug#1012717: Have you got an ETA?

[Ferenc Wágner]

Wow...  Thanks, Guido!  :)
-- 
Best regards,
Feri

Bug#1012717: Have you got an ETA?

[Ferenc Wágner]

Hi Guido!

Hope you're doing fine.  Have you got any plans for the next GBP PyPI
release yet?  I understand there're only two patches committed since
0.9.27 and I don't want to hurry you, just need to plan an immediate way
forward, because this bug breaks our automated workflow.  "Don't expect
anything until after Debconf at least" would be a perfectly fine answer,
I'd just rather not make a mess for no reason.
-- 
Thanks,
Feri

Bug#1006581: xmltooling: FTBFS with OpenSSL 3.0

[Ferenc Wágner]

Sebastian Andrzej Siewior  writes:

> Your package is failing to build using OpenSSL 3.0 with the
> following error:
>
> | make[5]: Entering directory '/<>/xmltoolingtest'
> | ../build-aux/test-driver: line 112: 1662259 Segmentation fault  "$@" >> 
> "$log_file" 2>&1
> | FAIL: xmltoolingtest

Hi,

I suspect that this stems from an OpenSSL version mismatch among the
dependencies (xml-security-c or cURL, which both use OpenSSL themselves)
and XMLTooling itself.  Or did you rebuild those with OpenSSL 3 before
testing XMLTooling?  Speaking of this, do you plan to finish the OpenSSL
transition before bookworm is frozen?
-- 
Thanks,
Feri

Bug#996394: cxxtest: shaky equality tests emit Python SyntaxWarnings (already on install)

[Ferenc Wágner]

Package: cxxtest
Version: 4.4+git171022-2

Dear Maintainer,

# apt install cxxtest
[...]
Setting up python3.9 (3.9.7-4) ...
Setting up python3 (3.9.2-3) ...
running python rtupdate hooks for python3.9...
/usr/share/cxxtest/cxxtest/cxx_parser.py:2090: SyntaxWarning: "is" with a 
literal. Did you mean "=="?
  if p.type is "":
/usr/share/cxxtest/cxxtest/cxxtest_parser.py:39: SyntaxWarning: "is" with a 
literal. Did you mean "=="?
  if len(suites) is 0 and not options.root:
/usr/share/cxxtest/cxxtest/cxxtest_parser.py:236: SyntaxWarning: "is not" with 
a literal. Did you mean "!="?
  if len(suite['tests']) is not 0:
running python post-rtupdate hooks for python3.9...
Setting up python3-ply (3.11-4) ...
Setting up cxxtest (4.4+git171022-2) ...
/usr/share/cxxtest/cxxtest/cxx_parser.py:2090: SyntaxWarning: "is" with a 
literal. Did you mean "=="?
  if p.type is "":
/usr/share/cxxtest/cxxtest/cxxtest_parser.py:39: SyntaxWarning: "is" with a 
literal. Did you mean "=="?
  if len(suites) is 0 and not options.root:
/usr/share/cxxtest/cxxtest/cxxtest_parser.py:236: SyntaxWarning: "is not" with 
a literal. Did you mean "!="?
  if len(suite['tests']) is not 0:
[...]

Since Python 3.8 such tests produce these warnings.  In my opinion these
warnings are legit, even though with the current implementation the code
works correctly as-is, because the empty string and the zero integer
happen to be interned automatically.  Please consider applying a small
patch as recommended by the warnings to get rid of them and to increase
code correctness.
-- 
Thanks,
Feri.

Bug#995569: debhelper: act on service files placed in usr/lib/systemd/system

[Ferenc Wágner]

Package: debhelper
Version: 13.5.2
Severity: normal

Dear Maintainer,

If some upstream install procedure places service files under
/usr/lib/systemd/system, dh_installsystemd won't notice those in
debian/tmp during package build, thus such units won't be enabled and
started on the installation of the resulting package.

I think this could (and should) be done irrespective of the usrmerge
transition and whether maintainer-provided unit files are installed into
/usr/lib or /lib, because this has little chance to change anything
automatically (unless some packages have been shipping unit files under
/usr/lib with the very purpose of not activating and starting them).
-- 
Thanks for your consideration,
Feri.

Bug#987941: buster-pu: package pacemaker/2.0.1-5+deb10u2

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear Stable Release Team,

The latest stretch security upgrade broke the upgrade path to buster.
Since fixing that in stretch didn't get any traction (#981088), we have
to fix this in buster, as put forward by Andreas Beckmann:

$ debdiff pacemaker_2.0.1-5+deb10u1.dsc pacemaker_2.0.1-5+deb10u2.dsc
diff -Nru pacemaker-2.0.1/debian/changelog pacemaker-2.0.1/debian/changelog
--- pacemaker-2.0.1/debian/changelog2020-11-07 20:21:48.0 +0100
+++ pacemaker-2.0.1/debian/changelog2021-03-28 03:21:46.0 +0200
@@ -1,3 +1,14 @@
+pacemaker (2.0.1-5+deb10u2) buster; urgency=medium
+
+  [ Andreas Beckmann ]
+  * [1088b23] pacemaker-resource-agents: Bump Breaks+Replaces: pacemaker to 
(<< 2)
+A new upstream release instroduced as security update 1.1.24-0+deb9u1 in
+stretch added the new file /usr/lib/ocf/resource.d/pacemaker/ifspeed to
+pacemaker, while it resides in pacemaker-resource-agents in buster.
+(Closes: #985173)
+
+ -- Ferenc Wágner   Sun, 28 Mar 2021 03:21:46 +0200
+
 pacemaker (2.0.1-5+deb10u1) buster-security; urgency=high

   * [bf23450] Apply patch series fixing CVE-2020-25654: ACL bypass.
diff -Nru pacemaker-2.0.1/debian/control pacemaker-2.0.1/debian/control
--- pacemaker-2.0.1/debian/control  2020-11-07 20:21:48.0 +0100
+++ pacemaker-2.0.1/debian/control  2021-03-28 03:19:48.0 +0200
@@ -84,9 +84,9 @@
  ${misc:Depends},
 # split out of pacemaker so that pacemaker-remote can also use them:
 Breaks:
- pacemaker (<< 1.1.14-2~),
+ pacemaker (<< 2),
 Replaces:
- pacemaker (<< 1.1.14-2~),
+ pacemaker (<< 2),
 Description: cluster resource manager general resource agents
  ${S:X-Common-Description}
  .

I'm ready to upload if you agree.
-- 
Thanks,
Feri.

Bug#987662: unblock: shibboleth-sp/3.2.2+dfsg1-1

[Ferenc Wágner]

(m4)
diff -Nru shibboleth-sp-3.2.1+dfsg1/config_win32.h 
shibboleth-sp-3.2.2+dfsg1/config_win32.h
--- shibboleth-sp-3.2.1+dfsg1/config_win32.h2021-03-16 14:33:45.0 
+0100
+++ shibboleth-sp-3.2.2+dfsg1/config_win32.h2021-04-23 00:18:15.0 
+0200
@@ -121,13 +121,13 @@
 #define PACKAGE_NAME "shibboleth"
 
 /* Define to the full name and version of this package. */
-#define PACKAGE_STRING "shibboleth 3.2.1"
+#define PACKAGE_STRING "shibboleth 3.2.2"
 
 /* Define to the one symbol short name of this package. */
 #define PACKAGE_TARNAME "shibboleth-sp"
 
 /* Define to the version of this package. */
-#define PACKAGE_VERSION "3.2.1"
+#define PACKAGE_VERSION "3.2.2"
 
 /* Define to the necessary symbol if this constant uses a non-standard name on
your system. */
@@ -140,7 +140,7 @@
 /* #undef TM_IN_SYS_TIME */
 
 /* Version number of package */
-#define VERSION "3.2.1"
+#define VERSION "3.2.2"
 
 /* Define to empty if `const' does not conform to ANSI C. */
 /* #undef const */
diff -Nru shibboleth-sp-3.2.1+dfsg1/debian/changelog 
shibboleth-sp-3.2.2+dfsg1/debian/changelog
--- shibboleth-sp-3.2.1+dfsg1/debian/changelog  2021-03-17 14:29:08.0 
+0100
+++ shibboleth-sp-3.2.2+dfsg1/debian/changelog  2021-04-27 12:11:06.0 
+0200
@@ -1,3 +1,20 @@
+shibboleth-sp (3.2.2+dfsg1-1) unstable; urgency=high
+
+  * [e44283d] New upstream release: 3.2.2
+High urgency because it fixes CVE-2021-31826:
+Session recovery feature contains a null pointer dereference
+The cookie-based session recovery feature added in V3.0 contains a
+flaw that is exploitable on systems *not* using the feature if a
+specially crafted cookie is supplied.
+This manifests as a crash in the shibd daemon.
+Because it is very simple to trigger this condition remotely, it
+results in a potential denial of service condition exploitable by
+a remote, unauthenticated attacker.
+Thanks to Scott Cantor (Closes: #987608)
+  * [3a6ac33] Refresh our patches
+
+ -- Ferenc Wágner   Tue, 27 Apr 2021 12:11:06 +0200
+
 shibboleth-sp (3.2.1+dfsg1-1) unstable; urgency=high
 
   * [4ecfe4a] New upstream release: 3.2.1
diff -Nru 
shibboleth-sp-3.2.1+dfsg1/debian/patches/Clean-up-cxxtest-configuration.patch 
shibboleth-sp-3.2.2+dfsg1/debian/patches/Clean-up-cxxtest-configuration.patch
--- 
shibboleth-sp-3.2.1+dfsg1/debian/patches/Clean-up-cxxtest-configuration.patch   
2021-03-17 14:26:00.0 +0100
+++ 
shibboleth-sp-3.2.2+dfsg1/debian/patches/Clean-up-cxxtest-configuration.patch   
2021-04-27 12:06:29.0 +0200
@@ -9,7 +9,7 @@
  1 file changed, 5 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index ddae588..ceb34a3 100644
+index 57dd2c0..7690d8c 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -940,15 +940,10 @@ AM_CONDITIONAL([GSSAPI_NAMINGEXTS],[test 
"x$ac_cv_have_decl_gss_get_name_attribu
diff -Nru 
shibboleth-sp-3.2.1+dfsg1/debian/patches/Use-runstatedir-from-future-Autoconf-2.70.patch
 
shibboleth-sp-3.2.2+dfsg1/debian/patches/Use-runstatedir-from-future-Autoconf-2.70.patch
--- 
shibboleth-sp-3.2.1+dfsg1/debian/patches/Use-runstatedir-from-future-Autoconf-2.70.patch
2021-03-17 14:26:00.0 +0100
+++ 
shibboleth-sp-3.2.2+dfsg1/debian/patches/Use-runstatedir-from-future-Autoconf-2.70.patch
2021-04-27 12:06:29.0 +0200
@@ -37,7 +37,7 @@
  
  # If $DAEMON_USER is set, try to run shibd as that user.  However,
 diff --git a/shibsp/Makefile.am b/shibsp/Makefile.am
-index 9176c17..0dd24cb 100644
+index c3490e0..466c699 100644
 --- a/shibsp/Makefile.am
 +++ b/shibsp/Makefile.am
 @@ -282,7 +282,7 @@ libshibsp_lite_la_LIBADD = \
diff -Nru shibboleth-sp-3.2.1+dfsg1/shibboleth.spec.in 
shibboleth-sp-3.2.2+dfsg1/shibboleth.spec.in
--- shibboleth-sp-3.2.1+dfsg1/shibboleth.spec.in2020-12-15 
04:00:19.0 +0100
+++ shibboleth-sp-3.2.2+dfsg1/shibboleth.spec.in2021-04-23 
00:18:15.0 +0200
@@ -93,8 +93,8 @@
 Obsoletes: shibboleth-sp-devel = 2.5.0
 Requires:  libxerces-c-devel >= 3.2
 Requires:  libxml-security-c-devel >= 2.0.0
-Requires:  libxmltooling-devel >= 3.1.0
-Requires:  libsaml-devel >= 3.1.0
+Requires:  libxmltooling-devel >= 3.2.0
+Requires:  libsaml-devel >= 3.2.0
 %{?_with_log4cpp:Requires: liblog4cpp-devel >= 1.0}
 %{!?_with_log4cpp:Requires: liblog4shib-devel >= 2}
 
@@ -481,6 +481,9 @@
 %doc %{pkgdocdir}/api
 
 %changelog
+* Thu Apr 22 2021 Scott Cantor  - 3.2.2-1
+- Fix devel dependency versions
+
 * Tue Dec 1 2020 Scott Cantor  - 3.2.0-1
 - Version and lib bump
 
diff -Nru shibboleth-sp-3.2.1+dfsg1/shibsp/handler/impl/SAML2Logout.cpp 
shibboleth-sp-3.2.2+dfsg1/shibsp/handler/impl/SAML2Logout.cpp
--- shibboleth-sp-3.2.1+dfsg1/shibsp/handler/impl/SAML2Logout.cpp   
2020-03-18 19:45:13.0 +0100
+++ shibboleth-sp-3.2.2+dfsg1/shibsp/handler/impl/SAML2Logout.cpp   
2

Bug#987608: shibboleth-sp: Session recovery feature contains a null pointer deference

[Ferenc Wágner]

Source: shibboleth-sp
Version: 3.0.2+dfsg1-1
Severity: important
Tags: upstream patch security
Forwarded: https://issues.shibboleth.net/jira/browse/SSPCPP-927

Shibboleth Service Provider Security Advisory [26 April 2021]

An updated version of the Service Provider software is now
available which corrects a denial of service vulnerability.

Session recovery feature contains a null pointer deference
==
The cookie-based session recovery feature added in V3.0 contains a
flaw that is exploitable on systems *not* using the feature if a
specially crafted cookie is supplied.

This manifests as a crash in the shibd daemon/service process.

Because it is very simple to trigger this condition remotely, it
results in a potential denial of service condition exploitable by
a remote, unauthenticated attacker.

Versions without this feature (prior to V3.0) are not vulnerable
to this particular issue.

Recommendations
===
Update to V3.2.2 or later of the Service Provider software, which
is now available.

In cases where this is not immediately possible, configuring a
DataSealer component in shibboleth2.xml (even if used for nothing)
will work around the vulnerability.

For example:



This workaround is only possible after having updated the
core configuration to the V3 XML namespace.

Other Notes
===
The cpp-sp git commit containing the fix for this issue is
5a47c3b9378f4c49392dd4d15189b70956f9f2ec


URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20210426.txt

Bug#986325: corosync: crash with compression enabled

[Ferenc Wágner]

Package: corosync
Version: 3.1.0-3
Severity: normal
Tags: patch upstream
Forwarded: https://github.com/corosync/corosync/issues/630

As reported by Lukey3332:

Sometimes corosync crashes at startup, but only if compression is enabled.

Distribution: Debian Bullseye

Corosync version:

Corosync Cluster Engine, version '3.1.0'
Copyright (c) 2006-2018 Red Hat, Inc.

Kronosnet version:

Package: libknet1
Source: kronosnet
Version: 1.20-4

Here is a backtrace:

#0  __GI___pthread_mutex_lock (mutex=mutex@entry=0x58619958) at 
../nptl/pthread_mutex_lock.c:67
#1  0x77e6c728 in pmtud_reschedule (knet_h=0x55577320 
<_logsys_log_printf>, knet_h@entry=0x58619958) at threads_common.c:42
#2  get_global_wrlock (knet_h=knet_h@entry=0x55577320 <_logsys_log_printf>) 
at threads_common.c:61
#3  0x77e64316 in knet_handle_compress (knet_h=0x55577320 
<_logsys_log_printf>, knet_handle_compress_cfg=0x7fffcea0) at compress.c:503
#4  0x5559ae8f in totemknet_configure_compression 
(knet_context=knet_context@entry=0x5574d900, 
totem_config=totem_config@entry=0x7fffd310) at totemknet.c:1565
#5  0x5559c104 in totemknet_initialize (poll_handle=0x556ddd30, 
knet_context=0x5574d900, totem_config=0x7fffd310, stats=, context=0x556eed20,
deliver_fn=0x5558c810 , iface_change_fn=0x5558d9c0 
, mtu_changed=0x5558c290 , 
target_set_completed=0x5558ddd0 )
at totemknet.c:1149
#6  0x55588550 in totemnet_initialize 
(loop_pt=loop_pt@entry=0x556ddd30, 
net_context=net_context@entry=0x557026f8, 
totem_config=totem_config@entry=0x7fffd310, stats=0x55702728,
context=context@entry=0x556eed20, 
deliver_fn=deliver_fn@entry=0x5558c810 , 
iface_change_fn=0x5558d9c0 , 
mtu_changed=0x5558c290 ,
target_set_completed=0x5558ddd0 ) at 
totemnet.c:343
#7  0x5559541a in totemsrp_initialize 
(poll_handle=poll_handle@entry=0x556ddd30, 
srp_context=srp_context@entry=0x556760f0 , 
totem_config=totem_config@entry=0x7fffd310,
stats=stats@entry=0x556760c0 , 
deliver_fn=deliver_fn@entry=0x555970b0 , 
confchg_fn=confchg_fn@entry=0x555965a0 ,
waiting_trans_ack_cb_fn=0x55596560 ) at 
totemsrp.c:981
#8  0x55597c28 in totempg_initialize (poll_handle=0x556ddd30, 
totem_config=totem_config@entry=0x7fffd310) at totempg.c:824
#9  0xe0de in main (argc=-11504, argv=, 
envp=) at main.c:1526

corosync.conf:

# Please read the corosync.conf.5 manual page
totem {
version: 2

cluster_name: tele-clu

key: 
crypto_cipher: aes256
crypto_hash: sha256

knet_compression_model: zlib
knet_compression_level: 6

link_mode: passive

interface {
linknumber: 0
knet_link_priority: 1
}

interface {
linknumber: 1
knet_link_priority: 0
}
token: 5000
}

logging {
# Log the source file and line where messages are being
# generated. When in doubt, leave off. Potentially useful for
# debugging.
fileline: off
# Log to standard error. When in doubt, set to yes. Useful when
# running in the foreground (when invoking "corosync -f")
to_stderr: yes
# Log to a log file. When set to "no", the "logfile" option
# must not be set.
to_logfile: yes
logfile: /var/log/corosync/corosync.log
# Log to the system log daemon. When in doubt, set to yes.
to_syslog: yes
# Log debug messages (very verbose). When in doubt, leave off.
debug: off
# Log messages with time stamps. When in doubt, set to hires (or on)
#timestamp: hires
logger_subsys {
subsys: QUORUM
debug: off
}
}

quorum {
# Enable and configure quorum subsystem (default: off)
# see also corosync.conf.5 and votequorum.5
provider: corosync_votequorum
}

nodelist {

node {
# Hostname of the node
name: tele-clu-01
# Cluster membership node identifier
nodeid: 1

ring0_addr: 192.168.233.1
ring1_addr: 192.168.178.241
}
node {
# Hostname of the node
name: tele-clu-02
# Cluster membership node identifier
nodeid: 2

ring0_addr: 192.168.233.2
ring1_addr: 192.168.178.242
}
node {
# Hostname of the node
name: tele-clu-03
# Cluster membership node identifier
nodeid: 3

ring0_addr: 192.168.233.6
ring1_addr: 192.168.178.243
}
}

--
As commented by fabbione:

It turns out the issue is in corosync configuration handling when doing 

Bug#985772: unblock: shibboleth-sp/3.2.1+dfsg1-1

[Ferenc Wágner]

 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -3540,7 +3540,7 @@
 
 # Define the identity of the package.
  PACKAGE='shibboleth-sp'
- VERSION='3.2.0'
+ VERSION='3.2.1'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -24274,7 +24274,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by shibboleth $as_me 3.2.0, which was
+This file was extended by shibboleth $as_me 3.2.1, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -24340,7 +24340,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-shibboleth config.status 3.2.0
+shibboleth config.status 3.2.1
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru shibboleth-sp-3.2.0+dfsg1/configure.ac 
shibboleth-sp-3.2.1+dfsg1/configure.ac
--- shibboleth-sp-3.2.0+dfsg1/configure.ac  2020-12-08 16:33:28.0 
+0100
+++ shibboleth-sp-3.2.1+dfsg1/configure.ac  2021-03-16 14:33:31.0 
+0100
@@ -1,5 +1,5 @@
 AC_PREREQ([2.50])
-AC_INIT([shibboleth],[3.2.0],[https://issues.shibboleth.net/],[shibboleth-sp])
+AC_INIT([shibboleth],[3.2.1],[https://issues.shibboleth.net/],[shibboleth-sp])
 AC_CONFIG_SRCDIR(shibsp)
 AC_CONFIG_AUX_DIR(build-aux)
 AC_CONFIG_MACRO_DIR(m4)
diff -Nru shibboleth-sp-3.2.0+dfsg1/config_win32.h 
shibboleth-sp-3.2.1+dfsg1/config_win32.h
--- shibboleth-sp-3.2.0+dfsg1/config_win32.h2020-12-07 21:51:12.0 
+0100
+++ shibboleth-sp-3.2.1+dfsg1/config_win32.h2021-03-16 14:33:45.0 
+0100
@@ -121,13 +121,13 @@
 #define PACKAGE_NAME "shibboleth"
 
 /* Define to the full name and version of this package. */
-#define PACKAGE_STRING "shibboleth 3.2.0"
+#define PACKAGE_STRING "shibboleth 3.2.1"
 
 /* Define to the one symbol short name of this package. */
 #define PACKAGE_TARNAME "shibboleth-sp"
 
 /* Define to the version of this package. */
-#define PACKAGE_VERSION "3.2.0"
+#define PACKAGE_VERSION "3.2.1"
 
 /* Define to the necessary symbol if this constant uses a non-standard name on
your system. */
@@ -140,7 +140,7 @@
 /* #undef TM_IN_SYS_TIME */
 
 /* Version number of package */
-#define VERSION "3.2.0"
+#define VERSION "3.2.1"
 
 /* Define to empty if `const' does not conform to ANSI C. */
 /* #undef const */
diff -Nru shibboleth-sp-3.2.0+dfsg1/debian/changelog 
shibboleth-sp-3.2.1+dfsg1/debian/changelog
--- shibboleth-sp-3.2.0+dfsg1/debian/changelog  2021-01-06 14:18:54.0 
+0100
+++ shibboleth-sp-3.2.1+dfsg1/debian/changelog  2021-03-17 14:29:08.0 
+0100
@@ -1,3 +1,12 @@
+shibboleth-sp (3.2.1+dfsg1-1) unstable; urgency=high
+
+  * [4ecfe4a] New upstream release: 3.2.1
+High urgency because it contains the fix for the phishing vulnerability
+https://shibboleth.net/community/advisories/secadv_20210317.txt.
+  * [80b3470] Refresh our patches
+
+ -- Ferenc Wágner   Wed, 17 Mar 2021 14:29:08 +0100
+
 shibboleth-sp (3.2.0+dfsg1-2) unstable; urgency=medium
 
   * [84158eb] Revert "New patch: Require XMLTooling and OpenSAML 3.2 via pkg
diff -Nru 
shibboleth-sp-3.2.0+dfsg1/debian/patches/Clean-up-cxxtest-configuration.patch 
shibboleth-sp-3.2.1+dfsg1/debian/patches/Clean-up-cxxtest-configuration.patch
--- 
shibboleth-sp-3.2.0+dfsg1/debian/patches/Clean-up-cxxtest-configuration.patch   
2020-12-27 21:57:54.0 +0100
+++ 
shibboleth-sp-3.2.1+dfsg1/debian/patches/Clean-up-cxxtest-configuration.patch   
2021-03-17 14:26:00.0 +0100
@@ -9,7 +9,7 @@
  1 file changed, 5 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index 385d11d..c278574 100644
+index ddae588..ceb34a3 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -940,15 +940,10 @@ AM_CONDITIONAL([GSSAPI_NAMINGEXTS],[test 
"x$ac_cv_have_decl_gss_get_name_attribu
diff -Nru shibboleth-sp-3.2.0+dfsg1/schemas/shibboleth-3.0-native-sp-config.xsd 
shibboleth-sp-3.2.1+dfsg1/schemas/shibboleth-3.0-native-sp-config.xsd
--- shibboleth-sp-3.2.0+dfsg1/schemas/shibboleth-3.0-native-sp-config.xsd   
2020-12-07 21:51:12.0 +0100
+++ shibboleth-sp-3.2.1+dfsg1/schemas/shibboleth-3.0-native-sp-config.xsd   
2021-03-16 15:21:18.0 +0100
@@ -9,7 +9,7 @@
elementFormDefault="qualified"
attributeFormDefault="unqualified"
blockDefault="substitution"
-   version="3.1">
+   version="3.2">
 
   http://www.w3.org/2000/09/xmldsig#; 
schemaLocation="xmldsig-core-schema.xsd" />
   
@@ -754,6 +754,7 @@
 
 
 
+
 
   
 
diff -Nru shibboleth-sp-3.2.0+dfsg1/shibboleth.spec 
shibboleth-sp-3.2.1+dfsg1/shibboleth.spec
--- shibboleth-sp-3.

Bug#985700: piuparts: man page: --scriptsdir references README_server.txt

[Ferenc Wágner]

Source: piuparts
Severity: minor

Dear Maintainer,

https://manpages.debian.org/unstable/piuparts/piuparts.1.en.html says:

> --scriptsdir*='DIR'::
>   Directory where are custom scripts are placed. By default, this is
>   not set. For more information about this, read README_server.txt

However, scripts are described in README.txt.
Please fix the reference.  (And maybe the excess asterisks as well.)
-- 
Thanks,
Feri.

Bug#985405: src:shibboleth-sp: Error templates allow query-based override of variables

[Ferenc Wágner]

Package: src:shibboleth-sp
Version: 3.0.2+dfsg1-1
Severity: important
Tags: upstream patch security
Forwarded: https://issues.shibboleth.net/jira/browse/SSPCPP-922

Shibboleth Service Provider Security Advisory [17 March 2021]

An updated version of the Service Provider software is available
which fixes a phishing vulnerability.

Template generation allows external parameters to override placeholders
==
The SP includes a primitive template engine used to render error pages
and various other status or transition pages, and it supports a syntax
for embedding placeholders that are replaced by internally supplied
values or configuration settings.

For reasons that are unclear in the code history, it was extended to
allow replacement via query parameters also, though this is not a
typical need. Because of this feature, it's possible to cause the SP
to display some templates containing values supplied externally by
URL manipulation. Though the values are encoded to prevent script
injection, the content nevertheless appears to come from the server
and so would be interpreted as trustworthy, allowing email addresses,
logos, or support URLs to be manipulated by an attacker.

All platforms are impacted by this issue.


Recommendations
===
Update to V3.2.1 or later of the Service Provider software, which
is now available.

The update adds a new  setting to the configuration called
externalParameters, which defaults to false. When false, support for
this "feature" is disabled. In the unlikely event that a valid need
for this exists, the setting can be enabled temporarily to maintain
function until the use case requiring it is addressed in some other
way.


Other Notes
===
The cpp-sp git commit containing the fix for this issue is
d1dbebfadc1bdb824fea63843c4c38fa69e54379


URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20210317.txt

Bug#984876: openssh-server: logs unsightly errors from pam_env due to missing /etc/default/locale

[Ferenc Wágner]

Package: openssh-server
Version: 1:8.4p1-4
Severity: minor

Dear Maintainer,

I installed openssh-server in an autopkgtest VM for debugging.  It works
fine, but pollutes the logs with red messages like

sshd[2122]: pam_env(sshd:session): Unable to open env file: 
/etc/default/locale: No such file or directory

The locales package is not installed on this VM, but I didn't do
anything for that.

In my opinion it would be nice to get rid of that error is possible.
Apparently it comes from /etc/pam.d/sshd:

# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
sessionrequired pam_env.so user_readenv=1 envfile=/etc/default/locale

Or should (for example) base-files make sure it exists?
-- 
Thanks,
Feri.

Bug#984501: unblock: libqb/2.0.3-1

[Ferenc Wágner]

help in
- short | recursive ) echo "Configuration of libqb 2.0.2:";;
+ short | recursive ) echo "Configuration of libqb 2.0.3:";;
esac
   cat <<\_ACEOF
 
@@ -1649,7 +1649,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-libqb configure 2.0.2
+libqb configure 2.0.3
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2426,7 +2426,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by libqb $as_me 2.0.2, which was
+It was created by libqb $as_me 2.0.3, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4666,7 +4666,7 @@
 
 # Define the identity of the package.
  PACKAGE='libqb'
- VERSION='2.0.2'
+ VERSION='2.0.3'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -23074,7 +23074,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by libqb $as_me 2.0.2, which was
+This file was extended by libqb $as_me 2.0.3, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -23140,7 +23140,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-libqb config.status 2.0.2
+libqb config.status 2.0.3
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru libqb-2.0.2/debian/changelog libqb-2.0.3/debian/changelog
--- libqb-2.0.2/debian/changelog2020-12-26 16:07:32.0 +0100
+++ libqb-2.0.3/debian/changelog2021-03-04 06:11:31.0 +0100
@@ -1,3 +1,11 @@
+libqb (2.0.3-1) unstable; urgency=medium
+
+  * [f0b428b] New upstream release (2.0.3)
+  * [ff0eed7] Delete upstream patch, refresh the rest
+  * [bee0959] Acknowledge new symbols
+
+ -- Ferenc Wágner   Thu, 04 Mar 2021 06:11:31 +0100
+
 libqb (2.0.2-1) unstable; urgency=medium
 
   * [afb0870] libqb-tools took over qb-blackbox from libqb-dev (<< 2)
diff -Nru libqb-2.0.2/debian/libqb100.symbols 
libqb-2.0.3/debian/libqb100.symbols
--- libqb-2.0.2/debian/libqb100.symbols 2020-12-25 16:19:24.0 +0100
+++ libqb-2.0.3/debian/libqb100.symbols 2021-03-04 06:10:02.0 +0100
@@ -91,6 +91,7 @@
  qb_log_blackbox_open@Base 2.0.1
  qb_log_blackbox_print_from_file@Base 2.0.1
  qb_log_blackbox_write_to_file@Base 2.0.1
+ qb_log_callsite_get2@Base 2.0.3
  qb_log_callsite_get@Base 2.0.1
  qb_log_callsites_dump@Base 2.0.1
  qb_log_callsites_register@Base 2.0.1
@@ -114,6 +115,7 @@
  qb_log_format_init@Base 2.0.1
  qb_log_format_set@Base 2.0.1
  qb_log_from_external_source@Base 2.0.1
+ qb_log_from_external_source_va2@Base 2.0.3
  qb_log_from_external_source_va@Base 2.0.1
  qb_log_init@Base 2.0.1
  qb_log_priority2str@Base 2.0.1
diff -Nru 
libqb-2.0.2/debian/patches/doxygen2man-ignore-all-whitespace-brief-description.patch
 
libqb-2.0.3/debian/patches/doxygen2man-ignore-all-whitespace-brief-description.patch
--- 
libqb-2.0.2/debian/patches/doxygen2man-ignore-all-whitespace-brief-description.patch
2020-12-26 16:07:22.0 +0100
+++ 
libqb-2.0.3/debian/patches/doxygen2man-ignore-all-whitespace-brief-description.patch
1970-01-01 01:00:00.0 +0100
@@ -1,21 +0,0 @@
-From: =?utf-8?q?Ferenc_W=C3=A1gner?= 
-Date: Sat, 26 Dec 2020 16:06:28 +0100
-Subject: doxygen2man: ignore all-whitespace brief description
-

- doxygen2man/doxygen2man.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/doxygen2man/doxygen2man.c b/doxygen2man/doxygen2man.c
-index f7973fd..c1cb438 100644
 a/doxygen2man/doxygen2man.c
-+++ b/doxygen2man/doxygen2man.c
-@@ -756,7 +756,7 @@ static void print_manpage(char *name, char *def, char 
*brief, char *args, char *
-   fprintf(manfile, ".TH %s %s %s \"%s\" \"%s\"\n", allcaps(name), 
man_section, dateptr, package_name, header);
- 
-   fprintf(manfile, ".SH NAME\n");
--  if (brief) {
-+  if (brief && not_all_whitespace(brief)) {
-   fprintf(manfile, "%s \\- %s\n", name, brief);
-   } else {
-   fprintf(manfile, "%s\n", name);
diff -Nru 
libqb-2.0.2/debian/patches/Fix-typos-and-inconsistencies-in-doxygen2man-help-text.patch
 
libqb-2.0.3/debian/patches/Fix-typos-and-inconsistencies-in-doxygen2man-help-text.patch
--- 
libqb-2.0.2/debian/patches/Fix-typos-and-inconsistencies-in-doxygen2man-help-text.patch
 2020-12-26 16:06:56.0 +0100
+++ 
libqb-2.0.3/debian/patches/Fix-typos-and-inconsistencies-in-doxygen2man-help-text.patch
 2021-03-04 05:50:39.0 +0100
@@ -7,10 +7,10 @@
  1 file changed, 9 insertions(+), 9 deletions(-)
 
 diff --git a/d

Bug#983598: lintian: package-installs-apt-sources emitted for packages whose names end in -archive-keyring

[Ferenc Wágner]

Package: lintian
Version: 2.15.0
Severity: normal

Dear Maintainer,

The tag info for package-installs-apt-sources states that "packages
whose names end in -apt-source or -archive-keyring are permitted to
install such files.  However, only the first suffix is exempted by the
code.  I don't know whether the documentation or the implementation is
right; please fix the one which isn't.
-- 
Thanks,
Feri.

Bug#983569: net-snmp: please enable systemd integration

[Ferenc Wágner]

Source: net-snmp
Severity: wishlist

Dear Maintainer,

Net-SNMP has systemd integration support, including socket activation,
which would be very handy for letting snmptrapd run without root
privileges and even CAP_NET_BIND_SERVICE.  It would also enable getting
rid of the conditional and dependency directives in the current unit
file.  If you aren't comfortable with changing the unit files now,
shortly before hard freeze, at least enabling support in the daemons
would still be very useful and also very easy with the --with-systemd
configure flag.  That wouldn't change behavior, only enable taking
advantage of the support via local configuration.  If you're interested,
I'm willing to open a merge request for easier review.  The Salsa CI
passed on my fork with the trivial change.
-- 
Thanks,
Feri.

Bug#979320: transition: xmltooling

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

The recent 3.2 release of the Shibboleth SP is a minor release, but due
to the internal structure of the stack it entails the usual three
transitions for xmltooling, opensaml and shibboleth-sp.  I'd like to do
successive sourceful uploads for these (the updated packages are already
in experimental).  The two other impacted packages build fine without any
change: shibboleth-resolver and moonshot-gss-eap.  The auto-{xmltooling,
opensaml,shibboleth-sp} trackers are good.  I'm ready to upload to
unstable on your word.
-- 
Thanks,
Feri.

Bug#978155: transition: libqb

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

I'd like to transition to libqb version 2.  The dependency list is
fairly short, and mostly contains packages under the HA Team umbrella.
The only breakage is caused by symbols file changes, which I'm ready to
fix by sourceful uploads of corosync and pacemaker.  The kronosnet
package will also receive a sourceful upload to use the new binary
package doxygen2man.  Altogether I rebuilt the following packages in
preparation:

kronosnet (with source changes)
corosync (with source changes)
corosync-qdevice
pacemaker (with source changes)
dlm
booth
fence-virt
sbd
ocfs2-tools
lvm2
usbguard

The auto-libqb tracker seems usable just too broad.

Ben file:

title = "libqb";
is_affected = .depends ~ "libqb0" | .depends ~ "libqb100";
is_good = .depends ~ "libqb100";
is_bad = .depends ~ "libqb0";

When you see fit, I'll upload libqb, kronosnet, corosync and pacemaker
in succession, then request the necessary binNMUs.
-- 
Thanks,
Feri.

Bug#974009: debhelper: please document that dh_installsystemd ignores unit failures in maintainer scripts

[Ferenc Wágner]

Package: debhelper
Version: 12.1.1
Severity: minor

Dear Maintainer,

I was surprised that a daemon start failure during install did not stop
dpkg from exiting with a successful exit status.  After much digging I
found https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766194#22, which
explains the asymmetry with dh_installinit.  While I'd find an option
for this more appropriate than different behavior, I also feel like the
current state merits some much more prominent documentation at least.
Please consider addig it to the respective compat level as well.
-- 
Thanks,
Feri.

Bug#971427: lintian: false positive package-contains-documentation-outside-usr-share-doc for SNMP MIB files

[Ferenc Wágner]

Package: lintian
Version: 2.96.0
Severity: normal

Dear Maintainer,

SNMP MIB files are generally /usr/share/snmp/mibs/*.txt, though
these text files aren't documentation.  Please make them exempt
from package-contains-documentation-outside-usr-share-doc.
See libsnmp-base for example.
-- 
Thanks,
Feri.

Bug#966111: dpkg-dev: dpkg-architecture(1) should document variable usage more prominently

[Ferenc Wágner]

Package: dpkg-dev
Version: 1.19.7
Severity: minor

Dear Maintainer,

The VARIABLES section of the dpkg-architecture manual starts by

The following variables are set by dpkg-architecture...

However, these variables are also *used* by dpkg-architecture, and
evidenced by the documentation of the --force option:

-f, --force
Values set by existing environment variables with the same name as
used by the scripts are honored (i.e. used by dpkg-architecture)...

I think this piece of information should be presented more prominently,
so I recommend moving this part of the --force documentation into the
DESCRIPTION section and also alluding to it in the VARIABLES section.
-- 
Thanks,
Feri.

Bug#966110: dpkg-dev: circular reference in dpkg-architecture(1)

[Ferenc Wágner]

Package: dpkg-dev
Version: 1.19.7
Severity: minor

Dear Maintainer,

man dpkg-architecture states that

-u, --print-unset
Print a similar command to --print-unset but to unset all variables.

I think it should reference --print-set instead, since that is already
defined above.
-- 
Thanks,
Feri.

Bug#964244: stretch-pu: package xml-security-c/1.7.3-4+deb9u2

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear Stable Release Team,

There's an old bug reported against xml-security-c (#922984), which was fixed
in the 2.0 branch in buster but still lingers around in 1.7 in stretch.  I'm
ready to upload with the following debdiff:

$ debdiff xml-security-c_1.7.3-4+deb9u[23].dsc 
diff -Nru xml-security-c-1.7.3/debian/changelog 
xml-security-c-1.7.3/debian/changelog
--- xml-security-c-1.7.3/debian/changelog   2018-12-10 11:45:41.0 
+0100
+++ xml-security-c-1.7.3/debian/changelog   2020-07-04 12:47:24.0 
+0200
@@ -1,3 +1,10 @@
+xml-security-c (1.7.3-4+deb9u3) stretch; urgency=medium
+
+  * [02c3993] New patch: Fix a length bug in concat method.
+Thanks to Scott Cantor (Closes: #922984 )
+
+ -- Ferenc Wágner   Sat, 04 Jul 2020 12:47:24 +0200
+
 xml-security-c (1.7.3-4+deb9u2) stretch; urgency=medium
 
   * [12dd825] New patches: DSA verification crashes OpenSSL on invalid
diff -Nru 
xml-security-c-1.7.3/debian/patches/Fix-a-length-bug-in-concat-method.patch 
xml-security-c-1.7.3/debian/patches/Fix-a-length-bug-in-concat-method.patch
--- xml-security-c-1.7.3/debian/patches/Fix-a-length-bug-in-concat-method.patch 
1970-01-01 01:00:00.0 +0100
+++ xml-security-c-1.7.3/debian/patches/Fix-a-length-bug-in-concat-method.patch 
2020-07-04 12:47:01.0 +0200
@@ -0,0 +1,24 @@
+From: Scott Cantor 
+Date: Mon, 4 Sep 2017 18:41:41 +
+Subject: Fix a length bug in concat method.
+
+git-svn-id: 
https://svn.apache.org/repos/asf/santuario/xml-security-cpp/trunk@1807280 
13f79535-47bb-0310-9956-ffa450edef68
+
+Closes: #922984
+---
+ xsec/utils/XSECSafeBuffer.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/xsec/utils/XSECSafeBuffer.cpp b/xsec/utils/XSECSafeBuffer.cpp
+index 71ae9a0..6d0798b 100644
+--- a/xsec/utils/XSECSafeBuffer.cpp
 b/xsec/utils/XSECSafeBuffer.cpp
+@@ -639,7 +639,7 @@ void safeBuffer::sbXMLChCat(const char * str) {
+ 
+   assert (t != NULL);
+ 
+-  len += XMLString::stringLen(t);
++  len += XMLString::stringLen(t) * size_XMLCh;
+   len += (xsecsize_t) (2 * size_XMLCh);
+ 
+   checkAndExpand(len);
diff -Nru xml-security-c-1.7.3/debian/patches/series 
xml-security-c-1.7.3/debian/patches/series
--- xml-security-c-1.7.3/debian/patches/series  2018-12-10 11:45:41.0 
+0100
+++ xml-security-c-1.7.3/debian/patches/series  2020-07-04 12:47:01.0 
+0200
@@ -24,3 +24,4 @@
 Default-KeyInfo-resolver-doesn-t-check-for-empty-element-.patch
 SANTUARIO-496-DSA-verification-crashes-OpenSSL-on-invalid.patch
 SANTUARIO-496-Prevent-KeyInfoResolver-returning-NONE-keys.patch
+Fix-a-length-bug-in-concat-method.patch

Bug#963751: wordpress-shibboleth: Please depend on libapache2-mod-shib (not -shib2)

[Ferenc Wágner]

Package: wordpress-shibboleth
Severity: serious

Dear Maintainer,

The Shibboleth SP package migrated from providing libapache2-mod-shib2
to libapache2-mod-shib; the former is already transitional in buster.
Please switch to using the new package name to keep wordpress-shibboleth
installable.
-- 
Thanks,
Feri.

Bug#963144: src:lcd4linux: Build-depends on libgphoto2, but does not use it

[Ferenc Wágner]

Package: src:lcd4linux
Severity: minor

Dear Maintainer,

The lcd4linux package Build-Depends on libgphoto2-dev, but does not
actually use it during the build.  I don't even understand how it could,
so I kindly ask you to consider dropping the dependency if possible.  It
would simplify checking the reverse dependencies of libgphoto2 before
uploads.
-- 
Thanks,
Feri.

Bug#963143: src:opencv: Build-depends on libgphoto2, but does not use it

[Ferenc Wágner]

Package: src:opencv
Severity: minor

Dear Maintainer,

The opencv package Build-Depends on libgphoto2-dev, but does not
actually use it during the build.  Please either drop the dependency,
or consider making use of it via a patch like

diff -Nru opencv-4.2.0+dfsg/debian/rules opencv-4.2.0+dfsg/debian/rules
--- opencv-4.2.0+dfsg/debian/rules  2020-04-02 05:02:10.0 +0200
+++ opencv-4.2.0+dfsg/debian/rules  2020-06-19 17:32:29.0 +0200
@@ -90,6 +90,7 @@
-DWITH_GDAL=ON \
-DWITH_GDCM=ON \
-DWITH_GSTREAMER=ON \
+   -DWITH_GPHOTO2=ON \
-DWITH_GTK=ON \
-DWITH_IPP=OFF \
-DWITH_ITT=OFF \

(I'm not asking for this feature, just noticed this inconsistency while
doing a test rebuild of the reverse dependencies of libgphoto2 before
upload.)
-- 
Thanks,
Feri.

Bug#963081: src:camera.app: Please switch to using pkg-config for libgphoto2

[Ferenc Wágner]

Package: src:camera.app
Version: 0.8.0-12
Severity: normal

Dear Maintainer,

I plan to upload libgphoto2 2.5.25 without the config scripts,
which upstream considers obsolete and hurt the multi-arch effort.
It's easy to switch to using pkg-config instead, see the attached
debdiff.  Please consider applying something along these lines so
that the incoming libgphoto2 upload does not make camera.app FTBFS.
Or I can do this NMU or send a Salsa MR if you prefer, just holler.

Thanks,
Feri.

$ debdiff camera.app_0.8.0-12.dsc camera.app_0.8.0-12.1.dsc
gpgv: Signature made Thu 07 Nov 2019 04:57:15 PM CET
gpgv:using RSA key 9236557B170C87F8821C0AC3C1E0D92E986F7C7E
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on 
/home/wferi/phototools/libgphoto2/rdeps/camera.app_0.8.0-12.dsc
dpkg-source: warning: extracting unsigned source package 
(/home/wferi/phototools/libgphoto2/rdeps/camera.app_0.8.0-12.1.dsc)
diff -Nru camera.app-0.8.0/debian/changelog camera.app-0.8.0/debian/changelog
--- camera.app-0.8.0/debian/changelog   2019-11-01 13:36:00.0 +0100
+++ camera.app-0.8.0/debian/changelog   2020-06-18 18:16:16.0 +0200
@@ -1,3 +1,10 @@
+camera.app (0.8.0-12.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * libgphoto_2.5.25-1 dropped the config scripts, switch to pkg-config.
+
+ -- Ferenc Wágner   Thu, 18 Jun 2020 18:16:16 +0200
+
 camera.app (0.8.0-12) unstable; urgency=medium
 
   * Fix Vcs fields.
diff -Nru camera.app-0.8.0/debian/control camera.app-0.8.0/debian/control
--- camera.app-0.8.0/debian/control 2019-11-01 13:36:00.0 +0100
+++ camera.app-0.8.0/debian/control 2020-06-18 18:16:10.0 +0200
@@ -7,7 +7,8 @@
 Build-Depends: debhelper (>= 11),
   gnustep-make (>= 2.6.6),
   libgnustep-gui-dev (>= 0.24.0),
-  libgphoto2-dev (>= 2.5.10)
+  libgphoto2-dev (>= 2.5.10),
+  pkg-config,
 Standards-Version: 4.4.1
 Vcs-Git: https://salsa.debian.org/gnustep-team/camera.app.git
 Vcs-Browser: https://salsa.debian.org/gnustep-team/camera.app
diff -Nru camera.app-0.8.0/debian/patches/series 
camera.app-0.8.0/debian/patches/series
--- camera.app-0.8.0/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ camera.app-0.8.0/debian/patches/series  2020-06-18 18:16:16.0 
+0200
@@ -0,0 +1 @@
+Use-pkg-config-for-libgphoto2.patch
diff -Nru camera.app-0.8.0/debian/patches/Use-pkg-config-for-libgphoto2.patch 
camera.app-0.8.0/debian/patches/Use-pkg-config-for-libgphoto2.patch
--- camera.app-0.8.0/debian/patches/Use-pkg-config-for-libgphoto2.patch 
1970-01-01 01:00:00.0 +0100
+++ camera.app-0.8.0/debian/patches/Use-pkg-config-for-libgphoto2.patch 
2020-06-18 18:16:16.0 +0200
@@ -0,0 +1,9 @@
+--- a/GNUmakefile.preamble
 b/GNUmakefile.preamble
+@@ -1,3 +1,3 @@
+-ADDITIONAL_INCLUDE_DIRS += `gphoto2-config --cflags`
++ADDITIONAL_INCLUDE_DIRS += `pkg-config libgphoto2 --cflags`
+ ADDITIONAL_OBJCFLAGS += -g -Wall
+-ADDITIONAL_GUI_LIBS += `gphoto2-config --libs`
+\ No newline at end of file
++ADDITIONAL_GUI_LIBS += `pkg-config libgphoto2 --libs`
diff -Nru camera.app-0.8.0/debian/rules camera.app-0.8.0/debian/rules
--- camera.app-0.8.0/debian/rules   2018-02-07 13:12:59.0 +0100
+++ camera.app-0.8.0/debian/rules   2020-06-18 18:16:16.0 +0200
@@ -15,11 +15,6 @@
 # import GNUstep settings for Debian
 include /usr/share/GNUstep/debian/config.mk
 
-# override GNUmakefile.preamble
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
-export ADDITIONAL_INCLUDE_DIRS += 
`/usr/lib/$(DEB_HOST_MULTIARCH)/libgphoto2-dev/bin/gphoto2-config --cflags`
-export ADDITIONAL_GUI_LIBS += 
`/usr/lib/$(DEB_HOST_MULTIARCH)/libgphoto2-dev/bin/gphoto2-config --libs`
-
 %:
dh $@
 

Bug#962659: transition: xmltooling

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

The 3.1 release of the Shibboleth software stack changed the ABI and API
of all the components.  It's pretty self-contained in Debian, though.
The affected packages (xmltooling, opensaml, shibboleth-sp and
shibboleth-resolver) are all in experimental now, and moonshot-gss-eap
will only need a binnmu to complete the transition.

We're ready to upload to unstable if you agree.

Ben file:

title = "shibboleth31";
is_affected = .depends ~ "libxmltooling8" | .depends ~ "libsaml10" | .depends ~ 
"libshibsp8" | .depends ~ "libshibresolver2" | .depends ~ "libxmltooling9" | 
.depends ~ "libsaml11" | .depends ~ "libshibsp9" | .depends ~ 
"libshibresolver3";
is_good = .depends ~ "libxmltooling9" | .depends ~ "libsaml11" | .depends ~ 
"libshibsp9" | .depends ~ "libshibresolver3";
is_bad = .depends ~ "libxmltooling8" | .depends ~ "libsaml10" | .depends ~ 
"libshibsp8" | .depends ~ "libshibresolver2";

Thanks,
the Shibboleth packaging team.

Bug#960280: wireshark: segfault during column manipulation

[Ferenc Wágner]

Package: wireshark
Version: 2.6.8-1.1
Severity: normal

Dear Maintainer,

While I was fiddling with the column setup, wireshark received a SIGSEGV
and crashed.  I'll keep the core file around for some time in case
there's interest; the backtrace starts like this:

(gdb) bt full
#0  __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:173
No locals.
#1  0x55d011cf0dbc in recent_get_column_width (col=) at 
./ui/recent.c:1431
col_l = 0x55d015bacfa0 = {0x7f27d002c300, 0x55d0170123d0}
col_w = 0x7f27d002c300
cfmt = 6
cfield = 0x0
#2  0x55d011c069d0 in ColumnEditorFrame::on_buttonBox_accepted 
(this=0x55d01399c590) at ./ui/qt/column_editor_frame.cpp:143
width = 
xalign = 
col_str = {d = 0x55d016490200}
#3  0x55d011ba5bc1 in ColumnEditorFrame::qt_static_metacall 
(_a=0x7ffc7bd4d930, _id=6, _c=QMetaObject::InvokeMetaMethod, _o=0x55d01399c590)
at 
./obj-x86_64-linux-gnu/ui/qt/qtui_autogen/EWIEGA46WW/moc_column_editor_frame.cpp:155
_t = 
result = 
#4  ColumnEditorFrame::qt_metacall (this=0x55d01399c590, 
_c=QMetaObject::InvokeMetaMethod, _id=6, _a=0x7ffc7bd4d930)
at 
./obj-x86_64-linux-gnu/ui/qt/qtui_autogen/EWIEGA46WW/moc_column_editor_frame.cpp:155
No locals.
#5  0x7f27e52b88b7 in QMetaObject::activate(QObject*, int, int, void**) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
[...]

I can't reproduce the crash, it took several operations to get there
(like adding, removing and editing columns).

Regards,
Feri.

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages wireshark depends on:
ii  wireshark-qt  2.6.8-1.1

wireshark recommends no packages.

wireshark suggests no packages.

-- no debconf information

Bug#958186: kdenlive: dependency problems

[Ferenc Wágner]

Package: kdenlive
Version: 19.12.3-1~bpo10+1
Severity: normal

Dear Maintainer,

During the backport of kdenlive to buster, I hit a couple of problems
which may be of your interest:

1. kdenlive Build-Depends on libmlt-dev (>= 6.10.0), but trying to build
   with 6.12 in buster gives a message that at least 6.18 is required.
   Thus I recommend bumping the version constraints like
   libmlt-dev (>= 6.18.0), libmlt++-dev (>= 6.18.0).

2. the final package should (probably) depend on kde-style-breeze,
   otherwise the colors are off, making the icons invisible.  The
   current Recommends: breeze-icon-theme is inadequate, I recommend
   Depends: kde-style-breeze.

Please note that I've got no familiarity with the KDE desktop, I just
describe what helped for me.

Beyond the above, removing libkf5doctools-dev from Build-Depends lets
the package build (otherwise the build failed due to missing entities)
with backported mlt and extra-cmake-modules and librttr from sid.  It
still reports lots of

WARNING : Fails to parse  "avdeinterlace"
WARNING : Fails to parse  "swscale"
"avfilter.abench" is blacklisted
"avfilter.acompressor" is blacklisted

on startup but seems usable.

Thanks,
Feri.

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kdenlive depends on:
ii  ffmpeg 7:4.1.4-1~deb10u1
ii  kded5  5.54.0-1
ii  kdenlive-data  19.12.3-1~bpo10+1
ii  kinit  5.54.0-1
ii  kio5.54.1-1
ii  kpackagetool5  5.54.0-1
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libkf5archive5 5.54.0-1
ii  libkf5attica5  5.54.0-1
ii  libkf5auth55.54.0-2
ii  libkf5bookmarks5   5.54.0-1
ii  libkf5codecs5  5.54.0-1
ii  libkf5completion5  5.54.0-1
ii  libkf5configcore5  5.54.0-1+deb10u1
ii  libkf5configgui5   5.54.0-1+deb10u1
ii  libkf5configwidgets5   5.54.0-1
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5crash5   5.54.0-1
ii  libkf5dbusaddons5  5.54.0-1
ii  libkf5declarative5 5.54.0-1
ii  libkf5filemetadata35.54.0-1
ii  libkf5guiaddons5   5.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5iconthemes5  5.54.0-1
ii  libkf5itemviews5   5.54.0-1
ii  libkf5jobwidgets5  5.54.0-1
ii  libkf5kiocore5 5.54.1-1
ii  libkf5kiofilewidgets5  5.54.1-1
ii  libkf5kiowidgets5  5.54.1-1
ii  libkf5newstuff55.54.0-2
ii  libkf5newstuffcore55.54.0-2
ii  libkf5notifications5   5.54.0-1
ii  libkf5notifyconfig55.54.0-1
ii  libkf5package5 5.54.0-1
ii  libkf5purpose-bin  5.54.0-1
ii  libkf5purpose5 5.54.0-1
ii  libkf5service-bin  5.54.0-1
ii  libkf5service5 5.54.0-1
ii  libkf5solid5   5.54.0-1
ii  libkf5sonnetui55.54.0-1
ii  libkf5textwidgets5 5.54.0-1
ii  libkf5widgetsaddons5   5.54.0-1
ii  libkf5xmlgui5  5.54.0-1
ii  libmlt++3  6.20.0-2~bpo10+1
ii  libmlt66.20.0-2~bpo10+1
ii  libqt5concurrent5  5.11.3+dfsg1-1+deb10u3
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus55.11.3+dfsg1-1+deb10u3
ii  libqt5gui5 5.11.3+dfsg1-1+deb10u3
ii  libqt5multimedia5  5.11.3-2
ii  libqt5network5 5.11.3+dfsg1-1+deb10u3
ii  libqt5qml5 5.11.3-4
ii  libqt5quick5   5.11.3-4
ii  libqt5quickwidgets55.11.3-4
ii  libqt5svg5 5.11.3-2
ii  libqt5webkit5  5.212.0~alpha2-21
ii  libqt5widgets5 5.11.3+dfsg1-1+deb10u3
ii  libqt5xml5 5.11.3+dfsg1-1+deb10u3
ii  librttr-core0.9.6  0.9.6+dfsg1-3
ii  libstdc++6 8.3.0-6
ii  libv4l-0   1.16.3-3
ii  melt   6.20.0-2~bpo10+1
ii  qml-module-qtgraphicaleffects  5.11.3-2
ii  qml-module-qtqml-models2   5.11.3-4
ii  qml-module-qtquick-controls5.11.3-2
ii  qml-module-qtquick-controls2   5.11.3+dfsg-2
ii  qml-module-qtquick-dialogs 5.11.3-2
ii  qml-module-qtquick-layouts 5.11.3-4
ii  qml-module-qtquick-window2 5.11.3-4
ii  qml-module-qtquick25.11.3-4

Bug#955206: freeradius: Daemon has write privilege to configuration

[Ferenc Wágner]

Source: freeradius
Version: 3.0.17+dfsg-1.1
Severity: wishlist

Dear Maintainer,

In the default installation freeradius runs as user freerad, which is
also the user owning the /etc/freeradius directory structure.  This
means that an arbitrary code execution compromise in the daemon means
immediate privilege escalation to root.  Isn't read permission enough
for most usual configurations?  If so, leaving the /etc/freeradius
structure owned by root would be a safer default in my opinion, please
consider switching to that.
-- 
Thanks,
Feri.

Bug#950587: rootskel: kernel argument parsing in S02module-params ignores quoting

[Ferenc Wágner]

Package: rootskel
Severity: normal

Dear Maintainer,

If I preseed multiple nameservers on the kernel command line, like for
example netcfg/get_nameservers="193.225.12.63 193.225.14.58", in the
installed system the following /etc/modprobe.d/local.conf appears:

--8<--
# Local module settings
# Created by the Debian installer

options 193.225.14 225.14.58"=193.225.14.58"
--8<--

Indeed, if I pass a="b c.d" on the kernel command line, the
misunderstanding is already present in the installer environment:

--8<--
~ # cat /var/lib/register-module/c.params
options:d"=c.d"
--8<--

The problematic code is S02module-params in rootskel. Proper and secure
quote handling is indeed pretty hard in shell programming, but security
isn't relevant in the Debian Installer context, so using shell eval
seems acceptable and probably provides the easiest solution.

Please consider fixing this some way.
-- 
Thanks,
Feri.

Bug#950488: buster-pu: package kronosnet/1.8-2

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear Stable Release Team,

I'v got a bold request: please let me update Kronosnet in buster from
1.8-2 to 1.13-something to fix #946222.  During the buster freeze
period, upstream released 1.9 and 1.10, but those didn't bring important
fixes, so I didn't request freeze exceptions for them.  However, when
Proxmox VE 6.0 got released (based on Debian buster), their users
reported lots of intertwined bugs, and the developers iterated through
1.11, 1.12 and 1.13 in quick succession to fix them, see the linked
https://forum.proxmox.com/threads/pve-5-4-11-corosync-3-x-major-issues.56124.
>From the announcements:

1.9, May 2019:
(https://lists.kronosnet.org/pipermail/devel/2019-May/77.html)
1.10, Jun 2019:
(https://lists.kronosnet.org/pipermail/devel/2019-June/78.html)

1.11, Aug 2019:
  Major bug fixes in the PMTUd code. MTU was not calculated correctly
  when using crypto and PMTUd would fail due to timeouts when using
  crypto and systems are overloaded. Thanks to the proxmox community for
  reporting the issues and testing pre-fixes.
  (https://lists.kronosnet.org/pipermail/devel/2019-August/79.html)

1.12, Sep 2019:
* IMPORTANT: any version prior to 1.12 has a memory corruption bug that
  could cause knet to crash or hung when the network is not stable for a
  long period of time. Please see
  https://github.com/kronosnet/kronosnet/issues/255 for details.
  If you are unable to upgrade to 1.12, please make sure to cherry pick
  
https://github.com/kronosnet/kronosnet/commit/6a92361c7554c2aa7222d6f868e43704694683c7
  (stable branch) into your distribution as soon as possible.

1.13, Oct 2019:
* IMPORTANT/URGENT: fix defrag buffer reclaim logic that could lead knet
   to deliver corrupted data to the application (corosync or alike).
* IMPORTANT/URGENT: fix MTU boundary check on links with very high
   packet loss and avoid delivering corrupted (short) data to the
   application.
(https://lists.kronosnet.org/pipermail/devel/2019-October/81.html)

Since Proxmox upgraded Kronosnet to 1.13, things settled and seem to
work reliably.  But Debian stable users were left out in the cold, I had
to recommend installing Kronosnet for bullseye, which worked for some
time but isn't optimal, so eventually #946222 was filed.  Backports
would certainly be a possibility, but given that Kronosnet 1.8 in buster
isn't really usable for anything serious, I decided to ask for a stable
update first.  Of course this would include some unnecessary (but good)
changes as well; while it would be possible to cherry pick the relevant
commits only, that involves quite some back-and-forth stuff muddying the
waters and would result in a misleading version number as well.  Since
the only package depending on Kronosnet is Corosync, which is also under
the HA Team umbrella, I find the risk acceptable (and the pieces would
fall back on me after all).

Some upstream communication about cherry-picking possibilities:

https://github.com/kronosnet/kronosnet/pull/242
"the big fat PMTU patch is a very serious bug. [...] The previous patch
set was less invasive but still wrong [...] The last patch, while
invasive in the look, makes the code a lot simpler and functional"

https://github.com/kronosnet/kronosnet/pull/257#issuecomment-533054215
"please make sure to cherry pick this fix ASAP, also for Debian stable.
It's a bad crash and memory corrupter. [...] coverity scan fixes will
hit stable release in 1.12, I would wait to push them into a stable
update for Debian, they are super nice, but nothing critical enough to
force it.  For #242 I still strongly recommend to take the big patch.
It's been tested a lot now"
-- 
Looking forward to hearing your advice,
Feri.

Bug#950478: buster-pu: package corosync/3.0.1-2

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Corosync upstream called my attention to an issue worth a stable update.
A potentially serious problem with a simple fix, which I backported to
the buster package:

$ debdiff corosync_3.0.1-2.dsc corosync_3.0.1-2+deb10u1.dsc
diff -Nru corosync-3.0.1/debian/changelog corosync-3.0.1/debian/changelog
--- corosync-3.0.1/debian/changelog 2019-02-04 00:31:24.0 +0100
+++ corosync-3.0.1/debian/changelog 2020-02-02 12:32:26.0 +0100
@@ -1,3 +1,11 @@
+corosync (3.0.1-2+deb10u1) buster; urgency=medium
+
+  * [f826af9] This branch is for buster updates
+  * [bfbfd3e] New patch: totemsrp: Reduce MTU to left room second mcast.
+Thanks to Jan Friesse (Closes: #950476)
+
+ -- Ferenc Wágner   Sun, 02 Feb 2020 12:32:26 +0100
+
 corosync (3.0.1-2) unstable; urgency=medium
 
   * [70f53cb] Switch to Debhelper level 12.
diff -Nru corosync-3.0.1/debian/gbp.conf corosync-3.0.1/debian/gbp.conf
--- corosync-3.0.1/debian/gbp.conf  2019-02-03 11:42:36.0 +0100
+++ corosync-3.0.1/debian/gbp.conf  2020-02-01 08:45:41.0 +0100
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/buster
 upstream-branch = upstream/latest
 
 [import-orig]
diff -Nru corosync-3.0.1/debian/patches/series 
corosync-3.0.1/debian/patches/series
--- corosync-3.0.1/debian/patches/series2019-02-03 11:42:36.0 
+0100
+++ corosync-3.0.1/debian/patches/series2020-02-02 12:31:51.0 
+0100
@@ -6,3 +6,4 @@
 AC_PROG_SED-is-already-present.patch
 Use-the-SED-variable-provided-by-configure.patch
 Use-the-AWK-variable-provided-by-configure.patch
+totemsrp-Reduce-MTU-to-left-room-second-mcast.patch
diff -Nru 
corosync-3.0.1/debian/patches/totemsrp-Reduce-MTU-to-left-room-second-mcast.patch
 
corosync-3.0.1/debian/patches/totemsrp-Reduce-MTU-to-left-room-second-mcast.patch
--- 
corosync-3.0.1/debian/patches/totemsrp-Reduce-MTU-to-left-room-second-mcast.patch
   1970-01-01 01:00:00.0 +0100
+++ 
corosync-3.0.1/debian/patches/totemsrp-Reduce-MTU-to-left-room-second-mcast.patch
   2020-02-02 12:31:51.0 +0100
@@ -0,0 +1,43 @@
+From: Jan Friesse 
+Date: Mon, 7 Oct 2019 15:26:22 +0200
+Subject: totemsrp: Reduce MTU to left room second mcast
+
+Messages sent during recovery phase are encapsulated so such message has
+extra size of mcast structure. This is not so big problem for UDPU,
+because most of the switches are able to fragment and defragment packet
+but it is problem for knet, because totempg is using maximum packet size
+(65536 bytes) and when another header is added during retransmition,
+then packet is too large.
+
+Solution is to reduce mtu by 2 * sizeof (struct mcast).
+
+Signed-off-by: Jan Friesse 
+Reviewed-by: Fabio M. Di Nitto 
+
+Closes: #950476
+---
+ exec/totemsrp.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/exec/totemsrp.c b/exec/totemsrp.c
+index ab27924..d846a0f 100644
+--- a/exec/totemsrp.c
 b/exec/totemsrp.c
+@@ -805,7 +805,7 @@ static void totempg_mtu_changed(void *context, int net_mtu)
+ {
+   struct totemsrp_instance *instance = context;
+ 
+-  instance->totem_config->net_mtu = net_mtu - sizeof (struct mcast);
++  instance->totem_config->net_mtu = net_mtu - 2 * sizeof (struct mcast);
+ 
+   log_printf (instance->totemsrp_log_level_debug,
+   "Net MTU changed to %d, new value is %d",
+@@ -5093,7 +5093,7 @@ void main_iface_change_fn (
+ }
+ 
+ void totemsrp_net_mtu_adjust (struct totem_config *totem_config) {
+-  totem_config->net_mtu -= sizeof (struct mcast);
++  totem_config->net_mtu -= 2 * sizeof (struct mcast);
+ }
+ 
+ void totemsrp_service_ready_register (

I'm ready to upload if you agree.
-- 
Thanks,
Feri.

Bug#950476: corosync: large messages are corrupted under heavy load

[Ferenc Wágner]

Package: corosync
Version: 3.0.1-2
Severity: important
Forwarded: https://bugzilla.redhat.com/show_bug.cgi?id=1765025
Control: fixed -1 3.0.3-1

Only happens when using knet as the transport as the MTU size is set
larger than the allowed knet buffer size for some large packets.

The actual impact depends on the message that gets corrupted, so possible
effects could be unexpected behaviour, hangs or fencing. If it's a
pacemaker message then it will probably be resent as pacemaker checksums
its messages.

Fix: 
https://github.com/corosync/corosync/commit/ee8b8993d98b3f6af9c058194228fc534fcd0796

Bug#950139: buster-pu: package xmltooling/3.0.4-1

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear Stable Release Team,

I'm looking for guidance first: I'd like to fix #950135 (libxmltooling8:
Race condition bug in new session cookie feature leads to SP crash) in
buster.  The actual upstream fix touches four lines:

diff --git a/xmltooling/security/impl/DataSealer.cpp 
b/xmltooling/security/impl/DataSealer.cpp
index c7ec7f9..aef85b7 100644
--- a/xmltooling/security/impl/DataSealer.cpp
+++ b/xmltooling/security/impl/DataSealer.cpp
@@ -156,8 +156,10 @@ string DataSealer::wrap(const char* s, time_t exp) const
 
 safeBuffer ciphertext;
 try {
+// Keys are not threadsafe, use a clone to encrypt.
+scoped_ptr clonedKey(defaultKey.second->clone());
 scoped_ptr 
method(XENCEncryptionMethod::create(env.get(), algorithm));
-if (!handler->encryptToSafeBuffer(, method.get(), 
defaultKey.second, dummydoc, ciphertext))
 {
+if (!handler->encryptToSafeBuffer(, method.get(), clonedKey.get(), 
dummydoc, ciphertext)) {
 throw XMLSecurityException("Data encryption failed.");
 }
 }
@@ -235,8 +237,10 @@ string DataSealer::unwrap(const char* s) const
 unsigned int len = 0;
 safeBuffer plaintext;
 try {
+// Keys are not threadsafe, use a clone to decrypt.
+scoped_ptr clonedKey(requiredKey.second->clone());
 scoped_ptr 
method(XENCEncryptionMethod::create(env.get(), algorithm));
-len = handler->decryptToSafeBuffer(, method.get(), 
requiredKey.second, dummydoc, plaintext)
;
+len = handler->decryptToSafeBuffer(, method.get(), clonedKey.get(), 
dummydoc, plaintext);
 }
 catch (const XSECException& ex) {
 auto_ptr_char msg(ex.getMsg());

Upstream cut a new release (3.0.5) for this fix specifically, but the
full diff between 3.0.4 and 3.0.5 is much longer due to changes in the
version number in several files, VC project files, generated Autotools
files, RPM spec file and Windows resource file.  Still not huge, and
most of that is entirely irrelevant for Debian.  But in the 3.0.5-1
upload I included some packaging changes (mainly autopkgtest and Salsa
CI, but also a no-effect upgrade to debhelper compat 12).  I guess you'd
rather not review all this in a stable update, right?  Then I'll add a
quilt patch and submit that, as you prefer.
-- 
Thanks,
Feri.

Bug#948715: stretch-pu: package xml-security-c/1.7.3-4+deb9u1

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear Stable Release Team,

The Security Team declined handling #913136 via a security upload and
recommended the stable upgrade route instead.  So I retargeted the
upload; the debdiff below differs in the changelog header only.
I'm ready to upload if you agree.

Thanks for your consideration.
Feri.

$ debdiff xml-security-c_1.7.3-4+deb9u1.dsc xml-security-c_1.7.3-4+deb9u2.dsc
diff -Nru xml-security-c-1.7.3/debian/changelog 
xml-security-c-1.7.3/debian/changelog
--- xml-security-c-1.7.3/debian/changelog   2018-08-03 11:32:52.0 
+0200
+++ xml-security-c-1.7.3/debian/changelog   2018-12-10 11:45:41.0 
+0100
@@ -1,3 +1,20 @@
+xml-security-c (1.7.3-4+deb9u2) stretch; urgency=medium
+
+  * [12dd825] New patches: DSA verification crashes OpenSSL on invalid
+combinations of key content.
+Particular KeyInfo combinations result in incomplete DSA key structures
+that OpenSSL can't handle without crashing.  In the case of Shibboleth
+SP software this manifests as a crash in the shibd daemon.  Exploitation
+is believed to be possible only in deployments employing the PKIX trust
+engine, which is generally recommended against.
+The upstream patches backported from 2.0.2 apply analogous safeguards to
+the RSA and ECDSA key handling as well.
+Upstream bug: https://issues.apache.org/jira/browse/SANTUARIO-496
+CVE: not assigned
+Thanks to Scott Cantor (Closes: #913136)
+
+ -- Ferenc Wágner   Mon, 10 Dec 2018 11:45:41 +0100
+
 xml-security-c (1.7.3-4+deb9u1) stretch-security; urgency=high
 
   * [93b87c6] New patch: Default KeyInfo resolver doesn't check for empty
diff -Nru 
xml-security-c-1.7.3/debian/patches/SANTUARIO-496-DSA-verification-crashes-OpenSSL-on-invalid.patch
 
xml-security-c-1.7.3/debian/patches/SANTUARIO-496-DSA-verification-crashes-OpenSSL-on-invalid.patch
--- 
xml-security-c-1.7.3/debian/patches/SANTUARIO-496-DSA-verification-crashes-OpenSSL-on-invalid.patch
 1970-01-01 01:00:00.0 +0100
+++ 
xml-security-c-1.7.3/debian/patches/SANTUARIO-496-DSA-verification-crashes-OpenSSL-on-invalid.patch
 2018-12-10 11:45:41.0 +0100
@@ -0,0 +1,103 @@
+From: Scott Cantor 
+Date: Thu, 11 Oct 2018 15:13:40 +
+Subject: SANTUARIO-496 - DSA verification crashes OpenSSL on invalid
+ combinations of key content
+
+Backport of
+git-svn-id: 
https://svn.apache.org/repos/asf/santuario/xml-security-cpp/trunk@1843562 
13f79535-47bb-0310-9956-ffa450edef68
+---
+ xsec/enc/OpenSSL/OpenSSLCryptoKeyDSA.cpp | 12 
+ xsec/enc/OpenSSL/OpenSSLCryptoKeyEC.cpp  | 12 
+ xsec/enc/OpenSSL/OpenSSLCryptoKeyRSA.cpp | 12 
+ 3 files changed, 36 insertions(+)
+
+diff --git a/xsec/enc/OpenSSL/OpenSSLCryptoKeyDSA.cpp 
b/xsec/enc/OpenSSL/OpenSSLCryptoKeyDSA.cpp
+index 57999a2..5bdf133 100644
+--- a/xsec/enc/OpenSSL/OpenSSLCryptoKeyDSA.cpp
 b/xsec/enc/OpenSSL/OpenSSLCryptoKeyDSA.cpp
+@@ -164,6 +164,12 @@ bool OpenSSLCryptoKeyDSA::verifyBase64Signature(unsigned 
char * hashBuf,
+   "OpenSSL:DSA - Attempt to validate signature with empty 
key");
+   }
+ 
++XSECCryptoKey::KeyType keyType = getKeyType();
++if (keyType != KEY_DSA_PAIR && keyType != KEY_DSA_PUBLIC) {
++throw XSECCryptoException(XSECCryptoException::DSAError,
++"OpenSSL:DSA - Attempt to validate signature without public key");
++}
++
+ char* cleanedBase64Signature;
+   unsigned int cleanedBase64SignatureLen = 0;
+ 
+@@ -264,6 +270,12 @@ unsigned int 
OpenSSLCryptoKeyDSA::signBase64Signature(unsigned char * hashBuf,
+   "OpenSSL:DSA - Attempt to sign data with empty key");
+   }
+ 
++KeyType keyType = getKeyType();
++if (keyType != KEY_DSA_PAIR && keyType != KEY_DSA_PRIVATE) {
++throw XSECCryptoException(XSECCryptoException::DSAError,
++"OpenSSL:DSA - Attempt to sign data without private key");
++}
++
+   DSA_SIG * dsa_sig;
+ 
+   dsa_sig = DSA_do_sign(hashBuf, hashLen, mp_dsaKey);
+diff --git a/xsec/enc/OpenSSL/OpenSSLCryptoKeyEC.cpp 
b/xsec/enc/OpenSSL/OpenSSLCryptoKeyEC.cpp
+index 3233343..09ba69e 100644
+--- a/xsec/enc/OpenSSL/OpenSSLCryptoKeyEC.cpp
 b/xsec/enc/OpenSSL/OpenSSLCryptoKeyEC.cpp
+@@ -151,6 +151,12 @@ bool 
OpenSSLCryptoKeyEC::verifyBase64SignatureDSA(unsigned char * hashBuf,
+   "OpenSSL:EC - Attempt to validate signature with empty 
key");
+   }
+ 
++KeyType keyType = getKeyType();
++if (keyType != KEY_EC_PAIR && keyType != KEY_EC_PUBLIC) {
++throw XSECCryptoException(XSECCryptoException::ECError,
++"OpenSSL:EC - Attempt to validate signature without public key");
++}
++
+   char * cleanedBase64Signature;
+   unsigned int cleanedBase64SignatureLen = 0;
+ 
+@@ -225

Bug#945018: systemd: please backport patch to fix sysctl warning on boot to buster

[Ferenc Wágner]

Package: systemd
Version: 241-7~deb10u2
Severity: minor

Dear Maintainer,

Booting a pretty stock buster system produces the following warning:

[   46.321681] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid 
argument

This is due to a stable kernel update, see
https://patchwork.openembedded.org/patch/162942/:

> Due to improved validation of sysctl settings in recent kernels (5.2+, but
> also stable kernels like 4.19.53), systemd will log an error message like
> [...]

The upstream issue is https://github.com/systemd/systemd/issues/12803,
and the master PR is https://github.com/systemd/systemd/pull/12808.
Please consider including this in a future stable update.
-- 
Thanks,
Feri.

Bug#939823: icinga2-bin: Notifications on downtimed services sent during shutdown of icinga2 service

[Ferenc Wágner]

Package: icinga2-bin
Version: 2.10.3-2
Severity: important
Tags: upstream
Forwarded: https://github.com/Icinga/icinga2/issues/7401

Dear Maintainer,

This bug has a major impact on the usability of Icinga2, because
spurious notifications mean considerable disruption for the staff
receiving them.  Please consider fixing it in a stable update.
-- 
Thanks,
Feri.

Bug#939339: munin-node: systemd hardening hurts the df plugin

[Ferenc Wágner]

Package: munin-node
Version: 2.0.49-1~bpo9+1
Severity: normal

Dear Maintainer,

Today I noticed that my /home mount is not graphed by the df plugin
against my expectations.  After too much debugging I realized that the
ProtectHome=true setting in /lib/systemd/system/munin-node.service
causes the problem.  After overriding it, the missing graph reappeared.
Please consider dropping this directive from the unit file.
-- 
Thanks,
Feri.

Bug#939263: nagios-nrpe-server: uses legacy directory /var/run

[Ferenc Wágner]

Package: nagios-nrpe-server
Version: 3.2.1-2
Severity: minor

Dear Maintainer,

I see this in the logs of a buster machine:

Sep  2 16:07:58 gum systemd-tmpfiles[21883]: 
[/usr/lib/tmpfiles.d/nagios-nrpe-server.conf:2] Line references path below 
legacy directory /var/run/, updating /var/run/nagios → /run/nagios; please 
update the tmpfiles.d/ drop-in file accordingly.

Actually, I'd recommend dropping tmpfiles.d/nagios-nrpe-server.conf
altogether; please consider switching to using the RuntimeDirectory
directive in the unit file.
-- 
Thanks,
Feri.

Bug#933991: src:libxcomposite: depends on empty transitional package x11proto-composite-dev

[Ferenc Wágner]

Package: src:libxcomposite
Version: 1:0.4.4-2
Severity: normal

Dear Maintainer,

x11proto-composite-dev is a "transitional dummy package" by its
description, and indeed empty, but I can't remove it from my system
because libxcomposite-dev depends on it (and the libxcomposite source
package build-depends on it).  Please consider dropping this dependency.
(BTW, there are similar problems with the other x11proto-*-dev dummy
packages, libx11(-dev) depends on some of them, etc.)
-- 
Thanks,
Feri.

Bug#930671: libauthen-radius-perl: most basic usage stopped working

[Ferenc Wágner]

Package: libauthen-radius-perl
Version: 0.29-1
Severity: important

Dear Maintainer,

I recently upgraded to buster and noticed that our RADIUS test plugin
does not work anymore.  Downgrading libauthen-radius-perl to 0.27-1
fixes the issue.  Take the first example from the top of the man page:

  use Authen::Radius;
  $r = new Authen::Radius(Host => 'myserver', Secret => 'mysecret');
  print "auth result=", $r->check_pwd('myname', 'mypwd'), "\n";

If I substitute the correct IPv4 address, secret, user name and password
into the above, the result is 1 (success) with 0.27-1, but upgrading to
0.29-1 gives an error message instead:

  unknown attr name 1 at /usr/share/perl5/Authen/Radius.pm line 865.

There might be a workaround via using the lower level operations instead
of the check_pwd method, but I haven't found it yet.  Please advise.
-- 
Thanks,
Feri.

Bug#930061: openssl: causes regression in kronosnet memory checks

[Ferenc Wágner]

Package: openssl
Version: 1.1.1c-1
Severity: serious

(You seem to use the serious severity for such reports.)

Dear OpenSSL Maintainers,

Please see https://github.com/kronosnet/kronosnet/issues/226: the
Kronosnet upstream CI started to fail in the Valgrind memory checks
after the libssl upgrade from 1.1.1b-2 to 1.1.1c-1.  This is
reproducible with kronosnet_1.8-2 in testing and unstable by building it
with valgrind installed: "make -C libknet/tests check-memcheck" gives a
failure in api_knet_send_crypto_test:

==28725== Thread 8:
==28725== Conditional jump or move depends on uninitialised value(s)
==28725==at 0xC4BED7B: ??? (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
==28725==by 0xC4BF422: ??? (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
==28725==by 0xC4C00B9: ??? (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
==28725==by 0xC4C0C02: ??? (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
==28725==by 0x48454B7: encrypt_openssl (crypto_openssl.c:184)
==28725==by 0x4845C5D: opensslcrypto_encrypt_and_signv 
(crypto_openssl.c:326)
==28725==by 0x4845D19: opensslcrypto_encrypt_and_sign (crypto_openssl.c:360)
==28725==by 0x48595C1: _handle_check_each (threads_heartbeat.c:74)
==28725==by 0x48595C1: _send_pings (threads_heartbeat.c:148)
==28725==by 0x48598F4: _handle_heartbt_thread (threads_heartbeat.c:217)
==28725==by 0x4877FA2: start_thread (pthread_create.c:486)
==28725==by 0x498A4CE: clone (clone.S:95)
[...]

I don't know whether this is a genuine library bug, an application bug
or a valgrind bug, but wanted to make sure you see this before the buster
release.  The Kronosnet DebCI tests don't run these tests automatically.
-- 
Regards,
Feri.

Bug#930026: unblock: pacemaker/2.0.1-5

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package pacemaker

Dear Release Team,

It turned out that the original upstream security fixes for #927714
(already contained in pacemaker 2.0.1-4 in testing) introduced some
bugs, which were fixed in three followup upstream patches.  These are
all lumped together in the proposed 1.1.16-1+deb9u1 security upload (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927714#29).  The
following debdiff brings the above fixes of the fixes into buster as well:

diff -Nru pacemaker-2.0.1/debian/changelog pacemaker-2.0.1/debian/changelog
--- pacemaker-2.0.1/debian/changelog2019-05-12 14:23:41.0 +0200
+++ pacemaker-2.0.1/debian/changelog2019-06-02 14:01:06.0 +0200
@@ -1,3 +1,12 @@
+pacemaker (2.0.1-5) unstable; urgency=medium
+
+  * [17ae230] Backport three more patches from upstream fixing memory safety
+bugs.
+Clearing up fallout from the preceding security fixes.
+Thanks to Ken Gaillot 
+
+ -- Ferenc Wágner   Sun, 02 Jun 2019 14:01:06 +0200
+
 pacemaker (2.0.1-4) unstable; urgency=high
 
   * [54ace53] Fix check for already present statoverride.
diff -Nru 
pacemaker-2.0.1/debian/patches/from-upstream/Fix-libcrmcommon-avoid-use-of-NULL-when-checking-whether-.patch
 
pacemaker-2.0.1/debian/patches/from-upstream/Fix-libcrmcommon-avoid-use-of-NULL-when-checking-whether-.patch
--- 
pacemaker-2.0.1/debian/patches/from-upstream/Fix-libcrmcommon-avoid-use-of-NULL-when-checking-whether-.patch
1970-01-01 01:00:00.0 +0100
+++ 
pacemaker-2.0.1/debian/patches/from-upstream/Fix-libcrmcommon-avoid-use-of-NULL-when-checking-whether-.patch
2019-06-02 13:49:43.0 +0200
@@ -0,0 +1,22 @@
+From: Ken Gaillot 
+Date: Wed, 24 Apr 2019 16:25:46 -0500
+Subject: Fix: libcrmcommon: avoid use-of-NULL when checking whether process
+ is active
+
+---
+ lib/common/pid.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/common/pid.c b/lib/common/pid.c
+index 2439680..4fbf2dd 100644
+--- a/lib/common/pid.c
 b/lib/common/pid.c
+@@ -57,7 +57,7 @@ crm_pid_active(long pid, const char *daemon)
+ } else if (rc == 0 && (daemon == NULL || have_proc_pid == -1)) {
+ return 1;  /* kill as the only indicator, cannot double check */
+ 
+-} else {
++} else if (daemon != NULL) {
+ /* make sure PID hasn't been reused by another process
+XXX: might still be just a zombie, which could confuse decisions */
+ bool checked_through_kill = (rc == 0);
diff -Nru 
pacemaker-2.0.1/debian/patches/from-upstream/Log-libcrmcluster-improve-CPG-membership-messages.patch
 
pacemaker-2.0.1/debian/patches/from-upstream/Log-libcrmcluster-improve-CPG-membership-messages.patch
--- 
pacemaker-2.0.1/debian/patches/from-upstream/Log-libcrmcluster-improve-CPG-membership-messages.patch
1970-01-01 01:00:00.0 +0100
+++ 
pacemaker-2.0.1/debian/patches/from-upstream/Log-libcrmcluster-improve-CPG-membership-messages.patch
2019-06-02 13:49:43.0 +0200
@@ -0,0 +1,182 @@
+From: Ken Gaillot 
+Date: Fri, 12 Apr 2019 09:46:51 -0500
+Subject: Log: libcrmcluster: improve CPG membership messages
+
+Show CPG event reason when provided by corosync, make messages more readable,
+upgrade duplicate pid messages to warnings (and log only one message in those
+cases).
+---
+ lib/cluster/cpg.c | 91 ++-
+ 1 file changed, 56 insertions(+), 35 deletions(-)
+
+diff --git a/lib/cluster/cpg.c b/lib/cluster/cpg.c
+index 2898c51..ef6fa36 100644
+--- a/lib/cluster/cpg.c
 b/lib/cluster/cpg.c
+@@ -360,8 +360,6 @@ pcmk_message_common_cs(cpg_handle_t handle, uint32_t 
nodeid, uint32_t pid, void
+ return NULL;
+ }
+ 
+-#define PEER_NAME(peer) ((peer)? ((peer)->uname? (peer)->uname : "") 
: "")
+-
+ static int cmp_member_list_nodeid(const void *first,
+   const void *second)
+ {
+@@ -376,6 +374,32 @@ static int cmp_member_list_nodeid(const void *first,
+ return 0;
+ }
+ 
++static const char *
++cpgreason2str(cpg_reason_t reason)
++{
++switch (reason) {
++case CPG_REASON_JOIN:   return " via cpg_join";
++case CPG_REASON_LEAVE:  return " via cpg_leave";
++case CPG_REASON_NODEDOWN:   return " via cluster exit";
++case CPG_REASON_NODEUP: return " via cluster join";
++case CPG_REASON_PROCDOWN:   return " for unknown reason";
++default:break;
++}
++return "";
++}
++
++static inline const char *
++peer_name(crm_node_t *peer)
++{
++if (peer == NULL) {
++return "unknown node";
++} else if (peer->uname == NULL) {
++return "peer node";
++} else {
++return peer->uname;
++}
++}
++
+ v

Bug#929269: coturn: overwrites database file /var/lib/turn/turndb on upgrade or reinstall

[Ferenc Wágner]

Package: coturn
Version: 4.3.1.2-1
Severity: critical
Justification: causes serious data loss

Dear Misi,

The coturn package ships /var/lib/turn/turndb as an empty SQLite
database template, thus unexpectedly overwrites it without warning on
upgrade or reinstall, destroying any data the user might have added to
it (such as user names, passwords, realms, IP addresses and so on).

Please stop shipping this file, the example (as currently shipped)
should be enough.  At most create it in the postinst if it does not
exist yet.
-- 
Thanks,
Feri.

Bug#928644: unblock: libqb/1.0.5-1

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libqb

Dear Release Team,

The 1.0.4 upstream security release of libqb introduced regressions,
which were fixed in 1.0.4-2 by the addition of some quilt patches.
These patches were upstreamed and released as 1.0.5.  So the 1.0.5-1
version currently in unstable has no actual code changes, the patched
tree is identical to that of 1.0.4-2, except for the man page timestamps
(these files are rebuilt anyway), the version number and a punctuation
fix in the documentation (which also went upstream after 1.0.5).

The following debdiff is therefore not very insightful:

diff -Nru libqb-1.0.4/ChangeLog libqb-1.0.5/ChangeLog
--- libqb-1.0.4/ChangeLog   2019-04-12 10:30:53.0 +0200
+++ libqb-1.0.5/ChangeLog   2019-04-25 10:30:00.0 +0200
@@ -1,3 +1,35 @@
+2019-04-25  Christine Caulfield  
+
+   version: bump soname for 1.0.5 release
+
+2019-04-23  Ferenc Wágner  
+
+   Let remote_tempdir() assume a NUL-terminated name
+   This is the case already.  We also fix a buffer overflow opportunity in
+   the memcpy() call by this change.
+
+   Make it impossible to truncate or overflow the connection description
+   It's hard to predict the length of formatted output, so we'd better
+   notice (and abort) if the description is truncated.  Incidentally,
+   mkdtemp() does this for us in the shared memory branch, but do an
+   explicit check there as well for consistency, and get rid of the wrongly
+   parametrized strncat() risking a buffer overflow (CONNECTION_DESCRIPTION
+   is not the length of the source "/qb").
+   Similar truncation checks should be added to qb_ipcs_{shm,us}_connect()
+   where they build the request/response names, and possibly to other
+   places using snprintf().
+
+   Allow group access to the IPC directory
+   And don't abort if we aren't permitted to chown() it.  The client might
+   still have the privileges to enter it.
+
+   Errors are represented as negative values
+
+   Fix garbled Doxygen markup
+   Part of d0ec0a6 on the master branch: fix the unreadable docstring.
+
+   Fix spelling: plaform -> platform
+
 2019-04-12  Christine Caulfield  
 
version: update version-info for 1.0.4 release
diff -Nru libqb-1.0.4/configure libqb-1.0.5/configure
--- libqb-1.0.4/configure   2019-04-12 10:30:39.0 +0200
+++ libqb-1.0.5/configure   2019-04-25 10:29:47.0 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for libqb 1.0.4.
+# Generated by GNU Autoconf 2.69 for libqb 1.0.5.
 #
 # Report bugs to .
 #
@@ -590,8 +590,8 @@
 # Identity of this package.
 PACKAGE_NAME='libqb'
 PACKAGE_TARNAME='libqb'
-PACKAGE_VERSION='1.0.4'
-PACKAGE_STRING='libqb 1.0.4'
+PACKAGE_VERSION='1.0.5'
+PACKAGE_STRING='libqb 1.0.5'
 PACKAGE_BUGREPORT='develop...@clusterlabs.org'
 PACKAGE_URL=''
 
@@ -1407,7 +1407,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures libqb 1.0.4 to adapt to many kinds of systems.
+\`configure' configures libqb 1.0.5 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1477,7 +1477,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of libqb 1.0.4:";;
+ short | recursive ) echo "Configuration of libqb 1.0.5:";;
esac
   cat <<\_ACEOF
 
@@ -1611,7 +1611,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-libqb configure 1.0.4
+libqb configure 1.0.5
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2388,7 +2388,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by libqb $as_me 1.0.4, which was
+It was created by libqb $as_me 1.0.5, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4569,7 +4569,7 @@
 
 # Define the identity of the package.
  PACKAGE='libqb'
- VERSION='1.0.4'
+ VERSION='1.0.5'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -21860,7 +21860,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by libqb $as_me 1.0.4, which was
+This file was extended by libqb $as_me 1.0.5, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -21930,7 +21930,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed '

Bug#927292: libqb: Breaks applications not running as root (for example pacemaker-based AKA cib)

[Ferenc Wágner]

Source: libqb
Version: 1.0.4-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Forwarded: https://github.com/ClusterLabs/libqb/issues/338

IPC connection setup is aborted if the application is unable to chown()
the temporary communication directory under /dev/shm to the credentials
of the client.  This can happen if the application isn't running as
root, but isn't necessarily fatal if the client has appropriate privileges.

Bug#927159: libqb: Insecure Temporary Files

[Ferenc Wágner]

Source: libqb
Version: 1.0.3-2
Severity: grave
Tags: patch upstream security
Justification: user security hole
Forwarded: https://github.com/ClusterLabs/libqb/issues/338
Control: found -1 0.11.1-2

Libqb creates files in world-writable directories (/dev/shm, /tmp) with
rather predictable file names (for example in case of USBGuard with names
like /dev/shm/qb-usbguard-request-7096-835-12-data). Also O_EXCL flag is
not used when opening the files. This could be exploited by a local
attacker to overwrite privileged system files (if not restricted by
sandboxing, MAC or symlinking policies).

Bug#926346: unblock: kronosnet/1.8-2

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package kronosnet

Dear Release Team,

The buildd setup got me again: the upload you kindly unblocked in
#926246 failed to build on all release architectures, because the
official buildds have module loading disabled, thus lack SCTP support,
and the changes introduced a new unit test which wasn't protected from
this yet.  I already uploaded a new revision 1.8-2 which adds a patch to
skip this new test if the SCTP protocol is not supported.  (The same
tests succeed on debci all right, BTW.)  I've blacklisted the sctp
module on my test machine to catch this problem next time.  For now,
please unblock 1.8-2; I provide the incremental debdiff below for ease
of review.

Thanks,
Feri.

diff -Nru kronosnet-1.8/debian/changelog kronosnet-1.8/debian/changelog
--- kronosnet-1.8/debian/changelog  2019-04-01 23:59:14.0 +0200
+++ kronosnet-1.8/debian/changelog  2019-04-03 10:33:30.0 +0200
@@ -1,3 +1,10 @@
+kronosnet (1.8-2) unstable; urgency=medium
+
+  * [b6a2cdc] New patch: send test: skip the SCTP test if SCTP is not supported
+by the kernel
+
+ -- Ferenc Wágner   Wed, 03 Apr 2019 10:33:30 +0200
+
 kronosnet (1.8-1) unstable; urgency=medium
 
   * [ff7beff] New upstream release (1.8)
diff -Nru 
kronosnet-1.8/debian/patches/send-test-skip-the-SCTP-test-if-SCTP-is-not-supported-by-.patch
 
kronosnet-1.8/debian/patches/send-test-skip-the-SCTP-test-if-SCTP-is-not-supported-by-.patch
--- 
kronosnet-1.8/debian/patches/send-test-skip-the-SCTP-test-if-SCTP-is-not-supported-by-.patch
1970-01-01 01:00:00.0 +0100
+++ 
kronosnet-1.8/debian/patches/send-test-skip-the-SCTP-test-if-SCTP-is-not-supported-by-.patch
2019-04-03 10:33:22.0 +0200
@@ -0,0 +1,28 @@
+From: =?utf-8?q?Ferenc_W=C3=A1gner?= 
+Date: Wed, 3 Apr 2019 10:26:11 +0200
+Subject: send test: skip the SCTP test if SCTP is not supported by the kernel
+
+For example, module loading is disabled on Debian build daemons.
+---
+ libknet/tests/api_knet_send.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/libknet/tests/api_knet_send.c b/libknet/tests/api_knet_send.c
+index f241201..1c55db1 100644
+--- a/libknet/tests/api_knet_send.c
 b/libknet/tests/api_knet_send.c
+@@ -173,12 +173,13 @@ static void test(uint8_t transport)
+   }
+ 
+   if (knet_link_set_config(knet_h, 1, 0, transport, , , 0) < 0) {
++  int exit_status = transport == KNET_TRANSPORT_SCTP && errno == 
EPROTONOSUPPORT ? SKIP : FAIL;
+   printf("Unable to configure link: %s\n", strerror(errno));
+   knet_host_remove(knet_h, 1);
+   knet_handle_free(knet_h);
+   flush_logs(logfds[0], stdout);
+   close_logpipes(logfds);
+-  exit(FAIL);
++  exit(exit_status);
+   }
+ 
+   if (knet_link_set_enable(knet_h, 1, 0, 1) < 0) {
diff -Nru kronosnet-1.8/debian/patches/series 
kronosnet-1.8/debian/patches/series
--- kronosnet-1.8/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ kronosnet-1.8/debian/patches/series 2019-04-03 10:33:22.0 +0200
@@ -0,0 +1 @@
+send-test-skip-the-SCTP-test-if-SCTP-is-not-supported-by-.patch

unblock kronosnet/1.8-2

Bug#926203: unblock: pacemaker/2.0.1-2

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package pacemaker

Dear Release Team,

As reported in #925354, the newly reintroduced pacemaker-dev package
missed Breaks+Replaces against some long-obsolete packages from wheezy,
leading to file conflicts in certain situations.  The version already in
unstable fixes this bug, please unblock it.

Thanks,
Feri.

diff -Nru pacemaker-2.0.1/debian/changelog pacemaker-2.0.1/debian/changelog
--- pacemaker-2.0.1/debian/changelog2019-03-04 21:34:46.0 +0100
+++ pacemaker-2.0.1/debian/changelog2019-04-01 13:39:28.0 +0200
@@ -1,3 +1,19 @@
+pacemaker (2.0.1-2) unstable; urgency=medium
+
+  * [d8939cc] Avoid file conflicts with leftover packages from wheezy.
+Pacemaker-dev in wheezy was a metapackage pulling in several -dev
+packages.  It is removed during the jessie dist-upgrade due to
+dependency problems, and jessie does not have pacemaker at all, so these
+obsolete -dev packages are left behind, unless replaced by the
+renamed -dev packages from jessie-backports or later from stretch, both
+of which requires manual action.  Lacking that, a manual install of the
+reintroduced pacemaker-dev from buster will try to overwrite headers
+from those obsolete -dev packages causing file conflicts, because the
+old Breaks+Replaces relations weren't carried over from the stretch
+packages. (Closes: #925354)
+
+ -- Ferenc Wágner   Mon, 01 Apr 2019 13:39:28 +0200
+
 pacemaker (2.0.1-1) unstable; urgency=medium
 
   * [7d6ff2e] New upstream release (2.0.1)
diff -Nru pacemaker-2.0.1/debian/control pacemaker-2.0.1/debian/control
--- pacemaker-2.0.1/debian/control  2019-03-04 21:30:38.0 +0100
+++ pacemaker-2.0.1/debian/control  2019-03-29 09:06:28.0 +0100
@@ -332,6 +332,10 @@
  liblrmd-dev (<< 2),
  libpengine-dev (<< 2),
  libstonithd-dev (<< 2),
+# header ghosts from wheezy, where pacemaker-dev used to exist:
+ libcrmcluster1-dev,
+ libcrmcommon2-dev,
+ libpengine3-dev,
 Replaces:
  libcib-dev (<< 2),
  libcrmcluster-dev (<< 2),
@@ -340,6 +344,10 @@
  liblrmd-dev (<< 2),
  libpengine-dev (<< 2),
  libstonithd-dev (<< 2),
+# header ghosts from wheezy, where pacemaker-dev used to exist:
+ libcrmcluster1-dev,
+ libcrmcommon2-dev,
+ libpengine3-dev,
 Description: cluster resource manager development
  ${S:X-Common-Description}
  .

unblock pacemaker/2.0.1-2

Bug#926162: unblock: opensaml/3.0.1-1

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package opensaml

Dear Release Team,

To fix their latest security bug, Shibboleth upstream made a coordinated
patch release of the full stack, as usual.  You already unblocked the
critical part of this (xmltooling and shibboleth-sp) and they even
reached testing, so we're good.  OpenSAML, the middle component also
gained a small patch, and I'm asking you about that now.  It isn't
critical at all, just a tuning down of a handful or error messages to
warn level.  As upstream put it: "The goal of those changes was to reach
a state in which any ERROR in the log requires a necessary operational
response." I think eliminating this deviation would improve the
administration experience and the upstream support opportunities for the
users of buster, thus I ask you to consider accepting it.

The debdiff below does not convey properly how small this change really
is, because the current 3.0.0-2 package carries a forward ported
upstream patch CPPOST-110-Rebenchmark-tests-with-SHA256-disgest.patch,
which was released with 3.0.1 and thus removed from the Debian patch
queue.  So the biggest part of this diff does not appear if you compare
the patched trees.

The result of dh_auto_test was ignored in 3.0.0-1 waiting for the above
patch, and that should have already been reverted in 3.0.0-2, because
all tests succeed again with the patch (I checked the buildd logs
manually now).  So they're safe to reenable and have no effect on the
binary packages.

Finally, the path change in HTTPMetadataProvider.xml fixes a unit test
which requires network access and is skipped during the package build
anyway.  (But also succeeds after the necessary URL configuration now.)

If you're fine with this, I'm ready to upload opensaml/3.0.1-1 to
unstable.

Thanks,
Feri.

diff -Nru opensaml-3.0.0/configure opensaml-3.0.1/configure
--- opensaml-3.0.0/configure2018-07-10 03:09:31.0 +0200
+++ opensaml-3.0.1/configure2019-03-08 16:01:45.0 +0100
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for opensaml 3.0.0.
+# Generated by GNU Autoconf 2.69 for opensaml 3.0.1.
 #
 # Report bugs to .
 #
@@ -590,8 +590,8 @@
 # Identity of this package.
 PACKAGE_NAME='opensaml'
 PACKAGE_TARNAME='opensaml'
-PACKAGE_VERSION='3.0.0'
-PACKAGE_STRING='opensaml 3.0.0'
+PACKAGE_VERSION='3.0.1'
+PACKAGE_STRING='opensaml 3.0.1'
 PACKAGE_BUGREPORT='https://issues.shibboleth.net/'
 PACKAGE_URL=''
 
@@ -1430,7 +1430,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures opensaml 3.0.0 to adapt to many kinds of systems.
+\`configure' configures opensaml 3.0.1 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1500,7 +1500,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of opensaml 3.0.0:";;
+ short | recursive ) echo "Configuration of opensaml 3.0.1:";;
esac
   cat <<\_ACEOF
 
@@ -1658,7 +1658,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-opensaml configure 3.0.0
+opensaml configure 3.0.1
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2202,7 +2202,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by opensaml $as_me 3.0.0, which was
+It was created by opensaml $as_me 3.0.1, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -3067,7 +3067,7 @@
 
 # Define the identity of the package.
  PACKAGE='opensaml'
- VERSION='3.0.0'
+ VERSION='3.0.1'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -21436,7 +21436,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by opensaml $as_me 3.0.0, which was
+This file was extended by opensaml $as_me 3.0.1, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -21502,7 +21502,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-opensaml config.status 3.0.0
+opensaml config.status 3.0.1
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru opensaml-3.0.0/configure.ac opensaml-3.0.1/configure.ac
--- opensaml-3.0.0/configure.ac 2018-07-10 03:09:09.0 +0200
+++ opensaml-3.0.1/configure.ac 2019-02-21 21:05:56.0 +0100
@@ -1,5 +1,5 @@
 AC_PREREQ([2.50])
-AC_INIT([opensaml],[3.0.0],[https://issues.shibboleth.net/],[opensaml])

Bug#925524: init-system-helpers: Please provide a stretch backport for debhelper 12~

[Ferenc Wágner]

Package: init-system-helpers
Version: 1.48
Severity: wishlist

Dear Maintainers,

Debhelper compat level 12 is stable and available in stretch-backports,
but uses the --skip-systemd-native option of invoke-rc.d, thus adds
init-system-helpers (>= 1.54~) to misc:Pre-Depends.  This is necessary
to fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887904.
However, the resulting pre-dependency can't be satisfied in stretch,
making the resulting binaries of compat 12 packages uninstallable in
stretch.  Could you please provide a stretch backport of a suitable
init-system-helpers version to accompany debhelper 12~, or do you
recommend some other solution to this problem?  (I suppose installing a
newer version of init-system-helpers manually to a stretch system
wouldn't break it, but it's rather inconvenient even if you confirm it.)
-- 
Thanks,
Feri.

Bug#924748: unblock: shibboleth-sp/3.0.4+dfsg1-1

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package shibboleth-sp

Dear Release Team,

When upstream fixed #924346 in xmltooling, they also fixed the same
problem (uncaught parser exceptions) in shibboleth-sp to prevent DoS
crashes that haven't been identified yet.  The fixes were published
together in new patch-level upstream releases for the whole Shibboleth
Service Provider stack: xmltooling, opensaml and shibboleth-sp.  Beyond
the DoS prevention, shibboleth-sp 3.0.4 consists of three other bugfixes:
* incorrect C++ code usage pattern invoking undefined behavior via
  boost::bind (https://issues.shibboleth.net/jira/browse/SSPCPP-847,
  already mentioned in unblock request #924577);
* certain web applications provoking unbounded cookie data growth
  (https://issues.shibboleth.net/jira/browse/SSPCPP-851); and
* documented configuration settings being ignored in some contexts
  (https://issues.shibboleth.net/jira/browse/SSPCPP-848).
This last one can be worked around by verbosely expanding the affected
configuration constructs, so it can be considered a minor issue.  But
the other three are major or potentially serious, so I ask for your
permission to to upload 3.0.4+dfsg1-1 to unstable with a future unblock.

Thanks,
Feri.

diff -Nru shibboleth-sp-3.0.3+dfsg1/configure 
shibboleth-sp-3.0.4+dfsg1/configure
--- shibboleth-sp-3.0.3+dfsg1/configure 2018-12-12 20:16:00.0 +0100
+++ shibboleth-sp-3.0.4+dfsg1/configure 2019-03-08 16:15:39.0 +0100
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for shibboleth 3.0.3.
+# Generated by GNU Autoconf 2.69 for shibboleth 3.0.4.
 #
 # Report bugs to .
 #
@@ -590,8 +590,8 @@
 # Identity of this package.
 PACKAGE_NAME='shibboleth'
 PACKAGE_TARNAME='shibboleth-sp'
-PACKAGE_VERSION='3.0.3'
-PACKAGE_STRING='shibboleth 3.0.3'
+PACKAGE_VERSION='3.0.4'
+PACKAGE_STRING='shibboleth 3.0.4'
 PACKAGE_BUGREPORT='https://issues.shibboleth.net/'
 PACKAGE_URL=''
 
@@ -1522,7 +1522,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures shibboleth 3.0.3 to adapt to many kinds of systems.
+\`configure' configures shibboleth 3.0.4 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1592,7 +1592,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of shibboleth 3.0.3:";;
+ short | recursive ) echo "Configuration of shibboleth 3.0.4:";;
esac
   cat <<\_ACEOF
 
@@ -1792,7 +1792,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-shibboleth configure 3.0.3
+shibboleth configure 3.0.4
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2670,7 +2670,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by shibboleth $as_me 3.0.3, which was
+It was created by shibboleth $as_me 3.0.4, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -3535,7 +3535,7 @@
 
 # Define the identity of the package.
  PACKAGE='shibboleth-sp'
- VERSION='3.0.3'
+ VERSION='3.0.4'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -24198,7 +24198,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by shibboleth $as_me 3.0.3, which was
+This file was extended by shibboleth $as_me 3.0.4, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -24264,7 +24264,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-shibboleth config.status 3.0.3
+shibboleth config.status 3.0.4
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru shibboleth-sp-3.0.3+dfsg1/configure.ac 
shibboleth-sp-3.0.4+dfsg1/configure.ac
--- shibboleth-sp-3.0.3+dfsg1/configure.ac  2018-10-12 20:06:42.0 
+0200
+++ shibboleth-sp-3.0.4+dfsg1/configure.ac  2019-03-08 16:09:43.0 
+0100
@@ -1,5 +1,5 @@
 AC_PREREQ([2.50])
-AC_INIT([shibboleth],[3.0.3],[https://issues.shibboleth.net/],[shibboleth-sp])
+AC_INIT([shibboleth],[3.0.4],[https://issues.shibboleth.net/],[shibboleth-sp])
 AC_CONFIG_SRCDIR(shibsp)
 AC_CONFIG_AUX_DIR(build-aux)
 AC_CONFIG_MACRO_DIR(m4)
diff -Nru shibboleth-sp-3.0.3+dfsg1/config_win32.h 
shibboleth-sp-3.0.4+dfsg1/config_win32.h
--- shibboleth-sp-3.0.3+dfsg1/config_win32.h2018-10-12 20:06:42.0 
+0200
+++ shibboleth-sp-3.0.4+dfsg1/config_win32.h2019-03-08 16:09:43.0 
+0100
@@ -121,13 

Bug#924577: unblock: xmltooling/3.0.4-1

[Ferenc Wágner]

 
 /* Define to the one symbol short name of this package. */
 #define PACKAGE_TARNAME "xmltooling"
 
 /* Define to the version of this package. */
-#define PACKAGE_VERSION "3.0.3"
+#define PACKAGE_VERSION "3.0.4"
 
 /* Define to the necessary symbol if this constant uses a non-standard name on
your system. */
@@ -125,7 +125,7 @@
 /* #undef TM_IN_SYS_TIME */
 
 /* Version number of package */
-#define VERSION "3.0.3"
+#define VERSION "3.0.4"
 
 /* Define if you wish to disable XML-Security-dependent features. */
 /* #undef XMLTOOLING_NO_XMLSEC */
diff -Nru xmltooling-3.0.3/debian/changelog xmltooling-3.0.4/debian/changelog
--- xmltooling-3.0.3/debian/changelog   2018-12-24 10:51:09.0 +0100
+++ xmltooling-3.0.4/debian/changelog   2019-03-14 14:58:36.0 +0100
@@ -1,3 +1,22 @@
+xmltooling (3.0.4-1) unstable; urgency=high
+
+  * [f185b26] New upstream security release: 3.0.4
+DSA-4407-1, CVE-2019-9628: uncaught exception on malformed XML
+declaration.
+Invalid data in the XML declaration causes an exception of a type
+that was not handled properly in the parser class and propagates an
+unexpected exception type.
+This generally manifests as a crash in the calling code, which in the
+Service Provider software's case is usually the shibd daemon process,
+but can be Apache in some cases. Note that the crash occurs prior to
+evaluation of a message's authenticity, so can be exploited by an
+untrusted attacker.
+https://shibboleth.net/community/advisories/secadv_20190311.txt
+https://issues.shibboleth.net/jira/browse/CPPXT-143
+Thanks to Scott Cantor (Closes: #924346)
+
+ -- Ferenc Wágner   Thu, 14 Mar 2019 14:58:36 +0100
+
 xmltooling (3.0.3-1) unstable; urgency=medium
 
   [ Ferenc Wágner ]
diff -Nru xmltooling-3.0.3/xmltooling/Makefile.am 
xmltooling-3.0.4/xmltooling/Makefile.am
--- xmltooling-3.0.3/xmltooling/Makefile.am 2018-11-09 16:42:30.0 
+0100
+++ xmltooling-3.0.4/xmltooling/Makefile.am 2019-03-08 15:44:44.0 
+0100
@@ -229,7 +229,7 @@
$(PTHREAD_LIBS) \
$(dlopen_LIBS)
 
-AM_LDFLAGS = -version-info 8:3:0
+AM_LDFLAGS = -version-info 8:4:0
 
 libxmltooling_lite_la_SOURCES = \
${common_sources}
diff -Nru xmltooling-3.0.3/xmltooling/Makefile.in 
xmltooling-3.0.4/xmltooling/Makefile.in
--- xmltooling-3.0.3/xmltooling/Makefile.in 2018-11-09 16:42:35.0 
+0100
+++ xmltooling-3.0.4/xmltooling/Makefile.in 2019-03-08 15:45:41.0 
+0100
@@ -913,7 +913,7 @@
$(PTHREAD_LIBS) \
$(dlopen_LIBS)
 
-AM_LDFLAGS = -version-info 8:3:0
+AM_LDFLAGS = -version-info 8:4:0
 libxmltooling_lite_la_SOURCES = \
${common_sources}
 
diff -Nru xmltooling-3.0.3/xmltooling/soap/impl/CURLSOAPTransport.cpp 
xmltooling-3.0.4/xmltooling/soap/impl/CURLSOAPTransport.cpp
--- xmltooling-3.0.3/xmltooling/soap/impl/CURLSOAPTransport.cpp 2018-10-12 
19:33:58.0 +0200
+++ xmltooling-3.0.4/xmltooling/soap/impl/CURLSOAPTransport.cpp 2019-03-08 
15:44:44.0 +0100
@@ -90,7 +90,8 @@
 curl_easy_setopt(m_handle,CURLOPT_USERPWD,0);
 curl_easy_setopt(m_handle,CURLOPT_SSL_VERIFYHOST,2);
 curl_easy_setopt(m_handle,CURLOPT_HEADERDATA,this);
-m_headers=curl_slist_append(m_headers,"Content-Type: text/xml");
+m_headers = curl_slist_append(m_headers, "Content-Type: text/xml");
+m_headers = curl_slist_append(m_headers, "Expect:");
 }
 
 virtual ~CURLSOAPTransport() {
diff -Nru xmltooling-3.0.3/xmltooling/util/CurlURLInputStream.cpp 
xmltooling-3.0.4/xmltooling/util/CurlURLInputStream.cpp
--- xmltooling-3.0.3/xmltooling/util/CurlURLInputStream.cpp 2018-07-10 
03:00:14.0 +0200
+++ xmltooling-3.0.4/xmltooling/util/CurlURLInputStream.cpp 2019-03-08 
15:44:44.0 +0100
@@ -305,6 +305,8 @@
 " libcurl/" + LIBCURL_VERSION + ' ' + OPENSSL_VERSION_TEXT;
 fHeaders = curl_slist_append(fHeaders, ua.c_str());
 
+fHeaders = curl_slist_append(fHeaders, "Expect:");
+
 // Add User-Agent and cache headers.
 curl_easy_setopt(fEasy, CURLOPT_HTTPHEADER, fHeaders);
 
diff -Nru xmltooling-3.0.3/xmltooling/util/ParserPool.cpp 
xmltooling-3.0.4/xmltooling/util/ParserPool.cpp
--- xmltooling-3.0.3/xmltooling/util/ParserPool.cpp 2018-07-10 
03:00:14.0 +0200
+++ xmltooling-3.0.4/xmltooling/util/ParserPool.cpp 2019-03-08 
15:44:44.0 +0100
@@ -148,14 +148,28 @@
 checkinBuilder(janitor.release());
 return doc;
 }
-catch (XMLException& ex) {
+catch (const DOMException& ex) {
+parser->getDomConfig()->setParameter(XMLUni::fgDOMErrorHandler, 
(void*)nullptr);
+
parser->getDomConfig()->setParameter(XMLUni::fgXercesUserAdoptsDOMDocument, 
true);
+checkinBuilder(janitor.release());
+auto_ptr_char temp(e

Bug#923740: unblock: pacemaker/2.0.1-1

[Ferenc Wágner]

on of logs, CIB directory, and processes
   + tools: crm_verify returns reliable exit codes
-  + tools: crm_simulate simulated resource history uses same name as live 
cluster would
+  + tools: crm_simulate resource history uses same name as live cluster would
+
 
 * Fri Jul 6 2018 Ken Gaillot  Pacemaker-2.0.0-1
 - Changesets: 885
diff -Nru pacemaker-2.0.1~rc5/configure.ac pacemaker-2.0.1/configure.ac
--- pacemaker-2.0.1~rc5/configure.ac2019-02-25 22:35:40.0 +0100
+++ pacemaker-2.0.1/configure.ac2019-03-04 20:55:07.0 +0100
@@ -1075,7 +1075,7 @@
 AC_PATH_PROGS(GIT, git false)
 AC_MSG_CHECKING(build version)
 
-BUILD_VERSION=22ee9a769e
+BUILD_VERSION=9e909a5bdd
 if test $BUILD_VERSION != ":%h$"; then
 AC_MSG_RESULT(archive hash: $BUILD_VERSION)
 elif test -x $GIT -a -d .git; then
diff -Nru pacemaker-2.0.1~rc5/debian/changelog pacemaker-2.0.1/debian/changelog
--- pacemaker-2.0.1~rc5/debian/changelog2019-02-26 09:52:21.0 
+0100
+++ pacemaker-2.0.1/debian/changelog2019-03-04 21:34:46.0 +0100
@@ -1,3 +1,9 @@
+pacemaker (2.0.1-1) unstable; urgency=medium
+
+  * [7d6ff2e] New upstream release (2.0.1)
+
+ -- Ferenc Wágner   Mon, 04 Mar 2019 21:34:46 +0100
+
 pacemaker (2.0.1~rc5-1) unstable; urgency=medium
 
   * [79e9089] Drop duplicate external library linkages
diff -Nru pacemaker-2.0.1~rc5/doc/Pacemaker_Development/en-US/Ch-Coding.txt 
pacemaker-2.0.1/doc/Pacemaker_Development/en-US/Ch-Coding.txt
--- pacemaker-2.0.1~rc5/doc/Pacemaker_Development/en-US/Ch-Coding.txt   
2019-02-25 22:35:40.0 +0100
+++ pacemaker-2.0.1/doc/Pacemaker_Development/en-US/Ch-Coding.txt   
2019-03-04 20:55:07.0 +0100
@@ -243,7 +243,7 @@
 should be documented with Doxygen comment blocks, as Pacemaker's
 http://clusterlabs.org/pacemaker/doxygen/[online API documentation]
 is automatically generated via Doxygen. It is helpful to document
-private symols in the same way, with an +\internal+ tag in the
+private symbols in the same way, with an +\internal+ tag in the
 Doxygen comment.
 
 === Symbol Naming ===
diff -Nru 
pacemaker-2.0.1~rc5/doc/Pacemaker_Explained/en-US/Ch-Multi-site-Clusters.txt 
pacemaker-2.0.1/doc/Pacemaker_Explained/en-US/Ch-Multi-site-Clusters.txt
--- 
pacemaker-2.0.1~rc5/doc/Pacemaker_Explained/en-US/Ch-Multi-site-Clusters.txt
2019-02-25 22:35:40.0 +0100
+++ pacemaker-2.0.1/doc/Pacemaker_Explained/en-US/Ch-Multi-site-Clusters.txt
2019-03-04 20:55:07.0 +0100
@@ -208,7 +208,7 @@
 
 
 These commands will actually just print a message telling the user that they
-requre '--force'. That is probably a good exercise rather than letting novice
+require '--force'. That is probably a good exercise rather than letting novice
 users cut and paste '--force' here.
 
 
diff -Nru pacemaker-2.0.1~rc5/doc/Pacemaker_Explained/en-US/Ch-Resources.txt 
pacemaker-2.0.1/doc/Pacemaker_Explained/en-US/Ch-Resources.txt
--- pacemaker-2.0.1~rc5/doc/Pacemaker_Explained/en-US/Ch-Resources.txt  
2019-02-25 22:35:40.0 +0100
+++ pacemaker-2.0.1/doc/Pacemaker_Explained/en-US/Ch-Resources.txt  
2019-03-04 20:55:07.0 +0100
@@ -685,7 +685,7 @@
  indexterm:[Action,Property,enabled]
 
 |record-pending
-|FALSE
+|TRUE
 |If +true+, the intention to perform the operation is recorded so that
  GUIs and CLI tools can indicate that an operation is in progress.
  This is best set as an _operation default_ (see <>).
diff -Nru pacemaker-2.0.1~rc5/include/crm/cib/util.h 
pacemaker-2.0.1/include/crm/cib/util.h
--- pacemaker-2.0.1~rc5/include/crm/cib/util.h  2019-02-25 22:35:40.0 
+0100
+++ pacemaker-2.0.1/include/crm/cib/util.h  2019-03-04 20:55:07.0 
+0100
@@ -1,23 +1,17 @@
-/* 
- * Copyright (C) 2004 Andrew Beekhof 
- * 
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- * 
- * This software is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- * 
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+/*
+ * Copyright 2004-2019 Andrew Beekhof 
+ *
+ * This source code is licensed under the GNU Lesser General Public License
+ * version 2.1 or later (LGPLv2.1+) WITHOUT ANY WARRANTY.
  */
+
 #ifndef CIB_UTIL__H
 #  define CIB_UTIL__H
 
+#include// gboolean
+#include // cib_t
+#include // xmlNode
+
 #ifdef __cplusplus
 extern "C" {
 #endif
diff -Nru pacemaker-2.0.1~rc5/include/crm/cib.h 
pacemaker-2.0.1/include/crm/cib.h
--- p

Bug#922379: libgphoto2: shuts down Sony cameras upon initialization

[Ferenc Wágner]

Source: libgphoto2
Version: 2.5.22-2
Severity: important
Tags: upstream patch

Dear Maintainer,

I successfully used gvfs-gphoto2-volume-monitor to download photos from
my Sony Alpha 5000 under jessie, but libgphoto2 broke for that camera in
stretch (I don't know the exact version).  This regression has just been
fixed upstream in commit f1e3b5ae8f9d8258db9a19861749b2bb6ad57b1e.  The
patch applies cleanly to 2.5.22 and fixes the issue for me; judging by
the issues referenced in the commit other users are affected as well.
Please include this fix in buster if at all possible!  Having a 2.5.23
would be best of course, but I've got no idea when that will happen.
A quilt patch would still have a chance to reach buster, though.
-- 
Thanks for your consideration,
Feri.

Bug#921946: rubberband-cli: Man page out of date

[Ferenc Wágner]

Package: rubberband-cli
Version: 1.8.1-7
Severity: normal

Dear Maintainer,

The rubberband.1 manual page got out of sync with the help output of the
rubberband binary, for example it does not mention the -M option.
Please consider updating it.
-- 
Thanks,
Feri.

Bug#921865: src:capnproto: Hole test fails on BTRFS

[Ferenc Wágner]

Package: src:capnproto
Version: 0.7.0-3
Severity: normal
Tags: upstream

Dear Maintainer,

When trying to build a stretch backports of capnproto, I hit a build
test failure:

[ TEST ] kj/filesystem-disk-test.c++:835: DiskFile holes
kj/filesystem-disk-test.c++:889: failed: expected file->stat().spaceUsed == 
meta.spaceUsed
stack: 55e8f965ca5c 55e8f96e4473 7f1b104b727f 7f1b102612d8 7f1b104b863d 
7f1b104b9670 7f1b102929df 7f1b102946a6 7f1b102612d8 7f1b10294864 7f1b104b601e 
7f1b0f6182e0 55e8f96444d9
[ FAIL ] kj/filesystem-disk-test.c++:835: DiskFile holes (248617 μs)

I don't know what causes this, my only idea is BTRFS, as in the title,
though that's a pure guess.  I build with sbuild on a BTRFS snapshot of
the clean build chroot.

As a workaround, I added the following quilt patch:

--- capnproto-0.7.0.orig/src/kj/filesystem-disk-test.c++
+++ capnproto-0.7.0/src/kj/filesystem-disk-test.c++
@@ -886,7 +886,7 @@
 
   file->truncate(1 << 21);
   file->datasync();
-  KJ_EXPECT(file->stat().spaceUsed == meta.spaceUsed);
+  // Fails on BTRFS: KJ_EXPECT(file->stat().spaceUsed == meta.spaceUsed);
   KJ_EXPECT(file->read(1 << 20, buf) == 7);
   KJ_EXPECT(StringPtr(reinterpret_cast(buf), 6) == "foobar");
 
which resulted in a successful build.  I'm not sure I'll have a chance
to dig into this, but wanted to make sure the information isn't lost.
I'm not tagging with patch, because it's based on a guess only.
-- 
Regards,
Feri.

Bug#918677: transition: pacemaker

[Ferenc Wágner]

Emilio Pozuelo Monfort  writes:

> On 15/01/2019 17:23, wf...@niif.hu wrote:
> 
>> The uploads are done, but the testing migration of pacemaker and pcs
>> probably deadlocked due to the autopkgtest of the latter.  Unstable pcs
>> needs unstable pacemaker, so they can only go together, which may need
>> manual intervention on your part.
>
> The way this is normally handled is by adding a Breaks on the new pacemaker
> against the broken pcs. That way the autopkgtests are run for the new pcs
> version, and britney migrates the two packages at the same time.

If only we knew in advance...  But there's a new Pacemaker pre-release
I'd like to upload; shall I add that Breaks now or just wait until this
unwrinkles?  I don't know when/if you will intervene or pcs will be
automatically migrated in two days.
-- 
Feri

Bug#918677: transition: pacemaker

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi Release Team,

We'd like to transition to Pacemaker 2.  The ben file below is mostly
equivalent to that of auto-pacemaker, but misses pacemaker-dev, because
I'm not sure how to handle that.  The current lib*-dev packages are
becoming transitional, depending on pacemaker-dev which is a union of
them.

The dlm package will also need a rebuild, because it dlopens libstonithd
and embeds its SONAME at build time.  Is there a way to represent this
in the tracker?  Anyway, I'm asking upstream for a new release, and will
do a sourceful upload once that happens (latest).  Would adding a
Recommends: libstonithdX let the auto tracker pick up this weak
dependency?

We expect sbd to break with the new Pacemaker libraries, and will handle
this with sourceful uploads.

I don't know of any other dependencies, this should be a very shallow
transition despite all the library packages taking part.  Please let me
know when I can upload Pacemaker 2 to unstable.

Thanks,
Feri.

Ben file:

title = "pacemaker";
is_affected = .depends ~ "libcib4" | .depends ~ "libcrmcluster4" | .depends ~ 
"libcrmcommon3" | .depends ~ "libcrmservice3" | .depends ~ "liblrmd1" | 
.depends ~ "libpe-rules2" | .depends ~ "libpe-status10" | .depends ~ 
"libpengine10" | .depends ~ "libstonithd2" | .depends ~ "libtransitioner2" | 
.depends ~ "libcib27" | .depends ~ "libcrmcluster29" | .depends ~ 
"libcrmcommon34" | .depends ~ "libcrmservice28" | .depends ~ "liblrmd28" | 
.depends ~ "libpe-rules26" | .depends ~ "libpe-status28" | .depends ~ 
"libpengine27" | .depends ~ "libstonithd26" | .depends ~ "libtransitioner25";
is_good = .depends ~ "libcib27" | .depends ~ "libcrmcluster29" | .depends ~ 
"libcrmcommon34" | .depends ~ "libcrmservice28" | .depends ~ "liblrmd28" | 
.depends ~ "libpe-rules26" | .depends ~ "libpe-status28" | .depends ~ 
"libpengine27" | .depends ~ "libstonithd26" | .depends ~ "libtransitioner25";
is_bad = .depends ~ "libcib4" | .depends ~ "libcrmcluster4" | .depends ~ 
"libcrmcommon3" | .depends ~ "libcrmservice3" | .depends ~ "liblrmd1" | 
.depends ~ "libpe-rules2" | .depends ~ "libpe-status10" | .depends ~ 
"libpengine10" | .depends ~ "libstonithd2" | .depends ~ "libtransitioner2";

Bug#918367: nmu: pam-mysql_0.8.0-1

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu pam-mysql_0.8.1-1 . ANY . unstable . -m "Rebuild against MariaDB 10.3 
(switch to internal implementaion of some dropped symbols)"

Bug#918029: transition: corosync

[Ferenc Wágner]

Emilio Pozuelo Monfort  writes:

> On 02/01/2019 15:21, Ferenc Wágner wrote:
>
>> please schedule a rebuild of sheepdog and dlm on all relevant
>> architectures, that should finish it.
>
> Done.

Thanks, the rebuilds went through just fine, I think we can close this
transition.  (I didn't with this message in case you still need to do
some administration.)
-- 
Regards,
Feri

Bug#918137: lintian: skip-systemd-native-flag-missing-pre-depends info text typo

[Ferenc Wágner]

Package: lintian
Version: 2.5.50.4
Severity: minor

Dear Maintainer,

The extended description of skip-systemd-native-flag-missing-pre-depends
says:

This flag is useful for maintainer scripts that want to defer systemd
actions to deb-systemd-invoke(1p). However, it was only added in
init-system-helpers version 1.58.

At the moment the latest version of init-system-helpers in unstable is
1.56+nmu1, and the actual dependency generated by Debhelper is
init-system-helpers (>= 1.54~).

Please consider fixing this typo.
-- 
Thanks,
Feri.

Bug#918029: transition: corosync

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

First of all, I'm sorry for inadvertently starting the Corosync
transition.  It isn't a problematic one, though: please schedule a
rebuild of sheepdog and dlm on all relevant architectures, that should
finish it.

Thanks,
Feri.

Ben file (the auto-corosync tracker looks fine, though):

title = "corosync";
is_affected = .depends ~ "libcfg6" | .depends ~ "libcfg7";
is_good = .depends ~ "libcfg7";
is_bad = .depends ~ "libcfg6";

Bug#913136: security update for xml-security-c in Stretch

[Ferenc Wágner]

wf...@niif.hu writes:

> The backport of the patches is fairly straightforward indeed, but up
> to now I couldn't reproduce the issue itself.

Hi Security Team,

After a couple more rounds with upstream it turns out that while #905332
affected simple parsing of the structure, this one affects verification
using an invalid structure.  So one has to convince the code to actually
attempt that verification, which does not seem easily possible with the
(recommended) explicit key trust engine.  However, deployments using the
PKIX trust engine are still prone to remote DoS, though I can't easily
test this.  All in all, for security and symmetry I recommend fixing
this issue in stretch the same way it was fixed in jessie by Thorsten.
Please find the debdiff attached.
-- 
Thanks,
Feri

diff -Nru xml-security-c-1.7.3/debian/changelog 
xml-security-c-1.7.3/debian/changelog
--- xml-security-c-1.7.3/debian/changelog   2018-08-03 11:32:52.0 
+0200
+++ xml-security-c-1.7.3/debian/changelog   2018-12-10 11:45:41.0 
+0100
@@ -1,3 +1,20 @@
+xml-security-c (1.7.3-4+deb9u2) stretch-security; urgency=high
+
+  * [12dd825] New patches: DSA verification crashes OpenSSL on invalid
+combinations of key content.
+Particular KeyInfo combinations result in incomplete DSA key structures
+that OpenSSL can't handle without crashing.  In the case of Shibboleth
+SP software this manifests as a crash in the shibd daemon.  Exploitation
+is believed to be possible only in deployments employing the PKIX trust
+engine, which is generally recommended against.
+The upstream patches backported from 2.0.2 apply analogous safeguards to
+the RSA and ECDSA key handling as well.
+Upstream bug: https://issues.apache.org/jira/browse/SANTUARIO-496
+CVE: not assigned
+Thanks to Scott Cantor (Closes: #913136)
+
+ -- Ferenc Wágner   Mon, 10 Dec 2018 11:45:41 +0100
+
 xml-security-c (1.7.3-4+deb9u1) stretch-security; urgency=high
 
   * [93b87c6] New patch: Default KeyInfo resolver doesn't check for empty
diff -Nru 
xml-security-c-1.7.3/debian/patches/SANTUARIO-496-DSA-verification-crashes-OpenSSL-on-invalid.patch
 
xml-security-c-1.7.3/debian/patches/SANTUARIO-496-DSA-verification-crashes-OpenSSL-on-invalid.patch
--- 
xml-security-c-1.7.3/debian/patches/SANTUARIO-496-DSA-verification-crashes-OpenSSL-on-invalid.patch
 1970-01-01 01:00:00.0 +0100
+++ 
xml-security-c-1.7.3/debian/patches/SANTUARIO-496-DSA-verification-crashes-OpenSSL-on-invalid.patch
 2018-12-10 11:44:59.0 +0100
@@ -0,0 +1,103 @@
+From: Scott Cantor 
+Date: Thu, 11 Oct 2018 15:13:40 +
+Subject: SANTUARIO-496 - DSA verification crashes OpenSSL on invalid
+ combinations of key content
+
+Backport of
+git-svn-id: 
https://svn.apache.org/repos/asf/santuario/xml-security-cpp/trunk@1843562 
13f79535-47bb-0310-9956-ffa450edef68
+---
+ xsec/enc/OpenSSL/OpenSSLCryptoKeyDSA.cpp | 12 
+ xsec/enc/OpenSSL/OpenSSLCryptoKeyEC.cpp  | 12 
+ xsec/enc/OpenSSL/OpenSSLCryptoKeyRSA.cpp | 12 
+ 3 files changed, 36 insertions(+)
+
+diff --git a/xsec/enc/OpenSSL/OpenSSLCryptoKeyDSA.cpp 
b/xsec/enc/OpenSSL/OpenSSLCryptoKeyDSA.cpp
+index 57999a2..5bdf133 100644
+--- a/xsec/enc/OpenSSL/OpenSSLCryptoKeyDSA.cpp
 b/xsec/enc/OpenSSL/OpenSSLCryptoKeyDSA.cpp
+@@ -164,6 +164,12 @@ bool OpenSSLCryptoKeyDSA::verifyBase64Signature(unsigned 
char * hashBuf,
+   "OpenSSL:DSA - Attempt to validate signature with empty 
key");
+   }
+ 
++XSECCryptoKey::KeyType keyType = getKeyType();
++if (keyType != KEY_DSA_PAIR && keyType != KEY_DSA_PUBLIC) {
++throw XSECCryptoException(XSECCryptoException::DSAError,
++"OpenSSL:DSA - Attempt to validate signature without public key");
++}
++
+ char* cleanedBase64Signature;
+   unsigned int cleanedBase64SignatureLen = 0;
+ 
+@@ -264,6 +270,12 @@ unsigned int 
OpenSSLCryptoKeyDSA::signBase64Signature(unsigned char * hashBuf,
+   "OpenSSL:DSA - Attempt to sign data with empty key");
+   }
+ 
++KeyType keyType = getKeyType();
++if (keyType != KEY_DSA_PAIR && keyType != KEY_DSA_PRIVATE) {
++throw XSECCryptoException(XSECCryptoException::DSAError,
++"OpenSSL:DSA - Attempt to sign data without private key");
++}
++
+   DSA_SIG * dsa_sig;
+ 
+   dsa_sig = DSA_do_sign(hashBuf, hashLen, mp_dsaKey);
+diff --git a/xsec/enc/OpenSSL/OpenSSLCryptoKeyEC.cpp 
b/xsec/enc/OpenSSL/OpenSSLCryptoKeyEC.cpp
+index 3233343..09ba69e 100644
+--- a/xsec/enc/OpenSSL/OpenSSLCryptoKeyEC.cpp
 b/xsec/enc/OpenSSL/OpenSSLCryptoKeyEC.cpp
+@@ -151,6 +151,12 @@ bool 
OpenSSLCryptoKeyEC::verifyBase64SignatureDSA(unsigned char * hashBuf,
+   "OpenSSL:EC - Attempt to validate signature with empty 
key");
+   }
+ 
++KeyType keyType = getKeyType();
++if (keyType != KEY_EC

Bug#915639: shibboleth-resolver: FTBFS: missing pkg-config/log4shib/log4cpp

[Ferenc Wágner]

Andreas Beckmann  writes:

> shibboleth-resolver FTBFS everywhere:
>
> checking for pkg-config... no

It's just pkg-config missing from Build-Depends.
Sam, are you around to fix this?
-- 
Thanks,
Feri

Bug#915157: RM: shibboleth-sp2 -- ROM; renamed to shibboleth-sp

[Ferenc Wágner]

Package: ftp.debian.org
Severity: normal

Hi,

This request goes with #915155 (removal of opensaml2), please find
additional rationale there.  Here we build libshibsp8 instead of
libshibsp7, thus the need for manual action.
-- 
Thanks,
Feri.

Bug#915155: RM: opensaml2 -- ROM; renamed to opensaml

[Ferenc Wágner]

Package: ftp.debian.org
Severity: normal

Hi,

The rename was part of a library transition, so the libsaml9 binary
package is not taken over by opensaml, we build libsaml10 instead.

I'm filing a separate removal request for the shibboleth-sp2 direct
dependency; the shibboleth-resolver and moonshot-gss-eap transitive
dependencies are already broken in unstable by the OpenSSL 1.1
transition and will soon be fixed (upgraded) by their maintainer, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915007#23:

> Don't wait for me on shibboleth-resolver or moonshot-gss-eap to file
> the removal requests.
> They are both basically broken in unstable, so there's no reason to
> block.

Thanks,
Feri.