On 1/19/26 11:35 AM, G.W. Haywood wrote:
Hi there,
As mentioned in another thread, I think the release of the
next
version of rsync-bpc - version 3.4.1.0rc1 - is approaching.
As its version number implies, this version is based on
the latest
upstream rsync, version 3.4.1. That version contains a
number of
improvements plus a few fixes for vulnerabilites.
Vulnerabilities
have been found in supporting packages such as zlib and
popt. For
whatever reasons, many packages (not just rsync and
BackupPC) bundled
the code for these libraries in their own source
distributions. The
problem with doing that, of course, is that the bundled
versions tend
to get out of date which is what happened for rsync,
BackupPC-XS and
rsync-bpc although the resulting issues were fortunately
not serious.
It could easily have been otherwise.
As for BackupPC-XS, the new version of rsync-bpc does away
with the
bundled zlib and popt code, instead relying on the system
to provide
these libraries. If the distribution's security teams and
your update
practice are up to snuff, then these paths to
vulnerability should be
closed off for good.
This has been quite a journey and I'm asking for
volunteers, to begin
with, to sanity-check what I've done.
The changes to the rsync-bpc code have been very extensive
(think in
terms of a context diff with a line count well into five
digits) so I
really do want to get people to put this thing under the
microscope.
It will help enormously if you're a proficient 'C' coder
but it isn't
an absolute requirement; just building and testing by
anyone will be
more than welcome. Running here, it's just done its first
incremental
backup after four fulls for just one share on just one
machine. I'll
be adding to that population in the coming days. So far I
only built
on one architecture (armhf). Anything could happen on a
64-bit box,
the data structures in rsync are truly scary.
There are still a couple of outstanding issues which I
want to look
into, and I'll be glad of any comments from users:
1. While testing on a box with usually ~3G spare memory, I
noticed a
tendency for one of the rsync-bpc processes to use it all
up and then
crash. After I'd removed most of my debugging (gigabyte+
log files)
this seemed to go away, but I'm reminded of Github issue
#547 and I
think it needs a bit more investigation. Also in the
coming days I
plan to do that. I know where to look and what to log, I
just don't
yet know if having a bunch of 8 MByte file buffers in RAM
is an issue.
2. The latest version of rsync offers extra options for
checksumming,
and that seemed to throw off the new rsync-bpc's use of
MD5 for file
comparisons. My very klundgy fix for that has been to add
the rsync
'--checksum-choice=md5' option to $Conf{RsyncArgs} but I'd
much prefer
to look at modifying the code to force the use of the
right checksums
without requiring any changes to the configuration. At
this stage I
don't know what this might mean for people using e.g.
'openrsync' on
the Mac - I don't know if the Mac's rsync recognizes the
option - and
I don't know if it will be an issue for people using very
old versions
of 'genuine' rsync on other clients. If there are Mac
users Out There
reading, *please* help me with the testing if you can. If
your rsync
version _is_ very old, I promise not to tell.
At this stage, rather than putting something on Github
which may quite
possibly crash and burn, I'd prefer to email the source to
volunteers.
Any takers?
I'd be happy to give it a shot. You have my email so send a
"tar.gz" when ready.
--
Jim KR
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
