I don't understand how applink is going to help you. The SSL libs are statically linked > into the _ssl extension DLL.

I personally have not used _ssl but on quick inspection I don't see any of the crypto algorithms implemented, AES, ECDSA, etc. What if we want to encrypt or sign content using OpenSSL? We'd import M2Crypto but when we go to load the key we'll get an OPENSSL_Applink error. Likewise for OpenSSL with xmlsec. Larry

I personally have not used _ssl but on quick inspection I don't see any of the crypto algorithms implemented, AES, ECDSA, etc. What if we want to encrypt or sign content using OpenSSL?

I suggested adding a class which gives you access to those. I think it's a good idea, and that serious use of SSL will require signing eventually. If you'd like to submit an RFE, particularly an RFE with a patch which includes a test case, that would move things along smartly. Bill

Bill Janssen wrote: [snip]

Do you have an opinion on the initial proposal of applink.c? The proposal does neither seem harmful nor problematic but I also don't see how it is going to help the op.

Christian

I know nothing about it -- it's a Windows thing. But reading the note at http://www.openssl.org/support/faq.html, I can see why Windows developers might like to have it: ``Note that debug and release libraries are NOT interchangeable. If you built OpenSSL with /MD your application must use /MD and cannot use /MDd. ``As per 0.9.8 the above limitation is eliminated for .DLLs. OpenSSL .DLLs compiled with some specific run-time option [we insist on the default /MD] can be deployed with application compiled with different option or even different compiler. But there is a catch! Instead of re-compiling OpenSSL toolkit, as you would have to with prior versions, you have to compile small C snippet with compiler and/or options of your choice. The snippet gets installed as <install-root>/include/openssl/applink.c and should be either added to your application project or simply #include-d in one [and only one] of your application source files. Failure to link this shim module into your application manifests itself as fatal "no OPENSSL_Applink" run-time error. An explicit reminder is due that in this situation [mixing compiler options] it is as important to add CRYPTO_malloc_init prior first call to OpenSSL.'' Bill

I won't pretend to know where the *best* place to put the include is, but python.c was suggested to me some time ago. Just so you know, we tried putting the include in some C code that is part of M2Crypto and it did not work because, as we discovered, the applink table needs to be part of main(). Extending that thought... If somebody wanted to somehow embed python is part of the same process in their program as with perhaps IIS, I submit it would not be part of main() and therefore benign. Now, I would like very much to be in a position to experiment with all the combinations and prepare a patch that worked, but I do not have the requisite Microsoft toolset. I primarily work with gcc under OSX, Linux, cygwin/mingw. This last raises a curiosity question. Is there a reason why Python.exe cannot be built using gcc instead of Visual Studio? Would not requiring the same VS version cause a problem in the field if someone were to receive an extension but had their Python built using a different version of VS? It seems building everything with gcc would get around the problem of having to match VS versions. ...or are we dependent on some specific Microsoft library? I dunno, I gotta ask. Larry -----Original Message----- From: "Martin v. Löwis" [mailto:martin@v.loewis.de] Sent: Tuesday, February 26, 2008 1:10 PM To: Christian Heimes Cc: Bill Janssen; Bugbee, Larry; python-dev@python.org Subject: Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?

Do you have an opinion on the initial proposal of applink.c? The proposal does neither seem harmful nor problematic but I also don't see how it is going to help the op.

The specific change isn't going to help. What could help is the inclusion of applink.c into dl_nt.c. This is not about somehow exposing SSL routines to other libraries, but about exposing CRT stuff to openssl, specifically stdin/stdout/stderr, fprintf, fgets, fwrite, fsetmod, feof, ferror, clearerr, fileno, _open, _read, _write, _lseek, _close. Actually, re-reading OpenSSL, adding it to python.exe (and probably pythonw.exe) would help: They do GetModuleHandle(NULL) (which is the handle to the executable), then GetProcAddress for OPENSSL_Applink. So I think it's harmless and could help, except for the maintenance burden of having to update our local copy of applink.c every time OpenSSL adds a new slot to their applink table (which they should rarely do). Of course, the entire approach breaks in cases where Python gets embedded: if, e.g., IIS loads the Python interpreter as a COM scripting host, it would be the IIS executable which would have to include applink.c :-) As IIS doesn't, extension modules that link with their own OpenSSL will continue to produce a warning about the missing applink when they run in the context of a COM server (or some other Python embedding). Regards, Martin

I appreciate the gesture but... At this juncture I'd prefer to see OpenSSL access to crypto APIs remain an external library like M2Crypto, at least until the Python community is willing to do a full implementation of all OpenSSL APIs. ...and maintain it. Larry -----Original Message----- From: Bill Janssen [mailto:janssen@parc.com] Sent: Tuesday, February 26, 2008 10:14 AM To: Bugbee, Larry Cc: Christian Heimes; python-dev@python.org Subject: Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?

I personally have not used _ssl but on quick inspection I don't see any of the crypto algorithms implemented, AES, ECDSA, etc. What if we

want to encrypt or sign content using OpenSSL?

I suggested adding a class which gives you access to those. I think it's a good idea, and that serious use of SSL will require signing eventually. If you'd like to submit an RFE, particularly an RFE with a patch which includes a test case, that would move things along smartly. Bill