Re: encrypted destination

On 12/23/2009 03:30 PM, Michael wrote: Hello I am looking for a method/feature to rsync my files and store them encrypted. While searching for a solution I found some postings about --source-filter and --dest-filter options but these seem to to be implemented. Of cause I could encrypt and them r

encrypted destination

Hello I am looking for a method/feature to rsync my files and store them encrypted. While searching for a solution I found some postings about --source-filter and --dest-filter options but these seem to to be implemented. Of cause I could encrypt and them rsync but this costs double of space and a

Re: encrypted destination

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 pla

Re: encrypted destination

On Wed, Aug 17, 2005 at 01:12:42AM -0700, Wayne Davison wrote: >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 s

Re: encrypted destination

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 som

encrypted destination

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

perlrsync (was plain source -> encrypted destination: rsync + gpg)

Hi, I have achieved a reasonable preprocessing of files before pushing them to the remote server (for instance, compressing or encrypting the files) using perlrsync (in the source) and rsync (destination). I tried patching the rsync sources, but it's obviously non-trivial and I am obviously no

Re: plain source -> encrypted destination: rsync + gpg

Kyle Jones wrote: Right. I was willing to give up the checksumming for my application. It seems that you could code a --source-filter patch that would - compare the source and destination modtimes - if they differ, then apply the filter to the source file storing the output in a temp file. com

Re: plain source -> encrypted destination: rsync + gpg

jw schultz wrote: Am I on the right track? Help/advise? Is it doable at all? That sounds fairly doable. I'm thinking what you would do is to create a temporary file to match/send and delete it on close. Essentially wrap the applicable open and close ops. I may try something this weekend. Actual

Re: plain source -> encrypted destination: rsync + gpg

[EMAIL PROTECTED] writes: > > If i recall correctly (i've not gone back to review that > > patch) that patch required whole-file transfers two avoid > > doing the operation twice per file. If the filter is > > deterministic and particularly if changes have minimal > > cascade effect you may b

Re: plain source -> encrypted destination: rsync +gpg(--dest-filter patch)

On Thu, Jun 26, 2003 at 05:45:55PM +0200, [EMAIL PROTECTED] wrote: [Lots of missing attribution maybe correctly reinserted] [please don't remove attributions of quoted content] > jw wrote: > > [EMAIL PROTECTED] wrote: [snip] > > > The idea of this patch seem to me very useful. > > > I'm plan to use

Re: plain source -> encrypted destination: rsync +gpg(--dest-filter patch)

> > > If i recall correctly (i've not gone back to review that > > > patch) that patch required whole-file transfers two avoid > s/two/to/ #ick > > > doing the operation twice per file. If the filter is > > > deterministic and particularly if changes have minimal > > > cascade effect you may be a

Re: plain source -> encrypted destination: rsync + gpg(--dest-filter patch)

On Thu, Jun 26, 2003 at 04:31:29PM +0200, [EMAIL PROTECTED] wrote: > > If i recall correctly (i've not gone back to review that > > patch) that patch required whole-file transfers two avoid s/two/to/ #ick > > doing the operation twice per file. If the filter is > > deterministic and particularly

Re: plain source -> encrypted destination: rsync + gpg(--dest-filter patch)

> If i recall correctly (i've not gone back to review that > patch) that patch required whole-file transfers two avoid > doing the operation twice per file. If the filter is > deterministic and particularly if changes have minimal > cascade effect you may be able to still take advantage of > the r

Re: plain source -> encrypted destination: rsync + gpg

On Thu, Jun 26, 2003 at 10:42:35PM +1200, Martin Langhoff wrote: > jw schultz wrote: > >Stop thinking client and server. Once the session is > >initiated there is little difference. Think instead sender > >and receiver. > > Good advise. Have to rephrase myself, then ;) > > As I read the patch,

Re: plain source -> encrypted destination: rsync + gpg

I am thinking of running an arbitrary command on the server, when it is Of course, I meant s/server/sender/; m -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: plain source -> encrypted destination: rsync + gpg

jw schultz wrote: Stop thinking client and server. Once the session is initiated there is little difference. Think instead sender and receiver. Good advise. Have to rephrase myself, then ;) As I read the patch, it seems to be running an arbitrary command on the receiver. I am thinking of runni

Re: plain source -> encrypted destination: rsync + gpg

On Thu, Jun 26, 2003 at 10:15:33PM +1200, Martin Langhoff wrote: > [EMAIL PROTECTED] wrote: > >The filter run on the client ! > > Are you sure? I just re-read the patch and it still seems to be at the > server. > > Maybe I don't have the right idea of server/client in my head. Or I am > just m

Re: plain source -> encrypted destination: rsync + gpg

[EMAIL PROTECTED] wrote: The filter run on the client ! Are you sure? I just re-read the patch and it still seems to be at the server. Maybe I don't have the right idea of server/client in my head. Or I am just misreading the patch. How can I tell it's on the server? m -- To unsubscrib

Re: plain source -> encrypted destination: rsync + gpg

> [EMAIL PROTECTED] 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%24256

Re: plain source -> encrypted destination: rsync + gpg

[EMAIL PROTECTED] 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

Re: plain source -> encrypted destination: rsync + gpg

e.NCTU.edu.tw&rnum=1 Addady - Original Message - From: "Martin Langhoff" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 26, 2003 8:38 AM Subject: plain source -> encrypted destination: rsync + gpg > We want to keep a backup or a mirror of yo

Re: plain source -> encrypted destination: rsync + gpg

Yet another thread on the matter -- To unsubscribe or

plain source -> encrypted destination: rsync + gpg

We want to keep a backup or a mirror of your files in a server we don't fully trust. You can have an encrypted FS on a file, and copy the complete FS to the untrusted server, but it is inefficient, and you get no granularity at all. In our case, the remote server runs amanda, and we want to use