Bug#1067874: Allow trailing whitespace in apt patterns

[Trent W. Buck]

Package: apt
Version: 2.7.14
Severity: wishlist

I think this is a bug:

root@hera:/# apt list '?source-package(^mg$) '
Listing... Error!
E: input:21-22: error: Expected end of file
   ?source-package(^mg$)
^

I think apt should ignore trailing whitespace, just as it ignores leading 
whitespace.

Here is a more complete transcript:

bash5$ mmdebstrap bookworm /dev/null --quiet --customize-hook='chroot $1'
root@hera:/# dpkg-query -W apt
apt 2.6.1
root@hera:/# apt --version
apt 2.6.1 (amd64)
root@hera:/# apt list '?source-package(^mg$)'
Listing... Done
mg/stable 20221112-1 amd64
root@hera:/# apt list ' ?source-package(^mg$)'
Listing... Done
mg/stable 20221112-1 amd64
root@hera:/# apt list ' ?source-package(^mg$) '
Listing... Error!
E: input:22-23: error: Expected end of file
?source-package(^mg$) 
 ^

And again in sid:

bash5$ mmdebstrap sid /dev/null --quiet --customize-hook='chroot $1'
root@hera:/# dpkg-query -W apt
apt 2.7.14
root@hera:/# apt --version
apt 2.7.14 (amd64)
root@hera:/# apt list '?source-package(^mg$)'
Listing... Done
mg/unstable 20230501-1 amd64
root@hera:/# apt list ' ?source-package(^mg$)'
Listing... Done
mg/unstable 20230501-1 amd64
root@hera:/# apt list ' ?source-package(^mg$) '
Listing... Error!
E: input:22-23: error: Expected end of file
?source-package(^mg$) 
 ^

Bug#1063374: RFP: HTMX - high power tools for HTML

[Trent W. Buck]

Hi, attached is my first draft of packaging htmx.
I don't know js packaging at all, so I kinda guessed.


https://github.com/cyberitsolutions/bootstrap2020/tree/twb/debian-12-PrisonPC.packages/node-htmx.org/debian

Known issues:

  * Have to build with DEB_BUILD_OPTIONS=nocheck, because
some test-time dependencies are missing (not in Debian at all)!

  * puts files in /usr/share/nodejs, but
apache2 expects /usr/share/javascript!

  * creates a .min.js for the main file, but
not any of the auxiliary files!
(I think this is an upstream bug?)

  * in the 2.0.0~alpha1 package,
all the auxiliary files are completely missing!

  * Makes a connection to registry.npmjs.org during build.
I don't know why.  The attacker's command was:

perl -MDebian::PkgJs::SimpleAudit -e print advisories(".")

  * The upstream source tarball is 20MB, that seems *way* too big.
(Update: it seems most of this is the embedded copy of https://htmx.org 
website.)

Lintian complains about a bunch of embedded copies, too:

E: node-htmx.org source: source-is-missing 
[test/lib/handlebars-v4.7.6.js]
E: node-htmx.org source: source-is-missing [test/lib/morphdom-umd.js]
E: node-htmx.org source: source-is-missing 
[www/static/node_modules/chai/chai.js]
E: node-htmx.org source: source-is-missing 
[www/static/node_modules/mocha/mocha.js]
E: node-htmx.org source: source-is-missing 
[www/static/node_modules/sinon/pkg/sinon.js]
E: node-htmx.org source: source-is-missing 
[www/static/test/lib/handlebars-v4.7.6.js]
E: node-htmx.org source: source-is-missing 
[www/static/test/lib/morphdom-umd.js]
E: node-htmx.org source: source-is-missing 
[www/themes/htmx-theme/static/js/_hyperscript.js]


On Wed 07 Feb 2024 10:15:32 +0530, Joseph Nuthalapati wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: libjs-htmx
>   Version : 1.9.10
>   Upstream Authors : Big Sky Software
> * URL : https://github.com/bigskysoftware/htmx
> * License : 0BSD
>   Programming Lang: JavaScript
>   Description : A JavaScript library to enhance the features of HTML
> 
> HTML has only two elements that communicate with the server -  and .
> HTMX allows all elements to send AJAX requests to the server. It also allows 
> DOM
> manipulation by replacing HTML elements with the response from the server. 
> This
> can significantly enhance the user experience of traditional multi-page web
> applications.
> .
> htmx allows you to access AJAX, CSS Transitions, WebSockets and Server Sent
> Events directly in HTML, using attributes, so you can build modern user
> interfaces with the simplicity and power of hypertext.
> .
> htmx has no runtime dependencies. It can be used by web applications written 
> in
> any programming language. The license is Zero-Clause BSD.


node-htmx.org_1.9.10-0PrisonPC1.debian.tar.xz
Description: application/xz

Bug#1064259: Remove spurious Depends: bubblewrap (it moved to libgnome-desktop-*)

[Trent W. Buck]

Package: nautilus
Version: 43.2-1
Severity: minor

Right now nautilus has Depends: bubblewrap, but it doesn't actually use 
bubblewrap.


https://salsa.debian.org/search?search=bubblewrap_source=navbar_id=5329_id=2002_code=true_ref=debian%2Flatest

This happened because nautilus used to contain an embedded copy of 
libgnome-desktop.
That was fixed, but the bubblewrap dependency was not removed.


https://salsa.debian.org/gnome-team/nautilus/-/commit/673c81cf9f1d68b71041220e6e44624dee44dbfc
 (libgnome-desktop embedded, bwrap required)

https://salsa.debian.org/gnome-team/nautilus/-/commit/4eb2d8705b7f799a16046b316a16ebde3af8dd0e
 (bwrap dependency documented)

https://salsa.debian.org/gnome-team/nautilus/-/commit/3862cf798039ccf3cb57d39400288314f04db25c
 (libgnome-desktop not embedded anymore, bwrap not directly required)

"libgnome-desktop* Depends: bubblewrap" provide this dependency already where 
it is still needed.


https://salsa.debian.org/search?search=bubblewrap_source=navbar_id=5207_id=2002_code=true_ref=debian%2Flatest


Boring context:
1. Can I use bwrap to harden XFCE's tumbler against the next
   https://security-tracker.debian.org/tracker/CVE-2023-4863 ?
2. Oh, nautilus Depends: bubblewrap directly.
   It's probably something simple (and steal-able!) like
   nautilus.desktop: TryExec=nautilus
   nautilus.desktop: Exec=bwrap ⋯ nautilus
3. Waitaminute, this isn't using bubblewrap *at all*?! >Confused<


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

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 nautilus depends on:
ii  bubblewrap  0.8.0-2
ii  desktop-file-utils  0.26-1
ii  gsettings-desktop-schemas   43.0-1
ii  gvfs1.50.3-1
ii  libadwaita-1-0  1.2.2-1
ii  libc6   2.36-9+deb12u4
ii  libcairo2   1.16.0-7
ii  libcloudproviders0  0.3.1-2
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libgexiv2-2 0.14.0-1+b1
ii  libglib2.0-02.74.6-2
ii  libglib2.0-data 2.74.6-2
ii  libgnome-autoar-0-0 0.4.3-1
ii  libgnome-desktop-4-243.2-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3+deb12u1
ii  libgstreamer1.0-0   1.22.0-2
ii  libgtk-4-1  4.8.3+ds-2+deb12u1
ii  libnautilus-extension4  43.2-1
ii  libpango-1.0-0  1.50.12+ds-1
ii  libportal-gtk4-10.6-4
ii  libportal1  0.6-4
ii  libselinux1 3.4-1+b6
ii  libtracker-sparql-3.0-0 3.4.2-1
ii  nautilus-data   43.2-1
ii  shared-mime-info2.2-1
ii  tracker 3.4.2-1
ii  tracker-extract 3.4.3-1
ii  tracker-miner-fs3.4.3-1

Versions of packages nautilus recommends:
ii  gnome-sushi   43.0-2
ii  gvfs-backends 1.50.3-1
ii  libgdk-pixbuf2.0-bin  2.42.10+dfsg-1+b1
ii  librsvg2-common   2.54.7+dfsg-1~deb12u1

Versions of packages nautilus suggests:
ii  eog 43.2-1
ii  evince [pdf-viewer] 43.1-2+b1
pn  nautilus-extension-brasero  
pn  nautilus-sendto 
ii  totem   43.0-2
ii  vlc [mp3-decoder]   3.0.20-0+deb12u1
ii  xdg-user-dirs   0.18-1
ii  xpdf [pdf-viewer]   3.04+git20220601-1+b2

-- no debconf information

Bug#1063993: Cannot "list set" multiple differently-typed sets in one process

[Trent W. Buck]

Package: nftables
Version: 1.0.6-2+deb12u2
Severity: minor

In production I wanted to list two sets and count how many elements are in each:

$ sudo nft -json 'list set inet my_filter my_IPS_IPv4_blacklist' | jq 
'.nftables[1].set.elem | length'
33

When I tried to list both sets at once (IPv4 & IPv6), nft gave confusing errors.
Below is the smallest test ruleset I found that reproduces the problem.

bash5$ sudo ip netns add delete-me

bash5$ sudo ip netns exec delete-me nft 'flush ruleset; table inet x { set 
xs { type ipv4_addr; }; set ys { type ipv6_addr; }; }'

bash5$ sudo ip netns exec delete-me nft list ruleset
table inet x {
set xs {
type ipv4_addr
}

set ys {
type ipv6_addr
}
}

bash5$ sudo ip netns exec delete-me nft 'list set inet x xs'
table inet x {
set xs {
type ipv4_addr
}
}

bash5$ sudo ip netns exec delete-me nft 'list set inet x ys'
table inet x {
set ys {
type ipv6_addr
}
}

bash5$ sudo ip netns exec delete-me nft 'list set inet x xs; list set inet 
x xs'
table inet x {
set xs {
type ipv4_addr
}
}
table inet x {
set xs {
type ipv4_addr
}
}

bash5$ sudo ip netns exec delete-me nft 'list set inet x ys; list set inet 
x ys'
table inet x {
set ys {
type ipv6_addr
}
}
table inet x {
set ys {
type ipv6_addr
}
}

bash5$ sudo ip netns exec delete-me nft 'list set inet x xs; list set inet 
x ys'
Error: No such file or directory; did you mean set ‘ys’ in table inet ‘x’?
list set inet x xs; list set inet x ys
^^

bash5$ sudo ip netns exec delete-me nft 'list set inet x ys; list set inet 
x xs'
Error: No such file or directory; did you mean set ‘xs’ in table inet ‘x’?
list set inet x ys; list set inet x xs
^^

bash5$ /sbin/nft --version
nftables v1.0.6 (Lester Gooch #5)

bash5$ uname -a
Linux hera 6.5.0-0.deb12.4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.5.10-1~bpo12+1 (2023-11-23) x86_64 GNU/Linux

bash5$ dpkg-query -W linux-image-amd64 nftables
linux-image-amd64   6.5.10-1~bpo12+1
nftables1.0.6-2+deb12u2


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

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 nftables depends on:
ii  libc6 2.36-9+deb12u4
ii  libedit2  3.1-20221030-2
ii  libnftables1  1.0.6-2+deb12u2

Versions of packages nftables recommends:
ii  netbase  6.4

Versions of packages nftables suggests:
pn  firewalld  

-- Configuration Files:
/etc/nftables.conf changed [not included]

-- no debconf information

Bug#1063764: Please protect exim4/postfix/dovecot/ by default again

[Trent W. Buck]

Package: sshguard
Version: 2.4.2-1+b2
Severity: normal

Consider this change to prevent sshguard triggering itself 
(https://bugs.debian.org/928525):


https://salsa.debian.org/debian/sshguard/-/commit/3563a43968bf1e143f2a1b20d06a95c48a95570b

- LOGREADER="LANG=C /bin/journalctl -afb -p info -n1 -o cat 
SYSLOG_FACILITY=4 SYSLOG_FACILITY=10"
+ LOGREADER="LANG=C journalctl -afb -p info -n1 -t sshd -o cat"

In 2019, "apt install sshguard" was sufficient to protect postfix and dovecot.
In 2023, "apt install sshguard" only protects openssh-server.

It's not hard to fix this on each host if you're experienced, but
I really liked being able to tell newbies:

Just "apt install sshguard".
Unlike fail2ban, it protects everything by default (except for 
apache2/nginx).
It doesn't require any opt-in configuration (except for apache2/nginx).
It defaults to modern nft sets, not the MUCH slower raw xtables rules (not 
even ipset!).
It uses a C parser instead of Python regexps, so it has lower overheads.

Attached is the sshguard.conf I've been running in production, as a reference.
(It's probably not suitable for upstreaming into Debian as-is, though.)

The important things are:

  0. Watch for events from more than just openssh-server.

 Unfortunately journalctl does'nt provide an easy way to say
 "all events EXCEPT the ones from sshguard@localhost", so
 I simply listed every daemon in Debian whose logs sshguard understands.

 I haven't tried to solve "ingest sshguard events from OTHER hosts", which
 is why sshguard reacts to its own logs at all.

  1. Use --unit= instead of --identifier=.

 I did this because e.g. postfix uses many different identifiers, and
 because when just reading the source,
 you can work out the unit(s) easier than the identifier(s).

 You could continue using -t, but you can't use a *mix* of -t and -u,
 because -tX -tY -tZ -uA -uB -uC means (X ∨ Y ∨ Z) ∧ (A ∨ B ∨ C).

 Also --unit= is harder to spoof, which may be a good thing or a bad thing.
 I don't know what the implications are for systemd-journal-remote and 
systemd-container.

  2. Watch for CLF logs (sshguard won't break if they're missing)

 If they aren't used, the only impact is 1 warning when sshguard starts.
 I added the nginx and apache2 default paths, but
 there are probably others I haven't considered.

Please consider making Debian's sshguard default to protecting
postfix/dovecot (as it used to) and maybe also nginx/apache2 (new).
# Written for sshguard 2.4.2.
#
# The way sshguard is laid out internally is confusing.
#
#  • sshguard is a shell script that creates a pipeline like this:
#
#  ( $LOGREADER & tail -Fn0 $FILES ) | sshg-parser | sshg-blocker | $BACKEND
#
#BACKEND *must* be set.
#Choices are https://bitbucket.org/sshguard/sshguard/src/master/src/fw/
#
#At least one of LOGREADER and FILES *must* be set.
#Both are used if both are set.
#
#This file is parsed by sshguard, which is a shell script.
#So you could do things like
#
#   for i in /etc/sshguard/sshguard.conf.d/*.conf; do [ -e "$i" ] && . 
"$i"; done
#
#  • The following variables are used by sshg-blocker, but NOT understood by it!
#sshguard reads them in and converts them to -x Y single-letter getopts CLI 
args.
#The defaults are set here:
#
#
https://bitbucket.org/sshguard/sshguard/src/a5ea6ffac184b6cec4f59f576b941247cb7d0c8f/src/blocker/sshguard_options.c#lines-41:52
#
#==    ==  ===
#sshguard.conf   sshg-blocker  sshguard_options.c  default
#==    ==  ===
#THRESHOLD   -aabuse_threshold 30
#BLACKLIST_FILE  -bblacklist_filename  n/a
#BLOCK_TIME  -ppardon_threshold120
#DETECTION_TIME  -sstale_threshold 1800
#IPv6_SUBNET -Nsubnet_ipv6 128  (i.e. single 
host)
#IPV4_SUBNET -nsubnet_ipv4 32   (i.e. single 
host)
#WHITELIST_FILE  -wn/a n/a  (but Debian 
sets /etc/sshguard/whitelist)
#==    ==  ===
#
#  • In sshguard.conf, WHITELIST_FILE and BLACKLIST_FILE may be 
whitespace-separate lists of files.
#Each file MUST begin with "/" or ".", or sshg-blocker will treat it as a 
value (not a file containing values).
#
#  • AFAICT there is no reason LOGREAD could not simply be "journalctl -f", 
i.e. reading EVERY log event.
#The only reasons to narrow this down are:
#
#  • To reduce CPU load (sshg-parser does less work)
#  • To avoid sshguard treating its own log events as evidence-of-attack 
logs.
#
#Debian default is
#
#LANG=C journalctl -afb -p info -n1 -t sshd -o cat
#
#This is very silly because "-t sshd" will prevent any log events except 
openssh-server being handled!
#I 

Bug#1061094: mmdebstrap vs. apt -o DPkg::Inhibit-Shutdown

[Trent W. Buck]

Package: apt
Version: 2.6.1
Severity: wishlist

I'm creating this bug so there's a bug number I can link to.
We discussed it on #debian-apt around 2024-01-16 08:54:47+00:00.

I noticed that since 2023-10-10, mmdebstrap triggers these errors:

2023-10-10T15:53:32+1100 hera polkitd[2696604]:
Error evaluating admin rules:
Error: Helper exited with non-zero exit status 1,
   stdout=`',
   stderr=`pkla-check-authorization: Invalid user `10': No UNIX 
user with name 10: Success
  (pkla-check-authorization:3461602): GLib-GObject-CRITICAL 
**: 15:53:32.183: g_object_unref: assertion 'G_IS_OBJECT (object)' failed'

I initially thought it was a faulty postinst, but
after several hours of digging, I managed to narrow it down:

bash5$ journalctl -o short-iso -u polkit --grep='Error evaluating admin 
rules' -fn0 &
bash5$ sudo dbus-monitor --system --pcap | tshark -r- -Y 'dbus.interface == 
"org.freedesktop.login1.Manager"' &

bash5$ mmdebstrap bookworm /dev/null --quiet
   11  24.706215  :1.1955 → org.freedesktop.login1 D-Bus 246 Inhibit() 
@ /org/freedesktop/login1
2024-01-18T10:36:10+1100 hera polkitd[1035]: Error evaluating admin rules: 
Error: Helper exited with non-zero exit status 1, stdout=`', 
stderr=`pkla-check-authorization: Invalid user `10': No UNIX user with name 
10: Success

 
(pkla-check-authorization:874223): GLib-GObject-CRITICAL **: 10:36:10.673: 
g_object_unref: assertion 'G_IS_OBJECT (object)' failed
 '
   50  37.507789  :1.1956 → org.freedesktop.login1 D-Bus 246 Inhibit() 
