It should be possible to provide a file to LFS_JWT_SECRET

[varanauskas]

Feature Description

TLDR: LFS_JWT_SECRT should be able to be stored in a separate file outlined by outlined by LFS_JWT_SECRET_URI

Secrets in the [security] section of config allow providing both an inline secret as well as a file where the secret is stored with the _URI suffix.

For example

# /etc/gitea/app.ini
[security]
INTERNAL_TOKEN=#SOME_SECRET_VALUE

# Can be replaced by:
# /etc/bites/app.ini
[security]
INTERNAL_TOKEN_URL=/etc/gitea/secrets/internal_token

# /etc/gitea/secrets/internal_token then contains the #SOME_SECRET_VALUE

This allows for better installation/maintenance of Gitea, as /etc/gitea/app.ini could be stored in version control, as all secrets would be outlined separately.

Proposal:

I propose adding a new config key LFW_JWT_SECRET_URI that would work the same as INTERNAL_TOKEN_URI by allowing users to specify a separate file where the LFS_JWT_SECRET is stored

Screenshots

No response

[varanauskas]

I do not have Go experience, but could try implementing this as it seems simple enough, as long as someone can review my changes

[lonix1]

Excellent idea.

Two points:

1. There are four secrets, and two have a file option:

   INTERNAL_TOKEN / INTERNAL_TOKEN_URI
   JWT_SECRET
   LFS_JWT_SECRET
   SECRET_KEY / SECRET_KEY_URI

2. We should use docker compose secrets for this, so for example SECRET_KEY_URI is mounted as /run/secrets/my-secret-key. But when I did that I discovered it is mounted as root:root and gitea runs as gitea:gitea.

Ideally we should have file secrets for all four secrets. But how do we deal with the second point? (How did you do it?)

[techknowlogick]

@lonix1 two have the URI as an option.

As well, if you are using the docker image, then all of them are, in theory, available as reading from a file if using env vars.

[lonix1]

two have the URI as an option

Thanks, you are right! I was probably looking at an old app.example.ini. So only JWT_SECRET_URI and LFS_JWT_SECRET_URI are needed.

if you are using the docker image, then all of them are, in theory, available as reading from a file if using env vars.

I assume you mean this?...

EDIT: actually, by putting them into env vars, it's a bad idea. They could get logged.

[wxiaoguang]

Make environment-to-ini support loading key value from file #24832

[lonix1]

Thank you very much @wxiaoguang for your advice. But I'm struggling to understand that PR (I'm not a go developer). Is there an example how to use it?

[wxiaoguang]

It's for docker users. See the documents.

	Environment variables of the form "GITEA__SECTION_NAME__KEY_NAME__FILE"
	will be mapped to the ini section "[section_name]" and the key
	"KEY_NAME" with the value loaded from the specified file.

And https://docs.gitea.com/1.20/installation/install-with-docker#managing-deployments-with-environment-variables

[lonix1]

Oh! 😄 Ok, that is what we were talking about above. But as I said there, keeping secrets in environment variables is a bad idea. Sometimes it's the only option though.

@varanauskas is right, we should have four file-based options for the four secrets.

But we need to consider that there is no good way to load them into the app, without leaking secrets. Maybe env vars is the only way, I hope there is a better way.

[wxiaoguang]

keeping secrets in environment variables is a bad idea. Sometimes it's the only option though.

Sorry I didn't get your point. See:

Environment variables of the form "GITEA__SECTION_NAME__KEY_NAME__FILE"
with the value loaded from the specified file.

They are indeed able to be stored in your file.

[lonix1]

Sorry @wxiaoguang, I didn't see that part.

So we can do this:

docker-compose.yml

# ...
environment:
  GITEA__server__LFS_JWT_SECRET__FILE: /LFS_JWT_SECRET
  GITEA__security__INTERNAL_TOKEN__FILE: /INTERNAL_TOKEN
  GITEA__security__SECRET_KEY__FILE: /SECRET_KEY
  GITEA__oauth2__JWT_SECRET__FILE: /JWT_SECRET
volumes:
  - ./INTERNAL_TOKEN:/INTERNAL_TOKEN:ro
  - ./JWT_SECRET:/JWT_SECRET:ro
  - ./LFS_JWT_SECRET:/LFS_JWT_SECRET:ro
  - ./SECRET_KEY:/SECRET_KEY:ro

$ cat ./INTERNAL_TOKEN

some secret

$ cat ./JWT_SECRET

some secret

$ cat ./LFS_JWT_SECRET

some secret

$ cat ./SECRET_KEY

some secret

Is that what you mean?

[wxiaoguang]

Yes, it should work this way.

If it doesn't work, feel free to open an issue for it (with reproducible steps)

[lonix1]

@wxiaoguang Thanks! That is very good news.

@varanauskas I am going to do it this way. I will let you know my results.