Comment 2 for bug 1910262

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

[Summary]
While I'd prefer this to be an extension of real rsync instead of a fork
it seems reasonably maintained and reduced to just the bits needed for
backuppc4.

This does need a security review - almost more for the "duplication" than what
the code does, but still. I'll assign ubuntu-security

List of specific binary packages to be promoted to main: backuppc-rsync

[Duplication]
Obviously there is rsync itself, but that is so much more than the forked and
adapted version of it that is just for the use of backuppc.
And in turn - the functions needed by backuppc are not available in rsync.
So duplication is ok, with a small regret that a proper module or such for the
real rsync would be better.

[Dependencies]
OK:
- no other Dependencies to MIR due to this

[Embedded sources and static linking]
OK:
- there are zlib / popt code in the souce, but they are not used
  as d/rules configures it for --with-included-zlib=no --with-included-popt=no
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- While there are no CVEs for this, it is derived from rsync which had issues.
  Those are mostly for the server components which are not present here, but
  still it is the same code.
  Furthermore we'd want security to ack on this being a rsync-fork to be
  supported.

[Common blockers]
OK:
- does not FTBFS currently
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard
- no new python2 dependency

Problems:
- It does not have a test suite that runs at build time nor an autopkgtest
  Gladly - since this is mostly a component of backuppc4 - there is an
  autopkgtest for that which implicitly uses backuppc-rsync and thereby
  is kind of an end-to-end test covering this.
  Not perfect but ok.

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is good (somewhat behind proper rsync, but with
  regular updates)
- Debian/Ubuntu update history is ok
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody (the source has refs to it, but not in the
  bits that are used for this build)
- no use of setuid (it does check for, but not use it)
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks