guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: “Building a Secure Software Supply Chain with GNU Guix”


From: Bengt Richter
Subject: Re: “Building a Secure Software Supply Chain with GNU Guix”
Date: Sun, 3 Jul 2022 12:38:39 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]