151–160 of 302 posts
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.
Earlier quoted context omitted.
What do you mean by “git often installs”. Git does not install anything. Developers configure their PS1 or install something that does.
The default shell on Mac and a lot of Linux distros do this installation, as well as git for windows.
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 to the machine". As he likes to say, "the gates are already open". 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?
This is silly. Fix PS1, I can’t trust all repos I clone. I also want to cross-user access git log/blame etc.
You don't have to trust repos you clone, if I understand correctly. You just need to trust ones you're given in other ways. The difference is, clone won't let you set up arbitrary config (or malformed internal data or etc.)
Earlier quoted context omitted.
Hmmm. git status seems like a simple read only command, but it can run a hook, which will change the result. So a default of no hooks might mean subtly or silently different, depending on who runs command, which can be really annoying kind of breakage to track down. "Why didn't the build start? Why wasn't the change noticed? I can see it." I can imagine wanting to avoid that scenario. Painted themselves into a bit of…
Right, I get the perspective, I’m just saying that there’s a lot of usecases where I know I don’t want this (PS1, git directory in /tmp, SSH into a shared machine) where I just want simple git commands to work, and a “git --safe” or something would be really helpful. I’m not even sure what the alternative would be here for a lot of these cases, besides writing my own “dumb” porcelain…
>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…
Earlier quoted context omitted.
The key is the "Git-enabled `PS1`". PS1 is an environment variable recognised by common shell programs (such as bash) that configures the shell prompt. Git often installs its own glue into the prompt that ends up running a Git executable to discover such things as the current branch name and how many changed files. The vulnerability is that it's possible to add malicious things to .git/config that the git executable…
in other news, access to a users account gives them access to a users account
>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…
Generally, you still want these additional protections even if you don't expect others to have access to a machine. Can't say if one or the other is a bigger problem. I think they are all components of having a secure system.
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.
Are you talking about stuff getting broken by this fix, or the patching effort required? This is relatively low risk so I would expect the mitigation to consist of "let your existing automation update it".
Earlier quoted context omitted.
The context of one is 'someone committed a thing a few weeks ago and it does a thing, according to someone posting to HN'. The context of the other is 'one of the biggest git users on the planet tells you there's git vuln, fix out right now'.
Git itself removing an ability should tell you that it's a big deal even more than "one of the biggest git users on the planet". And again, first line says it's a vulnerability. "it does a thing, according to someone posting to HN" is a big fat strawman.
On top of that, it breaks completely valid functionality - someones 'bug' is someone elses feature.