On Mon, Nov 19, 2018 at 2:40 PM Zac Medico <zmed...@gentoo.org> wrote: > > On 11/19/18 11:33 AM, Rich Freeman wrote: > > On Mon, Nov 19, 2018 at 2:21 PM Roy Bamford <neddyseag...@gentoo.org> 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