[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: status of forked zlibs in rsync and zsync

On 09/15/2009 01:29 PM, Simo Sorce wrote:
> On Tue, 2009-09-15 at 12:34 -0700, Toshio Kuratomi wrote:
>> 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.
> Sorry but the packager may have no way to influence upstream.
> And to be honest having a huge patch against rsync and/or zsync to
> extract a library against the will of the rsync and/or zsync upstream is
> contrary to fedora policy as (AFAIK).
You bring up several good thoughts here:

1) We have two conflicting policies.  Stick with upstream and do not
have private copies of system libraries.  Since the latter is in place
for security reasons and  maintainability while the former is only for
maintainability, I'd place more value on it.

2) There's huge patches and then there's huge patches.  If we ported
rsync to somehow use the system zlib and still be compatible with
current rsync and that was not accepted by upstream, that would be one
sort of huge patch.  However, if we break zlib's rsync out into a
subpackage and link rsync and zsync against that then that's a different
kind of patch.  The former is a patch against the code inside of rsync.
 The latter is a patch against the build scripts for rsync.  We often
make patches to build scripts because they aren't working in our

3) The packager works for the distro and the consumers of the distro.
If you can get upstream to acknowledge the burden they place on you and
do the work to make it better then you are to be congratulated.  You've
made the world a better place for everyone.  If you can't, then you need
to do the work yourself for the consumers of your product.

> And yes I am the maintainer of rsync and I am not doing the job, because
> I don't want to have to create or maintain such patcheset until the day
> I am reasonably sure upstream will want such patches.
This is wrong in attitude although it could be right in short-term
practice.  You are the representative of Fedora to upstream.  You need
to be doing work to try and get them to take a patch that satisfies our
requirements.  If they aren't going to budge in one direction, you need
to try a different option.  For instance, in this case we could try: (1)
use system zlib instead of our forked copy and be backwards
incompatible.  (2) Use system zlib and find a way to be backwards
compatible.  (3) Use a forked copy of zlib and make that fork a separate
project.  (4) Use a forked copy of zlib and make that a dynamic library
built out of the rsync package.

If upstream isn't going to budge at all we need to decide whether we
need to change the Guidelines or make changes locally.  As mentioned
making changes to fork out their zlib version has precedent so that's
one way we could make changes locally.  If you maintain the library (or
get other distro maintainers to help maintain it :-)  you can even send
a patch back to rsync upstream to use that broken out library if
configure discovers it at build time.

If you don't want to do any of that work, then you have to come up with
a good reason or plan for making a change to the Guidelines: Maybe your
argument is: "Security is not a goal of Fedora, therefore, we don't need
to worry about including forked copies of system libraries in
applications."  Or "We can mitigate the security risks by making all
maintainers of applications which include system libraries also be
maintainers of the libraries they are including and testing that they
are capable of forward porting their patchsets to new versions of the
system library they are including."  Or "Including system libraries
statically in an application is not a security risk, doesn't lead to
forks, etc.  The time that we had problems with zlib before was just a
fluke and really it was the Martian brain-zappers that caused most of
the problem, not zlib itself."

Just asserting that there is no problem doesn't cut it.  You have to
mitigate the problem or prove that it doesn't exist.


Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]