Guillem Jover: > Hi! > > On Tue, 2017-03-28 at 16:22:58 -0700, Matthew Garrett wrote: >> I'm looking at implementing support for IMA file signatures inside >> dpkg. The previous patches posted for this >> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850340) did so >> using extended PAX metadata, but people didn't seem terribly >> enthusiastic about that. >> https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking suggested >> mtree as a potential format, so I thought I'd try to kick off some >> discussion and see whether I'm missing any requirements or whether >> there were any better ideas. So: > > As mentioned on IRC, I updated the wiki with some more thoughts. > Regarding PAX, it's my intention to extend and merge those patches > for 1.19.x, but as stated there, I'm not entirely sure that's the best > way (currently) to transport that metadata. >
Glad to see this moving forward. :) > [...] >> Each entry shall be of the form >> >> /path/name key1=foo key2=bar > >> Ie, a leading space, a slash, and the path name of the installed file >> followed by a series of space-separated key=value pairs followed by a >> line feed. […] > > I don't think this is correct. Initial whitespace gets ignored (this is > not clear from mtree(5), but that's what the various implementations do). > The subset of type of lines I'm intending to support would be: > > ,--- > /set <global-attr…> > /unset <glonal-attr…> > .<absolute-pathname> <local-attr…> > # comment > <blank-line> > `--- > In this variant, can /set and /unset be interleaved between paths? My previous PoC implementation did this and I was wondering if it would be supported. :) > No indented nor continuation lines, no relative paths, no ".." entries. > > Then, my idea would be to further distinguish two types of mtree files, > template and detailed. The first would allow the globs permitted in the > spec ('[', ']', '?', '*'), and possibly also the "ignore" keyword. The > second would not. Template mtree would be used in source packages, and > would be used to generate the data.tar in the .deb and possibly part of > the detailed mtree in the control.tar, and of course the detailed mtree > in the db. > The "ignore" keyword being something like "anything that matches /except/ whatever matches the ignore keyword"? >> [...] > > > My current working plan is to get the last items for 1.18.x out, > ideally this week or the next. Then immediately branch 1.18.x and open > 1.19.x on master. Sounds great (from my PoV). :) > At which point I'd get the mtree support integrated > for the db as the first stage, and then we can start pondering about > how to transport additional metadata in the .deb as the second stage, > and finally about the templating mode. The last one might be more > involved as it will most probably require adding support for built-in > tar packing. But the second stage would allow to already test stuff > by manually crafting .debs or writing an external helper or tool to > inject that metadata, so this should allow us to experiment and not > block on the whole thing being finalized. > > Thanks, > Guillem > I still have a debhelper tool to generate the mtree format, which I am happy to revive. In particular, I would be delighted if that revival means we can migrate debhelper away from "chown" and just use the format to describe ownership. I intend to do an upload of debhelper to experimental later and am happy to include it there if it would be any help. Thanks, ~Niels