61–70 of 139 posts
Overall fixing this it looks like routine house keeping and nothing major.
Earlier quoted context omitted.
> Rust had a chance to fix this, but also dropped the ball. By default , a Rust project will panic on integer overflow in debug builds and will overflow on release builds. Two key points to note, however: 1. You can change the setting so that your project panics in release or overflows in debug mode. 2. We reserved the right to change the default at some point in the future. This will probably be widely communicated…
> I heard we are still waiting for the cost of performing those checks to be "reasonable" before thinking about making such a change. What I don't understand is, checking for integer overflow is extremely cheap in hardware, so why is there any cost for performing those checks? What am I missing?
Earlier quoted context omitted.
Probably because you'd want to access the value in either case, depending on your application.
Could be a `Result ` which would seem to express the intent better.
Earlier quoted context omitted.
My contribution to two open-source projects in recent years has involved a transition to the use of safe arithmetic, too. I think it makes a lot of sense to think about. Ultimately, it matters more in some applications than in others.
Can you explain this as if I were a programmer who doesn't know what that looks like?
bool SafeAddIntInt(int32_t x, int32_t y, int32_t *r);
int32_t result;
if (SafeAddIntInt(x, y, &result)) {
// do something with result
} else {
// handle overflow
}
[Edit: According to @rlpb's comment, git 2.39.1 is already available on Ubuntu] To install the latest git on Ubuntu: sudo apt upgrade git [Former post included instructions on how to install git from https://launchpad.net/~git-core/+archive/ubuntu/ppa ]
The updater just gave me 1:2.37.2-1ubuntu1.2 (to replace 1:2.37.2-1ubuntu1.1). It said it addresses the two CVEs in question.
So they (Ubuntu or maybe Debian) are taking the approach of patching a slightly older git version.
Regarding first vulnerability with gIt format, how can malicious party exploit it? Someone needs to convince you to run git log format with some unusual format specifier, right? And then they need to access some specific memory location this way so they still need to store something malicious elsewhere. Sounds like it would be really extremely hard for anyone to exploit this. Overall fixing this it looks like routine…
Both 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.
Don't see how. Given the hardware Rust is designed to program you have to compromise some or all of efficiency, memory usage and complexity to solve overflow.
Earlier quoted context omitted.
> Rust had a chance to fix this, but also dropped the ball. By default , a Rust project will panic on integer overflow in debug builds and will overflow on release builds. Two key points to note, however: 1. You can change the setting so that your project panics in release or overflows in debug mode. 2. We reserved the right to change the default at some point in the future. This will probably be widely communicated…
> I heard we are still waiting for the cost of performing those checks to be "reasonable" before thinking about making such a change. What I don't understand is, checking for integer overflow is extremely cheap in hardware, so why is there any cost for performing those checks? What am I missing?
Earlier quoted context omitted.
Could be a `Result ` which would seem to express the intent better.
Sometimes, sure. But an overflow doesn't have to be an error, it can be what you're after and you just want to know when it happens.
Earlier 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)
Saturated arithmetic instructions do not do this.