This has a lesser impact on Linux than it does on some other operating systems due to the fact that Linux uses a reasonably secure search path for shared libraries and modules by default, however it can be prefixed with a user-provided LD_LIBRARY_PATH environment variable.  A Linux user could be at risk if LD_LIBRARY_PATH contains an insecure directory.

If libltdl is provided with a module.la or libfoo.la file, it will obtain the "old_library" specification from the discovered .la file and will attempt to dlopen with that name (i.e. "archive.a"); this search is done with the bare name rather than a qualified (defined) path.  This could result in applications that were carefully designed to be secure being rendered insecure.  This, however, is only a problem if a static archive was built, so libraries and applications build with --disable-static are not impacted.  On Red Hat Enterprise Linux, most static archives are only provided via -devel packages, although there are a number of notable exceptions (such as gcc, binutils, dev86, and so forth).

As well, lt_dlopen() and dl_openext() with a bare specification and without an absolute path ("module.la" or "libfoo.la") will use a reasonably secure path, but it also checks the current directory for .la files also.  dl_openext() is documented to find the module by appending various extensions: it will append .la and if it finds a .la file, it will use it, otherwise it will retry with .so, however checking the current directory is _not_ documented behaviour.

On Linux, this issue is more difficult to exploit than on some other systems, due to the default of searching a reasonably secure search path (unless LD_LIBRARY_PATH is defined).  Packages using libltdl but with no .la files are not affected.  Packages using libltdl and .la files that contain "old_library=''" are not affected.  Packages using libltdl and .la files that contain "old_library='something.a'" will do a dlopen("something.a"), which may or may not be a problem, due to the reasons outlined above.

The following packages contain embedded libltdl.  Of them, only freeradius and pspell have a dependency on libltdl.so, so the rest are not linked to the system libltdl and would likely need to be updated as well.

Results in Tag: rhel3

arts-1.1.3-2.4: (source) arts-1.1.3.tar.bz2: arts-1.1.3/libltdl/ltdl.c
compat-gcc-7.3-2.96.128: (source) libgcj-2.96.tar.bz2: libgcj/libjava/libltdl/ltdl.c
freeradius-1.0.1-2.RHEL3.4: (source) freeradius-1.0.1.tar.gz: freeradius-1.0.1/libltdl/ltdl.c
gcc-3.2.3-59: (source) gcc-3.2.3-20040701.tar.bz2: gcc-3.2.3-20040701/libjava/libltdl/ltdl.c
gcc-ssa-3.5ssa-0.20030801.48: (source) gcc-3.5ssa-20030617.tar.bz2: gcc/libjava/libltdl/ltdl.c
guile-1.6.4-8.30.1: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/guile-ltdl.c
guile-1.6.4-8.30.1: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/raw-ltdl.c
guile-1.6.4-8.30.1: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/upstream/ltdl.c
guile-1.6.4-8.30.1: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/upstream/ltdl.c.diff
ImageMagick-5.5.6-25: (source) ImageMagick-5.5.6.tar.bz2: ImageMagick-5.5.6/ltdl/ltdl.c
kdelibs-3.1.3-6.12: (source) kdelibs-3.1.3.tar.bz2: kdelibs-3.1.3/libltdl/ltdl.c
libtool-1.4.3-6: (source) libtool-1.4.3.tar.gz: libtool-1.4.3/libltdl/ltdl.c
pspell-0.12.2-16.1: (source) pspell-.12.2.tar.gz: pspell-.12.2/libltdl/ltdl.c
unixODBC-2.2.8-2.3.0.2: (source) unixODBC-2.2.8.tar.gz: unixODBC-2.2.8/libltdl/ltdl.c

Results in Tag: rhel4

