Re: [Full-disclosure] Microsoft product vs Microsoft patch
- From: Valdis.Kletnieks@xxxxxx
- Date: Thu, 24 Aug 2006 17:05:43 -0400
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:
pgpffiabQqwei.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/
- Follow-Ups:
- Re: [Full-disclosure] Microsoft product vs Microsoft patch
- From: John Dietz
- Re: [Full-disclosure] Microsoft product vs Microsoft patch
- References:
- Prev by Date: Re: [Full-disclosure] PENNSYLVANIA BUSINESS EXECUTIVE WHO UNLAWFULLY ACCESSED AVON COMPANY'S WEB SITE IS SENTENCED
- Next by Date: [Full-disclosure] ftpd chdir() while root
- Previous by thread: [Full-disclosure] Microsoft product vs Microsoft patch
- Next by thread: Re: [Full-disclosure] Microsoft product vs Microsoft patch
- Index(es):
Relevant Pages
|
|
