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!)
