Bug#884713: approx: systemd's approx.socket should be configured to not have any trigger limit

[Arnaud Rebillout]

On Mon, 18 Dec 2017 16:40:40 +0100 =?utf-8?q?Rapha=C3=ABl_Hertzog?= 
 wrote:
> But IMO the default configuration should work even when you make 
heavy use
> of the package repositories... so I would like to see this in your 
default

> approx.socket. Or at least you should raise the limit to something larger
> like a few thousands requests.

To add some more context: initially systemd defaulted to « 2500 
activations per 5s », but then in v255 (commit from May 5, 2016), it 
changed to more conservative defaults of « 200 activations per 2s » when 
Accept=yes. Cf. 
https://github.com/systemd/systemd/commit/1f15ce28461ec54f85908efc063f99dc5a65b4ca.


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1034087: afl++: Include afl-clang-lto(++) in package

[Arnaud Rebillout]

Hello,

On Sat, 08 Apr 2023 13:47:19 +0200 =?utf-8?q?Jonathan_Neusch=C3=A4fer?= 
 wrote:


> Package: afl++
> Version: 4.04c-3
> Severity: wishlist
>
> Hello,
>
> the AFL++ documentation recommends using afl-clang-lto(++) if 
possible[1].

>
> Based on local tests, "PREFIX=/usr make" will produce an afl-clang-lto
> binary, if lld-14 is also installed (which should be the case, according
> to debian/rules). Not sure what's missing from the Debian package in
> order to get afl-clang-lto.
>
> Best regards,
> jn
>
>
> [1]: 
https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/fuzzing_in_depth.md#1-instrumenting-the-target 



at this point it seems that afl-clang-lto(++) are parts of the package:

    $ apt show afl++ | grep ^Version:
    Version: 4.09c-1+b1

    $ apt-file show afl++ | grep bin/afl-clang-lto
    afl++: /usr/bin/afl-clang-lto
    afl++: /usr/bin/afl-clang-lto++

Can we close this bug report then? Or did I misunderstand the bug report?

Best,

Arnaud

Bug#1067831: libaio: the t64 package slipped through and is in testing

[Arnaud Rebillout]

On 27/03/2024 7:21 pm, Guillem Jover wrote:

A binNMU would fix that, but given that no one has apparently asked
for that yet, I think instead I'll just add (later today) a compat
symlink only for the udeb for the old SONAME, because the new SONAME is
ABI compatible, but done to avoid stomping on the upstream SONAME in
case they end up merging something else or rejecting the patches, but
in d-i we do not care about backwards compatibility as long as it is
ABI compatible, then no binNMU will be needed anymore.


Thanks very much for your explanations and for the prompt upload.

I'll pick that up on Kali's side today.

Best,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1067831: libaio: the t64 package slipped through and is in testing

[Arnaud Rebillout]

Oups... https://gitlab.com/kalilinux/packages/debian-installer/-/issues/7/

Bug#1067831: libaio: the t64 package slipped through and is in testing

[Arnaud Rebillout]

I forgot to give the link to the original bug report in Kali Linux, so 
here it is: https://gitlab.com/kalilinux/packages/debian-installer/-/issues/


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1067831: libaio: the t64 package slipped through and is in testing

[Arnaud Rebillout]

Source: libaio
Version: 0.3.113-7
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

I noticed that the t64 variant of the package libaio is already in
testing. I did a quick check, and it seems that it's the only t64 package
in testing at the moment, I suppose it wasn't intentional?

$ chdist apt-file trixie search -x '/lib/.*lib[^/]+t64$'
libaio1t64: /usr/lib/x86_64-linux-gnu/libaio.so.1t64

The libaio1-udeb package is now also using the t64 lib, and it breaks
the installer ISO that is built from testing. When trying to partition
the disk using LVM, it fails, and we can see this error in the logs:

partman: pvscan: error while loading shared libraries: libaio.so.1:
  cannot open shared object file: No such file or directory
partman: vgscan: error while loading shared libraries: libaio.so.1:
  cannot open shared object file: No such file or directory
partman-lvm: vgchange: error while loading shared libraries: libaio.so.1:
  cannot open shared object file: No such file or directory

I must say that this issue was reported in the Kali Linux bugtracker
[1], as Kali is built on top of Debian testing, so our weekly images are
now broken for users who try to use LVM partitioning.

I didn't check if it _really_ affects the weekly Debian installer ISOs,
but I suppose so.

I don't know if anything can/should be done at this point, apart from
waiting for the t64 transition to complete? Or should there be a binNMU
for the d-i packages partman-*, would that fix the issue?

Any advice appreciated,

Best,

Arnaud

Bug#1061718: dpkg: Please add Kali Linux to the list of distros with a urs-merged layout

[Arnaud Rebillout]

On 07/03/2024 10:15 am, Guillem Jover wrote:

like:

   Vendor: Kali
   ...
   Show-Usrmerge-Warnings: no

versus something like:

   Vendor: Kali
   ...
   Dpkg-Suppress-Warnings: usrmerge


Rather than something centered around dpkg warnings, what about:

  Merged-Usr: yes/no

Wouldn't that be a more useful information for dpkg? Meaning: if the 
vendor declares that it uses a merged-/usr layout, then dpkg will 
suppress warnings, and maybe in the future it can do more smart things 
with this information.


Just throwing an idea in case it helps.

Cheers,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1061718: dpkg: Please add Kali Linux to the list of distros with a urs-merged layout

[Arnaud Rebillout]

Hello!

On 07/03/2024 10:15 am, Guillem Jover wrote:

Hi!

On Mon, 2024-01-29 at 11:21:32 +0700, Arnaud Rebillout wrote:

Package: dpkg
Version: 1.22.4
Severity: normal
User: de...@kali.org
Usertags: origin-kali
Kali Linux is a rolling distro based on Debian testing. We go with a
merged-usr layout for a while now, and therefore with patch away the
warning message regarding merged-usr-via-aliased-dirs. We also don't
install dpkg-fsys-usrunmess anymore, since dpkg 1.22.4.

Please find attached a patch that adds Kali to the list of distros with
a usr-merged layout, along Debian and Ubuntu.

Thanks for the patch! Sorry, it seems this has fallen through the
cracks. At the time I received this I looked into adding support for
some new field in the origins file so that then downstreams would not
need to patch dpkg at all, but got stuck with how to name it, and
whether to make it a boolean or contain a set of values for things to
not warn or similar to not make it so specific, contrast something
like:

   Vendor: Kali
   ...
   Show-Usrmerge-Warnings: no

versus something like:

   Vendor: Kali
   ...
   Dpkg-Suppress-Warnings: usrmerge

or similar. But other ideas welcome, although now that I tried to
name the suppress field, it's starting to grow on me. In any case it
seemed preferable to try to come up with a generic solution, and
assumed that as you probably had already made this change in your
distribution source, this was not urgent. But if this is the only
delta you have I'd be fine merging something like the patch that you
provided for now until a more generic solution is implemented.


What prompted me to submit a patch is that something changed in dpkg 
1.22.4, and I had to track what exactly in order to rework my patch: 
https://gitlab.com/kalilinux/packages/dpkg/-/commit/41a91264


So I thought, it I can get this upstream, that will save me the trouble 
in the future :)


This being said, there's no urgency to merge that, and we have some more 
(minor) delta in dpkg, so we need to carry a fork anyway.


As for the "best" solution, from an outsider, a field such as 
"Dpkg-Suppress-Warnings: usrmerge" looks nice and clean, and it's surely 
nice for downstreams if they can configure dpkg's behavior without 
having to fork it. But how many downstreams would use it? I can't say. 
Is it worth the cost of developing this feature? You know better than me 
how much work this feature represents.


From Kali's side, we're fine having a lightweight fork.

Best,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1037111: ITP: pipewire-module-xrdp -- xRDP module for the PipeWire sound server

[Arnaud Rebillout]

Some update on that:

* New upstream URL: https://github.com/neutrinolabs/pipewire-module-xrdp
* Latest discussion regarding including the package in Debian: 
https://github.com/neutrinolabs/pipewire-module-xrdp/issues/3


At this point it seems that this module will not be included in pipewire 
upstream, and it will be maintained by neutrinolabs (which is the 
upstream for xrdp already).


Upstream just tagged a v0.1 release, now is a good time to package it 
for Debian.


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1036214: Tracking gets confused by using copysrc on binnmu'ed packages

[Arnaud Rebillout]

For Kali Linux I just ran "reprepro retrack", which was enough to get 
rid of all the unwanted packages. The command took 15 minutes to run, 
and the Kali repo went from 806G to 439G -- not bad!


I will run this command manually every few weeks, and if it proves to be 
reliable, I will probably let cron run it once a week or something like 
that.


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1065466: fwupd-refresh: Can't start as the user is not created during package installation

[Arnaud Rebillout]

Package: fwupd
Version: 1.9.13-1
Severity: important
Tags: patch
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

Steps to reproduce: on a clean Debian sid system, install fwupd, then
try to start the fwupd-refresh service. It fails with:

```
systemd[1]: Starting fwupd-refresh.service - Refresh fwupd metadata and update 
motd...
(fwupdmgr)[3669]: fwupd-refresh.service: Failed to determine user credentials: 
No such process
systemd[1]: fwupd-refresh.service: Main process exited, code=exited, 
status=217/USER
systemd[1]: fwupd-refresh.service: Failed with result 'exit-code'.
systemd[1]: Failed to start fwupd-refresh.service - Refresh fwupd metadata and 
update motd.
```

The issue is that the fwupd-refresh user doesn't exist,  as can be seen
with `grep fwupd /etc/passwd`.

The bug was introduced with commit 6e3af79c on 2023-10-06, where the
adduser command in the fwupd.postinst was dropped, and instead a file
/usr/lib/sysusers.d/fwupd.conf was introduced.

However it's not enough to install a drop-in file in sysusers.d/, one
must also call systemd-sysusers in the postinst script, which is
achieved thanks to dh_installsysusers.

Please find the fix at:

https://salsa.debian.org/efi-team/fwupd/-/merge_requests/14

Thanks,

Arnaud

Bug#1060459: scalpel: Scalpel not working on Apple Silicon

[Arnaud Rebillout]

Hello, and thanks for reaching out!

On Thu, 11 Jan 2024 13:44:03 -0600 "Golden G. Richard III" 
 wrote:


> I have placed updated source distros for Scalpel 1.60 as well as the
> newer (and more powerful) Scalpel 2.02 on GitHub via
> https://github.com/nolaforensix/scalpel-1.60 and
> https://github.com/nolaforensix/scalpel-2.02. My recommendation is to
> rebuild the 1.60 package from the updated source and also consdering
> adding 2.02.

I have updated the package to latest commit on 
https://github.com/nolaforensix/scalpel-1.60.


I will consider packaging the 2.02 when I have a bit of time, this week 
or next week hopefully.


Best,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1033894: lintian: bad-distribution-in-changes-file bookworm

[Arnaud Rebillout]

On Tue, 28 Nov 2023 13:00:00 -0700 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
 wrote:


> The fix for this issue is still only in git at
> 
https://salsa.debian.org/lintian/lintian/-/commit/ebb739d102d55797516c0f10452e4e4c2502644d

> and there has not been any new Lintian uploads since Lintian 2.116.3
> in February 2023.
>
> Anybody maintaining packages in Bookworm and using Salsa-CI is bound
> to hit on hard failure as Lintian will error on this one. Example
> https://salsa.debian.org/otto/mariadb-server/-/jobs/4976386:
>
> E: mariadb changes: bad-distribution-in-changes-file bookworm


The fix was released in lintian 2.117.0. But unless it's backported to 
bookworm, the problem you highlighted remains.


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1061718: dpkg: Please add Kali Linux to the list of distros with a urs-merged layout

[Arnaud Rebillout]

Here's the patchFrom 68fcfefd5ce34d4423d5a6b9e23ad4a4ec620378 Mon Sep 17 00:00:00 2001
From: Arnaud Rebillout 
Date: Mon, 29 Jan 2024 11:12:02 +0700
Subject: [PATCH] Add Kali to the list of distros with a merged-usr layout

---
 debian/bug-script| 4 
 debian/dpkg.postinst | 4 
 debian/rules | 2 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/bug-script b/debian/bug-script
index 92b933da1..c690b12b6 100644
--- a/debian/bug-script
+++ b/debian/bug-script
@@ -30,6 +30,10 @@ check_merged_usr_via_aliased_dirs()
 # Ubuntu does not seem interested in it.
 return
 ;;
+  kali)
+# Kali neither.
+return
+;;
   esac
 
   for d in /bin /sbin /lib /lib32 /libo32 /libx32 /lib64; do
diff --git a/debian/dpkg.postinst b/debian/dpkg.postinst
index 113c8d53a..becfaafc8 100644
--- a/debian/dpkg.postinst
+++ b/debian/dpkg.postinst
@@ -39,6 +39,10 @@ check_merged_usr_via_aliased_dirs()
 # Ubuntu does not seem interested in it.
 return
 ;;
+  kali)
+# Kali neither.
+return
+;;
   esac
 
   for d in /bin /sbin /lib /lib32 /libo32 /libx32 /lib64; do
diff --git a/debian/rules b/debian/rules
index f4b923542..0f56f4b0d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -89,7 +89,7 @@ override_dh_bugfiles:
 override_dh_compress:
 	dh_compress -Xspec/
 
-ifeq (,$(filter $(DEB_VENDOR),Debian Ubuntu))
+ifeq (,$(filter $(DEB_VENDOR),Debian Kali Ubuntu))
 execute_after_dh_install:
 	dh_install -pdpkg usr/sbin/dpkg-fsys-usrunmess
 
-- 
2.43.0

Bug#1061718: dpkg: Please add Kali Linux to the list of distros with a urs-merged layout

[Arnaud Rebillout]

Package: dpkg
Version: 1.22.4
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Guillem,

Kali Linux is a rolling distro based on Debian testing. We go with a
merged-usr layout for a while now, and therefore with patch away the
warning message regarding merged-usr-via-aliased-dirs. We also don't
install dpkg-fsys-usrunmess anymore, since dpkg 1.22.4.

Please find attached a patch that adds Kali to the list of distros with
a usr-merged layout, along Debian and Ubuntu.

Thanks for your consideration,

Arnaud

Bug#1054823: starlette: FTBFS: tests failed

[Arnaud Rebillout]

The build failure is due to the library python3-httpx. This library uses 
python3-rfc3986, it's been upgraded lately [1], and it's now causing the 
breakage.


There's a discussion about this issue upstream [2]. If we bump src:httpx 
to version 0.24.0, the dependency on python3-rfc3986 goes away, and the 
problem will be fixed.


Looking at src:httpx now: Debian has 0.23.3-1, we need at least 0.24, 
and  upstream is at 0.25.2.


  $ build-rdeps python3-httpx
  Reverse Build-depends in main:
  --

  aioxmlrpc
  asgi-csrf
  asgi-lifespan
  dnspython
  fastapi
  greenbone-feed-sync
  nala
  ormar
  pontos
  python-a2wsgi
  python-authlib
  python-cobra
  python-duckpy
  python-falcon
  python-gvm
  python-tiny-proxy
  python-truststore
  python-uvicorn
  sqlmodel
  starlette

Since I'm not involved in Python packaging, I don't feel comfortable 
doing this upgrade.


Best,

Arnaud

[1]: https://tracker.debian.org/pkg/python-rfc3986

[2]: https://github.com/encode/starlette/discussions/1879

On Fri, 27 Oct 2023 21:48:44 +0200 Lucas Nussbaum  wrote:

> Source: starlette
> Version: 0.31.1-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231027 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > debian/rules build
> > dh build --with python3 --buildsystem=pybuild
> > dh_update_autotools_config -O--buildsystem=pybuild
> > dh_autoreconf -O--buildsystem=pybuild
> > dh_auto_configure -O--buildsystem=pybuild
> > dh_auto_build -O--buildsystem=pybuild
> > I: pybuild plugin_pyproject:110: Building wheel for python3.11 with 
"build" module
> > I: pybuild base:310: python3.11 -m build --skip-dependency-check 
--no-isolation --wheel --outdir 
/<>/.pybuild/cpython3_3.11_starlette

> > * Building wheel...
> > Successfully built starlette-0.31.1-py3-none-any.whl
> > I: pybuild plugin_pyproject:122: Unpacking wheel built for 
python3.11 with "installer" module

> > dh_auto_test -O--buildsystem=pybuild
> > I: pybuild base:310: cd 
/<>/.pybuild/cpython3_3.11_starlette/build; python3.11 -m 
pytest tests
> > = test session starts 
==

> > platform linux -- Python 3.11.6, pytest-7.4.3, pluggy-1.3.0
> > rootdir: /<>/.pybuild/cpython3_3.11_starlette/build
> > configfile: pyproject.toml
> > plugins: anyio-3.7.0
> > collected 420 items
> >
> > tests/test__utils.py .. [ 1%]
> > tests/test_applications.py .FF.FFF..F.FFF..F. [ 7%]
> > tests/test_authentication.py .FF.FF [ 9%]
> > tests/test_background.py  [ 10%]
> > tests/test_concurrency.py .F [ 10%]
> > tests/test_config.py  [ 11%]
> > tests/test_convertors.py FFF [ 12%]
> > tests/test_datastructures.py .. [ 17%]
> > tests/test_endpoints.py FFF... [ 19%]
> > tests/test_exceptions.py .FF.F [ 22%]
> > tests/test_formparsers.py ..F [ 31%]
> > tests/test_requests.py FFF...FFF.FF.F.FF. [ 
41%]

> > tests/test_responses.py FF. [ 48%]
> > tests/test_routing.py 
FF..FF.FF.FF.F.F.FF..F.F.F..FFF..FFF.. [ 60%]

> > .. [ 60%]
> > tests/test_schemas.py .F [ 61%]
> > tests/test_staticfiles.py FFF.FFF.FF.. [ 68%]
> > tests/test_status.py .. [ 68%]
> > tests/test_templates.py ..F.FF [ 71%]
> > tests/test_testclient.py F.F..FF.FFF [ 76%]
> > tests/test_websockets.py  [ 84%]
> > tests/middleware/test_base.py FF....FF..FF [ 89%]
> > tests/middleware/test_cors.py FFF [ 93%]
> > tests/middleware/test_errors.py .F [ 94%]
> > tests/middleware/test_gzip.py F [ 95%]

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1035061: gnome-keyring: prevents chrome/chromium from running on a new account's first run

