Re: [gentoo-dev] Trustless Infrastructure

[Michał Górny]

W dniu pon, 02.07.2018 o godzinie 20∶01 +0200, użytkownik Jason A.
Donenfeld napisał:
> On Mon, Jul 2, 2018 at 7:21 PM Michał Górny <mgorny@g.o> wrote:
> >
> > W dniu pon, 02.07.2018 o godzinie 19∶01 +0200, użytkownik Jason A.
> > Donenfeld napisał:
> > > On Mon, Jul 2, 2018 at 6:58 PM Michał Górny <mgorny@g.o> wrote:
> > > > - Have verification use a keyring of all Gentoo developers, with a
> > > > > manual prompt to add new Gentoo developers to it.
> > > >
> > > > How are you going to distribute this keyring, and how are you going to
> > > > protect attacker from injecting malicious key into it?
> > >
> > > Same model as Arch.
> > >
> >
> > Please write it down here instead of expecting us to figure it out.
> > It's your proposal, and it should be complete.
>
> I believe Arch's system relies on some core developers having master
> keys and the revocation certificates being distributed amongst them:
>
> https://www.archlinux.org/master-keys/
>
> Then all other developers are signed from there in one way or another.
> It's kind of a modified web of trust.
>
> I don't know whether or not this is necessarily the best model to
> emulate -- perhaps we could do better, for example -- but it does seem
> like a good starting point. Instead we might prefer a single hardware
> device somewhere.
>
> The idea would be -- portage fetches an updated "key list" from
> somewhere. This new list of keys is considered if it is: a) signed by
> the master keys and b) internally fulfills some WoT topological
> requirements. Then, if these pass, it is up to the user to then
> manually [y/N] the addition of new keys to the key ring. If they
> suspect a particular developer has bad security practices, for
> example, they could trivially [N] it, and then not have tree files he
> touched copied from the shadow location to the portage directory.

I'm afraid that in order to convince me you need to have a clear, well-
defined model that improves security over the current solution.

In other words, I see no purpose in adding a lot of complexity in order
to shift the weakest link from one Infra machine handling the signing to
another single point of failure in distributing the keys.

-- 
Best regards,
Michał Górny