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. 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