Re: [rdiff-backup-users] Bump major release version for rdiff-backup?

[Joe Steele]

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