Re: Crypto and initialisation

[Graham Leggett]

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

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

it's never been more widely adopted?  My experiences using nss-based ldap
have not been particularly fun in terms of interop.

several other programs in an unconnected manner, also using SSL. Take auth, from its inception. That includes nss; perhaps this is a significant reason

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
--

smime.p7s
Description: S/MIME Cryptographic Signature