On Wed, Dec 14, 2005 at 08:51:42AM +0100, Kevin F. Quinn wrote: > On Wed, 14 Dec 2005 07:59:23 +0100 > Harald van Dijk <[EMAIL PROTECTED]> wrote: > > > On Wed, Dec 14, 2005 at 03:50:16AM +0000, Mike Frysinger wrote: > > > my gnu stack docs are actually complete: > > > http://hardened.gentoo.org/gnu-stack.xml > > > > A question about that: you discourage fixing this with --noexecstack > > because it's better to be able to submit a patch upstream. What's your > > take on patches that modify configure scripts or similar files to > > check for this flag, keeping it out of the ebuild? Is that good, > > acceptable, or bad, and why? > > Using '--noexecstack' overrides anything the compiler works out for > itself, so applying it indiscriminately is a bad idea. For example, if > an application contains asm code with no markings, but also contains > code that creates trampolines, it should be marked for executable stack > even if the asm code is fixed. Applying '--noexecstack' via LDFLAGS > would break such an application. > > Regarding patches, it's usually much simpler to patch asm source code > compared to patching an application's make process. Patching asm > source code just means appending a few lines depending on the type of > assembler used. > > As far as ebuilds are concerned, if you add it to LDFLAGS you will need > to re-check the application every time you bump the ebuild, and it's > difficult to find new occurrences of nested functions for example if > you've applied '--noexecstack'.
LDFLAGS? Assuming you meant ASFLAGS, this doesn't affect C files, and would need rechecking of the assembly code on updates just as much as patches which add .note.GNU-stack would, right?
pgpNUhmpkS0CL.pgp
Description: PGP signature
