Re: Add support for shipping extended attributes in debs
On Tue, May 8, 2018 at 5:04 AM Guillem Jover <guillem@debian.org> wrote:
> 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.
I'm more than happy to contribute to your implementation, but it'd be
easier if you'd post what you have :) The 4-clause stuff all appears to be
copyright Berkeley, so my understanding is that it can just be relicensed
to 3-clause.
> > 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.
We're generating the signatures in our internal build system and then
merging those into any existing mtree file, so there's no inherent conflict
there. I'd definitely like to work with Debian to make it possible for
Debian to ship signatures, but I'd imagine that being a long-term process.
> 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.
I don't think you'd end up with file capabilities in any arch:all packages,
so the non-portability doesn't seem to be a huge problem - I was imagining
a way to express this in the source package, with tooling generating
something appropriate depending on the build architecture.
Reply to: