[CentOS-devel] Back on CentOS-devel to get some git.centos.org improvements

Sun Jul 6 21:54:24 UTC 2014
Nico Kadel-Garcia <nkadel at gmail.com>

On Sun, Jul 6, 2014 at 5:23 PM, Mark Mielke <mark.mielke at 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.)