Bug#1074378: bind9: Bind9 SEGFAULT when enable DLZ with samba

[Bernhard Schmidt]

Control: found -1 9.18.28-1~deb12u1
Control: severity -1 serious
Control: affects -1 samba-libs
Control: forwarded -1 https://bugzilla.samba.org/show_bug.cgi?id=15643
Control: summary -1 Workaround: Set environment 
LDB_MODULES_DISABLE_DEEPBIND=true


I don't know anything about that code so I can't fix it, but I think 
since it's breaking stable this warrants an RC bug and updated metadata.


Can anyone confirm the workaround from the Samba BZ setting 
LDB_MODULES_DISABLE_DEEPBIND=true ?

Bug#1077159: freeradius: Not backward compatible with eapol_test from bullseye

[Bernhard Schmidt]

Control: reassign -1 eapoltest
Control: found -1 2:2.10-8


freeradius with openssl 3.0.13-1~deb12u1 cannot successfully communicate
with eapol_test from bullseye (2:2.10-8~bpo11+2, openssl 1.1.1w-0+deb11u1).
eapol_test is used by our monitoring system to verify the functionality
of our freeradius services.

Server log shows the received Access-Request is handled and Access-Challenge
is sent. However eapol_test simply ignores it and re-sends Access-Request
packets again and again:


This sounds like a bug in eapoltest, not in Freeradius. Reassigning 
accordingly.


Note that the version in bullseye-backports is older than the one in 
bookworm it should base on. The version in bullseye-backports is missing 
these fixes from bookworm (stable). Some of those sound related.


I'm not sure whether bullseye-backports is still updateable, if yes it 
might be a good idea to backport the current stable-security version.


wpa (2:2.10-12+deb12u1) bookworm; urgency=high

  * Non-maintainer upload on behalf of the Security Team.
  * Fix CVE-2023-52160 (Closes: #1064061):
The implementation of PEAP in wpa_supplicant allows
authentication bypass. For a successful attack,
wpa_supplicant must be configured to not verify
the network's TLS certificate during Phase 1
authentication, and an eap_peap_decrypt vulnerability
can then be abused to skip Phase 2 authentication.
The attack vector is sending an EAP-TLV Success packet
instead of starting Phase 2. This allows an adversary
to impersonate Enterprise Wi-Fi networks.

 -- Bastien Roucariès   Tue, 30 Apr 2024 22:45:18 +

wpa (2:2.10-12) unstable; urgency=medium

  * Prevent hostapd units from being started if there’s
no config provided (Closes: #1028088).
  * hostapd: Enable 802.11ax support (Closes: #1013732).

 -- Andrej Shadura   Fri, 24 Feb 2023 14:01:35 +0100

wpa (2:2.10-11) unstable; urgency=medium

  * Drop security level to 0 with OpenSSL 3.0 when using TLS 1.0/1.1
(Closes: #1011121, LP: #1958267)
  * Drop dependency on lsb-base.

 -- Andrej Shadura   Tue, 31 Jan 2023 12:58:02 +0100

wpa (2:2.10-10) unstable; urgency=medium

  * Configure wpa_supplicant.service to create control sockets owned by 
group netdev

(Closes: #1012844)

 -- Andrej Shadura   Wed, 21 Dec 2022 10:03:29 +0100

wpa (2:2.10-9) unstable; urgency=medium

  [ Sebastien Bacher ]
  * debian/patches/allow-legacy-renegotiation.patch:
Allow legacy renegotiation to fix PEAP issues with some servers
(Closes: #1010603, LP: #1962541)

 -- Andrej Shadura   Thu, 05 May 2022 11:23:33 +0100


Tcpdump shows the Access-Challenge packet is indeed delivered to the client.
If the same configuration (both on server and eapol_test sides) is tested
with eapoltest from bookworm (2:2.10-12+deb12u1, openssl 3.0.13-1~deb12u1),
it is successful.

The issue is critical becasue possibly all clients with openssl 1.1.1w-0+deb11u1
might be affected.


We can't rule that out, but we haven't heard of any reports.

Bernhard

Bug#1076458: freeradius: replace radsecret script with bash

[Bernhard Schmidt]

Hi,


I also just proposed[2] this to upstream.


Thanks, looks like there is some discussion ongoing. As soon as this is 
settled I will pick it up.


Bernhard

Bug#1076458: freeradius: replace radsecret script with bash

[Bernhard Schmidt]

Hi Andreas,


Upstream also suggested[2] that we could just remove the radsecret
script, since it's not used by anything else, but I rather not deviate
from upstream that much if we can.


Same here. Have you considered to submit the replacement upstream? I 
will gladly cherry-pick the change as soon as it has been merged 
upstream. Since it is somewhat security sensitive I would rather not 
deviate from upstream here (the great Debian OpenSSL debacle comes to mind).


Bernhard

Bug#1076022: Backport some security settings from upstream 3.2.5 release to mitigate BlastRADIUS

[Bernhard Schmidt]

Am 12.07.24 um 13:34 schrieb Herwin Weststrate:

Dear Herwin,


FreeRADIUS 3.2.5 has just been released, which includes some security
fixes for BlastRADIUS: a vulnerability with a name and a website[0] and
a logo (hadn't seen one of those in a while).


[...]



Given that the freeradius codebase is really complicated I'm not entirely
sure whether we can do this (_I_ can't), or ask the security team for a
newer upstream version in stable.


I looked a bit deeper into it: there was a lot more needed than just
these two commits. Pretty much every commit of July 8 was relevant.


Thanks a lot for checking this out.


I have not yet tested the proxy settings, it takes a while to set that
up and I would first like to know if there is a chance that this patch
set will be accepted, if it gets rejected right away for whatever reason
I'd rather save myself the trouble.


> All the commits have been cherry-picked in order from the upstream
> changes, so a code review can compare these commits side by side.

I'm open to it, but ultimatively it's up to the security team to decide. 
We can either go for this 100k patch cherry-picked from upstream, or ask 
for 3.2.5 in stable. Or ignore it, which is in my opinion still on the 
table (I don't consider BlastRADIUS that bad, but it has a website and a 
logo so ...)


@Security Team: What do you think? Herwin did a spectacular job here 
already and I can also offer to get it some life testing in a production 
environment, but in the end we would have to jump into very cold waters.


Bernhard

Bug#1076022: Backport some security settings from upstream 3.2.5 release to mitigate BlastRADIUS

[Bernhard Schmidt]

Control: tags -1 help security

Am 09.07.24 um 18:15 schrieb Herwin Weststrate:

Package: freeradius
Version: 3.2.1+dfsg-4+deb12u1

FreeRADIUS 3.2.5 has just been released, which includes some security
fixes for BlastRADIUS: a vulnerability with a name and a website[0] and
a logo (hadn't seen one of those in a while).

The FreeRADIUS security page[1] (scroll to "2024.07.09", there is no
anchor to link directly to the relevant article) describes some new
configuration options to resolve everything. Since this will be the
first thing people read, it would be nice to have those backported to
the Debian packages.

At first glance, it looks like this requires just two commits[2] [3] to
be cherry-picked, but there may be some hidden dependencies in previous
commits.



[2] 
https://github.com/FreeRADIUS/freeradius-server/commit/0947439f2569d2b8c2b4949be24250263934e260
[3] 
https://github.com/FreeRADIUS/freeradius-server/commit/6616be90346beb6050446bd00c8ed5bca1b8ef29


I haven't looked closer yet, but the patches do not apply at all

dpkg-source: info: applying 0947439f2569d2b8c2b4949be24250263934e260.patch
patching file raddb/radiusd.conf.in
Hunk #1 FAILED at 625.
Hunk #2 FAILED at 643.
2 out of 2 hunks FAILED
patching file src/include/clients.h
Hunk #2 FAILED at 52.
1 out of 2 hunks FAILED
patching file src/include/libradius.h
Hunk #1 FAILED at 411.
1 out of 1 hunk FAILED
patching file src/include/radiusd.h
Hunk #1 FAILED at 178.
Hunk #2 succeeded at 564 (offset -6 lines).
1 out of 2 hunks FAILED
patching file src/lib/radius.c
Hunk #1 succeeded at 2631 (offset -128 lines).
Hunk #2 FAILED at 2770.
Hunk #3 FAILED at 2790.
2 out of 3 hunks FAILED
patching file src/main/client.c
Hunk #1 succeeded at 489 (offset -2 lines).
Hunk #2 FAILED at 515.
Hunk #3 succeeded at 904 (offset -16 lines).
Hunk #4 succeeded at 914 (offset -16 lines).
Hunk #5 succeeded at 1173 (offset -30 lines).
1 out of 5 hunks FAILED
patching file src/main/listen.c
Hunk #1 succeeded at 508 (offset -22 lines).
Hunk #2 FAILED at 683.
Hunk #3 succeeded at 1763 (offset -271 lines).
Hunk #4 FAILED at 2109.
Hunk #5 succeeded at 1846 (offset -271 lines).
2 out of 5 hunks FAILED
patching file src/main/mainconfig.c
Hunk #2 FAILED at 88.
Hunk #3 FAILED at 164.
Hunk #4 succeeded at 849 (offset -24 lines).
Hunk #5 FAILED at 1173.
3 out of 5 hunks FAILED


dpkg-source: info: applying 6616be90346beb6050446bd00c8ed5bca1b8ef29.patch
patching file raddb/clients.conf
Hunk #1 FAILED at 137.
Hunk #2 FAILED at 152.
2 out of 2 hunks FAILED
patching file raddb/proxy.conf
Hunk #1 FAILED at 255.
1 out of 1 hunk FAILED
patching file raddb/radiusd.conf.in
Hunk #1 FAILED at 604.
Hunk #2 FAILED at 632.
Hunk #3 FAILED at 691.
3 out of 3 hunks FAILED
patching file src/include/clients.h
Reversed (or previously applied) patch detected!  Skipping patch.
2 out of 2 hunks ignored
patching file src/include/libradius.h
Hunk #1 succeeded at 942 (offset -28 lines).
patching file src/include/radiusd.h
Hunk #1 FAILED at 176.
1 out of 1 hunk FAILED
patching file src/include/realms.h
Hunk #1 FAILED at 71.
1 out of 1 hunk FAILED
patching file src/main/client.c
Hunk #1 FAILED at 491.
Hunk #2 FAILED at 514.
Hunk #3 FAILED at 727.
Hunk #4 FAILED at 920.
Hunk #5 FAILED at 930.
Hunk #6 FAILED at 1203.
Hunk #7 succeeded at 1494 (offset -37 lines).
6 out of 7 hunks FAILED
patching file src/main/listen.c
Hunk #1 FAILED at 532.
Hunk #2 FAILED at 543.
Hunk #3 FAILED at 683.
Hunk #4 FAILED at 2114.
Hunk #5 FAILED at 2546.
5 out of 5 hunks FAILED
patching file src/main/mainconfig.c
Hunk #1 FAILED at 73.
Hunk #2 FAILED at 211.
Hunk #3 FAILED at 921.
Hunk #4 FAILED at 1225.
4 out of 4 hunks FAILED
patching file src/main/process.c
Hunk #1 FAILED at 2806.
Hunk #2 FAILED at 2823.
2 out of 2 hunks FAILED
patching file src/main/realms.c
Hunk #1 FAILED at 481.
Hunk #2 FAILED at 789.
2 out of 2 hunks FAILED

Even with fuzz 80% of the hunks do not apply.

Given that the freeradius codebase is really complicated I'm not 
entirely sure whether we can do this (_I_ can't), or ask the security 
team for a newer upstream version in stable.


But I'll give 3.2.5 a go in unstable ASAP.

Bernhard

Bug#1052561: bookworm-pu: package nfdump/1.7.3-1 (pre-discussion)

[Bernhard Schmidt]

On 08/10/23 10:19 PM, Bernhard Schmidt wrote:

Hi,

> > On Sun, Sep 24, 2023 at 09:36:00PM +0200, Bernhard Schmidt wrote:
> > > [ Other info ]
> > > I did not attach the debdiff because it would be too large and only 
> > > consist
> > > of upstream changes. No changes to debian/ (except dropping a backported 
> > > fix
> > > already in 12.1) are necessary.
> > 
> > What does diffstat look like, possibly with translations and tests
> > excluded? Let's see what sort of scale we're talking here.
> 
> Plain debdiff
> 
>  185 files changed, 25810 insertions(+), 28068 deletions(-)

Gentle ping about this. I'm totally fine if you think this is too risky,
I would go for bookworm-backports then.

[...]

> I'll reach out to upstream about those embedded lz4 copy, right now it does
> not look like one could build against an external library, in contrast to
> zstd and bz2 support.

Upstream has released 1.7.4 which supports building against the system
lz4 copy. I don't want to upload this to unstable until it's clear how
to proceed with this bug. So

1.) Drop this request and keep the old version in bookworm, upload
1.7.3+ to bookworm-backports
2.) Upload 1.7.3 to one of the next bookworm point releases
3.) Upload 1.7.4 to unstable, then target that for one of the next
bookworm point releases (but the diff will become even larger)

What's your take on this?

Thanks,
Bernhard

Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)

[Bernhard Schmidt]

> > > Considering the version in unstable is currently
> > > 
> > > 0.0+git20231103-1
> > > 
> > > should the upload be versioned
> > > 
> > > 0.0+git20231103-0+deb12u1 (like originally proposed) or
> > > 0.0+git20231103-1~deb12u1
> > 
> > As originally proposed please. You're not backporting 0.0+git20231103-1
> > directly as far as I know, because you have intermediate changes which
> > should not be included (correct me if I'm wrong about that).
> 
> There have been no changes in unstable other than the new upstream version,
> so technically it would be a backport of 0.0+git20231103-1. This is a diff
> between 0.0+git20230324-1 and 0.0+git20231103-1.
> 
>  Makefile| 13 ++---
>  compat-include/net/gso.h| 20 
>  debian/changelog| 21 +
>  debian/rules|  2 +-
>  drivers/net/ovpn-dco/ovpn.c |  1 +
>  drivers/net/ovpn-dco/tcp.c  | 14 +++---
>  linux-compat.h  |  4 ++--
>  7 files changed, 66 insertions(+), 9 deletions(-)
> 
> The change in d/rules is a new directory in the new upstream version.
> 
> I would just add a d/gbp.conf for the bookworm branch.
> 
> So 0.0+git20231103-1~deb12u1 ?

Uploaded as this version.

Final diff against the version in bookworm is attached

 Makefile| 13 ++---
 compat-include/net/gso.h| 20 
 debian/changelog| 28 
 debian/gbp.conf |  2 ++
 debian/rules|  2 +-
 drivers/net/ovpn-dco/ovpn.c |  1 +
 drivers/net/ovpn-dco/tcp.c  | 14 +++---
 linux-compat.h  |  4 ++--
 8 files changed, 75 insertions(+), 9 deletions(-)

FTR, the diff between 0.0+git20231103-1 and 0.0+git20231103-1~deb12u1 is

 debian/changelog | 7 +++
 debian/gbp.conf  | 2 ++
 2 files changed, 9 insertions(+)

Bernhard
diffstat for openvpn-dco-dkms-0.0+git20230324 openvpn-dco-dkms-0.0+git20231103

 Makefile|   13 ++---
 compat-include/net/gso.h|   20 
 debian/changelog|   28 
 debian/gbp.conf |2 ++
 debian/rules|2 +-
 drivers/net/ovpn-dco/ovpn.c |1 +
 drivers/net/ovpn-dco/tcp.c  |   14 +++---
 linux-compat.h  |4 ++--
 8 files changed, 75 insertions(+), 9 deletions(-)

diff -Nru openvpn-dco-dkms-0.0+git20230324/compat-include/net/gso.h openvpn-dco-dkms-0.0+git20231103/compat-include/net/gso.h
--- openvpn-dco-dkms-0.0+git20230324/compat-include/net/gso.h	1970-01-01 01:00:00.0 +0100
+++ openvpn-dco-dkms-0.0+git20231103/compat-include/net/gso.h	2023-11-11 22:20:11.0 +0100
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* OpenVPN data channel accelerator
+ *
+ *  Copyright (C) 2023 OpenVPN, Inc.
+ *
+ *  Author:	Antonio Quartulli 
+ */
+
+#ifndef _NET_OVPN_COMPAT_NET_GSO_H
+#define _NET_OVPN_COMPAT_NET_GSO_H
+
+#include 
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 10)
+#include_next 
+#else
+#include 
+#endif
+
+#endif /* _NET_OVPN_COMPAT_NET_GSO_H */
diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/changelog openvpn-dco-dkms-0.0+git20231103/debian/changelog
--- openvpn-dco-dkms-0.0+git20230324/debian/changelog	2023-04-13 09:47:41.0 +0200
+++ openvpn-dco-dkms-0.0+git20231103/debian/changelog	2024-04-07 15:20:37.0 +0200
@@ -1,3 +1,31 @@
+openvpn-dco-dkms (0.0+git20231103-1~deb12u1) bookworm; urgency=medium
+
+  * Upload 0.0+git20231103-1 to Debian Bookworm
+  * Add d/gbp.conf for debian/bookworm branch
+
+ -- Bernhard Schmidt   Sun, 07 Apr 2024 15:20:37 +0200
+
+openvpn-dco-dkms (0.0+git20231103-1) unstable; urgency=medium
+
+  * New upstream version 0.0+git20231103
+- fixes refcount imbalance ("waiting for tunxxx to become free") seen
+  on heavy loaded TCP servers
+
+ -- Bernhard Schmidt   Sat, 11 Nov 2023 22:20:21 +0100
+
+openvpn-dco-dkms (0.0+git20230816-2) unstable; urgency=medium
+
+  * Install compat-include directory (Closes: #1050211)
+
+ -- Bernhard Schmidt   Tue, 22 Aug 2023 18:00:24 +0200
+
+openvpn-dco-dkms (0.0+git20230816-1) unstable; urgency=medium
+
+  * New upstream version 0.0+git20230816
+- fix build error on kernel 6.5+ (Closes: #1043116)
+
+ -- Bernhard Schmidt   Mon, 21 Aug 2023 22:51:04 +0200
+
 openvpn-dco-dkms (0.0+git20230324-1) unstable; urgency=medium
 
   * Release to unstable targetting bookworm.
diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf openvpn-dco-dkms-0.0+git20231103/debian/gbp.conf
--- openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf	1970-01-01 01:00:00.0 +0100
+++ openvpn-dco-dkms-0.0+git20231103/debian/gbp.conf	2024-04-07 15:20:37.0 +0200
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch=debian/bookworm
diff -Nru openvpn-dco

Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens

[Bernhard Schmidt]

Hi,


Many of the man page URLs link into an access-restricted walled
garden. E.g. all openvpn.net links go to a Cloudflare site that is not
open to all people. It’s an injustice for a Debian man page to refer
users to exclusive resources that may exclude them. This is perhaps
something that should be fixed in the Debian version as the upstream
project has no duty to the users. Debian has a quality standard as
well as a social contract and users to give equitable treatment
to. Therefore IMO the Debian project should remove the
access-restricted links from the man page and ideally replace them
with openly accessible links. The most convenient way to do that would
be to find mirrored versions of the pages in the Wayback Machine.

This one-liner would perhaps do the job well enough:

   sed -e 
'/http.*.openvpn.net/s@https://\([[:alnum:].]*openvpn.net\)@https://web.archive.org/web/\1@'

ietf.org has the same problem.


For this, while I share your concerns about the unmindful use of 
Cloudflare reverse proxy for basically everything I don't agree to call 
this a "walled garden".  Certainly not enough to call the mentioning of 
an URL that just _now_ happens to be "protected" by Cloudflare a policy 
violation (or social contract violation) and alter the URLs to 
web.archive.org, which to my experience is broken quite often, dog-slow 
and not necessarily up-to-date. I think this would be more of a disservice.


Most of the interesting content should be in the manpage and in 
/usr/share/doc/packages/openvpn anyway.


If you have concerns about the use of Cloudflare, please raise this 
upstream. I know there are some devs sensitive to these concerns listening.


Bernhard

Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens

[Bernhard Schmidt]

Control: tags -1 upstream

Hi,


Users can perhaps experiment to work out which of the various possible
behaviors result, but the man page should be written unambiguously.


I completely agree, but this is not something the Debian OpenVPN 
maintainers can do. Please check the latest version at the upstream 
Github repository https://github.com/OpenVPN/openvpn and file issues 
there, if the issue is still present.


Bernhard

Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)

[Bernhard Schmidt]

Hi,

Considering the version in unstable is currently

0.0+git20231103-1

should the upload be versioned

0.0+git20231103-0+deb12u1 (like originally proposed) or
0.0+git20231103-1~deb12u1


As originally proposed please. You're not backporting 0.0+git20231103-1
directly as far as I know, because you have intermediate changes which
should not be included (correct me if I'm wrong about that).


There have been no changes in unstable other than the new upstream 
version, so technically it would be a backport of 0.0+git20231103-1. 
This is a diff between 0.0+git20230324-1 and 0.0+git20231103-1.


 Makefile| 13 ++---
 compat-include/net/gso.h| 20 
 debian/changelog| 21 +
 debian/rules|  2 +-
 drivers/net/ovpn-dco/ovpn.c |  1 +
 drivers/net/ovpn-dco/tcp.c  | 14 +++---
 linux-compat.h  |  4 ++--
 7 files changed, 66 insertions(+), 9 deletions(-)

The change in d/rules is a new directory in the new upstream version.

I would just add a d/gbp.conf for the bookworm branch.

So 0.0+git20231103-1~deb12u1 ?

Bernhard

Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)

[Bernhard Schmidt]

Hi Jonathan,


On Tue, Nov 14, 2023 at 11:26:54PM +0100, Bernhard Schmidt wrote:

[ Reason ]
openvpn-dco-dkms packages an accelerator kernel module for OpenVPN (OpenVPN
data channel offload). There is one annoying bug tracked as Bug#1055809 where on
heavily loaded TCP servers a refcount issue might occur and the module will
become unusable.


This request was approved but not uploaded in time for the previous point
release (12.5). Should it be included in 12.6, or should this request be
abandoned and closed?


Sorry, my bad, I'm getting old. I'm still interested.

Considering the version in unstable is currently

0.0+git20231103-1

should the upload be versioned

0.0+git20231103-0+deb12u1 (like originally proposed) or
0.0+git20231103-1~deb12u1

?

Bernhard

Bug#1056984: bind9: regression: the branch 9.19 misses some commits from the branch 9.18

[Bernhard Schmidt]

Control: forwarded -1 
https://salsa.debian.org/dns-team/bind9/-/merge_requests/26

On 27/11/23 09:12 PM, Arnaud Rebillout wrote:

Hi,

> In https://bugs.debian.org/1025519 was reported a bug in bind9 apparmor
> configuration. It was fixed on the branch `debian/9.18`, with commit
> https://salsa.debian.org/dns-team/bind9/-/commit/5c03f25e, and released
> version `1:9.18.10-2` of bind9 (released in December 2022).
> 
> However today the issue is back. The regression is due to the fact that
> the commit 5c03f25e was not applied in the branch `debian/9.19`, which
> is currently in Debian unstable.
> 
> Looking at the changelog (on branch `debian/9.19`), it jumps straight
> from `9.18.2-1` to `9.19.0-1`, makes me wonder how many good commits
> from the branch 9.18 are missing in the branch 9.19... Please have a
> look, and at least apply 5c03f25e, it's a must!

I have taken a look and identified four missing commits. 

@Ondrej: Could you have a look at
https://salsa.debian.org/dns-team/bind9/-/merge_requests/26 ?

Bernhard

Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: openvpn-dco-d...@packages.debian.org
Control: affects -1 + src:openvpn-dco-dkms

[ Reason ]
openvpn-dco-dkms packages an accelerator kernel module for OpenVPN (OpenVPN
data channel offload). There is one annoying bug tracked as Bug#1055809 where on
heavily loaded TCP servers a refcount issue might occur and the module will
become unusable.

The bug has been fixed upstream. The new upstream snapshot is already in sid.

Apart from that change there is a fix for compilation with Kernel >= 6.5 that
we might want to have in stable for backport kernels. Tracked as Bug#1043116.
That patch could be backported, but needs some fixup.

Apart from that there are only changes for building with RHEL9, which is a noop
on Debian.

https://github.com/OpenVPN/ovpn-dco/compare/1c2c84e99d0c1513db38ac7a3858f21229906fd7..master

Backporting the build fix would actually make the diff larger than the new
upstream version and harder to maintain, so I'm proposing two options:

a) backport only the fix for Bug#1055809 and upload as
openvpn-dco-dkms/0.0+git20230324-1+deb12u1

 changelog|9 
 gbp.conf |2 +
 patches/fix-refcount-imbalance.patch |   38 +++
 patches/series   |1 
 4 files changed, 50 insertions(+)

b) upload the new upstream snapshot as 0.0+git20231103-0+deb12u1, fixing the
build error on kernel 6.5

 Makefile|   13 ++---
 compat-include/net/gso.h|   20 
 debian/changelog|   21 +
 debian/rules|2 +-
 drivers/net/ovpn-dco/ovpn.c |1 +
 drivers/net/ovpn-dco/tcp.c  |   14 +++---
 linux-compat.h  |4 ++--
 7 files changed, 66 insertions(+), 9 deletions(-)

[ Impact ]
If neither update is allowed the kernel module will hang on busy servers

If we only fix the refcount imbalance the module will not build on future
backports kernels. Backporting that fix as well would be possible, but actually
the diff would be larger and we cannot be sure whether new fixes would apply
cleanly.

[ Tests ]
The code fix is trivial enough and has been verified upstream. The new module
is currently running on my employers eduVPN server.

[ Risks ]
The changes are pretty trivial and the vast majority of them is a noop on
Bookworm or Debian as a whole

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

[ Changes ]
See the explaination above for the minimal version and the github diff link for
the new upstream version
diffstat for openvpn-dco-dkms-0.0+git20230324 openvpn-dco-dkms-0.0+git20230324

 changelog|9 
 gbp.conf |2 +
 patches/fix-refcount-imbalance.patch |   38 +++
 patches/series   |1 
 4 files changed, 50 insertions(+)

diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/changelog 
openvpn-dco-dkms-0.0+git20230324/debian/changelog
--- openvpn-dco-dkms-0.0+git20230324/debian/changelog   2023-04-13 
09:47:41.0 +0200
+++ openvpn-dco-dkms-0.0+git20230324/debian/changelog   2023-11-14 
22:18:17.0 +0100
@@ -1,3 +1,12 @@
+openvpn-dco-dkms (0.0+git20230324-1+deb12u1) bookworm; urgency=medium
+
+  * Import upstream patch to fix refcount imbalance (Closes: 1055809)
+- fixes "waiting for tunxxx to become free" seen on heavy loaded TCP
+  servers
+  * Add d/gbp.conf for debian/bookworm branch
+
+ -- Bernhard Schmidt   Tue, 14 Nov 2023 22:18:17 +0100
+
 openvpn-dco-dkms (0.0+git20230324-1) unstable; urgency=medium
 
   * Release to unstable targetting bookworm.
diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf 
openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf
--- openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf1970-01-01 
01:00:00.0 +0100
+++ openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf2023-11-14 
22:18:17.0 +0100
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch=debian/bookworm
diff -Nru 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch
--- 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch
1970-01-01 01:00:00.0 +0100
+++ 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch
2023-11-14 22:18:17.0 +0100
@@ -0,0 +1,38 @@
+From 7b7a28fcb0c244c7182922f7c83cb09bcd840c84 Mon Sep 17 00:00:00 2001
+From: Antonio Quartulli 
+Date: Wed, 1 Nov 2023 23:49:39 +0100
+Subject: [PATCH] ovpn-dco: fix refcount imbalance up

Bug#1055809: Kernel module hangs with "waiting for tunxxx to become free"

[Bernhard Schmidt]

Source: openvpn-dco-dkms
Version: 0.0+git20230324-1
Severity: important
Tags: upstream

The dco module sometimes hangs on stopping/crashing OpenVPN processes with

unregister_netdevice: waiting for tun321 to become free. Usage count = 1

This has been tracked in https://github.com/OpenVPN/ovpn-dco/issues/18

Bug#1052561: bookworm-pu: package nfdump/1.7.3-1 (pre-discussion)

[Bernhard Schmidt]

Am 07.10.23 um 13:14 schrieb Jonathan Wiltshire:

Hi,


On Sun, Sep 24, 2023 at 09:36:00PM +0200, Bernhard Schmidt wrote:

[ Other info ]
I did not attach the debdiff because it would be too large and only consist
of upstream changes. No changes to debian/ (except dropping a backported fix
already in 12.1) are necessary.


What does diffstat look like, possibly with translations and tests
excluded? Let's see what sort of scale we're talking here.


Plain debdiff

 185 files changed, 25810 insertions(+), 28068 deletions(-)

There are no translation changes and not many tests to exclude, but a 
few things stand out. Dropping quite a bit from m4 buildfiles as part of 
commits


https://github.com/phaag/nfdump/commit/488e2136bb97f5ae45900fd93e390e1be25cb91e
https://github.com/phaag/nfdump/commit/93f1af69d15dec0600d7ac311bd33c15556dee25

(remove autogen m4 files from repo)

 m4/libtool.m4  | 8400 
---

 m4/ltoptions.m4|  437 --
 m4/ltsugar.m4  |  124 --
 m4/ltversion.m4|   24 -
 m4/lt~obsolete.m4  |   99 --

a few renames

 src/lib/{ => compress}/lzoconf.h   |0
 src/lib/{ => compress}/lzodefs.h   |0
 src/lib/{ => compress}/minilzo.c   |0
 src/lib/{ => compress}/minilzo.h   |0
 src/{ => lib}/conf/nfconf.c|   38 +-
 src/{ => lib}/conf/nfconf.h|2 +
 src/{ => lib}/conf/nfdump.conf.dist|   19 +-
 src/{ => lib}/conf/toml.c  |2 +-
 src/{ => lib}/conf/toml.h  |0
 src/{nfcapd/netflow_pcapd.c => netflow/nfd_raw.c}  |   96 +-
 src/{include/netflow_pcapd.h => netflow/nfd_raw.h} |   18 +-

and the move and update of the embedded lz4 code

https://github.com/phaag/nfdump/commit/99dc96e8433637ef1d62edbf13f26655a3815982

 src/lib/compress/lz4.c | 2751 
++

 src/lib/compress/lz4.h |  862 
 src/lib/lz4.c  | 1564 
--

 src/lib/lz4.h  |  483 ---

and the addition of the High Compression Mode of LZ4

 src/lib/compress/lz4hc.c   | 1637 
+++

 src/lib/compress/lz4hc.h   |  413 ++

https://github.com/phaag/nfdump/commit/cb254b1730b3abc39627b16d4c04b97cdcd62de0

I'll reach out to upstream about those embedded lz4 copy, right now it 
does not look like one could build against an external library, in 
contrast to zstd and bz2 support.


If you exclude all

git diff upstream/1.7.1 upstream/1.7.3 --stat -- . ':!*.m4' 
':!src/lib/compress/lz4.*' ':!src/lib/compress/lz4hc.*' ':!src/lib/lz4.*'


that you get down to

 .github/FUNDING.yml|   1 +
 .github/workflows/c-cpp.yml|  23 +
 .gitignore |   1 +
 ChangeLog  | 171 ++
 Makefile.am|   2 +-
 README.md  | 112 +++-
 configure.ac   |  64 +-
 extra/CreateSubHierarchy.pl|   6 +-
 extra/docker/Dockerfile.alpine |   2 +-
 extra/docker/Dockerfile.ubuntu |   2 +-
 extra/nfsen/nfsen-1.6-stats-influxdb.patch |   2 +-
 extra/nfsen/nfsen-trunk-stats-influxdb.patch   |   2 +-
 man/geolookup.1|   2 +-
 man/nfanon.1   |   4 +-
 man/nfcapd.1   |  49 +-
 man/nfdump.1   |  97 ++-
 man/nfexpire.1 |   6 +-
 man/nfpcapd.1  |  32 +-
 man/nfreplay.1 |   5 +-
 man/sfcapd.1   |  35 +-
 src/collector/Makefile.am  |   5 +-
 src/collector/bookkeeper.c |  28 +-
 src/collector/bookkeeper.h |  15 +-
 src/collector/collector.c  |  74 ++-
 src/collector/collector.h  |  30 +-
 src/collector/expire.c |  23 +-
 src/collector/launch.c | 329 ++
 src/collector/launch.h |  11 +-
 src/collector/metric.c |   8 +-
 src/collector/nfnet.c  |  92 ++-
 src/collector/nfnet.h  

Bug#1053142: chromium cannot startup after libfreetype6 upgrade to 2.12.1+dfsg-5+deb12u1

[Bernhard Schmidt]

Control: affects -1 src:freetype

Technically it probably should be the other way around, but I fear this
will be missed otherwise. Marking freetype as affected to at least it
shows up there.

Bug#1052561: bookworm-pu: package nfdump/1.7.3-1 (pre-discussion)

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: nfd...@packages.debian.org
Control: affects -1 + src:nfdump

[ Reason ]
I am proposing updating updating the nfdump package to a new _upstream_ release
in bookworm.

I made the judgement to switch to the new nfdump 1.7 series in the bookworm
release cycle. This has turned out to be premature. The 1.7.1 release we
shipped in bookworm was under rapid development.

One of the most popular applications for nfdump is to run it together with
nfsen, a PHP based webfrontend to collect and analyze netflows. This one also
has been under rapid development during the bookworm freeze.

It turns out that at least in some cases nfdump does not work well with recent
nfsen versions, see Bug#1042535. The likely commit has been identified, but it
was impossible to backport it due to the major source restructuring nfdump
1.7.x went through. Between 1.7.1 and 1.7.3 there were 169 commits, with bugfix
commits touching core parts of the code.

Things however appear to have stabilized now. The 1.7.3 release is a couple of
weeks old, with no bad bug reports appearing. It has been tested both by the
reporter of Bug#1042535 and by me, and it fixes all known errors with nfdump
1.7.x.

Therefor I'd like to update nfdump in bookworm from 1.7.1 to 1.7.3, same as in
testing.

The alternative would be to use backports to provide a better nfdump version
for bookworm users, but in this case I'm sure that 1.7.3 would be the better
fit for all users. If you reject updating to 1.7.3 I will do this instead.

I'm open to uploading that into -proposed early after the next point release to
give it the maximum possible coverage.

[ Impact ]
Users using nfsen (a popular framework for nfsen) will not get usable profiles.

[ Tests ]
There is an upstream testsuite ran during build, but this did not detect the
nfprofile issue earlier.

[ Risks ]
New upstream version always carries some risk, but the package is low popcon
and most of the times used with nfsen. Which is from the same author who
heartily recommends the latest 1.7.3

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

[ Changes ]
169 upstream commits.

[ Other info ]
I did not attach the debdiff because it would be too large and only consist
of upstream changes. No changes to debian/ (except dropping a backported fix
already in 12.1) are necessary.

Bug#904044: OpenVPN3

[Bernhard Schmidt]

Hi Marc,

Because our company decided "there will be no impact" to use multifactor 
authentication, I was forced to package openvpn3.


I don't know if you were planning anything in that direction, but my 
current work can be found here:


https://salsa.debian.org/televic-team/openvpn3 



It's rough, I need to go through the finer details.

If you are nog planning anything, I can open an ITP.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044 



Thanks for letting us know. I haven't taken a deep look at it, but it 
looks pretty sane and I'm not aware of any work other than the upstream 
repository. You are certainly welcome to package it.


I can review and sponsor the first uploads if noone beats me to it 
(anyone: feel free to do so, there is no need of the OpenVPN2 
maintainers to specifically review anything in OpenVPN3, and they will 
continue to be used in parallel for years to come).


I've seen you have applied for DM, so I would be happy to give you 
uploader rights when things have settled.


Bernhard

Bug#1050180: bookworm-pu: package freeradius/3.2.1+dfsg-4+deb12u1

[Bernhard Schmidt]

Hi,

Control: tag -1 confirmed

On Mon, Aug 21, 2023 at 04:16:12PM +0200, Bernhard Schmidt wrote:

[ Reason ]
I would like to fix a regression in the bookworm release of FreeRADIUS where
the TLS-Client-Cert-Common-Name attribute contains the wrong value, breaking
some use-cases (Bug#1043282)

It has been fixed in the new upstream version in sid, the two relevant commits
apply cleanly. The reporter has confirmed that this fixes his problem.


Please go ahead.


Thanks, the package has been uploaded and accepted.

Bernhard

Bug#1050180: bookworm-pu: package freeradius/3.2.1+dfsg-4+deb12u1

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: freerad...@packages.debian.org
Control: affects -1 + src:freeradius

[ Reason ]
I would like to fix a regression in the bookworm release of FreeRADIUS where
the TLS-Client-Cert-Common-Name attribute contains the wrong value, breaking
some use-cases (Bug#1043282)

It has been fixed in the new upstream version in sid, the two relevant commits
apply cleanly. The reporter has confirmed that this fixes his problem.

[ Impact ]
Attribute not usable for filtering/policy decisions

[ Tests ]
no additional CI tests covering _this_ specific feature. Reporter has confirmed
the fix.

[ Risks ]
Change is small and has been part of two upstream releases

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

[ Changes ]
See above + d/gbp.conf for the correct stable branch

[ Other info ]
none
diff -Nru freeradius-3.2.1+dfsg/debian/changelog 
freeradius-3.2.1+dfsg/debian/changelog
--- freeradius-3.2.1+dfsg/debian/changelog  2023-05-16 00:04:23.0 
+0200
+++ freeradius-3.2.1+dfsg/debian/changelog  2023-08-19 00:26:34.0 
+0200
@@ -1,3 +1,11 @@
+freeradius (3.2.1+dfsg-4+deb12u1) bookworm; urgency=medium
+
+  * Add d/gbp.conf for bookworm stable branch
+  * Cherry-Pick two upstream commits to fix TLS-Client-Cert-Common-Name
+contains incorrect value (Closes: #1043282)
+
+ -- Bernhard Schmidt   Sat, 19 Aug 2023 00:26:34 +0200
+
 freeradius (3.2.1+dfsg-4) unstable; urgency=medium
 
   * Don't install symlink for cache_eap module no longer shipped
diff -Nru freeradius-3.2.1+dfsg/debian/gbp.conf 
freeradius-3.2.1+dfsg/debian/gbp.conf
--- freeradius-3.2.1+dfsg/debian/gbp.conf   1970-01-01 01:00:00.0 
+0100
+++ freeradius-3.2.1+dfsg/debian/gbp.conf   2023-08-19 00:26:34.0 
+0200
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = debian/bookworm
diff -Nru 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch
--- 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch
1970-01-01 01:00:00.0 +0100
+++ 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch
2023-08-19 00:26:34.0 +0200
@@ -0,0 +1,40 @@
+From d23987cbf55821dc56ab70d5ce6af3305cf83289 Mon Sep 17 00:00:00 2001
+From: "Alan T. DeKok" 
+Date: Tue, 25 Oct 2022 10:51:02 -0400
+Subject: [PATCH] set partial chain always.  Helps with #4785
+
+---
+ src/main/tls.c | 11 ---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/src/main/tls.c b/src/main/tls.c
+index aa6395d8391f..a33699cbb66e 100644
+--- a/src/main/tls.c
 b/src/main/tls.c
+@@ -3546,6 +3546,11 @@ X509_STORE *fr_init_x509_store(fr_tls_server_conf_t 
*conf)
+   if (conf->check_all_crl)
+   X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK_ALL);
+ #endif
++
++#if defined(X509_V_FLAG_PARTIAL_CHAIN)
++  X509_STORE_set_flags(store, X509_V_FLAG_PARTIAL_CHAIN);
++#endif
++
+   return store;
+ }
+ 
+@@ -4011,11 +4016,11 @@ SSL_CTX *tls_init_ctx(fr_tls_server_conf_t *conf, int 
client, char const *chain_
+   if (conf->ca_file || conf->ca_path) {
+   if ((certstore = fr_init_x509_store(conf)) == NULL ) return 
NULL;
+   SSL_CTX_set_cert_store(ctx, certstore);
+-  }
+-
++  } else {
+ #if defined(X509_V_FLAG_PARTIAL_CHAIN)
+-  X509_STORE_set_flags(SSL_CTX_get_cert_store(ctx), 
X509_V_FLAG_PARTIAL_CHAIN);
++  X509_STORE_set_flags(SSL_CTX_get_cert_store(ctx), 
X509_V_FLAG_PARTIAL_CHAIN);
+ #endif
++  }
+ 
+   if (conf->ca_file && *conf->ca_file) SSL_CTX_set_client_CA_list(ctx, 
SSL_load_client_CA_file(conf->ca_file));
+ 
diff -Nru 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch
--- 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch
1970-01-01 01:00:00.0 +0100
+++ 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch
2023-08-19 00:26:34.0 +0200
@@ -0,0 +1,29 @@
+From 3d08027f30c6d9c1eaccf7d60c68c8f7d78017c3 Mon Sep 17 00:00:00 2001
+From: "Alan T. DeKok" 
+Date: Wed, 26 Oct 2022 07:31:43 -0400
+Subject: [PATCH] fix cert order only for lookup=0.  Fixes #4785
+
+---
+ src/main/tls.c | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/src/main/tls.c b/src/main/tls.c
+index a33699cbb66e..c67148cf12c7 100644
+--- a/src/main/tls.c
 b/src/main/tls.c
+@@ -3015,7 +3015,14 @@ int cbtls_verify(int ok, X509_STORE_CTX *ctx)
+*/
+   if (lookup

Bug#1043282: freeradius: TLS-Client-Cert-Common-Name contains incorrect value

[Bernhard Schmidt]

Control: forward -1 https://github.com/FreeRADIUS/freeradius-server/issues/4785
Control: fixed -1 3.2.3+dfsg-1

On 08/08/23 02:59 PM, Åke Holmlund wrote:

> We have a setup with TLS authentication where we use the CN of the
> client certificate ti check in LDAP if that CN has access to our VPN
> service. This was working fine in bullseye but breaks in bookworm. The
> reason is that TLS-Client-Cert-Common-Name no longer contains the CN
> from the client certificate but the CN from the CA certificate.
> 
> This is a known bug in freeradius 3.2.1 (see
> https://github.com/FreeRADIUS/freeradius-server/issues/4785) and is
> fixed in 3.2.2. I REALLY hope this can be fixed ASAP in bookworm
> because we have had to skip the LDAP check to get our VPN working
> again and that is not a good thing.

I have cherry-picked both commits mentioned in the GH issue, could you
please try the binaries at

https://people.debian.org/~berni/freeradius/

Thanks,
Bernhard

Bug#1042535: Acknowledgement (nfdump doesn't work with profiles using nfsen 1.3.9)

[Bernhard Schmidt]

Control: tags -1 confirmed upstream
Control: forward -1 https://github.com/phaag/nfsen/issues/19
Control: found -1 1.7.1-1

On 31/07/23 08:16 AM, Marcelo Gondim wrote:

Hi,

> > The commit you mention is quite intrusive (a lot of source cleanup mixed
> > with the bugfix) and does not apply to 1.7.1

So, I tested some more.

With my installation (still on Bullseye) the official backport of 1.7.1
somewhat works. A few random channels in a profile sometimes show 0 and
throw errors like

Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Unable to read appendix block of file: 
/opt/nfsen/profiles-data/ECIX/ECIX-BER-in/2023/08/18/nfcapd.202308181520
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Unable to read appendix block of file: 
/opt/nfsen/profiles-data/ECIX/ECIX-MUC-in/2023/08/18/nfcapd.202308181520
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
ptr error - elementHeader > eor

when running a query against it, but it mostly works.

The patch you mentioned can be applied with just a single manually fixed
reject, it builds cleanly and the testsuite also works. But with this
patch it actually is worse, no data is ever created by nfprofile. No
error in the logs.

Plain 1.7.2 does not work either, same issue.

On 1.7.2 the patch you mentioned does not apply either, it has other
rejects. Looking at the changes src/lib/nffile.c had since 1.7.2 has
been released I would not be comfortable to do this.

The current git head appears to work fine, but that's not an option for
stable.

Looking at the commits I think it's virtually impossible to get a clean
"this minimally intrusive commit fixes the bug on top of the 1.7.1 in
stable", so I believe the only viable option would be 

- upload current snapshot to unstable fixing this bug
- as soon as there is a 1.7.3 release, upload that and provide a
  bookworm-backport for people using nfsen

Bernhard

Bug#1024129: ITP: tacacs+ -- TACACS+ authentication daemon

[Bernhard Schmidt]

On 28/06/23 11:01 PM, Daniel Gröber wrote:

Hi,

> I'm also interested in having tacacs+ available in Debian. I wanted to test
> your packages but unfortunately mentors removes packages after a while and
> so they are gone from there now.
> 
> The git repo you linked to doesn't seem to contain debian packaging. Could
> you re-upload to mentors or push your packaging/debian branch?

I was also looking at this, Pawel any chance you could upload your
previous work somewhere?

There are multitude of issues with the current codebase and so far I'm
not sure whether all of them can be solved.

- latest Debian package had 4.0.4.27a from 2013
- latest official release is 4.0.4.28 from January 2015
- there is a 4.0.4.29a from March 2015 in the alpha/ directory of the
  upstream FTP server

There is at least one known fork of 4.0.4.28 from Facebook at
https://github.com/facebook/tac_plus . The project started good but
looks dead. There are however a few interesting open pull requests that
appear to fix errors on RHEL9, that should be sufficiently close to us.

The thing that lead to the removal from Debian was python2. Glancing at
the code I could not figure out the reason for the build-time
dependency. There is a python script installed in the tacacs+ binary
package (do_auth.py). Not everyone uses that. We don't, so I cannot
fully test it. But at first glance it appears to be able to be run on
python3 by just dropping the future imports. And there is an official
python3 port by it's original author at https://www.tacacs.org/

So I think using the Facebook fork with a few imported pull-requests and
maybe switching to the newer do_auth.py (in a seperate binary package
while we are at it) could do the trick.

Bernhard

Bug#1040447: odbc-mariadb cannot set up odcb-mariadb

[Bernhard Schmidt]

Control: severity -1 important
Control: tags -1 unreproducible

Same as Tuukka I cannot reproduce this. 

Bug#1041349: transition: linphone-stack

[Bernhard Schmidt]

Am 31.07.23 um 21:25 schrieb Sebastian Ramacher:

Hi

On 2023-07-30 11:09:08 +0200, Bernhard Schmidt wrote:

We need a rebuild of src:libosmo-abis against the new version of libortp and
trx will be removed, see Bug#1026042


Why is the rebuild of libosmo-abis required?


https://tracker.debian.org/pkg/ortp

migrating libortp16/1:5.2.0-2/amd64 to testing makes 
libosmotrau2/1.3.0-2+b1/amd64 uninstallable


linphone-stack upstream does not really support mixing the branches of 
the various libraries, so we don't use symbols and generate shlis 
dependencies like this


libortp16 (>= 1:5.1.64), libortp16 (<< 1:5.2.0)

and for the new version of libortp

libortp16 (>= 1:5.2.0-1), libortp16 (<< 1:5.3.0-1)

BTW, the RM bug for src:trx is Bug#1042534

Bernhard

Bug#1042535: Acknowledgement (nfdump doesn't work with profiles using nfsen 1.3.9)

[Bernhard Schmidt]

Hi Marcelo,

I asked Peter which commit solved the problem and I'm waiting for a 
response from him. While waiting for his response, I looked at the 
1.7.2 release commits at 
https://github.com/phaag/nfdump/compare/v1.7.2...master and saw this line:


Update nfprofile:
phaag committed on May 5
https://github.com/phaag/nfdump/commit/18a34c16b6d070323d3d44cb22af48a85ac9b0c5

But I can't tell you exactly if it was this commit that solved the 
problem.


Have you tested with the plain 1.7.2 release and it was still broken? So 
the commit that fixes _your_ issue was introduced after 1.7.2 has been 
released?


The commit you mention is quite intrusive (a lot of source cleanup mixed 
with the bugfix) and does not apply to 1.7.1


patching file src/lib/nffile.c
Hunk #2 FAILED at 39.
Hunk #3 succeeded at 50 (offset -1 lines).
Hunk #4 succeeded at 180 (offset -6 lines).
Hunk #5 succeeded at 210 (offset -6 lines).
Hunk #6 succeeded at 233 (offset -6 lines).
Hunk #7 succeeded at 256 (offset -6 lines).
Hunk #8 succeeded at 285 (offset -6 lines).
Hunk #9 succeeded at 318 (offset -6 lines).
Hunk #10 FAILED at 890.
Hunk #11 succeeded at 911 (offset -4 lines).
2 out of 11 hunks FAILED
patching file src/nfdump/nfdump.c
patching file src/nfsen/nfprofile.c
Hunk #1 succeeded at 100 (offset 1 line).
Hunk #2 succeeded at 122 (offset 1 line).
Hunk #3 succeeded at 164 (offset 1 line).
Hunk #4 succeeded at 176 (offset 1 line).
Hunk #5 succeeded at 191 (offset 1 line).
Hunk #6 succeeded at 205 (offset 1 line).
Hunk #7 succeeded at 218 (offset 1 line).
Hunk #8 succeeded at 244 (offset 1 line).
Hunk #9 FAILED at 292.
Hunk #10 succeeded at 317 (offset 1 line).
1 out of 10 hunks FAILED
patching file src/nfsen/profile.c

There are so many code changes between 1.7.1 and this commit that I 
would feel _very_ uncomfortable beating this specific commit into applying.


Bernhard

Bug#1041349: transition: linphone-stack

[Bernhard Schmidt]

Control: block -1 by 1026042

Am 27.07.23 um 00:33 schrieb Sebastian Ramacher:

Control: tags -1 confirmed

On 2023-07-17 21:38:47 +0200, Bernhard Schmidt wrote:

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

Hi,

I would like to upload a new release of the linphone-stack to unstable.


Please go ahead.


Stack has been uploaded and built on almost all architectures (except 
for riscv64)


We need a rebuild of src:libosmo-abis against the new version of libortp 
and trx will be removed, see Bug#1026042


Bernhard

Bug#1042535: Acknowledgement (nfdump doesn't work with profiles using nfsen 1.3.9)

[Bernhard Schmidt]

Hi Marcelo,


Just to complement, using the recent version of nfdump from github, the 
bug does not occur.


Thanks for the report. Do you by any chance know which exact commit 
fixes this issue? Is the fix in 1.7.2 or post-1.7.2 (only in git master)?


I can update unstable to 1.7.2 or even the latest git snapshot, but I 
need a specific commit to backport the fix to bullseye.


Bernhard

Bug#1026042: trx: License is incompatible with that of up-coming ortp 5.2.0

[Bernhard Schmidt]

Control: severity -1 serious

On 08/02/23 08:55 AM, Kyle Robbertze wrote:

Hi Kyle,

> > With the recently released version 5.2 ortp has been relicensed to GNU
> > AGPL-3+.  Since your package is GPL-2 it is my understanding that it
> > may not link in ortp 5.2 until it is relicensed to either GPL-3 or
> > AGPL-3.
> As there has not been any development upstream in several years, I think we
> will need to remove trx from Debian once the new ortp version is released.

ortp 5.2 has now been uploaded to unstable. 

Bernhard

Bug#1041349: transition: linphone-stack

[Bernhard Schmidt]

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

Hi,

I would like to upload a new release of the linphone-stack to unstable.

It consists of a number of packages that have been staged in experimental

  bctoolbox
  belr
  bcmatroska2
  bzrtp
  ortp
  belcard
  belle-sip
  lime
  mediastreamer2
  linphone
  linphone-desktop

The only external hit will be on src:trx which is not compatible with the new
license. The maintainer has agreed for it to be removed in #1026042. Other than
that the linphone stack is self-contained these days.

It will fix two RC bugs in unstable (ftbfs with GCC-13).

Automatic transition trackers for some of the libraries involved are

https://release.debian.org/transitions/html/auto-belle-sip.html
https://release.debian.org/transitions/html/auto-linphone.html
https://release.debian.org/transitions/html/auto-mediastreamer2.html
https://release.debian.org/transitions/html/auto-bzrtp.html

Bernhard

Bug#1040830: ESNET-SECADV-2023-0001: iperf3 memory allocation hazard and crash

[Bernhard Schmidt]

Source: iperf3
Version: 3.13-2
Severity: serious
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 

A security advisory for iperf3 has been issued.

https://downloads.es.net/pub/iperf/esnet-secadv-2023-0001.txt.asc

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

ESnet Software Security Advisory
ESNET-SECADV-2023-0001

Topic:  iperf3 memory allocation hazard and crash
Issued: 7 July 2023
Credits:@someusername123 via GitHub
Affects:iperf-3.13 and earlier
Corrected:  iperf-3.14
Cross-references:   esnet/iperf#1542 on GitHub

I.  Background

iperf3 is a utility for testing network performance using TCP, UDP,
and SCTP, running over IPv4 and IPv6.  It uses a client/server model,
where a client and server communicate the parameters of a test,
coordinate the start and end of the test, and exchange results.  This
message exchange takes place over a TCP "control connection".

II.  Problem Description

The iperf3 server and client will, at various times, exchange
JSON-formatted messages containing parameters and test results. By
convention, the actual JSON representation is preceded by a four-byte
integer that gives the length of the JSON message.

iperf3 uses the length to determine the size of a dynamically
allocated memory buffer in which to store the incoming message. If the
length equals 0x, an integer overflow can be triggered in the
receiving iperf3 process (typically the server), which can in turn
cause heap corruption and an abort/crash. While this is unlikely to
happen during normal iperf3 operation, a suitably crafted client
program could send a sequence of bytes on the iperf3 control channel
to cause an iperf3 server to crash.

III.  Impact

A malicious process can connect to an iperf3 server and, by sending a
malformed message on the control channel, cause the server process to
abort due to heap corruption. A malicious iperf3 server could
potentially mount a similar attack on an iperf3 client.

Among the officially supported platforms, this problem has only been
observed on Linux. So far, it has not been reproduced with iperf3
running under Linux or macOS.

iperf2, an older version of the iperf utility, uses a different model
of interaction between client and server, and is not affected by this
issue.

IV.  Workaround

There is no workaround for this issue, however as best practice
dictates, iperf3 should not be run with root privileges, to minimize
possible impact.

V.  Solution

Update iperf3 to a version containing the fix (i.e. iperf-3.14 or
later).

VI.  Correction details

The bug causing this vulnerability has been fixed by the following
commit in the esnet/iperf Github repository:

master  0ef151550d96cc4460f98832df84b4a1e87c65e9

All released versions of iperf3 issued on or after the date of this
advisory incorporate the fix.
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEE+Fo4IENp9xo01E6DSYSRCoyq7ooFAmSogHEACgkQSYSRCoyq
7orOGwgAwoF1S8ta/be1y90NYif36DnXDLjEvgcPwnFy4YadG4bI5Rx3btO73NGH
Xp/T/PXROtU40Qu3TaQsmEGFn46I+hgbGyzd11oxX1mysK6n0U3BUPCdgn7+JA5A
vpFfL4mo1efYe5cBEEUy6fnY7PipC4ltYv6I0jb4zprQalKZaPaP4TVm4si+vNKT
TViLgOZzvelIatKPl0SY7SEEQj7vkJDNw89kxQG9jZExeS1qLgPwRsmyR0b4TTDc
MMtUjn4Zl/uR2vCPeEmxTmh+QutY35vOw4N6vaqaUcHspNGJrWy5XW4QuIGEsbBq
KLsKmkzHa/fYp+1SesgNMrJkutOo2g==
=puru
-END PGP SIGNATURE-

Bug#1038899: bookworm-pu: package nfdump/1.7.1-2+deb12u1

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: nfd...@packages.debian.org
Control: affects -1 + src:nfdump

[ Reason ]
This update fixes two errors reported in #1038644
- a segfault when using a particular option
- a wrong 'failed' indication in the sysvinit initscript

The segfault fix is straight forward and just an error in the option
parsing.

[ Impact ]
nfcapd cannot repeat the packets received to another receiver

[ Tests ]
The same fix has been uploaded to 1.7.1-3 in unstable and the reporter
has verified the fix.

[ Risks ]
Fairly minor risk, the option parsing change has been part of an upstream
release (but mixed with a complete rewrite of the actual repeater code, so
it cannot be cherry-picked).

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

[ Changes ]
In addition debian/gbp.conf has been changed to point to the debian/bullseye
branch.

[ Other info ]
-
diff -Nru nfdump-1.7.1/debian/changelog nfdump-1.7.1/debian/changelog
--- nfdump-1.7.1/debian/changelog   2023-01-05 12:35:34.0 +0100
+++ nfdump-1.7.1/debian/changelog   2023-06-22 22:18:53.0 +0200
@@ -1,3 +1,12 @@
+nfdump (1.7.1-2+deb12u1) bookworm; urgency=medium
+
+  * [8554dec3] Fix init script to return success when process has started.
+Thanks to Yury Shevchuk
+  * [c9d7e789] Fix segfault in getopt parsing for -R (Closes: #1038644)
+  * [eb140f97] d/gbp.conf: set debian branch
+
+ -- Bernhard Schmidt   Thu, 22 Jun 2023 22:18:53 +0200
+
 nfdump (1.7.1-2) unstable; urgency=medium
 
   * [64bef089] Add tzdata build dependency (Closes: #1027379)
diff -Nru nfdump-1.7.1/debian/gbp.conf nfdump-1.7.1/debian/gbp.conf
--- nfdump-1.7.1/debian/gbp.conf2023-01-05 12:35:34.0 +0100
+++ nfdump-1.7.1/debian/gbp.conf2023-06-22 22:18:53.0 +0200
@@ -2,7 +2,7 @@
 
 [DEFAULT]
 # the default branch for the debian patch:
-debian-branch = unstable
+debian-branch = debian/bookworm
 # use pristine-tar:
 pristine-tar = True
 
diff -Nru nfdump-1.7.1/debian/nfdump.init nfdump-1.7.1/debian/nfdump.init
--- nfdump-1.7.1/debian/nfdump.init 2023-01-05 12:35:34.0 +0100
+++ nfdump-1.7.1/debian/nfdump.init 2023-06-22 22:18:53.0 +0200
@@ -58,19 +58,27 @@
 fi
 
 local PIDFILE="$PIDDIR$INSTANCE.pid"
+# Check if process is already running
 start-stop-daemon --start --quiet \
 --pidfile "$PIDFILE" --exec "$NFCAPD" --test > /dev/null \
 || return 1
+
+# Start process
 start-stop-daemon --start --quiet \
 --pidfile "$PIDFILE" \
 --exec "$NFCAPD" -- \
 -D -P "$PIDFILE" \
 $options \
 || return 2
+
+# Wait for 1 sec and check again if process has started successfully
 sleep 1
 start-stop-daemon --start --quiet \
 --pidfile "$PIDFILE" --exec "$NFCAPD" --test > /dev/null \
 && return 2
+
+# All good, return 0
+return 0
 }
 
 # Stop a nfcapd instance
diff -Nru nfdump-1.7.1/debian/patches/fix-segfault-in-getopt.patch 
nfdump-1.7.1/debian/patches/fix-segfault-in-getopt.patch
--- nfdump-1.7.1/debian/patches/fix-segfault-in-getopt.patch1970-01-01 
01:00:00.0 +0100
+++ nfdump-1.7.1/debian/patches/fix-segfault-in-getopt.patch2023-06-22 
22:18:53.0 +0200
@@ -0,0 +1,11 @@
+--- a/src/nfcapd/nfcapd.c
 b/src/nfcapd/nfcapd.c
+@@ -605,7 +605,7 @@
+ metricSocket = NULL;
+ metricInterval = 60;
+ 
+-while ((c = getopt(argc, argv, 
"46B:b:C:DeEf:g:hI:i:jJ:l:m:M:n:p:P:rRs:S:t:T:u:vVw:x:yzZ")) != EOF) {
++while ((c = getopt(argc, argv, 
"46B:b:C:DeEf:g:hI:i:jJ:l:m:M:n:p:P:rR:s:S:t:T:u:vVw:x:yzZ")) != EOF) {
+ switch (c) {
+ case 'h':
+ usage(argv[0]);
diff -Nru nfdump-1.7.1/debian/patches/series nfdump-1.7.1/debian/patches/series
--- nfdump-1.7.1/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ nfdump-1.7.1/debian/patches/series  2023-06-22 22:18:53.0 +0200
@@ -0,0 +1 @@
+fix-segfault-in-getopt.patch

Bug#1038824: bookworm-pu: package openvpn/2.6.3-1+deb12u1

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: open...@packages.debian.org
Control: affects -1 + src:openvpn

This -pu cherry-picks two fixes from upstream. One fixing a memory
leak that is noticable on long running servers, and one dangling pointer that
might lead to crashes. Both have been in 2.6.3-2 for about a month now,
migrated to testing flawlessly and are part of the recent upstream stable
release. 

There is nothing else in 2.6.3-2 that is not suitable for bookworm, I have just
changed the version and set the correct branch in gbp.conf

[ Reason ]
Bugfix

[ Impact ]
Memory leak

[ Tests ]
Upstream has an extensive testsuite/CI coverage. Part of it is ran during
build.

[ Risks ]
Isolated fixes that have been vetted upstream and have been part of an upstream
release

[ 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

Bernhard
diff -Nru openvpn-2.6.3/debian/changelog openvpn-2.6.3/debian/changelog
--- openvpn-2.6.3/debian/changelog  2023-04-13 09:19:40.0 +0200
+++ openvpn-2.6.3/debian/changelog  2023-06-21 21:41:33.0 +0200
@@ -1,3 +1,12 @@
+openvpn (2.6.3-1+deb12u1) bookworm; urgency=medium
+
+  * Cherry-pick two bugfix commits from upstream
+- Memory leak in dco_get_peer_stats_multi for Linux
+- dangling pointer passed to pkcs11-helper
+  * d/gbp.conf: set branch to bookworm
+
+ -- Bernhard Schmidt   Wed, 21 Jun 2023 21:41:33 +0200
+
 openvpn (2.6.3-1) unstable; urgency=medium
 
   * New upstream version 2.6.2
diff -Nru openvpn-2.6.3/debian/gbp.conf openvpn-2.6.3/debian/gbp.conf
--- openvpn-2.6.3/debian/gbp.conf   2023-04-13 09:19:40.0 +0200
+++ openvpn-2.6.3/debian/gbp.conf   2023-06-21 21:41:33.0 +0200
@@ -1,2 +1,3 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = debian/bookworm
diff -Nru openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch 
openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch
--- openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch   
1970-01-01 01:00:00.0 +0100
+++ openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch   
2023-06-21 21:41:33.0 +0200
@@ -0,0 +1,37 @@
+From 7e4becb4cd8be7f0d5ff80cf80877ea152f99830 Mon Sep 17 00:00:00 2001
+From: Selva Nair 
+Date: Tue, 9 May 2023 13:05:17 -0400
+Subject: [PATCH] Bugfix: dangling pointer passed to pkcs11-helper
+
+Github: Fixes OpenVPN/openvpn#323
+
+Signed-off-by: Selva Nair 
+Acked-by: Gert Doering 
+Message-Id: <20230509170517.2637245-1-selva.n...@gmail.com>
+URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26640.html
+Signed-off-by: Gert Doering 
+(cherry picked from commit f4850745709c5b80ab7d09c03a86c5ceea6d10a2)
+---
+ src/openvpn/pkcs11_openssl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/openvpn/pkcs11_openssl.c b/src/openvpn/pkcs11_openssl.c
+index eee86e17b6f..9b0ab39f9cf 100644
+--- a/src/openvpn/pkcs11_openssl.c
 b/src/openvpn/pkcs11_openssl.c
+@@ -165,6 +165,7 @@ xkey_pkcs11h_sign(void *handle, unsigned char *sig,
+ {
+ pkcs11h_certificate_t cert = handle;
+ CK_MECHANISM mech = {CKM_RSA_PKCS, NULL, 0}; /* default value */
++CK_RSA_PKCS_PSS_PARAMS pss_params = {0};
+ 
+ unsigned char buf[EVP_MAX_MD_SIZE];
+ size_t buflen;
+@@ -203,7 +204,6 @@ xkey_pkcs11h_sign(void *handle, unsigned char *sig,
+ }
+ else if (!strcmp(sigalg.padmode, "pss"))
+ {
+-CK_RSA_PKCS_PSS_PARAMS pss_params = {0};
+ mech.mechanism = CKM_RSA_PKCS_PSS;
+ 
+ if (!set_pss_params(_params, sigalg, cert))
diff -Nru 
openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch 
openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch
--- openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch  
1970-01-01 01:00:00.0 +0100
+++ openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch  
2023-06-21 21:41:33.0 +0200
@@ -0,0 +1,33 @@
+From 5e8a571af165c867ccb9c4c9e6334620f42013ac Mon Sep 17 00:00:00 2001
+From: Frank Lichtenheld 
+Date: Mon, 15 May 2023 16:21:16 +0200
+Subject: [PATCH] DCO: fix memory leak in dco_get_peer_stats_multi for Linux
+
+Leaks a small amount of memory every 15s.
+
+Signed-off-by: Frank Lichtenheld 
+Acked-by: Antonio Quartulli 
+Message-Id: <20230515142116.33135-1-fr...@lichtenheld.com>
+URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26659.html
+Signed-off-by: Gert Doering 
+(cherry picked from commit 276f7c86d70666bc2ab4e6192ef5f1dcbd6a230f)
+---
+ src/openvpn/dco_linux.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/src/openvpn/dco_linux.c b/src/open

Bug#1038644: nfdump: segfault if started with -R option

[Bernhard Schmidt]

On 19/06/23 05:25 PM, Yury Shevchuk wrote:

> # /usr/bin/nfcapd -D -P /var/run/nfcapd/default.pid -w /var/cache/nfdump -S1 
> -b 120.0.1 -p 2055 -R 127.0.0.2 2055
> Segmentation fault
> The patch (trivial) is attached.

Thanks. For the record, this is included in the much larger

https://github.com/phaag/nfdump/commit/abfab42419117add44e1ea15ad9559d265642219#diff-c95665baa1999e70e29344d1dc05f3282cd1cf7f31b47341581cd1cf81b7d062R593

in v1.7.2

> A minor change in /etc/init.d/nfdump conffile (added return 0) fixes false
> "failed!" message from "/etc/init.d/nfdump start" which appears on systems
> using sysvinit-core rather than systemd.

I really don't get what this code is supposed to do though. And I don't
want to invest much time into sysvinit.  From my understanding

start-stop-daemon --start --quiet \
--pidfile "$PIDFILE" --exec "$NFCAPD" --test > /dev/null \
|| return 1

First we run with --test. If start-stop-daemon returns zero (process not
already running) we continue, else we return 1. So far so good.

start-stop-daemon --start --quiet \
--pidfile "$PIDFILE" \
--exec "$NFCAPD" -- \
-D -P "$PIDFILE" \
$options \
|| return 2

Now we really start it. If we can do it we continue, if we can't we
return 2 (could not be started)

sleep 1
start-stop-daemon --start --quiet \
--pidfile "$PIDFILE" --exec "$NFCAPD" --test > /dev/null \
&& return 2

Now we basically test again if the daemon is already running. If it
isn't, we return 2, 

At this point we have checked that 1 second after the start the process
is still running, and can return 0.

Could you please try the just uploaded 1.7.1-3 to verify the fix for
both bugs?

Bernhard

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Bernhard Schmidt]

Hi Utkarsh,


I've actually managed to prepare a final update that I'm ready to
upload - this has quite some fixes plus 2 new CVE fixes. Would you
please test the new resulting binaries and make sure they look sane
enough? :)

The binaries can be found at
https://people.debian.org/~utkarsh/lts/ruby2.5/. Many thanks!


I don't use ruby outside of puppet, but my puppet problem is fixed with 
these binaries. So from my POV you can release it.


Many thanks!
Bernhard

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Bernhard Schmidt]

Package: libruby2.5
Version: 2.5.5-3+deb10u5
Severity: grave

Hi,

I can't quite figure out why, but the latest security upload of ruby2.5 in
Buster breaks the ability of the puppet agent to pull files from the master

With 2.5.5-3+deb10u4:
# puppet agent --onetime --server puppet-kom.srv.lrz.de  --test  --no-daemonize
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for simrad3.slb.lrz.de
Info: Applying configuration version 'master-70189ef6ab5a'


# apt dist-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libruby2.5 ruby2.5
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 3841 kB of archives.
After this operation, 2048 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://debian.mirror.lrz.de/debian-security buster/updates/main amd64 
libruby2.5 amd64 2.5.5-3+deb10u5 [3440 kB]
Get:2 http://debian.mirror.lrz.de/debian-security buster/updates/main amd64 
ruby2.5 amd64 2.5.5-3+deb10u5 [401 kB]
Fetched 3841 kB in 0s (30.3 MB/s)
Reading changelogs... Done
(Reading database ... 58907 files and directories currently installed.)
Preparing to unpack .../libruby2.5_2.5.5-3+deb10u5_amd64.deb ...
Unpacking libruby2.5:amd64 (2.5.5-3+deb10u5) over (2.5.5-3+deb10u4) ...
Preparing to unpack .../ruby2.5_2.5.5-3+deb10u5_amd64.deb ...
Unpacking ruby2.5 (2.5.5-3+deb10u5) over (2.5.5-3+deb10u4) ...
Setting up libruby2.5:amd64 (2.5.5-3+deb10u5) ...
Setting up ruby2.5 (2.5.5-3+deb10u5) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for libc-bin (2.28-10+deb10u2) ...

# puppet agent --onetime --server puppet-kom.srv.lrz.de  --test  --no-daemonize
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Error: /File[/var/lib/puppet/facts.d]: Failed to generate additional resources 
using 'eval_generate': Failed to open TCP connection to :8140 (Connection 
refused - connect(2) for "" port 8140)
Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not retrieve 
file metadata for puppet:///pluginfacts: Failed to open TCP connection to :8140 
(Connection refused - connect(2) for "" port 8140)
Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources 
using 'eval_generate': Failed to open TCP connection to :8140 (Connection 
refused - connect(2) for "" port 8140)
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve file 
metadata for puppet:///plugins: Failed to open TCP connection to :8140 
(Connection refused - connect(2) for "" port 8140)
Info: Retrieving locales
Error: /File[/var/lib/puppet/locales]: Failed to generate additional resources 
using 'eval_generate': Failed to open TCP connection to :8140 (Connection 
refused - connect(2) for "" port 8140)
Error: /File[/var/lib/puppet/locales]: Could not evaluate: Could not retrieve 
file metadata for puppet:///locales: Failed to open TCP connection to :8140 
(Connection refused - connect(2) for "" port 8140)
Info: Loading facts
Info: Caching catalog for simrad3.slb.lrz.de
Info: Applying configuration version 'master-70189ef6ab5a'
Error: 
/Stage[main]/Lrz_kom_radius::Radiussimrad/File[/etc/freeradius/.git/hooks/post-commit]:
 Could not evaluate: Could not retrieve file metadata for 
puppet:///modules/lrz_kom/classes/radius/git_post-commit_hook: Failed to open 
TCP connection to :8140 (Connection refused - connect(2) for "" port 8140)
Error: 
/Stage[main]/Lrz_common::Distributions::Debian::Vim/File[/etc/vim/vimrc.lrz-puppet]:
 Could not evaluate: Could not retrieve file metadata for 
puppet:///modules/lrz_common/vimrc.lrz-puppet: Failed to open TCP connection to 
:8140 (Connection refused - connect(2) for "" port 8140)
Error: 
/Stage[main]/Lrz_common::Distributions::Debian::Emacs/File[//etc/emacs/site-start.d/99lrz.el]:
 Could not evaluate: Could not retrieve file metadata for 
puppet:///modules/lrz_common/emacs/99lrz.el: Failed to open TCP connection to 
:8140 (Connection refused - connect(2) for "" port 8140)
Error: 
/Stage[main]/Lrz_common::Distributions::Debian/File[/etc/apt/trusted.gpg.d/debian-lrz.asc]:
 Could not evaluate: Could not retrieve file metadata for 
puppet:///modules/lrz_common/debian/debian-lrz.asc: Failed to open TCP 
connection to :8140 (Connection refused - connect(2) for "" port 8140)
Error: /Stage[main]/Puppetclient::Config/File[/usr/bin/waitrandom]: Could not 
evaluate: Could not retrieve file metadata for 
puppet:///modules/puppetclient/waitrandom: Failed to open TCP connection to 
:8140 (Connection refused - connect(2) for "" port 8140)
Notice: Applied catalog in 1.82 seconds

Note the empty servername in the "Failed to open TCP connection" messages.

Bernhard

Bug#1034661: twinkle: Please update twinkle to latest release

[Bernhard Schmidt]

Control: tags -1 + patch
Control: severity -1 serious
Control: forwarded -1 
https://github.com/LubosD/twinkle/commit/da274607aa835a2735dcf9b9a7ba550910f9d03e

On 15/05/23 11:34 PM, Frédéric Brière wrote:
> On Fri, Apr 21, 2023 at 04:46:20PM +1000, Jason Lewis wrote:
> > Please can you update twinkle to the latest release version 1.10.3
> > 
> > this will at least solve https://github.com/LubosD/twinkle/issues/222
> 
> (Upstream co-maintainer speaking.)
> 
> To provide some context: the domain name once used by the original
> author to host the user manual has now been acquired by scammers
> peddling "male enhancement devices" and such.  As you can imagine, this
> is not quite what users expect to see when they click on the "Manual"
> entry in the Help menu.
> 
> This has already been fixed upstream a few years ago, but since we're
> unlikely to see a full Twinkle release in the near future, we also put
> out a single-fix 1.10.3 release for the sake of distributions, with this
> URL change being the only difference between 1.10.2 and 1.10.3.

Thanks for the heads-up. I think this is RC. And easy to fix.

If noone else steps up I'll prepare a team upload and file an unblock
request.

Bernhard

Bug#1034336: unblock: openvpn/2.6.3-1 and openvpn-dco-dkms/0.0+git20230324-1 (pre-approval)

[Bernhard Schmidt]

Control: tags -1 - moreinfo

> > in order to reduce the deviation from an upstream tag I'd like to skip
> > 2.6.2 and go for 2.6.3. Updated debdiff attached.
> 
> Please go ahead and remove the moreinfo tag once the packages are
> available in unstable.

Uploaded, accepted and built on all architectures. piuparts is clean,
the autopkgtest of openvpn-dco-dkms also ran fine. The autopkgtest for
openvpn won't run in the Debian infrastructure due to the unsupported
isolation-machine restriction.

Please unblock (and - if possible - age) both packages.

unblock openvpn/2.6.3-1
unblock openvpn-dco-dkms/0.0+git20230324-1

Bernhard


signature.asc
Description: PGP signature

Bug#1000793: bind9-dnsutils: dig command fails with "`fd > STDERR_FILENO' failed" when run from a XFCE4 desktop applet

[Bernhard Schmidt]

Control: reassign -1 xfce4-genmon-plugin
Control: tags -1 = upstream fixed-upstream patch
Control: affects -1 bind9-dnsutils
Control: forwarded -1 
https://gitlab.xfce.org/panel-plugins/xfce4-genmon-plugin/-/issues/19

Hi Cesar,

On 24/04/23 12:04 AM, Cesar Enrique Garcia Dabo wrote:
> This turned out to be a bug in xfce4-genmon-plugin. For the record, this is
> the bug report:

Thanks for following up on this. I'll reassign the bug accordingly.

Bernhard

Bug#1034317: unblock: linphone-desktop/4.4.10-3

[Bernhard Schmidt]

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

Please unblock package linphone-desktop

[ Reason ]
It fixes the RC bug #1033868 where you had to agree to the upstream's ToS and
privacy policy even if not using their SIP service. This has been fixed by
Dennis by backporting a patch that has been in experimental for quite some
time (but linphone 5.0 did not make the freeze)

[ Impact ]
RC bug is not fixed

[ Tests ]
Testing done by the maintainer

[ Risks ]
Code change is trivial

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

unblock linphone-desktop/4.4.10-3
diff -Nru linphone-desktop-4.4.10/debian/changelog 
linphone-desktop-4.4.10/debian/changelog
--- linphone-desktop-4.4.10/debian/changelog2022-11-27 18:02:24.0 
+0100
+++ linphone-desktop-4.4.10/debian/changelog2023-04-04 18:09:27.0 
+0200
@@ -1,3 +1,10 @@
+linphone-desktop (4.4.10-3) unstable; urgency=medium
+
+  * Add patch to relax needlessly strict Terms of Service dialogue
+(Closes: #1033868).
+
+ -- Dennis Filder   Tue, 04 Apr 2023 18:09:27 +0200
+
 linphone-desktop (4.4.10-2) unstable; urgency=medium
 
   * Release to unstable.
diff -Nru 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch
--- 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch
1970-01-01 01:00:00.0 +0100
+++ 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch
2023-04-04 18:09:27.0 +0200
@@ -0,0 +1,25 @@
+Description: Enable creation of third-party accounts unconditionally
+ Users should be able to do it without the need for accepting BC's
+ Terms of Use and Privacy Policy.
+Author: Dennis Filder 
+Last-Update: 2022-12-13
+--- a/linphone-app/ui/views/App/Main/Assistant/AssistantHome.qml
 b/linphone-app/ui/views/App/Main/Assistant/AssistantHome.qml
+@@ -101,7 +101,7 @@
+   
+   cellHeight: height / 2
+   cellWidth: width / 2
+-  enabled: cguCheckBox.checked
++//enabled: cguCheckBox.checked
+   
+   delegate: Item {
+   height: buttons.cellHeight
+@@ -113,7 +113,7 @@
+   margins: 
AssistantHomeStyle.buttons.spacing
+   }
+   
+-  enabled: cguCheckBox.checked && 
SettingsModel[$viewType.charAt(0).toLowerCase() + $viewType.slice(1) + 
"Enabled"]
++  enabled: $viewType=='UseOtherSipAccount' || 
(cguCheckBox.checked && SettingsModel[$viewType.charAt(0).toLowerCase() + 
$viewType.slice(1) + "Enabled"])
+   text: $text.replace('%1', 
Qt.application.name.toUpperCase())
+   
+   onClicked:{ assistant.pushView($view, $props) }
diff -Nru linphone-desktop-4.4.10/debian/patches/series 
linphone-desktop-4.4.10/debian/patches/series
--- linphone-desktop-4.4.10/debian/patches/series   2022-11-27 
18:02:24.0 +0100
+++ linphone-desktop-4.4.10/debian/patches/series   2023-04-04 
18:09:27.0 +0200
@@ -5,3 +5,4 @@
 louden-find-package.patch
 guard-codec-download.patch
 #a11y.patch
+adjust-terms-of-service-barrier.patch

Bug#1033006: unblock: openvpn/2.6.1-1 (preapproval)

[Bernhard Schmidt]

On 25/03/23 10:17 PM, Sebastian Ramacher wrote:

> > - upload 2.6.1 from experimental to unstable, then stage 2.6.2 and the
> >   new DCO in experimental for the second review round
> > 
> > I would prefer the last option.
> 
> Let's go ahead with the last option. Please let us know once openvpn
> 2.6.1 is in unstable.

src:openvpn 2.6.1-1 is in unstable. I have cherry-picked the three most
important fixes from 2.6.2 as well (one crash, one memory-leak and one
stall due to a blocking socket)

I have also uploaded src:openvpn 2.6.2-1~exp1 and src:openvpn-dco-dkms
0.0+git20230324-1~exp1 to experimental. Those are the version I'd like
to end up in bookworm.

I have filed an internal change to get 2.6.2+dcov2 installed on our eduVPN
node next week.

Bernhard


signature.asc
Description: PGP signature

Bug#1033006: unblock: openvpn/2.6.1-1 (preapproval)

[Bernhard Schmidt]

On 15/03/23 04:57 PM, Bernhard Schmidt wrote:

Hi,

> The upcoming DCO change will involve a new version of src:openvpn and a new 
> version
> of src:openvpn-dco-dkms. The list of changes on the kernel side is already 
> visible
> on https://github.com/OpenVPN/ovpn-dco/commits/master .
> 
> In the past we managed to break DCO on above mentioned really heavily loaded
> OpenVPN server within a few hours. The new version is a major overhaul and 
> more
> in-line with code upstreamable in Linux, and did survive torture tests.
> 
> I know this is kind of late, but I think it would be better to include it as 
> well
> as soon as it is released because
> 
> - we cannot support the old deprecated module
> - openvpn uses DCO (of the right version) automatically and will transparently
>   fall-back to non-DCO mode if the module is not found (or the wrong version)
> - it has not been in Bullseye previously, so if we see that DCO is too 
> unstable
>   with the new version we can just drop it before the release

So, the release of 2.6.2 with the new DCO module has been done
yesterday, fixing a number of bugs already present in 2.6.0.

https://github.com/OpenVPN/openvpn/blob/release/2.6/Changes.rst

---
New control packets flow for data channel offloading on Linux. 2.6.2+
changes the way OpenVPN control packets are handled on Linux when DCO is
active, fixing the lockups observed with 2.6.0/2.6.1 under high client
connect/disconnect activity. This is an INCOMPATIBLE change and
therefore an ovpn-dco kernel module older than v0.2.20230323 (commit ID
726fdfe0fa21) will not work anymore and must be upgraded. The kernel
module was renamed to "ovpn-dco-v2.ko" in order to highlight this change
and ensure that users and userspace software could easily understand
which version is loaded. Attempting to use the old ovpn-dco with 2.6.2+
will lead to disabling DCO at runtime.
---

So I need some guidance from the release team how to proceed. I can
think of

- abandoning all of this, leading to a bookworm release using a buggy
  OpenVPN version with a DCO kernel interface that noone else uses
- update experimental to 2.6.2 and the new DCO module, then ask for a
  approval for upload to unstable (2.6.1+2.6.2) in one go
- upload 2.6.2 and the new DCO module to unstable right away
- upload 2.6.1 from experimental to unstable, then stage 2.6.2 and the
  new DCO in experimental for the second review round

I would prefer the last option.

Bernhard

Bug#1033317: unblock: linphone/5.1.65-4

[Bernhard Schmidt]

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

Please unblock package linphone

[ Reason ]
Two important bugs have been resolved

* Disable behind-the-scenes download of the AppImage (Closes: #1031771).
* Update documentation to highlight limitations in linphonec CLI utility
  and to properly explain how to create an initial ~/.linphonerc file
  (Closes: #1032051).

[ Impact ]
linphone will attempt to self-update by downloading a newer AppImage
version, which is upstream's preferred way of distributing linphone

The second change is documentary only and will update README.Debian and
the manpage to explain about the configuration migration logic in
linphone (CLI) vs. linphone-desktop.

[ Tests ]
No automatic tests, patches have been prepared by Dennis who has been
maintaining linphone with an excellent quality in mind.

Version has been in unstable for two weeks now

[ Risks ]
Patch has been tested and could easily be backed out if necessary

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

[ Other info ]
-

unblock linphone/5.1.65-4
diff -Nru linphone-5.1.65/debian/changelog linphone-5.1.65/debian/changelog
--- linphone-5.1.65/debian/changelog2023-01-21 09:21:53.0 +0100
+++ linphone-5.1.65/debian/changelog2023-03-02 20:10:59.0 +0100
@@ -1,3 +1,12 @@
+linphone (5.1.65-4) unstable; urgency=medium
+
+  * Disable behind-the-scenes download of the AppImage (Closes: #1031771).
+  * Update documentation to highlight limitations in linphonec CLI utility
+and to properly explain how to create an initial ~/.linphonerc file
+(Closes: #1032051).
+
+ -- Dennis Filder   Thu, 02 Mar 2023 20:10:59 +0100
+
 linphone (5.1.65-3) unstable; urgency=medium
 
   * Port wrappers/cpp/genwrapper.py to Python 3.11 (Closes: #1029253).
diff -Nru linphone-5.1.65/debian/linphone-cli.README.Debian 
linphone-5.1.65/debian/linphone-cli.README.Debian
--- linphone-5.1.65/debian/linphone-cli.README.Debian   1970-01-01 
01:00:00.0 +0100
+++ linphone-5.1.65/debian/linphone-cli.README.Debian   2023-03-02 
20:10:59.0 +0100
@@ -0,0 +1,24 @@
+Debian-specific information
+===
+
+linphonec by default erroneously still solely expects ~/.linphonerc to
+be present and is unaware of ~/.config/linphone/linphonerc.  To make
+linphonec use ~/.config/linphone/linphonerc invoke it with the -c
+parameter:
+
+  linphone -c $HOME/.config/linphone/linphonerc
+
+Alternatively, you can create a suitable symbolic link by running:
+
+  ln -v -s $HOME/.config/linphone/linphonerc $HOME/.linphonerc
+
+This cannot be done automatically because it might interfere with
+configuration migration logic.
+
+Also take note of the fact that the Qt-based graphical linphone
+application houses all migration logic for configuration files, chat
+logs etc.  If you have any existing such files you should run the
+graphical linphone application to ensure it is properly migrated after
+every upgrade.
+
+ -- Dennis Filder , Thu,  2 Mar 2023 19:40:11 +0100
diff -Nru linphone-5.1.65/debian/patches/disable_appimage_download.patch 
linphone-5.1.65/debian/patches/disable_appimage_download.patch
--- linphone-5.1.65/debian/patches/disable_appimage_download.patch  
1970-01-01 01:00:00.0 +0100
+++ linphone-5.1.65/debian/patches/disable_appimage_download.patch  
2023-03-02 20:10:59.0 +0100
@@ -0,0 +1,27 @@
+Description: Disable behind-the-scenes AppImage download
+ The error message is unfortunately only printed to the log, not stderr.
+Author: Dennis Filder 
+Last-Update: 2023-03-02
+Bug-Debian: https://bugs.debian.org/1031771
+Forwarded: not-needed
+--- a/coreapi/update_check.c
 b/coreapi/update_check.c
+@@ -114,6 +114,11 @@
+   return;
+   }
+ 
++  if (!getenv("LINPHONE_DO_APPIMAGE_DOWNLOAD")) {
++  bctbx_error("AppImage download disabled.  To enable it restart 
the program with the variable LINPHONE_DO_APPIMAGE_DOWNLOAD set to \"y\" in the 
environment.");
++  return;
++  }
++
+   if (version_check_url_root != NULL) {
+   belle_http_request_listener_callbacks_t belle_request_listener 
= { 0 };
+   belle_http_request_t *request;
+@@ -154,4 +159,4 @@
+   request = belle_http_request_create("GET", uri, 
belle_sip_header_create("User-Agent", linphone_core_get_user_agent(lc)), NULL);
+   belle_http_provider_send_request(lc->http_provider, request, 
update->http_listener);
+   }
+-}
+\ No newline at end of file
++}
diff -Nru linphone-5.1.65/debian/patches/fix_linphonec_manpage.patch 
linphone-5.1.65/debian/patches/fix_linphonec_manpage.patch
--- linphone-5.1.65/debian/patches/fix_linphonec_manpage.patch  1970-01-01 
01:00:00.0 +0100
+++ 

Bug#1033050: amdgpu output on USB-C docking station fails (after screen suspend?)

[Bernhard Schmidt]

Package: src:linux
Version: 6.1.15-1
Severity: important

Hi,

I run a Lenovo T14s Gen2 with a Lenovo Dockingstation and two
DP-connected external displays, with KDE on Wayland.

Every few days, after an extended coffee break/lunch, I find my
previously locked session unusable. The displays stay in standby mode,
although KDE thinks they are connected and extends the workspace there.

The quickest option at this point is to open the laptop lid, switch to
the console and reboot. I have not found a way to revive the external
displays.

There is one kernel WARNING that looks related to external MST displays,
happens at the right time and matches my perceived frequency. KDE energy
settings are currently set to

blank screen after 5 minutes
suspend screen after 10 minutes

I left the desktop at 11:13, so the kernel warning happens at the same
time the screen was suspended.

Mär 16 11:18:41 badwlrz-cl99868 dbus-daemon[1807]: [system] Activating service 
name='org.kde.powerdevil.backlighthelper' requested by ':1.239' (uid=1176730394 
pid=28764 comm="/usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdev") (using >
Mär 16 11:18:41 badwlrz-cl99868 dbus-daemon[1807]: [system] Successfully 
activated service 'org.kde.powerdevil.backlighthelper'
Mär 16 11:23:42 badwlrz-cl99868 kernel: [ cut here ]
Mär 16 11:23:42 badwlrz-cl99868 kernel: WARNING: CPU: 3 PID: 31810 at 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:154 
fill_dc_mst_payload_table_from_drm+0x99/0x140 [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel: Modules linked in: udp_diag tcp_diag 
inet_diag rpcsec_gss_krb5 nfsv4 nfs lockd grace nls_utf8 cifs cifs_arc4 
cifs_md4 dns_resolver fscache netfs ctr ccm rfcomm snd_seq_dummy snd_hrtimer 
snd_seq q>
Mär 16 11:23:42 badwlrz-cl99868 kernel:  snd_rn_pci_acp3x ucsi_acpi 
snd_acp_config snd_soc_acpi watchdog ccp typec_ucsi snd_timer snd_pci_acp3x 
roles snd rng_core soundcore typec rfkill ac joydev acpi_cpufreq serio_raw 
evdev hid_multit>
Mär 16 11:23:42 badwlrz-cl99868 kernel: CPU: 3 PID: 31810 Comm: kworker/u32:9 
Tainted: GW  6.1.0-6-amd64 #1  Debian 6.1.15-1
Mär 16 11:23:42 badwlrz-cl99868 kernel: Hardware name: LENOVO 
20XGS0N400/20XGS0N400, BIOS R1NET54W (1.24) 10/27/2022
Mär 16 11:23:42 badwlrz-cl99868 kernel: Workqueue: amdgpu_dm_hpd_rx_offloa 
dm_handle_hpd_rx_offload_work [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel: RIP: 
0010:fill_dc_mst_payload_table_from_drm+0x99/0x140 [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel: Code: c1 eb 0b 83 c2 01 48 83 c1 18 39 
d6 74 1c 40 38 39 75 f0 0f b7 3d 7f 93 53 00 48 63 ca 48 8d 0c 49 66 89 7c cc 
28 39 d6 75 22 <0f> 0b eb 1e 0f b7 5a 0c 0f b7 05 60 93 53 00 48 8d 0c 76 8a 4>
Mär 16 11:23:42 badwlrz-cl99868 kernel: RSP: 0018:b1f74ce73cb0 EFLAGS: 
00010246
Mär 16 11:23:42 badwlrz-cl99868 kernel: RAX: b1f74ce73cd8 RBX: 
 RCX: 
Mär 16 11:23:42 badwlrz-cl99868 kernel: RDX:  RSI: 
 RDI: b1f74ce73d58
Mär 16 11:23:42 badwlrz-cl99868 kernel: RBP: 8d1a5d3aa000 R08: 
b1f74ce73de4 R09: 
Mär 16 11:23:42 badwlrz-cl99868 kernel: R10: 0002 R11: 
0001 R12: b1f74ce73de4
Mär 16 11:23:42 badwlrz-cl99868 kernel: R13: 8d19f39bf340 R14: 
8d19c3786540 R15: 8d1a0147cba0
Mär 16 11:23:42 badwlrz-cl99868 kernel: FS:  () 
GS:8d1c9ecc() knlGS:
Mär 16 11:23:42 badwlrz-cl99868 kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Mär 16 11:23:42 badwlrz-cl99868 kernel: CR2: 559d90824354 CR3: 
4b21 CR4: 00750ee0
Mär 16 11:23:42 badwlrz-cl99868 kernel: PKRU: 5554
Mär 16 11:23:42 badwlrz-cl99868 kernel: Call Trace:
Mär 16 11:23:42 badwlrz-cl99868 kernel:  
Mär 16 11:23:42 badwlrz-cl99868 kernel:  
dm_helpers_dp_mst_write_payload_allocation_table+0x79/0xa0 [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel:  core_link_disable_stream+0x2d0/0x540 
[amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel:  
dc_link_dp_handle_link_loss+0x12e/0x160 [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel:  
dm_handle_hpd_rx_offload_work+0x12b/0x160 [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel:  process_one_work+0x1c7/0x380
Mär 16 11:23:42 badwlrz-cl99868 kernel:  worker_thread+0x4d/0x380
Mär 16 11:23:42 badwlrz-cl99868 kernel:  ? rescuer_thread+0x3a0/0x3a0
Mär 16 11:23:42 badwlrz-cl99868 kernel:  kthread+0xe9/0x110
Mär 16 11:23:42 badwlrz-cl99868 kernel:  ? kthread_complete_and_exit+0x20/0x20
Mär 16 11:23:42 badwlrz-cl99868 kernel:  ret_from_fork+0x22/0x30
Mär 16 11:23:42 badwlrz-cl99868 kernel:  
Mär 16 11:23:42 badwlrz-cl99868 kernel: ---[ end trace  ]---

-- Package-specific info:
** Version:
Linux version 6.1.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.15-1 (2023-03-05)

** Command line:

Bug#1033006: unblock: openvpn/2.6.1-1 (preapproval)

[Bernhard Schmidt]

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

Please give permission to upload OpenVPN 2.6.1-1 to unstable and let
it migrate to testing (currently in experimental as 2.6.1-1~exp1

[ Reason ]
Upstream has released the first minor release in the 2.6.x series. 
It is primarily a bugfix release but has one new security feature.

https://github.com/OpenVPN/openvpn/blob/v2.6.1/Changes.rst

| Dynamic TLS Crypt When both peers are OpenVPN 2.6.1+, OpenVPN will dynamically
| create a tls-crypt key that is used for renegotiation. This ensure that only
| the previously authenticated peer can do trigger renegotiation and complete
| renegotiations.

I am afraid that this might be CVE material down the road and would
be more invasive to backport during a stable release than adding it now.

There is another release slated for next week that will overhaul the
kernel interface to the optional DCO (data channel offload) kernel
module. I have asked upstream to make 2.6.2 as small as possible
compared to 2.6.1, so we can review 2.6.2 and the new DCO module 
in time.

There have been no changes in the debian/ packaging

[ Impact ]
Missing out on this release would make us miss all the small bugfixes and
make reviewing the DCO change a lot harder.

[ Tests ]
Upstream has a very thorough patch review process and CI pipeline
2.6.1-1~exp1 (but compiled on bullseye) has been running on my employers
eduVPN server serving thousands of university students.

[ Risks ]
The code change is not trivial but managable

https://github.com/OpenVPN/openvpn/compare/v2.6.0...v2.6.1

about half of the changes affect only Windows or FreeBSD

I'm not smart enough to understand anything about the one
new feature, but it has been extensively documented and
tested by upstream

https://github.com/OpenVPN/openvpn/commit/202a934fc32673ef865b5cbcb23ad6057ceb2e0b

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

I've omitted the debdiff because there have not been any changes
apart from the new upstream version, which is a lot more readable
as a list of commits on github than with a plain debdiff

If you want me to attach a debdiff feel free to tell me.

[ Other info ]
The upcoming DCO change will involve a new version of src:openvpn and a new 
version
of src:openvpn-dco-dkms. The list of changes on the kernel side is already 
visible
on https://github.com/OpenVPN/ovpn-dco/commits/master .

In the past we managed to break DCO on above mentioned really heavily loaded
OpenVPN server within a few hours. The new version is a major overhaul and more
in-line with code upstreamable in Linux, and did survive torture tests.

I know this is kind of late, but I think it would be better to include it as 
well
as soon as it is released because

- we cannot support the old deprecated module
- openvpn uses DCO (of the right version) automatically and will transparently
  fall-back to non-DCO mode if the module is not found (or the wrong version)
- it has not been in Bullseye previously, so if we see that DCO is too unstable
  with the new version we can just drop it before the release

unblock openvpn/2.6.1-1

Bug#1032590: Intermediate certficate support

[Bernhard Schmidt]

Am 13.03.23 um 16:29 schrieb Sakirnth Nagarasa:

Hi,


On 3/13/23 15:02, Bernhard Schmidt wrote:

Humm .. but there IS a change fixing intermediate CA support in 3.2.2...

Yes the intermediate CA support works now on version 3.2.2. I tested
that in my setup.


So, if I understand you correctly:

- The LDAP TLS error was caused by a local change (libldap built against 
OpenSSL instead of GnuTLS)

- Intermediate CA support works for you in 3.2.2-1~exp1
- but not in 3.2.1-3 where I have backported the commit?

Sorry to be asking again, but I need to know quite soon whether to file 
an unblock request for -3, revert the backported fix because it does not 
do any good, or ask for a pre-approval for 3.2.2.


Thanks,
Bernhard

Bug#1032590: Intermediate certficate support

[Bernhard Schmidt]

Am 13.03.23 um 14:48 schrieb Sakirnth Nagarasa:

Hi,


On 3/11/23 22:01, Bernhard Schmidt wrote:

Just to make sure, could you quickly verify which of these versions are
broken as well in your setup?

- 3.2.1-1 from testing
- 3.2.1-2 from
http://snapshot.debian.org/package/freeradius/3.2.1%2Bdfsg-2/
- 3.2.2-1~exp1 from experimental (just uploaded, might take a few hours
to appear in the archive)

It doesen't work for all listed versions in my setup. But in my company
the libldap package is built against OpenSSL instead of GnuTLS. And on
Saturday I installed the Debian version of freeradius-ldap built against
libldap linked to GnuTLS. Therefore it didn't work. After I built
freeradius-ldap version 3.2.2-1~exp1 against libldap linked to the
OpenSSL it worked. So on Saturday I didn't test the same setup, like before.

Therefore everything works, it was my mistake. Thank you very much for
uploading the new version.


Humm .. but there IS a change fixing intermediate CA support in 3.2.2...

@Daniel: Do you have a chance to test this, since you reported it in 
#1032572?


Bernhard

Bug#1032590: Intermediate certficate support

[Bernhard Schmidt]

Am 11.03.23 um 14:51 schrieb Sakirnth Nagarasa:

Hi,


On 3/10/23 08:55, Bernhard Schmidt wrote:

I will upload a 3.2.1-3 within the next hours to cherry-pick this, could
you please test the resulting binary and report back? I will then apply
for a freeze exception.


Thank you for uploading the new version. I quickly tested the new binary
in our setup, Freeradius can not bind to ldap server anymore with
version 3.2.1-3.


Meh :-(


TLS: can't connect: (unknown error code).
Sat Mar 11 14:28:38 2023 : Error: rlm_ldap (ldap): Bind with (anonymous)
to ldaps://${LDAP_SERVER}:636 failed: Can't contact LDAP server
Sat Mar 11 14:28:38 2023 : Debug: rlm_ldap: Closing libldap handle


TLS issue, sounds related to my cherry-picked patch.

Unfortunately there are a lot of patches between 3.2.1 and 3.2.2, and 
the commit message aren't always as descriptive as they could be.


https://github.com/FreeRADIUS/freeradius-server/compare/release_3_2_1...release_3_2_2

https://github.com/FreeRADIUS/freeradius-server/commit/d23987cbf55821dc56ab70d5ce6af3305cf83289
https://github.com/FreeRADIUS/freeradius-server/commit/3d08027f30c6d9c1eaccf7d60c68c8f7d78017c3

are likely candidates.

Just to make sure, could you quickly verify which of these versions are 
broken as well in your setup?


- 3.2.1-1 from testing
- 3.2.1-2 from http://snapshot.debian.org/package/freeradius/3.2.1%2Bdfsg-2/
- 3.2.2-1~exp1 from experimental (just uploaded, might take a few hours 
to appear in the archive)


Bernhard

Bug#1032572: new upstream (3.2.2)

[Bernhard Schmidt]

On 09/03/23 11:09 AM, Daniel Baumann wrote:

Hi Daniel,

> the latest upstream release (3.2.2) fixes some important bugs for us,
> e.g. the fact that using an intermediate CA for which EAP-TLS, upstream
> writes:
> 
>   "It's also worth mentioning that FreeRADIUS 3.2.1 has an issue with
>partial chains.  E.g. if you have
> 
>Root CA -> Intermediate CA -> Client Cert
> 
>and you want to put just Intermediate CA in the ca_file as that is
>what you want to trust rather than the root CA, then that does not
>work correctly on 3.2.1."
> 
> Given the freeze, it would be very helpful if you could upload 3.2.2 to
> experimental, this would ease the local backporting on our end
> tremendously since we need 3.2.2

I can do so later, but I would prefer to fix these bugs in bookworm,
where uploading a whole new upstream version is not accepted at this
point in the release preparation
(https://release.debian.org/testing/freeze_policy.html).

Interestingly someone else has reported the partial CA problem a few
hours after your report, and provided a link to the issue/commit fixing
this. See Bug#1032590

I have just uploaded 3.2.1-3 to the archive, it should be built in the
next hours. Could you test the resulting package and report back?

Bernhard


signature.asc
Description: PGP signature

Bug#1032590: Intermediate certficate support

[Bernhard Schmidt]

Control: forwarded -1 
https://github.com/FreeRADIUS/freeradius-server/issues/4753
Control: priority -1 important
Control: found -1 3.0.25+dfsg-1

On 09/03/23 05:29 PM, Sakirnth Nagarasa wrote:

Hi,

> It would be great if you could upgrade freeradius version 3.2.2 to
> Debian. With that certficates chains can be used without failing.
> 
> It patches this bug:
> https://github.com/FreeRADIUS/freeradius-server/issues/4753

Thanks for the report. Unfortunately we are in Freeze already, so just
uploading 3.2.2 is not easily possible.

https://release.debian.org/testing/freeze_policy.html

However, I can backport patches. According to the GH issue you provided
the bug was introduced in 3.0.22 and fixed with 

https://github.com/FreeRADIUS/freeradius-server/commit/aa5b642a3d6fed8663e5242d91884d25d14e9f53

I will upload a 3.2.1-3 within the next hours to cherry-pick this, could
you please test the resulting binary and report back? I will then apply
for a freeze exception.

Bernhard


signature.asc
Description: PGP signature

Bug#919234: ttls fails with tls 1.3, enabled by default

[Bernhard Schmidt]

Control: tags -1 + pending

Hi Fabio,

Am 07.03.23 um 17:00 schrieb Fabio PEDRETTI:

Hi, 3.2.1 currently in testing fixed most issues, however there is
still an issue preventing freeradius working with TLS 1.3.

The issue was reported upstream at:
https://github.com/FreeRADIUS/freeradius-server/issues/4878
and the commit fixing it is:
https://github.com/FreeRADIUS/freeradius-server/commit/0812bc1768cedc420adc03e86893d798fa19e872

That commit is already included in upstream 3.2.2.

So please consider upgrading to 3.2.2 (suggested, given this release
also fixes some other bugs), or apply the mentioned commit.

I updated the severity and forwarded bug reflecting this.


Thanks a lot for the investigation.

I have just uploaded 3.2.1-2 to the archive, could you please test this 
version? Importing the new 3.2.2 upstream version at this stage of the 
release freeze is not possible, see 
https://release.debian.org/testing/freeze_policy.html .


Bernhard

Bug#1029205: openvpn: Backporting openvpn 2.6.0~rc1 to bullseye-backports breaks network-manager-openvpn connections to older servers

[Bernhard Schmidt]

Am 19.01.23 um 16:47 schrieb René Krell:

Hi Rene,


IMHO, in each case it is not a idea to backport openvpn 2.6 unless 
network-manager-openvpn supports to override also --data-ciphers.


Packages are not upgraded to backports-versions by default. You have to 
opt-in (either manually or by adjusting pin-priorities in 
apt-preferences) to upgrade to 2.6.


Since the version of network-manager-openvpn in bullseye even works with 
the backported openvpn for the majority of not-outdated configurations 
there is nothing to be fixed here.


Unless you have another convincing argument I intend to close this bug 
in a couple of days.


Bernhard

Bug#1011538: RM: bind9-libs -- ROM; end-of-life, not needed anymore for isc-dhcp

[Bernhard Schmidt]

Control: affects -1 src:bind9-libs

Hi,

> src:isc-dhcp has switched to bundled libraries in #942502, so this package can
> finally be removed.
> 
> The only unsolved thing is #942501 in orphaned milter-greylist, so I bumped 
> the
> severity to serious.  I can do the NMU, but the package is orphaned and has
> other problems (links with obsoleted libgeoip), so it might be just better to
> remove it as well.

Reopening this because the previous attempt did not remove
src:bind9-libs as intended, but the bind9-libs binary package built from
src:bind9 . Yes, I know this is confusing.

Please remove src:bind9-libs including all binaries

libbind-dev
libbind-export-dev
libbind9-161
libdns-export1110
libdns-export1110-udeb
libdns1110
libirs-export161
libirs-export161-udeb
libirs161
libisc-export1105
libisc-export1105-udeb
libisc1105
libisccc-export161
libisccc-export161-udeb
libisccc161
libisccfg-export163
libisccfg-export163-udeb
libisccfg163
liblwres161

from unstable. 

Bernhard

Bug#1011437: Should bind9-libs be shipped in bookworm?

[Bernhard Schmidt]

Hi,

not about src:bind9, building the bind9-libs binary package (yes, this 
is totally confusing, even to Debian tooling)


I though that had been already removed: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011538 



But I guess something went wrong and perhaps **just** binary bind9-libs 
was removed instead.


Eheehe, this explains 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018016


Unless you beat me to it, I'll give it another RM stab.

Bernhard

Bug#1011437: Should bind9-libs be shipped in bookworm?

[Bernhard Schmidt]

Am 09.01.23 um 14:30 schrieb Ondřej Surý:

Hi Ondrej,


Looking at #942501 and #942502, the intention seems to be to not
ship bind9-libs in bookworm.


I agree, Ccing Ondrej who has done the heavy lifting on this package.

AFAICT there is no binary reverse dependency in unstable, and #942501
"just" needs a NMU for the removed build-dep.

Ondrej, what do you think?


No, not really. The bind9-libs package contains shared libraries for

bind9, bind9-dnsutils, bind9-host and bind9-utils package.

We could drop bind9-dev, but that was required by the bind9-dyndb-ldap
plugin - that's the thing that might be useful to solve, but then again, 
RedHat

chose GPL for the project, so there's little we can do in both upstream and
downstream - we certainly don't want to re-licence whole BIND 9 to GPL
because of the bundled plugin. I would rather keep them separate even
if it's painful.


Hum, either I got something totally wrong or we are talking about 
different things.


This thread is about src:bind9-libs, still on the 9.11 code train and 
building


libbind-dev
libbind-export-dev
libbind9-161
libdns-export1110
libdns-export1110-udeb
libdns1110
libirs-export161
libirs-export161-udeb
libirs161
libisc-export1105
libisc-export1105-udeb
libisc1105
libisccc-export161
libisccc-export161-udeb
libisccc161
libisccfg-export163
libisccfg-export163-udeb
libisccfg163
liblwres161

not about src:bind9, building the bind9-libs binary package (yes, this 
is totally confusing, even to Debian tooling)


Bernhard

Bug#1011437: Should bind9-libs be shipped in bookworm?

[Bernhard Schmidt]

On 22/05/22 11:47 PM, Adrian Bunk wrote:

> Looking at #942501 and #942502, the intention seems to be to not
> ship bind9-libs in bookworm.

I agree, Ccing Ondrej who has done the heavy lifting on this package.

AFAICT there is no binary reverse dependency in unstable, and #942501
"just" needs a NMU for the removed build-dep.

Ondrej, what do you think?

Bernhard

Bug#1028149: bookworm: ntp has been replaced by ntpsec

[Bernhard Schmidt]

Package: release-notes
Severity: minor

src:ntp (the ntp suite from ntp.org, including ntpd, ntpdate and sntp) has
been dropped from bookworm and superseded by src:ntpsec, the much improved fork
from ntpsec.org . Transitional packages are in place and for 99% of the users
this should have no impact, but it should be mentioned in the release notes.

Bug#1027918: Copy from remote RDP to local KDE Wayland session does not work

[Bernhard Schmidt]

Package: remmina-plugin-rdp
Version: 1.4.27+dfsg-2+b1
Severity: important
Tags: patch upstream

On an Wayland KDE session copy from a remote RDP session to the
local clipboard does not work.

Upstream has an extensive bugreport and already provided a patch for it,
see

https://gitlab.com/Remmina/Remmina/-/issues/2737
https://gitlab.com/Remmina/Remmina/-/commit/9f98daa414cfa0dd8da89f551a713153697d6318

The workaround

GDK_BACKEND=x11 remmina

works, too.

Bernhard

Bug#1027379: nfdump: FTBFS in bullseye (missing build-depends on tzdata)

[Bernhard Schmidt]

Control: tags -1 + pending
Control: tags -1 - moreinfo

Hi,

I have no problem fixing this up in unstable, but I think this does 
not warrant a stable update.


That would be unfortunate, as it means we will probably never have a 
stable release without FTBFS bugs.


"Never" is too hard, I will fix it in unstable targetting bookworm, so 
the next release should have it.


Since backporting those kind of bugs is completely trivial, I'm still 
aiming at having a stable distribution which is free from FTBFS bugs (of 
any kind). You are of course free not to help me in my goal, but it would
help immensely if every maintainer ensured that their own packages are 
free from FTBFS bugs in stable.


I somehow have my doubt that the release-team would be happy to have a 
lot of stable updates fixing just a FTBFS that does not happen with the 
default buildd configuration. I totally agree about the severity of 
other FTBFS bugs in stable.


Bernhard

Bug#1027379: nfdump: FTBFS in bullseye (missing build-depends on tzdata)

[Bernhard Schmidt]

Hi,

That's an odd one. I cannot reproduce it in any version, because in 
all my attempts (1.6.22-2 in a bullseye sbuild, in an sid sbuild, as 
well as in the build logs of the official buildds for all of 1.6.22-2, 
1.6.25-1 and 1.7.1-1) tzdata is actually installed in the build 
environment, even without additional build-dep.


tzdata is not really build essential, you should not install it in a 
chroot used to build packages from scratch. It follows from this that if 
you want to be sure that you don't miss build-dependencies, you should 
not accept debootstrap defaults when creating a chroot, as it installs

several packages which are not build-essential.

To reproduce, try building the package in a chroot which does not 
contain tzdata.


Both the official buildds and schroots created using the documented 
sbuild-createchroot then apparently do not follow recommended procedure?


I have no problem fixing this up in unstable, but I think this does not 
warrant a stable update.


BTW, it is reproducible using "sbuild --add-conflicts=tzdata"

Bernhard

Bug#1027379: nfdump: FTBFS in bullseye (missing build-depends on tzdata)

[Bernhard Schmidt]

Control: tags -1 + moreinfo

Hi Santiago,


During a rebuild of all packages in bullseye, your package failed to build:


[...]


Note: I'm using the "patch" tag because there is an obvious fix > (indicated in 
the subject).


That's an odd one. I cannot reproduce it in any version, because in all 
my attempts (1.6.22-2 in a bullseye sbuild, in an sid sbuild, as well as 
in the build logs of the official buildds for all of 1.6.22-2, 1.6.25-1 
and 1.7.1-1) tzdata is actually installed in the build environment, even 
without additional build-dep.


Bernhard

Bug#1011473: 2.5 clients cannot connect to a 2.6 server

[Bernhard Schmidt]

On 25/05/22 04:20 PM, Wolfgang Walter wrote:

Hi Wolfgang,

> opt-verify
> 
> on the server side allows 2.5.6 clients to connect again. So it seems that
> 2.5 and 2.6 disagree on tun-mtu (as the warning is not logged if both sides
> are either 2.5.6 or 2.6).

Could you try again with the just uploaded 2.6.0~rc1? There has been
quite some work in the last months to make the mtu calculation
better.

Bernhard

Bug#1027094: FTBFS against bind9 9.18.10

[Bernhard Schmidt]

Control: forwarded -1 https://pagure.io/bind-dyndb-ldap/issue/216

On 27/12/22 06:16 PM, Bernhard Schmidt wrote:

Hi,

so this is really massively broken :-(


> ../../src/log.h:21:9: error: too few arguments to function ‘isc_error_fatal’
>21 | isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__)
>   | ^~~

That one has been introduced in 9.18.9+. There is an open pull request
upstream at https://pagure.io/bind-dyndb-ldap/pull-request/215 , which
(together with bumping LIBDNS_VERSION_MAJOR in
d/p/hardcode-version.diff) fixes the logging errors.

> ../../src/ldap_driver.c: In function ‘allrdatasets’:
> ../../src/ldap_driver.c:474:71: error: passing argument 5 of 
> ‘dns_db_allrdatasets’ makes integer from pointer without a cast 
> [-Werror=int-conversion]
>   474 | return dns_db_allrdatasets(ldapdb->rbtdb, node, version, now, 
> iteratorp);
>   |   
> ^
>   |   
> |
>   |   
> dns_rdatasetiter_t ** {aka struct dns_rdatasetiter **}

Those appear to be new issues in 9.18.10. I have filed a new upstream
bugreport at https://pagure.io/bind-dyndb-ldap/issue/216 . Both
dns_db_allrdatasets and dns_zt_apply gained an additional argument

https://gitlab.isc.org/isc-projects/bind9/-/commit/1de9c052107a6f24e565441f53e4d8b33bb2e30a
https://gitlab.isc.org/isc-projects/bind9/-/commit/6f998bbe518ae629685404bcfddcfd6067176660

and while my attempts to monkeypatch the additional 0 argument into
dns_db_allrdatasets cleared most of the warnings I'm lost with the
remaining errors. Does not really help that I barely know C, my
knowledge ends pretty much here and I have no idea how to go further.

In file included from ../../src/zone_register.h:8,
 from ../../src/ldap_convert.c:28:
/usr/include/dns/zt.h:171:28: error: unknown type name ‘isc_rwlocktype_t’; did 
you mean ‘isc_rwlock_t’?
  171 | dns_zt_apply(dns_zt_t *zt, isc_rwlocktype_t lock, bool stop, 
isc_result_t *sub,
  |^~~~
  |isc_rwlock_t


libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Wextra -Werror -std=gnu99 -O2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-uninitialized -fvisibility=hidden 
-fno-delete-null-pointer-checks -std=gnu11 -c ../../src/ldap_helper.c  -fPIC 
-DPIC -o .libs/ldap_la-ldap_helper.o
../../src/ldap_driver.c:950:9: error: initialization of ‘isc_result_t 
(*)(dns_db_t *, dns_dbnode_t *, dns_dbversion_t *, unsigned int,  
isc_stdtime_t,  dns_rdatasetiter_t **)’ {aka ‘enum isc_result (*)(struct dns_db 
*, void *, void *, unsigned int,  unsigned int,  struct dns_rdatasetiter **)’} 
from incompatible pointer type ‘isc_result_t (*)(dns_db_t *, dns_dbnode_t *, 
dns_dbversion_t *, isc_stdtime_t,  dns_rdatasetiter_t **)’ {aka ‘enum 
isc_result (*)(struct dns_db *, void *, void *, unsigned int,  struct 
dns_rdatasetiter **)’} [-Werror=incompatible-pointer-types]
  950 | allrdatasets,
  | ^~~~
../../src/ldap_driver.c:950:9: note: (near initialization for 
‘ldapdb_methods.allrdatasets’)

Bug#1027094: FTBFS against bind9 9.18.10

[Bernhard Schmidt]

On 27/12/22 09:43 PM, Santiago Vila wrote:

> > bind-dyndb-ldap has a tight dependency on the upstream version of bind9-libs
> > (built by src:bind9) and needs to be rebuilt on every new upstream version
> > until https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 is fixed.
> 
> Hello. I suppose this is the reason it does not build in stable either.
> 
> Should we use the "found" directive with this bug,
> or it is better to file it as a separate bug?

I suspect this is a different bug (possibly for the same reason, changed
API within a stable release of bind9, but since the breaking code is
very fresh I doubt the same thing affects stable). So better file a new
one.

Bernhard

Bug#1027094: FTBFS against bind9 9.18.10

[Bernhard Schmidt]

Source: bind-dyndb-ldap
Version: 11.10-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: team+...@tracker.debian.org

bind-dyndb-ldap has a tight dependency on the upstream version of bind9-libs
(built by src:bind9) and needs to be rebuilt on every new upstream version
until https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 is fixed.

This worked fine until bind9 9.18.8, but fails in 9.18.10

https://buildd.debian.org/status/fetch.php?pkg=bind-dyndb-ldap=amd64=11.10-1%2Bb5=1671812545=0

This is rather serious as it prevents the migration of 9.18.10 to testing
which includes systemd notify support and upstream bugfixes. Also bind9 has
followed upstream security releases during bullseye already, so it will
break later if 9.18.10 misses the freeze due to this issue.

Possible commits:
https://gitlab.isc.org/isc-projects/bind9/-/compare/v9_18_8...v9_18_10?from_project_id=1

In file included from ../../src/zone_register.h:8,
 from ../../src/ldap_convert.c:28:
/usr/include/dns/zt.h:171:28: error: unknown type name ‘isc_rwlocktype_t’; did 
you mean ‘isc_rwlock_t’?
  171 | dns_zt_apply(dns_zt_t *zt, isc_rwlocktype_t lock, bool stop, 
isc_result_t *sub,
  |^~~~
  |isc_rwlock_t
make[3]: *** [Makefile:592: ldap_la-ldap_convert.lo] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from ../../src/util.h:17,
 from ../../src/bindcfg.h:10,
 from ../../src/ldap_driver.c:39:
../../src/ldap_driver.c: In function ‘beginload’:
../../src/log.h:21:9: error: too few arguments to function ‘isc_error_fatal’
   21 | isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__)
  | ^~~
../../src/ldap_driver.c:220:9: note: in expansion of macro ‘fatal_error’
  220 | fatal_error("ldapdb: method beginload() should never be 
called");
  | ^~~
In file included from /usr/include/isc/util.h:312,
 from /usr/include/isc/atomic.h:22,
 from /usr/include/isc/refcount.h:19,
 from ../../src/ldap_driver.c:16:
/usr/include/isc/error.h:42:1: note: declared here
   42 | isc_error_fatal(const char *, int, const char *, const char *, ...)
  | ^~~
../../src/ldap_driver.c: In function ‘endload’:
../../src/log.h:21:9: error: too few arguments to function ‘isc_error_fatal’
   21 | isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__)
  | ^~~
../../src/ldap_driver.c:237:9: note: in expansion of macro ‘fatal_error’
  237 | fatal_error("ldapdb: method endload() should never be called");
  | ^~~
/usr/include/isc/error.h:42:1: note: declared here
   42 | isc_error_fatal(const char *, int, const char *, const char *, ...)
  | ^~~
../../src/ldap_driver.c: In function ‘dump’:
../../src/log.h:21:9: error: too few arguments to function ‘isc_error_fatal’
   21 | isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__)
  | ^~~
../../src/ldap_driver.c:266:9: note: in expansion of macro ‘fatal_error’
  266 | fatal_error("ldapdb: method dump() should never be called");
  | ^~~
/usr/include/isc/error.h:42:1: note: declared here
   42 | isc_error_fatal(const char *, int, const char *, const char *, ...)
  | ^~~
../../src/ldap_driver.c: In function ‘allrdatasets’:
../../src/ldap_driver.c:474:71: error: passing argument 5 of 
‘dns_db_allrdatasets’ makes integer from pointer without a cast 
[-Werror=int-conversion]
  474 | return dns_db_allrdatasets(ldapdb->rbtdb, node, version, now, 
iteratorp);
  |   
^
  |   |
  |   
dns_rdatasetiter_t ** {aka struct dns_rdatasetiter **}
In file included from ../../src/ldap_driver.c:22:
/usr/include/dns/db.h:1162:57: note: expected ‘isc_stdtime_t’ {aka ‘unsigned 
int’} but argument is of type ‘dns_rdatasetiter_t **’ {aka ‘struct 
dns_rdatasetiter **’}
 1162 | unsigned int options, isc_stdtime_t now,
  |   ~~^~~
../../src/ldap_driver.c:474:16: error: too few arguments to function 
‘dns_db_allrdatasets’
  474 | return dns_db_allrdatasets(ldapdb->rbtdb, node, version, now, 
iteratorp);
  |^~~
/usr/include/dns/db.h:1161:1: note: declared here
 1161 | dns_db_allrdatasets(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t 
*version,
  | ^~~
../../src/ldap_driver.c: In function ‘node_isempty’:
../../src/ldap_driver.c:517:62: error: passing argument 5 of 
‘dns_db_allrdatasets’ makes integer from pointer without a 

Bug#994235: bind9-dnsutils: Exiting the nslookup tool with ^C causes termainl echo to disappear until reset command is run

[Bernhard Schmidt]

Control: tags -1 + confirmed upstream

On 14/09/21 06:19 PM, Gavin Rogers wrote:
> 
> After upgrading from Debian 10 to 11, the nslookup command misbehaves
> if it is exited with ^C rather than using the exit command, causing
> local echo to appear to be switched off. Running /usr/bin/reset
> restores the terminal.

Still present in 9.18, could you please file an upstream issue at
https://gitlab.isc.org/isc-projects/bind9 ?

Bernhard

Bug#861923: openvpn: arbitrary process limit

[Bernhard Schmidt]

On 10/10/17 04:02 PM, Bernhard Schmidt wrote:

> I think what we actually want is
> 
>TasksMax=N
>Specify the maximum number of tasks that may be created in the
>unit. This ensures that the number of tasks accounted for the
>unit (see above) stays below a specific limit. This either
>takes an absolute number of tasks or a percentage value that is
>taken relative to the configured maximum number of tasks on the
>system. If assigned the special value "infinity", no tasks
>limit is applied. This controls the "pids.max" control group
>attribute. For details about this control group attribute, see
>pids.txt[6].
> 
>Implies "TasksAccounting=true". The system default for this
>setting may be controlled with DefaultTasksMax= in systemd-
>system.conf(5).

I've decided to jump and uploaded this change for the Debian native
openvpn@.service with 2.6.0~git20221222-1 . I think this so much better
fits the actual threat model, and since this is supposed to be a real
limit per instance thing we should safely be able to revert back to the
original limit of 10 processes.

I plan to have this tested in the native debian unit first, and then
approach upstream again or patch the upstream units or revert the
change, depending on the outcome.

https://salsa.debian.org/debian/openvpn/-/commit/9be1339d15aec767796dd5d524f14e4be7b01aa7

Bernhard

Bug#1026903: nmu: bind-dyndb-ldap_11.10-1

[Bernhard Schmidt]

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

Hi,

while Bug#1014503 is not fixed we need another binNMU of bind-dyndb-ldap
against the new version of bind9 in unstable. This should be the last
time before the release.

nmu bind-dyndb-ldap_11.10-1 . ANY . unstable . -m "Rebuild for 
bind9/1:9.18.10-2"

Thanks,
Bernhard

Bug#1024846: Does not start because it cannot create the control socket

[Bernhard Schmidt]

Package: openbgpd
Version: 7.7-1
Severity: normal

Hi Marco,

I'm filing this as severity normal because I stumbled across it on a
local bullseye backport, and I haven't tested it on sid yet. But I think
it should be affected as well.

After upgrading from 7.2 to 7.7 openbgpd does not start anymore.

Nov 26 17:56:51 dns-test bgpd[256654]: PF_KEY not available, disabling ipsec
Nov 26 17:56:51 dns-test bgpd[256654]: control_init: unlink /run/bgpd.sock.0: 
Read-only file system
Nov 26 17:56:51 dns-test bgpd[256654]: fatal in bgpd: control socket setup 
failed

The systemd unit was changed from

ProtectSystem=full

to

ProtectSystem=strict
RuntimeDirectory=openbgpd

A writeable /run/openbgpd is created, but not used in the default
configuration, which creates the socket directly in /run

Adding an override

ReadWritePaths=/run

fixes the issue, but this opens a few more holes. So I think the default
location for the control socket should rather be moved to /run/openbgpd,
possibly by setting --runstatedir and/or --with-runstatedir accordingly.

Bernhard

Bug#1024845: transition: linphone-stack

[Bernhard Schmidt]

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

Dear release team,

once again, hopefully for the last time before the release, I'm asking for
permission for a small mostly self-contained transition of the whole linphone
stack. It has been staged in experimental.

Most of these libraries don't change SONAME (except for ortp, mediastreamer2)
but upstream only supports staying within the same minor version. So there is a
(>= | < ) dependency generated with shlibs and the stack will have to migrate
in one go.

bctoolbox 5.0.37-2 -> 5.1.64-1
belr 5.0.37-2 -> 5.1.64-1
bzrtp 5.0.37-2 -> 5.1.64-1
lime 5.0.37+dfsg-5 -> 5.1.64+dfsg-1
bcmatroska2 5.0.37-2 -> 5.1.20-1
ortp 1:5.0.37-2 -> 1:5.1.64-1
belcard 5.0.37-2 -> 5.1.64-1
belle-sip 5.0.37+dfsg-3 -> 5.1.64+dfsg-1
mediastreamer2  1:5.0.37+dfsg-4 -> 1:5.1.64+dfsg-1
linphone 5.0.37-6 -> 5.1.65-1
linphone-desktop 4.3.2-2 -> 4.4.10-1

only ortp has reverse dependencies outside of the linphone stack that will need
a binNMU.

libosmo-abis
trx

All other packages listed in the transition belong to the linphone stack and
will be uploaded by me.

https://release.debian.org/transitions/html/auto-ortp.html

Bernhard

Bug#994696: Bind9's systemd .service says named available before it actually is, which makes services which depend on it fail

[Bernhard Schmidt]

Control: reopen -1 =
Control: fixed -1 1:9.19.6-2

Reopening because we don't have that fix in unstable yet (needs to be 
backported)

Bug#1023594: nmu: bind-dyndb-ldap_11.10-1

[Bernhard Schmidt]

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

Hi,

while Bug#1014503 is not fixed we need another binNMU of bind-dyndb-ldap
against the new version of bind9 in unstable.

nmu bind-dyndb-ldap_11.10-1 . ANY . unstable . -m "Rebuild for 
bind9/1:9.18.8-1"


Thanks,
Bernhard

Bug#1021125: Bug#1021576: linphone-desktop: Core dumped: Program terminated with signal SIGABRT, Aborted.

[Bernhard Schmidt]

Hi,

I think this Bug can be downgraded and/or closed.

We've rebuilt both dependencies in Debian (liblime and linphone). Since 
soci is not using shlibs the generated dependency is on the 4.0.3 anyway.


I don't see a way to fix this without breaking lime/linphone again.

Bernhard

Bug#994696: Bind9's systemd .service says named available before it actually is, which makes services which depend on it fail

[Bernhard Schmidt]

Am 29.10.22 um 10:44 schrieb Bernhard Schmidt:

Hi Ondrej,


I think it would be best if someone has finished the upstream systemd
support. I am currently busy with other more important stuff, but if 
there

was a working MR I would be happy to do the review and also do the
backport to 9.18. The change is isolated, so it won't create any fuzz.


The code has been merged in 9.19.6. Do you think we could backport it, 
either upstream in the next release or in 9.18.8 for Debian?


I'll look at enabling this in the experimental branch.


Appears to work fine, I've pushed a commit enabling sd_notify to the 
debian/9.19 branch and it looks good, readyness is properly signaled and 
autopkgtest works even without the sleep 1


https://salsa.debian.org/dns-team/bind9/-/commit/5a6ee84642d91cdb721a04be11beb28621dd8e1f

Bernhard

Bug#994696: Bind9's systemd .service says named available before it actually is, which makes services which depend on it fail

[Bernhard Schmidt]

Hi Ondrej,


I think it would be best if someone has finished the upstream systemd
support. I am currently busy with other more important stuff, but if there
was a working MR I would be happy to do the review and also do the
backport to 9.18. The change is isolated, so it won't create any fuzz.


The code has been merged in 9.19.6. Do you think we could backport it, 
either upstream in the next release or in 9.18.8 for Debian?


I'll look at enabling this in the experimental branch.

Bernhard

Bug#1019233: conserver FTBFS on IPV6-only buildds

[Bernhard Schmidt]

After some thoughts on it I've decided to make the test-suite non-fatal
in the pending 8.2.7-2 upload. 

The root cause of the test-suite error appears to be that conserver is
using AI_ADDRCONFIG, and fails to resolve localhost to 127.0.0.1 on
machines that do not have non-local IPv4 connectivity.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952740
https://lists.debian.org/debian-devel/2022/02/msg00070.html

I have briefly tried to make the test-suite cope with both situations,
but was not successful. I don't want to make any code changes breaking
some real-world application while beating the testsuite into submission,
so for now I'll ignore the failure.

Bug#1021125: Bug#1021576: linphone-desktop: Core dumped: Program terminated with signal SIGABRT, Aborted.

[Bernhard Schmidt]

Am 11.10.22 um 18:19 schrieb Dennis Filder:


The change in 5.0.37-6 was tiny and I doubt it broke something.  But
maybe you're running into #1021125: liblinphone10:amd64 5.0.37-6 is
already linked against soci/4.0.3-1, but liblime0 5.0.37+dfsg-4 is
still linked against soci/4.0.1-5 and there was an ABI break.  You'd
have to downgrade to 5.0.37-5 and soci 4.0.1-5 and wait until either
that bug gets fixed or lime will be rebuilt and reuploaded.


Shall we just do a new upload of liblime0 then?

liblime and linphone are the only reverse dependencies in the archive, 
and linphone has already been rebuilt against the new version/ABI. I 
doubt one can fix the soci ABI bump without breaking linphone again, so 
we could just go forward and rebuild lime.


Bernhard

Bug#1019284: transition: linphone-stack

[Bernhard Schmidt]

Hi,

only ortp has reverse dependencies outside of the linphone stack that will need >> a binNMU. They have been successfully built against the version in 

experimental.


bcg729
trx
libosmo-abis
libosmo-netif
osmo-bts


Please go ahead


All uploaded and built on all release architectures. As far as I can 
see, only libosmo-abis and trx need a binNMU.


Bernhard

Bug#994696: Bind9's systemd .service says named available before it actually is, which makes services which depend on it fail

[Bernhard Schmidt]

On 09/09/22 10:33 AM, Bernhard Schmidt wrote:

> I'm sceptical about this myself. OTOH, I just saw that Ubuntu has done
> this change a year ago
> 
> https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1899902
> https://salsa.debian.org/dns-team/bind9/-/merge_requests/17

Reading closer, we HAD this changed in buster
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900788

But the change was lost during the transition to the 9.16 branch in
bullseye. So I believe we should redo that change ASAP and then migrate
to sd_notify() when it is available.

Bernhard

Bug#994696: Bind9's systemd .service says named available before it actually is, which makes services which depend on it fail

[Bernhard Schmidt]

On 09/09/22 09:52 AM, Ondřej Surý wrote:

Hi,

> I think it would be best if someone has finished the upstream systemd
> support. I am currently busy with other more important stuff, but if there
> was a working MR I would be happy to do the review and also do the
> backport to 9.18. The change is isolated, so it won't create any fuzz.

What is missing? In the MR there is an unresolved thread about sending
STOPPING=1 when doing a normal shutdown. Other than that it's already
done, no?
> 
> I don't think it's such a good idea to remote `-f` option from the unit.

I'm sceptical about this myself. OTOH, I just saw that Ubuntu has done
this change a year ago

https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1899902
https://salsa.debian.org/dns-team/bind9/-/merge_requests/17

Bernhard

Bug#994696: Bind9's systemd .service says named available before it actually is, which makes services which depend on it fail

[Bernhard Schmidt]

On 19/09/21 05:22 PM, Alain Knaff wrote:

> Bind9's systemd service file /lib/systemd/system/named.service marks
> bind service as available before it actually is.
> This allows systemd to proceed with starting other services which depend
> on bind's availability (i.e. with After=nss-lookup.target). These
> services then fail, because bind is not yet actually available at that
> point.

Right now we have 

ExecStart=/usr/sbin/named -f $OPTIONS
Type=simple (implicit)

so we assume the unit is started as soon as the process has been
created.

A simple improvement might be

ExecStart=/usr/sbin/named $OPTIONS
Type=forking

I'm not exactly sure what BIND does before forking, but judging from my
logs a lot of things including configuration check and loading of the
zones are done at this point.

And then there is upstream work by Ondrej (almost, but not quite
completed) in https://gitlab.isc.org/isc-projects/bind9/-/issues/1176 . 
The code in
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5514 looks
easy enough to be backported to 9.18 if ISC does not do it themselves
anyway, then we could use

ExecStart=/usr/sbin/named $OPTIONS
Type=notify

That would probably be the best option forward.

Ondrej, what do you think?

Bernhard

Bug#1019284: transition: linphone-stack

[Bernhard Schmidt]

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

Dear release team,

I'm asking for permission for a small mostly self-contained transition
of the whole linphone stack. It has been staged in experimental.

Most of these libraries don't change SONAME, but upstream only supports staying
within the same minor version. So there is a (>= | < ) dependency generated
with shlibs and the stack will have to migrate in one go.

bctoolbox 4.4.13-4 -> 5.0.37-2
belr 4.4.13-2 -> 5.0.37-1
bzrtp 4.4.13-2 -> 5.0.37-1
lime NEW in unstable
bcmatroska2 NEW in unstable
ortp 1:4.4.13-2 -> 1:5.0.37-1
belcard 4.4.13-2 -> 5.0.37-1
belle-sip 4.4.21+dfsg-2 -> 5.0.37+dfsg-2
mediastreamer2 1:4.4.21 -> 1:5.0.37+dfsg-3
linphone 4.4.21-2 -> 5.0.37-4
linphone-desktop 4.2.5-3 -> 4.3.2-1

only ortp has reverse dependencies outside of the linphone stack that will need
a binNMU. They have been successfully built against the version in experimental.

bcg729
trx
libosmo-abis
libosmo-netif
osmo-bts

Bernhard

Bug#1017148: soci: FTBFS: catch.hpp:6490:33: error: size of array ‘altStackMem’ is not an integral constant-expression

[Bernhard Schmidt]

Control: tags -1 + patch upstream fixed-upstream
Control: forwarded -1 https://github.com/SOCI/soci/pull/886

On 14/08/22 09:18 AM, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > /<>/tests/catch.hpp:6490:33: error: size of array 
> > ‘altStackMem’ is not an integral constant-expression
> >  6490 | static char altStackMem[SIGSTKSZ];
> >   | ^~~~
> > /<>/tests/catch.hpp:6541:45: error: size of array 
> > ‘altStackMem’ is not an integral constant-expression
> >  6541 | char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
> >   | ^~~~

This is likely fixed with a new upstream release

Version 4.0.3 differs from 4.0.2 in the following ways:

Changes affecting all or multiple backends:
 - Fix opening sessions from pool (#891).
 - Fix default backend search path (#928).
>- Fix build with latest glibc versions where SIGSTKSZ is not constant
   (#886).
 - Document using SOCI as a CMake subdirectory (#925).
 - Document using SOCI with Conan (#877).

The fix looks easy enough

https://github.com/SOCI/soci/pull/886/commits/7719b5a8242a5ec016f73666a51e80b3bd7f8956

@William: Any opinion on targeted fix vs. new upstream version?

As one of the package I somewhat care about (linphone) is affected by
this removal from testing I would NMU a targeted fix end of September.

Bernhard

Bug#1018016: bind9-libs not found for sid

[Bernhard Schmidt]

Hi,


I’ve recently moved, so everything is in but of disarray including my
builder machine. The git repository should be up to date, so if this
cannot wait a day or two until I connect rest of my network, anybody
should be able to build and upload new upstream version using
git-buildpackage. Alternatively, just wait a few days, I am almost
there re-connecting stuff…


I just came back from vacation and stumbled over this, sorry I couldn't 
help earlier.


You had uploaded 9.18.6-1, but somehow this ended up as an amd64 upload 
binary to unstable, so it did not migrate. And it did not migrate 
because a binNMU to bind-dyndb-ldap is necessary, see #1014503.


I have just made a no-change source-only upload, so the first problem 
should be resolved. For the second I have filed Bug#1019220 .


Now, I'm still utterly confused how this problem could have happened at 
all. I was able to verify at this point that sid was indeed lacking 
bind9-libs:amd64.


But it was built on the buildds

https://buildd.debian.org/status/fetch.php?pkg=bind9=amd64=1%3A9.18.4-2=1657022678=0

and (due to the migration issues) the package version that was lacking 
in sid is still present in testing, including bind9-libs:amd64


bind9-libs | 1:9.18.4-2  | testing| amd64, 
arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x


https://packages.debian.org/bookworm/bind9-libs
http://ftp.de.debian.org/debian/pool/main/b/bind9/bind9-libs_9.18.4-2_amd64.deb

http://snapshot.debian.org/package/bind9/1%3A9.18.4-2/#bind9-libs_1:3a:9.18.4-2

Bernhard

Bug#1019220: nmu: bind-dyndb-ldap_11.10-1

[Bernhard Schmidt]

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

Hi,

while Bug#1014503 is not fixed we need another binNMU of bind-dyndb-ldap
against the new version of bind9 in unstable (accepted a few minutes ago)

nmu bind-dyndb-ldap_11.10-1 . ANY . unstable . -m "Rebuild for bind9/1:9.18.6-2"

Thanks,
Bernhard

Bug#1017379: nm-openvpn: capng_change_id() failed applying capabilities: Operation not permitted (errno=1)

[Bernhard Schmidt]

Control: severity -1 serious
Control: forwarded -1 
https://sourceforge.net/p/openvpn/mailman/message/37693662/
Control: tags -1 confirmed upstream

On 15/08/22 09:36 AM, Benjamin Eikel wrote:

> Aug 15 09:24:46 myhostname nm-openvpn[11804]: capng_change_id() failed 
> applying capabilities: Operation not permitted (errno=1)
> Aug 15 09:24:46 myhostname nm-openvpn[11804]: NOTE: previous error likely due 
> to missing capability CAP_SETPCAP.
> Aug 15 09:24:46 myhostname nm-openvpn[11804]: Exiting due to fatal error

Thanks for the report. 

Upstream is looking into it, see
https://sourceforge.net/p/openvpn/mailman/message/37693662/ . Until this
is done, raising the severity to prevent testing migration.

Bernhard

Bug#989218: openvpn: the lack of down update-resolv-conf script

[Bernhard Schmidt]

On 29/05/21 04:14 AM, sergio wrote:

> resolv.conf left configured after tunnel down due to lack of down script

No, the Debian supplied script is supposed to be used for both

---
$ head /etc/openvpn/update-resolv-conf
#!/bin/bash
# 
# Parses DHCP options from openvpn to update resolv.conf
# To use set as 'up' and 'down' script in your openvpn *.conf:
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf
---

and handles down just fine.

> If you will be updating the current debian update-resolv-conf with
> client.up / client.down from openwrt, please pay attention, that
> client.up calls resolvconf with '-p' so it fails on debian.

I won't be updating the resolvconf scripts myself, but I would accept
tested patches for it. 

The scripts in
https://github.com/OpenVPN/openvpn/tree/master/contrib/pull-resolv-conf
are not acceptable (they fiddle with /etc/resolv.conf directly if
resolvconf is not available).

Bernhard

Bug#976070: openvpn fails with iproute option

[Bernhard Schmidt]

On 29/11/20 11:05 AM, Glennie Vignarajah wrote:

> In order to use openvpn with non root priviliges, iproute is need as
> state in openvpn's howto document [1]. By default, iproute is disabled
> on compile time and needs to enabled with ``--enable-iproute2``.

Upstream has now added the option for openvpn to retain the
CAP_NET_ADMIN capability while dropping priviledges. OpenVPN now works
correctly with --user something.

Bernhard

Bug#908559: openvpn: Openvpn cannot run /sbin/ip if started from systemd

[Bernhard Schmidt]

Version: 2.5.0-1

> The openvpn systemd unit cannot start because it cannot call the /sbin/ip
> script. If I run the same script by hand it starts, so the problem should be
> in the system unit file. I have been using the same config file for a while
> (~8-10 years) and changed nothing, it happened when I upgraded my host at
> the end of August after a long summber break.

Starting with 2.5.0, openvpn is not using direct calls to /sbin/ip
anymore, but netlink messages. Closing this bug.

Bernhard

Bug#1004054: /usr/bin/nslookup: Re: bind9-host: host crashes in netmgr.c

[Bernhard Schmidt]

Control: fixed -1 1:9.18.2-1

Hi,

> this is already reported in the upstream issue tracker, but since there’s no
> reliable reproducer, we (as in the BIND 9 upstream team) were not able
> to prepare the fix.

as far as I understand, this has been fixed upstream in 9.18.2

https://gitlab.isc.org/isc-projects/bind9/-/issues/3020
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5998

5831.   [bug]   When resending a UDP request in the result of a timeout,
the recv_done() function in dighost.c was prepending
the new query into the loookup's queries list instead
of inserting, which could cause an assertion failure
when the resent query's result was SERVFAIL. [GL #3020]

Bernhard

Bug#1000447: netmgr/netmgr.c:1737: (...) failed

[Bernhard Schmidt]

Control: fixed -1 1:9.18.2-1

Hi,

as far as I understand, this has been fixed upstream in 9.18.2

https://gitlab.isc.org/isc-projects/bind9/-/issues/3020
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5998

5831.   [bug]   When resending a UDP request in the result of a timeout,
the recv_done() function in dighost.c was prepending
the new query into the loookup's queries list instead
of inserting, which could cause an assertion failure
when the resent query's result was SERVFAIL. [GL #3020]

Bernhard

Bug#987927: bind9: unreasonable resource use and slow startup with lots of IP addresses

[Bernhard Schmidt]

On 11/05/21 02:30 PM, Ondřej Surý wrote:
> Control: forwarded -1 
> https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5012
> 
> Hi,
> 
> coincidentally, I’ve been working (well, experimenting would be better word) 
> with
> reducing the contention in the memory allocator and the first patch in the 
> branch
> might help with the initialization time.  Not so much with contention, for 
> that the
> work on the branch will have to be complete (e.g. this will go into upstream 
> 9.18,
> not 9.16), but I thought you might be interested in the work in progress.
> 
> This particular branch is very fresh, but I have at least 3 or 4 different 
> approaches
> with different experiments.

As far as I understand part of this work has been merged in 9.16.25, see 

https://kb.isc.org/docs/bind-memory-consumption-explained

Additionally, the memory allocator has been switched to jmealloc in
9.17.19

bind9 (1:9.17.19-2) unstable; urgency=medium
  * Add libjemalloc-dev to Build-Depends

Russell, could you test again?

Bernhard

Bug#1012567: openvpn --mktun --dev-type tap --dev tap2 fails

[Bernhard Schmidt]

Control: forward -1 https://sourceforge.net/p/openvpn/mailman/message/37665283/
Control: tags -1 upstream

Hi Wolfgang,

> Since 2.6.0~git20220518+dco-2 the following command fails:
> 
> openvpn --mktun --dev-type tap --dev tap2
> 
> with
> 
> Assertion failed at dco_linux.c:442 (tt-type == DEV_TYPE_TUN)
> Exit due to fatal error
> 
> I don't have dco support in the linux kernel.
> 
> openvpn --disable-dco --mktun --dev-type tap --dev tap2
> 
> works as a workaround, but I think --mktun --dev-type tap should continue to
> work without it.

Upstream is thinking about removing that feature, see

https://sourceforge.net/p/openvpn/mailman/message/37677365/

---
Hi,

we are discussing to remove support for openvpn --mktun / --rmtun options
in the upcoming 2.6 release - because it complicates the code, and we
think there is no actual *need* for it anymore (and it's Linux only, etc).

With "ip", there is a submode "ip tuntap", which does the same thing,
so 

  # openvpn --mktun --dev tun4

becomes

  # ip tuntap add mode tun name tun4

and similar for tap stuff, "user / group" settings, etc.


So, this message is intended to do two things

 - raise awareness "this will come in 2.6!"
 - and also gather feedback: *if* you use openvpn --mktun today, please
   test "ip tuntap..." and let us know if it gets the job done properly,
   or of something is missing.

The code is not removed yet, but will be, unless there are strong reasons
to keep it.

gert

---

Bernhard

Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea

[Bernhard Schmidt]

Am 05.07.22 um 09:23 schrieb Raphaël Hertzog:


as Kali is based on Debian testing, our users started to experience
the git snapshot of OpenVPN that you uploaded. Unfortunately, we got
multiple reports that their VPN break because many VPN services ship .opvn
files that rely on --cipher.

At the same time, it's not really reasonable to expect (commercial)
services to be ready for a version of OpenVPN that is not released yet.

Upstream OpenVPN contributors are blaming Debian/Kali for this choice:
https://forums.openvpn.net/viewtopic.php?p=107165#p107154

As such I really believe that this git snapshot should have stayed in
experimental. Why was it uploaded to unstable before its upstream
release?


I respectfully disagree. This is what unstable/testing is for. 2.6 is to 
be released really soon, it contains breaking changes which we need to 
iron out / document with both upstream and Debian packaging. This can't 
wait until the last minute before the freeze. The 2.6 upload was 
influenced by OpenSSL 3.0, but this was definitely not the only reason 
to do this.



If we don't want to switch back to 2.5.x, it might make sense to
temporarily revert the backwards incompatible change
that breaks most people's setup, I'm speaking of this commit:
https://github.com/OpenVPN/openvpn/commit/65f6da8eeb84fbcea357765e13fa73d0169a143c


I don't see a good reason to do this in Debian. We either have to keep 
that change forever, or at some point later revert the revert, which 
will immediately break these setups again. At least this way users see a 
major version upgrade in their apt log.


This could be discussed with upstream.

Bernhard

Bug#1014133: asterisk: Asterisk fails to build from source

[Bernhard Schmidt]

Control: severity -1 important
Control: found -1 1:16.16.1~dfsg-1
Control: fixed -1 1:16.16.1~dfsg+~2.10-1

Hi Ralf,

I am not very familiar with asterisk as packaged for Bullseye - only
know that it was pretty unusually done.

Maybe try build in a pristine build-environment.


What do you mean by this?


As Jonas already wrote, please use something like sbuild/cowbuilder. The 
packages for Bullseye have been built from source by the buildd, so 
generally they should work just fine.


I might have a look later, but since Jonas changed the packaging for 
Bullseye (in a way I don't grasp anymore :-) ) this is definitely not 
affecting the next release and it's definitely not stable-update 
material. So downgrading.


Bernhard

Bug#1012059: bind9: autopkgtest regression on amd64 and armhf: connection refused

[Bernhard Schmidt]

Control: tags -1 pending

Hi,
With a recent upload of bind9 the autopkgtest of bind9 fails in 
testing on amd64 and armhf when that autopkgtest is run with the 
binary packages of bind9 from unstable. It passes when run with only 
packages from testing. In tabular form:


I have had a brief look and it seems we are just too quick. Adding a 
sleep 1 into the setup function makes the test succeed.


However, I cannot figure out the current repository layout anymore. 
debian/main appears to be outdated. The closest thing that matches 
Debian sid right now is the isc/9.18 branch.

 > Could you please tell me how to handle this repository?


Since you have changed the structure of the repo again and I'm now 
reasonably sure that I have to look at the debian/9.18 branch I've 
pushed a commit fixing the autopkgtest regression in there. Not sure 
when it will land, since there is already a 9.18.4-1 tagged in there but 
not yet uploaded.


Bernhard

Bug#1012059: bind9: autopkgtest regression on amd64 and armhf: connection refused

[Bernhard Schmidt]

Control: tags -1 pending

Hi,
With a recent upload of bind9 the autopkgtest of bind9 fails in 
testing on amd64 and armhf when that autopkgtest is run with the 
binary packages of bind9 from unstable. It passes when run with only 
packages from testing. In tabular form:


I have had a brief look and it seems we are just too quick. Adding a 
sleep 1 into the setup function makes the test succeed.


However, I cannot figure out the current repository layout anymore. 
debian/main appears to be outdated. The closest thing that matches 
Debian sid right now is the isc/9.18 branch.

 > Could you please tell me how to handle this repository?


Since you have changed the structure of the repo again and I'm now 
reasonably sure that I have to look at the debian/9.18 branch I've 
pushed a commit fixing the autopkgtest regression in there. Not sure 
when it will land, since there is already a 9.18.4-1 tagged in there but 
not yet uploaded.


Bernhard

Bug#1012129: openvpn: 2.6 client fails authentication against older server

[Bernhard Schmidt]

Control: tags -1 + moreinfo

Hi Guillem,


Just upgraded openvpn the other day and could not connect anymore to the
VPN. Reverting back to 2.5.6-1 makes it work again. I checked #1011473
and nothing there seemed relevant. Here's an (edited) excerpt from the
log (from today's retry):




   2022-05-30 18:07:08 us=863166 AUTH: Received control message: AUTH_FAILED


This one looks weird, do you have any chance to check the logs on the 
other side?



The auth setting is locally set to SHA512, I'm assuming OpenSSL remaps
it, but that's just a warning. It just seems to be failing at the
PUSH_REQUEST step. Setting «compat-mode 2.5.6» did not help either.


This (different name between OpenSSL 1.1 and OPenSSL 3.0 for the same 
algo) has been fixed upstream already, but not yet imported into the dco 
tree. Unless you run opt-verify on the other side that should not matter 
though.


Bernhard

Bug#1012059: bind9: autopkgtest regression on amd64 and armhf: connection refused

[Bernhard Schmidt]

Hi Ondrej,

With a recent upload of bind9 the autopkgtest of bind9 fails in testing 
on amd64 and armhf when that autopkgtest is run with the binary packages 
of bind9 from unstable. It passes when run with only packages from 
testing. In tabular form:


I have had a brief look and it seems we are just too quick. Adding a 
sleep 1 into the setup function makes the test succeed.


However, I cannot figure out the current repository layout anymore. 
debian/main appears to be outdated. The closest thing that matches 
Debian sid right now is the isc/9.18 branch.


Could you please tell me how to handle this repository?

Bernhard