Bug#1082091: unattended-upgrades: Sending email report fails due to "HeaderWriteError" missing from Python mod. email.errors

[Jens Schmidt]

Ah, this is probably a one-time thing only, since file 
/usr/lib/python3.12/email/errors.py
actually already contains that Python fix on my system:

- snip -
[...]
class CharsetError(MessageError):
"""An illegal charset was given."""


class HeaderWriteError(MessageError):
"""Error while writing headers."""


# These are parsing defects which the parser was able to work around.
class MessageDefect(ValueError):
[...]
- snip -

Leaving it to you whether you'd like to do something about this issue or not.

For the record, the order of the package upgrades done by unattended-upgrade 
during the run where sending mail failed was as follows:

- snip -
[...]
Log started: 2024-09-18  10:51:15
(Reading database ... 101329 files and directories currently installed.)
Preparing to unpack .../python3.12-venv_3.12.6-1_amd64.deb ...
Unpacking python3.12-venv (3.12.6-1) over (3.12.4-3) ...
Preparing to unpack .../libpython3.12t64_3.12.6-1_amd64.deb ...
Unpacking libpython3.12t64:amd64 (3.12.6-1) over (3.12.4-3) ...
Preparing to unpack .../libssl3t64_3.3.2-1_amd64.deb ...
Unpacking libssl3t64:amd64 (3.3.2-1) over (3.2.2-1) ...
Selecting previously unselected package openssl-provider-legacy.
Preparing to unpack .../openssl-provider-legacy_3.3.2-1_amd64.deb ...
Unpacking openssl-provider-legacy (3.3.2-1) ...
Setting up libssl3t64:amd64 (3.3.2-1) ...
Setting up openssl-provider-legacy (3.3.2-1) ...
(Reading database ... 101333 files and directories currently installed.)
Preparing to unpack .../python3.12_3.12.6-1_amd64.deb ...
Unpacking python3.12 (3.12.6-1) over (3.12.4-3) ...
Preparing to unpack .../libpython3.12-stdlib_3.12.6-1_amd64.deb ...
Unpacking libpython3.12-stdlib:amd64 (3.12.6-1) over (3.12.4-3) ...
Preparing to unpack .../python3.12-minimal_3.12.6-1_amd64.deb ...
Unpacking python3.12-minimal (3.12.6-1) over (3.12.4-3) ...
Preparing to unpack .../libpython3.12-minimal_3.12.6-1_amd64.deb ...
Unpacking libpython3.12-minimal:amd64 (3.12.6-1) over (3.12.4-3) ...
Preparing to unpack .../openssl_3.3.2-1_amd64.deb ...
Unpacking openssl (3.3.2-1) over (3.2.2-1) ...
Setting up libpython3.12-minimal:amd64 (3.12.6-1) ...
Setting up openssl (3.3.2-1) ...
Installing new version of config file /etc/ssl/openssl.cnf ...
Setting up python3.12-minimal (3.12.6-1) ...
Setting up libpython3.12-stdlib:amd64 (3.12.6-1) ...
Setting up python3.12 (3.12.6-1) ...
Setting up libpython3.12t64:amd64 (3.12.6-1) ...
Setting up python3.12-venv (3.12.6-1) ...
Processing triggers for systemd (256.5-1) ...
Processing triggers for man-db (2.12.1-3) ...
Processing triggers for desktop-file-utils (0.27-2) ...
Processing triggers for libc-bin (2.39-7) ...
Log ended: 2024-09-18  10:51:19
[...]
Log started: 2024-09-18  10:53:14
Preconfiguring packages ...
Preconfiguring packages ...
(Reading database ... 101505 files and directories currently installed.)
Preparing to unpack .../unattended-upgrades_2.11+nmu1_all.deb ...
Unpacking unattended-upgrades (2.11+nmu1) over (2.11) ...
dpkg: warning: unable to delete old directory '/lib/systemd/system-sleep': 
Directory not empty
Setting up unattended-upgrades (2.11+nmu1) ...
Processing triggers for man-db (2.12.1-3) ...
Log ended: 2024-09-18  10:53:15
[...]
- snip -

Bug#1082091: unattended-upgrades: Sending email report fails due to "HeaderWriteError" missing from Python mod. email.errors

[Jens Schmidt]

Forgot to add information on the relevant (?) Python package:

[~]$ dpkg -S /usr/lib/python3.12/email/errors.py
libpython3.12-minimal:amd64: /usr/lib/python3.12/email/errors.py

[~]$ aptitude show libpython3.12-minimal
Package: libpython3.12-minimal   
Version: 3.12.6-1
State: installed
Automatically installed: yes
Multi-Arch: same
Priority: optional
Section: python
Maintainer: Matthias Klose 
Architecture: amd64
Uncompressed Size: 5,299 k
Depends: libc6 (>= 2.14), libssl3t64 (>= 3.3.0)
Recommends: libpython3.12-stdlib
Conflicts: binfmt-support (< 1.1.2)
Description: Minimal subset of the Python language (version 3.12)
 This package contains some essential modules. It is normally not used on it's
 own, but as a dependency of python3.12-minimal.

Bug#1081189: qemu-system: net bridge retards start from qemu for Minutes with 100% load on 1 Core. ...system-i386 ...system-arm. maybe the dropped package uml-utilities (tunctl) is the problem

[Dietmar Schmidt]

Package: qemu-system
Version: 1:9.0.2+ds-2+b1
Severity: normal
X-Debbugs-Cc: dietdeb...@schmidt-dietmar.com

qemu-system: net bridge retards start from qemu for Minutes with 100% load on 1 
Core.
 ...system-i386 ...system-arm. 
maybe the dropped package uml-utilities (tunctl) is the problem


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.10.6-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qemu-system depends on:
ii  qemu-system-arm1:9.0.2+ds-2+b1
pn  qemu-system-mips   
pn  qemu-system-misc   
pn  qemu-system-ppc
pn  qemu-system-sparc  
ii  qemu-system-x861:9.0.2+ds-2+b1

qemu-system recommends no packages.

qemu-system suggests no packages.

Bug#1076022: Additional patch for bullseye's FreeRADIUS (was: Backport some security settings from upstream 3.2.5 release to mitigate BlastRADIUS)

[Bernhard Schmidt]

On 22/08/24 08:36 PM, Bernhard Schmidt wrote:

> FTR, I've tested the binaries on our radius setup today and they worked as
> expected.

Unfortunately I'm still lacking time, but today I had two unexpected
consequences. 

A clients.conf entry spanning large subnets was upgraded automatically
from require_message_authenticator auto -> yes due to the first package
being received. Consequently messages from another Radius client within
the same clients.conf entry was dropped silently.

So far as expected, but I would have assumed FreeRADIUS to log an error
when a request without Message-Authenticator attribute comes in and it
is (auto-)configured to expect one. But I did not see anything. Is this
correct?

Another thing to watch out, although I would not want it to be in the
official changelog/news, Checkpoint Firewalls are known to be broken by
FreeRADIUS returning a Message-Authenticator attribute, see
https://support.checkpoint.com/results/sk/sk42184 . Apparently there is
an internal workaround available, but only to paying users.

