1 |
On Mon, Jul 2, 2018 at 12:43 PM Jason A. Donenfeld <zx2c4@g.o> wrote: |
2 |
> |
3 |
> There's a lot of text there, and rather than trying to parse all of |
4 |
> that, I'll just reiterate a primary important design goal that might |
5 |
> be overlooked: |
6 |
> |
7 |
> - End to end signatures from the developer to the user. |
8 |
> |
9 |
> This means that no matter the operation infra does before shipping it |
10 |
> out to the user, the user still needs to verify that the packages came |
11 |
> from the developers. In other words, whatever complicated mechanism |
12 |
> you propose, it needs to not rely on trusting infra to hold onto any |
13 |
> secrets. For example, I don't know whether this is attainable with the |
14 |
> the git signatures alone, without requiring users to sync the entire |
15 |
> git repository, which might not be acceptable for some. |
16 |
> |
17 |
|
18 |
You might want to read what I wrote then, because I proposed options |
19 |
for using the git signatures over rsync, as well as for with git |
20 |
syncing (which IMO is an under-rated option, as there is no need to |
21 |
preserve all the past commits in the repository once it is known-good, |
22 |
which I also mention). |
23 |
|
24 |
Everything I wrote is possible with dev signatures only, and would |
25 |
work fine over a completely compromised infrastructure, or non-Gentoo |
26 |
infrastructure. Granted, if you want to do git sigs over rsync you do |
27 |
need an untrusted program to do the extractions and if that fails it |
28 |
would be a DOS. |
29 |
|
30 |
If you think that one of my alternatives fails to meet your goals I'd |
31 |
be interested in hearing about it. |
32 |
|
33 |
-- |
34 |
Rich |