[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Improving security for pkgsrc
-----BEGIN PGP SIGNED MESSAGE-----
On 07/29/15 01:27, Greg Troxel wrote:
>>>> 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 breakage.
>> But then if it does break, and a bug is confirmed, is it not
>> better to break rather than expose a weird machine to potential
> It's not reasonable to decide that for other people, because none
> of us know the shape of their utility functions. Some people
> would rather turn off SSP and have their software still work, and
> some people would rather stop using the software because it's
> dangerous. The pkgsrc way is to let users make that call. This is
> not so different from setting ALLOW_VULNERABLE_PACKAGES. I suspect
> a non-trivial number of people do that.
Exactly: the default behavior for ALLOW_VULNERABLE_PACKAGES prevents
vulnerable packages from being installed, except if the user did
explicitly set it. How is SSP different?
I do not see any reason to not fail-safe here.
>>>> 4. fail if enabled but not supported for the current
>>> That really doesn't seem useful. Let's defer this until after
>>> it's the default for NetBSD/gcc.
>> To me it is the complete opposite. A user should not be let into
>> a dangerous direction without a big, fat warning and a barrier
>> to jump before falling off the bridge. We are operating a bridge
> By that logic we should disable pkgsrc completely until all known
> mitigations are implemented. In all seriousness, it's ok to make
> things better, but I don't think it's ok to start breaking things
> that used to work.
Compiler bugs aside, we would not be breaking things that used to
work, but breaking things that /seemed/ to work.
Anyway, as mentioned before, I totally agree to proceeding in steps and
we should. So let's first detect and solve obvious breakage if any,
and I really hope we will be in a situation where we can change the
default without known breakage earlier than not.
What about enabling it when PKG_DEVELOPER is enabled?
(possibly in another step)
> But, I'm not averse to adding SSP_SAFE=no to programs that are
> known to have issues, and heading to enabling PKGSRC_USE_SSP by
> default when we believe that the number of packages which should
> have SSP_SAFE=no set but don't is low.
On my local system devel/cmake refuses to build, which may however not
be related (I have a number of other changes). If confirmed, this
might be a first candidate for SSP_SAFE=no.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
Main Index |
Thread Index |