DEB_BUILD_CFLAGS and DEB_BUILD_LDFLAGS for packaging

[Martin Pitt]

Hi Kees,

Kees Cook [2007-05-03 14:47 -0700]:
> The problems I encountered were mostly with detecting what gcc was meant 
> to do (i.e. some tools will call gcc to do linking, and others will call 
> ld directly).  For example, sorting out when to include -pie vs -fPIC 
> caused me a bit of a headache.

Ah, I see the point. But maybe some heuristics can help here?  If -c
is specified, then the case is easy, and you only need to supply compiler flags.
	
I guess the large majority of software separates compilation and
linking, so if -c is not specified, supplying linker flags should
DTRT.

However, I thought if you always specify both compiler and linker
options, gcc just ignores the ones it currently doesn't need for the
task to be performed, so for the second case we could just pass both?

> > (1) The long-term goal that was dicussed previously was  that all
> > source packages need to be converted to integrate these environment
> > variables into the CFLAGS they pass to their configure/Makefiles. This
> > is the only way that guarantees 100% build reproducability (with
> > calling 'debian/rules build'). Obviously this is a huge task, will
> > take years to be completed, and requires that the Debian maintainers
> > agree to this.
> 
> Getting the changes plumbed for packages really worries me; as you say, 
> it will take a long time to get all packages adjusted.  Can (1) and (2) 
> co-exist?

By and large it should work. If source packages incorporate
$DEB_BUILD_CFLAGS into the CFLAGS they pass to configure, they will
override the ones hardcoded into the gcc wrapper. That doesn't mean
that nothing is going to break with this, though: similarly to our SSP
hack, packages which break with the gcc wrapper's default options have
to be changed to explicitly negate the things the gcc wrapper turned
on (instead of just not enabling it explicitly). This is true for both
(1) and (2), though, that's why I think that those solutions are
largely compatible.

> What would the next steps be for implementing either (1) or (2)?

(1) Start a discussion with Debian, convince them to agree to the
strategy, and then wait a few years until it is implemented.

(2) This should be much easier: Mostly just create the wrappers and
hook them into dpkg-buildpackage. Then a private archive rebuild would
be nice to see how much doesn't build any more, and testing the
resulting packages (we should build a live CD from them).

> > A more interesting question is where to actually define the defaults
> > for those variables? With solution (2) that is easy, we can put them
> > into a conffile and ship that in dpkg-buildpackage. If we aim for (1),
> > then the only place that seems sensible to me is /etc/environment.
> 
> Additionally, I'd like to see a way to select between multiple (or at 
> least two) sets of options.  As an example, we could have the "secure" 
> and "more secure" sets of options.

Hmm, I don't think that we should make it as complex as that (too
Genooish). For our buildds we only want one option set. I also don't
see the benefit: If the 'more secure' set works and doesn't have too
many performance penalties, they should be the default. If an admin
wants to locally change the build policy, she can always do so in the
conffile.

> While all applications get less 
> invasive things like -relro, -D_FORTIFY_SOURCE=2, -Wformat-security, 
> some should get additional protections via -pie or similar.  I'm not 
> sure how this would look in the debian/rules, though.  Best I figured 
> was to use a separate default and override it near the top of the 
> debian/rules:
> 
> DEB_BUILD_CFLAGS=$DEB_BUILD_CFLAGS_MORE_SECURE

This seems too crackful to me TBH. Since this is a per-package
decision, why not just alter CFLAGS (or D_B_C) as appropriate for the
package in debian/rules?

> I'm open to whatever makes sense; I just need help on getting momentum 
> on which ever the "supported" direction is going to be.  Everyone seems 
> to agree that we need a way to enforce better compiler defaults 
> distro-wide. :)

Thanks for bringing this forward. I for one am willing to sacrifice
the slight 'debian/rules build' inconsistency for a solution which
actually has a chance to be implemented in a reasonable time. I would
just define 'dpkg-buildpackage is the way to get a Debian/Ubuntu
package'. You can already get different results by gradually
calling build steps manually, so it would just get a bit worse.

Thanks,

Martin

-- 
Martin Pitt         http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org