Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some Git LFS hooks keep reappearing server-side #19810

Closed
samhocevar opened this issue May 26, 2022 · 13 comments · Fixed by #28848
Closed

Some Git LFS hooks keep reappearing server-side #19810

samhocevar opened this issue May 26, 2022 · 13 comments · Fixed by #28848
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented issue/critical This issue should be fixed ASAP. If it is a PR, the PR should be merged ASAP topic/lfs type/bug

Comments

@samhocevar
Copy link

samhocevar commented 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 #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
Copy link
Contributor

Gusted commented May 26, 2022

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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link

dav-sea commented 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

@philip-peterson
Copy link
Contributor

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
Copy link

dav-sea commented 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.

@wxiaoguang
Copy link
Contributor

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 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
@dav-sea
Copy link

dav-sea commented May 22, 2023

The problem described in #21148 is still reproduced on 1.19.3

@wxiaoguang wxiaoguang added issue/critical This issue should be fixed ASAP. If it is a PR, the PR should be merged ASAP issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented and removed issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail labels May 22, 2023
@wxiaoguang wxiaoguang added this to the 1.20.0 milestone May 22, 2023
@wxiaoguang
Copy link
Contributor

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

@delvh delvh removed this from the 1.20.0 milestone Jun 5, 2023
@puni9869
Copy link
Member

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

@AdamMajer
Copy link
Contributor

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?

brechtvl added a commit to brechtvl/gitea that referenced this issue Jan 19, 2024
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
lunny pushed a commit that referenced this issue Jan 19, 2024
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
GiteaBot pushed a commit to GiteaBot/gitea that referenced this issue Jan 19, 2024
…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
KN4CK3R pushed a commit that referenced this issue Jan 21, 2024
…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 <brecht@blender.org>
henrygoodman pushed a commit to henrygoodman/gitea that referenced this issue Jan 31, 2024
…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
silverwind pushed a commit to silverwind/gitea that referenced this issue Feb 20, 2024
…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
Copy link

github-actions bot commented Mar 1, 2024

Automatically locked because of our CONTRIBUTING guidelines

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented issue/critical This issue should be fixed ASAP. If it is a PR, the PR should be merged ASAP topic/lfs type/bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.