>> > Actually, there is a way to circumvent the problem. It is quite ugly >> > and I am not sure you would like to implement it. Here is it: make >> > the functions xprintf and xprint1 both static, and move them, >> > together with xvprintf, into a header file (.h) which will be >> > included by all other files calling xprintf or xprint1. The only >> > side effect is that the resulting shared library will increase in >> > size. >> >> I do not understand the problem. There are many internal glpk routines >> prefixed by '_glp_', which, in principle, can be called from the user >> program. However, there is a common convention not to call such routines >> from outside.
> We are not talking about normal users following the conventions. We are > talking about a malicious hacker that could exploit the buffer overflow > vulnerability currently in GLPK. I do not know much about such exploits > (and have no interest in learning them either) but knowing that Debian is > currently distributing libglpk with such a vulnerability makes me really > nervous. I do not think that that could jeopardize the system, only the application. > I think that I will patch your sources for the Debian package along the > vsnprintf lines suggested by Peter. I would encourage you to fix the > problem in the GLPK source. Okay. I will make necessary changes to use vsnprintf rather than vsprintf in the next release. Best wishes, Andrew Makhorin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]