Re: Compiling static vs. dynamic and building a universal binary
Ack! I see there are actually a number of responses I somehow missed. Pardon my error. ~~RMC On Fri, Jul 18, 2008 at 12:39 PM, Richard Conlan [EMAIL PROTECTED] wrote: Anybody have any response on this? Or is there a better list to ask? ~RMC On Tue, Jul 15, 2008 at 5:44 PM, Richard Conlan [EMAIL PROTECTED] wrote: Greetings! So, I have a handful of relatively esoteric questions. Say I have binaryX that will use both libcrypto and libssl. 1) Is it dangerous to statically link the one and dynamically link the other? what if the versions mismatch? 2) Does anybody know the version of OpenSSL included by default on the various versions of OSX? 3) I've tried building a version of OpenSSL for ppc7400 + i386 according to: http://developer.apple.com/opensource/buildingopensourceuniversal.html. Are there additional steps I could be doing to optimize the build further, especially that would shrink the additions to the final binaryX statically linked against the Universal libcrypto.a? Thanx! ~RMC
Re: Compiling static vs. dynamic and building a universal binary
[EMAIL PROTECTED] wrote on 07/17/2008 12:16:18 PM: Has this ever been (in recent history) an issue within a given release branch? Ie. has 0.9.8(n+1) ever broken apps that were running ok against 0.9.8n? 0.9.8x is of course not backwards compatible with 0.9.7y, and 0.9.9 will not be backwards compatible with 0.9.8 either. But that's why (reputable) distros allow these branches to coexist and be upgraded independently. I had one yesterday. I was linking with 0.9.8d, but I incorrectly had 0.9.8a include files in my path. This unfortunately simulated compiling with 'a but then an upgrade to 'd. Almost everything worked, but HMAC core dumped deep in my code. ... a plea to make as many new functions as you like, but freeze the existing ones. I don't even like changes outside a release branch. I don't want my 0.9.8 apps to break because some new one installed 0.9.9. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Compiling static vs. dynamic and building a universal binary
On Thu, Jul 17, 2008 at 6:16 PM, Geoff Thorpe [EMAIL PROTECTED] wrote: On Wednesday 16 July 2008 14:56:26 Kenneth Goldman wrote: [EMAIL PROTECTED] wrote on 07/16/2008 10:08:31 AM: 2) using static builds has a benefit: you know exactly what your [..] Is this really a drawback? Since OpenSSL updates break backward [..] Has this ever been (in recent history) an issue within a given release branch? [..] Nope, hasn't been a problem for a long time, but the question was - at least I read it that way - about using crypto+ssl as a [possible] mix static and dynamic and a risk analysis was requested. Sorry I didn't tack percentages to it, as some of the risks are less than others, but if the message came across that mixing parts static, parts dynamic is not the coolest thing to do (you can build both crypto and ssl as static /or/ dynamic libs and use them, no sweat, but please use the same style for both; you won't get a surprise this year, but if you have customers (like I have on Windows) who install other packages too, which happen to overwrite/update 'your' OpenSSL DLLs, well, you just /might/ be in for a little surprise functionality-wise (that binary compatibility is all hunky dory at the same time) - those tiny little surprises that are damn hard to debug over an email line and neigh impossible to reproduce. Risk level: LOW. (see the time difference between 0.9.5 and 0.9.9 in my example) Personally, I don't favor static or dynamic, both have their merits. It's just that mixing static linking crypto and dynamic linking ssl gives me goosebumps. Don't put too much into this, I come from another world and it's just that I've learned the hard way to keep either all my libraries as is, no touching, or, if you want 'to stay abreast' (and with crypto you should, is my belief) at least keep all stuff from a single vendor in sync. This is not about OpenSSL: the hard knocks came from other places (e.g. at really bad nights I vividly remember issues with Microsoft MFC42 dlls; all the same yet some are more same than others. I'm glad OpenSSL performs way beyond /that/ quality level.) Mea culpa if my response upset anyone. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Compiling static vs. dynamic and building a universal binary
Anybody have any response on this? Or is there a better list to ask? ~~RMC On Tue, Jul 15, 2008 at 5:44 PM, Richard Conlan [EMAIL PROTECTED] wrote: Greetings! So, I have a handful of relatively esoteric questions. Say I have binaryX that will use both libcrypto and libssl. 1) Is it dangerous to statically link the one and dynamically link the other? what if the versions mismatch? 2) Does anybody know the version of OpenSSL included by default on the various versions of OSX? 3) I've tried building a version of OpenSSL for ppc7400 + i386 according to: http://developer.apple.com/opensource/buildingopensourceuniversal.html. Are there additional steps I could be doing to optimize the build further, especially that would shrink the additions to the final binaryX statically linked against the Universal libcrypto.a? Thanx! ~RMC
Re: Compiling static vs. dynamic and building a universal binary
[EMAIL PROTECTED] wrote on 07/16/2008 10:08:31 AM: 2) using static builds has a benefit: you know exactly what your application is going to get SSL-wise: you will be sure it is installed on the target system because you brought it along. The drawback is that you have to provide your own update path to track security fixes -- that is compared to an OS/platform where others do the tracking and updating for you (e.g. active Linux distros with dynamic libraries). Is this really a drawback? Since OpenSSL updates break backward compatibility, there a problem as well with dynamic libraries. Someone installs an update, possibly automated, possibly the install of another program, and suddenly you application fails in strange ways. [... my quixotic plea for NEVER breaking backward compatibilty] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Compiling static vs. dynamic and building a universal binary
On Wednesday 16 July 2008 14:56:26 Kenneth Goldman wrote: [EMAIL PROTECTED] wrote on 07/16/2008 10:08:31 AM: 2) using static builds has a benefit: you know exactly what your application is going to get SSL-wise: you will be sure it is installed on the target system because you brought it along. The drawback is that you have to provide your own update path to track security fixes -- that is compared to an OS/platform where others do the tracking and updating for you (e.g. active Linux distros with dynamic libraries). Is this really a drawback? Since OpenSSL updates break backward compatibility, there a problem as well with dynamic libraries. Someone installs an update, possibly automated, possibly the install of another program, and suddenly you application fails in strange ways. [... my quixotic plea for NEVER breaking backward compatibilty] Has this ever been (in recent history) an issue within a given release branch? Ie. has 0.9.8(n+1) ever broken apps that were running ok against 0.9.8n? 0.9.8x is of course not backwards compatible with 0.9.7y, and 0.9.9 will not be backwards compatible with 0.9.8 either. But that's why (reputable) distros allow these branches to coexist and be upgraded independently. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Compiling static vs. dynamic and building a universal binary
Geoff Thorpe [EMAIL PROTECTED] writes: [...] Has this ever been (in recent history) an issue within a given release branch? Ie. has 0.9.8(n+1) ever broken apps that were running ok against 0.9.8n? 0.9.8x is of course not backwards compatible with 0.9.7y, and 0.9.9 will not be backwards compatible with 0.9.8 either. But that's why (reputable) distros allow these branches to coexist and be upgraded independently. I suspect an application using PKCS12_create and passing a non-NULL name will segfault on 0.9.8h. (I confess I've not actually tried that---I've only tried with an application built against 0.9.8h.) However, I guess (presuming the problem really exists, and I didn't mess up somehow) that's more a bug than a binary incompatibility. 0.9.8g (IIRC) broke source compatibility in the sense that at least some C++ compilers don't accept some of the headers. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Compiling static vs. dynamic and building a universal binary
On Thursday 17 July 2008 12:26:33 Bruce Stephens wrote: Geoff Thorpe [EMAIL PROTECTED] writes: [...] Has this ever been (in recent history) an issue within a given release branch? Ie. has 0.9.8(n+1) ever broken apps that were running ok against 0.9.8n? 0.9.8x is of course not backwards compatible with 0.9.7y, and 0.9.9 will not be backwards compatible with 0.9.8 either. But that's why (reputable) distros allow these branches to coexist and be upgraded independently. I suspect an application using PKCS12_create and passing a non-NULL name will segfault on 0.9.8h. (I confess I've not actually tried that---I've only tried with an application built against 0.9.8h.) However, I guess (presuming the problem really exists, and I didn't mess up somehow) that's more a bug than a binary incompatibility. yep, bugs are why 0.9.8x gets followed by 0.9.8y :-) 0.9.8g (IIRC) broke source compatibility in the sense that at least some C++ compilers don't accept some of the headers. Right, which would also be a bug. But in fact, the original question was about binary compatibility - ie. the analogous question would not be whether a C++ app could be built against 0.9.8g headers, but whether the pre-built app can link and run against 0.9.8g shared-libs *if* it had been built against 0.9.8f headers (and had been running ok with 0.9.8f shared-libs, aside from the bugs that 0.9.8g is supposed to fix). Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Compiling static vs. dynamic and building a universal binary
Geoff Thorpe [EMAIL PROTECTED] writes: [...] But in fact, the original question was about binary compatibility Sure, and I've no reason to believe binary compatibility has been broken in 0.9.8. (Though it's something I've never really cared about.) [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Compiling static vs. dynamic and building a universal binary
On Tue, Jul 15, 2008 at 11:44 PM, Richard Conlan [EMAIL PROTECTED] wrote: Greetings! So, I have a handful of relatively esoteric questions. Say I have binaryX that will use both libcrypto and libssl. 1) Is it dangerous to statically link the one and dynamically link the other? what if the versions mismatch? The risk there is that 1) API enhancements may appear over time. It does not happen all that often, but there's one that I have seen: the ASN.1 interface (macros, etc.) has been greatly improved since 0.9.5. Using a libcrypto 0.9.5 definitely wouldn't work with a libssl 0.9.9. 2) using static builds has a benefit: you know exactly what your application is going to get SSL-wise: you will be sure it is installed on the target system because you brought it along. The drawback is that you have to provide your own update path to track security fixes -- that is compared to an OS/platform where others do the tracking and updating for you (e.g. active Linux distros with dynamic libraries). 2) Does anybody know the version of OpenSSL included by default on the various versions of OSX? Sorry, no. 3) I've tried building a version of OpenSSL for ppc7400 + i386 according to: http://developer.apple.com/opensource/buildingopensourceuniversal.html. Are there additional steps I could be doing to optimize the build further, especially that would shrink the additions to the final binaryX statically linked against the Universal libcrypto.a? I scanned the page you referred to and indeed there's more you can do if you desire to reduce your disc footprint when statically linking. For this, you will need to make an inventory of which crypto algorithms and protocol sections of OpenSSL you are using; OpenSSL has several configurable flags (often labeled OPENSSL_NO_...) which will remove certain crypto algorithms, SSL protocol versions and other subsections (e.g. hardware crypto engines) at compile-time. HTH -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
