similar to: [librsync-users] MD4 second-preimage attack

On Thu, 2004-04-08 at 12:36, Martin Pool wrote: > On 5 Apr 2004, Donovan Baarda <abo@minkirri.apana.org.au> wrote: > > > librsync needs a whole file checksum. Without it, it silently fails for > > case 1), 3), and 4). > > Yes, a whole-file checksum should be used with it. Presumably > something stronger than md4 like SHA-1. md4 is probably good enough for most

On Tue, Jan 28, 2003 at 11:22:14PM -0800, Craig Barratt wrote: > And I have several things I would like to work on and submit: > > - Fix the MD4 block and file checksums to comply with the rfc > (currently MD4 is wrong for blocks of size 64*n, or files > longer than 512MB). > > - Adaptive first pass checksum lengths: use 3 or more bytes of the MD4 > block

G'day, I've been working on a Python interface to librsync and have noticed that it uses md4sum code borrowed from Andrew Tridgell and Martin Pool that comes via rsync and was originally written for samba. Is there anything special about this code compared to the RSA md4sum code that can be found with libmd <"http://www.penguin.cz/~mhi/libmd/">? Python uses the RSA

I am the author of BackupPC (http://backuppc.sourceforge.net) and I am working on adding rsync support to BackupPC. I am implementing the server-side in perl, and the client will run vanilla rsync. (BTW, is there the protocol documented? I've answered all my questions by looking at the source, but it would be great to check against any docs.) I started with librsync 0.9.3 and the

This message is for rsync developers who know the code very well. This is first time I am using rsync. In short trying to solve an problem by using existing rsync code. rsync does treewalk and it also does checksum on "logical file block", whose size can be choosen at will. I want to use this exisiting framework to write a utility to maintain a checksum tree of an dataset. Q. What do

I'm not sure if this is the appropriate forum for questions regarding librsync, but couldn't find any others. I'm trying to get librsync working properly on Solaris 2.7 and 2.8 Sparc servers. The problem is that while librsync appears to compile cleanly, "make check" fails the sources.test. Does anyone have any insight as to why this might be? Might I need a specific

Hello everybody, About librsync, does anyone know how to patch the delta without creating a new file ? I used the librsync and it always generates a new file, which is embarrassing if the file is over 1Gb. I tried to store the new file in RAM, but it saturates the machine. Is there a possibility to write in the current file to be synchronized, although this file is currently being

All, Does anyone know anything about librsync, and where it is currently maintained = on the web? It apparently is/was a samba project, but I'm not sure how it relates. The authors are listed as: Martin Pool <mbp@samba.org> Andrew Tridgell <tridge@samba.org> but I suspect someone else did the 0.9.5.1 update, because only 0.9.5 is = available on the rproxy site

Currently rsync has a bit of a problem with very large files. Dynamic block sizes were introduced to try handle that automatically if the user didn't specify a block size. Unfortunately that isn't enough and the block size would need to grow faster than the file. Besides, overly large block sizes mean large amounts of data need to be copied even for small changes. The maths indicate

Hi. It seems that librsync got left by the roadside ... is there anything similar for rsync 3.x.x? Or, is there any easy way to use the library routines in the rsync 3.x.x source independantly? The only other open source software I've found that looks similar is xdelta, and it's still beta for v3.x Thanks, Sam -------------- next part -------------- An HTML attachment was scrubbed...

Hi, while implementing the rsync protocol in one of our projects I found that the current CVS version still has a MD4 bug. I'm using the FreeBSD libmd implementation and I still had checksum mismatches with protocol version 27 for files whose size was a multiple of 64 - 4 ( - 4 due to checksum_seed). A patch for todays CVS version is attached. Someone should also review the clean_fname()

I noticed with rsync and compressed files or package files the transfer efficiency drops considerably. Eg. rsync an ISO image of a distribution will give you between 30% and 60% of the original transfer although from Beta1-Beta2 the change could not have been that great. The same thing happens with ZIP files for obvious reasons. My question or feature request if you want to call it is. Is it

Skipped content of type multipart/alternative-------------- next part -------------- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.9/39 - Release Date: 2005-07-04

I found the cvs repository at = http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/librsync/librsync/ The sourceforge project was just setup a couple of days ago. That must have = been why google could not find it yesterday. I believe the samba cvs site for librsync is now deprecated. The 0.9.5.1 version I was looking for looks to me to be a Jun. 27 cvs snapshot = from wherever cvs was at that

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 librsync 0.9.5 is released from rproxy.samba.org. This release contains small but important bug fixes. Changes in 0.9.5: * Bugfix patch from Shirish Hemant Phatak MD5 checksum: df1c35520e4b0bf9d6d7ac813ba86a14 *librsync-0.9.5.tar.gz - -- Martin Pool -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see

Merge installation of ldlinux.c32 from ext2_fat_install_file, btrfs_install_file and xfs_install_file into one function ext_install_ldlinux_c32 Signed-off-by: Nicolas Cornu <nicolac76 at yahoo.fr> --- extlinux/main.c | 106 +++++++++++++++++++++----------------------------------- 1 file changed, 40 insertions(+), 66 deletions(-) diff --git a/extlinux/main.c b/extlinux/main.c index

I'm interested in these very questions (librsync-rsync relationship, remaining limitations of rsync, active prospects for ground-up rewrites), Google searches for rsync info have proved a little too vague due to the programs ubiquity. Much has certainly changed since this was written, could some people with knowledge in these areas could update martin's response for the state of rsync,

On Tue, Sep 24, 2013 at 10:21 PM, Aris Adamantiadis <aris at 0xbadc0de.be> wrote: [snip] > I've worked this week on an alternative key exchange mechanism, in > reaction to the whole NSA leaks and claims over cryptographic backdoors > and/or cracking advances. The key exchange is in my opinion the most > critical defense against passive eavesdropping attacks. > I believe

For anyone who'd like to check out the latest release of my "rzync" [sic] test release, I've just released a new version. For those that might not have time to look at the code but could provide some feedback based on a rough description, I've created the following simple web page: http://www.clari.net/~wayne/new-protocol.html Here's the tar file of the new

On 24 Apr 2002, "Shirish H. Phatak" <shirish@tacitnetworks.com> wrote: > Since there appears to be a dedicated group of users and lots of > activity, maybe we can convince Martin to roll in these patches and make > a new release? I have been really lax in supporting librsync for the last few months, because of a new job and taking over maintenance of rsync