On Thu, 24 Aug 2006 20:14:03 BST, n3td3v said: > I believe for their operating system and their web browser Microsoft patches > take up half or all the original size of the Microsoft product. So? What's that actually *prove*? > I don't have the resources to carry out this study on my own, and I know > some folks do have those resources to release such information to the > security community. > > We need this information to be published professionally so its suitable for > media outlet consumption. No, you don't. Part of the problem is that the size of the "patch" is *highly* dependent on the details of the packaging system. If you want to go *that* route, you shouldn't hope to *ever* get Linux accepted. Let's take a look at how Redhat/Fedora package kernel "patches": The original Fedora Core 5 kernel for a single-processor 686: -rw-r--r-- 1 263 263 14070190 Mar 14 23:23 kernel-2.6.15-1.2054_FC5.i686.rpm Updates so far: -rw-r--r-- 1 2220 2220 15433301 Jul 15 00:13 kernel-2.6.17-1.2157_FC5.i686.rpm -rw-r--r-- 1 2220 2220 15442084 Aug 10 14:22 kernel-2.6.17-1.2174_FC5.i686.rpm Oh my *GOD*, the patches are twice the size of the original. And it's even worse over on RHEL 4, where they've shipped: kernel-2.6.9-5.EL kernel-2.6.9-5.0.5.EL kernel-2.6.9-11.EL kernel-2.6.9-34.EL kernel-2.6.9-34.0.2.EL kernel-2.6.9-42.EL Plus others I've possibly missed. Size of patches is 5x the size of the original. Why? Because the RPM format includes a replacement of *all* the files in the package (so that it's easily slipstreamed and install the "latest and greatest"). IBM AIX's "installp" format only ships updated files - but this ends up making updates a lot more challenging (it's possible to need as many as *4* or even more separate installp files to install a particular patchlevel of a product). Trying to count the size of the patch also runs astray when you have a patch that changes an API (for instance, adding a parameter to a function call). Most of the time, this ends up meaning that software tools like 'make' will recompile most of the package, even if only 1/5 of the recompiled files *really* need it. And trying to trim down the list by hand to find that 1/5 is *dangerous*, because if you miss one, you *will* have problems. Given the relatively cheap nature of both bandwidth and disk, most software developers end up erring on the side of caution. The metric you *want* to measure is what percentage of patches are themselves defective and require patching.
Attachment:
pgpOazkfITCDh.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/