From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#22883: Authenticating a Git checkout Date: Sat, 28 Dec 2019 18:45:36 +0100 Message-ID: <87k16g9we7.fsf@gnu.org> References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org> <20160426001359.GA23088@jasmine> <874majg0z8.fsf@gnu.org> <87bn3iz1xc.fsf_-_@gnu.org> <87wpket748.fsf@gnu.org> <87bmkwm8ed.fsf@gnu.org> <87png9o8i2.fsf@elephly.net> <87fth4bj6y.fsf@gnu.org> <87k16go2oq.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:55384) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilGA8-0008Nk-HC for bug-guix@gnu.org; Sat, 28 Dec 2019 12:46:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ilGA7-0006JY-Fo for bug-guix@gnu.org; Sat, 28 Dec 2019 12:46:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:52898) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ilGA7-0006HC-8T for bug-guix@gnu.org; Sat, 28 Dec 2019 12:46:03 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87k16go2oq.fsf@elephly.net> (Ricardo Wurmus's message of "Sat, 28 Dec 2019 17:05:57 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ricardo Wurmus Cc: 22883@debbugs.gnu.org Hi, Ricardo Wurmus skribis: > Ludovic Court=C3=A8s writes: > >> The caching implemented in 787766ed1e7f0806a98e696830542da528f957bb >> makes things acceptable: the first =E2=80=9Cmake authenticate=E2=80=9D r= un takes a bit >> more than two minutes to check all the commits starting from =E2=80=98v1= .0.1=E2=80=99, >> but subsequent runs take a few seconds. > > This sounds good. > > I wonder how we would integrate this into =E2=80=9Cguix pull=E2=80=9D. F= or > authentication to work at all the user would have to have *all* past > keys. (I=E2=80=99m missing at least one of the keys, because only curren= t keys > are contained in the keyring on Savannah.) Right. Clearly we shouldn=E2=80=99t rely on key servers because it=E2=80= =99s brittle, keys might be missing, it requires the whole GnuPG shebang to fetch a single key, etc. Instead, what I have in mind is to have a branch in the same repo containing a complete keyring of the past and current keys (say, one file per key). The machinery would thus start by loading the keyring and then use it when verifying signatures. We can generalize that to all channels: =E2=80=98.guix-channel=E2=80=99 cou= ld specify (1) a keyring branch, and (2) the name of a file listing authorized keys. How does that sound? Thanks, Ludo=E2=80=99.