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
