Live data from Hacker News

Git security vulnerabilities announced

github.blog

51–60 of 139 posts

Re: Git security vulnerabilities announced

#54
post #35

Original 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

No it shouldn't, an hour in this submission might have barely 7 points, not 177, and probably a comment or two bemoaning the readability and pointing out the clearer write-up(s) available for people not already keeping up with the mailing list.

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

#56
post #4
post #3

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.

>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.

Re: Git security vulnerabilities announced

#57
post #41

Earlier 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.

[deleted]

Re: Git security vulnerabilities announced

#58
post #3

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.

> 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?

Re: Git security vulnerabilities announced

#59
post #35

Original source: https://lore.kernel.org/git/xmqq7cxl9h0i.fsf@gitster.g/T/#u

> url = https://github.com/gitster/git

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

#60

Earlier 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.

Could be a `Result` which would seem to express the intent better.
Post reply on HN