crypting remote data

[david reinares]

I did as you said..the program calls openssl after rsync to decrypt
restored data...

But the patch has serious problems...besides the dest-filter error,
testing large amount of data (well, not such large, 70 Mbs),
i received this message..

html/lib/perl5db.html
      9 [main] rsync 2760 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_V
IOLATION
    608 [main] rsync 2760 open_stackdumpfile: Dumping stack trace to rsync.exe.s
tackdump
1870590 [main] rsync 2760 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_V
IOLATION
1909558 [main] rsync 2760 _cygtls::handle_exceptions: Error while dumping state
(probably corrupted stack)

This patch needs really hard work and lots of testing...reading the
list i think i saw something similar

rsync error: STATUS_ACCESS_VIOLATION

Rob Bosch
Thu, 25 Oct 2007 17:56:19 -0700


I don't know if it's the same failure or the same cause...


I guess i'll have to figure out another way to rsync and crypt in a
efficient way..another idea?


By the way thank you very much and sorry for the inconveniences


---------------------------------------------------------------------
On Mon, 2008-03-10 at 22:55 +0100, david reinares wrote:
> After testing a bit more i discovered that fails when i pass the
> command to restore and decrypt with dest-filter (in the client side).
> Always the same file, no matter how many times i execute rsync. But
> after testing diferent folders, i can't see the conection between the
> failed files. html, java, etc, but all of them with more files exactly
> like them in the folder but rsync'd and decrypted perfectly.
> If i do the same with source-filter (server side) it seems to work ok,
> i can restore all files. But that is a problem, because we don't want
> to have the files decrypted in the server not even for a second,
> appart of the fact that having a big bunch of clients restoring at the
> same time with all the hard work of decrypting in the server side
> would overload the server.
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------------
> Very good this patch...thank you
>
> I've been testing this after patching rsync, and works fine to backup...but
>
> when I'm restoring the crypted data after a while rsync shows
> rsync: Failed to close: Bad file descriptor (9)
> rsync: Failed dup/close: Bad file descriptor (9)
> rsync error: error in IPC code (code 14) at pipe.c(208) [receiver=3.0.0]
>
> rsync error: error in IPC code (code 14) at pipe.c(195) [receiver=3.0.0]
> rsync: connection unexpectedly closed (55 bytes received so far) [generator]
> rsync error: error in rsync protocol data stream (code 12) at io.c(600)
>
> [generat
> or=3.0.0]
>
> It's a bit strange. It restores some files before failing, and they are
> perfectly decrypted...i'm using openssl as command

I will look into the problem with the patch if I get a chance.  One
workaround for restoring files would be to rsync the desired files to
the target machine without filtering and then decrypt them there (with
rsync and --source-filter or just a shell script).

Matt
-------------- next part --------------
HTML attachment scrubbed and removed