Git security fixes released

Posted Apr 13, 2022 17:06 UTC (Wed) by mathstuf (subscriber, #69389)
In reply to: Git security fixes released by Karellen
Parent article: Git security fixes released

> was so that apps would have to support spaces in paths if they wanted to be capable of moving away from legacy FAT "mydocu~1" altnames.

Which was naive. Instructions just said to go to `C:\foo` instead. This may have worked for a while, but then `Documents and Settings` made it easy to run into path length limits (MSVC still has problems with some long filenames) which made projects run back to `C:\foo` and lose their spaces-in-paths test cases.

> but actual development tools like build systems - in the 2020s that don't support spaces in paths is mind-boggling.

IME, the issues actually usually come from autoconf-based (or raw Makefile) packages where quoting those `$(topdir)` and such expansions is pretty lax. In CMake, you're usually OK, but sometimes someone does something that tries to pass paths around without any thought about "might be seen as two words later".

Git security fixes released

Posted Apr 14, 2022 2:39 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

Well, there's also C:\Program Files, so at least your actual binary has to support spaces in its path, but the Python people managed to even avoid doing that by installing into C:\Python3x (where x is the minor version).

Git security fixes released

Posted Apr 14, 2022 15:18 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

> (MSVC still has problems with some long filenames)

_This_ is the mind-boggling part.

> which made projects run back to `C:\foo` and lose their spaces-in-paths test cases.

I wonder how many security holes lie there...

Git security fixes released

Posted Apr 14, 2022 17:34 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Probably as many that lurk in and around functions passed to signal(7) APIs.