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 ?

[lunny]

@go-gitea/technical-oversight-committee

[wolfogre]

I hope we can add a warning when adding a global secret in the UI. Like

"
Although secrets will be masked if users try to print them in Actions workflows, this is not absolutely secure. Users can still obtain the contents of secrets by writing malicious workflows, so please ensure that global secrets are not used by people you do not trust. Otherwise, please use organization/user-level or repository-level secrets to limit their scope of use. Alternatively, if it's acceptable to expose their contents, please use global variables.
"

Or it will be terrible if someone adds a global secret to a public instance and thinks it will be safe just because it's labeled as "secret".

[delvh]

@jbgomond will you add the change, or should someone else take over?

[jbgomond]

No pb, I'll do it tomorrow

[jbgomond]

Is it good like that ?

[KN4CK3R]

I see two problems:

• For public instances this a Anti-Feature. Even for closed instances, org secrets should be enough
• No one knows about possible existing global secrets. But we have this problem already with org/user secrets.

[KN4CK3R]

Not needed, {{range }} supports {{else}}.

[delvh]

Wait, we already have instance level variables.
As mentioned by everyone so far, what is the usecase for instance wide secrets?
Secrets are meant to stay secret by design.
However, instance-wide secrets are not secret at all as everyone can print value.
As such, it sounds like a really bad idea to me.
Or am I missing something?

[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