> On Apr 28, 2016, at 9:22 AM, Richard Purdie > <[email protected]> wrote: > > On Thu, 2016-04-28 at 08:58 -0700, Khem Raj wrote: >>> On Apr 28, 2016, at 6:27 AM, Joshua Lock <[email protected]> >>> wrote: >>> >>> -SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie >>> ${lcl_maybe_fortify}" >>> -SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong >>> ${lcl_maybe_fortify}" >>> +# Error on use of format strings that represent possible security >>> problems >>> +SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security >>> -Werror=format-security" >>> + >>> +SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie >>> ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}" >>> +SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong >>> ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}" >>> >>> SECURITY_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro,-z,now" >>> SECURITY_X_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro" >>> @@ -92,6 +95,23 @@ SECURITY_CFLAGS_pn-zlib = >>> "${SECURITY_NO_PIE_CFLAGS}" >>> SECURITY_CFLAGS_pn-ltp = "${SECURITY_NO_PIE_CFLAGS}" >>> SECURITY_CFLAGS_pn-pulseaudio = "${SECURITY_NO_PIE_CFLAGS}" >>> >>> +# Recipes which fail to compile when elevating -Wformat-security >>> to an error >>> +SECURITY_STRINGFORMAT_pn-busybox = "" >>> +SECURITY_STRINGFORMAT_pn-console-tools = "" >>> +SECURITY_STRINGFORMAT_pn-cmake = "" >>> +SECURITY_STRINGFORMAT_pn-expect = "" >>> +SECURITY_STRINGFORMAT_pn-gcc = "" >>> +SECURITY_STRINGFORMAT_pn-gettext = "" >>> +SECURITY_STRINGFORMAT_pn-kexec-tools = "" >>> +SECURITY_STRINGFORMAT_pn-leafpad = "" >>> +SECURITY_STRINGFORMAT_pn-libuser = "" >>> +SECURITY_STRINGFORMAT_pn-ltp = "" >>> +SECURITY_STRINGFORMAT_pn-makedevs = "" >>> +SECURITY_STRINGFORMAT_pn-oh-puzzles = "" >>> +SECURITY_STRINGFORMAT_pn-stat = "" >>> +SECURITY_STRINGFORMAT_pn-unzip = "" >>> +SECURITY_STRINGFORMAT_pn-zip = "" >> >> Can we use _remove operation instead of introducing a new variable >> and emptying it out here. > > I actually suggested we do the above. The reason is that this way, the > user can configure which flags they actually want to use. "remove" also > has the problem that its near impossible for the user to override > further. >
Thats right, and I was of the view that security flags should be one set and not offered at combination of multiple options, we just end up increasing the test matrix. > I'm starting to believe that remove usage in OE-Core itself is actually > symptomatic of a problem and that if we end up using it, it probably > should be done differently. > I believe _remove has the potential to be abused yes
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
