Change logs for rsync source package in Lunar

  • rsync (3.2.7-1) unstable; urgency=medium
    
      [ Juri Grabowski ]
      * New upstream version 3.2.7
      * Remove patches included in new release
    
      [ Helmut Grohne ]
      * Fix FTCBFS: Use native instances for python build depends
        (closes: #1022988).
    
      [ Samuel Henrique ]
      * d/rsync.lintian-overrides: Update findings as per lintian changes
      * d/patches: Add two upstream patches to fix issues post 3.2.7 release:
        - trust_the_sender_on_a_local_transfer.patch
        - avoid_quoting_of_tilde_when_its_a_destination_arg.patch
    
     -- Samuel Henrique <email address hidden>  Sun, 18 Dec 2022 14:10:54 +0000
  • rsync (3.2.6-4) unstable; urgency=medium
    
      * Upload to unstable
        - d/patches:
          ~ fix_files_from.patch: Upstream patch to address the files-from issue.
          ~ fix_relative.patch: Upstream patch to fix exclusion of /. with
            --relative.
          ~ fix_remote_filter_rules_validation.patch: Upstream patch to fix bug
            with validating remote filter rules.
        (closes: #1018296, #1019561)
    
     -- Samuel Henrique <email address hidden>  Wed, 21 Sep 2022 18:58:57 +0100
  • rsync (3.2.5-1) unstable; urgency=medium
    
      * New upstream version 3.2.5
        - Added some file-list safety checking that helps to ensure that a rogue
          sending rsync can't add unrequested top-level names and/or include
          recursive names that should have been excluded by the sender. These
          extra safety checks only require the receiver rsync to be updated. When
          dealing with an untrusted sending host, it is safest to copy into a
          dedicated destination directory for the remote content (i.e. don't copy
          into a destination directory that contains files that aren't from the
          remote host unless you trust the remote host)
          (closes: #1016543, CVE-2022-29154).
        - The build date that goes into the manpages is now based on the
          developer's release date, not on the build's local-timezone
          interpretation of the date (closes: #1009981)
    
     -- Samuel Henrique <email address hidden>  Tue, 16 Aug 2022 11:03:48 +0100