guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building from git


From: Wojtek Kosior
Subject: Re: Building from git
Date: Fri, 8 Sep 2023 11:47:56 +0200

Hello Josselin

> wolf <wolf@wolfsden.cz> writes:
> 
> > Hmm, but the recipe for the authenticate rule comes from the (possibly)
> > compromised source, no?  So the attacker can just modify the recipe instead 
> > of
> > the command going the authentication.  Am I missing something?  
> 
> You can use a previously trusted guix to do the authentication.  `make
> authenticate` is here for committers to check that their commits are all
> properly signed before pushing (it's used as a pre-push hook).

From my understanding of the documentation, `make authenticate` is not
just for committers but for all people who do a `git pull` in Guix tree
and want to verify that the newly pulled commits do come from the
committers. It it is not the case, then the documentation should
probably be modified to make it clear.

The recipe is not from an untrusted source mecause the Makefile is not
tracked by git. Rather, it gets generated when first building Guix. And
— as the documentation instructs — the initial checkout gets
authenticated with `guix git authenticate` rather than with `make
authenticate` so it can't get compromised that easily.

Had someone managed to serve us a commit that adds another Makefile
with a backdoor, git would report a conflict upon pulling. I believe
this is what the implementors had in mind. Please clarify if this is
wrong.

I do see 1 loophole here, though. One could serve a compromised
makefile under the name "GNUmakefile" and `make authenticate` would
happily choose it over the non-compromised "Makefile". I was planning
to start a new thread about it for some time... but this one seems like
a just as appropriate place to mention the issue.

It shouldn't be hard to fix. It boils down to having ./configure create
a GNUmakefile as well. Perhaps as a symlink to the original Makefile?

Best,
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Fri, 08 Sep 2023 11:10:37 +0200 Josselin Poiret <dev@jpoiret.xyz> wrote:

> Hi,
> 
> wolf <wolf@wolfsden.cz> writes:
> 
> > Hmm, but the recipe for the authenticate rule comes from the (possibly)
> > compromised source, no?  So the attacker can just modify the recipe instead 
> > of
> > the command going the authentication.  Am I missing something?  
> 
> You can use a previously trusted guix to do the authentication.  `make
> authenticate` is here for committers to check that their commits are all
> properly signed before pushing (it's used as a pre-push hook).
> 
> Best,

Attachment: pgplk6j6S88wv.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]