←back to thread

359 points dgl | 1 comments | | HN request time: 0.205s | source
Show context
dwrodri[dead post] ◴[] No.44502622[source]
[flagged]
jerf ◴[] No.44502680[source]
As the article says: "I find this particularly interesting because this isn't fundamentally a problem of the software being written in C. These are logic errors that are possible in nearly all languages, the common factor being this is a vulnerability in the interprocess communication of the components (either between git and external processes, or within the components of git itself). It is possible to draw a parallel with CRLF injection as seen in HTTP (or even SMTP smuggling)."

You can write this in any language. None of them will stop you. I'm on the cutting edge of "stop using C", but this isn't C's fault.

replies(1): >>44502905 #
gpm ◴[] No.44502905[source]
You can, but in languages like python/java/go/rust/... you wouldn't, because you wouldn't write serialization/de-serialization code by hand but call out to a battle hardened library.

This vulnerability is the fault of the C ecosystem where there is no reasonable project level package manager so everyone writes everything from scratch. It's exacerbated by the combination of a lack of generics (rust/java's solution), introspection (java/python's solution), and poor preprocessor in C (go's solution) so it wouldn't even be easy to make a ergonomic general purpose parser.

replies(2): >>44503022 #>>44504184 #
bangaladore ◴[] No.44503022[source]
I have a feeling that this code was developed before any of those languages were widely popular and before their package managers or packages were mature.

This file was written like 20 years ago.

replies(1): >>44503063 #
1. gpm ◴[] No.44503063[source]
Sure, I'm not trying to assign blame to Linus for deciding to write git in C, I'm saying that modern tooling (not C) would prevent the bug with reasonably high probability and that that's a factor when deciding what to do going forwards.