Add instance-level secrets

[jbgomond]

This PR adds instance-level secrets, and so closes #27373.

I did the implementation next to the current secrets code. I was wondering though if it was intentional that the code was outside the action files or legacy ? (it's out of the scope of this PR, but I was wondering)

[jbgomond]

Is it ok to be merged ?

[GiteaBot]

This pull request has a last call and has not had any activity in the past two weeks. Consider it to be a polite refusal. 🍵

[techknowlogick]

Reopening.

While we have instance wide variables, having instance wide secrets would be useful for a specific use case, if the instance is targeted to specific user group then this could work. As it is possible to extract secrets through various ways if you have access the be able to run a workflow, so it wouldnt work to protect a secret on a public instance or on one with untrusted users.

Previously when I used drone I did something like this to store docker hub secrets as I had repos in different orgs, but they all needed to push to the same place. And having this allowed me not to have to duplicate a secret. This only worked as I was the only one on the instance.

The above is to say I am welcoming of this PR, and would love to see it get in, I’m thinking it just needs some guide rails on it to ensure when people use it they are aware of the caveats.

[lunny]

per #27725 (review), I think maybe we can close this one.

[jbgomond]

For public instances this a Anti-Feature. Even for closed instances, org secrets should be enough

I disagree on that one. For public instances sure, it's useless. But Gitea is used by small firms or groups to have a private Git solution, and projects are separated in different "organisations", as are "workspaces" in Bitbucket, to separate the clients / projects.

In that type of situation (it's my case), we have single Docker instance, and we need to store passwords across all ""organisations"" because it's the same account. Using variables is not the solution, because they are shown plain text in the action logs.

Without instance level secrets, the only solution is to duplicate secrets in all organisations, and in case of changes, to update all of them. It's not feasable, I have more than 100 organisations (projects) created.

I understand that the secret system is flawed at its core, but in that case, it is the same with organisation secrets. Maybe there's room to improve that then ? Also, if we are scared about public instances, maybe a startup option would be the solution ? So that administrators are voluntarily enabling the feature ?

[techknowlogick]

@jbgomond I think we pretty much have the same use case for this.

[lunny]

Maybe we can have a configuration item so users can chose enable/disable it?

[jbgomond]

Fine for me, a good intermediate solution

[lunny]

Fine for me, a good intermediate solution

So that could you add the global configuration in this PR and disabled by default?

[ZPascal]

Hello @lunny, I have rebased the existing PR and opened a new one here PR to move the issue forward. If necessary, I would take over the PR and adjust the necessary code lines to embed the desired change (global configuration parameter).

[jbgomond]

Hello, thanks for the help @ZPascal 👍 I updated the branch. I'll test out everything and add the startup option tomorrow.

[ZPascal]

Hello, thanks for the help @ZPascal 👍 I updated the branch. I'll test out everything and add the startup option tomorrow.

@jbgomond Do you need further support to push the topic?