| 1 |
On 07/02/2018 08:08 PM, Jason A. Donenfeld wrote: |
| 2 |
> On Mon, Jul 2, 2018 at 7:57 PM Rich Freeman <rich0@g.o> wrote: |
| 3 |
>> This only helps you if a dev you don't trust is compromised. If a dev |
| 4 |
>> you trust is compromised, they can modify anything in the tree and |
| 5 |
>> you're hosed. |
| 6 |
> Yes indeed. This is more or less what we're aiming for. Putting the |
| 7 |
> trust in developers. The goal is for infra not to be the weak link in |
| 8 |
> this, as it currently is. |
| 9 |
> |
| 10 |
>> Sure, I'd prefer to not extract git signatures and just distribute via |
| 11 |
>> git purely without any rsync. |
| 12 |
> Yea, I personally don't really care much for rsync either. I've just |
| 13 |
> kind of been assuming this is a requirement of any gentoo solution. |
| 14 |
> But maybe this whole thing should take another dimension, and we |
| 15 |
> should instead talk about sunsetting rsync, and moving to a model of: |
| 16 |
> 1) git fetch, 2) git verify, 3) git checkout? There still might be |
| 17 |
> problems with "untrusting" devs, as I wrote above, but perhaps there's |
| 18 |
> room to grow within the git framework, by manually filtering commits |
| 19 |
> during checkout, or even by imposing ebuild directory signature-based |
| 20 |
> ACLs that I think you were hinting at before. So, sure, if you want to |
| 21 |
> call for an abolition of rsync, maybe I'd follow you in that direction |
| 22 |
> instead of the one here I'm proposing. |
| 23 |
> |
| 24 |
> |
| 25 |
|
| 26 |
picking a semi-random post to respond to, but the key management you're |
| 27 |
introducing with such a proposal is just silly. |
| 28 |
|
| 29 |
-- |
| 30 |
Kristian Fiskerstrand |
| 31 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
| 32 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives