unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: bokr@bokr.com, "Ludovic Courtès" <ludovic.courtes@inria.fr>
Cc: guix-devel <guix-devel@gnu.org>, guix-science@gnu.org
Subject: Re: “Building a Secure Software Supply Chain with GNU Guix”
Date: Fri, 01 Jul 2022 11:21:43 +0200	[thread overview]
Message-ID: <87h741nq6w.fsf@gmail.com> (raw)
In-Reply-To: <20220630213735.GA9726@LionPure>

Hi Bengt,

On jeu., 30 juin 2022 at 23:37, bokr@bokr.com wrote:

> I think IWBN to have some kind of trust code come with that git output,
> like gpg's 1-5 but indicating how well the committer/signer trusts
> that using the code will *not* cause a problem.

Well, from my understanding, Guix is dealing with 4 sort of code:

 1. Guix recipe of a package
 2. Guix service
 3. Guix itself
 4. Upstream 

I do not think committers are pushing code about #1, #2 or #3 that they
know beforehand it will cause a problem.

Therefore, I do not see how it could be implemented without being rooted
in committer feelings, opinion or self-confidence, i.e., highly variable
from one committer to the other.

The GPG trust level works because it is based on the web of trust.
Here, there is no web, IMHO.

Most of the security issues are from #4.  Considering how hard it is to
find and tackle the security issues, there is only two strategies, IMHO:
do not trust which implies deep audit of distributed source code and so
restrict the set of available packages (it is somehow an OpenBSD
approach); or accept more packages which means somehow trust upstream,
to some extent.


However, all in all, it asks what is expected by the reviewing process,
as discussed [1]. :-)

1: <https://yhetil.org/guix/87r13aifi3.fsf_-_@gnu.org>


Cheers,
simon


  reply	other threads:[~2022-07-01 17:43 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 [this message]
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
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=87h741nq6w.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=bokr@bokr.com \
    --cc=guix-devel@gnu.org \
    --cc=guix-science@gnu.org \
    --cc=ludovic.courtes@inria.fr \
    /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).