Bug#1055991: /usr/share/autofs/conffiles/auto.net: /etc/auto.net comments for nfsv4 are unclear

[Sam Morris]

Package: autofs
Version: 5.1.8-2+deb12u2
Severity: minor
File: /usr/share/autofs/conffiles/auto.net

Upstream /etc/auto.net looks like this:

  # add "nosymlink" here if you want to suppress symlinking local filesystems
  # add "nonstrict" to make it OK for some filesystems to not mount
  opts="-fstype=nfs,hard,nodev,nosuid"

15auto_net_nfs4.patch adds comments giving some nfsv4 advice:

   # add "nosymlink" here if you want to suppress symlinking local filesystems
   # add "nonstrict" to make it OK for some filesystems to not mount
  +# choose one of the two lines below depending on the NFS version in your
  +# environment
   opts="-fstype=nfs,hard,nodev,nosuid"
  +#opts="-fstype=nfs4,hard,nodev,nosuid,async"

Then fix-nfs4-mounts-in-auto-net.patch removes the the lints that set
opts, but leaves the comment in:

  --- a/samples/auto.net
  +++ b/samples/auto.net
  @@ -11,29 +11,44 @@
   # add "nonstrict" to make it OK for some filesystems to not mount
   # choose one of the two lines below depending on the NFS version in your
   # environment
  -opts="-fstype=nfs,hard,nodev,nosuid"
  -#opts="-fstype=nfs4,hard,nodev,nosuid,async"

As a result I was left scratching my head for a while wondering how to
use /etc/auto.net with nfsv4.

I suggest removing the comment block entirely and replacing it with
something like:

  # To use the traditional NFS MOUNT protocol for obtaining the NFS
  # export list, leave MOUNT_NFS_DEFAULT_PROTOCOL unset or set it to
  # "3". To use the NFSv4 pseudo-filesystem, set MOUNT_DEFAULT_PROTOCOL
  # to "4". The parameter may be set within /etc/default/autofs.

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable-security'), (550, 
'stable'), (530, 'testing'), (520, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages autofs depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u3
ii  libnsl2  1.3.0-2
ii  libtirpc31.3.3+ds-1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  ucf  3.0043+nmu1

Versions of packages autofs recommends:
ii  e2fsprogs   1.47.0-2
ii  kmod30+20221128-1
ii  nfs-common  1:2.6.2-4

autofs suggests no packages.

-- no debconf information

Bug#1052392: libpam-sss: Please ship a PAM config file for pam_sss_gss.so

[Sam Morris]

Package: libpam-sss
Version: 2.8.2-4
Severity: wishlist

Here's the config file I am using:

$ cat /usr/share/pam-configs/sss-gss 
Name: Authenticate if the user can obtain a valid Kerberos ticket for the 
local host
Default: yes
Priority: 512

Auth-Type: Primary
Auth:
[success=end default=ignore]pam_sss_gss.so
Auth-Initial:
[success=end default=ignore]pam_sss_gss.so

However it can't be added to the package yet because it will break
authentication for non-local users (beacuse we use the 'use_first_pass'
option with pam_sss.so when it's not the initial module, so a non-local
user is not able to log in when pam_sss.so is not the initial module and
no prior modules stashed a password for it to consume). 

For the time being we need 'use_first_pass' so that non-local users
don't get prompted by _both_ pam.unix.so and pam_sss.so.

Ideally pam_sss.so would have a 'try_first_pass' option which would
unblock us from shipping an sss-gss pam config. I've filed an RFE here:
.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable-security'), (550, 
'stable'), (530, 'testing'), (520, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages libpam-sss depends on:
ii  libc6 2.36-9+deb12u1
ii  libgssapi-krb5-2  1.20.1-2
ii  libpam-pwquality  1.4.5-1+b1
ii  libpam-runtime1.5.2-6
ii  libpam0g  1.5.2-6

Versions of packages libpam-sss recommends:
ii  sssd  2.8.2-4

libpam-sss suggests no packages.

-- no debconf information

Bug#1050346: gnome-control-center: Segfault when editing properties of Wi-Fi connection

[Sam Morris]

Package: gnome-control-center
Version: 1:43.6-2~deb12u1
Severity: normal
X-Debbugs-Cc: s...@robots.org.uk

When I try to edit a particular Wi-Fi connection I get a segfault.

(gdb) r
Starting program: /usr/bin/gnome-control-center 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x705ff6c0 (LWP 1746643)]
[New Thread 0x7fffefdfe6c0 (LWP 1746644)]
[New Thread 0x7fffef5fd6c0 (LWP 1746645)]
[Thread 0x7fffef5fd6c0 (LWP 1746645) exited]
[New Thread 0x7fffef5fd6c0 (LWP 1746652)]
[New Thread 0x7fffec8be6c0 (LWP 1746653)]
[New Thread 0x7fffd6bff6c0 (LWP 1746654)]
[New Thread 0x7fffd63fe6c0 (LWP 1746655)]
[Thread 0x7fffd63fe6c0 (LWP 1746655) exited]
[Thread 0x7fffd6bff6c0 (LWP 1746654) exited]
[Thread 0x7fffec8be6c0 (LWP 1746653) exited]
[Thread 0x7fffef5fd6c0 (LWP 1746652) exited]
[New Thread 0x7fffef5fd6c0 (LWP 1746657)]
[New Thread 0x7fffd63fe6c0 (LWP 1746658)]
[New Thread 0x7fffd6bff6c0 (LWP 1746659)]
[New Thread 0x7fffec8be6c0 (LWP 1746660)]
[New Thread 0x7fffedfcf6c0 (LWP 1746661)]
[New Thread 0x7fffed7556c0 (LWP 1746662)]
[New Thread 0x7fffd5bfd6c0 (LWP 1746664)]
[New Thread 0x7fffd53fc6c0 (LWP 1746665)]
[New Thread 0x7fffd4bfb6c0 (LWP 1746669)]
[New Thread 0x7fffc57ff6c0 (LWP 1746670)]
[New Thread 0x7fffc4ffe6c0 (LWP 1746671)]
[New Thread 0x7fffa7fff6c0 (LWP 1746672)]
[New Thread 0x7fffa77fe6c0 (LWP 1746673)]
[New Thread 0x7fffa6ffd6c0 (LWP 1746674)]
[New Thread 0x7fffa67fc6c0 (LWP 1746675)]
[New Thread 0x7fffa5ffb6c0 (LWP 1746676)]
[New Thread 0x7fffa57fa6c0 (LWP 1746677)]
[New Thread 0x7fffa4ff96c0 (LWP 1746681)]
[New Thread 0x7fff87fff6c0 (LWP 1746682)]
[Thread 0x7fffa4ff96c0 (LWP 1746681) exited]
[New Thread 0x7fffa4ff96c0 (LWP 1746683)]
[New Thread 0x7fff877fe6c0 (LWP 1746684)]
[Thread 0x7fff87fff6c0 (LWP 1746682) exited]
[Thread 0x7fffa4ff96c0 (LWP 1746683) exited]
[Thread 0x7fff877fe6c0 (LWP 1746684) exited]
[New Thread 0x7fff877fe6c0 (LWP 1746685)]
[Thread 0x7fff877fe6c0 (LWP 1746685) exited]
[New Thread 0x7fff877fe6c0 (LWP 1746686)]
[Thread 0x7fff877fe6c0 (LWP 1746686) exited]
[Thread 0x7fffc4ffe6c0 (LWP 1746671) exited]
[Thread 0x7fffa67fc6c0 (LWP 1746675) exited]
[Thread 0x7fffa77fe6c0 (LWP 1746673) exited]
[Thread 0x7fffa6ffd6c0 (LWP 1746674) exited]
[Thread 0x7fffa7fff6c0 (LWP 1746672) exited]
[Thread 0x7fffd4bfb6c0 (LWP 1746669) exited]
[Thread 0x7fffd53fc6c0 (LWP 1746665) exited]
[Thread 0x7fffc57ff6c0 (LWP 1746670) exited]
[Thread 0x7fffa5ffb6c0 (LWP 1746676) exited]
[New Thread 0x7fffa5ffb6c0 (LWP 1746725)]
[New Thread 0x7fffc57ff6c0 (LWP 1746726)]
[New Thread 0x7fffd53fc6c0 (LWP 1746727)]
[Thread 0x7fffc57ff6c0 (LWP 1746726) exited]
[Thread 0x7fffd53fc6c0 (LWP 1746727) exited]
[New Thread 0x7fffd53fc6c0 (LWP 1746731)]

(gnome-control-center:1746640): Gtk-CRITICAL **: 15:42:13.238: 
gtk_file_chooser_set_file: assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed

(gnome-control-center:1746640): Gtk-CRITICAL **: 15:42:13.404: 
gtk_file_chooser_set_file: assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed
[New Thread 0x7fffc57ff6c0 (LWP 1746733)]
[New Thread 0x7fffd4bfb6c0 (LWP 1746734)]
[New Thread 0x7fffa7fff6c0 (LWP 1746735)]
[New Thread 0x7fffa77fe6c0 (LWP 1746736)]
[New Thread 0x7fffa6ffd6c0 (LWP 1746737)]
[New Thread 0x7fffa67fc6c0 (LWP 1746738)]
[New Thread 0x7fffa4ff96c0 (LWP 1746739)]
[New Thread 0x7fff87fff6c0 (LWP 1746740)]
[New Thread 0x7fff877fe6c0 (LWP 1746750)]
[Thread 0x7fffd4bfb6c0 (LWP 1746734) exited]
[Thread 0x7fffa6ffd6c0 (LWP 1746737) exited]
[Thread 0x7fffa77fe6c0 (LWP 1746736) exited]
[Thread 0x7fff87fff6c0 (LWP 1746740) exited]
[Thread 0x7fffa4ff96c0 (LWP 1746739) exited]
[Thread 0x7fffa67fc6c0 (LWP 1746738) exited]
[Thread 0x7fffed7556c0 (LWP 1746662) exited]
[Thread 0x7fffa7fff6c0 (LWP 1746735) exited]
[Thread 0x7fffd53fc6c0 (LWP 1746731) exited]

(gnome-control-center:1746640): Gtk-WARNING **: 15:42:15.216: A floating object 
was finalized. This means that someone
called g_object_unref() on an object that had only a floating
reference; the initial floating reference is not owned by anyone
and must be removed with g_object_ref_sink().

(gnome-control-center:1746640): Gtk-WARNING **: 15:42:15.220: A floating object 
was finalized. This means that someone
called g_object_unref() on an object that had only a floating
reference; the initial floating reference is not owned by anyone
and must be removed with g_object_ref_sink().

(gnome-control-center:1746640): Gtk-WARNING **: 15:42:15.221: A floating object 
was finalized. This means that someone
called g_object_unref() on an object that had only a floating
reference; the initial floating reference is not owned by anyone
and must be removed with g_object_ref_sink().

(gnome-control-center:1746640): Gtk-WARNING **: 15:42:15.222: A floating object 
was finalized. This means that someone
called g_object_unref() on an object that had only a floating
reference; the initial floating reference is not owned by anyone
and must be removed with 

Bug#984879: podman does not work on Debian with selinux loaded

[Sam Morris]

On Wed, Jun 21, 2023 at 06:04:14PM +0100, Sam Morris wrote:
> On Wed, Jun 21, 2023 at 05:28:48PM +0100, Sam Morris wrote:
> > refpolicy has a 'container' module that appears to work, it's just not
> > built by default.
> 
> BTW, the existance of /etc/selinux/default/contexts/lxc_contexts is what
> causes Podman to try to label containers. Which prevents it from being
> able to start any container, since the container module is not
> included in selinux-policy-default.
> 
> https://sources.debian.org/src/golang-github-opencontainers-selinux/1.10.0+ds1-1/go-selinux/selinux_linux.go/?hl=943#L943
> 
> > Any chance that module could be built by default?
> 
> So if the module is not suitable to be built by default, please remove
> the `lxc_contexts` file; I have the feeling it might also cause problems
> with libvirt and k8s...

