Re: Microsoft product vs Microsoft patch

[Ajay Pal Singh Atwal <ajaypal () bbsbec org>]

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 <Valdis.Kletnieks () vt edu> 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/