plain source -> encrypted destination: rsync + gpg
ml at nzl.com.ar
Thu Jun 26 19:37:09 EST 2003
addady at active.co.il wrote:
> It seems that the --dest-filter patch of Kyle Jones can help you.
> Here is a link
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?
More information about the rsync