dlls/advapi32/crypt.c

[Dan Kegel]

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