tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Improving security for pkgsrc

Pierre Pronchery <> 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:
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?

>> 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

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

Home | Main Index | Thread Index | Old Index