Push via ssh looks for custom/conf/app.ini at wrong path #409

New Issue

GiteaMirror · 2025-11-02T03:22:07-06:00

GiteaMirror commented

2025-11-02 03:22:07 -06:00

Originally created by @jmert on GitHub (Feb 28, 2017).

Gitea version (or commit ref): Gitea version 1.0.0+351-g8947b711
Git version: git version 2.12.0
Operating system: Arch Linux
Database (use [x]):
- PostgreSQL
- MySQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

Using Arch's gittea-git AUR package, a recent recompile-and-update broke my ability to push to my repositories. The error message looked like:

$ git push
Counting objects: 10, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 1.83 KiB | 0 bytes/s, done.
Total 10 (delta 4), reused 0 (delta 0)
remote: 2017/02/28 08:42:59 [W] Custom config '/usr/bin/custom/conf/app.ini' not found, ignore this if you're running first time
remote: 2017/02/28 08:42:59 [...a/modules/log/log.go:59 NewGitLogger()] [E] Failed to create dir /usr/bin/log/hooks: mkdir /usr/bin/log: permission denied
To host:user/repo.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'gitea@host:user/repo.git'

I eventually figured out a work-around to be to add into my gitea user's ~/.ssh/environment file:

GITEA_CUSTOM=/var/lib/gitea/custom

The systemd service file includes this environment, so the web service started just fine. Neither of gitea's git hooks nor the authorized_keys file it generates explicitly includes this environment variable.

Searching through my system's update logs, it appears the issue has crept in sometime between versions r4904.284c0160-1 which was working and r5007.8947b711-1 which I installed yesterday. (I apologize for having to use the AUR package's versioning instead of gitea's versioning, but that's all my package manager knows about).

Originally created by @jmert on GitHub (Feb 28, 2017). - Gitea version (or commit ref): Gitea version 1.0.0+351-g8947b711 - Git version: git version 2.12.0 - Operating system: Arch Linux - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description Using Arch's [gittea-git AUR package](https://aur.archlinux.org/packages/gitea-git), a recent recompile-and-update broke my ability to push to my repositories. The error message looked like: ``` $ git push Counting objects: 10, done. Delta compression using up to 4 threads. Compressing objects: 100% (10/10), done. Writing objects: 100% (10/10), 1.83 KiB | 0 bytes/s, done. Total 10 (delta 4), reused 0 (delta 0) remote: 2017/02/28 08:42:59 [W] Custom config '/usr/bin/custom/conf/app.ini' not found, ignore this if you're running first time remote: 2017/02/28 08:42:59 [...a/modules/log/log.go:59 NewGitLogger()] [E] Failed to create dir /usr/bin/log/hooks: mkdir /usr/bin/log: permission denied To host:user/repo.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'gitea@host:user/repo.git' ``` I eventually figured out a work-around to be to add into my gitea user's `~/.ssh/environment` file: ``` GITEA_CUSTOM=/var/lib/gitea/custom ``` The systemd service file includes this environment, so the web service started just fine. Neither of gitea's git hooks nor the `authorized_keys` file it generates explicitly includes this environment variable. Searching through my system's update logs, it appears the issue has crept in sometime between versions `r4904.284c0160-1` which was working and `r5007.8947b711-1` which I installed yesterday. (I apologize for having to use the AUR package's versioning instead of gitea's versioning, but that's all my package manager knows about).

GiteaMirror added the issue/critical type/bug labels 2025-11-02 03:22:07 -06:00

GiteaMirror closed this issue

2025-11-02 03:22:07 -06:00

GiteaMirror commented

2025-11-02 03:22:08 -06:00

@lunny commented on GitHub (Feb 28, 2017):

The latest master version has a push bug which will be fixed by #1077. But I think that's not this one.
Could you cat your authorized_keys to see the command .../gitea serv. This command should include the custom app.ini parameter. And also please confirm your gitea's path is correct.

@lunny commented on GitHub (Feb 28, 2017): The latest master version has a push bug which will be fixed by #1077. But I think that's not this one. Could you cat your authorized_keys to see the command `.../gitea serv`. This command should include the custom app.ini parameter. And also please confirm your gitea's path is correct.

GiteaMirror commented

2025-11-02 03:22:08 -06:00

@jmert commented on GitHub (Feb 28, 2017):

The authorized_keys entries all start with:

command="/usr/bin/gitea serv key-1 --config='/var/lib/gitea/custom/conf/app.ini'",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa

I can confirm that my gitea binary is located at /usr/bin/gitea and that the custom configuration file is at /var/lib/gitea/custom/conf/app.ini.

(And for completeness, I also see #1073 / #1077 but that only presents itself once I've worked around the issue reported here. If I remove the ssh environment file, I can reliably have this problem instead.)

@jmert commented on GitHub (Feb 28, 2017): The `authorized_keys` entries all start with: ``` command="/usr/bin/gitea serv key-1 --config='/var/lib/gitea/custom/conf/app.ini'",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa ``` I can confirm that my gitea binary is located at `/usr/bin/gitea` and that the custom configuration file is at `/var/lib/gitea/custom/conf/app.ini`. (And for completeness, I also see #1073 / #1077 but that only presents itself once I've worked around the issue reported here. If I remove the ssh environment file, I can reliably have this problem instead.)

GiteaMirror commented

2025-11-02 03:22:08 -06:00

@francoism90 commented on GitHub (Feb 28, 2017):

Confirm here, on the latest commit push will cause an error on SSH. Version r4995.5bd22a2f-1 works fine.

@francoism90 commented on GitHub (Feb 28, 2017): Confirm here, on the latest commit push will cause an error on SSH. Version r4995.5bd22a2f-1 works fine.

GiteaMirror commented

2025-11-02 03:22:08 -06:00

@lunny commented on GitHub (Mar 1, 2017):

~~Yes. so you have to remove your ssh environment file and patch #1077~~

@lunny commented on GitHub (Mar 1, 2017): ~Yes. so you have to remove your ssh environment file and patch #1077~

GiteaMirror commented

2025-11-02 03:22:08 -06:00

@lunny commented on GitHub (Mar 1, 2017):

@francoism90 do you have the same issue with @jmert ?

@lunny commented on GitHub (Mar 1, 2017): @francoism90 do you have the same issue with @jmert ?

GiteaMirror commented

2025-11-02 03:22:08 -06:00

@lunny commented on GitHub (Mar 1, 2017):

@jmert @francoism90 please help to confirm the latest #1077 fix this issue.

@lunny commented on GitHub (Mar 1, 2017): @jmert @francoism90 please help to confirm the latest #1077 fix this issue.

GiteaMirror commented

2025-11-02 03:22:09 -06:00

@jmert commented on GitHub (Mar 1, 2017):

I manually applied the patch from #1077 on top of master (version 1.0.0+361-g9cb08a3c) and rebuilt within the AUR package specification. After updating, restarting, and removing the environment file, I again receive the error I originally reported.

tl;dr The patch in #1077 doesn't fix the issue for me.

(Once I restore the environment file, though, I can push a new branch, so that's a verify on my end for fixing #1073)

@jmert commented on GitHub (Mar 1, 2017): I manually applied the patch from #1077 on top of master (version 1.0.0+361-g9cb08a3c) and rebuilt within the AUR package specification. After updating, restarting, and removing the environment file, I again receive the error I originally reported. tl;dr The patch in #1077 doesn't fix the issue for me. (Once I restore the environment file, though, I can push a new branch, so that's a verify on my end for fixing #1073)

GiteaMirror commented

2025-11-02 03:22:09 -06:00

@lunny commented on GitHub (Mar 1, 2017):

@jmert Thanks for your confirmation since I cannot reproduce it myself. I just sent another commit and I wish it could resolve your issue.

@lunny commented on GitHub (Mar 1, 2017): @jmert Thanks for your confirmation since I cannot reproduce it myself. I just sent another commit and I wish it could resolve your issue.

GiteaMirror commented

2025-11-02 03:22:09 -06:00

@francoism90 commented on GitHub (Mar 1, 2017):

@lunny Yes, same issue as @jmert (I'm the maintainer of the gitea-git package).

#1077
Should c.GlobalIsSet("config") be the first one to check, instead of c.IsSet("config")?
Don't know how custom variables are handled by Gitea, but is it correct that it checks for GITEA_CUSTOM in the default config first, and second the global set in a systemd service for example?

@francoism90 commented on GitHub (Mar 1, 2017): @lunny Yes, same issue as @jmert (I'm the maintainer of the gitea-git package). #1077 Should c.GlobalIsSet("config") be the first one to check, instead of c.IsSet("config")? Don't know how custom variables are handled by Gitea, but is it correct that it checks for GITEA_CUSTOM in the default config first, and second the global set in a systemd service for example?

GiteaMirror commented

2025-11-02 03:22:09 -06:00

@lunny commented on GitHub (Mar 1, 2017):

When a git push occupied, SSH will set SSH_ORIGINAL_COMMAND and then call gitea serv --config=xxxx then Gitea will call the SSH_ORIGINAL_COMMAND git command. The git command will call gitea hook --config=xxxxx pre-receive, gitea hook --config=xxxxx update and gitea hook --config=xxxxx post-receive.

The different between IsSet and IsGlobalSet is IsSet means gitea hook update --config=xxxxx but IsGlobalSet means gitea hook --config=xxxxx update. The --config's position is not different.

So GITEA_CUSTOM will be ignored, this env will only be checked by gitea web and will write the variable to the authorized_keys and hooks files. So gitea serv and gitea hook will no need care GITEA_CUSTOM.

@francoism90 have you use the latest #1077 ? It should resolve your issue.

@lunny commented on GitHub (Mar 1, 2017): When a git push occupied, SSH will set `SSH_ORIGINAL_COMMAND` and then call `gitea serv --config=xxxx` then Gitea will call the `SSH_ORIGINAL_COMMAND` git command. The git command will call `gitea hook --config=xxxxx pre-receive`, `gitea hook --config=xxxxx update` and `gitea hook --config=xxxxx post-receive`. The different between `IsSet` and `IsGlobalSet` is `IsSet` means `gitea hook update --config=xxxxx` but `IsGlobalSet` means `gitea hook --config=xxxxx update`. The `--config`'s position is not different. So `GITEA_CUSTOM` will be ignored, this env will only be checked by `gitea web` and will write the variable to the `authorized_keys` and hooks files. So `gitea serv` and `gitea hook` will no need care `GITEA_CUSTOM`. @francoism90 have you use the latest #1077 ? It should resolve your issue.

GiteaMirror commented

2025-11-02 03:22:10 -06:00

@francoism90 commented on GitHub (Mar 1, 2017):

@lunny Your branch indeed fixes the issue! :)
Also thanks for your information about the configuration handling.

@jmert I simple used the branch of @lunny git://github.com/lunny/gitea.git#branch=lunny/bug_fix_push

$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 290 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
To ssh://host:52687/francoism90/my-repo.git
   7333209..c5933a0  master -> master

@francoism90 commented on GitHub (Mar 1, 2017): @lunny Your branch indeed fixes the issue! :) Also thanks for your information about the configuration handling. @jmert I simple used the branch of @lunny ```git://github.com/lunny/gitea.git#branch=lunny/bug_fix_push``` ``` $ git push Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 290 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) To ssh://host:52687/francoism90/my-repo.git 7333209..c5933a0 master -> master ```

GiteaMirror commented

2025-11-02 03:22:10 -06:00

@jmert commented on GitHub (Mar 1, 2017):

@lunny The latest commit also fixes the issue for me. Thanks!

@jmert commented on GitHub (Mar 1, 2017): @lunny The latest commit also fixes the issue for me. Thanks!

GiteaMirror referenced this issue

2025-11-02 11:44:54 -06:00

[PR #409] [MERGED] Fixed vulnerabilities labels #15364

Sign in to join this conversation.