On Sun, 30 Oct 2016 15:41:55 -0700 Zac Medico <[email protected]> wrote:
> On 10/30/2016 03:32 PM, Michał Górny wrote: > > On Sun, 30 Oct 2016 14:58:59 -0700 > > Zac Medico <[email protected]> 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/>
pgpH59SKWLSEZ.pgp
Description: OpenPGP digital signature
