Okay, so: - You can keep it on disk, just encrypt it with an ephemeral key. (In the long run). - How are you handling conflicts?
On Tue, May 30, 2006 at 12:34:54PM +1200, David McNab wrote: > (this discussion has been moved into its own-thread to get it back on-topic) > > Matthew Toseland wrote: > > How are you handling committing a directory? > > Hehe, I lost a bit of sleep thinking through that one :) > > What I've come up with is 4 'pseudo-files' that live in the toplevel > directory of a freedisk: > - .status - readonly, when read returns a status keyword, one of: > - 'idle' - neither updating nor committing > - 'committing' - dusk is syncing back into freenet > - 'updating' - disk is syncing locally from freenet > - 'failed\n<more details>' - something fatal happened > - .publickey - read/write - write an SSK public key into this file to > link the local freedisk with an in-freenet directory, so the > directory can be mounted readonly > - .privatekey - read/write - write an SSK private key into this file to > link the local freedisk with an in-freenet directory, so the > directory can be mounted read/write > - .cmd - write-only - typically one-word commands will be written in, > such as 'commit' or 'update' > > While committing or updating, the directory tree will be readonly, > despite any permissions to the contrary. > > When a freedisk is 'update'd from freenet, only the nodes > (file/directory records) will be fetched, not the data. When/if an > individual file is opened in read, update or append mode, the file's > data will be fetched as a CHK from freenet. If a file is opened in > write-only mode (ie truncate), no freenet fetch will occur, since the > file will become a new CHK with no reference to past content. > > When files are locally written, the changes will reside only in memory > until the next commit. > > I'm working on a command-line utility called 'freedisk' which handles > all the pseudo-files' I/O in a simple front-end, for example: > > freedisk -m /mnt/freenet new fred > Create a new freedisk called 'fred', at /mnt/freenet/usr/fred, > mounted readonly, with new random pub/priv keys > > freedisk -m /mnt/freenet add foo SSK at yadayadayada > Import a freedisk and mount readonlly, at /mnt/freenet/usr/foo > > freedisk -m /mnt/freenet update foo > Update freedisk 'foo' (at /mnt/freenet/usr/foo') from freenet > > freedisk -m /mnt/freenet add bar SSK at yadayada private > Import a freedisk and mount read/write, at /mnt/freenet/usr/bar, > using SSK private key SSK at yadayada > > freedisk -m /mnt/freenet commit bar > Commit directory /mnt/freenet/usr/bar back into freenet > > If the environment variable 'FREEDISK_MOUNTPOINT' is set, then the > '-m /mnt/freenet' option becomes unnecessary. > > Whenever a file's contents are fetched from freenet, it will be cached > in memory, not on disk - this is for security reasons, since if a PC is > uplifted by an attacker, a hard disk analysis won't identify anyone as > having accessed a freedisk (as long as they have an encrypted swapfile, > that is!) > > In the xml directory file discussed below, the 'hash' attribute will be > hexadecimal SHA(1) of the file's contents. (Not base64, because of the > plurality of base64 alphabets). > > >> To be honest, my gut feeling is that it's best for the 'freedisk' > >> project if I implement my own manifest scheme. The idea would be: > >> > >> - a manifest key, inserted as a single 'text/xml' file into > >> USK at blahblahblah/name/n, and of the form: > >> > >> <freedisk name="diskname" owner="nick"> > >> <node path="/"/> > >> <node path="/chinese_democracy.doc" > >> hash="yadayada" > >> size="nnn" > >> mimetype="application/msword" > >> uri="CHK at yadayadayada" > >> /> > >> ... > >> </freedisk> > >> > >> - CHKs for each file node > > Cheers > David > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060531/de13b832/attachment.pgp>
