On Monday 26 July 2004 00:14, Robert Shearman wrote:
- Implementation of "real handles", instead of "address-handles".
This is useful. Address handles (pointers to objects in memory) have the disadvantage that they can leak memory if the application can't be bothered to free them, although this only really matters if the library is unloaded (as if the process terminates, all memory will be freed anyway) and can be just as easily accomplished with a separate heap. Hmm, maybe it isn't so useful. Why did you go down this route?
I think there are many reasons to favour "real handles": If a long running process is using rsabase (e.g. a webserver serving https: requests) with many temporary connections and many keys, resource leakage is an issue. Furthermore, since rsabase is a cryptographic service provider, it might be important that a key, which is not referenced anymore is in fact destroyed (and the corresponding memory be nulled). I would think that otherwise you will over time accumulate a lot of keys in your address space, which is probably a security problem. Now, I'm aware that wine is not in a state today to be used for security critical applications and first rsabase implementations will probably have security issues more severe than this. However, sometime I think rsabase will have to use real handles. Why not right from the start?
- Separating OpenSSL dependend code from CSP code. I consider
this beneficial, since there seem to be some license issues with OpenSSL (at least for the ReactOS project - there was a short discussion on this on the wine-devel list). If the OpenSSL code is cleanly separated, it will be easier to support GNUTLS or something later.
I think this is just making the job harder. Yes, OpenSSL possible has licensing issues, but that is for the OS. Is there anything stopping you creating an OpenSSL layer on top of GNUTLS (or any other crypto library), rather than going down this messy compatibility route?
In my opinion it would be nice for the end user, if rsabase works with either OpenSSL or GNUTLS, whatever is installed. I think telling the end user to install a GNUTLS/OpenSSL compatibility layer library before using rsabase with GNUTLS is messier than making rsabase work with both of them. Furthermore, we could implement a "dummy" implementation, which does not do any cryptographic operation at all. So if neither openssl nor gnutls is installed only the "skin" of rsabase works, no "guts". I would bet that there are some applications which will run anyway (As the "Implemented enough of rsabase to make Steam login" comment in the current rsabase implementation suggests).
However, as I've said, I didn't implement much of the "guts" upto now. Thus I don't know how similar openssl and gnutls are and how hard it would be to abstract from both. So if you consider this approach messy, I will be happy to keep it out.
- Basically, my code doesn't do any crypto stuff at all until now
(Besides some first lines of code for MD5 hashing). I tried to get the MSDN CryptoAPI examples to compile and run, which only acquire contexts, hash data, derive keys, query CSP params and so on, but which never verify the results. So my code is mainly skin (but elephant skin), no guts.
Yes, it is similar code to mine, except I used the EVP higher-level routines as they offer a similar framework to CryptoAPI and it is really no more work to add in new algorithms (except for a case statement in one or two switch blocks).
I've attached the current version of my patch.
Do you have a certain application, which you want to get running?
Not really. I went down this route because I thought it would be needed for a certain application, but it turned out that it didn't need it. I'd still to finish the work and to get it incorporated into the Wine tree, however. I can still use this application to test with though (it calls ExitProcess if it doesn't verify correctly).
Would it be ok for you if we proceed as follows: I will wait until you submit your patch (It would be nice if you could add some unit-tests that test for behaviour you depend on). After this you give me a week or two to incorporate my work.
Sure, that sounds good.
Is there any area in rsabase, which you definitely will not implement in the near future and which I could work on until you submit your patch?
Well, pretty much everything that I was going to implement is in the patch I sent you. The only additional functions I was going to implement are RSA_CPSignHash and RSA_CPVerifySignature. However, if you want me to implement some more I would be only too happy to do so having gained a lot of familiarity with both CryptoAPI and the OpenSSL/Crypto library.
I don't have a certain application in mind either. So I don't have concrete wishes for functions to be implemented. I just wanted to find a start contributing to wine and ended up working on rsabase by chance.
Michael