Georg Sauthoff writes:
> I ended up tweaking my code to avoid the assertions, rather than disabling > them. For this particular situation, my original change was to try > > std::copy(&foo[0], &foo[0]+foo.size(), std::back_insert_iterator{bar}); >> But that still tripped the assertion when the foo vector was empty, so I had> wrap this inside an if(). But why don't you use the idiomatic copy(foo.begin(), foo.end(), back_inserter(bar)); ? No need to wrap it into an extra if statement.
I'm well aware of the alternatives. That's not the point.The point is that there's nothing wrong with this specific form of existing code that now throws exceptions when the hardened build gets turned on. There is no buffer overruns, and nothing to exploit.
IIRC, the hardened build did find one real bug in the upstream package that was the original subject matter here, but all of the rest were these kinds of false positives. Now you have a situation when the existing code is known to be working, but needs changing in order to use a hardened build. There's some level of risk of regression in any change, and that gets weighed against the benefits of having a hardened build.
The above was just a basic example of this. It is not true that exceptions from hardened code are always evidence of potentially exploitable problem. Sometimes/most of the time, but sometimes they are false positives.
Attachment:
pgpkm9IHLZTpH.pgp
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
