Pierre Pronchery <khorben%defora.org@localhost> writes: > On 07/28/15 19:44, David Holland wrote: >> On Sun, Jul 26, 2015 at 01:07:22AM +0200, Pierre Pronchery wrote: >> NetBSD's base system does not support "both" in the sense of a >> variable that's both user-settable and build-system-settable. >> That's why base has both MKFOO and USE_FOO settings. > > So MK... is for the build system, and USE_... is for the user? Not quite; the base system's MK/USE and what we're talking about here are different. MKFOO controls if the foo subsystem is built. USE_FOO controls whether random other programs use foo. An analogous situation is USE_FORT in mk.conf (to enable FORT/SSP for everything), and USE_FORT in the various Makefiles to set defaults (for setuid programs). However, this sort of coupling is tighter than we do in pkgsrc. An analogous situation would be having USE_SSP settable in mk.conf and an individual program have some SSP_BROKEN defines so that even if SSP is set globally, that program won't use SSP. This is rare in NetBSD's src; one example is: external/mit/xorg/bin/xauth/Makefile and it uses the same define. A similar example might be setting WARNS levels. But regardless of how it is in the NetBSD sources, pkgsrc norms are to use separate variables in mk.conf and to denote individual package needs. >>> And even then, packages could set "PKGSRC_USE_SSP?=yes" and then >>> the global setting would take precedence always if set >>> explicitly. >> >> Then you can't limit configuring it to yes to packages where it's >> been tested and found to work. > > Why not? That's what NetBSD's base system does. Programs and libraries > build without SSP by default, and those which were considered > sensitive (exposed to remote users or data) build with SSP by default. > How is that different? As I explained before, the pkgsrc mechanism is to have a variable in mk.conf that controls whether some global feature is wanted and a different variable in package makefiles that indicates if that global behavior should be overridden, usually by declining to implement a global feature. Or, we could have SSP_SAFE=yes, so that there is a way to set PKGSRC_USE_SSP to auto (so that it enables ssp on packages affirmatively marked). In the case of MAKE_JOBS, we decided to only mark failures, and then after a while it became reasonable for people to routinely enable MAKE_JOBS. This situation seems similar - I expect problems to be relatively rare. >>> b) My personal take on this is: - - it finds bugs (which is a >>> good thing) - - breaking is fail-safe (likewise) Are you asserting that enabling SSP will mean that if a package builds, it will definitely only malfunction on input which involves an overflow? >> ...it will likely break too many things to be anything other than >> an explicit setting for the near to middle future. > > Instead of > "likely break" "too many things" "near to middle future"... > ...can't we just go ahead and break them *now*? This flag *finds* > bugs, the most vicious kind, which will randomly corrupt memory and > possibly bite you at any seemingly unrelated point in the future. It seems like you don't accept that people actually use pkgsrc to build programs that they need to run to get work done. Just breaking things for *them* because *you* want more security is unreasonable, and is highly unlikely to be the consensus. > Why can't we just do it? If you would like to set PKGSRC_USE_SSP to yes on your system, and rebuild everything, and fix bugs that are found, go right ahead -- that would indeed be a service to the community, and I don't think anyone objects to you doing that. If you want to run a bulk build with SSP and publish it, so that others can try out the binaries, that would also be great. If you want to set PKGSRC_USE_SSP to yes by default in pkgsrc, so that random users and bulk build gets it, then we need evidence that it won't hurt functionality much. I really am not following your goals. There's nothing in the way of trying this and fixing all the fallout. We're only pointing out that imposing SSP on the entire user base, right now, is too much.
Attachment:
pgpkyrUsDgdlo.pgp
Description: PGP signature