The depends packages are built without _FORTIFY_SOURCE and -fstack-clash-protection unless the compiler turns them on by default. CMakeLists.txt adds both to core_interface only. The release flags in depends/hosts/linux.mk and mingw32.mk are only -O2. Debian's GCC turns on neither, so sqlite, libzmq and capnp are built without them. #27118 built libevent with -D_FORTIFY_SOURCE=3, but libevent is no longer in depends.
I add -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-clash-protection to linux_release_CFLAGS, and the two _FORTIFY_SOURCE flags to mingw32_release_CFLAGS. Through toolchain.cmake the flags also reach the main build. There secp256k1, which does not link core_interface, gets them too. #36534 does that for every build. Qt 6.8 already adds both flags to its own targets on Linux. I leave macOS alone, because its SDK already fortifies. Apple clang 21 ignores -fstack-clash-protection on arm64. I did not add -fcf-protection (see #30685).
In a debian:trixie container (GCC 14.2, aarch64) I built depends with NO_QT=1 and then Core, on master and on this branch. On master no library in depends calls a _chk function. On this branch libsqlite3.a, libzmq.a, libkj.a, libkj-async.a and libcapnpc.a do. secp256k1 is compiled with the new flags. All 380 ctest tests pass, and so do interface_zmq.py, wallet_basic.py and wallet_backup.py. With HOST=x86_64-w64-mingw32ucrt (mingw-w64 12), libsqlite3.a calls __memcpy_chk and bitcoind.exe links. I have not run a Guix build or built Qt.
This is one of several PRs from a large audit of Bitcoin Core that I did with the help of LLM tools. The audit produced its evidence all at once, which is why the PRs arrive together. I understand each change fully and will answer review questions myself.
