On 10/9/07, Michael Halcrow <[EMAIL PROTECTED]> wrote: > 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.
Well. This is not technical argument. Redhat will patch the ecryptfs to use nss, they have done this for OpenSSH and to pam_pkcs11, they don't do good job in understanding smartcards, so the users ends up with bad solution. But they do wrote that if OpenSSH (for example) would merge my PKCS#11 patch, they would revert their nss patch and use whatever upstream chose. I am working with OpenSSH developers for some time, but they do not have the time for new features. https://bugzilla.redhat.com/show_bug.cgi?id=186469 pkcs11-helper is used also by gnupg-pkcs11-scd which is the current only solution for standard smartcards into gnupg. pkcs11-helper is used by OpenVPN, and when released the RPM will be updated. kde-4.1 also will likely use QCA which in turn uses pkcs11-helper, and the next version of psi uses qca-2 which uses pkcs11-helper. So there are a few options: 1. Every project above be afraid of the large vendor, never introducing new dependencies, minimizing its functionality for a long time, keeping the user out of new features. And then reinventing the wheel resulting in a very basic solution for users, as not use code reuse tends to lead to minimizing the effort. 2. A package can supply an optional dependency (--enable-pkcs11), which will be available to all users. These large vendor can decide if they wish to provide this feature to its end users. But at least having the features, so users at different distribution may have the feature, and also people on these large vendors may add the feature if they wish to. And maybe next version these large vendors will get requests from their users to add the feature, hence adding the dependency. 3. A package can provide the snapshot of its dependencies within its tarball, fooling of these large enterprises if they don't wish to add a dependency. I believe that if you will argue that this solution is the right solution for your package, it will be accepted, but you should believe in it. They won't add library package if it is not a dependency of other packages. But anyway, I don't care placing a snapshot of pkcs11-helper at your tarball... autoconf do support recursive packaging, but this will be a mistake as we don't wish to fool the vendors. I will not rewrite low level PKCS#11 code outside the pkcs11-helper library, this will be unwise, unprofessional, unmaintainable and unsupported, especially if the reason is political one. I will wait for you to decide what you wish to do regarding this matter, as I don't wish to invest more time in this if we going to through it away. What I suggest is for you to support this configuration, and see if the large vendors use --enable-pkcs11. If they don't, you lose nothing for now, as you did not intend to have PKCS#11 so soon anyway, right? Then I and other users (if you don't want to be part of it), may discuss the inclusion of the feature with the large vendors and get their formal response. At least in the meantime many other users will enjoy the feature and provide valuable feedback. After a while if and when you decide to implement your own PKCS#11 key module, you do that *REPLACING* the former one, as there is no reason keeping both implementation around. But at least the efforts of making the environment, the API, the user interface and procedures already suitable for dynamic hardware cryptography. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
