Yasha writes;


> Please correct me if I am in error.  RHEL, binary licensed for fee, is built from a source that RH does not seem to release.

You've already got it backwards: Red Hat publishes as much as possible
as open source, preferably even freeware, and has been a champion if
turning closed source into open source and freeware. Look at openjdk
and all the kernel drivers that they publish, they've been *very* good
about this. And no, they don't license *bnaries* for free, they
publish source for free.

>  Rather, RH releases, through the RH subsidiary CentOS and a GIT mechanism, a source for all rebuilds, supposedly including CentOS.

Before RHEL, all the way up to Red HAt 9, they published SRPM and
binaries for everything they could. Java was the most notorious
exception, but there were various commercial tools they licensed for
commercial subscribers they could not publish source for. Starting
with RHEL up until RHEL 7, they published the SRPM's themselves
worldwide. Scientific Linux, CentOS, the old whitebox Linux, and some
hobby projects all reviewed the SRPM's, rebuilt binaries with their
own GPG signatures, carefully stripped out trademark and copyrighted
material they could not themselves republish, and provided invaluable
tools in the best free software and open source tradidions.

> Thus, SL and CentOS are built from the same source, but the actual RHEL source may or not may in fact (claims to the contrary notwithstanding) be the same, as no one outside of RH or a RH licensee actually sees the source for RHEL.

Red Hat claims the source at git.centos.org for RHEL 7, labeled as
imports in the logs, is what they used. CentOS and SL are doing what
they used to do: rebuilding from what Red Hat says is their source.
It's conceivable that RHEL lied,and continues to lie about what is in
the new git repositories and in their old SRPM's, and that they are
not in fact the source used for the published binaries they provide to
commercial clients. But they've been very good about their software
publication, and I have professional confidence in them.

I do have concerns about the new git.centos.org based publication.
It's unnecessary, and there are no GPG tags on this source tree. So
there is a real risk of manipulation oafter the repo is set up,
especially if you use a third party clone of git.centos.org. I've
raised this any number of times and gotten no satisfactory  response
to my concern. But I'm not so worried about CentOS project owners
manipulating their own repos, some of them are Red Hat employees and
the consequences would be devastating if they got caught manipulating
things. I'm worried about third party repositories, clones or rsync
mirrors or git access funneled through proxies that can effectively be
man in the middle attacked.

Saying "but it has an SSL key, don'e you think we know how to run a
secure site", as some of the current maintainers have done misses the
point. SSL k eys can be forged. (There are too many stolen signature
authorities to make a "valid" key with!). And mirrors or clones cannot
be verified without enormous effort without GPG tags.

> .  If RHEL also is built through a GIT mechanism, I am assuming that the Internet path to the RHEL GIT is not the same as that to the "public" rebuildable CentOS GIT.

It's apparently not an "internet path". It's a Red Hat internal
network path, since it's now the official publication venue for RHEL 7
source code.

> In the event that Fermilab or CERN has licensed the actual RHEL 7 source as a RHEL licensee, would personnel at either non-RH entity be allowed to comment if in fact there were non-trivial differences between the actual RHEL 7 source and the "rebuildable" CentOS 7 source?  Trivial differences would be the presence of RH logos and splash screens, each of which is replaced by whatever the rebuilder is using (SL for the SL rebuild) -- but all of the internal intellectual property references in the source code still (presumably) mentions RH in both the actual RHEL 7 source and the CentOS 7 rebuildable source.
>
> Yasha Karant

The concern has been raised before, and people are checking precisely
that. And the new import "we call it a tag by mentioning it in the
log, but it's not really a tag" technique that CentOS is using has
been verified by various folks in various projects. I've done a few
myself (including Samba!)