Actually this file should remain until Debian packages container-selinux
(which ships /usr/share/containers/selinux/contexts which replaces
/etc/selinux/default/contexts/lxc_contexts; without either file, Podman
etc. won't try to label their containers).

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#704180: p11-kit: provide package that diverts libnssckbi.so and replaces it with p11-kit-trust.so

[Sam Morris]

On Tue, Jun 27, 2023 at 04:33:06PM +0100, Sam Morris wrote:
> On Fri, Mar 03, 2023 at 02:43:48PM +0000, Sam Morris wrote:
> > Commands to divert the original file and replace it with a symlink:
> > 
> >   # dpkg-divert --add --rename /usr/lib/x86_64-linux-gnu/libnssckbi.so
> >   # ln -sr /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so 
> > /usr/lib/x86_64-linux-gnu/libnssckbi.so
> 
> Unfortunately this no longer works reliably. Since libnssckbi.so is now
> found in /usr/lib/x86_64-linux-gnu, as soon any library package is
> installer or upgraded, ldconfig will be run, which will replace
> the symlink.

Workaround: divert libnssckbi.so to a location outside of
/usr/lib/x86_64-linux-gnu, like so:

# dpkg-divert --local --rename --divert 
/usr/lib.x86_64-linux-gnu.libnssckbi.so.diverted --add 
/usr/lib/x86_64-linux-gnu/libnssckbi.so
Adding 'local diversion of /usr/lib/x86_64-linux-gnu/libnssckbi.so to 
/usr/lib.x86_64-linux-gnu.libnssckbi.so.diverted'

Ugly, but now ldconfig will not find the original file and create a
symlink to it based on its SONAME.

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#704180: p11-kit: provide package that diverts libnssckbi.so and replaces it with p11-kit-trust.so

[Sam Morris]

On Fri, Mar 03, 2023 at 02:43:48PM +, Sam Morris wrote:
> Commands to divert the original file and replace it with a symlink:
> 
>   # dpkg-divert --add --rename /usr/lib/x86_64-linux-gnu/libnssckbi.so
>   # ln -sr /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so 
> /usr/lib/x86_64-linux-gnu/libnssckbi.so

Unfortunately this no longer works reliably. Since libnssckbi.so is now
found in /usr/lib/x86_64-linux-gnu, as soon any library package is
installer or upgraded, ldconfig will be run, which will replace
the symlink.

(This is noted in the dpkg-divert man page).

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1039571: gnome-software: "Loading application details" displayed forever

[Sam Morris]

Package: gnome-software
Version: 43.4-1
Severity: important
X-Debbugs-Cc: s...@robots.org.uk

When I click on any application from the default screen, information
never loads. The "Loading application details" mesasge is displayed
forever.

If I click on a category instead of an application, the widgets that
would normally show highlighted applications from the category do not
load, they just display "..." forever.


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (570, 'stable-security'), (570, 'stable-debug'), (570, 'stable'), 
(550, 'testing-debug'), (550, 'testing'), (530, 'unstable-debug'), (530, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gnome-software depends on:
ii  appstream0.16.1-2
ii  apt-config-icons 0.16.1-2
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gnome-software-common43.4-1
ii  gsettings-desktop-schemas43.0-1
ii  libadwaita-1-0   1.2.2-1
ii  libappstream40.16.1-2
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libfwupd21.8.12-2
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-4-1   4.8.3+ds-2
ii  libgtk3-perl 0.038-3
ii  libgudev-1.0-0   237-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmalcontent-0-00.11.0-4
ii  libpackagekit-glib2-18   1.2.6-5
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpolkit-gobject-1-0122-3
ii  libsoup-3.0-03.3.1-1
ii  libxmlb2 0.3.10-2
ii  packagekit   1.2.6-5
ii  software-properties-gtk  0.99.30-4

Versions of packages gnome-software recommends:
ii  fwupd  1.8.12-2

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
ii  gnome-software-plugin-flatpak  43.4-1
pn  gnome-software-plugin-snap 

-- Configuration Files:
/etc/xdg/autostart/gnome-software-service.desktop [Errno 2] No such file or 
directory: '/etc/xdg/autostart/gnome-software-service.desktop'

-- no debconf information

Bug#1039570: flatpak: 'flatpak upgrade' repeatedly installs, removes, installs some obsolete runtimes

[Sam Morris]

Package: flatpak
Version: 1.14.4-1
Severity: normal
X-Debbugs-Cc: s...@robots.org.uk

Each time I run 'flatpak uprade' it installs and removes a couple of
obsolete runtimes, over and over.

According to 'flatpak list' the following flatpaks are installed:

root@fragarach:~# flatpak list
Name   Application ID   
   VersionBranch Installation
Color Picker   nl.hjdskes.gcolor3   
   2.4.0  stable system
Mesa   
org.freedesktop.Platform.GL.default 21.3.9 21.08
  system
Mesa   
org.freedesktop.Platform.GL.default 23.1.1 22.08
  system
Mesa (Extra)   
org.freedesktop.Platform.GL.default 23.1.1 22.08-extra  
  system
Intel  
org.freedesktop.Platform.VAAPI.Intel   21.08
  system
Intel  
org.freedesktop.Platform.VAAPI.Intel   22.08
  system
openh264   
org.freedesktop.Platform.openh264   2.1.0  2.0  
  system
openh264   
org.freedesktop.Platform.openh264   2.1.0  2.2.0
  system
GNOME Application Platform version 3.38org.gnome.Platform   
  3.38   system
GNOME Application Platform version 43  org.gnome.Platform   
  43 system
GNOME Application Platform version 44  org.gnome.Platform   
  44 system
Secretsorg.gnome.World.Secrets  
   7.3stable system
Adwaita dark GTK theme 
org.gtk.Gtk3theme.Adwaita-dark 3.22 
  system

Now if I run 'flatpak upgrade', it wants to install two runtimes that,
as far as I can tell are already installed?

root@fragarach:~# flatpak upgrade
Looking for updates…

Info: runtime org.freedesktop.Platform.VAAPI.Intel branch 20.08 is 
end-of-life, with reason:
   org.freedesktop.Platform 20.08 is no longer receiving fixes and security 
updates. Please update to a supported runtime version.

Info: runtime org.freedesktop.Platform.GL.default branch 20.08 is 
end-of-life, with reason:
   org.freedesktop.Platform 20.08 is no longer receiving fixes and security 
updates. Please update to a supported runtime version.


ID  Branch
Op   RemoteDownload
 1. [✓] org.freedesktop.Platform.GL.default 20.08 i 
   flathub   105.8 MB / 106.4 MB
 2. [✓] org.freedesktop.Platform.VAAPI.Intel20.08 i 
   flathub11.6 MB / 11.6 MB

Installation complete.

And if I run 'flatpak upgrade' again, then they get removed...

root@fragarach:~# flatpak upgrade
Looking for updates…

Info: runtime org.freedesktop.Platform.VAAPI.Intel branch 20.08 is 
end-of-life, with reason:
   org.freedesktop.Platform 20.08 is no longer receiving fixes and security 
updates. Please update to a supported runtime version.

Info: runtime org.freedesktop.Platform.GL.default branch 20.08 is 
end-of-life, with reason:
   org.freedesktop.Platform 20.08 is no longer receiving fixes and security 
updates. Please update to a supported runtime version.


IDBranch  Op
 1. [-] org.freedesktop.Platform.GL.default   20.08   r
 2. [-] org.freedesktop.Platform.VAAPI.Intel  20.08   r

Uninstall complete.

... and if I run it a third time they are installed again...

root@fragarach:~# flatpak upgrade
Looking for updates…

Info: runtime org.freedesktop.Platform.VAAPI.Intel branch 20.08 is 
end-of-life, with reason:
   org.freedesktop.Platform 20.08 is no longer receiving fixes and security 
updates. Please update to a supported runtime version.

Info: runtime org.freedesktop.Platform.GL.default branch 20.08 is 
end-of-life, with reason:
   org.freedesktop.Platform 20.08 is no longer receiving fixes and security 
updates. Please update to a supported runtime version.


ID  

Bug#984879: podman does not work on Debian with selinux loaded

[Sam Morris]

On Wed, Jun 21, 2023 at 05:28:48PM +0100, Sam Morris wrote:
> refpolicy has a 'container' module that appears to work, it's just not
> built by default.

BTW, the existance of /etc/selinux/default/contexts/lxc_contexts is what
causes Podman to try to label containers. Which prevents it from being
able to start any container, since the container module is not
included in selinux-policy-default.

https://sources.debian.org/src/golang-github-opencontainers-selinux/1.10.0+ds1-1/go-selinux/selinux_linux.go/?hl=943#L943

> Any chance that module could be built by default?

So if the module is not suitable to be built by default, please remove
the `lxc_contexts` file; I have the feeling it might also cause problems
with libvirt and k8s...

https://sources.debian.org/src/libvirt/9.0.0-4/src/security/security_selinux.c/?hl=650#L650

https://sources.debian.org/src/kubernetes/1.20.5+really1.20.2-1.1/vendor/github.com/opencontainers/selinux/go-selinux/selinux_linux.go/?hl=887#L887

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#984879: podman does not work on Debian with selinux loaded

[Sam Morris]

On Thu, May 13, 2021 at 10:14:38AM +0200, Laurent Bigonville wrote:
> From a SELinux policy perspective, the main problem is that the "container"
> policy is 100% Red Hat specific and has not been upstreamed and the
> difficulty is that the RH SELinux policy is heavily patched compared to the
> debian and upstream one.

Hi folks,

refpolicy has a 'container' module that appears to work, it's just not
built by default.

Steps taken to test it:

 1. Edit debian/modules.conf.default, adding 'container = module'
 2. Run 'debian/rules build-default-policy'
 3. Run 'semodule -i debian/build-default/container.pp'
 4. Start a container with 'podman run --rm -it docker.io/library/debian:11 
sleep inf'
 5. Check the context of the sleep process with 'ps -Z '

Any chance that module could be built by default?

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1038164: RFP: container-selinux -- SELinux policy module for containers

[Sam Morris]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  Package name: container-selinux
  URL : https://github.com/containers/container-selinux
  License : GPL
  Description : SELinux policy confinement of containers

This package is needed for podman/buildah to work on systems where
SELinux is running.

Unless it's installed, the user has to manally disable container
labelling in containers.conf, or disable SELinux.



-BEGIN PGP SIGNATURE-

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCZIwm4xIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIoKPgD+OHE7MjhotfAhTnNkM74pZGPzke033Rxb
OynaiRzwQ9gA/0imgNQhyIcaY5nfECbpiy4HiT5nZXVSkW2grAxCFsEG
=B1D/
-END PGP SIGNATURE-

Bug#926388: let Firefox trust /etc/ssl/certs/ca-certificates.crt

[Sam Morris]

On Fri, Feb 12, 2021 at 10:15:36AM +0100, Martin Habovštiak wrote:
> # TODO: support other archs
> replace_libnssckbi /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
> replace_libnssckbi /usr/lib/firefox-esr/libnssckbi.so
> replace_libnssckbi /usr/lib/thunderbird/libnssckbi.so

As of Debian 12 ("bookworm"), firefox-esr and thunderbird no longer ship
their own libnssckbi.so files:
<https://packages.debian.org/search?searchon=contents=libnssckbi.so>

So I thing this bug can be resolved as a duplicate of
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704180>.

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#704180: p11-kit: provide package that diverts libnssckbi.so and replaces it with p11-kit-trust.so

[Sam Morris]

On Fri, Mar 03, 2023 at 02:43:48PM +, Sam Morris wrote:
> FYI, the file paths in the original bug report are no longer accurate
> for Debian 12 ("bookworm").
> 
>   Old path: /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
>   New path: /usr/lib/x86_64-linux-gnu/libnssckbi.so
> 
> Commands to divert the original file and replace it with a symlink:
> 
>   # dpkg-divert --add --rename /usr/lib/x86_64-linux-gnu/libnssckbi.so
>   # ln -sr /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so 
> /usr/lib/x86_64-linux-gnu/libnssckbi.so
> 
> Commands to clean up the old diversion:
> 
>   # dpkg-divert --rename --remove /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
>   # dpkg -S /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
> ... output should show that this is no longer owned by any package
>   # rm /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so

A convenient way to test that the above works (instead of having to
restart your browser) is to use the following tool from the
libnss3-toosl package:

$ vfyserv server.example.com
Connecting to host server.example.com (addr 198.51.100.99) on port 443
Handshake Complete: SERVER CONFIGURED CORRECTLY
   bulk cipher AES-256-GCM, 256 secret key bits, 256 key bits, status: 1
   subject DN:
 CN=server.example.com,O=Example private certificate authority
   issuer  DN:
 CN=Certificate Authority,O=Example private certificate authority
   0 cache hits; 0 cache misses, 0 cache not reusable
* Connection 1 read 488 bytes total.

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#905745: util-linux: tty hijacking possible in "su" via TIOCSTI ioctl

[Sam Morris]

Package: util-linux
Followup-For: Bug #905745

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linux 6.2 introduces a sysctl dev.tty.legacy_tiocsti sysctl which can be
used to disable TIOCSTI. The default value of the sysctl is set at build
time with CONFIG_LEGACY_TIOCSTI.



- -- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (500, 'testing-security'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 util-linux depends on:
ii  libblkid1 2.38.1-5+b1
ii  libc6 2.36-9
ii  libcap-ng00.8.3-1+b3
ii  libcrypt1 1:4.4.33-2
ii  libmount1 2.38.1-5+b1
ii  libpam0g  1.5.2-6
ii  libselinux1   3.4-1+b5
ii  libsmartcols1 2.38.1-5+b1
ii  libsystemd0   252.6-1
ii  libtinfo6 6.4-2
ii  libudev1  252.6-1
ii  libuuid1  2.38.1-5+b1
ii  util-linux-extra  2.38.1-5+b1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages util-linux recommends:
ii  sensible-utils  0.0.17+nmu1

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.5.1-1+b1
pn  util-linux-locales  

- -- Configuration Files:
/etc/pam.d/su changed [not included]

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCZEo7HRIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIoVygD/esa+KDEoqGAI0xyY2/7wjt0QCYguxXJl
ezYU/QhuP/cA/3C9WAz7FDOHJAS8fG7BGdoQ/o7TAKHCHoH5NS1lC18L
=ZhB2
-END PGP SIGNATURE-

Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl

[Sam Morris]

Source: shadow
Followup-For: Bug #628843

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

su/runuser are provided by util-linux these days. Can this bug be
closed?

- -- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (500, 'testing-security'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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

-BEGIN PGP SIGNATURE-

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCZEo5zxIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIrPXQD/cwQDVq34zy/KZ0iOzcsQGfwUYiCrycss
qdxSuGlBoiEBANAB1vhWhZVyDYG5e/E8qrYXKMiVvOW+G7UxvH+tXaEM
=oCdS
-END PGP SIGNATURE-

Bug#1034002: ldapvi: Chase referrals option [-C, --chase] not documented

[Sam Morris]

Package: ldapvi
Version: 1.7-10+b6
Severity: minor

There is a rather useful -C option which can be used to disable referral
chasing:

$ ldapvi -C no

$ ldapvi --chase=no

It's not in the --help output nor the man page.

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (500, 'testing-security'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 ldapvi depends on:
ii  libc6  2.36-8
ii  libcrypt1  1:4.4.33-2
ii  libglib2.0-0   2.74.6-1
ii  libldap-2.5-0  2.5.13+dfsg-5
ii  libpopt0   1.19+dfsg-1
ii  libreadline8   8.2-1.3
ii  libtinfo6  6.4-2

ldapvi recommends no packages.

ldapvi suggests no packages.

-- no debconf information

Bug#1033673: buildah: Not build with libsubid

[Sam Morris]

Package: buildah
Followup-For: Bug #1033673

Here's a merge request:
https://salsa.debian.org/go-team/packages/golang-github-containers-buildah/-/merge_requests/2/


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (500, 'testing-security'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 buildah depends on:
ii  golang-github-containers-common  0.50.1+ds1-4
ii  libc62.36-8
ii  libdevmapper1.02.1   2:1.02.185-2
ii  libgpgme11   1.18.0-3+b1
ii  libseccomp2  2.5.4-1+b3
ii  uidmap   1:4.13+dfsg1-1+b1

Versions of packages buildah recommends:
ii  crun1.8.1-1
ii  fuse-overlayfs  1.10-1

Versions of packages buildah suggests:
ii  containers-storage  1.43.0+ds1-7+b2

-- no debconf information

Bug#1033673: buildah: Not build with libsubid

[Sam Morris]

Package: buildah
Version: 1.28.2+ds1-1+b2
Severity: normal
Tags: patch

Similar to podman's #1019929, buildah is not built with libsubid
support.

So users with subordinate UID/GIDs stored in an LDAP directory can't use
buildah without being root.

Merge request with patch on the way...

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (500, 'testing-security'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 buildah depends on:
ii  golang-github-containers-common  0.50.1+ds1-4
ii  libc62.36-8
ii  libdevmapper1.02.1   2:1.02.185-2
ii  libgpgme11   1.18.0-3+b1
ii  libseccomp2  2.5.4-1+b3
ii  uidmap   1:4.13+dfsg1-1+b1

Versions of packages buildah recommends:
ii  crun1.8.1-1
ii  fuse-overlayfs  1.10-1

Versions of packages buildah suggests:
ii  containers-storage  1.43.0+ds1-7+b2

-- no debconf information

Bug#1032515: libsoup-3.0-0: Can't download from https://www.bing.com - connection reset by peer

[Sam Morris]

Package: libsoup-3.0-0
Version: 3.2.2-2
Severity: normal
X-Debbugs-Cc: s...@robots.org.uk

With the following python script I get:

$ python3 bing.py 
Traceback (most recent call last):
  File "/tmp/bing.py", line 7, in 
ses.send_and_read(mes)
gi.repository.GLib.GError: g-io-error-quark: Error receiving data: 
Connection reset by peer (44)

Here's the script:

import gi

gi.require_version("Soup", "3.0")

from gi.repository import Soup

mes = Soup.Message.new_from_encoded_form(
"GET",
"https://www.bing.com/HPImageArchive.aspx;,
Soup.form_encode_hash(
{"format": "js", "idx": "0", "n": "1", "mbl": "1", "mkt": "auto"}
),
)
ses = Soup.Session()
ses.send_and_read(mes)

Soup 2.4 is able to access the same URL just fine, there's a gjs script
to demonstrate at
.

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-security'), (570, 
'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 'testing'), 
(530, 'unstable-debug'), (530, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages libsoup-3.0-0 depends on:
ii  glib-networking 2.66.0-2
ii  libbrotli1  1.0.9-2+b6
ii  libc6   2.36-8
ii  libglib2.0-02.74.5-1
ii  libgssapi-krb5-21.20.1-1
ii  libnghttp2-14   1.52.0-1
ii  libpsl5 0.21.0-1.2
ii  libsoup-3.0-common  3.2.2-2
ii  libsqlite3-03.40.1-1
ii  zlib1g  1:1.2.11.dfsg-2+deb11u2

libsoup-3.0-0 recommends no packages.

libsoup-3.0-0 suggests no packages.

-- no debconf information

Bug#1030310: python3-poetry: 'poetry check' requires python3-trove-classifiers

[Sam Morris]

Package: python3-poetry
Version: 1.3.2+dfsg-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There's a missing dependency on python3-trove-classifiers in order for
'poetry check' to work.

  $ poetry check

  No module named 'trove_classifiers'



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

Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 python3-poetry depends on:
ii  python3 3.11.1-3
ii  python3-cachecontrol0.12.12-2
ii  python3-cleo2.0.1-5
ii  python3-crashtest   0.4.1-1
ii  python3-dulwich 0.21.2-1+b1
ii  python3-filelock3.9.0-1
ii  python3-html5lib1.1-3
ii  python3-importlib-metadata  4.12.0-1
ii  python3-jsonschema  4.10.3-1
ii  python3-keyring 23.9.3-2
ii  python3-lockfile1:0.12.2-2.2
ii  python3-packaging   23.0-1
ii  python3-pexpect 4.8.0-4
ii  python3-pkginfo 1.8.2-2
ii  python3-platformdirs2.6.0-1
ii  python3-poetry-core 1.4.0-4
ii  python3-requests2.28.1+dfsg-1
ii  python3-requests-toolbelt   0.10.1-1
ii  python3-shellingham 1.5.0-1
ii  python3-tomli   2.0.1-2
ii  python3-tomlkit 0.11.6-1
ii  python3-urllib3 1.26.12-1
ii  python3-virtualenv  20.17.1+ds-1

python3-poetry recommends no packages.

python3-poetry suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCY9vkgBIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIpIzwEA52msPv9wVKApViUZjnun5pnaTInOBhZ9
yKyzSiWt0eEA/0behtTLnFqysrGDpW1y6/rWeKGgXgs2vjnf643ujVUB
=Bc0z
-END PGP SIGNATURE-

Bug#1029070: /usr/lib/python3/dist-packages/ipalib/x509.py: Broken by python3-cryptography API break in 38.0.1

[Sam Morris]

Package: python3-ipalib
Followup-For: Bug #1029070
Control: forwarded -1 https://pagure.io/freeipa/issue/9160
Control: tags -1 + fixed-upstream patch

Seems this is fixed in 4.9 and later versions.

There's a patch for 4.9 at

which works for me.

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 python3-ipalib depends on:
ii  freeipa-common  4.9.8-1
ii  gpg 2.2.40-1
ii  gpg-agent   2.2.40-1
ii  keyutils1.6.3-2
ii  librpm9 4.18.0+dfsg-1
ii  python3 3.10.6-3+b1
ii  python3-cffi1.15.1-5
ii  python3-cryptography38.0.4-2
ii  python3-dbus1.3.2-3
ii  python3-dnspython   2.2.1-2
ii  python3-gssapi  1.8.2-1
ii  python3-ldap3.4.3-2+b1
ii  python3-libipa-hbac 2.8.2-1~1.gbp44da1a
ii  python3-lxml4.9.2-1
ii  python3-netaddr 0.8.0-2
ii  python3-netifaces   0.11.0-2
ii  python3-pyasn1  0.4.8-3
ii  python3-pyasn1-modules  0.2.8-1
ii  python3-qrcode  7.3.1-1
ii  python3-requests2.28.1+dfsg-1
ii  python3-setuptools  65.5.0-1.1
ii  python3-six 1.16.0-4
ii  python3-usb 1.2.1-1
ii  python3-yubico  1.3.3-0.3
ii  systemd 252.4-1

python3-ipalib recommends no packages.

python3-ipalib suggests no packages.

-- no debconf information

Bug#1029070: /usr/lib/python3/dist-packages/ipalib/x509.py: Broken by python3-cryptography API break in 38.0.1

[Sam Morris]

Package: python3-ipalib
Version: 4.9.8-1
Severity: important
File: /usr/lib/python3/dist-packages/ipalib/x509.py

$ ipa vault-find
Traceback (most recent call last):
  File "/usr/bin/ipa", line 27, in 
from ipaclient.__main__ import main
  File "/usr/lib/python3/dist-packages/ipaclient/__main__.py", line 7, in 

from ipalib import api, cli
  File "/usr/lib/python3/dist-packages/ipalib/__init__.py", line 921, in 

from ipalib.frontend import Command, LocalOrRemote, Updater
  File "/usr/lib/python3/dist-packages/ipalib/frontend.py", line 31, in 

from ipalib.parameters import create_param, Param, Str, Flag
  File "/usr/lib/python3/dist-packages/ipalib/parameters.py", line 125, in 

from ipalib.x509 import (
  File "/usr/lib/python3/dist-packages/ipalib/x509.py", line 91, in 
@crypto_utils.register_interface(crypto_x509.Certificate)
AttributeError: module 'cryptography.utils' has no attribute 
'register_interface'. Did you mean: 'verify_interface'?

According to  this is caused by
cryptography 38.0.1 which removed the register_interface decorator.

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 python3-ipalib depends on:
ii  freeipa-common  4.9.8-1
ii  gpg 2.2.40-1
ii  gpg-agent   2.2.40-1
ii  keyutils1.6.3-2
ii  librpm9 4.18.0+dfsg-1
ii  python3 3.10.6-3+b1
ii  python3-cffi1.15.1-5
ii  python3-cryptography38.0.4-2
ii  python3-dbus1.3.2-3
ii  python3-dnspython   2.2.1-2
ii  python3-gssapi  1.8.2-1
ii  python3-ldap3.4.3-2+b1
ii  python3-libipa-hbac 2.8.2-1~1.gbp44da1a
ii  python3-lxml4.9.2-1
ii  python3-netaddr 0.8.0-2
ii  python3-netifaces   0.11.0-2
ii  python3-pyasn1  0.4.8-3
ii  python3-pyasn1-modules  0.2.8-1
ii  python3-qrcode  7.3.1-1
ii  python3-requests2.28.1+dfsg-1
ii  python3-setuptools  65.5.0-1.1
ii  python3-six 1.16.0-4
ii  python3-usb 1.2.1-1
ii  python3-yubico  1.3.3-0.3
ii  systemd 252.4-1

python3-ipalib recommends no packages.

python3-ipalib suggests no packages.

-- no debconf information

Bug#389183: passwd: 'passwd -l/-u' should edit the shadow account expiry field *in addition* to editing the password field as they do know

[Sam Morris]

Package: shadow,libpam-modules
Followup-For: Bug #389183

A note to software archeologists: this was reverted in June 2007 by
shadow 1:4.1.1-3, with the following remarks in the changelog:

  * debian/patches/494_passwd_lock-no_account_lock: Restore the previous
behavior of passwd -l (which changed in #389183): only lock the user's
password, not the user's account. Also explicitly document the
differences. This restores a behavior common with the previous versions of
passwd and with other implementations. Closes: #492307

The changelog shipped by the package doesn't go back that far.

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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#1014463: podman-toolbox: Toolbox only works with fedora-toolbox:34

[Sam Morris]

Package: podman-toolbox
Version: 0.0.99.3-1
Followup-For: Bug #1014463
X-Debbugs-Cc: s...@robots.org.uk

I think the log messages are a red herring and the underlying issue is
that the toolbox binary is not able to run inside the container.

Toolbox appears to work by bind-mounting /usr/bin/toolbox into the
container. 'toolbox init-container' is set as the entry point, and it's
_this_ command that's failing to start; but the output isn't shown by
toolbox and you get the generic 'invalid entry point PID of container'
error message instead.

$ toolbox create -i quay.io/centos/centos:stream8
Created container: centos-stream8
Enter with: toolbox enter centos-stream8

$ podman inspect centos-stream8 | jq '.[].ImageName'
"quay.io/centos/centos:stream8"

$ podman inspect centos-stream8 | jq '.[].Config.Cmd' -c

["toolbox","--log-level","debug","init-container","--gid","876099160","--home","/home/sam","--shell","/bin/bash","--uid","1423121","--user","sam","--monitor-host"]

$ podman start --attach centos-stream8
toolbox: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by 
toolbox)

$ podman unshare

# podman mount centos-stream8

/home/sam/.local/share/containers/storage/overlay/02976304f367a933a73eb3590c79acea57dc62e47f2642df560237190ea669b5/merged

# grep ^NAME= 
/home/sam/.local/share/containers/storage/overlay/02976304f367a933a73eb3590c79acea57dc62e47f2642df560237190ea669b5/merged/etc/os-release
 
NAME="CentOS Stream"

# ldd 
/home/sam/.local/share/containers/storage/overlay/02976304f367a933a73eb3590c79acea57dc62e47f2642df560237190ea669b5/merged/lib64/libc.so.6
[...]
Version definitions:
[...]
28 0x00 0x06969187 GLIBC_2.27
GLIBC_2.26 
29 0x00 0x06969188 GLIBC_2.28
GLIBC_2.27 
30 0x00 0x0963cf85 GLIBC_PRIVATE
GLIBC_2.28 
[...]

# exit
exit

I'm not seeing an easy way to fix this... if toolbox is built against
unstable then it's often going to pull in glibc symbols that are newer
than the container images that it tries to run.

In this case it's only a single symbol that is used from GLIBC_2.32.

$ objdump -T /usr/bin/toolbox | fgrep GLIBC_2.32
  DF *UND*   (GLIBC_2.32) 
pthread_sigmask


According to

this is fixed by , which
was closed a year ago. Maybe the libc-wrappers.a static library that
provides this symbol isn't being built by Debian for some reason...

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-security'), (570, 
'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 'testing'), 
(530, 'unstable-debug'), (530, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages podman-toolbox depends on:
ii  flatpak  1.10.7-0+deb11u1
ii  libc62.36-4
ii  podman   4.2.0+ds1-3
ii  uidmap   1:4.8.1-1

Versions of packages podman-toolbox recommends:
ii  bash-completion  1:2.11-2

podman-toolbox suggests no packages.

-- no debconf information

Bug#1023393: policykit-1: Not prompted to authenticate with my own identity any more

[Sam Morris]

On 03/11/2022 15:17, Sam Morris wrote:
But I suppose this should become a bug against polkitd-pkla since in 
practice its 49-polkit-pkla-compat.rules will never be called since 
40-debian-sudo.rules is called first.


Perhaps one solution would be to renumber to << 40, and ship a 
pklocalauthority config file with 'unix-group:sudo'. This will ensure 
that systems where polkitd-pkla is installed will match the default 
behaviour of systems where it isn't installed.


FYI, Fedora ship their default admin rules with these numbers:

# ls /etc/polkit-1/rules.d/
49-polkit-pkla-compat.rules  50-default.rules

50-default.rules is equivalent to Debian's 40-debian-sudo.rules file 
(although Fedora use the wheel group rather than sudo).


--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1023393: policykit-1: Not prompted to authenticate with my own identity any more

[Sam Morris]

On 03/11/2022 13:39, Simon McVittie wrote:

On Thu, 03 Nov 2022 at 11:51:52 +, Sam Morris wrote:

Here's my configuration:

 # cat /etc/polkit-1/localauthority.conf.d/60-sam.conf
 [Configuration]
 AdminIdentities=unix-user:sam.mor...@domain.example.com


Is that really your Unix/PAM login name, the one you'd get from `id -nu`
or `su - $user` or similar? Or is your login name something like sam.morris
or sam?


Yes - the user account lives in an Active Directory domain which is 
projected into the POSIX world by FreeIPA. The user name is the SAM 
Account Name of the user @ The AD domain's DNS FQDN.



The usual setup with a modern polkit version is that the admin identities
are handled by /usr/share/polkit-1/rules.d/40-debian-sudo.rules,
which returns "unix-group:sudo", meaning "any member of the sudo group
is a local sysadmin".


Having my username in the pklocalauthority like that is sort of a 
workaround for a number of unfortunate things about how polkit 
enumerates groups & because FreeIPA isn't able to put AD users into 
netgroups.


You're right, adding my user to the (local) sudo group will probably do 
the job.



It's usually unnecessary to configure this, either in the old PKLA
backend or in the newer JS backend, so the way this interoperates with
the legacy PKLA configuration is unlikely to be particularly well-tested.

I wonder whether the problem here might be that 40-debian-sudo.rules is
sequenced earlier than 49-polkit-pkla-compat.rules, which means only the
function defined in 40-debian-sudo.rules gets called, and the one in
49-polkit-pkla-compat.rules is ignored?


You're right. I actually just commented out the contents of 
40-debian-sudo.rules entirely. polkit immediately reloads the rules and 
my pkcheck command is once again prompting me for my own credentials.



polkit keeps calling admin rule functions until one returns a non-empty
result, so only the first one that returns a result (in lexicographic
order by filename) is practically useful.


Argh, that's a really annoying. I wonder why they don't call all the 
admin rules and collect all of the results...


Anyway, that's all I need to get our systems working sensibly again.

But I suppose this should become a bug against polkitd-pkla since in 
practice its 49-polkit-pkla-compat.rules will never be called since 
40-debian-sudo.rules is called first.


Perhaps one solution would be to renumber to << 40, and ship a 
pklocalauthority config file with 'unix-group:sudo'. This will ensure 
that systems where polkitd-pkla is installed will match the default 
behaviour of systems where it isn't installed.



 smcv


Thanks for your help! :)

--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1023393: policykit-1: Not prompted to authenticate with my own identity any more

[Sam Morris]

Package: polkitd
Version: 122-1
Severity: important
X-Debbugs-Cc: s...@robots.org.uk

Since updating to 122, polkit authentication prompts ask me to
authenticate as "Administrator" (root?) rather than my own user.

Here's my configuration:

# cat /etc/polkit-1/localauthority.conf.d/60-sam.conf 
[Configuration]
AdminIdentities=unix-user:sam.mor...@domain.example.com

# pkla-admin-identities 
unix-user:sam.mor...@domain.example.com

So it looks like polkitd-pkla still recognizes me as an administrator.

pkla-check-authorization however indicates that maybe my user is allowed
to connect/disconnect pre-existing network connections but is _not_
allowed to edit network connections. So maybe the problem is with
polkitd-pkla after all?

# pkla-check-authorization sam.mor...@domain.example.com true true 
org.freedesktop.NetworkManager.network-control
yes

# pkla-check-authorization sam.mor...@domain.example.com true true 
org.freedesktop.NetworkManager.settings.modify.system; echo $?
0

For the end to end test I'm running this command, which prompts me for
root's password rather than my own.

$ pkcheck -a org.freedesktop.NetworkManager.settings.modify.system -u -p $$
polkit\56dismissed=true
polkit\56retains_authorization_after_challenge=true
Authentication request was dismissed.

So based on that it's not clear to me whether the problem lies in
polkitd or polkitd-pkla...

Not sure whether the problem is with polkit itself or polkitd-pkla.
-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-security'), (570, 
'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 'testing'), 
(530, 'unstable-debug'), (530, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages policykit-1 depends on:
ii  pkexec   122-1
ii  polkitd  122-1

Versions of packages policykit-1 recommends:
ii  polkitd-pkla  122-1

policykit-1 suggests no packages.

Versions of packages polkitd depends on:
ii  adduser 3.118
ii  dbus [default-dbus-system-bus]  1.12.24-0+deb11u1
ii  libc6   2.35-4
ii  libduktape207   2.7.0-1+b1
ii  libexpat1   2.2.10-2+deb11u5
ii  libglib2.0-02.74.1-1
ii  libpam-systemd [logind] 251.6-1
ii  libpam0g1.4.0-9+deb11u1
ii  libpolkit-agent-1-0 122-1
ii  libpolkit-gobject-1-0   122-1
ii  libsystemd0 251.6-1
ii  systemd [systemd-sysusers]  251.6-1
ii  xml-core0.18+nmu1

Versions of packages polkitd suggests:
ii  polkitd-pkla  122-1

-- no debconf information

Bug#1022956: jmeter: fails to start: Unable to make field private static java.lang.String sun.awt.X11.XToolkit.awtAppClassName accessible: module java.desktop does not "opens sun.awt.X11" to unnamed m

[Sam Morris]

Package: jmeter
Version: 2.13-5
Severity: important
X-Debbugs-Cc: s...@robots.org.uk

jmeter fails to start:

  $ jmeter
  An error occurred: Unable to make field private static java.lang.String 
sun.awt.X11.XToolkit.awtAppClassName accessible: module java.desktop does not 
"opens sun.awt.X11" to unnamed module @2f410acf

There is a workaround:

  JAVA_ARGS="--add-opens java.desktop/sun.awt=ALL-UNNAMED 
--add-opens=java.desktop/sun.awt.shell=ALL-UNNAMED 
--add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED --add-opens 
java.desktop/sun.swing=ALL-UNNAMED --add-opens 
java.desktop/javax.swing.text.html=ALL-UNNAMED 
--add-opens=java.base/java.lang=ALL-UNNAMED 
--add-opens=java.base/java.lang.invoke=ALL-UNNAMED" jmeter

I took these options from .

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-security'), (570, 
'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 'testing'), 
(530, 'unstable-debug'), (530, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages jmeter depends on:
ii  default-jre [java2-runtime] 2:1.11-72
ii  java-wrappers   0.3
ii  junit4  4.13.1-2
ii  libavalon-framework-java4.2.0-10
ii  libbcmail-java  1.68-2
ii  libbcpkix-java  1.68-2
ii  libbcprov-java  1.68-2
ii  libbsf-java 1:2.4.0-8
ii  libbsh-java 2.0b4-20
ii  libcommons-codec-java   1.15-1
ii  libcommons-collections3-java3.2.2-2
ii  libcommons-httpclient-java  3.1-16
ii  libcommons-io-java  2.8.0-1
ii  libcommons-jexl-java1.1-3.1
ii  libcommons-jexl2-java   2.1.1-5
ii  libcommons-lang-java2.6-9
ii  libcommons-lang3-java   3.11-1
ii  libcommons-math3-java   3.6.1-3
ii  libcommons-net-java 3.6-1
ii  libcommons-pool2-java   2.8.0-1
ii  libdnsjava-java 2.1.8-2
ii  libexcalibur-logger-java2.1-7
ii  libexcalibur-logkit-java2.0-12
ii  libgeronimo-jms-1.1-spec-java   1.1.1-1
ii  libhtmlparser-java  1.6.20060610.dfsg0-9
ii  libhttpclient-java  4.5.13-2
ii  libhttpcore-java4.4.14-1
ii  libhttpmime-java4.5.13-2
ii  libjcharts-java 0.7.5-5
ii  libjdom1-java   1.1.3-2.1
ii  libjsoup-java   1.10.2-2
ii  libjtidy-java   7+svn20110807-5
ii  libmail-java1.6.5-1
ii  libmongodb-java 3.6.3-2
ii  liboro-java 2.0.8a-14
ii  librhino-java   1.7.7.2-3
ii  librsyntaxtextarea-java 2.5.8-1
ii  libxalan2-java  2.7.2-4
ii  libxmlgraphics-commons-java 2.4-2~deb11u1
ii  libxstream-java 1.4.15-3+deb11u1
ii  openjdk-11-jre [java2-runtime]  11.0.16+8-1~deb11u1
ii  openjdk-17-jre [java2-runtime]  17.0.4+8-1~deb11u1
ii  velocity1.7-6

Versions of packages jmeter recommends:
ii  jmeter-help  2.13-5
ii  jmeter-http  2.13-5

jmeter suggests no packages.

-- no debconf information

Bug#1019929: podman: Subordinate UID/GID ranges not fetched from libsubid

[Sam Morris]

Control: tag -1 + patch

On Fri, Sep 16, 2022 at 12:10:43PM +0100, Sam Morris wrote:
> ... but it looks like podman doesn't use this library yet:

I've prepared a patch that builds libpod against libsubid:

<https://salsa.debian.org/debian/libpod/-/merge_requests/6>

Regards,

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1020683: usbutils: Please include lsusbs.py

[Sam Morris]

On 25/09/2022 13:04, Aurelien Jarno wrote:
>

- The debian policy forbids to install a script in /usr/bin with the .py
   extension. It can not be called lsusb given the existing binary already
   provided by usbutils.


Policy sec. 10.4 says "the script name should not include an extension"; 
it doesn't say "must not".


On policy's side, we have not wanting to necessarily expose users to the 
fact that a script is written in a particular language.


On the other hand, upstream ships the script with this name, other 
distributions (at least Fedora and RHEL) install it as lsusb.py and so 
users (me!) expect it to be called that. The options and output of the 
script are completely different to the traditional lsusb command, so I 
don't ever expect upstream to replace the traditional lsusb command with 
this script, or to rename it.


IMO this tips the balance in favour of shipping it as lsusb.py.


- lsusb.py needs python3 and the usb.ids database, so it increases the
   disk footprint from ~0.5MB to ~22.3MB which has a big impact for
   embedded systems.


lsusb.py is still useful without usb.ids: it still shows the USB bus 
topology, including information about which drivers are attached to 
which interface, without it (try running lsusb.py -f /blah -i). So I 
think a Suggests is appropriate.


As for Python 3, I think Suggests is also appropriate: 99% of my use of 
the script is "what new weird way has this laptop manufacturer chosen to 
hook up its built-in peripherals" and this is, for me, always done on a 
system where python3 and usb.ids are pulled in by something else anyway. 
On small-footprint systems, the addition of an lsusb.py script that 
doesnt't work unless you pull in python3 isn't a regression.


OTOH adding a binary package for this one small script is additional 
archive bloat. Those embedded systems will suffer a little bit more for 
the extra package they need to know about in /var/lib/apt/lists... ;)



- lsusb.py lacks a manpage.


I've just written one. :)


If lsusb.py is really way more useful than lsusb, an option might be to
ship it in a separate package (usbutils-py? lsusb-py?) and change the
binary name (lsusb-py? lsusb-python?).


If you think a trip through binNEW is worth it, lsusb-py would make 
sense to me. I've prepared a debian.tar.xz with this in mind, attached 
to this message for your consideration.


I've not renamed the command, but if the above doesn't convince you, how 
about /usr/bin/lsusb-py? (of course, the man page also has to be 
renamed, which makes it harder to send upstream...)


Cheers,

--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9


usbutils_014-1.1.debian.tar.xz
Description: Binary data

Bug#1020683: usbutils: Please include lsusbs.py

[Sam Morris]

Package: usbutils
Version: 1:014-1
Severity: wishlist

usbutils includes a lsusbs.py command which gives much more readable
output than lsusb.

Looks like only 'usr/bin/lsusb.py' has to be added to debian/install to
get it included in the binary package.


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 usbutils depends on:
ii  libc6 2.34-8
ii  libudev1  251.4-3
ii  libusb-1.0-0  2:1.0.26-1

usbutils recommends no packages.

usbutils suggests no packages.

-- no debconf information

Bug#1020424: krb5: Versioned dependencies are needed in order to avoid version skew

[Sam Morris]

Source: krb5
Version: 1.20-1
Severity: normal
X-Debbugs-Cc: s...@robots.org.uk

When using a container image that has an older version of some of the
binary packages from krb5 in it, installing krb5-user results in binary
packages being installed that are a mix of the newer and older version.

The practical problem with this is:

$ podman run -ti docker.io/library/r-base:latest bash -l 

.. at this time, the following packages are installed (i.e., they're
part of the container image).

ii  libgssapi-krb5-2:amd64 1.19.2-2+b2  amd64MIT Kerberos runtime 
libraries - krb5 GSS-API Mechanism
ii  libk5crypto3:amd64 1.19.2-2+b2  amd64MIT Kerberos runtime 
libraries - Crypto Library
ii  libkrb5-3:amd641.19.2-2+b2  amd64MIT Kerberos runtime 
libraries
ii  libkrb5support0:amd64  1.19.2-2+b2  amd64MIT Kerberos runtime 
libraries - Support library

Now, I'll install kinit and try to use it:

root@d6ed10d8dfac:/# apt -qq update && apt install krb5-user
[...]

root@d6ed10d8dfac:/# kinit u...@example.com
kinit: Random number generator could not be seeded while getting initial 
credentials

This error message comes from libk5crypto.so.3. At this point,
libk5crypto3 is still at the old version, other binary packages have
been upgraded:

ii  krb5-user1.20-1   amd64basic programs to 
authenticate using MIT Kerberos
ii  libgssapi-krb5-2:amd64   1.20-1   amd64MIT Kerberos runtime 
libraries - krb5 GSS-API Mechanism
ii  libgssrpc4:amd64 1.20-1   amd64MIT Kerberos runtime 
libraries - GSS enabled ONCRPC
ii  libk5crypto3:amd64   1.19.2-2+b2  amd64MIT Kerberos runtime 
libraries - Crypto Library
ii  libkadm5clnt-mit12:amd64 1.20-1   amd64MIT Kerberos runtime 
libraries - Administration Clients
ii  libkadm5srv-mit12:amd64  1.20-1   amd64MIT Kerberos runtime 
libraries - KDC and Admin Server
ii  libkdb5-10:amd64 1.20-1   amd64MIT Kerberos runtime 
libraries - Kerberos database
ii  libkrb5-3:amd64  1.20-1   amd64MIT Kerberos runtime 
libraries
ii  libkrb5support0:amd641.20-1   amd64MIT Kerberos runtime 
libraries - Support library

After 'apt-get install libk5crypto3', version 1.20-1 is installed & the
kinit command works.

I think this is related to the removal of the embedded PRNG in 1.19 and
earlier versions. The code from 1.20 is calling
krb5_c_random_make_octets (which is provided by libk5crypto3) in a way
that the older implementation isn't happy with, and it throws this
error.

Maybe there's a missing Breaks or Conflicts somewhere; or maybe
versioned dependencies need to be added somewhere to ensure that all the
binary packages from krb5 are upgraded in lockstep.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-security'), (570, 
'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 'testing'), 
(530, 'unstable-debug'), (530, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_DIE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Bug#1019929: podman: Subordinate UID/GID ranges not fetched from libsubid

[Sam Morris]

Package: podman
Version: 4.2.0+ds1-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've not got anything in /etc/subuid or /etc/subgid because subordinate
id range info is stored in LDAP.

  $ grep ^subid: /etc/nsswitch.conf
  subid: sss

This is transparent to clients using libsubid:

  $ getsubids sam
  0: sam 2147483648 65536

... but it looks like podman doesn't use this library yet:

$ podman system info
ERRO[] cannot find UID/GID for user sam: no subuid ranges found for 
user "sam" in /etc/subuid - check rootless mode in man pages.
WARN[] Using rootless single mapping into the namespace. This might 
break some images. Check /etc/subuid and /etc/subgid for adding sub*ids if not 
using a network user
[...]
  idMappings:
gidmap:
- container_id: 0
  host_id: 1000
  size: 1
uidmap:
- container_id: 0
  host_id: 1000
  size: 1
[...]

- -- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages podman depends on:
ii  conmon   2.1.3+ds1-1
ii  crun 1.5+dfsg-1+b1
ii  golang-github-containers-common  0.48.0+ds1-1
ii  libc62.34-7
ii  libdevmapper1.02.1   2:1.02.185-1
ii  libgpgme11   1.17.1-4.1
ii  libseccomp2  2.5.4-1+b1
ii  systemd [systemd-tmpfiles]   251.4-3

Versions of packages podman recommends:
ii  buildah1.26.1+ds1-1
ii  catatonit  0.1.7-1
ii  dbus-user-session  1.14.0-2
ii  fuse-overlayfs 1.9-1
ii  slirp4netns1.2.0-1
ii  uidmap 1:4.11.1+dfsg1-2

Versions of packages podman suggests:
ii  containers-storage  1.37.2+ds1-1+b2
pn  docker-compose  
ii  iptables1.8.8-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCYyRZrhIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIra+wEA9cSULDer04xzpg1djBcsaxdK78eH6avT
szoQ8hl2ERMA/08sN17EOvYQOLB8WwleW1kPCQZdDztMiapcY5Ep7CYI
=DI3R
-END PGP SIGNATURE-

Bug#1019917: /usr/bin/getsubids: Segfaults when nsswitch.conf refers to a libsubid_*.so library that does not exist

[Sam Morris]

Package: uidmap
Version: 1:4.11.1+dfsg1-2
Severity: normal
File: /usr/bin/getsubids

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

With:

$ grep ^subid: /etc/nsswitch.conf
subid: sss

I get:

$ getsubids sam
Segmentation fault (core dumped)

GDB reveals that this is happening while handling the failure to open
libsubid_sss.so:

(gdb) where
#0  __vfprintf_internal (s=0x0, format=0x77f94872 "Error opening %s: 
%s\n", ap=ap@entry=0x7fffdbd0, mode_flags=mode_flags@entry=2) at 
./stdio-common/vfprintf-internal.c:1359
#1  0x77d1751f in ___fprintf_chk (fp=, 
flag=flag@entry=1, format=format@entry=0x77f94872 "Error opening %s: %s\n") 
at ./debug/fprintf_chk.c:33
#2  0x77f8318e in fprintf (__fmt=0x77f94872 "Error opening %s: 
%s\n", __stream=) at 
/usr/include/x86_64-linux-gnu/bits/stdio2.h:105
#3  nss_init (nsswitch_path=0x77f94820 "/etc/nsswitch.conf", 
nsswitch_path@entry=0x0) at ./lib/nss.c:94
#4  0x77f831bb in get_subid_nss_handle () at ./lib/nss.c:148
#5  0x77f852db in list_owner_ranges 
(owner=owner@entry=0x7fffe2a6 "sam", id_type=id_type@entry=ID_TYPE_UID, 
in_ranges=in_ranges@entry=0x7fffddd0) at ./lib/subordinateio.c:776
#6  0x77f7efad in get_subid_ranges (ranges=0x7fffddd0, 
id_type=ID_TYPE_UID, owner=owner@entry=0x7fffe2a6 "sam") at 
./libsubid/api.c:48
#7  0x514f in main (argc=2, argv=0x7fffdf18) at 
./src/getsubids.c:38

(gdb) l
89  goto done;
90  }
91  snprintf(libname, 64,  "libsubid_%s.so", token);
92  h = dlopen(libname, RTLD_LAZY);
93  if (!h) {
94  fprintf(shadow_logfd, "Error opening 
%s: %s\n", libname, dlerror());
95  fprintf(shadow_logfd, "Using files\n");
96  subid_nss = NULL;
97  goto done;
98  }

(gdb) p libname
$1 = "libsubid_sss.so", '\000' 

(gdb) p shadow_logfd
$2 = (FILE *) 0x77df3680 <_IO_2_1_stderr_>

(gdb) p dlerror()
$3 = 0x0

Looks like dlerror is returning NULL which causes the crash.

- -- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages uidmap depends on:
ii  libaudit11:3.0.7-1+b1
ii  libc62.34-7
ii  libselinux1  3.4-1+b1
ii  libsubid41:4.11.1+dfsg1-2

uidmap recommends no packages.

uidmap suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCYyQ5YxIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIo6aAD/ZVNMtggK8Tvo0OcKDjaIgT9Gv5cBYflG
ymusOSHQ2X4A/1+aBe0EfugsEePoyn2golGRMn44gDj4z9Sk5rrJKKoF
=12CG
-END PGP SIGNATURE-

Bug#958805: onedrive: SEGV and core dump on error (401)

[Sam Morris]

Package: onedrive
Version: 2.4.18-0.1+b1
Followup-For: Bug #958805
X-Debbugs-Cc: s...@robots.org.uk

According to
,

> This issue is caused by the way the 'onedrive' packages are built
> using the [Debian] LDC package & the default distribution compiler
> options which is the root cause for this issue. Refer to:
> https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1895969

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-security'), (570, 
'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 'testing'), 
(530, 'unstable-debug'), (530, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_DIE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages onedrive depends on:
ii  init-system-helpers   1.60
ii  libc6 2.34-7
ii  libgcc-s1 12.2.0-1
ii  libglib2.0-0  2.73.3-3
ii  libnotify40.7.9-3
ii  libphobos2-ldc-shared100  1:1.30.0-1+b1
ii  libsqlite3-0  3.34.1-3

onedrive recommends no packages.

onedrive suggests no packages.

-- no debconf information

Bug#1019263: Audio capture (e.g., in MS Teams) doesn't work

[Sam Morris]

It turns out this was caused by the audio_capture_enable setting which 
made its way into my profile.


--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1019263: chromium: Audio capture (e.g., in MS Teams) doesn't work

[Sam Morris]

Package: chromium
Version: 105.0.5195.102-1
Severity: normal
X-Debbugs-Cc: s...@robots.org.uk

When I try to join a Teams meeting, I get the mesasge

Are you sure you don't want audio or video? If you change your mind,
select the camera icon by your address bar and then _Always allow_.

This appears to happen because Teams can't see the existance of my
microphone. When I click the camera icon in the address bar, I see:

Camera and Microphone Blocked

This page has been blocked from accessing your camera and micrphone.

( ) Always allow https://teams.microsoft.com to access your camera and
microphone

(x) Continue blocking camera and microphone access


Microphone: Default

Camera: TOSHIBA Web Cam...

[Manage] [Done]

Now the funny things about this popup are:

 * Selecting 'always allow' and pressing Done doesn't work. If I click
   the camera icon again, the popup comes back and 'always allow' is
   selected, but Teams behaves as if I didn't change the option and
   continued to block it.

 * If I reload the page and join another meeting, 'Continue blocking' is
   set, so chromium doesn't remember my selection between page loads.

 * When I try to change the devices listed in the popup, by clicking on
   what I assume is supposed to be a dropdown menu, nothing happens;
   it's as if the widget is disabled, though there is no visual
   indication of such

 * If I press Manage, it takes me to
which has an entry right
   at the top of 'recent activity' saying: teams.microsoft.com: Allowed
   camera, microphone

 * If I click on this entry it takes me to
   

   which under 'permissions' has Microphone set to Block. If I click
   this I get a dropdown menu with the entries Block (default), Allow
   and Block. If I choose Allow in this dropdown menu, the choice is
   instantly reset back to Block.

Trying to debug this at another site,
,
when I press 'Start' I get the same popup as with Teams (although this
one doesn't mention the camera being blocked). This one has the same
behaviour: 'Continue blocking' is selected by default, if I change it to
'allow' and press 'Done', nothing happens. If I reload the page, next
time I click the camera icon to get the popup, 'Continue blocking' is
still set.

In the console, these messages are logged when I press 'Start'.

Requesting local stream
main.js:56 navigator.MediaDevices.getUserMedia error:  Permission denied 
NotAllowedError

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-security'), (570, 
'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 'testing'), 
(530, 'unstable-debug'), (530, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_DIE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages chromium depends on:
ii  chromium-common 105.0.5195.102-1
ii  libasound2  1.2.7.2-1
ii  libatk-bridge2.0-0  2.38.0-1
ii  libatk1.0-0 2.36.0-2
ii  libatomic1  12.2.0-1
ii  libatspi2.0-0   2.38.0-4
ii  libbrotli1  1.0.9-2+b2
ii  libc6   2.34-4
ii  libcairo2   1.16.0-5
ii  libcups22.4.2-1+b1
ii  libdbus-1-3 1.12.20-2
ii  libdouble-conversion3   3.1.5-6.1
ii  libdrm2 2.4.104-1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libexpat1   2.2.10-2+deb11u3
ii  libflac81.3.3-2+deb11u1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.12.1+dfsg-3
ii  libgbm1 20.3.5-1
ii  libgcc-s1   12.2.0-1
ii  libglib2.0-02.72.3-1+b1
ii  libgtk-3-0  3.24.34-3
ii  libjpeg62-turbo 1:2.0.6-4
ii  libjsoncpp251.9.5-4
ii  liblcms2-2  2.12~rc1-2
ii  libminizip1 

Bug#1015317: /lib/systemd/system/podman-auto-update.service: podman-auto-update.service broken - can't find /bin/podman

[Sam Morris]

Package: podman
Version: 4.1.1+ds1-2
Severity: normal
File: /lib/systemd/system/podman-auto-update.service

Jul 18 00:15:01 systemd[1]: Starting Podman auto-update service...
Jul 18 00:15:01 systemd[3185620]: podman-auto-update.service: Failed to locate 
executable /bin/podman: No such file or directory
Jul 18 00:15:01 systemd[3185620]: podman-auto-update.service: Failed at step 
EXEC spawning /bin/podman: No such file or directory
Jul 18 00:15:01 systemd[1]: podman-auto-update.service: Main process exited, 
code=exited, status=203/EXEC
Jul 18 00:15:01 systemd[1]: podman-auto-update.service: Failed with result 
'exit-code'.

The service file should reference /usr/bin/podman, not /bin/podman.


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

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

Versions of packages podman depends on:
ii  conmon   2.1.0+ds1-1
ii  containernetworking-plugins  1.1.0+ds1-1+b1
ii  crun 0.17+dfsg-1.1+b1
ii  golang-github-containers-common  0.48.0+ds1-1
ii  libc62.33-7
ii  libdevmapper1.02.1   2:1.02.183-2
ii  libgpgme11   1.17.1-4
ii  libseccomp2  2.5.4-1
ii  systemd [systemd-tmpfiles]   251.2-7

Versions of packages podman recommends:
ii  buildah   1.26.1+ds1-1
ii  catatonit 0.1.7-1
ii  fuse-overlayfs1.9-1
ii  golang-github-containernetworking-plugin-dnsname  1.3.1+ds1-2+b1
ii  slirp4netns   1.0.1-2
ii  uidmap1:4.11.1+dfsg1-2

Versions of packages podman suggests:
ii  containers-storage  1.37.2+ds1-1+b1
pn  docker-compose  
ii  iptables1.8.8-1

-- no debconf information

Bug#668462: network-manager: Wrong default for IPv6 Privacy Extensions

[Sam Morris]

Control: tags -1 + moreinfo

On Thu, Apr 12, 2012 at 01:47:18AM +0200, Juerd Waalboer wrote:
> It appears that when ip6-privacy is not defined, it defaults to 0. I believe
> that it should default to nothing at all and leave the sysctl value at 
> whatever
> value was set without the help of NetworkManager. Users who had enabled IPv6
> Privacy Extensions will probably have done so by adding a manual sysctl for
> net.ipv6.conf.*.use_tempaddr; the current NetworkManager overrides this value,
> possibly disabling previously perfectly functioning IPv6 Privacy Extensions.

Is this still the case? NetworkManager.conf(5) says:

ipv6.ip6-privacy
   If ipv6.ip6-privacy is unset, use the content of 
"/proc/sys/net/ipv6/conf/default/use_tempaddr" as last fallback.

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1010889: network-manager: Please ship additional NM config examples found in examples/nm-conf.d/

[Sam Morris]

Package: network-manager
Version: 1.37.92-1
Severity: wishlist

examples/nm-conf.d has a couple of drop-in example config files that it
would be nie to find in /usr/share/doc/network-manager/examples.

In particular, 30-anon.conf shows how to configure NM so that it won't
leak information to the network provider via DHCP identifiers.


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

Kernel: Linux 5.10.0-13-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_DIE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager depends on:
ii  adduser  3.121
ii  dbus 1.14.0-1
ii  libaudit11:3.0.7-1+b1
ii  libbluetooth35.64-2
ii  libc62.33-7
ii  libcurl3-gnutls  7.83.0-1
ii  libglib2.0-0 2.72.1-1
ii  libgnutls30  3.7.4-2
ii  libjansson4  2.14-2
ii  libmm-glib0  1.18.6-2
ii  libndp0  1.8-1
ii  libnewt0.52  0.52.21-5+b1
ii  libnm0   1.37.92-1
ii  libpsl5  0.21.0-1.2
ii  libreadline8 8.1.2-1.2
ii  libselinux1  3.3-1+b2
ii  libsystemd0  250.4-1
ii  libteamdctl0 1.31-1
ii  libudev1 250.4-1
ii  policykit-1  0.105-33
ii  udev 250.4-1

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.86-1.1
ii  libpam-systemd   250.4-1
pn  modemmanager 
pn  ppp  
ii  wireless-regdb   2021.08.28-1
ii  wpasupplicant2:2.10-9

Versions of packages network-manager suggests:
ii  iptables   1.8.7-1
pn  libteam-utils  

Versions of packages network-manager is related to:
pn  isc-dhcp-client  

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

-- no debconf information

Bug#1001644: [Pkg-sssd-devel] Bug#1001644: libpam-sss: OTP-enabled users do not recieve OTP prompts from pam_sss.so

[Sam Morris]

On Wed, Dec 15, 2021 at 11:19:23AM +0200, Timo Aaltonen wrote:
> On 13.12.2021 19.39, Sam Morris wrote:
> > Package: libpam-sss
> > Version: 2.6.1-1
> > Severity: normal
> >
> > In the default configuration, /etc/pam.d/common-auth contains:
> > 
> >auth [success=2 default=ignore]  pam_unix.so nullok
> >auth [success=1 default=ignore]  pam_sss.so use_first_pass
> >authrequisite   pam_deny.so
> > 
> > This means that pam_unix has the first & only change to prompt the user
> > for authentication, and the user gets a single 'Password:' prompt.
> > 
> > In the Red Hat world, /etc/pam.d/password-auth contains:
> > 
> >authrequired pam_env.so
> >authrequired 
> > pam_faildelay.so delay=200
> >auth[default=1 ignore=ignore success=ok] pam_usertype.so 
> > isregular
> >auth[default=1 ignore=ignore success=ok] pam_localuser.so
> >authsufficient   pam_unix.so 
> > nullok
> >auth[default=1 ignore=ignore success=ok] pam_usertype.so 
> > isregular
> >authsufficient   pam_sss.so 
> > forward_pass
> >authrequired pam_deny.so
> > 
> > A local user will hit pam_unix. A non-local user will skip over it and
> > be prompted by pam_sss.so.
> > 
> > An easy fix is to increase the Priority in /usr/share/pam-configs/sss to
> > some value > 256. That way, pam-auth-update puts pam_sss before
> > pam_unix.
> > 
> > I tested this, and 'su - localuser' still works.
> > 
> > Unfortunately I don't know of a way for a user to override this value
> > other than by editing that file, which is owned by libpam-sss.
> > 
> > Is there a good reason that pam_unix has to be first in the module
> > stack? If not, could we make this change?
>
> You're asking in the wrong place.. Anyway, pam_sss is not above pam_unix in
> Fedora either, so why should it have a higher priority here?

My goal is to get 2-factor authentication working on Debian systems as
easily as it does on Fedora/RHEL systems. This requires pam_sss to
prompt the user for their password, not pam_unix.

Here's a solution that uses pam_localuser to prevent pam_unix from being
invoked for pam_sss's users:

# here are the per-package modules (the "Primary" block)
auth[default=1 ignore=ignore success=ok] pam_localuser.so 
auth[success=2 default=ignore]  pam_unix.so nullok
auth[success=1 default=ignore]  pam_sss.so
# here's the fallback if no module succeeds
authrequisite   pam_deny.so

But, this another package to change for us (libpam-modules which ships
/usr/share/pam-configs/unix). We can ask, of course

For this to work, I had to remove the 'use_first_pass' option from
pam_sss. Otherwise FreeIPA users can't log in any more:

(2022-02-01 10:22:06): [be[ipa.example.com]] [krb5_auth_send] (0x0020): 
Illegal empty authtok for user [u...@ipa.example.com]

Unfortunately pam_sss doesn't have a 'try_first_pass' option. As a
result, if there is _another_ module that runs before pam_sss, AND
prompts the user for a password, storing itin the PAM environment,
pam_sss will not use it, and the user will be prompted for their
'password' or 'first factor' (depending on whether the user requires
MFA) a second time.

Even if 'try_first_pass' did exist in pam_sss, the user would still get
a 'password' prompt instead of a 'first factor' prompt, which is an
annoying behaviour difference between how things work in the Debian
universe rather than the Red Hat universe. The only fix for that is for
every other PAM module to avoid prompting for a password if the user is
'not for them', so that pam_sss still gets to be the first/only module
that prompts for a password, even though it is later on in the stack.

Because of requiring extra work in the libpam-modules package, and the
edge case above, it seems simpler to re-arrange the stack so that
pam_sss goes first.

So, we can either bump the priority of pam_sss, or remove the
use_first_pass option iff the PAM maintainers agree to add pam_localuser
to their pam-auth-update config file. What do you think?

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#656339: From: Felix Geyer

[Sam Morris]

On Fri, Mar 23, 2012 at 01:24:03PM +, Sam Morris wrote:
> > Could you please test if this is still a problem with version 4.1.8-dfsg-2?
> > 
> > mesa didn't load the dri module as it wasn't installed into the multiarch
> > directory.
> 
> Sadly this is still the case. I don't know why it took me so long to
> file the bug, I experienced it way before multiarch ever existed.

Things seem a lot better these days. Perhaps because my host has a newer
GPU, there are so many variables to pin down...

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1001644: libpam-sss: OTP-enabled users do not recieve OTP prompts from pam_sss.so

[Sam Morris]

Package: libpam-sss
Version: 2.6.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In the default configuration, /etc/pam.d/common-auth contains:

  auth  [success=2 default=ignore]  pam_unix.so nullok
  auth  [success=1 default=ignore]  pam_sss.so use_first_pass
  authrequisite   pam_deny.so

This means that pam_unix has the first & only change to prompt the user
for authentication, and the user gets a single 'Password:' prompt.

In the Red Hat world, /etc/pam.d/password-auth contains:

  authrequired pam_env.so
  authrequired pam_faildelay.so 
delay=200
  auth[default=1 ignore=ignore success=ok] pam_usertype.so 
isregular
  auth[default=1 ignore=ignore success=ok] pam_localuser.so
  authsufficient   pam_unix.so nullok
  auth[default=1 ignore=ignore success=ok] pam_usertype.so 
isregular
  authsufficient   pam_sss.so 
forward_pass
  authrequired pam_deny.so

A local user will hit pam_unix. A non-local user will skip over it and
be prompted by pam_sss.so.

An easy fix is to increase the Priority in /usr/share/pam-configs/sss to
some value > 256. That way, pam-auth-update puts pam_sss before
pam_unix.

I tested this, and 'su - localuser' still works.

Unfortunately I don't know of a way for a user to override this value
other than by editing that file, which is owned by libpam-sss.

Is there a good reason that pam_unix has to be first in the module
stack? If not, could we make this change?

- -- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 
'unstable'), (500, 'stable-security'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-sss depends on:
ii  libc6 2.32-5
ii  libgssapi-krb5-2  1.18.3-7
ii  libpam-pwquality  1.4.4-1
ii  libpam-runtime1.4.0-9+deb11u1
ii  libpam0g  1.4.0-11

Versions of packages libpam-sss recommends:
ii  sssd  2.6.1-1

libpam-sss suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCYbeFXRIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIpR9gEAldojCYmY4mvOcns5k9wcfXpTN324+MUx
wiiKCeGy5PgBAKsWW6nGrvuFyQggaQADHH5O1p+bdr5q35Bp4suL0w0A
=ldXe
-END PGP SIGNATURE-

Bug#995730: [Pkg-sssd-devel] Bug#995730: libnss-sss: sssd protocol is not stable; libnss-sss and so on need stricter dependencies

[Sam Morris]

On Tue, 2021-10-05 at 12:56 +0300, Timo Aaltonen wrote:
> 
> Shouldn't dist-upgrade have updated everything you need?
> 

I've got both testing/unstable repositories configured on my system and
I have testing pinned at a higher priority. In this case I did 'apt-get
install -t unstable sssd' in order to upgrade just sssd so I could drop
my patch for pam_sss_gss.so which was included in 2.5.2.

Sometimes I do run into the odd dependency issue like this as a
result... :)

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#995730: libnss-sss: sssd protocol is not stable; libnss-sss and so on need stricter dependencies

[Sam Morris]

Package: libnss-sss
Version: 2.5.2-3
Severity: normal

I upgraded sssd today, and found that netgroup lookups no longer worked.

See  for the details. The
underlying reason was that I had not upgraded libnss-sss, and the older
libnss_sss.so.2 was unable to understand messages from the newer sssd.

Can stricter dependencies be used to make sure that libnss-sss (and
probably libpam-sss and libsss-sudo) are upgraded in lockstep with sssd?

For libnss-sss this is a bit tricky since it only Recommends sssd; and
sssd-common only Recommends libnss-sss. Maybe Breaks can be used?

OTOH, libnss-sss (and libpam-sss and libsss-sudo) don't seem very useful
without sssd, so maybe they could be change to Depend on it by exact
version. Or even be rolled into the sssd package?

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 
'unstable'), (500, 'stable-security'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libnss-sss depends on:
ii  libc6  2.32-4

Versions of packages libnss-sss recommends:
ii  sssd  2.5.2-3

libnss-sss suggests no packages.

-- no debconf information

Bug#989986: network-manager: NetworkManager exited and now I have no networking

[Sam Morris]

Package: network-manager
Version: 1.30.0-2
Severity: important
X-Debbugs-Cc: s...@robots.org.uk

NetworkManager.service has Restart=on-failure, but if something sends
SIGTERM to NetworkManager then it exits with status 0. 

Anyway, this user expects NetworkManager expects NM to be up & the
network to be available, solely except when NetworkManager.service is
stopped via systemd.

So can NetworkManager.service be changed to use Restart=always?

The rest of this bug report is just me trying to figure out where the
SIGTERM came from. If you have seen this before, or have any ideas about
other log files I can look through, please let me know so I can find out
what happened.

Here are NM's log messages:

  Jun 17 08:35:44 NetworkManager[2502]:   [1623915344.5407] dhcp4 
(enp61s0): state changed extended -> extended, address=192.0.2.1
  Jun 17 09:20:44 NetworkManager[2502]:   [1623918044.5429] dhcp4 
(enp61s0): state changed extended -> extended, address=192.0.2.1
  Jun 17 10:05:44 NetworkManager[2502]:   [1623920744.5713] dhcp4 
(enp61s0): state changed extended -> extended, address=192.0.2.1
  Jun 17 10:25:18 NetworkManager[2502]:   [1623921918.1020] 
agent-manager: 
agent[bd3cdbf2bd4a9ba1,:1.59958/org.gnome.Shell.NetworkAgent/876099160]: agent 
registered
  Jun 17 10:27:33 systemd[1]: NetworkManager.service: Unexpected error response 
from GetNameOwner(): Connection terminated
  Jun 17 10:27:33 NetworkManager[2502]:   [1623922053.3429] caught 
SIGTERM, shutting down normally.
  Jun 17 10:27:33 NetworkManager[2502]:   [1623922053.3560] device 
(wlp2s0): state change: unavailable -> unmanaged (reason 'unmanaged', 
sys-iface-state: 'managed')
  Jun 17 10:27:33 NetworkManager[2502]:   [1623922053.3586] device 
(wlp2s0): set-hw-addr: reset MAC address to 68:EC:C5:B6:4F:9A (unmanage)
  Jun 17 10:27:33 NetworkManager[2502]:   [1623922053.3796] dhcp4 
(enp61s0): canceled DHCP transaction
  Jun 17 10:27:33 NetworkManager[2502]:   [1623922053.3797] dhcp4 
(enp61s0): state changed extended -> done
  Jun 17 10:27:33 NetworkManager[2502]:   [1623922053.3798] device 
(enp61s0): DHCPv4: trying to acquire a new lease within 90 seconds
  Jun 17 10:27:33 NetworkManager[2502]:   [1623922053.3831] manager: 
NetworkManager state is now CONNECTED_SITE
  Jun 17 10:27:33 NetworkManager[2502]:   [1623922053.4526] exiting 
(success)
  Jun 17 10:27:33 systemd[1]: NetworkManager.service: Succeeded.
  Jun 17 10:27:33 systemd[1]: NetworkManager.service: Consumed 5min 40.408s CPU 
time, read 22.2M from disk, written 85.9M to disk, received 9.7M IP traffic, 
sent 4.5M IP traffic.

NM received SIGTERM at 10:27:33.

At the time, I was running 'apt upgrade', which coincidentally killed my
session and dumped me back at GDM's greeter.

According to /var/log/apt/history.log:

  Start-Date: 2021-06-17  10:26:37
  Commandline: apt upgrade
  Requested-By: sam.morris (1000)
  Upgrade: libpolkit-agent-1-0:amd64 (0.105-30, 0.105-31), libwebpmux3:amd64 
(0.6.1-2+b1, 0.6.1-2.1), libnettle8:amd64 (3.7.2-3, 3.7.3-1), ssl-cert:amd64 
(1.1.0, 1.1.0+nmu1), libqt5quickwidgets5:amd64 (5.15.2+dfsg-5, 5.15.2+dfsg-6), 
chrony:amd64 (4.0-7, 4.0-8), qml-module-qtquick-layouts:amd64 (5.15.2+dfsg-5, 
5.15.2+dfsg-6), qml-module-qtquick-window2:amd64 (5.15.2+dfsg-5, 
5.15.2+dfsg-6), libqt5qml5:amd64 (5.15.2+dfsg-5, 5.15.2+dfsg-6), 
libwebpdemux2:amd64 (0.6.1-2+b1, 0.6.1-2.1), gir1.2-javascriptcoregtk-4.0:amd64 
(2.32.1-1, 2.32.1-2), gir1.2-webkit2-4.0:amd64 (2.32.1-1, 2.32.1-2), 
libqt5quick5:amd64 (5.15.2+dfsg-5, 5.15.2+dfsg-6), libgee-0.8-2:amd64 
(0.20.3-1, 0.20.4-1), apache2-bin:amd64 (2.4.46-4, 2.4.46-6), extlinux:amd64 
(3:6.04~git20190206.bf6db5b4+dfsg1-3, 3:6.04~git20190206.bf6db5b4+dfsg1-3+b1), 
syslinux:amd64 (3:6.04~git20190206.bf6db5b4+dfsg1-3, 
3:6.04~git20190206.bf6db5b4+dfsg1-3+b1), libgcrypt20:amd64 (1.8.7-3, 1.8.7-6), 
runc:amd64 (1.0.0~rc93+ds1-5, 1.0.0~rc93+ds1-5+b1), libnss3:amd64 (2:3.66-1, 
2:3.67-1), libpolkit-gobject-1-0:amd64 (0.105-30, 0.105-31), 
gir1.2-polkit-1.0:amd64 (0.105-30, 0.105-31), libwebp6:amd64 (0.6.1-2+b1, 
0.6.1-2.1), libjavascriptcoregtk-4.0-18:amd64 (2.32.1-1, 2.32.1-2), 
apache2-utils:amd64 (2.4.46-4, 2.4.46-6), qml-module-qtqml-models2:amd64 
(5.15.2+dfsg-5, 5.15.2+dfsg-6), code:amd64 (1.56.2-1620838498, 
1.57.0-1623259737), libhogweed6:amd64 (3.7.2-3, 3.7.3-1), youtube-dl:amd64 
(2021.02.10-1, 2021.02.10-2), libqt5qmlmodels5:amd64 (5.15.2+dfsg-5, 
5.15.2+dfsg-6), libwebkit2gtk-4.0-37:amd64 (2.32.1-1, 2.32.1-2), 
python3-pygments:amd64 (2.7.1+dfsg-2, 2.7.1+dfsg-2.1), 
qml-module-qtquick2:amd64 (5.15.2+dfsg-5, 5.15.2+dfsg-6), 
libqt5qmlworkerscript5:amd64 (5.15.2+dfsg-5, 5.15.2+dfsg-6), policykit-1:amd64 
(0.105-30, 0.105-31)
  End-Date: 2021-06-17  10:27:47

Checking with /var/log/dpkg.log:

  2021-06-17 10:27:06 status half-configured chrony:amd64 4.0-8
  2021-06-17 10:27:33 status installed chrony:amd64 4.0-8
  2021-06-17 10:27:33 configure libjavascriptcoregtk-4.0-18:amd64 2.32.1-2 

  2021-06-17 10:27:33 status unpacked 

Bug#922945: [Pkg-shadow-devel] Bug#922945: /var/log/lastlog is a 110 TByte sparse file, seriously affecting backup

[Sam Morris]

On Fri, Apr 16, 2021 at 01:30:36PM +0200, Bálint Réczey wrote:
> Control: severity -1 wishlist
> Control: tags -1 confirmed upstream
> 
> Hi Sam,
> 
> Sam Morris  ezt írta (időpont: 2021. ápr. 13., K, 19:45):
> >
> > On Tue, 2021-04-13 at 15:26 +0200, Chris Hofstaedtler wrote:
> > > This will then silently hide login failures from userids larger than
> > > this ID? Given the original submitter has a user with uid 37940,
> > > why whould this not be logged?
> > >
> > > If they didn't want those uids to be used, maybe dont assign them?
> > >
> > > Chris
> >
> > I think login.defs(5) says it best:
> >
> > "As higher user IDs are usually tracked by remote user identity and
> > authentication services there is no need to create a huge sparse
> > lastlog file for them."
> >
> > The design of the lastlog format means you either have an apparantly
> > huge (sparse) file, which causes problems for badly written backup
> > software, or you don't record information for users with high UIDs in
> > this file at all.
> >
> > In any case, it looks like OpenSSH has its own code to read/write to
> > /var/log/lastlog, rather than using pam_lastlog, so in any case
> > changing login.defs wouldn't be sufficient.
> 
> Lastlog format is stable for a very long time and I don't think it
> would be wise to change it and as Chris pointed out shipping a default
> low LASTLOG_UID_MAX would hide login failures which is also not desired as
> a default.

Hold on, I think we're getting a little mixed up here...

/var/log/lastb is the file that tracks login failures. LASTLOG_UID_MAX
won't affects writes to that file (which in any case are done directly
by login(1), gdm3(8), sshd(8), etc., and not via PAM).

/var/log/lastlog tracks the last successful login. Interestingly, in
Debian's default configuration, in practice this only means the last
login with a tty. This is because pam_lastlog(8) is only included in
/etc/pam.d/login, rather than /etc/pam.d/common-session. Other programs
that log users in to the system are expected to update /var/log/lastlog
(and /var/log/wtmp and /run/utmp) themselves... and in the case of
sshd(8), it only does so when it alloacates a tty!

So in practice, 'ssh host mycommand' bypasses the logging into
/var/log/wtmp and /var/log/lastlog entirely. And logins via gdm(3)
aren't recorded in /var/log/lastlog at all. Maybe this is just common
knowledge, but I am a bit surprised by this!

Anyway, I don't have much more to add to this bug. Before I added my
comments, I was under the impression that the handling of the
lastlog/lastb/wtmp/utmp files was performed by PAM, giving consistent
behaviour between applications; but sadly this is not the case.

To summarize, the large apparant size of /var/log/lastlog is not a bug;
backup software should be able to deal with sparse files; there is no
central configuration to control writes to /var/log/lastlog; so this bug
may as well be tagged wontfix.

-- 
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#922945: [Pkg-shadow-devel] Bug#922945: /var/log/lastlog is a 110 TByte sparse file, seriously affecting backup

[Sam Morris]

On Tue, 2021-04-13 at 15:26 +0200, Chris Hofstaedtler wrote:
> This will then silently hide login failures from userids larger than
> this ID? Given the original submitter has a user with uid 37940,
> why whould this not be logged?
> 
> If they didn't want those uids to be used, maybe dont assign them?
> 
> Chris

I think login.defs(5) says it best:

"As higher user IDs are usually tracked by remote user identity and
authentication services there is no need to create a huge sparse
lastlog file for them."

The design of the lastlog format means you either have an apparantly
huge (sparse) file, which causes problems for badly written backup
software, or you don't record information for users with high UIDs in
this file at all.

In any case, it looks like OpenSSH has its own code to read/write to
/var/log/lastlog, rather than using pam_lastlog, so in any case
changing login.defs wouldn't be sufficient.

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9



signature.asc
Description: This is a digitally signed message part

Bug#922945: /var/log/lastlog is a 110 TByte sparse file, seriously affecting backup

[Sam Morris]

Package: login
Followup-For: Bug #922945
X-Debbugs-Cc: s...@robots.org.uk
Control: affects -1 libpam-modules
Control: tag -1 patch

There is a hint as to what's going on in login.defs(5).

LASTLOG_UID_MAX (number)
   Highest user ID number for which the lastlog entries should be
   updated. As higher user IDs are usually tracked by remote user
   identity and authentication services there is no need to create a
   huge sparse lastlog file for them.

   No LASTLOG_UID_MAX option present in the configuration means that
   there is no user ID limit for writing lastlog entries.

Maybe we could choose a sensible default value for this option?

Per policy section 9.2.2, adduser will (by default) allocate from
1000-59,999.

>From a quick skim through FreeIPA's source code, it looks like lowest
possible ID range with the default settings is 60,000.

These values line up quite nicely, however...

Back to policy, nobody is 65534; although this account shouldn't ever
log in, if the system was somehow misconfigured to allow this it would
be nice to have the evidence show up in lastlog(8).

Skipping past the next unusable values, we arrive at 65536 - dynamically
allocated user accounts, but not (by default) allocated by adduser(8).

So how about setting LASTLOG_UID_MAX to either 6 or 65536 depending
on whether we want failed logins by 'nobody' to appear in lastlog(8) or
not?

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (550, 'testing-debug'), (550, 'testing'), (530, 
'unstable-debug'), (530, 'unstable'), (500, 'testing-security'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages login depends on:
ii  libaudit1   1:3.0-2
ii  libc6   2.31-11
ii  libcrypt1   1:4.4.17-1
ii  libpam-modules  1.4.0-7
ii  libpam-runtime  1.4.0-7
ii  libpam0g1.4.0-7

login recommends no packages.

login suggests no packages.

-- Configuration Files:
/etc/login.defs changed [not included]

-- no debconf information

Bug#966198: gdm3: Defunct gdm-session-worker processes occationally remains unhandled.

[Sam Morris]

Package: gdm3
Version: 3.38.2.1-1
Followup-For: Bug #966198
X-Debbugs-Cc: s...@robots.org.uk

I've noticed quite a few of these processes hanging around:

$ pgrep gdm-session-worker -f | xargs ps -o pid,ppid,user,unit,uunit,args
PIDPPID USER UNITUUNIT  
 COMMAND
  13684   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
  14493   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
 533734   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
 562961   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
 924525   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
 966813   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1082590   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1157998   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1330002   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1357332   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1464958   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1629189   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1681338   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1729650   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1811649   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1898863   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1980006   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
1994799   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
2038078   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
2038182   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
2090305   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
2183710   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
2330631   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
2398148   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
2922617   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
2924774   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
2980937   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
3095572   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
3126611   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
3604886   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
3616298   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
3631925   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
3631965   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
3740333   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
3740704   1 root session-3.scope -  
 gdm-session-worker [pam/gdm-password]
3850981   1 root 

Bug#982288: podman: Can't run caontainers - failed to connect to container's attach socket - fixed!

[Sam Morris]

This was resolved by updating conmon as well as podman.

(Older versions of podman/conmon were both truncating the attach socket
name to 108 bytes; upgrading one and not the other meant that podman
wasn't able to find the socket created by conmon any more).

And yeah, my UID is really that high--the wonders of large
enterprises... :)

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9



signature.asc
Description: This is a digitally signed message part

Bug#982288: podman: Can't run caontainers - failed to connect to container's attach socket

[Sam Morris]

Package: podman
Version: 3.0.0~rc2+dfsg1-2+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: s...@robots.org.uk

After upgrading to podman 3, I can't run any containers any more.

$ podman run --rm -it docker.io/library/debian:10 
Error: failed to connect to container's attach socket: 
/run/user/876099160/libpod/tmp/socket/3178d20b8a3a42642dc6a7f32884df47019bc4a2a82af94fe4928b00ed3293c9/attach:
 no such file or directory

The directory /run/user/876099160/libpod/tmp/socket is empty.

According to unix(7), socket paths are limited to 108 bytes, but the
path in the error message is slightly longer than that:

$ echo -n 
/run/user/876099160/libpod/tmp/socket/18654637587d169f834095dce40d4812378e0056936974c9b7073ba1ae767bfa/attach
 | wc -c
109

Podman had a similar sounding bug a couple of years ago,
, but that was
fixed in podman 0.11.1.

Full debug output:

INFO[] podman filtering at log level debug  
DEBU[] Called run.PersistentPreRunE(podman --log-level=debug run --rm 
-it docker.io/library/debian:10) 
DEBU[] Reading configuration file 
"/usr/share/containers/containers.conf" 
DEBU[] Merged system config "/usr/share/containers/containers.conf": 
&{Containers:{Devices:[] Volumes:[] ApparmorProfile:containers-default-0.33.1 
Annotations:[] CgroupNS:private Cgroups:enabled DefaultCapabilities:[CHOWN 
DAC_OVERRIDE FOWNER FSETID KILL NET_BIND_SERVICE SETFCAP SETGID SETPCAP SETUID 
SYS_CHROOT] DefaultSysctls:[net.ipv4.ping_group_range=0 0] DefaultUlimits:[] 
DefaultMountsFile: DNSServers:[] DNSOptions:[] DNSSearches:[] 
EnableKeyring:true EnableLabeling:true 
Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
TERM=xterm] EnvHost:false HTTPProxy:true Init:false InitPath: IPCNS:private 
LogDriver:k8s-file LogSizeMax:-1 NetNS:slirp4netns NoHosts:false PidsLimit:2048 
PidNS:private SeccompProfile:/usr/share/containers/seccomp.json ShmSize:65536k 
TZ: Umask:0022 UTSNS:private UserNS:host UserNSSize:65536} 
Engine:{ImageBuildFormat:oci CgroupCheck:false CgroupManager:systemd 
ConmonEnvVars:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
 ConmonPath:[/usr/libexec/podman/conmon /usr/local/libexec/podman/conmon 
/usr/local/lib/podman/conmon /usr/bin/conmon /usr/sbin/conmon 
/usr/local/bin/conmon /usr/local/sbin/conmon /run/current-system/sw/bin/conmon] 
DetachKeys:ctrl-p,ctrl-q EnablePortReservation:true Env:[] 
EventsLogFilePath:/run/user/876099160/libpod/tmp/events/events.log 
EventsLogger:journald HooksDir:[/usr/share/containers/oci/hooks.d] 
ImageDefaultTransport:docker:// InfraCommand: InfraImage:k8s.gcr.io/pause:3.2 
InitPath:/usr/libexec/podman/catatonit LockType:shm MultiImageArchive:false 
Namespace: NetworkCmdPath: NetworkCmdOptions:[] NoPivotRoot:false NumLocks:2048 
OCIRuntime:crun OCIRuntimes:map[crun:[/usr/bin/crun /usr/sbin/crun 
/usr/local/bin/crun /usr/local/sbin/crun /sbin/crun /bin/crun 
/run/current-system/sw/bin/crun] kata:[/usr/bin/kata-runtime 
/usr/sbin/kata-runtime /usr/local/bin/kata-runtime /usr/local/sbin/kata-runtime 
/sbin/kata-runtime /bin/kata-runtime /usr/bin/kata-qemu /usr/bin/kata-fc] 
runc:[/usr/bin/runc /usr/sbin/runc /usr/local/bin/runc /usr/local/sbin/runc 
/sbin/runc /bin/runc /usr/lib/cri-o-runc/sbin/runc 
/run/current-system/sw/bin/runc]] PullPolicy:missing Remote:false RemoteURI: 
RemoteIdentity: ActiveService: ServiceDestinations:map[] RuntimePath:[] 
RuntimeSupportsJSON:[crun runc] RuntimeSupportsNoCgroups:[crun] 
RuntimeSupportsKVM:[kata kata-runtime kata-qemu kata-fc] 
SetOptions:{StorageConfigRunRootSet:false StorageConfigGraphRootSet:false 
StorageConfigGraphDriverNameSet:false StaticDirSet:false VolumePathSet:false 
TmpDirSet:false} SignaturePolicyPath:/etc/containers/policy.json SDNotify:false 
StateType:3 
StaticDir:/home/ipa.example.com/sam.morris/.local/share/containers/storage/libpod
 StopTimeout:10 TmpDir:/run/user/876099160/libpod/tmp 
VolumePath:/home/ipa.example.com/sam.morris/.local/share/containers/storage/volumes
 VolumePlugins:map[]} Network:{CNIPluginDirs:[/usr/libexec/cni /usr/lib/cni 
/usr/local/lib/cni /opt/cni/bin] DefaultNetwork:podman 
NetworkConfigDir:/home/ipa.example.com/sam.morris/.config/cni/net.d}} 
DEBU[] Reading configuration file "/etc/containers/containers.conf" 
DEBU[] Merged system config "/etc/containers/containers.conf": 
&{Containers:{Devices:[] Volumes:[] ApparmorProfile:containers-default-0.33.1 
Annotations:[] CgroupNS:private Cgroups:enabled DefaultCapabilities:[CHOWN 
DAC_OVERRIDE FOWNER FSETID KILL NET_BIND_SERVICE SETFCAP SETGID SETPCAP SETUID 
SYS_CHROOT] DefaultSysctls:[net.ipv4.ping_group_range=0 0] DefaultUlimits:[] 
DefaultMountsFile: DNSServers:[] DNSOptions:[] DNSSearches:[] 
EnableKeyring:true EnableLabeling:true 
Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
TERM=xterm] EnvHost:false HTTPProxy:true Init:false 

Bug#980167: /usr/lib/python3/dist-packages/syncthing_gtk/nautilusplugin.py: Errors from nautilus extension: AttributeError: 'str' object has no attribute 'decode'

[Sam Morris]

Package: syncthing-gtk
Version: 0.9.4.4+ds+git20201209+c46fbd8-1
Severity: normal
File: /usr/lib/python3/dist-packages/syncthing_gtk/nautilusplugin.py

With the extension enabled, nautilus outputs the following repeatedly:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/syncthing_gtk/nautilusplugin.py", 
line 303, in get_background_items
path = self._get_path(item).rstrip("/")
  File "/usr/lib/python3/dist-packages/syncthing_gtk/nautilusplugin.py", 
line 117, in _get_path
return file.get_location().get_path().decode('utf-8')
AttributeError: 'str' object has no attribute 'decode'

Looks like code that hasn't been updated to work on Python 3...

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.10.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages syncthing-gtk depends on:
ii  gir1.2-glib-2.01.66.1-1+b1
ii  gir1.2-gtk-3.0 3.24.24-1
ii  gir1.2-notify-0.7  0.7.9-2
ii  gir1.2-rsvg-2.02.50.2+dfsg-1
ii  libgtk-3-0 3.24.24-1
ii  python33.9.1-1
ii  python3-bcrypt 3.1.7-4
ii  python3-dateutil   2.8.1-5
ii  python3-gi 3.38.0-1+b2
ii  python3-gi-cairo   3.38.0-1+b2

Versions of packages syncthing-gtk recommends:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.5-2
ii  syncthing1.10.0~ds1-1

Versions of packages syncthing-gtk suggests:
ii  python3-nautilus  1.2.3-3+b1

-- no debconf information

Bug#962994: pcp: cron jobs launch pcp in cron's cgroup

[Sam Morris]

Package: pcp
Version: 5.2.3-1
Followup-For: Bug #962994

This doesn't appear to be fixed. I can see init scripts & cron job
definitions but not systemd units present in the pcp package:

$ dpkg -L pcp | grep systemd
/usr/lib/pcp/pmdas/systemd
/usr/lib/pcp/pmdas/systemd/Install
/usr/lib/pcp/pmdas/systemd/README
/usr/lib/pcp/pmdas/systemd/Remove
/usr/lib/pcp/pmdas/systemd/domain.h
/usr/lib/pcp/pmdas/systemd/help
/usr/lib/pcp/pmdas/systemd/pmdasystemd
/usr/lib/pcp/pmdas/systemd/pmns
/usr/lib/pcp/pmdas/systemd/root
/usr/share/man/man1/pmdasystemd.1.gz
/var/lib/pcp/pmdas/systemd
/var/lib/pcp/pmdas/systemd/Install
/var/lib/pcp/pmdas/systemd/README
/var/lib/pcp/pmdas/systemd/Remove
/var/lib/pcp/pmdas/systemd/domain.h
/var/lib/pcp/pmdas/systemd/help
/var/lib/pcp/pmdas/systemd/pmdasystemd
/var/lib/pcp/pmdas/systemd/pmns
/var/lib/pcp/pmdas/systemd/root

In 

we still have:

checking if systemd should be used... no

I wish it was possible to see the config.log from this build... but at
least I can reproduce this with pbuilder.

Adding --with-systemd to the configure command line will promote this to
a build error. I recommend making that change in debian/rules so that
this doesn't fall through the cracks:

--- debian/rules.old2021-01-04 11:25:11.569164314 +
+++ debian/rules2021-01-04 11:08:33.345991196 +
@@ -121,7 +121,7 @@
 #   ... Makepkgs uses the latter mechanism to refine the configure
 #   options
 #
-configure_paths = --prefix=/usr --libexecdir=/usr/lib --sysconfdir=/etc 
--localstatedir=/var --with-rcdir=/etc/init.d --with-sysconfigdir=/etc/default
+configure_paths = --prefix=/usr --libexecdir=/usr/lib --sysconfdir=/etc 
--localstatedir=/var --with-rcdir=/etc/init.d --with-sysconfigdir=/etc/default 
--with-systemd

 checkdir = test -f debian/rules
 uninstall = cat debian/*.install | sed -e "s,^,debian/$(pcp)/," | xargs rm 
-f

With that in place, I get:

checking if systemd should be used... configure: error: cannot enable 
systemd support - no systemunitdir path
make: *** [debian/rules:150: .census] Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit 
status 2
I: copying local configuration
E: Failed autobuilding of package

This is because there is no build-dependency on systemd:

root@fragarach:/build/pcp-5.2.3# dpkg -l systemd
dpkg-query: no packages found matching systemd

And it's systemd that ships systemd.pc:

$ dpkg -S /usr/share/pkgconfig/systemd.pc
systemd: /usr/share/pkgconfig/systemd.pc

I got the build working:

checking if systemd should be used... yes
checking systemd/sd-daemon.h usability... yes
checking systemd/sd-daemon.h presence... yes
checking for systemd/sd-daemon.h... yes

... by adding the build-dependency:

$ diff -u debian/control.old debian/control
--- debian/control.old  2021-01-04 11:24:51.005091436 +
+++ debian/control  2021-01-04 11:25:19.965194070 +
@@ -4,7 +4,7 @@
 Homepage: https://pcp.io
 Maintainer: PCP Development Team 
 Uploaders: Nathan Scott , Ken McDonell 

-Build-Depends: bison, flex, gawk, procps, pkg-config, debhelper (>= 5), 
perl (>= 5.6), libreadline-dev | libreadline5-dev | libreadline-gplv2-dev, 
chrpath, libbsd-dev [kfreebsd-any], libkvm-dev [kfreebsd-any], python3-dev, 
libnspr4-dev, libnss3-dev, libsasl2-dev, libuv1-dev, libssl-dev, 
libavahi-common-dev, qtbase5-dev, qtbase5-dev-tools, libqt5svg5-dev, qtchooser, 
autotools-dev, zlib1g-dev, autoconf, libclass-dbi-perl, libdbd-mysql-perl, 
python3-psycopg2, dh-python, libpfm4-dev, libncurses5-dev, python3-six, 
python3-json-pointer, python3-requests, libextutils-autoinstall-perl, 
libxml-tokeparser-perl, librrds-perl, libjson-perl, libwww-perl, 
libnet-snmp-perl, libnss3-tools, liblzma-dev, libsystemd-dev, bpftrace (>= 
0.9.2) [amd64 arm64 ppc64el], libibumad-dev, libibmad-dev, manpages, systemd
+Build-Depends: bison, flex, gawk, procps, pkg-config, debhelper (>= 5), 
perl (>= 5.6), libreadline-dev | libreadline5-dev | libreadline-gplv2-dev, 
chrpath, libbsd-dev [kfreebsd-any], libkvm-dev [kfreebsd-any], python3-dev, 
libnspr4-dev, libnss3-dev, libsasl2-dev, libuv1-dev, libssl-dev, 
libavahi-common-dev, qtbase5-dev, qtbase5-dev-tools, libqt5svg5-dev, qtchooser, 
autotools-dev, zlib1g-dev, autoconf, libclass-dbi-perl, libdbd-mysql-perl, 
python3-psycopg2, dh-python, libpfm4-dev, libncurses5-dev, python3-six, 
python3-json-pointer, python3-requests, libextutils-autoinstall-perl, 
libxml-tokeparser-perl, librrds-perl, libjson-perl, libwww-perl, 
libnet-snmp-perl, libnss3-tools, liblzma-dev, libsystemd-dev, bpftrace (>= 
0.9.2) [amd64 arm64 ppc64el], libibumad-dev, libibmad-dev, manpages
 Standards-Version: 3.9.3
 X-Python3-Version: >= 3.3
 
(I guess 

Bug#971424: gsd-usb-protection fails to add rule to allow USB devices

[Sam Morris]

Package: gnome-settings-daemon
Version: 3.38.1-2
Followup-For: Bug #971424

I'm still seeing this.

The workaround is to stop (remove) usbguard, then disable usb protection
on any newly-attached devices:

for x in /sys/bus/usb/devices/usb*/authorized_default; do echo 1 > $x; done

and then authorize any currently-unauthorized devices with:

for x in /sys/bus/usb/devices/[0-9]*/authorized; do echo 1 > $x; done

-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-9-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#970230: freeipa FTBFS on non-nodejs architectures

[Sam Morris]

Package: src:freeipa
Followup-For: Bug #970230
Control: tag -1 + patch

This should let freeipa build on armel again:

$ diff -u debian/rules.old debian/rules
--- debian/rules.old2020-11-11 13:26:32.112603329 +
+++ debian/rules2020-11-11 13:26:37.020620794 +
@@ -99,7 +99,7 @@
-exec sed -i -e '1 s|^#!.*\bpython[^ ]*|#!/usr/bin/python3|' {} \;

 override_dh_missing:
-   dh_missing --fail-missing
+   dh_missing

 ifneq ($(ONLY_CLIENT), 1)
 override_dh_installsystemd:

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-9-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971424: gsd-usb-protection fails to add rule to allow USB devices

[Sam Morris]

Source: gnome-settings-daemon
Version: 3.38.0-2
Severity: normal

As I understand it, gsd-usb-protection adds a rule to allow any USB
device but only while the system is not locked.

On my system, gsd-usb-protection is unable to add the rule.

$ /usr/libexec/gsd-usb-protection  -v
(gsd-usb-protection:437340): GLib-DEBUG: 11:03:34.418: unsetenv() is not 
thread-safe and should not be used after threads are created
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.420: 
Starting USB protection manager
(gsd-usb-protection:437340): GLib-GIO-DEBUG: 11:03:34.422: 
_g_io_module_get_default: Found default implementation dconf 
(DConfSettingsBackend) for ‘gsettings-backend’
(gsd-usb-protection:437340): dconf-DEBUG: 11:03:34.429: watch_fast: 
"/org/gnome/desktop/privacy/" (establishing: 0, active: 0)
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.431: 
bus_acquired_cb: acquired bus 0x5627ceb83070 for name 
org.gnome.SettingsDaemon.UsbProtection
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.432: 
Registered client at path /org/gnome/SessionManager/Client43
(gsd-usb-protection:437340): dconf-DEBUG: 11:03:34.440: watch_established: 
"/org/gnome/desktop/privacy/" (establishing: 1)
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.443: 
name_acquired_cb: acquired name org.gnome.SettingsDaemon.UsbProtection on bus 
0x5627ceb83070
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.444: 
name_lost_cb: lost name org.gnome.SettingsDaemon.UsbProtection on bus 
0x5627ceb83070
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.456: 
Received screensaver ActiveChanged signal: 0 (old: 0)
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.464: 
usb_protection_policy_proxy_ready
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.464: Set 
protection policy proxy to 0x5627ceb961e0
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.465: 
Attempting to sync USB parameters: 1 0x5627ceb961e0 0x5627ceb76fa0
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.466: 
Listening to signals
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.470: 
InsertedDevicePolicy is: apply-policy
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.470: 
Ensuring allow all
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.481: 
Detecting rule...
(gsd-usb-protection:437340): usb-protection-plugin-DEBUG: 11:03:34.481: 
Adding rule 0

(gsd-usb-protection:437340): usb-protection-plugin-WARNING **: 
11:03:34.484: Error appending USBGuard rule: 
GDBus.Error:org.freedesktop.DBus.Error.Failed: Policy append: rule: Invalid 
parent ID

I've got usbguard 0.7.8+ds-2 instaled. It looks like it doesn't
recognize rule ID 0 as meaning prepend to existing rules.

Here are the D-Bus calls made by gsd-usb-protection:

‣ Type=method_call  Endian=l  Flags=0  Version=1 Cookie=20
  Sender=:1.79980  Destination=:1.923  Path=/org/usbguard1/Policy  
Interface=org.usbguard.Policy1  Member=appendRule
  UniqueName=:1.79980
  MESSAGE "sub" {
  STRING "allow id *:* label "GNOME_SETTINGS_DAEMON_RULE"";
  UINT32 0;
  BOOLEAN true;
  };

‣ Type=signal  Endian=l  Flags=1  Version=1 Cookie=110
  Sender=:1.923  Path=/org/usbguard1  Interface=org.usbguard1  
Member=ExceptionMessage
  UniqueName=:1.923
  MESSAGE "sss" {
  STRING "Policy append";
  STRING "rule";
  STRING "Invalid parent ID";
  };

‣ Type=error  Endian=l  Flags=1  Version=1 Cookie=111  ReplyCookie=20
  Sender=:1.923  Destination=:1.79980
  ErrorName=org.freedesktop.DBus.Error.Failed  ErrorMessage="Policy append: 
rule: Invalid parent ID"
  UniqueName=:1.923
  MESSAGE "s" {
  STRING "Policy append: rule: Invalid parent ID";
  };

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-9-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#967946: gnome-settings-daemon: pulls in usbguard, even though GNOME has no GUI for it and silently blocks devices

[Sam Morris]

Source: gnome-settings-daemon
Followup-For: Bug #967946

gnome-settings-daemon only Suggests: usbguard - so it's not pulled in by
default (unless apt is configured to install suggested packages by
default)?

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-9-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#968390: virtualbox-guest-x11: VBoxDRMClient missing

[Sam Morris]

Package: virtualbox-guest-x11
Version: 6.1.12-dfsg-9
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

VirtualBox guest additions now includes a VBoxDRMClient program that is
missing from the Debian package.

I believe this is used for 3d acceleration under Wayland. I've not had a
change to switch over to Wayland to confirm yet.

Note that upstream installs VBoxDRMClient setuid root and activates it
from VBoxClient --vmsvga; Fedora patch their package to drop the setuid
bit, launch VBoxDRMClient as a systemd service, and activate the service
by udev rules. These changes can be found at
.

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.7.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages virtualbox-guest-x11 depends on:
ii  libc6  2.31-3
ii  libnotify-bin  0.7.9-1
ii  libx11-6   2:1.6.10-3
ii  libxext6   2:1.3.3-1+b2
ii  libxmu62:1.1.2-2+b3
ii  libxt6 1:1.1.5-1+b3
ii  virtualbox-guest-utils 6.1.12-dfsg-9
ii  x11-xserver-utils  7.7+8
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.8-2

virtualbox-guest-x11 recommends no packages.

virtualbox-guest-x11 suggests no packages.

- -- Configuration Files:
/etc/X11/Xsession.d/98vboxadd-xclient changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl82VF8SHHNhbUByb2Jv
dHMub3JnLnVrAAoJENILQgJc2ie5KBkP/RCmH8TOFHyNCqJtYSM3rf5iy6fHF/Bu
i8BVWf0RmHxI5TmYH48vXKz7WWkUnumMbP1BKehPCAmDVFiZ9cZt1adpkK9OCcrw
/cSFhvvikcFYWi0ywYCPQ9Dnzt+XwqBIk/q2gxkylorL2QxOYD5lyJ4I7W8aLkXh
m23APTwOkHXIdt81od5jS8E2RrbYRwrDmJSVrihuhJzMPuNp7pZ5REkSbcjwPhF6
l0V9YWmoy4mZjuccW4u0Ajh2e5OO8fj4mtVwCelP85wstuKVN4dE0je4RtuOHCTD
1LZ+w78r5HWlWMi/0lA9SnZ7S2jNCjdGr9njV2G8mDTrONhK97U7Kh512uXK+QKY
Wq8Pr15Dc1xfHtMv3EXHFIR9XAt92MOQSjdRadW3XWLqCKEqpGMVRU+JZ7mujhBx
tFMvMbObRdFcDDe4SeUHGTdJ+/WY6zwOJS6LzJSFMyyCRAs52SbvblO87RpvI9G2
U4UcjTWeqkXY7QS09IkxGAmXtjJfBGyb9xcnp44d+6dGpLqrM6MqPVr5yi3kZ83D
Gr0HIgFB2iJtieZ1XMw3EgY1W22d8U08lrlLceCwDipqrkCZ3zurkO1iydVC/va/
80VBqfAQXJqH/bCoGveAl8GIzJsLT9m+ToP/JoSVFbB8rq+flDHgJmrM4idO/hKi
YJW5m85VlLCK
=G6vI
-END PGP SIGNATURE-

Bug#874191: gdm3 started users start in wrong context

[Sam Morris]

On Wed, Apr 01, 2020 at 11:48:29AM +0100, Sam Morris wrote:
> Patches available:
> 
> https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/2

This one isn't needed now that libselinux 3.1 is in unstable.

> https://salsa.debian.org/selinux-team/refpolicy/-/merge_requests/10

This one is still needed.

-- 
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#965143: sssd: SSSD 2.3 won't let log in or use sudo

[Sam Morris]

Source: sssd
Followup-For: Bug #965143
Control: -1 + fixed-upstream patch

Upstream things this is https://github.com/SSSD/sssd/pull/5222 which
has been fixed upstream.

https://patch-diff.githubusercontent.com/raw/SSSD/sssd/pull/5222.patch

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-8-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#965143: sssd: SSSD 2.3 won't let log in or use sudo

[Sam Morris]

Package: sssd
Version: 2.3.0-2
Severity: grave
Justification: renders package unusable

This locks me out of my systems.

$ sudo -l
[sudo] password for sam.morris@ad.domain.example: 
Sorry, try again.
[sudo] password for sam.morris@ad.domain.example: 
Sorry, try again.
[sudo] password for sam.morris@ad.domain.example: 
sudo: 3 incorrect password attempts

Each authentication attempt logs the following in sssd_pam.log:

(2020-07-16 18:08:38): [pam] [sysdb_search_user_by_upn_res] (0x0040): 
Search for upn [sam.morris@ad.domain.example] returns more than one result. One 
of the possible reasons can be that several users share the same email address.
(2020-07-16 18:08:38): [pam] [sysdb_search_user_by_upn] (0x0040): Error: 22 
(Invalid argument)
(2020-07-16 18:08:38): [pam] [sysdb_initgroups_by_upn] (0x0040): 
sysdb_search_user_by_upn() failed.
(2020-07-16 18:08:38): [pam] [cache_req_search_cache] (0x0020): CR #12: 
Unable to lookup [sam.morris@ad.domain.example] in cache [22]: Invalid argument
(2020-07-16 18:08:38): [pam] [pam_check_user_search_next] (0x0020): Fatal 
error, killing connection!

My user exists in an Active Directory domain that has a one-way trust
established via FreeIPA.

We do indeed have several users with the same email address. That's
(until now) been a perfectly valid setup (one human has several accounts
for performing different roles and they all have the same email
address).

Downgrading to 2.2.3-3 fixes the problem. It's necessary to remove the
sssd database after downgrading.

I've had a quick scan of the commits between 2.2.3 and 2.3.0 and
nothing's jumped out at me yet. I'll take another look later...

-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), 
(550, 'testing'), (530, 'unstable-debug'), (530, 'unstable'), (500, 
'stable-updates'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages sssd depends on:
ii  python3-sss  2.3.0-2
ii  sssd-ad  2.3.0-2
ii  sssd-common  2.3.0-2
ii  sssd-ipa 2.3.0-2
ii  sssd-krb52.3.0-2
ii  sssd-ldap2.3.0-2
ii  sssd-proxy   2.3.0-2

sssd recommends no packages.

sssd suggests no packages.

-- no debconf information

Bug#965059: Syntax warnings with Python 3.8

[Sam Morris]

Package: python3-yubico
Version: 1.3.3-0.3
Severity: normal

$ ipa user-find sam
/usr/lib/python3/dist-packages/netaddr/strategy/__init__.py:189: SyntaxWarning: 
"is not" with a literal. Did you mean "!="?
  if word_sep is not '':
/usr/lib/python3/dist-packages/yubico/yubikey_usb_hid.py:288: SyntaxWarning: 
"is" with a literal. Did you mean "=="?
  if mode is 'nand':
/usr/lib/python3/dist-packages/yubico/yubikey_usb_hid.py:294: SyntaxWarning: 
"is" with a literal. Did you mean "=="?
  elif mode is 'and':
/usr/lib/python3/dist-packages/yubico/yubikey_usb_hid.py:306: SyntaxWarning: 
"is" with a literal. Did you mean "=="?
  if mode is 'nand':
/usr/lib/python3/dist-packages/yubico/yubikey_config.py:478: SyntaxWarning: 
"is" with a literal. Did you mean "=="?
  if slot is 1:
/usr/lib/python3/dist-packages/yubico/yubikey_config.py:483: SyntaxWarning: 
"is" with a literal. Did you mean "=="?
  elif slot is 2:
[...]

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-8-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-yubico depends on:
ii  python3  3.7.3-1
pn  python3-usb  

python3-yubico recommends no packages.

python3-yubico suggests no packages.

Bug#964388: 'replicated server' entries with CIFS don't work

[Sam Morris]

Source: autofs
Version: 5.1.6-2
Severity: normal

I'm trying to make DFS-replicated CIFS file shares available. In
auto.master I have:

/dfsfile:/etc/auto.dfs   browse

and in auto.dfs I have:

   /dfs/HD-fstype=cifs,sec=krb5i,cruid=$UID,multiuser
://server1.domain.example/HD ://server2.domain.example/HD

but autofs interprets the entire server list as a single location:

Jul 06 16:31:14 kernel: CIFS: Attempting to mount 
//server1.domain.example/HD ://server2.domain.example/HD
Jul 06 16:31:14 kernel: CIFS VFS:  BAD_NETWORK_NAME: 
\\server1.domain.example\HD :
Jul 06 16:31:14 kernel: CIFS VFS: cifs_mount failed w/return code = -2

autofs(5) states:

A mount location can specify multiple hosts for a location,
portentially with a different export path for the same file system.
Historically these different locations  are  read- only and provide
the same replicated file system.

and gives the example of:

Multiple replicated hosts, different (potentially) paths:
 host1:/path/pathA host2:/path/pathB

which I think is the closest matching syntax. But I guess to automount,
CIFS shares don't have a host element, and the server name is given as
the first element to the path, which maybe means that this syntax is
only available for NFS entries...

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-8-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#795281: autofs: Please provide a mechanism to make automount root mount points shared

[Sam Morris]

Tags: patch

On Wed, Aug 12, 2015 at 04:37:04PM +0100, Ian Campbell wrote:
> As described in the final section of
> https://www.kernel.org/doc/Documentation/filesystems/autofs4.txt it is
> necessary to run "mount --make-shared /autofs/mount/point" on systems
> which make use of bind mounts and/or namespaces, or else things start
> spuriously failing with ELOOP.
> 
> Assuming that there is no desire to change the default then having an
> easy way to configure this would be very useful.

Fedora is carrying this patch:

https://src.fedoraproject.org/rpms/autofs/blob/master/f/autofs-5.1.6-make-bind-mounts-propagation-slave-by-default.patch

In addition to making 'slave' the default, it also adds a 'shared' mount
option.

-- 
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#693782: auto.master.d documentation

[Sam Morris]

On Tue, Nov 20, 2012 at 11:17:09AM +0100, Stefan Skoglund wrote:
> The documentation for how to use the 'auto.master.d' feature is really
> non-existing. What exists is a sketch from the designer for what it is
> (or how it should be.)

/etc/auto.master now has comments that describe how to use the feature:

# Include /etc/auto.master.d/*.autofs
# To add an extra map using this mechanism you will need to add
# two configuration items - one /etc/auto.master.d/extra.autofs file
# (using the same line format as the auto.master file)
# and a separate mount map (e.g. /etc/auto.extra or an auto.extra NIS 
map)
# that is referred to by the extra.autofs file.
#
+dir:/etc/auto.master.d

For instance, I have the following:

$ cat /etc/auto.master.d/work.autofs
/workfile:/etc/auto.workbrowse

$ cat /etc/auto.work
server1-share1-fstype=cifs,sec=krb5i,cruid=$CRUID,multiuser 
://server1.example.com/share1
server2-share1-fstype=cifs,sec=krb5i,cruid=$CRUID,multiuser 
://server2.example.com/share1

In addition, auto.master(5) describes the + inclusion feature:

Additionally, a map may be included from its source as if it were itself
present in the master map by including a line of the form:

+[maptype[,format]:map options]

and automount(8) will process the map according to the specification
described below for map entries.

... the format of a master map entry:

mount-point [map-type[,format]:]map [options]

... and describes the 'dir' map-type:

This map type can be used at + master map including notation. The
contents of files under given directory are included to the master
map. The name of file to be included must be ended with ".autofs". A
file will be ignored if its name is not ended with the suffix. In
addition a dot file, a file which name is started with "." is also
    ignored.

-- 
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#963899: Build smbclient against MIT krb5

[Sam Morris]

Package: smbclient
Version: 2:4.9.5+dfsg-1
Severity: wishlist

I don't know how sane this might be, but you don't find out of if you
don't ask, right?

I run into lots of problems trying to use smbclient in my workplace.
They boil down to the fact that Samba's bundled Heimdal library has a
number of missing features compared to MIT Kerberos, including:

 * Support for DIR, KCM and KEYRING credential cache types. These are
   improvements upon the FILE type (all support multiple credential
   caches, as opposed to FILE; KEYRING keeps credentials off disk as
   opposed to DIR; KCM stores credentials in a daemon (UNIX socket
   access isolated by mount namespaces)).
 * Support for includdedir directives when reading configuration.
   Files in /etc/krb5.conf.d and /var/lib/sss/pubconf/krb5.include.d
   (created by freeipa-client and sssd) are ignored.
 * Support for locator plugins. In a multi-site Active Directory
   environment, this causes Kerberos clients to talk to the local site's
   KDCs. This might also apply to FreeIPA multi-location environments
   too.
 * Support for other plugin types. sssd provides localauth, authdata and
   preauth plugins. Admittedly I don't think these would be used by
   smbclient.

For a long time I figured there was nothing to be done about this--Samba
is pretty tightly wedded to Heimdal. However I recently noticed that
Fedora build Samba against krb5, and I figure it should be possible to
do this in Debian.

Since running Samba AD DC built with MIT Kerberos is still an
experimental feature, it's not a good idea to switch the whole source
package over wholesale. But I wonder if it would be possible to build
only smbcliennt with the system libkrb5, so that it can take advantage
of these features (in particular, credential cache types other than
FILE)?

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-8-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages smbclient depends on:
ii  dpkg  1.19.7
ii  libarchive13  3.3.3-4+deb10u1
ii  libbsd0   0.9.1-2
ii  libc6 2.28-10
ii  libgnutls30   3.6.7-4+deb10u4
ii  libpopt0  1.16-12
ii  libreadline7  7.0-5
pn  libreadline8  
pn  libsmbclient  
pn  libtalloc2
pn  libtevent0
pn  libwbclient0  
pn  samba-common  
pn  samba-libs

smbclient recommends no packages.

Versions of packages smbclient suggests:
pn  cifs-utils   
pn  heimdal-clients  

Bug#860151: keepalived: System loses virtual ip address after each systemd-networkd restart

[Sam Morris]

Package: keepalived
Followup-For: Bug #860151

I think this is no longer an issue since systemd 243, which adds
the KeepConfiguration= network option. If set to 'yes' then networkd
won't remove VIPS and such from managed interfaces when it (re)starts.

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-8-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages keepalived depends on:
ii  init-system-helpers  1.56+nmu1
ii  iproute2 4.20.0-2
ii  libc62.28-10
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libip4tc01.8.2-4
ii  libip6tc01.8.2-4
ii  libjson-c3   0.12.1+ds-2
ii  libmnl0  1.0.4-2
ii  libnftnl11   1.1.2-2
ii  libnl-3-200  3.4.0-1
ii  libnl-genl-3-200 3.4.0-1
ii  libpcre2-8-0 10.32-5
pn  libsnmp30
pn  libsnmp35
ii  libssl1.11.1.1d-0+deb10u3
ii  libxtables12 1.8.2-4

Versions of packages keepalived recommends:
pn  ipvsadm  

keepalived suggests no packages.

Bug#963692: /usr/share/info/gnupg.info.gz: Documentation regarding default RSA key size is out of date

[Sam Morris]

Package: gnupg
Version: 2.2.20-1
Severity: minor
File: /usr/share/info/gnupg.info.gz

The documentation for ---default-new-key-algo says that the default is
rsa2048/cert,sign+rsa2048/encr but
gpg-default-to-3072-bit-RSA-keys.patch changes this to 
rsa3072/cert,sign+rsa3072/encr.

I suggest updating the wording so:

  This option can be used to change the default algorithms for key
  generation.  The STRING is similar to the arguments required for
  the command '--quick-add-key' but slightly different.  For example
  the current default of '"rsa3072/cert,sign+rsa3072/encr"' can be changed
  to the value of what we currently call future default, which is
  '"ed25519/cert,sign+cv25519/encr"'.  You need to consult the source code
  to learn the details.  Note that the advanced key generation commands
  can always be used to specify a key algorithm directly.
  
  The default of rsa3072 is specific to Debian. Upstream GPG still
  defaults to rsa2048.


-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), 
(550, 'testing'), (530, 'unstable-debug'), (530, 'unstable'), (500, 
'stable-updates'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages gnupg depends on:
ii  dirmngr 2.2.20-1
ii  gnupg-l10n  2.2.20-1
ii  gnupg-utils 2.2.20-1
ii  gpg 2.2.20-1
ii  gpg-agent   2.2.20-1
ii  gpg-wks-client  2.2.20-1
ii  gpg-wks-server  2.2.20-1
ii  gpgsm   2.2.20-1
ii  gpgv2.2.20-1

gnupg recommends no packages.

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information

Bug#962994: [pcp] Bug#962994: pcp: cron jobs launch pcp in cron's cgroup

[Sam Morris]

On Wed, Jun 17, 2020 at 10:06:39PM +1000, Nathan Scott wrote:
> Digging into that aspect, it seems the PCP configure script has now
> started disabling systemd (!) on Debian for reasons I don't follow.
> 
> Here's a relevant build log:
> https://buildd.debian.org/status/fetch.php?pkg=pcp=amd64=5.1.1-1=1590715276=0
> 
> This is the relevant PCP configure.ac snippet:
> 
> dnl Check for systemd services
> enable_systemd=false
> AC_MSG_CHECKING([if systemd should be used])
> AS_IF([test "x$do_systemd" != "xno"], [
> enable_systemd=true
> 
> PKG_CHECK_VAR([SYSTEMD_SYSTEMUNITDIR], [systemd], [systemdsystemunitdir],
> [pcp_systemdunit_dir=$SYSTEMD_SYSTEMUNITDIR], [enable_systemd=false])
> 
> so, we are (all of a sudden?) taking the enable_systemd=false path
> and looks like it's all downhill from there.

I bet the buildd chroots don't have systemd installed, and you don't
build-depend on it. You probably also want to build-depend on
libsystemd-dev, which ships the sd-daemon.h header used by another check
in configure.ac.

More generally though, it's not great for a Debian package to ship timer
units vs cron jobs based on whether systemd was installed when the
package is built.

This is because some users still prefer to use sysvinit on their Debian
system, in which case nothing will be launching pcp's timer units.

The good news is that it's easy to handle this case by modifying your
cron jobs, for instance:

# Look for and purge old sessions every 30 minutes
09,39 * * * * root   [ -x /usr/lib/php/sessionclean ] && if [ ! -d 
/run/systemd/system ]; then /usr/lib/php/sessionclean; fi

It's also a good idea to check whether the program your cron job
launches is still runnable in order to handle the case where the package
has been removed (which removes the program) but not purged. In this
case, conffiles such as cron jobs will still be present, and root will
receive lots of mail from cron about the missing program. :)

-- 
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#962994: pcp: cron jobs launch pcp in cron's cgroup

[Sam Morris]

Package: pcp
Version: 5.1.1-1
Severity: normal

$ systemctl status cron
● cron.service - Regular background program processing daemon
 Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: 
enabled)
 Active: active (running) since Wed 2020-06-17 09:03:18 BST; 2min 5s ago
   Docs: man:cron(8)
   Main PID: 3499535 (cron)
 IP: 0B in, 0B out
  Tasks: 49 (limit: 38380)
 Memory: 2.4G
CPU: 728ms
 CGroup: /system.slice/cron.service
 ├─2725001 /usr/bin/pmie -b -F -P -l 
/var/log/pcp/pmie/fragarach.domain.example/pmie.log -c config.default
 ├─3241662 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3244857 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -mreexec %Y%m%d.%H.%M
 ├─3249634 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3253479 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3258915 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3262983 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3265468 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3267625 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3270077 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3276784 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3289498 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3314737 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3329439 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3339935 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3350479 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3360898 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3367195 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3384420 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3393600 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3411864 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3415294 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3417448 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3419785 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3440219 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3443004 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3451062 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3453158 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3455206 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3457327 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -mreexec %Y%m%d.%H.%M
 ├─3460418 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3462492 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3464518 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3466563 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3468875 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check %Y%m%d.%H.%M
 ├─3471006 /usr/lib/pcp/bin/pmlogger -N -P -r -T24h10m -c 
config.default -v 100mb -m pmlogger_check 

Bug#668538: RFP: vdsm -- Virtual Desktop and Server Manager

[Sam Morris]

Followup-For: Bug #668538

Updated URL about building VDSM on Debian:
https://www.ovirt.org/develop/developer-guide/vdsm/on-debian.html

The changeset for debian packaging is here:
https://gerrit.ovirt.org/#/c/49257/

This was merged, but the debian packaging was removed from vdsm Git in
April 2016.

Bug#960947: sensors-applet: Please switch from libpanel-applet to libgnome-panel

[Sam Morris]

Thank you for taking care of this!

Sam

Bug#446036: exim4: please compile against openssl instead of gnutls

[Sam Morris]

I can't speak for whether GnuTLS' historical interoperability issues
are still a problem.

I think it is worth noting that OpenSSL 3.0 is available under the
Apache License v2. As such it should now be compatible with GPL'd
software excepting that which is GPLv2-only.

I would like to refer to the blog post "Crytographic Right Answers" <
https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html
>, which makes the following recommendation regarding web site security
(I am generalizing this to apply to TLS in general, yes):

   Use AWS ALB/ELB or OpenSSL, with LetsEncrypt

   [...]

   Otherwise, there was a dark period between 2010 and 2016 where
   OpenSSL might not have been the right answer, but that time has
   passed. OpenSSL has gotten better, and, more importantly, OpenSSL is
   on-the-ball with vulnerability disclosure and response.

   Using anything besides OpenSSL will drastically complicate your
   system for little, no, or even negative security benefit. So just
   keep it simple.

   [...]

   Avoid: offbeat TLS libraries like PolarSSL, GnuTLS, and MatrixSSL.

OpenSSL is also recommended by previous 'cryptographic right answers' 
posts from others over the years (Tomas Ptacek in 2015 and Colin
Percival in 2009). On the other hand, Latacora opens with:

   We’re less interested in empowering developers and a lot more
   pessimistic about the prospects of getting this stuff right.

Which does indicate bias towards secure secure and correct
implementations over user freedom (after all, they recommend paying
Amazon to do to TLS termination for you rather than even trying to do
it yourself with OpenSSL!)

In 2020, I think it's worth revisiting whether sticking with GnuTLS is
the best choice for Debian's users. Perhaps OpenSSL's relicensing makes
the political reason to stay with GnuTLS less important (I'll of course
defer to the opinions of the maintainers here!)

Anyway, if the maintainers would reconsider switching to OpenSSL once
3.0 enters Debian then I'd like to help!

-- 
Sam Morris <https://robots.org.uk/>

Bug#733094: uvcdynctrl still filling the disk

[Sam Morris]

severity 733094 serious
thanks

I just had to rescue a system that had four instances of uvcdynctrl
pegging the CPU to 100% and a full disk (that now prevents gdm from
giving the user a login screen). The log file is full of the same
messages regarding the driver having a slightly buggy implementation.

-- 
Sam Morris 

Bug#958025: gnome-shell: Wayland session never starts

[Sam Morris]

On Fri, 2020-04-17 at 17:08 +0100, Sam Morris wrote:
> Anyway... I'll keep upgrading things and follow up if I figure out
> which package fixes things...

Upgrading libatspi2.0-0 improved things. Although gnome-shell still
hangs, the backtrace is now:

   #0  0x7ff4b79b8b4f in __GI___poll (fds=fds@entry=0x7fffc4ee7df0, 
nfds=nfds@entry=1, timeout=timeout@entry=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29 
   #1  0x7ff4b467ed97 in poll (__timeout=-1, __nfds=1, 
__fds=0x7fffc4ee7df0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46  
  
   #2  read_block (len=8, buf=0x560e38cb2580, fd=53) at ../../src/xcb_in.c:388
   #3  _xcb_in_read_block (c=c@entry=0x560e38cb77b0, buf=0x560e38cb2580, 
len=len@entry=8) at ../../src/xcb_in.c:1075 

   #4  0x7ff4b467cb31 in read_setup (c=0x560e38cb77b0) at 
../../src/xcb_conn.c:177
   #5  xcb_connect_to_fd (fd=fd@entry=53, 
auth_info=auth_info@entry=0x7fffc4ee7f30) at ../../src/xcb_conn.c:359   
   
   #6  0x7ff4b4680ac2 in xcb_connect_to_display_with_auth_info 
(displayname=, auth=0x0, screenp=0x0) at 
../../src/xcb_util.c:532  
   #7  0x7ff48f204b26 in pa_client_conf_from_x11 () from 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-12.2.so 

   #8  0x7ff48f1c64d8 in pa_client_conf_load () from 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-12.2.so 

   #9  0x7ff48f24506b in pa_context_new_with_proplist () from 
/usr/lib/x86_64-linux-gnu/libpulse.so.0 
   
   #10 0x7ff48f2b2584 in gvc_mixer_new_pa_context 
(self=self@entry=0x560e38004f80) at ../subprojects/gvc/gvc-mixer-control.c:3319 
   
   #11 0x7ff48f2b3d0c in gvc_mixer_control_constructor (type=, n_construct_properties=1, construct_params=0x560e38c76400)
 
   at ../subprojects/gvc/gvc-mixer-control.c:3557
   #12 0x7ff4b87d95fc in g_object_new_with_custom_constructor (n_params=1, 
params=0x7fffc4ee8810, class=0x560e38cb1600) at ../../../gobject/gobject.c:1855 
  
   #13 g_object_new_internal (class=class@entry=0x560e38cb1600, 
params=params@entry=0x7fffc4ee8810, n_params=n_params@entry=1) at 
../../../gobject/gobject.c:1935
   #14 0x7ff4b87dae0b in g_object_new_with_properties 
(object_type=94619082364016, n_properties=, names=, values=)  
   at ../../../gobject/gobject.c:2099
  [lots of gjs and mozjs frames]

   After upgrading libpulse0 (which pulled in upgrades of all the
   installed binary packages from the pulseaudio source package) the
   problem is fixed!

   So I guess Breaks could be added to gnome-session to make sure
   libatk1.0-0 and libpulse0 get pulled in when GNOME 3.6 is installed; on
   the other hand, since so few people are likely to run into this problem
   and as you say skewed versions aren't really supportable, I won't be
   offended if you would prefer to close this bug without bloating gnome-
   session's dependencies. :)

   I remain faintly puzlled by the final mixture of X11 display sockets:

   u_str  LISTEN  0  1  /tmp/.X11-unix/X1024   1100515  *  0  
users:(("Xwayland",pid=74039,fd=5))
  u_str  LISTEN  0  1  @/tmp/.X11-unix/X1024  1100514  *  0  
users:(("Xwayland",pid=74039,fd=4))
  u_str  LISTEN  0  1  /tmp/.X11-unix/X1025   1100517  *  0  
users:(("gnome-shell",pid=74013,fd=40))
  u_str  LISTEN  0  1  @/tmp/.X11-unix/X1025  1100516  *  0  
users:(("Xwayland",pid=74039,fd=7))

... but things are definitely working again so I'm only faintly
puzzled. :)

Anyway, thanks for the help!

-- 
Sam Morris 

Bug#958025: gnome-shell: Wayland session never starts

[Sam Morris]

On Fri, 2020-04-17 at 16:19 +0100, Simon McVittie wrote:
> I notice you're using the latest GNOME from testing/unstable, on a
> system where many relevant packages have not been upgraded from 
> stable.

Yes, I usually roll with only the upgrades apt installs itself, and on
the (fairly rare) occasions where problems are caused by version skew
accross a source package I upgrade packages that apt missed by hand.

> On Fri, 17 Apr 2020 at 15:48:51 +0100, Sam Morris wrote:
> > Apr 17 15:16:09 gnome-session-binary[26371]: WARNING: Error
> > creating FIFO: File exists
> 
> From the gnome-session source code, this is something to do with
> gnome-session running sessions as systemd user services, which is new in
> GNOME 3.36. It wouldn't surprise me if this relies on relatively recent
> features or fixes in systemd or a related component.

Just as soon as I bet a grip on how GNOME sessions are started
everytihng changes again! :)

> > ... it seems suspicious that trying to connect to (presumably) Xwayland
> > on the login screen
> 
> AT-SPI :'-(

Indeed, installing some debug symbols reveals:

   #0  0x7f6a55f79b4f in __GI___poll (fds=fds@entry=0x7ffc6c2e5ae0, 
nfds=nfds@entry=1, timeout=timeout@entry=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
   #1  0x7f6a52c41d97 in poll (__timeout=-1, __nfds=1, 
__fds=0x7ffc6c2e5ae0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
   #2  read_block (len=8, buf=0x556e9049b9b0, fd=44) at ../../src/xcb_in.c:388
   #3  _xcb_in_read_block (c=c@entry=0x556e904b85c0, buf=0x556e9049b9b0, 
len=len@entry=8) at ../../src/xcb_in.c:1075
   #4  0x7f6a52c3fb31 in read_setup (c=0x556e904b85c0) at 
../../src/xcb_conn.c:177
   #5  xcb_connect_to_fd (fd=fd@entry=44, 
auth_info=auth_info@entry=0x7ffc6c2e5c20) at ../../src/xcb_conn.c:359
   #6  0x7f6a52c43ac2 in xcb_connect_to_display_with_auth_info 
(displayname=displayname@entry=0x556e9048f260 ":1024", auth=auth@entry=0x0, 
screenp=screenp@entry=0x0)
   at ../../src/xcb_util.c:532
   #7  0x7f6a52c43c3a in xcb_connect 
(displayname=displayname@entry=0x556e9048f260 ":1024", 
screenp=screenp@entry=0x0) at ../../src/xcb_util.c:489
   #8  0x7f6a55a13db2 in _XConnectXCB (dpy=dpy@entry=0x556e904b7370, 
display=display@entry=0x556e9048f260 ":1024", 
screenp=screenp@entry=0x7ffc6c2e5d6c)
   at ../../src/xcb_disp.c:78
   #9  0x7f6a55a04972 in XOpenDisplay (display=0x556e9048f260 ":1024") at 
