Some Git LFS hooks keep reappearing server-side #19810

samhocevar · 2022-05-26T10:45:41Z

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 = [email protected]
[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

The text was updated successfully, but these errors were encountered:

Gusted · 2022-05-26T19:52:17Z

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 · 2022-05-26T21:35:07Z

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 · 2022-05-27T12:50:26Z

@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 · 2022-10-28T18:15:27Z

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 · 2022-10-28T20:04:22Z

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 · 2022-10-28T22:37:00Z

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 · 2022-10-31T10:33:13Z

@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 · 2023-05-22T14:12:15Z

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 · 2023-05-22T14:25:15Z

The problem described in #21148 is still reproduced on 1.19.3

wxiaoguang · 2023-05-22T14:28:33Z

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

puni9869 · 2023-07-29T20:01:03Z

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

AdamMajer · 2023-12-12T14:56:55Z

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?

When LFS hooks are present in gitea-repositories, operations like git push for creating a pull request fail. These repositories are not meant to include LFS files or git push them, that is handled separately. And so they should not have LFS hooks. Installing git-lfs on some systems (like Debian Linux) will automatically set up /etc/gitconfig to create LFS hooks in repositories. For most git commands in Gitea this is not a problem, either because they run on a temporary clone or the git command does not create LFS hooks. But one case where this happens is git archive for creating repository archives. To fix that, add a GIT_CONFIG_NOSYSTEM=1 to disable using the system configuration for that command. According to a comment, GIT_CONFIG_NOSYSTEM is not used for all git commands because the system configuration can be intentionally set up for Gitea to use. Resolves go-gitea#19810, go-gitea#21148

When LFS hooks are present in gitea-repositories, operations like git push for creating a pull request fail. These repositories are not meant to include LFS files or git push them, that is handled separately. And so they should not have LFS hooks. Installing git-lfs on some systems (like Debian Linux) will automatically set up /etc/gitconfig to create LFS hooks in repositories. For most git commands in Gitea this is not a problem, either because they run on a temporary clone or the git command does not create LFS hooks. But one case where this happens is git archive for creating repository archives. To fix that, add a GIT_CONFIG_NOSYSTEM=1 to disable using the system configuration for that command. According to a comment, GIT_CONFIG_NOSYSTEM is not used for all git commands because the system configuration can be intentionally set up for Gitea to use. Resolves #19810, #21148

…8848) When LFS hooks are present in gitea-repositories, operations like git push for creating a pull request fail. These repositories are not meant to include LFS files or git push them, that is handled separately. And so they should not have LFS hooks. Installing git-lfs on some systems (like Debian Linux) will automatically set up /etc/gitconfig to create LFS hooks in repositories. For most git commands in Gitea this is not a problem, either because they run on a temporary clone or the git command does not create LFS hooks. But one case where this happens is git archive for creating repository archives. To fix that, add a GIT_CONFIG_NOSYSTEM=1 to disable using the system configuration for that command. According to a comment, GIT_CONFIG_NOSYSTEM is not used for all git commands because the system configuration can be intentionally set up for Gitea to use. Resolves go-gitea#19810, go-gitea#21148

@brechtvl

…28851) Backport #28848 by @brechtvl When LFS hooks are present in gitea-repositories, operations like git push for creating a pull request fail. These repositories are not meant to include LFS files or git push them, that is handled separately. And so they should not have LFS hooks. Installing git-lfs on some systems (like Debian Linux) will automatically set up /etc/gitconfig to create LFS hooks in repositories. For most git commands in Gitea this is not a problem, either because they run on a temporary clone or the git command does not create LFS hooks. But one case where this happens is git archive for creating repository archives. To fix that, add a GIT_CONFIG_NOSYSTEM=1 to disable using the system configuration for that command. According to a comment, GIT_CONFIG_NOSYSTEM is not used for all git commands because the system configuration can be intentionally set up for Gitea to use. Resolves #19810, #21148 Co-authored-by: Brecht Van Lommel <[email protected]>

