Gitea: 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. :wink:

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

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. :wink:

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. :wink:

[stale[bot]]

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. :wink:

[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.