../../src/OpenDis.c:129
   #10 0x7f6a54751074 in atspi_get_a11y_bus () from 
/usr/lib/x86_64-linux-gnu/libatspi.so.0
   #11 0x7f6a5648a780 in atk_bridge_adaptor_init (argc=, 
argv=) at ../atk-adaptor/bridge.c:1044
   #12 0x556e8f5986c7 in shell_a11y_init () at ../src/main.c:313
   #13 main (argc=, argv=) at ../src/main.c:525

And 'ss' reveals that the socket gnome-shell is trying to connect to is
owned by...

   u_str  LISTEN  01
  
/tmp/.X11-unix/X1024 1037591  * 0   
  users:(("gnome-shell",pid=70011,fd=38))   
 
   u_str  LISTEN  11
 
@/tmp/.X11-unix/X1024 1037590  * 0  
   users:(("gnome-shell",pid=70011,fd=37))  
  

gnome-shell!?

> ii  libatk-bridge2.0-0   2.30.0-5
> ii  libatk1.0-0  2.36.0-2
> 
> One of these relatively-closely-related libraries is 18 months older than
> the other. Perhaps the missing versioned dependency involves ATK/AT-SPI?

No luck so far having updated libatk1.0-0 to match...

> > ii  libegl-mesa0 [libegl-vendor]  18.3.6-2+deb10u1
> > ii  libgl1-mesa-dri   18.3.6-2+deb10u1
> > ii  libglx-mesa0 [libglx-vendor]  20.0.4-2
> 
> This also looks suspicious to me: you're mixing up modules from versions
> of Mesa released 2 years apart.
> 
>     smcv

