unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Pierre Neidhardt <mail@ambrevar.xyz>
To: zimoun <zimon.toutoune@gmail.com>
Cc: help-guix <help-guix@gnu.org>
Subject: Re: Guix and remote trust
Date: Fri, 13 Dec 2019 14:18:46 +0100	[thread overview]
Message-ID: <87d0csbbyh.fsf@ambrevar.xyz> (raw)
In-Reply-To: <CAJ3okZ3dVFE85HQQ261KNub4YBP5fSvB151Fr6nALQmu4FH+jg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]

zimoun <zimon.toutoune@gmail.com> writes:

> Hi Pierre,
>
> On Fri, 13 Dec 2019 at 13:24, Pierre Neidhardt <mail@ambrevar.xyz> 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...

OK, but why did you mention "guix gc --verify" in the first place?  How
can it help here?

> 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.).

Maybe there is a misunderstanding here.  I meant the we can only perform
the check from Aneto, because we don't trust Balaitou.

The following would not work:

- On Aneto: run guix publish.
- On Balaitou: Install packages using Aneto's trusted packages.

This does not work because the "guix" on Balaitou could very well lie
about what it gets, or even directly compromise what it gets.

>> 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

But you can't run "guix challenge" on balaitou because you can't trust
"guix" there.  It could very well "pass the challenge" while in reality
be compromised.

>> 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.

Yes, this seems correct.

>> 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.

Yes.

> 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.

As mentioned above, I don't think this works because we can't trust
"guix" on balaitou.

The other way around would work (with root access): build everything on
balaitou, guix publish there, then run "guix challenge" on Aneto.

Let me know if I'm incorrect! :)

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  parent reply	other threads:[~2019-12-13 13:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12 14:23 Guix and remote trust Pierre Neidhardt
2019-12-12 16:55 ` Christopher Baines
2019-12-13  8:48   ` Pierre Neidhardt
2019-12-13 11:05     ` zimoun
2019-12-13 12:24       ` Pierre Neidhardt
2019-12-13 12:50         ` zimoun
2019-12-13 13:05           ` Josh Marshall
2019-12-13 13:22             ` Pierre Neidhardt
2019-12-13 13:18           ` Pierre Neidhardt [this message]
2019-12-13 13:38             ` Pierre Neidhardt
2019-12-13 15:26               ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d0csbbyh.fsf@ambrevar.xyz \
    --to=mail@ambrevar.xyz \
    --cc=help-guix@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).