There's been a lot of discussion on this, which is surprising given that this is the wrong place for it. Maybe next we can discuss how to improve AutoYAST or IIS. Some people seem to have forgotten that CentOS, despite the recent change in employment status of several of its core members, is the *downstream* rebuilder. They get their sources via git.centos.org from a prominent North American Linux reseller, just like the rest of us. Read that again: CentOS is not special. They are *consumers* of the sources, not the producers. No, really. So if CentOS pushed a zillion signed tags to git.centos.org, that'd only mean that CentOS trusts those sources. If, as Nico suggested, git.centos.org was pwned, then CentOS just certified bogus sources. IOW, a signed tag from Jim, or Johnny, or KB, or any of the other CentOS devs means precisely fuck-all, and not a bit more, because they get the sources through the EXACT SAME distribution channel that the rest of us do. CentOS is not special, they just look that way. Really, if this is the assurance you want, just add your own signed tags to your local repo -- it's just as meaningful. What do we want? FUCK-ALL! When do we want it? NOW! If you want *actual* cryptographic assurance that the sources you're grabbing from git.centos.org are the same sources pushed there by the *upstream* vendor, maybe, just maybe, you should ask that upstream vendor. Otherwise it's just garbage in, garbage out, and they're only certifying that the sources you download match the sources someone else downloaded. I guess misery loves company, but that sure doesn't seem helpful. I'll warn you, though, since the specter of the all-powerful NSA was raised: they already have Red Hat's signing keys. And yours, too. On Sun, Jul 6, 2014 at 5:54 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote: > 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.) > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -- Chris St. Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140706/50211f6b/attachment-0007.html>