[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix and remote trust
From: |
Pierre Neidhardt |
Subject: |
Re: Guix and remote trust |
Date: |
Fri, 13 Dec 2019 14:18:46 +0100 |
zimoun <address@hidden> writes:
> Hi Pierre,
>
> On Fri, 13 Dec 2019 at 13:24, Pierre Neidhardt <address@hidden> 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/
signature.asc
Description: PGP signature
- Guix and remote trust, Pierre Neidhardt, 2019/12/12
- Re: Guix and remote trust, Christopher Baines, 2019/12/12
- Re: Guix and remote trust, Pierre Neidhardt, 2019/12/13
- Re: Guix and remote trust, zimoun, 2019/12/13
- Re: Guix and remote trust, Pierre Neidhardt, 2019/12/13
- Re: Guix and remote trust, zimoun, 2019/12/13
- Re: Guix and remote trust, Josh Marshall, 2019/12/13
- Re: Guix and remote trust, Pierre Neidhardt, 2019/12/13
- Re: Guix and remote trust,
Pierre Neidhardt <=
- Re: Guix and remote trust, Pierre Neidhardt, 2019/12/13
- Re: Guix and remote trust, zimoun, 2019/12/13