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

Mon Jul 7 10:22:33 UTC 2014
Nico Kadel-Garcia <nkadel at gmail.com>

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.