…8848) When LFS hooks are present in gitea-repositories, operations like git push for creating a pull request fail. These repositories are not meant to include LFS files or git push them, that is handled separately. And so they should not have LFS hooks. Installing git-lfs on some systems (like Debian Linux) will automatically set up /etc/gitconfig to create LFS hooks in repositories. For most git commands in Gitea this is not a problem, either because they run on a temporary clone or the git command does not create LFS hooks. But one case where this happens is git archive for creating repository archives. To fix that, add a GIT_CONFIG_NOSYSTEM=1 to disable using the system configuration for that command. According to a comment, GIT_CONFIG_NOSYSTEM is not used for all git commands because the system configuration can be intentionally set up for Gitea to use. Resolves go-gitea#19810, go-gitea#21148

github-actions · 2024-03-01T00:02:29Z

Automatically locked because of our CONTRIBUTING guidelines

@brechtvl

…8848) (go-gitea#28851) Backport go-gitea#28848 by @brechtvl When LFS hooks are present in gitea-repositories, operations like git push for creating a pull request fail. These repositories are not meant to include LFS files or git push them, that is handled separately. And so they should not have LFS hooks. Installing git-lfs on some systems (like Debian Linux) will automatically set up /etc/gitconfig to create LFS hooks in repositories. For most git commands in Gitea this is not a problem, either because they run on a temporary clone or the git command does not create LFS hooks. But one case where this happens is git archive for creating repository archives. To fix that, add a GIT_CONFIG_NOSYSTEM=1 to disable using the system configuration for that command. According to a comment, GIT_CONFIG_NOSYSTEM is not used for all git commands because the system configuration can be intentionally set up for Gitea to use. Resolves go-gitea#19810, go-gitea#21148 Co-authored-by: Brecht Van Lommel <[email protected]> (cherry picked from commit 0d50f27)

samhocevar added the type/bug label May 26, 2022

philip-peterson mentioned this issue Oct 28, 2022

After downloading a repository with LFS files as an archive, unnecessary git-hooks created and as a result trying to create a PR results in an error 500 #21148

Closed

wxiaoguang added the issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail label May 22, 2023

wxiaoguang added this to the 1.20.0 milestone May 22, 2023

delvh removed this from the 1.20.0 milestone Jun 5, 2023

lunny added the topic/lfs label Jul 31, 2023

brechtvl mentioned this issue Jan 19, 2024

Fix archive creating LFS hooks and breaking pull requests #28848

Merged

lunny closed this as completed in #28848 Jan 19, 2024

GiteaBot mentioned this issue Jan 19, 2024

Fix archive creating LFS hooks and breaking pull requests (#28848) #28851

Merged

github-actions bot locked as resolved and limited conversation to collaborators Mar 1, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Some Git LFS hooks keep reappearing server-side #19810

Some Git LFS hooks keep reappearing server-side #19810

samhocevar commented May 26, 2022 •

edited

Loading

Gusted commented May 26, 2022

zeripath commented May 26, 2022

silentcodeg commented May 27, 2022

philip-peterson commented Oct 28, 2022

dav-sea commented Oct 28, 2022 •

edited

Loading

philip-peterson commented Oct 28, 2022

dav-sea commented Oct 31, 2022

wxiaoguang commented May 22, 2023

dav-sea commented May 22, 2023

wxiaoguang commented May 22, 2023

puni9869 commented Jul 29, 2023

AdamMajer commented Dec 12, 2023

github-actions bot commented Mar 1, 2024

Some Git LFS hooks keep reappearing server-side #19810

Some Git LFS hooks keep reappearing server-side #19810

Comments

samhocevar commented May 26, 2022 • edited Loading

Description

Gitea Version

Can you reproduce the bug on the Gitea demo site?

Log Gist

Screenshots

Git Version

Operating System

How are you running Gitea?

Database

Gusted commented May 26, 2022

zeripath commented May 26, 2022

silentcodeg commented May 27, 2022

philip-peterson commented Oct 28, 2022

dav-sea commented Oct 28, 2022 • edited Loading

philip-peterson commented Oct 28, 2022

dav-sea commented Oct 31, 2022

wxiaoguang commented May 22, 2023

dav-sea commented May 22, 2023

wxiaoguang commented May 22, 2023

puni9869 commented Jul 29, 2023

AdamMajer commented Dec 12, 2023

github-actions bot commented Mar 1, 2024

samhocevar commented May 26, 2022 •

edited

Loading

dav-sea commented Oct 28, 2022 •

edited

Loading