On Wed, Aug 27, 2014 at 7:28 AM, Johnny Hughes <johnny at centos.org> wrote: >> Not when the metadata is poisoned by a trojaned merge. Git logs can be >> edited. Without the GPG sums, it's like a web mirror that has a pack >> of RPM's with a pack of checksums alongside them. The owner of the >> mirror, or a cracker attacking the host, can corrupt *both*, and >> without the GPG tag, it's hard to get provenance. >> >> And *that* is one of the points where having a GPG signed tag, >> especially one tied to the contents of the SRPM builds, becomes a a >> useful tool for verifying provenance of the tree. You can't rely on a >> binary comparison, there's likely to be frequent skew between the >> rsync mirrors and the main repo as a matter of course. > > Red Hat does not want to provide us a gpg signed tag, so therefore we > will not be getting one. No reason to keep bringing it up. Its not > happening ant time soon. I'm confused by this. What does Red Hat, at least the core business, have to do with this? You have a GPG key you use for making RPM's and SRPM's, why shouldn't or couldn't you use the same key to create git tags? This would be for tags for *your* work, and possibly for when you import Red Hat source. If you have to get your GPG keys from Red Hat, well, that belies the claims I've seen here that git.centos.org has no special relationship with Red Hat, that your git repo is "not special" and you have no special source code access, doesn't it? I'm sorry, but you can't have it both ways. I'm not suggesting you'd need a special Red Hat GPG tag for your imports, but rather have a tag that *you* at CentOS can apply to your repos and relevant tags. > We are not providing mirrors of this all over the place, we are quite > happy with one location and backups/failover. What we are trying to > provide is the ability for people who want a local mirror of this to be > able to get it another way. This is a convenience only, not something > that is required. Right. And they're the ones I'm worried about provenance for. My working assumption is that they will not be as secure as, say, git.centos.org. And it's not trivial to do a side by side comparision, because the sites will have a lot of churn. > I am producing CentOS-7 directly with the git repo as it is RIGHT NOW, > using absolutely nothing but the tools also provided in this repo and > calls to mock. Fermi Scientific Linux is also producing their SL7 from > this same git.centos.org repo, so this it is not a blocker to be able to > mirror this to get the source code or produce binaries. All the tools > are being provided or updated by the community and everything is open. > It all works right now. That's nice, but mostly irrelevant. It's all that's *available*, so they have to use it. The "analyze git logs to determine relevant revisions" has already broken down at least once that I saw reported here. The awkwardness of the "git log" analysis I've already gone over. If anyone else is going to access the contents form an rsync mirror, provenance becomes even more important. > So, if we can create a mechanism to mirror the content as well .. other > than just a script to do it via the json API, then we will. This is not > critical, obviously, as both CentOS and Scientific Linux are tracking > EL7 and doing updates from git.centos.org just fine right now. For CentOS, it's by choice and because you've alrady built it into your workflow. For Scientific Linux, it's because that's all that's available. Do you really think it's by *choice*, or by technical preference? I've seen no evidence of that.