On Wed, Jul 01, 2009 at 11:36:33AM -0400, Brian Utterback wrote: > A future ARC case could also switch us from using the OpenSSL > module to a new module with more direct access to the crypto framework. > Such a module would first need to be integrated in the community > project.
What sort of module are we talking? Where would it plug in? There already is a way to access the Solaris crypto framework more directly than via the OpenSSL PKCS#11 engine: just use libpkcs11 directly. > 4.4. Out of Scope: > > Support for NSS keystores or usage of gnutls, or libnss in place of > OpenSSL as the underlying encryption provider. Sounds like libxmlsec could use KMF. You should talk to the KMF project team. > 4.5. Interfaces: > > The libxslt[4] library is relocated to /lib but otherwise has > the same status. > > The provided commands and underlying crypto provider are > Volatile and could change based on new bits from the upstream > community and changes to the Solaris selection of crypto > providers. It strikes me that /usr/bin/xmlsec1-config should have the same commitment level as the API, i.e., Uncommitted in this case. (Also, I thought that -config commands nowadays were being deprecated in favor of pc files. Are there autoconf scripts that depend on xmlsec1-config?) Nico --
