Also as I think Wayne pointed out, using -c isn't very common in the first
place.
transfer. The delay due to I/O wait is going to be orders of magnitude higher
than any reasonable hash computation.
In a parallel life, I also mirrored some websites generated from database
backends. For
Besides all this, what is the performance impact of -c? If it's moved
from MD5 to X - will that impact performance?
I've never used -c as I trust size+dates - probably like 99.9% of
rsync users out there. I always ignored -c as I *assumed* it would
come at an appreciable performance hit...
Jason Haar wrote:
Besides all this, what is the performance impact of -c? If it's moved
from MD5 to X - will that impact performance?
The major impact of using checksums is that both the client and the server
now need to read out every file inspected by the rsync session, where before
they
On Mon, 2010-09-27 at 22:33 -0400, Benjamin R. Haskell wrote:
But the flip side is that rsync is not a security tool. MD5 is fine for
rsync for the same reason SHA-1 (which, as with all hashes, will
eventually be broken) is fine for git:
This gets a little off topic, but I /do/ want git to
On Tue, 28 Sep 2010, Matt McCutchen wrote:
On Mon, 2010-09-27 at 22:33 -0400, Benjamin R. Haskell wrote:
But the flip side is that rsync is not a security tool. MD5 is fine
for rsync for the same reason SHA-1 (which, as with all hashes, will
eventually be broken) is fine for git:
This gets
Yes, right now rsync -c is not good if an attacker has had the
opportunity to plant files on the destination and you want to make sure
the files get updated properly, but that's an uncommon use case
Or whitehat people backing up cracked boxes.
Or anyhat people backing up data generated from
On Mon 27 Sep 2010, grarpamp wrote:
Yes, right now rsync -c is not good if an attacker has had the
opportunity to plant files on the destination and you want to make sure
the files get updated properly, but that's an uncommon use case
Or whitehat people backing up cracked boxes.
If I
If
Ad nauseum... to each shall entertain their own use case scenarios.
The overall point is that MD5 is not suitable for data integrity
beyond it's known [and unknown] weaknesses. I've no faith
in an algorithm with such freely generatable collisions to not
have other collisions/rot with any of
On Mon, 27 Sep 2010, grarpamp wrote:
If
Ad nauseum... to each shall entertain their own use case scenarios.
The overall point is that MD5 is not suitable for data integrity
beyond it's known [and unknown] weaknesses.
But the flip side is that rsync is not a security tool. MD5 is fine for
On Fri, 2010-09-24 at 00:31 -0400, grarpamp wrote:
[rsync -c fails to copy a file with an MD5 collision]
Yes, right now rsync -c is not good if an attacker has had the
opportunity to plant files on the destination and you want to make sure
the files get updated properly, but that's an uncommon
Hi. Wanted to add something. There was recent talk
about the use of 'checksums' by rsync to determine
how or what parts of a file to copy. Something like that.
Anyways, it just so happens that I have a number of
files here that rsync completely fails to update...
l -isT */* ; md5 -r */* ; sha1
11 matches
Mail list logo
