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
51–60 of 139 posts
Re: Git security vulnerabilities announced
#52Original source: https://lore.kernel.org/git/xmqq7cxl9h0i.fsf@gitster.g/T/#u
Re: Git security vulnerabilities announced
#53For those of us who use Homebrew, the patched Git 2.39.1 should be available after this PR is merged: https://github.com/Homebrew/homebrew-core/pull/120818
Re: Git security vulnerabilities announced
#54Original source: https://lore.kernel.org/git/xmqq7cxl9h0i.fsf@gitster.g/T/#u
this should really be the article link instead of that proprietary writeup by a company taking advantage of OSS edit: just because someone puts up an "easy" ""free"" service, does not mean they are kind. GitHub is not your friend for git issues. I woul dhope this site would support true FOSS
If you don't believe me, have a look, this was probably submitted too, and is languishing somewhere off the front page while this one is at the top, by virtue of people voting for it and not the other.
Re: Git security vulnerabilities announced
#55Re: Git security vulnerabilities announced
#56Both 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.
>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)
Re: Git security vulnerabilities announced
#57Earlier quoted context omitted.
> Integer overflow isn't a security issue unless your program's memory safety depends on the correctness of the integer operation. That's simply not true and has wide-reaching horrible effects that can occur. The wrong number of tickets can be purchased from a website, charging for less than were purchased. The DNR order can be put in place instead of SAVE LIFE. There are countless security issues that can occur. Say…
That's most logic issues though, is it not? I agree with you though, i wish Rust more commonly pushed "safer" (not in the UB way) code, like `Vec::get` and `u32::overflow_add` and etc. Luckily lints help to easily ban the arithmetic/etc ops from projects. Nevertheless i feel it should be a bit closer to Rust's home.
Re: Git security vulnerabilities announced
#58Both 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 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…
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?
Re: Git security vulnerabilities announced
#59Original source: https://lore.kernel.org/git/xmqq7cxl9h0i.fsf@gitster.g/T/#u
huh, I would have thought for sure they would have linked to git/git from which that repo was forked
Also, the 2.39.1 tag alleges it was created Dec 13th - I wonder why they held it so long? I would have thought maybe embargo but the actual commit says "security fix" https://github.com/git/git/commit/01443f01b7c6a3c6ef03268b64...
Re: Git security vulnerabilities announced
#60Earlier quoted context omitted.
Slightly related, I wonder why the return type for `overflowing_add` isn't `Result ` and instead a tuple containing a boolean?
Probably because you'd want to access the value in either case, depending on your application.