Post History

While any piece of software receiving input from an untrusted source is additional attack surface, generally speaking `git pull` is not a security threat.

Three things happen when you `git pull`: a `git fetch`, a `git merge` or `git rebase` (depending on config), and any hooks you've defined may fire.

Starting with the last, the hooks are arbitrary scripts that can do anything before/during/after a pull. As such, hooks very much could harbor a security vulnerability, but you have to decide to add such hooks. A `git pull` can't add hooks itself.

`git fetch` is the step that actually retrieves data from the remote source. It basically just downloads it. There's a potential for a denial of service attack via resource exhaustion, e.g. using a lot of disk space or bandwidth, but that's about it.

While git will verify TLS certificates and such, it doesn't really "authenticate" the repository. Given the distributed model, this doesn't really make much sense. There are three scenarios for malicious input here: 1) extra "detached" commits, 2) changing history, 3) commits to a branch (including the main branch). The first doesn't really accomplish anything, such commits won't even be attempted to be merged in. The second is cryptographically hard to do. The attacker could make a *different* history, but that would not be silently merged at all. The last is a real problem but comes down to whether you trust the person who wrote the commit and this is addressed by commit signing.

`git merge`/`git rebase` is an entirely local operation but, of course, it's working on data gathered from a potentially untrusted source. The actual merge or rebase is just editing the source files and metadata. Besides any hooks, no "user code" is being executed. The main risk is that commits themselves introduce malicious code into the codebase. Commit signing can mitigate this, but, ultimately, the only way to be "sure" is to audit the changes yourself.

All told, the risk of a `git pull` itself pwning your machine is low.

----

The self-answer seems to define "dangerous" as "causes you an inconvenience". While I endorse restricting to only fast-forward pulls, the first issue in that answer is really with automatic conflict resolution. `--ff-only` alerts you to this consideration, but you still have to review the changes. Or, you know, don't, because the automatic merging logic is usually fine, and when it's not it is highly likely to break the build and/or tests.

The second issue that self-answer puts forward is purely an inconvenience, and the solution is not painstakingly verify all commits you're about to merge, but knowing how to back out of the problem if it happens. Specifically, the problem is that you may want to "undo" even a fast-forward merge. Of course, you have all history so this is certainly possible, but you need to know the hashes. The solution,  `git log -g` or `git reflog`. These list the reflog which is a record of the commands that changed a reference (such as `HEAD`). So if you `git pull --ff-only` and decide you want to change your mind, you can simply run `git log -g` or `git reflog` and get the commit hash immediately preceding the pull which will be plainly recorded.