Still Failing: g-i-installation_debian_sid_daily_hurd_lxde/228
See https://jenkins.debian.net/job/g-i-installation_debian_sid_daily_hurd_lxde/228/ and https://jenkins.debian.net/job/g-i-installation_debian_sid_daily_hurd_lxde/228//console and https://jenkins.debian.net/job/g-i-installation_debian_sid_daily_hurd_lxde/228//artifact/results/ if there are any.
Re: Porter roll call for Debian Stretch
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
Re: Porter roll call for Debian Stretch
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
Processed: retitle 838392 to hurd should not build hurd-dev at stage2
Processing commands for cont...@bugs.debian.org: > retitle 838392 hurd should not build hurd-dev at stage2 Bug #838392 [hurd] dpkg: should build-depend on hurd-dev Changed Bug title to 'hurd should not build hurd-dev at stage2' from 'dpkg: should build-depend on hurd-dev'. > thanks Stopping processing here. Please contact me if you need assistance. -- 838392: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838392 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#838392: dpkg: should build-depend on hurd-dev
Processing control commands: > reassign -1 hurd Bug #838392 [dpkg] dpkg: should build-depend on hurd-dev Bug reassigned from package 'dpkg' to 'hurd'. No longer marked as found in versions dpkg/1.18.10. Ignoring request to alter fixed versions of bug #838392 to the same values previously set > block -1 by 818618 Bug #838392 [hurd] dpkg: should build-depend on hurd-dev 838392 was not blocked by any bugs. 838392 was not blocking any bugs. Added blocking bug(s) of 838392: 818618 -- 838392: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838392 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
