It should use the system copy instead.
It does, doesn't it?
ehm, i was looking at the wrong log file
@net-mail: Do you want to fix this, or should I lastrite it? Vulnerable to CVE-2009-3736.
Created attachment 222255 [details, diff] Use system libltdl **Untested patch** epatch "${FILESDIR}"/${P}-libtool.patch rm -rf libltdl eautoreconf
I just had a look at this and think this bug is invalid. authdaemon looks to me as the only part of courier-authlib using libltdl and on my system, installed with the in-tree ebuild without any patches, it's linked against /usr/lib64/libltdl as it should: hanno@laverne /usr/lib/courier/courier-authlib $ ldd authdaemond linux-vdso.so.1 => (0x00007fff240a8000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007f69a2b37000) [...] So it seems courier-authlib bundles libltdl, but it doesn't use it if it's on the system - pretty fine imho. Correct me if I'm wrong.
Created attachment 222291 [details] build.log You might be right, from build.log I can see only authdaemond linking to -lltdl and objdump -o confirms it's linked to system copy of libltdl.so.7. The package builds and configures a copy of libltdl though, a bit ugly... but it never uses it
(In reply to comment #6) > and objdump -o confirms it's linked to system copy of libltdl.so.7. sorry, -p
“nm -D --only-defined” over the file, does it show libltdl functions? If so it's linking *and* bundling.
(In reply to comment #8) > “nm -D --only-defined” over the file, does it show libltdl functions? If so > it's linking *and* bundling. > Doesn't look like it... $ nm -D --defined-only /usr/lib64/courier/courier-authlib/authdaemond 0000000000403760 R _IO_stdin_used 00000000006051ec A __bss_start 00000000006051d8 D __data_start 0000000000403670 T __libc_csu_fini 0000000000403680 T __libc_csu_init 00000000006051ec A _edata 0000000000607260 A _end 0000000000403748 T _fini 00000000004014c8 T _init 00000000004018a0 T _start 0000000000605200 B courier_authdebug_login_level 00000000006051d8 W data_start 0000000000403780 R lt__PROGRAM__LTX_preloaded_symbols 0000000000403630 T main 0000000000403170 T start 0000000000605208 B stderr
Okay, then it's either a false positive or (more probable considered the bug# and date) was fixed over time.
(In reply to comment #10) > Okay, then it's either a false positive or (more probable considered the bug# > and date) was fixed over time. > Heh. The date... Well, thanks both, Hanno and Diego for looking at this, let's close this then.
