In the archives I see the question about encrypted destination and it's mostly answered with the --source-filter / --dest-filter patch by Kyle Jones. There are also some proposed updates to the patch. A lot of these posts 3 years old, is there plans or reasons not to include them in the main line code? // George -- George Georgalis, systems architect, administrator <IXOYE>< http://galis.org/ cell:646-331-2027 mailto:george@galis.org
On Mon, Aug 15, 2005 at 11:00:01AM -0400, George Georgalis wrote:> A lot of these posts 3 years old, is there plans or reasons not to > include [--source-filter / --dest-filter] in the main line code?That patch opens up a huge security hole in daemon servers, so that would have to be handled somehow (perhaps by making those options auto-refused). There are also several bugs/deficiencies that would need to be fixed (my updated patch--see below--lists the ones that I saw but didn't fix). Even if all that were done, I'd still be hesitant to add these options, though. I've just updated the several-year-old patch, and committed it into the patches dir: http://rsync.samba.org/ftp/unpacked/rsync/patches/source-filter_dest-filter.diff ..wayne..
George Georgalis wrote:>In the archives I see the question about encrypted destination and it's >mostly answered with the --source-filter / --dest-filter patch by Kyle >Jones. There are also some proposed updates to the patch. > >A lot of these posts 3 years old, is there plans or reasons not to >include them in the main line code? > >// George > >Personally, I solved that problem using a preprocessing program. The idea was to not share any key data with the destination. If that's interesting to you, do check out rsyncrypto (http://sf.net/projects/rsyncrypto). What it does is to encrypt the files prior to rsyncing them. The twist is that the files are encrypted in a way that does not obliterate the wire efficiency of applying rsync to the encrypted files. Shachar