@ /org/freedesktop/login1
2024-01-18T10:36:23+1100 hera polkitd[1035]: Error evaluating admin rules: 
Error: Helper exited with non-zero exit status 1, stdout=`', 
stderr=`pkla-check-authorization: Invalid user `10': No UNIX user with name 
10: Success

 
(pkla-check-authorization:875795): GLib-GObject-CRITICAL **: 10:36:23.475: 
g_object_unref: assertion 'G_IS_OBJECT (object)' failed
 '

bash5$ mmdebstrap bookworm /dev/null --quiet 
'--aptopt=DPKG::Inhibit-Shutdown 0;'

The relevant code is here:


https://salsa.debian.org/apt-team/apt/-/blob/2.6.1/apt-pkg/deb/dpkgpm.cc?ref_type=tags#L1508-1509

What is happening is this:

* "apt install foo" starts
* apt/dpkg --dbus--> systemd, "please inhibit (refuse to) shutdown/reboot 
during installs"
* systemd --dbus--> polkit, "user 1234 asked to inhibit shutdowns, is that 
allowed?"
* polkit --dbus--> systemd, "user 1234 doesn't exist, therefore no"
* systemd ignores the request (maybe signalling an error?)
* apt/dpkg continues on without any real issue

This issue DOES NOT affect normal host usage of apt, because
"sudo apt install x" runs the host's apt, with a normal host-wide user that 
polkit can see.
The inhibit works there (assuming pid1 is systemd, I guess).

This issue DOES NOT affect normal chroots, because
"sudo chroot /target apt install x" cannot "see" the un-chrooted dbus, so
the inhibit attempt fails before reaching systemd/polkit.

This issue affects mmdebstrap, because mmdebstrap run's the host's apt,
with an unshare'd userns such that apt thinks the user is root, and
systemd/polkit thinks it's a transient UID with no record in nss passwd table.

(systemd DynamicUser= units and systemd-nspawn containers have similar 
transient UIDs, and
in those cases "apt install libnss-systemd libnss-machines" provides nss passwd 
entries.)



Julian suggested this change:

-if (_config->FindB("DPkg::Inhibit-Shutdown", true))
+if (_config->FindB("DPkg::Inhibit-Shutdown", _config->FindDir("Dir", 
"/") == "/"))

I like this plan.

This will fix the mmdebstrap case, because mmdebstrap runs something like 
"unshare ⋯ apt -o Dir=/tmp/mmdebstrap.XX".
(No one cares if an mmdebstrap image build is "corrupted" by a halt/reboot - 
you just rerun mmdebstrap and make a fresh one.)

This should NOT affect "sudo apt install x" or "sudo chroot /target apt install 
x", because
in both cases apt is operating on / (either the host's /, or the chroot's /).

This should NOT affect debootstrap because it only runs dpkg, not apt (I think).

This MIGHT affect someone else doing "apt -o Dir=⋯" to do custom installs, but
everything I can think of offhand is a wrapper around debootstrap, except for
https://github.com/openSUSE/obs-build/blob/master/obs-docker-support#L118

Everything I can find seems to set e.g. Dir::Etc rather than Dir itself.

https://codesearch.debian.net/search?q=apt.*-o.*Dir%5B%5E%3A%5D
https://github.com/search?q=%2Fapt.*-o.*Dir%2F=code  (requires 
Microsoft account, requires javascript)

PS: general details about the "inihibit" functionality are here:

  

Bug#1060889: clamav cannot be cross-arch installed?

[Trent W. Buck]

Package: clamav-base
Version: 1.0.3+dfsg-1~deb12u1
Severity: minor

When trying to install clamav for non-default architecture,
I get this error from apt:

The following packages have unmet dependencies:
 clamav-daemon:i386 : Depends: clamav-base:i386 (= 1.0.3+dfsg-1~deb12u1) 
but it is not installable
 clamav-freshclam:i386 : Depends: clamav-base:i386 (>= 
1.0.3+dfsg-1~deb12u1) but it is not installable

This is really weird and confusing, because clamav-base is
an Architecture: all package, not
an Architecture: any package.

I speculate that either:

1. apt has a bug that clamav happens to trigger; or
2. clamav's Depends/Conflicts/Replaces are subtly bugged, and should be 
"fixed"; or
3. I've misunderstood something fundamental about how to use multiple 
architectures in apt.

Here are the full commands I ran.


These all complete without error:

bash5$ mmdebstrap bookworm /dev/null --quiet --architecture=amd64 
--include=clamav,clamav-daemon

bash5$ mmdebstrap bookworm /dev/null --quiet --architecture=i386 
--include=clamav:i386,clamav-daemon:i386

bash5$ mmdebstrap bookworm /dev/null --quiet --architecture=i386,amd64 
--include=clamav:i386,clamav-daemon:i386

bash5$ mmdebstrap bookworm /dev/null --quiet --architecture=amd64,i386 
--include=curl:i386   # some non-clamav cross-arch install


These fail with the weird bug:

bash5$ mmdebstrap bookworm /dev/null --architecture=amd64,i386 
--include=clamav:i386,clamav-daemon:i386
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: finding correct signed-by value...
done
I: automatically chosen format: null
I: using /tmp/mmdebstrap.W2DIp_TEfi as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: installing remaining packages inside the chroot...
done
Reading package lists...
Building dependency tree...
debconf is already the newest version (1.5.82).
libpam-runtime is already the newest version (1.5.2-6+deb12u1).
mawk is already the newest version (1.3.4.20200120-3.1).
libpam-modules is already the newest version (1.5.2-6+deb12u1).
libpam-modules-bin is already the newest version (1.5.2-6+deb12u1).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 clamav-daemon:i386 : Depends: clamav-base:i386 (= 1.0.3+dfsg-1~deb12u1) 
but it is not installable
 clamav-freshclam:i386 : Depends: clamav-base:i386 (>= 
1.0.3+dfsg-1~deb12u1) but it is not installable
E: Unable to correct problems, you have held broken packages.
E: setup failed: E: apt-get -o Dir::Bin::dpkg=env -o 
DPkg::Options::=--unset=TMPDIR -o DPkg::Options::=dpkg -o 
DPkg::Chroot-Directory=/tmp/mmdebstrap.W2DIp_TEfi --yes install 
-oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false clamav:i386 clamav-daemon:i386 
?narrow(?or(?archive(^bookworm$),?codename(^bookworm$)),?architecture(amd64),?and(?or(?priority(required),?priority(important)),?not(?essential)))
 failed
I: main() received signal PIPE: waiting for setup...
I: removing tempdir /tmp/mmdebstrap.W2DIp_TEfi...
E: mmdebstrap failed to run

bash5$ mmdebstrap bookworm /dev/null --architecture=i386,amd64 
--include=clamav:amd64,clamav-daemon:amd64
I: automatically chosen mode: unshare
I: i386 is different from amd64 but can be executed natively
I: finding correct signed-by value...
done
I: automatically chosen format: null
I: using /tmp/mmdebstrap.oM_yCF_dpY as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: installing remaining packages inside the chroot...
done
Reading package lists...
Building dependency tree...
debconf is already the newest version (1.5.82).
libpam-runtime is already the newest version (1.5.2-6+deb12u1).
mawk is already the newest version (1.3.4.20200120-3.1).
libpam-modules is already the newest version (1.5.2-6+deb12u1).
libpam-modules-bin is already the newest version (1.5.2-6+deb12u1).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 clamav-daemon:amd64 : Depends: clamav-base:amd64 (= 

Bug#1054559: numfmt: --to lakh ?

[Trent W. Buck]

Package: coreutils
Version: 9.1-1
Severity: wishlist
File: /usr/bin/numfmt
Tags: upstream

In India it is common to write large numbers using combinations of
"lakh" / "L" (10⁷) and "crore" / "cr" (10⁵).

https://en.wikipedia.org/wiki/Lakh
https://en.wikipedia.org/wiki/Crore

For example,

According to […] ₹15.3 lakh crore of the ₹15.41 lakh crore in demonetised 
bank notes, […]

— https://en.wikipedia.org/wiki/2016_Indian_banknote_demonetisation

When I try to convert these to SI units in my head, I always mess up.

Could numfmt handle this for me?
Something like this (my maths might be wrong!):

$ numfmt --from=auto --to=लाख 15.3T
15.3 lakh crore

$ numfmt --from=auto --to=लाख 1.2G
120 crore

$ numfmt --from=auto --to=लाख 1.2M
12 lakh

$ numfmt --from=लाख --to=si 12 lakh
1.2M

$ numfmt --from=लाख --to=si 15.3 lakh crore
15.3T




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

Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9+deb12u3
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b6

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1041731: Hyphens in man pages

[Trent W. Buck]

On Sun 15 Oct 2023 17:33:07 +0200, Iustin Pop wrote:
> At least you're not lazy. I am, so what I did many times is add a
> build-depends on pandoc, and write the man page in rst or md. I think
> that's a worse solution (pandoc is really heavy), but at least, I don't
> have to go back to *roff.

FWIW, there are lighter alternatives than pandoc:

pandoc:After this operation, 174 MB of 
additional disk space will be used.
sphinx-doc (sphinx-build -b man):  After this operation, 140 MB of 
additional disk space will be used.
rst2man (python3-docutils):After this operation, 37.6 MB of 
additional disk space will be used.
pod2man (perl):perl is already the newest version 
(5.36.0-9).

I'm not going to bother measuring docbook ;-)

If you are writing manpages by hand, this is an excellent overview:

https://manpages.debian.org/bookworm/manpages/man.7.en.html

See also:

https://www.oreilly.com/library/view/mastering-perl/9780596527242/ch15.html 
(POD)
https://www.docutils.org/docs/user/manpage.html#todo-open-issues


signature.asc
Description: PGP signature

Bug#1052302: Missing Depends/Recommends: bsdextrautils (hexdump)

[Trent W. Buck]

Package: translate-shell
Version: 0.9.7.1-1
Severity: minor

With default settings, trans(1) appears to assume hexdump is installed.
Please add a Recommends or Depends (whichever is appropriate).

(Also, it should probably treat this as an error, and exit non-zero.)

Minimal failing recipe:

bash5$ mmdebstrap bookworm /dev/null --components=main,contrib 
--include=translate-shell --customize-hook='chroot $1 trans la:zh "HOMO HOMINI 
LUPUS EST"'
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: finding correct signed-by value...
done
I: automatically chosen format: null
I: using /tmp/mmdebstrap.fG_WK1dcFL as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: installing remaining packages inside the chroot...
done
done
I: running --customize-hook in shell: sh -c 'chroot $1 trans la:zh "HOMO 
HOMINI LUPUS EST"' exec /tmp/mmdebstrap.fG_WK1dcFL
sh: 1: hexdump: not found

I: cleaning package lists and apt cache...
done
done
I: removing tempdir /tmp/mmdebstrap.fG_WK1dcFL...
I: success in 32.6198 seconds

Minimal working recipe:

bash5$ mmdebstrap bookworm /dev/null --components=main,contrib 
--include=translate-shell --customize-hook='chroot $1 trans la:zh "HOMO HOMINI 
LUPUS EST"' --include=bsdextrautils
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: finding correct signed-by value...
done
I: automatically chosen format: null
I: using /tmp/mmdebstrap.xj6706N7Sk as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: installing remaining packages inside the chroot...
done
done
I: running --customize-hook in shell: sh -c 'chroot $1 trans la:zh "HOMO 
HOMINI LUPUS EST"' exec /tmp/mmdebstrap.xj6706N7Sk
HOMO HOMINI LUPUS EST

男人对于男人来说就是狼
(Nánrén duìyú nánrén lái shuō jiùshì láng)

Translations of HOMO HOMINI LUPUS EST
[ Latina -> 简体中文 ]

HOMO HOMINI LUPUS EST
男人对于男人来说就是狼, 一个人对于一个人来说就是一头狼
I: cleaning package lists and apt cache...
done
done
I: removing tempdir /tmp/mmdebstrap.xj6706N7Sk...
I: success in 36.0941 seconds

Also affects sid:

bash5$ mmdebstrap sid /dev/null --components=main,contrib 
--include=translate-shell --customize-hook='chroot $1 trans la:zh "HOMO HOMINI 
LUPUS EST"'
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: finding correct signed-by value...
done
I: automatically chosen format: null
I: using /tmp/mmdebstrap.RDVdCh5fad as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: installing remaining packages inside the chroot...
done
done
I: running --customize-hook in shell: sh -c 'chroot $1 trans la:zh "HOMO 
HOMINI LUPUS EST"' exec /tmp/mmdebstrap.RDVdCh5fad
sh: 1: hexdump: not found

I: cleaning package lists and apt cache...
done
done
I: removing tempdir /tmp/mmdebstrap.RDVdCh5fad...
I: success in 29.9009 seconds




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

Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 translate-shell depends on:
ii  gawk1:5.2.1-2
ii  libfribidi-bin  1.0.8-2.1

Versions of packages translate-shell recommends:
ii  aspell0.60.8-4+b1
ii  curl  7.88.1-10+deb12u2
ii  hunspell  1.7.1-1
ii  less  590-2
ii  rlwrap0.46.1-1

Versions of packages translate-shell suggests:
ii  mpg123  1.31.2-1
ii  mpv 0.35.1-4

-- no debconf information

Bug#778849: Support restoring initrd on shutdown and pivoting into it

[Trent W. Buck]

On Wed 11 Jan 2023 00:17:44 +, Gervase wrote:
> On Sat, 2022-12-24 at 14:16 +, Gervase wrote:
> > Awhile back, I did have a look around the fix.  From what I
> > remembered,
> > intrigeri's solution used a systemd shutdown 'script' to check for
> > devmaps or whatever of LVMs, ZFS partitions, etc... and runs specific
> > commands to umount the partitions.
> 
> Apparently, I got confused.  What I saw is the script called 'shutdown'
> from the mkinitcpio package used in Arch Linux (see 
> https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/blob/master/shutdown
> ).
> 
> What it does is (1) recursively umount the devices, (2) detaches loop
> back devices and then (3) disassembles stacked devices (i.e. encrypted
> devices, lvm and raid).
> 
> In contrast, what intrigeri's solution SEEMS to do (I haven't done any
> experimentation using the solution) is provide a way for Debian's initrd
> process to "pivot" back to a systemd shutdown procedure within an
> initramfs environment, as opposed to running the Arch Linux shutdown
> script.  This shutdown procedure differs from Arch Linux's because its
> initramfs infrastructure differs from Debian's, I assume?

It does final umount/swapoff :

https://github.com/systemd/systemd/blob/v252/src/shutdown/shutdown.c#L422

i.e. it's similar to arch's script, except it's 1) C code; 2) distro-agnostic; 
and 3) a bit feature-limited.

I think if you want it to run arbitrary other commands (e.g. "zpool export 
-a"), you would need more code.

I think for that you'd want systemdize /run/initramfs/shutdown
(i.e. be a copy of systemd's /bin/init), and then run some subset of
https://github.com/systemd/systemd/blob/v252/man/bootup.xml#L291-L330

Note that systemd can "be" the boot initrd, too, which is the previous flow 
chart:
https://github.com/systemd/systemd/blob/v252/man/bootup.xml#L236-L288

AFAIK Debian initramfs-tools doesn't support this at all.
AFAIK ArchLinux supports this, but it is opt in (off by default).

Last time I looked (around Debian 10),
Debian dracut theoretically supported putting systemd in charge of boot initrd 
(and shutdown initrd?), BUT
it also installed a zillion bits of coreutils that systemd itself doesn't use.
Since my goal was to REDUCE the attack surface of the boot initrd, I gave up on 
dracut at the time.

> As intrigeri wrote in his instructions, the relevant scripts would need
> to be written for dismantling devices ('virtual' or physical) and placed
> in /usr/share/initramfs-tools/hooks/* (if I understood things
> correctly).  So, if ZFS was installed as root, there would need to be a
> script for that and/or if LUKS was installed as root, there would need
> to be a script for that, etc...

I think it'd be better if /run/initramfs/shutdown used existing code -- either
/lib/systemd/systemd-shutdown/*.shutdown, or
maybe .service units, if that's appropriate.

But I confess I still do not understand how a "pure systemd" boot initrd + 
shutdown initrd would actually look.

Bug#778849: Support restoring initrd on shutdown and pivoting into it

[Trent W. Buck]

On Fri 07 Apr 2017 12:02:46 +0200, intrigeri wrote:
> /lib/systemd/system/initramfs-shutdown.service:
> ⋯
> /usr/share/initramfs-tools/initramfs-restore:
> ⋯
> /usr/bin/unmkinitramfs /initrd.img "$WORKDIR"
> ⋯
> /lib/systemd/system-shutdown/initramfs-tools:
> ⋯
> /usr/share/initramfs-tools/hooks/shutdown:
> ⋯
> copy_exec /lib/systemd/systemd-shutdown /shutdown
> touch $DESTDIR/etc/initrd-release

I am interested in this ticket for two use cases:

a. netbooting Debian Live on diskless hosts.
b. "zpool export -a" on servers.

I am only considering case (a), below.

I tried intrigeri's approach for Debian Live but I ran into a couple of 
problems:

1. it assumes /initrd.img inside the rootfs exists and
   is consistent with the already-running system.
   This is not the case for me (I remove it to save space), and
   also not necessarily the case during upgrades.

2. it tries to unpack /initrd.img after systemd-networkd stops.
   Without KeepConfiguration= (which is a pain to guarantee),
   that means no network access, which means no access to remote rootfs.

I instead tried just keeping the boot initrd around.
Using a simple bind-mount didn't work (I don't understand why) – SOME files are 
missing after switch_root.
Doing a full cp -a did work, though.

This method seems to work for my very simple test case of 
failed-to-unmount-rootfs error going away.
I'm really not happy with it overall, though.
I've run out of "time budget" to work on this in the short term.


https://github.com/cyberitsolutions/bootstrap2020/tree/twb/doc/workaround-778849

PS: I looked at dracut, but it's simply unsupported for live-boot (Debian Live 
/ Tails), and
for servers, I found it unreliable (much worse than initramfs-tools).
(e.g. if bash has a security update, dracut doesn't trigger and the 
embedded copy of bash in the initrd remains vulnerable.)
(e.g. telling dracut to use only busybox/klibc and not bash breaks, because 
lots of dracut components need bash but don't declare a dependency on it.)
(e.g. dracut is written in bash and regularly has errors but doesn't exit 
non-zero, so you do not notice until the server doesn't actually boot anymore.)


usr_share_initramfs-tools_hooks_PrisonPC-install-systemd-shutdown
Description: Bourne shell script


shs11IyvBEnz.sh
Description: Bourne shell script

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Trent W. Buck]

On Tue 13 Dec 2022 22:04:40 +0200, Damyan Ivanov wrote:
> The package is more or less ready at
>  (-high-dpi at
> , probably
> needs a bit more work).

FYI I had a go this morning and got a "clean room" version working with 
cmake+ninja, ignoring scons.
This seems to be consistent with what upstream docs currently recommend.

https://github.com/cyberitsolutions/bootstrap2020/tree/twb/debian-12-PrisonPC.packages/endless-sky/debian

I only got it working enough for me, so e.g. debian/copyright isn't set up 
properly.
It builds and installs and runs, though - I did the tutorial mission string as 
a test.

I did not get the tests working, because I think cmake+make was
starting $(nproc) separate instances of the game at once to do tests,
and my laptop kept OOMing.  I didn't go back after I switchde to cmake+ninja.

Looking at Damyan's version from last year,
I think the only novel/interesting thing in mine is the rules file.
The rest is pretty boring.
I also used upstream's current README text for Description, instead
of Michael's original description from 5+ years ago.


endless-sky_0.10.2-1~PrisonPC1.debian.tar.xz
Description: application/xz


endless-sky_0.10.2-1~PrisonPC1_amd64.build.xz
Description: application/xz
Format: 1.0
Source: endless-sky
Binary: endless-sky endless-sky-data
Architecture: all amd64 source
Version: 0.10.2-1~PrisonPC1
Checksums-Md5:
 0c4c33d4e5f6a34cf75eca6ce29ae4e5 1097 endless-sky_0.10.2-1~PrisonPC1.dsc
 6d563dcdb4cb3f37042844e1361925c0 241438272 
endless-sky-data_0.10.2-1~PrisonPC1_all.deb
 b25a4ee7116bfcf2f47a004fea2dfcd8 1556788 
endless-sky_0.10.2-1~PrisonPC1_amd64.deb
Checksums-Sha1:
 af3ac77f2ba6e593e7ae6c31a59dee26f63e7cd1 1097 
endless-sky_0.10.2-1~PrisonPC1.dsc
 dfd0bb8cd6fd0ad1387f5bccc820cdd8e8d05aa1 241438272 
endless-sky-data_0.10.2-1~PrisonPC1_all.deb
 25e3059720203be0bd8ba48278f4540ef801bb9d 1556788 
endless-sky_0.10.2-1~PrisonPC1_amd64.deb
Checksums-Sha256:
 d55f14608580506c69cb1f2601692ec7919192b36061b178c0633381ff9a6433 1097 
endless-sky_0.10.2-1~PrisonPC1.dsc
 56e50c354b18747a4cf5bd9d074b3402eabb836497bb831139ad55acb15efe9b 241438272 
endless-sky-data_0.10.2-1~PrisonPC1_all.deb
 d8acf681f605bb7a19f1071b24924327c332708e5131c22997b1b22b3b415931 1556788 
endless-sky_0.10.2-1~PrisonPC1_amd64.deb
Build-Origin: Debian
Build-Architecture: amd64
Build-Date: Mon, 07 Aug 2023 21:17:25 +
Build-Tainted-By:
 merged-usr-via-aliased-dirs
Installed-Build-Depends:
 autoconf (= 2.71-3),
 automake (= 1:1.16.5-1.3),
 autopoint (= 0.21-12),
 autotools-dev (= 20220109.1),
 base-files (= 12.4+deb12u1),
 base-passwd (= 3.6.1),
 bash (= 5.2.15-2+b2),
 binutils (= 2.40-2),
 binutils-common (= 2.40-2),
 binutils-x86-64-linux-gnu (= 2.40-2),
 bsdextrautils (= 2.38.1-5+b1),
 bsdutils (= 1:2.38.1-5+b1),
 build-essential (= 12.9),
 bzip2 (= 1.0.8-5+b1),
 cmake (= 3.25.1-1),
 cmake-data (= 3.25.1-1),
 coreutils (= 9.1-1),
 cpp (= 4:12.2.0-3),
 cpp-12 (= 12.2.0-14),
 dash (= 0.5.12-2),
 debconf (= 1.5.82),
 debhelper (= 13.11.4),
 debianutils (= 5.7-0.4),
 dh-autoreconf (= 20),
 dh-strip-nondeterminism (= 1.13.1-1),
 diffutils (= 1:3.8-4),
 dpkg (= 1.21.22),
 dpkg-dev (= 1.21.22),
 dwz (= 0.15-1),
 file (= 1:5.44-3),
 findutils (= 4.9.0-4),
 g++ (= 4:12.2.0-3),
 g++-12 (= 12.2.0-14),
 gcc (= 4:12.2.0-3),
 gcc-12 (= 12.2.0-14),
 gcc-12-base (= 12.2.0-14),
 gettext (= 0.21-12),
 gettext-base (= 0.21-12),
 gir1.2-glib-2.0 (= 1.74.0-3),
 gir1.2-ibus-1.0 (= 1.5.27-5),
 grep (= 3.8-5),
 groff-base (= 1.22.4-10),
 gzip (= 1.12-1),
 hostname (= 3.23+nmu1),
 init-system-helpers (= 1.65.2),
 intltool-debian (= 0.35.0+20060710.6),
 libacl1 (= 2.3.1-3),
 libarchive-zip-perl (= 1.68-1),
 libarchive13 (= 3.6.2-1),
 libasan8 (= 12.2.0-14),
 libasound2 (= 1.2.8-1+b1),
 libasound2-data (= 1.2.8-1),
 libasound2-dev (= 1.2.8-1+b1),
 libasyncns0 (= 0.8-6+b3),
 libatomic1 (= 12.2.0-14),
 libattr1 (= 1:2.5.1-4),
 libaudit-common (= 1:3.0.9-1),
 libaudit1 (= 1:3.0.9-1),
 libbinutils (= 2.40-2),
 libblkid-dev (= 2.38.1-5+b1),
 libblkid1 (= 2.38.1-5+b1),
 libbrotli1 (= 1.0.9-2+b6),
 libbsd0 (= 0.11.7-2),
 libbz2-1.0 (= 1.0.8-5+b1),
 libc-bin (= 2.36-9+deb12u1),
 libc-dev-bin (= 2.36-9+deb12u1),
 libc6 (= 2.36-9+deb12u1),
 libc6-dev (= 2.36-9+deb12u1),
 libcap-ng0 (= 0.8.3-1+b3),
 libcap2 (= 1:2.66-4),
 libcc1-0 (= 12.2.0-14),
 libcom-err2 (= 1.47.0-2),
 libcrypt-dev (= 1:4.4.33-2),
 libcrypt1 (= 1:4.4.33-2),
 libctf-nobfd0 (= 2.40-2),
 libctf0 (= 2.40-2),
 libcurl4 (= 7.88.1-10+deb12u1),
 libdb5.3 (= 5.3.28+dfsg2-1),
 libdbus-1-3 (= 1.14.8-2~deb12u1),
 libdbus-1-dev (= 1.14.8-2~deb12u1),
 libdebconfclient0 (= 0.270),
 libdebhelper-perl (= 13.11.4),
 libdecor-0-0 (= 0.1.1-2),
 libdecor-0-dev (= 0.1.1-2),
 libdpkg-perl (= 1.21.22),
 libdrm-amdgpu1 (= 2.4.114-1+b1),
 libdrm-common (= 2.4.114-1),
 libdrm-dev (= 2.4.114-1+b1),
 libdrm-intel1 (= 2.4.114-1+b1),
 libdrm-nouveau2 (= 2.4.114-1+b1),
 libdrm-radeon1 (= 

Bug#1041470: Acknowledgement (RFP: gnome-crosswords -- crossword player and editor)

[Trent W. Buck]

I have a bare-minimum packaging working (below).
The libipuz stuff is a total mess, but enough to at least run the app.
If I do any more work on it (unlikely) it'll end up at
https://github.com/cyberitsolutions/bootstrap2020/tree/twb/debian-12-PrisonPC.packages


bash5$ grep -rnH ^ libipuz crosswords
libipuz/debian/source/format:1:3.0 (quilt)
libipuz/debian/rules:1:#!/usr/bin/make -f
libipuz/debian/rules:2:export DEB_BUILD_MAINT_OPTIONS = hardening=+all
libipuz/debian/rules:3:%:
libipuz/debian/rules:4: dh $@
libipuz/debian/control:1:Source: libipuz
libipuz/debian/control:2:Section: games
libipuz/debian/control:3:Priority: optional
libipuz/debian/control:4:Homepage: https://gitlab.gnome.org/jrb/libipuz/
libipuz/debian/control:5:Standards-Version: 4.5.1
libipuz/debian/control:6:Maintainer: Trent W. Buck 
libipuz/debian/control:7:Rules-Requires-Root: no
libipuz/debian/control:8:Build-Depends: debhelper-compat (= 13),
libipuz/debian/control:9: meson (>= 0.59.0),
libipuz/debian/control:10: pkg-config,
libipuz/debian/control:11: python3,
libipuz/debian/control:12: libglib2.0-dev,
libipuz/debian/control:13: libjson-glib-dev,
libipuz/debian/control:14: cmake,
libipuz/debian/control:15:
libipuz/debian/control:16:Package: libipuz-1
libipuz/debian/control:17:Depends:
libipuz/debian/control:18: ${misc:Depends},
libipuz/debian/control:19: ${shlibs:Depends},
libipuz/debian/control:20:Architecture: any
libipuz/debian/control:21:Description: FIXME
libipuz/debian/control:22: FIXME
libipuz/debian/changelog:1:libipuz (0.4.2-1) bookworm; urgency=medium
libipuz/debian/changelog:2:
libipuz/debian/changelog:3:  * Initial Debianization.
libipuz/debian/changelog:4:
libipuz/debian/changelog:5: -- Trent W. Buck   Thu, 25 
Aug 2022 20:19:14 +1000
libipuz/debian/watch:1:# Stolen from 
https://sources.debian.org/src/gucharmap/1:14.0.3-1/debian/watch/
libipuz/debian/watch:2:version=4
libipuz/debian/watch:3:https://gitlab.gnome.org/jrb/@PACKAGE@/tags \
libipuz/debian/watch:4:  .*/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
libipuz/debian/copyright:1:Files: *
libipuz/debian/copyright:2:Copyright: 2021 Trent W. Buck
libipuz/debian/copyright:3:License: expat
libipuz/debian/copyright:4:
libipuz/debian/copyright:5:License: expat
libipuz/debian/copyright:6: Permission is hereby granted, free of charge, 
to any person obtaining
libipuz/debian/copyright:7: a copy of this software and associated 
documentation files (the
libipuz/debian/copyright:8: "Software"), to deal in the Software without 
restriction, including
libipuz/debian/copyright:9: without limitation the rights to use, copy, 
modify, merge, publish,
libipuz/debian/copyright:10: distribute, sublicense, and/or sell copies of 
the Software, and to
libipuz/debian/copyright:11: permit persons to whom the Software is 
furnished to do so, subject to
libipuz/debian/copyright:12: the following conditions:
libipuz/debian/copyright:13: .
libipuz/debian/copyright:14: The above copyright notice and this permission 
notice shall be included
libipuz/debian/copyright:15: in all copies or substantial portions of the 
Software.
libipuz/debian/copyright:16: .
libipuz/debian/copyright:17: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT 
WARRANTY OF ANY KIND,
libipuz/debian/copyright:18: EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 
TO THE WARRANTIES OF
libipuz/debian/copyright:19: MERCHANTABILITY, FITNESS FOR A PARTICULAR 
PURPOSE AND NONINFRINGEMENT.
libipuz/debian/copyright:20: IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT 
HOLDERS BE LIABLE FOR ANY
libipuz/debian/copyright:21: CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN 
AN ACTION OF CONTRACT,
libipuz/debian/copyright:22: TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
CONNECTION WITH THE
libipuz/debian/copyright:23: SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
crosswords/debian/copyright:1:Files: *
crosswords/debian/copyright:2:Copyright: 2021 Trent W. Buck
crosswords/debian/copyright:3:License: expat
crosswords/debian/copyright:4:
crosswords/debian/copyright:5:License: expat
crosswords/debian/copyright:6: Permission is hereby granted, free of 
charge, to any person obtaining
crosswords/debian/copyright:7: a copy of this software and associated 
documentation files (the
crosswords/debian/copyright:8: "Software"), to deal in the Software without 
restriction, including
crosswords/debian/copyright:9: without limitation the rights to use, copy, 
modify, merge, publish,
crosswords/debian/copyright:10: distribute, sublicense, and/or sell copies 
of the Software, and to
crosswords/debian/copyright:11: permit persons to whom the Software is 
furnished to do so, subject to
crosswords/debian/copyright:12: the following conditions:
 

Bug#1041470: RFP: gnome-crosswords -- crossword player and editor

[Trent W. Buck]

Package: wnpp
Severity: wishlist

* Package name: gnome-crosswords
  Version : 0.3.4
  Upstream Contact: Jonathan Blandford?
* URL : https://gitlab.gnome.org/jrb/crosswords
* License : GPL3
  Programming Lang: C
  Description : crossword player and editor

Features:

 • Uses .ipuz files internally and supports a significant chunk of the open 
.ipuz spec for crosswords
 • Supports cryptic, barred, arrowword, filippine, and rebus-style puzzles
 • Loads .ipuz, .puz, and .jpz files from disk
 • Supports standalone puzzle collections of crosswords with multiple ways of 
playing them
 • External puzzle set downloaders can be used to download puzzles
 • Extensive styling support for crosswords. Square, black and white crosswords 
are traditional, but this game can also take advantage of color and shapes
 • Reveal button to find mistakes in the puzzle
 • Hint button to suggest possible answers using Peter Broda's Wordlist
 • Puzzle checksums for puzzles that don't include an answer
 • Respects the Desktop-wide dark-mode preference
 • Language-specific quirks
 • Adaptive sizing to let it work on tablets or mobile form-factors

While Debian has crossword puzzle apps, they're all very dated.
They are mostly using Xlib or Xaw so they look unpleasant.

This depends on libipuz-dev from the same author, so
that would have to be packaged at the same time.
https://gitlab.gnome.org/jrb/libipuz

I suppose technically that should also have an RFP, but
I don't think it has any use beyond "so I can have gnome-crosswords".

Bug#990486: mtools 4.0.33-1+really4.0.32-1: Internal error, size too big

[Trent W. Buck]

Silvio,

Thanks, changing "mcopy -b" to "mcopy" fixed things for me.

For the record, I attach the full scripts;
Debian 12 (4.0.33-1+really4.0.32-1) fails with -b;
Debian 11 (mtools=4.0.26-1) works with -b.
#!/usr/bin/python3
import argparse
import pathlib
import subprocess
import tempfile

__author__ = "Trent W. Buck"
__copyright__ = "Copyright © 2020 Trent W. Buck"
__license__ = "expat"

__doc__ = """ build the simplest Debian Live image that can boot

This uses mmdebstrap to do the heavy lifting;
it can run entirely without root privileges.
It emits a USB key disk image that contains a bootable EFI ESP,
which in turn includes a bootloader (refind), kernel, ramdisk, and filesystem.squashfs.

NOTE: this is the simplest config possible.
  It lacks CRITICAL SECURITY AND DATA LOSS packages, such as amd64-microcode and smartd.
"""

parser = argparse.ArgumentParser(description=__doc__)
parser.add_argument('output_file', nargs='?', default=pathlib.Path('filesystem.img'), type=pathlib.Path)
parser.add_argument('--boot-test', action='store_true')
args = parser.parse_args()


filesystem_img_size = '256M'# big enough to include filesystem.squashfs + about 64M of bootloader, kernel, and ramdisk.
esp_offset = 1024 * 1024# 1MiB
esp_label = 'UEFI-ESP'  # max 8 bytes for FAT32
live_media_path = 'debian-live'

with tempfile.TemporaryDirectory(prefix='debian-live-bullseye-amd64-minimal.') as td:
td = pathlib.Path(td)
subprocess.check_call(
['mmdebstrap',
 '--mode=unshare',
 '--variant=apt',
 '--aptopt=Acquire::http::Proxy "http://localhost:3142;',
 '--aptopt=Acquire::https::Proxy "DIRECT"',
 '--dpkgopt=force-unsafe-io',
 '--include=linux-image-amd64 init initramfs-tools live-boot netbase',
 '--include=dbus',  # https://bugs.debian.org/814758
 '--include=live-config iproute2 keyboard-configuration locales sudo user-setup',
 '--include=ifupdown isc-dhcp-client',  # live-config doesn't support systemd-networkd yet.

 # Do the **BARE MINIMUM** to make a USB key that can boot on X86_64 UEFI.
 # We use mtools so we do not ever need root privileges.
 # We can't use mkfs.vfat, as that needs kpartx or losetup (i.e. root).
 # We can't use mkfs.udf, as that needs mount (i.e. root).
 # We can't use "refind-install --usedefault" as that runs mount(8) (i.e. root).
 # We don't use genisoimage because
 # 1) ISO9660 must die;
 # 2) incomplete UDF 1.5+ support;
 # 3) resulting filesystem can't be tweaked after flashing (e.g. debian-live/site.dir/etc/systemd/network/up.network).
 #
 # We use refind because 1) I hate grub; and 2) I like refind.
 # If you want aarch64 or ia32 you need to install their BOOTxxx.EFI files.
 # If you want kernel+initrd on something other than FAT, you need refind/drivers_xxx/xxx_xxx.EFI.
 #
 # FIXME: with qemu in UEFI mode (OVMF), I get dumped into startup.nsh (UEFI REPL).
 #From there, I can manually type in "FS0:\EFI\BOOT\BOOTX64.EFI" to start refind, tho.
 #So WTF is its problem?  Does it not support fallback bootloader?
 '--include=refind parted mtools',
 '--essential-hook=echo refind refind/install_to_esp boolean false | chroot $1 debconf-set-selections',
 '--customize-hook=echo refind refind/install_to_esp boolean true  | chroot $1 debconf-set-selections',
 '--customize-hook=chroot $1 mkdir -p /boot/USB /boot/EFI/BOOT',
 '--customize-hook=chroot $1 cp /usr/share/refind/refind/refind_x64.efi /boot/EFI/BOOT/BOOTX64.EFI',
 f'--customize-hook=chroot $1 truncate --size={filesystem_img_size} /boot/USB/filesystem.img',
 f'--customize-hook=chroot $1 parted --script --align=optimal /boot/USB/filesystem.img  mklabel gpt  mkpart {esp_label} {esp_offset}b 100%  set 1 esp on',
 f'--customize-hook=chroot $1 mformat -i /boot/USB/filesystem.img@@{esp_offset} -F -v {esp_label}',
 f'--customize-hook=chroot $1 mmd -i /boot/USB/filesystem.img@@{esp_offset} ::{live_media_path}',
 f"""--customize-hook=echo '"Boot with default options" "boot=live live-media-path={live_media_path}"' >$1/boot/refind_linux.conf""",
 # NOTE: find sidesteps the "glob expands before chroot applies" problem.
 f"""--customize-hook=chroot $1 find -O3 /boot/ -xdev -mindepth 1 -maxdepth 1 -regextype posix-egrep -iregex '.*/(EFI|refind_linux.conf|vmlinuz.*|initrd.img.*)' -exec mcopy -vsbpm -i /boot/USB/filesystem.img@@{esp_offset} {{}} :: ';'""",
 # FIXME: copy-out doesn't handle sparseness, so is REALLY slow (about 50 seconds).
 # Therefore instead leave it in the s

Bug#1040245: wget-style scroll bars in syslog after Debian 11->12 upgrade

[Trent W. Buck]

Package: fwupd
Version: 1.8.12-2
Severity: minor

On Debian 11, I saw this:

$ journalctl --output=short-iso --identifier=fwupdmgr
⋮
2022-06-06T01:05:08+1000 hera fwupdmgr[906504]: Updating lvfs
2022-06-06T01:05:08+1000 hera fwupdmgr[906504]: Successfully downloaded new 
metadata: 6 local devices supported
2022-06-06T17:07:50+1000 hera fwupdmgr[1017291]: Updating lvfs
2022-06-06T17:07:51+1000 hera fwupdmgr[1017291]: Successfully downloaded 
new metadata: 6 local devices supported
2022-06-07T19:33:37+1000 hera fwupdmgr[1835934]: Updating lvfs
2022-06-07T19:33:38+1000 hera fwupdmgr[1835934]: Successfully downloaded 
new metadata: 3 local devices supported
2022-06-09T04:42:10+1000 hera fwupdmgr[2580402]: Updating lvfs
2022-06-09T04:42:11+1000 hera fwupdmgr[2580402]: Successfully downloaded 
new metadata: 3 local devices supported
⋮

On Debian 12, I see this:

$ journalctl --output=short-iso --identifier=fwupdmgr
⋮
2023-06-16T21:38:04+1000 hera fwupdmgr[471940]: Updating lvfs
2023-06-16T21:38:04+1000 hera fwupdmgr[471940]: Downloading… [ 
- ]Downloading… [ - 
]
2023-06-17T21:31:45+1000 hera fwupdmgr[897912]: Updating lvfs
2023-06-17T21:31:45+1000 hera fwupdmgr[897912]: Downloading… [ 
- ]Downloading… [ - 
]
2023-06-18T06:47:35+1000 hera fwupdmgr[1375535]: Updating lvfs
2023-06-18T06:47:36+1000 hera fwupdmgr[1375535]: Downloading… [ 
- ]Downloading… [ - 
]Downloading… [  -  
  ]Downloading… [   -   
]Downloading… [\  ]Downloading… 
[***]Downloading… 
[***]Downloading… [  \  
  ]Downloading… [   
]Downloading… [***
]Downloading… [** ]
2023-06-18T06:47:36+1000 hera fwupdmgr[1375535]: Successfully downloaded 
new metadata: 5 local devices supported
⋮

Can you please fix fwupd so the progress bar isn't logged to syslog?
If it just said "Downloading… done." or something, that would be OK.
It's the assumption that \r will erase the previous progress bar that's 
annoying -- syslog isn't a tty.

(These events also show up in logcheck emails.)


PS: I think the "Downloading" string is from 
https://salsa.debian.org/efi-team/fwupd/-/blob/debian/src/fu-console.c#L370
It seems like there's already an "isatty(1)" here: 
https://salsa.debian.org/efi-team/fwupd/-/blob/debian/src/fu-console.c#L91
I don't know why it isn't working properly anymore.  Maybe the change was in 
systemd's unit semantics, instead of fwupd?


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 fwupd depends on:
ii  adduser3.134
ii  libarchive13   3.6.2-1
ii  libc6  2.36-9
ii  libcbor0.8 0.8.0-2+b1
ii  libcurl3-gnutls7.88.1-10
ii  libefiboot137-6
ii  libflashrom1   1.3.0-2.1
ii  libfwupd2  1.8.12-2
ii  libgcab-1.0-0  1.5-1
ii  libglib2.0-0   2.74.6-2
ii  libgnutls303.7.9-2
ii  libgudev-1.0-0 237-2
ii  libgusb2   0.3.10-1
ii  libjcat1   0.1.9-1
ii  libjson-glib-1.0-0 1.6.6-1
ii  liblzma5   5.4.1-0.2
ii  libmbim-glib4  1.28.2-1
ii  libmbim-proxy  1.28.2-1
ii  libmm-glib01.20.4-1
ii  libpolkit-gobject-1-0  122-3
ii  libprotobuf-c1 1.4.1-1+b1
ii  libqmi-glib5   1.32.2-1
ii  libqmi-proxy   1.32.2-1
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.40.1-2
ii  libsystemd0252.6-1
ii  libtss2-esys-3.0.2-0   3.2.1-3
ii  libxmlb2   0.3.10-2
ii  shared-mime-info   2.2-1

Versions of packages fwupd recommends:
ii  bolt   0.9.5-1
ii  dbus   1.14.6-1
ii  fwupd-amd64-signed [fwupd-signed]  1:1.4+1
ii  jq 1.6-2.1
ii  python33.11.2-1+b1
pn  

Bug#950696: git-daemon-sysvinit: missing-systemd-service-for-init.d-script

[Trent W. Buck]

I don't use git-daemon; I use https://packages.debian.org/bookworm/klaus (and 
ssh).
I found this bug because src:git is one of the most popular packages to have a 
"missing" systemd unit.

I tested something similar to what Andreas suggested, but it did not work for 
me.
I have attached both ahead-of-time and on-demand units that work for me, at 
least enough that after

git clone --bare https://github.com/curl/curl /var/lib/git/curl.git
touch /var/lib/git/git-daemon-export-ok
touch /var/lib/git/curl.git/git-daemon-export-ok

I can do a clone through the git daemon, using

git clone git://localhost/git/curl.git && rm -rf curl

I partly cribbed from the units supplied here:


rsync://mirror.internode.on.net/archlinux/pool/packages/git-2.41.0-1-x86_64.pkg.tar.zst

Note that I have not supplied a
/lib/systemd/system-preset/50-git-daemon-sysvinit.preset because
Debian doesn't use those properly, but to mimic
/etc/default/git-daemon being disabled by default, it would be something like

# This is the non-inetd version; it isn't used by default.
mask git-daemon.service
# This is the inetd version.  It is opt-in by default.
disable git-daemon.socket

However a more logical approach would be to just add this to all three units:

ConditionPathExists=/var/lib/git

PS: I did not bother to go through "systemd-analyze security" to harden these 
units, either.
That would be the logical next step.


On Tue 04 Feb 2020 22:50:51 +0100, Andreas Henriksson wrote:
> Package: git-daemon-sysvinit
> Version: 1:2.25.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Please consider adding a native systemd service masking the already
> shipped init scripts (fixes lintian tag[1] in subject).
> 
> I'm attaching my attempt at writing a service file based on
> looking at the init script. Note that it's completely untested.
> Things to note about the service file:
> - does not reinvent start/enable of services[2], like done in init
>   script. (As discussed in #652355 already.)
> - EnvironmentFile=... takes a file with key=value syntax, but the
>   shipped default /etc/default/git-daemon file has a comment stating
>   it's a posix script snippet
> - Might be further improved with eg. security hardening[3] etc.
> 
> Please feel free to ask for additional assistance with this issue. I'm
> happy to help if you provide the testing and review (since I don't
> personally use the git-daemon-sysvinit).
> 
> Regards,
> Andreas Henriksson
> 
> 
> [1]: 
> https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
> [2]: 
> https://lintian.debian.org/tags/init.d-script-should-always-start-service.html
> [3]: 
> https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html

> [Unit]
> Description=git-daemon service
> After=network.target
> 
> [Service]
> Type=forking
> PIDFile=/run/git-daemon.pid
> Environment=GIT_DAEMON_BASE_PATH=/var/lib
> Environment=GIT_DAEMON_DIRECTORY=/var/lib/git
> Environment=GIT_DAEMON_OPTIONS=
> Environment=GIT_DAEMON_USER=gitdaemon
> EnvironmentFile=-/etc/default/git-daemon
> ExecStart=/usr/lib/git-core/git-daemon --user=$GIT_DAEMON_USER 
> --pid-file=/run/git-daemon.pid --detach --reuseaddr --verbose 
> $GIT_DAEMON_OPTIONS --base-path=$GIT_DAEMON_BASE_PATH $GIT_DAEMON_DIRECTORY
> 
> [Install]
> WantedBy=multi-user.target

[Unit]
Documentation=man:git-daemon(1)
[Socket]
ListenStream=9418
Accept=yes
[Install]
WantedBy=sockets.target
# This is "inetd-style" activated by git-daemon.socket.
# You want EITHER git-daemon.service OR git-daemon.socket + git-daemon@.service.
[Unit]
Documentation=man:git-daemon(1)
[Service]
User=gitdaemon
ExecStart=git daemon --inetd --verbose --base-path=/var/lib /var/lib/git
StandardInput=socket
StandardOutput=inherit
StandardError=journal
ProtectSystem=full
ProtectHome=on
PrivateDevices=on
NoNewPrivileges=on
[Install]
Also=git-daemon.socket
# I initially tried using EnvironmentFile= and variables, but
# git-daemon requires "--foo=$BAR" not "--foo $BAR", and
# I could not convince systemd to expand that out.
# Hard-coding everything works.
[Unit]
Documentation=man:git-daemon(1)
[Service]
Type=forking
User=gitdaemon
ExecStart=git daemon --detach --reuseaddr --verbose --base-path=/var/lib 
/var/lib/git
[Install]
WantedBy=multi-user.target

Bug#1033728: sudo-ldap might be removed post-bookworm or post-trixie

[Trent W. Buck]

On Fri 31 Mar 2023 09:41:16 +0200, Marc Haber wrote:
> Please add your reasons to this bug, so that the sudo maintainers can
> properly consider the reasons in their decision.

I personally DON'T need sudo-ldap anymore.

1. I ran sudo-ldap + slapd on an Ubuntu 10.04 farm until 2022.
   It was mainly for things like "sudo eject" (back when blank CDs were 
expensive, and HAL was still a thing) and
   "sudo ldapadduser" (to let managers onboard staff & create mailing lists 
without sysadmin help).

   I was planning to replace it with a "pure" samba AD stack, but the 
Windows-iness just got Too Hard, so
   I ended up going back to plain /etc/shadow and /etc/sudoers.d, now managed 
by ansible.

2. I set up sssd in 2022 at another site, on SLES 12, aimed at a Windows AD 
stack.
   I wasn't allowed to use sssd for sudo, though, so that site is still using 
sudoers.d (also via ansible).
   It wasn't clear if sssd-sudo required me to add additional schemata to AD, 
like sudoers-ldap does.
   If NOT, that would definitely be an advantage for sssd-ldap over sudo-ldap 
:-)

3. I run de Jong's libnss-ldapd / libpam-ldapd at another site, and it works 
well there, but again,
   the sudo rules are simple enough they get hard-coded into sudoers.d.
   I like https://manpages.debian.org/slapo-ppolicy.

4. For automated machine-to-machine jobs (e.g. zfs send/receive) I prefer to 
skip sudo altogether.
   For example, I now use https://manpages.debian.org/zfs-allow to let a 
non-root system user
   "zfs-receive-trinity" have permission to mess with ZFS dataset 
"morpheus/srv/backup/trinity".

   I've been thinking about https://archive.org/details/lca2020-Zero_Trust_SSH 
but
   right now I'm still just using Ed25519 keypairs for everything.

5. One thing I do really appreciate is that the sudoers.ldap objects
   are MUCH easier to understand than an equivalent sudoers.d config file.

dn: cn=responsible,ou=groups,o=cyber
objectClass: posixGroup
description: Staff responsible for OUR systems and networks.
description: I often reflect that if "privileges" had been called 
"responsibilities" or "duties", I would have saved thousands of hours 
explaining to people why they were only gonna get them over my dead body. -- 
Lee K. Gleason, VMS sysadmin
gidNumber: 2049
memberUID: twb
memberUID: REDACTED

dn: cn=defaults,ou=sudoers,o=cyber
objectClass: sudoRole
sudoOption: always_set_home
sudoOption: env_reset
sudoOption: ignore_dot
sudoOption: ignore_local_sudoers
sudoOption: insults
sudoOption: !setenv
sudoOption: set_logname

dn: cn=%responsible,ou=sudoers,o=cyber
objectClass: sudoRole
sudoUser: %responsible
sudoHost: ALL
sudoRunAsUser: ALL
sudoRunAsGroup: ALL
sudoCommand: ALL
sudoOption: !authenticate

dn: cn=bbq,ou=sudoers,o=cyber
description: Staff need this to burn CDs and DVDs on BBQ.
objectClass: sudoRole
sudoUser: %cyber
sudoHost: bbq
sudoRunAsUser:
sudoRunAsGroup: cdrom
sudoCommand: /usr/bin/wodim
sudoCommand: /usr/bin/cdrecord
sudoOption: noexec

   When I read an /etc/sudoers.d/ugh.conf I often start by reading
   https://manpages.debian.org/sudoers.ldap just so I don't go mad.

   If sudo could have the sudo-ldap format in flat file, I'd be happier.
   At least in cases when I have more than "%sudo (ALL:ALL) NOPASSWD: ALL".
   As an analogy, consider how much nicer it is now we can use
   /etc/apt/sources.list.d/debian.sources (deb822 format)
   instead of the old
   /etc/apt/sources.list.d/debian.list(legacy format)

Bug#1039270: Here's my monit.service

[Trent W. Buck]

FYI, attached are my monit systemd units.
They are definitely "too hardened" for some users.
You can PROBABLY just take everything before the hardening part, and use that 
as-is.

In particular, I deliberately prevent monit running as root
(I want systemd to restart units; I just want monit to check the availability 
of remote hosts).
This required some kludges because (IIRC) monit wants to have write access to 
its own config (like cupsd, or a crappy PHP webapp).

The NRPE replacement's "server" side should be here:
https://github.com/cyberitsolutions/die-nrpe-die
but I never got around to git filter-repo'ing the publishable parts out, so
I've attached a minified version of that as well.
[Unit]
Description=Pro-active monitoring utility for unix systems
After=network-online.target
Documentation=man:monit(1) https://mmonit.com/wiki/Monit/HowTo


# NOTE: "monit --interactive" means Run_Foreground and skips daemonize() 
(Type=simple).
#   This prevents systemd distinguishing "starting" from "started" 
(Type=forking).  Meh?
#   This DOES NOT prevent monit doing a weird "if monit is already running, 
just kill -USR1 it, and exit(0)"!
#   
https://bitbucket.org/tildeslash/monit/src/release-5-32-0/src/monit.c#lines-195:205
#   
https://bitbucket.org/tildeslash/monit/src/release-5-32-0/src/monit.c#lines-563:584
#   Overall, I think Type=forking gives systemd slightly better information.
#   Type=forking is required if you want to e.g. Before=nginx.service.
#
# NOTE: "monit reload" is basically "kill -HUP $MAINPID", but
#   it doesn't require "apt install procps".
[Service]
Type=forking
ExecStartPre=monit --test
ExecStart=monit
ExecReload=monit reload


# FIXME: sometimes on "systemctl start monit" or "systemctl restart monit",
#monit simply exits immediately.
#This can happen after unattended-upgrades + needrestart restart monit
#due to a library getting a security patch!
#
#
# /join irc://irc.cyber.com.au/#cyber
# 11:11  Why is monit down
# 11:12  Something stopped it at 6:25 which is when cron.daily runs
# 11:16  2022-11-20T06:25:01.984164+11:00 heavy systemd[1]: 
cron-daily.service: Succeeded.
# 11:16  2022-11-20T06:25:05.905322+11:00 heavy systemd[1]: Stopping 
Apt-Cacher NG software download proxy...
# 11:16  2022-11-20T06:25:05.906880+11:00 heavy systemd[1]: Stopping 
Statistics collection and monitoring daemon...
# 11:16  2022-11-20T06:25:05.910253+11:00 heavy systemd[1]: Stopping 
Pro-active monitoring utility for unix systems...
# 11:16  ...why?
# 11:17  Maybe needrestart did it in response to a package upgrade
# 11:17  2022-11-20T06:25:08.540726+11:00 heavy systemd[1]: Starting 
Statistics collection and monitoring daemon...
# 11:17  ...but then
# 11:17  it doesn't actually start properly
# 11:17  So I think there's two things here:
# 11:18  1) something in morning cron restarted a bunch of services
# 11:18  2) sometimes monit doesn't restart properly, and instead simply 
exits
# 11:18  I had seen (2) before not after I stopped messing with it
# 11:18  Same thing again when I run it by hand just now
# 11:20  monit is doing something like exit(0) for no reason
# 11:20  but not deterministically
# 11:20  An ugly workaround might be to set 'restart=always' instead of 
just on-error
# 12:06  mike: I've gotten nowhere debugging this
# 12:07  mike: I'm going to do what you suggest
#
# /join ircs://irc.libera.chat/#monit
# 11:21  So I have this problem where SOMETIMES monit when told to start 
as a daemon, will instead just exit immediately
# 11:21  http://ix.io/4gHg
#
#   twb@heavy:~$ sudo systemctl start monit
#   [sudo] password for twb:
#   twb@heavy:~$ sudo systemctl status monit
#   ● monit.service - Pro-active monitoring utility for unix systems
#Loaded: loaded (/etc/systemd/system/monit.service; 
enabled; vendor preset: enabled)
#Active: inactive (dead) since Thu 2022-11-24 11:18:40 
AEDT; 3s ago
#  Docs: man:monit(1)
#https://mmonit.com/wiki/Monit/HowTo
#   Process: 2059508 ExecStartPre=chown -h monit: 
/etc/monit/monitrc (code=exited, status=0/SUCCESS)
#   Process: 2059509 ExecStartPre=chmod 0600 /etc/monit/monitrc 
(code=exited, status=0/SUCCESS)
#   Process: 2059510 ExecStart=monit (code=exited, 
status=0/SUCCESS)
#  Main PID: 2059512 (code=exited, status=0/SUCCESS)
#   CPU: 272ms
#
#   Nov 24 11:18:40 heavy systemd[1]: Starting Pro-active 
monitoring utility for unix systems...
#   Nov 24 11:18:40 heavy monit[2059510]: Starting Monit 5.27.2 
daemon with http interface at [*]:2812
#   Nov 24 11:18:40 heavy monit[2059510]: Starting Monit 5.27.2 
daemon with http interface at [*]:2812
#   Nov 24 11:18:40 heavy systemd[1]: Started Pro-active monitoring 
utility for unix systems.

Bug#1038621: Please ACTUALLY remove the Depends: binutils

[Trent W. Buck]

Package: needrestart
Version: 3.6-4
Severity: minor

I upgraded to Debian 12, hoping this stupid error would finally go away:

bash5$ check-support-status
Limited security support for one or more packages

Unfortunately, it has been necessary to limit security support for some
packages.

The following packages found on this system are affected by this:

* Source:binutils
  Details: Only suitable for trusted content; see 
https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
  Affected binary packages:
  - binutils (installed version: 2.40-2)
  - binutils-common:amd64 (installed version: 2.40-2)
  - binutils-x86-64-linux-gnu (installed version: 2.40-2)
  - libbinutils:amd64 (installed version: 2.40-2)
  - libctf-nobfd0:amd64 (installed version: 2.40-2)
  - libctf0:amd64 (installed version: 2.40-2)
  - libgprofng0:amd64 (installed version: 2.40-2)

Because I knew this had happened some time ago:


https://github.com/liske/needrestart/commit/e6176258e6b9f9f907736cbe1f8d148582a057d9
https://sources.debian.org/src/needrestart/3.6-4/debian/changelog/#L39-L40
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986507

However, the binutils dependency was not actually removed!

https://sources.debian.org/src/needrestart/3.6-4/debian/control/#L24

Can you please fix this (remove "Depends: binutils")?
I can't find the git repo with the debian/ tree in it (there's no VCS-Git in 
debian/control).
So I'm not 100% sure if this was intentional (needrestart needs binutils for 
something else), or simply an oversight.


-- Package-specific info:
needrestart output:

checkrestart output:


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 needrestart depends on:
ii  binutils   2.40-2
ii  dpkg   1.21.22
ii  gettext-base   0.21-12
ii  libintl-perl   1.33-1
ii  libmodule-find-perl0.16-2
ii  libmodule-scandeps-perl1.31-2
ii  libproc-processtable-perl  0.634-1+b2
ii  libsort-naturally-perl 1.03-4
ii  libterm-readkey-perl   2.38-2+b1
ii  perl   5.36.0-7
ii  xz-utils   5.4.1-0.2

Versions of packages needrestart recommends:
ii  libpam-systemd  252.6-1
ii  systemd 252.6-1

Versions of packages needrestart suggests:
ii  iucode-tool  2.3.1-3
ii  needrestart-session  0.3-11

-- no debconf information

Bug#1036151: remove /etc/hostid?

[Trent W. Buck]

Package: mmdebstrap
Version: 0.7.5-2.2
Severity: wishlist

Before /etc/machine-id, there was /etc/hostid.  It's kinda crap.
It is in glibc and coreutils, but only ZFS really uses it.

https://manpages.debian.org/bullseye/manpages-dev/gethostid.3.en.html
https://manpages.debian.org/bullseye/manpages-dev/sethostid.3.en.html
https://manpages.debian.org/bullseye/coreutils/hostid.1.en.html

https://manpages.debian.org/bullseye-backports/zfsutils-linux/zgenhostid.8.en.html

https://manpages.debian.org/bullseye-backports/zfsutils-linux/zpoolprops.7.en.html#multihost

# systemctl start zfs-import-scan
zpool: cannot import 'test': pool was previously in use from another system.
zpool: Last accessed by alice-understudy (hostid=31a99d02) at Tue May 16 
13:35:57 2023
zpool: The pool can be imported, use 'zpool import -f' to import the pool.

With --include=zfs-dkms,zfsutils-linux you get an /etc/hostid in mmdebstrap's 
output.
I think /etc/hostid should be removed, like /etc/machine-id.
I think this would go under "cleanup/reproducible", like

if (-e "$options->{root}/etc/hostid") {
unlink "$options->{root}/etc/hostid"
  or error "cannot unlink /etc/hostid: $!";
}


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

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 mmdebstrap depends on:
ii  apt  2.2.4
ii  perl 5.32.1-4+deb11u2
ii  python3  3.9.2-3

Versions of packages mmdebstrap recommends:
ii  arch-test0.17-1
ii  fakechroot   2.19-3.3
ii  fakeroot 1.25.3-1.1
ii  gpg  2.2.27-2+deb11u2
ii  libdistro-info-perl  1.0
ii  mount2.36.1-8+deb11u1
ii  uidmap   1:4.8.1-1

Versions of packages mmdebstrap suggests:
ii  apt [apt-transport-https]  2.2.4
pn  apt-transport-tor  
ii  apt-utils  2.2.4
ii  binfmt-support 2.2.1-1+deb11u1
ii  ca-certificates20210119
pn  debootstrap
ii  distro-info-data   0.51+deb11u3
ii  dpkg-dev   1.20.12
ii  perl-doc   5.32.1-4+deb11u2
pn  proot  
ii  qemu-user  1:7.2+dfsg-3~bpo11+1
ii  qemu-user-static   1:7.2+dfsg-3~bpo11+1
ii  squashfs-tools-ng  1.0.4-1

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/mmdebstrap (from mmdebstrap package)

Bug#1035568: dnsmasq is broken on new bookworm installations

[Trent W. Buck]

On Fri 05 May 2023 15:17:37 +, Jens Meißner wrote:
> dnsmasq on bookworm fails to start after installation because the dns port 53 
> is already is use by systemd-resolved.
> After stopping systemd-resolved dnsmasq will start but refuses all dns 
> queries with the Extended DNS Error Code 14 "Not Ready".
> This error is reproducible on new installation.

First of all, this should block dnsmasq.service (binary package "dnsmasq"), but
it should NOT block /usr/sbin/dnsmasq (binary package "dnsmasq-base").
The latter is needed by things like libvirtd and network-manager!



Here is how I solved this on my Debian 11 router:

  1. in /etc/dnsmasq.d/cyber-kludges.conf

  # Don't fight nsd and systemd-resolved for control over ports.
  # Also don't shit yourself at boot time if dnsmasq starts before the 
ifaces are up.
  # The combination of options is a little confusing.
  # "--ignore-address=203.7.155.4" does something COMPLETELY unrelated, so
  # instead we need to whitelist the OTHER dmz address (203.7.155.1).
  # Then we need to whitelist the other ifaces, else it would bind ONLY to 
203.7.155.1.
  bind-dynamic
  interface=lo
  interface=byod
  interface=lan
  listen-address=203.7.155.1
  no-dhcp-interface=dmz
  listen-address=10.194.71.1
  no-dhcp-interface=vpn
  except-interface=internet


  # Proxy DNSv4/DNSv6 from the internet.
  # HARD CODE the upstream servers.
  # We SHOULD get them dynamically from systemd-networkd (the 
DHCPv4/RA/DHCPv6 client on the "internet" interface).
  # However, that requires third-party software like 
https://gitlab.com/craftyguy/networkd-dispatcher
  # Since Aussie Broadband rarely (if ever) change these, hard-coding them 
is Good EnoughTM.
  # I considered also/instead adding the Cloudflare and/or Google anycast 
DNS servers from here:
  # https://github.com/systemd/systemd/blob/main/docs/DISTRO_PORTING.md
  # ...but those DNS servers will direct us to more distant hosts.
  # For example, "deb.debian.org" is
  #  8ms away using the address from AB or CF, but
  # 22ms away using the address from Google.
  no-resolv
  all-servers
  cache-size=8192
  server=202.142.142.142
  server=202.142.142.242
  server=2403:5800:100:1::142
  server=2403:5800:1:5::242

  # THIS BIT IS ONLY NEEDED BECAUSE I *ALSO* RUN NSD.
  # IT IS NOT NEEDED FOR systemd-resolve + dnsmasq.
  # Don't go out to the internet and back in, for our own domains.
  # This also means e.g. "logserv" still works when the internet is down.
  server=/cyber.com.au/155.7.203.in-addr.arpa/203.7.155.4

  2. in /etc/systemd/network/00-dmz.network, tell systemd-networkd (and thus 
resolved) about dnsmasq

  [Match]
  Name=dmz
  [Link]
  RequiredForOnline=no
  [Network]
  Domains=cyber.com.au
  Address=203.7.155.1/26
  Address=203.7.155.4/26
  Address=203.7.155.49/26
  # THESE NEXT TWO LINES ARE THE RELEVANT ONES FOR 1035568
  Domains=cyber.com.au ~155.7.203.in-addr.arpa
  DNS=203.7.155.1

   3. install libnss-resolve and make this link

  lrwxrwxrwx 1 root root 24 Feb 24  2021 /etc/resolv.conf -> 
/lib/systemd/resolv.conf

In other words, what I have is:

  a. local nss users go

   libnss_resolve
   -> resolved (via socket)
  -> dnsmasq on 203.7.155.1 (for cyber.com.au and 
155.7.203.in-addr.arpa)

  -> whatever systemd-networkd got from upstream DHCP/DHCPv6 (for every 
other domain)

  b. local /etc/resolv.conf users go

   -> resolved on 127.0.0.53 (via UDP)
   [rest as above]

Because of the quirky way to code this in dnsmasq,
there is no good way to write a general default dnsmasq.conf to hook it up this 
way.

The other potential way to hook this up is to simply tell resolved not to 
listen on 127.0.0.53:53 (DNSStubListener=no in /etc/systemd/resolved.conf).
HOWEVER, it then means that name resolution is different for glibc (nss) versus 
everyone else, because

  a. local nss users go

 libnss_resolve
 -> resolved (via socket)
 -> whatever systemd-networkd got from upstream DHCP/DHCPv6 (for all 
domains)

 ...NEVER see RRs in dnsmasq.

  b. local resolv.conf users cannot go to resolved, because it now only listens 
on a AF_UNIX socket, not AF_DGRAM (UDP).

 So it either points directly upstream (typical legacy setup in dhclient) 
and bypasses BOTH dnsmasq and resolved; or
 it's set to 127.0.0.1 (i.e. dnsmasq) and bypasses resolved.

 Note that networkd has NO WAY to tell dnsmasq what DNS server(s) are 
supplied by upstream .network files / DHCP responses.
 networkd can only tell resolved that (I last checked back in v247).


PS: I have also seen deeply inconsistent results when there are unqualified 
names in /etc/hosts (e.g. "10.1.2.3 alice")
because libnss_files.so, dnsmasq, and resolved treat those differently.  In 
essence, 

Bug#1013448: pcre2 relies on write+execute mappings unnecessarily

[Trent W. Buck]

FYI,

systemd's MemoryDenyWriteExecute=yes breaks "git grep" because of pcre2jit.

An easy test command is something like this:

$ journalctl --user -fn0 &   # so you see the error
$ systemd-run --property=MemoryDenyWriteExecute=yes --user git -C 
/srv/vcs/kb grep -Fwi mutt

--error--> git[2289491]: fatal: Couldn't JIT the PCRE2 pattern 'mutt', got 
'-48'

A real-world use case is hardening gitit.service,
a git-based wiki .
With MemoryDenyWriteExecute=yes, gitit works perfectly, EXCEPT for search 
(which uses "git grep" under the hood).

Is there a way for a sysadmin to disable pcre2jit at runtime, e.g. with an 
environment variable?
I understand it makes pcre2 slower, but I might actually prefer to make that 
security-vs-speed tradeoff.
I looked at https://manpages.debian.org/pcre2jit but only found compile-time 
options.


See also https://github.com/systemd/systemd/issues/5970

Bug#1034239: vterm-mode make-process fails in an unshare(1)?

[Trent W. Buck]

Package: elpa-vterm
Version: 0.0.2+git20230217.3e5a9b7-1
Severity: normal

I've wanted to try vterm for a couple of years, but not enough to trust melpa 
with a C compiler.
I noticed it's in bookworm, but I'm still on bullseye, so I spun up a container 
to test it.
Unfortunately, it's not working at all in the container:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  vterm--set-pty-name(# nil)
  vterm-mode()
  vterm--internal(pop-to-buffer-same-window nil)
  vterm(nil)
  funcall-interactively(vterm nil)
  command-execute(vterm)
  command-line-1(("-f" "toggle-debug-on-error" "-f" "vterm"))
  command-line()
  normal-top-level()

The command I ran was this:

mmdebstrap bookworm /dev/null --customize-hook='chroot $1 env -i TERM=vt100 
PATH=/bin emacs -f toggle-debug-on-error -f vterm; false' 
--include=emacs-nox,elpa-vterm,ncurses-base,usrmerge

I also tried some other variations, like this (no improvement):

mmdebstrap --aptopt='Acquire::http::Proxy "http://[::1]:3142;' 
--dpkgopt=force-unsafe-io --variant=apt bookworm /dev/null  
--customize-hook='chroot $1 env PAGER=cat LOGNAME=root USERNAME=root USER=root 
HOME=/root emacs -f toggle-debug-on-error -f vterm; false' 
--include=emacs-nox,elpa-vterm,ncurses-base

I tried doing C-u C-M-x on vterm-mode, then stepping through it.
When I did that, Emacs crashed (segfault, dump core).

Here's the backtrace of that:

bash5$ coredumpctl list --since=-1h
TIME PIDUIDGID SIG COREFILE EXE 
 SIZE
Tue 2023-04-11 17:28:22 AEST 1970182 10 10 SIGSEGV inaccessible 
/tmp/mmdebstrap.PtAiFer3xS/usr/bin/emacs-nox-
Tue 2023-04-11 17:39:46 AEST 1974335 10 10 SIGSEGV inaccessible 
/tmp/mmdebstrap.APQHGHHtCi/usr/bin/emacs-nox-
bash5$ coredumpctl info 1970182 1974335
   PID: 1970182 (emacs)
   UID: 10 (10)
   GID: 10 (10)
Signal: 11 (SEGV)
 Timestamp: Tue 2023-04-11 17:28:21 AEST (29min ago)
  Command Line: emacs -f toggle-debug-on-error -f vterm
Executable: /tmp/mmdebstrap.PtAiFer3xS/usr/bin/emacs-nox
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/gnome-terminal-server.service
  Unit: user@1000.service
 User Unit: gnome-terminal-server.service
 Slice: user-1000.slice
 Owner UID: 1000 (twb)
   Boot ID: 3f4a7af4e0db401887a00190ddffd551
Machine ID: 029d2e3fb4ee4d5eaa67c315db3ba66d
  Hostname: hera
   Storage: 
/var/lib/systemd/coredump/core.emacs.10.3f4a7af4e0db401887a00190ddffd551.1970182.168119810100.zst
 (inaccessible)
   Package: systemd/252.6-1
  build-id: ec45aeba740496bc309cc07882b0a061a3ad64f7
   Message: Process 1970182 (emacs) of user 10 dumped core.

Module /usr/bin/emacs-nox from deb systemd-252.6-1.amd64
Module 
/root/.emacs.d/eln-cache/28.2-15c5d1e2/ielm-2a8237b7-eb124f6e.eln from deb 
systemd-252.6-1.amd64
Module 
/root/.emacs.d/eln-cache/28.2-15c5d1e2/misearch-3d1286b0-5dfbae2a.eln from deb 
systemd-252.6-1.amd64
Module 
/usr/lib/emacs/28.2/native-lisp/28.2-15c5d1e2/comp-cstr-ef162ef7-d21e459f.eln 
from deb systemd-252.6-1.amd64
Module 
/usr/lib/emacs/28.2/native-lisp/28.2-15c5d1e2/warnings-28e75f4d-870b026e.eln 
from deb systemd-252.6-1.amd64
Module 
/usr/lib/emacs/28.2/native-lisp/28.2-15c5d1e2/rx-627d8c83-dfb131e2.eln from deb 
systemd-252.6-1.amd64
Module 
/usr/lib/emacs/28.2/native-lisp/28.2-15c5d1e2/cl-extra-d7051cba-b4a2a77f.eln 
from deb systemd-252.6-1.amd64
Module 
/usr/lib/emacs/28.2/native-lisp/28.2-15c5d1e2/comp-7672a6ed-15edf202.eln from 
deb systemd-252.6-1.amd64
Module 
/root/.emacs.d/eln-cache/28.2-15c5d1e2/radix-tree-669a468d-fa18562f.eln from 
deb systemd-252.6-1.amd64
Module 
/root/.emacs.d/eln-cache/28.2-15c5d1e2/help-fns-d233c6e8-7adaac53.eln from deb 
systemd-252.6-1.amd64
Module 
/root/.emacs.d/eln-cache/28.2-15c5d1e2/cl-print-79bf9fb1-244c7280.eln from deb 
systemd-252.6-1.amd64
Module 
/usr/lib/emacs/28.2/native-lisp/28.2-15c5d1e2/help-mode-d4dbae3d-aaa71a7e.eln 
from deb systemd-252.6-1.amd64
Module 
/root/.emacs.d/eln-cache/28.2-15c5d1e2/backtrace-f58a28c5-7ec5fbcd.eln from deb 
systemd-252.6-1.amd64
Module 
/root/.emacs.d/eln-cache/28.2-15c5d1e2/debug-bee52b4d-68f66c17.eln from deb 
systemd-252.6-1.amd64
Module 
/root/.emacs.d/eln-cache/28.2-15c5d1e2/kmacro-048feaec-498151b6.eln from deb 
systemd-252.6-1.amd64
Module 
/root/.emacs.d/eln-cache/28.2-15c5d1e2/pp-5d47c1cc-de730a1a.eln from deb 

Bug#701065: git-add--interactive: should depend on (or at least recommend) libterm-readkey-perl

[Trent W. Buck]

On Thu 21 Feb 2013 17:10:49 +0900, Liyang HU wrote:
> Package: git
> Version: 1:1.7.10.4-1ubuntu1
> Severity: normal
> 
> In order for the interactive.singlekey option to work at all,
> libterm-readkey-perl should be installed.
> 
> Every time I install git on a fresh system, I end up reading through
> /usr/lib/git-core/git-add--interactive and Googling to figure this out.
> 
> I think this should be a 'Depends', or at the very least a 'Recommends'.

Can we at least have "git Suggests: libterm-readkey-perl"?

Like Liyang, I also struggle to find this package every time I move to a new 
system.
Making this relation visible to apt will make it much easier for me to find it.



Having Term::ReadKey installed HALVES the amount of typing for "git commit -p", 
which is really handy!

Here is the context, from the manpage:

   interactive.singleKey

   In interactive commands, allow the user to provide one-letter input 
with a single key (i.e., without hitting enter).

   Currently this is used by the --patch mode of
   git-add(1),
   git-checkout(1),
   git-restore(1),
   git-commit(1),
   git-reset(1), and
   git-stash(1).

   Note that this setting is silently ignored if portable keystroke 
input is not available;
   requires the Perl module Term::ReadKey.


https://manpages.debian.org/bullseye-backports/git-man/git-config.1.en.html#interactive.singlekey

Bug#1020328: Acknowledgement (Native systemd units)

[Trent W. Buck]

On Wed 07 Dec 2022 23:46:43 +, Richard Lewis wrote:
> I have been studying and experimenting - and learning a lot.
> For exim4, i found ⋯

I slurped your exim notes into my repo.
I probably won't do any actual testing with exim myself :-)


https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/commits/main/systemd/system/0-EXAMPLES/30-allow-mail-exim.conf

I was indeed originally plannign to push it into Debian as a kind of "apt 
install increased-hardening" package.
But I ran into enough nitpicking and static, my current approach is to instead 
try to work on individual packages, and
try to push upstreams to be more hardened by default.

e.g. SyscallFilters=@foo isn't backwards-compatible with old systemd, so
you can't use it if you don't know a minimum systemd version.

e.g. Architecture=native works fine until someone does something like "apt 
install curl:armhf".

e.g. the whole "if you call /usr/sbin/sendmail, everything becomes messy"

> - whether the unit is 'oneshot' - if so the unit needs to ensure exim has
> delivered the mail before the script exits - adding a small 'sleep' is
> enough - i think otherwise systemd gets confused about what process to
> monitor if the script causes exim to launch.

That doesn't sound right, but I suppose it's possible.
KillMode=process might trigger that.

> - whether or not the unit runs as root or a different user. With User=root
> you can get away with more hardening directives, but i think better to
> continue running as a non-root user

I think you'll find this is just because User=root implicitly disables a bunch 
of the settings.
If you set User=root, then "systemctl daemon-reload" then "systemd-analyze 
security foo.service",
you will see a bunch of stuff like:

Service runs as root, option does not matter
Service runs as root, option does not apply

PS: "systemd-analyze syscall-filter" is a good thing to look at when dealing 
with chown/seteuid.

Bug#1025223: minor

[Trent W. Buck]

Package: parted
Version: 3.4-1
Severity: normal

https://en.wikipedia.org/wiki/GUID_Partition_Table says

[Linux is] limited to 256 partitions per disk.^[19]

https://web.archive.org/web/20200326214544/https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/include/linux/genhd.h

Windows [is] limited to 128 partitions per disk.^[27]

https://msdn.microsoft.com/en-us/library/windows/hardware/dn640535%28v=vs.85%29.aspx

>From sheer orneriness, I wanted to make a disk image with a
partition that Linux could see, and Windows couldn't -- like a hidden track on 
an LP.
https://en.wikipedia.org/wiki/Hidden_track

But parted seems to be limited to 128 GPT partitions (test transcript below).
Is this a fundamental limitation of GPT?
If not, can parted be changed to allow 256 partitions?

bash5$ with-temp-dir
with-temp-dir: entering directory `/tmp/with-temp-dir.LUG7Fz'
This directory will be deleted when you exit.

