github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-05-22 05:15:42 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Some Git LFS hooks keep reappearing server-side #9000

New Issue
Closed
opened 2025-11-02 08:25:13 -06:00 by GiteaMirror · 13 comments
GiteaMirror commented 2025-11-02 08:25:13 -06:00
Owner
Copy Link

Originally created by @samhocevar on GitHub (May 26, 2022).

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 https://github.com/go-gitea/gitea/issues/8646#issuecomment-546334213 or https://github.com/go-gitea/gitea/issues/13597#issuecomment-733281409 or https://github.com/go-gitea/gitea/issues/6460#issuecomment-478711177). 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

Originally created by @samhocevar on GitHub (May 26, 2022). ### 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`: ```sh #!/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 https://github.com/go-gitea/gitea/issues/8646#issuecomment-546334213 or https://github.com/go-gitea/gitea/issues/13597#issuecomment-733281409 or https://github.com/go-gitea/gitea/issues/6460#issuecomment-478711177). 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: ```ini [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
GiteaMirror added the issue/confirmedissue/criticaltopic/lfstype/bug labels 2025-11-02 08:25:14 -06:00
GiteaMirror commented 2025-11-02 08:25:15 -06:00
Author
Owner
Copy Link

@Gusted commented on GitHub (May 26, 2022):

These hooks are generated by git. As shown in issue https://github.com/go-gitea/gitea/issues/13597#issuecomment-733281409 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 🤷🏽.

@Gusted commented on GitHub (May 26, 2022): These hooks are generated by git. As shown in issue https://github.com/go-gitea/gitea/issues/13597#issuecomment-733281409 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 🤷🏽.
GiteaMirror commented 2025-11-02 08:25:15 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 26, 2022):

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.

@zeripath commented on GitHub (May 26, 2022): 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.
GiteaMirror commented 2025-11-02 08:25:15 -06:00
Author
Owner
Copy Link

@silentcodeg commented on GitHub (May 27, 2022):

@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.

@silentcodeg commented on GitHub (May 27, 2022): @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.
GiteaMirror commented 2025-11-02 08:25:15 -06:00
Author
Owner
Copy Link

@philip-peterson commented on GitHub (Oct 28, 2022):

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
@philip-peterson commented on GitHub (Oct 28, 2022): 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 ```
GiteaMirror commented 2025-11-02 08:25:15 -06:00
Author
Owner
Copy Link

@dav-sea commented on GitHub (Oct 28, 2022):

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

@dav-sea commented on GitHub (Oct 28, 2022): 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
GiteaMirror commented 2025-11-02 08:25:16 -06:00
Author
Owner
Copy Link

@philip-peterson commented on GitHub (Oct 28, 2022):

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

@philip-peterson commented on GitHub (Oct 28, 2022): 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
GiteaMirror commented 2025-11-02 08:25:16 -06:00
Author
Owner
Copy Link

@dav-sea commented on GitHub (Oct 31, 2022):

@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.

@dav-sea commented on GitHub (Oct 31, 2022): @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](https://github.com/sergey-cs/representation-for-bug-with-download-archive-on-gitea).
GiteaMirror commented 2025-11-02 08:25:16 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (May 22, 2023):

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?

@wxiaoguang commented on GitHub (May 22, 2023): 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?
GiteaMirror commented 2025-11-02 08:25:16 -06:00
Author
Owner
Copy Link

@dav-sea commented on GitHub (May 22, 2023):

The problem described in #21148 is still reproduced on 1.19.3

@dav-sea commented on GitHub (May 22, 2023): The problem described in #21148 is still reproduced on 1.19.3
GiteaMirror commented 2025-11-02 08:25:17 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (May 22, 2023):

Changed the label to confirmed+critical, hopefully it could be resolved in 1.20

@wxiaoguang commented on GitHub (May 22, 2023): Changed the label to confirmed+critical, hopefully it could be resolved in 1.20
GiteaMirror commented 2025-11-02 08:25:17 -06:00
Author
Owner
Copy Link

@puni9869 commented on GitHub (Jul 29, 2023):

Needs some eyes on it. Are we still tracking this issue.

@puni9869 commented on GitHub (Jul 29, 2023): Needs some eyes on it. Are we still tracking this issue.
GiteaMirror commented 2025-11-02 08:25:17 -06:00
Author
Owner
Copy Link

@AdamMajer commented on GitHub (Dec 12, 2023):

I could only reproduce this issue if there is a global /etc/gitconfig with lfs filters installed. I've noticed that on linux distributions, like openSUSE TW or Debian, there are post-install scripts that install these filter systemwide.

https://sources.debian.org/src/git-lfs/3.4.0-1/debian/git-lfs.postinst/

Is Gitea suppose to run with these global filters installed or should these filters be absent?

@AdamMajer commented on GitHub (Dec 12, 2023): I could only reproduce this issue if there is a global `/etc/gitconfig` with lfs filters installed. I've noticed that on linux distributions, like openSUSE TW or Debian, there are post-install scripts that install these filter systemwide. https://sources.debian.org/src/git-lfs/3.4.0-1/debian/git-lfs.postinst/ Is Gitea suppose to run with these global filters installed or should these filters be absent?
GiteaMirror commented 2025-11-02 08:25:17 -06:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 1, 2024):

Automatically locked because of our CONTRIBUTING guidelines

@github-actions[bot] commented on GitHub (Mar 1, 2024): Automatically locked because of our [CONTRIBUTING guidelines](https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md#issue-locking)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/confirmed issue/critical topic/lfs type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#9000
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?