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 15:47:49 +0100 Message-ID: <87fth4bj6y.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> 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]:47518) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilDOp-0005a9-8l for bug-guix@gnu.org; Sat, 28 Dec 2019 09:49:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ilDOn-0005Vm-SX for bug-guix@gnu.org; Sat, 28 Dec 2019 09:49:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:52074) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ilDOn-0005Uh-N6 for bug-guix@gnu.org; Sat, 28 Dec 2019 09:49:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87png9o8i2.fsf@elephly.net> (Ricardo Wurmus's message of "Fri, 27 Dec 2019 20:48:05 +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 Hello! Ricardo Wurmus skribis: > Ludovic Court=C3=A8s writes: > [...] >> While reading >> , I >> realized we could store in empty Git commit messages, which would >> address the above problem (we could use a custom object type too, but >> that would be less convenient.) >> >> So the special commit could look like: >> >> Authorization >> >> (commit-authorizations >> (authorization-commit (KEY1 KEY2 =E2=80=A6)) >> (files ("hydra.gnu.org.pub") (KEY1 KEY2 =E2=80=A6)) >> (files _ (KEY1 KEY2 =E2=80=A6))) ;all other files >> >> That way, to authenticate a commit, we first fetch the latest >> authorization commit, read the authorization rules from there, and make >> sure that the changes it makes match the rules. >> >> Thoughts? > > Does this *have* to be baked into git? Or are we like the carpenter > apprentice who just learned how to use a hammer and considers everything > to be a kind of nail=E2=80=A6? > > I see the appeal of having everything in git as that=E2=80=99s where the = commits > are that should be authenticated, but using special commit messages > seems to me like shoehorning update authorization into a code revision > tool. Well, I=E2=80=99ve changed my mind on this topic since that message. :-) Now, the way I see it, we=E2=80=99d have a plain file listing authorized ke= ys (the file is under version control, but it=E2=80=99s a regular file). That still needs to be prototyped to check whether it=E2=80=99s acceptable performance-wise, but I=E2=80=99m more confident now. > You mentioned that checking signatures on commits is also kinda slow > because it=E2=80=99s sequential and not cached. I don=E2=80=99t know wha= t I really > want, but is there perhaps a way to aggregate signatures on past commits > so that the client=E2=80=99s work is reduced=E2=80=A6? The caching implemented in 787766ed1e7f0806a98e696830542da528f957bb makes things acceptable: the first =E2=80=9Cmake authenticate=E2=80=9D run = 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. I have plans to make things faster (independently of the cache) by doing OpenPGP signature verification entirely in Scheme instead of spawning =E2=80=98gpgv=E2=80=99 every time. Again, we=E2=80=99ll have to get a prot= otype before we can tell whether it actually is faster. I hope I can spend some more time on this during the holidays, but anyhow, feedback is much appreciated! Thanks, Ludo=E2=80=99.