In earlier news, it's unexpected that "cd directory" will give the directory owner access to your account.

Tbh I thought this was pretty obvious.

Git hooks have always been sketchy as hell.

Can't stand the Mac specific shit my co-workers keep dumping in there.

Wait, I thought git hooks aren't pulled from remote.

Wouldn't untrusted git hooks mean that git verify-* are useless since you're already running untrusted code?

Just to react to:

>Wait, I thought git hooks aren't pulled from remote.

You are correct. They are not. Other tools may auto-install them (I hate it), but git does not ever.

On my current app we use husky which installs hooks when you do a yarn install

You are in luck, it seems: https://blog.typicode.com/husky-git-hooks-autoinstall/

(Though not completely sure.)

This is really dismissive. Unexpected execution is not a users fault, and can happen for a variety of reasons (you telling me you’ve never unzipped a full git path someone sent you?)

Hi!

I can cheerfully confirm that I've absolutely never:

- received a git repo as an archive from someone, and then

- changed to root with "su" before unpacking it somewhere, such that

- the chosen location was above the home directory layer of a multi-user system.

- in such a way that one of the directories of the /path/to/home path has a .git/ subdirectory as a direct child, and not as an unpacked-tarball/.git grandchild which would not be accidentally found by git. I.e. that one of these directories exists, which might be found by someone running "git" in their home:

  /.git
  /path/.git
  /path/to/.git
  /path/to/home/.git

rather than the more likely:

  /foo-project-123/.git
  /path/foo-project-123/.git
  /path/to/foo-project-123/.git
  /path/to/home/foo-project-123/.git

which will not be found by someone running "git" in their home directory.

If I did such a thing, I'd care more about what happens when I happen to step on one of the malicious hooks in that repo as root, and less about what happens if users step on it.

Good for you. You are not everyone.

There are far more likely accidents that the superuser can perpetrate, that we do not compensate for with silly logic in applications.

Superuser could download some malware and put it into the system PATH. OK, so let's not execute anything in the PATH, unless it is owned by us.

/bin/ls? Not owned by me, don't trust it.

Okay.

Because linux has failed almost entirely to meet user level threats. Unlike android - which has per app permissions file permissions, linux is not there yet.

I know a lot of people are interested in better incapsulation for specific programs, and I know there's a lot of work being done in the area, but it's nowhere near as effective, in my opinion, as android and other systems.

linux follows the unix philosophy on this sort of. OK, you're a user, with some shell script, maybe git, maybe bash and it's PS1, I don't care, all I see as a kernel is that, you have permissions to edit this, upload this, send a packet, whatever, have fun!

From that perspective, nothing is wrong. That was my point. You could download s script that does 'rm / -Rf' and there's no security issue. User are given access to do as they please with files.

The issue is users can no longer reasonably trust the software on their system, from home-dialing marketing information and tracking, to having all sorts security issues in their virtual machines and sandboxes, running random code from websites constantly, we need a better way to encapsulate per file, per folder, per camera, per whatever, permissions, implemented at a system level.

You can download a directory containing a script, cd into that repo and less the file. ‘cd foo’ should never trigger arbitrary command execution. Ever.

Containerisation wouldn’t solve this, bash or similar would almost always be fun with near limitless boundaries.

I beg to disagree. I like my https://direnv.net/

As long as it's strictly opt-in, it's fine. But it needs to be opt-in to be secure.

The source machine may not be set up as a server, or you may not have an account there. Sending a .zip file could be simpler than pushing the repo to a third system the receiver does have access to.

Sure, mailing binaries can also be the right thing sometimes, but just as with git repos, you definitely shouldn't be taking them from untrusted sources.

(and I bet that many people don't even realize how easy using `git push` to mirror a repo actually is, since git is very commonly used in a centralized fashion)

You’ve never unzipped a repo? That’s something I regularly do - clients can’t get me access to their scm, and it’s not worth the effort.

I don't think I ever did. I usually have an opposite problem and sometimes accidentally zip/tar a repo when it shouldn't be included (at least there's `--exclude-vcs`).

In any case, this doesn't sound like a good idea at all, as git hooks exist.

You’re right but also I’m mad that you’re right. I need to check what hook functions there are, but I knew about hooks and still overlooked them, which to me thinks that they’re non obvious. Maybe git should prompt you on first run, which is either whitelisted on your host or signed by your git keys or similar