You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Blake Bender (Jira)" <ji...@apache.org> on 2019/09/11 14:24:00 UTC

[jira] [Updated] (GEODE-6007) Fix LGTM complaints in NC code base

     [ https://issues.apache.org/jira/browse/GEODE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Blake Bender updated GEODE-6007:
--------------------------------
    Summary: Fix LGTM complaints in NC code base  (was: Remove use of snprintf in NC code base)

> Fix LGTM complaints in NC code base
> -----------------------------------
>
>                 Key: GEODE-6007
>                 URL: https://issues.apache.org/jira/browse/GEODE-6007
>             Project: Geode
>          Issue Type: Improvement
>          Components: native client
>            Reporter: Blake Bender
>            Priority: Major
>
> This is bad practice in general, and may open us up to maliciousness.  There are two main situations in which we find lots of usage of snprintf with raw char buffers, which are:
>  * formatting messages for exceptions
>  * formatting messages for logging
> For the exception messages, we should switch to something known to be safe - a vsxprintf implementation, boost::format, std::stringstream, whatever.  As long as we stop declaring raw char buffers on the stack, it's all good
>  
> For logging, the situation is even dumber.  The various LOG* macros in the code _already_ take a format string and varargs, so as far as I know we essentially need to move the printf-style arguments into the logging macro and get rid of the other nonsense.  We may even buy a tiny performance improvement due to the fact that that logging macros can be compiled out of the code.
>  
> UPDATE:  Report from running LGTM on our code may be found at [https://lgtm.com/projects/g/apache/geode-native/alerts/?mode=list.]  This report has issues with tons of printf-style format specifiers, so it catches most of the snprintf stuff pointed out above.  MANY OF THESE ARE BUFFER OVERFLOW ISSUES, and must be addressed in the name of security.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)