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 <mgo...@gentoo.org> 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 <mgo...@gentoo.org> 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
signature.asc
Description: This is a digitally signed message part
