plain source -> encrypted destination: rsync + gpg

[Martin Langhoff]

addady at active.co.il wrote:
> It seems that the --dest-filter patch of Kyle Jones can help you.
> 
> Here is a link
> http://groups.google.com/groups?q=%22--dest-filter%22+group:mailing.unix.rsy
> nc+group:mailing.unix.rsync&hl=en&lr=&ie=UTF-8&group=mailing.unix.rsync&selm
> =b6f55s%24256q%241%40FreeBSD.csie.NCTU.edu.tw&rnum=1

I-n-t-e-r-e-s-t-i-n-g. I am still a bit confused as to why the 
compression happens at the server and not at the client.

In the case where the client starts the transaction to "push" files (or 
push changes, rather) to the untrusted server, running the tool on the 
remote server is self-defeating.

We are planning to use gpg for the purpose, so we could trust the server 
enough to run gpg with our public key. All the server needs is to use 
its own public key instead.

Is this going to be merged into HEAD? Are there any good reasons why for 
not running it on the client?

I have to admit, I am not familiar with the source. Browsing a cvs 
checkout of the HEAD, it seems that I should be looking at sender.c. 
There is exactly one instance of do_open() in send_files().

On the other hand, I don't know the protocol but if the pre-send filter 
changes the filesize in any way, we are toast. Or maybe not?

regards,





martin