<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 7, 2014 at 4:22 AM, Elias Persson <span dir="ltr"><<a href="mailto:delreich@takeit.se" target="_blank">delreich@takeit.se</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A signed tag from CentOS would say "this is the content from<br>
which we built our SRPM". It wouldn't be "signing the sources"<br>
any more than the signing of SRPMs would be. Why would that be<br>
bad?</blockquote><div><br></div><div>It's not bad as such, just useless. If I, the end user, am concerned about the sources having been illicitly tampered with, all this tells me is that I've got the same (untrusted, possibly trojaned) sources as CentOS. Big whoop. If upstream signed the content they push, though, then I'd be able to put my trust in upstream -- i.e., in the people who are actually curating and creating the vast majority of the content.</div>
<div><br></div><div>Until that happens, the tiny bit of value that might be derived from having a cryptographically secure means of knowing that I've been pwned in exactly the same was as CentOS is just not worth the work that would go into it. It might even be a little misleading, since there would be an appearance of trust and security where none actually existed. This really seriously needs to start with upstream, or it's all for naught.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> [...] Until then, a signed tag from CentOS just tells<br>
<div class="">> us that someone trusted made a change to something untrusted, and the<br>
> net result is still untrusted because -- say it with me this time -- the<br>
> chain of trust was broken by *upstream*.<br>
<br>
</div>And this would be different for signed (S)RPMs how, exactly?</blockquote></div><div class="gmail_extra"><br></div>It's not much different, really. A signed RPM tells me that CentOS did, in fact, build that RPM. It eliminates one possible point of contamination, but it does not ensure an unbroken chain of trust. Back in the olden days, it would have told me that CentOS built it using opaque processes from a signed upstream source -- the SRPMs at <a href="http://ftp.redhat.com">ftp.redhat.com</a> -- so there was still a break in the chain of trust, since CentOS's processes were insufficiently public. They're now increasingly public, so a signed RPM tells me that CentOS built the RPM, using well-known processes, from which point I could follow back the build logs and discover the unsigned, untrusted sources it was built from. Whereupon the chain of trust again disappears.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Do you trust CentOS to properly vet all of the sources they pull from <a href="http://git.centos.org">git.centos.org</a>? I don't. You saw how quickly they moved from RHEL 7.0 GA to CentOS 7.0 RC -- they weren't doing code audits. Upstream's security and audit processes are completely opaque, but I at least have some confidence that they exist. Without them signing the sources, though, all of the cryptographic assurance people have been talking about in this thread disappears completely.<br clear="all">
<div><br></div>-- <br>Chris St. Pierre
</div></div>