I've updated these ones too for good measure :)

Anyway... I'll keep upgrading things and follow up if I figure out
which package fixes things...


-- 
Sam Morris 

Bug#958025: gnome-shell: Wayland session never starts

[Sam Morris]

Package: gnome-shell
Version: 3.36.1-5
Severity: important

Since upgrading to 3.36, once GDM starts the login screen does not for
90 seconds. During this time trying to switch to a different VTY with
Ctrl+Alt+F5 etc. doesn't work.

With 'journalctl _UID=$(id -u Debian-gdm)' I see:

Apr 17 15:16:09 systemd[20957]: gnome-session.target: Requested dependency 
OnFailure=gnome-session-failed.target ignored (target units cannot fail).
Apr 17 15:16:09 systemd[20957]: gnome-session-pre.target: Requested 
dependency OnFailure=gnome-session-shutdown.target ignored (target units cannot 
fail).
Apr 17 15:16:09 systemd[20957]: gnome-session-initialized.target: Requested 
dependency OnFailure=gnome-session-shutdown.target ignored (target units cannot 
fail).
Apr 17 15:16:09 systemd[20957]: gnome-session@gnome-initial-setup.target: 
Requested dependency OnFailure=gnome-session-failed.target ignored (target 
units cannot fail).
Apr 17 15:16:09 systemd[20957]: gnome-session-failed.target: Requested 
dependency OnFailure=gnome-session-shutdown.target ignored (target units cannot 
fail).
Apr 17 15:16:09 systemd[20957]: gnome-session-wayland.target: Requested 
dependency OnFailure=gnome-session-shutdown.target ignored (target units cannot 
fail).
Apr 17 15:16:09 systemd[20957]: gnome-session@gnome-login.target: Requested 
dependency OnFailure=gnome-session-failed.target ignored (target units cannot 
fail).
Apr 17 15:16:09 gnome-session[26371]: gnome-session-binary[26371]: WARNING: 
Error creating FIFO: File exists
Apr 17 15:16:09 systemd[20957]: Reached target Session services which 
should run early before the graphical session is brought up.
Apr 17 15:16:09 gnome-session-binary[26371]: WARNING: Error creating FIFO: 
File exists
Apr 17 15:16:09 systemd[20957]: Starting Monitor Session leader for GNOME 
Session...
Apr 17 15:16:09 systemd[20957]: Started Monitor Session leader for GNOME 
Session.
Apr 17 15:16:09 systemd[20957]: Reached target Tasks to be run before GNOME 
Session starts.
Apr 17 15:16:09 gnome-session-c[26378]: Error creating FIFO: File exists
Apr 17 15:16:09 systemd[20957]: Starting GNOME Session Manager (session: 
gnome-login)...
Apr 17 15:16:09 gnome-session[26380]: gnome-session-binary[26380]: WARNING: 
Could not parse desktop file orca-autostart.desktop or it references a not 
found TryExec binary
Apr 17 15:16:09 gnome-session-binary[26380]: WARNING: Could not parse 
desktop file orca-autostart.desktop or it references a not found TryExec binary
Apr 17 15:16:09 systemd[20957]: Started GNOME Session Manager (session: 
gnome-login).
Apr 17 15:16:09 systemd[20957]: Reached target GNOME Session Manager is 
ready.
Apr 17 15:16:09 systemd[20957]: Starting GNOME Shell on Wayland...
Apr 17 15:16:09 gnome-shell[26385]: Failed to obtain high priority context
Apr 17 15:16:09 gnome-shell[26385]: Failed to obtain high priority context

