Build fails with clang when using "-Werror,-Wformat-security" (format string is not a string literal)

Bug #1193025 reported by Niederstrasser
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
High
Alex Valavanis

Bug Description

OS X 10.7, using Xcode 4.6.2 (Apple clang 425.0.28)

g++ -DHAVE_CONFIG_H -I. -I.. -I/sw/include/freetype2 -I/sw/include -I/sw/include/gnome-vfs-2.0 -I/sw/lib/gnome-vfs2.16/gnome-vfs-2.0/include -I/sw/include/gconf/2 -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -I/sw/include/ImageMagick -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/sw/include/libwpg-0.2 -I/sw/include/libwpd-0.9 -I/sw/include -I/sw/include/poppler -I/sw/include/poppler/glib -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -I/sw/include/cairo -I/sw/include -I/sw/include/freetype2 -I/usr/X11/include -DPOTRACE=\"potrace\" -I/sw/include/gdkmm-2.4 -I/sw/lib/gdkmm-2.4/include -I/sw/include/giomm-2.4 -I/sw/lib/giomm-2.4/include -I/sw/include/pangomm-1.4 -I/sw/lib/pangomm-1.4/include -I/sw/include/gtk-2.0 -I/sw/include/glibmm-2.4 -I/sw/lib/glibmm-2.4/include -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -I/sw/include/sigc++-2.0 -I/sw/lib/sigc++-2.0/include -I/sw/include/cairomm-1.0 -I/sw/lib/cairomm-1.0/include -I/sw/include/pango-1.0 -I/sw/include/cairo -I/sw/include -I/sw/include/freetype2 -I/sw/lib/gtk-2.0/include -I/sw/include/atk-1.0 -I/sw/include/gtkmm-2.4 -I/sw/lib/gtkmm-2.4/include -I/sw/include/gtk-unix-print-2.0 -I/sw/include/atkmm-1.6 -I/sw/include/libxml2 -I/sw/include/gtkspell-2.0 -I/sw/include/libpng15 -I/usr/X11/include -I../cxxtest -I./bind/javainc -I./bind/javainc/linux -Werror=format-security -Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2 -I/sw/include -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT box3d-context.o -MD -MP -MF $depbase.Tpo -c -o box3d-context.o box3d-context.cpp &&\
mv -f $depbase.Tpo $depbase.Po

box3d-context.cpp:643:57: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
    bc._message_context->setF(Inkscape::NORMAL_MESSAGE, _("<b>3D Box</b>; with <b>Shift</b> to extrude along the Z axis"));
                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/sw/include/glib-2.0/glib/gi18n.h:28:20: note: expanded from macro '_'
#define _(String) gettext (String)
                   ^~~~~~~~~~~~~~~~

Tags: build
su_v (suv-lp)
tags: added: build
Revision history for this message
su_v (suv-lp) wrote :

Are you trying to compile current stable or current trunk with clang?

Note: current stable (Inkscape 0.48.4, <lp:inkscape/0.48.x>) does not compile with clang - basic clang support has been implemented in current trunk though (Inkscape 0.48+devel, <lp:inkscape>), as already tracked in bug #992124. AFAICT clang support is unlikely to get backported to the current stable release branch.

Changed in inkscape:
status: New → Incomplete
Revision history for this message
su_v (suv-lp) wrote :

> box3d-context.cpp:643:57: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]

Current trunk does build with Apple's clang 3.1 from Xcode 4.3.2 on OS X 10.7.5 - though not without warnings. AFAIU the compiler flag '-Werror' will cause any build attempt of current Inkscape trunk with clang to fail, since all warnings are treated as errors, and Inkscape's code base does not compile completely without warnings.

Attached is a full build log of r12380 on OS X 10.7.5 (Xcode 4.3.2), with Apple clang version 3.1 (tags/Apple/clang-318.0.58)), using up-to-date dependencies installed via MacPorts (trunk), with optional (raster extensions with ImageMagick++) and experimental Inkscape features (lpe, gradient mesh) enabled - this one based on the X11 backend of GTK+ 2.24.18 (AFAIK Fink does not support building with GTK+/Quartz).

Revision history for this message
Niederstrasser (niederstrasser) wrote :

The exact error in coment #0 is from 0.48.4. However, I have tested current trunk as well and I see the same error about potentially insecure string literals. I understand that things won't necessarily be ported back to 0.48.4, but I can always grab trunk patches and apply them locally.

Have you tried compiling trunk with Xcode 4.6, which has a stricter clang than Xcode 4.3.2? llvm-gcc will be gone in Xcode 5, so Inkscape building with 4.3.2 is no guarantee that it will work once Xcode 5 arrives.

su_v (suv-lp)
Changed in inkscape:
status: Incomplete → New
Revision history for this message
Niederstrasser (niederstrasser) wrote :

This can be avoided by passing "-Wno-error=format-security" to CPPFLAGS, but of course, fixing the string would be a better long term solution.

