[Cryptech Core] git, again

[Василий Долматов]

13 янв. 2014 г., в 12:19, Fredrik Thulin <fredrik at thulin.net> написал(а):

> On Monday 13 January 2014 11.44.15 Василий Долматов wrote:
>> 13 янв. 2014 г., в 11:17, Rob Austein <sra at hactrn.net> написал(а):
>>> At Mon, 13 Jan 2014 15:59:02 +0900, Randy Bush wrote:
>>>>> - Don't attempt to automate enforcement of the signed commit policy,
>>>> 
>>>> why not?
>>> 
>>> Good to have, not critical path, or so went the thinking, such as it was.
>> 
>> Agree, not a critical path.
>> 
>> Once, again, implementing security measures it is necessary to start from
>> threat model. Otherwise it becomes «Security Theatre» (c)
> 
> IMO it would lessen the impact of a repository server compromise because 
> commits could not be forged from there.

Mmmm… Maybe we are talking about different things…

I have meant mechanism, when server _checks_ the signature of commit and puts or refuses to put commit in repository. That mechanism cannot fight with server compromise obviously.

Seems that you are talking about procedure, when every downloader checks the signature under  every commit, right? That means the necessity of distributing all public keys, maintaining that list, handling key revocation and changes, thus creating key server and moving same threat to it (100 to 1 that this key distribution server will be placed near repository server and if repository server were compromised, it would be compromised as well ;) ). 
> 
> It would also give us much more to work with if/when the repository server 
> and/or a committers workstation has been compromised.
If committer workstation has been compromised, keys used for access to repository are compromised as well as keys which were used for signing commits.
Commits signing does not add even tiny bit of security in this case.

> 
> I vote for signed commits, and also trying to automate enforcement. We also 
> need client side verification of commit signatures when we pull from the 
> repository server.
Yess… I guessed right… 
A lot of workload on client side, new resource that demands securing and maintaining,  having the only goal - «signed commits». ;) And adding nothing to the overall system security. 

dol@

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4815 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/core/attachments/20140113/f2b4938e/attachment.bin>