Ahhh well maybe we are forgetting the actual **for_real_men** technique for patching vulnerabilities and problems that can only be applied to GNU/ Linux like systems.
The diff files (aka patch files), applied directly to the source code, can you match their efficiency in terms of bandwidth. Sincerely Ajay Pal Singh Atwal ----- Valdis Kletnieks <[EMAIL PROTECTED]> wrote: > 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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/