Re: Microsoft product vs Microsoft patch

[Valdis.Kletnieks () vt edu]

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: _bin
Description:

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/