-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
GPG Commit Signatures by Gitea not working anymore in dev builds #19964
Comments
This comment was marked as outdated.
This comment was marked as outdated.
Ok, thanks. I changed command to git config --file /data/gitea/gitea-repositories/.gitconfig user.signingkey B0292765
git config --file /data/gitea/gitea-repositories/.gitconfig commit.gpgsign true and now gitea-signed commits showing as "Signed with default key by: Gitea". But creation of new signed commits (merge or new repo init) still failing with the same error in log. In |
I think it's the intentional behavior (which should be documented as well) because the Git's home directory is changed. And when Gitea runs as a server, it shouldn't use user's config. |
Now when i create new unitialized repo in gitea ui and push to main or new branch, there error in
but [repository]
ROOT = /data/gitea/gitea-repositories |
It should be fixed by #19930 The problem is that the git command is called before git.Init in a post hook.
|
it might have already been said, but I'd argue that when Gitea runs as a server it should pick up user's gitconfig. I, for one, am running Gitea with a dedicated user, even the docs used to endorse that, if I recall well. never mind, decisions have been made to change it, so be it, would a symlink in |
The problem is that there will be more and more options be put in the gitconfig in the future, some may affect git's behavior, even security. I believe most developers themselves won't like their own So, the gitconfig is isolated from the user's personal config file.
Either of them should work. |
turns out a [user]
[user]
>---email = gitea@fake.local
>---name = Gitea
[core]
>---quotePath = false
>---commitGraph = true
[receive]
>---advertisePushOptions = true
>---procReceiveRefs = refs/for
[gc]
>---writeCommitGraph = true which is a little different after the changes I did to further, I see a same applies to GPG (for commit/push signing): there is a new folder in
these changes could potentially break some deployments, I'm just saying. in fact they already did.
actually I have to thank you for replying to me, because I have just "fixed" another issue I've been having with Gitea for upwards of a week (not the mirror stuff mentioned elsewhere - #19928): I could not merge in the webUI, I was receiving a bunch of log of GPG signing issue thanks to recent changes to
|
That
sadly ... yes, so the PR has been marked as |
right, will be on the lookout for those changes 🦅
well, I am running master in prod so that's on me to deal with it as it happens. 🙈 perhaps a couple of additional points could be added to the release notes on how to resolve the situation, at least for other operators' sake. |
Sorry for bothering, I'd like to announce a breaking change between 1.17rc1 and next release. In 1.17rc1, the Git HOME was So in next release, the PR #20114 introduced a new option
After upgrading, Sorry for the inconvenience. 🙏 |
so to make sure I understand, that is, from what would happen if I set the newly created just as an aside, how have we arrived at this particular ( I'll probably try my old trick - symlinking relevant files/folders in there, it worked last time. |
Yes
That's fine, setting the git.HOME_PATH to the existing git home also works and then you need to do nothing more to upgrade from 1.16.x
symlinking is also fine. the full story is pretty long:
|
thanks for the reply @wxiaoguang, that's a rather lengthy process.. for anyone interested, I just tried replicating the original way of doing things (now I sound old-manish) by simply setting did't even need to symlink anything anywhere. |
That was the plan. 👍 |
Hey there, I have generated a gpg key (
I added the respective config to
My I generated the pgp key using Every time I try to sign something using the Web UI I get an error code 405 and the following error within logs:
I am running gitea using docker and docker-compose. This is my docker-compose.yml:
This is the only issue or mention I could find that somewhat mentions my problem. |
Description
Latest builds showing earlier merged signed commits as
No known key found for this signature in database
.New merged commits are unsigned.
New initialized repositories are created unsigned with
SIGNING_KEY = default
and not created at all with error 500 when specifying KEYID instead of default and adding SIGNING_NAME, SIGNING_EMAIL as per docs.Server GPG key without expiry date not changed in last two years, git or gitea relevant config parameters either.
git config --global user.signingkey B0292765 git config --global commit.gpgsign true
When i create manual test commits inside container they are signed.
Gitea Version
1.17.0+dev-709-gff82a1831
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Docker image gitea/gitea:dev
Database
PostgreSQL
The text was updated successfully, but these errors were encountered: