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.
-- 
Thanks,
Zac

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to