Earlier quoted context omitted.
I kindof agree with you, but if you go to a university lab then you will likely find that all the students are all in the same groups. You don’t really want to blindly trust the group that way.
Oh yeah, in such an environment that would not make sense. I'm saying it should be a (local/global) config option, not enabled by default. EDIT: Or maybe even more general, trustedOwnerUsers / trustedOwnerGroups
Git security vulnerability announced
91–100 of 302 posts
Re: Git security vulnerability announced
#92This is bullshit. I mean, ok, you are concerned about somebody using git-enabled PS1. Guess what, not everyone is using git-enabled PS1. Unbelievable, right? I would even mock the fact that you are trying to protect users from the behavior they pretty much explicitly allowed, but this is pointless. Truth is, developers are doing something that can fuck up their system daily. Let's forget about wget | bash and copying…
not everyone is running on a multi-user system either (realistically speaking, most personal computers are single user). That doesn't mean microsoft/apple/linux doesn't care about escalation of privilege exploits.
>Truth is, developers are doing something that can fuck up their system daily. Let's forget about wget | bash and copying completely untrusted git repositories (and it's pretty much guaranteed that everybody using git-enabled PS1 won't shy away from that).
So because devs are doing dumb shit on a daily basis, they shouldn't fix security vulnerabilities? What if I'm not doing dumb shit? should I get hacked because I entered a malicious directory on a multi-user system?
>I mean, actually fixing: making it possible to disable hooks & core.fsmonitor & whatever else they fucked up? No, right, let's just disable git instead.
but then what if you need hooks? then you'll have to somehow manually enable it on a repo-by-repo basis, which also doesn't seem very convenient. At least with the ownership check it's transparent to most users. For people that use shared directories and/or network drive mounts, they can always whitelist the path.
Re: Git security vulnerability announced
#93Earlier 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…
What do you mean by “git often installs”. Git does not install anything. Developers configure their PS1 or install something that does.
Re: Git security vulnerability announced
#94Did the link get changed? I can't find anything of what anyone is talking about in this github.blog post.
Re: Git security vulnerability announced
#95Re: Git security vulnerability announced
#96> 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?
Repos can have precommit hooks, which are just executables (usually executable she'll scripts, but anything will do) that will run (as your user) on commit, checkout, etc. I feel like this change is a far bigger one than thought, and it's gonna break some workflows, such as mine where I have a git repo that's shared between multiple "users" that I run applications as. I'm glad I've not gotten too far into this projec…
Breaks the CI system for perl, for example.
Re: Git security vulnerability announced
#97I feel like this doesn't have much to do with Git specifically. Seems to me like PS1 needs to avoid accessing files that aren't owned by the current user. Easier said than done though...
That’s partly true, but it is more relevant to Git than to other things because there are malicious ways to configure a git repository that will end up running programs written by someone else under your user id.
Re: Git security vulnerability announced
#98Well, 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…
Yes I’ve run “git status”, “git log” and “git diff” on other people’s repo’s plenty of times to help debug things, so it’d be sad to see this stop working. It seems some basic readonly operations should still be supported.
Re: Git security vulnerability announced
#99Did the link get changed? I can't find anything of what anyone is talking about in this github.blog post.
Re: Git security vulnerability announced
#100Earlier quoted context omitted.
That’s partly true, but it is more relevant to Git than to other things because there are malicious ways to configure a git repository that will end up running programs written by someone else under your user id.
Why are you setting your ps1 to run arbitrary code in any directory? Don’t do that!