Git security fixes released

Posted Apr 13, 2022 12:48 UTC (Wed) by draco (subscriber, #1792)
In reply to: Git security fixes released by nye
Parent article: Git security fixes released

In my experience, non-admin users can usually create directories directly in the root of the C: drive -- even in work environments.

Git security fixes released

Posted Apr 13, 2022 12:59 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (5 responses)

And it's often necessary to get paths short enough for some build systems or projects. Or those that don't support spaces in paths (yay "Documents and Settings").

Git security fixes released

Posted Apr 13, 2022 14:26 UTC (Wed) by Karellen (subscriber, #67644) [Link] (4 responses)

IIRC one of the reasons that Windows started creating paths with spaces by default back in the '90s (e.g. "My Documents", and later "Documents and Settings") 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.

The idea that there are Windows applications - and not just in-house LOB apps, but actual development tools like build systems - in the 2020s that don't support spaces in paths is mind-boggling.

Git security fixes released

Posted Apr 13, 2022 17:06 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (3 responses)

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

Git security fixes released

Posted Apr 13, 2022 15:40 UTC (Wed) by nye (subscriber, #51576) [Link]

Thanks, this appears to be the missing link - to my great surprise, it turns out that by default "Authenticated Users" has the "Create folders / append data" bit set explicitly for C: by default.

That's pretty horrifying but I suppose there are compatibility concerns that would make it hard to fix now.