[Rpm-maint] [rpm-software-management/rpm] Avoid negating an attacker-controlled signed integer (#1502)

[Demi Marie Obenour]

> It's undefined behavior, but what exactly you think will happen if that occurs? The result will still be an int32_t which is either in range or not, which can happen without invoking any undefined behavior and which we need to catch.
> 
> So what exactly is this supposed to achieve?

Undefined behavior means that arbitrarily bad things can happen.  [This blob post](https://blob.llvm.org/2011/05/what-every-c-programmer-should-know.html) is a good introduction.

One alternative is to have `configure` check that the compiler supports `-fwrapv`, which makes integer overflow well-defined, and error out if the compiler does not support it.  This is a completely legitimate choice to make ― the OCaml runtime does it ― but it does mean that RPM will no longer be a standards-conforming C program.  Both GCC and Clang support `-fwrapv`, so it should not limit our portability too much.  That said, while I support passing `-fwrapv` where available, I still believe that integer overflow should be avoided where possible, mostly because it makes it harder for fuzzers to find unintended integer overflows.  In C and C++, unintended integer overflows are a common cause of memory corruption.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1502#issuecomment-762079672
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20210118/e44bf062/attachment.html>