arts-1.3.1-2: (source) arts-1.3.1.tar.bz2: arts-1.3.1/libltdl/ltdl.c
compat-gcc-32-3.2.3-47.3: (source) gcc-3.2.3-20040701.tar.bz2: gcc-3.2.3-20040701/libjava/libltdl/ltdl.c
freeradius-1.0.1-3.RHEL4.5: (source) freeradius-1.0.1.tar.gz: freeradius-1.0.1/libltdl/ltdl.c
gcc-3.4.6-11: (source) gcc-3.4.6-20060404.tar.bz2: gcc-3.4.6-20060404/libjava/libltdl/ltdl.c
gcc4-4.1.2-44.EL4: (source) gcc-4.1.2-20090126.tar.bz2: gcc-4.1.2-20090126/libjava/libltdl/ltdl.c
guile-1.6.4-14: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/guile-ltdl.c
guile-1.6.4-14: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/raw-ltdl.c
guile-1.6.4-14: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/upstream/ltdl.c
guile-1.6.4-14: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/upstream/ltdl.c.diff
ImageMagick-6.0.7.1-20.el4: (source) ImageMagick-6.0.7-1.tar.bz2: ImageMagick-6.0.7/ltdl/ltdl.c
kdelibs-3.3.1-11.el4: (source) kdelibs-3.3.1.tar.bz2: kdelibs-3.3.1/libltdl/ltdl.c
lam-7.1.2-15.el4: (source) lam-7.1.2-rh1.tar.bz2: lam-7.1.2-rh1/share/libltdl/ltdl.c
libtool-1.5.6-4.EL4.2: (source) libtool-1.5.6.tar.gz: libtool-1.5.6/libltdl/ltdl.c
openmpi-1.2.8-4.el4: (source) openmpi-1.2.8.tar.bz2: openmpi-1.2.8/opal/libltdl/ltdl.c
openmpi11-1.1.5-7.el4: (source) openmpi-1.1.5.tar.bz2: openmpi-1.1.5/opal/libltdl/ltdl.c
openmpi11-1.1.5-7.el4: (source) openmpi-1.1.5.tar.bz2: openmpi-1.1.5/opal/win32/generated_source/ltdl.c
unixODBC-2.2.11-1.RHEL4.1: (source) unixODBC-2.2.11.tar.gz: unixODBC-2.2.11/libltdl/ltdl.c
xmlsec1-1.2.6-3: (source) xmlsec1-1.2.6.tar.gz: xmlsec1-1.2.6/src/ltdl.c
xmlsec1-1.2.6-3: (source) xmlsec1-1.2.6.tar.gz: xmlsec1-1.2.6/src/xmlsec-ltdl.c

Results in Tag: rhel5

arts-1.5.4-1: (source) arts-1.5.4.tar.bz2: arts-1.5.4/libltdl/ltdl.c
compat-gcc-32-3.2.3-61: (source) gcc-3.2.3-20040701.tar.bz2: gcc-3.2.3-20040701/libjava/libltdl/ltdl.c
compat-gcc-34-3.4.6-4: (source) gcc-3.4.6-20060404.tar.bz2: gcc-3.4.6-20060404/libjava/libltdl/ltdl.c
freeradius-1.1.3-1.4.el5: (source) freeradius-1.1.3.tar.bz2: freeradius-1.1.3/libltdl/ltdl.c
gcc-4.1.2-46.el5: (source) gcc-4.1.2-20080825.tar.bz2: gcc-4.1.2-20080825/libjava/libltdl/ltdl.c
gcc44-4.4.0-6.el5: (source) gcc-4.4.0-20090514.tar.bz2: gcc-4.4.0-20090514/libjava/libltdl/ltdl.c
gphoto2-2.2.0-3.el5: (source) libgphoto2-2.2.1.tar.bz2: libgphoto2-2.2.1/libgphoto2_port/libltdl/ltdl.c
gphoto2-2.2.0-3.el5: (source) libgphoto2-2.2.1.tar.bz2: libgphoto2-2.2.1/libltdl/ltdl.c
ImageMagick-6.2.8.0-4.el5_1.1: (source) ImageMagick-6.2.8-0.tar.bz2: ImageMagick-6.2.8/ltdl/ltdl.c
kdelibs-3.5.4-22.el5.centos: (source) kdelibs-3.5.4.tar.bz2: kdelibs-3.5.4/libltdl/ltdl.c
lam-7.1.2-14.el5: (source) lam-7.1.2-rh1.tar.bz2: lam-7.1.2-rh1/share/libltdl/ltdl.c
libtool-1.5.22-6.1: (source) libtool-1.5.22.tar.gz: libtool-1.5.22/libltdl/ltdl.c
openmpi-1.3.2-2.el5: (source) openmpi-1.3.2.tar.bz2: openmpi-1.3.2/opal/libltdl/ltdl.c
scim-1.4.4-41.el5: (source) scim-1.4.4-20060716.tar.gz: scim-1.4.4-20060716/src/ltdl.cpp
scim-chinese-standard-0.0.2-1.el5: (source) scim-chinese-standard-0.0.2.tar.gz: scim-chinese-standard-0.0.2/src/ltdl.c
unixODBC-2.2.11-7.1: (source) unixODBC-2.2.11.tar.gz: unixODBC-2.2.11/libltdl/ltdl.c
xmlsec1-1.2.9-8.1: (source) xmlsec1-1.2.9.tar.gz: xmlsec1-1.2.9/src/ltdl.c
xmlsec1-1.2.9-8.1: (source) xmlsec1-1.2.9.tar.gz: xmlsec1-1.2.9/src/xmlsec-ltdl.c