summary: - box3d-context.cpp compile failure with clang (OS X 10.7; not a string
- literal)
+ Build fails with clang when using "-Werror,-Wformat-security" (format
+ string is not a string literal)
Revision history for this message
Niederstrasser (niederstrasser) wrote :

For completeness sake, here's clang -v (from Xcode 4.6.2):

$ clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

Apple's clang source is available here: http://www.opensource.apple.com/source/clang/ although the source for this particular point release has apparently not been made public yet.

Revision history for this message
David Evans (devans-n) wrote :

Just to add another comment, it would be nice to have inkscape (trunk at least) build with clang since it is Apple's preferred compiler for recent versions of Mac OS X.

In this case, however, the problem is not really with clang but the CPPFLAGS set in configure.ac in combination with the offending code. I believe that any recent compiler that understands the flags given would fail in the same way.

Using clang, trunk r12556 and ---disable-strict-build with MacPorts, the status display after configure shows

        CPPFLAGS: -Werror=format-security -DGSEAL_ENABLE -DG_DISABLE_SINGLE_INCLUDES -Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2 -I/opt/local/include

and the compile fails as shown above. Removing -Werror=format-security or adding -Wno-format-security allows the build to
complete successfully although with non-fatal warnings also mentioned above.

Fixing the code would be the better solution to prevent potential vulnerabilities but I note that the same construction is used throughout the code base and so more than just this one instance is involved.

For the record, I'm building on OS X 10.8.5 with just released Xcode Version 5.0 (5A1413)

$ clang -v
Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

Revision history for this message
su_v (suv-lp) wrote :

@Alex - any chance you could help with solving this build issue with recent clang versions?

Changed in inkscape:
importance: Undecided → High
milestone: none → 0.49
status: New → Confirmed
Revision history for this message
su_v (suv-lp) wrote :

Attaching list of '[-Wformat-security]' warnings from r12557
(dbus api, mesh and experimental LPE enabled)

Revision history for this message
Alex Valavanis (valavanisalex) wrote :

Looking into it now :)

Changed in inkscape:
assignee: nobody → Alex Valavanis (valavanisalex)
status: Confirmed → In Progress
Revision history for this message
Alex Valavanis (valavanisalex) wrote :

Should be fixed in lp:inkscape r12563, but I don't have the version of clang that reports the error, so I can't test properly. Please let me know if problems persist.

Changed in inkscape:
status: In Progress → Fix Committed
Revision history for this message
su_v (suv-lp) wrote :

1) With (outdated) Apple clang version 3.1 I don't see any warnings about format-security anymore (r12563):

$ grep '\[-Wformat-security' 2013-09-21-bug1193025-clang-12563.txt | wc -l
       0

2) Attached is the list with all remaining warnings (Apple clang version 3.1) - I don't know if more recent clang versions handle all of them as warnings, too, or fail elsewhere.

$ grep '\[-W' 2013-09-21-bug1193025-clang-12563.txt | wc -l
     175

Re warnings from code implementing emf/wmf support:
I brought those up in bug #988601 (comment #158), here's the reply of the author of that specific code:
<https://bugs.launchpad.net/inkscape/+bug/988601/comments/162>

Revision history for this message
su_v (suv-lp) wrote :
Revision history for this message
su_v (suv-lp) wrote :

> tags: added: backport-proposed

See also bug #1194129 “backport fixes for clang compiler errors to the 0.48.x”

tags: added: backport-proposed
Revision history for this message
David Evans (devans-n) wrote :

I can also confirm that the fix committed in r12563 takes care of the format security errors when using the latest version
of clang (Xcode 5.0). Trunk (r12566) now builds successfully with this compiler using --disable-strict-build. Back-porting to
the 0.48.x branch sounds good. Thanks for your efforts.

Revision history for this message
su_v (suv-lp) wrote :

 Backport for format-security fix committed to lp:inkscape/0.48.x in revision 9952
(Note: lp:inkscape/0.48.x doesn't yet build with clang - there are still two issues pending)

Changed in inkscape:
milestone: 0.49 → 0.48.5
Revision history for this message
su_v (suv-lp) wrote :

On 2013-09-22 24:45 +0200, ~suv wrote:
> (Note: lp:inkscape/0.48.x doesn't yet build with clang - there are
> still two issues pending)

The pending issues in the stable release branch now have been addressed, and <lp:inkscape/0.48.x> r9963 has been confirmed to build successfully with Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) on 10.7/Xcode 4.6.3.

@David Evans - any feedback wrt to Xcode 5.0 / Apple LLVM version 5.0 would be highly appreciated. Inkscape bug-fix releases don't happen that often, and it would be great to know whether additional changes are required to support building with MacPorts 2.2.0 and Xcode 5.0, before the next release is prepared (0.48.5).

Kris (kris-degussem)
tags: removed: backport-proposed
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.