| 1 |
On Mon, Jul 2, 2018 at 11:47 AM, Jason A. Donenfeld <zx2c4@g.o> wrote: |
| 2 |
> On Mon, Jul 2, 2018 at 6:02 PM R0b0t1 <r030t1@×××××.com> wrote: |
| 3 |
>> Signed hashes should be faster, no? Each directory with files could |
| 4 |
>> have a manifest. |
| 5 |
> |
| 6 |
> Signatures work over hashes of data, anyway. I think what you're |
| 7 |
> wondering, though, is the granularity of each signature? I'd recommend |
| 8 |
> this be done on the per-file level, since we wouldn't want gentoo devs |
| 9 |
> signing files in a directory they haven't actually inspected. For |
| 10 |
> example, eclasses. |
| 11 |
> |
| 12 |
|
| 13 |
Ah, okay then - I think at one time in the past GPG did something |
| 14 |
strange with file contents directly, or perhaps the implementation was |
| 15 |
just inefficient. It was maybe related to Debian where I first read |
| 16 |
about this? They were signing an .iso directly and found it was faster |
| 17 |
to hash it and then sign the hash. |
| 18 |
|
| 19 |
>> |
| 20 |
>> > - Ensure the naming scheme of portage files is sufficiently strict, so |
| 21 |
>> > that renaming or re-parenting signed files doesn't result in RCE. [*] |
| 22 |
>> > - Distribute said .asc files with rsync per usual. |
| 23 |
>> |
| 24 |
>> Rsync would work with this setup, but there is also webrsync-gpg in |
| 25 |
>> Portage right now. This covers the vast majority of usecases right |
| 26 |
>> now. |
| 27 |
> |
| 28 |
> Not sure whether you've missed the point or if you're responding to |
| 29 |
> something slightly different, but it's worth noting that both rsync |
| 30 |
> and webrsync-gpg right now check against infra signatures, rather than |
| 31 |
> developer signatures, and this is a big problem. |
| 32 |
|
| 33 |
Right, I lost track of that. The infrastructure or release developers |
| 34 |
are implicitly trusting all developers, so I suppose cutting out the |
| 35 |
middleman will reduce work. |
Archives