On Sat, Apr 07, 2012 at 06:21:16PM -0400, Jeff Licquia wrote: > severity 667930 normal > forwarded 667930 http://www.epmhome.org/str.php?L38+P0+S-2+C0+I0+E0+M10+Q > thanks > > I've forwarded part of the patch upstream, as indicated above; it's the > part where CPPFLAGS is not respected. I'm not particularly interested > in the patch to doc/Makefile.in, since the resulting binary is a build > artifact and not shipped in the final package.
Thanks for forwarding the CPPFLAGS part. The general idea is to make it possible to automatically verify hardening flags by parsing the build log, this works quite well but to prevent false negatives/positives all compile commands must use the hardening flags. As it's a good idea to use the correct compiler flags (even without hardening) and the patch is just a few lines it would be great if you could send the doc/ patch to upstream as well - or just include it in debian/patches/. > I'm also not inclined to enable more hardening flags without testing > their impact on setup, which is intended to be bundled with a built > application to provide a Windows-style install GUI that runs on all > Linux distributions. When my testing is done, I'll decide whether the > bindnow feature is appropriate to enable. I can understand that. The reason why I enabled them is that they are already used by parts of the program because fltk's flags are used during the compile, enabling bindnow in a few places (bindnow was the only hardening flag missing). bindnow is just a linker flag which prevents writes to the loaded binary in a few places and won't cause any problems - unless the program is trying to rewrite itself, which I don't think it is or relro wouldn't work. Haven't tested that though. > (Yes, I'm aware that I could be in a pickle if PIE causes portability > problems; I'll cross that bridge when I come to it.) Most hardening flags work just fine, PIE is a often compile time problem, and sometimes a runtime problem - but there are exceptions of course. > I'm setting the severity to "normal" because epm doesn't look to be in > the first line of important packages to harden; it hasn't had a DSA > recently, is not priority "important", is not a daemon, and is not an > interpreter. You're right, sorry for the wrong severity. Regards, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9
pgpBKRMvqbIRl.pgp
Description: PGP signature
