documentation: explain how/where to add GPG within official Docker container

[alexanderadam]

Description

Currently the documentation regarding GPG integration/Commit signing is good but as far as I can see, there is no explanation how to integrate a key within the official Docker container. Or am I missing something?

[zeripath]

It's very difficult to say how best to do this. We're very happy to link or offer advice if there is a good suggestion but giving out bad advice would probably be worse than giving out no advice

[alexanderadam]

Isn't giving no advice the same like giving a bad advice? Because if people don't even know what configurations are considered bad, they definitely will configure the way it is considered bad. 😉

Also obviously, I wasn't asking about documenting a bad advice at here. 😉

From a user perspective it would be nice, just having to add a read-only mount (i.e. /signing-keys) and then adding the relevant key in the configuration (SIGNING_KEY, SIGNING_NAME, SIGNING_EMAIL).

But I guess it is not as easy as that…

[zeripath]

It's only their key they're exposing. If we give bad advice - we're exposing everyone's key.

I'm sure docker must have some secure way of passing secrets and some way of interfacing to a gpg_agent. I just don't know and haven't used these systems. If you know better and have a good idea for your to do it in a basic way - especially if you know a way of increasing the security say by using a tpm'd or credit-card key - then by all means write the suggestion and a pr.

At the moment we dodge this all by saying:

Installing and generating a GPG key for Gitea

It is up to a server administrator to determine how best to install a signing key. Gitea generates all its commits using the server git command at present - and therefore the server gpg will be used for signing (if configured.) Administrators should review best-practices for gpg - in particular it is probably advisable to only install a signing secret subkey without the master signing and certifying secret key.

[alexanderadam]

If we give bad advice - we're exposing everyone's key.

Which is exactly why I was writing

I wasn't asking about documenting a bad advice at here. 😉

I'm sure docker must have some secure way of passing secrets and some way of interfacing to a gpg_agent.

So is the Gitea implementation relying on a running gpg-agent?

If so, there's the possibility to either mount it from outside (variant A)) or use one from inside the container (variant B)), regarding this blog post.

But in that case it is probably better to add a running gpg-agent in the Docker container, right? Because if people are starting to use the gpg-agent from the host system, they might unintentionally expose all other keys from the gpg-agent as well. Which might cause other serious problems if there's a security flaw within gitea.

So the mentioned variant B) of the blog post is probably a safer variant. It obviously should not mount the ~/.gnupg directory, though but rather a dedicated directory for gitea.

I don't see anything gpg-agent related within the current Dockerfile though. So I guess it would also need a PR for adding gpg-agent to the Dockerfile.

Maybe having a dedicated mount point and an easy solution for adding a key (i.e. an add-signging-key entrypoint that does something like this) would make sense.

But I'm definitely not an expert regarding this topic either (this is why I opened this issue in the first place).

EDIT:

1. this comment reads like the signing key comes from a repository directory? Or am I misunderstanding this?
2. this line looks like gpg is called by Gitea. But when I try to call gpg within the container, there doesn't seem to be a gpg binary in $PATH. So maybe it needs a PR for the Dockerfile anyway?
3. Maybe a strong key should be generated if none is available, like suggested for GitLab here and here. But I guess this would be another issue as well. 😉

[stale]

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.

[alexanderadam]

Stalebot, please! Close this only if you are going to document it by yourself. 😉

[zeripath]

Sorry @alexanderadam I forgot about marking this issue confirmed. We still need this guide...

It might be simplest to put things in comments here, a gist or even start a PR. If we have a PR we should try to refrain from general comments - but rather use githubs suggestion syntax or provide diffs to try to fix things directly so that the PR doesn't descend too much into bikeshedding.

My thoughts:

1. We've finally got a PR that adds gnupg to the dockerfile.
2. That allows to reference the host gnupg as needed.
3. Another thing is whether docker secrets could be used to provide the key in some way.

[toxic0berliner]

sorry to bother everyone here, but I've been looking for about an hour and I can't find any helpful guide as I'm really a noob when it comes to GPG, and as said here there is nothing realy helpful in the doc to set it up.
I also sadly see here that there was a request to auto generate a key at initial docker startup that was rejected (without much debate I feel) that would have solved all my issues.

I'm working on my own on a gitea protected by other means and don't care about signing in any way other than it prevents me from using the pull requests. I even feel gpg might not really be mandatory to use PR but somehow it seem gitea wants it...

So giving a little help in setting it up even with a few warning saying one having concerns about code signing and security should not even follow the guide would actually still be helpfull to all those who don't really care but for which it goes just in their way..

Not sure my tone came out right, there is no bad intentions or reproaches from me here, only lots of love for the kind work everyone here makes available, just with a bit of frustration added in by my not finding a way to test PR in gitea for now, but that'll pass ;)

[Ryonez]

I've been going though the docs.

I'm at the stage the git user's gpg has signing keys, git is configured to use it though the configs, but there is no indication of Gitea as to if their signed or not.

As far as I can tell this isn't working.

Just pulled a new repo via git onto my local machine, and there's no signature for the initial commit, so Gitea's signing is definitely not working for me.

[plantroon]

I got this working with some help from delvh on matrix. He pointed me to this: https://blog.gitea.io/2022/07/gitea-1.17.0-is-released/#-internal-gitconfig-19732httpsgithubcomgo-giteagiteapull19732

This is in fact stated in documentation as well: https://docs.gitea.com/next/administration/signing#signing_key (Since 1.17,...)

You must have the correct .gitconfig and .gnupg in this new home directory (/var/lib/gitea/home inside the container). I think the documentation is sufficient, it just wasn't immediately clear what it's about, so I simply missed it.

Also, if you are running gpg command from within the container like I did, under the default user, whose home directory is in fact /var/lib/gitea/git, make sure to specify gpg --homedir /var/lib/gitea/home when working with the keyring.

I will add that I run the rootless version of the container and I cannot say how it works in the other version.

[PlexSheep]

I just spent a couple hours trying to set my instance up so that actions performed in th gui would be signed. It did not work. I feel like the only documentation we have is this single paragraph. It was very frustrating without even achieving anything.

Also, some points on the topic:

• Please also support passphrases for private keys, they are the norm
• It needs to be properly documented, where the "server gpg key" needs to go. Ideally, have the user upload one in the admin panel and automate everything else.