bash5$ truncate -s1P delete-me.img

bash5$ parted -saopt delete-me.img mklabel gpt $(for i in {1..512..2}; do 
echo "mkpart $i ext2 $((2048*i))s $((2048*(i+1)))s"; done)
Error: Too many primary partitions.

bash5$ parted -saopt delete-me.img print
Model:  (file)
Disk /tmp/with-temp-dir.LUG7Fz/delete-me.img: 1126TB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End SizeFile system  Name  Flags
 1  1049kB  2098kB  1049kB   1
 2  3146kB  4195kB  1049kB   3
 3  5243kB  6292kB  1049kB   5
 4  7340kB  8389kB  1049kB   7
 5  9437kB  10.5MB  1049kB   9
 6  11.5MB  12.6MB  1049kB   11
 7  13.6MB  14.7MB  1049kB   13
 8  15.7MB  16.8MB  1049kB   15
 9  17.8MB  18.9MB  1049kB   17
10  19.9MB  21.0MB  1049kB   19
11  22.0MB  23.1MB  1049kB   21
12  24.1MB  25.2MB  1049kB   23
13  26.2MB  27.3MB  1049kB   25
14  28.3MB  29.4MB  1049kB   27
15  30.4MB  31.5MB  1049kB   29
16  32.5MB  33.6MB  1049kB   31
17  34.6MB  35.7MB  1049kB   33
18  36.7MB  37.7MB  1049kB   35
19  38.8MB  39.8MB  1049kB   37
20  40.9MB  41.9MB  1049kB   39
21  43.0MB  44.0MB  1049kB   41
22  45.1MB  46.1MB  1049kB   43
23  47.2MB  48.2MB  1049kB   45
24  49.3MB  50.3MB  1049kB   47
25  51.4MB  52.4MB  1049kB   49
26  53.5MB  54.5MB  1049kB   51
27  55.6MB  56.6MB  1049kB   53
28  57.7MB  58.7MB  1049kB   55
29  59.8MB  60.8MB  1049kB   57
30  61.9MB  62.9MB  1049kB   59
31  64.0MB  65.0MB  1049kB   61
32  66.1MB  67.1MB  1049kB   63
33  68.2MB  69.2MB  1049kB   65
34  70.3MB  71.3MB  1049kB   67
35  72.4MB  73.4MB  1049kB   69
36  74.4MB  75.5MB  1049kB   71
37  76.5MB  77.6MB  1049kB   73
38  78.6MB  79.7MB  1049kB   75
39  80.7MB  81.8MB  1049kB   77
40  82.8MB  83.9MB  1049kB   79
41  84.9MB  86.0MB  1049kB   81
42  87.0MB  88.1MB  1049kB   83
43  89.1MB  90.2MB  1049kB   85
44  91.2MB  92.3MB  1049kB   87
45  93.3MB  94.4MB  1049kB   89
46  95.4MB  96.5MB  1049kB   91
47  97.5MB  98.6MB  1049kB   93
48  99.6MB  101MB   1049kB   95
49  102MB   103MB   1049kB   97
50  104MB   105MB   1049kB   99
51  106MB   107MB   1049kB   101
52  108MB   109MB   1049kB   103
53  110MB   111MB   1049kB   105
54  112MB   113MB   1049kB   107
55  114MB   115MB   1049kB   109
56  116MB   117MB   1049kB   111
57  118MB   120MB   1049kB   113
58  121MB   122MB   1049kB   115
59  123MB   124MB   1049kB   117
60  125MB   126MB   1049kB   119
61  127MB   128MB   1049kB   121
62  129MB   130MB   1049kB   123
63  131MB   132MB   1049kB   125
64  133MB   134MB   1049kB   127
65  135MB   136MB   1049kB   129
66  137MB   138MB   1049kB   131
67  139MB   141MB   1049kB   133
68  142MB   143MB   1049kB   

Bug#1024977: mmutf8fix does not fix omusrmsg

[Trent W. Buck]

Package: rsyslog
Version: 8.2102.0-2+deb11u1
Severity: minor

Using the attached rsyslog.conf, with this test log:

/usr/bin/printf 'TEST BYTES 
\xc3\xb1\xc3\x28\xa0\xa1\xe2\x82\xa1\xe2\x28\xa1\xe2\x82\x28\xf0\x90\x8c\xbc\xf0\x28\x8c\xbc\xf0\x90\x28\xbc\xf0\x28\x8c\x28\xf8\xa1\xa1\xa1\xa1\xfc\xa1\xa1\xa1\xa1\xa1'
 | logger -p auth.0 -t invalid-utf8-test

...I find that mmutf8fix has fixed auth.log, but not the emergency
event printed to logged-in terminals.

I *guess* this is because omusrmsg uses "properties" instead of "the message"?

Note that once it has been called, it actually modifies the message.
The original messsage is then no longer available.
However, this DOES NOT CHANGE ANY PROPERTIES set, used or extracted before 
the modification is done.


https://rsyslog.readthedocs.io/en/latest/configuration/modules/mmutf8fix.html


This issue doesn't really bother me, but
it would be nice if it was explicitly mentioned in the documentation, e.g.

For example, omusrmsg will not be affected, because
it uses properties (ignored by mmutf8fix) and ignores the message (fixed by 
mmutf8fix).



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

Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
$umask 0022
$WorkDirectory /var/spool/rsyslog
$MaxOpenFiles 2

module(load="imuxsock")
module(load="imklog")
module(load="imudp")
module(load="imrelp")
input(type="imudp" port="514")
input(type="imrelp" port="2514" KeepAlive="on")

module(load="mmutf8fix")
action(type="mmutf8fix")

template(name="PrisonPCFileFormat" type="list") {
property(name="timegenerated" dateFormat="rfc3339")
constant(value=" ")
property(name="hostname")
constant(value=" ")
property(name="syslogtag" field.delimiter="58" field.number="1")
constant(value=":")
property(name="msg" spifno1stsp="on")
property(name="msg" droplastlf="on")
constant(value="\n")
}

module(load="builtin:omfile"
   template="PrisonPCFileFormat"
   dirCreateMode="0755"
   fileCreateMode="0640"
   fileOwner="root"
   fileGroup="adm")

if ($syslogfacility-text == "auth" or $syslogfacility-text == "authpriv") then {
action(type="omfile"
   file="/var/log/auth.log"
   sync="off"
   asyncWriting="on"
   flushInterval="1"
   ioBufferSize="128K")
} else {
action(type="omfile"
   file="/var/log/syslog"
   sync="off"
   asyncWriting="on"
   flushInterval="5"
   ioBufferSize="128K")
}

if ($syslogpriority-text == "emerg") then {
action(type="omusrmsg" users="*")
}

