Re: Bits from dpkg developers - dpkg 1.16.1
On Tue, Oct 4, 2011 at 11:33 AM, Roger Leigh wrote: > On Tue, Oct 04, 2011 at 09:29:27AM +0200, Bastien ROUCARIES wrote: >> On Mon, Oct 3, 2011 at 8:33 PM, Simon McVittie wrote: >> > On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote: >> >> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote: >> >> > Not necessarily. -fPIC and -fPIE force calls to global functions >> >> > defined in the same translation unit to go through the PLT. They >> >> > aren't translated to direct IP-relative calls. For -fPIC, this is >> >> > required by the ELF specification (no kidding, this might seem strange >> >> > today). >> >> >> >> Could we add a gcc flag and be non conformant ? I suppose it is only >> >> for using LD_PRELOAD. >> > >> > -Bsymbolic, I think? GLib uses this to speed up internal calls, instead of >> > the hacks with functions-having-two-names that it used to use. >> > >> > With either solution, if you want to LD_PRELOAD (as for GLib's refdbg tool) >> > you have to have a second copy of GLib compiled to not do that, like >> > libglib2.0-refdbg in Debian. >> >> Unbuntu use Bsymbolic by default and they are only a few faillure. >> Time to get this in debian too ? > > It would break overriding of weak symbols, would it not? Yes it will break but at least unbuntu have sorted this kind of bug https://bugs.launchpad.net/ubuntu/+source/libxfont/+bug/230460 And weak symbols are pretty rare in the tree. But I tend to agree that a Bsymbolic-nonweak will be the best see for instance an old patch http://www.cygwin.com/ml/binutils/2005-07/msg00104.html that tend to reduce ooo relocation by 20% Bastien > > Regards, > Roger > > -- > .''`. Roger Leigh > : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ > `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ > `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20111004093323.gc11...@codelibre.net > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAbYsXoJxhNk6=jQbR4oSttCPwJvUVF=1wyitpycfto...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
On Tue, Oct 04, 2011 at 09:29:27AM +0200, Bastien ROUCARIES wrote: > On Mon, Oct 3, 2011 at 8:33 PM, Simon McVittie wrote: > > On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote: > >> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote: > >> > Not necessarily. -fPIC and -fPIE force calls to global functions > >> > defined in the same translation unit to go through the PLT. They > >> > aren't translated to direct IP-relative calls. For -fPIC, this is > >> > required by the ELF specification (no kidding, this might seem strange > >> > today). > >> > >> Could we add a gcc flag and be non conformant ? I suppose it is only > >> for using LD_PRELOAD. > > > > -Bsymbolic, I think? GLib uses this to speed up internal calls, instead of > > the hacks with functions-having-two-names that it used to use. > > > > With either solution, if you want to LD_PRELOAD (as for GLib's refdbg tool) > > you have to have a second copy of GLib compiled to not do that, like > > libglib2.0-refdbg in Debian. > > Unbuntu use Bsymbolic by default and they are only a few faillure. > Time to get this in debian too ? It would break overriding of weak symbols, would it not? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111004093323.gc11...@codelibre.net
Re: Bits from dpkg developers - dpkg 1.16.1
On Mon, Oct 3, 2011 at 7:31 PM, Bernhard R. Link wrote: > * Bastien ROUCARIES [111003 17:27]: >> > Not necessarily. -fPIC and -fPIE force calls to global functions >> > defined in the same translation unit to go through the PLT. They >> > aren't translated to direct IP-relative calls. For -fPIC, this is >> > required by the ELF specification (no kidding, this might seem strange >> > today). >> >> Could we add a gcc flag and be non conformant ? I suppose it is only >> for using LD_PRELOAD. > > Breaking -fPIC globally by changing gcc is a bad idea. > (If any library needs the improvement, it can always specify what to > call itself, which then has the added bonus of also doing this for > calls between different translation units of the same library). No I means using Bsymbolic by default on debian. Will break a few package but unbuntu has already sorted this issue (they built with Bsymbolic by default). Bastien > Bernhard R. Link > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20111003173112.ga13...@server.brlink.eu > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spaykwd1fp4qj2ci_i6u_js_3mr7ed+jmxdbv-wf3zvf...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
On Mon, Oct 3, 2011 at 8:33 PM, Simon McVittie wrote: > On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote: >> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote: >> > Not necessarily. -fPIC and -fPIE force calls to global functions >> > defined in the same translation unit to go through the PLT. They >> > aren't translated to direct IP-relative calls. For -fPIC, this is >> > required by the ELF specification (no kidding, this might seem strange >> > today). >> >> Could we add a gcc flag and be non conformant ? I suppose it is only >> for using LD_PRELOAD. > > -Bsymbolic, I think? GLib uses this to speed up internal calls, instead of > the hacks with functions-having-two-names that it used to use. > > With either solution, if you want to LD_PRELOAD (as for GLib's refdbg tool) > you have to have a second copy of GLib compiled to not do that, like > libglib2.0-refdbg in Debian. Unbuntu use Bsymbolic by default and they are only a few faillure. Time to get this in debian too ? > S > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/20111003183344.ga25...@reptile.pseudorandom.co.uk > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAZQo0vtYo70HhMqhWZ+hhZ8FECbHZG0=5pqsgbnjxm...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote: > On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote: > > Not necessarily. -fPIC and -fPIE force calls to global functions > > defined in the same translation unit to go through the PLT. They > > aren't translated to direct IP-relative calls. For -fPIC, this is > > required by the ELF specification (no kidding, this might seem strange > > today). > > Could we add a gcc flag and be non conformant ? I suppose it is only > for using LD_PRELOAD. -Bsymbolic, I think? GLib uses this to speed up internal calls, instead of the hacks with functions-having-two-names that it used to use. With either solution, if you want to LD_PRELOAD (as for GLib's refdbg tool) you have to have a second copy of GLib compiled to not do that, like libglib2.0-refdbg in Debian. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003183344.ga25...@reptile.pseudorandom.co.uk
Re: Bits from dpkg developers - dpkg 1.16.1
* Alastair McKinstry [111003 12:48]: > I would defend static libs for scientific apps. Static libs show a > significant performance > benefit (2-40%, median around 5-10% but sometimes far more with C++ > apps) Are those numbers only the position independent code (I guess mostly the register available less) or also the PLT-relative calls? The latter can usually be reduced a bit by using making functions static, more by using -fvisibility=hidden (and marking to be exported symbols) and totally by visibility combined with aliases. So properly done (yes, yes, I know, scientific programming is the opposite of properly done) the only downsize would be the missing register, which should mostly only be measureable on 32 bit i386 programs. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003175439.gd13...@server.brlink.eu
Re: Bits from dpkg developers - dpkg 1.16.1
* Bastien ROUCARIES [111003 17:27]: > > Not necessarily. -fPIC and -fPIE force calls to global functions > > defined in the same translation unit to go through the PLT. They > > aren't translated to direct IP-relative calls. For -fPIC, this is > > required by the ELF specification (no kidding, this might seem strange > > today). > > Could we add a gcc flag and be non conformant ? I suppose it is only > for using LD_PRELOAD. Breaking -fPIC globally by changing gcc is a bad idea. (If any library needs the improvement, it can always specify what to call itself, which then has the added bonus of also doing this for calls between different translation units of the same library). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003173112.ga13...@server.brlink.eu
Re: Bits from dpkg developers - dpkg 1.16.1
On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote: > * Adam Borowski: > >>> I would defend static libs for scientific apps. Static libs show a >>> significant performance benefit (2-40%, median around 5-10% but sometimes >>> far more with C++ apps) and so are standard in HPC still; >> >> If you see that big a difference, you do a lot of cross-file calls in >> tight loops. > > Not necessarily. -fPIC and -fPIE force calls to global functions > defined in the same translation unit to go through the PLT. They > aren't translated to direct IP-relative calls. For -fPIC, this is > required by the ELF specification (no kidding, this might seem strange > today). Could we add a gcc flag and be non conformant ? I suppose it is only for using LD_PRELOAD. Bastien > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/87d3eefcsv@mid.deneb.enyo.de > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAaWyJb7GGnQT4cj+A0c9748a0CtSB8XMij5gP=vfdd...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
* Bastien ROUCARIES: > On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote: >> * Adam Borowski: >> I would defend static libs for scientific apps. Static libs show a significant performance benefit (2-40%, median around 5-10% but sometimes far more with C++ apps) and so are standard in HPC still; >>> >>> If you see that big a difference, you do a lot of cross-file calls in >>> tight loops. >> >> Not necessarily. -fPIC and -fPIE force calls to global functions >> defined in the same translation unit to go through the PLT. They >> aren't translated to direct IP-relative calls. For -fPIC, this is >> required by the ELF specification (no kidding, this might seem strange >> today). > > Could we add a gcc flag and be non conformant ? I'm not sure if this is worth the deviation from upstream. If we want to break ABI, there far better options. > I suppose it is only for using LD_PRELOAD. Not sure. LD_PRELOAD still works for cross-library calls, but it would cease to redirect library-internal calls. I really don't know why ELF does this. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcs6drx9@mid.deneb.enyo.de
Re: Bits from dpkg developers - dpkg 1.16.1
* Adam Borowski: >> I would defend static libs for scientific apps. Static libs show a >> significant performance benefit (2-40%, median around 5-10% but sometimes >> far more with C++ apps) and so are standard in HPC still; > > If you see that big a difference, you do a lot of cross-file calls in > tight loops. Not necessarily. -fPIC and -fPIE force calls to global functions defined in the same translation unit to go through the PLT. They aren't translated to direct IP-relative calls. For -fPIC, this is required by the ELF specification (no kidding, this might seem strange today). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3eefcsv@mid.deneb.enyo.de
Re: Bits from dpkg developers - dpkg 1.16.1
* Henrique de Moraes Holschuh: > On Sun, 02 Oct 2011, Florian Weimer wrote: >> Couldn't we get rid of static libraries altogether, replacing static >> linking with ahead-of-time dynamic linking? > > Well, the normal usecase for static libraries and static linking is to > produce self-contained objects. If you can link a bunch of dynamic > objects into a self-contained object that behaves as a static-linked > object would, I'd say that yes, we could probably do away with static > libraries. It's technically conceivable in the sense that the required data is present in DSOs. I don't know if it's been implemented. > I do think it is a bad idea, though. We don't provide libraries just > for ourselves, we also provide them for the user to use when building > his own stuff and they might have other usecases. So it's probably necessary to continue compiling static libraries without -fPIC. This precludes statically linked PIE executables, but that's probably okay. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqiefgio@mid.deneb.enyo.de
Re: Bits from dpkg developers - dpkg 1.16.1
On Mon, Oct 03, 2011 at 11:20:11AM +0100, Alastair McKinstry wrote: > On 2011-10-02 23:08, Henrique de Moraes Holschuh wrote: > >On Sun, 02 Oct 2011, Florian Weimer wrote: > >>Couldn't we get rid of static libraries altogether, replacing static > >>linking with ahead-of-time dynamic linking? > > > I would defend static libs for scientific apps. Static libs show a > significant performance benefit (2-40%, median around 5-10% but sometimes > far more with C++ apps) and so are standard in HPC still; If you see that big a difference, you do a lot of cross-file calls in tight loops. This means you would greatly benefit of compiling with -flto instead. GCC doesn't allow linking flto objects from even slightly different compiler versions though as gimple format is not considered stable, so shipping precompiled static objects is no good. So what about shipping source instead so the user can optimize the heck out of it? -- 1KB // Yo momma uses IPv4! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003112333.ga2...@angband.pl
Re: Bits from dpkg developers - dpkg 1.16.1
On 2011-10-02 23:08, Henrique de Moraes Holschuh wrote: On Sun, 02 Oct 2011, Florian Weimer wrote: Couldn't we get rid of static libraries altogether, replacing static linking with ahead-of-time dynamic linking? [1] but I don't feel strong enough about it to get in the way if we do decide to drop static libs. I would defend static libs for scientific apps. Static libs show a significant performance benefit (2-40%, median around 5-10% but sometimes far more with C++ apps) and so are standard in HPC still; so I ship them in my packages even though they are not used much within the software shipped _by_ debian, but are used by our users. Note: this is for static libs without -fPIC. I'm not sure there is much benefit in shipping PIC static libs, (or potentially PIE codes); they are also highly unlikely to be used in 'web-facing' environments, and be security-sensitive; they are likely to be built by the user, used by that particular user alone, and hence should not be built with any security features( eg PIE) that cause performance degradation. -- Alastair McKinstry , , http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e898c5b.4010...@sceal.ie
Re: Bits from dpkg developers - dpkg 1.16.1
On Sun, 02 Oct 2011, Florian Weimer wrote: > Couldn't we get rid of static libraries altogether, replacing static > linking with ahead-of-time dynamic linking? Well, the normal usecase for static libraries and static linking is to produce self-contained objects. If you can link a bunch of dynamic objects into a self-contained object that behaves as a static-linked object would, I'd say that yes, we could probably do away with static libraries. I do think it is a bad idea, though. We don't provide libraries just for ourselves, we also provide them for the user to use when building his own stuff and they might have other usecases. Doing away with static libraries does not look like a service to our users at first glance[1]. Fixing [upstream] any braindead crap that gets in the way of proper static linking, OTOH, is useful to everybody... [1] but I don't feel strong enough about it to get in the way if we do decide to drop static libs. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111002220848.ge16...@khazad-dum.debian.net
Re: Bits from dpkg developers - dpkg 1.16.1
* Florian Weimer (f...@deneb.enyo.de) [111002 21:59]: > Couldn't we get rid of static libraries altogether, replacing static > linking with ahead-of-time dynamic linking? Could you explain what this means for people not so deep into that? (E.g. how is the linking done? When? What does that mean for compilation? ...) Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111002204640.gv15...@mails.so.argh.org
Re: Bits from dpkg developers - dpkg 1.16.1
* Kees Cook: > When we decide to build an entire architecture as PIE, then we'll also need > to build those static libs with -fPIE too. Couldn't we get rid of static libraries altogether, replacing static linking with ahead-of-time dynamic linking? There's still a theoretical difference between -fPIE and -fPIC: -fPIE can use non-indirect IP-relative function calls even for unhidden symbols. But GCC currently doesn't use this opportunity, as far as I can tell, so static libraries really seem a bit superfluous. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lit3qj7w@mid.deneb.enyo.de
Re: Bits from dpkg developers - dpkg 1.16.1
On Thu, Sep 29, 2011 at 06:41:29AM +0900, Charles Plessy wrote: > Le Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook a écrit : > > On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote: > > > Two hardening features are not enabled by default: PIE and bindnow. > > > If your package supports PIE, you might want to consider enabling it. > > > If the binaries are long running processes like daemons, and as such > > > the startup performance penalty of “bindnow” is acceptable, it might > > > be a good idea to enable it too but only if relro is in effect, > > > although another option might be to just define LD_BIND_NOW=1 on the > > > daemon's environment (for example in the init.d script), in which case > > > the sysadmin can always disable it, something that's not possible with > > > the build option. > > > > Just to be explicit, PIE tends to have small (<1%) performance hits on > > register-starved architectures (i386) in most cases, for for certain work > > loads (e.g. python) the hit is large (~15%). On architectures with plenty > > of registers (amd64) there's virtually no measurable performance hit that > > I've seen. > > By the way – and please pardon me if it is a too naive question – does this > recommendation of building packages with PIE when possible make obsolete the > recommendation of Policy's §10.2 to not build static libraries with -fPIC ? > > http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries It will only complicate things if a PIE executable needs to link against a static library like that, which is a relatively uncommon situation in the archive. When we decide to build an entire architecture as PIE, then we'll also need to build those static libs with -fPIE too. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111001175008.gs6...@outflux.net
Re: Bits from dpkg developers - dpkg 1.16.1
On Wed, Sep 28, 2011 at 11:38:06PM +0200, Mike Hommey wrote: > On Wed, Sep 28, 2011 at 10:52:15PM +0300, Riku Voipio wrote: > > On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote: > > > Just to be explicit, PIE tends to have small (<1%) performance hits on > > > register-starved architectures (i386) in most cases, for for certain work > > > loads (e.g. python) the hit is large (~15%). On architectures with plenty > > > of registers (amd64) there's virtually no measurable performance hit that > > > I've seen. > > > > > If your package handles 3rd party data of any kind (renders, network > > > daemons, file parsers, etc), I strongly recommend enabling PIE. > > > > However, on 32bit architectures address space randomizing (which is why > > people try sell PIE as a security feature) does not add much security. > > > > http://benpfaff.org/papers/asrandom.pdf > > Also note that as long as you can read memory in the process and have > access to /proc/self/auxv, you can find the base address of all > libraries. The auxv file isn't readable after a uid transition, and if an attacker has sufficient control over a process to read /proc/self, ASLR is already a non-issue for that exploit. :) That said, yes, plugging leaks of process memory locations is important when defending against local attacks. Remote attacks will have many fewer opportunities for finding memory location leaks. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111001174541.gr6...@outflux.net
Re: Bits from dpkg developers - dpkg 1.16.1
On Wed, Sep 28, 2011 at 10:52:15PM +0300, Riku Voipio wrote: > On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote: > > Just to be explicit, PIE tends to have small (<1%) performance hits on > > register-starved architectures (i386) in most cases, for for certain work > > loads (e.g. python) the hit is large (~15%). On architectures with plenty > > of registers (amd64) there's virtually no measurable performance hit that > > I've seen. > > > If your package handles 3rd party data of any kind (renders, network > > daemons, file parsers, etc), I strongly recommend enabling PIE. > > However, on 32bit architectures address space randomizing (which is why > people try sell PIE as a security feature) does not add much security. > > http://benpfaff.org/papers/asrandom.pdf This paper does a great job demonstrating why ASLR is only a statistical protection. (And that on small address space systems, the protection is more limited.) This does not, however, detract from the fact that it's still another layer that needs to be bypassed by an attacker. The effects of the bypass attempt also change based on the environment. Is it the kernel itself? Frequently you can't just try again since the machine will have fallen over. Attacking a respawning daemon? Suddenly the attack shows up as a spike in respawns, etc. No security protection is a silver bullet, and ASLR is no different. That said, weighing the potential benefit (which is non-zero) against possible performance impacts is up to the maintainer. I would opt for adding a protection in almost all cases. I'd like to see PIE enabled for all amd64 builds, but one step at a time. :) -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111001174133.gq6...@outflux.net
Re: Bits from dpkg developers - dpkg 1.16.1
Le Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook a écrit : > On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote: > > Two hardening features are not enabled by default: PIE and bindnow. > > If your package supports PIE, you might want to consider enabling it. > > If the binaries are long running processes like daemons, and as such > > the startup performance penalty of “bindnow” is acceptable, it might > > be a good idea to enable it too but only if relro is in effect, > > although another option might be to just define LD_BIND_NOW=1 on the > > daemon's environment (for example in the init.d script), in which case > > the sysadmin can always disable it, something that's not possible with > > the build option. > > Just to be explicit, PIE tends to have small (<1%) performance hits on > register-starved architectures (i386) in most cases, for for certain work > loads (e.g. python) the hit is large (~15%). On architectures with plenty > of registers (amd64) there's virtually no measurable performance hit that > I've seen. By the way – and please pardon me if it is a too naive question – does this recommendation of building packages with PIE when possible make obsolete the recommendation of Policy's §10.2 to not build static libraries with -fPIC ? http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110928214129.ge9...@merveille.plessy.net
Re: Bits from dpkg developers - dpkg 1.16.1
On Wed, Sep 28, 2011 at 10:52:15PM +0300, Riku Voipio wrote: > On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote: > > Just to be explicit, PIE tends to have small (<1%) performance hits on > > register-starved architectures (i386) in most cases, for for certain work > > loads (e.g. python) the hit is large (~15%). On architectures with plenty > > of registers (amd64) there's virtually no measurable performance hit that > > I've seen. > > > If your package handles 3rd party data of any kind (renders, network > > daemons, file parsers, etc), I strongly recommend enabling PIE. > > However, on 32bit architectures address space randomizing (which is why > people try sell PIE as a security feature) does not add much security. > > http://benpfaff.org/papers/asrandom.pdf Also note that as long as you can read memory in the process and have access to /proc/self/auxv, you can find the base address of all libraries. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110928213806.ga30...@glandium.org
Re: Bits from dpkg developers - dpkg 1.16.1
On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote: > Just to be explicit, PIE tends to have small (<1%) performance hits on > register-starved architectures (i386) in most cases, for for certain work > loads (e.g. python) the hit is large (~15%). On architectures with plenty > of registers (amd64) there's virtually no measurable performance hit that > I've seen. > If your package handles 3rd party data of any kind (renders, network > daemons, file parsers, etc), I strongly recommend enabling PIE. However, on 32bit architectures address space randomizing (which is why people try sell PIE as a security feature) does not add much security. http://benpfaff.org/papers/asrandom.pdf Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110928195215.ga24...@afflict.kos.to
Re: Bits from dpkg developers - dpkg 1.16.1
* Ian Jackson [110927 20:21]:
> Bernhard R. Link writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> > CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal
> > things to be in a users environment, so a package's rules file should
> > in my eyes not depend on them not being set or having any values sensible.
>
> This tells us more about the reliability of your opinion than it does
> about build systems.
Thanks in advance for keeping personal attacks out of the discussion
in the future.
> In general, upstream build systems cannot be
> relied on do to anything sane or predictable if they are run with
> these variables in the environment.
While some upstream build systems have problems with those flags,
most broken ones simply ignore them (unlike setting them as
make variables on the command line, where much more break).
automake/autoconf usually do a very good job on respecting those
variables and if some project fails to handle those properly, they
usually do so in not respecting a setting in the environment at
configure time (by overwriting it) or by adding stuff to it at
configure time so that running make with different flags given
as arguments misses those arguments (which is well for additional
warning flags and stuff like that but not for things like including
private headers), but both of those cases also cause no problem.
If mostly dealing with auto* projects, having some
CPPFLAGS=-I~/stuff/include and LDFLAGS=-L~/stuff/lib
together with some LD_LIBRARY_PATH is an very easy way to
develop as user without root priviledges (just needing
--prefix=~/stuff then for all configure runs).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110928085838.ga30...@server.brlink.eu
Re: Bits from dpkg developers - dpkg 1.16.1
On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote: > Two hardening features are not enabled by default: PIE and bindnow. > If your package supports PIE, you might want to consider enabling it. > If the binaries are long running processes like daemons, and as such > the startup performance penalty of “bindnow” is acceptable, it might > be a good idea to enable it too but only if relro is in effect, > although another option might be to just define LD_BIND_NOW=1 on the > daemon's environment (for example in the init.d script), in which case > the sysadmin can always disable it, something that's not possible with > the build option. Just to be explicit, PIE tends to have small (<1%) performance hits on register-starved architectures (i386) in most cases, for for certain work loads (e.g. python) the hit is large (~15%). On architectures with plenty of registers (amd64) there's virtually no measurable performance hit that I've seen. If your package handles 3rd party data of any kind (renders, network daemons, file parsers, etc), I strongly recommend enabling PIE. And, if you enable PIE, please enable bindnow too. The start-up performance hit of bindnow isn't measurable on most architectures. Some much slower ones can see problems (early ARM). It's possible that PIE and/or bindnow may be enabled by default for certain architectures in the future. If your package is using hardening-wrapper or hardening-includes, you were effectively using "+pie,+bindnow", so when converting, please continue to build with PIE and bindnow. :) Thanks! -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110928010154.gh6...@outflux.net
Re: Bits from dpkg developers - dpkg 1.16.1
Bernhard R. Link writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal
> things to be in a users environment, so a package's rules file should
> in my eyes not depend on them not being set or having any values sensible.
This tells us more about the reliability of your opinion than it does
about build systems. In general, upstream build systems cannot be
relied on do to anything sane or predictable if they are run with
these variables in the environment.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20098.4075.529503.254...@chiark.greenend.org.uk
Re: Bits from dpkg developers - dpkg 1.16.1
* Bernd Zeimetz [110927 15:36]: > > I'm one of the submitters of one of the bugs which requested this > > change. This is a reversion of dpkg to a previous behaviour, and it > > /un/breaks packages. Or at least I think it unbreaks much more than > > it breaks. > > ACtually I think that is true - the exported *FLAGS broke various of the > packages I maintain, mainly due to LDFLAGS breaking the build of Python > extensions or other kinds of plugins. CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal things to be in a users environment, so a package's rules file should in my eyes not depend on them not being set or having any values sensible. So while I think dpkg-buildpackage not setting something there which could cause people to think using the environment in debian/rules for those is OK is better than dpkg-buildpackage setting them, I'd consider a dpkg-buildpackage that sets CFLAGS, CPPFLAGS and LDFLAGS all to "-fyour-rules-file-is-broken" even better. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110927163107.gd29...@server.brlink.eu
Re: Bits from dpkg developers - dpkg 1.16.1
On 09/24/2011 05:48 PM, Ian Jackson wrote:
> Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
>> Raphael Hertzog wrote:
>>> * dpkg-buildpackage no longer exports
>>> CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS
>>
>> | You don't know how many packages are broken or no longer
>> | policy compliant because they were relying on those environment
>> | variables
>>
>> Who said that? Oh, yeah it was you.
>>
>> How are we supposed to deal with packages that have been broken or made
>> policy incompliant by this change to dpkg?
>
> I'm one of the submitters of one of the bugs which requested this
> change. This is a reversion of dpkg to a previous behaviour, and it
> /un/breaks packages. Or at least I think it unbreaks much more than
> it breaks.
ACtually I think that is true - the exported *FLAGS broke various of the
packages I maintain, mainly due to LDFLAGS breaking the build of Python
extensions or other kinds of plugins.
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e81ca91.1050...@debian.org
Re: Bits from dpkg developers - dpkg 1.16.1
I wrote:
> Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> > My concern is that we now have a whole history of ill-considered changes
> > to the build flags. To the point that it's possible to argue that every
> > build flag change save one* has been ill-considered. So why are we
> > continuing to add interfaces where the build flags are changed
> > centrally/globally, with the same processes that have not worked before?
>
> In one sense, yes, we are providing a way to set these flags locally.
should read globally ^^^
> But the new mechanism will make it much easier to locally override
> such settings (where "locally" means either in the package, in the
> build environment).
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20097.48549.383313.265...@chiark.greenend.org.uk
Re: Bits from dpkg developers - dpkg 1.16.1
Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> Ian Jackson wrote:
> > It was always completely wrong of dpkg-buildpackage to set these
> > variables. Source packages are entitled to assume that strange
> > environment variables which cause their tools to do odd things will
> > not be set.
>
> I'm willing to not worry about the likelihood that many packages added
> or updated over the past few years, while dpkg-buildpackage was forcing
> build flags, will not be built properly optimised now. That seems
> unlikely to completely break many of them, and as you say, forced build
> flags were always wrong, and we may just have to suck it up and deal
> with the breakage to get back to sanity.
Right. (Also those forced build flags would sometimes cause the build
to break entirely.)
> My concern is that we now have a whole history of ill-considered changes
> to the build flags. To the point that it's possible to argue that every
> build flag change save one* has been ill-considered. So why are we
> continuing to add interfaces where the build flags are changed
> centrally/globally, with the same processes that have not worked before?
In one sense, yes, we are providing a way to set these flags locally.
But the new mechanism will make it much easier to locally override
such settings (where "locally" means either in the package, in the
build environment).
> The build flags interface either needs some sort of compatability
> versioning, or the default build flags need to be specified in policy,
> and only changed with the same care we take with other policy changes
> that can make massive numbers of packages instabuggy.
I agree that we need a good process for testing default build flags
changes before propagating them. I'm not sure policy is the right
forum, but debian-devel is. Perhaps the policy should be that we
don't change the default flags without consultation here ?
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20097.46611.997488.647...@chiark.greenend.org.uk
Re: Bits from dpkg developers - dpkg 1.16.1
On Monday, September 26, 2011 08:21:19 PM Raphael Hertzog wrote: > On Mon, 26 Sep 2011, Scott Kitterman wrote: > > I can see where this might be useful for final work before an upload, > > what is one expected to do when one is doing successive builds where > > things change every time while working on a package? dpkg-buildpackage > > -b, "Oh, fail", "dpkg-source --commit", "no, no DEP-3, it's not a > > permenent patch, please go away", dpkg-buildpackage -b is getting > > tiring very quickly. > > "dpkg-buildpackage -b" doesn't rebuild the source package so it can't > fail. Right. Without the -b. Sorry. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1669246.GnDma2LIHB@scott-latitude-e6320
Re: Bits from dpkg developers - dpkg 1.16.1
On Mon, 26 Sep 2011, Scott Kitterman wrote: > I can see where this might be useful for final work before an upload, what is > one expected to do when one is doing successive builds where things change > every time while working on a package? dpkg-buildpackage -b, "Oh, fail", > "dpkg-source --commit", "no, no DEP-3, it's not a permenent patch, please go > away", dpkg-buildpackage -b is getting tiring very quickly. "dpkg-buildpackage -b" doesn't rebuild the source package so it can't fail. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110926182119.gc27...@rivendell.home.ouaza.com
Re: Bits from dpkg developers - dpkg 1.16.1
On Friday, September 23, 2011 08:17:54 AM Raphael Hertzog wrote: > * “dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail > if it detects upstream changes which are not managed by a quilt patch. > > You are expected to call “dpkg-source --commit” if you want to > record those changes permanently. In this process, you will have > to give a patch name and you will be invited to edit the DEP-3 > headers[1] of the new patch. I can see where this might be useful for final work before an upload, what is one expected to do when one is doing successive builds where things change every time while working on a package? dpkg-buildpackage -b, "Oh, fail", "dpkg-source --commit", "no, no DEP-3, it's not a permenent patch, please go away", dpkg-buildpackage -b is getting tiring very quickly. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/13443571.3WdoJ55DQj@scott-latitude-e6320
Re: Bits from dpkg developers - dpkg 1.16.1
On Mon, Sep 26, 2011 at 12:26 AM, Michael Gilbert wrote: > I should have been more explicit. I was referring to dpkg-buildflags > default outputs above. I see, agreed then. > I'm ok with the fact that each individual package will need to > be changed to support this (vice forcing it into gcc). I am not, I find it an utterly ridiculous course of action that will result in incomplete coverage 5 years down the track. The right way to do it would be to get GCC upstream to enable it by default. Of course now that most packages have relied on dpkg for enabling -O2, we would still need to fix them again, so that -D_FORTIFY_SOURCE=2 works again. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6FrvCo01R=prpnyylhg7i52uzmgp3rqely2nogjcbo...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
Paul Wise wrote: > On Sun, Sep 25, 2011 at 5:11 AM, Michael Gilbert wrote: > > > I think it would be better to enable all security-enhancing flags by > > default (at least all of the included ones so far, which are fairly > > well-tested). Yes, these two do have a larger potential to reduce > > performance, but its also sufficiently straightforward to add > > -pie,-bindnow to disable them. Thus, maintainers that do find > > performance issues after adding the flags, can easily solve the problem > > they've created. > > IIRC the Debian GCC maintainer did not want to enable these > security-enhancing flags. The only way to get these flags enabled by > default would be to talk with GCC upstream and hope that the Debian > GCC maintainer does not disable them. I should have been more explicit. I was referring to dpkg-buildflags default outputs above. I'm ok with the fact that each individual package will need to be changed to support this (vice forcing it into gcc). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110925122647.0fc66f66ebb27faac2039...@gmail.com
Re: Format 3.0 (git) (was: Re: single-debian-patch (was Re: Bits from dpkg developers - dpkg 1.16.1))
On Sat, 24 Sep 2011, Charles Plessy wrote: > If in a large number of cases where one would like to turn off the patch > system > of the 3.0 (quilt) format, the source package is stored in a Git repository, > then one way to move forward would be to make the format 3.0 (git) available > in Debian. What are the blocking points ? AFAIK, the _real_ problem is that the ftpmasters do not consiter it acceptable to packages to ship their entire history, and that's a fatal problem that has no simple solution. Shipping the whole history means you have to check the entire history for DFSG compliance. There's also the nasty detail that you have to destroy history past any point where an undistributable blob exists to make the whole thing distributable. Another problem is that you either face an unbounded increase in size over time, or you have to ship git shallow clones, which are not self-contained and very nasty to work with. I don't think we will have 3.0 (git) in Debian anytime soon, if ever. Corrections by any of the ftpmasters if I got any of this wrong, are very welcome. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110925024542.ga32...@khazad-dum.debian.net
Re: Format 3.0 (git) (was: Re: single-debian-patch (was Re: Bits from dpkg developers - dpkg 1.16.1))
On Sat, Sep 24, 2011 at 2:30 PM, Charles Plessy wrote: > If in a large number of cases where one would like to turn off the patch > system > of the 3.0 (quilt) format, the source package is stored in a Git repository, > then one way to move forward would be to make the format 3.0 (git) available > in Debian. What are the blocking points ? The main blocking point is that ftpmasters will not allow it into the archive. The folks on debian-devel are not the ones you need to convince about the format, this mail should have been directed to the ftpmasters instead. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6F-GetEFnOyD9kxB=ypoj70q8t2-qqh6gtjpadic0k...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
Ian Jackson wrote: > I'm one of the submitters of one of the bugs which requested this > change. This is a reversion of dpkg to a previous behaviour, and it > /un/breaks packages. Or at least I think it unbreaks much more than > it breaks. > > It was always completely wrong of dpkg-buildpackage to set these > variables. Source packages are entitled to assume that strange > environment variables which cause their tools to do odd things will > not be set. I'm willing to not worry about the likelihood that many packages added or updated over the past few years, while dpkg-buildpackage was forcing build flags, will not be built properly optimised now. That seems unlikely to completely break many of them, and as you say, forced build flags were always wrong, and we may just have to suck it up and deal with the breakage to get back to sanity. My concern is that we now have a whole history of ill-considered changes to the build flags. To the point that it's possible to argue that every build flag change save one* has been ill-considered. So why are we continuing to add interfaces where the build flags are changed centrally/globally, with the same processes that have not worked before? The build flags interface either needs some sort of compatability versioning, or the default build flags need to be specified in policy, and only changed with the same care we take with other policy changes that can make massive numbers of packages instabuggy. -- see shy jo * As the exception that proves the rule, there was a proper cost/benefit analysis of adding -Werror=format-security, concluding that the 5% or so of packages that it breaks are likely to have security holes that it will aid in fixing. signature.asc Description: Digital signature
Re: Bits from dpkg developers - dpkg 1.16.1
On Sun, Sep 25, 2011 at 5:11 AM, Michael Gilbert wrote: > I think it would be better to enable all security-enhancing flags by > default (at least all of the included ones so far, which are fairly > well-tested). Yes, these two do have a larger potential to reduce > performance, but its also sufficiently straightforward to add > -pie,-bindnow to disable them. Thus, maintainers that do find > performance issues after adding the flags, can easily solve the problem > they've created. IIRC the Debian GCC maintainer did not want to enable these security-enhancing flags. The only way to get these flags enabled by default would be to talk with GCC upstream and hope that the Debian GCC maintainer does not disable them. > As it stands now being a non-default setting, most packages will end up > not getting these protections, which I think is less desirable than > having most fully protected and only a small subset with reduced > protections. Agreed. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GN=TFTdNTWwADWhMwFGzwq_pZSYV+=m-jgbzlfb1t...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
berta...@ptitcanardnoir.org wrote: > On Fri, Sep 23, 2011 at 11:53:36AM +0200, Marco d'Itri wrote: > > On Sep 23, Raphael Hertzog wrote: > > > > > Two hardening features are not enabled by default: PIE and bindnow. > > Why? > > I guess because they have more impact on performance than the others. Hi, I think it would be better to enable all security-enhancing flags by default (at least all of the included ones so far, which are fairly well-tested). Yes, these two do have a larger potential to reduce performance, but its also sufficiently straightforward to add -pie,-bindnow to disable them. Thus, maintainers that do find performance issues after adding the flags, can easily solve the problem they've created. As it stands now being a non-default setting, most packages will end up not getting these protections, which I think is less desirable than having most fully protected and only a small subset with reduced protections. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110924171133.68c6c6af9e5cb45dc9fca...@gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> Raphael Hertzog wrote:
> > * dpkg-buildpackage no longer exports
> > CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS
>
> | You don't know how many packages are broken or no longer
> | policy compliant because they were relying on those environment
> | variables
>
> Who said that? Oh, yeah it was you.
>
> How are we supposed to deal with packages that have been broken or made
> policy incompliant by this change to dpkg?
I'm one of the submitters of one of the bugs which requested this
change. This is a reversion of dpkg to a previous behaviour, and it
/un/breaks packages. Or at least I think it unbreaks much more than
it breaks.
It was always completely wrong of dpkg-buildpackage to set these
variables. Source packages are entitled to assume that strange
environment variables which cause their tools to do odd things will
not be set.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20093.64447.724751.724...@chiark.greenend.org.uk
Format 3.0 (git) (was: Re: single-debian-patch (was Re: Bits from dpkg developers - dpkg 1.16.1))
Hello everybody, If in a large number of cases where one would like to turn off the patch system of the 3.0 (quilt) format, the source package is stored in a Git repository, then one way to move forward would be to make the format 3.0 (git) available in Debian. What are the blocking points ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110924063002.gh13...@merveille.plessy.net
Re: Bits from dpkg developers - dpkg 1.16.1
On Fri, 23 Sep 2011 08:17:54 +0200, Raphael Hertzog wrote: > * “dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail > if it detects upstream changes which are not managed by a quilt patch. > * When dpkg-source automatically applies patches at the start of the > build process, it will also automatically unapply them at the end > of a successful build. That's great news and saves quite some work [0] -- thank you! Cheers, gregor [0] cf. the discussions in http://bugs.debian.org/612356 -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key ID: 0x8649AA06 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Nick Cave And The Bad Seeds: Cannibal's Hymn signature.asc Description: Digital signature
Re: Bits from dpkg developers - dpkg 1.16.1
Raphael Hertzog wrote: > * dpkg-buildpackage no longer exports CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS | You don't know how many packages are broken or no longer | policy compliant because they were relying on those environment | variables Who said that? Oh, yeah it was you. How are we supposed to deal with packages that have been broken or made policy incompliant by this change to dpkg? -- see shy jo signature.asc Description: Digital signature
Re: single-debian-patch (was Re: Bits from dpkg developers - dpkg 1.16.1)
On Fri, 23 Sep 2011, Adam Borowski wrote: > Old-style: rm -rf .pc debian/patches > New-style: echo "single-debian-patch" >debian/source/options --single-debian-patch is no longer "new" at this point. The fact that you were not using it and relying on dpkg-source to generate a different patch at each upload was just bad taste IMO. Most people relying on dpkg-source to generate the patch of what's stored in the VCS are already using single-debian-patch (BTW, it's better to put it in debian/source/local-options). And as you noted, we took care to ensure that people relying on this option don't get the new behaviour. > It'd be nice if the error message pointed us to the new way. I'm afraid the error message is already verbose enough and I don't want to give conflicting recommendations. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110923124106.gd21...@rivendell.home.ouaza.com
Re: Bits from dpkg developers - dpkg 1.16.1
On Fri, Sep 23, 2011 at 11:53:36AM +0200, Marco d'Itri wrote: > On Sep 23, Raphael Hertzog wrote: > > > Two hardening features are not enabled by default: PIE and bindnow. > Why? I guess because they have more impact on performance than the others. > > If your package supports PIE, you might want to consider enabling it. > > If the binaries are long running processes like daemons, and as such > > the startup performance penalty of “bindnow” is acceptable, it might > > be a good idea to enable it too but only if relro is in effect, > > although another option might be to just define LD_BIND_NOW=1 on the > > daemon's environment (for example in the init.d script), in which case > > the sysadmin can always disable it, something that's not possible with > > the build option. > I believe that developers would benefit from more detailed > recommendations. > In other words, just say clearly who should enable these features (and > why). It has already been discussed here, and there are already pages describing it and people commited to help in this goal being reach for the next release. http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags http://anonscm.debian.org/viewvc/secure-testing/hardening/ bert. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110923114531.GC4401@localhost
single-debian-patch (was Re: Bits from dpkg developers - dpkg 1.16.1)
On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote: > we just released dpkg 1.16.1 to unstable. It comes with several disruptive > changes that you need to be aware of. Please read carefully. > * “dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail > if it detects upstream changes which are not managed by a quilt patch. > > You are expected to call “dpkg-source --commit” if you want to > record those changes permanently. In this process, you will have > to give a patch name and you will be invited to edit the DEP-3 > headers[1] of the new patch. This does break old-style use of "3.0 (sane)" (aka, goodies from 3.0 without its only flaw, ie, quilt). Old-style: rm -rf .pc debian/patches New-style: echo "single-debian-patch" >debian/source/options It'd be nice if the error message pointed us to the new way. Quilt pretty thoroughly breaks version control. There are several tens of attempts to reconcile them, with not a single one preserving all functionality users of modern VCS take for granted: bisection, no massive recompilation on trivial changes, keeping the history without duplication, non-linear history, etc. Please keep the support for quilt-less workflows. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Re: Bits from dpkg developers - dpkg 1.16.1
On Sep 23, Raphael Hertzog wrote: > Two hardening features are not enabled by default: PIE and bindnow. Why? > If your package supports PIE, you might want to consider enabling it. > If the binaries are long running processes like daemons, and as such > the startup performance penalty of “bindnow” is acceptable, it might > be a good idea to enable it too but only if relro is in effect, > although another option might be to just define LD_BIND_NOW=1 on the > daemon's environment (for example in the init.d script), in which case > the sysadmin can always disable it, something that's not possible with > the build option. I believe that developers would benefit from more detailed recommendations. In other words, just say clearly who should enable these features (and why). -- ciao, Marco signature.asc Description: Digital signature
