71–80 of 302 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
This article on a CVE for git published today has details on the vulnerability: https://github.blog/2022-04-12-git-security-vulnerability-an...
Ok, we've changed to that from https://github.com/git/git/commit/8959555cee7ec045958f9b6dd6... . Thanks!
I 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…
No criticism intended.
Earlier quoted context omitted.
in other news, access to a users account gives them access to a users account
In earlier news, it's unexpected that "cd directory" will give the directory owner access to your account.
Git hooks have always been sketchy as hell.
Can't stand the Mac specific shit my co-workers keep dumping in there.
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.
I 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…
is_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.
Deep inside some large enterprise company: Jr Engineer: "Hey, I know we've always managed our little dotnet application via email and shared-network-drive, but I've been reading about a thing called "git" that we should probably use." Sr Engineer: "Change is scary and bad, also we are not a software company. We're not going to learn some newfangled whatsit. Just email me the .vba files when you want me to review the…
I 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…
(A better fix would be to allow the command if there's no hooks, which does seem feasible, and only failing if it's actually asked to do something dangerous.)
But ok, let's not take it as an excuse. How about fixing git, then? 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.
And if I'm reading this correctly, I'm not even allowed to say "I don't care" — I must explicitly mark every shared directory as trusted (I mean, safe.directory = '/' won't work unless / is actually a git directory, right?).
I guess I just shouldn't update git until this "fix" is fixed. Or until git is forked.