your three dots are deserved, at the end there. it even occured to me while writing, that openbsd very likely already implements all that stuff itself.
if you want to omit --enable-hardening and --enable-stl-hardening, that's fine. i just added them because i thought, yeah why not.
really then the only flags that i can think of that openbsd might find worthwhile on the ports are:
--enable-rust-simd (the tests/crashreporter disablement are optional really)-ftrivial-auto-var-init=zero <-- this one, in the patch, might still be desirable. not sure if openbsd does that in its compilers.
therefore, should i re-factor the patch to only have these additions?i mean it's up to you. feel free to chop up my patch however you want, if you're even interested in it all. i have these in my librewolf port, but your responses tell me i could probably remove some of it there with no ill effect.
Am 04.09.26 um 15:37 schrieb Bryan Steele:
On Fri, Sep 04, 2026 at 02:21:57PM +0100, Leah Rowe wrote:Hi Byran, Am 04.09.26 um 12:40 schrieb Bryan Steele:-fwrapv at least is already the default on OpenBSD, for all compilers. https://man.openbsd.org/clang-localIf that is true, then that flag can be ommitted when merging the patch. that's fine.--enable-hardeningI actually didn't know the answer to this question, so I looked it up. It's a high-level wrapper in mozilla build systems that enables a bunch of C/C++ mitigations by appending specific flags to the compiler (CFLAGS / CXXFLAGS) and linker (LDFLAGS). Depending on the compiler and OS, it might inject things like: -D_FORTIFY_SOURCE=2, which will replace vulnerable libc calls like strcpy, memcpy, memset, sprintf etc with more secure, length-checked variants. So, boundary checks and such. It will also introduce behaviour e.g. when a write exceeds a target buffer's size, the process may abort rather than permitting a stack/heap overflow. I know OpenBSD does some of this at kernel level too, but this is implemented at the application layer._FORTIFY_SOURCE does absolutely nothing on OpenBSD, it's a feature of glibc and other linux libc implementations.It will harden flags pertaining to stack and memory layout e.g. add -fstack-protector-strong (or -all on some targets). More overflow protection.OpenBSD defaults to -fret-protector on most clang architectures, and falls back to -fstack-protector-strong when disabled, which for example the mozilla port does on arm64. https://github.com/openbsd/src/blob/master/gnu/llvm/clang/lib/Driver/ToolChains/Clang.cpp#L6925 https://github.com/openbsd/src/blob/master/gnu/llvm/clang/lib/Driver/ToolChains/OpenBSD.h#L95It will add flags like -Wl, -z (relro/now), forcing the linker to mark internal data sections read-only after relocation, also eliminates lazy binding and marks the global offset table read-only to prevent overwrite exploits. Also does things e.g. mark stack segments non-executable - again, OpenBSD already does things like this at kernel level e.g. w^x, though I'm aware that there are some complications with this already with mozilla due to the fact that it heavily uses dynamic recompilation for things like javascript.We have PIE w/ RELRO enabled by default, and has secure lazy-binding with kbind(2), relro doesn't require -znow or any extra flags on OpenBSD. OpenBSD doesn't have executable user stacks, period. GOT/PLT is already read-only.According to my research, it also has a negligible speed impact. Yeah, tl;dr runtime bounds checks enforced by the compiler. Of course, the source code itself should do checks on itself, but no two programmers are made equal are they?+ Look it up yourself. I recommend turning these on by default. Though, given that the context here is OpenBSD, openbsd itself probably turns a bunch of this stuff on by default anyway. In my mind, it certainly can't hurt to turn on these flags anyway....Basically these flags will make the program abort if it misbehaves, due to memory bugs. -- Company director, Minifree Ltd Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK
-- Company director, Minifree Ltd Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK
OpenPGP_0x5C654067D383B1FF.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