[Arnaud Rebillout]

I reported the issue upstream: 
https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/137

Bug#1035061: gnome-keyring: prevents chrome/chromium from running on a new account's first run

[Arnaud Rebillout]

th_login: closing: 
/home/kali/.local/share/keyrings/user.keystore


We can see that there's one more created object on first boot, with a 
label of "Login".


So it looks to me that, on first boot, the gnome-keyring-daemon creates 
the login keyring, however the change is not published on the bus.  And 
after looking at the code a few hours, it doesn't look like there's a 
one-line fix, rather it looks like the scenario of updating the 
collections on the bus is not supported (my reading of the code, might 
be wrong).


One additional detail: you'd think that a restart of 
gnome-keyring-daemon is enough to fix it, but not exactly. If I restart 
it (via systemd --user), and then I start chromium, GNOME prompts me for 
my password, saying "The login keyring did not get unlocked when you 
logged into your computer". However I can just click cancel, and then 
chromium proceeds and starts successfully.


--
Arnaud Rebillout / OffSec / Kali Linux Developer

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

[Arnaud Rebillout]

Source: bind9
Version: 1:9.19.17-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

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!

Thanks in advance,

Arnaud

Bug#1056592: debos: yaml: line X: did not find expected key

[Arnaud Rebillout]

On 24/11/2023 17:50, Christopher Obbard wrote:

Oh, turns out I completely forgot about that. I think it makes sense to
release a new upstream Debos version, import that into Debian and drop your
merge request. I will do that today.


Thanks for the quick fix Christopher! Have a nice week-end,

Arnaud

Bug#1056592: debos: yaml: line X: did not find expected key

[Arnaud Rebillout]

Hello Christopher,

On 23/11/2023 23:45, Christopher Obbard wrote:

For me with debos 1.1.2-2, I seem to reproduce your issue:

   Running /debos --artifactdir debos-tests --template-var 'ospack:"debian"'
debos-tests/test-key.yaml using kvm backend
   2023/11/23 16:41:30 yaml: line 7: did not find expected key


Good to hear, I'm not alone!


But with a local checkout of debos upstream built with `go build`, your recipe
runs just fine (notice there are now no single-quotes around the --template-
var argument to the inner debos call):

   Running /debos --artifactdir debos-tests --template-var ospack:debdfsa
debos-tests/test-key.yaml using kvm backend
   2023/11/23 16:41:46  debootstrap 


I think this has something to do with the recent shell escaping patches.
Perhaps there is some go module which isn't up to date in Debian causing the
additional single quotation marks around the inner debos call ?


Indeed, the package golang-github-alessio-shellescape is not exactly at 
the last version in Debian, we have 1.4.1, upstream is at 1.4.2.


However, after updating it, and rebuilding the fakemachine package, and 
then rebuilding debos, I still have the same error.


After digging a bit more, I found that Sjoerd added a few commits to 
debos, just after release 1.1.2. Those commits are needed if fakemachine 
0.0.7 is used, and I can confirm that the issue is fixed by importing 
those commits. Cf: 
https://salsa.debian.org/go-team/packages/debos/-/merge_requests/5


Packaging sidenote: please push your pristine-tar branch (or disable it 
in debian/gbp.conf), at the moment "gbp buildpackage" fails because of that.


Thanks!

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1056592: debos: yaml: line X: did not find expected key

[Arnaud Rebillout]

Package: debos
Version: 1.1.2-2
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Hi Christopher,

Here's a surprising bug report. The version of debos currently in Debian
unstable is a bit broken, in an odd way.

Consider the following recipe:

```
$ cat main.yaml
{{ $ospack := or .ospack "debian" }}
architecture: amd64
actions:
  - action: debootstrap
suite: sid
  - action: pack
file: {{ $ospack }}.tar.gz
```

If I run with `-t ospack:debian` it fails:

```
$ debos --print-recipe -t ospack:debian main.yaml
2023/11/23 23:05:27 Recipe '/home/user/debos/main.yaml':
2023/11/23 23:05:27
architecture: amd64
actions:
  - action: debootstrap
suite: sid
  - action: pack
file: debian.tar.gz
Running /debos --artifactdir /home/user/debos --template-var 'ospack:"debian"' 
/home/user/debos/main.yaml using kvm backend
2023/11/23 16:05:31 yaml: line 6: did not find expected key
```

However if I run without `-t`, it succeeds:

```
$ debos --print-recipe main.yaml
2023/11/23 23:10:55 Recipe '/home/user/debos/main.yaml':
2023/11/23 23:10:55
architecture: amd64
actions:
  - action: debootstrap
suite: sid
  - action: pack
file: debian.tar.gz
Running /debos --artifactdir /home/user/debos /home/user/debos/main.yaml using 
kvm backend
2023/11/23 16:10:59  debootstrap 
2023/11/23 16:10:59 Debootstrap | I: Target architecture can be executed
2023/11/23 16:10:59 Debootstrap | I: Retrieving InRelease
[...]
```

Another surprise: this is a regression introduced by package 1.1.2-2. If
I downgrade to version 1.1.2-1, everything works fine.

```
sudo apt install --allow-downgrades ./debos_1.1.2-1_amd64.deb
```

I compared the Built-Using fields between both packages:

```
-golang-1.21 (= 1.21.1-1)
+golang-1.21 (= 1.21.4-1)
+golang-github-alessio-shellescape (= 1.4.1-3)
 golang-github-cespare-xxhash (= 2.1.1-2)
 golang-github-docker-go-units (= 0.4.0-4)
-golang-github-go-debos-fakemachine (= 0.0.6-1)
+golang-github-go-debos-fakemachine (= 0.0.7-1)
 golang-github-google-uuid (= 1.3.0-1)
-golang-github-klauspost-compress (= 1.15.12+ds1-3)
+golang-github-klauspost-compress (= 1.17.2+ds1-1)
 golang-github-sjoerdsimons-ostree-go (= 0.0~git20201014.8fae757-2)
 golang-github-surma-gocpio (= 1.1.0+git20160926.fcb6877-1.1)
 golang-github-ulikunitz-xz (= 0.5.6-2)
 golang-go-flags (= 1.4.0-6)
-golang-golang-x-sys (= 0.9.0-1)
+golang-golang-x-sys (= 0.13.0-1)
 golang-gopkg-freddierice-go-losetup.v1 (= 0.0~git20170407.fc9adea-1.1)
 golang-yaml.v2 (= 2.4.0-4)
```

I suppose the regression was introduced by one of the dependencies that
changed. I have no idea how to troubleshot that... Tomorrow I'll try to
rebuild a package to see if that magically fixes it.

Can you try to reproduce this issue on your side, just to confirm?

Thanks in advance,

Arnaud


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

Kernel: Linux 6.5.0-4-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 debos depends on:
ii  busybox1:1.36.1-4
ii  debootstrap1.0.133
ii  libc6  2.37-12
ii  libglib2.0-0   2.78.1-4
ii  libostree-1-1  2023.7-3
ii  qemu-system-x861:8.1.2+ds-1
ii  qemu-user-static   1:8.1.2+ds-1
ii  systemd-container  255~rc2-1

Versions of packages debos recommends:
ii  bmap-tools 3.7-1
ii  bzip2  1.0.8-5+b1
ii  dosfstools 4.2-1
ii  e2fsprogs  1.47.0-2+b1
ii  fdisk  2.39.2-6
ii  linux-image-amd64  6.5.10-1
ii  mount  2.39.2-6
ii  ovmf   2023.05-2
ii  parted 3.6-3
ii  systemd-resolved   255~rc2-1
ii  udev   255~rc2-1
ii  xz-utils   5.4.4-0.1
ii  zip3.0-13

Versions of packages debos suggests:
pn  libslirp-helper  
pn  user-mode-linux  

-- no debconf information

Bug#1055039: redis-server: Crash every two hours (oom), seemingly due to systemd's ProcSubset=pid

[Arnaud Rebillout]

On 02/11/2023 21:31, Chris Lamb wrote:

Chris Lamb wrote:

D'oh, of course! As you might have guessed, I had a "brain typo" and
had completely forgotten that stable = bookworm (and not bullseye).
I'll get onto this presently.

This has been filed as #1055229.


Thanks very much Chris !

Best,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1055039: redis-server: Crash every two hours (oom), seemingly due to systemd's ProcSubset=pid

[Arnaud Rebillout]

Ola Chris!

On 02/11/2023 02:00, Chris Lamb wrote:

I just had a good look and ProcSubset=pid does not exist in redis in
stable, so no backport or update needed. (That's good, because updating
stable is a not completely straightforward.)


What do you mean with 'stable'? ProcSubset=pid definitely exists in 
bookworm, and that's debian stable.


By 'exists' I mean the setting exists in systemd (was introduced in 
version 247), and it's set in the redis service file:


  $ apt policy redis
  redis:
    Installed: 5:7.0.11-1
    Candidate: 5:7.0.11-1
    Version table:
   *** 5:7.0.11-1 500
      500 http://deb.debian.org/debian bookworm/main amd64 Packages
          500 mirror+file:/etc/apt/mirrors/debian.list bookworm/main 
amd64 Packages

      100 /var/lib/dpkg/status

This version of redis is what's in stable:

  $ rmadison redis | grep -w stable
  redis  | 5:7.0.11-1 | stable    | source, all

Am I missing something?



Glad that we (well, you!) managed to solve this problem and thanks for
passing it on. :)


No worries, thanks for your quick feedback. BTW I opened minor MRs in 
Salsa, but CI fails (unrelated), not sure you receive any notification 
for those. Nothing pressing though.


Cheers,

Arnaud

Bug#1055152: ca-certificates: Certificates from Sectigo Limited are not trusted

[Arnaud Rebillout]

Package: ca-certificates
Version: 20230311
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

  # wget https://mirror1.sox.rs/
  --2023-11-01 10:39:21--  https://mirror1.sox.rs/
  Resolving mirror1.sox.rs (mirror1.sox.rs)... 88.218.137.65, 2a09:ab81::65
  Connecting to mirror1.sox.rs (mirror1.sox.rs)|88.218.137.65|:443... connected.
  ERROR: The certificate of 'mirror1.sox.rs' is not trusted.
  ERROR: The certificate of 'mirror1.sox.rs' doesn't have a known issuer.

However, opening the page in Firefox, no problem, apparently Mozilla is
happy with this certificate, please check: https://mirror1.sox.rs/

At this point I must admit I know very little about the package
ca-certificates, but from a quick glance, according to README.Debian, it
looks like ca-certificates should be in line with Mozilla's trusted
certificates?

Looking online, https://wiki.mozilla.org/CA/Included_Certificates took
me to
https://ccadb.my.salesforce-sites.com/mozilla/IncludedCACertificateReport
which list Sectigo. However the Certificate Issuer Organization changed
from Comodo to Sectigo, Valid From 2021.03.22.

So maybe it's just that ca-certificates needs an update?

Thanks!

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

Kernel: Linux 6.5.0-3-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 ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  openssl3.0.12-1

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information:
  ca-certificates/trust_new_crts: yes
  ca-certificates/title:
  ca-certificates/enable_crts: mozilla/ACCVRAIZ1.crt, 
mozilla/AC_RAIZ_FNMT-RCM.crt, mozilla/AC_RAIZ_FNMT-RCM_SERVIDORES_SEGUROS.crt, 
mozilla/Actalis_Authentication_Root_CA.crt, mozilla/AffirmTrust_Commercial.crt, 
mozilla/AffirmTrust_Networking.crt, mozilla/AffirmTrust_Premium.crt, 
mozilla/AffirmTrust_Premium_ECC.crt, mozilla/Amazon_Root_CA_1.crt, 
mozilla/Amazon_Root_CA_2.crt, mozilla/Amazon_Root_CA_3.crt, 
mozilla/Amazon_Root_CA_4.crt, mozilla/ANF_Secure_Server_Root_CA.crt, 
mozilla/Atos_TrustedRoot_2011.crt, 
mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068_2.crt, 
mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, 
mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_Root_CA.crt, 
mozilla/Buypass_Class_3_Root_CA.crt, mozilla/CA_Disig_Root_R2.crt, 
mozilla/Certainly_Root_E1.crt, mozilla/Certainly_Root_R1.crt, 
mozilla/Certigna.crt, mozilla/Certigna_Root_CA.crt, 
mozilla/certSIGN_ROOT_CA.crt, mozilla/certSIGN_Root_CA_G2.crt, 
mozilla/Certum_EC-384_CA.crt, mozilla/Certum_Trusted_Network_CA_2.crt, 
mozilla/Certum_Trusted_Network_CA.crt, mozilla/Certum_Trusted_Root_CA.crt, 
mozilla/CFCA_EV_ROOT.crt, mozilla/Comodo_AAA_Services_root.crt, 
mozilla/COMODO_Certification_Authority.crt, 
mozilla/COMODO_ECC_Certification_Authority.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/DigiCert_Assured_ID_Root_CA.crt, 
mozilla/DigiCert_Assured_ID_Root_G2.crt, 
mozilla/DigiCert_Assured_ID_Root_G3.crt, mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_Global_Root_G2.crt, mozilla/DigiCert_Global_Root_G3.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, 
mozilla/DigiCert_TLS_ECC_P384_Root_G5.crt, 
mozilla/DigiCert_TLS_RSA4096_Root_G5.crt, mozilla/DigiCert_Trusted_Root_G4.crt, 
mozilla/D-TRUST_BR_Root_CA_1_2020.crt, mozilla/D-TRUST_EV_Root_CA_1_2020.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_2009.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_EV_2009.crt, 
mozilla/emSign_ECC_Root_CA_-_C3.crt, mozilla/emSign_ECC_Root_CA_-_G3.crt, 
mozilla/emSign_Root_CA_-_C1.crt, mozilla/emSign_Root_CA_-_G1.crt, 
mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, 
mozilla/Entrust_Root_Certification_Authority.crt, 
mozilla/Entrust_Root_Certification_Authority_-_EC1.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G2.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G4.crt, 
mozilla/ePKI_Root_Certification_Authority.crt, 
mozilla/e-Szigno_Root_CA_2017.crt, mozilla/E-Tugra_Certification_Authority.crt, 
mozilla/E-Tugra_Global_Root_CA_ECC_v3.crt, 
mozilla/E-Tugra_Global_Root_CA_RSA_v3.crt, mozilla/GDCA_TrustAUTH_R5_ROOT.crt, 
mozilla/GlobalSign_ECC_Root_CA_-_R4.crt, 
mozilla/GlobalSign_ECC_Root_CA_-_R5.crt, mozilla/GlobalSign_Root_CA.crt, 
mozilla/GlobalSign_Root_CA_-_R3.crt, mozilla/GlobalSign_Root_CA_-_R6.crt, 
mozilla/GlobalSign_Root_E46.crt, mozilla/GlobalSign_Root_R46.crt, 
mozilla/GLOBALTRUST_2020.crt, mozilla/Go_Daddy_Class_2_CA.crt, 
mozilla/Go_Daddy_Root_Certificate_Authority_-_G2.crt, mozilla/GTS_Root_R1.crt, 
mozilla/GTS_Root_R2.crt, mozilla/GTS_Root_R3.crt, mozilla/GTS_Root_R4.crt, 
mozilla/HARICA_TLS_ECC_Root_CA_2021.crt, 

Bug#1055039: redis-server: Crash every two hours (oom), seemingly due to systemd's ProcSubset=pid

[Arnaud Rebillout]

On 31/10/2023 22:36, Chris Lamb wrote:

tags 1055039 + pending
thanks

Hey Arnaud!


Long story below.

A huge thanks for tracking this down! I've gone ahead and removed
ProcSubset=pid from the systemd unit files, and am uploading a version
to unstable and experimental right now. However, do you think this
warrants an update to stable as well…? Thanks again.


I would say yes, upload to stable as well. At least for our use-case, it 
makes Redis unusable, that's pretty bad. I wish I could tell you more 
precisely what goes wrong in our case though...


I checked a bit more in the redis source code, to find reference to 
/proc (and not /proc/self):


  $ find -name '*.[ch]' | xargs grep -ho '[ "]/proc/[^ "]*' \
    | grep -v /self/ | tr -d ' ",.' |  sort | uniq -c
  1 /proc/cpuinfo
  1 /proc/curproc/map
  1 /proc/%d/maps
  1 /proc/%d/task/%d/maps
  1 /proc/%ld/psinfo
  1 /proc/%ld/smaps
  1 /proc//stat
  3 /proc/sys/net/core/somaxconn
  1 /proc/sys/net/ipv4/tcp_tw_reuse'
  8 /proc/sys/vm/overcommit_memory

To me, it suggests that yes, Redis needs full access to /proc to be 
fully functional.


Moreover, I see that ProcSusbset=pid caused some trouble already, that 
you fixed in 80470e3dc0ae56db9c9512c38a175783bcfc ;)


Looking at the part of the code that was touched by this patch, I see 
that Redis checks whether overcommit memory is enabled (function 
checkOvercommit), and it displays a big fat warning if ever it's not. I 
suppose that, with ProcSubset=pid, Redis won't be able to perform this 
check and won't be able to display this warning.


So, yep, I still think that it's better to backport this change to 
stable. If ever someone needs to re-enable ProcSubset=pid, maybe it will 
need more care. Better reach out to upstream to ask whether it's a good idea


Thank you very much for maintaining this package!

--

Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1055039: redis-server: Crash every two hours (oom), seemingly due to systemd's ProcSubset=pid

[Arnaud Rebillout]

Package: redis-server
Version: 5:7.0.11-1
Severity: important
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

After migrating an instance from bullseye to bookworm, redis started to
crash every 2 hours. I tracked it to a change in the system unit file,
the value ProcSubset=pid is what causes the issue.

Long story below.

Part of the Kali Linux infrastructure, we have a host that runs
mirrorbits, a geo redirector. Mirrorbits stores its data in a redis
database.

Some quick numbers:

