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
next prev parent 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.