$IncludeConfig /etc/rsyslog.d/*.conf

Bug#1024975: systemd hardening

[Trent W. Buck]

Package: motion
Version: 4.3.2-1
Severity: wishlist

Attached is my systemd hardening errata for motion.
It won't work for everyone, but
at least SOME of it could be added to debian/motion.service.


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

Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
# Security hardening.
#
# Read from http://camera1.cyber.com.au
# Write to file:///var/lib/motion/
# Write to smtp://localhost
[Service]
CapabilityBoundingSet=
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
RestrictNamespaces=yes
DevicePolicy=closed
NoNewPrivileges=yes
PrivateDevices=yes
PrivateMounts=yes
PrivateTmp=yes
PrivateUsers=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=noaccess
ProtectSystem=strict
ProcSubset=pid
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallFilter=~@privileged
SystemCallFilter=~@resources
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RemoveIPC=yes
UMask=0027
ProtectHostname=yes

IPAddressAllow=localhost
IPAddressAllow=203.7.155.0/24
IPAddressDeny=any

WorkingDirectory=/var/lib/%p

## This is causing me problems by chowning things I don't want it to!
# StateDirectory=%p

# 19:11  TIL if you do ReadWritePaths=/a/b/c /a/b/d  then your systemd 
unit can't rename(2) /a/b/c/evidence.mkv to /a/b/d/evidence.mkv
# 19:12  Because even though they're the same filesystem, the UNIT sees 
them as separate bind mounts
# ReadWritePaths=/var/lib/motion/new
# ReadWritePaths=/var/lib/motion/old

ReadWritePaths=/var/lib/motion


$ systemd-analyze security motion
  NAMEDESCRIPTION   
 EXPOSURE
✗ PrivateNetwork= Service has 
access to the host's network0.5
✓ User=/DynamicUser=  Service runs 
under a static non-root user identity 
✓ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP)Service cannot 
change UID/GID identities/capabilities  
✓ CapabilityBoundingSet=~CAP_SYS_ADMINService has no 
administrator privileges
✓ CapabilityBoundingSet=~CAP_SYS_PTRACE   Service has no 
ptrace() debugging abilities
✗ RestrictAddressFamilies=~AF_(INET|INET6)Service may 
allocate Internet sockets   0.3
✓ RestrictNamespaces=~CLONE_NEWUSER   Service cannot 
create user namespaces  
✓ RestrictAddressFamilies=~…  Service cannot 
allocate exotic sockets 
✓ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP)   Service cannot 
change file ownership/access mode/capabilities  
✓ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service cannot 
override UNIX file/IPC permission checks
✓ CapabilityBoundingSet=~CAP_NET_ADMINService has no 
network configuration privileges
✓ CapabilityBoundingSet=~CAP_SYS_MODULE   Service cannot 
load kernel modules 
✓ CapabilityBoundingSet=~CAP_SYS_RAWIOService has no 
raw I/O access  
✓ CapabilityBoundingSet=~CAP_SYS_TIME Service processes 
cannot change the system clock   
✗ DeviceAllow=Service has a 
device ACL with some special devices  0.1
✗ IPAddressDeny=  Service defines 
IP address allow list with non-localhost entries0.1
✓ KeyringMode=Service doesn't 
share key material with other services 
✓ NoNewPrivileges=Service processes 
cannot acquire new privileges
✓ NotifyAccess=   Service child 
processes cannot alter 

Bug#1024973: systemd hardening

[Trent W. Buck]

Package: ircd-irc2
Version: 2.11.2p3~dfsg-5.1
Severity: wishlist

Attached is my systemd hardening errata for ircd-irc2.
It won't work for everyone, but
at least SOME of it could be added to debian/ircd-irc2.service.


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

Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
# Security hardening.
[Service]
CapabilityBoundingSet=
PrivateDevices=yes
ProtectClock=yes
NoNewPrivileges=yes
ProtectKernelLogs=yes
RemoveIPC=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
SystemCallArchitectures=native
MemoryDenyWriteExecute=yes
RestrictNamespaces=yes
RestrictSUIDSGID=yes
ProtectHostname=yes
LockPersonality=yes
ProtectKernelTunables=yes
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
RestrictRealtime=yes
ProtectSystem=strict
ProcSubset=pid
ProtectHome=yes
PrivateUsers=yes
PrivateTmp=yes
SystemCallFilter=@system-service
SystemCallFilter=~@privileged
SystemCallFilter=~@resources
# These syscalls shouldn't actually be needed, but
# whatever, I don't care.
SystemCallFilter=@setuid
IPAddressDeny=any
IPAddressAllow=localhost
IPAddressAllow=203.7.155.0/24
IPAddressAllow=10.194.71.0/24
UMask=0077
$ systemd-analyze security ircd-irc2.service
  NAMEDESCRIPTION   

  EXPOSURE
✗ PrivateNetwork= Service has 
access to the host's network
 0.5
✓ User=/DynamicUser=  Service runs 
under a static non-root user identity
✓ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP)Service cannot 
change UID/GID identities/capabilities
✓ CapabilityBoundingSet=~CAP_SYS_ADMINService has no 
administrator privileges
✓ CapabilityBoundingSet=~CAP_SYS_PTRACE   Service has no 
ptrace() debugging abilities
✗ RestrictAddressFamilies=~AF_(INET|INET6)Service may 
allocate Internet sockets   
 0.3
✓ RestrictNamespaces=~CLONE_NEWUSER   Service cannot 
create user namespaces
✓ RestrictAddressFamilies=~…  Service cannot 
allocate exotic sockets
✓ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP)   Service cannot 
change file ownership/access mode/capabilities
✓ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service cannot 
override UNIX file/IPC permission checks
✓ CapabilityBoundingSet=~CAP_NET_ADMINService has no 
network configuration privileges
✓ CapabilityBoundingSet=~CAP_SYS_MODULE   Service cannot 
load kernel modules
✓ CapabilityBoundingSet=~CAP_SYS_RAWIOService has no 
raw I/O access
✓ CapabilityBoundingSet=~CAP_SYS_TIME Service processes 
cannot change the system clock
✗ DeviceAllow=Service has a 
device ACL with some special devices
   0.1
✗ IPAddressDeny=  Service defines 
IP address allow list with non-localhost entries
 0.1
✓ KeyringMode=Service doesn't 
share key material with other services
✓ NoNewPrivileges=Service processes 
cannot acquire new privileges
✓ NotifyAccess=   Service child 
processes cannot alter service state
✓ PrivateDevices= Service has no 
access to hardware devices
✓ PrivateMounts=  Service cannot 
install system mounts
✓ PrivateTmp= Service has no 
access to other software's temporary files
✓ PrivateUsers=   Service does not 
have access to other users
✓ ProtectClock=   Service cannot 
write to the hardware clock or system clock
✓ ProtectControlGroups=   Service cannot 
modify the control group file system
✓ ProtectHome=Service has no 
access to home directories
✓ ProtectKernelLogs=  

Bug#771631: dnsmasq: Please add ProtectSystem=yes to systemd service file

[Trent W. Buck]

On Wed 17 Dec 2014 20:52:30 +, Simon Kelley wrote:
> There's a potential problem with this: dnsmasq has an option to invoke
> child processes when the DHCP lease database changes, using the
> - --dhcp-script option. By making this change, those processes are going
> to be invoked with read-only /usr. That's probably fine in most cases,
> but there's no certainty that someone's script doesn't write /usr, and
> for that script, this is a non-backwards compatible change.

Is it sensible for the default dnsmasq.service and the default dnsmasq.conf to 
"match"?
That is, dnsmasq.service could block things dnsmasq doesn't do by default 
anyway.

If the sysadmin chooses to turn on --dhcp-script in /etc/dnsmasq.d/foo.conf,
they can also turn off hardening in 
/etc/systemd/system/dnsmasq.service.d/foo.conf.

I agree this is a backwards-incompatible change, but
you can drop a comment in debian/NEWS to say something like

This version of dnsmasq enables systemd hardening by default.
If you are upgrading and have previously enabled --dhcp-script, you
may need to change ProtectSystem=strict to ProtectSystem=no in 
dnsmasq.service.
e.g. "systemctl edit dnsmasq && systemctl restart dnsmasq".

Attached is a full hardening I'm running on Debian 11.
It definitely won't work for everyone, but
surely SOME of these can be turned on for 99.9% of users,
i.e. be on by default?
# Security hardening.
#
# dnsmasq needs to bind to low ports (53, 67).
# It doesn't support socket activation.
#  (and, it needs a raw socket for DHCPv4 which systemd.socket can't 
do)
# Therefore we have two choices:
#
#   1. dnsmasq manages priv-dropping;
#  systemd allows access to seteuid, setpcap, /etc/passwd, 
#
#   2. systemd manages priv-dropping;
#  systemd restricts it, but dnsmasq and its children permanently keep 
CAP_NET_*
#  (since dnsmasq lacks permission to remove them after it has initialized).
#
# For now, I'm going with #1.
[Service]

# Lease files are typically found in here.
# It is root:root rw-r--r--.
# Therefore either we start as root, or
# we have CAP_DAC_OVERRIDE ambient capability.
ReadWritePaths=-/var/lib/misc
CapabilityBoundingSet=CAP_DAC_OVERRIDE

# ProtectSystem=strict blocks /run, so
# re-allow write access to /run/dnsmasq (pidfiles, mainly).
RuntimeDirectory=%p

CapabilityBoundingSet=CAP_SETGID CAP_SETUID CAP_SETPCAP
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
RestrictNamespaces=yes
DevicePolicy=closed
NoNewPrivileges=yes
PrivateDevices=yes
PrivateMounts=yes
PrivateTmp=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=noaccess
ProtectSystem=strict
ProcSubset=pid
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
#SystemCallFilter=~@privileged
#SystemCallFilter=@chown @setuid capset capset32
SystemCallFilter=~@resources
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
UMask=0077
ProtectHostname=yes


# Upstream has this:
# ExecReload=/bin/kill -HUP $MAINPID
# which gets this:
# kill[572676]: kill: (535038): Operation not permitted
#
# As a quick and dirty fix, just run kill with full privs.
ExecReload=
ExecReload=+/bin/kill -HUP $MAINPID
$ systemd-analyze security dnsmasq.service
  NAMEDESCRIPTION   
  
EXPOSURE
✗ PrivateNetwork= Service has 
access to the host's network
 0.5
✗ User=/DynamicUser=  Service runs as 
root user   
 0.4
✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP)Service may 
change UID/GID identities/capabilities  
 0.3
✓ CapabilityBoundingSet=~CAP_SYS_ADMINService has no 
administrator privileges
✓ CapabilityBoundingSet=~CAP_SYS_PTRACE   Service has no 
ptrace() debugging abilities
✗ RestrictAddressFamilies=~AF_(INET|INET6)Service may 
allocate Internet sockets   
 0.3
✓ RestrictNamespaces=~CLONE_NEWUSER   Service cannot 
create user namespaces
✓ RestrictAddressFamilies=~…  Service cannot 
allocate exotic sockets
✓ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP)   Service cannot 
change file ownership/access mode/capabilities
✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may 
override UNIX file/IPC permission checks
 0.2
✗ 

Bug#1024673: Fix violations.ignore.d/logcheck-sudo (too precise)

[Trent W. Buck]

Package: logcheck-database
Version: 1.3.23
Severity: wishlist

This line is wrong in sudo 1.9.4+ (Debian 11+):


https://salsa.debian.org/debian/logcheck/-/blob/master/rulefiles/linux/violations.ignore.d/logcheck-sudo#L2

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
TTY=(unknown|console|(pts/|tty|vc/)[[:digit:]]+) ; PWD=[^;]+ ; 
USER=[._[:alnum:]-]+( ; GROUP=[._[:alnum:]-]+)? ; 
COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$

For example this real-world log event (compare "ssh X sudo Y" and "ssh X -t 
sudo Y", I think):

2022-11-23T03:27:25.170510+11:00 obese sudo: zfs-receive : 
PWD=/etc/zfs-receive ; USER=root ; COMMAND=/sbin/zfs receive -F -o 
mountpoint=/srv/backup/light -o canmount=noauto -o readonly=on obese/light

To fix the regexp, *AT LEAST* this change is needed (making TTY= optional):

-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
TTY=(unknown|console|(pts/|tty|vc/)[[:digit:]]+) ; PWD=[^;]+ ; 
USER=[._[:alnum:]-]+( ; GROUP=[._[:alnum:]-]+)? ; 
COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
(TTY=(unknown|console|(pts/|tty|vc/)[[:digit:]]+) ; )?PWD=[^;]+ ; 
USER=[._[:alnum:]-]+( ; GROUP=[._[:alnum:]-]+)? ; 
COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$

However, if you look at the actual source code:


https://github.com/sudo-project/sudo/blob/SUDO_1_9_5p2/lib/eventlog/eventlog.c#L60-L68

https://github.com/sudo-project/sudo/blob/SUDO_1_9_5p2/lib/eventlog/eventlog.c#L204-L284

You can see that ALL these fields are only included if they are actually set 
("if (details->⋯ != NULL)").

At which point we might as well have something like this:

-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
TTY=(unknown|console|(pts/|tty|vc/)[[:digit:]]+) ; PWD=[^;]+ ; 
USER=[._[:alnum:]-]+( ; GROUP=[._[:alnum:]-]+)? ; 
COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
((HOST|TTY|CHROOT|PWD|USER|GROUP|ENV|TSID)=[^ ;]+ ; 
)?COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$

What do you think?

Note that if you want to target Debian 12+, you need to handle 2 more fields, 
"EXIT" and "SIGNAL":

-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
TTY=(unknown|console|(pts/|tty|vc/)[[:digit:]]+) ; PWD=[^;]+ ; 
USER=[._[:alnum:]-]+( ; GROUP=[._[:alnum:]-]+)? ; 
COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
((HOST|TTY|CHROOT|PWD|USER|GROUP|ENV|TSID|EXIT|SIGNAL)=[^ ;]+ ; 
)?COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$

PS: another trivial way to confuse existing logcheck is this (missing "ENV="):

sudo HOME=/nonexistent id  # logcheck considers this a 
"Security Event"
sudo env HOME=/nonexistent id  # logcheck considers this harmless

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

Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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

Bug#1001647:

[Trent W. Buck]

Short version:

  • This works: printf 'options.plugins_url=""\noptions.motd_url=""\n' > 
~/.visidatarc
  • Your earlier suggestion does not work anymore.


Boring technical details follow.

On Mon 13 Dec 2021 18:58:27 -0800, Anja wrote:
> For now, you can set `options.plugins_url=None` to your `~/.visidatarc` to
> turn that off. `open-plugins` will not work, but if you do not want your
> software making network requests, you probably would not want that feature.

I am a nosy bystander.
I do not use visicalc (I use awk and sqlite ).

By default "visidata" causes two files to be created (by downloading).

~/.visidata/cache/https%3A%2F%2Fvisidata.org%2Fmotd-2.2.1
~/.visidata/cache/https%3A%2F%2Fvisidata.org%2Fplugins%2Fplugins.jsonl

One of them "leaks" the visidata version number.

https://sources.debian.org/src/visidata/2.2.1-1/visidata/motd.py/?hl=8#L16

Your suggested option did NOT have any effect (both files are created):

echo options.plugins_url=None > ~/.visidatarc

However, this DID work (neither file is created):

printf 'options.plugins_url=""\noptions.motd_url=""\n' > ~/.visidatarc

A full transcript is attached.
bash5$ mmdebstrap bullseye /dev/null \
--customize-hook='chroot $1 env HOME=/root bash; false' \
--include=visidata,ca-certificates
> > I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.CSr8eY4FbU as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
done
done
I: running --customize-hook in shell: sh -c 'chroot $1 env HOME=/root bash; 
false' exec /tmp/mmdebstrap.CSr8eY4FbU
root@hera:/# visidata
› visidata_menu| user_macros | saul.pw/VisiData v2.2.1 | Ctrl+H opens help  

 open-vd11 metasheets q
root@hera:/# root@hera:/# find /root/
/root/
/root/.visidata
/root/.visidata/cache
/root/.visidata/cache/https%3A%2F%2Fvisidata.org%2Fmotd-2.2.1
/root/.visidata/cache/https%3A%2F%2Fvisidata.org%2Fplugins%2Fplugins.jsonl
/root/.bashrc
/root/.profile
root@hera:/# rm -rf /root/.visidata
root@hera:/# echo options.plugins_url=None > ~/.visidatarc
root@hera:/# visidata
› visidata_menu| user_macros | saul.pw/VisiData v2.2.1 | Ctrl+Hopen-vd  
  11 metasheets q
root@hera:/# root@hera:/# find /root/
/root/
/root/.visidata
/root/.visidata/cache
/root/.visidata/cache/https%3A%2F%2Fvisidata.org%2Fplugins%2Fplugins.jsonl
/root/.visidata/cache/https%3A%2F%2Fvisidata.org%2Fmotd-2.2.1
/root/.visidatarc
/root/.bashrc
/root/.profile
root@hera:/# rm -rf /root/.visidata
root@hera:/# printf 'options.plugins_url=""\noptions.motd_url=""\n' > 
~/.visidatarc
root@hera:/# visidata
› visidata_menu| user_macros | saul.pw/VisiData v2.2.1 | Ctrl+Hopen-vd  
  11 metasheets q
root@hera:/# root@hera:/# find /root/
/root/
/root/.visidatarc
/root/.bashrc
/root/.profile
root@hera:/# exit
E: run_chroot failed: E: command failed: chroot $1 env HOME=/root bash; false
W: listening on child socket failed: 
I: removing tempdir /tmp/mmdebstrap.CSr8eY4FbU...
bash5$ 

Bug#1020328: Acknowledgement (Native systemd units)

[Trent W. Buck]

On Wed 09 Nov 2022 19:29:56 +1100, Trent W. Buck wrote:
> In short, what I'm saying is:
> 
>   1. you can't harden a script/daemon that uses the "fork+exec 
> /usr/sbin/sendmail" API, because
>  different /usr/sbin/sendmail implementations (e.g. postfix) require 
> different privileges.
> 
>  In particular, "requires setgid" prevents ALL of the following hardening 
> options:
> 
> DynamicUser LockPersonality MemoryDenyWriteExecute
> NoNewPrivileges PrivateDevices  ProtectClock
> ProtectHostname ProtectKernelLogs   ProtectKernelModules
> ProtectKernelTunables   RestrictAddressFamilies RestrictNamespaces
> RestrictRealtimeRestrictSUIDSGID
> SystemCallArchitectures
> SystemCallFilterSystemCallLog
> 
>   2. the smtp://localhost:25 API is usually available.
> 
>  It prevents fewer hardening options:
> 
> PrivateNetwork=yes
> IPAddressDeny=any
> RestrictAddressFamilies=~AF_TCP
> 
>  Basically you have to leave TCP/IP unblocked, but that's all.

I made a minor braino here, it should be AF_INET AF_INET6 not AF_TCP.

My old (Debian 9) notes about different techniques are here:


https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/0-EXAMPLES

30-allow-mail-msmtp.conf: # → Overall exposure 
level: 1.0 OK 

30-allow-mail-postfix-via-msmtp.conf: # → Overall exposure 
level: 0.9 SAFE 

30-allow-mail-postfix-root-dac-override.conf: # → Overall exposure 
level: 1.1 OK 
30-allow-mail-postfix-root-sys-admin.conf:# → Overall exposure 
level: 1.4 OK 

30-allow-mail-postfix-non-root-addgroup.conf: # → Overall exposure 
level: 0.5 SAFE 
30-allow-mail-postfix-non-root-dac-override.conf: # → Overall exposure 
level: 0.9 SAFE 
30-allow-mail-postfix-non-root-setgid.conf:   # → Overall exposure 
level: 2.4 OK 

Bug#1020328: Acknowledgement (Native systemd units)

[Trent W. Buck]

On Fri 04 Nov 2022 00:45:52 +, Richard Lewis wrote:
> Hi trent - i am interested in this approach:
> 
> i see you are binding msmtp over /usr/sbin/sendmail  -  i dont
> understand how this would lead to a different outcome: how else does
> msmtp know where to send the mail? is there some implicit assumption
> about local delivery here? i tried testing but msmtp  does not work at
> all out of the box for me - complains that it has no configuration
> file)

If you install msmtp you need to configure it.
Just as if you installed postfix, you would need to configure it.

"dpkg-reconfigure msmtp" ought to prompt you, but
here are some basic examples:

1.  $ sudo apt install msmtp postfix

$ cat >/etc/msmtprc <<'EOF'
# Send everything to postfix (smtp://localhost:25)
account default
  syslog on
  auto_from on
  host localhost
EOF

2.  $ sudo apt install msmtp-mta

$ cat >/etc/msmtprc <<'EOF'
# Send everything to gmail (no "real" MTA on localhost)
account default
  syslog on
  auto_from on
  host smtp.gmail.com
  port 587
  tls on
  auth on
  user alice
  passwordeval /usr/bin/cat /etc/secret.gmail.password
EOF

$ printf swordfish >/etc/secret.gmail.password

$ chmod 640 /etc/secret.gmail.password
$ chown -h root:logcheck /etc/secret.gmail.password

> As far as i can tell, the issue isn't with the "send mail" part, but
> the part where the mta (exim/postfix) tries to deliver it

I don't know about exim.

When /usr/sbin/sendmail is implemented by postfix (i.e. "apt install postfix),

1. sendmail calls postdrop
2. postdrop is sgid postdrop, so now you run with elevated privileges
3. postdrop writes to /var/spool/postfix/maildrop, which normal users can't 
write to

Note the sgid bit:

-rwxr-xr-x 1 rootroot  /usr/sbin/sendmail
-r-xr-sr-x 1 rootpostdrop  /usr/sbin/postdrop
drwx-wx--T 2 postfix postdrop  /var/spool/postfix/maildrop

If you use systemd hardening NoNewPrivileges=yes, that DISABLES SETGID -- by 
design.

So logcheck.service run /usr/bin/logcheck
which runs /usr/bin/mail
which runs /usr/sbin/sendmail
which runs /usr/sbin/postdrop
which DOESN'T get escalated privileges (group postdrop)
which FAILS to write to /var/spool/postfix/maildrop/.

By telling logcheck.service "actually just use msmtp", the path instead becomes

logcheck.service runs /usr/bin/logcheck
which runs /usr/bin/mail
which runs /usr/sbin/sendmail (actually /usr/bin/msmtp)
which connects to (say) smtp://localhost:25 or smtp://smtp.gmail.com:587

Thereafter, the rest of the flow (whatever is listening on
localhost:25) is not running inside the logcheck.service hardened
namespace/cgroup.  So it can do whatever it wants.


In short, what I'm saying is:

  1. you can't harden a script/daemon that uses the "fork+exec 
/usr/sbin/sendmail" API, because
 different /usr/sbin/sendmail implementations (e.g. postfix) require 
different privileges.

 In particular, "requires setgid" prevents ALL of the following hardening 
options:

DynamicUser LockPersonality MemoryDenyWriteExecute
NoNewPrivileges PrivateDevices  ProtectClock
ProtectHostname ProtectKernelLogs   ProtectKernelModules
ProtectKernelTunables   RestrictAddressFamilies RestrictNamespaces
RestrictRealtimeRestrictSUIDSGIDSystemCallArchitectures
SystemCallFilterSystemCallLog

  2. the smtp://localhost:25 API is usually available.

 It prevents fewer hardening options:

PrivateNetwork=yes
IPAddressDeny=any
RestrictAddressFamilies=~AF_TCP

 Basically you have to leave TCP/IP unblocked, but that's all.

  3. msmtp is a quick and easy way to convert (1) to (2).

  4. "apt install msmtp-mta" does (3) easily, but
 won't work if a "real" MTA is already installed.

  5. BindReadOnlyPaths=/usr/bin/msmtp:/usr/sbin/sendmail does (3), and
 works even if a "real" MTA is installed.

Bug#1022799: Support "protocol syslog"?

[Trent W. Buck]

Package: monit
Version: 1:5.27.2-1
Severity: wishlist

I had something like this:

check host  example.com
address example.com
if failed port 514 type udp then alert

This causes the receiving rsyslog to log a weird event, like this:

2022-10-26 19:09:49+11:00 example.net :

where we would expect more like

2022-10-26 19:09:49+11:00 example.net frobozzd[123]: success

I did a little bit of reading, and this seems to be Good EnoughTM:

check host  example.com
address example.com
if failed port 514 type udp
# https://www.rfc-editor.org/rfc/rfc5424#section-6.5
# 15 = LOG_USER (1) × 8 + LOG_DEBUG (7)
# syslog version 1 (RFC 5424)
# unknown time (-)
# hard-coded hostname (heavy)
# process name (monit)
# unknown process ID (-)
# no structured data (-)
# no message ID (-)
# a test message
send "<15>1 - example.net monit - - - testing if 514/UDP is open"
then alert

However it'd be nicer if I could just write

check host  example.com
address example.com
if failed port 514 type udp protocol syslog then alert

Can that "send" be baked into monit's C code in src/protocols/syslog.c ?

If so, it could also be a little bit better,
e.g. include correct timestamp, hostname, and PID.


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

Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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

Bug#1019624: UPSONIC IRT-3K 2U broken by length checking in blazer_usb/nutdrv_qx

[Trent W. Buck]

On Fri 21 Oct 2022 21:35:18 +0200, Laurent Bigonville wrote:
> On Tue, 13 Sep 2022 10:19:24 +1000 "Trent W. Buck" 
> wrote:
> Hello,
> >
> > Short version:
> >
> > 1. UPSONIC IRT-3K 2U speaks a variant of Q1 which omits final \r.
> > 2. nut 2.4 doesn't check for final \r, so it Just Works.
> > 3. nut 2.7 checks for final \r, cannot talk to my UPS.
> > 4. I fixed #3 but it's not very good.
> 
> Do you think you could check whether nut 2.8.0 (currently in unstable) works
> with your UPS?

That UPS is currently in production, so I can't easily mess with it.
I also do not have a spare.

However, I did find this which looks like the same bug:

https://github.com/networkupstools/nut/issues/441
https://github.com/zykh/nut/commit/1595a06501daa93e06035a861e3db7ccab2871dd

I don't know how I missed this earlier.

> Otherwise if the bug is still happening, could you please open a bug
> upstream if it's not already done?

I'm happy enough to mark this as done in sid.
When Debian 12 ships, if I run into this again, I'll reopen it.

I added a comment upstream:

https://github.com/networkupstools/nut/issues/441#issuecomment-1288238345

Bug#1010126: FYI working example .service

[Trent W. Buck]

Please find attached the .service I am using on Debian 11.
You don't need all of this crap, I guess.

 * The msmtp stuff is only needed if you have a git post-commit hook that
   makes git send an email.

 * The nginx stuff is only needed if you want to have >1 web app on the 
standard port.

 * The tmpfiles stuff (and git config core.sharedRepository)
   is only needed if users want to bypass the web UI and edit .pages directly.
   It's also a bit broken (adds needless execute permissions) right now.

 * The theme stuff is only needed if you hate the default theme.
   https://github.com/trentbuck/gitit-bootstrap-theme/


For simple cases, you could probably replace the sysusers file with 
DynamicUser=yes,
and just have gitit store all its state in /var/lib/gitit (StateDirectory=%p).


The only issue I've had with this setup so far is gitit claiming static files 
disappear, when they don't.
There's no user-visible impact when this happens.
It wasn't happening on the old (2010-era) gitit install I had running under 
upstart.

-- Journal begins at Sat 2022-08-06 18:32:36 AEST, ends at Tue 2022-10-04 
15:29:20 AEDT. --
Sep 26 12:54:20 heavy systemd[1]: Started gitit.service.
Sep 26 12:55:19 heavy gitit[2522]: HTTP request failed with: 
Network.Socket.sendBuf: resource vanished (Broken pipe)
Sep 26 12:55:29 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/bootstrap4/css/bootstrap.min.css:
 withFd: resource vanished (Broken pipe)
Sep 26 12:55:29 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/logo.svg: withFd: 
resource vanished (Broken pipe)
Sep 26 12:55:29 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/css/screen.css: withFd: 
resource vanished (Broken pipe)
Sep 26 12:55:29 heavy gitit[2522]: HTTP request failed with: 
/usr/share/gitit/data/static/css/highlighting.css: withFd: resource vanished 
(Broken pipe)
Sep 26 12:55:41 heavy gitit[2522]: HTTP request failed with: 
Network.Socket.sendBuf: resource vanished (Broken pipe)
Sep 26 12:55:46 heavy gitit[2522]: HTTP request failed with: 
Network.Socket.sendBuf: resource vanished (Broken pipe)
Sep 26 16:26:34 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Broken pipe)
Sep 26 18:00:09 heavy gitit[2522]: HTTP request failed with: 
Network.Socket.sendBuf: resource vanished (Broken pipe)
Sep 26 23:43:33 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/css/screen.css: withFd: 
resource vanished (Broken pipe)
Sep 26 23:43:33 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/css/print.css: withFd: 
resource vanished (Broken pipe)
Sep 26 23:43:33 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/fonts-fork-awesome/fonts/forkawesome-webfont.woff2:
 withFd: resource vanished (Broken pipe)
Sep 26 23:43:33 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Connection reset by peer)
Sep 27 12:53:13 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Broken pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/gitit/data/static/js/footnotes.js: withFd: resource vanished (Broken 
pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/logo.svg: withFd: 
resource vanished (Broken pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/gitit/data/static/js/jquery.min.js: withFd: resource vanished 
(Broken pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/css/screen.css: withFd: 
resource vanished (Broken pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/gitit/data/static/css/highlighting.css: withFd: resource vanished 
(Broken pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/css/print.css: withFd: 
resource vanished (Broken pipe)
Sep 28 19:25:00 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Broken pipe)
Sep 28 19:25:27 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Broken pipe)
Sep 29 10:02:17 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Broken pipe)
Oct 03 06:44:23 heavy 

Bug#1020328: Acknowledgement (Native systemd units)

[Trent W. Buck]

UPDATE: a debian/logcheck.tmpfiles (/etc/tmpfiles.d/logcheck.conf) is also 
needed.
The security hardening I added prevents logcheck from creating it.
See attached.
# Hardened logcheck.service started complaining after a reboot:
#
# systemd[1]: Starting logcheck — email sysadmin about anomalous log 
events...
# logcheck[807044]: mkdir: cannot create directory ‘/run/lock/logcheck’: 
Read-only file system
# msmtp[808400]: host=localhost tls=off auth=off from=logch...@cyber.com.au 
recipients=logcheck mailsize=1368 smtpstatus=250 smtpmsg='250 2.0.0 Ok: queued 
as CB96A283D8' exitcode=EX_OK
# systemd[1]: logcheck.service: Succeeded.
#
# It didn't complain BEFORE the reboot, presumably because that dir already 
existed.
# 
https://salsa.debian.org/debian/logcheck/-/blob/debian/1.3.24/src/logcheck#L653-657
#
# Move that "make sure the dir exists" into the separate systemd daemon whose 
entire job is to do that.
#
#  I have an existing batch job that I don't want to patch.
#   It is doing
#   LOCKDIR=/run/lock/logcheck
#   if [ ! -d "$LOCKDIR" ]; then mkdir -m 0755 "$LOCKDIR" fi
#   This fails when the .service is hardened.
#   Is there a way to make systemd manage that dir?
#   I initially thought RuntimeDirectory=%p, but that's /run/logcheck not 
/run/lock/logcheck.
#   I don't see anything relevant in "git grep -Fw lock -- man".
#   I guess I can write a tmpfiles.d, and then 
ReadWritePaths=/run/lock/logcheck...
#   Oh the latter is probably implicitly there already.
d /run/lock/logcheck 0755 logcheck logcheck - -
# If we just use Debian 11 default /etc/cron.d/logcheck, with systemd-cron,
# then after an unattended-upgrade, I regularly see this:
#
# $ systemctl status
# ● heavy
# State: degraded
#  Jobs: 0 queued
#Failed: 1 units
#
# $ systemctl –state=failed
#   UNIT   LOAD  ACTIVE SUBDESCRIPTION
# ● cron-logcheck-logcheck-1.timer not-found failed failed 
cron-logcheck-logcheck-1.timer
#
# This is a minor nuisance.
# If we create a native unit with the same name as the /etc/cron.d job,
# systemd-cron will automatically skip the /etc/cron.d job.
# This will make the annoying state=degraded go away.

[Unit]
Description=logcheck — email sysadmin about anomalous log events
Documentation=https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d

# NOTE: if using systemd-cron, "logcheck.timer exists" will automatically 
disable /etc/cron.d/logcheck.
#   if using vixie cron, you will need to change /etc/cron.d/logcheck to 
either
# 1) not exist; or
# 2) have something like like "[ -d /run/systemd ] ||"
#
# FIXME: Can I express this cron job as *ONE* .timer/.service pair?
#
https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d
#The hard part is to supply -R ("reboot mode") iff the unit was started 
due to OnBootSec=, and not OnCalendar=.
#For now, I will just accept that reboot jobs lack a "Reboot:" in the 
subject line.
# twb: if the command is different, then no. you'll have to 
write two services and two timers
#I don't think the -R is very important, so I say: "sorry, you can't 
have that feature anymore".

# logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; 
fi
[Unit]
ConditionPathExists=/usr/sbin/logcheck

[Service]
Type=oneshot
ExecStart=logcheck
Nice=10
User=logcheck

# logcheck sends an "on reboot" email.
# That ought to wait until the mail can reach a remote smarthost.
# As we aren't gated by vixie crond anymore,
# copy the "after network is up" from cron.service?
#  TIL cron.service will cheerfully start before the network is up, even 
though
#   cron mails might just flop around on the floor without a remote 
smarthost.
#  (Specifically I'm thinking of @reboot jobs and msmtp-mta)
# OK so let's just add a wild-ass sloppy guess.
[Unit]
After=remote-fs.target nss-user-lookup.target network-online.target



# Security hardening.
[Service]
CapabilityBoundingSet=
RestrictAddressFamilies=AF_UNIX
RestrictNamespaces=yes
DevicePolicy=closed
IPAddressDeny=any
NoNewPrivileges=yes
PrivateDevices=yes
PrivateMounts=yes
PrivateTmp=yes
PrivateUsers=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=noaccess
ProtectSystem=strict
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallFilter=~@privileged @resources
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RemoveIPC=yes
UMask=0077
ProtectHostname=yes
ProcSubset=pid
# Implicitly grants read-write access to /var/lib/logcheck, needed for the 
inode+offset stamp files.
StateDirectory=%p
# Use msmtp (not postfix) for sendmail.
# Trick logcheck(8)/mail(1) into using msmtp instead of postfix.
# This is because sendmail(1postfix) requires sgid maildrop.
# 

Bug#1020399: Please add Suggests: openssh-client

[Trent W. Buck]

Package: gvfs-backends
Version: 1.46.2-1
Severity: wishlist

To the best of my knowledge, "gio mount sftp://example.com; works by running 
"ssh example.com -s sftp".
It cannot use libssh (used by qemu); nor libssh2 (used by curl), nor dropbear 
dbclient[0].

To make this a little more obvious, please add "Suggests: openssh-client" to 
debian/control.

[0] 
https://sources.debian.org/src/gvfs/1.50.2-2/daemon/gvfsbackendsftp.c/#L247-L261

https://sources.debian.org/src/gvfs/1.50.2-2/daemon/gvfsbackendsftp.c/#L480-L520


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

Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 gvfs-backends depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gvfs 1.46.2-1
ii  gvfs-common  1.46.2-1
ii  gvfs-daemons 1.46.2-1
ii  gvfs-libs1.46.2-1
ii  libarchive13 3.4.3-2+deb11u1
ii  libavahi-client3 0.8-5+deb11u1
ii  libavahi-common3 0.8-5+deb11u1
ii  libavahi-glib1   0.8-5+deb11u1
ii  libc62.31-13+deb11u4
ii  libcdio-cdda210.2+2.0.0-1+b2
ii  libcdio-paranoia210.2+2.0.0-1+b2
ii  libcdio192.1.0-2
ii  libgcrypt20  1.8.7-6
ii  libgdata22   0.17.13-3
ii  libglib2.0-0 2.66.8-1
ii  libgoa-1.0-0b3.38.0-3
ii  libgphoto2-6 2.5.27-1
ii  libgphoto2-port122.5.27-1
ii  libgudev-1.0-0   234-1
ii  libimobiledevice61.3.0-6
ii  libmtp9  1.1.17-3
ii  libnfs13 4.0.0-1
ii  libplist32.2.0-6
ii  libpolkit-gobject-1-00.105-31+deb11u1
ii  libsmbclient 2:4.16.1+dfsg-8~bpo11+1
ii  libsoup2.4-1 2.72.0-2
ii  libusb-1.0-0 2:1.0.24-3
ii  libxml2  2.9.10+dfsg-6.7+deb11u2
ii  psmisc   23.4-2

Versions of packages gvfs-backends recommends:
ii  gnome-keyring  3.36.0-1

Versions of packages gvfs-backends suggests:
ii  bluez-obexd   5.55-3.1
ii  samba-common  2:4.16.1+dfsg-8~bpo11+1

-- no debconf information

Bug#1020328: Native systemd units

[Trent W. Buck]

Package: logcheck
Version: 1.3.23
Severity: wishlist

Please find attached a logcheck.timer and logcheck.service.
I just wrote them; they Work For Me™ so far.

If you just ship these, systemd-cron will automatically skip 
/etc/cron.d/logcheck.
Vixie cron might need something like this to manually skip /etc/cron.d/logcheck:

if ! [ -e /run/systemd ]; then ... ; fi

The "Security hardening" section is too aggressive to work for postfix, exim, 

If you ship this, you'll want to skip some/all of the hardening for portability 
reasons.

logcheck calls /usr/bin/mime-construct, which ONLY supports
/usr/sbin/sendmail.  Replacing /usr/sbin/sendmail with SMTP
(e.g. python3's smtplib) is one way to keep maximum systemd-level
hardening, without needing a bunch of MTA-specific workarounds.



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

Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
[Unit]
Description=logcheck — email sysadmin about anomalous log events
Documentation=https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d

[Install]
WantedBy=timers.target

[Timer]
# /etc/cron.d/logcheck said: "@reboot"
# https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d
# Round this up to "a little bit after boot".
OnStartupSec=2m

# /etc/cron.d/logcheck said: "2 * * * *"
# https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d
# Hourly, two minutes past the hour.
# Is there any reason to not just do OnCalendar=hourly?
# I guess the concern is overlapping with other @hourly jobs.
# Since this is the Debian default, keep it for now.
OnCalendar=*-*-* *:02:00
# If we just use Debian 11 default /etc/cron.d/logcheck, with systemd-cron,
# then after an unattended-upgrade, I regularly see this:
#
# $ systemctl status
# ● heavy
# State: degraded
#  Jobs: 0 queued
#Failed: 1 units
#
# $ systemctl –state=failed
#   UNIT   LOAD  ACTIVE SUBDESCRIPTION
# ● cron-logcheck-logcheck-1.timer not-found failed failed 
cron-logcheck-logcheck-1.timer
#
# This is a minor nuisance.
# If we create a native unit with the same name as the /etc/cron.d job,
# systemd-cron will automatically skip the /etc/cron.d job.
# This will make the annoying state=degraded go away.

[Unit]
Description=logcheck — email sysadmin about anomalous log events
Documentation=https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d

# NOTE: if using systemd-cron, "logcheck.timer exists" will automatically 
disable /etc/cron.d/logcheck.
#   if using vixie cron, you will need to change /etc/cron.d/logcheck to 
either
# 1) not exist; or
# 2) have something like like "[ -d /run/systemd ] ||"
#
# FIXME: Can I express this cron job as *ONE* .timer/.service pair?
#
https://salsa.debian.org/debian/logcheck/-/blob/master/debian/logcheck.cron.d
#The hard part is to supply -R ("reboot mode") iff the unit was started 
due to OnBootSec=, and not OnCalendar=.
#For now, I will just accept that reboot jobs lack a "Reboot:" in the 
subject line.
# twb: if the command is different, then no. you'll have to 
write two services and two timers
#I don't think the -R is very important, so I say: "sorry, you can't 
have that feature anymore".

# logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; 
fi
[Unit]
ConditionPathExists=/usr/sbin/logcheck

[Service]
Type=oneshot
ExecStart=logcheck
Nice=10
User=logcheck

# logcheck sends an "on reboot" email.
# That ought to wait until the mail can reach a remote smarthost.
# As we aren't gated by vixie crond anymore,
# copy the "after network is up" from cron.service?
#  TIL cron.service will cheerfully start before the network is up, even 
though
#   cron mails might just flop around on the floor without a remote 
smarthost.
#  (Specifically I'm thinking of @reboot jobs and msmtp-mta)
# OK so let's just add a wild-ass sloppy guess.
[Unit]
After=remote-fs.target nss-user-lookup.target network-online.target



# Security hardening.
[Service]
CapabilityBoundingSet=
RestrictAddressFamilies=AF_UNIX
RestrictNamespaces=yes
DevicePolicy=closed
IPAddressDeny=any
NoNewPrivileges=yes
PrivateDevices=yes
PrivateMounts=yes
PrivateTmp=yes
PrivateUsers=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=noaccess
ProtectSystem=strict
RestrictSUIDSGID=yes

Bug#1007152: RFP: virtiofsd -- vhost-user virtio-fs device backend written in Rust

[Trent W. Buck]

Thomas Koch wrote:
> Hash: SHA256
> 
> * Package name: virtiofsd
>   Version : 1.1.0
>   Upstream Author : multiple, Chromium OS, Intel Corp, Red Hat
> * URL : https://gitlab.com/virtio-fs/virtiofsd
> * License : BSD and Apache
>   Programming Lang: Rust
>   Description : vhost-user virtio-fs device backend written in Rust
> 
> Implementation of virtio FS: https://virtio-fs.gitlab.io for fast sharing of
> host filesystem with a VM guest.

I am also interested in this, but
I haven't time to learn the rust-jutsu.

In the meantime the the older C-based virtiofsd in qemu works OK --
I am booting off virtiofs using Debian 11's virt-manager/libvirtd/qemu:

qemu-system-common: /usr/lib/qemu/virtiofsd

https://manpages.debian.org/virtiofsd

https://github.com/qemu/qemu/tree/master/tools/virtiofsd

It is not clear to me what, specifically, upstream has improved in the
virtiofsd-rs codebase -- there isn't a ./NEWS or anything yet.

As at v1.4.0, the ./Cargo.toml lists these dependencies:

[dependencies]
bitflags = "1.2"> in Debian 11
capng = "0.2.2" > not in Debian
env_logger = "0.8.4"> in Debian 12
futures = {
  version = "0.3",  > in Debian 12
  features = ["thread-pool"] }
libc = "~0.2.120"   > in Debian 12
log = "0.4" > in Debian 11
libseccomp-sys = "0.2"  > in Debian 11
structopt = "0.3"   > in Debian 11
vhost-user-backend = "0.5.1"> not in Debian?
vhost = "0.4"   > not in Debian?
virtio-bindings = {
  version = "0.1",  > not in Debian?
  features = ["virtio-v5_0_0"] }
vm-memory = {
  version = ">=0.7",> in Debian Sid
  features = ["backend-mmap", "backend-atomic"] }
virtio-queue = "0.4"> not in Debian?
vmm-sys-util = "0.10"   > not in Debian 
(Sid version too old)
syslog = "6.0"  > in Debian 12

So I guess there's a few dependency libraries that have to be done first.

Bug#1019624: UPSONIC IRT-3K 2U broken by length checking in blazer_usb/nutdrv_qx

[Trent W. Buck]

p.
Using "sudo screen /dev/ttyUSB0" saw the same I/O errors.

UPSonic doesn't have a manual for a IRT-3K product anymore, but
their "ESART" products seem to use the DB-9 port very oddly --
with e.g. a dedicated pin for ON-BATTERY state.


https://www.upsonic.com.au/wp-content/uploads/2022/03/Upsonic-ESART-1kVA-to-3kVA-User-Manual-210322.pdf#page=25

https://www.upsonic.com.au/wp-content/uploads/2022/03/Upsonic-CSCT-Tower-Series-UPS-Upsonic-CSCRT-Rack-Tower-UPS-User-Manual-1000VA-to-3000VA-doc.rev-240322.pdf#page=27

Possibly unpatched nut can talk to my UPS over DB9, but
right now I don't know how.


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

Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
>From f15beb7a3c523e832e4cf63e27eafd9d1ef71a91 Mon Sep 17 00:00:00 2001
From: Laurent Bigonville 
Date: Sun, 10 Jul 2022 09:23:10 +0200
Subject: [PATCH 1/2] debian/watch: Update the URL and add support for RC
 releases

---
 debian/watch | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/watch b/debian/watch
index e228e43..0308379 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,3 @@
-version=3
-https://networkupstools.org/download.html .*/nut-(.*)\.tar\.(?:gz|bz2|xz)
+version=4
+opts="uversionmangle=s/-rc/~rc/" \
+https://networkupstools.org/source/(?:([\d\.]+))/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
-- 
2.34.1

