Hi Jan,

On Fri, Mar 23, 2007 at 03:18:56PM -0400, Jan Harkes wrote:
> > the checksums should include a per file random IV so that given a contents
> > one could not predict the corresponding Coda hash.
> > Otherwise the metainformation indirectly reveals the file contents.
> 
> No never, what the server should do is not provide the SHA1 at all as
> part of the metadata if the client is not allowed to read the file
> contents in the first place.

Sure, it is better.

> This would make it too expensive to build/use a lookaside database,
> let's say I have a local copy of a FC5 install and I want to use that
> for lookaside, do I now have to send the contents of all these files
> back to the server so that the server can figure out which local files
> happen to match so that it can send back the modified checksums.

If Coda contained more or less the same tree of directories, then
you just had to fetch the corresponding IV's from Coda (Venus might
provide such interface without fetching the contents) and then
build your database.

If the files are scattered, then it would not work.

You are right. I thought about building lookaside from Venus caches
but there are other situations where it is useful.

> And what are we protectings against? To prevent someone who doesn't have
> read access to a file from intercepting the sha1? If that is possible we

If sha1 is not available unless read access is allowed, then we are fine.
(Isn't the hash currently sent with the file attributes?)

> The current server already has no room for the lookaside SHA1 hashes.
> I'm still weighing different approaches to storing that additional
> information persistently to avoid having to recalculate it everytime a
> vnode is copied from RVM. The server currently uses an in-memory vnode
> cache which avoids some of pain of recalculating the SHA1.

Hope one sunny day directories will be migrated from rvm, or something.
Then there will be more space, hopefully.

Thanks for your work Jan!

Rune