(fwd from uke@jeremy.org) thanks and patch

[Martin Pool]

On 21 Mar 2002, Dave Dykstra <dwd at bell-labs.com> wrote:

> > > I guess that makes sense; I can't think of another easy to do what you want
> > > to do.  Pretty obscure case though.
> > 
> > Obscure now, but I expect not forever.
> > 
> > If you consider it desirable for rsync to be able to do this task
> > (encrypted backups on untrusted servers) all by itself, all it needs
> > in addition to the --date-only option is the ability to accept a
> > user-specified filter for each file to be transferred.  If I were to
> > make a patch for that, I don't suppose you'd want it?
> 
> I don't know, I think it would depend on the implementation.  There might
> be a number of uses that people could put it to.  The thing that I don't
> like about it is that for most uses I can think of (compression is another
> example) it won't be able to use the rsync rolling checksum algorithm,
> which is mostly what people think of when they think of rsync.  It's true
> that a lot of people end up using rsync just for its ability to recurse
> down two directory structures and identify differences, however, so they
> might be happy with it.  I would think the option would default to
> have the option.

So, you could possibly say that rsync should run gpg on the remote
machine to decrypt the old backup, transfer differences, and then
encrypt the new backup.  Of course this is not so secure if you really
distrust the remote admin.

I once thought that it would be good to have a way for rsync to call
commands in various scripting languages or through the shell at
crucial points.  I'm not really sure the complication it causes is
justified.  Machine-parseable output might get many of the same
benefits.

-- 
Martin