On 19/01/2018 12:44, Jaroslav Skarvada wrote:
stack, are the Fedora team really going to deny that technique for all
applications?
I am Fedora packager, and AFAIK the answer is NO. Also it seems there is
no Fedora global policy about it. Just rpmlint is complaining. I fixed the
spec not to enforce the NX stack and released updated builds. Feel free to
test and give it positive karma in Bodhi if OK.
Personally, I also don't like executable stacks, because they can ease the
attack for an attacker. It's always better to have all mitigation techniques
enabled, especially if the SW is processing data which are coming from the
air, just my two cents
thanks & regards
Jaroslav, OK2JRQ
Hi Jaroslav,
thanks for the update. What I still don't understand is that Mike,
KJ6VCP, reported the same issue with the RPM downloaded from the WSJT
project site. That RPM does not have a crippled jt9 executable. This is
why I had assumed something was happening at the system level rather
than packaging.
With respect to executable stack, you need to address that with the GNU
Fortran developers. I am sure they could implement procedure pointers
some other way but I doubt it is straightforward and I am sure it would
be very inefficient. Sometimes lint type programs have to be ignored,
they are not panaceas, they are just trying to help you look for
*potential* issues. It would be a very ingenious attacker that could
concoct a malicious attack vector delivered via audio from a radio
demodulator, or even by using the jt9 executable stand-alone as a
sub-process.
Just for some background. I am part way through a major re-factoring of
WSJT-X that will eventually combine the wsjtx and jt9 executables. The
Fortran codecs will remain but will be called from C++ code using
callbacks (the procedure pointers that are causing us to have this
conversation) to deliver decode information back to the UI components.
Currently the callbacks are to a Fortran layer (jt9) but are coded such
that they can be set-up and delivered to C++ code just the same. This
will still allow codec development in pure Fortran where desired, a
simple main procedure in that calls the codec and receives back decode
information via callbacks being used to develop and test before
deploying in the WSJT-X framework.
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
