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/23/15 14:47, Greg Troxel wrote:
>> Pierre Pronchery <> writes:
>>> On 07/23/15 07:23, David Holland wrote:

>> Generally, we declare each variable to be user-settable in mk.conf
>> or pkg-settable in Makefile, and never both.  See the FETCH_USING
>> flamage...
> Good point; I do think here it really makes sense to support both
> though, just like in NetBSD's base system. And even then, packages
> could set "PKGSRC_USE_SSP?=yes" and then the global setting would take
> precedence always if set explicitly.

That's exactly what we don't do.  Basically, either a package sets
things that are necessary, or a user sets choices.

Now, if there's a reason why a package *has* to use SSP, or can't use
it, then that would need to be noted.  But it should be a different
variable.   An example might be something like MAKE_JOBS_SAFE, where a
user sets MAKE_JOBS and packages with MAKE_JOBS_SAFE=no skip using it.
So we might want SSP_SAFE=no to omit ssp on some packages, similar to
MAKE_JOBS_SAFE and packages that don't do DESTDIR.

I don't see why it's reasonable for a package to enable ssp if the user
has not asked for it globally.  I am confident that we can figure out
something reasonable for any reasonable use case, though.

>> I wonder if PKGSRC_USE_SSP should provoke an error if used with a
>> compiler that doesn't support it, rather than silently failing.
>> Or perhaps a warning; an error seems too much.  But overall I think
>> I agree with how you handled it.
> My personal opinion is that it should trigger an error, and certainly
> not silently ignore it. It may not be the most practical answer for
> our users - but certainly the most secure.

I suspect it is mostly academic whether PKGSRC_USE_SSP=yes results in an
error or a warning on os/cpu/compiler combinations that don't have
support.  I lean to a warning, because the notion that someone will turn
it on without understanding that they might not get it seems a stretch.

> 1. introducing the feature (disabled by default)

You've committed this, so this is project.

> 2a. adventurous people/projects (EdgeBSD...) enable it by default and
>     report/fix failures

Sure, that's fine, or someone could turn it on individually, or do a
bulk build with it.

In your experience so far, do problems show up at build time, or do
programs just not work, or ?

> 2b. support gets added for more platforms
> 3. enabling by default on NetBSD/gcc (possibly also clang), possibly
>    partially (like for base)

To get to this, we probably need a SSP_SAFE=no define for individual
packages.  And confidence that we aren't causing undetected/unknown

> 4. fail if enabled but not supported for the current platform

That really doesn't seem useful.  Let's defer this until after it's the
default for NetBSD/gcc.

Attachment: pgpBo799E8z82.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index