httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Crypto and initialisation
Date Sun, 14 Sep 2008 19:03:52 GMT
William A. Rowe, Jr. wrote:

> Nonsense.  In the MS world, double initialization and thread safety are
> entirely mandated by design.

So, if I am reading you correctly, if module A called 
CryptGetDefaultProvider, then set parameters using CryptSetProvider or 
CryptSetProvParam, and then module B came along and did the same thing, 
these two modules would have completely independent handles to crypto 
that would not clash with each other? The docs I have read so far imply 
that settings are application wide. Can you confirm?

> Once upon a time, there was a need for a program to accept SSL input and
> do something other with it.  A single use of SSL and nothing further.
 >
> Today, the program which accepts SSL input then needs to ask questions of
> several other programs in an unconnected manner, also using SSL.  Take 
> auth,
> for example.  Even inquiring about the current processes credentials
> (think nss/pam/ldap) is going to trigger the necessity of an SSL provider.
> 
> So any SSL provider incapable of double initialization today is irrelevant
> from its inception.  That includes nss; perhaps this is a significant 
> reason
> it's never been more widely adopted?  My experiences using nss-based ldap
> have not been particularly fun in terms of interop.

Doesn't look that way to me:

http://fedoraproject.org/wiki/FedoraCryptoConsolidation

Let me chase up the NSS people and see what their comments are.

Regards,
Graham
--

Mime
View raw message