Gavriel State wrote:
That said on the licensing side, I have no idea whether the OpenSSL code actually provides the functionality we need to implement the CryptoAPIs. Has anyone looked into this yet?
The other alternative is to ask the libgcrypt team if they are willing to consider LGPL-ing their library so that we can use it. Has anyone asked?
FWIW, Peter Gutmann (author of another SSL API, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ ), says wine is welcome to use his code:
Dan Kegel wrote:
On an unrelated note, a couple people on wine-devel are thinking of implementing support for Microsoft's CryptoAPI in Wine (hopefully based on an existing crypto library, if one can be found that is suitable, license-wise). Any wisdom you could throw their way would probably be appreciated.
Euurgghh, that'd be like implementing RPC over SMB support for... oh hang on, that's already been done :-). The two problems are (1) it's a pretty awful design (and I'm using the word "design" loosely here, accretion might be a better word) and (2) it's a great pile of semi-documented, uncontrolled functions, structures, constants... hmm, it really is like RPC over SMB.
Anyway, if you do want to implement it you're welcome to use cryptlib for it (you can use it for Wine under whatever terms Wine requires), cryptlib has an API-mapping layer (look at cryptapi.c) which maps any API to the native cryptlib functions (a bit like the Win32 vs NT native API) so by unplugging cryptapi.c and plugging in a CryptoAPI-compatible interface you should be able to do a lot of what you want - there's support for certificate stores and all the usual stuff which CryptoAPI needs in there.
(As the above may indicate, I've looked at doing this a bit myself, but couldn't really work up much enthusiasm for it).
Peter.
- Dan