On Tue, Oct 09, 2007 at 03:32:15AM +0200, Alon Bar-Lev wrote: > And leading to the chance that I lose sync between calculation and > set... The serialize() is not called often, so I prefer to play > safe. If it really bothers you I will revert to your implementation > at OpenSSL.
I'm not terribly bothered by it, but putting the same if() over and over again in sequence it does raise eyebrows at first glance, and I'm not sure it does much for code readability. > > > +} > > > + > > > +static > > > +PKCS11H_BOOL > > > > See above. > > This is of the pkcs11-helper library... > I understand your position regarding this code, but other people do > prefer to have boolean type. > So I replaced TRUE->1, FALSE->0 but left the type. Okay. > > Okay; I see what's going on with pkcs11-helper now. > > > > I can understand the desire to simplify the interaction with a PKCS#11 > > implementation in this manner, but then this is not a pure "PKCS#11" > > key module. This is a key module that uses some intermediate generic > > interface to some PKCS#11 backend. As such, this should not be labeled > > as a "pkcs11" key module; it should be something like "pkcs11-helper". > > I disagree. > > If I would have implemented native PKCS#11 code it would have been > the same, but as you don't write a code for reuse it will be much > uglier. pkcs11-helper is just a helper library to reduce the code > from a applications, to ease maintenance. It does enable the > application to access pure PKCS#11 providers. My main concern is that I do not want to artificially limit the key module in any way with respect to the potential features offered by the PKCS#11 spec. A second concern is the introduction of dependencies that are not available in RHEL and SLES; businesses that use eCryptfs on future versions of enterprise distributions must be able to get PKCS#11 support with only the packages that ship and are officially supported in RHEL and SLES. If we introduce a dependency on pkcs11-helper in order to use the PKCS#11 key module, then pkcs11-helper needs to make it into RHEL and SLES right along with ecryptfs-utils. That translates to extra overhead for my team and for the distro's, and the distro's may very well decide to reject PKCS#11 support in eCryptfs altogether in RHEL and/or SLES rather than deal with introducing new software into the set that they must build, package, and support. > This makes ecryptfs project focus in encrypted file system and not on > re-invent what already been implemented. > > > The feature in the eCryptfs game plan is a key module that *only* > > uses the PKCS#11 API calls, without any additional dependencies > > (OpenSSL, helper library, etc.). The eCryptfs maintainers really > > cannot officially support anything else. > > I don't understand. I thought we agree I maintain it with you guys. > Supporting smartcards is not simple, I guess many API and > functionality should be added to other modules. I won't maintain > such module externally, I need your commitment that smartcard are > well supported an have this as part of the roadmap and release > engineer. If pkcs11-helper really is the best technical solution to the problem of providing PKCS#11 support, then I am all for it. As I mentioned above, the challenge of getting pkcs11-helper into the RHEL and SLES solution stack must be outweighed by the overhead of re-implementing its functionality in the key module in order for it to begin to make sense for us to merge it into the official distribution of the code. If we wind up having to implement a key module without any outside dependencies, I don't want the aliases to conflict, which is why I suggest "pkcs11-helper" or "pkcs11h" as the module alias. > > That said, I am not against the existence of the pkcs11-helper key > > module (that is the whole reason why there is a pluggable key module > > API, much like OpenSSL has a pluggable engine API). I will probably > > use it myself at some point. I just cannot promise you that it will > > wind up getting approved to be packaged and supported in the official > > ecryptfs-utils tarball; it might need to be shipped as an out-of-tree > > add-on, for which you are the official maintainer, and have the > > documentation point users to where they can download the key module > > and get support for it. I will have to check on this. > > This would be sad for both users and me, it would be more difficult to > maintain and support this module this way. > I don't understand what is the difference between the gcrypt, OpenSSL, > TSPI dependencies and the pkcs11-helper dependency. From the perspective of the development team at the IBM LTC, the difference is what is currently available in RHEL and SLES and what is not. > If you like I can paste pkcs11-helper into this source, but I am > sure it is not the correct approach. If we would just wind up largely re-implementing what pkcs11-helper already does, then this may be the path of least resistance. > Pluggable engine is not generic enough, as a maintainer of > opencryptoki large complex and none flexible OpenSSL maintainer, I > think you understand that. > > pkcs11-helper support multiple providers, supports session expiration, > serialization, offline mode, prompt hooks and much more, all these > features are a requirement for smartcard aware application, OpenSSL > engine nor opencryptoki provide a suitable interface for this. These facts may help convince Red Hat and Novell to adopt pkcs11-helper into their enterprise distro's, especially if it enables a major eCryptfs feature. I will have to investigate the code base more deeply to get a better understanding of everything it provides. > Also if they support this, they do it very slow... So it does not > worth the effort. > > But if you think this will perform better on external device I can > do this. The PKCS#11 interface is the primary "standard supported" means of accessing certain cryptographic hardware in use in businesses, and so that is the mechanism that my team requires for a PKCS#11 key module. > But please understand that as many devices does not support much of > the operations, the OpenSSL dependency cannot be dropped. Anything in our solution stacks that we develop does have full support for all operations, whether provided by hardware or by software fallback and any development effort sponsored by the LTC generally corresponds directly with customer requirements. I try to include features that benefit others in the general community where I can, so long as they do not present a substantial ongoing maintainership burden and as long as there are no unnecessary dependencies that could wind up causing headaches down the road. In short, it is not as easy to introduce dependencies in software targeted for SLES and RHEL, compared with software targeted for Fedora or Gentoo. Every additional dependency to our toolset must have a compelling justification, so I just want to make sure that we have all of our ducks in a row before we commit to introducing the pkcs11-helper library as the primary means of providing PKCS#11 support. Aside from the technical justification, this includes establishing a level of confidence that all the dependencies will make it into RHEL and SLES without too much difficulty. (I will get to the rest of your email tomorrow.) Thanks, Mike
pgpZyIEe4JWf7.pgp
Description: PGP signature
------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
