On Mon, Jul 7, 2014 at 4:59 AM, Karanbir Singh <mail-lists at karan.org> wrote: > On 07/07/2014 03:06 AM, Nico Kadel-Garcia wrote: >>> Read that again: CentOS is not special. They are *consumers* of the >>> sources, not the producers. >> >> They are special. Various members of the CentOS team are now Red Hat >> employees (http://seven.centos.org/2014/06/congratulations-to-red-hat-for-rhel7/) >> >> Do keep up with curent events. > > That doesnt change what Chris said though. > > We trust that source ( and the origin of that source ), which is why we > build and deliver the distro derived from there ( we do patch a few ), > and if someone needs the gpg signed content to setup cascading trust, do > so from the srpms. > > - KB And you folks at git.centos.org and the CentOS core developer group, I have some confidence in. Certainly Red Hat does, they hired a bunch of you. The result is that I assume you have good access from which you are building your imported git.centos.org sources, either direct git exports from Red Hat's internal git repos or a full feed Red Hat subscription to work the SRPM's from. I'm actually quite curious which you use, I don't see anything at git.centos.org to indicate. Either way, though, I have some confidence in *your* access to upstream resources. I'm qhappy to see git.centos.org. I really appreciate the visibility. But as soon as I start pulling its contents from some of the weird intervening proxy setups I've seen in the wild, I'm not talking directly to your repo anymore. Moreover, once I start doing any work in my own clone, or if I share that clone with other developers, I lose verifiability of who wrote what parts. That's what the git tags would provide, and potentially much more consistently than analyzing the 'git log' content for imports. In fact, that practice of encoding SRPM names in the git log 'import' lines is basically re-inventing tags, but without the GPG signature. Thinking about it, those 'import' labeled commits might be just the right ones to use to create actual tags. Name the tag after what is in the git log 'import' notated SRPM version, sign those, and you've got a much better verifiable source for remote clones to use. And much more legible and easier for developer to review, who can do a ''git checkout kernel-3.1.0-0.0.1' and be working in a sacrosanct local tag checkout, or do 'git diff kernel-3.1.0-0.0.1 kernel-3.1.0-0.0.2' to compare the tags much more easily than they can by deriving and manipulating commit tags read from the logs. Also, one of the more useful tricks I've been doing with git is to do a "rebase", which is much easier with tags than by deriving the 'git log' import information. It's certainly more *legible*. But consistently labeled 'git tag' use let's me refer to those tags directly, and when I check one out locally it's in "read only" mode It's extra work, I admit. I don't know if you're signing the RPM's and SRPM's manually, or with an automated build system. But if we're going to develop, and want to be able to rely on the code with concerns about the provenance, well, git.centos.org is a separate channel with different security needs. It's not technologically difficult to bring it up to a similar standard as the RPM and SRPM files.