On Wed, 24 Mar 2010 16:29:22 -0400 Tom Keiser <[email protected]> wrote:
> I think a great deal of value could come out of the design of a thin > abstraction that would allow us, over time, to back the crypto > routines with whatever is available. Sure; I think a case could be made that such a thing could even be an entirely separate module, and doesn't need to be that related to AFS. But is that in scope for a project like this? Or alternatively, does anyone else have time to create it so this project could use it? > Once we have a good API for the CM code to call, it's perfectly > reasonable (and perhaps even preferable from a portability standpoint) > to make the first implementation of our API a userspace upcall to e.g. > OpenSSL, or a pkcs11 library. We can always revisit the issue later > and provide targeted in-kernel implementations of the API on platforms > where people care enough to do the work. Okay, but is it still reasonable before such an API exists? It doesn't sound like a fun position to be in if the project has a dependency that OpenAFS does not fulfill yet. Unless creating it is in scope... If that approach is taken, I think care should be taken that you don't 'cheat' with the userspace stuff (i.e., do anything besides the encryption itself; such as encryption configuration or key requisition). Since the more that is done in userspace, the more will need to be re-done in kernelspace. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
