daniel:// stenberg://A quick reminder. This is what we do to keep curl secure. We try.
Shawn Webb@bagder is curl looking to adopt compiler-based exploit mitigations like CFI and SafeStack?
@lattera we ship source code, it's immune to compiler problems! 😁
@bagder doesn't curl ship a
./configure script, which generates a Makefile with certain compiler and linker flags?@lattera sure, so everyone who builds it can add all the pickiest and special compiler flags they want. There are countless compilers that can build curl and countless platforms that curl runs on.
@bagder is curl interested in maintaining a hardened set of default compiler flags?
@lattera maybe. doesn't seem like the appropriate place to collect that kind of information though!
@bagder I would think that curl would already set certain CFLAGS/LDFLAGS/etc. For example, libcurl.so would need to be built with
-fPIC (as you're very much already aware).@lattera yes, on some systems in some circumstances it uses -fPIC.
@bagder so then curl could, if it decided to, include a set of hardened default compiler flags.
setting certain compiler flags in the curl project would benefit all downstreams, not just the downstreams who themselves have hardened curl.
I suspect the curl developers know the curl codebase and which compiler flags would work better than some other random person with no experience in curl's source code.
@lattera in my experience, the ones who knows compiler options best are the compiler people and the ones building distros or otherwise build a lot for a specific platform.
We primarily focus on shipping source code that builds on 100 operating systems. We are not experts in the optimal options for fixed compiler on a particular specific plattforms.
Seth Larson@bagder @lattera If you're interested, CPython has adopted a subset of this guide: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html
We've done so incrementally by creating a "ignore" file for files with the warning(s) to get the options happening in CI and then these can be incrementally "resolved" as separate issues. This is useful for larger codebases, so you don't have to resolve it all at once.
@sethmlarson @bagder this is the way.
@sethmlarson @lattera we have "all" the picky warning options enabled, i was referring to more "hardening" options of the output
That OpenSSF guide is a good collection of options in an appropriate place!
@bagder @sethmlarson I'm not claiming curl should be the one to document compiler flags. rather, I'm claiming that curl could, if it chose to, adopt compiler-based exploit mitigations.
inside the curl codebase would be the right place to do it, since different compiler flags would need to be applied to libcurl.so rather than curl(1). for example, llvm's safestack cannot be applied to libcurl.so. additionally, if curl(1) was to call setjmp/longjmp, safestack could be disabled just for those call sites in curl(1).
@lattera @sethmlarson if someone would provide something like that, we'd discuss and consider it of course.