After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 579932 - Please do not export md5_* symbols
Please do not export md5_* symbols
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: general
2.26.x (obsolete)
Other Linux
: Normal major
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2009-04-23 09:37 UTC by Josselin Mouette
Modified: 2010-04-18 12:12 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26



Description Josselin Mouette 2009-04-23 09:37:58 UTC
Currently libedataserver exports the symbols from md5_utils.co to the public API/ABI. This sounds clearly like namespace abuse to me. If a binary happens to load libedataserver and another MD5 implementation in the same address space, it will lead to crashes (as it recently happened to us with the GStreamer LADPSA module).

Fixing this requires breaking the public API, by either:
 * making these symbols visibility("hidden") and removing them from the public API, only letting other functions in libedataserver use them
 * renaming them to e_md5_*
Comment 1 Matthew Barnes 2009-04-23 11:47:50 UTC
I agree, and that API is already deprecated (use GChecksum instead).  But we can't actually remove those symbols until GNOME 3.

A less drastic API break would be to make sure we're not including md5-utils.h in any public header.  Then you'd have to explicitly include it in order for it to stomp on the namespace.

First we need to analyze where md5-utils.h is being included implicitly and what modules may be affected.  But a quick grep of the E-D-S source didn't turn up any hits for me.  Got any specific examples of where it's causing problems?
Comment 2 Matthew Barnes 2009-04-23 11:50:17 UTC
Another option that might work for your specific case is to define EDS_DISABLE_DEPRECATED in your GStreamer module.
Comment 3 Josselin Mouette 2009-04-23 11:54:36 UTC
(In reply to comment #1)
> A less drastic API break would be to make sure we're not including md5-utils.h
> in any public header.  Then you'd have to explicitly include it in order for it
> to stomp on the namespace.

You don’t have to include the header for it to be a problem. As long as the symbols are publicly exported, they will appear in the global symbol table of all binaries linking (directly or indirectly) to it.

The problem with the GStreamer was not caused by e-d-s (anyone using it in a GStreamer module would deserve a painful death) but it’s an example of a disaster similar to the one that is waiting to happen with e-d-s.
Comment 4 Matthew Barnes 2010-04-18 12:12:25 UTC
The md5 symbols have been removed for version 2.31.1, so closing this as fixed.