> Do you run cfs with ciphertext in coda, and do stuff over a 28.8 line

  Huh? Ciphertext?! What do you mean?

Sorry, acronym collision.  See http://www.crypto.com/software/

CFS is a package that provides an encrypted filesystem.  It has
ciphertext (files with names in hex that are the encrypted file names,
with encrypted comments, and special symlinks that store IVs) in some
filesystem, and one speaks NFS to 'cfsd' to get the plaintext out,
using an admin protocol to give it the key and attach ciphertext.

So I have /crypt/gdt-coda show up on my system, and the ciphertext is
in 'secret' in my coda homedir.

This keeps the plaintext of my files off the server and off the backup
tapes.

Using coda for ciphertext storage is awkward for 2 reasons:

cfs by default opens files for write always, even if the plaintext
file is opened for read.   I've fixed this locally.

coda's cfs tool doesn't work in plaintext dirs; really there needs to
be some stackable fs notion of passing just calls down, translating
the names.  Repair also does not work.  So you have to do repairs on
ciphertext, for which it is hard to figure out what's going on.

It would be cool to teach cfs about global/ and local/ files, and have
those if they show up in cipertext just show up in plaintext.  Then
you could 'setmixedview' and look at the plaintext sensibly.   But
since my rate of being able to repair conflicts is so abysmally low, I
haven't bothered.

(I bet if I got a real conflict I could repair it.  But my usage
pattern avoids those, so I'm left with 'local inconsistent object'
problems.)