At Sat, 7 Mar 2009 10:45:19 -0500 (EST) CentOS mailing list <centos at centos.org> wrote: > > On Sat, 7 Mar 2009, Robert Heller wrote: > > > At Fri, 06 Mar 2009 23:31:08 +0100 CentOS mailing list <centos at centos.org> wrote: > > >>> I am also not sure if I need to update any of the files the installer > >>> uses to install the system -- is it enough to just drop the alternitive > >>> mkinitrd rpm? Do I need to rebuild any of the other files on the CD? > > > This seems overly complex for my needs. I don't want (or need) to > > rebuild all 6 of the install CDs. I just want to *replace* one RPM on > > the first CD. > > This is the problem with people thinking a respin is just > shuttling files in and out, or adding a driver to a mkinitrd. > > In a post process, you can easily enough 'update' the one RPM > in question with a bit of care in choosing the EVR > information. Anaconda has provided for this in every CentOS > release, and it usually suffices (adding install time drivers > are the major exception). One can drop in anything that may > be scripted -- the environment can be made Turing complete. The problem is that the mkinitrd rpm that is shipped with CentOS 5.2 *go into an infinite loop* if one is installing a kernel on a system with software raid disks. This means that the base install process *hangs*. I suspect that killing the looping mkinitrd process kills (crashes) the install. This means it is impossible to do a base install this way. *This is a known problem* (check the bug database for both RHEL5 and CentOS5 for details). The only other option is to patch the mkinitrd script *while* the install is in progress. I ended up doing this when I originally installed CentOS 5.2, but mis-typed the patch command and ended up with a zero length file in /sbin/mkinitrd -- this did not cause the installer to crash, it just failed to make the initrd file -- not really a problem -- I just booted with a rescue disk and manually re-made the initrd (and it was only a secondard O/S on my system and I had told the installer to not install any boot loader). > > > But then, _who_ is on the hook for maintaining and supporting > such a respin? No intention for providing a yum archive for > updates is stated; no attention is paid to ensure that > 'authentic' SIGNED rpms would be retrieved. Who gets splashed > with mud when things go wrong? > > > Assume there turns out to be a security hole in that package > and it needs to be updated, or even worse worse if the > re-spinner adds a package to drop in a "no key required" > 'just a couple of files add-on' updates yum archive. > > For the sake of analysis assume that the archive added then > gets compromised. Or the re-spinner loses interest, and lets > the domain lapse, and it gets picked up by a 'blackhat'. Or a > DNS poisoning attack subverts resolution of the domain -- no > signed package protection can raise the alarm. It was > bypassed. > > As I say, the customary bypass I have seen by minimal interest > 'just change a couple of things' packagers and archives, is to > wholly disable key checking for the archive they add. People > regularly offer content from their personal archives. [I > invite a self-audit, and would welcome a report of the last > ten mentioned, to see if they are still viable (churning out > updates), offering ONLY signed content with a well published > signing key fingerprint, and issuing a yum.repo.d file > requiring the packages used to be signed.] > > So continuing the thought experiment, when so altered to > trust an additional archive, the remote machines doing update > through cron, or yum-updatesd will trust ANYTHING, including > malicious content, placed in that compromised archive. > > Game over. > > Here is the fallout: The poor end user 'knows' it was CentOS, > because she was told by the respinner that it is 'CentOS with > just one package replaced'. Who gets the black eye here? > Who bears the support load of sorting out what happened when > the poor hurt user shows up in what she thinks is the correct > support venue, barely able to describe her VOIP turnkey box's > operation? > > The answer is, of course, the main mother-ship CentOS project > folks. > > And it is not right that people do this to us, but it is also > hard to stop. Probably the only real solution is to enforce > the CentOS trademark on the art and brand packages, and > prohibit respins containing such (just as the upstream does). > > Sad, but true. > > There is a reason the core CentOS group are skittish about > respins. We'll have to discuss this seriously. > > -- Russ herrold > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller at deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/