Bug 1037023

Summary: coreutils FTBFS if "-Werror=format-security" flag is used
Product: [Fedora] Fedora Reporter: Dhiru Kholia <dkholia>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: admiller, bressers, kdudka, kzak, ooprala, ovasik, pbrady, p, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-17 21:58:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1038083    

Description Dhiru Kholia 2013-12-03 02:56:52 UTC
Description of problem
----------------------

coreutils fails to build if "-Werror=format-security" flag is used.

...

test-xvasprintf.c:98:5: error: format not a string literal and no format arguments [-Werror=format-security]

...

We are working on a proposal to enable "-Werror=format-security" for all
packages. Once this flag is enabled, GCC will refuse to compile code that could
be vulnerable to a string format security flaw. For more details, please see
https://fedorahosted.org/fesco/ticket/1185 page.

To understand why it is important to fix this, please see
https://fedoraproject.org/wiki/Format-Security-FAQ page.

How to fix this
---------------

The fix for these errors is quite simple. It's a matter of changing a
line like,

   printf(foo);

to read,

   printf("%s", foo);

That's it.

Please fix this issue in rawhide with a patch (which you should submit
to upstream to merge moving forward). Please do a new build with the
fix in rawhide. Other releases do not need to be directly fixed, but
there should be no harm in pushing out this fix/patch with other needed
changes to those branches.

In the event you don't fix this bug before the next mass rebuild,
provenpackagers may step in and update your package(s) to fix this
issue.

How reproducible
----------------

Build coreutils-8.21-19.fc21.src.rpm with "-Werror=format-security" flag to reproduce the problem.

To make this process easier, you can use a modified "redhat-rpm-config" package
from http://people.fedoraproject.org/~halfie/artifacts/redhat-rpm-config/ URL.

$ sha256sum redhat-rpm-config-9.1.0-56.fc20.*
faad7594b2080fe76497d0ce50808c905a93dd7b41c1defdde5ca57e3833d3d2  redhat-rpm-config-9.1.0-56.fc20.noarch.rpm
5aa9357174305c7285ffdbc92d7ffe1c07a8a95d5459b930461308f5aad75413  redhat-rpm-config-9.1.0-56.fc20.src.rpm

Comment 1 Ondrej Vasik 2013-12-03 12:38:53 UTC
This is intentional and proposed fix can't be used - it is internal unit test for xvasprintf gnulib module checking the behaviour for empty format string. There was already some attempt to silence gcc warning about zero-length format string, it seems to be insufficient for the format-security warning checker. 

ATM I see two possibilities - one is ifdef disabling this test if WError is active, second one is to disable this gnulib test for our builds completely - we already do that for several tests which fail in koji mock environment quite often.

Comment 2 Ondrej Vasik 2013-12-03 15:30:03 UTC
gcc pragmas to disable some of the warnings will be used as solution in gnulib - http://lists.gnu.org/archive/html/bug-gnulib/2013-12/txtxl7suqXdqm.txt .

Comment 3 Tim Waugh 2013-12-03 16:25:40 UTC
I need the same patch for diffutils in bug #1037038 but it doesn't seem to fix the problem.

test-xvasprintf.c: In function 'test_xasprintf':
test-xvasprintf.c:104:5: error: format not a string literal and no format arguments [-Werror=format-security]
     result = xasprintf (empty);

Comment 4 Pádraig Brady 2013-12-03 22:53:17 UTC
Tim the above referenced one wasn't added to gnulib.
Could you try the one that was actually added?
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=4e42bcc4

Comment 5 Ondrej Vasik 2013-12-17 21:58:11 UTC
Fixed as part of coreutils-8.22 rebase.