On 10/10/07, Michael Halcrow <[EMAIL PROTECTED]> wrote: > We will work on merging the key module that uses pkcs11-helper into > the official ecryptfs-utils package.
Thanks. But it seems we have understand the the official differently, do you mean "binary rpm" as official and source tarball as not? > Such a key module will then be linked against anything that provides > that API. Right now, openCryptoki is available in RHEL and SLES, and > it fully implements the PKCS#11 spec, so that is likely to be the > library that we would recommend as the implementation of the API calls > if we decide to write a PKCS#11 key module in the near > future. However, *any* correct and complete PKCS#11 implementation > could be dropped in, and the key module will still function as > expected. This libecryptfs_key_mod_pkcs11 does not exist, and it may > never exist, so long as libecryptfs_key_mod_pkcs11-helper meets all of > our requirements. We still need to spend some time evaluating it > against requirements. I don't understand openCryptoki is a provider (as far as I know) and OpenSSL engine. Why will you consider linking against it? Linking against a specific provider is not the PKCS#11 way, as the user cannot use provider he chooses. And if you do, I don't understand why it will not be called openCryptoki key module. But never mind. Let's try to do our best for users. Best Regards, Alon Bar-Lev. ------------------------------------------------------------------------- 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
