Looks like Git has its own string type: https://github.com/git/git/blob/master/strbuf.h https://github.com/git/git/blob/master/strbuf.c See this for the story of why strncpy/strncat are insecure: https://en.wikipedia.org/wiki/C_string_handling#Replacements
Nice. Is there a similar standalone C library for safe/sane string handling? (Please don't tell me to use C++.)
Banned C standard library functions in Git source code
251–260 of 329 posts
Re: Banned C standard library functions in Git source code
#252Earlier quoted context omitted.
Tangential but the fact that I had to open up the machine and remove a screw to completely replace ChromeOS with linux bothers the fuck out of me.
My Chromebook just made me enable developer mode.
Developer mode lets you boot another OS, but leaves you open to accidentally wiping your drive if you hit the wrong button on boot. Replacing the firmware is a good idea, you do need to remove the write protect screw, but that really makes sense for some note of physical security.
Re: Banned C standard library functions in Git source code
#253Delighted to see strncat there, it's a buffer overflow waiting to happen, especially as the name sounds like it's the 'safer version' where it takes a size argument, except it's not the size of the destination buffer, it's the remaining size, so unless you know this, it's wrong for every non empty buffer. strlcat (not standard) operates how you expect.
Whenever I review code and see strncat there, it's almost guaranteed to be a bug. This is for the simple reason that nobody remembers exactly what strncat does, and so misuse it.
Re: Banned C standard library functions in Git source code
#254Earlier quoted context omitted.
The (more-or-less) sensible replacement is std::string. Adoption has been spotty, for practical, ideological, and fetishistic reasons. The first step is to compile the C program with a C++ compiler. Next, start making improvements. If you skip the first step, the ceiling on improvements is limited.
C++≠C, and making the jump isn't always feasible.
As I said.
And when it's not, the ceiling on improvements is limited.
Re: Banned C standard library functions in Git source code
#255Earlier quoted context omitted.
That make me wonder how hard it would be to just strip the bad functions out of the library.
Well your std c library is generally just a collection of .o, .a, .lib files. So you could use gnu bin tools to remove symbols of your choosing. However good luck getting your system to build software because that would modify the stdlib for all things compiled on your system. You could also tell gcc or clang not to link to the std library and providr your own with just a few switches on invocation of the compiler
Other thought would be to put the dlls with unsafe functions in different location than the safer ones and throw up a warning when an application loads them.
Re: Banned C standard library functions in Git source code
#256Earlier quoted context omitted.
I wonder about this every time I read C. There is talk about npm/rust having massive dependency trees (and they do) because it makes taking on dependencies too easy. But I feel like C is on the opposite side of the spectrum, where managing dependencies is difficult so every C code base is rolling it’s own version of everything. C also has an expansive standard library but it hasn’t offset re-invention of that stdlib…
It's bad that C devs have rolled their own awful, buggy custom solutions. However, here's the upshot-- that awful, buggy, custom solution is guaranteed to remain compatible with the codebase that contains it. You won't find a single instance where such a dev "improved", "refactored", "optimized", or "modernized" that awful, buggy code in a way that stopped the rest of the code from working and then shipped that broke…
Regarding remaining compatible, I would argue that this is why modern languages implement lock files and version pinning. If you don't like a particular change but need some extra functionality or a security fix you can fork the relevant libraries or extend the functionality with an extra self written library.
Re: Banned C standard library functions in Git source code
#257Windows programmers are familiar with StrSafe.h, https://en.wikipedia.org/wiki/Strsafe.h and https://github.com/dotnet/coreclr/blob/master/src/pal/inc/st... which go a lot further. Also found https://github.com/mubix/netview/blob/master/banned.h on Github with a better list.
You can find an up-to-date, authoritative version of banned.h here: https://github.com/x509cert/banned
Re: Banned C standard library functions in Git source code
#258Earlier quoted context omitted.
It's bad that C devs have rolled their own awful, buggy custom solutions. However, here's the upshot-- that awful, buggy, custom solution is guaranteed to remain compatible with the codebase that contains it. You won't find a single instance where such a dev "improved", "refactored", "optimized", or "modernized" that awful, buggy code in a way that stopped the rest of the code from working and then shipped that broke…
Regarding remaining compatible, I would argue that this is why modern languages implement lock files and version pinning. If you don't like a particular change but need some extra functionality or a security fix you can fork the relevant libraries or extend the functionality with an extra self written library.
It's not a guarantee that it will work, it's not that rare to encounter a minor/patch version in a library that introduced some subtle incompatible change (usually unbeknownst to the author)
Re: Banned C standard library functions in Git source code
#259Earlier quoted context omitted.
Like essentially all C programs.
What's a good library for this kind of boilerplate? A lightweight one if possible, i.e. not fucking glib
This is a good place to start:
https://dwheeler.com/secure-programs/3.71/Secure-Programs-HO...
Re: Banned C standard library functions in Git source code
#260I see a lot of comments to the effect of "shouldn't XYZ also be banned". The answer is that we're not necessarily trying to be exhaustive. The point is to flag common errors before we even hit review, so we add new functions mostly when somebody tries to misuse them. I don't recall anybody trying to abuse longjmp() in Git's codebase yet (and no, that's not a challenge).
Peff, for the people asking in the thread, is there a place where correct alternatives are suggested or demonstrated?
I know there are a few different places that talk about how to use git's internal machinery, but not sure if any are specific to these banned functions.