>From b7e417a410f0cf0557d0bb31a63807cbe139c5f5 Mon Sep 17 00:00:00 2001
From: "Trent W. Buck" 
Date: Tue, 13 Sep 2022 08:00:57 +1000
Subject: [PATCH 2/2] fix upsonic irt-3000 2u

---
 debian/changelog  |   6 +
 debian/patches/nut-upsonic-hack.patch | 262 ++
 debian/patches/series |   3 +
 3 files changed, 271 insertions(+)
 create mode 100644 debian/patches/nut-upsonic-hack.patch

diff --git a/debian/changelog b/debian/changelog
index c235416..811dd8a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+nut (2.7.4-13cyber2) UNRELEASED; urgency=medium
+
+  * fix upsonic irt-3000 2u
+
+ -- Trent W. Buck   Tue, 13 Sep 2022 08:19:40 +1000
+
 nut (2.7.4-13) unstable; urgency=medium
 
   [ Arnaud Quette ]
diff --git a/debian/patches/nut-upsonic-hack.patch 
b/debian/patches/nut-upsonic-hack.patch
new file mode 100644
index 000..601b19a
--- /dev/null
+++ b/debian/patches/nut-upsonic-hack.patch
@@ -0,0 +1,262 @@
+Description: 
+ TODO: Put a short summary on the line above and replace this paragraph
+ with a longer explanation of this change. Complete the meta-information
+ with other relevant fields (see below for details). To make it easier, the
+ information below has been extracted from the changelog. Adjust it or drop
+ it.
+ .
+ nut (2.8.0-2cyber1) UNRELEASED; urgency=medium
+ .
+   * Kludge the length checking for UPSONIC IRT-3K 2U.
+Author: Trent W. Buck 
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: , 
+Bug: 
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: 
+Reviewed-By: 
+Last-Update: 2022-09-12
+
+--- a/drivers/Makefile.am
 b/drivers/Makefile.am
+@@ -242,7 +242,7 @@ nutdrv_qx_SOURCES += libusb.c usb-common.c
+ nutdrv_qx_LDADD += $(LIBUSB_LIBS)
+ endif
+ NUTDRV_QX_SUBDRIVERS = nutdrv_qx_bestups.c nutdrv_qx_blazer-common.c  \
+- nutdrv_qx_mecer.c nutdrv_qx_megatec.c nutdrv_qx_megatec-old.c\
++ nutdrv_qx_mecer.c nutdrv_qx_megatec.c nutdrv_qx_upsonic.c 
nutdrv_qx_megatec-old.c\
+  nutdrv_qx_mustek.c nutdrv_qx_q1.c nutdrv_qx_voltronic.c  \
+  nutdrv_qx_voltronic-qs.c nutdrv_qx_voltronic-qs-hex.c nutdrv_qx_zinto.c
+ nutdrv_qx_SOURCES += $(NUTDRV_QX_SUBDRIVERS)
+@@ -263,7 +263,7 @@ dist_noinst_HEADERS = apc-mib.h apc-hid.h baytech-mib.h 
bcmxcp.h   \
+  upshandler.h usb-common.h usbhid-ups.h powercom-hid.h compaq-mib.h 
idowell-hid.h \
+  apcsmart.h apcsmart_tabs.h apcsmart-old.h apcupsd-ups.h cyberpower-mib.h 
riello.h openups-hid.h \
+  delta_ups-mib.h nutdrv_qx.h nutdrv_qx_bestups.h nutdrv_qx_blazer-common.h 
nutdrv_qx_mecer.h  \
+- nutdrv_qx_megatec.h nutdrv_qx_megatec-old.h nutdrv_qx_mustek.h 
nutdrv_qx_q1.h\
++ nutdrv_qx_megatec.h nutdrv_qx_upsonic.h nutdrv_qx_megatec-old.h 
nutdrv_qx_mustek.h nutdrv_qx_q1.h\
+  nutdrv_qx_voltronic.h nutdrv_qx_voltronic-qs.h nutdrv_qx_voltronic-qs-hex.h 
nutdrv_qx_zinto.h 

Bug#1018840: Please consider update-smart-drivedb cron job

[Trent W. Buck]

Package: smartmontools
Version: 7.2-1
Severity: wishlist

Is it reasonable to include a cron job to run update-smart-drivedb regularly?

It can be off-by-default, e.g.
just put it into debian/smartmontools.examples.

Here is the one I've been running on Debian 11 since 2021:

update-smart-drivedb.service:

[Unit]
Description=Update SMART drive database
ConditionPathExists=/usr/sbin/update-smart-drivedb

[Service]
Type=oneshot
ExecStart=update-smart-drivedb

[Unit]
Wants=network-online.target
After=network-online.target

Before=smartmontools.service
[Install]
WantedBy=smartmontools.service

update-smart-drivedb.timer:

[Unit]
ConditionPathExists=/usr/sbin/update-smart-drivedb

[Timer]
OnCalendar=daily
RandomizedDelaySec=24h
Persistent=true

[Install]
WantedBy=timers.target

If these were shipped in examples,
the end user (sysadmin) could enable it like this:

systemctl link \
  /usr/share/doc/smartmontools/examples/update-smart-drivedb.timer \
  /usr/share/doc/smartmontools/examples/update-smart-drivedb.service
systemctl preset --all

Probably OnCalendar=daily is a bit excessive; it could be weekly.

Bug#1008240: Inside mmdebstrap hooks, find /dev/ -type f matches irregular files

[Trent W. Buck]

Andreas Metzler wrote:
> Control: forcemerge 912180 1008240
> 
> FWIW this is a duplicate of 912180.
> AFAIU the upstream bug discussion find uses getdents() and avoids unecessary 
> stats().
> However Linux returns incorrect information.
> The possible performance penalty might be huge.

Thanks for the clarification.

I think the next steps are therefore:

  1. file a bug to against linux (kernel),
 to fix the wrong getdents behaviour.

  2. ensure /usr/share/info/find.info mentions

  * that find on Linux has this incorrect behaviour

  * that it's Linux's fault (linking to #1)

  * that find can't work around it without a significant performance cost

  * if the end user can work around it, how to do so.
e.g. changing "-type f" to "-type f -not -type b -not -type c"

(that example does NOT work)

What do you think?


AFAICT #2 isn't already done upstream, though I may be looking wrong.
https://www.gnu.org/software/findutils/manual/html_mono/find.html
https://git.savannah.gnu.org/cgit/findutils.git/plain/doc/find.texi

AFAICT #1 isn't already done upstream, though I may be looking wrong.
https://docs.kernel.org/admin-guide/reporting-issues.html
https://bugzilla.kernel.org/buglist.cgi?quicksearch=getdents
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux;include=subject%3Agetdents
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux;include=subject%3Afind
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux;include=subject%3Abind

Bug#942288: Wish for tar2squashfs

[Trent W. Buck]

FYI,

squashfs-tools-ng/bullseye has tar2sqfs and I've been using it for ages.
This unprivileged command already uses it internally:

$ mmdebstrap bullseye bullseye.squashfs

Bug#1012828: Please enable busybox sha3sum (SHA3/SHA-3/Keccak)

[Trent W. Buck]

Package: busybox
Version: 1:1.30.1-6+b3
Severity: wishlist
File: /usr/bin/busybox

Is there any reason NOT to enable busybox sha3sums?
(I don't care busybox-udeb or busybox-static.)


https://sources.debian.org/src/busybox/1%3A1.35.0-1/debian/config/pkg/deb/#L280

-# CONFIG_SHA3SUM is not set
+CONFIG_SHA3SUM=y


Per this handy reference table, everyone should be on SHA-3 by now:

https://valerieaurora.org/hash.html


I'd like to switch from b2sum to sha3sum, but

1) Debian only ships coreutils 8.32, and even
   latest coreutils (9.1) lacks "cksum -a sha3"; and

2) Debian's busybox is built without "busybox sha3sum".

3) Debian's python3 understands SHA-3 (hashlib.sha3_512), but
   lacks a turnkey equivalent of
   "sha3sum --check SHA3SUMS" and
   "sha3sum --tag -- *.changes >SHA3SUMS".





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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 busybox depends on:
ii  libc6  2.31-13+deb11u3

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information

Bug#1012680: rmadison --json (push @args, "=json")

[Trent W. Buck]

Package: devscripts
Version: 2.22.1~bpo11+1
Severity: wishlist
File: /usr/bin/rmadison

Please extend the rmadison parser so it can add =json to the URL it fetches.
This avoids people post-processing text to get json out.

01:08  TIL (from twb's comment earlier) "rmadison -u ubuntu" to 
find out package versions from ubuntu
01:09  It's super slow. :-/
01:11  And the output format differs
01:11  REDACTED2: indeed
01:12  so better not shell-parse that
01:13  the output here only seems to differ by a leading space 
in front of the package name
01:14  yes
01:19  rmadison $pkg | sed 's/  \+/ /g' | jc --csv   goes a long 
way to parsing the output though :)
01:19  TIL: jc
01:20  TIL there's no python-is-python2 in Ubuntu 22.04.
01:27  For me, "jc --csv" produces garbage on rmadison output.
01:30  Like... it assumes that the first line is a header, and 
uses "6" (?!) as the column separator.
01:30  oh hmm here (sid) it recognized the | as the separating 
character.  but I saw after posting that command that one would need to add a 
columns title line with echo for the json objects to make sense
01:31  anyway .. like you were saying, it's not super trivial to 
parse.
02:18  REDACTED1: I think this is probably easier: 
https://api.ftp-master.debian.org/madison?package=mg=json
02:19  The args rmadison passes are all single-letter codes, 
file:///usr/bin/rmadison#lines=197-209

Example output:

$ curl -s 
'https://api.ftp-master.debian.org/madison?package=mg=json=source=testing'
 | jq .
[
  {
"mg": {
  "testing": {
"20210609-1": {
  "component": "main",
  "architectures": [
"source"
  ],
  "source": "mg",
  "source_version": "20210609-1"
}
  }
}
  }
]

Note that this does NOT work for Ubuntu.

$ curl 
https://people.canonical.com/~ubuntu-archive/madison.cgi?package=mg\=json
dak ls aka madison
⋮
dak ls mg
 mg | 20110905-1.1 | trusty/universe  | source, amd64, arm64, armhf, i386, 
powerpc, ppc64el
 mg | 20160118-2   | xenial/universe  | source, amd64, arm64, armhf, i386, 
powerpc, ppc64el, s390x
 mg | 20171014-1   | bionic/universe  | source, amd64, arm64, armhf, i386, 
ppc64el, s390x
 mg | 20180927-1   | focal/universe   | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x
 mg | 20200723-1   | impish/universe  | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x
 mg | 20200723-1   | jammy/universe   | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x
 mg | 20210609-1   | kinetic/universe | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x
⋮
Usage: dak ls [OPTION] PACKAGE[...]
Display information about PACKAGE(s).

  -a, --architecture=ARCHonly show info for ARCH(s)
  -c, --component=COMPONENT  only show info for COMPONENT(s)
  -h, --help show this help and exit
  -r, --regextreat PACKAGE as a regex [not supported in 
madison.cgi]
  -s, --suite=SUITE  only show info for this suite
  -S, --source-and-binaryshow info for the binary children of source 
pkgs

ARCH, COMPONENT and SUITE can be comma (or space) separated lists, e.g.
--architecture=m68k,i386
⋮

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
BTS_CACHE=no
DEBCHANGE_RELEASE_HEURISTIC=changelog
DEB_BUILD_HARDENING=1
DEB_BUILD_OPTIONS=parallel=$(getconf _NPROCESSORS_ONLN || echo 1)

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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 devscripts depends on:
ii  dpkg-dev  1.20.10
ii  fakeroot  1.25.3-1.1
ii  file  1:5.39-3
ii  gnupg 2.2.27-2+deb11u1
ii  gpgv  2.2.27-2+deb11u1
ii  libc6 2.31-13+deb11u3
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.11-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004004-1
ii  libwww-perl   6.52-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-4+deb11u2
ii  python3   3.9.2-3
ii  sensible-utils0.0.14
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.2.4
ii  curl7.74.0-1.3+deb11u1
ii  dctrl-tools 

Bug#1010066: prayer: Depends on private functions that are hidden with tidy 5.8

[Trent W. Buck]

Boyuan Yang wrote:
> Source: prayer
> Version: 1.3.5-dfsg1-8
> Severity: grave
> X-Debbugs-CC: holmg...@debian.org
> User: tidy-ht...@packages.debian.org
> Usertags: tidy5.8
> 
> your package uses some of Tidy's unexported internal
> functions that are explicitly hidden in Tidy 5.8 [...]
> I believe this change is intentional by upstream, and will not be changed in
> the forseeable future. Please consider fixing the build by removing the use of
> internal Tidy functions. Thanks!

Hi, I am a nosy bystander.

I eyeballed these two references:


https://sources.debian.org/src/prayer/1.3.5-dfsg1-8/session/html_secure_tidy.c/#L274-L334

https://api.html-tidy.org/tidy/tidylib_api_5.8.0/group__parser__h.html#ga46769d54f0a1bcfd801d60c34eb563e7

Is it sufficient to simply change "prvTidyDiscardElement to "TY_DiscardElement"?

The TY_DiscardElement docs say "TY_Private".
Does that mean "you're not allowed to call this, either"?

If so, we can build prayer without tidy at all.
Prayer will then use an older in-house HTML sanitizer:

https://sources.debian.org/src/prayer/1.3.5-dfsg1-8/Config/?hl=16#L16

https://sources.debian.org/src/prayer/1.3.5-dfsg1-8/session/Makefile/#L27-L35

The whole purpose of html_secure*.c is to "safely" embed an attacker's
untrusted HTML (the email) inside trusted HTML (the webmail app).
The code predates things like Content-Security-Policy (added circa 2013),
so it's probably *NEVER* safe, regardless of whether tidy is or isn't used.

Prayer is abandoned upstream since the 201x's.
I can't find a direct citation, but here's the last time the "homepage" existed:


https://web.archive.org/web/20161129034822/http://www-uxsup.csx.cam.ac.uk:80/~dpc22/prayer/

https://web.archive.org/web/20130701184507/http://www-uxsup.csx.cam.ac.uk/%7Edpc22/

Bug#1010741: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc4 in position 136: invalid continuation byte

[Trent W. Buck]

Package: dopewars
Version: 1.5.12-19
Severity: normal

Python's configparser cannot parse /usr/share/applications/dopewars.desktop.
This is because that file is using ISO 8859-1 when it should be using UTF-8.
Please fix the encoding of the .desktop file.


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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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

Bug#1006753: dkms modules not rebuilt on kernel upgrades with unattended upgrades

[Trent W. Buck]

Trent W. Buck wrote:
> I can reproduce this issue.
> It has bitten me 3 or 4 times.
> I think happens every time the ABI bumps (5.10-n → 5.10-n+1).
> 
> For me, the timeline is this:
> 
>   1. unattended-upgrades installs new kernel
>   2. kernel postinst builds new initrd
>   3. unattended-upgrades installs new headers
>   4. kernel postinst new zfs.ko

PS: from unattended-upgrades-dpkg.log, I'm pretty sure the problem is "above" 
dpkg, but
I'm not clear if it's in unattended-upgrades or in apt.

If it's happening in the apt layer,
I guess that is because linux-image-N-amd64 does not Depends on 
linux-headers-N-amd64.
So apt thinks it can do 2 separate dpkg runs, and (sometimes?) in the wrong 
order?

If that's what happens, it's unreasonable to add stronger dependencies, 
because
then EVERYONE will be forced to install headers.

Is it reasonable for unattended-upgrades to have a special-case safety net 
for this?
Something like

 If unattended-upgradse is upgrading a kernel AND a headers,
 then ensure headers installs first.

Bug#1006753: dkms modules not rebuilt on kernel upgrades with unattended upgrades

[Trent W. Buck]

I can reproduce this issue.
It has bitten me 3 or 4 times.
I think happens every time the ABI bumps (5.10-n → 5.10-n+1).

For me, the timeline is this:

  1. unattended-upgrades installs new kernel
  2. kernel postinst builds new initrd
  3. unattended-upgrades installs new headers
  4. kernel postinst new zfs.ko

Because #2 happens before #4, I get an initrd that says

Failed to load ZFS modules.
Manually load the modules and exit.

⋮

(initramfs)

Attached are the detailed logs.

Note that unattended-upgrades runs once, but dpkg appears to run twice.
This might explain why triggers are run in the wrong order?


Please note that

  • linux-headers-amd64 is installed.
This is not simply "unattended-upgrades doesn't upgrade the header package"

  • No backport kernels are involved.
This is not simply "unattended-upgrades is a bit weird for bpo kernels"
adduser 3.118
alsa-topology-conf  1.2.4-1
alsa-ucm-conf   1.2.4-2
amd64-microcode 3.20191218.1
ansible 2.10.7+merged+base+2.10.8+dfsg-1
apparmor2.13.6-10
apt 2.2.4
apt-listbugs0.1.35
apt-listchanges 3.24
apt-utils   2.2.4
aptitude0.8.13-3
aptitude-common 0.8.13-3
augeas-lenses   1.12.0-2
base-files  11.1+deb11u3
base-passwd 3.5.51
bash5.1-2+b3
bash-completion 1:2.11-2
binutils2.35.2-2
binutils-common:amd64   2.35.2-2
binutils-x86-64-linux-gnu   2.35.2-2
bolt0.9.1-1
bsd-mailx   8.1.2-0.20180807cvs-2
bsdextrautils   2.36.1-8+deb11u1
bsdmainutils12.1.7+nmu3
bsdutils1:2.36.1-8+deb11u1
build-essential 12.9
busybox 1:1.30.1-6+b3
bzip2   1.0.8-4
ca-certificates 20210119
calendar12.1.7+nmu3
collectd-core   5.12.0-7
collectd-utils  5.12.0-7
console-setup   1.205
console-setup-linux 1.205
coreutils   8.32-4+b1
cpio2.13+dfsg-4
cpp 4:10.2.1-1
cpp-10  10.2.1-6
cryptsetup  2:2.3.7-1+deb11u1
cryptsetup-bin  2:2.3.7-1+deb11u1
cryptsetup-initramfs2:2.3.7-1+deb11u1
cryptsetup-run  2:2.3.7-1+deb11u1
curl7.74.0-1.3+deb11u1
cyber-zfs-backup0.3
dash0.5.11+git20200708+dd9ef66-5
dbus1.12.20-2
dbus-user-session   1.12.20-2
dctrl-tools 2.24-3+b1
debconf 1.5.77
debconf-i18n1.5.77
debian-archive-keyring  2021.1.1
debian-security-support 1:11+2021.03.19
debianutils 4.11.2
debsums 3.0.2
dictionaries-common 1.28.4
diffutils   1:3.7-5
dirmngr 2.2.27-2+deb11u1
distro-info-data0.51+deb11u1
dkms2.8.4-3
dmidecode   3.3-2
dmsetup 2:1.02.175-2.1
dosfstools  4.2-1
dpkg1.20.9
dpkg-dev1.20.9
dropbear-bin2020.81-3
dropbear-initramfs  2020.81-3
e2fsprogs   1.46.2-2
efibootmgr  17-1
eject   2.36.1-8+deb11u1
emacs   1:27.1+1-3.1
emacs-bin-common1:27.1+1-3.1
emacs-common1:27.1+1-3.1
emacs-el1:27.1+1-3.1
emacs-nox   1:27.1+1-3.1
emacsen-common  3.0.4
etckeeper   1.18.16-1
exfat-fuse  1.3.0-2
exfat-utils 1.3.0-2
fakeroot1.25.3-1.1
fdisk   2.36.1-8+deb11u1
file1:5.39-3
findutils   4.8.0-1
firmware-amd-graphics   20210315-3
firmware-linux  20210315-3
firmware-linux-free 20200122-1
firmware-linux-nonfree  20210315-3
firmware-misc-nonfree   20210315-3
firmware-realtek20210315-3
fontconfig  2.13.1-4.2
fontconfig-config   2.13.1-4.2
fonts-dejavu-core   2.37-2
fonts-lato  2.0-2.1
fuse2.9.9-5
fwupd   1.5.7-4
fwupd-amd64-signed  1.5.7+4
g++ 4:10.2.1-1
g++-10  10.2.1-6
gcc 4:10.2.1-1
gcc-10  10.2.1-6
gcc-10-base:amd64   10.2.1-6
gcc-9-base:amd649.3.0-22
gdisk   1.0.6-1.1
gettext-base0.21-4
gir1.2-glib-2.0:amd64   1.66.1-1+b1
git 1:2.30.2-1
git-man 1:2.30.2-1
gnupg   2.2.27-2+deb11u1
gnupg-l10n  2.2.27-2+deb11u1
gnupg-utils 2.2.27-2+deb11u1
gpg 2.2.27-2+deb11u1
gpg-agent   2.2.27-2+deb11u1
gpg-wks-client  2.2.27-2+deb11u1
gpg-wks-server  2.2.27-2+deb11u1
gpgconf 2.2.27-2+deb11u1
gpgsm   2.2.27-2+deb11u1
gpgv2.2.27-2+deb11u1
grep3.6-1
groff-base  1.22.4-6
gsasl-common1.10.0-4
gzip1.10-4+deb11u1
hdparm  9.60+ds-1
hostname3.23
how-can-i-help  17
htop3.0.5-7
ieee-data   20210605.1
ifupdown0.8.36
init1.60
init-system-helpers 1.60
initramfs-tools 0.140
initramfs-tools-core0.140
install-info6.7.0.dfsg.2-6
intel-microcode 3.20220207.1~deb11u1
iproute25.10.0-4
iputils-ping3:20210202-1
isc-dhcp-client 4.4.1-2.3
isc-dhcp-common 4.4.1-2.3
iucode-tool 2.3.1-1
javascript-common   11+nmu1
kbd 2.3.0-3
keyboard-configuration  1.205
klibc-utils 2.0.8-6.1
kmod28-1
knot-dnsutils   3.0.5-1
knot-host   3.0.5-1
ldnsutils   1.7.1-2+b1
less551-2
libacl1:amd64   2.2.53-10
libapparmor1:amd64  2.13.6-10
libapt-pkg6.0:amd64 2.2.4
libarchive13:amd64  3.4.3-2+deb11u1
libargon2-1:amd64   0~20171227-0.2
libasan6:amd64  10.2.1-6
libasound2:amd641.2.4-1.1
libasound2-data 1.2.4-1.1
libassuan0:amd642.5.3-7.1
libatasmart4:amd64  0.19-5
libatomic1:amd64

Bug#1009850: Hide .desktop menu item in X-only desktops (e.g. XFCE4)?

[Trent W. Buck]

Package: foot
Version: 1.6.4-1
Severity: wishlist

XFCE 4.16 (Debian 11) doesn't support Wayland apps.
However, foot still appears in its menu.
When clicking the menu, there is no user-visible impact of an error.
This appears in .xsession-errors:

info: main.c:356: version: 1.6.4 +ime
info: main.c:363: arch: x86_64/64-bit
info: main.c:367: locale: en_AU.UTF-8
 err: config.c:2109: no configuration found, using defaults
 err: wayland.c:: failed to connect to wayland; no compositor running?
info: main.c:523: goodbye


Can you make the menu item only appear where it will work (e.g. 
whitelist/blacklist named desktop environments)?

Obviously you cannot pop up an X11 error message -- you don't want to implement 
X at all.
However, at least XFCE (usually) accepts XDG notify events.
So you could send a notification message to cause an error popup, e.g.

Wayland environment not found.  Is your desktop X11-only?


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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

Bug#1009848: Please add "Provides: x-terminal-emulator"

[Trent W. Buck]

Package: gnome-console
Version: 42~beta-2
Severity: wishlist

Please add "Provides: x-terminal-emulator" to debian/control, so 
kgx/gnome-console is easier to find.

Bug#1009099: /usr/share/applications/gnome-breakout.desktop uses legacy encoding

[Trent W. Buck]

Package: gnome-breakout
Version: 0.5.3-7
Severity: minor

The gnome-breakout.desktop file is encoded in ISO-8859-1.  It should be UTF-8.
This causes problems when reading the file:

root@desktop:~# python3 -c "import configparser; app = 
configparser.RawConfigParser(); 
app.read('/usr/share/applications/gnome-breakout.desktop')"
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.9/configparser.py", line 697, in read
self._read(fp, filename)
  File "/usr/lib/python3.9/configparser.py", line 1017, in _read
for lineno, line in enumerate(fp, start=1):
  File "/usr/lib/python3.9/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf0 in position 177: 
invalid continuation byte

root@desktop:~# iconv --from iso-8859-1 
/usr/share/applications/gnome-breakout.desktop
[Desktop Entry]
Name=GNOME Breakout
Name[tr]=Gnome Breakout
Name[de]=GNOME Breakout
Comment=Play a clone of the classic arcade game Breakout for GNOME
Comment[tr]=Breakout klasiðinin Gnome teþkili
Comment[de]=Das klassische Arcade Spiel Breakout für GNOME
Exec=gnome-breakout
Icon=gnome-breakout.png
Terminal=false
Type=Application
Categories=Game;ArcadeGame;

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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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

Bug#1008564: Assumes /usr/games/polygen is in $PATH; not true for root

[Trent W. Buck]

Package: cappuccino
Version: 0.5.1-9.1
Severity: minor

Because there is no .desktop file, and my test desktop is built without a 
terminal emulator, I tried running cappuccino as root:

bash$ ssh root@bootstrap2020 'DISPLAY=:0 XAUTHORITY=$(echo 
/var/lib/xdm/authdir/authfiles/*)' cappuccino
Warning: Permanently added '[localhost]:2022' (ED25519) to the list of 
known hosts.
__main__.py:148: PyGIDeprecationWarning: GObject.timeout_add is deprecated; 
use GLib.timeout_add instead
/bin/sh: 1: polygen: not found
__main__.py:72: DeprecationWarning: Gtk.Alignment.set is deprecated
/bin/sh: 1: polygen: not found
__main__.py:84: PyGIDeprecationWarning: GObject.timeout_add is deprecated; 
use GLib.timeout_add instead
__main__.py:85: PyGIDeprecationWarning: GObject.timeout_add is deprecated; 
use GLib.timeout_add instead
/bin/sh: 1: polygen: not found
Traceback (most recent call last):
  File "__main__.py", line 107, in update_log
IndexError: pop from empty list
/bin/sh: 1: polygen: not found

This is happening because /usr/games/polygen is not in the default $PATH unless 
you 1) log in as a non-root user; and 2) pass through PAM session.
In the above case, neither (1) nor (2) happens.
For (2) it does not happen because "ssh host command" bypasses the login shell.

These situations are unlikely to occur, but given the failure
behaviour is pretty weird, I think simply hard-coding the default path
to "/usr/games/polygen" instead of "polygen" would suffice.

The manpage didn't suggest any CLI option to easily work around this.

PS: note that cappuccino itself is NOT installed in /usr/games/.
Moving it there would, I guess, be an equally easy fix.


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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

Bug#1007842: Bug#909124: quilt: Please fail gracefully on 'quilt series' when less(1) is not installed

[Trent W. Buck]

Daniel Shahaf wrote:
> > FAILS:  env PAGER=cat quilt series
> > WORKS:  env -u LESS PAGER=cat quilt series
> > 
> > 
> > This is actually a separate but related bug in quilt.
> > If $LESS is set, quilt ignores $PAGER and forces less.
> > This is wrong.
> ⋮
> > 18:38  [ -n "$LESS" -a -z "${QUILT_PAGER+x}" ] && 
> > QUILT_PAGER="less -FRX"
> 
> Agreed.  If Alice normally uses «export PAGER=less LESS=S» and then sets
> PAGER=foo, that's the pager quilt shoult use.
> 
> Cloned as -2.  The above patch does _not_ fix it.
> 
> > If quilt wants to override the user's requested $LESS,
> > it should do so with "export LESS=FRX",
> > entirely independent of $QUILT_PAGER'.
> 
> This particular approach would be lossy: it would overwrite the user's
> value of $LESS.  Instead, quilt could _append_ to $LESS, or pass -R into
> less(1)'s argv, or only use $LESS as a hint if PAGER and GIT_PAGER are
> also unset and less(1) is installed, or document that the user should
> configure their $PAGER / $LESS / $QUILT_PAGER envvars with -R, or…

OK that sounds reasonable.
The part I care about is "don't force PAGER=less when LESS=x".
I don't really care about the EXACT way that is achieved.

All else being equal, I think quilt should mimic git's equivalent logic.
I guess that's here:


https://sources.debian.org/src/git/1:2.35.1-1/Documentation/config/core.txt/?hl=508#L496-L519

Bug#1008240: Inside mmdebstrap hooks, find /dev/ -type f matches irregular files

[Trent W. Buck]

Package: mmdebstrap
Version: 0.7.5-2.2
Severity: minor

I see a quite odd behaviour where "find ... -type f" inside a customize hook is 
matching device files.
As a simple test, "find /dev -type f" finds /dev/zero inside mmdebstrap, but 
not outside mmdebstrap.

The problem doesn't appear to be affecting stat, test, or python -- only find.
I haven't tested with bwrap or unshare(1) instead of mmdebstrap – I'm not sure 
exactly how.
If find fails for those, clearly this bug should be reassigned to findutils.

I speculate this is some interaction between unshare(2) and stat(2) that may be 
a bug in find.
I looked at the strace, but I can't see anything obvious.

Here is some basic investigation outside mmdebstrap:

bash5$ find /dev/ -type f
[no matches]

bash5$ strace -e trace=file find /dev/zero -type f -print -quit
execve("/usr/bin/find", ["find", "/dev/zero", "-type", "f", "-print", 
"-quit"], 0x7ffc1e9c8578 /* 72 vars */) = 0
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libselinux.so.1", 
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", 
O_RDONLY|O_CLOEXEC) = 3
statfs("/sys/fs/selinux", 0x7ffd464f5210) = -1 ENOENT (No such file or 
directory)
statfs("/selinux", 0x7ffd464f5210)  = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3
access("/etc/selinux/config", F_OK) = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, ".", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/usr/share/locale/en_AU.UTF-8/LC_MESSAGES/findutils.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_AU.utf8/LC_MESSAGES/findutils.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_AU/LC_MESSAGES/findutils.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/findutils.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/findutils.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/findutils.mo", O_RDONLY) 
= -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/dev/zero", {st_mode=S_IFCHR|0666, 
st_rdev=makedev(0x1, 0x5), ...}, AT_SYMLINK_NOFOLLOW) = 0
+++ exited with 0 +++

Here is some basic investigation inside mmdebstrap:

bash5$ mmdebstrap bullseye /dev/null --customize-hook='chroot $1 bash; 
false' --include=strace,findutils
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.PqOlBcBbIw as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
done
I: running --customize-hook in shell: sh -c 'chroot $1 bash; false' exec 
/tmp/mmdebstrap.PqOlBcBbIw

root@hera:/# find /dev/ -type f
/dev/zero
/dev/urandom
/dev/tty
/dev/random
/dev/ptmx
/dev/null
/dev/full
/dev/console

