[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: Tue, 16 Jun 2020 11:36:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)


Christopher Baines <> skribis:

> My feeling is that making some initial step forward in this area is
> going to be tricky, care needs to be taken around the security and
> backwards compatibility aspects. I've now got around to actually
> thinking about potential ways to make parts of this happen though, and
> even changed some code [2] (although I haven't actually tried to run it
> yet).


> As I understand, the format for the ACL is based around [3] and I was
> excited to see as part of that specification is something I think might
> overlap with what I describe wanting above. Specifically, the k-of-n
> <subj-thresh> bit. I think this could work something like this in an
> ACL:
> (acl
>  (entry
>   (k-of-n
>    2
>    3
>    (public-key
>     (ecc
>      (curve Ed25519)
>      (q #5F5F4F321533D3A38F909785E682798933BA9BE257C97E5ABC07DD08F27B8DBF#)
>      )
>     )
>    (public-key
>     (ecc
>      (curve Ed25519)
>      (q #3AF2631C5E78F520CB1DC0D438D8D6F88EEF4B8E11097A62EE2DF390E946AED0#)
>      )
>     )
>    (public-key
>     (ecc
>      (curve Ed25519)
>      (q #1EEE5340C3AAD6E062A1395A88A86FC75982E8BC7DCBAE171858EEAAB14AAB77#)
>      )
>     )
>   )
>   (tag
>    (guix import)
>    )
>   )
> )
> 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.



reply via email to

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