Chris Burkhardt wrote:
My question in this particular case is, should bug reports be opened
against librsvg, strigi, and the others requesting that they not
directly allocate memory for the xmlEntity structure? I can take the
time to do it, if it should be done.
Well IHMO either a bug that they should not directly allocate memory,
*or* that they should have a Depends header on an exact version, *or* a
bug against libxml2 to not expose the structures in the public header
files. (If not another solution in the package management is being
taken.) Which one I don't know.
But in any case this would be a one-time reaction. What about all the
other thousands of packages built in C which might have similar binary
dependencies? Isn't it just a kind of problem waiting to happen again?
And, in some cases the problem might even go unnoticed for some time,
and since those problems are about mistaken memory accesses, I'm quite
sure that is holding up the possibility to open up security holes. It
would be irony if a DoS security fix would open up code injection
security holes without being noticed.
That's why I think there needs to be some tool which checks for this
kind of unsafe linkage.
Also I guess such a tool might be a better solution than just strictly
requiring that no dependencies on the binary interface exists: for
performance reasons libraries might decide to offer some of their
internal structures on purpose (e.g. so that structures can be allocated
on the stack), maybe also even macros and inlined functions. But a tool
which analyzes the headers and the application code and could point out
whether a library user has a binary dependency may allow to
automatically force a strict version dependency when building the .deb
(or such a tool might compare the header files between library versions
and find out whether the parts being used in a particular app changed,
and then somehow force the Debian package servers to tell which packages
need a rebuild, although I don't know how such abi information would be
tracked in a .deb (some hash value of the used API parts?)).
I don't know whether such a tool (for analyzing API/ABI usage and
-changes) already exists.
Christian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
