On 8/2/2019 6:13 AM, Otto Kekäläinen wrote:
Hello!
With the adoption of librsync2 the old MD4 hash is no longer supported
and thus a non-backwards compatible change is introduced. All backups
must therefore start from "scratch".
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776246
Please clarify. I find nothing in your citation that supports your
statements.
I find no changes in librsync2 that affect backward compatibility
versus, say, librsync1:
https://librsync.github.io/md_NEWS.html
From what I see, the old MD4 hashes are still supported in librysnc2
(although deprecated for security reasons):
https://librsync.github.io/librsync_8h.html#ab6abafd1db0a3947bb3c076507f4f7c2
Patches have been around for several years allowing rdiff-backup to use
librsync1:
https://github.com/sol1/rdiff-backup/issues/2
https://src.fedoraproject.org/rpms/rdiff-backup/raw/HEAD/f/rdiff-backup-1.2.8-librsync-1.0.0.patch
Per the above patch, rdiff-backup continues to use the old MD4 hashes
with librsync1. But my understanding is that the MD4 hash is only used
to compare files over the network between 2 instances of rdiff-backup
(client and server). The hashes are not incorporated into the .diff
files (delta files in librsync parlance) that are stored in the
rdiff-backup repository. Therefore, even if rdiff-backup was modified
to use the newer Blake2 hashes, rdiff-backup would remain compatible
with older backup repositories. Thus, I think it is incorrect to say
that 'All backups must therefore start from "scratch"'.
I think it probably would be good if rdiff-backup started using Blake2
rather than MD4 hashes by default. But when communicating with older
instances of rdiff-backup which don't use Blake2, rdiff-backup should
probably revert to using MD4 rather than failing.
--Joe
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
