On 06/22/2014 02:41 PM, Nico Kadel-Garcia wrote:
> On Sun, Jun 22, 2014 at 4:42 PM, Mark Rousell <[log in to unmask]> wrote:
>> I've been following the discussions on this list about the changes in RHEL's source availability and I'd like to confirm my understanding of the current situation.
>>
>> Someone on another mail list made this comment:
>>
>>          RedHat have said that they'll not be releasing source RPMs any more, so
>>          the response by the Scientific Linux people has more or less been
>>          "Either use CentOS or our very own re-packaged CentOS thingie".
>>
>> This is incorrect (in terms of both statements that it makes), isn't it.
>>
>>
>> Here is my current understanding. Please feel free to correct or confirm:-
>>
>> 1) RH now makes SRPMs available only to customers (but SRPMs are nevertheless still available on those terms).
>>
>> 2) The RHEL source is publicly also available on git.centos.org.
>>
>> 3) But it is not *absolutely* crystal clear what on git.centos.org is pure unadulterated RHEL source and what is CentOS source.
>>
>> 4) The SL project is writing tools to automatically extract RHEL source from git.centos.org.
>>
>> 5) SL7 will therefore be based on RHEL7 and definitely not on CentOS.
>>
>> 6) Anything I've forgotten?
>>
>>
>> Thanks to anyone who can help with this.
> Step 4 is not reliable, and may cause profound problems, without step
> 3. Without verifiable GPG signed tags, in fact, a malicious proxy
> could use any of the stolen SSL root certificates, sign a forged
> 'git.centos.org' SSL signature, and interprose their trojan software
> burdened git repository.
>
> Moving away from the public SRPM's is burdensome to rebuilders other
> than CentOS, at least without those steps.
Please correct me if the statements below are in error.

The SL distribution (re)packaging team are employed by Fermilab/CERN.  
These entities subscribe to RHEL, and thus can get the SRPMs that are 
genuine RHEL, not just CentOS.

Can the SL repackagers, after building the source from the CentOS git 
repositories, compare this source with the actual RHEL source, and thus 
identify the sort of compromises and contamination that, say, a 
compromised SSL certificate and signature could permit? Although most SL 
sites do not have a RHEL license, and thus cannot be allowed to "see" 
the SRPMs, can a site which does do the comparison?  If so, can a 
failure of the comparison be disclosed without revealing the actual 
contents of the RHEL SRPMs?  Or, can such a failure (and thus probable 
compromise or professional incompetence on the part of the CentOS 
"distributors") only be revealed to RH, forcing the community to be in 
limbo (using a source and binaries known to have failed comparison to 
RHEL)?   Obviously, trivial differences, e.g., absence of RH logos and 
the like, are not a matter of concern.

Yasha Karant