Re: [gentoo-dev] [pre-GLEP r1] Gentoo binary package container format

[Rich Freeman]

On Mon, Nov 19, 2018 at 2:40 PM Zac Medico <zmedico@g.o> wrote:
>
> On 11/19/18 11:33 AM, Rich Freeman wrote:
> > On Mon, Nov 19, 2018 at 2:21 PM Roy Bamford <neddyseagoon@g.o> wrote:
> >>
> >> "The archive members support optional OpenPGP signatures.
> >> The implementations must allow the user to specify whether OpenPGP
> >> signatures are to be expected in remotely fetched packages."
> >>
> >> Or can the user specify that only some elements need to be signed?
> >>
> >> Is it a problem if not all elements are signed with the same key?
> >> That could happen if one person makes a  binpackage and someone
> >> else updates the metadata.
> >>
> >
> > IMO this is going a bit into PM details for a GLEP that is about
> > container formats.
> >
> > Presumably any package manager is going to need to figure out what
> > keys are/aren't valid and allow the user to configure this behavior.
> > Users who want to go editing package innards will presumably adjust
> > their package manager settings to accept their modifications, whether
> > it means accepting their own sigs or disabling them.
>
> With the GLEP as it is, the user *must* use a local signing key to sign
> installed packages during the installation process if they want to be
> able to verify signatures for installed packages at some point in the
> future, since the binary package format does not provide a way to use
> binary package signatures for this purpose.

I think we might be talking about different signatures?

I think you're referring to signatures of the package files after they
are installed on the local filesystem, while I'm talking about
verifying the integrity of the package file themselves.

If these signatures are applied to different data then obviously you
couldn't just have the one signature serve double duty (unless you
hung onto the binary package, verified the signature on it, then
verified the package contents against the live filesystem).

The simplest solution would be to do as you seem to be suggesting -
verify the signature on the package before installing it, and then
during installation capture whatever metadata is already supported by
portage and sign that using a user's trusted key.

This seems like the most practical solution in any case since we
aren't likely to ever go down the route of using a single signed
squashfs for /usr like a release-based binary distro might.

-- 
Rich