For the second issue, lt_dlopen looking for .la files in the current working directory, it only does this if it has been given a path without a directory component e.g. "foo.la". If given an absolute path lt_dlopen will look only at that path.

Thanks for the handy list of packages in comment #10.

Oh - it is likely that some of the packages that use an embedded libltdl use an older one, we posted a patch to the libtool list with a backport of the change to branch-1-5.
http://lists.gnu.org/archive/html/libtool/2009-11/msg00065.html

Of course, if the packages work with the system libltdl, so much the better.

Upstream xmlsec1 has removed the internal copy as of Nov 7th, and due to it implementing crypto XML support, xmlsec1 should be patched to correct this as well.

unixODBC 2.2.14 uses the system libltdl, so only versions prior to that would contain the vulnerable code.

Created attachment 372311 [details]
test suite for libltdl

This test suite tests the behaviour of libltdl by using lt_dlopen() and lt_dlopenext() on a variety of filenames (thanks Tomas for the testing code).

Run before patching libtool on Fedora 11, and after, the git commits noted earlier do correct the issue and neither function looks at the $CWD for a .la file nor do they follow any specification in old_library if an .la file is loaded (which is only possible if it is in the path or a relative path is provided).

Created attachment 372312 [details]
patch to fix the flaw in libtool 2.x

For the embedded libltdl packages, we need to determine whether or not the package in question only uses the full path or if it always adds .so.  If either of these are true, then the package should not be affected by this flaw.  If .so is specified to either lt_dlopen() or lt_dlopenext(), it will never tried to load a .la file (but any extension other than .so will result in lt_dlopenext() looking for $file.la and then $file.so).  lt_dlopen() will not append a file extension when searching for $file.

To clarify the above, it's ok if .so is appended to a module name (or appended if it doesn't exist), because neither function will load a .so in the $CWD (pass a .so to either function and it always looks in the standard locations, even if a .so exists in $CWD, it is never touched).

