<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2014-01-13 10:21, Василий Долматов
wrote:<br>
</div>
<blockquote
cite="mid:0361128E-C7E3-4667-913E-1A1337596C2E@reedcat.net"
type="cite">
<pre wrap="">
13 янв. 2014 г., в 12:19, Fredrik Thulin <a class="moz-txt-link-rfc2396E" href="mailto:fredrik@thulin.net"><fredrik@thulin.net></a> написал(а):
</pre>
<blockquote type="cite">
<pre wrap="">On Monday 13 January 2014 11.44.15 Василий Долматов wrote:
</pre>
<blockquote type="cite">
<pre wrap="">13 янв. 2014 г., в 11:17, Rob Austein <a class="moz-txt-link-rfc2396E" href="mailto:sra@hactrn.net"><sra@hactrn.net></a> написал(а):
</pre>
<blockquote type="cite">
<pre wrap="">At Mon, 13 Jan 2014 15:59:02 +0900, Randy Bush wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- Don't attempt to automate enforcement of the signed commit policy,
</pre>
</blockquote>
<pre wrap="">
why not?
</pre>
</blockquote>
<pre wrap="">
Good to have, not critical path, or so went the thinking, such as it was.
</pre>
</blockquote>
<pre wrap="">
Agree, not a critical path.
Once, again, implementing security measures it is necessary to start from
threat model. Otherwise it becomes «Security Theatre» (c)
</pre>
</blockquote>
<pre wrap="">
IMO it would lessen the impact of a repository server compromise because
commits could not be forged from there.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
right, the commit hook is there to "remind" users to sign basically<br>
<blockquote
cite="mid:0361128E-C7E3-4667-913E-1A1337596C2E@reedcat.net"
type="cite">
<pre wrap="">
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 ;) ).
</pre>
<blockquote type="cite">
<pre wrap="">
It would also give us much more to work with if/when the repository server
and/or a committers workstation has been compromised.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">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@
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Core mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Core@cryptech.is">Core@cryptech.is</a>
<a class="moz-txt-link-freetext" href="https://cryptech.is/mailman/listinfo/core">https://cryptech.is/mailman/listinfo/core</a>
</pre>
</blockquote>
<br>
</body>
</html>