_FORTIFY_SOURCE by default?
_FORTIFY_SOURCE=2 appears to be the default for package building on many
Linux distributions now, as part of harding or security options. But we
often hear about problems related to this only when we hand the source
over to the packagers. So I think we might as well add this to our
standard compilation options, for example in src/include/port/linux.h.
What do you think?
Peter Eisentraut <peter_e@gmx.net> writes:
_FORTIFY_SOURCE=2 appears to be the default for package building on many
Linux distributions now, as part of harding or security options. But we
often hear about problems related to this only when we hand the source
over to the packagers. So I think we might as well add this to our
standard compilation options, for example in src/include/port/linux.h.
What do you think?
Doesn't seem like a good idea to me to add platform-specific options
with unspecified effects to platform-independent upstream sources.
To the extent that this option finds anything useful (which in my
experience is a negligibly small percentage anyway), it's the
responsibility of the packagers (including me) to report it.
regards, tom lane
On 09/16/2012 12:41 AM, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
_FORTIFY_SOURCE=2 appears to be the default for package building on many
Linux distributions now, as part of harding or security options. But we
often hear about problems related to this only when we hand the source
over to the packagers. So I think we might as well add this to our
standard compilation options, for example in src/include/port/linux.h.
What do you think?Doesn't seem like a good idea to me to add platform-specific options
with unspecified effects to platform-independent upstream sources.To the extent that this option finds anything useful (which in my
experience is a negligibly small percentage anyway), it's the
responsibility of the packagers (including me) to report it.
Might be worth having a buildfarm animal or two building with it, say by
setting CFLAGS before configure?
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
On 09/16/2012 12:41 AM, Tom Lane wrote:
Doesn't seem like a good idea to me to add platform-specific options
with unspecified effects to platform-independent upstream sources.
Might be worth having a buildfarm animal or two building with it, say by
setting CFLAGS before configure?
Possibly, but only if we actually pay attention to build warnings on
those animals.
regards, tom lane
On Sun, 2012-09-16 at 00:41 -0400, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
_FORTIFY_SOURCE=2 appears to be the default for package building on many
Linux distributions now, as part of harding or security options. But we
often hear about problems related to this only when we hand the source
over to the packagers. So I think we might as well add this to our
standard compilation options, for example in src/include/port/linux.h.
What do you think?Doesn't seem like a good idea to me to add platform-specific options
with unspecified effects to platform-independent upstream sources.
It's effectively a warning option, and we end up fixing all the warnings
anyway, so I don't see the point of deferring that effort. We could
rephrase this request as, how about adding this new warning option, it's
occasionally useful -- which we frequently do.
We add platform-specific warning and optimization options in many
places, and I don't think this is much different.
On Sun, 2012-09-16 at 10:36 -0400, Andrew Dunstan wrote:
Might be worth having a buildfarm animal or two building with it, say by
setting CFLAGS before configure?
I don't really see the value in that. Either this is part of our
standard set of warnings and checks that we are interested in, and then
everyone should see it, or we don't care about this, and then we should
ignore the issue altogether. Creating different diagnostics sets for
different people and different circumstances without clear purpose one
way or the other just creates friction.
Peter Eisentraut <peter_e@gmx.net> writes:
On Sun, 2012-09-16 at 00:41 -0400, Tom Lane wrote:
Doesn't seem like a good idea to me to add platform-specific options
with unspecified effects to platform-independent upstream sources.
It's effectively a warning option, and we end up fixing all the warnings
anyway, so I don't see the point of deferring that effort. We could
rephrase this request as, how about adding this new warning option, it's
occasionally useful -- which we frequently do.
We add platform-specific warning and optimization options in many
places, and I don't think this is much different.
Maybe we're talking past each other. What I thought you meant was
adding this #define unconditionally, without any awareness of what it
might do on particular platforms. If you are thinking of adding it
only on platforms where it is considered standard, I can live with that.
Another point to consider here is that (at least on Red Hat) I believe
this enables address-space randomization; which is something I very much
do not want to happen in debug builds.
Bottom line is if you just want a new configure option for this, I don't
particularly object ... but on the other hand I also don't see the
usefulness. It's already possible for packagers who want the flag
to inject it, and for buildfarm owners who want to test the case to do
so.
regards, tom lane
On Sun, 2012-09-16 at 15:58 -0400, Tom Lane wrote:
Maybe we're talking past each other. What I thought you meant was
adding this #define unconditionally, without any awareness of what it
might do on particular platforms. If you are thinking of adding it
only on platforms where it is considered standard, I can live with
that.
I had suggested to put it into src/include/port/linux.h
Another point to consider here is that (at least on Red Hat) I believe
this enables address-space randomization; which is something I very
much do not want to happen in debug builds.
I doubt that a preprocessor symbol has anything to do with address-space
randomization. You are probably thinking of some other option that
comes in with the hardening/security flags.
Peter Eisentraut <peter_e@gmx.net> writes:
On Sun, 2012-09-16 at 15:58 -0400, Tom Lane wrote:
Maybe we're talking past each other. What I thought you meant was
adding this #define unconditionally, without any awareness of what it
might do on particular platforms. If you are thinking of adding it
only on platforms where it is considered standard, I can live with
that.
I had suggested to put it into src/include/port/linux.h
OK, that's probably reasonable.
Another point to consider here is that (at least on Red Hat) I believe
this enables address-space randomization; which is something I very
much do not want to happen in debug builds.
I doubt that a preprocessor symbol has anything to do with address-space
randomization. You are probably thinking of some other option that
comes in with the hardening/security flags.
[ pokes around... ] You're right, I was confusing this with
"_hardened_build".
regards, tom lane
On Mon, 2012-09-17 at 23:10 -0400, Tom Lane wrote:
I had suggested to put it into src/include/port/linux.h
OK, that's probably reasonable.
It turns out that doesn't work because port.h is included after all the
interesting libc header files (stdio.h etc.).
I think the best place to put it is going to be src/template/linux.
That would mirror the existing practice of putting it on the compiler
command line.