Re: Porter roll call for Debian Stretch

2016-09-21 Thread Riku Voipio
On Tue, Sep 20, 2016 at 09:16:00PM +, Niels Thykier wrote:
> Over all, most people (who answered it) was positive towards the switch.
>  Based on this, I suspect that if we make PIE default in Stretch, then
> we will do it for all architectures.  That said, you will be notified if
> that default changes for Stretch.

Is this just for ASLR, or is ther another motivating factor for PIE?

AFAIK Address space randomizing is not really helpful on 32 bit 
architectures - there is just not that many places to randomize to[1].
At least previously, PIE added ~10% to binary size, which can have a major
performance impact on the 32-bit arm core's that don't have much cache to
begin with.

Riku
[1] https://cseweb.ucsd.edu/~hovav/dist/asrandom.pdf



Re: Porter roll call for Debian Stretch

2016-09-21 Thread Christian Seiler
On 09/21/2016 08:41 AM, Riku Voipio wrote:
> AFAIK Address space randomizing is not really helpful on 32 bit 
> architectures - there is just not that many places to randomize to[1].

Well, sure, but there's still a huge difference in an explot with
100% reliability, or an exploit that will just crash the program
in 95% of cases. Sure, if there's an easy way to repeatedly try
the exploit 20 times, it won't be a show-stopper, but it will
make the life of people who want to exploit a flaw just a tiny
bit harder.

> At least previously, PIE added ~10% to binary size,

At least on x86 there have been substantial improvements in
receent gcc versions when it comes to PIE support, so the impact
of PIE on executables even on 32bit is a lot smaller than it used
to be. I don't know about ARM though.

Consider the following two data points:

 - A _lot_ of code in Debian is in shared libraries, which are
   compiled with -fPIC anyway. Many executables only spend a
   fraction of their instructions in the executable code itself.

 - It's been considered best practice to enable PIE executables
   if possible (via hardening=+all or similar), so many programs
   in Debian (and e.g. all of my packages except one) already
   use that. I suspect that a lot of of code that you are
   currently running is already PIE, especially in the packages
   that are more actively maintained.

Regards,
Christian



Bug#838447: gtk+3.0: Please build documentation packages in binary-indep target

2016-09-21 Thread John Paul Adrian Glaubitz
Source: gtk+3.0
Version: 3.22.0-1
Severity: normal

Hi!

Currently, src:gtk+3.0 builds its documentation on all architectures which
is rather sub-optimal as this particular step in the build process is rather
time-consuming due to the fact that large XML files are parsed.

Additionally, the binary invoked, gtkdoc-mkhtml, also causes trouble when
building src:gtk+3.0 on architectures like m68k where we are using qemu:

cd html && gtkdoc-mkhtml $mkhtml_options 
"--path=\"/build/gtk+3.0-TswWzT/gtk+3.0-3.22.0/./docs/reference/gtk:/build/gtk+3.0-TswWzT/gtk+3.0-3.22.0/./examples\""
 gtk3 ../gtk-docs.sgml
Makefile:549: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Terminated
Makefile:1370: recipe for target 'html-build.stamp' failed
make[5]: *** [html-build.stamp] Terminated
Makefile:547: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Terminated
/usr/share/cdbs/1/class/makefile.mk:77: recipe for target 
'debian/stamp-makefile-build/shared' failed
make: *** [debian/stamp-makefile-build/shared] Terminated
E: Caught signal ‘Terminated’: terminating immediately
Makefile:722: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Terminated
Makefile:616: recipe for target 'all' failed
make[1]: *** [all] Terminated
E: Build killed with signal TERM after 60 minutes of inactivity

In order to get src:gtk+3.0 build on the affected architectures, I usually
edit the debian/rules file and disable the documentation by adding the
configure option '--disable-gtk-doc' to DEB_CONFIGURE_FLAGS_shared.

It would therefore be a good idea to build the documentation in the binary-indep
target in debian/rules only. This way, we would avoid issues like the one
above in the future and we also save quite a lot of build time on the
slower buildds.

Thanks for considering!

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913