Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
2 answers
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| alx | (no comment) | Aug 20, 2024 at 09:35 |
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.
git pull is dangerous, but not a security problem. The only danger is that it's difficult or inconvenient (but not impossible) to recover to the state prior to the pull, if it would be necessary.
Merge commits
The remote branch might have diverged from your own, in which case git will automatically try to resolve any conflicts with a merge commit. This might result in bad conflict resolutions (although that's rare).
This can be solved by running git pull --ff-only instead, which will only merge the origin changes if your local branch can be fast-forwarded (no merge commits).
If there are any local changes not in the remote branch, the pull will fail, and you'll be able to resolve the situation with a different method.
However, this solution doesn't solve the other problems of git-pull(1), so continue reading.
Predictability
git-pull(1) performs two operations:
- download the latest branch from the remote
- merge it to the local branch
But you can't predict what's in the remote branch. This means that your local branch will blindly jump to whatever commit the remote branch is in (assuming git pull --ff-only, and that your local branch has no changes).
You won't know where your branch was prior to the jump, unless you wrote the old commit hash somewhere. If after the pull you find out that you don't like the changes and want to go back to the old state, it will be hard to know where you were. (Imagine for example that the remote could have been hacked, and malicious contents could have been introduced in the branch.)
git-pull(1) has no way to mitigate this, since it's a problem inherent to the fact that git-pull(1) performs two operations.
The solution is to run two commands to perform those operations separately:
git fetch origingit merge --ff-only origin/master
Between the fetch and the merge, you can print a graph of the log, to analyze what will be merged:
$ git fetch origin
$ git log --all --graph --oneline
$ git merge --ff-only origin/master # or rebase, or whatever you need; you already know what you're merging. :)
Printing the log graph in the terminal will also let you have all the commit hashes written, in case you make any mistakes and need to go back to the original state (git reset <old-master> --hard) and start again.
This approach allows you to review all of the remote commits before merging them into any local branch.
3 comment threads
1 comment thread