... then the delay, then:

Apr 17 15:17:39 systemd[20957]: gnome-shell-wayland.service: start 
operation timed out. Terminating.
Apr 17 15:17:44 systemd[20957]: gnome-shell-wayland.service: State 
'stop-sigterm' timed out. Killing.
Apr 17 15:17:44 systemd[20957]: gnome-shell-wayland.service: Killing 
process 26385 (gnome-shell) with signal SIGKILL.
Apr 17 15:17:44 systemd[20957]: gnome-shell-wayland.service: Killing 
process 26389 (gdbus) with signal SIGKILL.
Apr 17 15:17:44 systemd[20957]: gnome-shell-wayland.service: Main process 
exited, code=killed, status=9/KILL
Apr 17 15:17:44 systemd[20957]: gnome-shell-wayland.service: Failed with 
result 'timeout'.
Apr 17 15:17:44 systemd[20957]: Failed to start GNOME Shell on Wayland.
Apr 17 15:17:44 systemd[20957]: Dependency failed for GNOME Shell on 
Wayland.
Apr 17 15:17:44 systemd[20957]: Dependency failed for GNOME Wayland Session.
Apr 17 15:17:44 systemd[20957]: Dependency failed for GNOME Wayland Session 
(session: gnome-login).
Apr 17 15:17:44 systemd[20957]: gnome-session-wayland@gnome-login.target: 
Job gnome-session-wayland@gnome-login.target/start failed with result 
'dependency'.
Apr 17 15:17:44 systemd[20957]: gnome-session-wayland.target: Job 
gnome-session-wayland.target/start failed with result 'dependency'.
Apr 17 15:17:44 systemd[20957]: gnome-shell-wayland.target: Job 
gnome-shell-wayland.target/start failed with result 'dependency'.

