build(deps): bump duplicity from 1.2.3 to 2.0.0

[dependabot]

Bumps duplicity from 1.2.3 to 2.0.0.

Release notes

Sourced from duplicity's releases.

librsync 2.0.0

Note: despite the major version bump, this release has few changes and should be binary and API compatible with the previous version.

• Bump librsync version number to 2.0, to match the library soname/dylib version. (Martin Pool, librsync/librsync#48)

Changelog

Sourced from duplicity's changelog.

librsync 2.0.0

Released 2015-11-29

Note: despite the major version bump, this release has few changes and should be binary and API compatible with the previous version.

• Bump librsync version number to 2.0, to match the library soname/dylib version. (Martin Pool, librsync/librsync#48)

librsync 1.0.1 (2015-11-21)

• Better performance on large files. (VictorDenisov)

• Add comment on usage of rs_build_hash_table(), and assert correct use. Callers must call rs_build_hash_table() after loading the signature, and before calling rs_delta_begin(). Thanks to Paul Harris paulharris@computer.org

• Switch from autoconf to CMake.

  Thanks to Adam Schubert.

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 librsync/librsync#5

  Thanks to Michael Samuel for reporting this and offering an initial patch.

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #637.