201–210 of 302 posts
Question for Mac users. Apple installs git with its command line tools and is currently at version 2.32. Is it wise to install git via Homebrew so that you can upgrade faster? Or are there some benefits from apple-git?
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_…
Same for debian 11 bullseye, which is today on git 2.30.2 . I'm not too worried, if someone besides me manages to create a /home/.git, then I'm already owned. But it's a bit surprising.
However, you can use bullseye-backports to get 2.34.1 if you want: See https://packages.debian.org/git
Edit: None of the debian versions have the patch yet: https://security-tracker.debian.org/tracker/CVE-2022-24765
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 explain? A shell isn't supposed to be installing things on it's own... (Assuming you're talking about zsh or bash when you say shell.)
Earlier quoted context omitted.
I can run git init in /tmp.
Then don't run commands in PS1 that blindly execute arbitrary code in that directory. Honestly, people haven't learned a single thing from Window's autorun days.
At least spend a couple seconds to think about what you're saying and how it relates to the issue at hand. You're being insufferable.
Was this change discussed publicly prior to merge? I think this is a big mistake. Build environments use separate users for security purposes. It's insane to decrease security for everyone by requiring a single user to do everything because some of your users want to have fancy terminal prompts. At the very least, let users configure this at a per-user level.
Fixing RCE vulnerabilities isn't something that should be debated about publicly.
Earlier quoted context omitted.
Why are you setting your ps1 to run arbitrary code in any directory? Don’t do that!
It’s one step more indirect than that. If I want my prompt to tell me what branch is checked out, I can have it include the output of running `git branch`, for example. Unbeknownst to me, running `git branch` can cause git to run programs specified in the git repository’s config file. It’s not normally a problem of course, because I am using my own computer with all of my own git repositories. But it can be a problem…
This is the real vulnerability. Why is git branch running random external programs?
> Run the uninstaller under an administrator account rather than as the SYSTEM user How do I run something as SYSTEM? I thought I always ran as "me" or Administrator. Is this only likely to happen for deployment automation tools? > Avoid running the uninstaller until after upgrading Don't leave us with this cliff-hanger... Does the upgrade installer run the uninstaller first? (The original report doesn't have this bu…
You can run it using something like psexec sysinternals tool or Process Hacker. But it’s not something someone would likely do by accident and it’s a bit orchestrated/non-obvious.
And of course the unspoken: almost nobody uses git on multi user systems, and when they do, most of the time every single user already has sudo.
This feels really pointless. If I can create /.git, I have root already. Any other parent-directory-escalation that I can think of would be so obscure as to be not worth caring about, and would also probably require having access to an already-higher-privilege account. And of course the unspoken: almost nobody uses git on multi user systems, and when they do, most of the time every single user already has sudo.
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…
> 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. The Unix "plug-in API" is pipes and exec and "everything is a file (descriptor)". A "good plug-in API" that doesn't support anything written outside the "huge convoluted script language" is not a plug-in API, it's an internal API of the "convoluted script language". "Do one th…
Absolutely correct. While it does have benefits in some situations, writing cross platform command line tools isn’t a place where it shines.