I don't know of a good way to debug what is causing gnome-shell to get
stuck. I did get this backtrace from it:

#0  0x7f24c9031b4f in __GI___poll (fds=0x7ffd85431130, nfds=1, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 
  
#1  0x7f24c5d2ed97 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1  

 
#2  0x7f24c5d2cb31 in xcb_connect_to_fd () from 
/usr/lib/x86_64-linux-gnu/libxcb.so.1  

Bug#958017: libpango-1.0-0: Crash in pango_font_get_hb_font

[Sam Morris]

Package: libpango-1.0-0
Version: 1.44.7-3
Followup-For: Bug #958017
Control: -1 severity minor

After upgrading libpangocairo-1.0-0 to the version in unstable,
pango-view gives some more useful messages:

(pango-view:303404): GLib-GObject-WARNING **: 13:40:03.869: specified class 
size for type 'PangoCairoFcFont' is smaller than the parent type's 
'PangoFcFont' class size

(pango-view:303404): GLib-GObject-CRITICAL **: 13:40:03.869: 
g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE 
(instance_type)' failed

(pango-view:303404): GLib-CRITICAL **: 13:40:03.869: g_once_init_leave: 
assertion 'result != 0' failed

(pango-view:303404): GLib-GObject-CRITICAL **: 13:40:03.869: 
g_object_new_valist: assertion 'G_TYPE_IS_OBJECT (object_type)' failed

So I think the crash is caused by the version skew between the
different pango libraries.

After installing libpangoft2-1.0-0 (which pulls in libharfbuzz0b as
well), pango-view and other programs work again.

-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), 
(550, 'testing'), (530, 'unstable-debug'), (530, 'unstable'), (500, 
'stable-updates'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages libpango-1.0-0 depends on:
ii  fontconfig 2.13.1-2
ii  libc6  2.30-4
ii  libfribidi01.0.5-3.1+deb10u1
ii  libglib2.0-0   2.64.1-1
ii  libharfbuzz0b  2.3.1-1
ii  libthai0   0.1.28-2

libpango-1.0-0 recommends no packages.

libpango-1.0-0 suggests no packages.

-- no debconf information

Bug#958017: libpango-1.0-0: Crash in pango_font_get_hb_font

[Sam Morris]

Package: libpango-1.0-0
Version: 1.44.7-3
Severity: grave
Justification: renders package unusable

After upgrading libpango-1.0-0 from version 1.42.4-7~deb10u1 to version
1.44.7, gnome-terminal-server will no longer start. It crashes with:

#0  0x in ?? ()
#1  0x7fa7b8049383 in pango_font_get_hb_font 
(font=font@entry=0x558d8a9a9860) at ../pango/fonts.c:1908
#2  0x7fa7b8063173 in pango_font_get_hb_font_for_context 
(context=0x7ffcb2ff2fd0, font=0x558d8a9a9860) at ../pango/pangofc-shape.c:345
#3  pango_hb_shape (font=0x558d8a9a9860, 
item_text=item_text@entry=0x558d8a6826f0 "!", item_length=item_length@entry=1, 
analysis=analysis@entry=0x558d8a914110, glyphs=glyphs@entry=0x558d8a75b180, 
paragraph_text=paragraph_text@entry=0x558d8a6826f0 "!", paragraph_length=1) at 
../pango/pangofc-shape.c:345
#4  0x7fa7b80629ea in pango_shape_with_flags (item_text=0x558d8a6826f0 
"!", item_length=1, paragraph_text=, paragraph_length=1, 
analysis=analysis@entry=0x558d8a914110, glyphs=glyphs@entry=0x558d8a75b180, 
flags=PANGO_SHAPE_ROUND_POSITIONS) at ../pango/shape.c:205
#5  0x7fa7b8053a33 in shape_run (line=line@entry=0x558d8a92a5e0, 
state=state@entry=0x7ffcb2ff3580, item=item@entry=0x558d8a914100) at 
../pango/pango-layout.c:3354
#6  0x7fa7b8055e78 in process_item (layout=layout@entry=0x558d8a65a400, 
line=line@entry=0x558d8a92a5e0, state=state@entry=0x7ffcb2ff3580, 
force_fit=force_fit@entry=1, no_break_at_end=no_break_at_end@entry=0) at 
../pango/pango-layout.c:3633
#7  0x7fa7b8057f6d in process_line (state=0x7ffcb2ff3580, 
layout=0x558d8a65a400) at ../pango/pango-layout.c:3951
#8  pango_layout_check_lines (layout=) at 
../pango/pango-layout.c:4315
#9  pango_layout_check_lines (layout=) at 
../pango/pango-layout.c:4175
#10 0x7fa7b8059a59 in pango_layout_get_extents_internal 
(layout=0x558d8a65a400, ink_rect=ink_rect@entry=0x0, 
logical_rect=logical_rect@entry=0x7ffcb2ff3720, 
line_extents=line_extents@entry=0x0) at ../pango/pango-layout.c:2623
#11 0x7fa7b8059e7c in pango_layout_get_extents (layout=, 
ink_rect=ink_rect@entry=0x0, logical_rect=logical_rect@entry=0x7ffcb2ff3720) at 
../pango/pango-layout.c:2817
#12 0x7fa7b88a1e00 in font_info_measure_font (info=0x558d8a8e9c00) at 
../src/vtedraw.cc:398
#13 font_info_allocate (context=0x558d8a8e9700) at ../src/vtedraw.cc:448
#14 font_info_find_for_context (context=0x558d8a8e9700) at 
../src/vtedraw.cc:612
#15 font_info_create_for_context (fontconfig_timestamp=, 
language=, desc=0x1, context=0x558d8a8e9700) at 
../src/vtedraw.cc:657
#16 font_info_create_for_screen (language=, desc=0x1, 
screen=) at ../src/vtedraw.cc:668
#17 font_info_create_for_widget (widget=widget@entry=0x558d8a92c320, 
desc=desc@entry=0x558d8a993560) at ../src/vtedraw.cc:679
#18 0x7fa7b88a2403 in _vte_draw_set_text_font (draw=0x558d8a9211c0, 
widget=0x558d8a92c320, fontdesc=0x558d8a993560, cell_width_scale=1, 
cell_height_scale=1) at ../src/vtedraw.cc:910
#19 0x7fa7b888ffd6 in vte::terminal::Terminal::ensure_font 
(this=0x558d8a92e000) at /usr/include/c++/9/bits/unique_ptr.h:360
#20 vte::terminal::Terminal::ensure_font (this=this@entry=0x558d8a92e000) 
at ../src/vte.cc:7318
#21 0x7fa7b88a985e in vte::terminal::Terminal::get_cell_width 
(this=0x558d8a92e000) at ../src/vteinternal.hh:1248
#22 vte_terminal_get_char_width (terminal=) at 
../src/vtegtk.cc:3447
#23 0x558d8a1925d8 in ?? ()
#24 0x558d8a198dfc in ?? ()
#25 0x558d8a19bfb5 in ?? ()
#26 0x558d8a19d713 in ?? ()
#27 0x7fa7b5ecaccd in ?? () from /usr/lib/x86_64-linux-gnu/libffi.so.7
#28 0x7fa7b5eca25a in ?? () from /usr/lib/x86_64-linux-gnu/libffi.so.7
#29 0x7fa7b7dd17fc in g_cclosure_marshal_generic 
(closure=closure@entry=0x558d8a85d470, return_gvalue=return_gvalue@entry=0x0, 
n_param_values=n_param_values@entry=3, 
param_values=param_values@entry=0x7ffcb2ff3db0, 
invocation_hint=invocation_hint@entry=0x7ffcb2ff3d30, 
marshal_data=marshal_data@entry=0x0) at ../../../gobject/gclosure.c:1500
#30 0x7fa7b7dd0fd2 in g_closure_invoke (closure=0x558d8a85d470, 
return_value=0x0, n_param_values=3, param_values=0x7ffcb2ff3db0, 
invocation_hint=0x7ffcb2ff3d30) at ../../../gobject/gclosure.c:810
#31 0x7fa7b7de41b3 in signal_emit_unlocked_R 
(node=node@entry=0x558d8a5ffe70, detail=detail@entry=0, 
instance=instance@entry=0x558d8a8d82a0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7ffcb2ff3db0) at 
../../../gobject/gsignal.c:3812
#32 0x7fa7b7def54f in g_signal_emit_valist 
(instance=instance@entry=0x558d8a8d82a0, signal_id=signal_id@entry=252, 
detail=detail@entry=0, var_args=var_args@entry=0x7ffcb2ff3ff8) at 
../../../gobject/gsignal.c:3498
#33 0x7fa7b7df098c in g_signal_emit_by_name (instance=0x558d8a8d82a0, 
detailed_signal=0x558d8a1a7bac "screen-switched") at 

Bug#955541: Login fails for a user name with non-ascii characters

[Sam Morris]

Package: systemd
Followup-For: Bug #955541
Control: affects -1 + sssd

This also prevents logging in using Active Directory credentials with
sssd. This is because sssd synthesizes an AD user's user name with:

CONCAT(SAM-Account-Name, '@', DNS Domain Name)

This also applies to group names.

It's worth remarking that a user or group SAM-Account-Name can contain
other characters that systemd isn't happy about such as commas and
spaces.

-- Package-specific info:

