On 11/10/07, Michael Halcrow <[EMAIL PROTECTED]> wrote: > On Sat, Nov 10, 2007 at 01:05:55AM +0200, Alon Bar-Lev wrote: > > I guess we are back on business? > > Can you please address these point? > > Your suggestions make sense. I don't have a lot of time over the next > 4 weeks to work on anything but critical bugfixes (kernel > oops/segfault type stuff). If someone wants to spend the time to make > these modifications and send patches along, I will review and merge > them.
Thanks! I will wait. > > > 1. Introduce statefull mode. > > So long as it is not a global state (i.e., it is referenced with a > handle that gets created by the key module and passed in on future > calls), I have no problem with that. I would like to keep the generic > calls into key module (i.e., ones that do not involve any sort of > session handle or what not) to remain reentrant. What I think is to call the key module to allocate its state. Also the key should not be deserialized at every call, so there should be a key state. Nothing global, all reentrant. > > > 2. Allow the key module to report that a key is unusable. > > Is the idea to prevent attempts to call encrypt/decrypt repeatedly? In > this case, we probably just need the proper return codes, along with > perhaps some annotation on the key in the user keyring for future calls. Great! Just tell me the codes... :) > > > 3. Key module context & parameters > > > > > Allow key module specific parameter that are not related to a specific > > > key, this will allow to specify some module wide options. It should be > > > read from some configuration file and forwarded to the key module > > > during initialization. > > I am inclined to just let each key module handle its own configuration > file in this case rather than futher complicate the existing > configuration file parsing code. OK. Already done this. > > > 4. [Not directly related] Pluggable Random Generator > > If you are talking about the per-file key generated in the kernel, > then this is more a kernel-level change than anything we should do in > userspace. The kernel already supports swapping out the random number > generator used for calls for random numbers via its own API (HW_RANDOM > build option). No, I mean calling the usermode daemon in order to do this... So that users may select a better source... But this is just a thought. Thanks, Alon. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
