On Sun, Jul 6, 2014 at 5:23 PM, Mark Mielke mark.mielke@gmail.com wrote:
A PGP-signed tag makes a promise about the content but does *not* make a promise about the origin host.
So, they are not the same.
In the case of git.centos.org, somebody who manipulates the repositories could likely fake the repository content being consistent, but would have a more difficult time faking a signature where the public key is stored elsewhere that git.centos.org (such as one of the PGP key servers). The SSL/SSH for git.centos.org would continue to pass, but the signature would not.
The other case already mentioned was the case that the content has an intermediate resting point. That is, I clone from git.centos.org, and then I publish to somebody else. How do they know which content is authentic... mine or git.centos.org? Being able to point to the signed tag shows cryptographically who signed the content and this could be an important differentiator in determining which source is the "real" source.
In theory, someone could publish a faked GPG tag to go with it. But GPG tags are *much* more portable and applicable to arbitrary content. They seem to be fundamental to the way Red Hat has been publishing RPM and SRPM's for years, and the way CentOS does, to allow reasonably safe third party mirrors to carry the software.
Now:
the bottom line is that unless you can get an authoritative manner of initial keyexchange, that you can absolutely trust, nothing else down the line is going to be any more secure than the initial handover. I'm happy to setup a keysign and keyexchange event at every dojo we run, but even that is likely to only reach a small fraction of the entire userbase.
There are too many SSL environments that have *no* reliable key exchange for the upstream site, due to mandataory or mishandled proxies or local caching of the software repository. I've pointed out a few.
Worse, once a git.centos.org repository is cloned locally, upstream SSL is no longer necessarily used. It is certainly possible to clone a repository with all commits *up to* the commit transaction for the final SRPM build and manipulation of '[package].metadata', then inject a local commit after that change, along with arbitrary trojan content.
The link to the upstream SSL repository would no longer necessarily be used. One could do a comparison against the upstream repository at git.centos.org, but that's an extra and unexpected step.
So the only way to get the originating gpg key ( that you'd verify against ) is over ssl on the internet, which also implies that having git.centos.org behind the same leave lof trust puts us no worse off.
Nonsense. It can come from any of dozens if not hundreds of mirror sites worldwide. And it can be verified in a way that SSL cannot, by reviewing the signature chain personally rather than relying on centralized certification authorities that have repeatedly proven themselves incompetent, or that are deliberately suborned as a matter of local policy.
I think you may be dismissing the two scenarios... 1) git.centos.org gets compromised, 2) intermediate resting point. Both of these require the *content* to be signed. You are only providing authentication of the original source which does not address either of these points effectively.
I'm less worried about git.centos.org getting p0wned. I am worried about what you refer to as "intermediate resting points". I'm also concerned that if *I* make a fork of, say, the OpenSSH repository, write patches, and submit them or use them, that I have a reliable and consistent "benchmark" version of the software. If I get p0wned, GPG tags on the buld versions of upstream software would help me review and verify, locally, that the template from upstream is good.
So, I don't think it is correct that the "bottom line" is as you state above. The real "bottom line" is that SSL/SSH only authenticates the source host. It provides *no* guarantee for the source content.
You've captured the substance of my concern.
If you authenticated the content, you wouldn't actually need to authenticate the source host. This is how Bittorrent works in general. It doesn't matter how the bytes get from point A to point B, as long as the final result has the correct *content*. SSL/SSH do not guarantee the correct *content* so it is rather ineffective as a means of authenticating the content. It's saying "trust me... I'm git.centos.org... what could go wrong?"
And there are a stack of environments where the SSL is inaccessible, such as isolated build hosts with no external network access. (I work with some of thiose.)