Re: SHA384_Update symbol clash with libgs

[Greg Troxel <gdt%lexort.com@localhost>]

Edgar Fuß <ef%math.uni-bonn.de@localhost> writes:

> I'm not sure at which level this needs to be dealt with.
>
> libgs, in its infinite wisdom, exports SHA384_Update, which of course clashes 
> with OpenSSL's well known symbol of the same name. Which means that as soon as 
> you pull in libgs, your TLS may fail in mysterious ways.
>
> [In my case, it was php-ldap failing to StartTLS because OpenSSL's 
> tls1_setup_key_block() failed. It took three working days (including two 
> stepping through OpenSSL code) to pinpoint that. libgs was pulled in via 
> php-imagick.]
>
> Apart from a GS rendering library exporting symbol with the name of a 
> well-known crypto function being a strange idea, who is at fault? Why does 
> libssl's reference to SHA384_Update gets resolved to libgs's symbol and not 
> libc's?
>
> Any workaround to make the code work?

I don't think there are any real definitions of which package is allowed
to do what.

In this case, though, it seems clear that libgs shouldn't use that name.
I would suggest renaming it in the sources and APIs to gs_SHA384_Update,
but I would suggest filing a bug upstream first to try to shed light on
what's happening and why.