[CentOS-devel] CentOS Interoperability SIG

Ljubomir Ljubojevic centos at plnet.rs
Wed Jan 29 19:25:26 UTC 2014


On 01/29/2014 02:26 PM, Johnny Hughes wrote:
> 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.
>

You misunderstood me.

I do get the proposed process, and it is a good one for add-on packages. 
What I focused on is packages from base that need to be 100% binary 
compatible, and only on those. And only in perspective of recreating the 
environment and POSSIBLE (I have not said probable) injection of 
security bugs. The document in question was: 
http://cm.bell-labs.com/who/ken/trust.html

All I argued is there IS POSSIBILITY for distrust and wish to build it 
by "yourself". Because if your job is to be paranoid, then YOU need to 
control the entire process.


-- 
Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant



More information about the CentOS-devel mailing list