On Thu, Oct 16, 2003 at 03:49:26PM +0100, Toad wrote: > On Fri, Oct 17, 2003 at 12:45:36AM +1000, fish wrote: > > On Thu, Oct 16, 2003 at 03:30:06PM +0100, Toad wrote: > > > On Thu, Oct 16, 2003 at 10:28:15PM +1000, fish wrote: > > > > On Wed, Oct 15, 2003 at 06:14:21PM -0700, Martin Stone Davis wrote: > > > > > > > > > SOLUTION #2: that keys that we request would somehow be moved into a > > > > > separate, encrypted store, and never placed in the main datastore. > > > > > > > > I talked about this once before, although for a differnet reason (I > > > > actually implented it at GetRequestProcesS level, because I was looking > > > > for speed for fproxy rather than trying to solve this particular problem). > > > > > > I am not sure where would be the best level to implement it yet. > > > > I used to think at fproxy level, but I've since changed my opinion, because > > I think it would be beneficial to provide this functionality to FCP based > > clients as well > > Exactly. It's ugly to do it at the state machine level, but I don't > think we have much choice. > > > > > Actually, it needs to be a key PER FILE. The files have randomly > > > generated filenames. We keep both the decryption key and the data key in > > > RAM at all times. We do NOT want to reimplement the monolithic > > > datastore, the filesystem is quite capable of storing files. > > > > It actually is per file, my phrasing was just unfortunate. > > Okay. As long as you aren't storing multiple keys in one file. Anyone > who reimplements the monolithic datastore will be subject to public > ridicule :)
By being made to debug the bloody thing. :) -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
