Hi Petter, On Wed, 12 Aug 2020 12:45:32 +0200, Petter Reinholdtsen <p...@hungry.com> wrote: > [Stephen Kitt] > > Builds can supply the appropriate flags, but they need to do so > > consciously, it doesn’t make sense to enable them by default. > > Why not? I would expect it made sense to enable as many security > defences as possible in the default build, and if I remember correctly, > this was the rationale behind enabling the flags by default in the first > place. > > I got the impression from the upstream commits that the default now > enable these flags by default, but might have been mistanken, as I do > not really know much about mingw. :)
The upstream build doesn’t support enabling the flags by default — or rather, the test suite doesn’t support it. The upstream changes ensure that the necessary relocation section is preserved when secure flags are enabled, but this results in an empty section in many cases, which confuses other tools. The problem is really that, in the past, the flags were just flags, toggled in the binary; they were effectively an assertion that the binary had been built in such a way that the corresponding security feature could be enabled, with no checks that that was actually the case. Things are somewhat better now but I’m still not sure that all the flags are handled, I haven’t taken the time to check on Windows. > > The settings are ultimately controlled by binutils-mingw-w64. The > > security flags were set by default starting with version 7 (so > > 2.28-5+7.4 in oldstable is the first affected version that’s currently > > available), and disabled again in version 8.8, and fixed up in 8.9 (so > > 2.34-5+8.9 in testing is the first fixed version that’s currently > > available). > > OK, I've tried to adjust the starting point accordingly. We’ll have to re-assign the bug for that to work, I’ll take care of that (and of updating the CVE information). Regards, Stephen
pgpnvSl2jV6gv.pgp
Description: OpenPGP digital signature
