unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Wojtek Kosior via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>
To: Josselin Poiret <dev@jpoiret.xyz>
Cc: wolf <wolf@wolfsden.cz>,
	"Simon Tournier" <zimon.toutoune@gmail.com>,
	"Nicolas Débonnaire" <n.debonnaire@gmail.com>,
	guix-devel@gnu.org
Subject: Re: Building from git
Date: Fri, 8 Sep 2023 11:47:56 +0200	[thread overview]
Message-ID: <20230908114756.61b28cf2.koszko@koszko.org> (raw)
In-Reply-To: <87ledht4he.fsf@jpoiret.xyz>

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

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2023-09-08  9:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-02  9:03 Building from git Nicolas Débonnaire
2023-09-05 14:18 ` Wojtek Kosior via Development of GNU Guix and the GNU System distribution.
2023-09-07 12:06 ` Simon Tournier
2023-09-07 16:37   ` Bruno Victal
2023-09-07 17:45   ` wolf
2023-09-07 18:59     ` Simon Tournier
2023-10-23 17:16       ` Nicolas Débonnaire
2023-09-08  9:10     ` Josselin Poiret
2023-09-08  9:47       ` Wojtek Kosior via Development of GNU Guix and the GNU System distribution. [this message]
2023-09-08 11:11         ` wolf
2023-09-09  8:32           ` Josselin Poiret

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=20230908114756.61b28cf2.koszko@koszko.org \
    --to=guix-devel@gnu.org \
    --cc=dev@jpoiret.xyz \
    --cc=koszko@koszko.org \
    --cc=n.debonnaire@gmail.com \
    --cc=wolf@wolfsden.cz \
    --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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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