Rename yara str functions to avoid symbol collisions #6917
Conversation
Yara publicly exposes the definition of various str functions like strlcpy, strlcat and so on if they are not present on the system it is compiled on. This is not ideal because other libraries use custom implementations of those functions and those symbols would collide with the public ones from yara, therefore we rename them to avoid the collision.
|
Has the upstream tip for YARA changed these? Should we also send them an issue / heads up to rename the functions? |
|
Upstream haven't changed these, actually there are more defines messing with other libc functions... Admittedly this is a bit of a lazy way to fix this; a better way would be to have a library that provides those functions in one place, and then tell Yara and the other libraries that we have an implementation they can use. I was briefly looking into Gnulib, but I was having a hard time understanding how to use their tool to generate the source code for the few functions I needed (was experimenting on building the toolchain with musl, which misses some functions that LLVM needs). |
It's not an entirely valid assumption, though (see 6.2.3 about the Solaris versus OpenBSD implementations)
Since they are (unfortunately) non-standard, I don't know if maintaining another library is any better than maintaining this patch of libyara. How about this? https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-strlcpy |
Well, I would expect the library to be based on a common implementation of
To be fair the objective was to commit as few source files as possible so that we don't have to maintain the configuration of a complex library. |
No I agree, I wouldn't suggest another library dependency just for this, if a patch to rename the routines in libyara will suffice. I just noted that |
I'm not sure what portability problems you're thinking about? This is the same implementation that libmagic, lldpd and Yara use, and there's only that implementation for all platforms.
But actually I would add a lib if it consisted only of those functions and nothing else :D. Although I realized now that So, we can accept this patch for now, but I don't think it makes sense to keep N implementations of the same functions, so ideally we would just add a new "thirdparty" library which we "maintain", which contains a copy of those functions, then that library is used by all the other ones that need those non-standard functions, so that there's only one implementation in the end and it's controlled by us. |
Yara publicly exposes the definition of various str functions like
strlcpy, strlcat and so on if they are not present on the system
it is compiled on.
This is not ideal because other libraries use custom implementations
of those functions and those symbols would collide with
the public ones from yara, therefore we rename them
to avoid the collision.