Pierre Pronchery <khorben%defora.org@localhost> 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 that. >>> 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. > http://allday.com/post/4658-11-of-the-dumbest-and-most-unusual-ways-peop > 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 work. 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