Live data from Hacker News

Git security vulnerability announced

github.blog

161–170 of 302 posts

Re: Git security vulnerability announced

#161
post #146

And .... there go probably tens of thousands of person-hours of human effort due to fixing this across huge numbers of systems. It's fascinating to me that we have people out there just casually making these kind of decisions with enormous cost implications with barely any thought to the downstream implications. Then meanwhile, we need approval in our org to claim a $30 taxi voucher as an expense.

It boggles the mind that someone thinks security decisions like these are made casually. Staying sane as an open source maintainer means ignoring such thanklessness as best you can.

Perhaps "casual" is the wrong word since it does have a pejorative implication. Put more neutrally, what I find fascinating is the asymmetry b/w the weight of process applied compared to impact. I am sure the individuals concerned thought very hard about it (I could not find the discussion on the mailing list, but from what I can see it may have been kept off the public list due to the security aspect).

Re: Git security vulnerability announced

#162
Don’t make tools use processes for “plug-in behavior”. Do one thing and do it well doesn’t really appeal to me to begin with but “let the first thing do the next thing on its own” is definitely a bastardization of that idea as well. Git has that Unix disease where the go to method of getting anything user configurable done with one program is launching another program. I’d much rather use tools that use huge convoluted script languages or good plug-in apis than tools that duct tape together with exit codes.

Re: Git security vulnerability announced

#163

Don’t make tools use processes for “plug-in behavior”. Do one thing and do it well doesn’t really appeal to me to begin with but “let the first thing do the next thing on its own” is definitely a bastardization of that idea as well. Git has that Unix disease where the go to method of getting anything user configurable done with one program is launching another program . I’d much rather use tools that use huge convolu…

[deleted]

Re: Git security vulnerability announced

#164

Don’t make tools use processes for “plug-in behavior”. Do one thing and do it well doesn’t really appeal to me to begin with but “let the first thing do the next thing on its own” is definitely a bastardization of that idea as well. Git has that Unix disease where the go to method of getting anything user configurable done with one program is launching another program . I’d much rather use tools that use huge convolu…

Modular design is bad for profit, amirite

Re: Git security vulnerability announced

#165
post #153

>This vulnerability affects users working on multi-user machines where a malicious actor could create a .git directory in a shared location above a victim’s current working directory If a malicious actor has access to the filesystem, isn't it a bigger problem? I remember Raymond Chen recounted in his blog that Microsoft usually dismisses vulnerability reports that start with "to use the exploit, you must have access…

[deleted]

Re: Git security vulnerability announced

#166
post #153

>This vulnerability affects users working on multi-user machines where a malicious actor could create a .git directory in a shared location above a victim’s current working directory If a malicious actor has access to the filesystem, isn't it a bigger problem? I remember Raymond Chen recounted in his blog that Microsoft usually dismisses vulnerability reports that start with "to use the exploit, you must have access…

> If you already have access to the machine and can create files outside of your home directory, what stops you from causing even greater havoc?

These systems don't let you put files in other people's directories. You can only create things in a specific spot, and if that thing is a directory then you and only you can put files inside it. Sometimes the only thing you can make in that spot is a directory.

(Other users can access those files if you explicitly add them to the permissions, of course.)

Re: Git security vulnerability announced

#167

Earlier quoted context omitted.

Thank you, I was confused. I'm very curious if the people complaining about this change as being too paternalistic still feel that way after reading the full disclosure link.

Even after reading the full disclosure link, I'm pretty surprised to learn that a security boundary was intended here. I thought it was common knowledge that git did an uncontrolled search up the filesystem for a .git file, and it would never have occurred to me to run git on a machine where people I don't trust have write access.

I was vaguely aware that git would search for .git directories. I had no idea that "git status" would run commands from such a directory.

Re: Git security vulnerability announced

#168
post #145

Earlier quoted context omitted.

Yes, but I feel like the other thing you need to keep in mind here is that this is going to be a massive pain for a lot of people, and they might end up doing things that are substantially worse for security, like refusing to update their git.

It’s possible, but I doubt it. 99% of people use a personal computer with just a single user account on it (or they use a phone with no git client, so let’s just think about git users for now). With only one real user account on the machine they are not very likely to encounter this security measure.

Just about anybody that uses docker and mounts a volume is going to have multiple users accessing their files, even if there's only one real user.

Re: Git security vulnerability announced

#169

Earlier quoted context omitted.

The default shell on Mac and a lot of Linux distros do this installation, as well as git for windows.

Can you say what Linux distro does this? Seems like very poor taste for a command shell to be assuming one particular SCM.

Command shells assume a lot of things, such as your preferred text editor, locale, input and output devices, etc. Most of these things can be configured, but the default install makes assumptions based on common configurations.

Re: Git security vulnerability announced

#170
Will Ubuntu update to v2.35.2? My current install is using the elder v2.25.1:

  ubuntu@vpn1:$ git --version
  git version 2.25.1

  ubuntu@vpn1:$ cat /etc/os-release
  NAME="Ubuntu"
  VERSION="20.04.4 LTS (Focal Fossa)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 20.04.4 LTS"
  VERSION_ID="20.04"
  HOME_URL="https://www.ubuntu.com/"
  SUPPORT_URL="https://help.ubuntu.com/"
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
  PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal
Post reply on HN