unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludovic.courtes@inria.fr>
To: Zhu Zihao <all_but_last@163.com>
Cc: guix-science@gnu.org,  guix-devel@gnu.org
Subject: Re: “Building a Secure Software Supply Chain with GNU Guix”
Date: Mon, 18 Jul 2022 10:45:41 +0200	[thread overview]
Message-ID: <87k08a4xmy.fsf@inria.fr> (raw)
In-Reply-To: <86fsj0nnxy.fsf@163.com> (Zhu Zihao's message of "Sun, 17 Jul 2022 15:54:29 +0800")

Hi,

Zhu Zihao <all_but_last@163.com> skribis:

> There's still some questions to ask. I'm concerned about the safety of
> the evaluation of channel code. IIRC, there's no sandbox for the
> evaluation of package in channel. So, it's possible to inject some
> side-effect code into a channel like
>
> ```
> (define-module (my channel code))
>
> (display "I'm planning to do evil things here!")
>
> (define-public some-package ...)
> (define-public another-package ...)
> ```

Yes.

> We have PGP sign and git commit chain to make sure the commits are
> committed by trusted people. But it's still possible for the channel
> owner to inject malicious code into the channel in a future commit. Like
> what Marak Squires did in faker.js project :( or the committer of Guix
> was attacked by an evil maid.

I’m not aware of the faker.js story, do you have a link?

The model here is that users trust authorized committers.  When you
think about it, there’s no way around it, because at the end of the day,
you’re installing software that an authorized committer added to the
channel.

To put it differently, side effects in the .scm file as you show above
are just one of the many ways an authorized committer could harm users.

> In Nix flakes, there's pure evaluation to make sure no side-effectful
> code is allowed. But Guix channel is less restricted than a Nix flake.
> It's a important problem to make sure the evaluation is safe for the user.

Yes, I understand.  I don’t think that makes a practical difference
though: when you pull from a Guix channel or fetch a Nix flake, that’s
because you want to install software according to what that
channel/flake provides.  So whether evil code is in the channel/flake
(as Scheme/Nix code) or in the package(s) themselves makes little
difference.

Does that make sense?

(Besides, there’s no mechanism for authenticated updates of flakes or of
Nixpkgs, which is the core of the paper.)

Thanks for your feedback!

Ludo’.


  reply	other threads:[~2022-07-18  8:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30 14:13 “Building a Secure Software Supply Chain with GNU Guix” Ludovic Courtès
2022-06-30 21:37 ` bokr
2022-07-01  9:21   ` zimoun
2022-07-03 10:38     ` Bengt Richter
2022-07-04  8:21       ` zimoun
2022-07-04 14:56         ` Bengt Richter
2022-07-04  7:44   ` Ludovic Courtès
2022-07-17  7:54 ` Zhu Zihao
2022-07-18  8:45   ` Ludovic Courtès [this message]
2022-07-18  9:40     ` Zhu Zihao
2022-07-18 12:30       ` Ludovic Courtès
2022-07-18 12:38         ` Ricardo Wurmus
2022-07-19 13:53     ` Maxime Devos
2022-07-19  7:21 ` Arun Isaac
2022-07-19 12:11   ` Ludovic Courtès
2022-07-20  6:17     ` Arun Isaac
2022-07-19 13:45   ` Maxime Devos
  -- strict thread matches above, loose matches on Subject: below --
2022-07-19  0:35 Jeremiah

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=87k08a4xmy.fsf@inria.fr \
    --to=ludovic.courtes@inria.fr \
    --cc=all_but_last@163.com \
    --cc=guix-devel@gnu.org \
    --cc=guix-science@gnu.org \
    /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).