[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

If "we" want to support additional semantics for sn?printf where the
standard says "undefined", we should take care to specify what is going
to be promised.

I don't know whether "we" is Debian, or "we" is (e)glibc upstream.

I also don't know exactly what is being proposed.  Something like
    When the format string begins with exactly "%s" and the
    corresponding argument is equal by pointer comparison to the
    output argument, the behavior is as if that corresponding
    argument was actually a copy of pointed-to string.
    [debian / e?glibc extension]

It's also worth noting that
 * The current behavior of sprintf depends not only on
   -D_FORTIFY_SOURCE but also on -O
 * freebsd snprintf has this appending behavior, but no version of 
   linux I tried did---only the unsafe sprintf.

This latter item is an important point: if we are going to make
append-style sprintf, we'd better make snprintf do it too, so that
when the inevitable "sprintf -> snprintf for security" changes come
along in whatever package, we odn't see the same breakage.

All that said, I am personally in favor of *not* defining this
sn?printf extension and fixing packages where we encounter use of
this idiom.


Attachment: signature.asc
Description: Digital signature

Reply to: