github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-13 02:57:44 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

LFS locks not enforced on server side (can push commit modifying a file locked by another user) #5246

New Issue
Open
opened 2025-11-02 06:19:02 -06:00 by GiteaMirror · 10 comments
GiteaMirror commented 2025-11-02 06:19:02 -06:00
Owner
Copy Link

Originally created by @ckuhlmann on GitHub (Apr 16, 2020).

  • Gitea version (or commit ref): 1.11.4
  • Git version: 2.26.1.windows.1
  • Operating system: Win7x64
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No (no LFS support)
    • Not relevant
  • Log gist:

Description

Steps to reproduce:

  1. Create a new gitea instance or use an existing one
  2. Add an admin user to gitea with name lfs_admin and password LFS_admin1 and extract the attached scripts.zip to a convenient directory.
  3. Modify the value of variable GITEAHOST in line 3 of s01_admin.sh (in attached zip) to match your gitea host name and save.
  4. Run
    ./s01_admin.sh
    in a git bash.
    This creates two users (a_user, b_user) and gives a_user a repo a_lfs_test, to which b_user is added as collaborator with write permission
  5. Modify the value of variable GITEAHOST in line 4 of s02_a_user.sh (in attached zip) to match your gitea host and save.
  6. Run
    ./s02_a_user.sh
    in a git bash.
    This initializes the a_lfs_test repo in sub-folder a_repo and puts all *.png files as lockable under LFS control. A file img.png is created and initialized with the content of wiki.png. This file and .gitattributes are staged, commited and pushed. Afterwards, the img.png file is locked by a_user.
  7. Modify the value of variable GITEAHOST in line 4 of s03_b_user.sh (in attached zip) to match your gitea host and save.
  8. Run
    ./s03_b_user.sh
    in a git bash (perhaps on a different machine, the result is the same).
    This clones the a_lfs_test repo into subfolder b_repo and initializes LFS. Because .gitattributes is checked out, LFS and locks are enabled for .png files. img.png is force overwritten by the contents of dice.png, staged, committed and pushed.
  9. Observe the following output after running ./s03_b_user.sh in the previous step:
$ ./s03_b_user.sh
Cloning into 'b_repo'...
[...]
'../dice.png' -> './img.png'
[...]
[master d78418b] img->dice
 1 file changed, 2 insertions(+), 2 deletions(-)
Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.http://b_user:B_user1,@localhost:88/a_user/a_lfs_test.git/info/lfs.locksverify true
Unable to push locked files:(1/1), 48 KB | 0 B/s
* img.png - A_User (refs: master)
WARNING: The above files would have halted this push.
Uploading LFS objects: 100% (1/1), 48 KB | 0 B/s, done.
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 355 bytes | 355.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: . Processing 1 references
remote: Processed 1 references in total
To http://localhost:88/a_user/a_lfs_test.git
   2e229ad..d78418b  master -> master
img.png A_User  ID:2
  1. Although a message Unable to push locked files:(1/1) is returned, only a warning WARNING: The above files would have halted this push. results and the push succeeds 2e229ad..d78418b master -> master even though the lock of a_user persists (git lfs locks -> img.png A_User ID:2)
  2. The result is also visible by opening img.png in the gitea UI: It shows the lock of a_user, but the content of dice.png pushed by b_user.

Expected result:
The push by b_user should be rejected (at least through a gitea configuration option), because a_user still holds a lock on img.png

Actual Result:
The push succeeds and the locked file img.png is modified by b_user

Requested change:
Please add a gitea configuration setting (either global or even better per repo) to reject such pushes on the server side, since otherwise locks are meaningless if the default client configuration is used. This leaves locks totally up to correct client configuration, which is error prone and negates the "protection" that locks should offer.

Thanks for gitea and for considering this request.

scripts.zip

