Re: [gentoo-dev] OpenPGP verification for gentoo-mirror repos

[Michał Górny]

On Sun, 30 Oct 2016 15:41:55 -0700
Zac Medico <zmedico@g.o> wrote:

> On 10/30/2016 03:32 PM, Michał Górny wrote:
> > On Sun, 30 Oct 2016 14:58:59 -0700
> > Zac Medico <zmedico@g.o> wrote:
> >
> >> On 10/30/2016 01:44 PM, Michał Górny wrote:
> >>> Hi, everyone.
> >>>
> >>> Just a quick note: I've prepared a simple tool [1] to verify clones of
> >>> gentoo-mirror repositories. It's still early WiP but can be easily used
> >>> to verify a clone:
> >>>
> >>>   $ ./verify-repo gentoo
> >>>   [/var/db/repos/gentoo]
> >>>   Untrusted signature on 42ccdf48d718287e981c00f25caea2242262906a
> >>>   (you may need to import/trust developer keys)
> >>>   Note: unsigned changes in metadata and/or caches found (it's fine)
> >>
> >> I don't think it's acceptable to use an unsigned metadata/cache commit.
> >> Can't we use an infrastructure key for this?
> >
> > How are you going to guarantee that a third-party didn't access
> > the remote server and alter the filesystem just before the commit? Not
> > to mention the pains of keeping the key secure.
> >
> > It's better not to sign that to provide false security.
>
> There's no absolute guarantee that the developer's key hasn't been
> compromised either. So we've got varying degrees of trust. An automated
> infrastructure signature may not have as much trust as a developer
> signature, but it's still better than nothing, for the same reason that
> publishing these key fingerprints via https is better than http:
>
> https://wiki.gentoo.org/wiki/Project:RelEng#Keys

The HTTPS argument is fairly irrelevant. There is a reason why project
publish tarball OpenPGP signatures, rather than relying on official
HTTPS downloads. It's not only about mirrors and subsequent
verification.

The major difference between a developer key and an automated key is
that the latter is far easier target. I think we can trust Gentoo
developers to at least have their keys encrypted. I suppose most of
them don't 'git log -p' the commits their sign but well, it's still
harder to target a developer PC than a public server that most likely
keeps its signature key unencrypted (or with cleartext password).

That said, repo-mirror-ci is running as user processes on a donated
space on a third-party server. We have no way of ensuring that it is
secure. Even if it were on Gentoo Infra, things wouldn't be much
better.

Furthermore, one important point in OpenPGP-signed commits is that
the top signature signs both the commit itself and its parent,
implicitly confirming all past commits. So if I am supposed to sign
the automated commit, I have to verify the signatures on the preceding
commit first. And where are the working tools to do that?

On the other hand, Gentoo developers already sign their commits without
verifying if the commits preceding them are trusted. We only have some
minor server-side verification from Infra, with future possibility of
verifying signatures client-side.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>