root@hera:/# strace -e trace=file find /dev/zero -type f -print -quit
execve("/usr/bin/find", ["find", "/dev/zero", "-type", "f", "-print", 
"-quit"], 0x7fff5a33ba68 /* 79 vars */) = 0
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libselinux.so.1", 
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0", 
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", 
O_RDONLY|O_CLOEXEC) = 3
statfs("/sys/fs/selinux", 0x7ffe4aac8df0) = -1 ENOENT (No such file or 
directory)
statfs("/selinux", 0x7ffe4aac8df0)  = -1 ENOENT (No such 

Bug#909124: quilt: Please fail gracefully on 'quilt series' when less(1) is not installed

[Trent W. Buck]

Trent W. Buck wrote:
> I ran into the same bug, except PAGER=cat also fails.
> 
> I also tried fixing ${x-fallback} to the more normal ${x:-fallback}, but it 
> did not help.
> 
> I do not understand why that is happening.
> 
> root@hera:/gdk-pixbuf# quilt series
> /usr/share/quilt/scripts/patchfns: line 1128: less: command not found
> 
> root@hera:/gdk-pixbuf# PAGER=cat quilt series
> /usr/share/quilt/scripts/patchfns: line 1128: less: command not found

I have some more info.

FAILS:  env PAGER=cat quilt series
WORKS:  env -u LESS PAGER=cat quilt series


This is actually a separate but related bug in quilt.
If $LESS is set, quilt ignores $PAGER and forces less.
This is wrong.
If quilt wants to override the user's requested $LESS,
it should do so with "export LESS=FRX",
entirely independent of $QUILT_PAGER'.


18:32  And for comparison, "PAGER=cat git diff" *is* working for git in 
the same environment.
18:32  I wonder if quilt is getting confused because $HOME doesn't exist?
18:33  Nope.  But "env -i PAGER=cat quilt series" behaves
18:34  Bizarre...
18:36  Get Fucked.
18:36  env -u LESS fixes it
18:36  But why?
18:37  because quilt is broken I guess
18:37  $LESS should be read by less(1), not by quilt(1)
18:38  [ -n "$LESS" -a -z "${QUILT_PAGER+x}" ] && QUILT_PAGER="less 
-FRX"
18:38  Ugh.
18:39  "env" didn't show anything, because it wasn't exported. We 
should have used "set" instead.

Bug#909124: quilt: Please fail gracefully on 'quilt series' when less(1) is not installed

[Trent W. Buck]

I ran into the same bug, except PAGER=cat also fails.

I also tried fixing ${x-fallback} to the more normal ${x:-fallback}, but it did 
not help.

I do not understand why that is happening.

root@hera:/gdk-pixbuf# quilt series
/usr/share/quilt/scripts/patchfns: line 1128: less: command not found

root@hera:/gdk-pixbuf# PAGER=cat quilt series
/usr/share/quilt/scripts/patchfns: line 1128: less: command not found

root@hera:/gdk-pixbuf# env | grep PAGER
PAGER=cat

root@hera:/gdk-pixbuf# emacs /usr/share/quilt/scripts/patchfns +1128
root@hera:/gdk-pixbuf# git diff --no-index 
/usr/share/quilt/scripts/patchfns.~1~ /usr/share/quilt/scripts/patchfns
diff --git a/usr/share/quilt/scripts/patchfns.~1~ 
b/usr/share/quilt/scripts/patchfns
index 4a36335d..a7e6e54d 100644
--- a/usr/share/quilt/scripts/patchfns.~1~
+++ b/usr/share/quilt/scripts/patchfns
@@ -,7 +,7 @@ setup_pager()

# QUILT_PAGER = QUILT_PAGER | GIT_PAGER | PAGER | less -R
# NOTE: QUILT_PAGER='' is significant
-   QUILT_PAGER=${QUILT_PAGER-${GIT_PAGER-${PAGER-less -R}}}
+   QUILT_PAGER=${QUILT_PAGER:-${GIT_PAGER:-${PAGER:-less -R}}}

[ -z "$QUILT_PAGER" -o "$QUILT_PAGER" = "cat" ]  && return 0

root@hera:/gdk-pixbuf# PAGER=cat quilt series
/usr/share/quilt/scripts/patchfns: line 1128: less: command not found

Bug#1006403: Does not understand pxelinux.cfg INITRD declaration

[Trent W. Buck]

Package: pxe-kexec
Version: 0.2.4-3+b5
Severity: minor

This config file works in pxelinux but not pxe-kexec:

root@tvserver:~# busybox tftp -g -r /pxelinux.cfg/default 10.128.2.2
/pxelinux.cfg/defaul 100% ||   223  0:00:00 
ETA
root@tvserver:~# cat default
DEFAULT linux
LABEL linux
  IPAPPEND 2
  KERNEL vmlinuz
  INITRD initrd.img
  APPEND boot=live netboot=cifs nfsopts=ro,guest,vers=3.1.1 
nfsroot=//10.128.2.4/qemu live-media-path= earlyprintk=ttyS0 console=ttyS0 
loglevel=1

root@tvserver:~# pxe-kexec --debug -nLl linux 10.128.2.2
⋮
DEBUG: Writing 1*512=512 bytes (1)
DEBUG: Writing 1*512=512 bytes (1)
DEBUG: Writing 1*512=512 bytes (1)
DEBUG: Writing 1*32=32 bytes (1)

DEBUG: Executing kexec '-l' '/tmp/pxe-kexec-kernel' '--initrd=' 
'--append=boot=live netboot=cifs nfsopts=ro,guest,vers=3.1.1 
nfsroot=//10.128.2.4/qemu live-media-path= early
Cannot open `': No such file or directory
Loading kernel failed.

This is happening because pxe-kexec only supports the older notation "APPEND 
initrd=xxx ...".
Please fix pxe-kexec so it is compatible with pxelinux 6, which is used in 
Debian 9/10/11/12.

https://wiki.syslinux.org/wiki/index.php?title=SYSLINUX#INITRD_initrd_file

In the meantime, using "APPEND initrd=..." seems to be a viable workaround.
This works in both pxelinux and pxe-kexec:

root@tvserver:~# busybox tftp -g -r /pxelinux.cfg/default 10.128.2.2
/pxelinux.cfg/defaul 100% ||   221  0:00:00 
ETA
root@tvserver:~# cat default
DEFAULT linux
LABEL linux
  IPAPPEND 2
  KERNEL vmlinuz
  APPEND initrd=initrd.img boot=live netboot=cifs 
nfsopts=ro,guest,vers=3.1.1 nfsroot=//10.128.2.4/qemu live-media-path= 
earlyprintk=ttyS0 console=ttyS0 loglevel=1
root@tvserver:~# pxe-kexec -nLl linux 10.128.2.2
Downloading kernel 
Downloading initrd ...
Kernel loaded
root@tvserver:~# systemctl kexec
[...]
Invalid physical address chosen!
Physical KASLR disabled: no suitable memory region!
[...]

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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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

Bug#1006267: Recommends (not Depends) xdg-desktop-portal-*? (don't require fuse/bwrap)

[Trent W. Buck]

Package: chromium
Version: 98.0.4758.102-1~deb11u1
Severity: normal

(This was initially sent to 1005...@bugs.debian.org;
dilinger convinced me this should be a new ticket.)

Hi, I ship chromium in prisons, where we extremely do not want
unprivileged users to be able to add new drivers (fuse) and
applications (flatpak/bubblewrap/xdg-desktop-portal). [*]

https://bugs.debian.org/1005230 and
https://bugs.debian.org/1005410 were recently fixed by adding
Depends: xdg-desktop-portal-gtk | xdg-desktop-portal-backend
which means chromium now hard-depends on fuse and bubblewrap.

 1. xdg-desktop-portal-* is not needed for XFCE and sway users.

As an experiment, I tried

   dpkg --force-depends --purge \
   xdg-desktop-portal \
   xdg-desktop-portal-backend \
   xdg-desktop-portal-gtk \
   fuse libfuse2 \
   fuse3 libfuse3-3 \
   bubblewrap flatpak \
   libgnome-desktop-3-19

And after doing so, I rebooted, logged into a GUI as a new user,
started chromium, successfully browsed to https://example.com/, and
successfully used File Open and File Save dialogues (the were GTK3-style).

I tested this with Debian 11 / Xorg / XFCE.
I tested this with Debian 11 / sway / Xwayland.

In both cases, everything worked,
i.e. the desktop portal is (presumably) not needed.

I'm not sure why other people seem to need xdg-desktop-portal-*.
My only guess is that I was testing in a qemu VM, and
maybe chromium silently disables sandboxing when it detects a VM???

I briefly tried to test task-gnome-desktop, but
gdm3 didn't auto-start, so I gave up.

I didn't test KDE, LXDE, Cinnamon, Mate, wlroots, or plain X (no DE/WM at 
all).

Boring details (turnkey test script ) are in my earlier emails here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005230#25


 2. I have a viable workaround, which
is just to make a fake xdg-desktop-portal package.
This is not really interesting to anyone else, but
I attach it for completeness.


>From MY perspective, the "easy" answer is to just downgrade Depends to 
>Recommends.

However this will re-break chromium for people who have neither gtk*
nor xdg-desktop-portal* installed (i.e. #1005230).

dilinger suggested something like the below.
Getting this just right will require some Deep Thinks.
I don't understand chromium internals enough to do that myself :-(

Depends: libgtk-4-1 |
 libgtk-3-0 |
 xdg-desktop-portal-gtk |
 xdg-desktop-portal-backend


[*] I have a bunch of other layers to block these, but
"libfuse* isn't even installed" is really nice layer to have.
e.g. detainee kernels have CONFIG_FUSE_FS disabled
(though CONFIG_USER_NS is enabled due to systemd).
Format: 3.0 (native)
Source: xdg-desktop-portal-ersatz
Binary: xdg-desktop-portal-ersatz
Architecture: all
Version: 11.0
Maintainer: Trent W. Buck 
Uploaders: Trent W. Buck 
Standards-Version: 4.3.0
Build-Depends: debhelper-compat (= 13)
Package-List:
 xdg-desktop-portal-ersatz deb metapackages optional arch=all
Checksums-Sha1:
 00944a5479997e1b0bf1ee953b263e7c6eb2ada4 2008 
xdg-desktop-portal-ersatz_11.0.tar.xz
Checksums-Sha256:
 c682a6987abb0b0c6c8a9d125a544f7300d3ac114501ec44723cf9351de00e2d 2008 
xdg-desktop-portal-ersatz_11.0.tar.xz
Files:
 6b2741ba9134a28c6e35ae8d317f7565 2008 xdg-desktop-portal-ersatz_11.0.tar.xz


xdg-desktop-portal-ersatz_11.0.tar.xz
Description: application/xz


xdg-desktop-portal-ersatz_11.0_all.deb
Description: application/vnd.debian.binary-package
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: info: source package xdg-desktop-portal-ersatz
dpkg-buildpackage: info: source version 11.0
dpkg-buildpackage: info: source distribution bullseye
dpkg-buildpackage: info: source changed by Trent W. Buck 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (native)'
dpkg-source: info: building xdg-desktop-portal-ersatz in 
xdg-desktop-portal-ersatz_11.0.tar.xz
dpkg-source: info: building xdg-desktop-portal-ersatz in 
xdg-desktop-portal-ersatz_11.0.dsc
 debian/rules binary
dh binary
   create-stamp debian/debhelper-build-stamp
dpkg-deb: building package 'xdg-desktop-portal-ersatz' in 
'../xdg-desktop-portal-ersatz_11.0_all.deb'.
 dpkg-genbuildinfo
 dpkg-genchanges  >../xdg-desktop-portal-ersatz_11.0_amd64.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build .
dpkg-buildpackage: info: full upload; Debian-native package (full source is 
included)
Now running lintian xdg-desktop-portal-ersatz_11.0_amd64.changes ...
warning: running with root privileges is not recommended!
W: xdg-desktop-portal-ersatz: debian-changelog-line-too-long line 4
W: xdg-desktop-portal-ersatz: debian-changelog-line-too-long line 7
W: xdg-desktop-portal-ersatz: extended-desc

Bug#1005230: Does chromium REALLY need fuse now?

[Trent W. Buck]

Trent W. Buck wrote:
> As at chromium 98.0.4758.102-1~deb11u1,
> chromium works with xdg-desktop-portal, fuse, flatpak removed.

As at chromium 98.0.4758.102-1~deb11u1,
I can reproduce the original "Trace/breakpoint trap" in sway,
without removing anything.

i.e. I don't think xdg-desktop-portal helped fix the original problem.

Test script attached.
#!/usr/bin/python3
import subprocess
import tempfile

__doc__ = """ test chrome w/o fuse

log in as "x",
run "LANG=C.UTF-8 sway",
type Alt+Return to open foot,
run chromium,
browse to https://example.museum/, Ctrl+S Enter to save.
See that saving works even with xdg-desktop-portal/flatpak/fuse removed.

NOTE: kvm's default geometry is 800x600 or something.
  GTK3's default save dialog does not fit.
  Try resizing the KVM window before lightdm starts.
"""

with tempfile.TemporaryDirectory() as td:
subprocess.check_call(
['mmdebstrap',
 '--include=linux-image-generic,live-boot,chromium,sway,sway-backgrounds,swaybg,foot',
 f'--aptopt=Acquire::http::Proxy "http://localhost:3142;',
 '--customize-hook=chroot $1 adduser x --gecos x --disabled-password --quiet',
 '--customize-hook=chroot $1 adduser x sudo',
 '--customize-hook=echo x: | chroot $1 chpasswd --crypt-method=NONE',
 '--customize-hook=download vmlinuz vmlinuz',
 '--customize-hook=download initrd.img initrd.img',

 # I can't easily type Penguin key into a VM.
 # So switch it to Alt.
 '--customize-hook=chroot $1 sed -rsi s/Mod4/Mod1/ /etc/sway/config',

 # Remove things that chromium claims it needs but does not actually need.
 # '--customize-hook=chroot $1 dpkg --force-depends --purge xdg-desktop-portal xdg-desktop-portal-backend xdg-desktop-portal-gtk',
 # '--customize-hook=chroot $1 dpkg --force-depends --purge fuse libfuse2 fuse3 libfuse3-3',
 # '--customize-hook=chroot $1 dpkg --force-depends --purge bubblewrap flatpak',
 # '--customize-hook=chroot $1 dpkg --force-depends --purge libgnome-desktop-3-19',

 # Report which version of chromium we are running.
 '--customize-hook=chroot $1 dpkg-query -W chromium',
 'bullseye',
 'filesystem.squashfs'],
cwd=td)
subprocess.check_call(
['kvm',
 '-m', '2G',
 '--device', 'virtio-vga',
 '--kernel', 'vmlinuz',
 '--initrd', 'initrd.img',
 '--append', 'boot=live plainroot root=/dev/vda quiet',
 '--drive', f'file=filesystem.squashfs,format=raw,media=disk,if=virtio,readonly=on'],
cwd=td)

Bug#1005230: Does chromium REALLY need fuse now?

[Trent W. Buck]

Trent W. Buck wrote:
> The error report for #1005230 only specifically mentioned GTK3.
> Are these other "portal" dependencies *really* needed now?

As at chromium 98.0.4758.102-1~deb11u1,
chromium works with xdg-desktop-portal, fuse, flatpak removed.

A minimal test script is attached.
it builds & boots a Debian 11 Live VM without chromium.
You can then launch chromium,
browse to https://example.com, Ctrl+S save and Ctrl+O open.

I'm not sure what other tests are needed.
Can I do anything else to help with this ticket?
#!/usr/bin/python3
import subprocess
import tempfile

__doc__ = """ test chrome w/o fuse

log in as "x", run chromium, browse to https://example.museum/, Ctrl+S Enter to save.
See that saving works even with xdg-desktop-portal/flatpak/fuse removed.

NOTE: kvm's default geometry is 800x600 or something.
  GTK3's default save dialog does not fit.
  Try resizing the KVM window before lightdm starts.
"""

with tempfile.TemporaryDirectory() as td:
subprocess.check_call(
['mmdebstrap',
 '--include=linux-image-generic,live-boot,chromium,task-xfce-desktop,sudo',
 # f'--aptopt=Acquire::http::Proxy "http://localhost:3142;',
 '--customize-hook=chroot $1 adduser x --gecos x --disabled-password --quiet',
 '--customize-hook=chroot $1 adduser x sudo',
 '--customize-hook=echo x: | chroot $1 chpasswd --crypt-method=NONE',
 '--customize-hook=download vmlinuz vmlinuz',
 '--customize-hook=download initrd.img initrd.img',

 # Remove things that chromium claims it needs but does not actually need.
 '--customize-hook=chroot $1 dpkg --force-depends --purge xdg-desktop-portal xdg-desktop-portal-backend xdg-desktop-portal-gtk fuse libfuse2 fuse3 libfuse3-3 bubblewrap flatpak libgnome-desktop-3-19',

 # Report which version of chromium we are running.
 '--customize-hook=chroot $1 dpkg-query -W chromium',
 'bullseye',
 'filesystem.squashfs'],
cwd=td)
subprocess.check_call(
['kvm',
 '-m', '2G',
 '--device', 'virtio-vga',
 '--kernel', 'vmlinuz',
 '--initrd', 'initrd.img',
 '--append', 'boot=live plainroot root=/dev/vda quiet',
 '--drive', f'file=filesystem.squashfs,format=raw,media=disk,if=virtio,readonly=on'],
cwd=td)
bash5$ python3 POC-chromium-without-fuse.py
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: squashfs
I: using /tmp/mmdebstrap.YvkchFlb0y as tempdir
W: tar2sqfs does not support extended attributes from the 'system' namespace
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
done
done
done
done
I: running --customize-hook in shell: sh -c 'chroot $1 adduser x --gecos x 
--disabled-password --quiet' exec /tmp/mmdebstrap.YvkchFlb0y
I: running --customize-hook in shell: sh -c 'chroot $1 adduser x sudo' exec 
/tmp/mmdebstrap.YvkchFlb0y
Adding user `x' to group `sudo' ...
Adding user x to group sudo
Done.
I: running --customize-hook in shell: sh -c 'echo x: | chroot $1 chpasswd 
--crypt-method=NONE' exec /tmp/mmdebstrap.YvkchFlb0y
I: running special hook: download vmlinuz vmlinuz
I: running special hook: download initrd.img initrd.img
I: running --customize-hook in shell: sh -c 'chroot $1 dpkg --force-depends 
--purge xdg-desktop-portal xdg-desktop-portal-backend xdg-desktop-portal-gtk 
fuse libfuse2 fuse3 libfuse3-3 bubblewrap flatpak libgnome-desktop-3-19' exec 
/tmp/mmdebstrap.YvkchFlb0y
dpkg: warning: ignoring request to remove xdg-desktop-portal-backend which 
isn't installed
dpkg: warning: ignoring request to remove fuse3 which isn't installed
dpkg: warning: ignoring request to remove libfuse3-3 which isn't installed
dpkg: warning: ignoring request to remove flatpak which isn't installed
dpkg: libgnome-desktop-3-19:amd64: dependency problems, but removing anyway as 
you requested:
 xdg-desktop-portal-gtk depends on libgnome-desktop-3-19 (>= 3.17.92).

(Reading database ... 31385 files and directories currently installed.)
Removing libgnome-desktop-3-19:amd64 (3.38.5-3) ...
dpkg: xdg-desktop-portal: dependency problems, but removing anyway as you 
requested:
 xdg-desktop-portal-gtk depends on xdg-desktop-portal (>= 1.7.1).

Removing xdg-desktop-portal (1.8.1-1) ...
dpkg: xdg-desktop-portal-gtk: dependency problems, but removing anyway as you 
requested:
 chromium depends on xdg-desktop-portal-gtk | xdg-desktop-portal-backend; 
however:
  Package xdg-desktop-portal-gtk is to be removed.
  Package xdg-desktop-portal-backend is not installed.
  Package xdg-desktop-portal-gtk which provides xdg-desktop-portal-backend is 
to be removed.
 chromium d

Bug#1005230: Does chromium REALLY need fuse now?

[Trent W. Buck]

Package: chromium
Followup-For: Bug #1005230

Hi, I ship chromium in prisons, where we extremely do not want
unprivileged users to be able to add new drivers (fuse) and
applications (flatpak/bubblewrap/xdg-desktop-portal). [*]

The fix for #1005230 added indirect dependencies on fuse and bubblewrap.

The error report for #1005230 only specifically mentioned GTK3.
Are these other "portal" dependencies *really* needed now?

If they are needed, I can deal with it.
If they aren't needed, is it feasible to define the hard dependencies more 
precisely?
Or downgrade xdg-desktop-portal to a Recommends?

(I repackage a few things in-house like linux and vlc, but
I'm frankly too scared to try that with chromium.)


As a sanity-check, I see that libwebkit2gtk-4.0-37 needs bubblewrap (but not 
fuse), and
firefox-esr needs neither.



[*] I have a bunch of other layers to block these, but
"libfuse* isn't even installed" is really nice layer to have.
e.g. detainee kernels have CONFIG_FUSE_FS disabled
(though CONFIG_USER_NS is enabled due to systemd).


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 chromium-common depends on:
ii  libc6   2.31-13+deb11u2
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.2-1
ii  libxext62:1.3.3-1.1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4.1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
pn  chromium-sandbox   
ii  fonts-liberation   1:1.07.4-11
ii  gnome-shell [notification-daemon]  3.38.6-1~deb11u1
ii  libgl1-mesa-dri20.3.5-1
ii  libu2f-udev1.1.10-3
ii  notification-daemon3.20.0-4
ii  system-config-printer  1.5.14-1
ii  upower 0.99.11-2

Bug#1005857: chmod 700 . && mmdebstrap sid /tmp/tmp.ext2 fails in File::Find

[Trent W. Buck]

Package: mmdebstrap
Version: 0.7.5-2.2
Severity: minor

mmdebstrap's approx_disk_usage calls File::Find find(), which
for some reason cares about the permissions of $PWD.
This is the case even when writing the .ext2 somewhere else.

bash5$ mkdir /tmp/a
bash5$ cd /tmp/a
bash5$ mmdebstrap sid /tmp/b.ext2 --quiet
copying from tar archive -
copying from tar archive -
bash5$ ls -lh /tmp/b.ext2
-rw-r--r-- 1 twb twb 306M 2022-02-16 16:11 /tmp/b.ext2

bash5$ chmod 0700 .
bash5$ pwd
/tmp/a
bash5$ mmdebstrap sid /tmp/b.ext2 --quiet
copying from tar archive -
Can't cd to /tmp/a: Permission denied
Use of uninitialized value $numblocks in chomp at /usr/bin/mmdebstrap line 
5607.
Use of uninitialized value $numblocks in numeric le (<=) at 
/usr/bin/mmdebstrap line 5636.
Use of uninitialized value $numblocks in concatenation (.) or string at 
/usr/bin/mmdebstrap line 5637.
bash5$ ls -lh /tmp/b.ext2
-rw-r--r-- 1 twb twb 0 2022-02-16 16:12 /tmp/b.ext2

It looks like File::Find has a "no_chdir" argument.
Maybe you just need to pass that?


https://sources.debian.org/src/perl/5.34.0-3/ext/File-Find/lib/File/Find.pm/#L282

https://sources.debian.org/src/perl/5.34.0-3/ext/File-Find/lib/File/Find.pm/#L273

I guess this is happening because approx_disk_usage runs inside an unshare(2)'d 
context.
So the other option might be to shuffle things around so it runs with full 
privileged.
But that is probably deeply painful and messy.

I would be happy with just having an earlier error message (i.e. before apt), 
like

if (!$options->{dryrun} && $format eq 'ext2')
if( <$PWD is not at least 0555> )
  die "ext2 output needs world-read/execute permissions on $PWD";


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 mmdebstrap depends on:
ii  apt  2.2.4
ii  perl 5.32.1-4+deb11u2
ii  python3  3.9.2-3

Versions of packages mmdebstrap recommends:
ii  arch-test0.17-1
ii  fakechroot   2.19-3.3
ii  fakeroot 1.25.3-1.1
ii  gpg  2.2.27-2
ii  libdistro-info-perl  1.0
ii  mount2.36.1-8+deb11u1
ii  uidmap   1:4.8.1-1

Versions of packages mmdebstrap suggests:
ii  apt [apt-transport-https]  2.2.4
pn  apt-transport-tor  
pn  apt-utils  
ii  binfmt-support 2.2.1-1
ii  ca-certificates20210119
ii  debootstrap1.0.123
ii  distro-info-data   0.51+deb11u1
ii  dpkg-dev   1.20.9
ii  perl-doc   5.32.1-4+deb11u2
pn  proot  
ii  qemu-user  1:5.2+dfsg-11+deb11u1
ii  qemu-user-static   1:5.2+dfsg-11+deb11u1
ii  squashfs-tools-ng  1.0.4-1

-- no debconf information

Bug#1004293: warn users that src:webkit2gtk and src:khtml are insecure?

[Trent W. Buck]

Moritz Mühlenhoff wrote:
> Am Thu, Jan 27, 2022 at 10:01:34AM +1100 schrieb Trent W. Buck:
> > Alberto Garcia wrote:
> > > Two WebKit ports are actively maintained, available in Debian and have
> > > security support: WPE WebKit and WebKitGTK (the package is called
> > > webkit2gtk for technical / historical reasons).
> > >
> > > Other WebKit ports available in Debian are not covered by security
> > > support. I know there's at least QtWebKit, I don't know if there are
> > > more.
> >
> > OK, so as I asked upthread:
> >
> > Am I misreading the Release Notes?
> >
> > 
> > https://www.debian.org/releases/bullseye/arm64/release-notes/ch-information.en.html#limited-security-support
> >
> > browsers built upon e.g. the webkit and khtml engines^[6] are
> > included in bullseye, but not covered by security support.
> >
> > Are you saying that webkit2gtk is supported, but anything that USES 
> > webkit2gtk is unsupported?
> >
> > If the answer is "yes", then I guess instead of
> > security-support-limited including src:webkitgtk it should include all
> > browsers that USE src:webkitgtk?
> >
> > e.g. epiphany-browser, evolution, yelp, and webkitgtk (due to MiniBrowser).
> >
> > Or all this stuff *is* all fully supported by Debian Security team, then
> > should I instead file a bug against the Release Notes?
>
> Any reverse dependency of webkit2gtk is supported (i.e. applications like
> Epiphany, Evolution etc).
>
> Other browsers which use engines which are similarly named since they
> share a common code history are not supported:
> - qtwebkit (only present up to Buster)
> - qtwebkit-opensource-src
> - qtwebengine-opensource-src
> - webkitgtk (only present up to Stretch)
>
> This e.g. means that the default browser in KDE (Konqueror) is entirely
> unsupported with security updates.
>
> Note this isn't the case for any distro out there, we're just the only one
> transparent about in in their release notes!
>
> E.g. qtwebengine rebases to Chromium releases from time to time, but
> definitely not a pace which is needed and none of this reaches distros
> properly.
>
> I understand this is probably a little confusing, so maybe we should
> instead list specific browsers as examples for webengine related components
> which are supported and which are not.

Definitely I am confused! :-)

As a sysadmin shipping Debian in prisons,
I want an easy way to detect and ban packages (especially browser 
engines/browsers) that are not security-supported.
My initial reading of the Debian 11 release notes was "unless it is EXACTLY 
firefox-esr or chromium, it's not supported".
So for example, I banned zenity because that uses webkit2gtk and that's not 
firefox-esr/chromium.

I care a lot more about having a clear list (or simple heuristic), than
about keeping any specific package in/out of the list.

I *think* my life is simpler if I allow/block entire engines, because
if there's a rule like "qtwebengine is supported as long as it only handles KDE 
help documents"
then I have to fiddle-fart around proving that each app will ONLY use
the engine for KDE help documents and not (for example) knewstuff
content from https://autoconfig.kde.org/ocs/providers.xml (which
Debian hasn't vetted).

Bug#1004713: GenericName= (empty string) is wrong; just remove it

[Trent W. Buck]

Package: torus-trooper
Version: 0.22.dfsg1-12
Severity: minor

Hi, when fiddling with show-generic-names in xfce4-panel,
I noticed Torus Trooper ended up with empty menu label.

I think the line "GenericName=" can and should simply be removed from here:


https://sources.debian.org/src/torus-trooper/0.22.dfsg1-12/debian/torus-trooper.desktop/#L4


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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

Bug#1004293: warn users that src:webkit2gtk and src:khtml are insecure?

[Trent W. Buck]

Alberto Garcia wrote:
> Two WebKit ports are actively maintained, available in Debian and have
> security support: WPE WebKit and WebKitGTK (the package is called
> webkit2gtk for technical / historical reasons).
> 
> Other WebKit ports available in Debian are not covered by security
> support. I know there's at least QtWebKit, I don't know if there are
> more.

OK, so as I asked upthread:

Am I misreading the Release Notes?


https://www.debian.org/releases/bullseye/arm64/release-notes/ch-information.en.html#limited-security-support

browsers built upon e.g. the webkit and khtml engines^[6] are
included in bullseye, but not covered by security support.

Are you saying that webkit2gtk is supported, but anything that USES 
webkit2gtk is unsupported?

If the answer is "yes", then I guess instead of
security-support-limited including src:webkitgtk it should include all
browsers that USE src:webkitgtk?

e.g. epiphany-browser, evolution, yelp, and webkitgtk (due to MiniBrowser).

Or all this stuff *is* all fully supported by Debian Security team, then
should I instead file a bug against the Release Notes?

Bug#1004293: warn users that src:webkit2gtk and src:khtml are insecure?

[Trent W. Buck]

Moritz Muehlenhoff wrote:
> On Tue, Jan 25, 2022 at 12:20:46AM +1100, Trent W. Buck wrote:
> > Package: debian-security-support
> > Version: 1:11+2021.03.19
> > Severity: normal
> > File: /usr/share/debian-security-support/security-support-limited
> > 
> > As at Debian 11,
> > 
> >   * webkitgtk is in src:webkit2gtk, not src:webkit.
> >   * khtml is in src:khtml, not src:kde4libs.
> > 
> > GNOME3 and KDE5 have been around for a while now.
> > I think security-support-limited should be updated to reflect this.
> 
> webkit2gtk is fully supported since Buster and there have been plenty of 
> security updates since
> then: https://security-tracker.debian.org/tracker/source-package/webkit2gtk

Am I misreading the Release Notes?


https://www.debian.org/releases/bullseye/arm64/release-notes/ch-information.en.html#limited-security-support

browsers built upon e.g. the webkit and khtml engines^[6] are
included in bullseye, but not covered by security support.

Are you saying that webkit2gtk is supported, but anything that USES webkit2gtk 
is unsupported?

Even if that is the case, webkit2gtk itself ships a web browser based on 
webkit2gtk:

libwebkit2gtk-4.0-37:amd64: 
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser

That browser even accesses a remote (therefore not trusted by debian) URL by 
default.
(Unlike e.g. yelp, which uses webkit2gtk mainly to render content provided by 
Debian.)
It also enables javascript (remote code execution) by default.

Since webkit2gtk includes a webkit2gtk-based browser, and
"browser built upon webkit" are "not covered by security support",
I still think webkit2gtk belongs in the "security support is limited" list.

I agree that debian-security has provided security updates for webkit2gtk in 
the past.
I think "limited" doesn't mean "we promise never to issue security updates";
I think "limited" means "we don't promise to issue security updates".

Sorry if I'm missing something obvious!

Oh!  I've been assuming when the Release Notes said only firefox-esr/chromium 
are supported, and
explicitly gave "webkit" as an example, that "webkit" meant webkit2gtk.
But maybe it only meant webkit (MacOS-only, not ever in Debian) or
"webkitgtk" (not in Debian for about 8 years)?
But then why even mention it in the *bullseye* release notes?

Bug#1004293: Acknowledgement (warn users that src:webkit2gtk and src:khtml are insecure?)

[Trent W. Buck]

As discussed in IRC, here's a rough draft patch.
I haven't actually, like, built a .deb and installed it and run the script 
(sorry).
>From 501e9a6653c86fb59eceffdc6bdcc320691b8604 Mon Sep 17 00:00:00 2001
From: "Trent W. Buck" 
Date: Tue, 25 Jan 2022 00:38:23 +1100
Subject: [PATCH] Warn people about khtml and webkit2gtk (Closes: #773387,
 #1004293)

---
 debian/changelog | 7 +++
 security-support-limited | 9 +
 2 files changed, 16 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 2a828a1..dc19574 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+debian-security-support (1:12+2021.12.09) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Warn people about khtml and webkit2gtk (Closes: #773387, #1004293)
+
+ -- Trent W. Buck   Tue, 25 Jan 2022 00:37:16 +1100
+
 debian-security-support (1:12+2021.12.08) unstable; urgency=medium
 
   [ Sylvain Beucler ]
diff --git a/security-support-limited b/security-support-limited
index bebda1c..7e9c7ad 100644
--- a/security-support-limited
+++ b/security-support-limited
@@ -6,13 +6,19 @@
 # 2. Descriptive text or URL with more details (optional)
 #In the program's output, this is prefixed with "Details:"
 
+# See also:
+# https://www.debian.org/releases/bullseye/arm64/release-notes/ch-information.en.html#limited-security-support
+
 adnsStub resolver that should only be used with trusted recursors
 binutilsOnly suitable for trusted content; see https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
 cython  Only included for building packages, not running them, #975058
 ganglia See README.Debian.security, only supported behind an authenticated HTTP zone, #702775
 ganglia-web See README.Debian.security, only supported behind an authenticated HTTP zone, #702776
 golang.*See https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking
+# Debian 10 and earlier?
 kde4libskhtml has no security support upstream, only for use on trusted content
+# Debian 9 and later?
+khtml   khtml has no security support upstream, only for use on trusted content
 libv8-3.14  Not covered by security support, only suitable for trusted content
 mozjs   Not covered by security support, only suitable for trusted content
 mozjs24 Not covered by security support, only suitable for trusted content
@@ -28,5 +34,8 @@ qtwebkitNo security support upstream and backports not feasible, only fo
 qtwebkit-opensource-src No security support upstream and backports not feasible, only for use on trusted content
 sql-ledger  Only supported behind an authenticated HTTP zone
 swftoolsNot covered by security support, only suitable for trusted content
+# Debian 9 and earlier
 webkitgtk   No security support upstream and backports not feasible, only for use on trusted content
+# Debian 8 and later
+webkit2gtk  No security support upstream and backports not feasible, only for use on trusted content
 zoneminder  See README.Debian.security, only supported behind an authenticated HTTP zone, #922724
-- 
2.30.2

Bug#1004293: warn users that src:webkit2gtk and src:khtml are insecure?

[Trent W. Buck]

Package: debian-security-support
Version: 1:11+2021.03.19
Severity: normal
File: /usr/share/debian-security-support/security-support-limited

As at Debian 11,

  * webkitgtk is in src:webkit2gtk, not src:webkit.
  * khtml is in src:khtml, not src:kde4libs.

GNOME3 and KDE5 have been around for a while now.
I think security-support-limited should be updated to reflect this.

These libraries are used by, for example, yelp and khelpcenter.
This means this fix will make check-security-support whinge at most GUI users,
the way it already does for needrestart users (#986507).

(I think this is a good thing.
There's really no reason yelp and khelpcenter need to JIT compile 
docbook/mallard to HTML and then embed a custom browser engine.
Get rid of them, render the HTML when the .deb is built, and just run the 
user's normal, security-supported browser.)

Note that someone already reported the khtml issue way back in Debian 7 
(#773387), but it was marked as blocked because
(paraphrasing) "KDE4 libraries are a mess and we'd end up with false positives 
for EVERY library in KDE" (#765452).
This is substantially improved in KDE5, and (AFAICT) should no longer block 
"correctly report src:khtml is insecure crap".



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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 debian-security-support depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  gettext-base   0.21-4

debian-security-support recommends no packages.

debian-security-support suggests no packages.

-- debconf information:
  debian-security-support/earlyend:
  debian-security-support/ended:
  debian-security-support/limited:

Bug#1004062: offline help (keys, manual, release notes, FAQ)

[Trent W. Buck]

Package: inkscape
Version: 1.1.1-2~bpo11+1
Severity: wishlist

Currently Inkscape's Help menu just opens URLs.

   
https://sources.debian.org/src/inkscape/1.1.1-2%7Ebpo11+1/src/verbs.cpp/#L2051-L2101

My disadvantaged users do not have internet access, so currently they cannot 
get help.
This is already fixed for Help > Tutorials (apt install inkscape-tutorials).
Can this be extended to the rest of the Help menu?

The tutorials come from this repository:

https://gitlab.com/inkscape/inkscape-docs/documentation

Help > Keys comes from that same repository.
Help > Command Line Options comes from that same repository (./man/).

Help > Manual currently points to an third-party manual that is

   * written for the wrong Inkscape version,
   * doesn't support https, and
   * cannot be distributed by Debian (non-commercial clause).

However, there is a new first-party manual which is here:

https://gitlab.com/inkscape/inkscape-docs/manuals

It is available pre-rendered here (only for latest version, not guaranteed to 
be for the version Debian ships):

https://inkscape-manuals.readthedocs.io/en/latest/
https://inkscape-manuals.readthedocs.io/_/downloads/en/latest/pdf/
https://inkscape-manuals.readthedocs.io/_/downloads/en/latest/htmlzip/
https://inkscape-manuals.readthedocs.io/_/downloads/en/latest/epub/



I am happy if "Help > Keys" and "Help > Manual" work offline.
However here are some notes about the other options:

Help > FAQ I think must come from here, but I can't see HOW.

https://gitlab.com/inkscape/inkscape-web/

Help > New In This Version comes from Mediawiki, so is probably annoying.
This may be auto-generated elsewhere; I haven't found evidence of this.

https://wiki.inkscape.org/wiki/Release_notes/1.1

Help > Report a Bug &
Help > Donate are not useful offline.

Help > SVG 1.1 Specification &
Help > SVG 2.0 Specification link to w3.org.
I don't know if it's worth caring about those.

Help > About Memory &
Help > About Inkscape
are already working offline, they are in-app widgets.



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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 inkscape depends on:
ii  libatkmm-1.6-1v5   2.28.0-3
ii  libboost-filesystem1.74.0  1.74.0-9
ii  libc6  2.31-13+deb11u2
ii  libcairo2  1.16.0-5
ii  libcairomm-1.0-1v5 1.12.2-4
ii  libcdr-0.1-1   0.1.6-2
ii  libdbus-glib-1-2   0.110-6
ii  libdouble-conversion3  3.1.5-6.1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1
ii  libgc1 1:8.0.4-3
ii  libgcc-s1  10.2.1-6
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libglib2.0-0   2.66.8-1
ii  libglibmm-2.4-1v5  2.64.2-2
ii  libgomp1   10.2.1-6
ii  libgsl25   2.6+dfsg-2
ii  libgspell-1-2  1.8.4-1
ii  libgtk-3-0 3.24.24-4
ii  libgtkmm-3.0-1v5   3.24.2-2
ii  libharfbuzz0b  2.7.4-1
ii  libjpeg62-turbo1:2.0.6-4
ii  liblcms2-2 2.12~rc1-2
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.3
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpangoft2-1.0-0  1.46.2-3
ii  libpangomm-1.4-1v5 2.42.1-1
ii  libpng16-161.6.37-3
ii  libpoppler-glib8   20.09.0-3.1
ii  libpoppler102  20.09.0-3.1
ii  libpotrace01.16-2
ii  libreadline8   8.1-1
ii  librevenge-0.0-0   0.0.4-6+b1
ii  librsvg2-common2.50.3+dfsg-1
ii  libsigc++-2.0-0v5  2.10.4-2
ii  libsoup2.4-1   2.72.0-2
ii  libstdc++6 10.2.1-6
ii  libvisio-0.1-1 0.1.7-1+b1
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.7.2-1
ii  libxml22.9.10+dfsg-6.7
ii  libxslt1.1 1.1.34-4
ii  python33.9.2-3
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages inkscape recommends:
ii  aspell   0.60.8-3
ii  fig2dev  1:3.2.8-3+b1
ii  graphicsmagick-imagemagick-compat [imagemagick]  1.4+really1.3.36+hg16481-2
ii  libimage-magick-perl 8:6.9.11.60+dfsg-1.3
ii  libwmf-bin   0.2.8.4-17
ii  python3-lxml 4.6.3+dfsg-0.1+deb11u1
ii  python3-numpy  

Bug#1004001: Acknowledgement (Missing ordering: initramfs-tools trigger must run AFTER fontconfig trigger)

[Trent W. Buck]

PS: an inelegant workaround is to run apt more than once.

It is neater to install fontconfig early (tested, works),

+ --essential-hook='chroot $1 apt install fontconfig -y'

...rather than install linux-image-generic late, or
switch plymouth over to a fontful theme and sit through a second initrd rebuild.
(mkinitramfs is quite slow, even with --include=pigz).
I haven't tested the below strategies today, but they've worked in the past.

- --include=linux-image-amd64/bullseye-backports
+ --customize-hook='chroot $1 apt install 
linux-image-amd64/bullseye-backport'

- --include=desktop-base
+ --customize-hook='chroot $1 apt install desktop-base'
+ --customize-hook='chroot $1 update-initramfs -u -k all'

- --include=desktop-base
+ --customize-hook='chroot $1 plymouth-set-default-theme --rebuild-initrd 
bgrt'

Bug#1004001: Missing ordering: initramfs-tools trigger must run AFTER fontconfig trigger

[Trent W. Buck]

Package: dpkg
Version: 1.20.9
Severity: normal

This fails due to a missing ordering between two dpkg triggers:

mmdebstrap bullseye /dev/null 
--include=linux-image-amd64/bullseye-backports,plymouth-themes,desktop-base 
'deb http://deb.debian.org/debian bullseye main' 'deb 
http://deb.debian.org/debian bullseye-backports main'

Changes to the package versions in bullseye can make this problem 
disappear/reappear.
When I build large Debian Live images, certain combinations of packages are 
enough to trigger it.
After a couple of hours, I've produced the above minimum recipe to reproduce it 
RIGHT NOW, but that might change :-(

What (I think) is happening:

1. linux-image-amd64 pulls in initramfs-tools, which tries to make 
/boot/initrd.img via a trigger.
2. debian-base makes plymouth use a GUI theme, which needs 
/etc/fonts/fonts.conf to exist when initrd.img is built.
3. fontconfig generates /etc/fonts/fonts.conf via a trigger.
4. if trigger #1 runs before trigger #3, fonts.conf doesn't exist yet, and 
/sbin/mkinitramfs fails.

I think the correct fix is for plymouth to tell dpkg

I need fonts in the ramdisk, therefore
please run fontconfig trigger BEFORE initramfs-tools trigger.

I am initially filing this against dpkg because:

1. AFAICT dpkg provides no mechanism for to plymouth to say that.
2. This bug comes and goes, so it'd be great if a dpkg expert looked at 
this promptly.
3. desktop-base/plymouth/fontconfig/linux maintainers probably aren't dpkg 
experts.

Sorry if this wastes your time because I assigned it to the wrong package! :-(


-- Package-specific info:
System tainted due to merged-usr-via-aliased-dirs.

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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13+deb11u2
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
pn  debsig-verify  

-- no debconf information
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.T5JrqJTIEv as tempdir
I: running apt-get update...
I: downloading packages with apt...
I: extracting archives...
I: installing essential packages...
I: downloading apt...
I: installing apt...
I: installing remaining packages inside the chroot...
Reading package lists...
Building dependency tree...
adduser is already the newest version (3.118).
apt is already the newest version (2.2.4).
debconf is already the newest version (1.5.77).
debian-archive-keyring is already the newest version (2021.1.1).
gcc-10-base is already the newest version (10.2.1-6).
gpgv is already the newest version (2.2.27-2).
mawk is already the newest version (1.3.4.20200120-2).
libpam-modules is already the newest version (1.4.0-9+deb11u1).
libpam-modules-bin is already the newest version (1.4.0-9+deb11u1).
libpam-runtime is already the newest version (1.4.0-9+deb11u1).
passwd is already the newest version (1:4.8.1-1).
The following additional packages will be installed:
  dmsetup fontconfig fontconfig-config fonts-cantarell fonts-dejavu-core 
fonts-quicksand initramfs-tools initramfs-tools-core klibc-utils libapparmor1 
libargon2-1 libbpf0 libbrotli1 libbsd0 libcairo-gobject2 libcairo2 libcap2 
libcap2-bin libcryptsetup12 libdatrie1 libdeflate0 libdevmapper1.02.1 
libdns-export1110 libdrm-common libdrm2 libedit2 libelf1 libestr0
  libexpat1 libext2fs2 libfastjson4 libfdisk1 libfontconfig1 libfreetype6 
libfribidi0 libgdk-pixbuf-2.0-0 libgdk-pixbuf2.0-common libglib2.0-0 
libgraphite2-3 libharfbuzz0b libicu67 libip4tc2 libisc-export1105 libjansson4 
libjbig0 libjpeg62-turbo libjson-c5 libklibc libkmod2 liblocale-gettext-perl 
liblognorm5 libmd0 libmnl0 libncurses6 libncursesw6 libnewt0.52
  libnftables1 libnftnl11 libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 
libpixman-1-0 libplymouth5 libpng16-16 libpopt0 libprocps8 librsvg2-2 
librsvg2-common libslang2 libss2 libtext-charwidth-perl libtext-iconv-perl 
libtext-wrapi18n-perl libthai-data libthai0 libtiff5 libwebp6 libx11-6 
libx11-data libxau6 libxcb-render0 libxcb-shm0 libxcb1 libxdmcp6
  libxext6 libxml2 libxrender1 libxtables12 linux-base 
linux-image-5.15.0-0.bpo.2-amd64 logsave plymouth plymouth-label 
shared-mime-info systemd-timesyncd tasksel ucf xxd
Suggested packages:
  

Bug#1003764: argparse: empty mutually_exclusive_group breaks --help

[Trent W. Buck]

Package: libpython3.9-minimal
Version: 3.9.2-1
Severity: normal
File: /usr/lib/python3.9/argparse.py

This works:

#!/usr/bin/python3
import argparse
parser = argparse.ArgumentParser(description='Demonstrate a dumbness in 
python 3.9')
parser.add_mutually_exclusive_group().add_argument('--fred')
parser.parse_args(['--help'])

This errors:

#!/usr/bin/python3
import argparse
parser = argparse.ArgumentParser(description='Demonstrate a dumbness in 
python 3.9')
parser.add_mutually_exclusive_group()
parser.parse_args(['--help'])

This is the error:

Traceback (most recent call last):
  File "", line 5, in 
  File "/usr/lib/python3.9/argparse.py", line 1830, in parse_args
args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python3.9/argparse.py", line 1863, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python3.9/argparse.py", line 2072, in _parse_known_args
start_index = consume_optional(start_index)
  File "/usr/lib/python3.9/argparse.py", line 2012, in consume_optional
take_action(action, args, option_string)
  File "/usr/lib/python3.9/argparse.py", line 1940, in take_action
action(self, namespace, argument_values, option_string)
  File "/usr/lib/python3.9/argparse.py", line 1104, in __call__
parser.print_help()
  File "/usr/lib/python3.9/argparse.py", line 2560, in print_help
self._print_message(self.format_help(), file)
  File "/usr/lib/python3.9/argparse.py", line 2544, in format_help
return formatter.format_help()
  File "/usr/lib/python3.9/argparse.py", line 295, in format_help
help = self._root_section.format_help()
  File "/usr/lib/python3.9/argparse.py", line 226, in format_help
item_help = join([func(*args) for func, args in self.items])
  File "/usr/lib/python3.9/argparse.py", line 226, in 
item_help = join([func(*args) for func, args in self.items])
  File "/usr/lib/python3.9/argparse.py", line 333, in _format_usage
action_usage = format(optionals + positionals, groups)
  File "/usr/lib/python3.9/argparse.py", line 408, in _format_actions_usage
start = actions.index(group._group_actions[0])
IndexError: list index out of range


The problem only affects --help; an empty mutex group (without
required=True) still works in regular (non --help) usage.

I think the default --help provider should just skip empty mutex groups.

I think this (UNTESTED!) patch is probably sufficient:

diff -ud --label /tmp/argparse.py --label \#\ 
/tmp/argparse.py /tmp/buffer-content-7I3lfM
--- /tmp/argparse.py
+++ #
@@ -404,6 +404,8 @@
 group_actions = set()
 inserts = {}
 for group in groups:
+if len(group._group_actions) == 0:
+continue
 try:
 start = actions.index(group._group_actions[0])
 except ValueError:

Diff finished.  Sat Jan 15 22:28:23 2022

I guess this is an upstream issue, but
I haven't time today to compare Debian's python to upstream's python.
Sorry about that.



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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 libpython3.9-minimal:amd64 depends on:
ii  libc6  2.31-13+deb11u2
ii  libssl1.1  1.1.1k-1+deb11u1

Versions of packages libpython3.9-minimal:amd64 recommends:
ii  libpython3.9-stdlib  3.9.2-1

libpython3.9-minimal:amd64 suggests no packages.

-- no debconf information

Bug#983035: Missing dependency on dbus-x11

[Trent W. Buck]

Francesco,

Is dbus-user-session installed?
xfce4-session recommends dbus-user-session, so
it SHOULD already be installed.


Francesco P. Lovergine wrote:
> Package: xfce4
> Version: 4.16
> Severity: normal
> 
> I found a missing dependency on /usr/bin/dbus-launch (dbus-x11) in bullseye,
> somewhere. Not sure this is an xfce4 issue specifically, feel free to
> reassign to another proper package.
> 
> In order to replicate the problem: I just installed from scratch a bullseye
> current image (debian/testing64) in vagrant, with virtualbox provider, an
> upgraded it.  Then installed xfce4i (the metapackage) and started lightdm.
> After that, the user cannot login and start a session due to missing
> dbus-launch, with appropriate message at screen. Installing dbus-x11 solves
> the problem.

dbus-launch (from "dbus-x11") package is the Old Way,
which is still attempted as a fallback.

Most systemd linux systems will instead use libpam-systemd to set up the user 
dbus session.
In this case, dbus-launch is not used.

You can see this in the source code -- if there's already a dbus
session (usually created by systemd), it just returns immediately.


https://sources.debian.org/src/xfce4-session/4.16.0-1/xfce4-session/main.c/#L275-L278

This is encoded in the control file like this:

https://sources.debian.org/src/xfce4-session/4.16.0-1/debian/control/#L31

On a Debian GNU/Linux architecture, that
will default to the systemd path (dbus-user-session).
Where systemd isn't available (e.g. Debian GNU/kFreeBSD),
it falls back to dbus-x11 (dbus-launch).

See also


https://sources.debian.org/src/xfce4-session/4.16.0-1/debian/changelog/#L37-L38
https://bugs.debian.org/836062

Bug#1003427: COMPRESS=zstd and COMPRESS=lz4 hard-coded to bad COMPRESSLEVELs

[Trent W. Buck]

Ben Hutchings wrote:
> On Mon, 2022-01-10 at 11:04 +1100, Trent W. Buck wrote:
> > Package: initramfs-tools
> > Version: 0.140
> > Severity: wishlist
> > 
> > This is a vote for 
> > https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/52
> > I did this investigation 2 months ago, but AFAICT I forgot to push it to 
> > bugs.debian.org.
> > https://github.com/cyberitsolutions/bootstrap2020/blob/main/doc/N-ramdisk-compression.rst
> > 
> > Are pigz and xz *REALLY* the best choices for rd compression?
> > Surely lz4 and zstd are better tradeoffs?
> [...]
> 
> You'll be pleased to hear that in master, zstd with compression level 9
> is now the default.  The -T0 option is still unconditional though...
> 
> I have no idea whether the lz4 options should be changed.  I'm not sure
> it's actually a good choice for anyone.

FTR my two use cases are:

  1. Build a test Debian Live image and run qemu on it, just once.
 Build should be quick and ideally not make my laptop heat up.
 Output size doesn't matter at all.

  2. Build a prod Debian Live image and then upload it to a server
 where 1000 desktops will netboot it daily.

I'm using tar2squashfs --comp=lz4 for case #1, so
using lz4 at other layers was intuitive.

Based on the actual measurements, however, I think pigz is a better
bet than lz4 unless/until lz4 gets a -T0 option. ;-)

Bug#1003427: Acknowledgement (COMPRESS=zstd and COMPRESS=lz4 hard-coded to bad COMPRESSLEVELs)

[Trent W. Buck]

PS: my previous email speculated: does zstd -T0 break SOURCE_DATE_EPOCH?
I think this test shows that zstd -T0 is safe even when SOURCE_DATE_EPOCH=1.
i.e. it does not need the equivalent of mkinitramfs's workaround for xz and 
gzip.

bash5$ ls -hl
total 1.1G
-rw-r--r-- 1 twb twb 1.1G 2022-01-10 11:06 linux_5.15.5.orig.tar

bash5$ zstd --keep --fast --verbose --threads=0 linux_5.15.5.orig.tar
*** zstd command line interface 64-bits v1.4.8, by Yann Collet ***
Note: 4 physical core(s) detected
linux_5.15.5.orig.tar : 21.38%   (1136691200 => 243006203 bytes, 
linux_5.15.5.orig.tar.zst)

bash5$ ls
linux_5.15.5.orig.tar  linux_5.15.5.orig.tar.zst

bash5$ mv linux_5.15.5.orig.tar.zst linux_5.15.5.orig.tar.zst.~1~

bash5$ zstd --keep --fast --verbose --threads=0 linux_5.15.5.orig.tar
*** zstd command line interface 64-bits v1.4.8, by Yann Collet ***
Note: 4 physical core(s) detected
linux_5.15.5.orig.tar : 21.38%   (1136691200 => 243006203 bytes, 
linux_5.15.5.orig.tar.zst)

bash5$ mv linux_5.15.5.orig.tar.zst linux_5.15.5.orig.tar.zst.~2~

bash5$ b2sum *~

570c5509c9c95dabb655be223f70d48182ee547da3df43696139f00969e3eeb51b4f0a5bab9ca3e905ba3e52fbebb6892ee643e246522198b764143228e81437
  linux_5.15.5.orig.tar.zst.~1~

570c5509c9c95dabb655be223f70d48182ee547da3df43696139f00969e3eeb51b4f0a5bab9ca3e905ba3e52fbebb6892ee643e246522198b764143228e81437
  linux_5.15.5.orig.tar.zst.~2~

bash5$ SOURCE_DATE_EPOCH=1 zstd --keep --verbose --threads=0 
linux_5.15.5.orig.tar
*** zstd command line interface 64-bits v1.4.8, by Yann Collet ***
Note: 4 physical core(s) detected
linux_5.15.5.orig.tar : 16.29%   (1136691200 => 185188738 bytes, 
linux_5.15.5.orig.tar.zst)

bash5$ ls -lh
total 1.7G
-rw-r--r-- 1 twb twb 1.1G 2022-01-10 11:06 linux_5.15.5.orig.tar
-rw-r--r-- 1 twb twb 177M 2022-01-10 11:06 linux_5.15.5.orig.tar.zst
-rw-r--r-- 1 twb twb 232M 2022-01-10 11:06 linux_5.15.5.orig.tar.zst.~1~
-rw-r--r-- 1 twb twb 232M 2022-01-10 11:06 linux_5.15.5.orig.tar.zst.~2~

bash5$ mv linux_5.15.5.orig.tar.zst linux_5.15.5.orig.tar.zst.~1~

bash5$ SOURCE_DATE_EPOCH=1 zstd --keep --verbose --threads=0 
linux_5.15.5.orig.tar
*** zstd command line interface 64-bits v1.4.8, by Yann Collet ***
Note: 4 physical core(s) detected
linux_5.15.5.orig.tar : 16.29%   (1136691200 => 185188738 bytes, 
linux_5.15.5.orig.tar.zst)

bash5$ mv linux_5.15.5.orig.tar.zst linux_5.15.5.orig.tar.zst.~2~

bash5$ b2sum *~

7edc85faf5c53c62d2a7b13f58100f2795aee109092bbf728c763d1945c84797cb71a4ae32f1cfd53fdaea959120dbbe6eea47fcdb4ee67a5e71faea7e1a122a
  linux_5.15.5.orig.tar.zst.~1~

7edc85faf5c53c62d2a7b13f58100f2795aee109092bbf728c763d1945c84797cb71a4ae32f1cfd53fdaea959120dbbe6eea47fcdb4ee67a5e71faea7e1a122a
  linux_5.15.5.orig.tar.zst.~2~

Bug#1003427: COMPRESS=zstd and COMPRESS=lz4 hard-coded to bad COMPRESSLEVELs

[Trent W. Buck]

Package: initramfs-tools
Version: 0.140
Severity: wishlist

This is a vote for 
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/52
I did this investigation 2 months ago, but AFAICT I forgot to push it to 
bugs.debian.org.
https://github.com/cyberitsolutions/bootstrap2020/blob/main/doc/N-ramdisk-compression.rst

Are pigz and xz *REALLY* the best choices for rd compression?
Surely lz4 and zstd are better tradeoffs?

Looking at [a Debian Live chroot]::

# apt install pixz pigz zstd lz4 xz-utils firmware-misc-nonfree
# for i in lz4 gzip xz zstd;
  do
  echo === $i === &&
  echo COMPRESS=$i >/etc/initramfs-tools/conf.d/test &&
  time update-initramfs -u -k all &&
  ls -hl /boot/initrd.img-5.14.0-0.bpo.2-amd64;
  done

COMPRESSrealusersys size
lz4 0m10.125s   0m9.263s0m1.242s55M
gzip0m5.724s0m11.860s   0m1.123s47M(really 
pigz)
xz  0m18.556s   1m15.392s   0m1.307s32M
zstd0m25.993s   1m20.542s   0m1.237s35M

So:

•   pigz greatly beats lz4 for wall-clock time.
pigz beats lz4 for size.
lz4 slightly beats pigz for CPU time (meh).

pigz is the best choice for --optimize=speed.

•   xz slightly beats zstd for size.
xz beats zstd for wall-clock time.
xz slightly beats zstd for CPU time (meh).

xz is the best choice for --optimize=size.

BUT /usr/sbin/mkinitramfs makes these UNFAIR COMPARISONS.
It uses the HIGHEST compression level for lz4 and zstd, but
the DEFAULT (best tradeoff) compression for gzip and xz. ::

case "${compress}" in
gzip)   # If we're doing a reproducible build, use gzip -n
if [ -n "${SOURCE_DATE_EPOCH}" ]; then
compress="gzip -n"
# Otherwise, substitute pigz if it's available
elif command -v pigz >/dev/null; then
compress=pigz
fi
;;
lz4)compress="lz4 -9 -l" ;;
zstd)   compress="zstd -q -19 -T0" ;;
xz) compress="xz --check=crc32"
# If we're not doing a reproducible build, enable multithreading
test -z "${SOURCE_DATE_EPOCH}" && compress="$compress --threads=0"
;;
bzip2|lzma|lzop)
# no parameters needed
;;
*)  echo "W: Unknown compression command ${compress}" >&2 ;;
esac

Just for my peace of mind, let's re-test this with the -9 and -19 removed::

# sed -rsi /usr/sbin/mkinitramfs -e 's/ -19 / /' -e 's/ -9 / /'
# apt install pixz pigz zstd lz4 xz-utils firmware-misc-nonfree
# for i in lz4 gzip xz zstd;
  do
  echo === $i === &&
  echo COMPRESS=$i >/etc/initramfs-tools/conf.d/test &&
  time update-initramfs -u -k all &&
  ls -hl /boot/initrd.img-5.14.0-0.bpo.2-amd64;
  done


COMPRESSrealusersys size
lz4 0m5.070s0m4.207s0m1.209s67M
gzip0m5.572s0m11.308s   0m1.197s47M(really 
pigz)
xz  0m18.646s   1m14.563s   0m1.204s32M
zstd0m5.159s0m5.334s0m1.137s43M

So:

•   When lz4 isn't forced into a bad time/size tradeoff,
it's as fast as pigz, but much bigger.  Fail.

•   When zstd isn't forced into a bad time/size tradeoff,
it's a little smaller than pigz,
it's as fast as pigz, and
it's MUCH faster than xz.

Clear win.

It seems to me that the following changes should be made:

•   Don't pass -19 to zstd.
•   Don't pass -T0 to zstd when [ -n $SOURCE_DATE_EPOCH ] (same as other -T0 
cases).
•   Encourage people to switch to zstd? ;-)




-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 53M 2021-11-19 09:17 
/boot/initrd.img-5.14.0-0.bpo.2-amd64
-- /proc/cmdline
root=ZFS=hera/hera quiet splash noresume initrd=\initrd.img-5.14.0-0.bpo.2-amd64

-- /proc/filesystems
fuseblk
ext3
ext2
ext4
vfat

-- lsmod
Module  Size  Used by
ccm20480  6
rfcomm 90112  0
cmac   16384  7
algif_hash 16384  3
algif_skcipher 16384  3
af_alg 32768  14 algif_hash,algif_skcipher
bnep   28672  2
binfmt_misc24576  1
intel_pmc_core_pltdrv16384  0
intel_pmc_core 45056  0
snd_sof_pci_intel_cnl16384  0
snd_sof_intel_hda_common   106496  1 snd_sof_pci_intel_cnl
x86_pkg_temp_thermal20480  0
soundwire_intel45056  1 snd_sof_intel_hda_common
intel_powerclamp   20480  0
coretemp   20480  0
soundwire_generic_allocation16384  1 soundwire_intel
soundwire_cadence  36864  1 soundwire_intel
snd_sof_intel_hda  20480  1 snd_sof_intel_hda_common
kvm_intel 323584  0
snd_sof_pci20480  2 

Bug#1003194: Inconsistencies between "make bindeb-pkg" and official Debian kernels

[Trent W. Buck]

Package: debian-kernel-handbook
Version: 1.0.19
Severity: normal

[Initially filed against debian-kernel-handbook because while the
problem is in src:linux, it's not strictly a problem with src:linux's
official binary packages.]

Debian Live images with custom kernels need some workarounds, because
"make bindeb-pkg" is inconsistent with official Debian kernels.
I would like to remove both the inconsistencies and my workarounds.

Attached are two scripts, one using stock kernel, one using custom
kernel built with "make bindeb-pkg" and then hosted on a PPA.
Removing either workaround breaks the "download" lines.

A few minor issues are annoying me:


  1. /vmlinuz and /initrd.img are not created.

 The problem appears to be inconsistency between these two scripts:

 a. official images use this, which calls linux-update-symlinks (and 
Depends: linux-base)

 
https://sources.debian.org/src/linux/5.14.9-2%7Ebpo11+1/debian/templates/image.postinst.in/#L17

 b. "make bindeb-pkg" use this, which does not

 
https://sources.debian.org/src/linux/5.14.9-2~bpo11+1/scripts/package/builddeb/#L186-L209

 Is it reasonable to make builddeb call linux-update-symlinks and Depends: 
linux-base?
 This seems reasonable to me.


  2. /boot/initrd.img- is not created.

 I think this is because there is no Depends, so
 (if everything happens in a single "apt install"),
 /var/lib/dpkg/info/linux-image-X.postinst runs before
 /etc/kernel/postinst.d/initramfs-tools exists.

 This does not happen with stock kernels, which I think use this:

 
https://sources.debian.org/src/linux/5.14.9-2%7Ebpo11+1/debian/templates/control.image.in/#L3-L5

 Is it reasonable to make builddeb add equivalent 
Depends/Recommends/Suggests?

 It would need to NOT mention initrd when build with CONFIG_MODULES=n, but
 builddeb already knows when this is the case.

 If build with (for example) "make localyesconfig", then even if 
CONFIG_MODULES=y,
 it should probably only Recommends or Suggests initramfs-tools (for 
amd64-microcode).

 This gets a little messy!


  3. I'd like a Provides or metapackage equivalent to "linux-image-generic", so
 with a PPA, I can say --include=linux-image-inmate and have it always pick 
the latest available.
 Currently with --include=linux-image-5.14.9inmate, I have to keep updating 
the --include line.

 The "inmate" comes from CONFIG_LOCALVERSION=inmate, so
 I guess builddeb would check if that was set, and if so, add

 Provides: linux-image-${CONFIG_LOCALVERSION}

 Is this reasonable?
 I can't see any downside, and it sounds easy.
 If I can get my head around builddeb, I'll try to submit a patch for this.


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
#!/bin/bash
cmd=(
mmdebstrap
bullseye
live/filesystem.squashfs
--customize-hook='download /vmlinuz ./live/vmlinuz'
--customize-hook='download /initrd.img ./live/initrd.img'
--include=live-boot
--include=linux-image-generic
https://deb.debian.org/debian
)

mkdir live
"${cmd[@]}"
ls -hlR live
#!/bin/bash
cmd=(
mmdebstrap
bullseye
live/filesystem.squashfs
# Work around lack of linux-update-symlinks
--customize-hook='chroot $1 linux-update-symlinks install 5.14.9inmate 
/boot/vmlinuz-5.14.9inmate'
# Work around lack of Depends: initramfs-tools
--customize-hook='chroot $1 dpkg-reconfigure linux-image-5.14.9inmate'
--customize-hook='download /vmlinuz ./live/vmlinuz'
--customize-hook='download /initrd.img ./live/initrd.img'
--include=live-boot
--include=linux-image-5.14.9inmate
https://deb.debian.org/debian
'deb [signed-by=/home/twb/PrisonPC-archive-pubkey.asc] 
https://apt.cyber.com.au/PrisonPC bullseye kernel-demo'
)

mkdir live
"${cmd[@]}"
ls -hlR live

Bug#983436: i386-cpuinfo.h missing in gcc-10-plugin-dev

[Trent W. Buck]

This bug means I cannot enable Linux kernel hardening features,
when using Debian 11's gcc and backport kernel.

GCC_PLUGIN_RANDSTRUCT "Randomize layout of sensitive kernel structures"

https://github.com/torvalds/linux/blob/master/scripts/gcc-plugins/Kconfig#L49

GCC_PLUGIN_STACKLEAK "Poison kernel stack before returning from syscalls"

https://github.com/torvalds/linux/blob/master/security/Kconfig.hardening#L152

GCC_PLUGIN_STRUCTLEAK
https://github.com/torvalds/linux/blob/master/security/Kconfig.hardening#L4

The specific kernel I tested was


https://snapshot.debian.org/archive/debian/20211015T150402Z/pool/main/l/linux/linux_5.14.9-2%7Ebpo11%2B1.dsc

Bug#1002889: Support CONFIG_BOOT_CONFIG (embed kernel boot parameters in ramdisk file)

[Trent W. Buck]

Package: initramfs-tools
Version: 0.140
Severity: wishlist

Recent Linux kernels support putting boot options
(e.g. "init=/bin/sh" or "i915.alpha_support=1")
inside the initrd file.


https://www.kernel.org/doc/html/latest/admin-guide/bootconfig.html#boot-kernel-with-a-boot-config

For me, this would often be easier than patching the bootloader(s) config.

Can someone (i.e. not me) do the initial thinking about this?
Like "how hard is this to do?" and
"what would the config structure in /etc look like?" and
"do /proc/cmdline scripts need to also check /proc/bootconfig now?"


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 53M 2021-11-19 09:17 
/boot/initrd.img-5.14.0-0.bpo.2-amd64
-- /proc/cmdline
root=ZFS=hera/hera quiet splash noresume initrd=\initrd.img-5.14.0-0.bpo.2-amd64

-- /proc/filesystems
fuseblk
ext3
ext2
ext4
vfat
exfat

-- lsmod
Module  Size  Used by
hid_generic16384  0
uhid   20480  1
hid   151552  2 hid_generic,uhid
rfcomm 90112  4
cmac   16384  9
algif_hash 16384  4
algif_skcipher 16384  4
af_alg 32768  18 algif_hash,algif_skcipher
exfat  86016  0
nf_log_syslog  20480  2
nft_log16384  2
nft_reject_inet16384  1
nf_reject_ipv4 16384  1 nft_reject_inet
nf_reject_ipv6 20480  1 nft_reject_inet
nft_reject 16384  1 nft_reject_inet
nft_ct 20480  1
nf_conntrack  176128  1 nft_ct
nf_defrag_ipv6 24576  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
tcp_diag   16384  0
inet_diag  28672  1 tcp_diag
rpcsec_gss_krb532768  0
auth_rpcgss   155648  1 rpcsec_gss_krb5
nfsv4 925696  2
dns_resolver   16384  1 nfsv4
nfs   430080  2 nfsv4
lockd 126976  1 nfs
grace  16384  1 lockd
fscache   397312  1 nfs
netfs  53248  1 fscache
ccm20480  9
bnep   28672  2
nf_tables 262144  52 nft_ct,nft_log,nft_reject_inet,nft_reject
libcrc32c  16384  2 nf_conntrack,nf_tables
nfnetlink  20480  1 nf_tables
binfmt_misc24576  1
intel_pmc_core_pltdrv16384  0
intel_pmc_core 45056  0
x86_pkg_temp_thermal20480  0
intel_powerclamp   20480  0
snd_sof_pci_intel_cnl16384  0
coretemp   20480  0
snd_sof_intel_hda_common   106496  1 snd_sof_pci_intel_cnl
soundwire_intel45056  1 snd_sof_intel_hda_common
kvm_intel 323584  0
soundwire_generic_allocation16384  1 soundwire_intel
soundwire_cadence  36864  1 soundwire_intel
snd_sof_intel_hda  20480  1 snd_sof_intel_hda_common
snd_sof_pci20480  2 snd_sof_intel_hda_common,snd_sof_pci_intel_cnl
snd_sof_xtensa_dsp 16384  1 snd_sof_intel_hda_common
snd_sof   147456  2 snd_sof_pci,snd_sof_intel_hda_common
snd_hda_codec_hdmi 73728  1
btusb  65536  0
kvm  1019904  1 kvm_intel
soundwire_bus  94208  3 
soundwire_intel,soundwire_generic_allocation,soundwire_cadence
btrtl  28672  1 btusb
btbcm  20480  1 btusb
btintel32768  1 btusb
bluetooth 757760  35 btrtl,btintel,btbcm,bnep,btusb,rfcomm
snd_soc_skl   180224  0
irqbypass  16384  1 kvm
snd_soc_hdac_hda   24576  2 snd_sof_intel_hda_common,snd_soc_skl
snd_hda_ext_core   36864  4 
snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_soc_skl,snd_sof_intel_hda
snd_ctl_led24576  0
snd_soc_sst_ipc20480  1 snd_soc_skl
nls_ascii  16384  1
snd_soc_sst_dsp36864  1 snd_soc_skl
nls_cp437  20480  1
snd_soc_acpi_intel_match53248  3 
snd_sof_intel_hda_common,snd_soc_skl,snd_sof_pci_intel_cnl
snd_hda_codec_realtek   159744  1
vfat   20480  1
snd_soc_acpi   16384  3 
snd_soc_acpi_intel_match,snd_sof_intel_hda_common,snd_soc_skl
joydev 28672  0
ghash_clmulni_intel16384  0
mei_hdcp   24576  0
iwlmvm352256  0
snd_soc_core  331776  5 
soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_soc_skl
snd_hda_codec_generic98304  1 snd_hda_codec_realtek
fat86016  1 vfat
intel_rapl_msr 20480  0
jitterentropy_rng  16384  1
snd_compress   32768  1 snd_soc_core
sha512_ssse3   49152  1
mac80211 1048576  1 iwlmvm
ext4  917504  1
sha512_generic 16384  1 sha512_ssse3
aesni_intel   380928  19
snd_hda_intel  57344  4
snd_intel_dspcfg   28672  3 
snd_hda_intel,snd_sof_intel_hda_common,snd_soc_skl
snd_intel_sdw_acpi 20480  2 snd_sof_intel_hda_common,snd_intel_dspcfg
uvcvideo  

Bug#1002491: ZFS transparent compression triggers spurious "Trailing allocated space"

[Trent W. Buck]

Package: apt-cacher-ng
Version: 3.6.4-1
Severity: normal

NOTE: I notice "c) never truncating package files, only appending" in
  https://salsa.debian.org/blade/apt-cacher-ng/-/blob/debian/sid/ChangeLog
  So this issue might ALREADY be fixed in testing/unstable.
  I have not tested this experimentally yet (sorry).

  Hopefully this bug report at least helps other Debian 11
  acng+ZFS users understand what's going on.

When /var/cache/apt-cacher-ng is a ZFS filesystem with transparent compression,
the space saving (or loss!) is visible on the command line with du 
--apparent-size:

root@odin:~# ls -l 
/var/cache/apt-cacher-ng/debrep/dists/experimental/main/source/Sources.xz
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 342636 Dec 23 17:58 
/var/cache/apt-cacher-ng/debrep/dists/experimental/main/source/Sources.xz

root@odin:~# du --block-size=512 --apparent-size 
/var/cache/apt-cacher-ng/debrep/dists/experimental/main/source/Sources.xz
740 
/var/cache/apt-cacher-ng/debrep/dists/experimental/main/source/Sources.xz

root@odin:~# du --block-size=512 
/var/cache/apt-cacher-ng/debrep/dists/experimental/main/source/Sources.xz
786 
/var/cache/apt-cacher-ng/debrep/dists/experimental/main/source/Sources.xz

On a system WITHOUT transparent compression,
these would normally report the same size (except for sparse files).

I *think* this difference causes apt-cacher-ng to mis-detect a file as being 
the wrong size:

Trailing allocated space on 
/var/cache/apt-cacher-ng/debrep/dists/experimental/main/source/Sources.xz (786 
blocks, expected: ~740), will be trimmed later

I only get 187 warnings though /var/cache/apt-cacher-ng has 20691 files.
I think this makes sense because most files in /var/cache/apt-cacher-ng are
already strongly compressed (e.g. Packages.xz or LZMA2's .deb).

"zfs get compressratio" supports this theory:

COMPRESSRATIO  USEDDS  NAME
zstd1.04x   7.70G  rpool/var/cache/apt-cacher-ng
zstd3.86x   3.02G  rpool
zstd5.33x571M  rpool/var/log/journal

On this basis, a reasonable workaround is to simply disable
transparent compression on apt-cacher-ng's filesystem, e.g.

zfs set compression=off rpool/var/cache/apt-cacher-ng

This will not affect files already written to disk, so
you'll still see trailing space warnings for existing files.
(Just delete them and let apt-cacher-ng re-fetch them, I guess.)




-- Package-specific info:

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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.77
ii  dpkg 1.20.9
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13+deb11u2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libgcc-s110.2.1-6
ii  liblzma5 5.2.5-2
ii  libssl1.11.1.1k-1+deb11u1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-6
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20210119

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.8-5
pn  doc-base  
ii  libfuse2  2.9.9-5

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
  apt-cacher-ng/proxy: keep
  apt-cacher-ng/bindaddress: keep
  apt-cacher-ng/cachedir: keep
  apt-cacher-ng/port: keep
* apt-cacher-ng/tunnelenable: false
  apt-cacher-ng/gentargetmode: No automated setup

Apt-Cacher NG maintenance tasks
Maintenance task Expiration, apt-cacher-ng version: 3.2.1 (Cancel)
Locating potentially expired files in the cache...
Scanning, found 1 file...
Scanning, found 2 files...
Scanning, found 4 files...
Scanning, found 8 files...
Scanning, found 16 files...
Scanning, found 32 files...
Trailing allocated space on 
/var/cache/apt-cacher-ng/snapshot.debian.org/archive/debian/20210901/pool/main/s/slang2/libslang2_2.3.2-5_amd64.deb
 (1042 blocks, expected: ~994), will be trimmed later
Scanning, found 64 files...
Scanning, found 128 files...
Trailing allocated space on 
/var/cache/apt-cacher-ng/snapshot.debian.org/archive/debian/20210901/pool/main/p/pcre2/libpcre2-8-0_10.36-2_amd64.deb
 (530 blocks, expected: ~483), will be 

Bug#962800: nut: NUT and systemd interacting poorly

[Trent W. Buck]

This is working to remove both warnings.
I'm 99% sure the real problem is that upsmon is trying to do things that are 
now systemd's job.
You can see the "kill" log even there which suggests upsmon remains derp.

# Trying to fix these warnings:
#nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) 
after start: Operation not permitted
#nut-monitor.service: Supervising process 1287240 which is not our 
child. We'll most likely not notice when it exits.
[Service]
RuntimeDirectory=nut
# Because /run/nut is shared by several nut units,
# do not erase it when THIS one ends.
# This might not be necessary, but
# I cannot easily tell, because
# I only run nut-monitor on this host!
RuntimeDirectoryPreserve=true
# Sigh, because upsmon starts as root then drops privs,
# it still fails to write to root:root /run/nut?
# Start upsmon as root:nut and make /run/nut root:nut.
# Maybe that will be enough to make thus STFU?
Group=nut
#  twb just remove PIDFile=
PIDFile=


cyber@light:~$ systemctl status nut-monitor
● nut-monitor.service - Network UPS Tools - power device monitor and shutdown 
controller
 Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor 
preset: enabled)
Drop-In: /etc/systemd/system/nut-monitor.service.d
 └─override.conf
 Active: active (running) since Wed 2021-12-22 13:56:11 AEDT; 6min ago
Process: 1303859 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS)
   Main PID: 1303860 (upsmon)
  Tasks: 2 (limit: 4653)
 Memory: 896.0K
