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.
