[CentOS-devel] CentOS Interoperability SIG

[Johnny Hughes]

On 01/29/2014 07:17 AM, Johnny Hughes wrote:
> On 01/29/2014 05:16 AM, Ljubomir Ljubojevic wrote:
>> On 01/29/2014 06:10 AM, Johnny Hughes wrote:
>>> If CentOS exists as a rebuild of the EL codebase and if the rebuilt code
>>> works and is tested by the community ... AND if the same source code can
>>> be used as the basis for the addon variant or repos seamlessly (as is
>>> our goal), then why does someone else need to rebuild the rebuilt code
>>> again under another name?
>> The reason does not have to be to build public distro, or maybe public 
>> but for other purposes. One of the issues every user of CentOS is facing 
>> is security.
>>
>> Reality is that CentOS rebuilds packages to be 100% binary compatible. 
>> That means rebuilding against specific versions of packages for 
>> dependencies. Essentially, you packages will have same security bug RHEL 
>> has, if that bug was created with manipulating environment. I read 
>> recently an article which explains how compiling first with modified 
>> compiler then with "proper"/vanila one can introduce changes in the way 
>> same code of the package will be binary different.
>>
>> So first thing that comes to my mind is: If several persons inside Red 
>> Hat decide which environment will be created to build a package, is it 
>> possible those persons to be working with NSA to implant hardly 
>> detectable security holes? Even Read Hat CEO does not have to be aware 
>> of that. And if process is non-transparent and needs tweaking, then one 
>> can assume foul play is possible.
>>
>> As a normal CentOS user, I do not really care much if my system has such 
>> sophisticated hole, but any foreign govt (not-USA) would have serious 
>> concerns to use something USA could have tampered with.
>>
>> For example, Russian govt uses (as far as I remember) REL (Rosa 
>> Enterprise Linux). They are part of Russian govt FOSS Project, for use 
>> by all govt branches, just like RHEL is used by USA govt. What about 
>> other govts that distrust both USA and Russians?
>>
>> And with recent claims that NSA is also running industrial espionage in 
>> favor of USA companies, Big international companies could be reluctant 
>> to use either RHEL or CentOS, or any other 100% binary clone.
>>
>> Argument about USA govt using same packages does not have to be true. 
>> Since Red Hat has closed update/package network with accounts, how hard 
>> would it be to hook USA govt systems to slightly different channel with 
>> few key packages without bugs that exist for all other users of Red Hat? 
>> maybe just a active symlink creation pointing to secret packages.
>>
>> That is why people might want to totally control building process 
>> without spending large amounts of time. Even if only to compare packages 
>> built against different environment.
>>
> Well, it is very easy to see which SRPMs are modified and which ones are
> not (they will have a .centos in the name). 
>
> All the SRPMs are provided. 
>
> All the git trees (with logs) are provided. 
>
> All the binaries are provided.
>
> All the mock configs will be provided.   
>
> All the build logs will be provided.
>
> People will be able, if they choose, to check out any portion of the
> code and modify it on their own.  Things with mods that are needed for
> SIGs can be pushed back into that SIGs tree and be part of the project.
>
> CentOS will not be publishing RHEL packages directly, we will be
> publishing (like we do now) the things that come out of the build system
> ... which are tied to the build logs, root logs, and source code that
> will be published.
>
> Everything will be available for public community review ... in fact, I
> would personally be suspicious of anyone who wanted to take the code and
> rebuild it OUTSIDE this openness, since all the source code, build logs,
> git tree history, etc, will not be available for that rebuild (or if it
> is available, then it is completely duplicated effort).  Instead, if
> those people concentrate on what it is that they want to be different
> from the BASE, then anyone that wants to use what they produce, THAT IS
> DIFFERENT, can choose to get it.  All of the community wins by getting
> more things that work with the EL code base ... rather than silos (or
> stovepipes) of things that are the same.

Let me take this just a bit further and give an example.  Take a look at
the "Cloud-init for CentOS" thread on this list recently.  In that
thread, several cloud providers for CentOS worked together with the
maintainer of the common cloud-init package (in EPEL) and collaborated
(just on this list and the final SIGs are not even complete yet) to get
a package that works for several different groups available in a places
that are not even part of CentOS. 

How much easier will this process be once we have all the collaboration
facilities in place?

Where else but here would all of those groups be working together to get
a common package that works for all of the groups combined?

This is an example of how we can all win by getting groups out of
stovepipes and silos and into community focused SIGs.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140129/1e14be09/attachment.sig>