On Mon, Jun 23, 2014 at 2:44 AM, Yasha Karant <[log in to unmask]> wrote:
> 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.

That seems very reasonable. I've not yet personally bought a
subscription to RHEL 7 to verify SRPM access. I assume it's still
using 'yum-rhn-setup', which is burdensomely slow compared to
anonymous FTP or HTTP access.  (I's been a busy week!) Also note that
there will always be disparities between release versions of
individual packages and what is at git.centos.org, due to migration
delays. But I think yes, one can theoretically start from there.

> 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

In theory? I think yes. In practice? That's an automation nightmare.
It also makes it awkward for SL to maintain their current "vendor"
repository of SRPM's, with a direct copy of unmodified code from
upstream that is automatically used along with the modified packages
from SL.

> 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

Those are precisely what would make the automation hard right now.
It's very difficult to predict where, and precisely how, the
rebranding changes would occur and in what packages. A simple
consistent branching and tagging convention at git.centos.org, say of
creating signed ''r7_pkg-version-relase.el6" pure imports or branched
and resynced copies of the upstream SRPM contents would be very
helpful and could address the faked SSL certificate man-in-the-middle
attack problem that I've raised.

Such tags could, in theory, be signed with Red Hat GPG keys from the
RHEL installation media and subscription keys, rather than a CentOS
specific tag.