View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002966 | unreal | ircd | public | 2006-06-10 02:52 | 2006-09-28 15:49 |
| Reporter | buildsmart | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | PowerPC and Intel | OS | Mac OS X/Darwin | OS Version | 10.4.6/8.6.0 |
| Product Version | 3.2.4 | ||||
| Fixed in Version | 3.2.6 | ||||
| Summary | 0002966: libz and libssl version issue | ||||
| Description | When ever my OS vendor updates either of these libraries unreal reports the version descrepency forcing a rebuild of unreal. Would it be possible to have a disable option during configure or utilize bundled sources to create static libraires of these two problematic libraires to avoid this issue? | ||||
| Additional Information | I've managed to compile in dual architecture for Mac OSX/Darwin (Intel/PowerPC), I've modified the configure script to look for libcares and libtre in the standard /usr/lib, /usr/local/lib and /usr/local/unreal/lib and skip building these and use the installed ones which hasn't hurt performance but does reduce the overall size of the unreal binaries. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
What you did with c-ares and all is entirely unsupported by us, just so you know that. I'll leave the bugreport for the rest, I need to look into when exactly lib X is binary incompatible and when not, anyway ;p. (In the past OpenSSL always called the shared lib stuff unsupport or experimental, so that wasn't exactly helpful). I'll have to mail both authors/developers to get a proper position from them. Could you past the messages you get? (so we can see the difference in versions) |
|
|
[!!!] OpenSSL version mismatch: compiled for 'OpenSSL 0.9.7b 10 Apr 2003', library is 'OpenSSL 0.9.7i 14 Oct 2005' [!!!] Zlib version mismatch: compiled for '1.2.2', library is '1.2.3' [!!!] Header <-> Library mistmatch can make UnrealIRCd *CRASH*! Make sure you don't have multiple versions of zlib and openssl installed (eg: one in /usr and one in /usr/local). And, if you recently upgraded them be sure to recompile Unreal. Note: Saving the static libraries of c-ares and tre is not a support issue, keeping these static libraries just means that they can be used by other apps. While repeatedly building the same version it makes no sense to waste time rebuilding these two libraries if they never change and neither zlib or openssl are compiled into these libraries. Saving these libraries also has no effect on the unreal binaries, they are static and get compiled into the the unreal binaires. Developmentally, perhaps it might be a consideration to build these libraries as shared and link them into unreal rather than compile them into unreal but only compile them if they are not already installed and available. |
|
|
The point behind 90% of the zlib and openssl lib updates are security issues. Distributing libopenssl and zlib with Unreal would just serve to require MORE updates from the Unreal crew to keep up with those security issues. I know my vote likely isn't worth anything, but I'd veto this. The only reason to even CONSIDER distributing your own copies is a) if security isn't a major issue b) you need to fix 'bugs' in the official versions. c) (sub point a) your release cycles are so slow that you might miss whole major ABI changes in the SSL libs (like 0.9.6 -> 0.9.7 -> 0.9.8). For the most part, minor (lettered releases) don't cause binary differences shouldn't crash. However the openssl devs won't ever promise that. |
|
|
The point to a prebuilt binary is to aid installation and configuration for others by standardizing the installation parameters thus making any trouble-shooting easier and yes, security is an issue when an exploit is determined to reside in libssl/libcrypto. This has nothing to do with distributing a personal build of the software, my own personal copy has been reworked entirely and barely ressembles the source distributed by the unreal team however, I cannot utilize this implementation for mass disctribution without being solely responsible for it. This doesn't negate the issues with libz and libssl/libcrypto when the OS vendor offers a security update which updates these libraries on a minor revision level such as 0.9.7a -> 0.9.7i or 1.2.2 to 1.2.3. As a temporary solution, I've made static libs of these offending libraries and built using them until a more suitable solution is available to determine when an update actually needs to occur rather than when OpenSSL changes from 0.9.7g to 0.9.7i. These binaries shouldn't suffer these messages since the libraries themselves ar embedded however I'd be disappointed that it does complain if the headers files are updated with the dynamic libraries which are never linked to the binary. This has a drawback that any security updated in these libraries force a binary rebuild since these are not linked statically so I think another method needs to be utilized to determine what is acceptable in a library update and what is not. Currently, I've been forced to use zlib1.2.3 and openssl 0.9.7b static libraries to avoid these offending messages but this prevents the binary from taking advantage of the security update if it's compatable so to have the unreal crew to fix these checks for the minor version changes and adjust the build revsion code to reflect this specific revision to aid in support would be a somewhat acceptable solution since they would know what versions of libssl and zlib would be incompatable with version unrealircd v3.2.4. Apple has been known to apply patches to correct specific security issues when build issues of updated software occurs (such as OpenSSL) until such time that the build issue can be resolved yet a failure is gauged against the installed version number and not against the actual security issue which may have been corrected by a vendor provided patch. In the case of OpenSSL, since the unrealircd version will be 3.2.4 (untill a new stable is released), updating of this library in the minor revision level shouldn't cause any crashes provided the same API/functions are available and as far as I know, the functions in 0.9.7b exist in 0.9.8b and as noted on the openssl site, are mailnly compatibility fixes. In the case of zlib, for the most part have been backwards compatible so when a newer version is being linked dynamically it shouldn't through up any flags of a version mismatch if the update is solely to resolve a security issue such as the 1.2.2 to 1.2.3 change. The thought of having to rebuild and update a binary everytime one of these libraries is updated makes no sense yet I do understand the need to do it when a serious security issue/exploit is present and the library is incompatable but since the library is linked dynamically, updating the openssl library should resolve the security issue without the need to rebuild unrealircd (since it will be basically the same binary) unless it's incompatable and crashes it and I can't expect the unreal crew to guarantee it wont so there has to be some leniency provided to allow an acceptable update of dynamic linked libraries. I also realize that expecting support from the unreal crew is unrealistic since few have (if any) any Mac OSX experience or access to a machine sporting the OS. These static libs aren't distributed with the binary product since they become part of the binary itself and the libs are no longer required for distribution. Standardizing the binary/runtime paths used in the installation makes it easier to locate binaries, configuration and module files because these locations will be the same in all Mac OSX installations. /usr/local/unreal/bin <- for applications and scripts /usr/local/unreal/modules <- for modules /etc/unreal <- for configuration files /System/Library/launchDaemons <- for startup I have absolutely no problems with providing basic configuration support for this software as I am familiar with the environment and it's caveats and since I will be responsible for providing the binaries and yes, Apple's release cycles are slow. I do have a little fore-knowledge of when these libraries are to be updated so if a rebuild is required I'll be the first to know but since I have to use the stable releases in the distribution I want to ensure that what is being provided is going to be stable in all senses, continual log warnings of zlib or openssl version changes that fix security issues doesn't make a released software package look very stable unless you're conceeding that unrealircd isn't stable or dependable which I'd find hard to believe since I've run the same software (3.2.3) without issue for more than 11 months at which time I updated to 3.2.4. |
|
|
I'll get to work on inventing a crystal ball, and as soon as it's done (coming right after Duke Nukem Forever), It'll let you know in advance whether an OpenSSL release will break any one particular app on a particular platform. It'll even include all future security patches, so you'll only have to patch once! Please be aware that your ability to extract the patches from the crystal ball may be affected by spherical distortions and minute variations in the timestream. The simple fact is that the Unreal coders will have a terrible time knowing in advance what will and won't happen, whether a particular patch might break something, etc. They could try making it only complain if it's a major release, and not a lettered release. But there's no promise from the OpenSSL devs that those releases might not break anything. |
|
|
I don't need to know when it will break, I will know before everyone else. What I'm trying to resolve is uncessary rebuilding just because a minor revision changed and messages in logs that will freak out end users who will flood me with e-mail because they're seeing message they don't understand. These libraries are linked dynamically, when the ABI for OpenSSL has changed making it incompatable with unreal it will more than likely also require an OS update since OpenSSL is part of the core OS. We are currently at 0.9.7i, I know on the next update we will be at 0.9.8b and the ABI will be pretty much the same with regards to the functions being used by the unrealircd binary. In the case of OpenSSL, it would make sense to only report a potential problem if a minor version level changes and not a revision level change and the same can probably be said about zlib. Perhaps an option to allow a leanient revision level change or only output this information in debug mode. I'm now examining the section of code that tests these versions to see what modification would be required to relax these tests a little. I believe that some kind of test should be performed but by using static libraries for these critical libraries a rebuild is required and may not be ncessary unless a vulnerability exists when the library is compatable. So as it currently stands, OS updates wont affect unrealircd however it also wont/can't take advantage of any security updates which may be applied to the existing OpenSSL library that my OS vendor provides so in a sense, a vulnerability can be build in and go un-noticed for an exceptional period of time. |
|
|
Thanks for your input tabrisnet. Indeed, so far I've always heard the openssl guys can't tell (and don't seem to care either) if a new version breaks binary compatability. For zlib I'm less sure, so I'll bug the author. Anyway, just to be clear: I'm not considering static libs or a disable option or anything at all. The reason I left this open is as a "investigate when exactly zlib/openssl versions are incompatible", currently we simply don't know and will warn (yes WARN!! not error!) whenever a version difference is detected in the compiled version and the shared library, and set a flag. This is basically so users know something bad might happen, and if it crashes then we know this incompatible thingy might be the problem (or not, of course). buildsmart: I would seriously discourage the use of static libs, actually. You even know yourself why.. whenever there's a security vuln. you would have to recompile etc, while with the current Unreal system you could - especially if, like you say, you are so convinced there are no problems - simply restart unreal if it used shared libsthen the only thing you will see is a WARNING. Truth is, there might be binary compatibly problems, and truth is.. the openssl developers don't care much.. but I only know for sure that was their position for 0.9.7*, I haven't rechecked it recently (especially now we have 0.9.8*) but I wouldn't be surprised if it's still their current position. It's not so easy to maintain binary compatability, really. The only thing I remembered from previous discussion is that a suggestion was to parse the openssl version number so not to compare the full 'openssl 0.9.7x 1 Jan 2010' versionid but only the 'openssl 0.9.7x' part (so without the date), since sometimes distributions backport fixes - possibly for the main reason to keep binary compatible and safe etc for sure - and then we shouldn't complain about it. I actually thought I already did that, but looking at the source I did not. |
|
|
Yes I know that static libs for these aren't a good idea in the face of a vulnerability and this is why I'd like to use the dynamic libraries where-ever possible but as you know, end users make mountains out of mole-hills and any messages about version mismatches wreak havoc. How about considering something like: (off the top of my head but you'll get the idea) strncpy(compiledfor, OPENSSL_VERSION_TEXT, 13); strncpy(runtime, SSLeay_version(SSLEAY_VERSION), 13); this would translate "OpenSSL 0.9.7b 10 Apr 2003" and reduce it to "OpenSSL 0.9.7" and would allow any of the 0.9.7x variants to run without throughing up the warning. I did test from 0.9.7b to 0.9.8a (ignoring the warning) using dynamic libraries and I ran each successive build for a couple of days with no crashing just to be sure. I have no problems doing the recompile when required and think that on a version change it would be wise to recompile just in case, then provide the updated package with the OS software update. If you want to add version information to reflect a Macintosh build with these changes I'd have no issue with that but I don't want to drop the test because it would be unwise to do so and the reasons are obvious. |
|
|
Because it might crash anyway? Now we'll get a new set of bugreports "UnrealIRCd crashes for NO REASON </whine>" We track it down, and OpenSSL changed, broke their install, etc. No win situation. |
|
|
Thought a little more about the test method: if (!strncasecmp(compiledfor, runtime, 13)) might be better. This is where you are wrong, if and when OpenSSL crashes unrealircd, I'll have a week minimum to build a new binary using the updated OpenSSL library and submit it for distribution with the updated libraries so it would be impossible for the end user to obtain the updated library without obtaining an updated unrealircd binary so your claim of exagerated crashing bug reports would be unfounded. Mention of libssl being experimental in a dynamic library is resolved by using a static library but this defeats the ability to provide a security update because the unreal software is far too paranoid to use dynamic libraires which makes absolutely no sense. Put a quick patch together to denote this particular 3.2.4 build, I'll apply it and every time I'm contacted about this software, I'll test the issue and if it's not related to an updated OpenSSL, curl or zlib library issue (regardless of cause) I'll directly forward them here so you can deal with their issues and I'll only concern myself with updates to the binary when OpenSSL, curl and zlib libraries are updated. Most Mac users can't build any software, they can't run anything without some kind of GUI, this has been designed and implemented for use with unreal software, I can leave it as it is, provide the initial binary and let the users contact you directly as well leaving me nothing to do but wait for 10.5 so I can then generate the initial package for it and you can then deal with the user and updating his software or teaching him to do it. Now, I realize that unreal depends on third party libraries which it can't be responsible for, the current method employed is overly paranoid at the very least all I'm trying to do is get some kind of relaxed test or change so these messages are not displayed to the average user but if you want to do my work for me by all means, I'll let you do it, otherwise, I'd appreciate it if you could work with me a little on this issue since it is not my intention to flood you with unnecessary bug reports but if this software is released with these messages I can pretty much bank on you being flooded with garbage support requests and bug reports. |
|
|
You must be thinking of an out-of-tree patch. At which point, IT'S NOT A RELEVANT BUG REPORT HERE! Either such a patch gets into the official tree, and thus potentially affects others... or it never does and thus it's not even a germane point. It remains trapped within your own little private world which doesn't affect us and we never support you. For this idea, you don't need us. You can just patch the compare function yourself, and if anybody who uses your build bugs us, we just tell them to complain to you. Simple, no? |
|
|
That's a good point. We should probably insist that you specially tag your version so we know. We certainly can't afford to support your customized version. I slightly patch my ircd, but I tend to know better than to bug the ircd devs about my patches. |
|
|
buildsmart: you keep insisting on the "IT IS TEH COMPATIBLE" thing, but really you cannot know that for sure. I (and tabrisnet) have repeatidly said this is not the case, and even the openssl docs state it clearly, here is the paste, though you probably still won't believe it (from 'INSTALL'): Shared library is currently an experimental feature. The only reason to have them would be to conserve memory on systems where several program are using OpenSSL. Binary backward compatibility can't be guaranteed before OpenSSL version 1.0. If you just keep ignoring our info then it has not much use continueing this discussion. I don't like binary packaging at all, which is why I'm glad for example debian does not ship with an unrealircd package (other coders disagree on this btw). I don't see the problem with compiling (on *NIX) anyway, you just run ./Config and make (windows is a different thing, seeing all the work to get a proper build environment). If you ask me, if you cannot do that, you shouldn't be running an IRCd... So I'm glad there are not really binary packages (which also have other problems, like.. delayed releases). If I'm not mistaken FreeBSD ports solves it quite nicely, since it rebuilds Unreal whenever openssl needed to be rebuilded as well. But I'm not a *BSD guy so I don't know the details :P. I don't understand it either, you modify all kinds of things, but for you changing this version thingy is not an option?. Your version is not supported, I already said that. So you should follow the general procedure anyone should take with modified code (and which tabrisnet and other regular bugcontributors follows quite well), which is: whenever a bug appears, judge whether it's because of the modifications or not, don't let others (or yourself) bug us first, and if you are unsure if it's the modifications (eg: crash with heap corruption, where you cannot see the direct cause of the crash), then run an official release to see if you can reproduce it. [as outlined in one of our faq entries] I'm still considering keeping this entry open until I checked with the zlib guys to see what their position is. Seems the openssl ones is still the same now I checked latest release INSTALL file (the note I pasted is still there). Naturally, the reason we introduced all these checks is because they actually caused several bugreports and weird issues, it's not like we add this stuff just to annoy people or anything.... to the contrary. It is also a warning and not an error for a reason as well. |
|
|
I am aware of the backward compatability statement but within a lettered patch level the library should be compatable and I can't find an instance where it isn't and yes I realize there are no gaurantees on this. A build environment is not provided with the Mac OS X installation, most Mac users have no clue how to build and install any software manually as the OS vendor does this for them. This doesn't make them any less capable of managing an IRC server. It's not like you have to be a master mechanic to drive a car, it's nice if you have the knowledge As I said earlier, I can't provide a package with custom modifications without your prior written authorization permitting the use of such modification, what will be released will be your supplied code built using the stated runtime paths. I'll build it using static OpenSSL libraires since using the (experimental) dynamic libraries seems to be a concern/issue and this does remove any messages about this library being updated. This request was being made to alleviate unnecessary support requests but since we can't seem to come to some reasonable compromise on this issue, I'll set up the unreal build environment to build to your library specification and generate the initial binary from the available (unmodified) code I've already obtained. Despite your build rules, having a dynamic library of c-ares-1.2.1 may already be installed if the user has elected to install the extended DNS package and it causes this library to be linked instead of your static library, while I know how to ensure your static library is linked you will need to be aware of this potential issue when assisting other Mac OS X users. I will ensure that the initially provided build does not link to this dynamic library when configuring and setting up the unrealircd build environment so if you get any support requests which have this c-ares library dynamically linked you can be sure it is not a proper build and that the linked c-ares-1.2.1 is not compatable. As a side note, c-ares is supposed to be included in libcurl so if this library is linked there shouldn't be any need to build c-ares but I haven't looked into it any further than it is built using it and might be something worth looking into. The moment that curl or zlib is updated or any other issues bring them for support, I'll direct them here to file bug reports and obtain support from you and remove myself entirely from the support request loop and reduce my activities to providing the initial build which will be compliant at the time of distribution. |
|
|
Another point of view to the issue. Let me cite openssl/opensslv.h file: /* The macros below are to be used for shared library (.so, .dll, ...) * versioning. That kind of versioning works a bit differently between * operating systems. The most usual scheme is to set a major and a minor * number, and have the runtime loader check that the major number is equal * to what it was at application link time, while the minor number has to * be greater or equal to what it was at application link time. With this * scheme, the version number is usually part of the file name, like this: * * libcrypto.so.0.9 * * Some unixen also make a softlink with the major verson number only: * * libcrypto.so.0 * <...> * So, here's the way it works here: first of all, the library version * number doesn't need at all to match the overall OpenSSL version. * However, it's nice and more understandable if it actually does. * The current library version is stored in the macro SHLIB_VERSION_NUMBER, * which is just a piece of text in the format "M.m.e" (Major, minor, edit). <...> #define SHLIB_VERSION_NUMBER "0.9.8" ok, it doesn't say explicitly that all 0.9.8* versions will be binary compatible. But it knows that loader will not complain if user's program will be compiled with 0.9.7 and at the load time there will be 0.9.8 (strictly speaking, it says that any 0.9.7+, 0.10.* and so on will be used). More, it do not make steps to prevent this (by using versions 90801.0). Why then we should be afraid? Yes, I know disclaimer about binary compatibility. But in the license it also says it does not necesarily performs SSL-stuff at all ;-) [<...>ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. <...>] Yet we use this library. |
|
|
Because *WE* do care about our users! Amazingly as it sounds... In your hypotethical "compiled for 0.9.7, but the 0.9.8 .so loaded" it would *CRASH*. Hopefully it will crash, that is, because it could also cause severe memory corruption, which is even more evil. As I said in my previous post, they don't do binary compatability at all and shared library support is still "experimental". The only reason this issue is still open is because of zlib, not openssl. |
|
|
And there we go: The application can compare zlibVersion and ZLIB_VERSION for consistency. If the first character differs, the library code actually used is not compatible with the zlib.h header file used by the application. So zlib 1.x should be compatible with all 1.*, and 2.x with 2.y etc. Glad at least one library has a brain :P. The check has been updated to reflect this statement in 32* and 33*. This bugreport can be closed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-06-10 02:52 | buildsmart | New Issue | |
| 2006-06-10 06:50 | syzop | Note Added: 0011941 | |
| 2006-06-10 06:51 | syzop | Note Edited: 0011941 | |
| 2006-06-10 11:00 | buildsmart | Note Added: 0011942 | |
| 2006-06-14 15:24 | tabrisnet | Note Added: 0011952 | |
| 2006-06-14 23:41 | buildsmart | Note Added: 0011953 | |
| 2006-06-15 03:20 | tabrisnet | Note Added: 0011954 | |
| 2006-06-15 17:00 | buildsmart | Note Added: 0011960 | |
| 2006-06-15 17:48 | syzop | Note Added: 0011961 | |
| 2006-06-15 23:55 | buildsmart | Note Added: 0011963 | |
| 2006-06-15 23:58 | tabrisnet | Note Added: 0011964 | |
| 2006-06-16 01:18 | buildsmart | Note Added: 0011965 | |
| 2006-06-16 01:31 | tabrisnet | Note Added: 0011966 | |
| 2006-06-16 01:41 | tabrisnet | Note Added: 0011967 | |
| 2006-06-16 06:20 | syzop | Note Added: 0011969 | |
| 2006-06-16 09:11 | buildsmart | Note Added: 0011971 | |
| 2006-09-28 15:04 | monas | Note Added: 0012455 | |
| 2006-09-28 15:40 | syzop | Note Added: 0012457 | |
| 2006-09-28 15:49 | syzop | Status | new => resolved |
| 2006-09-28 15:49 | syzop | Fixed in Version | => 3.2.6 |
| 2006-09-28 15:49 | syzop | Resolution | open => fixed |
| 2006-09-28 15:49 | syzop | Assigned To | => syzop |
| 2006-09-28 15:49 | syzop | Note Added: 0012458 |
