Fedora 21 Security Update: librsync-1.0.0-1.fc21,csync2-1.34-15.fc21,duplicity-0.6.25-3.fc21,rdiff-backup-1.2.8-14.fc21

Resolved Bugs
1126712 – CVE-2014-8242 librsync: MD4 collision file corruption
1126718 – librsync: rsync: checksum collisions leading to a denial of service [fedora-all]<br
Changes in librsync 1.0.0 (2015-01-23)
======================================
* SECURITY: CVE-2014-8242: librsync previously used a truncated MD4 “strong” check sum to match blocks. However, MD4 is not cryptographically strong. It’s possible that an attacker who can control the contents of one part of a file could use it to control other regions of the file, if it’s transferred using librsync/rdiff. For example this might occur in a database, mailbox, or VM image containing some attacker-controlled data. To mitigate this issue, signatures will by default be computed with a 256-bit BLAKE2 hash. Old versions of librsync will complain about a bad magic number when given these signature files. Backward compatibility can be obtained using the new `rdiff sig –hash=md4` option or through specifying the “signature magic” in the API, but this should not be used when either the old or new file contain untrusted data. Deltas generated from those signatures will also use BLAKE2 during generation, but produce output that can be read by old versions. See https://github.com/librsync/librsync/issues/5. Thanks to Michael Samuel for reporting this and offering an initial patch.
* Various build fixes, thanks Timothy Gu.
* Improved rdiff man page from Debian.
* Improved librsync.spec file for building RPMs.
* Fixed bug #1110812 ‘internal error: job made no progress’; on large files.
* Moved hosting to https://github.com/librsync/librsync/
* Travis-CI.org integration test at https://travis-ci.org/librsync/librsync/
* Remove bundled copy of popt; it must be installed separately.
* You can set `$LIBTOOLIZE` before running `autogen.sh`, for example on OS X Homebrew where it is called `glibtoolize`.

Fedora 21 Security Update: freexl-1.0.0i-1.fc21

Resolved Bugs
1199328 – freexl-1.0.0i is available<br
Four potentially harmful bugs causing crashes and stack corruption
were detected in FreeXL by American Fuzzy Lop and are solved in this release.
Please note: such issues are never realistically expected
to be encountered in real world XLS spreadsheets, anyway
some purposely forged XLS document could be used as a
“poisoned bait” to maliciously open a security breach.
https://groups.google.com/forum/#!topic/spatialite-users/plxKNbYw184

Fedora 21 Security Update: xen-4.4.1-13.fc21

Resolved Bugs
1187153 – CVE-2015-1563 xen: vgic: incorrect rate limiting of guest triggered logging on ARM architectures (XSA-118)<br
enable building pngs from fig files which is working again,
fix oxenstored.service preset preuninstall script,
arm: vgic: incorrect rate limiting of guest triggered logging,
Information leak via internal x86 system device emulation,
Information leak through version information hypercall

Fedora 20 Security Update: freexl-1.0.0i-1.fc20

Resolved Bugs
1199328 – freexl-1.0.0i is available<br
Four potentially harmful bugs causing crashes and stack corruption
were detected in FreeXL by American Fuzzy Lop and are solved in this release.
Please note: such issues are never realistically expected
to be encountered in real world XLS spreadsheets, anyway
some purposely forged XLS document could be used as a
“poisoned bait” to maliciously open a security breach.
https://groups.google.com/forum/#!topic/spatialite-users/plxKNbYw184

Fedora 20 Security Update: librsync-1.0.0-1.fc20,csync2-1.34-15.fc20,duplicity-0.6.25-3.fc20,rdiff-backup-1.2.8-14.fc20

Resolved Bugs
1126718 – librsync: rsync: checksum collisions leading to a denial of service [fedora-all]
1126712 – CVE-2014-8242 librsync: MD4 collision file corruption<br
Changes in librsync 1.0.0 (2015-01-23)
======================================
* SECURITY: CVE-2014-8242: librsync previously used a truncated MD4 “strong” check sum to match blocks. However, MD4 is not cryptographically strong. It’s possible that an attacker who can control the contents of one part of a file could use it to control other regions of the file, if it’s transferred using librsync/rdiff. For example this might occur in a database, mailbox, or VM image containing some attacker-controlled data. To mitigate this issue, signatures will by default be computed with a 256-bit BLAKE2 hash. Old versions of librsync will complain about a bad magic number when given these signature files. Backward compatibility can be obtained using the new `rdiff sig –hash=md4` option or through specifying the “signature magic” in the API, but this should not be used when either the old or new file contain untrusted data. Deltas generated from those signatures will also use BLAKE2 during generation, but produce output that can be read by old versions. See https://github.com/librsync/librsync/issues/5. Thanks to Michael Samuel for reporting this and offering an initial patch.
* Various build fixes, thanks Timothy Gu.
* Improved rdiff man page from Debian.
* Improved librsync.spec file for building RPMs.
* Fixed bug #1110812 ‘internal error: job made no progress’; on large files.
* Moved hosting to https://github.com/librsync/librsync/
* Travis-CI.org integration test at https://travis-ci.org/librsync/librsync/
* Remove bundled copy of popt; it must be installed separately.
* You can set `$LIBTOOLIZE` before running `autogen.sh`, for example on OS X Homebrew where it is called `glibtoolize`.