status of forked zlibs in rsync and zsync

[Toshio Kuratomi]

On 09/15/2009 12:14 PM, Adam Jackson wrote:
> On Tue, 2009-09-15 at 11:27 -0700, Toshio Kuratomi wrote:
>> On 09/15/2009 06:55 AM, Adam Jackson wrote:
>>> On Tue, 2009-09-15 at 13:44 +0200, Josephine Tannhäuser wrote:
>>>> Hey,
>>>>
>>>> I googled for it and found Karims blogpost and Simon aka kassamedias
>>>> answer (comment 3)
>>>>
>>>> http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/
>>>
>>> If we _really_ cared about doing this OAOO, we could probably get the
>>> rsync package to drop out its own zlib copy as a shared lib, make that a
>>> subpackage, and link zsync against that.
>>>
>>> But, for 74k of shared library, I just don't care that much.  This
>>> shouldn't block packaging zsync.
>>>
>> The rules against shared libraries aren't because of saving space::
>>
>> https://fedoraproject.org/wiki/No_Bundled_Libraries
> 
> I'm aware, I just don't think they read strongly enough on this case to
> matter.  The copy of zlib is there _because_ it can't change, so the
> arguments for changing things OAOO are really weak.
> 
Uhm.... Why can't it change?  For instance: zlib upstream has buffer
overflow.  We issue a zero day update.  Woo hoo, go us.  After a few
weeks rsync upstream notices that zlib has been updated.  Applies their
patches to their copy of zlib.  We make a zero day update of rsync...
but the vulnerable version has been out there and known for several
weeks.  Now zsync notices that the zlib in rsync has been updated.  They
update their version of zlib.  We release yet another zero day update...
but it's been even longer that the vulnerability has been published at
this point....

> I'm also not aware of any precedent for what to name a library like
> this.  %{_libdir}/libfedora-rsync-zlib.so.0 ? What version number do we
> pick?  Who's responsible for making sure it gets bumped when it should?
> Seems like a lot of policy to type for very little practical gain.
> 
All of these are reasons that people have been trying to get upstream to
manage the forked library instead of forking it here.  However, last
time I checked no one has contacted rsync upstream to see if they're
willing to support the forked library in their packaging.  So we're at a
point where no one is doing the work to make this happen... either
upstream or locally.

> Speaking more generally, the package review process makes it very hard
> to get anything in the door if it doesn't fit the existing rules, and
> the rules do not change quickly.  We would probably deliver more value
> if we were willing to accept packages with merely a _plan_ to fix the
> deviations.  As a bonus, we'd have a list of things to do for people
> looking for ways to contribute.
> 
This would be great if maintainers were willing to fix issues after the
fact.  Look at rsync -- there's no incentive to fix the library issue at
this point because rsync is already in the distribution.  We need to fix
this lack of incentive for other reasons -- but we need to fix it before
we start trying to get more packages into the distro with less initial
quality.

-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/20090915/a1a13ec3/attachment.sig>