From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 878FB138334 for ; Mon, 19 Nov 2018 19:51:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 04B31E088F; Mon, 19 Nov 2018 19:51:19 +0000 (UTC) Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 914D6E07DF for ; Mon, 19 Nov 2018 19:51:18 +0000 (UTC) Received: by mail-pl1-f194.google.com with SMTP id b5so8652871plr.4 for ; Mon, 19 Nov 2018 11:51:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vg8NF7D9xypVdhgtglgEbLhQmOM1niK5qxgFm6OgUQk=; b=X05koyGc8fifx+MRLYQK/Mp8sTwjGs9EVHoKZJX6JYPJPO9WAuGbO+56jXc3MkcYb9 en0JgXg9j5dFuqukYXlOT8ah+bjahI74Q8eaqm4211KmzezjRUMzpkgqDx66erbcv3b/ y9wFw+35+sHM/VaPvbNwNiQe/T6n8irm2ftllIbAlUzGOYg0MH9YCuZM+rKXCc8o7kGQ XENFHj6bh0fBH5BraVrYpozjh5N4nYz6kyP5WGRoo2dniUdjW7uKonAjy/FK+GiBBHrf 8eZLtePBybusoxgUG57NL8MoyrUASk092M9YBKb0ycvs3BFK260HXiRWEXPTn+OdlW3W uW2A== X-Gm-Message-State: AGRZ1gJ0z+sCr34oapiRuY3juZXdeQGTAZu9NYfdkQZMYTsibaQAY6aV nDQq4VHEpJcxwe+TbbafiQm7RiBrNGToWSi3EhKz4w1F X-Google-Smtp-Source: AJdET5cxFNdAQXTigCHK0XYAMEpMOBTaQjGwTaqLotLX+IcMRsNp/9gbnA21yaojWsvPHoIDRxV+4HI2bXoXmcl0M/g= X-Received: by 2002:a17:902:404:: with SMTP id 4-v6mr24154202ple.331.1542657077101; Mon, 19 Nov 2018 11:51:17 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 References: <1542652504.26086.4.camel@gentoo.org> <2oZseLC4rnPfibSkOcVhyV@7goCMnFg7BjVAn3Dwj0Mo> <76ff3312-94ad-6f28-0b16-e5f9ff1c1348@gentoo.org> In-Reply-To: <76ff3312-94ad-6f28-0b16-e5f9ff1c1348@gentoo.org> From: Rich Freeman Date: Mon, 19 Nov 2018 14:51:05 -0500 Message-ID: Subject: Re: [gentoo-dev] [pre-GLEP r1] Gentoo binary package container format To: Zac Medico Cc: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 37e10497-de0e-4fef-87f5-29f128bb1d0b X-Archives-Hash: 8da2237914a71394515ee598474395f7 On Mon, Nov 19, 2018 at 2:40 PM Zac Medico wrote: > > On 11/19/18 11:33 AM, Rich Freeman wrote: > > On Mon, Nov 19, 2018 at 2:21 PM Roy Bamford 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