<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 2:48 PM, zooko <span dir="ltr"><<a href="mailto:zooko@zooko.com" target="_blank">zooko@zooko.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, Sep 08, 2013 at 08:28:27AM -0400, Phillip Hallam-Baker wrote:<br>
><br>
> It think we need a different approach to source code management. Get rid of<br>
> user authentication completely, passwords and SSH are both a fragile<br>
> approach. Instead every code update to the repository should be signed and<br>
> recorded in an append only log and the log should be public and enable any<br>
> party to audit the set of updates at any time.<br>
><br>
> This would be 'Code Transparency'.<br>
<br>
</div>This is a very good idea, and eminently doable. See also Ben Laurie's blog<br>
post:<br>
<br>
<a href="http://www.links.org/?p=1262" target="_blank">http://www.links.org/?p=1262</a><br>
<div class="im"><br>
> Problem is we would need to modify GIT to implement.<br>
<br>
</div>No, simply publish the git commits (hashes) in a replicated, append-only log.<br></blockquote><div><br></div><div>Well people bandwidth is always a problem.</div><div><br></div><div>But what I want is not just the ability to sign, I want to have a mechanism to support verification and checking of the log etc. etc.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So what's the next step? We just need the replicated, append-only log.<br></blockquote><div><br></div><div>Where I am headed is to first divide up the space for PRISM-PROOF email between parts that are solved and only need good execution (message formats, mail integration, etc) and parts that are or may be regarded as research (key distribution, key signing, PKI).</div>
<div><br></div><div>Once that is done I am going to be building myself a very lightweight development testbed built on a SMTP/SUBMIT + IMAP proxy. </div><div><br></div><div>But hopefully other people will see that there is general value to such a scheme and work on:</div>
<div><br></div><div>[1] Enabling MUAs to make use of research built on the testbed.</div><div><br></div><div>[2] Enabling legacy PKI to make use of the testbed.</div><div><br></div><div>[3] Research schemes</div><div> </div>
</div><div><br></div><div>Different people have different skills and different interests. My interest is on the research side but other folk just want to write code to a clear spec. Anyone going for [3] has to understand at the outset that whatever they do is almost certain to end up being blended with other work before a final standard is arrived at. We cannot afford another PGP/SMIME debacle.</div>
<div><br></div><div>On the research side, I am looking at something like Certificate Transparency but with a two layer notary scheme. Instead of the basic infrastructure unit being a CA, the basic infrastructure unit is a Tier 2 append only log. To get people to trust your key you get it signed by a trust provider. Anyone can be a trust provider but not every trust provider is trusted by everyone. A CA is merely a trust provider that issues policy and practices statements and is subject to third party audit.</div>
<div><br></div><div><br></div><div>The Tier 2 notaries get their logs timestamped by at least one Tier 1 notary and the Tier 1 notaries cross notarize.</div><div><br></div><div>So plugging code signing projects into a Tier 2 notary would make a lot of sense.</div>
<div><br></div><div>We could also look at getting Sourceforge and GITHub to provide support maybe.</div><div><br></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>