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