Bugzilla Bug 123733

QA Notice: the following files contain executable stacks
 Files with executable stacks will not work properly (or at all!)
 on some architectures/operating systems.  A bug should be filed
 at http://bugs.gentoo.org/ to make sure the file is fixed.
 Please include this file in your report:
 /var/tmp/portage/slmodem-2.9.11_pre20051101/temp/scanelf-exec.log
RWX --- --- usr/sbin/slmodem_test
RWX --- --- usr/sbin/slmodemd

It isn't the only package where you see this warning.
This QA Notice should be removed from portage because it confuses users. A
mixed package (source code + binary modules) will always trigger this warning.

the check isnt being removed, end of story

i thought i added some code for ebuilds to mark certain things as "ignorable",
but that must have been lost in the shuffle

also, if it's binary only, why dont you try contacting upstream about it ...
it's a trivial issue to resolve and adding the ELF section header wont break
any system

upstream of net-dialup/hsfmodem give packages for specific arches (x86 and
amd64). they will say that whatever it is in those binaries it isn't others
business.

there are too many packages that break this check for not allowing the
maintainers to disable the check. 
please implement a RESTRICT=scanelf or something similar in the portage code.

> upstream of net-dialup/hsfmodem give packages for specific arches (x86 and
> amd64). they will say that whatever it is in those binaries it isn't others
> business.

so you're just going to assume defeat without even trying

executable stacks has nothing to do with reverse engineering, it is an extra
layer of security with no overhead

(In reply to comment #5)
> so you're just going to assume defeat without even trying

there are too many of those packages to assume anything but (at least partial)
defeat.

> executable stacks has nothing to do with reverse engineering, it is an extra
> layer of security with no overhead

I know that but you don't take into account upstream inertia (or in some cases
direct opposition). At least some upstreams will change nothing, for whatever
reason you could imagine. Then what? We will got stuck with some QA warnings on
packages that works with or without section header.

> there are too many of those packages to assume anything but (at least partial)
> defeat.

you must be kidding

> I know that but you don't take into account upstream inertia (or in some cases
> direct opposition).

i never said any such thing, i simply said *why dont you try*

> At least some upstreams will change nothing, for whatever reason you could 
> imagine. Then what? We will got stuck with some QA warnings on
> packages that works with or without section header.

you missed the point ... i never said i wasnt going to add a way for ebuilds to
mark things as ignorable, i said you should at least try and get the situation
rectified properly before going around and adding ignore hacks

(In reply to comment #7)
> you must be kidding

am I? lets see:
  app-mobilephone/bitpim
  net-dialup/hcfpcimodem
  net-dialup/hcfusbmodem
  net-dialup/hsfmodem
  net-dialup/slmodem
this list isn't necessarily complete.

I don't really understand why this check was necessary in the first place. Any
of those packages are designed for 1 or 2 (when amd64 is supported, through
emulation or natively by using a different tarball) arches, As you can see,
most of them have "-*" in their KEYWORDS.

Anyway, I will borrow some of your optimism in this matter and try to persuade
upstreams to change their files.

(In reply to comment #1)
> It isn't the only package where you see this warning.
> This QA Notice should be removed from portage because it confuses users. A
> mixed package (source code + binary modules) will always trigger this warning.
> 

Confused users is not a good argument for removing helpful (to some)
functionality.  However we are looking at doing a few things, possibly a
RESTRICT for turning off some of the scanelf checks, and possible a FEATURE for
squelching QA output, or logging it to another location..etc.

I need to discuss with SpanKY and QA regarding how we are to proceed.

> > you must be kidding
> 
> am I? lets see:

you misread my statement ... i said you must be kidding that you're going to
simply not try to get anything resolved properly

> I don't really understand why this check was necessary in the first place.

why dont you read the gentoo-dev mailing list where we've covered executable
stacks and text relocations

> Any of those packages are designed for 1 or 2 (when amd64 is supported, 
> through emulation or natively by using a different tarball) arches, As you can
> see, most of them have "-*" in their KEYWORDS.

so ?  the architecture is irrelevant, exec stacks and textrels affect everyone

generally speaking though, exec stacks and textrels tend to be a "bigger" issue
on x86 than any other architecture, so really you've reinforced my stance ;)

now I understand. I didn't read that notice very carefully and thought it was
about some missing ELF header or something. my appologies...

yes, exec stacks are bad from security point of view, but if upstream refuses
to fix these, what would we do next? 

> yes, exec stacks are bad from security point of view, but if upstream refuses
> to fix these, what would we do next? 

with exec stacks, there isnt anything we can reliably do ... we cant reliably
inject a GNU_STACK program header as we have no idea if the binary code
actually needs the exec stack (maybe it uses a trampoline), or if it's just a
matter of code neglecting to include proper markings, or the compiler was too
old, or ...

so, if upstream really truly refuses to cooperate, we can either leave the QA
warning in, or we can go ahead and add support to portage for ebuild
maintainers to be like:
QA_EXEC_STACK="usr/sbin/slmodemd usr/sbin/slmodem_test"

looks like slmodem is going to have exec stacks and we're just going to have to
like it:
$ readelf -S dsplibs.o | grep GNU-stack
  [147] .note.GNU-stack   PROGBITS        00000000 0eb2d3 000000 00   X  0   0 
1

this means that when gcc generated dsplibs.o, it determined that the code it
generated is going to require executable stacks ... so if we disable that
marking, we're probably going to make the slmodem programs crash

I confirm that slmodem crash stack doesn't have X flag set on.

Since upstream don't exist and we don't have the source of dsplibs.o, I will
mark this as CANTFIX.

*** Bug 147282 has been marked as a duplicate of this bug. ***

Make the ebuild shut up then:


--- slmodem-2.9.11_pre20051101-r1.ebuild.orig   2006-09-10 12:06:38.000000000
+0200
+++ slmodem-2.9.11_pre20051101-r1.ebuild        2006-09-12 11:30:00.000000000
+0200
@@ -17,6 +17,8 @@
 DEPEND="alsa? ( media-libs/alsa-lib )
        amd64? ( app-emulation/emul-linux-x86-soundlibs )"

+QA_EXECSTACK="usr/sbin/slmodem_test usr/sbin/slmodemd"
+
 S=${WORKDIR}/${P/_pre/-}

 pkg_setup() {

fixed in slmodem-2.9.11_pre20051101-r1.

Ok, the ebuild is shutted up. I hope upstream will change its mind and resolve
the issue. Please remember to check if the QA_EXECSTACK is still needed in the
next version.