I could not find a quick way to disable FreeRADIUS always _sending_ the
Message-Authenticator header.

All of that only quickly tested on the Bullseye package, I had no time
yet to dig deeper.

Bernhard


signature.asc
Description: PGP signature

Bug#1079442: rlwrap: Warnings on invalid escape sequences for rlwrap during Python upgrades

[Jens Schmidt]

Package: rlwrap
Version: 0.46.1-1+b1
Severity: normal
X-Debbugs-Cc: in.cognit...@arcor.de

Dear Maintainer,

   * What led up to the situation?

Upgrades of the python3 package, for example, with unattended upgrades.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Nothing in particular, just letting the upgrades happen.

   * What was the outcome of this action?

Getting warnings on rlwrap-related files during python3 upgrades:

- snip -
Log started: 2024-08-23  10:40:46
Preparing to unpack .../python3-venv_3.12.5-1_amd64.deb ...
Unpacking python3-venv (3.12.5-1) over (3.12.4-1) ...
Preparing to unpack .../python3-minimal_3.12.5-1_amd64.deb ...
Unpacking python3-minimal (3.12.5-1) over (3.12.4-1) ...
Setting up python3-minimal (3.12.5-1) ...
Preparing to unpack .../python3_3.12.5-1_amd64.deb ...
Unpacking python3 (3.12.5-1) over (3.12.4-1) ...
Preparing to unpack .../libpython3-stdlib_3.12.5-1_amd64.deb ...
Unpacking libpython3-stdlib:amd64 (3.12.5-1) over (3.12.4-1) ...
Setting up libpython3-stdlib:amd64 (3.12.5-1) ...
Setting up python3 (3.12.5-1) ...
/usr/share/rlwrap/filters/ftp_filter.py:57: SyntaxWarning: invalid escape 
sequence '\s'
  results = [re.split('\s+', l)[dir_filename_column[where]] for l in lines]
/usr/share/rlwrap/filters/ftp_filter.py:100: SyntaxWarning: invalid escape 
sequence '\s'
  nwords = len(re.split('\s+', line))
/usr/share/rlwrap/filters/ftp_filter.py:108: SyntaxWarning: invalid escape 
sequence '\s'
  command = re.search('\s*(\S+)', line).group(1)
