On 08/27/2014 09:32 PM, Nico Kadel-Garcia wrote: > 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. I said the "CentOS Team" does not have any special access to Red Hat SRPMS ... We, as well as anyone else who wants to use git.centos.org, get code provided by Red Hat Engineering into git.centos.org. The original import is not done by the CentOS team, it is done by Red Hat. If they want to add a gpg signed tag, they can .. if they don't they won't. Once the code shows up, I see it just like you do. >> 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. These local mirrors would not be CentOS mirrors at all, they are mirrors that some local user would be using for their own purpose, the CentOS team does not provide any assurance that those local mirrors are in any way accurate. > >> 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. > We are not talking about providing official rsync mirrors, we are providing git.centos.org. If other people want to have a local copy, for their OWN USE (not in any way supported or recommended by CentOS) that is what we are talking about trying to provide. >> 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. It has nothing to do with my/our workflow .. These sources are provided by Red Hat as the official Red Hat community sources to git.centos.org, I have to use them just like everyone else, whether I like them or not. What we are talking about also providing is a way for people to make local copies to help them if they want a local copy, nothing more. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140828/6cd0bca8/attachment-0007.sig>