* Charles Plessy <ple...@debian.org> [120430 16:26]: > If people who are interested by improving our dozens of thousands upstream > makefiles could spend time forwarding patches upstream by themselves, that > would be appreciated. I have a hard time finding convincing words when I > think > the patch is borderline useless.
What are you talking about? Sorry, but I really cannot make any sense out of that. Let me try to explain the situation, so you can tell me where you disagree: We want some options enabled in as many package builds as possible. Options that have not been the decade long defaults in compilers, so they break a significant amount of software. Changing the compiler defaults would have the side effect of also affecting users and forcing all packages to cope with the changed defaults at once. (And the packages having the hardest to fix issues are usually the packages with the most absurd build systems, so having to fix all of them to include compiler options disabling the hardening flags is not that easy). So instead of an opt-out by changing what the compiler does by default and forcing the package maintainer to override them, we have a opt-in system: the maintainer can give the options to the build system. For that there is the new dpkg-buildflags command, that outputs all categories of flags a package maintainer would want to have: It give you preprocessor flags, it gives you C compiler flags, it gives you C++ compiler flags, it gives you fortran compiler flags and it gives you linker flags. By default it gives some default hardning flags but also supports the maintainer requesting more intrusive flags or disabling some classes of flags (see the discussion of DEB_BUILD_MAINT_OPTIONS in dpkg-buildflags manpage). It's also done in a way that support for 'noopt' it automatic, so it even makes it even less work for the maintainer. To ease it for package maintainers, the flags dpkg-buildflags generates have the names the GNU coding standards request all package build systems should support. As those are quite influental, many build systems name them this way. And as they are split into the flags the different tools want to have, every other scheme can be computed out of those easily by just appending those set of flags you need. If you have a build-system that does not support passing flags to the compiler, then you won't get support for hardning with this opt-in way, of course. But such a package would also have no way to override a specific set of hardening flags, so it would have problems with the opt-out way to, because it cannot opt-out. As not everyone build systems has the same names for variables holding the compiler (meaning preprocessor/actual compiler/linker) flags. There is not even theoretically (compare "halting problem") a way to determine what the variables are named like and what content they expect. This simply needs a human to look at it and say which flags need to be put where so that the upstream build system will pick them up. If a build system does not support passing flags to the compiler, and you want it to have hardening flags, that might need some makefile patches. But if there is no time for this or this is too complicated, then one can just do without, generating a package without hardening (and most likely also without support for noopt and the like, so do not suppose other people will be extremly willing to help you fix the bugs in it), but so be it. The release goal is "This goal is to update as many packages as possible to use security hardening build flags via dpkg-buildflags. These flags enable various protections against security issues such as stack smashing, predictable locations of values in memory, etc." It's not "Every package even if only hardly being of a quality to be included in a distribution must support hardening flags or it must be removed from Debian". 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/20120501095606.ga2...@client.brlink.eu