Originally created by @ckuhlmann on GitHub (Apr 16, 2020). <!-- NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue --> <!-- [scripts.zip](https://github.com/go-gitea/gitea/files/4486348/scripts.zip) 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - Gitea version (or commit ref): 1.11.4 - Git version: 2.26.1.windows.1 - Operating system: Win7x64 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No (no LFS support) - [ ] Not relevant - Log gist: ## Description Steps to reproduce: 1. Create a new gitea instance or use an existing one 2. Add an admin user to gitea with name `lfs_admin` and password `LFS_admin1` and extract the attached [scripts.zip](https://github.com/go-gitea/gitea/files/4487308/scripts.zip) to a convenient directory. 3. Modify the value of variable `GITEAHOST` in line 3 of `s01_admin.sh` (in attached zip) to match your gitea host name and save. 4. Run `./s01_admin.sh` in a git bash. This creates two users (`a_user`, `b_user`) and gives `a_user` a repo `a_lfs_test`, to which `b_user` is added as collaborator with `write` permission 5. Modify the value of variable `GITEAHOST` in line 4 of `s02_a_user.sh` (in attached zip) to match your gitea host and save. 6. Run `./s02_a_user.sh` in a git bash. This initializes the `a_lfs_test` repo in sub-folder `a_repo` and puts all *.png files as lockable under LFS control. A file `img.png` is created and initialized with the content of `wiki.png`. This file and `.gitattributes` are staged, commited and pushed. Afterwards, the `img.png` file is locked by `a_user`. 7. Modify the value of variable `GITEAHOST` in line 4 of `s03_b_user.sh` (in attached zip) to match your gitea host and save. 8. Run `./s03_b_user.sh` in a git bash (perhaps on a different machine, the result is the same). This clones the `a_lfs_test` repo into subfolder `b_repo` and initializes LFS. Because `.gitattributes` is checked out, LFS and locks are enabled for `.png` files. `img.png` is force overwritten by the contents of `dice.png`, staged, committed and pushed. 9. Observe the following output after running `./s03_b_user.sh` in the previous step: ```bash $ ./s03_b_user.sh Cloning into 'b_repo'... [...] '../dice.png' -> './img.png' [...] [master d78418b] img->dice 1 file changed, 2 insertions(+), 2 deletions(-) Locking support detected on remote "origin". Consider enabling it with: $ git config lfs.http://b_user:B_user1,@localhost:88/a_user/a_lfs_test.git/info/lfs.locksverify true Unable to push locked files:(1/1), 48 KB | 0 B/s * img.png - A_User (refs: master) WARNING: The above files would have halted this push. Uploading LFS objects: 100% (1/1), 48 KB | 0 B/s, done. Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 4 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 355 bytes | 355.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 remote: . Processing 1 references remote: Processed 1 references in total To http://localhost:88/a_user/a_lfs_test.git 2e229ad..d78418b master -> master img.png A_User ID:2 ``` 10. Although a message `Unable to push locked files:(1/1)` is returned, only a warning `WARNING: The above files would have halted this push.` results and the push succeeds `2e229ad..d78418b master -> master` even though the lock of `a_user` persists (`git lfs locks` -> `img.png A_User ID:2`) 11. The result is also visible by opening `img.png` in the gitea UI: It shows the lock of `a_user`, but the content of `dice.png` pushed by `b_user`. **Expected result:** The push by `b_user` should be rejected (at least through a gitea configuration option), because `a_user` still holds a lock on `img.png` **Actual Result:** The push succeeds and the locked file `img.png` is modified by `b_user` **Requested change:** Please add a gitea configuration setting (either global or even better per repo) to reject such pushes on the server side, since otherwise locks are meaningless if the default client configuration is used. This leaves locks totally up to correct client configuration, which is error prone and negates the "protection" that locks should offer. Thanks for gitea and for considering this request. [scripts.zip](https://github.com/go-gitea/gitea/files/4487308/scripts.zip)
GiteaMirror added the issue/confirmedtype/enhancementtopic/lfs labels 2025-11-02 06:19:02 -06:00
GiteaMirror commented 2025-11-02 06:19:03 -06:00
Author
Owner
Copy Link

@Eric-Li-376192056 commented on GitHub (Apr 17, 2020):

I met this problem too, please consider this request.

@Eric-Li-376192056 commented on GitHub (Apr 17, 2020): I met this problem too, please consider this request.
GiteaMirror commented 2025-11-02 06:19:03 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jun 17, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Jun 17, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.
GiteaMirror commented 2025-11-02 06:19:03 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jul 3, 2020):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Jul 3, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.
GiteaMirror commented 2025-11-02 06:19:03 -06:00
Author
Owner
Copy Link

@eNBeWe commented on GitHub (Dec 2, 2020):

Just ran into this issue.
I assumed that locked files would indeed be handled as locked as was very surprised when gitea just accepted the push.
Anything left to be done? Can anyone support to get this feature?

@eNBeWe commented on GitHub (Dec 2, 2020): Just ran into this issue. I assumed that locked files would indeed be handled as locked as was very surprised when gitea just accepted the push. Anything left to be done? Can anyone support to get this feature?
GiteaMirror commented 2025-11-02 06:19:04 -06:00
Author
Owner
Copy Link

@jhgryder commented on GitHub (May 24, 2021):

I am also experiencing this issue with Gitea version 1.13.2 and Git LFS version 2.13.2. Is there any plan to fix Gitea to enforce LFS locking?

@jhgryder commented on GitHub (May 24, 2021): I am also experiencing this issue with Gitea version 1.13.2 and Git LFS version 2.13.2. Is there any plan to fix Gitea to enforce LFS locking?
GiteaMirror commented 2025-11-02 06:19:04 -06:00
Author
Owner
Copy Link

@PostPollux commented on GitHub (Aug 26, 2021):

Having the same problem with Gitea 1.15.0. Would be nice to see this in a future release!

@PostPollux commented on GitHub (Aug 26, 2021): Having the same problem with Gitea 1.15.0. Would be nice to see this in a future release!
GiteaMirror commented 2025-11-02 06:19:04 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Aug 26, 2021):

Maybe we need check the lock in the function https://github.com/go-gitea/gitea/blob/v1.15.0/services/lfs/server.go#L253

@lunny commented on GitHub (Aug 26, 2021): Maybe we need check the lock in the function https://github.com/go-gitea/gitea/blob/v1.15.0/services/lfs/server.go#L253
GiteaMirror commented 2025-11-02 06:19:05 -06:00
Author
Owner
Copy Link

@markusstephanides commented on GitHub (Jun 30, 2022):

Bump. What is the point of having locks if they are not enforced? Or am I missing something?

@markusstephanides commented on GitHub (Jun 30, 2022): Bump. What is the point of having locks if they are not enforced? Or am I missing something?
GiteaMirror commented 2025-11-02 06:19:05 -06:00
Author
Owner
Copy Link

@Gromina commented on GitHub (Feb 3, 2023):

I do need this feature as well.

@Gromina commented on GitHub (Feb 3, 2023): I do need this feature as well.
GiteaMirror commented 2025-11-02 06:19:05 -06:00
Author
Owner
Copy Link

@sfellnersmart commented on GitHub (Aug 7, 2023):

I do need this feature as well.
Please implement a working mechanism that prevents a locked file from being overwritten! Otherwise this function is nonsense.

Gitea version 1.18.5 and Git LFS version 3.3.0.

@sfellnersmart commented on GitHub (Aug 7, 2023): I do need this feature as well. Please implement a working mechanism that prevents a locked file from being overwritten! Otherwise this function is nonsense. Gitea version 1.18.5 and Git LFS version 3.3.0.
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 topic/lfs type/enhancement
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#5246
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?