I don't know if "announced" is really the word they want to use here. It makes it sound like they're unveiling a new feature.
Git security vulnerabilities announced
31–40 of 139 posts
Re: Git security vulnerabilities announced
#32Earlier quoted context omitted.
>It's unclear to me why our languages still default to modulo arithmetic semantics. Because that's what processors do? (leaving aside backwards compatibility issues)
Our processors also require manually manipulating registers. The whole point of higher level programming languages is to abstract away the fiddly bits of dealing with processors that we don't want to have to deal with. This is one of those cases.
In this case it's really that the cost of determining if an overflow did occur or will occur on modern architectures is too high and the likelihood too low for it to be reasonable to perform the checks in most cases in native code. Might be different for interpreted languages depending on a lot of things (whether or not they even use integer arithmetic, whether or not they default to some arbitrary precision integers by default, etc.). If common architectures automatically interrupted on overflow rather than setting a flag at no additional cost, I'd think you'd see safety guarantees instantly.
Re: Git security vulnerabilities announced
#33Re: Git security vulnerabilities announced
#34Both critical bugs are integer overflows. It's unclear to me why our languages still default to modulo arithmetic semantics. I feel Rust had a chance to fix this, but also dropped the ball.
Rust makes integer overflow panic in debug builds, so Rust code is effectively required to opt into overflowing operations for correctness reasons. It disables those checks on release builds for performance reasons, but as sibling comments point out, it reserves the right to change that behavior. Unfortunately, there is a circular dependency here. Languages are reluctant to make integer overflows error conditions bec…
That sounds like the similar, but opposite case of tail recursion optimization. Some languages/compilers don't do it because devs want stack traces. But allow TCO in and now the code that gets written is quite different than the code that would not do tail calls because TCO doesn't exist.
Also a surprising amount of undefined behavior gets relied on in code. I don't use Rust, but the idea that they could potentially change the future behavior on overflow seems... risky?
Re: Git security vulnerabilities announced
#35Original source: https://lore.kernel.org/git/xmqq7cxl9h0i.fsf@gitster.g/T/#u
Re: Git security vulnerabilities announced
#36Earlier quoted context omitted.
>It's unclear to me why our languages still default to modulo arithmetic semantics. Because that's what processors do? (leaving aside backwards compatibility issues)
Our processors also require manually manipulating registers. The whole point of higher level programming languages is to abstract away the fiddly bits of dealing with processors that we don't want to have to deal with. This is one of those cases.
In cases where you're willing to take the perf hit, you can just use languages like Python which abstract over integer size entirely.
Re: Git security vulnerabilities announced
#37I don't know if "announced" is really the word they want to use here. It makes it sound like they're unveiling a new feature.
Normally these posts would by called advisories (or more specifically security advisories)
Some vendors use the term Security Bulletins
Re: Git security vulnerabilities announced
#38Earlier quoted context omitted.
Integer overflow isn't a security issue unless your program's memory safety depends on the correctness of the integer operation. Safe rust doesn't (in any build mode), but C/C++ does.
You don't know the business logic of every program. You can't say that a rust program won't have a security issue due to this. `UserAccessLevel > Threshold` Like there could be a million ways an integer becoming small could mess up something. Also there are business logic issues as well
Sure, but a logic error is a fundamentally different class of error compared to a memory error. The potential harm of a logic error is limited in scope to what the program was written to be able to do. A memory error can lead to arbitrary code execution.
Re: Git security vulnerabilities announced
#39Both critical bugs are integer overflows. It's unclear to me why our languages still default to modulo arithmetic semantics. I feel Rust had a chance to fix this, but also dropped the ball.
Integer overflow isn't a security issue unless your program's memory safety depends on the correctness of the integer operation. Safe rust doesn't (in any build mode), but C/C++ does.
[deleted]
Re: Git security vulnerabilities announced
#40Earlier quoted context omitted.
Slightly related, I wonder why the return type for `overflowing_add` isn't `Result ` and instead a tuple containing a boolean?
There are times when you want to know how much overflow occurred -- think of the way you learn to do multi-digit addition. There is a checked_add that returns an Option if you only care about success/failure.
An example is efficient prime-field arithmetic:
https://cp4space.hatsya.com/2021/09/01/an-efficient-prime-fo...
> If A happened to be larger than C, and therefore the result of the subtraction underflowed, then we can correct for this by adding p to the result. [...] we can multiply B by 2^32 using a binary shift and a subtraction, and then add it to the result. We might encounter an overflow, but we can correct for that by subtracting p.
(Highlighting the parts that relate to reacting to overflow.)