From: "Ludovic Courtès" <ludo@gnu.org>
To: Christopher Baines <mail@cbaines.net>
Cc: guix-devel@gnu.org
Subject: Re: K of N trust in substitutes (related to reproducible builds)
Date: Tue, 16 Jun 2020 11:36:14 +0200 [thread overview]
Message-ID: <87o8pjwdwx.fsf@gnu.org> (raw)
In-Reply-To: <87lfkq8ugk.fsf@cbaines.net> (Christopher Baines's message of "Sat, 13 Jun 2020 23:35:55 +0100")
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’.
next prev parent reply other threads:[~2020-06-16 9:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-13 22:35 K of N trust in substitutes (related to reproducible builds) Christopher Baines
2020-06-16 9:36 ` Ludovic Courtès [this message]
2020-06-16 19:05 ` Christopher Baines
2020-06-19 20:33 ` Ludovic Courtès
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o8pjwdwx.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=mail@cbaines.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).