Re: Putty or libcrypto bug?

In <20041123204859.GA2002_at_gothmog.gr>, keramida_at_linux.gr wrote:
>On 2004-11-23 19:59, Wiktor Niesiobedzki <bsd_at_w.evip.pl> wrote:
>>On Tue, Nov 23, 2004 at 08:39:30PM +0200, Giorgos Keramidas wrote:
>>> This is a Bad Idea(TM) most of the time though.  The library
>>> implements a function that other programs or libraries may depend upon
>>> to work in certain ways.  Replacing the library function with a
>>> hand-rolled version may or may not work -- the latter in this case :-/
>>
>> Should'nt libc load nss_ldap with kind of RTLD_LOCAL, so the libc will load
>> libldap in another symbol-space so symbol lookups will not end in main
>> program (if it is at all possible... I'm not familiar with dynamic linking)?
>
>What happens if parts of the program want to access symbols from many
>disjoint namespaces?  If a program links to two shared objects:
>libfoo.so.1 and libmore.2, which in turn depend on other shared objects,
>for example:
>
>	program
>		libfoo.so.1
>			libtest.so.3
>		libmore.so.2
>			libtmp.so.4
>				libthread.so.5
>
>and libmore _does_ want to override thread_create() from libthread.so.5
>but libtmp.so.4 wants only the original thread_create() function from
>libthread.so.5, which function will the runtime linker call when
>`program' calls thread_create()?

Then the author of libmore needs to take special steps; overriding
standards-described symbols is not something that should be taken lightly,
and there's no particular reason to make it trivial, and some good
reasons to make it somewhat difficult, so it takes deliberate
actions.

>> If not, then it is the fact, that programmer of any program should
>> aviod duplicating function names across every library that may
>> eventually be installed and somehow linked to this programm, what
>> sounds rather ridiculous to me.
>
>I don't think there is support for multiple symbol namespaces in C.
>This is probably why most of the utilities in the src/ tree export as
>few symbols as possible; many times just a main() function.
>
>Judicious use of static scope and unique name prefixes like putty_ may
>avoid such problems without the need for `RTLD_LOCAL'.

Absolutely, but the problem is not in putty.  The various UNIX(tm)
standards (POSIX and SUS) have quite a bit to say in this area, but
the upshot is fairly easily described in two sentences:

A library should not use symbol names that are in the user's namespace.
A library should declare what names(pace) it uses.

For example, POSIX reserves typedefs ending in _t.  An application that
trips over that has a bug.

So, back to the original poster's question:
> ... should the putty change the function name ... ?

I would vote no.  OpenSSL should not pollute the namespace with
symbols that it doesn't declare.  The sk_* functions are a
perfect example of this, they're totally internal to the operation
of the ssl library, and not a public interface at all.

Now, to convince the OpenSSL maintainers, that's a different challenge.

-- 
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.8" / 37N 20' 14.9"
 Internet: steve _at_ Watt.COM                         Whois: SW32
   Free time?  There's no such thing.  It just comes in varying prices...