Message ID | 20221128132338.1572561-1-adolf.belka@ipfire.org |
---|---|
State | Accepted |
Commit | bf81d068067bd4369feb0bcc647effba50a22c0d |
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4NLR4b1chrz3xfS for <patchwork@web04.haj.ipfire.org>; Mon, 28 Nov 2022 13:23:43 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4NLR4Z3KhXz2q9; Mon, 28 Nov 2022 13:23:42 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4NLR4Z2hlrz2xx3; Mon, 28 Nov 2022 13:23:42 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4NLR4Y06gcz2xNV for <development@lists.ipfire.org>; Mon, 28 Nov 2022 13:23:41 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4NLR4X2DyLz2kn; Mon, 28 Nov 2022 13:23:40 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1669641820; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ycHEQPBjKJTr843CQsigsbyrrSmrqrvQSf++DYT826U=; b=fAlIpPYGk6xRBCLnMjqvQMgwHKN6/Sb4HdFVT9uxl1uH14TBf5eR5x5jC5+f6YJRzfHas8 8apmmsszN32ObaDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1669641820; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ycHEQPBjKJTr843CQsigsbyrrSmrqrvQSf++DYT826U=; b=DSv7bH/VWL8/8YOFOy//Tga/OVL/4HBktSGDf3PhTRBiR1MVNtoPnqdOXo1Dnf0AAOvkzv Uw5iT4TDa7H3TRN/JQLXIvkmIMYdleFc3Twu48+w2gVELEV0OR0/fRsQMOFgKjStAL0Sg+ qt5ZE3WuLlE4kFssktTn2jk2MPsPSdSsAkmqE0HapA9rnr7L7zyPaiYU9/GvPIVYtbx5ZO ksFHbYrkOCNg8S9W4bhM4/rY3l3mXKxIUwGw56Vxrn6t8LF6W+l26BzoRBbdHH8AfdWa8T aj6TmAk9wU/PCeQvvNs5USLP58T8dG3oEzU52MXYpZVyn54EeR81b9smtExwVg== From: Adolf Belka <adolf.belka@ipfire.org> To: development@lists.ipfire.org Subject: [PATCH] rsync: Update to version 3.2.7 Date: Mon, 28 Nov 2022 14:23:38 +0100 Message-Id: <20221128132338.1572561-1-adolf.belka@ipfire.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
rsync: Update to version 3.2.7
|
|
Commit Message
Adolf Belka
Nov. 28, 2022, 1:23 p.m. UTC
- Update from version 3.2.6 to 3.2.7
- Update of rootfile not required
- Changelog
# NEWS for rsync 3.2.7 (20 Oct 2022)
### BUG FIXES:
- Fixed the client-side validating of the remote sender's filtering behavior.
- More fixes for the "unrequested file-list name" name, including a copy of
"/" with `--relative` enabled and a copy with a lot of related paths with
`--relative` enabled (often derived from a `--files-from` list).
- When rsync gets an unpack error on an ACL, mention the filename.
- Avoid over-setting sanitize_paths when a daemon is serving "/" (even if
"use chroot" is false).
### ENHANCEMENTS:
- Added negotiated daemon-auth support that allows a stronger checksum digest
to be used to validate a user's login to the daemon. Added SHA512, SHA256,
and SHA1 digests to MD5 & MD4. These new digests are at the highest priority
in the new daemon-auth negotiation list.
- Added support for the SHA1 digest in file checksums. While this tends to be
overkill, it is available if someone really needs it. This overly-long
checksum is at the lowest priority in the normal checksum negotiation list.
See [`--checksum-choice`](rsync.1#opt) (`--cc`) and the `RSYNC_CHECKSUM_LIST`
environment var for how to customize this.
- Improved the xattr hash table to use a 64-bit key without slowing down the
key's computation. This should make extra sure that a hash collision doesn't
happen.
- If the `--version` option is repeated (e.g. `-VV`) then the information is
output in a (still readable) JSON format. Client side only.
- The script `support/json-rsync-version` is available to get the JSON style
version output from any rsync. The script accepts either text on stdin
**or** an arg that specifies an rsync executable to run with a doubled
`--version` option. If the text we get isn't already in JSON format, it is
converted. Newer rsync versions will provide more complete json info than
older rsync versions. Various tweaks are made to keep the flag names
consistent across versions.
- The [`use chroot`](rsyncd.conf.5#) daemon parameter now defaults to "unset"
so that rsync can use chroot when it works and a sanitized copy when chroot
is not supported (e.g., for a non-root daemon). Explicitly setting the
parameter to true or false (on or off) behaves the same way as before.
- The `--fuzzy` option was optimized a bit to try to cut down on the amount of
computations when considering a big pool of files. The simple heuristic from
Kenneth Finnegan resuled in about a 2x speedup.
- If rsync is forced to use protocol 29 or before (perhaps due to talking to an
rsync before 3.0.0), the modify time of a file is limited to 4-bytes. Rsync
now interprets this value as an unsigned integer so that a current year past
2038 can continue to be represented. This does mean that years prior to 1970
cannot be represented in an older protocol, but this trade-off seems like the
right choice given that (1) 2038 is very rapidly approaching, and (2) newer
protocols support a much wider range of old and new dates.
- The rsync client now treats an empty destination arg as an error, just like
it does for an empty source arg. This doesn't affect a `host:` arg (which is
treated the same as `host:.`) since the arg is not completely empty. The use
of [`--old-args`](rsync.1#opt) (including via `RSYNC_OLD_ARGS`) allows the
prior behavior of treating an empty destination arg as a ".".
### PACKAGING RELATED:
- The checksum code now uses openssl's EVP methods, which gets rid of various
deprecation warnings and makes it easy to support more digest methods. On
newer systems, the MD4 digest is marked as legacy in the openssl code, which
makes openssl refuse to support it via EVP. You can choose to ignore this
and allow rsync's MD4 code to be used for older rsync connections (when
talking to an rsync prior to 3.0.0) or you can choose to configure rsync to
tell openssl to enable legacy algorithms (see below).
- A simple openssl config file is supplied that can be installed for rsync to
use. If you install packaging/openssl-rsync.cnf to a public spot (such as
`/etc/ssl/openssl-rsync.cnf`) and then run configure with the option
`--with-openssl-conf=/path/name.cnf`, this will cause rsync to export the
configured path in the OPENSSL_CONF environment variable (when the variable
is not already set). This will enable openssl's MD4 code for rsync to use.
- The packager may wish to include an explicit "use chroot = true" in the top
section of their supplied /etc/rsyncd.conf file if the daemon is being
installed to run as the root user (though rsync should behave the same even
with the value unset, a little extra paranoia doesn't hurt).
- I've noticed that some packagers haven't installed support/nameconvert for
users to use in their chrooted rsync configs. Even if it is not installed
as an executable script (to avoid a python3 dependency) it would be good to
install it with the other rsync-related support scripts.
- It would be good to add support/json-rsync-version to the list of installed
support scripts.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
---
lfs/rsync | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Comments
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org> > On 28 Nov 2022, at 13:23, Adolf Belka <adolf.belka@ipfire.org> wrote: > > - Update from version 3.2.6 to 3.2.7 > - Update of rootfile not required > - Changelog > # NEWS for rsync 3.2.7 (20 Oct 2022) > ### BUG FIXES: > - Fixed the client-side validating of the remote sender's filtering behavior. > - More fixes for the "unrequested file-list name" name, including a copy of > "/" with `--relative` enabled and a copy with a lot of related paths with > `--relative` enabled (often derived from a `--files-from` list). > - When rsync gets an unpack error on an ACL, mention the filename. > - Avoid over-setting sanitize_paths when a daemon is serving "/" (even if > "use chroot" is false). > ### ENHANCEMENTS: > - Added negotiated daemon-auth support that allows a stronger checksum digest > to be used to validate a user's login to the daemon. Added SHA512, SHA256, > and SHA1 digests to MD5 & MD4. These new digests are at the highest priority > in the new daemon-auth negotiation list. > - Added support for the SHA1 digest in file checksums. While this tends to be > overkill, it is available if someone really needs it. This overly-long > checksum is at the lowest priority in the normal checksum negotiation list. > See [`--checksum-choice`](rsync.1#opt) (`--cc`) and the `RSYNC_CHECKSUM_LIST` > environment var for how to customize this. > - Improved the xattr hash table to use a 64-bit key without slowing down the > key's computation. This should make extra sure that a hash collision doesn't > happen. > - If the `--version` option is repeated (e.g. `-VV`) then the information is > output in a (still readable) JSON format. Client side only. > - The script `support/json-rsync-version` is available to get the JSON style > version output from any rsync. The script accepts either text on stdin > **or** an arg that specifies an rsync executable to run with a doubled > `--version` option. If the text we get isn't already in JSON format, it is > converted. Newer rsync versions will provide more complete json info than > older rsync versions. Various tweaks are made to keep the flag names > consistent across versions. > - The [`use chroot`](rsyncd.conf.5#) daemon parameter now defaults to "unset" > so that rsync can use chroot when it works and a sanitized copy when chroot > is not supported (e.g., for a non-root daemon). Explicitly setting the > parameter to true or false (on or off) behaves the same way as before. > - The `--fuzzy` option was optimized a bit to try to cut down on the amount of > computations when considering a big pool of files. The simple heuristic from > Kenneth Finnegan resuled in about a 2x speedup. > - If rsync is forced to use protocol 29 or before (perhaps due to talking to an > rsync before 3.0.0), the modify time of a file is limited to 4-bytes. Rsync > now interprets this value as an unsigned integer so that a current year past > 2038 can continue to be represented. This does mean that years prior to 1970 > cannot be represented in an older protocol, but this trade-off seems like the > right choice given that (1) 2038 is very rapidly approaching, and (2) newer > protocols support a much wider range of old and new dates. > - The rsync client now treats an empty destination arg as an error, just like > it does for an empty source arg. This doesn't affect a `host:` arg (which is > treated the same as `host:.`) since the arg is not completely empty. The use > of [`--old-args`](rsync.1#opt) (including via `RSYNC_OLD_ARGS`) allows the > prior behavior of treating an empty destination arg as a ".". > ### PACKAGING RELATED: > - The checksum code now uses openssl's EVP methods, which gets rid of various > deprecation warnings and makes it easy to support more digest methods. On > newer systems, the MD4 digest is marked as legacy in the openssl code, which > makes openssl refuse to support it via EVP. You can choose to ignore this > and allow rsync's MD4 code to be used for older rsync connections (when > talking to an rsync prior to 3.0.0) or you can choose to configure rsync to > tell openssl to enable legacy algorithms (see below). > - A simple openssl config file is supplied that can be installed for rsync to > use. If you install packaging/openssl-rsync.cnf to a public spot (such as > `/etc/ssl/openssl-rsync.cnf`) and then run configure with the option > `--with-openssl-conf=/path/name.cnf`, this will cause rsync to export the > configured path in the OPENSSL_CONF environment variable (when the variable > is not already set). This will enable openssl's MD4 code for rsync to use. > - The packager may wish to include an explicit "use chroot = true" in the top > section of their supplied /etc/rsyncd.conf file if the daemon is being > installed to run as the root user (though rsync should behave the same even > with the value unset, a little extra paranoia doesn't hurt). > - I've noticed that some packagers haven't installed support/nameconvert for > users to use in their chrooted rsync configs. Even if it is not installed > as an executable script (to avoid a python3 dependency) it would be good to > install it with the other rsync-related support scripts. > - It would be good to add support/json-rsync-version to the list of installed > support scripts. > > Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> > --- > lfs/rsync | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/lfs/rsync b/lfs/rsync > index 07a56f96d..abd5d5053 100644 > --- a/lfs/rsync > +++ b/lfs/rsync > @@ -26,7 +26,7 @@ include Config > > SUMMARY = Versatile tool for fast incremental file transfer > > -VER = 3.2.6 > +VER = 3.2.7 > > THISAPP = rsync-$(VER) > DL_FILE = $(THISAPP).tar.gz > @@ -34,7 +34,7 @@ DL_FROM = $(URL_IPFIRE) > DIR_APP = $(DIR_SRC)/$(THISAPP) > TARGET = $(DIR_INFO)/$(THISAPP) > PROG = rsync > -PAK_VER = 16 > +PAK_VER = 17 > > DEPS = > > @@ -48,7 +48,7 @@ objects = $(DL_FILE) > > $(DL_FILE) = $(DL_FROM)/$(DL_FILE) > > -$(DL_FILE)_BLAKE2 = fa0c4aa9cdffbc9ffd4f81e8c3cdc1fda7080f80c1923084c6d705e6872caaba31c13de4603c9462f312dbbdae76520c27d3f4f40b327f1e66c7127b1d05ea73 > +$(DL_FILE)_BLAKE2 = 1b910b321e8d6b49af9f26bef813509f0da12dedd6857897de136d3617c68d38368ce05de13b9b0ef35a5452dca141ebdcdfb6af8456151d0ca0ad546452b504 > > install : $(TARGET) > > -- > 2.38.1 >
diff --git a/lfs/rsync b/lfs/rsync index 07a56f96d..abd5d5053 100644 --- a/lfs/rsync +++ b/lfs/rsync @@ -26,7 +26,7 @@ include Config SUMMARY = Versatile tool for fast incremental file transfer -VER = 3.2.6 +VER = 3.2.7 THISAPP = rsync-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -34,7 +34,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = rsync -PAK_VER = 16 +PAK_VER = 17 DEPS = @@ -48,7 +48,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_BLAKE2 = fa0c4aa9cdffbc9ffd4f81e8c3cdc1fda7080f80c1923084c6d705e6872caaba31c13de4603c9462f312dbbdae76520c27d3f4f40b327f1e66c7127b1d05ea73 +$(DL_FILE)_BLAKE2 = 1b910b321e8d6b49af9f26bef813509f0da12dedd6857897de136d3617c68d38368ce05de13b9b0ef35a5452dca141ebdcdfb6af8456151d0ca0ad546452b504 install : $(TARGET)