This uses the same approach taken by Flatpak [1] to ensure that the
certificates from certificate authorities (or CAs) that are available
inside a Toolbx container are kept synchronized with the host operating
system.  Any program that uses PKCS containers#11 to access CA certificates should
see the same ones both inside the container and on the host.

During every 'enter' and 'run' command, toolbox(1) ensures that an
instance of 'p11-kit server' is running on the host listening on a local
file system socket that's accessible to both the container and the host.
If an instance is already running, then a second one is not created.
The location of the socket is injected into the container through the
P11_KIT_SERVER_ADDRESS environment variable.

The Toolbx container's entry point configures it to use the
p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so
module.  This talks to the 'p11-kit server' instance running on the host
over the socket instead of reading the CA certificates that are present
inside the container.

However, unlike Flatpak, this doesn't use D-Bus to set up the
communication between the container and the host, because when invoked
as 'sudo toolbox ...' there's no user or session D-Bus instance
available for the root user.

This set-up is skipped if 'p11-kit server' can't be run on the host, or
if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or
p11-kit-client.so are missing inside the container.  None of these are
considered hard dependencies to accommodate size-constrained OSes like
Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx
containers and old images that might not have p11-kit-client.so.

Verions of lsof from 4.88 to older than 4.94.0 always select the file
descriptor field [2], and these are present in versions of Ubuntu from
16.04 to 22.04.  This needs to be factored in as long as a Ubuntu 22.04
host is used to run the CI.  One option is to always select the file
descriptor field even though it's not really needed for the tests.

The ubuntu-toolbox:22.04 has been failing to rebuild [3]:
  STEP 6/10: RUN sed -Ei '/apt-get (update|upgrade)/s/^/#/'
      /usr/local/sbin/unminimize &&     apt-get update &&     yes |
      /usr/local/sbin/unminimize &&     DEBIAN_FRONTEND=noninteractive
      apt-get -y install         ubuntu-minimal ubuntu-standard
      libnss-myhostname         flatpak-xdg-utils
      $(cat extra-packages | xargs) &&     rm -rd /var/lib/apt/lists/*
  ...
  ...
  (Reading database ... 100%
  (Reading database ... 4387 files and directories currently installed.)
  Preparing to unpack .../libc-bin_2.35-0ubuntu3.9_arm64.deb ...
  Unpacking libc-bin (2.35-0ubuntu3.9) over (2.35-0ubuntu3.9) ...
  Setting up libc-bin (2.35-0ubuntu3.9) ...
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)
  dpkg: error processing package libc-bin (--configure):
   installed libc-bin package post-installation script subprocess returned error exit status 139
  Errors were encountered while processing:
   libc-bin
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  ...

It's probably some network problem because it doesn't reliably occur
everywhere.  Until this gets sorted out, Toolbx containers created from
the ubuntu-toolbox:22.04 won't have access to the CA certificates from
the host.

The fedora-toolbox and the UBI-based toolbox images haven't yet been
updated to contain p11-kit-client.so.  Until that happens, containers
created from them won't have access to the CA certificates from the
host.

[1] Flatpak commit 66b2ff40f7caf3a7
    flatpak/flatpak@66b2ff40f7caf3a7
    flatpak/flatpak#1757
    p11-glue/p11-kit#68

[2] lsof commit 811dc78cc6404cb3
    lsof-org/lsof@811dc78cc6404cb3
    lsof-org/lsof#125
    lsof-org/lsof#103

[3] containers#1634
    containers#1643

containers#626

This uses the same approach taken by Flatpak [1] to ensure that the
certificates from certificate authorities (or CAs) that are available
inside a Toolbx container are kept synchronized with the host operating
system.  Any program that uses PKCS containers#11 to access CA certificates should
see the same ones both inside the container and on the host.

During every 'enter' and 'run' command, toolbox(1) ensures that an
instance of 'p11-kit server' is running on the host listening on a local
file system socket that's accessible to both the container and the host.
If an instance is already running, then a second one is not created.
The location of the socket is injected into the container through the
P11_KIT_SERVER_ADDRESS environment variable.

The Toolbx container's entry point configures it to use the
p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so
module.  This talks to the 'p11-kit server' instance running on the host
over the socket instead of reading the CA certificates that are present
inside the container.

However, unlike Flatpak, this doesn't use D-Bus to set up the
communication between the container and the host, because when invoked
as 'sudo toolbox ...' there's no user or session D-Bus instance
available for the root user.

This set-up is skipped if 'p11-kit server' can't be run on the host, or
if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or
p11-kit-client.so are missing inside the container.  None of these are
considered hard dependencies to accommodate size-constrained OSes like
Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx
containers and old images that might not have p11-kit-client.so.

Verions of lsof from 4.88 to older than 4.94.0 always select the file
descriptor field [2], and these are present in versions of Ubuntu from
16.04 to 22.04.  This needs to be factored in as long as a Ubuntu 22.04
host is used to run the CI.  One option is to always select the file
descriptor field even though it's not really needed for the tests.

The ubuntu-toolbox:22.04 has been failing to rebuild [3]:
  STEP 6/10: RUN sed -Ei '/apt-get (update|upgrade)/s/^/#/'
      /usr/local/sbin/unminimize &&     apt-get update &&     yes |
      /usr/local/sbin/unminimize &&     DEBIAN_FRONTEND=noninteractive
      apt-get -y install         ubuntu-minimal ubuntu-standard
      libnss-myhostname         flatpak-xdg-utils
      $(cat extra-packages | xargs) &&     rm -rd /var/lib/apt/lists/*
  ...
  ...
  (Reading database ... 100%
  (Reading database ... 4387 files and directories currently installed.)
  Preparing to unpack .../libc-bin_2.35-0ubuntu3.9_arm64.deb ...
  Unpacking libc-bin (2.35-0ubuntu3.9) over (2.35-0ubuntu3.9) ...
  Setting up libc-bin (2.35-0ubuntu3.9) ...
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)
  dpkg: error processing package libc-bin (--configure):
   installed libc-bin package post-installation script subprocess returned error exit status 139
  Errors were encountered while processing:
   libc-bin
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  ...

It's probably some network problem because it doesn't reliably occur
everywhere.  Until this gets sorted out, Toolbx containers created from
the ubuntu-toolbox:22.04 won't have access to the CA certificates from
the host.

The fedora-toolbox and the UBI-based toolbox images haven't yet been
updated to contain p11-kit-client.so.  Until that happens, containers
created from them won't have access to the CA certificates from the
host.

[1] Flatpak commit 66b2ff40f7caf3a7
    flatpak/flatpak@66b2ff40f7caf3a7
    flatpak/flatpak#1757
    p11-glue/p11-kit#68

[2] lsof commit 811dc78cc6404cb3
    lsof-org/lsof@811dc78cc6404cb3
    lsof-org/lsof#125
    lsof-org/lsof#103

[3] containers#1634
    containers#1643

containers#626