```
# free -h
 total  used  free  shared  buff/cache  available
Mem:  61Gi  24Gi  13Gi   612Ki22Gi   37Gi
Swap:   0B0B0B

# redis-cli info | grep -E '(used_memory_(peak_)?human)'
used_memory_human:22.94G
used_memory_peak_human:23.24G
```

This instance is managed with Ansible. Not in producion yet.

It was running fine with Debian bullseye, then we re-deployed it on a
bookworm VM. On this new host, Redis crashes every two hours roughly:

```
# journalctl | grep redis | grep code=killed | tail
Oct 28 14:58:30 host systemd[1]: redis.service: Main process exited, 
code=killed, status=11/SEGV
Oct 28 16:44:24 host systemd[1]: redis.service: Main process exited, 
code=killed, status=11/SEGV
Oct 28 18:49:49 host systemd[1]: redis.service: Main process exited, 
code=killed, status=11/SEGV
Oct 28 21:07:28 host systemd[1]: redis.service: Main process exited, 
code=killed, status=11/SEGV
Oct 28 22:54:32 host systemd[1]: redis.service: Main process exited, 
code=killed, status=11/SEGV
Oct 29 00:39:06 host systemd[1]: redis.service: Main process exited, 
code=killed, status=11/SEGV
Oct 29 02:43:30 host systemd[1]: redis.service: Main process exited, 
code=killed, status=11/SEGV
```

Looking at the Redis log files, we see this kind of line, repeated
hundreds of times within a few seconds, before Redis finally crashes:

```
8:M 15 Oct 2023 01:55:55.811 # Out Of Memory allocating 24576 bytes!
```

First thing I did was to disable the RDB snapshot (set every hours in
our config), just to make sure it was not related. It was not, Redis
kept crashing.

Redis RAM usage is rather constant for us (from 22G to 24G), and on this
machine there's only mirrorbits+redis running. There's plenty of RAM
available, I monitored the RAM during a crash, and `free` reports around
37G of RAM available. So I don't think we're running out of RAM.

I checked what changed in the Redis package, between bullseye and
bookworm, and this commit stands out:

d/redis-server.service: harden systemd service file
https://salsa.debian.org/lamby/pkg-redis/-/commit/8fec88c1

I tried to revert the systemd unit file to the bullseye version, and
Redis worked again, no more crash. From there I re-enabled the changes
one by one, until I found the setting that causes the crash:

ProcSubset=pid

I'm not really knowledgeable regarding systemd hardening, but after
reading the doc, it seems pretty clear that this setting is
questionable, and probably shouldn't be enabled.

