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