From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Marshall Subject: Re: Guix and remote trust Date: Fri, 13 Dec 2019 08:05:06 -0500 Message-ID: References: <87eex9r5ay.fsf@ambrevar.xyz> <87h825wkj6.fsf@cbaines.net> <87h824d319.fsf@ambrevar.xyz> <8736doct1z.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:39370) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifkdH-0006UY-2d for help-guix@gnu.org; Fri, 13 Dec 2019 08:05:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ifkdF-0005kM-Jl for help-guix@gnu.org; Fri, 13 Dec 2019 08:05:22 -0500 Received: from mail-qt1-x82a.google.com ([2607:f8b0:4864:20::82a]:46566) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ifkdE-0005hS-Fu for help-guix@gnu.org; Fri, 13 Dec 2019 08:05:21 -0500 Received: by mail-qt1-x82a.google.com with SMTP id 38so2147375qtb.13 for ; Fri, 13 Dec 2019 05:05:20 -0800 (PST) In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: zimoun Cc: help-guix But couldn't a theoretically compromised machine use a VM to obtain the valid hashes? On Fri, Dec 13, 2019, 07:51 zimoun wrote: > Hi Pierre, > > On Fri, 13 Dec 2019 at 13:24, Pierre Neidhardt wrote: > > > > 1. check the integrity on the balaitou machine by running "guix gc > --verify" > > > > I'm not sure this works because if `guix' itself is compromised, > > `guix gc --verify' becomes irrelevant. Or is there another way? > > Ok. And so? > It means that some hashes will differ between the hashes on aneto (you > trust) and balaitou (compromised). > It is not possible to "guix gc --verify" two machines and to obtain > all the same hashes. Or it means that the "attacker" is doing > hash-collision... > > > > > 2. publish the store of aneto with "guix publish" > > > > And then install packages from balaitou? But if Balaitou's "guix" is > > compromised, it does not matter that the substitute server is trusted. > > Your point is to check if balaitou is compromised, right? > The goal of "guix publish" is not to install or serve substitutes, it > is just to publicly expose what we trust. > Whatever from where comes from the binary (substitutes, local build, etc.). > > > > > 3. challenge the store of balaitou against the store of aneto with > > > "guix challenge" > > > > This seems like a good option. In particular, this should verify "guix" > > itself, and thus everything else. > > Without the "guix publish" on aneto, it is hard to "guix challenge" on > balaitou > > > > So I'd reverse your point. By first challenging Balaitou, we can trust > > the guix executable and from there we can run 1. and 2. > > Yes, if you have root access and network control on balaitou, you can > expose it ("guix publish"). > Then Alice will "guix challenge" her own store (on aneto) against the > balaitou one. > > > > Thoughts? > > The only issue is that "guix challenge" works with local builds. > So Alice needs to locally build everything used on balaitou. > I am imagining that aneto is the Alice's laptop and balaitou a server. > So, Alice could populate the aneto store using substitutes (from > ci.guix.gnu.org) for example. And then publishing the result. > And the server balaitou can build what Alice wants to use on balaitou. > > > Well, all this is on theory and principles. :-) > > Hope that helps. > > Cheers, > simon > >