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:

>> In your experience so far, do problems show up at build time, or
>> do programs just not work, or ?
> Some projects might no longer build, but I do not expect much breakage
> there: major distributions have been building the same software with
> SSP enabled for many years now.
> Issues at run-time may occur, but they depend on the code path and
> context. Finding run-time issues is a good thing though: it should
> indicate a bug in the program. If confirmed so, then the program had
> an issue, not the compiler.

So there will be both build-time issues and run-time issues.  build-time
will be obvious, and run-time will not be.

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

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

>>> 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.
> 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 here.
> le-have-died/pages/2/

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

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.

Attachment: pgpANgzYoHJ9i.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index