<br><br><div class="gmail_quote">On Thu, Feb 4, 2010 at 10:22 AM, JK <span dir="ltr"><<a href="mailto:jknapka@kneuro.net">jknapka@kneuro.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<snip> </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> None of that would be pertinent to the<br>
question of why one would want an encrypted view of a clear local filesystem.<br>
If the objective is to secure the data stream in transit, then the<br>
straightforward answer would be to, well, encrypt the data stream in<br>
transit.<br>
<br>
Maybe I'm missing something, though.<br>
<font color="#888888"><br>
-- JK<br>
</font><div><div></div><div class="h5"><br></div></div></blockquote><div><br>My understand is he wants something to transparently encrypt the files as he reads them from disk so they end up encrypted on the disk of the remote host. Duplicity uses gpg as it goes, so it should meet that goal. My only concern with duplicity is that it apparently creates tarballs in /tmp before encrypting, which is a no-no to me since my /tmp is not encrypted, though I'm considering doing a cryptoswap-style /tmp (random key generated on boot). <br>
</div></div><br><br clear="all"><br>-- <br>David Tomaschik, RHCE<br>System Administrator/Developer<br><a href="http://tuxteam.com">http://tuxteam.com</a><br>GPG: 0x6D428695<br>