Doesn’t homebrew typically get setup as a different user? How’s that going to work?
Homebrew typically changes the ownership of the directory to the current account.
Git security vulnerability announced
51–60 of 302 posts
Re: Git security vulnerability announced
#52Earlier quoted context omitted.
It's using it here on line 1042? git_config_pathname(&interpolated, key, value)
Yes but that's a general use function, it won't check for safe.directory inside of it
Right, all that does is turn paths like ~/foo into /home//foo. I’ve no idea why it even takes the key as an argument.
Re: Git security vulnerability announced
#53is_path_owned_by_current_uid(const char *path) isn't symlink safe given a multi-component path.
Symlinks, the poisonous gift that keeps on giving.
Re: Git security vulnerability announced
#54Re: Git security vulnerability announced
#55This is silly. Fix PS1, I can’t trust all repos I clone. I also want to cross-user access git log/blame etc.
Also, looks like you didn't read the linked page. The first thing there is a git config option to disable this check on select directories.
Obviously adding every single repo you will ever work with into the config is not workable.
Re: Git security vulnerability announced
#56> Merely navigating to such a space with a Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/` can lead to a compromised account. I'm curious about this -- what's the attack vector here?
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
Re: Git security vulnerability announced
#57Earlier quoted context omitted.
No, the .git directory is not cloned. But if the repo is already on disk it can be game over.
Though you could have a repository on Github that contains a subdirectory that is a malicious bare Git repo. So doing: ``` git clone github.com/foo/bar cd bar/subdir/ ``` is unsafe with a Git PS1. See https://offensi.com/2019/12/16/4-google-cloud-shell-bugs-exp...
Looks like git complains of invalid paths when you try that.
Re: Git security vulnerability announced
#58Shouldn't `safe_directory_cb` be checking the key parameter? It's ignoring it completely. So any unrelated config that has a directory in its value will also mark it as safe. Unless I'm misunderstanding something?
[deleted]
Re: Git security vulnerability announced
#59I shouldn’t ask too much of an open source project, etc. etc., but this sounds like something Git should fix themselves rather than just outright disabling. “I want to go into a directory and run git log” is kind of a simple thing to want to do and to not be able to do that sucks. It’s easy to pontificate on this forum but having a “safe” git that doesn’t automatically run hooks or whatever seems like the way forward here, and useful outside of even just a “I want my PS1 to work”.
Re: Git security vulnerability announced
#60Well, depending on exactly how much this blocks, this could get pretty awkward -- typing 'git log' in a repo owned by someone else can be awfully handy, even if file system permissions block changing it at all, and putting together a list of all places you might want to do this in advance could get pretty awkward. (Not running hooks, or allowing operations that would trigger them, from non-owned directories would pre…
I do this quite often, actually. I have my NixOS system config officially stored in /etc/nixos/ and owned by root. I have a clone that lives in my home directory for WIP changes, but builds always run out of the official copy. Sometimes it’s convenient to quickly run some read-only commands directly in the official copy
Ultimately you own that repository so just set it as safe in your config. Similarly if you are looking at a coworker’s repository then you can probably trust them. It’s only when you start sharing a computer with people that you don’t really know that you have a problem.