Re: [RFC] gpkg format proposal v2 (was: Re: [gentoo-portage-dev] [RFC] Improving Gentoo package format)

[Michał Górny]

On Tue, 2018-11-13 at 10:55 -0800, Zac Medico wrote:
> On 11/13/18 10:50 AM, Zac Medico wrote:
> > On 11/11/18 12:53 PM, Michał Górny wrote:
> > > Hi,
> > >
> > > Ok, here's the second version integrating the feedback received.
> > > The format is much simpler, based on nested tarballs inspired by Debian.
> > >
> > > The outer tarball is uncompressed and uses '.gpkg.tar' suffix.  It
> > > contains (preferably in order but PM should also handle packages with
> > > mismatched order):
> > >
> > > 1. Optional (but recommended) "gpkg: ${PF}" package label that can be
> > > used to quickly distinguish Gentoo binpkgs from regular tarballs
> > > (for file(1)).
> > >
> > > 2. "metadata.tar${comp}" tarball containing binary package metadata
> > > as files.
> > >
> > > 3. Optional "metadata.tar${comp}.sig" containing detached signature
> > > for the metadata archive.
> > >
> > > 4. "contents.tar${comp}" tarball containing files to be installed.
> > >
> > > 5. Optional "contents.tar${comp}.sig" containing detached signature for
> > > the contents archive.
> >
> > We need to establish the procedure for signature verification of the
> > files in "contents.tar${comp}" at any point in the future *after* they
> > have been installed. In order to identify corruption of a particular
> > installed file, we'll need separate digests for each of the installed
> > files, and a signature covering the separate digests.
>
> We need separate digests for the files in "metadata.tar${comp}" too, for
> the same reason. Note the environment.bz2 is mutable because it is
> deserialized/reserialized for each pkg_* phase. If the installation
> process has access to a trusted signing key, it can sign environment.bz2
> after each mutation.

Most of the other metadata is also mutable because of package moves.

-- 
Best regards,
Michał Górny