/usr/share/rlwrap/filters/rlwrapfilter.py:4: SyntaxWarning: invalid escape 
sequence '\s'
  """
/usr/share/rlwrap/filters/rlwrapfilter.py:211: SyntaxWarning: invalid escape 
sequence '\S'
  m = re.match("(\S+) (.*?)\r?\n", sys.stdin.readline())
Setting up python3-venv (3.12.5-1) ...
Processing triggers for man-db (2.12.1-3) ...
Log ended: 2024-08-23  10:40:48
- snip -

   * What outcome did you expect instead?

No warnings.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages rlwrap depends on:
ii  libc62.39-6
ii  libreadline8t64  8.2-4
ii  libtinfo66.5-2
ii  perl 5.38.2-5
ii  python3  3.12.5-1

rlwrap recommends no packages.

rlwrap suggests no packages.

-- no debconf information

Bug#1076022: Additional patch for bullseye's FreeRADIUS (was: Backport some security settings from upstream 3.2.5 release to mitigate BlastRADIUS)

[Bernhard Schmidt]

On 22/08/24 01:45 PM, Santiago Ruano Rincón wrote:

> Bernhard, Bastien (in CC) is willing to handle the PUs. Please, let us
> know if it is still OK for you. In any case, we would like to avoid
> duplicated work.

Sure, go ahead. @Bastien feel free to push to the normal branches in
Salsa as well. No objections in any way.

FTR, I've tested the binaries on our radius setup today and they worked as
expected.

Bernhard


signature.asc
Description: PGP signature

Bug#1047146: stimfit 0.16.4-1.1 packaged for debian

[Christoph Schmidt-Hieber]

Dear all,

Apologies for the slow response, I was on holidays.

I have just accepted Alois' pull request on the GitHub repo.
 
Best wishes
Christoph



> On 16 Aug 2024, at 17:23, Alois Schlögl  wrote:
> 
> Dear Yaroslav,
> 
> yes, everything for 0.16.4-1 avaiable in [1] at
> commit 416e655f02085118ffc7dbf2da85c52415b42f57 (tag: v0.16.4debian, 
> origin/master, origin/HEAD)
> Currently, I can not push the attached patch for 0.16.4-1-1 into [1], 
> therefore I attached the patch.
> A clone of the repo is also available here [2], which includes that latest 
> patch.
> 
> Let me know if you need anything else.
> 
> 
> Cheers,
>   Alois
> 
> 
> 
> 
> [1] https://github.com/neurodroid/stimfit
> [2] https://git.ista.ac.at/alois.schloegl/stimfit
> 
> 
> Am 8/16/24 um 14:32 schrieb Yaroslav Halchenko:
>> Hi Alois
>> 
>> Sorry for radio silence.  Now I have my attention on this, let's get
>> stimfit updated.
>> 
>> On 5 Apr 2024 you also shared new orig and .deb for 0.16.4-1 but forgot
>> to share sources (.dsc or at least .debian.tar.gz) -- could you do that?
>> Or may be you already have it all in git, e.g. in a debian branch on
>> your https://github.com/neurodroid/stimfit ?
>> 
>> Cheers,
>> 
>> On Fri, 16 Aug 2024, Alois Schlögl wrote:
>> 
>>> Dear Debian maintainers,
>>> Upgrading to the latest release of stimfit v0.16.4 fixes this issue.
>>> The resulting debian packages are available from here:
>>>  https://pub.ista.ac.at/~schloegl/src/stimfit/0.16.4-1.1/
>>> The debian packages can be rebuild with this command (tested on
>>> Debian12/bookworm)
>>> git clone https://github.com/neurodroid/stimfit
>>> patch -p1 < stimfit-0.16.4-1.1-debian-release-changes.patch
>>> or
>>> git clone https://git.ista.ac.at/alois.schloegl/stimfit
>>> and run this script to build the debian packages:
>>> (. dist/debian/mkdeb.sh)
>> 
>>> Cheers,
>>>   Alois
>> 
>> 
>>> commit 020ba74efafa5e76e263cf13c67babc88ca63025
>>> Author: Alois Schlögl 
>>> Date:   Thu Aug 15 23:06:28 2024 +0200
>>> prepare debian release 0.16.4-1.1
>>> diff --git a/dist/debian/changelog b/dist/debian/changelog
>>> index abb6b13b..e5a49571 100644
>>> --- a/dist/debian/changelog
>>> +++ b/dist/debian/changelog
>>> @@ -1,3 +1,11 @@
>>> +stimfit (0.16.4-1.1) unstable; urgency=medium
>>> +
>>> +  * Non-maintainer upload.
>>> +  * use external libbiosig instead of internal
>>> +(configure --with-biosig instead of --with-biosiglite)
>>> +
>>> + -- Alois Schloegl   Thu, 15 Aug 2024 12:56:35 
>>> +1300
>>> +
>>>  stimfit (0.16.4-1) unstable; urgency=medium
>>>* Non-maintainer upload.
>>> diff --git a/dist/debian/control b/dist/debian/control
>>> index 38d85c55..aaff7404 100644
>>> --- a/dist/debian/control
>>> +++ b/dist/debian/control
>>> @@ -3,7 +3,7 @@ Section: science
>>>  Priority: optional
>>>  Maintainer: Christoph Schmidt-Hieber 
>>>  Uploaders: Yaroslav Halchenko 
>>> -Build-Depends: debhelper (>= 9), dh-python, libbiosig-dev (>= 2.1.0), 
>>> python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, 
>>> python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.2-dev, libfftw3-dev, liblapack-dev, 
>>> chrpath, help2man, zlib1g-dev, dh-autoreconf, pkg-config
>>> +Build-Depends: debhelper (>= 10), dh-python, libbiosig-dev (>= 2.1.0), 
>>> python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, 
>>> python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.2-dev, libfftw3-dev, liblapack-dev, 
>>> chrpath, help2man, zlib1g-dev, dh-autoreconf, pkg-config
>>>  Standards-Version: 3.9.8
>>>  Homepage: http://www.stimfit.org
>>> diff --git a/dist/debian/copyright b/dist/debian/copyright
>>> index 4d12ebad..4ba47f1c 100644
>>> --- a/dist/debian/copyright
>>> +++ b/dist/debian/copyright
>>> @@ -7,10 +7,6 @@ Files: *
>>>  Copyright: 2011, Christoph Schmidt-Hieber 
>>>  License: GPL-2+
>>> -Files: src/libbiosiglite/*
>>> -Copyright: 2005-2016, Alois Schloegl 
>>> -License: GPL-3
>>> -
>>>  Files: src/libstfio/abf/axon/*
>>>  Copyright: 1993-2000, Axon Instruments 
>>>  License: axon1
>>> diff --git a/dist/debian/mkdeb.sh b/dist/debian/mkdeb.sh
>>> index 661c8962..dd0c333f 100644
>>> --- a/dist/debian/mkdeb.sh
>>> +++ b/dist/debian/mkd

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

[Bernhard Schmidt]

Hi,


Yes but time here is short, last PU is end of august

I can test drive the bulleye version on one of our production servers
after 20th, and I can certainly ask in the higher education group in
Germany who can test either locally available .debs or better use
-proposed uploads before the point release.


Fine thansk

Bookworm backport could go along ASAP. Risk is low here


I've asked around and found a few who could test drive .debs next week. 
If you build binaries (or if you have a branch with the proposed changes 
for bookworm too) I can send them over.



Do we have a date for the next point release already?

Last day of august


okay, so uploading on 23rd at the latest. I'll get to it early CW 34, 
but you are totally free to give it a go before, no objections.


Bernhard

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

[Bernhard Schmidt]

Another story is bullseye, that one is affected as well but a backport
there is even harder. For now I have marked it as well no-dsa in the
security-tracker, but maybe it should be  with mentioning
that backporting patches is too intrusive?


Regarding the version in bullseye: upstream has kindly shared with me a
set of patches. I've pushed them to:
https://salsa.debian.org/debian/freeradius/-/tree/wip/debian/blastradius/bullseye.

While they build, I haven't been able to test them (yet). The
autopkgtest job fails, but that is related to a bug in Salsa CI and
systemd when tmp.mount is masked.

Bernhard, are you able to test them? I do not have any experience with
FreeRADIUS, so I could test them, but I would take me some time. Just
let me know if help is needed here.


Cool, unfortunately I'm off to vacation tomorrow and I'm not sure how 
much I can do before. I'll be back on August 20th.


So, if I understood you correctly, the plan is to use Bastien's 
backported patches in 
https://salsa.debian.org/debian/freeradius/-/tree/wip/debian/blastradius/bullseye 
and update the version in bookworm to the current trixie version, both 
in a point release?


I can test drive the bulleye version on one of our production servers 
after 20th, and I can certainly ask in the higher education group in 
Germany who can test either locally available .debs or better use 
-proposed uploads before the point release.


Do we have a date for the next point release already?

Bernhard

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#1073825: dracut: manual dracut creates initramfs-*.img files, post-install hook does initrd.img-*

[Jens Schmidt]

On 2024-06-21  15:07, Laszlo wrote:

> Would the following work ? If it does it should be probably added to
> the Debian package config.
> 
>> initrdname="initrd-${kernel}.img"

You mean as a value in /etc/{dracut.conf|dracut.conf.d/*}?

I haven't tested it, because I thought that the dracut script does
not evaluate the value (as far as I can see from the sources).  But
OTOH dracut *sources* the configuration files, so this might
actually work.  Of course only if dracut sources them per kernel
version.

I could test it, but only on Monday ...

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 o

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#1065520: python3-nitime: package install Waring

[Greg Schmidt]

Package: python3-nitime
Version: 0.10.2-2
Severity: minor
X-Debbugs-Cc: g...@gwschmidt.com

Dear Maintainer,

syntax error found in doc string of 
usr/lib/python3/dist-packages/nitime/algorithms/event_related.py

Preparing to unpack .../8-python3-nitime_0.10.2-2_all.deb ...
Unpacking python3-nitime (0.10.2-2) over (0.10.2-1) ...
Setting up python3-nitime (0.10.2-2) ...
>>> /usr/lib/python3/dist-packages/nitime/algorithms/event_related.py:13: 
>>> SyntaxWarning: invalid escape sequence '\h'



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-nitime depends on:
ii  python3 3.11.6-1
ii  python3-matplotlib  3.6.3-1+b2
ii  python3-numpy   1:1.24.2-2
ii  python3-scipy   1.11.4-6

Versions of packages python3-nitime recommends:
ii  python3-networkx  2.8.8-1
ii  python3-nibabel   5.2.1-1

python3-nitime suggests no packages.

-- no debconf information

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#1060375: libcgroup: new upstream version available: 3.1.0

[Adriaan Schmidt]

Source: libcgroup
Severity: wishlist
Tags: upstream patch

Dear Maintainer,

A new upstream version of this software is available:
https://github.com/libcgroup/libcgroup/releases/tag/v3.1.0

In case it helps, I have created a MR on salsa:
https://salsa.debian.org/debian/libcgroup/-/merge_requests/5

Thanks for your work!

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

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

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 imbalan

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#1055601: darktable: Segfault in first run after system hang

[Greg Schmidt]

Package: darktable
Version: 4.4.2-1+b1
Severity: normal
X-Debbugs-Cc: g...@desk1.attlocal.net

Dear Maintainer,

I was using darktable when my system hung. I had to reboot to recover. After 
the reboot I started darktable and 
it segfaulted. A backtrace was created which implicated dlopen. It was 
attempting to load "libMesaOpenCL.so.1".
A subsequent start of darktable was normal. 

Content of /tmp/darktable_bt_T7K9D2.txt follows:

this is darktable 4.4.2 reporting a segfault:

warning: Currently logging to /tmp/darktable_bt_T7K9D2.txt.  Turn the logging 
off and on to make the new setting effective.
#0  0x7f83a54f11b7 in __GI___wait4 (pid=5442, stat_loc=0x0, options=0, 
usage=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1  0x7f83a57a28d0 in  () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#2  0x7f83a545a510 in  () at 
/lib/x86_64-linux-gnu/libc.so.6
#3  0x7f833fd6bd52 in LLVMCreateTargetMachine () at 
/lib/x86_64-linux-gnu/libLLVM-15.so.1
#4  0x7f8351455e0e in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#5  0x7f83514561c5 in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#6  0x7f83513654eb in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#7  0x7f8351365943 in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#8  0x7f8395331720 in amdgpu_winsys_create () at 
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#9  0x7f8351366616 in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#10 0x7f835123b50a in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#11 0x7f8351eb4fa8 in  () at /lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#12 0x7f8351ea0bd8 in  () at /lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#13 0x7f8351eafae2 in  () at /lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#14 0x7f8351e737d9 in  () at /lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#15 0x7f83a5dfad2e in call_init (env=0x5568250ba0e0, argv=0x7ffd910bebe8, 
argc=7, l=) at ./elf/dl-init.c:90
#16 call_init (l=, argc=7, argv=0x7ffd910bebe8, 
env=0x5568250ba0e0) at ./elf/dl-init.c:27
#17 0x7f83a5dfae14 in _dl_init (main_map=0x556825573a60, argc=7, 
argv=0x7ffd910bebe8, env=0x5568250ba0e0) at ./elf/dl-init.c:137
#18 0x7f83a5df7516 in __GI__dl_catch_exception 
(exception=exception@entry=0x0, operate=operate@entry=0x7f83a5e01570 
, args=args@entry=0x7ffd910ba280) at ./elf/dl-catch.c:211
#19 0x7f83a5e0150e in dl_open_worker (a=a@entry=0x7ffd910ba420) at 
./elf/dl-open.c:808
#20 0x7f83a5df7489 in __GI__dl_catch_exception 
(exception=exception@entry=0x7ffd910ba400, operate=operate@entry=0x7f83a5e01480 
, args=args@entry=0x7ffd910ba420) at ./elf/dl-catch.c:237
#21 0x7f83a5e018a8 in _dl_open (file=0x556825096160 "libMesaOpenCL.so.1", 
mode=, caller_dlopen=0x7f839c0238bd, nsid=, 
argc=7, argv=0x7ffd910bebe8, env=0x5568250ba0e0) at ./elf/dl-open.c:884
#22 0x7f83a54a26f8 in dlopen_doit (a=a@entry=0x7ffd910ba690) at 
./dlfcn/dlopen.c:56
#23 0x7f83a5df7489 in __GI__dl_catch_exception 
(exception=exception@entry=0x7ffd910ba5f0, operate=0x7f83a54a26a0 
, args=0x7ffd910ba690) at ./elf/dl-catch.c:237
#24 0x7f83a5df75af in _dl_catch_error (objname=0x7ffd910ba648, 
errstring=0x7ffd910ba650, mallocedp=0x7ffd910ba647, operate=, 
args=) at ./elf/dl-catch.c:256
#25 0x7f83a54a21e7 in _dlerror_run (operate=operate@entry=0x7f83a54a26a0 
, args=args@entry=0x7ffd910ba690) at ./dlfcn/dlerror.c:138
#26 0x7f83a54a27a9 in dlopen_implementation (dl_caller=, 
mode=, file=) at ./dlfcn/dlopen.c:71
#27 ___dlopen (file=, mode=) at 
./dlfcn/dlopen.c:81
#28 0x7f839c0238bd in  () at /lib/x86_64-linux-gnu/libOpenCL.so.1
#29 0x7f839c023aa3 in  () at /lib/x86_64-linux-gnu/libOpenCL.so.1
#30 0x7f839c0249e3 in clGetPlatformIDs () at 
/lib/x86_64-linux-gnu/libOpenCL.so.1
#31 0x7f83a578aabb in dt_opencl_init () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#32 0x7f83a56efbf3 in dt_init () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#33 0x556823a7a08c in  ()
#34 0x7f83a54456ca in __libc_start_call_main 
(main=main@entry=0x556823a7a070, argc=argc@entry=7, 
argv=argv@entry=0x7ffd910bebe8) at ../sysdeps/nptl/libc_start_call_main.h:58
#35 0x7f83a5445785 in __libc_start_main_impl (main=0x556823a7a070, argc=7, 
argv=0x7ffd910bebe8, init=, fini=, 
rtld_fini=, stack_end=0x7ffd910bebd8) at ../csu/libc-start.c:360
#36 0x556823a7a0f1 in  ()

=

  Id   Target Id Frame 
* 1Thread 0x7f839dc860c0 (LWP 5423) "darktable"  0x7f83a54f11b7 in 
__GI___wait4 (pid=5442, stat_loc=0x0, options=0, usage=0x0) at 
../sysdeps/unix/sysv/linux/wait4.c:30
  2Thread 0x7f839d7ff6c0 (LWP 5425) "pool-spawner"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7f839cffe6c0 (LWP 5426) "gmain"  0x7f83a5519a1f in 
__GI___poll (fds=0x556825096e50, nfds=1, timeout=-1) at 
.

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 

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#1051329: dictionaries-common: Use of uninitialized value in string eq

[Andreas Schmidt]

Package: dictionaries-common
Version: 1.29.6
Severity: normal
Tags: patch

Dear Maintainer,

when I updated hunspell-de-med, I found this in the log:

*
Setting up hunspell-de-med (20230905-1) ...
Use of uninitialized value in string eq at
/usr/share/perl5/Debian/DictionariesCommon.pm line 566.
Use of uninitialized value in string eq at
/usr/share/perl5/Debian/DictionariesCommon.pm line 566.

Processing triggers for dictionaries-common (1.29.6) ...
Use of uninitialized value in string eq at
/usr/share/perl5/Debian/DictionariesCommon.pm line 566.
Use of uninitialized value in string eq at
/usr/share/perl5/Debian/DictionariesCommon.pm line 566.
*


The attached patch should fix this.

Best regards,

Andreas


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dictionaries-common depends on:
ii  cdebconf [debconf-2.0]  0.270
ii  debconf [debconf-2.0]   1.5.82
ii  emacsen-common  3.0.5
ii  libtext-iconv-perl  1.7-8

dictionaries-common recommends no packages.

Versions of packages dictionaries-common suggests:
ii  aspell0.60.8-6
ii  hunspell  1.7.2+really1.7.2-10
ii  ispell3.4.05-1
ii  wamerican [wordlist]  2020.12.07-2
ii  wngerman [wordlist]   20161207-11

-- debconf information excluded
--- DictionariesCommon.pm   2023-09-06 10:36:44.641067430 +0200
+++ DictionariesCommon.pm.fixed 2023-09-06 10:48:09.078836355 +0200
@@ -560,10 +560,11 @@
   # Get a list of emacsen and hash names declared in hunspell-info files.
   foreach my $lang ( keys %$main_dicts ){
 my $lang_entries = $main_dicts->{$lang};
-$main_dicts_emacsen{$lang_entries->{'emacsen-name'}}++
-   if ( defined $lang_entries->{'emacsen-name'} );
-$main_dicts_hashes{$lang_entries->{'hash-name'}}++
-   unless ( $lang_entries->{'emacsen-name'} eq "english_american" );
+if ( defined $lang_entries->{'emacsen-name'} ) {
+$main_dicts_emacsen{$lang_entries->{'emacsen-name'}}++;
+$main_dicts_hashes{$lang_entries->{'hash-name'}}++
+unless ( $lang_entries->{'emacsen-name'} eq "english_american" );
+}
   }
   # Show some debugging code
   dico_debugprint "main-dicts: ". join(', ',sort keys %$main_dicts);

Bug#1040445: udev creates wrong symlink from rule after upgrade to bookworm

[Karl Schmidt]

I'm not up on the steps to do to get the debug (if you can list the command(s) 
to run?).

BUT -

After the last reboot which has 252.12-1~deb12u1  I saw

lrwxrwxrwx 1 root root   9 2023-08-17 16:29 ttyUSB-nut -> gpiochip0

Which is wrong - So I unplugged and replugged the cable and looked again and 
see:

lrwxrwxrwx 1 root root 15 2023-08-23 11:57 ttyUSB-nut -> bus/usb/001/003

Which is also wrong...

Nothing unusual in syslog:

2023-08-23T11:57:33.070249-05:00 localhost kernel: [502060.481676] ftdi_sio ttyUSB0: FTDI USB Serial Device converter 
now disconnected from ttyUSB0

2023-08-23T11:57:33.070259-05:00 localhost kernel: [502060.481724] ftdi_sio 
1-8:1.0: device disconnected
2023-08-23T11:57:35.772093-05:00 localhost kernel: [502063.187387] usb 1-8: new full-speed USB device number 3 using 
xhci_hcd
2023-08-23T11:57:35.924035-05:00 localhost kernel: [502063.341331] usb 1-8: New USB device found, idVendor=0403, 
idProduct=6001, bcdDevice= 6.00
2023-08-23T11:57:35.924054-05:00 localhost kernel: [502063.341345] usb 1-8: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

2023-08-23T11:57:35.924056-05:00 localhost kernel: [502063.341352] usb 1-8: 
Product: FT232R USB UART
2023-08-23T11:57:35.924058-05:00 localhost kernel: [502063.341358] usb 1-8: 
Manufacturer: FTDI
2023-08-23T11:57:35.924060-05:00 localhost kernel: [502063.341363] usb 1-8: 
SerialNumber: AJV9MKOY
2023-08-23T11:57:35.928058-05:00 localhost kernel: [502063.345376] ftdi_sio 1-8:1.0: FTDI USB Serial Device converter 
detected

2023-08-23T11:57:35.928077-05:00 localhost kernel: [502063.345482] usb 1-8: 
Detected FT232R
2023-08-23T11:57:35.928080-05:00 localhost kernel: [502063.346643] usb 1-8: FTDI USB Serial Device converter now 
attached to ttyUSB0



--
----
Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street  Ph (785) 841-3089
Lawrence, KS 66049

Being wrong, is the natural state of experts.
-Malcolm Kendrick

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 (l

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#1043348: rrsync: Directory check too strict

[Johannes Schmidt]

Package: rsync
Version: 3.2.7-1
Severity: normal
X-Debbugs-Cc: jsmith6...@gmx.net

Dear Maintainer,

I found a regression in rrsync, which came with the change from Perl (Bullseye)
to Python (Bookworm), and would like to propose a bug fix.


   * What led up to the situation?

I am using backupninja to create local backups from a remote server. With
Bullseye, I had to use the following line in the configuration file to make it
work with rrsync:
include = .

backupninja converts this to the command
rsync  user@remoteserver:/./ /localbackupdir/
to read the complete subdirectory defined by rrsync (see below) and store it in
the local backup directory.


authorized_keys on the remote server:
command="/usr/bin/rrsync -ro /path/to/restricted/source/",restrict ssh-rsa
...


Starting with Bookworm, rrsync breaks the backup process with the error "unsafe
arg":
(Output of die('unsafe arg:', orig_arg, [arg, real_arg]) )
unsafe arg: /./, [/path/to/restricted/source/., /path/to/restricted/source]

Note that arg is not equal to real_arg, since the trailing "/./" of the
original argument (orig_arg) is not completely stripped from arg.


   * What exactly did you do (or not do) that was effective (or ineffective)?

I found that in rrsync, there is a directory argument check that is too
restrictive to work with above (valid) string:

rrsync 3.2.7 (as in Bookworm):
https://salsa.debian.org/debian/rsync/-/blob/debian/3.2.7-1/support/rrsync?ref_type=tags#L309

ret = [ ]
for arg in got:
if args.dir != '/' and arg != '.' and (typ == 3 or (typ == 2 and not
am_sender)):
arg_has_trailing_slash = arg.endswith('/')
if arg_has_trailing_slash:
arg = arg[:-1]
else:
arg_has_trailing_slash_dot = arg.endswith('/.')
if arg_has_trailing_slash_dot:
arg = arg[:-2]
real_arg = os.path.realpath(arg)
if arg != real_arg and not real_arg.startswith(args.dir_slash):
die('unsafe arg:', orig_arg, [arg, real_arg])
if arg_has_trailing_slash:
arg += '/'
elif arg_has_trailing_slash_dot:
arg += '/.'
if opt == 'arg' and arg.startswith(args.dir_slash):
arg = arg[args.dir_slash_len:]
if arg == '':
arg = '.'
ret.append(arg)

After a small patch, the code seems still valid for me, but allowing a trailing
"/" after a trailing "/.", therefore allowing a trailing "/./".

My proposed patch:

ret = [ ]
for arg in got:
if args.dir != '/' and arg != '.' and (typ == 3 or (typ == 2 and not
am_sender)):
1.  arg_has_trailing_slash = arg.endswith('/')
if arg_has_trailing_slash:
arg = arg[:-1]
2.  arg_has_trailing_slash_dot = arg.endswith('/.')
if arg_has_trailing_slash_dot:
arg = arg[:-2]
3.  real_arg = os.path.realpath(arg)
if arg != real_arg and not real_arg.startswith(args.dir_slash):
die('unsafe arg:', orig_arg, [arg, real_arg])
4.  if arg_has_trailing_slash_dot:
arg += '/.'
5.  if arg_has_trailing_slash:
arg += '/'
if opt == 'arg' and arg.startswith(args.dir_slash):
arg = arg[args.dir_slash_len:]
if arg == '':
arg = '.'
ret.append(arg)

1. Trailing "/" is removed.
2. Trailing "/." is removed.
3. Directory is checked.
4. Trailing "/." is appended again.
5. Trailing "/" is appended again.

Please check carefully, I am not familiar with the Python language.


   * What was the outcome of this action?

The check in line 320 (
https://salsa.debian.org/debian/rsync/-/blob/debian/3.2.7-1/support/rrsync?ref_type=tags#L320
) does not fail, which is the intended result.


Thank you in advance.


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

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rsync depends on:
ii  init-system-helpers1.65.2
ii  libacl12.3.1-3
ii  libc6  2.36-9+deb12u1
ii  liblz4-1   1.9.4-1
ii  libpopt0   1.19+dfsg-1
ii  libssl33.0.9-1
ii  libxxhash0 0.8.1-1
ii  libzstd1   1.5.4+dfsg2-5
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

rsync recommends no packages.

Versions of pac

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#1041440: popularity-contest: Non Debian - non Deb packages should be able to be reported - packages missing from Debian

[Karl Schmidt]

On 7/18/23 11:07PM, Petter Reinholdtsen wrote:

[Karl Schmidt]

While popcon seems a good idea - it seems that data from repository
downloads would do much the same job.


Due to the distributed nature of the mirroring setup, there are no such
data, so it can not be used like that.


It Would be possible to fix that. Data just from one server would give a pretty good idea of the popularity. People that 
run popcon likewise are a subset of the real picture.  A scrip could look at the download logs - make a count - you 
could then compare with popcon to see if the numbers match - I think they would.





What would be even more important is gathering statistics on non
Debian and even non Deb package software installed.


This has been discussed for a while.  You might find for example
https://bugs.debian.org/632438 > illuminating.


Interesting. For example - I know there are a lot of people still using 
komposer - nothing really replaces it.

The number of people running appimage packages in place of the older debian 
versions would be interesting to know as well.

The non-debian executable information seems more important than popcon to me.



--

Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street  Ph (785) 841-3089
Lawrence, KS 66049

Modernity is the denial of uncertainty; a false narrative.
-kps

Bug#1041440: popularity-contest: Non Debian - non Deb packages should be able to be reported - packages missing from Debian

[Karl Schmidt]

Package: popularity-contest
Version: 1.76
Severity: wishlist

While popcon seems a good idea - it seems that data from repository downloads 
would do much the same job. 
What would be even more important is gathering statistics on non Debian and 
even non Deb package software installed.

I would imagine a setting to identify locations of non Debian executables so 
such data could be collected.

There is a pseudo-package bug - wnpp - that almost no one uses, but I would 
think that statistics on what 
is missing from Debian would be quite important.


-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'oldstable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.21.22

Versions of packages popularity-contest recommends:
ii  cron [cron-daemon] 3.0pl1-162
ii  exim4-daemon-light [mail-transport-agent]  4.96-15
ii  gpg2.2.40-1.1

Versions of packages popularity-contest suggests:
ii  anacron   2.3-36
pn  tor   
pn  torsocks  

-- debconf information:
* popularity-contest/participate: true
  popularity-contest/submiturls:

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#1017520: Still alive in 4:2.27.5-2

[Karl Schmidt]

I checked the file it mentions - it exists (probably the source of the error?)

The file belongs to plasma-workspace-data

The error fires off in the log in sets of 4 -

2023-07-09T19:44:13.921511-05:00 singapore plasmashell[2077]: Could not find the Plasmoid for 
Plasma::FrameSvgItem(0x7f7214028120) QQmlContext(0x558176238800) 
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")





--

Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street  Ph (785) 841-3089
Lawrence, KS 66049

Collective intelligence fails - science is not a popularity contest.
kps

Bug#1040446: nut-server: failed after upgrade - upscode2: Missing UPCL after UPCL error

[Karl Schmidt]

Package: nut-server
Version: 2.7.4-13
Severity: normal

Upgrade to bookworm broke things with the new nut-server pkg

The error is misleading - it has to do with some debug code. 

Some details on the mailing list at:
https://alioth-lists.debian.net/pipermail/nut-upsuser/2023-July/013366.html

The jist of it - the driver upscode2 works with debug=3 - but not without - some
bug was just fixed that probably cures this according to the mailing list.

I didn't sucseed in creating a new pkg from the github sources so I downgraded 
to the 
old version to keep things working.

There is a new version upstream - would love to test it once in a deb package.


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nut-server depends on:
ii  adduser3.134
ii  init-system-helpers1.65.2
ii  libc6  2.36-9
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libnutscan12.7.4-13
ii  libupsclient4  2.7.4-13
ii  libusb-0.1-4   2:0.1.12-32
ii  libwrap0   7.6.q-32
ii  lsb-base   11.6
hi  nut-client 2.7.4-13
ii  sysvinit-utils [lsb-base]  3.06-4
ii  udev   252.11-1

nut-server recommends no packages.

Versions of packages nut-server suggests:
pn  nut-cgi   
pn  nut-ipmi  
pn  nut-snmp  
pn  nut-xml   

-- Configuration Files:
/etc/nut/ups.conf changed:
[malaysia]
driver = upscode2
port = /dev/ttyUSB0
desc = "NetUPS SE"

/etc/nut/upsd.conf changed:
LISTEN 127.0.0.1 3493

/etc/nut/upsd.users changed:
[root]
password = ups
instcmds = ALL
actions = SET FSD

[monuser]
password  = ups
upsmon master



-- no debconf information

Bug#1040443: wajig crashes on listhold

[Karl Schmidt]

Package: wajig
Version: 4.0.3
Severity: normal


# wajig listhold
Traceback (most recent call last):
  File "/usr/bin/wajig", line 33, in 
 sys.exit(load_entry_point('wajig==4.0.3', 'console_scripts', 'wajig')())
   ^^
  File "/usr/lib/python3/dist-packages/wajig/__init__.py", line 1209, in 
main
 result.func(result)
File "/usr/lib/python3/dist-packages/wajig/commands.py", line 632, in 
listhold
  perform.execute("dpkg --get-selections | grep -E 'hold$' | cut -f1", 
teach=args.teach, noop=args.noop)

^^
  AttributeError: 'Namespace' object has no attribute 'teach'


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wajig depends on:
ii  apt  2.6.1
ii  aptitude 0.8.13-5
ii  dpkg 1.21.22
ii  python3  3.11.2-1+b1
ii  python3-apt  2.6.0
ii  python3-distro   1.8.0-1
ii  python3-fuzzywuzzy   0.18.0-4
ii  python3-levenshtein  0.12.2-2+b4

wajig recommends no packages.

Versions of packages wajig suggests:
ii  alien  8.95.6
ii  apt-file   3.3
ii  apt-move   4.2.27-6
ii  apt-show-versions  0.22.13+nmu1
pn  chkconfig  
ii  dctrl-tools2.24-3+b1
ii  debconf1.5.82
ii  deborphan  1.7.35
ii  debsums3.0.2.1
ii  debtags2.1.5
ii  dpkg-dev   1.21.22
ii  dpkg-repack1.52
ii  fakeroot   1.31-1.2
ii  locales2.36-9
ii  netselect-apt  0.3.ds1-30.1
ii  reportbug  12.0.0
ii  sudo   1.9.13p3-1
ii  vrms   1.33

-- no debconf information

Bug#1040072: meld: Gets stuck in full screen mode if you don't know the secret

[Karl Schmidt]

Package: meld
Version: 3.22.0-2
Severity: normal


If opened from a past full screen adventure - it will open in full screen and 
there is no obvious way to exit full screen. It isn't Exc - or cnt-f or cnt-f

(Going to a second computer and searching the web - turns out F11 is the trick)

Looks like it is being fixed finnaly but - wanted to post this bug as a 
breadcrumb for others.
https://gitlab.gnome.org/GNOME/meld/-/issues/735
https://gitlab.gnome.org/GNOME/meld/-/issues/716


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages meld depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-gtksource-4   4.8.4-4
ii  libgtk-3-0   3.24.37-2
ii  patch2.7.6-7
ii  python3  3.11.2-1+b1
ii  python3-gi   3.42.2-3+b1
ii  python3-gi-cairo 3.42.2-3+b1

Versions of packages meld recommends:
ii  yelp  42.2-1

meld suggests no packages.

-- no debconf information

Bug#1039000: calamares-settings-mobian: fstab has ext4 instead of btrfs for the root filesystem

[Chris Schmidt]

Source: calamares-settings-mobian
Version: 0.3.1
Severity: normal
X-Debbugs-Cc: chris-schm...@mailbox.org

Dear Maintainer,

I installed Mobian on my new PineTab2 and selected btrfs during
installation. After the installation was done there was the following
entry in /etc/fstab with ext4 instead of btrfs:

/dev/mapper/calamares_crypt / ext4  defaults,x-systemd.growfs0   1

Also the last field (fs_passno) should probably be 0, see
https://btrfs.readthedocs.io/en/latest/fsck.btrfs.html. So the expected
outcome would be:

/dev/mapper/calamares_crypt / btrfs defaults,x-systemd.growfs0   0

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 6.3-rockchip (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

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(&pss_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/

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#998705: Many 502 errors, when using apt-cacher-ng for Debian installation

[Mirco Schmidt]

On Wed, 16 Feb 2022 09:28:13 -0300 Eriberto Mota  wrote:
> Hi guys,
> 
> I am running Debian Stable (Bullseye) in my desktop and in my local server.
> 
> Yesterday I made a backport version of the apt-cacher-ng for me and I put it
> in the server. The problem seems is solved.
> 
> Regards,
> 
> Eriberto
> 
> 


Same here, while upgrading a machine to bookworm I experienced the issue. Went 
ahead and upgraded the Machine hosting ACNG first and the problem is fixed ;-)

Greetz
Mircsicz

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

[Schmidt, Bernhard]

Am Mittwoch, dem 07.06.2023 um 15:28 +0200 schrieb Bernhard Schmidt:

Hi Utkarsh,


> > > Yep, I'm taking a look to prep something for 2.5.
> > 
> > I've prepared a fix for the regression and uploaded the binaries
> > at:
> > https://people.debian.org/~utkarsh/lts/ruby2.5/
> > 
> > Can you please give these a try and see if that fixes the
> > regression you're seeing?
> 
> Looking good!

Any news here?

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

[Schmidt, Bernhard]

Am Mittwoch, dem 07.06.2023 um 18:47 +0530 schrieb Utkarsh Gupta:

Hi,

> > Yep, I'm taking a look to prep something for 2.5.
> 
> I've prepared a fix for the regression and uploaded the binaries at:
> https://people.debian.org/~utkarsh/lts/ruby2.5/
> 
> Can you please give these a try and see if that fixes the regression
> you're seeing?

Looking good!

# puppet agent --test
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
[..]


# dpkg -i libruby2.5_2.5.5-3+deb10u6_amd64.deb
(Reading database ... 69723 files and directories currently installed.)
Preparing to unpack libruby2.5_2.5.5-3+deb10u6_amd64.deb ...
Unpacking libruby2.5:amd64 (2.5.5-3+deb10u6) over (2.5.5-3+deb10u5) ...
Setting up libruby2.5:amd64 (2.5.5-3+deb10u6) ...
Processing triggers for libc-bin (2.28-10+deb10u2) ...

# puppet agent --test
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for xxx.lrz.de
Info: Applying configuration version 'master-3a083818c9e2'
Notice: Applied catalog in 3.86 seconds

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#1036738: digikam: New upstream available - 8.0

[Karl Schmidt]

Package: digikam
Version: 4:7.1.0-2
Severity: normal

Dear Maintainer,
 There is a new version that probably should be in sid these days:
https://download.kde.org/stable/digikam/8.0.0/

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
+++ l

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:
BOOT_IMAGE=/vmlinuz-6.1.0-6-amd6

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#1031200: hylafax-server: faxgetty.service doesn't work with iaxmodem

[Tino Schmidt]

Package: hylafax-server
Version: 3:6.0.7-3.1
Severity: important
X-Debbugs-Cc: debian-bu...@dc0wh17f.mooo.com

Dear Maintainer,

as mentioned in https://debianforum.de/forum/viewtopic.php?t=185052 (German, 
VERY long) there seems to be an issue with faxgetty's service unit in 
combination with the shipped udev rules of the package when hylafax is 
configured with iaxmodem.

When properly configured, iaxmodem creates a device /dev/ttyIAX which is a 
symlink to /dev/pts/. The appearance of the device does not result in an 
udev event, since events under /dev/pts/ didn't seem to be covered by udev.

The symlink is also created by iaxmodem itself. Hence, the shipped udev rules 
(/lib/udev/rules.d/60-hylafax-server.rules) do not come into action, so a line 
like
KERNEL=="ttyIAX0", SYMLINK="ttyIAX0", TAG+="systemd"
is ignored.

This is fatal, because the attached systemd-tag is necessary for creating 
device files which are required by faxgetty's systemd-unit 
(/lib/systemd/system/faxgetty@.service):

[Unit]
Description=HylaFAX faxgetty %I
BindsTo=dev-%i.device
After=dev-%i.device

So, faxgetty.service is waiting for a device that never shows up.

As a temporary workaround the BindsTo and After lines were replaced with a more 
soft dependency, so it looks like this:

[Unit]
Description=HylaFAX faxgetty %I
Wants=iaxmodem.service dev-%i.device

After that faxgetty started successfully.

Please provide a fix for this.

Thanks,
Tino


-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-21-686-pae (SMP w/1 CPU thread)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hylafax-server depends on:
ii  adduser3.118
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-2
ii  debconf [debconf-2.0]  1.5.77
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  ghostscript9.53.3~dfsg-7+deb11u2
ii  hylafax-client 3:6.0.7-3.1
ii  init-system-helpers1.60
ii  libc6  2.31-13+deb11u5
ii  libcrypt1  1:4.4.18-4
ii  libgcc-s1  10.2.1-6
ii  libjbig0   2.1-3.1+b2
ii  libpam0g   1.4.0-9+deb11u1
ii  libstdc++6 10.2.1-6
ii  libtiff-tools  4.2.0-1+deb11u3
ii  libtiff5   4.2.0-1+deb11u3
ii  lsb-base   11.1.0
ii  psmisc 23.4-2
ii  sed4.7-1
ii  systemd247.3-6
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

hylafax-server recommends no packages.

Versions of packages hylafax-server suggests:
pn  mgetty  
pn  psrip   

-- Configuration Files:
/etc/hylafax/hosts.hfaxd [Errno 13] Keine Berechtigung: 
'/etc/hylafax/hosts.hfaxd'

-- debconf information excluded

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&Paste 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&paste 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&arch=amd64&ver=11.10-1%2Bb5&stamp=1671812545&raw=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 po

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#864795: brave-less Debian

[Karl Schmidt]

On Fri, 16 Dec 2022 08:53:49 + =?UTF-8?B?RGFuaWFsIEJlaHphZGkg2K/Yp9mG24zYp9mEINio2YfYstin2K/bjA==?= 
 wrote:

Brave always looked malware to me.
Maybe that's why it's always in RFP and there's no ITP. I personally prefer a 
brave-less Debian.


I've come to think the same thing.  I suppose more than half of the 'secure' apps/programs/VPNs are really honeypots by 
the three letter guys. If you use secure setups you probably end up on a list.



--
----
Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street  Ph (785) 841-3089
Lawrence, KS 66049

Few things are more dangerous to humanity
than a failed and humiliated ruling class
that still clings to power.
-kps

Bug#1025691: atril: Segfault when opening a copy of a PDF document with annotations

[Andreas Schmidt]

Package: atril
Version: 1.26.0-2
Severity: normal

Dear Maintainer,

I used "latexmk -pdf" to create a simple PDF file from the following code:

*
\documentclass{article}
\usepackage{lipsum}

\begin{document}
\lipsum[1]
\end{document}
*

Then I used atril to add an annotation, saved the file and quit atril. Opening
the file again and selecting "File --> Open a Copy" from the menu caused a
segfault. Here's the output from running this in gdb:

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

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from atril...
Reading symbols from /usr/lib/debug/.build-
id/fc/383bf206707989cc0e0bc3eaceca8c55668ba5.debug...
(gdb) run
Starting program: /usr/bin/atril
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffecdff6c0 (LWP 309723)]
[New Thread 0x7fffe7fff6c0 (LWP 309724)]
[New Thread 0x7fffe77fe6c0 (LWP 309725)]
[New Thread 0x7fffe6ffd6c0 (LWP 309726)]
[Thread 0x7fffe6ffd6c0 (LWP 309726) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 309727)]
[New Thread 0x7fffe67fc6c0 (LWP 309728)]
[Thread 0x7fffe6ffd6c0 (LWP 309727) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 309729)]
[New Thread 0x7fffe5ffb6c0 (LWP 309730)]
[Thread 0x7fffe67fc6c0 (LWP 309728) exited]
[Thread 0x7fffe6ffd6c0 (LWP 309729) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 309731)]
[New Thread 0x7fffe67fc6c0 (LWP 309732)]
[Thread 0x7fffe5ffb6c0 (LWP 309730) exited]
[Thread 0x7fffe6ffd6c0 (LWP 309731) exited]
[Thread 0x7fffe67fc6c0 (LWP 309732) exited]
[New Thread 0x7fffe67fc6c0 (LWP 309733)]
[New Thread 0x7fffe6ffd6c0 (LWP 309734)]
[New Thread 0x7fffe5ffb6c0 (LWP 309735)]
[Thread 0x7fffe6ffd6c0 (LWP 309734) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 309736)]
[New Thread 0x7fffe57fa6c0 (LWP 309737)]
[Thread 0x7fffe5ffb6c0 (LWP 309735) exited]
[Thread 0x7fffe6ffd6c0 (LWP 309736) exited]
[Thread 0x7fffe57fa6c0 (LWP 309737) exited]
[New Thread 0x7fffe57fa6c0 (LWP 309739)]
[New Thread 0x7fffe6ffd6c0 (LWP 309740)]
[Thread 0x7fffe57fa6c0 (LWP 309739) exited]
[Thread 0x7fffe6ffd6c0 (LWP 309740) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 309742)]
[New Thread 0x7fffe57fa6c0 (LWP 309743)]
[New Thread 0x7fffe5ffb6c0 (LWP 309744)]
[New Thread 0x7fffc6c0 (LWP 309745)]
[New Thread 0x7fffcf7fe6c0 (LWP 309746)]
[New Thread 0x7fffceffd6c0 (LWP 309747)]
[New Thread 0x7fffce7fc6c0 (LWP 309748)]
[New Thread 0x7fffcdffb6c0 (LWP 309749)]
[New Thread 0x7fffcd7fa6c0 (LWP 309750)]
[Thread 0x7fffcdffb6c0 (LWP 309749) exited]
[New Thread 0x7fffcdffb6c0 (LWP 309751)]
[New Thread 0x7fffccff96c0 (LWP 309752)]
[Thread 0x7fffcd7fa6c0 (LWP 309750) exited]
[Thread 0x7fffcdffb6c0 (LWP 309751) exited]
[New Thread 0x7fffcdffb6c0 (LWP 309753)]
[New Thread 0x7fffcd7fa6c0 (LWP 309754)]
[Thread 0x7fffccff96c0 (LWP 309752) exited]
[Thread 0x7fffcdffb6c0 (LWP 309753) exited]
[New Thread 0x7fffcdffb6c0 (LWP 309755)]
[New Thread 0x7fffccff96c0 (LWP 309756)]
[Thread 0x7fffcd7fa6c0 (LWP 309754) exited]
[Thread 0x7fffcdffb6c0 (LWP 309755) exited]
[Thread 0x7fffccff96c0 (LWP 309756) exited]
[Thread 0x7fffe77fe6c0 (LWP 309725) exited]
[Thread 0x7fffe57fa6c0 (LWP 309743) exited]
[Thread 0x7fffe5ffb6c0 (LWP 309744) exited]
[Thread 0x7fffceffd6c0 (LWP 309747) exited]
[Thread 0x7fffce7fc6c0 (LWP 309748) exited]
[Thread 0x7fffc6c0 (LWP 309745) exited]
[Thread 0x7fffcf7fe6c0 (LWP 309746) exited]
[New Thread 0x7fffcf7fe6c0 (LWP 309760)]
[New Thread 0x7fffc6c0 (LWP 309761)]
[New Thread 0x7fffce7fc6c0 (LWP 309762)]
[New Thread 0x7fffceffd6c0 (LWP 309763)]
[New Thread 0x7fffe5ec96c0 (LWP 309764)]
[Thread 0x7fffceffd6c0 (LWP 309763) exited]
[New Thread 0x7fffceffd6c0 (LWP 309765)]
[New Thread 0x7fffcdffb6c0 (LWP 309766)]
[Thread 0x7fffe5ec96c0 (LWP 309764) exited]
[Thread 0x7fffceffd6c0 (LWP 309765) exited]
[New Thread 0x7fffceffd6c0 (LWP 309767)]
[New Thread 0x7fffe5ec96c0 (LWP 309768)]
[Thread 0x7fffcdffb6c0 (LWP 309766) exited]
[New Thread 0x7fffceffd6c0 (LWP 309769)]
[Thread 0x7fffceffd6c0 (LWP 309767) exited]
[New Thread 0x7fffcdffb6c0 (LWP 309770)]
[Thread 0x7fffe5ec96c0 (LWP 309768) exited]
[Thread 0x7fffceffd6c0 (LWP 309769) exited]
[Thread 0x7fffcdffb6c0 (LWP 309770) exited]

(atril:309720): Gdk-CRITICAL **: 13:57:19.180: gdk_window_get_display:
assertion 'GDK_IS_WINDOW (window)' failed

(atril:309720): Gdk-CRITICAL **: 13:57:19.180:
g

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