Re: Add support for shipping extended attributes in debs

[Guillem Jover <guillem@debian.org>]

Hi!

On Tue, 2018-05-01 at 13:37:26 -0700, Matthew Garrett wrote:
> This is currently something of a scratch proposal, but let's see where
> it goes. This patchset adds support for shipping an mtree file within
> debs, which (right now) is only used for writeout of extended
> attributes. The idea is that additional metadata can be incorporated
> into the mtree file, providing a unified format for metadata storage and
> making it easy to compare the installed system state to the default
> package state (and restore it if necessary).

Thanks for the patches. And sorry again for having been so slow on the
dpkg front for the last several months, and not having finished the work
on this as I wanted to, life got in the way. :/

Unfortunately this does not integrate quite well with the dpkg
internals, some of the files are also using BSD 4-clause license, so I
think I'll continue with the implementation I've got half done. My plan
is still to first switch the internal database into using mtree (and
stop using the files list files), then consider binaries shipping such
metadata, and then exposing that in the source package.

  <https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking>

For the first stage, I'm moving the file metadata from dpkg into libdpkg,
which will also make it easier to unit test it.

> I'm primarily interested in using this to ship security metadata in the
> form of security.ima and security.evm, but this also provides a way to
> ship file capabilities without requiring postinst to mess about with
> setcap.

As I've mentioned in the past on IRC, I'm yet not sure how we'd integrate
the signing mechanism part into the toolchain, also because this might
require external tooling that for example in Debian or derivatives we
might not directly want to use, but others might, so this might need
to be something to hook into somewhere.

Also I'm not sure file capabilities is a good example, because those
tend to be conditional, and when they fail to be set, the maintscripts
tend to fallback to using set-user-ID on the binaries, and also because
these are inherently non-portable.

Thanks,
Guillem