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!
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 @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.