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

[Ludovic Courtès]

Hi!

Christopher Baines <mail@cbaines.net> 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).

Nice!

> 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: http://theworld.com/~cme/spki.txt
>
> 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?

Ludo’.