Dia format string vulnerabilities (correction)

[Hans de Goede]

Stanislav Brabec wrote:
> Hans de Goede writes:
>> Hi all,
>>
>> I was a bit short on time when I mailed my previous mail on this, so I
>> didn't test (I didn't even compile) the patch. It turns out my previous
>> patch contained one cut and paste error causing compilation to fail.
>>
>> The attached patch fixes this and has been tested.
> 
> And maybe these two extra chunks (at least in 0.94).
> 
> Found by:
> grep '\(message_\(error\|warning\)\|g_\(print\|message\|warning\)\|dia_assert_true\) *([^_"]' $(find -name '*.c')
> 
> 
> 
> ------------------------------------------------------------------------
> 
> --- plug-ins/python/pydia-error.c
> +++ plug-ins/python/pydia-error.c
> @@ -98,7 +98,7 @@
>    if (self->str)
>      g_string_append (self->str, s);
>  
> -  g_print (s);
> +  g_print ("%s", s);
>  
>    Py_INCREF(Py_None);
>    return Py_None;

This one is already fixed in 0.95


> --- plug-ins/xfig/xfig-export.c
> +++ plug-ins/xfig/xfig-export.c
> @@ -263,7 +263,7 @@
>  figWarn(XfigRenderer *renderer, int warning) 
>  {
>    if (renderer->warnings[warning]) {
> -    message_warning(renderer->warnings[warning]);
> +    message_warning("%s", renderer->warnings[warning]);
>      renderer->warnings[warning] = NULL;
>    }
>  }

Dang! missed this one <sigh> Thats what you get when staring at many
lines of code in over 100 files. Luckily this one isn't a security issue
though. There is only one type of warning in the renderer->warnings
array and this always gets initialised to: _("No more user-definable
colors - using black") and is never changed, so this isn't a problem.
Still I missed it.

Regards,

Hans