Bug#279551: ITP: zsync -- A client-side implementation of the rsync algorithm

[Colin Phipps <cph@moria.org.uk>]

On Wed, Nov 03, 2004 at 07:32:02PM +0100, Jeroen van Wolffelaar wrote:
> It also at the moment copies several C files from zlib and rsync, in stead
> of linking to it as library. This poses a security support risk:

It takes one file from rsync, which is nothing to do with rsync itself
(md4 implementation - I will have to look and see if I can take it from
openssl instead). I see the security risk argument - rsync has had a
string of these for this very reason (and it still doesn't use librsync
afaik - which hardly inspires much confidence in it).

> this package would need to get patched on rsync or zlib security
> updates too, something that wouldn't be needed if you dynamically
> linked to it.

I will try pushing my changes to zlib once my requirements from it are
stable. Whether they will take them is another question - zlib does not
seem to offer mid-stream decompression support, let alone the kind of
low-level stream mapping that I am doing, so it would be rather a new
feature for them.

On Wed, Nov 03, 2004 at 07:55:40PM +0100, Jeroen van Wolffelaar wrote:
> It'd be cool if librsync would be enhanced to also be able to work the
> other way around, such that rsync simply gains this capability, which
> would in the end benefit much more people -- in the end, why not enhance
> the rsync protocol to also support this backwards rsync to shift the
> extreme CPU usage to the client?

Because the rsync protocol itself is an issue too - people don't want to
run an rsyncd. zsync works over HTTP. No rsync protocol needed, no new
server needed, run over existing mirror infrastructure. I think I can
make it work and be as efficient as rsync but over a standard networking
protocol.

Maybe an endpoint-reversed librsync would be useful, but I doubt it -
there are good reasons for the checksum transfer to be upstream in
rsync's peer-to-peer use case, it makes better use of the available
bandwidth. zsync is for the client-server scenario, where the main issue
is that nobody wants an rsyncd in the first place.

I do need to look at librsync to see if there is any overlap. I get the
impression that at least some of it is coded to the rsync protocol, so
it is probably at a different level of abstraction to libzsync. But it
needs investigation.

-- 
Colin Phipps <cph@moria.org.uk>