CPU: 17ms
 CGroup: /system.slice/nut-monitor.service
 ├─1303860 /lib/nut/upsmon
 └─1303861 /lib/nut/upsmon

Dec 22 13:56:11 light systemd[1]: Starting Network UPS Tools - power device 
monitor and shutdown controller...
Dec 22 13:56:11 light upsmon[1303859]: kill: No such process
Dec 22 13:56:11 light upsmon[1303859]: UPS: up...@omega.cyber.com.au (slave) 
(power value 1)
Dec 22 13:56:11 light upsmon[1303859]: Using power down flag file /etc/killpower
Dec 22 13:56:11 light upsmon[1303860]: Startup successful
Dec 22 13:56:11 light systemd[1]: Started Network UPS Tools - power device 
monitor and shutdown controller.
Dec 22 13:56:11 light upsmon[1303861]: Init SSL without certificate database

Bug#962800: nut: NUT and systemd interacting poorly

[Trent W. Buck]

Christi Scarborough wrote:
> Jun 14 11:29:51 yaga systemd[1]: /lib/systemd/system/nut-monitor.service:6: 
> PIDFile= references path below legacy directory /var/run/, updating 
> /var/run/nut/upsmon.pid → /run/nut/upsmon.pid; please update the unit file 
> accordingly.
> Jun 14 11:32:46 yaga systemd[1]: Starting Network UPS Tools - power device 
> monitor and shutdown controller...
> Jun 14 11:32:46 yaga upsmon[34188]: fopen /var/run/nut/upsmon.pid: No such 
> file or directory
> Jun 14 11:32:46 yaga upsmon[34188]: UPS:  (slave) (power value 1)
> Jun 14 11:32:46 yaga upsmon[34188]: Using power down flag file /etc/killpower
> Jun 14 11:32:46 yaga systemd[1]: nut-monitor.service: Can't open PID file 
> /run/nut/upsmon.pid (yet?) after start: No such file or directory
> Jun 14 11:32:46 yaga upsmon[34195]: Startup successful
> Jun 14 11:32:46 yaga systemd[1]: Started Network UPS Tools - power device 
> monitor and shutdown controller.
> Jun 14 11:32:46 yaga upsmon[34196]: Init SSL without certificate database
> 
> Although the app is working, both errors (the first and 6th lines above are 
> of concern, as I am uncertain whether they will cause unpredictable behaviour.

I see this also, on a Debian 11 host with nut-client installed.
The nut server is on a different host.
I tried a couple of variations of this, but it didn't help:

# /etc/systemd/system/nut-monitor.service.d/override.conf

# Trying to fix these warnings:
#nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) 
after start: Operation not permitted
#nut-monitor.service: Supervising process 1287240 which is not our 
child. We'll most likely not notice when it exits.
[Service]
RuntimeDirectory=nut
# Because /run/nut is shared by several nut units,
# do not erase it when THIS one ends.
# This might not be necessary, but
# I cannot easily tell, because
# I only run nut-monitor on this host!
RuntimeDirectoryPreserve=true
# Sigh, because upsmon starts as root then drops privs,
# it still fails to write to root:root /run/nut?
# Start upsmon as root:nut and make /run/nut root:nut.
# Maybe that will be enough to make thus STFU?
Group=nut

Bug#1000789: kiosk locked xfce4-panel causes ~/.xsession-errors to rapidly fill with error logspam

[Trent W. Buck]

Package: xfce4-panel
Version: 4.16.2-1
Severity: minor

https://sources.debian.org/src/xfce4-panel/4.16.3-1/plugins/launcher/launcher.c/?hl=593#L592-L667

This function copy-paste-edits
/usr/share/applications/foo.desktop
to
~/.config/xfce4/panel/launcher-NUMBER/TIMESTAMP.desktop

Then it updates xfconf property xfce4-panel/plugins/plugin-NUMBER/items[] to 
refer to the new location.

When the panel is locked (by ), the update fails.

In XFCE 4.10 (Debian 9), this happened once per login.
In XFCE 4.16 (Debian 11), this happens about once per second.
This is causing ~/.xsession-errors to fill up,
eventually filling $HOME and triggering EDQUOT/ENOSPC errors for all 
applications.

The rate of consumption is approximately 655 bytes per launcher item per second.
For a quicklaunch bar with 3 items, this is 161 MB/day.

A minimum file to reproduce is attached;
put it in world-readable 
/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml.

Please provide kiosk operators a way to opt-out of 
launcher_plugin_item_duplicate.
I would be happy with any of these:

1. xfce4-panel sees the xfconf channel is locked, and implicitly skips 
launcher_plugin_item_duplicate.
2. xfce4-panel checks for an explicit opt-out like 
xfce4-panel/plugins/plugin-1/duplicate-launcher=false.
3. launcher_plugin_item_duplicate is only tried once-per-login (not 
once-per-second), so .xsession-errors doesn't fill up.
4. xfconf/garcon warnings/assertions are suppressed, so .xsession-errors 
doesn't fill up.


The errors look like this on Debian 11:

(xfce4-panel:658): xfconf-WARNING **: 10:23:49.199: Failed to set property 
"xfce4-panel::/plugins/plugin-1/items": 
GDBus.Error:org.xfce.Xfconf.Error.PermissionDenied: Permission denied while 
modifying property "/plugins/plugin-1/items" on channel "xfce4-panel"

(xfce4-panel:658): garcon-CRITICAL **: 10:23:49.227: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): garcon-CRITICAL **: 10:23:49.228: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): garcon-CRITICAL **: 10:23:49.228: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): xfconf-WARNING **: 10:23:50.199: Failed to set property 
"xfce4-panel::/plugins/plugin-1/items": 
GDBus.Error:org.xfce.Xfconf.Error.PermissionDenied: Permission denied while 
modifying property "/plugins/plugin-1/items" on channel "xfce4-panel"

