On Mon, Jan 26, 2015 at 09:12:19AM +0100, Thijs Kinkhorst wrote: > > See https://github.com/librsync/librsync/issues/5 . librsync uses MD4 > > as part of syncing; given the low strength and size of MD4, and the > > relative ease of computing collisions/preimages, that makes librsync > > unsafe to use on untrusted data, such as when running a duplicity > > backup. > > > > The upstream fix involves changing the signature format to use a strong > > hash. The new version of librsync supports reading the old signature > > format, but always writes the new one. So, fixing this has some of the > > same implications as Berkeley DB upgrades. In particular, any > > applications using librsync and its data format across multiple systems > > will require upgrading any readers along with writers. I'd suggest > > coordinating this with the reverse dependencies of librsync1. > > Although a genuine issue, the fix is indeed too invasive to deploy in a > stable release and requires something of a transition. We should therefore > start this in sid for stretch. librsync 1.0.0 is available in experimental for some time (and is source-incompatible with 0.9.x), and as the freeze is over we can start working on this.
-- WBR, wRAR
signature.asc
Description: Digital signature
