all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Bengt Richter <bokr@bokr.com>
To: zimoun <zimon.toutoune@gmail.com>
Cc: "Ludovic Courtès" <ludovic.courtes@inria.fr>,
	guix-devel <guix-devel@gnu.org>,
	guix-science@gnu.org
Subject: Re: “Building a Secure Software Supply Chain with GNU Guix”
Date: Sun, 3 Jul 2022 12:38:39 +0200	[thread overview]
Message-ID: <20220703103839.GA41557@LionPure> (raw)
In-Reply-To: <87h741nq6w.fsf@gmail.com>

Hi Simon, and all,

On +2022-07-01 11:21:43 +0200, zimoun wrote:
> 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.
>

Hm, -- unless <context-requirements-not-met> ... ? :)

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

Well, guix developers who know each other well "in real life" have a pretty
good web, if not formal, no? :)
It's just not accessible to newcoming outsiders, who can't see the trust
codes in the insiders' heads :)

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

Agreed, #4 is usually the source of security issues.

I'm just looking for some greppable coded hint of the difference between
a package that consists of e.g. a reverse polish calculator homework
assignemnt that a nerdy friend showed how to submit as a package, vs.
e.g. a package where the comments say over 10K subscribers have now been
running this hundreds of times daily for 2 months of beta testing with
no reported problems. Vs. This is alpha stuff, but seems harmless enough
if you run it in a container.

I'm not asking any guarantees, just a professional's quick judgement.
Like a chef's quick opinion on the cantaloupes at the open market. 

This is separate from the issue of whether to include a package under guix.
No blocker if the cantaloupe is not ripe, but helpful to have a sticker
saying so, for those who (for lack of time perhaps) want to order on line
and use grep instead of their nose :)

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

I am not forgetting that I should be thankful for anything I am provided
freely. So thank you all!
--
Regards,
Bengt Richter



  reply	other threads:[~2022-07-03 10:39 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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220703103839.GA41557@LionPure \
    --to=bokr@bokr.com \
    --cc=guix-devel@gnu.org \
    --cc=guix-science@gnu.org \
    --cc=ludovic.courtes@inria.fr \
    --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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.