[Top][All Lists]

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

Re: K of N trust in substitutes (related to reproducible builds)

From: Ludovic Courtès
Subject: Re: K of N trust in substitutes (related to reproducible builds)
Date: Fri, 19 Jun 2020 22:33:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)


Christopher Baines <> skribis:

> Ludovic Courtès <> writes:
>>> 3:
>>> Using the above ACL, you'd trust a substitute for a path with a specific
>>> hash if you can find 2 narinfos for that path and hash if they're signed
>>> with keys in that entry. Multiple entries would still be supported, and
>>> you wouldn't need to specify the k-of-n bit if you don't want to.
>>> I'm not quite sure how expressive this is, or if there are some policies
>>> that would be good to support that either can't be expressed, or can't
>>> be expressed easily. There's probably other approaches, and how to
>>> support trusting substitutes is an important part to consider.
>> I would be tempted to not bake it into /etc/guix/acl.  You would still
>> authorize all the servers, but instead of choosing a policy that accepts
>> anything signed by one of them, as is currently the case, you would
>> choose a policy that only accepts something signed by two of them.
>> The policy would be implemented in (guix scripts substitute).  I haven’t
>> put much thought into it but it could be something akin to
>> ‘lookup-narinfos/diverse’, roughly.
>> Thoughts?
> I think that could work, do you have any suggestions on how that "two"
> would be configured? I guess it could be a boolean on/off, but it would
> be probably more extensible to just allow providing a minimum number of
> substitiute servers to agree.

There should be a procedure that takes a list of narinfos signed with an
authorized key and returns a Boolean.

Then there can be a higher-order procedure returning a predicate, like:

  (make-ratio-predicate k n)

The user-chosen predicate could live in /etc/guix/substitute-policy.scm
or similar.


reply via email to

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