Quoting systemd.exec(5)`:

If "pid", all files and directories not directly associated with process
management and introspection are made invisible in the /proc/ file
system configured for the unit's processes. [...] Note that Linux
exposes various kernel APIs via /proc/, which are made unavailable with
this setting. Since these APIs are used frequently this option is useful
only in a few, specific cases, and is not suitable for most non-trivial
programs.

At this point I think there's enough information to support disabling
ProcSubset=pid. Please tell me if you need more information, since the
issue is reproducible, it's easy for me to provide more logs.

Thanks in advance!

Arnaud

Bug#1036256: golang-github-pin-tftp: FTBFS in testing

[Arnaud Rebillout]

On Mon, 18 Sep 2023 09:23:19 -0300 Thiago Andrade  
wrote:

> I'm waiting for this upgrade. After I'll try to upgrade gobuster to
> 3.6.0 version.

Hello Thiago,

the new package was uploaded and is now in unstable.

However, after manually triggering the autopkgtests two times, I noticed 
that a test failed (2 times, on a different architecture each time, cf 
ppc64el and riscv64 logs at [1]). So it still looks like a test is 
flaky, or maybe there's a bug in the code. I pinged upstream to see if 
they can help [2].


Cheers,

Arnaud

--

[1] https://ci.debian.net/packages/g/golang-github-pin-tftp/

[2] https://github.com/pin/tftp/issues/87

Bug#1052387: geoipupdate: Please add dependency on ca-certificates

[Arnaud Rebillout]

On 21/09/2023 17:23, Faidon Liambotis wrote:

Thanks so much for taking the time to report this! That's a good point.
I pushed a commit in git that adds such a dependency. I'll work on a
couple more issues, and wait for a few days to see if anything more
accumulates, then upload a new version.

Let me know if you find any more issues. I don't use this package much
these days, so I could always hear more from users!


Well, there's not much to say, geoipupdate works flawlessly for me :)

Thanks for maintaining it! Have a nice day,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1052387: geoipupdate: Please add dependency on ca-certificates

[Arnaud Rebillout]

Package: geoipupdate
Version: 6.0.0-1
Severity: normal

Dear Maintainer,

geoipupdates talks to MaxMind servers over HTTPS, so it needs the
package ca-certificates to be functional. Otherwise:

  $ geoipupdate -v
  geoipupdate version 4.6.0
  Using config file /etc/GeoIP.conf
  Using database directory /var/lib/GeoIP
  Performing get filename request to 
https://updates.maxmind.com/app/update_getfilename?product_id=GeoLite2-ASN
  
  ... wait a few minutes here, nothing happens ...

  error retrieving updates: error retrieving filename for GeoLite2-ASN:
  error performing HTTP request: Get 
"https://updates.maxmind.com/app/update_getfilename?product_id=GeoLite2-ASN":
  x509: certificate signed by unknown authority

Thanks,

Arnaud

Bug#1036256: golang-github-pin-tftp: FTBFS in testing

[Arnaud Rebillout]

I tried to rebuild the package locally, works for me. Tried to run 
autopkgtests in GitLab CI: worked [1]. It hints at flaky tests indeed...


I noticed that in Debian we package 2.2.0, however upstream is at 
version 3.0.0, with significant changes.


We have only two reverse build-deps: gobuster and ignition.

1) gobuster already uses pin-tftp 3.0

2) ignition seems to use an older version of pin-tftp, but I could 
rebuild it with pin-tftp 3.0 successfully


So I'm going to upload version 3.0 of pin-tftp, and I'll check if builds 
and autopkgtests succeed with this new version.


--

[1]: https://gitlab.com/arnaudr/golang-github-pin-tftp/-/jobs/5108371487

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1018873: Works for me

[Arnaud Rebillout]

On Fri, 25 Aug 2023 22:38:03 +0200 Roland Clobus  wrote:
> Control: tags 1018873 +pending
>
> I've tried the following with the latest version from git:
>
> lb config --firmware-chroot true --archive-areas "main contrib non-free"
> --distribution sid
>
> lb config --firmware-chroot true --archive-areas main contrib non-free
> non-free-firmware --distribution sid --debian-installer live
>
> Both variants work for me, they will build an image without errors.


I tried the command:

  # apt install nvidia-tesla-470-alternative nvidia-tesla-alternative

in a bookworm and in a sid container. Works in both cases.

It seems to me that the issue was fixed in the 
nvidia-graphics-drivers-tesla-470  package a while ago, maybe commit 
7aca87283c58d77dd88c52f645101f8428707464


We had some workaround in place for this issue in Kali. I will remove 
those workarounds, so if there's still a problem I will know it immediately.


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1049418: xfce4-pulseaudio-plugin: Please loosen Recommends, and allow pipewire-pulse as an alternative to pulseaudio

[Arnaud Rebillout]

On 08/09/2023 14:13, Yves-Alexis Perez wrote:

On Fri, 2023-09-08 at 10:53 +0700, Arnaud Rebillout wrote:
> Hope that it answers all your questions!

Hi Arnaud, thanks for the very detailed information, that's much 
helpful. And

it does make sense to use alternate dependencies indeed.

But here there might be some differences. In your initial mail you say:

> A minor issue, in Kali, is that we still have to install pulseaudio, due
> to the fact that xfce4-pulseaudio-plugin depends on pulseaudio. So
> pulseaudio must be installed, even though it's not running.

> On the same line, we also can't install the metapackage pipewire-audio,
> since it Conflicts with pulseaudio, hence breaks the xfce4 metapackage.

> Changing the Recommends field of xfce4-pulseaudio-plugin to
> 'pulseaudio|pipewire-pulse' would solve those two issues, and more
> generally it would make life easier for people who want to switch to
> pipewire and remove pulseaudio.

I don't think that's completely true. Recommends: can (and are, on 
Debian at
least) installed by default (when doing apt install or apt-get 
install) but

you can totally remove it afterwards.

So I guess the only relevant use case is when a user
- has pipewire-pulse installed
- has *not* pulseaudio installed
- runs apt install xfce4-pulseaudio-plugin (or xfce4-plugins)

In that case, with the alternate recommends I'd assume it would 
consider the

recommends already satisfied and won't try to install pulseaudio.


I believe you are correct on that, 100% agree.



I don't think that's really what Kali is concerned about, but rather the
default installation.


So the issue we had in Kali was a bit different, I didn't go into the 
full details as I didn't want to bore you, but since we are here, let me 
try to explain.


Ideally, for the Kali XFCE desktop (implemented by the metapackage 
kali-desktop-xfce), I would like to depend on pipewire-audio. 
pipewire-audio is a metapackage that « depends on a recommended set of 
pipewire packages
 for a standard audio desktop use ». It's maintained by the pipewire 
maintainers: they know best what packages are needed for a working 
pipewire audio setup (and btw, gnome-core depends on pipewire-audio, ie. 
they fully embraced pipewire).


However I could not do that, I couldn't depend on pipewire-audio. The 
issue is that pipewire-audio Conflicts/Replaces pulseaudio (due to some 
of its dependencies that are really NOT co-installable with pulseaudio). 
This is problematic for the upgrade scenario: all Kali XFCE users 
already have pulseaudio installed. So what would happen on apt full-upgrade?


What I found during my tests is that, if I make kali-desktop-xfce 
depends on pipewire-audio, "apt full-upgrade" will NOT completely 
upgrade the system. It refuses to remove the pulseaudio package 
automatically, therefore can't install pipewire-audio, and then the 
package "kali-desktop-xfce" is "held back". Apparently, as long as a 
package Depends or Recommends pulseaudio, apt will refuse to remove 
pulseaudio automatically (which makes sense IMO).


Due to this behavior, I couldn't use the pipewire-audio package, instead 
I have to list the packages required: 
https://gitlab.com/kalilinux/packages/kali-meta/-/blob/16b8d88a2b7c28f7129d1cc07bd5bf90392996a9/debian/control#L2424-2429


Long-term, this is not a good solution, I'd really prefer to use the 
pipewire-audio package. But I can't, as long as some packages depend on 
pulseaudio only, instead of 'pulseaudio | pipewire-pulse'. And as I can 
see, there are only two packages that are blocking: 
xfce4-pulseaudio-plugin and pavucontrol.


So that's why I opened this bug report. That's the long story :D



I'm not sure how Kali does it but afair on Debian the
initial installation (using d-i but also I think when using debootstrap or
other tools) doesn't install recommends by default (because it still uses
tasksel).


I think that it's not correct, the debian-installer indeed uses tasksel 
to install the desktop, but then tasksel sets Recommends to true, cf. 
https://salsa.debian.org/installer-team/tasksel/-/blob/edc9b2e20346279a10c48eeb750d0749fe7c19e2/tasksel.pl#L923. 
I don't know about debootstrap.


Best,

--

Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1049418: xfce4-pulseaudio-plugin: Please loosen Recommends, and allow pipewire-pulse as an alternative to pulseaudio

[Arnaud Rebillout]

On 08/09/2023 02:30, Yves-Alexis Perez wrote:
I have no idea what pipewire is, could you explain a bit here what it 
is? Is
it a drop-in for pulseaudio or something? Because 
xfce4-pulseaudio-plugin is

(by definition) really linked to pulseaudio.


Hello Yves-Alexis,

Pipewire - https://pipewire.org/ - is a sound server, similar to 
Pulseaudio, but wider in scope, as it handles both audio and video 
streams. It also aims to support both consumer-grade and pro audio, so 
in the long-term it might replace both Pulseaudio and JACK.


The initial release 0.1.0 was in June 2017. Since then, it has become 
the default sound server in GNOME: in April 2021 for Fedora 34, then in 
Ubuntu 22.10 and finally Debian bookworm.


pipewire itself is not a drop-in replacement, however the associated 
daemon pipewire-pulse is. Quoting the man page:


> pipewire-pulse starts a PulseAudio-compatible daemon that integrates 
with the PipeWire media server. This daemon is a drop-in replacement for 
the PulseAudio daemon.


For more details, I recommend 
https://bootlin.com/blog/an-introduction-to-pipewire/, paragraph "API 
and backward compatibility" (1 minute read).


The introduction from https://wiki.debian.org/PipeWire also gives a good 
overview.



And if we have a drop-in replacement, does it really make sense to 
have every
pulseaudio depending package to use alternate dependencies? Isn't 
there a way

to centralize this change?


This was discussed at https://bugs.debian.org/992686. In short, the 
maintainer believe it's better to let each package "opt-in" by depending 
either on pulseaudio or pipewire-pulse, rather than making the package 
pipewire-pulse provide pulseaudio. The discussion explains why.


Having the dependency be "pulseaudio | pipewire-pulse" (in this order) 
won't change the fact that pulseaudio is favored by apt (during an 
installation of Debian with XFCE desktop, for example). So it shouldn't 
change anything for XFCE. However it will make life easier for users (or 
derivatives) who are willing to switch and completely replace pulseaudio.


A data point: I noticed that KDE's followed this route for their audio 
applet plasma-pa, cf. https://bugs.debian.org/994224 (unfortunately the 
bug report doesn't include any discussion).


Another thing that you might want to know. Both packages pulseaudio and 
pipewire-pulse are co-installable, however when both are installed, only 
the daemon pipewire-pulse is started. It's done at the systemd level, as 
can be seen in this file:


    $ cat /lib/systemd/user/pipewire-pulse.service
    [...]
    Conflicts=pulseaudio.service

So in effect, it's pretty easy to test if pipewire-pulse works well for 
you, just install it and reboot.


Hope that it answers all your questions!

Best,

--

Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

On 21/08/2023 04:03, Philip Hands wrote:

If you want to do your own tests, the mini.iso can be downloaded via:

https://salsa.debian.org/philh/grub-installer/-/jobs/4582667/artifacts/file/debian/output/debian-202306XX+salsaci+20230820+228-amd64-gtkmini.iso


Hello, I download it and tested it in a QEMU VM. I tested it two times: 
with and without UEFI enabled. I can report that installation succeeded 
in both cases.


Here are logs obtained post-install with 'grep grub-installer: 
/var/log/installer/syslog', in case it's useful


 With UEFI enabled:

Success mounting /target/proc
Success mounting /target/sys
Success mounting /target/sys/firmware/efi/efivars
info: architecture: amd64/efi
info: Identified partition label for /dev/sda2: gpt
dpkg: warning: ignoring request to remove grub which isn't installed
dpkg: warning: ignoring request to remove grub-legacy which isn't installed
dpkg: warning: ignoring request to remove grub-pc-bin which isn't installed
dpkg: warning: ignoring request to remove grub-pc which isn't installed
info: initial os-prober call found the following OSes:
info:
info: Found NO other OSes, triggering question about os-prober, default 
false

info: Additionally installing shim-signed to go with grub-efi-amd64
info: Installing grub on 'dummy'
info: grub-install does not support --no-floppy
info: Running chroot /target grub-install  --force "dummy"
Installing for x86_64-efi platform.
Installation finished. No error reported.
info: grub-install ran successfully

    Without UEFI:

info: architecture: amd64/generic
info: Mounting /proc into /target
info: Identified partition label for /dev/sda1: msdos
dpkg: warning: ignoring request to remove grub which isn't installed
dpkg: warning: ignoring request to remove grub-legacy which isn't installed
dpkg: warning: ignoring request to remove grub-efi which isn't installed
dpkg: warning: ignoring request to remove grub-efi-amd64-bin which isn't 
installed
dpkg: warning: ignoring request to remove grub-efi-amd64-signed which 
isn't installed
dpkg: warning: ignoring request to remove grub-efi-amd64 which isn't 
installed
dpkg: warning: ignoring request to remove grub-efi-ia32-bin which isn't 
installed
dpkg: warning: ignoring request to remove grub-efi-ia32 which isn't 
installed

info: initial os-prober call found the following OSes:
info:
info: Found NO other OSes, triggering question about os-prober, default 
false

info: Installing grub on '/dev/sda'
info: grub-install does not support --no-floppy
info: Running chroot /target grub-install  --force "/dev/sda"
Installing for i386-pc platform.
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda2": No such device
Unknown device "/dev/sda5": No such device
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda1": No such device
Unknown device "/dev/sda1": No such device
Installation finished. No error reported.
info: grub-install ran successfully

Cheers,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1049418: xfce4-pulseaudio-plugin: Please loosen Recommends, and allow pipewire-pulse as an alternative to pulseaudio

[Arnaud Rebillout]

Source: xfce4-pulseaudio-plugin
Version: 0.4.7-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

it would be nice if xfce4-pulseaudio-plugin would Recommend
'pulseaudio|pipewire-pulse' instead of simply 'pulseaudio'.

For background: in Kali Linux (a derivative based on Debian testing), we
switched from pulseaudio to pipewire in our flagship desktop XFCE, that
was back in May 2023 [1]. So far so good: sound works great, via the
compat daemon pipewire-pulse. I'm not claiming *everything* works 100%
(I just don't know), but it seems that it works well enough, based on
the feedback we had so far on our bug tracker.

XUbuntu (XFCE's flavor of Ubuntu) also switched to pipewire in version
23.04, back in Apr 2023 [2].

A minor issue, in Kali, is that we still have to install pulseaudio, due
to the fact that xfce4-pulseaudio-plugin depends on pulseaudio. So
pulseaudio must be installed, even though it's not running.

On the same line, we also can't install the metapackage pipewire-audio,
since it Conflicts with pulseaudio, hence breaks the xfce4 metapackage.

Changing the Recommends field of xfce4-pulseaudio-plugin to
'pulseaudio|pipewire-pulse' would solve those two issues, and more
generally it would make life easier for people who want to switch to
pipewire and remove pulseaudio.

Thanks for considering this change,

Arnaud

[1] https://www.kali.org/blog/kali-linux-2023-2-release/#xfce--pipewire
[2] https://xubuntu.org/news/xubuntu-23-04-released/

Bug#1049417: pavucontrol: Please loosen Recommends, and allow pipewire-pulse as an alternative to pulseaudio

[Arnaud Rebillout]

Source: pavucontrol
Version: 5.0-2
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

it would be nice if pavucontrol would Recommend
'pulseaudio|pipewire-pulse' instead of simply 'pulseaudio'.

For background: in Kali Linux (a derivative based on Debian testing), we
switched from pulseaudio to pipewire in our flagship desktop XFCE, that
was back in May 2023 [1]. So far so good: sound works great, and
pavucontrol also works, via the compat daemon pipewire-pulse. I'm not
claiming *everything* works 100% (I just don't know), but it seems that 
it works well enough, based on the feedback we had so far on our bug
tracker.

XUbuntu (XFCE's flavor of Ubuntu) also switched to pipewire in version 
23.04, back in Apr 2023 [2].

A minor issue, in Kali, is that we still have to install pulseaudio, due
to the fact that xfce4 depends on pavucontrol, itself depending on
pulseaudio. So pulseaudio must be installed, even though it's not 
running.

On the same line, we also can't install the metapackage pipewire-audio, 
since it Conflicts with pulseaudio, hence breaks the xfce4 metapackage.

Changing the Recommends field of pavucontrol to
'pulseaudio|pipewire-pulse' would solve those two issues, and more
generally it would make life easier for people who want to switch to
pipewire and remove pulseaudio, while still using pavucontrol.

I've seen that a MR is already open [3].

Thanks for considering this change,

Arnaud



[1] https://www.kali.org/blog/kali-linux-2023-2-release/#xfce--pipewire
[2] https://xubuntu.org/news/xubuntu-23-04-released/
[3] https://salsa.debian.org/pulseaudio-team/pavucontrol/-/merge_requests/5

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

Tentative fix, for what it's worth:

https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/19

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

Following up with that, it seems that the failure is due to a change in 
the kernel.


I'm testing 2 Kali netinst ISOs, one from last week (no problem), and a 
daily iso from today (which fails).


Last weekly iso had kernel 6.1.0-kali9-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives nothing, hence the grub-installer 
postinst doesn't try to mount the efivarfs.


Today's iso has kernel 6.3.0-kali1-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives `nodev efivarfs`, hence the 
grub-installer postinst tries to mount efivarfs, and fails.


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

On 12/07/2023 21:57, Roland Clobus wrote:


This looks to be very similar that I reported in the first part of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039710

On BIOS-boots the EFI /sys mount is not present.


I've read #1039710, I can confirm about the syslog issue, 
/var/log/syslog has just one line in it.


Regarding GRUB failing to install, I forgot to mention how it actually 
looks like: a error screen, red, stating "Failed to mount /target/proc". 
The message is pretty misleading though, it's hardcoded in the template, 
and it can show up in various situations: when mkdir fails, or when 
mount fails, and for either /proc, /sys or /sys/firmware/efi/efivars...


Cheers,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

Hello,

I'm testing a Kali Linux mini.iso, in a BIOS virtual machine. Kali uses 
the grub-installer package from Debian, no change and it's up-to-date.


The postinst still fails at this point. The error can be reproduced from 
the console:


  mkdir -p /target/sys/firmware/efi/efivars
  mkdir: can't create directory '/target/sys/firmware/efi': Operation 
not permitted


I suppose the mkdir call must also be allowed to fail when fstype is 
efivarfs (following the same logic that is already used for mount).


Do you want me to submit a patch?

NB: the issue only affects a BIOS VM. If I boot a UEFI VM, everything 
works fine.


Thanks

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1039868: logrotate: logrotate -s /dev/null replaces /dev/null with a regular file

[Arnaud Rebillout]

Package: logrotate
Version: 3.18.0-2+deb11u1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

this bug affects Debian bullseye (ie. logrotate 3.18). It was fixed
upstream in version 3.19.

The command 'logrotate --state /dev/null ...' happily replaces the
device /dev/null with a regular file, breaking the system badly, in a
non-obvious way.

Steps to reproduce:

  # ls -l /dev/null
  crw-rw-rw- 1 root root 1, 3 Jun 29 01:43 /dev/null
  # logrotate --state /dev/null /etc/logrotate.conf
  # ls -l /dev/null
  -rw-rw--w- 1 root root 1257 Jun 29 02:19 /dev/null

Steps to recover:

  # rm -f /dev/null; mknod -m 0666 /dev/null c 1 3

I looked at the 'bullseye' branch of the Salsa repo [1], I've seen that
you imported a number of patches related to the state file. In
particular, the patch Do-not-lock-state-file-dev-null.patch is what lead
me to shot myself in the foot, since it adds two lines in the manual
page, suggesting to use /dev/null as a state file:

  ++If \fI/dev/null\fR is given as the state file, then \fBlogrotate\fR will
  ++not try to lock or write the state file.

However, in your series of upstream patches, I think you missed this one:

  https://github.com/logrotate/logrotate/commit/45669264

Given the potential for destruction of 'logrotate -s /dev/null', and
seeing how simple is the patch above, would you consider doing an
upload to fix it in bullseye?

Best,

Arnaud



[1] https://salsa.debian.org/debian/logrotate/-/tree/bullseye

Bug#1038862: debian-installer: Doesn't work in UEFI mode with a unsigned GRUB (/boot/grub/fonts/unicode.pf2 not found)

[Arnaud Rebillout]

Hello Cyril,

On 22/06/2023 22:19, Cyril Brulebois wrote:

I'll let Steve comment on this, but having had to deal with far-reaching
consequences of that very change, that seemed trivial enough, Im very
much not convinced I'd like to see more things getting tweaked there.

I acknowledge that this means a maintenance burden for downstream
distributions that would like to use an unsigned GRUB. But then, that's
their choice…


In Kali I fixed it another way, we now use the "monolithic unsigned 
grub" inside our installer, instead of the "legacy" grub style. That 
gets us closer to Debian's mainline, and hopefully will avoid this kind 
of breakage in the future.


I'll be very happy to submit this kind of patch BTW, that is, if you're 
still willing to support building the installer images with a unsigned 
grub for x86, it will be easier to use the monolithic grub. AFAIK it's 
the same as the signed grub, the only difference is that it's not signed.


But to be back to this bug reports: I wanted to make sure that the 
breakage was not Kali specific, and it's not. Being the one that noticed 
it, and knowing that it's a bug in the debian-installer, I thought it 
would be nice to spend the time, and investigate it properly and propose 
a fix, even though we don't use this fix in Kali (as said above we 
solved it differently by using a monolithic unsigned grub). I must add 
that I tested those changes, in case it was not clear, even though 
"tested" for me just means booting the .iso in a QEMU VM.


Cheers,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1038862: debian-installer: Doesn't work in UEFI mode with a unsigned GRUB (/boot/grub/fonts/unicode.pf2 not found)

[Arnaud Rebillout]

Package: debian-installer
Version: 20230607
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

This issue doesn't affect Debian (as Debian's installer images come with
a signed GRUB), but it affects Debian derivatives that use a unsigned
GRUB in their installer. In particular, it did break the Kali Linux
installer images a short while ago, cf.
https://gitlab.com/kalilinux/packages/debian-installer/-/issues/4

The cause of the issue is this commit:
https://salsa.debian.org/installer-team/debian-installer/-/commit/a4dc8c0f

In the change above, the GRUB font was changed from '$prefix/font.pf2'
to 'unicode'. However nothing was done to copy the unicode font at the
right location. It's not an issue for Debian, which uses a sigend GRUB,
ie. a big bundle that embeds everything needed, including this unicode
font.

However for derivatives that don't use Debian's signed GRUB (like Kali
Linux), what we get is a more "traditional" GRUB: a small binary, and
plenty of modules and other files that GRUB will load as need be. For
this unsigned GRUB, we must make sure that the unicode font is present
at the right location.

I propose the following fixes:

https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/35
to change the GRUB font from ascii.pf2 to unicode.pf2, and install it
under the fonts/ directory.

https://salsa.debian.org/images-team/debian-cd/-/merge_requests/32 so
that debian-cd tries to copy fonts from grub/*.pf2 and grub/fonts/.

Below comes a longer step-by-step procedure to repoduce the issue, if
anyone wants to check it by themselves.



First, build a set of installer images with `EFI_SIGNED` set to no.

```
cd debian-installer
sed -i 's/EFI_SIGNED=y/EFI_SIGNED=n/' build/config/*.cfg
git commit -a -m "EFI_SIGNED=n"
sbuild
sbuild --arch=i386
```

Then, rebuild a iso with those installer images. I used `simple-cdd`:

```
mkdir <>
cd <>

mkdir custom-installer
cp <>/debian-installer-images_* custom-installer/
cd custom-installer; for f in *.gz; do tar -xf $f; done; cd ..

cat << EOF > simple-cdd.conf
custom_installer="$(pwd)/custom-installer"
mirror_tools="reprepro download"
mirror_files=""  # Don't try to download README doc/ tools/
export OMIT_MANUAL=1
export OMIT_RELEASE_NOTES=1
export OMIT_DOC_TOOLS=1
export ARCHES="amd64 i386"  # Workaround 
https://salsa.debian.org/debian/simple-cdd/-/merge_requests/12
EOF

build-simple-cdd --verbose --debug --force-root --conf simple-cdd.conf
```

Boot the resulting iso with kvm and UEFI enabled: we can briefly see a error
message about missing unicode font, then the GRUB menu appears. Hit  to
start installation: it fails with "Booting in blind mode".

Find more details (and screenshots!) at:




Best,

Arnaud

Bug#1034771: generate_firmware_patterns failed: 512 at ./tmp/debian-cd/tools/make_disc_trees.pl line 1257

[Arnaud Rebillout]

On Sat, 03 Jun 2023 23:17:22 -0700 Vagrant Cascadian 
 wrote:

>
> This is because reprepro does not generate or support these
> dep11/Components-*.ym.gz files...
>
> https://bugs.debian.org/824521
>
> It might be possible to work around in similar to how debian-installer
> images are download in simple_cdd/tools/mirror_download.py

Another approach: debian-cd could make DEP11 optional, so that 
derivatives can opt out. I opened a merge request: 
https://salsa.debian.org/images-team/debian-cd/-/merge_requests/31


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1037111: ITP: pipewire-module-xrdp -- xRDP module for the PipeWire sound server

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-utopia-maintain...@lists.alioth.debian.org

* Package name: pipewire-module-xrdp
  Version : git HEAD
  Upstream Contact: https://github.com/matt335672/pipewire-module-xrdp/issues
* URL : https://github.com/matt335672/pipewire-module-xrdp
* License : MIT
  Programming Lang: C
  Description : xRDP module for the PipeWire sound server

This module allows xrdp to generate sound on a pipewire-based system.

A known user of xrdp is the MS Hyper-V virtual machines, when running in
so-called "Enhanced Session Mode" or ESM for short. ESM means that user
access their VM over xRDP. In this mode, if the Linux guest uses
Pipewire, then we need an additional xRDP module for the sound.

Discussions show that there's interest from PipeWire upstream to include
such a module [1]. So hopefully, the package pipewire-module-xrdp that
I'm proposing here is only temporary.

I plan to maintain this package with the Utopia team (which already
maintains pipewire), and I'd be happy to get a round of review from
them.

[1]: 
https://github.com/neutrinolabs/xrdp/discussions/2023#discussioncomment-4829470

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Arnaud Rebillout]

On 19/05/2023 01:33, Luca Boccassi wrote:

We heard so much in the past couple of weeks about how important it is
for the project not to cause issues for derivatives and
cross-compatibility use cases, even speculatively. This is not even
speculative, it is certain to cause damage (as we experienced first
hard last year), I don't see how we can ignore it after all of these
discussions.

Speaking as Kali maintainer, we patched it out already a while ago:
https://gitlab.com/kalilinux/packages/dpkg/-/commit/bff5fa3c

Best,

Arnaud

Bug#1034666: unblock: mirrorbits/0.5.1+git20220308.9189dc7+ds1-1+b1

[Arnaud Rebillout]

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

Please unblock package mirrorbits

This changeset fixes the build of mirrorbits.

[ Reason ]

This is to fix FTBFS reported at https://bugs.debian.org/1026674. FTBFS
was due to changes in build dependencies, the package needed some minor
adjustments.

[ Impact ]

mirrorbits won't be included in bookworm

[ Tests ]

N/A

[ Risks ]

Low risk, this is a leaf package

[ 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 ]

The package has not been uploaded to unstable yet.

unblock mirrorbits/0.5.1+git20220308.9189dc7+ds1-1+b1
diff -Nru mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/changelog 
mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/changelog
--- mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/changelog   2022-07-18 
19:55:10.0 +0700
+++ mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/changelog   2023-04-21 
11:20:56.0 +0700
@@ -1,3 +1,11 @@
+mirrorbits (0.5.1+git20220308.9189dc7+ds1-2) unstable; urgency=medium
+
+  * Replace transitional golang-goprotobuf-dev package
+  * Drop patch aimed at compatibility with golang-goprotobuf-dev 1.5.x
+  * Fix FTBFS with libprotobuf-dev 3.21.9 (Closes: #1026674)
+
+ -- Arnaud Rebillout   Fri, 21 Apr 2023 11:20:56 +0700
+
 mirrorbits (0.5.1+git20220308.9189dc7+ds1-1) unstable; urgency=medium
 
   * Drop patches, applied upstream
diff -Nru mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/control 
mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/control
--- mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/control 2022-07-18 
19:55:10.0 +0700
+++ mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/control 2023-04-21 
11:20:56.0 +0700
@@ -10,6 +10,7 @@
  dh-sequence-golang,
  golang-any,
  golang-github-coreos-go-systemd-dev,
+ golang-github-golang-protobuf-1-3-dev,
  golang-github-gomodule-redigo-dev,
  golang-github-howeyc-gopass-dev,
  golang-github-op-go-logging-dev,
@@ -19,8 +20,8 @@
  golang-golang-x-net-dev,
  golang-google-grpc-dev,
  golang-gopkg-tylerb-graceful.v1-dev,
- golang-goprotobuf-dev,
  golang-yaml.v2-dev,
+ protoc-gen-go-1-3,
 Standards-Version: 4.6.0
 Vcs-Browser: https://salsa.debian.org/debian/mirrorbits
 Vcs-Git: https://salsa.debian.org/debian/mirrorbits.git
diff -Nru 
mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/patches/Add-Go-import-path-to-.proto-file.patch
 
mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/patches/Add-Go-import-path-to-.proto-file.patch
--- 
mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/patches/Add-Go-import-path-to-.proto-file.patch
 2022-07-18 19:55:10.0 +0700
+++ 
mirrorbits-0.5.1+git20220308.9189dc7+ds1/debian/patches/Add-Go-import-path-to-.proto-file.patch
 1970-01-01 08:00:00.0 +0800
@@ -1,52 +0,0 @@
-From: Arnaud Rebillout 
-Date: Mon, 11 Jul 2022 14:59:38 +0200
-Subject: Add Go import path to .proto file
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-This is required for golang-goprotobuf-dev 1.5.2-1 (currently in Debian
-experimental), otherwise protoc fails with:
-
-protoc -I rpc --go_out=plugins=grpc:rpc rpc/rpc.proto
-protoc-gen-go: unable to determine Go import path for "rpc.proto"
-
-Please specify either:
-. a "go_package" option in the .proto source file, or
-. a "M" argument on the command line.
-
-See 
https://developers.google.com/protocol-buffers/docs/reference/go-generated#package
 for more information.
-
---go_out: protoc-gen-go: Plugin failed with status code 1.
-
-The fancy value '.;rpc' comes from:
-https://github.com/golang/protobuf/issues/1102#issuecomment-619240905
-
-Actually the option should specify the full Go path, howeverif I do that,
-protoc generates the file rpc.pb.go in a completely different location, and the
-value of 'package' in rpc.pb.go becomes a full path, rather than just "rpc".
-
-I'm aiming at minimal changes here (because of my poor Go skills), so I prefer
-to use this trick in order to keep the generated file unchanged, as much as
-possible.
-
-Forwarded: not-needed, Debian-specific

- rpc/rpc.proto | 4 +++-
- 1 file changed, 3 insertions(+), 1 deletion(-)
-
-diff --git a/rpc/rpc.proto b/rpc/rpc.proto
-index fed9eb3..b5b9eae 100644
 a/rpc/rpc.proto
-+++ b/rpc/rpc.proto
-@@ -3,6 +3,8 @@ syntax = "proto3";
- import "google/protobuf/empty.proto";
- import "google/protobuf/timestamp.proto";
- 
-+option go_package = ".;rpc";
-+
- service CLI {
- rpc GetVersion (google.protobuf.Empty) returns (VersionReply) {}
- rpc Upgrade (google.protobuf.Empty) returns (google.protobuf.Empty) {}
---
-2.36.1
diff -Nru mirrorbits-0.5.1+git20220308.91

Bug#1029803: command-not-found breaks dist-upgrade bullseye → bookworm

[Arnaud Rebillout]

We were also hit by this issue in Kali Linux, it broke apt during a few 
hours until I could fix it at the repository level.


I think that it would also have been better if the apt hook ended with 
"|| true", so that users still have a usable apt whenever cnf misbehaves.


Ie. in file 
https://salsa.debian.org/jak/command-not-found/-/blob/main/data/50command-not-found:


|"if /usr/bin/test -w /var/lib/command-not-found/ -a -e 
/usr/lib/cnf-update-db; then /usr/lib/cnf-update-db > /dev/null || true; 
fi";|


Thanks!

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1031426: reprepro: update with a pair of components doesn't work as expected

[Arnaud Rebillout]

Package: reprepro
Version: 5.3.1-1
Severity: normal

Dear Maintainer,

Here's a minimal example to demonstrate the problem:

 $ cat conf/distributions
 Codename: my-distro
 Architectures: amd64 source
 Components: non-free
 Update: - update-sid
 Log: my-distro.log
 # don't pack indices for this example
 DebIndices: Packages Release .
 DscIndices: Sources Release .

 $ cat conf/updates
 Name: update-sid
 VerifyRelease: blindtrust
 Method: http://deb.debian.org/debian/
 Suite: unstable
 Components: non-free non-free-firmware>non-free
 FilterSrcList: deinstall updates-filter

 $ cat conf/updates-filter
 atmel-firmware install

In the example above, I create 'my-distro', it has only one component
named 'non-free'. my-distro gets its updates from Debian unstable, from
the two components non-free and non-free-firmware, that are merged into
one component using "non-free-firmware>non-free".

For the sake of the example, my-distro has only one package, it's
atmel-firmware, that comes from the non-free-firmware component in
Debian.

This setup seems to work, at least on the surface:

 $ reprepro update
 Calculating packages to get...
 Getting packages...
 Installing (and possibly deleting) packages...
 Exporting indices...

However, looking a bit deeper, there are 2 things that are not correct:

 $ grep -E -rni '(Package-List|non-free-firmware)' dists/
 dists/my-distro/non-free/binary-amd64/Packages:19:Section: 
non-free-firmware/kernel
 dists/my-distro/non-free/source/Sources:24:Package-List: 
 dists/my-distro/non-free/source/Sources:25: atmel-firmware deb 
non-free-firmware/kernel optional arch=all
 dists/my-distro/non-free/source/Sources:28:Section: non-free-firmware/misc

In the snippet above, we can see that the name of the component is not
updated in the Section and in the Package-List fields (it should be
non-free).

If we decide to also create a Contents file, ie. we add the line:

 Contents: percomponent .

to conf/distributions, then the name of the component is also wrong in
the Contents file:

 $ cat dists/my-distro/non-free/Contents-amd64
 etc/pcmcia/atmel.conf  non-free-firmware/kernel/atmel-firmware
 lib/firmware/atmel_at76c502-wpa.bin
non-free-firmware/kernel/atmel-firmware
 [...]

The issue is for real. I used 'non-free-firmware>non-free' in order to
delay the addition of the new non-free-firmware component in Kali Linux.
However it broke command-not-found, a program that parses the Contents
files and crashes when it encounters an unknown component. Since
command-not-found is run after "apt update" (as a hook or something like
that), in practice it means that "apt update" failed for every Kali
Linux users...

As a quick fix, I could workaround the issue by using this reprepro
trick in conf/updates:

 ListShellHook: sed -e '/^Section: /s/non-free-firmware/non-free/' -e '/^ /s/ 
deb non-free-firmware\// deb non-free\//'

However it's sloppy, I think the issue should be fixed in reprepro.
reprepro should take care of renaming the component in the Sources and
Packages index files, for the fields Section and Package-List. That is
enough to also fix the Contents files.

I can come up with a patch, would you be willing to review it?

Thanks!

Arnaud

Bug#1030287: simple-cdd: What if reprepro_retries is reached?

[Arnaud Rebillout]

On 06/02/2023 10:07, Vagrant Cascadian wrote:

On 2023-02-06, Arnaud Rebillout wrote:

By the way, as I see that simple-cdd is in Salsa's debian group: are you
Ok if we (Kali Linux developers, that would be Raphael Hertzog or me)
release the package from time to time, or do you prefer to be taking
care of that?

I would be fine with that. I do not actually use simple-cdd ... other
than to test simple-cdd... so someone who actually uses it for something
real would probably keep it in better shape... :)

Feel free to put yourselves in the Uploaders field!


Done, and I just uploaded a new release. Thanks!


--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1030287: simple-cdd: What if reprepro_retries is reached?

[Arnaud Rebillout]

Hello Vagrant,


On 03/02/2023 03:45, Vagrant Cascadian wrote:

There were definitely cases of packages that had alternate dependencies
that will never be satisfyable (e.g. from contrib or non-free when
building only from main, or even ubuntu), so failing to resolve all
dependencies is not technically an error.

But sure, issuing a warning that reprepro_retries was reached and
suggesting to bump the value if later steps fail due to missing
dependencies seems reasonable...

The mirroring here is definitely a best-effort shotgun approach,
grabbing all the dependencies/recommends of any package you actually
expressed interest in (by putting in a .packages or .downloads file in
one of the profiles), and *trying* to pull in anything mentioned in any
Depends or Recommends or Provides field, recursively... and comparing
the previous run to the current run if anything changed.

If it does not pull in enough, I think debian-cd still
fails... maybe... I guess... hope? :)

In some cases, adding more packages to one of the .downloads files is
the appropriate workaround.


Thanks for the detailed explanations, much appreciated!



Sounds like the default should at least be bumped to a larger value,
then.

That has been the value since at least 2006, picked by finding the right
value at the time for the biggest profile I ever tested and doubling
it... there have been quite a few packages added to Debian since then,
so it is no surprise that it would need to be updated!

Feel free to propose a higher value grounded in a current real world
use-case, and double it. :)


I opened a merge request on Salsa:

https://salsa.debian.org/debian/simple-cdd/-/merge_requests/10

I just doubled the value and made it 40.

From the Kali Linux build logs I can see, the number of attempts goes 
from 11 to 20. Unfortunately we don't keep daily build logs, only those 
that fail, so I can't really tell what's the average number of attempts, 
for example. I just know that "sometimes" we reach 20.




Thanks for looking into it!

Help is definitely appreciated! I have not really looked at simple-cdd
much since the previous release, and simple-cdd surely needs some help
now that we are into the early phases of a freeze cycle!


And thanks for the quick feedback!

By the way, as I see that simple-cdd is in Salsa's debian group: are you 
Ok if we (Kali Linux developers, that would be Raphael Hertzog or me) 
release the package from time to time, or do you prefer to be taking 
care of that?


Cheers,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1030287: simple-cdd: What if reprepro_retries is reached?

[Arnaud Rebillout]

Package: simple-cdd
Version: 0.6.8
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: vagr...@debian.org

Dear Maintainer,

Looking at tools/mirror/reprepro [1], I see that this script runs
'reprepro update' in a loop, until reprepro_retries (default: 20) is
reached.

However, it's a bit strange that, if ever reprepro_retries is reached,
the code doesn't error out with a message such as "There are still
dependencies missing after $i attempts!". Instead, the script silently
keeps going, and exits with zero, as if there was no problem.

I'd suggest to either:
- error out when reprepro_retries is reached, as suggested above.
- if it's not considered an error, at least print a message to say that
  reprepro_retries was reached, and clarify that it's not a problem.

This is not a theoretical situation. I looked at the logs from the Kali
Linux daily builds, and for some builds it took 20 attempts, so it seems
likely that for some builds it would have taken more attempts.

I can submit a patch if needed,

Thanks!

[1]: 
https://salsa.debian.org/debian/simple-cdd/-/blob/master/tools/mirror/reprepro

Bug#999582: ucf: Wrong code in ucf

[Arnaud Rebillout]

I prepared a NMU, cf. https://salsa.debian.org/arnaudr/ucf/

I plan to test it next week and then upload it to the DELAYED queue.

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1028372: ncat: Please lower alternative priority below nc.traditional

[Arnaud Rebillout]

On Wed, 18 Jan 2023 23:04:54 +0100 Hilko Bengen  wrote:
> > We have users in Kali Linux who have been beaten by this. They use nc,
> > they also need ncat for the extra options it provides, they install it,
> > and then are very surprised that nc is now ncat. From their background
> > (I'm talking about professional pentesters), nc and ncat are different
> > tools, they really don't expect ncat to replace nc.
>
> I'd like to see in what way people have been irritateed. Can you link to
> specific bug reports or mailing list/form discussions?

From my understanding, one big difference between nc and ncat is the 
output. ncat's output is very different from nc, much more verbose 
apparently. This is not always suitable, for example some folks have 
teaching material with nc, where they demonstrate nc's commands and 
output. They also need to use ncat in those courses, but from the moment 
ncat is installed, nc's output become ncat, the output is much more 
verbose. It's kind of confusing, and even though they *could* update 
their courses to show ncat's output (instead of nc), and explain that 
"after installing ncat, nc is now ncat", it's just not what they want, 
because ncat's output is too verbose, while nc output is just right (for 
the purpose of teaching material).


Another point, as I understand it, is just that ncat and nc have always 
been two different tools (although they clearly have some big overlap), 
at least in Debian & Kali, since before April 2018, they have always 
been distributed as two different tools. So users have been used to 
install & use nc when needed, install & use ncat when needed, and 
sometimes install & use both, each for a specific purpose. While the 
use-case of having ncat == nc exists, I have the impression that it's 
maybe not the main use-case.


I will reach out to the folks who reported this issue, and try to get 
them to provide more details on this bug report.


Also, for transparency: those folks are from Offensive Security, which 
is also my employer (Kali Linux is developed by Offensive Security). 
Apologizes for not stating that in my initial message.


Cheers,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#999582: ucf: Wrong code in ucf

[Arnaud Rebillout]

I can confirm that the issue is still present.

There are patches proposed at https://bugs.debian.org/979354. I think 
they should be applied before the bookworm freeze. There are other 
patches sitting on Salsa.


I'm a bit reluctant to do a NMU as I'm not familiar with this package, 
and I don't know if the patches proposed in #979354 are enough of a fix, 
or if there's more to it.


--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1028511: initramfs-tools: Please include `hyperv-keyboard` to enter LUKS password in Gen2 Hyper-V machines

[Arnaud Rebillout]

Package: initramfs-tools
Version: 0.142
Severity: normal
Tags: patch
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

As reported in the Kali Linux bug tracker, it's not possible to type the
LUKS password, in case of full disk encryption, in Gen2 Hyper-V virtual
machine. This is due to missing modules.

The original bug is at https://bugs.kali.org/view.php?id=7846, and I'll
quote the bits that are relevant:

> Because Generation 2 virtual machines in Hyper-V are presented with a
> minimal set of EFI hardware, the kernel module "hyperv_keyboard" must
> be present to interact with the console keyboard. On systems with disk
> encryption, the user will be prompted for the key to decrypt the disk,
> but cannot enter the password because no keyboard driver is present.
>
> [...]
>
> This module *is* present when the grub menu is presented and later
> when the kernel is fully loaded.  FYI, if some mechanism requires a
> mouse or touch, the hid_hyperv module will also be needed.

This issue also affects Debian, as discussed in:


This issue was also reported in the Ubuntu tracker, back in 2016:

It was fixed in Ubuntu, but the changes never made it to Debian.

Please find a merge request at:


Thanks,

  Arnaud

Bug#1028372: ncat: Please lower alternative priority below nc.traditional

[Arnaud Rebillout]

Package: ncat
Version: 7.92+dfsg2-1+b1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

Please consider lowering the priority of ncat below nc.traditional, or
remove it completely from the nc alternatives.

At the moment, there are 3 alternatives for nc:

  # update-alternatives --list nc
  /bin/nc.openbsd
  /bin/nc.traditional
  /usr/bin/ncat

The alternatives for nc.openbsd and nc.traditional are necessary as they
both provide the bin/nc binary, however it's not strictly necessary for
ncat, as it comes under the name bin/ncat. And indeed, for a long while
ncat was NOT part of the nc alternatives, it was added only in response
to bug https://bugs.debian.org/881639, and was released with src:nmap
7.70+dfsg1-2 in April 2018.

Quoting the bug above:

> The clevis package (ITP #854410) needs a netcat for the dracut
> unlocker, and an alpha tester reported the implementations provided
> by both -traditional and -openbsd don't fit the needs. I was told
> Redhat (where clevis comes from) uses nmap's ncat for nc, and things
> work fine then.

However, clevis dropped the dependency on ncat a while ago:
https://github.com/latchset/clevis/commit/9cdd0415 (Dec 2020). So the
reason that prompted this change in ncat is not valid anymore.

I think it's still useful to have ncat amongst nc alternatives though.
Even though it's not needed for clevis anymore, this bug demonstrated
that there can be use-cases for which it's useful to have nc == ncat. If
only for compatibility with Redhat.

However I think it shouldn't have a higher priority than nc.traditional.
I think it should be opt-in, it should replace nc only if users want it
to, by running update-alternatives manually. The main reason is that
ncat is not a drop-in replacement for nc, it's not 100% compatible, it
has a very different output, etc...

We have users in Kali Linux who have been beaten by this. They use nc,
they also need ncat for the extra options it provides, they install it,
and then are very surprised that nc is now ncat. From their background
(I'm talking about professional pentesters), nc and ncat are different
tools, they really don't expect ncat to replace nc.

Therefore I suggest to lower the priority of the ncat alternative to
zero, so that upon installation it does NOT replace nc.

Thanks,

Arnaud

Bug#1027259: buildah: Sticky bit isn't preserved when adding tarball

[Arnaud Rebillout]

Package: buildah
Version: 1.28.0+ds1-3
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: siret...@tauware.de

Dear Maintainer,

the buildah package currently in Sid (1.28.0+ds1-3) is affected by
upstream bug: https://github.com/containers/buildah/issues/4427

It is solved with version 1.28.1 (nb: latest tag upstream is 1.28.2).

Can we bump this package to 1.28.2? Or is it preferable to just import
the patch (I'm not familiar with this packge, so I prefer to ask)?

I can do a manual upload myself if that's Ok with you.

Best,

Arnaud

Bug#1026120: git-buildpackage: issues with upstreams LFS files

[Arnaud Rebillout]

On Wed, 21 Dec 2022 15:04:43 +0700 Arnaud Rebillout  
wrote:


> It's solved by setting --defuse-gitattributes.

I meant: setting --defuse-gitattributes=off, of course.

Bug#1026120: git-buildpackage: issues with upstreams LFS files

[Arnaud Rebillout]

On 15/12/2022 15:54, Guido Günther wrote:

Or use `gbp clone --git-defuse-attributes=off ...` ?


Indeed! Thanks, I didn't notice this option, and I can confirm that it 
solves the issue (the exact option name is "--defuse-gitattributes=off" 
actually).


I took the time to look a bit at this option and where it comes from 
(seemingly, the goal is that gbp is compatible with other tools such as 
dgit). There's still something that strikes me.


IIUC, it's *only* "gbp clone" that will defuse the git attributes.

So developer A does "gbp import-orig", brings in the offending 
attributes: still they are not defused on their local copy. Then 
developer B does "gbp pull", and then no change: gbp does not defuse 
attributes during pull, so attributes are still enabled. Then developer 
C does "gbp clone", and they possibly get a different working copy, 
because in this case only, attributes are defused.


It seems that this behavior is prone to create problems, albeit it might 
be detected by CI (not sure what Salsa CI does in details), and it's 
also kind of a niche issue anyway.


We took a look at our packaging repos in Kali Linux (~ 600 repos), and 
we found 3 of them that are unclean on `gbp clone`. It's solved by 
setting --defuse-gitattributes. So we will probably add this argument to 
our .mrconfig, and make sure to use it all the time. We'll see where it 
gets us.


I'm really not familiar with git attributes, so I don't have any 
recommendation, or anything else to say, I'm merely reporting in case it 
helps.


Cheers,

Arnaud

Bug#1023383: git-buildpackage: gbp pull shows empty error message on failure

[Arnaud Rebillout]

For what it's worth, I rebased my branch so that the CI now passes.

The new commit with the patch is: 
https://salsa.debian.org/arnaudr/git-buildpackage/-/commit/8f10840587e05b27ee43fbff10480ef2734805bb


BTW, please tell me if there's a better workflow than having a fork on 
Salsa, in order to contribute to gbp.


Thanks!

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1026120: git-buildpackage: issues with upstreams LFS files

[Arnaud Rebillout]

 Cloning from 'g...@gitlab.com:arnaudr/king-phisher2.git'
  gbp:debug: ['git', 'clone', '--quiet', 
'g...@gitlab.com:arnaudr/king-phisher2.git']
  gbp:debug: ['git', 'rev-parse', '--show-cdup']
  gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
  gbp:debug: ['git', 'rev-parse', '--git-dir']
  gbp:debug: ['git', 'rev-parse', '--show-cdup']
  gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
  gbp:debug: ['git', 'rev-parse', '--git-dir']
  gbp:debug: Will track branches: ['kali/master', 'upstream', 'pristine-tar']
  gbp:debug: ['git', 'show-ref', '--verify', 'refs/remotes/origin/kali/master']
  gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/kali/master']
  gbp:debug: ['git', 'show-ref', '--verify', 'refs/remotes/origin/upstream']
  gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
  gbp:debug: ['git', 'branch', 'upstream', 'origin/upstream']
  gbp:debug: ['git', 'show-ref', '--verify', 'refs/remotes/origin/pristine-tar']
  gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
  gbp:debug: ['git', 'branch', 'pristine-tar', 'origin/pristine-tar']
  gbp:debug: ['git', 'show-ref', '--verify', 'refs/remotes/kali/master']
  gbp:debug: ['git', 'config', 'user.name', 'Arnaud Rebillout']
  gbp:debug: ['git', 'config', 'user.email', 'arna...@kali.org']
  gbp:debug: ['git', 'ls-tree', '-z', '-r', '-l', 'HEAD', '--']
  gbp:debug: Found non-empty .gitattributes: b'.gitattributes'
  gbp:debug: Configuring Git attributes
  
  $ cd king-phisher2
  
  $ git status
  On branch kali/master
  Your branch is up to date with 'origin/kali/master'.
  
  Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified:   data/server/king_phisher/GeoLite2-City.mmdb
  
  no changes added to commit (use "git add" and/or "git commit -a")
  
  $ cat .gitattributes 
  *.mmdb filter=lfs diff=lfs merge=lfs -text
  $ cat .git/info/attributes 
  # Added by git-buildpackage to disable .gitattributes found in the upstream 
tree
  [attr]dgit-defuse-attrs  -text -eol -crlf -ident -filter 
-working-tree-encoding
  * -export-ignore
  * dgit-defuse-attrs
  $ ls -l data/server/king_phisher/GeoLite2-City.mmdb 
  -rw-r--r-- 1 arno arno 61615395 Dec 15 12:12 
data/server/king_phisher/GeoLite2-City.mmdb
  
As we can see above (my interpretation):
* during the 'gbp clone' step, the 'git clone' command will actually
  trigger git lfs, and download the GeoLite2 database (assuming you have
  the package git-lfs installed on your machine).
* then at the end of the gbp clone operation, we can see "Configuring
  Git attributes", and this is when gbp creates the file
  .git/info/attributes
* as a result, the git repo is in an unclean state

To bring back the Git repo in shape, we can either:

1) Undo what gbp just did:

rm -fr .git/info/attributes

2) Undo what git lfs did:

$ git checkout data/server/king_phisher/GeoLite2-City.mmdb
Updated 1 path from the index
$ cat data/server/king_phisher/GeoLite2-City.mmdb
version https://git-lfs.github.com/spec/v1
oid sha256:a253d9cd68fe17b00087da24375f31f07cd4bb3852dc5fe3afe37b8f59e5abd0
size 61615395

As we can see with option 2), the LFS file becomes a short metadata
file, because that's what's really in the Git repo, before "git lfs"
replaces it with the "real file" that it fetches from somewhere else.

  == Questions

How does the git LFS files should be handled? When "gbp clone" disables
the gitattributes, it disables Git LFS in turn: is it intended, or not?
Does gbp has an opinion on that?  In any case, it seems that disabling
the gitattributes after 'git clone' has run is too late, because the Git
LFS objects were already fetched.

Thanks for reading, and please help me understand how we should handle
those LFS files.

Arnaud

Bug#1025519: bind9: apparmor profile prevents openssl config files other than etc/ssl/openssl.cnf

[Arnaud Rebillout]

Package: bind9
Version: 9.18.8-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

This bug was initially reported against the Kali bug tracker:
https://bugs.kali.org/view.php?id=8079#c17121.

The issue is that, in Kali Linux, named crashes as it can't access the
file etc/openssl/kali.cnf. Here's the interesting part of the strace
output:

  $ sudo strace -e trace=file named --help
  [...]
  newfstatat(AT_FDCWD, "/etc/ssl/kali.cnf", {st_mode=S_IFREG|0644, st_size=653, 
...}, 0) = 0
  openat(AT_FDCWD, "/etc/ssl/kali.cnf", O_RDONLY) = -1 EACCES (Permission 
denied)
  tls.c:88: fatal error: RUNTIME_CHECK(OPENSSL_init_ssl((0x0200L | 
0x0400L | 0x1000L | 0x2000L | 0x4000L) | 0x0040L, ((void 
*)0)) == 1) failed
  --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2631, si_uid=0} ---
  +++ killed by SIGABRT +++
  zsh: IOT instruction sudo strace -e trace=file named --help

This is due to the apparmor profile for named, which is pretty
restrictive regarding which openssl config files are allowed:

  debian/extras/apparmor.d/usr.sbin.named
  
  # ssl
  /etc/ssl/openssl.cnf r,

I wonder if this part could be relaxed a bit, with something like:

  # ssl
  /etc/ssl/*.cnf r,
  /etc/ssl/*.conf r,

To give more context: in Kali Linux we ship the openssl config file at
the usual location /etc/ssl/openssl.cnf, but we also have a second file
with extra configuration at /etc/ssl/kali.cnf. This second file is
included from the main file, using the .include directive.

As documented in the openssl config man page (`man 5 config`), the
.include directive allows to include *any* location, which doesn't
really help here... But the man page also says (more or less) that the
standard extension for openssl config files should be .cnf or .conf.

The change I suggest above would give more rope to sysadmins (or
derivatives like Kali Linux), and would allow named to read any config
file, as long as it's located in /etc/ssl and have the .cnf or .conf
extension.

I looked at other packages and I found that cupsd does something
similar:
https://salsa.debian.org/printing-team/cups/-/blob/debian/main/debian/local/apparmor-profile


Best,

Arnaud

Bug#1024549: espeakup: crashes during speech synthesis installation, snd_pcm_area_copy assertion failed

[Arnaud Rebillout]

On 05/12/2022 03:52, Samuel Thibault wrote:

I was about to try to investigate, but I cannot reproduce it with the
daily image any more. It uses the new alsa-lib 1.2.8 upstream version,
so perhaps the bug was just fixed, could you also give it a try?


I just grabbed the daily image. I can confirm that it comes with alsa 
1.2.8, and also with espeakup 1:0.90-12 (ie. it contains your code to 
restart espeakup).


On my side, espeakup keeps crashing, but it's restarted thanks to your 
changes. I wouldn't have noticed the crashes if I didn't look at the logs.


The log file /var/log/espeakup.log shows that it's been restarted 3 
times when I arrived at the tasksel screen.


Cheers,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1019194: pulseaudio: ALSA woke us up to write new data to the device, but there was actually nothing to write.

[Arnaud Rebillout]

On Mon, 05 Sep 2022 12:04:12 +0200 Tobias Koeck  
wrote:> Package: pulseaudio

>
> Sep 5 11:58:46 tron-nb pulseaudio[4602]: ALSA woke us up to write new 
data to the device, but there was actually nothing to write.
> Sep 5 11:58:46 tron-nb pulseaudio[4602]: Most likely this is a bug in 
the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA 
developers.
> Sep 5 11:58:46 tron-nb pulseaudio[4602]: We were woken up with 
POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or 
another value < min_avail.


I'm seeing something similar here, in a QEMU virtual machine started 
with -device intel-hda -device hda-duplex. The only difference with the 
logs reported by Tobias above is the alsa driver in second line:


Nov 30 03:53:00 debian pulseaudio[600]: ALSA woke us up to write new 
data to the device, but there was actually nothing to write.
Nov 30 03:53:00 debian pulseaudio[600]: Most likely this is a bug in the 
ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA 
developers.
Nov 30 03:53:00 debian pulseaudio[600]: We were woken up with POLLOUT 
set -- however a subsequent snd_pcm_avail() returned 0 or another value 
< min_avail.


--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1025133: cdebconf: task selection is ignored with d-i in speech synthesis mode

[Arnaud Rebillout]

Package: cdebconf
Version: 0.265
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: sthiba...@debian.org

Dear Maintainer,

Short story: task selection is ignored in speech synthesis mode. This is
due to a regression in the cdebconf text frontend. The issue is easily
fixed, and I propose the following patch:
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/18

Longer story: the issue is easy to reproduce, just fire the debian
installer (daily build), select speech synthesis install, and when comes
the time to select the tasks, select something that is not the default.
For example, I select '1 4 10 11 12', and then pretty much nothing gets
installed. After reboot, there is just a console. `dpkg -l | wc -l`
tells me that 256 packages are installed. No desktop environment.

It's possible to see the issue with `DEBCONF_DEBUG=.` on the kernel
cmdline. The offending part of the syslog:

  Nov 30 00:36:23 debconf: --> GET tasksel/first
  Nov 30 00:36:23 debconf: <-- 0
  Nov 30 00:36:23 in-target: debconf (developer): < (passthrough) 0
  Nov 30 00:36:23 in-target: debconf (developer): Got "" for tasksel/first

The second line shouldn't be empty.

I CC Samuel, as he reworked the text frontend lately, it will be
straightforward for him to review and ack my patch (or fix it
differently, at your preference Samuel).

The issue was originally reported against Kali Linux:


Thanks!

Arnaud

Bug#1001825: netsniff-ng: Recommend time-daemon instead of ntp?

[Arnaud Rebillout]

Dear maintainer / uploader,

just a friendly ping in case you didn't see this bug report. Also I've 
seen that you changed the Recommends from ntp to ntpsec in Apr 2022. Any 
reason to prefer this package over whatever other package that 
"Provides: time-daemon"?


Thanks,

Arnaud


On Fri, 17 Dec 2021 14:13:52 +0700 Arnaud Rebillout  
wrote:


> Source: netsniff-ng
> Version: 0.6.8-2
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
>
> Dear Maintainer,
>
> I've seen that netsniff-ng recommends the package ntp. Is it because it
> needs to be sure that the system time is accurate? In that case, would
> it be better to recommend the virtual package time-daemon instead?
>
> $ grep-aptavail -F Provides "time-daemon" | grep ^Package:
> Package: chrony
> Package: linuxptp
> Package: ntp
> Package: ntpsec
> Package: openntpd
> Package: systemd-timesyncd
>
> $ cd /usr/share/doc/debian-policy
> $ zgrep 'name: time-daemon' virtual-package-names-list.yaml.gz -A1
> - name: time-daemon
> description: anything that serves as a time daemon
>
> Please note that I don't know what netsniff-ng is or what it does. I was
> just working of building OS images for Kali (a Debian derivative), and I
> was wondering why some images came with ntp installed, and other images
> came with systemd-timesyncd instead. I found out that it's netsniff-ng
> that forces the installation of ntp and prevents systemd-timesyncd to be
> installed.
>
> I think it would be better if the package just recommended time-daemon
> without requiring a particular implementation (ntp in this case). But
> once again, I'm not familiar with netsniff-ng and I don't want to break
> anything!
>
> Thanks,
>
> Arnaud
>
>

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1024549: espeakup: crashes during speech synthesis installation, snd_pcm_area_copy assertion failed

[Arnaud Rebillout]

On 23/11/2022 04:11, Samuel Thibault wrote:

Arnaud Rebillout, le lun. 21 nov. 2022 15:52:47 +0700, a ecrit:

It's fairly easy to reproduce, for me it crashes every time, although it
doesn't always crash at the same moment of the installation. The exact
moment when it crashes seems quite unpredictable.

Note that I'm running the iso in a QEMU VM on an up-to-date Debian Sid,
so that's qemu-system-x86 7.1+dfsg-2+b2 and linux-image-amd64 6.0.8-1,
in case it matters.

Every detail can matter. Since it's in a vm, normally one should be able
to reproduce it, but it seems I can't. So please provide all details:

- how exactly you start the VM, notably which audio device do you use


My command is:

kvm -m 4G -cpu host \
-device e1000,netdev=net0 \
-netdev user,id=net0,hostfwd=tcp::10022-:22,hostfwd=tcp::3389-:3389 \
-device intel-hda \
-device hda-duplex \
-spice port=5930,disable-ticketing=on \
-device virtio-serial \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-chardev spicevmc,debug=0,id=vdagent,name=vdagent \
-vga qxl \
-virtfs local,mount_tag=home,path=/home/arno,security_model=none \
-drive file=debian-testing-amd64-netinst.img,format=raw \
-boot d -cdrom debian-testing-amd64-netinst.iso

I use remote-viewer and SPICE protocol to interact with the VM.



- during installation, which choices do you make that depart from the
   default value (language, tasks, etc.)


No choices, I just press Enter and stick with the defaults.

Maybe of interest, I see some errror messages in /var/log/syslog, after 
I confirm the second screen. Here's a good chunk of logs for context, 
the actual errors are the lines with "main-menu[527]: (process:):":


Nov 23 00:55:38 debconf: Setting debconf/language to en
Nov 23 00:55:38 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb

Nov 23 00:55:38 main-menu[527]: INFO: Menu item 'localechooser' selected
Nov 23 00:55:40 debconf: Setting debconf/language to en
Nov 23 00:55:47 init: starting pid 507, tty '/dev/tty2': '-/bin/sh'
Nov 23 00:56:05 localechooser: info: Language = 'en'
Nov 23 00:56:05 localechooser: info: line=en;0;US;en_US.UTF-8;;console-setup
Nov 23 00:56:05 localechooser: info: Set debian-installer/language = 'en'
Nov 23 00:56:05 localechooser: info: Default country = 'US'
Nov 23 00:56:05 localechooser: info: Default locale = 'en_US.UTF-8'
Nov 23 00:56:05 localechooser: info: Set debian-installer/consoledisplay 
= 'console-setup'

Nov 23 00:56:05 debconf: Setting debconf/language to en
Nov 23 00:56:08 localechooser: info: Set debian-installer/country = 'US'
Nov 23 00:56:08 localechooser: info: Set debian-installer/locale = 
'en_US.UTF-8'
Nov 23 00:56:08 localechooser: info: System locale 
(debian-installer/locale) = 'en_US.UTF-8'
Nov 23 00:56:08 main-menu[527]: (process:538): ls: 
/usr/share/mbrola/en[1-9]/en[1-9]: No such file or directory

Nov 23 00:56:08 main-menu[527]: (process:538): sh: missing ]
Nov 23 00:56:08 main-menu[527]: (process:538): ls: 
/usr/share/mbrola/en[1-9]/en[1-9]: No such file or directory

Nov 23 00:56:08 main-menu[527]: (process:538): sh: missing ]
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb

Nov 23 00:56:08 main-menu[527]: INFO: Menu item 'brltty-udeb' selected
Nov 23 00:56:08 main-menu[527]: WARNING **: Unable to set title for 
brltty-udeb.
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb

Nov 23 00:56:08 main-menu[527]: INFO: Menu item 'espeakup-udeb' selected
Nov 23 00:56:10 main-menu[527]: (process:1753): ls: 
/usr/share/mbrola/en[1-9]/en[1-9]: No such file or directory

Nov 23 00:56:10 main-menu[527]: (process:1753): sh: missing ]
Nov 23 00:56:10 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb
Nov 23 00:56:10 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb
Nov 23 00:56:10 main-menu[527]: INFO: Menu item 'console-setup-udeb' 
selected


The errors related to mbrola and sh come from 
debian/espeakup-udeb.restart in src:espeakup. I don't know if it's 
relevant to the issue at hand though.




Yes, I really doubt the bug is in espeakup (or pcaudiolib) itself since
these functions are really deep inside alsa, but we have to investigate
to be sure about it.


Just to confirm, I grabbed the debian-testing-amd64-netinst.iso from 
today (2022-11-22) and I can confirm that I can still reproduce the issue.


Another interesting detail is that restarting espeakup makes it speaks 
again, like if nothing happens. So I think it could be useful to have 
something monitor the daemon and restart it in case it crashes. Would 
make it more reliable overall,

Bug#1024549: espeakup: crashes during speech synthesis installation, snd_pcm_area_copy assertion failed

[Arnaud Rebillout]

Package: espeakup
Version: 1:0.90-11
Severity: normal
Tags: d-i
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

This bug was first reported in the Kali Linux installer, and it can be
reproduced in the Debian daily installer image [1].

The speech synthesis installation starts fine, but at some point,
there's no more sound. Therefore I open another console, type 'ps', I
can see that espeakup is not running. There's nothing in
/var/log/espeakup.log (the file is empty).

So I restart the process with additional debug argument:

  espeakup --alsa-volume -V en --debug

Back to the installer, the sound is back, I keep installing, until at
some point, it goes silent again. Back to the console, I can see that
espeakup crashed:

  espeakup: pcm.c:3237: snd_pcm_area_copy: Assertion `dst < src || dst >= src + 
bytes' failed.
  Aborted

It's fairly easy to reproduce, for me it crashes every time, although it
doesn't always crash at the same moment of the installation. The exact
moment when it crashes seems quite unpredictable.

Note that I'm running the iso in a QEMU VM on an up-to-date Debian Sid,
so that's qemu-system-x86 7.1+dfsg-2+b2 and linux-image-amd64 6.0.8-1,
in case it matters.

I'l try to debug further, but I'm not familiar with these low-level
bits. The assertion error happens in the alsa-lib source package (binary
package libasound2 is my guess), as you might have noticed. I really
have no clue how to debug that.

Best regards,

Arnaud

[1] 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/

Bug#1023383: git-buildpackage: gbp pull shows empty error message on failure

[Arnaud Rebillout]

Package: git-buildpackage
Version: 0.9.29
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

Today 'gbp pull' failed without giving me much details:

  $ gbp pull --verbose
  gbp:info: Fetching from default remote for each branch
  gbp:debug: ['git', 'rev-parse', '--show-cdup']
  gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
  gbp:debug: ['git', 'rev-parse', '--git-dir']
  gbp:debug: ['git', 'symbolic-ref', 'HEAD']
  gbp:debug: ['git', 'show-ref', 'refs/heads/kali/master']
  gbp:debug: ['git', 'status', '--porcelain']
  gbp:debug: ['git', 'fetch', '--quiet']
  gbp:debug: ['git', 'fetch', '--quiet', '--tags']
  gbp:error: Error running git fetch:

As you can see, the error message from 'git fetch' was not displayed. So
I had to go patch gbp and drop the '--quiet' argument from the 'git
fetch' command, so that I could understand what was the issue.

Output after I patched:

  $ gbp pull --verbose
  gbp:info: Fetching from default remote for each branch
  gbp:debug: ['git', 'rev-parse', '--show-cdup']
  gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
  gbp:debug: ['git', 'rev-parse', '--git-dir']
  gbp:debug: ['git', 'symbolic-ref', 'HEAD']
  gbp:debug: ['git', 'show-ref', 'refs/heads/kali/master']
  gbp:debug: ['git', 'status', '--porcelain']
  gbp:debug: ['git', 'fetch']
  gbp:debug: ['git', 'fetch', '--tags']
  gbp:error: Error running git fetch: From gitlab.com:kalilinux/packages/grub2
   ! [rejected]kali/2.06-3kali2 -> kali/2.06-3kali2  (would clobber 
existing tag)

That's much better!

Clearly, this '--quiet' argument gets in the way. So first, I tried to
understand where it comes from. I could track the addition of it to this
commit:

  8038a46e77b557ed234a0cfcb3c6109190d1b2c2
  Author: Guido Günther   2011-11-07 23:37:54
  Subject: GitRepository: fetch and pull quietly

Looking at the code, it seems that at the time (2011!) stdout/stderr
would be displayed "as is" by gbp, therefore the addition of '--quiet'
was meant to make gbp a bit more quiet. At least, that's how I
understand it.

Fast-forward today: the function 'fetch' calls '_git_command', which
captures stderr and stdout, and uses it only internally to display an
error message, if ever there's an error (cf.  `gbp/git/repository.py`).
Then it's discarded (not returned to the caller).

So it seems to me that there's no good reason to use '--quiet' anymore.

Please find a tentative change at:
https://salsa.debian.org/arnaudr/git-buildpackage/-/commit/4c798909

Best regards,

Arnaud



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, 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)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.22.2
ii  git1:2.37.2-1
ii  man-db 2.11.0-1+b1
ii  python33.10.6-1
ii  python3-dateutil   2.8.2-1
ii  python3-pkg-resources  65.5.0-1
ii  python3-yaml   5.4.1-1+b2
ii  sensible-utils 0.0.17

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.49
ii  python3-requests  2.27.1+dfsg-1
ii  sbuild0.83.2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.11p3-2
ii  unzip6.0-27

-- no debconf information

Bug#1023379: git-buildpackage: FTBFS with Git 2.38.1

[Arnaud Rebillout]

Package: git-buildpackage
Version: 0.9.29
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

I tried to rebuild git-buildpackage locally and the submodule tests
fail:


==
ERROR: Add a submodule
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/build/git-buildpackage-JtfSq8/git-buildpackage-0.9.29/tests/04_test_submodules.py",
 line 99, in test_add_submodule
REPO.add_submodule(SUBMODULES[0].dir)
  File 
"/build/git-buildpackage-JtfSq8/git-buildpackage-0.9.29/gbp/git/repository.py", 
line 1938, in add_submodule
self._git_command("submodule", ["add", repo_path])
  File 
"/build/git-buildpackage-JtfSq8/git-buildpackage-0.9.29/gbp/git/repository.py", 
line 245, in _git_command
raise GitRepositoryError("Error running git %s: %s" % (command, 
detail.decode().strip()))
gbp.git.repository.GitRepositoryError: Error running git submodule: Cloning 
into '/tmp/tmp7tjw_zrzgbp_tests.04_test_submodules_/test_repo/test_submodule'...
fatal: transport 'file' not allowed
fatal: clone of '/tmp/tmp7tjw_zrzgbp_tests.04_test_submodules_/test_submodule' 
into submodule path 
'/tmp/tmp7tjw_zrzgbp_tests.04_test_submodules_/test_repo/test_submodule' failed
 >> begin captured logging << 
gbp: debug: ['git', 'submodule', 'add', 
'/tmp/tmp7tjw_zrzgbp_tests.04_test_submodules_/test_submodule']
- >> end captured logging << -


This is due to a recent change in Git, and it's documented at:
* 
https://vielmetti.typepad.com/logbook/2022/10/git-security-fixes-lead-to-fatal-transport-file-not-allowed-error-in-ci-systems-cve-2022-39253.html
* https://bugs.launchpad.net/ubuntu/+source/git/+bug/1993586

Please find a tentative fix at:
https://salsa.debian.org/arnaudr/git-buildpackage/-/commit/5a73cf0e

I tried using REPO.set_config() but it didn't work, so I used the
environment instead.

Best,

Arnaud



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, 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)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.22.2
ii  git1:2.37.2-1
ii  man-db 2.11.0-1+b1
ii  python33.10.6-1
ii  python3-dateutil   2.8.2-1
ii  python3-pkg-resources  65.5.0-1
ii  python3-yaml   5.4.1-1+b2
ii  sensible-utils 0.0.17

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.49
ii  python3-requests  2.27.1+dfsg-1
ii  sbuild0.83.2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.11p3-2
ii  unzip6.0-27

-- no debconf information

Bug#1004421: ITS: cadaver

[Arnaud Rebillout]

On 31/10/2022 06:23, Hugh McMaster wrote:

I'm pleased to report that we have a new upstream version, 0.24.


I just uploaded it (look for version 0.24+dfsg-1 in Debian Sid).

Please give it a try and don't hesitate to report any issue.

Cheers,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1004421: ITS: cadaver

[Arnaud Rebillout]

Hi Hugh,

On 31/10/2022 06:23, Hugh McMaster wrote:

Hi Sebastian and Arnaud,

I've been working with upstream [1] to fix several issues in cadaver,
particularly its inability to regenerate its build system from source,
which is a major issue.

I'm pleased to report that we have a new upstream version, 0.24.

I believe Arnaud has taken over as maintainer but wanted to inform you
both of the new version.

Please let me know if you need any help with package maintenance. In
particular, this new version is a good opportunity to switch to dh
format in d/rules.

Bugs fixed by this upstream release include 605121 [2], 879882 [3] and
949059 [4].

Hugh

[1] https://github.com/notroj/cadaver
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605121
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879882
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949059


I will look into that and hopefully upload this new version in Debian 
this week.


Thanks for the ping and all the details, it's really helpful!

Cheers

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1023037: ITS: goodvibes

[Arnaud Rebillout]

Package: goodvibes
Version: 0.7.2-0.1
Severity: important
X-Debbugs-Cc: sergi...@debian.org

Dear Maintainer,

I would like to maintain this package from now on. Disclaimer: I'm also
the upstream author of this program.

The reason for me taking over this package is that the current
maintainer Elías doesn't seem to be around anymore:

* Dec 2021: I did the last upload (version 0.7.2-0.1), it was sponsored
  by Sergio (CC in this email).
* Apr 2022: I opened a bug to notify of a new upstream release [2], but
  there was no answer so far.

Elias, if you see this email, please answer! You are very welcome to
keep maintaining this package if you wish to do so. Otherwise I'm happy
to take care of it from now on.

All the best,

Arnaud

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993929#12
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009355

Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1

[Arnaud Rebillout]

On 26/10/2022 23:20, Michael Tokarev wrote:

Control: forward -1 https://bugzilla.samba.org/show_bug.cgi?id=15205
Control: tag -1 + upstream patch

Ok, there's a bugreport in samba (see above), and the fixes went to 
4.17.1,

but not to 4.16.6 (they're in 4.16-test, though.

I can probably make another 4.16 upload - was thinking about making 4.17
the default finally but decided to wait for yet another minor release due
to another symlink attack issue found in the new 4.17 code.

Oh well. I hate useless work, - it is useless to push the already pending
patches. But the next 4.16.7 is scheduled for Jan 05 2023, which is quite
some time from now.

Hwell..


Thanks Michael!

Arnaud

Bug#1022826: [Pkg-samba-maint] Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1

[Arnaud Rebillout]

On Wed, 26 Oct 2022 18:13:51 +0300 Michael Tokarev  wrote:
> Control: tag -1 + moreinfo unreproducible
>
> 26.10.2022 17:45, Arnaud Rebillout wrote:
> > Package: samba-common-bin
> > Severity: normal
> > User: de...@kali.org
> > Usertags: origin-kali
> >
> > Dear Maintainer,
> >
> > This command fails:
> >
> > # testparm /etc/samba/smb.conf --suppress-prompt
> > Load smb config files from <>
> > Error loading services.
>
> Which version of samba-common-bin is that?
>
> I was about to close this bug right away because you didn't
> specify a version. But I'd give it a try anyway.
>
> The thing is that the libpopt is bundled with samba sources, and
> current samba in debian unstable (4.16.6+dfsg-3) already has the
> necessary fixes for it. There should be, in theory, no issues with
> the fixed/new libpopt.
>
> I just tested that one with current libpopt, - it works as expected
> here.

Sorry about forgetting the version.

So this is version 2:4.16.6+dfsg-3. Right now I can fire a Debian sid 
container and reproduce the issue with:


  # apt update && apt install -y smbclient
  # testparm /etc/samba/smb.conf --suppress-prompt
  Load smb config files from gW???U
  Error loading services.

NB: you MUST pass /etc/samba/smb.conf in argument to trigger the issue.

The issue with libpopt seems to be documented at 
https://github.com/rpm-software-management/popt/issues/80.


However I didn't notice that samba embeds its own libpopt, so now I'm 
confused. Are you 100% sure it's the embedded lib that is used?


  # ldd /usr/bin/testparm | grep popt
  libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x7f52a45d1000)

Or does the line above suggests that it uses the shared library? (real 
question, I'm not familiar with ldd)


Cheers, and thanks for the quick reply.

Arnaud

Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1

[Arnaud Rebillout]

Package: samba-common-bin
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

This command fails:

  # testparm /etc/samba/smb.conf --suppress-prompt
  Load smb config files from <>
  Error loading services.

However this command succeeds:

  # testparm --suppress-prompt
  [...]

The second command is identical to the first one, except that we don't
explicitly pass the location of the config file to test. If not
specified, the default config file is /etc/samba/smb.conf.

It seems that the issue is due to the package libpopt0. The command
worked fine with libpopt0 1.18-3, and it crashes with libpopt0
1.19+dfsg-1 that just landed in Debian testing, hence in Kali Linux.

The issue was initially reported in the Kali bug tracker at
https://bugs.kali.org/view.php?id=8024#c17003, and it can be reproduced
in Debian unstable.

Thanks,

Arnaud

Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

On 24/10/2022 21:55, Christopher Obbard wrote:

I'm more leaning on just adding it as a direct Dependency to the Debos
package and seeing if anyone moans...

Works for me.

Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

On 24/10/2022 17:34, Christopher Obbard wrote:

I have proposed[1] to check if systemd-resolved is available at
runtime, to at least let users know *why* name resolution doesn't work
inside their fakemachine over letting the user debugging it themselves.
[1]:https://github.com/go-debos/fakemachine/pull/115


That's nice! I thought of it as well, and I was wondering if 
systemd-resolved (and possibly other services) should be listed under 
Requires= instead of Wants= (talking about 
https://github.com/go-debos/fakemachine/blob/main/machine.go#L288). But 
then, I noticed commit 4c60b85a8302f0fa544adae73f0649726034711c, and why 
using Wants= is the intention. So your approach works better.




Perhaps we should add systemd-resolved to Suggests in
debos/fakemachine? Adding it as a Depends/Recommends would break users
who have some other package on their machine handling name resolution.

@Arnaud, how does that sound?


Well, I'm not sure for the packaging part. If fakemachine needs 
systemd-resolved to be functional, then it should be a Depends. That's 
what Depends is for.


At a quick glance, there's no reverse dependencies of fakemachine / 
debos. So the only users that would be surprised by the change are the 
ones who installed it explicitly, so we can assume those are technical 
users and they'll find their way? But then, what if there are some 
installations on servers (think builders), and the upgrade breaks the 
name resolution? Not a nice surprise.


OTOH, an error message saying that "/lib/systemd/systemd-resolved is 
missing", plus a Suggests: systemd-resolved, both together gives a 
strong hint regarding what should be done. It sounds sensible as well.


Sorry, that's not really a clear answer :)

Best,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#907878: xrdp: gnome session asks permission for colord

[Arnaud Rebillout]

Regarding colord, I noticed that Fedora now ships the files 
xrdp-polkit-1.rules [1], so that XRDP + colord works out of the box. 
It's in the new Javascript format for polkit (cf. 
/usr/share/doc/polkitd/NEWS.Debian.gz). Maybe the xrdp Debian package 
could do the same?


Cheers,

Arnaud

--

[1]: 
https://src.fedoraproject.org/rpms/xrdp/blob/rawhide/f/xrdp-polkit-1.rules

Bug#1021702: debian-cd: Take constraints into account while building the cd packages pool

[Arnaud Rebillout]

Package: debian-cd
Version: debian-cd: Please take constraints into account while building the cd 
packages pool
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

I'm documenting here something that we've hit in Kali lately. The
installer didn't include a package that was depended upon, and
therefore the installation failed.

The offending package was king-phisher (only in Kali). Syslog said:

  in-target: The following packages have unmet dependencies:
  in-target:  king-phisher : Depends: python3-matplotlib (>= 1.4.3) but it is 
not installable
  in-target: Recommends: python3-mpltoolkits.basemap (>= 1.0.7) 
but it is not installable
  
By entering a chroot, and trying to install the king-phisher package,
using the pool of packages provided in the Kali installer, I get:

  # apt install king-phisher
  [...]
  The following packages have unmet dependencies:
   python3-fonttools : Depends: python3-unicodedata2 (>= 14.0.0) but it is not 
installable or
python3-all (>= 3.11.0) but 3.10.6-1 is to be 
installed
  E: Unable to correct problems, you have held broken packages.

Looking at the dependency tree now:

  king-phisher
  +-- python3-matplotlib
+-- python3-fonttools
  +-- python3-unicodedata2 (>= 14.0.0) | python3-all (>= 3.11.0)
  
In the pool of packages that are available in the Kali iso, we don't
have python3-unicodedata2 , however we have python3-all , BUT it's at
version 3.10.6-1 ... So nothing can satisfy the dependency.

So it looks to me that it's a bug in debian-cd. I guess that the
resolver that decides which packages are included in the pool didn't
include python3-unicodedata2 because there was python3-all already, but
it didn't take into account the constraints >= 3.11.0.

As a sidenote, it looks like the maintainer of python3-fonttools is a
bit ahead of time, his package depends on python3-unicodedata2 (>=
14.0.0) | python3-all (>= 3.11.0) but 3.11 is not yet released, it's
planned for end of October.

Note that this is an issue only for installers that don't have access to
the network. If network is available, I guess that python3-unicodedata2
will be fetched from a remote package repository, so no problem for most
users.

Thanks,

Arnaud

Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

On 05/10/2022 22:06, Michael Biebl wrote:
I think if you want to assemble a root/usr fs where you don't want do 
"disturb" the host system, I'd use a debootstrapped chroot but not the 
host fs.


I think the original reason for fakemachine to exist was to build OS 
images from within containers. At first it doesn't sound like a great 
idea, because usually there's not enough capabilities in the container 
for that (ie. no access to the loop device). But systems like Jenkins or 
GitLab CI drop you in a container, you have no choice. So fakemachine 
came as a solution / workaround to spawn a VM from within a container 
(according that you have access to /dev/kvm), and then from within the 
VM you can build an OS image.


Hence this weird approach of "faking a machine", ie. creating a VM by 
reusing bits from the host filesystem. To say it again: if you're 
already within an environment that has been setup for the job (chroot or 
container), no need to debootstrap a chroot again, let's just make sure 
this environment has everything needed, and re-use it for the VM. That's 
the approach of fakemachine, as I understand it.


And so, for this use-case when fakemachine is used from within a 
chroot/container, I must say that the systemd-resolved split is not 
really problematic: all it takes is to add systemd-resolved to the list 
of packages to install in the chroot/container.


The issue is for people installing fakemachine on their own machine. So 
far it worked great (I've been using it a lot to build OS images). Now 
it doesn't anymore. So either I install systemd-resolved, either I start 
a chroot and run fakemachine from there. It doesn't work "out of the 
box" anymore, if you want.



Say you want to install apache2 in your fakemachine managed VM, this 
would also start it on the host system, or not?


Yes, but this comparison is not really relevant here. systemd-resolved 
is needed for the VM to have a functional network, so it's really a 
prerequisite for a functional VM, regardless of what users want to do 
with it. Hence the question of whether it should become a Depends for 
the fakemachine package.


While apache2 will never be a Depend of fakemachine in any case, and if 
users have a need for a particular need for that, it's in their hand to 
decide how to do it.


Maybe fakemachine is more or less a VM counterpart of "systemd-nspawn -D 
/ -xb" (systemd-nspawn(1), example 6)?


I hope that I clarified a few points here. Would be nice to hear more 
from fakemachine maintainers.


Best regards,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

On 05/10/2022 16:58, Christopher Obbard wrote:

Hi Arnaud,

Thanks for shedding the extra light. This is not a nice bug !

I think we should ask the systemd maintainer if they'd accept a patch
to make the enabling of systemd-resolved service a manual operation, or
at least to split the binary into a separate package, something like
systemd-standalone-resolved ?



Dear systemd maintainers,

the packages fakemachine & debos (which uses fakemachine) are facing an 
issue now that systemd-resolved was split in a separate package.


For the background: fakemachine is a program that spawns a QEMU VM that 
"mimics" the host. It does so mainly by mounting /usr from the host into 
the VM, plus a few other bits from here and there. For the network to 
work in the VM, it relies on systemd-networkd and systemd-resolved. 
These programs need to be present on the host, so that they are 
available in the VM.


For more details, you can just run "fakemachine" in a shell, then "ps 
fax | grep qemu" in another shell: you will see how fakemachine uses qemu.


So far, the package fakemachine Depends on systemd, and that was enough. 
Now with the split, and since we need systemd-resolved, we should make 
fakemachine Depend on systemd-resolved as well. However, and if I 
understand properly, installing systemd-resolved also *enables* it. A 
user installing the package is saying: I want name resolution to be done 
by systemd-resolved. Therefore it's not really suitable to put it in a 
Depend or a Recommend. fakemachine only needs the code from 
systemd-resolved (lib and binary, I suppose), but it definitely doesn't 
want to enable it: this decision belongs to the user.


Does that make sense so far?

I don't know how to solve best this situation. Maybe the the lib and 
binaries could go back into the systemd package, leaving only the 
"enablement" part in systemd-resolved?


Thanks!

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

> On Sun, 25 Sep 2022 12:28:19 +0100 Christopher Obbard
>  wrote:
> > Because of this, on a machine which does not have
> > systemd-resolved installed, debos no longer works as
> > intended.
> >
> > Please add systemd-resolved as a runtime dependency to debos.
>
> It will fix debos but might break user's setup, or at least surprise
> user, because systemd-resolved will take over name resolution
> on the machine where it's installed.
>
> Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020288

This comment also applies to fakemachine bug:
https://bugs.debian.org/1020690

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

Hello Christopher!

On Sun, 25 Sep 2022 12:28:19 +0100 Christopher Obbard 
 wrote:
> Because of this, on a machine which does not have systemd-resolved 
installed,

> debos no longer works as intended.
>
> Please add systemd-resolved as a runtime dependency to debos.

It will fix debos but might break user's setup, or at least surprise user,
because systemd-resolved will take over name resolution on the
machine where it's installed.

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

Best,

Arnaud

Bug#1021231: dpdk: Consider increasing the timeout for test-fastsuite

[Arnaud Rebillout]

Source: dpdk
Version: 21.11-5
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

I've noticed that the autopkgtests for dpdk tend to fail. Looking at  
https://ci.debian.net/packages/d/dpdk/testing/amd64/, the 10 most recent
test failures are all caused by a timeout of pflock_autotest and
ticketlock_autotest, which are part of test-fastsuite.

I wonder if it's expected, and if the timeout should be increased.
Timeout is defined in debian/tests/test-fastsuite, the option "-t 3"
causes the timeout to be 3 x 10 = 30 seconds.

NB: I don't know anything about dpdk, I just took a bit of time to
investigate why the autopkgtests fail.  We also see these failures
when those tests run on the Kali Linux infra:
https://autopkgtest.kali.org/packages/d/dpdk/kali-rolling/amd64/

Best regards,

Arnaud

Bug#1020288: debos: unable to resolve host address

[Arnaud Rebillout]

Package: debos
Version: 1.0.0+git20210707.c66a48d-2+b2
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: dai...@debian.org

Dear Maintainer,

at the moment debos (and fakemachine) is broken in unstable:


$ cat debootstrap.yaml
architecture: amd64

actions:
  - action: debootstrap
suite: stable

$ debos debootstrap.yaml
Running /debos --artifactdir /home/arno/kali/proj/vm-images/kali-vm/tmp 
/home/arno/kali/proj/vm-images/kali-vm/tmp/debootstrap.yaml using kvm backend
2022/09/19 10:49:09  debootstrap 
2022/09/19 10:49:09 Debootstrap | W: Unable to read /etc/apt/apt.conf.d/ - 
DirectoryExists (2: No such file or directory)
2022/09/19 10:49:09 Debootstrap | W: Unable to read /etc/apt/apt.conf.d/ - 
DirectoryExists (2: No such file or directory)
2022/09/19 10:49:09 Debootstrap | I: Target architecture can be executed
2022/09/19 10:49:09 Debootstrap | I: Retrieving InRelease
2022/09/19 10:49:09 Debootstrap | I: Retrieving Release
2022/09/19 10:49:09 Debootstrap | E: Failed getting release file 
http://deb.debian.org/debian/dists/stable/Release
2022/09/19 10:49:09 debootstrap.log | amd64: ok
2022/09/19 10:49:09 debootstrap.log | wget: unable to resolve host address 
'deb.debian.org'
2022/09/19 10:49:09 debootstrap.log | wget: unable to resolve host address 
'deb.debian.org'
2022/09/19 10:49:09 Action `debootstrap` failed at stage Run, error: exit 
status 1
Powering off.


Hostname resolution broke because systemd-resolved was split out of the
systemd package, and now it lives in its own package systemd-resolved. 
On my system, systemd-resolved is not installed, hence the failure 
above. Apparently systemd-resolved is mandatory for the kvm backend?
What about the uml backend?

At a first glance, it seems that debos (and fakemachine) should now 
Depend on systemd-resolved. However it's a bit more complicated.

Installing the package systemd-resolved has MAJOR consequences:
- the postinst script will remove /etc/resolv.conf, and replace it with
  a symlink to ../run/systemd/resolve/stub-resolv.conf
- the service systemd-resolved will be enabled

This behavior makes sense when a user manually installs systemd-resolved
(because they want to use it for name resolution). But when installing
debos, enabling name resolution via systemd-resolved at the same time is
surely an unintended (and unexpected) effect.

I don't know how to handle that. I don't know if it would be possible to
rework the systemd-resolved package and split it, so that it's possible
to install the binaries, without actually enabling it. Maybe we should
ask the systemd maintainer, but I wanted to get your impression first.

Thanks!

Arnaud

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-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=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 debos depends on:
ii  busybox1:1.35.0-2
ii  debootstrap1.0.127
ii  libc6  2.34-7
ii  libglib2.0-0   2.73.3-3
ii  libostree-1-1  2022.5-3
ii  qemu-system-x861:7.0+dfsg-7+b1
ii  qemu-user-static   1:7.0+dfsg-7+b1
ii  systemd-container  251.4-3

Versions of packages debos recommends:
ii  bmap-tools 3.6-1
ii  bzip2  1.0.8-5
ii  e2fsprogs  1.46.5-2
ii  linux-image-amd64  5.19.6-1
ii  mount  2.38.1-1
ii  ovmf   2022.05-4
ii  parted 3.5-1
ii  udev   251.4-3
ii  xz-utils   5.2.5-2.1
ii  zip3.0-12

debos suggests no packages.

-- no debconf information

Bug#1020277: 20copyfiles: cp: not writing through dangling symlink

[Arnaud Rebillout]

Package: schroot
Version: 1.6.13-2
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

in a chroot I need to install systemd-resolved. systemd-resolved creates
a symlink etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf,
which is a dangling symlink.

Consequently, schroot fails to start the chroot:

  E: 20copyfiles: cp: not writing through dangling symlink 
'<>/etc/resolv.conf'
  E: <>: Chroot setup failed: stage=setup-start

To reproduce:


# debootstrap sid sid-resolved

# cat << EOF > /etc/schroot/chroot.d/sid-resolved
[sid-resolved]
type=directory
directory=$(pwd)/sid-resolved
profile=default
groups=root,sbuild
root-groups=root,sbuild
EOF

# schroot -c sid-resolved -- sh -c "apt-get update && apt-get install -y 
systemd-resolved"

# schroot -c sid-resolved 
E: 20copyfiles: cp: not writing through dangling symlink 
'/var/run/schroot/mount/sid-resolved-2b844c78-1704-45e6-a260-6e8271ea2f2d/etc/resolv.conf'
E: sid-resolved-2b844c78-1704-45e6-a260-6e8271ea2f2d: Chroot setup failed: 
stage=setup-start

# ls -l sid-resolved/etc/resolv.conf
lrwxrwxrwx 1 root root 39 Sep 19 14:40 sid-resolved/etc/resolv.conf -> 
../run/systemd/resolve/stub-resolv.conf


We can force cp to copy the file anyway by using the option
--remove-destination. Cf. merge request at:
https://codeberg.org/shelter/reschroot/pulls/4

Regards,

Arnaud

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-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=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 schroot depends on:
ii  debconf [debconf-2.0]   1.5.79
ii  libboost-filesystem1.74.0   1.74.0-17
ii  libboost-iostreams1.74.01.74.0-17
ii  libboost-program-options1.74.0  1.74.0-17
ii  libc6   2.34-7
ii  libgcc-s1   12.2.0-2
ii  libpam0g1.5.2-2
ii  libstdc++6  12.2.0-2
ii  libuuid12.38.1-1
ii  schroot-common  1.6.13-2
ii  sysvinit-utils [lsb-base]   3.05-2

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-tools | unionfs-fuse  
pn  btrfs-progs
ii  bzip2  1.0.8-5
ii  debootstrap1.0.127
ii  lvm2   2.03.16-1
ii  qemu-user-static   1:7.0+dfsg-7+b1
ii  xz-utils   5.2.5-2.1
pn  zfsutils-linux 
ii  zstd   1.5.2+dfsg-1

-- debconf information:
  schroot/bad-names:

Bug#1016644: simple-cdd: Please allow to preseed the 'error' type

[Arnaud Rebillout]

On Thu, 04 Aug 2022 15:57:36 +0200 Arnaud Rebillout  
wrote:

>
> Note that the error message above seems to come from debconf, and I
> wonder if it can be solved by adding 'error' to the list of known types
> here: 
https://sources.debian.org/src/debconf/1.5.79/debconf-set-selections/#L154


No, it doesn't work, I just tried.

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1016644: simple-cdd: Please allow to preseed the 'error' type

[Arnaud Rebillout]

Package: debian-cdd
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

Lately I tried to preseed a question of the type 'error', and it wasn't
really straightforward.

Such a question can be seen in the package encfs, at:
https://sources.debian.org/src/encfs/1.9.5-1/debian/encfs.templates

The template looks like that:

  Template: encfs/security-information
  Type: error
  _Description: Encfs security information
   According to a security audit by Taylor Hornby (Defuse Security), the current
   [...]

In effect, when the package encfs is installed by the Debian installer,
it displays an error message. It's not really a question, it's simply an
error message.

I tried to use preseeding to prevent the Debian installer from showing
this message. The tentative preseed line that I applied was:

  encfs encfs/security-information seen true

However, this leads to a build failure in live-build-config:

  $ ./build.sh --verbose --installer --variant netinst
  [...]
  2022-08-04 10:05:37,846 DEBUG Checking configuration...
  error: Cannot find a question for encfs/security-information
  2022-08-04 10:05:38,016 ERROR preseed file invalid:
<>/simple-cdd/profiles/default.preseed

Fortunately, there's a workaround! We have to apply this preseeding instead:

  encfs encfs/security-information boolean true
  encfs encfs/security-information seen true

It seems like the first line is enough to trick simple-cdd/debconf into
accepting the second line. This workaround has been use to build the
Kali Linux ISOs:
https://gitlab.com/kalilinux/build-scripts/live-build-config/-/commit/d9040785

Note that the error message above seems to come from debconf, and I
wonder if it can be solved by adding 'error' to the list of known types
here: https://sources.debian.org/src/debconf/1.5.79/debconf-set-selections/#L154

To finish this report, a few URLs showing that other people struggle
with this issue:
- https://bugs.launchpad.net/ubuntu/+source/encfs/+bug/1672827
- https://askubuntu.com/q/1401467/424636

Thanks,

Arnaud

Bug#933298: qcontrold systemd unit possible typo

[Arnaud Rebillout]

There seems to be a small typo, related 
tohttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781886,
in the qcontrold systemd unit.

The unit depends on:
/dev/input/by-path/platform-gpio_keys-event

The actual file to watch for seems to be:
/dev/input/by-path/platform-gpio-keys-event



Just updated my QNAP TS-219 to Debian bullseye. For me, the path is with 
an underscore (/dev/input/by-path/platform-gpio_keys-event), so it's all 
good.

Bug#1015845: about gtkhash ITA

[Arnaud Rebillout]

Hello Sheng Wen,

On Fri, 29 Jul 2022 09:08:20 +0800 
=?UTF-8?B?eGlhbyBzaGVuZyB3ZW4o6IKW55ub5paHKQ==?=  wrote:

>     Do you want ITA gtkhash package now?
> This package had orphan now, see #1015845.
>
> If you don't want ITA it, I would do ITA.

please feel free to ITA this package. I don't have much time to work on 
it myself.


Don't forget to have a look at 
https://gitlab.com/kalilinux/packages/gtkhash and cherry-pick any commit 
you need from there!


Thanks for reaching out, and thanks for taking care of gtkhash,

Regards,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed

[Arnaud Rebillout]

On Thu, 14 Jul 2022 20:14:15 +0200 Ben Hutchings  
wrote:

>
> You should find out why that is, before proposing to override it. What
> if something in KDE really does need FUSE 2?

I don't think that it can happen. A package might need FUSE3 (in such 
case it depends on fuse3), or it might need FUSE (any implementation) 
(in such case it depends on fuse, and it's either fuse or fuse3 that 
will be installed, as fuse3 Provides fuse). But it cannot really ask for 
FUSE2, as far as I understand (there's no fuse2 package).


In the case I described above, if fuse gets installed, it's not because 
a package needs FUSE2, it's because no package needs FUSE3. So apt picks 
fuse rather than fuse3.


> (Since you found that removing fuse doesn't remove anything else, this
> implies that the relationship is only a Recommends and not a Depends.
> But that doesn't mean that removal won't break anything.)

I believe that if replacing fuse by fuse3 doesn't remove anything, it's 
because fuse3 Provides fuse.


In any case: in Kali we solved that by recommending fuse3 in 
kali-desktop-core, a metapackage that is always installed with every 
Kali desktop. Therefore we're sure to have fuse3 (we don't let apt 
guess), and we're sure that open-vm-tools will be installed if needed. 
It's a better solution than modifying hw-detect as I suggested here.


Therefore I'll close this bug, as I don't think it affects Debian anyway.

Thanks for your feedback, and sorry for the noise.

Arnaud

Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed

[Arnaud Rebillout]

Source: hw-detect
Version: 1.147
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

The package open-vm-tools 11.3.5, released in January 2022, depends on
fuse3 rather than fuse [1].

As a consequence, hw-detect fails to install open-vm-tools if ever the
package fuse was already installed. This is because installing fuse3
would cause the removal of fuse, and removals are not allowed.

This can be seen in the logs of the installer:

in-target: The following additional packages will be installed:
in-target:   ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3
in-target:   libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5
in-target:   libsigc++-2.0-0v5 open-vm-tools zerofree
in-target: Suggested packages:
in-target:   cloud-init
in-target: The following packages will be REMOVED:
in-target:   fuse
in-target: The following NEW packages will be installed:
in-target:   ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3
in-target:   libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5
in-target:   libsigc++-2.0-0v5 open-vm-tools open-vm-tools-desktop zerofree
in-target: 0 upgraded, 13 newly installed, 1 to remove and 0 not upgraded.
in-target: E: Packages need to be removed but remove is disabled.

In practice, it hits Kali Linux users, as reported in [2]. For some
reasons, fuse gets installed if users install the KDE desktop for Kali.

Does it happen in Debian as well? A quick check tells me that it does
NOT happen for GNOME, as gnome-core Depends on gvfs-fuse which Depends
on fuse3. But for other desktop environments I don't know.

I've seen that the script apt-install supports an option --allow-remove,
so I wonder if we could make use of it in this case, to make installing
open-vm-tools more reliable.

For example, this kind of patch:

diff --git a/hw-detect.finish-install.d/08hw-detect 
b/hw-detect.finish-install.d/08hw-detect
index a91bff07..5269f114 100755
--- a/hw-detect.finish-install.d/08hw-detect
+++ b/hw-detect.finish-install.d/08hw-detect
@@ -103,10 +103,12 @@ enable_modules_loading() {

 case "$(detect_virt)" in
 vmware)
+   # open-vm-tools depends on fuse3, which Replaces fuse,
+   # so we allow removal in case fuse is already installed.
if detect_desktop; then
-   apt-install --with-recommends open-vm-tools-desktop || true
+   apt-install --with-recommends --allow-remove open-vm-tools-desktop 
|| true
else
-   apt-install --with-recommends open-vm-tools || true
+   apt-install --with-recommends --allow-remove open-vm-tools || true
fi
;;
 oracle)

Does anyone has an opinion on that? I can submit a patch if you think
it's a good idea.

Cheers,

Arnaud



NB: fuse3 seems to be a drop-in replacement for fuse:

Package: fuse3
Version: 3.11.0-1
[...]
Provides: fuse (= 3.11.0-1)
Depends: libc6 (>= 2.33), libfuse3-3 (= 3.11.0-1), adduser,
 mount (>= 2.19.1), sed (>= 4), lsb-base (>= 3.2-14)
Breaks: fuse
Replaces: fuse



References:

[1]: 
https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/commit/d5176b54
[2]: https://bugs.kali.org/view.php?id=7774

Bug#1009355: goodvibes: New upstream version 0.7.4 available

[Arnaud Rebillout]

On Tue, 12 Apr 2022 16:06:35 +0700 Arnaud Rebillout  
wrote:

> latest version of Goodvibes was released a few weeks ago:
> https://gitlab.com/goodvibes/goodvibes/-/tags/v0.7.4

Just a ping :)

Bug#1007022: podman: starting rootless container fails with: can't get final child's PID from pipe: EOF

[Arnaud Rebillout]

Hi Shengjing,

On Sun, 19 Jun 2022 15:28:32 +0800 Shengjing Zhu  wrote:
> Can someone checks if you still fail to run rootless container with
> runc and podman 4.1?
>
> I think it's because
> https://github.com/containers/podman/issues/13731, which is fixed in
> podman 4.1.
> And it's caused by systemd 250 which changes OOMScoreAdjust in 
user@.service


I just tried, and it seems that indeed, podman 4.1 fixes the issue. Here 
are the steps I followed:


1) I removed the package crun, so that I only have runc installed:

    $ sudo apt purge crun

2) From this point, I can reproduce the issue:

    $ podman run --rm -it kali-rolling
    Error: OCI runtime error: runc create failed: unable to start 
container process: can't get final child's PID from pipe: EOF


3) Now I install podman from experimental:

    $ sudo apt install -t experimental podman
    Get:1 http://deb.debian.org/debian experimental/main amd64 
golang-github-containers-common all 0.48.0+ds1-1 [34.5 kB]
    Get:2 http://deb.debian.org/debian experimental/main amd64 podman 
amd64 4.1.0+ds2-2 [9,997 kB]
    Get:3 http://deb.debian.org/debian experimental/main amd64 buildah 
amd64 1.26.1+ds1-1 [6,041 kB]


4) Tried to run podman rootless again:

    $ podman run --rm -it kali-rolling
    ┌──(root㉿633e94a0ebde)-[/]
    └─#

It works!

Thanks,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#984516: [git-buildpackage/master] import-dsc: Fix error message when missing debian branch

[Arnaud Rebillout]

tag 984516 pending
thanks

Date:   Thu Mar 4 21:23:48 2021 +0700
Author: Arnaud Rebillout 
Commit ID: abce93c865b6592aaa3940bde7db776af8e98604
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=abce93c865b6592aaa3940bde7db776af8e98604
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=abce93c865b6592aaa3940bde7db776af8e98604

import-dsc: Fix error message when missing debian branch

The error message mistakenly talks about the upstream branch when it
should be talking about the debian branch. Logs:

# initial failure
$ gbp import-dsc apt:desktop-base/sid
gbp:info: Downloading 'desktop-base/sid' using 'apt-get'...
gbp:info: Tag 11.0.2 not found, importing Debian tarball
gbp:error:
Repository does not have branch 'master' for upstream sources. If 
there is none see

file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
on howto create it otherwise use --upstream-branch to specify it.

Also check the --create-missing-branches option.

# trying as suggested
$ gbp import-dsc --upstream-branch=debian apt:desktop-base/sid
gbp:info: Downloading 'desktop-base/sid' using 'apt-get'...
gbp:info: Tag 11.0.2 not found, importing Debian tarball
gbp:error:
Repository does not have branch 'master' for upstream sources. If 
there is none see

file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
on howto create it otherwise use --upstream-branch to specify it.

Also check the --create-missing-branches option.

# in fact it's the debian branch!
$ gbp import-dsc --debian-branch=debian apt:desktop-base/sid
gbp:info: Downloading 'desktop-base/sid' using 'apt-get'...
gbp:info: Tag 11.0.2 not found, importing Debian tarball
gbp:info: Version '11.0.2' imported under 
'/home/user/src/desktop-base'

Closes: #984516

  

Bug#1004421: ITS: cadaver

[Arnaud Rebillout]

CC Sebastian Harl in case it helps

Sebastian are you Ok if I take over this package and maintain it within 
pkg-security-team?


Cheers

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1007022: podman: starting rootless container fails with: can't get final child's PID from pipe: EOF

[Arnaud Rebillout]

I can reproduce it locally.

For background: I just setup a new machine, and I installed both 
docker.io and podman. Since docker.io depends on runc, and podman 
depends on crun|runc, only runc was installed.


The issue is fixed after installing crun manually (note that both runc 
and crun can be installed on the system, it doesn't seem to cause any 
issue).


Cheers,

Arnaud