On Mon, May 21, 2012 at 08:42:11AM +0100, Mark Brown wrote: > This isn't a problem at all - it's not like any of the test programs are > actually shipped. I'm not sure why I bothered even pass it in to be > honest, I think I was just too mystified as to what your patch was all > about.
True, they are not shipped. But compiling all files with
hardening flags makes automatic checks to detect missing flags
easier.
And fixing the upstream build system to respect flags from the
environment sounds like a good idea to me.
>> I think just patching in LDFLAGS is simpler than fixing configure
>> and adding TEST_LDFLAGS in a few places.
>
> This is a really invasive change to upstream and is going to be fragile
> going forward, it's fine for drive by people like you who don't care
> about maintianing the package but it's not helpful to people who have
> some ongoing interest in the package. Since upstream already provides a
I don't understand why you are so hostile. I was just trying to
help fix a problem with your package. Instead of telling me that
my patch just sucks, why don't you tell me what I should have
done better so I can provide better patches in the future.
And "don't modify the buildsystem" is not enough because in most
cases the buildsystem of the program is broken and needs to be
fixed (in zlib's case it works because you can ignore the broken
test build, but in most packages not only the test flags are
broken).
> way of doing this we should use it, if you have a burning desire to
> change the upstream build system you should as Jonathan say speak to
> them.
I just wanted to (help) fix the problem and thus provided a
patch. If you as maintainer don't like it - that's fine of course
- just implement a different solution (which works).
But I don't think it's my job to talk to upstream to fix their
buildsystem just because I provided a patch to fix the package.
That's your job as maintainer if you don't want to carry a change
as Debian-only patch or think a proposed patch has a better fix.
> hardening-check is really not very useful for this purpose, it's
> absurdly verbose when run over the whole package even for a tiny little
> one like this and doesn't tell you what the expected output is either
> which makes things a little illegible. blhc doesn't seem to be
> packaged. There's really no meaningful way of checking this stuff with
> the standard Debian tools.
hardening-check isn't perfect, that's true. But I'm sure patches
are welcome to improve it.
However the following command should help, it displays missing
flags of all binaries and libraries in the current directory and
ignores flags not enabled by default:
find -type f \( -executable -o -name \*.so\* \) -exec hardening-check
--quiet --nopie --nobindnow {} + 2>/dev/null | grep -vF '(ignored)'
blhc is no official Debian tool yet, but it works quite well and
is non-verbose.
Regards,
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
pgpDNwuxG7Qy4.pgp
Description: PGP signature