-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), 
(550, 'testing'), (530, 'unstable-debug'), (530, 'unstable'), (500, 
'stable-updates'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.30-2
ii  libcap2  1:2.25-2
ii  libcrypt11:4.4.15-1
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.12-2
ii  libgpg-error01.35-1
ii  libidn2-02.0.5-1+deb10u1
ii  libip4tc21.8.3-2~bpo10+1
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.34-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.3-1
ii  libselinux1  3.0-2.1
ii  libsystemd0  245.2-1.1
ii  mount2.34-0.1
ii  util-linux   2.34-0.1

Versions of packages systemd recommends:
ii  dbus  1.12.16-1

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133+deb10u1
ii  libnss-systemd   245.2-1.1
hi  libpam-systemd   245.2-1.1
ii  udev 244.3-1

-- Configuration Files:
/etc/pam.d/systemd-user changed [not included]

-- no debconf information

Bug#874191: gdm3 started users start in wrong context

[Sam Morris]

Package: selinux-policy-default
Followup-For: Bug #874191

Patches available:

https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/2
https://salsa.debian.org/selinux-team/refpolicy/-/merge_requests/10

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-8-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages selinux-policy-default depends on:
ii  libselinux1  2.8-1+b1
ii  libsemanage1 2.8-2
ii  libsepol12.8-1
pn  policycoreutils  
pn  selinux-utils

Versions of packages selinux-policy-default recommends:
pn  checkpolicy  
pn  setools  

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

Bug#874191: gdm3 started users start in wrong context

[Sam Morris]

Package: selinux-policy-default
Version: 2:2.20190201-7
Followup-For: Bug #874191
Control: -1 + patch

I have fixed this by making the following changes:

 1. Patch libselinux with



 2. Modify /etc/selinux/default/contexts/users/* by adding the following lines 
(taken from my Fedora machine)

$ grep init_t /etc/selinux/default/contexts/users
/etc/selinux/default/contexts/users/guest_u:system_r:init_t:s0 
guest_r:guest_t:s0
/etc/selinux/default/contexts/users/staff_u:system_r:init_t:s0 
staff_r:staff_t:s0
/etc/selinux/default/contexts/users/unconfined_u:system_r:init_t:s0 
unconfined_r:unconfined_t:s0
/etc/selinux/default/contexts/users/user_u:system_r:init_t:s0 
user_r:user_t:s0
/etc/selinux/default/contexts/users/xguest_u:system_r:init_t:s0 
xguest_r:xguest_t:s0

 3. Reboot the machine (I don't know why a simple 'loginctl teminate-user
$USER' followed by logging in is not sufficient, any ideas?)

As for the purpose of that patch; see
. Note the ERANGE error
when writing to /sys/fs/selinux/user:

$ strace -s 2048 python3 -c 'import selinux; 
selinux.get_ordered_context_list("unconfined_u", "system_u:system_r:init_t:s0")'
[...]
openat(AT_FDCWD, "/etc/selinux/config", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=584, ...}) = 0
read(3, "# This file controls the state of SELinux on the system.\n# 
SELINUX= can take one of these three values:\n# enforcing - SELinux security 
policy is enforced.\n# permissive -   SELinux prints warnings instead of 
enforcing.\n# disabled - No SELinux policy is loaded.  
\nSELINUX=permissive\n# SELINUXTYPE= can take one of these two values:\n# 
default -   equivalent to the old strict and targeted policies\n# mls   
  - Multi-Level Security (for military and educational use)\n# src - 
Custom policy built from   
source\nSELINUXTYPE=default\n\n# SETLOCALDEFS= Check local definition   
  changes\nSETLOCALDEFS=0\n", 4096) = 584
read(3, "", 4096)   = 0
close(3)= 0
futex(0x7f546b70db40, FUTEX_WAKE_PRIVATE, 2147483647) = 0
access("/var/run/setrans/.setrans-unix", F_OK) = -1 ENOENT (No such file or 
directory)
futex(0x7f546b70dbc8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "/sys/fs/selinux/user", O_RDWR|O_CLOEXEC) = 3
write(3, "system_u:system_r:init_t:s0 unconfined_u", 40) = -1 ERANGE 
(Numerical result out of range)
close(3)= 0
openat(AT_FDCWD, "/etc/selinux/default/contexts/failsafe_context", 
O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
read(3, "sysadm_r:sysadm_t:s0\n", 4096) = 21
close(3)= 0
openat(AT_FDCWD, "/sys/fs/selinux/context", O_RDWR|O_CLOEXEC) = 3
write(3, "unconfined_u:sysadm_r:sysadm_t:s0\0", 34) = -1 EINVAL (Invalid 
argument)
close(3)

This matches one of the comments,

"On our experimental Ubuntu 18.04.3 LTS machine running SELinux with
latest official reference policy, we always get pam_selinux.so
complaining “unable to get valid context for gdm” during system
bootup.  And we found it is the security_compute_user() hits the 4k
page size bound with error -ERANGE from sel_write_user().
Specifically, we intend to transition from
“system_u:system_r:init_t” to “system_u:system_r:xdm_t” in order to
run the systemd user instance for system user gdm. With some
instruments in the kernel, we realize we need roughly 16k for
complete set of reachable contexts."

and

I believe Fedora has worked around the issue by altering their
policy to restrict outbound transitions from init_t and other
unconfined domains to only legitimate ones.

And indeed, on my Fedora machine the write is successful and is followed
by a read that returns 19 contexts.

So.

Rather than figuring out how Fedora modified refpolicy to make the transitions
fit into a single page, applying the patch above does the job. But refpolicy
must still be modified by adding entries for init_t to the selinux user default
context files as descibed above (refer to Fedora's versions of these files at
;
it looks like Fedora are keeping their modifications directly in that repo
rather than as a seriers of patches to be applied to vanilla refpolicy?)

-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), 
(550, 'testing'), (530, 'unstable-debug'), (530, 'unstable'), (500, 
'stable-updates'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 

Bug#874191: gdm3 started users start in wrong context

[Sam Morris]

Package: selinux-policy-default
Version: 2:2.20190201-7
Followup-For: Bug #874191

I realised that the log messages I provided above refer to gdm's systemd
--user instance.

Looking more carefully, on the Fedora system I see:

systemd[1]: Starting User Manager for UID 167301...
audit[236830]: USER_ACCT pid=236830 uid=0 auid=4294967295 ses=4294967295 
subj=system_u:system_r:init_t:s0 msg='op=PAM:accounting 
grantors=pam_unix,pam_sss,pam_permit acct="sam" exe="/usr/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=success'
systemd[236830]: pam_selinux(systemd-user:session): Open Session
systemd[236830]: pam_selinux(systemd-user:session): Username= sam SELinux 
User= unconfined_u Level= s0-s0:c0.c1023
systemd[236830]: pam_selinux(systemd-user:session): Set executable context: 
[] -> [unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023]
systemd[236830]: pam_selinux(systemd-user:session): Security Context 
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Assigned
audit[236830]: USER_ROLE_CHANGE pid=236830 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='pam: 
default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
systemd[236830]: pam_selinux(systemd-user:session): conversation failed
systemd[236830]: pam_selinux(systemd-user:session): Set key creation 
context to unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
systemd[236830]: pam_selinux(systemd-user:session): Key Creation Context 
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Assigned
systemd[236830]: pam_selinux(systemd-user:session): conversation failed
systemd[236830]: pam_unix(systemd-user:session): session opened for user 
sam by (uid=0)
audit[236830]: USER_START pid=236830 uid=0 auid=167301 ses=13 
subj=system_u:system_r:init_t:s0 msg='op=PAM:session_open 
grantors=pam_selinux,pam_selinux,pam_loginuid,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_sss
 acct="sam" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? 
res=success'

Note that we have "Username= sam" so we're looking at the right messages
this time! Based on this it looks like the mechanism by which 'systemd
--user' transitions from init_t to unconfined_t is via pam_selinux.so.

By contrast, when logging on to my Debian system:

audit[9657]: USER_ACCT pid=9657 uid=0 auid=4294967295 ses=4294967295 
subj=system_u:system_r:init_t:s0 msg='op=PAM:accounting 
grantors=pam_permit,pam_sss acct="sam.morris@ad.domain.example" 
exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
audit[9657]: CRED_ACQ pid=9657 uid=0 auid=4294967295 ses=4294967295 
subj=system_u:system_r:init_t:s0 msg='op=PAM:setcred grantors=pam_permit 
acct="sam.morris@ad.domain.example" exe="/lib/systemd/systemd" hostname=? 
addr=? terminal=? res=success'
systemd[9657]: pam_selinux(systemd-user:session): Open Session
audit[8280]: AVC avc:  denied  { read } for  pid=8280 comm="polkitd" 
name="userdb" dev="tmpfs" ino=18467 scontext=system_u:system_r:policykit_t:s0 
tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir permissive=1
audit[8280]: AVC avc:  denied  { map } for  pid=8280 comm="polkitd" 
path="/etc/passwd" dev="dm-2" ino=133411 
scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:object_r:etc_t:s0 
tclass=file permissive=1
audit[8280]: AVC avc:  denied  { connectto } for  pid=8280 comm="polkitd" 
path="/run/systemd/userdb/io.systemd.DynamicUser" 
scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:system_r:init_t:s0 
tclass=unix_stream_socket permissive=1
systemd[9657]: pam_selinux(systemd-user:session): Username= 
sam.morris@ad.domain.example SELinux User= unconfined_u Level= s0-s0:c0.c1023
systemd[9657]: pam_selinux(systemd-user:session): Unable to get valid 
context for sam.morris@ad.domain.example
systemd[9657]: pam_selinux(systemd-user:session): conversation failed
systemd[9657]: pam_unix(systemd-user:session): session opened for user 
sam.morris@ad.domain.example by (uid=0)
audit[9657]: USER_START pid=9657 uid=0 auid=876099160 ses=10 
subj=system_u:system_r:init_t:s0 msg='op=PAM:session_open 
grantors=pam_selinux,pam_selinux,pam_loginuid,pam_limits,pam_permit,pam_unix,pam_systemd
 acct="sam.morris@ad.domain.example" exe="/lib/systemd/systemd" hostname=? 
addr=? terminal=? res=success'

I can reproduce this with the test program at
:

$ build/se
user=sam.morris@ad.domain.example
seuser=unconfined_u; level=s0-s0:c0.c1023
get_ordered_context_list_with_level: Invalid argument

Perhaps this is expected, since there is no entry for init_t in
/etc/selinux/default/contexts/default_contexts; on the other hand,
adding an entry such as:

system_u:system_r:init_t:s0 user_r:user_t:s0 staff_r:staff_t:s0 

Bug#874191: gdm3 started users start in wrong context

[Sam Morris]

Package: selinux-policy-default
Version: 2:2.20190201-7
Followup-For: Bug #874191

I've noticed that the processes that are part of my login session have
the correct label. But systemd --user (and the processes underneath it)
largely run with init_t and initrc_t.

Adding 'verbose debug' to the 'pam_selinux.so open' line in
/etc/pam.d/systemd-user reveals:

systemd[140316]: pam_selinux(systemd-user:session): Open Session
systemd[140316]: pam_selinux(systemd-user:session): Username= Debian-gdm 
SELinux User= unconfined_u Level= s0-s0:c0.c1023
systemd[140316]: pam_selinux(systemd-user:session): Unable to get valid 
context for Debian-gdm
systemd[140316]: pam_selinux(systemd-user:session): conversation failed
systemd[140316]: pam_unix(systemd-user:session): session opened for user 
Debian-gdm by (uid=0)

By contrast, on a system running Fedora, systemd --user and most of its
child processes are running with the expected label, and these messages
are logged:

systemd[224172]: pam_selinux(systemd-user:session): Open Session
systemd[224172]: pam_selinux(systemd-user:session): Username= gdm SELinux 
User= unconfined_u Level= s0-s0:c0.c1023
systemd[224172]: pam_selinux(systemd-user:session): Set executable context: 
[] -> [unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023]
systemd[224172]: pam_selinux(systemd-user:session): Security Context 
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Assigned
systemd[224172]: pam_selinux(systemd-user:session): conversation failed
systemd[224172]: pam_selinux(systemd-user:session): Set key creation 
context to unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
systemd[224172]: pam_selinux(systemd-user:session): Key Creation Context 
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Assigned
systemd[224172]: pam_selinux(systemd-user:session): conversation failed

Here's a handy command for examining the relationship between parent
process, login session, user and selinux context:

$ ps f -e -o user,lsession,label,cmd
USER SESSION LABEL   CMD
root -   system_u:system_r:kernel_t:s0   [kthreadd]
root -   system_u:system_r:kernel_t:s0\_ [rcu_gp]
root -   system_u:system_r:kernel_t:s0\_ [rcu_par_gp]
root -   system_u:system_r:kernel_t:s0\_ [kworker/0:0H]
root -   system_u:system_r:kernel_t:s0\_ [mm_percpu_wq]
root -   system_u:system_r:kernel_t:s0\_ [ksoftirqd/0]
root -   system_u:system_r:kernel_t:s0\_ [rcu_sched]
root -   system_u:system_r:kernel_t:s0\_ [migration/0]
root -   system_u:system_r:kernel_t:s0\_ [cpuhp/0]
root -   system_u:system_r:kernel_t:s0\_ [cpuhp/1]
root -   system_u:system_r:kernel_t:s0\_ [migration/1]
root -   system_u:system_r:kernel_t:s0\_ [ksoftirqd/1]
root -   system_u:system_r:kernel_t:s0\_ 
[kworker/1:0H-kblockd]
root -   system_u:system_r:kernel_t:s0\_ [cpuhp/2]
root -   system_u:system_r:kernel_t:s0\_ [migration/2]
root -   system_u:system_r:kernel_t:s0\_ [ksoftirqd/2]
root -   system_u:system_r:kernel_t:s0\_ 
[kworker/2:0H-events_highpri]
root -   system_u:system_r:kernel_t:s0\_ [cpuhp/3]
root -   system_u:system_r:kernel_t:s0\_ [migration/3]
root -   system_u:system_r:kernel_t:s0\_ [ksoftirqd/3]
root -   system_u:system_r:kernel_t:s0\_ 
[kworker/3:0H-events_highpri]
root -   system_u:system_r:kernel_t:s0\_ [kdevtmpfs]
root -   system_u:system_r:kernel_t:s0\_ [netns]
root -   system_u:system_r:kernel_t:s0\_ [kauditd]
root -   system_u:system_r:kernel_t:s0\_ [khungtaskd]
root -   system_u:system_r:kernel_t:s0\_ [oom_reaper]
root -   system_u:system_r:kernel_t:s0\_ [writeback]
root -   system_u:system_r:kernel_t:s0\_ [kcompactd0]
root -   system_u:system_r:kernel_t:s0\_ [ksmd]
root -   system_u:system_r:kernel_t:s0\_ [khugepaged]
root -   system_u:system_r:kernel_t:s0\_ [kintegrityd]
root -   system_u:system_r:kernel_t:s0\_ [kblockd]
root -   system_u:system_r:kernel_t:s0\_ [blkcg_punt_bio]
root -   system_u:system_r:kernel_t:s0\_ [edac-poller]
root -   system_u:system_r:kernel_t:s0\_ [devfreq_wq]
root -   system_u:system_r:kernel_t:s0\_ [kswapd0]
root -   system_u:system_r:kernel_t:s0\_ [kthrotld]
root -   system_u:system_r:kernel_t:s0\_ [irq/122-aerdrv]
root -   

Bug#953070: RFP: source-to-image -- toolkit for building reproducible container images from source code

[Sam Morris]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: source-to-image
  Version : 1.2.0
  Upstream Author : Various
* URL : https://github.com/openshift/source-to-image
* License : Apache 2.0
  Programming Lang: Go
  Description : toolkit for building reproducible container images from 
source code

Source-to-Image (S2I) S2I produces ready-to-run images by injecting
source code into a container image and letting the container prepare
that source code for execution. By creating self-assembling builder
images, you can version and control your build environments exactly like
you use container images to version your runtime environments.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl5fAmwSHHNhbUByb2Jv
dHMub3JnLnVrAAoJENILQgJc2ie5Qj4P+gO9RW6HwqDIewsik99hWGMHN8C55ue0
AhH5dHLJRvAYW7R+0b279tJRbRDJwqYKCYubDNwBHYM8rw+dF+jbQwxJTDocb/GG
zgz0UEYGoak2+YNVCynAFKbJ/OwOA+WUq9Dssp0SU1kcifTuZQtRFImwSOAIhxMm
3sediKtS41bpoFBML4CZ7MG6BxJ/e/uUgvxFep/G9SLAWbP98XolEmBLPmbFIqJg
K8JH2TNGJQQ/MXP1FTMVl9RXPGuBSP6roxMQM4hgoxLeqHbMYnoB1OmNI6Xgb12a
RDrrhK60l3HQsnj0sYtWIioPqIH/bcpOKvZZZhp3VR2MoT+z2iVrxYh9BFHQjzQw
d4epcPBf8UEkl6FTZyFWYtIWLJA51w6FbswgZ7BWGojsRbM5lkY3FPAEnzVGKKji
oz+qHZ8gqzZWxqlY27t2k9LzMkbG7r4LjnfO1avcZsAubRlSLyFRKFrw0qRvV37H
WyXPSGnXIg8NyTk3St9EP7tNWX04nfD2eJwVe+r0wokIj2YZCvXf9rxSBXWNz3sZ
gh38Kh0MpDeLReFsnloOSAm5oaYgdymTu+PrUPWJ/CW1uI/bFktGohLU8lYD6Lju
Yt/ktyc/QGmE2w8FzRkKrkqZrSX53PfSvoXX3E7j+15FokBjME0zn61/pKUs+T8w
QiBq0EYHAr4v
=MiI4
-END PGP SIGNATURE-

Bug#950831: cockpit: Should recommend realmd

[Sam Morris]

Package: cockpit
Version: 212-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

My machine is joined to a FreeIPA realm, but Cockpit isn't aware of
this. After I installed realmd, Cockpit correctly shows information
about the realm. I think cockpit should Recommend realmd so that it's
installed by default.

- -- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable-debug'), (550, 'stable'), 
(530, 'testing-debug'), (530, 'testing'), (520, 'unstable-debug'), (520, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages cockpit depends on:
ii  cockpit-bridge  212-1
ii  cockpit-system  212-1
ii  cockpit-ws  212-1

Versions of packages cockpit recommends:
ii  cockpit-dashboard   212-1
ii  cockpit-networkmanager  212-1
ii  cockpit-packagekit  212-1
ii  cockpit-storaged212-1

Versions of packages cockpit suggests:
pn  cockpit-doc   
pn  cockpit-docker
pn  cockpit-machines  
pn  cockpit-pcp   
ii  xdg-utils 1.1.3-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl49I+gSHHNhbUByb2Jv
dHMub3JnLnVrAAoJENILQgJc2ie5myQQAIbgzUkfBp8JiuRuOtVxgldZXGZ5ygPf
FrCJBCN5Z0nS9z77D5IQJC8QPKdSlHRHQ5cw8rfHV7FSxx+fYA1nPe2kWrdXxM4t
N+pZqCwEvu9Jl5CfqKRi2dyxAXq5hb7jHNHewcMMkq3bmJ/gDxQw1zf3BYa9pDpK
VVoJnqVZxKA9t0MlmjtbA+9JXRH6K2x9fBUDWgn3sABFnOdzwEGOXrBKgFx8K81r
pJcq/1V2Fm9vEJlpTdXxB2xZ1tU1SRFV8WYC3qaBUD34Qq59KQBH0EevEtBOOTE5
4TGN04Iufp8YX9c/yGCrBlipQ4c7muvXMfzb1CtocYti0wedLIcjbUZSHJkeWWcw
ajaiXvimW9QebWsl2l+7I61Zny84HDEUr38YaRIrXga3NEFEvdd8xd3PT6WOyI5I
V2y0wDEx4PvmDC4i1YRLViGNyIp9gMa5XdLAAuselFxhCuMROnrMb5tgCiluZ52o
Nsa1EWGskXfMz6XSId+hm6KiXhR62Rs++/6kTE56cswXMOUhuayIZJMI3V9eGru9
DusD4BoLo5PM+L8GpDuYw+D4gcUg3u74RFxxLZqLegG84KB4f9y/fQOGoP3DFV5R
bxGobRrOcegFWZRm6bww4pqCxIt/JcuaVqksA+1Xjt4kYkVR4WZlGBdciux8m+Iy
cmraIQjafx/y
=DdyZ
-END PGP SIGNATURE-

Bug#946843: virtualbox-guest-x11: VBoxClient --clipboard terminates silently

[Sam Morris]

Package: virtualbox-guest-x11
Version: 6.1.0-dfsg-3
Followup-For: Bug #946843

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I started seeing this too at around the same time. VBoxClient outputs
the following:

$ VBoxClient -v --clipboard -f 
Shared Clipboard: Starting X11 event thread
Shared Clipboard: Stopping X11 event thread ...
Shared Clipboard: X11 event thread terminated successfully
Error connecting to host service, rc=VERR_NOT_IMPLEMENTED
Service terminated abnormally with VERR_NOT_IMPLEMENTED
Running service failed: VERR_NOT_IMPLEMENTED

There is a forum post with the same symptoms, but it has not yet recieved
any response: https://forums.virtualbox.org/viewtopic.php?f=3=96309

- -- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable-debug'), (550, 'stable'), 
(530, 'testing-debug'), (530, 'testing'), (520, 'unstable-debug'), (520, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages virtualbox-guest-x11 depends on:
ii  libc6  2.29-7
ii  libnotify-bin  0.7.7-4
ii  libx11-6   2:1.6.7-1
ii  libxext6   2:1.3.3-1+b2
ii  libxmu62:1.1.2-2+b3
ii  libxrandr2 2:1.5.1-1
ii  libxt6 1:1.1.5-1+b3
ii  virtualbox-guest-utils 6.1.0-dfsg-3
ii  x11-xserver-utils  7.7+8
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.4-1

virtualbox-guest-x11 recommends no packages.

virtualbox-guest-x11 suggests no packages.

- -- Configuration Files:
/etc/X11/Xsession.d/98vboxadd-xclient changed:
in_virtual_machine()
{
if [ -z "$(lspci -d 80ee:cafe)" ]; then
echo "VirtualBox Additions disabled, not in a Virtual Machine" >&2
return 1
fi
return 0
}
in_virtual_machine || return
for i in $HOME/.vboxclient-*.pid; do
test -w $i || rm -f $i
done
if ! test -c /dev/vboxguest 2>/dev/null; then
   # Do not start if the kernel module is not present.
   # Execute notify-send in the back-ground to avoid racing with sddm,
   # as notify-send may wait for sddm to start while it waits for us to exit.
   notify-send "VBoxClient: the VirtualBox kernel service is not running.  
Exiting." &
elif test -z "${SSH_CONNECTION}"; then
   # This script can also be triggered by a connection over SSH, which is not
   # what we had in mind, so we do not start VBoxClient in that case.  We do
   # not use "exit" here as this script is "source"d, not executed.
  /usr/bin/VBoxClient --clipboard || true
  /usr/bin/VBoxClient --checkhostversion || true
  /usr/bin/VBoxClient --display || true
  /usr/bin/VBoxClient --seamless || true
  # disable drag and drop 'cos I never use it and it pegs the CPU
  #/usr/bin/VBoxClient --draganddrop || true
  /usr/bin/VBoxClient --vmsvga-x11  || true # In case VMSVGA emulation is 
enabled
fi


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl4YqBASHHNhbUByb2Jv
dHMub3JnLnVrAAoJENILQgJc2ie5swEP/2YWpvrFzRgDvUQf6n9H3iYpjNZCeHwR
fZWO06t+mPy1JWbzyBLmIiB996ErLX8hMoV97YfUSk7rsWGCfs1P+Nl5HLaBb4XR
ADIM10U7m+XgoSS5ZAuhXKm8b46M9JJGyJsilxDHVry9DUEkXA+B9qQgoSxGZcbt
r7mcBmK42Zg3e6907M8AoWIndso4walYwV5GMGGf0ekxSQyujFSYNuvF/r+0H5Mg
OuuIoh5Guzm8X/D8j7ecl4N8DcMEYgEOvundsxskNM1cU8Xe99yW3eXv6hyz0GY6
+nB3NCWmoaMGkq31jNMLoC+YKxJAmgK9/bolJw6VtF9yKJ4hl+tmDm3Sudzbn20E
9k3TRqEffeiyGn+jhdyLW2AxGly9xYn7WWzidqQ41MF9aArxwxVkdFOUIDTAP5ha
jJjoQNR/8MzF8n2cjE8WFnbdOvw0meq1qdGCTC0pEg1YeWjV2bVq1ZQHZO1/fuHN
DctUaGtxcOtOj7wjWxEcWequE4S5o4RX0f9JFk3FDcwQWRpiuvgZvuHIjDXVq1CW
pA58q9dZnSozS6JVsS9/TUrvDeVZJk5V3DQ70KBq+v4/eoH53BfZ7S7Mrl84Slfq
Le7c17gkLF6zKxgsAIhTOlKWHey+LFcipUDW9YXOEzd7P+I3KQ5ZUvdJK40wsNQR
e7gU/tAfv2F9
=9c+p
-END PGP SIGNATURE-

Bug#911289: ca-certificates: How to handle certificates distrusted in gecko?

[Sam Morris]

Package: ca-certificates
Followup-For: Bug #911289

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I think this comment[0] leads me to the place where the Symantec
distrust is implemented. And it's not in NSS itself, but in browsers
themselves [1, 2].

I don't know where this leaves ca-certficiates. For the time being, the
certificates blacklisted by browsers can be blacklisted in
ca-certificates itself. But in general a simple whitelist of trusted
certificate authorities is no longer sufficient.  For instance, NSS has
the ability[3] to distrust a CA certificate after a particular date.
This simply isn't possible to represent in ca-certificates' whitelist.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1456112#c5
[1] 
https://github.com/mozilla/gecko-dev/blob/e070fba60fae8411f1f2e2f50bb22d5b86e71679/security/certverifier/NSSCertDBTrustDomain.cpp#L1174
[2] 
https://github.com/chromium/chromium/blob/2ca8c5037021c9d2ecc00b787d58a31ed8fc8bcb/net/http/transport_security_state_ct_policies.inc#L39
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1465613

- -- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable-debug'), (550, 'stable'), 
(530, 'testing-debug'), (530, 'testing'), (520, 'unstable-debug'), (520, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  openssl1.1.1d-0+deb10u2

ca-certificates recommends no packages.

ca-certificates suggests no packages.

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl3vlhsSHHNhbUByb2Jv
dHMub3JnLnVrAAoJENILQgJc2ie5nnsP/1CCKb9Ke+EXtp3oveLgQSJ2OWUwLXwY
bWbbegoH8rMcKn8gz8AA6DVb/uoB3cSFV2qUbP+MvTW70AVoR1W6sxobY8vJSKBJ
in3kTX3IpAsKG0BYh00Gn3a9zl2xGH+qd5Lc1Y4EhCkB/LdK2HBzqccCuGxyQIgb
5ZgGoDwRDA/Wwro5XSb1nq4uuP4RgsTm4hY1QUHWwKzqIIhofsAHlXG7CAINO7RA
w6t7eBn1BTDQVehWBLfbP1ec70uyuoEevOppxzQUnj/cFc9vWeExLHW3uD1I5dt9
x5Ee+dgPxtENRokXzDOj1r9f9CIzI3fdZR2nzf07puiX0YnwyDYenJKQYrLjAVhr
RXbAc5D6GavQFtYKqZhvuYDCLJ4NTphbd0JDps+3JQBPlbtoigP6uSztPGDh1cEc
EhMIwRGzrwbgvbVHGTtFU1rLnVQzBRk6c0N+8rMXISVCvRlJ6pWoq8T4v5iSegv5
xhZxHF6EAn4jdgXF/Fr0qlwXMPVC/pmpAj7LYGC/aXDXIHu5pmZHnAE0Hix951Ug
ty2xXTx+VFJS6L7KiTbhQoIN0L7lyQAMWl2HsSIE71JLpaohDV5v1CvmNMrjKCzF
EopXiuKkUB1zU+9PFfME5ufdfc7Ab25RzKPw9yz8MpIB7zAi7I2Cx+wCah74+aIz
zDpt+qpHLoaC
=gFUD
-END PGP SIGNATURE-

Bug#911289: ca-certificates: Symantec cert still included in Debian

[Sam Morris]

Package: ca-certificates
Followup-For: Bug #911289

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm trying to find a list of the distrusted certificates and it's not
easy... going by [0], the last entry on the list is:

CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, 
Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", 
C=US

23:99:56:11:27:A5:71:25:DE:8C:EF:EA:61:0D:DF:2F:A0:78:B5:C8:06:7F:4E:82:82:90:BF:B8:60:E8:4B:3C

Which is still included in ca-certificates!

$ openssl x509 -noout -fingerprint -sha256 -in 
/usr/share/ca-certificates/mozilla/VeriSign_Universal_Root_Certification_Authority.crt
SHA256 
Fingerprint=23:99:56:11:27:A5:71:25:DE:8C:EF:EA:61:0D:DF:2F:A0:78:B5:C8:06:7F:4E:82:82:90:BF:B8:60:E8:4B:3C

[0] 
https://blogs.oracle.com/java-platform-group/jdk-distrusting-symantec-tls-certificates

- -- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable-debug'), (550, 'stable'), 
(530, 'testing-debug'), (530, 'testing'), (520, 'unstable-debug'), (520, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  openssl1.1.1d-0+deb10u2

ca-certificates recommends no packages.

ca-certificates suggests no packages.

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl3vg8QSHHNhbUByb2Jv
dHMub3JnLnVrAAoJENILQgJc2ie5HjMQAJOAR8+8c4KbzWTChJSKQ9fVJPrDrEqi
bGVQ/tceYqSDTWE/2DAp+9kBMPQzE6bFJVUXo2V/P08impNG87OxwscYdFARa5O2
F1/16Vag9sg9U+sCNEO9a0UwQCZsXAYM6ctapB/teVOyNjbNqeDBcLFlg+NhGtK7
W7jgFTC8W2wQJTjlV+ASwuMncuVImGQJm9vQpa0SnBInVVLt5MPwgk95FRlDBEVs
UBIL2IcGWrpYc8AgxaYyb9jqnsRXedcESk58q+NdPwFTQo+F6260Hh/EHhA0IV/q
1acoscdRFVEGQZwC1gSQvLYUhN8dHNqNmtwdLGzbxUGWSQ/0h4LHunmBUlDdZOOp
szV/aVb31BJa0es8mfL/tVqX92C9jfOM9FSrqTMwFtPyJIj7dljkmTk/2CcD9OlJ
Z52yQwyvdag+r6LNR0KsBy3G6mZpLkfEGEXEriv2THps5l0r6cUz7M7AWJIL6GqZ
tJ8S91Z7gEJqmqUA+ZHt+IgEsPEJijIkvs6EnDJdEUtdd+FUd7y7yb34j049zD8G
pfjtWAZ0VzOi+BUj6TCdpek8StL4pZZptunnsEjkWnqJXv/3DFAKNKyKYPbUtXQV
WBGvkWqIro/SDSXluEo7aM9jx/aaFOIJMiRW519O+MQxr1m9IUJd6sbk0hS9LfhV
HUVa7NG9ys5d
=zke0
-END PGP SIGNATURE-

Bug#945532: RFP: python-urllib-gssapi -- GSSAPI over HTTP Negotiate/SPNEGO support for urllib/urllib2

[Sam Morris]

Package: wnpp
Severity: wishlist

* Package name: python-urllib-gssapi
  Version : 1.0.1
* URL : https://github.com/pythongssapi/urllib-gssapi/
* License : Apache License 2.0
  Programming Lang: Python
  Description : GSSAPI over HTTP Negotiate/SPNEGO support for urllib/urllib2

urllib_gssapi is a urllib backend for GSSAPI/SPNEGO authentication to
HTTP servers.

urllib_gssapi replaces urllib_kerberos, and behaves the same way - just
rename to HTTPSPNEGOAuthHandler.

The package enhances ansible, which relies on it in order to be able to
use Kerberos authentication when talking to web servers (e.g., a
FreeIPA server).

Bug#945274: ca-certificates: Deal with multiple certificates per .crt file

[Sam Morris]

Control: tag -1 + patch

Here's a first draft at implementing this:

https://salsa.debian.org/debian/ca-certificates/merge_requests/3


-- 
Sam Morris 

Bug#945274: ca-certificates: Deal with multiple certificates per .crt file

[Sam Morris]

Package: ca-certificates
Version: 20190110
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When joining a machine to a FreeIPA domain, the domain's trusted
certificates are placed in
 for integration with
ca-certificates.

If multiple certificates exist in FreeIPA's trust store, they will all
be written to this file.

This prevents OpenSSL clients from trusting *any* certificate within the
file:

# openssl rehash /etc/ssl/certs
rehash: warning: skipping ipa-ca.pem,it does not contain exactly one 
certificate or CRL

ca-certificates does not document whether it intends to cope with such
an input file.

If not then it should print a warning when update-ca-certificates is
run, and ignore the input file entirely (to prevent inconsistency with
whether a CA is trusted depending on whether the client uses the jumbo
/etc/ssl/certs/ca-certificates.crt file, or whether it uses the OpenSSL
hash symlinks). Assuming this is the case, I filed #924590, which is
 upstream.

Alternatively, ca-certificates could take it upon itself to split an
input file containing more than one certificate into several files
containing one certificate in, say, /var/lib/ca-certificates, and then
symlink _those_ into /etc/ssl/certs rather than the original file; in
which case the freeipa-client bug can be closed without further action.

If you were going to do that then there is an edge case to consider:
FreeIPA let's you have multiple certificates for the same authority
(i.e., Subject DN) within the trust store. This happens if, for
instance, a CA's certificate was re-issued to extend its validity
period. This will cause collisions when 'openssl rehash' hashes the CAs
Subject DN in order to create its symlinks. update-ca-certificates would
have to notice this collision, and correctly choose the certificate with
the latest notAfter date && with a notBefore date in the past? the exact
logic is up for debate).

I've marked this bug as blocking the freeipa-client bug because the
decision of whether multiple certificates within a single file
determines whether changes have to be made in freeipa-client or not.

I'm happy to send a patch implementing either behaviour, if you can tell
me which one you want.

- -- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable-debug'), (550, 'stable'), 
(530, 'testing-debug'), (530, 'testing'), (520, 'unstable-debug'), (520, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  openssl1.1.1d-0+deb10u2

ca-certificates recommends no packages.

ca-certificates suggests no packages.

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl3XpdASHHNhbUByb2Jv
dHMub3JnLnVrAAoJENILQgJc2ie5Uv4P/RyRQouGS0X+HlR8Ay2SIX9arCHk9HOm
aVEM/O6hH3qxDU7b1FK1PnWVZarAaTUxFLHKFVwtDs5GapV6wBoyMCCD6pX+VzdM
db32tGbEz8Z4N3oYoka1Wy4NZE4c4VSUo/n4SWDAu0hrFXtWFJ1DUNuiAUBFQIWX
nckrEJFfCJolQOcTbkLjA5VcugP/60nUEYRGEdMgOXMPeJRvo13+nitOEgsVC7OW
imvZ5Ni9k/Lvo6uREVofRG0Is+WsP1UGOhh/B0XoIrVXf5UP83GDgudH9KvCTiDL
8BwgeEgdtliEpSXBcG8V3N0VR/1xrH2AXhL+xIt9MVjMkRtotn2CYumIdGKX6eDm
phe1Q3JRMAOeFQnPRTduxbqtYpNCSas1oWEOed4Y4ahq9zflJt97HgNgCeNPzdrW
WW5tWhE90fDwAc4R4VAmiPFpu1X6hH3Fk9C+9i7kFoQ6tPJMn6O1z1sRraAJZlJs
n6S5VXsJwHVQ0I0gwmxAOMEzXf17Lqlsx44pxn/ZTw+9vz8VjHtVJBXWfaRQByuJ
AJlHwI95zQdy97eCXy5yO9FlSDNM2vKxPmgXjQ1kk75OYOPFuxljTCbWoseDHlNc
VXuMzzuKQm9Pd2L73ig41imB9SLk1kfjUw3uxIaMR7EW7TwfykvYTS8XY63tTGyB
A+G3oA03R0WA
=1LeL
-END PGP SIGNATURE-

Bug#944232: /lib/systemd/system/virtlogd.service: Please add needrestart overrides

[Sam Morris]

Package: libvirt-daemon-system
Version: 5.6.0-2
Severity: normal
File: /lib/systemd/system/virtlogd.service

needrestart currently defaults to restarting virtlogd when it detects
that the service needs a restart.

According to the man page and systemd unit, a reload operation will
re-exec the virtlogd executable without losing virtual machine logs.

Please ship /etc/needrestart/restart.d/virtlogd.service and
/etc/needrestart/restart.d/virtlog scripts which should call 'systemctl
reload virtlogd.service' and '/etc/init.d/virtlogd reload',
respectively, so that needrestart doesn't just restart the service on
its own.

See /etc/needrestart/restart.d/README.needrestart for more information.

-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-debug'), (570, 'stable'), 
(550, 'testing-debug'), (550, 'testing'), (540, 'unstable-debug'), (540, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  firewalld  0.7.2-1
ii  gettext-base   0.19.8.1-9
ii  init-system-helpers1.56+nmu1
ii  iptables   1.8.3-2~bpo10+1
ii  libc6  2.29-2
ii  libvirt-clients5.6.0-2
ii  libvirt-daemon 5.6.0-2
ii  libvirt0   5.6.0-2
ii  libxml22.9.4+dfsg1-7+b3
ii  logrotate  3.14.0-4
ii  lsb-base   10.2019051400
ii  policykit-10.105-25

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.2-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iproute2 4.20.0-2
ii  parted   3.2-25

Versions of packages libvirt-daemon-system suggests:
ii  apparmor2.13.3-6
ii  auditd  1:2.8.4-3
pn  nfs-common  
pn  open-iscsi  
pn  pm-utils
pn  radvd   
ii  systemd 242-7
ii  systemtap   4.0-1
pn  zfsutils

-- Configuration Files:
/etc/libvirt/nwfilter/allow-arp.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-arp.xml'
/etc/libvirt/nwfilter/allow-dhcp-server.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-dhcp-server.xml'
/etc/libvirt/nwfilter/allow-dhcp.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-dhcp.xml'
/etc/libvirt/nwfilter/allow-incoming-ipv4.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-incoming-ipv4.xml'
/etc/libvirt/nwfilter/allow-ipv4.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-ipv4.xml'
/etc/libvirt/nwfilter/clean-traffic-gateway.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/clean-traffic-gateway.xml'
/etc/libvirt/nwfilter/clean-traffic.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/clean-traffic.xml'
/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-spoofing.xml'
/etc/libvirt/nwfilter/no-ip-multicast.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-ip-multicast.xml'
/etc/libvirt/nwfilter/no-ip-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-mac-broadcast.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-mac-broadcast.xml'
/etc/libvirt/nwfilter/no-mac-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-other-l2-traffic.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-other-l2-traffic.xml'
/etc/libvirt/nwfilter/no-other-rarp-traffic.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-other-rarp-traffic.xml'
/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml'
/etc/libvirt/nwfilter/qemu-announce-self.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/qemu-announce-self.xml'
/etc/libvirt/qemu.conf [Errno 13] Permission denied: '/etc/libvirt/qemu.conf'
/etc/libvirt/qemu/networks/default.xml [Errno 13] Permission denied: 
'/etc/libvirt/qemu/networks/default.xml'

-- debconf information excluded

Bug#944157: geoclue-2.0: Segfaults when location services are not available

[Sam Morris]

Package: geoclue-2.0
Version: 2.5.2-1
Severity: normal

I see this a lot on my laptops:

-- Logs begin at Tue 2019-07-23 14:37:14 BST, end at Tue 2019-11-05 
10:43:48 GMT. --
Oct 22 14:53:25 geoclue[1582]: Failed to query location: Error resolving 
“location.services.mozilla.com”: Name or service not known
Oct 22 15:23:54 geoclue[1582]: Failed to query location: Error resolving 
“location.services.mozilla.com”: Name or service not known
Oct 22 19:39:53 geoclue[1582]: WiFi scan failed
Oct 22 19:39:53 geoclue[1582]: Failed to query location: Error resolving 
“location.services.mozilla.com”: Name or service not known
Oct 22 19:39:53 geoclue[1582]: Scanning of WiFi networks failed: 
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "Scan" with 
signature "a{sv}" on interface "fi.w1.wpa_supplicant
Oct 22 19:39:53 audit[1582]: ANOM_ABEND auid=4294967295 uid=109 gid=114 
ses=4294967295 subj==unconfined pid=1582 comm="geoclue" 
exe="/usr/lib/geoclue-2.0/geoclue" sig=11 res=1

Here's the backgrace:

#0  0x7f9753ccb240 in g_bit_lock (address=address@entry=0x20, 
lock_bit=lock_bit@entry=0) at ../../../glib/gbitlock.c:214
#1  0x7f9753d363a9 in g_variant_lock (value=value@entry=0x0) at 
../../../glib/gvariant-core.c:991
#2  0x7f9753d363a9 in g_variant_n_children (value=value@entry=0x0) at 
../../../glib/gvariant-core.c:991
#3  0x5578c348d183 in variant_to_string (variant=0x0, 
len=len@entry=0x0) at ../src/gclue-mozilla.c:49
#4  0x5578c348d408 in get_ssid_from_bss (bss=0x5578c4207790) at 
../src/gclue-mozilla.c:71
#5  0x5578c348d408 in gclue_mozilla_should_ignore_bss 
(bss=bss@entry=0x5578c4207790) at ../src/gclue-mozilla.c:414
#6  0x5578c348c9ca in on_bss_proxy_ready (source_object=, res=, user_data=user_data@entry=0x5578c42122e0) at 
../src/gclue-wifi.c:313
#7  0x7f9753b81e99 in g_task_return_now (task=0x5578c42390f0 [GTask]) 
at ../../../gio/gtask.c:1212
#8  0x7f9753b829bd in g_task_return (task=0x5578c42390f0 [GTask], 
type=) at ../../../gio/gtask.c:1281
#9  0x7f9753b832de in g_task_return (type=G_TASK_RETURN_SUCCESS, 
task=) at ../../../gio/gtask.c:1797
#10 0x7f9753b832de in g_task_return_boolean (task=, 
result=) at ../../../gio/gtask.c:1801
#11 0x7f9753be69e9 in init_second_async_cb 
(source_object=0x5578c4207790 [WPABSSProxy], res=0x5578c423c6d0, 
user_data=0x5578c423c6d0, user_data@entry=0x5578c42390f0) at 
../../../gio/gdbusproxy.c:1823
#12 0x7f9753b81e99 in g_task_return_now (task=0x5578c42390f0 [GTask]) 
at ../../../gio/gtask.c:1212
#13 0x7f9753b829bd in g_task_return (task=0x5578c423c6d0 [GTask], 
type=) at ../../../gio/gtask.c:1281
#14 0x7f9753b82fdc in g_task_return (type=G_TASK_RETURN_SUCCESS, 
task=) at ../../../gio/gtask.c:1684
#15 0x7f9753b82fdc in g_task_return_pointer (task=, 
result=, result_destroy=) at 
../../../gio/gtask.c:1689
#16 0x7f9753be6054 in async_init_get_all_cb (connection=, res=, user_data=user_data@entry=0x5578c423c6d0) at 
../../../gio/gdbusproxy.c:1456
#17 0x7f9753b81e99 in g_task_return_now (task=0x5578c41eec80 [GTask]) 
at ../../../gio/gtask.c:1212
#18 0x7f9753b829bd in g_task_return (task=0x5578c41eec80 [GTask], 
type=) at ../../../gio/gtask.c:1281
#19 0x7f9753b83476 in g_task_return (type=G_TASK_RETURN_ERROR, 
task=) at ../../../gio/gtask.c:1860
#20 0x7f9753b83476 in g_task_return_error (task=, 
error=) at ../../../gio/gtask.c:1865
#21 0x7f9753bdaffc in g_dbus_connection_call_done (source=, result=0x5578c41eeb00, user_data=user_data@entry=0x5578c41eec80) at 
../../../gio/gdbusconnection.c:5749
#22 0x7f9753b81e99 in g_task_return_now (task=0x5578c41eeb00 [GTask]) 
at ../../../gio/gtask.c:1212
#23 0x7f9753b81ed9 in complete_in_idle_cb (task=0x5578c41eeb00) at 
../../../gio/gtask.c:1226
#24 0x7f9753cf7d7e in g_main_dispatch (context=0x5578c41e09b0) at 
../../../glib/gmain.c:3179
#25 0x7f9753cf7d7e in g_main_context_dispatch 
(context=context@entry=0x5578c41e09b0) at ../../../glib/gmain.c:3844
#26 0x7f9753cf8130 in g_main_context_iterate (context=0x5578c41e09b0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:3917
#27 0x7f9753cf8403 in g_main_loop_run (loop=0x5578c41ee610) at 
../../../glib/gmain.c:4111
#28 0x5578c3472908 in main (argc=, argv=) 
at ../src/gclue-main.c:194

This is fixed by

in version 2.5.3.  It would be great to get this applied to buster.

-- System Information:
Debian Release: 10.1
  APT prefers stable-debug
  APT policy: (570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), 
(550, 'testing'), (530, 'unstable-debug'), (530, 'unstable'), (500, 
'stable-updates'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU 

Bug#931831: cups: http://localhost:631/ is served with HTTP Content-Type: text/plain

[Sam Morris]

Package: cups
Followup-For: Bug #931831

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm not seeing this with 2.3.0-5:

$ curl -sSi http://localhost:631/ | grep ^Content-Type
Content-Type: text/html; charset=utf-8

- -- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable-debug'), (550, 'stable'), 
(530, 'testing-debug'), (530, 'testing'), (520, 'unstable-debug'), (520, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages cups depends on:
ii  cups-client2.3.0-5
ii  cups-common2.3.0-5
ii  cups-core-drivers  2.3.0-5
ii  cups-daemon2.3.0-5
ii  cups-filters   1.21.6-5
ii  cups-ppdc  2.3.0-5
ii  cups-server-common 2.3.0-5
ii  debconf [debconf-2.0]  1.5.71
ii  ghostscript9.27~dfsg-2+deb10u2
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.29-2
ii  libcups2   2.3.0-5
ii  libgcc11:8.3.0-6
ii  libstdc++6 8.3.0-6
ii  libusb-1.0-0   2:1.0.22-2
ii  poppler-utils  0.71.0-5
ii  procps 2:3.3.15-2

Versions of packages cups recommends:
ii  avahi-daemon 0.7-4+b1
ii  colord   1.4.3-4
ii  cups-filters [ghostscript-cups]  1.21.6-5
pn  printer-driver-gutenprint

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
pn  foomatic-db-compressed-ppds | foomatic-db  
pn  hplip  
pn  printer-driver-hpcups  
ii  smbclient  2:4.11.1+dfsg-1
ii  udev   241-7~deb10u1

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl20NZcSHHNhbUByb2Jv
dHMub3JnLnVrAAoJENILQgJc2ie5hLcP/iv2tgApjnr7YzxeWjlq8IxWW1Ez09Vg
l1iqc7ZeuJwEhosqli7nInriyP7wRH0U9vXM+YyVFYC8FJqlK85lNGu8Kf9C79Mz
19+m7LZgSsr5UxVqlPLT1JoISZn2OUJww6/+9gx1DwyALcOGk0eBnQqia+nyvk+f
lyAamjsRjJrIUfHxjlmc5EZaER6uWuDyabA7jiWDO03pacaWem2qkGyz5tjJMe86
1ATBa2uHqqtD9CvIHcXuv1LzHLq80vktuLpqoPWw5k1xLRx9tV4UwSUr0LZxBBoD
LHYf+bOAs/bIHUTdC9wIHO+iYIX92pARw/n1Eqxq7gRQp57o2tA89+8fKS6fO18k
M4uJK8sWz0rtW7yKDPtH6Claae5yvmi0LsvsQn9nPNkMnOeTkidy3eeZ5xVceU07
Z9FCijs3dxwOC6LFLOJI010aQrA/+C57rAXTfySrvyHStKSXHQTFPYQfETzjAQAc
iLBONtZT4HhzfJgZsmaWyb0FMhCIe3J/02+K/duCGXTqBEkPevBRVTWwv4sWrpZb
Y4JatM5yesZ14R+jCcSvw9Dd0OmVyu+pqJhiGoHoPe2O6cqBa0YI/q9rEtZnkdEu
WzJ2I5wyzivaRwA3J1j1p3PlPlb8JzTk2N81cnryw4u0ednzJO6n93ZgbI94+Ql4
nkLpOQ8pOd2n
=09Sj
-END PGP SIGNATURE-

Bug#942368: libvirt-daemon: firewall rules lost when firewalld restarts

[Sam Morris]

Package: libvirt-daemon
Version: 5.6.0-2
Severity: normal

My virtual machines often lose connectivity to external networks. This
seems to be because libvirt's iptables rules are missing:

root@fragarach:~# iptables -nv -L FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   
destination 
0 0 DOCKER-USER  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 DOCKER-ISOLATION-STAGE-1  all  --  *  *   0.0.0.0/0 
   0.0.0.0/0   
0 0 ACCEPT all  --  *  docker0  0.0.0.0/0
0.0.0.0/0ctstate RELATED,ESTABLISHED
0 0 DOCKER all  --  *  docker0  0.0.0.0/0
0.0.0.0/0   
0 0 ACCEPT all  --  docker0 !docker0  0.0.0.0/0
0.0.0.0/0   
0 0 ACCEPT all  --  docker0 docker0  0.0.0.0/0
0.0.0.0/0   
0 0 ACCEPT all  --  *  *   0.0.0.0/0
0.0.0.0/0ctstate RELATED,ESTABLISHED,DNAT
0 0 ACCEPT all  --  lo *   0.0.0.0/0
0.0.0.0/0   
0 0 FORWARD_direct  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 FORWARD_IN_ZONES  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 FORWARD_OUT_ZONES  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 LOGall  --  *  *   0.0.0.0/0
0.0.0.0/0ctstate INVALID PKTTYPE = unicast LOG flags 0 level 4 
prefix "STATE_INVALID_DROP: "
0 0 DROP   all  --  *  *   0.0.0.0/0
0.0.0.0/0ctstate INVALID
0 0 LOGall  --  *  *   0.0.0.0/0
0.0.0.0/0PKTTYPE = unicast LOG flags 0 level 4 prefix 
"FINAL_REJECT: "
0 0 REJECT all  --  *  *   0.0.0.0/0
0.0.0.0/0reject-with icmp-host-prohibited

This is fixed by restarting firewalld:

root@fragarach:~# systemctl restart libvirtd
root@fragarach:~# iptables -nv -L FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   
destination 
0 0 LIBVIRT_FWX  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 LIBVIRT_FWI  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 LIBVIRT_FWO  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 DOCKER-USER  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 DOCKER-ISOLATION-STAGE-1  all  --  *  *   0.0.0.0/0 
   0.0.0.0/0   
0 0 ACCEPT all  --  *  docker0  0.0.0.0/0
0.0.0.0/0ctstate RELATED,ESTABLISHED
0 0 DOCKER all  --  *  docker0  0.0.0.0/0
0.0.0.0/0   
0 0 ACCEPT all  --  docker0 !docker0  0.0.0.0/0
0.0.0.0/0   
0 0 ACCEPT all  --  docker0 docker0  0.0.0.0/0
0.0.0.0/0   
0 0 ACCEPT all  --  *  *   0.0.0.0/0
0.0.0.0/0ctstate RELATED,ESTABLISHED,DNAT
0 0 ACCEPT all  --  lo *   0.0.0.0/0
0.0.0.0/0   
0 0 FORWARD_direct  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 FORWARD_IN_ZONES  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 FORWARD_OUT_ZONES  all  --  *  *   0.0.0.0/0
0.0.0.0/0   
0 0 LOGall  --  *  *   0.0.0.0/0
0.0.0.0/0ctstate INVALID PKTTYPE = unicast LOG flags 0 level 4 
prefix "STATE_INVALID_DROP: "
0 0 DROP   all  --  *  *   0.0.0.0/0
0.0.0.0/0ctstate INVALID
0 0 LOGall  --  *  *   0.0.0.0/0
0.0.0.0/0PKTTYPE = unicast LOG flags 0 level 4 prefix 
"FINAL_REJECT: "
0 0 REJECT all  --  *  *   0.0.0.0/0
0.0.0.0/0reject-with icmp-host-prohibited

I'm guessing the method that libvirtd uses to watch when firewalld
reloads the firewall, so that libvirt can add its own rules, is not
always effective.

-- System Information:
Debian Release: 10.1
  APT prefers stable-debug
  APT policy: (570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), 
(550, 'testing'), (530, 'unstable-debug'), (530, 'unstable'), (500, 
'stable-updates'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 

Bug#942367: openipmi: Bashisms in init script

[Sam Morris]

Source: openipmi
Version: 2.0.25-2
Severity: normal

/etc/init.d/openipmi uses /bin/sh but uses some features that require
bash:

$ checkbashisms debian/openipmi.init 
possible bashism in debian/openipmi.init line 55 (should be 'b = a'):
if [ "${kernel}" == "2.4" ]; then
possible bashism in debian/openipmi.init line 202 ($"foo" should be 
eval_gettext "foo"):
log_begin_msg $"Starting ipmi_watchdog driver: "
possible bashism in debian/openipmi.init line 213 ($"foo" should be 
eval_gettext "foo"):
log_begin_msg $"Stopping ipmi_watchdog driver: "
possible bashism in debian/openipmi.init line 245 (should be 'b = a'):
if [ "${IPMI_POWERCYCLE}" == "yes" ]; then

Per policy sec. 10.4:

If a shell script requires non-POSIX.1-2017 features from the shell
interpreter other than those listed above, the appropriate shell
must be specified in the first line of the script (e.g.,
#!/bin/bash) and the package must depend on the package providing
the shell (unless the shell package is marked “Essential”, as in the
case of bash).

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (570, 'testing-debug'), (570, 'testing'), (540, 
'unstable-debug'), (540, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#942369: sysbench: --warmup-time option is not implemented

[Sam Morris]

Package: sysbench
Version: 1.0.17+ds-1
Severity: normal

Although documented, the --warmup-time option doesn't actually work:

$ sysbench --warmup-time=5 cpu run
sysbench 1.0.17 (using system LuaJIT 2.1.0-beta3)

invalid option: --warmup-time=5

-- System Information:
Debian Release: 10.1
  APT prefers stable-debug
  APT policy: (570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), 
(550, 'testing'), (530, 'unstable-debug'), (530, 'unstable'), (500, 
'stable-updates'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages sysbench depends on:
ii  libaio1  0.3.112-3
ii  libc62.29-2
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-5.1
ii  libmariadb3  1:10.3.17-0+deb10u1
ii  libpq5   11.5-1+deb10u1

sysbench recommends no packages.

sysbench suggests no packages.

-- no debconf information

Bug#941577: nextcloud-desktop: Please build against libcloudproviders

[Sam Morris]

Package: nextcloud-desktop
Version: 2.5.3-1
Severity: normal

Currently users of Nextcloud are missing a convenient way to see the
status of synchronization or access settings. libcloudproviders is the
'proper' way to do that in GNOME. When it is used, there is no longer
any need for the user to rely on the (IME unreliable) Topicons or
appindicator GNOME Shell extensions.

I believe it also provides some measure of Nautilus integration--synced
folders automatically appear in the side bar, the syncrhonization status
of files is displayed, and files can be shared and so on directly from
Nautilus. This at least is possible today with the nautilus-nextcloud
package, but libcloudproviders does it in a provider-independent way.

-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-debug'), (570, 'stable'), 
(550, 'testing-debug'), (550, 'testing'), (540, 'unstable-debug'), (540, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages nextcloud-desktop depends on:
ii  libc6 2.29-2
ii  libgcc1   1:8.3.0-6
ii  libnextcloudsync0 2.5.3-1
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5dbus5   5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5keychain1   0.9.1-2
ii  libqt5network55.11.3+dfsg1-1
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1
ii  libqt5webenginecore5  5.11.3+dfsg-2+b1
ii  libqt5webenginewidgets5   5.11.3+dfsg-2+b1
ii  libqt5webkit5 5.212.0~alpha2-21
ii  libqt5widgets55.11.3+dfsg1-1
ii  libqt5xml55.11.3+dfsg1-1
ii  libstdc++69.2.1-8
ii  nextcloud-desktop-common  2.5.1-3+deb10u1
ii  nextcloud-desktop-l10n2.5.1-3+deb10u1

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  2.5.1-3+deb10u1

nextcloud-desktop suggests no packages.

-- no debconf information