Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
But there is another problem which Unix-style Configure doesn't solve now: dll can include VERSION_INFO resource. Now Configure creates .rc file only if IsMK1MF is set. I think that if we want to have native Win32 dll, we should include this resource, even if build environment is completely Unix-style. Care to figure out and tell how to do it with windres and ld? I mean I've never done this... This one probably doesn't have to be mingw specific, cygwin people [Corinna?] might appreciate it just as much. Here is preliminary patch to generate resource sections for DLLs. I've chosen a bit different approach, see and check the latest snapshot. In addition to this resource thing the snapshot engages applink. The latter makes it possible to use .DLLs compiled with newer MSC [tested with cl version 13, a.k.a. 2003] used with mingw-compiled application and vice versa. At the very least test suits pass with replacement .DLLs:-) I call it preliminary, because: 1. DLL name issue is not permanentely settled. MSVC build creates libeay32.dll and ssleay32.dll, and Mingw build crypto32.dll and ssl32.dll. Patch includes code to support this difference, but I'm not absolutely sure it belongs there. So we have to decide on unified naming convention for both MSC and mingw. Suggestion is to embed version number into name, but remaining questions are: - do we still stick to 8.3 naming? - do we want to denote dll origin in its name? Last question means that crypto099 doesn't really give you a hint that it's an OpenSSL library. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
On 2006.10.25 at 13:36:11 +0200, Andy Polyakov wrote: So we have to decide on unified naming convention for both MSC and mingw. Suggestion is to embed version number into name, but remaining questions are: - do we still stick to 8.3 naming? Really I think that time to forget 8.3 naming is already here for five years or so. I suspect that 32-bit openssl applications won't work on Win16 with Win32s anyway. And it is only case where 8.3 matters for 32bit DLLs. As to source file naming, I don't think 8.3 is neccessary even if DJGPP target is supported. It is easier to use cross-compiler or use Windows platform for compiling. - do we want to denote dll origin in its name? Last question means that crypto099 doesn't really give you a hint that it's an OpenSSL library. A. This is good reason. eay suffix did exactly so. But I'm not sure that it is strictly neccessary. At least origin is denoted in VERSION_INFO __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
ts.h using NO_* instead of OPENSSL_NO_*
Hi, I'm trying to build a version of openssl with a very strongly reduced set of cryptographic primitives. I've already hit a number of quirks (it might be it mostly impacts Windows builds) that I'll try to detail when I have time, but here is one that's easy to fix : ts.h doesn't use the standard OPENSSL_NO_* defines for excluded stuff but instead NO_BUFFER, NO_EVP, etc. This just impacts of few line at top of ts.h __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OpenSSL and LSB
Id like to re-start some discussion about including OpenSSL in LSB (acronym expansion: Linux Standards Base see: http://www.freestandards.org). There is apparently general interest in seeing OpenSSL in LSB both for its SSL functionality as well as its utility as a general cryptographic library. In particular applications that wish to be LSB compliant would benefit from security bug fixes. Currently applications that use OpenSSL and wish to be LSB compliant are forced to statically link OpenSSL and in theory at least, may need to re-release binaries for each OpenSSL release (or at least evaluate if a re-release is necessary), something that is typically just not practical for most LSB applications. The general issues with incorporating OpenSSL into LSB are ABI stability since the magic 1.0.0 release (while closer) has not happened yet, and just the shear size of the OpenSSL API. I spent quiet a bit of time conducting an analysis of 0.7.x-0.9.8d OpenSSL releases. (documented at http://www.freestandards.org/en/OpenSSL_stability_analysis) The analysis attempted to determine three things: What APIs are actually used by released applications and can a sub-set of the total OpenSSL API be created that is functionally useful and finally is that API subset ABI stable across many releases of OpenSSL. The answers are generally, yes it is possible to determine an API subset that will work for most applications that make use of OpenSSL (language bindings and the like are ignored here), and more-or-less yes that subset is ABI stable. Further experiments attempted to determine if by treating all or most OpenSSL structure types as opaque types (i.e. no stack allocations or direct structure manipulations) would give ABI stability. The quick answer there again is yes this provided almost perfect ABI stability, but with a loss of functionality. The loss of functionality was because a fairly large portion of the OpenSSL API is implemented as macros that perform trivial manipulations on OpenSSL data types. However since these are macros, it is not also possible to force the data types they manipulate to be opaque. In almost all cases it is fairly trivial to convert the macros into functions and remove the dependency on fully typed data types. Which brings me to my questions for the OpenSSL developer community: 1) First and most fundamentally: Is the general idea of attempting to only incorporate an API subset into the LSB ABI a good or acceptable one? LSB ABIs typically do not include every last interface of most libraries that are standardized either because the non-included APIs are really library internals, the API is not stable or is only useful in specialized cases. In this case the APIs I didnt include are as far as I can tell only useful in specialized cases, or have higher level APIs that provide the same functionality (EVP vs. DES). 2) Is my concern about API stability going forward using fully typed structures unfounded? 3) Are there concerns about converting large numbers of macros into functions? (Performance etc.) Thanks, Tracy Camp
Re: OpenSSL and LSB
IBM uses OpenSSL internally for crypto, though we have our own SSL library. To make it consumable for IBM products we did most of the things you've mentioned in a wrapper layer and provide essentially only the EVP layer to IBM applications. Anything where we've needed access to the underlying data more generally we've added accessor functions, there's no noticeable performance impact. Where this has been needed it's generally been for something that's relatively slow anyway - i.e. Diffie-Hellman. The opaque data types have generally been fine for normal use, the only times we've been forced to cheat and peek under the covers has been when we've been coding up some of the NIST test cases. The only thing that's been really inconvenient to deal with in this way is ASN.1 parsing, and again that's generally only been when writing test cases or working around bugs - i.e. the recent PKCS#1.5 padding problem. 1) First and most fundamentally: Is the general idea of attempting to only incorporate an API subset into the LSB ABI a good or acceptable one? LSB ABIs typically do not include every last interface of most libraries that are standardized either because the non-included APIs are really library internals, the API is not stable or is only useful in specialized cases. In this case the APIs I didn’t include are as far as I can tell only useful in specialized cases, or have higher level APIs that provide the same functionality (EVP vs. DES). 2) Is my concern about API stability going forward using fully typed structures unfounded? 3) Are there concerns about converting large numbers of macros into functions? (Performance etc.) 1) EVP seems sufficient with a few small tweaks. OpenSSL's SSL layer may not yet sit cleanly on that but it could. 2) Opaque data structures is the way to go in our experience. Some apps. may claim they need more, but the same can be said of the data structures within the kernel. 3) ASN.1 is the only obvious problem I've noticed, performance is unlikely to be an issue. There are a couple of other issues you may need to deal with: Callbacks: everyone +dog setting the threading and memory allocation callbacks doesn't work where you have multiple independent shared libraries using OpenSSL within the same process. Various parts of the application end up stealing one anothers callbacks and/or crashing because the shared library where the callbacks point was unloaded while some other part of the application was using OpenSSL. I'd guess you'd hit this if you started using OpenSSL in a big way within Gnome or KDE. We just set them to a sane default when the shared library containing our wrapper code gets loaded and ignore further attempts to set them, this probably needs to be a build option. We also added namespacing to OpenSSL to avoid crashes when customer application code linked with other versions of OpenSSL ended up in the same process - for LSB you may not need that since the objective is to have everyone use one common version. Cheers Peter Peter Waltenberg Camp, TracyX E [EMAIL PROTECTED] tel.com To Sent by: openssl-dev@openssl.org owner-openssl-dev cc @openssl.org Subject OpenSSL and LSB 26/10/06 05:53 AM Please respond to openssl-dev I’d like to re-start some discussion about including OpenSSL in LSB (acronym expansion: Linux Standards Base see: http://www.freestandards.org ). There is apparently general interest in seeing OpenSSL in LSB both for its SSL functionality as well as its utility as a general cryptographic library. In particular applications that wish to be LSB compliant would benefit from security bug fixes. Currently applications that use OpenSSL and wish to be LSB compliant are forced to statically link OpenSSL and in theory at least, may need to re-release binaries for each OpenSSL release (or at least evaluate if a re-release
