Those are registered as CVE-2016-9843, CVE-2016-9842, CVE-2016-9841,
CVE-2016-9840, but judging from the code, it's not even clear how to build
an exploit from this (mostly underspecified C behavior, plus it's deep
within zlib's streams).
So, don't get too alarmed about this.
Okay sthen@, naddy@
Note that there is no xattr support on OpenBSD so we're not affected by
all the bugs upstreams fixed
discussed with jca, naddy and espie
ok espie (maintainer)
fix for a transfer from a sender that you don't fully trust.
Originally gonzalo@ submitted a broken update to espie@ who passed
it around and then everybody forgot.
Add support for a new-compression idiom that does not compress all the
matching data in a transfer. This can help rsync to use less cpu when a
transfer has a lot of matching data,
Switch to bundled zlib in order to support both old and new compression.
ok sthen@, espie@
changes, and now uses the system zlib.
https://rsync.samba.org/ftp/rsync/src/rsync-3.1.0-NEWS
Clean up some cruft:
* Dropped the -T from --with-rsh. No tty allocation is the default
for ssh, and if somebody sets RequestTTY in .ssh/config, they should
get what they want.
* Removed pointless SECURITY file.
* Replaced the outdated DESCR text with the description from the man page.
ok espie@
Tweak man pages accordingly.
While here:
simplify @extra marker in PLIST
set GPL version
"looks good" to naddy@
with inputs from and ok schwarze@, ok sthen@
There is a path-sanitizing bug that affects daemon mode in all
recent rsync versions (including 2.6.2) but only if chroot is
disabled. It does NOT affect the normal send/receive filenames
that specify what files should be transferred. It does affect
certain option paths that cause auxiliary files to be read or
written.
http://rsync.samba.org/#security_aug04
SECURITY:
Paths sent to an rsync daemon are more thoroughly sanitized when
chroot is not used. If you're running a non-read-only rsync daemon
with chroot disabled, *please upgrade*, especially if the user privs
you run rsync under is anything above "nobody".
