Re: RFC: Consequences of redesign of .deb signatures
Hi!
On Wed, 2025-09-03 at 23:59:05 +0300, Peter Pentchev wrote:
> On Wed, Sep 03, 2025 at 09:35:12PM +0200, Philipp Kern wrote:
> > On 9/2/25 1:55 PM, Guillem Jover wrote:
> > > And IMA has indeed the same exact problem, where I'm also not convinced
> > > at all about them for the Debian archive. Yet, I still think it would
> > > be nice to have a format that might make it possible to explore that,
> > > because perhaps for some organizations or distribution methods it does
> > > make sense. (Because decoupling the IMA signatures from the general
> > > filesystem metadata payload means injecting or changing them is going
> > > to be way easier.)
> >
> > Yeah that's fair. Having a format where you can just append some signatures
> > on the fly might make sense here. But then maybe they would need to be
> > authenticated differently than the repo root of trust.
>
> I'm not exactly sure what you mean by "append on the fly", but the current
> file format that debsigs creates and modifies (and debsig-verify checks)
> keeps the signatures in a separate ar member of the deb file. This allows,
> even now, and most probably in Guillem's revamp too, adding a new signature
> without removing all the existing ones, and without modifying the actual
> content of the deb file's "control" and "data" members.
>
> So if I'm following the discussion, in theory even the current format would
> allow adding a signature with a new key, although, of course, that would
> modify the MD5/SHA256/whatever checksums of the deb file itself, so
> Apt may then throw a hissy fit (and it would be right to).
For a bit of context IMA signatures are attached to extracted files
on the filesystem as xattrs, where the kernel verifies them at run-time.
Using the same member to transport IMA signatures as we'd use for
debsigs signatures would be in contrast to previous proposals to
transport IMA signatures as part of the file metadata, inside the
control.tar or data.tar members, which makes injecting them after
having built the .deb (but before adding to the repo) more involved,
in addition to for example invalidating pre-existing debsigs signatures.
Thanks,
Guillem
Reply to: