> > And the very first package I maintain that appears on that list, abe, > is an interesting one. The game has an internal function, > path_sprintf(), which is static in Game.c. All callers of that > function are visible in the same file, and all pass constant strings > into the function, which passes those constant strings to sprintf(). > The function's purpose is to produce a pathname for a file of interest > to the caller in the game's installed location. It's too bad that > gcc's analysis cannot span function calls inside a compilation unit. > There really is nothing wrong with this code. You're right, some of the "bugs" aren't really bugs. It would be handy if there was some form of taint checking in gcc, but we have to work with what we have. We mention this in the FAQ. https://fedoraproject.org/wiki/Format-Security-FAQ#I_don.27t_process_untrusted_string.2C_this_isn.27t_an_error.21 I would rather see us future proof all code than try to figure out each possible use case. This is a bit of a blanket strategy, but I do think it will have a net benefit. It's not every day you can remove an entire class of security issues (I can count the number of times we've done this on one hand). Thanks. -- Josh Bressers / Red Hat Product Security Team -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
