status of forked zlibs in rsync and zsync

[Toshio Kuratomi]

On 09/30/2009 02:25 AM, Michael Schroeder wrote:
> On Wed, Sep 30, 2009 at 11:05:58AM +0200, Florian Festi wrote:
>> deltarpm has the same problem as it supports the rsync protocol, too.
> 
> I think deltarpm's zlib patch to support 'gzip --rsyncable' is
> different to the rsync patch. I've sent the patch upstream in 2005,
> but got no response.
> 
> (The original --rsyncable patch was done by Rusty Russell in 2002, btw)
> 
So... that means the custom zlib isn't necessary to the proper operation
of deltarpm, correct?  I haven't looked at where in the code this is
being used yet but I'm guessing this zlib is used when:

1) Reading the existing rpm -- this should work with vanilla zlib as well
2) Compressing the deltarpm -- this should work with vanilla zlib, just
not be as kind to rsync.

If this is all, we need to get rid of this ASAP.  Unlike the rsync
version of libz, deltarpm's is based on a version with known security
vulnerabilities.  One of the three changes which together are supposed
to fix the issues is applied in the deltarpm tree.  One of the security
issues is against a piece of code that is not used.  And one of the
issues is still present in the source.  I'm building new versions
without the included zlib now.  Please stop me if pushing those builds
out is going to break anything.

Note that this is an example of why we disallow bundling of local copies
of libraries in Fedora:

1) Old security issues can remain in the distro long after the library
package has been fixed
2) We have to spend time auditing the source code that upstream gives us
to tell whether they've applied security fixes without making a note of it.
3) In the case where a library has forked and the application depends on
the changes introduced in the fork we have to spend time unravelling
what changes the application applied to which upstream version and from
there, how to port the changes to a new version of the library.
4) While we futz around with all of that, our users continue to be
affected by a known vulerability.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090930/de329e50/attachment.sig>