Some Git LFS hooks keep reappearing server-side

[samhocevar]

Description

At random moments that we have been unable to clearly identify, like every couple of months, the post-checkout, post-commit, post-merge and pre-push LFS hooks reappear in a repository on the server. This has happened to several repositories, and multiple times to the same repository. The contents of the files are always the default LFS hooks, e.g. for pre-push:

#!/bin/sh
command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/pre-push.\n"; exit 2; }
git lfs pre-push "$@"

This breaks all pull requests (as seen e.g. in #8646 (comment) or #13597 (comment) or #6460 (comment)). It seems #16372 also has an occurrence of these hooks appearing for seemingly no reason.

We have millions of lines of logs, with sensitive information even in repository names, so I will have trouble sharing full logs, but I can filter them if instructed on what could be relevant. Looking at the logs at the hook creation timestamp (in this case, 2022-05-25 17:31:19.279970086), nothing happens in the logs. Looking a few seconds after or before that, the only Git commands issued appear innocuous (cat-file, show-ref, upload-pack, and log).

I have seen that the ~git/.gitconfig file may be relevant, so here it is:

[user]
        name = Gitea
        email = gitea@fake.local
[core]
        quotepath = false
        commitGraph = true
[credential]
        helper = store
[filter "lfs"]
        clean = git-lfs clean -- %f
        smudge = git-lfs smudge -- %f
        process = git-lfs filter-process
        required = true
[gc]
        writeCommitGraph = true
[alias]
        ll = log --oneline
[receive]
        advertisePushOptions = true
        procReceiveRefs = refs/for

Gitea Version

1.16.0+dev-350-ge11c19ed6

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

git version 2.35.1 — git-lfs/3.0.2 (GitHub; linux amd64; go 1.17.2)

Operating System

Debian GNU/Linux (sid)

How are you running Gitea?

• Gitea is built from source
• it has just one unrelated patch (changes in the password complexity)
• we run it under systemd
• there is an Apache reverse proxy in front of Gitea

Database

PostgreSQL 14.1

[Gusted]

These hooks are generated by git. As shown in issue #13597 (comment) it suggests that these hooks are somehow being added due to some condition(maybe user-error). So unless there's new evidence/analysis of when this happens, this is just a duplicate of that issue 🤷🏽.

[zeripath]

Your version of Gitea makes no sense as 1.16.0+dev-350-ge11c19ed6 is not a commit in Gitea.

Then:

git describe v1.16.0-rc1'^'

reveals that even v1.16.0-rc1 was at 882 commits after 1.16.0-dev was branched so even if 1.16.0+dev-350-ge11c19ed6 did represent a commit in Gitea it would be at least 1156 commits behind the current HEAD.

---

However, the thing putting these hooks in your repositories is not Gitea. Your configuration of git lfs is responsible for doing this.

[silentcodeg]

@samhocevar since this problem seems to be a recurring one, it would be quite helpful to figure out how it happened in your environment. Is there any chance that it could originate from a human error? If Gitea was installed on a server where you are certain that no human tampered with it, I'd be happy to investigate more. Given your background as a developer, I'm inclined to ultimately trust the information you provide is reliable and that you will followup should I dedicate time to figure this out.

[philip-peterson]

This seems to be caused by the download archive functionality. Can be fixed by having the git archive command it invokes (which has lfs filter-process configured) to be passed

-c core.hooksPath=/path/to/empty/dir

[dav-sea]

I think it is important that this fix gets into the release as soon as possible because more people using Git LFS might have this problem

[philip-peterson]

I actually can't reproduce it on vanilla Gitea, but here's a branch, maybe someone can see if it fixes it for them. https://github.com/go-gitea/gitea/compare/main...philip-peterson:gitea:peterson/poc-archive-patch?expand=1

[dav-sea]

@philip-peterson, The problem occurs only after closing the PR and creating a new one exactly the same. Specified it in the steps for reproduction here.

[wxiaoguang]

Now Gitea doesn't use the user's gitconfig, so I think if the problem is caused by the conflicts of user gitconfig, it might have been resolved?

[dav-sea]

The problem described in #21148 is still reproduced on 1.19.3