DEB_BUILD_CFLAGS and DEB_BUILD_LDFLAGS for packaging

Kees Cook kees at ubuntu.com
Thu May 3 22:47:29 BST 2007


Hi,

On Fri, Apr 20, 2007 at 01:51:11PM +0200, Martin Pitt wrote:
> Hm, I do not see a major obstacle to this; after all, it works well
> for ccache. What were the particular problems?

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.

> (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?

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

> 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.  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

> I am still looking for a way how to shy around (1), since the
> gain/effort ratio compared to (2) is so ludicrously small. However,
> the only solution for this that comes to my mind is to just define
> 'debian/rules build' as 'not the way how to build an official deb' and
> bless dpkg-buildpackage as the sole official interface that guarantees
> reproduction of buildd results.

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. :)

-- 
Kees Cook
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070503/9b1d77c5/attachment.pgp 


More information about the ubuntu-devel mailing list