Symbol ares__close_sockets@@ (32-bit UNIX System V ABI Intel 80386) present 2 times libcares /usr/bin/unrealircd
When compiling, unrealircd appears to also compiles its own copy of dev-libs/tre. It extracts tre from a targz, so it's API is probably compatible with the system dev-libs/tre.
Created attachment 178556 [details, diff] patch to net-dns/c-ares providing function unrealircd wants see http://www.freebsdsoftware.org/dns/c-ares.html : unrealircd has a small patch against c-ares to add a special ares_get_config function that unrealircd uses. The following patch was grabbed from Unrealircd's current sources (which packages c-ares-1.6.0 which isn't in portage, but I'm pretty sure it'll work with c-ares-1.5*) compared with a copy of c-ares-1.6.0. This patch works fine against c-ares-1.5.3 and allows it to install. I'll try to test using unrealircd against a patched c-ares. However, is this something that should be pushed upstream or is unrealircd imposing an interface upon c-ares that c-ares doesn't want? I got my system so that ldd $(which unrealircd)'s output includes the following two lines, I'll submit my other patches tomorrow: libtre.so.4 => /usr/lib64/libtre.so.4 (0x00007f453f15f000) libcares.so.2 => /usr/lib64/libcares.so.2 (0x00007f453ef4f000)
Created attachment 178629 [details, diff] hackedly has unrealircd compile against external tre
Created attachment 178631 [details, diff] has unrealircd compile against external c-ares, applied after unrealircd-system-tre.patch I'm not sure how to go about talking to upstream about the issue of included libraries, so I have these patches in my overlay. Unrealircd compiled. However, it segfaults when I run it inside of c-ares's code. The version of c-ares included in the tarball for the current Unrealircd is 6.0 - maybe this is the issue? I'll try to test this later.
Created attachment 178657 [details, diff] unrealircd compiles against external c-ares, fixes callback prototype, apply after unrealircd-system-tre.patch The reason I got segfaults was that I had ignored the following output while compiling: res.c: In function 'unrealdns_doclient': res.c:203: warning: passing argument 5 of 'ares_gethostbyaddr' from incompatible pointer type res.c:207: warning: passing argument 5 of 'ares_gethostbyaddr' from incompatible pointer type ... See c-ares's documentation: the unrealircd code was not correctly defining a callback function. I have no idea how unrealircd worked with the bundled library, because I thought that patch 178556 (c-ares-unrealircd.patch) was the only difference between the system c-ares and the bundled c-ares. I now have unrealircd up at ohnopublishing.net and it's linking to the system c-ares (which is patched) and tre. :-) btw, c-ares-unrealircd.patch is essentially the file found at http://bugs.unrealircd.org/view.php?id=3671 . In fact, running ediff showed that only the udiff-headers and whitespace differed between the path I made and the one used by unrealircd.
Because of bug 255408 I think this is now security issue.
Created attachment 179174 [details, diff] changes I made to unrealircd-3.2.7-r2.ebuild I'm not sure if all of the changes I made were necessary, but I think trying to remove any distributed files from extras/ would make a good QA check for creating ebuilds for new versions of unrealircd.
(In reply to comment #6) > Because of bug 255408 I think this is now security issue. > unrealircd-3.2.8 (see bug 260806) bundles c-ares-1.6.0 instead. I've filed a bug on unrealircd for its usage of internal tre ( http://bugs.unrealircd.org/view.php?id=3842 ). It's been sitting there a few weeks and not received any attention.
Comment on attachment 178556 [details, diff] patch to net-dns/c-ares providing function unrealircd wants I found out that patching c-ares is wrong. c-ares has a native function which UnrealIRCD should use. http://c-ares.haxx.se/ares_save_options.html describes a the function unrealircd should use instead.
Current unrealircd (3.2.9) is unaffected by this bug. It both bundles a newer copy of c-ares-1.7.3 and supports compiling against a system-installed c-ares (which is what the ebuild specifies).
(In reply to comment #6) > Because of bug 255408 I think this is now security issue. Then rating as B3. GLSA vote: no.
GLSA Vote: no. Closing noglsa.