Additional possible problematic packages (for Fedora): heartbeat, proftpd, prelude, sane, GraphicsMagick, libtunepimp, smalltalk, and redland (based on Mandriva's package list advisory: http://www.mandriva.com/en/security/advisories?name=MDVSA-2009:307 )

pspell handles this appropriately:

  PspellString libname;
  libname  = LIBDIR "/libpspell_";
  libname += name;
  libname += ".la";
  lt_dlhandle h = lt_dlopen (libname.c_str());

where LIBDIR is defined at compile-time as ${libdir}; at any rate it definitely uses the system libltdl.

libtool-2.2.6-11.fc11.2 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/libtool-2.2.6-11.fc11.2

libtool-2.2.6-17.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/libtool-2.2.6-17.fc12

libtool-1.5.26-4.fc10.1 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/libtool-1.5.26-4.fc10.1

Patch user for GraphicsMagick-1.3.7:

  http://bugs.gentoo.org/attachment.cgi?id=211756&action=view

Created attachment 375475 [details]
Local copy of Gentoo patch for CVE-2009-3736 for GraphicsMagick-1.3.7

Andreas, Rex, 

  could you schedule Fedora GraphicsMagick update with above patch?

Thanks, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

libtool-2.2.6-11.fc11.3 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/libtool-2.2.6-11.fc11.3

gcc-4.4.2-14.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gcc-4.4.2-14.fc12

This issue has been addressed in following products:

  Red Hat Enterprise Linux 3
  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 5

Via RHSA-2009:1646 https://rhn.redhat.com/errata/RHSA-2009-1646.html

While unixODBC contains a vulnerable embedded libltdl, the impact of this issue on unixODBC is low to none.

unixODBC calls lt_dlopen(), not ld_dlopentxt() and as a result a user would have to use a driver name with .la (explicitly) in order to exploit this.  All documentation for unixODBC indicates to use the full path to a .so file, so this scenario is extremely unlikely.  We do not ship .la files in unixODBC so there is no reason for a user to configure unixODBC with .la files rather than the provided (and documented) usage of .so files.

Likewise, unixODBC does not search for modules in untrusted directories, and will only look in the current directory if the specified driver is a .la file.

As a result, we do not see this issue as posing any kind of threat with regards to unixODBC and will not be issuing updated packages.

libtool-2.2.6-11.fc11.3 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

libtool-2.2.6-17.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

gcc-4.4.2-20.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

This issue has been addressed in following products:

  Red Hat Enterprise Linux 3
  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 5

Via RHSA-2010:0039 https://rhn.redhat.com/errata/RHSA-2010-0039.html

Is anyone here against filing a bug to get as many of these embedded libltdl packages using the system libltdl as possible?  I'm going through everything in Fedora right now that uses libltdl internally (weeded out those already using the system libltdl) and while most look ok to not warrant an immediate fix, I'd feel much more comfortable going forward if we could make as many of these as we can use the system library rather than an embedded copy.

Once I'm finished checking the list I'll note it here and indicate which ones should be fixed in Fedora right away (or at least that need a more expert eye to look at).

Ok, here are the results of my checking on the Fedora packages that contain embedded libltdl and have either not been fixed yet (based on a notification of a package release on this bug), or contain embedded libltdl but use the system libltdl and are therefore not affected anymore.

Fedora 11

gcc-4.4.0-4: (source) gcc-4.4.0-20090506.tar.bz2: gcc-4.4.0-20090506/libjava/libltdl/ltdl.c
  - this was updated for Fedora 12, but not Fedora 11

Fedora 11 and 12:

bochs-2.3.8-0.8.git04387139e3b.fc12: (source) bochs-2.3.8.tar.gz: bochs-2.3.8/ltdl.c
  - uses lt_dlopen() in plugin.cc but provides a full path (PLUGIN_PATH=@libdir@/bochs/plugins/
callweaver-1.2.1-2.fc12: (source) callweaver-1.2.1.tar.bz2: callweaver-1.2.1/libltdl/ltdl.c
  - uses lt_dlopen() in corelib/loader.c but provides a full path
    (cw_config_CW_MODULE_DIR=cwmoddir=${cwlibdir}/modules)
clamav-0.95.2-5.fc12: (source) clamav-0.95.2-norar.tar.bz2: clamav-0.95.2/libltdl/ltdl.c
  - uses lt_dlopen() in libclamav/others.c; will search current directory
    (searchpath=""), but also appends pre-defined suffixes to the module
    name when searching (LT_MODULE_EXT(,LIBCLAMAV_FULLVER,LIBCLAMAV_MAJORVER),.LT_LIBEXT);
    LT_LIBEXT is defined as 'a' in ltdl.c, but clamav-config.h undef's it
collectd-4.6.5-1.fc12: (source) collectd-4.6.5.tar.bz2: collectd-4.6.5/libltdl/ltdl.c
  - uses lt_dlopen() in src/plugin.c in plugin_load_file(), called by
    plugin_load() which searches a given directory for modules and attempts
    to load them, directory provided by plugin_get_dir() which returns the
    compiled in default of $pkglibdir or the specified value of PluginDir
    in the config (if set), but since it's looking for full names in a
    directory, they will contain extensions so no ext-based searching; we
    also set PluginDir to /usr/lib/collectd in /etc/collectd.conf by
    default
cpl-4.2.0-4.fc12: (source) cpl-4.2.0.tar.gz: cpl-4.2.0/libltdl/ltdl.c
  - uses lt_dlopen() in cpljava/cpl_gasgano.c; first invocation calls
    lt_dlsetseachpath() first; second uses a hardcoded .so; not sure where
    the path comes from in the first call (path is passed to the function,
    but can't see where that function is used -- from apps that call that
    function externally perhaps?)
esorex-3.6.12-4.fc12: (source) esorex-3.6.12.tar.gz: esorex-3.6.12/libltdl/ltdl.c
  - uses lt_dlopen in src/er_pluginlist.c in numerous functions; plugin_valid_file() looks ok (passed a
    full file path/name), but unsure of the rest
gambas-1.0.19-11.fc12: (source) gambas-1.0.19.tar.bz2: gambas-1.0.19/libltdl/ltdl.c
  - uses lt_dlopenext() in src/exec/gbx_library.c and src/comp/gbi.c;
    unsure if this one passes full paths/filenames or not; probably
    requires fixing
ggobi-2.1.7-3.fc12: (source) ggobi-2.1.7.tar.bz2: ggobi-2.1.7/libltdl/ltdl.c
  - uses lt_dlopen() in src/plugin.c, filename provided by
    ggobi_find_data_file(), which looks in $GOBI_HOME and the current
    directory; requires fixing
gnash-0.9.0-0.6.20090809bzr11401.fc12: (source) gnash-0.9.0.20090809bzr11401.tar.gz: gnash-0.9.0/gnash-trunk/libltdl/ltdl.c
  - uses lt_dlopenext() in libbase/{sharedlib.cpp,extension.cpp} and
    cygnal/cgi-bin/oflaDemo/oflaDemo.cpp; probably suspect but I don't do
    C++ so can't verify
gnu-smalltalk-3.1-7.fc12: (source) smalltalk-3.1.tar.gz: smalltalk-3.1/lib-src/ltdl.c
  - uses lt_dlopenext() in libgst/cint.c and snprintfv/snprintfv/dl-yes.c;
    for cint.c not sure where the filename comes from (don't see a call to
    the dld_open() function anywhere, unless it is the dldLink
    definition that is uses in kernel/DLD.st -- at that point I have no
    idea what is going on), for dl-yes.c it will attempt to load every
    module in LTDL_LIBRARY_PATH environment variable (from
    snv_load_all_modules()); possibly requires fixing
hamlib-1.2.9-1.fc12: (source) hamlib-1.2.9.tar.gz: hamlib-1.2.9/libltdl/ltdl.c
  - uses lt_dlopenext() and lt_dlopen() in src/rot_reg.c and
    src/register.c; modules are automatically prefixed with 'hamlib-', and
    looks like ROT_BACKEND_LIST is a hard-coded list of modules to load,
    but no path specification that I can see
libannodex-0.7.3-12.fc12: (source) libannodex-0.7.3.tar.gz: libannodex-0.7.3/libltdl/ltdl.c
  - uses lt_dlopen() in src/libannodex/fix_dl.c, used in dlopen_F(); looks
    like it is passed a full pathname (set in
    anx_register_all_media_importers_dir() from src/libannodex/anx_import.c
libnetdude-0.11-3.fc12: (source) libnetdude-0.11.tar.gz: libnetdude-0.11/libltdl/ltdl.c
  - uses lt_dlopenext() in src/libnd_{plugin,protocol_plugin}.c; not sure
    about this one, looks like it's iterating over a list of plugins but
    not sure where the list is coming from so can't determine if they're
    full paths or not; possibly requires fixing
libprelude-0.9.24.1-1.fc12: (source) libprelude-0.9.24.1.tar.gz: libprelude-0.9.24.1/libltdl/ltdl.c
  - uses lt_dlopenext() in src/prelude-plugins.c, which is ultimately
    called through prelude_plugin_load_from_dir() which takes a directory
    name as an argument so presumably it will be passed a full filename,
    but this maybe depends on what is calling that function (an external
    app using libprelude by the looks of things); possibly requires fixing
    unless we can determine that a full path is always being passed
mingw32-libltdl-1.5.26-14.fc12: (source) libtool-1.5.26.tar.gz: libtool-1.5.26/libltdl/ltdl.c
  - absolutely no idea on this one; looks like windows binaries for
    cross-compiling, but I don't know if this issue affects windows dll
    loading or not
naim-0.11.8.3.1-8.fc12: (source) naim-0.11.8.3.1.tar.bz2: naim-0.11.8.3.1/libltdl/ltdl.c
  - uses lt_dlopen() in src/conio.c, but all calls are either NULL or a
    .dll filename (for cygwin?), one uses lt_dlopenext() on args[0]
    (self?); probably ok but definitely odd
proftpd-1.3.2b-1.fc12: (source) proftpd-1.3.2b.tar.bz2: proftpd-1.3.2b/lib/libltdl/ltdl.c
  - uses lt_dlopen() and lt_dlopenext() in modules/mod_dso.c; lt_dlopen()
    is safe (loads self), lt_dlopenext() opens a module with a full
    pathname ($prefix/libexec/<module>) or from LoadFile in the config
    (must be a full file and path); should be ok
q-7.11-6.fc12: (source) q-7.11.tar.gz: q-7.11/libltdl/ltdl.c
  - uses lt_dlopen() and lt_dlopenext() in src/sys.c and lt_dlopenext() in
    src/q.c; looks like in sys.c it's redefining both functions, in q.c it
    looks a little fishy to me but I can't be sure; possibly requires
    fixing
sdcc-2.9.0-4.fc12: (source) sdcc-src-2.9.0.tar.bz2: sdcc/sim/ucsim/libltdl/ltdl.c
  - not entirely sure where there is an embedded libltdl here; lt_dlopen*()
    is not used at all
ski-1.3.2-8.fc12: (source) ski-1.3.2.tar.gz: ski-1.3.2/src/ltdl.c
  - uses lt_dlopen() in src/sim.c; tries to open the value of the
    SKIHOOK_PATH environment variable; I suppose this must be pointing to a
    file of some sort (not noted elsewhere in the code); only a problem if
    the user sets this env var to a relative path; should be fine
squid-3.1.0.14-1.fc12: (source) squid-3.1.0.14.tar.bz2: squid-3.1.0.14/lib/libLtdl/ltdl.c
  - uses lt_dlopen() in src/LoadableModule.cc; I have no idea about this
    one; probably should be checked by the maintainer
vrq-1.0.62-1.fc12: (source) vrq-1.0.62.tar.gz: vrq-1.0.62/libltdl/ltdl.c
  - uses lt_dlopen() in plugin/sim/pliext.cc and src/main.cc; looks like in
    all cases it uses a full path and filename prefixed by pluginPath;
    should be ok
whatsup-1.9-2.fc12: (source) whatsup-1.9.tar.gz: whatsup-1.9/src/libcommon/ltdl.c
  - uses lt_dlopen() in src/whatsup/whatsup.c,
    src/libnodeupdown/nodeupdown_module.c, and src/pingd/pingd_config.c; in
    whatsup.c loads a full path in WHATSUP_MODULE_DIR; in
    nodeupdown_module.c loads a full path in NODEUPDOWN_MODULE_DIR; and
    PINGD_MODULE_DIR in pingd_config.c; should be ok

So, for the above, the following packages need to be fixed or updated by their respective maintainers:

- gcc (in Fedora 11)
- esorex
- gambas
- ggobi
- gnash
- gnu-smalltalk
- hamlib
- libnetdude
- libprelude
- mingw32-libltdtl
- q
- squid

mingw32-libltdl-1.5.26-20.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mingw32-libltdl-1.5.26-20.fc12

mingw32-libltdl-1.5.26-17.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/mingw32-libltdl-1.5.26-17.fc11

gnash-0.8.6-13.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gnash-0.8.6-13.fc12

gnash-0.8.6-13.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/gnash-0.8.6-13.fc11

gnash-0.8.6-13.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

gnash-0.8.6-13.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

esorex-3.7.2-6.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/esorex-3.7.2-6.fc13

esorex-3.7.2-5.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/esorex-3.7.2-5.fc12

esorex-3.7.2-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/esorex-3.7.2-3.fc11

esorex-3.7.2-5.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/esorex-3.7.2-5.fc12

esorex-3.7.2-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/esorex-3.7.2-3.fc11

esorex-3.7.2-6.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/esorex-3.7.2-6.fc13

esorex-3.7.2-5.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/esorex-3.7.2-5.fc12

esorex-3.7.2-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/esorex-3.7.2-3.fc11

mingw32-libltdl-1.5.26-20.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

mingw32-libltdl-1.5.26-17.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

esorex-3.7.2-6.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

hamlib-1.2.10-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/hamlib-1.2.10-2.fc12

hamlib-1.2.8-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/hamlib-1.2.8-4.fc11

esorex-3.7.2-5.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

esorex-3.7.2-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

hamlib-1.2.10-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

hamlib-1.2.8-4.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Statement:

(none)

This has been fixed in upstream GraphicsMagick:

2011-10-21  Bob Friesenhahn  <bfriesen.tx.us>

* libtool: Updated to libtool 2.4.2.