(xfce4-panel:658): garcon-CRITICAL **: 10:23:50.215: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): garcon-CRITICAL **: 10:23:50.215: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): garcon-CRITICAL **: 10:23:50.215: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): xfconf-WARNING **: 10:23:51.198: Failed to set property 
"xfce4-panel::/plugins/plugin-1/items": 
GDBus.Error:org.xfce.Xfconf.Error.PermissionDenied: Permission denied while 
modifying property "/plugins/plugin-1/items" on channel "xfce4-panel"

(xfce4-panel:658): garcon-CRITICAL **: 10:23:51.215: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): garcon-CRITICAL **: 10:23:51.215: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): garcon-CRITICAL **: 10:23:51.215: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): xfconf-WARNING **: 10:23:52.198: Failed to set property 
"xfce4-panel::/plugins/plugin-1/items": 
GDBus.Error:org.xfce.Xfconf.Error.PermissionDenied: Permission denied while 
modifying property "/plugins/plugin-1/items" on channel "xfce4-panel"

(xfce4-panel:658): garcon-CRITICAL **: 10:23:52.212: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): garcon-CRITICAL **: 10:23:52.213: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): garcon-CRITICAL **: 10:23:52.213: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): xfconf-WARNING **: 10:23:53.198: Failed to set property 
"xfce4-panel::/plugins/plugin-1/items": 
GDBus.Error:org.xfce.Xfconf.Error.PermissionDenied: Permission denied while 
modifying property "/plugins/plugin-1/items" on channel "xfce4-panel"

(xfce4-panel:658): garcon-CRITICAL **: 10:23:53.214: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): garcon-CRITICAL **: 10:23:53.214: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): garcon-CRITICAL **: 10:23:53.215: 
garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed

(xfce4-panel:658): xfconf-WARNING **: 

Bug#1000429: understand $LOCATE_PATH=~/.locatedb and do... something better

[Trent W. Buck]

Package: catfish
Version: 4.16.3-1
Severity: wishlist

catfish has a hard-coded path to mlocate's default database path:

https://codesearch.debian.net/search?q=pkg%3Acatfish+mlocate=1


https://sources.debian.org/src/catfish/4.16.3-1/catfish_lib/catfishconfig.py/#L32

mlocate and plocate support $LOCATE_PATH being a colon-separated list of paths 
to locate databases:


https://manpages.debian.org/bullseye-backports/plocate/plocate.1.en.html#ENVIRONMENT

I use this to run updatedb directly on the NAS, which is MUCH more efficient.
The commands are approximately this:

# on the file server, generate ~twb/.locatedb
sudo -H -u twb nice nocache updatedb --require-visibility=no --output 
.locatedb --database-root ~twb

# on the desktop, where ~twb is NFS and / is Debian Live
export LOCATE_PATH=~twb/.locatedb
locate foo
catfish

I think with Debian 11's catfish, it will ALWAYS pop up this alert:

The search database is more than 7 days old.  Update now?  [Update] [X]

I'm not sure EXACTLY what the correct semantics here should be, but
the current behaviour is definitely annoying me! :-)




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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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

Bug#1000353: Downgrade e2fsprogs from Depends to Recommends?

[Trent W. Buck]

Package: libblockdev-fs2
Version: 2.25-2
Severity: wishlist
File: /usr/lib/x86_64-linux-gnu/libbd_fs.so.2.0.0

libblockdev-fs2 Depends e2fsprogs because it calls dumpe2fs 
This was done per https://bugs.debian.org/887270
AFAICT there is a run-time check for this:

https://codesearch.debian.net/search?q=bd_fs_ext_is_tech_avail

In other words, dumpe2fs isn't found in $PATH, libblockdev-fs2 will
print an obvious error, instead of e.g. segfaulting.

Therefore, can you downgrade e2fsprogs from Depends to Recommends?

In a prison where USB keys are banned, this will
let me support trash:// (via "gvfs" package),
without shipping ext4 tools.

I can work around this with a dummy package, so
if there's a good counter-argument,
I can live with the status quo.


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 libblockdev-fs2:amd64 depends on:
ii  e2fsprogs  1.46.2-2
ii  libblkid1  2.36.1-8
ii  libblockdev-part-err2  2.25-2
ii  libblockdev-utils2 2.25-2
ii  libc6  2.31-13+deb11u2
ii  libglib2.0-0   2.66.8-1
ii  libmount1  2.36.1-8
ii  libparted-fs-resize0   3.4-1
ii  libparted2 3.4-1

libblockdev-fs2:amd64 recommends no packages.

libblockdev-fs2:amd64 suggests no packages.

-- no debconf information

Bug#409272: nfsmount: incompatible with nfsv4

[Trent W. Buck]

Trent W. Buck wrote:
>   3. A single mount(2) call also works!
> 
> It is quite annoying that we need *anything* special in userland, because
> a nfsvers=4.2,sec=sys mount requires only 2049/tcp (no other ports/services), 
> and
> the actual filesystem is in-kernel, so
> really all that should be needed is enough of a C program to issue a single 
> mount(2)!
> 
> As an experiment, I tried do compile in EXACTLY that, and it works for me:
> 
> root@main:~# >nfsmount.c printf '#include \n#include 
> \nint main() {exit(mount("10.0.2.100:/srv/netboot", "/mnt", 
> "nfs", 0, "vers=4.2,addr=10.0.2.100,clientaddr=10.0.2.15"));}'
> root@main:~# klcc -o nfsmount nfsmount.c
> root@main:~# ./nfsmount; echo $?
> ./nfsmount; echo $?
> Nov 17 10:11:31 main.lan kernel: process '/root/nfsmount' started with 
> executable stack
> 0
> 
> This is pretty narrow in scope and is probably achievable.
> It allows you to boot off NFSv4, without putting glibc into the initrd.

I had a go at actually packaging this (attached), but
it turns out to be slightly harder than I thought (see comments in mount.nfs.c).
I don't have time to pursue this further.


prisonpc-nfs4-client_11.0.tar.xz
Description: application/xz

Bug#409272: nfsmount: incompatible with nfsv4

[Trent W. Buck]

Short version:

  1. nfsmount(8klibc) is still explicitly broken for NFSv4.
  2. mount.nfs(8nfs-utils) works in the ramdisk.
  3. A single mount(2) call also works!


Boring detailed version follows.

John Goerzen wrote:
> nfsmount is incapable of mounting NFSv4 filesystems.  It seems to have
> support for v3 and maybe v2, but not v4.

This is still the case in Debian 11, klibc-utils=2.0.8-6.1.
A workaround is to copy nfs-utils 1.3's mount.nfs into the initrd:

/usr/share/initramfs-tools/hooks/zz-nfs4:

#!/bin/sh
[ prereqs = "$1" ] && exit
. /usr/share/initramfs-tools/hook-functions
copy_exec /sbin/mount.nfs /bin/nfsmount

Here are some specific errors I saw, with an NFSv4-only server on 10.0.2.100 
port 2049/tcp

# Normal nfs-common=1:1.3.4-6 works fine
root@main:~# mount.nfs 10.0.2.100:/srv/netboot/images /mnt
root@main:~# umount /mnt

root@main:~# /usr/lib/klibc/bin/nfsmount -o nfsvers=4.2,sec=sys 
10.0.2.100:/srv/netboot/images /mnt
4.2: invalid value for nfsvers

https://sources.debian.org/src/klibc/2.0.8-6.1/usr/kinit/nfsmount/main.c/#L145

root@main:~# /usr/lib/klibc/bin/nfsmount -o nfsvers=4,sec=sys 
10.0.2.100:/srv/netboot/images /mnt
/usr/lib/klibc/bin/nfsmount: bad option 'sec'

# This hangs because NFSv3 ports (inc. portmap) are not allowed AT ALL by 
10.0.2.100.
# klibc-utils is hard-coded to *EXPLICITLY* ask for a NFSv3 mount.
root@main:~# /usr/lib/klibc/bin/nfsmount 10.0.2.100:/srv/netboot/images /mnt
connect: Connection timed out



It is quite annoying that we need *anything* special in userland, because
a nfsvers=4.2,sec=sys mount requires only 2049/tcp (no other ports/services), 
and
the actual filesystem is in-kernel, so
really all that should be needed is enough of a C program to issue a single 
mount(2)!

As an experiment, I tried do compile in EXACTLY that, and it works for me:

root@main:~# apt install build-essential strace
root@main:~# strace -s9 -emount mount.nfs 10.0.2.100:/srv/netboot /mnt
mount("10.0.2.100:/srv/netboot", "/mnt", "nfs", 0, 
"vers=4.2,addr=10.0.2.100,clientaddr=10.0.2.15") = 0
root@main:~# umount /mnt

root@main:~# journalctl -kfn0 &
root@main:~# cc -x c - <<< 'int main() 
{exit(mount("10.0.2.100:/srv/netboot", "/mnt", "nfs", 0, 
"vers=4.2,addr=10.0.2.100,clientaddr=10.0.2.15"));}' && ./a.out; echo $?
: In function ‘main’:
:1:13: warning: implicit declaration of function ‘exit’ 
[-Wimplicit-function-declaration]
:1:13: warning: incompatible implicit declaration of built-in 
function ‘exit’
:1: note: include ‘’ or provide a declaration of ‘exit’
:1:18: warning: implicit declaration of function ‘mount’ 
[-Wimplicit-function-declaration]
0
root@main:~# umount /mnt

Can I do the same thing with klibc instead of glibc?
Well, the compiler wrapper is a bit confused...

root@main:~# apt install libklibc-dev
root@main:~# klcc -x c - <<< 'int main() 
{exit(mount("10.0.2.100:/srv/netboot", "/mnt", "nfs", 0, 
"vers=4.2,addr=10.0.2.100,clientaddr=10.0.2.15"));}' && ./a.out; echo $?
nfsmount.c printf '#include \n#include 
\nint main() {exit(mount("10.0.2.100:/srv/netboot", "/mnt", "nfs", 
0, "vers=4.2,addr=10.0.2.100,clientaddr=10.0.2.15"));}'
root@main:~# klcc -o nfsmount nfsmount.c
root@main:~# ./nfsmount; echo $?
./nfsmount; echo $?
Nov 17 10:11:31 main.lan kernel: process '/root/nfsmount' started with 
executable stack
0

So for current-generation NFS, without kerberos, all we *REALLY* need
is something to getopts from

nfsmount -t nfs -o nfsvers=4.2,sec=sys example.com:/srv /srv

into

mount("example.com:/srv", "/srv", 0, "nfsvers=4.2,sec=sys");

This is pretty narrow in scope and is probably achievable.
It allows you to boot off NFSv4, without putting glibc into the initrd.

Bug#999417: Blank line in plymouthd.conf silently breaks it

[Trent W. Buck]

PS: I reran my test script with "sid" instead of "bullseye", and
the problem still exists in sid.  It also includes lsinitramfs output.

Trent W. Buck wrote:
> > I just tried now with plymouth version 0.9.5+git20211018-1, after adding a
> > white space in the configuration file and regenerating the initramfs (with
> > update-initramfs -u) I can see the theme in initramfs (lsinitramfs) and the
> > bgrt theme is properly used.
> > 
> > How did you regenerate the initramfs? Does lsinitramfs show you the theme
> > files inside the initramfs? Could you try with 0.9.5+git20211018-1 and see
> > if it makes a difference?
> 
> OK here's a script (attached) that should reliably show
> 1) working behaviour; then
> 2) failing behaviour.


plymouth-issue-test.sh
Description: Bourne shell script
bash5$ /home/twb/Desktop/bootstrap2020/plymouth-issue-test.sh
#!/bin/bash -v

build=(
mmdebstrap sid tmp.squashfs
--aptopt='Acquire::http::Proxy "http://localhost:3142;'
--include=plymouth-themes,linux-image-generic,init,live-boot,pigz
--dpkgopt=force-unsafe-io
--dpkgopt=force-confold # dpkg, don't pause because I edited 
plymouth.conf before you
--essential-hook='mkdir -p $1/etc/plymouth'
--essential-hook='copy-in plymouthd.conf /etc/plymouth/'
--customize-hook='download /vmlinuz vmlinuz'
--customize-hook='download /initrd.img initrd.img'
--customize-hook='chroot $1 dpkg-query -W plymouth plymouth-themes'
--customize-hook='chroot $1 lsinitramfs -l /initrd.img | grep plymouth'
)
test=(
kvm
-m 1024 # without this, not enough ram to start the 
initrd!
-hda tmp.squashfs
-kernel vmlinuz
-initrd initrd.img
-append 'splash boot=live plainroot root=/dev/sda'
)

# With no \n\n, plymouthd shows correct spinner animation on black background 
(bgrt inherits from spinner).
printf '[Daemon]\nTheme=bgrt\n' >plymouthd.conf && "${build[@]}" && "${test[@]}"
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: squashfs
I: using /tmp/mmdebstrap.0JUC5aHB_o as tempdir
W: tar2sqfs does not support extended attributes from the 'system' namespace
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: running --essential-hook in shell: sh -c 'mkdir -p $1/etc/plymouth' exec 
/tmp/mmdebstrap.0JUC5aHB_o
I: running special hook: copy-in plymouthd.conf /etc/plymouth/
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
done
done
I: running special hook: download /vmlinuz vmlinuz
I: running special hook: download /initrd.img initrd.img
I: running --customize-hook in shell: sh -c 'chroot $1 dpkg-query -W plymouth 
plymouth-themes' exec /tmp/mmdebstrap.0JUC5aHB_o
plymouth0.9.5+git20211018-1
plymouth-themes 0.9.5+git20211018-1
I: running --customize-hook in shell: sh -c 'chroot $1 lsinitramfs -l 
/initrd.img | grep plymouth' exec /tmp/mmdebstrap.0JUC5aHB_o
drwxr-xr-x   2 root root0 Nov 15 05:52 etc/plymouth
-rw-r--r--   1 1000 1000   20 Nov 15 05:51 
etc/plymouth/plymouthd.conf
-rwxr-xr-x   1 root root  151 Nov 10 15:45 
scripts/init-bottom/plymouth
-rwxr-xr-x   1 root root  472 Nov 10 15:45 
scripts/init-premount/plymouth
-rwxr-xr-x   1 root root  155 Nov 10 15:45 scripts/panic/plymouth
-rwxr-xr-x   1 root root47880 Nov 10 15:45 usr/bin/plymouth
drwxr-xr-x   3 root root0 Nov 15 05:52 
usr/lib/x86_64-linux-gnu/plymouth
-rw-r--r--   1 root root18944 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/details.so
-rw-r--r--   1 root root14664 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/label.so
drwxr-xr-x   2 root root0 Nov 15 05:52 
usr/lib/x86_64-linux-gnu/plymouth/renderers
-rw-r--r--   1 root root60416 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/renderers/drm.so
-rw-r--r--   1 root root35632 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/renderers/frame-buffer.so
-rw-r--r--   1 root root23200 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/text.so
-rw-r--r--   1 root root69032 Nov 10 15:45 
usr/lib/x86_64-linux-gnu/plymouth/two-step.so
drwxr-xr-x   2 root root0 Nov 15 05:52 usr/libexec/plymouth
-rwxr-xr-x   1 root root14600 Nov 10 15:45 
usr/libexec/plymouth/plymouthd-fd-escrow
-rwxr-xr-x   1 root root   151584 Nov 10 15:45 usr/sbin/plymouthd
drwxr-xr-x   3 root root0 Nov 15 05:52 usr/share/plymouth
-rw-r--r--   1 root root 5834 Nov 15 05:52 
usr/share/plymouth/debian-logo.png
-rw-r--r--   1 root root  139 Nov 10 15:45 
usr/share/plymouth/plym

Bug#999417: Blank line in plymouthd.conf silently breaks it

[Trent W. Buck]

Laurent Bigonville wrote:
> On Thu, 11 Nov 2021 06:24:53 +1100 "Trent W. Buck" 
> wrote:
> 
> > See attached example files.
> 
> Could you please explain a bit more what's not working?

Sorry, I thought my report included more information than it did.
This is the actual commit that fixed it for me:

https://github.com/cyberitsolutions/bootstrap2020/commit/af75998

The behaviour I see is that plymouth shows a splash screen, but
it uses the fallback "text" theme, with the "█ █ █" three rectangles,
with a spinner on a Tango dark grey background (#2E3436).

When plymouthd.conf contains no \n\n sequences, I see the correct bgrt theme,
with an animated spinner (white circle on black background).

> I just tried now with plymouth version 0.9.5+git20211018-1, after adding a
> white space in the configuration file and regenerating the initramfs (with
> update-initramfs -u) I can see the theme in initramfs (lsinitramfs) and the
> bgrt theme is properly used.
> 
> How did you regenerate the initramfs? Does lsinitramfs show you the theme
> files inside the initramfs? Could you try with 0.9.5+git20211018-1 and see
> if it makes a difference?

Let me see if I make a full test recipe... hrm, not easily.
I will instead include the "before" and "after" ramdisks and kernel.
...hrm, they're 40MB each, not really suitable for email.

The actual images are identical except for the plymouthd.conf and some 
fontconfig cache files.
That suggests the problem is inside the plymouthd C code itself.

OK here's a script (attached) that should reliably show
1) working behaviour; then
2) failing behaviour.


plymouth-issue-test.sh
Description: Bourne shell script

Bug#999417: Blank line in plymouthd.conf silently breaks it

[Trent W. Buck]

Package: plymouth
Version: 0.9.5-3
Severity: normal

See attached example files.


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

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
#  I don't care about PrisonPC branding on inmate desktops.
#   The only branding I care about is in ppcadm.
#
# The Debian 11 default splash is loud and Debian-y:
#   https://wiki.debian.org/DebianArt/Themes/Homeworld
#
# Change the default to match Windows 10 style.
# That is:
#   * black background
#   * a simple spinner animation
#   * if present, a centered logo, from
# /sys/firmware/acpi/tables/BGRT.
#
# This makes the transition from EFI to plymouth "seamless".
#
# WARNING: if this file contains any blank lines,
#  it will silently fail to include the correct theme in the ramdisk,
#  causing a de facto Theme=text behaviour.
[Daemon]
Theme=bgrt
#  I don't care about PrisonPC branding on inmate desktops.
#   The only branding I care about is in ppcadm.

# The Debian 11 default splash is loud and Debian-y:
#   https://wiki.debian.org/DebianArt/Themes/Homeworld
#
# Change the default to match Windows 10 style.
# That is:
#   * black background
#   * a simple spinner animation
#   * if present, a centered logo, from
# /sys/firmware/acpi/tables/BGRT.
#
# This makes the transition from EFI to plymouth "seamless".

[Daemon]
Theme=bgrt

Bug#998444: apt source --target-release=/./ is weird

[Trent W. Buck]

Package: apt
Version: 2.2.4
Severity: minor

On a system with bullseye and bullseye-backports,
I wanted to source the latest vlc apt had anywhere (backports or not).
That is, temporarily override any pinning.

$ apt source   -t/./ vlc # gives confusing error (see below)
$ apt download -t/./ vlc # works as expected

The expected behaviour is that --target-release works the same for "apt source" 
as it does for "apt download" (or "apt install").


20:40  twb: So source does not support regular expressions or glob 
patterns in -t, APT::Default-Release
20:40  only exact release names
20:41  twb: presumably nobody noticed that it did its own matching :)
20:41  OK.  If that's known/expected behaviour, then it's not a bug
20:42  i think it's a bug because it's an oversight and clashes with 
the release notes
20:42  which suggested that default-release 
"/^bullseye(-security|-updates)$/" works as "bullseye" would have before; but 
it breaks source


Here is full transcript for bullseye:

bash5$ mmdebstrap bullseye /dev/null --customize-hook='chroot $1 apt 
download -t/./ vlc' --customize-hook='chroot $1 apt source -t/./ vlc'  'deb 
http://deb.debian.org/debian bullseye main' 'deb-src 
http://deb.debian.org/debian bullseye main'
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.FcuegMKvYL as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
done
--> I: running --customize-hook in shell: sh -c 'chroot $1 apt download 
-t/./ vlc' exec /tmp/mmdebstrap.FcuegMKvYL
--> Get:1 http://deb.debian.org/debian bullseye/main amd64 vlc amd64 
3.0.16-1 [144 kB]
Fetched 144 kB in 0s (1526 kB/s)
W: Download is performed unsandboxed as root as file 
'//vlc_3.0.16-1_amd64.deb' couldn't be accessed by user '_apt'. - 
pkgAcquire::Run (13: Permission denied)
--> I: running --customize-hook in shell: sh -c 'chroot $1 apt source -t/./ 
vlc' exec /tmp/mmdebstrap.FcuegMKvYL
--> Reading package lists... Done
E: Unable to find a source package for vlc
E: run_chroot failed: E: command failed: chroot $1 apt source -t/./ vlc
W: listening on child socket failed: 
I: removing tempdir /tmp/mmdebstrap.FcuegMKvYL...


Here is a full transcript for sid:

bash5$ mmdebstrap unstable /dev/null --customize-hook='chroot $1 apt 
download -t/./ vlc' --customize-hook='chroot $1 apt source -t/./ vlc'  'deb 
http://deb.debian.org/debian unstable main' 'deb-src 
http://deb.debian.org/debian unstable main'
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.nTcELCiBZM as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
done
--> I: running --customize-hook in shell: sh -c 'chroot $1 apt download 
-t/./ vlc' exec /tmp/mmdebstrap.nTcELCiBZM
--> Get:1 http://deb.debian.org/debian unstable/main amd64 vlc amd64 
3.0.16-1+b4 [145 kB]
Fetched 145 kB in 0s (1443 kB/s)
W: Download is performed unsandboxed as root as file 
'//vlc_3.0.16-1+b4_amd64.deb' couldn't be accessed by user '_apt'. - 
pkgAcquire::Run (13: Permission denied)
--> I: running --customize-hook in shell: sh -c 'chroot $1 apt source -t/./ 
vlc' exec /tmp/mmdebstrap.nTcELCiBZM
--> Reading package lists... Done
--> E: Can not find version '3.0.16-1' of package 'vlc'
--> E: Unable to find a source package for vlc
E: run_chroot failed: E: command failed: chroot $1 apt source -t/./ vlc
W: listening on child socket failed: 
I: removing tempdir /tmp/mmdebstrap.nTcELCiBZM...
bash5$

Bug#997852: Should dh_systemd_enable --no-enable create a systemd.preset? (fix ssh.socket)

[Trent W. Buck]

I noticed some other things being unexpected enabled by preset-all, e.g.
msmtpd.service, systemd-networkd.socket, reboot.target.

I think this shows relevant packages:


https://codesearch.debian.net/search?q=dh_.*systemd.*--no-enable=0=29=1

$ curl -s 
https://codesearch.debian.net/results/460eb7b7b3635bc8/packages.txt | sort | fmt
2ping 389-ds-base acmetool acpid amavisd-new anope aprx argonaut
argus-clients balboa bdii beanstalkd bind9 bit-babbler bitlbee
booth btrfsmaintenance buildbot burp burrow canid chasquid
conserver consul corosync-qdevice csync2 davmail ddclient debhelper
dhcpy6d direwolf dogtag-pki dovecot drbd-utils fetch-crl fever fio
freeipa fwknop game-data-packager gamemode gfarm globus-gatekeeper
globus-gridftp-server globus-scheduler-event-generator glusterfs
golang-github-containernetworking-plugins gpsd graphite-carbon hdapsd
hylafax ifupdown init-system-helpers interimap ipmitool ipmiutil iwd
jupyter-notebook knockd libcircle-be-perl libosmo-sccp linux lirc
lizardfs logdata-anomaly-miner mailavenger mailgraph mariadb-10.5
mediawiki minissdpd miniupnpd moosefs mopidy mpd msmtp myproxy natlog
netscript-2.4 nextepc nftables nomad nordugrid-arc onak open-iscsi
openbgpd openssh osmo-bsc osmo-bts osmo-ggsn osmo-hlr osmo-iuh
osmo-mgw osmo-msc osmo-pcu osmo-sgsn osmo-trx packagekit pagure pgcluu
phosh pmacct postfwd powertop pptpd prelude-correlator prelude-lml
prelude-manager proftpd-dfsg public-inbox puppet qemu radicale rauc rsync
rtkit rygel sane-backends sanlock sbws slinkwatch sniproxy spamassassin
speech-dispatcher speech-dispatcher-contrib srslte stenographer syncplay
systemd-bootchart tcpcrypt teeworlds thinkfan trojan tryton-server
umtp-responder upower vanguards vdirsyncer voms w1retap wesnoth-1.14
xpra xscreensaver ypbind-mt ypserv zeroc-ice znc zoneminder

That suggests mariadb@.service would be affected, but
testing indicates otherwise:

$ mmdebstrap sid /dev/null --include=init,mariadb-server 
--customize-hook='systemctl --root=$1 preset-all' --logfile=tmp.log
$ grep mariadb tmp.log
[no matches]

So I dunno!

Bug#997852: Should dh_systemd_enable --no-enable create a systemd.preset? (fix ssh.socket)

[Trent W. Buck]

Package: debhelper
Version: 13.3.4
Severity: wishlist
File: /usr/bin/dh_systemd_enable

This is an obscure edge-case for systemd.
I am not an expert.  What I'm proposing might be very silly.
Probably the approriate debian-systemd ML should be CC'd.


Background: what is systemd.preset?
===
You know how when you install a new .service,
you typically do "systemctl enable frobozzd.service",
which runs [Install] WantedBy=multi-user.target?

Well historically,
Debian policy was "if you install frobozzd, it starts right away with sensible 
defaults", but
RHEL policy was "if you install frobozzd, it doesn't start until YOU configure 
& enable it".

To avoid fights over defaults,
systemd has a layer of middleware to opt in/out of "enable frobozzd".
See https://manpages.debian.org/systemd.preset
But for various reasons it isn't really used much.

It is used automatically by systemd "first boot" mode, i.e. when you boot with 
no /etc/machine-id.
It is used manually by calling "systemctl --root=/path/to/chroot preset-all".


Specific issue: openssh
===
The openssh rules file does this:

override_dh_systemd_enable:
dh_systemd_enable -popenssh-server --name ssh ssh.service
dh_systemd_enable -popenssh-server --name ssh --no-enable ssh.socket

But systemd preset doesn't "see" this, so BOTH units are enabled,
which causes boot-time failures (both bind to *:22 by default).
Here's a minimum recipe to reproduce:

bash5$ mmdebstrap sid /dev/null --include=init,openssh-server 
--customize-hook='systemctl --root=$1 preset-all'
⋮
I: running --customize-hook in shell: sh -c 'systemctl --root=$1 
preset-all' exec /tmp/mmdebstrap.E3rs3TFVsO
⋮
Created symlink 
/tmp/mmdebstrap.E3rs3TFVsO/etc/systemd/system/sockets.target.wants/ssh.socket → 
/usr/lib/systemd/system/ssh.socket.
⋮
I: success in 24.9741 seconds

I think the easy workaround is that "dh_enable_systemd --no-enable" should 
create something like this:

/lib/systemd/system-preset/50-.preset:

# auto-generated by debhelper
disable 

A sysadmin can still override this in /etc/, as is normal for systemd config 
files.

There may be other implications I haven't considered, though!



-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 debhelper depends on:
ii  autotools-dev20180224.1+nmu1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.12.0-1
ii  dpkg 1.20.9
ii  dpkg-dev 1.20.9
ii  dwz  0.13+20210201-1
ii  file 1:5.39-3
ii  libdebhelper-perl13.3.4
ii  libdpkg-perl 1.20.9
ii  man-db   2.9.4-2
ii  perl 5.32.1-4+deb11u1
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#996927: Drop NSCD_SOCKET_OLD and harden systemd unit?

[Trent W. Buck]

Trent W. Buck wrote:
> RuntimeDirectory=unscd

That's a typo, it should be "RuntimeDirectory=nscd".
Testing didn't catch it until I did a reboot, because
the non-systemd doesn't remove /run/nscd when unscd stops.

Bug#892730: nslcd: Please add systemd .service file

[Trent W. Buck]

PS: the hardening bit also works as a dropin,
i.e. you can put it into /etc/systemd/system/nslcd.service.d/hardening.conf
and the rest of the unit remains auto-generated from /etc/init.d/nslcd.

Trent W. Buck wrote:
> # nslcd listens to /run/nslcd/socket and creates /run/nslcd/nslcd.pid.
> # We can tell systemd about this.
> RuntimeDirectory=nslcd
> WorkingDirectory=/run/nslcd
> 
> 
> # Additional security lockdown (optional).
> # $ systemd-analyze security nslcd:
> # → Overall exposure level for nslcd.service: 1.2 OK 
> [Service]
> CapabilityBoundingSet=
> RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
> DevicePolicy=closed
> NoNewPrivileges=yes
> PrivateDevices=yes
> PrivateTmp=yes
> PrivateUsers=yes
> ProtectClock=yes
> ProtectControlGroups=yes
> ProtectHome=yes
> ProtectKernelLogs=yes
> ProtectKernelModules=yes
> ProtectKernelTunables=yes
> ProtectProc=invisible
> ProtectSystem=strict
> RestrictSUIDSGID=yes
> SystemCallArchitectures=native
> SystemCallFilter=@system-service
> # We can't drop @privileged because we fail with:
> #   nslcd: wait_for_response(): read_response() returned 0 (expected 4)
> #   nslcd: unable to daemonize: No data available
> #SystemCallFilter=~@privileged
> SystemCallFilter=~@resources
> RestrictNamespaces=yes
> RestrictRealtime=yes
> LockPersonality=yes
> MemoryDenyWriteExecute=yes
> RemoveIPC=yes
> UMask=0077
> ProtectHostname=yes
> ProcSubset=pid